[AVT] RE: avt Digest, Vol 35, Issue 29

["Ingemar Johansson S \(LU/EAB\)" <[e-mail]>]

Hi

There are a few speech/audio codecs available that support dynamic changes in bitrate during a session. From the AMR codec family one can chose from

AMR:     
  Narrowband speech codec (8kHz sample rate).
  Bitrates 4.75-12.2kbps 
  (aka the codec used in GSM, UMTS)
  http://en.wikipedia.org/wiki/AMR-WB
AMR-WB:  Widedband speech codec (16kHz sample rate). 
  Bitrates 6.60-23.85kbps
  http://en.wikipedia.org/wiki/AMR-WB 
Payload format in RFC3267 and soon updated by draft-ietf-avt-rtp-amr-bis

AMR-WB+: 
  Speech and audio stereo/mono codec. 
  Audio bandwidth varies between 6.4kHz and 20kHz depending on 
  bitrate (5.2-48kbps), the sample rate remains the same though due to 
  internal "dynamically adjustable" resampling. Worth notice is also 
  that it is possible to even switch between stereo and mono 
  almost seamlessly during a session
  http://en.wikipedia.org/wiki/AMR-WB%2B  
Payload format in RFC4352

C-code for the codecs mendioned above can be downloaded from 
http://www.3gpp.org/ftp/Specs/html-info/26-series.htm
The floating point c-code are specs 26.104, 26.204 and 26.304
Also: The bitrate switching and the associated signaling is specified in 3GPP TS26.114 available from the same website, this does actually adress the dynamic codec rate question described below.

Regards
Ingemar


> Date: Tue, 27 Mar 2007 15:33:22 +0200
> From: "Taddei, Herve" <[e-mail]>
> Subject: AW: [AVT] Dynamic selection of Codec??
> To: <[e-mail]>, <[e-mail]>
> Message-ID:
> 	
> <[e-mail]>
> Content-Type: text/plain;	charset="iso-8859-1"
> 
> 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: [e-mail] [mailto:[e-mail]] 
> Gesendet: Dienstag, 27. März 2007 15:14
> An: [e-mail]
> Betreff: [AVT] Dynamic selection of Codec??
> 
> 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: [e-mail] [mailto:[e-mail]] 
> Sent: Tuesday, March 06, 2007 10:30 PM
> To: [e-mail]
> Subject: avt Digest, Vol 35, Issue 9
> 
> Send avt mailing list submissions to
> 	[e-mail]
> 
> 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
> 	[e-mail]
> 
> You can reach the person managing the list at
> 	[e-mail]
> 
> 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 
>       ([e-mail])
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 5 Mar 2007 12:37:37 -0500
> From: "Allison, Art" <[e-mail]>
> Subject: RE: LIP synch and TMMBR; was Re: R:	[AVT]	CCMdraftreview--
> 	should"bandwidth"includetheheaderoverhead
> To: <[e-mail]>
> Message-ID: <[e-mail]>
> 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: [phone]
> Fax: [phone]
> [e-mail]
> 
> 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:[e-mail]] 
> Sent: Monday, February 26, 2007 5:40 AM
> To: Allison, Art
> Cc: Desineni, Harikishan; [e-mail]
> 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 [phone]
> Torshamsgatan 23           | Fax   [phone]
> S-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 05 Mar 2007 13:14:52 -0500
> From: Randell Jesup <[e-mail]>
> Subject: Re: Issues with using tuples in TMMBR was:Re: R: [AVT] CCM
> 	draft	review --	
> should"bandwidth"includetheheaderoverhead
> To: Magnus Westerlund <[e-mail]>
> Cc: [e-mail], Franceschini Guido
> 	<[e-mail]>
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=us-ascii
> 
> Magnus Westerlund <[e-mail]> writes:
> >Randell Jesup skrev:
> >> Magnus Westerlund <[e-mail]> 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
> [e-mail]
> "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: [e-mail]
> Subject: [AVT] I-D ACTION:draft-ietf-avt-profile-savpf-10.txt 
> To: [e-mail]
> Cc: [e-mail]
> Message-ID: <[e-mail]>
> 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-sav
> pf-10.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [e-mail] 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:
> 	[e-mail].
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt
> 
> 
> End of avt Digest, Vol 35, Issue 9
> **********************************
> 
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 27 Mar 2007 16:24:37 +0200
> From: "SOLLAUD Aurelien RD-TECH-LAN"
> 	<[e-mail]>
> Subject: RE: [AVT] Dynamic selection of Codec??
> To: <[e-mail]>
> Cc: [e-mail]
> Message-ID:
> 	
> <[e-mail]
> lecom.fr>
> 	
> Content-Type: text/plain;	charset="us-ascii"
> 
> >    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.
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt
> 
> 
> End of avt Digest, Vol 35, Issue 29
> ***********************************
> 

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