I understand that it is customary for SIP User Agents to send OPTIONS packets every now and then to check that a peer is still alive and well. Indeed I understand that Asterisk itself sends them if qualify is set to yes in the peer configuration. How is one supposed to configure the dialplan so that Asterisk responds correctly to these requests? At the moment, I'm seeing "Looking for s in default" and then a "404 Not Found" being returned - which can't be right. Thanks! Alex Lake DIGITAL MAIL LIMITED
Alex Lake wrote:> I understand that it is customary for SIP User Agents to send OPTIONS > packets every now and then to check that a peer is still alive and well. > Indeed I understand that Asterisk itself sends them if qualify is set to > yes in the peer configuration. > > How is one supposed to configure the dialplan so that Asterisk responds > correctly to these requests? > > At the moment, I'm seeing "Looking for s in default" and then a "404 Not > Found" being returned - which can't be right. > > Thanks! > Alex Lake > DIGITAL MAIL LIMITEDHandling of OPTIONS in Asterisk has changed a little bit through chan_sip versions... but for the most part the other side usually just wants you to respond with something/anything. Is the other side unhappy with the 404 Not Found? Joshua Colp Software Developer Digium, Inc.
Hi Alex,> How is one supposed to configure the dialplan so that Asterisk responds > correctly to these requests? > > At the moment, I'm seeing "Looking for s in default" and then a "404 Not > Found" being returned - which can't be right.Not specific to an OPTIONS packet, but I know that I previously experienced wierdness when I had my dialplan matching too much. For me it was a 'default route' for all calls going out a particular SIP peer. exten => _.,1,Dial(SIP/${EXTEN}@provider,,r) There were instances of SIP reinvites that would match this dial plan and be dialled back out to the provider. My fix was _XXXX etc, matching more specifically what extensions I wanted to dial out to that provider. Your problem looks similar - Asterisk, based on your dialplan is initerpreting the special extension s as some dial attempt, resulting in 404 Not Found. There are a bunch of these special extensions: http://www.voip-info.org/wiki/index.php?page=Asterisk+config+extensions.conf Predefined Extension Names Asterisk uses some extension names for special purposes: * i : Invalid * s : Start * h : Hangup * t : Timeout * T : AbsoluteTimeout * o : Operator This is my guess anyhow - if this isn't right, hopefully someone else can pin it down for you .. Regards, Chris Bennett
Hi Alex,> How is one supposed to configure the dialplan so that Asterisk responds > correctly to these requests? > > At the moment, I'm seeing "Looking for s in default" and then a "404 Not > Found" being returned - which can't be right.Not specific to an OPTIONS packet, but I know that I previously experienced wierdness when I had my dialplan matching too much. For me it was a 'default route' for all calls going out a particular SIP peer. exten => _.,1,Dial(SIP/${EXTEN}@provider,,r) There were instances of SIP reinvites that would match this dial plan and be dialled back out to the provider. My fix was _XXXX etc, matching more specifically what extensions I wanted to dial out to that provider. Your problem looks similar - Asterisk, based on your dialplan is initerpreting the special extension s as some dial attempt, resulting in 404 Not Found. There are a bunch of these special extensions: http://www.voip-info.org/wiki/index.php?page=Asterisk+config+extensions.conf Predefined Extension Names Asterisk uses some extension names for special purposes: * i : Invalid * s : Start * h : Hangup * t : Timeout * T : AbsoluteTimeout * o : Operator This is my guess anyhow - if this isn't right, hopefully someone else can pin it down for you .. Regards, Chris Bennett