[AVT] some questions regarding 3GPP UP over RTP

Haining.Liu@mindspeed.com Wed, 28 September 2005 06:27 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKVPb-0003Kr-8o; Wed, 28 Sep 2005 02:27:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKVPY-0003JI-P0 for avt@megatron.ietf.org; Wed, 28 Sep 2005 02:27:24 -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 CAA08412 for <avt@ietf.org>; Wed, 28 Sep 2005 02:27:23 -0400 (EDT)
From: Haining.Liu@mindspeed.com
Received: from mail-fra.bigfish.com ([62.209.45.166] helo=mail17-fra-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKVWw-0002Cm-0Y for avt@ietf.org; Wed, 28 Sep 2005 02:35:03 -0400
Received: from mail17-fra.bigfish.com (localhost.localdomain [127.0.0.1]) by mail17-fra-R.bigfish.com (Postfix) with ESMTP id 4D2374445A4 for <avt@ietf.org>; Wed, 28 Sep 2005 06:27:09 +0000 (UTC)
X-BigFish: VPC
Received: by mail17-fra (MessageSwitch) id 1127888829223651_7073; Wed, 28 Sep 2005 06:27:09 +0000 (UCT)
Received: from mspdsmtp1.mindspeed.com (mspdsmtp1.mindspeed.com [199.33.64.92]) by mail17-fra.bigfish.com (Postfix) with ESMTP id A643B43FB4E for <avt@ietf.org>; Wed, 28 Sep 2005 06:27:08 +0000 (UTC)
Received: from npblnh1.la.mindspeed.com (npblnh1.la.mindspeed.com [10.231.23.16]) by mspdsmtp1.mindspeed.com (8.11.7p1+Sun/8.11.7) with ESMTP id j8S6R7P13059 for <avt@ietf.org>; Tue, 27 Sep 2005 23:27:07 -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 2005092723270648-472059 ; Tue, 27 Sep 2005 23:27:06 -0700
Importance: Normal
X-Priority: 3 (Normal)
To: avt@ietf.org
Date: Tue, 27 Sep 2005 23:27:05 -0700
Message-ID: <OF9A9EB6F5.DA2A4799-ON8825708A.00237080-8825708A.00237091@mindspeed.com>
X-MIMETrack: Serialize by Notes Server on NPBLNM2/Server/Conexant(Release 6.53HF680 | August 17, 2005) at 09/27/2005 23:27:05, Serialize complete at 09/27/2005 23:27:05, Itemize by Notes Server on NPBLNM2/Server/Conexant(Release 6.53HF680 | August 17, 2005) at 09/27/2005 23:27:05, Serialize by Router on NPBLNM2/Server/Conexant(Release 6.53HF680 | August 17, 2005) at 09/27/2005 23:27:05, Itemize by SMTP Server on NPBLNH1/Server/Conexant(Release 6.5.3|September 14, 2004) at 09/27/2005 11:27:06 PM, Serialize by Router on NPBLNH1/Server/Conexant(Release 6.5.3|September 14, 2004) at 09/27/2005 11:27:08 PM, Serialize complete at 09/27/2005 11:27:08 PM
MIME-Version: 1.0
X-Spam-Score: 3.4 (+++)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: michael.beadle@mindspeed.com
Subject: [AVT] 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="===============0410453071=="
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

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