Subject: [AVT] Clearmode / VoIP Media Gateways supporting ISDN data

From: Kreuter Ruediger <[email-masked]>
Date: Tue, 15 Oct 2002 14:44:57 +0200

Hi,

in August I published draft-kreuter-avt-rtp-clearmode-00.txt
with the intention to drive a IANA registration for a Codec
that can be used to support ISDN data connections via RTP.
The main application for that are VoIP media gateways 
replacing a TDM network.

This registration will have an influence on all VoIP media 
gateways and related softswitches in the converged network 
market, at least in interworking cases. Therefore I would 
like to get some comments by suppliers of such gear.
Do you agree with this draft (besides from typos :-) ? 
Are there concurrent solutions in the market/field ?

*********************************************************

Another topic to be discussed, 
is a discussion input for a "Coding of SDP Media Description 
Lines from TMR/USI", in case of "Call Interworking from BICC/
ISUP to SIP" (ITU, Study Group 11, WP3, Meetings of BICC/SIP 
interworking in Ottawa, Canada, 9th - 13th September 2002).

This ITU standardization input, recommends to use UDP for 
Nx64kbit/s unrestricted connections. ("64kbit/s unrestricted" 
or "transparent mode" are synonyms for "clearmode")
In SDP this would look like:

b=AS:64
m=data <port> udp

This approach leads to two questions:

Is it a good idea to transport ISDN data in VoIP networks 
directly on top of UDP instead of RTP ?
This would enforce to rebuild all features which currently 
are based on RTP/RTCP parameters; e.g. synchronization 
(time stamps) or statistics & billing (RTCP sender/receiver 
reports).

And is it necessary to support Nx64kbit/s (with N>1) 
within draft-kreuter-avt-rtp-clearmode-00.txt ? 
That is, is TDM:Nx64kbit/s visible to a VoIP media 
gateway ?
In that case an additional parameter describing the 
size of N would be needed, and an algorithm describing
the packetization in case of N>1.

Any opinions according this topic ?

Regards

