From tarun2.gupta@aricent.com  Mon Oct  3 04:37:20 2011
Return-Path: <tarun2.gupta@aricent.com>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5871421F85FF for <megaco@ietfa.amsl.com>; Mon,  3 Oct 2011 04:37:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.739
X-Spam-Level: 
X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UR8ZLdR5PMah for <megaco@ietfa.amsl.com>; Mon,  3 Oct 2011 04:37:15 -0700 (PDT)
Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1E55F21F849A for <megaco@ietf.org>; Mon,  3 Oct 2011 04:37:15 -0700 (PDT)
Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id EF4F536B59 for <megaco@ietf.org>; Mon,  3 Oct 2011 17:04:26 +0530 (IST)
Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (Postfix) with ESMTP id D8DC536B51 for <megaco@ietf.org>; Mon,  3 Oct 2011 17:04:26 +0530 (IST)
Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Mon, 3 Oct 2011 17:10:14 +0530
From: Tarun2 Gupta <tarun2.gupta@aricent.com>
To: "megaco@ietf.org" <megaco@ietf.org>
Date: Mon, 3 Oct 2011 17:10:13 +0530
Thread-Topic: IP Address exhaustion in residential scenarios
Thread-Index: AcyBwTapmy/+GM5fTfOty29oE3RAfw==
Message-ID: <80A9B9A571A97C4993A1772F177352421511BC9B58@GUREXMB01.ASIAN.AD.ARICENT.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_80A9B9A571A97C4993A1772F177352421511BC9B58GUREXMB01ASIA_"
MIME-Version: 1.0
Subject: [Megaco] IP Address exhaustion in residential scenarios
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 03 Oct 2011 11:37:20 -0000

--_000_80A9B9A571A97C4993A1772F177352421511BC9B58GUREXMB01ASIA_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All

Does Megaco offer any solution to IPv4 address space exhaustion in CPE/resi=
dential implementations?

In current architecture, a Softswitch (MGC) communicates with multiple CPEs=
 (MG) over Megaco interface, each having its own public IP address. Since n=
umber of CPEs can be in the order of thousands, there is a risk of IP addre=
ss exhaustion. How do I overcome this?

Regards,
Tarun Gupta
Aricent





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

--_000_80A9B9A571A97C4993A1772F177352421511BC9B58GUREXMB01ASIA_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
hemas-microsoft-com:office:word" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"\@Arial MT";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.MsoBodyText3, li.MsoBodyText3, div.MsoBodyText3
	{margin:0in;
	margin-bottom:.0001pt;
	line-height:12.0pt;
	text-autospace:none;
	font-size:10.0pt;
	font-family:Arial;
	color:blue;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:black;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:651759932;
	mso-list-type:hybrid;
	mso-list-template-ids:603242712 67698703 -1218031332 67698715 67698703 676=
98713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Arial;
	mso-fareast-font-family:"\@Arial MT";}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"Section1">
<p class=3D"MsoNormal"><font size=3D"2" color=3D"black" face=3D"Arial"><spa=
n style=3D"font-size:
10.0pt;font-family:Arial;color:black">Hi All<o:p></o:p></span></font></p>
<p class=3D"MsoNormal"><font size=3D"2" color=3D"black" face=3D"Arial"><spa=
n style=3D"font-size:
10.0pt;font-family:Arial;color:black"><o:p>&nbsp;</o:p></span></font></p>
<p class=3D"MsoNormal"><font size=3D"2" color=3D"black" face=3D"Arial"><spa=
n style=3D"font-size:
10.0pt;font-family:Arial;color:black">Does Megaco offer any solution to IPv=
4 address space exhaustion in CPE/residential implementations?<o:p></o:p></=
span></font></p>
<p class=3D"MsoNormal"><font size=3D"2" color=3D"black" face=3D"Arial"><spa=
n style=3D"font-size:
10.0pt;font-family:Arial;color:black">&nbsp;<o:p></o:p></span></font></p>
<p class=3D"MsoNormal"><font size=3D"2" color=3D"black" face=3D"Arial"><spa=
n style=3D"font-size:
10.0pt;font-family:Arial;color:black">In current architecture, a Softswitch=
 (MGC) communicates with multiple CPEs (MG) over Megaco interface, each hav=
ing its own public
 IP address. Since number of CPEs can be in the order of thousands, there i=
s a risk of IP address exhaustion. How do I overcome this?<o:p></o:p></span=
></font></p>
<p class=3D"MsoNormal"><font size=3D"2" color=3D"black" face=3D"Arial"><spa=
n style=3D"font-size:
10.0pt;font-family:Arial;color:black"><o:p>&nbsp;</o:p></span></font></p>
<p class=3D"MsoNormal"><font size=3D"2" color=3D"black" face=3D"Arial"><spa=
n style=3D"font-size:
10.0pt;font-family:Arial;color:black">Regards,</span></font><font color=3D"=
black"><span style=3D"color:black"><o:p></o:p></span></font></p>
<p class=3D"MsoNormal"><font size=3D"2" color=3D"black" face=3D"Arial"><spa=
n style=3D"font-size:
10.0pt;font-family:Arial;color:black">Tarun Gupta<o:p></o:p></span></font><=
/p>
<p class=3D"MsoNormal"><font size=3D"2" color=3D"black" face=3D"Arial"><spa=
n style=3D"font-size:
10.0pt;font-family:Arial;color:black">Aricent</span></font><o:p></o:p></p>
<p class=3D"MsoNormal"><font size=3D"3" face=3D"Times New Roman"><span styl=
e=3D"font-size:
12.0pt"><o:p>&nbsp;</o:p></span></font></p>
</div>
<br>
<font face=3D"Arial" color=3D"Gray" size=3D"2"><br>
<br>
<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D<br>
Please refer to http://www.aricent.com/legal/email_disclaimer.html<br>
for important disclosures regarding this electronic communication.<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D<br>
</font>
</body>
</html>

--_000_80A9B9A571A97C4993A1772F177352421511BC9B58GUREXMB01ASIA_--

From arindam.bhattacharjee@alcatel-lucent.com  Mon Oct  3 07:03:29 2011
Return-Path: <arindam.bhattacharjee@alcatel-lucent.com>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D343E21F8B56 for <megaco@ietfa.amsl.com>; Mon,  3 Oct 2011 07:03:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOiJyhwWk5Tf for <megaco@ietfa.amsl.com>; Mon,  3 Oct 2011 07:03:25 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id BDCAF21F8B49 for <megaco@ietf.org>; Mon,  3 Oct 2011 07:03:25 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p93E6Ld6008988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Oct 2011 09:06:21 -0500 (CDT)
Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p93E5Nes000643 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 3 Oct 2011 09:06:21 -0500
Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 3 Oct 2011 09:06:19 -0500
From: "Bhattacharjee, Arindam (Arindam)" <arindam.bhattacharjee@alcatel-lucent.com>
To: Tarun2 Gupta <tarun2.gupta@aricent.com>, "megaco@ietf.org" <megaco@ietf.org>
Date: Mon, 3 Oct 2011 09:06:13 -0500
Thread-Topic: IP Address exhaustion in residential scenarios
Thread-Index: AcyBwTapmy/+GM5fTfOty29oE3RAfwAE+BlA
Message-ID: <703C56B521385C4C9091299BE82357B7EE367324@USNAVSXCHMBSA2.ndc.alcatel-lucent.com>
References: <80A9B9A571A97C4993A1772F177352421511BC9B58@GUREXMB01.ASIAN.AD.ARICENT.COM>
In-Reply-To: <80A9B9A571A97C4993A1772F177352421511BC9B58@GUREXMB01.ASIAN.AD.ARICENT.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_703C56B521385C4C9091299BE82357B7EE367324USNAVSXCHMBSA2n_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Subject: Re: [Megaco] IP Address exhaustion in residential scenarios
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 03 Oct 2011 14:03:29 -0000

--_000_703C56B521385C4C9091299BE82357B7EE367324USNAVSXCHMBSA2n_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Tarun,
Megaco is transport mode independent protocol, in general
H248.67 defines packages for various transport modes supported by H.248.

I think in your case you need upgrades from your MGC and MG vendors to have=
 IPv6 support for megaco interface.

-Arindam

From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of=
 Tarun2 Gupta
Sent: Monday, October 03, 2011 7:40 AM
To: megaco@ietf.org
Subject: [Megaco] IP Address exhaustion in residential scenarios

Hi All

Does Megaco offer any solution to IPv4 address space exhaustion in CPE/resi=
dential implementations?

In current architecture, a Softswitch (MGC) communicates with multiple CPEs=
 (MG) over Megaco interface, each having its own public IP address. Since n=
umber of CPEs can be in the order of thousands, there is a risk of IP addre=
ss exhaustion. How do I overcome this?

Regards,
Tarun Gupta
Aricent





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

--_000_703C56B521385C4C9091299BE82357B7EE367324USNAVSXCHMBSA2n_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
p.MsoBodyText3, li.MsoBodyText3, div.MsoBodyText3
	{mso-style-priority:99;
	mso-style-link:"Body Text 3 Char";
	margin:0in;
	margin-bottom:.0001pt;
	line-height:12.0pt;
	text-autospace:none;
	font-size:10.0pt;
	font-family:"Arial","sans-serif";
	color:blue;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.BodyText3Char
	{mso-style-name:"Body Text 3 Char";
	mso-style-priority:99;
	mso-style-link:"Body Text 3";
	font-family:"Calibri","sans-serif";}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:black;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Hi Tarun,<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Megaco is transport mode independent protocol, in general<o:=
p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>H248.67 defines packages for various transport modes support=
ed
by H.248.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>I think in your case you need upgrades from your MGC and MG
vendors to have IPv6 support for megaco interface.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>-Arindam<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] <b>On Behalf Of </=
b>Tarun2
Gupta<br>
<b>Sent:</b> Monday, October 03, 2011 7:40 AM<br>
<b>To:</b> megaco@ietf.org<br>
<b>Subject:</b> [Megaco] IP Address exhaustion in residential scenarios<o:p=
></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif";
color:black'>Hi All<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif";
color:black'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif";
color:black'>Does Megaco offer any solution to IPv4 address space exhaustio=
n in
CPE/residential implementations?<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif";
color:black'>&nbsp;<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif";
color:black'>In current architecture, a Softswitch (MGC) communicates with
multiple CPEs (MG) over Megaco interface, each having its own public IP
address. Since number of CPEs can be in the order of thousands, there is a =
risk
of IP address exhaustion. How do I overcome this?<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif";
color:black'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif";
color:black'>Regards,</span><span style=3D'color:black'><o:p></o:p></span><=
/p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif";
color:black'>Tarun Gupta<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif";
color:black'>Aricent</span><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:gray=
'><br>
<br>
<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D<br>
Please refer to http://www.aricent.com/legal/email_disclaimer.html<br>
for important disclosures regarding this electronic communication.<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D</span><o:p></o:p></p>

</div>

</body>

</html>

--_000_703C56B521385C4C9091299BE82357B7EE367324USNAVSXCHMBSA2n_--

From Raju.Makaraju@alcatel-lucent.com  Mon Oct  3 08:36:51 2011
Return-Path: <Raju.Makaraju@alcatel-lucent.com>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B871D21F8B8F for <megaco@ietfa.amsl.com>; Mon,  3 Oct 2011 08:36:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flKMesis8Uky for <megaco@ietfa.amsl.com>; Mon,  3 Oct 2011 08:36:47 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id A2DD821F8B8C for <megaco@ietf.org>; Mon,  3 Oct 2011 08:36:47 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p93Fdh5e007617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Oct 2011 10:39:44 -0500 (CDT)
Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p93FdhK0002251 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 3 Oct 2011 10:39:43 -0500
Received: from USNAVSXCHMBSD3.ndc.alcatel-lucent.com ([135.3.39.155]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 3 Oct 2011 10:39:43 -0500
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: "Bhattacharjee, Arindam (Arindam)" <arindam.bhattacharjee@alcatel-lucent.com>, Tarun2 Gupta <tarun2.gupta@aricent.com>, "megaco@ietf.org" <megaco@ietf.org>
Date: Mon, 3 Oct 2011 10:39:40 -0500
Thread-Topic: IP Address exhaustion in residential scenarios
Thread-Index: AcyBwTapmy/+GM5fTfOty29oE3RAfwAE+BlAAAMj5PA=
Message-ID: <31939CE9629A7F46885A9F97CEA9BF577B540920@USNAVSXCHMBSD3.ndc.alcatel-lucent.com>
References: <80A9B9A571A97C4993A1772F177352421511BC9B58@GUREXMB01.ASIAN.AD.ARICENT.COM> <703C56B521385C4C9091299BE82357B7EE367324@USNAVSXCHMBSA2.ndc.alcatel-lucent.com>
In-Reply-To: <703C56B521385C4C9091299BE82357B7EE367324@USNAVSXCHMBSA2.ndc.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_31939CE9629A7F46885A9F97CEA9BF577B540920USNAVSXCHMBSD3n_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Subject: Re: [Megaco] IP Address exhaustion in residential scenarios
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 03 Oct 2011 15:36:51 -0000

--_000_31939CE9629A7F46885A9F97CEA9BF577B540920USNAVSXCHMBSD3n_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Tarun,

VLANs can be used to have overlapped IP address space.
VLAN ids in signaling interface (NOT the bearer, for which there is a VLAN =
pkg H.248.56) is outside the scope of h.248 recommendation.
However, identification of each RGW (with same ip but different VLAN) can b=
e done on MGC using MID (in H.248 msg hdr).

Best Regards
Raju

________________________________
From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of=
 Bhattacharjee, Arindam (Arindam)
Sent: Monday, October 03, 2011 9:06 AM
To: Tarun2 Gupta; megaco@ietf.org
Subject: Re: [Megaco] IP Address exhaustion in residential scenarios

Hi Tarun,
Megaco is transport mode independent protocol, in general
H248.67 defines packages for various transport modes supported by H.248.

I think in your case you need upgrades from your MGC and MG vendors to have=
 IPv6 support for megaco interface.

-Arindam

From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of=
 Tarun2 Gupta
Sent: Monday, October 03, 2011 7:40 AM
To: megaco@ietf.org
Subject: [Megaco] IP Address exhaustion in residential scenarios

Hi All

Does Megaco offer any solution to IPv4 address space exhaustion in CPE/resi=
dential implementations?

In current architecture, a Softswitch (MGC) communicates with multiple CPEs=
 (MG) over Megaco interface, each having its own public IP address. Since n=
umber of CPEs can be in the order of thousands, there is a risk of IP addre=
ss exhaustion. How do I overcome this?

Regards,
Tarun Gupta
Aricent





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

--_000_31939CE9629A7F46885A9F97CEA9BF577B540920USNAVSXCHMBSD3n_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:x =3D=20
"urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20
"urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20
"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20
"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20
"urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b =3D=
=20
"urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20
"urn:schemas-microsoft-com:office:spreadsheet" xmlns:c =3D=20
"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc =3D=20
"urn:schemas-microsoft-com:office:odc" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:html =3D=20
"http://www.w3.org/TR/REC-html40" xmlns:q =3D=20
"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc =3D=20
"http://microsoft.com/officenet/conferencing" XMLNS:D =3D "DAV:" XMLNS:Repl=
 =3D=20
"http://schemas.microsoft.com/repl/" xmlns:mt =3D=20
"http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2 =3D=20
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda =3D=20
"http://www.passport.com/NameSpace.xsd" xmlns:ois =3D=20
"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir =3D=20
"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds =3D=20
"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp =3D=20
"http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc =3D=20
"http://schemas.microsoft.com/data/udc" xmlns:xsd =3D=20
"http://www.w3.org/2001/XMLSchema" xmlns:sub =3D=20
"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec =3D=
=20
"http://www.w3.org/2001/04/xmlenc#" xmlns:sp =3D=20
"http://schemas.microsoft.com/sharepoint/" xmlns:sps =3D=20
"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi =3D=20
"http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs =3D=20
"http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf =3D=20
"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p =3D=20
"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf =3D=20
"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss =3D=20
"http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi =3D=20
"http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi =3D=20
"http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mv=
er =3D=20
"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m =3D=20
"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels =3D=20
"http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp =
=3D=20
"http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t =3D=20
"http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m =3D=
=20
"http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl =
=3D=20
"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl =3D=
=20
"http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksServ=
ice"=20
XMLNS:Z =3D "urn:schemas-microsoft-com:" xmlns:st =3D "=01"><HEAD>
<META content=3D"text/html; charset=3Dus-ascii" http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.19120">
<STYLE>@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"; FONT-SIZE: 12=
pt
}
LI.MsoNormal {
	MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"; FONT-SIZE: 12=
pt
}
DIV.MsoNormal {
	MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"; FONT-SIZE: 12=
pt
}
P.MsoBodyText3 {
	LINE-HEIGHT: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Arial","sans-serif";=
 COLOR: blue; FONT-SIZE: 10pt; mso-style-priority: 99; mso-style-link: "Bod=
y Text 3 Char"
}
LI.MsoBodyText3 {
	LINE-HEIGHT: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Arial","sans-serif";=
 COLOR: blue; FONT-SIZE: 10pt; mso-style-priority: 99; mso-style-link: "Bod=
y Text 3 Char"
}
DIV.MsoBodyText3 {
	LINE-HEIGHT: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Arial","sans-serif";=
 COLOR: blue; FONT-SIZE: 10pt; mso-style-priority: 99; mso-style-link: "Bod=
y Text 3 Char"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.BodyText3Char {
	FONT-FAMILY: "Calibri","sans-serif"; mso-style-priority: 99; mso-style-lin=
k: "Body Text 3"; mso-style-name: "Body Text 3 Char"
}
SPAN.EmailStyle19 {
	FONT-STYLE: normal; FONT-FAMILY: "Arial","sans-serif"; COLOR: black; FONT-=
WEIGHT: normal; TEXT-DECORATION: none; mso-style-type: personal
}
SPAN.EmailStyle20 {
	FONT-FAMILY: "Calibri","sans-serif"; COLOR: #1f497d; mso-style-type: perso=
nal-reply
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US link=3Dblue vLink=3Dpurple>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D003253215-03102011><FONT color=3D=
#0000ff=20
size=3D2 face=3DArial>Tarun,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D003253215-03102011><FONT color=3D=
#0000ff=20
size=3D2 face=3DArial></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D003253215-03102011><FONT color=3D=
#0000ff=20
size=3D2 face=3DArial>VLANs can be used to have overlapped IP address=20
space.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D003253215-03102011><FONT color=3D=
#0000ff=20
size=3D2 face=3DArial>VLAN ids in signaling interface (NOT the bearer,&nbsp=
;for=20
which there is a VLAN pkg H.248.56)&nbsp;is outside the scope of h.248=20
recommendation.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D003253215-03102011><FONT color=3D=
#0000ff=20
size=3D2 face=3DArial>However, identification of each RGW (with same ip but=
=20
different VLAN) can be done on MGC using MID (in H.248 msg=20
hdr).</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D003253215-03102011><FONT color=3D=
#0000ff=20
size=3D2 face=3DArial></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D003253215-03102011><FONT color=3D=
#0000ff=20
size=3D2 face=3DArial>Best Regards</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D003253215-03102011><FONT color=3D=
#0000ff=20
size=3D2 face=3DArial>Raju</FONT>&nbsp;</SPAN></DIV><BR>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5p=
x; MARGIN-RIGHT: 0px"=20
dir=3Dltr>
  <DIV dir=3Dltr lang=3Den-us class=3DOutlookMessageHeader align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT size=3D2 face=3DTahoma><B>From:</B> megaco-bounces@ietf.org=20
  [mailto:megaco-bounces@ietf.org] <B>On Behalf Of </B>Bhattacharjee, Arind=
am=20
  (Arindam)<BR><B>Sent:</B> Monday, October 03, 2011 9:06 AM<BR><B>To:</B>=
=20
  Tarun2 Gupta; megaco@ietf.org<BR><B>Subject:</B> Re: [Megaco] IP Address=
=20
  exhaustion in residential scenarios<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: =
11pt">Hi=20
  Tarun,<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: =
11pt">Megaco=20
  is transport mode independent protocol, in general<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: =
11pt">H248.67=20
  defines packages for various transport modes supported by=20
  H.248.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: =
11pt"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: =
11pt">I=20
  think in your case you need upgrades from your MGC and MG vendors to have=
 IPv6=20
  support for megaco interface.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: =
11pt"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: =
11pt">-Arindam<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: =
11pt"><o:p>&nbsp;</o:p></SPAN></P>
  <DIV>
  <DIV=20
  style=3D"BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BO=
TTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt s=
olid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
  <P class=3DMsoNormal><B><SPAN=20
  style=3D"FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt">From:</SPAN=
></B><SPAN=20
  style=3D"FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt">=20
  megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] <B>On Behalf Of=
