Hello,
the forward() doesn't take variables as parameter, you have to set $ru or $du to the address where you want to send and then just use forward().
Also, rewrite*() functions do not work with variables.
In assignments, inside the strings of expressions, the vars are not evaluated, you need to use concatenation (+):
$du = "sip:" + $var(cancel_dst) + ":5060;transport=udp";
Cheers, Daniel
On 21/03/16 13:17, Grant Bagdasarian wrote:
Hi Daniel,
I’ve tried with htable implementation, but I can’t seem to use a variable as the argument for the forward function.
I’ve tried multiple possibilities:
forward($avp(s:cancel_dst));
forward(“$avp(s:cancel_dst)”);
forward($var(cancel_dst));
forward(“$var(cancel_dst)”);
forward($sht(cancel=>$ci));
forward(“$sht(cancel=>$ci)”);
I keep getting the following error:
CRITICAL: <core> [proxy.c:265]: mk_proxy(): could not resolve hostname: "$avp(s:cancel_dst)"
Or when I don’t enclose the variable in quotes an error about the parameter requiring a string.
I’ve also tried using the following steps, but rewritehost doesn’t allow variables too L
rewritehost(“$var(cancel_dst)”);
$du = "sip:$var(cancel_dst):5060;transport=udp";
Any ideas?
Regards,
Grant
*From:*sr-users [mailto:sr-users-bounces@lists.sip-router.org] *On Behalf Of *Grant Bagdasarian *Sent:* Monday, March 21, 2016 10:01 AM *To:* 'miconda@gmail.com' miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org *Subject:* Re: [SR-Users] Kamailio 4.3.4: receive_msg(): no via found in reply
Hello Daniel,
Thank you for figuring this out and explaining it to me! This has helped me a lot!
Regards,
Grant
*From:*Daniel-Constantin Mierla [mailto:miconda@gmail.com] *Sent:* Friday, March 18, 2016 4:33 PM *To:* Grant Bagdasarian <gb@cm.nl mailto:gb@cm.nl>; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.org mailto:sr-users@lists.sip-router.org> *Subject:* Re: [SR-Users] Kamailio 4.3.4: receive_msg(): no via found in reply
Hello,
the problem is that the device you interconnect with (Server: sbc_5) is not sending all the Via headers from INVITE in the 487 -- it is only one Via:
# U 10.0.0.1:5060 -> 10.14.0.1:5060
SIP/2.0 487 Request Cancelled. Via: SIP/2.0/UDP 10.14.0.1;branch=z9hG4bK3c3b.a6603e0f92db305f775f8bf1d95dc7d9.0. From: "+31612345678" sip:+31612345678@10.14.0.3:5060 sip:+31612345678@10.14.0.3:5060;tag=1f15682a. To: sip:0031123456789@10.14.0.3:5060 sip:0031123456789@10.14.0.3:5060;tag=sbcsipuas_1_C52464_20160314100333554_b12sb10. Call-ID: 78100ZGIyZGM2ZTY4ODM4YWZlZGFjNTBjMDZmYjQzMzBkOGI. Contact: sip:10.0.0.1:5060 sip:10.0.0.1:5060. CSeq: 2 INVITE. Server: sbc_5. Content-Length: 0.
Notice the 100 trying Via stack:
# U 10.0.0.1:5060 -> 10.14.0.1:5060
SIP/2.0 100 Trying. Via: SIP/2.0/UDP 10.14.0.1;branch=z9hG4bK3c3b.a6603e0f92db305f775f8bf1d95dc7d9.0. Via: SIP/2.0/UDP 10.14.0.2;branch=z9hG4bK3c3b.6002c178e1a0751f80857e10c4caeb35.0. Via: SIP/2.0/UDP 10.14.0.3;branch=z9hG4bK3c3b.9cad3c629aa5c2985e543c285f2f6d1d.0. Via: SIP/2.0/UDP 10.14.0.3;branch=z9hG4bKsr-jNXap0IRuJngh6iFuS1xpYUspYiRWQikWSisuQfjcQKOM-8C8odTwzW4V-4LMU1N8O2fWSINuYFmpSUfpcKXuq8NW0is8YdObqasuQuP. From: "+31612345678" sip:+31612345678@10.14.0.3:5060 sip:+31612345678@10.14.0.3:5060;tag=1f15682a. To: sip:0031123456789@10.14.0.3:5060 sip:0031123456789@10.14.0.3:5060. Call-ID: 78100ZGIyZGM2ZTY4ODM4YWZlZGFjNTBjMDZmYjQzMzBkOGI. Contact: sip:10.0.0.1:5060 sip:10.0.0.1:5060. CSeq: 2 INVITE. Server: sbc_5. Content-Length: 0.
My guess that the sbc_5 is so poor implemented that it takes the Via from last request, which is CANCEL, but CANCEL is a hop-by-hop request in this case. If my guess is confirmed, the implementation of sbc_5 is really far away from RFC3261, something that I haven't probably seen since 2002/3.
To test, you can try to use forward() for CANCEL instead of t_relay(). But you need to know where to send it -- same address as for INVITE -- you can hardcode some values in config for sake of simplicity to test. A proper workaround can be built using htable module to store where the invite was sent, using call-id as a key.
Cheers, Daniel
On 18/03/16 15:43, Grant Bagdasarian wrote:
Hi Daniel, No problem J Our devices are kamailios. Our customers use different equipment for sending traffic and I’m not sure what kind of equipment our carriers are using. So, I can’t really tell what device they’re using. My test was done using Bria (X-Lite) acting as a “customer”. Regards, Grant *From:*Daniel-Constantin Mierla [mailto:miconda@gmail.com] *Sent:* Friday, March 18, 2016 10:25 AM *To:* Grant Bagdasarian <gb@cm.nl> <mailto:gb@cm.nl>; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.org> <mailto:sr-users@lists.sip-router.org> *Subject:* Re: [SR-Users] Kamailio 4.3.4: receive_msg(): no via found in reply Hello, with CeBIT trip this week, I didn't get the change to look too much at it... What is the device sending the reply to INVITE? Cheers, Daniel On 18/03/16 10:05, Grant Bagdasarian wrote: Hello Community, Could someone point me into the right direction for fixing this issue with CANCEL replies? Regards, Grant *From:*sr-users [mailto:sr-users-bounces@lists.sip-router.org] *On Behalf Of *Grant Bagdasarian *Sent:* Tuesday, March 15, 2016 8:47 PM *To:* 'miconda@gmail.com <mailto:miconda@gmail.com>' <miconda@gmail.com> <mailto:miconda@gmail.com>; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.org> <mailto:sr-users@lists.sip-router.org> *Subject:* Re: [SR-Users] Kamailio 4.3.4: receive_msg(): no via found in reply Any ideas how to solve this? Regards, Grant ------------------------------------------------------------------------ *From:*sr-users <sr-users-bounces@lists.sip-router.org <mailto:sr-users-bounces@lists.sip-router.org>> on behalf of Grant Bagdasarian <gb@cm.nl <mailto:gb@cm.nl>> *Sent:* Monday, March 14, 2016 3:09:47 PM *To:* 'miconda@gmail.com <mailto:miconda@gmail.com>'; Kamailio (SER) - Users Mailing List *Subject:* Re: [SR-Users] Kamailio 4.3.4: receive_msg(): no via found in reply Hello Daniel, Carrier: 10.0.0.1 Kamailio 1: 10.14.0.1 Kamailio 2: 10.14.0.2 I also removed the SDP from the INVITE and the 183 messages. This is the trace from the Kamailio which directly communicates with the Carrier. U 10.14.0.2:5060 -> 10.14.0.1:5060 INVITE sip:0031123456789@10.14.0.1:5060SIP/2.0. Record-Route: <sip:10.14.0.2;lr=on>. Record-Route: <sip:10.14.0.3;lr=on>. Via: SIP/2.0/UDP 10.14.0.2;branch=z9hG4bK3c3b.6002c178e1a0751f80857e10c4caeb35.0. Via: SIP/2.0/UDP 10.14.0.3;branch=z9hG4bK3c3b.9cad3c629aa5c2985e543c285f2f6d1d.0. Via: SIP/2.0/UDP 10.14.0.3;branch=z9hG4bKsr-jNXap0IRuJngh6iFuS1xpYUspYiRWQikWSisuQfjcQKOM-8C8odTwzW4V-4LMU1N8O2fWSINuYFmpSUfpcKXuq8NW0is8YdObqasuQuP. Max-Forwards: 68. Contact: <sip:10.14.0.3;line=sr-1sX9bA20uS8PuS8NWSFPWUiPW0IRuS8RuJHNuQ4KuQ89>. To: <sip:0031123456789@10.14.0.3:5060>. From: "+31612345678"<sip:+31612345678@10.14.0.3:5060>;tag=1f15682a. Call-ID: 78100ZGIyZGM2ZTY4ODM4YWZlZGFjNTBjMDZmYjQzMzBkOGI. CSeq: 2 INVITE. Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, MESSAGE. Content-Type: application/sdp. User-Agent: Bria 4 release 4.2.1 stamp 78100. Content-Length: 431. # U 10.14.0.1:5060 -> 10.14.0.2:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 10.14.0.2;branch=z9hG4bK3c3b.6002c178e1a0751f80857e10c4caeb35.0. Via: SIP/2.0/UDP 10.14.0.3;branch=z9hG4bK3c3b.9cad3c629aa5c2985e543c285f2f6d1d.0. Via: SIP/2.0/UDP 10.14.0.3;branch=z9hG4bKsr-jNXap0IRuJngh6iFuS1xpYUspYiRWQikWSisuQfjcQKOM-8C8odTwzW4V-4LMU1N8O2fWSINuYFmpSUfpcKXuq8NW0is8YdObqasuQuP. To: <sip:0031123456789@10.14.0.3:5060>. From: "+31612345678"<sip:+31612345678@10.14.0.3:5060>;tag=1f15682a. Call-ID: 78100ZGIyZGM2ZTY4ODM4YWZlZGFjNTBjMDZmYjQzMzBkOGI. CSeq: 2 INVITE. Server: kamailio (4.3.4 (x86_64/linux)). Content-Length: 0. . # U 10.14.0.1:5060 -> 10.0.0.1:5060 INVITE sip:0031123456789@10.0.0.1:5060SIP/2.0. Record-Route: <sip:10.14.0.1;lr=on>. Record-Route: <sip:10.14.0.2;lr=on>. Record-Route: <sip:10.14.0.3;lr=on>. Via: SIP/2.0/UDP 10.14.0.1;branch=z9hG4bK3c3b.a6603e0f92db305f775f8bf1d95dc7d9.0. Via: SIP/2.0/UDP 10.14.0.2;branch=z9hG4bK3c3b.6002c178e1a0751f80857e10c4caeb35.0. Via: SIP/2.0/UDP 10.14.0.3;branch=z9hG4bK3c3b.9cad3c629aa5c2985e543c285f2f6d1d.0. Via: SIP/2.0/UDP 10.14.0.3;branch=z9hG4bKsr-jNXap0IRuJngh6iFuS1xpYUspYiRWQikWSisuQfjcQKOM-8C8odTwzW4V-4LMU1N8O2fWSINuYFmpSUfpcKXuq8NW0is8YdObqasuQuP. Max-Forwards: 67. Contact: <sip:10.14.0.3;line=sr-1sX9bA20uS8PuS8NWSFPWUiPW0IRuS8RuJHNuQ4KuQ89>. To: <sip:0031123456789@10.14.0.3:5060>. From: "+31612345678"<sip:+31612345678@10.14.0.3:5060>;tag=1f15682a. Call-ID: 78100ZGIyZGM2ZTY4ODM4YWZlZGFjNTBjMDZmYjQzMzBkOGI. CSeq: 2 INVITE. Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, MESSAGE. Content-Type: application/sdp. User-Agent: Bria 4 release 4.2.1 stamp 78100. Content-Length: 431. # U 10.0.0.1:5060 -> 10.14.0.1:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 10.14.0.1;branch=z9hG4bK3c3b.a6603e0f92db305f775f8bf1d95dc7d9.0. Via: SIP/2.0/UDP 10.14.0.2;branch=z9hG4bK3c3b.6002c178e1a0751f80857e10c4caeb35.0. Via: SIP/2.0/UDP 10.14.0.3;branch=z9hG4bK3c3b.9cad3c629aa5c2985e543c285f2f6d1d.0. Via: SIP/2.0/UDP 10.14.0.3;branch=z9hG4bKsr-jNXap0IRuJngh6iFuS1xpYUspYiRWQikWSisuQfjcQKOM-8C8odTwzW4V-4LMU1N8O2fWSINuYFmpSUfpcKXuq8NW0is8YdObqasuQuP. From: "+31612345678" <sip:+31612345678@10.14.0.3:5060>;tag=1f15682a. To: <sip:0031123456789@10.14.0.3:5060>. Call-ID: 78100ZGIyZGM2ZTY4ODM4YWZlZGFjNTBjMDZmYjQzMzBkOGI. Contact: <sip:10.0.0.1:5060>. CSeq: 2 INVITE. Server: sbc_5. Content-Length: 0. . # U 10.14.0.2:5060 -> 10.14.0.1:5060 CANCEL sip:0031123456789@10.14.0.1:5060SIP/2.0. Via: SIP/2.0/UDP 10.14.0.2;branch=z9hG4bK3c3b.6002c178e1a0751f80857e10c4caeb35.0. Max-Forwards: 68. To: <sip:0031123456789@10.14.0.3:5060>. From: "+31612345678"<sip:+31612345678@10.14.0.3:5060>;tag=1f15682a. Call-ID: 78100ZGIyZGM2ZTY4ODM4YWZlZGFjNTBjMDZmYjQzMzBkOGI. CSeq: 2 CANCEL. Content-Length: 0. . # U 10.14.0.1:5060 -> 10.0.0.1:5060 CANCEL sip:0031123456789@10.0.0.1:5060SIP/2.0. Via: SIP/2.0/UDP 10.14.0.1;branch=z9hG4bK3c3b.a6603e0f92db305f775f8bf1d95dc7d9.0. Max-Forwards: 67. To: <sip:0031123456789@10.14.0.3:5060>. From: "+31612345678"<sip:+31612345678@10.14.0.3:5060>;tag=1f15682a. Call-ID: 78100ZGIyZGM2ZTY4ODM4YWZlZGFjNTBjMDZmYjQzMzBkOGI. CSeq: 2 CANCEL. Content-Length: 0. . # U 10.14.0.1:5060 -> 10.14.0.2:5060 SIP/2.0 200 canceling. Via: SIP/2.0/UDP 10.14.0.2;branch=z9hG4bK3c3b.6002c178e1a0751f80857e10c4caeb35.0. To: <sip:0031123456789@10.14.0.3:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-52bb. From: "+31612345678"<sip:+31612345678@10.14.0.3:5060>;tag=1f15682a. Call-ID: 78100ZGIyZGM2ZTY4ODM4YWZlZGFjNTBjMDZmYjQzMzBkOGI. CSeq: 2 CANCEL. Server: kamailio (4.3.4 (x86_64/linux)). Content-Length: 0. . # U 10.0.0.1:5060 -> 10.14.0.1:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.14.0.1;branch=z9hG4bK3c3b.a6603e0f92db305f775f8bf1d95dc7d9.0. From: "+31612345678" <sip:+31612345678@10.14.0.3:5060>;tag=1f15682a. To: <sip:0031123456789@10.14.0.3:5060>. Call-ID: 78100ZGIyZGM2ZTY4ODM4YWZlZGFjNTBjMDZmYjQzMzBkOGI. CSeq: 2 CANCEL. Server: sbc_5. Content-Length: 0. . # U 10.0.0.1:5060 -> 10.14.0.1:5060 SIP/2.0 487 Request Cancelled. Via: SIP/2.0/UDP 10.14.0.1;branch=z9hG4bK3c3b.a6603e0f92db305f775f8bf1d95dc7d9.0. From: "+31612345678" <sip:+31612345678@10.14.0.3:5060>;tag=1f15682a. To: <sip:0031123456789@10.14.0.3:5060>;tag=sbcsipuas_1_C52464_20160314100333554_b12sb10. Call-ID: 78100ZGIyZGM2ZTY4ODM4YWZlZGFjNTBjMDZmYjQzMzBkOGI. Contact: <sip:10.0.0.1:5060>. CSeq: 2 INVITE. Server: sbc_5. Content-Length: 0. . # U 10.14.0.1:5060 -> 10.0.0.1:5060 ACK sip:0031123456789@10.0.0.1:5060SIP/2.0. Via: SIP/2.0/UDP 10.14.0.1;branch=z9hG4bK3c3b.a6603e0f92db305f775f8bf1d95dc7d9.0. Max-Forwards: 67. To: <sip:0031123456789@10.14.0.3:5060>;tag=sbcsipuas_1_C52464_20160314100333554_b12sb10. From: "+31612345678"<sip:+31612345678@10.14.0.3:5060>;tag=1f15682a. Call-ID: 78100ZGIyZGM2ZTY4ODM4YWZlZGFjNTBjMDZmYjQzMzBkOGI. CSeq: 2 ACK. Content-Length: 0. . # U 10.14.0.1:5060 -> 10.14.0.2:5060 SIP/2.0 487 Request Cancelled. From: "+31612345678" <sip:+31612345678@10.14.0.3:5060>;tag=1f15682a. To: <sip:0031123456789@10.14.0.3:5060>;tag=sbcsipuas_1_C52464_20160314100333554_b12sb10. Call-ID: 78100ZGIyZGM2ZTY4ODM4YWZlZGFjNTBjMDZmYjQzMzBkOGI. Contact: <sip:10.0.0.1:5060>. CSeq: 2 INVITE. Server: sbc_5. Content-Length: 0. . # U 10.14.0.1:5060 -> 10.14.0.2:5060 SIP/2.0 487 Request Cancelled. From: "+31612345678" <sip:+31612345678@10.14.0.3:5060>;tag=1f15682a. To: <sip:0031123456789@10.14.0.3:5060>;tag=sbcsipuas_1_C52464_20160314100333554_b12sb10. Call-ID: 78100ZGIyZGM2ZTY4ODM4YWZlZGFjNTBjMDZmYjQzMzBkOGI. Contact: <sip:10.0.0.1:5060>. CSeq: 2 INVITE. Server: sbc_5. Content-Length: 0. . # U 10.14.0.1:5060 -> 10.14.0.2:5060 SIP/2.0 487 Request Cancelled. From: "+31612345678" <sip:+31612345678@10.14.0.3:5060>;tag=1f15682a. To: <sip:0031123456789@10.14.0.3:5060>;tag=sbcsipuas_1_C52464_20160314100333554_b12sb10. Call-ID: 78100ZGIyZGM2ZTY4ODM4YWZlZGFjNTBjMDZmYjQzMzBkOGI. Contact: <sip:10.0.0.1:5060>. CSeq: 2 INVITE. Server: sbc_5. Content-Length: 0. . # U 10.14.0.1:5060 -> 10.14.0.2:5060 SIP/2.0 487 Request Cancelled. From: "+31612345678" <sip:+31612345678@10.14.0.3:5060>;tag=1f15682a. To: <sip:0031123456789@10.14.0.3:5060>;tag=sbcsipuas_1_C52464_20160314100333554_b12sb10. Call-ID: 78100ZGIyZGM2ZTY4ODM4YWZlZGFjNTBjMDZmYjQzMzBkOGI. Contact: <sip:10.0.0.1:5060>. CSeq: 2 INVITE. Server: sbc_5. Content-Length: 0. . *From:*sr-users [mailto:sr-users-bounces@lists.sip-router.org] *On Behalf Of *Daniel-Constantin Mierla *Sent:* Monday, March 14, 2016 2:44 PM *To:* Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org>> *Subject:* Re: [SR-Users] Kamailio 4.3.4: receive_msg(): no via found in reply Hello, what would be relevant here is seeing the INVITE request sent to 10.14.0.1:5060 -- paste it to the mailing list discussion. That is going to be used to generate 487, and the Via stack from it should be used there. Cheers, Daniel On 14/03/16 13:23, Grant Bagdasarian wrote: Hello, We’re testing kamailio 4.3.4 with two kamailio’s communicating with each other. One of them is a gateway with rtpengine at the carrier side, the other is a basic sip router. When calling a destination and cancelling the INVITE a 487 is received from the carrier and directly ACK’d by the first kamailio and in turn is forwarded to the second. But the 487 response received by the 2^nd kamailio doesn’t have a Via header which results in kamailio printing the error: receive_msg(): no via found in reply. Any ideas why the forwarded 487 doesn’t contain a Via header and how to fix this? Note: IP’s are changed. Carrier: 10.0.0.1 Kamailio 1: 10.14.0.1 Kamailio 2: 10.14.0.2 U 10.0.0.1:5060 -> 10.14.0.1:5060 SIP/2.0 487 Request Cancelled. Via: SIP/2.0/UDP 10.14.0.1;branch=z9hG4bK8e28.642c68037d059634308d4be8fe3f0cdc.0. From: "+31612345678" <sip:+31612345678@10.14.0.3:5060> <sip:+31612345678@10.14.0.3:5060>;tag=109ac722. To: <sip:003112345678@10.14.0.3:5060> <sip:003112345678@10.14.0.3:5060>;tag=sbcsipuas_1_C22196_20160314080307791_b59sb10. Call-ID: 78100MjY3OGExZmMyODU2MzAyMzM5ODA3MmNhMDdlMzg0MzU. Contact: <sip:10.0.0.1:5060> <sip:10.0.0.1:5060>. CSeq: 2 INVITE. Server: sbc_5. Content-Length: 0. . # U 10.14.0.1:5060 -> 10.0.0.1:5060 ACK sip:003112345678@10.0.0.1:5060SIP/2.0. Via: SIP/2.0/UDP 10.14.0.1;branch=z9hG4bK8e28.642c68037d059634308d4be8fe3f0cdc.0. Max-Forwards: 67. To: <sip:003112345678@10.14.0.3:5060> <sip:003112345678@10.14.0.3:5060>;tag=sbcsipuas_1_C22196_20160314080307791_b59sb10. From: "+31612345678"<sip:+31612345678@10.14.0.3:5060> <sip:+31612345678@10.14.0.3:5060>;tag=109ac722. Call-ID: 78100MjY3OGExZmMyODU2MzAyMzM5ODA3MmNhMDdlMzg0MzU. CSeq: 2 ACK. Content-Length: 0. . # U 10.14.0.1:5060 -> 10.14.0.2:5060 SIP/2.0 487 Request Cancelled. From: "+31612345678" <sip:+31612345678@10.14.0.3:5060> <sip:+31612345678@10.14.0.3:5060>;tag=109ac722. To: <sip:003112345678@10.14.0.3:5060> <sip:003112345678@10.14.0.3:5060>;tag=sbcsipuas_1_C22196_20160314080307791_b59sb10. Call-ID: 78100MjY3OGExZmMyODU2MzAyMzM5ODA3MmNhMDdlMzg0MzU. Contact: <sip:10.0.0.1:5060> <sip:10.0.0.1:5060>. CSeq: 2 INVITE. Server: sbc_5. Content-Length: 0. _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto: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://twitter.com/#!/miconda <http://twitter.com/#%21/miconda>- http://www.linkedin.com/in/miconda Kamailio World Conference, Berlin, May 18-20, 2016 - http://www.kamailioworld.com -- Daniel-Constantin Mierla http://www.asipto.com http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda>- http://www.linkedin.com/in/miconda Kamailio World Conference, Berlin, May 18-20, 2016 - http://www.kamailioworld.com-- Daniel-Constantin Mierla http://www.asipto.com http://twitter.com/#!/miconda http://twitter.com/#%21/miconda- http://www.linkedin.com/in/miconda Kamailio World Conference, Berlin, May 18-20, 2016 - http://www.kamailioworld.com