<br><br><div><span class="gmail_quote">2008/1/9, Steve Langstaff <<a href="mailto:steve.langstaff@citel.com">steve.langstaff@citel.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> -----Original Message-----<br>> From: <a href="mailto:asterisk-users-bounces@lists.digium.com">asterisk-users-bounces@lists.digium.com</a><br>> [mailto:<a href="mailto:asterisk-users-bounces@lists.digium.com">asterisk-users-bounces@lists.digium.com
</a>] On Behalf Of<br>> Johansson Olle E<br>> Sent: 09 January 2008 14:11<br>> To: Asterisk Users Mailing List - Non-Commercial Discussion<br>> Subject: Re: [asterisk-users] How to check if a SIP phone<br>> isforwardedwithoutringing it ?
<br>><br>><br>> 9 jan 2008 kl. 10.46 skrev Steve Langstaff:<br>><br>> >> -----Original Message-----<br>> >> From: <a href="mailto:asterisk-users-bounces@lists.digium.com">asterisk-users-bounces@lists.digium.com
</a><br>> >> [mailto:<a href="mailto:asterisk-users-bounces@lists.digium.com">asterisk-users-bounces@lists.digium.com</a>] On Behalf Of<br>> >> Johansson Olle E<br>> >> Sent: 09 January 2008 06:50
<br>> >> To: Asterisk Users Mailing List - Non-Commercial Discussion<br>> >> Subject: Re: [asterisk-users] How to check if a SIP phone<br>> >> isforwardedwithout ringing it ?<br>> >><br>
> >><br>> >> 9 jan 2008 kl. 02.48 skrev Raj Jain:<br>> >><br>> >>> This issue of phone vendors not supporting OPTIONS<br>> according to RFC<br>> >>> 3261<br>> >>> often comes up on this list. Like Kevin Fleming said, an OPTIONS
<br>> >>> request is supposed to be responded in the same way as an INVITE.<br>> >>> Almost all SIP phone vendors have construed OPTIONS as some<br>> >> kind of a<br>> >>> keep-alive request, which is wrong.
<br>> >> Which we do too, by the way. In worst case, maybe Asterisk has set<br>> >> this industry standard.<br>> >><br>> >> OPTIONS is far to heavy in processing on the server side<br>> to be used
<br>> >> for keep-alives. I'm starting to see devices that use it for<br>> >> checking capabilities - the proper way. To do this<br>> properly, we will<br>> >> have to authenticate the OPTIONs request and match it with
<br>> the proper<br>> >> peer/ user to get the proper codec settings, ACLs and such.<br>> >><br>> >> Since all versions of Asterisk use OPTIONs for<br>> NAT-keepalives, I'm a<br>> >> bit hesitant to fix this. It's a catch 22. I want to do it
<br>> properly,<br>> >> but then the amount of processing for each OPTIONs request that we<br>> >> receive is going to be a bit too much. Maybe one could ask<br>> vendors to<br>> >> add a header to the OPTIONs packet saying "this is just a
<br>> >> keep-alive.<br>> >> Give me a 200 OK without any parsing and be happy, because I don't<br>> >> care about the reply."<br>> ><br>> > It looks like there are two issues rolled into one here...
<br>> ><br>> > I hope I'm not "teaching my grandmother to suck eggs" when<br>> telling you<br>> > this, Olle, but as I understand it, Asterisk sending OPTIONS to<br>> > devices as a NAT keepalive is a separate issue from devices sending
<br>> > OPTIONS to asterisk as a capabilities check...<br>> ><br>> > Received OPTIONS messages should/must be handled as-per the<br>> RFCs (so<br>> > authentication, matching etc should be done).
<br>> ><br>> > If Asterisk wants to send an OPTIONS message just to keep a NAT<br>> > binding open then I don't think that it has any obligation<br>> to include<br>> > authentication headers if it receives a 401/407 response - it has
<br>> > received *some* response, and that's enough.<br>> ><br>> > If Asterisk wants to send an OPTIONS message to discover peer state<br>> > (e.g.<br>> > call forward enabled) then obviously it will have to complete any
<br>> > 401/407<br>> > handling.<br>> ><br>> > So instead of needing<br>> > "a header to the OPTIONs packet saying "this is just a<br>> keep-alive""<br>> > I think that maybe Asterisk needs to control how it uses OPTIONS,
<br>> > depending on purpose.<br>><br>> The issue here is that it requires a lot of extra processing<br>> when RECEIVING the OPTION message if we want to do it right.<br>> Sending is not an issue.<br>>
<br>> If we want to handle OPTIONs correctly we need to match with<br>> the peer/ user list and then set up a complete dialog with<br>> all the options from the peer/user and then reply...<br><br>Right.<br><br>I agree that RECEIVING an OPTION message on the Asterisk server may
<br>require a lot of extra processing.<br><br>I agree that sending an OPTION message from the Asterisk server could<br>well have a low processing load.<br><br>The original poster wanted to use OPTIONS sent FROM the Asterisk server
<br>to query the phone state, so I don't think your concerns about receive<br>processing come into the picture.</blockquote><div><br>Yes, obviously, there are 2 different issues :<br>1. how to query phone status<br>
2. how to keep NAT alives<br><br>A. For phone status queries, a list of phone vendors (at least one) supporting this usage or future SIPit tests would help to motivate other vendors to implement desired SIP OPTIONS behaviour along today's one.
<br>Maybe an email sent by Digium to a list of SIP phone vendors and asking for guidance would be a practical mean to get replies.<br><br>B. As keeping NAT alive is a basic need, maybe we should ask SIP PING method authors or sponsors for advice on this (contact address in enclosed in
<a href="http://www.cornfed.com/ping.html">http://www.cornfed.com/ping.html</a> ) ?<br>Either SIP PING (or something equivalent) should be ratified or SIP OPTIONS should be "clarified".<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
_______________________________________________<br>-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com">http://www.api-digital.com</a> --<br><br>asterisk-users mailing list<br>To UNSUBSCRIBE or update options visit:
<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br></blockquote></div><br>