=20
  </B>Tarun2 Gupta<BR><B>Sent:</B> Monday, October 03, 2011 7:40=20
  AM<BR><B>To:</B> megaco@ietf.org<BR><B>Subject:</B> [Megaco] IP Address=20
  exhaustion in residential scenarios<o:p></o:p></SPAN></P></DIV></DIV>
  <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: black; FONT-SIZE: 10pt=
">Hi=20
  All<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: black; FONT-SIZE: 10pt=
"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: black; FONT-SIZE: 10pt=
">Does=20
  Megaco offer any solution to IPv4 address space exhaustion in CPE/residen=
tial=20
  implementations?<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: black; FONT-SIZE: 10pt=
">&nbsp;<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: black; FONT-SIZE: 10pt=
">In=20
  current architecture, a Softswitch (MGC) communicates with multiple CPEs =
(MG)=20
  over Megaco interface, each having its own public IP address. Since numbe=
r of=20
  CPEs can be in the order of thousands, there is a risk of IP address=20
  exhaustion. How do I overcome this?<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: black; FONT-SIZE: 10pt=
"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: black; FONT-SIZE: 10pt=
">Regards,</SPAN><SPAN=20
  style=3D"COLOR: black"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: black; FONT-SIZE: 10pt=
">Tarun=20
  Gupta<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: black; FONT-SIZE: 10pt=
">Aricent</SPAN><o:p></o:p></P>
  <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
  <P class=3DMsoNormal><BR><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: gray; FONT-SIZE: 10pt"=
><BR><BR><BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>Please=20
  refer to http://www.aricent.com/legal/email_disclaimer.html<BR>for import=
ant=20
  disclosures regarding this electronic=20
  communication.<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN><o:p></o:p></P></DIV></BLOCKQUOTE><=
/BODY></HTML>

--_000_31939CE9629A7F46885A9F97CEA9BF577B540920USNAVSXCHMBSD3n_--

From javi@trajano.us.es  Fri Oct 14 03:28:53 2011
Return-Path: <javi@trajano.us.es>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37CD21F8B9C for <megaco@ietfa.amsl.com>; Fri, 14 Oct 2011 03:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZAg3d80vnYL for <megaco@ietfa.amsl.com>; Fri, 14 Oct 2011 03:28:53 -0700 (PDT)
Received: from mail.us.es (mail.us.es [193.147.175.20]) by ietfa.amsl.com (Postfix) with ESMTP id CB02A21F8B44 for <megaco@ietf.org>; Fri, 14 Oct 2011 03:28:52 -0700 (PDT)
Received: (qmail 30742 invoked from network); 14 Oct 2011 12:28:50 +0200
Received: from unknown (HELO us.es) (192.168.2.13) by us.es with SMTP; 14 Oct 2011 12:28:50 +0200
Received: (qmail 19526 invoked by uid 507); 14 Oct 2011 10:28:49 -0000
Received: from 127.0.0.1 by antivirus3 (envelope-from <javi@trajano.us.es>, uid 501) with qmail-scanner-2.08 (clamdscan: 0.97.2/13798.   Clear:RC:1(127.0.0.1):.  Processed in 0.031911 secs); 14 Oct 2011 10:28:49 -0000
Received: from unknown (HELO antivirus3) (127.0.0.1) by us.es with SMTP; 14 Oct 2011 10:28:49 -0000
Received: from 192.168.1.13 (192.168.1.13) by antivirus3 (F-Secure/fsigk_smtp/406/antivirus3); Fri, 14 Oct 2011 12:28:49 +0200 (CEST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/406/antivirus3)
Received: (qmail 32552 invoked from network); 14 Oct 2011 12:28:49 +0200
Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 14 Oct 2011 12:28:49 +0200
Received: from [193.147.162.138] (adriano.us.es [193.147.162.138]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id p9EASmJ6019927 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 14 Oct 2011 12:28:48 +0200
Message-ID: <4E980EF1.4020407@trajano.us.es>
Date: Fri, 14 Oct 2011 12:29:05 +0200
From: =?ISO-8859-1?Q?Javi_Mu=F1oz?= <javi@trajano.us.es>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: "megaco@ietf.org" <megaco@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Example of MeGaco messages for Multiplex terminations
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 14 Oct 2011 10:28:53 -0000

Hi,

I have read that a multiplexing termination hides all of the 
terminations it contains from the rest of the context, so the streamIDs 
of the streams flowing between the contained terminations and the 
multiplexing termination are local rather than global in scope.

If e have the following situation:

                         Context interior ---->
                     _________                 _________
        Data stream  | H.226 |                 | H.223 |   Audio stream
Ckt 1 ..............| "MUX" |                 |  MUX  | .................
        . . .        | term  |   Data stream   | term  |
        Data stream  |       | ................|       |   Video stream
Ckt n ..............|       |                 |       | .................
                     |       |                 |       |
                     ---------                 ---------

How we know that the stream between the H.226 and H.223 multiplexing 
terminations is a data stream, while the streams passing from the H.223 
termination to the rest of the context are audio and video?. I think we 
need an explicit description of the exterior-side and context-side 
streams supported by each multiplex somewhere within our Megaco/H.248 
documentation but, how may it be indicated in a MeGaCo meesage?

Also, if we want to use separate RTP terminations for audio and video, I 
need to be able to tell that mux stream 1 shall be mapped to RTP 
termination T3, and stream 2 into RTP termination T4. How may it be 
indicated?


In summary, may someone propose the full MeGaCo messages to create this 
scenario with multiplex terminations?


From claudio.fontana@gmail.com  Fri Oct 14 04:27:26 2011
Return-Path: <claudio.fontana@gmail.com>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8242521F8B16 for <megaco@ietfa.amsl.com>; Fri, 14 Oct 2011 04:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTwXQimJxpgy for <megaco@ietfa.amsl.com>; Fri, 14 Oct 2011 04:27:26 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 33A6A21F8B07 for <megaco@ietf.org>; Fri, 14 Oct 2011 04:27:21 -0700 (PDT)
Received: by eyg24 with SMTP id 24so1098447eyg.31 for <megaco@ietf.org>; Fri, 14 Oct 2011 04:27:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4yOCKeplFMkdi98YqH+n8aONv5f3ug5INwua0NtK4XY=; b=YcOcuZMBwDEksgwk8g/c1BFF3JPDzuz9ON78Nz390+ADPO9T9AOGEfR0eX/NFkQ7ht qHk2xtnqXD7D4TzuM4odUPHUA+KqlQAcd7vGyP2Imfq8R7zfP1eWO2LIwHnPIx+Ygktm TWLXIIA5+EG3wxvcoqZwHl8B8nMgSFyKjnRD4=
Received: by 10.223.62.15 with SMTP id v15mr3546364fah.22.1318591640313; Fri, 14 Oct 2011 04:27:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.96.71 with HTTP; Fri, 14 Oct 2011 04:27:00 -0700 (PDT)
In-Reply-To: <4E980EF1.4020407@trajano.us.es>
References: <4E980EF1.4020407@trajano.us.es>
From: Claudio Fontana <claudio.fontana@gmail.com>
Date: Fri, 14 Oct 2011 13:27:00 +0200
Message-ID: <CAJuRt+oqTeEU_sKrsyAcnBHteji+g2+_e4x1GRdbJsY_WEdEiQ@mail.gmail.com>
To: =?ISO-8859-1?Q?Javi_Mu=F1oz?= <javi@trajano.us.es>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "megaco@ietf.org" <megaco@ietf.org>
Subject: Re: [Megaco] Example of MeGaco messages for Multiplex terminations
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 14 Oct 2011 11:27:26 -0000

My answer might be OT for this list, but remember that if you are
using megaco for voice in a 3gpp network, multiplexed terminations are
not supported in any of the 3gpp releases.

ref: 29.232 C.6.2 "Multiplexed terminations"

From javi@trajano.us.es  Fri Oct 14 05:00:19 2011
Return-Path: <javi@trajano.us.es>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC7421F8726 for <megaco@ietfa.amsl.com>; Fri, 14 Oct 2011 05:00:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLZxcFL-bqjg for <megaco@ietfa.amsl.com>; Fri, 14 Oct 2011 05:00:19 -0700 (PDT)
Received: from mail.us.es (mail.us.es [193.147.175.20]) by ietfa.amsl.com (Postfix) with ESMTP id 896B221F8B35 for <megaco@ietf.org>; Fri, 14 Oct 2011 05:00:18 -0700 (PDT)
Received: (qmail 4740 invoked from network); 14 Oct 2011 14:00:17 +0200
Received: from unknown (HELO us.es) (192.168.2.11) by us.es with SMTP; 14 Oct 2011 14:00:17 +0200
Received: (qmail 4254 invoked by uid 507); 14 Oct 2011 12:00:06 -0000
Received: from 127.0.0.1 by antivirus1 (envelope-from <javi@trajano.us.es>, uid 501) with qmail-scanner-2.08 (clamdscan: 0.97.2/13798.   Clear:RC:1(127.0.0.1):.  Processed in 0.039051 secs); 14 Oct 2011 12:00:06 -0000
Received: from unknown (HELO antivirus1) (127.0.0.1) by us.es with SMTP; 14 Oct 2011 12:00:06 -0000
Received: from 192.168.1.13 (192.168.1.13) by antivirus1 (F-Secure/fsigk_smtp/406/antivirus1); Fri, 14 Oct 2011 14:00:06 +0200 (CEST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/406/antivirus1)
Received: (qmail 29425 invoked from network); 14 Oct 2011 14:00:06 +0200
Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 14 Oct 2011 14:00:06 +0200
Received: from [193.147.162.138] (adriano.us.es [193.147.162.138]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id p9EC05P4021585 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 14 Oct 2011 14:00:06 +0200
Message-ID: <4E982456.7080001@trajano.us.es>
Date: Fri, 14 Oct 2011 14:00:22 +0200
From: =?ISO-8859-1?Q?Javi_Mu=F1oz?= <javi@trajano.us.es>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: "megaco@ietf.org" <megaco@ietf.org>
References: <4E980EF1.4020407@trajano.us.es> <CAJuRt+oqTeEU_sKrsyAcnBHteji+g2+_e4x1GRdbJsY_WEdEiQ@mail.gmail.com>
In-Reply-To: <CAJuRt+oqTeEU_sKrsyAcnBHteji+g2+_e4x1GRdbJsY_WEdEiQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Claudio Fontana <claudio.fontana@gmail.com>
Subject: Re: [Megaco] Example of MeGaco messages for Multiplex terminations
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 14 Oct 2011 12:00:19 -0000

El 14/10/2011 13:27, Claudio Fontana escribió:
> My answer might be OT for this list, but remember that if you are
> using megaco for voice in a 3gpp network, multiplexed terminations are
> not supported in any of the 3gpp releases.
>
> ref: 29.232 C.6.2 "Multiplexed terminations"
>
In my case (supporting of Nx64 multichannel calls), these terminations 
are the only solution. So, I need to build de MeGaco messages to create 
them.

From albrecht.schwarz@alcatel-lucent.com  Fri Oct 14 05:45:58 2011
Return-Path: <albrecht.schwarz@alcatel-lucent.com>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A07921F84BA for <megaco@ietfa.amsl.com>; Fri, 14 Oct 2011 05:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.374
X-Spam-Level: 
X-Spam-Status: No, score=-5.374 tagged_above=-999 required=5 tests=[AWL=0.575,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHiuVZjjLy-K for <megaco@ietfa.amsl.com>; Fri, 14 Oct 2011 05:45:58 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id B018B21F84B8 for <megaco@ietf.org>; Fri, 14 Oct 2011 05:45:57 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p9EChmUo023759 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 14 Oct 2011 14:45:52 +0200
Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.50]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 14 Oct 2011 14:45:26 +0200
From: "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>
To: =?iso-8859-1?Q?Javi_Mu=F1oz?= <javi@trajano.us.es>, "megaco@ietf.org" <megaco@ietf.org>, Christian Groves <Christian.Groves@NTECZONE.COM>
Date: Fri, 14 Oct 2011 14:45:23 +0200
Thread-Topic: [Megaco] Example of MeGaco messages for Multiplex terminations
Thread-Index: AcyKaN3fM2bGLNz9RTOS6rzyZLvp1gABMmrQ
Message-ID: <5F7BCCF5541B7444830A2288ABBEBC962160D26A45@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com>
References: <4E980EF1.4020407@trajano.us.es> <CAJuRt+oqTeEU_sKrsyAcnBHteji+g2+_e4x1GRdbJsY_WEdEiQ@mail.gmail.com> <4E982456.7080001@trajano.us.es>
In-Reply-To: <4E982456.7080001@trajano.us.es>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Cc: Claudio Fontana <claudio.fontana@gmail.com>
Subject: Re: [Megaco] Example of MeGaco messages for Multiplex terminations
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 14 Oct 2011 12:45:58 -0000

Question for clarifications:
the right hand side seems to be not any multimedia-over-H.223 service (due =
to separate ephemeral terminations for audio & video), rather multimedia-ov=
er-packet like H.323 or SIP.

Is my assumption correct that the left hand side relates to a protocol stac=
k like=20
{Audio, Video}-over-H.324/H.226/H.223-over-N x Channels, right?

Thus, there would be then two levels of multiplexing, H.226 & H.223, right?

You did select for each a Mux termination, which logically belong both to t=
he left side of the Context.=20
[The right hand side should look like Figure 6/H.248.1, i.e., there wouldn'=
t be any Mux termination at the right hand side.]

It looks like that your use case is addressed by H.248.1, =A7 6.2:
"Multiplexing terminations may be cascades (e.g., H.226 multiplex of digita=
l channels feeding into a H.223 multiplex supporting an H.324 session)."

Thus, cascades are allowed, but I'm not really familiar with the MuxType el=
ement.

Christian,
do you know the syntax for creating Mux terminations with hierarchical mult=
iplexing levels?

BR,
Albrecht


> -----Original Message-----
> From: megaco-bounces@ietf.org=20
> [mailto:megaco-bounces@ietf.org] On Behalf Of Javi Mu=F1oz
> Sent: Freitag, 14. Oktober 2011 14:00
> To: megaco@ietf.org
> Cc: Claudio Fontana
> Subject: Re: [Megaco] Example of MeGaco messages for=20
> Multiplex terminations
>=20
> El 14/10/2011 13:27, Claudio Fontana escribi=F3:
> > My answer might be OT for this list, but remember that if you are=20
> > using megaco for voice in a 3gpp network, multiplexed=20
> terminations are=20
> > not supported in any of the 3gpp releases.
> >
> > ref: 29.232 C.6.2 "Multiplexed terminations"
> >
> In my case (supporting of Nx64 multichannel calls), these=20
> terminations are the only solution. So, I need to build de=20
> MeGaco messages to create them.
>=20
_______________________________________________
-----Original Message-----
From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of=
 Javi Mu=F1oz
Sent: Freitag, 14. Oktober 2011 12:29
To: megaco@ietf.org
Subject: [Megaco] Example of MeGaco messages for Multiplex terminations

Hi,

I have read that a multiplexing termination hides all of the terminations i=
t contains from the rest of the context, so the streamIDs of the streams fl=
owing between the contained terminations and the multiplexing termination a=
re local rather than global in scope.

If e have the following situation:

                         Context interior ---->
                     _________                 _________
        Data stream  | H.226 |                 | H.223 |   Audio stream
Ckt 1 ..............| "MUX" |                 |  MUX  | .................
        . . .        | term  |   Data stream   | term  |
        Data stream  |       | ................|       |   Video stream
Ckt n ..............|       |                 |       | .................
                     |       |                 |       |
                     ---------                 ---------

How we know that the stream between the H.226 and H.223 multiplexing termin=
ations is a data stream, while the streams passing from the H.223 terminati=
on to the rest of the context are audio and video?. I think we need an expl=
icit description of the exterior-side and context-side streams supported by=
 each multiplex somewhere within our Megaco/H.248 documentation but, how ma=
y it be indicated in a MeGaCo meesage?

Also, if we want to use separate RTP terminations for audio and video, I ne=
ed to be able to tell that mux stream 1 shall be mapped to RTP termination =
T3, and stream 2 into RTP termination T4. How may it be indicated?


In summary, may someone propose the full MeGaCo messages to create this sce=
nario with multiplex terminations?

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www.ietf.org/mailman/listinfo/megaco> =

From tom111.taylor@bell.net  Sun Oct 16 12:13:24 2011
Return-Path: <tom111.taylor@bell.net>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6F121F8538 for <megaco@ietfa.amsl.com>; Sun, 16 Oct 2011 12:13:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.496
X-Spam-Level: 
X-Spam-Status: No, score=-101.496 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5dxCJCpO819 for <megaco@ietfa.amsl.com>; Sun, 16 Oct 2011 12:13:23 -0700 (PDT)
Received: from blu0-omc2-s21.blu0.hotmail.com (blu0-omc2-s21.blu0.hotmail.com [65.55.111.96]) by ietfa.amsl.com (Postfix) with ESMTP id 314ED21F85EF for <megaco@ietf.org>; Sun, 16 Oct 2011 12:13:23 -0700 (PDT)
Received: from BLU0-SMTP5 ([65.55.111.73]) by blu0-omc2-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 16 Oct 2011 12:13:22 -0700
X-Originating-IP: [69.158.64.45]
X-Originating-Email: [tom111.taylor@bell.net]
Message-ID: <BLU0-SMTP5B76027A65AB404533C34D8E70@phx.gbl>
Received: from [192.168.2.17] ([69.158.64.45]) by BLU0-SMTP5.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 16 Oct 2011 12:13:21 -0700
Date: Sun, 16 Oct 2011 15:13:19 -0400
From: Tom Taylor <tom111.taylor@bell.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Javi_Mu=F1oz?= <javi@trajano.us.es>
References: <4E980EF1.4020407@trajano.us.es>
In-Reply-To: <4E980EF1.4020407@trajano.us.es>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 16 Oct 2011 19:13:21.0887 (UTC) FILETIME=[ABB6B6F0:01CC8C37]
Cc: "megaco@ietf.org" <megaco@ietf.org>
Subject: Re: [Megaco] Example of MeGaco messages for Multiplex terminations
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Sun, 16 Oct 2011 19:13:24 -0000

Start with H.248.1v3/clause 6.2. That should give you some idea of how 
to construct the syntax. Details for the MUX descriptor are given in 
clause 7.1.3. I can put the whole picture together for you if you have 
trouble, but I should warn you that my views differ from those published 
as H.248.20.

On 14/10/2011 6:29 AM, Javi Muñoz wrote:
> Hi,
>
> I have read that a multiplexing termination hides all of the
> terminations it contains from the rest of the context, so the streamIDs
> of the streams flowing between the contained terminations and the
> multiplexing termination are local rather than global in scope.
>
> If e have the following situation:
>
> Context interior ---->
> _________ _________
> Data stream | H.226 | | H.223 | Audio stream
> Ckt 1 ..............| "MUX" | | MUX | .................
> . . . | term | Data stream | term |
> Data stream | | ................| | Video stream
> Ckt n ..............| | | | .................
> | | | |
> --------- ---------
>
> How we know that the stream between the H.226 and H.223 multiplexing
> terminations is a data stream, while the streams passing from the H.223
> termination to the rest of the context are audio and video?. I think we
> need an explicit description of the exterior-side and context-side
> streams supported by each multiplex somewhere within our Megaco/H.248
> documentation but, how may it be indicated in a MeGaCo meesage?
>
> Also, if we want to use separate RTP terminations for audio and video, I
> need to be able to tell that mux stream 1 shall be mapped to RTP
> termination T3, and stream 2 into RTP termination T4. How may it be
> indicated?
>
>
> In summary, may someone propose the full MeGaCo messages to create this
> scenario with multiplex terminations?
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
>
>

From Christian.Groves@nteczone.com  Sun Oct 16 20:15:00 2011
Return-Path: <Christian.Groves@nteczone.com>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269AF21F84ED for <megaco@ietfa.amsl.com>; Sun, 16 Oct 2011 20:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.124
X-Spam-Level: 
X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.175,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39knvLn47PIf for <megaco@ietfa.amsl.com>; Sun, 16 Oct 2011 20:14:59 -0700 (PDT)
Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 027A821F84E5 for <megaco@ietf.org>; Sun, 16 Oct 2011 20:14:58 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApMBAJSbm0520VkT/2dsb2JhbAAMNqtVAQEBBAEBASQLAQUbGwoBDAQLEQQBAQEJFggHCQMCAQIBFR8JCAYNAQUCAQEXh2y0GQSICASlZA
Received: from ppp118-209-89-19.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.89.19]) by ipmail06.adl6.internode.on.net with ESMTP; 17 Oct 2011 13:44:55 +1030
Message-ID: <4E9B9DAE.1050908@nteczone.com>
Date: Mon, 17 Oct 2011 14:14:54 +1100
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Javi_Mu=F1oz?= <javi@trajano.us.es>
References: <4E980EF1.4020407@trajano.us.es> <CAJuRt+oqTeEU_sKrsyAcnBHteji+g2+_e4x1GRdbJsY_WEdEiQ@mail.gmail.com> <4E982456.7080001@trajano.us.es> <5F7BCCF5541B7444830A2288ABBEBC962160D26A45@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com>
In-Reply-To: <5F7BCCF5541B7444830A2288ABBEBC962160D26A45@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "megaco@ietf.org" <megaco@ietf.org>, Claudio Fontana <claudio.fontana@gmail.com>
Subject: Re: [Megaco] Example of MeGaco messages for Multiplex terminations
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 17 Oct 2011 03:15:00 -0000

