[Spce-user] sipwise 3.1 (CE) and websocket support

[Andrew Pogrebennyk]

On 15/02/14 00:00, Andrew Pogrebennyk wrote:
> thanks, sufficient info collected. The issue is triggered by the Route
> inserted by sipml5: Route:
> <sip:172.18.101.48:5060;lr;sipml5-outbound;transport=udp>
> I'll check what kamailio-lb should do in this case. But as a workaround
> you can try disabling route or "outbound proxy" in sipml5 client.
> 
>> > Feb 14 23:26:54 spce lb[3773]: DEBUG: websocket [ws_frame.c:589]: ws_frame_receive(): Rx SIP message:
>> > ACK sip:ngcp-lb at 172.18.101.48:5060;ngcpct=7369703a3132372e302e302e313a35303830 SIP/2.0
>> > Via: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bKPLN9elJsPlfeyLsMqN2J;rport
>> > From: "4252143385"<sip:4252143385 at 172.18.101.48>;tag=RtycJXR6JIUFzAezAbRX
>> > To: <sip:2067077495 at 172.18.101.48>;tag=1F9894DE-52FE982E000437E0-321A4700
>> > Contact: "4252143385"<sip:4252143385 at df7jal23ls0d.invalid;rtcweb-breaker=yes;click2call=no;transport=ws>;+g.oma.sip-im;+sip.ice;language="en,fr"
>> > Call-ID: 1bff80ac-1e47-ab0f-3ea4-6a7b8637030b
>> > CSeq: 43084 ACK
>> > Content-Length: 0
>> > Route: <sip:172.18.101.48:5060;lr;sipml5-outbound;transport=udp>
>> > Max-Forwards: 70
>> > Proxy-Authorization: …
>> > Route: <sip:172.18.101.48;transport=ws;r2=on;lr=on;ftag=RtycJXR6JIUFzAezAbRX;nat=yes;ngcplb=yes;socket=ws:172.18.101.48:5060>
>> > Route: <sip:127.0.0.1;r2=on;lr=on;ftag=RtycJXR6JIUFzAezAbRX;nat=yes;ngcplb=yes;socket=ws:172.18.101.48:5060>
>> > Route: <sip:127.0.0.1:5062;lr=on;ftag=RtycJXR6JIUFzAezAbRX;did=117.fcb;mpd=ii;ice_caller=replace;savp_caller=force_srtp;avpf_caller=force_avpf;ice_callee=strip;savp_callee=force_rtp;avpf_callee=force_avp;rtpprx=yes;vsf=ampNeU9nS3R6XXJyQ2QgJVJTaiZjfFJ4S35Wf0E->
>> > User-Agent: IM-client/OMA1.0 sipML5-v1.2014.01.27

^^
I think this is a violation of RFC3261 actually. It says in 12.2 that:
   Requests within a dialog MAY contain Record-Route and Contact header
   fields.  However, these requests do not cause the dialog's route set
   to be modified, although they may modify the remote target URI.
   Specifically, requests that are not target refresh requests do not
   modify the dialog's remote target URI, and requests that are target
   refresh requests do.  For dialogs that have been established with an
   INVITE, the only target refresh request defined is re-INVITE (see
   Section 14).  Other extensions may define different target refresh
   requests for dialogs established in other ways.

The sipml5 shall not modify the route set by prepending an extra route
in in-dialog ACK to the route set received from server in 200 OK. They
intentionally make the request loop by sending a Route set with
non-unique URIs. Nevertheless I've posted a question on sr-users mailing
list to confirm that kamailio behavior is 100% valid.