Subject: [AVT] Dynamic selection of Codec??

From: <[email-masked]>
Date: Tue, 27 Mar 2007 18:44:08 +0530

Hello, 
   Can we select codec dynamically in the mid session when a SIP call is
going on?  

Suppose in 10 min. of a SIP call, Initially my bandwidth is excellent so I
choose for quality codec rather than bandwidth consumption codec, and after
few minutes my bandwidth is very less, so at that time, how can I manage my
quality of call?  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, March 06, 2007 10:30 PM
To: [email-masked]
Subject: avt Digest, Vol 35, Issue 9

Send avt mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/avt
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of avt digest..."

Today's Topics:

   1. RE: LIP synch and TMMBR; was Re: R:	[AVT]	CCMdraftreview--
      should"bandwidth"includetheheaderoverhead (Allison, Art)
   2. Re: Issues with using tuples in TMMBR was:Re: R: [AVT] CCM
      draft	review --	should"bandwidth"includetheheaderoverhead
      (Randell Jesup)
   3. I-D ACTION:draft-ietf-avt-profile-savpf-10.txt 
      ([email-masked])

----------------------------------------------------------------------

Message: 1
Date: Mon, 5 Mar 2007 12:37:37 -0500
From: "Allison, Art" <[email-masked]>
Subject: RE: LIP synch and TMMBR; was Re: R:	[AVT]	CCMdraftreview--
	should"bandwidth"includetheheaderoverhead
To: <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

I think others more expert than I are addressing this more precisely
than I can. 

I jumped in because there was a discussion of codec only vs. codec plus
overhead alternatives,  I know that lip-synch is difficult to manage and
I thought it to be a factor that should be considered.
 
The signaling of each of the flows, at the codec level only for video
[and audio but assuming for simplicity it is the 'same method' - even
though audio is not in scope], would seem to make differential delay
assessment for the two flows through their paths more complex, and the
impact seemed relevant to contribute to the selection of which.  

The differences may be well handled by buffer models, but getting lip
synch right is a practical challenge for every digital system and the
offsets vary with flow rates for the components.  So from 100k meters
up, it seemed and still seems relevant to consider as a factor.

I leave to the advocates of  alternative flow definitions to assert
whether or not this consideration supports their case. 

See below for specific answers.

As background  <not directly applicable here>, see ATSC IS/191 at
http://www.atsc.org/standards/is_findings.html for determination of the
broadcast quality timing budgets.  I will note that the maintenance of
lip-synch within the 15ms lead and 45ms lag in outputs to fixed relative
delay delivery paths remains a challenge even with absolutely known (but
changing) differential path delays as the content changes. If it is hard
with complete knowledge, it will not be easier with less information....
:)

My concern is maintaining the quality of broadcasters' web streams to IP
devices.
Art
_____________
Art Allison
Director, Advanced Engineering
Science & Technology
National Association of Broadcasters
1771 N Street, NW
Washington, D.C. 20036
Phone: 202.429.5418
Fax: 202.777.4981
[email-masked]

The National Association of Broadcasters is a trade association that
advocates on behalf of more than 8,300 free, local radio and television
stations and also broadcast networks before Congress, the Federal
Communications Commission and the Courts.

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Monday, February 26, 2007 5:40 AM
To: Allison, Art
Cc: Desineni, Harikishan; [email-masked]
Subject: LIP synch and TMMBR; was Re: R: [AVT] CCMdraftreview--
should"bandwidth"includetheheaderoverhead

Allison, Art skrev:
> How to control lip-sync or lack thereof is clearly out of scope here.
> 
> However, I respectively disagree with the AD that it is out of scope 
> as a factor in the decision between selection of a total bit rate 
> control vs. a partial bit rate control.

Can you please clarify what you mean with total vs partial bit-rate
control.
AA> Total includes overhead(s), partial is codec payload only. 
> 
> It is only one factor, but declaring it out of scope as a 
> consideration can be expected to impact the technical choice.
> 
> I request reconsideration and clarification, as surly the AD did not 
> intend to force the group to ignore a technical factor that is 
> material to the RFC content.
> 

To be clear, in AVT I am only another technical contributor. Cullen
Jennings is the responsible AD for this WG. I am not trying to force
something out. However I have so far failed to see how the issue you are
discussing do affect TMMBR. Looking at the fundamental synchronization
model RTP has, TMMBRs impact on lip-synch is purely implementation
specific. Sure there are things that in the implementation that controls
what is actually sent that could affect when packets get sent in such a
way that it has some impact on the lip-synch. Are there any special part
of the problem that you would like to have note about to help improve
implementations?
AA> Not really, it is just that receivers will have to deal with the
flow rate for both audio and video at the 'same' time, which impacts
complexity/processing power of the implementation. 
Thanks,
Art//

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

