< Previous by Date	Date Index	Next by Date >
< Previous in Thread	Thread Index	Next in Thread >

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

From: "Scott Godin" <slgodin@xxxxxxxxxxxx>
Date: Fri, 21 Sep 2007 22:47:07 -0400

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@xxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Byron Campen
Sent: September 21, 2007 5:27 PM
To: Yuan, Frank
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Justin Matthews
Sent: Friday, April 20, 2007 7:11 PM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
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