Generic selectors
Exact matches only
Search in title
Search in content

reINVITE compliance – RFC 3264

Viewing 1 post (of 1 total)
  • Author
    Posts
  • #30328 Reply
    Anad Xocliw
    Guest

    Folks,

    Need some help interpreting section 8 for reINVITE comlpliance for this flow.

    Specifically; am I correct in stating that a component of compliance is the ability for a UAS’s reINVITE to change a stream limited to the original media stream offers and definition of the UAC?

    Ex. If m=… 0 18 was offered and answered with 0; a complinat reINVITE by a UAS can offer
    m=…18 only.

    “8 Modifying the Session

    At any point during the session, either participant MAY issue a new
    offer to modify characteristics of the session. It is fundamental to the operation of the offer/answer model that the exact same offer/answer procedure defined above is used for modifying parameters of an existing session.

    The offer MAY be identical to the last SDP provided to the other
    party (which may have been provided in an offer or an answer), or it
    MAY be different. We refer to the last SDP provided as the “previous
    SDP”. If the offer is the same, the answer MAY be the same as the
    previous SDP from the answerer, or it MAY be different. If the
    offered SDP is different from the previous SDP, some constraints are
    placed on its construction, discussed below.

    Nearly all aspects of the session can be modified. New streams can
    be added, existing streams can be deleted, and parameters of existing
    streams can change. When issuing an offer that modifies the session,
    the “o=” line of the new SDP MUST be identical to that in the
    previous SDP, except that the version in the origin field MUST
    increment by one from the previous SDP. If the version in the origin
    line does not increment, the SDP MUST be identical to the SDP with
    that version number. The answerer MUST be prepared to receive an
    offer that contains SDP with a version that has not changed; this is
    effectively a no-op. However, the answerer MUST generate a valid
    answer (which MAY be the same as the previous SDP from the answerer,
    or MAY be different), according to the procedures defined in Section
    6.

    If an SDP is offered, which is different from the previous SDP, the
    new SDP MUST have a matching media stream for each media stream in
    the previous SDP. In other words, if the previous SDP had N “m=”
    lines, the new SDP MUST have at least N “m=” lines. The i-th media
    stream in the previous SDP, counting from the top, matches the i-th
    media stream in the new SDP, counting from the top. This matching is
    necessary in order for the answerer to determine which stream in the
    new SDP corresponds to a stream in the previous SDP. Because of
    these requirements, the number of “m=” lines in a stream never
    decreases, but either stays the same or increases. Deleted media
    streams from a previous SDP MUST NOT be removed in a new SDP;
    however, attributes for these streams need not be present.”

Viewing 1 post (of 1 total)
Reply To: reINVITE compliance – RFC 3264
Your information:




<a href="" title="" rel="" target=""> <blockquote cite=""> <code> <pre class=""> <em> <strong> <del datetime="" cite=""> <ins datetime="" cite=""> <ul> <ol start=""> <li> <img src="" border="" alt="" height="" width="">