Subject: [MMUSIC] Does order of SDP attributes have any significance?

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 24 Aug 2010 14:02:06 +0200

Dear all,

I would be glad if you could help me with the following questions:

It is clear that the position of SDP attributes with respect to m-lines
in SDP allows to keep apart media-level and session-level attributes and
to relate attributes to a media line.

But:

1.	Is anybody aware of any SDP attributes where their position
within the attributes of an m-line or within the session level
attributes is of any significance?
2.	Would it be allowed according to RFC 4655 to assign any
semantics to such positions of SDP attributes?
3.	Can one expect that intermediates parsing SDP (without adding or
removing attributes) maintain the order of m-lines, or are there known
examples where the order is modified?

Thanks for your help,

Thomas

---------------------------------- 
Dr. Thomas Belling 
3GPP Standardisation
Nokia Siemens Networks

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 24 Aug 2010 08:50:16 -0500

On 08/24/2010 07:02 AM, Belling, Thomas (NSN - DE/Munich) wrote:
> in SDP allows to keep apart media-level and session-level attributes
> and  to relate attributes to a media line.
> 
> But:
> 

The m-line order cannot be changed; m-lines define media sessions, and
their order is significant. I suppose if an intermediate reordered them,
and also ensured that all future offers from the same endpoint were
reordered in an identical (or at least compatible) fashion it wouldn't
cause any harm, but it's certainly not risk-proof.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: "Roni Even" <[email-masked]>
Date: Wed, 25 Aug 2010 00:18:07 +0300

For the third question look at RFC 3264 section 6
http://tools.ietf.org/html/rfc3264#section-6 

Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Kevin P. Fleming
> Sent: Tuesday, August 24, 2010 4:50 PM
> To: [email-masked]
> Subject: Re: [MMUSIC] Does order of SDP attributes have any
> significance?
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 24 Aug 2010 16:21:49 -0500

> http://tools.ietf.org/html/rfc3264#section-6 

He actually asked a slightly different question, one that is not
addressed by RFC3264 because the RFCs don't address 'middle boxes'. His
question was if endpoint A sends an INVITE with an SDP offer that has
two media streams through some middle box towards endpoint B, and the
middle box reorders the 'm' lines, is that allowable. Yes, endpoint B
has to answer with 'm' lines that match up with the ones it received in
the offer as seen after it leaves the middle box, but as long as the
middle box *also* reorders the 'm' lines in endpoint B's answer,
endpoint A will work as expected.

I still wouldn't want to see it done by middle boxes, but it could be
done in a non-harmful way if care is taken to do it properly.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Aug 2010 17:40:12 -0400

> done in a non-harmful way if care is taken to do it properly.

This depends on what you mean by "middle box".

If you mean *proxy* then it isn't allowed to modify the SDP (or any 
body) in any way.

But if the middle box is a B2BUA, then it can do *anything* to the SDP.
In this case the rules about SDP only apply to any one of the "calls", 
which in this case would be each "side" of the B2BUA.

A particular case of this that I have worked on in the past is where a 
B2BUA decomposes a call with more than one m-line, into multiple calls 
each getting a subset of those m-lines. Of course it must be careful to 
do something that "makes sense".

	Thanks,
	Paul

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 24 Aug 2010 16:43:17 -0500

> which in this case would be each "side" of the B2BUA.

Right... I was explicitly excluding proxies, as the RFCs mandate how
they are allowed to behave, and I think I was using the most common
definition of 'middle box' I've seen on these lists, which is something
that does more than a proxy but less than a B2BUA. This sort of device
does not actually terminate SIP dialogs, it passes them through, but
modifies them in ways that proxies are not allowed to do. SBCs usually
fall into this category, but there are probably other sorts of devices
that do as well... but let's not start the "we should define middle
boxes" discussion again :-)

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Aug 2010 18:43:06 -0400

> boxes" discussion again :-)

If the box is going to do something that a proxy can't do, then it must 
be a UA or it isn't 3261 compliant. If its a *middle* box and a UA, then 
it is presumably a B2BUA.

	Thanks,
	Paul

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 25 Aug 2010 05:00:04 +0200

Dear Kevin,

thanks for your reply. Unfortunately I had a typo in my third question.
Sorry for that confusion. It is clear that the m-line order is very
important.
And although intermediates do all sorts of stuff, they would make their
life very hard when messing around with the m-line order.
What I meant to ask is:

