Subject: [Megaco] RE: Handling of Notify Reply not received by MG

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 21 Sep 2001 10:44:39 -0400

These look like reasonable propositions.  As a complication, I would assume
that under these circumstances the MG might decide that it had lost touch
with the MGC.

-----Original Message-----
From: Chuong N. Nguyen [mailto:[email-masked]]
Sent: Friday, September 21, 2001 8:53 AM
To: Taylor, Tom-PT [NORSE:B881:EXCH]; [email-masked]
Subject: Handling of Notify Reply not received by MG

Now said that MG never gets a Reply for the Notify (due to whatever
reason)what should the MG do? 
1) LongTimer expired so the transaction for that Notify is not repeated
anymore. 
2) Should the MG keep the Event in the Event buffer due to Notify Reply not
received? 
     This seems logical since event was not Notify successfully due to
Notify Reply not received. 
3) Thus when MGC does an Audit w/ObservedEvents Descriptor, should MG 
     return any events which did not get a Notify Reply from MG? 
Thanks 
Chuong 

Tom-PT Taylor wrote: 
  
Sorry, I've been busied out for the last few weeks.  Anyway, that's the
intent: when the MG is using a non-order-preserving transport, is should not
send a second NOTIFY on the same termination until the first is replied to. 
-----Original Message----- 
From: Chuong N. Nguyen [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]] 
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]] 
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 
_______________________________________________ 
Megaco mailing list 
[email-masked] 
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 ****

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Fri, 21 Sep 2001 11:12:42 -0500

Yes, MG might decide that it had lost touch w/MGC.
Once it has re-established to a MGC, should it reports all outstanding
Notify.
Or let the MGC audits the MG to find out?

The other complication is (Still in the lost Notify scenario)
Said an onhook event Notify Reply is pending at MG - thus an outstanding
Notify for that particular termination.

Subscriber goes offhook, does this means that this offhook event can't
be Notify by MG since
it still has an outstanding onhook Notify?

Tom-PT Taylor wrote:

>
>
> These look like reasonable propositions.  As a complication, I would
> assume that under these circumstances the MG might decide that it had
> lost touch with the MGC.
>
> 1) LongTimer expired so the transaction for that Notify is not
> repeated anymore.
> 2) Should the MG keep the Event in the Event buffer due to Notify
> Reply not received?
> Sorry, I've been busied out for the last few weeks.  Anyway, that's
> the intent: when the MG is using a non-order-preserving transport, is
> should not send a second NOTIFY on the same termination until the
> first is replied to.
>
> 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.
>