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 <[email protected]> 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 [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 >> >> > -- > 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
