Subject: [AVT] SDP Negotiation based on Profile-Level-Id

From: Tom Taylor <[email-masked]>
Date: Wed, 03 Sep 2008 02:30:30 +0200

For some reason this message got bounced. I am forwarding it to the list, copy 
the sender.

Tom Taylor
> 
> ------------------------------------------------------------------------
> 
> Subject:
> SDP Negotiation based on Profile-Level-Id
> From:
> "sunil.kumar" <[email-masked]>
> Date:
> Tue, 02 Sep 2008 17:41:24 +0530
> To:
> [email-masked]
> 
> To:
> [email-masked]
> 
> 
> Hi All,
> 
> When we tried to make Video call from Polycom to Eyebeam (and vice 
> versa), video negotiation got failed.
> Eyebeam supports H.264(Profile Level Id = 42e015).
> Polycom supports H.264(Profile Level Id = 42a014).
> 
> As per RFC 3984(Page 38)
> ****************************************************
>                   If the profile-level-id parameter is used for
>                   capability exchange or session setup procedure,
>                   it indicates the profile that the codec
>                   supports and the highest level
>                   supported for the signaled profile.
> ****************************************************
> Call from Polycom to Eyebeam:
> Eyebeam supports Level 2.1(42e015) and it should be able to handle 
> 2.0(42a014) level.But it rejects the Video Offer.
> 
> Could any one help us to understand to do SDP Codec negotiation based on 
> the Profile-Level-Id?
> 
> Regards
> sunil kumar

-------- Original Message --------
Subject: Uncaught bounce notification
Date: Tue, 02 Sep 2008 05:12:29 -0700
From: [email-masked]
To: [email-masked]

The attached message was received as a bounce, but either the bounce
format was not recognized, or no member addresses could be extracted
from it.  This mailing list has been configured to send all
unrecognized bounce messages to the list administrator(s).

For more information see:
https://www.ietf.org/mailman/admin/avt/bounce

Subject: SDP Negotiation based on Profile-Level-Id
From: "sunil.kumar" <[email-masked]>
To: [email-masked]
Date: Tue, 02 Sep 2008 17:41:24 +0530

Hi All,

When we tried to make Video call from Polycom to Eyebeam (and vice 
versa), video negotiation got failed.
Eyebeam supports H.264(Profile Level Id = 42e015).
Polycom supports H.264(Profile Level Id = 42a014).

As per RFC 3984(Page 38)
****************************************************
                   If the profile-level-id parameter is used for
                   capability exchange or session setup procedure,
                   it indicates the profile that the codec
                   supports and the highest level
                   supported for the signaled profile.
****************************************************
Call from Polycom to Eyebeam:
Eyebeam supports Level 2.1(42e015) and it should be able to handle 
2.0(42a014) level.But it rejects the Video Offer.

Could any one help us to understand to do SDP Codec negotiation based on 
the Profile-Level-Id?

Regards
sunil kumar

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Roni Even" <[email-masked]>
Date: Wed, 3 Sep 2008 08:23:03 +0300

Hi,
You are right with the text you gave but this had to do with the text in
section 8.2.2 of RFC 3984

"The parameters identifying a media format configuration for H.264 are
"profile-level-id", "packetization-mode", and, if required by
"packetization-mode", "sprop-deint-buf-req".  These three parameters MUST be
used symmetrically; i.e., the answerer MUST either maintain all
configuration parameters or remove the media format (payload type)
completely, if one or more of the parameter values are not supported."

This topic was discussed and the 3984bis draft will fix it to recognize that
the level part does not have to be symmetrical.

Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom
Taylor
Sent: Wednesday, September 03, 2008 3:31 AM
To: IETF AVT WG
Cc: sunil.kumar
Subject: [AVT] SDP Negotiation based on Profile-Level-Id

For some reason this message got bounced. I am forwarding it to the list,
copy the sender.

Tom Taylor
> Could any one help us to understand to do SDP Codec negotiation based 
> on the Profile-Level-Id?
> 
> Regards
> sunil kumar

