Subject: [Sip] SIPit21: SDP in a 200OK when using 100rel

From: Robert Sparks <[email-masked]>
Date: Mon, 19 Nov 2007 15:13:42 -0600

There was a lot of discussion and disagreement at SIPit21 about  
whether the following 200 OK is allowed (or should) have SDP in it:

INVITE (offer)
-------->
18x (with 100rel) (answer)
<--------
PRACK
--------->
200 OK (can this carry SDP?)
<---------
ACK
--------->

I couldn't find anything definitive in RFC form. Paul's offeranswer  
draft talks about this I think.

If I understand things, the right answer here is that it's not  
supposed to carry any SDP and that you should ignore it if it shows up.

The question is, other than waste, what can go wrong if it is there?  
When we end up with clear text around the requirement, will
it say SDP SHOULD NOT, or MUST NOT appear?

Or do I have this wrong?

RjS

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Victor Grinberg <[email-masked]>
Date: Mon, 19 Nov 2007 15:18:50 -0600

> 18x (with 100rel) (answer)

What if INVITE forked and you got 18x from one of destinations and 200
from another?

--
VictorG

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Mon, 19 Nov 2007 16:22:00 -0500

It is not clear from the call flow if the 200 OK is for PRACK or INVITE?

I guess you meant 200 OK for Invite. If that is the case, I think the
RFC is clear that the answer sdp is optional in it and if it does have
an answer sdp, it MUST be idential to answer in 18x. But I think the
offer-answer draft has clarified it further that it should not have any
answer sdp. This is probably harsh in case of one offer-answer exchange,
but makes sense if there are multiple early dialog offer-answer
exchanges in say Prack/200 OK or using UPDATE.

Sanjay

>-----Original Message-----
>From: Robert Sparks [mailto:[email-masked]] 
>Sent: Monday, November 19, 2007 4:14 PM
>To: sip List
>Subject: [Sip] SIPit21: SDP in a 200OK when using 100rel
>
>There was a lot of discussion and disagreement at SIPit21 
>about whether the following 200 OK is allowed (or should) have 
>SDP in it:
>
>INVITE (offer)
>-------->
>I couldn't find anything definitive in RFC form. Paul's 
>offeranswer draft talks about this I think.
>
>When we end up with clear text around the requirement, will it 
>say SDP SHOULD NOT, or MUST NOT appear?
>
>Or do I have this wrong?
>
>RjS
>
>
>This list is for NEW development of the core SIP Protocol Use 
>[email-masked] for questions on current sip

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Mon, 19 Nov 2007 16:25:34 -0500

Forking is different, since there is different to-tags from forked legs
and so offer-answer applies to each leg.

Sanjay 

>From: Victor Grinberg [mailto:[email-masked]] 
>Sent: Monday, November 19, 2007 4:19 PM
>To: Robert Sparks
>Cc: sip List
>Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
>
>What if INVITE forked and you got 18x from one of destinations 
>and 200 from another?
>
>--
>VictorG
>
>
>
>

---

From: Robert Sparks <[email-masked]>
Date: Mon, 19 Nov 2007 16:23:29 -0600

Yes, I did mean 200 INVITE.

On Nov 19, 2007, at 3:22 PM, Sanjay Sinha (sanjsinh) wrote:

> an answer sdp, it MUST be idential to answer in 18x.
>

Really? Point me to where you find this please.

> But I think the

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Mon, 19 Nov 2007 19:35:52 -0500

Pl. see inline...

>Sent: Monday, November 19, 2007 5:23 PM
>To: Sanjay Sinha (sanjsinh)
>Cc: sip List

I was referring to sec. 13.2.1 of RFC 3261.

 o  If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
 correlated to that INVITE.  For this specification, that is
only the final 2xx response to that INVITE.  That same exact
answer MAY also be placed in any provisional responses sent
prior to the answer.  The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE. 

The strengths of assertion may not be what you are looking for here.

Thanks
Sanjay

>
>> But I think the
>> offer-answer draft has clarified it further that it should not have 
>> any answer sdp. This is probably harsh in case of one offer-answer 
>> exchange, but makes sense if there are multiple early dialog 
>> offer-answer exchanges in say Prack/200 OK or using UPDATE.
>>
>> Sanjay
>>
>>> When we end up with clear text around the requirement, will it say 
>>> SDP SHOULD NOT, or MUST NOT appear?
>>>
>>> Or do I have this wrong?
>>>
>>> RjS
>>>
>>>
>>> [email-masked] for questions on current sip Use 
>>> [email-masked] for new developments on the application of sip
>>>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Nov 2007 19:49:51 -0500

