Subject: RE: Megaco ATM Package Queries

From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS <[email-masked]>
Date: Thu, 5 Apr 2001 14:22:46 +0200

Hello,

Sorry for the late question, but I don't see in which cases the VCChange
event is needed. Why not using H.248 replies to commands instead? 
For instance, if Adding a Termination to a context leads to the creation of
a VC, the reply to this request could actually provide the same information
as VCChange/Est to the MGC (i.e. the bearer is established.)
And if the bearer can't be established, the MG returns an error.

Is there any case where VCChange information can't be actually provided in
TransactionReplies?

               ```
              (o o)
----------oOO--(_)-OOo--------------
Jean-Emmanuel CHAPRON
FRANCE TELECOM R&D
DAC/ACE
38-40 rue du général Leclerc
92794 Issy-les-Moulineaux Cedex 9 - France
Tel: +33 1 45 29 64 50
-------------------------------------

> -----Message d'origine-----
> De : Rosen, Brian [mailto:[email-masked]]
> Envoyé : jeudi 29 mars 2001 16:37
> À : 'CHATRAS Bruno FTRD/DAC/ISS'; [email-masked]'
> Cc : [email-masked]
> Objet : RE: Megaco ATM Package Queries
> 
> 
> Yes, the reason for not using BNCChange is that I consider 
> the idea that
> a signal is used to create a VC is not a consensus position; 
> it is SG11's
> current position, and there are advocates in the SG16/Megaco community
> for that position.  Yet, we have not had the opportunity to determine
> how the majority feels about the issue.  I may well be that I 
> am a very
> small minority, but, as yet, we don't have any idea where we 
> (collectively)
> sit on the issue.  
> 
> Brian
> 
> > -----Original Message-----
> > From: CHATRAS Bruno FTRD/DAC/ISS
> > [mailto:[email-masked]]
> > Sent: Thursday, March 29, 2001 6:31 AM
> > To: 'Rosen, Brian'; [email-masked]'
> > Cc: [email-masked]
> > Subject: RE: Megaco ATM Package Queries
> > 
> > 
> > Hello,
> > 
> > I have a more basic question.
> > 
> > What is the difference between the VCChange event and the 
> > BNCChange event
> > defined in the Generic Bearer Connection Package defined in Q.1950?
> > 
> > If they are identical, I guess that the reason for not using 
> > the BNCChange
> > is that you don't want to support the whole Generic Bearer 
> Connection
> > package (i.e. the signals used to trigger the sending of 
> > bearer control
> > messages). Is this a correct interpretation?
> > 
> > If yes, it probably means that the Q.1950 Generic Bearer 
> > Connection package
> > should have been split into two packages (one for the events 
> > and one for the
> > signals), in which case the same event would have been applicable
> > irrespective of the method used to trigger the sending of 
> > bearer control
> > messages. 
> > 
> > 
> > > -----Message d'origine-----
> > > De : Rosen, Brian [mailto:[email-masked]]
> > > Envoyé : mercredi 28 mars 2001 21:01
> > > À : [email-masked]'
> > > Cc : [email-masked]
> > > Objet : RE: Megaco ATM Package Queries
> > > 
> > > 
> > > Glad to see someone looking at this critically.  Comments below:
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]
> > > > Sent: Tuesday, March 27, 2001 4:27 AM
> > > > To: [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: Megaco ATM Package Queries
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Hello,
> > > >      After going through the Megaco ATM Package (as given in
> > > > draft-rosen-megaco-atm-package-00.txt) I feel that the 
> > > > following events,
> > > >      properties and signals need to be added to the package  :-
> > > > 
> > > > a)   Signals to enable forwarding and receiving various Tones 
> > > > via ATM Packets.
> > > > For e.g. DTMF tone forwarding , MF tone forwarding etc.
> > > >      This is required for support of CAS signals.
> > > This would not be done in the ATM package.  There is a CAS package
> > > being developed.
> > > 
> > > > b)   An event for modifying codecs dynamically.
> > > Only AAL2 can do this.  The pftrans event does this for AAL2.
> > > 
> > > > c)   An event for modifying Packetization period.
> > > This is not an event, this is set at the creation of the 
> > termination.
> > > 
> > > > d)   Property to set the Cell and Packet Loss Threshold and 
> > > > events to indicate
> > > > that Cell and Packet Loss Threshold have been exceeded.
> > > This has been discussed before.  Basically, we have not 
> implemented
> > > it in any other bearer, and I'm inclined to leave it out of the
> > > basic package.  It could be part of an "advanced" package 
> > > that extended
> > > the base package.  Other opinions would be welcome on this 
> > suggestion.
> > > 
> > > >      This may be useful for MGC to immediately come to know 
> > > > about the quality
> > > > degradation. If only statistics related to cell and packet
> > > >      loss are maintained, then MGC would have to get the 
> > > > statistics from MG on
> > > > periodic basis to know the QoS.
> > > > e)   An event to indicate Connection Failure
> > > This is done with the cause event in the generic package
> > > 
> > > > f)   An event to indicate that the bearer path fails to any 
> > > > predetermined
> > > > combination of quality criteria such as loss, delay, jitter
> > > >      (an event for Quality Alert).
> > > >      This is required so that MGC can control the QoS.\
> > > Same as "e"
> > > 
> > > 
> > > 
> > > Probably the atmpackage should define error codes.
> > > 
> > > 
> > > Brian 
> > > 
> > 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 5 Apr 2001 09:23:40 -0400

VCChange is optional of course, you don't have to use it.

If the Add waited until the VC was established, and the normalMGexecution
time was relatively short, while the ATM network was relatively slow,
the MGC could time out on the action.  Thus, many believe it's appropriate
to use an event to signal the successful creation.

Brian

> From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS
> [mailto:[email-masked]]
> Sent: Thursday, April 05, 2001 8:23 AM
> To: [email-masked]