-------- Original Message --------
Subject: Uncaught bounce notification
Date: Tue, 02 Sep 2008 05:12:29 -0700
From: [email-masked]
To: [email-masked]

The attached message was received as a bounce, but either the bounce format
was not recognized, or no member addresses could be extracted from it.  This
mailing list has been configured to send all unrecognized bounce messages to
the list administrator(s).

---

From: Randell Jesup <[email-masked]>
Date: Thu, 04 Sep 2008 16:08:37 -0400

>completely, if one or more of the parameter values are not supported."

Correct, though there was a "clarification" posted (by Magnus and others)
after 3984 that said that the level part could be downgraded in a response.
However, in trying to actually write that into 3984bis, it's clear that
the "clarification" has major problems in practice without additional
guidance and mechanisms.  (For example, level downgrade fails or is very
painful when used with the (recommended) sprop-parameter-sets parameter.)

>the level part does not have to be symmetrical.

Or rather, we still hope the 3984bis draft will find a way to fix that.
So far, it does not have a usable overall fix (IMHO).

>Sunil writes:

Another major problem is that pretty much NO ONE properly and fully
implements RFC 3984.

In the case of Polycom to Eyebeam, Eyebeam *should* be able to realize it
could respond with level 2.0 - however, the offer also specifies "a0" for
constraints, while Eyebeam naturally supports "e0".  Since polycom asked
for less constraints ("constraint bit 1" isn't set), it's possible that
Eyebeam can't handle it (can't use 42a014, though it should be able to
handle 42e014), and so rejects it.  You're never allowed to change
constraints in the answer, even in 3984bis.

The upshot of all this is that, once again, for wide compatibility a device
has to offer almost every possible combination of settings in the offer if
you want to follow 3984.  For example, Polycom *could* offer:
m=video 2345 RTP/AVP 90 91 92 93 94 95
...
a=fmtp:90 profile-level-id=42a014;packetization-mode=0;...
a=fmtp:91 profile-level-id=42a014;packetization-mode=1;...
a=fmtp:92 profile-level-id=42e014;packetization-mode=0;...
a=fmtp:93 profile-level-id=42e014;packetization-mode=1;...
a=fmtp:94 profile-level-id=428014;packetization-mode=0;...
a=fmtp:95 profile-level-id=428014;packetization-mode=1;...

And if you include sprop-parameter-sets, you have to include parameter-sets
for every possible level downgrade as well in the response.  If you don't
allow downgrade, you have to include separate payloads for each possible
level downgrade (times each possible packetization-mode).

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: "Roni Even" <[email-masked]>
Date: Thu, 4 Sep 2008 23:35:15 +0300

Randell,
What do you mean by "For example, level downgrade fails or is very
painful when used with the (recommended) sprop-parameter-sets parameter"

Roni

-----Original Message-----
From: Randell Jesup [mailto:[email-masked]] 
Sent: Thursday, September 04, 2008 11:09 PM
To: Roni Even
Cc: 'Tom Taylor'; 'IETF AVT WG'; 'sunil.kumar'
Subject: Re: [AVT] SDP Negotiation based on Profile-Level-Id

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS
team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the
weapons
provided for defence against real, pretended, or imaginary dangers from
abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Randell Jesup <[email-masked]>
Date: Fri, 05 Sep 2008 11:50:51 -0400

>painful when used with the (recommended) sprop-parameter-sets parameter"

Witness the discussions at IETF 70(?) in Philadelphia on the topic.

Note that parameter sets include a copy of the profile-level-id values,
so you have to use a parameter set that matches the profile-level-id
agreed to (or one you know the answerer can decode, which means a lower
level with the same constraints).

Without sprop-parameter-sets, it's not too hard (see the example I gave -
if you want to handle an answer with different constraints it causes a
small payload explosion, but not too bad).  You send parameter sets
in-band, and can choose them to match the result of negotiation.  This
works, with some downsides especially on packet loss at stream start, and
wastes some bandwidth (especially in mode 0).

