Olle, Yes, OPTIONS is too heavy for keep-alives and conflicts with its intended usage - capability discovery without actually placing a call. The IETF seems to be finally reaching a conclusion on how to do keep-alives in a lightweight fashion. These are described in the SIP-outbound draft:
http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-11.txt Basically, the idea is to use STUN for SIP/UDP and a CRLF packet for SIP/TCP. -- Raj > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Johansson Olle E > Sent: Wednesday, January 09, 2008 1:50 AM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [asterisk-users] How to check if a SIP phone > isforwardedwithout ringing it ? > > > 9 jan 2008 kl. 02.48 skrev Raj Jain: > > > This issue of phone vendors not supporting OPTIONS according to RFC > > 3261 > > often comes up on this list. Like Kevin Fleming said, an OPTIONS > > request is supposed to be responded in the same way as an INVITE. > > Almost all SIP phone vendors have construed OPTIONS as some > kind of a > > keep-alive request, which is wrong. > Which we do too, by the way. In worst case, maybe Asterisk > has set this industry standard. > > OPTIONS is far to heavy in processing on the server side to > be used for keep-alives. I'm starting to see devices that > use it for checking capabilities - the proper way. To do this > properly, we will have to authenticate the OPTIONs request > and match it with the proper peer/ user to get the proper > codec settings, ACLs and such. > > Since all versions of Asterisk use OPTIONs for > NAT-keepalives, I'm a bit hesitant to fix this. It's a catch > 22. I want to do it properly, but then the amount of > processing for each OPTIONs request that we receive is going > to be a bit too much. Maybe one could ask vendors to add a > header to the OPTIONs packet saying "this is just a keep-alive. > Give me a 200 OK without any parsing and be happy, because I > don't care about the reply." > > Linksys has a setting and use NOTIFY for Keep-alives, which > also is a poor solution, but at least something we can just > give an error response to without a lot of processing. There > was a proposal for PING, but it never got anywhere. > > /O > > _______________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
