Subject: [AVT] Moving draft-marjou-behave-app-rtp-keepalive to AVT

From: Colin Perkins <[email-masked]>
Date: Fri, 1 Jun 2007 18:15:23 +0100

There has been some private discussion on adopting the draft on  
Application Mechanisms for maintaining alive NAT mappings associated  
with RTP flows (draft-marjou-behave-app-rtp-keepalive-01.txt) as an  
AVT working group draft. This has previously been discussed in AVT,  
BEHAVE and MMUSIC. Opinions on whether this draft should become a  
working group draft, and on the appropriate home for it, are  
solicited by 8 June 2007.

Colin (as AVT co-chair)

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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Jun 2007 11:09:16 -0700

> solicited by 8 June 2007.

We need a document that consolidates NAT keepalive mechanisms for
UDP-based protocols, most notably RTP (and, to a lesser extent,
SIP).  Currently this is spread in various documents and there
is no consolidated guidance to implementtors on the strength
or weakness of various approaches.  Section 4 of Xavier's 
document shows the current state of the art -- 7 different
keepalive techniques are in various levels of active use.

Most of the keepalive techniques apply to RTP, and thus AVT seems
the best home.  There are a few exceptions which don't fit into
AVT, such as the keepalive technique used by SIP Outbound 
(draft-ietf-sip-outbound), but I don't see the exceptions as
significant enough to resist making this an AVT WG item.  If we 
had an "RAIWG" (akin to TSVWG), it might fit best there, but we 
don't have one.  It doesn't quite fit into BEHAVE, as NATs only
care to see a UDP packet is occasionally sent to the peer and 
NATs don't care what sort of UDP packet is sent; however, the
receiving peer may very much care if it's a STUN packet, a
0-byte packet, or the 5 other types of packets described in
Xavier's document.

I support adding a milestone to AVT for keepalives, and adopting 
that document to meet that milestone.

-d

---

From: Lars Eggert <[email-masked]>
Date: Mon, 4 Jun 2007 10:38:39 +0300

On 2007-6-1, at 21:09, ext Dan Wing wrote:
> or weakness of various approaches.

I'm wondering if it'd make sense to add this guidance as a section in  
http://tools.ietf.org/html/draft-ietf-tsvwg-udp-guidelines?

Lars

---

From: Dave Singer <[email-masked]>
Date: Mon, 4 Jun 2007 09:19:15 -0700

Hi

we have a need to group together two media streams, in the style of RFC
3388 <http://www.ietf.org/rfc/rfc3388.txt> but we're unsure whether an
existing group type is suitable or not, and if it's not, we'd like to
agree on a new one, and document it (presumably in an RFC).

What we have is a normal media stream, and a separate 'repair' or
'entry' stream, that can be used when tuning in, or after loss, but is
otherwise un-needed.  An example might be a video stream with a low
I-frame interval (say every 15 seconds), with a repair stream which has
only I-frames that are equivalent to the time-parallel non-I frame, at a
frequency of say 1 per second.

It's not clear to us whether this is "one media flow" in the sense of
FID, or not.  The example offers AMR and GSM audio, which are
alternatives, and DTMF tones along with audio, which are supplementary
to each other.  Perhaps we fall afoul of this restriction:

"An application that encodes the same media using different codecs
simultaneously MUST NOT use FID to group those media lines."

or this one, for layered encoding:

"FID MUST NOT be used to group "m" lines that do not represent the same
information."  (Though how DTMF tones and their associated audio pass
this test is not clear).

Nor is it clear that the FEC group of RFC 4756 is right, either.  For a
start, we may wish to use this new ID in combination with FEC, and
secondly this tune-in stream has different characteristics.  For
example, one can typically ignore all FEC and (as long as there are no
errors) decode the stream correctly.  Ignoring the tune-in stream
entirely may mean that you will never find a tune-in point, making the
normal stream useless.

So, can we use FID for associating a repair stream with its base (we tag
the streams so we know which is which, of course)?

p.s. RFC 4756 claims in the IANA section that the FEC group is 
registered under SDP characteristics, but actually I can find no 
registry anywhere in IANA of group types.

-- 
David Singer
Apple/QuickTime

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 5 Jun 2007 10:03:31 +0300

Dave,
For layered encoding there is a proposal for a new grouping attribute in
http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.tx
t

I looked at RFC3388 and I think that FID is not the answer to your
requirement as you mentioned

