21 Mar
2016
21 Mar
'16
8:07 p.m.
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(a)gmail.com' <miconda(a)gmail.com>om>; Kamailio (SER) - Users
Mailing List <sr-users(a)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(a)cm.nl <mailto:gb@cm.nl>>; Kamailio (SER) -
Users Mailing List <sr-users(a)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(a)cm.nl> <mailto:gb@cm.nl>; Kamailio
(SER) - Users Mailing List <sr-users(a)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(a)gmail.com <mailto:miconda@gmail.com>'
<miconda(a)gmail.com> <mailto:miconda@gmail.com>; Kamailio (SER)
- Users Mailing List <sr-users(a)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(a)lists.sip-router.org
<mailto:sr-users-bounces@lists.sip-router.org>> on behalf of
Grant Bagdasarian <gb(a)cm.nl <mailto:gb@cm.nl>>
*Sent:* Monday, March 14, 2016 3:09:47 PM
*To:* 'miconda(a)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(a)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(a)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
--
Daniel-Constantin Mierla
http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, Berlin, May 18-20, 2016 - http://www.kamailioworld.com