Chrome Unable to Process the SDP using SIP Plugin

[Amit Bagga]

Hi All,

I have successfully complied the gateway and sip plugin all is working fine but when consumed in chrome or safari we have the same issue.

///SDP

"v=0
o=CMSsirad-MediaServer 1513083813684169 1 IN IP4 18.221.193.199
s=session
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS janus
m=audio 9 UDP/TLS/RTP/SAVPF 8 110
c=IN IP4 18.xxx.xxx.xxx
a=sendrecv
a=mid:audio
a=rtcp-mux
a=ice-ufrag:z2Nz
a=ice-pwd:1HFtRdnSR7P8bOCHyDn5NV
a=ice-options:trickle
a=fingerprint:sha-256 C9:90:74:8B:80:99:17:4C:F7:0B:39:31:9F:B3:95:8E:C9:6D:8C:C6:A6:3B:59:3C:DE:59:0C:01:17:98:1F:B5
a=setup:active
a=rtpmap:8 PCMA/8000
a=rtpmap:110 telephone-event/48000
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=rtcp-fb:111 transport-cc
a=ssrc:3788505901 cname:janusaudio
a=ssrc:3788505901 msid:janus janusa0
a=ssrc:3788505901 mslabel:janus
a=ssrc:3788505901 label:janusa0
a=candidate:1 1 udp 2013266431 172.xx.xx.xxx 37882 typ host
a=candidate:2 1 udp 1677721855 18.xxx.xxx.xxx 37882 typ srflx raddr 172.xx.xx.xxx rport 37882
a=end-of-candidates

Uncaught (in promise) DOMException: Failed to parse SessionDescription.  Failed to parse audio codecs correctly.

PLEASE HELP!!.

Thank You,

Amit

[Lorenzo Miniero]

My guess would be "a=rtcp-fb:111 transport-cc", as 111 is not a listed payload type. The SIP plugin never originates SDP, so it's something you or someone else is doing wrong in the SIP infrastructure.

L.

[Mirko Brankovic]

by the way, you forgot to hide IP in 0= sdp attribute, next time better use replace options of some editor :)

also  172.16.0.0/12   is private space, if your ip was in that range, so no need to hide private spaces... ;) 

--
You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janus+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Regards,

Mirko

[Amit Bagga]

Thanks for pointing that issue we have fixed and its working now but now the voice quality on the receiving end is bad.

Thank You,
Amit

[Lorenzo Miniero]

The SIP plugin simply relays whatever you send it to the WebRTC user exactly as it is. No transcoding happens, so the bad audio is typically a problem at the source. Apart from that, a-law audio is bad by itself (8khz), and probably suffers from loss more than other codecs.

L.