Ruediger Kreuter
[email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Chong, Koan S, ALVAP" <[email-masked]>
Date: Tue, 15 Oct 2002 10:48:08 -0400

I've forwarded your email to the ITU-T SG11  mailing list. Would be glad to receive further guidance. Thanks.
Regards,
Koan S. Chong
+1-732-420-4557

-----Original Message-----
From: Kreuter Ruediger [mailto:[email-masked]]
Sent: Tuesday, October 15, 2002 8:45 AM
To: [email-masked]
Cc: [email-masked]'; Chong, Koan S, ALVAP
Subject: Clearmode / VoIP Media Gateways supporting ISDN data

Hi,

b=AS:64
m=data <port> udp

Regards

Ruediger Kreuter

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 22 Oct 2002 08:32:51 -0400

Some comments from Study Group 11 relating to the CLEARMODE draft for your
information.

-----Original Message-----
From: Leslie Graf [mailto:[email-masked]] 
Sent: Monday, October 21, 2002 8:04 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Clearmode / VoIP Media Gateways supporting ISDN data

Collegues,
Just to add to what Steve has correctly stated. This TMR calue is used for
the 7kHZ ausio service where no network fallback is permited.. This is
certainly not a data service. Regards Leslie

[email-masked] wrote:

> Gents
>
> Just because the call is marked as "64Kbits/s unrestricted" does not 
> mean that this is a data call in the IP sense of a data call. Some 
> customers use this TMR to transfer real time data between applications 
> in different networks. That the TMR does not tell you of the type of 
> application that is using this "media" so it would be prudent to use 
> RTP when interworking ISUP to SIP networks.
>
> Regards
>
> Steve Norreys  acd
>
> British Telecommunications plc
> Registered office: 81 Newgate Street London EC1A 7AJ Registered in 
> England no. 1800000 This electronic message contains information from 
> British Telecommunications plc which may be privileged or 
> confidential. The information is intended to be for the use of the 
> individual(s) or entity named above. If you are not the intended 
> recipient be aware that any disclosure, copying, distribution or use 
> of the contents of this information is prohibited. If you have 
> received this electronic message in error, please notify us by 
> telephone or email (to the numbers or address above) immediately. 
> Activity and use of the British Telecommunications plc E-mail system 
> is monitored to secure its effective operation and for other lawful 
> business purposes. Communications using this system will also be 
> monitored and may be recorded to secure effective operation and for 
> other lawful business purposes.
>
> From: Chong, Koan S, ALVAP [mailto:[email-masked]]
> Sent: 15 October 2002 15:44
> To: tsg11bicc
> Subject: FW: Clearmode / VoIP Media Gateways supporting ISDN data
>
> Please look at the questions at the end of the attached email. 
> Regards, Koan
>
> with the intention to drive a IANA registration for a Codec that can 
> be used to support ISDN data connections via RTP. The main application 
> for that are VoIP media gateways replacing a TDM network.
>
> This registration will have an influence on all VoIP media gateways 
> and related softswitches in the converged network market, at least in 
> interworking cases. Therefore I would like to get some comments by 
> suppliers of such gear. Do you agree with this draft (besides from 
> typos :-) ? Are there concurrent solutions in the market/field ?
>
> is a discussion input for a "Coding of SDP Media Description Lines 
> from TMR/USI", in case of "Call Interworking from BICC/ ISUP to SIP" 
> (ITU, Study Group 11, WP3, Meetings of BICC/SIP interworking in 
> Ottawa, Canada, 9th - 13th September 2002).
>
> This ITU standardization input, recommends to use UDP for Nx64kbit/s 
> unrestricted connections. ("64kbit/s unrestricted" or "transparent 
> mode" are synonyms for "clearmode") In SDP this would look like:
>
> b=AS:64
> m=data <port> udp
>
> Is it a good idea to transport ISDN data in VoIP networks directly on 
> top of UDP instead of RTP ? This would enforce to rebuild all features 
> which currently are based on RTP/RTCP parameters; e.g. synchronization

---

From: Chip Sharp <[email-masked]>
Date: Tue, 22 Oct 2002 09:24:42 -0400

I don't get to agree with Leslie much, so I want to take this 
opportunity... to agree. :-)

64 kbit Unrestricted service is pretty much what it says it is: 
Unrestricted 64 kbit/s synchronous digital service with 8 kHz 
integrity.  Which means to me that I can transmit anything I want to over it.

It is being used (or has been used) to carry:
      * Audio (as pointed out by Leslie at 7 kHz)
      * Higher rate Audio (15 kHz at n x 64 kbit/s)
      * Video (H.320 at n x 64 bkit/s where each channel is
        signaled independently)
      * PPP (with IP on top).
      * X.25/LAPB
      * Subrate asynch or sync rate adapted to 64 kbit/s
        (V.110, V.120, T-Link, DMI Mode 2/3, X.25)
      * Group 4 Fax

As for Multirate service (n x 64 kbit/s with 8 kHz integrity), the only 
public service I was aware of as of 1996 was the H0 (384 kbit/s), and H11 
(1536 kbit/s) and possibly H12 (1920 kbit/s) rates, although there could be 
more by now.

I believe that if this will work at all over IP, then it needs something 
similar to RTP.  Sticking  125 usec samples into UDP probably won't work. :-)

Some coordination with pwe3 wg might be needed, but there isn't necessarily 
complete overlap.  Also, I learned through painful experience that just 
because the Q.931 signaling (Bearer Capability) said 64 kbit/s unrestricted 
didn't necessarily mean that the service actually supported 64 kbit/s 
unrestricted. Things have no doubt improved, but in the mid-'90s calls 
signaled as 64 kbit/s rate adapted to 56 kbit/s from US to Australia showed 
up in Australia as 64 kbit/s unrestricted.

Chip

At 08:04 PM 10/21/2002, Leslie Graf wrote:
> > Just because the call is marked as "64Kbits/s unrestricted" does not mean
> > that this is a data call in the IP sense of a data call. Some customers use
> > this TMR to transfer real time data between applications in different
> > networks. That the TMR does not tell you of the type of application that is
> > using this "media" so it would be prudent to use RTP when interworking ISUP
> > to SIP networks.
> >
> > Regards
> >
> > Steve Norreys  acd
> >
> > Registered office: 81 Newgate Street London EC1A 7AJ
> > Registered in England no. 1800000
> > This electronic message contains information from British 
> Telecommunications
> > plc which may be privileged or confidential. The information is intended to
> > be for the use of the individual(s) or entity named above. If you are not
> > the intended recipient be aware that any disclosure, copying, distribution
> > or use of the contents of this information is prohibited. If you have
> > received this electronic message in error, please notify us by telephone or
> > email (to the numbers or address above) immediately.
> > Activity and use of the British Telecommunications plc E-mail system is
> > monitored to secure its effective operation and for other lawful business
> > purposes. Communications using this system will also be monitored and 
> may be
> > recorded to secure effective operation and for other lawful business
> > purposes.
> >
> > Koan