4 Jul
2016
4 Jul
'16
4:13 p.m.
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 + "(a)sip.core.com".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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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