<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/4.4.2">
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#ffffff">
Hi Daniel,<BR>
<BR>
Thanks for the answers.<BR>
<BR>
WebSockets will just use the TCP/TLS sockets and upgrade them when necessary. It seems the simplest way as the initial WebSocket request is an HTTP GET.<BR>
<BR>
Also, while I agree with Inaki that SIP outbound makes things simpler, I am not planning on relying on that for WebSockets at the moment. Not only does Kamailio not support it yet, but I don't want to assume all clients will either. The URIs in Via headers and the Contact header in SIP over WebSockets is just a random invalid one (because the client can't be expected to put anything sensible in there). However, I was thinking that the existing support for received in Kamailio should mean that responses just "do the right thing" (as all I need is the socket source IP and port combination for the WebSocket module to find the right connection). Also I think I can use nathelper:fix_nated_register(), nathelper:add_contact_alias(), and nathelper:handle_ruri_alias() in the configuration file to make requests get routed the the right place.<BR>
<BR>
Thanks,<BR>
<BR>
Peter<BR>
<BR>
On Fri, 2012-06-22 at 12:14 +0200, Daniel-Constantin Mierla wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
Hello,<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
On 6/22/12 11:13 AM, Peter Dunkley wrote:<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE TYPE=CITE>
Hi,<BR>
<BR>
I am just trying to work out exactly what needs to be updated in the Kamailio core/parser for WebSockets.<BR>
<BR>
I already know that the Via: parser needs to be updated to understand the WS and WSS transports, and the URI parser needs to be updated to understand the the WS transport, but is there anything else?<BR>
<BR>
I'd appreciate it if anyone has any ideas about what else might need changed (and where in the code), as my guessing at this could be a bit hit-and-miss...<BR>
</BLOCKQUOTE>
<BR>
indeed it might be hard to hit all at once, but it can be fixed as it goes on...<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<BR>
I don't plan to add a forward_ws() function to core because I don't think it'll work (or at least not in all cases as servers cannot initiate WebSocket connections). But are there updates needed in the following areas (and any ideas where in the code I should look)?
<UL>
<LI>forward_no_connect()
<LI>the proto core variable
<LI>the snd_proto core variable
</UL>
</BLOCKQUOTE>
<BR>
these are part of configuration file language, as special tokens -- the grammar of the config file is handled in cfg.lex and cfg.y. Then the interpretation is in action.c, with fixup and helpers in route_struct.{c,h} and route.{c,h}, and it may go through other files. I can help with flex/yacc part if needed.<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<UL>
<LI>Is a WS keyword (like SCTP/TCP/TLS/UDP) needed
</UL>
</BLOCKQUOTE>
Yes, IMO, useful for detecting the incoming protocol
<BLOCKQUOTE TYPE=CITE>
<UL>
<LI>Are the pseudo variables (for example, I know that the mutable variable $du needs to do the right thing as this is fundamental to being able to route requests), transformations, and selects that need to be updated
</UL>
</BLOCKQUOTE>
<BR>
The $du is practically just returning/setting a string, the interpretation is done by internal relay/forward functions. There are some pv/selects that return the protocol, they need updates, but should be trivial once the core part of defining the protocol types (e.g., like PROTO_WS/PROTO_WSS) and updating the uri parser and socket structures.<BR>
<BR>
Btw, there will be dedicated sockets to listen for ws/wss or the tcp/tls will be used and the connection type upgraded to ws/wss?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<UL>
<LI>Are there any modules (rr, nathelper?) that need to be updated
</UL>
</BLOCKQUOTE>
<BR>
There should be some helper functions that build URIs based on internal structures, where the protocol is used. Not sure all the modules use them or have own implementation. Perhaps searching on PROTO_TLS or another one will reveal the places where to add PROTO_WS/_WSS<BR>
<BR>
Cheers,<BR>
Daniel<BR>
<BR>
<PRE>
--
Daniel-Constantin Mierla - <A HREF="http://www.asipto.com">http://www.asipto.com</A>
<A HREF="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</A> - <A HREF="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</A>
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - <A HREF="http://asipto.com/u/katu">http://asipto.com/u/katu</A>
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - <A HREF="http://asipto.com/u/kpw">http://asipto.com/u/kpw</A>
</PRE>
</BLOCKQUOTE>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
</PRE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>