[SR-Users] UPDATE relayed from wrong socket

[Sergiu Pojoga]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20181015/02607323/attachment.html>