UPDATE relayed from wrong socket

List overview All Threads
Download

newer

older

Dialog variables and persistence

Distorted uri / Route header...

Sergiu Pojoga

11 Oct 2018 11 Oct '18

7:03 p.m.

Hi ppl,

I have this problem with call transfer, may be someone can help.

The phone to the far right is registered with the Registrar to the far left using two PATH headers (trespassing two proxy ports, 5070 then 5060).

As you can see in the graph below, after receiving the UPDATE request, Kamailio relays it further from port 5060, I expect it to be from 5070 just like the dialog forming INVITE and the CANCEL afterwards.

[image: image.png]

The UPDATE has a to-tag, but unlike the original INVITE - it has no Route header!???

route[*WITHINDLG*] { if (!has_totag()) return; if (loose_route()) { route(DLGURI); if (is_method("BYE")) {

...

} else if ( is_method("ACK") ) { route(NATMANAGE); } else if ( is_method("NOTIFY") ) { record_route(); }

route(RELAY); exit; }

if ( is_method("ACK") ) {

...

}

# handle UPDATE method for in-dialog requests if (is_method("*UPDATE*")) { route(DLGURI); record_route(); route(RELAY); } }

Thanks in advance.

Attachments:

attachment.html (text/html — 3.0 KB)
image.png (image/png — 20.5 KB)

Show replies by date

Daniel-Constantin Mierla

12 Oct 12 Oct

1:38 p.m.

Hello,

you hve to provide the sip traffic for this case, the screenshot doesn't show the sip headers used for routing in this case, therefore grab the sip traffic for all sip messages in such scenarion, either ngrep output or pcap file, and send it over to see if some headers are missing or not set properly.

Cheers, Daniel

On 11.10.18 21:03, Sergiu Pojoga wrote:

...

Hi ppl,

I have this problem with call transfer, may be someone can help.

The phone to the far right is registered with the Registrar to the far left using two PATH headers (trespassing two proxy ports, 5070 then 5060).

As you can see in the graph below, after receiving the UPDATE request, Kamailio relays it further from port 5060, I expect it to be from 5070 just like the dialog forming INVITE and the CANCEL afterwards.

image.png

The UPDATE has a to-tag, but unlike the original INVITE - it has no Route header!???

route[*WITHINDLG*] { if (!has_totag()) return; if (loose_route()) { route(DLGURI); if (is_method("BYE")) {
    ...
} else if ( is_method("ACK") ) { route(NATMANAGE); } else if ( is_method("NOTIFY") ) { record_route(); }

route(RELAY); exit; }

if ( is_method("ACK") ) {
...
}

# handle UPDATE method for in-dialog requests if (is_method("*UPDATE*")) { route(DLGURI); record_route(); route(RELAY); } }

Thanks in advance.

Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

Sergiu Pojoga

2:53 p.m.

Hi Daniel,

Certainly, below find the initial INVITE and the subsequent UPDATE, as received by Kamailio@65.xx.xx.167. If those aren't sufficient, let me know and if it's ok with you, I'll send the full pcap in private.

The dilemma in my mind is whether the UPDATE should have a pre-set Route header, similar to how the INVITE has.

2018/10/11 12:34:57.339306 65.xx.xx.172:5060 -> 65.xx.xx.167:5060

INVITE sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b SIP/2.0

Via: SIP/2.0/UDP 65.xx.xx.172:5060;branch=z9hG4bK694382a1

Max-Forwards: 70

Route: sip:65.xx.xx.167;lr;received=sip:65.xx.xx.161:64877;r2=on,sip:xx.xx.xx.167:5070;lr;received=sip:65.xx.xx.161:64877;r2=on

From: "Robert" sip:226@mypbx.net;tag=as0ecef1c4

To: sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b

Contact: sip:226@65.xx.xx.172:5060

Call-ID: 1e82197b42f0173b25e70759753d4210@mypbx.net

CSeq: 102 INVITE

Supported: replaces, timer, path

Content-Type: application/sdp

Content-Length: 386

2018/10/11 12:35:06.096457 65.xx.xx.172:5060 -> 65.xx.xx.167:5060

UPDATE sip:238@10.17.0.35:64877;alias=65.xx.xx.161~64877~1 SIP/2.0

Via: SIP/2.0/UDP 65.xx.xx.172:5060;branch=z9hG4bK34fab05c

Max-Forwards: 70

From: "Robert" sip:226@mypbx.net;tag=as0ecef1c4

To: sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b;tag=6467b07f

Contact: sip:226@65.xx.xx.172:5060

Call-ID: 1e82197b42f0173b25e70759753d4210@mypbx.net

CSeq: 103 UPDATE

Content-Length: 0

Much obliged.

On Fri, Oct 12, 2018 at 9:38 AM Daniel-Constantin Mierla miconda@gmail.com wrote:

...

Hello,

you hve to provide the sip traffic for this case, the screenshot doesn't show the sip headers used for routing in this case, therefore grab the sip traffic for all sip messages in such scenarion, either ngrep output or pcap file, and send it over to see if some headers are missing or not set properly. Cheers, Daniel

On 11.10.18 21:03, Sergiu Pojoga wrote:

Hi ppl,

I have this problem with call transfer, may be someone can help.

The phone to the far right is registered with the Registrar to the far left using two PATH headers (trespassing two proxy ports, 5070 then 5060).

As you can see in the graph below, after receiving the UPDATE request, Kamailio relays it further from port 5060, I expect it to be from 5070 just like the dialog forming INVITE and the CANCEL afterwards.

[image: image.png]

The UPDATE has a to-tag, but unlike the original INVITE - it has no Route header!???

route[*WITHINDLG*] { if (!has_totag()) return; if (loose_route()) { route(DLGURI); if (is_method("BYE")) {

...

} else if ( is_method("ACK") ) { route(NATMANAGE); } else if ( is_method("NOTIFY") ) { record_route(); }

route(RELAY); exit; }

if ( is_method("ACK") ) {

...

}

# handle UPDATE method for in-dialog requests if (is_method("*UPDATE*")) { route(DLGURI); record_route(); route(RELAY); } }

Thanks in advance.

Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

Daniel-Constantin Mierla

15 Oct 15 Oct

6:34 a.m.

Hello,

that seems to be a re-INVITE (has To-tag). I would need at least the initial INVITE and the 200ok, along with the UPDATE request.

If the UPDATE is after the re-INVITE, it is missing the Route header as in the re-INVITE.

Cheers, Daniel

On 12.10.18 16:53, Sergiu Pojoga wrote:

...

Hi Daniel,

Certainly, below find the initial INVITE and the subsequent UPDATE, as received by Kamailio@65.xx.xx.167. If those aren't sufficient, let me know and if it's ok with you, I'll send the full pcap in private.

The dilemma in my mind is whether the UPDATE should have a pre-set Route header, similar to how the INVITE has.

2018/10/11 12:34:57.339306 65.xx.xx.172:5060 -> 65.xx.xx.167:5060 INVITE sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b SIP/2.0 Via: SIP/2.0/UDP 65.xx.xx.172:5060;branch=z9hG4bK694382a1 Max-Forwards: 70 Route: sip:65.xx.xx.167;lr;received=sip:65.xx.xx.161:64877;r2=on,sip:xx.xx.xx.167:5070;lr;received=sip:65.xx.xx.161:64877;r2=on From: "Robert" <sip:226@mypbx.net mailto:sip%3A226@mypbx.net>;tag=as0ecef1c4 To: sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b Contact: sip:226@65.xx.xx.172:5060 Call-ID: 1e82197b42f0173b25e70759753d4210@mypbx.net mailto:1e82197b42f0173b25e70759753d4210@mypbx.net CSeq: 102 INVITE Supported: replaces, timer, path Content-Type: application/sdp Content-Length: 386

2018/10/11 12:35:06.096457 65.xx.xx.172:5060 -> 65.xx.xx.167:5060 UPDATE sip:238@10.17.0.35:64877;alias=65.xx.xx.161~64877~1 SIP/2.0 Via: SIP/2.0/UDP 65.xx.xx.172:5060;branch=z9hG4bK34fab05c Max-Forwards: 70 From: "Robert" <sip:226@mypbx.net mailto:sip%3A226@mypbx.net>;tag=as0ecef1c4 To: sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b;tag=6467b07f Contact: sip:226@65.xx.xx.172:5060 Call-ID: 1e82197b42f0173b25e70759753d4210@mypbx.net mailto:1e82197b42f0173b25e70759753d4210@mypbx.net CSeq: 103 UPDATE Content-Length: 0

Much obliged.

On Fri, Oct 12, 2018 at 9:38 AM Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello,

you hve to provide the sip traffic for this case, the screenshot
doesn't show the sip headers used for routing in this case,
therefore grab the sip traffic for all sip messages in such
scenarion, either ngrep output or pcap file, and send it over to
see if some headers are missing or not set properly.

Cheers,
Daniel

On 11.10.18 21:03, Sergiu Pojoga wrote:
...
Hi ppl,

I have this problem with call transfer, may be someone can help.

The phone to the far right is registered with the Registrar to
the far left using two PATH headers (trespassing two proxy ports,
5070 then 5060).

As you can see in the graph below, after receiving the UPDATE
request, Kamailio relays it further from port 5060, I expect it
to be from 5070 just like the dialog forming INVITE and the
CANCEL afterwards.

image.png

The UPDATE has a to-tag, but unlike the original INVITE - it has
no Route header!???

route[*WITHINDLG*] {
if (!has_totag()) return;
if (loose_route()) {
route(DLGURI);
if (is_method("BYE")) {

        ...

}
else if ( is_method("ACK") ) {
route(NATMANAGE);
}
else if ( is_method("NOTIFY") ) {
record_route();
} 

route(RELAY);
exit;
}

if ( is_method("ACK") ) {

    ...

}

# handle UPDATE method for in-dialog requests
if (is_method("*UPDATE*")) {
route(DLGURI);
record_route();
route(RELAY);
}
}

Thanks in advance.



_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- 
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio World Conference -- www.kamailioworld.com <http://www.kamailioworld.com>
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com <http://www.asipto.com>

Sergiu Pojoga

2 p.m.

Hi again,

Hmm... I don't see a To-tag in the INVITE, neither there's a 200OK to provide because the UPDATE was sent out prior to the callee answering the call.

If there should be a Route header in the UPDATE, it would it indicate a bug with Asterisk firing off the UPDATE without a pre-set Route dictated by the Path?

If that's the case, I suppose my options are:

1. reach out to Asterisk to investigate and fix it (unrealistic) 2. store the Route header from the initial INVITE in a AVP and insert it later if an UPDATE follows. Would that break anything up?

Any other constructive suggestions?

Thanks.

On Mon, Oct 15, 2018 at 2:34 AM Daniel-Constantin Mierla miconda@gmail.com wrote:

...

Hello,

that seems to be a re-INVITE (has To-tag). I would need at least the initial INVITE and the 200ok, along with the UPDATE request.

If the UPDATE is after the re-INVITE, it is missing the Route header as in the re-INVITE.

Cheers, Daniel

On 12.10.18 16:53, Sergiu Pojoga wrote:

Hi Daniel,

Certainly, below find the initial INVITE and the subsequent UPDATE, as received by Kamailio@65.xx.xx.167. If those aren't sufficient, let me know and if it's ok with you, I'll send the full pcap in private.

The dilemma in my mind is whether the UPDATE should have a pre-set Route header, similar to how the INVITE has.

2018/10/11 12:34:57.339306 65.xx.xx.172:5060 -> 65.xx.xx.167:5060

INVITE sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b SIP/2.0

Via: SIP/2.0/UDP 65.xx.xx.172:5060;branch=z9hG4bK694382a1

Max-Forwards: 70

Route: sip:65.xx.xx.167;lr;received=sip:65.xx.xx.161:64877;r2=on, sip:xx.xx.xx.167:5070;lr;received=sip:65.xx.xx.161:64877;r2=on

From: "Robert" sip:226@mypbx.net;tag=as0ecef1c4

To: sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b

Contact: sip:226@65.xx.xx.172:5060

Call-ID: 1e82197b42f0173b25e70759753d4210@mypbx.net

CSeq: 102 INVITE
              Supported: replaces, timer, path
Content-Type: application/sdp

Content-Length: 386

2018/10/11 12:35:06.096457 65.xx.xx.172:5060 -> 65.xx.xx.167:5060

UPDATE sip:238@10.17.0.35:64877;alias=65.xx.xx.161~64877~1 SIP/2.0

Via: SIP/2.0/UDP 65.xx.xx.172:5060;branch=z9hG4bK34fab05c

Max-Forwards: 70

From: "Robert" sip:226@mypbx.net;tag=as0ecef1c4

To: sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b;tag=6467b07f

Contact: sip:226@65.xx.xx.172:5060

Call-ID: 1e82197b42f0173b25e70759753d4210@mypbx.net

CSeq: 103 UPDATE

Content-Length: 0

Much obliged.

On Fri, Oct 12, 2018 at 9:38 AM Daniel-Constantin Mierla < miconda@gmail.com> wrote:

...
Hello,

you hve to provide the sip traffic for this case, the screenshot doesn't show the sip headers used for routing in this case, therefore grab the sip traffic for all sip messages in such scenarion, either ngrep output or pcap file, and send it over to see if some headers are missing or not set properly. Cheers, Daniel

On 11.10.18 21:03, Sergiu Pojoga wrote:

Hi ppl,

I have this problem with call transfer, may be someone can help.

The phone to the far right is registered with the Registrar to the far left using two PATH headers (trespassing two proxy ports, 5070 then 5060).

As you can see in the graph below, after receiving the UPDATE request, Kamailio relays it further from port 5060, I expect it to be from 5070 just like the dialog forming INVITE and the CANCEL afterwards.

[image: image.png]

The UPDATE has a to-tag, but unlike the original INVITE - it has no Route header!???

route[*WITHINDLG*] { if (!has_totag()) return; if (loose_route()) { route(DLGURI); if (is_method("BYE")) {

...

} else if ( is_method("ACK") ) { route(NATMANAGE); } else if ( is_method("NOTIFY") ) { record_route(); }

route(RELAY); exit; }

if ( is_method("ACK") ) {

...

}

# handle UPDATE method for in-dialog requests if (is_method("*UPDATE*")) { route(DLGURI); record_route(); route(RELAY); } }

Thanks in advance.

Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

Daniel-Constantin Mierla

4:15 p.m.

Hello,

indeed, I was misled by the Route headers in INVITE, which looked like inside a dialog, but the parameter in To header is rinstance.

Is there any 18x response?

Cheers, Daniel

On 15.10.18 16:00, Sergiu Pojoga wrote:

...

Hi again,

Hmm... I don't see a To-tag in the INVITE, neither there's a 200OK to provide because the UPDATE was sent out prior to the callee answering the call.

If there should be a Route header in the UPDATE, it would it indicate a bug with Asterisk firing off the UPDATE without a pre-set Route dictated by the Path?

If that's the case, I suppose my options are:

reach out to Asterisk to investigate and fix it (unrealistic)
store the Route header from the initial INVITE in a AVP and insert it later if an UPDATE follows. Would that break anything up?

Any other constructive suggestions?

Thanks.

On Mon, Oct 15, 2018 at 2:34 AM Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:

Hello,

that seems to be a re-INVITE (has To-tag). I would need at least
the initial INVITE and the 200ok, along with the UPDATE request.

If the UPDATE is after the re-INVITE, it is missing the Route
header as in the re-INVITE.

Cheers,
Daniel


On 12.10.18 16:53, Sergiu Pojoga wrote:

...

Hi Daniel,

Certainly, below find the initial INVITE and the subsequent
UPDATE, as received by Kamailio@65.xx.xx.167
<mailto:Kamailio@65.xx.xx.167>. If those aren't sufficient, let
me know and if it's ok with you, I'll send the full pcap in private.

The dilemma in my mind is whether the UPDATE should have a
pre-set Route header, similar to how the INVITE has. 

2018/10/11 12:34:57.339306 65.xx.xx.172:5060 ->
65.xx.xx.167:5060                                               
                                                                 
                                                   
INVITE sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b
SIP/2.0                                                         
                                                                 
                                       
Via: SIP/2.0/UDP 65.xx.xx.172:5060;branch=z9hG4bK694382a1       
                                                                 
                                                                 
                                  
Max-Forwards: 70                                                 
                                                                 
                                                                 
                                  
Route:
<sip:65.xx.xx.167;lr;received=sip:65.xx.xx.161:64877;r2=on>,<sip:xx.xx.xx.167:5070;lr;received=sip:65.xx.xx.161:64877;r2=on> 
                                                                 
                             
From: "Robert" <sip:226@mypbx.net
<mailto:sip%3A226@mypbx.net>>;tag=as0ecef1c4                     
                                                                 
                                                                 
     
To: <sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b>     
                                                                 
                                                                 
                                  
Contact: <sip:226@65.xx.xx.172:5060>                             
                                                                 
                                                                 
                                 
Call-ID: 1e82197b42f0173b25e70759753d4210@mypbx.net
<mailto:1e82197b42f0173b25e70759753d4210@mypbx.net>             
                                                                 
                                                                 
                  
CSeq: 102 INVITE                                                 
                                                                 
                                                                 
                                                                 
                                                                 
                                                                 
Supported: replaces, timer, path                                 
                                                                 
                                                                 
                                                                 
                                                                 
                                                          
Content-Type: application/sdp                                   
                                                                 
                                                                 
                                   
Content-Length: 386


2018/10/11 12:35:06.096457 65.xx.xx.172:5060 ->
65.xx.xx.167:5060                                               
                                                                 
                                                   
UPDATE sip:238@10.17.0.35:64877;alias=65.xx.xx.161~64877~1
SIP/2.0                                                         
                                                                 
                                         
Via: SIP/2.0/UDP 65.xx.xx.172:5060;branch=z9hG4bK34fab05c       
                                                                 
                                                                 
                                  
Max-Forwards: 70                                                 
                                                                 
                                                                 
                                  
From: "Robert" <sip:226@mypbx.net
<mailto:sip%3A226@mypbx.net>>;tag=as0ecef1c4                     
                                                                 
                                                                 
     
To:
<sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b>;tag=6467b07f 
                                                                 
                                                                 
                         
Contact: <sip:226@65.xx.xx.172:5060>                             
                                                                 
                                                                 
                                 
Call-ID: 1e82197b42f0173b25e70759753d4210@mypbx.net
<mailto:1e82197b42f0173b25e70759753d4210@mypbx.net>             
                                                                 
                                                                 
                  
CSeq: 103 UPDATE                                                 
                                                                 
                                                                 
                                  
Content-Length: 0 

Much obliged.

On Fri, Oct 12, 2018 at 9:38 AM Daniel-Constantin Mierla
<miconda@gmail.com <mailto:miconda@gmail.com>> wrote:

    Hello,

    you hve to provide the sip traffic for this case, the
    screenshot doesn't show the sip headers used for routing in
    this case, therefore grab the sip traffic for all sip
    messages in such scenarion, either ngrep output or pcap file,
    and send it over to see if some headers are missing or not
    set properly.

    Cheers,
    Daniel

    On 11.10.18 21:03, Sergiu Pojoga wrote:

...

    Hi ppl,

    I have this problem with call transfer, may be someone can help.

    The phone to the far right is registered with the Registrar
    to the far left using two PATH headers (trespassing two
    proxy ports, 5070 then 5060).

    As you can see in the graph below, after receiving the
    UPDATE request, Kamailio relays it further from port 5060, I
    expect it to be from 5070 just like the dialog forming
    INVITE and the CANCEL afterwards.

    image.png

    The UPDATE has a to-tag, but unlike the original INVITE - it
    has no Route header!???

    route[*WITHINDLG*] {
    if (!has_totag()) return;
    if (loose_route()) {
    route(DLGURI);
    if (is_method("BYE")) {

            ...

    }
    else if ( is_method("ACK") ) {
    route(NATMANAGE);
    }
    else if ( is_method("NOTIFY") ) {
    record_route();
    } 

    route(RELAY);
    exit;
    }

    if ( is_method("ACK") ) {

        ...

    }

    # handle UPDATE method for in-dialog requests
    if (is_method("*UPDATE*")) {
    route(DLGURI);
    record_route();
    route(RELAY);
    }
    }

    Thanks in advance.



    _______________________________________________
    Kamailio (SER) - Users Mailing List
    sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
    https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

    -- 
    Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
    www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
    Kamailio World Conference -- www.kamailioworld.com <http://www.kamailioworld.com>
    Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com <http://www.asipto.com>

-- 
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio World Conference -- www.kamailioworld.com <http://www.kamailioworld.com>
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com <http://www.asipto.com>

Sergiu Pojoga

4:33 p.m.

Yes there was a 180 reply from the Callee.

2018/10/11 12:34:57.535510 65.xx.xx.161:64877 -> 65.xx.xx.167:5070 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 65.xx.xx.167:5070;branch=z9hG4bK98e3.3392254b0b2d98dfc66f12cb7fdba746.0 Via: SIP/2.0/UDP 65.xx.xx.172:5060;rport=5060;branch=z9hG4bK694382a1 Record-Route: sip:65.xx.xx.167:5070;r2=on;lr=on;did=bbf.658 Record-Route: sip:65.xx.xx.167;r2=on;lr=on;did=bbf.658 Contact: sip:238@10.17.0.35:64877 To: "John"sip:238@65.xx.xx.161 :64877;rinstance=8a315091627cc10b;tag=6467b07f From: "Robert" sip:226@mypbx.net;tag=as0ecef1c4 Call-ID: 1e82197b42f0173b25e70759753d4210@mypbx.net CSeq: 102 INVITE User-Agent: Bria 4 release 4.8.1 stamp 84929 Allow-Events: talk, hold Content-Length: 0

2018/10/11 12:34:57.535631 65.xx.xx.167:5060 -> 65.xx.xx.172:5060 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 65.xx.xx.172:5060;rport=5060;branch=z9hG4bK694382a1 Record-Route: sip:65.xx.xx.167:5070;r2=on;lr=on;did=bbf.658 Record-Route: sip:65.xx.xx.167;r2=on;lr=on;did=bbf.658 Contact: sip:238@10.17.0.35:64877;alias=65.xx.xx.161~64877~1 To: "John"sip:238@65.xx.xx.161 :64877;rinstance=8a315091627cc10b;tag=6467b07f From: "Robert" sip:226@mypbx.net;tag=as0ecef1c4 Call-ID: 1e82197b42f0173b25e70759753d4210@mypbx.net CSeq: 102 INVITE Allow-Events: talk, hold Content-Length: 0

On Mon, Oct 15, 2018 at 12:15 PM Daniel-Constantin Mierla miconda@gmail.com wrote:

...

Hello,

indeed, I was misled by the Route headers in INVITE, which looked like inside a dialog, but the parameter in To header is rinstance.

Is there any 18x response?

Cheers, Daniel

On 15.10.18 16:00, Sergiu Pojoga wrote:

Hi again,

Hmm... I don't see a To-tag in the INVITE, neither there's a 200OK to provide because the UPDATE was sent out prior to the callee answering the call.

If there should be a Route header in the UPDATE, it would it indicate a bug with Asterisk firing off the UPDATE without a pre-set Route dictated by the Path?

If that's the case, I suppose my options are:

reach out to Asterisk to investigate and fix it (unrealistic)

store the Route header from the initial INVITE in a AVP and insert

it later if an UPDATE follows. Would that break anything up?

Any other constructive suggestions?

Thanks.

On Mon, Oct 15, 2018 at 2:34 AM Daniel-Constantin Mierla < miconda@gmail.com> wrote:

...
Hello,

that seems to be a re-INVITE (has To-tag). I would need at least the initial INVITE and the 200ok, along with the UPDATE request.

If the UPDATE is after the re-INVITE, it is missing the Route header as in the re-INVITE.

Cheers, Daniel

On 12.10.18 16:53, Sergiu Pojoga wrote:

Hi Daniel,

Certainly, below find the initial INVITE and the subsequent UPDATE, as received by Kamailio@65.xx.xx.167. If those aren't sufficient, let me know and if it's ok with you, I'll send the full pcap in private.

The dilemma in my mind is whether the UPDATE should have a pre-set Route header, similar to how the INVITE has.

2018/10/11 12:34:57.339306 65.xx.xx.172:5060 -> 65.xx.xx.167:5060

INVITE sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b SIP/2.0

Via: SIP/2.0/UDP 65.xx.xx.172:5060;branch=z9hG4bK694382a1

Max-Forwards: 70

Route: sip:65.xx.xx.167;lr;received=sip:65.xx.xx.161:64877;r2=on, sip:xx.xx.xx.167:5070;lr;received=sip:65.xx.xx.161:64877;r2=on

From: "Robert" sip:226@mypbx.net;tag=as0ecef1c4

To: sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b

Contact: sip:226@65.xx.xx.172:5060

Call-ID: 1e82197b42f0173b25e70759753d4210@mypbx.net

CSeq: 102 INVITE
              Supported: replaces, timer, path
Content-Type: application/sdp

Content-Length: 386

2018/10/11 12:35:06.096457 65.xx.xx.172:5060 -> 65.xx.xx.167:5060

UPDATE sip:238@10.17.0.35:64877;alias=65.xx.xx.161~64877~1 SIP/2.0

Via: SIP/2.0/UDP 65.xx.xx.172:5060;branch=z9hG4bK34fab05c

Max-Forwards: 70

From: "Robert" sip:226@mypbx.net;tag=as0ecef1c4

To: sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b;tag=6467b07f

Contact: sip:226@65.xx.xx.172:5060

Call-ID: 1e82197b42f0173b25e70759753d4210@mypbx.net

CSeq: 103 UPDATE

Content-Length: 0

Much obliged.

On Fri, Oct 12, 2018 at 9:38 AM Daniel-Constantin Mierla < miconda@gmail.com> wrote:

...
Hello,

you hve to provide the sip traffic for this case, the screenshot doesn't show the sip headers used for routing in this case, therefore grab the sip traffic for all sip messages in such scenarion, either ngrep output or pcap file, and send it over to see if some headers are missing or not set properly. Cheers, Daniel

On 11.10.18 21:03, Sergiu Pojoga wrote:

Hi ppl,

I have this problem with call transfer, may be someone can help.

The phone to the far right is registered with the Registrar to the far left using two PATH headers (trespassing two proxy ports, 5070 then 5060).

As you can see in the graph below, after receiving the UPDATE request, Kamailio relays it further from port 5060, I expect it to be from 5070 just like the dialog forming INVITE and the CANCEL afterwards.

[image: image.png]

The UPDATE has a to-tag, but unlike the original INVITE - it has no Route header!???

route[*WITHINDLG*] { if (!has_totag()) return; if (loose_route()) { route(DLGURI); if (is_method("BYE")) {

...

} else if ( is_method("ACK") ) { route(NATMANAGE); } else if ( is_method("NOTIFY") ) { record_route(); }

route(RELAY); exit; }

if ( is_method("ACK") ) {

...

}

# handle UPDATE method for in-dialog requests if (is_method("*UPDATE*")) { route(DLGURI); record_route(); route(RELAY); } }

Thanks in advance.

Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

Daniel-Constantin Mierla

5:57 p.m.

Then the UPDATE either has to follow the Record-Route stack received in 180, or be constructed like the initial INVITE with pre-loaded Route set.

I don't have the time to check the SIP specs right now, but by reusing the Call-Id and From-tag and increasing the CSeq, this is more like a request within dialog, but it doesn't use the To-tag from 180 and no Route headers. So something needs to be fixed inside the UA, the proxy is just following the routing headers that are present in the request.

Cheers, Daniel

On 15.10.18 18:33, Sergiu Pojoga wrote:

...

Yes there was a 180 reply from the Callee.

2018/10/11 12:34:57.535510 65.xx.xx.161:64877 -> 65.xx.xx.167:5070 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 65.xx.xx.167:5070;branch=z9hG4bK98e3.3392254b0b2d98dfc66f12cb7fdba746.0 Via: SIP/2.0/UDP 65.xx.xx.172:5060;rport=5060;branch=z9hG4bK694382a1 Record-Route: sip:65.xx.xx.167:5070;r2=on;lr=on;did=bbf.658 Record-Route: sip:65.xx.xx.167;r2=on;lr=on;did=bbf.658 Contact: <sip:238@10.17.0.35:64877 http://sip:238@10.17.0.35:64877> To: "John"sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b;tag=6467b07f From: "Robert" <sip:226@mypbx.net mailto:sip%3A226@mypbx.net>;tag=as0ecef1c4 Call-ID: 1e82197b42f0173b25e70759753d4210@mypbx.net mailto:1e82197b42f0173b25e70759753d4210@mypbx.net CSeq: 102 INVITE User-Agent: Bria 4 release 4.8.1 stamp 84929 Allow-Events: talk, hold Content-Length: 0

2018/10/11 12:34:57.535631 65.xx.xx.167:5060 -> 65.xx.xx.172:5060 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 65.xx.xx.172:5060;rport=5060;branch=z9hG4bK694382a1 Record-Route: sip:65.xx.xx.167:5070;r2=on;lr=on;did=bbf.658 Record-Route: sip:65.xx.xx.167;r2=on;lr=on;did=bbf.658 Contact: sip:238@10.17.0.35:64877;alias=65.xx.xx.161~64877~1 To: "John"sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b;tag=6467b07f From: "Robert" <sip:226@mypbx.net mailto:sip%3A226@mypbx.net>;tag=as0ecef1c4 Call-ID: 1e82197b42f0173b25e70759753d4210@mypbx.net mailto:1e82197b42f0173b25e70759753d4210@mypbx.net CSeq: 102 INVITE Allow-Events: talk, hold Content-Length: 0

On Mon, Oct 15, 2018 at 12:15 PM Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:

Hello,

indeed, I was misled by the Route headers in INVITE, which looked
like inside a dialog, but the parameter in To header is rinstance.

Is there any 18x response?

Cheers,
Daniel


On 15.10.18 16:00, Sergiu Pojoga wrote:

...

Hi again,

Hmm... I don't see a To-tag in the INVITE, neither there's a
200OK to provide because the UPDATE was sent out prior to the
callee answering the call.

If there should be a Route header in the UPDATE, it would it
indicate a bug with Asterisk firing off the UPDATE without a
pre-set Route dictated by the Path?

If that's the case, I suppose my options are:

 1. reach out to Asterisk to investigate and fix it (unrealistic)
 2. store the Route header from the initial INVITE in a AVP and
    insert it later if an UPDATE follows. Would that break
    anything up?

Any other constructive suggestions?

Thanks.

On Mon, Oct 15, 2018 at 2:34 AM Daniel-Constantin Mierla
<miconda@gmail.com <mailto:miconda@gmail.com>> wrote:

    Hello,

    that seems to be a re-INVITE (has To-tag). I would need at
    least the initial INVITE and the 200ok, along with the UPDATE
    request.

    If the UPDATE is after the re-INVITE, it is missing the Route
    header as in the re-INVITE.

    Cheers,
    Daniel


    On 12.10.18 16:53, Sergiu Pojoga wrote:

...

    Hi Daniel,

    Certainly, below find the initial INVITE and the subsequent
    UPDATE, as received by Kamailio@65.xx.xx.167
    <mailto:Kamailio@65.xx.xx.167>. If those aren't sufficient,
    let me know and if it's ok with you, I'll send the full pcap
    in private.

    The dilemma in my mind is whether the UPDATE should have a
    pre-set Route header, similar to how the INVITE has. 

    2018/10/11 12:34:57.339306 65.xx.xx.172:5060 ->
    65.xx.xx.167:5060                                           
                                                               
                                                                 
    INVITE sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b
    SIP/2.0                                                     
                                                               
                                                     
    Via: SIP/2.0/UDP 65.xx.xx.172:5060;branch=z9hG4bK694382a1   
                                                               
                                                               
                                                      
    Max-Forwards: 70                                           
                                                               
                                                               
                                                        
    Route:
    <sip:65.xx.xx.167;lr;received=sip:65.xx.xx.161:64877;r2=on>,<sip:xx.xx.xx.167:5070;lr;received=sip:65.xx.xx.161:64877;r2=on> 
                                                               
                                       
    From: "Robert" <sip:226@mypbx.net
    <mailto:sip%3A226@mypbx.net>>;tag=as0ecef1c4               
                                                               
                                                               
                           
    To: <sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b> 
                                                               
                                                               
                                                      
    Contact: <sip:226@65.xx.xx.172:5060>                       
                                                               
                                                               
                                                       
    Call-ID: 1e82197b42f0173b25e70759753d4210@mypbx.net
    <mailto:1e82197b42f0173b25e70759753d4210@mypbx.net>         
                                                               
                                                               
                                      
    CSeq: 102 INVITE                                           
                                                               
                                                               
                                                               
                                                               
                                                               
                                        Supported: replaces,
    timer, path                                                 
                                                               
                                                               
                                                               
                                                               
                                                               
          
    Content-Type: application/sdp                               
                                                               
                                                               
                                                       
    Content-Length: 386


    2018/10/11 12:35:06.096457 65.xx.xx.172:5060 ->
    65.xx.xx.167:5060                                           
                                                               
                                                                 
    UPDATE sip:238@10.17.0.35:64877;alias=65.xx.xx.161~64877~1
    SIP/2.0                                                     
                                                               
                                                       
    Via: SIP/2.0/UDP 65.xx.xx.172:5060;branch=z9hG4bK34fab05c   
                                                               
                                                               
                                                      
    Max-Forwards: 70                                           
                                                               
                                                               
                                                        
    From: "Robert" <sip:226@mypbx.net
    <mailto:sip%3A226@mypbx.net>>;tag=as0ecef1c4               
                                                               
                                                               
                           
    To:
    <sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b>;tag=6467b07f 
                                                               
                                                               
                                         
    Contact: <sip:226@65.xx.xx.172:5060>                       
                                                               
                                                               
                                                       
    Call-ID: 1e82197b42f0173b25e70759753d4210@mypbx.net
    <mailto:1e82197b42f0173b25e70759753d4210@mypbx.net>         
                                                               
                                                               
                                      
    CSeq: 103 UPDATE                                           
                                                               
                                                               
                                                        
    Content-Length: 0 

    Much obliged.

    On Fri, Oct 12, 2018 at 9:38 AM Daniel-Constantin Mierla
    <miconda@gmail.com <mailto:miconda@gmail.com>> wrote:

        Hello,

        you hve to provide the sip traffic for this case, the
        screenshot doesn't show the sip headers used for routing
        in this case, therefore grab the sip traffic for all sip
        messages in such scenarion, either ngrep output or pcap
        file, and send it over to see if some headers are
        missing or not set properly.

        Cheers,
        Daniel

        On 11.10.18 21:03, Sergiu Pojoga wrote:

...

        Hi ppl,

        I have this problem with call transfer, may be someone
        can help.

        The phone to the far right is registered with the
        Registrar to the far left using two PATH headers
        (trespassing two proxy ports, 5070 then 5060).

        As you can see in the graph below, after receiving the
        UPDATE request, Kamailio relays it further from port
        5060, I expect it to be from 5070 just like the dialog
        forming INVITE and the CANCEL afterwards.

        image.png

        The UPDATE has a to-tag, but unlike the original INVITE
        - it has no Route header!???

        route[*WITHINDLG*] {
        if (!has_totag()) return;
        if (loose_route()) {
        route(DLGURI);
        if (is_method("BYE")) {

                ...

        }
        else if ( is_method("ACK") ) {
        route(NATMANAGE);
        }
        else if ( is_method("NOTIFY") ) {
        record_route();
        } 

        route(RELAY);
        exit;
        }

        if ( is_method("ACK") ) {

            ...

        }

        # handle UPDATE method for in-dialog requests
        if (is_method("*UPDATE*")) {
        route(DLGURI);
        record_route();
        route(RELAY);
        }
        }

        Thanks in advance.



        _______________________________________________
        Kamailio (SER) - Users Mailing List
        sr-users@lists.kamailio.org
        <mailto:sr-users@lists.kamailio.org>
        https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

        -- 
        Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
        www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda
        <http://www.linkedin.com/in/miconda>
        Kamailio World Conference -- www.kamailioworld.com <http://www.kamailioworld.com>
        Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com <http://www.asipto.com>

    -- 
    Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
    www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
    Kamailio World Conference -- www.kamailioworld.com <http://www.kamailioworld.com>
    Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com <http://www.asipto.com>

-- 
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio World Conference -- www.kamailioworld.com <http://www.kamailioworld.com>
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com <http://www.asipto.com>

2337

Age (days ago)

2341

Last active (days ago)

sr-users@lists.kamailio.org

7 comments

2 participants

tags (0)

participants (2)

Daniel-Constantin Mierla
Sergiu Pojoga