From: Javi Mu=F1oz [mailto:javi@trajano.us.es]=20
Sent: Dienstag, 1. Februar 2011 14:07
To: megaco@ietf.org
Subject: Re:=20 [Megaco] TDMPW and MeGaCo/SDP

H.248 MUX terminati= on (N=20 x B channels) is a good choice at ISDN termination.

But, at IP= =20 side, we still need to describe TDMoIP in SDP. For instance, we may=20 propose any like this:

m=3Daudio <puerto> RTP/AVP=20 <PT_din=E1mico>
a=3Drtpmap:<PT_din=E1mico>=20 TDMoIP/8000

El 31/01/2011 16:54, Schwarz, Albr= echt=20 (Albrecht) escribi=F3:=20 Just some high-le= vel=20 indications:

Multirate means effec= tively=20 N-out-of-K (with K =3D 24 or 30 dependent on ANSI /ETSI markets; an= d 1=20 < N <=3D K).

That's a first=20 requirement.

Secondly, the selecti= on of=20 channels may be random, they must not be in consecutive order (e.g.= ,=20 think about the permutations for N =3D 5).

Thirdly, there could = be a=20 dependency of the choosen CESoIP emulation service to the H.248=20 connection model.

Possible solution: H.= 248 MUX=20 termination ... at the high-level ...

From: Javi [mailto:javi@trajano.us.es]
Se= nt:=20 Montag, 31. Januar 2011 11:47
To: megaco@ietf.org
Subject: R= e:=20 [Megaco] TDMPW and MeGaCo/SDP

I agree, TDMoIP= is=20 an option only.

But, if it is used, MGC would use SDP at=20 Local/Remote MeGaCo descriptors. How may be that SDP description = for=20 TDMoIP?

However, there w= as never=20 any H.248 Profile standardized with=20 multirate support, at least to my=20 knowledge.

(I'm aware of vendor s= pecific=20 profile, but that are proprietary solutions.)

I w= ould be=20 interested to know any of that proprietary solutions. May you ind= icate=20 me any?

__
Y.2262 PSTN/ISDN emu= lation=20 and simulation, Appendix IV
Examples of emulation of PSTN an= d=20 N-ISDN bearer services
(This appendix does not form= an=20 integral part of this Recommendation)

Examples for the=20 emulation of PSTN and N-ISDN bearer services are provided:
<= BR>1)=20 Monorate bearer services (=3D 1 =D7 64-kbit/s digital bearer in= =20 PSTN/ISDN)
=95 ITU-T Recommendations I.231.2 and I.231.3 may= be=20 emulated by a single RTP
session, with or without RTP contro= l=20 protocol (RTCP), using an RTP profile according
to IETF RFC= =20 3551.
=95 ITU-T Recommendation I.231.1 may be emulated by a = single=20 RTP session, with or
without RTCP, using RTP clearmode accor= ding=20 to IETF RFC 4040.

2) Multirate bearer services (=3D N = =D7=20 64-kbit/s digital bearer in PSTN/ISDN; N greater than one)
= =95=20 ITU-T Recommendations I.231.4 to I.231.10 may be emulated by TD= MoIP=20 described
in ITU-T Recommendation=20 Y.1453.

> -----Original=20 Message-----
> From: megaco-bounces@ietf.org
> [<= A=20 href=3D"mailto:megaco-bounces@ietf.org"=20 moz-do-not-send=3D"true">mailto:megaco-bounces@ietf.org] On= Behalf=20 Of Javi
> Sent: Samstag, 29. Januar 2011 02:13
> To= : megaco@ietf.org
> Subject: [= Megaco]=20 TDMPW and MeGaCo/SDP
>
> Assuming the next=20 situation:
>
> ISDN Terminal 1 -   = MG1=20 - [IP network] - MG2   -   ISDN= =20 Terminal 2
>
> where the MGs (Media Gateway) are=20 controlled by a MGC (Media Gateway
> Controller) via=20 MeGaCo[H.248.1].
>
> [ITU-T Y.2262 / Annex IV] prop= osses=20 that MGs may transport
> ISDN B-channels over the IP=20 network:
>
> + By a single RTP session (when=20 monochannels ISDN services)
>
> + Or by TDMoIP (=3D= UDP=20 TDMPWs), when multichannels ISDN services.
>
>
&= gt;=20 How may MGC indicate to the MG that it uses PWs at the IP=20 termination?
>
> It may be done by MeGaCo, using=20 SDP[RFC4566] at Local/Remote
> descriptors. However, how = may=20 be that SDP description of TDMPWs?
>
>=20 Thanks,
>
> Javier Mu=F1oz
>
>
>= =20 _______________________________________________
> Megaco= =20 mailing list
> Megaco@ietf.org
> https://www.ietf.org/mailman/listinfo/= megaco
>=20

