SL> The actual text from RFC 3264 says: SL> RFC 2543 [10] specified that placing a user on hold was accomplished SL> by setting the connection address to 0.0.0.0. Its usage for putting SL> a call on hold is no longer recommended, since it doesn't allow for SL> RTCP to be used with held streams, doesn't work with IPv6, and breaks SL> with connection oriented media. SL> SL> Nothing in there about "uni-directional pausing of media streams", as I SL> read it.
RJ> Okay, so the RFC 3264 text doesn't spell it out, but does that make it not an advantage? RJ> The SIP Service Examples draft talks about unidirectional nature of hold, for instance: RJ> http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples- 12.txt You originally said "c=0.0.0.0 does not allow uni-directional pausing of media streams". The service example says: Note that hold is unidirectional in nature. However, a UA that places the other party on hold will generally also stop sending media, resulting in no media exchange between the UAs. Older UAs may set the connection address to 0.0.0.0 when initiating hold. However, this behavior has been deprecated in favor of using the a=sendonly SDP attribute. If one party has put the call on hold by specifying c=0.0.0.0, though "generally" it will "also stop sending media" (at least according to the service examples) it is still at liberty to stream media to the other party - isn't that an example of "uni-directional pausing of media streams"? But hey, let's not waste cycles arguing over deprecated behaviour. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
