RE: [AVT] some questions regarding 3GPP UP over RTP

Dear Mr Liu,

you are probably asking this questions on the wrong email explorer, I would recommend the 3GPP CT3 email explorer instead - see http://list.3gpp.org/3gpp_tsg_ct_wg3.html.

Please find some answers inline.

Best regards, Th Belling

---------------------------------- 
Dr. Thomas Belling 
Siemens AG           
Sankt-Martin-Str. 76 
D-81541 München Germany 
Com MN PG NT MN 1 
MCH M 34 307 
Tel     +49 89 636 75207 
Fax     +49 89 636 75577 
Mobile  +49 172 2974678 
Email   Thomas.Belling@siemens.com 

	-----Original Message-----
	From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Haining.Liu@mindspeed.com
	Sent: Wednesday, September 28, 2005 8:27 AM
	To: avt@ietf.org
	Cc: michael.beadle@mindspeed.com
	Subject: [AVT] some questions regarding 3GPP UP over RTP

	Hello,

	When we implement 3GPP UP over RTP in our products, we've fould some confusions regarding how to stack UP and RTP together correctly.  Some of our customers have different opinions regarding these issues. We consulted 3GPP standards, and the answers are simply not there. Can you guys throw some opinions? Can we somehow standardize this within IETF? I can certainly contribute on this if necessary...

	Let me first give a brief overview of the problem.

	Iu/NbUP is a user plane protocol which is designed to convey GSM AMR traffic or G711 traffic between base stations and the core networks. Similar to RTP, it has sequence number, payload type indication, though defined in a different way. Apart from attaching these information to each encoded frame, it also has specified some other control functionalities, such as the delivery of requests such as error indication, time alignment and rate control. The frames deliever this type of information are categorized as control frames. Since IP-based infrastructure is gradually replacing the traditional PSTN or ATM networks, different venders  
	and ISPs are calling for IuUP/NbUP over RTP/UDP/IP. 3GPP has two separate standards that specify how to do this, but there are plenty of grey zones left which are basically left for the vendors or ISPs to interpret.

	Here are some specific issues. As in past practice, UP layer is directly stacked over RTP layer. As a result, control frames and data frames are indeed multiplexed into a single RTP packet flow at the sender. The how should the sequence number be generated if data frames and control frames are interleaved together? What about time stamp, RTP statistics, and RTCP stats? 
	[Belling Thomas] 
	Keeping apart control and data frames is part of NbFP, nothing to bother about on RTP layer, where they are treated in the same way. In my understanding, it is a basic proinciple of a layered protocol design that details of data transported as payload do not need to be taken into account in the encapsulating protocol. NbFP also features own sequence numbers/time stamps, see TS 29.415 and TS 24.415. TS 29.414 therefore states

	6.2.3.1.7              Sequence Number 

	The sequence number shall be supplied by the source MGW of a RTP PDU. The sink MGW of a RTP PDU may ignore the sequence number or it may use it to obtain statistics about the link quality and / or to correct out-of-sequence delivery, e.g. by dropping out-of-sequence packets.

	6.2.3.1.8              Timestamp

	The timestamp shall be supplied by the source MGW of a RTP PDU. A clock frequency of 16000 Hz shall be used. The sink MGW of a RTP PDU may ignore the timestamp or it may use it to obtain statistics about the link quality and / or to correct jitter.

	6.2.4       RTCP

	RTCP (see RFC 1889 [24]) may be applied. The use of the RTCP protocol is optional.

	A MGW may ignore incoming RTCP PDUs.

	Some think that as long as there is only one RTP packet flow, time stamp value and sequence number value should reference a single space because all packets use a single SSRC value (e.g., if we have data packets at 0ms and 20ms, and a control packet at 15ms, we have the following event sequence: data-->control-->data). This certainly will create some confusion at the receiver, since there might be some sequence number gaps between neighbouring data packets. Arguing this, others think control frames should not share the sequence number space with data frames. But the down side of this approach is that some RTP implementation will drop the out-of-the-sequence packets without investigating what is actually inside the payload.
	[Belling Thomas] 
	I would recommend to relay more on the NBFP sequence number. If you do statistics on RTP layer, you should keep in mind the effect you describe in the interpretation. I agree that it is not a good idea to treat the control packages with same kind of seperate RTP sequence numbers, as this may result in fundamental non-interoperability, rather than only some confusions if statistics are misintepreted.

	Basically the confusion here is about how RTP layer should package heterogenous upper layer content. How should the time stamp value and the sequence number value be defined here? 

	Any comments or pointers are welcome!

	Haining Liu
	Mindspeed Technologies Inc.
	Newport Beach, CA, USA