--_000_5F7BCCF5541B7444830A2288ABBEBC961D5001937BFRMRSSXCHMBSD_-- From javi@trajano.us.es Wed Feb 2 16:39:12 2011 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FBD83A63D2 for ; Wed, 2 Feb 2011 16:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ldwdemjuO25 for ; Wed, 2 Feb 2011 16:39:00 -0800 (PST) Received: from mail.us.es (mail.us.es [193.147.175.20]) by core3.amsl.com (Postfix) with ESMTP id 18FCC3A6359 for ; Wed, 2 Feb 2011 16:38:57 -0800 (PST) Received: (qmail 25034 invoked from network); 3 Feb 2011 01:42:18 +0100 Received: from unknown (HELO us.es) (192.168.2.13) by us.es with SMTP; 3 Feb 2011 01:42:18 +0100 Received: (qmail 5720 invoked by uid 507); 3 Feb 2011 00:42:10 -0000 Received: from 127.0.0.1 by antivirus3 (envelope-from , uid 501) with qmail-scanner-2.08 (clamdscan: 0.96.5/12616. Clear:RC:1(127.0.0.1):. Processed in 0.136159 secs); 03 Feb 2011 00:42:10 -0000 Received: from unknown (HELO antivirus3) (127.0.0.1) by us.es with SMTP; 3 Feb 2011 00:42:10 -0000 Received: from 192.168.1.13 (192.168.1.13) by antivirus3 (F-Secure/fsigk_smtp/403/antivirus3); Thu, 03 Feb 2011 01:42:10 +0100 (CET) X-Virus-Status: clean(F-Secure/fsigk_smtp/403/antivirus3) Received: (qmail 21202 invoked from network); 3 Feb 2011 01:42:09 +0100 Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 3 Feb 2011 01:42:09 +0100 Received: from [192.168.1.40] (70.Red-83-36-250.dynamicIP.rima-tde.net [83.36.250.70]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id p130g7cU028010; Thu, 3 Feb 2011 01:42:08 +0100 Message-ID: <4D49F9CF.2000901@trajano.us.es> Date: Thu, 03 Feb 2011 01:41:51 +0100 From: Javi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "megaco@ietf.org" References: <4D4369B7.3020100@trajano.us.es> <5F7BCCF5541B7444830A2288ABBEBC961D50018F98@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <4D46933D.6000505@trajano.us.es> <5F7BCCF5541B7444830A2288ABBEBC961D500190D7@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <4D480581.7020605@trajano.us.es> <5F7BCCF5541B7444830A2288ABBEBC961D50019244@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <4D493265.8000102@trajano.us.es> <5F7BCCF5541B7444830A2288ABBEBC961D5001937B@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> In-Reply-To: <5F7BCCF5541B7444830A2288ABBEBC961D5001937B@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------000900090409070609090804" Subject: Re: [Megaco] TDMPW and MeGaCo/SDP X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 00:39:12 -0000 This is a multi-part message in MIME format. --------------000900090409070609090804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Albrecht and all, I agree with you, but we must take into account the pseudowires establishment procedures (that is what meant with "PW control plane"). I will try to justify the scenario. An ISDN terminal connected to the IP network via an access gateway, communicating with a another ISDN terminal. The AGW relays the ISDN signalling to an MGC, which controls the AGW media by using Megaco. I'm interested in supporting multichannel services. I'm exploring TDMPWs (like [IETF RFC 5087]) to convey the data flows over the IP network. The TDMPW is establish between both access gateways (then, each one is an PE): |ISDN TE| [1xD channel ] --> |AGW| <--> MGC (Q.931/SIP)<--> |AGW| <-- [1xD channel ] |ISDN TE| |_______| [NxB channels] --> |___| <--------[TDMPW]-------->|___| <-- [NxB channels] |_______| * TE: Terminal equipment * AGW: Access Gateway and PE (Provider Edge) * MGC: Media Gateway Controller 1º An ISDN TE sends and Q.931 SETUP message to establish an ISDN multichannel call. 2º Upon receiving that ISDN signaling message, the MGC must tell the AGW (using MeGaCo/SDP) that it has to set up a TDMoIP PW, with the proper parameters (for instance, the IP address of the other end/AGW). This is a similar case to the Megaco messages indicating the IP address and UDP ports for RTP-based monocanal flows. 3º AGW sets up the TDMPW with the other AGW, using pseudowires establishment procedures. Then, NxB channels from one ISDN terminals are convey to the other ISDN TE via this TDMPW (PW data plane) Without the MeGaCo/SDP indication (step "2º"), the AGW will not know what to do with the incoming ISDN B channels. I think it justifies why these MeGaCo/SDP description is needed Javier Muñoz El 20:59, Schwarz, Albrecht (Albrecht) escribió: > What "could be enough" is of course a subjective position, because a > conditional statement. > You got two options: develop a generic solution (eg., a set of > (mandatory & optional) SDP elements for controlling Y.1453 TDMoIP IWF > types) or to specify your aimed deployment scenario via an H.248 profile. > The profile approach allows to distinguish signalled and provisioned > parameter values. A profile would reflect specific network deployment > scenarios, supported Y.1453 capabilities by H.248 MGs, supported "ISDN > multirate call service applications" at MGC level, etc. > The ratio between signalled and provisioned parameter values may vary > fundamentally between 100% and 0%. > E.g., 100% parameter signalling in case of a H.320 multirate call and > multiple mode of Y.1453 IWF support. > E.g., 0% signalling (i.e., all values provisioned) for the > interconnection of two ISDN PBX (and emulation service of > semi-permanent connections; perhaps indicated via H.248.21). > Again, such use cases would be subject of the H.248 profile > specification, operated between the MGC and MG. > > ------------------------------------------------------------------------ > *From:* Javi [mailto:javi@trajano.us.es] > *Sent:* Mittwoch, 2. Februar 2011 11:31 > *To:* megaco@ietf.org > *Cc:* Schwarz, Albrecht (Albrecht); Christian.Groves@nteczone.com > *Subject:* Re: [Megaco] TDMPW and MeGaCo/SDP > > Hi Albrecht, Christian and all, > > >> /To H.248 Media Descriptor for IP bearer:/ >> >> * >> /your proposal would be insufficient, Y.1453 defines not a >> single, but multiple possible modes of TDMoIP interworking! / >> * >> /See § 7.2/Y.1453 concerning information elements for >> TDMoIP control (=> ´correspondent SDP must be defined if >> the Y.1453 provisioning approach would be replaced by an >> SDP-based signalling approach (for TDMoIP IWFs embedded in >> H.248 MGs or SIP VoiceGateways)./ >> > > That's right, but we must take into account that TDMPW parameters > may be negotiate by the PW control plane. > > So, I think it could be enough that MGC, by MeGaCo/SDP, indicates > to the MG that it must use a TDMPW "codec" and the address of the > other PW edge. > > c=IN IP4 333.333.1.1 > m=audio RTP/AVP > a=rtpmap: TDMoIP/8000 > >> / >> /To H.248 Media Descriptor for TDM bearer:/ >> >> * >> /the MUX approach is just an option!/ >> * >> /alternatives, e.g., the "the group-and-member scheme >> (addrtype is "GRP")" as proposed by Tom in his SDP-TDM >> draft >> (http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01.txt)/ >> >> / >> // >> // >> >> ------------------------------------------------------------------------ >> *From:* Javi Muñoz [mailto:javi@trajano.us.es] >> *Sent:* Dienstag, 1. Februar 2011 14:07 >> *To:* megaco@ietf.org >> *Subject:* Re: [Megaco] TDMPW and MeGaCo/SDP >> >> H.248 MUX termination (N x B channels) is a good choice at >> ISDN termination. >> >> But, at IP side, we still need to describe TDMoIP in SDP. For >> instance, we may propose any like this: >> >> m=audio RTP/AVP >> a=rtpmap: TDMoIP/8000 >> >> >> >> >> >> El 31/01/2011 16:54, Schwarz, Albrecht (Albrecht) escribió: >>> /Just some high-level indications:/ >>> // >>> /Multirate means effectively N-out-of-K (with K = 24 or 30 >>> dependent on ANSI /ETSI markets; and 1 < N <= K)./ >>> /That's a first requirement./ >>> /Secondly, the selection of channels may be random, they >>> must not be in consecutive order (e.g., think about the >>> permutations for N = 5)./ >>> /Thirdly, there could be a dependency of the choosen CESoIP >>> emulation service to the H.248 connection model./ >>> // >>> /Possible solution: H.248 MUX termination ... at the >>> high-level .../ >>> // >>> >>> ------------------------------------------------------------------------ >>> *From:* Javi [mailto:javi@trajano.us.es] >>> *Sent:* Montag, 31. Januar 2011 11:47 >>> *To:* megaco@ietf.org >>> *Subject:* Re: [Megaco] TDMPW and MeGaCo/SDP >>> >>> I agree, TDMoIP is an option only. >>> >>> But, if it is used, MGC would use SDP at Local/Remote >>> MeGaCo descriptors. How may be that SDP description for >>> TDMoIP? >>> >>>> However, there was never any H.248 Profile standardized >>>> with /*multirate*/ support, at least to my knowledge. >>>> (I'm aware of vendor specific profile, but that are >>>> proprietary solutions.) >>>> >>> >>> I would be interested to know any of that proprietary >>> solutions. May you indicate me any? >>> >>>> >>>> __ >>>> /*Y.2262 PSTN/ISDN emulation and simulation, Appendix IV >>>> Examples of emulation of PSTN and N-ISDN bearer services >>>> *(This appendix does not form an integral part of this >>>> Recommendation) >>>> >>>> Examples for the emulation of PSTN and N-ISDN bearer >>>> services are provided: >>>> >>>> 1) Monorate bearer services (= 1 × 64-kbit/s digital >>>> bearer in PSTN/ISDN) >>>> . ITU-T Recommendations I.231.2 and I.231.3 may be >>>> emulated by a single RTP >>>> session, with or without RTP control protocol (RTCP), >>>> using an RTP profile according >>>> to IETF RFC 3551. >>>> . ITU-T Recommendation I.231.1 may be emulated by a >>>> single RTP session, with or >>>> without RTCP, using RTP clearmode according to IETF RFC >>>> 4040. >>>> >>>> 2) Multirate bearer services (= N × 64-kbit/s digital >>>> bearer in PSTN/ISDN; N greater than one) >>>> . ITU-T Recommendations I.231.4 to I.231.10 may be >>>> emulated by TDMoIP described >>>> in ITU-T Recommendation Y.1453. >>>> >>>> / >>>> > -----Original Message----- >>>> > From: megaco-bounces@ietf.org >>>> > [mailto:megaco-bounces@ietf.org] On Behalf Of Javi >>>> > Sent: Samstag, 29. Januar 2011 02:13 >>>> > To: megaco@ietf.org >>>> > Subject: [Megaco] TDMPW and MeGaCo/SDP >>>> > >>>> > Assuming the next situation: >>>> > >>>> > ISDN Terminal 1 - MG1 - [IP network] - MG2 - >>>> ISDN Terminal 2 >>>> > >>>> > where the MGs (Media Gateway) are controlled by a MGC >>>> (Media Gateway >>>> > Controller) via MeGaCo[H.248.1]. >>>> > >>>> > [ITU-T Y.2262 / Annex IV] proposses that MGs may >>>> transport >>>> > ISDN B-channels over the IP network: >>>> > >>>> > + By a single RTP session (when monochannels ISDN >>>> services) >>>> > >>>> > + Or by TDMoIP (= UDP TDMPWs), when multichannels >>>> ISDN services. >>>> > >>>> > >>>> > How may MGC indicate to the MG that it uses PWs at >>>> the IP termination? >>>> > >>>> > It may be done by MeGaCo, using SDP[RFC4566] at >>>> Local/Remote >>>> > descriptors. However, how may be that SDP description >>>> of TDMPWs? >>>> > >>>> > Thanks, >>>> > >>>> > Javier Muñoz >>>> > >>>> > >>>> > _______________________________________________ >>>> > Megaco mailing list >>>> > Megaco@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/megaco >>>> > >>> >> > --------------000900090409070609090804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Albrecht and all,

I agree with you, but we must take into account the pseudowires establishment procedures (that is what meant with "PW control plane").

I will try to justify the scenario.

An ISDN terminal connected to the IP network via
an access gateway, communicating with a another ISDN terminal. The AGW relays the ISDN
signalling to an MGC, which controls the AGW media by using Megaco.

I'm interested in supporting multichannel services. I'm exploring TDMPWs (like [IETF RFC 5087]) to convey the data flows over the IP network. The TDMPW is establish between both access gateways (then, each one is an PE):

|ISDN TE| [1xD channel ] --> |AGW| <--> MGC (Q.931/SIP)<--> |AGW| <-- [1xD channel ] |ISDN TE| |_______| [NxB channels] --> |___| <--------[TDMPW]-------->|___| <-- [NxB channels] |_______|

* TE: Terminal equipment
* AGW: Access Gateway and PE (Provider Edge)
* MGC: Media Gateway Controller

1º An ISDN TE sends and Q.931 SETUP message to establish an ISDN multichannel call.

2º Upon receiving that ISDN signaling message, the MGC must tell the AGW (using MeGaCo/SDP) that it has to set up a TDMoIP PW, with the
proper parameters (for instance, the IP address of the other end/AGW). This is a similar case to the Megaco messages indicating the IP address and UDP ports
for RTP-based monocanal flows.

3º AGW sets up the TDMPW with the other AGW, using pseudowires establishment procedures. Then, NxB channels from one ISDN terminals are convey to the other ISDN TE via this TDMPW (PW data plane)

Without the MeGaCo/SDP indication (step "2º"), the AGW will not know what to do with the incoming ISDN B channels.

I think it justifies why these MeGaCo/SDP description is needed

Javier Muñoz

El 20:59, Schwarz, Albrecht (Albrecht) escribió:

What "could be enough" is of course a subjective position, because a conditional statement.

You got two options: develop a generic solution (eg., a set of (mandatory & optional) SDP elements for controlling Y.1453 TDMoIP IWF types) or to specify your aimed deployment scenario via an H.248 profile.

The profile approach allows to distinguish signalled and provisioned parameter values. A profile would reflect specific network deployment scenarios, supported Y.1453 capabilities by H.248 MGs, supported "ISDN multirate call service applications" at MGC level, etc.

The ratio between signalled and provisioned parameter values may vary fundamentally between 100% and 0%.

E.g., 100% parameter signalling in case of a H.320 multirate call and multiple mode of Y.1453 IWF support.

E.g., 0% signalling (i.e., all values provisioned) for the interconnection of two ISDN PBX (and emulation service of semi-permanent connections; perhaps indicated via H.248.21).

Again, such use cases would be subject of the H.248 profile specification, operated between the MGC and MG.

From: Javi [mailto:javi@trajano.us.es]
Sent: Mittwoch, 2. Februar 2011 11:31
To: megaco@ietf.org
Cc: Schwarz, Albrecht (Albrecht); Christian.Groves@nteczone.com
Subject: Re: [Megaco] TDMPW and MeGaCo/SDP

Hi Albrecht, Christian and all,

To H.248 Media Descriptor for IP bearer:

your proposal would be insufficient, Y.1453 defines not a single, but multiple possible modes of TDMoIP interworking!

See § 7.2/Y.1453 concerning information elements for TDMoIP control (=> ´correspondent SDP must be defined if the Y.1453 provisioning approach would be replaced by an SDP-based signalling approach (for TDMoIP IWFs embedded in H.248 MGs or SIP VoiceGateways).

That's right, but we must take into account that TDMPW parameters may be negotiate by the PW control plane.

So, I think it could be enough that MGC, by MeGaCo/SDP, indicates to the MG that it must use a TDMPW "codec" and the address of the other PW edge.

c=IN IP4 333.333.1.1
m=audio <port> RTP/AVP <Dynamic_PT>
a=rtpmap:<Dynamic_PT> TDMoIP/8000

To H.248 Media Descriptor for TDM bearer:

the MUX approach is just an option!

alternatives, e.g., the "the group-and-member scheme (addrtype is "GRP")" as proposed by Tom in his SDP-TDM draft (http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01.txt)

From: Javi Muñoz [mailto:javi@trajano.us.es]
Sent: Dienstag, 1. Februar 2011 14:07
To: megaco@ietf.org
Subject: Re: [Megaco] TDMPW and MeGaCo/SDP

H.248 MUX termination (N x B channels) is a good choice at ISDN termination.

But, at IP side, we still need to describe TDMoIP in SDP. For instance, we may propose any like this:

m=audio <puerto> RTP/AVP <PT_dinámico>
a=rtpmap:<PT_dinámico> TDMoIP/8000

El 31/01/2011 16:54, Schwarz, Albrecht (Albrecht) escribió:

Just some high-level indications:

Multirate means effectively N-out-of-K (with K = 24 or 30 dependent on ANSI /ETSI markets; and 1 < N <= K).

That's a first requirement.

Secondly, the selection of channels may be random, they must not be in consecutive order (e.g., think about the permutations for N = 5).

Thirdly, there could be a dependency of the choosen CESoIP emulation service to the H.248 connection model.

Possible solution: H.248 MUX termination ... at the high-level ...

From: Javi [mailto:javi@trajano.us.es]
Sent: Montag, 31. Januar 2011 11:47
To: megaco@ietf.org
Subject: Re: [Megaco] TDMPW and MeGaCo/SDP

I agree, TDMoIP is an option only.

But, if it is used, MGC would use SDP at Local/Remote MeGaCo descriptors. How may be that SDP description for TDMoIP?

However, there was never any H.248 Profile standardized with multirate support, at least to my knowledge.

(I'm aware of vendor specific profile, but that are proprietary solutions.)

I would be interested to know any of that proprietary solutions. May you indicate me any?

__
Y.2262 PSTN/ISDN emulation and simulation, Appendix IV
Examples of emulation of PSTN and N-ISDN bearer services
(This appendix does not form an integral part of this Recommendation)

Examples for the emulation of PSTN and N-ISDN bearer services are provided:

1) Monorate bearer services (= 1 × 64-kbit/s digital bearer in PSTN/ISDN)
• ITU-T Recommendations I.231.2 and I.231.3 may be emulated by a single RTP
session, with or without RTP control protocol (RTCP), using an RTP profile according
to IETF RFC 3551.
• ITU-T Recommendation I.231.1 may be emulated by a single RTP session, with or
without RTCP, using RTP clearmode according to IETF RFC 4040.

2) Multirate bearer services (= N × 64-kbit/s digital bearer in PSTN/ISDN; N greater than one)
• ITU-T Recommendations I.231.4 to I.231.10 may be emulated by TDMoIP described
in ITU-T Recommendation Y.1453.

> -----Original Message-----
> From: megaco-bounces@ietf.org
> [mailto:megaco-bounces@ietf.org] On Behalf Of Javi
> Sent: Samstag, 29. Januar 2011 02:13
> To: megaco@ietf.org
> Subject: [Megaco] TDMPW and MeGaCo/SDP
>
> Assuming the next situation:
>
> ISDN Terminal 1 -   MG1 - [IP network] - MG2   -   ISDN Terminal 2
>
> where the MGs (Media Gateway) are controlled by a MGC (Media Gateway
> Controller) via MeGaCo[H.248.1].
>
> [ITU-T Y.2262 / Annex IV] proposses that MGs may transport
> ISDN B-channels over the IP network:
>
> + By a single RTP session (when monochannels ISDN services)
>
> + Or by TDMoIP (= UDP TDMPWs), when multichannels ISDN services.
>
>
> How may MGC indicate to the MG that it uses PWs at the IP termination?
>
> It may be done by MeGaCo, using SDP[RFC4566] at Local/Remote
> descriptors. However, how may be that SDP description of TDMPWs?
>
> Thanks,
>
> Javier Muñoz
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
>

--------------000900090409070609090804-- From albrecht.schwarz@alcatel-lucent.com Thu Feb 3 08:11:33 2011 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 330083A69E0 for ; Thu, 3 Feb 2011 08:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.428 X-Spam-Level: X-Spam-Status: No, score=-5.428 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdENuMhRXGMK for ; Thu, 3 Feb 2011 08:11:30 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 3A11F3A695D for ; Thu, 3 Feb 2011 08:11:28 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p13GEi4i021726 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Feb 2011 17:14:49 +0100 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.53]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 3 Feb 2011 17:14:44 +0100 From: "Schwarz, Albrecht (Albrecht)" To: Javi , "megaco@ietf.org" Date: Thu, 3 Feb 2011 17:14:43 +0100 Thread-Topic: RE: [Megaco] TDMPW and MeGaCo/SDP Thread-Index: AcvDOzvrQUIRZ6DETwGMcwy4qD79vQAgS0vg Message-ID: <5F7BCCF5541B7444830A2288ABBEBC961D50019606@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <4D4369B7.3020100@trajano.us.es> <5F7BCCF5541B7444830A2288ABBEBC961D50018F98@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <4D46933D.6000505@trajano.us.es> <5F7BCCF5541B7444830A2288ABBEBC961D500190D7@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <4D480581.7020605@trajano.us.es> <5F7BCCF5541B7444830A2288ABBEBC961D50019244@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <4D493265.8000102@trajano.us.es> <5F7BCCF5541B7444830A2288ABBEBC961D5001937B@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <4D49F9CF.2000901@trajano.us.es> In-Reply-To: <4D49F9CF.2000901@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: multipart/alternative; boundary="_000_5F7BCCF5541B7444830A2288ABBEBC961D50019606FRMRSSXCHMBSD_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [Megaco] TDMPW and MeGaCo/SDP X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 16:11:33 -0000 --_000_5F7BCCF5541B7444830A2288ABBEBC961D50019606FRMRSSXCHMBSD_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Javi, I don't object against this specific use case, but it's just a subset of Y.= 1453. Y.1453 TDMoIP and IETF PW architecture are complementary. You may apply Y.1= 453 also in a non-PW architecture. Thus, you would cover this specific use case in a, let's say, H.248 "Pseudo= wire TDMoIP" Profile, which would refer in the connection model, H.248 term= ination types, etc to the - PW architecture RFC 3985 - PW TDMoIP RFC 5087 - ... - PW TDMoIP MIB RFC 5604 concerning provisioned information. Thus, when starting this email discussion you should have already indicated= that you are just considering a specific network scenario, and not TDMoIP = in general. Regards, Albrecht ________________________________ From: Javi [mailto:javi@trajano.us.es] Sent: Donnerstag, 3. Februar 2011 01:42 To: megaco@ietf.org Subject: Re: RE: [Megaco] TDMPW and MeGaCo/SDP Hi Albrecht and all, I agree with you, but we must take into account the pseudowires establishme= nt procedures (that is what meant with "PW control plane"). I will try to justify the scenario. An ISDN terminal connected to the IP network via an access gateway, communicating with a another ISDN terminal. The AGW rela= ys the ISDN signalling to an MGC, which controls the AGW media by using Megaco. I'm interested in supporting multichannel services. I'm exploring TDMPWs (l= ike [IETF RFC 5087]) to convey the data flows over the IP network. The TDMP= W is establish between both access gateways (then, each one is an PE): |ISDN TE| [1xD channel ] --> |AGW| <--> MGC (Q.931/SIP)<--> |AGW| <-- [1xD = channel ] |ISDN TE| |_______| [NxB channels] --> |___| <--------[TDMPW]-------->|___| <-- [NxB = channels] |_______| * TE: Terminal equipment * AGW: Access Gateway and PE (Provider Edge) * MGC: Media Gateway Controller 1=BA An ISDN TE sends and Q.931 SETUP message to establish an ISDN multicha= nnel call. 2=BA Upon receiving that ISDN signaling message, the MGC must tell the AGW = (using MeGaCo/SDP) that it has to set up a TDMoIP PW, with the proper parameters (for instance, the IP address of the other end/AGW). This= is a similar case to the Megaco messages indicating the IP address and UDP= ports for RTP-based monocanal flows. 3=BA AGW sets up the TDMPW with the other AGW, using pseudowires establishm= ent procedures. Then, NxB channels from one ISDN terminals are convey to th= e other ISDN TE via this TDMPW (PW data plane) Without the MeGaCo/SDP indication (step "2=BA"), the AGW will not know what= to do with the incoming ISDN B channels. I think it justifies why these MeGaCo/SDP description is needed Javier Mu=F1oz El 20:59, Schwarz, Albrecht (Albrecht) escribi=F3: What "could be enough" is of course a subjective position, because a condit= ional statement. You got two options: develop a generic solution (eg., a set of (mandatory &= optional) SDP elements for controlling Y.1453 TDMoIP IWF types) or to spec= ify your aimed deployment scenario via an H.248 profile. The profile approach allows to distinguish signalled and provisioned parame= ter values. A profile would reflect specific network deployment scenarios, = supported Y.1453 capabilities by H.248 MGs, supported "ISDN multirate call = service applications" at MGC level, etc. The ratio between signalled and provisioned parameter values may vary funda= mentally between 100% and 0%. E.g., 100% parameter signalling in case of a H.320 multirate call and multi= ple mode of Y.1453 IWF support. E.g., 0% signalling (i.e., all values provisioned) for the interconnection = of two ISDN PBX (and emulation service of semi-permanent connections; perha= ps indicated via H.248.21). Again, such use cases would be subject of the H.248 profile specification, = operated between the MGC and MG. ________________________________ From: Javi [mailto:javi@trajano.us.es] Sent: Mittwoch, 2. Februar 2011 11:31 To: megaco@ietf.org Cc: Schwarz, Albrecht (Albrecht); Christian.Groves@nteczone.com Subject: Re: [Megaco] TDMPW and MeGaCo/SDP Hi Albrecht, Christian and all, To H.248 Media Descriptor for IP bearer: * your proposal would be insufficient, Y.1453 defines not a single, but multi= ple possible modes of TDMoIP interworking! * See =A7 7.2/Y.1453 concerning information elements for TDMoIP control (=3D>= =B4correspondent SDP must be defined if the Y.1453 provisioning approach w= ould be replaced by an SDP-based signalling approach (for TDMoIP IWFs embed= ded in H.248 MGs or SIP VoiceGateways). That's right, but we must take into account that TDMPW parameters may be ne= gotiate by the PW control plane. So, I think it could be enough that MGC, by MeGaCo/SDP, indicates to the MG= that it must use a TDMPW "codec" and the address of the other PW edge. c=3DIN IP4 333.333.1.1 m=3Daudio RTP/AVP a=3Drtpmap: TDMoIP/8000 To H.248 Media Descriptor for TDM bearer: * the MUX approach is just an option! * alternatives, e.g., the "the group-and-member scheme (addrtype is "GRP")" a= s proposed by Tom in his SDP-TDM draft (http://www.watersprings.org/pub/id/= draft-taylor-mmusic-sdp-tdm-01.txt) ________________________________ From: Javi Mu=F1oz [mailto:javi@trajano.us.es] Sent: Dienstag, 1. Februar 2011 14:07 To: megaco@ietf.org Subject: Re: [Megaco] TDMPW and MeGaCo/SDP H.248 MUX termination (N x B channels) is a good choice at ISDN termination= . But, at IP side, we still need to describe TDMoIP in SDP. For instance, we = may propose any like this: m=3Daudio RTP/AVP a=3Drtpmap: TDMoIP/8000 El 31/01/2011 16:54, Schwarz, Albrecht (Albrecht) escribi=F3: Just some high-level indications: Multirate means effectively N-out-of-K (with K =3D 24 or 30 dependent on AN= SI /ETSI markets; and 1 < N <=3D K). That's a first requirement. Secondly, the selection of channels may be random, they must not be in cons= ecutive order (e.g., think about the permutations for N =3D 5). Thirdly, there could be a dependency of the choosen CESoIP emulation servic= e to the H.248 connection model. Possible solution: H.248 MUX termination ... at the high-level ... ________________________________ From: Javi [mailto:javi@trajano.us.es] Sent: Montag, 31. Januar 2011 11:47 To: megaco@ietf.org Subject: Re: [Megaco] TDMPW and MeGaCo/SDP I agree, TDMoIP is an option only. But, if it is used, MGC would use SDP at Local/Remote MeGaCo descriptors. H= ow may be that SDP description for TDMoIP? However, there was never any H.248 Profile standardized with multirate supp= ort, at least to my knowledge. (I'm aware of vendor specific profile, but that are proprietary solutions.) I would be interested to know any of that proprietary solutions. May you in= dicate me any? __ Y.2262 PSTN/ISDN emulation and simulation, Appendix IV Examples of emulation of PSTN and N-ISDN bearer services (This appendix does not form an integral part of this Recommendation) Examples for the emulation of PSTN and N-ISDN bearer services are provided: 1) Monorate bearer services (=3D 1 =D7 64-kbit/s digital bearer in PSTN/ISD= N) * ITU-T Recommendations I.231.2 and I.231.3 may be emulated by a single RTP session, with or without RTP control protocol (RTCP), using an RTP profile = according to IETF RFC 3551. * ITU-T Recommendation I.231.1 may be emulated by a single RTP session, wit= h or without RTCP, using RTP clearmode according to IETF RFC 4040. 2) Multirate bearer services (=3D N =D7 64-kbit/s digital bearer in PSTN/IS= DN; N greater than one) * ITU-T Recommendations I.231.4 to I.231.10 may be emulated by TDMoIP descr= ibed in ITU-T Recommendation Y.1453. > -----Original Message----- > From: megaco-bounces@ietf.org > [mailto:megaco-bounces@ietf.org] On Behalf Of Javi > Sent: Samstag, 29. Januar 2011 02:13 > To: megaco@ietf.org > Subject: [Megaco] TDMPW and MeGaCo/SDP > > Assuming the next situation: > > ISDN Terminal 1 - MG1 - [IP network] - MG2 - ISDN Terminal 2 > > where the MGs (Media Gateway) are controlled by a MGC (Media Gateway > Controller) via MeGaCo[H.248.1]. > > [ITU-T Y.2262 / Annex IV] proposses that MGs may transport > ISDN B-channels over the IP network: > > + By a single RTP session (when monochannels ISDN services) > > + Or by TDMoIP (=3D UDP TDMPWs), when multichannels ISDN services. > > > How may MGC indicate to the MG that it uses PWs at the IP termination? > > It may be done by MeGaCo, using SDP[RFC4566] at Local/Remote > descriptors. However, how may be that SDP description of TDMPWs? > > Thanks, > > Javier Mu=F1oz > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco > --_000_5F7BCCF5541B7444830A2288ABBEBC961D50019606FRMRSSXCHMBSD_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Javi,

