Subject: Re: Some Megaco Queries

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 3 Nov 1999 08:14:13 -0500

Answers below.

> -----Original Message-----
> From: Prashant Jain [SMTP:[email-masked]]
> Sent: Monday, November 01, 1999 11:20 PM
> To:   [email-masked]
> Subject:
>
> hi brian, Tom,
>
> We have few implementation queries in the draft
> "draft-ietf-megaco-protocol-04.txt".
>
> 1. In section 8, it is mentioned that if a command in a Transaction
> Request
> contains a wildcarded TerminationID, then a Response within the
> Transaction
> Reply is included for each matching TerminationID.  Now take the case of
> an
> AUDIT Command Request (whether Audit Cap. or  Audit Value) being sent from
> MGC
> to MG for the audit all terminations of MG using wildcard . Considering
> 'N'
> number of Terminations in MG ( N may be a large value, say, 10000) , then
> the
> above logic may result into a reply which shall
> contain N responses for single command in the Transaction Reply.
>      Our query is can we split the number of responses in a single Reply
> by
> having a upper bound on the number of Command Responses  being generated
> for a
> single command Request or all the Responses should be sent in one shot for
> wildcarded Terminations.
        [[TomT]]
        The protocol makes no provision for splitting large messages.  This
is an open issue.

> 2.  In the Section 8, it is written that a Transaction guarentees ordered
> Command processing. Moreover, a Transaction consist of one or more
> actions, an
> action being identified by a ContextID.
>      Now, if a transaction contains one or more actions ( i.e. multiple
> contexts
> information) , how can one expect to have ordered processing across
> Contexts
> because as far as our interpretation, the Contexts pertains to
> terminations in a
> call and the ordered processing should be guarenteed within a context.
>      With this point of view, one can have only single ContextID
> inofrmation in
> a Transaction if a transaction guarentees ordered processing, except for
> the
> case of MOVE command in which one can have multiple contextIDs in CALL
> FORWARDING scenario.
> Please through some light on this.
        [[TomT]]
        How you use transactions is up to you.  The mechanism is there, but
as you argue, it may not make sense to apply it with multiple actions in
most cases.  The implied issue is whether we can identify once and for all
all of the circumstances where ordering of multiple actions is required.  I
suspect we cannot do so, because the protocol will be used for more complex
operations than just setting up voice calls.  A particular product may be
aimed at an application where that sort of decision can be made.  I'm not
sure what it buys you in terms of a simpler implementation.

> 3.  If a particulat termination has been indicated to be hardware blocked
> by a
> servicer change request from MG. Say if this termination was in some
> context,
> then MGC will try to delete it from that context using the Megacop
> Subtract
> command.
> What does MG do in this case. Our understanding is that it will remove the
> termination from the context. But then what happens to the embedded
> signals and
> events specified for application in the subtract command. Do they get
> ignored or
> an error condition is returned in the subtract response. Basically, what
> is the
> MG behavior in such cases.
        [[TomT]]
        I agree that we should specify behaviour for out of service
terminations.  It seems fairly clear that while a termination is out of
service (as opposed to under test) signals cannot be applied to it and it
will not report events.  The question is whether we want deferred support of
events and signals -- the ability to provide descriptors which apply only
when the termination returns to service.  For signals at least I suspect the
answer is NO: the loss of control over timing of the application of the
signal would be unacceptable in most cases.  So the only question is whether
we want to allow the MGC to specify an event descriptor for an out of
service termination, to take effect when it returns to service.

> 4.  In the ANNEX E.1 , the responses are acknowledged by "response
> Acknowledgement parameter" to emulate three-way handshake, like TCP.
> However, in
> the grammar, we are not having any such parameter to get the response
> acknowledged.
        [[TomT]]
        Sounds like an editorial error.

> 5. As per the draft, in the MG configuration, a primary and the list of
> secondary MGCs are configured. Our query is whether the secondary MGCs are
> meant
> for redundant takeover in the case of MGC failure or its up to the
> implementor
> to  configure secondary MGCs as redundant ones or not. In other words, if
> a MG
> switches from a primary MGC to a secondary one, will all the ongoing
> transactions stay or they be lost.
        [[TomT]]
        Depends on the implementation, I'd say.

> regards,
>
> -Prashant Jain
> ( for Gateway Team, Hughes Software Systems)

---

From: John Segers <[email-masked]>
Date: Thu, 4 Nov 1999 10:51:09 +0100

Tom, Prashant,

One additional comment, re. the three way handshake: we added the syntax
for this in Red Bank.

John

> Tom-PT Taylor wrote:
>      1. In section 8, it is mentioned that if a command in a
>      Transaction Request
>      Reply is included for each matching TerminationID.  Now take the
>      case of an
>      AUDIT Command Request (whether Audit Cap. or  Audit Value) being
>      sent from MGC
>      to MG for the audit all terminations of MG using wildcard .
>      Considering 'N'
>      number of Terminations in MG ( N may be a large value, say,
>      10000) , then the
>           Our query is can we split the number of responses in a
>      single Reply by
>      having a upper bound on the number of Command Responses  being
>      generated for a
>      The protocol makes no provision for splitting large messages.
>      This is an open issue.
>
>      Command processing. Moreover, a Transaction consist of one or
>      more actions, an
>           Now, if a transaction contains one or more actions ( i.e.
>      multiple contexts
>      information) , how can one expect to have ordered processing
>      across Contexts
>      a Transaction if a transaction guarentees ordered processing,
>      except for the
>      How you use transactions is up to you.  The mechanism is there,
>      but as you argue, it may not make sense to apply it with multiple
>      actions in most cases.  The implied issue is whether we can
>      identify once and for all all of the circumstances where ordering
>      of multiple actions is required.  I suspect we cannot do so,
>      because the protocol will be used for more complex operations
>      than just setting up voice calls.  A particular product may be
>      aimed at an application where that sort of decision can be made.
>      I'm not sure what it buys you in terms of a simpler
>      implementation.
>
>      3.  If a particulat termination has been indicated to be hardware
>      blocked by a
>      servicer change request from MG. Say if this termination was in
>      some context,
>      then MGC will try to delete it from that context using the
>      Megacop Subtract
>      command.
>      termination from the context. But then what happens to the
>      embedded signals and
>      events specified for application in the subtract command. Do they
>      get ignored or
>      an error condition is returned in the subtract response.
>      Basically, what is the
>      terminations.  It seems fairly clear that while a termination is
>      out of service (as opposed to under test) signals cannot be
>      applied to it and it will not report events.  The question is
>      whether we want deferred support of events and signals -- the
>      ability to provide descriptors which apply only when the
>      termination returns to service.  For signals at least I suspect
>      the answer is NO: the loss of control over timing of the
>      application of the signal would be unacceptable in most cases.
>      So the only question is whether we want to allow the MGC to
>      specify an event descriptor for an out of service termination, to
>      take effect when it returns to service.
>
>      Acknowledgement parameter" to emulate three-way handshake, like
>      TCP. However, in
>      secondary MGCs are configured. Our query is whether the secondary
>      MGCs are meant
>      for redundant takeover in the case of MGC failure or its up to
>      the implementor
>      to  configure secondary MGCs as redundant ones or not. In other
>      words, if a MG

--
John Segers                                  email: [email-masked]
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954