------------------------------

Message: 2
Date: Mon, 05 Mar 2007 13:14:52 -0500
From: Randell Jesup <[email-masked]>
Subject: Re: Issues with using tuples in TMMBR was:Re: R: [AVT] CCM
	draft	review --	should"bandwidth"includetheheaderoverhead
To: Magnus Westerlund <[email-masked]>
Cc: [email-masked], Franceschini Guido
	<[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

Magnus Westerlund <[email-masked]> writes:
>Randell Jesup skrev:
>> Magnus Westerlund <[email-masked]> writes:
>>> A session starts with a single limitation equal to the session maximum
>>> bit-rate and a overhead value equal to 0.
>> I hate to beat a dead horse, but exactly what does "session maximum
>> bit-rate" mean in this context?  And do the sender and the receiver have
>> the same idea about what the maximum is to start with in all scenarios?
>> Is it the requested bitrate the receiver sent?  What if the sender
decided
>> to use a higher (or lower) rate?
>
>The session maximum bit-rate is negotiated by the session setup
>protocol. For example the AS values in SDP when using SIP.

b=AS says "I, the receiver, would like you to (or suggest that you) send no
faster than this".  This is not negotiated per se, and it's not a hard
limit.  And note that whether it's meant to or not, the term "session
maximum bitrate" implies several things that are misleading - it implies
that it's a session-level (as opposed to media-stream-level) item.  (It may
be, but b=AS may be at the stream level, and I'm assuming that a TMMBR over
RTCP applies to the stream for that RTCP port.  Does it apply to the entire
session if a b=AS only existed at the session level?)  It also implies (to
the new reader) that there is a two-way maximum negotiated.  This isn't the
case, but the terminology will tend to confuse people (and has in these
discussions here).

>> What if the receiver is joining an existing session?
>
>Also in this case there is some type of session establishment that can
>provide a upper limit. And when joining a session with already existing
>restrictions the receiver may send a TMMBR message to establish its
>limitation prior to seeing a TMMBN. In that case it will learn the set of
>restrictions from the TMMBN sent as reaction to the TMMBR.

We should consider (if not already done) talking to this case in the draft,
if for no other reason than to guide implementors.

-- 
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)

------------------------------

Message: 3
Date: Mon, 05 Mar 2007 15:50:03 -0500
From: [email-masked]
Subject: [AVT] I-D ACTION:draft-ietf-avt-profile-savpf-10.txt 
To: [email-masked]
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Audio/Video Transport Working Group of the
IETF.

	Title		: Extended Secure RTP Profile for RTCP-based
Feedback (RTP/SAVPF)
	Author(s)	: J. Ott, E. Carrara
	Filename	: draft-ietf-avt-profile-savpf-10.txt
	Pages		: 17
	Date		: 2007-3-5
	
An RTP profile (SAVP) is defined for secure real-time 
   communications, and another profile (AVPF) is specified to provide 
   timely feedback from the receivers to a sender.  This memo defines 
   the combination of both profiles to enable secure RTP 
   communications with feedback.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-savpf-10.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-avt-profile-savpf-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-profile-savpf-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
-------------- next part --------------
Skipped content of type multipart/alternative

------------------------------

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

End of avt Digest, Vol 35, Issue 9
**********************************

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

---

From: "Taddei, Herve" <[email-masked]>
Date: Tue, 27 Mar 2007 15:33:22 +0200

Hi,

You can use a scalable codec for example G.729.1 standardized in the ITU-T and decide on the bitrate you want to say based on the network conditions. You don't need any codec re-negotiation when you change of bitrate. RTP payload format is RFC 4749.

Cheers

Hervé

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Dienstag, 27. März 2007 15:14
An: [email-masked]
Betreff: [AVT] Dynamic selection of Codec??

Hello, 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, March 06, 2007 10:30 PM
To: [email-masked]
Subject: avt Digest, Vol 35, Issue 9

Today's Topics:

Message: 1

 

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Monday, February 26, 2007 5:40 AM
To: Allison, Art
Cc: Desineni, Harikishan; [email-masked]
Subject: LIP synch and TMMBR; was Re: R: [AVT] CCMdraftreview--

Cheers

Magnus Westerlund

Message: 2

decided

Message: 3

	

Send a message to:
	[email-masked].
In the body type:

---

From: "SOLLAUD Aurelien RD-TECH-LAN" <[email-masked]>
Date: Tue, 27 Mar 2007 16:24:37 +0200

>    Can we select codec dynamically in the mid session when a 
> SIP call is going on?  
> 

Yes if the caller and callee proposed several common codecs in their
SDP.
[Note that some low-end endpoints may not implement this part of the
standard and may ignore RTP packets with a payload type different from
the first codec...]

