Hi Christer, Brett, This bullet might mean what you say. Overall I can understand it. But reading the specs carefully, I'm confused a little. IMO The first statement in this bullet is not necessary, it is the cause of trouble more than the explanation. Lets get the discussion back to the 3rd bullet, I think it is necessary, but "should not" is better than "MUST NOT". Regards, Shinji Christer Holmberg <christer.holmberg@xxxxxxxxxxxx> Mon, 19 Apr 2010 13:55:26 +0200 >The text talks about generating additional offers, but not >about including a copy of previously sent ones. Brett Tate <brett@xxxxxxxxxxxxx> Mon, 19 Apr 2010 07:54:08 -0700 >Very little since from UAC perspective, the SDP MUST be ignored. >Thus if UAS places a modified SDP within a subsequent response, >it isn't an offer SDP or an updated answer SDP. >> I don't intend to be strongly particular about the last "MUST NOT". >> >> But RFC3261 say, >> o 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. >> >> What do the above statements forbid? _______________________________________________ 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
