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

[Byron Campen]

	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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070921/c26be16e/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/20070921/c26be16e/attachment.bin>