> Really? Point me to where you find this please.

Mostly in 3261 sec 13.2.1. It says:

The first three sentences are the clearly normative part. When combined 
with RFC 3262 definition of reliable provisionals, they say that the 
reliable provisional contains the answer.

The last sentence doesn't really say the UAS may include sdp in 
subsequent responses to the invite transaction, but neither does it say 
you can't. It does say the UAC should ignore them if present, which 
implies they can be present, but says nothing about what value they must 
have if they are present.

AFAIK there is nothing that says the answer may be repeated in the 200. 
However it is seemingly done a lot, so one had better beware.

	Paul

---

From: Robert Sparks <[email-masked]>
Date: Tue, 20 Nov 2007 08:54:01 -0600

Yeah - that's not it - it doesn't match your assertion even.
That text says that _if_ SDP shows up in the 200, you have to ignore it.
It doesn't say anything about it matching the 18x, and it doesn't say  
anything about whether the UAS is allowed to put it in the 200 in the  
first place.

Btw - that passage _IS BEING USED_ to argue that it's ok, and even  
_right_, to put SDP in the 200 OK since things MUST ignore it.

RjS

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Tue, 20 Nov 2007 10:08:07 -0500

Okay, then it can probably be clarified in the offer-answer draft, if it
is not already.

Sanjay

>Sent: Tuesday, November 20, 2007 9:54 AM
>It doesn't say anything about it matching the 18x, and it 
>doesn't say anything about whether the UAS is allowed to put 
>it in the 200 in the first place.
>
>Btw - that passage _IS BEING USED_ to argue that it's ok, and 
>even _right_, to put SDP in the 200 OK since things MUST ignore it.
>
>RjS
>
>correlated 
>> to that INVITE.  For this specification, that is only the final 2xx 
>> response to that INVITE.  That same exact answer MAY also be 
>placed in 
>> any provisional responses sent prior to the answer.  The UAC MUST 
>> treat the first session description it receives as the answer, and 
>> MUST ignore any session descriptions in subsequent responses to the 
>> initial INVITE.
>>
>>>>> supposed to carry any SDP and that you should ignore it 
>if it shows 
>>>>> up.
>>>>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Nov 2007 11:56:48 -0500

The intention was that, when reliable provisionals are used, the answer 
would NOT appear in the 200 OK to the original INVITE. The paragraph in 
RFC3261 is talking specifically about the case of an unreliable 
provisional response.

The drawback of sending the answer in the reliable 18x and then 
repeating it in the 200 OK, is what if they are not the same. It gets 
really complicated if there are multiple O/A exchanges in UPDATE/PRACK 
prior to the final 200 OK.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: "Lincoln Y. Lavoie" <[email-masked]>
Date: Tue, 20 Nov 2007 13:41:13 -0500

Isn't that exactly what preconditions does.  That is, use the 1xx 
messages to pas SDP back and forth until both sides have agreed on the 
media conditions required.

Jonathan Rosenberg wrote:
>> The first three sentences are the clearly normative part. When 
>> combined with RFC 3262 definition of reliable provisionals, they say 
>> that the reliable provisional contains the answer.
>>
>> subsequent responses to the invite transaction, but neither does it 
>> say you can't. It does say the UAC should ignore them if present, 
>> which implies they can be present, but says nothing about what value 
>> they must have if they are present.
>>
>> AFAIK there is nothing that says the answer may be repeated in the 
>> 200. However it is seemingly done a lot, so one had better beware.
>>
>>     Paul
>>
>>>> But I think the

-- 
**********************************************************************
Lincoln Lavoie
Senior Engineer
UNH InterOperability Laboratory
121 Technology Drive, Suite 2, Durham, NH 03824
+1-603-862-4809
AIM: LincolnAtIOL, MSN: [email-masked]
Jabber: [email-masked]

Ars sine scientia nihil est! -- Art without science is nothing.
Scientia sine ars est vacua! -- Science without art is empty.
**********************************************************************

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 20 Nov 2007 20:03:54 +0100

Hi,
 
An implementation should keep offer/answer state and simply discard the SDP in the 200 OK.
 
I don't think that is complicated :)
 
Regards,
 
Christer

________________________________

From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tue 20/11/2007 17:56
To: Paul Kyzivat
Cc: Sanjay Sinha (sanjsinh); sip List
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel

-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net <http://www.jdrosen.net/>                          PHONE: (408) 902-3084
http://www.cisco.com <http://www.cisco.com/>

---

From: Dean Willis <[email-masked]>
Date: Wed, 21 Nov 2007 14:20:28 -0600

