Hi Paul,
I also attempted to do the same search. Thanks for your exposure.
By the finding, we CAN say that the problem is not a urgent one, as such implementation is not lawful.
But as I said in one previous mail, permissibility of sending another Offer is signalling relating issue. So, whether it is the mark of "finishing of the ini-O/A transaction" is still not clear. But it has been downgraded as pure academic issue now(by your finding, there's no engineering issue nowadays).
Thanks,
Gao
Paul Kyzivat <pkyzivat@xxxxxxxxx> 写于 2010-04-19 22:26:37:
>
>
> Paul Kyzivat wrote:
>
> > 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.
> >
> > 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.
>
> I have now found the contradiction I was looking for:
>
> If the UAC thought that receipt of the unreliable response with SDP
> meant it could now send another offer, in what message could it send
> that offer? The only messages where it could include an offer are:
>
> - an INVITE. But it is forbidden from sending another INVITE until
> the current INVITE transaction is complete.
>
> - an UPDATE. But RFC 3311 says
>
> o If the UPDATE is being sent before completion of the initial
> INVITE transaction, and the initial INVITE contained an offer,
> the UPDATE can contain an offer if the callee generated an
> answer in a reliable provisional response, and the caller has
> received answers to any other offers it sent in either PRACK or
> UPDATE, and has generated answers for any offers it received in
> an UPDATE from the callee.
>
> (note that this language itself is non-normative and is justified as
> a corollary of 3261.)
>
> This rules out sending the new offer in an UPDATE.
>
> - a PRACK. But a PRACK can only be sent in response to a reliable
> provisional. The assumption here is that the answer has not been sent
> in a reliable provisional yet. So the PRACK would only be an option
> if a reliable provisional *without* SDP was sent after sending an
> answer in an unreliable provisional. This is a very weird case.
>
> - in a response. But the only case where an offer is permitted in a
> response is in the response to INVITE, which isn't a possibility here.
>
> I think the above is enough to debunk this interpretation.
>
> Thanks,
> Paul
>
>
-------------------------------------------------------- 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
