[asterisk-dev] [Code Review] SIP user fields are crazy. Repeat extension searches if they all fail and semicolons are obfuscating the extension in the uri.

[David Vossel]

----- Original Message -----
> From: "Leif Madsen" <leif.madsen at asteriskdocs.org>
> To: asterisk-dev at lists.digium.com
> Sent: Thursday, May 12, 2011 11:15:49 AM
> Subject: Re: [asterisk-dev] [Code Review] SIP user fields are crazy. Repeat extension searches if they all fail and
> semicolons are obfuscating the extension in the uri.
> On 11-05-12 11:35 AM, Jonathan Rose wrote:
> > I don't know if I agree with that. I was more in line with thinking
> > an
> > option like this could be channel specific. You might want to cull
> > different words with an outside SIP provider from what you'd use
> > internally or with another SIP provider, and I'm not entirely sure
> > it's
> > easy, clean, or necessary to do that with another conf file.
> 
> You can still do that though. If you look at the queuerules.conf file,
> you
> define rules, and then the queues.conf allows you to apply separate
> rules to
> each queue, and that's how I would expect this to work.
> 
> The grammar file would contain the different ways of dealing with the
> grammars,
> then you could apply those rules to the specific peer within the
> sip.conf file.
> 
> sip_grammars.conf
> 
> [my_grammar]
> <insert whatever the grammars would look like>
> 
> 
> 
> sip.conf
> 
> [my_peer]
> type=peer
> ...
> grammar_rule=my_grammar
> 
> 
> That's what I'd expect.
> 
> Leif.

It looks like we might be getting into some theoretical discussions about things that are beyond the scope of the issue at hand.  The issue at hand is that there's stuff in the user field being sent from some devices that is screwing up extension and peer matching.

I want to make this simple, so here's a simple proposal.

For those people who have devices that do this to the user field and they don't want it there, lets just make a sip.conf option that strips those values out entirely out of every URI so their devices work.  No storing of the values in channel variables or anything like that to complicated it.  Just strip them off and let pattern matching do its thing without them.  If my understanding is correct, that is all people really want that are having interoperability issues with these user field options.

I'd imagine the option would look like this.

strip_uri_user_options = yes  ; When this option is enabled any parts of the user field of a URI delimited by a ';' will be stripped off before extensions or peer pattern matching occurs. This option is purely for interoperability purposes for devices that put options in the user field that are not supposed to be used during pattern matching.

If someone doesn't what those undefined fields stripped off their user fields, then they don't enable the option and have to do dialplan magic to get the extension to match correctly.

Does this work for everyone?  I know there is more to discuss here, but this approach seems to have merit regardless of what other changes in this area may be introduced in the future.

-- 
David Vossel
Digium, Inc. | Software Developer, Open Source Software
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org
The_Boy_Wonder in #asterisk-dev