Re: [asterisk-users] How to check if a SIP phone isforwardedwithout ringing it ?
Section 11.2 of RFC 3261 details the "Processing of OPTIONS Request"
The response to an OPTIONS is constructed using the standard rules
for a SIP response as discussed in Section 8.2.6. The response code
chosen MUST be the same that would have been chosen had the request
been an INVITE. That is, a 200 (OK) would be returned if the UAS is
ready to accept a call, a 486 (Busy Here) would be returned if the
UAS is busy, etc. This allows an OPTIONS request to be used to
determine the basic state of a UAS, which can be an indication of
whether the UAS will accept an INVITE request.
Section 21.3.3 of RFC3261 details the "302 Moved Temporarily" response
code.
Looks to me like those two things should interwork just fine.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Olivier
Sent: 08 January 2008 14:32
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] How to check if a SIP phone
isforwardedwithout ringing it ?
2008/1/8, Steve Langstaff <[EMAIL PROTECTED]>:
That's going to be pretty phone-specific. How about
asking your phone supplier to fix their phone so that it responds to
OPTIONS correctly?
Yes, you're right but RFC3261 doesn't specify such 302 replies.
So I'm very pessimistic about my phone supplier answer.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Olivier
Sent: 08 January 2008 12:50
To: Asterisk Users Mailing List - Non-Commercial
Discussion
Subject: Re: [asterisk-users] How to check if a
SIP phone is forwardedwithout ringing it ?
2008/1/7, Kevin P. Fleming
<[EMAIL PROTECTED]>:
Olivier wrote:
> Is there way for an Asterisk server to
check if a sip phone is forwarded
> without bothering phone's user ?
No.
> I was thinking of some Alert-Info
option that would let the phone reply
> with a 302 Moved Temporarily or 182
Queued message and not let the phone
> ring or display anything on its
screen.
According to the SIP RFC, a SIP endpoint
is supposed to respond to an
OPTIONS message the same way that it
would respond to an INVITE message
with the identical destination, but I've
never seen a phone respond to
an OPTIONS message with anything but
'200 OK', even when a redirect
(forward) is in place.
So, the alternative option is to play with html
and use phone embedded html server to get this redirection data.
Cheers
--
Kevin P. Fleming
Director of Software Technologies
Digium, Inc. - "The Genuine Asterisk
Experience" (TM)
___
--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
Re: [asterisk-users] How to check if a SIP phone isforwardedwithout ringing it ?
> -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. ___ -- 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
Re: [asterisk-users] How to check if a SIP phone isforwardedwithout ringing it ?
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
Re: [asterisk-users] How to check if a SIP phone isforwardedwithout ringing it ?
There is something called as answer-mode in SIP. The idea is to allow the UAC to request the UAS to auto-answer the call. At least in theory, this could be used to check the status of the phone without ringing it. This is obviously not an ideal replacement of OPTIONS. Also, this is a new spec so I'm not sure how many phone vendors support it yet: http://www.ietf.org/internet-drafts/draft-ietf-sip-answermode-06.txt -- Raj From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Sent: Wednesday, January 09, 2008 1:47 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] How to check if a SIP phone isforwardedwithout ringing it ? As using OPTIONS requests main benefit is to non-phone specific, what shall we do when most vendors do not comply with RFC ? 2008/1/9, Raj Jain <[EMAIL PROTECTED] >: 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. Can we ask the phone vendors to play by the book? -- Raj From: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Sent: Tuesday, January 08, 2008 7:50 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] How to check if a SIP phone is forwardedwithout ringing it ? 2008/1/7, Kevin P. Fleming <[EMAIL PROTECTED]>: Olivier wrote: > Is there way for an Asterisk server to check if a sip phone is forwarded > without bothering phone's user ? No. > I was thinking of some Alert-Info option that would let the phone reply > with a 302 Moved Temporarily or 182 Queued message and not let the phone > ring or display anything on its screen. According to the SIP RFC, a SIP endpoint is supposed to respond to an OPTIONS message the same way that it would respond to an INVITE message with the identical destination, but I've never seen a phone respond to an OPTIONS message with anything but '200 OK', even when a redirect (forward) is in place. So, the alternative option is to play with html and use phone embedded html server to get this redirection data. Cheers -- Kevin P. Fleming Director of Software Technologies Digium, Inc. - "The Genuine Asterisk Experience" (TM) ___ -- 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
Re: [asterisk-users] How to check if a SIP phone isforwardedwithout ringing 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... Where's my eggs? /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
