[SR-Users] rtjson + mhomed and record route (corrected)

Diego Nadares dnadares at gmail.com
Thu Dec 22 16:20:56 CET 2016


Hi list,

We have two eth,  one with a private ip and the other with a public ip. We
have MHOMED configured. The call comes from private network and then is
routed to a public network via rtjson routing. The call is routed but the
thing is that the record route is being set with the private one (It's the
same when calls come from public and is routed to a private network, record
route has the public and not the private).

With mhomed configured shouldn't Record Route be updated as VIA header?

".... When activated, sip-router will select a socket that can reach the
destination (to be able to connect to the remote address). (sip-router
opens a UDP socket to the destination, then it retrieves the local IP which
was assigned by the operating system to the new UDP socket. Then this
socket will be closed and the retrieved IP address will be used as IP
address in the Via/Record-Route headers)..."

This is part of ngrep

U 2016/12/22 11:24:15.019643 172.16.213.21:5060 -> 172.16.213.38:5060
INVITE sip:11111111111 at 172.16.213.38:5060 SIP/2.0.
Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-13024-1-0.
From: "Test" <sip:2222222222 at 172.16.213.21:5060;user=phone>;tag=1.
To: <sip:1111111111 at 172.16.213.38:5060>.
Call-ID: 1-13024 at 172.16.213.21.
CSeq: 1 INVITE.
Contact: "2222222222 <sip:2222222222 at 172.16.213.21:5060>.
....

U 2016/12/22 11:24:15.023923 172.16.213.38:5060 -> 172.16.213.21:5060
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-13024-1-0.
....

U 2016/12/22 11:24:15.038695 XXX.XXX.XXX.01:5060 -> XXX.XXX.XXX.02:5060
INVITE sip:1111111111 <011%201111-1111>@XXX.XXX.XXX.02:5060 SIP/2.0.
*-----> Record-Route: <sip:172.16.213.38;lr;ftag=1;did=1111>. <----*
Via: SIP/2.0/UDP XXX.XXX.XXX.01;branch=z9hG4bKc09f
Via: SIP/2.0/UDP 127.0.0.8;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.NLOBF6

This is my cfg

mhomed=1

request_route {


        # per request initial checks
        route(REQINIT);

        # NAT detection
        #route(NATDETECT);

        # CANCEL processing
        if (is_method("CANCEL")) {
                if (t_check_trans()) {
                        route(RELAY);
                }
                exit;
        }

        # handle requests within SIP dialogs
        route(WITHINDLG);

        ### only initial requests (no To tag)

        # handle retransmissions
        if(t_precheck_trans()) {
                t_check_trans();
                exit;
        }
        t_check_trans();

        # authentication
        route(AUTH);

        # record routing for dialog forming requests (in case they are
routed)
        # - remove preloaded route headers
        remove_hf("Route");
        if (is_method("INVITE|SUBSCRIBE")) {
                record_route();
        }
....

Thanks in advance.

Diego

2016-12-22 12:08 GMT-03:00 Diego Nadares <dnadares at gmail.com>:

> Hi list,
>
> We have two eth,  one with a private ip and the other with a public ip. We
> have MHOMED configured. The call comes from private network and then is
> routed to a public network via rtjson routing. The is routed but the thing
> is that the record route is being set with the private one (It's the same
> when calls come from public and is routed to a private network, record
> route has the public and not the private).
>
> With mhomed configured shouldn't Record Route be updated as VIA header
>
> ".... When activated, sip-router will select a socket that can reach the
> destination (to be able to connect to the remote address). (sip-router
> opens a UDP socket to the destination, then it retrieves the local IP which
> was assigned by the operating system to the new UDP socket. Then this
> socket will be closed and the retrieved IP address will be used as IP
> address in the Via/Record-Route headers)..."
>
> This is part of ngrep
>
> U 2016/12/22 11:24:15.019643 172.16.213.21:5060 -> 172.16.213.38:5060
> INVITE sip:11111111111 at 172.16.213.38:5060 SIP/2.0.
> Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-13024-1-0.
> From: "Test" <sip:2222222222 at 172.16.213.21:5060;user=phone>;tag=1.
> To: <sip:1111111111 at 172.16.213.38:5060>.
> Call-ID: 1-13024 at 172.16.213.21.
> CSeq: 1 INVITE.
> Contact: "2222222222 <sip:2222222222 at 172.16.213.21:5060>.
> ....
>
> U 2016/12/22 11:24:15.023923 172.16.213.38:5060 -> 172.16.213.21:5060
> SIP/2.0 100 trying -- your call is important to us.
> Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-13024-1-0.
> ....
>
> U 2016/12/22 11:24:15.038695 XXX.XXX.XXX.01:5060 -> XXX.XXX.XXX.02:5060
> INVITE sip:1111111111 <011%201111-1111>@XXX.XXX.XXX.02:5060 SIP/2.0.
> *-----> Record-Route: <sip:172.16.213.38;lr;ftag=1;did=1111>. <----*
> Via: SIP/2.0/UDP XXX.XXX.XXX.01;branch=z9hG4bKc09f
> Via: SIP/2.0/UDP 127.0.0.8;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.NLOBF6
>
> This is my cfg
>
> mhomed=1
>
> request_route {
>
>
>         # per request initial checks
>         route(REQINIT);
>
>         # NAT detection
>         #route(NATDETECT);
>
>         # CANCEL processing
>         if (is_method("CANCEL")) {
>                 if (t_check_trans()) {
>                         route(RELAY);
>                 }
>                 exit;
>         }
>
>         # handle requests within SIP dialogs
>         route(WITHINDLG);
>
>         ### only initial requests (no To tag)
>
>         # handle retransmissions
>         if(t_precheck_trans()) {
>                 t_check_trans();
>                 exit;
>         }
>         t_check_trans();
>
>         # authentication
>         route(AUTH);
>
>         # record routing for dialog forming requests (in case they are
> routed)
>         # - remove preloaded route headers
>         remove_hf("Route");
>         if (is_method("INVITE|SUBSCRIBE")) {
>                 record_route();
>         }
>
>
> Thanks in advance.
>
> Diego.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20161222/c7562255/attachment.html>


More information about the sr-users mailing list