<div dir="ltr">Hi Andrew,<div> Thank you for the quick turn-around. I followed your instructions and collected logs. The attached .zip file also contains javascript console logs for sipML5 in case they are of any use.</div>
<div><br></div><div>Let me know if you need anything else. I'll be happy to test.</div><div><br></div><div>Thanks again,</div><div>Ashu</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 14, 2014 at 1:59 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">Hi,<br>
thanks for detailed info, the problem is that kamailio-lb fails to<br>
remove its own Route headers so the ACK loops from proxy back to lb.<br>
<br>
The request and specifically the Route headers look OK to my eye:<br>
> Feb 14 20:41:58 spce lb[3773]: NOTICE: <script>: New request - M=ACK R=sip:ngcp-lb@172.18.101.48:5060;ngcpct=7369703a3132372e302e302e313a35303830 F=<a href="mailto:sip%3A4252143385@172.18.101.48">sip:4252143385@172.18.101.48</a> T=<a href="mailto:sip%3A2067077495@172.18.101.48">sip:2067077495@172.18.101.48</a> IP=ws:<a href="http://172.18.101.38:62770" target="_blank">172.18.101.38:62770</a> ID=58961608-d303-29b9-f2b3-827dc65b7179<br>
> Feb 14 20:41:58 spce lb[3773]: INFO: <script>: Unmasked internal contact - R=sip:<a href="http://127.0.0.1:5080" target="_blank">127.0.0.1:5080</a> ID=58961608-d303-29b9-f2b3-827dc65b7179<br>
> Feb 14 20:41:58 spce lb[3773]: INFO: <script>: Reset loose-routing, du='sip:172.18.101.48;transport=ws;r2=on;lr=on;ftag=qKNJeBx56Duy6f26lMTq;nat=yes;ngcplb=yes;socket=ws:<a href="http://172.18.101.48:5060" target="_blank">172.18.101.48:5060</a>' - R=sip:<a href="http://127.0.0.1:5080" target="_blank">127.0.0.1:5080</a> ID=58961608-d303-29b9-f2b3-827dc65b7179<br>
><br>
> ACK sip:<a href="http://127.0.0.1:5080" target="_blank">127.0.0.1:5080</a> SIP/2.0<br>
> Record-Route: <sip:127.0.0.1;r2=on;lr=on;ftag=qKNJeBx56Duy6f26lMTq;nat=yes;ngcplb=yes;socket=ws:<a href="http://172.18.101.48:5060" target="_blank">172.18.101.48:5060</a>><br>
> Record-Route: <sip:172.18.101.48;transport=ws;r2=on;lr=on;ftag=qKNJeBx56Duy6f26lMTq;nat=yes;ngcplb=yes;socket=ws:<a href="http://172.18.101.48:5060" target="_blank">172.18.101.48:5060</a>><br>
> Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK7e9f.7ae637ea9391145a1b3a2569182092f3.0<br>
> Via: SIP/2.0/WS df7jal23ls0d.invalid;received=172.18.101.38;branch=z9hG4bK0LbF7QFyhgoyOk2gQVK1;rport=62770<br>
> From: \"4252143385\"<<a href="mailto:sip%3A4252143385@172.18.101.48">sip:4252143385@172.18.101.48</a>>;tag=qKNJeBx56Duy6f26lMTq<br>
> To: <<a href="mailto:sip%3A2067077495@172.18.101.48">sip:2067077495@172.18.101.48</a>>;tag=6111C524-52FE71860005D18C-321A4700<br>
> Contact: \"<a href="tel:4252143385" value="+14252143385">4252143385</a>\"<sip:<a href="tel:4252143385" value="+14252143385">4252143385</a>@df7jal23ls0d.invalid;alias=172.18.101.38~62770~5;rtcweb-breaker=yes;click2call=no;transport=ws>;+g.oma.sip-im;+sip.ice;language=\"en,fr\"<br>
> Call-ID: 58961608-d303-29b9-f2b3-827dc65b7179<br>
> CSeq: 19663 ACK<br>
> Content-Length: 0<br>
> Max-Forwards: 15<br>
> Proxy-Authorization: Digest username=\"4252143385\",realm=\"172.18.101.48\",nonce=\"Uv5yslL+cYbPfssd+yGMtK3o3OXkGDEm\",uri=\"sip:ngcp-lb@172.18.101.48:5060;ngcpct=7369703a3132372e302e302e313a35303830\",response=\"087b7a6b4c55c1b8be8734072be1628c\",algorithm=MD5<br>
> Route: <sip:172.18.101.48;transport=ws;r2=on;lr=on;ftag=qKNJeBx56Duy6f26lMTq;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=qKNJeBx56Duy6f26lMTq;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=qKNJeBx56Duy6f26lMTq;did=1ab.20c1;mpd=ii;ice_caller=strip;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>
> Organization: Doubango Telecom<br>
> P-NGCP-Src-Ip: 172.18.101.38<br>
> P-NGCP-Src-Port: 62770<br>
> P-NGCP-Src-Proto: ws<br>
> P-NGCP-Src-Af: 4<br>
> P-Sock-Info: ws:<a href="http://172.18.101.48:5060" target="_blank">172.18.101.48:5060</a><br>
> P-NGCP-Src-Nat: 1<br>
<br>
I guess we need to debug kamailio-lb here. Could you please raise the<br>
loglevel to 3:<br>
ngcp-kamctl lb fifo debug 3<br>
then redirect log to a file: tail -f /var/log/ngcp/kamailio-lb.log | tee<br>
kamailio-lb-debug.log<br>
make a test call and send me the kamailio-lb-debug.log file?<br>
And the kamailio-proxy.log with debug for this call would be also nice.<br>
>From my side I'll setup a testbed and try to test it with sipml5 soon.<br>
<br>
Regards,<br>
Andrew<br>
<div class=""><br>
On 14/02/14 21:35, Ashutosh Apte wrote:<br>
> Hi Andrew,<br>
> Thanks for your reply. I made the recommended changes and now I can<br>
> see that the INVITE request received by the legacy gateway does contain<br>
> a RTP/AVP media profile. I've run into the next problem though.<br>
><br>
> The legacy gateway does not receive an ACK so the call never gets<br>
> established. (I do see that media from the WebRTC client does make it<br>
> all the way to the legacy gateway so that's a good news.)<br>
><br>
> After about 32 seconds (while the gateway is re-transmitting its 200 OK<br>
> response), ngcp sends an ACK (it is internally generated) followed by a<br>
> BYE request to end the call.<br>
><br>
> I see the following errors in the kamailio-proxy.log:<br>
><br>
> -----<br>
> Feb 14 20:41:58 spce proxy[3785]: DEBUG: <script>: start of route<br>
> ROUTE_OUTBOUND - 1014 ACK<br>
> Feb 14 20:41:58 spce proxy[3785]: WARNING: <core><br>
</div>> [msg_translator.c:2499]: via_builder(): *_TCP/TLS connection (id: 0) for<br>
> WebSocket could not be found_*<br>
<div class="">> Feb 14 20:41:58 spce proxy[3785]: ERROR: <core> [msg_translator.c:1725]:<br>
> build_req_buf_from_sip_req(): could not create Via header<br>
> Feb 14 20:41:58 spce proxy[3785]: ERROR: <core> [forward.c:607]:<br>
> forward_request(): ERROR: forward_request: building failed<br>
> Feb 14 20:41:58 spce proxy[3785]: ERROR: sl [sl_funcs.c:371]:<br>
> sl_reply_error(): ERROR: sl_reply_error used: I'm terribly sorry, server<br>
> error occurred (1/SL)<br>
> Feb 14 20:41:58 spce proxy[3785]: DEBUG: <script>: exit of route<br>
> ROUTE_OUTBOUND - 1014 ACK<br>
> -----<br>
><br>
</div>> Note that I'm using *ws://*<a href="http://172.18.101.48:5060/ws" target="_blank">172.18.101.48:5060/ws</a><br>
> <<a href="http://172.18.101.48:5060/ws" target="_blank">http://172.18.101.48:5060/ws</a>> (and not http://) as the websocket server<br>
> URL. Andreas had suggested earlier to use *http:*//ip:port/ws. The<br>
<div class="im HOEnZb">> WebRTC clients that I'm using for testing (sipML5 and jsSIP) do not like<br>
> anything other than ws:// for Websocket server URL.<br>
><br>
> Not sure if this is the real issue as the request fails to get sent to<br>
> the legacy gateway, which is not using Websockets but the above<br>
> mentioned error occurs when it is ready to send the ACK to the legacy<br>
> gateway.<br>
><br>
> Also attached is a .zip file containing the proxy and lb logs.<br>
><br>
> Thanks again for all your help. I think I'm getting closer to get<br>
> everything working.<br>
><br>
> Ashutosh<br>
><br>
><br>
><br>
> On Fri, Feb 14, 2014 at 1:38 AM, Andrew Pogrebennyk<br>
</div><div class="HOEnZb"><div class="h5">> <<a href="mailto:apogrebennyk@sipwise.com">apogrebennyk@sipwise.com</a> <mailto:<a href="mailto:apogrebennyk@sipwise.com">apogrebennyk@sipwise.com</a>>> wrote:<br>
><br>
> On 14/02/14 01:33, Ashutosh Apte wrote:<br>
> > I've also created a SIP Peering Group to route calls to a legacy SIP<br>
> > gateway. On dialing, the call hits the legacy gateway but I notice<br>
> that<br>
> > the SDP body in the INVITE message uses RTP/SAVF. This gateway<br>
> does not<br>
> > support sRTP. Is there a way to force the mediaproxy to use RTP only?<br>
> ><br>
> > I've changed the parameter under Domains -> Preferences -> NAT and<br>
> Media<br>
> > Flow Control -> srtp_transcoding from "transparent" to "ForceRTP". The<br>
> > kamailio proxy debug logs do show that the parameter was indeed<br>
> changed<br>
> > but it did not have any effect on the INVITE message.<br>
> ><br>
> > What configuration parameter should I be changing to get this to work?<br>
><br>
> Hi,<br>
> from my PoV you should set srtp_transcoding in the domain to "Prefer<br>
> SRTP" (AFAIK it doesn't work if you leave it as "transparent" and I want<br>
> to add automatic detection of endpoints that use RTP/SAVP and RTP/SAVPF)<br>
> and most important - srtp_transcoding in the peer preferences (for your<br>
> legacy gateway) to "Force RTP". This will enable transcoding. You may<br>
> also need to set rtcp_feedback to "Prefer AVPF" on the domain and "Force<br>
> AVP" on the legacy gateway.<br>
><br>
> Andrew<br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>