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@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   //   Twitter   LinkedIn   Google Plus   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

Exceptional people. Proven Processes. Innovative Technology. Discover CoreDial - watch our video

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();
  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


-- 
Daniel-Constantin Mierla
http://www.asipto.com - http://www.kamailio.org
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda