Subject: RE: [Megaco] Topology descriptor execution sequence

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?

	> -----Original Message----- 
	> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
	> Sent: Friday, September 13, 2002 12:29 AM 
	> To: [email-masked] 
	> Subject: [Megaco] Topology descriptor execution sequence 
	> 
	> 
	> 
	> 
	> 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
<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
<https://www1.ietf.org/mailman/listinfo/megaco>

---

From: SHRI KUMAR <[email-masked]>
Date: Fri, 20 Sep 2002 05:56:46 +0100 (BST)

Hi Raphael

The MEGACO's context and termination model
distinguishes the media descriptor and topology
descriptor on termination and context, respectively.
Factually speaking the mediaD defines the stream
chracteristics which can differ from one termination
to another for the same stream ID. Therefore, starting
a media stream (mediaD) is independent of how that
stream is going to be connected to another stream
(topologyD) with the same stream id. It is really only
the IDs which decide the connection. The streams can
exist independent of the connection - isolate or
1/2-way. If isolate the packets may be received and
dumped just before the ingress to the context. This is
also legible from the point of view of detecting
events and applying signals to streams which are
otherwise not connected in a context.

Had this not been the case, the protocol should have
defined the mediaD also at the context level and
included the list of terminations along side. This
would have ensured that create a stream between term1
and term2 and topology-T.

Or is there something missing here?

--shri 

 --- Raphael Tryster <[email-masked]> wrote: > In
practice, I think the software entity executing
> the media descriptor
=== message truncated === 

________________________________________________________________________
Missed your favourite TV serial last night? Try the new, Yahoo! TV.
       visit http://in.tv.yahoo.com
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: SHRI KUMAR <[email-masked]>
Date: Fri, 20 Sep 2002 05:56:46 +0100 (BST)

Hi Raphael

--shri