Request-URI vs. To-Header-URI beim eingehenden Routing in SIP

...

To
INVITE
INVITE
INVITE sip:bob@pbx;transport=udp SIP/2.0
To: "Bob" <sip:bob@pbx>
...

To
sip:bob@pbx
      Request-URI: The Request-URI is a SIP or SIPS URI as described in
           Section 19.1 or a general URI (RFC 2396 [5]).  It indicates
           the user or service to which this request is being addressed.

   The initial Request-URI of the message SHOULD be set to the value of
   the URI in the To field.

   The To header field first and foremost specifies the desired
   "logical" recipient of the request, or the address-of-record of the
   user or resource that is the target of this request.

   The To header field specifies the logical recipient of the request.

   The To header field identifies the original recipient of the request
   designated by the user identified in the From field.  The original
   recipient may or may not be the UAS processing the request, due to
   call forwarding or other proxy operations.

   However, the Request-URI identifies the UAS that is to process the
   request

   In some cases, users may want to conceal personal information in
   header fields that convey identity.  This can apply not only to the
   From and related headers representing the originator of the request,
   but also the To - it may not be appropriate to convey to the final
   destination a speed-dialing nickname, or an unexpanded identifier for
   a group of targets, either of which would be removed from the
   Request-URI as the request is routed, but not changed in the To
   header field if the two were initially identical.  Thus it MAY be
   desirable for privacy reasons to create a To header field that
   differs from the Request-URI.

To
INVITE
To
To
To
To
To
INVITE sip:accountname@host;transport=udp SIP/2.0
To: <sip:012377777555@pbx>
...

INVITE sip:0123777770@host;transport=udp SIP/2.0
To: <sip:012377777555@pbx>
...

REGISTER
REGISTER
xxxx
accountname
0123777770
INVITE sip:accountname@...
INVITE sip:0123777770@...
To
To
To
/opt/gemeinschaft/etc/asterisk/e-gategroups-in.ael.php
    /*
    # hack for Sipgate.de {
    if (preg_match('/\bsipgate\b/i', $name)) {
        echo "\t\t\t", "\n";
        echo "\t\t\t", 'Set(did_full=${SIP_HEADER(To)});' ,"\n";
        echo "\t\t\t", 'Set(did_full=${CUT(did_full,@,1)});' ,"\n";
        echo "\t\t\t", 'Set(did_full=${did_full:5});' ,"\n";
        echo "\t\t\t", 'Verbose(1,### Inbound call from Sipgate to ${did_full});' ,"\n";
        echo "\t\t\t", "\n";
    }
    # hack for Sipgate.de }
    */

/*
*/
To
    # hack for routing based on To header URI {
    echo 'if ("${CHANNEL(channeltype)}" = "SIP") {' ,"\n";
    echo '    Set(did_full=${SIP_HEADER(To)});' ,"\n";
    //                    "Bob" <sip:012377777555@host>
    echo '    Set(did_full=${CUT(did_full,@,1)});' ,"\n";
    //                    "Bob" <sip:012377777555
    echo '    if ("${CUT(did_full,<,2)}" != "") {' ,"\n";
    echo '        Set(did_full=${CUT(did_full,<,2)});' ,"\n";
    echo '    }' ,"\n";
    //                           sip:012377777555
    echo '    if ("${CUT(did_full,:,2)}" != "") {' ,"\n";
    echo '        Set(did_full=${CUT(did_full,:,2)});' ,"\n";
    echo '    }' ,"\n";
    //                               012377777555
    echo '    Verbose(1,### DNID by To header: ${did_full});' ,"\n";
    echo '}' ,"\n";
    # hack for routing based on To header URI }

/etc/init.d/asterisk restart
asterisk -r
core set verbose 1
core set
	verbose 3
012377777555
012377777
555
555555
Remote-Party-ID
;party=called
;party=called
P-Called-Party-ID
X-irgendwas
X-Original-DDI-URI
To
To
A Workaround is to put the originally called number in the To header - 
but this is ugly as To based routing it is against all RFCs.

Using To: you assume that the To header contains the originally called 
number. But that depends on the setup of the trunking provider.

Found it: http://www.ietf.org/rfc/rfc3455.txt
P-Called-Party-ID (there is is good documentation why other workarounds 
are not good).

This remembers me on another approach - differentiate between routing 
and retargeting. Please read 
http://tools.ietf.org/html/draft-rosenberg-sip-ua-loose-route-02 which 
also addresses these problems. As this is logically not retargeting but 
routing, the trunking provider could send the called number in the RURI, 
and the registered contact is sent as Route header. Thus, Asterisk could 
match the registered contact against the topmost Route header and the 
RURI contains the dialed number.

Probably, as there are multiple solutions, we should ask on the
SIP implementors list.

Right now there's too many ways for service providers to solve
this problem, including home-brewed headers. That doesn't
help anyone.

INVITE sip:056854@87.127.89.138:5060 SIP/2.0
From: Alice <sip:alice@voip.co.uk>
To: Bob <sip:bob@voip.co.uk>

      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      From                    c       r    m   m   m   m   m   m
      To                      c(1)    r    m   m   m   m   m   m

   The "proxy" column describes the operations a proxy may perform on a
   header field:

      r: A proxy must be able to read the header field, and thus this
           header field cannot be encrypted.

History-Info

Request-URI vs. To-Header-URI beim eingehenden Routing in SIP

Definitionen aus dem SIP-RFC

Was bedeutet das?

Problem: SIP-Trunks bei SIP-Providern

Woher bekommen wir die Zielrufnummer?

Workaround in Gemeinschaft

Weitere technische Diskussionen zum Thema