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

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

Tom-PT Taylor wrote:
> 
> 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?

[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.

> 
> 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.

[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.

> 
> 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?

[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.

> 
> 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?

[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.

> 
> 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.

[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?

> 
> A CHOOSE wildcard alone indicates a request to create an ephemeral
> 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.

> 
> 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.

[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.

> 
> 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.

[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.

> 
> <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

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

---

From: Christian Groves <[email-masked]>
Date: Fri, 23 Nov 2001 11:09:49 +1100

G'Day Kevin,

Please see my replies below.

Christian

Kevin Boyle wrote:
> Subject:        Re: ADD with CHOOSE (was RE: [Megaco] Race condition
> between Modify a  nd Subtract)
> 
> G'Day Tom,
> 
> > I found a few other problems with the text -- it really doesn't
> address the
> [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.

[CHG] I agree that different errors will be generated depending on
seperate scenarios. If I have a IP phone MG that has 6 IP/Ephemeral
terminations which aren't in other contexts. Why can't I do
ADD(TID=ALL)? You could also use a partial TID with ALL which could
narrow the number of terminations added. We shouldn't preclude this. If
the MGC wants to do it let it, the MG will say what the consequences
are.

..snip..
> [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.

[CHG] Where in H.248/Megaco it this idea discussed? Some people may want
to specifically refer to a ephemeral other may want to use choose. If
the MGC knows the termination ID structure then it has the power to do
this. It is not like contextIDs as the MGC has no knowlodge on who these
are allocated. I do not want to mandate either behaviour in the
recommendation.

> > The termination identifier included in the Add command may consist
> of an ALL
> > or CHOOSE wildcard alone, a partially specified termination
> identifier which
> > interpret such an identifier would be too messy.]  The MG reports
> the fully
> > specified termination identifier for each termination successfully
> added to
> [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?

[CHG] OK I see your point however I don't think we need the changes.

> [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.

[CHG] Is there a compelling case not to do it this way? I don't buy the
argument about processing time as I don't see that it was a major
consideration when designing the protocol and it is certainly
implementation specific. By being able to look at local and remote it
gives the MG more concise information of what case of termination should
be chosen and the appropriate resources to choose. It leads you to have
a less complicated TID structure.

> > ALL-wildcarded termination identifier matches more than one
> TerminationID in
> > terminations successfully added and an appropriate error descriptor
> for the
> > failure.
> 
> 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.

[CHG] My prevous points above cover this. It depends on the GW you have,
the size of it, whether you partially specify the TID will ALL etc. etc.

> > TerminationId" if the given identifier does not match any
> implemented naming
> > attempt to create and add an ephemeral termination to the context
> using the
> > given identifier.
> >
> [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.
> 
> >
> > <KN> Even if we have a fixed naming pattern, we need to handle $,
> because it
> > In particular, in text encoding, the transport profile given on the
> m= line
> > of
> > the SDP
> > 'distinguishing' descriptors or properties. Should MG generate an
> error for
> > this

---

From: Christian Groves <[email-masked]>
Date: Fri, 23 Nov 2001 11:09:49 +1100

G'Day Kevin,

Christian

..snip..