As far as I am concerned we are NOT writing these things into offer answer offer answer is meant to be a general clarification of what exists at the moment. The statements you are proposing update RFC 3264 and need to be in a candidate standards track RFC that does that. regards Keith > -----Original Message----- > From: sipping-bounces@xxxxxxxx > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of OKUMURA Shinji > Sent: Wednesday, April 14, 2010 8:32 AM > To: sipping@xxxxxxxx > Subject: Re: [Sipping] About offeranswer draft: > > 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. > > >> 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 > _______________________________________________ > 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
