Hi Daniel, Certainly, below find the initial INVITE and the subsequent UPDATE, as received by [email protected]. 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:[email protected]: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:[email protected]>;tag=as0ecef1c4 To: <sip:[email protected]:64877;rinstance=8a315091627cc10b> Contact: <sip:[email protected]:5060> Call-ID: [email protected] 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:[email protected]: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:[email protected]>;tag=as0ecef1c4 To: <sip:[email protected]:64877;rinstance=8a315091627cc10b>;tag=6467b07f Contact: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 103 UPDATE Content-Length: 0 Much obliged. On Fri, Oct 12, 2018 at 9:38 AM Daniel-Constantin Mierla <[email protected]> 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 > [email protected]https://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 > >
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
