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