[asterisk-dev] [Code Review] SIP Interop - Add an option to truncate user field at '; 's for the purpose of finding an extension.

[Walter Doekes]

On 13/05/11 18:17, David Vossel wrote:
>     On May 13th, 2011, 10:12 a.m., *David Vossel* wrote:
>
>         This fixes the instance where we are matching the extension in get_destination, but what about every other place sip URI's are parsed.  For instance, isn't this a problem when matching peer names as well?
>
>     On May 13th, 2011, 10:36 a.m., *jrose* wrote:
>
>         I imagine it very easily could, but the only scenario the bug reporter mentioned was the case where he was trying to make a call and couldn't connect to the extension.  So really, I don't know much about how it matches peer names at the moment.  I also don't know if there is any need to fix it up to match peer names.  I don't think the reporter or any of the responders mentioned anything about problems relating to them, and for all I know at the moment, the device in question might not be throwing in all these user parameters for things like REGISTER, SUBSCRIBE, or whatever else uses a peer name.
>
>         So yeah... hard to say if it's a problem or not.
>
> The peer is matched on the receive address in the issue linked to this review.  That's why it does not cause an issue for them.  For Users connecting to Asterisk we attempt to authenticate using the userfield portion of the From header, which could be jacked up just like the request URI. At least it appears this is possible based on the From header I observed in the issue.
>
> From:"KANOBE LLC"  <sip:2069106501;phone-context=+1 at 76.191.73.19:5060;user=phone>;tag=9b85b6358c7c201476787c3241c38f29
>
> If you are interested as to exactly where peer/user's are matched, take a look at the check_peer_ok() function in chan_sip.
>
> The most consistent way to solve this issue is to have every URI's userfield stripped when this option is enabled.

Wouldn't that force you to have to re-add these parameters in replies? I 
suspect that some devices like to see their own From header in the 
returned messages.

That would force you to have both a from_user_parameters and a 
ruri_user_parameters field. (Assuming that asterisk builds up the reply 
from scratch, and not from the original.)

Walter