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

[Ashutosh Apte]

Hi Andrew,
    Thanks for your help with this. I did find the same old thread that you
just revived while searching for a solution to this. Once I removed the
outbound proxy from sipML5, the calls (signaling wise, at least) are now
working. So that's great.

The focus has now shifted to media path and I have now run into two new
issues: (Maybe I should open a new thread?)

1: I notice that sipML5 offers payload type 126 for DTMF. However, the
legacy gateway that I'm using ignores that and responds with 101. This is
obviously an issue on the legacy gateway and I'm trying to see if I can
resolve it on that end. In the absence of that, the sipML5 client falls
back to SIP INFO method. The kamailio proxy responds back with 405 "Method
Not Allowed". A cursory look at
/etc/ngcp-config/templates/etc/kamailio/proxy/proxy.cfg.tt2 seems to
indicate that INFO is not supported and hence it returns an error response.
Is there a way to change the proxy to have the SIP INFO message sent over
to the legacy gateway?

(P.S. I tweaked proxy.cfg.tt2 to route INFO to ROUTE_PBX_REQUEST but that
caused the proxy to respond with either 486 Busy here or 408 Timeout so
I've reverted those changes.)

2: My bigger issue at the moment is that even though the call is
successfully established between the sipML5 client and the legacy gateway
(that plays an IVR script), I cannot hear any audio on the sipML5 side.
I've captured network packets on both ends and:

a: Legacy gateway end: I can successfully listen to what is being spoken on
the sipML5 end (microphone is working, in other words) and I can also
confirm that valid packets are being streamed out.

b: sipML5 client end: Since the RTP streams are encrypted, I can not play
them back through the network capture tool. I do know that the speakers are
working properly as I can hear the ringback tone (that is locally
generated) and DTMF tones when pressing keys on the keypad (again, locally
generated)

so it seems that the media path is working one way:
sipML5 --> mediaproxy --> legacy gateway [OK]
legacy gateway --> mediaproxy --> sipML5 [Not OK]

At this point, I'm not sure where to even start troubleshooting for these
issues. All the help is highly appreciated.

Thanks,
Ashu



On Fri, Feb 14, 2014 at 3:43 PM, Andrew Pogrebennyk <
apogrebennyk at sipwise.com> wrote:

> 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
> @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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20140214/f621fbb1/attachment-0001.html>