Subbu,
take a look at the following draft that talks about it.
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-10.txt
Section 3.1.1 states that if you are UAS, you should not send any SDP in 2xx but
if you are UAC, be ready to ignore it. In other words, don't kill a call if it
is there.
Unfortunate reality is that many endpoints are hardcoded to expect SDP in 2xx
even if offer/answer is fully done. And, they end up killing the call if no SDP
is present in 2xx.
Neb
On 1/20/2009 1:30 AM, Subbu Rajendran wrote:
> Hi All,
> Following is example call flow from RFC 3311 (SIP UPDATE Method). Is SDP a
> must in the 200 OK for INVITE in this case? If it is required, then 200 OK
> should contain 'answer 3'. Is this a legal behavior as answer in 200 OK for
> INVITE ('answer 3') is not based on the offer in the INVITE ('offer 1').
>
> Could anyone please explain or point me to the RFC that explains this case?
>
> Caller Callee
>
> (1) INVITE with offer 1
> |---------------------------->|
>
> (2) 180 with answer 1
> |<----------------------------|
>
> (3) PRACK
> |---------------------------->|
>
> (4) 200 PRACK
> |<----------------------------|
>
> (5) UPDATE with offer 2
> |---------------------------->|
>
> (6) 200 UPDATE with answer 2
> |<----------------------------|
>
> (7) UPDATE with offer 3
> |<----------------------------|
>
> (8) 200 UPDATE with answer 3
> |---------------------------->|
>
> (9) 200 INVITE (SDP ?)
> |<----------------------------|
>
> (10) ACK
> |---------------------------->|
>
>
> Thanks & Regards,
> Subbu
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
