[sr-dev] Websocket testing
Jesús Pérez Rubio
jesus.perez at quobis.com
Fri Sep 14 11:55:30 CEST 2012
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 <carlos.ruizdiaz at gmail.com>
> 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 <
> peter.dunkley at crocodile-rcs.com> wrote:
>
>> Hi,
>>
>> I have added some comments in-line below.
>>
>> Regards,
>>
>> Peter
>>
>> > 1. After setting up the proxy ip:port in the call.htm file (of sipml5)
>> to
>> > *
>> > 127.0.0.1:5060* the client started to work but kamailio script refused
>> to
>> > establish my connection because the following condition was not
>> satisfied:
>> >
>> >
>> > *if ($Rp != MY_WS_PORT && $Rp != MY_WSS_PORT) {*
>> > * xlog("L_WARN", "HTTP request received on $Rp\n");*
>> > * xhttp_reply("403", "Forbidden", "", "");*
>> > * exit;*
>> > *}*
>> >
>> > *MY_WS_PORT* and *MY_WSS_PORT *are set to 80 and 443 respectively, as
>> the
>> > default config example of websocket module says so.
>> >
>> > Then, I decided to change the ip:port to *127.0.0.1:80*, always in the
>> > call.htm file and afterwards the condition was satisfied but sipml5 dies
>> > with
>> >
>> > SIP stack start: proxy='127.0.0.1:80', realm='<sip:127.0.0.1>',
>> > impi='2000', impu='<sip:2000 at 127.0.0.1>'
>> > tsk_utils.js:97<
>> http://127.0.0.1/sipml5/src/tinySAK/src/tsk_utils.js?svn=5>
>> > Connecting to 'ws://127.0.0.1:80'
>> > 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>
>> > Unexpected response code: 200 :1 <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
>> > original values of ip:port to *127.0.0.1:5060* .
>> >
>> > Having done that, I tried again and another error was thrown but this
>> > time,
>> > in the next condition block: * if ($hdr(Host) == $null ||
>> > !is_myself($hdr(Host))) *
>> >
>> > <script>: WebSocket
>> > Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <script>:
>> > Host:
>> > 127.0.0.1:5060
>> > Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <script>:
>> > Origin: http://127.0.0.1
>> > Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <core>
>> > [socket_info.c:589]: grep_sock_info - checking if host==us: 14==9 && [
>> > 127.0.0.1:5060] == [127.0.0.1]
>> > Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <core>
>> > [socket_info.c:589]: grep_sock_info - checking if host==us: 14==9 && [
>> > 127.0.0.1:5060] == [127.0.0.2]
>> > Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <core>
>> > [socket_info.c:589]: grep_sock_info - checking if host==us: 14==13 && [
>> > 127.0.0.1:5060] == [192.168.10.95]
>> > Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <core>
>> > [socket_info.c:589]: grep_sock_info - checking if host==us: 14==13 && [
>> > 127.0.0.1:5060] == [192.168.10.55]
>> > Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <core>
>> > [socket_info.c:589]: grep_sock_info - checking if host==us: 14==9 && [
>> > 127.0.0.1:5060] == [127.0.0.1]
>> > Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <core>
>> > [socket_info.c:589]: grep_sock_info - checking if host==us: 14==9 && [
>> > 127.0.0.1:5060] == [127.0.0.2]
>> > Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <core>
>> > [socket_info.c:589]: grep_sock_info - checking if host==us: 14==13 && [
>> > 127.0.0.1:5060] == [192.168.10.95]
>> > Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <core>
>> > [socket_info.c:589]: grep_sock_info - checking if host==us: 14==13 && [
>> > 127.0.0.1:5060] == [192.168.10.55]
>> > Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <core>
>> > [forward.c:462]: *check_self: host != me*
>> > Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: 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.
>>
>> > 2. I registered a legacy softphone (twinkle) to attempt to initiate a
>> call
>> > in both ways, but the was something wrong with the signaling, probably
>> > some
>> > frame decoding garbage in the buffer of the SIP message. Perhaps these
>> > bytes are part of the frame control header but since I haven't read the
>> > RFC
>> > (yet) I am mentioning it anyway.
>> >
>> > tcp_send: buf=*#012�~#003�*INVITE
>> > sip:2000 at 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:
>> > 69#015#012To: <sip:2000 at 127.0.0.1>#015#012From: "1000"
>> > <sip:1000 at 127.0.0.1>;tag=lrtfz#015#012Call-ID:
>> > gxsqobolphfchfq at carlosrdcnx-laptop.site#015#012CSeq: 654
>> > INVITE#015#012Contact: <sip:1000 at 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:
>> > replaces,norefersub,100rel#015#012User-Agent:
>> > Twinkle/1.4.2#015#012Content-Length:
>> > 302#015#012#015#012v=0#015#012o=twinkle 391470222 1383232165 IN IP4
>> > 127.0.0.1#015#012s=-#015#012c=IN IP4 127.0.0.1#015#012t=0
>> 0#015#012m=audio
>> > 8008 RTP/AVP 98 97 8 0 3 101#015#012a=rtpmap:98
>> > speex/16000#015#012a=rtpmap:97 speex/8000#015#012a=rtpmap:8
>> > PCMA/8000#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:3
>> > GSM/8000#015#012a=rtpmap:101 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.
>>
>> > 3. Does Twinkle support the minimum media 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 at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20120914/08c67548/attachment-0001.htm>
More information about the sr-dev
mailing list