Subject: [AVT] 3984bis - packetization mode

From: "Ashish Goyal" <[email-masked]>
Date: Tue, 18 Aug 2009 23:23:55 -0500

Based on the 3984 packetization modes and the packetization mode table
(table 3)  - any decoder which supports packetization mode  1 also would
inherently support packetization mode 0. 

Also section 6.2 says packetization mode 0 is mandatory. 

I would like to propose that any UA offering packetization mode 1 -
should be considered capable of supporting  packetization mode 0. So if
an offer contains packetization-mode 1- the answerer may answer with
packetization-mode 0 or skip packetization-mode in the answer. In this
case packetization mode 0 will be used for the call. 

Currently - it's a challenge for anyone who supports mode 1 - to
establish communication with mode 0 endpoints - since mode0 endpoints
which don't assume that mode 1 support also implies mode 0 and may
reject the offer. 

Ashish

---

From: Roni Even <[email-masked]>
Date: Wed, 19 Aug 2009 08:39:16 +0300

Hi,

I assume that you suggest to change the text in section  8.2.2

The parameters identifying a media format configuration for   H.264 are
"profile-level-id" and "packetization-mode", when    present.  These media
format configuration parameters (except  for the level part of
"profile-level-id") 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.

The above text mandates packetization mode symmetrical so an offer with
packetization-mode =1 must be answered with the same packetization mode.

Roni Even

As individual

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ashish
Goyal
Sent: Wednesday, August 19, 2009 7:24 AM
To: IETF AVT WG
Subject: [AVT] 3984bis - packetization mode

I would like to propose that any UA offering packetization mode 1 - should
be considered capable of supporting  packetization mode 0. So if an offer
contains packetization-mode 1- the answerer may answer with
packetization-mode 0 or skip packetization-mode in the answer. In this case
packetization mode 0 will be used for the call. 

Currently - it's a challenge for anyone who supports mode 1 - to establish
communication with mode 0 endpoints - since mode0 endpoints which don't
assume that mode 1 support also implies mode 0 and may reject the offer. 

Ashish

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 19 Aug 2009 10:05:59 +0300

A change to the text in 8.2.2 most likely will also require changes in other
places for consistency. 
 
Is this really needed? If the offer contains both SDP for mode 0 and mode 1,
then a mode 0 answerer can just pick the mode 0 SDP.
 
BR, YK

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni
Even
Sent: Wednesday, August 19, 2009 8:39 AM
To: 'Ashish Goyal'; 'IETF AVT WG'
Subject: Re: [AVT] 3984bis - packetization mode

Hi,

Roni Even

As individual

Ashish

---

From: Tom Kristensen <[email-masked]>
Date: Wed, 19 Aug 2009 09:18:33 +0200

I agree with YK on this issue. I'd rather not see a change of Section
8.2.2 and elsewhere in this bis draft.

It's true as Ashish states, so instead of just offering mode 1 add
mode 0 to your SDPs as well.

-- Tom

2009/8/19 Ye-Kui Wang <[email-masked]>:
> ________________________________
> (table 3)  – any decoder which supports packetization mode  1 also would
> I would like to propose that any UA offering packetization mode 1 – should
> contains packetization-mode 1– the answerer may answer with
> Currently – it’s a challenge for anyone who supports mode 1 – to establish
> communication with mode 0 endpoints – since mode0 endpoints which don’t
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>
>

-- 
# TANDBERG R&D
## http://www.tandberg.com
### http://folk.uio.no/tomkri/

---

From: Roni Even <[email-masked]>
Date: Wed, 19 Aug 2009 12:50:40 +0300

Hi,
I think this will mean that you have to have two payload type numbers one
with packetization mode=0 and the other with packetization mode=1 for each
configuration offered.
Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tom Kristensen
> Sent: Wednesday, August 19, 2009 10:19 AM
> To: Ye-Kui Wang
> Cc: Roni Even; IETF AVT WG
> should
> establish

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 19 Aug 2009 16:25:11 +0300

Correct. But that is not a problem, is it? 

BR, YK 

> From: Roni Even [mailto:[email-masked]] 
> Sent: Wednesday, August 19, 2009 12:51 PM
> To: 'Tom Kristensen'; 'Ye-Kui Wang'
> Cc: 'IETF AVT WG'
> Subject: RE: [AVT] 3984bis - packetization mode
> 
> Hi,
> I think this will mean that you have to have two payload type 
> numbers one with packetization mode=0 and the other with 
> packetization mode=1 for each configuration offered.
> Roni
> 
> > > A change to the text in 8.2.2 most likely will also 
> require changes
> > in other
> > > places for consistency.
> > >
> > > Is this really needed? If the offer contains both SDP for 
> mode 0 and
> > mode 1,
> > > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > > Of
> > Roni
> > > Even
> > > The parameters identifying a media format configuration 
> for   H.264
> > are
> > > "profile-level-id" and "packetization-mode", when    
> present.  These
> > media
> > > "profile-level-id") MUST be used    symmetrically; i.e., 
> the answerer
> > MUST
> > > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > > Of
> > Ashish
> > > Goyal
> > > be considered capable of supporting  packetization mode 
> 0. So if an
> > offer

---

From: "Ashish Goyal" <[email-masked]>
Date: Wed, 19 Aug 2009 22:05:09 -0500

That is an issue I am trying to avoid.  Multiple m lines - makes the
implementation non interoperable/most of the proxies, sbc's start
behaving weirdly. IMHO - we should figure out a way to fix this in the
bis - which would also help simplify implementations and interop.

This came up in a video vendors group where we are trying to use 3984bis
as a reference - but the implementers are finding practical issues in
following this section.  

There is really no ambiguity here - any decoder that supports mode 1
does support mode 0.  If you folks fundamentally agree with that - and
your concern is primarily around it's impact on the draft  - we  can
discuss offline on how to minimize impact to draft.

Ashish

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ye-Kui Wang
Sent: Wednesday, August 19, 2009 6:55 PM
To: 'Roni Even'; 'Tom Kristensen'
Cc: 'IETF AVT WG'
Subject: Re: [AVT] 3984bis - packetization mode

BR, YK

---

From: Roni Even <[email-masked]>
Date: Thu, 20 Aug 2009 07:59:00 +0300

Ashish,
This does  not require multiple m-lines.
The offer has one m-line with two payload type numbers which is well defined
and supported

I think there are some concerns.

1. The change is just for the private case of 1 and 0 and not to other
packetization mode.

2. The offerer  may want to use packetization mode 1 and not 0. This is not
a strong point since I would assume that the offerere will prefer to
establish a video connection with mode 0 if the other side supports does not
support mode 1

Roni

> From: Ashish Goyal [mailto:[email-masked]]
> Sent: Thursday, August 20, 2009 6:05 AM
> To: Ye-Kui Wang; Roni Even; Tom Kristensen
> Cc: IETF AVT WG
> > > > either maintain all   configuration parameters or remove the
> media
> > > format
> > > > (payload  type) completely, if one or more of the parameter
> values
> > > are not
> > > >  supported.
> > > >
> > > >
> > > >
> > > > The above text mandates packetization mode symmetrical so an
> offer
> > > with
> > > > packetization-mode =1 must be answered with the same
> packetization
> > > mode.
> > > >
> > > >
> > > >
> > > > Roni Even
> > > >
> > > > As individual
> > > >
> > > >
> > > >
> > > > (table 3)  - any decoder which supports packetization mode  1
> also
> > > would

---

From: Randell Jesup <[email-masked]>
Date: Thu, 20 Aug 2009 14:33:46 -0400

I'm finally back from vacation and unburied myself enough to find a few
minutes to catch up on AVT mail.  Sorry that I didn't get to send an
3984bis update before I left, since I didn't really agree with YK's last
set of changes (where he reverted a bunch of text about what level is
used in out-of-band cases).  I'll try to get that in the next couple of
days.

>The offer has one m-line with two payload type numbers which is well defined

Correct.  One m= line, MANY payload values (in theory a huge number, if
you include other orthogonal issues).  It help lead to "issues" for UDP
SIP (you have to break the requirement against fragmenting SIP packets
(which is somewhat breakable since the RFC also mandates that all
endpoints recieve fragmented SIP, for backwards compatibility), or use
TCP/TLS).  This is part of why they say on answers you have to match by
payloads by profile, packetization-mode and (for mode 2) one other
parameter.

>establish a video connection with mode 0 if the other side supports does not

There's also a practical aspect - some devices out there simply ignore
packetization FMTP parameters and always use 0 (explicitly or by
default).  So if you get an 'illegal' response that accepts mode 0 when
you offered only mode 1, you either need to kill the session, or knuckle
under and simply send mode 0.  Others may be smart enough to reject mode
1.

The proposal would be to make responding with mode 0 to a mode 1 request
legal.  The downside of that is it complicates the "matching" mentioned
above, where packetization-mode is part of the match.  You can do it;
you would just define that an offer of mode 1 is an implicit offer of
mode 0 with the same payload value and all other parameters.  The
downside is compatibility - a 'strict' 3984 answer implementation would
(as per above) reject the mode 1 payload, and a 3984bis implementation
(with this proposed mod) might accept a 3984 mode 1-only offer as mode
0, which the offerer might not expect (though per above, some endpoints
do this today because they ignore packetization-mode).

You could add parameters to indicate this new negotiation style (offer
mode 0 but say you really prefer 1), but you may end up limiting
yourself to mode 0 if talking to a 3984 implentations, when both sides
can do mode 1 and would prefer it.

My small preference (given a non-0 number of endpoints that require mode
0) is towards allowing downgrade to mode 0.  For maximum compatibility,
if you want to avoid possibility of a strict 3984 implementation
rejecting, include payloads for both 0 and 1 on all offers.  I'd also be
fine with leaving it alone.

Yet another case where lack of real capability declaration in SDP bites
us.  (like AVP/AVPF/SAVP/SAVPF, etc).  :-(

-- 
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: "Gert Olsson" <[email-masked]>
Date: Mon, 31 Aug 2009 10:45:17 +0200

Hi,
Receiving-wise, packetization mode 0 is a subset of 1; you get 0 for
free if you support 1.
Sending-wise, this is not the case; not being allowed to fragment NAL
units (which could be large) is an added complication to a given mode 1
implementation. 
Separe payload type numbers, no special 'downgrading rules', would be
the best in my view.

br
/GO
__________________________________________________________________|
Gert Olsson   /  phone: +46 10 7154604   /  e-mail:
[email-masked]
ST-Ericsson, Product Group Mobile Platforms, SE-221 83  Lund, Sweden

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Randell Jesup
Sent: den 20 augusti 2009 20:34
To: Roni Even
Cc: 'IETF AVT WG'
Subject: Re: [AVT] 3984bis - packetization mode

>The offer has one m-line with two payload type numbers which is well 
>defined and supported

>2. The offerer  may want to use packetization mode 1 and not 0. This is

>not a strong point since I would assume that the offerere will prefer 
>to establish a video connection with mode 0 if the other side supports 
>does not support mode 1

>> behaving weirdly. IMHO - we should figure out a way to fix this in 
>> the bis - which would also help simplify implementations and interop.
>> 
>> This came up in a video vendors group where we are trying to use 
>> 3984bis as a reference - but the implementers are finding practical 
>> issues in following this section.
>> 
>> does support mode 0.  If you folks fundamentally agree with that - 
>> and your concern is primarily around it's impact on the draft  - we  
>> can discuss offline on how to minimize impact to draft.
>> 
>> Ashish
>> 

>> > > It's true as Ashish states, so instead of just offering mode 1 
>> > > add mode 0 to your SDPs as well.
>> > >
>> > > -- Tom
>> > >
>> > > > Based on the 3984 packetization modes and the packetization 
>> > > > mode
>> > > table
>> > > > packetization-mode 0 or skip packetization-mode in the answer. 
>> > > > In
>> > > this case
>> > > > communication with mode 0 endpoints - since mode0 endpoints 
>> > > > which
>> > > don't
>> > > > assume that mode 1 support also implies mode 0 and may reject 
>> > > > the
>> > > offer.
>> > > >
>> > > >
>> > > >
>> > > > Ashish
>> > > >
>> > > > Audio/Video Transport Working Group [email-masked] 
>> > > Audio/Video Transport Working Group [email-masked] 

--
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)
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt