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@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:control...@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:control...@kamailio.org >> Refer-To: sip:106@MYPUBLICIP >> sip:control...@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.sm...@claritytele.com >> <mailto:paul.sm...@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 >>> <mico...@gmail.com <mailto:mico...@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@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://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
