Subject: [AVT] RE: [MMUSIC] Comments on draft-hdesinen-mmusic-oa-send-bw-attr-02.txt

From: "Desineni, Harikishan" <[email-masked]>
Date: Sat, 17 Mar 2007 00:25:42 -0700

I copied a post (from AVT list) from Roni which states that TIAS was
actually used in his implementation. I am not sure if it is an
implementation in offer/answer model.

[CCed AVT as TIAS was also recently discussed on AVT list]

"
-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: Monday, January 08, 2007 7:35 AM
To: Randell Jesup
Cc: Stephan Wenger; [email-masked]
Subject: RE: [AVT] CCM draft review -- should "bandwidth" include
theheaderoverhead

Randell,
RFC 4890 recommends sending both TIAS and AS for backward compatibility
with systems that do not support TIAS. This RFC gives a good explanation
why to use TIAS. This is what we do in our implementation.
"

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Friday, March 16, 2007 9:44 AM
> To: Desineni, Harikishan
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Comments on
draft-hdesinen-mmusic-oa-send-bw-attr-
> 02.txt
> 
> Desineni, Harikishan skrev:
> >
> >
> > Magnus,
> >
> > Thanks for the comments.
> >
> > In the initial version, I captured the current understanding of
(TIAS
> > ,maxprate) based on RFC3890.
> >
> > Based on the current RFCs, majority of the community interprets TIAS
as
> > receive only direction attribute. Instead of updating RFC3890 to
modify
> > TIAS as a send direction only attribute, it is better to use a new
> > attribute 'MSR' proposed in this draft. This would also avoid any
> > backward compatibility/inter-op issues that can arise with current
> > implementations which (correctly) interpret TIAS as receive
direction
> > only attribute in offer/answer.
> 
> Well, I wonder how there can be backwards compatibility issues with
> something that clearly doesn't work if you actually try to use it.
There
> might be implementations but I can't really understand how they could
> work. Do you know of implementations?
> 
> >
> > Another approach is to add directionality to TIAS. By default, TIAS
is
> > receive only (not much useful) and "TIAS/sendonly" will be send only
> > direction. "maxprate/send" will be packet rate in send direction.
> >
> > What you are proposing is the following
> > Send direction attributes: RTP Payload rate and maxpacket rate
> > Receive direction attributes: AS (or a new one), packet overhead
> 
> Okay, here I think the more important question is, are we expecting to
> be able to specify a value on another level than IP? If not I think AS
> works fine.
> 
> >
> > In this draft I am proposing that 'MSR' be used for signaling RTP
> > payload rate in 'send' direction. IMO, it is not a clean approach to
> > redefine TIAS to be a 'send' direction attribute.
> 
> We disagree on this. TIAS was specified as a send direction attribute.
I
> made an error in the offer/answer usage because I didn't consider the
> implications. And no one picked up on it.
> 
> As I can see it in regards to RFC 3890 we have two alternatives:
> 
> 1. Fix the offer/answer section to correctly define it to apply in the
> sending direction.
> 
> 2. Obsolete usage of TIAS in Offer/Answer exchanges and only use it
for
> declarative usage, like in RTSP.
> 
> If there are implementations i any numbers that interpret TIAS as a
> receiver direction attribute then I agree alternative 2 will be best.
> However I would like to have some positive acknowledgments of this
> first. This was after all revealed in the attempt to apply TIAS to
> offer/answer in the 3GPP MTSI standardization work. Resulting in that
> TIAS was only included in the draft spec for a while. I don't know if
> some other umbrella standard has included TIAS combined with
offer/answer.
> 
> >
> > I am OK with signaling packet rate in send direction. But we need to
> > consider whether to reuse maxprate for this or add directionality to
> > maxprate (maxprate/send) to avoid any inter-op issues with current
> > implementations.
> >
> 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM/M
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------

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