QoS and SDP

“The offer/answer model [RFC 3264] for SDP [RFC4 566] does not provide any mechanism for endpoints to negotiate the QoS mechanism to be used for a particular media stream. Even when QoS preconditions [RFC3 312] are used, the choice of the QoS mechanism is left unspecified and is up to the endpoints. Endpoints that support more than one QoS mechanism need a way to negotiate which one to use for a particular media stream. Examples of QoS mechanisms are RSVP (Resource Reservation Protocol) [RFC 2205] and NSIS (Next Steps in Signaling) [QoS-NSLP].”

RFC 5432: Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) published in March 2009

Introduces qos-mech-send and qos-mech-recv attributes for SDP.

Slide Notes

James Polk, Subha Dhesikan, and Gonzalo Camarillo, Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP), IETF, Network Working Group, RFC 5432, March 2009 http://tools.ietf.org/html/rfc5432 Links to an external site./p>

Transcript

[slide212] Now, the next problem was QoS. So we have these descriptions about what we want to exchange in our streams of media. But, oops, we never really have baked in a means to describe the quality of service that we want. So RFC 5432 says here's a way of being able to put QoS specifications into the SDP. So now I can basically say if you can meet these quality of service requirements, for instance, by setting it up using RSVP, here's the kind of video you can get. If you can't manage those bandwidths, then there's no point in trying to set up this high-quality video, choose another video quality.