Subject: [Megaco] RE: ADD with CHOOSE

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

Comments below.  Since we are addressing H.248v2, changes to the protocol
are conceivable, but obviously not without consensus.

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

[PTT] At a minimum we should agree on the error code the MG returns if it
can't decide.  We probably need a new one.  

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

[PTT] I accept your point unless there is an overwhelming consensus
otherwise.

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

[PTT] I'd still like that made clear.  I'll propose alternate text depending
on the outcome of this discussion.

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

[PTT] That's what I assumed.

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

[PTT] Some things are specific to the Add command.  I wouldn't consider
limiting the scope of ALL in a Modify, for instance.  That said, maybe this
particular text is more general in application.  I'll think about it.

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

[PTT] Up to yesterday I was committed to a model which assumed the MG could
make its decisions based on properties.  But while I was thinking through
the text we're commenting on, I realized that at least in theory, the MGC is
free to change the properties of any termination at any time.  I really
think we need to do more work on that aspect (which I'll discuss in a
separate E-mail), but in the meantime it raised the importance of naming
patterns in my mind.  Probably I went too far.

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

[PTT] Already discussed above, but I'll repeat that I think existing text
contradicts standard command handling.  Maybe we should simply make sure
that standard command handling is documented in its appropriate section,
then pull the text out of 7.2.1.

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

> 
> <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: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 21 Nov 2001 13:42:11 -0500

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

Regards, Christian

information

the

physical

ALL
which
fully
to

TerminationId
already
in
the

"Unknown
naming
the
context

absence
it
line
for