23 Oct
2014
23 Oct
'14
3:57 p.m.
I seem to be going round in circles… I am trying to use dlg_bridge() from the dialog
module to establish a call between two SIP endpoints. I have tested with Snom phones and
linphone soft phone with the same result.
I get an outbound call to the first (from) end point, I answer the phone… and then
nothing obvious happens.
I can get this same result when using kamcmd or from within the kamailio.cfg. For example
using kamcmd:
kamcmd dlg.bridge_dlg sip:105@mykamailioip sip:106@mykamailioip sip:mykamailioip:5060
I expected this to send an invite from "controller" via my KamailioIP to my
registered local subscriber 105 (from), and then send a re-invite to 105 so that 105
creates a call leg to 106 (to).
The kamailio.cfg is pretty much the default. I am running 4.2 and rtpengine to proxy the
RTP streams.
Not sure if it is necessary or useful but I call setflag() at the start of the
request_route() to set the Dialog flag. What else should I have included in the
kamailio.cfg to make this work?
Also is there any way to control the SDP in the initial invite from dlg_bridge. By
default I see RTP/AVP, with alaw and ulaw…. I’d like to offer RTP/SAVP swell or instead of
RTP/AVP.
Thanks
23 Oct
23 Oct
4:39 p.m.
Hello,
what should be happen, is the following:
- invite from controller to first parameter (caller of desired call)
- after 200ok comes from 'caller', kamailio sends REFER to it pointing
to the second parameter (callee of desired call) and then BYE, getting
out of the initial call
- after getting the REFER, caller should send a new INVITE to callee
You can run with debug=3 to see what happens. In kamailio config is
nothing special needed, just allow traffic from kamailio to go back to
kamailio.
Cheers,
Daniel
On 23/10/14 15:57, Paul Smith wrote:
I seem to be going round in circles… I am trying to
use dlg_bridge()
from the dialog module to establish a call between two SIP endpoints.
I have tested with Snom phones and linphone soft phone with the same
result.
I get an outbound call to the first (from) end point, I answer the
phone… and then nothing obvious happens.
I can get this same result when using kamcmd or from within the
kamailio.cfg. For example using kamcmd:
kamcmd dlg.bridge_dlg sip:105@mykamailioip sip:106@mykamailioip
sip:mykamailioip:5060
I expected this to send an invite from "controller" via my KamailioIP
to my registered local subscriber 105 (from), and then send a
re-invite to 105 so that 105 creates a call leg to 106 (to).
The kamailio.cfg is pretty much the default. I am running 4.2 and
rtpengine to proxy the RTP streams.
Not sure if it is necessary or useful but I call setflag() at the
start of the request_route() to set the Dialog flag. What else should
I have included in the kamailio.cfg to make this work?
Also is there any way to control the SDP in the initial invite from
dlg_bridge. By default I see RTP/AVP, with alaw and ulaw…. I’d like
to offer RTP/SAVP swell or instead of RTP/AVP.
Thanks
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
24 Oct
24 Oct
11:09 a.m.
Thank you for the reply Daniel. I have enabled debug=3 and put in a few more xlog lines.
I can see the REFER coming in on local interface 127.0.0.1. I am now trying to narrow
down the issue in the kamailio.cfg.
My conclusions so far are:
1) The REFER packet has a problem which causes it to fail sanity_check()
2) sanity_check returns 0=exit rather than -1 = error.
I have 2 snom phones registered to the kamailio server over NAT and can make calls between
them.
The REFER is failing in the REQINIT route block. The script stops there.
Kamailio.cfg : I started again with default 4.2 and kamailio.cfg as shipped enabled MYSQL,
USRLOCDB, inserted dialog module, replaced rtpproxy with rtpengine.
#!define WITH_MYSQL
#!define WITH_AUTH
#!define WITH_USRLOCDB
#!define WITH_NAT
amended REQINIT as follows. I see log lines for “going to sanity check” but neither
“Malformed” or “returning” line are reached.
...
if (is_method("REFER")) {xlog("L_INFO","REFER going to
sanity check\n");}
if(!sanity_check("1511", "7")) {
xlog("L_INFO","Malformed SIP message from
$si:$sp\n");
exit;
}
if (is_method("REFER")) {xlog("L_INFO","REFER returning
OK from sanity check");}
...
Then run from the command line:
kamcmd dlg.bridge_dlg sip:105@MYPUBLICIP sip:106@MYPUBLICIP sip:MYPUBLICIP:5060
Kamailio Output:
2(32566) DEBUG: <core> [parser/msg_parser.c:623]: parse_msg(): SIP Request:
2(32566) DEBUG: <core> [parser/msg_parser.c:625]: parse_msg(): method:
<REFER>
2(32566) DEBUG: <core> [parser/msg_parser.c:627]: parse_msg(): uri:
<sip:105@192.168.1.15:1082;transport=tcp;line=5twzz1pj>
2(32566) DEBUG: <core> [parser/msg_parser.c:629]: parse_msg(): version:
<SIP/2.0>
2(32566) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param
type 232, <branch> = <z9hG4bKf666.1955cd53000000000000000000000000.0>;
state=16
2(32566) DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header
reached, state=5
2(32566) DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers:
Via found, flags=2
2(32566) DEBUG: <core> [parser/msg_parser.c:515]: parse_headers(): parse_headers:
this is the first via
2(32566) DEBUG: <core> [receive.c:154]: receive_msg(): After parse_msg...
2(32566) DEBUG: <core> [receive.c:197]: receive_msg(): preparing to run routing
scripts...
2(32566) INFO: <script>: --- SCRIPT Got a REFER packet from MYPUBLICIP to
sip:105@192.168.1.15:1082;transport=tcp;line=5twzz1pj --
2(32566) DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG:
add_param: tag=wg03aczruz
2(32566) DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of
header reached, state=29
2(32566) DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG:
get_hdr_field: <To> [41]; uri=[sip:105@MYPUBLICIP]
2(32566) DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body
[<sip:105@MYPUBLICIP>]
2(32566) DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field:
cseq <CSeq>: <11> <REFER>
2(32566) DEBUG: maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value = 70
2(32566) INFO: <script>: REFER going to sanity check
2(32566) DEBUG: <core> [parser/msg_parser.c:204]: get_hdr_field(): DEBUG:
get_hdr_body : content_length=0
2(32566) DEBUG: sanity [mod_sanity.c:255]: w_sanity_check(): sanity checks result: 0
On 23 Oct 2014, at 15:39, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
Hello,
what should be happen, is the following:
- invite from controller to first parameter (caller of desired call)
- after 200ok comes from 'caller', kamailio sends REFER to it pointing to the
second parameter (callee of desired call) and then BYE, getting out of the initial call
- after getting the REFER, caller should send a new INVITE to callee
You can run with debug=3 to see what happens. In kamailio config is nothing special
needed, just allow traffic from kamailio to go back to kamailio.
Cheers,
Daniel
12:07 p.m.
I added a log line to the top of kamailio.cfg request_route block to grab the message
buffer of the REFER. I also put a condition around the sanity_check to skip it for
method=REFER …
I got the following output for $mb at the start of request_route for the REFER packet (I
have substituted MYPUBLICIP for my ip address)
2(341) INFO: <script>: --- SCRIPT Got a REFER packet from MYPUBLICIP to
sip:105@MYPUBLICIP:1095;transport=tcp;line=5twzz1pj with message buffer REFER
sip:105@192.168.1.15:1095;transport=tcp;line=5twzz1pj SIP/2.0
Via: SIP/2.0/UDP MYPUBLICIP;branch=z9hG4bKcfed.c87adfb2000000000000000000000000.0
To: <sip:105@MYPUBLICIP>;tag=q42s05ts0b
From: <sip:controller@kamailio.org>;tag=48329130e552128b3c54a5eeb8c86eea-03b0
CSeq: 11 REFER
Call-ID: 1a37a04a3bd8d656-347@MYPUBLICIP
Route: <sip:MYPUBLICIP;r2=on;lr;did=cd7.3482;nat=yes>,
<sip:MYPUBLICIP;transport=tcp;r2=on;lr;did=cd7.3482;nat=yes>
Max-Forwards: 70
Content-Length: 0
User-Agent: kamailio (4.2.0 (x86_64/linux))
Referred-By: sip:controller@kamailio.org
Refer-To: sip:106@MYPUBLICIP
sip:controller@kamailio.org
The last line does not look right to me … why is there a sip uri at the end of the message
buffer with no field name.
later on in the output I see:
Oct 24 10:50:27 KamTesting002 kamailio[402]: DEBUG: tm [t_lookup.c:1373]: t_newtran():
DEBUG: t_newtran: msg id=2 , global msg id=1 , T on entrance=0xffffffffffffffff
Oct 24 10:50:27 KamTesting002 kamailio[402]: ERROR: tm [t_lookup.c:1403]: t_newtran():
ERROR: t_newtran: EoH not parsed
On 24 Oct 2014, at 10:09, Paul Smith <paul.smith(a)claritytele.com> wrote:
Thank you for the reply Daniel. I have enabled
debug=3 and put in a few more xlog lines. I can see the REFER coming in on local
interface 127.0.0.1. I am now trying to narrow down the issue in the kamailio.cfg.
My conclusions so far are:
1) The REFER packet has a problem which causes it to fail sanity_check()
2) sanity_check returns 0=exit rather than -1 = error.
I have 2 snom phones registered to the kamailio server over NAT and can make calls
between them.
The REFER is failing in the REQINIT route block. The script stops there.
Kamailio.cfg : I started again with default 4.2 and kamailio.cfg as shipped enabled
MYSQL, USRLOCDB, inserted dialog module, replaced rtpproxy with rtpengine.
#!define WITH_MYSQL
#!define WITH_AUTH
#!define WITH_USRLOCDB
#!define WITH_NAT
amended REQINIT as follows. I see log lines for “going to sanity check” but neither
“Malformed” or “returning” line are reached.
...
if (is_method("REFER")) {xlog("L_INFO","REFER going to
sanity check\n");}
if(!sanity_check("1511", "7")) {
xlog("L_INFO","Malformed SIP message from
$si:$sp\n");
exit;
}
if (is_method("REFER")) {xlog("L_INFO","REFER returning
OK from sanity check");}
...
Then run from the command line:
kamcmd dlg.bridge_dlg sip:105@MYPUBLICIP sip:106@MYPUBLICIP sip:MYPUBLICIP:5060
Kamailio Output:
2(32566) DEBUG: <core> [parser/msg_parser.c:623]: parse_msg(): SIP Request:
2(32566) DEBUG: <core> [parser/msg_parser.c:625]: parse_msg(): method:
<REFER>
2(32566) DEBUG: <core> [parser/msg_parser.c:627]: parse_msg(): uri:
<sip:105@192.168.1.15:1082;transport=tcp;line=5twzz1pj>
2(32566) DEBUG: <core> [parser/msg_parser.c:629]: parse_msg(): version:
<SIP/2.0>
2(32566) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param
type 232, <branch> = <z9hG4bKf666.1955cd53000000000000000000000000.0>;
state=16
2(32566) DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header
reached, state=5
2(32566) DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers:
Via found, flags=2
2(32566) DEBUG: <core> [parser/msg_parser.c:515]: parse_headers(): parse_headers:
this is the first via
2(32566) DEBUG: <core> [receive.c:154]: receive_msg(): After parse_msg...
2(32566) DEBUG: <core> [receive.c:197]: receive_msg(): preparing to run routing
scripts...
2(32566) INFO: <script>: --- SCRIPT Got a REFER packet from MYPUBLICIP to
sip:105@192.168.1.15:1082;transport=tcp;line=5twzz1pj --
2(32566) DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG:
add_param: tag=wg03aczruz
2(32566) DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of
header reached, state=29
2(32566) DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG:
get_hdr_field: <To> [41]; uri=[sip:105@MYPUBLICIP]
2(32566) DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body
[<sip:105@MYPUBLICIP>]
2(32566) DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field:
cseq <CSeq>: <11> <REFER>
2(32566) DEBUG: maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value = 70
2(32566) INFO: <script>: REFER going to sanity check
2(32566) DEBUG: <core> [parser/msg_parser.c:204]: get_hdr_field(): DEBUG:
get_hdr_body : content_length=0
2(32566) DEBUG: sanity [mod_sanity.c:255]: w_sanity_check(): sanity checks result: 0
On 23 Oct 2014, at 15:39, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
Hello,
what should be happen, is the following:
- invite from controller to first parameter (caller of desired call)
- after 200ok comes from 'caller', kamailio sends REFER to it pointing to the
second parameter (callee of desired call) and then BYE, getting out of the initial call
- after getting the REFER, caller should send a new INVITE to callee
You can run with debug=3 to see what happens. In kamailio config is nothing special
needed, just allow traffic from kamailio to go back to kamailio.
Cheers,
Daniel
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2:56 p.m.
I don't recall any change to this part for 4.2 and I am using dlg_bridge
with 4.1 (no time to upgrade that box yet) -- but apparently there is a
bug building the REFER. There were few changes on how From/To are built
locally, but they are ok.
I am traveling at Astricon, but with first occasion I will check it.
Cheers,
Daniel
On 24/10/14 12:07, Paul Smith wrote:
I added a log line to the top of kamailio.cfg
request_route block to
grab the message buffer of the REFER. I also put a condition around
the sanity_check to skip it for method=REFER …
I got the following output for $mb at the start of request_route for
the REFER packet (I have substituted MYPUBLICIP for my ip address)
2(341) INFO: <script>: --- SCRIPT Got a REFER packet from MYPUBLICIP
to sip:105@MYPUBLICIP:1095;transport=tcp;line=5twzz1pj with message
buffer REFER sip:105@192.168.1.15:1095;transport=tcp;line=5twzz1pj SIP/2.0
Via: SIP/2.0/UDP
MYPUBLICIP;branch=z9hG4bKcfed.c87adfb2000000000000000000000000.0
To: <sip:105@MYPUBLICIP>;tag=q42s05ts0b
From:
<sip:controller@kamailio.org>;tag=48329130e552128b3c54a5eeb8c86eea-03b0
CSeq: 11 REFER
Call-ID: 1a37a04a3bd8d656-347@MYPUBLICIP
Route: <sip:MYPUBLICIP;r2=on;lr;did=cd7.3482;nat=yes>,
<sip:MYPUBLICIP;transport=tcp;r2=on;lr;did=cd7.3482;nat=yes>
Max-Forwards: 70
Content-Length: 0
User-Agent: kamailio (4.2.0 (x86_64/linux))
Referred-By: sip:controller@kamailio.org
Refer-To: sip:106@MYPUBLICIP
sip:controller@kamailio.org
The last line does not look right to me … why is there a sip uri at
the end of the message buffer with no field name.
later on in the output I see:
Oct 24 10:50:27 KamTesting002 kamailio[402]: DEBUG: tm
[t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=2 , global
msg id=1 , T on entrance=0xffffffffffffffff
Oct 24 10:50:27 KamTesting002 kamailio[402]: ERROR: tm
[t_lookup.c:1403]: t_newtran(): ERROR: t_newtran: EoH not parsed
On 24 Oct 2014, at 10:09, Paul Smith <paul.smith(a)claritytele.com
<mailto:paul.smith@claritytele.com>> wrote:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Thank you for the reply Daniel. I have enabled
debug=3 and put in a
few more xlog lines. I can see the REFER coming in on local
interface 127.0.0.1. I am now trying to narrow down the issue in the
kamailio.cfg.
My conclusions so far are:
1) The REFER packet has a problem which causes it to fail sanity_check()
2) sanity_check returns 0=exit rather than -1 = error.
I have 2 snom phones registered to the kamailio server over NAT and
can make calls between them.
The REFER is failing in the REQINIT route block. The script stops
there.
Kamailio.cfg : I started again with default 4.2 and kamailio.cfg as
shipped enabled MYSQL, USRLOCDB, inserted dialog module, replaced
rtpproxy with rtpengine.
#!define WITH_MYSQL
#!define WITH_AUTH
#!define WITH_USRLOCDB
#!define WITH_NAT
amended REQINIT as follows. I see log lines for “going to sanity
check” but neither “Malformed” or “returning” line are reached.
...
if (is_method("REFER")) {xlog("L_INFO","REFER going to
sanity
check\n");}
if(!sanity_check("1511", "7")) {
xlog("L_INFO","Malformed SIP message from
$si:$sp\n");
exit;
}
if (is_method("REFER")) {xlog("L_INFO","REFER returning
OK
from sanity check");}
...
Then run from the command line:
kamcmd dlg.bridge_dlg
sip:105@MYPUBLICIP sip:106@MYPUBLICIP sip:MYPUBLICIP:5060
Kamailio Output:
2(32566) DEBUG: <core> [parser/msg_parser.c:623]: parse_msg(): SIP
Request:
2(32566) DEBUG: <core> [parser/msg_parser.c:625]: parse_msg():
method: <REFER>
2(32566) DEBUG: <core> [parser/msg_parser.c:627]: parse_msg(): uri:
<sip:105@192.168.1.15:1082;transport=tcp;line=5twzz1pj>
2(32566) DEBUG: <core> [parser/msg_parser.c:629]: parse_msg():
version: <SIP/2.0>
2(32566) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param():
Found param type 232, <branch> =
<z9hG4bKf666.1955cd53000000000000000000000000.0>; state=16
2(32566) DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end
of header reached, state=5
2(32566) DEBUG: <core> [parser/msg_parser.c:513]: parse_headers():
parse_headers: Via found, flags=2
2(32566) DEBUG: <core> [parser/msg_parser.c:515]: parse_headers():
parse_headers: this is the first via
2(32566) DEBUG: <core> [receive.c:154]: receive_msg(): After
parse_msg...
2(32566) DEBUG: <core> [receive.c:197]: receive_msg(): preparing to
run routing scripts...
2(32566) INFO: <script>: --- SCRIPT Got a REFER packet from
MYPUBLICIP to sip:105@192.168.1.15:1082;transport=tcp;line=5twzz1pj --
2(32566) DEBUG: <core> [parser/parse_addr_spec.c:176]:
parse_to_param(): DEBUG: add_param: tag=wg03aczruz
2(32566) DEBUG: <core> [parser/parse_addr_spec.c:898]:
parse_addr_spec(): end of header reached, state=29
2(32566) DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field():
DEBUG: get_hdr_field: <To> [41]; uri=[sip:105@MYPUBLICIP]
2(32566) DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field():
DEBUG: to body [<sip:105@MYPUBLICIP>]
2(32566) DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field():
get_hdr_field: cseq <CSeq>: <11> <REFER>
2(32566) DEBUG: maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value = 70
2(32566) INFO: <script>: REFER going to sanity check
2(32566) DEBUG: <core> [parser/msg_parser.c:204]: get_hdr_field():
DEBUG: get_hdr_body : content_length=0
2(32566) DEBUG: sanity [mod_sanity.c:255]: w_sanity_check(): sanity
checks result: 0
On 23 Oct 2014, at 15:39, Daniel-Constantin Mierla <miconda(a)gmail.com
<mailto:miconda@gmail.com>> wrote:
Hello,
what should be happen, is the following:
- invite from controller to first parameter (caller of desired call)
- after 200ok comes from 'caller', kamailio sends REFER to it
pointing to the second parameter (callee of desired call) and then
BYE, getting out of the initial call
- after getting the REFER, caller should send a new INVITE to callee
You can run with debug=3 to see what happens. In kamailio config is
nothing special needed, just allow traffic from kamailio to go back
to kamailio.
Cheers,
Daniel
_______________________________________________
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
29 Oct
29 Oct
12:11 p.m.
Hello,
should be fixed in 4.2 -- the issue was introduced when changed the
build of refer to contain a contact header, as it was reported some UA
don't like it without the header.
Let me know if all works ok now.
Cheers,
Daniel
On 24/10/14 14:56, Daniel-Constantin Mierla wrote:
I don't recall any change to this part for 4.2 and
I am using
dlg_bridge with 4.1 (no time to upgrade that box yet) -- but
apparently there is a bug building the REFER. There were few changes
on how From/To are built locally, but they are ok.
I am traveling at Astricon, but with first occasion I will check it.
Cheers,
Daniel
On 24/10/14 12:07, Paul Smith wrote:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
I added a log line to the top of kamailio.cfg
request_route block to
grab the message buffer of the REFER. I also put a condition around
the sanity_check to skip it for method=REFER …
I got the following output for $mb at the start of request_route for
the REFER packet (I have substituted MYPUBLICIP for my ip address)
2(341) INFO: <script>: --- SCRIPT Got a REFER packet from MYPUBLICIP
to sip:105@MYPUBLICIP:1095;transport=tcp;line=5twzz1pj with message
buffer REFER sip:105@192.168.1.15:1095;transport=tcp;line=5twzz1pj
SIP/2.0
Via: SIP/2.0/UDP
MYPUBLICIP;branch=z9hG4bKcfed.c87adfb2000000000000000000000000.0
To: <sip:105@MYPUBLICIP>;tag=q42s05ts0b
From:
<sip:controller@kamailio.org>;tag=48329130e552128b3c54a5eeb8c86eea-03b0
CSeq: 11 REFER
Call-ID: 1a37a04a3bd8d656-347@MYPUBLICIP
Route: <sip:MYPUBLICIP;r2=on;lr;did=cd7.3482;nat=yes>,
<sip:MYPUBLICIP;transport=tcp;r2=on;lr;did=cd7.3482;nat=yes>
Max-Forwards: 70
Content-Length: 0
User-Agent: kamailio (4.2.0 (x86_64/linux))
Referred-By: sip:controller@kamailio.org
Refer-To: sip:106@MYPUBLICIP
sip:controller@kamailio.org
The last line does not look right to me … why is there a sip uri at
the end of the message buffer with no field name.
later on in the output I see:
Oct 24 10:50:27 KamTesting002 kamailio[402]: DEBUG: tm
[t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=2 , global
msg id=1 , T on entrance=0xffffffffffffffff
Oct 24 10:50:27 KamTesting002 kamailio[402]: ERROR: tm
[t_lookup.c:1403]: t_newtran(): ERROR: t_newtran: EoH not parsed
On 24 Oct 2014, at 10:09, Paul Smith <paul.smith(a)claritytele.com
<mailto:paul.smith@claritytele.com>> wrote:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Thank you for the reply Daniel. I have enabled
debug=3 and put in a
few more xlog lines. I can see the REFER coming in on local
interface 127.0.0.1. I am now trying to narrow down the issue in
the kamailio.cfg.
My conclusions so far are:
1) The REFER packet has a problem which causes it to fail sanity_check()
2) sanity_check returns 0=exit rather than -1 = error.
I have 2 snom phones registered to the kamailio server over NAT and
can make calls between them.
The REFER is failing in the REQINIT route block. The script stops
there.
Kamailio.cfg : I started again with default 4.2 and kamailio.cfg as
shipped enabled MYSQL, USRLOCDB, inserted dialog module, replaced
rtpproxy with rtpengine.
#!define WITH_MYSQL
#!define WITH_AUTH
#!define WITH_USRLOCDB
#!define WITH_NAT
amended REQINIT as follows. I see log lines for “going to sanity
check” but neither “Malformed” or “returning” line are reached.
...
if (is_method("REFER")) {xlog("L_INFO","REFER going to
sanity check\n");}
if(!sanity_check("1511", "7")) {
xlog("L_INFO","Malformed SIP message from
$si:$sp\n");
exit;
}
if (is_method("REFER")) {xlog("L_INFO","REFER returning
OK
from sanity check");}
...
Then run from the command line:
kamcmd dlg.bridge_dlg
sip:105@MYPUBLICIP sip:106@MYPUBLICIP sip:MYPUBLICIP:5060
Kamailio Output:
2(32566) DEBUG: <core> [parser/msg_parser.c:623]: parse_msg(): SIP
Request:
2(32566) DEBUG: <core> [parser/msg_parser.c:625]: parse_msg():
method: <REFER>
2(32566) DEBUG: <core> [parser/msg_parser.c:627]: parse_msg():
uri: <sip:105@192.168.1.15:1082;transport=tcp;line=5twzz1pj>
2(32566) DEBUG: <core> [parser/msg_parser.c:629]: parse_msg():
version: <SIP/2.0>
2(32566) DEBUG: <core> [parser/parse_via.c:1284]:
parse_via_param(): Found param type 232, <branch> =
<z9hG4bKf666.1955cd53000000000000000000000000.0>; state=16
2(32566) DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end
of header reached, state=5
2(32566) DEBUG: <core> [parser/msg_parser.c:513]: parse_headers():
parse_headers: Via found, flags=2
2(32566) DEBUG: <core> [parser/msg_parser.c:515]: parse_headers():
parse_headers: this is the first via
2(32566) DEBUG: <core> [receive.c:154]: receive_msg(): After
parse_msg...
2(32566) DEBUG: <core> [receive.c:197]: receive_msg(): preparing to
run routing scripts...
2(32566) INFO: <script>: --- SCRIPT Got a REFER packet from
MYPUBLICIP to sip:105@192.168.1.15:1082;transport=tcp;line=5twzz1pj --
2(32566) DEBUG: <core> [parser/parse_addr_spec.c:176]:
parse_to_param(): DEBUG: add_param: tag=wg03aczruz
2(32566) DEBUG: <core> [parser/parse_addr_spec.c:898]:
parse_addr_spec(): end of header reached, state=29
2(32566) DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field():
DEBUG: get_hdr_field: <To> [41]; uri=[sip:105@MYPUBLICIP]
2(32566) DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field():
DEBUG: to body [<sip:105@MYPUBLICIP>]
2(32566) DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field():
get_hdr_field: cseq <CSeq>: <11> <REFER>
2(32566) DEBUG: maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value
= 70
2(32566) INFO: <script>: REFER going to sanity check
2(32566) DEBUG: <core> [parser/msg_parser.c:204]: get_hdr_field():
DEBUG: get_hdr_body : content_length=0
2(32566) DEBUG: sanity [mod_sanity.c:255]: w_sanity_check(): sanity
checks result: 0
On 23 Oct 2014, at 15:39, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
what should be happen, is the following:
- invite from controller to first parameter (caller of desired call)
- after 200ok comes from 'caller', kamailio sends REFER to it
pointing to the second parameter (callee of desired call) and then
BYE, getting out of the initial call
- after getting the REFER, caller should send a new INVITE to callee
You can run with debug=3 to see what happens. In kamailio config is
nothing special needed, just allow traffic from kamailio to go back
to kamailio.
Cheers,
Daniel
_______________________________________________
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
6:43 p.m.
Hi Daniel,
I’ve just done a few quick tests after “git pull origin” upgrade.
It works when the 2 snom endpoints are registered over UDP transport with stun enabled.
Which is great thank you very much.
But I have come across a couple of cases that are not working for me yet:
FAIL CASE 1 : It does not send the REFER to the from device when the from device is
registered with transport UDP and with stun disabled.
FAIL CASE 2 : It does not send the REFER to the from device when the from device is
registered with transport tcp with stun enabled. It turns out that the snom is not doing
stun when the transport =tcp so this is actually the same case as the one above …. i.e.
nat handling and routing.
… not sure yet whether the nat routing failures are is due to my script or the module… I
would have thought theREFER should still go to 105@NATROUTERIP rather than
105@LANlocalIP?
WORKING CASE : udp transport, stun enabled
--------------------------------------------------------------The message buffer dump at
the top of request_route() gives me
2(3415) INFO: <script>: --- SCRIPT Got a REFER packet from KAMAILIOSERVERIP to
sip:105@NATROUTERIP:38788;line=1ba8dgba with message buffer:
REFER sip:105@NATROUTERIP:38788;line=1ba8dgba SIP/2.0
Via: SIP/2.0/UDP KAMAILIOSERVERIP;branch=z9hG4bK92d2.dc966e61000000000000000000000000.0
To: <sip:105@KAMAILIOSERVERIP>;tag=uj221nkycd
From: <sip:controller@kamailio.org>;tag=48329130e552128b3c54a5eeb8c86eea-ca5a
CSeq: 11 REFER
Call-ID: 5abe7c773aaefc3d-3421@KAMAILIOSERVERIP
Route: <sip:KAMAILIOSERVERIP;lr;did=906.c812;nat=yes>
Max-Forwards: 70
Content-Length: 0
User-Agent: kamailio (4.2.0 (x86_64/linux))
Referred-By: sip:controller@kamailio.org
Refer-To: sip:106@KAMAILIOSERVERIP
Contact: <sip:controller@kamailio.org:5060>
kamctl ul show 105@KAMAILIOSERVERIP
Contact::
<sip:105@NATROUTERIP:38788;line=1ba8dgba>;q=1;expires=3592;flags=0x0;cflags=0x40;state=2;socket=<udp:KAMAILIOSERVERIP:5060>;methods=0x17DF;received=<sip:NATROUTERIP:38788>;user_agent=<snom370/8.7.3.19>;+sip.instance=<urn:uuid:b56f3e3c-78ac-4aa2-8073-000413260935>;reg-id=1
FAIL CASE 1 : udp transport + stun disabled
------------------------------------------------------------ The message buffer dump at
the top of request_route() gives me
1(3414) INFO: <script>: --- SCRIPT Got a REFER packet from KAMAILIOSERVERIP to
sip:105@192.168.1.15:5060;line=dq8tdtq2 with message buffer:
REFER sip:105@192.168.1.15:5060;line=dq8tdtq2 SIP/2.0
Via: SIP/2.0/UDP KAMAILIOSERVERIP;branch=z9hG4bK03d2.fbd72b40000000000000000000000000.0
To: <sip:105@KAMAILIOSERVERIP>;tag=z0qd99c588
From: <sip:controller@kamailio.org>;tag=48329130e552128b3c54a5eeb8c86eea-8a12
CSeq: 11 REFER
Call-ID: 5abe7c773aaefc3c-3421@KAMAILIOSERVERIP
Route: <sip:KAMAILIOSERVERIP;lr;did=016.a3f1;nat=yes>
Max-Forwards: 70
Content-Length: 0
User-Agent: kamailio (4.2.0 (x86_64/linux))
Referred-By: sip:controller@kamailio.org
Refer-To: sip:106@KAMAILIOSERVERIP
Contact: <sip:controller@kamailio.org:5060>
kamctl ul show 105@KAMAILIOSERVERIP
Contact::
<sip:105@192.168.1.15:5060;line=dq8tdtq2>;q=1;expires=3595;flags=0x0;cflags=0x40;state=2;socket=<udp:KAMAILIOSERVERIP:5060>;methods=0x17DF;received=<sip:NATROUTERIP:38788>;user_agent=<snom370/8.7.3.19>;+sip.instance=<urn:uuid:b56f3e3c-78ac-4aa2-8073-000413260935>;reg-id=1
FAIL CASE 2 : tcp transport + stun enabled.
---------------------------------------------------------The message buffer dump at the
top of request_route() gives me
It looks like the snom ignores stun settings when transport=tcp …. therefore this failure
case is actually the same as the one above…. i.e it is a routing / NAT problem when stun
is disabled
INFO: <script>: --- SCRIPT Got a REFER packet from KAMAILIOSERVERIP to
sip:105@192.168.1.15:1113;transport=tcp;line=vr59tdgv with message buffer:
REFER sip:105@192.168.1.15:1113;transport=tcp;line=vr59tdgv SIP/2.0
Via: SIP/2.0/UDP KAMAILIOSERVERIP;branch=z9hG4bKf2d2.9651ae40000000000000000000000000.0
To: <sip:105@KAMAILIOSERVERIP>;tag=h233uut5bz
From: <sip:controller@kamailio.org>;tag=48329130e552128b3c54a5eeb8c86eea-4c61
CSeq: 11 REFER
Call-ID: 5abe7c773aaefc3b-3421@KAMAILIOSERVERIP
Route: <sip:KAMAILIOSERVERIP;r2=on;lr;did=f06.06e;nat=yes>,
<sip:KAMAILIOSERVERIP;transport=tcp;r2=on;lr;did=f06.06e;nat=yes>
Max-Forwards: 70
Content-Length: 0
User-Agent: kamailio (4.2.0 (x86_64/linux))
Referred-By: sip:controller@kamailio.org
Refer-To: sip:106@KAMAILIOSERVERIP
Contact: <sip:controller@kamailio.org:5060>
kamctl ul show 105@KAMAILIOSERVERIP
Contact::
<sip:105@192.168.1.15:1113;transport=tcp;line=vr59tdgv>;q=1;expires=3587;flags=0x0;cflags=0x40;state=2;socket=<tcp:KAMAILIOSERVERIP:5060>;methods=0x17DF;received=<sip:NATROUTERIP:34841;transport=TCP>;user_agent=<snom370/8.7.3.19>;+sip.instance=<urn:uuid:b56f3e3c-78ac-4aa2-8073-000413260935>;reg-id=1
On 29 Oct 2014, at 11:11, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
Hello,
should be fixed in 4.2 -- the issue was introduced when changed the build of refer to
contain a contact header, as it was reported some UA don't like it without the
header.
Let me know if all works ok now.
Cheers,
Daniel
7:17 p.m.
New subject: RTP Engine offer within onsend_route
Hi,
In my Kamailio configuration I added the below lines:
route{
.
.
rtpengine_manage("replace-session-connection symmetric ICE=remove
media-address=172.16.0.150");
.
.
}
onsend_route {
if(to_ip == My.Carrier.I.P){
xlog("going to carrier");
rtpengine_offer("replace-session-connection symmetric ICE=remove
media-address=My.Server.I.P");
}
}
By adding the rtpengine_offer within onsend route I want to override the previously added
private IP (in route) from the SDP before sending it to my carrier. But, it seems not
working as it is still sending the private IP. how can I solve this ?
Thanks in advanced.
3472
days inactive
3478
days old
7 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Kamrul Khan -
Paul Smith