Re: [sr-dev] Websocket testing

Hi, I had the same problem and I solve it changing this line on my kamailio.cfg: # DIRTY WORKARROUND :P #if ($hdr(Host) == $null || !is_myself($hdr(Host))) { if ($hdr(Host) == $null) { xlog("L_WARN", "Bad host $hdr(Host)\n"); xhttp_reply("403", "Forbidden", "", ""); exit; } Could anybode confirm me if this solution is correct (and secure) please? Thanks in advance :). 2012/8/8 Carlos Ruiz Díaz &lt;carlos.ruizdiaz(a)gmail.com&gt; Thank you for your time Peter. I'll setup a VM with Windows to continue with my tests and I'll come back later with more feedback. Regards. Carlos. On Wed, Aug 8, 2012 at 12:22 PM, Peter Dunkley &lt;peter.dunkley(a)crocodile-rcs.com&gt; wrote: Hi, I have added some comments in-line below. Regards, Peter call.htm file (of sipml5) to kamailio script refused to condition was not satisfied: received on $Rp\n");* "");* respectively, as the *127.0.0.1:80*, always in the satisfied but sipml5 dies realm='<sip:127.0.0.1>', tsk_utils.js:97<http://127.0.0.1/sipml5/src/tinySAK/src/tsk_utils.js?svn=5> tsk_utils.js:97<http://127.0.0.1/sipml5/src/tinySAK/src/tsk_utils.js?svn=5> > Stack starting tsk_utils.js:97<http://127.0.0.1/sipml5/src/tinySAK/src/tsk_utils.js?svn=5> <http://127.0.0.1/> > __tsip_transport_ws_onerror tsk_utils.js:97<http://127.0.0.1/sipml5/src/tinySAK/src/tsk_utils.js?svn=5> > __tsip_transport_ws_onclose tsk_utils.js:97<http://127.0.0.1/sipml5/src/tinySAK/src/tsk_utils.js?svn=5> > Failed to connet to the server > Finally, I ended up commenting the condition block and restored the > Having done that, I tried again and another error was thrown but this $null || > <script>: WebSocket DEBUG: <script>: DEBUG: <script>: DEBUG: <core> host==us: 14==9 && [ DEBUG: <core> host==us: 14==9 && [ DEBUG: <core> host==us: 14==13 && [ DEBUG: <core> host==us: 14==13 && [ DEBUG: <core> host==us: 14==9 && [ DEBUG: <core> host==us: 14==9 && [ DEBUG: <core> host==us: 14==13 && [ DEBUG: <core> host==us: 14==13 && [ DEBUG: <core> WARNING: <script>: Bad > host 127.0.0.1:5060 > I commented the block too and only then sipml5 was able to register > itself. > What am I doing wrong here? When I tested this I was hosting sipml5 on a web-server on a separate machine from Kamailio, and my web-browser was on a separate machine from both Kamailio and the web-server. The example configuration works for that scenario (which is likely to be the way it would be deployed in a real system). I suspect that the Kamailio listen directives (or something else related) aren't set-up quite right for your environment. Host: is a required header when establishing a WebSocket connection. The Host: header added by the client should indicate the name of the server the client is trying to connect to as indicated in the WebSocket URI (so if you put an IP address in the URI that will be in the Host: header, if you put a hostname in the URI then it will be in the Host: header). The WebSocket server (in this case Kamailio) should check that this header matches what it believes it's externally visible name is before accepting the connection. This check needs to be performed in kamailio.cfg instead of the WebSocket module in order for the check to be flexible. The check in the example kamailio.cfg is: - Making sure the Host: header is present - Making sure the name in the Host: header is an IP address (as defined in the listen directives) or alias (for example a domain name) that the Kamailio instance believes it is authoritative for. As the WebSocket stack in a web-browser will add the Host: header automatically, any problem with this suggests that the WebSocket URI set in sipml5 and the listen/alias directives in kamailio.cfg don't match - which would be consistent with the first part your connection establishment problem too. I would suggest that you should re-instate these lines as, by commenting them out (rather than fixing the underlying problems in the test set-up), you may be moving the issues down-stream. attempt to initiate a call signaling, probably message. Perhaps these I haven't read the > RFC > (yet) I am mentioning it anyway. > sip:2000@df7jal23ls0d.invalid;transport=ws > SIP/2.0#015#012Record-Route: <sip:127.0.0.1;transport=ws;r2=on;lr=on>#015#012Record-Route: > <sip:127.0.0.1;r2=on;lr=on>#015#012Via: SIP/2.0/WS 127.0.0.1;branch=z9hG4bK90a8.b1a7035e13ed19880dd12a1f4c86adbb.0#015#012Via: > SIP/2.0/UDP 127.0.0.1:5062;rport=5062;branch=z9hG4bKimixlbyp#015#012Max-Forwards: "1000" 654 <sip:1000@127.0.0.1:5062>#015#012Content-Type: > application/sdp#015#012Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE#015#012Supported: 1383232165 IN IP4 127.0.0.1#015#012t=0 0#015#012m=audio speex/8000#015#012a=rtpmap:8 PCMU/8000#015#012a=rtpmap:3 telephone-event/8000#015#012a=fmtp:101 > 0-15#015#012a=ptime:20#015#012 That INVITE is for a call towards sipml5 on a WebSocket connection. So this isn't a SIP message over TCP, it is a SIP message over WebSockets over TCP - and those are not the same thing. The stuff at the start of the TCP buffer is the WebSocket framing and it is meant to be there. The WebSocket framing will not be present on the connection to Twinkle. requirements for testing? If > not, > what (Linux) softphone is suitable for this purpose? When using an up-to-date Google Chrome you need to use a client that supports RTP/SAVPF. Boghe (from Doubango) is a Windows client that supports this. I don't know which (if any) Linux clients support this feature. -- Peter Dunkley Technical Director Crocodile RCS Ltd _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Jesús Pérez VoIP Engineer at Quobis Fixed: +34 902 999 465 Site: http://www.quobis.com _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev