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

Dean Willis wrote:
> 
> On Nov 21, 2007, at 3:36 PM, Robert Sparks wrote:
> 
>> That's an improper dichotomy for the question at
hand.
> 
> Why? The question at hand is, if I have it "If we
send an answer in a 
> reliable provisional response, should we include a copy
of that answer 
> in the final 200 OK response?"
> 
> We agree that IF we send the answer in both places,
then it MUST be the 
> same answer, because if it isn't then all sorts of
things get confusing. 
> Right? The only question is whether or not to include
it.
> 
>> Nobody's arguing against ignoring the SDP if it
shows up.
>>
>> The question to be addressed is the ambiguity the
spec currently 
>> suffers around whether things should put something
there.
>> The danger in leaving the "its ok to put
something there because 
>> things are supposed to ignore it" is the
slippery slope that
>> leads to people _requiring_ it be there, then
_requiring_ that it mean 
>> something (which somebody must already be doing or
>> people wouldn't be so uptight about it being there)
and then we have a 
>> deployed de-facto standard that does not match the
documentation.
>>
>> Is that what you're arguing for?
> 
> Well, I hope I'm not arguing in favor of ambiguity.
> 
> I'm trying to argue for stating in section 2.1 of 
> draft-ietf-sipping-sip-offeranswer-04.txt (pattern 3)
that the final 200 
> OK  either MAY or SHOULD contain a copy of the offer
sent in the 
> reliable provisional response, as this approach offers
less backward 
> compatibility headache than not including a copy of the
answer.

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.

	Paul

> It's 
> also consistent with the "preview" model of
sending an answer in a 
> non-reliable provisional response as discussed in
section 3.1 of that 
> draft.
> 
> -- 
> Dean
> 
> 
> -- 
> 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
> 


_______________________________________________
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 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