Attila Sipos <[EMAIL PROTECTED]> writes:
>Firstly, RFC2543 is somewhat obsolete since it has been replaced by
>RFC3261.
As I mentioned, RFC 3264 is one of the documents (3261, 3263,
3264) that obsoleted RFC 2543.
>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.
I'd recommend that first re-INVITE with a=sendonly/inactive,
then see if the SDP answer contains a=recvonly/inactive. If
there is no such attribute, then try to use 0.0.0.0 in another
re-INVITE.
>If you adhere to the above, you should be able
>to maximise your interoperability.
Not really. The RTCP does not work with your proposal. Getting
RTCP to work is the point of a=sendonly/inactive exercise.
Pekka
>> -----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
