[SR-Users] Problem initiating a call with dlg_bridge

[Paul Smith]

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:***@mykamailioip sip:***@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

[Daniel-Constantin Mierla]

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:***@mykamailioip sip:***@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-***@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

[Paul Smith]

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:***@MYPUBLICIP sip:***@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:***@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:***@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:***@MYPUBLICIP]
2(32566) DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [<sip:***@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 <***@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
>

[Paul Smith]

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:***@MYPUBLICIP:1095;transport=tcp;line=5twzz1pj with message buffer REFER sip:***@192.168.1.15:1095;transport=tcp;line=5twzz1pj SIP/2.0
Via: SIP/2.0/UDP MYPUBLICIP;branch=z9hG4bKcfed.c87adfb2000000000000000000000000.0
To: <sip:***@MYPUBLICIP>;tag=q42s05ts0b
From: <sip:***@kamailio.org>;tag=48329130e552128b3c54a5eeb8c86eea-03b0
CSeq: 11 REFER
Call-ID: 1a37a04a3bd8d656-***@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:***@kamailio.org
Refer-To: sip:***@MYPUBLICIP
sip:***@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 <***@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:***@MYPUBLICIP sip:***@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:***@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:***@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:***@MYPUBLICIP]
> 2(32566) DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [<sip:***@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 <***@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-***@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[Daniel-Constantin Mierla]

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:***@MYPUBLICIP:1095;transport=tcp;line=5twzz1pj with message
> buffer REFER sip:***@192.168.1.15:1095;transport=tcp;line=5twzz1pj SIP/2.0
> Via: SIP/2.0/UDP
> MYPUBLICIP;branch=z9hG4bKcfed.c87adfb2000000000000000000000000.0
> To: <sip:***@MYPUBLICIP>;tag=q42s05ts0b
> From:
> <sip:***@kamailio.org>;tag=48329130e552128b3c54a5eeb8c86eea-03b0
> CSeq: 11 REFER
> Call-ID: 1a37a04a3bd8d656-***@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:***@kamailio.org
> Refer-To: sip:***@MYPUBLICIP
> sip:***@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 <***@claritytele.com
> <mailto:***@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:***@MYPUBLICIP sip:***@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:***@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:***@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:***@MYPUBLICIP]
>> 2(32566) DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field():
>> DEBUG: to body [<sip:***@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 <***@gmail.com
>> <mailto:***@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-***@lists.sip-router.org <mailto:sr-***@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

[Daniel-Constantin Mierla]

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:
>> 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:***@MYPUBLICIP:1095;transport=tcp;line=5twzz1pj with message
>> buffer REFER sip:***@192.168.1.15:1095;transport=tcp;line=5twzz1pj
>> SIP/2.0
>> Via: SIP/2.0/UDP
>> MYPUBLICIP;branch=z9hG4bKcfed.c87adfb2000000000000000000000000.0
>> To: <sip:***@MYPUBLICIP>;tag=q42s05ts0b
>> From:
>> <sip:***@kamailio.org>;tag=48329130e552128b3c54a5eeb8c86eea-03b0
>> CSeq: 11 REFER
>> Call-ID: 1a37a04a3bd8d656-***@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:***@kamailio.org
>> Refer-To: sip:***@MYPUBLICIP
>> sip:***@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 <***@claritytele.com
>> <mailto:***@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:***@MYPUBLICIP sip:***@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:***@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:***@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:***@MYPUBLICIP]
>>> 2(32566) DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field():
>>> DEBUG: to body [<sip:***@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
>>> <***@gmail.com <mailto:***@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-***@lists.sip-router.org <mailto:sr-***@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

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

[Paul Smith]

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 ***@NATROUTERIP rather than ***@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:***@NATROUTERIP:38788;line=1ba8dgba with message buffer:
REFER sip:***@NATROUTERIP:38788;line=1ba8dgba SIP/2.0
Via: SIP/2.0/UDP KAMAILIOSERVERIP;branch=z9hG4bK92d2.dc966e61000000000000000000000000.0
To: <sip:***@KAMAILIOSERVERIP>;tag=uj221nkycd
From: <sip:***@kamailio.org>;tag=48329130e552128b3c54a5eeb8c86eea-ca5a
CSeq: 11 REFER
Call-ID: 5abe7c773aaefc3d-***@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:***@kamailio.org
Refer-To: sip:***@KAMAILIOSERVERIP
Contact: <sip:***@kamailio.org:5060>



kamctl ul show ***@KAMAILIOSERVERIP
Contact:: <sip:***@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:***@192.168.1.15:5060;line=dq8tdtq2 with message buffer:
REFER sip:***@192.168.1.15:5060;line=dq8tdtq2 SIP/2.0
Via: SIP/2.0/UDP KAMAILIOSERVERIP;branch=z9hG4bK03d2.fbd72b40000000000000000000000000.0
To: <sip:***@KAMAILIOSERVERIP>;tag=z0qd99c588
From: <sip:***@kamailio.org>;tag=48329130e552128b3c54a5eeb8c86eea-8a12
CSeq: 11 REFER
Call-ID: 5abe7c773aaefc3c-***@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:***@kamailio.org
Refer-To: sip:***@KAMAILIOSERVERIP
Contact: <sip:***@kamailio.org:5060>



kamctl ul show ***@KAMAILIOSERVERIP
Contact:: <sip:***@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:***@192.168.1.15:1113;transport=tcp;line=vr59tdgv with message buffer:
REFER sip:***@192.168.1.15:1113;transport=tcp;line=vr59tdgv SIP/2.0
Via: SIP/2.0/UDP KAMAILIOSERVERIP;branch=z9hG4bKf2d2.9651ae40000000000000000000000000.0
To: <sip:***@KAMAILIOSERVERIP>;tag=h233uut5bz
From: <sip:***@kamailio.org>;tag=48329130e552128b3c54a5eeb8c86eea-4c61
CSeq: 11 REFER
Call-ID: 5abe7c773aaefc3b-***@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:***@kamailio.org
Refer-To: sip:***@KAMAILIOSERVERIP
Contact: <sip:***@kamailio.org:5060>


kamctl ul show ***@KAMAILIOSERVERIP
Contact:: <sip:***@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 <***@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
>

[Kamrul Khan]

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.