Subject: [Sipping] I-DACTION:draft-sawada-sipping-sip-offeranswer-01.txt: SDP sess-version

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 28 Jun 2006 12:34:14 +0200

Hi,

However, without going into that, I think it would be good to describe
what happens when a UAS receives an offer where the sess-version is
identical to the previous. I propose that the UAS should simply return
the previous answer in this case.

The reason I think this is important is because it would cause less
impact e.g. on the usage of the re-INVITE for session-timer. The UAS
does not need to compare the SDP with the previous one in order to
determine whether they are identical or not - it simply looks at the
sess-version value.

Now, one can say that this is already described in the SDP spec, and
that it is very obvious. Well, I have seen implementations that do not
increase the value, even if the SDP is updated, so I think it would be
good to clarify. Also, it is not so much about teach-yourself-SDP, but
more about the expected behavior of the one receiving the offer.

In another e-mail I talked about the possibility to use the SDP
sess-version (part of the o= line) to reject an offer, by not increasing
the sess-version value in the answer, but that is a separate discussion.

Regards,

Christer

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked]
Date: Wed, 28 Jun 2006 08:27:00 -0400

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>

Maybe I'm overlooking something, but doesn't this passage (RFC 3264,
section 8, paragraph 3) cover all these matters?

     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.

So if a UA receives an offer with the same version as previously, the
offer must be identical to the previous offer.  The UA must return an
answer, which might be the same as the previous answer (and have the
same version as the previous answer), or it may have an incremented
version (and then may be different from the previous answer).

   I have seen implementations that do not increase the value.

They're erroneous.

   In another e-mail I talked about the possibility to use the SDP
   sess-version (part of the o= line) to reject an offer, by not
   increasing the sess-version value in the answer, but that is a
   separate discussion.

That isn't rejecting the offer, though, that's providing the previous
answer as the answer to the new offer.  It does seem that if the
previous answer is also a valid answer for the new offer, it's
allowed to do that.

Dale