To me it looks like what you are looking for is a way to specify
alternate offers. If this is the case I have similar requirements and
would be happy to support such work.

You also need a way to give semantics to the "repair" stream, this can
be done based on the content attribute from RFC 4796 or using a
dependency attribute see in Schierl's draft. The mid tag is not enough
for the receiver to know what you meant by this offer and which stream
is the repair.

Here is an example for a solution using a new Alternatives grouping
attribute and giving semantics to the repair stream 

By using the grouping attribute in the offer you can know if the
answerer understood the grouping since if he does not than he will send
an answer with no a=group

v=0 
o=bob 280744730 28977631 IN IP4 host.example.com 
s= 
t=0 0 

a=group:ALTS 1 2 
a=group:ALTS 1 3 

m=audio 6886 RTP/AVP 0 
c=IN IP6 2001:0600::1 
a=mid:1 

m=video 9000 RTP/AVP 100
c=IN IP4 192.0.2.2 
a=rtpmap:100 H263-1998 
a=mid:2 

m=video 9002 RTP/AVP 101 
c=IN IP4 192.0.2.2 
a=rtpmap:101 H263-1998 
a=mid:3
a=content:repair=2 or a=depend:repair=2

Roni Even

> -----Original Message-----
> From: Dave Singer [mailto:[email-masked]]
> Sent: Monday, June 04, 2007 7:19 PM
> To: mmusic; IETF AVT WG
> Cc: Clinton Priddle (KI/EAB)
> Subject: [MMUSIC] questions about grouping media streams in RTP and
SDP
> (RFC3388 etc), advice needed
> 
> Hi
> 
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Kalleitner, Franz" <[email-masked]>
Date: Tue, 5 Jun 2007 11:54:20 +0200

hi, dave,
 
you can find some work and ideas on how to handle a "repair" stream in parallel to an orignal RTP stream in RFC4588 too.
 
cheers, franz

________________________________

Von: Even, Roni [mailto:[email-masked]]
Gesendet: Di 05.06.2007 09:03
An: Dave Singer; mmusic; IETF AVT WG
Cc: Clinton Priddle (KI/EAB)
Betreff: [AVT] RE: [MMUSIC] questions about grouping media streams in RTPand SDP (RFC3388 etc), advice needed

Dave,

v=0

a=group:ALTS 1 2
a=group:ALTS 1 3

m=audio 6886 RTP/AVP 0
c=IN IP6 2001:0600::1
a=mid:1

m=video 9000 RTP/AVP 100
c=IN IP4 192.0.2.2
a=rtpmap:100 H263-1998
a=mid:2

m=video 9002 RTP/AVP 101
c=IN IP4 192.0.2.2
a=rtpmap:101 H263-1998
a=mid:3

Roni Even

SDP

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 4 Jun 2007 13:54:29 -0700

> http://tools.ietf.org/html/draft-ietf-tsvwg-udp-guidelines?

I agree "send periodic UDP traffic" would be good in that
document.  REQ-6 of draft-ford-behave-app-05 may provide the 
beginnings of some useful text (CC'ing the authors of that 
document).

As with all applications on today's Internet, an RTP 
application needs to be robust and able to deal with whatever 
is sent to it, so perhaps you're right -- an application-
specific keepalive document may well be overly specific and
we should, rather, document what any UDP-based application
should do to prevent middleboxes (such as NATs) from 
clobbering a flow.

-d

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 4 Jun 2007 13:40:11 -0700

I think that the AVT WG has the right people to review and recommend  
way(s) to do keep alive for RTP flows - so if we are doing this work  
anywhere, AVT  would be my preferred WG to do it in. Now that Behave  
has published, RFC 4787, I think it is easy for the AVT group to  
ensure that whatever the recommendation is,  it will work with NATs  
that are compliant with BEHAVE. This helps resolve the issues of  
making sure that enough NAT people are involved with the discussion.

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 5 Jun 2007 15:57:45 +0300

Hi,

I think that defining the keepalive for RTP that will not break RTP is
an important work and can be done in AVT. 
I read the draft and it looks like a good start. I support as having it
an AVT working group draft

Roni Even 

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Friday, June 01, 2007 8:15 PM
> To: IETF AVT WG; [email-masked]; mmusic
> Cc: Even, Roni; Tom Taylor; Dan Wing ((dwing)); Cullen Jennings; Joerg
> Ott; Xavier Marjou; Jean-Francois Mule; Magnus Westerlund
> Subject: Moving draft-marjou-behave-app-rtp-keepalive to AVT
>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 5 Jun 2007 16:05:29 +0100

