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

Haining.Liu@mindspeed.com Wed, 28 September 2005 16:58 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKfGF-0006Uy-8L; Wed, 28 Sep 2005 12:58:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKfGC-0006T4-30 for avt@megatron.ietf.org; Wed, 28 Sep 2005 12:58:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19926 for <avt@ietf.org>; Wed, 28 Sep 2005 12:58:21 -0400 (EDT)
From: Haining.Liu@mindspeed.com
Received: from mail-haw.bigfish.com ([12.129.199.61] helo=mail18-haw-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKfNg-0002Uo-2l for avt@ietf.org; Wed, 28 Sep 2005 13:06:08 -0400
Received: from mail18-haw.bigfish.com (localhost.localdomain [127.0.0.1]) by mail18-haw-R.bigfish.com (Postfix) with ESMTP id A9931322947 for <avt@ietf.org>; Wed, 28 Sep 2005 16:58:02 +0000 (UTC)
X-BigFish: VPC
Received: by mail18-haw (MessageSwitch) id 1127926534480828_22506; Wed, 28 Sep 2005 16:55:34 +0000 (UCT)
Received: from mspdsmtp2.mindspeed.com (mspdsmtp2.mindspeed.com [199.33.64.93]) by mail18-haw.bigfish.com (Postfix) with ESMTP id 6EBDD322828 for <avt@ietf.org>; Wed, 28 Sep 2005 16:55:34 +0000 (UTC)
Received: from npblnh1.la.mindspeed.com (npblnh1.la.mindspeed.com [10.231.23.16]) by mspdsmtp2.mindspeed.com (8.11.7p1+Sun/8.11.7) with ESMTP id j8SGtYo21969 for <avt@ietf.org>; Wed, 28 Sep 2005 09:55:34 -0700 (PDT)
Received: from npblnm2.la.mindspeed.com ([10.231.23.18]) by npblnh1.la.mindspeed.com (Lotus Domino Release 6.5.3) with ESMTP id 2005092809553367-478543 ; Wed, 28 Sep 2005 09:55:33 -0700
To: avt@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OF3D0EBBC7.5A49FFC6-ON8825708A.005CDC30-8825708A.005CEE09@mindspeed.com>
Date: Wed, 28 Sep 2005 09:55:09 -0700
X-MIMETrack: Serialize by Router on NPBLNM2/Server/Conexant(Release 6.53HF680 | August 17, 2005) at 09/28/2005 09:55:32, Serialize complete at 09/28/2005 09:55:32, Itemize by SMTP Server on NPBLNH1/Server/Conexant(Release 6.5.3|September 14, 2004) at 09/28/2005 09:55:33 AM, Serialize by Router on NPBLNH1/Server/Conexant(Release 6.5.3|September 14, 2004) at 09/28/2005 09:55:34 AM, Serialize complete at 09/28/2005 09:55:34 AM
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21
Subject: [AVT] Fw: some questions regarding 3GPP UP over RTP
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1250156174=="
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Firstly, thanks Dr. Thomas's comments.  May I get some more opinions?

Best,

haining


----- Forwarded by Haining Liu/USA/Mindspeed on 09/28/2005 09:53 AM -----

Haining Liu/USA/Mindspeed wrote on 09/27/2005 11:27:05 PM:

> 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? 
> 
> 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.
> 
> 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
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt