Yes it does create confusion and caller should not use answer1. Best
option for callee, to make sure that this kind of call flow works, is to
not send any sdp in 200 OK. Or maybe the standard should say that answer
sdp in 200 OK must be same as last answer.

Sanjay

>-----Original Message-----
>From: Paul Kyzivat (pkyzivat) 
>Sent: Tuesday, February 20, 2007 1:36 PM
>To: Attila Sipos
>Cc: Christer Holmberg (JO/LMF); Sweeney, Andrew (Andrew); Ira 
>Kadin; Sanjay Sinha (sanjsinh); Miljanovic, Nebojsa (Neb); 
>[email protected]
>Subject: Re: [Sip-implementors] SDP in 2xx response after reliable 18x
>
>I've mentioned a slightly different scenario before that 
>pertains to this discussion.
>
>-> INVITE w/offer1
><- 18x (reliable) w/answer1
>-> PRACK w/offer2
><- 200 PRACK w/answer2
><- 200 INVITE w/answer1
>-> ACK
>
>The above is a legal flow. The caller *should not* end up 
>using answer1.
>
>The logic that says to take a changed answer in a 200 as an 
>override to an answer received in a 18x would seem logically 
>to lead to using
>answer1 in the above. You *could* treat it differently, but 
>that makes things even more confusing.
>
>       Paul
>
>Attila Sipos wrote:
>>>> Now, I don't know why the 2xx response's SDP should be ignored.
>>>> Maybe someone can think of a scenario where not ignoring 
>the 2xx SDP 
>>>> would cause an error.  ??
>>> If you have already received SDP on the same dialog as the 200 SDP, 
>>> and you are listening to the media associated to that dialog, it 
>>> should not cause an error - assuming the sender of the SDP 
>behaves correctly.
>> 
>> You are talking about the standards again, are you not?
>>  
>> What I mean is that clearly  the SIP protocol has been designed this 
>> way because of some kind of problem that would be caused if it wasn't
>> done this way.   So, what are the problems?   What is an 
>example that illustrates
>> the problems?
>>  
>> Regards,
>> Attila
>>  
>>  
>> 
>> _______________________________________________
>> 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

Reply via email to