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

From: Carsten Waitzmann <[email-masked]>
Date: Thu, 01 Apr 2004 15:16:04 +0100

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

---

From: Carsten Waitzmann <[email-masked]>
Date: Thu, 01 Apr 2004 15:16:04 +0100

Hello Christian,

MGC -> MG:
MEGACO / 1 [1.2.3.4]
Transaction = 100 {

MG -> MGC
MEGACO / 1 [1.2.3.5]
Reply = 100 {
    Context = 1 {
                              Add = TDM1 {
                                           Media  {
                                                Local {a=h248item:TMR = 
00000010}
                                                       }}}}

Thanks  a lot!

Carsten

Alcatel

---

From: Christian Groves <[email-masked]>
Date: Tue, 06 Apr 2004 11:55:54 +1000

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

---

From: Christian Groves <[email-masked]>
Date: Tue, 06 Apr 2004 11:55:54 +1000

Hello Carsten,

ie. H.248.1 Annex A

Regards, Christian

---

From: Carsten Waitzmann <[email-masked]>
Date: Mon, 26 Apr 2004 14:49:02 +0200

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:

>>                                                Local {a=h248item:TMR 
>> = 00000010}
>> 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,
>>>
>>> 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:
>>>
>>>> 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 
>>>>> Even though, an explicit TDM Media Descriptor for I.231.1  might 
>>>>> be helpful
>>>>> Implicit signaling is in my understanding the situation of today. 
>>>>> In case
>>>>> case that a DSP is looped-in, then must be the DSP channel 
>>>>> operation mode
>>>>> signalled, like signal processing network equipment functions, 
>>>>> e.g., EC").
>>>>>
>>>>> TDM hairpinning means, an "H.248-controlled TDM switching 
>>>>> function" from
>>>>> descriptors.  Unfortunately, CLEARMODE is still under 
>>>>> consideration by the
>>>>> IESG
>>>>>>    single media gateway. The media comes in on one TDM channel 
>>>>>> and goes
>>>>>> general "TDM hairpinning" capability (dependent on required type 
>>>>>> of IWF,
>>>>>> property of your DS0 channel at your PDH/SDH/SONET framer; the 
>>>>>> way, how
>>>>>> interoperability, a V.152 compliant implementation shall support 
>>>>>> at least
>>>>>> prohibited. If you receive this e-mail in error, please notify 
>>>>>> the sender
>>> 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.
>>>
>>> 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.
>>>
>>>

---

From: Carsten Waitzmann <[email-masked]>
Date: Mon, 26 Apr 2004 14:49:02 +0200

Hello Christian,

a=h248item:<??>/TMR = 40

thanks.
Carsten

---

From: Christian Groves <[email-masked]>
Date: Tue, 27 Apr 2004 19:16:42 +1000

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

---

From: Christian Groves <[email-masked]>
Date: Tue, 27 Apr 2004 19:16:42 +1000

Hello Carsten,

Regards, Christian

---

From: Carsten Waitzmann <[email-masked]>
Date: Tue, 27 Apr 2004 13:55:12 +0200

Hi Christian,

Your suggestion is OK for us.
We (Alcatel) will support your contribution.
thanks.
Carsten

Christian Groves wrote:

>> 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,
>>>
>>>> = 0000 0010}}
>>>>                                                Local 
>>>> {a=h248item:TMR = 00000010}
>>>>                                                       }}}}
>>>>
>>>> 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.
>>>>>>
>>>>>>> My conclusion is, that an explicit signalling method doesn't 
>>>>>>> exist today
>>>>>>> Implicit signaling is in my understanding the situation of 
>>>>>>> today. In case
>>>>>>> hairpinning", but technically it is exactly representing an ISDN 
>>>>>>> B channel
>>>>>>>>    out on another TDM channel through the use of an internal 
>>>>>>>> loop in the
>>>>>>>>    media gateway.
>>>>>>>>
>>>>>>>> general "TDM hairpinning" capability (dependent on required 
>>>>>>>> type of IWF,
>>>>>>>> [Note: dependent on MG architecture and implementation, 
>>>>>>>> property might be
>>>>>>>> interoperability, a V.152 compliant implementation shall 
>>>>>>>> support at least
>>>>> 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.
>>>>>
>>>>>

---

From: Carsten Waitzmann <[email-masked]>
Date: Tue, 27 Apr 2004 13:55:12 +0200

Hi Christian,

---

From: Troy Cauble <[email-masked]>
Date: Wed, 28 Apr 2004 10:51:45 -0400

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

---

From: Troy Cauble <[email-masked]>
Date: Wed, 28 Apr 2004 10:51:45 -0400

Christian,

-troy

---

From: Tom Taylor <[email-masked]>
Date: Wed, 28 Apr 2004 14:28:03 -0400

I was always of a similar opinion: that Annex C would gradually be eroded away 
through migration of the material to other packages.

So: what would be the principle of the text packages: would they still capture the 
Q.x signalling as (hex-encoded) binary, or would we define enumerations where 
applicable?

---

From: Tom Taylor <[email-masked]>
Date: Wed, 28 Apr 2004 14:28:03 -0400

---

From: Troy Cauble <[email-masked]>
Date: Wed, 28 Apr 2004 15:03:36 -0400

Minor nit:  They wouldn't be "text packages".  They'd just be packages.
Packages inherently support both text and binary encoding.

-troy

Tom Taylor wrote:

> I was always of a similar opinion: that Annex C would gradually be 
> eroded away through migration of the material to other packages.
> 
> So: what would be the principle of the text packages: would they still 
> capture the Q.x signalling as (hex-encoded) binary, or would we define 
> enumerations where applicable?
> 
> Troy Cauble wrote:
> 
>> Christian,
>>

---

From: Troy Cauble <[email-masked]>
Date: Wed, 28 Apr 2004 15:03:36 -0400

-troy

---

From: Christian Groves <[email-masked]>
Date: Thu, 29 Apr 2004 09:13:19 +1000

Hello Troy, Tom and Kevin,

I agree Annex C is not a package however it does use the same method of 
referencing the properties ie. packageId/propertyID where in the binary case the 
packageId is 0000.

However USI and TMR is being used by implementations so we can't simply 
deprecate Annex C as some seem to indicate. We have seen a case where TMR/USI 
would be useful for text implementations. There are several options here. As 
USI/TMR are already being used by binary implementations it isn't appropriate to 
make changes to this, which essentially a new package would be. This leaves 
modifications for the text encoding. I thought the easiest way would be to use 
the H.248.15 to carry the property, the side effect being a "packageID" would be 
needed. This seemed to be simplest method, keeps it in the H.248 domain and is 
in the WGs control. The other method would be to define SDP to carry the octets 
for USI/TMR. This will muddy the water has people will think this relates to SIP 
in some way. This will probably take some time to sort out.

If we had our time again I would have prefered the use of packages only (no 
Annex C/no SDP) ;).

Regards, Christian

Troy Cauble wrote:

>>> The text name for Annex C is not missing.  Annex C is *EXPLICITLY* 
>>> for the binary encoding only.
>>>
>>> Isn't the real solution here to make a proper Package that handles 
>>> TMR and related parameters for both text and binary encoding???
>>>
>>>
>>>
>>> replaced with proper packages.  The package writers could even tell 
>>> us which descriptors to use the parameters in, something Annex C 
>>> never did.
>>>
>>>
>>> -troy
>>>
>>>
> 
>

---

From: Christian Groves <[email-masked]>
Date: Thu, 29 Apr 2004 09:13:19 +1000

Regards, Christian

---

From: Tom Taylor <[email-masked]>
Date: Thu, 29 Apr 2004 09:42:18 -0400

We can replicate the binary values for the TMR and USI, and reassign the packageId 
for them.

However, if necessary, I can revive my I-D on SDP encoding of TMR/USI.  I dropped 
it for lack of apparent interest.

Christian Groves wrote:

> referencing the properties ie. packageId/propertyID where in the binary 
> case the packageId is 0000.
> 
> deprecate Annex C as some seem to indicate. We have seen a case where 
> TMR/USI would be useful for text implementations. There are several 
> options here. As USI/TMR are already being used by binary 
> implementations it isn't appropriate to make changes to this, which 
> essentially a new package would be. This leaves modifications for the 
> text encoding. I thought the easiest way would be to use the H.248.15 to 
> carry the property, the side effect being a "packageID" would be needed. 
> This seemed to be simplest method, keeps it in the H.248 domain and is 
> in the WGs control. The other method would be to define SDP to carry the 
> octets for USI/TMR. This will muddy the water has people will think this 
> relates to SIP in some way. This will probably take some time to sort out.
> 
> If we had our time again I would have prefered the use of packages only 
> (no Annex C/no SDP) ;).
> 
> Regards, Christian
> 
...

