8 Aug
2012
8 Aug
'12
11:16 a.m.
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(a)crocodile-rcs.com> wrote:
On 7 Aug 2012, at 23:57, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
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.
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.
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.
--
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: +92 334 422 40 88
MSN: shari_786pk(a)hotmail.com
Email: shaheryarkh(a)googlemail.com
>
> 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 ;)
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?
> 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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
_______________________________________________
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