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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 17 Sep 2002 12:57:14 -0400

It's quite clear that the topology descriptor is executed after the other
commands in the action.  This was stated right from the outset, to resolve
any ambiguities.  As I see it, that means that if any command along the way
fails, the topology descriptor never gets executed.  Any other views?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, September 13, 2002 12:29 AM
> To: [email-masked]
> 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
> 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.
> 
> 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.
> 
> 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.
>                        ( 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
> 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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 17 Sep 2002 12:57:14 -0400

---

From: Raphael Tryster <[email-masked]>
Date: Wed, 18 Sep 2002 08:40:33 +0200

In practice, I think the software entity executing the media descriptor
needs to be aware of the topology descriptor.  Otherwise, it will open some
unnecessary connection paths (and perhaps announce a spurious lack of
resources) that will have to be closed again when the topology descriptor is
processed.

Raphael Tryster

	-----Original Message-----
	From:	Tom-PT Taylor [SMTP:[email-masked]]
	Sent:	Tuesday, 17 September, 2002 6:57 PM
	To:	[email-masked]'; [email-masked]
	Subject:	RE: [Megaco] Topology descriptor execution sequence

	It's quite clear that the topology descriptor is executed after the
other commands in the action.  This was stated right from the outset, to
resolve any ambiguities.  As I see it, that means that if any command along
the way fails, the topology descriptor never gets executed.  Any other
views?

	> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
	> ---------------------- Forwarded by Kapil Nayar/HSS on 
<https://www1.ietf.org/mailman/listinfo/megaco>  
	> transmitted by this email including damage from virus. 
<https://www1.ietf.org/mailman/listinfo/megaco>

---

From: [email-masked]
Date: Thu, 19 Sep 2002 10:40:46 +0530

But if we execute the topology descriptor at the end of action then what will be
the behaviour of MG when topology execution fails. As per protocol grammar this
can be reported in action level error, but then what will happened to the
command's of that action that are successfully completed.
There is also a second problem viz. there may be some signal that are defined as
proceeding from termination to the interior of context. If this type of signal
comes with command, then what will be is meaning as the path within the context
(i.e. topology) is still not implemented.

Thanks & Regards,
Siddhartha Sharma

"Tom-PT Taylor" <[email-masked]> on 09/17/2002 10:27:14 PM

To:   Kapil Nayar/HSS@HSS, [email-masked]
cc:    (bcc: Siddharth Sharma/HSS)

---

From: [email-masked]
Date: Fri, 20 Sep 2002 12:42:18 +0530

Hi Christian/List,
Does this means that only add, move & subtract command in action will result in
topology descriptor implementation or it can be with every command.
Also if topology implementation with a command fails then MG will give error
response of that command. But what will be the error code for "topology
implementation failure". Does there is any such error code, if not then we
should add this.

Thanks & Regards,
Siddhartha Sharma

Christian Groves <[email-masked]> on 09/20/2002 06:55:37 AM

To:   Siddharth Sharma/HSS@HSS
cc:   Tom-PT Taylor <[email-masked]>, Kapil Nayar/HSS@HSS,
      [email-masked]

Subject:  Re: [Megaco] Topology descriptor execution sequence

Hello

H.248.1v2 sect 7.1.18 states "The Topology descriptor occurs before the commands
in an action."

This means that you must consider the topology descriptor before addressing the
commands. You should then use the information that is in the topology descriptor
when you process the commands in the message. If an ADD fails then the MGC
should be smart enough to realise any topology change concerning the failed ADD
is invalid.

Regards, Christian

> > ---------------------- Forwarded by Kapil Nayar/HSS on
--------------------------------------------------------------------------------
>                   Name: att1.htm
>    att1.htm       Type: Hypertext Markup Language (text/html)
>               Encoding: base64
>            Description: Internet HTML

---

From: [email-masked]
Date: Mon, 23 Sep 2002 13:55:22 +0530

Hi Christian,
Thanks for your reply. But still I have some doubt, PL see the embedded comments
marked with Sidd>.

Regards,
Siddhartha Sharma

Christian Groves <[email-masked]> on 09/23/2002 12:15:43 PM

Hello Siddhartha,

Its the topology descriptor that results in a certain topology descriptor
implementation not a particular command. Thus the topology descriptor can be
implemented with command in a transaction, although some combinations may not
make a lot of sense.

With regards to error codes you could return different error codes at the same
level (action level) as the topology. eg. in the case where an ADD fails you
coudl return "No termination Id matched a wildcard"

Sidd> As per grammar MG can report only action level error if topology fails
with ADD command in this case.
     actionReply          = CtxToken EQUAL ContextID LBRKT
                            ( errorDescriptor / commandReply )
Now consider the following case. If a action contain the following commands
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    = $ {Media..., Event..., Signal...}
     }
}
and ADD command fails due to topology application failure. Then MG shall reply
with action level error with error code "No termination Id matched a wildcard".
But how does MG include the success reply for the 2 MODIFY commands. Will it be
appropriate to define a topology specific error-code and include it in ADD
command reply in case of a failure during topology application. This would also
facilitate sending success replies for the 2 MODIFY commands before ADD reply.

Regards, Christian

[email-masked] wrote:
> > But if we execute the topology descriptor at the end of action then what
will
> be
> > There is also a second problem viz. there may be some signal that are
defined
> as

---

From: [email-masked]
Date: Mon, 23 Sep 2002 13:55:22 +0530

Hi Christian,

Regards,
Siddhartha Sharma

Hello Siddhartha,

Regards, Christian

