Support for RFC 5576

Wondering if there is already support for RFC 5576 ( ) in asterisk or if anyone would have some pointers into how I can extend asterisk to support this.

The reason is the newest version of Chrome to be released sometime in Dec sends the ssrc attributes in the SDP and expects an answer to have the ssrc attributes as well. Chrome/WebRTC developers have acknowledged this as a bug on their end but may not be able to get a fix in before Chrome 24 is shipped and it will have to wait for Chrome 25. This would mean I am unable to use WebRTC with an asterisk endpoint until then.

Hoping Google can fix, but if not will have to add the ssrc attributes to the accept SDP.
If I have to add them in, wondering where the ssrc data exists so I can append to the SDP with the appropriate values.

Thanks so much.

Asterisk doesn’t maintain the integrity of SSRCs in RTP, when non-natively bridging (we had problems with Cisco phones not liking it when there was a transition between an internally generated beep and through audio from the agent, when a queue connected to an agent - there is a discontinuity in time stamps, and although the mark bit was set the phones really wanted a new SSRC). There is no field in the ast_frame structure to carry any abstraction of an SSRC (Asterisk is not designed around SIP).

If you get packet to packet native bridging, the packets are retransmitted with the original SSRCs, and external bridging sends the original packets direct. However, anything that goes through the core has a completely new SSRC generated on the other side.

I think it very unlikely that it would support sending SSRCs in the SDP.

nickfirespotter, we made a patch for sending ssrc in the SDP according to RFC 5576 succesfully. It adds a line a=ssrc: for both audio and video media sections from the value used in each RTP frame. It even compounds a cname: field as the RFC says, (according to RFC it’s a MUST), although its value is filled on the fly with the SIP call-info header field because Asterisk (the one we are modifying from) does not fill the CNAME chunk in the SDES field of RTCP. We don’t need it and I guess Chrome does not need it either but, if it were necessary, there would also be a patch to fill the CNAME chunk in RTCP from here: … 39664.html
In that case you’ll have to adjust our patch because the shifted lines.