> should do to prevent middleboxes (such as NATs) from

The udp-guidelines draft should probably outline what sort of keep  
alive mechanism is needed, but the implementation is likely protocol  
specific, and should be done by the group designing that protocol, I  
think.

-- 
Colin Perkins
http://csperkins.org/

---

From: Lars Eggert <[email-masked]>
Date: Tue, 5 Jun 2007 18:10:19 +0300

On 2007-6-5, at 18:05, ext Colin Perkins wrote:
> alive mechanism is needed, but the implementation is likely  
> protocol specific, and should be done by the group designing that  
> protocol, I think.

Makes sense to me.

Lars

---

From: Dave Singer <[email-masked]>
Date: Tue, 5 Jun 2007 08:34:08 -0700

>http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.tx

I don't think this is a layered coding issue, either, alas.

>alternate offers.

No, these streams are not alternatives to each other in the regular 
sense.  Nor is this really used in offer/answer;  it's more an issue 
for multicast.  In multicast, you open the tune-in stream and the 
base stream, grab the first I-frame that arrives (in either) and then 
drop the tune-in stream.

Yes, we're aware that the recipient needs to be able to tell which is 
the base and which is the tune-in.

>If this is the case I have similar requirements and

-- 
David Singer
Apple/QuickTime

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 6 Jun 2007 09:34:12 +0300

Dave,
 From your response:

"No, these streams are not alternatives to each other in the regular
sense.  Nor is this really used in offer/answer;  it's more an issue for
multicast.  In multicast, you open the tune-in stream and the base
stream, grab the first I-frame that arrives (in either) and then drop
the tune-in stream.

Yes, we're aware that the recipient needs to be able to tell which is
the base and which is the tune-in."

Reading your application I will try to generalize it. To me you have two
streams that have a relationship and there is semantics for the relation
between the streams.

You say that typically a user will only use the tune-in stream for
synchronization; I would think that this can happen when joining the
session or when losing synchronization. 
In the general case these two streams are coming from the same source
and the user may use one or the other. This is why I called them
alternate streams

After specifying the two streams (as alternate since the receiver may
chose one or the other), you want to apply a specific semantics to the
content of one stream (a repair stream). Again, I think that we need to
specify the general mechanism for semantics to enable implementations
from different vendors to understand what to do with the streams coming
from the same source.

In the current work at MMUSIC, the Label attribute (RFC 4574) define
tags to a stream but with no semantics. The content attribute RFC 4796
defines semantic to a stream. I think that we now have a requirement for
adding semantics to the relationship between streams; examples are the
repair streams and the layered codecs.

I think that by using grouping and dependency attributes we can define a
general framework that will enable these general requirements and use
them for the specific applications like repair stream, layered codecs
and just alternate offers.

Roni

