The above sanity check is intended to make sure that:

- SIP over TCP/TLS arriving on the ports intended for SIP over WebSocket is correctly rejected - SIP over TCP/TLS arriving on the port intended for MSRP is correctly rejected

In examples/websocket.cfg with default settings:

- SIP over UDP is supported on port 5060 - SIP over TCP is supported on port 5060 - SIP over TLS is supported on port 5061 - SIP over WS is supported on port 80 - SIP over WSS is supported on port 443 - MSRP is supported over TLS on port 9000 - traffic of the wrong type/transport arriving on the wrong ports is correctly rejected

I believe that the check you have described, and the related ones in onreply_route, event_route[xhttp:request], and event_route[msrp:frame-in], are not too tough do exactly what they are meant to. Whether the checks are too tough for your exact use case depends on what that is.

Regards,

Peter

On 24 September 2013 12:30, Mikko Lehto mslehto@iki.fi wrote:

Hi websocketeers, examples/websocket.cfg starts with this check:

---

request_route { if ((($Rp == MY_WS_PORT || $Rp == MY_WSS_PORT) && !(proto == WS || proto == WSS)) || $Rp == MY_MSRP_PORT) { xlog("L_WARN", "SIP request received on $Rp\n"); sl_send_reply("403", "Forbidden"); exit; }

---

My in-dialog SIP over TCP requests got 403 treatment because of this. I believe reason was MY_WS_ADDR in route set, added by record_route().

Above sanity check seems sensible tough, so I fixed advertised route set with call to force_send_socket() as seen on attached patch.

I wonder if my fix is the best approach. Should the remaining other two t_relay() calls also be prepared with force_send_socket()?

-- Mikko

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users