---

From: Tom Taylor <[email-masked]>
Date: Thu, 29 Apr 2004 09:42:18 -0400

...

---

From: Christian Groves <[email-masked]>
Date: Fri, 30 Apr 2004 08:52:41 +1000

Hello Tom, Kevin, Troy,

It's not about replicating the values it's about the packageid/property ID 
itself. You can't simply remove it if it's in use.

If you want to progress down the path of defining TMR and USI for SDP then it's 
OK by me. I didn't raise the need for TMR/USI in text in the first place. Those 
wanting it should speak up about their preference.

If we do go down the way of putting TMR and USI in SDP then I think all we 
should do is simply carry the TMR/USI in SDP. I don't think there's any point in 
exploding the octets to individual text descriptions as you have done in the draft.

Regards, Christian

Tom Taylor wrote:
> We can replicate the binary values for the TMR and USI, and reassign the 
> packageId for them.
> 
> However, if necessary, I can revive my I-D on SDP encoding of TMR/USI.  
> I dropped it for lack of apparent interest.
> 
> Christian Groves wrote:
> 
>> I agree Annex C is not a package however it does use the same method 
>> of referencing the properties ie. packageId/propertyID where in the 
>> binary case the packageId is 0000.
>>
>> However USI and TMR is being used by implementations so we can't 
>> simply deprecate Annex C as some seem to indicate. We have seen a case 
>> where TMR/USI would be useful for text implementations. There are 
>> several options here. As USI/TMR are already being used by binary 
>> text encoding. I thought the easiest way would be to use the H.248.15 
>> to carry the property, the side effect being a "packageID" would be 
>> needed. This seemed to be simplest method, keeps it in the H.248 
>> domain and is in the WGs control. The other method would be to define 
>> SDP to carry the octets for USI/TMR. This will muddy the water has 
>> people will think this relates to SIP in some way. This will probably 
>> take some time to sort out.
>>
>> If we had our time again I would have prefered the use of packages 
>> only (no Annex C/no SDP) ;).
>>
>> Regards, Christian
>>
> ...
>

---

From: Christian Groves <[email-masked]>
Date: Fri, 30 Apr 2004 08:52:41 +1000

Hello Tom, Kevin, Troy,

Regards, Christian