Hello Javi,

Have you looked at H.248.20 "The use of local and remote descriptors 
with H.221 and H.223 multiplexing" and also H.248.12 "H.248.1 packages 
for H.323 and H.324 interworking" both these give examples.

I don't think its really a syntax issue, more of a modelling one and 
understanding how Terminations and Streams map.

I think the termination model you need is something like in a single 
Context (6 Terminations):

        Tmux1=Mux(H.226(TermA,TermB))  Tmux2=Mux(H.223(Tmux1))
                  |                       |
TermA (Ckt1)  ---|-----------------------|----------- TermC (RTP)
TermB (Ckt1)  ---|                       |----------- TermD (RTP)
                  |                       |

In terms of Streams for TermA, TermB and Tmux1 you could simply use a 
single stream with StreamID=1. For Tmux2 it would have the same number 
of streams as the number of media related logical channels. I.e. for 
audio and video it would be two streams, the audio stream with 
StreamID=2 and the video stream with StreamID=3. I've avoided using 
StreamID=1 in TermC and TermD to avoid confusion. See H.248.12 about 
using logical channel number to map between streamIDs and logical channels.
If you then want to have different RTP media in different terminations 
then you simply assign the StreamID to the Termination you want. i.e. 
for audio TermC could be assigned StreamID=2 and for video TermD could 
be assigned StreamID=3. Alternatively TermC and/or TermC could be 
assigned StreamIDs 2&3 for both media.

Regards, Christian

On 14/10/2011 11:45 PM, Schwarz, Albrecht (Albrecht) wrote:
> Question for clarifications:
> the right hand side seems to be not any multimedia-over-H.223 service (due to separate ephemeral terminations for audio&  video), rather multimedia-over-packet like H.323 or SIP.
>
> Is my assumption correct that the left hand side relates to a protocol stack like
> {Audio, Video}-over-H.324/H.226/H.223-over-N x Channels, right?
>
> Thus, there would be then two levels of multiplexing, H.226&  H.223, right?
>
> You did select for each a Mux termination, which logically belong both to the left side of the Context.
> [The right hand side should look like Figure 6/H.248.1, i.e., there wouldn't be any Mux termination at the right hand side.]
>
> It looks like that your use case is addressed by H.248.1, § 6.2:
> "Multiplexing terminations may be cascades (e.g., H.226 multiplex of digital channels feeding into a H.223 multiplex supporting an H.324 session)."
>
> Thus, cascades are allowed, but I'm not really familiar with the MuxType element.
>
> Christian,
> do you know the syntax for creating Mux terminations with hierarchical multiplexing levels?
>
> BR,
> Albrecht
>
>
>> -----Original Message-----
>> From: megaco-bounces@ietf.org
>> [mailto:megaco-bounces@ietf.org] On Behalf Of Javi Muñoz
>> Sent: Freitag, 14. Oktober 2011 14:00
>> To: megaco@ietf.org
>> Cc: Claudio Fontana
>> Subject: Re: [Megaco] Example of MeGaco messages for
>> Multiplex terminations
>>
>> El 14/10/2011 13:27, Claudio Fontana escribió:
>>> My answer might be OT for this list, but remember that if you are
>>> using megaco for voice in a 3gpp network, multiplexed
>> terminations are
>>> not supported in any of the 3gpp releases.
>>>
>>> ref: 29.232 C.6.2 "Multiplexed terminations"
>>>
>> In my case (supporting of Nx64 multichannel calls), these
>> terminations are the only solution. So, I need to build de
>> MeGaco messages to create them.
>>
> _______________________________________________
> -----Original Message-----
> From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Javi Muñoz
> Sent: Freitag, 14. Oktober 2011 12:29
> To: megaco@ietf.org
> Subject: [Megaco] Example of MeGaco messages for Multiplex terminations
>
> Hi,
>
> I have read that a multiplexing termination hides all of the terminations it contains from the rest of the context, so the streamIDs of the streams flowing between the contained terminations and the multiplexing termination are local rather than global in scope.
>
> If e have the following situation:
>
>                           Context interior ---->
>                       _________                 _________
>          Data stream  | H.226 |                 | H.223 |   Audio stream
> Ckt 1 ..............| "MUX" |                 |  MUX  | .................
>          . . .        | term  |   Data stream   | term  |
>          Data stream  |       | ................|       |   Video stream
> Ckt n ..............|       |                 |       | .................
>                       |       |                 |       |
>                       ---------                 ---------
>
> How we know that the stream between the H.226 and H.223 multiplexing terminations is a data stream, while the streams passing from the H.223 termination to the rest of the context are audio and video?. I think we need an explicit description of the exterior-side and context-side streams supported by each multiplex somewhere within our Megaco/H.248 documentation but, how may it be indicated in a MeGaCo meesage?
>
> Also, if we want to use separate RTP terminations for audio and video, I need to be able to tell that mux stream 1 shall be mapped to RTP termination T3, and stream 2 into RTP termination T4. How may it be indicated?
>
>
> In summary, may someone propose the full MeGaCo messages to create this scenario with multiplex terminations?
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www.ietf.org/mailman/listinfo/megaco>

From javi@trajano.us.es  Mon Oct 17 04:58:29 2011
Return-Path: <javi@trajano.us.es>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A0021F8A96 for <megaco@ietfa.amsl.com>; Mon, 17 Oct 2011 04:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-w-DdeQz4Yd for <megaco@ietfa.amsl.com>; Mon, 17 Oct 2011 04:58:28 -0700 (PDT)
Received: from mail.us.es (mail.us.es [193.147.175.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3675321F8A70 for <megaco@ietf.org>; Mon, 17 Oct 2011 04:58:28 -0700 (PDT)
Received: (qmail 3042 invoked from network); 17 Oct 2011 13:58:26 +0200
Received: from unknown (HELO us.es) (192.168.2.11) by us.es with SMTP; 17 Oct 2011 13:58:26 +0200
Received: (qmail 26366 invoked by uid 507); 17 Oct 2011 11:58:23 -0000
Received: from 127.0.0.1 by antivirus1 (envelope-from <javi@trajano.us.es>, uid 501) with qmail-scanner-2.08 (clamdscan: 0.97.2/13809.   Clear:RC:1(127.0.0.1):.  Processed in 0.049327 secs); 17 Oct 2011 11:58:23 -0000
Received: from unknown (HELO antivirus1) (127.0.0.1) by us.es with SMTP; 17 Oct 2011 11:58:23 -0000
Received: from 192.168.1.13 (192.168.1.13) by antivirus1 (F-Secure/fsigk_smtp/406/antivirus1); Mon, 17 Oct 2011 13:58:23 +0200 (CEST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/406/antivirus1)
Received: (qmail 3157 invoked from network); 17 Oct 2011 13:58:23 +0200
Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 17 Oct 2011 13:58:23 +0200
Received: from [193.147.162.138] (adriano.us.es [193.147.162.138]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id p9HBwMW1006262 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 17 Oct 2011 13:58:22 +0200
Message-ID: <4E9C185E.1090902@trajano.us.es>
Date: Mon, 17 Oct 2011 13:58:22 +0200
From: =?ISO-8859-1?Q?Javi_Mu=F1oz?= <javi@trajano.us.es>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: "megaco@ietf.org" <megaco@ietf.org>
References: <4E980EF1.4020407@trajano.us.es> <BLU0-SMTP5B76027A65AB404533C34D8E70@phx.gbl>
In-Reply-To: <BLU0-SMTP5B76027A65AB404533C34D8E70@phx.gbl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Claudio Fontana <claudio.fontana@gmail.com>
Subject: Re: [Megaco] Example of MeGaco messages for Multiplex terminations
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 17 Oct 2011 11:58:29 -0000

Albrecht, Tom, Claudio and Christian,

The proposed scenario was just an example with the intention of asking 
about the syntax for creating multiplex terminations and mapping StreamIDs.

The real scenario that I need to solve is the next one, related to 
convey ISDN D-channel SAPI 16 flows on HDLCPW pseudowires:

   Tmux1=Mux(1x64K(TermA/StreamID=1,TermA/StreamID=2,TermB/StreamID=1)) -- * -- TermC (HDLCPW1)
                                     |
TermA (D-Channel, UNI p)            |
    StreamID=1 (SAPI 16, TEI r)      |
    StreamID=2 (SAPI 16, TEI s)      |
                                     |
TermA (D-Channel, UNI q)            |
    StreamID=1 (SAPI 16, TEI r)-----|
    StreamID=2 (SAPI 16, TEI s)------------|
    StreamID=3 (SAPI 16, TEI t)------------|
                                              |
                     Tmux2=Mux(1x64K(TermB/StreamID=2,TermB/StreamID=3) -- * -- TermC (HDLCPW1)


Every HDLCPW may convey SAPI 16 flows from different channels D (so, the 
Mux termination has Streams from different terminations). I do not know 
if these multiplex terminations are possible and, if so, how to define 
them in a MeGaCo message (how to define "TermA/StreamID=1" in the Mux 
descriptor).

Regards,

Javi




El 16/10/2011 21:13, Tom Taylor escribió:
> Start with H.248.1v3/clause 6.2. That should give you some idea of how 
> to construct the syntax. Details for the MUX descriptor are given in 
> clause 7.1.3. I can put the whole picture together for you if you have 
> trouble, but I should warn you that my views differ from those 
> published as H.248.20.
>
> On 14/10/2011 6:29 AM, Javi Muñoz wrote:
>> Hi,
>>
>> I have read that a multiplexing termination hides all of the
>> terminations it contains from the rest of the context, so the streamIDs
>> of the streams flowing between the contained terminations and the
>> multiplexing termination are local rather than global in scope.
>>
>> If e have the following situation:
>>
>> Context interior ---->
>> _________ _________
>> Data stream | H.226 | | H.223 | Audio stream
>> Ckt 1 ..............| "MUX" | | MUX | .................
>> . . . | term | Data stream | term |
>> Data stream | | ................| | Video stream
>> Ckt n ..............| | | | .................
>> | | | |
>> --------- ---------
>>
>> How we know that the stream between the H.226 and H.223 multiplexing
>> terminations is a data stream, while the streams passing from the H.223
>> termination to the rest of the context are audio and video?. I think we
>> need an explicit description of the exterior-side and context-side
>> streams supported by each multiplex somewhere within our Megaco/H.248
>> documentation but, how may it be indicated in a MeGaCo meesage?
>>
>> Also, if we want to use separate RTP terminations for audio and video, I
>> need to be able to tell that mux stream 1 shall be mapped to RTP
>> termination T3, and stream 2 into RTP termination T4. How may it be
>> indicated?
>>
>>
>> In summary, may someone propose the full MeGaCo messages to create this
>> scenario with multiplex terminations?
>>
>> _______________________________________________
>> Megaco mailing list
>> Megaco@ietf.org
>> https://www.ietf.org/mailman/listinfo/megaco
>>
>>
>


From Christian.Groves@nteczone.com  Tue Oct 18 02:51:22 2011
Return-Path: <Christian.Groves@nteczone.com>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7261A21F8ACE for <megaco@ietfa.amsl.com>; Tue, 18 Oct 2011 02:51:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.242
X-Spam-Level: 
X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.057,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3FlfdHdjDK0 for <megaco@ietfa.amsl.com>; Tue, 18 Oct 2011 02:51:21 -0700 (PDT)
Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4293021F8AFD for <megaco@ietf.org>; Tue, 18 Oct 2011 02:51:21 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApMBAANKnU520Y3R/2dsb2JhbAAMN6tYAQEBBAEBASQLAQUbGwoBEAsYCRYPCQMCAQIBFTAGDQEFAgEBiAS2OwSIGwSlZw
Received: from ppp118-209-141-209.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.141.209]) by ipmail04.adl6.internode.on.net with ESMTP; 18 Oct 2011 20:21:18 +1030
Message-ID: <4E9D4C14.7080707@nteczone.com>
Date: Tue, 18 Oct 2011 20:51:16 +1100
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Javi_Mu=F1oz?= <javi@trajano.us.es>
References: <4E980EF1.4020407@trajano.us.es> <BLU0-SMTP5B76027A65AB404533C34D8E70@phx.gbl> <4E9C185E.1090902@trajano.us.es>
In-Reply-To: <4E9C185E.1090902@trajano.us.es>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "megaco@ietf.org" <megaco@ietf.org>, Claudio Fontana <claudio.fontana@gmail.com>
Subject: Re: [Megaco] Example of MeGaco messages for Multiplex terminations
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 18 Oct 2011 09:51:22 -0000

Hello Javi,

There's no means via the multiplex descriptor to indicate StreamIDs in 
addition to the TerminationID. The multiplex descriptor can only have 
TerminationIDs. Also you can't specify a number for N in "Nx64k" in the 
Multiplex descriptor. For Nx64k N is assumed by the number of 
terminations added to the MuxDescriptor.

With regards to the example below I'm abit confused. There are two TermA 
and two TermCs but no Term B? Should Tmux1 include TermA/Stream=2? This 
would mean StreamID=2 is going to both muxes.

I'm not 100% sure what you're trying to do but if you're only using a 
single Termination to represent each D-channel and a single Termination 
for the HDLCPW it seems to me that you don't need a mux termination and 
that it may be sufficient to simply use a property to assign TEIs to 
Streams (or Terminations).

Regards, Christian

On 17/10/2011 10:58 PM, Javi Muñoz wrote:
> Albrecht, Tom, Claudio and Christian,
>
> The proposed scenario was just an example with the intention of asking 
> about the syntax for creating multiplex terminations and mapping 
> StreamIDs.
>
> The real scenario that I need to solve is the next one, related to 
> convey ISDN D-channel SAPI 16 flows on HDLCPW pseudowires:
>
>   Tmux1=Mux(1x64K(TermA/StreamID=1,TermA/StreamID=2,TermB/StreamID=1)) 
> -- * -- TermC (HDLCPW1)
>                                     |
> TermA (D-Channel, UNI p)            |
>    StreamID=1 (SAPI 16, TEI r)      |
>    StreamID=2 (SAPI 16, TEI s)      |
>                                     |
> TermA (D-Channel, UNI q)            |
>    StreamID=1 (SAPI 16, TEI r)-----|
>    StreamID=2 (SAPI 16, TEI s)------------|
>    StreamID=3 (SAPI 16, TEI t)------------|
>                                              |
>                     Tmux2=Mux(1x64K(TermB/StreamID=2,TermB/StreamID=3) 
> -- * -- TermC (HDLCPW1)
>
>
> Every HDLCPW may convey SAPI 16 flows from different channels D (so, 
> the Mux termination has Streams from different terminations). I do not 
> know if these multiplex terminations are possible and, if so, how to 
> define them in a MeGaCo message (how to define "TermA/StreamID=1" in 
> the Mux descriptor).
>
> Regards,
>
> Javi
>
>
>
>
> El 16/10/2011 21:13, Tom Taylor escribió:
>> Start with H.248.1v3/clause 6.2. That should give you some idea of 
>> how to construct the syntax. Details for the MUX descriptor are given 
>> in clause 7.1.3. I can put the whole picture together for you if you 
>> have trouble, but I should warn you that my views differ from those 
>> published as H.248.20.
>>
>> On 14/10/2011 6:29 AM, Javi Muñoz wrote:
>>> Hi,
>>>
>>> I have read that a multiplexing termination hides all of the
>>> terminations it contains from the rest of the context, so the streamIDs
>>> of the streams flowing between the contained terminations and the
>>> multiplexing termination are local rather than global in scope.
>>>
>>> If e have the following situation:
>>>
>>> Context interior ---->
>>> _________ _________
>>> Data stream | H.226 | | H.223 | Audio stream
>>> Ckt 1 ..............| "MUX" | | MUX | .................
>>> . . . | term | Data stream | term |
>>> Data stream | | ................| | Video stream
>>> Ckt n ..............| | | | .................
>>> | | | |
>>> --------- ---------
>>>
>>> How we know that the stream between the H.226 and H.223 multiplexing
>>> terminations is a data stream, while the streams passing from the H.223
>>> termination to the rest of the context are audio and video?. I think we
>>> need an explicit description of the exterior-side and context-side
>>> streams supported by each multiplex somewhere within our Megaco/H.248
>>> documentation but, how may it be indicated in a MeGaCo meesage?
>>>
>>> Also, if we want to use separate RTP terminations for audio and 
>>> video, I
>>> need to be able to tell that mux stream 1 shall be mapped to RTP
>>> termination T3, and stream 2 into RTP termination T4. How may it be
>>> indicated?
>>>
>>>
>>> In summary, may someone propose the full MeGaCo messages to create this
>>> scenario with multiplex terminations?
>>>
>>> _______________________________________________
>>> Megaco mailing list
>>> Megaco@ietf.org
>>> https://www.ietf.org/mailman/listinfo/megaco
>>>
>>>
>>
>
>

From javi@trajano.us.es  Tue Oct 18 03:29:44 2011
Return-Path: <javi@trajano.us.es>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F93B21F8C12 for <megaco@ietfa.amsl.com>; Tue, 18 Oct 2011 03:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKWcCw6Wr2Dn for <megaco@ietfa.amsl.com>; Tue, 18 Oct 2011 03:29:43 -0700 (PDT)
Received: from mail.us.es (mail.us.es [193.147.175.20]) by ietfa.amsl.com (Postfix) with ESMTP id E38FE21F8BF9 for <megaco@ietf.org>; Tue, 18 Oct 2011 03:29:42 -0700 (PDT)
Received: (qmail 16163 invoked from network); 18 Oct 2011 12:29:41 +0200
Received: from unknown (HELO us.es) (192.168.2.12) by us.es with SMTP; 18 Oct 2011 12:29:41 +0200
Received: (qmail 15416 invoked by uid 507); 18 Oct 2011 10:29:30 -0000
Received: from 127.0.0.1 by antivirus2 (envelope-from <javi@trajano.us.es>, uid 501) with qmail-scanner-2.08 (clamdscan: 0.97.2/13814.   Clear:RC:1(127.0.0.1):.  Processed in 0.044095 secs); 18 Oct 2011 10:29:30 -0000
Received: from unknown (HELO antivirus2) (127.0.0.1) by us.es with SMTP; 18 Oct 2011 10:29:30 -0000
Received: from 192.168.1.13 (192.168.1.13) by antivirus2 (F-Secure/fsigk_smtp/406/antivirus2); Tue, 18 Oct 2011 12:29:30 +0200 (CEST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/406/antivirus2)
Received: (qmail 15638 invoked from network); 18 Oct 2011 12:29:30 +0200
Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 18 Oct 2011 12:29:30 +0200
Received: from [193.147.162.138] (adriano.us.es [193.147.162.138]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id p9IATQKI024603 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for <megaco@ietf.org>; Tue, 18 Oct 2011 12:29:27 +0200
Message-ID: <4E9D5509.4040105@trajano.us.es>
Date: Tue, 18 Oct 2011 12:29:29 +0200
From: =?ISO-8859-1?Q?Javi_Mu=F1oz?= <javi@trajano.us.es>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: "megaco@ietf.org" <megaco@ietf.org>
References: <4E980EF1.4020407@trajano.us.es> <BLU0-SMTP5B76027A65AB404533C34D8E70@phx.gbl> <4E9C185E.1090902@trajano.us.es>
In-Reply-To: <4E9C185E.1090902@trajano.us.es>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Megaco] Example of MeGaco messages for Multiplex terminations
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 18 Oct 2011 10:29:44 -0000

I have detected an error in the draw. It would be so:

   Tmux1=Mux(1x64K(TermA/StreamID=1,TermA/StreamID=2,TermB/StreamID=1)) 
-- * -- TermC (HDLCPW1)
                                     |
TermA (D-Channel, UNI p)            |
    StreamID=1 (SAPI 16, TEI r)------|
    StreamID=2 (SAPI 16, TEI s)      |
                                     |
TermB (D-Channel, UNI q)            |
    StreamID=1 (SAPI 16, TEI r)------|
    StreamID=2 (SAPI 16, TEI s)------------|
    StreamID=3 (SAPI 16, TEI t)------------|
                                           |
                     Tmux2=Mux(1x64K(TermB/StreamID=2,TermB/StreamID=3) 
-- * -- TermD (HDLCPW2)


Sorry for the inconvenience

Javi

El 17/10/2011 13:58, Javi Muñoz escribió:
> Albrecht, Tom, Claudio and Christian,
>
> The proposed scenario was just an example with the intention of asking 
> about the syntax for creating multiplex terminations and mapping 
> StreamIDs.
>
> The real scenario that I need to solve is the next one, related to 
> convey ISDN D-channel SAPI 16 flows on HDLCPW pseudowires:
>
>   Tmux1=Mux(1x64K(TermA/StreamID=1,TermA/StreamID=2,TermB/StreamID=1)) 
> -- * -- TermC (HDLCPW1)
>                                     |
> TermA (D-Channel, UNI p)            |
>    StreamID=1 (SAPI 16, TEI r)      |
>    StreamID=2 (SAPI 16, TEI s)      |
>                                     |
> TermA (D-Channel, UNI q)            |
>    StreamID=1 (SAPI 16, TEI r)-----|
>    StreamID=2 (SAPI 16, TEI s)------------|
>    StreamID=3 (SAPI 16, TEI t)------------|
>                                              |
>                     Tmux2=Mux(1x64K(TermB/StreamID=2,TermB/StreamID=3) 
> -- * -- TermC (HDLCPW1)
>
>
> Every HDLCPW may convey SAPI 16 flows from different channels D (so, 
> the Mux termination has Streams from different terminations). I do not 
> know if these multiplex terminations are possible and, if so, how to 
> define them in a MeGaCo message (how to define "TermA/StreamID=1" in 
> the Mux descriptor).
>
> Regards,
>
> Javi
>
>
>
>
> El 16/10/2011 21:13, Tom Taylor escribió:
>> Start with H.248.1v3/clause 6.2. That should give you some idea of 
>> how to construct the syntax. Details for the MUX descriptor are given 
>> in clause 7.1.3. I can put the whole picture together for you if you 
>> have trouble, but I should warn you that my views differ from those 
>> published as H.248.20.
>>
>> On 14/10/2011 6:29 AM, Javi Muñoz wrote:
>>> Hi,
>>>
>>> I have read that a multiplexing termination hides all of the
>>> terminations it contains from the rest of the context, so the streamIDs
>>> of the streams flowing between the contained terminations and the
>>> multiplexing termination are local rather than global in scope.
>>>
>>> If e have the following situation:
>>>
>>> Context interior ---->
>>> _________ _________
>>> Data stream | H.226 | | H.223 | Audio stream
>>> Ckt 1 ..............| "MUX" | | MUX | .................
>>> . . . | term | Data stream | term |
>>> Data stream | | ................| | Video stream
>>> Ckt n ..............| | | | .................
>>> | | | |
>>> --------- ---------
>>>
>>> How we know that the stream between the H.226 and H.223 multiplexing
>>> terminations is a data stream, while the streams passing from the H.223
>>> termination to the rest of the context are audio and video?. I think we
>>> need an explicit description of the exterior-side and context-side
>>> streams supported by each multiplex somewhere within our Megaco/H.248
>>> documentation but, how may it be indicated in a MeGaCo meesage?
>>>
>>> Also, if we want to use separate RTP terminations for audio and 
>>> video, I
>>> need to be able to tell that mux stream 1 shall be mapped to RTP
>>> termination T3, and stream 2 into RTP termination T4. How may it be
>>> indicated?
>>>
>>>
>>> In summary, may someone propose the full MeGaCo messages to create this
>>> scenario with multiplex terminations?
>>>
>>> _______________________________________________
>>> Megaco mailing list
>>> Megaco@ietf.org
>>> https://www.ietf.org/mailman/listinfo/megaco
>>>
>>>
>>
>


From javi@trajano.us.es  Thu Oct 20 01:38:45 2011
Return-Path: <javi@trajano.us.es>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB04721F8BB5 for <megaco@ietfa.amsl.com>; Thu, 20 Oct 2011 01:38:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uii4CI1TdEII for <megaco@ietfa.amsl.com>; Thu, 20 Oct 2011 01:38:45 -0700 (PDT)
Received: from mail.us.es (mail.us.es [193.147.175.20]) by ietfa.amsl.com (Postfix) with ESMTP id ADFB521F8BB3 for <megaco@ietf.org>; Thu, 20 Oct 2011 01:38:43 -0700 (PDT)
Received: (qmail 27738 invoked from network); 20 Oct 2011 10:38:42 +0200
Received: from unknown (HELO us.es) (192.168.2.11) by us.es with SMTP; 20 Oct 2011 10:38:42 +0200
Received: (qmail 29192 invoked by uid 507); 20 Oct 2011 08:38:41 -0000
Received: from 127.0.0.1 by antivirus1 (envelope-from <javi@trajano.us.es>, uid 501) with qmail-scanner-2.08 (clamdscan: 0.97.2/13827.   Clear:RC:1(127.0.0.1):.  Processed in 0.037585 secs); 20 Oct 2011 08:38:41 -0000
Received: from unknown (HELO antivirus1) (127.0.0.1) by us.es with SMTP; 20 Oct 2011 08:38:41 -0000
Received: from 192.168.1.13 (192.168.1.13) by antivirus1 (F-Secure/fsigk_smtp/406/antivirus1); Thu, 20 Oct 2011 10:38:41 +0200 (CEST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/406/antivirus1)
Received: (qmail 32088 invoked from network); 20 Oct 2011 10:38:41 +0200
Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 20 Oct 2011 10:38:41 +0200
Received: from [193.147.162.138] (adriano.us.es [193.147.162.138]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id p9K8cdhr028241 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for <megaco@ietf.org>; Thu, 20 Oct 2011 10:38:41 +0200
Message-ID: <4E9FDE1A.4050207@trajano.us.es>
Date: Thu, 20 Oct 2011 10:38:50 +0200
From: =?ISO-8859-1?Q?Javi_Mu=F1oz?= <javi@trajano.us.es>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: "megaco@ietf.org" <megaco@ietf.org>
References: <4E980EF1.4020407@trajano.us.es>	<BLU0-SMTP5B76027A65AB404533C34D8E70@phx.gbl>	<4E9C185E.1090902@trajano.us.es> <4E9D5509.4040105@trajano.us.es>
In-Reply-To: <4E9D5509.4040105@trajano.us.es>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: [Megaco] Multiple Streams and mutiplex terminations
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 20 Oct 2011 08:38:45 -0000

Does MeGaCo support the next contexts?:


   Tmux1=Mux(1x64K(TermA/StreamID=1,TermA/StreamID=2,TermB/StreamID=1)) 
-- * -- TermC (HDLCPW1)
                                     |
TermA (ISDN D-Channel, UNI p)       |
    StreamID=1 (SAPI 16, TEI r)------|
    StreamID=2 (SAPI 16, TEI s)------|
                                     |
TermB (ISDN D-Channel, UNI q)       |
    StreamID=1 (SAPI 16, TEI r)------|
    StreamID=2 (SAPI 16, TEI s)------------|
    StreamID=3 (SAPI 16, TEI t)------------|
                                           |
                     Tmux2=Mux(1x64K(TermB/StreamID=2,TermB/StreamID=3) 
-- * -- TermD (HDLCPW2)


where:

(a) Every multiplex termination is multiplexing Streams from different 
ISDN terminations, and only any Streams of each termination.

(b) The result of the multiplexion must be a flow of "64 kbps".

Javi Muñoz

From Christian.Groves@nteczone.com  Thu Oct 20 02:12:23 2011
Return-Path: <Christian.Groves@nteczone.com>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF7D21F8B03 for <megaco@ietfa.amsl.com>; Thu, 20 Oct 2011 02:12:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yd2GpuGZvja for <megaco@ietfa.amsl.com>; Thu, 20 Oct 2011 02:12:23 -0700 (PDT)
Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 977C521F84DF for <megaco@ietf.org>; Thu, 20 Oct 2011 02:12:22 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvEBAKLjn0520YjB/2dsb2JhbAAMNpoZkWcBAQEBAwEBAS8BBRsbChELGAkWDwkDAgECARUwEwYCAQGIBLR8BIgnBKVq
Received: from ppp118-209-136-193.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.136.193]) by ipmail05.adl6.internode.on.net with ESMTP; 20 Oct 2011 19:42:20 +1030
Message-ID: <4E9FE5EF.6070907@nteczone.com>
Date: Thu, 20 Oct 2011 20:12:15 +1100
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: megaco@ietf.org
References: <4E980EF1.4020407@trajano.us.es>	<BLU0-SMTP5B76027A65AB404533C34D8E70@phx.gbl>	<4E9C185E.1090902@trajano.us.es> <4E9D5509.4040105@trajano.us.es> <4E9FDE1A.4050207@trajano.us.es>
In-Reply-To: <4E9FDE1A.4050207@trajano.us.es>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Megaco] Multiple Streams and mutiplex terminations
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 20 Oct 2011 09:12:23 -0000

Hello Javi,

Did you see my email on the 18/10 which discusses this? Even with the 
clarification of the Terminations there's some questions.

Regards, Christian

On 20/10/2011 7:38 PM, Javi Muñoz wrote:
> Does MeGaCo support the next contexts?:
>
>
>   Tmux1=Mux(1x64K(TermA/StreamID=1,TermA/StreamID=2,TermB/StreamID=1)) 
> -- * -- TermC (HDLCPW1)
>                                     |
> TermA (ISDN D-Channel, UNI p)       |
>    StreamID=1 (SAPI 16, TEI r)------|
>    StreamID=2 (SAPI 16, TEI s)------|
>                                     |
> TermB (ISDN D-Channel, UNI q)       |
>    StreamID=1 (SAPI 16, TEI r)------|
>    StreamID=2 (SAPI 16, TEI s)------------|
>    StreamID=3 (SAPI 16, TEI t)------------|
>                                           |
>                     Tmux2=Mux(1x64K(TermB/StreamID=2,TermB/StreamID=3) 
> -- * -- TermD (HDLCPW2)
>
>
> where:
>
> (a) Every multiplex termination is multiplexing Streams from different 
> ISDN terminations, and only any Streams of each termination.
>
> (b) The result of the multiplexion must be a flow of "64 kbps".
>
> Javi Muñoz
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
>

From javi@trajano.us.es  Thu Oct 20 02:29:41 2011
Return-Path: <javi@trajano.us.es>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF4C21F8A80 for <megaco@ietfa.amsl.com>; Thu, 20 Oct 2011 02:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mo-WOYHBX00Q for <megaco@ietfa.amsl.com>; Thu, 20 Oct 2011 02:29:40 -0700 (PDT)
Received: from mail.us.es (mail.us.es [193.147.175.20]) by ietfa.amsl.com (Postfix) with ESMTP id 164F021F8A6F for <megaco@ietf.org>; Thu, 20 Oct 2011 02:29:39 -0700 (PDT)
Received: (qmail 25664 invoked from network); 20 Oct 2011 11:29:36 +0200
Received: from unknown (HELO us.es) (192.168.2.11) by us.es with SMTP; 20 Oct 2011 11:29:36 +0200
Received: (qmail 9802 invoked by uid 507); 20 Oct 2011 09:29:35 -0000
Received: from 127.0.0.1 by antivirus1 (envelope-from <javi@trajano.us.es>, uid 501) with qmail-scanner-2.08 (clamdscan: 0.97.2/13827.   Clear:RC:1(127.0.0.1):.  Processed in 0.0502 secs); 20 Oct 2011 09:29:35 -0000
Received: from unknown (HELO antivirus1) (127.0.0.1) by us.es with SMTP; 20 Oct 2011 09:29:34 -0000
Received: from 192.168.1.13 (192.168.1.13) by antivirus1 (F-Secure/fsigk_smtp/406/antivirus1); Thu, 20 Oct 2011 11:29:34 +0200 (CEST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/406/antivirus1)
Received: (qmail 1711 invoked from network); 20 Oct 2011 11:29:34 +0200
Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 20 Oct 2011 11:29:34 +0200
Received: from [193.147.162.138] (adriano.us.es [193.147.162.138]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id p9K9TYdB028977 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 20 Oct 2011 11:29:34 +0200
Message-ID: <4E9FEA09.3080900@trajano.us.es>
Date: Thu, 20 Oct 2011 11:29:45 +0200
From: =?ISO-8859-1?Q?Javi_Mu=F1oz?= <javi@trajano.us.es>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: "megaco@ietf.org" <megaco@ietf.org>
References: <4E980EF1.4020407@trajano.us.es>	<BLU0-SMTP5B76027A65AB404533C34D8E70@phx.gbl>	<4E9C185E.1090902@trajano.us.es>	<4E9D5509.4040105@trajano.us.es> <4E9FDE1A.4050207@trajano.us.es> <4E9FE5EF.6070907@nteczone.com>
In-Reply-To: <4E9FE5EF.6070907@nteczone.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Megaco] Multiple Streams and mutiplex terminations
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 20 Oct 2011 09:29:41 -0000

Hello Christian,

Sorry, I missed it.

You wrote:

[Chistian] There's no means via the multiplex descriptor to indicate 
StreamIDs in addition to the TerminationID. The multiplex descriptor can 
only have TerminationIDs.

[Javi] Then, Do you mean MeGaCo does not support this kind of context?


[Christian]  Also you can't specify a number for N in "Nx64k" in the 
Multiplex descriptor. For Nx64k N is assumed by the number of 
terminations added to the MuxDescriptor.

[Javi] Again, MeGaCo would not support kind of multiplexing.


[Christian] With regards to the example below I'm abit confused. There 
are two TermA and two TermCs but no Term B? Should Tmux1 include 
TermA/Stream=2? This would mean StreamID=2 is going to both muxes.

[Javi] I hope the new picture has clarified these issues


[Christian] I'm not 100% sure what you're trying to do but if you're 
only using a single Termination to represent each D-channel and a single 
Termination for the HDLCPW it seems to me that you don't need a mux 
termination and that it may be sufficient to simply use a property to 
assign TEIs to Streams (or Terminations).

[Javi] Each D-channel has several streams and I need to direct them to 
different multiplex terminations.



Regards,

Javi Muñoz


El 20/10/2011 11:12, Christian Groves escribió:
> Hello Javi,
>
> Did you see my email on the 18/10 which discusses this? Even with the 
> clarification of the Terminations there's some questions.
>
> Regards, Christian
>
> On 20/10/2011 7:38 PM, Javi Muñoz wrote:
>> Does MeGaCo support the next contexts?:
>>
>>
>>   
>> Tmux1=Mux(1x64K(TermA/StreamID=1,TermA/StreamID=2,TermB/StreamID=1)) 
>> -- * -- TermC (HDLCPW1)
>>                                     |
>> TermA (ISDN D-Channel, UNI p)       |
>>    StreamID=1 (SAPI 16, TEI r)------|
>>    StreamID=2 (SAPI 16, TEI s)------|
>>                                     |
>> TermB (ISDN D-Channel, UNI q)       |
>>    StreamID=1 (SAPI 16, TEI r)------|
>>    StreamID=2 (SAPI 16, TEI s)------------|
>>    StreamID=3 (SAPI 16, TEI t)------------|
>>                                           |
>>                     
>> Tmux2=Mux(1x64K(TermB/StreamID=2,TermB/StreamID=3) -- * -- TermD 
>> (HDLCPW2)
>>
>>
>> where:
>>
>> (a) Every multiplex termination is multiplexing Streams from 
>> different ISDN terminations, and only any Streams of each termination.
>>
>> (b) The result of the multiplexion must be a flow of "64 kbps".
>>
>> Javi Muñoz
>> _______________________________________________
>> Megaco mailing list
>> Megaco@ietf.org
>> https://www.ietf.org/mailman/listinfo/megaco
>>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
>


From Christian.Groves@nteczone.com  Mon Oct 24 19:35:38 2011
Return-Path: <Christian.Groves@nteczone.com>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7755611E80DD for <megaco@ietfa.amsl.com>; Mon, 24 Oct 2011 19:35:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.271
X-Spam-Level: 
X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.028,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMGHl55un0Wd for <megaco@ietfa.amsl.com>; Mon, 24 Oct 2011 19:35:37 -0700 (PDT)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by ietfa.amsl.com (Postfix) with ESMTP id 9487911E80B8 for <megaco@ietf.org>; Mon, 24 Oct 2011 19:35:37 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApMBAFwfpk520QnM/2dsb2JhbAAMN6wIAQEBAQMBAQEvAQUbGwoBEAsYCRYPCQMCAQIBFTAGDQEFAgEBiAS0XQSIQASleA
Received: from ppp118-209-9-204.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.9.204]) by ipmail07.adl2.internode.on.net with ESMTP; 25 Oct 2011 13:05:35 +1030
Message-ID: <4EA62075.3060404@nteczone.com>
Date: Tue, 25 Oct 2011 13:35:33 +1100
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Javi_Mu=F1oz?= <javi@trajano.us.es>
References: <4E980EF1.4020407@trajano.us.es>	<BLU0-SMTP5B76027A65AB404533C34D8E70@phx.gbl>	<4E9C185E.1090902@trajano.us.es>	<4E9D5509.4040105@trajano.us.es> <4E9FDE1A.4050207@trajano.us.es> <4E9FE5EF.6070907@nteczone.com> <4E9FEA09.3080900@trajano.us.es>
In-Reply-To: <4E9FEA09.3080900@trajano.us.es>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "megaco@ietf.org" <megaco@ietf.org>
Subject: Re: [Megaco] Multiple Streams and mutiplex terminations
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 25 Oct 2011 02:35:38 -0000

Hello Javi,

Please see my replies below.

Regards, Christian

On 20/10/2011 8:29 PM, Javi Muñoz wrote:
> Hello Christian,
>
> Sorry, I missed it.
>
> You wrote:
>
> [Chistian] There's no means via the multiplex descriptor to indicate 
> StreamIDs in addition to the TerminationID. The multiplex descriptor 
> can only have TerminationIDs.
>
> [Javi] Then, Do you mean MeGaCo does not support this kind of context?
>
[CNG]No, I mean that the syntax doesn't support adding streams in the 
multiplex descriptor. This is different to what's happening in the Content.
>
> [Christian]  Also you can't specify a number for N in "Nx64k" in the 
> Multiplex descriptor. For Nx64k N is assumed by the number of 
> terminations added to the MuxDescriptor.
>
> [Javi] Again, MeGaCo would not support kind of multiplexing.
[CNG] No, Megaco does support Nx64K, the syntax doesn't support 
including N in the multiplex descriptor. As I mentioned its implied by 
the number of terminations in the list of termination assigned to the 
multiplex descriptor.
>
>
> [Christian] With regards to the example below I'm abit confused. There 
> are two TermA and two TermCs but no Term B? Should Tmux1 include 
> TermA/Stream=2? This would mean StreamID=2 is going to both muxes.
>
> [Javi] I hope the new picture has clarified these issues
[CNG] A little, I understand the termination aspect. I'm still not sure 
about the streams. I don't understand how you can have multiple H.248 
streams for the circuit termination TermA and TermB? With what 
information element (i.e. property) do you assign the SAPI and TEI to a 
Stream? What properties distinguish the Nx64K termination from a HDLCW1 one?
>
>
> [Christian] I'm not 100% sure what you're trying to do but if you're 
> only using a single Termination to represent each D-channel and a 
> single Termination for the HDLCPW it seems to me that you don't need a 
> mux termination and that it may be sufficient to simply use a property 
> to assign TEIs to Streams (or Terminations).
>
> [Javi] Each D-channel has several streams and I need to direct them to 
> different multiplex terminations.

[CNG] I think you're trying to solve this at a different level than what 
it should be. The multiplex descriptor describe the multiplex of 
terminations used to make up a stream. It doesn't describe what's 
happening at a stream level itself. We have the Stream Descriptor with 
associated (Local, Remote, LocalControl descriptors) to do this.


>
>
>
> Regards,
>
> Javi Muñoz
>
>
> El 20/10/2011 11:12, Christian Groves escribió:
>> Hello Javi,
>>
>> Did you see my email on the 18/10 which discusses this? Even with the 
>> clarification of the Terminations there's some questions.
>>
>> Regards, Christian
>>
>> On 20/10/2011 7:38 PM, Javi Muñoz wrote:
>>> Does MeGaCo support the next contexts?:
>>>
>>>
>>>   
>>> Tmux1=Mux(1x64K(TermA/StreamID=1,TermA/StreamID=2,TermB/StreamID=1)) 
>>> -- * -- TermC (HDLCPW1)
>>>                                     |
>>> TermA (ISDN D-Channel, UNI p)       |
>>>    StreamID=1 (SAPI 16, TEI r)------|
>>>    StreamID=2 (SAPI 16, TEI s)------|
>>>                                     |
>>> TermB (ISDN D-Channel, UNI q)       |
>>>    StreamID=1 (SAPI 16, TEI r)------|
>>>    StreamID=2 (SAPI 16, TEI s)------------|
>>>    StreamID=3 (SAPI 16, TEI t)------------|
>>>                                           |
>>>                     
>>> Tmux2=Mux(1x64K(TermB/StreamID=2,TermB/StreamID=3) -- * -- TermD 
>>> (HDLCPW2)
>>>
>>>
>>> where:
>>>
>>> (a) Every multiplex termination is multiplexing Streams from 
>>> different ISDN terminations, and only any Streams of each termination.
>>>
>>> (b) The result of the multiplexion must be a flow of "64 kbps".
>>>
>>> Javi Muñoz
>>> _______________________________________________
>>> Megaco mailing list
>>> Megaco@ietf.org
>>> https://www.ietf.org/mailman/listinfo/megaco
>>>
>> _______________________________________________
>> Megaco mailing list
>> Megaco@ietf.org
>> https://www.ietf.org/mailman/listinfo/megaco
>>
>
>

From javi@trajano.us.es  Tue Oct 25 04:52:01 2011
Return-Path: <javi@trajano.us.es>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B306221F8AE9 for <megaco@ietfa.amsl.com>; Tue, 25 Oct 2011 04:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xc+-TSX783jT for <megaco@ietfa.amsl.com>; Tue, 25 Oct 2011 04:52:01 -0700 (PDT)
Received: from mail.us.es (mail.us.es [193.147.175.20]) by ietfa.amsl.com (Postfix) with ESMTP id 989DC21F8A62 for <megaco@ietf.org>; Tue, 25 Oct 2011 04:52:00 -0700 (PDT)
Received: (qmail 10594 invoked from network); 25 Oct 2011 13:51:50 +0200
Received: from unknown (HELO us.es) (192.168.2.11) by us.es with SMTP; 25 Oct 2011 13:51:50 +0200
Received: (qmail 9017 invoked by uid 507); 25 Oct 2011 11:51:44 -0000
Received: from 127.0.0.1 by antivirus1 (envelope-from <javi@trajano.us.es>, uid 501) with qmail-scanner-2.08 (clamdscan: 0.97.3/13848.   Clear:RC:1(127.0.0.1):.  Processed in 0.053745 secs); 25 Oct 2011 11:51:44 -0000
Received: from unknown (HELO antivirus1) (127.0.0.1) by us.es with SMTP; 25 Oct 2011 11:51:44 -0000
Received: from 192.168.1.13 (192.168.1.13) by antivirus1 (F-Secure/fsigk_smtp/406/antivirus1); Tue, 25 Oct 2011 13:51:44 +0200 (CEST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/406/antivirus1)
Received: (qmail 1460 invoked from network); 25 Oct 2011 13:51:44 +0200
Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 25 Oct 2011 13:51:44 +0200
Received: from [193.147.162.138] (adriano.us.es [193.147.162.138]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id p9PBphwd018325 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for <megaco@ietf.org>; Tue, 25 Oct 2011 13:51:44 +0200
Message-ID: <4EA6A2D4.2050903@trajano.us.es>
Date: Tue, 25 Oct 2011 13:51:48 +0200
From: =?ISO-8859-1?Q?Javi_Mu=F1oz?= <javi@trajano.us.es>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: "megaco@ietf.org" <megaco@ietf.org>
References: <4E980EF1.4020407@trajano.us.es>	<BLU0-SMTP5B76027A65AB404533C34D8E70@phx.gbl>	<4E9C185E.1090902@trajano.us.es>	<4E9D5509.4040105@trajano.us.es> <4E9FDE1A.4050207@trajano.us.es> <4E9FE5EF.6070907@nteczone.com> <4E9FEA09.3080900@trajano.us.es> <4EA62075.3060404@nteczone.com>
In-Reply-To: <4EA62075.3060404@nteczone.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Megaco] Multiple Streams and mutiplex terminations
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 25 Oct 2011 11:52:01 -0000

Hello Christian,

Thank you for your answer.

I understand MeGaCo syntax doesn't support adding streams in the 
multiplex descriptor neither including N in the multiplex descriptor.

[Christian] A little, I understand the termination aspect. I'm still not 
sure about the streams. I don't understand how you can have multiple 
H.248 streams for the circuit termination TermA and TermB? With what 
information element (i.e. property) do you assign the SAPI and TEI to a 
Stream? What properties distinguish the Nx64K termination from a HDLCW1 one?
[Christian] I'm not 100% sure what you're trying to do but if you're 
only using a single Termination to represent each D-channel and a single 
Termination for the HDLCPW it seems to me that you don't need a mux 
termination and that it may be sufficient to simply use a property to 
assign TEIs to Streams (or Terminations).
[Christian] I think you're trying to solve this at a different level 
than what it should be. The multiplex descriptor describe the multiplex 
of terminations used to make up a stream. It doesn't describe what's 
happening at a stream level itself. We have the Stream Descriptor with 
associated (Local, Remote, LocalControl descriptors) to do this.


In ISDN, each D-channel (channel of 16 or 64 kbps) transport multiple 
flows muliplexed by its TEI and SAPI in the Q.921 header.

Every of these flows may need to be transported to a different server in 
the IP network, and each server may receive only a HDLCPW. So, I need to 
multiplex multiple D-channel flows in each HDLCPW. In each HDLCPW, each 
flow would be distinguished by its TEI/SAPI and D-channel identifier.

I can not think how to describe in SDP (Local, Remote, LocalControl 
descriptors) what D-channel flows must be transported by any HDLCPW. May 
you proposed an example?

Regards,

Javier Muñoz
>>
>>
>>>
>>>
>>>
>>> Regards,
>>>
>>> Javi Muñoz
>>>
>>>
>>> El 20/10/2011 11:12, Christian Groves escribió:
>>>> Hello Javi,
>>>>
>>>> Did you see my email on the 18/10 which discusses this? Even with
>>>> the clarification of the Terminations there's some questions.
>>>>
>>>> Regards, Christian
>>>>
>>>> On 20/10/2011 7:38 PM, Javi Muñoz wrote:
>>>>> Does MeGaCo support the next contexts?:
>>>>>
>>>>>
>>>>>
>>>>> Tmux1=Mux(1x64K(TermA/StreamID=1,TermA/StreamID=2,TermB/StreamID=1))
>>>>> -- * -- TermC (HDLCPW1)
>>>>>                                     |
>>>>> TermA (ISDN D-Channel, UNI p)       |
>>>>>    StreamID=1 (SAPI 16, TEI r)------|
>>>>>    StreamID=2 (SAPI 16, TEI s)------|
>>>>>                                     |
>>>>> TermB (ISDN D-Channel, UNI q)       |
>>>>>    StreamID=1 (SAPI 16, TEI r)------|
>>>>>    StreamID=2 (SAPI 16, TEI s)------------|
>>>>>    StreamID=3 (SAPI 16, TEI t)------------|
>>>>>                                           |
>>>>>
>>>>> Tmux2=Mux(1x64K(TermB/StreamID=2,TermB/StreamID=3) -- * -- TermD
>>>>> (HDLCPW2)
>>>>>
>>>>>
>>>>> where:
>>>>>
>>>>> (a) Every multiplex termination is multiplexing Streams from
>>>>> different ISDN terminations, and only any Streams of each
>>>>> termination.
>>>>>
>>>>> (b) The result of the multiplexion must be a flow of "64 kbps".
>>>>>
>>>>> Javi Muñoz
>>>>> _______________________________________________
>>>>> Megaco mailing list
>>>>> Megaco@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/megaco
>>>>>
>>>> _______________________________________________
>>>> Megaco mailing list
>>>> Megaco@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/megaco
>>>>
>>>
>>>
>>


From Christian.Groves@nteczone.com  Thu Oct 27 18:23:41 2011
Return-Path: <Christian.Groves@nteczone.com>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EFB11E8073 for <megaco@ietfa.amsl.com>; Thu, 27 Oct 2011 18:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.274
X-Spam-Level: 
X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1f9D5lkO4xU for <megaco@ietfa.amsl.com>; Thu, 27 Oct 2011 18:23:40 -0700 (PDT)
Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 668BD21F8560 for <megaco@ietf.org>; Thu, 27 Oct 2011 18:23:40 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApMBAPECqk520VaF/2dsb2JhbAAMNqxZAQEBBAEBAS8BBRsbCgEQCxgJFg8JAwIBAgEVMAYNAQUCAQGIBrVMiH4EpgA
Received: from ppp118-209-86-133.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.86.133]) by ipmail05.adl6.internode.on.net with ESMTP; 28 Oct 2011 11:53:38 +1030
Message-ID: <4EAA0413.5040007@nteczone.com>
Date: Fri, 28 Oct 2011 12:23:31 +1100
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Javi_Mu=F1oz?= <javi@trajano.us.es>
References: <4E980EF1.4020407@trajano.us.es>	<BLU0-SMTP5B76027A65AB404533C34D8E70@phx.gbl>	<4E9C185E.1090902@trajano.us.es>	<4E9D5509.4040105@trajano.us.es> <4E9FDE1A.4050207@trajano.us.es> <4E9FE5EF.6070907@nteczone.com> <4E9FEA09.3080900@trajano.us.es> <4EA62075.3060404@nteczone.com> <4EA6A2D4.2050903@trajano.us.es>
In-Reply-To: <4EA6A2D4.2050903@trajano.us.es>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "megaco@ietf.org" <megaco@ietf.org>
Subject: Re: [Megaco] Multiple Streams and mutiplex terminations
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 28 Oct 2011 01:23:41 -0000

Hello Javi,

I'm not aware of any SDP that would allow you to specify the TEI and 
SAPI. Probably the closest draft to doing this was Tom's draft 
http://tools.ietf.org/id/draft-taylor-mmusic-sdp-tdm-01.txt.

Rather than use SDP you probably need to create a new package with two 
properties that allow you to indicate the SAPI and TEI. Each property 
would be a sub-list allowing you to indicate with SAPIs and TEIs apply 
to the stream. You probably wouldn't need multiple StreamIDs in this case.

Regards, Christian

On 25/10/2011 10:51 PM, Javi Muñoz wrote:
> Hello Christian,
>
> Thank you for your answer.
>
> I understand MeGaCo syntax doesn't support adding streams in the 
> multiplex descriptor neither including N in the multiplex descriptor.
>
> [Christian] A little, I understand the termination aspect. I'm still 
> not sure about the streams. I don't understand how you can have 
> multiple H.248 streams for the circuit termination TermA and TermB? 
> With what information element (i.e. property) do you assign the SAPI 
> and TEI to a Stream? What properties distinguish the Nx64K termination 
> from a HDLCW1 one?
> [Christian] I'm not 100% sure what you're trying to do but if you're 
> only using a single Termination to represent each D-channel and a 
> single Termination for the HDLCPW it seems to me that you don't need a 
> mux termination and that it may be sufficient to simply use a property 
> to assign TEIs to Streams (or Terminations).
> [Christian] I think you're trying to solve this at a different level 
> than what it should be. The multiplex descriptor describe the 
> multiplex of terminations used to make up a stream. It doesn't 
> describe what's happening at a stream level itself. We have the Stream 
> Descriptor with associated (Local, Remote, LocalControl descriptors) 
> to do this.
>
>
> In ISDN, each D-channel (channel of 16 or 64 kbps) transport multiple 
> flows muliplexed by its TEI and SAPI in the Q.921 header.
>
> Every of these flows may need to be transported to a different server 
> in the IP network, and each server may receive only a HDLCPW. So, I 
> need to multiplex multiple D-channel flows in each HDLCPW. In each 
> HDLCPW, each flow would be distinguished by its TEI/SAPI and D-channel 
> identifier.
>
> I can not think how to describe in SDP (Local, Remote, LocalControl 
> descriptors) what D-channel flows must be transported by any HDLCPW. 
> May you proposed an example?
>
> Regards,
>
> Javier Muñoz
>>>
>>>
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Javi Muñoz
>>>>
>>>>
>>>> El 20/10/2011 11:12, Christian Groves escribió:
>>>>> Hello Javi,
>>>>>
>>>>> Did you see my email on the 18/10 which discusses this? Even with
>>>>> the clarification of the Terminations there's some questions.
>>>>>
>>>>> Regards, Christian
>>>>>
>>>>> On 20/10/2011 7:38 PM, Javi Muñoz wrote:
>>>>>> Does MeGaCo support the next contexts?:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Tmux1=Mux(1x64K(TermA/StreamID=1,TermA/StreamID=2,TermB/StreamID=1))
>>>>>> -- * -- TermC (HDLCPW1)
>>>>>>                                     |
>>>>>> TermA (ISDN D-Channel, UNI p)       |
>>>>>>    StreamID=1 (SAPI 16, TEI r)------|
>>>>>>    StreamID=2 (SAPI 16, TEI s)------|
>>>>>>                                     |
>>>>>> TermB (ISDN D-Channel, UNI q)       |
>>>>>>    StreamID=1 (SAPI 16, TEI r)------|
>>>>>>    StreamID=2 (SAPI 16, TEI s)------------|
>>>>>>    StreamID=3 (SAPI 16, TEI t)------------|
>>>>>>                                           |
>>>>>>
>>>>>> Tmux2=Mux(1x64K(TermB/StreamID=2,TermB/StreamID=3) -- * -- TermD
>>>>>> (HDLCPW2)
>>>>>>
>>>>>>
>>>>>> where:
>>>>>>
>>>>>> (a) Every multiplex termination is multiplexing Streams from
>>>>>> different ISDN terminations, and only any Streams of each
>>>>>> termination.
>>>>>>
>>>>>> (b) The result of the multiplexion must be a flow of "64 kbps".
>>>>>>
>>>>>> Javi Muñoz
>>>>>> _______________________________________________
>>>>>> Megaco mailing list
>>>>>> Megaco@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/megaco
>>>>>>
>>>>> _______________________________________________
>>>>> Megaco mailing list
>>>>> Megaco@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/megaco
>>>>>
>>>>
>>>>
>>>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
>

From javi@trajano.us.es  Fri Oct 28 03:04:04 2011
Return-Path: <javi@trajano.us.es>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126A421F8B2A for <megaco@ietfa.amsl.com>; Fri, 28 Oct 2011 03:04:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.998
X-Spam-Level: 
X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FngZ6wCpsfCx for <megaco@ietfa.amsl.com>; Fri, 28 Oct 2011 03:04:00 -0700 (PDT)
Received: from mail.us.es (mail.us.es [193.147.175.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3799421F8B26 for <megaco@ietf.org>; Fri, 28 Oct 2011 03:03:59 -0700 (PDT)
Received: (qmail 15380 invoked from network); 28 Oct 2011 12:03:48 +0200
Received: from unknown (HELO us.es) (192.168.2.13) by us.es with SMTP; 28 Oct 2011 12:03:48 +0200
Received: (qmail 4846 invoked by uid 507); 28 Oct 2011 10:03:40 -0000
Received: from 127.0.0.1 by antivirus3 (envelope-from <javi@trajano.us.es>, uid 501) with qmail-scanner-2.08 (clamdscan: 0.97.3/13862.   Clear:RC:1(127.0.0.1):.  Processed in 0.098161 secs); 28 Oct 2011 10:03:40 -0000
Received: from unknown (HELO antivirus3) (127.0.0.1) by us.es with SMTP; 28 Oct 2011 10:03:40 -0000
Received: from 192.168.1.13 (192.168.1.13) by antivirus3 (F-Secure/fsigk_smtp/406/antivirus3); Fri, 28 Oct 2011 12:03:40 +0200 (CEST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/406/antivirus3)
Received: (qmail 15898 invoked from network); 28 Oct 2011 12:03:40 +0200
Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 28 Oct 2011 12:03:40 +0200
Received: from [193.147.162.138] (adriano.us.es [193.147.162.138]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id p9SA3dlv013327 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 28 Oct 2011 12:03:40 +0200
Message-ID: <4EAA7E0C.50807@trajano.us.es>
Date: Fri, 28 Oct 2011 12:03:56 +0200
From: =?ISO-8859-1?Q?Javi_Mu=F1oz?= <javi@trajano.us.es>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: "megaco@ietf.org" <megaco@ietf.org>
References: <4E980EF1.4020407@trajano.us.es>	<BLU0-SMTP5B76027A65AB404533C34D8E70@phx.gbl>	<4E9C185E.1090902@trajano.us.es>	<4E9D5509.4040105@trajano.us.es> <4E9FDE1A.4050207@trajano.us.es> <4E9FE5EF.6070907@nteczone.com> <4E9FEA09.3080900@trajano.us.es> <4EA62075.3060404@nteczone.com> <4EA6A2D4.2050903@trajano.us.es> <4EAA0413.5040007@nteczone.com>
In-Reply-To: <4EAA0413.5040007@nteczone.com>
Content-Type: multipart/alternative; boundary="------------030002080409010604020802"
Subject: Re: [Megaco] Multiple Streams and mutiplex terminations
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 28 Oct 2011 10:04:04 -0000

This is a multi-part message in MIME format.
--------------030002080409010604020802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hello Christian,

If we use SDP, an example could be:

MEGACO/1 [123.123.123.1]:11111    (MG <- MGC)
  Transaction = 10 {
    Context = $ {
       Add = ISDNTerm/*BA17-BA18-PRI1*/D/$ {
           Media { Stream = 1
                    {
                       Local { v=0
                           c=ISDN SAPI 16 BA17
m=data TEI 1 PLP
c=ISDN SAPI 16 BA17
m=data TEI 6 PLP
c=ISDN SAPI 16 BA18
m=data TEI 3 PLP
c=ISDN SAPI 16 PRI1
m=data TEI 9 PLP
} } },
Add = HDLCPW1 {
           Media { Stream = 1 {
               # ---Descriptores Local/Remote-- } } }
  } }

Here, I found two serious problems:

+ We are defining a termination which has ISDN D-channels from different 
physical interfaces/UNIs (BA17-BA18-PRI1 indicates UNI BRI "17", UNI BRI 
"18" and UNI PRI "1"). I think it contradicts the definition of 
terminationss proposed by H.248.1.

+ We are describing several SDP flows (m=) in the Local Descriptor, but 
these flows are multiplexing in their respective channels D (the 
situation is not that: aflow is transmitted and, until it ends, no other 
flow is transmitted; But all flows are simultaneous transmitted, being 
differentiated by the header of the LAPD frames).


If we use MeGaCo properties to specify the TEI and SAPI, it would have 
the same problems.

Javi


El 28/10/2011 3:23, Christian Groves escribió:
> Hello Javi,
>
> I'm not aware of any SDP that would allow you to specify the TEI and 
> SAPI. Probably the closest draft to doing this was Tom's draft 
> http://tools.ietf.org/id/draft-taylor-mmusic-sdp-tdm-01.txt.
>
> Rather than use SDP you probably need to create a new package with two 
> properties that allow you to indicate the SAPI and TEI. Each property 
> would be a sub-list allowing you to indicate with SAPIs and TEIs apply 
> to the stream. You probably wouldn't need multiple StreamIDs in this 
> case.
>
> Regards, Christian
>
> On 25/10/2011 10:51 PM, Javi Muñoz wrote:
>> Hello Christian,
>>
>> Thank you for your answer.
>>
>> I understand MeGaCo syntax doesn't support adding streams in the 
>> multiplex descriptor neither including N in the multiplex descriptor.
>>
>> [Christian] A little, I understand the termination aspect. I'm still 
>> not sure about the streams. I don't understand how you can have 
>> multiple H.248 streams for the circuit termination TermA and TermB? 
>> With what information element (i.e. property) do you assign the SAPI 
>> and TEI to a Stream? What properties distinguish the Nx64K 
>> termination from a HDLCW1 one?
>> [Christian] I'm not 100% sure what you're trying to do but if you're 
>> only using a single Termination to represent each D-channel and a 
>> single Termination for the HDLCPW it seems to me that you don't need 
>> a mux termination and that it may be sufficient to simply use a 
>> property to assign TEIs to Streams (or Terminations).
>> [Christian] I think you're trying to solve this at a different level 
>> than what it should be. The multiplex descriptor describe the 
>> multiplex of terminations used to make up a stream. It doesn't 
>> describe what's happening at a stream level itself. We have the 
>> Stream Descriptor with associated (Local, Remote, LocalControl 
>> descriptors) to do this.
>>
>>
>> In ISDN, each D-channel (channel of 16 or 64 kbps) transport multiple 
>> flows muliplexed by its TEI and SAPI in the Q.921 header.
>>
>> Every of these flows may need to be transported to a different server 
>> in the IP network, and each server may receive only a HDLCPW. So, I 
>> need to multiplex multiple D-channel flows in each HDLCPW. In each 
>> HDLCPW, each flow would be distinguished by its TEI/SAPI and 
>> D-channel identifier.
>>
>> I can not think how to describe in SDP (Local, Remote, LocalControl 
>> descriptors) what D-channel flows must be transported by any HDLCPW. 
>> May you proposed an example?
>>
>> Regards,
>>
>> Javier Muñoz
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Javi Muñoz
>>>>>
>>>>>
>>>>> El 20/10/2011 11:12, Christian Groves escribió:
>>>>>> Hello Javi,
>>>>>>
>>>>>> Did you see my email on the 18/10 which discusses this? Even with
>>>>>> the clarification of the Terminations there's some questions.
>>>>>>
>>>>>> Regards, Christian
>>>>>>
>>>>>> On 20/10/2011 7:38 PM, Javi Muñoz wrote:
>>>>>>> Does MeGaCo support the next contexts?:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Tmux1=Mux(1x64K(TermA/StreamID=1,TermA/StreamID=2,TermB/StreamID=1)) 
>>>>>>>
>>>>>>> -- * -- TermC (HDLCPW1)
>>>>>>>                                     |
>>>>>>> TermA (ISDN D-Channel, UNI p)       |
>>>>>>>    StreamID=1 (SAPI 16, TEI r)------|
>>>>>>>    StreamID=2 (SAPI 16, TEI s)------|
>>>>>>>                                     |
>>>>>>> TermB (ISDN D-Channel, UNI q)       |
>>>>>>>    StreamID=1 (SAPI 16, TEI r)------|
>>>>>>>    StreamID=2 (SAPI 16, TEI s)------------|
>>>>>>>    StreamID=3 (SAPI 16, TEI t)------------|
>>>>>>>                                           |
>>>>>>>
>>>>>>> Tmux2=Mux(1x64K(TermB/StreamID=2,TermB/StreamID=3) -- * -- TermD
>>>>>>> (HDLCPW2)
>>>>>>>
>>>>>>>
>>>>>>> where:
>>>>>>>
>>>>>>> (a) Every multiplex termination is multiplexing Streams from
>>>>>>> different ISDN terminations, and only any Streams of each
>>>>>>> termination.
>>>>>>>
>>>>>>> (b) The result of the multiplexion must be a flow of "64 kbps".
>>>>>>>
>>>>>>> Javi Muñoz
>>>>>>> _______________________________________________
>>>>>>> Megaco mailing list
>>>>>>> Megaco@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/megaco
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Megaco mailing list
>>>>>> Megaco@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/megaco
>>>>>>
>>>>>
>>>>>
>>>>
>>
>> _______________________________________________
>> Megaco mailing list
>> Megaco@ietf.org
>> https://www.ietf.org/mailman/listinfo/megaco
>>
>


--------------030002080409010604020802
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Hello Christian,<br>
    <br>
    If we use SDP, an example could be:<br>
    <br>
    <tt>MEGACO/1 [123.123.123.1]:11111&nbsp;&nbsp;&nbsp; (MG &lt;- MGC) <br>
      &nbsp;Transaction = 10 {<br>
      &nbsp;&nbsp; Context = $ {<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add = ISDNTerm/<font color="#cc0000"><b>BA17-BA18-PRI1</b></font>/D/$

      {<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media { Stream = 1<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {<br>
      &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Local { v=0<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c=ISDN SAPI 16 BA17<br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </tt><tt>m=data TEI 1 PLP<br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </tt><tt>c=ISDN SAPI 16 BA17<br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </tt><tt>m=data TEI 6 PLP<br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </tt><tt>c=ISDN SAPI 16 BA18<br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </tt><tt>m=data TEI 3 PLP<br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </tt><tt>c=ISDN SAPI 16 PRI1<br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </tt><tt>m=data TEI 9 PLP<br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </tt><tt>} } },<br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </tt><tt>Add = HDLCPW1 {<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media { Stream = 1 {<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # &#8211;-Descriptores Local/Remote-- } } }<br>
      &nbsp;} }</tt><br>
    <br>
    Here, I found two serious problems:<br>
    <br>
    + We are defining a termination which has ISDN D-channels from
    different physical interfaces/UNIs (<tt>BA17-BA18-PRI1</tt>
    indicates UNI BRI "17", UNI BRI "18" and UNI PRI "1"). I think it <span
      id="result_box" class="short_text" lang="en"><span class="hps">contradicts
        the definition of</span> <span class="hps">terminationss
        proposed by</span></span> H.248.1.<br>
    <br>
    + We are describing several SDP flows (m=) in the Local Descriptor,
    but these flows are multiplexing <span id="result_box"
      class="short_text" lang="en"><span class="hps">in their respective</span>
      <span class="hps">channels</span> <span class="hps">D (</span></span><span
      id="result_box" class="" lang="en"><span class="hps">the situation
        is not</span> <span class="hps">that:</span> a<span class="hps">
        flow</span> <span class="hps">is transmitted</span> <span
        class="hps">and,</span> <span class="hps">until it</span> <span
        class="hps">ends,</span> <span class="hps">no</span> <span
        class="hps">other flow</span> <span class="hps">is transmitted;
      </span><span class="hps">But all</span> <span class="hps"></span><span
        class="hps">flows are</span> <span class="hps"></span></span><span
      id="result_box" class="" lang="en"><span class="hps">simultaneous</span>
    </span><span id="result_box" class="" lang="en"><span class="hps">transmitted</span></span><span
      id="result_box" class="" lang="en"><span class="hps">, being </span></span><span
      id="result_box" class="" lang="en"><span class="hps">differentiated
        by</span> <span class="hps">the head</span>er <span
        class="hps">of the</span> <span class="hps">LAPD</span> <span
        class="hps">frames</span><span class="">).</span></span><br>
    <br>
    <br>
    If we use MeGaCo properties to specify the TEI and SAPI, it would
    have the same problems.<br>
    <br>
    Javi<br>
    <br>
    <br>
    El 28/10/2011 3:23, Christian Groves escribi&oacute;:
    <blockquote cite="mid:4EAA0413.5040007@nteczone.com" type="cite">Hello
      Javi,
      <br>
      <br>
      I'm not aware of any SDP that would allow you to specify the TEI
      and SAPI. Probably the closest draft to doing this was Tom's draft
      <a class="moz-txt-link-freetext" href="http://tools.ietf.org/id/draft-taylor-mmusic-sdp-tdm-01.txt">http://tools.ietf.org/id/draft-taylor-mmusic-sdp-tdm-01.txt</a>.
      <br>
      <br>
      Rather than use SDP you probably need to create a new package with
      two properties that allow you to indicate the SAPI and TEI. Each
      property would be a sub-list allowing you to indicate with SAPIs
      and TEIs apply to the stream. You probably wouldn't need multiple
      StreamIDs in this case.
      <br>
      <br>
      Regards, Christian
      <br>
      <br>
      On 25/10/2011 10:51 PM, Javi Mu&ntilde;oz wrote:
      <br>
      <blockquote type="cite">Hello Christian,
        <br>
        <br>
        Thank you for your answer.
        <br>
        <br>
        I understand MeGaCo syntax doesn't support adding streams in the
        multiplex descriptor neither including N in the multiplex
        descriptor.
        <br>
        <br>
        [Christian] A little, I understand the termination aspect. I'm
        still not sure about the streams. I don't understand how you can
        have multiple H.248 streams for the circuit termination TermA
        and TermB? With what information element (i.e. property) do you
        assign the SAPI and TEI to a Stream? What properties distinguish
        the Nx64K termination from a HDLCW1 one?
        <br>
        [Christian] I'm not 100% sure what you're trying to do but if
        you're only using a single Termination to represent each
        D-channel and a single Termination for the HDLCPW it seems to me
        that you don't need a mux termination and that it may be
        sufficient to simply use a property to assign TEIs to Streams
        (or Terminations).
        <br>
        [Christian] I think you're trying to solve this at a different
        level than what it should be. The multiplex descriptor describe
        the multiplex of terminations used to make up a stream. It
        doesn't describe what's happening at a stream level itself. We
        have the Stream Descriptor with associated (Local, Remote,
        LocalControl descriptors) to do this.
        <br>
        <br>
        <br>
        In ISDN, each D-channel (channel of 16 or 64 kbps) transport
        multiple flows muliplexed by its TEI and SAPI in the Q.921
        header.
        <br>
        <br>
        Every of these flows may need to be transported to a different
        server in the IP network, and each server may receive only a
        HDLCPW. So, I need to multiplex multiple D-channel flows in each
        HDLCPW. In each HDLCPW, each flow would be distinguished by its
        TEI/SAPI and D-channel identifier.
        <br>
        <br>
        I can not think how to describe in SDP (Local, Remote,
        LocalControl descriptors) what D-channel flows must be
        transported by any HDLCPW. May you proposed an example?
        <br>
        <br>
        Regards,
        <br>
        <br>
        Javier Mu&ntilde;oz
        <br>
        <blockquote type="cite">
          <blockquote type="cite">
            <br>
            <br>
            <blockquote type="cite">
              <br>
              <br>
              <br>
              Regards,
              <br>
              <br>
              Javi Mu&ntilde;oz
              <br>
              <br>
              <br>
              El 20/10/2011 11:12, Christian Groves escribi&oacute;:
              <br>
              <blockquote type="cite">Hello Javi,
                <br>
                <br>
                Did you see my email on the 18/10 which discusses this?
                Even with
                <br>
                the clarification of the Terminations there's some
                questions.
                <br>
                <br>
                Regards, Christian
                <br>
                <br>
                On 20/10/2011 7:38 PM, Javi Mu&ntilde;oz wrote:
                <br>
                <blockquote type="cite">Does MeGaCo support the next
                  contexts?:
                  <br>
                  <br>
                  <br>
                  <br>
Tmux1=Mux(1x64K(TermA/StreamID=1,TermA/StreamID=2,TermB/StreamID=1))
                  <br>
                  -- * -- TermC (HDLCPW1)
                  <br>
                  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |
                  <br>
                  TermA (ISDN D-Channel, UNI p)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |
                  <br>
                  &nbsp;&nbsp; StreamID=1 (SAPI 16, TEI r)------|
                  <br>
                  &nbsp;&nbsp; StreamID=2 (SAPI 16, TEI s)------|
                  <br>
                  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |
                  <br>
                  TermB (ISDN D-Channel, UNI q)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |
                  <br>
                  &nbsp;&nbsp; StreamID=1 (SAPI 16, TEI r)------|
                  <br>
                  &nbsp;&nbsp; StreamID=2 (SAPI 16, TEI s)------------|
                  <br>
                  &nbsp;&nbsp; StreamID=3 (SAPI 16, TEI t)------------|
                  <br>
                  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |
                  <br>
                  <br>
                  Tmux2=Mux(1x64K(TermB/StreamID=2,TermB/StreamID=3) --
                  * -- TermD
                  <br>
                  (HDLCPW2)
                  <br>
                  <br>
                  <br>
                  where:
                  <br>
                  <br>
                  (a) Every multiplex termination is multiplexing
                  Streams from
                  <br>
                  different ISDN terminations, and only any Streams of
                  each
                  <br>
                  termination.
                  <br>
                  <br>
                  (b) The result of the multiplexion must be a flow of
                  "64 kbps".
                  <br>
                  <br>
                  Javi Mu&ntilde;oz
                  <br>
                  _______________________________________________
                  <br>
                  Megaco mailing list
                  <br>
                  <a class="moz-txt-link-abbreviated" href="mailto:Megaco@ietf.org">Megaco@ietf.org</a>
                  <br>
                  <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/megaco">https://www.ietf.org/mailman/listinfo/megaco</a>
                  <br>
                  <br>
                </blockquote>
                _______________________________________________
                <br>
                Megaco mailing list
                <br>
                <a class="moz-txt-link-abbreviated" href="mailto:Megaco@ietf.org">Megaco@ietf.org</a>
                <br>
                <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/megaco">https://www.ietf.org/mailman/listinfo/megaco</a>
                <br>
                <br>
              </blockquote>
              <br>
              <br>
            </blockquote>
            <br>
          </blockquote>
        </blockquote>
        <br>
        _______________________________________________
        <br>
        Megaco mailing list
        <br>
        <a class="moz-txt-link-abbreviated" href="mailto:Megaco@ietf.org">Megaco@ietf.org</a>
        <br>
        <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/megaco">https://www.ietf.org/mailman/listinfo/megaco</a>
        <br>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------030002080409010604020802--

From Christian.Groves@nteczone.com  Sun Oct 30 16:28:18 2011
Return-Path: <Christian.Groves@nteczone.com>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E311F0C49 for <megaco@ietfa.amsl.com>; Sun, 30 Oct 2011 16:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level: 
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OIID5q5nPXh for <megaco@ietfa.amsl.com>; Sun, 30 Oct 2011 16:28:18 -0700 (PDT)
Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5A83D1F0C42 for <megaco@ietf.org>; Sun, 30 Oct 2011 16:28:16 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApMBAEvbrU520XmW/2dsb2JhbAAMN6w3AQEBAQIBAQEBLwEFGxsLEAsYCSUPAhYwBg0BBQIBAYd+CLJOiQIEpgE
Received: from ppp118-209-121-150.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.121.150]) by ipmail05.adl6.internode.on.net with ESMTP; 31 Oct 2011 09:58:15 +1030
Message-ID: <4EADDD8C.30509@nteczone.com>
Date: Mon, 31 Oct 2011 10:28:12 +1100
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: =?windows-1252?Q?Javi_Mu=F1oz?= <javi@trajano.us.es>
References: <4E980EF1.4020407@trajano.us.es>	<BLU0-SMTP5B76027A65AB404533C34D8E70@phx.gbl>	<4E9C185E.1090902@trajano.us.es>	<4E9D5509.4040105@trajano.us.es> <4E9FDE1A.4050207@trajano.us.es> <4E9FE5EF.6070907@nteczone.com> <4E9FEA09.3080900@trajano.us.es> <4EA62075.3060404@nteczone.com> <4EA6A2D4.2050903@trajano.us.es> <4EAA0413.5040007@nteczone.com> <4EAA7E0C.50807@trajano.us.es>
In-Reply-To: <4EAA7E0C.50807@trajano.us.es>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "megaco@ietf.org" <megaco@ietf.org>
Subject: Re: [Megaco] Multiple Streams and mutiplex terminations
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Sun, 30 Oct 2011 23:28:19 -0000

Hello Javi,

Please see my replies below.

Regards, Christian

On 28/10/2011 9:03 PM, Javi Muñoz wrote:
> Hello Christian,
>
> If we use SDP, an example could be:
>
> MEGACO/1 [123.123.123.1]:11111 (MG <- MGC)
> Transaction = 10 {
> Context = $ {
> Add = ISDNTerm/*BA17-BA18-PRI1*/D/$ {
> Media { Stream = 1
> {
> Local { v=0
> c=ISDN SAPI 16 BA17
> m=data TEI 1 PLP
> c=ISDN SAPI 16 BA17
> m=data TEI 6 PLP
> c=ISDN SAPI 16 BA18
> m=data TEI 3 PLP
> c=ISDN SAPI 16 PRI1
> m=data TEI 9 PLP
> } } },
> Add = HDLCPW1 {
> Media { Stream = 1 {
> # –-Descriptores Local/Remote-- } } }
> } }
>
> Here, I found two serious problems:
[CNG] Attached there's more the above SDP isn't valid. You can't have 
more than one m= line per stream. You can have the "reserve group" 
concept (7.1.7&7.1.8/H.248.1) but the above SDP doesn't match that either.
>
> + We are defining a termination which has ISDN D-channels from 
> different physical interfaces/UNIs (BA17-BA18-PRI1 indicates UNI BRI 
> "17", UNI BRI "18" and UNI PRI "1"). I think it contradicts the 
> definition of terminationss proposed by H.248.1.

[CNG] Yes, so why do you propose a single Termination? Why not add the 
interfaces via multiple Terminations to the Context?

>
> + We are describing several SDP flows (m=) in the Local Descriptor, 
> but these flows are multiplexing in their respective channels D (the 
> situation is not that: aflow is transmitted and, until it ends, no 
> other flow is transmitted; But all flows are simultaneous transmitted, 
> being differentiated by the header of the LAPD frames).
[CNG] OK, I still don't see why you need to specifically label these 
flows via a Stream or SDP m= line.
>
>
> If we use MeGaCo properties to specify the TEI and SAPI, it would have 
> the same problems.
[CNG] Not necessarily.

Below is an example of the use of two properties TEI and SAPI (I haven't 
proposed a descriptor could be LocalControl). By assigning the numbers 
to different termination it indicates which sub-flows go where. i.e. the 
HDLCPW1 termination has flows with TEI=1,3,9 but not 6.

ISDNTerm/BA17
StreamID=1(TEI=[1,6],SAPI=16) \
\
ISDNTerm/BA18 \ HDLCPW1
StreamID=1(TEI=[3],SAPI=16) ---*----- StreamID=1 (TEI=[1,3,9],SAPI=16)
/
ISDNTerm/BA19 /
StreamID=1(TEI=[9],SAPI=16) /




>
> Javi
>
>
> El 28/10/2011 3:23, Christian Groves escribió:
>> Hello Javi,
>>
>> I'm not aware of any SDP that would allow you to specify the TEI and 
>> SAPI. Probably the closest draft to doing this was Tom's draft 
>> http://tools.ietf.org/id/draft-taylor-mmusic-sdp-tdm-01.txt.
>>
>> Rather than use SDP you probably need to create a new package with 
>> two properties that allow you to indicate the SAPI and TEI. Each 
>> property would be a sub-list allowing you to indicate with SAPIs and 
>> TEIs apply to the stream. You probably wouldn't need multiple 
>> StreamIDs in this case.
>>
>> Regards, Christian
>>
>> On 25/10/2011 10:51 PM, Javi Muñoz wrote:
>>> Hello Christian,
>>>
>>> Thank you for your answer.
>>>
>>> I understand MeGaCo syntax doesn't support adding streams in the 
>>> multiplex descriptor neither including N in the multiplex descriptor.
>>>
>>> [Christian] A little, I understand the termination aspect. I'm still 
>>> not sure about the streams. I don't understand how you can have 
>>> multiple H.248 streams for the circuit termination TermA and TermB? 
>>> With what information element (i.e. property) do you assign the SAPI 
>>> and TEI to a Stream? What properties distinguish the Nx64K 
>>> termination from a HDLCW1 one?
>>> [Christian] I'm not 100% sure what you're trying to do but if you're 
>>> only using a single Termination to represent each D-channel and a 
>>> single Termination for the HDLCPW it seems to me that you don't need 
>>> a mux termination and that it may be sufficient to simply use a 
>>> property to assign TEIs to Streams (or Terminations).
>>> [Christian] I think you're trying to solve this at a different level 
>>> than what it should be. The multiplex descriptor describe the 
>>> multiplex of terminations used to make up a stream. It doesn't 
>>> describe what's happening at a stream level itself. We have the 
>>> Stream Descriptor with associated (Local, Remote, LocalControl 
>>> descriptors) to do this.
>>>
>>>
>>> In ISDN, each D-channel (channel of 16 or 64 kbps) transport 
>>> multiple flows muliplexed by its TEI and SAPI in the Q.921 header.
>>>
>>> Every of these flows may need to be transported to a different 
>>> server in the IP network, and each server may receive only a HDLCPW. 
>>> So, I need to multiplex multiple D-channel flows in each HDLCPW. In 
>>> each HDLCPW, each flow would be distinguished by its TEI/SAPI and 
>>> D-channel identifier.
>>>
>>> I can not think how to describe in SDP (Local, Remote, LocalControl 
>>> descriptors) what D-channel flows must be transported by any HDLCPW. 
>>> May you proposed an example?
>>>
>>> Regards,
>>>
>>> Javier Muñoz
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Javi Muñoz
>>>>>>
>>>>>>
>>>>>> El 20/10/2011 11:12, Christian Groves escribió:
>>>>>>> Hello Javi,
>>>>>>>
>>>>>>> Did you see my email on the 18/10 which discusses this? Even with
>>>>>>> the clarification of the Terminations there's some questions.
>>>>>>>
>>>>>>> Regards, Christian
>>>>>>>
>>>>>>> On 20/10/2011 7:38 PM, Javi Muñoz wrote:
>>>>>>>> Does MeGaCo support the next contexts?:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Tmux1=Mux(1x64K(TermA/StreamID=1,TermA/StreamID=2,TermB/StreamID=1)) 
>>>>>>>>
>>>>>>>> -- * -- TermC (HDLCPW1)
>>>>>>>> |
>>>>>>>> TermA (ISDN D-Channel, UNI p) |
>>>>>>>> StreamID=1 (SAPI 16, TEI r)------|
>>>>>>>> StreamID=2 (SAPI 16, TEI s)------|
>>>>>>>> |
>>>>>>>> TermB (ISDN D-Channel, UNI q) |
>>>>>>>> StreamID=1 (SAPI 16, TEI r)------|
>>>>>>>> StreamID=2 (SAPI 16, TEI s)------------|
>>>>>>>> StreamID=3 (SAPI 16, TEI t)------------|
>>>>>>>> |
>>>>>>>>
>>>>>>>> Tmux2=Mux(1x64K(TermB/StreamID=2,TermB/StreamID=3) -- * -- TermD
>>>>>>>> (HDLCPW2)
>>>>>>>>
>>>>>>>>
>>>>>>>> where:
>>>>>>>>
>>>>>>>> (a) Every multiplex termination is multiplexing Streams from
>>>>>>>> different ISDN terminations, and only any Streams of each
>>>>>>>> termination.
>>>>>>>>
>>>>>>>> (b) The result of the multiplexion must be a flow of "64 kbps".
>>>>>>>>
>>>>>>>> Javi Muñoz
>>>>>>>> _______________________________________________
>>>>>>>> Megaco mailing list
>>>>>>>> Megaco@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/megaco
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Megaco mailing list
>>>>>>> Megaco@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/megaco
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> Megaco mailing list
>>> Megaco@ietf.org
>>> https://www.ietf.org/mailman/listinfo/megaco
>>>
>>
>

From javi@trajano.us.es  Mon Oct 31 03:19:57 2011
Return-Path: <javi@trajano.us.es>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACEE21F8C5B for <megaco@ietfa.amsl.com>; Mon, 31 Oct 2011 03:19:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1I873-xzosYq for <megaco@ietfa.amsl.com>; Mon, 31 Oct 2011 03:19:57 -0700 (PDT)
Received: from mail.us.es (mail.us.es [193.147.175.20]) by ietfa.amsl.com (Postfix) with ESMTP id 84AD221F8C13 for <megaco@ietf.org>; Mon, 31 Oct 2011 03:19:55 -0700 (PDT)
Received: (qmail 6123 invoked from network); 31 Oct 2011 11:19:52 +0100
Received: from unknown (HELO us.es) (192.168.2.11) by us.es with SMTP; 31 Oct 2011 11:19:52 +0100
Received: (qmail 22350 invoked by uid 507); 31 Oct 2011 10:19:50 -0000
Received: from 127.0.0.1 by antivirus1 (envelope-from <javi@trajano.us.es>, uid 501) with qmail-scanner-2.08 (clamdscan: 0.97.3/13869.   Clear:RC:1(127.0.0.1):.  Processed in 0.962771 secs); 31 Oct 2011 10:19:50 -0000
Received: from unknown (HELO antivirus1) (127.0.0.1) by us.es with SMTP; 31 Oct 2011 10:19:49 -0000
Received: from 192.168.1.13 (192.168.1.13) by antivirus1 (F-Secure/fsigk_smtp/406/antivirus1); Mon, 31 Oct 2011 11:19:49 +0100 (CET)
X-Virus-Status: clean(F-Secure/fsigk_smtp/406/antivirus1)
Received: (qmail 17967 invoked from network); 31 Oct 2011 11:19:49 +0100
Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 31 Oct 2011 11:19:49 +0100
Received: from [127.0.0.1] (112.pool85-56-79.dynamic.orange.es [85.56.79.112]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id p9VAJlFM027506 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 31 Oct 2011 11:19:48 +0100
Message-ID: <4EAE763F.3020502@trajano.us.es>
Date: Mon, 31 Oct 2011 11:19:43 +0100
From: Javi <javi@trajano.us.es>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: "megaco@ietf.org" <megaco@ietf.org>
References: <4E980EF1.4020407@trajano.us.es>	<BLU0-SMTP5B76027A65AB404533C34D8E70@phx.gbl>	<4E9C185E.1090902@trajano.us.es>	<4E9D5509.4040105@trajano.us.es> <4E9FDE1A.4050207@trajano.us.es> <4E9FE5EF.6070907@nteczone.com> <4E9FEA09.3080900@trajano.us.es> <4EA62075.3060404@nteczone.com> <4EA6A2D4.2050903@trajano.us.es> <4EAA0413.5040007@nteczone.com> <4EAA7E0C.50807@trajano.us.es> <4EADDD8C.30509@nteczone.com>
In-Reply-To: <4EADDD8C.30509@nteczone.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Megaco] Multiple Streams and mutiplex terminations
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 31 Oct 2011 10:19:58 -0000

Hello Christian,

[CNG] Attached there's more the above SDP isn't valid. You can't have 
more than one m= line per stream. You can have the "reserve group" 
concept (7.1.7&7.1.8/H.248.1) but the above SDP doesn't match that either.

[Javi] Of course, I agree. It would be something like:

MEGACO/1 [123.123.123.1]:11111    (MG <- MGC)
  Transaction = 10 {
    Context = $ {
      Add = ISDNTerm/BA17-BA18-PRI1/D/$ {
         Media { Stream = 1
         {
           LocalControl {
               Mode = ReceiveOnly,
               ReserveGroup = True,
               ReserveValue = True },
           Local { v=0
                   c=ISDN SAPI 16 BA17
                   m=data TEI 1 PLP
v=0
c=ISDN SAPI 16 BA17
m=data TEI 6 PLP
v=0
c=ISDN SAPI 16 BA18
m=data TEI 3 PLP
v=0
c=ISDN SAPI 16 PRI1
m=data TEI 9 PLP
} } },
     Add = HDLCPW1 { Media { Stream = 1 { # –-Descriptores 
Local/Remote-- } } }
  } }


> [CNG] Below is an example of the use of two properties TEI and SAPI (I 
> haven't proposed a descriptor could be LocalControl). By assigning the 
> numbers to different termination it indicates which sub-flows go 
> where. i.e. the HDLCPW1 termination has flows with TEI=1,3,9 but not 6.
>
> ISDNTerm/BA17
> StreamID=1(TEI=[1,6],SAPI=16)\
>                               \
> ISDNTerm/BA18                  \       HDLCPW1
> StreamID=1(TEI=[3],SAPI=16) ---*----- StreamID=1 (TEI=[1,3,9],SAPI=16)
>                                /
> ISDNTerm/BA19                 /
> StreamID=1(TEI=[9],SAPI=16)  /
>

[Javi] Ok. But there is tow problems:

a) "ISDNTern/BA17/[TEI 6]" would be transported on HDLCPW2. How would 
you model the context?. I think the next option is not possible:


ISDNTerm/BA17
StreamID=1(TEI=[1,6],SAPI=16)\
                               \   ---- HDLCPW1
ISDNTerm/BA18                  \ / StreamID=1 (TEI=[1,3,9],SAPI=16)
StreamID=1(TEI=[3],SAPI=16) ----*
                                / \
ISDNTerm/BA19                 /   ----HDLCPW2
StreamID=1(TEI=[9],SAPI=16)  /         StreamID=1 (TEI=[6], SAPI=16)


b) "ISDNTerm/BA17/[TEI 1]" may be transported on HDLCPW1 but 
""ISDNTerm/BA18/[TEI 1]" may be transported on HDLCPW2. How would you 
model this?. You would need to indicate the termination name in the 
properties:

ISDNTerm/BA17
StreamID=1(TEI=[1,6],SAPI=16)\
                               \   ---- HDLCPW1
ISDNTerm/BA18                  \ / StreamID=1 
(TEI=[1-ISDNTerm/BA17,9-ISDNTerm/BA19],SAPI=16)
StreamID=1(TEI=[1],SAPI=16) ----*
                                / \
ISDNTerm/BA19                 /   ----HDLCPW2
StreamID=1(TEI=[9],SAPI=16)  /         StreamID=1 
(TEI=[6-ISDNTerm/BA17,1-ISDNTerm/BA18],SAPI=16)



[CNG] Yes, so why do you propose a single Termination? Why not add the 
interfaces via multiple Terminations to the Context?

[Javi] Yes. Indeed, this woud be my solution to the problem: Create an 
ephemeral termination for each flow, including flows of HDLCPWs:

ISDNTerm/BA17/D/SAPI16,TEI1 --- * --- HDLCPW1/BA17/D/SAPI16,TEI1

ISDNTerm/BA17/D/SAPI16,TEI6 --- * --- HDLCPW2/BA17/D/SAPI16,TEI6

ISDNTerm/BA18/D/SAPI16,TEI1 --- * --- HDLCPW2/BA18/D/SAPI16,TEI1

ISDNTerm/BA19/D/SAPI16,TEI9 --- * --- HDLCPW1/BA19/D/SAPI16,TEI9


I think this is possible.


Thanks,

Javi

From Christian.Groves@nteczone.com  Mon Oct 31 17:50:33 2011
Return-Path: <Christian.Groves@nteczone.com>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4041F0DC6 for <megaco@ietfa.amsl.com>; Mon, 31 Oct 2011 17:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.403
X-Spam-Level: 
X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9v+GpPYdUIAH for <megaco@ietfa.amsl.com>; Mon, 31 Oct 2011 17:50:33 -0700 (PDT)
Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id E9D2E1F0C49 for <megaco@ietf.org>; Mon, 31 Oct 2011 17:50:32 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApMBAE1Br0520ZYb/2dsb2JhbAAMN6wtAQEBAQIBOBsmBQsLISUPAkYGDQEHAQEXh2e0PIkCBKYB
Received: from ppp118-209-150-27.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.150.27]) by ipmail06.adl6.internode.on.net with ESMTP; 01 Nov 2011 11:20:31 +1030
Message-ID: <4EAF4252.60403@nteczone.com>
Date: Tue, 01 Nov 2011 11:50:26 +1100
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Javi <javi@trajano.us.es>
References: <4E980EF1.4020407@trajano.us.es>	<BLU0-SMTP5B76027A65AB404533C34D8E70@phx.gbl>	<4E9C185E.1090902@trajano.us.es>	<4E9D5509.4040105@trajano.us.es> <4E9FDE1A.4050207@trajano.us.es> <4E9FE5EF.6070907@nteczone.com> <4E9FEA09.3080900@trajano.us.es> <4EA62075.3060404@nteczone.com> <4EA6A2D4.2050903@trajano.us.es> <4EAA0413.5040007@nteczone.com> <4EAA7E0C.50807@trajano.us.es> <4EADDD8C.30509@nteczone.com> <4EAE763F.3020502@trajano.us.es>
In-Reply-To: <4EAE763F.3020502@trajano.us.es>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "megaco@ietf.org" <megaco@ietf.org>
Subject: Re: [Megaco] Multiple Streams and mutiplex terminations
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 01 Nov 2011 00:50:34 -0000

Hello Javi,

Please see my comments below.

Regards, Christian

..snip..
>
>> [CNG] Below is an example of the use of two properties TEI and SAPI 
>> (I haven't proposed a descriptor could be LocalControl). By assigning 
>> the numbers to different termination it indicates which sub-flows go 
>> where. i.e. the HDLCPW1 termination has flows with TEI=1,3,9 but not 6.
>>
>> ISDNTerm/BA17
>> StreamID=1(TEI=[1,6],SAPI=16)\
>>                               \
>> ISDNTerm/BA18                  \       HDLCPW1
>> StreamID=1(TEI=[3],SAPI=16) ---*----- StreamID=1 (TEI=[1,3,9],SAPI=16)
>>                                /
>> ISDNTerm/BA19                 /
>> StreamID=1(TEI=[9],SAPI=16)  /
>>
>
> [Javi] Ok. But there is tow problems:
>
> a) "ISDNTern/BA17/[TEI 6]" would be transported on HDLCPW2. How would 
> you model the context?. I think the next option is not possible:
>
>
> ISDNTerm/BA17
> StreamID=1(TEI=[1,6],SAPI=16)\
>                               \   ---- HDLCPW1
> ISDNTerm/BA18                  \ / StreamID=1 (TEI=[1,3,9],SAPI=16)
> StreamID=1(TEI=[3],SAPI=16) ----*
>                                / \
> ISDNTerm/BA19                 /   ----HDLCPW2
> StreamID=1(TEI=[9],SAPI=16)  /         StreamID=1 (TEI=[6], SAPI=16)
>
>
[CNG] Why do you think its not possible? I can't see the issue. By using 
the TEI=[6] parameter all you're saying is "only transport frames 
related to TEI=[6] in this stream".

> b) "ISDNTerm/BA17/[TEI 1]" may be transported on HDLCPW1 but 
> ""ISDNTerm/BA18/[TEI 1]" may be transported on HDLCPW2. How would you 
> model this?. You would need to indicate the termination name in the 
> properties:
>
> ISDNTerm/BA17
> StreamID=1(TEI=[1,6],SAPI=16)\
>                               \   ---- HDLCPW1
> ISDNTerm/BA18                  \ / StreamID=1 
> (TEI=[1-ISDNTerm/BA17,9-ISDNTerm/BA19],SAPI=16)
> StreamID=1(TEI=[1],SAPI=16) ----*
>                                / \
> ISDNTerm/BA19                 /   ----HDLCPW2
> StreamID=1(TEI=[9],SAPI=16)  /         StreamID=1 
> (TEI=[6-ISDNTerm/BA17,1-ISDNTerm/BA18],SAPI=16)
>
[CNG] I suspected we'd end up at this case. It sounds like you're trying 
to turn a single Context into an entire router to get around the fact 
that you can't have a single physical termination in multiple contexts. 
Have a look at H.248.64 to see how we handled that for an IP router. How 
many more Terminations do you envisage in a Context?

You could add TerminationID to the TEI parameter, but if you're having 
lots of Termination it may quickly become complicated.
>
>
> [CNG] Yes, so why do you propose a single Termination? Why not add the 
> interfaces via multiple Terminations to the Context?
>
> [Javi] Yes. Indeed, this woud be my solution to the problem: Create an 
> ephemeral termination for each flow, including flows of HDLCPWs:
>
> ISDNTerm/BA17/D/SAPI16,TEI1 --- * --- HDLCPW1/BA17/D/SAPI16,TEI1
>
> ISDNTerm/BA17/D/SAPI16,TEI6 --- * --- HDLCPW2/BA17/D/SAPI16,TEI6
>
> ISDNTerm/BA18/D/SAPI16,TEI1 --- * --- HDLCPW2/BA18/D/SAPI16,TEI1
>
> ISDNTerm/BA19/D/SAPI16,TEI9 --- * --- HDLCPW1/BA19/D/SAPI16,TEI9
>
>
> I think this is possible.
[CNG] A ephemeral Termination for an ISDN termination? These are 
typically physical terminations.

>
>
> Thanks,
>
> Javi
>