<div dir="ltr">Hi Andrew,<div> 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.</div>
<div><br></div><div>The focus has now shifted to media path and I have now run into two new issues: (Maybe I should open a new thread?)</div><div><br></div><div>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?</div>
<div><br></div><div>(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.)</div><div><br></div><div>
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:</div>
<div><br></div><div>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.</div>
<div><br></div><div>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)</div>
<div><br></div><div>so it seems that the media path is working one way:</div><div>sipML5 --> mediaproxy --> legacy gateway [OK]</div><div>legacy gateway --> mediaproxy --> sipML5 [Not OK]</div><div><br></div><div>
At this point, I'm not sure where to even start troubleshooting for these issues. All the help is highly appreciated.</div><div><br></div><div>Thanks,</div><div>Ashu</div><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Feb 14, 2014 at 3:43 PM, Andrew Pogrebennyk <span dir="ltr"><<a href="mailto:apogrebennyk@sipwise.com" target="_blank">apogrebennyk@sipwise.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On 15/02/14 00:00, Andrew Pogrebennyk wrote:<br>
> thanks, sufficient info collected. The issue is triggered by the Route<br>
> inserted by sipml5: Route:<br>
> <sip:172.18.101.48:5060;lr;sipml5-outbound;transport=udp><br>
> I'll check what kamailio-lb should do in this case. But as a workaround<br>
> you can try disabling route or "outbound proxy" in sipml5 client.<br>
><br>
>> > Feb 14 23:26:54 spce lb[3773]: DEBUG: websocket [ws_frame.c:589]: ws_frame_receive(): Rx SIP message:<br>
>> > ACK sip:ngcp-lb@172.18.101.48:5060;ngcpct=7369703a3132372e302e302e313a35303830 SIP/2.0<br>
>> > Via: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bKPLN9elJsPlfeyLsMqN2J;rport<br>
>> > From: "4252143385"<<a href="mailto:sip%3A4252143385@172.18.101.48">sip:4252143385@172.18.101.48</a>>;tag=RtycJXR6JIUFzAezAbRX<br>
>> > To: <<a href="mailto:sip%3A2067077495@172.18.101.48">sip:2067077495@172.18.101.48</a>>;tag=1F9894DE-52FE982E000437E0-321A4700<br>
>> > Contact: "<a href="tel:4252143385" value="+14252143385">4252143385</a>"<sip:<a href="tel:4252143385" value="+14252143385">4252143385</a>@df7jal23ls0d.invalid;rtcweb-breaker=yes;click2call=no;transport=ws>;+g.oma.sip-im;+sip.ice;language="en,fr"<br>
>> > Call-ID: 1bff80ac-1e47-ab0f-3ea4-6a7b8637030b<br>
>> > CSeq: 43084 ACK<br>
>> > Content-Length: 0<br>
>> > Route: <sip:172.18.101.48:5060;lr;sipml5-outbound;transport=udp><br>
>> > Max-Forwards: 70<br>
</div>>> > Proxy-Authorization: …<br>
<div class="">>> > Route: <sip:172.18.101.48;transport=ws;r2=on;lr=on;ftag=RtycJXR6JIUFzAezAbRX;nat=yes;ngcplb=yes;socket=ws:<a href="http://172.18.101.48:5060" target="_blank">172.18.101.48:5060</a>><br>
>> > Route: <sip:127.0.0.1;r2=on;lr=on;ftag=RtycJXR6JIUFzAezAbRX;nat=yes;ngcplb=yes;socket=ws:<a href="http://172.18.101.48:5060" target="_blank">172.18.101.48:5060</a>><br>
>> > 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-><br>
>> > User-Agent: IM-client/OMA1.0 sipML5-v1.2014.01.27<br>
<br>
</div>^^<br>
I think this is a violation of RFC3261 actually. It says in 12.2 that:<br>
Requests within a dialog MAY contain Record-Route and Contact header<br>
fields. However, these requests do not cause the dialog's route set<br>
to be modified, although they may modify the remote target URI.<br>
Specifically, requests that are not target refresh requests do not<br>
modify the dialog's remote target URI, and requests that are target<br>
refresh requests do. For dialogs that have been established with an<br>
INVITE, the only target refresh request defined is re-INVITE (see<br>
Section 14). Other extensions may define different target refresh<br>
requests for dialogs established in other ways.<br>
<br>
The sipml5 shall not modify the route set by prepending an extra route<br>
in in-dialog ACK to the route set received from server in 200 OK. They<br>
intentionally make the request loop by sending a Route set with<br>
non-unique URIs. Nevertheless I've posted a question on sr-users mailing<br>
list to confirm that kamailio behavior is 100% valid.<br>
</blockquote></div><br></div>