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:[email protected]:64877> To: "John"<sip:[email protected] :64877;rinstance=8a315091627cc10b>;tag=6467b07f From: "Robert" <sip:[email protected]>;tag=as0ecef1c4 Call-ID: [email protected] 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:[email protected]:64877;alias=65.xx.xx.161~64877~1> To: "John"<sip:[email protected] :64877;rinstance=8a315091627cc10b>;tag=6467b07f From: "Robert" <sip:[email protected]>;tag=as0ecef1c4 Call-ID: [email protected] CSeq: 102 INVITE Allow-Events: talk, hold Content-Length: 0 On Mon, Oct 15, 2018 at 12:15 PM Daniel-Constantin Mierla <[email protected]> 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 < > [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 >> >> > -- > 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
