[sr-dev] Websocket module
Muhammad Shahzad
shaheryarkh at googlemail.com
Wed Aug 8 10:16:04 CEST 2012
Interesting discussion is going on, great.
Just wanted to add some notes from my own experience. I have used both
OverSIP and Kamailio for web sockets testing. In my experience, using
kamailio i was able to register two web socket clients to kamailio and make
calls between them. But if try to do the following nothing works,
1. try to forward registration requests to another registrar.
2. try to make calls between a webrtc and non-webrtc client.
3. try to send call from webrtc client to asterisk / freeswitch server to
play e.g. some IVR, voice mail etc.
and many other scenarios, which all have one thing common, that is one or
more sip servers behind kamailio, webrtc clients do not work at all. They
work only and only if kamailio is the only SIP server on the server side,
mostly because kamailio currently do not have neither PATH nor outbound
support.
On the other hand OverSIP is merely a basic SIP proxy with web sockets
support, but it is has real good support for PATH and outbound, perhaps
because it was designed as an edge SIP proxy that can work and relay client
requests to another SIP server in the setup. This makes it easy to
integrate in an existing SIP infrastructure, where one may have dedicated
servers for e.g. SIP registration, PSTN termination, Announcement and voice
mail services etc. etc.
Right now i am working on media side, i am able establish call between a
webrtc and non-webrtc client but media does not flow either way. I am
working with all possible options, using media servers e.g. asterisk,
freeswitch, media proxy etc. I did got some success with asterisk after
adding support ICE, SAVPF and VP8 pass through but still a lot needs to
done and tested before we have a proper integration of webrtc clients in
existing voip setups.
Thank you.
On Wed, Aug 8, 2012 at 2:31 AM, Peter Dunkley <
peter.dunkley at crocodile-rcs.com> wrote:
>
> On 7 Aug 2012, at 23:57, Iñaki Baz Castillo <ibc at aliax.net> wrote:
>
> >>
> >> All new WebSocket connections are handled by an
> >> event_route[xhttp:request]. This allows any inspection of the headers
> you
> >> want, and you can perform HTTP digest authentication using this
> >> event_route.
> >
> > Note that, even if RFC 6455 gives the door open to HTTP basic/digest
> > authentication, currently no one browser with WebSocket support reacts
> > on a 401/407 for the WS GET.
> >
> > I strongly know that WWW people does not like authentication
> > mechanisms other than those based on HTML forms ;)
> >
> Fortunately, even this should be do-able with Kamailio. Another reason I
> used event_route[xhttp:request] is that it enables me to differentiate the
> HTTP requests (so I can do things like handle WebSockets and run XCAP on
> the same port). This leaves open the possibility to serve pages/forms
> (possibly using app_lua do do the heavy lifting) from Kamailio - so HTML
> form authentication (as unpleasant an idea as it is) should be possible.
>
> >
> >> Once you are happy that the connection should be allowed you
> >> call the ws_handle_handshake() function to do some further checks,
> >> generate the handshake response, and upgrade the connection in Kamailio
> >> core. So, for example:
> >>
> >> event_route[xhttp:request] {
> >> set_reply_close();
> >> set_reply_no_connect();
> >>
> >> if ($Rp != 80 && $Rp != 443) {
> >> xlog("L_WARN", "HTTP request received on $Rp\n");
> >> xhttp_reply("403", "Forbidden", "", "");
> >> exit;
> >> }
> >>
> >> xlog("L_DBG", "HTTP Request Received\n");
> >>
> >> if ($hdr(Upgrade)=~"websocket"
> >> && $hdr(Connection)=~"Upgrade"
> >> && $rm=~"GET") {
> >
> > But the Sec-WebSocket-Accept header is generated (and added to the 101
> > response) by the WS module itself, am I right?
> >
> The ws_handle_handshake() performs the header and 101 response generation
> (as well as handling a number of other protocol issues with the handshake).
> The checks in event_route[xhttp:request] are only there to determine if
> the request should be passed to the WebSocket module for handling (and do
> things with Origin and cookies) or whether it is an ordinary HTTP request
> that should be handled outside of that module.
>
> >
> >> xlog("L_DBG", "WebSocket\n");
> >> xlog("L_DBG", " Host: $hdr(Host)\n");
> >> xlog("L_DBG", " Origin: $hdr(Origin)\n");
> >>
> >> if ($hdr(Host) == $null || !is_myself($hdr(Host))) {
> >> xlog("L_WARN", "Bad host $hdr(Host)\n");
> >> xhttp_reply("403", "Forbidden", "", "");
> >> exit;
> >> }
> >>
> >> # Optional... validate Origin
> >> # Optional... perform HTTP authentication
> >>
> >> # ws_handle_handshake() exits (no further configuration
> file
> >> # processing of the request) when complete.
> >> ws_handle_handshake();
> >> }
> >>
> >> xhttp_reply("404", "Not found", "", "");
> >> }
> >
> >
> > It seems a good decision :)
> >
> >
> > Thanks a lot for your explanations, and congratulations for your work.
> >
> >
> Thanks for the feedback. The one thing that I would like to do now is get
> Outbound into Kamilio so that I don't need the aliasing. I am trying to
> get my head around what is missing, but what needs to be done to support
> this is a little unclear to me at the moment.
>
> Also, I don't think sipml5 (which I've been using for testing) supports
> outbound at the moment.
>
> However, I would much prefer to be using Outbound for both WebSockets and
> TCP from behind NAT where I can.
>
>
> > --
> > Iñaki Baz Castillo
> > <ibc at aliax.net>
> >
> > _______________________________________________
> > 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
>
--
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: +92 334 422 40 88
MSN: shari_786pk at hotmail.com
Email: shaheryarkh at googlemail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20120808/306df399/attachment.htm>
More information about the sr-dev
mailing list