On Nov 20, 2007, at 8:54 AM, Robert Sparks wrote:

> It doesn't say anything about it matching the 18x, and it doesn't  
> say anything about whether the UAS is allowed to put it in the 200  
> in the first place.
>

Apply Postel's maxim here.

Broken UAs might (and from what I hear, frequently do) ignore the  
answer in the 18x, instead taking the answer from the 200. If these  
answers are identical, then it works. If they aren't, then it doesn't.

Is it better to have a clearly described irrecoverable failure or a  
working call?

--
Dean

---

From: Robert Sparks <[email-masked]>
Date: Wed, 21 Nov 2007 15:36:10 -0600

That's an improper dichotomy for the question at hand.

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?

RjS

---

From: Dean Willis <[email-masked]>
Date: Wed, 21 Nov 2007 16:22:45 -0600

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

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Nov 2007 18:15:28 -0500

Dean Willis wrote:
> 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.
> 
>> 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.
>>
> 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

---

From: Dean Willis <[email-masked]>
Date: Wed, 21 Nov 2007 19:02:40 -0600

On Nov 21, 2007, at 5:15 PM, Paul Kyzivat wrote:
> 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

---

From: Robert Sparks <[email-masked]>
Date: Wed, 21 Nov 2007 22:57:51 -0600

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:

>> 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?     |
>>     |<-----------------|
>>
> 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.
>
> 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
>
>

---

From: Dean Willis <[email-masked]>
Date: Wed, 21 Nov 2007 23:20:39 -0600

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.

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.

>>> Its better to do what is already required - send no SDP in the  
>>> 200 for the invite.
>>

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 22 Nov 2007 08:02:14 +0000

I don't see it as an "UPDATE race condition". There are legitimate
sequences (arising from 100rel, UPDATE, pre-conditions, early session
disposition etc.) in which, following conclusion of the original
offer-answer exchange when the answer is sent in a reliable provisional
response, further offer-answer exchanges can occur (using PRACK or
UPDATE). These can occur before the 200 response to INVITE. Thus
repeating the original SDP answer in the 200 response to INVITE is
history - it has been overtaken by subsequent offers and answers. At
best it will be ignored, but at worst it will lead to confusion, e.g.,
the UAC and UAS getting out of step with which SDP version from the UAS
is to be used. And why should the UAS even have to store the original
SDP answer it sent, if it has been overtaken by subsequent SDPs?

Of course, one can question the wisdom behind some of these mechanisms,
some of which have not seen much deployment. But they are there, and
unless we deprecate them, we change the offer-answer rules at our peril.

John

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 22 November 2007 05:21
> To: Robert Sparks
> Cc: Sanjay Sinha (sanjsinh); sip List; Paul Kyzivat

---

From: Robert Sparks <[email-masked]>
Date: Thu, 22 Nov 2007 02:25:16 -0600

I'm still not sure what you originally objected to. Just to be point  
out that the UPDATE can come from either side, I'm copying figure 1  
from the UPDATE RFC here.

Tell me what SDP you think is safe to put in message 9.
I _think_ you're saying it should be answer 1 from message 2. How  
could that help anybody? The session described by offer1/answer1 is  
long long gone.
If you repeat offer 3 from message 7, again - how could that help  
anybody?

I'll accept that you don't like the whole idea of early dialogs and  
early media. But that cat's so far out of the bag its forgotten what  
the bag smells like.
Given that this stuff is now _deployed_, what's the best answer to my  
original question?

What Paul points out causes me to champion making a much clearer MUST  
NOT put SDP in the 200-INVITE if you're using 100-rel.

And my questions about how the repeat of either of those SDPs is  
earnest, not rhetorical. I really don't see how its helping something  
work.
Can you diagram the scenario where not repeating the SDP you want to  
repeat leads to abject failure?

RjS

                 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               |
                    |<----------------------------|
                    |                             |
                    |                             |
                    |(10) ACK                     |
                    |---------------------------->|
                    |                             |
                    |                             |
                    |                             |
                    |                             |

                      Figure 1: UPDATE Call Flow

On Nov 21, 2007, at 11:20 PM, Dean Willis wrote:

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

---

From: Dean Willis <[email-masked]>
Date: Thu, 22 Nov 2007 11:33:28 -0600

On Nov 22, 2007, at 2:25 AM, Robert Sparks wrote:

> I'm still not sure what you originally objected to. Just to be  
> point out that the UPDATE can come from either side, I'm copying  
> figure 1 from the UPDATE RFC here.
>

