From tarun2.gupta@aricent.com Mon Oct 3 04:37:20 2011 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 To: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

Hi All

 

Does Megaco offer any solution to IPv= 4 address space exhaustion in CPE/residential implementations?

 

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?

 

Regards,

Tarun Gupta<= /p>

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_-- From arindam.bhattacharjee@alcatel-lucent.com Mon Oct 3 07:03:29 2011 Return-Path: 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 ; 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 ; 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 ; 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)" To: Tarun2 Gupta , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

Hi Tarun,

Megaco is transport mode independent protocol, in general

H248.67 defines packages for various transport modes support= ed 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 exhaustio= n in CPE/residential implementations?

 

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?

 

Regards,<= /p>

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_-- From Raju.Makaraju@alcatel-lucent.com Mon Oct 3 08:36:51 2011 Return-Path: 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 ; 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 ; 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 ; 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)" To: "Bhattacharjee, Arindam (Arindam)" , Tarun2 Gupta , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Tarun,
 
VLANs can be used to have overlapped IP address=20 space.
VLAN ids in signaling interface (NOT the bearer, = ;for=20 which there is a VLAN pkg H.248.56) is outside the scope of h.248=20 recommendation.
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).
 
Best Regards
Raju 

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

Hi=20 Tarun,

Megaco=20 is transport mode independent protocol, in general

H248.67=20 defines packages for various transport modes supported by=20 H.248.

 

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

 

-Arindam

 

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

 




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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=20 refer to http://www.aricent.com/legal/email_disclaimer.html
for import= ant=20 disclosures regarding this electronic=20 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

<= /BODY> --_000_31939CE9629A7F46885A9F97CEA9BF577B540920USNAVSXCHMBSD3n_-- From javi@trajano.us.es Fri Oct 14 03:28:53 2011 Return-Path: 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 ; 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 ; 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 ; 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 , 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?= 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; Fri, 14 Oct 2011 04:27:21 -0700 (PDT) Received: by eyg24 with SMTP id 24so1098447eyg.31 for ; 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 Date: Fri, 14 Oct 2011 13:27:00 +0200 Message-ID: To: =?ISO-8859-1?Q?Javi_Mu=F1oz?= Content-Type: text/plain; charset=ISO-8859-1 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 , 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?= 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" References: <4E980EF1.4020407@trajano.us.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Claudio Fontana 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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)" To: =?iso-8859-1?Q?Javi_Mu=F1oz?= , "megaco@ietf.org" , Christian Groves 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> <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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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: 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 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?= 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 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?= References: <4E980EF1.4020407@trajano.us.es> <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" , Claudio Fontana 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 , 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?= 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" References: <4E980EF1.4020407@trajano.us.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Claudio Fontana 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 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?= References: <4E980EF1.4020407@trajano.us.es> <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" , Claudio Fontana 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 , 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 ; 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?= 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" References: <4E980EF1.4020407@trajano.us.es> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 , 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 ; 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?= 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" References: <4E980EF1.4020407@trajano.us.es> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 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> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 , 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?= 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" References: <4E980EF1.4020407@trajano.us.es> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 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?= References: <4E980EF1.4020407@trajano.us.es> <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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 , 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 ; 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?= 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" References: <4E980EF1.4020407@trajano.us.es> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 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?= References: <4E980EF1.4020407@trajano.us.es> <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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 , 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?= 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" References: <4E980EF1.4020407@trajano.us.es> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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: a flow 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-- From Christian.Groves@nteczone.com Sun Oct 30 16:28:18 2011 Return-Path: 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 ; 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 ; 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 ; 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 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?= References: <4E980EF1.4020407@trajano.us.es> <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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 , 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 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" References: <4E980EF1.4020407@trajano.us.es> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 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 References: <4E980EF1.4020407@trajano.us.es> <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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 >