> Sent: Tuesday, June 05, 2007 6:34 PM
> To: Even, Roni; mmusic; IETF AVT WG
> Subject: RE: [MMUSIC] questions about grouping media streams in RTP
and
> SDP (RFC3388 etc), advice needed
> 
> >>  we have a need to group together two media streams, in the style
of
> >RFC
> >>  I-frame interval (say every 15 seconds), with a repair stream
which
> >has
> >>  only I-frames that are equivalent to the time-parallel non-I
frame, at
> >a
> >>  Nor is it clear that the FEC group of RFC 4756 is right, either.
For
> >a
> >  > entirely may mean that you will never find a tune-in point,
making
> the
> >>  normal stream useless.
> >>
> >>  So, can we use FID for associating a repair stream with its base
(we
> >tag

---

From: Andrea Lorenzo VITALI <[email-masked]>
Date: Thu, 07 Jun 2007 13:24:00 +0200

RFC3388 tagging/grouping cannot be used

  - simultaneous encoding is explicitly forbidden (no Multiple
Description Coding)

  - grouping of layers explicitly forbidden (no Layered Coding)

I talked about this in my presentation at IETF (page 6):
http://www3.ietf.org/proceedings/05nov/slides/avt-3.pdf

My presentation was about standard-compatible Multiple Description
Coding (MDC). You can find the draft here:
http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-vitali-ietf-avt-mdc-lc-00.txt

Your scheme is in fact an unbalanced multiple description coding scheme,
isn't it? You transmit the full video and a low-resolution video to be
used for concealment (1+1/4).

The question of dependency between streams has also been raised for the
new Scalable Video Codec (SVC).

  Andrea

-- 
 ______________________________________________________________

  Andrea VITALI                            [email-masked]

  tel (+39) 039 603 7244             mobile (+39) 347 93 08 433
  fax (+39) 039 603 6129

  STMicroelectronics
  Centro Direzionale COLLEONI - Palazzo "DIALETTICA"
  20041 Agrate Brianza (MI) ITALY
 ______________________________________________________________
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Dave Singer <[email-masked]>
Date: Thu, 7 Jun 2007 09:24:42 -0700

>   - grouping of layers explicitly forbidden (no Layered Coding)

Yes, I think it does seem that FID can't be used, though frankly the 
reasons for these restrictions are really unclear to me.  It's also 
not clear to me how DTMF tones pass their own tests (see below), but 
that's not terribly relevant.

>used for concealment (1+1/4).

It's similar;  we're actually in a different coding system (not 
video), but the video is a good analog.

>new Scalable Video Codec (SVC).

Yes, I work on that too.

Is it possible we can agree fairly soon on the group ID for grouping 
media lines of the same codec, where the client terminal chooses 
which of the media streams it needs, and when, by examining their 
other characteristics?  Examples would be layered coding, or repair 
coding.

Here's an example:

v=0
o=adam 289083124 289083124 IN IP4 host.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:group_name 1 2
m=video 30000 RTP/AVP 97
a=rtpmap:97 coding-system/90000
a=fmtp:97 contains-redundant="normal"
a=mid:1
m=video 30002 RTP/AVP 98
a=rtpmap:98 coding-system/90000
a=fmtp:98 contains-redundant="redundant"
a=mid:2

The question is, what is the "group_name" here?  And once we agree on 
the code, do we need an RFC?

Is the space of covered applications just these two:  repair and 
layered coding?

>Attachment converted: DaveG49:andrea.vitali.vcf (TEXT/ttxt) (000CDBBA)

-- 
David Singer
Apple/QuickTime

---

From: "Thomas Schierl" <[email-masked]>
Date: Thu, 7 Jun 2007 10:46:11 -0700

Hi Dave, 

I think there is a strong relation of your problem and the
http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.txt
In this draft, we described media dependency in general, not only for
scalable video. Currently, two types of dependencies are defined: layered
and mdc assuming the media is partially transported in different RTP
sessions. There is not requirement, that the part of the media is
independently decodable. It would be easy to integrate your needs, if they
should not be already covered.

Thomas

> Sent: Tuesday, June 05, 2007 8:34 AM
> Subject: [AVT] RE: [MMUSIC] questions about grouping media streams in RTP
> andSDP (RFC3388 etc), advice needed
>

---

From: Dave Singer <[email-masked]>
Date: Thu, 7 Jun 2007 10:49:08 -0700

At 10:40  -0700 7/06/07, Thomas Schierl wrote:
>http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.txt .
>sessions. It would be easy to integrate your needs, if they should not be
>already covered.
>
>
>Thomas

Thank you.  I agree the problems are identical, or close to it.

Do you think we should use 'lay' or 'mdc', or a new dependency type? 
Or integrate a new group type into the draft (is 'DDP' right for our 
application)?

-- 
David Singer
Apple/QuickTime

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 7 Jun 2007 23:06:45 +0300

Hi,
My view is that you have similarity in the need for dependencies between
streams but the grouping logic is different.
In the layered codec the grouping is for a group that you can use all or
part of while in the repair case you may take one or the other.

Roni Even

> From: Thomas Schierl [mailto:[email-masked]]
> Sent: Thursday, June 07, 2007 8:46 PM
> To: 'Dave Singer'; Even, Roni; 'mmusic'; 'IETF AVT WG'
> Cc: [email-masked]; 'Clinton Priddle (KI/EAB)'
> Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media streams
in
> RTP andSDP (RFC3388 etc), advice needed
> 
> Hi Dave,
> 
> > Subject: [AVT] RE: [MMUSIC] questions about grouping media streams
in
> RTP
> > >For layered encoding there is a proposal for a new grouping
attribute
> in
of
> > >RFC
> > >>  3388 <http://www.ietf.org/rfc/rfc3388.txt> but we're unsure
whether
> an
> > >>  existing group type is suitable or not, and if it's not, we'd
like
> to
> > >>  'entry' stream, that can be used when tuning in, or after loss,
but
> is
which
> > >>  only I-frames that are equivalent to the time-parallel non-I
frame,
> at
> > >>  It's not clear to us whether this is "one media flow" in the
sense
> > >>  "FID MUST NOT be used to group "m" lines that do not represent
the
> > >same
> > >>  example, one can typically ignore all FEC and (as long as there
are
> no
making
(we

---

From: "Thomas Schierl" <[email-masked]>
Date: Thu, 7 Jun 2007 14:33:30 -0700

Hi Dave,

I think the grouping type DDP fits, but we should talk about an extra type
of dependency for that. 

Thomas

> Sent: Thursday, June 07, 2007 10:49 AM
> To: Thomas Schierl
> Cc: [email-masked]; [email-masked]; 'Even, Roni'; [email-masked]
> inRTP andSDP (RFC3388 etc), advice needed
> 
> .
> whether an
> but is
> are no

---

From: "Thomas Schierl" <[email-masked]>
Date: Thu, 7 Jun 2007 14:47:12 -0700

Hi Roni,

Then it would be something like we call 'mdc'. But I would like to put that
into an extra dependency type, since the characteristics of the streams are
different, even if they could be used exchangeable. But there is one main
stream, let us say. And that one should be identifiable.

Thomas

> From: Even, Roni [mailto:[email-masked]]
> Sent: Thursday, June 07, 2007 1:07 PM
> To: Thomas Schierl; Dave Singer; mmusic; IETF AVT WG
> Cc: [email-masked]; Clinton Priddle (KI/EAB)
> Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media streams in

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 7 Jun 2007 15:01:42 -0700

Yes, and if this were a non-exotic use case, we would need such a  
type.  As it IS an exotic use case, I guess we can survive with 3GPP  
specifying the "normal" stream having a lower port number than the  
"repair" stream, or something like this.
(Now go out and blast me for unclean design choices. :-)
Stephan

On Jun 7, 2007, at 2:47 PM, Thomas Schierl wrote:

>>> independently decodable. It would be easy to integrate your  
>>> needs, if
>> they
>>>>> http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered- 
>>>>> codec-
>>> 03.tx
>>>>> t
>>>>

---

From: "Even, Roni" <[email-masked]>
Date: Fri, 8 Jun 2007 10:39:02 +0300

Thomas,
I already wrote that we need to look at the general case before going to
a specific solution.

Currently for a media stream we have a way to mark a stream using the
label attribute. We have a way to apply semantics to a single stream
using the content attribute. What we are doing here is defining
semantics to a group of streams by using dependency attribute. The
parameter for the dependency does not have to be the same for all cases
and depends on what you want. As for tagging the dependencies it may be
the mid number or use a label.

Now the second part that is needed is to specify the grouping, we have a
grouping attribute but it lacks some parameters for the layered codecs
and the repair stream. 
I would like to add to this the case of simple alternate attributes. For
example I can do G.711 with two H.263 video streams or G.711 with one
H.264 video stream.

I see two cases for the group, one for alternate streams and the other
for a set of streams. The advantage of using the group attribute is that
if the other side does not support it, he will remove it from the
answer.

Here are examples for both

Alternate: here you may use 1 and 2  or 1 and 3

a=group:ALTS:1 1 2
a=group:ALTS:1 1 3 

m=audio 6886 RTP/AVP 0
c=IN IP6 2001:0600::1
a=mid:1 

m=video 9000 RTP/AVP 100
c=IN IP4 192.0.2.2
a=rtpmap:100 H263-1998
a=mid:2 

m=video 9002 RTP/AVP 101
c=IN IP4 192.0.2.2
a=rtpmap:101 H263-1998
a=mid:3

For a SET here you say that 2 and 3 are a set for layering

a=group:SET 2 3

m=audio 6886 RTP/AVP 0
c=IN IP6 2001:0600::1
a=mid:1 

m=video 9000 RTP/AVP 100
c=IN IP4 192.0.2.2
a=rtpmap:100 H263-1998
a=mid:2 

m=video 9002 RTP/AVP 101
c=IN IP4 192.0.2.2
a=rtpmap:101 H263-1998
a=mid:3

Roni

> Sent: Friday, June 08, 2007 12:47 AM
> To: Even, Roni; 'Dave Singer'; 'mmusic'; 'IETF AVT WG'
in
> into an extra dependency type, since the characteristics of the
streams
> > > independently decodable. It would be easy to integrate your needs,
if
> > > > Yes, we're aware that the recipient needs to be able to tell
which
> > > > >You also need a way to give semantics to the "repair" stream,
this
> > can
> > > > >answerer understood the grouping since if he does not than he
will
> > send
> > > > >>  Subject: [MMUSIC] questions about grouping media streams in
RTP
> > > > >>  What we have is a normal media stream, and a separate
'repair'
> > or
> > > > >>  otherwise un-needed.  An example might be a video stream
with a
> > low
> > > > >>  information."  (Though how DTMF tones and their associated
audio
> > > pass
> > > > >>  start, we may wish to use this new ID in combination with
FEC,

---

From: "Thomas Schierl" <[email-masked]>
Date: Thu, 7 Jun 2007 10:40:15 -0700

Hi Dave, 

Thomas

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 7 Jun 2007 14:42:15 -0700

Hi all,
Yes, i agree with Roni: This is not a layered codec case in any  
sense, as there is no directed use hierarchy between those two  
flows.  Under certain conditions (i.e. in the absence of packet  
loss), both are valid, usable streams.
But, IMHO, this may be not a bad example for multiple description  
coding.  The two streams represent essentially the same media, and  
(under certain conditions such as packet loss) it is advantageous to  
use both of them, not only one.  It may not be a direct hit on the  
Schierl draft MDC use case, but it's close enough to be documentable  
in a 3GPP spec.
I'm not sure that the use case in question warrants a new I-D.  If  
the analogy to video transmission would be a bit more solid, I would  
have a different view.  But, a it stands, you could not use the  
mechanism envisioned with any predictive video codec (possible  
exception: H.264 extended profile, utilizing SI/SP technology), as it  
is at present close to impossible to generate identical reference  
pictures from two different streams, using different encoding methods.
Finally, I'm unsure whether 3GPP's intended timing would allow for  
yet another draft.  Even the Schierl draft comes kind of late for  
this work.
Regards,
Stephan

On Jun 7, 2007, at 1:06 PM, Even, Roni wrote:

> codec-03.tx

---

From: Colin Perkins <[email-masked]>
Date: Fri, 8 Jun 2007 15:30:13 +0100

On 1 Jun 2007, at 18:15, Colin Perkins wrote:
> Application Mechanisms for maintaining alive NAT mappings  
> associated with RTP flows (draft-marjou-behave-app-rtp- 
> keepalive-01.txt) as an AVT working group draft. This has  
> previously been discussed in AVT, BEHAVE and MMUSIC. Opinions on  
> whether this draft should become a working group draft, and on the  
> appropriate home for it, are solicited by 8 June 2007.

There were several comments in favour of this proposal, and no  
objections. Accordingly, we will take this draft as an AVT work item.

-- 
Colin Perkins
http://csperkins.org/

---

From: Dave Singer <[email-masked]>
Date: Fri, 8 Jun 2007 15:56:13 -0700

At 11:54  +0200 5/06/07, Kalleitner, Franz wrote:
>hi, dave,
>
>you can find some work and ideas on how to handle a "repair" stream 
>in parallel to an orignal RTP stream in RFC4588 too.
>
>cheers, franz

Thank you.  This has the rather useful paragraph:

    A special case of the SDP description is a description that contains
    only one original session "m" line and one retransmission session "m"
    line, the grouping is then obvious and FID semantics MAY be omitted
    in this special case only.

Since this exactly describes our current situation -- the normal and 
repair streams are indeed easily identified, and we currently only 
allow one normal stream per session -- perhaps we will take this 
route, and let the standards catch up to where we need to be, if 
anyone has a need for multiple base streams in the future.

And indeed, not doing grouping means avoiding having to insist that 
any audio or video streams in the same SDP also have a media ID (as 
the grouping RFC requires)., even though those IDs are not grouped.

>loss), both are valid, usable streams.

Is an SI AVC stream really a usable stream in its own right?

>exception: H.264 extended profile, utilizing SI/SP technology), as 
>it is at present close to impossible to generate identical reference 

Actually I would have agreed with you until I found someone doing it 
in AVC successfully using I frames, not SI frames.

>stream, let us say. And that one should be identifiable.

As I say, the rtpmap declarations and parameters identify the two 
streams, we have that in hand.  We just wondered how we should group 
them -- and all that is needed is a group.  Happily the quote above 
provides the short-term answer -- don't!
-- 
David Singer
Apple/QuickTime

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 10 Jun 2007 10:10:50 +0300

Dave,
I understand that you intend to send two media streams using two m lines
without grouping and any specific semantics to identify the stream.
Our experience is that if you have two video m lines you can not know
which one the other will pick if he does not understand the relation
between the streams.
Roni

> Sent: Saturday, June 09, 2007 1:56 AM
> To: Kalleitner, Franz; Even, Roni; mmusic; IETF AVT WG
> Subject: Re: AW: [AVT] RE: [MMUSIC] questions about grouping media
streams
> in RTPand SDP (RFC3388 etc), advice needed
> 
> >Then it would be something like we call 'mdc'. But I would like to
put
> that
streams

---

From: Dave Singer <[email-masked]>
Date: Mon, 11 Jun 2007 11:51:24 -0700

Roni

you keep missing that the streams have attributes that tell me which is which.

m=video
a=fmtp: yes this is a foobar primary stream
m=video
a=fmtp:yes this is a foobar repair stream

if I see such an SDP with only one foobar primary and only one foobar 
repair, it's fairly clear that the foobar repair stream is associated 
with the foobar primary stream, without needing grouping.

I only need grouping if I have two primary streams, and that use case 
is not yet in our requirements.  It would be nice to document, but 
we're not in a hurry.
-- 
David Singer
Apple/QuickTime

---

From: Randell Jesup <[email-masked]>
Date: Tue, 12 Jun 2007 00:00:54 -0400

>repair, it's fairly clear that the foobar repair stream is associated with
>the foobar primary stream, without needing grouping.

Roni's point was really not that *you* wouldn't be able to tell, but that
some other UA (which "does not understand the relation beween the streams")
could/would mis-interpret the SDP.  This of course assumes they think at
least one payload for each stream is something they know how to
send/receive.

That's also a problem with the current grouping RFC (along with the
chicken-and-egg syndrome).

