Summary:ASTERISK-00359: SIP URIs are inappropriately shortened
Reporter:John Todd (jtodd)Labels:
Date Opened:2003-10-07 14:02:53Date Closed:2004-09-25 02:49:15
Versions:Frequency of
Description:Dialing "user@domain.com" via a sip client results in only "user" appearing in the dialplan extension matching.


I dialed "user@domain.com" from my 7960, and had this in my dialplan for that SIP peer (all calls hit "intern" first when originating from the 7960):

exten => _.,1,NoOp(${EXTEN})

This is the output on the console:
-- Executing NoOp("SIP/2203-6f64", "user") in new stack

The "@domain.com" part got cut off!  That pretty much defeats the purpose of URI-based dialing.  The dialplan should get the whole URI, and not just the username.  At a minium, it should be a selectable feature in sip.conf for each peer if the full URI is passed through or not.
Comments:By: John Todd (jtodd) 2003-10-07 17:06:22

See http://bugs.digium.com/bug_view_page.php?bug_id=0000363  for an application that could handily grab the username portion of the URI in front of the "@" sign.

By: Mark Spencer (markster) 2003-10-14 04:43:57

I think a domain mapping would be ideal, something like

domain1.com => domain1context
domain2.com => domain2context

Anybody want to write it?

By: John Todd (jtodd) 2003-10-14 22:16:55

I'm not sure why that would be required; just use the "cut" routines to determine where to send calls.  All that needs to happen is that the full SIP URI needs to find it's way into ${EXTEN}

Here's an example of what I'd see as the method to use:

exten => _.,1,Cut(USER=EXTEN,@,1)
exten => _.,2,Cut(DOMAIN=EXTEN,@,2)
exten => _.,3,GotoIf($[${DOMAIN} = domain1.com]?domain1context|${USER}|1:4
exten => _.,4,GotoIf($[${DOMAIN} = domain2.com]?domain2context|${USER}|1:5
exten => _.,5,Congestion

Maybe something in sip.conf under each SIP entry that looks like this:


to do the obvious thing and maintain backwards compatability

By: Olle Johansson (oej) 2003-10-27 04:04:22.000-0600

In addition to this, maybe another but related bug:
If you get a call from sip:someone@somedomain.com, all that shows up in my  CDR record is "someone" not "sip:someone@somedomain.com".

By: Olle Johansson (oej) 2003-10-27 04:23:15.000-0600

I also think there's something wrong with the DIAL syntax


Doesn't mean "try finding a SIP proxy for domain "edvina.net" and dial olle at that proxy. It seems to mean "dial olle at the proxy defined in sip.conf under [edvina.net] - which does not scale. We need to separate the two so that we can dial out to SIP urls, like
Dial (SIP/olle@hostname-in-sip.conf)
Dial (SIP/sip:olle@domain.tld)

The later do a DNS SRV lookup and place a SIP call.
Disclaimer: It might work this way today, but I can't see any docs and can't make it work as I want...

By: John Todd (jtodd) 2003-10-27 12:17:00.000-0600

This may be impractical due to parsing limitations, but it seems perhaps a reasonable solution to enclose fully-qualified SIP URIs in quotes, but leave things which are referenced without quotes to be handled by specific sip.conf stanza syntax.

Dial(SIP/olle@hostname-in-sip.conf) - uses the values under the specific hostname in sip.conf for outbound configs

Dial(SIP/"olle@domain.tld:5061") - this does an SRV lookup on domain.tld and connects on port 5061 to that host, and uses the settings in [general] for codecs, tos, etc.

By: Olle Johansson (oej) 2003-10-27 13:55:28.000-0600

I think we have to use a full SIP url

so we're prepared fro the day we can write

for TLS connections (but that's another story, really).

>Dial(SIP/"olle@domain.tld:5061") - this does an SRV lookup on domain.tld and
> connects on port 5061 to that host, and uses the settings in [general] for
> codecs, tos, etc.
If you give a port number, SRV lookup can't be done - or?
SRV lookup is based on port number, like _sip._udp or _sip._udp for port
5060/udp and 5060/tcp
Without port number, SRV lookup is needed.

By: Olle Johansson (oej) 2003-11-03 15:30:27.000-0600

From chan_sip.c:

static int get_destination(struct sip_pvt *p, struct sip_request *oreq)
       char tmp[256] = "", *c, *a;
       char tmpf[256]= "", *fr;
       struct sip_request *req;

       req = oreq;
       if (!req)
               req = &p->initreq;
       if (req->rlPart2)
               strncpy(tmp, req->rlPart2, sizeof(tmp) - 1);
       c = ditch_braces(tmp);

       strncpy(tmpf, get_header(req, "From"), sizeof(tmpf) - 1);
       fr = ditch_braces(tmpf);

       if (strncmp(c, "sip:", 4)) {
               ast_log(LOG_WARNING, "Huh?  Not a SIP header (%s)?\n", c);
               return -1;
       c += 4;
       if (strlen(fr)) {
               if (strncmp(fr, "sip:", 4)) {
                       ast_log(LOG_WARNING, "Huh?  Not a SIP header (%s)?\n", fr);
                       return -1;
               fr += 4;
       } else
               fr = NULL;

       /* -------
        * OEJ: Here's where the domain is removed from To: Url, which
               breaks outbound SIP URL dialing
               We should only null @ if it's one of our own domains.
       if ((a = strchr(c, '@')) || (a = strchr(c, ';'))) {
               *a = '\0';
       if ((a = strchr(fr, '@')) || (a = strchr(fr, ';'))) {
               *a = '\0';
       if (sipdebug)
               ast_verbose("Looking for %s in %s\n", c, p->context);
       if (ast_exists_extension(NULL, p->context, c, 1, fr) ||
               !strcmp(c, ast_pickup_ext())) {
               if (!oreq)
                       strncpy(p->exten, c, sizeof(p->exten) - 1);
               return 0;

       if (ast_canmatch_extension(NULL, p->context, c, 1, fr) ||
           !strncmp(c, ast_pickup_ext(),strlen(c))) {
               return 1;

       return -1;

Quick fix is to add a variable for our own domain and only replace @ with null if it is
* Incoming call
* followed by one of our own IP addresses
* followed by one of our own domains

If we do this, how do we get outbound SIP URL:s to ENUM/SRV lookups and out?

By: Brian West (bkw918) 2003-12-14 13:03:02.000-0600

This has been fixed... ${EXTEN} would = user and ${SIPDOMAIN} would = domain.com


By: Brian West (bkw918) 2003-12-14 13:03:53.000-0600

domain would be in ${SIPDOMAIN}