Hello,
I have merged the pd/websocket branch into Kamailio master. This means
that you can now connect SIP over WebSocket
(draft-ibc-sipcore-sip-websocket-02) clients to Kamailio using the "ws://"
and "wss://" protocols.
Some customisation of the websocket module is possible through modparams,
but for most users the defaults should be OK. The WebSocket module uses
the xhttp and sl modules for the initial handshake, and (unless you have
both a Kamailio installation and WebSocket SIP client supporting GRUU,
Outbound[1], and Path[2]) nathelper for request routing and the core
force_rport() function for response routing (a new nat_uac_test() has been
added to detect whether a message has arrived on a WebSocket). There is
an example kamailio.cfg in the websocket module directory.
[1] Kamailio does not currently support Outbound
[2] I have not updated the Path module for WebSockets
I believe that, once Kamailio supports Outbound and WebSocket support is
added to the Path module (and you have a SIP over WebSocket client that
supports this), it will be possible to use the websocket module without
the nathelper module and force_rport() and without needing to change the
websocket module or Kamailio core code.
If you want to use secure WebSockets (wss) as well as ordinary WebSockets
just configure TLS and listen on an appropriate port.
I have added WebSocket support to some modules, but there are definitely
going to be others (modules/lcr, modules/sipcapture,
modules_k/nat_traversal, modules_k/path, modules_k/seas, and
modules_k/snmpstats, at least) that need updating too. WebSockets is an
unusual transport, so I have put a few notes together for anyone who needs
to use it in the code (including adding support to additional modules):
- A WebSocket server cannot initiate a WebSocket connection. So a
WebSocket connection (over TCP or TLS) is like a TCP/TLS connection coming
from behind a NAT. This is why nathelper aliasing and force_rport() is
used for the routing, and "set_..._no_connect()" is always used (it's set
within the websocket module).
- WebSocket (PROTO_WS) and secure WebSocket (PROTO_WSS) connections are
just upgraded TCP and TLS connections, so there are no listening sockets
for PROTO_WS and PROTO_WSS. This means that, when deciding on what
transport is being used, you need to look at the proto set in the
tcp_connection, receive_info, and/or dest_info structure for the message -
looking at the socket_info structure (that the message has arrived on or
will be sent on) will not give you the right answer.
- Although WebSocket (PROTO_WS) and secure WebSocket (PROTO_WSS) are
different internal protocols there is only one SIP transport type for both
";transport=ws" (WS and WSS are explicitly used in Via: headers though).
This means that you can't tell whether the transport parameter in an
R-URI, Route/Record-Route, or Contact-URI is for WebSockets or secure
WebSockets. As long as the message makes it into the WebSocket module
everything will be OK as that module sorts it all out, but it has led to
slightly more complex checks being required in some of the code relating
to record-routing to handle this - and it may have an effect on other
modules too.
Please give the new module a go and let me know about any issues you find,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Alex Hermann (axlh)
Attached to Project - sip-router
Summary - Internal timer lags real time by the startup time
Task Type - Bug Report
Category - Core
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Medium
Priority - Normal
Reported Version - 3.2
Due in Version - Undecided
Due Date - Undecided
Details - The internal timer (global variable "ticks", and function "ser_time()") lag the real time by the time it took kamailio to start up. This difference is usually small enough not to be noticed (1~2 sec), but when startup takes longer due to heavy database queries (htable) or probing of unreachable rtpproxies, this becomes significant, up to the point it seriously affects functionality. In a kamailio flavour build, at least authentication nonces are affected.
For debugging i created a PV $TSi which returns the result of ser_time(). Logging this variable and $TS results in:
xlog("L_NOTICE", "TS: $TS TSi: $TSi");
Jul 9 12:54:00 devprx01 proxy3[28491]: NOTICE: TS: 1341831240 TSi: 1341831229
In this case, startup was delayed by unreachable rtpproxies, which resulted in a 10 sec delay.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=243
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Hello,
during the last leap-second i noticed the internally kept time (ticks,
ser_time()) deviates from the real time (time()). The difference is not
contant buf fluctuates around 11 secs. How is it possible that both times
deviate and how to prevent it?
This is (amongst other things) breaking authentication using nonces generated
on different hosts.
For debugging, I added a PV to print the internal ser_time(): $TSi, and got
this result:
xlog("L_NOTICE", "TS: $TS TSi: $TSi");
Jul 9 12:54:00 devprx01 proxy3[28491]: NOTICE: TS: 1341831240 TSi:
1341831229
This behaviour survives kamailio restarts and survived host restarts until
july 2nd. After that, a host restart got both times in sync. I still have an
affected host i have not restarted since the leap second which still exhibits
this behaviour.
--
Greetings,
Alex Hermann
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task is now closed:
FS#242 - ndb_redis redisc_free_reply bug
User who did this - Vicente Hernando (vicente)
Reason for closing: Fixed
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=242
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#242 - ndb_redis redisc_free_reply bug
User who did this - Vicente Hernando (vicente)
----------
sqlops module has a similar structure, so looking at it I have chosen second option to fix the bug.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=242#comment704
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.