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

Fri Feb 14 17:33:32 EST 2014

Hi Andrew,
    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.

Let me know if you need anything else. I'll be happy to test.

Thanks again,
Ashu

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

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