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

[Byron Campen]

	Alright, I'm checking this in shortly.

Best regards,
Byron Campen

> 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
>
>
>
> _______________________________________________
> 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/20070926/02ae73e3/attachment.htm>