> removing attributes) maintain the order of attribute lines, or are
there known 

Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Kevin P. Fleming
Sent: Tuesday, August 24, 2010 3:50 PM
To: [email-masked]
Subject: Re: [MMUSIC] Does order of SDP attributes have any
significance?

On 08/24/2010 07:02 AM, Belling, Thomas (NSN - DE/Munich) wrote:
> It is clear that the position of SDP attributes with respect to 
> m-lines in SDP allows to keep apart media-level and session-level 
> attributes and  to relate attributes to a media line.
> 
> But:
> 

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked] Check us out at
www.digium.com & www.asterisk.org
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 25 Aug 2010 17:18:02 +0200

Dear all,

although I am thankful for the many answers my email triggered, the
discussion unfortunately focused on my miss-formulated question 3 only.

I thus repeat my (corrected) questions:

2.      Would it be allowed according to RFC 4655 to assign any semantic
or syntactical meaning to such positions of SDP attributes?

3.      Can one expect that intermediates parsing SDP (without adding or
removing attributes) maintain the order of  attribute lines, or are
there known examples where the order is modified?

Cheers, Thomas

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Wed, 25 Aug 2010 23:21:21 +0800

Hi Thomas

Answering your 3rd Question..

I can think of a SIP B2BUA attempting to modify the SDP (i.e removing a
particular m line and adding its own SDP lines) when it is behaving in a
3PCC mode.

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Belling, Thomas (NSN - DE/Munich)
Sent: Wednesday, August 25, 2010 8:48 PM
To: [email-masked]
Subject: Re: [MMUSIC] Does order of SDP attributes have any
significance?

Dear all,

Cheers, Thomas

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 25 Aug 2010 19:47:00 +0200

Thanks Ranjit.

however, I was more interested in intermediates not performing any
semantical modifications to SDP (like adding or removing m-lines and
related attributes) but merely parsing it, e.g. to check if a SIP INVITE
is acceptable according to their media related policies.

The background is that I received comments that some such SIP parsers
might modify the order of session level attributes or attributes
relating to a single media line and I wanted to get a feeling if such a
behaviour is frequent and permissible from the SDP point of view. (see
also my first question)

Regards, Thomas

-----Original Message-----
From: ext Avasarala Ranjit-A20990 [mailto:[email-masked]] 
Sent: Wednesday, August 25, 2010 5:21 PM
To: Belling, Thomas (NSN - DE/Munich); [email-masked]
Subject: RE: [MMUSIC] Does order of SDP attributes have any
significance?

Hi Thomas

Regards
Ranjit

-----Original Message-----

Dear all,

Cheers, Thomas

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 25 Aug 2010 13:33:36 -0500

> behaviour is frequent and permissible from the SDP point of view. (see

SDP itself does not mandate any order for a= lines inside an m= block.
There may be some SDP extensions that do, however, if there are a= lines
that are dependent on previous a= lines. In general, though, I believe
that SDP parsers are supposed to look for particular *types* of a-lines
in a certain order, depending on which SDP extensions they support,
regardless of the order those a= lines appear in the m= block itself.
Certainly that would fit with the 'be tolerant in what you accept and
strict in what you send' philosophy.

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Thu, 26 Aug 2010 14:44:01 +0800

Hi Thomas

Ok. I have not come across any intermediate that merely parse the SDP,
unless it is UAS which if it does not understand a particular codec,
could send a 415 Media Unsupported response  

Regards
Ranjit

-----Original Message-----
From: Belling, Thomas (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Wednesday, August 25, 2010 11:17 PM
To: Avasarala Ranjit-A20990; [email-masked]
Subject: RE: [MMUSIC] Does order of SDP attributes have any
significance?

Thanks Ranjit.

Regards, Thomas

-----Original Message-----
From: ext Avasarala Ranjit-A20990 [mailto:[email-masked]]
Sent: Wednesday, August 25, 2010 5:21 PM
To: Belling, Thomas (NSN - DE/Munich); [email-masked]
Subject: RE: [MMUSIC] Does order of SDP attributes have any
significance?

Hi Thomas

Regards
Ranjit

-----Original Message-----

Dear all,

Cheers, Thomas