[SR-Users] UPDATE relayed from wrong socket

[Sergiu Pojoga]

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 at 10.17.0.35:64877>
To: "John"<sip:238 at 65.xx.xx.161
:64877;rinstance=8a315091627cc10b>;tag=6467b07f
From: "Robert" <sip:226 at mypbx.net>;tag=as0ecef1c4
Call-ID: 1e82197b42f0173b25e70759753d4210 at 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 at 10.17.0.35:64877;alias=65.xx.xx.161~64877~1>
To: "John"<sip:238 at 65.xx.xx.161
:64877;rinstance=8a315091627cc10b>;tag=6467b07f
From: "Robert" <sip:226 at mypbx.net>;tag=as0ecef1c4
Call-ID: 1e82197b42f0173b25e70759753d4210 at 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 at 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 at 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 at 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 at 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 at mypbx.net>;tag=as0ecef1c4
>>
>>
>> To: <sip:238 at 65.xx.xx.161:64877;rinstance=8a315091627cc10b>
>>
>>
>>
>> Contact: <sip:226 at 65.xx.xx.172:5060>
>>
>>
>>
>> Call-ID: 1e82197b42f0173b25e70759753d4210 at 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 at 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 at mypbx.net>;tag=as0ecef1c4
>>
>>
>> To: <sip:238 at 65.xx.xx.161:64877;rinstance=8a315091627cc10b>;tag=6467b07f
>>
>>
>>
>> Contact: <sip:226 at 65.xx.xx.172:5060>
>>
>>
>>
>> Call-ID: 1e82197b42f0173b25e70759753d4210 at mypbx.net
>>
>>
>> CSeq: 103 UPDATE
>>
>>
>>
>> Content-Length: 0
>>
>> Much obliged.
>>
>> On Fri, Oct 12, 2018 at 9:38 AM Daniel-Constantin Mierla <
>> miconda at 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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20181015/1625d182/attachment.html>