From: Qiu Xiuping <[email-masked]>
Date: Sat, 22 Jan 2000 10:51:27 +0800

Hi,  Brian£¡

  Thanks for your reply and it helps me a lot.

  It seems that  version 14 will be issued  next week .

  I think  AuditDescriptor will contain the EventBuffer Descriptor

  And how MGC use the EventBuffer , that is which command EventBuffer is used in
  is not described.

  I think it should used  in Add, Modify and Move.

At 00-1-21 11:48:00 you wrote£º
>> -----Original Message-----
>> From: Qiu Xiuping [mailto:[email-masked]]
>> Sent: Thursday, January 20, 2000 6:31 AM
>> To: [email-masked]
>> Subject:
>>
>I have had some connectivity problems while traveling, and am way
>behind on comments to V13.  On the other hand, today is the day
>we wish to settle the text, if at all possible.
>
>I know there are other messages on this thread already, but this
>is my opinion
>
>
>
>>
>> Hi, All .
>>
>> While reading MEGACO/H.248  version 13,  I meet some questions.
>>
>> 1. In  6.2 " Terminations may be created which represent
>> multiplexed bearers, "
>>
>> I don't understand what multiplexed bearer mean.. Will you
>> please give a detailed example?
>This was answered correctly, AAL1/2, or there are several proposals
>to create a multiplexed RTP.  More than one "call" on a single
>bearer "connection"
>
>> 2. In  6.2.4   property may be declared as "Global"
>>
>> I don't know how to decalre a property as " Global", I read
>> everything but find nothing more
>> about it. And  it is the same with the " "Properties may be
>> read-only or read/write "" ,
>> there is  no  place to  declare a property to be  read-only.
>You literally say "Global" and/or "read-only",.... in the
>package definition document.  It goes in the "characteristics"
>line.  The text in section 12.1.3 needs to be modified to mention
>this.
>
>>
>>
>> 3. In 7.1.8 Local and Remote Descriptors
>> 	
>>  Local refers to the media received by the MG and Remote
>> refers to the media sent by the MG.
>>
>> I think this sentence is misfortune to be typo error. :-)
>There is some confusion here.  I think we need to align it with MGCP,
>as there is no other reason to choose, and we unnecessarily
>confuse people if they are different.  In MGCP, local specifies
>what you receive.
>
>
>>
>> 4 In 7.1.9 Events Descriptor
>>
>> The MG shall send a Notify command to the MGC when it detects
>> an event in the Events Descriptor.   "
>>
>> If so, what is the use of  eventbuffer ?
>I think this was answered.  EventsDescriptor specifies what
>to look for, ObservedEvents Descriptor tells you what has
>been detected.  EventBuffer specifies what to look for after
>you have found an event in EventsDescriptor but before the
>MGC can come back with a new EventsDescriptor.
>
>>
>> 5 In 7.2.5 AuditValue ".
>>
>> If the TerminationId is wildcarded, only one command return
>> is generated, with the contents containing the union
>> of the values of all Terminations matching the wildcard.
>> This convention may reduce the volume of data required
>> to audit a group of Terminations "
>>
>> Will you please give me a example for union of the values of
>> all Terminations matching the wildcard?
>Also answered reasonably.  Suppose I had 3 terminations A1, A2
>and A3, and let's just say there was a property pf/c which
>could have values 0-25.  Suppose A1's pf/c was currently 13,
>and A2 as well as A3 currently have pf/c set to 0.  If you did
>Context=*{W-AuditValue=A*{Audit{TerminationState}}}
>your reply might look like
>Context=*{W-AuditValue=A*{TerminationsState{...,pf/c={0,13}...
>
>>
>> 6. In 7.2.8 ServiceChange
>>
>> Restart - indicates that service will be restored on the
>> specified Terminations after expiration of the
>> ServiceChangeDelayThe MG should set serviceState to
>> "inService" upon expiry of ServiceChangeDelay
>>
>> How to deal with the bad terminations ? They can not be in "
>> inService "" of course.
>They don't get restarted!  Maybe I misunderstand the question.
>
>>
>> 7 In 8.2.2 TransactionReply
>>
>> " If the end of a command cannot be reliably determined it
>> will return 442 Syntax Error in Transaction as the reply to
>> the last action it can parse."
>>
>> It seems that "442 Syntax Error in Transaction" should be
>> corrected  to be " 442 Syntax Error in Command "  :-)
>>
>> 8 In 8.2.3 TransactionPending
>>
>> If a duplicate request is received when pending, the
>> responder may send a duplicate pending immediately,
>> or continue waiting for its timer to trigger another
>> Transaction Pending.
>>
>> My question is how to determine to choose which  method?
>It doesn't matter.  It is not necessary to send it as the
>way the timers work, you will always get a response (either
>the reply or another pending) from the original request
>before you could get one from the duplicate.  It doesn't hurt
>to get extra ones.  Your choice.
>
>Brian
>
>------------
>Brian Rosen, Principal Engineer
>Marconi (Formerly FORE Systems)
>1000 FORE Drive, Warrendale, PA 15086
>(724) 742-6826  mailto:[email-masked]
>

Regards,
Xiuping Qiu
_______________________________________________

Xiuping Qiu
Huawei Technologies Co., Ltd.
Mail to   [email-masked]
Visit     http://www.huawei.com.cn
_______________________________________________