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>