Subject: [Megaco] Topology descriptor execution sequence

From: [email-masked]
Date: Fri, 13 Sep 2002 09:59:09 +0530

Hi Tom/ List

I didn't get any reply/ comments on this mail.
From the earlier discussions on the mailing list, it seems that there
definitely are some existing implementations supporting Topology descriptor.
I would request them to provide some clarity on these issues in the interest
of the MEGACO interoperability.
Unless the questions/ issues raised in this mail are inconsequential and
grossly missing something, in which case please indicate so.

regards

Kapil Nayar
Hughes Software Systems Ltd.
www.hssworld.com

---------------------- Forwarded by Kapil Nayar/HSS on 09/13/2002 09:53 AM
---------------------------

[email-masked] on 09/11/2002 03:00:07 PM

To:   "[email-masked]'" <[email-masked]>
cc:    (bcc: Kapil Nayar/HSS)

Subject:  [Megaco] Topology descriptor execution sequence

Hi Tom,

I have a query on the expected processing sequence of topology....
I am not sure but probably it was discussed on the list that it is appropriate
to process the topology descriptor only after all the commands in the
corresponding action have been processed successfully. This seems to be
significant if one of the commands is ADD (termID-$), since the termination is
resolved only after ADD command processing.

Consider an action described below:
   MEGACO/1 [123.123.123.4]:55555
   Transaction = 50003 {
       Context = 1 {
         Topology {$,A3333,oneway,$, A4444, oneway, A3333, A5555, oneway},
         Modify = A3333  { Media..., Event..., Signal...},
         Modify = A4444  { Media..., Event..., Signal...},
          Add    = A5555  { Media..., Event..., Signal... }
          Add    = $ {Media..., Event..., Signal...}
     }
}

When is the topology descriptor processed??

1. Before, processing any command in the action - inherent problem because of a
reference to $ which would be resolved only after ADD($) command execution.

2. Incrementally, as and when the commands related to the terminations are
executed.
Problems -
If a command fails when part of the topology descriptor is already applied, MG
communicates the command failure but how to communicate the part-execution of
the topology descriptor. Can it be implied to the MGC?
An action can contain multiple commands referring to a single termination in any
order, in which case it may be difficult for the MG to keep track of "no pending
commands" for the terminations before executing topology tuple.

3. After, processing all the commands in the action.
Problems -
What happens if ADD(A5555) command fails?
Does MG execute the topology descriptor before sending failure at the command
level?
Even if topology descriptor is executed, is it executed in part or complete?
Again how is the topology execution communicated to the MGC? Can it be implied?
What if after successfully executing all the commands, the topology descriptor
execution failed?
The topology failures can be communicated at the action level only, without
including any command replies.
actionReply          = CtxToken EQUAL ContextID LBRKT
                       ( errorDescriptor / commandReply ) RBRKT
How does MG communicate in reply that all the commands were successful but only
topology failed to apply?
Do we need a mechanism to reply back topology failure along with command
replies?

Please reply.

Regards,

Kapil Nayar
Hughes Software Systems Ltd.
www.hssworld.com

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

DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited (HSS) and is intended solely for the use of the individual
to whom it is addressed. It may contain  privileged or confidential
information  and should not be circulated or used for any purpose other
than for what it is intended. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. HSS accepts
no responsibility for loss or damage arising from the use of the information
transmitted by this email including damage from virus.

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