With sprop-parameter-sets, in order to have a level-downgrade in the
response, you have problems.  For example, the answerer is *required* to
include the parameter sets from the offer in the answer ("an answerer MUST
maintain all parameter sets received in the offer in its answer").  The
answer can add parameter sets (usually), so it could *add* a parameter set
for the lower level in the response, and then send data using that
parameter set.  However, unless the offerer had included a parameter set
for the exact level (or lower) that the answerer selected, the offerer
can't send any video to the answerer (since it has to use a parameter set
from the original offer) - or it could send in-band parameter sets (that
don't conflict with the parameter sets it already offered), which steps on
the whole reason for handling them in the negotiation.  The alternative is
for the offerer to include parameter sets for *every* possible level
downgrade (ugh), or include one or two lower-level ones, and on a level
downgrade drop the first one lower than the answer.

It gets even more complex with the "matching" rules for payloads.

Ugh.

Of course, no one appears to implement sprop-parameter-sets per the spec
anyways.  (We come close, but with a bunch of kludges to try to get it to
work with people who ignore sprop-parameter-sets (almost everyone) or get
it wrong.)  And we don't handle level-downgrade for sprop-parameter-sets.

---

From: "Roni Even" <[email-masked]>
Date: Sat, 6 Sep 2008 01:31:59 +0300

Randell,
I think that sprop-parameter-sets include the parameter sets that will be
used by the encoder and not what it can receive, sprop parameters are not
used for negotiation. The only requirement is that the receiver will have
the parameter sets before they are used. It is true that the parameter-add
parameter got me confused and I am not sure why it is there in the first
place. I think that the only limitation should be that the added parameter
sets can not contradict the mode (profile-level and other receive
parameters) that the offer can receive.
Since we are adding text about in-band parameter sets than we probably need
to clarify the parameter-add usage.
I think that we need to clarify that if the offer offers for example level 3
with parameter sets for level 3 and the answer can only receive 2.1 than the
offerer needs to send 2.1 and MUST provide relevant parameter sets either as
sprop-parameter sets or inband so that they should be available to the
receiver before they are used.

Some text from RFC 3984

Section 8
Some parameters provide a receiver with the properties of the stream
   that will be sent.  The name of all these parameters starts with
   "sprop" for stream properties.  Some of these "sprop" parameters are
   limited by other payload or codec configuration parameters.  For
   example, the sprop-parameter-sets parameter is constrained by the
   profile-level-id parameter.  The media sender selects all "sprop"
   parameters rather than the receiver.  This uncommon characteristic of
   the "sprop" parameters may not be compatible with some signaling
   protocol concepts, in which case the use of these parameters SHOULD
   be avoided.

And

sprop-parameter-sets:
                        This parameter MAY be used to convey
                        any sequence and picture parameter set NAL
                        units (herein referred to as the initial
                        parameter set NAL units) that MUST precede any
                        other NAL units in decoding order.  The
                        parameter MUST NOT be used to indicate codec
                        capability in any capability exchange
                        procedure.

I noticed the text

"The "sprop-parameter-sets" parameter is used as described above.
      In addition, an answerer MUST maintain all parameter sets received
      in the offer in its answer.  Depending on the value of the
      "parameter-add" parameter, different rules apply: If "parameter-
      add" is false (0), the answer MUST NOT add any additional
      parameter sets.  If "parameter-add" is true (1), the answerer, in
      its answer, MAY add additional parameter sets to the "sprop-
      parameter-sets" parameter.  The answerer MUST also, independent of
      the value of "parameter-add", accept to receive a video stream
      using the sprop-parameter-sets it declared in the answer.

         Informative note: care must be taken when parameter sets are
         added not to cause overwriting of already transmitted parameter
         sets by using conflicting parameter set identifiers."

But after you see

Furthermore, the following considerations are necessary:

   o  Parameters used for declaring receiver capabilities are in general
      downgradable; i.e., they express the upper limit for a sender's
      possible behavior.  Thus a sender MAY select to set its encoder
      using only lower/lesser or equal values of these parameters.
      "sprop-parameter-sets" MUST NOT be used in a sender's declaration
      of its capabilities, as the limits of the values that are carried
      inside the parameter sets are implicit with the profile and level
      used.

The text in example 8.3

   As the Offer/Answer negotiation covers both sending and receiving
   streams, an offer indicates the exact parameters for what the offerer
   is willing to receive, whereas the answer indicates the same for what
   the answerer accepts to receive.  In this case the offerer declared
   that it is willing to receive payload type 98.  The answerer accepts
   this by declaring a equivalent payload type 97; i.e., it has
   identical values for the three parameters "profile-level-id",
   packetization-mode, and "sprop-deint-buf-req".  This has the
   following implications for both the offerer and the answerer
   concerning the parameters that declare properties.  The offerer
   initially declared a certain value of the "sprop-parameter-sets" in
   the payload definition for PT=98.  However, as the answerer accepted
   this as PT=97, the values of "sprop-parameter-sets" in PT=98 must now
   be used instead when the offerer sends PT=97.  Similarly, when the
   answerer sends PT=98 to the offerer, it has to use the properties
   parameters it declared in PT=97.

Demonstrate that the parameter sets are for the send side and not the
receive side.

Roni

-----Original Message-----
From: Randell Jesup [mailto:[email-masked]] 
Sent: Friday, September 05, 2008 6:51 PM
To: Roni Even
Cc: 'sunil.kumar'; 'Tom Taylor'; 'IETF AVT WG'
Subject: Re: [AVT] SDP Negotiation based on Profile-Level-Id

Ugh.

---

From: "Roni Even" <[email-masked]>
Date: Sat, 6 Sep 2008 01:37:16 +0300

Randell,

Some text from RFC 3984

Section 8

And

sprop-parameter-sets:

I noticed the text

But after you see

The text in example 8.3

Roni

-----Original Message-----
From: Randell Jesup [mailto:[email-masked]] 
Sent: Friday, September 05, 2008 6:51 PM
To: Roni Even
Cc: 'sunil.kumar'; 'Tom Taylor'; 'IETF AVT WG'
Subject: Re: [AVT] SDP Negotiation based on Profile-Level-Id

Ugh.

---

From: Randell Jesup <[email-masked]>
Date: Fri, 05 Sep 2008 22:39:48 -0400

"Roni Even" <[email-masked]> writes:

>used for negotiation.

sprop-parameter-sets are what will be used to send (not receive) - but that
does not mean they are not 'negotiated'.  RFC 3984 specifies (in the
Offer-Answer section) that an answer must include all parameter sets from
the offer (though I'm really confused as to why this is - I see no reason
for it), and can (optionally, unless sprop-parameter-add is 0) add sets.
Now, this may have been a bad idea, but that's what the spec says.

> The only requirement is that the receiver will have
>the parameter sets before they are used.

If that's a requirement, it can only be guaranteed via SDP (reliable
out-of-band); in-band isn't reliable (normally).  

