Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion

From: [email-masked]
Date: Mon, 1 Mar 2004 08:49:31 +0100

Christian,

you are right. H.248.1 Annex C.9 defines already the solution for non-BICC
CS2 networks.
Thanks for that hint!
Albrecht

|---------+------------------------------->
|         |           Christian Groves    |
|         |           <Christian.Groves@er|
|         |           icsson.com>         |
|         |                               |
|         |           01.03.2004 00:53    |
|         |                               |
|---------+------------------------------->
  >------------------------------------------------------------------------------------------------------------|
  |                                                                                                            |
  |        To:      Tom Taylor <[email-masked]>                                                     |
  |        cc:      Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, Zhao Bo <[email-masked]>, [email-masked]             |
  |        Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco]       |
  |        Hairpin case A/u Law conversion                                                                     |
  >------------------------------------------------------------------------------------------------------------|

Hello Tom and Albrecht,

What peice of information do you want to signal explicitely? Doesn't TMR
allow
you to specify 64Kbit UDI? If so then its supported by H.248.1 Annex C.9.
For
H.248 text users this (or any element in Annex C) can be tranferred via
H.248.15. Alternatively Q.1950 sect 5.7.1.2 specifies an equivalent
encoding.

Regards, Christian

Tom Taylor wrote:

> I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in my
> intervention.  My old draft has been allowed to expire because it did
> not seem to be of much interest to the community.
>
> You are right: the draft just referred to doesn't apply to TDM, only to
> the packet side.  I wasn't thinking.  I agree that in the absence of the
> attributes provided in my old draft, TDM bearer characteristics are
> assumed rather than signalled explicitly.
>
> [email-masked] wrote:
>
>> I think that the question is, whether this specific TDM bearer
capability
>> should be (1) explicitly signalled, or whether (2) implicit assumption
is
>> already sufficient.
>>
>> With regard to (1), Tom, I guess that your refer to
>>
>> * RTP/CLEARMODE
>>   RTP payload format for a 64 kbit/s transparent call
>>
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-04.txt
>>
>> But, this coming RFC may not be directly applied, e.g., packetization
>> time
>> parameter isn't applicable IMHO. Pls correct me if wrong.
>>
>> Or do you refer to your proposals in your expired draft wrt
>> * TDM/CLEARMODE
>>   Conventions for the use of the Session Description Protocol (SDP)
>>   for Digital Circuit Connections
>>   http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01.txt
>>
>> My conclusion is, that an explicit signalling method doesn't exist today
>> ("exception might be Q.1950").
>> Even though, an explicit TDM Media Descriptor for I.231.1  might be
>> helpful
>> for unambigously specification in certain MG implementations.
>>
>>
>> With regard to (2):
>> Implicit signaling is in my understanding the situation of today. In
case
>> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Media
>> Descriptors with transparent channel indications", when a transparent
>> 64-kbit/s bearer connection may be established.
>> Sometimes this is also called "native TDM switching", or "native TDM
>> hairpinning", but technically it is exactly representing an ISDN B
>> channel
>> with I.231.1 bearer service. [=> the channel may bypass the DSP, but in
>> case that a DSP is looped-in, then must be the DSP channel operation
mode
>> configured for 'Clearmode']
>>
>> Last comment:
>> Such kind of implicit signalling mechanism is often assumed in telco
>> industry, because this is the legacy signaling mechanism within a TDM
>> switch ("if there aren't any signaled bearer capabilities then
>> transparent
>> channel; any needed bearer capability in addition must be explicitly
>> signalled, like signal processing network equipment functions, e.g.,
>> EC").
>>
>> TDM hairpinning means, an "H.248-controlled TDM switching function" from
>> H.248 Media Gateway perspective. Hence, this implicit signalling
>> assumption
>> may be still valid, or do you see any needs for explicit signaling
>> codepoints in case of TDM-to-TDM ISDN I.231.1 calls?
>>
>> Regards
>>
>> Albrecht
>>
>>
>>
>>
>>
>>
>>

>>                       Tom
>> Taylor

>>                       <taylor@nortelne         To:      Zhao Bo
>> <[email-masked]>

>>                       tworks.com>              cc:      Albrecht
>> SCHWARZ/DE/ALCATEL@ALCATEL,
>> [email-masked]
>>                                                Subject: Re: TDM
>> Hairpinning; Re: [Megaco] Hairpin case A/u Law
>> conversion                                                 26.02.2004
>> 14:05

>>
>>
>>
>>
>> I think you would do it by specifying the CLEARMODE codec in the Local
>> and
>> Remote
>> descriptors.  Unfortunately, CLEARMODE is still under consideration by
>> the
>> IESG
>> and hasn't reached RFC status.
>>
>> Zhao Bo wrote:
>>
>>> Dear Albrecht:
>>>    Is there any H.248 package defined to signal the UDI transparency
>>
>>
>> properties in TDM hairping case?
>>
>>>    Best regards
>>>
>>> ----- Original Message -----
>>> From: <[email-masked]>
>>> To: "Zhao Bo" <[email-masked]>
>>> Cc: <[email-masked]>; <[email-masked]>
>>> Sent: Wednesday, February 25, 2004 10:24 PM
>>> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion
>>>
>>>
>>>
>>> Dear Zhao Bo,
>>>
>>> because there isn't any "hairpinning" definition in MEGACOP/H.248
>>
>>
>> standards
>>
>>> ("please correct if I'm wrong"), I'd like to use the following one for
>>> responding your questions:
>>>
>>>
>>
>>
***********************************************************************************

>>
>>
>>
>>> Definition:
>>> TDM Hairpinning
>>> ? is a scenario whereby a call is being made between two TDM
>>> endpoints on
>>
>>
>> a
>>
>>>    single media gateway. The media comes in on one TDM channel and goes
>>>    out on another TDM channel through the use of an internal loop in
the
>>>    media gateway.
>>>
>>> Note 1: due to the fact that there are local call types at local
>>
>>
>> exchanges
>>
>>> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks (PSTN,
>>> NISDN, etc), there is a variety of TDM-to-TDM connection types behind
>>> the
>>> general "TDM hairpinning" capability (dependent on required type of
IWF,
>>> etc.) in corresponding H.248 MG types
>>>
>>> Note 2: H.248/MEGCOP perspective
>>> TDM Hairpinning = Single H.248 Context with 2 H.248 TDM Terminations
>>>
>>
>>
************************************************************************************

>>
>>
>>
>>> Based on this hairpinning understanding, my answers are:
>>>
>>> (1) Speech telephony service: G.711 companding formats are a property
of
>>> the corresponding H.248 TDM termination
>>>
>>> [Note: dependent on MG architecture and implementation, property
>>> might be
>>> signalled or preprovisioned. Of course, G.711 companding law is an
>>
>>
>> inherent
>>
>>> property of your DS0 channel at your PDH/SDH/SONET framer; the way, how
>>> this DS0 property is associated with the corresponding H.248 TDM
>>> Termination property may only realized MG-internally for very
>>> specific MG
>>> architectures. Generally it is up to the MGC, particularly if some (or
>>
>>
>> all)
>>
>>> DS0's are ISDN B channels.]
>>>
>>> (2) Voiceband Data services: same as in (1)
>>>
>>> [Note: VBD according new ITU-T V.152 -> "... For purposes of
>>> interoperability, a V.152 compliant implementation shall support at
>>> least
>>> both G.711 A-law and G.711 ì-law codecs as VBD codecs. "]
>>>
>>> (3) ISDN UDI = all ISDN Teleservices with ISDN I.231. bearer service
>>> requirement
>>> => H.248 TDM Termination property must be signalled by MGC, if not, MG
>>
>>
>> may
>>
>>> not guarantee UDI capability (i.e., fully transparent 64-kbit/s bearer
>>> channel) in TDM hairpinning scenarios ...
>>>
>>>
>>> Conclusion:
>>> IF your MG is supporting
>>> PSTN lines (= H.248 ALN Termination),
>>> PSTN trunks (= H.248 TDM Termination), and
>>> ISDN B channels (= H.248 TDM Termination)
>>>
>>> AND IF you've such services and interworking requirements
>>>
>>> THEN you should generally signal the corresponding properties ...
>>>
>>> ... in case of
>>> TDM hairpinning,
>>> ALN hairpinning, or
>>> ALN-to-TDM connection types.
>>>
>>> Regards,
>>> Albrecht
>>>
>>> ALCATEL
>>>
>>>
>>>
>>>
>>>
>>
>>
>>>                      Zhao Bo
>>
>>
>>
>>>                      <[email-masked]>         To:      [email-masked]
>>
>>
>>
>>>                      Sent by:                 cc:
>>
>>
>>
>>>                      megaco-admin@iet         Subject: [Megaco] Hairpin
>>
>>
>> case A/u Law conversion
>>
>>>                      f.org
>>
>>
>>
>>
>>
>>>                      25.02.2004 08:11
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>> In this case, the A/u law format of a TDM ciruit can be provisioned,
>>> but
>>> the MG doesn't know the service type of a call, thus
>>> has no way to know if a conversion is needed. For speech service
>>
>>
>> conversion
>>
>>> may be needed; for data service like isdn UDI, conversion is not
>>
>>
>> permitted.
>>
>>> Is there any method to solve this problem?
>>>
>>> Zhao Bo
>>>
>>> *****************************************************************
>>> This e-mail and its attachments contain confidential information from
>>> HUAWEI, which is intended only for the person or entity whose address
is
>>> listed above. Any use of the information contained herein in any way
>>> (including, but not limited to, total or partial disclosure,
>>
>>
>> reproduction,
>>
>>> or dissemination) by persons other than the intended recipient(s) is
>>> prohibited. If you receive this e-mail in error, please notify the
>>> sender
>>> by phone or email immediately and delete it!
>>> *****************************************************************
>>>
>>> _______________________________________________
>>> Megaco mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Megaco mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/megaco
>>> 1èr‰šŠX§‚X¬´Ç iÊ"z×è®m¶›?ÿ0Ö'~Šàþf¢–f§þX¬¶)ß£ùž§(
>>
>>
>>
>>
>>
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
>

This communication is confidential and intended solely for the
addressee(s). Any unauthorized review, use, disclosure or distribution is
prohibited. If you believe this message has been sent to you in error,
please notify the sender by replying to this transmission and delete the
message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we only
send and receive e-mails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.

��(����x%��Lz��'�~����i����
bz���j)fj��b��?��r

---

From: [email-masked]
Date: Mon, 1 Mar 2004 08:49:31 +0100

Christian,

  |                                                                                                            |

Hello Tom and Albrecht,

Regards, Christian

capability
is
case
mode

the
IWF,

of
is