[SR-Users] (no subject)
John Petrini
jpetrini at coredial.com
Mon Jul 4 15:13:02 CEST 2016
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.
On Mon, Jul 4, 2016 at 7:15 AM, Daniel-Constantin Mierla <miconda at 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 at 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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160704/e9d14269/attachment.html>
More information about the sr-users
mailing list