>It is true that the parameter-add parameter got me confused and I am not
>sure why it is there in the first place. I think that the only limitation
>should be that the added parameter sets can not contradict the mode
>(profile-level and other receive parameters) that the offer can receive.

Parameter-add is there (I assume) to keep an answerer from using parameter
sets (and values in them) that the offerer can't support, perhaps for fixed
function hardware devices.  I agree it's odd.

Even so, there really aren't restrictions on the parameter sets in the
answer (explicitly - the restrictions are implicit).

>to clarify the parameter-add usage.

Yes.  It would help to know *why* it's there, and for what use-case.
Earlier versions of our phone specified it, because we weren't ready to
parse SDP parameter sets other than the one we used normally, but I doubt
that was the intended usage.

>receiver before they are used.

That's similar to what I was saying: the offerer must either provide a
number of parameter sets at different levels (down to 1.0), or it has to
transmit them in-band (which violates the reason for sending them
out-of-band in the first place, and puts you back in the unreliable setting
of parameters), or you have to do a re-INVITE (or equivalent).

>         sets by using conflicting parameter set identifiers."

Right - that last part is part of the description of how
sprop-parameter-sets works in offer/answer (not all uses of SDP are
offer-answer). 

>   parameters it declared in PT=97.

Right.  Note that all this payload matching, etc is a royal pain, but there
are logical reasons behind it based on the very limited way in which SDP
and offer-answer work (which the cap-negotiation stuff in mmusic is trying
to solve, but that will add far more complexity...)

