Interesting discussion is going on, great.<div><br></div><div>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,</div>
<div><br></div><div>1. try to forward registration requests to another registrar.</div><div>2. try to make calls between a webrtc and non-webrtc client.</div><div>3. try to send call from webrtc client to asterisk / freeswitch server to play e.g. some IVR, voice mail etc.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Thank you.</div><div><br></div><div><br><div class="gmail_quote">On Wed, Aug 8, 2012 at 2:31 AM, Peter Dunkley <span dir="ltr"><<a href="mailto:peter.dunkley@crocodile-rcs.com" target="_blank">peter.dunkley@crocodile-rcs.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 7 Aug 2012, at 23:57, Iñaki Baz Castillo <<a href="mailto:ibc@aliax.net">ibc@aliax.net</a>> wrote:<br>
<br>
>><br>
>> All new WebSocket connections are handled by an<br>
>> event_route[xhttp:request]. This allows any inspection of the headers you<br>
>> want, and you can perform HTTP digest authentication using this<br>
>> event_route.<br>
><br>
> Note that, even if RFC 6455 gives the door open to HTTP basic/digest<br>
> authentication, currently no one browser with WebSocket support reacts<br>
> on a 401/407 for the WS GET.<br>
><br>
> I strongly know that WWW people does not like authentication<br>
> mechanisms other than those based on HTML forms ;)<br>
><br>
</div>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.<br>
<div class="im"><br>
><br>
>> Once you are happy that the connection should be allowed you<br>
>> call the ws_handle_handshake() function to do some further checks,<br>
>> generate the handshake response, and upgrade the connection in Kamailio<br>
>> core. So, for example:<br>
>><br>
>> event_route[xhttp:request] {<br>
>> set_reply_close();<br>
>> set_reply_no_connect();<br>
>><br>
>> if ($Rp != 80 && $Rp != 443) {<br>
>> xlog("L_WARN", "HTTP request received on $Rp\n");<br>
>> xhttp_reply("403", "Forbidden", "", "");<br>
>> exit;<br>
>> }<br>
>><br>
>> xlog("L_DBG", "HTTP Request Received\n");<br>
>><br>
>> if ($hdr(Upgrade)=~"websocket"<br>
>> && $hdr(Connection)=~"Upgrade"<br>
>> && $rm=~"GET") {<br>
><br>
> But the Sec-WebSocket-Accept header is generated (and added to the 101<br>
> response) by the WS module itself, am I right?<br>
><br>
</div>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.<br>
<div class="im"><br>
><br>
>> xlog("L_DBG", "WebSocket\n");<br>
>> xlog("L_DBG", " Host: $hdr(Host)\n");<br>
>> xlog("L_DBG", " Origin: $hdr(Origin)\n");<br>
>><br>
>> if ($hdr(Host) == $null || !is_myself($hdr(Host))) {<br>
>> xlog("L_WARN", "Bad host $hdr(Host)\n");<br>
>> xhttp_reply("403", "Forbidden", "", "");<br>
>> exit;<br>
>> }<br>
>><br>
>> # Optional... validate Origin<br>
>> # Optional... perform HTTP authentication<br>
>><br>
>> # ws_handle_handshake() exits (no further configuration file<br>
>> # processing of the request) when complete.<br>
>> ws_handle_handshake();<br>
>> }<br>
>><br>
>> xhttp_reply("404", "Not found", "", "");<br>
>> }<br>
><br>
><br>
</div><div class="im">> It seems a good decision :)<br>
><br>
><br>
> Thanks a lot for your explanations, and congratulations for your work.<br>
><br>
><br>
</div>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.<br>
<br>
Also, I don't think sipml5 (which I've been using for testing) supports outbound at the moment.<br>
<br>
However, I would much prefer to be using Outbound for both WebSockets and TCP from behind NAT where I can.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> --<br>
> Iñaki Baz Castillo<br>
> <<a href="mailto:ibc@aliax.net">ibc@aliax.net</a>><br>
><br>
> _______________________________________________<br>
> sr-dev mailing list<br>
> <a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>
> <a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
<br>
_______________________________________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Muhammad Shahzad<br>-----------------------------------<br>CISCO Rich Media Communication Specialist (CRMCS)<br>CISCO Certified Network Associate (CCNA)<br>
Cell: +92 334 422 40 88<br>MSN: <a href="mailto:shari_786pk@hotmail.com">shari_786pk@hotmail.com</a><br>Email: <a href="mailto:shaheryarkh@googlemail.com">shaheryarkh@googlemail.com</a><br>
</div>