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

[Byron Campen]

	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/20070924/2e3a4452/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070924/2e3a4452/attachment.bin>