Inline. gao.yang2@xxxxxxxxxx wrote: > > > Paul Kyzivat <pkyzivat@xxxxxxxxx> 写于 2010-04-14 22:23:57: > > > inline > > > > gao.yang2@xxxxxxxxxx wrote: > > > > > > Hi Shinji, > > > > > > Please see inlines. > > > > > > Thanks, > > > > > > Gao > > > > > > sipping-bounces@xxxxxxxx 写于 2010-04-12 10:55:47: > > > > > > > Hi Gao, > > > > > > > > The clarifications for the section 13.2.1 of RFC 3261 is > > > > one of the major purposes in this draft. > > > > > > > > In the section 3.1 of this draft, > > > > | 3.1. Offer/Answer for the INVITE method with 100rel extension > > > > | (snip) All the session > > > > | descriptions in the unreliable responses to the INVITE > request must > > > > | be identical to the answer which is included in the reliable > > > > | response. > > > > > > > > Do you doubt this clarification? > > > > In my understanding, this has already reached the consensus in WG. > > > > > > [Gao] I am not want to *challenge* the consensus we have reached in WG. > > > But as this draft is aims for clarification, not for normative > > > correction, I have no way to convince the *UAS*. > > > > (I just posted a related reply to a later message in this thread.) > > > > Whether this clarification is supported by the existing normative text > > is worthy of some careful thought. > > > > As I noted in the other reply, a UAS sending multiple *unreliable* > > responses with SDP must assume that some or all of them will be lost. If > > these SDPs have different values, and the UAC processes the first it > > receives, and ignores the rest, then the resulting behavior will be > > indeterminate. > > Yes. So, I think finally using the real answer in the first reliable > response can making the final session determinate. > But in your case, UAC would have a indeterminate early media, depending > on which SDP is the one it first receives. Yes, finally using the SDP in the first reliable response *would* make this case determinate. However, that has consequences - one of the following: - if the SDP from an unreliable response is used initially, and then a different SDP from a reliable response is received, there will be need to "switch" from the earlier to the later. This switching (and even parsing of the SDP) is extra cost that is unnecessary if the UAS behaves correctly and does not change the SDP. - the SDP from the unreliable responses might be ignored, so as to avoid the need to switch. Instead simply wait for the reliable response. For one, this is not permitted by the exiting text (though it can be achieved by pretending to lose the unreliable responses.) More important, this will delay the setup and use of the media streams. This can be unacceptable. All this is simply to provide determinacy for a non-conforming UAS. We usually don't specify behavior in non-conforming cases. Rather we leave it to implementations to decide. > > > > IMO this is sufficient to infer that there is only one meaningful > > interpretation, so that a clarification is sufficient without a > > normative change. > > I don't catch this point. Could you say it more. My point was that the interpretation that permits the UAS to send changed values of the SDP in unreliable provisionals and then the reliable response leads to indeterminacy. Its nonsensical to believe the spec intended to be indeterminate here. So the interpretation is not a valid one. Rather, it should be excluded, leaving only the interpretation that the UAS MUST send the same SDP in unreliable responses and the subsequent reliable response. But I have in another message confronted yet another interpretation you apparently obtained from someone you deal with. Lets cap off this thread here and pick it up in that one. Thanks, 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
