ast1.2.7.1 : SIP INVITE parse error w/ SONUS VoIP gateways

Affects all asterisk systems that must interop with SONUS gateways (e.g. most of the big VoIP telco world).

Consider this from chan_sip.c in asterisk-

[code]line 10368: handle_request_invite
line 10368: call to get_destination
line 6523: get_destination
line 6560: /* Skip any options */
line 6561: if ((a = strchr(uri, ‘;’))) {
line 6562: *a = ‘\0’;
line 6563: }

line 6565: /* Get the target domain */
line 6566: if ((a = strchr(uri, ‘@’))) {
line 6567: a = ‘\0’;
line 6568: a++;
line 6569: } else { /
No username part /
line 6570: a = uri;
line 6571: uri = “s”; /
Set extension to “s” */
line 6572: }[/code]

follow it’s processing with this INVITE:

problem is the code doesn’t expect a semicolon in the user part before the @ sign. Note that some valid examples have multiple semicolons before the @ sign. In present case, stripping everything after the first semicolon (line 6562) strips the @ sign, and the following code that checks for the domain thinks there is no user because the @ is missing (line 6569). This results in the call with this type of URI being dumped into the ‘s’ extension instead of the intended extension. It also causes p->domain to be set to the extension in line 6577.

After spending a few hours looking at chan_sip.c code for first time I could track down and figure out this much. But I’m seriously not a coder (did pascal & fortran 10+ years ago in college), anyone here could fix it much faster, and if I make my own fix I’ll screw up patching it whenever I upgrade asterisk releases. Please help!!

I think the right approach is to:

  1. first check for @ sign, and if it’s missing assume no user part & dump into ‘s’ extension
  2. if @ sign is present, then:
    split into user & domain pieces
    strip everything after ';'
    strip everything after ‘;’ in domain piece (and set *a to start of it)
    concatenate user@domain to reform URI without options
  3. else if @ sign is not present, then:
    a= uri ; uri = “s” ;

I’m probably missing something, but this should be enough for you real programmers to figure it out! I’m not shirking responsibility by not fixing it… I’m truly rising from a humble place to the best that I can contribute.

Thanks :smile:

FYI here’s another example URI that must be parsed successfully:

sip:7135551212;rn=7132310099;npdi=yes@;dtg=TRUNKGROUP01;user=phone SIP/2.0

Very interesting. I think it might be a good idea to file this as a bug at I’m not a coder either - well, I have the same problem you have, with pascal 10 years ago, which isn’t exactly modern C :smile:

I probably will have to interop with Sonus in the future, so it might be a good thing to get this fixed.