Hello Pekka, Firstly, RFC2543 is somewhat obsolete since it has been replaced by RFC3261.
But whatever SIP RFC you wish to use, I would recommend: 1. use the way in RFC3264 since this is newer. The sendonly, recvonly, inactive attributes give a little more control than the old "0.0.0.0" method. But also: 2. If someone sends you a re-INVITE with "0.0.0.0" try to accept it as described in RFC2543 so that you are backward-compatible with implementations that use it. 3. When putting someone on hold by sending a=sendonly or a=inactive, then also use the "0.0.0.0". This way, if the implementation doesn't understand the sendonly or inactive, it will still stop sending you media. If you adhere to the above, you should be able to maximise your interoperability. Regards, Attila Attila Sipos Software Engineer www.vegastream.com Let's talk Business, Let's talk VoIP > -----Original Message----- > From: Pekka Pessi [mailto:[EMAIL PROTECTED] > Sent: 09 December 2003 10:48 > To: Andreas Bystr�m > Cc: Sip Implemators > Subject: Re: [Sip-implementors] Call hold questions > > > "Andreas Bystr�m" <[EMAIL PROTECTED]> writes: > >I'm a bit confused regarding Call Hold service using SIP. I > have seen two > >differnet approaches to solve this: > > >1. Send a re-Invite with "0.0.0.0" as the IP address in the sdp data > > This is the way recommended in RFC 2543 (Appendix B.5) > > >2. Send a re-Invite with the parameter a=sendonly set in the sdp data > > This is the way recommended in RFC 3264 (section 8.4), which > obsoletes RFC 2543. > > >Is there some draft or RFC about this? Which one is > preferred? I guess it is > >best to have support for both ways (at least receiveng call > hold) but when I > >send the call hold I need to know which way to use. > > >Do you see any pros/cons about the two different solutions? > > In one hand a=sendonly is the way recommended by current RFC. On > the one hand, you can use the fingers of that hand to count > implementations that support a=sendonly. If you use 0.0.0.0, the > recipient can not send RTCP to you (if you, for instance, send > muzak to keep the held person on line). > > Pekka > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
