[SR-Users] UPDATE relayed from wrong socket
Daniel-Constantin Mierla
miconda at gmail.com
Mon Oct 15 19:57:57 CEST 2018
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 at 10.17.0.35:64877 <http://sip:238@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
> <mailto:sip%3A226 at mypbx.net>>;tag=as0ecef1c4
> Call-ID: 1e82197b42f0173b25e70759753d4210 at mypbx.net
> <mailto: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
> <mailto:sip%3A226 at mypbx.net>>;tag=as0ecef1c4
> Call-ID: 1e82197b42f0173b25e70759753d4210 at mypbx.net
> <mailto: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 <mailto: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 <mailto: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
>>> <mailto: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
>>> <mailto:sip%3A226 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
>>> <mailto: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
>>> <mailto:sip%3A226 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
>>> <mailto: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 <mailto: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.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 at lists.kamailio.org
>>>> <mailto:sr-users at 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>
>
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20181015/7fa7696f/attachment.html>
More information about the sr-users
mailing list