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

[Ashutosh Apte]

Hi Andrew,
    I'm attaching a fresh set of rtp / proxy logs that contains only one
failed call to avoid distraction.

>From the rtp.log, it looks like that there is something in the sdp answer
from the legacy gateway that the rtpproxy does not like.

Feb 17 19:31:17 spce mediaproxy-ng[3732]: Got valid command from
127.0.0.1:43412: answer - { "sdp": "v=0#015#012o=Dialogic_SIP_CCLIB
3033845960 3033845961 IN IP4
172.20.151.76#015#012s=Dialogic_SIP_CCLIB#015#012t=0
0#015#012a=group:BUNDLE audio#015#012a=msid-semantic: WMS
Ylq6JTKuRTrFYJJ0Mkgs8q5vAcAT14UT2Y4f#015#012m=audio 49154 RTP/AVP 0
126#015#012c=IN IP4
172.20.151.76#015#012a=mid:audio#015#012a=sendrecv#015#012a=rtpmap:0
PCMU/8000#015#012a=rtcp:30009#015#012a=ptime:20#015#012a=rtpmap:126
telephone-event/8000#015#012a=fmtp:126
0-15#015#012a=direction:active#015#012", "ICE": "force", "flags": [
"force", "trust-address", "symmetric" ], "replace": [ "origin",
"session-connection" ], "transport-protocol": "RTP/SAVPF", "call-id":
"0e14086c-8057-649a-144d-eb68db003365", "via-branch":
"z9hG4bKb7b9.deb8e0f4a4dd082b065875a1bcc028fc.0", "received-from": [ "IP4",
"127.0.0.1" ], "from-tag": "e8MNyf126LvTdyK3kOAM", "to-tag":
"5F0A4E3C-53025574000BE441-DECBB700", "command": "answer" }
Feb 17 19:31:17 spce mediaproxy-ng[3732]:
[0e14086c-8057-649a-144d-eb68db003365 -
z9hG4bKb7b9.deb8e0f4a4dd082b065875a1bcc028fc.0] *Got LOOKUP, but no usable
callstreams found*

Let me know if the attached logs are of any help. If not, is there a way to
increase the logging level for the rtpproxy?

Thanks for all your help. I have a feeling that I'm very close to getting
this working and move ahead with evaluating other areas of sipProvider for
our needs.

Ashu


On Sat, Feb 15, 2014 at 10:39 AM, Ashutosh Apte <apteashutosh at gmail.com>wrote:

> 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/20140217/673f8e8b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtp_log.zip
Type: application/zip
Size: 457343 bytes
Desc: not available
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20140217/673f8e8b/attachment-0001.zip>