[Megaco] Megaco Marketplace

["Omair Nissar" <[e-mail]>]

Dear....,

            i am having some queries related to Megaco :-

what is the market share from Megaco in terms of revenue.

what is the future prospect of Megaco

percentage of companies who deploy Megaco.

please do send me the details and the possible sources of information
regarding these queries.



----- Original Message -----
From: <[e-mail]>
To: <[e-mail]>
Sent: Friday, April 04, 2003 10:30 PM
Subject: Megaco digest, Vol 1 #855 - 7 msgs


> Send Megaco mailing list submissions to
> [e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www1.ietf.org/mailman/listinfo/megaco
> or, via email, send a message with subject or body 'help' to
> [e-mail]
>
> You can reach the person managing the list at
> [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Megaco digest..."
>
>
> Today's Topics:
>
>    1. Re: ADD handling for Out-of-service termination (Selvam.V)
>    2. MEGACO Marketplace (Omair Nissar)
>    3. RE: Processing of command, action ...
(=?iso-8859-1?q?petric=20john?=)
>    4. I-D ACTION:draft-ietf-megaco-h248v2-04.txt
([e-mail])
>    5. RE: ADD handling for Out-of-service termination (Kevin Boyle)
>    6. RE: Processing Order of Context Properties and Terminati
>        on Properties (Kevin Boyle)
>
> --__--__--
>
> Message: 1
> From: "Selvam.V" <[e-mail]>
> To: <[e-mail]>, <[e-mail]>
> Subject: Re: [Megaco] ADD handling for Out-of-service termination
> Date: Fri, 4 Apr 2003 11:31:31 +0530
>
> Hi,
>         Is there is a need to send a subtract command.
>         what will be the contextID in the subtract command.
>         when the Termination is OOS, it will be returning an error for the
> ADD
>         request.
>
>         Best Regards,
>         selva
>
> ----- Original Message -----
> From: <[e-mail]>
> To: <[e-mail]>
> Sent: Thursday, April 03, 2003 6:15 PM
> Subject: [Megaco] ADD handling for Out-of-service termination
>
>
> >
> >
> > Hi
> >
> > I have a query  related to ADD command processing for terminations
> involving
> > out-of-service terminations:
> >       An ADD request is received by an MG to add a termination in a
> context
> > which already has a OOS termination.
> >      Scenario:
> >      1) A termination added in a Context.
> >      2) MG operator puts the termination out of service
> >      3) MG sends Service change Forced to the MGC.
> >      4) Before MGC receives a ServiceChange, it has sent an ADD
> request(without
> > a Topolgy descriptor) to MG to add the termination in the
> >           above context.
> > Though it can be argued that MGC will always send substract request
> whenever it
> > receives ServiceChange Forced but
> > does it worth exchanging substract messages when ADD failure could have
> solved
> > the problem.
> > However there can be exception to this scenario where multiple
> terminations are
> > in context and only one termination is made OOS. Then
> > if MGC properly specifies the topology descriptor then ADD command
should
> work.
> >
> > Regards
> > venkat
> >
> >
> >
> > _______________________________________________
> > Megaco mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/megaco
>
>
> --__--__--
>
> Message: 2
> From: "Omair Nissar" <[e-mail]>
> To: <[e-mail]>
> Date: Fri, 4 Apr 2003 14:52:24 +0530
> Subject: [Megaco] MEGACO Marketplace
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_003D_01C2FAB9.CD7B9F80
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> Dear...,
>
>              i am doing research on Megaco Marketplace and i am supposed =
> to prepare a report on Megaco and its Marketplace .i have recently =
> subscribed for Megaco mailing list.i would like to have some information =
> regarding Megaco.Below are some queries
>
> 1. Deployment of Megaco
> 2.Revenue generated from this stack
> 3.Market share from Megaco
> 4.Estimate and forecast
>
>
>
> Regards
>
> omair
>
> Business Dev.Associate
>
> iLocus
>
> 15-sidco Electronics Complex
> Rangreth,Budgam-7,J&K, India
> Tel :- 0194 2300594
> E-Mail :- [e-mail]
>
> ------=_NextPart_000_003D_01C2FAB9.CD7B9F80
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META http-equiv=3DContent-Type content=3D"text/html; =
> charset=3Diso-8859-1">
> <META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><FONT face=3DArial size=3D2>Dear...,</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial=20
> size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
> p;&nbsp;=20
> i am doing research on Megaco Marketplace and i am supposed to prepare a =
> report=20
> on Megaco and its Marketplace .i have recently subscribed for Megaco =
> mailing=20
> list.i would like to have some information regarding Megaco.Below are =
> some=20
> queries</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>1. Deployment of Megaco</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>2.Revenue generated from this =
> stack</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>3.Market share from Megaco</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>4.Estimate and forecast</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2>Regards</FONT></DIV>
> <DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2>omair</FONT></DIV>
> <DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2>Business =
> Dev.Associate</FONT></DIV>
> <DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2>iLocus</FONT></DIV>
> <DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2><FONT color=3D#0000ff>15-sidco =
> Electronics=20
> Complex<BR>Rangreth,Budgam-7,J&amp;K, India<BR>Tel :- 0194 =
> 2300594<BR>E-Mail :-=20
> </FONT><A=20
> href=3D"mailto:[e-mail]">[e-mail]</A><BR></FONT></DIV></B=
> ODY></HTML>
>
> ------=_NextPart_000_003D_01C2FAB9.CD7B9F80--
>
>
> --__--__--
>
> Message: 3
> Date: Fri, 4 Apr 2003 21:34:40 +1000 (EST)
> From: =?iso-8859-1?q?petric=20john?= <[e-mail]>
> Subject: RE: [Megaco] Processing of command, action ...
> To: [e-mail], petric john <[e-mail]>,
>    Raphael Tryster <[e-mail]>
> Cc: [e-mail], [e-mail]
>
> Sorry, forgot to post it to mailing list.
> Repeating the same.
>
> -- john
>
>  --- petric john <[e-mail]> wrote: >
> see the comments with [PJJ]
> >
> >  --- Raphael Tryster <[e-mail]> wrote: >
> > See
> > [FSRT] within.
> > >
> > > Raphael Tryster
> > >
> > > -----Original Message-----
> > > From: petric john
> > [mailto:[e-mail]]
> > > Sent: Thursday, 3 April 2003 16:01
> > > To: [e-mail]
> > > Subject: [Megaco] Processing of command, action
> > ...
> > >
> > >
> > > Hi,
> > >
> > > This is in context of the text mentioned in 8.2.2
> > as
> > > below.
> > >
> > > S1: If the end of an action cannot be reliably
> > > determined but one or more commands can be parsed,
> > > it
> > > will process them and then send 422 - Syntax Error
> > > in
> > > Action as the last action for the transaction.
> > >
> > > S2: If the end of a transaction cannot be reliably
> > > determined and one or more Actions can be parsed,
> > it
> > > will process them and then return 403 - Syntax
> > Error
> > > in Transaction as the last action reply for the
> > > transaction.
> > >
> > > In both the above statemets, it is mentioned about
> > > the
> > > unreliable determination of the action, and
> > > transaction respectively.
> > >
> > > As mentioned, does processing of the commands (in
> > > S1)
> > > means the execution of the commands, and does
> > > processing of the action (in S2) means the
> > execution
> > > in the context of the MGC/MG application???
> > >
> > > [FSRT] Yes.
> > >
> > [PJJ] I think then there are more issues asociated
> > with this. See below.
> >
> > > This apprently shows that even if the parsing
> > > (decoding) of the given component of the protocol
> > > message is partial, the decoded information is
> > still
> > > passed on to the MG/MGC application for further
> > > processing/execution.
> > >
> > > [FSRT]  Yes.  In practice, it means your parser
> > has
> > > to be able to generate
> > > partial output, as well as an indication that the
> > > only processing required
> > > for a specific command or action is to return an
> > > error.
> > >
> > [PJJ]
> >
> > 1. Assume that there are four commands in an action.
> > Now the parsing of the command 1 and 2 was
> > successful,
> > and the third one failed. Then according to the
> > above,
> > we shall send the command 1 and 2 to the
> > application.
> > What about the command command number 4 in the
> > action
> > (which could be syntactically correct)? What we
> > should
> > do to it??
> >
> > 2. If we have to still parse for the command 4 in
> > the
> > action, then it is going to be difficult to know the
> > exact start of the command 4 in the action.
> >
> > 3. What would be the action on the sender's side in
> > this case?? As we shall report the error "422 -
> > Syntax
> > Error in Action" to the sender, how its going to
> > retransmitt the commands 3 and 4??
> >
> > 4. Partial decoding is certainly not applicable in
> > case of command, as it does make any sense to do so.
> > Also the basic unit of the data that has to go to
> > the
> > application is Command, and it should be complete at
> > any point of time. Thus when sender, after receiving
> > the 422, shall send the command 3 and 4 with the
> > same
> > TransactionId (hopefully), in which case it will be
> > the re-transmission of the Transaction (which is
> > again
> > not correct). The resending of the commands 3 and 4
> > has to be a new Transaction. Correct me if wrong.
> >
> > 5. To make above process more complex, assume if the
> > command 1 and 3 were parsed successfully. then
> > should
> > we send command 1 and 3 to the application?? (even
> > otherwise parsing of the alternate commands is
> > definitely not easy. Same is the case with Action,
> > see
> > below.
> >
> > 6. I would like to make a point here that as long as
> > the parsing of the commands in the action (and so
> > actions in the Transaction) is moving successfully,
> > the information is useful. But we should stop
> > parsing
> > as soon as the command decode is failure, and jump
> > to
> > the next action in the Transaction (if present).
> >
> > 7. The parsing logic is certainly going to be
> > complex
> > to find out the next Action in the Transaction.
> >
> > looking forward for the clarifications. ;-)
> >
> > > So far I am under impression that even a single
> > > parse
> > > failure (at any level) of the messgge would
> > prohibit
> > > it from sending it to the application, thus
> > > rejecting
> > > it compeletely.
> > >
> > > [FSRT]  That was my impression once too, but I
> > > couldn't find anything in the
> > > standard to support it.
> > >
> > [PJJ] Same here. I guess there is no support in the
> > standard too for the some of the doubts raised
> > above.
> >
> > > what is the significance of the word "it will
> > > process
> > > them"???
> > >
> > > [FSRT]  As if there were no subsequent error.
> > >
> > > regards,
> > >
> > >
> > >
> > > =====
> > > ~|~
> > >  o
> > > John
> > >
> > > http://mobile.yahoo.com.au - Yahoo! Mobile
> > > - Check & compose your email via SMS on your
> > Telstra
> > > or Vodafone mobile.
> > > _______________________________________________
> > > Megaco mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/megaco
> > >
> >
> > =====
> > ~|~
> >  o
> > John
> >
> > http://mobile.yahoo.com.au - Yahoo! Mobile
> > - Check & compose your email via SMS on your Telstra
> > or Vodafone mobile.
> >
>
> =====
> ~|~
>  o
> John
>
> http://mobile.yahoo.com.au - Yahoo! Mobile
> - Check & compose your email via SMS on your Telstra or Vodafone mobile.
>
> --__--__--
>
> Message: 4
> To: IETF-Announce: ;
> Cc: [e-mail]
> From: [e-mail]
> Reply-to: [e-mail]
> Date: Fri, 04 Apr 2003 06:44:15 -0500
> Subject: [Megaco] I-D ACTION:draft-ietf-megaco-h248v2-04.txt
>
> --NextPart
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Media Gateway Control Working Group of
the IETF.
>
> Title : The Megaco/H.248v2 Gateway Control Protocol, version 2
> Author(s) : C. Groves, M. Pantaleo et al.
> Filename : draft-ietf-megaco-h248v2-04.txt
> Pages : 219
> Date : 2003-4-3
>
> This document describes the second version of the general-purpose
> gateway control protocol standardized as Megaco in the IETF and as
> Recommendation H.248 (now H.248.1) in the ITU-T.  It is common text
> with Recommendation H.248.1 (05/02), published by the ITU-T.  Megaco
> v2 includes the corrections to RFC 3015 which resulted in RFC xxxx
> [draft-ietf-megaco-3015corr-02.txt], plus the following new
> capabilities:
> - ability to audit specific properties, events, signals and
> statistics
> - use of serviceChange to indicate that capabilities have changed in
> the Media Gateway
> - playing a signal on the Root Termination
> - limiting the number of repetitions of transaction pending
> - allowing topology to be set per stream
> - ability to audit context properties
> - new Nx64K multiplex type
> - provision for digit buffering when a digit map completes.
> In addition, the use of the Modem Descriptor was deprecated.
> A detailed list of changes from draft-ietf-megaco-3015corr-
> 02.txt/H.248.1 (03/02) to this document is given in Appendix II at
> the end of this document.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248v2-04.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the
message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-megaco-h248v2-04.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [e-mail].
> In the body type:
> "FILE /internet-drafts/draft-ietf-megaco-h248v2-04.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> --NextPart
> Content-Type: Multipart/Alternative; Boundary="OtherAccess"
>
> --OtherAccess
> Content-Type: Message/External-body;
> access-type="mail-server";
> server="[e-mail]"
>
> Content-Type: text/plain
> Content-ID: <[e-mail]>
>
> ENCODING mime
> FILE /internet-drafts/draft-ietf-megaco-h248v2-04.txt
>
> --OtherAccess
> Content-Type: Message/External-body;
> name="draft-ietf-megaco-h248v2-04.txt";
> site="ftp.ietf.org";
> access-type="anon-ftp";
> directory="internet-drafts"
>
> Content-Type: text/plain
> Content-ID: <[e-mail]>
>
> --OtherAccess--
>
> --NextPart--
>
>
>
> --__--__--
>
> Message: 5
> From: "Kevin Boyle" <[e-mail]>
> To: [e-mail], [e-mail]
> Subject: RE: [Megaco] ADD handling for Out-of-service termination
> Date: Fri, 4 Apr 2003 08:51:24 -0500
>
> Having an OOS term in a context does NOT preclude addition of another
term.
>
> It is clearly stated in the spec that the MGC will subtract the OOS term.
> However, if another term is added in the meantime, the MG should do as it
is
> told, and add the new term into the context.
>
> Also, what does TP have to do with adding a term if one is OOS?  The term
> will be subtracted imminently -- I do not see the problem here.
>
> Kevin
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, April 03, 2003 7:45 AM
> To: [e-mail]
> Subject: [Megaco] ADD handling for Out-of-service termination
>
>
>
>
> Hi
>
> I have a query  related to ADD command processing for terminations
involving
> out-of-service terminations:
>       An ADD request is received by an MG to add a termination in a
context
> which already has a OOS termination.
>      Scenario:
>      1) A termination added in a Context.
>      2) MG operator puts the termination out of service
>      3) MG sends Service change Forced to the MGC.
>      4) Before MGC receives a ServiceChange, it has sent an ADD
> request(without a Topolgy descriptor) to MG to add the termination in the
>           above context.
> Though it can be argued that MGC will always send substract request
whenever
> it receives ServiceChange Forced but does it worth exchanging substract
> messages when ADD failure could have solved the problem. However there can
> be exception to this scenario where multiple terminations are in context
and
> only one termination is made OOS. Then if MGC properly specifies the
> topology descriptor then ADD command should work.
>
> Regards
> venkat
>
>
>
> _______________________________________________
> Megaco mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/megaco
>
> --__--__--
>
> Message: 6
> From: "Kevin Boyle" <[e-mail]>
> To: [e-mail], [e-mail]
> Cc: [e-mail]
> Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
> on Properties
> Date: Fri, 4 Apr 2003 08:51:23 -0500
>
> If one of the terms is illegal in terms of the context in question, the MG
> should return an error.
>
> Kevin
>
> -----Original Message-----
> From: Nurit Shenhar [mailto:[e-mail]]
> Sent: Thursday, April 03, 2003 6:47 AM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [e-mail]
> Cc: [e-mail]
> Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
> on Properties
>
>
> Kevin
>
> In this case, what should the MG do if one of the terminations defined in
> the topology is illegal? (i.e belongs to another context). Should there be
> some session of legality check for the topology?
>
> Nurit
>
> -----Original Message-----
> From: Kevin Boyle [mailto:[e-mail]]
> Sent: Thursday, March 27, 2003 9:54 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
> on Properties
>
>
> Clearly you cannot add the new term before modifying T2.  So the steps are
> thus:
>
> 1. Process the TP descriptor, noting that there is a term that will be
added
> later in the action which will be isolated from all the other existing
terms
> in the context. 2. Process the Modify T2 command. 3. Process the Add
> command, and add the new term.  Note that because the TP descriptor has
> ALREADY been processed, the term is added isolated from all other terms in
> the context.
>
> Kevin
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, March 27, 2003 1:48 AM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: [e-mail]
> Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
> on Properties
>
>
>
>
>
> Hi Kevin/List,
> Taking the discussion a bit further, please clarify if the following
> sequence for implementing Topology Descriptor is correct. Transaction
> receieved: ...Context=1{Topology{$, *, isolate}, Modify=T2{...},
Add=${...}}
>
> Processing steps:
> 1. Resolve the termination name i.e. select one termination conforming to
> the name specified in the Add command. 2. Add this termination to the
> Context. This step may involve using some information given in the Add
> command. 3. If the addition of the termination is successful proceed
> further. If the addition of termination to Context is not successful give
a
> Context Level Error in the response. 4. Apply Topology for the newly added
> termination. 5. Process the Modify command. 6. Process the Add command.
Some
> information present in this command will be used while adding the
> termination to the Context. Rest of the information is processed here.
>
> Please correct me if I am wrong.
>
> Regards,
> Chintan...
> www.hssworld.com
>
>
>
>
>
> "Kevin Boyle" <[e-mail]> on 03/20/2003 12:14:08 PM
>
> To:   Chintan Kaushik/HSS@HSS, David Kao <[e-mail]>
> cc:   [e-mail]
>
> Subject:  RE: [Megaco] Processing Order of Context Properties and
Terminati
> on
>       Properties
>
>
>
> This is not correct.  As has been repeatedly covered, the Topology
> descriptor is executed before any commands, regardless of the information
> available.  The difference between this statement, and what you have
> expressed is this:
>
> C=1{TP{$,*,IS},A=${...}
>
> Topology first:
> The new term is added already isolated from all other terms in the
context.
>
> Topology once "enough information" is present:
> The new term is added bothway to all terms, and then topology is altered
to
> isolate the term from all other terms in the context.
>
> As you can see there is a significant difference between these two
> scenarios.  If the command fails, then it is up to the MGC to clean up any
> potential mess that results from having executed the TP descriptor.
>
> Kevin
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, March 19, 2003 11:27 PM
> To: David Kao
> Cc: [e-mail]
> Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
> on Properties
>
>
>
>
>
> Hi,
> A small addition to what Kevin has already mentioned: -
> Attempt is made to apply the Topology descriptor before any commands for
> that action. However, if due to some reason this is not possible then the
> Topology Descriptor is applied as soon as all the information to apply it
is
> known to the MG. e.g. ... Context = 1{Topology{idstr1,$,Bothway } ,Add=$
> {... In this case Topology will be applied once the "Add=$" command has
been
> executed successfully.
>
> Regards,
> Chintan...
>
>
>
>
> "Kevin Boyle" <[e-mail]> on 03/19/2003 12:30:27 AM
>
> To:   David Kao <[e-mail]>, [e-mail]
> cc:    (bcc: Chintan Kaushik/HSS)
>
> Subject:  RE: [Megaco] Processing Order of Context Properties and
Terminati
> on
>       Properties
>
>
>
> Comments inline. [KJBII]
>
> Kevin
>
> -----Original Message-----
> From: David Kao [mailto:[e-mail]]
> Sent: Monday, March 17, 2003 10:22 PM
> To: [e-mail]
> Subject: [Megaco] Processing Order of Context Properties and Termination
> Properties
>
>
>
> Please accept my apology if the same questions were asked and discussed
> before.
>
>
>
> The spec says, "Transactions guarantee ordered Command processing. That
is,
> Commands within a Transaction are executed sequentially." I have two
> relevant questions based on this statement.
>
>
>
> 1. How about the processing order of context properties? Are they supposed
> to be processed in the same same sequential order like the commands?
>
>
>
> For instance, based on previously posted emails from Christian Grove,
> topology descriptor should be processed before commands in an action,
since
> "The Topology descriptor occurs before the commands in an action." In
fact,
> all contextRequests come before the commands. If this is the case, is the
> following generalization correct?
>
>
>
> "In a transaction, actions are executed sequentially. In an action,
context
> requests (including context property modifications and context property
> audits) and commands are executed sequentially."
> [KJBII] Yes.  H.248 is, essentially, a left to right protocol.
>
>
>
> 2. How about the processing order of termination properties? Without a
> well-defined order, different MG implementations can respond differently
to
> the same command. For instance, if Signals descriptor is processed before
> Events descriptor can produce different results than the case when Events
> descriptor is processed first. [KJBII] See above comment.
>
>
>
> Regards,
>
>
>
> David Kao
>
>
>
> _______________________________________________
> Megaco mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
>
> _______________________________________________
> Megaco mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/megaco
> _______________________________________________
> Megaco mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
>
> _______________________________________________
> Megaco mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
> --__--__--
>
> _______________________________________________
> Megaco mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
> End of Megaco Digest
>
>

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