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

[Ashutosh Apte]

Hi Andrew,


1: SIP INFO for DTMF: I should have checked the legacy gateway side to see
if the INFO messages are showing up. I'll repeat the test and send logs if
it fails to show up.

2: Attached are the proxy and rtp logs. I've included a network capture
from the legacy gateway end. Since it is plain RTP, one can listen to both
directions and confirm that the audio from sipML5 --> legacy gateway is
working and also that the legacy gateway is streaming proper audio out.

I notice the following error in the rtp.log:
Feb 15 00:06:35 spce mediaproxy-ng[3812]: Error generating SRTP session keys

Also, it seem to log only for "Side A". I don't see anything for "Side B"

The file contains more than one call. The above timestamp points to the
last call in the log.

Thanks again for all your help.
Ashu


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

> Hi Ashu,
>
> On 15/02/14 01:20, Ashutosh Apte wrote:
> > 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.)
>
> It should be ROUTE_PRX_REQUEST, see this thread:
> http://lists.sipwise.com/pipermail/spce-user/2014-February/005788.html
> If that's what you did, I'd suppose that INFO gets relayed to the legacy
> gateway and gw is the one that responds with 486 or 408. Have a look at
> the network trace or kamailio-lb.log (without debug - ngcp-kamctl lb
> fifo debug 2), if unsure send me the kamailio-proxy log so as to see if
> INFO is handled correctly.
> Spce can't transcode DTMF like webrtc2sip.org does..
>
> > 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]
>
> Let's see your /var/log/ngcp/rtp.log, it should show A/B side RTP
> statistics in the end and the flags mediaproxy-ng was called with..
>
> cheers,
> Andrew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20140215/d31f1895/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sip_works_one_way_audio.zip
Type: application/zip
Size: 3487620 bytes
Desc: not available
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20140215/d31f1895/attachment-0001.zip>