Inline...
On 4/16/2010 3:14 PM, Paul Kyzivat wrote:
I think we are now down to the essence of the question:
gao.yang2@xxxxxxxxxx wrote:
> Could you please show the text in 3261 which says that the SDP in an
> unreliable response is the SDP answer?
[Gao]: text from RFC3261:
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.
And, considering UAS send SDP in unreliable response before the answer,
then the SDP would be the *the first session*
* description it receives*.
RFC3261 using the word "AS THE ANSWER", not as if.
At this point, we are arguing about the *intent* of the text - it is
clearly confusing to some people.
And AFAIK we (me, Gao, Shinji, and Christer) are all in agreement that
the intent of the existing text is that:
- *if* the UAC receives SDP in an unreliable response before
receiving it in a reliable response, it MUST begin to use it
in the same way that it would use it if that SDP had been
received in a reliable response,
- but that it is not officially "the answer", and so it is not
yet permissible to initiate another o/a exchange until a reliable
response containing "the answer" is received.
- but when "the answer" is received, it MUST be ignored
(rather than "used") if an earlier SDP has already been
received and so "treated as the answer".
Are *we* all in agreement that this is the one and only *intended*
meaning of the text?
Then the issue is that *someone else* (who Gao has had occasion to do
interop testing with) is claiming that there is a different, yet
legitimate, interpretation of the exiting text. Namely:
- *if* the UAC receives SDP in an unreliable response before
receiving it in a reliable response, it MUST begin to use it
in the same way that it would use it if it had been received
in a reliable response,
- the UAC MUST (or SHOULD?) consider this SDP to be "the answer",
and hence it MAY send another offer, even before receiving
another copy of that answer SDP in a *reliable* response.
- still it MUST ignore SDP in subsequent responses to the
INVITE.
If so, then the question comes down to:
Is this alternate interpretation a valid and legitimate interpretation
of the existing text, or not?
I agree that this is a fair question to ask, and I am not yet settled on
an answer to it.
Sure, it's fair to ask but IMHO it's wrong. The second clause in your
first list above (saying SDP in an unreliable response is not the
"official" answer) is not just an opinion. 3261 says:
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.
Seems pretty clear: SDP in the unreliable response is to be *treated as*
the answer although (based on the first sentence) it isn't actually the
answer. Elsewhere it is said that the SDP can't change from unreliable
to reliable response so you could say that the unreliable SDP *might as
well* have been the answer. In my view that doesn't change the fact that
the official answer is the one in the first reliable response.
So I agree with "we" and I see no need for any fixes.
Thanks,
Anders
I am approaching this in the manner of a mathematical proof by
contradiction: If this alternative interpretation leads to some sort of
inconsistency, then it is not valid. If we can find no inconsistencies,
then it is a valid interpretation. And if it is, then the text is
ambiguous and will require normative changes to fix.
So, we can either seek out such an inconsistency, OR we can simply
concede that the text is ambiguous and begin work on a normative
correction to address it.
I'm pretty sure that we are going to reach the same endpoint either way.
So its a matter of whether we need a normative document to convince
everyone or not.
I'd appreciate feedback on my logic above.
Thank you,
Paul
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
