VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
| View previous topic :: View next topic |
| Author |
Message |
steve.langstaff at cit...
Guest
|
 Posted: Tue Jan 08, 2008 10:00 am Post subject: [asterisk-users] How to check if a SIP phone isforwardedwith |
 |
|
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: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] 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 <steve.langstaff at citel.com>:
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: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] 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
<kpfleming at digium.com>:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080108/da7dcda4/attachment.htm |
|
| Back to top |
|
 |
steve.langstaff at cit...
Guest
|
| Posted: Wed Jan 09, 2008 4:46 am Post subject: [asterisk-users] How to check if a SIP phone isforwardedwith |
|
|
| Quote: | -----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] 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:
| Quote: | 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
| Quote: | 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. |
|
| Back to top |
|
|
rj2807 at gmail.com
Guest
|
| Posted: Wed Jan 09, 2008 5:23 am Post subject: [asterisk-users] How to check if a SIP phone isforwardedwith |
|
|
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: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] 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 <rj2807 at gmail.com >:
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: asterisk-users-bounces at lists.digium.com
<mailto:asterisk-users-bounces at lists.digium.com>
[mailto:asterisk-users-bounces at lists.digium.com] 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 <kpfleming at digium.com>:
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 |
|
| Back to top |
|
|
rj2807 at gmail.com
Guest
|
| Posted: Wed Jan 09, 2008 5:35 am Post subject: [asterisk-users] How to check if a SIP phone isforwardedwith |
|
|
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
| Quote: | -----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] 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:
| Quote: | 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
| Quote: | 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 |
|
|
| Back to top |
|
|
oej at edvina.net
Guest
|
| Posted: Wed Jan 09, 2008 9:10 am Post subject: [asterisk-users] How to check if a SIP phone isforwardedwith |
|
|
9 jan 2008 kl. 10.46 skrev Steve Langstaff:
| Quote: | | Quote: | -----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] 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:
| Quote: | 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
| Quote: | 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 |
|
| Back to top |
|
|
steve.langstaff at cit...
Guest
|
| Posted: Wed Jan 09, 2008 9:44 am Post subject: [asterisk-users] How to check if a SIP phone isforwardedwith |
|
|
| Quote: | -----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] 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:
| Quote: | | Quote: | -----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] 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:
| Quote: | This issue of phone vendors not supporting OPTIONS
|
|
|
according to RFC
| Quote: | | Quote: | | Quote: | 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
| Quote: | 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
| Quote: | | Quote: | for keep-alives. I'm starting to see devices that use it for
checking capabilities - the proper way. To do this
|
|
properly, we will
| Quote: | | Quote: | have to authenticate the OPTIONs request and match it with
|
|
the proper
| Quote: | | Quote: | peer/ user to get the proper codec settings, ACLs and such.
Since all versions of Asterisk use OPTIONs for
|
|
NAT-keepalives, I'm a
| Quote: | | Quote: | bit hesitant to fix this. It's a catch 22. I want to do it
|
|
properly,
| Quote: | | Quote: | 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
| Quote: | | Quote: | 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
| Quote: | 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
| Quote: | 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
| Quote: | 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""
| Quote: | 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. |
|
| Back to top |
|
|
oza-4h07 at myamail.com
Guest
|
| Posted: Wed Jan 09, 2008 1:14 pm Post subject: [asterisk-users] How to check if a SIP phone isforwardedwith |
|
|
2008/1/9, Steve Langstaff <steve.langstaff at citel.com>:
| Quote: |
| Quote: | -----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] 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:
| Quote: | | Quote: | -----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] 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:
| Quote: | This issue of phone vendors not supporting OPTIONS
|
|
|
according to RFC
| Quote: | | Quote: | | Quote: | 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
| Quote: | 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
| Quote: | | Quote: | for keep-alives. I'm starting to see devices that use it for
checking capabilities - the proper way. To do this
|
|
properly, we will
| Quote: | | Quote: | have to authenticate the OPTIONs request and match it with
|
|
the proper
| Quote: | | Quote: | peer/ user to get the proper codec settings, ACLs and such.
Since all versions of Asterisk use OPTIONs for
|
|
NAT-keepalives, I'm a
| Quote: | | Quote: | bit hesitant to fix this. It's a catch 22. I want to do it
|
|
properly,
| Quote: | | Quote: | 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
| Quote: | | Quote: | 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
| Quote: | 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
| Quote: | 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
| Quote: | 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""
| Quote: | 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.
|
Yes, obviously, there are 2 different issues :
1. how to query phone status
2. how to keep NAT alives
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.
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.
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
http://www.cornfed.com/ping.html ) ?
Either SIP PING (or something equivalent) should be ratified or SIP OPTIONS
should be "clarified".
_______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080109/803c862d/attachment.htm |
|
| Back to top |
|
|
benny+usenet at amorse...
Guest
|
| Posted: Thu Jan 10, 2008 2:43 am Post subject: [asterisk-users] How to check if a SIP phone isforwardedwith |
|
|
"Steve Langstaff" <steve.langstaff at citel.com> writes:
| Quote: | 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.
|
If the asterisk community is going to ask the phone manufacturers to
comply to the RFC, it looks rather silly when asterisk itself doesn't.
Not that I have a good solution.
/Benny |
|
| Back to top |
|
|
oza-4h07 at myamail.com
Guest
|
| Posted: Thu Jan 10, 2008 4:50 am Post subject: [asterisk-users] How to check if a SIP phone isforwardedwith |
|
|
2008/1/10, Benny Amorsen <benny+usenet at amorsen.dk>:
| Quote: |
"Steve Langstaff" <steve.langstaff at citel.com> writes:
| Quote: | 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.
|
If the asterisk community is going to ask the phone manufacturers to
comply to the RFC, it looks rather silly
|
Shall we really care about this ?
As Steve said, ourselves not implementing RFC compliant OPTIONS is another
topic.
when asterisk itself doesn't.
| Quote: |
Not that I have a good solution.
|
Separating problems might help to find such good solution
/Benny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080110/3c6fe0e8/attachment-0001.htm |
|
| Back to top |
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
Search