I don't object against this specific use case, but= it's=20 just a subset of Y.1453.

Y.1453 TDMoIP and IETF PW architecture are=20 complementary. You may apply Y.1453 also in a non-PW=20 architecture.

Thus, you would cover this specific use case in a,= let's=20 say, H.248 "Pseudowire TDMoIP" Profile, which would refer in the connection= =20 model, H.248 termination types, etc to the

- PW architecture RFC=20 3985

- PW TDMoIP RFC=20 5087

-=20 ...

- PW TDMoIP MIB RFC 5604 c= oncerning=20 provisioned information.

Thus, when starting this e= mail=20 discussion you should have already indicated that you are just considering = a=20 specific network scenario, and not TDMoIP in=20 general.

Regards,

Albrecht

From: Javi [mailto:javi@trajano.us.es= ]=20
Sent: Donnerstag, 3. Februar 2011 01:42
To:=20 megaco@ietf.org
Subject: Re: RE: [Megaco] TDMPW and=20 MeGaCo/SDP

Hi Albrecht and all,

I agree with you, but we must take= into=20 account the pseudowires establishment procedures (that is what meant with= "PW=20 control plane").

I will try to justify the scenario.

An ISD= N=20 terminal connected to the IP network via
an access gateway, communica= ting=20 with a another ISDN terminal. The AGW relays the ISDN
signalling to a= n=20 MGC, which controls the AGW media by using Megaco.

