Subject: Re: [Megaco] TDMPW and MeGaCo/SDP

From: Javi Muñoz <[email-masked]>
Date: Tue, 01 Feb 2011 14:07:13 +0100

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:[email-masked]]
>     *Sent:* Montag, 31. Januar 2011 11:47
>     *To:* [email-masked]
>     *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: [email-masked]
>>     > [mailto:[email-masked]] On Behalf Of Javi
>>     > Sent: Samstag, 29. Januar 2011 02:13
>>     > To: [email-masked]
>>     > 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
>>     > [email-masked]
>>     > https://www.ietf.org/mailman/listinfo/megaco
>>     >
>

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Tue, 1 Feb 2011 15:11:14 +0100

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).

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:[email-masked]]
Sent: Dienstag, 1. Februar 2011 14:07
To: [email-masked]
Subject: Re: [Megaco] TDMPW and MeGaCo/SDP

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

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:[email-masked]]
Sent: Montag, 31. Januar 2011 11:47
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Megaco] TDMPW and MeGaCo/SDP

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.

> From: [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> ISDN Terminal 1  -   MG1 -  [IP network] -  MG2   -   ISDN Terminal 2
>
> where the MGs (Media Gateway) are controlled by a MGC (Media Gateway
> How may MGC indicate to the MG that it uses PWs at the IP termination?
>
> [email-masked]<mailto:[email-masked]>

---

From: Javi <[email-masked]>
Date: Tue, 01 Feb 2011 17:50:45 +0100

El 01/02/2011 15:11, Schwarz, Albrecht (Albrecht) escribió:
> /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)./
>

I agree. could you propose an possible example of SDP descriptions for 
TDMPWs?

> /
> /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)/
>
> /

Is GRP suitable for MeGaCo?:

    The NUL scheme is suitable for use with media gateway control, since
    other means are available (as mentioned above) for designating the
    TDM circuit.

If NUL is useful for MeGaCo, I assumed GRP is for SIP only.

Version "01" removed Nx64 services:

1.4 Changes From The Previous Version

    The main change from the previous version has been to limit the
    scope of the present document by placing greater reliance on the
    Megaco/H.248 multiplex concept. This has meant the removal of wideband
    or aggregated N x 64 kbit/s service from the scope of thedocument

>     *From:* Javi Muñoz [mailto:[email-masked]]
>     *Sent:* Dienstag, 1. Februar 2011 14:07
>     *To:* [email-masked]
>>     /Multirate means effectively N-out-of-K (with K = 24 or 30
>>     dependent on ANSI /ETSI markets; and 1 < N <= K)./
>>     /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./
>>     //
>>>         . ITU-T Recommendations I.231.2 and I.231.3 may be emulated
>>>         by a single RTP
>>>         . ITU-T Recommendation I.231.1 may be emulated by a single
>>>         RTP session, with or
>>>         . ITU-T Recommendations I.231.4 to I.231.10 may be emulated
>>>         by TDMoIP described

---

From: Christian Groves <[email-masked]>
Date: Wed, 02 Feb 2011 09:57:37 +1100

Hello Javi and Albrecht,

I think its safe to say that there's really no normative (or informative 
description for that matter) of how TDMoIP (as defined by Y.1453) can be 
described by SDP. Given that TDMoIP is essentially a new payload format 
then an approach as suggested by Javi of the dynamic payload is probably 
the way to go. However as Albrecht points out there are other parameters 
that either need to be provisioned or signalled. Some of these are 
probably available in RFC3108 i.e. the SBC parameter for nx64. Other 
parameters are defined in H.248.1 Annex C. These would be available in 
SDP using H.248.15 "SDP H.248 package attribute".

Regards, Christian

On 2/02/2011 3:50 AM, Javi wrote:
>>>     /Secondly, the selection of channels may be random, they must
>>>     not be in consecutive order (e.g., think about the permutations
>>>     for N = 5)./
>>>>         However, there was never any H.248 Profile standardized
>>>>         with /*multirate*/ support, at least to my knowledge.
>>>>         • ITU-T Recommendations I.231.2 and I.231.3 may be emulated
>>>>         by a single RTP
>>>>         • ITU-T Recommendation I.231.1 may be emulated by a single
>>>>         RTP session, with or
>>>>         • ITU-T Recommendations I.231.4 to I.231.10 may be emulated
>>>>         by TDMoIP described

---

From: Javi <[email-masked]>
Date: Wed, 02 Feb 2011 11:31:01 +0100

Hi Albrecht, Christian and all,

>       signalling approach (for TDMoIP IWFs embedded in H.248 MGs or

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

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 2 Feb 2011 11:59:01 +0100

What "could be enough" is of course a subjective position, because a conditional statement.
You got two options: develop a generic solution (e.g., 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:[email-masked]]
Sent: Mittwoch, 2. Februar 2011 11:31
To: [email-masked]
Cc: Schwarz, Albrecht (Albrecht); [email-masked]
Subject: Re: [Megaco] TDMPW and MeGaCo/SDP

 *

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

 *

__

---

From: Javi <[email-masked]>
Date: Thu, 03 Feb 2011 01:41:51 +0100

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ó:
> 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.
> 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.
>
>     *Sent:* Mittwoch, 2. Februar 2011 11:31
>     *To:* [email-masked]
>     *Cc:* Schwarz, Albrecht (Albrecht); [email-masked]
>>           /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
>>           /alternatives, e.g., the "the group-and-member scheme
>>           (addrtype is "GRP")" as proposed by Tom in his SDP-TDM
>>           draft
>>>         /Secondly, the selection of channels may be random, they
>>>         must not be in consecutive order (e.g., think about the
>>>         permutations for N = 5)./
>>>             But, if it is used, MGC would use SDP at Local/Remote
>>>             MeGaCo descriptors. How may be that SDP description for
>>>             TDMoIP?
>>>
>>>>             . ITU-T Recommendations I.231.2 and I.231.3 may be
>>>>             emulated by a single RTP
>>>>             . ITU-T Recommendation I.231.1 may be emulated by a
>>>>             single RTP session, with or
>>>>             . ITU-T Recommendations I.231.4 to I.231.10 may be
>>>>             emulated by TDMoIP described

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Thu, 3 Feb 2011 17:14:43 +0100

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.1453 also in a non-PW architecture.

Thus, you would cover this specific use case in a, let's say, H.248 "Pseudowire TDMoIP" Profile, which would refer in the connection model, H.248 termination 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:[email-masked]]
Sent: Donnerstag, 3. Februar 2011 01:42
To: [email-masked]
Subject: Re: RE: [Megaco] TDMPW and MeGaCo/SDP

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").

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

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.

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.

Cc: Schwarz, Albrecht (Albrecht); [email-masked]<mailto:[email-masked]>

 *

c=IN IP4 333.333.1.1

 *

__