Re: [asterisk-users] SIP registration problem
I have seen this issue where there were internet connectivity issues. Asterisk registers every so often with the ITS. For some reason or another (it can be many reasons such as DNS, internet, ISP has issue etc). asterisk cant re-register so it keeps trying. As far as the so context if you have a simple register line in sip.conf (such as register=> axe:[EMAIL PROTECTED]) then asterisk will tell the server that it is registering it with to send all calls to the s extension in your default context. - Original Message - From: Michelle Dupuis To: asterisk-users@lists.digium.com Sent: Saturday, May 05, 2007 4:08 PM Subject: [asterisk-users] SIP registration problem I've reposted with a more meaningful subject - hopefully someone will replyWe have an Asterisk v1.2.16 box registering with an ITSP using SIP. The registration succeeds, and is confirmed with SIP SHOW REGISTER. However, we frequently (every few minutes) see this on our console: REGISTER attempt 1 to [EMAIL PROTECTED] REGISTER attempt 2 to [EMAIL PROTECTED] Any ideas what is going on? In particular 1. What causes the two register attempt messages above? 2. Why is our asterisk box being associated with the "entryunauthorized" context, not the "entryinternal" context? (See below) 3. Why is the contact "" in our SIP messages, why s@ anything? Thanks MD -- Contents of sip.conf at ITSP: [999] context=entryinternal ; I know this context exists! This is the right context. type=friend username=999 secret= callerid="Test" <999> host=dynamic nat=no canreinvite=no allow=ulaw allow=alaw dtmfmode=rfc2833 --- Console log from ITSP show strange SIP traffic: --- Scheduling destruction of call '[EMAIL PROTECTED]' in 15000 ms pbx*CLI> pbx*CLI> <-- SIP read from 123.183.86.231:5060: REGISTER sip:pbx.itsp.com SIP/2.0 Via: SIP/2.0/UDP 123.183.86.231:5060;branch=z9hG4bK1a8cee82;rport From: ;tag=as3218ff14 To: Call-ID: [EMAIL PROTECTED] CSeq: 103 REGISTER User-Agent: Asterisk PBX Max-Forwards: 70 Authorization: Digest username="999", realm="pbx.itsp.com", algorithm=MD5, uri="sip:pbx.itsp.com", nonce="5cec66c0", response="6451967016fc38f896efeb7247523fe1", opaque="" Expires: 120 Contact: Event: registration Content-Length: 0 --- (13 headers 0 lines) --- Using latest REGISTER request as basis request Sending to 123.183.86.231 : 5060 (NAT) Transmitting (no NAT) to 123.183.86.231:5060: SIP/2.0 100 Trying Via: SIP/2.0/UDP 123.183.86.231:5060;branch=z9hG4bK1a8cee82;received=123.183.86.231;rport=5060 From: ;tag=as3218ff14 To: Call-ID: [EMAIL PROTECTED] CSeq: 103 REGISTER User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: Content-Length: 0 --- Transmitting (no NAT) to 123.183.86.231:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP 123.183.86.231:5060;branch=z9hG4bK1a8cee82;received=123.183.86.231;rport=5060 From: ;tag=as3218ff14 To: ;tag=as7d680d48 Call-ID: [EMAIL PROTECTED] CSeq: 103 REGISTER User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Expires: 120 Contact: ;expires=120 Date: Fri, 04 May 2007 19:27:58 GMT ontent-Length: 0 <-- SIP read from 123.183.86.231:5060: OPTIONS sip:pbx.itsp.com SIP/2.0 Via: SIP/2.0/UDP 123.183.86.231:5060;branch=z9hG4bK36c1df86;rport From: "asterisk" ;tag=as6e5334cf To: Contact: Call-ID: [EMAIL PROTECTED] CSeq: 102 OPTIONS User-Agent: Asterisk PBX Max-Forwards: 70 Date: Fri, 04 May 2007 19:38:36 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 --- (12 headers 0 lines) --- Looking for s in entryunauthorized (domain pbx.itsp.com) Transmitting (no NAT) to 123.183.86.231:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP 123.183.86.231:5060;branch=z9hG4bK36c1df86;received=123.183.86.231;rport=5060 From: "asterisk" ;tag=as6e5334cf To: ;tag=as51d476cd Call-ID: [EMAIL PROTECTED] CSeq: 102 OPTIONS User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: Accept: application/sdp Content-Length: 0 -- ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] SIP registration problem w/ SBC
Thanks Andrew, I see the resolved bug report. I'll get the patch fix. Sorry for the unnecessary mail. -Tom On 1/20/07, Andrew Joakimsen <[EMAIL PROTECTED]> wrote: http://www.google.com/search?q=423+%22Interval+Too+Brief%22&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official Hint: Who develops Asterisk? On 1/20/07, Thomas Madler <[EMAIL PROTECTED]> wrote: > Hi, > > I'm trying to get my * server connected to a softswitch through an SBC. I > get the following error when * trys to register. > > Got SIP response 423 "Interval Too Brief" back from xxx.xxx.xxx.xxx > Jan 20 12:43:54 NOTICE[2138]: chan_sip.c:5473 sip_reg_timeout:-- > Registration for '[EMAIL PROTECTED] ' timed out, trying again > (Attempt #9) > > Is there something I can tweak on my end to fix this? > > TIA, > > -Tom > ___ > --Bandwidth and Colocation provided by Easynews.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > > http://lists.digium.com/mailman/listinfo/asterisk-users > > > ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] SIP registration problem w/ SBC
http://www.google.com/search?q=423+%22Interval+Too+Brief%22&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official Hint: Who develops Asterisk? On 1/20/07, Thomas Madler <[EMAIL PROTECTED]> wrote: Hi, I'm trying to get my * server connected to a softswitch through an SBC. I get the following error when * trys to register. Got SIP response 423 "Interval Too Brief" back from xxx.xxx.xxx.xxx Jan 20 12:43:54 NOTICE[2138]: chan_sip.c:5473 sip_reg_timeout:-- Registration for '[EMAIL PROTECTED] ' timed out, trying again (Attempt #9) Is there something I can tweak on my end to fix this? TIA, -Tom ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] SIP registration problem
In the Grandstream setup, turn off "subscribe to message waiting indication". ...or upgrade to CVS head, where I've fixed this problem with SUBSCRIBE. Best regards, /Olle ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] SIP Registration problem
>From the wiki... http://www.voip-info.org/wiki-Asterisk+phone+grandstream+budgetone "If you are having problems with the phone losing registration periodically, make sure that "SUBSCRIBE for MWI" is set to "No" in the phone's configuration. This applies to at least version 1.0.4.55, possibly others." Just answered this one maybe yesterday? :) -Jon -Original Message- Hi Folks, I'm having problem with GS registering in Asterisk. My setup is the following: Anyone has any clue? Isamar ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] SIP Registration Problem
Brian Rathman wrote: I am using snom200 phones registering with Asterisk via SIP. I can see where the phone registers without a problem, and then when you try and make a call I get a proxy authentication required message on the phone and failed to authenticate user error in the Asterisk messages file. Then the next call you make from the phone goes through without a problem. Nothing changes between these two events, but it is almost like the phone is using two different passwords for the same account. Has anyone else seen a problem like this? I am using an Asterisk CVS version from early March, not sure if upgrading will help as well. Thanks, Brian Please don't start a new thread by replying to an exisiting post - threaded mailreaders list it as a reply to that post (even if you change the subject, as theading is done by messageid). You're also less likely to get a response due to the post being inside an existing converstion rather than as listed as a new topic. regards, Julien ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] SIP Registration Problem
Title: Re: [Asterisk-Users] Wiki TOS - worrying for an open sourceproject? To add to the previous information I am receiving error messages on the phones that say: [5]28/5/2004 11:20:26: Match challenge for user=9991110035, realm=asterisk, valid=all: [2]28/5/2004 11:20:26: Registrar [EMAIL PROTECTED] refused with code 407 [5]28/5/2004 11:20:26: No nonce found on response [2]28/5/2004 11:20:26: Registrar [EMAIL PROTECTED] refused with code 401 Does anyone know what these 407 and 401 errors are? -Original Message-From: Brian J. Rathman [mailto:[EMAIL PROTECTED]Sent: Friday, May 28, 2004 11:28 AMTo: [EMAIL PROTECTED]Subject: [Asterisk-Users] SIP Registration Problem I am using snom200 phones registering with Asterisk via SIP. I can see where the phone registers without a problem, and then when you try and make a call I get a proxy authentication required message on the phone and failed to authenticate user error in the Asterisk messages file. Then the next call you make from the phone goes through without a problem. Nothing changes between these two events, but it is almost like the phone is using two different passwords for the same account. Has anyone else seen a problem like this? I am using an Asterisk CVS version from early March, not sure if upgrading will help as well. Thanks, Brian
Re: [Asterisk-Users] Sip Registration Problem
Karl Brose wrote: This is also closely related to Asterisk SIP's lack of proper [user section] authentication/recognition for incoming calls. We've seen a lot of posts here where new users have problems with this, but the real problem is usually not acknowledged. So tell me what's wrong with the user authentication/recognition ? I'm working on that part in chan_sip2 now. /O ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Sip Registration Problem
No and Yes, Olle. But mostly NO. What Asterisk is doing actually depends on how it is configured. If you are, by design, accepting calls for a particular [user] through the default context from the general section in sip.conf it will generate the correct response, but this is not because asterisk recognized the situation and behaved appropriately, but because it's broken and doesn't check for the correct context to determine if the call should return a 200/OK or whether it should say 404 because the call could never succeed if it where an INVITE. This is also closely related to Asterisk SIP's lack of proper [user section] authentication/recognition for incoming calls. We've seen a lot of posts here where new users have problems with this, but the real problem is usually not acknowledged. Olle E. Johansson wrote: Karl Brose wrote: If the response to an OPTIONS is generated by a proxy server, the This is what asterisk is doing, or? see above Please explain where and how you think Asterisk is not following the RFC, and I'll look into it. The other alternative would be to act as a UAS, but that may be confusing. Is any phone using this for checking if an URL is busy or not? In dialogue or out of dialogue? Just want to know if there's anything out there to test with. Thank you for looking this up. /O I found out through an actual server that send OPTION packets. but that was a while ago before I fixed my drivers. Haven't submitted it to the bug tracker. I posted a fix for this earlier today here for the recent cvs'es, it at least looks up the context to test for the extension called and returns 200 if that extension is valid. But there should really be more processing for more general compliance. ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Sip Registration Problem
Karl Brose wrote: If the response to an OPTIONS is generated by a proxy server, the proxy returns a 200 (OK), listing the capabilities of the server. The response does not contain a message body. Allow, Accept, Accept-Encoding, Accept-Language, and Supported header fields SHOULD be present in a 200 (OK) response to an OPTIONS request. If the response is generated by a proxy, the Allow header field SHOULD be omitted as it is ambiguous since a proxy is method agnostic. Contact header fields MAY be present in a 200 (OK) response and have the same semantics as in a 3xx response. That is, they may list a set of alternative names and methods of reaching the user. A Warning header field MAY be present. This is what asterisk is doing, or? Please explain where and how you think Asterisk is not following the RFC, and I'll look into it. The other alternative would be to act as a UAS, but that may be confusing. Is any phone using this for checking if an URL is busy or not? In dialogue or out of dialogue? Just want to know if there's anything out there to test with. Thank you for looking this up. /O ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Sip Registration Problem
for those who want to patch their SIP, here is a quck fix to make Asterisk do a little better: --- chan_sip.c 2004-05-16 01:33:06.0 -0400 +++ chan_sip.c_OPTIONS 2004-05-17 14:30:36.0 -0400 @@ -5916,6 +5916,7 @@ /* Initialize the context if it hasn't been already */ if (!strcasecmp(cmd, "OPTIONS")) { + check_user(p, req, cmd, e, 0, sin, 0); res = get_destination(p, req); build_contact(p); /* XXX Should we authenticate OPTIONS? XXX */ Olle E. Johansson wrote: Karl Brose wrote: Btw, Ignoring OPTIONS is not a valid option (:-) whether sip proxy or not, Asterisk doesn't do it correctly either. The host should respond with 200/OK if the call >could< succeed theoretically if it were an INVITE or else it should send a 404 or maybe a 487(? hmm, have to look) see the RFC for details. Interesting, didn't know that. Where in the RFC? ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Sip Registration Problem
RFC 3261 states: 11.2 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. An OPTIONS request received within a dialog generates a 200 (OK) response that is identical to one constructed outside a dialog and does not have any impact on the dialog. This use of OPTIONS has limitations due to the differences in proxy handling of OPTIONS and INVITE requests. While a forked INVITE can result in multiple 200 (OK) responses being returned, a forked OPTIONS will only result in a single 200 (OK) response, since it is treated by proxies using the non-INVITE handling. See Section 16.7 for the normative details. If the response to an OPTIONS is generated by a proxy server, the proxy returns a 200 (OK), listing the capabilities of the server. The response does not contain a message body. Allow, Accept, Accept-Encoding, Accept-Language, and Supported header fields SHOULD be present in a 200 (OK) response to an OPTIONS request. If the response is generated by a proxy, the Allow header field SHOULD be omitted as it is ambiguous since a proxy is method agnostic. Contact header fields MAY be present in a 200 (OK) response and have the same semantics as in a 3xx response. That is, they may list a set of alternative names and methods of reaching the user. A Warning header field MAY be present. A message body MAY be sent, the type of which is determined by the Accept header field in the OPTIONS request (application/sdp is the default if the Accept header field is not present). If the types include one that can describe media capabilities, the UAS SHOULD include a body in the response for that purpose. Details on the construction of such a body in the case of application/sdp are described in [13]. Brett Nemeroff wrote: How will this effect a live system? No new calls? Or will it terminate exisiting calls? I'll have a chat with the vendor regarding the OPTIONS reply.. It certainly does sesem like it should reply with something.. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olle E. Johansson Sent: Tuesday, May 25, 2004 1:13 AM To: [EMAIL PROTECTED] Subject: Re: [Asterisk-Users] Sip Registration Problem Karl Brose wrote: Btw, Ignoring OPTIONS is not a valid option (:-) whether sip proxy or not, Asterisk doesn't do it correctly either. The host should respond with 200/OK if the call >could< succeed theoretically if it were an INVITE or else it should send a 404 or maybe a 487(? hmm, have to look) see the RFC for details. Interesting, didn't know that. Where in the RFC? I removed the qualify lines and sip reload [ed]. The extension still showed up as "UNREACHABLE" instead of "UNMONITORED". I had to do a full restart to get it to stop sending the OPTIONS messages. What did I do wrong here? How can I make a change to qualify without restarting? If a peer is registred at reload/sip reload, it will not change. You have to unload the sip module and reload it or restart asterisk to change the configuration of a registred, i.e. active, peer. /O ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Sip Registration Problem
>>>I removed the qualify lines and sip reload [ed]. The extension still >>>showed up as "UNREACHABLE" instead of "UNMONITORED". I had to do a >>>full restart to get it to stop sending the OPTIONS messages. >>>What did I do wrong here? How can I make a change to qualify without >>>restarting? > If a peer is registred at reload/sip reload, it will not change. > You have to unload the sip module and reload it or restart asterisk > to change the configuration of a registred, i.e. active, peer. > /O Brett Nemeroff wrote: How will this effect a live system? No new calls? Or will it terminate exisiting calls? Unloading SIP module will terminate all SIP calls Restarting Asterisk will terminate all calls :( ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] Sip Registration Problem
How will this effect a live system? No new calls? Or will it terminate exisiting calls? I'll have a chat with the vendor regarding the OPTIONS reply.. It certainly does sesem like it should reply with something.. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olle E. Johansson Sent: Tuesday, May 25, 2004 1:13 AM To: [EMAIL PROTECTED] Subject: Re: [Asterisk-Users] Sip Registration Problem Karl Brose wrote: > Btw, Ignoring OPTIONS is not a valid option (:-) whether sip proxy or > not, Asterisk doesn't do it correctly either. > The host should respond with 200/OK if the call >could< succeed > theoretically if it were an INVITE or else it should send a > 404 or maybe a 487(? hmm, have to look) see the RFC for details. Interesting, didn't know that. Where in the RFC? >> I removed the qualify lines and sip reload [ed]. The extension still >> showed up as "UNREACHABLE" instead of "UNMONITORED". I had to do a >> full restart to get it to stop sending the OPTIONS messages. >> >> What did I do wrong here? How can I make a change to qualify without >> restarting? If a peer is registred at reload/sip reload, it will not change. You have to unload the sip module and reload it or restart asterisk to change the configuration of a registred, i.e. active, peer. /O ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Sip Registration Problem
Karl Brose wrote: Btw, Ignoring OPTIONS is not a valid option (:-) whether sip proxy or not, Asterisk doesn't do it correctly either. The host should respond with 200/OK if the call >could< succeed theoretically if it were an INVITE or else it should send a 404 or maybe a 487(? hmm, have to look) see the RFC for details. Interesting, didn't know that. Where in the RFC? I removed the qualify lines and sip reload [ed]. The extension still showed up as "UNREACHABLE" instead of "UNMONITORED". I had to do a full restart to get it to stop sending the OPTIONS messages. What did I do wrong here? How can I make a change to qualify without restarting? If a peer is registred at reload/sip reload, it will not change. You have to unload the sip module and reload it or restart asterisk to change the configuration of a registred, i.e. active, peer. /O ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Sip Registration Problem
It's a bug in Asterisk. I believe it's still open also on the bugtracker. There are a few reported senarios with these kind of problems. Some of them where solved with the recent 'ast_gethostbyname' fix. Are you running a recent version? Btw, Ignoring OPTIONS is not a valid option (:-) whether sip proxy or not, Asterisk doesn't do it correctly either. The host should respond with 200/OK if the call >could< succeed theoretically if it were an INVITE or else it should send a 404 or maybe a 487(? hmm, have to look) see the RFC for details. Brett Nemeroff wrote: Hi All, I had an unusual problem today; I'm sure it's a configuration problem. I had 2 phones behind a nat device and I had qualify=300 in both extensions config. The device I was talking to was an edgewater traffic shaper,/Sip Proxy. Since it is acting as a sip proxy, it was ignoring the OPTIONS messages that * was sending, and thus * interpreted that as the extensions being down. I removed the qualify lines and sip reload [ed]. The extension still showed up as "UNREACHABLE" instead of "UNMONITORED". I had to do a full restart to get it to stop sending the OPTIONS messages. What did I do wrong here? How can I make a change to qualify without restarting? Thanks all, Brett ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users