will
defined

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 23 Sep 2002 09:58:16 -0400

As the inventor of the topology descriptor, Christian has to be the ultimate
authority.  I defer to his opinion.

> From: Christian Groves [mailto:[email-masked]] 
> Sent: Thursday, September 19, 2002 9:26 PM
> To: [email-masked]
> Cc: Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]; 
> [email-masked]
> H.248.1v2 sect 7.1.18 states "The Topology descriptor occurs 
> before the commands in an action."
> 
> This means that you must consider the topology descriptor 
> before addressing the commands. You should then use the 
> information that is in the topology descriptor when you 
> process the commands in the message. If an ADD fails then the 
> MGC should be smart enough to realise any topology change 
> concerning the failed ADD is invalid.
> 
> Regards, Christian
> 
> 
> > But if we execute the topology descriptor at the end of action then 
> > what will be the behaviour of MG when topology execution 
> fails. As per 
> > protocol grammar this can be reported in action level 
> error, but then 
> > what will happened to the command's of that action that are 
> > successfully completed. There is also a second problem viz. 
> there may 
> > be some signal that are defined as proceeding from 
> termination to the 
> > interior of context. If this type of signal comes with 
> command, then 
> > what will be is meaning as the path within the context 
> (i.e. topology) 
> > other commands in the action.  This was stated right from 
> the outset, 
> > to resolve any ambiguities.  As I see it, that means that if any 
> > command along the way fails, the topology descriptor never gets 
> > executed.  Any other views?
> > 
> > > 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 
> 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.
> > >
> > > 1. Before, processing any command in the action - 
> inherent problem 
> > > because of a reference to $ which would be resolved only after 
> > > ADD($) command execution.
> > >
> > > 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 -
> > > [email-masked] https://www1.ietf.org/mailman/listinfo/megaco
> > >
> > >
> > >

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 23 Sep 2002 09:58:16 -0400

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 24 Sep 2002 16:41:49 -0400

Action level errors may occur at the command level (or lower) in the reply.
See the second paragraph of section 7.1.19, "Error Descriptor".

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, September 23, 2002 4:25 AM
To: Christian Groves
Cc: Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]; [email-masked]
Subject: Re: [Megaco] Topology descriptor execution sequence

Hi Christian,
Thanks for your reply. But still I have some doubt, PL see the embedded
comments marked with Sidd>.

Regards,
Siddhartha Sharma

Christian Groves <[email-masked]> on 09/23/2002 12:15:43
PM

Hello Siddhartha,

Its the topology descriptor that results in a certain topology descriptor
implementation not a particular command. Thus the topology descriptor can be
implemented with command in a transaction, although some combinations may
not make a lot of sense.

With regards to error codes you could return different error codes at the
same level (action level) as the topology. eg. in the case where an ADD
fails you coudl return "No termination Id matched a wildcard"

Sidd> As per grammar MG can report only action level error if topology 
Sidd> fails
with ADD command in this case.
     actionReply          = CtxToken EQUAL ContextID LBRKT
                            ( errorDescriptor / commandReply ) Now consider
the following case. If a action contain the following commands 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    = $ {Media..., Event..., Signal...}
     }
}
and ADD command fails due to topology application failure. Then MG shall
reply with action level error with error code "No termination Id matched a
wildcard". But how does MG include the success reply for the 2 MODIFY
commands. Will it be appropriate to define a topology specific error-code
and include it in ADD command reply in case of a failure during topology
application. This would also facilitate sending success replies for the 2
MODIFY commands before ADD reply.

Regards, Christian

[email-masked] wrote:
>
> Hi Christian/List,
> Does this means that only add, move & subtract command in action will 
> result
in
> Also if topology implementation with a command fails then MG will give 
> error response of that command. But what will be the error code for 
> "topology implementation failure". Does there is any such error code, 
> if not then we should add this.
>
> Thanks & Regards,
> Siddhartha Sharma
> H.248.1v2 sect 7.1.18 states "The Topology descriptor occurs before 
> the
commands
> in an action."
>
> This means that you must consider the topology descriptor before 
> addressing
the
> when you process the commands in the message. If an ADD fails then the 
> MGC should be smart enough to realise any topology change concerning 
> the failed
ADD
> > what
will
> be
> > the behaviour of MG when topology execution fails. As per protocol 
> > grammar
> this
> > can be reported in action level error, but then what will happened 
> > to the command's of that action that are successfully completed. 
defined
> as
> > proceeding from termination to the interior of context. If this type 
> > of
signal
> > comes with command, then what will be is meaning as the path within 
> > the
> context
> > other commands in the action.  This was stated right from the 
> > outset, to resolve any ambiguities.  As I see it, that means that if 
> > any command along the way fails, the topology descriptor never gets 
> > > 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
> > > I am not sure but probably it was discussed on the list that it is 
> > > successfully. This seems to be significant if one of the commands 
> > > is ADD (termID-$), since the termination is resolved only after 
> > > ADD command processing.
> > >
> > > 1. Before, processing any command in the action - inherent problem 
> > > terminations are executed. Problems - If a command fails when part 
> > > of the topology descriptor is already applied, MG communicates the 
> > > 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.
> > >
----------------------------------------------------------------------------
----

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 24 Sep 2002 16:41:49 -0400

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, September 23, 2002 4:25 AM
To: Christian Groves
Cc: Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]; [email-masked]
Subject: Re: [Megaco] Topology descriptor execution sequence

Hi Christian,

Regards,
Siddhartha Sharma

Hello Siddhartha,

Regards, Christian

in
commands
the
ADD
will
defined
signal