Subject: RE: [Megaco] MG capabilities

From: "Blatherwick, Peter" <[email-masked]>
Date: Wed, 24 Oct 2001 10:18:58 -0400

Just to add some quick bits to Brian's summary for completeness, 

Profiles define the *minimum* set of capabilities supported (Packages, options, etc) for interop, not limiting extending beyond that.  This is an important distinction to enable innovation.  

Profile definitions also allow some things to be understood about behavior of the MG which are not necessarily easily discovered through Audit, such as naming conventions or special meaning of particular termination names which may actually support identical Packages (Megaco IP Phone does this to distinguish e.g. handset from handsfree unit).  Since a great deal can be understood by accepting the Profile alone, a great deal of ambiguity is eliminated and audit-related traffic is greatly reduced, possibly to zero in tightly defined Profiles.  Effectively this constitutes an application-level agreement on behavior between the MGC and the MG.  

Also note that even if the MGC does not understand the Profile, it can still choose to accept the ServiceChange, then audit to determine what's actually there (some risk involved in this of course, especially in cases where Package support does not tell the whole story).  Another option is for the MGC to decline the ServiceChange, but direct the MG to another MGC to try which does support the Profile (via ServiceChangeMgcId parameter).  

-- Peter Blatherwick

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: October 24, 2001 08:18
To: 'Niraj Kedar'; [email-masked]
Subject: RE: [Megaco] MG capabilities

There are two mechanisms:
The Profile and the Audit.

When the MG first registers with the MGC, one of the items in the
ServiceChange is the Profile.  A profile is a document that describes
a complete set of capabilities.  It might include a list of packages,
a set of termination naming conventions, a transport protocol and
an encoding choice - often a profile will make a choice for every
option defined in the protocol.  When the MG asks the MGC for service,
the MGC looks at the offered profile.  If it can handle that profile,
it might decide to accept the MG for service.  However, if it doesn't
implement that profile, it might decline.  The MG would then seach
further for an MGC which could support it.

After the ServiceChange, the MGC can use AuditCapability and AuditValue
to discover what the MG can do.  In particular, auditing of Packages
tells you what packages are implemented on a termination or wildcarded
set of terminations.

> -----Original Message-----
> From: Niraj Kedar [mailto:[email-masked]]
> Sent: Wednesday, October 24, 2001 5:42 AM
> To: [email-masked]
> Subject: [Megaco] MG capabilities
> 
> 
> Is there some form of negotiation of the capabilities
> between the MG(s) and the controlling MGC. Does the
> MGC have to be informed of the packages that an MG,
> which it is controlling, is implementing before they
> communicate with each other? If yes whats the
> mechanism of doing this.
> 
> The underspecified (using CHOOSE) and overspecified
> values can lead to the MG replying with the
> descriptors it has. But this can happen only after
> they have initiated communication?
> 
> thanx
> niraj
> 
> __________________________________________________
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com
> 
> _______________________________________________
> Megaco mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/megaco
> 

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

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