[Megaco] [RTP stream pause & resume]: middleboxes (ITU-T H.248.PAURES)

"Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com> Wed, 22 April 2015 08:36 UTC

Return-Path: <albrecht.schwarz@alcatel-lucent.com>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6DF1B2AA6; Wed, 22 Apr 2015 01:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snoGOv5jRcWU; Wed, 22 Apr 2015 01:36:31 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B0A61B2E36; Wed, 22 Apr 2015 01:35:53 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 3FE4F7BA0BA11; Wed, 22 Apr 2015 08:35:50 +0000 (GMT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t3M8Zn1C021499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Apr 2015 10:35:51 +0200
Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.123]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 22 Apr 2015 10:35:49 +0200
From: "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>
To: "megaco@ietf.org" <megaco@ietf.org>, Christian Groves <Christian.Groves@nteczone.com>, "Yangweiwei (Tommy)" <tommy@huawei.com>
Thread-Topic: [RTP stream pause & resume]: middleboxes (ITU-T H.248.PAURES)
Thread-Index: AdB811TRB4197gUtSO2jI6ZzZli3Aw==
Date: Wed, 22 Apr 2015 08:35:49 +0000
Message-ID: <786615F3A85DF44AA2A76164A71FE1AC7AD725D6@FR711WXCHMBA03.zeu.alcatel-lucent.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.41]
Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC7AD725D6FR711WXCHMBA03z_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/megaco/tstfbonYwHFrk3_fgBEc93t-HZc>
Cc: "avtext@ietf.org" <avtext@ietf.org>
Subject: [Megaco] [RTP stream pause & resume]: middleboxes (ITU-T H.248.PAURES)
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Media Gateway Control <megaco.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/megaco>, <mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/megaco/>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Apr 2015 08:36:33 -0000

Hello Christian,

perhaps you noticed already that we've submitted early contributions based on a review and consideration of specific use cases for H.248 IP-to-IP media gateways (besides the obvious primary scenarios for H.248 media servers).



http://wftp3.itu.int/av-arch/avc-site/2013-2016/1506_Che/1506_Che.html



AVD-4695<http://wftp3.itu.int/av-arch/avc-site/2013-2016/1506_Che/AVD-4695.zip>


3


H.248.PAURES: H.248 use cases and design considerations (clauses 1 to 7)


Alcatel-Lucent


AVD-4696<http://wftp3.itu.int/av-arch/avc-site/2013-2016/1506_Che/AVD-4696.zip>


3


H.248.PAURES: Part II - Package review


Alcatel-Lucent


AVD-4697<http://wftp3.itu.int/av-arch/avc-site/2013-2016/1506_Che/AVD-4697.zip>


3


H.248.PAURES: Part III - Possible interactions with RTP topologies


Alcatel-Lucent






Hello Bo & Azam,

when trying to figure out the exact protocol behaviour in the protocol endpoints of the RTP sender and RTP receiver entities, then we ended always in state models, which essentially allow to concentrate the entire specification "in a single place" (which is so far distribute over clauses 5, 6 and 8).

Thus, Fig. 4 "RTP pause states" is the key part at RTP sender side.

Two comments/questions:

1) the RTP sender state model seems to be not fully complete, thus, supposing that the Fig. just highlights the major state transitions, right?

2) a RTP receiver state model is missing, - why?



FYI: above contribution AVD-4696 provides a new proposed Appendix for ITU-T H.248.PAURES related to state modeling and above questions.



Regards,

Albrecht