Subject: [Megaco] Race condition between Modify and Subtract

From: Raphael Tryster <[email-masked]>
Date: Sun, 18 Nov 2001 15:54:48 +0200

I have a question about RFC 3015 paragraph 9.1.2, which states that "...a
media gateway may sometimes receive a Modify command that applies to a
previously subtracted termination.  Such commands should be ignored, and an
error code should be returned".

Since it is permitted for Modify commands to operate on terminations that
are in the Null context, how does an MG distinguish between the following
cases?

1.	Modify was sent before Subtract, but the commands were received in
the wrong order.  The MG should ignore the Modify.
2.	Subtract was sent (possibly long) before Modify, and received in the
same order.  The MG should process the Modify because this is the beginning
of setting up a new call.

Could the context id of the Modify command be used to distinguish the cases?
Perhaps a Modify command that refers to the termination in the Null context
should be considered new and processed, while a Modify command that refers
to the termination in a non-Null context (while the MG considers the
termination to be in the Null context) should be considered obsolete and
ignored.  This solution looks less attractive when we consider that the
rules might be different if the command is Add or Move instead of Modify.

Any other ideas as to how to make this distinction?

Raphael Tryster

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 19 Nov 2001 08:53:44 -0500

There are two possible error conditions here.  If neither condition applies,
the command must be processed without regard to any possible misordering,
because you have no choice -- the misordering is indetectible.

The two error conditions are:
 -- termination appears in the wrong context (typically it is in NULL, but
its previous context is specified)
 -- termination no longer exists (was an ephemeral)

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Sunday, November 18, 2001 8:55 AM
To: [email-masked]
Subject: [Megaco] Race condition between Modify and Subtract

I have a question about RFC 3015 paragraph 9.1.2, which states that "...a
media gateway may sometimes receive a Modify command that applies to a
previously subtracted termination.  Such commands should be ignored, and an
error code should be returned".
Since it is permitted for Modify commands to operate on terminations that
are in the Null context, how does an MG distinguish between the following
cases?
Modify was sent before Subtract, but the commands were received in the wrong
order.  The MG should ignore the Modify. 
Subtract was sent (possibly long) before Modify, and received in the same
order.  The MG should process the Modify because this is the beginning of
setting up a new call. 

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 19 Nov 2001 08:59:02 -0500

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

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.  I suspect this is getting very close to
an implementation issue rather than a protocol issue, but it is feasible.

-----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: Mon, 19 Nov 2001 08:59:02 -0500

-----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: [email-masked]
Date: Tue, 20 Nov 2001 10:09:21 +0530

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,

Thanking in advance

Regards
Atanu Mondal

---

From: [email-masked]
Date: Tue, 20 Nov 2001 10:09:21 +0530

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