asterisk users - Aug 2014 - Asterisk rejects sdp from webrtc client

Hello,

I was testing with sdp and something came up worth asking:

While calling from a webrtc client to another (chrome, sip.js) Asterisk
receives the following sdp and rejects it with 488 Not Acceptable. Why does
this happen, what's wrong with the sdp? The second sdp body below is
accepted instead. Both have rtp profile RTP/SAVPF, difference is that the
second one was produced by rtpengine, first one came directly from the
client.

I defined my clients according to the sip.js guide:
http://sipjs.com/guides/server-configuration/asterisk/

So this was rejected:
(I marked the extra lines with '//' to ease looking through the
differences)

v=0
o=- 9046935681162021751 2 IN IP4 91.221.66.61
s=-
t=0 0
a=group:BUNDLE audio //
a=msid-semantic: WMS Kqg5QpXyqNeviT8qxUIRi8QNUaV7mUnFiDIF
m=audio 11076 RTP/SAVPF 111 103 104 0 8 106 105 13 126
c=IN IP4 91.221.66.61
a=candidate:2999745851 1 udp 2122260223 192.168.56.1 52820 typ host
generation 0 //
a=candidate:2999745851 2 udp 2122260223 192.168.56.1 52820 typ host
generation 0 //
a=candidate:3350409123 1 udp 2122194687 192.168.0.101 52821 typ host
generation 0 //
a=candidate:3350409123 2 udp 2122194687 192.168.0.101 52821 typ host
generation 0 //
a=candidate:4233069003 1 tcp 1518280447 192.168.56.1 0 typ host generation 0
//
a=candidate:4233069003 2 tcp 1518280447 192.168.56.1 0 typ host generation 0
//
a=candidate:2301678419 1 tcp 1518214911 192.168.0.101 0 typ host generation
0 //
a=candidate:2301678419 2 tcp 1518214911 192.168.0.101 0 typ host generation
0 //
a=candidate:1190865175 1 udp 1685987071 91.145.67.22 52821 typ srflx raddr
192.168.0.101 rport 52821 generation 0 //
a=candidate:1190865175 2 udp 1685987071 91.145.67.22 52821 typ srflx raddr
192.168.0.101 rport 52821 generation 0 //
a=ice-ufrag:QJy1Fslu8ITGYl/d //
a=ice-pwd:Q8N6+0PPj4CUG6leGAie7zaL //
a=ice-options:google-ice //
a=fingerprint:sha-256
CF:30:A7:7F:71:11:D4:5E:B0:E7:E3:F9:D8:C2:F4:60:2A:D0:76:46:F8:3A:97:01:C9:0C:5A:F7:B8:7D:C1:43
a=setup:actpass
a=mid:audio //
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level //
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time //
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:2179369454 cname:SvzCJjIAujxHGm9P
a=ssrc:2179369454 msid:Kqg5QpXyqNeviT8qxUIRi8QNUaV7mUnFiDIF
add6e533-c83d-42f2-b487-fcac8646ad32
a=ssrc:2179369454 mslabel:Kqg5QpXyqNeviT8qxUIRi8QNUaV7mUnFiDIF
a=ssrc:2179369454 label:add6e533-c83d-42f2-b487-fcac8646ad32
a=sendrecv
a=rtcp:11077
a=rtcp-mux
a=candidate:hhsCc0ehS5qzXXxS 1 UDP 1518214655 91.221.66.61 11076 typ host
a=candidate:hhsCc0ehS5qzXXxS 2 UDP 1518214654 91.221.66.61 11077 typ host


And this was accepted as such:

v=0
o=- 9046935681162021751 2 IN IP4 91.221.66.61
s=-
t=0 0
a=msid-semantic: WMS Kqg5QpXyqNeviT8qxUIRi8QNUaV7mUnFiDIF
m=audio 11080 RTP/SAVPF 111 103 104 0 8 106 105 13 126
c=IN IP4 91.221.66.61
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:2179369454 cname:SvzCJjIAujxHGm9P
a=ssrc:2179369454 msid:Kqg5QpXyqNeviT8qxUIRi8QNUaV7mUnFiDIF
add6e533-c83d-42f2-b487-fcac8646ad32
a=ssrc:2179369454 mslabel:Kqg5QpXyqNeviT8qxUIRi8QNUaV7mUnFiDIF
a=ssrc:2179369454 label:add6e533-c83d-42f2-b487-fcac8646ad32
a=sendrecv
a=rtcp:11081
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:RV9RgRP59zI6AoZKhGT4iq0Fj6A5tVbLy+zzj9JB
a=setup:actpass
a=fingerprint:sha-1
C2:D0:75:69:46:19:83:17:22:08:D4:8F:46:39:C7:AD:06:6A:CD:CC


cheers,
Olli
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20140822/3f797cb9/attachment.html>