[SR-Users] (no subject)
John Petrini
jpetrini at coredial.com
Wed Jul 6 00:25:41 CEST 2016
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 at 22.222.22.222
;isup-oli=62>;tag=gK04650084.
To: <sip:4444444444 at s.core.com>;tag=CNAM-11144-1467649116955.
Call-ID: 201625658_65946715 at 22.222.22.222.
CSeq: 852627 INVITE.
Contact: "CNAM" <sip:cnam_gw at 10.212.16.31>; transport=udp.
Max-Forwards: 10.
P-Asserted-Identity: "Unavailable" <sip:+12222222222 at 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 at 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 at ns.core.com;trans-type=5
From: sip:+12222222222 at 22.222.22.222;isup-oli=62 (22.222.22.222) To:
sip:4444444444 at s.core.com UA: <null> CID: 203428094_132100710 at 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 at 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 at 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 at 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 at 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 at 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 at gmail.com>
>> *Sent: *Monday, July 4, 2016 9:38 AM
>> *To: *John Petrini <jpetrini at coredial.com>
>> *Cc: *Kamailio (SER) - Users Mailing List <sr-users at 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 at core.com:5060 SIP/2.0.
>>
>> Via: SIP/2.0/UDP 44.444.4.444:5060;branch=z9hG4bK04Bef9112d99372eace.
>>
>> From: "UNKNOWN" <sip:+13333333333 at 44.444.4.444;isup-oli=62>
>> ;tag=gK046fcff6.
>>
>> To: <sip:2222222222 at core.com>.
>>
>> Call-ID: 1698991986_66771899 at 44.444.4.444.
>>
>> CSeq: 468700 INVITE.
>>
>> Max-Forwards: 70.
>>
>> Allow: INVITE,ACK,CANCEL,BYE,OPTIONS.
>>
>> Accept: application/sdp.
>>
>> Contact: "UNKNOWN" <sip:+13333333333 at 44.444.4.444:5060>.
>>
>> P-Asserted-Identity: "UNKNOWN" <sip:+13333333333 at 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 at 44.444.4.444;isup-oli=62>
>> ;tag=gK046fcff6.
>>
>> To: <sip:2222222222 at core.com>.
>>
>> Call-ID: 1698991986_66771899 at 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 at 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 at sip.core.com>;tag=gK046fcff6.
>>
>> To: <sip:2222222222 at core.com>.
>>
>> Call-ID: 1698991986_66771899 at 44.444.4.444.
>>
>> CSeq: 468700 INVITE.
>>
>> Max-Forwards: 69.
>>
>> Allow: INVITE,ACK,CANCEL,BYE,OPTIONS.
>>
>> Accept: application/sdp.
>>
>> Contact: "UNKNOWN" <sip:+13333333333 at 44.444.4.444:5060>.
>>
>> P-Asserted-Identity: "UNKNOWN" <sip:+13333333333 at 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 at sip.core.com>;tag=gK046fcff6.
>>
>> To: <sip:2222222222 at core.com>;tag=CNAM-16688-1467636671937.
>>
>> Call-ID: 1698991986_66771899 at 44.444.4.444.
>>
>> CSeq: 468700 INVITE.
>>
>> Contact: "CNAM" <sip:cnam_gw at 10.212.16.30>; transport=udp.
>>
>> Max-Forwards: 10.
>>
>> P-Asserted-Identity: "Unavailable" <sip:+13333333333 at 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 at 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 at sip.core.com>;tag=gK046fcff6.
>>
>> To: <sip:2222222222 at core.com>;tag=CNAM-16688-1467636671937.
>>
>> Call-ID: 1698991986_66771899 at 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 at 44.444.4.444;isup-oli=62>
>> ;tag=gK046fcff6.
>>
>> To: <sip:2222222222 at core.com>;tag=CNAM-16688-1467636671937.
>>
>> Call-ID: 1698991986_66771899 at 44.444.4.444.
>>
>> CSeq: 468700 INVITE.
>>
>> Contact: "CNAM" <sip:cnam_gw at 10.212.16.30>; transport=udp.
>>
>> Max-Forwards: 10.
>>
>> P-Asserted-Identity: "Unavailable" <sip:+13333333333 at 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 at 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160705/fedb2fad/attachment.html>
More information about the sr-users
mailing list