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

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 28 Apr 2004 14:42:32 -0400

I have to agree with Troy on this.  Annex C is definitively for the binary
encoding.  Text encoding should use packages, or an appropriate SDP
construct for communicating the information.  Using .15 to allow SDP
transport of Annex C is dodging the problem (and creating its own as Troy
has pointed out), rather than solving it.  We should define a package that
then could make use of .15 if need be.

Kevin 

-----Original Message-----
From: Troy Cauble [mailto:[email-masked]] 
Sent: Wednesday, April 28, 2004 10:52 AM
To: Christian Groves
Cc: Carsten Waitzmann; Taylor, Tom-PT [CAR:5N00:EXCH];
[email-masked]; Zhao Bo; [email-masked]
Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM
Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion

Christian,

The text name for Annex C is not missing.  Annex C is *EXPLICITLY* for the
binary encoding only.

	"The protocol syntax for the binary format of the protocol is
	defined in Annex A. Annex C specifies the encoding of the Local
	and Remote descriptors for use with the binary format.

	A complete ABNF of the text encoding of the protocol per RFC
	2234 is given in Annex B. SDP is used as the encoding of the 	
	Local and Remote descriptors for use with the text encoding as
	modified in 7.1.8."

H.248.15 is designed to allow Packages to add parameters to the text
encoding of the Local and Remote descriptors.  Annex C is not a Package.

Isn't the real solution here to make a proper Package that handles TMR and
related parameters for both text and binary encoding???

This mod would allow recursion in both encodings:

	a=h248:AnxC/SDP_A=h248:AnxC/SDP_A=h248:AnxC/SDP_A=......

Now I'm going to go too far and really alienate people:

On an as needed basis, portions of Annex C should be deprecated and 
replaced with proper packages.  The package writers could even tell us 
which descriptors to use the parameters in, something Annex C never did.

-troy

Christian Groves wrote:

> Hello Carsten,
> 
> Seems you have a very good point. The text name for Annex C is missing.
> I propose using "AnxC". Or is there another suggestion?
> 
> I will put this in a contribution for the upcoming ITU SG16 meeting.
> 
> Regards, Christian
> 
> Carsten Waitzmann wrote:
> 
>> Hello Christian,
>>
>> thanks for the information. I am still missing one piece:
>>
>> In case of textual encoding, what <package name> should be used for 
>> the media stream properties described in H.248.1 Annex C?
>>
>> a=h248item:<??>/TMR = 40
>>
>> thanks.
>> Carsten
>>
>> Christian Groves wrote:
>>
>>> Hello Carsten,
>>>
>>> Yes this is what I had in mind. The package ID for Annex C is 0.
>>>
>>> ie. H.248.1 Annex A
>>> PkgdName ::= OCTET STRING(SIZE(4))
>>> -- represents Package Name (2 octets) plus Property, Event,
>>> -- Signal Names or Statistics ID. (2 octets)
>>> -- To wildcard a package use 0xFFFF for first two octets, choose
>>> -- is not allowed. To reference native property tag specified in
>>> -- Annex C, use 0x0000 as first two octets.
>>>
>>> Regards, Christian
>>>
>>> Carsten Waitzmann wrote:
>>>
>>>> Hello Christian,
>>>>
>>>> I took your suggestion as a basis for the following example:
>>>>
>>>> MGC -> MG:
>>>> MEGACO / 1 [1.2.3.4]
>>>> Transaction = 100 {
>>>>    Context = $  { Add = TDM1 {
>>>>                                       Media  {
>>>>                                              LocalControl {Mode = 
>>>> SendReceive},
>>>>                                              Local {a=h248item:TMR = 
>>>> 0000 0010}}
>>>>                                 }}}
>>>>
>>>> MG -> MGC
>>>> MEGACO / 1 [1.2.3.5]
>>>> Reply = 100 {
>>>>    Context = 1 {
>>>>                              Add = TDM1 {
>>>>                                           Media  {
>>>>                                                Local {a=h248item:TMR 
>>>> = 00000010}
>>>>                                                       }}}}
>>>>
>>>> Is this usage in line to what you have in mind?
>>>> H.248.15 specifies: a=h248item:<package name>/<property name> = 
>>>> <value>. For H.248.1 C.9 I do not know which package applies to 
>>>> property TMR. But H.248.15 states "To enable the carriage of package 
>>>> defined properties in the local and remote descriptors of the text 
>>>> encoded H.248.1 protocol the Package attribute shall be used" thus I 
>>>> am wondering whether a package name isn't mandatory?
>>>>
>>>> Thanks  a lot!
>>>>
>>>> Carsten
>>>>
>>>> Alcatel
>>>>
>>>> Christian Groves wrote:
>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Megaco mailing list
>>>>> [email-masked]
>>>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>>>
>>>>
>>>
>>>
>>
> 
> 
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 28 Apr 2004 14:42:32 -0400

Kevin 

-----Original Message-----
From: Troy Cauble [mailto:[email-masked]] 
Sent: Wednesday, April 28, 2004 10:52 AM
To: Christian Groves
Cc: Carsten Waitzmann; Taylor, Tom-PT [CAR:5N00:EXCH];

Christian,

-troy