Otherwise, you need to perform a Re-INVITE to change the codec.

---

From: <[email-masked]>
Date: Tue, 27 Mar 2007 20:05:08 +0530

Hi, 
 
Is this only limited for wideband / scalable codecs?? If that’s the case,
then how can we it be implemented if I don’t have scalable codecs?

Thanks & regards,
Vamsi. 

-----Original Message-----
From: Taddei, Herve [mailto:[email-masked]] 
Sent: Tuesday, March 27, 2007 7:03 PM
To: [email-masked]; [email-masked]
Subject: AW: [AVT] Dynamic selection of Codec??

Hi,

You can use a scalable codec for example G.729.1 standardized in the ITU-T
and decide on the bitrate you want to say based on the network conditions.
You don't need any codec re-negotiation when you change of bitrate. RTP
payload format is RFC 4749.

Cheers

Hervé

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Dienstag, 27. März 2007 15:14
An: [email-masked]
Betreff: [AVT] Dynamic selection of Codec??

Hello, 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, March 06, 2007 10:30 PM
To: [email-masked]
Subject: avt Digest, Vol 35, Issue 9

To subscribe or unsubscribe via the World Wide Web, visit
	https:/From [email-masked] Tue Mar 27 10:37:30 2007
From: <[email-masked]>
To: "'Taddei, Herve'" <[email-masked]>,
	<[email-masked]>
Subject: RE: [AVT] Dynamic selection of Codec??
Date: Tue, 27 Mar 2007 20:05:08 +0530
Cc: 

Hi, 
 
Is this only limited for wideband / scalable codecs?? If that’s the case,
then how can we it be implemented if I don’t have scalable codecs?

Thanks & regards,
Vamsi. 

-----Original Message-----
From: Taddei, Herve [mailto:[email-masked]] 
Sent: Tuesday, March 27, 2007 7:03 PM
To: [email-masked]; [email-masked]
Subject: AW: [AVT] Dynamic selection of Codec??

Hi,

You can use a scalable codec for example G.729.1 standardized in the ITU-T
and decide on the bitrate you want to say based on the network conditions.
You don't need any codec re-negotiation when you change of bitrate. RTP
payload format is RFC 4749.

Cheers

Hervé

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Dienstag, 27. März 2007 15:14
An: [email-masked]
Betreff: [AVT] Dynamic selection of Codec??

Hello, 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, March 06, 2007 10:30 PM
To: [email-masked]
Subject: avt Digest, Vol 35, Issue 9

Today's Topics:

Message: 1

 

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Monday, February 26, 2007 5:40 AM
To: Allison, Art
Cc: Desineni, Harikishan; [email-masked]
Subject: LIP synch and TMMBR; was Re: R: [AVT] CCMdraftreview--

> I request reconsid/www1.ietf.org/mailman/listinfo/avt

Today's Topics:

Message: 1

 

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Monday, February 26, 2007 5:40 AM
To: Allison, Art
Cc: Desineni, Harikishan; [email-masked]
Subject: LIP synch and TMMBR; was Re: R: [AVT] CCMdraftreview--

Cheers

Magnus Westerlund

Message: 2

decided

-- 
Randell Jesup, Worldgate (developers oferation and clarification, as surly the AD did not 

Cheers

Magnus Westerlund

Message: 2

decided

Message: 3

	

Send a message to:
	[email-masked].
In the body type:

---

From: <[email-masked]>
Date: Tue, 27 Mar 2007 20:05:52 +0530

Hi, 
   
   May I know what is the standard implemented, i.e. is there any rfc for
this?

Or how we need to send a Re-INVITE so as to change the codec dynamically
when a call is going on?

Thanks & regards,
Vamsi.

-----Original Message-----
From: SOLLAUD Aurelien RD-TECH-LAN
[mailto:[email-masked]] 
Sent: Tuesday, March 27, 2007 7:55 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [AVT] Dynamic selection of Codec??

by uid 510); 27 Mar 2007 08:50:22 -0600
From: <[email-masked]>
To: "'SOLLAUD Aurelien RD-TECH-LAN'" <[email-masked]>
Subject: RE: [AVT] Dynamic selection of Codec??
Date: Tue, 27 Mar 2007 20:05:52 +0530
Cc: [email-masked]

Hi, 
   
   May I know what is the standard implemented, i.e. is there any rfc for
this?

Or how we need to send a Re-INVITE so as to change the codec dynamically
when a call is going on?

Thanks & regards,
Vamsi.

-----Original Message-----
From: SOLLAUD Aurelien RD-TECH-LAN
[mailto:[email-masked]] 
Sent: Tuesday, March 27, 2007 7:55 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [AVT] Dynamic selection of Codec??