Added creator attribute to mute and unmute elements so that these events can be correlated with a particular content type; clarified use of the reason element in cases other than termination.
Added creator attribute to mute and unmute elements so that these events can be correlated with a particular content type; clarified use of the reason element in cases other than termination; defined handling of content-add when none of the offered payload-types are supported, where the signalling uses a content-reject message with a Jingle reason of <failed-application/> and a list of the supported codecs.
Note: If the responder supports none of the payload-types offered by the initiator, the responder SHOULD terminate the session and include a Jingle reason of <failed-application/>. This reason can also be included in non-termination events, such as content-reject when the other party has tried to add a content-type for which the recipient supports none of the payload types.
+If the responder supports none of the payload-types offered by the initiator, the responder SHOULD terminate the session and include a Jingle reason of <failed-application/>.
If the responder accepts the session, the initiator acknowledges the session-accept message:
Then Juliet accepts video.
+Note: If the responder supports none of the payload-types offered by the initiator, the responder MUST reply to the content-add request with a content-reject; this message SHOULD include a Jingle reason of <failed-application/> and a list of the payload-types that the responder supports (along with an empty element for the same transport offered by the initiatior), as shown in the following example.
+However, here we assume that Juliet's client supports at least one of the payload-types offered by Romeo's client, and that she Juliet accepts the offer of adding video to the session.