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:


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.

Tell me what SDP you think is safe to put in message 9.

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

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.

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

That would be a state mismatch, so don't do it.

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?


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.

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?


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



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

Reply via email to