| Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>
2010-04-16 01:16 |
|
Hi,
>>Whether it's clearly specified somewhere needs to be checked, though.
>>
>>I know there are implementations that "update" the SDP answer from
>>one reliable response to another (within the same transaction), for
>>the same transaction, but that is certainly nothing we have standardized.
>>
>I think it should be mentioned here, what is the *lawful* answer?
>It is the one in the first reliable response.
Agree. Whatever comes before that (unreliably), and after that (reliably OR unreliably),
has no meaning.
>>As it is the *lawful* answer, I think the UAC should using it when it
>>get the answer. And this seems *should* be made normative.
>>While how UAC handle SDP(from UAS) before the real answer, it can be BCP
>>issue.
>
>I think you are arguing that it is "lawful" for the UAS to send
>differing values for the SDP successive unreliable responses and in the
>subsequent reliable response. And that it is then the responsibility of
>the UAC to make this work "right" and "deterministically" by honoring
>the first and ignoring the subsequent ones. Is that right?
>
>But that makes no sense. The UAS cannot know if the UAC will receive the
>first, or any of, the unreliable responses. So if it were to do this odd
>behavior it must be satisfied that *any* of then are the one that the
>UAC uses. Or else it must be assuming that the UAC *might* use one or
>more of the unreliable ones, and eventually *switch* to the one in the
>reliable response.
>
>But 3261 is clear that the UAC should use the first one it receives, and
>ignore the remainder, *including* the reliable one. There is no
>provision for *switching*.
Agree.
I am aware of implementations that, once they have received a reliable SDP answer,
they don't even parse additional SDPs for the same transaction. So, they don't even
know whether the additional SDPs are identical or not.
[Gao] Yes.
But when the UAC have received the SDP in one unreliable response, could it ignore subsequent SDP, even the REAL ANSWER. By current RFC3261, it should ignore subsequent SDP, even the REAL ANSWER.
Now, we also have other signal rules on O/A, such as sending UPDATE after the ini-O/A. The key here is, IS the SDP (in unreliable before the real ANSWER) answer?
If it is answer, then signal rules on O/A need to be corrected.
If it is not answer, the RFC3261's text seems need correction.
As O/A draft does not aim for normative correction, so I just feel it seams need a normative one. I guess Paul has the prestige to draft such text:)
>Hence, its a corollary that the only behavior that the UAC can follow
>that is valid and consistent in the face of loss of unreliable responses
>is for them all to contain the same SDP. So that is the *lawful*
>behavior - a UAS that violates this is unreasonable.
Yes.
Regards,
Christer
-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________ 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
