Subject: [AVT] Question on AMR-RTP-verion -10 PL format

From: Faerber Tobias ICM MP PO8 RD MCH83 <[email-masked]>
Date: Wed, 24 Oct 2001 12:10:40 +0200

hi,
I have two questions copncerning the RTP-AMR-PL format:
1)
normally no codec mode switching between AMR and AMR-WB is possible (chapter
6). But if a server sends an RTSP-"ANNOUNCE" command, it could update
session description and so introduce AMR-WB into the session. Is that
possible ? (I cannot find any hint on the session description only beeing
made once at the beginning).
So cm switching between codecs would be possible in that way but would not
make sense I guess not to risk a break of the stream!

2)
in chapter 2 I only find the hint that in case of robust sorting a bit
sensitivity ordering shall be made. but I guess it is always in really every
case of transmission used, because in simple payload sorting you find a hint
that here as well bits are ordered accoring to sensititvity.
so am I right that ordering according to AMR-IF2-table will be used in any
case ?

best regards,
Tobi

----------------------------------------------------------------------------
-------
> Faerber Tobias		Siemens AG
----------------------------------------------------------------------------
---------------------------

> -----Ursprüngliche Nachricht-----
> Von:	[email-masked] [SMTP:[email-masked]]
> Gesendet am:	Freitag, 27. Juli 2001 13:07
> Cc:	[email-masked]
> Betreff:	[AVT] I-D ACTION:draft-ietf-avt-rtp-new-10.txt,.ps
> 
> 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		: RTP: A Transport Protocol for Real-Time
> Applications
> 	Author(s)	: H. Schulzrinne, S. Casner, R. Frederick, V.
> Jacobson
> 	Filename	: draft-ietf-avt-rtp-new-10.txt,.ps
> 	Pages		: 104
> 	Date		: 26-Jul-01
> 	
> This memorandum is a revision of RFC 1889 in preparation for
> advancement from Proposed Standard to Draft Standard status. Readers
> are encouraged to use the PostScript form of this draft to see where
> changes from RFC 1889 are marked by change bars.
> This memorandum describes RTP, the real-time transport protocol. RTP
> provides end-to-end network transport functions suitable for
> applications transmitting real-time data, such as audio, video or
> simulation data, over multicast or unicast network services. RTP does
> not address resource reservation and does not guarantee quality-of-
> service for real-time services. The data transport is augmented by a
> control protocol (RTCP) to allow monitoring of the data delivery in a
> manner scalable to large multicast networks, and to provide minimal
> control and identification functionality. RTP and RTCP are designed
> to be independent of the underlying transport and network layers. The
> protocol supports the use of RTP-level translators and mixers.
> This specification is a product of the Audio/Video Transport working
> group within the Internet Engineering Task Force. Comments are
> solicited and should be addressed to the working group's mailing list
> at [email-masked] and/or the authors.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-10.txt
> 
> 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-rtp-new-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-rtp-new-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. << Nachricht: Unbenannte Anlage >> 

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 24 Oct 2001 13:22:39 +0200

Hi Tobias,

> make sense I guess not to risk a break of the stream!

You can assign two payload types, one of AMR and one for AMR-WB in the same
media line in the SDP description. Then the server can switch between them. The
problem in a streaming session is that there is no RTP channel in the direction
client - server which can be used for signaling codec mode request.

> so am I right that ordering according to AMR-IF2-table will be used in any

Yes, the speech bits in each speech frame is sorted in sensitivity order, which
is specified in 3GPP TS 26.101(NB) and 26.201(WB). This is regardless of the use
of robust sorting or not. Robust sorting will sort all speech frame bytes into a
payload which is in sensitivity order.

Regards

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Pekka Pessi <[email-masked]>
Date: 24 Oct 2001 15:37:42 +0300

In message <[email-masked]> Magnus Westerlund <[email-masked]> writes:
>You can assign two payload types, one of AMR and one for AMR-WB in the
>same media line in the SDP description. Then the server can switch
>between them. The problem in a streaming session is that there is no
>RTP channel in the direction client - server which can be used for
>signaling codec mode request.

	I think that two separate RTSP (and RTP) sessions is best
	solution for this problem.  If there are two RTSP-level
	sessions, the RTSP client can PAUSE one session and PLAY another
	when it wants to change the codec.  The reason for two RTP
	sessions is difference in timestamp resolution, which is 8000 Hz
	AMR and 16000 Hz for AMR-WB.  At least, the AMR-WB stream should
	have different SSRC (hence it can use different TS/SEQ space).

					Pekka Pessi