Either the SDP from message 2 (the answer that corresponds to the  
offer from INVITE), or nothing. No other SDP can go there.

> could that help anybody? The session described by offer1/answer1 is  

It's not particularly useful, though it might have been had the  
UPDATE sequence not occurred. And for those UAs that neither  
implement answer-in-provisional nor UPDATE, it will at least result  
in a working call.

> If you repeat offer 3 from message 7, again - how could that help  

That would be a state mismatch, so don't do it.
> early media. But that cat's so far out of the bag its forgotten  
> what the bag smells like.
> Given that this stuff is now _deployed_, what's the best answer to  
> my original question?
>

Either the final answer has to match the provisional answer, or it  
has to contain nothing. There are cases of not-quite-right UAs where  
either will cause disaster. It's a probability game.

> What Paul points out causes me to champion making a much clearer  
> MUST NOT put SDP in the 200-INVITE if you're using 100-rel.
>
> earnest, not rhetorical. I really don't see how its helping  
> something work.
> Can you diagram the scenario where not repeating the SDP you want  
> to repeat leads to abject failure?
>

It is not uncommon for older UAs to completely ignore SDP in a  
provisional response. I think both the SIP phones at my house do this  
(although one also doesn't do reliable provisional at all, but I'm  
not sure it rejects the 180 correctly).

if we skip the SDP in 4, Caller thinks he has never received an answer:

                 Caller                        Callee
                    |                             |
                    |                             |
                    |(1) INVITE with offer 1      |
                    |---------------------------->|
                    |                             |
                    |                             |
                    |(2) 180 with answer 1        |
                    |<----------------------------|
         ans.       |                             |
         ignored    |                             |
                    |(3) PRACK                    |
                    |---------------------------->|
                    |                             |
                    |                             |
                    |                             |
                    |(4) 200 INVITE with ans 1    |
                    |<----------------------------|
                    |                             |
                    |                             |
                    |(5) ACK                     |
                    |---------------------------->|
                    |                             |
                    |                             |
                    |                             |
                    |                             |

---

From: Dean Willis <[email-masked]>
Date: Thu, 22 Nov 2007 11:33:28 -0600

Caller                        Callee
                    |                             |
                    |                             |

---

From: Robert Sparks <[email-masked]>
Date: Thu, 22 Nov 2007 12:31:37 -0600

I disbelieve that there are any UAs that claim support for 100rel and  
don't pay attention to the answer in the 180.
Please show me one (send me traces please).

Are you mixing the non-reliable 18x case in here? (I think that might  
be where you're coming from since you say "older" UAs).'
That's not what we're discussing. Repeating the answer in the 200  
here makes sense.

And what do you mean "rejects the 180"? That makes no sense.

Do you have a UAS that's tries to send 100rel responses when the UA  
hasn't indicated support?

RjS

On Nov 22, 2007, at 11:33 AM, Dean Willis wrote:

>> could that help anybody? The session described by offer1/answer1  
>> is long long gone.
>
>> I'll accept that you don't like the whole idea of early dialogs  
>> and early media. But that cat's so far out of the bag its  
>> forgotten what the bag smells like.
> has to contain nothing. There are cases of not-quite-right UAs  
> where either will cause disaster. It's a probability game.
>
> provisional response. I think both the SIP phones at my house do  
> this (although one also doesn't do reliable provisional at all, but  
> I'm not sure it rejects the 180 correctly).
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 23 Nov 2007 19:26:39 -0600

On Nov 22, 2007, at 12:31 PM, Robert Sparks wrote:

> I disbelieve that there are any UAs that claim support for 100rel  
> and don't pay attention to the answer in the 180.

I believe I have some that also ignore the 100-rel, neither sending a  
prack nor paying attention to the answer.

> Are you mixing the non-reliable 18x case in here? (I think that  
> might be where you're coming from since you say "older" UAs).'

For some really old UAs, this is the same use case.
> And what do you mean "rejects the 180"? That makes no sense.

Some nodes will treat an SDP-bearing 183 as a non-SDP-bearing 180.  
Others will just ignore the whole response.

> hasn't indicated support?

Ah now, that's a better question. I don't have such a thing, but I  
wouldn't be surprised if it happened.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Nov 2007 21:46:26 -0500

Dean,

So are you saying the ignores the Require:100rel in the response and 
then fails to send the PRACK?

And then the UAS is supposed to not mind that it isn't getting the PRACK???

This is *so* broken that we shouldn't even be discussing it.

	Paul

Dean Willis wrote:
>> That's not what we're discussing. Repeating the answer in the 200 here 
>> makes sense.
>