Hello,
I'm trying to append a branch, assign it a q value so it has priority and serialize the new branch and the main branch.
The goal is to send the new branch off to our CNAM provider, capture the CNAM in their reply to an $avp then drop the branch, stick the cnam in the main branch and allow the call to continue as normal. We do this currently using OpenSIPS with serialize_branches(1) but the of load_contacts() behavior seems to be different than serialize_branches.
route[CNAM_DIPS] t_on_branch("CNAM_DIPS"); t_on_reply("CNAM_DIPS"); t_on_failure("CNAM_DIPS"); t_load_contacts(); t_next_contacts(); append_branch("sip:2223334444@22.33.444.55:5600;trans-type=5", "0.5"); relay(); break;
Two problems. First when t_next_contacts is called I get the following error: ERROR: pv [pv_branch.c:58]: pv_get_branchx(): error accessing branch [0] So it looks like the branches aren't actually being loaded?
Second problem is that despite the first error my call goes out on the branch I appended and I get a reply from the CNAM provider but Kamailio forwards that reply back to the phone causing the phone to send a second invite. In OpenSIPs we just called drop, to drop the branch and let the main branch continue but this doesn't seem to work in Kamailio.
I've read and reread the documentaion but it doesn't seem to behave the way the documentation says it should. Is there something I'm missing? Is there a better way to accomplish this in Kamailio?
Thank You,
___
John Petrini
Hello,
I expect that you have to call append_branch() before doing t_load_contacts().
Then, where do you execute drop() for the sip reply? Kamailio is dropping the replies if you call drop() -- this is a feature since 2005-2006 (openser 1.1.x or so), if I recall it properly at this moment, I may even be the developer for this feature. Anyhow, it should work fine if used in reply_route or onreply_route -- I used for a new config last week inside reply_route to fix issues with a broken gateway that doesn't like 183 before 180.
Maybe you can provide a pcap as well as relevant configuration file snippets for use of the drop().
Cheers, Daniel
On 02/07/16 15:49, John Petrini wrote:
Hello,
I'm trying to append a branch, assign it a q value so it has priority and serialize the new branch and the main branch.
The goal is to send the new branch off to our CNAM provider, capture the CNAM in their reply to an $avp then drop the branch, stick the cnam in the main branch and allow the call to continue as normal. We do this currently using OpenSIPS with serialize_branches(1) but the of load_contacts() behavior seems to be different than serialize_branches.
route[CNAM_DIPS] t_on_branch("CNAM_DIPS"); t_on_reply("CNAM_DIPS"); t_on_failure("CNAM_DIPS"); t_load_contacts(); t_next_contacts(); append_branch("sip:2223334444@22.33.444.55:5600;trans-type=5", "0.5"); relay(); break;
Two problems. First when t_next_contacts is called I get the following error: ERROR: pv [pv_branch.c:58]: pv_get_branchx(): error accessing branch [0] So it looks like the branches aren't actually being loaded?
Second problem is that despite the first error my call goes out on the branch I appended and I get a reply from the CNAM provider but Kamailio forwards that reply back to the phone causing the phone to send a second invite. In OpenSIPs we just called drop, to drop the branch and let the main branch continue but this doesn't seem to work in Kamailio.
I've read and reread the documentaion but it doesn't seem to behave the way the documentation says it should. Is there something I'm missing? Is there a better way to accomplish this in Kamailio?
Thank You,
John Petrini
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
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 <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"; 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}); } 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:+12222222222@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:2222222222@core.com. Call-ID: 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:2222222222@core.com. Call-ID: 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 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:+13333333333@sip.core.com;tag=gK046fcff6. To: sip:2222222222@core.com. Call-ID: 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 -> 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:+13333333333@sip.core.com;tag=gK046fcff6. To: sip:2222222222@core.com;tag=CNAM-16688-1467636671937. Call-ID: 1698991986_66771899@44.444.4.444. CSeq: 468700 INVITE. Contact: "CNAM" sip:cnam_gw@10.212.16.30; transport=udp. Max-Forwards: 10. P-Asserted-Identity: "Unavailable" sip:+13333333333@sip.core.com. Content-Length: 0. .
U 2016/07/04 08:46:41.368421 333.33.33.3:5060 -> 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:+13333333333@sip.core.com;tag=gK046fcff6. To: sip:2222222222@core.com;tag=CNAM-16688-1467636671937. Call-ID: 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:2222222222@core.com;tag=CNAM-16688-1467636671937. Call-ID: 1698991986_66771899@44.444.4.444. CSeq: 468700 INVITE. Contact: "CNAM" sip:cnam_gw@10.212.16.30; transport=udp. Max-Forwards: 10. P-Asserted-Identity: "Unavailable" sip:+13333333333@sip.core.com. Content-Length: 0. P-hint: onreply CNAM_DIPS. .
___
John Petrini
NOC Systems Administrator // *CoreDial, LLC* // coredial.com // [image: Twitter] https://twitter.com/coredial [image: LinkedIn] http://www.linkedin.com/company/99631 [image: Google Plus] https://plus.google.com/104062177220750809525/posts [image: 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: * jpetrini@coredial.com
[image: 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 7:15 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
I expect that you have to call append_branch() before doing t_load_contacts().
Then, where do you execute drop() for the sip reply? Kamailio is dropping the replies if you call drop() -- this is a feature since 2005-2006 (openser 1.1.x or so), if I recall it properly at this moment, I may even be the developer for this feature. Anyhow, it should work fine if used in reply_route or onreply_route -- I used for a new config last week inside reply_route to fix issues with a broken gateway that doesn't like 183 before 180.
Maybe you can provide a pcap as well as relevant configuration file snippets for use of the drop().
Cheers, Daniel
On 02/07/16 15:49, John Petrini wrote:
Hello,
I'm trying to append a branch, assign it a q value so it has priority and serialize the new branch and the main branch.
The goal is to send the new branch off to our CNAM provider, capture the CNAM in their reply to an $avp then drop the branch, stick the cnam in the main branch and allow the call to continue as normal. We do this currently using OpenSIPS with serialize_branches(1) but the of load_contacts() behavior seems to be different than serialize_branches.
route[CNAM_DIPS] t_on_branch("CNAM_DIPS"); t_on_reply("CNAM_DIPS"); t_on_failure("CNAM_DIPS"); t_load_contacts(); t_next_contacts(); append_branch("sip:2223334444@22.33.444.55:5600;trans-type=5", "0.5"); relay(); break;
Two problems. First when t_next_contacts is called I get the following error: ERROR: pv [pv_branch.c:58]: pv_get_branchx(): error accessing branch [0] So it looks like the branches aren't actually being loaded?
Second problem is that despite the first error my call goes out on the branch I appended and I get a reply from the CNAM provider but Kamailio forwards that reply back to the phone causing the phone to send a second invite. In OpenSIPs we just called drop, to drop the branch and let the main branch continue but this doesn't seem to work in Kamailio.
I've read and reread the documentaion but it doesn't seem to behave the way the documentation says it should. Is there something I'm missing? Is there a better way to accomplish this in Kamailio?
Thank You,
John Petrini
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlahttp://www.asipto.com - http://www.kamailio.orghttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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:+12222222222@core.com:5060 http://sip:+12222222222@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:2222222222@core.com mailto:sip%3A2222222222@core.com>. Call-ID: 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:2222222222@core.com mailto:sip%3A2222222222@core.com>. Call-ID: 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:+13333333333@sip.core.com mailto:sip%3A%2B13333333333@sip.core.com>;tag=gK046fcff6. To: <sip:2222222222@core.com mailto:sip%3A2222222222@core.com>. Call-ID: 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:+13333333333@sip.core.com mailto:sip%3A%2B13333333333@sip.core.com>;tag=gK046fcff6. To: <sip:2222222222@core.com mailto:sip%3A2222222222@core.com>;tag=CNAM-16688-1467636671937. Call-ID: 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:+13333333333@sip.core.com mailto:sip%3A%2B13333333333@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:+13333333333@sip.core.com mailto:sip%3A%2B13333333333@sip.core.com>;tag=gK046fcff6. To: <sip:2222222222@core.com mailto:sip%3A2222222222@core.com>;tag=CNAM-16688-1467636671937. Call-ID: 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:2222222222@core.com mailto:sip%3A2222222222@core.com>;tag=CNAM-16688-1467636671937. Call-ID: 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:+13333333333@sip.core.com mailto:sip%3A%2B13333333333@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 // *F: *215.297.4401 // *E: *jpetrini@coredial.com mailto:jpetrini@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.
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
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, jpetrini@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:miconda@gmail.com *Sent: *Monday, July 4, 2016 9:38 AM *To: *John Petrini mailto:jpetrini@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:+12222222222@core.com:5060 <http://sip:+12222222222@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> <sip:+13333333333@44.444.4.444;isup-oli=62>;tag=gK046fcff6. To: <sip:2222222222@core.com <mailto:sip%3A2222222222@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> <sip:+13333333333@44.444.4.444:5060>. P-Asserted-Identity: "UNKNOWN" <sip:+13333333333@44.444.4.444:5060> <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> <sip:+13333333333@44.444.4.444;isup-oli=62>;tag=gK046fcff6. To: <sip:2222222222@core.com <mailto:sip%3A2222222222@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-> <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:+13333333333@sip.core.com <mailto:sip%3A%2B13333333333@sip.core.com>>;tag=gK046fcff6. To: <sip:2222222222@core.com <mailto:sip%3A2222222222@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> <sip:+13333333333@44.444.4.444:5060>. P-Asserted-Identity: "UNKNOWN" <sip:+13333333333@44.444.4.444:5060> <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:+13333333333@sip.core.com <mailto:sip%3A%2B13333333333@sip.core.com>>;tag=gK046fcff6. To: <sip:2222222222@core.com <mailto:sip%3A2222222222@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:+13333333333@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:+13333333333@sip.core.com <mailto:sip%3A%2B13333333333@sip.core.com>>;tag=gK046fcff6. To: <sip:2222222222@core.com <mailto:sip%3A2222222222@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> <sip:+13333333333@44.444.4.444;isup-oli=62>;tag=gK046fcff6. To: <sip:2222222222@core.com <mailto:sip%3A2222222222@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:+13333333333@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 // *F: *215.297.4401 // *E: *jpetrini@coredial.com <mailto:jpetrini@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
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@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"; 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}); } 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 // [image: Twitter] https://twitter.com/coredial [image: LinkedIn] http://www.linkedin.com/company/99631 [image: Google Plus] https://plus.google.com/104062177220750809525/posts [image: 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: * jpetrini@coredial.com
[image: 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 <miconda@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, jpetrini@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 miconda@gmail.com *Sent: *Monday, July 4, 2016 9:38 AM *To: *John Petrini jpetrini@coredial.com *Cc: *Kamailio (SER) - Users Mailing List 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 <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";
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});} 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:+12222222222@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.
Call-ID: 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.
Call-ID: 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
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:+13333333333@sip.core.com;tag=gK046fcff6.
Call-ID: 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 -> 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:+13333333333@sip.core.com;tag=gK046fcff6.
To: sip:2222222222@core.com;tag=CNAM-16688-1467636671937.
Call-ID: 1698991986_66771899@44.444.4.444.
CSeq: 468700 INVITE.
Contact: "CNAM" sip:cnam_gw@10.212.16.30; transport=udp.
Max-Forwards: 10.
P-Asserted-Identity: "Unavailable" sip:+13333333333@sip.core.com.
Content-Length: 0.
.
U 2016/07/04 08:46:41.368421 333.33.33.3:5060 -> 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:+13333333333@sip.core.com;tag=gK046fcff6.
To: sip:2222222222@core.com;tag=CNAM-16688-1467636671937.
Call-ID: 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:2222222222@core.com;tag=CNAM-16688-1467636671937.
Call-ID: 1698991986_66771899@44.444.4.444.
CSeq: 468700 INVITE.
Contact: "CNAM" sip:cnam_gw@10.212.16.30; transport=udp.
Max-Forwards: 10.
P-Asserted-Identity: "Unavailable" sip:+13333333333@sip.core.com.
Content-Length: 0.
P-hint: onreply CNAM_DIPS.
.
John Petrini
NOC Systems Administrator // *CoreDial, LLC* // coredial.com // [image: Twitter] https://twitter.com/coredial [image: LinkedIn] http://www.linkedin.com/company/99631 [image: Google Plus] https://plus.google.com/104062177220750809525/posts [image: 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: * jpetrini@coredial.com
[image: 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://www.linkedin.com/in/miconda
-- Daniel-Constantin Mierlahttp://www.asipto.com - http://www.kamailio.orghttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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...
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 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 ;isup-oli=62;tag=gK04650084. To: sip:4444444444@s.core.com;tag=CNAM-11144-1467649116955. Call-ID: 201625658_65946715@22.222.22.222. CSeq: 852627 INVITE. Contact: "CNAM" sip:cnam_gw@10.212.16.31; transport=udp. Max-Forwards: 10. P-Asserted-Identity: "Unavailable" sip:+12222222222@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;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 2152974400@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 instead of 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:2152974400@ns.core.com;trans-type=5 From: sip:+12222222222@22.222.22.222;isup-oli=62 (22.222.22.222) To: sip:4444444444@s.core.com UA: <null> CID: 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 jpetrini@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@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"; 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}); } 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 // [image: Twitter] https://twitter.com/coredial [image: LinkedIn] http://www.linkedin.com/company/99631 [image: Google Plus] https://plus.google.com/104062177220750809525/posts [image: 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: * jpetrini@coredial.com
[image: 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 < miconda@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, jpetrini@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 miconda@gmail.com *Sent: *Monday, July 4, 2016 9:38 AM *To: *John Petrini jpetrini@coredial.com *Cc: *Kamailio (SER) - Users Mailing List 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 <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";
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});} 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:+12222222222@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.
Call-ID: 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.
Call-ID: 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
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:+13333333333@sip.core.com;tag=gK046fcff6.
Call-ID: 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 -> 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:+13333333333@sip.core.com;tag=gK046fcff6.
To: sip:2222222222@core.com;tag=CNAM-16688-1467636671937.
Call-ID: 1698991986_66771899@44.444.4.444.
CSeq: 468700 INVITE.
Contact: "CNAM" sip:cnam_gw@10.212.16.30; transport=udp.
Max-Forwards: 10.
P-Asserted-Identity: "Unavailable" sip:+13333333333@sip.core.com.
Content-Length: 0.
.
U 2016/07/04 08:46:41.368421 333.33.33.3:5060 -> 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:+13333333333@sip.core.com;tag=gK046fcff6.
To: sip:2222222222@core.com;tag=CNAM-16688-1467636671937.
Call-ID: 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:2222222222@core.com;tag=CNAM-16688-1467636671937.
Call-ID: 1698991986_66771899@44.444.4.444.
CSeq: 468700 INVITE.
Contact: "CNAM" sip:cnam_gw@10.212.16.30; transport=udp.
Max-Forwards: 10.
P-Asserted-Identity: "Unavailable" sip:+13333333333@sip.core.com.
Content-Length: 0.
P-hint: onreply CNAM_DIPS.
.
John Petrini
NOC Systems Administrator // *CoreDial, LLC* // coredial.com // [image: Twitter] https://twitter.com/coredial [image: LinkedIn] http://www.linkedin.com/company/99631 [image: Google Plus] https://plus.google.com/104062177220750809525/posts [image: 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: * jpetrini@coredial.com
[image: 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://www.linkedin.com/in/miconda
-- Daniel-Constantin Mierlahttp://www.asipto.com - http://www.kamailio.orghttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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:4444444444@s.core.com mailto:sip%3A4444444444@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:+12222222222@sip.core.com mailto:sip%3A%2B12222222222@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 2152974400@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:2152974400@ns.core.com mailto:sip%3A2152974400@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:4444444444@s.core.com mailto:sip%3A4444444444@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 <jpetrini@coredial.com mailto:jpetrini@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: *jpetrini@coredial.com <mailto:jpetrini@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 <miconda@gmail.com <mailto:miconda@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, jpetrini@coredial.com <mailto:jpetrini@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:miconda@gmail.com> *Sent: *Monday, July 4, 2016 9:38 AM *To: *John Petrini <mailto:jpetrini@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:+12222222222@core.com:5060 <http://sip:+12222222222@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:2222222222@core.com <mailto:sip%3A2222222222@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:2222222222@core.com <mailto:sip%3A2222222222@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:+13333333333@sip.core.com <mailto:sip%3A%2B13333333333@sip.core.com>>;tag=gK046fcff6. To: <sip:2222222222@core.com <mailto:sip%3A2222222222@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:+13333333333@sip.core.com <mailto:sip%3A%2B13333333333@sip.core.com>>;tag=gK046fcff6. To: <sip:2222222222@core.com <mailto:sip%3A2222222222@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:+13333333333@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:+13333333333@sip.core.com <mailto:sip%3A%2B13333333333@sip.core.com>>;tag=gK046fcff6. To: <sip:2222222222@core.com <mailto:sip%3A2222222222@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:2222222222@core.com <mailto:sip%3A2222222222@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:+13333333333@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: *jpetrini@coredial.com <mailto:jpetrini@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
This config from my earlier email. Do you want to see the entire 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@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"; 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}); } 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(); }; }
And these are the corresponding logs I was referencing:
Kamailio log: https://gist.github.com/johnavp1989/92adb1b9461168b4e46ba8842f65dac9 Packet capture: https://gist.github.com/johnavp1989/1167391732307a8ec025a992b4cda79a Syslog: https://gist.github.com/johnavp1989/6ea392880a6fd9aaa4e4eded57819b6c
-
Daniel-Constantin Mierla -
John Petrini -
jpetrini＠coredial.com