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

Richard Fuchs rfuchs at sipwise.com
Tue Feb 18 10:17:04 EST 2014


Hello,

This error ("Got LOOKUP ...") is caused by the answer SDP containing an
explicit RTCP port that's different from the implicit one:

m=audio 49154 RTP/AVP 0 126
a=rtcp:30009

While this is perfectly valid SDP, unfortunately this case is not well
supported by the current stable mediaproxy-ng (the next major release
will correctly handle this). Is there a way to configure the Dialogic to
run RTCP only on the default implicit port?

The other error ("Error generating SRTP session keys") is caused by the
Dialogic sending RTP packets before the answer SDP was received by
mediaproxy-ng, aka early media. Early media is not possible when using
SDES, as the SRTP keys are unidirectional and signalled only for
outgoing direction. This is a design limitation of the SDES protocol.

Neither of these errors should break the flow of RTP though. The first
error will break RTCP but not RTP (which normally isn't a big problem),
while the second one will break early media, but not RTP after the
answer SDP has been received. Maybe there's something else going on that
breaks RTP?

cheers


On 02/17/14 13:57, Ashutosh Apte wrote:
> 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 <http://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
> <mailto: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 <mailto: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
>         <http://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
> 
> 
> 
> 
> 
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> http://lists.sipwise.com/listinfo/spce-user
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20140218/79cc0330/attachment-0001.asc>


More information about the Spce-user mailing list