sipping-bounces@xxxxxxxx 写于 2010-04-15 04:38:21:
> Hi,
>
> >> In your chart SDP4 is a reliable answer. Therefore SDP5 might be
> >> interpreted as a new offer, hence UAC could send an answer in PRACK.
> >> Quite similarly to 3PCC cases, where 200 contains the offer and ACK the
> >> answer.
> >
> >That has been investigated. Its not allowed. (Unfortunately I cannot
> >recall the chain of reasoning that derived its illegality - it wasn't
> >obvious but it was sound. It was worked out a *long* time ago.)
>
> The rule we have agreed to is very simple: at most one offer/answer
> exchange per SIP transaction.
Yes, it is. And what I talked here is also under this basic rule.
>
> 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.
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.
Why I think this should be clarified, is that during interworking testing, we should know which side is reasonable.
Thanks,
Gao
>
> Regards,
>
> Christer
>
>
>
>
> > ------------------------------------------------------------------------
> > *From:* sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] *On
> > Behalf Of *ext gao.yang2@xxxxxxxxxx
> > *Sent:* Wednesday, April 14, 2010 11:19
> > *To:* OKUMURA Shinji
> > *Cc:* sipping-bounces@xxxxxxxx; sipping@xxxxxxxx
> > *Subject:* [Sipping] 答复: Re: About offeranswer draft:
> >
> >
> > Hi Shinji,
> >
> >
> > sipping-bounces@xxxxxxxx 写于 2010-04-14 15:31:54:
> >
> > > Hi Gao,
> > >
> > > gao.yang2@xxxxxxxxxx
> > > Wed, 14 Apr 2010 12:21:45 +0800
> > > >sipping-bounces@xxxxxxxx 写于 2010-04-14 11:17:23:
> > > >
> > > >> Hi Gao,
> > > >>
> > > >> In the following case,
> > > >>
> > > >> UAC UAS
> > > >> | F1 INVITE (SDP1) | <-- offer
> > > >> |-------------------->|
> > > >> | F2 1xx (SDP2) |
> > > >> |<--------------------|
> > > >> | F3 1xx (SDP3) |
> > > >> |<--------------------|
> > > >> | F4 1xx-rel (SDP4) | <-- answer
> > > >> |<--------------------|
> > > >> | F5 1xx-rel (SDP5) |
> > > >> |<--------------------|
> > > >> | F6 1xxl (SDP6) |
> > > >> |<--------------------|
> > > >> | F7 2xx INV(SDP7) |
> > > >> |<--------------------|
> > > >> | F8 ACK |
> > > >> |-------------------->|
> > > >> (PRACK transactions are not shown)
> > > >>
> > > >> I tried to arrange the rules.
> > > >> (small letters mean informational)
> > > >>
> > > >> UAC,
> > > >> (Rc1) MUST treat SDP2 as the answer.
> > > >> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> > > >> (Rc3) may treat SDP3 as the answer.
> > > >
> > > >[Gao] OK
> > > >
> > > >> (Rc4) should treat SDP4 as the answer and confirm the current O/A
> > > >> status by sending new offer.
> > > >
> > > >[Gao] support of this, though this may be modification of current
> > RFC3261.
> > >
> > > You will probably think of the following statements,
> > > RFC3261/13.2.1 Creating the Initial INVITE
> > > (snip) "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."
> > >
> > > No doubt this is one of the cussword built in this document.
> > > It is a personal interpretation of mine,
> > > "as the answer" is associated with not "treat" but "receives",
> > > and "treat" means "not ignore".
> > >
> > > Just putting that aside for now, I think there is a consensus that
> > > Rc4 does not need a modification of current RFC3261.
> >
> > I see. But if there's memo of such consensus, it would be quite useful
> > in interworking testing.
> >
> > >
> > > >> UAS,
> > > >> (Rs1) should not send SDP5, SDP6 and SDP7.
> > > >> (Rs2) must not send SDP2 and SDP3 if these are not the same as SDP4.
> > > >>
> > > >> Rc3 and Rc4 are new added descriptions.
> > > >> Rs1 and Rs2 are current descriptions in this draft.
> > > >>
> > > >> I think "MUST NOT" is suitable for (Rs1).
> > > >> Because RFC3261 says
> > > >> Once the UAS has sent or received an answer to the initial
> > > >> offer, it MUST NOT generate subsequent offers in any responses
> > > >> to the initial INVITE. This means that a UAS based on this
> > > >> specification alone can never generate subsequent offers until
> > > >> completion of the initial transaction.
> > > >>
> > > >
> > > >[Gao] Yes.
> > > >
> > > >> SDP5 and SDP7 are regarded as "subsequent offers".
> > > >
> > > >[Gao] as "MUST NOT" is suitable for (Rs1), so there must be no
> > "subsequent
> > > >offers" in subsequent response.
> > >
> > > Certainly UAC MUST ignore SDPs no matter what these are.
> > >
> > > Regards,
> > > Shinji
> >
> > --------------------------------------------------------
> > 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
> _______________________________________________
> 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
-------------------------------------------------------- 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
