<div dir="ltr">Hi Andrew,<div> I'm attaching a fresh set of rtp / proxy logs that contains only one failed call to avoid distraction.</div><div><br></div><div>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. </div>
<div><br></div><div><div><font size="1">Feb 17 19:31:17 spce mediaproxy-ng[3732]: Got valid command from <a href="http://127.0.0.1:43412">127.0.0.1:43412</a>: 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" }</font></div>
<div><font size="1">Feb 17 19:31:17 spce mediaproxy-ng[3732]: [0e14086c-8057-649a-144d-eb68db003365 - z9hG4bKb7b9.deb8e0f4a4dd082b065875a1bcc028fc.0] <b><font color="#ff0000">Got LOOKUP, but no usable callstreams found</font></b></font></div>
</div><div><br></div><div>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?</div><div><br></div><div>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.</div>
<div><br></div><div>Ashu</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Feb 15, 2014 at 10:39 AM, Ashutosh Apte <span dir="ltr"><<a href="mailto:apteashutosh@gmail.com" target="_blank">apteashutosh@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Andrew,<div><br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>I notice the following error in the rtp.log:</div><div>Feb 15 00:06:35 spce mediaproxy-ng[3812]: Error generating SRTP session keys<br></div><div><br></div><div>Also, it seem to log only for "Side A". I don't see anything for "Side B"</div>
<div><br></div><div>The file contains more than one call. The above timestamp points to the last call in the log.</div><div class=""><div><br></div><div>Thanks again for all your help.</div></div><div>Ashu</div></div><div class="HOEnZb">
<div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Feb 14, 2014 at 11:25 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 Ashu,<br>
<div><br>
On 15/02/14 01:20, Ashutosh Apte wrote:<br>
> 1: I notice that sipML5 offers payload type 126 for DTMF. However, the<br>
> legacy gateway that I'm using ignores that and responds with 101. This<br>
> is obviously an issue on the legacy gateway and I'm trying to see if I<br>
> can resolve it on that end. In the absence of that, the sipML5 client<br>
> falls back to SIP INFO method. The kamailio proxy responds back with 405<br>
> "Method Not Allowed". A cursory look at<br>
> /etc/ngcp-config/templates/etc/kamailio/proxy/proxy.cfg.tt2 seems to<br>
> indicate that INFO is not supported and hence it returns an error<br>
> response. Is there a way to change the proxy to have the SIP INFO<br>
> message sent over to the legacy gateway?<br>
><br>
> (P.S. I tweaked proxy.cfg.tt2 to route INFO to ROUTE_PBX_REQUEST but<br>
> that caused the proxy to respond with either 486 Busy here or 408<br>
> Timeout so I've reverted those changes.)<br>
<br>
</div>It should be ROUTE_PRX_REQUEST, see this thread:<br>
<a href="http://lists.sipwise.com/pipermail/spce-user/2014-February/005788.html" target="_blank">http://lists.sipwise.com/pipermail/spce-user/2014-February/005788.html</a><br>
If that's what you did, I'd suppose that INFO gets relayed to the legacy<br>
gateway and gw is the one that responds with 486 or 408. Have a look at<br>
the network trace or kamailio-lb.log (without debug - ngcp-kamctl lb<br>
fifo debug 2), if unsure send me the kamailio-proxy log so as to see if<br>
INFO is handled correctly.<br>
Spce can't transcode DTMF like <a href="http://webrtc2sip.org" target="_blank">webrtc2sip.org</a> does..<br>
<div><br>
> 2: My bigger issue at the moment is that even though the call is<br>
> successfully established between the sipML5 client and the legacy<br>
> gateway (that plays an IVR script), I cannot hear any audio on the<br>
> sipML5 side. I've captured network packets on both ends and:<br>
><br>
> a: Legacy gateway end: I can successfully listen to what is being spoken<br>
> on the sipML5 end (microphone is working, in other words) and I can also<br>
> confirm that valid packets are being streamed out.<br>
><br>
> b: sipML5 client end: Since the RTP streams are encrypted, I can not<br>
> play them back through the network capture tool. I do know that the<br>
> speakers are working properly as I can hear the ringback tone (that is<br>
> locally generated) and DTMF tones when pressing keys on the keypad<br>
> (again, locally generated)<br>
><br>
> so it seems that the media path is working one way:<br>
> sipML5 --> mediaproxy --> legacy gateway [OK]<br>
> legacy gateway --> mediaproxy --> sipML5 [Not OK]<br>
<br>
</div>Let's see your /var/log/ngcp/rtp.log, it should show A/B side RTP<br>
statistics in the end and the flags mediaproxy-ng was called with..<br>
<br>
cheers,<br>
Andrew<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>