22 Jun
2012
22 Jun
'12
12:13 p.m.
Hi,
I am just trying to work out exactly what needs to be updated in the
Kamailio core/parser for WebSockets.
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?
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...
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)?
* forward_no_connect()
* the proto core variable
* the snd_proto core variable
* Is a WS keyword (like SCTP/TCP/TLS/UDP) needed
* 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
* Are there any modules (rr, nathelper?) that need to be updated
Thanks for your help,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
22 Jun
22 Jun
1:14 p.m.
Hello,
On 6/22/12 11:13 AM, Peter Dunkley wrote:
Hi,
I am just trying to work out exactly what needs to be updated in the
Kamailio core/parser for WebSockets.
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?
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...
indeed it might be hard to hit all at once, but it can be fixed as it
goes on...
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)?
* forward_no_connect()
* the proto core variable
* the snd_proto core variable
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.
* Is a WS keyword (like SCTP/TCP/TLS/UDP) needed
Yes, IMO, useful for detecting the incoming protocol
* 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
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.
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?
* Are there any modules (rr, nathelper?) that need
to be updated
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
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
1:23 p.m.
Hi Daniel,
Thanks for the answers.
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.
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.
Thanks,
Peter
On Fri, 2012-06-22 at 12:14 +0200, Daniel-Constantin Mierla wrote:
Hello,
On 6/22/12 11:13 AM, Peter Dunkley wrote:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
Hi,
I am just trying to work out exactly what needs to be updated in the
Kamailio core/parser for WebSockets.
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?
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...
indeed it might be hard to hit all at once, but it can be fixed as it
goes on...
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)?
* forward_no_connect()
* the proto core variable
* the snd_proto core variable
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.
* Is a WS keyword (like SCTP/TCP/TLS/UDP)
needed
Yes, IMO, useful for detecting the incoming protocol
* 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
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.
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?
* Are there any modules (rr, nathelper?)
that need to be
updated
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
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
2:52 p.m.
OK thanks.
I will update any modules I need for what I am doing and leave the rest
to the module authors.
Peter
On Fri, 2012-06-22 at 14:15 +0300, Juha Heinanen wrote:
Peter Dunkley writes:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
* Is a WS keyword (like SCTP/TCP/TLS/UDP)
needed
in my opinion, yes.
* Are there any modules (rr, nathelper?)
that need to be updated
any module that deals with transport protocols, e.g., permissions, but
you can leave those to the authors.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
4539
days inactive
4539
days old
4 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Juha Heinanen -
Peter Dunkley