I'm interested= in=20 supporting multichannel services. I'm exploring TDMPWs (like [IETF RFC 50= 87])=20 to convey the data flows over the IP network. The TDMPW is establish betw= een=20 both access gateways (then, each one is an PE):

|ISDN TE| [1xD channel ] --> |AGW| <--> MGC (Q.931/SIP)<--> = |AGW| <-- [1xD channel ] |ISDN TE| |_______| [NxB channels] --> |_= __|=20 <--------[TDMPW]-------->|___| <-- [NxB channels] |_______|=20

* TE: Terminal equipment
* AGW: Access Gateway and PE=20 (Provider Edge)
* MGC: Media Gateway Controller

1=BA An ISDN T= E sends=20 and Q.931 SETUP message to establish an ISDN multichannel call.

2= =BA=20 Upon receiving that ISDN signaling message, the MGC must tell the AGW (us= ing=20 MeGaCo/SDP) that it has to set up a TDMoIP PW, with the
proper parame= ters=20 (for instance, the IP address of the other end/AGW). This is a similar ca= se to=20 the Megaco messages indicating the IP address and UDP ports
for RTP-b= ased=20 monocanal flows.

3=BA AGW sets up the TDMPW with the other AGW, u= sing=20 pseudowires establishment procedures. Then, NxB channels from one ISDN=20 terminals are convey to the other ISDN TE via this TDMPW (PW data=20 plane)

