----------------------------------
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 at siemens.com
-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Haining.Liu at mindspeed.com
Sent: Wednesday, September 28, 2005 8:27 AM
To: avt at ietf.org
Cc: michael.beadle at mindspeed.com
Subject: [AVT] some questions regarding 3GPP UP over RTPHello,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 states6.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 LiuMindspeed Technologies Inc.Newport Beach, CA, USA
_______________________________________________ Audio/Video Transport Working Group avt at ietf.org https://www1.ietf.org/mailman/listinfo/avt