After several people hitting on us, we will automatically detect if the other party supports RFC3264. We will do this by searching for a=sendrecv, a=sendonly etc. If we don�t find it, we will fall back to using 0.0.0.0 as hold address. On the other side, we will NOT omit a=sendrecv, so that the other party has the chance to do the same detection algorithm.
It seems to be not only an issue for Asterisk, also other equipment has problems (transfer seems to fail on Cisco 3620 IOS-12.x gateway because it thinks it is not on hold). Maybe someone can write an update to RFC3264 (change in � 5.1: "it MAY include an 'a=sendrecv' attribute, or it MAY omit it, since sendrecv is the default" -> "it MUST include an "a=sendrecv" attribute)". Christian > -----Urspr�ngliche Nachricht----- > Von: [EMAIL PROTECTED] [mailto:sip-implementors- > [EMAIL PROTECTED] Im Auftrag von Paul Kyzivat > Gesendet: Dienstag, 9. Dezember 2003 15:27 > An: Attila Sipos > Cc: 'Pekka Pessi'; r�m; Andreas Byst; Sip Implemators > Betreff: Re: [Sip-implementors] Call hold questions > > > > Attila Sipos wrote: > > > > 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. > > If you use "0.0.0.0", then there is no point to using a=sendonly. The > purpose of a=sendonly is so that the RTCP stream can still remain > active, but if you put "0.0.0.0" in the c= line then you can't do that. > > If you want to reap the benefits of the new approach and yet still > remain backwards compatible, then I think you must try the new way, and > then retry the old way if the first attempt fails. > > Perhaps we should have specified that a=sendrecv SHOULD be explicitly > specified by default, so that it could be used as a hint that the > endpoint that used it is also capable of understanding > a=sendonly/recvonly/inactive. > > But I suppose that wouldn't have been foolproof either. I have seen UAs > that fail on a= lines they don't understand. > > Paul > > _______________________________________________ > 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
