Its clear from 3264 that just as an offer can change the session, the
answer may change as well. Think of the sip session as having one
currently active session description on each end. Via subsequent
offer/answer either one of the session descriptions may be changed by
providing a suitable SDP in an offer or answer. If a session description
is changed in an offer then the version number in that offer must be
incremented. If the session description is changed in an answer then the
version number must be incremented in the answer SDP.
Paul
Alexeitsev, D wrote:
> Thank you for the citation.
>
> The question is does the defined MUST connection between a new offer and
> increment of the version number works in the opposite way? I.e. the
> incremented version number MUST mean a new offer even if the version change
> occurred in SDP transported in 200 OK?
>
> Greetings,
> Denis Alexeitsev
>
> -----Ursprьngliche Nachricht-----
> Von: Harpreet S Juneja [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 26. Juli 2007 15:34
> An: Alexeitsev, Denis
> Cc: sip-implementors@lists.cs.columbia.edu
> Betreff: Re: [Sip-implementors] Relevance of the session version field in SDP
> answer
>
>
> RFC3264 "An Offer/Answer Model with the Session Description Protocol" (par. 8
> Modifying the Session), specifies that:
>
>
> "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."
>
>
>
> On 26/07/07, Alexeitsev, D <[EMAIL PROTECTED]> wrote:
>
>> Hello All
>>
>> Does the value of the session version field in an answer effectively
>> mean anything, or does it only have a meaning in an offer?
>>
>> The problem is that some UAS increment the version number in the
>> answer and some UACs interpret it as a new offer and try to answer it
>> in the ACK. That leads to all kind of mess.
>>
>> So who is wrong here - UAS incrementing the version number in the
>> answer, or UAC interpreting it as a new offer?
>>
>> Greetings,
>> Denis Alexeitsev
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> <mailto:Sip-implementors@lists.cs.columbia.edu>
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
