Re: SIPit21: SDP in a 200OK when using 100rel

There can be several UPDATEs with their associated
200-UPDATES before  
the 200-INVITE.
Remember that UPDATE is a nonINVITE transaction and there
may be a  
_long_ time between the UPDATE and the 200-INVITE.

Paul drew the arrow backwards for the 200-UPDATE though -
did that  
mislead you?

RjS

On Nov 21, 2007, at 7:02 PM, Dean Willis wrote:

>
> On Nov 21, 2007, at 5:15 PM, Paul Kyzivat wrote:
>>
>> That may seem simple and harmless. But it gets ugly
when  
>> additional offer/answers happen:
>>
>>   Alice               Bob
>>     |  INVITE offer1   |
>>     |----------------->|
>>     |  183 answer1     |
>>     |<-----------------|
>>     |  PRACK           |
>>     |----------------->|
>>     |  200 PRACK       |
>>     |<-----------------|
>>     |  UPDATE offer2   |
>>     |<-----------------|
>>     |  200 UP answer2  |
>>     |<-----------------|
>>     |  200 IN SDP?     |
>>     |<-----------------|
>>
>> Now what should be in the 200 for the invite?
>>
>> Its better to do what is already required - send no
SDP in the 200  
>> for the invite.
>
> Huh. Is it actually ok to send a 200 OK for the UPDATE
before  
> sending the 200 OK for the INVITE? That seems like a
race condition  
> from hell.
>
> If it's OK only because you can claim the INVITE's O/A
sequence  
> completed before the UPDATE was sent, then we're making
the SIP  
> state machine dependent on the O/A model, and that's
just wrong.
>
> --
> Dean
>
>



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

On Nov 21, 2007, at 10:57 PM, Robert Sparks wrote:

> There can be several UPDATEs with their associated
200-UPDATES  
> before the 200-INVITE.
> Remember that UPDATE is a nonINVITE transaction and
there may be a  
> _long_ time between the UPDATE and the 200-INVITE.
>
> Paul drew the arrow backwards for the 200-UPDATE though
- did that  
> mislead you?
>

Ah, yes, I read that Alice had sent a second conflicting
offer in  
UPDATE.

However, even with this directionality, the answer in the
INVITE-200,  
if present, would have to be a copy of the answer in the
183. This  
doesn't create any error I can see, it just illustrates the
UPDATE  
race condition that would have existed even had there not
been an  
answer in the 183. Early media, early session, and UPDATE
were all  
bad ideas (probably all because of forking and PSTN
interactions)  
IMHO, and I'm pretty sure reliable provisionals are on that
list too.


>>>
>>>   Alice               Bob
>>>     |  INVITE offer1   |
>>>     |----------------->|
>>>     |  183 answer1     |
>>>     |<-----------------|
>>>     |  PRACK           |
>>>     |----------------->|
>>>     |  200 PRACK       |
>>>     |<-----------------|
>>>     |  UPDATE offer2   |
>>>     |<-----------------|
>>>     |  200 UP answer2  |
>>>     |<-----------------|
>>>     |  200 IN SDP?     |
>>>     |<-----------------|
>>>
>>> Now what should be in the 200 for the invite?
>>>
>>> Its better to do what is already required -
send no SDP in the  
>>> 200 for the invite.
>>

--
Dean


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip