Subject: Re: [AVT] 3984bis - packetization mode

From: Tom Kristensen <[email-masked]>
Date: Wed, 2 Sep 2009 13:37:00 +0200

I agree. Several products out there already announce both
packetization mode 0 and 1. The fact that products just signal support
for mode 1 - and not bother adding a payload type for mode 0 - is
disappointing - at least if H.264 mode 1 is the only video codec
offered.

I'm not in favour of altering RFC3984bis to allow
"downgrading"/interpretation rules here.

-- Tom

2009/8/31 Gert Olsson <[email-masked]>:
> 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
>
> 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.
>
>>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
>
> 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.
>
>>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
>
> 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).  :-(
>
>>
>>
>>Roni
>>
>>> -----Original Message-----
>>> 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
>>> Subject: RE: [AVT] 3984bis - packetization mode
>>>
>>> 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
>>>
>>>
>>> Correct. But that is not a problem, is it?
>>>
>>> BR, YK
>>>
>>> > -----Original Message-----
>>> > 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
>>> >
>>> > > -----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
>>> > > Subject: Re: [AVT] 3984bis - packetization mode
>>> > >
>>> > > 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]>:
>>> > > > 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,
>>> > > >
>>> > > > 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
>>> > > >
>>> > > >
>>> > > >
>>> > > > 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
>>> > > >
>>> > > > _______________________________________________
>>> > > > 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/
>>> > > _______________________________________________
>>> > > Audio/Video Transport Working Group [email-masked]
>>> > > https://www.ietf.org/mailman/listinfo/avt
>>> >
>>> >
>>>
>>>
>>> _______________________________________________
>>> Audio/Video Transport Working Group
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/avt
>>
>>_______________________________________________
>>Audio/Video Transport Working Group
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/avt
>
>
> --
> 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
> _______________________________________________
> 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: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 3 Sep 2009 04:36:37 -0400

Gert, Tom,
You seem to be echoing the earlier concern noted by Roni:

"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 offerer will prefer
to establish a video connection with mode 0 if the other side supports
does not support mode 1"

If the sender is capable of sending only packetization mode 1 (i.e. must
fragment large NALUs, not merely prefers to), and the receiver is
capable of receiving only mode 0, then that session will be rejected
regardless of this proposal. So that scenario does not seem to raise any
real objection to the proposal. In what specific scenario do problems
arise with this proposal, and how would offering mode 0 and 1 as
separate payload types improve the situation?

BR,
Mo Zanaty

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tom Kristensen
Sent: Wednesday, September 02, 2009 7:37 AM
To: Gert Olsson
Cc: Randell Jesup; IETF AVT WG; Roni Even
Subject: Re: [AVT] 3984bis - packetization mode

-- Tom

---

From: Roni Even <[email-masked]>
Date: Thu, 03 Sep 2009 15:25:03 +0300

Hi,

I am not sure what you mean in the second paragraph when you say the session
will be rejected. If the answer is with mode 0 and a port is given, than a
session is established , so how is it rejected?
Roni Even

> From: Mo Zanaty (mzanaty) [mailto:[email-masked]]
> Sent: Thursday, September 03, 2009 11:37 AM
> To: Tom Kristensen; Gert Olsson
> Cc: Randell Jesup; IETF AVT WG; Roni Even; Chelliah Sivachelvan
> (chelliah); Ashish Goyal

---

From: Randell Jesup <[email-masked]>
Date: Sun, 06 Sep 2009 02:33:14 -0400

>session is established , so how is it rejected?

RFC 3984 requires that if the modes don't match, then the payloads don't
match (you match on profile-level-id (perhaps minus the level),
packetization-mode, and a third item that only applies to Mode 2)..
Effectively, a mode 0 response to a mode 1 only offer would be illegal,
since it wouldn't be matched up with the Mode 1 offer.

The option here would be to allow a mode 0 response to a mode 1 offer
(relax the matching rules to cover this) under the assumption that an
offerer who can process mode 1 can process mode 0. As mentioned by
others, it's theoretically possible, however, that a device might need
to send mode 1 (for example, they may be unable to control the NALU size
generated by the encoder, or might be packetizing a pre-encoded stream
with NALUs larger than the packet size).  In that case, a mode 1 offerer
might need to immediately end a call if they can't handle
sending/receiving it.

I agree that a mode 1 decoder will be fine decoding a mode 0 input
stream.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone)
[email-masked]

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 8 Sep 2009 11:32:52 -0400

I should have clarified this nuance. Under the existing draft, the
answerer could reject the session when it receives the offer with mode
1. Under the proposed change, the offerer could reject the session when
it receives the answer with mode 0. "Reject the session" refers to
SIP/SDP session signaling in general, not limited to setting the port to
zero in an answer, and depends on implementation-specific behavior --
e.g. allow one-way video in this case, re-invite without H.264,
re-invite without any video, reject the entire session/call, etc.

BR,
Mo Zanaty

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Thursday, September 03, 2009 8:25 AM
To: Mo Zanaty (mzanaty); 'Tom Kristensen'; 'Gert Olsson'
Cc: 'Randell Jesup'; 'IETF AVT WG'; Chelliah Sivachelvan (chelliah);
'Ashish Goyal'

Hi,

I am not sure what you mean in the second paragraph when you say the
session
will be rejected. If the answer is with mode 0 and a port is given, than
a
session is established , so how is it rejected?
Roni Even

> > units (which could be large) is an added complication to a given
mode
> 1
> > rejecting, include payloads for both 0 and 1 on all offers.  I'd
also
> be
> > Randell Jesup, Worldgate (developers of the Ojo videophone),
ex-Amiga
> OS

---

From: Roni Even <[email-masked]>
Date: Tue, 08 Sep 2009 19:09:05 +0300

Mo,
The offerer will need to do a re-invite in this case, which will require
another offer answer exchange. So it will be better to the offerer to offer
two payload types one with mode 0 and the other with mode 1 if he does not
care. Using the media capability draft it can offer mode 1 and say that he
is willing to get mode 0.
Roni Even

> Sent: Tuesday, September 08, 2009 6:33 PM
> To: Roni Even; Tom Kristensen; Gert Olsson
> Cc: Randell Jesup; IETF AVT WG; Chelliah Sivachelvan (chelliah); Ashish
> Goyal
> > > used in out-of-band cases).  I'll try to get that in the next
> couple
> > of
> > > days.
> > >
> > >>Ashish,
> > > Correct.  One m= line, MANY payload values (in theory a huge
> number,
> > if
> > > TCP/TLS).  This is part of why they say on answers you have to
> match
> > by
> > >>2. The offerer  may want to use packetization mode 1 and not 0.
> This
> > is
> > >
> > >>> There is really no ambiguity here - any decoder that supports
> mode
> > 1
> Behalf