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

Fri Feb 14 20:07:11 EST 2014

Hi Andrew,
    Update on SIP INFO / DTMF issue.

I changed the legacy gateway to force using the same telephone-event
payload type (126, in this case) but it had no effect on sipML5 client
behavior. It continues to send DTMF events using SIP INFO. This results in
DTMFs not crossing the sipCE.

In the meantime, I also routed a call through WebRTC2SIP (
http://webrtc2sip.org/) gateway and found out that it accepts SIP INFO
message and uses it to insert DTMF (RFC 2833) packets into the RTP stream
towards the legacy gateway.

Is this something I can do with sipCE?

Thanks again,
Ashutosh

On Fri, Feb 14, 2014 at 4:20 PM, Ashutosh Apte <apteashutosh at gmail.com>wrote:

> 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/427845a2/attachment-0001.html>