[SR-Users] (no subject)
Daniel-Constantin Mierla
miconda at gmail.com
Wed Jul 6 09:11:53 CEST 2016
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 at 22.222.22.222
> <mailto:sip%3A%2B12222222222 at 22.222.22.222>;isup-oli=62>;tag=gK04650084.
> To: <sip:4444444444 at s.core.com
> <mailto:sip%3A4444444444 at s.core.com>>;tag=CNAM-11144-1467649116955.
> Call-ID: 201625658_65946715 at 22.222.22.222
> <mailto:201625658_65946715 at 22.222.22.222>.
> CSeq: 852627 INVITE.
> Contact: "CNAM" <sip:cnam_gw at 10.212.16.31
> <mailto:sip%3Acnam_gw at 10.212.16.31>>; transport=udp.
> Max-Forwards: 10.
> P-Asserted-Identity: "Unavailable" <sip:+12222222222 at sip.core.com
> <mailto:sip%3A%2B12222222222 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
> <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 at 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 at ns.core.com
> <mailto:sip%3A2152974400 at ns.core.com>;trans-type=5 From:
> sip:+12222222222 at 22.222.22.222
> <mailto:sip%3A%2B12222222222 at 22.222.22.222>;isup-oli=62
> (22.222.22.222) To: sip:4444444444 at s.core.com
> <mailto:sip%3A4444444444 at s.core.com> UA: <null> CID:
> 203428094_132100710 at 22.222.22.222
> <mailto: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
> <mailto: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
> <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 at coredial.com
> <mailto:jpetrini at 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 at gmail.com <mailto: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
> <mailto: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 <mailto:miconda at gmail.com>
>> *Sent: *Monday, July 4, 2016 9:38 AM
>> *To: *John Petrini <mailto:jpetrini at coredial.com>
>> *Cc: *Kamailio (SER) - Users Mailing List
>> <mailto: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
>> <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 at 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 at 44.444.4.444;isup-oli=62>;tag=gK046fcff6.
>>
>> To: <sip:2222222222 at core.com
>> <mailto:sip%3A2222222222 at core.com>>.
>>
>> Call-ID: 1698991986_66771899 at 44.444.4.444
>> <mailto: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
>> <mailto:sip%3A2222222222 at core.com>>.
>>
>> Call-ID: 1698991986_66771899 at 44.444.4.444
>> <mailto: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 <http://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
>> <mailto:sip%3A%2B13333333333 at sip.core.com>>;tag=gK046fcff6.
>>
>> To: <sip:2222222222 at core.com
>> <mailto:sip%3A2222222222 at core.com>>.
>>
>> Call-ID: 1698991986_66771899 at 44.444.4.444
>> <mailto: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
>> <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 at sip.core.com
>> <mailto:sip%3A%2B13333333333 at sip.core.com>>;tag=gK046fcff6.
>>
>> To: <sip:2222222222 at core.com
>> <mailto:sip%3A2222222222 at core.com>>;tag=CNAM-16688-1467636671937.
>>
>> Call-ID: 1698991986_66771899 at 44.444.4.444
>> <mailto:1698991986_66771899 at 44.444.4.444>.
>>
>> CSeq: 468700 INVITE.
>>
>> Contact: "CNAM" <sip:cnam_gw at 10.212.16.30
>> <mailto:sip%3Acnam_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 <http://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
>> <mailto:sip%3A%2B13333333333 at sip.core.com>>;tag=gK046fcff6.
>>
>> To: <sip:2222222222 at core.com
>> <mailto:sip%3A2222222222 at core.com>>;tag=CNAM-16688-1467636671937.
>>
>> Call-ID: 1698991986_66771899 at 44.444.4.444
>> <mailto: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
>> <mailto:sip%3A2222222222 at core.com>>;tag=CNAM-16688-1467636671937.
>>
>> Call-ID: 1698991986_66771899 at 44.444.4.444
>> <mailto:1698991986_66771899 at 44.444.4.444>.
>>
>> CSeq: 468700 INVITE.
>>
>> Contact: "CNAM" <sip:cnam_gw at 10.212.16.30
>> <mailto:sip%3Acnam_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
>> <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 at coredial.com
>> <mailto:jpetrini at 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
>
>
>
--
Daniel-Constantin Mierla
http://www.asipto.com - http://www.kamailio.org
http://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/20160706/327cb8d0/attachment.html>
More information about the sr-users
mailing list