Subject: RE: Notify behavior (was: RE: [Megaco] Basic doubt)

From: "David Stonehouse" <[email-masked]>
Date: Wed, 12 Sep 2001 16:02:38 -0400

Yes, both of the Notify commands could be for the same termination. This is
okay because the MGC is guaranteed to process them in the correct order.
 
Let's try:
"For transport that does not guarantee in sequence delivery of messages
(e.g., UDP), on a given termination, the MG should ensure that there is at
most one outstanding transaction containing a Notify command for that
termination at any time.  I.e., when an MG sends a transaction containing a
Notify command for a particular termination, it should wait for the MGC to
reply to the transaction before sending additional Notify commands for that
same termination.  One transaction may contain multiple Notify commands for
the same termination, because ordered processing within the transaction is
guaranteed." 

Dave

-----Original Message-----
From: Chuong N. Nguyen [mailto:[email-masked]]
Sent: Wednesday, September 12, 2001 3:44 PM
To: [email-masked]
Subject: Re: Notify behavior (was: RE: [Megaco] Basic doubt)

Hi David 

I am still not clear from your suggested wording for the Standard. 

Can we have multiple (more than 1) Notify commands for the same termination
in a transaction? 

Thanks 
Chuong 

David Stonehouse wrote: 

For each termination, the MG should not send a Notify until it has received
a Notify Reply on the last Notify.  I will amend my last suggestion to make
this point clear, and also mention the possibility that two Notify commands
could still be sent in one transaction, as this would also guarantee proper
ordering of the two requests: 

"For transport that does not guarantee in sequence delivery of messages
(e.g., UDP), on a given termination, the MG should ensure that there is at
most one outstanding Notify command at any time.  I.e., when an MG sends a
transaction containing one or more Notify commands  for a particular
termination, it should wait for the MGC to reply to the transaction before
sending additional Notify commands for that same termination." 

As I mentioned in my last e-mail, I believe this should be normative text in
section 9.1, preferrably before the "suggestions" for MGC behavior. 

Dave 
-----Original Message----- 
From: Chuong N. Nguyen [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Friday, September 07, 2001 2:41 PM 
To: [email-masked] 
Subject: Re: [Megaco] Basic doubt 

   2. On a Termination, there should normally be at most one outstanding 
      command (Add or Modify or Move), unless the outstanding commands 
      are in the same transaction.  However, a Subtract command may be 
      issued at any time.  In consequence, 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. 
   3. On a given Termination, there should normally be at most one 
      outstanding Notify command at any time. 
Tom 
Does "outstanding" here mean that a MG can't send another Notify to MGC
until MG has 
received a NotifyReply? 
Thanks 
Chuong 

Tom-PT Taylor wrote: 

This brings us back to a point which someone made recently, and which I
failed to follow up at the time.  The requirement not to have more than one
outstanding Notify on a termination at any one time was deleted from where
it occurred in H.248.  However, it should be added back in at an appropriate
point in Annex D, since it is still needed for UDP operation. 

-----Original Message----- 
From: [email-masked] 
[ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, September 06, 2001 5:56 AM 
To: [email-masked]; [email-masked]; [email-masked] 
Subject: RE: [Megaco] Basic doubt 
Hi, 
If the two messages do not have any common information between them(e.g. 
context Ids) then there is no problem at all. 
But if both the messages affect the same termination/context then there can 
be a problem. Logically I am not able to visualize a case where an 
application sends a two messages affecting the same context at the other end

of the network without waiting for the response of the first one. So I feel 
that keeping track of these kind of messages falls in the domain of the 
application rather than the stack. 
Any comments.... 
Kishore 
-----Original Message----- 
From: ext Atanum [ mailto:[email-masked] <mailto:[email-masked]>
] 
Sent: 06. September 2001 11:37 
To: Madhu Babu Brahmanapally; megaco 
Subject: Re: [Megaco] Basic doubt 
Hi all, 
I have some queries on this string.. 
Say a Megacomessage which has been sent gets delayed or some how get lost in

the network. 
The Message sent after the former reaches safely and is handed over to the 
application over the megaco stack. 
Now the timer for the first message times out and the first message is send 
again... Now who should keep track of 
which of the message is first and which is second... 
Should it be in some way that for each gateway a process will keep track of 
the message sent to the gateway and the reply received from it 
and then only the next message be sent.. or is there a way to find out which

message should be executed first and which one second... 
Can somebody please clarify this... 
_______________________________________________ 
Megaco mailing list 
[email-masked] 
http://www1.ietf.org/mailman/listinfo/megaco
<http://www1.ietf.org/mailman/listinfo/megaco>  
_______________________________________________ 
Megaco mailing list 
[email-masked] 
http://www1.ietf.org/mailman/listinfo/megaco
<http://www1.ietf.org/mailman/listinfo/megaco>  
-- 
  Alcatel USA, Inc             Internet: [email-masked] 
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613 
  **** The opinions expressed are not those of Alcatel USA, Inc **** 

-- 

  Alcatel USA, Inc             Internet: [email-masked]

  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613

  **** The opinions expressed are not those of Alcatel USA, Inc ****