[SR-Users] Problem initiating a call with dlg_bridge
Daniel-Constantin Mierla
miconda at gmail.com
Wed Oct 29 12:11:23 CET 2014
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:105 at MYPUBLICIP:1095;transport=tcp;line=5twzz1pj with message
>> buffer REFER sip:105 at 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 at MYPUBLICIP>;tag=q42s05ts0b
>> From:
>> <sip:controller at kamailio.org>;tag=48329130e552128b3c54a5eeb8c86eea-03b0
>> CSeq: 11 REFER
>> Call-ID: 1a37a04a3bd8d656-347 at 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 at kamailio.org
>> Refer-To: sip:106 at MYPUBLICIP
>> sip:controller at 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 at claritytele.com
>> <mailto:paul.smith at 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 at MYPUBLICIP sip:106 at 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 at 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 at 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 at MYPUBLICIP]
>>> 2(32566) DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field():
>>> DEBUG: to body [<sip:105 at 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 at gmail.com <mailto:miconda at 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 at lists.sip-router.org <mailto:sr-users at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20141029/aa2faa76/attachment.html>
More information about the sr-users
mailing list