Even if it does not happen soon for RFC3264, we can make sure that SIPForum can include this as a part of requirements document for SIP user agent...because anyway it is specfying hold behaviour for user agents.
Regards, Udit Paul Kyzivat <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 10/06/2005 08:51 AM To Roman Shpount <[EMAIL PROTECTED]> cc [email protected], Chris Whitaker <[EMAIL PROTECTED]>, [email protected], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject Re: [Sip] Re: Sip-implementors Digest, Vol 31, Issue 14 Roman, While I agree that 3264 could do with some cleanup, I doubt it will happen any time soon. Paul Roman Shpount wrote: > John, > > You wrote: > > >>RFC 3264 does indeed tell you to do that. In section 5.1 it states: >>"If the offerer wishes to communicate, but wishes to neither send nor >>receive media at this time, it MUST mark the stream with an "a=inactive" >>attribute." > > >>The problem is, this appears to be contradicted elsewhere. > > > The problem is in RFC 3264 section 8.4. It states: > "If the stream to be placed on hold was previously a sendrecv media > stream, it is placed on hold by marking it as sendonly." This sentence > is more often false then true and should not be considered normative. > > I think the original intent of this text was to say that that SDP with > c=0.0.0.0 corresponds to sendonly SDP and not inactive SDP. Since > SDP with c=0.0.0.0 used to be called hold SDP, sending an offer with such > SDP was normally called putting on hold. Hence the confusion. > > In generall, it would be a good idea to remove mentioning of term hold from > RFC 3264. Also, correspondence between SDP with c=0.0.0.0 and sendonly SDP > should be spelled out. This should not change anything in the meaning > of the RFC, but hopefully will end the hold confusion. > ___________________________________ > Roman Shpount, VP of Technology > aTelo, Inc. -- www.atelo.com > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [email protected] for questions on current sip > Use [email protected] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
