Subject: [MMUSIC] [RFC4566] Increment of SDP session version when NO modification is made to the session data

From: "Anh Cao" <[email-masked]>
Date: Tue, 15 Mar 2016 09:04:07 +0700

Hi all

I am a new in SIP/SDP and I have a question about the session version of
SDP:

According to the  <https://tools.ietf.org/html/rfc4566#page-11> RFC4566 item
5.2 : <sess-version> is a version number for this session description.  Its
usage is up to the creating tool, so long as <sess-version> is increased
when a modification is made to the session data.

So, If session data is NOT made any change, is session-version acceptable to
increase or it is NOT ?

I used SIPp tool (137.116.158.97) to check my SIP proxy (10.250.160.168) and
see that 200 OK INVITE and 200 OK re-INVITE have SDP data are the same but
session-version is increased by 1, and I'm not sure this behaivio of SIP
proxy is acceptable or not?

Thanks for reading my email. I highly appreciate your help.

Best regards,

Anh Cao

---

From: Brett Tate <[email-masked]>
Date: Tue, 15 Mar 2016 10:36:47 -0400

> I am a new in SIP/SDP and I have a question

The following list may be helpful for future sip related questions.

https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

> If session data is NOT made any change, is session-version
> acceptable to increase or it is NOT?

As far as I know, RFC 4028 section 7.4 provides the only related mandate.
For interoperability reasons, I recommend being lenient when receiving.

Section 7.4:

"It is RECOMMENDED that the UPDATE request not contain an
offer [4], but a re-INVITE SHOULD contain one, even if the details of
the session have not changed.  In that case, the offer MUST indicate
that it has not changed.  In the case of SDP, this is accomplished by
including the same value for the origin field as did previous SDP
messages to its peer.  The same is true for an answer exchanged as a
result of a session refresh request; if it has not changed, that MUST
be indicated."

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 15 Mar 2016 11:59:20 -0400

> So, If session data is NOT made any change, is session-version acceptable to

Yes, because there is no rule that forbids it.

OTOH, the recipient of the SDP may do more work to process the SDP if it
has a new version number than if the version number is unchanged -- if
the version number is unchanged, the recipient knows that the SDP has
not changed and need not analyze it.  So it is in general preferable to
not change the version number if the SDP has not changed.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Mar 2016 12:04:10 -0400

> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Yes, that is the best place for this sort of query.

> result of a session refresh request; if it has not changed, that MUST

Note that 4028 is only concerned with session timers. IMO its language 
is confusing and possibly deceptive in some regards. It is *not* 
intended to refine how offer/answer works - only to comment on how 
standard O/A rules might best be used for signaling triggered by session 
timer.

AFAIK it is not *invalid* to increase the SDP session-version when 
nothing else in the SDP has changed. But doing so may cause the other 
side to do more work. (It might have an optimization for the case where 
the version isn't changed.)

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Tue, 15 Mar 2016 13:06:01 -0400

Hi,

> >> If session data is NOT made any change, is session-version acceptable
> >> to increase or it is NOT?
> >
> > "It is RECOMMENDED that the UPDATE request not contain an offer [4],
> > but a re-INVITE SHOULD contain one, even if the details of the session
> > have not changed.  In that case, the offer MUST indicate that it has
> > not changed.  In the case of SDP, this is accomplished by including
> > the same value for the origin field as did previous SDP messages to
> > its peer.  The same is true for an answer exchanged as a result of a
> > session refresh request; if it has not changed, that MUST be
> > indicated."
>
is
> confusing and possibly deceptive in some regards. It is *not* intended
to
> refine how offer/answer works - only to comment on how standard O/A
rules
> might best be used for signaling triggered by session timer.

I agree that text only applies to devices that support RFC 4028.  However
AFAIK, it does impose related mandates on devices that support RFC 4028
since the working group decided to use MUST instead of SHOULD.

---

From: "Anh Cao" <[email-masked]>
Date: Wed, 16 Mar 2016 09:35:19 +0700

Thank everyone for helping me.

So, if session data is not changed, session version can be increased but NOT
RECOMMENDED because it may cause the other side to do more work :)

Best regards,

Anh Cao

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Brett Tate
Sent: Wednesday, March 16, 2016 12:06 AM
To: Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] [RFC4566] Increment of SDP session version when NO
modification is made to the session data

Hi,

> > As far as I know, RFC 4028 section 7.4 provides the only related

mandate.

> > For interoperability reasons, I recommend being lenient when

receiving.

> > but a re-INVITE SHOULD contain one, even if the details of the 

> > session have not changed.  In that case, the offer MUST indicate 

> > that it has not changed.  In the case of SDP, this is accomplished 

> > by including the same value for the origin field as did previous SDP 

> > result of a session refresh request; if it has not changed, that 

> > MUST be indicated."

is

to

rules

_______________________________________________

mmusic mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/mmusic>
https://www.ietf.org/mailman/listinfo/mmusic