Subject: RE: [Megaco] Basic doubt

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 27 Nov 2001 23:36:36 -0500

The two sections can be reconciled by saying that, in accordance with
section 7.1.9, processing of events can continue in uninterrupted fashion.
However, in accordance with 9.1.3 and assuming UDP transport, the MG has to
hold on to any events that have been recognized on the termination until the
response to the earlier Notify has come back; then it can send all of the
accumulated event reports in a new Notify.  These events are matched against
the current Events descriptor rather than buffered according to the
EventBufferDescriptor for later matching.

Maybe this is what you are saying.  In the six months over which we debated
how Megaco events should work, we found it impossible to come to a clear
understanding of the MGCP model.  This is not to denigrate the assistance of
MGCP experts in firming up how Megaco should work.  I'll confess that I
haven't looked at MGCP since, and the documentation may now be much clearer.

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Tuesday, November 27, 2001 10:05 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Chuong N. Nguyen'; [email-masked]
Subject: RE: [Megaco] Basic doubt

What I gather from following this thread is that there is a contradiction in
RFC 3015 between sections 7.1.9 and 9.1.3.  Section 7.1.9 allows the MG to
continue uninterrupted processing of events if EventBufferControl is Off,
while 9.1.3 requires waiting for acknowledgement of a Notify.  So the
algorithm of 7.1.9 is OK when using TCP, but 9.1.3 is required when using
UDP.  Thus 7.1.9 needs to be modified when using UDP.
Would it be correct to suggest that the modification needed to 7.1.9 is
precisely the MGCP notification state feature that is missing in Megaco?
That is, EventBufferControl = Off behaves like LockStep until the reply to
Notify is received?
Raphael Tryster 

-----Original Message----- 
From:   Tom-PT Taylor [SMTP:[email-masked]] 
Sent:   Friday, 21 September, 2001 2:39 PM 
To:     'Chuong N. Nguyen'; [email-masked] 
Subject:        RE: [Megaco] Basic doubt 
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 ****

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