>Demonstrate that the parameter sets are for the send side and not the

Right, we all know that.  That's exactly part of the problem (and they're
sender-side parameters for good reasons).  If the answer downgrades level
(which is supposed to be allowed, and there's a good reason to allow), then
the offerer is in a very tough place if it didn't include a wide range of
parameter sets in the offer.  It can't send level 3 (from the parameter set
it included in the offer) to a 2.1 partner, and it can't guarantee any
in-band parameter set it sends will be received.

---

From: "Roni Even" <[email-masked]>
Date: Sat, 6 Sep 2008 08:18:44 +0300

Randell,

On the following assumption - 
"Parameter-add is there (I assume) to keep an answerer from using parameter
sets (and values in them) that the offerer can't support, perhaps for fixed
function hardware devices.  I agree it's odd."

This will make the decoder no compliant since the lower level mode is
included in the higher level one and therefore the decoder must be able to
support it.

I intend to clarify that in the 3984bis draft and take away this limitation
on based on parameter add - I am looking for input from the original authors
about why it is there in the first place.

As for inband - my intention is to add the text from H.241 about IDR refresh
point for the use case of video switching MCU as specified in the topology
draft. The issue of reliability is addressed there by suggesting to use some
mechanisms like repeating the sending of the parameter sets.

Roni Even

---

From: <[email-masked]>
Date: Sat, 6 Sep 2008 09:45:49 +0300

Just to point out that, in Dublin, the following changes in
draft-wang-avt-rfc3984bis-01.txt and summarized in the present slides
were all agreed. That does not necessarily mean we cannot further change
these, but it seems to me that the discussions in this thread are not
based on the latest status. 

- Level downgrade: If a level is offered, any lower level of the same
profile is automatically offered, including level 1b.

- Removed the restriction that sprop-parameter_sets in an SDP answer
shall be equal or a superset of that in the offer. 
-- It seems to be a clear mistake in RFC 3984, because the restriction
seriously limits separate encoding optimizations in the two sides, and
it basically disallows level downgrade
-- However, this change affects backward compatibility with RFC 3984

- Removed parameter-add
-- Affect backward compatibility with RFC 3984 for implementations using
this parameter with value 0 (the default value with the absence is 1)
-- But on the other hand, there seemed to be reason to have this if
above regarding sprop-parameter_sets is agreed. 

BR, YK

>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of ext Randell Jesup
>Sent: 06 September, 2008 05:40
>To: Roni Even
>>>>This topic was discussed and the 3984bis draft will fix it
>to recognize
>>>that

---

From: Randell Jesup <[email-masked]>
Date: Mon, 08 Sep 2008 01:12:23 -0400

>profile is automatically offered, including level 1b.

Ok, that means that the "constraints" section can change (but only in
one very specific case).  No other constraint changes are allowed.

>it basically disallows level downgrade

This is factually incorrect, though I agree with the sentiment.  Just
because the answer has to be a superset of the offer doesn't in any way
limit encoding optimizations.  The answer can add whatever parameter sets
it wants (within the profile-level-id constraints), then use those when
encoding.  Just because the answer has parameter sets copied from the offer
doesn't affect this.

That said, being forced to include them seems silly.  I'm fine with this
change.