-- 
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: Dave Singer <[email-masked]>
Date: Mon, 11 Jun 2007 21:57:38 -0700

>least one payload for each stream is something they know how to

Ah, OK.  Sure, if I was introducing this for an existing media type, 
and the payload type of the repair stream was recognizable (maybe the 
same), that would be a problem.

My immediate need is for a new codec, and anyone who can decode 
either stream will have read the document that contains the media 
tagging, so I think I dodge that bullet also.

-- 
David Singer
Apple/QuickTime

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 12 Jun 2007 10:01:26 +0300

Dave,
Now we are going to a different topic.
Is this a specific codec topic or a general media repair stream. 
I thought that we are addressing a general dependency problem and not a
one specific codec problem.
Roni

> Sent: Tuesday, June 12, 2007 7:58 AM
> To: Randell Jesup
> Cc: Clinton Priddle (KI/EAB); Kalleitner,Franz; Even, Roni; mmusic;
IETF
> AVT WG
> streamsin RTPand SDP (RFC3388 etc), advice needed
> 
> with
> >Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga
OS
> team

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 12 Jun 2007 10:07:09 +0300

Randell,

I think that using grouping gives a better hint to the offerer if the
answer do not support this group semantics by excluding the group
attribute in the answer 
If you just give two m-lines the answer does not tell if the answerer
support two streams and decided for the moment to do one or if it does
not support/understand the meaning of the offer.

BTW: I think that this may have some relation also to the service tag
work but this may open a can of worms
Roni  

> From: Randell Jesup [mailto:[email-masked]]
> Sent: Tuesday, June 12, 2007 7:01 AM
> To: Dave Singer
> Cc: Even, Roni; Kalleitner, Franz; mmusic; IETF AVT WG; Clinton
Priddle
> (KI/EAB)
streams
> >you keep missing that the streams have attributes that tell me which
is
> which.
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."

---

From: Dave Singer <[email-masked]>
Date: Tue, 12 Jun 2007 08:34:39 -0700

>one specific codec problem.

If there was a solution to the general problem available, then I 
would have used it.  But the immediate need is for a specific, new, 
codec and payload format;  the example I gave of a video codec was 
just an example (and simpler to explain).

-- 
David Singer
Apple/QuickTime