Without the MeGaCo/SDP indication (step "2=BA"), the AGW wi= ll not=20 know what to do with the incoming ISDN B channels.

I think it=20 justifies why these MeGaCo/SDP description is needed

Javier=20 Mu=F1oz

El 20:59, Schwarz, Albrecht (Albrecht) escribi=F3:=20
What "could be enough" is= of course=20 a subjective position, because a conditional statement.
You got two options: deve= lop a=20 generic solution (eg., a set of (mandatory & optional) SDP ele= ments=20 for controlling Y.1453 TDMoIP IWF types) or to specify your aimed deplo= yment=20 scenario via an H.248 profile.

&nb= sp;

The profile approach allo= ws to=20 distinguish signalled and provisioned parameter values. A profile would= =20 reflect specific network deployment scenarios, supported Y.1453 capabil= ities=20 by H.248 MGs, supported "ISDN multirate call service applications" at M= GC=20 level, etc.

&nb= sp;

The ratio between signall= ed and=20 provisioned parameter values may vary fundamentally between 100% and=20 0%.

E.g., 100% parameter sign= alling in=20 case of a H.320 multirate call and multiple mode of Y.1453 IWF=20 support.

E.g., 0% signalling (i.e.= , all=20 values provisioned) for the interconnection of two ISDN PBX (and emulat= ion=20 service of semi-permanent connections; perhaps indicated via=20 H.248.21).

&nb= sp;

Again, such use cases wou= ld be=20 subject of the H.248 profile specification, operated between the MGC an= d=20 MG.

From: Javi [mailto:javi@trajano.us.es]=20
Sent: Mittwoch, 2. Februar 2011 11:31
To: megaco@ietf.org
Cc: Sch= warz,=20 Albrecht (Albrecht); Christian.Groves@nteczo= ne.com
Subject:=20 Re: [Megaco] TDMPW and MeGaCo/SDP

Hi Albrecht,=20 Christian and all,

To H.248 Media Descriptor= for IP=20 bearer:

your proposal would be= =20 insufficient, Y.1453 defines not a single, but multiple possible = modes=20 of TDMoIP interworking!