>-- However, this change affects backward compatibility with RFC 3984

I doubt that this will have any practical effect, given that these are
"send" parameters.

>above regarding sprop-parameter_sets is agreed. 

Per other email, we need to find out *why* these aspects of parameter set
negotiation were included.

---

From: <[email-masked]>
Date: Mon, 8 Sep 2008 09:32:53 +0300

Randell,

Good that you agreed with these changes. 

>negotiation were included.

Right - but as long as nobody from the RFC 3984 author list and anyone
else knows the original reason say anything, we have to make the changes
based on our own understanding. My guess of having parameter-add was
because of and added after the mistaken restriction on
sprop-parameter-sets - to mor or less allow for more space for encoding
optimization. However, if that mistaken restriction itself is removed,
then there is no reason at all to have this parameter. Anyway, this is
just my guess. Please speak up if anyone knows the real reason. Unless
there is a good reason to keep the parameter, I think we should go ahead
with the bis draft with this parameter removed. 

BR, YK

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 09 Sep 2008 10:33:16 +0200

> with the bis draft with this parameter removed. 

I can't remember, but I would think because we where not fully 
understanding all the implications of this. I am not sure that I 
understand all the implications of this either. The offer/answer 
procedure was mostly mine and a real bitch to try to write. I clearly 
didn't understand the codec and the implications of the parameter well 
enough. I also think I didn't got all the usages right.

We will need to try to fix this. However, offer/answer is making this 
problematic because the fact we are trying to guess what the answerer is 
going to say and provide parameter sets that match that guess. When you 
guess wrong, you have no alternative other than to go inband, or do a 
update of them to match the answer.

When consider how to write the text remember the following. The text 
needs to work for

Offer/answer unicast
   - Simple point to point with one or more SSRC per side
   - Multi-point with confernece focus

Offer/answer multicast

And for these consider all the three directionalities, sendonly, 
recvonly and sendrecv.

Then we also needs parameters that work for declaration in SSM or ASM or 
RTSP controlled streaming.

I think one of the problems are that we aren't providing enough 
differentiation between the cases for certain functionality. One need to 
be able to express how one really are providing the parameter sets or 
other sprop parameters in these different cases.

A more practical detail regarding parameter-sets. I think we need to 
consider if they should be bound to SSRCs. The reason is that if one has 
multiple SSRCs at the side one is declaring or offer/answering for one 
need to express that the different decoder instances for each stream 
needs to run on different sets. Determine which is which based on trying 
them seems error prone.

Regarding the backwards compatibility isssue. For offer/answer I would 
simply add a new parameter to indicate that the answer should use the 
alternative definition provided in new parameter names. I wonder how 
much we need to change for the declarative stuff, but we might have to 
do both old and new parameters.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: <[email-masked]>
Date: Tue, 9 Sep 2008 13:21:49 +0300

>update of them to match the answer.

Right. 

>   - Simple point to point with one or more SSRC per side

Could you give examples when you would use more than one SSRC by one
side in a point-to-point topology?

>other sprop parameters in these different cases.

Exactly - providing separate text for each of the different cases would
make things much clearer. In the latest draft of 3984bis we are working
on, a step towards this direction has already been made. 

>needs to run on different sets. Determine which is which based 

As discussed in another email in the same thread, you cannot do
out-of-band parameter sets transport in during-session source switching
cases unless the value space of parameter set ID is pre-allocated for
different sources (by the application). However, if we bound
sprop-parameter-sets to SSRC, it then should be possible to do
out-of-band parameter sets transport in any topology. I would like to
have this if nobody objects. 

>do both old and new parameters.

Sorry I don't understand this. Could you clarify a bit more? For
example, what are "new parameter names"? Are you suggesting a solution
that would make changes really backwards compatible to RFC3984, or make
them as backwards compatible as possible?

BR, YK

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 09 Sep 2008 13:39:11 +0200

> side in a point-to-point topology?

