Subject: RE: ADD with CHOOSE (was RE: [Megaco] Race condition between Modi fy a nd Subtract)

From: Raphael Tryster <[email-masked]>
Date: Wed, 21 Nov 2001 12:16:48 +0200

Tom,

First of all, thank you for your reply about Race condition between Modify
and Subtract, and changing the subject line after it was hijacked to a
different topic.

Regarding the current topic, I would like to ask if it ever makes sense to
Move an ephemeral termination to another context?  If the answer is no, then
it would be possible for an MG to adopt a very simple naming convention for
ephemeral terminations, in which each context id is allocated a group of
ephemeral termination ids that may be created only in that context.  Your
proposed criterion #3 gives the MGC the ability to create ephemeral
terminations with arbitrary identifiers, which makes that kind of simplicity
in the MG impossible.  If ephemeral terminations can be moved, then this
would be no great loss, as the naming convention would have to be
independent of the context anyway.

Criterion #2 in your proposal implies that the MGC is aware of the MG's
naming conventions.  Under what circumstances would it be reasonable for an
MGC developer to put that kind of vendor-specific awareness in its product?

Criterion #5 implies that the ephemeral terminations within an MG may not
all be created equal, and may be grouped in some way that make partial
wildcard specification possible.  In what kind of MG might this occur?  I
would have thought that whereas a pure wildcard (* or $ by itself) can
denote both physical and ephemeral terminations, a partially specified
wildcard (e.g. term1/* or term1/$) could only represent physical
terminations.  Are the rules more complicated than that?

Raphael Tryster

	-----Original Message-----
	From:	Tom-PT Taylor [SMTP:[email-masked]]
	Sent:	Tuesday, 20 November, 2001 7:58 PM
	To:	[email-masked]'
	Cc:	'Atanu Mondal'; [email-masked]
	Subject:	ADD with CHOOSE (was RE: [Megaco] Race condition
between Modify a nd  Subtract)

	I believe the question comes out of the discussion below is this: is
it an
	error for the MGC to request an Add=$ without specifying enough
information
	to allow the MG to determine the termination identifier it should
return?

	I have to confess that I can't dodge the issue by saying that naming
	patterns are a proprietary blot on the protocol.  Persistent
terminations
	will have terminationIDs amongst other properties, and the MG has to
know
	whether it is being asked to select from persistent or ephemeral
	terminations.

	Having accepted this, I took a look at the text of section 7.2.1 as
it
	stands in H.248v2, and particularly the first paragraph following
the API.
	I found a few other problems with the text -- it really doesn't
address the
	possibility of a partially specified termination identifier, and is
rather
	vague on a number of counts.  One item I commend to your attention:
is it
	reasonable to restrict the use of ALL wildcards in Add commands to
physical
	terminations?  I myself believe so, since otherwise the MG could end
up
	exhausting its resources in an useless frenzy of ephemeral creation.

	Another point: the text currently says that all possible matches to
an ALL
	wildcarded identifier are attempted and the results for each
reported.
	Would it not be more consistent with the operation of the protocol
to
	terminate execution of the command if an error is encountered?

	One final point: do people have views on whether the MGC can fully
specify
	the identifier for an ephemeral termination it wants the MG to
create?

	Anticipating your responses, I propose that the following text be
added to
	section 7.2.1, replacing all of the second paragraph beyond the
sentence
	"The Termination is either created, or taken from the null Context."
	Brackets [] enclose comments, which are not intended to be included
in the
	new text.
	 
	<Begin replacement text>
	  
	The termination identifier included in the Add command may consist
of an ALL
	or CHOOSE wildcard alone, a partially specified termination
identifier which
	includes one or more ALL or CHOOSE wildcards, or a fully specified
	termination identifier.  It is illegal to specify a termination
identifier
	containing both ALL and CHOOSE wildcards.  [.. because describing
how to
	interpret such an identifier would be too messy.]  The MG reports
the fully
	specified termination identifier for each termination successfully
added to
	the context as a result of the Add command. 

	A CHOOSE wildcard alone indicates a request to create an ephemeral
	termination and add it to the context.

	Usage of ALL wildcards within an Add command would be unusual.  When
they
	are present, the termination identifier shall be interpreted to
refer only
	to physical terminations residing in the NULL context.  If no
terminations
	currently in the NULL context match the ALL-wildcarded termination
	identifier in the Add command, the MG MAY return error 431 "No
TerminationId
	matched a wildcard" even if the identifier would match a termination
already
	in an active context.  [This saves the MG the pointless effort of
checking
	active contexts just to return a more accurate error code.]  If an
	ALL-wildcarded termination identifier matches more than one
TerminationID in
	the NULL context, the MG shall attempt to add each matching
termination to
	the context.  The order of attempts when multiple TerminationIDs
match is
	not specified.  As usual, a failure to add a particular termination
	terminates execution of the command; the MG reports the identities
of the
	terminations successfully added and an appropriate error descriptor
for the
	failure.

	A termination identifier which is CHOOSE-wildcarded or fully
specified may
	designate either a physical or an ephemeral termination.  In making
the
	decision as to which to add, the MG shall use the following criteria
in
	decreasing order of priority.

	 1) If the termination identifier is fully specified and it matches
an
	existing termination, the MG shall either add that termination or
return
	error 433 "TerminationId is already in a context" as appropriate.

	 2) If the MG implements fixed naming patterns for particular
termination
	types then it shall process the given identifier accordingly.
Possible
	outcomes include successful addition of a termination or error 430
"Unknown
	TerminationId" if the given identifier does not match any
implemented naming
	pattern.  Other errors are possible, particularly if the given
identifier
	matches the naming pattern for physical terminations.

	 3) If the termination identifier is fully specified and the type of
the
	termination has not been resolved by the first two rules, the MG
shall
	attempt to create and add an ephemeral termination to the context
using the
	given identifier.

	 4) If the termination identifier is partially specified with CHOOSE
	wildcards and matches one or more terminations currently in the NULL
	context, the MG shall choose one of these terminations to add to the
context
	and report the result.

	 5) Finally, if the termination identifier is partially specified
with
	CHOOSE wildcards and has not been resolved by the previous rules,
the MG
	shall attempt to create and add an ephemeral termination with a
unique
	termination identifier matching the pattern specified by the
identifier in
	the Add command.

	<End of replacement text>

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]]
	Sent: Monday, November 19, 2001 11:39 PM
	To: Taylor, Tom-PT [CAR:B800:EXCH]
	Cc: 'Atanu Mondal'; [email-masked]
	Subject: RE: [Megaco] Race condition between Modify and Subtract

	Hi Tom

	Please see my comments below:

	"Tom-PT Taylor" <[email-masked]> on 11/19/2001 07:29:02
PM

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

	Subject:  RE: [Megaco] Race condition between Modify and Subtract

	Let me sum up what has been mostly covered by others: the type of a
	termination is determined by the properties assigned to it.  In the
absence
	of a fixed naming pattern, the MG has to analyze the properties
given with
	the ADD command to decide what kind of termination to use.
	<KN> Even if we have a fixed naming pattern, we need to handle $,
because it
	doesnot refer to any specific pattern or in other words it refers to
any
	naming
	pattern.

	In particular, in text encoding, the transport profile given on the
m= line
	of
	the SDP
	should be helpful when Local and Remote are present.
	<KN> What if the MGC initially just does an ADD (term-$) without any
	'distinguishing' descriptors or properties. Should MG generate an
error for
	this
	case since the termination ID cannot be determined.

	I have maintained in the past that if the type of the termination is
	ambiguous, it can still be implemented as a software placeholder,
pending
	the receipt of further information.
	<KN> Since MG necessarily needs to respond back with a
fully-specified
	termination ID (which should comply with a naming pattern either for
	ephemeral
	or physical), it may not be possible to pend the termination type
decision
	till
	further information.

	I suspect this is getting very close to
	an implementation issue rather than a protocol issue, but it is
feasible.
	<KN> It would be helpful Tom if you can clarify.....from the
protocol
	perspective.

	Thanks & Regards,
	-Kapil Nayar

	-----Original Message-----
	From: Atanu Mondal [mailto:[email-masked]]
	Sent: Monday, November 19, 2001 12:26 AM
	To: [email-masked]
	Subject: Re: [Megaco] Race condition between Modify and Subtract

	Hi List,
	I need some clarification regarding the addition of a termination in
the
	context.
	How does a gateway understand that it need to create a ephemeral
	termination and not physical termination.
	Should there be any condition when the agent can send a "Add =$ "to
	choose any physical termination
	of the gateway, or the "$" is only meant for ephemeral termination
only.

	Thanking in advance

	Regards
	Atanu Mondal
	Net Brahma Technologies Ltd

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

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

---

From: Raphael Tryster <[email-masked]>
Date: Wed, 21 Nov 2001 12:16:48 +0200

Tom,

Raphael Tryster

	-----Original Message-----
	From:	Tom-PT Taylor [SMTP:[email-masked]]
	Sent:	Tuesday, 20 November, 2001 7:58 PM
	To:	[email-masked]'
	Cc:	'Atanu Mondal'; [email-masked]
	Subject:	ADD with CHOOSE (was RE: [Megaco] Race condition

	 
	<Begin replacement text>

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]]
	Sent: Monday, November 19, 2001 11:39 PM
	To: Taylor, Tom-PT [CAR:B800:EXCH]
	Cc: 'Atanu Mondal'; [email-masked]
	Subject: RE: [Megaco] Race condition between Modify and Subtract

	Hi Tom

	Thanks & Regards,
	-Kapil Nayar

	-----Original Message-----
	From: Atanu Mondal [mailto:[email-masked]]
	Sent: Monday, November 19, 2001 12:26 AM
	To: [email-masked]
	Subject: Re: [Megaco] Race condition between Modify and Subtract

	Hi List,

	Thanking in advance

	Regards
	Atanu Mondal

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 21 Nov 2001 13:49:58 -0500

Hi.  Comments below.

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Wednesday, November 21, 2001 5:17 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: [email-masked]
Subject: RE: ADD with CHOOSE (was RE: [Megaco] Race condition between Modi
fy a nd Subtract)

Tom, 

[PTT]
In fact, the prime value of Move is to change the active context of
ephemerals.  Examples of application are the call waiting scenario shown in
the standard, or a simple call transfer of the remote party.

[PTT]
Some profiles include naming conventions.  One of the interesting issues for
profiles will be what to do about naming conventions in different profiles
which contradict each other.

[PTT]
An example of where you might encounter grouped ephemeral terminations is
that of AAL2 subchannels within a common ATM bearer.  I could think of other
applications.

Raphael Tryster 

-----Original Message----- 
From:   Tom-PT Taylor [SMTP:[email-masked]] 
Sent:   Tuesday, 20 November, 2001 7:58 PM 
To:     [email-masked]' 
Cc:     'Atanu Mondal'; [email-masked] 
Subject:        ADD with CHOOSE (was RE: [Megaco] Race condition between
Modify a nd  Subtract) 
I believe the question comes out of the discussion below is this: is it an 
error for the MGC to request an Add=$ without specifying enough information 
to allow the MG to determine the termination identifier it should return? 
I have to confess that I can't dodge the issue by saying that naming 
patterns are a proprietary blot on the protocol.  Persistent terminations 
will have terminationIDs amongst other properties, and the MG has to know 
whether it is being asked to select from persistent or ephemeral 
terminations. 
Having accepted this, I took a look at the text of section 7.2.1 as it 
stands in H.248v2, and particularly the first paragraph following the API. 
I found a few other problems with the text -- it really doesn't address the 
possibility of a partially specified termination identifier, and is rather 
vague on a number of counts.  One item I commend to your attention: is it 
reasonable to restrict the use of ALL wildcards in Add commands to physical 
terminations?  I myself believe so, since otherwise the MG could end up 
exhausting its resources in an useless frenzy of ephemeral creation. 
Another point: the text currently says that all possible matches to an ALL 
wildcarded identifier are attempted and the results for each reported. 
Would it not be more consistent with the operation of the protocol to 
terminate execution of the command if an error is encountered? 
One final point: do people have views on whether the MGC can fully specify 
the identifier for an ephemeral termination it wants the MG to create? 
Anticipating your responses, I propose that the following text be added to 
section 7.2.1, replacing all of the second paragraph beyond the sentence 
"The Termination is either created, or taken from the null Context." 
Brackets [] enclose comments, which are not intended to be included in the 
new text. 
  
<Begin replacement text> 
  
The termination identifier included in the Add command may consist of an ALL

or CHOOSE wildcard alone, a partially specified termination identifier which

includes one or more ALL or CHOOSE wildcards, or a fully specified 
termination identifier.  It is illegal to specify a termination identifier 
containing both ALL and CHOOSE wildcards.  [.. because describing how to 
interpret such an identifier would be too messy.]  The MG reports the fully 
specified termination identifier for each termination successfully added to 
the context as a result of the Add command. 
A CHOOSE wildcard alone indicates a request to create an ephemeral 
termination and add it to the context. 
Usage of ALL wildcards within an Add command would be unusual.  When they 
are present, the termination identifier shall be interpreted to refer only 
to physical terminations residing in the NULL context.  If no terminations 
currently in the NULL context match the ALL-wildcarded termination 
identifier in the Add command, the MG MAY return error 431 "No TerminationId

matched a wildcard" even if the identifier would match a termination already

in an active context.  [This saves the MG the pointless effort of checking 
active contexts just to return a more accurate error code.]  If an 
ALL-wildcarded termination identifier matches more than one TerminationID in

the NULL context, the MG shall attempt to add each matching termination to 
the context.  The order of attempts when multiple TerminationIDs match is 
not specified.  As usual, a failure to add a particular termination 
terminates execution of the command; the MG reports the identities of the 
terminations successfully added and an appropriate error descriptor for the 
failure. 
A termination identifier which is CHOOSE-wildcarded or fully specified may 
designate either a physical or an ephemeral termination.  In making the 
decision as to which to add, the MG shall use the following criteria in 
decreasing order of priority. 
 1) If the termination identifier is fully specified and it matches an 
existing termination, the MG shall either add that termination or return 
error 433 "TerminationId is already in a context" as appropriate. 
 2) If the MG implements fixed naming patterns for particular termination 
types then it shall process the given identifier accordingly.  Possible 
outcomes include successful addition of a termination or error 430 "Unknown 
TerminationId" if the given identifier does not match any implemented naming

pattern.  Other errors are possible, particularly if the given identifier 
matches the naming pattern for physical terminations. 
 3) If the termination identifier is fully specified and the type of the 
termination has not been resolved by the first two rules, the MG shall 
attempt to create and add an ephemeral termination to the context using the 
given identifier. 
 4) If the termination identifier is partially specified with CHOOSE 
wildcards and matches one or more terminations currently in the NULL 
context, the MG shall choose one of these terminations to add to the context

and report the result. 
 5) Finally, if the termination identifier is partially specified with 
CHOOSE wildcards and has not been resolved by the previous rules, the MG 
shall attempt to create and add an ephemeral termination with a unique 
termination identifier matching the pattern specified by the identifier in 
the Add command. 
<End of replacement text> 
  
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 19, 2001 11:39 PM 
To: Taylor, Tom-PT [CAR:B800:EXCH] 
Cc: 'Atanu Mondal'; [email-masked] 
Subject: RE: [Megaco] Race condition between Modify and Subtract 

Hi Tom 

"Tom-PT Taylor" <[email-masked]> on 11/19/2001 07:29:02 PM 
To:   "'Atanu Mondal'" <[email-masked]>, [email-masked] 
cc:    (bcc: Kapil Nayar/HSS) 
Subject:  RE: [Megaco] Race condition between Modify and Subtract 

Let me sum up what has been mostly covered by others: the type of a 
termination is determined by the properties assigned to it.  In the absence 
of a fixed naming pattern, the MG has to analyze the properties given with 
the ADD command to decide what kind of termination to use. 
<KN> Even if we have a fixed naming pattern, we need to handle $, because it

doesnot refer to any specific pattern or in other words it refers to any 
naming 
pattern. 

In particular, in text encoding, the transport profile given on the m= line 
of 
the SDP 
should be helpful when Local and Remote are present. 
<KN> What if the MGC initially just does an ADD (term-$) without any 
'distinguishing' descriptors or properties. Should MG generate an error for 
this 
case since the termination ID cannot be determined. 

I have maintained in the past that if the type of the termination is 
ambiguous, it can still be implemented as a software placeholder, pending 
the receipt of further information. 
<KN> Since MG necessarily needs to respond back with a fully-specified 
termination ID (which should comply with a naming pattern either for 
ephemeral 
or physical), it may not be possible to pend the termination type decision 
till 
further information. 
I suspect this is getting very close to 
an implementation issue rather than a protocol issue, but it is feasible. 
<KN> It would be helpful Tom if you can clarify.....from the protocol 
perspective. 
Thanks & Regards, 
-Kapil Nayar 
-----Original Message----- 
From: Atanu Mondal [mailto:[email-masked]] 
Sent: Monday, November 19, 2001 12:26 AM 
To: [email-masked] 
Subject: Re: [Megaco] Race condition between Modify and Subtract 

Hi List, 
I need some clarification regarding the addition of a termination in the 
context. 
How does a gateway understand that it need to create a ephemeral 
termination and not physical termination. 
Should there be any condition when the agent can send a "Add =$ "to 
choose any physical termination 
of the gateway, or the "$" is only meant for ephemeral termination only. 
Thanking in advance 
Regards 
Atanu Mondal 
Net Brahma Technologies Ltd

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 21 Nov 2001 13:49:58 -0500

Hi.  Comments below.

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Wednesday, November 21, 2001 5:17 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: [email-masked]
Subject: RE: ADD with CHOOSE (was RE: [Megaco] Race condition between Modi
fy a nd Subtract)

Tom, 

[PTT]

[PTT]

[PTT]

Raphael Tryster 

-----Original Message----- 
From:   Tom-PT Taylor [SMTP:[email-masked]] 
Sent:   Tuesday, 20 November, 2001 7:58 PM 
To:     [email-masked]' 
Cc:     'Atanu Mondal'; [email-masked] 
Subject:        ADD with CHOOSE (was RE: [Megaco] Race condition between
Modify a nd  Subtract) 
  
<Begin replacement text> 

and report the result. 
  
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 19, 2001 11:39 PM 
To: Taylor, Tom-PT [CAR:B800:EXCH] 
Cc: 'Atanu Mondal'; [email-masked] 
Subject: RE: [Megaco] Race condition between Modify and Subtract 

Hi Tom 

-----Original Message----- 
From: Atanu Mondal [mailto:[email-masked]] 
Sent: Monday, November 19, 2001 12:26 AM 
To: [email-masked] 
Subject: Re: [Megaco] Race condition between Modify and Subtract 

Hi List,

---

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 22 Nov 2001 11:51:28 -0500

Comments inline. [KJBII]

Kevin

 -----Original Message-----
From: 	Christian Groves [mailto:[email-masked]] 
Sent:	Tuesday, November 20, 2001 7:14 PM
To:	Taylor, Tom-PT [CAR:B800:EXCH]
Cc:	[email-masked]'; 'Atanu Mondal'; [email-masked]
Subject:	Re: ADD with CHOOSE (was RE: [Megaco] Race condition between
Modify a  nd Subtract)

G'Day Tom,

I think attempting to clarify is a good thing however I believe that the
text below is not simply a clarification but changes how the protocol
works today.

Please see my comments below.

Regards, Christian

information
> to allow the MG to determine the termination identifier it should return?

[CHG] It depends on your application. Its really up to the MG to decide
how much information it needs to select a TID.

[KJBII] I agree, although I can see the benefit of restricting this
expression to mean create an ephemeral.

> vague on a number of counts.  

> One item I commend to your attention: is it
physical
> exhausting its resources in an useless frenzy of ephemeral creation.

[CHG] I believe the current text is sufficient. We shouldn't limit all
to just physical connections. You have the protection of max number of
termination per context. The MG will return an error if you do anything
too silly. Secondly if you have a small MG it may be valid to do this.

[KJBII] How would ALL in an Add command ever be equivalent to an ephemeral?
Certainly the MG won't create ephemerals in this case, and Add of a
termination already in a context is illegal.

> terminate execution of the command if an error is encountered?

[CHG] I don't read that the current text precludes termination the
execution of the command. I thought it was a common thread through the
protocol that command execution continues until an error is encountered.

[KJBII] I fully agree here.  Execute commands until an error is encountered,
then halt and return an error descriptor.

> the identifier for an ephemeral termination it wants the MG to create?

[CHG] My view is that the MGC CAN fully specify a ephemeral identifier.

[KJBII] Doesn't this run counter to the idea that it is the domain of the
gateway to name ephemeral terminations?  Why, then, would we bother with the
CHOOSE wildcard?  Why not just have the MGC explicitly name every
termination, and those that the MG doesn't know about are, by default,
ephemerals?  I believe that ephemeral Ids, like context Ids, are the domain
of the MG, and should not be fully specified by the MGC prior to creation.

> the context as a result of the Add command.

[CHG] Disagree - If you want to clarify what can be used in TIDs then
clause 6.2.2 is more appropriate. It is not specific to the ADD command. 

[KJBII] I beg to differ.  The text puts restrictions on what may be used for
Modify, Move, Subtract, Notify, and ServiceChange.  Why should Add be any
different?

> termination and add it to the context.

[CHG] Disagree - the MG may today choose a physical termination. Some
properties may point to be a physical termination.
[KJBII] While I agree with your point that under the current text CHOOSE by
itself may be used to specify a physical when coupled with appropriate Local
and Remote descriptors, is there a compelling usecase for it to be that way?
By adding this restriction, the protocol is made less complex, and
processing time required by the MG to execute this command is reduced.

TerminationId
already
> terminations successfully added and an appropriate error descriptor for
the

[CHG] Disagree - with ALL only being for physical and I don't think we
need to restate standard command handling.

[KJBII] I think that Tom's suggestion here, once again, simplifies the
processing required for the Add command.  If there are no terminations in
the NULL context, then what will checking every existing term accomplish?
And, while I agree that the last sentence is redundant, I don't see a
problem with restating it for clarity.

"Unknown
context
> termination identifier matching the pattern specified by the identifier in

[CHG] Disagree - This should be very simple. The MG should attempt to
select a ephemeral or physical termination based on the provided
termination ID (CHOOSE, Partial, ALL, fully specified) and the
properties provided in the ADD command.

[KJBII] I agree with both of you here, I guess.  I do believe that this
should be simple; but then again, I don't see these guidelines as being all
that complex either.  I don't particularly like item 3, though - this goes
back to the ephemeral ID being the domain of the MG.  I think that if the
term name is fully specified, and it doesn't exist in the NULL context,
return an error.

absence

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 27 Nov 2001 23:36:31 -0500

This has a great deal of appeal, not least because it solves a problem I
have been wrestling with: is there any way of standardizing the constraints
on package compatibility on the same termination?  I have always been wary
of typing, however, because it involves the definition of types and their
registration with IANA.  I am nervous that we could get lost in a swamp of
endless variations on ATM connections, for instance.  Moreover, does type
express only the top-most layer of the transport stack, or does it look
below that?  If we can come up with satisfactory answers to these concerns I
would be happy to work on the mechanics of the proposal.  I don't even think
it requires a protocol change -- it might be possible to do it with a
package.

-----Original Message-----
From: Troy Cauble [mailto:[email-masked]]
Sent: Monday, November 26, 2001 11:21 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: [email-masked]'; 'Atanu Mondal'; [email-masked]
Subject: Re: ADD with CHOOSE (was RE: [Megaco] Race condition between
Modify a nd Subtract)

information
> stands in H.248v2, and particularly the first paragraph following the API.

Since we're changing things for V2...

I've always maintained that since the MGC knows what
type of termination it wants, it should simply *TELL*
the MG.  (type=TDM or something)

While it's been pointed out that an "empty vessel" approach
is possible, it's annoying and unnecessary.  I've not yet 
seen a good reason why this protocol makes the MG *DEDUCE* 
the type of termination by searching descriptors.

-troy

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 27 Nov 2001 23:36:31 -0500

-----Original Message-----
From: Troy Cauble [mailto:[email-masked]]
Sent: Monday, November 26, 2001 11:21 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: [email-masked]'; 'Atanu Mondal'; [email-masked]
Subject: Re: ADD with CHOOSE (was RE: [Megaco] Race condition between
Modify a nd Subtract)

information

-troy