> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Johansson Olle E > Sent: 09 January 2008 14:11 > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [asterisk-users] How to check if a SIP phone > isforwardedwithoutringing it ? > > > 9 jan 2008 kl. 10.46 skrev Steve Langstaff: > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of > >> Johansson Olle E > >> Sent: 09 January 2008 06:50 > >> 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." > > > > It looks like there are two issues rolled into one here... > > > > I hope I'm not "teaching my grandmother to suck eggs" when > telling you > > this, Olle, but as I understand it, Asterisk sending OPTIONS to > > devices as a NAT keepalive is a separate issue from devices sending > > OPTIONS to asterisk as a capabilities check... > > > > Received OPTIONS messages should/must be handled as-per the > RFCs (so > > authentication, matching etc should be done). > > > > If Asterisk wants to send an OPTIONS message just to keep a NAT > > binding open then I don't think that it has any obligation > to include > > authentication headers if it receives a 401/407 response - it has > > received *some* response, and that's enough. > > > > If Asterisk wants to send an OPTIONS message to discover peer state > > (e.g. > > call forward enabled) then obviously it will have to complete any > > 401/407 > > handling. > > > > So instead of needing > > "a header to the OPTIONs packet saying "this is just a > keep-alive"" > > I think that maybe Asterisk needs to control how it uses OPTIONS, > > depending on purpose. > > The issue here is that it requires a lot of extra processing > when RECEIVING the OPTION message if we want to do it right. > Sending is not an issue. > > If we want to handle OPTIONs correctly we need to match with > the peer/ user list and then set up a complete dialog with > all the options from the peer/user and then reply...
Right. I agree that RECEIVING an OPTION message on the Asterisk server may require a lot of extra processing. I agree that sending an OPTION message from the Asterisk server could well have a low processing load. The original poster wanted to use OPTIONS sent FROM the Asterisk server to query the phone state, so I don't think your concerns about receive processing come into the picture. _______________________________________________ -- 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
