Subject: [Megaco] Textual Coding of H.248.1 Annex C; Re: Signaling of UDI rsp Clearmode Bearer Service;

From: [email-masked]
Date: Fri, 30 Apr 2004 15:50:20 +0200

Hello All!

Thread was originating from us.
ALCATEL's preference is still the proposed solution of a textual codepoint
for Annex C, indicated in

http://www1.ietf.org/mail-archive/working-groups/megaco/current/msg05068.html
http://www1.ietf.org/mail-archive/working-groups/megaco/current/msg05069.html

Of course, we didn't made a comprehensive analysis up to now by
investigating all potential impacts.
I'll formulate at least our current view in an contribution for the next
Rapporteurs meeting.

Best regards,
Albrecht

ALCATEL

|---------+------------------------------->
|         |           Christian Groves    |
|         |           <christian.groves@er|
|         |           icsson.com>         |
|         |           Sent by:            |
|         |           [email-masked]|
|         |           g                   |
|         |                               |
|         |                               |
|         |           30.04.2004 00:52    |
|         |                               |
|---------+------------------------------->
  >------------------------------------------------------------------------------------------------------------|
  |                                                                                                            |
  |        To:      Tom Taylor <[email-masked]>                                                     |
  |        cc:      Troy Cauble <[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, 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:
>
>> 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
>>
> ...
>

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

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