Speaker and document camera is one example. The point is that we can't 
limit the RTP model that allows multiple SSRCs from any sender peer.

>>   - Multi-point with confernece focus

Another is the conference focus that doesn't mix video. Then the focus 
will send over unicast one stream per other participant, each with there 
own encoder and different parameter sets.

> have this if nobody objects. 

Yes, there is a difference between how a conference focus work, but for 
a switching or simply forwarding MCU that preserves SSRC this will work.

> them as backwards compatible as possible?

I suggest that we might need to create new parameters to fulfill our 
requirements. The changes to existing parameters are such that the loss 
of backwards compatibility isn't acceptable. Instead one have one new 
parameter with the correct sematics and functionality. For certain cases 
one can also use the existing ones for backwards compatibility.

If one simply tries to determine if the peer(s) support the update 
specification one can add a new parameter for this, and require the 
answerer to echo it back. If it isn't echoed back then the peer doesn't 
support the new parameters.

Please note that the above are orthogonal and can be combined.

Cheers

Magnus Westerlund

---

From: <[email-masked]>
Date: Tue, 9 Sep 2008 15:05:58 +0300

Thanks for the clarifications. 

On the point-to-point  with multiple SSRCs case, my understanding to your example is that there are two completely independent video streams transported in different RTP streams. I am not sure this works without any addition to somewhere not in the payload spec, e.g. in a generic SDP spec.

Questions: 
- I guess separate RTCP processes would be used, However, will one or two RTP sessions be used for the two RTP streams?
- When an offerer offers two such video streams, how does the answerer know that both are intended to be received and played back simultaneously? Does SDP or any SPD extension has this kind of grouping indication to tell this?

BR, YK 

>From: ext Magnus Westerlund [mailto:[email-masked]] 
>Sent: 09 September, 2008 14:39
>To: Wang Ye-Kui (Nokia-NRC/Tampere)
>Cc: [email-masked]; [email-masked]; 
>[email-masked]; [email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 09 Sep 2008 14:20:06 +0200

> On the point-to-point  with multiple SSRCs case, my understanding to your example is that there are two completely independent video streams transported in different RTP streams. I am not sure this…

No, this is standard RTP behavior. A end-point can simple use more than 
one SSRC within an RTP session to send more than on stream. The document 
camera and main speaker cam is usually realized using two RTP streams so 
it was actually a bad case. The conference focus use case is one that is 
much easier to understand where several SSRCs are being sent from the 
same source IP address and UDP port.

> - I guess separate RTCP processes would be used, However, will one or two RTP sessions be used for the two RTP streams?

For each SSRC you need to run a RTCP related information collection and 
sending the relevant report.

> - When an offerer offers two such video streams, how does the answerer know that both are intended to be received and played back simultaneously? Does SDP or any SPD extension has this kind of grou…

This is only done implicit. All streams sent in an RTP session needs to 
be dealt with. How is always a difficult question where application 
context helps quite a lot.

Cheers

Magnus Westerlund

---

From: <[email-masked]>
Date: Wed, 10 Sep 2008 09:45:14 +0300

>   What is the use of profile_idc in profile-level-id ? , If sender A 
>and Receiver B has a different profile_idc in profile-level-id ,What 
>will happen ?

profile_idc is part of the configurtaion parameters that must be kept
intact in an answer to an offer. In your example, the receiver has to
reject the offer. 

> And what is the relation between Profile_idc and Profile_IOP in 
>profile-level-Id ?

I suggest that you read the H.264/AVC spec itself to get the exact
answer. My summary: the bits Profile_IOP indicate other profile_idc
values than the one in profile-level-id that could be used. When
level_1b is involved for some profiles, one of the bits in Profile_IOP,
together with level_idc, indicates the level.

>  And What is the Importance of  Profile_idc and profile_IOP  in 
>profile-level-Id  in SDP negotiation ?

Again, they are part of the configurtaion parameters. See RFC 3984 or
draft-wang-avt-rfc3984bis-01.txt for more details.

BR, YK