See =A7 7.2/Y.1453 conc= erning=20 information elements for TDMoIP control (=3D> =B4correspondent= SDP must=20 be defined if the Y.1453 provisioning approach would be replaced = by an=20 SDP-based signalling approach (for TDMoIP IWFs embedded in H.248 = MGs=20 or SIP=20 VoiceGateways).

Th= at's=20 right, but we must take into account that TDMPW parameters may be=20 negotiate by the PW control plane.

So, I think it could be eno= ugh=20 that MGC, by MeGaCo/SDP, indicates to the MG that it must use a TDMPW= =20 "codec" and the address of the other PW edge.

c=3DIN IP4=20 333.333.1.1
m=3Daudio <port> RTP/AVP=20 <Dynamic_PT>
a=3Drtpmap:<Dynamic_PT> TDMoIP/8000

To H.248 Media Descriptor= =20 for TDM bearer:

the MUX approach is jus= t an=20 option!

alternatives, e.g., the= "the=20 group-and-member scheme (addrtype is "GRP")" as proposed by = Tom=20 in his SDP-TDM draft (http://www.watersprings.org/pub/id/draft= -taylor-mmusic-sdp-tdm-01.txt)

=

From: Javi Mu=F1oz [mailto:javi@trajano.us.es]
Se= nt:=20 Dienstag, 1. Februar 2011 14:07
To: megaco@ietf.org
Subject: R= e:=20 [Megaco] TDMPW and MeGaCo/SDP

H.248 MUX=20 termination (N x B channels) is a good choice at ISDN=20 termination.

But, at IP side, we still need to describe TD= MoIP=20 in SDP. For instance, we may propose any like this:

m=3Dau= dio=20 <puerto> RTP/AVP=20 <PT_din=E1mico>
a=3Drtpmap:<PT_din=E1mico>=20 TDMoIP/8000

El 31/01/2011 16:54, Schwarz,= =20 Albrecht (Albrecht) escribi=F3:=20
Just some hig= h-level=20 indications:

Multirate means e= ffectively=20 N-out-of-K (with K =3D 24 or 30 dependent on ANSI /ETSI markets= ; and 1=20 < N <=3D K).

That's a first=20 requirement.

Secondly, the sel= ection of=20 channels may be random, they must not be in consecutive order (= e.g.,=20 think about the permutations for N =3D 5).
Thirdly, there co= uld be a=20 dependency of the choosen CESoIP emulation service to the H.248= =20 connection model.

Possible solution= : H.248 MUX=20 termination ... at the high-level ...

From: Javi [mailto:javi@trajano.us.es]=20
Sent: Montag, 31. Januar 2011 11:47
To: = megaco@ietf.org
Subject: Re:=20 [Megaco] TDMPW and MeGaCo/SDP

I agree, TD= MoIP=20 is an option only.

But, if it is used, MGC would use S= DP at=20 Local/Remote MeGaCo descriptors. How may be that SDP descript= ion=20 for TDMoIP?

However, the= re was=20 never any H.248 Profile standardized with=20 multirate support, at least to my= =20 knowledge.

(I'm aware of vend= or=20 specific profile, but that are proprietary=20 solutions.)

<= BR>I=20 would be interested to know any of that proprietary solutions= . May=20 you indicate me any?

__
Y.2262 PSTN/ISDN= =20 emulation and simulation, Appendix IV
Examples of emulat= ion=20 of PSTN and N-ISDN bearer services
(This append= ix=20 does not form an integral part of this=20 Recommendation)

Examples for the emulation of PSTN a= nd=20 N-ISDN bearer services are provided:

1) Monorate bea= rer=20 services (=3D 1 =D7 64-kbit/s digital bearer in PSTN/ISDN)<= BR>=95=20 ITU-T Recommendations I.231.2 and I.231.3 may be emulated b= y a=20 single RTP
session, with or without RTP control protocol= =20 (RTCP), using an RTP profile according
to IETF RFC 3551.=
=95=20 ITU-T Recommendation I.231.1 may be emulated by a single RT= P=20 session, with or
without RTCP, using RTP clearmode accor= ding=20 to IETF RFC 4040.

2) Multirate bearer services (=3D = N =D7=20 64-kbit/s digital bearer in PSTN/ISDN; N greater than one)<= BR>=95=20 ITU-T Recommendations I.231.4 to I.231.10 may be emulated b= y=20 TDMoIP described
in ITU-T Recommendation=20 Y.1453.

> -----Original=20 Message-----
> From: megaco-bounces@ietf.org
>= ; [mailto:megaco-bounces@ietf.org= ] On=20 Behalf Of Javi
> Sent: Samstag, 29. Januar 2011=20 02:13
> To: megaco@ietf.org
> Subjec= t:=20 [Megaco] TDMPW and MeGaCo/SDP
>
> Assuming the = next=20 situation:
>
> ISDN Terminal 1 - &nb= sp;=20 MG1 - [IP network] - MG2   - &nb= sp;=20 ISDN Terminal 2
>
> where the MGs (Media Gatewa= y)=20 are controlled by a MGC (Media Gateway
> Controller) = via=20 MeGaCo[H.248.1].
>
> [ITU-T Y.2262 / Annex IV]= =20 proposses that MGs may transport
> ISDN B-channels ov= er=20 the IP network:
>
> + By a single RTP session (= when=20 monochannels ISDN services)
>
> + Or by TDMoIP = (=3D=20 UDP TDMPWs), when multichannels ISDN=20 services.
>
>
> How may MGC indicate to t= he MG=20 that it uses PWs at the IP termination?
>
> It = may=20 be done by MeGaCo, using SDP[RFC4566] at Local/Remote
&g= t;=20 descriptors. However, how may be that SDP description of=20 TDMPWs?
>
> Thanks,
>
> Javier=20 Mu=F1oz
>
>
>=20 _______________________________________________
> Meg= aco=20 mailing list
> Megaco@ietf.org
> https://www.ietf.org/mailman/listi= nfo/megaco
>=20

<= /BODY> --_000_5F7BCCF5541B7444830A2288ABBEBC961D50019606FRMRSSXCHMBSD_-- From javi@trajano.us.es Sun Feb 6 10:02:12 2011 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42603A6992 for ; Sun, 6 Feb 2011 10:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mUrc58WFKnO for ; Sun, 6 Feb 2011 10:02:12 -0800 (PST) Received: from mail.us.es (mail.us.es [193.147.175.20]) by core3.amsl.com (Postfix) with ESMTP id 5B35C3A68CB for ; Sun, 6 Feb 2011 10:02:10 -0800 (PST) Received: (qmail 21687 invoked from network); 6 Feb 2011 19:02:11 +0100 Received: from unknown (HELO us.es) (192.168.2.13) by us.es with SMTP; 6 Feb 2011 19:02:11 +0100 Received: (qmail 27972 invoked by uid 507); 6 Feb 2011 18:02:09 -0000 Received: from 127.0.0.1 by antivirus3 (envelope-from , uid 501) with qmail-scanner-2.08 (clamdscan: 0.96.5/12636. Clear:RC:1(127.0.0.1):. Processed in 0.031543 secs); 06 Feb 2011 18:02:09 -0000 Received: from unknown (HELO antivirus3) (127.0.0.1) by us.es with SMTP; 6 Feb 2011 18:02:09 -0000 Received: from 192.168.1.13 (192.168.1.13) by antivirus3 (F-Secure/fsigk_smtp/403/antivirus3); Sun, 06 Feb 2011 19:02:09 +0100 (CET) X-Virus-Status: clean(F-Secure/fsigk_smtp/403/antivirus3) Received: (qmail 5782 invoked from network); 6 Feb 2011 19:02:09 +0100 Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 6 Feb 2011 19:02:09 +0100 Received: from [192.168.1.40] (204.Red-83-60-209.dynamicIP.rima-tde.net [83.60.209.204]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id p16I265a003024; Sun, 6 Feb 2011 19:02:08 +0100 Message-ID: <4D4EE208.5070600@trajano.us.es> Date: Sun, 06 Feb 2011 19:01:44 +0100 From: Javi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "megaco@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: taylor@nortelnetworks.com Subject: [Megaco] GRP address type in MeGaCo/SDP for TDM X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 18:02:12 -0000 Hi Albrecht, Tom and all, About the use of the GRP address type, [draft-taylor-mmusic-sdp-tdm-01] proposes: The GRP scheme designates a logical or physical grouping of circuits within which individual 64 kbit/s channels may be identified by integer values. The GRP connection-address consists of two parts. The first part identifies the logical or physical group, while the second identifies the individual circuit within the group. grp-connection-address = group-part "/" member-part group-part = non-ws-string member-part = non-ws-string If we want to describe an ISDN mutichannel service with 3 B-channel (B1, B4, B7) belonging to the ISDN interface of the rack "A", I image a possible example would be: v=0 c=TDM GRP 1111/1 c=TDM GRP 1111/4 c=TDM GRP 1111/7 m=application 1 TDM octect-stream b=AS:64 # each channel of 64 kbps But, then: How does MGC and MG agree the group number of each ISDN interface (in the example, the "1111" number for the ISDN interface of the rack "A" (and similarly for member number "1,4,7" with the B1,B4,B7 channels, although the correlative numbering is a possibility here)? Regards, Javier Muñoz From albrecht.schwarz@alcatel-lucent.com Mon Feb 7 23:07:27 2011 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41C483A7032 for ; Mon, 7 Feb 2011 23:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.049 X-Spam-Level: X-Spam-Status: No, score=-5.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_111=0.6, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EUGUU9z5FWM for ; Mon, 7 Feb 2011 23:07:26 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 094883A6C9A for ; Mon, 7 Feb 2011 23:07:25 -0800 (PST) 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 p1877UEB020889 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Feb 2011 08:07:30 +0100 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.53]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 8 Feb 2011 08:07:30 +0100 From: "Schwarz, Albrecht (Albrecht)" To: Javi , "megaco@ietf.org" Date: Tue, 8 Feb 2011 08:07:29 +0100 Thread-Topic: [Megaco] GRP address type in MeGaCo/SDP for TDM Thread-Index: AcvGKAGYmvCPccEOS8WFHd6VjuBY+gBNaKfQ Message-ID: <5F7BCCF5541B7444830A2288ABBEBC961D500198F3@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <4D4EE208.5070600@trajano.us.es> In-Reply-To: <4D4EE208.5070600@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.64 on 155.132.188.80 Cc: "taylor@nortelnetworks.com" Subject: Re: [Megaco] GRP address type in MeGaCo/SDP for TDM X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 07:07:27 -0000 ... e.g. via Termination names, which are defined in H.248 PROFILEs. You could choose correspondent "Termination naming convention for TDM termi= nations", which satisfy your "grouping", hierarchical, physical, Layer 1, .= .. characteristics. For instance: ETSI TISPAN H.248 Profile for TGW ES 283 024 -> =A7 5.6.1.1 5.6.1.1.1.1 ABNF Grammar for H.248 Text Encoding Mode ABNF (RFC 4234 [26]) is used for the syntax specification. ABNF coding: pathName =3D TDMToken SLASH (PCMsystem / "*")=20 TDMToken =3D "tdm" PCMsystem =3D 0*(HierarchyLevelHIGHToken SLASH) HierarchyLevelLOWToken HierarchyLevelHIGHToken =3D (UnitTypeToken "_" UnitNumber) HierarchyLevelLOWToken =3D (UnitTypeToken "_" Wildcard) / Channel / Wildca= rd UnitTypeToken =3D "ChassisToken" / "SDHToken" / "SONETToken" / "PDHToken"=20 ChassisToken =3D "s" / "su" ; slot, sub-unit within slot SDHToken =3D "stm4" / "stm1" ; relevant is capacity, but not electrical or optical interface type SONETToken =3D "oc12" / "oc3"=20 PDHToken =3D "ds3" / "e3" / "ds2" / "e2" /"ds1" / "e1" ; ANSI & ETSI UnitNumber =3D 1*DIGIT=20 Channel =3D %d0-31 / %d0-23 ; value range E1/T1 system Wildcard =3D "*" ____ If your grouping concept wouldn't be already covered, then just extend the = naming scheme. See also AGW: ETSI TS 183002 V3.3.1, =A7 5.6.1.1 ... and extend if required /Albrecht =20 > -----Original Message----- > From: megaco-bounces@ietf.org=20 > [mailto:megaco-bounces@ietf.org] On Behalf Of Javi > Sent: Sonntag, 6. Februar 2011 19:02 > To: megaco@ietf.org > Cc: taylor@nortelnetworks.com > Subject: [Megaco] GRP address type in MeGaCo/SDP for TDM >=20 > Hi Albrecht, Tom and all, >=20 > About the use of the GRP address type,=20 > [draft-taylor-mmusic-sdp-tdm-01] > proposes: >=20 > The GRP scheme designates a logical or physical grouping of=20 > circuits within which individual 64 kbit/s channels may be=20 > identified by integer values. The GRP connection-address=20 > consists of two parts. > The first part identifies the logical or physical group,=20 > while the second identifies the individual circuit within the group. >=20 > grp-connection-address =3D group-part "/" member-part >=20 > group-part =3D non-ws-string > member-part =3D non-ws-string >=20 >=20 > If we want to describe an ISDN mutichannel service with 3=20 > B-channel (B1, B4, B7) belonging to the ISDN interface of the=20 > rack "A", I image a possible example would be: >=20 > v=3D0 > c=3DTDM GRP 1111/1 > c=3DTDM GRP 1111/4 > c=3DTDM GRP 1111/7 > m=3Dapplication 1 TDM octect-stream > b=3DAS:64 # each channel of 64 kbps >=20 >=20 > But, then: How does MGC and MG agree the group number of each=20 > ISDN interface (in the example, the "1111" number for the=20 > ISDN interface of the rack "A" (and similarly for member=20 > number "1,4,7" with the B1,B4,B7 channels, although the=20 > correlative numbering is a possibility here)? >=20 > Regards, >=20 > Javier Mu=F1oz > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco > = From Rudra.Singh@aricent.com Mon Feb 7 01:53:30 2011 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1119B3A6D78 for ; Mon, 7 Feb 2011 01:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAfoIjq4sZvo for ; Mon, 7 Feb 2011 01:53:29 -0800 (PST) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id 7BE643A6D7C for ; Mon, 7 Feb 2011 01:53:28 -0800 (PST) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 0ED5236B8E for ; Mon, 7 Feb 2011 15:20:35 +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 E148A36B87 for ; Mon, 7 Feb 2011 15:20:34 +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, 7 Feb 2011 15:23:27 +0530 From: Rudra Pratap Singh To: "megaco@ietf.org" Date: Mon, 7 Feb 2011 15:23:25 +0530 Thread-Topic: Megaco codec negotiation Thread-Index: AcvGrNzKwH8kt6nNTv2DntKEUtxwjA== Message-ID: <233DCD84F0DD4C4BA6376E8D12567A8E0A37D792AE@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_233DCD84F0DD4C4BA6376E8D12567A8E0A37D792AEGUREXMB01ASIA_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 08 Feb 2011 05:48:16 -0800 Subject: [Megaco] Megaco codec negotiation X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 09:54:56 -0000 --_000_233DCD84F0DD4C4BA6376E8D12567A8E0A37D792AEGUREXMB01ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I'm a fresher in Megaco area. I have some doubt regarding codec negotiation for audio and image in the fo= llowing scenario- Firstly there is negotiation of audio codec. And after successful audio negotiation , there is a modify command to one o= f the termination from MGC that contains image in local (L{image}) and an empty remote (R{}) can anyone please tell what should be the expected behaviour of MG? following is the pdu-- !/1 [192.168.0.203]:2944 T=3D347{C=3D2{MF=3Deph3{M{O{MO=3DIN},L{v=3D0 c=3DIN IP4 $ a=3Dptime:10 m=3Dimage $ udptl t38 },R{}}}}} and after this transaction ,if MGC send the folllwing !/1 [192.168.0.203]:2944 T=3D347{C=3D2{MF=3Deph3{M{O{MO=3DIN},L{v=3D0 c=3DIN IP4 $ a=3Dptime:10 m=3Daudio $ RTP/AVP 8 },R{}}} then what should be the reply of MG? Any information will be appreciated! Thanks & Regards, Rudra Pratap Singh ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." --_000_233DCD84F0DD4C4BA6376E8D12567A8E0A37D792AEGUREXMB01ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

I'm a fresher in Megaco area.
I have some doubt regarding codec negotiation for audio and image in the fo= llowing scenario-

Firstly there is negotiation of audio codec.
And after successful audio negotiation , there is a modify command to one o= f the termination from MGC
that contains image in local (L{image}) and an empty remote (R{})
can anyone please tell what should be the expected behaviour of MG?
following is the pdu--

!/1 [192.168.0.203]:2944 T=3D347{C= =3D2{MF=3Deph3{M{O{MO=3DIN},L{v=3D0=

c=3DIN IP4 $

a=3Dptime:10

m=3Dimage $ udptl t38

},R{}}}}}

and after this transaction ,if MGC send the folllwin= g

!/1 [192.168.0.203]:2944 T=3D347{C= =3D2{MF=3Deph3{M{O{MO=3DIN},L{v=3D0

c=3DIN IP4 $

a=3Dptime:10

m=3Daudio $ RTP/AVP 8

},R{}}}

then what should be the reply of MG?

Any information will be appreciated!

Thanks & Regards,

Rudra Pratap Singh

"DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than for what it is intended. If you have recei= ved this message in error, please notify the originator immediately. If you= are not the intended recipient, you are notified that you are strictly pro= hibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibil= ity for loss or damage arising from the use of the information transmitted = by this email including damage from virus."
--_000_233DCD84F0DD4C4BA6376E8D12567A8E0A37D792AEGUREXMB01ASIA_-- From albrecht.schwarz@alcatel-lucent.com Tue Feb 8 06:10:24 2011 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF633A6E16 for ; Tue, 8 Feb 2011 06:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.049 X-Spam-Level: X-Spam-Status: No, score=-5.049 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8o-HpVJ348K2 for ; Tue, 8 Feb 2011 06:10:23 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 96C3F3A6D9E for ; Tue, 8 Feb 2011 06:10:22 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p18E9eEX017443 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Feb 2011 15:10:25 +0100 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.53]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 8 Feb 2011 15:10:14 +0100 From: "Schwarz, Albrecht (Albrecht)" To: Rudra Pratap Singh , "megaco@ietf.org" Date: Tue, 8 Feb 2011 15:10:12 +0100 Thread-Topic: Megaco codec negotiation Thread-Index: AcvGrNzKwH8kt6nNTv2DntKEUtxwjAA7Am3Q Message-ID: <5F7BCCF5541B7444830A2288ABBEBC961D50019A19@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <233DCD84F0DD4C4BA6376E8D12567A8E0A37D792AE@GUREXMB01.ASIAN.AD.ARICENT.COM> In-Reply-To: <233DCD84F0DD4C4BA6376E8D12567A8E0A37D792AE@GUREXMB01.ASIAN.AD.ARICENT.COM> 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: multipart/alternative; boundary="_000_5F7BCCF5541B7444830A2288ABBEBC961D50019A19FRMRSSXCHMBSD_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [Megaco] Megaco codec negotiation X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:10:24 -0000 --_000_5F7BCCF5541B7444830A2288ABBEBC961D50019A19FRMRSSXCHMBSD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not sure whether this is meaningfull signalling at all: * modification to StreamMode 'inactive' ... and later change again? to? * the SDP for T.38 looks incorrect (what's the purpose of ptime?) Further: * Any H.248 Stream is bidirectional and the media format in each direction mi= ght be principally different ("asymmetric media"). If the MODIFY transactio= n would be successfull, then there would be different media formats in each= direction. * the notion of "codec negotiation" is OK on call control level, but not at H= .248 due to master-slave relationship. There isn't any negotiation. Rather = a resource reservation and committment concept. If you look for correct SDP example signaling, see eg. T.38 (2010) and V.15= 2 (2010). ________________________________ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of= Rudra Pratap Singh Sent: Montag, 7. Februar 2011 10:53 To: megaco@ietf.org Subject: [Megaco] Megaco codec negotiation Hi All, I'm a fresher in Megaco area. I have some doubt regarding codec negotiation for audio and image in the fo= llowing scenario- Firstly there is negotiation of audio codec. And after successful audio negotiation , there is a modify command to one o= f the termination from MGC that contains image in local (L{image}) and an empty remote (R{}) can anyone please tell what should be the expected behaviour of MG? following is the pdu-- !/1 [192.168.0.203]:2944 T=3D347{C=3D2{MF=3Deph3{M{O{MO=3DIN},L{v=3D0 c=3DIN IP4 $ a=3Dptime:10 m=3Dimage $ udptl t38 },R{}}}}} and after this transaction ,if MGC send the folllwing !/1 [192.168.0.203]:2944 T=3D347{C=3D2{MF=3Deph3{M{O{MO=3DIN},L{v=3D0 c=3DIN IP4 $ a=3Dptime:10 m=3Daudio $ RTP/AVP 8 },R{}}} then what should be the reply of MG? Any information will be appreciated! Thanks & Regards, Rudra Pratap Singh ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." --_000_5F7BCCF5541B7444830A2288ABBEBC961D50019A19FRMRSSXCHMBSD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Not sure whether this is meaningfull signalling = at=20 all:

modification to StreamMode 'inactive' ... and = later=20 change again? to?

the SDP for T.38 looks incorrect (what's the p= urpose=20 of ptime?)

Further:

Any H.248 Stream is bidirectional and the medi= a=20 format in each direction might be principally different ("asymmetric medi= a").=20 If the MODIFY transaction would be successfull= , then=20 there would be different media formats in each=20 direction.

the notion of "codec negotiation" is OK on cal= l=20 control level, but not at H.248 due to master-slave relationship. There i= sn't=20 any negotiation. Rather a resource reservation and committment=20 concept.

If you look for correct SDP example signaling, s= ee eg.=20 T.38 (2010) and V.152 (2010).

From: megaco-bounces@ietf.org=20 [mailto:megaco-bounces@ietf.org] On Behalf Of Rudra Pratap=20 Singh
Sent: Montag, 7. Februar 2011 10:53
To:=20 megaco@ietf.org
Subject: [Megaco] Megaco codec=20 negotiation

Hi All,

I'm a fresher in Megaco area.
I ha= ve some=20 doubt regarding codec negotiation for audio and image in the following=20 scenario-

Firstly there is negotiation of audio codec.
And afte= r=20 successful audio negotiation , there is a modify command to one of the=20 termination from MGC
that contains image in local (L{image}) and an em= pty=20 remote (R{})
can anyone please tell what should be the expected behavi= our=20 of MG?
following is the pdu--

!/1 [192.168.0.203]:2944=20 T=3D347{C=3D2{MF=3Deph3{M{O{MO=3DIN},L{v=3D0

c=3DIN IP4 $

a=3Dptime:10

m=3Dimage $ udptl t38

},R{}}}}}

and after this transaction ,if MGC send the=20 folllwing

!/1 [192.168.0.203]:2944=20 T=3D347{C=3D2{MF=3Deph3{M{O{MO=3DIN},L{v=3D0

c=3DIN IP4 $

a=3Dptime:10

m=3Daudio $ RTP/AVP 8

},R{}}}

then what should be the reply of MG?

An= y=20 information will be appreciated!

Thanks &=20 Regards,

Rudra Pratap=20 Singh

"DISCLAIMER: This message is pro= prietary to=20 Aricent and is intended solely for the use of the individual to whom it i= s=20 addressed. It may contain privileged or confidential information and shou= ld=20 not be circulated or used for any purpose other than for what it is inten= ded.=20 If you have received this message in error, please notify the originator= =20 immediately. If you are not the intended recipient, you are notified that= you=20 are strictly prohibited from using, copying, altering, or disclosing the= =20 contents of this message. Aricent accepts no responsibility for loss or d= amage=20 arising from the use of the information transmitted by this email includi= ng=20 damage from virus."
--_000_5F7BCCF5541B7444830A2288ABBEBC961D50019A19FRMRSSXCHMBSD_-- From javi@trajano.us.es Wed Feb 9 09:39:18 2011 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 031E63A69DE for ; Wed, 9 Feb 2011 09:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_72=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ab9vYxD-FJZE for ; Wed, 9 Feb 2011 09:39:17 -0800 (PST) Received: from mail.us.es (mail.us.es [193.147.175.20]) by core3.amsl.com (Postfix) with ESMTP id 894203A67A5 for ; Wed, 9 Feb 2011 09:39:16 -0800 (PST) Received: (qmail 10579 invoked from network); 9 Feb 2011 18:39:24 +0100 Received: from unknown (HELO us.es) (192.168.2.13) by us.es with SMTP; 9 Feb 2011 18:39:24 +0100 Received: (qmail 29761 invoked by uid 507); 9 Feb 2011 17:39:23 -0000 Received: from 127.0.0.1 by antivirus3 (envelope-from , uid 501) with qmail-scanner-2.08 (clamdscan: 0.96.5/12652. Clear:RC:1(127.0.0.1):. Processed in 0.04213 secs); 09 Feb 2011 17:39:23 -0000 Received: from unknown (HELO antivirus3) (127.0.0.1) by us.es with SMTP; 9 Feb 2011 17:39:23 -0000 Received: from 192.168.1.13 (192.168.1.13) by antivirus3 (F-Secure/fsigk_smtp/403/antivirus3); Wed, 09 Feb 2011 18:39:23 +0100 (CET) X-Virus-Status: clean(F-Secure/fsigk_smtp/403/antivirus3) Received: (qmail 1249 invoked from network); 9 Feb 2011 18:39:22 +0100 Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 9 Feb 2011 18:39:22 +0100 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 p19HdMkd002324; Wed, 9 Feb 2011 18:39:22 +0100 Message-ID: <4D52D16A.2050105@trajano.us.es> Date: Wed, 09 Feb 2011 18:39:54 +0100 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.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "megaco@ietf.org" References: <4D4EE208.5070600@trajano.us.es> <5F7BCCF5541B7444830A2288ABBEBC961D500198F3@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> In-Reply-To: <5F7BCCF5541B7444830A2288ABBEBC961D500198F3@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Megaco] GRP address type in MeGaCo/SDP for TDM X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 17:39:18 -0000 Albrecht, I agree with you. For ISDN monochannel services, I have been used the naming scheme proposed by the ETSI_ARGW profile[TS 183002 V3.3.1]. For example: pra//// pra/5/9/3/20 If we want to describe an ISDN mutichannel service with 3 B-channel (B1, B4, B7) belonging to the ISDN interface of the subrack "5", we though to use: pra/5/9/3/1,4,7 And for ranges (B1, B2, B3): pra/5/9/3/1-3 But, If we use this, which is the usefulness of the GRP address type?. It would not be necessary. Javi El 08/02/2011 8:07, Schwarz, Albrecht (Albrecht) escribió: > ... e.g. via Termination names, which are defined in H.248 PROFILEs. > > You could choose correspondent "Termination naming convention for TDM terminations", which satisfy your "grouping", hierarchical, physical, Layer 1, ... characteristics. > > For instance: ETSI TISPAN H.248 Profile for TGW > ES 283 024 > -> § 5.6.1.1 > > 5.6.1.1.1.1 ABNF Grammar for H.248 Text Encoding Mode > ABNF (RFC 4234 [26]) is used for the syntax specification. > ABNF coding: > pathName = TDMToken SLASH (PCMsystem / "*") > TDMToken = "tdm" > PCMsystem = 0*(HierarchyLevelHIGHToken SLASH) HierarchyLevelLOWToken > HierarchyLevelHIGHToken = (UnitTypeToken "_" UnitNumber) > HierarchyLevelLOWToken = (UnitTypeToken "_" Wildcard) / Channel / Wildcard > UnitTypeToken = "ChassisToken" / "SDHToken" / "SONETToken" / "PDHToken" > ChassisToken = "s" / "su" ; slot, sub-unit within slot > SDHToken = "stm4" / "stm1" ; relevant is capacity, but not > electrical or optical interface type > SONETToken = "oc12" / "oc3" > PDHToken = "ds3" / "e3" / "ds2" / "e2" /"ds1" / "e1" ; ANSI& ETSI > UnitNumber = 1*DIGIT > Channel = %d0-31 / %d0-23 ; value range E1/T1 system > Wildcard = "*" > > ____ > If your grouping concept wouldn't be already covered, then just extend the naming scheme. > See also AGW: ETSI TS 183002 V3.3.1, § 5.6.1.1 ... and extend if required > > /Albrecht > > > > >> -----Original Message----- >> From: megaco-bounces@ietf.org >> [mailto:megaco-bounces@ietf.org] On Behalf Of Javi >> Sent: Sonntag, 6. Februar 2011 19:02 >> To: megaco@ietf.org >> Cc: taylor@nortelnetworks.com >> Subject: [Megaco] GRP address type in MeGaCo/SDP for TDM >> >> Hi Albrecht, Tom and all, >> >> About the use of the GRP address type, >> [draft-taylor-mmusic-sdp-tdm-01] >> proposes: >> >> The GRP scheme designates a logical or physical grouping of >> circuits within which individual 64 kbit/s channels may be >> identified by integer values. The GRP connection-address >> consists of two parts. >> The first part identifies the logical or physical group, >> while the second identifies the individual circuit within the group. >> >> grp-connection-address = group-part "/" member-part >> >> group-part = non-ws-string >> member-part = non-ws-string >> >> >> If we want to describe an ISDN mutichannel service with 3 >> B-channel (B1, B4, B7) belonging to the ISDN interface of the >> rack "A", I image a possible example would be: >> >> v=0 >> c=TDM GRP 1111/1 >> c=TDM GRP 1111/4 >> c=TDM GRP 1111/7 >> m=application 1 TDM octect-stream >> b=AS:64 # each channel of 64 kbps >> >> >> But, then: How does MGC and MG agree the group number of each >> ISDN interface (in the example, the "1111" number for the >> ISDN interface of the rack "A" (and similarly for member >> number "1,4,7" with the B1,B4,B7 channels, although the >> correlative numbering is a possibility here)? >> >> Regards, >> >> Javier Muñoz >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www.ietf.org/mailman/listinfo/megaco >>