[reSIProcate] SDP in ACK after intial offer/answer exchange causesBYE from resip/dum

[Scott Godin]

Looks good to me!  : )

 

From: Byron Campen [mailto:bcampen at estacado.net] 
Sent: Monday, September 24, 2007 4:01 PM
To: Scott Godin
Cc: 'Yuan, Frank'; resiprocate-devel at list.resiprocate.org
Subject: Re: [reSIProcate] SDP in ACK after intial offer/answer exchange
causesBYE from resip/dum

 

          Here's a diff from my working copy. If you're familiar with
the code, give it a look.

 

*snip*

Index: InviteSession.cxx

===================================================================

--- InviteSession.cxx   (revision 7255)

+++ InviteSession.cxx   (working copy)

@@ -1251,6 +1251,7 @@

          break;

       case OnAck:

+      case OnAckAnswer: // .bwc. Don't drop ACK with SDP!

          mCurrentRetransmit200 = 0; // stop the 200 retransmit timer

          handler->onAckReceived(getSessionHandle(), msg);

          break;

Index: ServerInviteSession.cxx

===================================================================

--- ServerInviteSession.cxx     (revision 7255)

+++ ServerInviteSession.cxx     (working copy)

@@ -778,6 +778,7 @@

    switch (toEvent(msg, sdp.get()))

    {

       case OnAck:

+      case OnAckAnswer:

       {

          mCurrentRetransmit200 = 0; // stop the 200 retransmit timer

          transition(Connected);

@@ -785,14 +786,16 @@

          break;

       }

-      case OnAckAnswer:

-      {

-         mCurrentRetransmit200 = 0; // stop the 200 retransmit timer

-         sendBye();

-         transition(Terminated);

-         handler->onTerminated(getSessionHandle(),
InviteSessionHandler::GeneralFailure, &msg);

-         break;

-      }

+//       .bwc. unsolicited SDP in ACK; it would probably make sense to
just

+//       ignore.

+//      case OnAckAnswer:

+//      {

+//         mCurrentRetransmit200 = 0; // stop the 200 retransmit timer

+//         sendBye();

+//         transition(Terminated);

+//         handler->onTerminated(getSessionHandle(),
InviteSessionHandler::GeneralFailure, &msg);

+//         break;

+//      }

       

       case OnCancel:

       {

*snip*

 

Best regards,

Byron Campen





Makes sense to me.  If we can handle the call - why not try?  A Warning
log is probably appropriate as a mechanism to detect non-compliant
implementations.

 

Scott

 

From: resiprocate-devel-bounces at resiprocate.org
[mailto:resiprocate-devel-bounces at resiprocate.org] On Behalf Of Byron
Campen
Sent: September 21, 2007 5:27 PM
To: Yuan, Frank
Cc: resiprocate-devel at list.resiprocate.org
Subject: Re: [reSIProcate] SDP in ACK after intial offer/answer exchange
causesBYE from resip/dum

 

            Looking back at this, it seems that we might want to change
the code to just silently ignore the bad SDP instead of tearing down the
call. Any opinions?

 

Best regards,

Byron Campen






Here is SIP FAQ from SIP Expert Jonathan:

 

 

If I get a new SDP body in the ACK, and I don't like the media type, how
can I indicate its unacceptable to me?

 

It doesn't work that way. You should not get a "new" SDP in the ACK. SDP
goes in ACK only if there was no SDP in INVITE, then SDP was included in
the 200 OK. This SDP should represent a subset of the media "offered" in
the 200 OK. In other words, a normal SIP transaction has one SDP in the
INVITE, and another in 200 OK. Now, we have the same two phase process,
but the first SDP is in the 200 OK, and the second in the ACK.

Categories for this entry

 

Last update: 2000-07-11 16:16

Author: Jonathan Rosenberg

 

 

Regards,

 

FrankY

 

-----Original Message-----
From: resiprocate-devel-bounces at list.resiprocate.org
[mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf Of
Justin Matthews
Sent: Friday, April 20, 2007 7:11 PM
To: resiprocate-devel at list.resiprocate.org
Subject: [reSIProcate] SDP in ACK after intial offer/answer exchange
causesBYE from resip/dum

 

A certain UA, with "bridges in the logo" (:-) I love that comment),  is

sending SDP in the ACK during the initial call setup, but after the

offer/answer has been completed in the invite/200.  This causes DUM in

ServerInviteSession::dispatchAccepted() to handle the event as
OnAckAnswer

and send a BYE, terminating the session.

 

Section 13.2.1 in 3261 states some restrictions here, but it doesn't
appear

that this case is spelled out.  To me I can understand how this is

considered bad behavior, with no way to answer this new offer in the
ACK.

Question is, is sending a BYE too harsh here?  Could this decision be
left

up to the APP?  For example, if the SDP is the same as the initial
INVITE,

just ignore this behavior?

 

UAC               UAS

 

INVITE w/offer ->

200 OK w/answer <-

ACK w/SDP ->

BYE <-

ACK ->

 

 

Thanks,

 

-Justin

 

_______________________________________________

resiprocate-devel mailing list

resiprocate-devel at list.resiprocate.org

https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

_______________________________________________

resiprocate-devel mailing list

resiprocate-devel at list.resiprocate.org

https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

 

_______________________________________________

resiprocate-devel mailing list

resiprocate-devel at resiprocate.org

https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070925/bd63b03c/attachment.htm>