Hello,
On 06/07/16 00:25, John Petrini wrote: > Hi Daniel, > > > You were right and t_load_contacts was never my problem so I've taken > a step back and reverted to my original config that I pasted above and > I've been trying to work forward from there. Even t_cancel_branches > which I thought was stopping Kamailio from relaying the reply from the > cnam provider to the phone is not working. > > So focusing on the config above I see two things... you haven't provided any config, which one you refer as "config above"? Cheers, Daniel > > 1.) An invite is sent to the cnam provider. They reply with the cnam > in the PAID header. This response is forwarded off to the phone. I see > this in the PCAP and also see the reply in the logs.... > > Jul 4 11:39:34 s3 /usr/sbin/kamailio[12248]: DEBUG: <core> > [parser/msg_parser.c:635]: parse_msg(): SIP Reply (status): > Jul 4 11:39:34 s3 /usr/sbin/kamailio[12248]: DEBUG: <core> > [parser/msg_parser.c:637]: parse_msg(): version: <SIP/2.0> > Jul 4 11:39:34 s3 /usr/sbin/kamailio[12248]: DEBUG: <core> > [parser/msg_parser.c:639]: parse_msg(): status: <380> > Jul 4 11:39:34 s3 /usr/sbin/kamailio[12248]: DEBUG: <core> > [parser/msg_parser.c:641]: parse_msg(): reason: <cnam lookup> > > *This is what's forwarded back to the phone, > aka ** 22.222.22.222:5060 <http://22.222.22.222:5060>* > > U 2016/07/04 12:14:20.334227 888.88.88.8:5060 -> 22.222.22.222:5060 > <http://22.222.22.222:5060> > SIP/2.0 380 cnam lookup. > Via: SIP/2.0/UDP 22.222.22.222:5060;branch=z9hG4bK04Baa81485b774fe246. > From: "John Doe" <sip:+12222222222@22.222.22.222 > <mailto:sip%3A%2B12222222222@22.222.22.222>;isup-oli=62>;tag=gK04650084. > To: <sip:4444444...@s.core.com > <mailto:sip%3a4444444...@s.core.com>>;tag=CNAM-11144-1467649116955. > Call-ID: 201625658_65946715@22.222.22.222 > <mailto:201625658_65946715@22.222.22.222>. > CSeq: 852627 INVITE. > Contact: "CNAM" <sip:cnam_gw@10.212.16.31 > <mailto:sip%3Acnam_gw@10.212.16.31>>; transport=udp. > Max-Forwards: 10. > P-Asserted-Identity: "Unavailable" <sip:+12222222...@sip.core.com > <mailto:sip%3a%2b12222222...@sip.core.com>>. > Content-Length: 0. > > > > 2.) At the same time however I see another contact in the logs. The > strange thing here is that the R-URI is 2152974400@*ns*.core.com > <http://core.com>;trans-type=5. This R-URI has been modified in two > places; by the append_branch in the CNAM_DIPS route where I changed > the entire URI to 2152974...@core.com > <http://core.com>;trans-type=5 but also the domain was modified by our > PREPARE_FOR_BWP route which is called within the PREPARE_FOR_LAUNCH > route so that it now reads *ns*.core.com <http://core.com> instead of > core.com <http://core.com>. > > I'm not sure what this contact is. Is it the main branch? If so why > has it been modified by calling append_branch? Maybe that's expected > behaviour? Also, it doesn't look to me that these two branches are > running in a serial fashion. > > > Jul 4 11:39:34 s3 /usr/sbin/kamailio[12247]: INFO: <script>: > (route[PREPARE_FOR_LAUNCH]) -- INVITE R-URI: > sip:2152974...@ns.core.com > <mailto:sip%3a2152974...@ns.core.com>;trans-type=5 From: > sip:+12222222222@22.222.22.222 > <mailto:sip%3A%2B12222222222@22.222.22.222>;isup-oli=62 > (22.222.22.222) To: sip:4444444...@s.core.com > <mailto:sip%3a4444444...@s.core.com> UA: <null> CID: > 203428094_132100710@22.222.22.222 > <mailto:203428094_132100710@22.222.22.222> > Jul 4 11:39:34 s3 /usr/sbin/kamailio[12326]: DEBUG: <core> > [parser/msg_parser.c:635]: parse_msg(): SIP Reply (status): Jul 4 > 11:39:34 s3 /usr/sbin/kamailio[12326]: DEBUG: <core> > [parser/msg_parser.c:637]: parse_msg(): version: <SIP/2.0> Jul 4 > 11:39:34 s3 /usr/sbin/kamailio[12326]: DEBUG: <core> > [parser/msg_parser.c:639]: parse_msg(): status: <404> Jul 4 11:39:34 > s3 /usr/sbin/kamailio[12326]: DEBUG: <core> [parser/msg_parser.c:641]: > parse_msg(): reason: <Not found> > > As far as the failure route, I'm calling t_relay() only if there are > remaining contacts. Is this what you mean when you say I need to > forward the request again? > > > Any help you or the rest of the community can provide would be greatly > appreciated. I've been hacking at this for a few days and I'm not > making much progress at this point. Let me know if I can provide any > more details. > > > Thank you, > > John Petrini > > > > On Mon, Jul 4, 2016 at 12:39 PM, John Petrini <jpetr...@coredial.com > <mailto:jpetr...@coredial.com>> wrote: > > Hi Daniel, > > Sorry for the confusion. As requested here is a coherent call > sample including the debug changes, config, kamailio log, packet > capture, and syslog. I've only attached the relevant CNAM_DIPS > section of the config. It's a rather large config with many other > routes but if need be I can provide the rest of the config. > > In regards to the 3xx responses. The CNAM provider returns a 380 > with the CNAM in the PAID header but from my testing I've seen the > 380 drop to the onreply_route[CNAM_DIPS] NOT > faliure_route[CNAM_DIPS]. You can see in my config below that this > is where I'm capturing the PAID header into an AVP. I was > expecting the 380 to put me in the failure route and capture the > CNAM there but instead I'm successfully capturing in on_reply. > > Config: > > route[CNAM_DIPS] { > # Check call direction. If we're outbound nothing to do here > if ($avp(direction) == "in") { > t_on_branch("CNAM_DIPS"); > t_on_reply("CNAM_DIPS"); > t_on_failure("CNAM_DIPS"); > $avp(cnam_dip_authorized) = 0; > sql_xquery("routing", "SELECT * FROM callRoute WHERE > telephoneNumber = '$var(dest_tn)'", "callRoute_cnam_query"); > $avp(cnam_dip_authorized) = > $xavp(callRoute_cnam_query=>cnamDipAuthorized); > append_branch("sip:8888888888 > <tel:8888888888>@444.44.444.44:5060;trans-type=5", "0.5"); > t_load_contacts(); > t_next_contacts(); > t_relay(); > break; > } > } > > branch_route[CNAM_DIPS] { > $var(modified_from) = "sip:" + $fU + "@sip.core.com > <http://sip.core.com>"; > uac_replace_from("$var(modified_from)"); > } > > onreply_route[CNAM_DIPS] { > if (t_check_status("380")) { > xlog("L_INFO", "INFO: Received valid reply from TNSi > (on_reply_route[CNAM_DIPS])"); > $avp(cnam) = $(hdr(P-Asserted-Identity){nameaddr.name > <http://nameaddr.name>}); > } else { > xlog("L_ERROR", "INFO: Received bad reply from TNSi > (on_reply_route[CNAM_DIPS])"); > }; > drop; > } > > failure_route[CNAM_DIPS] { > if (!t_next_contacts()) { > xlog("L_ERR", "ERROR: Gateway failure > (failure_route[CNAM_DIPS])"); > exit; > } else { > t_next_contacts(); > t_relay(); > }; > } > > Kamailio > log: https://gist.github.com/johnavp1989/92adb1b9461168b4e46ba8842f65dac9 > Packet > capture: > https://gist.github.com/johnavp1989/1167391732307a8ec025a992b4cda79a > Syslog: > https://gist.github.com/johnavp1989/6ea392880a6fd9aaa4e4eded57819b6c > > ___ > > John Petrini > > NOC Systems Administrator // *CoreDial, > LLC* // coredial.com <http://coredial.com/> // Twitter > <https://twitter.com/coredial> LinkedIn > <http://www.linkedin.com/company/99631> Google Plus > <https://plus.google.com/104062177220750809525/posts> Blog > <http://success.coredial.com/blog> > Hillcrest I, 751 Arbor Way, Suite 150, Blue Bell PA, 19422 > *P: *215.297.4400 x232 > // *F: *215.297.4401 // *E: *jpetr...@coredial.com > <mailto:jpetr...@coredial.com> > > Exceptional people. Proven Processes. Innovative Technology. > Discover CoreDial - watch our video > > <http://cta-redirect.hubspot.com/cta/redirect/210539/4c492538-6e4b-445e-9480-bef676787085> > > The information transmitted is intended only for the person or > entity to which it is addressed and may contain confidential > and/or privileged material. Any review, retransmission, > dissemination or other use of, or taking of any action in > reliance upon, this information by persons or entities other than > the intended recipient is prohibited. If you received this in > error, please contact the sender and delete the material from any > computer. > > > On Mon, Jul 4, 2016 at 10:43 AM, Daniel-Constantin Mierla > <mico...@gmail.com <mailto:mico...@gmail.com>> wrote: > > Hello, > > it is really confusing how you provide details for > troubleshooting -- if you want us to help you, then you have > to be coherent in providing config snippets, logs and traces > as used at that moment that exposed the issue. If you give > something that not match, we work on invalid input, then lose > time and interest in providing help. > > To reset and restart with proper input: > > - provide the relevant snippets that you use at the moment > the issues are exposed > - load debugger module and set its cfgtrace parameter to 1 > - set debug=3 in kamailio cfg and then rerun the tests, take > the log messages from syslog and provide them here > > I checked the source code and t_load_contacts() should not > trigger any code in pv module, so the next log message that > you pasted in your first email is not related to > t_load_contacts(), you have something else in the > configuration file: > > >>> ERROR: pv [pv_branch.c:58]: pv_get_branchx(): error accessing > branch [0] > > So some other parts were not provided in the config snippets. > > If you set a failure route, then you don't need to drop > failure response codes such 3xx, it will be overwritten if you > forward the request again. But if you don't forward the > request in failure_route, then last winning response is sent > in this case. > > Cheers, > Daniel > > > On 04/07/16 16:14, jpetr...@coredial.com > <mailto:jpetr...@coredial.com> wrote: >> >> Hi Daniel, >> >> >> >> I have it commented out currently because neither seem to be >> working. The packet capture however was taken with drop >> uncommented and without the t_cancel_branches if statement. >> t_load_contacts was also commented out to avoid hitting the >> unable to load contact error. >> >> >> >> Regards, >> >> >> >> John Petrini >> >> >> >> >> >> *From: *Daniel-Constantin Mierla <mailto:mico...@gmail.com> >> *Sent: *Monday, July 4, 2016 9:38 AM >> *To: *John Petrini <mailto:jpetr...@coredial.com> >> *Cc: *Kamailio (SER) - Users Mailing List >> <mailto:sr-users@lists.sip-router.org> >> *Subject: *Re: [SR-Users] (no subject) >> >> >> >> Hello, >> >> in the new email, the t_load_contacts() and drop are commented. >> >> Is it how you have them in the config or again some >> formatting issue? >> >> Cheers, >> Daniel >> >> On 04/07/16 15:13, John Petrini wrote: >> >> Hi Daniel, >> >> >> >> I made a mistake with my formatting when I pasted here. I >> am calling append_branch() before t_load_contacts. I've >> attached a view of the entire route including where I was >> using drop; below. Also a packet capture that shows >> Kamailio forwarding the reply from the cnam provider back >> to the phone. I've discovered t_cancel_branches("this") >> and that seems to be doing the job of killing the second >> branch as well as the reply to the phone. >> >> >> >> My main issue right now is serializing the branches, >> append_branch creates an additional branch but >> t_load_contacts fails. I've tried appending multiple >> branches and also using seturi to replicate the >> documentation as closely as possible with no luck. >> >> >> >> route[CNAM_DIPS] { >> >> if ($avp(direction) == "in") { >> >> t_on_branch("CNAM_DIPS"); >> >> t_on_reply("CNAM_DIPS"); >> >> t_on_failure("CNAM_DIPS"); >> >> $var(reply_count) = 0; >> >> append_branch("sip:8888888888 >> <tel:2152974400>@222.22.222.22:5060;trans-type=5", "0.5"); >> >> #t_load_contacts(); >> >> t_next_contacts(); >> >> t_relay(); >> >> break; >> >> } >> >> } >> >> >> >> branch_route[CNAM_DIPS] { >> >> $var(modified_from) = "sip:" + $fU + "@sip.core.com >> <http://sip.core.com/>"; >> >> uac_replace_from("$var(modified_from)"); >> >> } >> >> >> >> onreply_route[CNAM_DIPS] { >> >> $var(reply_count) = $var(reply_count) + 1; >> >> if (t_check_status("380")) { >> >> $avp(cnam) = $(hdr(P-Asserted-Identity){nameaddr.name >> <http://nameaddr.name/>}); >> >> } else { >> >> xlog("L_ERROR", "INFO: Received bad reply >> (on_reply_route[CNAM_DIPS]):"); >> >> }; >> >> if ($var(reply_count) = 1) { >> >> t_cancel_branches("this"); >> >> } >> >> #drop; >> >> } >> >> >> >> failure_route[CNAM_DIPS] { >> >> if (!t_next_contacts()) { >> >> xlog("L_ERR", "ERROR: Gateway failure >> (failure_route[CNAM_DIPS]): Failed to ship call"); >> >> exit; >> >> } else { >> >> t_next_contacts(); >> >> t_relay(); >> >> }; >> >> } >> >> >> >> >> >> Packet capture using drop in the on_reply route rather >> than t_cancel_branches("this"): >> >> >> >> U 2016/07/04 08:46:41.223295 44.444.4.444:5060 -> >> 333.33.33.3:5060 >> >> INVITE sip:+12222222...@core.com:5060 >> <http://sip:+12222222...@core.com:5060> SIP/2.0. >> >> Via: SIP/2.0/UDP >> 44.444.4.444:5060;branch=z9hG4bK04Bef9112d99372eace. >> >> From: "UNKNOWN" >> <sip:+13333333333@44.444.4.444;isup-oli=62>;tag=gK046fcff6. >> >> To: <sip:2222222...@core.com >> <mailto:sip%3a2222222...@core.com>>. >> >> Call-ID: 1698991986_66771899@44.444.4.444 >> <mailto:1698991986_66771899@44.444.4.444>. >> >> CSeq: 468700 INVITE. >> >> Max-Forwards: 70. >> >> Allow: INVITE,ACK,CANCEL,BYE,OPTIONS. >> >> Accept: application/sdp. >> >> Contact: "UNKNOWN" <sip:+13333333333@44.444.4.444:5060>. >> >> P-Asserted-Identity: "UNKNOWN" >> <sip:+13333333333@44.444.4.444:5060>. >> >> Supported: replaces. >> >> Content-Length: 281. >> >> Content-Disposition: session; handling=required. >> >> Content-Type: application/sdp. >> >> . >> >> v=0. >> >> o=Sonus_UAC 807784 731434 IN IP4 44.444.4.444. >> >> s=SIP Media Capabilities. >> >> c=IN IP4 55.555.5.55. >> >> t=0 0. >> >> m=audio 54018 RTP/AVP 0 18 101. >> >> a=rtpmap:0 PCMU/8000. >> >> a=rtpmap:18 G729/8000. >> >> a=fmtp:18 annexb=no. >> >> a=rtpmap:101 telephone-event/8000. >> >> a=fmtp:101 0-15. >> >> a=sendrecv. >> >> a=ptime:20. >> >> >> >> >> >> U 2016/07/04 08:46:41.230033 333.33.33.3:5060 -> >> 44.444.4.444:5060 >> >> SIP/2.0 100 trying -- your call is important to us. >> >> Via: SIP/2.0/UDP >> 44.444.4.444:5060;branch=z9hG4bK04Bef9112d99372eace. >> >> From: "UNKNOWN" >> <sip:+13333333333@44.444.4.444;isup-oli=62>;tag=gK046fcff6. >> >> To: <sip:2222222...@core.com >> <mailto:sip%3a2222222...@core.com>>. >> >> Call-ID: 1698991986_66771899@44.444.4.444 >> <mailto:1698991986_66771899@44.444.4.444>. >> >> CSeq: 468700 INVITE. >> >> Server: kamailio (4.2.7 (x86_64/linux)). >> >> Content-Length: 0. >> >> . >> >> >> >> >> >> U 2016/07/04 08:46:41.234143 333.33.33.3:5060 -> >> 222.22.222.22:5060 <http://222.22.222.22:5060> >> >> INVITE sip:8888888888@222.22.222.22:5060;trans-type=5 >> SIP/2.0. >> >> Record-Route: >> >> <sip:333.33.33.3;lr;ftag=gK046fcff6;vsf=AAAAAAAAAAAAAAAAAAAAAABFXl4cUF5cXABSXl87aXN1cC1vbGk9NjI->. >> >> Via: SIP/2.0/UDP >> >> 333.33.33.3;branch=z9hG4bK8ac3.daa229dcb24f16332fa5a21927e9a72f.0. >> >> Via: SIP/2.0/UDP >> 44.444.4.444:5060;branch=z9hG4bK04Bef9112d99372eace. >> >> From: "UNKNOWN" <sip:+13333333...@sip.core.com >> <mailto:sip%3a%2b13333333...@sip.core.com>>;tag=gK046fcff6. >> >> To: <sip:2222222...@core.com >> <mailto:sip%3a2222222...@core.com>>. >> >> Call-ID: 1698991986_66771899@44.444.4.444 >> <mailto:1698991986_66771899@44.444.4.444>. >> >> CSeq: 468700 INVITE. >> >> Max-Forwards: 69. >> >> Allow: INVITE,ACK,CANCEL,BYE,OPTIONS. >> >> Accept: application/sdp. >> >> Contact: "UNKNOWN" <sip:+13333333333@44.444.4.444:5060>. >> >> P-Asserted-Identity: "UNKNOWN" >> <sip:+13333333333@44.444.4.444:5060>. >> >> Supported: replaces. >> >> Content-Length: 281. >> >> Content-Disposition: session; handling=required. >> >> Content-Type: application/sdp. >> >> P-hint: branch_route CNAM_DIPS. >> >> . >> >> v=0. >> >> o=Sonus_UAC 807784 731434 IN IP4 44.444.4.444. >> >> s=SIP Media Capabilities. >> >> c=IN IP4 55.555.5.55. >> >> t=0 0. >> >> m=audio 54018 RTP/AVP 0 18 101. >> >> a=rtpmap:0 PCMU/8000. >> >> a=rtpmap:18 G729/8000. >> >> a=fmtp:18 annexb=no. >> >> a=rtpmap:101 telephone-event/8000. >> >> a=fmtp:101 0-15. >> >> a=sendrecv. >> >> a=ptime:20. >> >> >> >> >> >> U 2016/07/04 08:46:41.367868 222.22.222.22:5060 >> <http://222.22.222.22:5060> -> 333.33.33.3:5060 >> >> SIP/2.0 380 cnam lookup. >> >> Via: SIP/2.0/UDP >> >> 333.33.33.3;branch=z9hG4bK8ac3.daa229dcb24f16332fa5a21927e9a72f.0. >> >> Via: SIP/2.0/UDP >> 44.444.4.444:5060;branch=z9hG4bK04Bef9112d99372eace. >> >> From: "UNKNOWN" <sip:+13333333...@sip.core.com >> <mailto:sip%3a%2b13333333...@sip.core.com>>;tag=gK046fcff6. >> >> To: <sip:2222222...@core.com >> <mailto:sip%3a2222222...@core.com>>;tag=CNAM-16688-1467636671937. >> >> Call-ID: 1698991986_66771899@44.444.4.444 >> <mailto:1698991986_66771899@44.444.4.444>. >> >> CSeq: 468700 INVITE. >> >> Contact: "CNAM" <sip:cnam_gw@10.212.16.30 >> <mailto:sip%3Acnam_gw@10.212.16.30>>; transport=udp. >> >> Max-Forwards: 10. >> >> P-Asserted-Identity: "Unavailable" >> <sip:+13333333...@sip.core.com>. >> >> Content-Length: 0. >> >> . >> >> >> >> >> >> U 2016/07/04 08:46:41.368421 333.33.33.3:5060 -> >> 222.22.222.22:5060 <http://222.22.222.22:5060> >> >> ACK sip:8888888888@222.22.222.22:5060;trans-type=5 SIP/2.0. >> >> Via: SIP/2.0/UDP >> >> 333.33.33.3;branch=z9hG4bK8ac3.daa229dcb24f16332fa5a21927e9a72f.0. >> >> From: "UNKNOWN" <sip:+13333333...@sip.core.com >> <mailto:sip%3a%2b13333333...@sip.core.com>>;tag=gK046fcff6. >> >> To: <sip:2222222...@core.com >> <mailto:sip%3a2222222...@core.com>>;tag=CNAM-16688-1467636671937. >> >> Call-ID: 1698991986_66771899@44.444.4.444 >> <mailto:1698991986_66771899@44.444.4.444>. >> >> CSeq: 468700 ACK. >> >> Max-Forwards: 69. >> >> Content-Length: 0. >> >> . >> >> >> >> >> >> U 2016/07/04 08:46:44.227076 333.33.33.3:5060 -> >> 44.444.4.444:5060 >> >> SIP/2.0 380 cnam lookup. >> >> Via: SIP/2.0/UDP >> 44.444.4.444:5060;branch=z9hG4bK04Bef9112d99372eace. >> >> From: "UNKNOWN" >> <sip:+13333333333@44.444.4.444;isup-oli=62>;tag=gK046fcff6. >> >> To: <sip:2222222...@core.com >> <mailto:sip%3a2222222...@core.com>>;tag=CNAM-16688-1467636671937. >> >> Call-ID: 1698991986_66771899@44.444.4.444 >> <mailto:1698991986_66771899@44.444.4.444>. >> >> CSeq: 468700 INVITE. >> >> Contact: "CNAM" <sip:cnam_gw@10.212.16.30 >> <mailto:sip%3Acnam_gw@10.212.16.30>>; transport=udp. >> >> Max-Forwards: 10. >> >> P-Asserted-Identity: "Unavailable" >> <sip:+13333333...@sip.core.com>. >> >> Content-Length: 0. >> >> P-hint: onreply CNAM_DIPS. >> >> . >> >> >> >> >> >> >> >> >> >> >> ___ >> >> John Petrini >> >> NOC Systems Administrator // *CoreDial, >> LLC* // coredial.com >> <http://coredial.com/> // Twitter >> <https://twitter.com/coredial> LinkedIn >> <http://www.linkedin.com/company/99631> Google Plus >> <https://plus.google.com/104062177220750809525/posts> Blog >> <http://success.coredial.com/blog> >> Hillcrest I, 751 Arbor Way, Suite 150, Blue Bell PA, 19422 >> *P: *215.297.4400 x232 <tel:215.297.4400%C2%A0x232> >> // *F: *215.297.4401 >> <tel:215.297.4401> // *E: *jpetr...@coredial.com >> <mailto:jpetr...@coredial.com> >> >> Exceptional people. Proven Processes. Innovative >> Technology. Discover CoreDial - watch our video >> >> <http://cta-redirect.hubspot.com/cta/redirect/210539/4c492538-6e4b-445e-9480-bef676787085> >> >> The information transmitted is intended only for the >> person or entity to which it is addressed and may contain >> confidential and/or privileged material. Any review, >> retransmission, dissemination or other use of, or taking >> of any action in reliance upon, this information by >> persons or entities other than the intended recipient is >> prohibited. If you received this in error, please contact >> the sender and delete the material from any computer. >> >> >> >> >> >> -- >> Daniel-Constantin Mierla >> http://www.asipto.com - http://www.kamailio.org >> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> - >> http://www.linkedin.com/in/miconda >> >> >> > > -- > Daniel-Constantin Mierla > http://www.asipto.com - http://www.kamailio.org > http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> - > http://www.linkedin.com/in/miconda > > > -- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
