Christer Holmberg <christer.holmberg@xxxxxxxxxxxx> 写于 2010-04-16 15:00:43:
>
> Hi,
>
> > I think you need to separate things.
> >
> > Since the SDP in the unreliable and reliable responses shall be the
> > same, the UAC should not have to look at the SDP in the reliable
> > response, if it is already "using" the SDP from an unreliable answer.
> >
> > However, even if the UAC is using the SDP from an unreliable
> > response, the UAC can not initiate a new offer/answer transaction
> > before it has received the reliable response, because the reliable
> > response terminates the offer/answer transaction.
> >
> >[Gao] I know it well.
> >But RFC3261 said UAC MUST treat the SDP(which we think should not
> be the ANSWER, at most treat it as if answer) as answer.
> >
> >During interworking testing, the other side's people said it is
> answer, then it(the UAC) has finished it's Ini-O/A, what's
> normative text can you use to convince them?
>
> You tell them that an offer/answer transaction is not finished until
> the answer has been delivered reliably.
>
> >So, first we should correct RFC3261 clearly that the SDP in
> unreliable response is not ANSWER, even it is the first SDP UAC got.
>
> 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.
>
> >Until finishing of the correction, we *MAY* do BCP thing on the
> handling of such SDP. And about BCP, I think there still are two alternative:
> >1. as O/A draft says, such SDP MUST be the same as the subsequent
> real answer. And UAC MUST using it AS IF answer.
>
> Since it has to be the same, it doesn't really matter which the UAC
> uses. But still, the offer/answer transaction is not finished until
> the SDP has been received reliably.
>
> >2. Do not do such MUST/MUST NOT restrict, just let UAC's free to
> handle the SDP. If the UAC use it, OK; just ignore it, also OK. But
> the UAC MUST handle the real ANSWER as answer.
>
> I am not really sure what you mean, but I am the first one to agree
> that offer/answer, and usage of SDP in SIP, is a big mess. We use
> SIP message to carry SDP, mix together session control and media
> control, but there is not always a one-to-one mapping between SIP
> transactions and offer/answer exchanges, and therefor we need to
> define rules on what you can insert where, etc.
>
> Regards,
>
> Christer
>
>
> >
> > So, just because the UAC is using an SDP from an unrelaible
> > response, it doesn't mean that the offer/answer transaction is finished.
> >
> > Regards,
> >
> > Christer
> >
> > From: gao.yang2@xxxxxxxxxx [mailto:gao.yang2@xxxxxxxxxx]
> > Sent: 16. huhtikuuta 2010 8:49
> > To: Christer Holmberg
> > Cc: Paul Kyzivat; sipping@xxxxxxxx
> > Subject: 答复: RE: [Sipping] About offeranswer draft:
>
> >
> > Please see http://www.ietf.org/mail-
> archive/web/sipping/current/msg17552.html
> >
> > ===================================
> > Zip : 210012
> > Tel : 87211
> > Tel2 :(+86)-025-52877211
> > e_mail : gao.yang2@xxxxxxxxxx
> > ===================================
> >
>
>
>
> --------------------------------------------------------
> 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.
>
>
-------------------------------------------------------- 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
