From megaco-admin@ietf.org  Fri Jan  2 10:05:34 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11258
	for <megaco-archive@lists.ietf.org>; Fri, 2 Jan 2004 10:05:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcQrI-0003FB-L1; Fri, 02 Jan 2004 10:05:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcQqu-0003EA-Tg
	for megaco@optimus.ietf.org; Fri, 02 Jan 2004 10:04:55 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11164
	for <megaco@ietf.org>; Fri, 2 Jan 2004 10:04:37 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcQqn-0004eC-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:04:33 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcQn3-0004a4-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:00:44 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcQlS-0004Wd-00
	for megaco@ietf.org; Fri, 02 Jan 2004 09:59:02 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i02EwUk01476
	for <megaco@ietf.org>; Fri, 2 Jan 2004 09:58:30 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y10GP7>; Fri, 2 Jan 2004 09:58:31 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D7AF82C@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Steve Cipolli <SCipolli@radvision.com>,
        Steve Cipolli
	 <SCipolli@radvision.com>,
        "'Troy Cauble'" <troy@bell-labs.com>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 L), & Short T imers (S)
Date: Fri, 2 Jan 2004 09:58:21 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

OK.  I can see the benefit of both constructs.  Let me see.  How about:
 
>>If the Z specifier is not followed by a digit (0-9, A-K or the wildcard
X), then the MG shall reject the digitmap as invalid protocol.  When used
inside a range notation, the Z specifier applies solely to the immediately
following digit.  When used immediately prior to a range, the Z modifier
applies to all digits in the range (thereby requiring a match in the range
to be long duration).<<
 
Better?
 
Kevin



  _____  

From: Steve Cipolli [mailto:SCipolli@radvision.com] 
Sent: Friday, December 12, 2003 5:31 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Steve Cipolli; 'Troy Cauble'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)


Kevin,
 
I think "ZX" and "Z[123]" should be valid.  Your additions seem to prohibit
these.  
 
On a related topic should an empty range specification ("[]") be rejected as
well, since nothing could possibly match it.
 
--Stephen
 

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Wednesday, December 10, 2003 7:35 PM
To: Steve Cipolli; 'Troy Cauble'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)



All, 

Here is some proposed text for this.  I will include this in the IG.  Please
let me know any changes that would be better.  New text is demarcated by
>><<.

7.1.14.3        DigitMap Syntax 
... 
In addition to these event symbols, the string may contain "S" and "L"
inter-event timing specifiers and the "Z" duration modifier. "S" and "L"
respectively indicate that the MG should use the short (S) timer or the long
(L) timer for subsequent events, overriding the timing rules described
above. If an explicit timing specifier is in effect in one alternative event
sequence, but none is given in any other candidate alternative, the timer
value set by the explicit timing specifier must be used. If all sequences
with explicit timing controls are dropped from the candidate set, timing
reverts to the default rules given above. >>If used inside a range notation,
the S and L specifiers shall be ignored.<<  Finally, if conflicting timing
specifiers are in effect in different alternative sequences, the long timer
shall be used.

A "Z" designates a long duration event: placed in front of the symbol(s)
designating the event(s) which satisfy a given digit position, it indicates
that that position is satisfied only if the duration of the event exceeds
the long-duration threshold. The value of this threshold is assumed to be
provisioned in the MG.  >>If the Z specifier is not followed by a digit (0-9
or A-K), then the MG shall reject the digitmap as invalid protocol.  When
used in a range notation, the Z specifier applies solely to the immediately
following digit.<<

Kevin 
________________________________ 

        From: Steve Cipolli [mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
        Sent: Friday, December 05, 2003 1:09 PM 
        To: Boyle, Kevin [NCRTP:3Z40:EXCH]; 'Troy Cauble' 
        Cc: megaco@ietf.org 
        Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
Timers ( L), & Short T imers (S) 
        
        
        While I tend to agree with most of the answers below, I don't see
any of this specified in the specification.  If we can agree that the
answers below are the correct interpretation, then we still need
clarification in the spec or implementors guide.  I'm still hoping the
original author of this section of the spec will clarify the original
intention.

         
        --Stephen 

                -----Original Message----- 
                From: Kevin Boyle [mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> ] 
                Sent: Tuesday, December 02, 2003 3:18 PM 
                To: Steve Cipolli; 'Troy Cauble' 
                Cc: megaco@ietf.org 
                Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z),
Long Timers ( L), & Short T imers (S) 
                
                

                Comments inline. [KJBII] 

                Kevin 

                -----Original Message----- 
                From: Steve Cipolli [mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
                Sent: Tuesday, December 02, 2003 2:40 PM 
                To: 'Troy Cauble'; Boyle, Kevin [NCRTP:3Z40:EXCH] 
                Cc: megaco@ietf.org 
                Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z),
Long Timers ( L), & Short T imers (S) 

                Perhaps I moved us off track a bit.  It is clear that there
is more than one interpretation of the specification with regard to L, S,
and to a lesser extent Z.  Can the authors comment on what the intent of the
specification was and then perhaps we can reach some conclusion?

                Here is a partial list of odd digitmaps that seem to defy
interpretation: 
                        "123Z"                          - "Z" ignored or
error? 
                [KJBII] Z here has nothing to modify.  Error. 

                        "123S"                  - "S" (or "L") ignored or
error? 
                [KJBII] In this instance, the digitmap switches to short
interdigit timing after detecting "123".  So, neither. 

                        "1ZZ23"                 - First "Z" ignored or
error? 
                [KJBII] Because Z is defined as modifying the following
digit, and Z cannot modify Z, this should be an error. 

                        "1ZSSSSSSSSS23"         - "Z" applied to the "2" or
ignored or error? 
                [KJBII] See above.  Error as Z cannot modify S (or L). 

                        "135[2Z46]"                     - "Z" applied to "4"
or to all in the range (246) or ignored or error? 

                [KJBII] Z applies solely to the 4 here. 

                        "135[246Z]79"           - "Z" applied to "7" or
ignored or error? 
                [KJBII] Nothing for Z to modify.  Error. 

                        "135[2S46]"                     - "S" (or "L")
applied to all in range (246) or ignored or error? 

                [KJBII] This is the root of our earlier discussion.  L and S
do not modify digits -- they modify timing strategy for the digitmap at the
time they are encountered.  [246] means "match 2, 4 or 6".  So [2S46]
means... What exactly? "Match 2, short timeout, 4 or 6"?  Or "match 2, 4 or
6 while running the short timer for this digit only"?  Or "run the short
timer S after detecting 2, but not if 4 or 6 is detected"?  If the string
were "135S[246]" then we would start using the short timer before looking
for 2, 4 or 6.  If it were "135[246]S", we would start using the short timer
AFTER matching 2, 4 or 6.  But, with the S timer INSIDE the range, that
would indicate that the timer would have to fire to continue.  For instance,
if the string were "135[2S46]79", that would seem to indicate that if NO
digit was detected for the duration of the short timer, then we should
continue with the string to find 7.  This is a contrary usage to S and L at
any other point in a digitmap.  I think S and L should be ignored within
ranges.  If the MGC wants to use the S or L timer, then put them outside the
range.

                        "135[2L4S6]"            - "L" or "S" applied or both
(somehow?) or ignored or error? 
                [KJBII] See above -- the same arguments apply here.  I would
note that L would never get "detected" here, since S would match first.

                Thanks, 
                --Stephen 

                        

                > -----Original Message----- 
                > From: Steve Cipolli [mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
                > Sent: Monday, December 01, 2003 8:01 PM 
                > To: 'Troy Cauble'; Kevin Boyle 
                > Cc: megaco@ietf.org 
                > Subject: RE: [Megaco] Digit Maps: Long Duration
Modifier(Z), Long 
                > Timers ( L), & Short T imers (S) 
                > 
                > 
                > Part of the problem is the term "alternatives" is not
clear.  
                > The text in 
                > 7.1.14.3 says of "alternatives": 
                > A DigitMap, according to this syntax, is defined either by
a string or 
                > by a list of strings.  Each string in the list is an
alternative event 
                > sequence, specified either as a sequence of digit map
symbols or as a 
                > regular expression of digit map symbols. 
                > 
                > My reading of this is that "alternatives" are each string
and not the 
                > possible sequences through a range, but admittedly this is
not clear. 
                > 
                > The section doesn't seem to explain other odd sequences
like "123Z". 
                > Presumably the "Z" is simply ignored although an error
could also be 
                > considered the proper outcome. 
                > 
                > I must say I prefer an interpretation in which the number
of possible 
                > ways to perform the same action is as close to 1 and
possible. 
                > Therefore, I'd 
                > prefer to ban (or at least ignore) "L" and "S" within
ranges. 
                > 
                > --Stephen 
                > 
                > > -----Original Message----- 
                > > From: Troy Cauble [mailto:troy@bell-labs.com
<mailto:troy@bell-labs.com> ] 
                > > Sent: Monday, December 01, 2003 6:33 PM 
                > > To: Kevin Boyle 
                > > Cc: megaco@ietf.org 
                > > Subject: Re: [Megaco] Digit Maps: Long Duration
Modifier(Z), Long 
                > > Timers ( L), & Short T imers (S) 
                > > 
                > > 
                > > 
                > > 
                > > I disagree that "L" and "S" are meaningless within a
range. 
                > > 
                > > "L" and "S" are used to specify the timer used for
"subsequent 
                > > events". 
                > > 
                > > I would argue that the "5" is a subsequent event in
"[34L]5", just 
                > > as it is in "[34]L5". 
                > > 
                > > I would also argue that the "4" in "[3L4]5" is NOT a
"subsequent 
                > > event", although one might debate the definition of
"subsequent". 
                > > 
                > > In summary, I think "[L34]5", "[3L4]5", "[34L]5", and 
                > "[34]L5" are all 
                > > the same. (And the "L" is not meaningless.) 
                > > 
                > > 
                > > Note that section 7.1.14.3 does bother to specify what
happens when 
                > > explicit timing specifiers are only active in some
"alternatives", 
                > or when they 
                > > differ in among alternatives -- the same timer value is
used for all 
                > > alternatives. 
                > > 
                > > 
                > > 7.1.14.3: 
                > > 
                > >  > In addition to these event symbols, the string may
contain "S" 
                > > and "L" 
                > >  > inter-event timing specifiers and the "Z" duration
modifier. "S" 
                > > and "L" 
                > >  > respectively indicate that the MG should use the
short (S) timer 
                > > or the  > long (L) timer for subsequent events,
overriding the 
                > > timing rules  > described above. If an explicit timing
specifier is 
                > > in effect in one  > alternative event sequence, but none
is given in 
                > > any other candidate  > alternative, the timer value set
by the 
                > > explicit timing specifier must be  > used. If all
sequences with 
                > > explicit timing controls are dropped from the  >
candidate set, 
                > > timing reverts to the default rules given above.
Finally,  > if 
                > > conflicting timing specifiers are in effect in different
alternative  
                > > > sequences, the long timer shall be used. 
                > > 
                > > 
                > > -troy 
                > > 
                > > 
                > > 
                > > Kevin Boyle wrote: 
                > > 
                > > > Since a range means "match one of these", I would
agree 
                > > with the assessment 
                > > > that L and S are meaningless within a range. 
                > > >  
                > > > Kevin 
                > > > 
                > > > 
                > > >   _____ 
                > > > 
                > > > From: Steve Cipolli [mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
                > > > Sent: Monday, December 01, 2003 5:22 PM 
                > > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org 
                > > > Subject: RE: [Megaco] Digit Maps: Long Duration 
                > > Modifier(Z), Long Timers ( 
                > > > L), & Short T imers (S) 
                > > > 
                > > > 
                > > > Thanks for the feedback.  
                > > >  
                > > > Just to make sure I understand the L and S cases: 
                > > > They are syntactically legal in a range specification,
but 
                > > semantically they 
                > > > have no effect.  Correct? 
                > > >  
                > > > --Stephen 
                > > > 
                > > > -----Original Message----- 
                > > > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> ] 
                > > > Sent: Monday, December 01, 2003 5:15 PM 
                > > > To: Steve Cipolli; megaco@ietf.org 
                > > > Subject: RE: [Megaco] Digit Maps: Long Duration 
                > > Modifier(Z), Long Timers ( 
                > > > L), & Short T imers (S) 
                > > > 
                > > > 
                > > > Your interpretation is correct.  Because Z changes how
a 
                > > digit is matched, 
                > > > it makes sense within a range.  Think of Z as part of
the 
                > > digit it modifies, 
                > > > rather than a separate symbol. 
                > > >  
                > > > The L and S timers within a digitmap give specific 
                > > instruction as to which 
                > > > timer to run at that point in the digitmap.  While
allowed 
                > > in a range, I 
                > > > don't think they provide much value within a range
since 
                > they do not 
                > > > actually match anything.  For effective use, they
should be 
                > > outside the 
                > > > range. 
                > > >  
                > > > Kevin 
                > > > 
                > > > 
                > > >   _____ 
                > > > 
                > > > From: Steve Cipolli [mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
                > > > Sent: Monday, December 01, 2003 3:26 PM 
                > > > To: megaco@ietf.org 
                > > > Subject: [Megaco] Digit Maps: Long Duration
Modifier(Z), 
                > > Long Timers (L), & 
                > > > Short T imers (S) 
                > > > 
                > > > 
                > > >  
                > > > According to the syntax in RFCs 3015 & 3525 the long 
                > > duration modifier (Z), 
                > > > Long Timers (L), & Short Timers (S) in digit maps can 
                > > appear in a digit 
                > > > range.  For example (where Z is 1000ms): 
                > > >     "135[2Z46]" 
                > > >  
                > > > Is this valid?  If it is valid, does this mean that
the 
                > > fourth digit event 
                > > > must be either 2, 6 (held for any duration) or 4 held
for 1000 ms? 
                > > >  
                > > > How does long timer (L) and short timer (S) in a digit

                > range apply? 
                > > >  
                > > > --Stephen 
                > > >  
                > > >  
                > > > 
                > > > 
                > > > _______________________________________________ 
                > > > Megaco mailing list 
                > > > Megaco@ietf.org 
                > > > https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  
                > > 
                > > 
                > > 
                > > _______________________________________________ 
                > > Megaco mailing list 
                > > Megaco@ietf.org 
                > > https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  
                > > 
                > 
                > 
                > _______________________________________________ 
                > Megaco mailing list 
                > Megaco@ietf.org 
                > https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  
                > 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan  2 10:10:48 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11790
	for <megaco-archive@odin.ietf.org>; Fri, 2 Jan 2004 10:10:48 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcQwQ-0003mG-3m
	for megaco-archive@odin.ietf.org; Fri, 02 Jan 2004 10:10:22 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i02FAMfX014516
	for megaco-archive@odin.ietf.org; Fri, 2 Jan 2004 10:10:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcQwP-0003m3-UM
	for megaco-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 10:10:21 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11740
	for <megaco-web-archive@ietf.org>; Fri, 2 Jan 2004 10:10:17 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcQwI-0004oh-00
	for megaco-web-archive@ietf.org; Fri, 02 Jan 2004 10:10:14 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcQtc-0004i5-00
	for megaco-web-archive@ietf.org; Fri, 02 Jan 2004 10:07:31 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcQre-0004eu-00
	for megaco-web-archive@ietf.org; Fri, 02 Jan 2004 10:05:26 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcQrG-0003Ei-Dz; Fri, 02 Jan 2004 10:05:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcQqP-0003Dq-VP
	for megaco@optimus.ietf.org; Fri, 02 Jan 2004 10:04:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11096
	for <megaco@ietf.org>; Fri, 2 Jan 2004 10:03:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcQq8-0004cO-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:03:52 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcQmu-0004Ze-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:00:35 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcQlI-0004W4-00
	for megaco@ietf.org; Fri, 02 Jan 2004 09:58:52 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i02EwKk01466
	for <megaco@ietf.org>; Fri, 2 Jan 2004 09:58:20 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y10GPV>; Fri, 2 Jan 2004 09:58:21 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D7AF822@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: gsachin@hss.hns.com, megaco@ietf.org
Subject: RE: [Megaco] ICAS Package 'Call Duration' statistics
Date: Fri, 2 Jan 2004 09:58:12 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: gsachin@hss.hns.com [mailto:gsachin@hss.hns.com] 
Sent: Saturday, December 20, 2003 4:51 AM
To: megaco@ietf.org
Subject: [Megaco] ICAS Package 'Call Duration' statistics





hi List,

the 'Call Duration' statistics in the ICAS package is described as

***
6.4.1 Call Duration
StatisticID: cd (0x0001)
Description: Provides the cumulative duration the termination is in active
call context i.e. from the point of applying/receiving "Answered"
signal till the point of release ("Clear-forward" or "Clear-back")
initiation.
***

Can somebody pls specify what 'active call context' refers to?
[KJBII] The text describes exactly what it means: from the point of
applying/receiving "Answered" signal till the point of release
("Clear-forward" or "Clear-back") initiation.

Should this be related to the stream mode property also?
[KJBII] No.  The text describes exactly what it should be.


Also the NT package define 'duration' statistics. the description is as
follows

***
        Description: Provides duration of time the termination has been
        in the context.
***

How does both these statistics differ. A termination can support both these
statistics.
[KJBII] Again, the text describes exactly what the statistic is.  Duration
in the nt package is the length of time the termination has been in a
context.  The two stats are different.  Indeed, both packages can be
supported by the same termination.  Since they are different measurements, I
don't see a problem.


regards
Sachin Gupta

"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain  privileged or confidential information and should
not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From exim@www1.ietf.org  Fri Jan  2 10:10:54 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11813
	for <megaco-archive@odin.ietf.org>; Fri, 2 Jan 2004 10:10:54 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcQwV-0003mb-FY
	for megaco-archive@odin.ietf.org; Fri, 02 Jan 2004 10:10:27 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i02FARns014535
	for megaco-archive@odin.ietf.org; Fri, 2 Jan 2004 10:10:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcQwV-0003mM-BN
	for megaco-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 10:10:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11750
	for <megaco-web-archive@ietf.org>; Fri, 2 Jan 2004 10:10:23 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcQwO-0004op-00
	for megaco-web-archive@ietf.org; Fri, 02 Jan 2004 10:10:20 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcQtf-0004iF-00
	for megaco-web-archive@ietf.org; Fri, 02 Jan 2004 10:07:34 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcQre-0004ev-00
	for megaco-web-archive@ietf.org; Fri, 02 Jan 2004 10:05:26 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcQrI-0003FB-L1; Fri, 02 Jan 2004 10:05:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcQqu-0003EA-Tg
	for megaco@optimus.ietf.org; Fri, 02 Jan 2004 10:04:55 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11164
	for <megaco@ietf.org>; Fri, 2 Jan 2004 10:04:37 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcQqn-0004eC-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:04:33 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcQn3-0004a4-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:00:44 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcQlS-0004Wd-00
	for megaco@ietf.org; Fri, 02 Jan 2004 09:59:02 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i02EwUk01476
	for <megaco@ietf.org>; Fri, 2 Jan 2004 09:58:30 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y10GP7>; Fri, 2 Jan 2004 09:58:31 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D7AF82C@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Steve Cipolli <SCipolli@radvision.com>,
        Steve Cipolli
	 <SCipolli@radvision.com>,
        "'Troy Cauble'" <troy@bell-labs.com>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 L), & Short T imers (S)
Date: Fri, 2 Jan 2004 09:58:21 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

OK.  I can see the benefit of both constructs.  Let me see.  How about:
 
>>If the Z specifier is not followed by a digit (0-9, A-K or the wildcard
X), then the MG shall reject the digitmap as invalid protocol.  When used
inside a range notation, the Z specifier applies solely to the immediately
following digit.  When used immediately prior to a range, the Z modifier
applies to all digits in the range (thereby requiring a match in the range
to be long duration).<<
 
Better?
 
Kevin



  _____  

From: Steve Cipolli [mailto:SCipolli@radvision.com] 
Sent: Friday, December 12, 2003 5:31 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Steve Cipolli; 'Troy Cauble'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)


Kevin,
 
I think "ZX" and "Z[123]" should be valid.  Your additions seem to prohibit
these.  
 
On a related topic should an empty range specification ("[]") be rejected as
well, since nothing could possibly match it.
 
--Stephen
 

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Wednesday, December 10, 2003 7:35 PM
To: Steve Cipolli; 'Troy Cauble'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)



All, 

Here is some proposed text for this.  I will include this in the IG.  Please
let me know any changes that would be better.  New text is demarcated by
>><<.

7.1.14.3        DigitMap Syntax 
... 
In addition to these event symbols, the string may contain "S" and "L"
inter-event timing specifiers and the "Z" duration modifier. "S" and "L"
respectively indicate that the MG should use the short (S) timer or the long
(L) timer for subsequent events, overriding the timing rules described
above. If an explicit timing specifier is in effect in one alternative event
sequence, but none is given in any other candidate alternative, the timer
value set by the explicit timing specifier must be used. If all sequences
with explicit timing controls are dropped from the candidate set, timing
reverts to the default rules given above. >>If used inside a range notation,
the S and L specifiers shall be ignored.<<  Finally, if conflicting timing
specifiers are in effect in different alternative sequences, the long timer
shall be used.

A "Z" designates a long duration event: placed in front of the symbol(s)
designating the event(s) which satisfy a given digit position, it indicates
that that position is satisfied only if the duration of the event exceeds
the long-duration threshold. The value of this threshold is assumed to be
provisioned in the MG.  >>If the Z specifier is not followed by a digit (0-9
or A-K), then the MG shall reject the digitmap as invalid protocol.  When
used in a range notation, the Z specifier applies solely to the immediately
following digit.<<

Kevin 
________________________________ 

        From: Steve Cipolli [mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
        Sent: Friday, December 05, 2003 1:09 PM 
        To: Boyle, Kevin [NCRTP:3Z40:EXCH]; 'Troy Cauble' 
        Cc: megaco@ietf.org 
        Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
Timers ( L), & Short T imers (S) 
        
        
        While I tend to agree with most of the answers below, I don't see
any of this specified in the specification.  If we can agree that the
answers below are the correct interpretation, then we still need
clarification in the spec or implementors guide.  I'm still hoping the
original author of this section of the spec will clarify the original
intention.

         
        --Stephen 

                -----Original Message----- 
                From: Kevin Boyle [mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> ] 
                Sent: Tuesday, December 02, 2003 3:18 PM 
                To: Steve Cipolli; 'Troy Cauble' 
                Cc: megaco@ietf.org 
                Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z),
Long Timers ( L), & Short T imers (S) 
                
                

                Comments inline. [KJBII] 

                Kevin 

                -----Original Message----- 
                From: Steve Cipolli [mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
                Sent: Tuesday, December 02, 2003 2:40 PM 
                To: 'Troy Cauble'; Boyle, Kevin [NCRTP:3Z40:EXCH] 
                Cc: megaco@ietf.org 
                Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z),
Long Timers ( L), & Short T imers (S) 

                Perhaps I moved us off track a bit.  It is clear that there
is more than one interpretation of the specification with regard to L, S,
and to a lesser extent Z.  Can the authors comment on what the intent of the
specification was and then perhaps we can reach some conclusion?

                Here is a partial list of odd digitmaps that seem to defy
interpretation: 
                        "123Z"                          - "Z" ignored or
error? 
                [KJBII] Z here has nothing to modify.  Error. 

                        "123S"                  - "S" (or "L") ignored or
error? 
                [KJBII] In this instance, the digitmap switches to short
interdigit timing after detecting "123".  So, neither. 

                        "1ZZ23"                 - First "Z" ignored or
error? 
                [KJBII] Because Z is defined as modifying the following
digit, and Z cannot modify Z, this should be an error. 

                        "1ZSSSSSSSSS23"         - "Z" applied to the "2" or
ignored or error? 
                [KJBII] See above.  Error as Z cannot modify S (or L). 

                        "135[2Z46]"                     - "Z" applied to "4"
or to all in the range (246) or ignored or error? 

                [KJBII] Z applies solely to the 4 here. 

                        "135[246Z]79"           - "Z" applied to "7" or
ignored or error? 
                [KJBII] Nothing for Z to modify.  Error. 

                        "135[2S46]"                     - "S" (or "L")
applied to all in range (246) or ignored or error? 

                [KJBII] This is the root of our earlier discussion.  L and S
do not modify digits -- they modify timing strategy for the digitmap at the
time they are encountered.  [246] means "match 2, 4 or 6".  So [2S46]
means... What exactly? "Match 2, short timeout, 4 or 6"?  Or "match 2, 4 or
6 while running the short timer for this digit only"?  Or "run the short
timer S after detecting 2, but not if 4 or 6 is detected"?  If the string
were "135S[246]" then we would start using the short timer before looking
for 2, 4 or 6.  If it were "135[246]S", we would start using the short timer
AFTER matching 2, 4 or 6.  But, with the S timer INSIDE the range, that
would indicate that the timer would have to fire to continue.  For instance,
if the string were "135[2S46]79", that would seem to indicate that if NO
digit was detected for the duration of the short timer, then we should
continue with the string to find 7.  This is a contrary usage to S and L at
any other point in a digitmap.  I think S and L should be ignored within
ranges.  If the MGC wants to use the S or L timer, then put them outside the
range.

                        "135[2L4S6]"            - "L" or "S" applied or both
(somehow?) or ignored or error? 
                [KJBII] See above -- the same arguments apply here.  I would
note that L would never get "detected" here, since S would match first.

                Thanks, 
                --Stephen 

                        

                > -----Original Message----- 
                > From: Steve Cipolli [mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
                > Sent: Monday, December 01, 2003 8:01 PM 
                > To: 'Troy Cauble'; Kevin Boyle 
                > Cc: megaco@ietf.org 
                > Subject: RE: [Megaco] Digit Maps: Long Duration
Modifier(Z), Long 
                > Timers ( L), & Short T imers (S) 
                > 
                > 
                > Part of the problem is the term "alternatives" is not
clear.  
                > The text in 
                > 7.1.14.3 says of "alternatives": 
                > A DigitMap, according to this syntax, is defined either by
a string or 
                > by a list of strings.  Each string in the list is an
alternative event 
                > sequence, specified either as a sequence of digit map
symbols or as a 
                > regular expression of digit map symbols. 
                > 
                > My reading of this is that "alternatives" are each string
and not the 
                > possible sequences through a range, but admittedly this is
not clear. 
                > 
                > The section doesn't seem to explain other odd sequences
like "123Z". 
                > Presumably the "Z" is simply ignored although an error
could also be 
                > considered the proper outcome. 
                > 
                > I must say I prefer an interpretation in which the number
of possible 
                > ways to perform the same action is as close to 1 and
possible. 
                > Therefore, I'd 
                > prefer to ban (or at least ignore) "L" and "S" within
ranges. 
                > 
                > --Stephen 
                > 
                > > -----Original Message----- 
                > > From: Troy Cauble [mailto:troy@bell-labs.com
<mailto:troy@bell-labs.com> ] 
                > > Sent: Monday, December 01, 2003 6:33 PM 
                > > To: Kevin Boyle 
                > > Cc: megaco@ietf.org 
                > > Subject: Re: [Megaco] Digit Maps: Long Duration
Modifier(Z), Long 
                > > Timers ( L), & Short T imers (S) 
                > > 
                > > 
                > > 
                > > 
                > > I disagree that "L" and "S" are meaningless within a
range. 
                > > 
                > > "L" and "S" are used to specify the timer used for
"subsequent 
                > > events". 
                > > 
                > > I would argue that the "5" is a subsequent event in
"[34L]5", just 
                > > as it is in "[34]L5". 
                > > 
                > > I would also argue that the "4" in "[3L4]5" is NOT a
"subsequent 
                > > event", although one might debate the definition of
"subsequent". 
                > > 
                > > In summary, I think "[L34]5", "[3L4]5", "[34L]5", and 
                > "[34]L5" are all 
                > > the same. (And the "L" is not meaningless.) 
                > > 
                > > 
                > > Note that section 7.1.14.3 does bother to specify what
happens when 
                > > explicit timing specifiers are only active in some
"alternatives", 
                > or when they 
                > > differ in among alternatives -- the same timer value is
used for all 
                > > alternatives. 
                > > 
                > > 
                > > 7.1.14.3: 
                > > 
                > >  > In addition to these event symbols, the string may
contain "S" 
                > > and "L" 
                > >  > inter-event timing specifiers and the "Z" duration
modifier. "S" 
                > > and "L" 
                > >  > respectively indicate that the MG should use the
short (S) timer 
                > > or the  > long (L) timer for subsequent events,
overriding the 
                > > timing rules  > described above. If an explicit timing
specifier is 
                > > in effect in one  > alternative event sequence, but none
is given in 
                > > any other candidate  > alternative, the timer value set
by the 
                > > explicit timing specifier must be  > used. If all
sequences with 
                > > explicit timing controls are dropped from the  >
candidate set, 
                > > timing reverts to the default rules given above.
Finally,  > if 
                > > conflicting timing specifiers are in effect in different
alternative  
                > > > sequences, the long timer shall be used. 
                > > 
                > > 
                > > -troy 
                > > 
                > > 
                > > 
                > > Kevin Boyle wrote: 
                > > 
                > > > Since a range means "match one of these", I would
agree 
                > > with the assessment 
                > > > that L and S are meaningless within a range. 
                > > >  
                > > > Kevin 
                > > > 
                > > > 
                > > >   _____ 
                > > > 
                > > > From: Steve Cipolli [mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
                > > > Sent: Monday, December 01, 2003 5:22 PM 
                > > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org 
                > > > Subject: RE: [Megaco] Digit Maps: Long Duration 
                > > Modifier(Z), Long Timers ( 
                > > > L), & Short T imers (S) 
                > > > 
                > > > 
                > > > Thanks for the feedback.  
                > > >  
                > > > Just to make sure I understand the L and S cases: 
                > > > They are syntactically legal in a range specification,
but 
                > > semantically they 
                > > > have no effect.  Correct? 
                > > >  
                > > > --Stephen 
                > > > 
                > > > -----Original Message----- 
                > > > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> ] 
                > > > Sent: Monday, December 01, 2003 5:15 PM 
                > > > To: Steve Cipolli; megaco@ietf.org 
                > > > Subject: RE: [Megaco] Digit Maps: Long Duration 
                > > Modifier(Z), Long Timers ( 
                > > > L), & Short T imers (S) 
                > > > 
                > > > 
                > > > Your interpretation is correct.  Because Z changes how
a 
                > > digit is matched, 
                > > > it makes sense within a range.  Think of Z as part of
the 
                > > digit it modifies, 
                > > > rather than a separate symbol. 
                > > >  
                > > > The L and S timers within a digitmap give specific 
                > > instruction as to which 
                > > > timer to run at that point in the digitmap.  While
allowed 
                > > in a range, I 
                > > > don't think they provide much value within a range
since 
                > they do not 
                > > > actually match anything.  For effective use, they
should be 
                > > outside the 
                > > > range. 
                > > >  
                > > > Kevin 
                > > > 
                > > > 
                > > >   _____ 
                > > > 
                > > > From: Steve Cipolli [mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
                > > > Sent: Monday, December 01, 2003 3:26 PM 
                > > > To: megaco@ietf.org 
                > > > Subject: [Megaco] Digit Maps: Long Duration
Modifier(Z), 
                > > Long Timers (L), & 
                > > > Short T imers (S) 
                > > > 
                > > > 
                > > >  
                > > > According to the syntax in RFCs 3015 & 3525 the long 
                > > duration modifier (Z), 
                > > > Long Timers (L), & Short Timers (S) in digit maps can 
                > > appear in a digit 
                > > > range.  For example (where Z is 1000ms): 
                > > >     "135[2Z46]" 
                > > >  
                > > > Is this valid?  If it is valid, does this mean that
the 
                > > fourth digit event 
                > > > must be either 2, 6 (held for any duration) or 4 held
for 1000 ms? 
                > > >  
                > > > How does long timer (L) and short timer (S) in a digit

                > range apply? 
                > > >  
                > > > --Stephen 
                > > >  
                > > >  
                > > > 
                > > > 
                > > > _______________________________________________ 
                > > > Megaco mailing list 
                > > > Megaco@ietf.org 
                > > > https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  
                > > 
                > > 
                > > 
                > > _______________________________________________ 
                > > Megaco mailing list 
                > > Megaco@ietf.org 
                > > https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  
                > > 
                > 
                > 
                > _______________________________________________ 
                > Megaco mailing list 
                > Megaco@ietf.org 
                > https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  
                > 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan  2 10:25:31 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12757
	for <megaco-archive@lists.ietf.org>; Fri, 2 Jan 2004 10:25:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcRAc-00040d-Le; Fri, 02 Jan 2004 10:25:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcR9y-0003yv-10
	for megaco@optimus.ietf.org; Fri, 02 Jan 2004 10:24:22 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12732
	for <megaco@ietf.org>; Fri, 2 Jan 2004 10:24:17 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcR9v-0005Ph-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:24:19 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcR8A-0005Le-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:22:33 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcR6P-0005De-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:20:41 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i02FK0504922
	for <megaco@ietf.org>; Fri, 2 Jan 2004 10:20:00 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y10G6D>; Fri, 2 Jan 2004 10:20:01 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D7AF882@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: "Tom-PT Taylor" <taylor@nortelnetworks.com>, gsachin@hss.hns.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Query Related to Automatic Metering
Date: Fri, 2 Jan 2004 10:19:55 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Do we need an IG item?  I can add one for the upcoming meeting, if we
believe that this should be fixed.

I would rather not have use of KA mandated.  Let the implementor decide how
the event should interact with any signals.

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH] 
Sent: Monday, December 22, 2003 11:53 AM
To: gsachin@hss.hns.com
Cc: megaco@ietf.org
Subject: Re: [Megaco] Query Related to Automatic Metering

I think you make a good point.  It's desirable to keep the protocol intact,
rather than define exceptions within individual packages.

gsachin@hss.hns.com wrote:

> 
> 
> 
> Hi List,
> 
> 
> this is a query regarding Periodic report event 'pr' defined in AMET 
> package .the package procedure says that
> 
> "the detection of event pr shall not cause the termination of the 
> signal em or signal mbp, even if the KeppActive(KA) flag is not set 
> for the pr event"
> 
> what i feel is that the detection of the 'pr' event shall not cause 
> the termination of any of the signals.
> 
> pls tell me if this is a correct assumption?
> 
> if yes, then i think here the package procedures should have mandated 
> the use of KA flag with this event. Doing this will keep the protocol 
> rules intact.
> 
> 
> 
> Regards
> Sachin Gupta
> 
> "DISCLAIMER: This message is proprietary to Hughes Software Systems 
> Limited
> (HSS) and is intended solely for the use of the individual to whom it 
> is addressed. It may contain  privileged or confidential information 
> and should not be circulated or used for any purpose other than for 
> what it is intended. If you have received this message in error, 
> please notify the originator immediately. If you are not the intended 
> recipient, you are notified that you are strictly prohibited from 
> using, copying, altering, or disclosing the contents of this message. 
> HSS accepts no responsibility for loss or damage arising from the use 
> of the information transmitted by this email including damage from virus."
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan  2 10:29:15 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12842
	for <megaco-archive@odin.ietf.org>; Fri, 2 Jan 2004 10:29:15 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcREH-00049X-Ci
	for megaco-archive@odin.ietf.org; Fri, 02 Jan 2004 10:28:49 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i02FSnPE015962
	for megaco-archive@odin.ietf.org; Fri, 2 Jan 2004 10:28:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcREF-00049N-RN
	for megaco-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 10:28:49 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12837
	for <megaco-web-archive@ietf.org>; Fri, 2 Jan 2004 10:28:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcRED-0005ZQ-00
	for megaco-web-archive@ietf.org; Fri, 02 Jan 2004 10:28:45 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcRCB-0005VD-00
	for megaco-web-archive@ietf.org; Fri, 02 Jan 2004 10:26:42 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcRAd-0005R4-00
	for megaco-web-archive@ietf.org; Fri, 02 Jan 2004 10:25:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcRAc-00040d-Le; Fri, 02 Jan 2004 10:25:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcR9y-0003yv-10
	for megaco@optimus.ietf.org; Fri, 02 Jan 2004 10:24:22 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12732
	for <megaco@ietf.org>; Fri, 2 Jan 2004 10:24:17 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcR9v-0005Ph-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:24:19 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcR8A-0005Le-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:22:33 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcR6P-0005De-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:20:41 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i02FK0504922
	for <megaco@ietf.org>; Fri, 2 Jan 2004 10:20:00 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y10G6D>; Fri, 2 Jan 2004 10:20:01 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D7AF882@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: "Tom-PT Taylor" <taylor@nortelnetworks.com>, gsachin@hss.hns.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Query Related to Automatic Metering
Date: Fri, 2 Jan 2004 10:19:55 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Do we need an IG item?  I can add one for the upcoming meeting, if we
believe that this should be fixed.

I would rather not have use of KA mandated.  Let the implementor decide how
the event should interact with any signals.

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH] 
Sent: Monday, December 22, 2003 11:53 AM
To: gsachin@hss.hns.com
Cc: megaco@ietf.org
Subject: Re: [Megaco] Query Related to Automatic Metering

I think you make a good point.  It's desirable to keep the protocol intact,
rather than define exceptions within individual packages.

gsachin@hss.hns.com wrote:

> 
> 
> 
> Hi List,
> 
> 
> this is a query regarding Periodic report event 'pr' defined in AMET 
> package .the package procedure says that
> 
> "the detection of event pr shall not cause the termination of the 
> signal em or signal mbp, even if the KeppActive(KA) flag is not set 
> for the pr event"
> 
> what i feel is that the detection of the 'pr' event shall not cause 
> the termination of any of the signals.
> 
> pls tell me if this is a correct assumption?
> 
> if yes, then i think here the package procedures should have mandated 
> the use of KA flag with this event. Doing this will keep the protocol 
> rules intact.
> 
> 
> 
> Regards
> Sachin Gupta
> 
> "DISCLAIMER: This message is proprietary to Hughes Software Systems 
> Limited
> (HSS) and is intended solely for the use of the individual to whom it 
> is addressed. It may contain  privileged or confidential information 
> and should not be circulated or used for any purpose other than for 
> what it is intended. If you have received this message in error, 
> please notify the originator immediately. If you are not the intended 
> recipient, you are notified that you are strictly prohibited from 
> using, copying, altering, or disclosing the contents of this message. 
> HSS accepts no responsibility for loss or damage arising from the use 
> of the information transmitted by this email including damage from virus."
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan  2 10:43:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13346
	for <megaco-archive@lists.ietf.org>; Fri, 2 Jan 2004 10:43:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcRS1-0004jk-NN; Fri, 02 Jan 2004 10:43:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcJd6-0003uX-9C
	for megaco@optimus.ietf.org; Fri, 02 Jan 2004 02:21:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20717
	for <megaco@ietf.org>; Fri, 2 Jan 2004 02:21:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcJd2-0000XU-00
	for megaco@ietf.org; Fri, 02 Jan 2004 02:21:52 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcJbB-0000Te-00
	for megaco@ietf.org; Fri, 02 Jan 2004 02:20:00 -0500
Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcJZI-0000P3-00
	for megaco@ietf.org; Fri, 02 Jan 2004 02:18:06 -0500
Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38])
	by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id i027BRuY016909
	for <megaco@ietf.org>; Fri, 2 Jan 2004 15:11:34 +0800 (CST)
Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Fri Jan 02 15:19:36 2004 +0800
Received: from bellnet-mail1.sbell.com.cn ([172.24.208.21]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 2 Jan 2004 15:19:35 +0800
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-7"
Content-Transfer-Encoding: 7bit
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Fri, 2 Jan 2004 15:19:35 +0800
Message-ID: <C2DB7F5BC458EA4C8EB46B7A4EFF7E76C681C9@bellnet-mail1.sbell.com.cn>
Thread-Topic: a question about fax pass through
Thread-Index: AcPRAMUZCptqvllKRSiM2QDq5QJaQA+AD0APQ-
From: "FND-V Wang JuLin" <JuLin.Wang@alcatel-sbell.com.cn>
To: <megaco@ietf.org>
Cc: "Albrecht Schwarz" <Albrecht.Schwarz@alcatel.de>,
        "Gunter Weiss" <G.Weiss@alcatel.de>
X-OriginalArrivalTime: 02 Jan 2004 07:19:35.0513 (UTC) FILETIME=[C663A490:01C3D100]
Content-Transfer-Encoding: 7bit
Subject: [Megaco] a question about fax pass through
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hello,List,
Is there any signalling way for MGC indicate the gateway to transfer fax packet with pass through mode?
Can we  use the following SDP to implement it?
MGC to MG:
MEGACO/1.0 +AFs-123.123.123.4+AF0-:55555
Transaction +AD0- 14 +AHs-
 Context +AD0- 2000 +AHs-
  Modify +AD0- RTP/1 +AHs-
   Media +AHs- 
    Stream +AD0- 1 +AHs- 
     Local +AHs-
v+AD0-0
c+AD0-IN IP4 124.124.124.222
m+AD0-image 1110 RTP/AVP 0 //please pay attention to this line.
.....
     +AH0-   
    +AH0-         
   +AH0-
  +AH0-  
 +AH0-
+AH0-

    

 best  regards
+AD4- :-)Jerry Wang
tel:(8621)58541240 ext 9531
MP:13621761050
mailto:Julin.Wang+AEA-alcatel-sbell.com.cn 
Alcatel Shanghai Bell Co.LTD


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan  2 10:47:11 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13435
	for <megaco-archive@odin.ietf.org>; Fri, 2 Jan 2004 10:47:11 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcRVc-0004tU-Sd
	for megaco-archive@odin.ietf.org; Fri, 02 Jan 2004 10:46:45 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i02Fkir6018806
	for megaco-archive@odin.ietf.org; Fri, 2 Jan 2004 10:46:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcRVc-0004tF-OS
	for megaco-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 10:46:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13421
	for <megaco-web-archive@ietf.org>; Fri, 2 Jan 2004 10:46:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcRVa-0006Dh-00
	for megaco-web-archive@ietf.org; Fri, 02 Jan 2004 10:46:42 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcRTl-00068k-00
	for megaco-web-archive@ietf.org; Fri, 02 Jan 2004 10:44:52 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcRS1-00064O-00
	for megaco-web-archive@ietf.org; Fri, 02 Jan 2004 10:43:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcRS1-0004jk-NN; Fri, 02 Jan 2004 10:43:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcJd6-0003uX-9C
	for megaco@optimus.ietf.org; Fri, 02 Jan 2004 02:21:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20717
	for <megaco@ietf.org>; Fri, 2 Jan 2004 02:21:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcJd2-0000XU-00
	for megaco@ietf.org; Fri, 02 Jan 2004 02:21:52 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcJbB-0000Te-00
	for megaco@ietf.org; Fri, 02 Jan 2004 02:20:00 -0500
Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcJZI-0000P3-00
	for megaco@ietf.org; Fri, 02 Jan 2004 02:18:06 -0500
Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38])
	by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id i027BRuY016909
	for <megaco@ietf.org>; Fri, 2 Jan 2004 15:11:34 +0800 (CST)
Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Fri Jan 02 15:19:36 2004 +0800
Received: from bellnet-mail1.sbell.com.cn ([172.24.208.21]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 2 Jan 2004 15:19:35 +0800
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-7"
Content-Transfer-Encoding: 7bit
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Fri, 2 Jan 2004 15:19:35 +0800
Message-ID: <C2DB7F5BC458EA4C8EB46B7A4EFF7E76C681C9@bellnet-mail1.sbell.com.cn>
Thread-Topic: a question about fax pass through
Thread-Index: AcPRAMUZCptqvllKRSiM2QDq5QJaQA+AD0APQ-
From: "FND-V Wang JuLin" <JuLin.Wang@alcatel-sbell.com.cn>
To: <megaco@ietf.org>
Cc: "Albrecht Schwarz" <Albrecht.Schwarz@alcatel.de>,
        "Gunter Weiss" <G.Weiss@alcatel.de>
X-OriginalArrivalTime: 02 Jan 2004 07:19:35.0513 (UTC) FILETIME=[C663A490:01C3D100]
Content-Transfer-Encoding: 7bit
Subject: [Megaco] a question about fax pass through
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello,List,
Is there any signalling way for MGC indicate the gateway to transfer fax packet with pass through mode?
Can we  use the following SDP to implement it?
MGC to MG:
MEGACO/1.0 +AFs-123.123.123.4+AF0-:55555
Transaction +AD0- 14 +AHs-
 Context +AD0- 2000 +AHs-
  Modify +AD0- RTP/1 +AHs-
   Media +AHs- 
    Stream +AD0- 1 +AHs- 
     Local +AHs-
v+AD0-0
c+AD0-IN IP4 124.124.124.222
m+AD0-image 1110 RTP/AVP 0 //please pay attention to this line.
.....
     +AH0-   
    +AH0-         
   +AH0-
  +AH0-  
 +AH0-
+AH0-

    

 best  regards
+AD4- :-)Jerry Wang
tel:(8621)58541240 ext 9531
MP:13621761050
mailto:Julin.Wang+AEA-alcatel-sbell.com.cn 
Alcatel Shanghai Bell Co.LTD


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan  2 10:49:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13512
	for <megaco-archive@lists.ietf.org>; Fri, 2 Jan 2004 10:49:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcRXp-0004xE-PG; Fri, 02 Jan 2004 10:49:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcRXf-0004wt-30
	for megaco@optimus.ietf.org; Fri, 02 Jan 2004 10:48:51 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13487
	for <megaco@ietf.org>; Fri, 2 Jan 2004 10:48:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcRXc-0006JJ-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:48:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcRVP-0006D3-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:46:34 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcRTb-00066i-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:44:39 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i02Fi8m06830
	for <megaco@ietf.org>; Fri, 2 Jan 2004 10:44:08 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y10HKY>; Fri, 2 Jan 2004 10:44:08 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D7AF8BF@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: "Tom-PT Taylor" <taylor@nortelnetworks.com>, megaco@ietf.org
Subject: RE: [Megaco] Add and CHOOSE
Date: Fri, 2 Jan 2004 10:44:02 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

I will add an IG item for this, since I have heard nothing to the contrary.

If anyone objects to Tom's wording, speak now!

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH] 
Sent: Friday, December 19, 2003 7:58 AM
To: megaco@ietf.org
Subject: [Megaco] Add and CHOOSE

Denis Osadchy has spotted an inaccuracy in section 7.2.1 as it relates to
wildcarding of terminationIDs.

-------- Original Message --------
Subject: Re[2]:
Date: Fri, 19 Dec 2003 12:09:52 +0600
From: äÅÎÉÓ ïÓÁÄÞÉÊ <osadchy@itsib.ru>
Reply-To: äÅÎÉÓ ïÓÁÄÞÉÊ <osadchy@itsib.ru>
To: Taylor, Tom-PT [CAR:5N00:EXCH]<taylor@americasm01.nt.com>
References: <88625468765.20031218165025@itsib.ru>
<3FE1BED4.1080508@nortelnetworks.com>

Hello Tom,
I'm fully agree. It will be more clearly.

Thursday, December 18, 2003 tou wrote:

TT> You are right that there is a contradiction.  However, I would
suggest a
TT> different way to fix the paragraph.

TT> Let me suggest a situation you might want to think about, and one
that I
TT> think is quite realistic: that you want the MG to choose a 
TT> particular circuit from a group, where the terminationID consists of 
TT> the circuit group name concatenated with the individual circuit name or
number.
TT> Then what the Add command would have is a partially specified 
TT> terminationID with the choose wildcard replacing the circuit
name/number
TT> portion.

TT> If you agree with this possible application, the paragraph should 
TT> instead be fixed by changing the sentence to read:

TT> "For an existing termination, the TerminationID SHALL be specific or 
TT> partially specified."

TT> Again, if you agree, we should forward this exchange of notes to the 
TT> Megaco list.

TT> äÅÎÉÓ ïÓÁÄÞÉÊ wrote:

>> Hello, I have question: by protocol
>> 
>> " 7.2.1   Add ... The TerminationID specifies the termination to be
>>  added to the Context.  The Termination is either created, or taken  
>> from the null Context.  For an existing Termination, the 
>> TerminationID would be specific. For a Termination that does not yet 
>> exist, the TerminationID is specified as CHOOSE  in the command. ... 
>> "
>> 
>> If terminationID is CHOOSE then it's request to add ephemeral 
>> termination? If i'm right then in this text we shall use SHALL (not  
>> would)? "For an existing Termination, the TerminationID would be 
>> specific."
>> 
>> 
>> Denis
>> 
>> 
>> 
>> 



÷ÓÅÇÏ ÎÁÉÌÕÞÛÅÇÏ,
äÅÎÉÓ ïÓÁÄÞÉÊ                          mailto:osadchy@itsib.ru





_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan  2 10:52:54 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13687
	for <megaco-archive@odin.ietf.org>; Fri, 2 Jan 2004 10:52:54 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcRb9-000570-Tm
	for megaco-archive@odin.ietf.org; Fri, 02 Jan 2004 10:52:28 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i02FqRDj019643
	for megaco-archive@odin.ietf.org; Fri, 2 Jan 2004 10:52:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcRb9-00056k-KF
	for megaco-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 10:52:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13658
	for <megaco-web-archive@ietf.org>; Fri, 2 Jan 2004 10:52:23 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcRb7-0006Vo-00
	for megaco-web-archive@ietf.org; Fri, 02 Jan 2004 10:52:25 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcRZH-0006QN-00
	for megaco-web-archive@ietf.org; Fri, 02 Jan 2004 10:50:34 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcRXq-0006K7-00
	for megaco-web-archive@ietf.org; Fri, 02 Jan 2004 10:49:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcRXp-0004xE-PG; Fri, 02 Jan 2004 10:49:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcRXf-0004wt-30
	for megaco@optimus.ietf.org; Fri, 02 Jan 2004 10:48:51 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13487
	for <megaco@ietf.org>; Fri, 2 Jan 2004 10:48:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcRXc-0006JJ-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:48:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcRVP-0006D3-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:46:34 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcRTb-00066i-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:44:39 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i02Fi8m06830
	for <megaco@ietf.org>; Fri, 2 Jan 2004 10:44:08 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y10HKY>; Fri, 2 Jan 2004 10:44:08 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D7AF8BF@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: "Tom-PT Taylor" <taylor@nortelnetworks.com>, megaco@ietf.org
Subject: RE: [Megaco] Add and CHOOSE
Date: Fri, 2 Jan 2004 10:44:02 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

I will add an IG item for this, since I have heard nothing to the contrary.

If anyone objects to Tom's wording, speak now!

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH] 
Sent: Friday, December 19, 2003 7:58 AM
To: megaco@ietf.org
Subject: [Megaco] Add and CHOOSE

Denis Osadchy has spotted an inaccuracy in section 7.2.1 as it relates to
wildcarding of terminationIDs.

-------- Original Message --------
Subject: Re[2]:
Date: Fri, 19 Dec 2003 12:09:52 +0600
From: äÅÎÉÓ ïÓÁÄÞÉÊ <osadchy@itsib.ru>
Reply-To: äÅÎÉÓ ïÓÁÄÞÉÊ <osadchy@itsib.ru>
To: Taylor, Tom-PT [CAR:5N00:EXCH]<taylor@americasm01.nt.com>
References: <88625468765.20031218165025@itsib.ru>
<3FE1BED4.1080508@nortelnetworks.com>

Hello Tom,
I'm fully agree. It will be more clearly.

Thursday, December 18, 2003 tou wrote:

TT> You are right that there is a contradiction.  However, I would
suggest a
TT> different way to fix the paragraph.

TT> Let me suggest a situation you might want to think about, and one
that I
TT> think is quite realistic: that you want the MG to choose a 
TT> particular circuit from a group, where the terminationID consists of 
TT> the circuit group name concatenated with the individual circuit name or
number.
TT> Then what the Add command would have is a partially specified 
TT> terminationID with the choose wildcard replacing the circuit
name/number
TT> portion.

TT> If you agree with this possible application, the paragraph should 
TT> instead be fixed by changing the sentence to read:

TT> "For an existing termination, the TerminationID SHALL be specific or 
TT> partially specified."

TT> Again, if you agree, we should forward this exchange of notes to the 
TT> Megaco list.

TT> äÅÎÉÓ ïÓÁÄÞÉÊ wrote:

>> Hello, I have question: by protocol
>> 
>> " 7.2.1   Add ... The TerminationID specifies the termination to be
>>  added to the Context.  The Termination is either created, or taken  
>> from the null Context.  For an existing Termination, the 
>> TerminationID would be specific. For a Termination that does not yet 
>> exist, the TerminationID is specified as CHOOSE  in the command. ... 
>> "
>> 
>> If terminationID is CHOOSE then it's request to add ephemeral 
>> termination? If i'm right then in this text we shall use SHALL (not  
>> would)? "For an existing Termination, the TerminationID would be 
>> specific."
>> 
>> 
>> Denis
>> 
>> 
>> 
>> 



÷ÓÅÇÏ ÎÁÉÌÕÞÛÅÇÏ,
äÅÎÉÓ ïÓÁÄÞÉÊ                          mailto:osadchy@itsib.ru





_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan  2 10:54:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11257
	for <megaco-archive@lists.ietf.org>; Fri, 2 Jan 2004 10:05:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcQrG-0003Ei-Dz; Fri, 02 Jan 2004 10:05:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcQqP-0003Dq-VP
	for megaco@optimus.ietf.org; Fri, 02 Jan 2004 10:04:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11096
	for <megaco@ietf.org>; Fri, 2 Jan 2004 10:03:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcQq8-0004cO-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:03:52 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcQmu-0004Ze-00
	for megaco@ietf.org; Fri, 02 Jan 2004 10:00:35 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcQlI-0004W4-00
	for megaco@ietf.org; Fri, 02 Jan 2004 09:58:52 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i02EwKk01466
	for <megaco@ietf.org>; Fri, 2 Jan 2004 09:58:20 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y10GPV>; Fri, 2 Jan 2004 09:58:21 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D7AF822@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: gsachin@hss.hns.com, megaco@ietf.org
Subject: RE: [Megaco] ICAS Package 'Call Duration' statistics
Date: Fri, 2 Jan 2004 09:58:12 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: gsachin@hss.hns.com [mailto:gsachin@hss.hns.com] 
Sent: Saturday, December 20, 2003 4:51 AM
To: megaco@ietf.org
Subject: [Megaco] ICAS Package 'Call Duration' statistics





hi List,

the 'Call Duration' statistics in the ICAS package is described as

***
6.4.1 Call Duration
StatisticID: cd (0x0001)
Description: Provides the cumulative duration the termination is in active
call context i.e. from the point of applying/receiving "Answered"
signal till the point of release ("Clear-forward" or "Clear-back")
initiation.
***

Can somebody pls specify what 'active call context' refers to?
[KJBII] The text describes exactly what it means: from the point of
applying/receiving "Answered" signal till the point of release
("Clear-forward" or "Clear-back") initiation.

Should this be related to the stream mode property also?
[KJBII] No.  The text describes exactly what it should be.


Also the NT package define 'duration' statistics. the description is as
follows

***
        Description: Provides duration of time the termination has been
        in the context.
***

How does both these statistics differ. A termination can support both these
statistics.
[KJBII] Again, the text describes exactly what the statistic is.  Duration
in the nt package is the length of time the termination has been in a
context.  The two stats are different.  Indeed, both packages can be
supported by the same termination.  Since they are different measurements, I
don't see a problem.


regards
Sachin Gupta

"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain  privileged or confidential information and should
not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From megaco-admin@ietf.org  Sat Jan  3 01:31:32 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09000
	for <megaco-archive@lists.ietf.org>; Sat, 3 Jan 2004 01:31:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcfJN-0005P4-Pv; Sat, 03 Jan 2004 01:31:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcfIf-0005Ni-4q
	for megaco@optimus.ietf.org; Sat, 03 Jan 2004 01:30:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08972
	for <megaco@ietf.org>; Sat, 3 Jan 2004 01:30:15 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcfIc-0003Xg-00
	for megaco@ietf.org; Sat, 03 Jan 2004 01:30:14 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcfGf-0003UM-00
	for megaco@ietf.org; Sat, 03 Jan 2004 01:28:14 -0500
Received: from [202.41.97.50] (helo=u1.doe.ernet.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcfEi-0003PZ-00
	for megaco@ietf.org; Sat, 03 Jan 2004 01:26:12 -0500
Received: from uucp-relay-delhi.ernet.in (uucp-relay-delhi.ernet.in [202.41.97.134])
	by u1.doe.ernet.in (8.12.8/8.12.8) with ESMTP id i036Hwtu017272;
	Sat, 3 Jan 2004 11:48:14 +0530
Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0)
	id MAA15287; Sat, 3 Jan 2004 12:04:58 -0500 (GMT)
>Received: from cancer.cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4)
	id LAA22464; Sat, 3 Jan 2004 11:56:13 -0500
Message-ID: <3FF65E47.2E91A4BA@cdotd.ernet.in>
Date: Sat, 03 Jan 2004 11:46:39 +0530
From: manish rathi <rathi@cdotd.ernet.in>
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.11.00 9000/785)
X-Accept-Language: en
MIME-Version: 1.0
To: FND-V Wang JuLin <JuLin.Wang@alcatel-sbell.com.cn>
CC: megaco@ietf.org, Albrecht Schwarz <Albrecht.Schwarz@alcatel.de>,
        Gunter Weiss <G.Weiss@alcatel.de>
Subject: Re: [Megaco] a question about fax pass through
References: <C2DB7F5BC458EA4C8EB46B7A4EFF7E76C681C9@bellnet-mail1.sbell.com.cn>
Content-Transfer-Encoding: 7bit
Received: from cdotd by vikram.eis.ernet.in; Sat,  3 Jan 2004 12:04 GMT
Content-Type: text/plain; charset=us-ascii
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MSGID_FROM_MTA_HEADER 
	autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

hi,
Is there any changes required in Megaco for mobile switch?

Manish



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Sat Jan  3 01:34:54 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09116
	for <megaco-archive@odin.ietf.org>; Sat, 3 Jan 2004 01:34:54 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcfMd-0005YE-CP
	for megaco-archive@odin.ietf.org; Sat, 03 Jan 2004 01:34:25 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i036YNt7021332
	for megaco-archive@odin.ietf.org; Sat, 3 Jan 2004 01:34:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcfMd-0005Xz-7O
	for megaco-web-archive@optimus.ietf.org; Sat, 03 Jan 2004 01:34:23 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09105
	for <megaco-web-archive@ietf.org>; Sat, 3 Jan 2004 01:34:21 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcfMa-0003id-00
	for megaco-web-archive@ietf.org; Sat, 03 Jan 2004 01:34:20 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcfKl-0003ef-00
	for megaco-web-archive@ietf.org; Sat, 03 Jan 2004 01:32:28 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcfJN-0003aC-00
	for megaco-web-archive@ietf.org; Sat, 03 Jan 2004 01:31:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcfJN-0005P4-Pv; Sat, 03 Jan 2004 01:31:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcfIf-0005Ni-4q
	for megaco@optimus.ietf.org; Sat, 03 Jan 2004 01:30:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08972
	for <megaco@ietf.org>; Sat, 3 Jan 2004 01:30:15 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcfIc-0003Xg-00
	for megaco@ietf.org; Sat, 03 Jan 2004 01:30:14 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcfGf-0003UM-00
	for megaco@ietf.org; Sat, 03 Jan 2004 01:28:14 -0500
Received: from [202.41.97.50] (helo=u1.doe.ernet.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcfEi-0003PZ-00
	for megaco@ietf.org; Sat, 03 Jan 2004 01:26:12 -0500
Received: from uucp-relay-delhi.ernet.in (uucp-relay-delhi.ernet.in [202.41.97.134])
	by u1.doe.ernet.in (8.12.8/8.12.8) with ESMTP id i036Hwtu017272;
	Sat, 3 Jan 2004 11:48:14 +0530
Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0)
	id MAA15287; Sat, 3 Jan 2004 12:04:58 -0500 (GMT)
>Received: from cancer.cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4)
	id LAA22464; Sat, 3 Jan 2004 11:56:13 -0500
Message-ID: <3FF65E47.2E91A4BA@cdotd.ernet.in>
Date: Sat, 03 Jan 2004 11:46:39 +0530
From: manish rathi <rathi@cdotd.ernet.in>
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.11.00 9000/785)
X-Accept-Language: en
MIME-Version: 1.0
To: FND-V Wang JuLin <JuLin.Wang@alcatel-sbell.com.cn>
CC: megaco@ietf.org, Albrecht Schwarz <Albrecht.Schwarz@alcatel.de>,
        Gunter Weiss <G.Weiss@alcatel.de>
Subject: Re: [Megaco] a question about fax pass through
References: <C2DB7F5BC458EA4C8EB46B7A4EFF7E76C681C9@bellnet-mail1.sbell.com.cn>
Content-Transfer-Encoding: 7bit
Received: from cdotd by vikram.eis.ernet.in; Sat,  3 Jan 2004 12:04 GMT
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MSGID_FROM_MTA_HEADER 
	autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

hi,
Is there any changes required in Megaco for mobile switch?

Manish



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Sat Jan  3 17:41:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15022
	for <megaco-archive@lists.ietf.org>; Sat, 3 Jan 2004 17:41:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcuS5-000246-8c; Sat, 03 Jan 2004 17:41:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcuRo-00023d-SB
	for megaco@optimus.ietf.org; Sat, 03 Jan 2004 17:40:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15005
	for <megaco@ietf.org>; Sat, 3 Jan 2004 17:40:41 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcuRm-0005sp-00
	for megaco@ietf.org; Sat, 03 Jan 2004 17:40:42 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcuPr-0005oh-00
	for megaco@ietf.org; Sat, 03 Jan 2004 17:38:44 -0500
Received: from cisc01.iskratel.si ([193.2.48.125])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcuOD-0005h5-00
	for megaco@ietf.org; Sat, 03 Jan 2004 17:37:01 -0500
Received: from ntmailkr.iskratel.si (ntmailkr.iskratel.si [10.1.2.90])
	by cisc01.iskratel.si (8.12.10/8.12.10) with ESMTP id i03MaBUi003110
	for <megaco@ietf.org>; Sat, 3 Jan 2004 23:36:11 +0100 (MET)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Sat, 3 Jan 2004 23:36:30 +0100
Message-ID: <57D0409C9DC47A4B936406AC1788FA00BB07AF@ntmailkr.iskratel.si>
Thread-Topic: Configuring generic parameter for MG
Thread-Index: AcPSRrAyqMORDn4ESeKoC9EnXsSHCQAAzI/A
From: "Aljaz Tomaz    ITWEG" <aljaz@iskratel.si>
To: <megaco@ietf.org>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Subject: [Megaco] Configuring generic parameter for MG
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

> Hi,
> I'm relative new to MEGACO protocol and also I haven't found exactly =
the right answer to my issue. I would like to configure parameters on =
Media gateway (MG) that are valid for all MG (not stream specific).
>=20
> Can anyone help me with that?
>=20
> Best regards,=20
> Tomaz

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Sat Jan  3 17:45:07 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15125
	for <megaco-archive@odin.ietf.org>; Sat, 3 Jan 2004 17:45:07 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcuVY-0002Bx-6Z
	for megaco-archive@odin.ietf.org; Sat, 03 Jan 2004 17:44:40 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i03MiaLt008421
	for megaco-archive@odin.ietf.org; Sat, 3 Jan 2004 17:44:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcuVY-0002Bi-0E
	for megaco-web-archive@optimus.ietf.org; Sat, 03 Jan 2004 17:44:36 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15115
	for <megaco-web-archive@ietf.org>; Sat, 3 Jan 2004 17:44:32 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcuVV-000601-00
	for megaco-web-archive@ietf.org; Sat, 03 Jan 2004 17:44:33 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcuTf-0005xO-00
	for megaco-web-archive@ietf.org; Sat, 03 Jan 2004 17:42:39 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcuS5-0005u0-00
	for megaco-web-archive@ietf.org; Sat, 03 Jan 2004 17:41:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcuS5-000246-8c; Sat, 03 Jan 2004 17:41:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcuRo-00023d-SB
	for megaco@optimus.ietf.org; Sat, 03 Jan 2004 17:40:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15005
	for <megaco@ietf.org>; Sat, 3 Jan 2004 17:40:41 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcuRm-0005sp-00
	for megaco@ietf.org; Sat, 03 Jan 2004 17:40:42 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcuPr-0005oh-00
	for megaco@ietf.org; Sat, 03 Jan 2004 17:38:44 -0500
Received: from cisc01.iskratel.si ([193.2.48.125])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcuOD-0005h5-00
	for megaco@ietf.org; Sat, 03 Jan 2004 17:37:01 -0500
Received: from ntmailkr.iskratel.si (ntmailkr.iskratel.si [10.1.2.90])
	by cisc01.iskratel.si (8.12.10/8.12.10) with ESMTP id i03MaBUi003110
	for <megaco@ietf.org>; Sat, 3 Jan 2004 23:36:11 +0100 (MET)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Sat, 3 Jan 2004 23:36:30 +0100
Message-ID: <57D0409C9DC47A4B936406AC1788FA00BB07AF@ntmailkr.iskratel.si>
Thread-Topic: Configuring generic parameter for MG
Thread-Index: AcPSRrAyqMORDn4ESeKoC9EnXsSHCQAAzI/A
From: "Aljaz Tomaz    ITWEG" <aljaz@iskratel.si>
To: <megaco@ietf.org>
Content-Transfer-Encoding: quoted-printable
Subject: [Megaco] Configuring generic parameter for MG
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

> Hi,
> I'm relative new to MEGACO protocol and also I haven't found exactly =
the right answer to my issue. I would like to configure parameters on =
Media gateway (MG) that are valid for all MG (not stream specific).
>=20
> Can anyone help me with that?
>=20
> Best regards,=20
> Tomaz

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Sat Jan  3 18:51:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18095
	for <megaco-archive@lists.ietf.org>; Sat, 3 Jan 2004 18:51:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcvXq-000453-AX; Sat, 03 Jan 2004 18:51:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Acu4W-0001BG-W7
	for megaco@optimus.ietf.org; Sat, 03 Jan 2004 17:16:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14423
	for <megaco@ietf.org>; Sat, 3 Jan 2004 17:16:37 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Acu4U-0004oq-00
	for megaco@ietf.org; Sat, 03 Jan 2004 17:16:38 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Acu2i-0004kw-00
	for megaco@ietf.org; Sat, 03 Jan 2004 17:14:48 -0500
Received: from cisc01.iskratel.si ([193.2.48.125])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Acu1A-0004eh-00
	for megaco@ietf.org; Sat, 03 Jan 2004 17:13:12 -0500
Received: from ntmailkr.iskratel.si (ntmailkr.iskratel.si [10.1.2.90])
	by cisc01.iskratel.si (8.12.10/8.12.10) with ESMTP id i03MCFUi001978
	for <megaco@ietf.org>; Sat, 3 Jan 2004 23:12:15 +0100 (MET)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Sat, 3 Jan 2004 23:12:34 +0100
Message-ID: <57D0409C9DC47A4B936406AC1788FA001E9BE2@ntmailkr.iskratel.si>
Thread-Topic: Configuring generic parameter for MG
Thread-Index: AcPSRrAyqMORDn4ESeKoC9EnXsSHCQ==
From: "Aljaz Tomaz    ITWEG" <aljaz@iskratel.si>
To: <megaco@ietf.org>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Subject: [Megaco] Configuring generic parameter for MG
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Hi,
I'm relative new to MEGACO protocol and also I haven't found exactly the =
right answer to my issue. I would like to configure parameters on Media =
gateway (MG) that are valid for all MG (not stream specific).

Can anyone help me with that?

Best regards,=20
Tomaz

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Sat Jan  3 18:55:02 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18191
	for <megaco-archive@odin.ietf.org>; Sat, 3 Jan 2004 18:55:02 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcvbI-0004GJ-1l
	for megaco-archive@odin.ietf.org; Sat, 03 Jan 2004 18:54:36 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i03NsaEk016377
	for megaco-archive@odin.ietf.org; Sat, 3 Jan 2004 18:54:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcvbH-0004G4-Tg
	for megaco-web-archive@optimus.ietf.org; Sat, 03 Jan 2004 18:54:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18158
	for <megaco-web-archive@ietf.org>; Sat, 3 Jan 2004 18:54:31 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcvbE-0001I0-00
	for megaco-web-archive@ietf.org; Sat, 03 Jan 2004 18:54:32 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AcvZM-0001Ef-00
	for megaco-web-archive@ietf.org; Sat, 03 Jan 2004 18:52:36 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AcvXp-0001Bh-00
	for megaco-web-archive@ietf.org; Sat, 03 Jan 2004 18:51:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AcvXq-000453-AX; Sat, 03 Jan 2004 18:51:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Acu4W-0001BG-W7
	for megaco@optimus.ietf.org; Sat, 03 Jan 2004 17:16:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14423
	for <megaco@ietf.org>; Sat, 3 Jan 2004 17:16:37 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Acu4U-0004oq-00
	for megaco@ietf.org; Sat, 03 Jan 2004 17:16:38 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Acu2i-0004kw-00
	for megaco@ietf.org; Sat, 03 Jan 2004 17:14:48 -0500
Received: from cisc01.iskratel.si ([193.2.48.125])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Acu1A-0004eh-00
	for megaco@ietf.org; Sat, 03 Jan 2004 17:13:12 -0500
Received: from ntmailkr.iskratel.si (ntmailkr.iskratel.si [10.1.2.90])
	by cisc01.iskratel.si (8.12.10/8.12.10) with ESMTP id i03MCFUi001978
	for <megaco@ietf.org>; Sat, 3 Jan 2004 23:12:15 +0100 (MET)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Sat, 3 Jan 2004 23:12:34 +0100
Message-ID: <57D0409C9DC47A4B936406AC1788FA001E9BE2@ntmailkr.iskratel.si>
Thread-Topic: Configuring generic parameter for MG
Thread-Index: AcPSRrAyqMORDn4ESeKoC9EnXsSHCQ==
From: "Aljaz Tomaz    ITWEG" <aljaz@iskratel.si>
To: <megaco@ietf.org>
Content-Transfer-Encoding: quoted-printable
Subject: [Megaco] Configuring generic parameter for MG
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hi,
I'm relative new to MEGACO protocol and also I haven't found exactly the =
right answer to my issue. I would like to configure parameters on Media =
gateway (MG) that are valid for all MG (not stream specific).

Can anyone help me with that?

Best regards,=20
Tomaz

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Jan  5 02:05:41 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27683
	for <megaco-archive@lists.ietf.org>; Mon, 5 Jan 2004 02:05:41 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdOnO-0002kG-JD; Mon, 05 Jan 2004 02:05:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdOmi-0002j2-AB
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 02:04:22 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26234
	for <megaco@ietf.org>; Mon, 5 Jan 2004 02:04:15 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdOmX-0007WP-00
	for megaco@ietf.org; Mon, 05 Jan 2004 02:04:09 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdOho-0007RK-00
	for megaco@ietf.org; Mon, 05 Jan 2004 01:59:18 -0500
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdOgU-0007NG-00
	for megaco@ietf.org; Mon, 05 Jan 2004 01:57:54 -0500
Received: from l12381 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HR000GHW8LLYQ@mta0.huawei.com> for megaco@ietf.org;
 Mon, 05 Jan 2004 14:56:10 +0800 (CST)
Date: Mon, 05 Jan 2004 14:58:04 +0800
From: lihu <l12381@huawei.com>
To: Kevin Boyle <kboyle@nortelnetworks.com>
Cc: megaco@ietf.org
Message-id: <000a01c3d359$49e06a60$e0486e0a@huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
Content-type: multipart/alternative;
 boundary="Boundary_(ID_Wi+RP6fbr7tmb6hdHgD6wA)"
X-Priority: 3
X-MSMail-priority: Normal
References: <ABA227A15B80D511BD1A00508BF93A1C0D2B3BF0@zrtpd0jq.us.nortel.com>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=2.9 required=5.0 tests=AWL,DEAR_SOMETHING,
	FROM_ENDS_IN_NUMS,HTML_20_30,HTML_FONT_FACE_BAD,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR autolearn=no version=2.60
Subject: [Megaco] Re: About ICASCo packages
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

--Boundary_(ID_Wi+RP6fbr7tmb6hdHgD6wA)
Content-type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7BIT

hi,kevin,
   In ICASCO package, the digitmap of "di" is described as below "if the di token does not include a DigitMap name or value,then the digit map defined within the EventsDescriptor is used.If a digit map is neither provided within the di portion of this parameter nor as an EventDM parameter,then digits are collected until end of pulsing digit is received."   But in fact,the end of pulsing digit is not always sent. So it will be compelling signaling timeout .  I think an extend sign should be defined to resolve the situation where no digitmap and end of pulse will be present. Perhaps, digit is notified  one by one may solve the problem.
  
   How do you think so ?


   Best regards

LiHu
Huawei co.,Ltd.
86-10-82882747

*****************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
*****************************************************************

  ----- Original Message ----- 
  From: Kevin Boyle 
  To: lihu 
  Sent: Saturday, December 13, 2003 12:02 AM
  Subject: RE: About ICASCo packages


  Where does the 10 second figure come from?  Digitmap timers can be set and overridden to be whatever you want them to be.  I think you are placing artificial limits on the digitmap construct and on the package.

  I can assure you that using multiple digitmaps is possible -- we do it today in deployed products that support dialing plans from many different countries as well as international dialing.  Utilizing shorter timeouts and well-designed digitmaps will minimize the problems of digit collection delay.

  In the example you provide, the additional digits result in two extra messages each (a notify and a reply).  Each one of those messages is subject to latency and loss.  If either one of the messages for each digit is lost, that will result in retransmission, with the resultant delay for that digit, and also delay the notification of any further digits.  If the further digits are not held, then the digits could end up arriving at the MGC out of order, causing misrouting or call failure.  So the delays due to network latency and loss are encountered for each and every digit.  Fewer messages reduces the delay and loss impacts.

  Kevin



----------------------------------------------------------------------------
    From: lihu [mailto:l12381@huawei.com] 
    Sent: Friday, December 12, 2003 12:59 AM
    To: Boyle, Kevin [NCRTP:3Z40:EXCH]
    Subject: Re: About ICASCo packages


    Because the if the total called number is collected by Timeout in Digitmap,it will induce more than 10 secends delay.And in some location ,the peer cas link will not send the end of pulse .So if the digitmap can't cover all possible dialing number,there is only to wait for timeout.

    Also there is an example ,why the mgc can't use one or more digitmap to get digit without using timeout in digitmap.
          MGC
           |
    R2----MG -----R2---international   called:080-010-114,  080-010-12345678
     if a call is international call ,and MGC don't know the called length.It can 
    send digitmap dm={080x.L}$B!#(BIf MGC send the digitmap={080},and the rest digits are collected in digit by digit,the time addressing called is more shorter than the former.

    Does digitmap have some other method to solve the addressing called time ?

    Best Regards

    LiHu
    Huawei co.,Ltd.
    86-10-82882747

      ----- Original Message ----- 
      From: Kevin Boyle 
      To: lihu 
      Sent: Friday, December 12, 2003 12:18 PM
      Subject: RE: About ICASCo packages


      Why do you have to use only one digitmap?  There is nothing that says that you cannot use a second digitmap after the first one completes.

      Secondly, your example is not representative of all dialing plans.  I personally know of some locations where digit series of more than 30 digits are collected and passed on for international trunk translations.  Further, the assertion that "there are only 2 messages more" is fine if you are talking about a single termination collecting digits.  But what if this is a large tandem office with tens of thousands of CAS circuits?  The "2 more messages" becomes far, far more messaging en masse.

      Certainly, if your MGC wishes to collect digits in this fashion, that's certainly up to you as the implementor.  However, it is highly inefficient and each additional message carries network latency and the potential for loss/retransmission.  So you are potentially worsening your delay problem, not improving it.

      I'm not sure what you mean on your third point.  mfd is not in hex.  There are discrete digit events, or there are digitmap symbols.  The only hex present in the package is the binary encodings.

      Kevin



------------------------------------------------------------------------
        From: lihu [mailto:l12381@huawei.com] 
        Sent: Thursday, December 11, 2003 9:04 PM
        To: Boyle, Kevin [NCRTP:3Z40:EXCH]
        Subject: Re: About ICASCo packages


        Dear kevin,
         Because a perfect Digitmap is not easy to find, and also some center office(CO) can't decide whether the digit is collected completly.So the first part di are collected with icasco,the last part of di are collected with dd or mfd package.
        But if the icasco di'digitmap is improved with the ability of collecting digit by digit.So the icasco package is very flexible.The messages will only increase about 2 times of the collecting digit by digit.
        eg. di=123456 ,  MGC sends icaco di=dm{xxxx}, and the sends some other extend sign,
        which means the rest digit is notified digit by digit.
        There are only 2 messages more.
        Furthermore ,if mfd is used ,the notified content(hex code) should be convert to string.




        LiHu
        Huawei co.,Ltd.
        86-10-82882747

        ----- Original Message ----- 
          From: Kevin Boyle 
          To: lihu 
          Sent: Friday, December 12, 2003 8:08 AM
          Subject: RE: About ICASCo packages


          Digit by digit collection will result in a very large number of messages.  The balance will always be between delay and number of messages.  If you wish to do single digit collection, there is nothing prohibiting it -- use the dd or mfd package to look for single digits.  If, however, you are trying to strike a balance between number of messages and minimal delay, then your implementation will have to choose digitmaps that balance those two considerations appropriately for your particular implementation.

          Kevin



--------------------------------------------------------------------
            From: lihu [mailto:l12381@huawei.com] 
            Sent: Thursday, December 11, 2003 5:56 AM
            To: Boyle, Kevin [NCRTP:3Z40:EXCH]
            Subject: About ICASCo packages


            Dear sir,
               In ICASCO package in <D-xxx_H.248.ICASC.doc>,it describes 3 kinds of di collecting .But the end of Digitmap and end of pulsing can induce some delay if 
            MGC  can't send a perfect Digitmap and the peer can't send end of pulsing.
            So a digit by digit way should be defined in ICASCO package' di.

            Does it have any way to solve it ?

            Bestregards


            LiHu
            Huawei co.,Ltd.
            86-10-82882747

            *****************************************************************
            This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
            *****************************************************************

--Boundary_(ID_Wi+RP6fbr7tmb6hdHgD6wA)
Content-type: text/html; charset=iso-2022-jp
Content-Transfer-Encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-2022-jp">
<META content="MSHTML 5.50.4933.1800" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=$BAWBN(B size=2>hi,kevin,</FONT></DIV>
<DIV><FONT face=$BAWBN(B size=2>&nbsp;&nbsp;&nbsp;In ICASCO package, the digitmap of 
"di" is described as below "if the di token does not include a DigitMap name or 
value,then the digit map defined within the EventsDescriptor is used.If a digit 
map is neither provided within the di portion of this parameter nor as an 
EventDM parameter,then digits are collected until end of pulsing digit is 
received."&nbsp;&nbsp; But in fact,the end of pulsing digit is not always sent. 
So it will be compelling signaling&nbsp;timeout .&nbsp; I think an extend sign 
should be defined to resolve the situation where no digitmap and end of pulse 
will be present. Perhaps, digit is notified&nbsp; one by one may solve the 
problem.</FONT></DIV>
<DIV><FONT face=$BAWBN(B size=2>&nbsp; </FONT></DIV>
<DIV><FONT face=$BAWBN(B size=2>&nbsp;&nbsp; How do you think so ?</FONT></DIV>
<DIV><FONT face=$BAWBN(B size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=$BAWBN(B size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=$BAWBN(B size=2>&nbsp;&nbsp; Best regards</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>LiHu<BR>Huawei co.,Ltd.<BR>86-10-82882747</DIV>
<DIV>&nbsp;</DIV>
<DIV>*****************************************************************<BR>This 
e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use 
of the information contained herein in any way (including, but not limited to, 
total or partial disclosure, reproduction, or dissemination) by persons other 
than the intended recipient(s) is prohibited. If you receive this e-mail in 
error, please notify the sender by phone or email immediately and delete 
it!<BR>*****************************************************************<BR></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 9pt $BAWBN(B">----- Original Message ----- </DIV>
  <DIV style="BACKGROUND: #e4e4e4; FONT: 9pt $BAWBN(B; font-color: black"><B>From:</B> 
  <A title=kboyle@nortelnetworks.com 
  href="mailto:kboyle@nortelnetworks.com">Kevin Boyle</A> </DIV>
  <DIV style="FONT: 9pt $BAWBN(B"><B>To:</B> <A title=l12381@huawei.com 
  href="mailto:l12381@huawei.com">lihu</A> </DIV>
  <DIV style="FONT: 9pt $BAWBN(B"><B>Sent:</B> Saturday, December 13, 2003 12:02 
  AM</DIV>
  <DIV style="FONT: 9pt $BAWBN(B"><B>Subject:</B> RE: About ICASCo packages</DIV>
  <DIV><BR></DIV>
  <DIV dir=ltr align=left><SPAN class=282593014-12122003><FONT face=Arial 
  size=2>Where does the&nbsp;10 second figure come&nbsp;from?&nbsp; Digitmap 
  timers can be set and overridden to be whatever you want them to be.&nbsp; I 
  think you are placing artificial limits on the digitmap construct and on the 
  package.</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=282593014-12122003><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=282593014-12122003><FONT face=Arial 
  size=2>I can assure you that using multiple digitmaps is possible -- we do it 
  today in deployed products that support dialing plans from many different 
  countries as well as international dialing.&nbsp; Utilizing shorter timeouts 
  and well-designed digitmaps will minimize the problems of digit collection 
  delay.</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=282593014-12122003><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=282593014-12122003><FONT face=Arial 
  size=2>In the example you provide, the additional digits result in two extra 
  messages each (a notify and a reply).&nbsp; Each one of those messages is 
  subject to latency and loss.&nbsp; If either one of the messages for each 
  digit is lost, that will result in retransmission, with the resultant delay 
  for that digit, and also delay the notification of any further digits.&nbsp; 
  If the further digits are not held, then the digits could end up arriving at 
  the MGC out of order, causing misrouting or call failure.&nbsp; So the delays 
  due to network latency and loss are encountered for each and every 
  digit.&nbsp; Fewer messages reduces the delay and loss 
  impacts.</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=282593014-12122003><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=282593014-12122003><FONT face=Arial 
  size=2>Kevin</FONT></SPAN></DIV><BR>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
    <HR tabIndex=-1>
    <FONT face=Tahoma size=2><B>From:</B> lihu [mailto:l12381@huawei.com] 
    <BR><B>Sent:</B> Friday, December 12, 2003 12:59 AM<BR><B>To:</B> Boyle, 
    Kevin [NCRTP:3Z40:EXCH]<BR><B>Subject:</B> Re: About ICASCo 
    packages<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV><FONT size=2>Because the&nbsp;if the&nbsp;total&nbsp;called number is 
    collected by Timeout in Digitmap,it will induce&nbsp;more than&nbsp;10 
    secends&nbsp;delay.And in some location ,the peer cas link will not send the 
    end of pulse .So if the digitmap can't cover all possible dialing 
    number,there is only to wait for timeout.</FONT></DIV>
    <DIV><FONT size=2></FONT><FONT size=2></FONT>&nbsp;</DIV>
    <DIV><FONT size=2>Also there is an example ,why the mgc can't&nbsp;use one 
    or more digitmap to get digit without&nbsp;using timeout 
    in&nbsp;digitmap.</FONT></DIV>
    <DIV><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MGC</FONT></DIV>
    <DIV><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT></DIV>
    <DIV><FONT size=2>R2----MG -----R2---international&nbsp;&nbsp; 
    called:080-010-114,&nbsp; 080-010-12345678</FONT></DIV>
    <DIV>&nbsp;<FONT size=2>if a call is international call ,and MGC don't know 
    the called length.It can </FONT></DIV>
    <DIV><FONT size=2>send digitmap dm={080x.L}$B!#(BIf MGC send the 
    digitmap={080},and the rest digits are collected in digit by digit,the time 
    addressing called&nbsp;is more shorter than the former.</FONT></DIV>
    <DIV><FONT size=2></FONT>&nbsp;</DIV>
    <DIV><FONT size=2>Does&nbsp;digitmap have some other method to solve the 
    addressing called time ?</FONT></DIV>
    <DIV><FONT size=2></FONT>&nbsp;</DIV>
    <DIV><FONT size=2>Best Regards</FONT></DIV>
    <DIV><FONT size=2></FONT>&nbsp;</DIV>
    <DIV>LiHu<BR>Huawei co.,Ltd.<BR>86-10-82882747</DIV>
    <DIV><FONT size=2></FONT>&nbsp;</DIV>
    <BLOCKQUOTE dir=ltr 
    style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
      <DIV style="FONT: 9pt $BAWBN(B">----- Original Message ----- </DIV>
      <DIV 
      style="BACKGROUND: #e4e4e4; FONT: 9pt $BAWBN(B; font-color: black"><B>From:</B> 
      <A title=kboyle@nortelnetworks.com 
      href="mailto:kboyle@nortelnetworks.com">Kevin Boyle</A> </DIV>
      <DIV style="FONT: 9pt $BAWBN(B"><B>To:</B> <A title=l12381@huawei.com 
      href="mailto:l12381@huawei.com">lihu</A> </DIV>
      <DIV style="FONT: 9pt $BAWBN(B"><B>Sent:</B> Friday, December 12, 2003 12:18 
      PM</DIV>
      <DIV style="FONT: 9pt $BAWBN(B"><B>Subject:</B> RE: About ICASCo packages</DIV>
      <DIV><BR></DIV>
      <DIV dir=ltr align=left><SPAN class=202041104-12122003><FONT face=Arial 
      size=2>Why do you have to use only one digitmap?&nbsp; There is nothing 
      that says that you cannot use a second digitmap after the first one 
      completes.</FONT></SPAN></DIV>
      <DIV dir=ltr align=left><SPAN class=202041104-12122003><FONT face=Arial 
      size=2></FONT></SPAN>&nbsp;</DIV>
      <DIV dir=ltr align=left><SPAN class=202041104-12122003><FONT face=Arial 
      size=2>Secondly, your example is not representative of all dialing 
      plans.&nbsp; I personally know of some locations where digit series of 
      more than 30 digits are collected and passed on for international trunk 
      translations.&nbsp; Further, the assertion that "there are only 2 messages 
      more" is fine if you are talking about a single termination collecting 
      digits.&nbsp; But what if this is a large tandem office with tens of 
      thousands of CAS circuits?&nbsp; The "2 more messages" becomes far, far 
      more messaging en masse.</FONT></SPAN></DIV>
      <DIV dir=ltr align=left><SPAN class=202041104-12122003><FONT face=Arial 
      size=2></FONT></SPAN>&nbsp;</DIV>
      <DIV dir=ltr align=left><SPAN class=202041104-12122003><FONT face=Arial 
      size=2>Certainly, if your MGC wishes to collect digits in this fashion, 
      that's certainly up to you as the implementor.&nbsp; However, it is highly 
      inefficient and each additional message carries network latency and the 
      potential for loss/retransmission.&nbsp; So you are potentially worsening 
      your delay problem, not improving it.</FONT></SPAN></DIV>
      <DIV dir=ltr align=left><SPAN class=202041104-12122003><FONT face=Arial 
      size=2></FONT></SPAN>&nbsp;</DIV>
      <DIV dir=ltr align=left><SPAN class=202041104-12122003><FONT face=Arial 
      size=2>I'm not sure what you mean on your third point.&nbsp; mfd is not in 
      hex.&nbsp; There are discrete digit events, or there are digitmap 
      symbols.&nbsp; The only hex present in the package is the binary 
      encodings.</FONT></SPAN></DIV>
      <DIV dir=ltr align=left><SPAN class=202041104-12122003><FONT face=Arial 
      size=2></FONT></SPAN>&nbsp;</DIV>
      <DIV dir=ltr align=left><SPAN class=202041104-12122003><FONT face=Arial 
      size=2>Kevin</FONT></SPAN></DIV><BR>
      <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
        <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
        <HR tabIndex=-1>
        <FONT face=Tahoma size=2><B>From:</B> lihu [mailto:l12381@huawei.com] 
        <BR><B>Sent:</B> Thursday, December 11, 2003 9:04 PM<BR><B>To:</B> 
        Boyle, Kevin [NCRTP:3Z40:EXCH]<BR><B>Subject:</B> Re: About ICASCo 
        packages<BR></FONT><BR></DIV>
        <DIV></DIV>
        <DIV><FONT size=2>Dear kevin,</FONT></DIV>
        <DIV><FONT size=2>&nbsp;Because a perfect Digitmap&nbsp;is not easy to 
        find, and also some center office(CO)&nbsp;can't decide whether the 
        digit is collected completly.So the first part di&nbsp;are collected 
        with icasco,the last part of di are collected with dd or mfd 
        package.</FONT></DIV>
        <DIV><FONT size=2>But if the icasco di'digitmap is improved with the 
        ability of collecting digit by digit.So the icasco package is very 
        flexible.The messages will only increase about 2 times of the collecting 
        digit by digit.</FONT></DIV>
        <DIV><FONT size=2>eg.&nbsp;di=123456 ,&nbsp; MGC sends icaco 
        di=dm{xxxx}, and the sends some other extend sign,</FONT></DIV>
        <DIV><FONT size=2>which means the rest digit is notified digit by 
        digit.</FONT></DIV>
        <DIV><FONT size=2>There are only 2 messages more.</FONT></DIV>
        <DIV><FONT size=2>Furthermore ,if mfd is used ,the notified content(hex 
        code) should be convert to string.</FONT></DIV>
        <DIV><FONT size=2></FONT>&nbsp;</DIV>
        <DIV><FONT size=2></FONT>&nbsp;</DIV>
        <DIV><FONT size=2></FONT>&nbsp;</DIV>
        <DIV><FONT size=2></FONT>&nbsp;</DIV>
        <DIV>LiHu<BR>Huawei co.,Ltd.<BR>86-10-82882747</DIV>
        <DIV>&nbsp;</DIV>
        <DIV>----- Original Message ----- </DIV>
        <BLOCKQUOTE dir=ltr 
        style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
          <DIV 
          style="BACKGROUND: #e4e4e4; FONT: 9pt $BAWBN(B; font-color: black"><B>From:</B> 
          <A title=kboyle@nortelnetworks.com 
          href="mailto:kboyle@nortelnetworks.com">Kevin Boyle</A> </DIV>
          <DIV style="FONT: 9pt $BAWBN(B"><B>To:</B> <A title=l12381@huawei.com 
          href="mailto:l12381@huawei.com">lihu</A> </DIV>
          <DIV style="FONT: 9pt $BAWBN(B"><B>Sent:</B> Friday, December 12, 2003 8:08 
          AM</DIV>
          <DIV style="FONT: 9pt $BAWBN(B"><B>Subject:</B> RE: About ICASCo 
          packages</DIV>
          <DIV><BR></DIV>
          <DIV dir=ltr align=left><SPAN class=551120120-11122003><FONT 
          face=Arial size=2>Digit by digit collection will result in a very 
          large number of messages.&nbsp; The balance will always be between 
          delay and number of messages.&nbsp; If you wish to do single digit 
          collection, there is nothing prohibiting it -- use the dd or mfd 
          package to look for single digits.&nbsp; If, however, you are trying 
          to strike a balance between number of messages and minimal delay, then 
          your implementation will have to choose digitmaps that balance those 
          two considerations appropriately for your particular 
          implementation.</FONT></SPAN></DIV>
          <DIV dir=ltr align=left><SPAN class=551120120-11122003><FONT 
          face=Arial size=2></FONT></SPAN>&nbsp;</DIV>
          <DIV dir=ltr align=left><SPAN class=551120120-11122003><FONT 
          face=Arial size=2>Kevin</FONT></SPAN></DIV><BR>
          <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
            <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
            <HR tabIndex=-1>
            <FONT face=Tahoma size=2><B>From:</B> lihu 
            [mailto:l12381@huawei.com] <BR><B>Sent:</B> Thursday, December 11, 
            2003 5:56 AM<BR><B>To:</B> Boyle, Kevin 
            [NCRTP:3Z40:EXCH]<BR><B>Subject:</B> About ICASCo 
            packages<BR></FONT><BR></DIV>
            <DIV></DIV>
            <DIV><FONT size=2>Dear sir,</FONT></DIV>
            <DIV><FONT size=2>&nbsp;&nbsp; In ICASCO package in 
            &lt;D-xxx_H.248.ICASC.doc&gt;,it describes 3 kinds of di collecting 
            .But the end of Digitmap and end of pulsing can induce some delay if 
            </FONT></DIV>
            <DIV><FONT size=2>MGC&nbsp; can't send a perfect Digitmap and the 
            peer can't send end of pulsing.</FONT></DIV>
            <DIV><FONT size=2>So a digit by digit way should be defined in 
            ICASCO package' di.</FONT></DIV>
            <DIV><FONT size=2></FONT>&nbsp;</DIV>
            <DIV><FONT size=2>Does it have any way to solve it ?</FONT></DIV>
            <DIV><FONT size=2></FONT>&nbsp;</DIV>
            <DIV><FONT size=2>Bestregards</FONT></DIV>
            <DIV>&nbsp;</DIV>
            <DIV><FONT size=2></FONT>&nbsp;</DIV>
            <DIV><FONT size=2>LiHu<BR>Huawei 
            co.,Ltd.<BR>86-10-82882747</FONT></DIV>
            <DIV>&nbsp;</DIV>
            <DIV><FONT 
            size=2>*****************************************************************<BR>This 
            e-mail and its attachments contain confidential information from 
            HUAWEI, which is intended only for the person or entity whose 
            address is listed above. Any use of the information contained herein 
            in any way (including, but not limited to, total or partial 
            disclosure, reproduction, or dissemination) by persons other than 
            the intended recipient(s) is prohibited. If you receive this e-mail 
            in error, please notify the sender by phone or email immediately and 
            delete 
            it!<BR>*****************************************************************<BR></FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_Wi+RP6fbr7tmb6hdHgD6wA)--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Mon Jan  5 02:13:36 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04365
	for <megaco-archive@odin.ietf.org>; Mon, 5 Jan 2004 02:13:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdOvB-0003wy-39
	for megaco-archive@odin.ietf.org; Mon, 05 Jan 2004 02:13:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i057D4Hf015183
	for megaco-archive@odin.ietf.org; Mon, 5 Jan 2004 02:13:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdOvA-0003wo-0F
	for megaco-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 02:13:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04297
	for <megaco-web-archive@ietf.org>; Mon, 5 Jan 2004 02:12:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdOuw-00000M-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 02:12:50 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdOrs-0007hR-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 02:09:43 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdOnq-0007ZE-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 02:05:30 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdOnO-0002kG-JD; Mon, 05 Jan 2004 02:05:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdOmi-0002j2-AB
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 02:04:22 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26234
	for <megaco@ietf.org>; Mon, 5 Jan 2004 02:04:15 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdOmX-0007WP-00
	for megaco@ietf.org; Mon, 05 Jan 2004 02:04:09 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdOho-0007RK-00
	for megaco@ietf.org; Mon, 05 Jan 2004 01:59:18 -0500
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdOgU-0007NG-00
	for megaco@ietf.org; Mon, 05 Jan 2004 01:57:54 -0500
Received: from l12381 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HR000GHW8LLYQ@mta0.huawei.com> for megaco@ietf.org;
 Mon, 05 Jan 2004 14:56:10 +0800 (CST)
Date: Mon, 05 Jan 2004 14:58:04 +0800
From: lihu <l12381@huawei.com>
To: Kevin Boyle <kboyle@nortelnetworks.com>
Cc: megaco@ietf.org
Message-id: <000a01c3d359$49e06a60$e0486e0a@huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
Content-type: multipart/alternative;
 boundary="Boundary_(ID_Wi+RP6fbr7tmb6hdHgD6wA)"
X-Priority: 3
X-MSMail-priority: Normal
References: <ABA227A15B80D511BD1A00508BF93A1C0D2B3BF0@zrtpd0jq.us.nortel.com>
Subject: [Megaco] Re: About ICASCo packages
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=3.0 required=5.0 tests=AWL,DEAR_SOMETHING,
	FROM_ENDS_IN_NUMS,HTML_20_30,HTML_FONT_FACE_BAD,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR autolearn=no version=2.60

This is a multi-part message in MIME format.

--Boundary_(ID_Wi+RP6fbr7tmb6hdHgD6wA)
Content-type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7BIT

hi,kevin,
   In ICASCO package, the digitmap of "di" is described as below "if the di token does not include a DigitMap name or value,then the digit map defined within the EventsDescriptor is used.If a digit map is neither provided within the di portion of this parameter nor as an EventDM parameter,then digits are collected until end of pulsing digit is received."   But in fact,the end of pulsing digit is not always sent. So it will be compelling signaling timeout .  I think an extend sign should be defined to resolve the situation where no digitmap and end of pulse will be present. Perhaps, digit is notified  one by one may solve the problem.
  
   How do you think so ?


   Best regards

LiHu
Huawei co.,Ltd.
86-10-82882747

*****************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
*****************************************************************

  ----- Original Message ----- 
  From: Kevin Boyle 
  To: lihu 
  Sent: Saturday, December 13, 2003 12:02 AM
  Subject: RE: About ICASCo packages


  Where does the 10 second figure come from?  Digitmap timers can be set and overridden to be whatever you want them to be.  I think you are placing artificial limits on the digitmap construct and on the package.

  I can assure you that using multiple digitmaps is possible -- we do it today in deployed products that support dialing plans from many different countries as well as international dialing.  Utilizing shorter timeouts and well-designed digitmaps will minimize the problems of digit collection delay.

  In the example you provide, the additional digits result in two extra messages each (a notify and a reply).  Each one of those messages is subject to latency and loss.  If either one of the messages for each digit is lost, that will result in retransmission, with the resultant delay for that digit, and also delay the notification of any further digits.  If the further digits are not held, then the digits could end up arriving at the MGC out of order, causing misrouting or call failure.  So the delays due to network latency and loss are encountered for each and every digit.  Fewer messages reduces the delay and loss impacts.

  Kevin



----------------------------------------------------------------------------
    From: lihu [mailto:l12381@huawei.com] 
    Sent: Friday, December 12, 2003 12:59 AM
    To: Boyle, Kevin [NCRTP:3Z40:EXCH]
    Subject: Re: About ICASCo packages


    Because the if the total called number is collected by Timeout in Digitmap,it will induce more than 10 secends delay.And in some location ,the peer cas link will not send the end of pulse .So if the digitmap can't cover all possible dialing number,there is only to wait for timeout.

    Also there is an example ,why the mgc can't use one or more digitmap to get digit without using timeout in digitmap.
          MGC
           |
    R2----MG -----R2---international   called:080-010-114,  080-010-12345678
     if a call is international call ,and MGC don't know the called length.It can 
    send digitmap dm={080x.L}$B!#(BIf MGC send the digitmap={080},and the rest digits are collected in digit by digit,the time addressing called is more shorter than the former.

    Does digitmap have some other method to solve the addressing called time ?

    Best Regards

    LiHu
    Huawei co.,Ltd.
    86-10-82882747

      ----- Original Message ----- 
      From: Kevin Boyle 
      To: lihu 
      Sent: Friday, December 12, 2003 12:18 PM
      Subject: RE: About ICASCo packages


      Why do you have to use only one digitmap?  There is nothing that says that you cannot use a second digitmap after the first one completes.

      Secondly, your example is not representative of all dialing plans.  I personally know of some locations where digit series of more than 30 digits are collected and passed on for international trunk translations.  Further, the assertion that "there are only 2 messages more" is fine if you are talking about a single termination collecting digits.  But what if this is a large tandem office with tens of thousands of CAS circuits?  The "2 more messages" becomes far, far more messaging en masse.

      Certainly, if your MGC wishes to collect digits in this fashion, that's certainly up to you as the implementor.  However, it is highly inefficient and each additional message carries network latency and the potential for loss/retransmission.  So you are potentially worsening your delay problem, not improving it.

      I'm not sure what you mean on your third point.  mfd is not in hex.  There are discrete digit events, or there are digitmap symbols.  The only hex present in the package is the binary encodings.

      Kevin



------------------------------------------------------------------------
        From: lihu [mailto:l12381@huawei.com] 
        Sent: Thursday, December 11, 2003 9:04 PM
        To: Boyle, Kevin [NCRTP:3Z40:EXCH]
        Subject: Re: About ICASCo packages


        Dear kevin,
         Because a perfect Digitmap is not easy to find, and also some center office(CO) can't decide whether the digit is collected completly.So the first part di are collected with icasco,the last part of di are collected with dd or mfd package.
        But if the icasco di'digitmap is improved with the ability of collecting digit by digit.So the icasco package is very flexible.The messages will only increase about 2 times of the collecting digit by digit.
        eg. di=123456 ,  MGC sends icaco di=dm{xxxx}, and the sends some other extend sign,
        which means the rest digit is notified digit by digit.
        There are only 2 messages more.
        Furthermore ,if mfd is used ,the notified content(hex code) should be convert to string.




        LiHu
        Huawei co.,Ltd.
        86-10-82882747

        ----- Original Message ----- 
          From: Kevin Boyle 
          To: lihu 
          Sent: Friday, December 12, 2003 8:08 AM
          Subject: RE: About ICASCo packages


          Digit by digit collection will result in a very large number of messages.  The balance will always be between delay and number of messages.  If you wish to do single digit collection, there is nothing prohibiting it -- use the dd or mfd package to look for single digits.  If, however, you are trying to strike a balance between number of messages and minimal delay, then your implementation will have to choose digitmaps that balance those two considerations appropriately for your particular implementation.

          Kevin



--------------------------------------------------------------------
            From: lihu [mailto:l12381@huawei.com] 
            Sent: Thursday, December 11, 2003 5:56 AM
            To: Boyle, Kevin [NCRTP:3Z40:EXCH]
            Subject: About ICASCo packages


            Dear sir,
               In ICASCO package in <D-xxx_H.248.ICASC.doc>,it describes 3 kinds of di collecting .But the end of Digitmap and end of pulsing can induce some delay if 
            MGC  can't send a perfect Digitmap and the peer can't send end of pulsing.
            So a digit by digit way should be defined in ICASCO package' di.

            Does it have any way to solve it ?

            Bestregards


            LiHu
            Huawei co.,Ltd.
            86-10-82882747

            *****************************************************************
            This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
            *****************************************************************

--Boundary_(ID_Wi+RP6fbr7tmb6hdHgD6wA)
Content-type: text/html; charset=iso-2022-jp
Content-Transfer-Encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-2022-jp">
<META content="MSHTML 5.50.4933.1800" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=$BAWBN(B size=2>hi,kevin,</FONT></DIV>
<DIV><FONT face=$BAWBN(B size=2>&nbsp;&nbsp;&nbsp;In ICASCO package, the digitmap of 
"di" is described as below "if the di token does not include a DigitMap name or 
value,then the digit map defined within the EventsDescriptor is used.If a digit 
map is neither provided within the di portion of this parameter nor as an 
EventDM parameter,then digits are collected until end of pulsing digit is 
received."&nbsp;&nbsp; But in fact,the end of pulsing digit is not always sent. 
So it will be compelling signaling&nbsp;timeout .&nbsp; I think an extend sign 
should be defined to resolve the situation where no digitmap and end of pulse 
will be present. Perhaps, digit is notified&nbsp; one by one may solve the 
problem.</FONT></DIV>
<DIV><FONT face=$BAWBN(B size=2>&nbsp; </FONT></DIV>
<DIV><FONT face=$BAWBN(B size=2>&nbsp;&nbsp; How do you think so ?</FONT></DIV>
<DIV><FONT face=$BAWBN(B size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=$BAWBN(B size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=$BAWBN(B size=2>&nbsp;&nbsp; Best regards</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>LiHu<BR>Huawei co.,Ltd.<BR>86-10-82882747</DIV>
<DIV>&nbsp;</DIV>
<DIV>*****************************************************************<BR>This 
e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use 
of the information contained herein in any way (including, but not limited to, 
total or partial disclosure, reproduction, or dissemination) by persons other 
than the intended recipient(s) is prohibited. If you receive this e-mail in 
error, please notify the sender by phone or email immediately and delete 
it!<BR>*****************************************************************<BR></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 9pt $BAWBN(B">----- Original Message ----- </DIV>
  <DIV style="BACKGROUND: #e4e4e4; FONT: 9pt $BAWBN(B; font-color: black"><B>From:</B> 
  <A title=kboyle@nortelnetworks.com 
  href="mailto:kboyle@nortelnetworks.com">Kevin Boyle</A> </DIV>
  <DIV style="FONT: 9pt $BAWBN(B"><B>To:</B> <A title=l12381@huawei.com 
  href="mailto:l12381@huawei.com">lihu</A> </DIV>
  <DIV style="FONT: 9pt $BAWBN(B"><B>Sent:</B> Saturday, December 13, 2003 12:02 
  AM</DIV>
  <DIV style="FONT: 9pt $BAWBN(B"><B>Subject:</B> RE: About ICASCo packages</DIV>
  <DIV><BR></DIV>
  <DIV dir=ltr align=left><SPAN class=282593014-12122003><FONT face=Arial 
  size=2>Where does the&nbsp;10 second figure come&nbsp;from?&nbsp; Digitmap 
  timers can be set and overridden to be whatever you want them to be.&nbsp; I 
  think you are placing artificial limits on the digitmap construct and on the 
  package.</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=282593014-12122003><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=282593014-12122003><FONT face=Arial 
  size=2>I can assure you that using multiple digitmaps is possible -- we do it 
  today in deployed products that support dialing plans from many different 
  countries as well as international dialing.&nbsp; Utilizing shorter timeouts 
  and well-designed digitmaps will minimize the problems of digit collection 
  delay.</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=282593014-12122003><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=282593014-12122003><FONT face=Arial 
  size=2>In the example you provide, the additional digits result in two extra 
  messages each (a notify and a reply).&nbsp; Each one of those messages is 
  subject to latency and loss.&nbsp; If either one of the messages for each 
  digit is lost, that will result in retransmission, with the resultant delay 
  for that digit, and also delay the notification of any further digits.&nbsp; 
  If the further digits are not held, then the digits could end up arriving at 
  the MGC out of order, causing misrouting or call failure.&nbsp; So the delays 
  due to network latency and loss are encountered for each and every 
  digit.&nbsp; Fewer messages reduces the delay and loss 
  impacts.</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=282593014-12122003><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=282593014-12122003><FONT face=Arial 
  size=2>Kevin</FONT></SPAN></DIV><BR>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
    <HR tabIndex=-1>
    <FONT face=Tahoma size=2><B>From:</B> lihu [mailto:l12381@huawei.com] 
    <BR><B>Sent:</B> Friday, December 12, 2003 12:59 AM<BR><B>To:</B> Boyle, 
    Kevin [NCRTP:3Z40:EXCH]<BR><B>Subject:</B> Re: About ICASCo 
    packages<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV><FONT size=2>Because the&nbsp;if the&nbsp;total&nbsp;called number is 
    collected by Timeout in Digitmap,it will induce&nbsp;more than&nbsp;10 
    secends&nbsp;delay.And in some location ,the peer cas link will not send the 
    end of pulse .So if the digitmap can't cover all possible dialing 
    number,there is only to wait for timeout.</FONT></DIV>
    <DIV><FONT size=2></FONT><FONT size=2></FONT>&nbsp;</DIV>
    <DIV><FONT size=2>Also there is an example ,why the mgc can't&nbsp;use one 
    or more digitmap to get digit without&nbsp;using timeout 
    in&nbsp;digitmap.</FONT></DIV>
    <DIV><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MGC</FONT></DIV>
    <DIV><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT></DIV>
    <DIV><FONT size=2>R2----MG -----R2---international&nbsp;&nbsp; 
    called:080-010-114,&nbsp; 080-010-12345678</FONT></DIV>
    <DIV>&nbsp;<FONT size=2>if a call is international call ,and MGC don't know 
    the called length.It can </FONT></DIV>
    <DIV><FONT size=2>send digitmap dm={080x.L}$B!#(BIf MGC send the 
    digitmap={080},and the rest digits are collected in digit by digit,the time 
    addressing called&nbsp;is more shorter than the former.</FONT></DIV>
    <DIV><FONT size=2></FONT>&nbsp;</DIV>
    <DIV><FONT size=2>Does&nbsp;digitmap have some other method to solve the 
    addressing called time ?</FONT></DIV>
    <DIV><FONT size=2></FONT>&nbsp;</DIV>
    <DIV><FONT size=2>Best Regards</FONT></DIV>
    <DIV><FONT size=2></FONT>&nbsp;</DIV>
    <DIV>LiHu<BR>Huawei co.,Ltd.<BR>86-10-82882747</DIV>
    <DIV><FONT size=2></FONT>&nbsp;</DIV>
    <BLOCKQUOTE dir=ltr 
    style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
      <DIV style="FONT: 9pt $BAWBN(B">----- Original Message ----- </DIV>
      <DIV 
      style="BACKGROUND: #e4e4e4; FONT: 9pt $BAWBN(B; font-color: black"><B>From:</B> 
      <A title=kboyle@nortelnetworks.com 
      href="mailto:kboyle@nortelnetworks.com">Kevin Boyle</A> </DIV>
      <DIV style="FONT: 9pt $BAWBN(B"><B>To:</B> <A title=l12381@huawei.com 
      href="mailto:l12381@huawei.com">lihu</A> </DIV>
      <DIV style="FONT: 9pt $BAWBN(B"><B>Sent:</B> Friday, December 12, 2003 12:18 
      PM</DIV>
      <DIV style="FONT: 9pt $BAWBN(B"><B>Subject:</B> RE: About ICASCo packages</DIV>
      <DIV><BR></DIV>
      <DIV dir=ltr align=left><SPAN class=202041104-12122003><FONT face=Arial 
      size=2>Why do you have to use only one digitmap?&nbsp; There is nothing 
      that says that you cannot use a second digitmap after the first one 
      completes.</FONT></SPAN></DIV>
      <DIV dir=ltr align=left><SPAN class=202041104-12122003><FONT face=Arial 
      size=2></FONT></SPAN>&nbsp;</DIV>
      <DIV dir=ltr align=left><SPAN class=202041104-12122003><FONT face=Arial 
      size=2>Secondly, your example is not representative of all dialing 
      plans.&nbsp; I personally know of some locations where digit series of 
      more than 30 digits are collected and passed on for international trunk 
      translations.&nbsp; Further, the assertion that "there are only 2 messages 
      more" is fine if you are talking about a single termination collecting 
      digits.&nbsp; But what if this is a large tandem office with tens of 
      thousands of CAS circuits?&nbsp; The "2 more messages" becomes far, far 
      more messaging en masse.</FONT></SPAN></DIV>
      <DIV dir=ltr align=left><SPAN class=202041104-12122003><FONT face=Arial 
      size=2></FONT></SPAN>&nbsp;</DIV>
      <DIV dir=ltr align=left><SPAN class=202041104-12122003><FONT face=Arial 
      size=2>Certainly, if your MGC wishes to collect digits in this fashion, 
      that's certainly up to you as the implementor.&nbsp; However, it is highly 
      inefficient and each additional message carries network latency and the 
      potential for loss/retransmission.&nbsp; So you are potentially worsening 
      your delay problem, not improving it.</FONT></SPAN></DIV>
      <DIV dir=ltr align=left><SPAN class=202041104-12122003><FONT face=Arial 
      size=2></FONT></SPAN>&nbsp;</DIV>
      <DIV dir=ltr align=left><SPAN class=202041104-12122003><FONT face=Arial 
      size=2>I'm not sure what you mean on your third point.&nbsp; mfd is not in 
      hex.&nbsp; There are discrete digit events, or there are digitmap 
      symbols.&nbsp; The only hex present in the package is the binary 
      encodings.</FONT></SPAN></DIV>
      <DIV dir=ltr align=left><SPAN class=202041104-12122003><FONT face=Arial 
      size=2></FONT></SPAN>&nbsp;</DIV>
      <DIV dir=ltr align=left><SPAN class=202041104-12122003><FONT face=Arial 
      size=2>Kevin</FONT></SPAN></DIV><BR>
      <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
        <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
        <HR tabIndex=-1>
        <FONT face=Tahoma size=2><B>From:</B> lihu [mailto:l12381@huawei.com] 
        <BR><B>Sent:</B> Thursday, December 11, 2003 9:04 PM<BR><B>To:</B> 
        Boyle, Kevin [NCRTP:3Z40:EXCH]<BR><B>Subject:</B> Re: About ICASCo 
        packages<BR></FONT><BR></DIV>
        <DIV></DIV>
        <DIV><FONT size=2>Dear kevin,</FONT></DIV>
        <DIV><FONT size=2>&nbsp;Because a perfect Digitmap&nbsp;is not easy to 
        find, and also some center office(CO)&nbsp;can't decide whether the 
        digit is collected completly.So the first part di&nbsp;are collected 
        with icasco,the last part of di are collected with dd or mfd 
        package.</FONT></DIV>
        <DIV><FONT size=2>But if the icasco di'digitmap is improved with the 
        ability of collecting digit by digit.So the icasco package is very 
        flexible.The messages will only increase about 2 times of the collecting 
        digit by digit.</FONT></DIV>
        <DIV><FONT size=2>eg.&nbsp;di=123456 ,&nbsp; MGC sends icaco 
        di=dm{xxxx}, and the sends some other extend sign,</FONT></DIV>
        <DIV><FONT size=2>which means the rest digit is notified digit by 
        digit.</FONT></DIV>
        <DIV><FONT size=2>There are only 2 messages more.</FONT></DIV>
        <DIV><FONT size=2>Furthermore ,if mfd is used ,the notified content(hex 
        code) should be convert to string.</FONT></DIV>
        <DIV><FONT size=2></FONT>&nbsp;</DIV>
        <DIV><FONT size=2></FONT>&nbsp;</DIV>
        <DIV><FONT size=2></FONT>&nbsp;</DIV>
        <DIV><FONT size=2></FONT>&nbsp;</DIV>
        <DIV>LiHu<BR>Huawei co.,Ltd.<BR>86-10-82882747</DIV>
        <DIV>&nbsp;</DIV>
        <DIV>----- Original Message ----- </DIV>
        <BLOCKQUOTE dir=ltr 
        style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
          <DIV 
          style="BACKGROUND: #e4e4e4; FONT: 9pt $BAWBN(B; font-color: black"><B>From:</B> 
          <A title=kboyle@nortelnetworks.com 
          href="mailto:kboyle@nortelnetworks.com">Kevin Boyle</A> </DIV>
          <DIV style="FONT: 9pt $BAWBN(B"><B>To:</B> <A title=l12381@huawei.com 
          href="mailto:l12381@huawei.com">lihu</A> </DIV>
          <DIV style="FONT: 9pt $BAWBN(B"><B>Sent:</B> Friday, December 12, 2003 8:08 
          AM</DIV>
          <DIV style="FONT: 9pt $BAWBN(B"><B>Subject:</B> RE: About ICASCo 
          packages</DIV>
          <DIV><BR></DIV>
          <DIV dir=ltr align=left><SPAN class=551120120-11122003><FONT 
          face=Arial size=2>Digit by digit collection will result in a very 
          large number of messages.&nbsp; The balance will always be between 
          delay and number of messages.&nbsp; If you wish to do single digit 
          collection, there is nothing prohibiting it -- use the dd or mfd 
          package to look for single digits.&nbsp; If, however, you are trying 
          to strike a balance between number of messages and minimal delay, then 
          your implementation will have to choose digitmaps that balance those 
          two considerations appropriately for your particular 
          implementation.</FONT></SPAN></DIV>
          <DIV dir=ltr align=left><SPAN class=551120120-11122003><FONT 
          face=Arial size=2></FONT></SPAN>&nbsp;</DIV>
          <DIV dir=ltr align=left><SPAN class=551120120-11122003><FONT 
          face=Arial size=2>Kevin</FONT></SPAN></DIV><BR>
          <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
            <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
            <HR tabIndex=-1>
            <FONT face=Tahoma size=2><B>From:</B> lihu 
            [mailto:l12381@huawei.com] <BR><B>Sent:</B> Thursday, December 11, 
            2003 5:56 AM<BR><B>To:</B> Boyle, Kevin 
            [NCRTP:3Z40:EXCH]<BR><B>Subject:</B> About ICASCo 
            packages<BR></FONT><BR></DIV>
            <DIV></DIV>
            <DIV><FONT size=2>Dear sir,</FONT></DIV>
            <DIV><FONT size=2>&nbsp;&nbsp; In ICASCO package in 
            &lt;D-xxx_H.248.ICASC.doc&gt;,it describes 3 kinds of di collecting 
            .But the end of Digitmap and end of pulsing can induce some delay if 
            </FONT></DIV>
            <DIV><FONT size=2>MGC&nbsp; can't send a perfect Digitmap and the 
            peer can't send end of pulsing.</FONT></DIV>
            <DIV><FONT size=2>So a digit by digit way should be defined in 
            ICASCO package' di.</FONT></DIV>
            <DIV><FONT size=2></FONT>&nbsp;</DIV>
            <DIV><FONT size=2>Does it have any way to solve it ?</FONT></DIV>
            <DIV><FONT size=2></FONT>&nbsp;</DIV>
            <DIV><FONT size=2>Bestregards</FONT></DIV>
            <DIV>&nbsp;</DIV>
            <DIV><FONT size=2></FONT>&nbsp;</DIV>
            <DIV><FONT size=2>LiHu<BR>Huawei 
            co.,Ltd.<BR>86-10-82882747</FONT></DIV>
            <DIV>&nbsp;</DIV>
            <DIV><FONT 
            size=2>*****************************************************************<BR>This 
            e-mail and its attachments contain confidential information from 
            HUAWEI, which is intended only for the person or entity whose 
            address is listed above. Any use of the information contained herein 
            in any way (including, but not limited to, total or partial 
            disclosure, reproduction, or dissemination) by persons other than 
            the intended recipient(s) is prohibited. If you receive this e-mail 
            in error, please notify the sender by phone or email immediately and 
            delete 
            it!<BR>*****************************************************************<BR></FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_Wi+RP6fbr7tmb6hdHgD6wA)--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Jan  5 02:17:35 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04765
	for <megaco-archive@lists.ietf.org>; Mon, 5 Jan 2004 02:17:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdOz0-0004Mr-7x; Mon, 05 Jan 2004 02:17:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdOyk-0004LV-C7
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 02:16:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04666
	for <megaco@ietf.org>; Mon, 5 Jan 2004 02:16:38 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdOyW-00006j-00
	for megaco@ietf.org; Mon, 05 Jan 2004 02:16:32 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdOuS-0007mx-00
	for megaco@ietf.org; Mon, 05 Jan 2004 02:12:21 -0500
Received: from [81.1.223.5] (helo=itsib.ru)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdOqU-0007fE-00
	for megaco@ietf.org; Mon, 05 Jan 2004 02:08:15 -0500
Received: from denis_hd ([10.0.0.120])
	by itsib.ru (8.11.6/8.11.6) with ESMTP id i057B7V32765
	for <megaco@ietf.org>; Mon, 5 Jan 2004 13:11:07 +0600
Date: Mon, 5 Jan 2004 13:08:16 +0600
From: =?koi8-r?B?5MXOydMg79PBxN7Jyg==?= <osadchy@itsib.ru>
X-Mailer: The Bat! (v1.51) UNREG / CD5BF9353B3B7091
Reply-To: =?koi8-r?B?5MXOydMg79PBxN7Jyg==?= <osadchy@itsib.ru>
X-Priority: 3 (Normal)
Message-ID: <1811888015.20040105130816@itsib.ru>
To: megaco@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 8bit
Subject: [Megaco] initial value for normalMGCExecutionTime
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Hi,
what value I should use for normalMGCExecutionTime at the start when
sending registration message to MGC?
Denis



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Mon Jan  5 02:22:28 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05232
	for <megaco-archive@odin.ietf.org>; Mon, 5 Jan 2004 02:22:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdP3n-0004rW-Vt
	for megaco-archive@odin.ietf.org; Mon, 05 Jan 2004 02:22:00 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i057LxM5018689
	for megaco-archive@odin.ietf.org; Mon, 5 Jan 2004 02:21:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdP3n-0004rM-MQ
	for megaco-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 02:21:59 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05185
	for <megaco-web-archive@ietf.org>; Mon, 5 Jan 2004 02:21:57 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdP3X-0000Kx-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 02:21:43 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdP2W-0000E2-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 02:20:40 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdOzM-00008P-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 02:17:24 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdOz0-0004Mr-7x; Mon, 05 Jan 2004 02:17:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdOyk-0004LV-C7
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 02:16:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04666
	for <megaco@ietf.org>; Mon, 5 Jan 2004 02:16:38 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdOyW-00006j-00
	for megaco@ietf.org; Mon, 05 Jan 2004 02:16:32 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdOuS-0007mx-00
	for megaco@ietf.org; Mon, 05 Jan 2004 02:12:21 -0500
Received: from [81.1.223.5] (helo=itsib.ru)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdOqU-0007fE-00
	for megaco@ietf.org; Mon, 05 Jan 2004 02:08:15 -0500
Received: from denis_hd ([10.0.0.120])
	by itsib.ru (8.11.6/8.11.6) with ESMTP id i057B7V32765
	for <megaco@ietf.org>; Mon, 5 Jan 2004 13:11:07 +0600
Date: Mon, 5 Jan 2004 13:08:16 +0600
From: =?koi8-r?B?5MXOydMg79PBxN7Jyg==?= <osadchy@itsib.ru>
X-Mailer: The Bat! (v1.51) UNREG / CD5BF9353B3B7091
Reply-To: =?koi8-r?B?5MXOydMg79PBxN7Jyg==?= <osadchy@itsib.ru>
X-Priority: 3 (Normal)
Message-ID: <1811888015.20040105130816@itsib.ru>
To: megaco@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [Megaco] initial value for normalMGCExecutionTime
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi,
what value I should use for normalMGCExecutionTime at the start when
sending registration message to MGC?
Denis



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Jan  5 07:30:38 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15755
	for <megaco-archive@lists.ietf.org>; Mon, 5 Jan 2004 07:30:38 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdTrv-0001AK-Nr; Mon, 05 Jan 2004 07:30:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdTr9-00018M-G6
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 07:29:15 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15694
	for <megaco@ietf.org>; Mon, 5 Jan 2004 07:29:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdTr8-00003L-00
	for megaco@ietf.org; Mon, 05 Jan 2004 07:29:14 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdTpJ-0007Zq-00
	for megaco@ietf.org; Mon, 05 Jan 2004 07:27:26 -0500
Received: from ext-proxy-1.ftel.co.uk ([192.65.220.99])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdTmb-00073i-00
	for megaco@ietf.org; Mon, 05 Jan 2004 07:24:33 -0500
Received: from utility-1.ftel.co.uk (utility-1.ftel.co.uk [193.112.172.10])
	by ext-proxy-1.ftel.co.uk (8.12.10/8.12.9/Revision:1.91/relay-in/ssl/db) with ESMTP id i05CNAXi017615;
	Mon, 5 Jan 2004 12:23:11 GMT
Received: from DALLAPTOP (dhcp-172-16-48-64.ftel.co.uk [172.16.48.64])
	by utility-1.ftel.co.uk (8.12.9+Sun/8.12.9/Revision:1.90/db) with SMTP id i05CN3Nk004698;
	Mon, 5 Jan 2004 12:23:03 GMT
Message-ID: <009801c3d386$ab2baaf0$403010ac@DALLAPTOP>
From: "Dal Chohan" <D.Chohan@ftel.co.uk>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>,
        "Tom-PT Taylor" <taylor@nortelnetworks.com>, <gsachin@hss.hns.com>
Cc: <megaco@ietf.org>
References: <ABA227A15B80D511BD1A00508BF93A1C0D7AF882@zrtpd0jq.us.nortel.com>
Subject: Re: [Megaco] Query Related to Automatic Metering
Date: Mon, 5 Jan 2004 12:23:01 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0095_01C3D386.A92EC980"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.0 required=5.0 tests=EXCUSE_16,HTML_30_40,
	HTML_MESSAGE autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0095_01C3D386.A92EC980
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Shouldn't the clause 7.5 paragraph 5 procedures in the "amet" package be =
modified so that they don't override the standard Events =
Descriptor/KeepActive flag procedures defined in Megaco rather than =
specifying something in the Implementation Guide? I recommend that the =
offending sentence of clause 7.5 paragraph 5 "The detection of event pr =
shall not cause the termination of the signal em or signal mbp, even if =
the KeepActive flag is not set for the pr event" is deleted from the =
"amet" package.

In addition there is a similar problem with clause 7.5 paragraph 4 of =
the "amet" package which also potentially overrides the standard Megaco =
Events Descriptor/KeepActive flag and Signal Descriptor/KeepActive flag  =
procedures.

"If the value of the parameter pc is zero or if this parameter is not =
supplied by the MGC, then the repetitive application of metering pulses =
should continue until either an event (other than pr) is detected, or =
until the SignalsDescriptor is replaced with a new SignalsDescriptor =
that does not include the signal em. Any pulses applied due to a =
concurrent mpb signal shall be in addition to the required repetitive =
pulses applied for the em signal".

For example the meter pulses will continue even when an on-hook event is =
detected providing the events descriptor that armed the on-hook event =
had the KeepActive flag set. This action may be required for certain =
territories where all outstanding meter pulses must be delivered even =
when the analogue line is in the on-hook state.

Again the sentence above defining the SignalDescriptor procedures in the =
"amet" package does not define anything new which is not already =
specified in the standrad Megaco procedures. Hence I recommend that =
clause 7.5 paragraph 4 of the "amet" package be modified to read as:

"If the value of the parameter pc is zero or if this parameter is not =
supplied by the MGC, then any pulses applied due to a concurrent mpb =
signal shall be in addition to the required repetitive pulses applied =
for the em signal"



Regards,



Dal Chohan.



----- Original Message -----=20
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: "Tom-PT Taylor" <taylor@nortelnetworks.com>; <gsachin@hss.hns.com>
Cc: <megaco@ietf.org>
Sent: Friday, January 02, 2004 3:19 PM
Subject: RE: [Megaco] Query Related to Automatic Metering


> Do we need an IG item?  I can add one for the upcoming meeting, if we
> believe that this should be fixed.
>=20
> I would rather not have use of KA mandated.  Let the implementor =
decide how
> the event should interact with any signals.
>=20
> Kevin
>=20
> -----Original Message-----
> From: Taylor, Tom-PT [CAR:5N00:EXCH]=20
> Sent: Monday, December 22, 2003 11:53 AM
> To: gsachin@hss.hns.com
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Query Related to Automatic Metering
>=20
> I think you make a good point.  It's desirable to keep the protocol =
intact,
> rather than define exceptions within individual packages.
>=20
> gsachin@hss.hns.com wrote:
>=20
> >=20
> >=20
> >=20
> > Hi List,
> >=20
> >=20
> > this is a query regarding Periodic report event 'pr' defined in AMET =

> > package .the package procedure says that
> >=20
> > "the detection of event pr shall not cause the termination of the=20
> > signal em or signal mbp, even if the KeppActive(KA) flag is not set=20
> > for the pr event"
> >=20
> > what i feel is that the detection of the 'pr' event shall not cause=20
> > the termination of any of the signals.
> >=20
> > pls tell me if this is a correct assumption?
> >=20
> > if yes, then i think here the package procedures should have =
mandated=20
> > the use of KA flag with this event. Doing this will keep the =
protocol=20
> > rules intact.
> >=20
> >=20
> >=20
> > Regards
> > Sachin Gupta
> >=20
> > "DISCLAIMER: This message is proprietary to Hughes Software Systems=20
> > Limited
> > (HSS) and is intended solely for the use of the individual to whom =
it=20
> > is addressed. It may contain  privileged or confidential information =

> > and should not be circulated or used for any purpose other than for=20
> > what it is intended. If you have received this message in error,=20
> > please notify the originator immediately. If you are not the =
intended=20
> > recipient, you are notified that you are strictly prohibited from=20
> > using, copying, altering, or disclosing the contents of this =
message.=20
> > HSS accepts no responsibility for loss or damage arising from the =
use=20
> > of the information transmitted by this email including damage from =
virus."
> >=20
> >=20
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> >=20
>=20
>=20
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>=20
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 
------=_NextPart_000_0095_01C3D386.A92EC980
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV>Shouldn't the clause 7.5 paragraph 5 procedures in the "amet" =
package be=20
modified so that they don't override the standard Events =
Descriptor/KeepActive=20
flag procedures defined in Megaco rather than specifying something in =
the=20
Implementation Guide? I recommend that the offending sentence of clause =
7.5=20
paragraph 5 "The detection of event pr shall not cause the termination =
of the=20
signal em or signal mbp, even if the KeepActive flag is not set for the =
pr=20
event" is <STRONG><U>deleted</U></STRONG> from the "amet" package.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>In addition there is a similar problem with clause 7.5 paragraph 4 =
of the=20
"amet" package which also potentially overrides the standard Megaco =
Events=20
Descriptor/KeepActive flag&nbsp;and Signal Descriptor/KeepActive =
flag&nbsp;=20
procedures.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>"<FONT face=3D"Times New Roman" =
size=3D3>If the value=20
of the parameter pc is zero or if this parameter is not supplied by the =
MGC,=20
then the repetitive application of metering pulses should continue until =
either=20
an event (other than pr) is detected, or until the SignalsDescriptor is =
replaced=20
with a new SignalsDescriptor that does not include the signal em. <SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'MS Mincho'; =
mso-fareast-language: EN-US; mso-ansi-language: EN-US; =
mso-bidi-language: AR-SA">Any=20
pulses applied due to a concurrent mpb signal shall be in addition to =
the=20
required repetitive pulses applied for the em=20
signal</SPAN>".</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"=20
size=3D3></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>For example the=20
meter pulses will continue even when an on-hook event is detected =
providing the=20
events descriptor that armed the on-hook event&nbsp;had the KeepActive =
flag set.=20
This action may be required for certain territories where all =
outstanding meter=20
pulses must be delivered even when the analogue line is in the on-hook=20
state.</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial =
size=3D2></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>Again the=20
sentence above&nbsp;defining the SignalDescriptor procedures in the =
"amet"=20
package does not define anything new which is not already specified in =
the=20
standrad Megaco procedures. Hence I recommend that&nbsp;clause&nbsp;7.5=20
paragraph 4 of the "amet" package be modified to read =
as:</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial =
size=3D2></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3><STRONG>"If the=20
value of the parameter pc is zero or if this parameter is not supplied =
by the=20
MGC, then a<SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'MS Mincho'; =
mso-fareast-language: EN-US; mso-ansi-language: EN-US; =
mso-bidi-language: AR-SA">ny=20
pulses applied due to a concurrent mpb signal shall be in addition to =
the=20
required repetitive pulses applied for the em=20
signal"</SPAN></STRONG></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Dal Chohan.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>----- Original Message ----- </FONT>
<DIV><FONT face=3DArial size=3D2>From: "Kevin Boyle" &lt;</FONT><A=20
href=3D"mailto:kboyle@nortelnetworks.com"><FONT face=3DArial=20
size=3D2>kboyle@nortelnetworks.com</FONT></A><FONT face=3DArial=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>To: "Tom-PT Taylor" &lt;</FONT><A=20
href=3D"mailto:taylor@nortelnetworks.com"><FONT face=3DArial=20
size=3D2>taylor@nortelnetworks.com</FONT></A><FONT face=3DArial =
size=3D2>&gt;;=20
&lt;</FONT><A href=3D"mailto:gsachin@hss.hns.com"><FONT face=3DArial=20
size=3D2>gsachin@hss.hns.com</FONT></A><FONT face=3DArial =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Cc: &lt;</FONT><A=20
href=3D"mailto:megaco@ietf.org"><FONT face=3DArial=20
size=3D2>megaco@ietf.org</FONT></A><FONT face=3DArial =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Sent: Friday, January 02, 2004 3:19 =
PM</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Subject: RE: [Megaco] Query Related to =
Automatic=20
Metering</FONT></DIV></DIV>
<DIV><FONT face=3DArial><BR><FONT size=3D2></FONT></FONT></DIV><FONT =
face=3DArial=20
size=3D2>&gt; Do we need an IG item?&nbsp; I can add one for the =
upcoming meeting,=20
if we<BR>&gt; believe that this should be fixed.<BR>&gt; <BR>&gt; I =
would rather=20
not have use of KA mandated.&nbsp; Let the implementor decide =
how<BR>&gt; the=20
event should interact with any signals.<BR>&gt; <BR>&gt; Kevin<BR>&gt; =
<BR>&gt;=20
-----Original Message-----<BR>&gt; From: Taylor, Tom-PT [CAR:5N00:EXCH] =
<BR>&gt;=20
Sent: Monday, December 22, 2003 11:53 AM<BR>&gt; To: </FONT><A=20
href=3D"mailto:gsachin@hss.hns.com"><FONT face=3DArial=20
size=3D2>gsachin@hss.hns.com</FONT></A><BR><FONT face=3DArial =
size=3D2>&gt; Cc:=20
</FONT><A href=3D"mailto:megaco@ietf.org"><FONT face=3DArial=20
size=3D2>megaco@ietf.org</FONT></A><BR><FONT face=3DArial size=3D2>&gt; =
Subject: Re:=20
[Megaco] Query Related to Automatic Metering<BR>&gt; <BR>&gt; I think =
you make a=20
good point.&nbsp; It's desirable to keep the protocol intact,<BR>&gt; =
rather=20
than define exceptions within individual packages.<BR>&gt; <BR>&gt; =
</FONT><A=20
href=3D"mailto:gsachin@hss.hns.com"><FONT face=3DArial=20
size=3D2>gsachin@hss.hns.com</FONT></A><FONT face=3DArial size=3D2> =
wrote:<BR>&gt;=20
<BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; Hi List,<BR>&gt; =
&gt;=20
<BR>&gt; &gt; <BR>&gt; &gt; this is a query regarding Periodic report =
event 'pr'=20
defined in AMET <BR>&gt; &gt; package .the package procedure says =
that<BR>&gt;=20
&gt; <BR>&gt; &gt; "the detection of event pr shall not cause the =
termination of=20
the <BR>&gt; &gt; signal em or signal mbp, even if the KeppActive(KA) =
flag is=20
not set <BR>&gt; &gt; for the pr event"<BR>&gt; &gt; <BR>&gt; &gt; what =
i feel=20
is that the detection of the 'pr' event shall not cause <BR>&gt; &gt; =
the=20
termination of any of the signals.<BR>&gt; &gt; <BR>&gt; &gt; pls tell =
me if=20
this is a correct assumption?<BR>&gt; &gt; <BR>&gt; &gt; if yes, then i =
think=20
here the package procedures should have mandated <BR>&gt; &gt; the use =
of KA=20
flag with this event. Doing this will keep the protocol <BR>&gt; &gt; =
rules=20
intact.<BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; =
Regards<BR>&gt;=20
&gt; Sachin Gupta<BR>&gt; &gt; <BR>&gt; &gt; "DISCLAIMER: This message =
is=20
proprietary to Hughes Software Systems <BR>&gt; &gt; Limited<BR>&gt; =
&gt; (HSS)=20
and is intended solely for the use of the individual to whom it <BR>&gt; =
&gt; is=20
addressed. It may contain&nbsp; privileged or confidential information =
<BR>&gt;=20
&gt; and should not be circulated or used for any purpose other than for =

<BR>&gt; &gt; what it is intended. If you have received this message in =
error,=20
<BR>&gt; &gt; please notify the originator immediately. If you are not =
the=20
intended <BR>&gt; &gt; recipient, you are notified that you are strictly =

prohibited from <BR>&gt; &gt; using, copying, altering, or disclosing =
the=20
contents of this message. <BR>&gt; &gt; HSS accepts no responsibility =
for loss=20
or damage arising from the use <BR>&gt; &gt; of the information =
transmitted by=20
this email including damage from virus."<BR>&gt; &gt; <BR>&gt; &gt; =
<BR>&gt;=20
&gt; _______________________________________________<BR>&gt; &gt; Megaco =
mailing=20
list<BR>&gt; &gt; </FONT><A href=3D"mailto:Megaco@ietf.org"><FONT =
face=3DArial=20
size=3D2>Megaco@ietf.org</FONT></A><BR><FONT face=3DArial size=3D2>&gt; =
&gt; </FONT><A=20
href=3D"https://www1.ietf.org/mailman/listinfo/megaco"><FONT =
face=3DArial=20
size=3D2>https://www1.ietf.org/mailman/listinfo/megaco</FONT></A><BR><FON=
T=20
face=3DArial size=3D2>&gt; &gt; <BR>&gt; <BR>&gt; <BR>&gt;=20
_______________________________________________<BR>&gt; Megaco mailing=20
list<BR>&gt; </FONT><A href=3D"mailto:Megaco@ietf.org"><FONT =
face=3DArial=20
size=3D2>Megaco@ietf.org</FONT></A><BR><FONT face=3DArial size=3D2>&gt; =
</FONT><A=20
href=3D"https://www1.ietf.org/mailman/listinfo/megaco"><FONT =
face=3DArial=20
size=3D2>https://www1.ietf.org/mailman/listinfo/megaco</FONT></A><BR><FON=
T=20
face=3DArial size=3D2>&gt; <BR>&gt;=20
_______________________________________________<BR>&gt; Megaco mailing=20
list<BR>&gt; </FONT><A href=3D"mailto:Megaco@ietf.org"><FONT =
face=3DArial=20
size=3D2>Megaco@ietf.org</FONT></A><BR><FONT face=3DArial size=3D2>&gt; =
</FONT><A=20
href=3D"https://www1.ietf.org/mailman/listinfo/megaco"><FONT =
face=3DArial=20
size=3D2>https://www1.ietf.org/mailman/listinfo/megaco</FONT></A><BR><FON=
T=20
face=3DArial size=3D2>&gt; </FONT></BODY></HTML>

------=_NextPart_000_0095_01C3D386.A92EC980--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Mon Jan  5 07:33:52 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15960
	for <megaco-archive@odin.ietf.org>; Mon, 5 Jan 2004 07:33:52 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdTv8-0001KT-46
	for megaco-archive@odin.ietf.org; Mon, 05 Jan 2004 07:33:22 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i05CXMgp005105
	for megaco-archive@odin.ietf.org; Mon, 5 Jan 2004 07:33:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdTv7-0001KE-Te
	for megaco-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 07:33:21 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15951
	for <megaco-web-archive@ietf.org>; Mon, 5 Jan 2004 07:33:20 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdTv7-0000JE-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 07:33:21 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdTtO-0000FG-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 07:31:36 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdTs1-00009c-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 07:30:09 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdTrv-0001AK-Nr; Mon, 05 Jan 2004 07:30:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdTr9-00018M-G6
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 07:29:15 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15694
	for <megaco@ietf.org>; Mon, 5 Jan 2004 07:29:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdTr8-00003L-00
	for megaco@ietf.org; Mon, 05 Jan 2004 07:29:14 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdTpJ-0007Zq-00
	for megaco@ietf.org; Mon, 05 Jan 2004 07:27:26 -0500
Received: from ext-proxy-1.ftel.co.uk ([192.65.220.99])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdTmb-00073i-00
	for megaco@ietf.org; Mon, 05 Jan 2004 07:24:33 -0500
Received: from utility-1.ftel.co.uk (utility-1.ftel.co.uk [193.112.172.10])
	by ext-proxy-1.ftel.co.uk (8.12.10/8.12.9/Revision:1.91/relay-in/ssl/db) with ESMTP id i05CNAXi017615;
	Mon, 5 Jan 2004 12:23:11 GMT
Received: from DALLAPTOP (dhcp-172-16-48-64.ftel.co.uk [172.16.48.64])
	by utility-1.ftel.co.uk (8.12.9+Sun/8.12.9/Revision:1.90/db) with SMTP id i05CN3Nk004698;
	Mon, 5 Jan 2004 12:23:03 GMT
Message-ID: <009801c3d386$ab2baaf0$403010ac@DALLAPTOP>
From: "Dal Chohan" <D.Chohan@ftel.co.uk>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>,
        "Tom-PT Taylor" <taylor@nortelnetworks.com>, <gsachin@hss.hns.com>
Cc: <megaco@ietf.org>
References: <ABA227A15B80D511BD1A00508BF93A1C0D7AF882@zrtpd0jq.us.nortel.com>
Subject: Re: [Megaco] Query Related to Automatic Metering
Date: Mon, 5 Jan 2004 12:23:01 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0095_01C3D386.A92EC980"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,EXCUSE_16,HTML_30_40,
	HTML_MESSAGE autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_0095_01C3D386.A92EC980
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Shouldn't the clause 7.5 paragraph 5 procedures in the "amet" package be =
modified so that they don't override the standard Events =
Descriptor/KeepActive flag procedures defined in Megaco rather than =
specifying something in the Implementation Guide? I recommend that the =
offending sentence of clause 7.5 paragraph 5 "The detection of event pr =
shall not cause the termination of the signal em or signal mbp, even if =
the KeepActive flag is not set for the pr event" is deleted from the =
"amet" package.

In addition there is a similar problem with clause 7.5 paragraph 4 of =
the "amet" package which also potentially overrides the standard Megaco =
Events Descriptor/KeepActive flag and Signal Descriptor/KeepActive flag  =
procedures.

"If the value of the parameter pc is zero or if this parameter is not =
supplied by the MGC, then the repetitive application of metering pulses =
should continue until either an event (other than pr) is detected, or =
until the SignalsDescriptor is replaced with a new SignalsDescriptor =
that does not include the signal em. Any pulses applied due to a =
concurrent mpb signal shall be in addition to the required repetitive =
pulses applied for the em signal".

For example the meter pulses will continue even when an on-hook event is =
detected providing the events descriptor that armed the on-hook event =
had the KeepActive flag set. This action may be required for certain =
territories where all outstanding meter pulses must be delivered even =
when the analogue line is in the on-hook state.

Again the sentence above defining the SignalDescriptor procedures in the =
"amet" package does not define anything new which is not already =
specified in the standrad Megaco procedures. Hence I recommend that =
clause 7.5 paragraph 4 of the "amet" package be modified to read as:

"If the value of the parameter pc is zero or if this parameter is not =
supplied by the MGC, then any pulses applied due to a concurrent mpb =
signal shall be in addition to the required repetitive pulses applied =
for the em signal"



Regards,



Dal Chohan.



----- Original Message -----=20
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: "Tom-PT Taylor" <taylor@nortelnetworks.com>; <gsachin@hss.hns.com>
Cc: <megaco@ietf.org>
Sent: Friday, January 02, 2004 3:19 PM
Subject: RE: [Megaco] Query Related to Automatic Metering


> Do we need an IG item?  I can add one for the upcoming meeting, if we
> believe that this should be fixed.
>=20
> I would rather not have use of KA mandated.  Let the implementor =
decide how
> the event should interact with any signals.
>=20
> Kevin
>=20
> -----Original Message-----
> From: Taylor, Tom-PT [CAR:5N00:EXCH]=20
> Sent: Monday, December 22, 2003 11:53 AM
> To: gsachin@hss.hns.com
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Query Related to Automatic Metering
>=20
> I think you make a good point.  It's desirable to keep the protocol =
intact,
> rather than define exceptions within individual packages.
>=20
> gsachin@hss.hns.com wrote:
>=20
> >=20
> >=20
> >=20
> > Hi List,
> >=20
> >=20
> > this is a query regarding Periodic report event 'pr' defined in AMET =

> > package .the package procedure says that
> >=20
> > "the detection of event pr shall not cause the termination of the=20
> > signal em or signal mbp, even if the KeppActive(KA) flag is not set=20
> > for the pr event"
> >=20
> > what i feel is that the detection of the 'pr' event shall not cause=20
> > the termination of any of the signals.
> >=20
> > pls tell me if this is a correct assumption?
> >=20
> > if yes, then i think here the package procedures should have =
mandated=20
> > the use of KA flag with this event. Doing this will keep the =
protocol=20
> > rules intact.
> >=20
> >=20
> >=20
> > Regards
> > Sachin Gupta
> >=20
> > "DISCLAIMER: This message is proprietary to Hughes Software Systems=20
> > Limited
> > (HSS) and is intended solely for the use of the individual to whom =
it=20
> > is addressed. It may contain  privileged or confidential information =

> > and should not be circulated or used for any purpose other than for=20
> > what it is intended. If you have received this message in error,=20
> > please notify the originator immediately. If you are not the =
intended=20
> > recipient, you are notified that you are strictly prohibited from=20
> > using, copying, altering, or disclosing the contents of this =
message.=20
> > HSS accepts no responsibility for loss or damage arising from the =
use=20
> > of the information transmitted by this email including damage from =
virus."
> >=20
> >=20
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> >=20
>=20
>=20
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>=20
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 
------=_NextPart_000_0095_01C3D386.A92EC980
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV>Shouldn't the clause 7.5 paragraph 5 procedures in the "amet" =
package be=20
modified so that they don't override the standard Events =
Descriptor/KeepActive=20
flag procedures defined in Megaco rather than specifying something in =
the=20
Implementation Guide? I recommend that the offending sentence of clause =
7.5=20
paragraph 5 "The detection of event pr shall not cause the termination =
of the=20
signal em or signal mbp, even if the KeepActive flag is not set for the =
pr=20
event" is <STRONG><U>deleted</U></STRONG> from the "amet" package.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>In addition there is a similar problem with clause 7.5 paragraph 4 =
of the=20
"amet" package which also potentially overrides the standard Megaco =
Events=20
Descriptor/KeepActive flag&nbsp;and Signal Descriptor/KeepActive =
flag&nbsp;=20
procedures.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>"<FONT face=3D"Times New Roman" =
size=3D3>If the value=20
of the parameter pc is zero or if this parameter is not supplied by the =
MGC,=20
then the repetitive application of metering pulses should continue until =
either=20
an event (other than pr) is detected, or until the SignalsDescriptor is =
replaced=20
with a new SignalsDescriptor that does not include the signal em. <SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'MS Mincho'; =
mso-fareast-language: EN-US; mso-ansi-language: EN-US; =
mso-bidi-language: AR-SA">Any=20
pulses applied due to a concurrent mpb signal shall be in addition to =
the=20
required repetitive pulses applied for the em=20
signal</SPAN>".</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"=20
size=3D3></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>For example the=20
meter pulses will continue even when an on-hook event is detected =
providing the=20
events descriptor that armed the on-hook event&nbsp;had the KeepActive =
flag set.=20
This action may be required for certain territories where all =
outstanding meter=20
pulses must be delivered even when the analogue line is in the on-hook=20
state.</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial =
size=3D2></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>Again the=20
sentence above&nbsp;defining the SignalDescriptor procedures in the =
"amet"=20
package does not define anything new which is not already specified in =
the=20
standrad Megaco procedures. Hence I recommend that&nbsp;clause&nbsp;7.5=20
paragraph 4 of the "amet" package be modified to read =
as:</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial =
size=3D2></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3><STRONG>"If the=20
value of the parameter pc is zero or if this parameter is not supplied =
by the=20
MGC, then a<SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'MS Mincho'; =
mso-fareast-language: EN-US; mso-ansi-language: EN-US; =
mso-bidi-language: AR-SA">ny=20
pulses applied due to a concurrent mpb signal shall be in addition to =
the=20
required repetitive pulses applied for the em=20
signal"</SPAN></STRONG></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Dal Chohan.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>----- Original Message ----- </FONT>
<DIV><FONT face=3DArial size=3D2>From: "Kevin Boyle" &lt;</FONT><A=20
href=3D"mailto:kboyle@nortelnetworks.com"><FONT face=3DArial=20
size=3D2>kboyle@nortelnetworks.com</FONT></A><FONT face=3DArial=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>To: "Tom-PT Taylor" &lt;</FONT><A=20
href=3D"mailto:taylor@nortelnetworks.com"><FONT face=3DArial=20
size=3D2>taylor@nortelnetworks.com</FONT></A><FONT face=3DArial =
size=3D2>&gt;;=20
&lt;</FONT><A href=3D"mailto:gsachin@hss.hns.com"><FONT face=3DArial=20
size=3D2>gsachin@hss.hns.com</FONT></A><FONT face=3DArial =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Cc: &lt;</FONT><A=20
href=3D"mailto:megaco@ietf.org"><FONT face=3DArial=20
size=3D2>megaco@ietf.org</FONT></A><FONT face=3DArial =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Sent: Friday, January 02, 2004 3:19 =
PM</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Subject: RE: [Megaco] Query Related to =
Automatic=20
Metering</FONT></DIV></DIV>
<DIV><FONT face=3DArial><BR><FONT size=3D2></FONT></FONT></DIV><FONT =
face=3DArial=20
size=3D2>&gt; Do we need an IG item?&nbsp; I can add one for the =
upcoming meeting,=20
if we<BR>&gt; believe that this should be fixed.<BR>&gt; <BR>&gt; I =
would rather=20
not have use of KA mandated.&nbsp; Let the implementor decide =
how<BR>&gt; the=20
event should interact with any signals.<BR>&gt; <BR>&gt; Kevin<BR>&gt; =
<BR>&gt;=20
-----Original Message-----<BR>&gt; From: Taylor, Tom-PT [CAR:5N00:EXCH] =
<BR>&gt;=20
Sent: Monday, December 22, 2003 11:53 AM<BR>&gt; To: </FONT><A=20
href=3D"mailto:gsachin@hss.hns.com"><FONT face=3DArial=20
size=3D2>gsachin@hss.hns.com</FONT></A><BR><FONT face=3DArial =
size=3D2>&gt; Cc:=20
</FONT><A href=3D"mailto:megaco@ietf.org"><FONT face=3DArial=20
size=3D2>megaco@ietf.org</FONT></A><BR><FONT face=3DArial size=3D2>&gt; =
Subject: Re:=20
[Megaco] Query Related to Automatic Metering<BR>&gt; <BR>&gt; I think =
you make a=20
good point.&nbsp; It's desirable to keep the protocol intact,<BR>&gt; =
rather=20
than define exceptions within individual packages.<BR>&gt; <BR>&gt; =
</FONT><A=20
href=3D"mailto:gsachin@hss.hns.com"><FONT face=3DArial=20
size=3D2>gsachin@hss.hns.com</FONT></A><FONT face=3DArial size=3D2> =
wrote:<BR>&gt;=20
<BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; Hi List,<BR>&gt; =
&gt;=20
<BR>&gt; &gt; <BR>&gt; &gt; this is a query regarding Periodic report =
event 'pr'=20
defined in AMET <BR>&gt; &gt; package .the package procedure says =
that<BR>&gt;=20
&gt; <BR>&gt; &gt; "the detection of event pr shall not cause the =
termination of=20
the <BR>&gt; &gt; signal em or signal mbp, even if the KeppActive(KA) =
flag is=20
not set <BR>&gt; &gt; for the pr event"<BR>&gt; &gt; <BR>&gt; &gt; what =
i feel=20
is that the detection of the 'pr' event shall not cause <BR>&gt; &gt; =
the=20
termination of any of the signals.<BR>&gt; &gt; <BR>&gt; &gt; pls tell =
me if=20
this is a correct assumption?<BR>&gt; &gt; <BR>&gt; &gt; if yes, then i =
think=20
here the package procedures should have mandated <BR>&gt; &gt; the use =
of KA=20
flag with this event. Doing this will keep the protocol <BR>&gt; &gt; =
rules=20
intact.<BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; =
Regards<BR>&gt;=20
&gt; Sachin Gupta<BR>&gt; &gt; <BR>&gt; &gt; "DISCLAIMER: This message =
is=20
proprietary to Hughes Software Systems <BR>&gt; &gt; Limited<BR>&gt; =
&gt; (HSS)=20
and is intended solely for the use of the individual to whom it <BR>&gt; =
&gt; is=20
addressed. It may contain&nbsp; privileged or confidential information =
<BR>&gt;=20
&gt; and should not be circulated or used for any purpose other than for =

<BR>&gt; &gt; what it is intended. If you have received this message in =
error,=20
<BR>&gt; &gt; please notify the originator immediately. If you are not =
the=20
intended <BR>&gt; &gt; recipient, you are notified that you are strictly =

prohibited from <BR>&gt; &gt; using, copying, altering, or disclosing =
the=20
contents of this message. <BR>&gt; &gt; HSS accepts no responsibility =
for loss=20
or damage arising from the use <BR>&gt; &gt; of the information =
transmitted by=20
this email including damage from virus."<BR>&gt; &gt; <BR>&gt; &gt; =
<BR>&gt;=20
&gt; _______________________________________________<BR>&gt; &gt; Megaco =
mailing=20
list<BR>&gt; &gt; </FONT><A href=3D"mailto:Megaco@ietf.org"><FONT =
face=3DArial=20
size=3D2>Megaco@ietf.org</FONT></A><BR><FONT face=3DArial size=3D2>&gt; =
&gt; </FONT><A=20
href=3D"https://www1.ietf.org/mailman/listinfo/megaco"><FONT =
face=3DArial=20
size=3D2>https://www1.ietf.org/mailman/listinfo/megaco</FONT></A><BR><FON=
T=20
face=3DArial size=3D2>&gt; &gt; <BR>&gt; <BR>&gt; <BR>&gt;=20
_______________________________________________<BR>&gt; Megaco mailing=20
list<BR>&gt; </FONT><A href=3D"mailto:Megaco@ietf.org"><FONT =
face=3DArial=20
size=3D2>Megaco@ietf.org</FONT></A><BR><FONT face=3DArial size=3D2>&gt; =
</FONT><A=20
href=3D"https://www1.ietf.org/mailman/listinfo/megaco"><FONT =
face=3DArial=20
size=3D2>https://www1.ietf.org/mailman/listinfo/megaco</FONT></A><BR><FON=
T=20
face=3DArial size=3D2>&gt; <BR>&gt;=20
_______________________________________________<BR>&gt; Megaco mailing=20
list<BR>&gt; </FONT><A href=3D"mailto:Megaco@ietf.org"><FONT =
face=3DArial=20
size=3D2>Megaco@ietf.org</FONT></A><BR><FONT face=3DArial size=3D2>&gt; =
</FONT><A=20
href=3D"https://www1.ietf.org/mailman/listinfo/megaco"><FONT =
face=3DArial=20
size=3D2>https://www1.ietf.org/mailman/listinfo/megaco</FONT></A><BR><FON=
T=20
face=3DArial size=3D2>&gt; </FONT></BODY></HTML>

------=_NextPart_000_0095_01C3D386.A92EC980--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Jan  5 10:17:50 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20297
	for <megaco-archive@lists.ietf.org>; Mon, 5 Jan 2004 10:17:50 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdWTW-0006bo-CN; Mon, 05 Jan 2004 10:17:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdWSj-0006aY-3m
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 10:16:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20123
	for <megaco@ietf.org>; Mon, 5 Jan 2004 10:16:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdWSW-0006Bl-00
	for megaco@ietf.org; Mon, 05 Jan 2004 10:16:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdWOR-000632-00
	for megaco@ietf.org; Mon, 05 Jan 2004 10:11:48 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdWKB-0005sH-00
	for megaco@ietf.org; Mon, 05 Jan 2004 10:07:23 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i05F6Qj24336
	for <megaco@ietf.org>; Mon, 5 Jan 2004 10:06:26 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y10TH9>; Mon, 5 Jan 2004 10:06:27 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D85ADF5@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Dal Chohan <D.Chohan@ftel.co.uk>,
        "Tom-PT Taylor" <taylor@nortelnetworks.com>, gsachin@hss.hns.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Query Related to Automatic Metering
Date: Mon, 5 Jan 2004 10:06:24 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,EXCUSE_16 autolearn=no 
	version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

The way to correct Recommendations in the H.248 subseries is to insert an
item in the IG for that Recommendation.  This would go in the IG in a
chapter for H.248.26.  More comments inline. [KJBII]
 
Kevin


  _____  

From: Dal Chohan [mailto:D.Chohan@ftel.co.uk] 
Sent: Monday, January 05, 2004 7:23 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH];
gsachin@hss.hns.com
Cc: megaco@ietf.org
Subject: Re: [Megaco] Query Related to Automatic Metering


Shouldn't the clause 7.5 paragraph 5 procedures in the "amet" package be
modified so that they don't override the standard Events
Descriptor/KeepActive flag procedures defined in Megaco rather than
specifying something in the Implementation Guide? I recommend that the
offending sentence of clause 7.5 paragraph 5 "The detection of event pr
shall not cause the termination of the signal em or signal mbp, even if the
KeepActive flag is not set for the pr event" is deleted from the "amet"
package.
[KJBII] See above. 
 
In addition there is a similar problem with clause 7.5 paragraph 4 of the
"amet" package which also potentially overrides the standard Megaco Events
Descriptor/KeepActive flag and Signal Descriptor/KeepActive flag
procedures.
 
"If the value of the parameter pc is zero or if this parameter is not
supplied by the MGC, then the repetitive application of metering pulses
should continue until either an event (other than pr) is detected, or until
the SignalsDescriptor is replaced with a new SignalsDescriptor that does not
include the signal em. Any pulses applied due to a concurrent mpb signal
shall be in addition to the required repetitive pulses applied for the em
signal".
 
For example the meter pulses will continue even when an on-hook event is
detected providing the events descriptor that armed the on-hook event had
the KeepActive flag set. This action may be required for certain territories
where all outstanding meter pulses must be delivered even when the analogue
line is in the on-hook state.
[KJBII] I'm not sure what this example has to do with the problem mentioned
above -- the package already functions this way. 
 
Again the sentence above defining the SignalDescriptor procedures in the
"amet" package does not define anything new which is not already specified
in the standrad Megaco procedures. Hence I recommend that clause 7.5
paragraph 4 of the "amet" package be modified to read as:
 
"If the value of the parameter pc is zero or if this parameter is not
supplied by the MGC, then any pulses applied due to a concurrent mpb signal
shall be in addition to the required repetitive pulses applied for the em
signal"
[KJBII] This would be a natural extension of the above correction. 
 
 
 
Regards,
 
 
 
Dal Chohan.
 
 
 
----- Original Message ----- 
From: "Kevin Boyle" < <mailto:kboyle@nortelnetworks.com>
kboyle@nortelnetworks.com>
To: "Tom-PT Taylor" < <mailto:taylor@nortelnetworks.com>
taylor@nortelnetworks.com>; < <mailto:gsachin@hss.hns.com>
gsachin@hss.hns.com>
Cc: < <mailto:megaco@ietf.org> megaco@ietf.org>
Sent: Friday, January 02, 2004 3:19 PM
Subject: RE: [Megaco] Query Related to Automatic Metering


> Do we need an IG item?  I can add one for the upcoming meeting, if we
> believe that this should be fixed.
> 
> I would rather not have use of KA mandated.  Let the implementor decide
how
> the event should interact with any signals.
> 
> Kevin
> 
> -----Original Message-----
> From: Taylor, Tom-PT [CAR:5N00:EXCH] 
> Sent: Monday, December 22, 2003 11:53 AM
> To:  <mailto:gsachin@hss.hns.com> gsachin@hss.hns.com
> Cc:  <mailto:megaco@ietf.org> megaco@ietf.org
> Subject: Re: [Megaco] Query Related to Automatic Metering
> 
> I think you make a good point.  It's desirable to keep the protocol
intact,
> rather than define exceptions within individual packages.
> 
>  <mailto:gsachin@hss.hns.com> gsachin@hss.hns.com wrote:
> 
> > 
> > 
> > 
> > Hi List,
> > 
> > 
> > this is a query regarding Periodic report event 'pr' defined in AMET 
> > package .the package procedure says that
> > 
> > "the detection of event pr shall not cause the termination of the 
> > signal em or signal mbp, even if the KeppActive(KA) flag is not set 
> > for the pr event"
> > 
> > what i feel is that the detection of the 'pr' event shall not cause 
> > the termination of any of the signals.
> > 
> > pls tell me if this is a correct assumption?
> > 
> > if yes, then i think here the package procedures should have mandated 
> > the use of KA flag with this event. Doing this will keep the protocol 
> > rules intact.
> > 
> > 
> > 
> > Regards
> > Sachin Gupta
> > 
> > "DISCLAIMER: This message is proprietary to Hughes Software Systems 
> > Limited
> > (HSS) and is intended solely for the use of the individual to whom it 
> > is addressed. It may contain  privileged or confidential information 
> > and should not be circulated or used for any purpose other than for 
> > what it is intended. If you have received this message in error, 
> > please notify the originator immediately. If you are not the intended 
> > recipient, you are notified that you are strictly prohibited from 
> > using, copying, altering, or disclosing the contents of this message. 
> > HSS accepts no responsibility for loss or damage arising from the use 
> > of the information transmitted by this email including damage from
virus."
> > 
> > 
> > _______________________________________________
> > Megaco mailing list
> >  <mailto:Megaco@ietf.org> Megaco@ietf.org
> >  <https://www1.ietf.org/mailman/listinfo/megaco>
https://www1.ietf.org/mailman/listinfo/megaco
> > 
> 
> 
> _______________________________________________
> Megaco mailing list
>  <mailto:Megaco@ietf.org> Megaco@ietf.org
>  <https://www1.ietf.org/mailman/listinfo/megaco>
https://www1.ietf.org/mailman/listinfo/megaco
> 
> _______________________________________________
> Megaco mailing list
>  <mailto:Megaco@ietf.org> Megaco@ietf.org
>  <https://www1.ietf.org/mailman/listinfo/megaco>
https://www1.ietf.org/mailman/listinfo/megaco
> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Mon Jan  5 10:28:36 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20773
	for <megaco-archive@odin.ietf.org>; Mon, 5 Jan 2004 10:28:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdWeH-00076x-GB
	for megaco-archive@odin.ietf.org; Mon, 05 Jan 2004 10:28:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i05FS9pI027331
	for megaco-archive@odin.ietf.org; Mon, 5 Jan 2004 10:28:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdWeH-00076k-Cp
	for megaco-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 10:28:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20650
	for <megaco-web-archive@ietf.org>; Mon, 5 Jan 2004 10:28:05 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdWeE-0006iI-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 10:28:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdWb0-0006Um-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 10:24:47 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdWUA-0006FH-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 10:17:42 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdWTW-0006bo-CN; Mon, 05 Jan 2004 10:17:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdWSj-0006aY-3m
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 10:16:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20123
	for <megaco@ietf.org>; Mon, 5 Jan 2004 10:16:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdWSW-0006Bl-00
	for megaco@ietf.org; Mon, 05 Jan 2004 10:16:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdWOR-000632-00
	for megaco@ietf.org; Mon, 05 Jan 2004 10:11:48 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdWKB-0005sH-00
	for megaco@ietf.org; Mon, 05 Jan 2004 10:07:23 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i05F6Qj24336
	for <megaco@ietf.org>; Mon, 5 Jan 2004 10:06:26 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y10TH9>; Mon, 5 Jan 2004 10:06:27 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D85ADF5@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Dal Chohan <D.Chohan@ftel.co.uk>,
        "Tom-PT Taylor" <taylor@nortelnetworks.com>, gsachin@hss.hns.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Query Related to Automatic Metering
Date: Mon, 5 Jan 2004 10:06:24 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,EXCUSE_16 autolearn=no 
	version=2.60

The way to correct Recommendations in the H.248 subseries is to insert an
item in the IG for that Recommendation.  This would go in the IG in a
chapter for H.248.26.  More comments inline. [KJBII]
 
Kevin


  _____  

From: Dal Chohan [mailto:D.Chohan@ftel.co.uk] 
Sent: Monday, January 05, 2004 7:23 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH];
gsachin@hss.hns.com
Cc: megaco@ietf.org
Subject: Re: [Megaco] Query Related to Automatic Metering


Shouldn't the clause 7.5 paragraph 5 procedures in the "amet" package be
modified so that they don't override the standard Events
Descriptor/KeepActive flag procedures defined in Megaco rather than
specifying something in the Implementation Guide? I recommend that the
offending sentence of clause 7.5 paragraph 5 "The detection of event pr
shall not cause the termination of the signal em or signal mbp, even if the
KeepActive flag is not set for the pr event" is deleted from the "amet"
package.
[KJBII] See above. 
 
In addition there is a similar problem with clause 7.5 paragraph 4 of the
"amet" package which also potentially overrides the standard Megaco Events
Descriptor/KeepActive flag and Signal Descriptor/KeepActive flag
procedures.
 
"If the value of the parameter pc is zero or if this parameter is not
supplied by the MGC, then the repetitive application of metering pulses
should continue until either an event (other than pr) is detected, or until
the SignalsDescriptor is replaced with a new SignalsDescriptor that does not
include the signal em. Any pulses applied due to a concurrent mpb signal
shall be in addition to the required repetitive pulses applied for the em
signal".
 
For example the meter pulses will continue even when an on-hook event is
detected providing the events descriptor that armed the on-hook event had
the KeepActive flag set. This action may be required for certain territories
where all outstanding meter pulses must be delivered even when the analogue
line is in the on-hook state.
[KJBII] I'm not sure what this example has to do with the problem mentioned
above -- the package already functions this way. 
 
Again the sentence above defining the SignalDescriptor procedures in the
"amet" package does not define anything new which is not already specified
in the standrad Megaco procedures. Hence I recommend that clause 7.5
paragraph 4 of the "amet" package be modified to read as:
 
"If the value of the parameter pc is zero or if this parameter is not
supplied by the MGC, then any pulses applied due to a concurrent mpb signal
shall be in addition to the required repetitive pulses applied for the em
signal"
[KJBII] This would be a natural extension of the above correction. 
 
 
 
Regards,
 
 
 
Dal Chohan.
 
 
 
----- Original Message ----- 
From: "Kevin Boyle" < <mailto:kboyle@nortelnetworks.com>
kboyle@nortelnetworks.com>
To: "Tom-PT Taylor" < <mailto:taylor@nortelnetworks.com>
taylor@nortelnetworks.com>; < <mailto:gsachin@hss.hns.com>
gsachin@hss.hns.com>
Cc: < <mailto:megaco@ietf.org> megaco@ietf.org>
Sent: Friday, January 02, 2004 3:19 PM
Subject: RE: [Megaco] Query Related to Automatic Metering


> Do we need an IG item?  I can add one for the upcoming meeting, if we
> believe that this should be fixed.
> 
> I would rather not have use of KA mandated.  Let the implementor decide
how
> the event should interact with any signals.
> 
> Kevin
> 
> -----Original Message-----
> From: Taylor, Tom-PT [CAR:5N00:EXCH] 
> Sent: Monday, December 22, 2003 11:53 AM
> To:  <mailto:gsachin@hss.hns.com> gsachin@hss.hns.com
> Cc:  <mailto:megaco@ietf.org> megaco@ietf.org
> Subject: Re: [Megaco] Query Related to Automatic Metering
> 
> I think you make a good point.  It's desirable to keep the protocol
intact,
> rather than define exceptions within individual packages.
> 
>  <mailto:gsachin@hss.hns.com> gsachin@hss.hns.com wrote:
> 
> > 
> > 
> > 
> > Hi List,
> > 
> > 
> > this is a query regarding Periodic report event 'pr' defined in AMET 
> > package .the package procedure says that
> > 
> > "the detection of event pr shall not cause the termination of the 
> > signal em or signal mbp, even if the KeppActive(KA) flag is not set 
> > for the pr event"
> > 
> > what i feel is that the detection of the 'pr' event shall not cause 
> > the termination of any of the signals.
> > 
> > pls tell me if this is a correct assumption?
> > 
> > if yes, then i think here the package procedures should have mandated 
> > the use of KA flag with this event. Doing this will keep the protocol 
> > rules intact.
> > 
> > 
> > 
> > Regards
> > Sachin Gupta
> > 
> > "DISCLAIMER: This message is proprietary to Hughes Software Systems 
> > Limited
> > (HSS) and is intended solely for the use of the individual to whom it 
> > is addressed. It may contain  privileged or confidential information 
> > and should not be circulated or used for any purpose other than for 
> > what it is intended. If you have received this message in error, 
> > please notify the originator immediately. If you are not the intended 
> > recipient, you are notified that you are strictly prohibited from 
> > using, copying, altering, or disclosing the contents of this message. 
> > HSS accepts no responsibility for loss or damage arising from the use 
> > of the information transmitted by this email including damage from
virus."
> > 
> > 
> > _______________________________________________
> > Megaco mailing list
> >  <mailto:Megaco@ietf.org> Megaco@ietf.org
> >  <https://www1.ietf.org/mailman/listinfo/megaco>
https://www1.ietf.org/mailman/listinfo/megaco
> > 
> 
> 
> _______________________________________________
> Megaco mailing list
>  <mailto:Megaco@ietf.org> Megaco@ietf.org
>  <https://www1.ietf.org/mailman/listinfo/megaco>
https://www1.ietf.org/mailman/listinfo/megaco
> 
> _______________________________________________
> Megaco mailing list
>  <mailto:Megaco@ietf.org> Megaco@ietf.org
>  <https://www1.ietf.org/mailman/listinfo/megaco>
https://www1.ietf.org/mailman/listinfo/megaco
> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Jan  5 10:42:31 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21370
	for <megaco-archive@lists.ietf.org>; Mon, 5 Jan 2004 10:42:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdWrh-0007qX-Id; Mon, 05 Jan 2004 10:42:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdWqy-0007pB-Hz
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 10:41:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21357
	for <megaco@ietf.org>; Mon, 5 Jan 2004 10:41:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdWqw-0007Ev-00
	for megaco@ietf.org; Mon, 05 Jan 2004 10:41:14 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdWp4-0007CD-00
	for megaco@ietf.org; Mon, 05 Jan 2004 10:39:21 -0500
Received: from ext-proxy-2.ftel.co.uk ([192.65.220.98])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdWnn-00079q-00
	for megaco@ietf.org; Mon, 05 Jan 2004 10:37:59 -0500
Received: from utility-1.ftel.co.uk (utility-1.ftel.co.uk [193.112.172.10])
	by ext-proxy-2.ftel.co.uk (8.12.10/8.12.9/Revision:1.91/relay-in/ssl/db) with ESMTP id i05Fb5Mu007803;
	Mon, 5 Jan 2004 15:37:06 GMT
Received: from DALLAPTOP (dhcp-172-16-48-64.ftel.co.uk [172.16.48.64])
	by utility-1.ftel.co.uk (8.12.9+Sun/8.12.9/Revision:1.90/db) with SMTP id i05FaxNk011053;
	Mon, 5 Jan 2004 15:36:59 GMT
Message-ID: <00ef01c3d3a1$c2d4b0a0$403010ac@DALLAPTOP>
From: "Dal Chohan" <D.Chohan@ftel.co.uk>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>,
        "Tom-PT Taylor" <taylor@nortelnetworks.com>, <gsachin@hss.hns.com>
Cc: <megaco@ietf.org>
References: <ABA227A15B80D511BD1A00508BF93A1C0D85ADF5@zrtpd0jq.us.nortel.com>
Subject: Re: [Megaco] Query Related to Automatic Metering
Date: Mon, 5 Jan 2004 15:36:57 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00EC_01C3D3A1.C0F653B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,EXCUSE_16,HTML_30_40,
	HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_MESSAGE autolearn=no 
	version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00EC_01C3D3A1.C0F653B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Please can you specify what text you will be including in the IG - Also =
see in-line comments.,


Regards,


Dal Chohan
  ----- Original Message -----=20
  From: Kevin Boyle=20
  To: Dal Chohan ; Tom-PT Taylor ; gsachin@hss.hns.com=20
  Cc: megaco@ietf.org=20
  Sent: Monday, January 05, 2004 3:06 PM
  Subject: RE: [Megaco] Query Related to Automatic Metering


  The way to correct Recommendations in the H.248 subseries is to insert =
an item in the IG for that Recommendation.  This would go in the IG in a =
chapter for H.248.26.  More comments inline. [KJBII]

  Kevin



-------------------------------------------------------------------------=
---
    From: Dal Chohan [mailto:D.Chohan@ftel.co.uk]=20
    Sent: Monday, January 05, 2004 7:23 AM
    To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH]; =
gsachin@hss.hns.com
    Cc: megaco@ietf.org
    Subject: Re: [Megaco] Query Related to Automatic Metering


    Shouldn't the clause 7.5 paragraph 5 procedures in the "amet" =
package be modified so that they don't override the standard Events =
Descriptor/KeepActive flag procedures defined in Megaco rather than =
specifying something in the Implementation Guide? I recommend that the =
offending sentence of clause 7.5 paragraph 5 "The detection of event pr =
shall not cause the termination of the signal em or signal mbp, even if =
the KeepActive flag is not set for the pr event" is deleted from the =
"amet" package.
    [KJBII] See above.=20

    In addition there is a similar problem with clause 7.5 paragraph 4 =
of the "amet" package which also potentially overrides the standard =
Megaco Events Descriptor/KeepActive flag and Signal =
Descriptor/KeepActive flag  procedures.

    "If the value of the parameter pc is zero or if this parameter is =
not supplied by the MGC, then the repetitive application of metering =
pulses should continue until either an event (other than pr) is =
detected, or until the SignalsDescriptor is replaced with a new =
SignalsDescriptor that does not include the signal em. Any pulses =
applied due to a concurrent mpb signal shall be in addition to the =
required repetitive pulses applied for the em signal".

    For example the meter pulses will continue even when an on-hook =
event is detected providing the events descriptor that armed the on-hook =
event had the KeepActive flag set. This action may be required for =
certain territories where all outstanding meter pulses must be delivered =
even when the analogue line is in the on-hook state.
    [KJBII] I'm not sure what this example has to do with the problem =
mentioned above -- the package already functions this way.=20

    [DC] This item is related to this e-mail topic, because if you read =
the current amet procedures in clause 7.4 para 4, they effectively say =
that an event such as on-hook will interrupt the meter pulse even if the =
KeepActive flag is set. This clearly overrides the standard H.248/Megaco =
EventDescriptor/KeepActive flag procedures in a similar fashion to the =
item being discussed.=20

    Again the sentence above defining the SignalDescriptor procedures in =
the "amet" package does not define anything new which is not already =
specified in the standrad Megaco procedures. Hence I recommend that =
clause 7.5 paragraph 4 of the "amet" package be modified to read as:

    "If the value of the parameter pc is zero or if this parameter is =
not supplied by the MGC, then any pulses applied due to a concurrent mpb =
signal shall be in addition to the required repetitive pulses applied =
for the em signal"
    [KJBII] This would be a natural extension of the above correction.=20

    [DC] - Okay - that would address the concerns raised by my second =
point.


    Regards,



    Dal Chohan.



    ----- Original Message -----=20
    From: "Kevin Boyle" <kboyle@nortelnetworks.com>
    To: "Tom-PT Taylor" <taylor@nortelnetworks.com>; =
<gsachin@hss.hns.com>
    Cc: <megaco@ietf.org>
    Sent: Friday, January 02, 2004 3:19 PM
    Subject: RE: [Megaco] Query Related to Automatic Metering


    > Do we need an IG item?  I can add one for the upcoming meeting, if =
we
    > believe that this should be fixed.
    >=20
    > I would rather not have use of KA mandated.  Let the implementor =
decide how
    > the event should interact with any signals.
    >=20
    > Kevin
    >=20
    > -----Original Message-----
    > From: Taylor, Tom-PT [CAR:5N00:EXCH]=20
    > Sent: Monday, December 22, 2003 11:53 AM
    > To: gsachin@hss.hns.com
    > Cc: megaco@ietf.org
    > Subject: Re: [Megaco] Query Related to Automatic Metering
    >=20
    > I think you make a good point.  It's desirable to keep the =
protocol intact,
    > rather than define exceptions within individual packages.
    >=20
    > gsachin@hss.hns.com wrote:
    >=20
    > >=20
    > >=20
    > >=20
    > > Hi List,
    > >=20
    > >=20
    > > this is a query regarding Periodic report event 'pr' defined in =
AMET=20
    > > package .the package procedure says that
    > >=20
    > > "the detection of event pr shall not cause the termination of =
the=20
    > > signal em or signal mbp, even if the KeppActive(KA) flag is not =
set=20
    > > for the pr event"
    > >=20
    > > what i feel is that the detection of the 'pr' event shall not =
cause=20
    > > the termination of any of the signals.
    > >=20
    > > pls tell me if this is a correct assumption?
    > >=20
    > > if yes, then i think here the package procedures should have =
mandated=20
    > > the use of KA flag with this event. Doing this will keep the =
protocol=20
    > > rules intact.
    > >=20
    > >=20
    > >=20
    > > Regards
    > > Sachin Gupta
    > >=20
    > > "DISCLAIMER: This message is proprietary to Hughes Software =
Systems=20
    > > Limited
    > > (HSS) and is intended solely for the use of the individual to =
whom it=20
    > > is addressed. It may contain  privileged or confidential =
information=20
    > > and should not be circulated or used for any purpose other than =
for=20
    > > what it is intended. If you have received this message in error, =

    > > please notify the originator immediately. If you are not the =
intended=20
    > > recipient, you are notified that you are strictly prohibited =
from=20
    > > using, copying, altering, or disclosing the contents of this =
message.=20
    > > HSS accepts no responsibility for loss or damage arising from =
the use=20
    > > of the information transmitted by this email including damage =
from virus."
    > >=20
    > >=20
    > > _______________________________________________
    > > Megaco mailing list
    > > Megaco@ietf.org
    > > https://www1.ietf.org/mailman/listinfo/megaco
    > >=20
    >=20
    >=20
    > _______________________________________________
    > Megaco mailing list
    > Megaco@ietf.org
    > https://www1.ietf.org/mailman/listinfo/megaco
    >=20
    > _______________________________________________
    > Megaco mailing list
    > Megaco@ietf.org
    > https://www1.ietf.org/mailman/listinfo/megaco
    > 
------=_NextPart_000_00EC_01C3D3A1.C0F653B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial color=3D#ff0000 size=3D2>Please can you specify =
what text you=20
will be including in the IG - Also see in-line comments.,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#ff0000 size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial color=3D#ff0000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#ff0000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#ff0000 size=3D2>Dal Chohan</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dkboyle@nortelnetworks.com=20
  href=3D"mailto:kboyle@nortelnetworks.com">Kevin Boyle</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3DD.Chohan@ftel.co.uk=20
  href=3D"mailto:D.Chohan@ftel.co.uk">Dal Chohan</A> ; <A=20
  title=3Dtaylor@nortelnetworks.com =
href=3D"mailto:taylor@nortelnetworks.com">Tom-PT=20
  Taylor</A> ; <A title=3Dgsachin@hss.hns.com=20
  href=3D"mailto:gsachin@hss.hns.com">gsachin@hss.hns.com</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A title=3Dmegaco@ietf.org=20
  href=3D"mailto:megaco@ietf.org">megaco@ietf.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, January 05, 2004 =
3:06=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [Megaco] Query =
Related to=20
  Automatic Metering</DIV>
  <DIV><BR></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D434511614-05012004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>The way to correct Recommendations in the =
H.248 subseries=20
  is to insert an item in the IG for that Recommendation.&nbsp; This =
would go in=20
  the IG in a chapter for H.248.26.&nbsp; More comments inline.=20
  [KJBII]</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D434511614-05012004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D434511614-05012004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Kevin</FONT></SPAN></DIV><BR>
  <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
    <HR tabIndex=3D-1>
    <FONT face=3DTahoma size=3D2><B>From:</B> Dal Chohan=20
    [mailto:D.Chohan@ftel.co.uk] <BR><B>Sent:</B> Monday, January 05, =
2004 7:23=20
    AM<BR><B>To:</B> Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT=20
    [CAR:5N00:EXCH]; <A=20
    =
href=3D"mailto:gsachin@hss.hns.com">gsachin@hss.hns.com</A><BR><B>Cc:</B>=
 <A=20
    =
href=3D"mailto:megaco@ietf.org">megaco@ietf.org</A><BR><B>Subject:</B> =
Re:=20
    [Megaco] Query Related to Automatic Metering<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV>Shouldn't the clause 7.5 paragraph 5 procedures in the "amet" =
package=20
    be modified so that they don't override the standard Events=20
    Descriptor/KeepActive flag procedures defined in Megaco rather than=20
    specifying something in the Implementation Guide? I recommend that =
the=20
    offending sentence of clause 7.5 paragraph 5 "The detection of event =
pr=20
    shall not cause the termination of the signal em or signal mbp, even =
if the=20
    KeepActive flag is not set for the pr event" is=20
    <STRONG><U>deleted</U></STRONG> from the "amet" package.<BR><SPAN=20
    class=3D434511614-05012004><FONT face=3DArial size=3D2><FONT=20
    color=3D#0000ff><STRONG><EM>[KJBII]</EM></STRONG>&nbsp;See=20
    above.&nbsp;</FONT></FONT></SPAN></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV>In addition there is a similar problem with clause 7.5 =
paragraph 4 of=20
    the "amet" package which also potentially overrides the standard =
Megaco=20
    Events Descriptor/KeepActive flag&nbsp;and Signal =
Descriptor/KeepActive=20
    flag&nbsp; procedures.</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>"<FONT face=3D"Times New Roman" =
size=3D3>If the=20
    value of the parameter pc is zero or if this parameter is not =
supplied by=20
    the MGC, then the repetitive application of metering pulses should =
continue=20
    until either an event (other than pr) is detected, or until the=20
    SignalsDescriptor is replaced with a new SignalsDescriptor that does =
not=20
    include the signal em. <SPAN=20
    style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'MS Mincho'; =
mso-fareast-language: EN-US; mso-ansi-language: EN-US; =
mso-bidi-language: AR-SA">Any=20
    pulses applied due to a concurrent mpb signal shall be in addition =
to the=20
    required repetitive pulses applied for the em=20
    signal</SPAN>".</FONT></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"=20
    size=3D3></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>For example=20
    the meter pulses will continue even when an on-hook event is =
detected=20
    providing the events descriptor that armed the on-hook =
event&nbsp;had the=20
    KeepActive flag set. This action may be required for certain =
territories=20
    where all outstanding meter pulses must be delivered even when the =
analogue=20
    line is in the on-hook state.<BR><SPAN =
class=3D434511614-05012004><FONT=20
    face=3DArial size=3D2><FONT=20
    color=3D#0000ff><STRONG><EM>[KJBII]</EM></STRONG>&nbsp;I'm not sure =
what this=20
    example has to do with the problem mentioned above -- the=20
    package&nbsp;already functions this=20
    way.&nbsp;</FONT></FONT></SPAN></FONT></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D434511614-05012004></SPAN></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2><FONT face=3DArial color=3D#ff0000 =
size=3D2><SPAN=20
    class=3D434511614-05012004>[DC] This item is related to this e-mail =
topic,=20
    because if you read the current amet procedures in clause 7.4 para =
4, they=20
    effectively say that an event such as on-hook will interrupt the =
meter pulse=20
    even if the KeepActive flag is set. This clearly overrides the =
standard=20
    H.248/Megaco EventDescriptor/KeepActive flag procedures in a similar =
fashion=20
    to the item being discussed. </SPAN></FONT></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2><FONT face=3DArial color=3D#ff0000 =
size=3D2><SPAN=20
    class=3D434511614-05012004></SPAN></FONT></FONT><FONT face=3DArial =
size=3D2><FONT=20
    face=3DArial size=3D2></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>Again the=20
    sentence above&nbsp;defining the SignalDescriptor procedures in the =
"amet"=20
    package does not define anything new which is not already specified =
in the=20
    standrad Megaco procedures. Hence I recommend =
that&nbsp;clause&nbsp;7.5=20
    paragraph 4 of the "amet" package be modified to read=20
as:</FONT></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2><FONT face=3DArial=20
    size=3D2></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3><STRONG>"If=20
    the value of the parameter pc is zero or if this parameter is not =
supplied=20
    by the MGC, then a</STRONG><SPAN=20
    style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'MS Mincho'; =
mso-fareast-language: EN-US; mso-ansi-language: EN-US; =
mso-bidi-language: AR-SA"><STRONG>ny=20
    pulses applied due to a concurrent mpb signal shall be in addition =
to the=20
    required repetitive pulses applied for the em =
signal"<BR></STRONG><SPAN=20
    class=3D434511614-05012004><FONT face=3DArial size=3D2><FONT=20
    color=3D#0000ff><STRONG><EM>[KJBII]</EM></STRONG>&nbsp;This would be =
a natural=20
    extension of the above=20
    correction.&nbsp;</FONT></FONT></SPAN></SPAN></FONT></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial color=3D#ff0000 size=3D2>[DC] - Okay - that =
would address=20
    the concerns raised by my second point.</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>Dal Chohan.</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>----- Original Message ----- =
</FONT>
    <DIV><FONT face=3DArial size=3D2>From: "Kevin Boyle" &lt;</FONT><A=20
    href=3D"mailto:kboyle@nortelnetworks.com"><FONT face=3DArial=20
    size=3D2>kboyle@nortelnetworks.com</FONT></A><FONT face=3DArial=20
    size=3D2>&gt;</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>To: "Tom-PT Taylor" &lt;</FONT><A=20
    href=3D"mailto:taylor@nortelnetworks.com"><FONT face=3DArial=20
    size=3D2>taylor@nortelnetworks.com</FONT></A><FONT face=3DArial =
size=3D2>&gt;;=20
    &lt;</FONT><A href=3D"mailto:gsachin@hss.hns.com"><FONT face=3DArial =

    size=3D2>gsachin@hss.hns.com</FONT></A><FONT face=3DArial=20
    size=3D2>&gt;</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>Cc: &lt;</FONT><A=20
    href=3D"mailto:megaco@ietf.org"><FONT face=3DArial=20
    size=3D2>megaco@ietf.org</FONT></A><FONT face=3DArial =
size=3D2>&gt;</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>Sent: Friday, January 02, 2004 3:19 =

    PM</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>Subject: RE: [Megaco] Query Related =
to=20
    Automatic Metering</FONT></DIV></DIV>
    <DIV><FONT face=3DArial><BR><FONT size=3D2></FONT></FONT></DIV><FONT =
face=3DArial=20
    size=3D2>&gt; Do we need an IG item?&nbsp; I can add one for the =
upcoming=20
    meeting, if we<BR>&gt; believe that this should be fixed.<BR>&gt; =
<BR>&gt; I=20
    would rather not have use of KA mandated.&nbsp; Let the implementor =
decide=20
    how<BR>&gt; the event should interact with any signals.<BR>&gt; =
<BR>&gt;=20
    Kevin<BR>&gt; <BR>&gt; -----Original Message-----<BR>&gt; From: =
Taylor,=20
    Tom-PT [CAR:5N00:EXCH] <BR>&gt; Sent: Monday, December 22, 2003 =
11:53=20
    AM<BR>&gt; To: </FONT><A href=3D"mailto:gsachin@hss.hns.com"><FONT =
face=3DArial=20
    size=3D2>gsachin@hss.hns.com</FONT></A><BR><FONT face=3DArial =
size=3D2>&gt; Cc:=20
    </FONT><A href=3D"mailto:megaco@ietf.org"><FONT face=3DArial=20
    size=3D2>megaco@ietf.org</FONT></A><BR><FONT face=3DArial =
size=3D2>&gt; Subject:=20
    Re: [Megaco] Query Related to Automatic Metering<BR>&gt; <BR>&gt; I =
think=20
    you make a good point.&nbsp; It's desirable to keep the protocol=20
    intact,<BR>&gt; rather than define exceptions within individual=20
    packages.<BR>&gt; <BR>&gt; </FONT><A =
href=3D"mailto:gsachin@hss.hns.com"><FONT=20
    face=3DArial size=3D2>gsachin@hss.hns.com</FONT></A><FONT =
face=3DArial size=3D2>=20
    wrote:<BR>&gt; <BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; =
&gt; Hi=20
    List,<BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; this is a query =
regarding=20
    Periodic report event 'pr' defined in AMET <BR>&gt; &gt; package =
.the=20
    package procedure says that<BR>&gt; &gt; <BR>&gt; &gt; "the =
detection of=20
    event pr shall not cause the termination of the <BR>&gt; &gt; signal =
em or=20
    signal mbp, even if the KeppActive(KA) flag is not set <BR>&gt; &gt; =
for the=20
    pr event"<BR>&gt; &gt; <BR>&gt; &gt; what i feel is that the =
detection of=20
    the 'pr' event shall not cause <BR>&gt; &gt; the termination of any =
of the=20
    signals.<BR>&gt; &gt; <BR>&gt; &gt; pls tell me if this is a correct =

    assumption?<BR>&gt; &gt; <BR>&gt; &gt; if yes, then i think here the =
package=20
    procedures should have mandated <BR>&gt; &gt; the use of KA flag =
with this=20
    event. Doing this will keep the protocol <BR>&gt; &gt; rules =
intact.<BR>&gt;=20
    &gt; <BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; Regards<BR>&gt; &gt; =
Sachin=20
    Gupta<BR>&gt; &gt; <BR>&gt; &gt; "DISCLAIMER: This message is =
proprietary to=20
    Hughes Software Systems <BR>&gt; &gt; Limited<BR>&gt; &gt; (HSS) and =
is=20
    intended solely for the use of the individual to whom it <BR>&gt; =
&gt; is=20
    addressed. It may contain&nbsp; privileged or confidential =
information=20
    <BR>&gt; &gt; and should not be circulated or used for any purpose =
other=20
    than for <BR>&gt; &gt; what it is intended. If you have received =
this=20
    message in error, <BR>&gt; &gt; please notify the originator =
immediately. If=20
    you are not the intended <BR>&gt; &gt; recipient, you are notified =
that you=20
    are strictly prohibited from <BR>&gt; &gt; using, copying, altering, =
or=20
    disclosing the contents of this message. <BR>&gt; &gt; HSS accepts =
no=20
    responsibility for loss or damage arising from the use <BR>&gt; &gt; =
of the=20
    information transmitted by this email including damage from =
virus."<BR>&gt;=20
    &gt; <BR>&gt; &gt; <BR>&gt; &gt;=20
    _______________________________________________<BR>&gt; &gt; Megaco =
mailing=20
    list<BR>&gt; &gt; </FONT><A href=3D"mailto:Megaco@ietf.org"><FONT =
face=3DArial=20
    size=3D2>Megaco@ietf.org</FONT></A><BR><FONT face=3DArial =
size=3D2>&gt; &gt;=20
    </FONT><A =
href=3D"https://www1.ietf.org/mailman/listinfo/megaco"><FONT=20
    face=3DArial=20
    =
size=3D2>https://www1.ietf.org/mailman/listinfo/megaco</FONT></A><BR><FON=
T=20
    face=3DArial size=3D2>&gt; &gt; <BR>&gt; <BR>&gt; <BR>&gt;=20
    _______________________________________________<BR>&gt; Megaco =
mailing=20
    list<BR>&gt; </FONT><A href=3D"mailto:Megaco@ietf.org"><FONT =
face=3DArial=20
    size=3D2>Megaco@ietf.org</FONT></A><BR><FONT face=3DArial =
size=3D2>&gt; </FONT><A=20
    href=3D"https://www1.ietf.org/mailman/listinfo/megaco"><FONT =
face=3DArial=20
    =
size=3D2>https://www1.ietf.org/mailman/listinfo/megaco</FONT></A><BR><FON=
T=20
    face=3DArial size=3D2>&gt; <BR>&gt;=20
    _______________________________________________<BR>&gt; Megaco =
mailing=20
    list<BR>&gt; </FONT><A href=3D"mailto:Megaco@ietf.org"><FONT =
face=3DArial=20
    size=3D2>Megaco@ietf.org</FONT></A><BR><FONT face=3DArial =
size=3D2>&gt; </FONT><A=20
    href=3D"https://www1.ietf.org/mailman/listinfo/megaco"><FONT =
face=3DArial=20
    =
size=3D2>https://www1.ietf.org/mailman/listinfo/megaco</FONT></A><BR><FON=
T=20
    face=3DArial size=3D2>&gt; =
</FONT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00EC_01C3D3A1.C0F653B0--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Mon Jan  5 10:45:51 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21447
	for <megaco-archive@odin.ietf.org>; Mon, 5 Jan 2004 10:45:51 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdWux-0007zI-NS
	for megaco-archive@odin.ietf.org; Mon, 05 Jan 2004 10:45:24 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i05FjNrO030697
	for megaco-archive@odin.ietf.org; Mon, 5 Jan 2004 10:45:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdWux-0007z1-2V
	for megaco-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 10:45:23 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21434
	for <megaco-web-archive@ietf.org>; Mon, 5 Jan 2004 10:45:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdWuu-0007Mr-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 10:45:20 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdWsz-0007Jh-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 10:43:23 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdWri-0007Gg-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 10:42:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdWrh-0007qX-Id; Mon, 05 Jan 2004 10:42:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdWqy-0007pB-Hz
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 10:41:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21357
	for <megaco@ietf.org>; Mon, 5 Jan 2004 10:41:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdWqw-0007Ev-00
	for megaco@ietf.org; Mon, 05 Jan 2004 10:41:14 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdWp4-0007CD-00
	for megaco@ietf.org; Mon, 05 Jan 2004 10:39:21 -0500
Received: from ext-proxy-2.ftel.co.uk ([192.65.220.98])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdWnn-00079q-00
	for megaco@ietf.org; Mon, 05 Jan 2004 10:37:59 -0500
Received: from utility-1.ftel.co.uk (utility-1.ftel.co.uk [193.112.172.10])
	by ext-proxy-2.ftel.co.uk (8.12.10/8.12.9/Revision:1.91/relay-in/ssl/db) with ESMTP id i05Fb5Mu007803;
	Mon, 5 Jan 2004 15:37:06 GMT
Received: from DALLAPTOP (dhcp-172-16-48-64.ftel.co.uk [172.16.48.64])
	by utility-1.ftel.co.uk (8.12.9+Sun/8.12.9/Revision:1.90/db) with SMTP id i05FaxNk011053;
	Mon, 5 Jan 2004 15:36:59 GMT
Message-ID: <00ef01c3d3a1$c2d4b0a0$403010ac@DALLAPTOP>
From: "Dal Chohan" <D.Chohan@ftel.co.uk>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>,
        "Tom-PT Taylor" <taylor@nortelnetworks.com>, <gsachin@hss.hns.com>
Cc: <megaco@ietf.org>
References: <ABA227A15B80D511BD1A00508BF93A1C0D85ADF5@zrtpd0jq.us.nortel.com>
Subject: Re: [Megaco] Query Related to Automatic Metering
Date: Mon, 5 Jan 2004 15:36:57 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00EC_01C3D3A1.C0F653B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,EXCUSE_16,HTML_30_40,
	HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_MESSAGE autolearn=no 
	version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_00EC_01C3D3A1.C0F653B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Please can you specify what text you will be including in the IG - Also =
see in-line comments.,


Regards,


Dal Chohan
  ----- Original Message -----=20
  From: Kevin Boyle=20
  To: Dal Chohan ; Tom-PT Taylor ; gsachin@hss.hns.com=20
  Cc: megaco@ietf.org=20
  Sent: Monday, January 05, 2004 3:06 PM
  Subject: RE: [Megaco] Query Related to Automatic Metering


  The way to correct Recommendations in the H.248 subseries is to insert =
an item in the IG for that Recommendation.  This would go in the IG in a =
chapter for H.248.26.  More comments inline. [KJBII]

  Kevin



-------------------------------------------------------------------------=
---
    From: Dal Chohan [mailto:D.Chohan@ftel.co.uk]=20
    Sent: Monday, January 05, 2004 7:23 AM
    To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH]; =
gsachin@hss.hns.com
    Cc: megaco@ietf.org
    Subject: Re: [Megaco] Query Related to Automatic Metering


    Shouldn't the clause 7.5 paragraph 5 procedures in the "amet" =
package be modified so that they don't override the standard Events =
Descriptor/KeepActive flag procedures defined in Megaco rather than =
specifying something in the Implementation Guide? I recommend that the =
offending sentence of clause 7.5 paragraph 5 "The detection of event pr =
shall not cause the termination of the signal em or signal mbp, even if =
the KeepActive flag is not set for the pr event" is deleted from the =
"amet" package.
    [KJBII] See above.=20

    In addition there is a similar problem with clause 7.5 paragraph 4 =
of the "amet" package which also potentially overrides the standard =
Megaco Events Descriptor/KeepActive flag and Signal =
Descriptor/KeepActive flag  procedures.

    "If the value of the parameter pc is zero or if this parameter is =
not supplied by the MGC, then the repetitive application of metering =
pulses should continue until either an event (other than pr) is =
detected, or until the SignalsDescriptor is replaced with a new =
SignalsDescriptor that does not include the signal em. Any pulses =
applied due to a concurrent mpb signal shall be in addition to the =
required repetitive pulses applied for the em signal".

    For example the meter pulses will continue even when an on-hook =
event is detected providing the events descriptor that armed the on-hook =
event had the KeepActive flag set. This action may be required for =
certain territories where all outstanding meter pulses must be delivered =
even when the analogue line is in the on-hook state.
    [KJBII] I'm not sure what this example has to do with the problem =
mentioned above -- the package already functions this way.=20

    [DC] This item is related to this e-mail topic, because if you read =
the current amet procedures in clause 7.4 para 4, they effectively say =
that an event such as on-hook will interrupt the meter pulse even if the =
KeepActive flag is set. This clearly overrides the standard H.248/Megaco =
EventDescriptor/KeepActive flag procedures in a similar fashion to the =
item being discussed.=20

    Again the sentence above defining the SignalDescriptor procedures in =
the "amet" package does not define anything new which is not already =
specified in the standrad Megaco procedures. Hence I recommend that =
clause 7.5 paragraph 4 of the "amet" package be modified to read as:

    "If the value of the parameter pc is zero or if this parameter is =
not supplied by the MGC, then any pulses applied due to a concurrent mpb =
signal shall be in addition to the required repetitive pulses applied =
for the em signal"
    [KJBII] This would be a natural extension of the above correction.=20

    [DC] - Okay - that would address the concerns raised by my second =
point.


    Regards,



    Dal Chohan.



    ----- Original Message -----=20
    From: "Kevin Boyle" <kboyle@nortelnetworks.com>
    To: "Tom-PT Taylor" <taylor@nortelnetworks.com>; =
<gsachin@hss.hns.com>
    Cc: <megaco@ietf.org>
    Sent: Friday, January 02, 2004 3:19 PM
    Subject: RE: [Megaco] Query Related to Automatic Metering


    > Do we need an IG item?  I can add one for the upcoming meeting, if =
we
    > believe that this should be fixed.
    >=20
    > I would rather not have use of KA mandated.  Let the implementor =
decide how
    > the event should interact with any signals.
    >=20
    > Kevin
    >=20
    > -----Original Message-----
    > From: Taylor, Tom-PT [CAR:5N00:EXCH]=20
    > Sent: Monday, December 22, 2003 11:53 AM
    > To: gsachin@hss.hns.com
    > Cc: megaco@ietf.org
    > Subject: Re: [Megaco] Query Related to Automatic Metering
    >=20
    > I think you make a good point.  It's desirable to keep the =
protocol intact,
    > rather than define exceptions within individual packages.
    >=20
    > gsachin@hss.hns.com wrote:
    >=20
    > >=20
    > >=20
    > >=20
    > > Hi List,
    > >=20
    > >=20
    > > this is a query regarding Periodic report event 'pr' defined in =
AMET=20
    > > package .the package procedure says that
    > >=20
    > > "the detection of event pr shall not cause the termination of =
the=20
    > > signal em or signal mbp, even if the KeppActive(KA) flag is not =
set=20
    > > for the pr event"
    > >=20
    > > what i feel is that the detection of the 'pr' event shall not =
cause=20
    > > the termination of any of the signals.
    > >=20
    > > pls tell me if this is a correct assumption?
    > >=20
    > > if yes, then i think here the package procedures should have =
mandated=20
    > > the use of KA flag with this event. Doing this will keep the =
protocol=20
    > > rules intact.
    > >=20
    > >=20
    > >=20
    > > Regards
    > > Sachin Gupta
    > >=20
    > > "DISCLAIMER: This message is proprietary to Hughes Software =
Systems=20
    > > Limited
    > > (HSS) and is intended solely for the use of the individual to =
whom it=20
    > > is addressed. It may contain  privileged or confidential =
information=20
    > > and should not be circulated or used for any purpose other than =
for=20
    > > what it is intended. If you have received this message in error, =

    > > please notify the originator immediately. If you are not the =
intended=20
    > > recipient, you are notified that you are strictly prohibited =
from=20
    > > using, copying, altering, or disclosing the contents of this =
message.=20
    > > HSS accepts no responsibility for loss or damage arising from =
the use=20
    > > of the information transmitted by this email including damage =
from virus."
    > >=20
    > >=20
    > > _______________________________________________
    > > Megaco mailing list
    > > Megaco@ietf.org
    > > https://www1.ietf.org/mailman/listinfo/megaco
    > >=20
    >=20
    >=20
    > _______________________________________________
    > Megaco mailing list
    > Megaco@ietf.org
    > https://www1.ietf.org/mailman/listinfo/megaco
    >=20
    > _______________________________________________
    > Megaco mailing list
    > Megaco@ietf.org
    > https://www1.ietf.org/mailman/listinfo/megaco
    > 
------=_NextPart_000_00EC_01C3D3A1.C0F653B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial color=3D#ff0000 size=3D2>Please can you specify =
what text you=20
will be including in the IG - Also see in-line comments.,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#ff0000 size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial color=3D#ff0000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#ff0000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#ff0000 size=3D2>Dal Chohan</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dkboyle@nortelnetworks.com=20
  href=3D"mailto:kboyle@nortelnetworks.com">Kevin Boyle</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3DD.Chohan@ftel.co.uk=20
  href=3D"mailto:D.Chohan@ftel.co.uk">Dal Chohan</A> ; <A=20
  title=3Dtaylor@nortelnetworks.com =
href=3D"mailto:taylor@nortelnetworks.com">Tom-PT=20
  Taylor</A> ; <A title=3Dgsachin@hss.hns.com=20
  href=3D"mailto:gsachin@hss.hns.com">gsachin@hss.hns.com</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A title=3Dmegaco@ietf.org=20
  href=3D"mailto:megaco@ietf.org">megaco@ietf.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, January 05, 2004 =
3:06=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [Megaco] Query =
Related to=20
  Automatic Metering</DIV>
  <DIV><BR></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D434511614-05012004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>The way to correct Recommendations in the =
H.248 subseries=20
  is to insert an item in the IG for that Recommendation.&nbsp; This =
would go in=20
  the IG in a chapter for H.248.26.&nbsp; More comments inline.=20
  [KJBII]</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D434511614-05012004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D434511614-05012004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Kevin</FONT></SPAN></DIV><BR>
  <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
    <HR tabIndex=3D-1>
    <FONT face=3DTahoma size=3D2><B>From:</B> Dal Chohan=20
    [mailto:D.Chohan@ftel.co.uk] <BR><B>Sent:</B> Monday, January 05, =
2004 7:23=20
    AM<BR><B>To:</B> Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT=20
    [CAR:5N00:EXCH]; <A=20
    =
href=3D"mailto:gsachin@hss.hns.com">gsachin@hss.hns.com</A><BR><B>Cc:</B>=
 <A=20
    =
href=3D"mailto:megaco@ietf.org">megaco@ietf.org</A><BR><B>Subject:</B> =
Re:=20
    [Megaco] Query Related to Automatic Metering<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV>Shouldn't the clause 7.5 paragraph 5 procedures in the "amet" =
package=20
    be modified so that they don't override the standard Events=20
    Descriptor/KeepActive flag procedures defined in Megaco rather than=20
    specifying something in the Implementation Guide? I recommend that =
the=20
    offending sentence of clause 7.5 paragraph 5 "The detection of event =
pr=20
    shall not cause the termination of the signal em or signal mbp, even =
if the=20
    KeepActive flag is not set for the pr event" is=20
    <STRONG><U>deleted</U></STRONG> from the "amet" package.<BR><SPAN=20
    class=3D434511614-05012004><FONT face=3DArial size=3D2><FONT=20
    color=3D#0000ff><STRONG><EM>[KJBII]</EM></STRONG>&nbsp;See=20
    above.&nbsp;</FONT></FONT></SPAN></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV>In addition there is a similar problem with clause 7.5 =
paragraph 4 of=20
    the "amet" package which also potentially overrides the standard =
Megaco=20
    Events Descriptor/KeepActive flag&nbsp;and Signal =
Descriptor/KeepActive=20
    flag&nbsp; procedures.</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>"<FONT face=3D"Times New Roman" =
size=3D3>If the=20
    value of the parameter pc is zero or if this parameter is not =
supplied by=20
    the MGC, then the repetitive application of metering pulses should =
continue=20
    until either an event (other than pr) is detected, or until the=20
    SignalsDescriptor is replaced with a new SignalsDescriptor that does =
not=20
    include the signal em. <SPAN=20
    style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'MS Mincho'; =
mso-fareast-language: EN-US; mso-ansi-language: EN-US; =
mso-bidi-language: AR-SA">Any=20
    pulses applied due to a concurrent mpb signal shall be in addition =
to the=20
    required repetitive pulses applied for the em=20
    signal</SPAN>".</FONT></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"=20
    size=3D3></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>For example=20
    the meter pulses will continue even when an on-hook event is =
detected=20
    providing the events descriptor that armed the on-hook =
event&nbsp;had the=20
    KeepActive flag set. This action may be required for certain =
territories=20
    where all outstanding meter pulses must be delivered even when the =
analogue=20
    line is in the on-hook state.<BR><SPAN =
class=3D434511614-05012004><FONT=20
    face=3DArial size=3D2><FONT=20
    color=3D#0000ff><STRONG><EM>[KJBII]</EM></STRONG>&nbsp;I'm not sure =
what this=20
    example has to do with the problem mentioned above -- the=20
    package&nbsp;already functions this=20
    way.&nbsp;</FONT></FONT></SPAN></FONT></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D434511614-05012004></SPAN></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2><FONT face=3DArial color=3D#ff0000 =
size=3D2><SPAN=20
    class=3D434511614-05012004>[DC] This item is related to this e-mail =
topic,=20
    because if you read the current amet procedures in clause 7.4 para =
4, they=20
    effectively say that an event such as on-hook will interrupt the =
meter pulse=20
    even if the KeepActive flag is set. This clearly overrides the =
standard=20
    H.248/Megaco EventDescriptor/KeepActive flag procedures in a similar =
fashion=20
    to the item being discussed. </SPAN></FONT></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2><FONT face=3DArial color=3D#ff0000 =
size=3D2><SPAN=20
    class=3D434511614-05012004></SPAN></FONT></FONT><FONT face=3DArial =
size=3D2><FONT=20
    face=3DArial size=3D2></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>Again the=20
    sentence above&nbsp;defining the SignalDescriptor procedures in the =
"amet"=20
    package does not define anything new which is not already specified =
in the=20
    standrad Megaco procedures. Hence I recommend =
that&nbsp;clause&nbsp;7.5=20
    paragraph 4 of the "amet" package be modified to read=20
as:</FONT></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2><FONT face=3DArial=20
    size=3D2></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3><STRONG>"If=20
    the value of the parameter pc is zero or if this parameter is not =
supplied=20
    by the MGC, then a</STRONG><SPAN=20
    style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'MS Mincho'; =
mso-fareast-language: EN-US; mso-ansi-language: EN-US; =
mso-bidi-language: AR-SA"><STRONG>ny=20
    pulses applied due to a concurrent mpb signal shall be in addition =
to the=20
    required repetitive pulses applied for the em =
signal"<BR></STRONG><SPAN=20
    class=3D434511614-05012004><FONT face=3DArial size=3D2><FONT=20
    color=3D#0000ff><STRONG><EM>[KJBII]</EM></STRONG>&nbsp;This would be =
a natural=20
    extension of the above=20
    correction.&nbsp;</FONT></FONT></SPAN></SPAN></FONT></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial color=3D#ff0000 size=3D2>[DC] - Okay - that =
would address=20
    the concerns raised by my second point.</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>Dal Chohan.</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>----- Original Message ----- =
</FONT>
    <DIV><FONT face=3DArial size=3D2>From: "Kevin Boyle" &lt;</FONT><A=20
    href=3D"mailto:kboyle@nortelnetworks.com"><FONT face=3DArial=20
    size=3D2>kboyle@nortelnetworks.com</FONT></A><FONT face=3DArial=20
    size=3D2>&gt;</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>To: "Tom-PT Taylor" &lt;</FONT><A=20
    href=3D"mailto:taylor@nortelnetworks.com"><FONT face=3DArial=20
    size=3D2>taylor@nortelnetworks.com</FONT></A><FONT face=3DArial =
size=3D2>&gt;;=20
    &lt;</FONT><A href=3D"mailto:gsachin@hss.hns.com"><FONT face=3DArial =

    size=3D2>gsachin@hss.hns.com</FONT></A><FONT face=3DArial=20
    size=3D2>&gt;</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>Cc: &lt;</FONT><A=20
    href=3D"mailto:megaco@ietf.org"><FONT face=3DArial=20
    size=3D2>megaco@ietf.org</FONT></A><FONT face=3DArial =
size=3D2>&gt;</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>Sent: Friday, January 02, 2004 3:19 =

    PM</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>Subject: RE: [Megaco] Query Related =
to=20
    Automatic Metering</FONT></DIV></DIV>
    <DIV><FONT face=3DArial><BR><FONT size=3D2></FONT></FONT></DIV><FONT =
face=3DArial=20
    size=3D2>&gt; Do we need an IG item?&nbsp; I can add one for the =
upcoming=20
    meeting, if we<BR>&gt; believe that this should be fixed.<BR>&gt; =
<BR>&gt; I=20
    would rather not have use of KA mandated.&nbsp; Let the implementor =
decide=20
    how<BR>&gt; the event should interact with any signals.<BR>&gt; =
<BR>&gt;=20
    Kevin<BR>&gt; <BR>&gt; -----Original Message-----<BR>&gt; From: =
Taylor,=20
    Tom-PT [CAR:5N00:EXCH] <BR>&gt; Sent: Monday, December 22, 2003 =
11:53=20
    AM<BR>&gt; To: </FONT><A href=3D"mailto:gsachin@hss.hns.com"><FONT =
face=3DArial=20
    size=3D2>gsachin@hss.hns.com</FONT></A><BR><FONT face=3DArial =
size=3D2>&gt; Cc:=20
    </FONT><A href=3D"mailto:megaco@ietf.org"><FONT face=3DArial=20
    size=3D2>megaco@ietf.org</FONT></A><BR><FONT face=3DArial =
size=3D2>&gt; Subject:=20
    Re: [Megaco] Query Related to Automatic Metering<BR>&gt; <BR>&gt; I =
think=20
    you make a good point.&nbsp; It's desirable to keep the protocol=20
    intact,<BR>&gt; rather than define exceptions within individual=20
    packages.<BR>&gt; <BR>&gt; </FONT><A =
href=3D"mailto:gsachin@hss.hns.com"><FONT=20
    face=3DArial size=3D2>gsachin@hss.hns.com</FONT></A><FONT =
face=3DArial size=3D2>=20
    wrote:<BR>&gt; <BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; =
&gt; Hi=20
    List,<BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; this is a query =
regarding=20
    Periodic report event 'pr' defined in AMET <BR>&gt; &gt; package =
.the=20
    package procedure says that<BR>&gt; &gt; <BR>&gt; &gt; "the =
detection of=20
    event pr shall not cause the termination of the <BR>&gt; &gt; signal =
em or=20
    signal mbp, even if the KeppActive(KA) flag is not set <BR>&gt; &gt; =
for the=20
    pr event"<BR>&gt; &gt; <BR>&gt; &gt; what i feel is that the =
detection of=20
    the 'pr' event shall not cause <BR>&gt; &gt; the termination of any =
of the=20
    signals.<BR>&gt; &gt; <BR>&gt; &gt; pls tell me if this is a correct =

    assumption?<BR>&gt; &gt; <BR>&gt; &gt; if yes, then i think here the =
package=20
    procedures should have mandated <BR>&gt; &gt; the use of KA flag =
with this=20
    event. Doing this will keep the protocol <BR>&gt; &gt; rules =
intact.<BR>&gt;=20
    &gt; <BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; Regards<BR>&gt; &gt; =
Sachin=20
    Gupta<BR>&gt; &gt; <BR>&gt; &gt; "DISCLAIMER: This message is =
proprietary to=20
    Hughes Software Systems <BR>&gt; &gt; Limited<BR>&gt; &gt; (HSS) and =
is=20
    intended solely for the use of the individual to whom it <BR>&gt; =
&gt; is=20
    addressed. It may contain&nbsp; privileged or confidential =
information=20
    <BR>&gt; &gt; and should not be circulated or used for any purpose =
other=20
    than for <BR>&gt; &gt; what it is intended. If you have received =
this=20
    message in error, <BR>&gt; &gt; please notify the originator =
immediately. If=20
    you are not the intended <BR>&gt; &gt; recipient, you are notified =
that you=20
    are strictly prohibited from <BR>&gt; &gt; using, copying, altering, =
or=20
    disclosing the contents of this message. <BR>&gt; &gt; HSS accepts =
no=20
    responsibility for loss or damage arising from the use <BR>&gt; &gt; =
of the=20
    information transmitted by this email including damage from =
virus."<BR>&gt;=20
    &gt; <BR>&gt; &gt; <BR>&gt; &gt;=20
    _______________________________________________<BR>&gt; &gt; Megaco =
mailing=20
    list<BR>&gt; &gt; </FONT><A href=3D"mailto:Megaco@ietf.org"><FONT =
face=3DArial=20
    size=3D2>Megaco@ietf.org</FONT></A><BR><FONT face=3DArial =
size=3D2>&gt; &gt;=20
    </FONT><A =
href=3D"https://www1.ietf.org/mailman/listinfo/megaco"><FONT=20
    face=3DArial=20
    =
size=3D2>https://www1.ietf.org/mailman/listinfo/megaco</FONT></A><BR><FON=
T=20
    face=3DArial size=3D2>&gt; &gt; <BR>&gt; <BR>&gt; <BR>&gt;=20
    _______________________________________________<BR>&gt; Megaco =
mailing=20
    list<BR>&gt; </FONT><A href=3D"mailto:Megaco@ietf.org"><FONT =
face=3DArial=20
    size=3D2>Megaco@ietf.org</FONT></A><BR><FONT face=3DArial =
size=3D2>&gt; </FONT><A=20
    href=3D"https://www1.ietf.org/mailman/listinfo/megaco"><FONT =
face=3DArial=20
    =
size=3D2>https://www1.ietf.org/mailman/listinfo/megaco</FONT></A><BR><FON=
T=20
    face=3DArial size=3D2>&gt; <BR>&gt;=20
    _______________________________________________<BR>&gt; Megaco =
mailing=20
    list<BR>&gt; </FONT><A href=3D"mailto:Megaco@ietf.org"><FONT =
face=3DArial=20
    size=3D2>Megaco@ietf.org</FONT></A><BR><FONT face=3DArial =
size=3D2>&gt; </FONT><A=20
    href=3D"https://www1.ietf.org/mailman/listinfo/megaco"><FONT =
face=3DArial=20
    =
size=3D2>https://www1.ietf.org/mailman/listinfo/megaco</FONT></A><BR><FON=
T=20
    face=3DArial size=3D2>&gt; =
</FONT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00EC_01C3D3A1.C0F653B0--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Jan  5 11:05:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22133
	for <megaco-archive@lists.ietf.org>; Mon, 5 Jan 2004 11:05:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdXDy-0000GJ-09; Mon, 05 Jan 2004 11:05:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdXD3-0000Ev-DJ
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 11:04:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22125
	for <megaco@ietf.org>; Mon, 5 Jan 2004 11:03:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdXCq-0000Vk-00
	for megaco@ietf.org; Mon, 05 Jan 2004 11:03:52 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdX8W-0000Pm-00
	for megaco@ietf.org; Mon, 05 Jan 2004 10:59:25 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdX6z-0000Hu-00
	for megaco@ietf.org; Mon, 05 Jan 2004 10:57:49 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i05FvH005616
	for <megaco@ietf.org>; Mon, 5 Jan 2004 10:57:17 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y10V42>; Mon, 5 Jan 2004 10:57:18 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D85B093@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Dal Chohan <D.Chohan@ftel.co.uk>,
        "Tom-PT Taylor" <taylor@nortelnetworks.com>, gsachin@hss.hns.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Query Related to Automatic Metering
Date: Mon, 5 Jan 2004 10:57:16 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,EXCUSE_16 autolearn=no 
	version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

More comments inline. [KJBII]
 
Kevin


  _____  

From: Dal Chohan [mailto:D.Chohan@ftel.co.uk] 
Sent: Monday, January 05, 2004 10:37 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH];
gsachin@hss.hns.com
Cc: megaco@ietf.org
Subject: Re: [Megaco] Query Related to Automatic Metering


Please can you specify what text you will be including in the IG - Also see
in-line comments.,
[KJBII] The text would remove the two "override" portions. 
 
 
Regards,
 
 
Dal Chohan

----- Original Message ----- 
From: Kevin Boyle <mailto:kboyle@nortelnetworks.com>  
To: Dal Chohan <mailto:D.Chohan@ftel.co.uk>  ; Tom-PT Taylor
<mailto:taylor@nortelnetworks.com>  ; gsachin@hss.hns.com
<mailto:gsachin@hss.hns.com>  
Cc: megaco@ietf.org <mailto:megaco@ietf.org>  
Sent: Monday, January 05, 2004 3:06 PM
Subject: RE: [Megaco] Query Related to Automatic Metering

The way to correct Recommendations in the H.248 subseries is to insert an
item in the IG for that Recommendation.  This would go in the IG in a
chapter for H.248.26.  More comments inline. [KJBII]
 
Kevin


  _____  

From: Dal Chohan [mailto:D.Chohan@ftel.co.uk] 
Sent: Monday, January 05, 2004 7:23 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH];
gsachin@hss.hns.com <mailto:gsachin@hss.hns.com> 
Cc: megaco@ietf.org <mailto:megaco@ietf.org> 
Subject: Re: [Megaco] Query Related to Automatic Metering


Shouldn't the clause 7.5 paragraph 5 procedures in the "amet" package be
modified so that they don't override the standard Events
Descriptor/KeepActive flag procedures defined in Megaco rather than
specifying something in the Implementation Guide? I recommend that the
offending sentence of clause 7.5 paragraph 5 "The detection of event pr
shall not cause the termination of the signal em or signal mbp, even if the
KeepActive flag is not set for the pr event" is deleted from the "amet"
package.
[KJBII] See above. 
 
In addition there is a similar problem with clause 7.5 paragraph 4 of the
"amet" package which also potentially overrides the standard Megaco Events
Descriptor/KeepActive flag and Signal Descriptor/KeepActive flag
procedures.
 
"If the value of the parameter pc is zero or if this parameter is not
supplied by the MGC, then the repetitive application of metering pulses
should continue until either an event (other than pr) is detected, or until
the SignalsDescriptor is replaced with a new SignalsDescriptor that does not
include the signal em. Any pulses applied due to a concurrent mpb signal
shall be in addition to the required repetitive pulses applied for the em
signal".
 
For example the meter pulses will continue even when an on-hook event is
detected providing the events descriptor that armed the on-hook event had
the KeepActive flag set. This action may be required for certain territories
where all outstanding meter pulses must be delivered even when the analogue
line is in the on-hook state.
[KJBII] I'm not sure what this example has to do with the problem mentioned
above -- the package already functions this way. 
 
[DC] This item is related to this e-mail topic, because if you read the
current amet procedures in clause 7.4 para 4, they effectively say that an
event such as on-hook will interrupt the meter pulse even if the KeepActive
flag is set. This clearly overrides the standard H.248/Megaco
EventDescriptor/KeepActive flag procedures in a similar fashion to the item
being discussed. 
[KJBII] Where does it say that?  I think you are reading too much into it --
the intent was not to override the KeepActive flag. 
 
Again the sentence above defining the SignalDescriptor procedures in the
"amet" package does not define anything new which is not already specified
in the standrad Megaco procedures. Hence I recommend that clause 7.5
paragraph 4 of the "amet" package be modified to read as:
 
"If the value of the parameter pc is zero or if this parameter is not
supplied by the MGC, then any pulses applied due to a concurrent mpb signal
shall be in addition to the required repetitive pulses applied for the em
signal"
[KJBII] This would be a natural extension of the above correction. 
 
[DC] - Okay - that would address the concerns raised by my second point.
 
 
Regards,
 
 
 
Dal Chohan.
 
 
 
----- Original Message ----- 
From: "Kevin Boyle" < <mailto:kboyle@nortelnetworks.com>
kboyle@nortelnetworks.com>
To: "Tom-PT Taylor" < <mailto:taylor@nortelnetworks.com>
taylor@nortelnetworks.com>; < <mailto:gsachin@hss.hns.com>
gsachin@hss.hns.com>
Cc: < <mailto:megaco@ietf.org> megaco@ietf.org>
Sent: Friday, January 02, 2004 3:19 PM
Subject: RE: [Megaco] Query Related to Automatic Metering


> Do we need an IG item?  I can add one for the upcoming meeting, if we
> believe that this should be fixed.
> 
> I would rather not have use of KA mandated.  Let the implementor decide
how
> the event should interact with any signals.
> 
> Kevin
> 
> -----Original Message-----
> From: Taylor, Tom-PT [CAR:5N00:EXCH] 
> Sent: Monday, December 22, 2003 11:53 AM
> To:  <mailto:gsachin@hss.hns.com> gsachin@hss.hns.com
> Cc:  <mailto:megaco@ietf.org> megaco@ietf.org
> Subject: Re: [Megaco] Query Related to Automatic Metering
> 
> I think you make a good point.  It's desirable to keep the protocol
intact,
> rather than define exceptions within individual packages.
> 
>  <mailto:gsachin@hss.hns.com> gsachin@hss.hns.com wrote:
> 
> > 
> > 
> > 
> > Hi List,
> > 
> > 
> > this is a query regarding Periodic report event 'pr' defined in AMET 
> > package .the package procedure says that
> > 
> > "the detection of event pr shall not cause the termination of the 
> > signal em or signal mbp, even if the KeppActive(KA) flag is not set 
> > for the pr event"
> > 
> > what i feel is that the detection of the 'pr' event shall not cause 
> > the termination of any of the signals.
> > 
> > pls tell me if this is a correct assumption?
> > 
> > if yes, then i think here the package procedures should have mandated 
> > the use of KA flag with this event. Doing this will keep the protocol 
> > rules intact.
> > 
> > 
> > 
> > Regards
> > Sachin Gupta
> > 
> > "DISCLAIMER: This message is proprietary to Hughes Software Systems 
> > Limited
> > (HSS) and is intended solely for the use of the individual to whom it 
> > is addressed. It may contain  privileged or confidential information 
> > and should not be circulated or used for any purpose other than for 
> > what it is intended. If you have received this message in error, 
> > please notify the originator immediately. If you are not the intended 
> > recipient, you are notified that you are strictly prohibited from 
> > using, copying, altering, or disclosing the contents of this message. 
> > HSS accepts no responsibility for loss or damage arising from the use 
> > of the information transmitted by this email including damage from
virus."
> > 
> > 
> > _______________________________________________
> > Megaco mailing list
> >  <mailto:Megaco@ietf.org> Megaco@ietf.org
> >  <https://www1.ietf.org/mailman/listinfo/megaco>
https://www1.ietf.org/mailman/listinfo/megaco
> > 
> 
> 
> _______________________________________________
> Megaco mailing list
>  <mailto:Megaco@ietf.org> Megaco@ietf.org
>  <https://www1.ietf.org/mailman/listinfo/megaco>
https://www1.ietf.org/mailman/listinfo/megaco
> 
> _______________________________________________
> Megaco mailing list
>  <mailto:Megaco@ietf.org> Megaco@ietf.org
>  <https://www1.ietf.org/mailman/listinfo/megaco>
https://www1.ietf.org/mailman/listinfo/megaco
> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Mon Jan  5 11:14:47 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22451
	for <megaco-archive@odin.ietf.org>; Mon, 5 Jan 2004 11:14:47 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdXMx-0000pM-GT
	for megaco-archive@odin.ietf.org; Mon, 05 Jan 2004 11:14:19 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i05GEJG3003174
	for megaco-archive@odin.ietf.org; Mon, 5 Jan 2004 11:14:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdXMx-0000p7-9s
	for megaco-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 11:14:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22444
	for <megaco-web-archive@ietf.org>; Mon, 5 Jan 2004 11:14:17 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdXMr-0000u5-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 11:14:13 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdXGk-0000hY-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 11:07:55 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdXE7-0000Xe-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 11:05:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdXDy-0000GJ-09; Mon, 05 Jan 2004 11:05:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdXD3-0000Ev-DJ
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 11:04:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22125
	for <megaco@ietf.org>; Mon, 5 Jan 2004 11:03:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdXCq-0000Vk-00
	for megaco@ietf.org; Mon, 05 Jan 2004 11:03:52 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdX8W-0000Pm-00
	for megaco@ietf.org; Mon, 05 Jan 2004 10:59:25 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdX6z-0000Hu-00
	for megaco@ietf.org; Mon, 05 Jan 2004 10:57:49 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i05FvH005616
	for <megaco@ietf.org>; Mon, 5 Jan 2004 10:57:17 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y10V42>; Mon, 5 Jan 2004 10:57:18 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D85B093@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Dal Chohan <D.Chohan@ftel.co.uk>,
        "Tom-PT Taylor" <taylor@nortelnetworks.com>, gsachin@hss.hns.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Query Related to Automatic Metering
Date: Mon, 5 Jan 2004 10:57:16 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,EXCUSE_16 autolearn=no 
	version=2.60

More comments inline. [KJBII]
 
Kevin


  _____  

From: Dal Chohan [mailto:D.Chohan@ftel.co.uk] 
Sent: Monday, January 05, 2004 10:37 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH];
gsachin@hss.hns.com
Cc: megaco@ietf.org
Subject: Re: [Megaco] Query Related to Automatic Metering


Please can you specify what text you will be including in the IG - Also see
in-line comments.,
[KJBII] The text would remove the two "override" portions. 
 
 
Regards,
 
 
Dal Chohan

----- Original Message ----- 
From: Kevin Boyle <mailto:kboyle@nortelnetworks.com>  
To: Dal Chohan <mailto:D.Chohan@ftel.co.uk>  ; Tom-PT Taylor
<mailto:taylor@nortelnetworks.com>  ; gsachin@hss.hns.com
<mailto:gsachin@hss.hns.com>  
Cc: megaco@ietf.org <mailto:megaco@ietf.org>  
Sent: Monday, January 05, 2004 3:06 PM
Subject: RE: [Megaco] Query Related to Automatic Metering

The way to correct Recommendations in the H.248 subseries is to insert an
item in the IG for that Recommendation.  This would go in the IG in a
chapter for H.248.26.  More comments inline. [KJBII]
 
Kevin


  _____  

From: Dal Chohan [mailto:D.Chohan@ftel.co.uk] 
Sent: Monday, January 05, 2004 7:23 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH];
gsachin@hss.hns.com <mailto:gsachin@hss.hns.com> 
Cc: megaco@ietf.org <mailto:megaco@ietf.org> 
Subject: Re: [Megaco] Query Related to Automatic Metering


Shouldn't the clause 7.5 paragraph 5 procedures in the "amet" package be
modified so that they don't override the standard Events
Descriptor/KeepActive flag procedures defined in Megaco rather than
specifying something in the Implementation Guide? I recommend that the
offending sentence of clause 7.5 paragraph 5 "The detection of event pr
shall not cause the termination of the signal em or signal mbp, even if the
KeepActive flag is not set for the pr event" is deleted from the "amet"
package.
[KJBII] See above. 
 
In addition there is a similar problem with clause 7.5 paragraph 4 of the
"amet" package which also potentially overrides the standard Megaco Events
Descriptor/KeepActive flag and Signal Descriptor/KeepActive flag
procedures.
 
"If the value of the parameter pc is zero or if this parameter is not
supplied by the MGC, then the repetitive application of metering pulses
should continue until either an event (other than pr) is detected, or until
the SignalsDescriptor is replaced with a new SignalsDescriptor that does not
include the signal em. Any pulses applied due to a concurrent mpb signal
shall be in addition to the required repetitive pulses applied for the em
signal".
 
For example the meter pulses will continue even when an on-hook event is
detected providing the events descriptor that armed the on-hook event had
the KeepActive flag set. This action may be required for certain territories
where all outstanding meter pulses must be delivered even when the analogue
line is in the on-hook state.
[KJBII] I'm not sure what this example has to do with the problem mentioned
above -- the package already functions this way. 
 
[DC] This item is related to this e-mail topic, because if you read the
current amet procedures in clause 7.4 para 4, they effectively say that an
event such as on-hook will interrupt the meter pulse even if the KeepActive
flag is set. This clearly overrides the standard H.248/Megaco
EventDescriptor/KeepActive flag procedures in a similar fashion to the item
being discussed. 
[KJBII] Where does it say that?  I think you are reading too much into it --
the intent was not to override the KeepActive flag. 
 
Again the sentence above defining the SignalDescriptor procedures in the
"amet" package does not define anything new which is not already specified
in the standrad Megaco procedures. Hence I recommend that clause 7.5
paragraph 4 of the "amet" package be modified to read as:
 
"If the value of the parameter pc is zero or if this parameter is not
supplied by the MGC, then any pulses applied due to a concurrent mpb signal
shall be in addition to the required repetitive pulses applied for the em
signal"
[KJBII] This would be a natural extension of the above correction. 
 
[DC] - Okay - that would address the concerns raised by my second point.
 
 
Regards,
 
 
 
Dal Chohan.
 
 
 
----- Original Message ----- 
From: "Kevin Boyle" < <mailto:kboyle@nortelnetworks.com>
kboyle@nortelnetworks.com>
To: "Tom-PT Taylor" < <mailto:taylor@nortelnetworks.com>
taylor@nortelnetworks.com>; < <mailto:gsachin@hss.hns.com>
gsachin@hss.hns.com>
Cc: < <mailto:megaco@ietf.org> megaco@ietf.org>
Sent: Friday, January 02, 2004 3:19 PM
Subject: RE: [Megaco] Query Related to Automatic Metering


> Do we need an IG item?  I can add one for the upcoming meeting, if we
> believe that this should be fixed.
> 
> I would rather not have use of KA mandated.  Let the implementor decide
how
> the event should interact with any signals.
> 
> Kevin
> 
> -----Original Message-----
> From: Taylor, Tom-PT [CAR:5N00:EXCH] 
> Sent: Monday, December 22, 2003 11:53 AM
> To:  <mailto:gsachin@hss.hns.com> gsachin@hss.hns.com
> Cc:  <mailto:megaco@ietf.org> megaco@ietf.org
> Subject: Re: [Megaco] Query Related to Automatic Metering
> 
> I think you make a good point.  It's desirable to keep the protocol
intact,
> rather than define exceptions within individual packages.
> 
>  <mailto:gsachin@hss.hns.com> gsachin@hss.hns.com wrote:
> 
> > 
> > 
> > 
> > Hi List,
> > 
> > 
> > this is a query regarding Periodic report event 'pr' defined in AMET 
> > package .the package procedure says that
> > 
> > "the detection of event pr shall not cause the termination of the 
> > signal em or signal mbp, even if the KeppActive(KA) flag is not set 
> > for the pr event"
> > 
> > what i feel is that the detection of the 'pr' event shall not cause 
> > the termination of any of the signals.
> > 
> > pls tell me if this is a correct assumption?
> > 
> > if yes, then i think here the package procedures should have mandated 
> > the use of KA flag with this event. Doing this will keep the protocol 
> > rules intact.
> > 
> > 
> > 
> > Regards
> > Sachin Gupta
> > 
> > "DISCLAIMER: This message is proprietary to Hughes Software Systems 
> > Limited
> > (HSS) and is intended solely for the use of the individual to whom it 
> > is addressed. It may contain  privileged or confidential information 
> > and should not be circulated or used for any purpose other than for 
> > what it is intended. If you have received this message in error, 
> > please notify the originator immediately. If you are not the intended 
> > recipient, you are notified that you are strictly prohibited from 
> > using, copying, altering, or disclosing the contents of this message. 
> > HSS accepts no responsibility for loss or damage arising from the use 
> > of the information transmitted by this email including damage from
virus."
> > 
> > 
> > _______________________________________________
> > Megaco mailing list
> >  <mailto:Megaco@ietf.org> Megaco@ietf.org
> >  <https://www1.ietf.org/mailman/listinfo/megaco>
https://www1.ietf.org/mailman/listinfo/megaco
> > 
> 
> 
> _______________________________________________
> Megaco mailing list
>  <mailto:Megaco@ietf.org> Megaco@ietf.org
>  <https://www1.ietf.org/mailman/listinfo/megaco>
https://www1.ietf.org/mailman/listinfo/megaco
> 
> _______________________________________________
> Megaco mailing list
>  <mailto:Megaco@ietf.org> Megaco@ietf.org
>  <https://www1.ietf.org/mailman/listinfo/megaco>
https://www1.ietf.org/mailman/listinfo/megaco
> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Jan  5 11:25:32 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22914
	for <megaco-archive@lists.ietf.org>; Mon, 5 Jan 2004 11:25:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdXXK-00018i-Rf; Mon, 05 Jan 2004 11:25:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdXWa-00017x-NR
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 11:24:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22888
	for <megaco@ietf.org>; Mon, 5 Jan 2004 11:24:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdXWO-0001KF-00
	for megaco@ietf.org; Mon, 05 Jan 2004 11:24:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdXQz-000157-00
	for megaco@ietf.org; Mon, 05 Jan 2004 11:18:29 -0500
Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdXMe-0000pz-00
	for megaco@ietf.org; Mon, 05 Jan 2004 11:14:00 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i05GD1P01555
	for <megaco@ietf.org>; Mon, 5 Jan 2004 10:13:01 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA18270; Mon, 5 Jan 2004 11:12:59 -0500 (EST)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA18266; Mon, 5 Jan 2004 11:12:58 -0500 (EST)
Message-ID: <3FF98D0B.1070207@bell-labs.com>
Date: Mon, 05 Jan 2004 11:12:59 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [Megaco] disabled terminations
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


If an MG is configured (via SNMP for example) to have some terminations
disabled, and has sent the ServiceChange { Method = Forced } messages,
what error should it return if it receives subsequent Add/Move/Modify/etc. ?

?	430 Unknown TerminationID	?
?	530 Service Changing		?


-troy


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From megaco-admin@ietf.org  Mon Jan  5 11:27:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22983
	for <megaco-archive@lists.ietf.org>; Mon, 5 Jan 2004 11:27:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdXZF-0001Nh-BA; Mon, 05 Jan 2004 11:27:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdXYW-0001N5-3Q
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 11:26:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22949
	for <megaco@ietf.org>; Mon, 5 Jan 2004 11:26:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdXYQ-0001Wr-00
	for megaco@ietf.org; Mon, 05 Jan 2004 11:26:10 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdXV1-0001EG-00
	for megaco@ietf.org; Mon, 05 Jan 2004 11:22:40 -0500
Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdXOZ-0000zM-00
	for megaco@ietf.org; Mon, 05 Jan 2004 11:15:59 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i05GFEP03418
	for <megaco@ietf.org>; Mon, 5 Jan 2004 10:15:14 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA18307; Mon, 5 Jan 2004 11:15:12 -0500 (EST)
Cc: MEGACO list <megaco@ietf.org>
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA18288; Mon, 5 Jan 2004 11:15:11 -0500 (EST)
Message-ID: <3FF98D8F.2090609@bell-labs.com>
Date: Mon, 05 Jan 2004 11:15:11 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Troy Cauble <troy@bell-labs.com>
Original-CC: MEGACO list <megaco@ietf.org>
References: <3FF98D0B.1070207@bell-labs.com>
In-Reply-To: <3FF98D0B.1070207@bell-labs.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Re: disabled terminations
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Troy Cauble wrote:

> 
> If an MG is configured (via SNMP for example) to have some terminations
> disabled, and has sent the ServiceChange { Method = Forced } messages,
> what error should it return if it receives subsequent 
> Add/Move/Modify/etc. ?
> 
> ?    430 Unknown TerminationID    ?
> ?    530 Service Changing        ?
> 
> 
> -troy
> 

Similarly, if it receives a wildcard command or a wildcard return command
should it behave as if those terminations don't exist or should errors be
returned?

-troy




_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Mon Jan  5 11:30:23 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23457
	for <megaco-archive@odin.ietf.org>; Mon, 5 Jan 2004 11:30:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdXc2-0001gN-PM
	for megaco-archive@odin.ietf.org; Mon, 05 Jan 2004 11:29:54 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i05GTsSu006461
	for megaco-archive@odin.ietf.org; Mon, 5 Jan 2004 11:29:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdXc2-0001g8-L6
	for megaco-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 11:29:54 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23387
	for <megaco-web-archive@ietf.org>; Mon, 5 Jan 2004 11:29:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdXc1-0001xf-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 11:29:53 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdXaZ-0001jU-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 11:28:23 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdXXg-0001Oq-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 11:25:24 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdXXK-00018i-Rf; Mon, 05 Jan 2004 11:25:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdXWa-00017x-NR
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 11:24:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22888
	for <megaco@ietf.org>; Mon, 5 Jan 2004 11:24:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdXWO-0001KF-00
	for megaco@ietf.org; Mon, 05 Jan 2004 11:24:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdXQz-000157-00
	for megaco@ietf.org; Mon, 05 Jan 2004 11:18:29 -0500
Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdXMe-0000pz-00
	for megaco@ietf.org; Mon, 05 Jan 2004 11:14:00 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i05GD1P01555
	for <megaco@ietf.org>; Mon, 5 Jan 2004 10:13:01 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA18270; Mon, 5 Jan 2004 11:12:59 -0500 (EST)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA18266; Mon, 5 Jan 2004 11:12:58 -0500 (EST)
Message-ID: <3FF98D0B.1070207@bell-labs.com>
Date: Mon, 05 Jan 2004 11:12:59 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Megaco] disabled terminations
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


If an MG is configured (via SNMP for example) to have some terminations
disabled, and has sent the ServiceChange { Method = Forced } messages,
what error should it return if it receives subsequent Add/Move/Modify/etc. ?

?	430 Unknown TerminationID	?
?	530 Service Changing		?


-troy


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From exim@www1.ietf.org  Mon Jan  5 11:31:46 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23651
	for <megaco-archive@odin.ietf.org>; Mon, 5 Jan 2004 11:31:46 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdXdO-0001xb-8o
	for megaco-archive@odin.ietf.org; Mon, 05 Jan 2004 11:31:18 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i05GVIlm007529
	for megaco-archive@odin.ietf.org; Mon, 5 Jan 2004 11:31:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdXdO-0001xM-5U
	for megaco-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 11:31:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23538
	for <megaco-web-archive@ietf.org>; Mon, 5 Jan 2004 11:31:15 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdXdN-00022a-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 11:31:17 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdXbU-0001sn-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 11:29:21 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdXZZ-0001aO-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 11:27:21 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdXZF-0001Nh-BA; Mon, 05 Jan 2004 11:27:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdXYW-0001N5-3Q
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 11:26:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22949
	for <megaco@ietf.org>; Mon, 5 Jan 2004 11:26:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdXYQ-0001Wr-00
	for megaco@ietf.org; Mon, 05 Jan 2004 11:26:10 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdXV1-0001EG-00
	for megaco@ietf.org; Mon, 05 Jan 2004 11:22:40 -0500
Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdXOZ-0000zM-00
	for megaco@ietf.org; Mon, 05 Jan 2004 11:15:59 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i05GFEP03418
	for <megaco@ietf.org>; Mon, 5 Jan 2004 10:15:14 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA18307; Mon, 5 Jan 2004 11:15:12 -0500 (EST)
Cc: MEGACO list <megaco@ietf.org>
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA18288; Mon, 5 Jan 2004 11:15:11 -0500 (EST)
Message-ID: <3FF98D8F.2090609@bell-labs.com>
Date: Mon, 05 Jan 2004 11:15:11 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Troy Cauble <troy@bell-labs.com>
Original-CC: MEGACO list <megaco@ietf.org>
References: <3FF98D0B.1070207@bell-labs.com>
In-Reply-To: <3FF98D0B.1070207@bell-labs.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Re: disabled terminations
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Troy Cauble wrote:

> 
> If an MG is configured (via SNMP for example) to have some terminations
> disabled, and has sent the ServiceChange { Method = Forced } messages,
> what error should it return if it receives subsequent 
> Add/Move/Modify/etc. ?
> 
> ?    430 Unknown TerminationID    ?
> ?    530 Service Changing        ?
> 
> 
> -troy
> 

Similarly, if it receives a wildcard command or a wildcard return command
should it behave as if those terminations don't exist or should errors be
returned?

-troy




_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Jan  5 14:34:31 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29278
	for <megaco-archive@lists.ietf.org>; Mon, 5 Jan 2004 14:34:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdaUD-0000VS-CR; Mon, 05 Jan 2004 14:34:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdaTX-0000Ug-Me
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 14:33:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29150
	for <megaco@ietf.org>; Mon, 5 Jan 2004 14:33:16 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdaTU-0001bv-00
	for megaco@ietf.org; Mon, 05 Jan 2004 14:33:16 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdaRc-0001VG-00
	for megaco@ietf.org; Mon, 05 Jan 2004 14:31:22 -0500
Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdaPl-0001My-00
	for megaco@ietf.org; Mon, 05 Jan 2004 14:29:25 -0500
Received: from radvpost.RADVISION.com [192.168.216.29]
	by radvpost.radvision.com
	with XWall v3.28 ;
	Mon, 5 Jan 2004 14:29:10 -0500
Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19)
	id <V4QZ4AGB>; Mon, 5 Jan 2004 14:29:09 -0500
Message-ID: <A3851AA1B761E944912B20D1E95A7EFE0B0ADF@radvpost.radvision.com>
From: Steve Cipolli <SCipolli@radvision.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'Troy Cauble'"
	 <troy@bell-labs.com>
Cc: "'megaco@ietf.org'" <megaco@ietf.org>
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 	 L), & Short T imers (S)
Date: Mon, 5 Jan 2004 14:29:01 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3D3C2.2BE8F770"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no 
	version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3D3C2.2BE8F770
Content-Type: text/plain;
	charset="iso-8859-1"

Looks good.

--Stephen
-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Friday, January 02, 2004 9:58 AM
To: Steve Cipolli; Steve Cipolli; 'Troy Cauble'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)


OK.  I can see the benefit of both constructs.  Let me see.  How about:

>>If the Z specifier is not followed by a digit (0-9, A-K or the wildcard
X), then the MG shall reject the digitmap as invalid protocol.  When used
inside a range notation, the Z specifier applies solely to the immediately
following digit.  When used immediately prior to a range, the Z modifier
applies to all digits in the range (thereby requiring a match in the range
to be long duration).<<

Better?

Kevin




From: Steve Cipolli [mailto:SCipolli@radvision.com] 
Sent: Friday, December 12, 2003 5:31 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Steve Cipolli; 'Troy Cauble'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)


Kevin,

I think "ZX" and "Z[123]" should be valid.  Your additions seem to prohibit
these.  

On a related topic should an empty range specification ("[]") be rejected as
well, since nothing could possibly match it.

--Stephen

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Wednesday, December 10, 2003 7:35 PM
To: Steve Cipolli; 'Troy Cauble'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)


All, 
Here is some proposed text for this.  I will include this in the IG.  Please
let me know any changes that would be better.  New text is demarcated by
>><<.
7.1.14.3        DigitMap Syntax 
... 
In addition to these event symbols, the string may contain "S" and "L"
inter-event timing specifiers and the "Z" duration modifier. "S" and "L"
respectively indicate that the MG should use the short (S) timer or the long
(L) timer for subsequent events, overriding the timing rules described
above. If an explicit timing specifier is in effect in one alternative event
sequence, but none is given in any other candidate alternative, the timer
value set by the explicit timing specifier must be used. If all sequences
with explicit timing controls are dropped from the candidate set, timing
reverts to the default rules given above. >>If used inside a range notation,
the S and L specifiers shall be ignored.<<  Finally, if conflicting timing
specifiers are in effect in different alternative sequences, the long timer
shall be used.
A "Z" designates a long duration event: placed in front of the symbol(s)
designating the event(s) which satisfy a given digit position, it indicates
that that position is satisfied only if the duration of the event exceeds
the long-duration threshold. The value of this threshold is assumed to be
provisioned in the MG.  >>If the Z specifier is not followed by a digit (0-9
or A-K), then the MG shall reject the digitmap as invalid protocol.  When
used in a range notation, the Z specifier applies solely to the immediately
following digit.<<
Kevin 

snip...
 

------_=_NextPart_001_01C3D3C2.2BE8F770
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers =
( 	 L), &amp; Short T imers (S)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Looks good.</FONT>
</P>

<P><FONT SIZE=3D2>--Stephen</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Kevin Boyle [<A =
HREF=3D"mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, January 02, 2004 9:58 AM</FONT>
<BR><FONT SIZE=3D2>To: Steve Cipolli; Steve Cipolli; 'Troy =
Cauble'</FONT>
<BR><FONT SIZE=3D2>Cc: megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Megaco] Digit Maps: Long Duration =
Modifier(Z), Long Timers ( L), &amp; Short T imers (S)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>OK.&nbsp; I can see the benefit of both =
constructs.&nbsp; Let me see.&nbsp; How about:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;If the Z specifier is not followed by a digit =
(0-9, A-K or the wildcard X), then the MG shall reject the digitmap as =
invalid protocol.&nbsp; When used inside a range notation, the Z =
specifier applies solely to the immediately following digit.&nbsp; When =
used immediately prior to a range, the Z modifier applies to all digits =
in the range (thereby requiring a match in the range to be long =
duration).&lt;&lt;</FONT></P>

<P><FONT SIZE=3D2>Better?</FONT>
</P>

<P><FONT SIZE=3D2>Kevin</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>From: Steve Cipolli [<A =
HREF=3D"mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>=
] </FONT>
<BR><FONT SIZE=3D2>Sent: Friday, December 12, 2003 5:31 PM</FONT>
<BR><FONT SIZE=3D2>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Steve Cipolli; =
'Troy Cauble'</FONT>
<BR><FONT SIZE=3D2>Cc: megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Megaco] Digit Maps: Long Duration =
Modifier(Z), Long Timers ( L), &amp; Short T imers (S)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Kevin,</FONT>
</P>

<P><FONT SIZE=3D2>I think &quot;ZX&quot; and &quot;Z[123]&quot; should =
be valid.&nbsp; Your additions seem to prohibit these.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>On a related topic should an empty range =
specification (&quot;[]&quot;) be rejected as well, since nothing could =
possibly match it.</FONT></P>

<P><FONT SIZE=3D2>--Stephen</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Kevin Boyle [<A =
HREF=3D"mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, December 10, 2003 7:35 PM</FONT>
<BR><FONT SIZE=3D2>To: Steve Cipolli; 'Troy Cauble'</FONT>
<BR><FONT SIZE=3D2>Cc: megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Megaco] Digit Maps: Long Duration =
Modifier(Z), Long Timers ( L), &amp; Short T imers (S)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>All, </FONT>
<BR><FONT SIZE=3D2>Here is some proposed text for this.&nbsp; I will =
include this in the IG.&nbsp; Please let me know any changes that would =
be better.&nbsp; New text is demarcated by &gt;&gt;&lt;&lt;.</FONT></P>

<P><FONT SIZE=3D2>7.1.14.3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
DigitMap Syntax </FONT>
<BR><FONT SIZE=3D2>... </FONT>
<BR><FONT SIZE=3D2>In addition to these event symbols, the string may =
contain &quot;S&quot; and &quot;L&quot; inter-event timing specifiers =
and the &quot;Z&quot; duration modifier. &quot;S&quot; and =
&quot;L&quot; respectively indicate that the MG should use the short =
(S) timer or the long (L) timer for subsequent events, overriding the =
timing rules described above. If an explicit timing specifier is in =
effect in one alternative event sequence, but none is given in any =
other candidate alternative, the timer value set by the explicit timing =
specifier must be used. If all sequences with explicit timing controls =
are dropped from the candidate set, timing reverts to the default rules =
given above. &gt;&gt;If used inside a range notation, the S and L =
specifiers shall be ignored.&lt;&lt;&nbsp; Finally, if conflicting =
timing specifiers are in effect in different alternative sequences, the =
long timer shall be used.</FONT></P>

<P><FONT SIZE=3D2>A &quot;Z&quot; designates a long duration event: =
placed in front of the symbol(s) designating the event(s) which satisfy =
a given digit position, it indicates that that position is satisfied =
only if the duration of the event exceeds the long-duration threshold. =
The value of this threshold is assumed to be provisioned in the =
MG.&nbsp; &gt;&gt;If the Z specifier is not followed by a digit (0-9 or =
A-K), then the MG shall reject the digitmap as invalid protocol.&nbsp; =
When used in a range notation, the Z specifier applies solely to the =
immediately following digit.&lt;&lt;</FONT></P>

<P><FONT SIZE=3D2>Kevin </FONT>
</P>

<P><FONT SIZE=3D2>snip...</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3D3C2.2BE8F770--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Mon Jan  5 14:37:54 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29411
	for <megaco-archive@odin.ietf.org>; Mon, 5 Jan 2004 14:37:54 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdaXW-0000om-GF
	for megaco-archive@odin.ietf.org; Mon, 05 Jan 2004 14:37:26 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i05JbQvb003144
	for megaco-archive@odin.ietf.org; Mon, 5 Jan 2004 14:37:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdaXW-0000oa-96
	for megaco-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 14:37:26 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29392
	for <megaco-web-archive@ietf.org>; Mon, 5 Jan 2004 14:37:23 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdaXT-0001nB-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 14:37:23 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdaVd-0001jI-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 14:35:30 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdaUD-0001ff-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 14:34:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdaUD-0000VS-CR; Mon, 05 Jan 2004 14:34:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdaTX-0000Ug-Me
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 14:33:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29150
	for <megaco@ietf.org>; Mon, 5 Jan 2004 14:33:16 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdaTU-0001bv-00
	for megaco@ietf.org; Mon, 05 Jan 2004 14:33:16 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdaRc-0001VG-00
	for megaco@ietf.org; Mon, 05 Jan 2004 14:31:22 -0500
Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdaPl-0001My-00
	for megaco@ietf.org; Mon, 05 Jan 2004 14:29:25 -0500
Received: from radvpost.RADVISION.com [192.168.216.29]
	by radvpost.radvision.com
	with XWall v3.28 ;
	Mon, 5 Jan 2004 14:29:10 -0500
Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19)
	id <V4QZ4AGB>; Mon, 5 Jan 2004 14:29:09 -0500
Message-ID: <A3851AA1B761E944912B20D1E95A7EFE0B0ADF@radvpost.radvision.com>
From: Steve Cipolli <SCipolli@radvision.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'Troy Cauble'"
	 <troy@bell-labs.com>
Cc: "'megaco@ietf.org'" <megaco@ietf.org>
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 	 L), & Short T imers (S)
Date: Mon, 5 Jan 2004 14:29:01 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3D3C2.2BE8F770"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no 
	version=2.60

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3D3C2.2BE8F770
Content-Type: text/plain;
	charset="iso-8859-1"

Looks good.

--Stephen
-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Friday, January 02, 2004 9:58 AM
To: Steve Cipolli; Steve Cipolli; 'Troy Cauble'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)


OK.  I can see the benefit of both constructs.  Let me see.  How about:

>>If the Z specifier is not followed by a digit (0-9, A-K or the wildcard
X), then the MG shall reject the digitmap as invalid protocol.  When used
inside a range notation, the Z specifier applies solely to the immediately
following digit.  When used immediately prior to a range, the Z modifier
applies to all digits in the range (thereby requiring a match in the range
to be long duration).<<

Better?

Kevin




From: Steve Cipolli [mailto:SCipolli@radvision.com] 
Sent: Friday, December 12, 2003 5:31 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Steve Cipolli; 'Troy Cauble'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)


Kevin,

I think "ZX" and "Z[123]" should be valid.  Your additions seem to prohibit
these.  

On a related topic should an empty range specification ("[]") be rejected as
well, since nothing could possibly match it.

--Stephen

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Wednesday, December 10, 2003 7:35 PM
To: Steve Cipolli; 'Troy Cauble'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)


All, 
Here is some proposed text for this.  I will include this in the IG.  Please
let me know any changes that would be better.  New text is demarcated by
>><<.
7.1.14.3        DigitMap Syntax 
... 
In addition to these event symbols, the string may contain "S" and "L"
inter-event timing specifiers and the "Z" duration modifier. "S" and "L"
respectively indicate that the MG should use the short (S) timer or the long
(L) timer for subsequent events, overriding the timing rules described
above. If an explicit timing specifier is in effect in one alternative event
sequence, but none is given in any other candidate alternative, the timer
value set by the explicit timing specifier must be used. If all sequences
with explicit timing controls are dropped from the candidate set, timing
reverts to the default rules given above. >>If used inside a range notation,
the S and L specifiers shall be ignored.<<  Finally, if conflicting timing
specifiers are in effect in different alternative sequences, the long timer
shall be used.
A "Z" designates a long duration event: placed in front of the symbol(s)
designating the event(s) which satisfy a given digit position, it indicates
that that position is satisfied only if the duration of the event exceeds
the long-duration threshold. The value of this threshold is assumed to be
provisioned in the MG.  >>If the Z specifier is not followed by a digit (0-9
or A-K), then the MG shall reject the digitmap as invalid protocol.  When
used in a range notation, the Z specifier applies solely to the immediately
following digit.<<
Kevin 

snip...
 

------_=_NextPart_001_01C3D3C2.2BE8F770
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers =
( 	 L), &amp; Short T imers (S)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Looks good.</FONT>
</P>

<P><FONT SIZE=3D2>--Stephen</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Kevin Boyle [<A =
HREF=3D"mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, January 02, 2004 9:58 AM</FONT>
<BR><FONT SIZE=3D2>To: Steve Cipolli; Steve Cipolli; 'Troy =
Cauble'</FONT>
<BR><FONT SIZE=3D2>Cc: megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Megaco] Digit Maps: Long Duration =
Modifier(Z), Long Timers ( L), &amp; Short T imers (S)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>OK.&nbsp; I can see the benefit of both =
constructs.&nbsp; Let me see.&nbsp; How about:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;If the Z specifier is not followed by a digit =
(0-9, A-K or the wildcard X), then the MG shall reject the digitmap as =
invalid protocol.&nbsp; When used inside a range notation, the Z =
specifier applies solely to the immediately following digit.&nbsp; When =
used immediately prior to a range, the Z modifier applies to all digits =
in the range (thereby requiring a match in the range to be long =
duration).&lt;&lt;</FONT></P>

<P><FONT SIZE=3D2>Better?</FONT>
</P>

<P><FONT SIZE=3D2>Kevin</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>From: Steve Cipolli [<A =
HREF=3D"mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>=
] </FONT>
<BR><FONT SIZE=3D2>Sent: Friday, December 12, 2003 5:31 PM</FONT>
<BR><FONT SIZE=3D2>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Steve Cipolli; =
'Troy Cauble'</FONT>
<BR><FONT SIZE=3D2>Cc: megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Megaco] Digit Maps: Long Duration =
Modifier(Z), Long Timers ( L), &amp; Short T imers (S)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Kevin,</FONT>
</P>

<P><FONT SIZE=3D2>I think &quot;ZX&quot; and &quot;Z[123]&quot; should =
be valid.&nbsp; Your additions seem to prohibit these.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>On a related topic should an empty range =
specification (&quot;[]&quot;) be rejected as well, since nothing could =
possibly match it.</FONT></P>

<P><FONT SIZE=3D2>--Stephen</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Kevin Boyle [<A =
HREF=3D"mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, December 10, 2003 7:35 PM</FONT>
<BR><FONT SIZE=3D2>To: Steve Cipolli; 'Troy Cauble'</FONT>
<BR><FONT SIZE=3D2>Cc: megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Megaco] Digit Maps: Long Duration =
Modifier(Z), Long Timers ( L), &amp; Short T imers (S)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>All, </FONT>
<BR><FONT SIZE=3D2>Here is some proposed text for this.&nbsp; I will =
include this in the IG.&nbsp; Please let me know any changes that would =
be better.&nbsp; New text is demarcated by &gt;&gt;&lt;&lt;.</FONT></P>

<P><FONT SIZE=3D2>7.1.14.3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
DigitMap Syntax </FONT>
<BR><FONT SIZE=3D2>... </FONT>
<BR><FONT SIZE=3D2>In addition to these event symbols, the string may =
contain &quot;S&quot; and &quot;L&quot; inter-event timing specifiers =
and the &quot;Z&quot; duration modifier. &quot;S&quot; and =
&quot;L&quot; respectively indicate that the MG should use the short =
(S) timer or the long (L) timer for subsequent events, overriding the =
timing rules described above. If an explicit timing specifier is in =
effect in one alternative event sequence, but none is given in any =
other candidate alternative, the timer value set by the explicit timing =
specifier must be used. If all sequences with explicit timing controls =
are dropped from the candidate set, timing reverts to the default rules =
given above. &gt;&gt;If used inside a range notation, the S and L =
specifiers shall be ignored.&lt;&lt;&nbsp; Finally, if conflicting =
timing specifiers are in effect in different alternative sequences, the =
long timer shall be used.</FONT></P>

<P><FONT SIZE=3D2>A &quot;Z&quot; designates a long duration event: =
placed in front of the symbol(s) designating the event(s) which satisfy =
a given digit position, it indicates that that position is satisfied =
only if the duration of the event exceeds the long-duration threshold. =
The value of this threshold is assumed to be provisioned in the =
MG.&nbsp; &gt;&gt;If the Z specifier is not followed by a digit (0-9 or =
A-K), then the MG shall reject the digitmap as invalid protocol.&nbsp; =
When used in a range notation, the Z specifier applies solely to the =
immediately following digit.&lt;&lt;</FONT></P>

<P><FONT SIZE=3D2>Kevin </FONT>
</P>

<P><FONT SIZE=3D2>snip...</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3D3C2.2BE8F770--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Jan  5 17:26:32 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07349
	for <megaco-archive@lists.ietf.org>; Mon, 5 Jan 2004 17:26:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AddAg-0007bW-Up; Mon, 05 Jan 2004 17:26:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AddAU-0007aN-R1
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 17:25:55 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07321
	for <megaco@ietf.org>; Mon, 5 Jan 2004 17:25:42 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AddAI-0002Ce-00
	for megaco@ietf.org; Mon, 05 Jan 2004 17:25:38 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Add20-0001lJ-00
	for megaco@ietf.org; Mon, 05 Jan 2004 17:17:06 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Adcw9-0001R3-00
	for megaco@ietf.org; Mon, 05 Jan 2004 17:11:01 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i05MA5M03910
	for <megaco@ietf.org>; Mon, 5 Jan 2004 17:10:05 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2YFACWK>; Mon, 5 Jan 2004 17:10:06 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D8A74B0@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Dal Chohan <D.Chohan@ftel.co.uk>,
        "Tom-PT Taylor" <taylor@nortelnetworks.com>, gsachin@hss.hns.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Query Related to Automatic Metering
Date: Mon, 5 Jan 2004 17:10:00 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,EXCUSE_16 autolearn=no 
	version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Here's the IG text I have added.  Deletions marked by [[]], additions by
>><<.  If anyone has a problem with this wording change, please speak up!
 

7.5 Procedures

If the value of the parameter pc is zero or if this parameter is not
supplied by the MGC, then the repetitive application of metering pulses
should continue until [[either an event (other than pr) is detected, or
until the SignalsDescriptor is replaced with a new SignalsDescriptor that
does not include the signal em]]>>the signal is halted in any of the normal
ways<<. Any pulses applied due to a concurrent mpb signal shall be in
addition to the required repetitive pulses applied for the em signal.

If following the application of any metering pulse (regardless of whether it
was generated as a result of the signal em or as a result of the signal
mbp), the EventsDescriptor contains the event pr, and if the value of pcslr
is equal to the value of the EventsDescriptor parameter rp, then the pr
event shall be notified, and the value of the statistic pcslr shall be reset
to zero.  [[The detection of the event pr shall not cause the termination of
the signal em or the signal mbp, even if the KeepActive flag is not set for
the pr event.]]

 
Kevin


________________________________

	From: Dal Chohan [mailto:D.Chohan@ftel.co.uk] 
	Sent: Monday, January 05, 2004 7:23 AM
	To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH];
gsachin@hss.hns.com
	Cc: megaco@ietf.org
	Subject: Re: [Megaco] Query Related to Automatic Metering
	
	
	Shouldn't the clause 7.5 paragraph 5 procedures in the "amet"
package be modified so that they don't override the standard Events
Descriptor/KeepActive flag procedures defined in Megaco rather than
specifying something in the Implementation Guide? I recommend that the
offending sentence of clause 7.5 paragraph 5 "The detection of event pr
shall not cause the termination of the signal em or signal mbp, even if the
KeepActive flag is not set for the pr event" is deleted from the "amet"
package.
	 
	In addition there is a similar problem with clause 7.5 paragraph 4
of the "amet" package which also potentially overrides the standard Megaco
Events Descriptor/KeepActive flag and Signal Descriptor/KeepActive flag
procedures.
	 
	"If the value of the parameter pc is zero or if this parameter is
not supplied by the MGC, then the repetitive application of metering pulses
should continue until either an event (other than pr) is detected, or until
the SignalsDescriptor is replaced with a new SignalsDescriptor that does not
include the signal em. Any pulses applied due to a concurrent mpb signal
shall be in addition to the required repetitive pulses applied for the em
signal".
	 
	For example the meter pulses will continue even when an on-hook
event is detected providing the events descriptor that armed the on-hook
event had the KeepActive flag set. This action may be required for certain
territories where all outstanding meter pulses must be delivered even when
the analogue line is in the on-hook state.
	 
	Again the sentence above defining the SignalDescriptor procedures in
the "amet" package does not define anything new which is not already
specified in the standrad Megaco procedures. Hence I recommend that clause
7.5 paragraph 4 of the "amet" package be modified to read as:
	 
	"If the value of the parameter pc is zero or if this parameter is
not supplied by the MGC, then any pulses applied due to a concurrent mpb
signal shall be in addition to the required repetitive pulses applied for
the em signal"
	 
	 
	 
	Regards,
	 
	 
	 
	Dal Chohan.
	 
	 
	 
	----- Original Message ----- 
	From: "Kevin Boyle" <kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> >
	To: "Tom-PT Taylor" <taylor@nortelnetworks.com
<mailto:taylor@nortelnetworks.com> >; <gsachin@hss.hns.com
<mailto:gsachin@hss.hns.com> >
	Cc: <megaco@ietf.org <mailto:megaco@ietf.org> >
	Sent: Friday, January 02, 2004 3:19 PM
	Subject: RE: [Megaco] Query Related to Automatic Metering
	
	
	> Do we need an IG item?  I can add one for the upcoming meeting, if
we
	> believe that this should be fixed.
	> 
	> I would rather not have use of KA mandated.  Let the implementor
decide how
	> the event should interact with any signals.
	> 
	> Kevin
	> 
	> -----Original Message-----
	> From: Taylor, Tom-PT [CAR:5N00:EXCH] 
	> Sent: Monday, December 22, 2003 11:53 AM
	> To: gsachin@hss.hns.com <mailto:gsachin@hss.hns.com> 
	> Cc: megaco@ietf.org <mailto:megaco@ietf.org> 
	> Subject: Re: [Megaco] Query Related to Automatic Metering
	> 
	> I think you make a good point.  It's desirable to keep the
protocol intact,
	> rather than define exceptions within individual packages.
	> 
	> gsachin@hss.hns.com <mailto:gsachin@hss.hns.com>  wrote:
	> 
	> > 
	> > 
	> > 
	> > Hi List,
	> > 
	> > 
	> > this is a query regarding Periodic report event 'pr' defined in
AMET 
	> > package .the package procedure says that
	> > 
	> > "the detection of event pr shall not cause the termination of
the 
	> > signal em or signal mbp, even if the KeppActive(KA) flag is not
set 
	> > for the pr event"
	> > 
	> > what i feel is that the detection of the 'pr' event shall not
cause 
	> > the termination of any of the signals.
	> > 
	> > pls tell me if this is a correct assumption?
	> > 
	> > if yes, then i think here the package procedures should have
mandated 
	> > the use of KA flag with this event. Doing this will keep the
protocol 
	> > rules intact.
	> > 
	> > 
	> > 
	> > Regards
	> > Sachin Gupta
	> > 
	> > "DISCLAIMER: This message is proprietary to Hughes Software
Systems 
	> > Limited
	> > (HSS) and is intended solely for the use of the individual to
whom it 
	> > is addressed. It may contain  privileged or confidential
information 
	> > and should not be circulated or used for any purpose other than
for 
	> > what it is intended. If you have received this message in error,

	> > please notify the originator immediately. If you are not the
intended 
	> > recipient, you are notified that you are strictly prohibited
from 
	> > using, copying, altering, or disclosing the contents of this
message. 
	> > HSS accepts no responsibility for loss or damage arising from
the use 
	> > of the information transmitted by this email including damage
from virus."
	> > 
	> > 
	> > _______________________________________________
	> > Megaco mailing list
	> > Megaco@ietf.org <mailto:Megaco@ietf.org> 
	> > https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco> 
	> > 
	> 
	> 
	> _______________________________________________
	> Megaco mailing list
	> Megaco@ietf.org <mailto:Megaco@ietf.org> 
	> https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco> 
	> 
	> _______________________________________________
	> Megaco mailing list
	> Megaco@ietf.org <mailto:Megaco@ietf.org> 
	> https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco> 
	> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Mon Jan  5 17:36:06 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08056
	for <megaco-archive@odin.ietf.org>; Mon, 5 Jan 2004 17:36:05 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AddJy-00088v-Oq
	for megaco-archive@odin.ietf.org; Mon, 05 Jan 2004 17:35:39 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i05MZcv0031296
	for megaco-archive@odin.ietf.org; Mon, 5 Jan 2004 17:35:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AddJy-00088g-JW
	for megaco-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 17:35:38 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07968
	for <megaco-web-archive@ietf.org>; Mon, 5 Jan 2004 17:35:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AddJv-0003El-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 17:35:35 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AddHe-0002n0-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 17:33:15 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AddAy-0002EM-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 17:26:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AddAg-0007bW-Up; Mon, 05 Jan 2004 17:26:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AddAU-0007aN-R1
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 17:25:55 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07321
	for <megaco@ietf.org>; Mon, 5 Jan 2004 17:25:42 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AddAI-0002Ce-00
	for megaco@ietf.org; Mon, 05 Jan 2004 17:25:38 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Add20-0001lJ-00
	for megaco@ietf.org; Mon, 05 Jan 2004 17:17:06 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Adcw9-0001R3-00
	for megaco@ietf.org; Mon, 05 Jan 2004 17:11:01 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i05MA5M03910
	for <megaco@ietf.org>; Mon, 5 Jan 2004 17:10:05 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2YFACWK>; Mon, 5 Jan 2004 17:10:06 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D8A74B0@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Dal Chohan <D.Chohan@ftel.co.uk>,
        "Tom-PT Taylor" <taylor@nortelnetworks.com>, gsachin@hss.hns.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Query Related to Automatic Metering
Date: Mon, 5 Jan 2004 17:10:00 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,EXCUSE_16 autolearn=no 
	version=2.60

Here's the IG text I have added.  Deletions marked by [[]], additions by
>><<.  If anyone has a problem with this wording change, please speak up!
 

7.5 Procedures

If the value of the parameter pc is zero or if this parameter is not
supplied by the MGC, then the repetitive application of metering pulses
should continue until [[either an event (other than pr) is detected, or
until the SignalsDescriptor is replaced with a new SignalsDescriptor that
does not include the signal em]]>>the signal is halted in any of the normal
ways<<. Any pulses applied due to a concurrent mpb signal shall be in
addition to the required repetitive pulses applied for the em signal.

If following the application of any metering pulse (regardless of whether it
was generated as a result of the signal em or as a result of the signal
mbp), the EventsDescriptor contains the event pr, and if the value of pcslr
is equal to the value of the EventsDescriptor parameter rp, then the pr
event shall be notified, and the value of the statistic pcslr shall be reset
to zero.  [[The detection of the event pr shall not cause the termination of
the signal em or the signal mbp, even if the KeepActive flag is not set for
the pr event.]]

 
Kevin


________________________________

	From: Dal Chohan [mailto:D.Chohan@ftel.co.uk] 
	Sent: Monday, January 05, 2004 7:23 AM
	To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH];
gsachin@hss.hns.com
	Cc: megaco@ietf.org
	Subject: Re: [Megaco] Query Related to Automatic Metering
	
	
	Shouldn't the clause 7.5 paragraph 5 procedures in the "amet"
package be modified so that they don't override the standard Events
Descriptor/KeepActive flag procedures defined in Megaco rather than
specifying something in the Implementation Guide? I recommend that the
offending sentence of clause 7.5 paragraph 5 "The detection of event pr
shall not cause the termination of the signal em or signal mbp, even if the
KeepActive flag is not set for the pr event" is deleted from the "amet"
package.
	 
	In addition there is a similar problem with clause 7.5 paragraph 4
of the "amet" package which also potentially overrides the standard Megaco
Events Descriptor/KeepActive flag and Signal Descriptor/KeepActive flag
procedures.
	 
	"If the value of the parameter pc is zero or if this parameter is
not supplied by the MGC, then the repetitive application of metering pulses
should continue until either an event (other than pr) is detected, or until
the SignalsDescriptor is replaced with a new SignalsDescriptor that does not
include the signal em. Any pulses applied due to a concurrent mpb signal
shall be in addition to the required repetitive pulses applied for the em
signal".
	 
	For example the meter pulses will continue even when an on-hook
event is detected providing the events descriptor that armed the on-hook
event had the KeepActive flag set. This action may be required for certain
territories where all outstanding meter pulses must be delivered even when
the analogue line is in the on-hook state.
	 
	Again the sentence above defining the SignalDescriptor procedures in
the "amet" package does not define anything new which is not already
specified in the standrad Megaco procedures. Hence I recommend that clause
7.5 paragraph 4 of the "amet" package be modified to read as:
	 
	"If the value of the parameter pc is zero or if this parameter is
not supplied by the MGC, then any pulses applied due to a concurrent mpb
signal shall be in addition to the required repetitive pulses applied for
the em signal"
	 
	 
	 
	Regards,
	 
	 
	 
	Dal Chohan.
	 
	 
	 
	----- Original Message ----- 
	From: "Kevin Boyle" <kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> >
	To: "Tom-PT Taylor" <taylor@nortelnetworks.com
<mailto:taylor@nortelnetworks.com> >; <gsachin@hss.hns.com
<mailto:gsachin@hss.hns.com> >
	Cc: <megaco@ietf.org <mailto:megaco@ietf.org> >
	Sent: Friday, January 02, 2004 3:19 PM
	Subject: RE: [Megaco] Query Related to Automatic Metering
	
	
	> Do we need an IG item?  I can add one for the upcoming meeting, if
we
	> believe that this should be fixed.
	> 
	> I would rather not have use of KA mandated.  Let the implementor
decide how
	> the event should interact with any signals.
	> 
	> Kevin
	> 
	> -----Original Message-----
	> From: Taylor, Tom-PT [CAR:5N00:EXCH] 
	> Sent: Monday, December 22, 2003 11:53 AM
	> To: gsachin@hss.hns.com <mailto:gsachin@hss.hns.com> 
	> Cc: megaco@ietf.org <mailto:megaco@ietf.org> 
	> Subject: Re: [Megaco] Query Related to Automatic Metering
	> 
	> I think you make a good point.  It's desirable to keep the
protocol intact,
	> rather than define exceptions within individual packages.
	> 
	> gsachin@hss.hns.com <mailto:gsachin@hss.hns.com>  wrote:
	> 
	> > 
	> > 
	> > 
	> > Hi List,
	> > 
	> > 
	> > this is a query regarding Periodic report event 'pr' defined in
AMET 
	> > package .the package procedure says that
	> > 
	> > "the detection of event pr shall not cause the termination of
the 
	> > signal em or signal mbp, even if the KeppActive(KA) flag is not
set 
	> > for the pr event"
	> > 
	> > what i feel is that the detection of the 'pr' event shall not
cause 
	> > the termination of any of the signals.
	> > 
	> > pls tell me if this is a correct assumption?
	> > 
	> > if yes, then i think here the package procedures should have
mandated 
	> > the use of KA flag with this event. Doing this will keep the
protocol 
	> > rules intact.
	> > 
	> > 
	> > 
	> > Regards
	> > Sachin Gupta
	> > 
	> > "DISCLAIMER: This message is proprietary to Hughes Software
Systems 
	> > Limited
	> > (HSS) and is intended solely for the use of the individual to
whom it 
	> > is addressed. It may contain  privileged or confidential
information 
	> > and should not be circulated or used for any purpose other than
for 
	> > what it is intended. If you have received this message in error,

	> > please notify the originator immediately. If you are not the
intended 
	> > recipient, you are notified that you are strictly prohibited
from 
	> > using, copying, altering, or disclosing the contents of this
message. 
	> > HSS accepts no responsibility for loss or damage arising from
the use 
	> > of the information transmitted by this email including damage
from virus."
	> > 
	> > 
	> > _______________________________________________
	> > Megaco mailing list
	> > Megaco@ietf.org <mailto:Megaco@ietf.org> 
	> > https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco> 
	> > 
	> 
	> 
	> _______________________________________________
	> Megaco mailing list
	> Megaco@ietf.org <mailto:Megaco@ietf.org> 
	> https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco> 
	> 
	> _______________________________________________
	> Megaco mailing list
	> Megaco@ietf.org <mailto:Megaco@ietf.org> 
	> https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco> 
	> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Jan  5 17:39:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08627
	for <megaco-archive@lists.ietf.org>; Mon, 5 Jan 2004 17:39:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AddNE-0000Sc-RY; Mon, 05 Jan 2004 17:39:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AddN3-0000SC-Vd
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 17:38:49 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08425
	for <megaco@ietf.org>; Mon, 5 Jan 2004 17:38:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AddN1-0003mJ-00
	for megaco@ietf.org; Mon, 05 Jan 2004 17:38:47 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AddKx-0003Q1-00
	for megaco@ietf.org; Mon, 05 Jan 2004 17:36:40 -0500
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AddJ6-0002y7-00
	for megaco@ietf.org; Mon, 05 Jan 2004 17:34:44 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i05MYBe10087
	for <megaco@ietf.org>; Mon, 5 Jan 2004 16:34:12 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id RAA24166; Mon, 5 Jan 2004 17:34:09 -0500 (EST)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id RAA24162; Mon, 5 Jan 2004 17:34:08 -0500 (EST)
Message-ID: <3FF9E662.70705@bell-labs.com>
Date: Mon, 05 Jan 2004 17:34:10 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [Megaco] disabled terminations
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


(Re-sending after bounces...)

If an MG is configured (via SNMP for example) to have some terminations
disabled, and has sent the ServiceChange { Method = Forced } messages,
what error should it return if it receives subsequent Add/Move/Modify/etc. ?

?	430 Unknown TerminationID	?
?	530 Service Changing		?


Similarly, if it receives a wildcard command or a wildcard return command
should it behave as if those terminations don't exist or should errors be
returned?

-troy



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Mon Jan  5 17:42:08 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08978
	for <megaco-archive@odin.ietf.org>; Mon, 5 Jan 2004 17:42:08 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AddPp-0000d0-LE
	for megaco-archive@odin.ietf.org; Mon, 05 Jan 2004 17:41:41 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i05Mffuh002408
	for megaco-archive@odin.ietf.org; Mon, 5 Jan 2004 17:41:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AddPo-0000cd-3n
	for megaco-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 17:41:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08970
	for <megaco-web-archive@ietf.org>; Mon, 5 Jan 2004 17:41:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AddPi-00049P-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 17:41:34 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AddOQ-00043e-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 17:40:15 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AddNF-0003pG-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 17:39:01 -0500
Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org)
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1AddNF-0002Ep-Po
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 17:39:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AddNE-0000Sc-RY; Mon, 05 Jan 2004 17:39:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AddN3-0000SC-Vd
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 17:38:49 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08425
	for <megaco@ietf.org>; Mon, 5 Jan 2004 17:38:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AddN1-0003mJ-00
	for megaco@ietf.org; Mon, 05 Jan 2004 17:38:47 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AddKx-0003Q1-00
	for megaco@ietf.org; Mon, 05 Jan 2004 17:36:40 -0500
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AddJ6-0002y7-00
	for megaco@ietf.org; Mon, 05 Jan 2004 17:34:44 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i05MYBe10087
	for <megaco@ietf.org>; Mon, 5 Jan 2004 16:34:12 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id RAA24166; Mon, 5 Jan 2004 17:34:09 -0500 (EST)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id RAA24162; Mon, 5 Jan 2004 17:34:08 -0500 (EST)
Message-ID: <3FF9E662.70705@bell-labs.com>
Date: Mon, 05 Jan 2004 17:34:10 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Megaco] disabled terminations
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


(Re-sending after bounces...)

If an MG is configured (via SNMP for example) to have some terminations
disabled, and has sent the ServiceChange { Method = Forced } messages,
what error should it return if it receives subsequent Add/Move/Modify/etc. ?

?	430 Unknown TerminationID	?
?	530 Service Changing		?


Similarly, if it receives a wildcard command or a wildcard return command
should it behave as if those terminations don't exist or should errors be
returned?

-troy



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Jan  5 18:31:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11749
	for <megaco-archive@lists.ietf.org>; Mon, 5 Jan 2004 18:31:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdeBa-0002mt-Iw; Mon, 05 Jan 2004 18:31:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdeAu-0002c7-2X
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 18:30:20 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11627
	for <megaco@ietf.org>; Mon, 5 Jan 2004 18:30:15 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdeAq-0000CB-00
	for megaco@ietf.org; Mon, 05 Jan 2004 18:30:16 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Addvh-0006aH-00
	for megaco@ietf.org; Mon, 05 Jan 2004 18:14:39 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Addpn-0005cC-00
	for megaco@ietf.org; Mon, 05 Jan 2004 18:08:31 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 05 Jan 2004 15:15:11 +0000
Received: from sampathkw2k02 (dhcp-171-71-248-81.cisco.com [171.71.248.81])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id i05N7nJ6026677;
	Mon, 5 Jan 2004 15:07:49 -0800 (PST)
From: "Sampath Komanduri" <sampathk@cisco.com>
To: "'Troy Cauble'" <troy@bell-labs.com>, "'MEGACO list'" <megaco@ietf.org>
Subject: RE: [Megaco] disabled terminations
Date: Mon, 5 Jan 2004 15:07:44 -0800
Message-ID: <000701c3d3e0$bdac8140$51f847ab@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <3FF9E662.70705@bell-labs.com>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

I guess 502.

Here is the text from H.248.8...

4.2.37	Error Code #: 502 Name: Not ready
Definition: The command directed to a termination was not executed
because of the service state of the termination.
Package: -
Reference: -
Error Text in the error Descriptor: The service state is indicated in
the error text in the error descriptor.
Comment: -

Thanks,
Sampath


-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Troy Cauble
Sent: Monday, January 05, 2004 2:34 PM
To: MEGACO list
Subject: [Megaco] disabled terminations



(Re-sending after bounces...)

If an MG is configured (via SNMP for example) to have some terminations
disabled, and has sent the ServiceChange { Method = Forced } messages,
what error should it return if it receives subsequent
Add/Move/Modify/etc. ?

?	430 Unknown TerminationID	?
?	530 Service Changing		?


Similarly, if it receives a wildcard command or a wildcard return
command
should it behave as if those terminations don't exist or should errors
be
returned?

-troy



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Mon Jan  5 18:40:49 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13250
	for <megaco-archive@odin.ietf.org>; Mon, 5 Jan 2004 18:40:48 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdeKc-0003sJ-Oi
	for megaco-archive@odin.ietf.org; Mon, 05 Jan 2004 18:40:22 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i05NeMCD014894
	for megaco-archive@odin.ietf.org; Mon, 5 Jan 2004 18:40:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdeKc-0003s4-9o
	for megaco-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 18:40:22 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13071
	for <megaco-web-archive@ietf.org>; Mon, 5 Jan 2004 18:40:16 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdeKX-0002Y2-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 18:40:17 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdeGw-0001Xc-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 18:36:36 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdeBd-0000PJ-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 18:31:05 -0500
Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org)
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1AdeBc-0000ci-Qa
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 18:31:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdeBa-0002mt-Iw; Mon, 05 Jan 2004 18:31:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdeAu-0002c7-2X
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 18:30:20 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11627
	for <megaco@ietf.org>; Mon, 5 Jan 2004 18:30:15 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdeAq-0000CB-00
	for megaco@ietf.org; Mon, 05 Jan 2004 18:30:16 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Addvh-0006aH-00
	for megaco@ietf.org; Mon, 05 Jan 2004 18:14:39 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Addpn-0005cC-00
	for megaco@ietf.org; Mon, 05 Jan 2004 18:08:31 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 05 Jan 2004 15:15:11 +0000
Received: from sampathkw2k02 (dhcp-171-71-248-81.cisco.com [171.71.248.81])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id i05N7nJ6026677;
	Mon, 5 Jan 2004 15:07:49 -0800 (PST)
From: "Sampath Komanduri" <sampathk@cisco.com>
To: "'Troy Cauble'" <troy@bell-labs.com>, "'MEGACO list'" <megaco@ietf.org>
Subject: RE: [Megaco] disabled terminations
Date: Mon, 5 Jan 2004 15:07:44 -0800
Message-ID: <000701c3d3e0$bdac8140$51f847ab@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <3FF9E662.70705@bell-labs.com>
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I guess 502.

Here is the text from H.248.8...

4.2.37	Error Code #: 502 Name: Not ready
Definition: The command directed to a termination was not executed
because of the service state of the termination.
Package: -
Reference: -
Error Text in the error Descriptor: The service state is indicated in
the error text in the error descriptor.
Comment: -

Thanks,
Sampath


-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Troy Cauble
Sent: Monday, January 05, 2004 2:34 PM
To: MEGACO list
Subject: [Megaco] disabled terminations



(Re-sending after bounces...)

If an MG is configured (via SNMP for example) to have some terminations
disabled, and has sent the ServiceChange { Method = Forced } messages,
what error should it return if it receives subsequent
Add/Move/Modify/etc. ?

?	430 Unknown TerminationID	?
?	530 Service Changing		?


Similarly, if it receives a wildcard command or a wildcard return
command
should it behave as if those terminations don't exist or should errors
be
returned?

-troy



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Jan  5 19:12:28 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15098
	for <megaco-archive@lists.ietf.org>; Mon, 5 Jan 2004 19:12:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdepF-0005QJ-Oj; Mon, 05 Jan 2004 19:12:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdeoY-0005Dg-Qz
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 19:11:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15036
	for <megaco@ietf.org>; Mon, 5 Jan 2004 19:11:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdeoQ-0004jA-00
	for megaco@ietf.org; Mon, 05 Jan 2004 19:11:10 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Adej3-0004YS-00
	for megaco@ietf.org; Mon, 05 Jan 2004 19:05:38 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Adefg-0004O1-00
	for megaco@ietf.org; Mon, 05 Jan 2004 19:02:08 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id i05NE4v28381;
	Tue, 6 Jan 2004 10:14:04 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.171]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5MDTVL; Tue, 6 Jan 2004 10:15:14 +1100
Message-ID: <3FF9F064.2000202@ericsson.com>
Date: Tue, 06 Jan 2004 10:16:52 +1100
From: Christian Groves <Christian.Groves@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Troy Cauble <troy@bell-labs.com>
CC: MEGACO list <megaco@ietf.org>
Subject: Re: [Megaco] disabled terminations
References: <3FF9E662.70705@bell-labs.com>
In-Reply-To: <3FF9E662.70705@bell-labs.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ish7.ericsson.com.au id i05NE4v28381
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Hello Troy,

502 would be most appropriate:
"4.2.37	Error Code #: 502 Name: Not ready
Definition: The command directed to a termination was not executed becaus=
e of=20
the service state of the termination.
Package: =96
Reference: =96
Error Text in the error Descriptor: The service state is indicated in the=
 error=20
text in the error descriptor.
Comment: =96"

Christian


Troy Cauble wrote:

>=20
> (Re-sending after bounces...)
>=20
> If an MG is configured (via SNMP for example) to have some terminations
> disabled, and has sent the ServiceChange { Method =3D Forced } messages=
,
> what error should it return if it receives subsequent=20
> Add/Move/Modify/etc. ?
>=20
> ?    430 Unknown TerminationID    ?
> ?    530 Service Changing        ?
>=20
>=20
> Similarly, if it receives a wildcard command or a wildcard return comma=
nd
> should it behave as if those terminations don't exist or should errors =
be
> returned?
>=20
> -troy
>=20
>=20
>=20
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>=20


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Mon Jan  5 19:20:33 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15214
	for <megaco-archive@odin.ietf.org>; Mon, 5 Jan 2004 19:20:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Adex3-0005em-GW
	for megaco-archive@odin.ietf.org; Mon, 05 Jan 2004 19:20:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i060K5nW021738
	for megaco-archive@odin.ietf.org; Mon, 5 Jan 2004 19:20:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Adex3-0005eX-9n
	for megaco-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 19:20:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15204
	for <megaco-web-archive@ietf.org>; Mon, 5 Jan 2004 19:20:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Adeww-000518-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 19:19:58 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdetZ-0004td-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 19:16:30 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdepX-0004mD-00
	for megaco-web-archive@ietf.org; Mon, 05 Jan 2004 19:12:19 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdepF-0005QJ-Oj; Mon, 05 Jan 2004 19:12:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdeoY-0005Dg-Qz
	for megaco@optimus.ietf.org; Mon, 05 Jan 2004 19:11:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15036
	for <megaco@ietf.org>; Mon, 5 Jan 2004 19:11:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdeoQ-0004jA-00
	for megaco@ietf.org; Mon, 05 Jan 2004 19:11:10 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Adej3-0004YS-00
	for megaco@ietf.org; Mon, 05 Jan 2004 19:05:38 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Adefg-0004O1-00
	for megaco@ietf.org; Mon, 05 Jan 2004 19:02:08 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id i05NE4v28381;
	Tue, 6 Jan 2004 10:14:04 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.171]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5MDTVL; Tue, 6 Jan 2004 10:15:14 +1100
Message-ID: <3FF9F064.2000202@ericsson.com>
Date: Tue, 06 Jan 2004 10:16:52 +1100
From: Christian Groves <Christian.Groves@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Troy Cauble <troy@bell-labs.com>
CC: MEGACO list <megaco@ietf.org>
Subject: Re: [Megaco] disabled terminations
References: <3FF9E662.70705@bell-labs.com>
In-Reply-To: <3FF9E662.70705@bell-labs.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ish7.ericsson.com.au id i05NE4v28381
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hello Troy,

502 would be most appropriate:
"4.2.37	Error Code #: 502 Name: Not ready
Definition: The command directed to a termination was not executed becaus=
e of=20
the service state of the termination.
Package: =96
Reference: =96
Error Text in the error Descriptor: The service state is indicated in the=
 error=20
text in the error descriptor.
Comment: =96"

Christian


Troy Cauble wrote:

>=20
> (Re-sending after bounces...)
>=20
> If an MG is configured (via SNMP for example) to have some terminations
> disabled, and has sent the ServiceChange { Method =3D Forced } messages=
,
> what error should it return if it receives subsequent=20
> Add/Move/Modify/etc. ?
>=20
> ?    430 Unknown TerminationID    ?
> ?    530 Service Changing        ?
>=20
>=20
> Similarly, if it receives a wildcard command or a wildcard return comma=
nd
> should it behave as if those terminations don't exist or should errors =
be
> returned?
>=20
> -troy
>=20
>=20
>=20
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>=20


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Jan  6 16:13:32 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03941
	for <megaco-archive@lists.ietf.org>; Tue, 6 Jan 2004 16:13:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdyVY-0001fF-V8; Tue, 06 Jan 2004 16:13:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdyUv-0001eS-9L
	for megaco@optimus.ietf.org; Tue, 06 Jan 2004 16:12:21 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03910
	for <megaco@ietf.org>; Tue, 6 Jan 2004 16:12:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdyUj-0000cQ-00
	for megaco@ietf.org; Tue, 06 Jan 2004 16:12:09 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdyPL-0000Rg-00
	for megaco@ietf.org; Tue, 06 Jan 2004 16:06:37 -0500
Received: from [216.90.186.146] (helo=mail.ipnetfusion.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdyMC-0000HC-00
	for megaco@ietf.org; Tue, 06 Jan 2004 16:03:20 -0500
Received: from ipnetfusion.com (proxy.ipnetfusion.com [216.90.186.147])
	(authenticated)
	by mail.ipnetfusion.com (8.11.6/8.11.6) with ESMTP id i06L0TM18768
	for <megaco@ietf.org>; Tue, 6 Jan 2004 15:00:29 -0600
Message-ID: <3FFB21FF.6040306@ipnetfusion.com>
Date: Tue, 06 Jan 2004 15:00:47 -0600
From: Nicholas Garcia <ngarcia@ipnetfusion.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: megaco@ietf.org
Subject: [Megaco] 2 Physical Terminations in the same context?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hello,

I am currently working off of the ETSI TS 101 889-2 V1.1.1 (2002-08) 
Test Structure document and have a question. How can I get the MGC to 
send the MG an add request that will allow it to set up a Context with 
two Physical Terminations (who are already in the NULL context)?  Is it 
possible to do this without setting up any Ephemeral Terminations?

Thanks for the help,

Nick

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Tue Jan  6 16:16:58 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04162
	for <megaco-archive@odin.ietf.org>; Tue, 6 Jan 2004 16:16:58 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdyYw-0001wV-Mc
	for megaco-archive@odin.ietf.org; Tue, 06 Jan 2004 16:16:30 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i06LGUt8007463
	for megaco-archive@odin.ietf.org; Tue, 6 Jan 2004 16:16:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdyYw-0001wI-Gl
	for megaco-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 16:16:30 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04118
	for <megaco-web-archive@ietf.org>; Tue, 6 Jan 2004 16:16:27 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdyYu-0000w5-00
	for megaco-web-archive@ietf.org; Tue, 06 Jan 2004 16:16:28 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdyXI-0000nx-00
	for megaco-web-archive@ietf.org; Tue, 06 Jan 2004 16:14:48 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdyVl-0000et-00
	for megaco-web-archive@ietf.org; Tue, 06 Jan 2004 16:13:13 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdyVY-0001fF-V8; Tue, 06 Jan 2004 16:13:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AdyUv-0001eS-9L
	for megaco@optimus.ietf.org; Tue, 06 Jan 2004 16:12:21 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03910
	for <megaco@ietf.org>; Tue, 6 Jan 2004 16:12:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdyUj-0000cQ-00
	for megaco@ietf.org; Tue, 06 Jan 2004 16:12:09 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AdyPL-0000Rg-00
	for megaco@ietf.org; Tue, 06 Jan 2004 16:06:37 -0500
Received: from [216.90.186.146] (helo=mail.ipnetfusion.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AdyMC-0000HC-00
	for megaco@ietf.org; Tue, 06 Jan 2004 16:03:20 -0500
Received: from ipnetfusion.com (proxy.ipnetfusion.com [216.90.186.147])
	(authenticated)
	by mail.ipnetfusion.com (8.11.6/8.11.6) with ESMTP id i06L0TM18768
	for <megaco@ietf.org>; Tue, 6 Jan 2004 15:00:29 -0600
Message-ID: <3FFB21FF.6040306@ipnetfusion.com>
Date: Tue, 06 Jan 2004 15:00:47 -0600
From: Nicholas Garcia <ngarcia@ipnetfusion.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: megaco@ietf.org
Subject: [Megaco] 2 Physical Terminations in the same context?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello,

I am currently working off of the ETSI TS 101 889-2 V1.1.1 (2002-08) 
Test Structure document and have a question. How can I get the MGC to 
send the MG an add request that will allow it to set up a Context with 
two Physical Terminations (who are already in the NULL context)?  Is it 
possible to do this without setting up any Ephemeral Terminations?

Thanks for the help,

Nick

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Jan  6 23:20:40 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19911
	for <megaco-archive@lists.ietf.org>; Tue, 6 Jan 2004 23:20:39 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ae5Aq-0001dc-8T; Tue, 06 Jan 2004 23:20:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ae5Aj-0001cE-66
	for megaco@optimus.ietf.org; Tue, 06 Jan 2004 23:19:57 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19879
	for <megaco@ietf.org>; Tue, 6 Jan 2004 23:19:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ae5Ah-0004E2-00
	for megaco@ietf.org; Tue, 06 Jan 2004 23:19:55 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ae58p-00049z-00
	for megaco@ietf.org; Tue, 06 Jan 2004 23:18:00 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ae57o-00046P-00
	for megaco@ietf.org; Tue, 06 Jan 2004 23:16:56 -0500
Received: from sampathkw2k02 (dhcp-171-71-9-200.cisco.com [171.71.9.200])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i074GPGN012088;
	Tue, 6 Jan 2004 20:16:25 -0800 (PST)
From: "Sampath Komanduri" <sampathk@cisco.com>
To: "'MEGACO list'" <megaco@ietf.org>
Date: Tue, 6 Jan 2004 20:16:20 -0800
Message-ID: <001201c3d4d5$03e46c50$c80947ab@amer.cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0013_01C3D491.F5C12C50"
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: High
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE,
	X_MSMAIL_PRIORITY_HIGH,X_PRIORITY_HIGH autolearn=no version=2.60
Subject: [Megaco] TPKT value for H.248 over TCP
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C3D491.F5C12C50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi List,
I am not sure if this question was already raised in the list. If it
was, pls. point me to the discussion and the consensus.

According to ANNEX D of H.248.1 protocol, "TPKT, according to
<http://www.faqs.org/rfcs/rfc1006.html> RFC 1006, SHALL be used to
delineate messages within the TCP stream". RFC 1006 limits the size of
TPDU to 65524. Replicating the relevant text here for convenience:
 
***************************************************
     "A TPKT consists of two parts:  a packet-header and a TPDU.  
      The format of the header is constant regardless of the type of
packet.
      The format of the packet-header is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      vrsn     |    reserved   |          packet length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      where:

      vrsn                         8 bits

      This field is always 3 for the version of the protocol described
in this memo.

      packet length                16 bits (min=7, max=65535)

      This field contains the length of entire packet in octets,
including packet-header.
      This permits a maximum TPDU size of 65531 octets.
      Based on the size of the data transfer (DT) TPDU, this permits a
maximum 
      TSDU size of 65524 octets."
*********************************************************
 
This causes an issue. Based on the wildcard level of Audit and the
descriptors involved, this size could easily exceed 64K size (especially
if MG and MGC are using Long text format and white spaces in the
messages). In few cases, it is possible to return an error code (533:
Response exceeds maximum transport PDU size).
However, in some cases returning 533 is not an option. 
Consider for example the following scenario: After an association is
DISCONNECTED, MGC may want to want to get the list of non-null contexts
on the gateway using the following command (pls. ignore if there is any
mistake in the message and reply construct):
 
!/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}}
!/1 ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}}, ....and so
on}

In the best case (i.e. no white-space, no audit descriptor and short
format), this allows for an MG to have only 5000 active contexts on the
card. Anything more (or any variation in the audit command) will reduce
the number of active contexts that an MG can have even with TCP as the
transport option.
Responding with 533 is not an option here since that would leave MG-MGC
in state from where there is no elegant way out (at least from H.248
protocol).
 
How do the gurus' on list suggest we solve this issue? Couple of ideas
that come to mind are:

1.	Define a Bulk-Audit Package/scheme: As was done for MGCP, define
a Bulk-Audit package/scheme especially with support for       
    RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" and
    NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].
    This will certainly reduce the cases and scenarios when MG/MGC will
run into the issue under discussion but may not eliminate it.
2.	Add more information on W- Audit support in the protocol.
3.	Introduce RFC 1006 modification (with version field 4) such that
"packet length" of packet header in TPKT is 32 bits as opposed to 16
bits.
4.	Combination of the above schemes.
5.	Anything else?

Pls. advice on how this problem can be solved?

Thanks,
Sampath

------=_NextPart_000_0013_01C3D491.F5C12C50
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY><!-- Converted from text/plain format -->
<DIV><FONT face=3DArial size=3D2>Hi List,<BR>I am not sure if this =
question was=20
already raised in the list. If it was, pls. point me to the discussion =
and the=20
consensus.<BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>According to ANNEX D of H.248.1 =
protocol, "TPKT,=20
according to </FONT><A =
href=3D"http://www.faqs.org/rfcs/rfc1006.html"><FONT=20
face=3DArial size=3D2>RFC 1006</FONT></A><FONT face=3DArial size=3D2>, =
SHALL be used to=20
delineate messages within the TCP stream".&nbsp;RFC 1006&nbsp;limits the =
size=20
of&nbsp;TPDU to 65524. Replicating the relevant text here for=20
convenience:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>***************************************************</FONT></DIV>=

<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; "A TPKT =
consists of two=20
parts:&nbsp; a packet-header and a TPDU.&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
format of the=20
header is constant regardless of the type of=20
packet.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The format of the =
packet-header is as=20
follows:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
3<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0 1 2 3 4 5 6 7 8 9 0 1 =
2 3 4 5=20
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; vrsn&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;=20
reserved&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
packet length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR><BR>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
where:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
vrsn&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
8 bits<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This field is always 3 for =
the=20
version of the protocol described in this=20
memo.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet=20
length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
16 bits (min=3D7, max=3D65535)<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
This field=20
contains the length of entire packet in octets, including=20
packet-header.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp; This permits =
a maximum=20
TPDU size of 65531 octets.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp; Based on the =
size of the=20
data transfer (DT) TPDU, this permits a maximum </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
T</FONT><FONT=20
face=3DArial size=3D2>SDU size of 65524=20
octets."<BR>*********************************************************<BR>=
&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>This causes an issue. Based on =
the&nbsp;wildcard=20
level&nbsp;of Audit and the descriptors involved, this size could easily =
exceed=20
64K size (especially if MG and MGC are using Long text format and white =
spaces=20
in the messages). In few cases, it is possible to&nbsp;return =
an&nbsp;error code=20
(533: Response exceeds maximum transport PDU size).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>However, in some cases returning 533 is =
not an=20
option. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Consider for example the following =
scenario: After=20
an association is DISCONNECTED, MGC may want to want to get =
the&nbsp;list of=20
non-null contexts on the gateway using the following command (pls. =
ignore if=20
there is any mistake in the message and reply construct):</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT face=3DArial>!/1 [10.102.2.201]:4000=20
T=3D3700003{C=3D*{AV=3DROOT{AT{}}}}<BR></FONT><FONT face=3DArial>!/1=20
ABCD_MG&nbsp;P=3D3700003{C=3D</FONT></FONT><FONT face=3DArial=20
size=3D2>1{AV=3DC{*}},C=3D2<FONT face=3DArial>{AV=3DC{*}},C=3D3<FONT=20
face=3DArial>{AV=3DC{*}},&nbsp;....and so =
on}</FONT></FONT><BR></FONT><FONT=20
face=3DArial></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>In the best case (i.e. no white-space, =
no audit=20
descriptor&nbsp;and short format), this allows for an MG to have only =
5000=20
active contexts on the card. Anything more (or any variation in the =
audit=20
command) will reduce the number of active contexts that an MG can have =
even with=20
TCP as the transport option.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Responding with 533 is not an option =
here since=20
that would leave MG-MGC in state from where there is no elegant way out =
(at=20
least from H.248 protocol).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>How do the gurus' on list suggest we =
solve this=20
issue? Couple of ideas that come to mind are:</FONT></DIV>
<OL>
  <LI><FONT face=3DArial><FONT size=3D2>Define a Bulk-Audit =
Package/scheme: As was=20
  done for MGCP, define a Bulk-Audit package/scheme especially with =
support=20
  for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp;=20
  RangeWildcard =3D "[" NumericalRange *( "," NumericalRange ) "]"=20
  and<BR>&nbsp;&nbsp;&nbsp; NumericalRange&nbsp;&nbsp;&nbsp;&nbsp; =3D =
1*(DIGIT) [=20
  "-" 1*(DIGIT) ].<BR>&nbsp;&nbsp;&nbsp; This will certainly reduce the =
cases=20
  and scenarios when MG/MGC will run into the issue under discussion but =
may not=20
  eliminate it.</FONT></FONT></LI>
  <LI><FONT face=3DArial size=3D2>Add more information on W- Audit =
support in the=20
  protocol.</FONT></LI>
  <LI><FONT face=3DArial><FONT size=3D2>Introduce RFC 1006 modification =
(with=20
  version field 4) such that "packet length" of packet header in TPKT is =
32 bits=20
  as opposed to 16 bits.</FONT></FONT></LI>
  <LI><FONT face=3DArial><FONT size=3D2>Combination of the above=20
  schemes.</FONT></FONT></LI>
  <LI><FONT face=3DArial size=3D2>Anything else?</FONT></LI></OL>
<DIV><FONT face=3DArial size=3D2>Pls. advice on how this problem can be=20
solved?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT =
face=3DArial=20
size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
size=3D2></FONT><FONT face=3DArial size=3D2></FONT><BR><FONT =
face=3DArial><FONT=20
size=3D2>Thanks,<BR>Sampath</FONT></DIV></FONT></BODY></HTML>

------=_NextPart_000_0013_01C3D491.F5C12C50--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Tue Jan  6 23:24:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20006
	for <megaco-archive@odin.ietf.org>; Tue, 6 Jan 2004 23:24:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ae5Ef-0001oV-G1
	for megaco-archive@odin.ietf.org; Tue, 06 Jan 2004 23:24:01 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i074O1J9006965
	for megaco-archive@odin.ietf.org; Tue, 6 Jan 2004 23:24:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ae5Ef-0001oG-9Z
	for megaco-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 23:24:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19972
	for <megaco-web-archive@ietf.org>; Tue, 6 Jan 2004 23:23:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ae5Ed-0004N5-00
	for megaco-web-archive@ietf.org; Tue, 06 Jan 2004 23:23:59 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ae5Cq-0004IY-00
	for megaco-web-archive@ietf.org; Tue, 06 Jan 2004 23:22:12 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ae5Aw-0004FH-00
	for megaco-web-archive@ietf.org; Tue, 06 Jan 2004 23:20:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ae5Aq-0001dc-8T; Tue, 06 Jan 2004 23:20:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ae5Aj-0001cE-66
	for megaco@optimus.ietf.org; Tue, 06 Jan 2004 23:19:57 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19879
	for <megaco@ietf.org>; Tue, 6 Jan 2004 23:19:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ae5Ah-0004E2-00
	for megaco@ietf.org; Tue, 06 Jan 2004 23:19:55 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ae58p-00049z-00
	for megaco@ietf.org; Tue, 06 Jan 2004 23:18:00 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ae57o-00046P-00
	for megaco@ietf.org; Tue, 06 Jan 2004 23:16:56 -0500
Received: from sampathkw2k02 (dhcp-171-71-9-200.cisco.com [171.71.9.200])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i074GPGN012088;
	Tue, 6 Jan 2004 20:16:25 -0800 (PST)
From: "Sampath Komanduri" <sampathk@cisco.com>
To: "'MEGACO list'" <megaco@ietf.org>
Date: Tue, 6 Jan 2004 20:16:20 -0800
Message-ID: <001201c3d4d5$03e46c50$c80947ab@amer.cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0013_01C3D491.F5C12C50"
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: High
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: [Megaco] TPKT value for H.248 over TCP
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE,
	X_MSMAIL_PRIORITY_HIGH,X_PRIORITY_HIGH autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C3D491.F5C12C50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi List,
I am not sure if this question was already raised in the list. If it
was, pls. point me to the discussion and the consensus.

According to ANNEX D of H.248.1 protocol, "TPKT, according to
<http://www.faqs.org/rfcs/rfc1006.html> RFC 1006, SHALL be used to
delineate messages within the TCP stream". RFC 1006 limits the size of
TPDU to 65524. Replicating the relevant text here for convenience:
 
***************************************************
     "A TPKT consists of two parts:  a packet-header and a TPDU.  
      The format of the header is constant regardless of the type of
packet.
      The format of the packet-header is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      vrsn     |    reserved   |          packet length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      where:

      vrsn                         8 bits

      This field is always 3 for the version of the protocol described
in this memo.

      packet length                16 bits (min=7, max=65535)

      This field contains the length of entire packet in octets,
including packet-header.
      This permits a maximum TPDU size of 65531 octets.
      Based on the size of the data transfer (DT) TPDU, this permits a
maximum 
      TSDU size of 65524 octets."
*********************************************************
 
This causes an issue. Based on the wildcard level of Audit and the
descriptors involved, this size could easily exceed 64K size (especially
if MG and MGC are using Long text format and white spaces in the
messages). In few cases, it is possible to return an error code (533:
Response exceeds maximum transport PDU size).
However, in some cases returning 533 is not an option. 
Consider for example the following scenario: After an association is
DISCONNECTED, MGC may want to want to get the list of non-null contexts
on the gateway using the following command (pls. ignore if there is any
mistake in the message and reply construct):
 
!/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}}
!/1 ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}}, ....and so
on}

In the best case (i.e. no white-space, no audit descriptor and short
format), this allows for an MG to have only 5000 active contexts on the
card. Anything more (or any variation in the audit command) will reduce
the number of active contexts that an MG can have even with TCP as the
transport option.
Responding with 533 is not an option here since that would leave MG-MGC
in state from where there is no elegant way out (at least from H.248
protocol).
 
How do the gurus' on list suggest we solve this issue? Couple of ideas
that come to mind are:

1.	Define a Bulk-Audit Package/scheme: As was done for MGCP, define
a Bulk-Audit package/scheme especially with support for       
    RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" and
    NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].
    This will certainly reduce the cases and scenarios when MG/MGC will
run into the issue under discussion but may not eliminate it.
2.	Add more information on W- Audit support in the protocol.
3.	Introduce RFC 1006 modification (with version field 4) such that
"packet length" of packet header in TPKT is 32 bits as opposed to 16
bits.
4.	Combination of the above schemes.
5.	Anything else?

Pls. advice on how this problem can be solved?

Thanks,
Sampath

------=_NextPart_000_0013_01C3D491.F5C12C50
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY><!-- Converted from text/plain format -->
<DIV><FONT face=3DArial size=3D2>Hi List,<BR>I am not sure if this =
question was=20
already raised in the list. If it was, pls. point me to the discussion =
and the=20
consensus.<BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>According to ANNEX D of H.248.1 =
protocol, "TPKT,=20
according to </FONT><A =
href=3D"http://www.faqs.org/rfcs/rfc1006.html"><FONT=20
face=3DArial size=3D2>RFC 1006</FONT></A><FONT face=3DArial size=3D2>, =
SHALL be used to=20
delineate messages within the TCP stream".&nbsp;RFC 1006&nbsp;limits the =
size=20
of&nbsp;TPDU to 65524. Replicating the relevant text here for=20
convenience:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>***************************************************</FONT></DIV>=

<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; "A TPKT =
consists of two=20
parts:&nbsp; a packet-header and a TPDU.&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
format of the=20
header is constant regardless of the type of=20
packet.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The format of the =
packet-header is as=20
follows:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
3<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0 1 2 3 4 5 6 7 8 9 0 1 =
2 3 4 5=20
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; vrsn&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;=20
reserved&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
packet length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR><BR>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
where:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
vrsn&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
8 bits<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This field is always 3 for =
the=20
version of the protocol described in this=20
memo.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet=20
length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
16 bits (min=3D7, max=3D65535)<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
This field=20
contains the length of entire packet in octets, including=20
packet-header.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp; This permits =
a maximum=20
TPDU size of 65531 octets.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp; Based on the =
size of the=20
data transfer (DT) TPDU, this permits a maximum </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
T</FONT><FONT=20
face=3DArial size=3D2>SDU size of 65524=20
octets."<BR>*********************************************************<BR>=
&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>This causes an issue. Based on =
the&nbsp;wildcard=20
level&nbsp;of Audit and the descriptors involved, this size could easily =
exceed=20
64K size (especially if MG and MGC are using Long text format and white =
spaces=20
in the messages). In few cases, it is possible to&nbsp;return =
an&nbsp;error code=20
(533: Response exceeds maximum transport PDU size).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>However, in some cases returning 533 is =
not an=20
option. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Consider for example the following =
scenario: After=20
an association is DISCONNECTED, MGC may want to want to get =
the&nbsp;list of=20
non-null contexts on the gateway using the following command (pls. =
ignore if=20
there is any mistake in the message and reply construct):</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT face=3DArial>!/1 [10.102.2.201]:4000=20
T=3D3700003{C=3D*{AV=3DROOT{AT{}}}}<BR></FONT><FONT face=3DArial>!/1=20
ABCD_MG&nbsp;P=3D3700003{C=3D</FONT></FONT><FONT face=3DArial=20
size=3D2>1{AV=3DC{*}},C=3D2<FONT face=3DArial>{AV=3DC{*}},C=3D3<FONT=20
face=3DArial>{AV=3DC{*}},&nbsp;....and so =
on}</FONT></FONT><BR></FONT><FONT=20
face=3DArial></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>In the best case (i.e. no white-space, =
no audit=20
descriptor&nbsp;and short format), this allows for an MG to have only =
5000=20
active contexts on the card. Anything more (or any variation in the =
audit=20
command) will reduce the number of active contexts that an MG can have =
even with=20
TCP as the transport option.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Responding with 533 is not an option =
here since=20
that would leave MG-MGC in state from where there is no elegant way out =
(at=20
least from H.248 protocol).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>How do the gurus' on list suggest we =
solve this=20
issue? Couple of ideas that come to mind are:</FONT></DIV>
<OL>
  <LI><FONT face=3DArial><FONT size=3D2>Define a Bulk-Audit =
Package/scheme: As was=20
  done for MGCP, define a Bulk-Audit package/scheme especially with =
support=20
  for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp;=20
  RangeWildcard =3D "[" NumericalRange *( "," NumericalRange ) "]"=20
  and<BR>&nbsp;&nbsp;&nbsp; NumericalRange&nbsp;&nbsp;&nbsp;&nbsp; =3D =
1*(DIGIT) [=20
  "-" 1*(DIGIT) ].<BR>&nbsp;&nbsp;&nbsp; This will certainly reduce the =
cases=20
  and scenarios when MG/MGC will run into the issue under discussion but =
may not=20
  eliminate it.</FONT></FONT></LI>
  <LI><FONT face=3DArial size=3D2>Add more information on W- Audit =
support in the=20
  protocol.</FONT></LI>
  <LI><FONT face=3DArial><FONT size=3D2>Introduce RFC 1006 modification =
(with=20
  version field 4) such that "packet length" of packet header in TPKT is =
32 bits=20
  as opposed to 16 bits.</FONT></FONT></LI>
  <LI><FONT face=3DArial><FONT size=3D2>Combination of the above=20
  schemes.</FONT></FONT></LI>
  <LI><FONT face=3DArial size=3D2>Anything else?</FONT></LI></OL>
<DIV><FONT face=3DArial size=3D2>Pls. advice on how this problem can be=20
solved?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT =
face=3DArial=20
size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
size=3D2></FONT><FONT face=3DArial size=3D2></FONT><BR><FONT =
face=3DArial><FONT=20
size=3D2>Thanks,<BR>Sampath</FONT></DIV></FONT></BODY></HTML>

------=_NextPart_000_0013_01C3D491.F5C12C50--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan  7 03:37:36 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27682
	for <megaco-archive@lists.ietf.org>; Wed, 7 Jan 2004 03:37:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ae9BW-00063L-EC; Wed, 07 Jan 2004 03:37:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ae9AY-00061x-2E
	for megaco@optimus.ietf.org; Wed, 07 Jan 2004 03:36:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27648
	for <megaco@ietf.org>; Wed, 7 Jan 2004 03:36:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ae9AV-00028h-00
	for megaco@ietf.org; Wed, 07 Jan 2004 03:35:59 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ae98Y-00024L-00
	for megaco@ietf.org; Wed, 07 Jan 2004 03:33:59 -0500
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ae96q-00021I-00
	for megaco@ietf.org; Wed, 07 Jan 2004 03:32:12 -0500
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id i078WBI2015384;
	Wed, 7 Jan 2004 09:32:12 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <ZJBQMSSW>; Wed, 7 Jan 2004 09:33:15 +0100
Message-ID: <F8EFC4B4A8C016428BC1F589296D4FBF05683E61@esealnt630.al.sw.ericsson.se>
From: "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>
To: "'Nicholas Garcia'" <ngarcia@ipnetfusion.com>, megaco@ietf.org
Subject: RE: [Megaco] 2 Physical Terminations in the same context?
Date: Wed, 7 Jan 2004 09:31:29 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


Hi,

You just send two ADDs, one for each physical termination. The protocol doesn't require you to always add an emphemeral termination to a context. It's the capabilities of the MG and MGC which define what context models you can use.

The H.248 protocol, however, doesn't specify what will trigger the MGC to do that (if that's what you are asking for).

Regards,

Christer Holmberg
Ericsson Finland





> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
> Nicholas Garcia
> Sent: 6. tammikuuta 2004 23:01
> To: megaco@ietf.org
> Subject: [Megaco] 2 Physical Terminations in the same context?
> 
> 
> Hello,
> 
> I am currently working off of the ETSI TS 101 889-2 V1.1.1 (2002-08) 
> Test Structure document and have a question. How can I get the MGC to 
> send the MG an add request that will allow it to set up a 
> Context with 
> two Physical Terminations (who are already in the NULL 
> context)?  Is it 
> possible to do this without setting up any Ephemeral Terminations?
> 
> Thanks for the help,
> 
> Nick
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan  7 03:40:32 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27822
	for <megaco-archive@odin.ietf.org>; Wed, 7 Jan 2004 03:40:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ae9EQ-0006TH-MV
	for megaco-archive@odin.ietf.org; Wed, 07 Jan 2004 03:40:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i078e2u9024845
	for megaco-archive@odin.ietf.org; Wed, 7 Jan 2004 03:40:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ae9EO-0006Se-8D
	for megaco-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 03:40:00 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27776
	for <megaco-web-archive@ietf.org>; Wed, 7 Jan 2004 03:39:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ae9EL-0002Jd-00
	for megaco-web-archive@ietf.org; Wed, 07 Jan 2004 03:39:57 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ae9CU-0002F0-00
	for megaco-web-archive@ietf.org; Wed, 07 Jan 2004 03:38:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ae9BZ-0002B9-00
	for megaco-web-archive@ietf.org; Wed, 07 Jan 2004 03:37:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ae9BW-00063L-EC; Wed, 07 Jan 2004 03:37:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ae9AY-00061x-2E
	for megaco@optimus.ietf.org; Wed, 07 Jan 2004 03:36:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27648
	for <megaco@ietf.org>; Wed, 7 Jan 2004 03:36:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ae9AV-00028h-00
	for megaco@ietf.org; Wed, 07 Jan 2004 03:35:59 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ae98Y-00024L-00
	for megaco@ietf.org; Wed, 07 Jan 2004 03:33:59 -0500
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ae96q-00021I-00
	for megaco@ietf.org; Wed, 07 Jan 2004 03:32:12 -0500
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id i078WBI2015384;
	Wed, 7 Jan 2004 09:32:12 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <ZJBQMSSW>; Wed, 7 Jan 2004 09:33:15 +0100
Message-ID: <F8EFC4B4A8C016428BC1F589296D4FBF05683E61@esealnt630.al.sw.ericsson.se>
From: "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>
To: "'Nicholas Garcia'" <ngarcia@ipnetfusion.com>, megaco@ietf.org
Subject: RE: [Megaco] 2 Physical Terminations in the same context?
Date: Wed, 7 Jan 2004 09:31:29 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60


Hi,

You just send two ADDs, one for each physical termination. The protocol doesn't require you to always add an emphemeral termination to a context. It's the capabilities of the MG and MGC which define what context models you can use.

The H.248 protocol, however, doesn't specify what will trigger the MGC to do that (if that's what you are asking for).

Regards,

Christer Holmberg
Ericsson Finland





> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
> Nicholas Garcia
> Sent: 6. tammikuuta 2004 23:01
> To: megaco@ietf.org
> Subject: [Megaco] 2 Physical Terminations in the same context?
> 
> 
> Hello,
> 
> I am currently working off of the ETSI TS 101 889-2 V1.1.1 (2002-08) 
> Test Structure document and have a question. How can I get the MGC to 
> send the MG an add request that will allow it to set up a 
> Context with 
> two Physical Terminations (who are already in the NULL 
> context)?  Is it 
> possible to do this without setting up any Ephemeral Terminations?
> 
> Thanks for the help,
> 
> Nick
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan  7 03:51:34 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28207
	for <megaco-archive@lists.ietf.org>; Wed, 7 Jan 2004 03:51:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ae9P5-0006kf-CU; Wed, 07 Jan 2004 03:51:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ae9O6-0006j4-Li
	for megaco@optimus.ietf.org; Wed, 07 Jan 2004 03:50:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28197
	for <megaco@ietf.org>; Wed, 7 Jan 2004 03:50:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ae9O4-0002vH-00
	for megaco@ietf.org; Wed, 07 Jan 2004 03:50:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ae9MV-0002sB-00
	for megaco@ietf.org; Wed, 07 Jan 2004 03:48:23 -0500
Received: from eagle.ericsson.se ([193.180.251.53])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ae9L4-0002l1-00
	for megaco@ietf.org; Wed, 07 Jan 2004 03:46:54 -0500
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id i078ks8K006940;
	Wed, 7 Jan 2004 09:46:54 +0100
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <ZJBQMXH8>; Wed, 7 Jan 2004 09:47:58 +0100
Message-ID: <F8EFC4B4A8C016428BC1F589296D4FBF05683E62@esealnt630.al.sw.ericsson.se>
From: "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>
To: "'Kumar'" <kumaraswamy.uppu@analog.com>, megaco@ietf.org
Subject: RE: [Megaco] How to differentiate Ephemeral and Physical Terminat
	ion
Date: Wed, 7 Jan 2004 09:46:14 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


Hi,

If your MG can't decide what kind of termination to add based on other information (descriptor values etc) provided I guess your MGC must use partly wildcarded termination Ids, where the non-wildcarded part of the termination Id speicfies the termination "type" (eg "RTP/$"). Please note that your MG may support multiple types of emphemeral- and physical terminations, so it may not be enough just two distinguish between those two - you need to specify exactly what type of emphemeral- or physical termination you want.

Regards,

Christer Holmberg
Ericsson Finland



> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
> Kumar
> Sent: 31. joulukuuta 2003 8:06
> To: megaco@ietf.org
> Subject: [Megaco] How to differentiate Ephemeral and Physical
> Termination
> 
> 
> Hi All,
> 
>     I have a question about termination ids.
> 
>     1. Is it OK to send add req with termination id as CHOOSE 
> for physical
> termination ? In general we get CHOOSE to add RTP termination 
> .If so, on MG
> side, how can I differentiate between Ephemeral (RTP) termination and
> physical termination ?
> 
> Thanks & Regards,
> Kumar
> 
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan  7 03:54:39 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28331
	for <megaco-archive@odin.ietf.org>; Wed, 7 Jan 2004 03:54:39 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ae9S6-0006tK-Rq
	for megaco-archive@odin.ietf.org; Wed, 07 Jan 2004 03:54:11 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i078sAB6026489
	for megaco-archive@odin.ietf.org; Wed, 7 Jan 2004 03:54:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ae9S6-0006t8-Bn
	for megaco-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 03:54:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28319
	for <megaco-web-archive@ietf.org>; Wed, 7 Jan 2004 03:54:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ae9S3-00037M-00
	for megaco-web-archive@ietf.org; Wed, 07 Jan 2004 03:54:07 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ae9Q9-00032j-00
	for megaco-web-archive@ietf.org; Wed, 07 Jan 2004 03:52:09 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ae9P7-0002xt-00
	for megaco-web-archive@ietf.org; Wed, 07 Jan 2004 03:51:05 -0500
Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org)
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1Ae9P9-0007xg-Hf
	for megaco-web-archive@ietf.org; Wed, 07 Jan 2004 03:51:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ae9P5-0006kf-CU; Wed, 07 Jan 2004 03:51:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ae9O6-0006j4-Li
	for megaco@optimus.ietf.org; Wed, 07 Jan 2004 03:50:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28197
	for <megaco@ietf.org>; Wed, 7 Jan 2004 03:50:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ae9O4-0002vH-00
	for megaco@ietf.org; Wed, 07 Jan 2004 03:50:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ae9MV-0002sB-00
	for megaco@ietf.org; Wed, 07 Jan 2004 03:48:23 -0500
Received: from eagle.ericsson.se ([193.180.251.53])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ae9L4-0002l1-00
	for megaco@ietf.org; Wed, 07 Jan 2004 03:46:54 -0500
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id i078ks8K006940;
	Wed, 7 Jan 2004 09:46:54 +0100
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <ZJBQMXH8>; Wed, 7 Jan 2004 09:47:58 +0100
Message-ID: <F8EFC4B4A8C016428BC1F589296D4FBF05683E62@esealnt630.al.sw.ericsson.se>
From: "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>
To: "'Kumar'" <kumaraswamy.uppu@analog.com>, megaco@ietf.org
Subject: RE: [Megaco] How to differentiate Ephemeral and Physical Terminat
	ion
Date: Wed, 7 Jan 2004 09:46:14 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60


Hi,

If your MG can't decide what kind of termination to add based on other information (descriptor values etc) provided I guess your MGC must use partly wildcarded termination Ids, where the non-wildcarded part of the termination Id speicfies the termination "type" (eg "RTP/$"). Please note that your MG may support multiple types of emphemeral- and physical terminations, so it may not be enough just two distinguish between those two - you need to specify exactly what type of emphemeral- or physical termination you want.

Regards,

Christer Holmberg
Ericsson Finland



> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
> Kumar
> Sent: 31. joulukuuta 2003 8:06
> To: megaco@ietf.org
> Subject: [Megaco] How to differentiate Ephemeral and Physical
> Termination
> 
> 
> Hi All,
> 
>     I have a question about termination ids.
> 
>     1. Is it OK to send add req with termination id as CHOOSE 
> for physical
> termination ? In general we get CHOOSE to add RTP termination 
> .If so, on MG
> side, how can I differentiate between Ephemeral (RTP) termination and
> physical termination ?
> 
> Thanks & Regards,
> Kumar
> 
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan  7 09:44:31 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12545
	for <megaco-archive@lists.ietf.org>; Wed, 7 Jan 2004 09:44:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeEuf-0006oa-4U; Wed, 07 Jan 2004 09:44:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeEtu-0006oA-Ec
	for megaco@optimus.ietf.org; Wed, 07 Jan 2004 09:43:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12380
	for <megaco@ietf.org>; Wed, 7 Jan 2004 09:43:10 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeEtq-0006WR-00
	for megaco@ietf.org; Wed, 07 Jan 2004 09:43:10 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AeEs5-0006Is-00
	for megaco@ietf.org; Wed, 07 Jan 2004 09:41:22 -0500
Received: from [216.90.186.146] (helo=mail.ipnetfusion.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeEqQ-000636-00
	for megaco@ietf.org; Wed, 07 Jan 2004 09:39:38 -0500
Received: from ipnetfusion.com (proxy.ipnetfusion.com [216.90.186.147])
	(authenticated)
	by mail.ipnetfusion.com (8.11.6/8.11.6) with ESMTP id i07EdWM12423;
	Wed, 7 Jan 2004 08:39:32 -0600
Message-ID: <3FFC1A36.9090401@ipnetfusion.com>
Date: Wed, 07 Jan 2004 08:39:50 -0600
From: Nicholas Garcia <ngarcia@ipnetfusion.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>
CC: megaco@ietf.org
Subject: Re: [Megaco] 2 Physical Terminations in the same context?
References: <F8EFC4B4A8C016428BC1F589296D4FBF05683E61@esealnt630.al.sw.ericsson.se>
In-Reply-To: <F8EFC4B4A8C016428BC1F589296D4FBF05683E61@esealnt630.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Thanks for the help, that answered my question.

Nick


Christer Holmberg (JO/LMF) wrote:

>Hi,
>
>You just send two ADDs, one for each physical termination. The protocol doesn't require you to always add an emphemeral termination to a context. It's the capabilities of the MG and MGC which define what context models you can use.
>
>The H.248 protocol, however, doesn't specify what will trigger the MGC to do that (if that's what you are asking for).
>
>Regards,
>
>Christer Holmberg
>Ericsson Finland
>
>
>
>
>
>  
>
>>-----Original Message-----
>>From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
>>Nicholas Garcia
>>Sent: 6. tammikuuta 2004 23:01
>>To: megaco@ietf.org
>>Subject: [Megaco] 2 Physical Terminations in the same context?
>>
>>
>>Hello,
>>
>>I am currently working off of the ETSI TS 101 889-2 V1.1.1 (2002-08) 
>>Test Structure document and have a question. How can I get the MGC to 
>>send the MG an add request that will allow it to set up a 
>>Context with 
>>two Physical Terminations (who are already in the NULL 
>>context)?  Is it 
>>possible to do this without setting up any Ephemeral Terminations?
>>
>>Thanks for the help,
>>
>>Nick
>>
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>    
>>
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco
>
>  
>


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan  7 09:48:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12891
	for <megaco-archive@odin.ietf.org>; Wed, 7 Jan 2004 09:48:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeEyX-000780-E0
	for megaco-archive@odin.ietf.org; Wed, 07 Jan 2004 09:48:01 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i07Em1g7027396
	for megaco-archive@odin.ietf.org; Wed, 7 Jan 2004 09:48:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeEyX-00077n-B6
	for megaco-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 09:48:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12781
	for <megaco-web-archive@ietf.org>; Wed, 7 Jan 2004 09:47:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeEyV-0006sS-00
	for megaco-web-archive@ietf.org; Wed, 07 Jan 2004 09:47:59 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AeEwa-0006k5-00
	for megaco-web-archive@ietf.org; Wed, 07 Jan 2004 09:46:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeEug-0006aC-00
	for megaco-web-archive@ietf.org; Wed, 07 Jan 2004 09:44:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeEuf-0006oa-4U; Wed, 07 Jan 2004 09:44:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeEtu-0006oA-Ec
	for megaco@optimus.ietf.org; Wed, 07 Jan 2004 09:43:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12380
	for <megaco@ietf.org>; Wed, 7 Jan 2004 09:43:10 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeEtq-0006WR-00
	for megaco@ietf.org; Wed, 07 Jan 2004 09:43:10 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AeEs5-0006Is-00
	for megaco@ietf.org; Wed, 07 Jan 2004 09:41:22 -0500
Received: from [216.90.186.146] (helo=mail.ipnetfusion.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeEqQ-000636-00
	for megaco@ietf.org; Wed, 07 Jan 2004 09:39:38 -0500
Received: from ipnetfusion.com (proxy.ipnetfusion.com [216.90.186.147])
	(authenticated)
	by mail.ipnetfusion.com (8.11.6/8.11.6) with ESMTP id i07EdWM12423;
	Wed, 7 Jan 2004 08:39:32 -0600
Message-ID: <3FFC1A36.9090401@ipnetfusion.com>
Date: Wed, 07 Jan 2004 08:39:50 -0600
From: Nicholas Garcia <ngarcia@ipnetfusion.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>
CC: megaco@ietf.org
Subject: Re: [Megaco] 2 Physical Terminations in the same context?
References: <F8EFC4B4A8C016428BC1F589296D4FBF05683E61@esealnt630.al.sw.ericsson.se>
In-Reply-To: <F8EFC4B4A8C016428BC1F589296D4FBF05683E61@esealnt630.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Thanks for the help, that answered my question.

Nick


Christer Holmberg (JO/LMF) wrote:

>Hi,
>
>You just send two ADDs, one for each physical termination. The protocol doesn't require you to always add an emphemeral termination to a context. It's the capabilities of the MG and MGC which define what context models you can use.
>
>The H.248 protocol, however, doesn't specify what will trigger the MGC to do that (if that's what you are asking for).
>
>Regards,
>
>Christer Holmberg
>Ericsson Finland
>
>
>
>
>
>  
>
>>-----Original Message-----
>>From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
>>Nicholas Garcia
>>Sent: 6. tammikuuta 2004 23:01
>>To: megaco@ietf.org
>>Subject: [Megaco] 2 Physical Terminations in the same context?
>>
>>
>>Hello,
>>
>>I am currently working off of the ETSI TS 101 889-2 V1.1.1 (2002-08) 
>>Test Structure document and have a question. How can I get the MGC to 
>>send the MG an add request that will allow it to set up a 
>>Context with 
>>two Physical Terminations (who are already in the NULL 
>>context)?  Is it 
>>possible to do this without setting up any Ephemeral Terminations?
>>
>>Thanks for the help,
>>
>>Nick
>>
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>    
>>
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco
>
>  
>


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan  7 15:51:32 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00460
	for <megaco-archive@lists.ietf.org>; Wed, 7 Jan 2004 15:51:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKdq-00006m-U3; Wed, 07 Jan 2004 15:51:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKdF-000052-Q5
	for megaco@optimus.ietf.org; Wed, 07 Jan 2004 15:50:25 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00425
	for <megaco@ietf.org>; Wed, 7 Jan 2004 15:50:23 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKdE-0002mR-00
	for megaco@ietf.org; Wed, 07 Jan 2004 15:50:24 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AeKbP-0002iF-00
	for megaco@ietf.org; Wed, 07 Jan 2004 15:48:32 -0500
Received: from [216.90.186.146] (helo=mail.ipnetfusion.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKaG-0002VP-00
	for megaco@ietf.org; Wed, 07 Jan 2004 15:47:20 -0500
Received: from ipnetfusion.com (proxy.ipnetfusion.com [216.90.186.147])
	(authenticated)
	by mail.ipnetfusion.com (8.11.6/8.11.6) with ESMTP id i07Kj3M26063;
	Wed, 7 Jan 2004 14:45:03 -0600
Message-ID: <3FFC6FE1.2010409@ipnetfusion.com>
Date: Wed, 07 Jan 2004 14:45:21 -0600
From: Nicholas Garcia <ngarcia@ipnetfusion.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: megaco@ietf.org
Subject: [Megaco] 4 Ephemeral terminations and no physical
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hello,

I understand that the MG can't control the termination requests sent by 
the MGC, but does anybody know of a case where the MGC would request 4 
ephemeral terminations in 2 contexts? or 4 ephemeral terminations in 
general with no physical terminations?

Thanks for the help,

Nick

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan  7 15:54:56 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00767
	for <megaco-archive@odin.ietf.org>; Wed, 7 Jan 2004 15:54:56 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKhA-0000Mm-3Q
	for megaco-archive@odin.ietf.org; Wed, 07 Jan 2004 15:54:28 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i07KsSOC001402
	for megaco-archive@odin.ietf.org; Wed, 7 Jan 2004 15:54:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKh9-0000MX-VG
	for megaco-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 15:54:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00614
	for <megaco-web-archive@ietf.org>; Wed, 7 Jan 2004 15:54:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKh8-00036R-00
	for megaco-web-archive@ietf.org; Wed, 07 Jan 2004 15:54:26 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AeKfE-0002vy-00
	for megaco-web-archive@ietf.org; Wed, 07 Jan 2004 15:52:29 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKdr-0002p1-00
	for megaco-web-archive@ietf.org; Wed, 07 Jan 2004 15:51:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKdq-00006m-U3; Wed, 07 Jan 2004 15:51:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKdF-000052-Q5
	for megaco@optimus.ietf.org; Wed, 07 Jan 2004 15:50:25 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00425
	for <megaco@ietf.org>; Wed, 7 Jan 2004 15:50:23 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKdE-0002mR-00
	for megaco@ietf.org; Wed, 07 Jan 2004 15:50:24 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AeKbP-0002iF-00
	for megaco@ietf.org; Wed, 07 Jan 2004 15:48:32 -0500
Received: from [216.90.186.146] (helo=mail.ipnetfusion.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKaG-0002VP-00
	for megaco@ietf.org; Wed, 07 Jan 2004 15:47:20 -0500
Received: from ipnetfusion.com (proxy.ipnetfusion.com [216.90.186.147])
	(authenticated)
	by mail.ipnetfusion.com (8.11.6/8.11.6) with ESMTP id i07Kj3M26063;
	Wed, 7 Jan 2004 14:45:03 -0600
Message-ID: <3FFC6FE1.2010409@ipnetfusion.com>
Date: Wed, 07 Jan 2004 14:45:21 -0600
From: Nicholas Garcia <ngarcia@ipnetfusion.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: megaco@ietf.org
Subject: [Megaco] 4 Ephemeral terminations and no physical
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello,

I understand that the MG can't control the termination requests sent by 
the MGC, but does anybody know of a case where the MGC would request 4 
ephemeral terminations in 2 contexts? or 4 ephemeral terminations in 
general with no physical terminations?

Thanks for the help,

Nick

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan  7 16:03:32 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01771
	for <megaco-archive@lists.ietf.org>; Wed, 7 Jan 2004 16:03:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKpT-00017d-19; Wed, 07 Jan 2004 16:03:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKon-0000nV-0o
	for megaco@optimus.ietf.org; Wed, 07 Jan 2004 16:02:21 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01636
	for <megaco@ietf.org>; Wed, 7 Jan 2004 16:02:18 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKol-0003aJ-00
	for megaco@ietf.org; Wed, 07 Jan 2004 16:02:19 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AeKmw-0003VM-00
	for megaco@ietf.org; Wed, 07 Jan 2004 16:00:27 -0500
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKlv-0003Q4-00
	for megaco@ietf.org; Wed, 07 Jan 2004 15:59:23 -0500
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120])
	by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id i07KxMSs021855;
	Wed, 7 Jan 2004 21:59:22 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <ZJBQSQAD>; Wed, 7 Jan 2004 22:00:28 +0100
Message-ID: <F8EFC4B4A8C016428BC1F589296D4FBF05683E71@esealnt630.al.sw.ericsson.se>
From: "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>
To: "'Nicholas Garcia'" <ngarcia@ipnetfusion.com>, megaco@ietf.org
Subject: RE: [Megaco] 4 Ephemeral terminations and no physical
Date: Wed, 7 Jan 2004 21:58:42 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


Hi,

>I understand that the MG can't control the termination 
>requests sent by the MGC, but does anybody know of a case where the MGC would 
>request 4 ephemeral terminations in 2 contexts? or 4 ephemeral terminations in 
>general with no physical terminations?

If you eg connect IP bearers only you will only have ephemeral terminations, and eg in conference cases you may have 4 (or any number) on terminations (ephemeral and/or physical) within a single context.

Why do you want to place terminations in different contexts, if you want those terminations to somehow be associated/connected with each other?

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan  7 16:06:52 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02167
	for <megaco-archive@odin.ietf.org>; Wed, 7 Jan 2004 16:06:52 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKsi-0001ae-65
	for megaco-archive@odin.ietf.org; Wed, 07 Jan 2004 16:06:24 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i07L6Ohc006106
	for megaco-archive@odin.ietf.org; Wed, 7 Jan 2004 16:06:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKsi-0001aP-1i
	for megaco-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 16:06:24 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02065
	for <megaco-web-archive@ietf.org>; Wed, 7 Jan 2004 16:06:21 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKsg-0003un-00
	for megaco-web-archive@ietf.org; Wed, 07 Jan 2004 16:06:22 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AeKr6-0003lx-00
	for megaco-web-archive@ietf.org; Wed, 07 Jan 2004 16:04:45 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKpS-0003dg-00
	for megaco-web-archive@ietf.org; Wed, 07 Jan 2004 16:03:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKpT-00017d-19; Wed, 07 Jan 2004 16:03:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKon-0000nV-0o
	for megaco@optimus.ietf.org; Wed, 07 Jan 2004 16:02:21 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01636
	for <megaco@ietf.org>; Wed, 7 Jan 2004 16:02:18 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKol-0003aJ-00
	for megaco@ietf.org; Wed, 07 Jan 2004 16:02:19 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AeKmw-0003VM-00
	for megaco@ietf.org; Wed, 07 Jan 2004 16:00:27 -0500
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKlv-0003Q4-00
	for megaco@ietf.org; Wed, 07 Jan 2004 15:59:23 -0500
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120])
	by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id i07KxMSs021855;
	Wed, 7 Jan 2004 21:59:22 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <ZJBQSQAD>; Wed, 7 Jan 2004 22:00:28 +0100
Message-ID: <F8EFC4B4A8C016428BC1F589296D4FBF05683E71@esealnt630.al.sw.ericsson.se>
From: "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>
To: "'Nicholas Garcia'" <ngarcia@ipnetfusion.com>, megaco@ietf.org
Subject: RE: [Megaco] 4 Ephemeral terminations and no physical
Date: Wed, 7 Jan 2004 21:58:42 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60


Hi,

>I understand that the MG can't control the termination 
>requests sent by the MGC, but does anybody know of a case where the MGC would 
>request 4 ephemeral terminations in 2 contexts? or 4 ephemeral terminations in 
>general with no physical terminations?

If you eg connect IP bearers only you will only have ephemeral terminations, and eg in conference cases you may have 4 (or any number) on terminations (ephemeral and/or physical) within a single context.

Why do you want to place terminations in different contexts, if you want those terminations to somehow be associated/connected with each other?

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan  7 16:11:34 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02321
	for <megaco-archive@lists.ietf.org>; Wed, 7 Jan 2004 16:11:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKxC-00026e-KX; Wed, 07 Jan 2004 16:11:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKwV-00024j-20
	for megaco@optimus.ietf.org; Wed, 07 Jan 2004 16:10:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02272
	for <megaco@ietf.org>; Wed, 7 Jan 2004 16:10:16 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKwT-00049Y-00
	for megaco@ietf.org; Wed, 07 Jan 2004 16:10:17 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AeKuo-00045Q-00
	for megaco@ietf.org; Wed, 07 Jan 2004 16:08:35 -0500
Received: from [216.90.186.146] (helo=mail.ipnetfusion.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKu0-0003qs-00
	for megaco@ietf.org; Wed, 07 Jan 2004 16:07:44 -0500
Received: from ipnetfusion.com (proxy.ipnetfusion.com [216.90.186.147])
	(authenticated)
	by mail.ipnetfusion.com (8.11.6/8.11.6) with ESMTP id i07L5eM26919;
	Wed, 7 Jan 2004 15:05:40 -0600
Message-ID: <3FFC74B7.7010506@ipnetfusion.com>
Date: Wed, 07 Jan 2004 15:05:59 -0600
From: Nicholas Garcia <ngarcia@ipnetfusion.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>
CC: megaco@ietf.org
Subject: Re: [Megaco] 4 Ephemeral terminations and no physical
References: <F8EFC4B4A8C016428BC1F589296D4FBF05683E71@esealnt630.al.sw.ericsson.se>
In-Reply-To: <F8EFC4B4A8C016428BC1F589296D4FBF05683E71@esealnt630.al.sw.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Christer,

Thanks for the quick response.  I am running simulations of a MG and the 
ETSI test case calls for 4 ephemeral terminations with two in each context.

Thanks again,

Nick

Christer Holmberg (JO/LMF) wrote:

>Hi,
>
>  
>
>>I understand that the MG can't control the termination 
>>requests sent by the MGC, but does anybody know of a case where the MGC would 
>>request 4 ephemeral terminations in 2 contexts? or 4 ephemeral terminations in 
>>general with no physical terminations?
>>    
>>
>
>If you eg connect IP bearers only you will only have ephemeral terminations, and eg in conference cases you may have 4 (or any number) on terminations (ephemeral and/or physical) within a single context.
>
>Why do you want to place terminations in different contexts, if you want those terminations to somehow be associated/connected with each other?
>
>Regards,
>
>Christer Holmberg
>Ericsson Finland
>
>  
>


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan  7 16:14:43 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02445
	for <megaco-archive@odin.ietf.org>; Wed, 7 Jan 2004 16:14:43 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeL0J-0002Fr-AJ
	for megaco-archive@odin.ietf.org; Wed, 07 Jan 2004 16:14:15 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i07LEFeX008661
	for megaco-archive@odin.ietf.org; Wed, 7 Jan 2004 16:14:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeL0J-0002Fc-60
	for megaco-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 16:14:15 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02412
	for <megaco-web-archive@ietf.org>; Wed, 7 Jan 2004 16:14:12 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeL0H-0004LY-00
	for megaco-web-archive@ietf.org; Wed, 07 Jan 2004 16:14:13 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AeKyW-0004HO-00
	for megaco-web-archive@ietf.org; Wed, 07 Jan 2004 16:12:25 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKxF-0004Ch-00
	for megaco-web-archive@ietf.org; Wed, 07 Jan 2004 16:11:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKxC-00026e-KX; Wed, 07 Jan 2004 16:11:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKwV-00024j-20
	for megaco@optimus.ietf.org; Wed, 07 Jan 2004 16:10:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02272
	for <megaco@ietf.org>; Wed, 7 Jan 2004 16:10:16 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKwT-00049Y-00
	for megaco@ietf.org; Wed, 07 Jan 2004 16:10:17 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AeKuo-00045Q-00
	for megaco@ietf.org; Wed, 07 Jan 2004 16:08:35 -0500
Received: from [216.90.186.146] (helo=mail.ipnetfusion.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKu0-0003qs-00
	for megaco@ietf.org; Wed, 07 Jan 2004 16:07:44 -0500
Received: from ipnetfusion.com (proxy.ipnetfusion.com [216.90.186.147])
	(authenticated)
	by mail.ipnetfusion.com (8.11.6/8.11.6) with ESMTP id i07L5eM26919;
	Wed, 7 Jan 2004 15:05:40 -0600
Message-ID: <3FFC74B7.7010506@ipnetfusion.com>
Date: Wed, 07 Jan 2004 15:05:59 -0600
From: Nicholas Garcia <ngarcia@ipnetfusion.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>
CC: megaco@ietf.org
Subject: Re: [Megaco] 4 Ephemeral terminations and no physical
References: <F8EFC4B4A8C016428BC1F589296D4FBF05683E71@esealnt630.al.sw.ericsson.se>
In-Reply-To: <F8EFC4B4A8C016428BC1F589296D4FBF05683E71@esealnt630.al.sw.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Christer,

Thanks for the quick response.  I am running simulations of a MG and the 
ETSI test case calls for 4 ephemeral terminations with two in each context.

Thanks again,

Nick

Christer Holmberg (JO/LMF) wrote:

>Hi,
>
>  
>
>>I understand that the MG can't control the termination 
>>requests sent by the MGC, but does anybody know of a case where the MGC would 
>>request 4 ephemeral terminations in 2 contexts? or 4 ephemeral terminations in 
>>general with no physical terminations?
>>    
>>
>
>If you eg connect IP bearers only you will only have ephemeral terminations, and eg in conference cases you may have 4 (or any number) on terminations (ephemeral and/or physical) within a single context.
>
>Why do you want to place terminations in different contexts, if you want those terminations to somehow be associated/connected with each other?
>
>Regards,
>
>Christer Holmberg
>Ericsson Finland
>
>  
>


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan  8 05:43:32 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16389
	for <megaco-archive@lists.ietf.org>; Thu, 8 Jan 2004 05:43:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeXcz-0007qo-Gf; Thu, 08 Jan 2004 05:43:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeXcV-0007pz-Lz
	for megaco@optimus.ietf.org; Thu, 08 Jan 2004 05:42:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16365
	for <megaco@ietf.org>; Thu, 8 Jan 2004 05:42:27 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeXcR-0000C3-00
	for megaco@ietf.org; Thu, 08 Jan 2004 05:42:28 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AeXah-00007B-00
	for megaco@ietf.org; Thu, 08 Jan 2004 05:40:40 -0500
Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1AeXa4-00000z-00
	for megaco@ietf.org; Thu, 08 Jan 2004 05:40:05 -0500
Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1073472905; Thu Jan  8 12:50:54 2004
Received: by MAILSERVER with Internet Mail Service (5.5.2657.72)
	id <Y7JR7ZJY>; Thu, 8 Jan 2004 12:39:16 +0200
Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F381016593@MAILSERVER>
From: Raphael Tryster <raphael@tdsoft.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>, megaco@ietf.org
Date: Thu, 8 Jan 2004 12:39:15 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3D5D3.A9B84F30"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE 
	autolearn=no version=2.60
Subject: [Megaco] call waiting signal type
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3D5D3.A9B84F30
Content-Type: text/plain;
	charset="iso-8859-1"

In draft_boyle_megaco_alerting_03.txt, the alert/cw signal has type brief,
whereas the standard signal dt/cw apparently has type timeout.  Is this a
matter of national protocol?  The description of alert/cw says "Call wait
patterns do not repeat".  In Israel, a call waiting signal consists of 3
short tones, repeated once a few seconds later.

If it is a matter of national protocol, does this mean that a particular
installation will use either alert/cw or dt/cw, but not both?

Raphael Tryster

------_=_NextPart_001_01C3D5D3.A9B84F30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-885=
9-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 5.5.2653.1=
2">
<TITLE>call waiting signal type</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">In</FONT> <FONT SIZE=3D2 FACE=3D"Arial">=
draft_boyle_megaco_alerting_03</FONT><FONT SIZE=3D2 FACE=3D"Arial">.txt, =
the alert/cw signal has type brief, whereas the standard signal dt/cw app=
arently has type timeout.&nbsp; Is this a matter of national protocol?&nb=
sp; The description of alert/cw says "</FONT><FONT SIZE=3D2 FACE=3D"Arial=
">Ca</FONT><FONT SIZE=3D2 FACE=3D"Arial">ll wait patterns do not repeat".=
&nbsp; In Israel, a call waiting signal consists of 3 short tones, repeat=
ed once a few seconds later.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If it is a matter of national protocol, =
does this mean that a particular installation will use either alert/cw or=
 dt/cw, but not both?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Tahoma">Raphael Tryster</FONT>
</P>

</BODY>
</HTML>

------_=_NextPart_001_01C3D5D3.A9B84F30--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan  8 05:47:06 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16557
	for <megaco-archive@odin.ietf.org>; Thu, 8 Jan 2004 05:47:06 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeXgU-00080m-Kn
	for megaco-archive@odin.ietf.org; Thu, 08 Jan 2004 05:46:39 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i08AkcOU030795
	for megaco-archive@odin.ietf.org; Thu, 8 Jan 2004 05:46:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeXgU-00080c-Hq
	for megaco-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 05:46:38 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16545
	for <megaco-web-archive@ietf.org>; Thu, 8 Jan 2004 05:46:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeXgQ-0000Ra-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 05:46:35 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AeXed-0000LG-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 05:44:44 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeXd0-0000Ev-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 05:43:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeXcz-0007qo-Gf; Thu, 08 Jan 2004 05:43:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeXcV-0007pz-Lz
	for megaco@optimus.ietf.org; Thu, 08 Jan 2004 05:42:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16365
	for <megaco@ietf.org>; Thu, 8 Jan 2004 05:42:27 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeXcR-0000C3-00
	for megaco@ietf.org; Thu, 08 Jan 2004 05:42:28 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AeXah-00007B-00
	for megaco@ietf.org; Thu, 08 Jan 2004 05:40:40 -0500
Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1AeXa4-00000z-00
	for megaco@ietf.org; Thu, 08 Jan 2004 05:40:05 -0500
Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1073472905; Thu Jan  8 12:50:54 2004
Received: by MAILSERVER with Internet Mail Service (5.5.2657.72)
	id <Y7JR7ZJY>; Thu, 8 Jan 2004 12:39:16 +0200
Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F381016593@MAILSERVER>
From: Raphael Tryster <raphael@tdsoft.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>, megaco@ietf.org
Date: Thu, 8 Jan 2004 12:39:15 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3D5D3.A9B84F30"
Subject: [Megaco] call waiting signal type
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE 
	autolearn=no version=2.60

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3D5D3.A9B84F30
Content-Type: text/plain;
	charset="iso-8859-1"

In draft_boyle_megaco_alerting_03.txt, the alert/cw signal has type brief,
whereas the standard signal dt/cw apparently has type timeout.  Is this a
matter of national protocol?  The description of alert/cw says "Call wait
patterns do not repeat".  In Israel, a call waiting signal consists of 3
short tones, repeated once a few seconds later.

If it is a matter of national protocol, does this mean that a particular
installation will use either alert/cw or dt/cw, but not both?

Raphael Tryster

------_=_NextPart_001_01C3D5D3.A9B84F30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-885=
9-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 5.5.2653.1=
2">
<TITLE>call waiting signal type</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">In</FONT> <FONT SIZE=3D2 FACE=3D"Arial">=
draft_boyle_megaco_alerting_03</FONT><FONT SIZE=3D2 FACE=3D"Arial">.txt, =
the alert/cw signal has type brief, whereas the standard signal dt/cw app=
arently has type timeout.&nbsp; Is this a matter of national protocol?&nb=
sp; The description of alert/cw says "</FONT><FONT SIZE=3D2 FACE=3D"Arial=
">Ca</FONT><FONT SIZE=3D2 FACE=3D"Arial">ll wait patterns do not repeat".=
&nbsp; In Israel, a call waiting signal consists of 3 short tones, repeat=
ed once a few seconds later.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If it is a matter of national protocol, =
does this mean that a particular installation will use either alert/cw or=
 dt/cw, but not both?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Tahoma">Raphael Tryster</FONT>
</P>

</BODY>
</HTML>

------_=_NextPart_001_01C3D5D3.A9B84F30--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan  8 09:43:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24617
	for <megaco-archive@lists.ietf.org>; Thu, 8 Jan 2004 09:43:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AebNF-0002nI-OW; Thu, 08 Jan 2004 09:43:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AebMG-0002kT-RT
	for megaco@optimus.ietf.org; Thu, 08 Jan 2004 09:42:00 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24543
	for <megaco@ietf.org>; Thu, 8 Jan 2004 09:41:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AebLq-0005zw-00
	for megaco@ietf.org; Thu, 08 Jan 2004 09:41:34 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AebJy-0005kh-00
	for megaco@ietf.org; Thu, 08 Jan 2004 09:39:39 -0500
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AebFq-0005YL-00
	for megaco@ietf.org; Thu, 08 Jan 2004 09:35:22 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i08EYCe03106
	for <megaco@ietf.org>; Thu, 8 Jan 2004 08:34:17 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id JAA16532; Thu, 8 Jan 2004 09:34:08 -0500 (EST)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id JAA16528; Thu, 8 Jan 2004 09:34:07 -0500 (EST)
Message-ID: <3FFD6A5D.9070504@bell-labs.com>
Date: Thu, 08 Jan 2004 09:34:05 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [Megaco] V1 vs V2
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Is there a document that calls out the differences between H.248 V1 & V2?
For someone moving a V1 implementation to V2, is their best option to
read both 140+ page documents and look for all the differences?

Is there an RFC version of H.248 V2?  RFC3015 is V1.
(V1 as of June '00, IIRC.)

Thanks,
-troy


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan  8 09:47:15 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24961
	for <megaco-archive@odin.ietf.org>; Thu, 8 Jan 2004 09:47:15 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AebQt-00035J-RJ
	for megaco-archive@odin.ietf.org; Thu, 08 Jan 2004 09:46:47 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i08Ekl6W011851
	for megaco-archive@odin.ietf.org; Thu, 8 Jan 2004 09:46:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AebQt-000354-NB
	for megaco-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 09:46:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24832
	for <megaco-web-archive@ietf.org>; Thu, 8 Jan 2004 09:46:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AebQr-0006hD-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 09:46:45 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AebOy-0006Ol-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 09:44:49 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AebNF-00069m-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 09:43:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AebNF-0002nI-OW; Thu, 08 Jan 2004 09:43:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AebMG-0002kT-RT
	for megaco@optimus.ietf.org; Thu, 08 Jan 2004 09:42:00 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24543
	for <megaco@ietf.org>; Thu, 8 Jan 2004 09:41:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AebLq-0005zw-00
	for megaco@ietf.org; Thu, 08 Jan 2004 09:41:34 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AebJy-0005kh-00
	for megaco@ietf.org; Thu, 08 Jan 2004 09:39:39 -0500
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AebFq-0005YL-00
	for megaco@ietf.org; Thu, 08 Jan 2004 09:35:22 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i08EYCe03106
	for <megaco@ietf.org>; Thu, 8 Jan 2004 08:34:17 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id JAA16532; Thu, 8 Jan 2004 09:34:08 -0500 (EST)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id JAA16528; Thu, 8 Jan 2004 09:34:07 -0500 (EST)
Message-ID: <3FFD6A5D.9070504@bell-labs.com>
Date: Thu, 08 Jan 2004 09:34:05 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Megaco] V1 vs V2
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Is there a document that calls out the differences between H.248 V1 & V2?
For someone moving a V1 implementation to V2, is their best option to
read both 140+ page documents and look for all the differences?

Is there an RFC version of H.248 V2?  RFC3015 is V1.
(V1 as of June '00, IIRC.)

Thanks,
-troy


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan  8 10:15:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27129
	for <megaco-archive@lists.ietf.org>; Thu, 8 Jan 2004 10:15:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AebsE-0004RS-Fq; Thu, 08 Jan 2004 10:15:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aebs6-0004R2-Ln
	for megaco@optimus.ietf.org; Thu, 08 Jan 2004 10:14:54 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27074
	for <megaco@ietf.org>; Thu, 8 Jan 2004 10:14:49 -0500 (EST)
From: Albrecht.Schwarz@alcatel.de
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aebrx-0000mj-00
	for megaco@ietf.org; Thu, 08 Jan 2004 10:14:45 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aebpg-0000fU-00
	for megaco@ietf.org; Thu, 08 Jan 2004 10:12:25 -0500
Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=sls26e.stgl.netd.alcatel.de)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aebnk-0000XG-00
	for megaco@ietf.org; Thu, 08 Jan 2004 10:10:24 -0500
Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205])
	by sls26e.stgl.netd.alcatel.de (8.12.10/8.12.10) with ESMTP id i08F9pqV004986;
	Thu, 8 Jan 2004 15:09:51 GMT
To: megaco@ietf.org
Cc: Thomas.Voith@alcatel.de
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF8D0F3225.A033BD1F-ONC1256E15.0052A7F6@netfr.alcatel.fr>
Date: Thu, 8 Jan 2004 16:09:50 +0100
X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 01/08/2004 16:09:50
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
X-Alcanet-virus-scanned: i08F9pqV004986 at sls26e.stgl.netd.alcatel.de
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=3.4 required=5.0 tests=NO_REAL_NAME,USERPASS 
	autolearn=no version=2.60
Subject: [Megaco] Drafts H.248.ICASCGEN & H.248.PCMSB; Re: 2 Q3/16 Contributions from ALCATEL
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hi all,

following two Package proposals will be presented to ITU-T in next SG16
meeting, starting 01/20
Please review. Any comments are appreciated.

Thanks

Albrecht


http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/Draft_H.248.ICASCGEN_ed03.zip


http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/Draft_H.248.PCMSB_ed08.zip




----- Forwarded by Albrecht SCHWARZ/DE/ALCATEL on 08.01.2004 16:02 -----
                                                                                                                                                    
                      OKUBO Sakae                                                                                                                   
                      <okubo@mxz.mesh.         To:      Albrecht SCHWARZ/DE/ALCATEL@ALCATEL                                                         
                      ne.jp>                   cc:      Thomas.Voith@alcatel.de, itu-sg16@external.cisco.com                                        
                      Sent by:                 Subject: Re: 2 Q3/16 Contributions from ALCATEL                                                      
                      owner-tsg16q3@it                                                                                                              
                      u.int                                                                                                                         
                                                                                                                                                    
                                                                                                                                                    
                      08.01.2004 15:48                                                                                                              
                      Please respond                                                                                                                
                      to OKUBO Sakae                                                                                                                
                                                                                                                                                    
                                                                                                                                                    




Dear Mr. Schwarz,

At 08:29 +0100 04/01/08, Albrecht.Schwarz@alcatel.de wrote:
>attached 2 delayed contributions were yesterday uploaded on the ITU
>server. May you please upload them on avc-site.

They are now available at the following place for advance review:


http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/Draft_H.248.ICASCGEN_ed03.zip


http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/Draft_H.248.PCMSB_ed08.zip


--
Best regards,

OKUBO Sakae
e-mail: sokubo@waseda.jp
Visiting Professor
Graduate School of Science and Engineering
Waseda University
*******************************************************************
<Yokosuka Research Park>
   Waseda University, YRP Ichibankan 312        Tel: +81 46 847 5406
   3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken  Fax: +81 46 847 5413
   239-0847 Japan
<Nishi-Waseda>
   29-7 Waseda University Bldg.                 Tel: +81 3 5286 9841
   1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo      Fax: +81 3 5286 3832
   169-0051 Japan
*******************************************************************





_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From megaco-admin@ietf.org  Thu Jan  8 10:24:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27451
	for <megaco-archive@lists.ietf.org>; Thu, 8 Jan 2004 10:24:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aec0v-0004uF-H2; Thu, 08 Jan 2004 10:24:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aec0U-0004tp-NE
	for megaco@optimus.ietf.org; Thu, 08 Jan 2004 10:23:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27444
	for <megaco@ietf.org>; Thu, 8 Jan 2004 10:23:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aec0L-0001Br-00
	for megaco@ietf.org; Thu, 08 Jan 2004 10:23:26 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aebve-0000wa-00
	for megaco@ietf.org; Thu, 08 Jan 2004 10:18:35 -0500
Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aebqp-0000jg-00
	for megaco@ietf.org; Thu, 08 Jan 2004 10:13:36 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i08FCjE29208
	for <megaco@ietf.org>; Thu, 8 Jan 2004 09:12:54 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id KAA16735; Thu, 8 Jan 2004 10:12:32 -0500 (EST)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id KAA16731; Thu, 8 Jan 2004 10:12:32 -0500 (EST)
Message-ID: <3FFD735E.3050002@bell-labs.com>
Date: Thu, 08 Jan 2004 10:12:30 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Subject: Re: [Megaco] V1 vs V2
References: <3FFD6A5D.9070504@bell-labs.com>
In-Reply-To: <3FFD6A5D.9070504@bell-labs.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Troy Cauble wrote:

> Is there a document that calls out the differences between H.248 V1 & V2?
> For someone moving a V1 implementation to V2, is their best option to
> read both 140+ page documents and look for all the differences?
> 
> Is there an RFC version of H.248 V2?  RFC3015 is V1.
> (V1 as of June '00, IIRC.)

Ok, I found the following expired draft:
http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248v2-04.txt

Does this correspond to the 05/02 H248.1 V2?  Or some other
date or IG?

-troy


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan  8 10:26:05 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27494
	for <megaco-archive@odin.ietf.org>; Thu, 8 Jan 2004 10:26:05 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aec2T-00057F-UK
	for megaco-archive@odin.ietf.org; Thu, 08 Jan 2004 10:25:38 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i08FPbbJ019664
	for megaco-archive@odin.ietf.org; Thu, 8 Jan 2004 10:25:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aec2T-000575-P7
	for megaco-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 10:25:37 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27483
	for <megaco-web-archive@ietf.org>; Thu, 8 Jan 2004 10:25:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aec2M-0001Fz-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 10:25:30 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aebvr-0000z3-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 10:18:48 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AebsX-0000n6-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 10:15:21 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AebsE-0004RS-Fq; Thu, 08 Jan 2004 10:15:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aebs6-0004R2-Ln
	for megaco@optimus.ietf.org; Thu, 08 Jan 2004 10:14:54 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27074
	for <megaco@ietf.org>; Thu, 8 Jan 2004 10:14:49 -0500 (EST)
From: Albrecht.Schwarz@alcatel.de
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aebrx-0000mj-00
	for megaco@ietf.org; Thu, 08 Jan 2004 10:14:45 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aebpg-0000fU-00
	for megaco@ietf.org; Thu, 08 Jan 2004 10:12:25 -0500
Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=sls26e.stgl.netd.alcatel.de)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aebnk-0000XG-00
	for megaco@ietf.org; Thu, 08 Jan 2004 10:10:24 -0500
Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205])
	by sls26e.stgl.netd.alcatel.de (8.12.10/8.12.10) with ESMTP id i08F9pqV004986;
	Thu, 8 Jan 2004 15:09:51 GMT
To: megaco@ietf.org
Cc: Thomas.Voith@alcatel.de
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF8D0F3225.A033BD1F-ONC1256E15.0052A7F6@netfr.alcatel.fr>
Date: Thu, 8 Jan 2004 16:09:50 +0100
X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 01/08/2004 16:09:50
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
X-Alcanet-virus-scanned: i08F9pqV004986 at sls26e.stgl.netd.alcatel.de
Subject: [Megaco] Drafts H.248.ICASCGEN & H.248.PCMSB; Re: 2 Q3/16 Contributions from ALCATEL
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=3.4 required=5.0 tests=NO_REAL_NAME,USERPASS 
	autolearn=no version=2.60

Hi all,

following two Package proposals will be presented to ITU-T in next SG16
meeting, starting 01/20
Please review. Any comments are appreciated.

Thanks

Albrecht


http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/Draft_H.248.ICASCGEN_ed03.zip


http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/Draft_H.248.PCMSB_ed08.zip




----- Forwarded by Albrecht SCHWARZ/DE/ALCATEL on 08.01.2004 16:02 -----
                                                                                                                                                    
                      OKUBO Sakae                                                                                                                   
                      <okubo@mxz.mesh.         To:      Albrecht SCHWARZ/DE/ALCATEL@ALCATEL                                                         
                      ne.jp>                   cc:      Thomas.Voith@alcatel.de, itu-sg16@external.cisco.com                                        
                      Sent by:                 Subject: Re: 2 Q3/16 Contributions from ALCATEL                                                      
                      owner-tsg16q3@it                                                                                                              
                      u.int                                                                                                                         
                                                                                                                                                    
                                                                                                                                                    
                      08.01.2004 15:48                                                                                                              
                      Please respond                                                                                                                
                      to OKUBO Sakae                                                                                                                
                                                                                                                                                    
                                                                                                                                                    




Dear Mr. Schwarz,

At 08:29 +0100 04/01/08, Albrecht.Schwarz@alcatel.de wrote:
>attached 2 delayed contributions were yesterday uploaded on the ITU
>server. May you please upload them on avc-site.

They are now available at the following place for advance review:


http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/Draft_H.248.ICASCGEN_ed03.zip


http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/Draft_H.248.PCMSB_ed08.zip


--
Best regards,

OKUBO Sakae
e-mail: sokubo@waseda.jp
Visiting Professor
Graduate School of Science and Engineering
Waseda University
*******************************************************************
<Yokosuka Research Park>
   Waseda University, YRP Ichibankan 312        Tel: +81 46 847 5406
   3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken  Fax: +81 46 847 5413
   239-0847 Japan
<Nishi-Waseda>
   29-7 Waseda University Bldg.                 Tel: +81 3 5286 9841
   1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo      Fax: +81 3 5286 3832
   169-0051 Japan
*******************************************************************





_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From exim@www1.ietf.org  Thu Jan  8 10:37:10 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28292
	for <megaco-archive@odin.ietf.org>; Thu, 8 Jan 2004 10:37:10 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AecDD-0005s9-Ra
	for megaco-archive@odin.ietf.org; Thu, 08 Jan 2004 10:36:43 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i08FahGI022567
	for megaco-archive@odin.ietf.org; Thu, 8 Jan 2004 10:36:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AecDD-0005ru-MJ
	for megaco-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 10:36:43 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28248
	for <megaco-web-archive@ietf.org>; Thu, 8 Jan 2004 10:36:39 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AecD6-0001qM-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 10:36:36 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aec5t-0001Ut-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 10:29:10 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aec1E-0001Ca-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 10:24:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aec0v-0004uF-H2; Thu, 08 Jan 2004 10:24:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aec0U-0004tp-NE
	for megaco@optimus.ietf.org; Thu, 08 Jan 2004 10:23:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27444
	for <megaco@ietf.org>; Thu, 8 Jan 2004 10:23:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aec0L-0001Br-00
	for megaco@ietf.org; Thu, 08 Jan 2004 10:23:26 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aebve-0000wa-00
	for megaco@ietf.org; Thu, 08 Jan 2004 10:18:35 -0500
Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aebqp-0000jg-00
	for megaco@ietf.org; Thu, 08 Jan 2004 10:13:36 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i08FCjE29208
	for <megaco@ietf.org>; Thu, 8 Jan 2004 09:12:54 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id KAA16735; Thu, 8 Jan 2004 10:12:32 -0500 (EST)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id KAA16731; Thu, 8 Jan 2004 10:12:32 -0500 (EST)
Message-ID: <3FFD735E.3050002@bell-labs.com>
Date: Thu, 08 Jan 2004 10:12:30 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Subject: Re: [Megaco] V1 vs V2
References: <3FFD6A5D.9070504@bell-labs.com>
In-Reply-To: <3FFD6A5D.9070504@bell-labs.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Troy Cauble wrote:

> Is there a document that calls out the differences between H.248 V1 & V2?
> For someone moving a V1 implementation to V2, is their best option to
> read both 140+ page documents and look for all the differences?
> 
> Is there an RFC version of H.248 V2?  RFC3015 is V1.
> (V1 as of June '00, IIRC.)

Ok, I found the following expired draft:
http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248v2-04.txt

Does this correspond to the 05/02 H248.1 V2?  Or some other
date or IG?

-troy


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan  8 11:41:33 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02042
	for <megaco-archive@lists.ietf.org>; Thu, 8 Jan 2004 11:41:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AedDT-0001pz-9X; Thu, 08 Jan 2004 11:41:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AedCw-0001ot-1F
	for megaco@optimus.ietf.org; Thu, 08 Jan 2004 11:40:30 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01971
	for <megaco@ietf.org>; Thu, 8 Jan 2004 11:40:27 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AedCu-00072U-00
	for megaco@ietf.org; Thu, 08 Jan 2004 11:40:28 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aed8F-0006Y5-00
	for megaco@ietf.org; Thu, 08 Jan 2004 11:35:39 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aed1g-0005qS-00
	for megaco@ietf.org; Thu, 08 Jan 2004 11:28:52 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i08GRte08859
	for <megaco@ietf.org>; Thu, 8 Jan 2004 11:27:55 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2YFBXWC>; Thu, 8 Jan 2004 11:27:56 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0DA8A0F4@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Raphael Tryster <raphael@tdsoft.com>, megaco@ietf.org
Date: Thu, 8 Jan 2004 11:27:55 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Megaco] RE: call waiting signal type
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Call wait patterns are generally replayed after a short amount of time (10
seconds in North America).  Note that this is not a repetition -- this is
actually a second distinct application of the signal.  There are several
feature scenarios where the second signal will not be applied -- if the
waiting party hangs up, or if the callee flashes, to name a couple.
 
As for the dt package, I believe the characterization of call wait tone as
timeout is erroneous, although previous attempts to fix it have been
rejected.  I wrote the alerting package to be local-variant unaware, leaving
it to the MG to be responsible for how the signals should be applied to its
terminations.  Note that most localities have more than one wait tone
pattern, to allow for assignable distinctive tones (similar to assigning
distinctive ringing patterns to different incoming callers).
 
I see no reason to use dt/cw if using alert/cw.  The alerting package
provides far more functionality than the dt package for both ringing and
call waiting.
 
Kevin


  _____  

From: Raphael Tryster [mailto:raphael@tdsoft.com] 
Sent: Thursday, January 08, 2004 5:39 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
Subject: call waiting signal type



In draft_boyle_megaco_alerting_03.txt, the alert/cw signal has type brief,
whereas the standard signal dt/cw apparently has type timeout.  Is this a
matter of national protocol?  The description of alert/cw says "Call wait
patterns do not repeat".  In Israel, a call waiting signal consists of 3
short tones, repeated once a few seconds later.

If it is a matter of national protocol, does this mean that a particular
installation will use either alert/cw or dt/cw, but not both?

Raphael Tryster 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan  8 11:45:14 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02325
	for <megaco-archive@odin.ietf.org>; Thu, 8 Jan 2004 11:45:14 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AedH4-00023L-U8
	for megaco-archive@odin.ietf.org; Thu, 08 Jan 2004 11:44:47 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i08Gik9U007885
	for megaco-archive@odin.ietf.org; Thu, 8 Jan 2004 11:44:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AedH4-000236-R6
	for megaco-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 11:44:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02298
	for <megaco-web-archive@ietf.org>; Thu, 8 Jan 2004 11:44:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AedGz-0007Ob-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 11:44:41 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AedFO-0007I1-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 11:43:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AedDV-00079k-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 11:41:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AedDT-0001pz-9X; Thu, 08 Jan 2004 11:41:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AedCw-0001ot-1F
	for megaco@optimus.ietf.org; Thu, 08 Jan 2004 11:40:30 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01971
	for <megaco@ietf.org>; Thu, 8 Jan 2004 11:40:27 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AedCu-00072U-00
	for megaco@ietf.org; Thu, 08 Jan 2004 11:40:28 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aed8F-0006Y5-00
	for megaco@ietf.org; Thu, 08 Jan 2004 11:35:39 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aed1g-0005qS-00
	for megaco@ietf.org; Thu, 08 Jan 2004 11:28:52 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i08GRte08859
	for <megaco@ietf.org>; Thu, 8 Jan 2004 11:27:55 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2YFBXWC>; Thu, 8 Jan 2004 11:27:56 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0DA8A0F4@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Raphael Tryster <raphael@tdsoft.com>, megaco@ietf.org
Date: Thu, 8 Jan 2004 11:27:55 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: [Megaco] RE: call waiting signal type
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60

Call wait patterns are generally replayed after a short amount of time (10
seconds in North America).  Note that this is not a repetition -- this is
actually a second distinct application of the signal.  There are several
feature scenarios where the second signal will not be applied -- if the
waiting party hangs up, or if the callee flashes, to name a couple.
 
As for the dt package, I believe the characterization of call wait tone as
timeout is erroneous, although previous attempts to fix it have been
rejected.  I wrote the alerting package to be local-variant unaware, leaving
it to the MG to be responsible for how the signals should be applied to its
terminations.  Note that most localities have more than one wait tone
pattern, to allow for assignable distinctive tones (similar to assigning
distinctive ringing patterns to different incoming callers).
 
I see no reason to use dt/cw if using alert/cw.  The alerting package
provides far more functionality than the dt package for both ringing and
call waiting.
 
Kevin


  _____  

From: Raphael Tryster [mailto:raphael@tdsoft.com] 
Sent: Thursday, January 08, 2004 5:39 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
Subject: call waiting signal type



In draft_boyle_megaco_alerting_03.txt, the alert/cw signal has type brief,
whereas the standard signal dt/cw apparently has type timeout.  Is this a
matter of national protocol?  The description of alert/cw says "Call wait
patterns do not repeat".  In Israel, a call waiting signal consists of 3
short tones, repeated once a few seconds later.

If it is a matter of national protocol, does this mean that a particular
installation will use either alert/cw or dt/cw, but not both?

Raphael Tryster 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan  8 14:41:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07653
	for <megaco-archive@lists.ietf.org>; Thu, 8 Jan 2004 14:41:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aeg1d-0002DB-T0; Thu, 08 Jan 2004 14:41:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aeg19-0002Bt-Pg
	for megaco@optimus.ietf.org; Thu, 08 Jan 2004 14:40:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07568
	for <megaco@ietf.org>; Thu, 8 Jan 2004 14:40:28 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aeg17-0001bB-00
	for megaco@ietf.org; Thu, 08 Jan 2004 14:40:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AefzC-0001UP-00
	for megaco@ietf.org; Thu, 08 Jan 2004 14:38:30 -0500
Received: from tor-vs2.business.allstream.net ([207.181.89.34] helo=mail.business.allstream.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AefxH-0001Kb-00
	for megaco@ietf.org; Thu, 08 Jan 2004 14:36:31 -0500
Received: from pcgson ([66.46.159.238])
	by mail.business.allstream.net (bela (1.1)/8.12.8) with SMTP id i08JaD4B005570;
	Thu, 8 Jan 2004 14:36:13 -0500 (EST)
From: "Giyeong Son" <gson@mediadigm.net>
To: "Christer Holmberg \(JO/LMF\)" <christer.holmberg@ericsson.com>,
        "'Nicholas Garcia'" <ngarcia@ipnetfusion.com>, <megaco@ietf.org>
Subject: RE: [Megaco] 4 Ephemeral terminations and no physical
Date: Thu, 8 Jan 2004 14:46:58 -0500
Message-ID: <MHEKJKIGAIAOFMMGBCPPIEMLCGAA.gson@mediadigm.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <F8EFC4B4A8C016428BC1F589296D4FBF05683E71@esealnt630.al.sw.ericsson.se>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,

If the below case is IP based conference, do you have any idea how to
support or represent mixer without using Topology Descriptors? Let's assume
that the number of ephemeral terminations is over 16 and the conference type
is centralized conference mode.

Regards,
Giyeong

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
Christer Holmberg (JO/LMF)
Sent: Wednesday, January 07, 2004 3:59 PM
To: 'Nicholas Garcia'; megaco@ietf.org
Subject: RE: [Megaco] 4 Ephemeral terminations and no physical



Hi,

>I understand that the MG can't control the termination
>requests sent by the MGC, but does anybody know of a case where the MGC
would
>request 4 ephemeral terminations in 2 contexts? or 4 ephemeral terminations
in
>general with no physical terminations?

If you eg connect IP bearers only you will only have ephemeral terminations,
and eg in conference cases you may have 4 (or any number) on terminations
(ephemeral and/or physical) within a single context.

Why do you want to place terminations in different contexts, if you want
those terminations to somehow be associated/connected with each other?

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan  8 14:45:09 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07806
	for <megaco-archive@odin.ietf.org>; Thu, 8 Jan 2004 14:45:09 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aeg5B-0002Xq-EA
	for megaco-archive@odin.ietf.org; Thu, 08 Jan 2004 14:44:42 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i08Jif64009782
	for megaco-archive@odin.ietf.org; Thu, 8 Jan 2004 14:44:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aeg5B-0002Xh-BH
	for megaco-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 14:44:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07757
	for <megaco-web-archive@ietf.org>; Thu, 8 Jan 2004 14:44:38 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aeg58-0001rc-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 14:44:38 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aeg3E-0001kX-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 14:42:41 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aeg1d-0001f7-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 14:41:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aeg1d-0002DB-T0; Thu, 08 Jan 2004 14:41:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aeg19-0002Bt-Pg
	for megaco@optimus.ietf.org; Thu, 08 Jan 2004 14:40:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07568
	for <megaco@ietf.org>; Thu, 8 Jan 2004 14:40:28 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aeg17-0001bB-00
	for megaco@ietf.org; Thu, 08 Jan 2004 14:40:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AefzC-0001UP-00
	for megaco@ietf.org; Thu, 08 Jan 2004 14:38:30 -0500
Received: from tor-vs2.business.allstream.net ([207.181.89.34] helo=mail.business.allstream.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AefxH-0001Kb-00
	for megaco@ietf.org; Thu, 08 Jan 2004 14:36:31 -0500
Received: from pcgson ([66.46.159.238])
	by mail.business.allstream.net (bela (1.1)/8.12.8) with SMTP id i08JaD4B005570;
	Thu, 8 Jan 2004 14:36:13 -0500 (EST)
From: "Giyeong Son" <gson@mediadigm.net>
To: "Christer Holmberg \(JO/LMF\)" <christer.holmberg@ericsson.com>,
        "'Nicholas Garcia'" <ngarcia@ipnetfusion.com>, <megaco@ietf.org>
Subject: RE: [Megaco] 4 Ephemeral terminations and no physical
Date: Thu, 8 Jan 2004 14:46:58 -0500
Message-ID: <MHEKJKIGAIAOFMMGBCPPIEMLCGAA.gson@mediadigm.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <F8EFC4B4A8C016428BC1F589296D4FBF05683E71@esealnt630.al.sw.ericsson.se>
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi,

If the below case is IP based conference, do you have any idea how to
support or represent mixer without using Topology Descriptors? Let's assume
that the number of ephemeral terminations is over 16 and the conference type
is centralized conference mode.

Regards,
Giyeong

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
Christer Holmberg (JO/LMF)
Sent: Wednesday, January 07, 2004 3:59 PM
To: 'Nicholas Garcia'; megaco@ietf.org
Subject: RE: [Megaco] 4 Ephemeral terminations and no physical



Hi,

>I understand that the MG can't control the termination
>requests sent by the MGC, but does anybody know of a case where the MGC
would
>request 4 ephemeral terminations in 2 contexts? or 4 ephemeral terminations
in
>general with no physical terminations?

If you eg connect IP bearers only you will only have ephemeral terminations,
and eg in conference cases you may have 4 (or any number) on terminations
(ephemeral and/or physical) within a single context.

Why do you want to place terminations in different contexts, if you want
those terminations to somehow be associated/connected with each other?

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan  8 14:47:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07968
	for <megaco-archive@lists.ietf.org>; Thu, 8 Jan 2004 14:47:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aeg7R-0002h8-RW; Thu, 08 Jan 2004 14:47:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aeg7I-0002gX-5z
	for megaco@optimus.ietf.org; Thu, 08 Jan 2004 14:46:52 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07939
	for <megaco@ietf.org>; Thu, 8 Jan 2004 14:46:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aeg7F-00021y-00
	for megaco@ietf.org; Thu, 08 Jan 2004 14:46:49 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aeg5c-0001vt-00
	for megaco@ietf.org; Thu, 08 Jan 2004 14:45:09 -0500
Received: from tor-vs2.business.allstream.net ([207.181.89.34] helo=mail.business.allstream.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aeg4k-0001o7-00
	for megaco@ietf.org; Thu, 08 Jan 2004 14:44:14 -0500
Received: from pcgson ([66.46.159.238])
	by mail.business.allstream.net (bela (1.1)/8.12.8) with SMTP id i08JiD4B009931
	for <megaco@ietf.org>; Thu, 8 Jan 2004 14:44:13 -0500 (EST)
From: "Giyeong Son" <gson@mediadigm.net>
To: <megaco@ietf.org>
Date: Thu, 8 Jan 2004 14:54:59 -0500
Message-ID: <MHEKJKIGAIAOFMMGBCPPOEMLCGAA.gson@mediadigm.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0DA8A0F4@zrtpd0jq.us.nortel.com>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Regarding conference support by MEGACO
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,

In order to support a pure IP based conference (i.e. with H.323 or SIP) with
MEGACO, is there any way to support or implement mixer in a conference
without using Topology Descriptors?

Regards,
Giyeong


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan  8 14:51:09 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08090
	for <megaco-archive@odin.ietf.org>; Thu, 8 Jan 2004 14:51:09 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AegB0-0002qb-4p
	for megaco-archive@odin.ietf.org; Thu, 08 Jan 2004 14:50:42 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i08JogY5010939
	for megaco-archive@odin.ietf.org; Thu, 8 Jan 2004 14:50:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AegAz-0002qM-V0
	for megaco-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 14:50:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08071
	for <megaco-web-archive@ietf.org>; Thu, 8 Jan 2004 14:50:38 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AegAx-0002C4-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 14:50:39 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aeg95-00027e-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 14:48:43 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aeg7R-000231-00
	for megaco-web-archive@ietf.org; Thu, 08 Jan 2004 14:47:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aeg7R-0002h8-RW; Thu, 08 Jan 2004 14:47:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aeg7I-0002gX-5z
	for megaco@optimus.ietf.org; Thu, 08 Jan 2004 14:46:52 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07939
	for <megaco@ietf.org>; Thu, 8 Jan 2004 14:46:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aeg7F-00021y-00
	for megaco@ietf.org; Thu, 08 Jan 2004 14:46:49 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aeg5c-0001vt-00
	for megaco@ietf.org; Thu, 08 Jan 2004 14:45:09 -0500
Received: from tor-vs2.business.allstream.net ([207.181.89.34] helo=mail.business.allstream.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aeg4k-0001o7-00
	for megaco@ietf.org; Thu, 08 Jan 2004 14:44:14 -0500
Received: from pcgson ([66.46.159.238])
	by mail.business.allstream.net (bela (1.1)/8.12.8) with SMTP id i08JiD4B009931
	for <megaco@ietf.org>; Thu, 8 Jan 2004 14:44:13 -0500 (EST)
From: "Giyeong Son" <gson@mediadigm.net>
To: <megaco@ietf.org>
Date: Thu, 8 Jan 2004 14:54:59 -0500
Message-ID: <MHEKJKIGAIAOFMMGBCPPOEMLCGAA.gson@mediadigm.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0DA8A0F4@zrtpd0jq.us.nortel.com>
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Regarding conference support by MEGACO
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi,

In order to support a pure IP based conference (i.e. with H.323 or SIP) with
MEGACO, is there any way to support or implement mixer in a conference
without using Topology Descriptors?

Regards,
Giyeong


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan  9 02:02:34 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05158
	for <megaco-archive@lists.ietf.org>; Fri, 9 Jan 2004 02:02:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aeqeg-0004Do-41; Fri, 09 Jan 2004 02:02:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeqeJ-0004CZ-0i
	for megaco@optimus.ietf.org; Fri, 09 Jan 2004 02:01:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04111
	for <megaco@ietf.org>; Fri, 9 Jan 2004 02:01:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aeqe8-0001Qq-00
	for megaco@ietf.org; Fri, 09 Jan 2004 02:01:28 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aeqcs-0001Jx-00
	for megaco@ietf.org; Fri, 09 Jan 2004 02:00:11 -0500
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeqWR-00018W-00
	for megaco@ietf.org; Fri, 09 Jan 2004 01:53:31 -0500
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id i096r5I2014022;
	Fri, 9 Jan 2004 07:53:05 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <ZJBQ0D9D>; Fri, 9 Jan 2004 07:54:13 +0100
Message-ID: <F8EFC4B4A8C016428BC1F589296D4FBF05683E7C@esealnt630.al.sw.ericsson.se>
From: "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>
To: "Christian Groves (MC/EPA)" <christian.groves@ericsson.com>,
        Giyeong Son <gson@mediadigm.net>
Cc: "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>,
        "'Nicholas Garcia'" <ngarcia@ipnetfusion.com>, megaco@ietf.org
Subject: RE: [Megaco] 4 Ephemeral terminations and no physical
Date: Fri, 9 Jan 2004 07:52:19 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


Hi,

I guess one could say that the "everbody talks to everybody" is the default value of the topology descriptor, which is used if you don't separately define and send one from the MGC to the MG.

Regards,

Christer Holmberg
Ericsson Finland


> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: 9. tammikuuta 2004 0:46
> To: Giyeong Son
> Cc: Christer Holmberg (JO/LMF); 'Nicholas Garcia'; megaco@ietf.org
> Subject: Re: [Megaco] 4 Ephemeral terminations and no physical
> 
> 
> Hello Giyeong,
> 
> If the conference is centralized conference where everybody 
> talks to everybody 
> then you do not need any topology descriptor. The standard 
> mode of H.248 is that 
> everybody can hear everybody in a context.
> 
> Christian
> 
> Giyeong Son wrote:
> 
> > Hi,
> > 
> > If the below case is IP based conference, do you have any 
> idea how to
> > support or represent mixer without using Topology 
> Descriptors? Let's assume
> > that the number of ephemeral terminations is over 16 and 
> the conference type
> > is centralized conference mode.
> > 
> > Regards,
> > Giyeong
> > 
> > -----Original Message-----
> > From: megaco-admin@ietf.org 
> [mailto:megaco-admin@ietf.org]On Behalf Of
> > Christer Holmberg (JO/LMF)
> > Sent: Wednesday, January 07, 2004 3:59 PM
> > To: 'Nicholas Garcia'; megaco@ietf.org
> > Subject: RE: [Megaco] 4 Ephemeral terminations and no physical
> > 
> > 
> > 
> > Hi,
> > 
> > 
> >>I understand that the MG can't control the termination
> >>requests sent by the MGC, but does anybody know of a case 
> where the MGC
> > 
> > would
> > 
> >>request 4 ephemeral terminations in 2 contexts? or 4 
> ephemeral terminations
> > 
> > in
> > 
> >>general with no physical terminations?
> > 
> > 
> > If you eg connect IP bearers only you will only have 
> ephemeral terminations,
> > and eg in conference cases you may have 4 (or any number) 
> on terminations
> > (ephemeral and/or physical) within a single context.
> > 
> > Why do you want to place terminations in different 
> contexts, if you want
> > those terminations to somehow be associated/connected with 
> each other?
> > 
> > Regards,
> > 
> > Christer Holmberg
> > Ericsson Finland
> > 
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> > 
> > 
> > 
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> > 
> 

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan  9 02:10:18 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12784
	for <megaco-archive@odin.ietf.org>; Fri, 9 Jan 2004 02:10:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeqmE-0005Hx-7z
	for megaco-archive@odin.ietf.org; Fri, 09 Jan 2004 02:09:50 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0979oPi020311
	for megaco-archive@odin.ietf.org; Fri, 9 Jan 2004 02:09:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeqmC-0005HW-Nb
	for megaco-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 02:09:48 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12259
	for <megaco-web-archive@ietf.org>; Fri, 9 Jan 2004 02:09:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aeqm4-0001hP-00
	for megaco-web-archive@ietf.org; Fri, 09 Jan 2004 02:09:40 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aeqj9-0001bA-00
	for megaco-web-archive@ietf.org; Fri, 09 Jan 2004 02:06:39 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aeqf1-0001RI-00
	for megaco-web-archive@ietf.org; Fri, 09 Jan 2004 02:02:23 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aeqeg-0004Do-41; Fri, 09 Jan 2004 02:02:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeqeJ-0004CZ-0i
	for megaco@optimus.ietf.org; Fri, 09 Jan 2004 02:01:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04111
	for <megaco@ietf.org>; Fri, 9 Jan 2004 02:01:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aeqe8-0001Qq-00
	for megaco@ietf.org; Fri, 09 Jan 2004 02:01:28 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aeqcs-0001Jx-00
	for megaco@ietf.org; Fri, 09 Jan 2004 02:00:11 -0500
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeqWR-00018W-00
	for megaco@ietf.org; Fri, 09 Jan 2004 01:53:31 -0500
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id i096r5I2014022;
	Fri, 9 Jan 2004 07:53:05 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <ZJBQ0D9D>; Fri, 9 Jan 2004 07:54:13 +0100
Message-ID: <F8EFC4B4A8C016428BC1F589296D4FBF05683E7C@esealnt630.al.sw.ericsson.se>
From: "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>
To: "Christian Groves (MC/EPA)" <christian.groves@ericsson.com>,
        Giyeong Son <gson@mediadigm.net>
Cc: "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>,
        "'Nicholas Garcia'" <ngarcia@ipnetfusion.com>, megaco@ietf.org
Subject: RE: [Megaco] 4 Ephemeral terminations and no physical
Date: Fri, 9 Jan 2004 07:52:19 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60


Hi,

I guess one could say that the "everbody talks to everybody" is the default value of the topology descriptor, which is used if you don't separately define and send one from the MGC to the MG.

Regards,

Christer Holmberg
Ericsson Finland


> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: 9. tammikuuta 2004 0:46
> To: Giyeong Son
> Cc: Christer Holmberg (JO/LMF); 'Nicholas Garcia'; megaco@ietf.org
> Subject: Re: [Megaco] 4 Ephemeral terminations and no physical
> 
> 
> Hello Giyeong,
> 
> If the conference is centralized conference where everybody 
> talks to everybody 
> then you do not need any topology descriptor. The standard 
> mode of H.248 is that 
> everybody can hear everybody in a context.
> 
> Christian
> 
> Giyeong Son wrote:
> 
> > Hi,
> > 
> > If the below case is IP based conference, do you have any 
> idea how to
> > support or represent mixer without using Topology 
> Descriptors? Let's assume
> > that the number of ephemeral terminations is over 16 and 
> the conference type
> > is centralized conference mode.
> > 
> > Regards,
> > Giyeong
> > 
> > -----Original Message-----
> > From: megaco-admin@ietf.org 
> [mailto:megaco-admin@ietf.org]On Behalf Of
> > Christer Holmberg (JO/LMF)
> > Sent: Wednesday, January 07, 2004 3:59 PM
> > To: 'Nicholas Garcia'; megaco@ietf.org
> > Subject: RE: [Megaco] 4 Ephemeral terminations and no physical
> > 
> > 
> > 
> > Hi,
> > 
> > 
> >>I understand that the MG can't control the termination
> >>requests sent by the MGC, but does anybody know of a case 
> where the MGC
> > 
> > would
> > 
> >>request 4 ephemeral terminations in 2 contexts? or 4 
> ephemeral terminations
> > 
> > in
> > 
> >>general with no physical terminations?
> > 
> > 
> > If you eg connect IP bearers only you will only have 
> ephemeral terminations,
> > and eg in conference cases you may have 4 (or any number) 
> on terminations
> > (ephemeral and/or physical) within a single context.
> > 
> > Why do you want to place terminations in different 
> contexts, if you want
> > those terminations to somehow be associated/connected with 
> each other?
> > 
> > Regards,
> > 
> > Christer Holmberg
> > Ericsson Finland
> > 
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> > 
> > 
> > 
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> > 
> 

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From mailman-admin@ietf.org  Fri Jan  9 12:59:10 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18676
	for <megaco-archive@lists.ietf.org>; Fri, 9 Jan 2004 12:59:10 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Af0uB-0000il-IM
	for megaco-archive@lists.ietf.org; Fri, 09 Jan 2004 12:58:43 -0500
Date: Fri, 09 Jan 2004 12:58:43 -0500
Message-ID: <20040109175843.9164.67054.Mailman@www1.ietf.org>
Subject: ietf.org mailing list memberships reminder
From: mailman-owner@www1.ietf.org
To: megaco-archive@ietf.org
X-No-Archive: yes
X-Ack: no
Sender: mailman-admin@ietf.org
Errors-To: mailman-admin@ietf.org
X-BeenThere: mailman@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk

This is a reminder, sent out once a month, about your ietf.org mailing
list memberships.  It includes your subscription info and how to use
it to change it or unsubscribe from a list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, megaco-request@ietf.org) containing just the
word 'help' in the message body, and an email message will be sent to
you with instructions.

***************************************************************************


                              Note Well

All statements related to the activities of the IETF and addressed to
the IETF are subject to all provisions of Section 10 of RFC 2026,
which grants to the IETF and its participants certain licenses and
rights in such statements. Such statements include verbal statements
in IETF meetings, as well as written and electronic communications
made at any time or place, which are addressed to

        * the IETF plenary session,
        * any IETF working group or portion thereof,
        * the IESG, or any member thereof on behalf of the IESG,
        * the IAB or any member thereof on behalf of the IAB,
        * any IETF mailing list, including the IETF list itself, any
working
            group or design team list, or any other list functioning
under IETF
            auspices,
        * the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other
function, that are clearly not intended to be input to an IETF
activity, group or function, are not subject to these provisions.

   
***************************************************************************


If you have questions, problems, comments, etc, send them to
mailman-owner@www1.ietf.org.  Thanks!

Passwords for megaco-archive@lists.ietf.org:

List                                     Password // URL
----                                     --------  
megaco@ietf.org                          rFKd      
https://www1.ietf.org/mailman/options/megaco/megaco-archive%40lists.ietf.org


From megaco-admin@ietf.org  Fri Jan  9 17:34:37 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24583
	for <megaco-archive@lists.ietf.org>; Fri, 9 Jan 2004 17:34:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Af5Cb-0002oK-4l; Fri, 09 Jan 2004 17:34:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Af5CY-0002o1-KG
	for megaco@optimus.ietf.org; Fri, 09 Jan 2004 17:33:58 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24569
	for <megaco@ietf.org>; Fri, 9 Jan 2004 17:33:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Af5CW-0000Cc-00
	for megaco@ietf.org; Fri, 09 Jan 2004 17:33:56 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Af5Aq-00007N-00
	for megaco@ietf.org; Fri, 09 Jan 2004 17:32:12 -0500
Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Af59Q-0007eI-00
	for megaco@ietf.org; Fri, 09 Jan 2004 17:30:44 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i09MTkn19435
	for <megaco@ietf.org>; Fri, 9 Jan 2004 16:29:52 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id QAA29219; Fri, 9 Jan 2004 16:28:36 -0500 (EST)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id QAA29215; Fri, 9 Jan 2004 16:28:36 -0500 (EST)
Message-ID: <3FFF1D00.4020804@bell-labs.com>
Date: Fri, 09 Jan 2004 16:28:32 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [Megaco] 05/02 V2 typos and nit-picks
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


I was reading the V2 doc and spotted the following minor items...

In Annex B, auditItem was added to serviceChangeParm.  The
at-most-once comment doesn't really apply to auditItem;
possibly to the elements of auditItem.

In Annex B, where indAudterminationAudit was added to X
there's a typo -- an extra paren.

In Annex A, where comments discuss "X-" and "X+", there's
a typo/problem with the "-".

In Appendix I, the call flow examples all show "MEGACO/1"
instead of "MEGACO/2".  Also the registration ServiceChange
message does not use the mandatory ServiceChangeVersion param.

   (From 11.3: "A ServiceChange command from a MG that registers
   with an MGC shall contain the version number of the protocol
   supported by the MG in the ServiceChangeVersion parameter.")

-troy





_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan  9 17:38:21 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24720
	for <megaco-archive@odin.ietf.org>; Fri, 9 Jan 2004 17:38:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Af5GL-0003EI-Mw
	for megaco-archive@odin.ietf.org; Fri, 09 Jan 2004 17:37:54 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i09MbrDk012408
	for megaco-archive@odin.ietf.org; Fri, 9 Jan 2004 17:37:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Af5GL-0003E3-18
	for megaco-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 17:37:53 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24677
	for <megaco-web-archive@ietf.org>; Fri, 9 Jan 2004 17:37:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Af5GI-0000Mq-00
	for megaco-web-archive@ietf.org; Fri, 09 Jan 2004 17:37:50 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Af5ET-0000IB-00
	for megaco-web-archive@ietf.org; Fri, 09 Jan 2004 17:35:58 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Af5Ci-0000EG-00
	for megaco-web-archive@ietf.org; Fri, 09 Jan 2004 17:34:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Af5Cb-0002oK-4l; Fri, 09 Jan 2004 17:34:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Af5CY-0002o1-KG
	for megaco@optimus.ietf.org; Fri, 09 Jan 2004 17:33:58 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24569
	for <megaco@ietf.org>; Fri, 9 Jan 2004 17:33:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Af5CW-0000Cc-00
	for megaco@ietf.org; Fri, 09 Jan 2004 17:33:56 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Af5Aq-00007N-00
	for megaco@ietf.org; Fri, 09 Jan 2004 17:32:12 -0500
Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Af59Q-0007eI-00
	for megaco@ietf.org; Fri, 09 Jan 2004 17:30:44 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i09MTkn19435
	for <megaco@ietf.org>; Fri, 9 Jan 2004 16:29:52 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id QAA29219; Fri, 9 Jan 2004 16:28:36 -0500 (EST)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id QAA29215; Fri, 9 Jan 2004 16:28:36 -0500 (EST)
Message-ID: <3FFF1D00.4020804@bell-labs.com>
Date: Fri, 09 Jan 2004 16:28:32 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Megaco] 05/02 V2 typos and nit-picks
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


I was reading the V2 doc and spotted the following minor items...

In Annex B, auditItem was added to serviceChangeParm.  The
at-most-once comment doesn't really apply to auditItem;
possibly to the elements of auditItem.

In Annex B, where indAudterminationAudit was added to X
there's a typo -- an extra paren.

In Annex A, where comments discuss "X-" and "X+", there's
a typo/problem with the "-".

In Appendix I, the call flow examples all show "MEGACO/1"
instead of "MEGACO/2".  Also the registration ServiceChange
message does not use the mandatory ServiceChangeVersion param.

   (From 11.3: "A ServiceChange command from a MG that registers
   with an MGC shall contain the version number of the protocol
   supported by the MG in the ServiceChangeVersion parameter.")

-troy





_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Jan 13 06:35:33 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07321
	for <megaco-archive@lists.ietf.org>; Tue, 13 Jan 2004 06:35:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgMp4-00014d-CS; Tue, 13 Jan 2004 06:35:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgMoE-000135-9A
	for megaco@optimus.ietf.org; Tue, 13 Jan 2004 06:34:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07203
	for <megaco@ietf.org>; Tue, 13 Jan 2004 06:34:06 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgMoA-00000w-00
	for megaco@ietf.org; Tue, 13 Jan 2004 06:34:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgMmE-0007iF-00
	for megaco@ietf.org; Tue, 13 Jan 2004 06:32:07 -0500
Received: from ext-proxy-2.ftel.co.uk ([192.65.220.98])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgMkK-0007dn-00
	for megaco@ietf.org; Tue, 13 Jan 2004 06:30:08 -0500
Received: from utility-2.ftel.co.uk (utility-2.ftel.co.uk [193.112.172.11])
	by ext-proxy-2.ftel.co.uk (8.12.10/8.12.9/Revision:1.91/relay-in/ssl/db) with ESMTP id i0DBTZMu023358
	for <megaco@ietf.org>; Tue, 13 Jan 2004 11:29:35 GMT
Received: from DALLAPTOP (dhcp-172-16-48-64.ftel.co.uk [172.16.48.64])
	by utility-2.ftel.co.uk (8.12.9+Sun/8.12.9/Revision:1.90/db) with SMTP id i0DBTTEp014172
	for <megaco@ietf.org>; Tue, 13 Jan 2004 11:29:30 GMT
Message-ID: <005f01c3d9c8$827a5e10$403010ac@DALLAPTOP>
From: "Dal Chohan" <D.Chohan@ftel.co.uk>
To: "MEGACO list" <megaco@ietf.org>
Date: Tue, 13 Jan 2004 11:29:27 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_005C_01C3D9C8.80E87370"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE 
	autolearn=no version=2.60
Subject: [Megaco] H.248.1  generic package - signal completion event
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_005C_01C3D9C8.80E87370
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: H.248.1 E.1 Generic Package "Signal Completion" event

The package description suggests that the signal completion event can =
only be sent when the notifyCompletion parameter is included. However, =
clause 7.1.11 of H.248 version 2 indicates that a signal =
completion/termination event can be sent, even when the =
"notifyCompletion" parameter was not present in the situation the signal =
stopped and was never started for other reason (i.e. Meth =3D NC), .=20

In addition the package contains references to 7.1.1, 7.1.17 and 7.2.7, =
but no reference to "7.1.11 Signal Descriptor" where the procedures for =
signal completion are defined.


I guess a note in the IG should be included to take into account the =
above comments and re-word the text in the package to say something =
along the lines "Indicates the termination of a signal and is this event =
is sent as defined in the procedures of 7.1.11".



Dal Chohan

------=_NextPart_000_005C_01C3D9C8.80E87370
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><U>RE: H.248.1 E.1 Generic Package =
"Signal=20
Completion" event</U></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The package description suggests that =
the signal=20
completion event can only be sent when the notifyCompletion parameter is =

included. However, clause 7.1.11 of H.248 version 2 indicates that a =
signal=20
completion/termination event can be sent, even when the =
"notifyCompletion"=20
parameter was not present in the situation the signal stopped and was =
never=20
started for other reason (i.e. Meth =3D NC),&nbsp;. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In addition the package&nbsp;contains =
references to=20
7.1.1, 7.1.17 and 7.2.7, but no reference to "7.1.11 Signal Descriptor" =
where=20
the procedures for signal completion are defined.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I guess a note in the IG should be =
included to take=20
into account the above comments and re-word the text in the package to =
say=20
something along the lines "Indicates the termination of a signal and is =
this=20
event is sent as defined in the procedures of 7.1.11".</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Dal =
Chohan<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_005C_01C3D9C8.80E87370--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Tue Jan 13 06:39:03 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07596
	for <megaco-archive@odin.ietf.org>; Tue, 13 Jan 2004 06:39:03 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgMsW-0001XX-UU
	for megaco-archive@odin.ietf.org; Tue, 13 Jan 2004 06:38:37 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DBcaIJ005918
	for megaco-archive@odin.ietf.org; Tue, 13 Jan 2004 06:38:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgMsW-0001XN-OD
	for megaco-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 06:38:36 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07585
	for <megaco-web-archive@ietf.org>; Tue, 13 Jan 2004 06:38:32 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgMsS-0000QY-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 06:38:32 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgMql-0000JH-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 06:36:48 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgMp5-00009y-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 06:35:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgMp4-00014d-CS; Tue, 13 Jan 2004 06:35:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgMoE-000135-9A
	for megaco@optimus.ietf.org; Tue, 13 Jan 2004 06:34:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07203
	for <megaco@ietf.org>; Tue, 13 Jan 2004 06:34:06 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgMoA-00000w-00
	for megaco@ietf.org; Tue, 13 Jan 2004 06:34:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgMmE-0007iF-00
	for megaco@ietf.org; Tue, 13 Jan 2004 06:32:07 -0500
Received: from ext-proxy-2.ftel.co.uk ([192.65.220.98])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgMkK-0007dn-00
	for megaco@ietf.org; Tue, 13 Jan 2004 06:30:08 -0500
Received: from utility-2.ftel.co.uk (utility-2.ftel.co.uk [193.112.172.11])
	by ext-proxy-2.ftel.co.uk (8.12.10/8.12.9/Revision:1.91/relay-in/ssl/db) with ESMTP id i0DBTZMu023358
	for <megaco@ietf.org>; Tue, 13 Jan 2004 11:29:35 GMT
Received: from DALLAPTOP (dhcp-172-16-48-64.ftel.co.uk [172.16.48.64])
	by utility-2.ftel.co.uk (8.12.9+Sun/8.12.9/Revision:1.90/db) with SMTP id i0DBTTEp014172
	for <megaco@ietf.org>; Tue, 13 Jan 2004 11:29:30 GMT
Message-ID: <005f01c3d9c8$827a5e10$403010ac@DALLAPTOP>
From: "Dal Chohan" <D.Chohan@ftel.co.uk>
To: "MEGACO list" <megaco@ietf.org>
Date: Tue, 13 Jan 2004 11:29:27 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_005C_01C3D9C8.80E87370"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Subject: [Megaco] H.248.1  generic package - signal completion event
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE 
	autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_005C_01C3D9C8.80E87370
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: H.248.1 E.1 Generic Package "Signal Completion" event

The package description suggests that the signal completion event can =
only be sent when the notifyCompletion parameter is included. However, =
clause 7.1.11 of H.248 version 2 indicates that a signal =
completion/termination event can be sent, even when the =
"notifyCompletion" parameter was not present in the situation the signal =
stopped and was never started for other reason (i.e. Meth =3D NC), .=20

In addition the package contains references to 7.1.1, 7.1.17 and 7.2.7, =
but no reference to "7.1.11 Signal Descriptor" where the procedures for =
signal completion are defined.


I guess a note in the IG should be included to take into account the =
above comments and re-word the text in the package to say something =
along the lines "Indicates the termination of a signal and is this event =
is sent as defined in the procedures of 7.1.11".



Dal Chohan

------=_NextPart_000_005C_01C3D9C8.80E87370
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><U>RE: H.248.1 E.1 Generic Package =
"Signal=20
Completion" event</U></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The package description suggests that =
the signal=20
completion event can only be sent when the notifyCompletion parameter is =

included. However, clause 7.1.11 of H.248 version 2 indicates that a =
signal=20
completion/termination event can be sent, even when the =
"notifyCompletion"=20
parameter was not present in the situation the signal stopped and was =
never=20
started for other reason (i.e. Meth =3D NC),&nbsp;. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In addition the package&nbsp;contains =
references to=20
7.1.1, 7.1.17 and 7.2.7, but no reference to "7.1.11 Signal Descriptor" =
where=20
the procedures for signal completion are defined.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I guess a note in the IG should be =
included to take=20
into account the above comments and re-word the text in the package to =
say=20
something along the lines "Indicates the termination of a signal and is =
this=20
event is sent as defined in the procedures of 7.1.11".</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Dal =
Chohan<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_005C_01C3D9C8.80E87370--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Jan 13 12:29:34 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27244
	for <megaco-archive@lists.ietf.org>; Tue, 13 Jan 2004 12:29:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgSLe-00067u-8M; Tue, 13 Jan 2004 12:29:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgSLC-00066z-SS
	for megaco@optimus.ietf.org; Tue, 13 Jan 2004 12:28:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27235
	for <megaco@ietf.org>; Tue, 13 Jan 2004 12:28:31 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgSLB-0006lg-00
	for megaco@ietf.org; Tue, 13 Jan 2004 12:28:33 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgSJP-0006i5-00
	for megaco@ietf.org; Tue, 13 Jan 2004 12:26:44 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgSHw-0006bG-00
	for megaco@ietf.org; Tue, 13 Jan 2004 12:25:12 -0500
Received: from SAMPATHKW2K03 (dhcp-171-71-9-200.cisco.com [171.71.9.200])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0DHOdGN003388
	for <megaco@ietf.org>; Tue, 13 Jan 2004 09:24:40 -0800 (PST)
Reply-To: <sampathk@cisco.com>
From: "Sampath Komanduri" <sampathk@cisco.com>
To: "'MEGACO list'" <megaco@ietf.org>
Subject: RE: [Megaco] TPKT value for H.248 over TCP
Date: Tue, 13 Jan 2004 09:24:39 -0800
Organization: Cisco Systems
Message-ID: <000b01c3d9fa$2047be90$c80947ab@SAMPATHKW2K03>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000C_01C3D9B7.12247E90"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Importance: Normal
In-Reply-To: <001201c3d4d5$03e46c50$c80947ab@amer.cisco.com>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,HTML_30_40,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_000C_01C3D9B7.12247E90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Could the author of Annex D pls. respond?
 
Thanks,
Sampath

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Sampath Komanduri
Sent: Tuesday, January 06, 2004 8:16 PM
To: 'MEGACO list'
Subject: [Megaco] TPKT value for H.248 over TCP
Importance: High


Hi List,
I am not sure if this question was already raised in the list. If it
was, pls. point me to the discussion and the consensus.

According to ANNEX D of H.248.1 protocol, "TPKT, according to
<http://www.faqs.org/rfcs/rfc1006.html> RFC 1006, SHALL be used to
delineate messages within the TCP stream". RFC 1006 limits the size of
TPDU to 65524. Replicating the relevant text here for convenience:
 
***************************************************
     "A TPKT consists of two parts:  a packet-header and a TPDU.  
      The format of the header is constant regardless of the type of
packet.
      The format of the packet-header is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      vrsn     |    reserved   |          packet length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      where:

      vrsn                         8 bits

      This field is always 3 for the version of the protocol described
in this memo.

      packet length                16 bits (min=7, max=65535)

      This field contains the length of entire packet in octets,
including packet-header.
      This permits a maximum TPDU size of 65531 octets.
      Based on the size of the data transfer (DT) TPDU, this permits a
maximum 
      TSDU size of 65524 octets."
*********************************************************
 
This causes an issue. Based on the wildcard level of Audit and the
descriptors involved, this size could easily exceed 64K size (especially
if MG and MGC are using Long text format and white spaces in the
messages). In few cases, it is possible to return an error code (533:
Response exceeds maximum transport PDU size).
However, in some cases returning 533 is not an option. 
Consider for example the following scenario: After an association is
DISCONNECTED, MGC may want to get the list of non-null contexts on the
gateway using the following command (pls. ignore if there is any mistake
in the message and reply construct):
 
!/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}}
!/1 ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}}, ....and so
on}

In the best case (i.e. no white-space, no audit descriptor and short
format), this allows for an MG to have only 5000 active contexts on the
card. Anything more (or any variation in the audit command) will reduce
the number of active contexts that an MG can have even with TCP as the
transport option.
Responding with 533 is not an option here since that would leave MG-MGC
in state from where there is no elegant way out (at least from H.248
protocol).
 
How do the gurus' on list suggest we solve this issue? Couple of ideas
that come to mind are:

1.	Define a Bulk-Audit Package/scheme: As was done for MGCP, define
a Bulk-Audit package/scheme especially with support for       
    RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" and
    NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].
    This will certainly reduce the cases and scenarios when MG/MGC will
run into the issue under discussion but may not eliminate it. 

2.	Add more information on W- Audit support in the protocol. 

3.	Introduce RFC 1006 modification (with version field 4) such that
"packet length" of packet header in TPKT is 32 bits as opposed to 16
bits. 

4.	Combination of the above schemes. 

5.	Anything else?

Pls. advice on how this problem can be solved?

Thanks,
Sampath


------=_NextPart_000_000C_01C3D9B7.12247E90
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D673442317-13012004>Could=20
the author of Annex D pls. respond?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D673442317-13012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D673442317-13012004>Thanks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D673442317-13012004>Sampath</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] <B>On Behalf Of=20
  </B>Sampath Komanduri<BR><B>Sent:</B> Tuesday, January 06, 2004 8:16=20
  PM<BR><B>To:</B> 'MEGACO list'<BR><B>Subject:</B> [Megaco] TPKT value =
for=20
  H.248 over TCP<BR><B>Importance:</B> High<BR><BR></FONT></DIV><!-- =
Converted from text/plain format -->
  <DIV><FONT face=3DArial size=3D2>Hi List,<BR>I am not sure if this =
question was=20
  already raised in the list. If it was, pls. point me to the discussion =
and the=20
  consensus.<BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>According to ANNEX D of H.248.1 =
protocol, "TPKT,=20
  according to </FONT><A =
href=3D"http://www.faqs.org/rfcs/rfc1006.html"><FONT=20
  face=3DArial size=3D2>RFC 1006</FONT></A><FONT face=3DArial size=3D2>, =
SHALL be used=20
  to delineate messages within the TCP stream".&nbsp;RFC =
1006&nbsp;limits the=20
  size of&nbsp;TPDU to 65524. Replicating the relevant text here for=20
  convenience:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial=20
  =
size=3D2>***************************************************</FONT></DIV>=

  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; "A TPKT =
consists of two=20
  parts:&nbsp; a packet-header and a TPDU.&nbsp; </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
format of the=20
  header is constant regardless of the type of=20
  packet.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The format of the =
packet-header is=20
  as follows:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  3<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0 1 2 3 4 5 6 7 8 9 0 =
1 2 3 4=20
  5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; vrsn&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp; reserved&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet=20
  length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR><BR>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  where:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
vrsn&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  8 bits<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This field is always 3 =
for the=20
  version of the protocol described in this=20
  memo.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet=20
  =
length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
  16 bits (min=3D7, max=3D65535)<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
This field=20
  contains the length of entire packet in octets, including=20
  packet-header.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp; This =
permits a maximum=20
  TPDU size of 65531 octets.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp; Based on =
the size of=20
  the data transfer (DT) TPDU, this permits a maximum </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
T</FONT><FONT=20
  face=3DArial size=3D2>SDU size of 65524=20
  =
octets."<BR>*********************************************************<BR>=
&nbsp;</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>This causes an issue. Based on =
the&nbsp;wildcard=20
  level&nbsp;of Audit and the descriptors involved, this size could =
easily=20
  exceed 64K size (especially if MG and MGC are using Long text format =
and white=20
  spaces in the messages). In few cases, it is possible to&nbsp;return=20
  an&nbsp;error code (533: Response exceeds maximum transport PDU=20
  size).</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>However, in some cases returning 533 =
is not an=20
  option. </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Consider for example the following =
scenario:=20
  After an association is DISCONNECTED, MGC may want to get =
the&nbsp;list of=20
  non-null contexts on the gateway using the following command (pls. =
ignore if=20
  there is any mistake in the message and reply construct):</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><FONT face=3DArial>!/1 [10.102.2.201]:4000=20
  T=3D3700003{C=3D*{AV=3DROOT{AT{}}}}<BR></FONT><FONT face=3DArial>!/1=20
  ABCD_MG&nbsp;P=3D3700003{C=3D</FONT></FONT><FONT face=3DArial=20
  size=3D2>1{AV=3DC{*}},C=3D2<FONT face=3DArial>{AV=3DC{*}},C=3D3<FONT=20
  face=3DArial>{AV=3DC{*}},&nbsp;....and so =
on}</FONT></FONT><BR></FONT><FONT=20
  face=3DArial></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>In the best case (i.e. no =
white-space, no audit=20
  descriptor&nbsp;and short format), this allows for an MG to have only =
5000=20
  active contexts on the card. Anything more (or any variation in the =
audit=20
  command) will reduce the number of active contexts that an MG can have =
even=20
  with TCP as the transport option.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Responding with 533 is not an option =
here since=20
  that would leave MG-MGC in state from where there is no elegant way =
out (at=20
  least from H.248 protocol).</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>How do the gurus' on list suggest we =
solve this=20
  issue? Couple of ideas that come to mind are:</FONT></DIV>
  <OL>
    <LI><FONT face=3DArial><FONT size=3D2>Define a Bulk-Audit =
Package/scheme: As was=20
    done for MGCP, define a Bulk-Audit package/scheme especially with =
support=20
    for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp;=20
    RangeWildcard =3D "[" NumericalRange *( "," NumericalRange ) "]"=20
    and<BR>&nbsp;&nbsp;&nbsp; NumericalRange&nbsp;&nbsp;&nbsp;&nbsp; =3D =
1*(DIGIT)=20
    [ "-" 1*(DIGIT) ].<BR>&nbsp;&nbsp;&nbsp; This will certainly reduce =
the=20
    cases and scenarios when MG/MGC will run into the issue under =
discussion but=20
    may not eliminate it.</FONT></FONT>=20
    <LI><FONT face=3DArial size=3D2>Add more information on W- Audit =
support in the=20
    protocol.</FONT>=20
    <LI><FONT face=3DArial><FONT size=3D2>Introduce RFC 1006 =
modification (with=20
    version field 4) such that "packet length" of packet header in TPKT =
is 32=20
    bits as opposed to 16 bits.</FONT></FONT>=20
    <LI><FONT face=3DArial><FONT size=3D2>Combination of the above=20
    schemes.</FONT></FONT>=20
    <LI><FONT face=3DArial size=3D2>Anything else?</FONT></LI></OL>
  <DIV><FONT face=3DArial size=3D2>Pls. advice on how this problem can =
be=20
  solved?</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
  face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT =
face=3DArial=20
  size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
  size=3D2></FONT><FONT face=3DArial size=3D2></FONT><BR><FONT =
face=3DArial><FONT=20
  =
size=3D2>Thanks,<BR>Sampath</FONT></DIV></BLOCKQUOTE></FONT></BODY></HTML=
>

------=_NextPart_000_000C_01C3D9B7.12247E90--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Tue Jan 13 12:32:54 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27388
	for <megaco-archive@odin.ietf.org>; Tue, 13 Jan 2004 12:32:54 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgSOx-0006Zy-Iw
	for megaco-archive@odin.ietf.org; Tue, 13 Jan 2004 12:32:27 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DHWRMI025290
	for megaco-archive@odin.ietf.org; Tue, 13 Jan 2004 12:32:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgSOx-0006Zp-D0
	for megaco-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 12:32:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27351
	for <megaco-web-archive@ietf.org>; Tue, 13 Jan 2004 12:32:23 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgSOv-0006tz-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 12:32:25 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgSN2-0006pR-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 12:30:29 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgSLi-0006mP-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 12:29:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgSLe-00067u-8M; Tue, 13 Jan 2004 12:29:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgSLC-00066z-SS
	for megaco@optimus.ietf.org; Tue, 13 Jan 2004 12:28:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27235
	for <megaco@ietf.org>; Tue, 13 Jan 2004 12:28:31 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgSLB-0006lg-00
	for megaco@ietf.org; Tue, 13 Jan 2004 12:28:33 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgSJP-0006i5-00
	for megaco@ietf.org; Tue, 13 Jan 2004 12:26:44 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgSHw-0006bG-00
	for megaco@ietf.org; Tue, 13 Jan 2004 12:25:12 -0500
Received: from SAMPATHKW2K03 (dhcp-171-71-9-200.cisco.com [171.71.9.200])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0DHOdGN003388
	for <megaco@ietf.org>; Tue, 13 Jan 2004 09:24:40 -0800 (PST)
Reply-To: <sampathk@cisco.com>
From: "Sampath Komanduri" <sampathk@cisco.com>
To: "'MEGACO list'" <megaco@ietf.org>
Subject: RE: [Megaco] TPKT value for H.248 over TCP
Date: Tue, 13 Jan 2004 09:24:39 -0800
Organization: Cisco Systems
Message-ID: <000b01c3d9fa$2047be90$c80947ab@SAMPATHKW2K03>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000C_01C3D9B7.12247E90"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Importance: Normal
In-Reply-To: <001201c3d4d5$03e46c50$c80947ab@amer.cisco.com>
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,HTML_30_40,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_000C_01C3D9B7.12247E90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Could the author of Annex D pls. respond?
 
Thanks,
Sampath

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Sampath Komanduri
Sent: Tuesday, January 06, 2004 8:16 PM
To: 'MEGACO list'
Subject: [Megaco] TPKT value for H.248 over TCP
Importance: High


Hi List,
I am not sure if this question was already raised in the list. If it
was, pls. point me to the discussion and the consensus.

According to ANNEX D of H.248.1 protocol, "TPKT, according to
<http://www.faqs.org/rfcs/rfc1006.html> RFC 1006, SHALL be used to
delineate messages within the TCP stream". RFC 1006 limits the size of
TPDU to 65524. Replicating the relevant text here for convenience:
 
***************************************************
     "A TPKT consists of two parts:  a packet-header and a TPDU.  
      The format of the header is constant regardless of the type of
packet.
      The format of the packet-header is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      vrsn     |    reserved   |          packet length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      where:

      vrsn                         8 bits

      This field is always 3 for the version of the protocol described
in this memo.

      packet length                16 bits (min=7, max=65535)

      This field contains the length of entire packet in octets,
including packet-header.
      This permits a maximum TPDU size of 65531 octets.
      Based on the size of the data transfer (DT) TPDU, this permits a
maximum 
      TSDU size of 65524 octets."
*********************************************************
 
This causes an issue. Based on the wildcard level of Audit and the
descriptors involved, this size could easily exceed 64K size (especially
if MG and MGC are using Long text format and white spaces in the
messages). In few cases, it is possible to return an error code (533:
Response exceeds maximum transport PDU size).
However, in some cases returning 533 is not an option. 
Consider for example the following scenario: After an association is
DISCONNECTED, MGC may want to get the list of non-null contexts on the
gateway using the following command (pls. ignore if there is any mistake
in the message and reply construct):
 
!/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}}
!/1 ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}}, ....and so
on}

In the best case (i.e. no white-space, no audit descriptor and short
format), this allows for an MG to have only 5000 active contexts on the
card. Anything more (or any variation in the audit command) will reduce
the number of active contexts that an MG can have even with TCP as the
transport option.
Responding with 533 is not an option here since that would leave MG-MGC
in state from where there is no elegant way out (at least from H.248
protocol).
 
How do the gurus' on list suggest we solve this issue? Couple of ideas
that come to mind are:

1.	Define a Bulk-Audit Package/scheme: As was done for MGCP, define
a Bulk-Audit package/scheme especially with support for       
    RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" and
    NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].
    This will certainly reduce the cases and scenarios when MG/MGC will
run into the issue under discussion but may not eliminate it. 

2.	Add more information on W- Audit support in the protocol. 

3.	Introduce RFC 1006 modification (with version field 4) such that
"packet length" of packet header in TPKT is 32 bits as opposed to 16
bits. 

4.	Combination of the above schemes. 

5.	Anything else?

Pls. advice on how this problem can be solved?

Thanks,
Sampath


------=_NextPart_000_000C_01C3D9B7.12247E90
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D673442317-13012004>Could=20
the author of Annex D pls. respond?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D673442317-13012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D673442317-13012004>Thanks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D673442317-13012004>Sampath</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] <B>On Behalf Of=20
  </B>Sampath Komanduri<BR><B>Sent:</B> Tuesday, January 06, 2004 8:16=20
  PM<BR><B>To:</B> 'MEGACO list'<BR><B>Subject:</B> [Megaco] TPKT value =
for=20
  H.248 over TCP<BR><B>Importance:</B> High<BR><BR></FONT></DIV><!-- =
Converted from text/plain format -->
  <DIV><FONT face=3DArial size=3D2>Hi List,<BR>I am not sure if this =
question was=20
  already raised in the list. If it was, pls. point me to the discussion =
and the=20
  consensus.<BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>According to ANNEX D of H.248.1 =
protocol, "TPKT,=20
  according to </FONT><A =
href=3D"http://www.faqs.org/rfcs/rfc1006.html"><FONT=20
  face=3DArial size=3D2>RFC 1006</FONT></A><FONT face=3DArial size=3D2>, =
SHALL be used=20
  to delineate messages within the TCP stream".&nbsp;RFC =
1006&nbsp;limits the=20
  size of&nbsp;TPDU to 65524. Replicating the relevant text here for=20
  convenience:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial=20
  =
size=3D2>***************************************************</FONT></DIV>=

  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; "A TPKT =
consists of two=20
  parts:&nbsp; a packet-header and a TPDU.&nbsp; </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
format of the=20
  header is constant regardless of the type of=20
  packet.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The format of the =
packet-header is=20
  as follows:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  3<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0 1 2 3 4 5 6 7 8 9 0 =
1 2 3 4=20
  5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; vrsn&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp; reserved&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet=20
  length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR><BR>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  where:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
vrsn&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  8 bits<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This field is always 3 =
for the=20
  version of the protocol described in this=20
  memo.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet=20
  =
length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
  16 bits (min=3D7, max=3D65535)<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
This field=20
  contains the length of entire packet in octets, including=20
  packet-header.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp; This =
permits a maximum=20
  TPDU size of 65531 octets.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp; Based on =
the size of=20
  the data transfer (DT) TPDU, this permits a maximum </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
T</FONT><FONT=20
  face=3DArial size=3D2>SDU size of 65524=20
  =
octets."<BR>*********************************************************<BR>=
&nbsp;</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>This causes an issue. Based on =
the&nbsp;wildcard=20
  level&nbsp;of Audit and the descriptors involved, this size could =
easily=20
  exceed 64K size (especially if MG and MGC are using Long text format =
and white=20
  spaces in the messages). In few cases, it is possible to&nbsp;return=20
  an&nbsp;error code (533: Response exceeds maximum transport PDU=20
  size).</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>However, in some cases returning 533 =
is not an=20
  option. </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Consider for example the following =
scenario:=20
  After an association is DISCONNECTED, MGC may want to get =
the&nbsp;list of=20
  non-null contexts on the gateway using the following command (pls. =
ignore if=20
  there is any mistake in the message and reply construct):</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><FONT face=3DArial>!/1 [10.102.2.201]:4000=20
  T=3D3700003{C=3D*{AV=3DROOT{AT{}}}}<BR></FONT><FONT face=3DArial>!/1=20
  ABCD_MG&nbsp;P=3D3700003{C=3D</FONT></FONT><FONT face=3DArial=20
  size=3D2>1{AV=3DC{*}},C=3D2<FONT face=3DArial>{AV=3DC{*}},C=3D3<FONT=20
  face=3DArial>{AV=3DC{*}},&nbsp;....and so =
on}</FONT></FONT><BR></FONT><FONT=20
  face=3DArial></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>In the best case (i.e. no =
white-space, no audit=20
  descriptor&nbsp;and short format), this allows for an MG to have only =
5000=20
  active contexts on the card. Anything more (or any variation in the =
audit=20
  command) will reduce the number of active contexts that an MG can have =
even=20
  with TCP as the transport option.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Responding with 533 is not an option =
here since=20
  that would leave MG-MGC in state from where there is no elegant way =
out (at=20
  least from H.248 protocol).</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>How do the gurus' on list suggest we =
solve this=20
  issue? Couple of ideas that come to mind are:</FONT></DIV>
  <OL>
    <LI><FONT face=3DArial><FONT size=3D2>Define a Bulk-Audit =
Package/scheme: As was=20
    done for MGCP, define a Bulk-Audit package/scheme especially with =
support=20
    for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp;=20
    RangeWildcard =3D "[" NumericalRange *( "," NumericalRange ) "]"=20
    and<BR>&nbsp;&nbsp;&nbsp; NumericalRange&nbsp;&nbsp;&nbsp;&nbsp; =3D =
1*(DIGIT)=20
    [ "-" 1*(DIGIT) ].<BR>&nbsp;&nbsp;&nbsp; This will certainly reduce =
the=20
    cases and scenarios when MG/MGC will run into the issue under =
discussion but=20
    may not eliminate it.</FONT></FONT>=20
    <LI><FONT face=3DArial size=3D2>Add more information on W- Audit =
support in the=20
    protocol.</FONT>=20
    <LI><FONT face=3DArial><FONT size=3D2>Introduce RFC 1006 =
modification (with=20
    version field 4) such that "packet length" of packet header in TPKT =
is 32=20
    bits as opposed to 16 bits.</FONT></FONT>=20
    <LI><FONT face=3DArial><FONT size=3D2>Combination of the above=20
    schemes.</FONT></FONT>=20
    <LI><FONT face=3DArial size=3D2>Anything else?</FONT></LI></OL>
  <DIV><FONT face=3DArial size=3D2>Pls. advice on how this problem can =
be=20
  solved?</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
  face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT =
face=3DArial=20
  size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
  size=3D2></FONT><FONT face=3DArial size=3D2></FONT><BR><FONT =
face=3DArial><FONT=20
  =
size=3D2>Thanks,<BR>Sampath</FONT></DIV></BLOCKQUOTE></FONT></BODY></HTML=
>

------=_NextPart_000_000C_01C3D9B7.12247E90--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Jan 13 14:45:32 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07107
	for <megaco-archive@lists.ietf.org>; Tue, 13 Jan 2004 14:45:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgUTH-0007Kh-1K; Tue, 13 Jan 2004 14:45:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgUSZ-0007Hq-7j
	for megaco@optimus.ietf.org; Tue, 13 Jan 2004 14:44:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06996
	for <megaco@ietf.org>; Tue, 13 Jan 2004 14:44:16 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgUSW-0000fe-00
	for megaco@ietf.org; Tue, 13 Jan 2004 14:44:16 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgUQd-0000Zo-00
	for megaco@ietf.org; Tue, 13 Jan 2004 14:42:20 -0500
Received: from [65.198.40.5] (helo=mails.conexion.com.py)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgUOp-0000Nv-00
	for megaco@ietf.org; Tue, 13 Jan 2004 14:40:27 -0500
Received: from carlos ([65.198.40.11])
	by mails.conexion.com.py (8.12.8/8.12.8) with SMTP id i0DJieq8031740
	for <megaco@ietf.org>; Tue, 13 Jan 2004 16:44:46 -0300
Message-ID: <001601c3d9ed$1c9ccae0$6600a8c0@carlos>
From: =?iso-8859-1?Q?Carlos_Rodr=EDguez_Alcal=E1_Villagra?= <crav@conexion.com.py>
To: <megaco@ietf.org>
Date: Tue, 13 Jan 2004 16:51:24 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0011_01C3D9F5.7AF16080"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300
X-ConeXion-MailScanner-Information: Please contact the ISP for more information
X-ConeXion-MailScanner: Found to be clean
X-ConeXion-MailScanner-SpamCheck: no es spam, SpamAssassin (puntuación=1.3,
	requerido 3, HTML_50_70 0.30, SPAM_PHRASE_00_01 0.78,
	USER_AGENT_OE 0.18)
X-ConeXion-MailScanner-SpamScore: s
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,DATE_IN_PAST_03_06,
	HTML_60_70,HTML_MESSAGE autolearn=no version=2.60
Subject: [Megaco] Termination Id = *
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C3D9F5.7AF16080
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Can I create this packet??

Mgc to mg1:
MEGACO/1 [123.123.123.4]:55555
Transaction=3D10001{
    Context =3D -  {
        Modify =3D *  {           ;with this parameter as * ????
                Events =3D 1111{ al /of}
                }
        }
}


***************
It's posible to put in Context * or it must be a Real Termonation Id
Thanks
                                   =20

------=_NextPart_000_0011_01C3D9F5.7AF16080
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2734.1600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Can I create this packet??</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Mgc to mg1:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>MEGACO/1 =
[123.123.123.4]:55555</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Transaction=3D10001{</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Context =3D =
-</FONT><FONT=20
face=3DArial size=3D2>&nbsp; {</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
Modify =3D *=20
&nbsp;{&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ;with this =
parameter=20
as * ????</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Events =3D 1111{ al =
/of}</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
}</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>***************</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>It's posible to put in Context * or it =
must be a=20
Real Termonation Id</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
</FONT></DIV></BODY></HTML>

------=_NextPart_000_0011_01C3D9F5.7AF16080--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Tue Jan 13 14:49:15 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07397
	for <megaco-archive@odin.ietf.org>; Tue, 13 Jan 2004 14:49:15 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgUWt-0007Xg-5u
	for megaco-archive@odin.ietf.org; Tue, 13 Jan 2004 14:48:48 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DJmltQ028988
	for megaco-archive@odin.ietf.org; Tue, 13 Jan 2004 14:48:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgUWt-0007XT-2r
	for megaco-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 14:48:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07334
	for <megaco-web-archive@ietf.org>; Tue, 13 Jan 2004 14:48:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgUWq-000151-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 14:48:44 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgUUv-0000sz-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 14:46:46 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgUTH-0000mS-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 14:45:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgUTH-0007Kh-1K; Tue, 13 Jan 2004 14:45:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgUSZ-0007Hq-7j
	for megaco@optimus.ietf.org; Tue, 13 Jan 2004 14:44:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06996
	for <megaco@ietf.org>; Tue, 13 Jan 2004 14:44:16 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgUSW-0000fe-00
	for megaco@ietf.org; Tue, 13 Jan 2004 14:44:16 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgUQd-0000Zo-00
	for megaco@ietf.org; Tue, 13 Jan 2004 14:42:20 -0500
Received: from [65.198.40.5] (helo=mails.conexion.com.py)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgUOp-0000Nv-00
	for megaco@ietf.org; Tue, 13 Jan 2004 14:40:27 -0500
Received: from carlos ([65.198.40.11])
	by mails.conexion.com.py (8.12.8/8.12.8) with SMTP id i0DJieq8031740
	for <megaco@ietf.org>; Tue, 13 Jan 2004 16:44:46 -0300
Message-ID: <001601c3d9ed$1c9ccae0$6600a8c0@carlos>
From: =?iso-8859-1?Q?Carlos_Rodr=EDguez_Alcal=E1_Villagra?= <crav@conexion.com.py>
To: <megaco@ietf.org>
Date: Tue, 13 Jan 2004 16:51:24 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0011_01C3D9F5.7AF16080"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300
X-ConeXion-MailScanner-Information: Please contact the ISP for more information
X-ConeXion-MailScanner: Found to be clean
X-ConeXion-MailScanner-SpamCheck: no es spam, SpamAssassin (puntuación=1.3,
	requerido 3, HTML_50_70 0.30, SPAM_PHRASE_00_01 0.78,
	USER_AGENT_OE 0.18)
X-ConeXion-MailScanner-SpamScore: s
Subject: [Megaco] Termination Id = *
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,DATE_IN_PAST_03_06,
	HTML_50_60,HTML_MESSAGE autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C3D9F5.7AF16080
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Can I create this packet??

Mgc to mg1:
MEGACO/1 [123.123.123.4]:55555
Transaction=3D10001{
    Context =3D -  {
        Modify =3D *  {           ;with this parameter as * ????
                Events =3D 1111{ al /of}
                }
        }
}


***************
It's posible to put in Context * or it must be a Real Termonation Id
Thanks
                                   =20

------=_NextPart_000_0011_01C3D9F5.7AF16080
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2734.1600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Can I create this packet??</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Mgc to mg1:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>MEGACO/1 =
[123.123.123.4]:55555</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Transaction=3D10001{</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Context =3D =
-</FONT><FONT=20
face=3DArial size=3D2>&nbsp; {</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
Modify =3D *=20
&nbsp;{&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ;with this =
parameter=20
as * ????</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Events =3D 1111{ al =
/of}</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
}</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>***************</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>It's posible to put in Context * or it =
must be a=20
Real Termonation Id</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
</FONT></DIV></BODY></HTML>

------=_NextPart_000_0011_01C3D9F5.7AF16080--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Jan 13 15:05:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08511
	for <megaco-archive@lists.ietf.org>; Tue, 13 Jan 2004 15:05:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgUmc-0008GF-FB; Tue, 13 Jan 2004 15:05:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgUmC-0008FI-Ak
	for megaco@optimus.ietf.org; Tue, 13 Jan 2004 15:04:36 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08305
	for <megaco@ietf.org>; Tue, 13 Jan 2004 15:04:32 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgUm9-00020V-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:04:33 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgUkH-0001qu-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:02:37 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgUiQ-0001iq-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:00:43 -0500
Received: from SAMPATHKW2K03 (dhcp-171-71-9-200.cisco.com [171.71.9.200])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0DK09GN021823;
	Tue, 13 Jan 2004 12:00:10 -0800 (PST)
Reply-To: <sampathk@cisco.com>
From: "Sampath Komanduri" <sampathk@cisco.com>
To: "=?iso-8859-1?Q?'Carlos_Rodr=EDguez_Alcal=E1_Villagra'?=" <crav@conexion.com.py>,
        <megaco@ietf.org>
Subject: RE: [Megaco] Termination Id = *
Date: Tue, 13 Jan 2004 12:00:09 -0800
Organization: Cisco Systems
Message-ID: <002201c3da0f$d9baf9e0$c80947ab@SAMPATHKW2K03>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0023_01C3D9CC.CB97B9E0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Importance: Normal
In-Reply-To: <001601c3d9ed$1c9ccae0$6600a8c0@carlos>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_50_60,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0023_01C3D9CC.CB97B9E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

No, you can't. al/of is an event for SCN termination. Based on the
recent discussions, SCN terminations should be specific or partially
specific (see the discussion in=20
http://www.ietf.org/mail-archive/working-groups/megaco/current/msg04781.
html)=20
=20
Thanks,
Sampath

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Carlos Rodr=EDguez Alcal=E1 Villagra
Sent: Tuesday, January 13, 2004 7:51 AM
To: megaco@ietf.org
Subject: [Megaco] Termination Id =3D *


=20
Can I create this packet??
=20
Mgc to mg1:
MEGACO/1 [123.123.123.4]:55555
Transaction=3D10001{
    Context =3D -  {
        Modify =3D *  {           ;with this parameter as * ????
                Events =3D 1111{ al /of}
                }
        }
}
=20
=20
***************
It's posible to put in Context * or it must be a Real Termonation Id
Thanks
                                   =20


------=_NextPart_000_0023_01C3D9CC.CB97B9E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =
size=3D2>No,=20
you can't. al/of is an event for SCN termination. Based on the recent=20
discussions, SCN terminations&nbsp;should be specific or partially =
specific (see=20
the discussion in </FONT></SPAN></DIV>
<DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =
size=3D2><A=20
href=3D"http://www.ietf.org/mail-archive/working-groups/megaco/current/ms=
g04781.html">http://www.ietf.org/mail-archive/working-groups/megaco/curre=
nt/msg04781.html</A>)</FONT></SPAN><SPAN=20
class=3D695305619-13012004>&nbsp;</SPAN></DIV>
<DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Sampath</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] <B>On Behalf Of=20
  </B>Carlos Rodr=EDguez Alcal=E1 Villagra<BR><B>Sent:</B> Tuesday, =
January 13, 2004=20
  7:51 AM<BR><B>To:</B> megaco@ietf.org<BR><B>Subject:</B> [Megaco] =
Termination=20
  Id =3D *<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Can I create this =
packet??</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Mgc to mg1:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>MEGACO/1 =
[123.123.123.4]:55555</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Transaction=3D10001{</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Context =3D =
-</FONT><FONT=20
  face=3DArial size=3D2>&nbsp; {</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
Modify =3D *=20
  &nbsp;{&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ;with this =
parameter=20
  as * ????</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =

  &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Events =3D 1111{ al =
/of}</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =

  &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =

  }</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>***************</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>It's posible to put in Context * or =
it must be a=20
  Real Termonation Id</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =

  &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0023_01C3D9CC.CB97B9E0--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Tue Jan 13 15:09:28 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09376
	for <megaco-archive@odin.ietf.org>; Tue, 13 Jan 2004 15:09:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgUqT-0000KU-E9
	for megaco-archive@odin.ietf.org; Tue, 13 Jan 2004 15:09:01 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DK91f7001260
	for megaco-archive@odin.ietf.org; Tue, 13 Jan 2004 15:09:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgUqT-0000KC-A3
	for megaco-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 15:09:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09249
	for <megaco-web-archive@ietf.org>; Tue, 13 Jan 2004 15:08:57 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgUqQ-0002Zr-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 15:08:58 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgUoq-0002LQ-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 15:07:21 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgUma-00024Z-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 15:05:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgUmc-0008GF-FB; Tue, 13 Jan 2004 15:05:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgUmC-0008FI-Ak
	for megaco@optimus.ietf.org; Tue, 13 Jan 2004 15:04:36 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08305
	for <megaco@ietf.org>; Tue, 13 Jan 2004 15:04:32 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgUm9-00020V-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:04:33 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgUkH-0001qu-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:02:37 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgUiQ-0001iq-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:00:43 -0500
Received: from SAMPATHKW2K03 (dhcp-171-71-9-200.cisco.com [171.71.9.200])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0DK09GN021823;
	Tue, 13 Jan 2004 12:00:10 -0800 (PST)
Reply-To: <sampathk@cisco.com>
From: "Sampath Komanduri" <sampathk@cisco.com>
To: "=?iso-8859-1?Q?'Carlos_Rodr=EDguez_Alcal=E1_Villagra'?=" <crav@conexion.com.py>,
        <megaco@ietf.org>
Subject: RE: [Megaco] Termination Id = *
Date: Tue, 13 Jan 2004 12:00:09 -0800
Organization: Cisco Systems
Message-ID: <002201c3da0f$d9baf9e0$c80947ab@SAMPATHKW2K03>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0023_01C3D9CC.CB97B9E0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Importance: Normal
In-Reply-To: <001601c3d9ed$1c9ccae0$6600a8c0@carlos>
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_50_60,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_0023_01C3D9CC.CB97B9E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

No, you can't. al/of is an event for SCN termination. Based on the
recent discussions, SCN terminations should be specific or partially
specific (see the discussion in=20
http://www.ietf.org/mail-archive/working-groups/megaco/current/msg04781.
html)=20
=20
Thanks,
Sampath

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Carlos Rodr=EDguez Alcal=E1 Villagra
Sent: Tuesday, January 13, 2004 7:51 AM
To: megaco@ietf.org
Subject: [Megaco] Termination Id =3D *


=20
Can I create this packet??
=20
Mgc to mg1:
MEGACO/1 [123.123.123.4]:55555
Transaction=3D10001{
    Context =3D -  {
        Modify =3D *  {           ;with this parameter as * ????
                Events =3D 1111{ al /of}
                }
        }
}
=20
=20
***************
It's posible to put in Context * or it must be a Real Termonation Id
Thanks
                                   =20


------=_NextPart_000_0023_01C3D9CC.CB97B9E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =
size=3D2>No,=20
you can't. al/of is an event for SCN termination. Based on the recent=20
discussions, SCN terminations&nbsp;should be specific or partially =
specific (see=20
the discussion in </FONT></SPAN></DIV>
<DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =
size=3D2><A=20
href=3D"http://www.ietf.org/mail-archive/working-groups/megaco/current/ms=
g04781.html">http://www.ietf.org/mail-archive/working-groups/megaco/curre=
nt/msg04781.html</A>)</FONT></SPAN><SPAN=20
class=3D695305619-13012004>&nbsp;</SPAN></DIV>
<DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Sampath</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] <B>On Behalf Of=20
  </B>Carlos Rodr=EDguez Alcal=E1 Villagra<BR><B>Sent:</B> Tuesday, =
January 13, 2004=20
  7:51 AM<BR><B>To:</B> megaco@ietf.org<BR><B>Subject:</B> [Megaco] =
Termination=20
  Id =3D *<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Can I create this =
packet??</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Mgc to mg1:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>MEGACO/1 =
[123.123.123.4]:55555</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Transaction=3D10001{</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Context =3D =
-</FONT><FONT=20
  face=3DArial size=3D2>&nbsp; {</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
Modify =3D *=20
  &nbsp;{&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ;with this =
parameter=20
  as * ????</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =

  &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Events =3D 1111{ al =
/of}</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =

  &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =

  }</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>***************</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>It's posible to put in Context * or =
it must be a=20
  Real Termonation Id</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =

  &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0023_01C3D9CC.CB97B9E0--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Jan 13 15:10:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09484
	for <megaco-archive@lists.ietf.org>; Tue, 13 Jan 2004 15:10:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgUrR-0000NC-Lb; Tue, 13 Jan 2004 15:10:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgUqU-0000Kv-S9
	for megaco@optimus.ietf.org; Tue, 13 Jan 2004 15:09:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09258
	for <megaco@ietf.org>; Tue, 13 Jan 2004 15:08:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgUqR-0002a6-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:08:59 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgUos-0002Ln-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:07:23 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgUme-00020W-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:05:04 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0DK4Fd26645;
	Tue, 13 Jan 2004 15:04:15 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2YF11F4>; Tue, 13 Jan 2004 15:04:15 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0DC7B8B7@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: =?iso-8859-1?Q?Carlos_Rodr=EDguez_Alcal=E1_Villagra?=
	 <crav@conexion.com.py>,
        megaco@ietf.org
Subject: RE: [Megaco] Termination Id = *
Date: Tue, 13 Jan 2004 15:04:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3DA10.6AB1E562"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE 
	autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3DA10.6AB1E562
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The message as constructed below would apply the given Events =
descriptor to
all terminations in the NULL context.
=20
Kevin


  _____ =20

From: Carlos Rodr=EDguez Alcal=E1 Villagra =
[mailto:crav@conexion.com.py]=20
Sent: Tuesday, January 13, 2004 10:51 AM
To: megaco@ietf.org
Subject: [Megaco] Termination Id =3D *


=20
Can I create this packet??
=20
Mgc to mg1:
MEGACO/1 [123.123.123.4]:55555
Transaction=3D10001{
    Context =3D -  {
        Modify =3D *  {           ;with this parameter as * ????
                Events =3D 1111{ al /of}
                }
        }
}
=20
=20
***************
It's posible to put in Context * or it must be a Real Termonation Id
Thanks
                                   =20


------_=_NextPart_001_01C3DA10.6AB1E562
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
face=3DArial=20
size=3D2>The message as constructed below would apply the given Events =
descriptor=20
to all terminations in the NULL context.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
face=3DArial=20
size=3D2>Kevin</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Carlos Rodr=EDguez Alcal=E1 =
Villagra=20
  [mailto:crav@conexion.com.py] <BR><B>Sent:</B> Tuesday, January 13, =
2004 10:51=20
  AM<BR><B>To:</B> megaco@ietf.org<BR><B>Subject:</B> [Megaco] =
Termination Id =3D=20
  *<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Can I create this =
packet??</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Mgc to mg1:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>MEGACO/1 =
[123.123.123.4]:55555</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Transaction=3D10001{</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Context =3D =
-</FONT><FONT=20
  face=3DArial size=3D2>&nbsp; {</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp; Modify =3D *=20
  &nbsp;{&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ;with this =
parameter=20
  as * ????</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Events =3D 1111{ al =
/of}</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
  }</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>***************</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>It's posible to put in Context * or =
it must be a=20
  Real Termonation Id</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3DA10.6AB1E562--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Tue Jan 13 15:13:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09930
	for <megaco-archive@odin.ietf.org>; Tue, 13 Jan 2004 15:13:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgUuL-0000XT-Ig
	for megaco-archive@odin.ietf.org; Tue, 13 Jan 2004 15:13:01 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DKD1sk002065
	for megaco-archive@odin.ietf.org; Tue, 13 Jan 2004 15:13:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgUuL-0000XE-DJ
	for megaco-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 15:13:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09883
	for <megaco-web-archive@ietf.org>; Tue, 13 Jan 2004 15:12:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgUuI-0002vC-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 15:12:58 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgUsR-0002mz-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 15:11:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgUrQ-0002ee-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 15:10:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgUrR-0000NC-Lb; Tue, 13 Jan 2004 15:10:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgUqU-0000Kv-S9
	for megaco@optimus.ietf.org; Tue, 13 Jan 2004 15:09:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09258
	for <megaco@ietf.org>; Tue, 13 Jan 2004 15:08:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgUqR-0002a6-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:08:59 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgUos-0002Ln-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:07:23 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgUme-00020W-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:05:04 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0DK4Fd26645;
	Tue, 13 Jan 2004 15:04:15 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2YF11F4>; Tue, 13 Jan 2004 15:04:15 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0DC7B8B7@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: =?iso-8859-1?Q?Carlos_Rodr=EDguez_Alcal=E1_Villagra?=
	 <crav@conexion.com.py>,
        megaco@ietf.org
Subject: RE: [Megaco] Termination Id = *
Date: Tue, 13 Jan 2004 15:04:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3DA10.6AB1E562"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE 
	autolearn=no version=2.60

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3DA10.6AB1E562
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The message as constructed below would apply the given Events =
descriptor to
all terminations in the NULL context.
=20
Kevin


  _____ =20

From: Carlos Rodr=EDguez Alcal=E1 Villagra =
[mailto:crav@conexion.com.py]=20
Sent: Tuesday, January 13, 2004 10:51 AM
To: megaco@ietf.org
Subject: [Megaco] Termination Id =3D *


=20
Can I create this packet??
=20
Mgc to mg1:
MEGACO/1 [123.123.123.4]:55555
Transaction=3D10001{
    Context =3D -  {
        Modify =3D *  {           ;with this parameter as * ????
                Events =3D 1111{ al /of}
                }
        }
}
=20
=20
***************
It's posible to put in Context * or it must be a Real Termonation Id
Thanks
                                   =20


------_=_NextPart_001_01C3DA10.6AB1E562
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
face=3DArial=20
size=3D2>The message as constructed below would apply the given Events =
descriptor=20
to all terminations in the NULL context.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
face=3DArial=20
size=3D2>Kevin</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Carlos Rodr=EDguez Alcal=E1 =
Villagra=20
  [mailto:crav@conexion.com.py] <BR><B>Sent:</B> Tuesday, January 13, =
2004 10:51=20
  AM<BR><B>To:</B> megaco@ietf.org<BR><B>Subject:</B> [Megaco] =
Termination Id =3D=20
  *<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Can I create this =
packet??</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Mgc to mg1:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>MEGACO/1 =
[123.123.123.4]:55555</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Transaction=3D10001{</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Context =3D =
-</FONT><FONT=20
  face=3DArial size=3D2>&nbsp; {</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp; Modify =3D *=20
  &nbsp;{&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ;with this =
parameter=20
  as * ????</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Events =3D 1111{ al =
/of}</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
  }</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>***************</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>It's posible to put in Context * or =
it must be a=20
  Real Termonation Id</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3DA10.6AB1E562--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Jan 13 15:29:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11176
	for <megaco-archive@lists.ietf.org>; Tue, 13 Jan 2004 15:29:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgV9o-00010s-SI; Tue, 13 Jan 2004 15:29:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgV9M-0000zj-Ic
	for megaco@optimus.ietf.org; Tue, 13 Jan 2004 15:28:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11160
	for <megaco@ietf.org>; Tue, 13 Jan 2004 15:28:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgV9L-0003lD-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:28:31 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgV7c-0003hX-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:26:45 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgV6c-0003cN-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:25:42 -0500
Received: from SAMPATHKW2K03 (dhcp-171-71-9-200.cisco.com [171.71.9.200])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0DKP9GN026025;
	Tue, 13 Jan 2004 12:25:10 -0800 (PST)
Reply-To: <sampathk@cisco.com>
From: "Sampath Komanduri" <sampathk@cisco.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "=?iso-8859-1?Q?'Carlos_Rodr=EDguez_Alcal=E1_Villagra'?=" <crav@conexion.com.py>,
        <megaco@ietf.org>
Subject: RE: [Megaco] Termination Id = *
Date: Tue, 13 Jan 2004 12:25:09 -0800
Organization: Cisco Systems
Message-ID: <003201c3da13$57962f80$c80947ab@SAMPATHKW2K03>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0033_01C3D9D0.4972EF80"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Importance: Normal
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0DC7B8B7@zrtpd0jq.us.nortel.com>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_50_60,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0033_01C3D9D0.4972EF80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Sorry, I didn't notice context "-"

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Kevin Boyle
Sent: Tuesday, January 13, 2004 12:04 PM
To: Carlos Rodr=EDguez Alcal=E1 Villagra; megaco@ietf.org
Subject: RE: [Megaco] Termination Id =3D *


The message as constructed below would apply the given Events descriptor
to all terminations in the NULL context.
=20
Kevin


  _____ =20

From: Carlos Rodr=EDguez Alcal=E1 Villagra [mailto:crav@conexion.com.py] =

Sent: Tuesday, January 13, 2004 10:51 AM
To: megaco@ietf.org
Subject: [Megaco] Termination Id =3D *


=20
Can I create this packet??
=20
Mgc to mg1:
MEGACO/1 [123.123.123.4]:55555
Transaction=3D10001{
    Context =3D -  {
        Modify =3D *  {           ;with this parameter as * ????
                Events =3D 1111{ al /of}
                }
        }
}
=20
=20
***************
It's posible to put in Context * or it must be a Real Termonation Id
Thanks
                                   =20


------=_NextPart_000_0033_01C3D9D0.4972EF80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><SPAN class=3D569492420-13012004><FONT face=3DArial color=3D#0000ff =
size=3D2>Sorry,=20
I didn't notice context "-"</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] <B>On Behalf Of =
</B>Kevin=20
  Boyle<BR><B>Sent:</B> Tuesday, January 13, 2004 12:04 PM<BR><B>To:</B> =
Carlos=20
  Rodr=EDguez Alcal=E1 Villagra; megaco@ietf.org<BR><B>Subject:</B> RE: =
[Megaco]=20
  Termination Id =3D *<BR><BR></FONT></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
face=3DArial=20
  size=3D2>The message as constructed below would apply the given Events =

  descriptor to all terminations in the NULL =
context.</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
face=3DArial=20
  size=3D2>Kevin</FONT></SPAN></DIV><BR>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
    <HR tabIndex=3D-1>
    <FONT face=3DTahoma size=3D2><B>From:</B> Carlos Rodr=EDguez =
Alcal=E1 Villagra=20
    [mailto:crav@conexion.com.py] <BR><B>Sent:</B> Tuesday, January 13, =
2004=20
    10:51 AM<BR><B>To:</B> megaco@ietf.org<BR><B>Subject:</B> [Megaco]=20
    Termination Id =3D *<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>Can I create this =
packet??</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>Mgc to mg1:</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>MEGACO/1 =
[123.123.123.4]:55555</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>Transaction=3D10001{</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Context =3D =
-</FONT><FONT=20
    face=3DArial size=3D2>&nbsp; {</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp; Modify =3D=20
    * &nbsp;{&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ;with =
this=20
    parameter as * ????</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Events =3D 1111{ al =
/of}</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
    }</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>***************</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>It's posible to put in Context * or =
it must be=20
    a Real Termonation Id</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
  </FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0033_01C3D9D0.4972EF80--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Tue Jan 13 15:33:03 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11469
	for <megaco-archive@odin.ietf.org>; Tue, 13 Jan 2004 15:33:03 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgVDG-0001GR-P7
	for megaco-archive@odin.ietf.org; Tue, 13 Jan 2004 15:32:34 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DKWYsX004855
	for megaco-archive@odin.ietf.org; Tue, 13 Jan 2004 15:32:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgVDG-0001GE-Ln
	for megaco-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 15:32:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11413
	for <megaco-web-archive@ietf.org>; Tue, 13 Jan 2004 15:32:28 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgVDB-0003ue-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 15:32:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgVBN-0003rC-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 15:30:38 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgV9p-0003nG-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 15:29:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgV9o-00010s-SI; Tue, 13 Jan 2004 15:29:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgV9M-0000zj-Ic
	for megaco@optimus.ietf.org; Tue, 13 Jan 2004 15:28:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11160
	for <megaco@ietf.org>; Tue, 13 Jan 2004 15:28:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgV9L-0003lD-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:28:31 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgV7c-0003hX-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:26:45 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgV6c-0003cN-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:25:42 -0500
Received: from SAMPATHKW2K03 (dhcp-171-71-9-200.cisco.com [171.71.9.200])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0DKP9GN026025;
	Tue, 13 Jan 2004 12:25:10 -0800 (PST)
Reply-To: <sampathk@cisco.com>
From: "Sampath Komanduri" <sampathk@cisco.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "=?iso-8859-1?Q?'Carlos_Rodr=EDguez_Alcal=E1_Villagra'?=" <crav@conexion.com.py>,
        <megaco@ietf.org>
Subject: RE: [Megaco] Termination Id = *
Date: Tue, 13 Jan 2004 12:25:09 -0800
Organization: Cisco Systems
Message-ID: <003201c3da13$57962f80$c80947ab@SAMPATHKW2K03>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0033_01C3D9D0.4972EF80"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Importance: Normal
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0DC7B8B7@zrtpd0jq.us.nortel.com>
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_40_50,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_0033_01C3D9D0.4972EF80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Sorry, I didn't notice context "-"

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Kevin Boyle
Sent: Tuesday, January 13, 2004 12:04 PM
To: Carlos Rodr=EDguez Alcal=E1 Villagra; megaco@ietf.org
Subject: RE: [Megaco] Termination Id =3D *


The message as constructed below would apply the given Events descriptor
to all terminations in the NULL context.
=20
Kevin


  _____ =20

From: Carlos Rodr=EDguez Alcal=E1 Villagra [mailto:crav@conexion.com.py] =

Sent: Tuesday, January 13, 2004 10:51 AM
To: megaco@ietf.org
Subject: [Megaco] Termination Id =3D *


=20
Can I create this packet??
=20
Mgc to mg1:
MEGACO/1 [123.123.123.4]:55555
Transaction=3D10001{
    Context =3D -  {
        Modify =3D *  {           ;with this parameter as * ????
                Events =3D 1111{ al /of}
                }
        }
}
=20
=20
***************
It's posible to put in Context * or it must be a Real Termonation Id
Thanks
                                   =20


------=_NextPart_000_0033_01C3D9D0.4972EF80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><SPAN class=3D569492420-13012004><FONT face=3DArial color=3D#0000ff =
size=3D2>Sorry,=20
I didn't notice context "-"</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] <B>On Behalf Of =
</B>Kevin=20
  Boyle<BR><B>Sent:</B> Tuesday, January 13, 2004 12:04 PM<BR><B>To:</B> =
Carlos=20
  Rodr=EDguez Alcal=E1 Villagra; megaco@ietf.org<BR><B>Subject:</B> RE: =
[Megaco]=20
  Termination Id =3D *<BR><BR></FONT></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
face=3DArial=20
  size=3D2>The message as constructed below would apply the given Events =

  descriptor to all terminations in the NULL =
context.</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
face=3DArial=20
  size=3D2>Kevin</FONT></SPAN></DIV><BR>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
    <HR tabIndex=3D-1>
    <FONT face=3DTahoma size=3D2><B>From:</B> Carlos Rodr=EDguez =
Alcal=E1 Villagra=20
    [mailto:crav@conexion.com.py] <BR><B>Sent:</B> Tuesday, January 13, =
2004=20
    10:51 AM<BR><B>To:</B> megaco@ietf.org<BR><B>Subject:</B> [Megaco]=20
    Termination Id =3D *<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>Can I create this =
packet??</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>Mgc to mg1:</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>MEGACO/1 =
[123.123.123.4]:55555</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>Transaction=3D10001{</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Context =3D =
-</FONT><FONT=20
    face=3DArial size=3D2>&nbsp; {</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp; Modify =3D=20
    * &nbsp;{&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ;with =
this=20
    parameter as * ????</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Events =3D 1111{ al =
/of}</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
    }</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>***************</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>It's posible to put in Context * or =
it must be=20
    a Real Termonation Id</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
  </FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0033_01C3D9D0.4972EF80--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Jan 13 15:33:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11490
	for <megaco-archive@lists.ietf.org>; Tue, 13 Jan 2004 15:33:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgVDh-0001Hh-GD; Tue, 13 Jan 2004 15:33:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgVDF-0001G9-Ph
	for megaco@optimus.ietf.org; Tue, 13 Jan 2004 15:32:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11436
	for <megaco@ietf.org>; Tue, 13 Jan 2004 15:32:31 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgVDE-0003v1-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:32:32 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgVBQ-0003rb-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:30:40 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgVAF-0003nA-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:29:27 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0DKStQ27487
	for <megaco@ietf.org>; Tue, 13 Jan 2004 15:28:55 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2YF1FAN>; Tue, 13 Jan 2004 15:28:55 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0DC7B9BB@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: sampathk@cisco.com,
        "'Carlos Rodríguez Alcalá Villagra'"
	 <crav@conexion.com.py>,
        megaco@ietf.org
Subject: RE: [Megaco] Termination Id = *
Date: Tue, 13 Jan 2004 15:28:44 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

The message referenced below talks specifically about Add commands, and
would not apply here.
 
Kevin


  _____  

From: Sampath Komanduri [mailto:sampathk@cisco.com] 
Sent: Tuesday, January 13, 2004 3:00 PM
To: 'Carlos Rodríguez Alcalá Villagra'; megaco@ietf.org
Subject: RE: [Megaco] Termination Id = *


No, you can't. al/of is an event for SCN termination. Based on the recent
discussions, SCN terminations should be specific or partially specific (see
the discussion in 
http://www.ietf.org/mail-archive/working-groups/megaco/current/msg04781.html
<http://www.ietf.org/mail-archive/working-groups/megaco/current/msg04781.htm
l> ) 
 
Thanks,
Sampath

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Carlos Rodríguez Alcalá Villagra
Sent: Tuesday, January 13, 2004 7:51 AM
To: megaco@ietf.org
Subject: [Megaco] Termination Id = *


 
Can I create this packet??
 
Mgc to mg1:
MEGACO/1 [123.123.123.4]:55555
Transaction=10001{
    Context = -  {
        Modify = *  {           ;with this parameter as * ????
                Events = 1111{ al /of}
                }
        }
}
 
 
***************
It's posible to put in Context * or it must be a Real Termonation Id
Thanks
                                    


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Tue Jan 13 15:36:49 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11656
	for <megaco-archive@odin.ietf.org>; Tue, 13 Jan 2004 15:36:49 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgVGv-0001es-A8
	for megaco-archive@odin.ietf.org; Tue, 13 Jan 2004 15:36:21 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DKaL6o006368
	for megaco-archive@odin.ietf.org; Tue, 13 Jan 2004 15:36:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgVGv-0001ed-6v
	for megaco-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 15:36:21 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11612
	for <megaco-web-archive@ietf.org>; Tue, 13 Jan 2004 15:36:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgVGt-000433-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 15:36:19 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgVFA-00040I-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 15:34:33 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgVDh-0003xO-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 15:33:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgVDh-0001Hh-GD; Tue, 13 Jan 2004 15:33:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgVDF-0001G9-Ph
	for megaco@optimus.ietf.org; Tue, 13 Jan 2004 15:32:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11436
	for <megaco@ietf.org>; Tue, 13 Jan 2004 15:32:31 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgVDE-0003v1-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:32:32 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgVBQ-0003rb-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:30:40 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgVAF-0003nA-00
	for megaco@ietf.org; Tue, 13 Jan 2004 15:29:27 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0DKStQ27487
	for <megaco@ietf.org>; Tue, 13 Jan 2004 15:28:55 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2YF1FAN>; Tue, 13 Jan 2004 15:28:55 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0DC7B9BB@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: sampathk@cisco.com,
        "'Carlos Rodríguez Alcalá Villagra'"
	 <crav@conexion.com.py>,
        megaco@ietf.org
Subject: RE: [Megaco] Termination Id = *
Date: Tue, 13 Jan 2004 15:28:44 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60

The message referenced below talks specifically about Add commands, and
would not apply here.
 
Kevin


  _____  

From: Sampath Komanduri [mailto:sampathk@cisco.com] 
Sent: Tuesday, January 13, 2004 3:00 PM
To: 'Carlos Rodríguez Alcalá Villagra'; megaco@ietf.org
Subject: RE: [Megaco] Termination Id = *


No, you can't. al/of is an event for SCN termination. Based on the recent
discussions, SCN terminations should be specific or partially specific (see
the discussion in 
http://www.ietf.org/mail-archive/working-groups/megaco/current/msg04781.html
<http://www.ietf.org/mail-archive/working-groups/megaco/current/msg04781.htm
l> ) 
 
Thanks,
Sampath

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Carlos Rodríguez Alcalá Villagra
Sent: Tuesday, January 13, 2004 7:51 AM
To: megaco@ietf.org
Subject: [Megaco] Termination Id = *


 
Can I create this packet??
 
Mgc to mg1:
MEGACO/1 [123.123.123.4]:55555
Transaction=10001{
    Context = -  {
        Modify = *  {           ;with this parameter as * ????
                Events = 1111{ al /of}
                }
        }
}
 
 
***************
It's posible to put in Context * or it must be a Real Termonation Id
Thanks
                                    


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Jan 13 20:43:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26629
	for <megaco-archive@lists.ietf.org>; Tue, 13 Jan 2004 20:43:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aga3h-0007Gs-4N; Tue, 13 Jan 2004 20:43:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aga3E-0007Fu-3v
	for megaco@optimus.ietf.org; Tue, 13 Jan 2004 20:42:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26588
	for <megaco@ietf.org>; Tue, 13 Jan 2004 20:42:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aga3B-0002i1-00
	for megaco@ietf.org; Tue, 13 Jan 2004 20:42:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aga1J-0002eO-00
	for megaco@ietf.org; Tue, 13 Jan 2004 20:40:36 -0500
Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgZzj-0002c4-00
	for megaco@ietf.org; Tue, 13 Jan 2004 20:38:55 -0500
Received: from a70444 (huawei.com [172.17.1.60])
 by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14
 2003)) with ESMTPA id <0HRG00LWVHIBW5@mta1.huawei.com> for megaco@ietf.org;
 Wed, 14 Jan 2004 09:30:13 +0800 (CST)
Date: Wed, 14 Jan 2004 09:39:18 +0800
From: Atul Saini <Atul@huawei.com>
To: megaco@ietf.org
Message-id: <002001c3da3f$3a4ceaa0$6a00460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
X-Mailer: Microsoft Outlook Express 5.50.4927.1200
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <20040113202900.3883.9447.Mailman@www1.ietf.org>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.9 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_BLUE,
	HTML_MESSAGE autolearn=no version=2.60
Content-Transfer-Encoding: 7BIT
Subject: [Megaco] Mux Related Detail  Document
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7BIT

Hi All ,

I am looking for some detail document regarding using for MUX termination.
for handling media coming from H324 terminal to be sent to RTP Audio and
Video Stream..
If Any one have some details .Please send it ASAP .
Thanks and Regards,
Atul Saini

"You  are never given a wish without being given the power to make it true;
You may have to work for it however"
                                                      Richard Bach
----- Original Message -----
From: <megaco-request@ietf.org>
To: <megaco@ietf.org>
Sent: Wednesday, January 14, 2004 4:29 AM
Subject: Megaco digest, Vol 1 #1057 - 5 msgs


> Send Megaco mailing list submissions to
> megaco@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www1.ietf.org/mailman/listinfo/megaco
> or, via email, send a message with subject or body 'help' to
> megaco-request@ietf.org
>
> You can reach the person managing the list at
> megaco-admin@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Megaco digest..."
>
>
> Today's Topics:
>
>    1. RE: TPKT value for H.248 over TCP (Sampath Komanduri)
>    2. Termination Id = *
(=?iso-8859-1?Q?Carlos_Rodr=EDguez_Alcal=E1_Villagra?=)
>    3. RE: Termination Id = * (Sampath Komanduri)
>    4. RE: Termination Id = * (Kevin Boyle)
>    5. RE: Termination Id = * (Sampath Komanduri)
>
> --__--__--
>
> Message: 1
> Reply-To: <sampathk@cisco.com>
> From: "Sampath Komanduri" <sampathk@cisco.com>
> To: "'MEGACO list'" <megaco@ietf.org>
> Subject: RE: [Megaco] TPKT value for H.248 over TCP
> Date: Tue, 13 Jan 2004 09:24:39 -0800
> Organization: Cisco Systems
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_000C_01C3D9B7.12247E90
> Content-Type: text/plain;
> charset="us-ascii"
> Content-Transfer-Encoding: 7bit
>
> Could the author of Annex D pls. respond?
>
> Thanks,
> Sampath
>
> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
> Sampath Komanduri
> Sent: Tuesday, January 06, 2004 8:16 PM
> To: 'MEGACO list'
> Subject: [Megaco] TPKT value for H.248 over TCP
> Importance: High
>
>
> Hi List,
> I am not sure if this question was already raised in the list. If it
> was, pls. point me to the discussion and the consensus.
>
> According to ANNEX D of H.248.1 protocol, "TPKT, according to
> <http://www.faqs.org/rfcs/rfc1006.html> RFC 1006, SHALL be used to
> delineate messages within the TCP stream". RFC 1006 limits the size of
> TPDU to 65524. Replicating the relevant text here for convenience:
>
> ***************************************************
>      "A TPKT consists of two parts:  a packet-header and a TPDU.
>       The format of the header is constant regardless of the type of
> packet.
>       The format of the packet-header is as follows:
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |      vrsn     |    reserved   |          packet length        |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       where:
>
>       vrsn                         8 bits
>
>       This field is always 3 for the version of the protocol described
> in this memo.
>
>       packet length                16 bits (min=7, max=65535)
>
>       This field contains the length of entire packet in octets,
> including packet-header.
>       This permits a maximum TPDU size of 65531 octets.
>       Based on the size of the data transfer (DT) TPDU, this permits a
> maximum
>       TSDU size of 65524 octets."
> *********************************************************
>
> This causes an issue. Based on the wildcard level of Audit and the
> descriptors involved, this size could easily exceed 64K size (especially
> if MG and MGC are using Long text format and white spaces in the
> messages). In few cases, it is possible to return an error code (533:
> Response exceeds maximum transport PDU size).
> However, in some cases returning 533 is not an option.
> Consider for example the following scenario: After an association is
> DISCONNECTED, MGC may want to get the list of non-null contexts on the
> gateway using the following command (pls. ignore if there is any mistake
> in the message and reply construct):
>
> !/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}}
> !/1 ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}}, ....and so
> on}
>
> In the best case (i.e. no white-space, no audit descriptor and short
> format), this allows for an MG to have only 5000 active contexts on the
> card. Anything more (or any variation in the audit command) will reduce
> the number of active contexts that an MG can have even with TCP as the
> transport option.
> Responding with 533 is not an option here since that would leave MG-MGC
> in state from where there is no elegant way out (at least from H.248
> protocol).
>
> How do the gurus' on list suggest we solve this issue? Couple of ideas
> that come to mind are:
>
> 1. Define a Bulk-Audit Package/scheme: As was done for MGCP, define
> a Bulk-Audit package/scheme especially with support for
>     RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" and
>     NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].
>     This will certainly reduce the cases and scenarios when MG/MGC will
> run into the issue under discussion but may not eliminate it.
>
> 2. Add more information on W- Audit support in the protocol.
>
> 3. Introduce RFC 1006 modification (with version field 4) such that
> "packet length" of packet header in TPKT is 32 bits as opposed to 16
> bits.
>
> 4. Combination of the above schemes.
>
> 5. Anything else?
>
> Pls. advice on how this problem can be solved?
>
> Thanks,
> Sampath
>
>
> ------=_NextPart_000_000C_01C3D9B7.12247E90
> Content-Type: text/html;
> charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Dus-ascii">
> <TITLE>Message</TITLE>
>
> <META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
> <BODY>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
> class=3D673442317-13012004>Could=20
> the author of Annex D pls. respond?</SPAN></FONT></DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
> class=3D673442317-13012004></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
> class=3D673442317-13012004>Thanks,</SPAN></FONT></DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
> class=3D673442317-13012004>Sampath</SPAN></FONT></DIV>
> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
>   <DIV></DIV>
>   <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
> align=3Dleft><FONT=20
>   face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
>   megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] <B>On Behalf Of=20
>   </B>Sampath Komanduri<BR><B>Sent:</B> Tuesday, January 06, 2004 8:16=20
>   PM<BR><B>To:</B> 'MEGACO list'<BR><B>Subject:</B> [Megaco] TPKT value =
> for=20
>   H.248 over TCP<BR><B>Importance:</B> High<BR><BR></FONT></DIV><!-- =
> Converted from text/plain format -->
>   <DIV><FONT face=3DArial size=3D2>Hi List,<BR>I am not sure if this =
> question was=20
>   already raised in the list. If it was, pls. point me to the discussion =
> and the=20
>   consensus.<BR></FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>According to ANNEX D of H.248.1 =
> protocol, "TPKT,=20
>   according to </FONT><A =
> href=3D"http://www.faqs.org/rfcs/rfc1006.html"><FONT=20
>   face=3DArial size=3D2>RFC 1006</FONT></A><FONT face=3DArial size=3D2>, =
> SHALL be used=20
>   to delineate messages within the TCP stream".&nbsp;RFC =
> 1006&nbsp;limits the=20
>   size of&nbsp;TPDU to 65524. Replicating the relevant text here for=20
>   convenience:</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial=20
>   =
> size=3D2>***************************************************</FONT></DIV>=
>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; "A TPKT =
> consists of two=20
>   parts:&nbsp; a packet-header and a TPDU.&nbsp; </FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
> format of the=20
>   header is constant regardless of the type of=20
>   packet.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The format of the =
> packet-header is=20
>   as follows:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   =
> 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   =
> 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   =
> 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   3<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0 1 2 3 4 5 6 7 8 9 0 =
> 1 2 3 4=20
>   5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
> 1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   =
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbs=
> p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; vrsn&nbsp;&nbsp;&nbsp;&nbsp;=20
>   |&nbsp;&nbsp;&nbsp; reserved&nbsp;&nbsp;=20
>   |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet=20
>   length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   =
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR><BR>=
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   where:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   =
> vrsn&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
> sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
> p;=20
>   8 bits<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This field is always 3 =
> for the=20
>   version of the protocol described in this=20
>   memo.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet=20
>   =
> length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
> nbsp;&nbsp;&nbsp;&nbsp;=20
>   16 bits (min=3D7, max=3D65535)<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
> This field=20
>   contains the length of entire packet in octets, including=20
>   packet-header.</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp; This =
> permits a maximum=20
>   TPDU size of 65531 octets.</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp; Based on =
> the size of=20
>   the data transfer (DT) TPDU, this permits a maximum </FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
> T</FONT><FONT=20
>   face=3DArial size=3D2>SDU size of 65524=20
>   =
> octets."<BR>*********************************************************<BR>=
> &nbsp;</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>This causes an issue. Based on =
> the&nbsp;wildcard=20
>   level&nbsp;of Audit and the descriptors involved, this size could =
> easily=20
>   exceed 64K size (especially if MG and MGC are using Long text format =
> and white=20
>   spaces in the messages). In few cases, it is possible to&nbsp;return=20
>   an&nbsp;error code (533: Response exceeds maximum transport PDU=20
>   size).</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>However, in some cases returning 533 =
> is not an=20
>   option. </FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>Consider for example the following =
> scenario:=20
>   After an association is DISCONNECTED, MGC may want to get =
> the&nbsp;list of=20
>   non-null contexts on the gateway using the following command (pls. =
> ignore if=20
>   there is any mistake in the message and reply construct):</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT size=3D2><FONT face=3DArial>!/1 [10.102.2.201]:4000=20
>   T=3D3700003{C=3D*{AV=3DROOT{AT{}}}}<BR></FONT><FONT face=3DArial>!/1=20
>   ABCD_MG&nbsp;P=3D3700003{C=3D</FONT></FONT><FONT face=3DArial=20
>   size=3D2>1{AV=3DC{*}},C=3D2<FONT face=3DArial>{AV=3DC{*}},C=3D3<FONT=20
>   face=3DArial>{AV=3DC{*}},&nbsp;....and so =
> on}</FONT></FONT><BR></FONT><FONT=20
>   face=3DArial></FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>In the best case (i.e. no =
> white-space, no audit=20
>   descriptor&nbsp;and short format), this allows for an MG to have only =
> 5000=20
>   active contexts on the card. Anything more (or any variation in the =
> audit=20
>   command) will reduce the number of active contexts that an MG can have =
> even=20
>   with TCP as the transport option.</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>Responding with 533 is not an option =
> here since=20
>   that would leave MG-MGC in state from where there is no elegant way =
> out (at=20
>   least from H.248 protocol).</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial size=3D2>How do the gurus' on list suggest we =
> solve this=20
>   issue? Couple of ideas that come to mind are:</FONT></DIV>
>   <OL>
>     <LI><FONT face=3DArial><FONT size=3D2>Define a Bulk-Audit =
> Package/scheme: As was=20
>     done for MGCP, define a Bulk-Audit package/scheme especially with =
> support=20
>     for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp;=20
>     RangeWildcard =3D "[" NumericalRange *( "," NumericalRange ) "]"=20
>     and<BR>&nbsp;&nbsp;&nbsp; NumericalRange&nbsp;&nbsp;&nbsp;&nbsp; =3D =
> 1*(DIGIT)=20
>     [ "-" 1*(DIGIT) ].<BR>&nbsp;&nbsp;&nbsp; This will certainly reduce =
> the=20
>     cases and scenarios when MG/MGC will run into the issue under =
> discussion but=20
>     may not eliminate it.</FONT></FONT>=20
>     <LI><FONT face=3DArial size=3D2>Add more information on W- Audit =
> support in the=20
>     protocol.</FONT>=20
>     <LI><FONT face=3DArial><FONT size=3D2>Introduce RFC 1006 =
> modification (with=20
>     version field 4) such that "packet length" of packet header in TPKT =
> is 32=20
>     bits as opposed to 16 bits.</FONT></FONT>=20
>     <LI><FONT face=3DArial><FONT size=3D2>Combination of the above=20
>     schemes.</FONT></FONT>=20
>     <LI><FONT face=3DArial size=3D2>Anything else?</FONT></LI></OL>
>   <DIV><FONT face=3DArial size=3D2>Pls. advice on how this problem can =
> be=20
>   solved?</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
> size=3D2></FONT><FONT=20
>   face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT =
> face=3DArial=20
>   size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
>   size=3D2></FONT><FONT face=3DArial size=3D2></FONT><BR><FONT =
> face=3DArial><FONT=20
>   =
> size=3D2>Thanks,<BR>Sampath</FONT></DIV></BLOCKQUOTE></FONT></BODY></HTML=
> >
>
> ------=_NextPart_000_000C_01C3D9B7.12247E90--
>
>
>
> --__--__--
>
> Message: 2
> From: =?iso-8859-1?Q?Carlos_Rodr=EDguez_Alcal=E1_Villagra?=
<crav@conexion.com.py>
> To: <megaco@ietf.org>
> Date: Tue, 13 Jan 2004 16:51:24 +0100
> Subject: [Megaco] Termination Id = *
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_0011_01C3D9F5.7AF16080
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
>
> Can I create this packet??
>
> Mgc to mg1:
> MEGACO/1 [123.123.123.4]:55555
> Transaction=3D10001{
>     Context =3D -  {
>         Modify =3D *  {           ;with this parameter as * ????
>                 Events =3D 1111{ al /of}
>                 }
>         }
> }
>
>
> ***************
> It's posible to put in Context * or it must be a Real Termonation Id
> Thanks
>                                    =20
>
> ------=_NextPart_000_0011_01C3D9F5.7AF16080
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META http-equiv=3DContent-Type content=3D"text/html; =
> charset=3Diso-8859-1">
> <META content=3D"MSHTML 6.00.2734.1600" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>Can I create this packet??</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>Mgc to mg1:</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>MEGACO/1 =
> [123.123.123.4]:55555</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>Transaction=3D10001{</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Context =3D =
> -</FONT><FONT=20
> face=3DArial size=3D2>&nbsp; {</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
> Modify =3D *=20
> &nbsp;{&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ;with this =
> parameter=20
> as * ????</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Events =3D 1111{ al =
> /of}</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
> }</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>***************</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>It's posible to put in Context * or it =
> must be a=20
> Real Termonation Id</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
> </FONT></DIV></BODY></HTML>
>
> ------=_NextPart_000_0011_01C3D9F5.7AF16080--
>
>
>
> --__--__--
>
> Message: 3
> Reply-To: <sampathk@cisco.com>
> From: "Sampath Komanduri" <sampathk@cisco.com>
> To: "=?iso-8859-1?Q?'Carlos_Rodr=EDguez_Alcal=E1_Villagra'?="
<crav@conexion.com.py>,
>         <megaco@ietf.org>
> Subject: RE: [Megaco] Termination Id = *
> Date: Tue, 13 Jan 2004 12:00:09 -0800
> Organization: Cisco Systems
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_0023_01C3D9CC.CB97B9E0
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> No, you can't. al/of is an event for SCN termination. Based on the
> recent discussions, SCN terminations should be specific or partially
> specific (see the discussion in=20
> http://www.ietf.org/mail-archive/working-groups/megaco/current/msg04781.
> html)=20
> =20
> Thanks,
> Sampath
>
> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
> Carlos Rodr=EDguez Alcal=E1 Villagra
> Sent: Tuesday, January 13, 2004 7:51 AM
> To: megaco@ietf.org
> Subject: [Megaco] Termination Id =3D *
>
>
> =20
> Can I create this packet??
> =20
> Mgc to mg1:
> MEGACO/1 [123.123.123.4]:55555
> Transaction=3D10001{
>     Context =3D -  {
>         Modify =3D *  {           ;with this parameter as * ????
>                 Events =3D 1111{ al /of}
>                 }
>         }
> }
> =20
> =20
> ***************
> It's posible to put in Context * or it must be a Real Termonation Id
> Thanks
>                                    =20
>
>
> ------=_NextPart_000_0023_01C3D9CC.CB97B9E0
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Diso-8859-1">
> <TITLE>Message</TITLE>
>
> <META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =
> size=3D2>No,=20
> you can't. al/of is an event for SCN termination. Based on the recent=20
> discussions, SCN terminations&nbsp;should be specific or partially =
> specific (see=20
> the discussion in </FONT></SPAN></DIV>
> <DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =
> size=3D2><A=20
> href=3D"http://www.ietf.org/mail-archive/working-groups/megaco/current/ms=
> g04781.html">http://www.ietf.org/mail-archive/working-groups/megaco/curre=
> nt/msg04781.html</A>)</FONT></SPAN><SPAN=20
> class=3D695305619-13012004>&nbsp;</SPAN></DIV>
> <DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =
>
> size=3D2></FONT></SPAN>&nbsp;</DIV>
> <DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =
>
> size=3D2>Thanks,</FONT></SPAN></DIV>
> <DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =
>
> size=3D2>Sampath</FONT></SPAN></DIV>
> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
>   <DIV></DIV>
>   <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
> align=3Dleft><FONT=20
>   face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
>   megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] <B>On Behalf Of=20
>   </B>Carlos Rodr=EDguez Alcal=E1 Villagra<BR><B>Sent:</B> Tuesday, =
> January 13, 2004=20
>   7:51 AM<BR><B>To:</B> megaco@ietf.org<BR><B>Subject:</B> [Megaco] =
> Termination=20
>   Id =3D *<BR><BR></FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial size=3D2>Can I create this =
> packet??</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial size=3D2>Mgc to mg1:</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>MEGACO/1 =
> [123.123.123.4]:55555</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>Transaction=3D10001{</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Context =3D =
> -</FONT><FONT=20
>   face=3DArial size=3D2>&nbsp; {</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
> Modify =3D *=20
>   &nbsp;{&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ;with this =
> parameter=20
>   as * ????</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
>
>   &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Events =3D 1111{ al =
> /of}</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
>
>   &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
>
>   }</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial size=3D2>***************</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>It's posible to put in Context * or =
> it must be a=20
>   Real Termonation Id</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
>
>   &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>   &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
> </FONT></DIV></BLOCKQUOTE></BODY></HTML>
>
> ------=_NextPart_000_0023_01C3D9CC.CB97B9E0--
>
>
>
> --__--__--
>
> Message: 4
> From: "Kevin Boyle" <kboyle@nortelnetworks.com>
> To: =?iso-8859-1?Q?Carlos_Rodr=EDguez_Alcal=E1_Villagra?=
> <crav@conexion.com.py>,
>         megaco@ietf.org
> Subject: RE: [Megaco] Termination Id = *
> Date: Tue, 13 Jan 2004 15:04:14 -0500
>
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
>
> ------_=_NextPart_001_01C3DA10.6AB1E562
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> The message as constructed below would apply the given Events =
> descriptor to
> all terminations in the NULL context.
> =20
> Kevin
>
>
>   _____ =20
>
> From: Carlos Rodr=EDguez Alcal=E1 Villagra =
> [mailto:crav@conexion.com.py]=20
> Sent: Tuesday, January 13, 2004 10:51 AM
> To: megaco@ietf.org
> Subject: [Megaco] Termination Id =3D *
>
>
> =20
> Can I create this packet??
> =20
> Mgc to mg1:
> MEGACO/1 [123.123.123.4]:55555
> Transaction=3D10001{
>     Context =3D -  {
>         Modify =3D *  {           ;with this parameter as * ????
>                 Events =3D 1111{ al /of}
>                 }
>         }
> }
> =20
> =20
> ***************
> It's posible to put in Context * or it must be a Real Termonation Id
> Thanks
>                                    =20
>
>
> ------_=_NextPart_001_01C3DA10.6AB1E562
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Diso-8859-1">
>
>
> <META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
> face=3DArial=20
> size=3D2>The message as constructed below would apply the given Events =
> descriptor=20
> to all terminations in the NULL context.</FONT></SPAN></DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
> face=3DArial=20
> size=3D2></FONT></SPAN>&nbsp;</DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
> face=3DArial=20
> size=3D2>Kevin</FONT></SPAN></DIV><BR>
> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
>   <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
> align=3Dleft>
>   <HR tabIndex=3D-1>
>   <FONT face=3DTahoma size=3D2><B>From:</B> Carlos Rodr=EDguez Alcal=E1 =
> Villagra=20
>   [mailto:crav@conexion.com.py] <BR><B>Sent:</B> Tuesday, January 13, =
> 2004 10:51=20
>   AM<BR><B>To:</B> megaco@ietf.org<BR><B>Subject:</B> [Megaco] =
> Termination Id =3D=20
>   *<BR></FONT><BR></DIV>
>   <DIV></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial size=3D2>Can I create this =
> packet??</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial size=3D2>Mgc to mg1:</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>MEGACO/1 =
> [123.123.123.4]:55555</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>Transaction=3D10001{</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Context =3D =
> -</FONT><FONT=20
>   face=3DArial size=3D2>&nbsp; {</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp; Modify =3D *=20
>   &nbsp;{&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ;with this =
> parameter=20
>   as * ????</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>   &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Events =3D 1111{ al =
> /of}</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>   &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>   }</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial size=3D2>***************</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>It's posible to put in Context * or =
> it must be a=20
>   Real Termonation Id</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>   &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>   &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
> </FONT></DIV></BLOCKQUOTE></BODY></HTML>
>
> ------_=_NextPart_001_01C3DA10.6AB1E562--
>
>
> --__--__--
>
> Message: 5
> Reply-To: <sampathk@cisco.com>
> From: "Sampath Komanduri" <sampathk@cisco.com>
> To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
>         "=?iso-8859-1?Q?'Carlos_Rodr=EDguez_Alcal=E1_Villagra'?="
<crav@conexion.com.py>,
>         <megaco@ietf.org>
> Subject: RE: [Megaco] Termination Id = *
> Date: Tue, 13 Jan 2004 12:25:09 -0800
> Organization: Cisco Systems
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_0033_01C3D9D0.4972EF80
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> Sorry, I didn't notice context "-"
>
> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
> Kevin Boyle
> Sent: Tuesday, January 13, 2004 12:04 PM
> To: Carlos Rodr=EDguez Alcal=E1 Villagra; megaco@ietf.org
> Subject: RE: [Megaco] Termination Id =3D *
>
>
> The message as constructed below would apply the given Events descriptor
> to all terminations in the NULL context.
> =20
> Kevin
>
>
>   _____ =20
>
> From: Carlos Rodr=EDguez Alcal=E1 Villagra [mailto:crav@conexion.com.py] =
>
> Sent: Tuesday, January 13, 2004 10:51 AM
> To: megaco@ietf.org
> Subject: [Megaco] Termination Id =3D *
>
>
> =20
> Can I create this packet??
> =20
> Mgc to mg1:
> MEGACO/1 [123.123.123.4]:55555
> Transaction=3D10001{
>     Context =3D -  {
>         Modify =3D *  {           ;with this parameter as * ????
>                 Events =3D 1111{ al /of}
>                 }
>         }
> }
> =20
> =20
> ***************
> It's posible to put in Context * or it must be a Real Termonation Id
> Thanks
>                                    =20
>
>
> ------=_NextPart_000_0033_01C3D9D0.4972EF80
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Diso-8859-1">
> <TITLE>Message</TITLE>
>
> <META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><SPAN class=3D569492420-13012004><FONT face=3DArial color=3D#0000ff =
> size=3D2>Sorry,=20
> I didn't notice context "-"</FONT></SPAN></DIV>
> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
>   <DIV></DIV>
>   <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
> align=3Dleft><FONT=20
>   face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
>   megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] <B>On Behalf Of =
> </B>Kevin=20
>   Boyle<BR><B>Sent:</B> Tuesday, January 13, 2004 12:04 PM<BR><B>To:</B> =
> Carlos=20
>   Rodr=EDguez Alcal=E1 Villagra; megaco@ietf.org<BR><B>Subject:</B> RE: =
> [Megaco]=20
>   Termination Id =3D *<BR><BR></FONT></DIV>
>   <DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
> face=3DArial=20
>   size=3D2>The message as constructed below would apply the given Events =
>
>   descriptor to all terminations in the NULL =
> context.</FONT></SPAN></DIV>
>   <DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
> face=3DArial=20
>   size=3D2></FONT></SPAN>&nbsp;</DIV>
>   <DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
> face=3DArial=20
>   size=3D2>Kevin</FONT></SPAN></DIV><BR>
>   <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
>     <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
> align=3Dleft>
>     <HR tabIndex=3D-1>
>     <FONT face=3DTahoma size=3D2><B>From:</B> Carlos Rodr=EDguez =
> Alcal=E1 Villagra=20
>     [mailto:crav@conexion.com.py] <BR><B>Sent:</B> Tuesday, January 13, =
> 2004=20
>     10:51 AM<BR><B>To:</B> megaco@ietf.org<BR><B>Subject:</B> [Megaco]=20
>     Termination Id =3D *<BR></FONT><BR></DIV>
>     <DIV></DIV>
>     <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>     <DIV><FONT face=3DArial size=3D2>Can I create this =
> packet??</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>     <DIV><FONT face=3DArial size=3D2>Mgc to mg1:</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>MEGACO/1 =
> [123.123.123.4]:55555</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>Transaction=3D10001{</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Context =3D =
> -</FONT><FONT=20
>     face=3DArial size=3D2>&nbsp; {</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp; Modify =3D=20
>     * &nbsp;{&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ;with =
> this=20
>     parameter as * ????</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>     &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Events =3D 1111{ al =
> /of}</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>     &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>     }</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>     <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>     <DIV><FONT face=3DArial size=3D2>***************</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>It's posible to put in Context * or =
> it must be=20
>     a Real Termonation Id</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>     &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>     &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
>   </FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
>
> ------=_NextPart_000_0033_01C3D9D0.4972EF80--
>
>
>
>
> --__--__--
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
> End of Megaco Digest


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Tue Jan 13 20:47:10 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26748
	for <megaco-archive@odin.ietf.org>; Tue, 13 Jan 2004 20:47:10 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aga7B-0007Qh-Li
	for megaco-archive@odin.ietf.org; Tue, 13 Jan 2004 20:46:42 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0E1kbjd028553
	for megaco-archive@odin.ietf.org; Tue, 13 Jan 2004 20:46:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aga7B-0007QS-Hm
	for megaco-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 20:46:37 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26728
	for <megaco-web-archive@ietf.org>; Tue, 13 Jan 2004 20:46:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aga78-0002qe-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 20:46:34 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aga5W-0002nl-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 20:44:56 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aga3g-0002kX-00
	for megaco-web-archive@ietf.org; Tue, 13 Jan 2004 20:43:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aga3h-0007Gs-4N; Tue, 13 Jan 2004 20:43:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aga3E-0007Fu-3v
	for megaco@optimus.ietf.org; Tue, 13 Jan 2004 20:42:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26588
	for <megaco@ietf.org>; Tue, 13 Jan 2004 20:42:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aga3B-0002i1-00
	for megaco@ietf.org; Tue, 13 Jan 2004 20:42:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aga1J-0002eO-00
	for megaco@ietf.org; Tue, 13 Jan 2004 20:40:36 -0500
Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgZzj-0002c4-00
	for megaco@ietf.org; Tue, 13 Jan 2004 20:38:55 -0500
Received: from a70444 (huawei.com [172.17.1.60])
 by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14
 2003)) with ESMTPA id <0HRG00LWVHIBW5@mta1.huawei.com> for megaco@ietf.org;
 Wed, 14 Jan 2004 09:30:13 +0800 (CST)
Date: Wed, 14 Jan 2004 09:39:18 +0800
From: Atul Saini <Atul@huawei.com>
To: megaco@ietf.org
Message-id: <002001c3da3f$3a4ceaa0$6a00460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
X-Mailer: Microsoft Outlook Express 5.50.4927.1200
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <20040113202900.3883.9447.Mailman@www1.ietf.org>
Content-Transfer-Encoding: 7BIT
Subject: [Megaco] Mux Related Detail  Document
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.9 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_BLUE,
	HTML_MESSAGE autolearn=no version=2.60
Content-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Hi All ,

I am looking for some detail document regarding using for MUX termination.
for handling media coming from H324 terminal to be sent to RTP Audio and
Video Stream..
If Any one have some details .Please send it ASAP .
Thanks and Regards,
Atul Saini

"You  are never given a wish without being given the power to make it true;
You may have to work for it however"
                                                      Richard Bach
----- Original Message -----
From: <megaco-request@ietf.org>
To: <megaco@ietf.org>
Sent: Wednesday, January 14, 2004 4:29 AM
Subject: Megaco digest, Vol 1 #1057 - 5 msgs


> Send Megaco mailing list submissions to
> megaco@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www1.ietf.org/mailman/listinfo/megaco
> or, via email, send a message with subject or body 'help' to
> megaco-request@ietf.org
>
> You can reach the person managing the list at
> megaco-admin@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Megaco digest..."
>
>
> Today's Topics:
>
>    1. RE: TPKT value for H.248 over TCP (Sampath Komanduri)
>    2. Termination Id = *
(=?iso-8859-1?Q?Carlos_Rodr=EDguez_Alcal=E1_Villagra?=)
>    3. RE: Termination Id = * (Sampath Komanduri)
>    4. RE: Termination Id = * (Kevin Boyle)
>    5. RE: Termination Id = * (Sampath Komanduri)
>
> --__--__--
>
> Message: 1
> Reply-To: <sampathk@cisco.com>
> From: "Sampath Komanduri" <sampathk@cisco.com>
> To: "'MEGACO list'" <megaco@ietf.org>
> Subject: RE: [Megaco] TPKT value for H.248 over TCP
> Date: Tue, 13 Jan 2004 09:24:39 -0800
> Organization: Cisco Systems
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_000C_01C3D9B7.12247E90
> Content-Type: text/plain;
> charset="us-ascii"
> Content-Transfer-Encoding: 7bit
>
> Could the author of Annex D pls. respond?
>
> Thanks,
> Sampath
>
> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
> Sampath Komanduri
> Sent: Tuesday, January 06, 2004 8:16 PM
> To: 'MEGACO list'
> Subject: [Megaco] TPKT value for H.248 over TCP
> Importance: High
>
>
> Hi List,
> I am not sure if this question was already raised in the list. If it
> was, pls. point me to the discussion and the consensus.
>
> According to ANNEX D of H.248.1 protocol, "TPKT, according to
> <http://www.faqs.org/rfcs/rfc1006.html> RFC 1006, SHALL be used to
> delineate messages within the TCP stream". RFC 1006 limits the size of
> TPDU to 65524. Replicating the relevant text here for convenience:
>
> ***************************************************
>      "A TPKT consists of two parts:  a packet-header and a TPDU.
>       The format of the header is constant regardless of the type of
> packet.
>       The format of the packet-header is as follows:
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |      vrsn     |    reserved   |          packet length        |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       where:
>
>       vrsn                         8 bits
>
>       This field is always 3 for the version of the protocol described
> in this memo.
>
>       packet length                16 bits (min=7, max=65535)
>
>       This field contains the length of entire packet in octets,
> including packet-header.
>       This permits a maximum TPDU size of 65531 octets.
>       Based on the size of the data transfer (DT) TPDU, this permits a
> maximum
>       TSDU size of 65524 octets."
> *********************************************************
>
> This causes an issue. Based on the wildcard level of Audit and the
> descriptors involved, this size could easily exceed 64K size (especially
> if MG and MGC are using Long text format and white spaces in the
> messages). In few cases, it is possible to return an error code (533:
> Response exceeds maximum transport PDU size).
> However, in some cases returning 533 is not an option.
> Consider for example the following scenario: After an association is
> DISCONNECTED, MGC may want to get the list of non-null contexts on the
> gateway using the following command (pls. ignore if there is any mistake
> in the message and reply construct):
>
> !/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}}
> !/1 ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}}, ....and so
> on}
>
> In the best case (i.e. no white-space, no audit descriptor and short
> format), this allows for an MG to have only 5000 active contexts on the
> card. Anything more (or any variation in the audit command) will reduce
> the number of active contexts that an MG can have even with TCP as the
> transport option.
> Responding with 533 is not an option here since that would leave MG-MGC
> in state from where there is no elegant way out (at least from H.248
> protocol).
>
> How do the gurus' on list suggest we solve this issue? Couple of ideas
> that come to mind are:
>
> 1. Define a Bulk-Audit Package/scheme: As was done for MGCP, define
> a Bulk-Audit package/scheme especially with support for
>     RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" and
>     NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].
>     This will certainly reduce the cases and scenarios when MG/MGC will
> run into the issue under discussion but may not eliminate it.
>
> 2. Add more information on W- Audit support in the protocol.
>
> 3. Introduce RFC 1006 modification (with version field 4) such that
> "packet length" of packet header in TPKT is 32 bits as opposed to 16
> bits.
>
> 4. Combination of the above schemes.
>
> 5. Anything else?
>
> Pls. advice on how this problem can be solved?
>
> Thanks,
> Sampath
>
>
> ------=_NextPart_000_000C_01C3D9B7.12247E90
> Content-Type: text/html;
> charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Dus-ascii">
> <TITLE>Message</TITLE>
>
> <META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
> <BODY>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
> class=3D673442317-13012004>Could=20
> the author of Annex D pls. respond?</SPAN></FONT></DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
> class=3D673442317-13012004></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
> class=3D673442317-13012004>Thanks,</SPAN></FONT></DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
> class=3D673442317-13012004>Sampath</SPAN></FONT></DIV>
> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
>   <DIV></DIV>
>   <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
> align=3Dleft><FONT=20
>   face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
>   megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] <B>On Behalf Of=20
>   </B>Sampath Komanduri<BR><B>Sent:</B> Tuesday, January 06, 2004 8:16=20
>   PM<BR><B>To:</B> 'MEGACO list'<BR><B>Subject:</B> [Megaco] TPKT value =
> for=20
>   H.248 over TCP<BR><B>Importance:</B> High<BR><BR></FONT></DIV><!-- =
> Converted from text/plain format -->
>   <DIV><FONT face=3DArial size=3D2>Hi List,<BR>I am not sure if this =
> question was=20
>   already raised in the list. If it was, pls. point me to the discussion =
> and the=20
>   consensus.<BR></FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>According to ANNEX D of H.248.1 =
> protocol, "TPKT,=20
>   according to </FONT><A =
> href=3D"http://www.faqs.org/rfcs/rfc1006.html"><FONT=20
>   face=3DArial size=3D2>RFC 1006</FONT></A><FONT face=3DArial size=3D2>, =
> SHALL be used=20
>   to delineate messages within the TCP stream".&nbsp;RFC =
> 1006&nbsp;limits the=20
>   size of&nbsp;TPDU to 65524. Replicating the relevant text here for=20
>   convenience:</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial=20
>   =
> size=3D2>***************************************************</FONT></DIV>=
>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; "A TPKT =
> consists of two=20
>   parts:&nbsp; a packet-header and a TPDU.&nbsp; </FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
> format of the=20
>   header is constant regardless of the type of=20
>   packet.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The format of the =
> packet-header is=20
>   as follows:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   =
> 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   =
> 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   =
> 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   3<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0 1 2 3 4 5 6 7 8 9 0 =
> 1 2 3 4=20
>   5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
> 1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   =
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbs=
> p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; vrsn&nbsp;&nbsp;&nbsp;&nbsp;=20
>   |&nbsp;&nbsp;&nbsp; reserved&nbsp;&nbsp;=20
>   |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet=20
>   length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   =
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR><BR>=
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   where:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>   =
> vrsn&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
> sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
> p;=20
>   8 bits<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This field is always 3 =
> for the=20
>   version of the protocol described in this=20
>   memo.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet=20
>   =
> length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
> nbsp;&nbsp;&nbsp;&nbsp;=20
>   16 bits (min=3D7, max=3D65535)<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
> This field=20
>   contains the length of entire packet in octets, including=20
>   packet-header.</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp; This =
> permits a maximum=20
>   TPDU size of 65531 octets.</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp; Based on =
> the size of=20
>   the data transfer (DT) TPDU, this permits a maximum </FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
> T</FONT><FONT=20
>   face=3DArial size=3D2>SDU size of 65524=20
>   =
> octets."<BR>*********************************************************<BR>=
> &nbsp;</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>This causes an issue. Based on =
> the&nbsp;wildcard=20
>   level&nbsp;of Audit and the descriptors involved, this size could =
> easily=20
>   exceed 64K size (especially if MG and MGC are using Long text format =
> and white=20
>   spaces in the messages). In few cases, it is possible to&nbsp;return=20
>   an&nbsp;error code (533: Response exceeds maximum transport PDU=20
>   size).</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>However, in some cases returning 533 =
> is not an=20
>   option. </FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>Consider for example the following =
> scenario:=20
>   After an association is DISCONNECTED, MGC may want to get =
> the&nbsp;list of=20
>   non-null contexts on the gateway using the following command (pls. =
> ignore if=20
>   there is any mistake in the message and reply construct):</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT size=3D2><FONT face=3DArial>!/1 [10.102.2.201]:4000=20
>   T=3D3700003{C=3D*{AV=3DROOT{AT{}}}}<BR></FONT><FONT face=3DArial>!/1=20
>   ABCD_MG&nbsp;P=3D3700003{C=3D</FONT></FONT><FONT face=3DArial=20
>   size=3D2>1{AV=3DC{*}},C=3D2<FONT face=3DArial>{AV=3DC{*}},C=3D3<FONT=20
>   face=3DArial>{AV=3DC{*}},&nbsp;....and so =
> on}</FONT></FONT><BR></FONT><FONT=20
>   face=3DArial></FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>In the best case (i.e. no =
> white-space, no audit=20
>   descriptor&nbsp;and short format), this allows for an MG to have only =
> 5000=20
>   active contexts on the card. Anything more (or any variation in the =
> audit=20
>   command) will reduce the number of active contexts that an MG can have =
> even=20
>   with TCP as the transport option.</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>Responding with 533 is not an option =
> here since=20
>   that would leave MG-MGC in state from where there is no elegant way =
> out (at=20
>   least from H.248 protocol).</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial size=3D2>How do the gurus' on list suggest we =
> solve this=20
>   issue? Couple of ideas that come to mind are:</FONT></DIV>
>   <OL>
>     <LI><FONT face=3DArial><FONT size=3D2>Define a Bulk-Audit =
> Package/scheme: As was=20
>     done for MGCP, define a Bulk-Audit package/scheme especially with =
> support=20
>     for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp;=20
>     RangeWildcard =3D "[" NumericalRange *( "," NumericalRange ) "]"=20
>     and<BR>&nbsp;&nbsp;&nbsp; NumericalRange&nbsp;&nbsp;&nbsp;&nbsp; =3D =
> 1*(DIGIT)=20
>     [ "-" 1*(DIGIT) ].<BR>&nbsp;&nbsp;&nbsp; This will certainly reduce =
> the=20
>     cases and scenarios when MG/MGC will run into the issue under =
> discussion but=20
>     may not eliminate it.</FONT></FONT>=20
>     <LI><FONT face=3DArial size=3D2>Add more information on W- Audit =
> support in the=20
>     protocol.</FONT>=20
>     <LI><FONT face=3DArial><FONT size=3D2>Introduce RFC 1006 =
> modification (with=20
>     version field 4) such that "packet length" of packet header in TPKT =
> is 32=20
>     bits as opposed to 16 bits.</FONT></FONT>=20
>     <LI><FONT face=3DArial><FONT size=3D2>Combination of the above=20
>     schemes.</FONT></FONT>=20
>     <LI><FONT face=3DArial size=3D2>Anything else?</FONT></LI></OL>
>   <DIV><FONT face=3DArial size=3D2>Pls. advice on how this problem can =
> be=20
>   solved?</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
> size=3D2></FONT><FONT=20
>   face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT =
> face=3DArial=20
>   size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
>   size=3D2></FONT><FONT face=3DArial size=3D2></FONT><BR><FONT =
> face=3DArial><FONT=20
>   =
> size=3D2>Thanks,<BR>Sampath</FONT></DIV></BLOCKQUOTE></FONT></BODY></HTML=
> >
>
> ------=_NextPart_000_000C_01C3D9B7.12247E90--
>
>
>
> --__--__--
>
> Message: 2
> From: =?iso-8859-1?Q?Carlos_Rodr=EDguez_Alcal=E1_Villagra?=
<crav@conexion.com.py>
> To: <megaco@ietf.org>
> Date: Tue, 13 Jan 2004 16:51:24 +0100
> Subject: [Megaco] Termination Id = *
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_0011_01C3D9F5.7AF16080
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
>
> Can I create this packet??
>
> Mgc to mg1:
> MEGACO/1 [123.123.123.4]:55555
> Transaction=3D10001{
>     Context =3D -  {
>         Modify =3D *  {           ;with this parameter as * ????
>                 Events =3D 1111{ al /of}
>                 }
>         }
> }
>
>
> ***************
> It's posible to put in Context * or it must be a Real Termonation Id
> Thanks
>                                    =20
>
> ------=_NextPart_000_0011_01C3D9F5.7AF16080
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META http-equiv=3DContent-Type content=3D"text/html; =
> charset=3Diso-8859-1">
> <META content=3D"MSHTML 6.00.2734.1600" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>Can I create this packet??</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>Mgc to mg1:</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>MEGACO/1 =
> [123.123.123.4]:55555</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>Transaction=3D10001{</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Context =3D =
> -</FONT><FONT=20
> face=3DArial size=3D2>&nbsp; {</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
> Modify =3D *=20
> &nbsp;{&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ;with this =
> parameter=20
> as * ????</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Events =3D 1111{ al =
> /of}</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
> }</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>***************</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>It's posible to put in Context * or it =
> must be a=20
> Real Termonation Id</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
> </FONT></DIV></BODY></HTML>
>
> ------=_NextPart_000_0011_01C3D9F5.7AF16080--
>
>
>
> --__--__--
>
> Message: 3
> Reply-To: <sampathk@cisco.com>
> From: "Sampath Komanduri" <sampathk@cisco.com>
> To: "=?iso-8859-1?Q?'Carlos_Rodr=EDguez_Alcal=E1_Villagra'?="
<crav@conexion.com.py>,
>         <megaco@ietf.org>
> Subject: RE: [Megaco] Termination Id = *
> Date: Tue, 13 Jan 2004 12:00:09 -0800
> Organization: Cisco Systems
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_0023_01C3D9CC.CB97B9E0
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> No, you can't. al/of is an event for SCN termination. Based on the
> recent discussions, SCN terminations should be specific or partially
> specific (see the discussion in=20
> http://www.ietf.org/mail-archive/working-groups/megaco/current/msg04781.
> html)=20
> =20
> Thanks,
> Sampath
>
> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
> Carlos Rodr=EDguez Alcal=E1 Villagra
> Sent: Tuesday, January 13, 2004 7:51 AM
> To: megaco@ietf.org
> Subject: [Megaco] Termination Id =3D *
>
>
> =20
> Can I create this packet??
> =20
> Mgc to mg1:
> MEGACO/1 [123.123.123.4]:55555
> Transaction=3D10001{
>     Context =3D -  {
>         Modify =3D *  {           ;with this parameter as * ????
>                 Events =3D 1111{ al /of}
>                 }
>         }
> }
> =20
> =20
> ***************
> It's posible to put in Context * or it must be a Real Termonation Id
> Thanks
>                                    =20
>
>
> ------=_NextPart_000_0023_01C3D9CC.CB97B9E0
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Diso-8859-1">
> <TITLE>Message</TITLE>
>
> <META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =
> size=3D2>No,=20
> you can't. al/of is an event for SCN termination. Based on the recent=20
> discussions, SCN terminations&nbsp;should be specific or partially =
> specific (see=20
> the discussion in </FONT></SPAN></DIV>
> <DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =
> size=3D2><A=20
> href=3D"http://www.ietf.org/mail-archive/working-groups/megaco/current/ms=
> g04781.html">http://www.ietf.org/mail-archive/working-groups/megaco/curre=
> nt/msg04781.html</A>)</FONT></SPAN><SPAN=20
> class=3D695305619-13012004>&nbsp;</SPAN></DIV>
> <DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =
>
> size=3D2></FONT></SPAN>&nbsp;</DIV>
> <DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =
>
> size=3D2>Thanks,</FONT></SPAN></DIV>
> <DIV><SPAN class=3D695305619-13012004><FONT face=3DArial color=3D#0000ff =
>
> size=3D2>Sampath</FONT></SPAN></DIV>
> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
>   <DIV></DIV>
>   <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
> align=3Dleft><FONT=20
>   face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
>   megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] <B>On Behalf Of=20
>   </B>Carlos Rodr=EDguez Alcal=E1 Villagra<BR><B>Sent:</B> Tuesday, =
> January 13, 2004=20
>   7:51 AM<BR><B>To:</B> megaco@ietf.org<BR><B>Subject:</B> [Megaco] =
> Termination=20
>   Id =3D *<BR><BR></FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial size=3D2>Can I create this =
> packet??</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial size=3D2>Mgc to mg1:</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>MEGACO/1 =
> [123.123.123.4]:55555</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>Transaction=3D10001{</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Context =3D =
> -</FONT><FONT=20
>   face=3DArial size=3D2>&nbsp; {</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
> Modify =3D *=20
>   &nbsp;{&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ;with this =
> parameter=20
>   as * ????</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
>
>   &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Events =3D 1111{ al =
> /of}</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
>
>   &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
>
>   }</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial size=3D2>***************</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>It's posible to put in Context * or =
> it must be a=20
>   Real Termonation Id</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
>
>   &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>   &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
> </FONT></DIV></BLOCKQUOTE></BODY></HTML>
>
> ------=_NextPart_000_0023_01C3D9CC.CB97B9E0--
>
>
>
> --__--__--
>
> Message: 4
> From: "Kevin Boyle" <kboyle@nortelnetworks.com>
> To: =?iso-8859-1?Q?Carlos_Rodr=EDguez_Alcal=E1_Villagra?=
> <crav@conexion.com.py>,
>         megaco@ietf.org
> Subject: RE: [Megaco] Termination Id = *
> Date: Tue, 13 Jan 2004 15:04:14 -0500
>
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
>
> ------_=_NextPart_001_01C3DA10.6AB1E562
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> The message as constructed below would apply the given Events =
> descriptor to
> all terminations in the NULL context.
> =20
> Kevin
>
>
>   _____ =20
>
> From: Carlos Rodr=EDguez Alcal=E1 Villagra =
> [mailto:crav@conexion.com.py]=20
> Sent: Tuesday, January 13, 2004 10:51 AM
> To: megaco@ietf.org
> Subject: [Megaco] Termination Id =3D *
>
>
> =20
> Can I create this packet??
> =20
> Mgc to mg1:
> MEGACO/1 [123.123.123.4]:55555
> Transaction=3D10001{
>     Context =3D -  {
>         Modify =3D *  {           ;with this parameter as * ????
>                 Events =3D 1111{ al /of}
>                 }
>         }
> }
> =20
> =20
> ***************
> It's posible to put in Context * or it must be a Real Termonation Id
> Thanks
>                                    =20
>
>
> ------_=_NextPart_001_01C3DA10.6AB1E562
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Diso-8859-1">
>
>
> <META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
> face=3DArial=20
> size=3D2>The message as constructed below would apply the given Events =
> descriptor=20
> to all terminations in the NULL context.</FONT></SPAN></DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
> face=3DArial=20
> size=3D2></FONT></SPAN>&nbsp;</DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
> face=3DArial=20
> size=3D2>Kevin</FONT></SPAN></DIV><BR>
> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
>   <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
> align=3Dleft>
>   <HR tabIndex=3D-1>
>   <FONT face=3DTahoma size=3D2><B>From:</B> Carlos Rodr=EDguez Alcal=E1 =
> Villagra=20
>   [mailto:crav@conexion.com.py] <BR><B>Sent:</B> Tuesday, January 13, =
> 2004 10:51=20
>   AM<BR><B>To:</B> megaco@ietf.org<BR><B>Subject:</B> [Megaco] =
> Termination Id =3D=20
>   *<BR></FONT><BR></DIV>
>   <DIV></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial size=3D2>Can I create this =
> packet??</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial size=3D2>Mgc to mg1:</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>MEGACO/1 =
> [123.123.123.4]:55555</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>Transaction=3D10001{</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Context =3D =
> -</FONT><FONT=20
>   face=3DArial size=3D2>&nbsp; {</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp; Modify =3D *=20
>   &nbsp;{&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ;with this =
> parameter=20
>   as * ????</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>   &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Events =3D 1111{ al =
> /of}</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>   &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>   }</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial size=3D2>***************</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>It's posible to put in Context * or =
> it must be a=20
>   Real Termonation Id</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>   &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>   &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
> </FONT></DIV></BLOCKQUOTE></BODY></HTML>
>
> ------_=_NextPart_001_01C3DA10.6AB1E562--
>
>
> --__--__--
>
> Message: 5
> Reply-To: <sampathk@cisco.com>
> From: "Sampath Komanduri" <sampathk@cisco.com>
> To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
>         "=?iso-8859-1?Q?'Carlos_Rodr=EDguez_Alcal=E1_Villagra'?="
<crav@conexion.com.py>,
>         <megaco@ietf.org>
> Subject: RE: [Megaco] Termination Id = *
> Date: Tue, 13 Jan 2004 12:25:09 -0800
> Organization: Cisco Systems
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_0033_01C3D9D0.4972EF80
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> Sorry, I didn't notice context "-"
>
> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
> Kevin Boyle
> Sent: Tuesday, January 13, 2004 12:04 PM
> To: Carlos Rodr=EDguez Alcal=E1 Villagra; megaco@ietf.org
> Subject: RE: [Megaco] Termination Id =3D *
>
>
> The message as constructed below would apply the given Events descriptor
> to all terminations in the NULL context.
> =20
> Kevin
>
>
>   _____ =20
>
> From: Carlos Rodr=EDguez Alcal=E1 Villagra [mailto:crav@conexion.com.py] =
>
> Sent: Tuesday, January 13, 2004 10:51 AM
> To: megaco@ietf.org
> Subject: [Megaco] Termination Id =3D *
>
>
> =20
> Can I create this packet??
> =20
> Mgc to mg1:
> MEGACO/1 [123.123.123.4]:55555
> Transaction=3D10001{
>     Context =3D -  {
>         Modify =3D *  {           ;with this parameter as * ????
>                 Events =3D 1111{ al /of}
>                 }
>         }
> }
> =20
> =20
> ***************
> It's posible to put in Context * or it must be a Real Termonation Id
> Thanks
>                                    =20
>
>
> ------=_NextPart_000_0033_01C3D9D0.4972EF80
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Diso-8859-1">
> <TITLE>Message</TITLE>
>
> <META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><SPAN class=3D569492420-13012004><FONT face=3DArial color=3D#0000ff =
> size=3D2>Sorry,=20
> I didn't notice context "-"</FONT></SPAN></DIV>
> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
>   <DIV></DIV>
>   <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
> align=3Dleft><FONT=20
>   face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
>   megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] <B>On Behalf Of =
> </B>Kevin=20
>   Boyle<BR><B>Sent:</B> Tuesday, January 13, 2004 12:04 PM<BR><B>To:</B> =
> Carlos=20
>   Rodr=EDguez Alcal=E1 Villagra; megaco@ietf.org<BR><B>Subject:</B> RE: =
> [Megaco]=20
>   Termination Id =3D *<BR><BR></FONT></DIV>
>   <DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
> face=3DArial=20
>   size=3D2>The message as constructed below would apply the given Events =
>
>   descriptor to all terminations in the NULL =
> context.</FONT></SPAN></DIV>
>   <DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
> face=3DArial=20
>   size=3D2></FONT></SPAN>&nbsp;</DIV>
>   <DIV dir=3Dltr align=3Dleft><SPAN class=3D973370220-13012004><FONT =
> face=3DArial=20
>   size=3D2>Kevin</FONT></SPAN></DIV><BR>
>   <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
>     <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
> align=3Dleft>
>     <HR tabIndex=3D-1>
>     <FONT face=3DTahoma size=3D2><B>From:</B> Carlos Rodr=EDguez =
> Alcal=E1 Villagra=20
>     [mailto:crav@conexion.com.py] <BR><B>Sent:</B> Tuesday, January 13, =
> 2004=20
>     10:51 AM<BR><B>To:</B> megaco@ietf.org<BR><B>Subject:</B> [Megaco]=20
>     Termination Id =3D *<BR></FONT><BR></DIV>
>     <DIV></DIV>
>     <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>     <DIV><FONT face=3DArial size=3D2>Can I create this =
> packet??</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>     <DIV><FONT face=3DArial size=3D2>Mgc to mg1:</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>MEGACO/1 =
> [123.123.123.4]:55555</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>Transaction=3D10001{</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Context =3D =
> -</FONT><FONT=20
>     face=3DArial size=3D2>&nbsp; {</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp; Modify =3D=20
>     * &nbsp;{&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ;with =
> this=20
>     parameter as * ????</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>     &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Events =3D 1111{ al =
> /of}</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>     &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>     }</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>     <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
>     <DIV><FONT face=3DArial size=3D2>***************</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>It's posible to put in Context * or =
> it must be=20
>     a Real Termonation Id</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
>     <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>     &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
>     &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
>   </FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
>
> ------=_NextPart_000_0033_01C3D9D0.4972EF80--
>
>
>
>
> --__--__--
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
> End of Megaco Digest


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan 14 09:05:33 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18318
	for <megaco-archive@lists.ietf.org>; Wed, 14 Jan 2004 09:05:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agldn-0008TS-Iw; Wed, 14 Jan 2004 09:05:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgldS-0008Rm-IQ
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 09:04:42 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18279
	for <megaco@ietf.org>; Wed, 14 Jan 2004 09:04:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgldR-0004Ac-00
	for megaco@ietf.org; Wed, 14 Jan 2004 09:04:41 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aglbe-00048V-00
	for megaco@ietf.org; Wed, 14 Jan 2004 09:02:51 -0500
Received: from ext-proxy-2.ftel.co.uk ([192.65.220.98])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aglb2-00045Y-00
	for megaco@ietf.org; Wed, 14 Jan 2004 09:02:12 -0500
Received: from utility-3.ftel.co.uk (utility-3.ftel.co.uk [193.112.172.12])
	by ext-proxy-2.ftel.co.uk (8.12.10/8.12.9/Revision:1.91/relay-in/ssl/db) with ESMTP id i0EE1XMu014226
	for <megaco@ietf.org>; Wed, 14 Jan 2004 14:01:34 GMT
Received: from DALLAPTOP (temp-ppp-19.ftel.co.uk [193.123.211.19])
	by utility-3.ftel.co.uk (8.12.9+Sun/8.12.9/Revision:1.90/db) with SMTP id i0EE1PxH014234
	for <megaco@ietf.org>; Wed, 14 Jan 2004 14:01:26 GMT
Message-ID: <003a01c3daa6$e7969e60$13d37bc1@DALLAPTOP>
From: "Dal Chohan" <D.Chohan@ftel.co.uk>
To: "MEGACO list" <megaco@ietf.org>
Date: Wed, 14 Jan 2004 14:01:23 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0037_01C3DAA6.E4B30670"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_40_50,HTML_MESSAGE 
	autolearn=no version=2.60
Subject: [Megaco] Points for clarification on H.248.16 extended DTMF Detection Package.
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0037_01C3DAA6.E4B30670
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Whilst studying the H.248.16 "xdd" package I noticed the following =
anomalies/points for clarification:



1. Unmatched event parameter ("extra")=20


(a) According to H.248.1 version 2 "clause 7.1.14.5 item 5 (a)" this =
suggests that the reporting off the unmatched event is controlled by the =
digit map completion event. But this capability doesn't appear to be =
included in the "xdd" package. Is the assumption that the "umatched =
event" parameter is always reported when completion is triggered by an =
event that results in no remaining candidates ?

(b) The current text associated with the "extra" parameter under the =
heading "possible values" suffers from too many "nots" and is =
potentially confusing to the reader - 'Not included if completion was =
not triggered by an unmatched event (extra digit)'. This sentence should =
be deleted, because the text under the heading "description" adequately =
describes the case when this parameter is included.



2. Shortest Digit Match

Item 5 of the procedures in H.248.16 for package "xdd" indicates that in =
the case where  no candidates remain for match, then a digit completion =
event is sent with a"partial match". However, no procedures are defined =
with respect to how the additional event that resulted in 'no =
candidates' for match is handled as per H.248.1 version 2 clauses 5(a) =
and 5 (b). Is the extra digit discarded (if specified by parameter =
"xdd") or buffered and is the event reported via parameter "extra" etc.







Dal Chohan

------=_NextPart_000_0037_01C3DAA6.E4B30670
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Whilst studying the H.248.16 "xdd" =
package I=20
noticed the following anomalies/points for clarification:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1. Unmatched event parameter ("extra")=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>(a) According to H.248.1 version 2 =
"clause 7.1.14.5=20
item 5 (a)" this suggests that the reporting off the unmatched event is=20
controlled by the digit map completion event. But this capability =
doesn't appear=20
to be included in the "xdd" package. Is the assumption that the =
"umatched event"=20
parameter&nbsp;is always reported when completion is triggered by an =
event that=20
results in no remaining candidates ?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2>(b) The current text associated =
with the=20
"extra" parameter under the heading "possible values" suffers from too =
many=20
"nots" and is potentially confusing to the reader -&nbsp;<FONT=20
face=3D"Times New Roman">'<SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; =
mso-ansi-language: EN-GB; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA">Not=20
included if completion was not triggered by an unmatched event (extra =
digit)'.=20
<FONT face=3DArial size=3D2>This sentence should be deleted, because the =
text under=20
the heading "description" adequately describes the case when this =
parameter is=20
included.</FONT></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"><FONT =
face=3DArial=20
size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; =
mso-ansi-language: EN-GB; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"><FONT =
face=3DArial=20
size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; =
mso-ansi-language: EN-GB; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"><FONT =
face=3DArial=20
size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; =
mso-ansi-language: EN-GB; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial size=3D2><SPAN =
lang=3DEN-GB=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; =
mso-ansi-language: EN-GB; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA">2.=20
<FONT face=3DArial size=3D2>Shortest Digit=20
Match</FONT></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Item 5 of the procedures in H.248.16 =
for package=20
"xdd" indicates that in the case where&nbsp; <U>no candidates</U> remain =
for=20
match, then a digit completion event is sent with a"partial match". =
However, no=20
procedures are defined with respect to how the additional event that =
resulted in=20
'no candidates' for match is handled as per H.248.1 version 2 clauses =
5(a) and 5=20
(b). Is the extra digit discarded (if specified by parameter "xdd") or =
buffered=20
and is the event reported via parameter "extra"&nbsp;etc.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Dal =
Chohan<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_0037_01C3DAA6.E4B30670--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan 14 09:09:09 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18595
	for <megaco-archive@odin.ietf.org>; Wed, 14 Jan 2004 09:09:09 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AglhI-0000Wo-Lm
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 09:08:41 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EE8eND002026
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 09:08:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AglhI-0000Wb-IZ
	for megaco-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 09:08:40 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18522
	for <megaco-web-archive@ietf.org>; Wed, 14 Jan 2004 09:08:38 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AglhG-0004Qf-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 09:08:38 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AglfO-0004Eh-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 09:06:43 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agldo-0004Bq-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 09:05:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agldn-0008TS-Iw; Wed, 14 Jan 2004 09:05:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgldS-0008Rm-IQ
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 09:04:42 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18279
	for <megaco@ietf.org>; Wed, 14 Jan 2004 09:04:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgldR-0004Ac-00
	for megaco@ietf.org; Wed, 14 Jan 2004 09:04:41 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aglbe-00048V-00
	for megaco@ietf.org; Wed, 14 Jan 2004 09:02:51 -0500
Received: from ext-proxy-2.ftel.co.uk ([192.65.220.98])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aglb2-00045Y-00
	for megaco@ietf.org; Wed, 14 Jan 2004 09:02:12 -0500
Received: from utility-3.ftel.co.uk (utility-3.ftel.co.uk [193.112.172.12])
	by ext-proxy-2.ftel.co.uk (8.12.10/8.12.9/Revision:1.91/relay-in/ssl/db) with ESMTP id i0EE1XMu014226
	for <megaco@ietf.org>; Wed, 14 Jan 2004 14:01:34 GMT
Received: from DALLAPTOP (temp-ppp-19.ftel.co.uk [193.123.211.19])
	by utility-3.ftel.co.uk (8.12.9+Sun/8.12.9/Revision:1.90/db) with SMTP id i0EE1PxH014234
	for <megaco@ietf.org>; Wed, 14 Jan 2004 14:01:26 GMT
Message-ID: <003a01c3daa6$e7969e60$13d37bc1@DALLAPTOP>
From: "Dal Chohan" <D.Chohan@ftel.co.uk>
To: "MEGACO list" <megaco@ietf.org>
Date: Wed, 14 Jan 2004 14:01:23 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0037_01C3DAA6.E4B30670"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Subject: [Megaco] Points for clarification on H.248.16 extended DTMF Detection Package.
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_40_50,HTML_MESSAGE 
	autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_0037_01C3DAA6.E4B30670
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Whilst studying the H.248.16 "xdd" package I noticed the following =
anomalies/points for clarification:



1. Unmatched event parameter ("extra")=20


(a) According to H.248.1 version 2 "clause 7.1.14.5 item 5 (a)" this =
suggests that the reporting off the unmatched event is controlled by the =
digit map completion event. But this capability doesn't appear to be =
included in the "xdd" package. Is the assumption that the "umatched =
event" parameter is always reported when completion is triggered by an =
event that results in no remaining candidates ?

(b) The current text associated with the "extra" parameter under the =
heading "possible values" suffers from too many "nots" and is =
potentially confusing to the reader - 'Not included if completion was =
not triggered by an unmatched event (extra digit)'. This sentence should =
be deleted, because the text under the heading "description" adequately =
describes the case when this parameter is included.



2. Shortest Digit Match

Item 5 of the procedures in H.248.16 for package "xdd" indicates that in =
the case where  no candidates remain for match, then a digit completion =
event is sent with a"partial match". However, no procedures are defined =
with respect to how the additional event that resulted in 'no =
candidates' for match is handled as per H.248.1 version 2 clauses 5(a) =
and 5 (b). Is the extra digit discarded (if specified by parameter =
"xdd") or buffered and is the event reported via parameter "extra" etc.







Dal Chohan

------=_NextPart_000_0037_01C3DAA6.E4B30670
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Whilst studying the H.248.16 "xdd" =
package I=20
noticed the following anomalies/points for clarification:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1. Unmatched event parameter ("extra")=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>(a) According to H.248.1 version 2 =
"clause 7.1.14.5=20
item 5 (a)" this suggests that the reporting off the unmatched event is=20
controlled by the digit map completion event. But this capability =
doesn't appear=20
to be included in the "xdd" package. Is the assumption that the =
"umatched event"=20
parameter&nbsp;is always reported when completion is triggered by an =
event that=20
results in no remaining candidates ?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2>(b) The current text associated =
with the=20
"extra" parameter under the heading "possible values" suffers from too =
many=20
"nots" and is potentially confusing to the reader -&nbsp;<FONT=20
face=3D"Times New Roman">'<SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; =
mso-ansi-language: EN-GB; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA">Not=20
included if completion was not triggered by an unmatched event (extra =
digit)'.=20
<FONT face=3DArial size=3D2>This sentence should be deleted, because the =
text under=20
the heading "description" adequately describes the case when this =
parameter is=20
included.</FONT></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"><FONT =
face=3DArial=20
size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; =
mso-ansi-language: EN-GB; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"><FONT =
face=3DArial=20
size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; =
mso-ansi-language: EN-GB; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"><FONT =
face=3DArial=20
size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; =
mso-ansi-language: EN-GB; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial size=3D2><SPAN =
lang=3DEN-GB=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; =
mso-ansi-language: EN-GB; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA">2.=20
<FONT face=3DArial size=3D2>Shortest Digit=20
Match</FONT></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Item 5 of the procedures in H.248.16 =
for package=20
"xdd" indicates that in the case where&nbsp; <U>no candidates</U> remain =
for=20
match, then a digit completion event is sent with a"partial match". =
However, no=20
procedures are defined with respect to how the additional event that =
resulted in=20
'no candidates' for match is handled as per H.248.1 version 2 clauses =
5(a) and 5=20
(b). Is the extra digit discarded (if specified by parameter "xdd") or =
buffered=20
and is the event reported via parameter "extra"&nbsp;etc.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Dal =
Chohan<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_0037_01C3DAA6.E4B30670--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan 14 13:27:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01768
	for <megaco-archive@lists.ietf.org>; Wed, 14 Jan 2004 13:27:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgpjJ-0007FZ-0u; Wed, 14 Jan 2004 13:27:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgpjD-0007Ew-FV
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 13:26:55 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01762
	for <megaco@ietf.org>; Wed, 14 Jan 2004 13:26:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgpjB-0001B5-00
	for megaco@ietf.org; Wed, 14 Jan 2004 13:26:53 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgpiJ-00019c-00
	for megaco@ietf.org; Wed, 14 Jan 2004 13:26:00 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agphe-00015c-00
	for megaco@ietf.org; Wed, 14 Jan 2004 13:25:18 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0EIOl823418
	for <megaco@ietf.org>; Wed, 14 Jan 2004 13:24:47 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2YF1WWY>; Wed, 14 Jan 2004 13:24:46 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0DCB7F45@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: sampathk@cisco.com, "'MEGACO list'" <megaco@ietf.org>
Subject: RE: [Megaco] TPKT value for H.248 over TCP
Date: Wed, 14 Jan 2004 13:24:37 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

I was under the impression that TCP segmented large packets automatically.
Is that not the case?
 
Kevin



  _____  

From: Sampath Komanduri [mailto:sampathk@cisco.com] 
Sent: Tuesday, January 13, 2004 12:25 PM
To: 'MEGACO list'
Subject: RE: [Megaco] TPKT value for H.248 over TCP


Could the author of Annex D pls. respond?
 
Thanks,
Sampath

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Sampath Komanduri
Sent: Tuesday, January 06, 2004 8:16 PM
To: 'MEGACO list'
Subject: [Megaco] TPKT value for H.248 over TCP
Importance: High


Hi List,
I am not sure if this question was already raised in the list. If it was,
pls. point me to the discussion and the consensus.

According to ANNEX D of H.248.1 protocol, "TPKT, according to
<http://www.faqs.org/rfcs/rfc1006.html> RFC 1006, SHALL be used to delineate
messages within the TCP stream". RFC 1006 limits the size of TPDU to 65524.
Replicating the relevant text here for convenience:
 
***************************************************
     "A TPKT consists of two parts:  a packet-header and a TPDU.  
      The format of the header is constant regardless of the type of packet.
      The format of the packet-header is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      vrsn     |    reserved   |          packet length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      where:

      vrsn                         8 bits

      This field is always 3 for the version of the protocol described in
this memo.

      packet length                16 bits (min=7, max=65535)

      This field contains the length of entire packet in octets, including
packet-header.
      This permits a maximum TPDU size of 65531 octets.
      Based on the size of the data transfer (DT) TPDU, this permits a
maximum 
      TSDU size of 65524 octets."
*********************************************************
 
This causes an issue. Based on the wildcard level of Audit and the
descriptors involved, this size could easily exceed 64K size (especially if
MG and MGC are using Long text format and white spaces in the messages). In
few cases, it is possible to return an error code (533: Response exceeds
maximum transport PDU size).
However, in some cases returning 533 is not an option. 
Consider for example the following scenario: After an association is
DISCONNECTED, MGC may want to get the list of non-null contexts on the
gateway using the following command (pls. ignore if there is any mistake in
the message and reply construct):
 
!/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}}
!/1 ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}}, ....and so on}

In the best case (i.e. no white-space, no audit descriptor and short
format), this allows for an MG to have only 5000 active contexts on the
card. Anything more (or any variation in the audit command) will reduce the
number of active contexts that an MG can have even with TCP as the transport
option.
Responding with 533 is not an option here since that would leave MG-MGC in
state from where there is no elegant way out (at least from H.248 protocol).
 
How do the gurus' on list suggest we solve this issue? Couple of ideas that
come to mind are:

1.	Define a Bulk-Audit Package/scheme: As was done for MGCP, define a
Bulk-Audit package/scheme especially with support for       
    RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" and
    NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].
    This will certainly reduce the cases and scenarios when MG/MGC will run
into the issue under discussion but may not eliminate it. 

2.	Add more information on W- Audit support in the protocol. 

3.	Introduce RFC 1006 modification (with version field 4) such that
"packet length" of packet header in TPKT is 32 bits as opposed to 16 bits. 

4.	Combination of the above schemes. 

5.	Anything else?

Pls. advice on how this problem can be solved?

Thanks,
Sampath


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan 14 13:29:17 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01827
	for <megaco-archive@odin.ietf.org>; Wed, 14 Jan 2004 13:29:17 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agpl5-0007Qs-5l
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 13:28:51 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EISpch028566
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 13:28:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agpl5-0007Qf-1i
	for megaco-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 13:28:51 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01814
	for <megaco-web-archive@ietf.org>; Wed, 14 Jan 2004 13:28:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agpl2-0001ET-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 13:28:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Agpk9-0001DV-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 13:27:54 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgpjK-0001CG-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 13:27:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgpjJ-0007FZ-0u; Wed, 14 Jan 2004 13:27:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgpjD-0007Ew-FV
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 13:26:55 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01762
	for <megaco@ietf.org>; Wed, 14 Jan 2004 13:26:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgpjB-0001B5-00
	for megaco@ietf.org; Wed, 14 Jan 2004 13:26:53 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgpiJ-00019c-00
	for megaco@ietf.org; Wed, 14 Jan 2004 13:26:00 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agphe-00015c-00
	for megaco@ietf.org; Wed, 14 Jan 2004 13:25:18 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0EIOl823418
	for <megaco@ietf.org>; Wed, 14 Jan 2004 13:24:47 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2YF1WWY>; Wed, 14 Jan 2004 13:24:46 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0DCB7F45@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: sampathk@cisco.com, "'MEGACO list'" <megaco@ietf.org>
Subject: RE: [Megaco] TPKT value for H.248 over TCP
Date: Wed, 14 Jan 2004 13:24:37 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60

I was under the impression that TCP segmented large packets automatically.
Is that not the case?
 
Kevin



  _____  

From: Sampath Komanduri [mailto:sampathk@cisco.com] 
Sent: Tuesday, January 13, 2004 12:25 PM
To: 'MEGACO list'
Subject: RE: [Megaco] TPKT value for H.248 over TCP


Could the author of Annex D pls. respond?
 
Thanks,
Sampath

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Sampath Komanduri
Sent: Tuesday, January 06, 2004 8:16 PM
To: 'MEGACO list'
Subject: [Megaco] TPKT value for H.248 over TCP
Importance: High


Hi List,
I am not sure if this question was already raised in the list. If it was,
pls. point me to the discussion and the consensus.

According to ANNEX D of H.248.1 protocol, "TPKT, according to
<http://www.faqs.org/rfcs/rfc1006.html> RFC 1006, SHALL be used to delineate
messages within the TCP stream". RFC 1006 limits the size of TPDU to 65524.
Replicating the relevant text here for convenience:
 
***************************************************
     "A TPKT consists of two parts:  a packet-header and a TPDU.  
      The format of the header is constant regardless of the type of packet.
      The format of the packet-header is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      vrsn     |    reserved   |          packet length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      where:

      vrsn                         8 bits

      This field is always 3 for the version of the protocol described in
this memo.

      packet length                16 bits (min=7, max=65535)

      This field contains the length of entire packet in octets, including
packet-header.
      This permits a maximum TPDU size of 65531 octets.
      Based on the size of the data transfer (DT) TPDU, this permits a
maximum 
      TSDU size of 65524 octets."
*********************************************************
 
This causes an issue. Based on the wildcard level of Audit and the
descriptors involved, this size could easily exceed 64K size (especially if
MG and MGC are using Long text format and white spaces in the messages). In
few cases, it is possible to return an error code (533: Response exceeds
maximum transport PDU size).
However, in some cases returning 533 is not an option. 
Consider for example the following scenario: After an association is
DISCONNECTED, MGC may want to get the list of non-null contexts on the
gateway using the following command (pls. ignore if there is any mistake in
the message and reply construct):
 
!/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}}
!/1 ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}}, ....and so on}

In the best case (i.e. no white-space, no audit descriptor and short
format), this allows for an MG to have only 5000 active contexts on the
card. Anything more (or any variation in the audit command) will reduce the
number of active contexts that an MG can have even with TCP as the transport
option.
Responding with 533 is not an option here since that would leave MG-MGC in
state from where there is no elegant way out (at least from H.248 protocol).
 
How do the gurus' on list suggest we solve this issue? Couple of ideas that
come to mind are:

1.	Define a Bulk-Audit Package/scheme: As was done for MGCP, define a
Bulk-Audit package/scheme especially with support for       
    RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" and
    NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].
    This will certainly reduce the cases and scenarios when MG/MGC will run
into the issue under discussion but may not eliminate it. 

2.	Add more information on W- Audit support in the protocol. 

3.	Introduce RFC 1006 modification (with version field 4) such that
"packet length" of packet header in TPKT is 32 bits as opposed to 16 bits. 

4.	Combination of the above schemes. 

5.	Anything else?

Pls. advice on how this problem can be solved?

Thanks,
Sampath


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan 14 13:39:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02286
	for <megaco-archive@lists.ietf.org>; Wed, 14 Jan 2004 13:39:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agpuu-00087K-GQ; Wed, 14 Jan 2004 13:39:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agpuk-00084k-Rv
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 13:38:51 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02255
	for <megaco@ietf.org>; Wed, 14 Jan 2004 13:38:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agpui-0001mh-00
	for megaco@ietf.org; Wed, 14 Jan 2004 13:38:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Agptk-0001kC-00
	for megaco@ietf.org; Wed, 14 Jan 2004 13:37:49 -0500
Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agpso-0001hp-00
	for megaco@ietf.org; Wed, 14 Jan 2004 13:36:50 -0500
Received: from openetsrv.ho.lucent.com (h135-17-173-5.lucent.com [135.17.173.5])
	by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0EIa9C21978;
	Wed, 14 Jan 2004 12:36:13 -0600 (CST)
Received: from MMRAJUPC by openetsrv.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id NAA20906; Wed, 14 Jan 2004 13:36:08 -0500 (EST)
From: "Raju" <mmraju@lucent.com>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>, <sampathk@cisco.com>,
        "'MEGACO list'" <megaco@ietf.org>
Subject: RE: [Megaco] TPKT value for H.248 over TCP
Date: Wed, 14 Jan 2004 12:35:21 -0600
Message-ID: <APEOKDBAKLMDJCPJCBOOIEDHDHAA.mmraju@lucent.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0DCB7F45@zrtpd0jq.us.nortel.com>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Kevin,

That's correct.
But to find the beginning and end of packets H.248 uses TPKT Version 3 (RFC
1006)
which has a header (4 bytes) followed by the H.248 msg. The TPKT  header
has 2 byte length field, using which we can only send a h248 msg of size <
65531 bytes
(the TPKT two bytes length includes the TPKT header length of 4 bytes).


Thanks
Raju

> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
> Kevin Boyle
> Sent: Wednesday, January 14, 2004 12:25 PM
> To: sampathk@cisco.com; 'MEGACO list'
> Subject: RE: [Megaco] TPKT value for H.248 over TCP
>
>
> I was under the impression that TCP segmented large packets automatically.
> Is that not the case?
>
> Kevin
>
>
>
>   _____
>
> From: Sampath Komanduri [mailto:sampathk@cisco.com]
> Sent: Tuesday, January 13, 2004 12:25 PM
> To: 'MEGACO list'
> Subject: RE: [Megaco] TPKT value for H.248 over TCP
>
>
> Could the author of Annex D pls. respond?
>
> Thanks,
> Sampath
>
> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
> Sampath Komanduri
> Sent: Tuesday, January 06, 2004 8:16 PM
> To: 'MEGACO list'
> Subject: [Megaco] TPKT value for H.248 over TCP
> Importance: High
>
>
> Hi List,
> I am not sure if this question was already raised in the list. If it was,
> pls. point me to the discussion and the consensus.
>
> According to ANNEX D of H.248.1 protocol, "TPKT, according to
> <http://www.faqs.org/rfcs/rfc1006.html> RFC 1006, SHALL be used
> to delineate
> messages within the TCP stream". RFC 1006 limits the size of TPDU
> to 65524.
> Replicating the relevant text here for convenience:
>
> ***************************************************
>      "A TPKT consists of two parts:  a packet-header and a TPDU.
>       The format of the header is constant regardless of the type
> of packet.
>       The format of the packet-header is as follows:
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |      vrsn     |    reserved   |          packet length        |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       where:
>
>       vrsn                         8 bits
>
>       This field is always 3 for the version of the protocol described in
> this memo.
>
>       packet length                16 bits (min=7, max=65535)
>
>       This field contains the length of entire packet in octets, including
> packet-header.
>       This permits a maximum TPDU size of 65531 octets.
>       Based on the size of the data transfer (DT) TPDU, this permits a
> maximum
>       TSDU size of 65524 octets."
> *********************************************************
>
> This causes an issue. Based on the wildcard level of Audit and the
> descriptors involved, this size could easily exceed 64K size
> (especially if
> MG and MGC are using Long text format and white spaces in the
> messages). In
> few cases, it is possible to return an error code (533: Response exceeds
> maximum transport PDU size).
> However, in some cases returning 533 is not an option.
> Consider for example the following scenario: After an association is
> DISCONNECTED, MGC may want to get the list of non-null contexts on the
> gateway using the following command (pls. ignore if there is any
> mistake in
> the message and reply construct):
>
> !/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}}
> !/1 ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}},
> ....and so on}
>
> In the best case (i.e. no white-space, no audit descriptor and short
> format), this allows for an MG to have only 5000 active contexts on the
> card. Anything more (or any variation in the audit command) will
> reduce the
> number of active contexts that an MG can have even with TCP as
> the transport
> option.
> Responding with 533 is not an option here since that would leave MG-MGC in
> state from where there is no elegant way out (at least from H.248
> protocol).
>
> How do the gurus' on list suggest we solve this issue? Couple of
> ideas that
> come to mind are:
>
> 1.	Define a Bulk-Audit Package/scheme: As was done for MGCP, define a
> Bulk-Audit package/scheme especially with support for
>     RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" and
>     NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].
>     This will certainly reduce the cases and scenarios when
> MG/MGC will run
> into the issue under discussion but may not eliminate it.
>
> 2.	Add more information on W- Audit support in the protocol.
>
> 3.	Introduce RFC 1006 modification (with version field 4) such that
> "packet length" of packet header in TPKT is 32 bits as opposed to
> 16 bits.
>
> 4.	Combination of the above schemes.
>
> 5.	Anything else?
>
> Pls. advice on how this problem can be solved?
>
> Thanks,
> Sampath
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan 14 13:42:16 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02399
	for <megaco-archive@odin.ietf.org>; Wed, 14 Jan 2004 13:42:16 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agpwk-0008II-Sr
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 13:40:55 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EIesi2031876
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 13:40:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agpwk-0008I3-Pa
	for megaco-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 13:40:54 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02336
	for <megaco-web-archive@ietf.org>; Wed, 14 Jan 2004 13:40:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agpwi-0001rJ-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 13:40:52 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Agpvn-0001px-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 13:39:56 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agpuu-0001oT-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 13:39:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agpuu-00087K-GQ; Wed, 14 Jan 2004 13:39:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agpuk-00084k-Rv
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 13:38:51 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02255
	for <megaco@ietf.org>; Wed, 14 Jan 2004 13:38:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agpui-0001mh-00
	for megaco@ietf.org; Wed, 14 Jan 2004 13:38:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Agptk-0001kC-00
	for megaco@ietf.org; Wed, 14 Jan 2004 13:37:49 -0500
Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agpso-0001hp-00
	for megaco@ietf.org; Wed, 14 Jan 2004 13:36:50 -0500
Received: from openetsrv.ho.lucent.com (h135-17-173-5.lucent.com [135.17.173.5])
	by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0EIa9C21978;
	Wed, 14 Jan 2004 12:36:13 -0600 (CST)
Received: from MMRAJUPC by openetsrv.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id NAA20906; Wed, 14 Jan 2004 13:36:08 -0500 (EST)
From: "Raju" <mmraju@lucent.com>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>, <sampathk@cisco.com>,
        "'MEGACO list'" <megaco@ietf.org>
Subject: RE: [Megaco] TPKT value for H.248 over TCP
Date: Wed, 14 Jan 2004 12:35:21 -0600
Message-ID: <APEOKDBAKLMDJCPJCBOOIEDHDHAA.mmraju@lucent.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0DCB7F45@zrtpd0jq.us.nortel.com>
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Kevin,

That's correct.
But to find the beginning and end of packets H.248 uses TPKT Version 3 (RFC
1006)
which has a header (4 bytes) followed by the H.248 msg. The TPKT  header
has 2 byte length field, using which we can only send a h248 msg of size <
65531 bytes
(the TPKT two bytes length includes the TPKT header length of 4 bytes).


Thanks
Raju

> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
> Kevin Boyle
> Sent: Wednesday, January 14, 2004 12:25 PM
> To: sampathk@cisco.com; 'MEGACO list'
> Subject: RE: [Megaco] TPKT value for H.248 over TCP
>
>
> I was under the impression that TCP segmented large packets automatically.
> Is that not the case?
>
> Kevin
>
>
>
>   _____
>
> From: Sampath Komanduri [mailto:sampathk@cisco.com]
> Sent: Tuesday, January 13, 2004 12:25 PM
> To: 'MEGACO list'
> Subject: RE: [Megaco] TPKT value for H.248 over TCP
>
>
> Could the author of Annex D pls. respond?
>
> Thanks,
> Sampath
>
> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
> Sampath Komanduri
> Sent: Tuesday, January 06, 2004 8:16 PM
> To: 'MEGACO list'
> Subject: [Megaco] TPKT value for H.248 over TCP
> Importance: High
>
>
> Hi List,
> I am not sure if this question was already raised in the list. If it was,
> pls. point me to the discussion and the consensus.
>
> According to ANNEX D of H.248.1 protocol, "TPKT, according to
> <http://www.faqs.org/rfcs/rfc1006.html> RFC 1006, SHALL be used
> to delineate
> messages within the TCP stream". RFC 1006 limits the size of TPDU
> to 65524.
> Replicating the relevant text here for convenience:
>
> ***************************************************
>      "A TPKT consists of two parts:  a packet-header and a TPDU.
>       The format of the header is constant regardless of the type
> of packet.
>       The format of the packet-header is as follows:
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |      vrsn     |    reserved   |          packet length        |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       where:
>
>       vrsn                         8 bits
>
>       This field is always 3 for the version of the protocol described in
> this memo.
>
>       packet length                16 bits (min=7, max=65535)
>
>       This field contains the length of entire packet in octets, including
> packet-header.
>       This permits a maximum TPDU size of 65531 octets.
>       Based on the size of the data transfer (DT) TPDU, this permits a
> maximum
>       TSDU size of 65524 octets."
> *********************************************************
>
> This causes an issue. Based on the wildcard level of Audit and the
> descriptors involved, this size could easily exceed 64K size
> (especially if
> MG and MGC are using Long text format and white spaces in the
> messages). In
> few cases, it is possible to return an error code (533: Response exceeds
> maximum transport PDU size).
> However, in some cases returning 533 is not an option.
> Consider for example the following scenario: After an association is
> DISCONNECTED, MGC may want to get the list of non-null contexts on the
> gateway using the following command (pls. ignore if there is any
> mistake in
> the message and reply construct):
>
> !/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}}
> !/1 ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}},
> ....and so on}
>
> In the best case (i.e. no white-space, no audit descriptor and short
> format), this allows for an MG to have only 5000 active contexts on the
> card. Anything more (or any variation in the audit command) will
> reduce the
> number of active contexts that an MG can have even with TCP as
> the transport
> option.
> Responding with 533 is not an option here since that would leave MG-MGC in
> state from where there is no elegant way out (at least from H.248
> protocol).
>
> How do the gurus' on list suggest we solve this issue? Couple of
> ideas that
> come to mind are:
>
> 1.	Define a Bulk-Audit Package/scheme: As was done for MGCP, define a
> Bulk-Audit package/scheme especially with support for
>     RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" and
>     NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].
>     This will certainly reduce the cases and scenarios when
> MG/MGC will run
> into the issue under discussion but may not eliminate it.
>
> 2.	Add more information on W- Audit support in the protocol.
>
> 3.	Introduce RFC 1006 modification (with version field 4) such that
> "packet length" of packet header in TPKT is 32 bits as opposed to
> 16 bits.
>
> 4.	Combination of the above schemes.
>
> 5.	Anything else?
>
> Pls. advice on how this problem can be solved?
>
> Thanks,
> Sampath
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan 14 13:51:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02784
	for <megaco-archive@lists.ietf.org>; Wed, 14 Jan 2004 13:51:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agq6X-0000EX-VC; Wed, 14 Jan 2004 13:51:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agq6S-0000Dl-I7
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 13:50:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02742
	for <megaco@ietf.org>; Wed, 14 Jan 2004 13:50:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agq6Q-0002Am-00
	for megaco@ietf.org; Wed, 14 Jan 2004 13:50:54 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Agq5U-00029V-00
	for megaco@ietf.org; Wed, 14 Jan 2004 13:49:58 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agq5H-00027z-00
	for megaco@ietf.org; Wed, 14 Jan 2004 13:49:43 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 14 Jan 2004 10:51:19 +0000
Received: from SAMPATHKW2K03 (dhcp-171-71-9-200.cisco.com [171.71.9.200])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0EIn9VM006920;
	Wed, 14 Jan 2004 10:49:10 -0800 (PST)
Reply-To: <sampathk@cisco.com>
From: "Sampath Komanduri" <sampathk@cisco.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'MEGACO list'" <megaco@ietf.org>
Subject: RE: [Megaco] TPKT value for H.248 over TCP
Date: Wed, 14 Jan 2004 10:49:09 -0800
Organization: Cisco Systems
Message-ID: <000a01c3dacf$1892b8a0$c80947ab@SAMPATHKW2K03>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000B_01C3DA8C.0A70FF40"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0DCB7F45@zrtpd0jq.us.nortel.com>
Importance: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C3DA8C.0A70FF40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Kevin,
The issue is not with TCP itself. The problem stems from the basis that
MEGACO is an ISO application which is designed to run over the OSI stack
(7 layer stack), not the TCP/IP stack (5 layer stack, no session or
presentation layers).  In order to make ISO protocols/applications
capable of running over TCP, a "pseudo-header" (or TPKT) in RFC1006 was
created.  This allowed support for the additional layers not found in
the TCP/IP stack.  This pseudo-header is found in the application layer
of the TCP/IP stack and has no correlation to the functions preformed at
the TCP layer.  Applications that were designed for the TCP/IP stack do
not require this pseudo-header (ex. HTTP or FTP).  These applications
use other means for delimiting messages (read RFC959 sections 3.4.1 &
3.4.2 for how FTP delimit messages) and as you know have no PDU size
limitations (FTP can handle Megabyte file transfers).

This essentially restricts the maximum transport protocol data unit
(TPDU) size that can be transferred to TCP layer by Megaco application
to 65524 octets. TCP, based on the MTU and PMTUD, will segment and
re-assemble the TPDU (max. 65524 octets) at transmiting and recieving
end.
 
I was asking if we authors of H.248 Annex D can address this issue in
the standard itself. One way to do it is bump up the "version" field in
TPKT to 4 and use 4 octets to represent the TPDU size.
 
Thanks,
Sampath
 

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] 
Sent: Wednesday, January 14, 2004 10:25 AM
To: sampathk@cisco.com; 'MEGACO list'
Subject: RE: [Megaco] TPKT value for H.248 over TCP


I was under the impression that TCP segmented large packets
automatically.  Is that not the case?
 
Kevin



  _____  

From: Sampath Komanduri [mailto:sampathk@cisco.com] 
Sent: Tuesday, January 13, 2004 12:25 PM
To: 'MEGACO list'
Subject: RE: [Megaco] TPKT value for H.248 over TCP


Could the author of Annex D pls. respond?
 
Thanks,
Sampath

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Sampath Komanduri
Sent: Tuesday, January 06, 2004 8:16 PM
To: 'MEGACO list'
Subject: [Megaco] TPKT value for H.248 over TCP
Importance: High


Hi List,
I am not sure if this question was already raised in the list. If it
was, pls. point me to the discussion and the consensus.

According to ANNEX D of H.248.1 protocol, "TPKT, according to
<http://www.faqs.org/rfcs/rfc1006.html> RFC 1006, SHALL be used to
delineate messages within the TCP stream". RFC 1006 limits the size of
TPDU to 65524. Replicating the relevant text here for convenience:
 
***************************************************
     "A TPKT consists of two parts:  a packet-header and a TPDU.  
      The format of the header is constant regardless of the type of
packet.
      The format of the packet-header is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      vrsn     |    reserved   |          packet length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      where:

      vrsn                         8 bits

      This field is always 3 for the version of the protocol described
in this memo.

      packet length                16 bits (min=7, max=65535)

      This field contains the length of entire packet in octets,
including packet-header.
      This permits a maximum TPDU size of 65531 octets.
      Based on the size of the data transfer (DT) TPDU, this permits a
maximum 
      TSDU size of 65524 octets."
*********************************************************
 
This causes an issue. Based on the wildcard level of Audit and the
descriptors involved, this size could easily exceed 64K size (especially
if MG and MGC are using Long text format and white spaces in the
messages). In few cases, it is possible to return an error code (533:
Response exceeds maximum transport PDU size).
However, in some cases returning 533 is not an option. 
Consider for example the following scenario: After an association is
DISCONNECTED, MGC may want to get the list of non-null contexts on the
gateway using the following command (pls. ignore if there is any mistake
in the message and reply construct):
 
!/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}}
!/1 ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}}, ....and so
on}

In the best case (i.e. no white-space, no audit descriptor and short
format), this allows for an MG to have only 5000 active contexts on the
card. Anything more (or any variation in the audit command) will reduce
the number of active contexts that an MG can have even with TCP as the
transport option.
Responding with 533 is not an option here since that would leave MG-MGC
in state from where there is no elegant way out (at least from H.248
protocol).
 
How do the gurus' on list suggest we solve this issue? Couple of ideas
that come to mind are:

1.	Define a Bulk-Audit Package/scheme: As was done for MGCP, define
a Bulk-Audit package/scheme especially with support for       
    RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" and
    NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].
    This will certainly reduce the cases and scenarios when MG/MGC will
run into the issue under discussion but may not eliminate it. 

2.	Add more information on W- Audit support in the protocol. 

3.	Introduce RFC 1006 modification (with version field 4) such that
"packet length" of packet header in TPKT is 32 bits as opposed to 16
bits. 

4.	Combination of the above schemes. 

5.	Anything else?

Pls. advice on how this problem can be solved?

Thanks,
Sampath


------=_NextPart_000_000B_01C3DA8C.0A70FF40
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D752353318-14012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Kevin,</FONT></SPAN></DIV>
<DIV><SPAN class=3D752353318-14012004><FONT face=3DArial><FONT =
color=3D#0000ff=20
size=3D2>The issue is not with TCP itself. The problem stems from the =
basis that=20
MEGACO is an ISO application which is designed to run over the OSI stack =
(7=20
layer stack), not the TCP/IP stack (5 layer stack, no session or =
presentation=20
layers).&nbsp; In order to make ISO protocols/applications capable of =
running=20
over TCP,&nbsp;a "pseudo-header" (or TPKT) in RFC1006 was created.&nbsp; =
This=20
allowed support for the additional layers not found in the TCP/IP =
stack.&nbsp;=20
This pseudo-header is found in the application layer of the TCP/IP stack =
and has=20
no correlation to the functions preformed at the TCP layer.&nbsp; =
Applications=20
that were designed for the TCP/IP stack do not require this =
pseudo-header (ex.=20
HTTP or FTP).&nbsp; These applications use other means for delimiting =
messages=20
(read RFC959 sections 3.4.1 &amp; 3.4.2 for how FTP delimit messages) =
and as you=20
know have no PDU size limitations (FTP can handle Megabyte file=20
transfers).<BR><BR>This essentially restricts the maximum </FONT><FONT=20
color=3D#0000ff size=3D2>transport protocol data unit (TPDU) size that =
can be=20
transferred to TCP layer by Megaco application to 65524 octets. TCP, =
based on=20
the MTU and PMTUD, will segment and re-assemble the TPDU (<U>max. 65524=20
octets</U>) at transmiting and recieving end.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D752353318-14012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D752353318-14012004><FONT face=3DArial color=3D#0000ff =
size=3D2>I was=20
asking if we authors of H.248 Annex D can address this issue in the =
standard=20
itself. One way to do it is bump up the "version" field in TPKT to 4 and =
use 4=20
octets to represent the TPDU size.</FONT></SPAN></DIV>
<DIV><SPAN class=3D752353318-14012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D752353318-14012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D752353318-14012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Sampath</FONT></SPAN></DIV>
<DIV><SPAN class=3D752353318-14012004><FONT face=3DArial color=3D#0000ff =

size=3D2>&nbsp;</DIV></FONT></SPAN>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Kevin Boyle=20
  [mailto:kboyle@nortelnetworks.com] <BR><B>Sent:</B> Wednesday, January =
14,=20
  2004 10:25 AM<BR><B>To:</B> sampathk@cisco.com; 'MEGACO=20
  list'<BR><B>Subject:</B> RE: [Megaco] TPKT value for H.248 over=20
  TCP<BR><BR></FONT></DIV>
  <DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2><SPAN=20
  class=3D874522118-14012004>I was under the impression that TCP =
segmented large=20
  packets automatically.&nbsp; Is that not the case?</SPAN></FONT></DIV>
  <DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2><SPAN=20
  class=3D874522118-14012004></SPAN></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2><SPAN=20
  class=3D874522118-14012004>Kevin</SPAN></FONT></DIV><FONT face=3DArial =

  size=3D2></FONT><BR>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
    <HR tabIndex=3D-1>
    <FONT face=3DTahoma size=3D2><B>From:</B> Sampath Komanduri=20
    [mailto:sampathk@cisco.com] <BR><B>Sent:</B> Tuesday, January 13, =
2004 12:25=20
    PM<BR><B>To:</B> 'MEGACO list'<BR><B>Subject:</B> RE: [Megaco] TPKT =
value=20
    for H.248 over TCP<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
    class=3D673442317-13012004>Could the author of Annex D pls.=20
    respond?</SPAN></FONT></DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
    class=3D673442317-13012004></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
    class=3D673442317-13012004>Thanks,</SPAN></FONT></DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
    class=3D673442317-13012004>Sampath</SPAN></FONT></DIV>
    <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
      <DIV></DIV>
      <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
      face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
      megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] <B>On Behalf =
Of=20
      </B>Sampath Komanduri<BR><B>Sent:</B> Tuesday, January 06, 2004 =
8:16=20
      PM<BR><B>To:</B> 'MEGACO list'<BR><B>Subject:</B> [Megaco] TPKT =
value for=20
      H.248 over TCP<BR><B>Importance:</B> High<BR><BR></FONT></DIV><!-- =
Converted from text/plain format -->
      <DIV><FONT face=3DArial size=3D2>Hi List,<BR>I am not sure if this =
question=20
      was already raised in the list. If it was, pls. point me to the =
discussion=20
      and the consensus.<BR></FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>According to ANNEX D of H.248.1 =
protocol,=20
      "TPKT, according to </FONT><A=20
      href=3D"http://www.faqs.org/rfcs/rfc1006.html"><FONT face=3DArial =
size=3D2>RFC=20
      1006</FONT></A><FONT face=3DArial size=3D2>, SHALL be used to =
delineate=20
      messages within the TCP stream".&nbsp;RFC 1006&nbsp;limits the =
size=20
      of&nbsp;TPDU to 65524. Replicating the relevant text here for=20
      convenience:</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
      <DIV><FONT face=3DArial=20
      =
size=3D2>***************************************************</FONT></DIV>=

      <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; "A TPKT =
consists of=20
      two parts:&nbsp; a packet-header and a TPDU.&nbsp; </FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The format of=20
      the header is constant regardless of the type of=20
      packet.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The format of the =
packet-header=20
      is as follows:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      3<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0 1 2 3 4 5 6 7 8 =
9 0 1 2=20
      3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0=20
      1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; vrsn&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp;&nbsp; reserved&nbsp;&nbsp;=20
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet=20
      length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR><BR>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      where:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
vrsn&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
      8 bits<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This field is always =
3 for=20
      the version of the protocol described in this=20
      memo.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet=20
      =
length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
      16 bits (min=3D7, =
max=3D65535)<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This=20
      field contains the length of entire packet in octets, including=20
      packet-header.</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp; This =
permits a=20
      maximum TPDU size of 65531 octets.</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp; Based =
on the size=20
      of the data transfer (DT) TPDU, this permits a maximum =
</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
T</FONT><FONT=20
      face=3DArial size=3D2>SDU size of 65524=20
      =
octets."<BR>*********************************************************<BR>=
&nbsp;</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>This causes an issue. Based on=20
      the&nbsp;wildcard level&nbsp;of Audit and the descriptors =
involved, this=20
      size could easily exceed 64K size (especially if MG and MGC are =
using Long=20
      text format and white spaces in the messages). In few cases, it is =

      possible to&nbsp;return an&nbsp;error code (533: Response exceeds =
maximum=20
      transport PDU size).</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>However, in some cases returning =
533 is not=20
      an option. </FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>Consider for example the =
following scenario:=20
      After an association is DISCONNECTED, MGC may want to get =
the&nbsp;list of=20
      non-null contexts on the gateway using the following command (pls. =
ignore=20
      if there is any mistake in the message and reply =
construct):</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
      <DIV><FONT size=3D2><FONT face=3DArial>!/1 [10.102.2.201]:4000=20
      T=3D3700003{C=3D*{AV=3DROOT{AT{}}}}<BR></FONT><FONT =
face=3DArial>!/1=20
      ABCD_MG&nbsp;P=3D3700003{C=3D</FONT></FONT><FONT face=3DArial=20
      size=3D2>1{AV=3DC{*}},C=3D2<FONT =
face=3DArial>{AV=3DC{*}},C=3D3<FONT=20
      face=3DArial>{AV=3DC{*}},&nbsp;....and so =
on}</FONT></FONT><BR></FONT><FONT=20
      face=3DArial></FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>In the best case (i.e. no =
white-space, no=20
      audit descriptor&nbsp;and short format), this allows for an MG to =
have=20
      only 5000 active contexts on the card. Anything more (or any =
variation in=20
      the audit command) will reduce the number of active contexts that =
an MG=20
      can have even with TCP as the transport option.</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>Responding with 533 is not an =
option here=20
      since that would leave MG-MGC in state from where there is no =
elegant way=20
      out (at least from H.248 protocol).</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
      <DIV><FONT face=3DArial size=3D2>How do the gurus' on list suggest =
we solve=20
      this issue? Couple of ideas that come to mind are:</FONT></DIV>
      <OL>
        <LI><FONT face=3DArial><FONT size=3D2>Define a Bulk-Audit =
Package/scheme: As=20
        was done for MGCP, define a Bulk-Audit package/scheme especially =
with=20
        support=20
        =
for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp;=20
        RangeWildcard =3D "[" NumericalRange *( "," NumericalRange ) "]" =

        and<BR>&nbsp;&nbsp;&nbsp; NumericalRange&nbsp;&nbsp;&nbsp;&nbsp; =
=3D=20
        1*(DIGIT) [ "-" 1*(DIGIT) ].<BR>&nbsp;&nbsp;&nbsp; This will =
certainly=20
        reduce the cases and scenarios when MG/MGC will run into the =
issue under=20
        discussion but may not eliminate it.</FONT></FONT>=20
        <LI><FONT face=3DArial size=3D2>Add more information on W- Audit =
support in=20
        the protocol.</FONT>=20
        <LI><FONT face=3DArial><FONT size=3D2>Introduce RFC 1006 =
modification (with=20
        version field 4) such that "packet length" of packet header in =
TPKT is=20
        32 bits as opposed to 16 bits.</FONT></FONT>=20
        <LI><FONT face=3DArial><FONT size=3D2>Combination of the above=20
        schemes.</FONT></FONT>=20
        <LI><FONT face=3DArial size=3D2>Anything else?</FONT></LI></OL>
      <DIV><FONT face=3DArial size=3D2>Pls. advice on how this problem =
can be=20
      solved?</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
      face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT face=3DArial=20
      size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT =
face=3DArial=20
      size=3D2></FONT><FONT face=3DArial size=3D2></FONT><BR><FONT =
face=3DArial><FONT=20
      =
size=3D2>Thanks,<BR>Sampath</FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCK=
QUOTE></FONT></BODY></HTML>

------=_NextPart_000_000B_01C3DA8C.0A70FF40--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan 14 13:53:28 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02892
	for <megaco-archive@odin.ietf.org>; Wed, 14 Jan 2004 13:53:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agq8S-0000Nx-Iq
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 13:53:00 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EIr0MC001475
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 13:53:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agq8S-0000Ni-Dg
	for megaco-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 13:53:00 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02883
	for <megaco-web-archive@ietf.org>; Wed, 14 Jan 2004 13:52:57 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agq8P-0002Fj-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 13:52:58 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Agq7P-0002D8-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 13:51:57 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agq6W-0002Bk-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 13:51:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agq6X-0000EX-VC; Wed, 14 Jan 2004 13:51:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agq6S-0000Dl-I7
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 13:50:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02742
	for <megaco@ietf.org>; Wed, 14 Jan 2004 13:50:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agq6Q-0002Am-00
	for megaco@ietf.org; Wed, 14 Jan 2004 13:50:54 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Agq5U-00029V-00
	for megaco@ietf.org; Wed, 14 Jan 2004 13:49:58 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agq5H-00027z-00
	for megaco@ietf.org; Wed, 14 Jan 2004 13:49:43 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 14 Jan 2004 10:51:19 +0000
Received: from SAMPATHKW2K03 (dhcp-171-71-9-200.cisco.com [171.71.9.200])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0EIn9VM006920;
	Wed, 14 Jan 2004 10:49:10 -0800 (PST)
Reply-To: <sampathk@cisco.com>
From: "Sampath Komanduri" <sampathk@cisco.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'MEGACO list'" <megaco@ietf.org>
Subject: RE: [Megaco] TPKT value for H.248 over TCP
Date: Wed, 14 Jan 2004 10:49:09 -0800
Organization: Cisco Systems
Message-ID: <000a01c3dacf$1892b8a0$c80947ab@SAMPATHKW2K03>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000B_01C3DA8C.0A70FF40"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0DCB7F45@zrtpd0jq.us.nortel.com>
Importance: Normal
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C3DA8C.0A70FF40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Kevin,
The issue is not with TCP itself. The problem stems from the basis that
MEGACO is an ISO application which is designed to run over the OSI stack
(7 layer stack), not the TCP/IP stack (5 layer stack, no session or
presentation layers).  In order to make ISO protocols/applications
capable of running over TCP, a "pseudo-header" (or TPKT) in RFC1006 was
created.  This allowed support for the additional layers not found in
the TCP/IP stack.  This pseudo-header is found in the application layer
of the TCP/IP stack and has no correlation to the functions preformed at
the TCP layer.  Applications that were designed for the TCP/IP stack do
not require this pseudo-header (ex. HTTP or FTP).  These applications
use other means for delimiting messages (read RFC959 sections 3.4.1 &
3.4.2 for how FTP delimit messages) and as you know have no PDU size
limitations (FTP can handle Megabyte file transfers).

This essentially restricts the maximum transport protocol data unit
(TPDU) size that can be transferred to TCP layer by Megaco application
to 65524 octets. TCP, based on the MTU and PMTUD, will segment and
re-assemble the TPDU (max. 65524 octets) at transmiting and recieving
end.
 
I was asking if we authors of H.248 Annex D can address this issue in
the standard itself. One way to do it is bump up the "version" field in
TPKT to 4 and use 4 octets to represent the TPDU size.
 
Thanks,
Sampath
 

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] 
Sent: Wednesday, January 14, 2004 10:25 AM
To: sampathk@cisco.com; 'MEGACO list'
Subject: RE: [Megaco] TPKT value for H.248 over TCP


I was under the impression that TCP segmented large packets
automatically.  Is that not the case?
 
Kevin



  _____  

From: Sampath Komanduri [mailto:sampathk@cisco.com] 
Sent: Tuesday, January 13, 2004 12:25 PM
To: 'MEGACO list'
Subject: RE: [Megaco] TPKT value for H.248 over TCP


Could the author of Annex D pls. respond?
 
Thanks,
Sampath

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Sampath Komanduri
Sent: Tuesday, January 06, 2004 8:16 PM
To: 'MEGACO list'
Subject: [Megaco] TPKT value for H.248 over TCP
Importance: High


Hi List,
I am not sure if this question was already raised in the list. If it
was, pls. point me to the discussion and the consensus.

According to ANNEX D of H.248.1 protocol, "TPKT, according to
<http://www.faqs.org/rfcs/rfc1006.html> RFC 1006, SHALL be used to
delineate messages within the TCP stream". RFC 1006 limits the size of
TPDU to 65524. Replicating the relevant text here for convenience:
 
***************************************************
     "A TPKT consists of two parts:  a packet-header and a TPDU.  
      The format of the header is constant regardless of the type of
packet.
      The format of the packet-header is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      vrsn     |    reserved   |          packet length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      where:

      vrsn                         8 bits

      This field is always 3 for the version of the protocol described
in this memo.

      packet length                16 bits (min=7, max=65535)

      This field contains the length of entire packet in octets,
including packet-header.
      This permits a maximum TPDU size of 65531 octets.
      Based on the size of the data transfer (DT) TPDU, this permits a
maximum 
      TSDU size of 65524 octets."
*********************************************************
 
This causes an issue. Based on the wildcard level of Audit and the
descriptors involved, this size could easily exceed 64K size (especially
if MG and MGC are using Long text format and white spaces in the
messages). In few cases, it is possible to return an error code (533:
Response exceeds maximum transport PDU size).
However, in some cases returning 533 is not an option. 
Consider for example the following scenario: After an association is
DISCONNECTED, MGC may want to get the list of non-null contexts on the
gateway using the following command (pls. ignore if there is any mistake
in the message and reply construct):
 
!/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}}
!/1 ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}}, ....and so
on}

In the best case (i.e. no white-space, no audit descriptor and short
format), this allows for an MG to have only 5000 active contexts on the
card. Anything more (or any variation in the audit command) will reduce
the number of active contexts that an MG can have even with TCP as the
transport option.
Responding with 533 is not an option here since that would leave MG-MGC
in state from where there is no elegant way out (at least from H.248
protocol).
 
How do the gurus' on list suggest we solve this issue? Couple of ideas
that come to mind are:

1.	Define a Bulk-Audit Package/scheme: As was done for MGCP, define
a Bulk-Audit package/scheme especially with support for       
    RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" and
    NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].
    This will certainly reduce the cases and scenarios when MG/MGC will
run into the issue under discussion but may not eliminate it. 

2.	Add more information on W- Audit support in the protocol. 

3.	Introduce RFC 1006 modification (with version field 4) such that
"packet length" of packet header in TPKT is 32 bits as opposed to 16
bits. 

4.	Combination of the above schemes. 

5.	Anything else?

Pls. advice on how this problem can be solved?

Thanks,
Sampath


------=_NextPart_000_000B_01C3DA8C.0A70FF40
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D752353318-14012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Kevin,</FONT></SPAN></DIV>
<DIV><SPAN class=3D752353318-14012004><FONT face=3DArial><FONT =
color=3D#0000ff=20
size=3D2>The issue is not with TCP itself. The problem stems from the =
basis that=20
MEGACO is an ISO application which is designed to run over the OSI stack =
(7=20
layer stack), not the TCP/IP stack (5 layer stack, no session or =
presentation=20
layers).&nbsp; In order to make ISO protocols/applications capable of =
running=20
over TCP,&nbsp;a "pseudo-header" (or TPKT) in RFC1006 was created.&nbsp; =
This=20
allowed support for the additional layers not found in the TCP/IP =
stack.&nbsp;=20
This pseudo-header is found in the application layer of the TCP/IP stack =
and has=20
no correlation to the functions preformed at the TCP layer.&nbsp; =
Applications=20
that were designed for the TCP/IP stack do not require this =
pseudo-header (ex.=20
HTTP or FTP).&nbsp; These applications use other means for delimiting =
messages=20
(read RFC959 sections 3.4.1 &amp; 3.4.2 for how FTP delimit messages) =
and as you=20
know have no PDU size limitations (FTP can handle Megabyte file=20
transfers).<BR><BR>This essentially restricts the maximum </FONT><FONT=20
color=3D#0000ff size=3D2>transport protocol data unit (TPDU) size that =
can be=20
transferred to TCP layer by Megaco application to 65524 octets. TCP, =
based on=20
the MTU and PMTUD, will segment and re-assemble the TPDU (<U>max. 65524=20
octets</U>) at transmiting and recieving end.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D752353318-14012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D752353318-14012004><FONT face=3DArial color=3D#0000ff =
size=3D2>I was=20
asking if we authors of H.248 Annex D can address this issue in the =
standard=20
itself. One way to do it is bump up the "version" field in TPKT to 4 and =
use 4=20
octets to represent the TPDU size.</FONT></SPAN></DIV>
<DIV><SPAN class=3D752353318-14012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D752353318-14012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D752353318-14012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Sampath</FONT></SPAN></DIV>
<DIV><SPAN class=3D752353318-14012004><FONT face=3DArial color=3D#0000ff =

size=3D2>&nbsp;</DIV></FONT></SPAN>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Kevin Boyle=20
  [mailto:kboyle@nortelnetworks.com] <BR><B>Sent:</B> Wednesday, January =
14,=20
  2004 10:25 AM<BR><B>To:</B> sampathk@cisco.com; 'MEGACO=20
  list'<BR><B>Subject:</B> RE: [Megaco] TPKT value for H.248 over=20
  TCP<BR><BR></FONT></DIV>
  <DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2><SPAN=20
  class=3D874522118-14012004>I was under the impression that TCP =
segmented large=20
  packets automatically.&nbsp; Is that not the case?</SPAN></FONT></DIV>
  <DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2><SPAN=20
  class=3D874522118-14012004></SPAN></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2><SPAN=20
  class=3D874522118-14012004>Kevin</SPAN></FONT></DIV><FONT face=3DArial =

  size=3D2></FONT><BR>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
    <HR tabIndex=3D-1>
    <FONT face=3DTahoma size=3D2><B>From:</B> Sampath Komanduri=20
    [mailto:sampathk@cisco.com] <BR><B>Sent:</B> Tuesday, January 13, =
2004 12:25=20
    PM<BR><B>To:</B> 'MEGACO list'<BR><B>Subject:</B> RE: [Megaco] TPKT =
value=20
    for H.248 over TCP<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
    class=3D673442317-13012004>Could the author of Annex D pls.=20
    respond?</SPAN></FONT></DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
    class=3D673442317-13012004></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
    class=3D673442317-13012004>Thanks,</SPAN></FONT></DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
    class=3D673442317-13012004>Sampath</SPAN></FONT></DIV>
    <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
      <DIV></DIV>
      <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
      face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
      megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] <B>On Behalf =
Of=20
      </B>Sampath Komanduri<BR><B>Sent:</B> Tuesday, January 06, 2004 =
8:16=20
      PM<BR><B>To:</B> 'MEGACO list'<BR><B>Subject:</B> [Megaco] TPKT =
value for=20
      H.248 over TCP<BR><B>Importance:</B> High<BR><BR></FONT></DIV><!-- =
Converted from text/plain format -->
      <DIV><FONT face=3DArial size=3D2>Hi List,<BR>I am not sure if this =
question=20
      was already raised in the list. If it was, pls. point me to the =
discussion=20
      and the consensus.<BR></FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>According to ANNEX D of H.248.1 =
protocol,=20
      "TPKT, according to </FONT><A=20
      href=3D"http://www.faqs.org/rfcs/rfc1006.html"><FONT face=3DArial =
size=3D2>RFC=20
      1006</FONT></A><FONT face=3DArial size=3D2>, SHALL be used to =
delineate=20
      messages within the TCP stream".&nbsp;RFC 1006&nbsp;limits the =
size=20
      of&nbsp;TPDU to 65524. Replicating the relevant text here for=20
      convenience:</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
      <DIV><FONT face=3DArial=20
      =
size=3D2>***************************************************</FONT></DIV>=

      <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; "A TPKT =
consists of=20
      two parts:&nbsp; a packet-header and a TPDU.&nbsp; </FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The format of=20
      the header is constant regardless of the type of=20
      packet.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The format of the =
packet-header=20
      is as follows:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      3<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0 1 2 3 4 5 6 7 8 =
9 0 1 2=20
      3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0=20
      1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; vrsn&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp;&nbsp; reserved&nbsp;&nbsp;=20
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet=20
      length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR><BR>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      where:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
vrsn&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
      8 bits<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This field is always =
3 for=20
      the version of the protocol described in this=20
      memo.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet=20
      =
length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
      16 bits (min=3D7, =
max=3D65535)<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This=20
      field contains the length of entire packet in octets, including=20
      packet-header.</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp; This =
permits a=20
      maximum TPDU size of 65531 octets.</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp; Based =
on the size=20
      of the data transfer (DT) TPDU, this permits a maximum =
</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
T</FONT><FONT=20
      face=3DArial size=3D2>SDU size of 65524=20
      =
octets."<BR>*********************************************************<BR>=
&nbsp;</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>This causes an issue. Based on=20
      the&nbsp;wildcard level&nbsp;of Audit and the descriptors =
involved, this=20
      size could easily exceed 64K size (especially if MG and MGC are =
using Long=20
      text format and white spaces in the messages). In few cases, it is =

      possible to&nbsp;return an&nbsp;error code (533: Response exceeds =
maximum=20
      transport PDU size).</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>However, in some cases returning =
533 is not=20
      an option. </FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>Consider for example the =
following scenario:=20
      After an association is DISCONNECTED, MGC may want to get =
the&nbsp;list of=20
      non-null contexts on the gateway using the following command (pls. =
ignore=20
      if there is any mistake in the message and reply =
construct):</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
      <DIV><FONT size=3D2><FONT face=3DArial>!/1 [10.102.2.201]:4000=20
      T=3D3700003{C=3D*{AV=3DROOT{AT{}}}}<BR></FONT><FONT =
face=3DArial>!/1=20
      ABCD_MG&nbsp;P=3D3700003{C=3D</FONT></FONT><FONT face=3DArial=20
      size=3D2>1{AV=3DC{*}},C=3D2<FONT =
face=3DArial>{AV=3DC{*}},C=3D3<FONT=20
      face=3DArial>{AV=3DC{*}},&nbsp;....and so =
on}</FONT></FONT><BR></FONT><FONT=20
      face=3DArial></FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>In the best case (i.e. no =
white-space, no=20
      audit descriptor&nbsp;and short format), this allows for an MG to =
have=20
      only 5000 active contexts on the card. Anything more (or any =
variation in=20
      the audit command) will reduce the number of active contexts that =
an MG=20
      can have even with TCP as the transport option.</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>Responding with 533 is not an =
option here=20
      since that would leave MG-MGC in state from where there is no =
elegant way=20
      out (at least from H.248 protocol).</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
      <DIV><FONT face=3DArial size=3D2>How do the gurus' on list suggest =
we solve=20
      this issue? Couple of ideas that come to mind are:</FONT></DIV>
      <OL>
        <LI><FONT face=3DArial><FONT size=3D2>Define a Bulk-Audit =
Package/scheme: As=20
        was done for MGCP, define a Bulk-Audit package/scheme especially =
with=20
        support=20
        =
for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp;=20
        RangeWildcard =3D "[" NumericalRange *( "," NumericalRange ) "]" =

        and<BR>&nbsp;&nbsp;&nbsp; NumericalRange&nbsp;&nbsp;&nbsp;&nbsp; =
=3D=20
        1*(DIGIT) [ "-" 1*(DIGIT) ].<BR>&nbsp;&nbsp;&nbsp; This will =
certainly=20
        reduce the cases and scenarios when MG/MGC will run into the =
issue under=20
        discussion but may not eliminate it.</FONT></FONT>=20
        <LI><FONT face=3DArial size=3D2>Add more information on W- Audit =
support in=20
        the protocol.</FONT>=20
        <LI><FONT face=3DArial><FONT size=3D2>Introduce RFC 1006 =
modification (with=20
        version field 4) such that "packet length" of packet header in =
TPKT is=20
        32 bits as opposed to 16 bits.</FONT></FONT>=20
        <LI><FONT face=3DArial><FONT size=3D2>Combination of the above=20
        schemes.</FONT></FONT>=20
        <LI><FONT face=3DArial size=3D2>Anything else?</FONT></LI></OL>
      <DIV><FONT face=3DArial size=3D2>Pls. advice on how this problem =
can be=20
      solved?</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
      face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT face=3DArial=20
      size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT =
face=3DArial=20
      size=3D2></FONT><FONT face=3DArial size=3D2></FONT><BR><FONT =
face=3DArial><FONT=20
      =
size=3D2>Thanks,<BR>Sampath</FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCK=
QUOTE></FONT></BODY></HTML>

------=_NextPart_000_000B_01C3DA8C.0A70FF40--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan 14 14:37:31 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05430
	for <megaco-archive@lists.ietf.org>; Wed, 14 Jan 2004 14:37:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agqp4-0002gw-Af; Wed, 14 Jan 2004 14:37:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgqoL-0002fj-Re
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 14:36:17 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05187
	for <megaco@ietf.org>; Wed, 14 Jan 2004 14:36:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgqoJ-0004KK-00
	for megaco@ietf.org; Wed, 14 Jan 2004 14:36:15 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgqnS-0004Df-00
	for megaco@ietf.org; Wed, 14 Jan 2004 14:35:23 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgqmN-00045B-00
	for megaco@ietf.org; Wed, 14 Jan 2004 14:34:15 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0EJXe626597
	for <megaco@ietf.org>; Wed, 14 Jan 2004 14:33:41 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2YF1Z1A>; Wed, 14 Jan 2004 14:33:41 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0DD0691B@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: sampathk@cisco.com, "'MEGACO list'" <megaco@ietf.org>
Subject: RE: [Megaco] TPKT value for H.248 over TCP
Date: Wed, 14 Jan 2004 14:33:32 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

I have proposed a method whereby responders can break their very long
response into several smaller complete messages for Version 3 (it will
require a syntax change).  This means that the Megaco application can do its
own segmentation.  Such a mechanism should resolve your problem, regardless
of the transport.  This addition will be discussed at the ITU meeting
January 20-30.
 
Kevin


  _____  

From: Sampath Komanduri [mailto:sampathk@cisco.com] 
Sent: Wednesday, January 14, 2004 1:49 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; 'MEGACO list'
Subject: RE: [Megaco] TPKT value for H.248 over TCP


Kevin,
The issue is not with TCP itself. The problem stems from the basis that
MEGACO is an ISO application which is designed to run over the OSI stack (7
layer stack), not the TCP/IP stack (5 layer stack, no session or
presentation layers).  In order to make ISO protocols/applications capable
of running over TCP, a "pseudo-header" (or TPKT) in RFC1006 was created.
This allowed support for the additional layers not found in the TCP/IP
stack.  This pseudo-header is found in the application layer of the TCP/IP
stack and has no correlation to the functions preformed at the TCP layer.
Applications that were designed for the TCP/IP stack do not require this
pseudo-header (ex. HTTP or FTP).  These applications use other means for
delimiting messages (read RFC959 sections 3.4.1 & 3.4.2 for how FTP delimit
messages) and as you know have no PDU size limitations (FTP can handle
Megabyte file transfers).

This essentially restricts the maximum transport protocol data unit (TPDU)
size that can be transferred to TCP layer by Megaco application to 65524
octets. TCP, based on the MTU and PMTUD, will segment and re-assemble the
TPDU (max. 65524 octets) at transmiting and recieving end.
 
I was asking if we authors of H.248 Annex D can address this issue in the
standard itself. One way to do it is bump up the "version" field in TPKT to
4 and use 4 octets to represent the TPDU size.
 
Thanks,
Sampath
 

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] 
Sent: Wednesday, January 14, 2004 10:25 AM
To: sampathk@cisco.com; 'MEGACO list'
Subject: RE: [Megaco] TPKT value for H.248 over TCP


I was under the impression that TCP segmented large packets automatically.
Is that not the case?
 
Kevin



  _____  

From: Sampath Komanduri [mailto:sampathk@cisco.com] 
Sent: Tuesday, January 13, 2004 12:25 PM
To: 'MEGACO list'
Subject: RE: [Megaco] TPKT value for H.248 over TCP


Could the author of Annex D pls. respond?
 
Thanks,
Sampath

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Sampath Komanduri
Sent: Tuesday, January 06, 2004 8:16 PM
To: 'MEGACO list'
Subject: [Megaco] TPKT value for H.248 over TCP
Importance: High


Hi List,
I am not sure if this question was already raised in the list. If it was,
pls. point me to the discussion and the consensus.

According to ANNEX D of H.248.1 protocol, "TPKT, according to
<http://www.faqs.org/rfcs/rfc1006.html> RFC 1006, SHALL be used to delineate
messages within the TCP stream". RFC 1006 limits the size of TPDU to 65524.
Replicating the relevant text here for convenience:
 
***************************************************
     "A TPKT consists of two parts:  a packet-header and a TPDU.  
      The format of the header is constant regardless of the type of packet.
      The format of the packet-header is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      vrsn     |    reserved   |          packet length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      where:

      vrsn                         8 bits

      This field is always 3 for the version of the protocol described in
this memo.

      packet length                16 bits (min=7, max=65535)

      This field contains the length of entire packet in octets, including
packet-header.
      This permits a maximum TPDU size of 65531 octets.
      Based on the size of the data transfer (DT) TPDU, this permits a
maximum 
      TSDU size of 65524 octets."
*********************************************************
 
This causes an issue. Based on the wildcard level of Audit and the
descriptors involved, this size could easily exceed 64K size (especially if
MG and MGC are using Long text format and white spaces in the messages). In
few cases, it is possible to return an error code (533: Response exceeds
maximum transport PDU size).
However, in some cases returning 533 is not an option. 
Consider for example the following scenario: After an association is
DISCONNECTED, MGC may want to get the list of non-null contexts on the
gateway using the following command (pls. ignore if there is any mistake in
the message and reply construct):
 
!/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}}
!/1 ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}}, ....and so on}

In the best case (i.e. no white-space, no audit descriptor and short
format), this allows for an MG to have only 5000 active contexts on the
card. Anything more (or any variation in the audit command) will reduce the
number of active contexts that an MG can have even with TCP as the transport
option.
Responding with 533 is not an option here since that would leave MG-MGC in
state from where there is no elegant way out (at least from H.248 protocol).
 
How do the gurus' on list suggest we solve this issue? Couple of ideas that
come to mind are:

1.	Define a Bulk-Audit Package/scheme: As was done for MGCP, define a
Bulk-Audit package/scheme especially with support for       
    RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" and
    NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].
    This will certainly reduce the cases and scenarios when MG/MGC will run
into the issue under discussion but may not eliminate it. 

2.	Add more information on W- Audit support in the protocol. 

3.	Introduce RFC 1006 modification (with version field 4) such that
"packet length" of packet header in TPKT is 32 bits as opposed to 16 bits. 

4.	Combination of the above schemes. 

5.	Anything else?

Pls. advice on how this problem can be solved?

Thanks,
Sampath


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan 14 14:40:35 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05701
	for <megaco-archive@odin.ietf.org>; Wed, 14 Jan 2004 14:40:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agqqt-0003D0-33
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 14:38:55 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EJctTj012328
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 14:38:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agqqr-0003Cb-Iv
	for megaco-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 14:38:53 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05497
	for <megaco-web-archive@ietf.org>; Wed, 14 Jan 2004 14:38:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agqqo-0004Vq-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 14:38:50 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Agqps-0004S7-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 14:37:53 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agqp3-0004On-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 14:37:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agqp4-0002gw-Af; Wed, 14 Jan 2004 14:37:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgqoL-0002fj-Re
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 14:36:17 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05187
	for <megaco@ietf.org>; Wed, 14 Jan 2004 14:36:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgqoJ-0004KK-00
	for megaco@ietf.org; Wed, 14 Jan 2004 14:36:15 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgqnS-0004Df-00
	for megaco@ietf.org; Wed, 14 Jan 2004 14:35:23 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgqmN-00045B-00
	for megaco@ietf.org; Wed, 14 Jan 2004 14:34:15 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0EJXe626597
	for <megaco@ietf.org>; Wed, 14 Jan 2004 14:33:41 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2YF1Z1A>; Wed, 14 Jan 2004 14:33:41 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0DD0691B@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: sampathk@cisco.com, "'MEGACO list'" <megaco@ietf.org>
Subject: RE: [Megaco] TPKT value for H.248 over TCP
Date: Wed, 14 Jan 2004 14:33:32 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60

I have proposed a method whereby responders can break their very long
response into several smaller complete messages for Version 3 (it will
require a syntax change).  This means that the Megaco application can do its
own segmentation.  Such a mechanism should resolve your problem, regardless
of the transport.  This addition will be discussed at the ITU meeting
January 20-30.
 
Kevin


  _____  

From: Sampath Komanduri [mailto:sampathk@cisco.com] 
Sent: Wednesday, January 14, 2004 1:49 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; 'MEGACO list'
Subject: RE: [Megaco] TPKT value for H.248 over TCP


Kevin,
The issue is not with TCP itself. The problem stems from the basis that
MEGACO is an ISO application which is designed to run over the OSI stack (7
layer stack), not the TCP/IP stack (5 layer stack, no session or
presentation layers).  In order to make ISO protocols/applications capable
of running over TCP, a "pseudo-header" (or TPKT) in RFC1006 was created.
This allowed support for the additional layers not found in the TCP/IP
stack.  This pseudo-header is found in the application layer of the TCP/IP
stack and has no correlation to the functions preformed at the TCP layer.
Applications that were designed for the TCP/IP stack do not require this
pseudo-header (ex. HTTP or FTP).  These applications use other means for
delimiting messages (read RFC959 sections 3.4.1 & 3.4.2 for how FTP delimit
messages) and as you know have no PDU size limitations (FTP can handle
Megabyte file transfers).

This essentially restricts the maximum transport protocol data unit (TPDU)
size that can be transferred to TCP layer by Megaco application to 65524
octets. TCP, based on the MTU and PMTUD, will segment and re-assemble the
TPDU (max. 65524 octets) at transmiting and recieving end.
 
I was asking if we authors of H.248 Annex D can address this issue in the
standard itself. One way to do it is bump up the "version" field in TPKT to
4 and use 4 octets to represent the TPDU size.
 
Thanks,
Sampath
 

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] 
Sent: Wednesday, January 14, 2004 10:25 AM
To: sampathk@cisco.com; 'MEGACO list'
Subject: RE: [Megaco] TPKT value for H.248 over TCP


I was under the impression that TCP segmented large packets automatically.
Is that not the case?
 
Kevin



  _____  

From: Sampath Komanduri [mailto:sampathk@cisco.com] 
Sent: Tuesday, January 13, 2004 12:25 PM
To: 'MEGACO list'
Subject: RE: [Megaco] TPKT value for H.248 over TCP


Could the author of Annex D pls. respond?
 
Thanks,
Sampath

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Sampath Komanduri
Sent: Tuesday, January 06, 2004 8:16 PM
To: 'MEGACO list'
Subject: [Megaco] TPKT value for H.248 over TCP
Importance: High


Hi List,
I am not sure if this question was already raised in the list. If it was,
pls. point me to the discussion and the consensus.

According to ANNEX D of H.248.1 protocol, "TPKT, according to
<http://www.faqs.org/rfcs/rfc1006.html> RFC 1006, SHALL be used to delineate
messages within the TCP stream". RFC 1006 limits the size of TPDU to 65524.
Replicating the relevant text here for convenience:
 
***************************************************
     "A TPKT consists of two parts:  a packet-header and a TPDU.  
      The format of the header is constant regardless of the type of packet.
      The format of the packet-header is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      vrsn     |    reserved   |          packet length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      where:

      vrsn                         8 bits

      This field is always 3 for the version of the protocol described in
this memo.

      packet length                16 bits (min=7, max=65535)

      This field contains the length of entire packet in octets, including
packet-header.
      This permits a maximum TPDU size of 65531 octets.
      Based on the size of the data transfer (DT) TPDU, this permits a
maximum 
      TSDU size of 65524 octets."
*********************************************************
 
This causes an issue. Based on the wildcard level of Audit and the
descriptors involved, this size could easily exceed 64K size (especially if
MG and MGC are using Long text format and white spaces in the messages). In
few cases, it is possible to return an error code (533: Response exceeds
maximum transport PDU size).
However, in some cases returning 533 is not an option. 
Consider for example the following scenario: After an association is
DISCONNECTED, MGC may want to get the list of non-null contexts on the
gateway using the following command (pls. ignore if there is any mistake in
the message and reply construct):
 
!/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}}
!/1 ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}}, ....and so on}

In the best case (i.e. no white-space, no audit descriptor and short
format), this allows for an MG to have only 5000 active contexts on the
card. Anything more (or any variation in the audit command) will reduce the
number of active contexts that an MG can have even with TCP as the transport
option.
Responding with 533 is not an option here since that would leave MG-MGC in
state from where there is no elegant way out (at least from H.248 protocol).
 
How do the gurus' on list suggest we solve this issue? Couple of ideas that
come to mind are:

1.	Define a Bulk-Audit Package/scheme: As was done for MGCP, define a
Bulk-Audit package/scheme especially with support for       
    RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" and
    NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].
    This will certainly reduce the cases and scenarios when MG/MGC will run
into the issue under discussion but may not eliminate it. 

2.	Add more information on W- Audit support in the protocol. 

3.	Introduce RFC 1006 modification (with version field 4) such that
"packet length" of packet header in TPKT is 32 bits as opposed to 16 bits. 

4.	Combination of the above schemes. 

5.	Anything else?

Pls. advice on how this problem can be solved?

Thanks,
Sampath


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan 14 15:13:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08328
	for <megaco-archive@lists.ietf.org>; Wed, 14 Jan 2004 15:13:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgrNs-00050B-3k; Wed, 14 Jan 2004 15:13:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgrNp-0004xH-DW
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 15:12:57 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08261
	for <megaco@ietf.org>; Wed, 14 Jan 2004 15:12:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgrNo-0006XT-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:12:56 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgrMs-0006Vl-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:11:58 -0500
Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgrM8-0006SK-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:11:12 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0EKADC02983
	for <megaco@ietf.org>; Wed, 14 Jan 2004 14:10:19 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA08464; Wed, 14 Jan 2004 15:10:11 -0500 (EST)
Cc: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'MEGACO list'" <megaco@ietf.org>
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA08450; Wed, 14 Jan 2004 15:10:10 -0500 (EST)
Message-ID: <4005A29B.7010809@bell-labs.com>
Date: Wed, 14 Jan 2004 15:12:11 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sampathk@cisco.com
Original-CC: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'MEGACO list'" <megaco@ietf.org>
Subject: Re: [Megaco] TPKT value for H.248 over TCP
References: <000a01c3dacf$1892b8a0$c80947ab@SAMPATHKW2K03>
In-Reply-To: <000a01c3dacf$1892b8a0$c80947ab@SAMPATHKW2K03>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Sampath Komanduri wrote:

> I was asking if we authors of H.248 Annex D can address this issue in 
> the standard itself. One way to do it is bump up the "version" field in 
> TPKT to 4 and use 4 octets to represent the TPDU size.
>  
> Thanks,
> Sampath

Using 4 octets has a limit as well.
Better avoid that too.

-troy


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan 14 15:15:26 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08551
	for <megaco-archive@odin.ietf.org>; Wed, 14 Jan 2004 15:15:25 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgrPk-0005Lu-PD
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 15:14:57 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EKEu23020568
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 15:14:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgrPk-0005Lf-Ln
	for megaco-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 15:14:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08485
	for <megaco-web-archive@ietf.org>; Wed, 14 Jan 2004 15:14:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgrPj-0006eJ-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 15:14:55 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgrOm-0006a9-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 15:13:56 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgrNt-0006YH-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 15:13:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgrNs-00050B-3k; Wed, 14 Jan 2004 15:13:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgrNp-0004xH-DW
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 15:12:57 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08261
	for <megaco@ietf.org>; Wed, 14 Jan 2004 15:12:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgrNo-0006XT-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:12:56 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgrMs-0006Vl-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:11:58 -0500
Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgrM8-0006SK-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:11:12 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0EKADC02983
	for <megaco@ietf.org>; Wed, 14 Jan 2004 14:10:19 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA08464; Wed, 14 Jan 2004 15:10:11 -0500 (EST)
Cc: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'MEGACO list'" <megaco@ietf.org>
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA08450; Wed, 14 Jan 2004 15:10:10 -0500 (EST)
Message-ID: <4005A29B.7010809@bell-labs.com>
Date: Wed, 14 Jan 2004 15:12:11 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sampathk@cisco.com
Original-CC: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'MEGACO list'" <megaco@ietf.org>
Subject: Re: [Megaco] TPKT value for H.248 over TCP
References: <000a01c3dacf$1892b8a0$c80947ab@SAMPATHKW2K03>
In-Reply-To: <000a01c3dacf$1892b8a0$c80947ab@SAMPATHKW2K03>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Sampath Komanduri wrote:

> I was asking if we authors of H.248 Annex D can address this issue in 
> the standard itself. One way to do it is bump up the "version" field in 
> TPKT to 4 and use 4 octets to represent the TPDU size.
>  
> Thanks,
> Sampath

Using 4 octets has a limit as well.
Better avoid that too.

-troy


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan 14 15:37:32 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10130
	for <megaco-archive@lists.ietf.org>; Wed, 14 Jan 2004 15:37:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agrl8-0006Kp-Jx; Wed, 14 Jan 2004 15:37:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgrkA-0006Jo-C0
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 15:36:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10075
	for <megaco@ietf.org>; Wed, 14 Jan 2004 15:36:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agrk8-0007Zm-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:36:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgrjE-0007YA-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:35:05 -0500
Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgriX-0007TB-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:34:21 -0500
Received: from openetsrv.ho.lucent.com (h135-17-173-5.lucent.com [135.17.173.5])
	by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0EKXdC16742;
	Wed, 14 Jan 2004 14:33:41 -0600 (CST)
Received: from MMRAJUPC by openetsrv.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id PAA20826; Wed, 14 Jan 2004 15:33:37 -0500 (EST)
From: "Raju" <mmraju@lucent.com>
To: "Troy Cauble" <troy@bell-labs.com>, <sampathk@cisco.com>
Cc: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'MEGACO list'" <megaco@ietf.org>
Subject: RE: [Megaco] TPKT value for H.248 over TCP
Date: Wed, 14 Jan 2004 14:32:50 -0600
Message-ID: <APEOKDBAKLMDJCPJCBOOKEDJDHAA.mmraju@lucent.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <4005A29B.7010809@bell-labs.com>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Troy,

I doubt if we ever reach 32-bit length range (32 Gaga bytes in
one single h248 msg?! if a GW ever needs to send such a huge msg
then  there must be some other big problems in dealing with
such a huge msg!!).

Besides that, if we all want, we can even have a 8-byte length
field in TPKT version 4 (which can hold trillions o f bytes).

Kevin,
Can you please resend the proposal you made to overcome this 64k
limitation.

Thanks
Raju

> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
> Troy Cauble
> Sent: Wednesday, January 14, 2004 2:12 PM
> To: sampathk@cisco.com
> Cc: 'Kevin Boyle'; 'MEGACO list'
> Subject: Re: [Megaco] TPKT value for H.248 over TCP
>
>
> Sampath Komanduri wrote:
>
> > I was asking if we authors of H.248 Annex D can address this issue in
> > the standard itself. One way to do it is bump up the "version" field in
> > TPKT to 4 and use 4 octets to represent the TPDU size.
> >
> > Thanks,
> > Sampath
>
> Using 4 octets has a limit as well.
> Better avoid that too.
>
> -troy
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan 14 15:39:31 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10202
	for <megaco-archive@odin.ietf.org>; Wed, 14 Jan 2004 15:39:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agrn4-0006k9-4e
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 15:39:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EKd2ui025915
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 15:39:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agrn4-0006ju-0U
	for megaco-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 15:39:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10189
	for <megaco-web-archive@ietf.org>; Wed, 14 Jan 2004 15:38:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agrn2-0007gD-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 15:39:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Agrm4-0007dk-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 15:38:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agrl9-0007c2-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 15:37:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agrl8-0006Kp-Jx; Wed, 14 Jan 2004 15:37:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgrkA-0006Jo-C0
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 15:36:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10075
	for <megaco@ietf.org>; Wed, 14 Jan 2004 15:36:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agrk8-0007Zm-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:36:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgrjE-0007YA-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:35:05 -0500
Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgriX-0007TB-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:34:21 -0500
Received: from openetsrv.ho.lucent.com (h135-17-173-5.lucent.com [135.17.173.5])
	by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0EKXdC16742;
	Wed, 14 Jan 2004 14:33:41 -0600 (CST)
Received: from MMRAJUPC by openetsrv.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id PAA20826; Wed, 14 Jan 2004 15:33:37 -0500 (EST)
From: "Raju" <mmraju@lucent.com>
To: "Troy Cauble" <troy@bell-labs.com>, <sampathk@cisco.com>
Cc: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'MEGACO list'" <megaco@ietf.org>
Subject: RE: [Megaco] TPKT value for H.248 over TCP
Date: Wed, 14 Jan 2004 14:32:50 -0600
Message-ID: <APEOKDBAKLMDJCPJCBOOKEDJDHAA.mmraju@lucent.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <4005A29B.7010809@bell-labs.com>
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Troy,

I doubt if we ever reach 32-bit length range (32 Gaga bytes in
one single h248 msg?! if a GW ever needs to send such a huge msg
then  there must be some other big problems in dealing with
such a huge msg!!).

Besides that, if we all want, we can even have a 8-byte length
field in TPKT version 4 (which can hold trillions o f bytes).

Kevin,
Can you please resend the proposal you made to overcome this 64k
limitation.

Thanks
Raju

> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
> Troy Cauble
> Sent: Wednesday, January 14, 2004 2:12 PM
> To: sampathk@cisco.com
> Cc: 'Kevin Boyle'; 'MEGACO list'
> Subject: Re: [Megaco] TPKT value for H.248 over TCP
>
>
> Sampath Komanduri wrote:
>
> > I was asking if we authors of H.248 Annex D can address this issue in
> > the standard itself. One way to do it is bump up the "version" field in
> > TPKT to 4 and use 4 octets to represent the TPDU size.
> >
> > Thanks,
> > Sampath
>
> Using 4 octets has a limit as well.
> Better avoid that too.
>
> -troy
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan 14 15:58:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11812
	for <megaco-archive@lists.ietf.org>; Wed, 14 Jan 2004 15:58:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ags5R-00088H-JJ; Wed, 14 Jan 2004 15:58:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ags4c-00086E-5d
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 15:57:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11630
	for <megaco@ietf.org>; Wed, 14 Jan 2004 15:57:06 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ags4Z-0000aC-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:57:07 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ags3a-0000Wo-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:56:07 -0500
Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ags2s-0000Rc-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:55:27 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0EKsmJ17986
	for <megaco@ietf.org>; Wed, 14 Jan 2004 14:54:48 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA09024; Wed, 14 Jan 2004 15:54:46 -0500 (EST)
Cc: sampathk@cisco.com, "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'MEGACO list'" <megaco@ietf.org>
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA08991; Wed, 14 Jan 2004 15:54:44 -0500 (EST)
Message-ID: <4005AD0D.5080707@bell-labs.com>
Date: Wed, 14 Jan 2004 15:56:45 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Raju <mmraju@lucent.com>
Original-CC: sampathk@cisco.com, "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'MEGACO list'" <megaco@ietf.org>
Subject: Re: [Megaco] TPKT value for H.248 over TCP
References: <APEOKDBAKLMDJCPJCBOOKEDJDHAA.mmraju@lucent.com>
In-Reply-To: <APEOKDBAKLMDJCPJCBOOKEDJDHAA.mmraju@lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Raju wrote:
> Troy,
> 
> I doubt if we ever reach 32-bit length range (32 Gaga bytes in
> one single h248 msg?! if a GW ever needs to send such a huge msg
> then  there must be some other big problems in dealing with
> such a huge msg!!).
> 
> Besides that, if we all want, we can even have a 8-byte length
> field in TPKT version 4 (which can hold trillions o f bytes).
> 
> Kevin,
> Can you please resend the proposal you made to overcome this 64k
> limitation.
> 
> Thanks
> Raju


Well, I would have said the same for 64K, which was really my point.
It already seems like a hypothetical issue to me.

But I guess I work with smaller gateways than some people.


(Hi Raju!  Still employed I see!)

-troy



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan 14 16:00:31 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11943
	for <megaco-archive@odin.ietf.org>; Wed, 14 Jan 2004 16:00:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ags7O-0008Ic-Jc
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 16:00:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EL02Dm031894
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 16:00:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ags7N-0008I4-Bb
	for megaco-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 16:00:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11887
	for <megaco-web-archive@ietf.org>; Wed, 14 Jan 2004 15:59:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ags7L-0000k1-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 15:59:59 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ags6N-0000gf-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 15:58:59 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ags5R-0000da-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 15:58:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ags5R-00088H-JJ; Wed, 14 Jan 2004 15:58:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ags4c-00086E-5d
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 15:57:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11630
	for <megaco@ietf.org>; Wed, 14 Jan 2004 15:57:06 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ags4Z-0000aC-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:57:07 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ags3a-0000Wo-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:56:07 -0500
Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ags2s-0000Rc-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:55:27 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0EKsmJ17986
	for <megaco@ietf.org>; Wed, 14 Jan 2004 14:54:48 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA09024; Wed, 14 Jan 2004 15:54:46 -0500 (EST)
Cc: sampathk@cisco.com, "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'MEGACO list'" <megaco@ietf.org>
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA08991; Wed, 14 Jan 2004 15:54:44 -0500 (EST)
Message-ID: <4005AD0D.5080707@bell-labs.com>
Date: Wed, 14 Jan 2004 15:56:45 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Raju <mmraju@lucent.com>
Original-CC: sampathk@cisco.com, "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'MEGACO list'" <megaco@ietf.org>
Subject: Re: [Megaco] TPKT value for H.248 over TCP
References: <APEOKDBAKLMDJCPJCBOOKEDJDHAA.mmraju@lucent.com>
In-Reply-To: <APEOKDBAKLMDJCPJCBOOKEDJDHAA.mmraju@lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Raju wrote:
> Troy,
> 
> I doubt if we ever reach 32-bit length range (32 Gaga bytes in
> one single h248 msg?! if a GW ever needs to send such a huge msg
> then  there must be some other big problems in dealing with
> such a huge msg!!).
> 
> Besides that, if we all want, we can even have a 8-byte length
> field in TPKT version 4 (which can hold trillions o f bytes).
> 
> Kevin,
> Can you please resend the proposal you made to overcome this 64k
> limitation.
> 
> Thanks
> Raju


Well, I would have said the same for 64K, which was really my point.
It already seems like a hypothetical issue to me.

But I guess I work with smaller gateways than some people.


(Hi Raju!  Still employed I see!)

-troy



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan 14 16:01:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12004
	for <megaco-archive@lists.ietf.org>; Wed, 14 Jan 2004 16:01:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ags8L-0008Kg-ME; Wed, 14 Jan 2004 16:01:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ags7S-0008Iq-GZ
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 16:00:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11911
	for <megaco@ietf.org>; Wed, 14 Jan 2004 16:00:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ags7Q-0000kp-00
	for megaco@ietf.org; Wed, 14 Jan 2004 16:00:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ags6T-0000he-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:59:06 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ags5k-0000c6-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:58:20 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0EKvm625648
	for <megaco@ietf.org>; Wed, 14 Jan 2004 15:57:48 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2YF17D9>; Wed, 14 Jan 2004 15:57:48 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0DD06D30@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Raju <mmraju@lucent.com>, Troy Cauble <troy@bell-labs.com>,
        sampathk@cisco.com
Cc: "'MEGACO list'" <megaco@ietf.org>
Subject: RE: [Megaco] TPKT value for H.248 over TCP
Date: Wed, 14 Jan 2004 15:57:41 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,USERPASS autolearn=no 
	version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

The document is H.248.1v3_Proposal.doc at either:

http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/ or
ftp://avguest:Avguest@ftp3.itu.int/avc-site/0401_Gen/

It has also been posted at the ITU as D-410 for the upcoming meeting.

Kevin

-----Original Message-----
From: Raju [mailto:mmraju@lucent.com] 
Sent: Wednesday, January 14, 2004 3:33 PM
To: Troy Cauble; sampathk@cisco.com
Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; 'MEGACO list'
Subject: RE: [Megaco] TPKT value for H.248 over TCP

Troy,

I doubt if we ever reach 32-bit length range (32 Gaga bytes in one single
h248 msg?! if a GW ever needs to send such a huge msg then  there must be
some other big problems in dealing with such a huge msg!!).

Besides that, if we all want, we can even have a 8-byte length field in TPKT
version 4 (which can hold trillions o f bytes).

Kevin,
Can you please resend the proposal you made to overcome this 64k limitation.

Thanks
Raju

> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of 
> Troy Cauble
> Sent: Wednesday, January 14, 2004 2:12 PM
> To: sampathk@cisco.com
> Cc: 'Kevin Boyle'; 'MEGACO list'
> Subject: Re: [Megaco] TPKT value for H.248 over TCP
>
>
> Sampath Komanduri wrote:
>
> > I was asking if we authors of H.248 Annex D can address this issue 
> > in the standard itself. One way to do it is bump up the "version" 
> > field in TPKT to 4 and use 4 octets to represent the TPDU size.
> >
> > Thanks,
> > Sampath
>
> Using 4 octets has a limit as well.
> Better avoid that too.
>
> -troy
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan 14 16:03:22 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12102
	for <megaco-archive@odin.ietf.org>; Wed, 14 Jan 2004 16:03:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgsAA-0008Sp-Bv
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 16:02:54 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EL2sAq032529
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 16:02:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgsAA-0008Sa-8i
	for megaco-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 16:02:54 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12060
	for <megaco-web-archive@ietf.org>; Wed, 14 Jan 2004 16:02:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgsA8-0000rz-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 16:02:52 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ags9A-0000pA-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 16:01:53 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ags8L-0000n8-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 16:01:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ags8L-0008Kg-ME; Wed, 14 Jan 2004 16:01:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ags7S-0008Iq-GZ
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 16:00:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11911
	for <megaco@ietf.org>; Wed, 14 Jan 2004 16:00:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ags7Q-0000kp-00
	for megaco@ietf.org; Wed, 14 Jan 2004 16:00:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ags6T-0000he-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:59:06 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ags5k-0000c6-00
	for megaco@ietf.org; Wed, 14 Jan 2004 15:58:20 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0EKvm625648
	for <megaco@ietf.org>; Wed, 14 Jan 2004 15:57:48 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2YF17D9>; Wed, 14 Jan 2004 15:57:48 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0DD06D30@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Raju <mmraju@lucent.com>, Troy Cauble <troy@bell-labs.com>,
        sampathk@cisco.com
Cc: "'MEGACO list'" <megaco@ietf.org>
Subject: RE: [Megaco] TPKT value for H.248 over TCP
Date: Wed, 14 Jan 2004 15:57:41 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.7 required=5.0 tests=AWL,USERPASS autolearn=no 
	version=2.60

The document is H.248.1v3_Proposal.doc at either:

http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/ or
ftp://avguest:Avguest@ftp3.itu.int/avc-site/0401_Gen/

It has also been posted at the ITU as D-410 for the upcoming meeting.

Kevin

-----Original Message-----
From: Raju [mailto:mmraju@lucent.com] 
Sent: Wednesday, January 14, 2004 3:33 PM
To: Troy Cauble; sampathk@cisco.com
Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; 'MEGACO list'
Subject: RE: [Megaco] TPKT value for H.248 over TCP

Troy,

I doubt if we ever reach 32-bit length range (32 Gaga bytes in one single
h248 msg?! if a GW ever needs to send such a huge msg then  there must be
some other big problems in dealing with such a huge msg!!).

Besides that, if we all want, we can even have a 8-byte length field in TPKT
version 4 (which can hold trillions o f bytes).

Kevin,
Can you please resend the proposal you made to overcome this 64k limitation.

Thanks
Raju

> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of 
> Troy Cauble
> Sent: Wednesday, January 14, 2004 2:12 PM
> To: sampathk@cisco.com
> Cc: 'Kevin Boyle'; 'MEGACO list'
> Subject: Re: [Megaco] TPKT value for H.248 over TCP
>
>
> Sampath Komanduri wrote:
>
> > I was asking if we authors of H.248 Annex D can address this issue 
> > in the standard itself. One way to do it is bump up the "version" 
> > field in TPKT to 4 and use 4 octets to represent the TPDU size.
> >
> > Thanks,
> > Sampath
>
> Using 4 octets has a limit as well.
> Better avoid that too.
>
> -troy
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan 14 16:28:37 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14985
	for <megaco-archive@lists.ietf.org>; Wed, 14 Jan 2004 16:28:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgsYT-0001P1-Tf; Wed, 14 Jan 2004 16:28:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgsYQ-0001OY-5H
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 16:27:58 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14967
	for <megaco@ietf.org>; Wed, 14 Jan 2004 16:27:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgsYO-0003iw-00
	for megaco@ietf.org; Wed, 14 Jan 2004 16:27:56 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgsXV-0003ga-00
	for megaco@ietf.org; Wed, 14 Jan 2004 16:27:02 -0500
Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgsWS-0003ct-00
	for megaco@ietf.org; Wed, 14 Jan 2004 16:25:56 -0500
Received: from radvpost.radvision.com [192.168.216.29]
	by radvpost.radvision.com
	with XWall v3.28 ;
	Wed, 14 Jan 2004 16:25:45 -0500
Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19)
	id <V4QZ4N32>; Wed, 14 Jan 2004 16:25:45 -0500
Message-ID: <A3851AA1B761E944912B20D1E95A7EFE0B0B48@radvpost.radvision.com>
From: Steve Cipolli <SCipolli@radvision.com>
To: "'Troy Cauble'" <troy@bell-labs.com>, Raju <mmraju@lucent.com>
Cc: sampathk@cisco.com, "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'MEGACO list'" <megaco@ietf.org>
Subject: RE: [Megaco] TPKT value for H.248 over TCP
Date: Wed, 14 Jan 2004 16:25:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

A colleague of mine suggested to simply interpret a TPKT packetlength of 0
(currently not legal since the TPKT header length is included in the
packetlength) as an indication of that the message is continued in the next
TPKT and that the packet length of this PDU is 65524.  This scheme allows
infinitely long messages and provides backward compatibility for packets
under 65524 bytes.   Compatibility may be important since there is no way to
negotiate which version of TPKT MEGACO entities should use and asking for
more well-known ports from IANA for a new version of TPKT for MEGACO
transport may be tough to come by.

--Stephen

> -----Original Message-----
> From: Troy Cauble [mailto:troy@bell-labs.com]
> Sent: Wednesday, January 14, 2004 3:57 PM
> To: Raju
> Cc: sampathk@cisco.com; 'Kevin Boyle'; 'MEGACO list'
> Subject: Re: [Megaco] TPKT value for H.248 over TCP
> 
> 
> 
> 
> Raju wrote:
> > Troy,
> > 
> > I doubt if we ever reach 32-bit length range (32 Gaga bytes in
> > one single h248 msg?! if a GW ever needs to send such a huge msg
> > then  there must be some other big problems in dealing with
> > such a huge msg!!).
> > 
> > Besides that, if we all want, we can even have a 8-byte length
> > field in TPKT version 4 (which can hold trillions o f bytes).
> > 
> > Kevin,
> > Can you please resend the proposal you made to overcome this 64k
> > limitation.
> > 
> > Thanks
> > Raju
> 
> 
> Well, I would have said the same for 64K, which was really my point.
> It already seems like a hypothetical issue to me.
> 
> But I guess I work with smaller gateways than some people.
> 
> 
> (Hi Raju!  Still employed I see!)
> 
> -troy
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan 14 16:30:37 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15076
	for <megaco-archive@odin.ietf.org>; Wed, 14 Jan 2004 16:30:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgsaX-0001XY-2h
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 16:30:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0ELU98Z005914
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 16:30:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgsaW-0001XJ-VJ
	for megaco-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 16:30:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15039
	for <megaco-web-archive@ietf.org>; Wed, 14 Jan 2004 16:30:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgsaT-0003nU-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 16:30:05 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgsaB-0003kn-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 16:29:48 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgsYT-0003jO-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 16:28:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgsYT-0001P1-Tf; Wed, 14 Jan 2004 16:28:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgsYQ-0001OY-5H
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 16:27:58 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14967
	for <megaco@ietf.org>; Wed, 14 Jan 2004 16:27:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgsYO-0003iw-00
	for megaco@ietf.org; Wed, 14 Jan 2004 16:27:56 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgsXV-0003ga-00
	for megaco@ietf.org; Wed, 14 Jan 2004 16:27:02 -0500
Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgsWS-0003ct-00
	for megaco@ietf.org; Wed, 14 Jan 2004 16:25:56 -0500
Received: from radvpost.radvision.com [192.168.216.29]
	by radvpost.radvision.com
	with XWall v3.28 ;
	Wed, 14 Jan 2004 16:25:45 -0500
Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19)
	id <V4QZ4N32>; Wed, 14 Jan 2004 16:25:45 -0500
Message-ID: <A3851AA1B761E944912B20D1E95A7EFE0B0B48@radvpost.radvision.com>
From: Steve Cipolli <SCipolli@radvision.com>
To: "'Troy Cauble'" <troy@bell-labs.com>, Raju <mmraju@lucent.com>
Cc: sampathk@cisco.com, "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'MEGACO list'" <megaco@ietf.org>
Subject: RE: [Megaco] TPKT value for H.248 over TCP
Date: Wed, 14 Jan 2004 16:25:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60

A colleague of mine suggested to simply interpret a TPKT packetlength of 0
(currently not legal since the TPKT header length is included in the
packetlength) as an indication of that the message is continued in the next
TPKT and that the packet length of this PDU is 65524.  This scheme allows
infinitely long messages and provides backward compatibility for packets
under 65524 bytes.   Compatibility may be important since there is no way to
negotiate which version of TPKT MEGACO entities should use and asking for
more well-known ports from IANA for a new version of TPKT for MEGACO
transport may be tough to come by.

--Stephen

> -----Original Message-----
> From: Troy Cauble [mailto:troy@bell-labs.com]
> Sent: Wednesday, January 14, 2004 3:57 PM
> To: Raju
> Cc: sampathk@cisco.com; 'Kevin Boyle'; 'MEGACO list'
> Subject: Re: [Megaco] TPKT value for H.248 over TCP
> 
> 
> 
> 
> Raju wrote:
> > Troy,
> > 
> > I doubt if we ever reach 32-bit length range (32 Gaga bytes in
> > one single h248 msg?! if a GW ever needs to send such a huge msg
> > then  there must be some other big problems in dealing with
> > such a huge msg!!).
> > 
> > Besides that, if we all want, we can even have a 8-byte length
> > field in TPKT version 4 (which can hold trillions o f bytes).
> > 
> > Kevin,
> > Can you please resend the proposal you made to overcome this 64k
> > limitation.
> > 
> > Thanks
> > Raju
> 
> 
> Well, I would have said the same for 64K, which was really my point.
> It already seems like a hypothetical issue to me.
> 
> But I guess I work with smaller gateways than some people.
> 
> 
> (Hi Raju!  Still employed I see!)
> 
> -troy
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan 14 19:50:36 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23784
	for <megaco-archive@lists.ietf.org>; Wed, 14 Jan 2004 19:50:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agvhz-00038x-Vv; Wed, 14 Jan 2004 19:50:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agvh5-00037m-1Y
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 19:49:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23737
	for <megaco@ietf.org>; Wed, 14 Jan 2004 19:49:05 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agvh3-0004Uh-00
	for megaco@ietf.org; Wed, 14 Jan 2004 19:49:05 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Agvg6-0004TA-00
	for megaco@ietf.org; Wed, 14 Jan 2004 19:48:07 -0500
Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgvfV-0004Rk-00
	for megaco@ietf.org; Wed, 14 Jan 2004 19:47:29 -0500
Received: from [172.16.1.210] (helo=CCPU00204)
	by smtp.ccpu.com with smtp (Exim 4.24 #1 (Debian))
	id 1AgvfQ-0006nm-Gb; Wed, 14 Jan 2004 16:47:24 -0800
From: "Rashim Anand" <ranand@ccpu.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'MEGACO list'" <megaco@ietf.org>
Subject: [Megaco] A question about H.248.6
Date: Wed, 14 Jan 2004 16:50:34 -0800
Message-ID: <LLEMKHPJAECAPBFPABPNAEPHCDAA.ranand@ccpu.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002C_01C3DABE.875AEBB0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <A3851AA1B761E944912B20D1E95A7EFE0B0B48@radvpost.radvision.com>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_20_30,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no 
	version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_002C_01C3DABE.875AEBB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Could the authors of the Dynamic Tone Definition (H.248.6) package please
clarify the possible values of the tid property (0x0001) in the dtd (dynamic
tone definition) package. This is what the document says -

Type:         expanding enumeration
Possible Values:
   Existing package_id, tone id described in supported packages that extend
tonegen or new tones to be added.

This description is not very clear. Could you also provide some examples of
the values of tid? Also, what is the meaning of "expanding" in the
"expanding enumeration" type?

Thanks,

Rashim Anand



------=_NextPart_000_002C_01C3DABE.875AEBB0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<P><FONT size=3D2>Hi,<BR><BR>Could the authors of the&nbsp;Dynamic Tone =
Definition=20
(H.248.6)&nbsp;package please clarify the possible values of the tid =
property=20
(0x0001) in the dtd (dynamic tone definition) package. This is what=20
the&nbsp;document says=20
-<BR><BR>Type:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; expanding =

enumeration<BR>Possible Values:<BR>&nbsp;&nbsp; Existing package_id, =
tone id=20
described in supported packages that extend tonegen or new tones to be=20
added.</FONT></P>
<P><FONT size=3D2>This description is not very clear. Could you also =
provide some=20
examples of the values of tid? Also, what is the meaning of "expanding" =
in the=20
"expanding enumeration" type?</FONT></P>
<P><FONT size=3D2>Thanks,</FONT></P>
<P><FONT size=3D2>Rashim Anand</FONT></P>
<P><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT>&nbsp;</P></BODY></HTML>

------=_NextPart_000_002C_01C3DABE.875AEBB0--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan 14 19:52:41 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23842
	for <megaco-archive@odin.ietf.org>; Wed, 14 Jan 2004 19:52:41 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agvk4-0003Hv-G9
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 19:52:13 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F0qCm1012636
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 19:52:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agvk4-0003Hj-9j
	for megaco-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 19:52:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23823
	for <megaco-web-archive@ietf.org>; Wed, 14 Jan 2004 19:52:05 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agvjx-0004bq-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 19:52:05 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Agviy-0004Z1-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 19:51:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agvi2-0004X9-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 19:50:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agvhz-00038x-Vv; Wed, 14 Jan 2004 19:50:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agvh5-00037m-1Y
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 19:49:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23737
	for <megaco@ietf.org>; Wed, 14 Jan 2004 19:49:05 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agvh3-0004Uh-00
	for megaco@ietf.org; Wed, 14 Jan 2004 19:49:05 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Agvg6-0004TA-00
	for megaco@ietf.org; Wed, 14 Jan 2004 19:48:07 -0500
Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgvfV-0004Rk-00
	for megaco@ietf.org; Wed, 14 Jan 2004 19:47:29 -0500
Received: from [172.16.1.210] (helo=CCPU00204)
	by smtp.ccpu.com with smtp (Exim 4.24 #1 (Debian))
	id 1AgvfQ-0006nm-Gb; Wed, 14 Jan 2004 16:47:24 -0800
From: "Rashim Anand" <ranand@ccpu.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'MEGACO list'" <megaco@ietf.org>
Subject: [Megaco] A question about H.248.6
Date: Wed, 14 Jan 2004 16:50:34 -0800
Message-ID: <LLEMKHPJAECAPBFPABPNAEPHCDAA.ranand@ccpu.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002C_01C3DABE.875AEBB0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <A3851AA1B761E944912B20D1E95A7EFE0B0B48@radvpost.radvision.com>
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_20_30,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no 
	version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_002C_01C3DABE.875AEBB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Could the authors of the Dynamic Tone Definition (H.248.6) package please
clarify the possible values of the tid property (0x0001) in the dtd (dynamic
tone definition) package. This is what the document says -

Type:         expanding enumeration
Possible Values:
   Existing package_id, tone id described in supported packages that extend
tonegen or new tones to be added.

This description is not very clear. Could you also provide some examples of
the values of tid? Also, what is the meaning of "expanding" in the
"expanding enumeration" type?

Thanks,

Rashim Anand



------=_NextPart_000_002C_01C3DABE.875AEBB0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<P><FONT size=3D2>Hi,<BR><BR>Could the authors of the&nbsp;Dynamic Tone =
Definition=20
(H.248.6)&nbsp;package please clarify the possible values of the tid =
property=20
(0x0001) in the dtd (dynamic tone definition) package. This is what=20
the&nbsp;document says=20
-<BR><BR>Type:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; expanding =

enumeration<BR>Possible Values:<BR>&nbsp;&nbsp; Existing package_id, =
tone id=20
described in supported packages that extend tonegen or new tones to be=20
added.</FONT></P>
<P><FONT size=3D2>This description is not very clear. Could you also =
provide some=20
examples of the values of tid? Also, what is the meaning of "expanding" =
in the=20
"expanding enumeration" type?</FONT></P>
<P><FONT size=3D2>Thanks,</FONT></P>
<P><FONT size=3D2>Rashim Anand</FONT></P>
<P><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT>&nbsp;</P></BODY></HTML>

------=_NextPart_000_002C_01C3DABE.875AEBB0--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan 14 20:18:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24996
	for <megaco-archive@lists.ietf.org>; Wed, 14 Jan 2004 20:18:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agw93-0004pk-6k; Wed, 14 Jan 2004 20:18:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agw8A-0004lO-M3
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 20:17:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24950
	for <megaco@ietf.org>; Wed, 14 Jan 2004 20:17:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agw88-0005mn-00
	for megaco@ietf.org; Wed, 14 Jan 2004 20:17:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Agw7B-0005lT-00
	for megaco@ietf.org; Wed, 14 Jan 2004 20:16:06 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agw6h-0005kU-00
	for megaco@ietf.org; Wed, 14 Jan 2004 20:15:35 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1Agw6i-0005QY-1E
	for megaco@ietf.org; Wed, 14 Jan 2004 20:15:36 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id i0F106v28227
	for <megaco@ietf.org>; Thu, 15 Jan 2004 12:00:06 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.174]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5M2GG4; Thu, 15 Jan 2004 12:01:01 +1100
Message-ID: <4005E68A.3030007@ericsson.com>
Date: Thu, 15 Jan 2004 12:02:02 +1100
From: Christian Groves <Christian.Groves@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: megaco ietf <megaco@ietf.org>
Subject: [Fwd: Re: [Megaco] TPKT value for H.248 over TCP]
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Resending due to error.
Christian

-------- Original Message --------
Subject: Re: [Megaco] TPKT value for H.248 over TCP
Date: Wed, 14 Jan 2004 11:33:04 +1100
From: Christian Groves <Christian.Groves@ericsson.com>
To: sampathk@cisco.com
CC: 'MEGACO list' <megaco@ietf.org>
References: <000b01c3d9fa$2047be90$c80947ab@SAMPATHKW2K03>

Hello Sampath,

I'm not the author of Annex D however:  In the case where the message would be
too big the MGC could audit groups of terminations. This will return what
context the terminations are in. This is probably more useful than just the
context IDs.

Regards, Christian

Sampath Komanduri wrote:

> Could the author of Annex D pls. respond?
>  
> Thanks,
> Sampath
> 
>     -----Original Message-----
>     From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf
>     Of Sampath Komanduri
>     Sent: Tuesday, January 06, 2004 8:16 PM
>     To: 'MEGACO list'
>     Subject: [Megaco] TPKT value for H.248 over TCP
>     Importance: High
> 
>     Hi List,
>     I am not sure if this question was already raised in the list. If it
>     was, pls. point me to the discussion and the consensus.
>     According to ANNEX D of H.248.1 protocol, "TPKT, according to RFC
>     1006 <http://www.faqs.org/rfcs/rfc1006.html>, SHALL be used to
>     delineate messages within the TCP stream". RFC 1006 limits the size
>     of TPDU to 65524. Replicating the relevant text here for convenience:
>      
>     ***************************************************
>          "A TPKT consists of two parts:  a packet-header and a TPDU. 
>           The format of the header is constant regardless of the type of
>     packet.
>           The format of the packet-header is as follows:
> 
>             0                   1                   2                   3
>             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>            |      vrsn     |    reserved   |          packet length        |
>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>           where:
> 
>           vrsn                         8 bits
> 
>           This field is always 3 for the version of the protocol
>     described in this memo.
> 
>           packet length                16 bits (min=7, max=65535)
> 
>           This field contains the length of entire packet in octets,
>     including packet-header.
>           This permits a maximum TPDU size of 65531 octets.
>           Based on the size of the data transfer (DT) TPDU, this permits
>     a maximum
>           TSDU size of 65524 octets."
>     *********************************************************
>      
>     This causes an issue. Based on the wildcard level of Audit and the
>     descriptors involved, this size could easily exceed 64K size
>     (especially if MG and MGC are using Long text format and white
>     spaces in the messages). In few cases, it is possible to return
>     an error code (533: Response exceeds maximum transport PDU size).
>     However, in some cases returning 533 is not an option.
>     Consider for example the following scenario: After an association is
>     DISCONNECTED, MGC may want to get the list of non-null contexts on
>     the gateway using the following command (pls. ignore if there is any
>     mistake in the message and reply construct):
>      
>     !/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}}
>     !/1
>     ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}}, ....and so on}
>     In the best case (i.e. no white-space, no audit descriptor and short
>     format), this allows for an MG to have only 5000 active contexts on
>     the card. Anything more (or any variation in the audit command) will
>     reduce the number of active contexts that an MG can have even with
>     TCP as the transport option.
>     Responding with 533 is not an option here since that would leave
>     MG-MGC in state from where there is no elegant way out (at least
>     from H.248 protocol).
>      
>     How do the gurus' on list suggest we solve this issue? Couple of
>     ideas that come to mind are:
> 
>        1. Define a Bulk-Audit Package/scheme: As was done for MGCP,
>           define a Bulk-Audit package/scheme especially with support
>           for       
>               RangeWildcard = "[" NumericalRange *( "," NumericalRange )
>           "]" and
>               NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].
>               This will certainly reduce the cases and scenarios when
>           MG/MGC will run into the issue under discussion but may not
>           eliminate it.
>        2. Add more information on W- Audit support in the protocol.
>        3. Introduce RFC 1006 modification (with version field 4) such
>           that "packet length" of packet header in TPKT is 32 bits as
>           opposed to 16 bits.
>        4. Combination of the above schemes.
>        5. Anything else?
> 
>     Pls. advice on how this problem can be solved?
> 
>     Thanks,
>     Sampath




_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan 14 20:20:32 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25086
	for <megaco-archive@odin.ietf.org>; Wed, 14 Jan 2004 20:20:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgwB1-00050T-Lv
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 20:20:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F1K3Cd019239
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 20:20:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgwB0-00050E-Mr
	for megaco-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 20:20:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25056
	for <megaco-web-archive@ietf.org>; Wed, 14 Jan 2004 20:20:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgwAy-0005tO-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 20:20:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Agw9z-0005qi-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 20:19:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agw91-0005nt-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 20:17:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agw93-0004pk-6k; Wed, 14 Jan 2004 20:18:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agw8A-0004lO-M3
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 20:17:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24950
	for <megaco@ietf.org>; Wed, 14 Jan 2004 20:17:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agw88-0005mn-00
	for megaco@ietf.org; Wed, 14 Jan 2004 20:17:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Agw7B-0005lT-00
	for megaco@ietf.org; Wed, 14 Jan 2004 20:16:06 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agw6h-0005kU-00
	for megaco@ietf.org; Wed, 14 Jan 2004 20:15:35 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1Agw6i-0005QY-1E
	for megaco@ietf.org; Wed, 14 Jan 2004 20:15:36 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id i0F106v28227
	for <megaco@ietf.org>; Thu, 15 Jan 2004 12:00:06 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.174]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5M2GG4; Thu, 15 Jan 2004 12:01:01 +1100
Message-ID: <4005E68A.3030007@ericsson.com>
Date: Thu, 15 Jan 2004 12:02:02 +1100
From: Christian Groves <Christian.Groves@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: megaco ietf <megaco@ietf.org>
Subject: [Fwd: Re: [Megaco] TPKT value for H.248 over TCP]
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Resending due to error.
Christian

-------- Original Message --------
Subject: Re: [Megaco] TPKT value for H.248 over TCP
Date: Wed, 14 Jan 2004 11:33:04 +1100
From: Christian Groves <Christian.Groves@ericsson.com>
To: sampathk@cisco.com
CC: 'MEGACO list' <megaco@ietf.org>
References: <000b01c3d9fa$2047be90$c80947ab@SAMPATHKW2K03>

Hello Sampath,

I'm not the author of Annex D however:  In the case where the message would be
too big the MGC could audit groups of terminations. This will return what
context the terminations are in. This is probably more useful than just the
context IDs.

Regards, Christian

Sampath Komanduri wrote:

> Could the author of Annex D pls. respond?
>  
> Thanks,
> Sampath
> 
>     -----Original Message-----
>     From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf
>     Of Sampath Komanduri
>     Sent: Tuesday, January 06, 2004 8:16 PM
>     To: 'MEGACO list'
>     Subject: [Megaco] TPKT value for H.248 over TCP
>     Importance: High
> 
>     Hi List,
>     I am not sure if this question was already raised in the list. If it
>     was, pls. point me to the discussion and the consensus.
>     According to ANNEX D of H.248.1 protocol, "TPKT, according to RFC
>     1006 <http://www.faqs.org/rfcs/rfc1006.html>, SHALL be used to
>     delineate messages within the TCP stream". RFC 1006 limits the size
>     of TPDU to 65524. Replicating the relevant text here for convenience:
>      
>     ***************************************************
>          "A TPKT consists of two parts:  a packet-header and a TPDU. 
>           The format of the header is constant regardless of the type of
>     packet.
>           The format of the packet-header is as follows:
> 
>             0                   1                   2                   3
>             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>            |      vrsn     |    reserved   |          packet length        |
>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>           where:
> 
>           vrsn                         8 bits
> 
>           This field is always 3 for the version of the protocol
>     described in this memo.
> 
>           packet length                16 bits (min=7, max=65535)
> 
>           This field contains the length of entire packet in octets,
>     including packet-header.
>           This permits a maximum TPDU size of 65531 octets.
>           Based on the size of the data transfer (DT) TPDU, this permits
>     a maximum
>           TSDU size of 65524 octets."
>     *********************************************************
>      
>     This causes an issue. Based on the wildcard level of Audit and the
>     descriptors involved, this size could easily exceed 64K size
>     (especially if MG and MGC are using Long text format and white
>     spaces in the messages). In few cases, it is possible to return
>     an error code (533: Response exceeds maximum transport PDU size).
>     However, in some cases returning 533 is not an option.
>     Consider for example the following scenario: After an association is
>     DISCONNECTED, MGC may want to get the list of non-null contexts on
>     the gateway using the following command (pls. ignore if there is any
>     mistake in the message and reply construct):
>      
>     !/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}}
>     !/1
>     ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}}, ....and so on}
>     In the best case (i.e. no white-space, no audit descriptor and short
>     format), this allows for an MG to have only 5000 active contexts on
>     the card. Anything more (or any variation in the audit command) will
>     reduce the number of active contexts that an MG can have even with
>     TCP as the transport option.
>     Responding with 533 is not an option here since that would leave
>     MG-MGC in state from where there is no elegant way out (at least
>     from H.248 protocol).
>      
>     How do the gurus' on list suggest we solve this issue? Couple of
>     ideas that come to mind are:
> 
>        1. Define a Bulk-Audit Package/scheme: As was done for MGCP,
>           define a Bulk-Audit package/scheme especially with support
>           for       
>               RangeWildcard = "[" NumericalRange *( "," NumericalRange )
>           "]" and
>               NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].
>               This will certainly reduce the cases and scenarios when
>           MG/MGC will run into the issue under discussion but may not
>           eliminate it.
>        2. Add more information on W- Audit support in the protocol.
>        3. Introduce RFC 1006 modification (with version field 4) such
>           that "packet length" of packet header in TPKT is 32 bits as
>           opposed to 16 bits.
>        4. Combination of the above schemes.
>        5. Anything else?
> 
>     Pls. advice on how this problem can be solved?
> 
>     Thanks,
>     Sampath




_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan 14 23:54:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00502
	for <megaco-archive@lists.ietf.org>; Wed, 14 Jan 2004 23:54:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgzW5-00074u-Cb; Wed, 14 Jan 2004 23:54:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgzVH-000732-5k
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 23:53:11 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00476
	for <megaco@ietf.org>; Wed, 14 Jan 2004 23:53:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgzVE-0004PL-00
	for megaco@ietf.org; Wed, 14 Jan 2004 23:53:09 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgzUJ-0004No-00
	for megaco@ietf.org; Wed, 14 Jan 2004 23:52:12 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgzTf-0004KV-00
	for megaco@ietf.org; Wed, 14 Jan 2004 23:51:37 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id i0F3PCv07508;
	Thu, 15 Jan 2004 14:25:12 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.174]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5M22QM; Thu, 15 Jan 2004 14:26:07 +1100
Message-ID: <40060889.2060906@ericsson.com>
Date: Thu, 15 Jan 2004 14:27:05 +1100
From: Christian Groves <Christian.Groves@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>
CC: Steve Cipolli <SCipolli@radvision.com>,
        "'Troy Cauble'" <troy@bell-labs.com>, Raju <mmraju@lucent.com>,
        sampathk@cisco.com, "'MEGACO list'" <megaco@ietf.org>
Subject: Re: [Megaco] TPKT value for H.248 over TCP
References: <A3851AA1B761E944912B20D1E95A7EFE0B0B48@radvpost.radvision.com>
In-Reply-To: <A3851AA1B761E944912B20D1E95A7EFE0B0B48@radvpost.radvision.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

G'Day all,

Rather than tweaking one transport to carry infinitely long messages I think we 
should look at a solution that would allow very long messages to be carried 
across all the defined transports. I think Kevin has started the discussion 
through his contribution. I personally would like to a solution that doesn't 
need H.248.1 to manage segmentation for one particular transport.

Regards, Christian

Steve Cipolli wrote:

> A colleague of mine suggested to simply interpret a TPKT packetlength of 0
> (currently not legal since the TPKT header length is included in the
> packetlength) as an indication of that the message is continued in the next
> TPKT and that the packet length of this PDU is 65524.  This scheme allows
> infinitely long messages and provides backward compatibility for packets
> under 65524 bytes.   Compatibility may be important since there is no way to
> negotiate which version of TPKT MEGACO entities should use and asking for
> more well-known ports from IANA for a new version of TPKT for MEGACO
> transport may be tough to come by.
> 
> --Stephen
> 
> 
>>-----Original Message-----
>>From: Troy Cauble [mailto:troy@bell-labs.com]
>>Sent: Wednesday, January 14, 2004 3:57 PM
>>To: Raju
>>Cc: sampathk@cisco.com; 'Kevin Boyle'; 'MEGACO list'
>>Subject: Re: [Megaco] TPKT value for H.248 over TCP
>>
>>
>>
>>
>>Raju wrote:
>>
>>>Troy,
>>>
>>>I doubt if we ever reach 32-bit length range (32 Gaga bytes in
>>>one single h248 msg?! if a GW ever needs to send such a huge msg
>>>then  there must be some other big problems in dealing with
>>>such a huge msg!!).
>>>
>>>Besides that, if we all want, we can even have a 8-byte length
>>>field in TPKT version 4 (which can hold trillions o f bytes).
>>>
>>>Kevin,
>>>Can you please resend the proposal you made to overcome this 64k
>>>limitation.
>>>
>>>Thanks
>>>Raju
>>
>>
>>Well, I would have said the same for 64K, which was really my point.
>>It already seems like a hypothetical issue to me.
>>
>>But I guess I work with smaller gateways than some people.
>>
>>
>>(Hi Raju!  Still employed I see!)
>>
>>-troy
>>
>>
>>
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan 14 23:55:39 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00538
	for <megaco-archive@odin.ietf.org>; Wed, 14 Jan 2004 23:55:39 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgzXE-0007Ej-2E
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 23:55:12 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F4tCSp027814
	for megaco-archive@odin.ietf.org; Wed, 14 Jan 2004 23:55:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgzXD-0007EX-Sf
	for megaco-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 23:55:11 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00531
	for <megaco-web-archive@ietf.org>; Wed, 14 Jan 2004 23:55:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgzXB-0004TF-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 23:55:09 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgzWG-0004S4-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 23:54:13 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgzW5-0004Qi-00
	for megaco-web-archive@ietf.org; Wed, 14 Jan 2004 23:54:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgzW5-00074u-Cb; Wed, 14 Jan 2004 23:54:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgzVH-000732-5k
	for megaco@optimus.ietf.org; Wed, 14 Jan 2004 23:53:11 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00476
	for <megaco@ietf.org>; Wed, 14 Jan 2004 23:53:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgzVE-0004PL-00
	for megaco@ietf.org; Wed, 14 Jan 2004 23:53:09 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgzUJ-0004No-00
	for megaco@ietf.org; Wed, 14 Jan 2004 23:52:12 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgzTf-0004KV-00
	for megaco@ietf.org; Wed, 14 Jan 2004 23:51:37 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id i0F3PCv07508;
	Thu, 15 Jan 2004 14:25:12 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.174]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5M22QM; Thu, 15 Jan 2004 14:26:07 +1100
Message-ID: <40060889.2060906@ericsson.com>
Date: Thu, 15 Jan 2004 14:27:05 +1100
From: Christian Groves <Christian.Groves@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>
CC: Steve Cipolli <SCipolli@radvision.com>,
        "'Troy Cauble'" <troy@bell-labs.com>, Raju <mmraju@lucent.com>,
        sampathk@cisco.com, "'MEGACO list'" <megaco@ietf.org>
Subject: Re: [Megaco] TPKT value for H.248 over TCP
References: <A3851AA1B761E944912B20D1E95A7EFE0B0B48@radvpost.radvision.com>
In-Reply-To: <A3851AA1B761E944912B20D1E95A7EFE0B0B48@radvpost.radvision.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

G'Day all,

Rather than tweaking one transport to carry infinitely long messages I think we 
should look at a solution that would allow very long messages to be carried 
across all the defined transports. I think Kevin has started the discussion 
through his contribution. I personally would like to a solution that doesn't 
need H.248.1 to manage segmentation for one particular transport.

Regards, Christian

Steve Cipolli wrote:

> A colleague of mine suggested to simply interpret a TPKT packetlength of 0
> (currently not legal since the TPKT header length is included in the
> packetlength) as an indication of that the message is continued in the next
> TPKT and that the packet length of this PDU is 65524.  This scheme allows
> infinitely long messages and provides backward compatibility for packets
> under 65524 bytes.   Compatibility may be important since there is no way to
> negotiate which version of TPKT MEGACO entities should use and asking for
> more well-known ports from IANA for a new version of TPKT for MEGACO
> transport may be tough to come by.
> 
> --Stephen
> 
> 
>>-----Original Message-----
>>From: Troy Cauble [mailto:troy@bell-labs.com]
>>Sent: Wednesday, January 14, 2004 3:57 PM
>>To: Raju
>>Cc: sampathk@cisco.com; 'Kevin Boyle'; 'MEGACO list'
>>Subject: Re: [Megaco] TPKT value for H.248 over TCP
>>
>>
>>
>>
>>Raju wrote:
>>
>>>Troy,
>>>
>>>I doubt if we ever reach 32-bit length range (32 Gaga bytes in
>>>one single h248 msg?! if a GW ever needs to send such a huge msg
>>>then  there must be some other big problems in dealing with
>>>such a huge msg!!).
>>>
>>>Besides that, if we all want, we can even have a 8-byte length
>>>field in TPKT version 4 (which can hold trillions o f bytes).
>>>
>>>Kevin,
>>>Can you please resend the proposal you made to overcome this 64k
>>>limitation.
>>>
>>>Thanks
>>>Raju
>>
>>
>>Well, I would have said the same for 64K, which was really my point.
>>It already seems like a hypothetical issue to me.
>>
>>But I guess I work with smaller gateways than some people.
>>
>>
>>(Hi Raju!  Still employed I see!)
>>
>>-troy
>>
>>
>>
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan 15 00:12:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00974
	for <megaco-archive@lists.ietf.org>; Thu, 15 Jan 2004 00:12:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgznV-00086Q-Aw; Thu, 15 Jan 2004 00:12:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agzmj-00085q-3C
	for megaco@optimus.ietf.org; Thu, 15 Jan 2004 00:11:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00924
	for <megaco@ietf.org>; Thu, 15 Jan 2004 00:11:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agzmg-00050X-00
	for megaco@ietf.org; Thu, 15 Jan 2004 00:11:10 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Agzli-0004ze-00
	for megaco@ietf.org; Thu, 15 Jan 2004 00:10:11 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgzlA-0004yf-00
	for megaco@ietf.org; Thu, 15 Jan 2004 00:09:36 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1AgzlA-0000kH-E8
	for megaco@ietf.org; Thu, 15 Jan 2004 00:09:37 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id i0F2v9v05801;
	Thu, 15 Jan 2004 13:57:09 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.174]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5M22CY; Thu, 15 Jan 2004 13:58:04 +1100
Message-ID: <400601F8.9050508@ericsson.com>
Date: Thu, 15 Jan 2004 13:59:04 +1100
From: Christian Groves <Christian.Groves@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
CC: Dal Chohan <D.Chohan@ftel.co.uk>, Kevin Boyle <kboyle@nortelnetworks.com>
Subject: Re: [Megaco] H.248.1  generic package - signal completion event
References: <005f01c3d9c8$827a5e10$403010ac@DALLAPTOP> <400490A0.2010903@ericsson.com>
In-Reply-To: <400490A0.2010903@ericsson.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Resend due to error.

Christian Groves wrote:

> Hello Dal,
> 
> Yes this seems to be somewhere were the text can be improved. I would 
> actually propose to change 7.1.1 to 7.1.11. It looks like a '1' was 
> dropped off the reference.
> 
> Kevin could you please add this to your IG list?
> 
> Regards, Christian
> 
> Dal Chohan wrote:
> 
>> RE: H.248.1 E.1 Generic Package "Signal Completion" event
>>  
>> The package description suggests that the signal completion event can 
>> only be sent when the notifyCompletion parameter is included. However, 
>> clause 7.1.11 of H.248 version 2 indicates that a signal 
>> completion/termination event can be sent, even when the 
>> "notifyCompletion" parameter was not present in the situation the 
>> signal stopped and was never started for other reason (i.e. Meth = NC), .
>>  
>> In addition the package contains references to 7.1.1, 7.1.17 and 
>> 7.2.7, but no reference to "7.1.11 Signal Descriptor" where the 
>> procedures for signal completion are defined.
>>  
>>  
>> I guess a note in the IG should be included to take into account the 
>> above comments and re-word the text in the package to say something 
>> along the lines "Indicates the termination of a signal and is this 
>> event is sent as defined in the procedures of 7.1.11".
>>  
>>  
>>  
>> Dal Chohan
> 
> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan 15 00:13:41 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01012
	for <megaco-archive@odin.ietf.org>; Thu, 15 Jan 2004 00:13:40 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agzof-0008G4-AT
	for megaco-archive@odin.ietf.org; Thu, 15 Jan 2004 00:13:13 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F5DDYR031738
	for megaco-archive@odin.ietf.org; Thu, 15 Jan 2004 00:13:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agzof-0008Fp-5v
	for megaco-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 00:13:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01009
	for <megaco-web-archive@ietf.org>; Thu, 15 Jan 2004 00:13:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agzoc-00054u-00
	for megaco-web-archive@ietf.org; Thu, 15 Jan 2004 00:13:10 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Agznj-00053e-00
	for megaco-web-archive@ietf.org; Thu, 15 Jan 2004 00:12:16 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgznU-00051z-00
	for megaco-web-archive@ietf.org; Thu, 15 Jan 2004 00:12:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgznV-00086Q-Aw; Thu, 15 Jan 2004 00:12:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agzmj-00085q-3C
	for megaco@optimus.ietf.org; Thu, 15 Jan 2004 00:11:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00924
	for <megaco@ietf.org>; Thu, 15 Jan 2004 00:11:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agzmg-00050X-00
	for megaco@ietf.org; Thu, 15 Jan 2004 00:11:10 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Agzli-0004ze-00
	for megaco@ietf.org; Thu, 15 Jan 2004 00:10:11 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgzlA-0004yf-00
	for megaco@ietf.org; Thu, 15 Jan 2004 00:09:36 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1AgzlA-0000kH-E8
	for megaco@ietf.org; Thu, 15 Jan 2004 00:09:37 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id i0F2v9v05801;
	Thu, 15 Jan 2004 13:57:09 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.174]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5M22CY; Thu, 15 Jan 2004 13:58:04 +1100
Message-ID: <400601F8.9050508@ericsson.com>
Date: Thu, 15 Jan 2004 13:59:04 +1100
From: Christian Groves <Christian.Groves@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
CC: Dal Chohan <D.Chohan@ftel.co.uk>, Kevin Boyle <kboyle@nortelnetworks.com>
Subject: Re: [Megaco] H.248.1  generic package - signal completion event
References: <005f01c3d9c8$827a5e10$403010ac@DALLAPTOP> <400490A0.2010903@ericsson.com>
In-Reply-To: <400490A0.2010903@ericsson.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Resend due to error.

Christian Groves wrote:

> Hello Dal,
> 
> Yes this seems to be somewhere were the text can be improved. I would 
> actually propose to change 7.1.1 to 7.1.11. It looks like a '1' was 
> dropped off the reference.
> 
> Kevin could you please add this to your IG list?
> 
> Regards, Christian
> 
> Dal Chohan wrote:
> 
>> RE: H.248.1 E.1 Generic Package "Signal Completion" event
>>  
>> The package description suggests that the signal completion event can 
>> only be sent when the notifyCompletion parameter is included. However, 
>> clause 7.1.11 of H.248 version 2 indicates that a signal 
>> completion/termination event can be sent, even when the 
>> "notifyCompletion" parameter was not present in the situation the 
>> signal stopped and was never started for other reason (i.e. Meth = NC), .
>>  
>> In addition the package contains references to 7.1.1, 7.1.17 and 
>> 7.2.7, but no reference to "7.1.11 Signal Descriptor" where the 
>> procedures for signal completion are defined.
>>  
>>  
>> I guess a note in the IG should be included to take into account the 
>> above comments and re-word the text in the package to say something 
>> along the lines "Indicates the termination of a signal and is this 
>> event is sent as defined in the procedures of 7.1.11".
>>  
>>  
>>  
>> Dal Chohan
> 
> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan 15 03:52:38 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19807
	for <megaco-archive@lists.ietf.org>; Thu, 15 Jan 2004 03:52:38 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ah3EW-0004IG-6x; Thu, 15 Jan 2004 03:52:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ah3Ds-0004FS-Pc
	for megaco@optimus.ietf.org; Thu, 15 Jan 2004 03:51:28 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19802
	for <megaco@ietf.org>; Thu, 15 Jan 2004 03:51:27 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ah3Dq-00050y-00
	for megaco@ietf.org; Thu, 15 Jan 2004 03:51:26 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ah3Cr-0004tY-00
	for megaco@ietf.org; Thu, 15 Jan 2004 03:50:27 -0500
Received: from cisc01.iskratel.si ([193.2.48.125])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ah3Be-0004gF-00
	for megaco@ietf.org; Thu, 15 Jan 2004 03:49:10 -0500
Received: from ntmailkr.iskratel.si (ntmailkr.iskratel.si [10.1.2.90])
	by cisc01.iskratel.si (8.12.10/8.12.10) with ESMTP id i0F85MUi004776
	for <megaco@ietf.org>; Thu, 15 Jan 2004 09:05:23 +0100 (MET)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3DB3E.5E2136DE"
Date: Thu, 15 Jan 2004 09:05:41 +0100
Message-ID: <57D0409C9DC47A4B936406AC1788FA001E9BF8@ntmailkr.iskratel.si>
Thread-Topic: [Megaco] A question about H.248.6
Thread-Index: AcPbAZl5D7iz6u7dSbKY8umKsKpw0QAO+55Q
From: "Aljaz Tomaz    ITWEG" <aljaz@iskratel.si>
To: "MEGACO list" <megaco@ietf.org>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_50_60,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no 
	version=2.60
Subject: [Megaco] A question about # of simlutaneus sessions
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3DB3E.5E2136DE
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi!
Are any available H.248 packages that can limit the number of =
simultaneus sessions on MG like IP phone (MG IP phone). For example I =
would like to configure MG IP phone that can send/have only 2 =
simultaneus VoIP sessions.=20
=20
Best regards,
Tomaz


------_=_NextPart_001_01C3DB3E.5E2136DE
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<TITLE></TITLE>

<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR></HEAD>
<BODY hb_focus_attach=3D"true">
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D825415907-15012004>Hi!</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D825415907-15012004>Are=20
any available H.248 packages that can limit the number of simultaneus =
sessions=20
on MG like IP phone (MG IP phone). For example I would like to =
configure&nbsp;MG=20
IP phone that can send/have only 2 simultaneus VoIP sessions.=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D825415907-15012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D825415907-15012004>Best=20
regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D825415907-15012004>Tomaz</SPAN></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></DIV>
<P></P></BODY></HTML>

------_=_NextPart_001_01C3DB3E.5E2136DE--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan 15 04:09:46 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20485
	for <megaco-archive@odin.ietf.org>; Thu, 15 Jan 2004 04:09:46 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ah3V7-0006Aa-8H
	for megaco-archive@odin.ietf.org; Thu, 15 Jan 2004 04:09:17 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F99GcT023705
	for megaco-archive@odin.ietf.org; Thu, 15 Jan 2004 04:09:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ah3V6-0006AF-Kr
	for megaco-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 04:09:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20371
	for <megaco-web-archive@ietf.org>; Thu, 15 Jan 2004 04:09:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ah3V3-0005jN-00
	for megaco-web-archive@ietf.org; Thu, 15 Jan 2004 04:09:13 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ah3U3-0005ZD-00
	for megaco-web-archive@ietf.org; Thu, 15 Jan 2004 04:08:12 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ah3Sa-0005O4-01
	for megaco-web-archive@ietf.org; Thu, 15 Jan 2004 04:06:41 -0500
Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org)
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1Ah3EZ-0004sa-OZ
	for megaco-web-archive@ietf.org; Thu, 15 Jan 2004 03:52:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ah3EW-0004IG-6x; Thu, 15 Jan 2004 03:52:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ah3Ds-0004FS-Pc
	for megaco@optimus.ietf.org; Thu, 15 Jan 2004 03:51:28 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19802
	for <megaco@ietf.org>; Thu, 15 Jan 2004 03:51:27 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ah3Dq-00050y-00
	for megaco@ietf.org; Thu, 15 Jan 2004 03:51:26 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ah3Cr-0004tY-00
	for megaco@ietf.org; Thu, 15 Jan 2004 03:50:27 -0500
Received: from cisc01.iskratel.si ([193.2.48.125])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ah3Be-0004gF-00
	for megaco@ietf.org; Thu, 15 Jan 2004 03:49:10 -0500
Received: from ntmailkr.iskratel.si (ntmailkr.iskratel.si [10.1.2.90])
	by cisc01.iskratel.si (8.12.10/8.12.10) with ESMTP id i0F85MUi004776
	for <megaco@ietf.org>; Thu, 15 Jan 2004 09:05:23 +0100 (MET)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3DB3E.5E2136DE"
Date: Thu, 15 Jan 2004 09:05:41 +0100
Message-ID: <57D0409C9DC47A4B936406AC1788FA001E9BF8@ntmailkr.iskratel.si>
Thread-Topic: [Megaco] A question about H.248.6
Thread-Index: AcPbAZl5D7iz6u7dSbKY8umKsKpw0QAO+55Q
From: "Aljaz Tomaz    ITWEG" <aljaz@iskratel.si>
To: "MEGACO list" <megaco@ietf.org>
Subject: [Megaco] A question about # of simlutaneus sessions
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_50_60,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no 
	version=2.60

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3DB3E.5E2136DE
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi!
Are any available H.248 packages that can limit the number of =
simultaneus sessions on MG like IP phone (MG IP phone). For example I =
would like to configure MG IP phone that can send/have only 2 =
simultaneus VoIP sessions.=20
=20
Best regards,
Tomaz


------_=_NextPart_001_01C3DB3E.5E2136DE
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<TITLE></TITLE>

<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR></HEAD>
<BODY hb_focus_attach=3D"true">
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D825415907-15012004>Hi!</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D825415907-15012004>Are=20
any available H.248 packages that can limit the number of simultaneus =
sessions=20
on MG like IP phone (MG IP phone). For example I would like to =
configure&nbsp;MG=20
IP phone that can send/have only 2 simultaneus VoIP sessions.=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D825415907-15012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D825415907-15012004>Best=20
regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D825415907-15012004>Tomaz</SPAN></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></DIV>
<P></P></BODY></HTML>

------_=_NextPart_001_01C3DB3E.5E2136DE--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan 16 00:50:34 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18389
	for <megaco-archive@lists.ietf.org>; Fri, 16 Jan 2004 00:50:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhMrs-0003BM-1N; Fri, 16 Jan 2004 00:50:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhMqt-000393-Bn
	for megaco@optimus.ietf.org; Fri, 16 Jan 2004 00:49:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18350
	for <megaco@ietf.org>; Fri, 16 Jan 2004 00:48:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhMqq-00041j-00
	for megaco@ietf.org; Fri, 16 Jan 2004 00:49:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AhMpw-0003zQ-00
	for megaco@ietf.org; Fri, 16 Jan 2004 00:48:04 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhMp7-0003xB-00
	for megaco@ietf.org; Fri, 16 Jan 2004 00:47:13 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1AhMp4-0007Zq-AW
	for megaco@ietf.org; Fri, 16 Jan 2004 00:47:13 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id i0FMfOv03605;
	Fri, 16 Jan 2004 09:41:27 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.156]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5M2XDH; Fri, 16 Jan 2004 09:42:19 +1100
Message-ID: <40071783.7090808@ericsson.com>
Date: Fri, 16 Jan 2004 09:43:15 +1100
From: Christian Groves <Christian.Groves@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Aljaz Tomaz ITWEG <aljaz@iskratel.si>
CC: MEGACO list <megaco@ietf.org>
Subject: Re: [Megaco] A question about # of simlutaneus sessions
References: <57D0409C9DC47A4B936406AC1788FA001E9BF8@ntmailkr.iskratel.si>
In-Reply-To: <57D0409C9DC47A4B936406AC1788FA001E9BF8@ntmailkr.iskratel.si>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hello Tomaz,

Use the MaxNrOfContexts property from the base root package. Each VoIP will 
generate one context, thus to have a maximum of 2 sessions set this property to 2.

Regards, Christian

Aljaz Tomaz ITWEG wrote:

> Hi!
> Are any available H.248 packages that can limit the number of 
> simultaneus sessions on MG like IP phone (MG IP phone). For example I 
> would like to configure MG IP phone that can send/have only 2 
> simultaneus VoIP sessions.
>  
> Best regards,
> Tomaz
> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan 16 00:52:27 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18475
	for <megaco-archive@odin.ietf.org>; Fri, 16 Jan 2004 00:52:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhMtj-0003Nl-QZ
	for megaco-archive@odin.ietf.org; Fri, 16 Jan 2004 00:52:00 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0G5px4c012995
	for megaco-archive@odin.ietf.org; Fri, 16 Jan 2004 00:51:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhMtj-0003NW-Mv
	for megaco-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 00:51:59 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18437
	for <megaco-web-archive@ietf.org>; Fri, 16 Jan 2004 00:51:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhMtg-0004B7-00
	for megaco-web-archive@ietf.org; Fri, 16 Jan 2004 00:51:57 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AhMt0-00048C-00
	for megaco-web-archive@ietf.org; Fri, 16 Jan 2004 00:51:14 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhMrt-00045q-00
	for megaco-web-archive@ietf.org; Fri, 16 Jan 2004 00:50:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhMrs-0003BM-1N; Fri, 16 Jan 2004 00:50:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhMqt-000393-Bn
	for megaco@optimus.ietf.org; Fri, 16 Jan 2004 00:49:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18350
	for <megaco@ietf.org>; Fri, 16 Jan 2004 00:48:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhMqq-00041j-00
	for megaco@ietf.org; Fri, 16 Jan 2004 00:49:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AhMpw-0003zQ-00
	for megaco@ietf.org; Fri, 16 Jan 2004 00:48:04 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhMp7-0003xB-00
	for megaco@ietf.org; Fri, 16 Jan 2004 00:47:13 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1AhMp4-0007Zq-AW
	for megaco@ietf.org; Fri, 16 Jan 2004 00:47:13 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id i0FMfOv03605;
	Fri, 16 Jan 2004 09:41:27 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.156]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5M2XDH; Fri, 16 Jan 2004 09:42:19 +1100
Message-ID: <40071783.7090808@ericsson.com>
Date: Fri, 16 Jan 2004 09:43:15 +1100
From: Christian Groves <Christian.Groves@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Aljaz Tomaz ITWEG <aljaz@iskratel.si>
CC: MEGACO list <megaco@ietf.org>
Subject: Re: [Megaco] A question about # of simlutaneus sessions
References: <57D0409C9DC47A4B936406AC1788FA001E9BF8@ntmailkr.iskratel.si>
In-Reply-To: <57D0409C9DC47A4B936406AC1788FA001E9BF8@ntmailkr.iskratel.si>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello Tomaz,

Use the MaxNrOfContexts property from the base root package. Each VoIP will 
generate one context, thus to have a maximum of 2 sessions set this property to 2.

Regards, Christian

Aljaz Tomaz ITWEG wrote:

> Hi!
> Are any available H.248 packages that can limit the number of 
> simultaneus sessions on MG like IP phone (MG IP phone). For example I 
> would like to configure MG IP phone that can send/have only 2 
> simultaneus VoIP sessions.
>  
> Best regards,
> Tomaz
> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan 16 02:24:33 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03709
	for <megaco-archive@lists.ietf.org>; Fri, 16 Jan 2004 02:24:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhOKo-0001JP-Fb; Fri, 16 Jan 2004 02:24:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhOK6-0001Gk-Dp
	for megaco@optimus.ietf.org; Fri, 16 Jan 2004 02:23:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03556
	for <megaco@ietf.org>; Fri, 16 Jan 2004 02:23:15 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhOK2-0000oK-00
	for megaco@ietf.org; Fri, 16 Jan 2004 02:23:14 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AhOIw-0000la-00
	for megaco@ietf.org; Fri, 16 Jan 2004 02:22:06 -0500
Received: from cisc01.iskratel.si ([193.2.48.125])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhOIU-0000iR-00
	for megaco@ietf.org; Fri, 16 Jan 2004 02:21:38 -0500
Received: from ntmailkr.iskratel.si (ntmailkr.iskratel.si [10.1.2.90])
	by cisc01.iskratel.si (8.12.10/8.12.10) with ESMTP id i0G6oVUi020185;
	Fri, 16 Jan 2004 07:50:32 +0100 (MET)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Megaco] A question about # of simlutaneus sessions
Date: Fri, 16 Jan 2004 07:50:50 +0100
Message-ID: <57D0409C9DC47A4B936406AC1788FA001E9BFA@ntmailkr.iskratel.si>
Thread-Topic: [Megaco] A question about # of simlutaneus sessions
Thread-Index: AcPbuSNWyqBuuFw2Rte6C6o+b8WV8gAQtnNg
From: "Aljaz Tomaz    ITWEG" <aljaz@iskratel.si>
To: "Christian Groves" <Christian.Groves@ericsson.com>
Cc: "MEGACO list" <megaco@ietf.org>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Hello Christian,
Thanks for the answer.=20
I would like to little extend the issue about number of simultaneous =
sessions. With MaxNrOfContexts property I can limit number of contexts, =
but how can I limit the number of concurrent sessions in one =
termination. For example if you have middle-box and would like to limit =
the number of concurrent sessions from some terminal this can not be the =
right way or will be?

best regards,
Tomaz

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com]
Sent: Thursday, January 15, 2004 11:43 PM
To: Aljaz Tomaz ITWEG
Cc: MEGACO list
Subject: Re: [Megaco] A question about # of simlutaneus sessions


Hello Tomaz,

Use the MaxNrOfContexts property from the base root package. Each VoIP =
will=20
generate one context, thus to have a maximum of 2 sessions set this =
property to 2.

Regards, Christian

Aljaz Tomaz ITWEG wrote:

> Hi!
> Are any available H.248 packages that can limit the number of=20
> simultaneus sessions on MG like IP phone (MG IP phone). For example I=20
> would like to configure MG IP phone that can send/have only 2=20
> simultaneus VoIP sessions.
> =20
> Best regards,
> Tomaz
>=20


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan 16 02:26:33 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03862
	for <megaco-archive@odin.ietf.org>; Fri, 16 Jan 2004 02:26:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhOMn-0001VH-0p
	for megaco-archive@odin.ietf.org; Fri, 16 Jan 2004 02:26:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0G7Q47h005780
	for megaco-archive@odin.ietf.org; Fri, 16 Jan 2004 02:26:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhOMm-0001V9-L0
	for megaco-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 02:26:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03848
	for <megaco-web-archive@ietf.org>; Fri, 16 Jan 2004 02:26:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhOMi-0000vO-00
	for megaco-web-archive@ietf.org; Fri, 16 Jan 2004 02:26:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AhOLl-0000tI-00
	for megaco-web-archive@ietf.org; Fri, 16 Jan 2004 02:25:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhOKo-0000qs-00
	for megaco-web-archive@ietf.org; Fri, 16 Jan 2004 02:24:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhOKo-0001JP-Fb; Fri, 16 Jan 2004 02:24:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhOK6-0001Gk-Dp
	for megaco@optimus.ietf.org; Fri, 16 Jan 2004 02:23:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03556
	for <megaco@ietf.org>; Fri, 16 Jan 2004 02:23:15 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhOK2-0000oK-00
	for megaco@ietf.org; Fri, 16 Jan 2004 02:23:14 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AhOIw-0000la-00
	for megaco@ietf.org; Fri, 16 Jan 2004 02:22:06 -0500
Received: from cisc01.iskratel.si ([193.2.48.125])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhOIU-0000iR-00
	for megaco@ietf.org; Fri, 16 Jan 2004 02:21:38 -0500
Received: from ntmailkr.iskratel.si (ntmailkr.iskratel.si [10.1.2.90])
	by cisc01.iskratel.si (8.12.10/8.12.10) with ESMTP id i0G6oVUi020185;
	Fri, 16 Jan 2004 07:50:32 +0100 (MET)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Megaco] A question about # of simlutaneus sessions
Date: Fri, 16 Jan 2004 07:50:50 +0100
Message-ID: <57D0409C9DC47A4B936406AC1788FA001E9BFA@ntmailkr.iskratel.si>
Thread-Topic: [Megaco] A question about # of simlutaneus sessions
Thread-Index: AcPbuSNWyqBuuFw2Rte6C6o+b8WV8gAQtnNg
From: "Aljaz Tomaz    ITWEG" <aljaz@iskratel.si>
To: "Christian Groves" <Christian.Groves@ericsson.com>
Cc: "MEGACO list" <megaco@ietf.org>
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hello Christian,
Thanks for the answer.=20
I would like to little extend the issue about number of simultaneous =
sessions. With MaxNrOfContexts property I can limit number of contexts, =
but how can I limit the number of concurrent sessions in one =
termination. For example if you have middle-box and would like to limit =
the number of concurrent sessions from some terminal this can not be the =
right way or will be?

best regards,
Tomaz

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com]
Sent: Thursday, January 15, 2004 11:43 PM
To: Aljaz Tomaz ITWEG
Cc: MEGACO list
Subject: Re: [Megaco] A question about # of simlutaneus sessions


Hello Tomaz,

Use the MaxNrOfContexts property from the base root package. Each VoIP =
will=20
generate one context, thus to have a maximum of 2 sessions set this =
property to 2.

Regards, Christian

Aljaz Tomaz ITWEG wrote:

> Hi!
> Are any available H.248 packages that can limit the number of=20
> simultaneus sessions on MG like IP phone (MG IP phone). For example I=20
> would like to configure MG IP phone that can send/have only 2=20
> simultaneus VoIP sessions.
> =20
> Best regards,
> Tomaz
>=20


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Sat Jan 17 09:10:38 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07898
	for <megaco-archive@lists.ietf.org>; Sat, 17 Jan 2004 09:10:38 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ahr9H-0004U9-HQ; Sat, 17 Jan 2004 09:10:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ahr8z-0004TS-S2
	for megaco@optimus.ietf.org; Sat, 17 Jan 2004 09:09:45 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07886
	for <megaco@ietf.org>; Sat, 17 Jan 2004 09:09:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ahr8t-0002iE-00
	for megaco@ietf.org; Sat, 17 Jan 2004 09:09:39 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ahr5N-0002bk-00
	for megaco@ietf.org; Sat, 17 Jan 2004 09:06:01 -0500
Received: from web40510.mail.yahoo.com ([66.218.78.127])
	by ietf-mx with smtp (Exim 4.12)
	id 1Ahr47-0002UE-00
	for megaco@ietf.org; Sat, 17 Jan 2004 09:04:43 -0500
Message-ID: <20040117140344.83683.qmail@web40510.mail.yahoo.com>
Received: from [202.138.120.38] by web40510.mail.yahoo.com via HTTP; Sat, 17 Jan 2004 06:03:44 PST
Date: Sat, 17 Jan 2004 06:03:44 -0800 (PST)
From: "BALKI\(RELIANCE\)" <mailtobalki@yahoo.com>
To: megaco@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Subject: [Megaco] hi friends
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

hi all,
     hi i'm new to this group.  actually i dont know anything about
MEGACO.  but i'm very much interested to know abt MEGACO.  will anyone
of u pls tell me what exactly is MEGACO. 
      whether all the functions like detection of
onhook,offhook,sending dial tone,sensing whether the digit is pressed
,sending ringtone etc is done by MEGACO or MG?  what is the exact
communication between MGC and MG? this is my main doubt.  whether
MEGACO is used in our telephone exchange like BSNL or is it used for
doing voice chat,video conferencing etc.  this is my greeat doubt.  
     i'm expecting a early reply from u ppls.  bye.  

=====

Thanks & regards,

Balakrishnan.R



__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Sat Jan 17 09:16:50 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08018
	for <megaco-archive@odin.ietf.org>; Sat, 17 Jan 2004 09:16:50 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhrFO-0004sw-Tf
	for megaco-archive@odin.ietf.org; Sat, 17 Jan 2004 09:16:23 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0HEGMIW018774
	for megaco-archive@odin.ietf.org; Sat, 17 Jan 2004 09:16:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhrFO-0004sj-NU
	for megaco-web-archive@optimus.ietf.org; Sat, 17 Jan 2004 09:16:22 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08008
	for <megaco-web-archive@ietf.org>; Sat, 17 Jan 2004 09:16:20 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhrFI-00033s-00
	for megaco-web-archive@ietf.org; Sat, 17 Jan 2004 09:16:16 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AhrCc-0002u6-00
	for megaco-web-archive@ietf.org; Sat, 17 Jan 2004 09:13:31 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ahr9d-0002lC-00
	for megaco-web-archive@ietf.org; Sat, 17 Jan 2004 09:10:25 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ahr9H-0004U9-HQ; Sat, 17 Jan 2004 09:10:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ahr8z-0004TS-S2
	for megaco@optimus.ietf.org; Sat, 17 Jan 2004 09:09:45 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07886
	for <megaco@ietf.org>; Sat, 17 Jan 2004 09:09:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ahr8t-0002iE-00
	for megaco@ietf.org; Sat, 17 Jan 2004 09:09:39 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ahr5N-0002bk-00
	for megaco@ietf.org; Sat, 17 Jan 2004 09:06:01 -0500
Received: from web40510.mail.yahoo.com ([66.218.78.127])
	by ietf-mx with smtp (Exim 4.12)
	id 1Ahr47-0002UE-00
	for megaco@ietf.org; Sat, 17 Jan 2004 09:04:43 -0500
Message-ID: <20040117140344.83683.qmail@web40510.mail.yahoo.com>
Received: from [202.138.120.38] by web40510.mail.yahoo.com via HTTP; Sat, 17 Jan 2004 06:03:44 PST
Date: Sat, 17 Jan 2004 06:03:44 -0800 (PST)
From: "BALKI\(RELIANCE\)" <mailtobalki@yahoo.com>
To: megaco@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [Megaco] hi friends
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

hi all,
     hi i'm new to this group.  actually i dont know anything about
MEGACO.  but i'm very much interested to know abt MEGACO.  will anyone
of u pls tell me what exactly is MEGACO. 
      whether all the functions like detection of
onhook,offhook,sending dial tone,sensing whether the digit is pressed
,sending ringtone etc is done by MEGACO or MG?  what is the exact
communication between MGC and MG? this is my main doubt.  whether
MEGACO is used in our telephone exchange like BSNL or is it used for
doing voice chat,video conferencing etc.  this is my greeat doubt.  
     i'm expecting a early reply from u ppls.  bye.  

=====

Thanks & regards,

Balakrishnan.R



__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Sat Jan 17 10:07:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08911
	for <megaco-archive@lists.ietf.org>; Sat, 17 Jan 2004 10:07:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ahs2P-00010G-D9; Sat, 17 Jan 2004 10:07:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ahs21-0000wb-Nu
	for megaco@optimus.ietf.org; Sat, 17 Jan 2004 10:06:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08852
	for <megaco@ietf.org>; Sat, 17 Jan 2004 10:06:24 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ahs1k-0004nB-00
	for megaco@ietf.org; Sat, 17 Jan 2004 10:06:20 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AhrzV-0004jL-00
	for megaco@ietf.org; Sat, 17 Jan 2004 10:04:02 -0500
Received: from zcars04e.nortelnetworks.com ([47.129.242.56])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ahrxc-0004de-00
	for megaco@ietf.org; Sat, 17 Jan 2004 10:02:04 -0500
Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67])
	by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0HF0iV29400;
	Sat, 17 Jan 2004 10:00:44 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id ZMG3CRYB; Sat, 17 Jan 2004 10:00:43 -0500
Received: from nortelnetworks.com (acart1hy.ca.nortel.com [47.129.129.239]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DBDZ2862; Sat, 17 Jan 2004 10:00:44 -0500
Message-ID: <40094E1B.1030608@nortelnetworks.com>
Date: Sat, 17 Jan 2004 10:00:43 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Aljaz Tomaz ITWEG <aljaz@iskratel.si>
CC: Christian Groves <Christian.Groves@ericsson.com>,
        MEGACO list <megaco@ietf.org>
Subject: Re: [Megaco] A question about # of simlutaneus sessions
References: <57D0409C9DC47A4B936406AC1788FA001E9BFA@ntmailkr.iskratel.si>
In-Reply-To: <57D0409C9DC47A4B936406AC1788FA001E9BFA@ntmailkr.iskratel.si>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

A given termination can be in only one context at once.  Is that your question?

Aljaz Tomaz ITWEG wrote:
> Hello Christian,
> Thanks for the answer. 
> I would like to little extend the issue about number of simultaneous sessions. With MaxNrOfContexts property I can limit number of contexts, but how can I limit the number of concurrent sessions in one termination. For example if you have middle-box and would like to limit the number of concurrent sessions from some terminal this can not be the right way or will be?
> 
> best regards,
> Tomaz
> 
> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Thursday, January 15, 2004 11:43 PM
> To: Aljaz Tomaz ITWEG
> Cc: MEGACO list
> Subject: Re: [Megaco] A question about # of simlutaneus sessions
> 
> 
> Hello Tomaz,
> 
> Use the MaxNrOfContexts property from the base root package. Each VoIP will 
> generate one context, thus to have a maximum of 2 sessions set this property to 2.
> 
> Regards, Christian
> 
> Aljaz Tomaz ITWEG wrote:
> 
> 
>>Hi!
>>Are any available H.248 packages that can limit the number of 
>>simultaneus sessions on MG like IP phone (MG IP phone). For example I 
>>would like to configure MG IP phone that can send/have only 2 
>>simultaneus VoIP sessions.
>> 
>>Best regards,
>>Tomaz
>>
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Sat Jan 17 10:14:13 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09467
	for <megaco-archive@odin.ietf.org>; Sat, 17 Jan 2004 10:14:13 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ahs64-0002Cm-O6
	for megaco-archive@odin.ietf.org; Sat, 17 Jan 2004 10:10:53 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0HFAmHp008470
	for megaco-archive@odin.ietf.org; Sat, 17 Jan 2004 10:10:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ahs64-0002CW-Im
	for megaco-web-archive@optimus.ietf.org; Sat, 17 Jan 2004 10:10:48 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09171
	for <megaco-web-archive@ietf.org>; Sat, 17 Jan 2004 10:10:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ahs5x-0004wd-00
	for megaco-web-archive@ietf.org; Sat, 17 Jan 2004 10:10:41 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ahs3k-0004rh-00
	for megaco-web-archive@ietf.org; Sat, 17 Jan 2004 10:08:25 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ahs2i-0004op-00
	for megaco-web-archive@ietf.org; Sat, 17 Jan 2004 10:07:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ahs2P-00010G-D9; Sat, 17 Jan 2004 10:07:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ahs21-0000wb-Nu
	for megaco@optimus.ietf.org; Sat, 17 Jan 2004 10:06:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08852
	for <megaco@ietf.org>; Sat, 17 Jan 2004 10:06:24 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ahs1k-0004nB-00
	for megaco@ietf.org; Sat, 17 Jan 2004 10:06:20 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AhrzV-0004jL-00
	for megaco@ietf.org; Sat, 17 Jan 2004 10:04:02 -0500
Received: from zcars04e.nortelnetworks.com ([47.129.242.56])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ahrxc-0004de-00
	for megaco@ietf.org; Sat, 17 Jan 2004 10:02:04 -0500
Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67])
	by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0HF0iV29400;
	Sat, 17 Jan 2004 10:00:44 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id ZMG3CRYB; Sat, 17 Jan 2004 10:00:43 -0500
Received: from nortelnetworks.com (acart1hy.ca.nortel.com [47.129.129.239]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DBDZ2862; Sat, 17 Jan 2004 10:00:44 -0500
Message-ID: <40094E1B.1030608@nortelnetworks.com>
Date: Sat, 17 Jan 2004 10:00:43 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Aljaz Tomaz ITWEG <aljaz@iskratel.si>
CC: Christian Groves <Christian.Groves@ericsson.com>,
        MEGACO list <megaco@ietf.org>
Subject: Re: [Megaco] A question about # of simlutaneus sessions
References: <57D0409C9DC47A4B936406AC1788FA001E9BFA@ntmailkr.iskratel.si>
In-Reply-To: <57D0409C9DC47A4B936406AC1788FA001E9BFA@ntmailkr.iskratel.si>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

A given termination can be in only one context at once.  Is that your question?

Aljaz Tomaz ITWEG wrote:
> Hello Christian,
> Thanks for the answer. 
> I would like to little extend the issue about number of simultaneous sessions. With MaxNrOfContexts property I can limit number of contexts, but how can I limit the number of concurrent sessions in one termination. For example if you have middle-box and would like to limit the number of concurrent sessions from some terminal this can not be the right way or will be?
> 
> best regards,
> Tomaz
> 
> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Thursday, January 15, 2004 11:43 PM
> To: Aljaz Tomaz ITWEG
> Cc: MEGACO list
> Subject: Re: [Megaco] A question about # of simlutaneus sessions
> 
> 
> Hello Tomaz,
> 
> Use the MaxNrOfContexts property from the base root package. Each VoIP will 
> generate one context, thus to have a maximum of 2 sessions set this property to 2.
> 
> Regards, Christian
> 
> Aljaz Tomaz ITWEG wrote:
> 
> 
>>Hi!
>>Are any available H.248 packages that can limit the number of 
>>simultaneus sessions on MG like IP phone (MG IP phone). For example I 
>>would like to configure MG IP phone that can send/have only 2 
>>simultaneus VoIP sessions.
>> 
>>Best regards,
>>Tomaz
>>
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Sat Jan 17 18:00:39 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16736
	for <megaco-archive@lists.ietf.org>; Sat, 17 Jan 2004 18:00:38 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhzQF-0004nr-W4; Sat, 17 Jan 2004 18:00:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhzPG-0004Y8-VS
	for megaco@optimus.ietf.org; Sat, 17 Jan 2004 17:59:17 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15792
	for <megaco@ietf.org>; Sat, 17 Jan 2004 17:58:57 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ahy25-0003lF-00
	for megaco@ietf.org; Sat, 17 Jan 2004 16:31:05 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ahy0p-0003SA-00
	for megaco@ietf.org; Sat, 17 Jan 2004 16:29:48 -0500
Received: from cisc01.iskratel.si ([193.2.48.125])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhxyY-0003DX-00
	for megaco@ietf.org; Sat, 17 Jan 2004 16:27:26 -0500
Received: from ntmailkr.iskratel.si (ntmailkr.iskratel.si [10.1.2.90])
	by cisc01.iskratel.si (8.12.10/8.12.10) with ESMTP id i0HLPrUi022584;
	Sat, 17 Jan 2004 22:25:53 +0100 (MET)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Megaco] A question about # of simlutaneus sessions
Date: Sat, 17 Jan 2004 22:26:11 +0100
Message-ID: <57D0409C9DC47A4B936406AC1788FA00BB081E@ntmailkr.iskratel.si>
Thread-Topic: [Megaco] A question about # of simlutaneus sessions
Thread-Index: AcPdCrZ2FDP8D7kwTvuRj9bXJtA9rAANZ4zA
From: "Aljaz Tomaz    ITWEG" <aljaz@iskratel.si>
To: "Tom Taylor" <taylor@nortelnetworks.com>
Cc: "Christian Groves" <Christian.Groves@ericsson.com>,
        "MEGACO list" <megaco@ietf.org>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Yes, termination can only be in only one context at one.

Best regards,
Tomaz

-----Original Message-----
From: Tom Taylor [mailto:taylor@nortelnetworks.com]
Sent: Saturday, January 17, 2004 4:01 PM
To: Aljaz Tomaz ITWEG
Cc: Christian Groves; MEGACO list
Subject: Re: [Megaco] A question about # of simlutaneus sessions


A given termination can be in only one context at once.  Is that your =
question?

Aljaz Tomaz ITWEG wrote:
> Hello Christian,
> Thanks for the answer.=20
> I would like to little extend the issue about number of simultaneous =
sessions. With MaxNrOfContexts property I can limit number of contexts, =
but how can I limit the number of concurrent sessions in one =
termination. For example if you have middle-box and would like to limit =
the number of concurrent sessions from some terminal this can not be the =
right way or will be?
>=20
> best regards,
> Tomaz
>=20
> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Thursday, January 15, 2004 11:43 PM
> To: Aljaz Tomaz ITWEG
> Cc: MEGACO list
> Subject: Re: [Megaco] A question about # of simlutaneus sessions
>=20
>=20
> Hello Tomaz,
>=20
> Use the MaxNrOfContexts property from the base root package. Each VoIP =
will=20
> generate one context, thus to have a maximum of 2 sessions set this =
property to 2.
>=20
> Regards, Christian
>=20
> Aljaz Tomaz ITWEG wrote:
>=20
>=20
>>Hi!
>>Are any available H.248 packages that can limit the number of=20
>>simultaneus sessions on MG like IP phone (MG IP phone). For example I=20
>>would like to configure MG IP phone that can send/have only 2=20
>>simultaneus VoIP sessions.
>>=20
>>Best regards,
>>Tomaz
>>
>=20
>=20
>=20
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>=20


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Sat Jan 17 18:19:13 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19760
	for <megaco-archive@odin.ietf.org>; Sat, 17 Jan 2004 18:19:13 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhziJ-0003pD-AE
	for megaco-archive@odin.ietf.org; Sat, 17 Jan 2004 18:18:47 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0HNIlE9014697
	for megaco-archive@odin.ietf.org; Sat, 17 Jan 2004 18:18:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhziI-0003oo-Vc
	for megaco-web-archive@optimus.ietf.org; Sat, 17 Jan 2004 18:18:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19560
	for <megaco-web-archive@ietf.org>; Sat, 17 Jan 2004 18:18:37 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ahzaq-0001P9-00
	for megaco-web-archive@ietf.org; Sat, 17 Jan 2004 18:11:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AhzUJ-0000iA-00
	for megaco-web-archive@ietf.org; Sat, 17 Jan 2004 18:04:20 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhzQS-0007bl-00
	for megaco-web-archive@ietf.org; Sat, 17 Jan 2004 18:00:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhzQF-0004nr-W4; Sat, 17 Jan 2004 18:00:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhzPG-0004Y8-VS
	for megaco@optimus.ietf.org; Sat, 17 Jan 2004 17:59:17 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15792
	for <megaco@ietf.org>; Sat, 17 Jan 2004 17:58:57 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ahy25-0003lF-00
	for megaco@ietf.org; Sat, 17 Jan 2004 16:31:05 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ahy0p-0003SA-00
	for megaco@ietf.org; Sat, 17 Jan 2004 16:29:48 -0500
Received: from cisc01.iskratel.si ([193.2.48.125])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhxyY-0003DX-00
	for megaco@ietf.org; Sat, 17 Jan 2004 16:27:26 -0500
Received: from ntmailkr.iskratel.si (ntmailkr.iskratel.si [10.1.2.90])
	by cisc01.iskratel.si (8.12.10/8.12.10) with ESMTP id i0HLPrUi022584;
	Sat, 17 Jan 2004 22:25:53 +0100 (MET)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Megaco] A question about # of simlutaneus sessions
Date: Sat, 17 Jan 2004 22:26:11 +0100
Message-ID: <57D0409C9DC47A4B936406AC1788FA00BB081E@ntmailkr.iskratel.si>
Thread-Topic: [Megaco] A question about # of simlutaneus sessions
Thread-Index: AcPdCrZ2FDP8D7kwTvuRj9bXJtA9rAANZ4zA
From: "Aljaz Tomaz    ITWEG" <aljaz@iskratel.si>
To: "Tom Taylor" <taylor@nortelnetworks.com>
Cc: "Christian Groves" <Christian.Groves@ericsson.com>,
        "MEGACO list" <megaco@ietf.org>
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Yes, termination can only be in only one context at one.

Best regards,
Tomaz

-----Original Message-----
From: Tom Taylor [mailto:taylor@nortelnetworks.com]
Sent: Saturday, January 17, 2004 4:01 PM
To: Aljaz Tomaz ITWEG
Cc: Christian Groves; MEGACO list
Subject: Re: [Megaco] A question about # of simlutaneus sessions


A given termination can be in only one context at once.  Is that your =
question?

Aljaz Tomaz ITWEG wrote:
> Hello Christian,
> Thanks for the answer.=20
> I would like to little extend the issue about number of simultaneous =
sessions. With MaxNrOfContexts property I can limit number of contexts, =
but how can I limit the number of concurrent sessions in one =
termination. For example if you have middle-box and would like to limit =
the number of concurrent sessions from some terminal this can not be the =
right way or will be?
>=20
> best regards,
> Tomaz
>=20
> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Thursday, January 15, 2004 11:43 PM
> To: Aljaz Tomaz ITWEG
> Cc: MEGACO list
> Subject: Re: [Megaco] A question about # of simlutaneus sessions
>=20
>=20
> Hello Tomaz,
>=20
> Use the MaxNrOfContexts property from the base root package. Each VoIP =
will=20
> generate one context, thus to have a maximum of 2 sessions set this =
property to 2.
>=20
> Regards, Christian
>=20
> Aljaz Tomaz ITWEG wrote:
>=20
>=20
>>Hi!
>>Are any available H.248 packages that can limit the number of=20
>>simultaneus sessions on MG like IP phone (MG IP phone). For example I=20
>>would like to configure MG IP phone that can send/have only 2=20
>>simultaneus VoIP sessions.
>>=20
>>Best regards,
>>Tomaz
>>
>=20
>=20
>=20
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>=20


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Sun Jan 18 19:58:37 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10043
	for <megaco-archive@lists.ietf.org>; Sun, 18 Jan 2004 19:58:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AiNjt-0006jt-Cm; Sun, 18 Jan 2004 19:58:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AiNj1-0006j0-22
	for megaco@optimus.ietf.org; Sun, 18 Jan 2004 19:57:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10007
	for <megaco@ietf.org>; Sun, 18 Jan 2004 19:57:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AiNiy-0003bW-00
	for megaco@ietf.org; Sun, 18 Jan 2004 19:57:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AiNi1-0003Zs-00
	for megaco@ietf.org; Sun, 18 Jan 2004 19:56:06 -0500
Received: from smtp-27.ig.com.br ([200.226.132.159])
	by ietf-mx with smtp (Exim 4.12)
	id 1AiNhC-0003Wi-00
	for megaco@ietf.org; Sun, 18 Jan 2004 19:55:14 -0500
Received: (qmail 8678 invoked from network); 19 Jan 2004 00:54:46 -0000
Received: from unknown (HELO tipkpfqazswj71) (200.151.224.92)
  by smtp-27.ig.com.br with SMTP; 19 Jan 2004 00:54:46 -0000
Message-ID: <00cb01c3de26$f467e940$1ca897c8@tipkpfqazswj71>
From: "luka" <luka682@ig.com.br>
To: <megaco@ietf.org>
Date: Sun, 18 Jan 2004 22:55:13 -0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00C6_01C3DE16.21F46F20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS,
	HTML_50_60,HTML_MESSAGE autolearn=no version=2.60
Subject: [Megaco] Megaco/h.248
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00C6_01C3DE16.21F46F20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi, folks.

I am doing an article about Megaco and I=B4d like to get information =
about Set-top Box.
How does Set-top Box work?=20
What are the Megaco commands used in this application? ( between MG and =
MGC)=20


Could you tell me where I  get this information from Internet?  =20

Thanks a lot

Luka
   
------=_NextPart_000_00C6_01C3DE16.21F46F20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1264" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi, folks.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I am doing an article about Megaco =
and&nbsp;I=B4d=20
like to get&nbsp;information&nbsp;<FONT size=3D3><FONT=20
face=3D"Times New Roman">about<STRONG> Set-top=20
Box.</STRONG></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>How does Set-top Box work? =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>What are the Megaco commands =
used&nbsp;in this=20
application?&nbsp;( between MG and MGC)&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Could you tell me where =
I&nbsp;&nbsp;get this=20
information&nbsp;from Internet?&nbsp;&nbsp;&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks a lot</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Luka</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;</FONT></DIV></BODY></HTML>

------=_NextPart_000_00C6_01C3DE16.21F46F20--



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Sun Jan 18 20:00:39 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10118
	for <megaco-archive@odin.ietf.org>; Sun, 18 Jan 2004 20:00:39 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AiNly-0006uA-C5
	for megaco-archive@odin.ietf.org; Sun, 18 Jan 2004 20:00:10 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0J10Awx026541
	for megaco-archive@odin.ietf.org; Sun, 18 Jan 2004 20:00:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AiNly-0006u0-6j
	for megaco-web-archive@optimus.ietf.org; Sun, 18 Jan 2004 20:00:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10096
	for <megaco-web-archive@ietf.org>; Sun, 18 Jan 2004 20:00:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AiNlv-0003ia-00
	for megaco-web-archive@ietf.org; Sun, 18 Jan 2004 20:00:07 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AiNkx-0003fz-00
	for megaco-web-archive@ietf.org; Sun, 18 Jan 2004 19:59:08 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AiNjz-0003dl-00
	for megaco-web-archive@ietf.org; Sun, 18 Jan 2004 19:58:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AiNjt-0006jt-Cm; Sun, 18 Jan 2004 19:58:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AiNj1-0006j0-22
	for megaco@optimus.ietf.org; Sun, 18 Jan 2004 19:57:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10007
	for <megaco@ietf.org>; Sun, 18 Jan 2004 19:57:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AiNiy-0003bW-00
	for megaco@ietf.org; Sun, 18 Jan 2004 19:57:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AiNi1-0003Zs-00
	for megaco@ietf.org; Sun, 18 Jan 2004 19:56:06 -0500
Received: from smtp-27.ig.com.br ([200.226.132.159])
	by ietf-mx with smtp (Exim 4.12)
	id 1AiNhC-0003Wi-00
	for megaco@ietf.org; Sun, 18 Jan 2004 19:55:14 -0500
Received: (qmail 8678 invoked from network); 19 Jan 2004 00:54:46 -0000
Received: from unknown (HELO tipkpfqazswj71) (200.151.224.92)
  by smtp-27.ig.com.br with SMTP; 19 Jan 2004 00:54:46 -0000
Message-ID: <00cb01c3de26$f467e940$1ca897c8@tipkpfqazswj71>
From: "luka" <luka682@ig.com.br>
To: <megaco@ietf.org>
Date: Sun, 18 Jan 2004 22:55:13 -0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00C6_01C3DE16.21F46F20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Subject: [Megaco] Megaco/h.248
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS,
	HTML_50_60,HTML_MESSAGE autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_00C6_01C3DE16.21F46F20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi, folks.

I am doing an article about Megaco and I=B4d like to get information =
about Set-top Box.
How does Set-top Box work?=20
What are the Megaco commands used in this application? ( between MG and =
MGC)=20


Could you tell me where I  get this information from Internet?  =20

Thanks a lot

Luka
   
------=_NextPart_000_00C6_01C3DE16.21F46F20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1264" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi, folks.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I am doing an article about Megaco =
and&nbsp;I=B4d=20
like to get&nbsp;information&nbsp;<FONT size=3D3><FONT=20
face=3D"Times New Roman">about<STRONG> Set-top=20
Box.</STRONG></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>How does Set-top Box work? =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>What are the Megaco commands =
used&nbsp;in this=20
application?&nbsp;( between MG and MGC)&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Could you tell me where =
I&nbsp;&nbsp;get this=20
information&nbsp;from Internet?&nbsp;&nbsp;&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks a lot</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Luka</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;</FONT></DIV></BODY></HTML>

------=_NextPart_000_00C6_01C3DE16.21F46F20--



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Jan 19 10:08:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19312
	for <megaco-archive@lists.ietf.org>; Mon, 19 Jan 2004 10:08:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aib0T-0004Oc-Li; Mon, 19 Jan 2004 10:08:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AiazZ-0003lG-A6
	for megaco@optimus.ietf.org; Mon, 19 Jan 2004 10:07:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19270
	for <megaco@ietf.org>; Mon, 19 Jan 2004 10:06:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AiazM-00025o-00
	for megaco@ietf.org; Mon, 19 Jan 2004 10:06:52 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AiawG-0001yi-00
	for megaco@ietf.org; Mon, 19 Jan 2004 10:03:40 -0500
Received: from zcars04e.nortelnetworks.com ([47.129.242.56])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AiavK-0001tI-00
	for megaco@ietf.org; Mon, 19 Jan 2004 10:02:42 -0500
Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67])
	by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0JF1fm00763;
	Mon, 19 Jan 2004 10:01:41 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id ZMG3103F; Mon, 19 Jan 2004 10:01:41 -0500
Received: from nortelnetworks.com (acart1h8.ca.nortel.com [47.129.129.216]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DBDZ29GZ; Mon, 19 Jan 2004 10:01:41 -0500
Message-ID: <400BF154.9070806@nortelnetworks.com>
Date: Mon, 19 Jan 2004 10:01:40 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: luka <luka682@ig.com.br>
CC: megaco@ietf.org
Subject: Re: [Megaco] Megaco/h.248
References: <00cb01c3de26$f467e940$1ca897c8@tipkpfqazswj71>
In-Reply-To: <00cb01c3de26$f467e940$1ca897c8@tipkpfqazswj71>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04e.nortelnetworks.com id i0JF1fm00763
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

The obvious starting point is the PacketCable work on telephony over cabl=
e.  You=20
can get their specifications at http://www.packetcable.com/specifications=
/, and=20
the specification for the set-top box control in particular at=20
http://www.packetcable.com/downloads/specs/PKT-SP-MGCP-I09-040113.pdf

Unfortunately from the Megaco point of view, PacketCable chose to go with=
 MGCP=20
rather than Megaco as the basis of their control protocol.

luka wrote:

> Hi, folks.
> =20
> I am doing an article about Megaco and I=B4d like to=20
> get information about* Set-top Box.*
> How does Set-top Box work?
> What are the Megaco commands used in this application? ( between MG and=
=20
> MGC)=20
> =20
> =20
> Could you tell me where I  get this information from Internet?  =20
> =20
> Thanks a lot
> =20
> Luka
>   =20


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Mon Jan 19 10:14:36 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19603
	for <megaco-archive@odin.ietf.org>; Mon, 19 Jan 2004 10:14:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aib6K-0000yR-Jb
	for megaco-archive@odin.ietf.org; Mon, 19 Jan 2004 10:14:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JFE4XC003740
	for megaco-archive@odin.ietf.org; Mon, 19 Jan 2004 10:14:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aib6G-0000y7-6e
	for megaco-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 10:14:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19552
	for <megaco-web-archive@ietf.org>; Mon, 19 Jan 2004 10:13:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aib69-0002Vs-00
	for megaco-web-archive@ietf.org; Mon, 19 Jan 2004 10:13:53 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aib3z-0002ME-00
	for megaco-web-archive@ietf.org; Mon, 19 Jan 2004 10:11:41 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aib0o-0002CN-00
	for megaco-web-archive@ietf.org; Mon, 19 Jan 2004 10:08:22 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aib0T-0004Oc-Li; Mon, 19 Jan 2004 10:08:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AiazZ-0003lG-A6
	for megaco@optimus.ietf.org; Mon, 19 Jan 2004 10:07:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19270
	for <megaco@ietf.org>; Mon, 19 Jan 2004 10:06:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AiazM-00025o-00
	for megaco@ietf.org; Mon, 19 Jan 2004 10:06:52 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AiawG-0001yi-00
	for megaco@ietf.org; Mon, 19 Jan 2004 10:03:40 -0500
Received: from zcars04e.nortelnetworks.com ([47.129.242.56])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AiavK-0001tI-00
	for megaco@ietf.org; Mon, 19 Jan 2004 10:02:42 -0500
Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67])
	by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0JF1fm00763;
	Mon, 19 Jan 2004 10:01:41 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id ZMG3103F; Mon, 19 Jan 2004 10:01:41 -0500
Received: from nortelnetworks.com (acart1h8.ca.nortel.com [47.129.129.216]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DBDZ29GZ; Mon, 19 Jan 2004 10:01:41 -0500
Message-ID: <400BF154.9070806@nortelnetworks.com>
Date: Mon, 19 Jan 2004 10:01:40 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: luka <luka682@ig.com.br>
CC: megaco@ietf.org
Subject: Re: [Megaco] Megaco/h.248
References: <00cb01c3de26$f467e940$1ca897c8@tipkpfqazswj71>
In-Reply-To: <00cb01c3de26$f467e940$1ca897c8@tipkpfqazswj71>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04e.nortelnetworks.com id i0JF1fm00763
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

The obvious starting point is the PacketCable work on telephony over cabl=
e.  You=20
can get their specifications at http://www.packetcable.com/specifications=
/, and=20
the specification for the set-top box control in particular at=20
http://www.packetcable.com/downloads/specs/PKT-SP-MGCP-I09-040113.pdf

Unfortunately from the Megaco point of view, PacketCable chose to go with=
 MGCP=20
rather than Megaco as the basis of their control protocol.

luka wrote:

> Hi, folks.
> =20
> I am doing an article about Megaco and I=B4d like to=20
> get information about* Set-top Box.*
> How does Set-top Box work?
> What are the Megaco commands used in this application? ( between MG and=
=20
> MGC)=20
> =20
> =20
> Could you tell me where I  get this information from Internet?  =20
> =20
> Thanks a lot
> =20
> Luka
>   =20


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan 21 15:23:31 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06345
	for <megaco-archive@lists.ietf.org>; Wed, 21 Jan 2004 15:23:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjOsP-0006oV-IG; Wed, 21 Jan 2004 15:23:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjOro-0006U1-47
	for megaco@optimus.ietf.org; Wed, 21 Jan 2004 15:22:24 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06273
	for <megaco@ietf.org>; Wed, 21 Jan 2004 15:22:22 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjOrm-0007hs-00
	for megaco@ietf.org; Wed, 21 Jan 2004 15:22:22 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjOqr-0007fZ-00
	for megaco@ietf.org; Wed, 21 Jan 2004 15:21:25 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjOqc-0007cr-00
	for megaco@ietf.org; Wed, 21 Jan 2004 15:21:10 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 21 Jan 2004 12:24:48 +0000
Received: from SAMPATHKW2K03 (dhcp-171-71-248-129.cisco.com [171.71.248.129])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0LKKbff024788
	for <megaco@ietf.org>; Wed, 21 Jan 2004 12:20:38 -0800 (PST)
Reply-To: <sampathk@cisco.com>
From: "Sampath Komanduri" <sampathk@cisco.com>
To: <megaco@ietf.org>
Date: Wed, 21 Jan 2004 12:20:37 -0800
Organization: Cisco Systems
Message-ID: <001c01c3e05c$087bccd0$81f847ab@SAMPATHKW2K03>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001D_01C3E018.FA588CD0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
In-Reply-To: <400BF154.9070806@nortelnetworks.com>
Importance: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE 
	autolearn=no version=2.60
Subject: [Megaco] Can chp/mgcon event be persistent event?
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_001D_01C3E018.FA588CD0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi all,
It was my understanding that Megaco doesn't allow any persistent events.
If my understanding is correct... Could someone pls. clarify what the
following paragraph in H.248.10 mean?

ITU-T Rec. H.248.10 (07/2001) 1

4.2 Events
        4.2.1 MGCongestion
                Event name: MGCon
                        EventID: mgcon, (0x0001)
                        Description:
This event occurs when the MG requires that the MGC start or finish load
reduction
towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the
MGC or provisioned.
                        EventsDescriptor Parameters: None
                        ObservedEventsDescriptor Parameters 
 
Thanks,
Sampath

------=_NextPart_000_001D_01C3E018.FA588CD0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY><!-- Converted from text/plain format -->
<DIV><FONT face=3DArial size=3D2>Hi all,<BR>It was my understanding that =
Megaco=20
doesn't allow any persistent events. If my understanding is correct... =
Could=20
someone pls. clarify what the following paragraph in H.248.10 =
mean?<BR><BR>ITU-T=20
Rec. H.248.10 (07/2001) 1</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><BR>4.2=20
Events<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.2.1=20
MGCongestion<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Event name:=20
MGCon<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EventID: mgcon,=20
(0x0001)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Description:<BR>This event =
occurs=20
when the MG requires that the MGC start or finish load =
reduction<BR>towards the=20
MG or to adjust the Load Reduction Percentage. <STRONG><U>The event is =
ordered=20
by the<BR>MGC or=20
provisioned.</U></STRONG><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EventsDescriptor Parameters:=20
None<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ObservedEventsDescriptor =
Parameters=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Sampath</FONT></DIV></BODY></HTML>

------=_NextPart_000_001D_01C3E018.FA588CD0--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan 21 15:24:48 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06430
	for <megaco-archive@odin.ietf.org>; Wed, 21 Jan 2004 15:24:48 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjOtf-0007Cf-Fj
	for megaco-archive@odin.ietf.org; Wed, 21 Jan 2004 15:24:19 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LKOJAl027686
	for megaco-archive@odin.ietf.org; Wed, 21 Jan 2004 15:24:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjOtf-0007CT-AK
	for megaco-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 15:24:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06408
	for <megaco-web-archive@ietf.org>; Wed, 21 Jan 2004 15:24:17 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjOte-0007m5-00
	for megaco-web-archive@ietf.org; Wed, 21 Jan 2004 15:24:18 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjOsj-0007kR-00
	for megaco-web-archive@ietf.org; Wed, 21 Jan 2004 15:23:21 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjOsQ-0007iY-00
	for megaco-web-archive@ietf.org; Wed, 21 Jan 2004 15:23:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjOsP-0006oV-IG; Wed, 21 Jan 2004 15:23:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjOro-0006U1-47
	for megaco@optimus.ietf.org; Wed, 21 Jan 2004 15:22:24 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06273
	for <megaco@ietf.org>; Wed, 21 Jan 2004 15:22:22 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjOrm-0007hs-00
	for megaco@ietf.org; Wed, 21 Jan 2004 15:22:22 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjOqr-0007fZ-00
	for megaco@ietf.org; Wed, 21 Jan 2004 15:21:25 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjOqc-0007cr-00
	for megaco@ietf.org; Wed, 21 Jan 2004 15:21:10 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 21 Jan 2004 12:24:48 +0000
Received: from SAMPATHKW2K03 (dhcp-171-71-248-129.cisco.com [171.71.248.129])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0LKKbff024788
	for <megaco@ietf.org>; Wed, 21 Jan 2004 12:20:38 -0800 (PST)
Reply-To: <sampathk@cisco.com>
From: "Sampath Komanduri" <sampathk@cisco.com>
To: <megaco@ietf.org>
Date: Wed, 21 Jan 2004 12:20:37 -0800
Organization: Cisco Systems
Message-ID: <001c01c3e05c$087bccd0$81f847ab@SAMPATHKW2K03>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001D_01C3E018.FA588CD0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
In-Reply-To: <400BF154.9070806@nortelnetworks.com>
Importance: Normal
Subject: [Megaco] Can chp/mgcon event be persistent event?
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE 
	autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_001D_01C3E018.FA588CD0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi all,
It was my understanding that Megaco doesn't allow any persistent events.
If my understanding is correct... Could someone pls. clarify what the
following paragraph in H.248.10 mean?

ITU-T Rec. H.248.10 (07/2001) 1

4.2 Events
        4.2.1 MGCongestion
                Event name: MGCon
                        EventID: mgcon, (0x0001)
                        Description:
This event occurs when the MG requires that the MGC start or finish load
reduction
towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the
MGC or provisioned.
                        EventsDescriptor Parameters: None
                        ObservedEventsDescriptor Parameters 
 
Thanks,
Sampath

------=_NextPart_000_001D_01C3E018.FA588CD0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY><!-- Converted from text/plain format -->
<DIV><FONT face=3DArial size=3D2>Hi all,<BR>It was my understanding that =
Megaco=20
doesn't allow any persistent events. If my understanding is correct... =
Could=20
someone pls. clarify what the following paragraph in H.248.10 =
mean?<BR><BR>ITU-T=20
Rec. H.248.10 (07/2001) 1</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><BR>4.2=20
Events<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.2.1=20
MGCongestion<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Event name:=20
MGCon<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EventID: mgcon,=20
(0x0001)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Description:<BR>This event =
occurs=20
when the MG requires that the MGC start or finish load =
reduction<BR>towards the=20
MG or to adjust the Load Reduction Percentage. <STRONG><U>The event is =
ordered=20
by the<BR>MGC or=20
provisioned.</U></STRONG><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EventsDescriptor Parameters:=20
None<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ObservedEventsDescriptor =
Parameters=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Sampath</FONT></DIV></BODY></HTML>

------=_NextPart_000_001D_01C3E018.FA588CD0--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan 21 23:20:33 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25415
	for <megaco-archive@lists.ietf.org>; Wed, 21 Jan 2004 23:20:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjWK3-0001fT-FO; Wed, 21 Jan 2004 23:20:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjWJa-0001bv-KS
	for megaco@optimus.ietf.org; Wed, 21 Jan 2004 23:19:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25403
	for <megaco@ietf.org>; Wed, 21 Jan 2004 23:19:32 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjWJY-0006LF-00
	for megaco@ietf.org; Wed, 21 Jan 2004 23:19:32 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjWIe-0006JL-00
	for megaco@ietf.org; Wed, 21 Jan 2004 23:18:37 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjWHy-0006FK-00
	for megaco@ietf.org; Wed, 21 Jan 2004 23:17:54 -0500
Received: from cisco.com (samrat.cisco.com [192.135.241.21])
	by india-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0M4HHLo029571;
	Wed, 21 Jan 2004 20:17:17 -0800 (PST)
Received: from aniljw2k02 (dhcp-10-77-5-168.cisco.com [10.77.5.168])
	by cisco.com (8.11.2/8.8.8) with ESMTP id i0M4HDC19514;
	Thu, 22 Jan 2004 09:47:13 +0530 (IST)
Reply-To: <anilj@cisco.com>
From: "Anil Jangam" <anilj@cisco.com>
To: <kboyle@nortelnetworks.com>, <megaco@ietf.org>
Cc: <sampathk@cisco.com>
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Thu, 22 Jan 2004 09:47:17 +0530
Message-ID: <001b01c3e09e$9f04c390$a8054d0a@apac.cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001C_01C3E0CC.B8BE8630"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
In-Reply-To: <001c01c3e05c$087bccd0$81f847ab@SAMPATHKW2K03>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_40_50,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_001C_01C3E0CC.B8BE8630
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Kevin,
 
There is a link on the discussion of persistent event.
http://www1.ietf.org/mail-archive/working-groups/megaco/current/msg04494
.html (first para)
As it was indicated, I think there is some kind of inconsistency with
these two statements. Is there any different aspect to the
'provisioning' in the case below??
 
/anil.
 
 

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Sampath Komanduri
Sent: Thursday, January 22, 2004 1:51 AM
To: megaco@ietf.org
Subject: [Megaco] Can chp/mgcon event be persistent event?


Hi all,
It was my understanding that Megaco doesn't allow any persistent events.
If my understanding is correct... Could someone pls. clarify what the
following paragraph in H.248.10 mean?

ITU-T Rec. H.248.10 (07/2001) 1

4.2 Events
        4.2.1 MGCongestion
                Event name: MGCon
                        EventID: mgcon, (0x0001)
                        Description:
This event occurs when the MG requires that the MGC start or finish load
reduction
towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the
MGC or provisioned.
                        EventsDescriptor Parameters: None
                        ObservedEventsDescriptor Parameters 
 
Thanks,
Sampath


------=_NextPart_000_001C_01C3E0CC.B8BE8630
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D614190704-22012004>Hi=20
Kevin,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D614190704-22012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D614190704-22012004>There=20
is a link on the discussion of <FONT color=3D#000000>persistent=20
event.&nbsp;</FONT></SPAN></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D614190704-22012004><A=20
href=3D"http://www1.ietf.org/mail-archive/working-groups/megaco/current/m=
sg04494.html">http://www1.ietf.org/mail-archive/working-groups/megaco/cur=
rent/msg04494.html</A><FONT=20
color=3D#000000>&nbsp;(first para)</FONT></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D614190704-22012004>As it =
was indicated,=20
I think there is some kind of inconsistency with these two =
statements.&nbsp;Is=20
there any different&nbsp;aspect to the 'provisioning' in the case=20
below??</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D614190704-22012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D614190704-22012004>/anil.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D614190704-22012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D614190704-22012004></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] <B>On Behalf Of=20
  </B>Sampath Komanduri<BR><B>Sent:</B> Thursday, January 22, 2004 1:51=20
  AM<BR><B>To:</B> megaco@ietf.org<BR><B>Subject:</B> [Megaco] Can =
chp/mgcon=20
  event be persistent event?<BR><BR></FONT></DIV><!-- Converted from =
text/plain format -->
  <DIV><FONT face=3DArial size=3D2>Hi all,<BR>It was my understanding =
that Megaco=20
  doesn't allow any persistent events. If my understanding is correct... =
Could=20
  someone pls. clarify what the following paragraph in H.248.10=20
  mean?<BR><BR>ITU-T Rec. H.248.10 (07/2001) 1</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><BR>4.2=20
  Events<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.2.1=20
  MGCongestion<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Event name:=20
  MGCon<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EventID: mgcon,=20
  (0x0001)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Description:<BR>This event =
occurs=20
  when the MG requires that the MGC start or finish load =
reduction<BR>towards=20
  the MG or to adjust the Load Reduction Percentage. <STRONG><U>The =
event is=20
  ordered by the<BR>MGC or=20
  =
provisioned.</U></STRONG><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EventsDescriptor =
Parameters:=20
  None<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ObservedEventsDescriptor =
Parameters=20
  </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
  <DIV><FONT face=3DArial =
size=3D2>Sampath</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_001C_01C3E0CC.B8BE8630--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan 21 23:22:05 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25458
	for <megaco-archive@odin.ietf.org>; Wed, 21 Jan 2004 23:22:05 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjWLZ-0001nw-B6
	for megaco-archive@odin.ietf.org; Wed, 21 Jan 2004 23:21:37 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M4Lbut006930
	for megaco-archive@odin.ietf.org; Wed, 21 Jan 2004 23:21:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjWLZ-0001nh-4t
	for megaco-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 23:21:37 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25449
	for <megaco-web-archive@ietf.org>; Wed, 21 Jan 2004 23:21:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjWLX-0006Pp-00
	for megaco-web-archive@ietf.org; Wed, 21 Jan 2004 23:21:35 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjWKX-0006Nm-00
	for megaco-web-archive@ietf.org; Wed, 21 Jan 2004 23:20:34 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjWK4-0006MH-00
	for megaco-web-archive@ietf.org; Wed, 21 Jan 2004 23:20:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjWK3-0001fT-FO; Wed, 21 Jan 2004 23:20:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjWJa-0001bv-KS
	for megaco@optimus.ietf.org; Wed, 21 Jan 2004 23:19:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25403
	for <megaco@ietf.org>; Wed, 21 Jan 2004 23:19:32 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjWJY-0006LF-00
	for megaco@ietf.org; Wed, 21 Jan 2004 23:19:32 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjWIe-0006JL-00
	for megaco@ietf.org; Wed, 21 Jan 2004 23:18:37 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjWHy-0006FK-00
	for megaco@ietf.org; Wed, 21 Jan 2004 23:17:54 -0500
Received: from cisco.com (samrat.cisco.com [192.135.241.21])
	by india-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0M4HHLo029571;
	Wed, 21 Jan 2004 20:17:17 -0800 (PST)
Received: from aniljw2k02 (dhcp-10-77-5-168.cisco.com [10.77.5.168])
	by cisco.com (8.11.2/8.8.8) with ESMTP id i0M4HDC19514;
	Thu, 22 Jan 2004 09:47:13 +0530 (IST)
Reply-To: <anilj@cisco.com>
From: "Anil Jangam" <anilj@cisco.com>
To: <kboyle@nortelnetworks.com>, <megaco@ietf.org>
Cc: <sampathk@cisco.com>
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Thu, 22 Jan 2004 09:47:17 +0530
Message-ID: <001b01c3e09e$9f04c390$a8054d0a@apac.cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001C_01C3E0CC.B8BE8630"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
In-Reply-To: <001c01c3e05c$087bccd0$81f847ab@SAMPATHKW2K03>
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_001C_01C3E0CC.B8BE8630
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Kevin,
 
There is a link on the discussion of persistent event.
http://www1.ietf.org/mail-archive/working-groups/megaco/current/msg04494
.html (first para)
As it was indicated, I think there is some kind of inconsistency with
these two statements. Is there any different aspect to the
'provisioning' in the case below??
 
/anil.
 
 

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Sampath Komanduri
Sent: Thursday, January 22, 2004 1:51 AM
To: megaco@ietf.org
Subject: [Megaco] Can chp/mgcon event be persistent event?


Hi all,
It was my understanding that Megaco doesn't allow any persistent events.
If my understanding is correct... Could someone pls. clarify what the
following paragraph in H.248.10 mean?

ITU-T Rec. H.248.10 (07/2001) 1

4.2 Events
        4.2.1 MGCongestion
                Event name: MGCon
                        EventID: mgcon, (0x0001)
                        Description:
This event occurs when the MG requires that the MGC start or finish load
reduction
towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the
MGC or provisioned.
                        EventsDescriptor Parameters: None
                        ObservedEventsDescriptor Parameters 
 
Thanks,
Sampath


------=_NextPart_000_001C_01C3E0CC.B8BE8630
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D614190704-22012004>Hi=20
Kevin,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D614190704-22012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D614190704-22012004>There=20
is a link on the discussion of <FONT color=3D#000000>persistent=20
event.&nbsp;</FONT></SPAN></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D614190704-22012004><A=20
href=3D"http://www1.ietf.org/mail-archive/working-groups/megaco/current/m=
sg04494.html">http://www1.ietf.org/mail-archive/working-groups/megaco/cur=
rent/msg04494.html</A><FONT=20
color=3D#000000>&nbsp;(first para)</FONT></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D614190704-22012004>As it =
was indicated,=20
I think there is some kind of inconsistency with these two =
statements.&nbsp;Is=20
there any different&nbsp;aspect to the 'provisioning' in the case=20
below??</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D614190704-22012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D614190704-22012004>/anil.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D614190704-22012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D614190704-22012004></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] <B>On Behalf Of=20
  </B>Sampath Komanduri<BR><B>Sent:</B> Thursday, January 22, 2004 1:51=20
  AM<BR><B>To:</B> megaco@ietf.org<BR><B>Subject:</B> [Megaco] Can =
chp/mgcon=20
  event be persistent event?<BR><BR></FONT></DIV><!-- Converted from =
text/plain format -->
  <DIV><FONT face=3DArial size=3D2>Hi all,<BR>It was my understanding =
that Megaco=20
  doesn't allow any persistent events. If my understanding is correct... =
Could=20
  someone pls. clarify what the following paragraph in H.248.10=20
  mean?<BR><BR>ITU-T Rec. H.248.10 (07/2001) 1</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><BR>4.2=20
  Events<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.2.1=20
  MGCongestion<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Event name:=20
  MGCon<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EventID: mgcon,=20
  (0x0001)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Description:<BR>This event =
occurs=20
  when the MG requires that the MGC start or finish load =
reduction<BR>towards=20
  the MG or to adjust the Load Reduction Percentage. <STRONG><U>The =
event is=20
  ordered by the<BR>MGC or=20
  =
provisioned.</U></STRONG><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EventsDescriptor =
Parameters:=20
  None<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ObservedEventsDescriptor =
Parameters=20
  </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
  <DIV><FONT face=3DArial =
size=3D2>Sampath</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_001C_01C3E0CC.B8BE8630--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan 22 11:43:31 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27864
	for <megaco-archive@lists.ietf.org>; Thu, 22 Jan 2004 11:43:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajhv2-0004UT-Os; Thu, 22 Jan 2004 11:43:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajhu3-0004H6-UU
	for megaco@optimus.ietf.org; Thu, 22 Jan 2004 11:41:59 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27758
	for <megaco@ietf.org>; Thu, 22 Jan 2004 11:41:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajhu2-0003wA-00
	for megaco@ietf.org; Thu, 22 Jan 2004 11:41:58 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajhiu-0003En-00
	for megaco@ietf.org; Thu, 22 Jan 2004 11:30:29 -0500
Received: from ftpbox.mot.com ([129.188.136.101])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajha4-0002X4-00
	for megaco@ietf.org; Thu, 22 Jan 2004 11:21:20 -0500
Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242])
	by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i0MGL5mq017063;
	Thu, 22 Jan 2004 09:21:07 -0700 (MST)
Received: from smilevm.motorola.com ([10.14.25.162])
	by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i0MGKwD3018792;
	Thu, 22 Jan 2004 10:20:59 -0600
Message-Id: <5.2.1.1.0.20040122111141.05270110@IL06EXM13.corp.mot.com>
X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Thu, 22 Jan 2004 11:19:06 -0500
To: <sampathk@cisco.com>, <megaco@ietf.org>
From: Aleksandr Ryabin <kengr@motorola.com>
Subject: Re: [Megaco] Can chp/mgcon event be persistent event?
In-Reply-To: <001c01c3e05c$087bccd0$81f847ab@SAMPATHKW2K03>
References: <400BF154.9070806@nortelnetworks.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_553414157==.ALT"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.8 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE 
	autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

--=====================_553414157==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi,

Persistent events in MGCP are defined by package specs.
Provisioned events in MEGACO are configured by an MG operator.
As for any descriptor default EventsDescriptor values can be
provisioned on MG to be non-empty.

The only question here which RequestID to use for such pre-provisioned events?
The common consensus on the list was that 0 is a reasonable default value to
use in such cases, but of course can also be provisioned to something else
by an MG operator.

Regards,
         Aleks

At 03:20 PM 1/21/2004, Sampath Komanduri wrote:
>Hi all,
>It was my understanding that Megaco doesn't allow any persistent events. 
>If my understanding is correct... Could someone pls. clarify what the 
>following paragraph in H.248.10 mean?
>
>ITU-T Rec. H.248.10 (07/2001) 1
>
>4.2 Events
>         4.2.1 MGCongestion
>                 Event name: MGCon
>                         EventID: mgcon, (0x0001)
>                         Description:
>This event occurs when the MG requires that the MGC start or finish load 
>reduction
>towards the MG or to adjust the Load Reduction Percentage. The event is 
>ordered by the
>MGC or provisioned.
>                         EventsDescriptor Parameters: None
>                         ObservedEventsDescriptor Parameters
>
>Thanks,
>Sampath

--=====================_553414157==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Hi,<br><br>
Persistent events in MGCP are defined by package specs.<br>
Provisioned events in MEGACO are configured by an MG operator.<br>
As for any descriptor default EventsDescriptor values can be<br>
provisioned on MG to be non-empty.<br><br>
The only question here which RequestID to use for such pre-provisioned
events?<br>
The common consensus on the list was that 0 is a reasonable default value
to <br>
use in such cases, but of course can also be provisioned to something
else<br>
by an MG operator.<br><br>
Regards,<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Aleks<br><br>
At 03:20 PM 1/21/2004, Sampath Komanduri wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2>Hi
all,<br>
It was my understanding that Megaco doesn't allow any persistent events.
If my understanding is correct... Could someone pls. clarify what the
following paragraph in H.248.10 mean?<br><br>
ITU-T Rec. H.248.10 (07/2001) 1</font><br>
<font face="arial" size=2><br>
4.2 Events<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.2.1 MGCongestion<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Event name: MGCon<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventID: mgcon, (0x0001)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Description:<br>
This event occurs when the MG requires that the MGC start or finish load
reduction<br>
towards the MG or to adjust the Load Reduction Percentage. <b><u>The
event is ordered by the<br>
MGC or provisioned.</u></b><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventsDescriptor Parameters: None<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ObservedEventsDescriptor Parameters </font><br>
&nbsp;<br>
<font face="arial" size=2>Thanks,</font><br>
<font face="arial" size=2>Sampath</font></blockquote></body>
</html>

--=====================_553414157==.ALT--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan 22 11:48:19 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28860
	for <megaco-archive@odin.ietf.org>; Thu, 22 Jan 2004 11:48:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajhzj-000566-OF
	for megaco-archive@odin.ietf.org; Thu, 22 Jan 2004 11:47:51 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MGlp1i019590
	for megaco-archive@odin.ietf.org; Thu, 22 Jan 2004 11:47:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajhzj-00055t-Ky
	for megaco-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 11:47:51 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28794
	for <megaco-web-archive@ietf.org>; Thu, 22 Jan 2004 11:47:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajhzi-0005AZ-00
	for megaco-web-archive@ietf.org; Thu, 22 Jan 2004 11:47:50 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajhxy-0004oK-00
	for megaco-web-archive@ietf.org; Thu, 22 Jan 2004 11:46:06 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajhv5-0004Ap-00
	for megaco-web-archive@ietf.org; Thu, 22 Jan 2004 11:43:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajhv2-0004UT-Os; Thu, 22 Jan 2004 11:43:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajhu3-0004H6-UU
	for megaco@optimus.ietf.org; Thu, 22 Jan 2004 11:41:59 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27758
	for <megaco@ietf.org>; Thu, 22 Jan 2004 11:41:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajhu2-0003wA-00
	for megaco@ietf.org; Thu, 22 Jan 2004 11:41:58 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajhiu-0003En-00
	for megaco@ietf.org; Thu, 22 Jan 2004 11:30:29 -0500
Received: from ftpbox.mot.com ([129.188.136.101])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajha4-0002X4-00
	for megaco@ietf.org; Thu, 22 Jan 2004 11:21:20 -0500
Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242])
	by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i0MGL5mq017063;
	Thu, 22 Jan 2004 09:21:07 -0700 (MST)
Received: from smilevm.motorola.com ([10.14.25.162])
	by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i0MGKwD3018792;
	Thu, 22 Jan 2004 10:20:59 -0600
Message-Id: <5.2.1.1.0.20040122111141.05270110@IL06EXM13.corp.mot.com>
X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Thu, 22 Jan 2004 11:19:06 -0500
To: <sampathk@cisco.com>, <megaco@ietf.org>
From: Aleksandr Ryabin <kengr@motorola.com>
Subject: Re: [Megaco] Can chp/mgcon event be persistent event?
In-Reply-To: <001c01c3e05c$087bccd0$81f847ab@SAMPATHKW2K03>
References: <400BF154.9070806@nortelnetworks.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_553414157==.ALT"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE 
	autolearn=no version=2.60

--=====================_553414157==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi,

Persistent events in MGCP are defined by package specs.
Provisioned events in MEGACO are configured by an MG operator.
As for any descriptor default EventsDescriptor values can be
provisioned on MG to be non-empty.

The only question here which RequestID to use for such pre-provisioned events?
The common consensus on the list was that 0 is a reasonable default value to
use in such cases, but of course can also be provisioned to something else
by an MG operator.

Regards,
         Aleks

At 03:20 PM 1/21/2004, Sampath Komanduri wrote:
>Hi all,
>It was my understanding that Megaco doesn't allow any persistent events. 
>If my understanding is correct... Could someone pls. clarify what the 
>following paragraph in H.248.10 mean?
>
>ITU-T Rec. H.248.10 (07/2001) 1
>
>4.2 Events
>         4.2.1 MGCongestion
>                 Event name: MGCon
>                         EventID: mgcon, (0x0001)
>                         Description:
>This event occurs when the MG requires that the MGC start or finish load 
>reduction
>towards the MG or to adjust the Load Reduction Percentage. The event is 
>ordered by the
>MGC or provisioned.
>                         EventsDescriptor Parameters: None
>                         ObservedEventsDescriptor Parameters
>
>Thanks,
>Sampath

--=====================_553414157==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Hi,<br><br>
Persistent events in MGCP are defined by package specs.<br>
Provisioned events in MEGACO are configured by an MG operator.<br>
As for any descriptor default EventsDescriptor values can be<br>
provisioned on MG to be non-empty.<br><br>
The only question here which RequestID to use for such pre-provisioned
events?<br>
The common consensus on the list was that 0 is a reasonable default value
to <br>
use in such cases, but of course can also be provisioned to something
else<br>
by an MG operator.<br><br>
Regards,<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Aleks<br><br>
At 03:20 PM 1/21/2004, Sampath Komanduri wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2>Hi
all,<br>
It was my understanding that Megaco doesn't allow any persistent events.
If my understanding is correct... Could someone pls. clarify what the
following paragraph in H.248.10 mean?<br><br>
ITU-T Rec. H.248.10 (07/2001) 1</font><br>
<font face="arial" size=2><br>
4.2 Events<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.2.1 MGCongestion<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Event name: MGCon<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventID: mgcon, (0x0001)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Description:<br>
This event occurs when the MG requires that the MGC start or finish load
reduction<br>
towards the MG or to adjust the Load Reduction Percentage. <b><u>The
event is ordered by the<br>
MGC or provisioned.</u></b><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventsDescriptor Parameters: None<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ObservedEventsDescriptor Parameters </font><br>
&nbsp;<br>
<font face="arial" size=2>Thanks,</font><br>
<font face="arial" size=2>Sampath</font></blockquote></body>
</html>

--=====================_553414157==.ALT--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan 22 13:30:32 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02790
	for <megaco-archive@lists.ietf.org>; Thu, 22 Jan 2004 13:30:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajjad-0005lF-21; Thu, 22 Jan 2004 13:30:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjjZZ-0005i9-2C
	for megaco@optimus.ietf.org; Thu, 22 Jan 2004 13:29:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02767
	for <megaco@ietf.org>; Thu, 22 Jan 2004 13:28:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjjZM-0002f6-00
	for megaco@ietf.org; Thu, 22 Jan 2004 13:28:45 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjjXs-0002ZY-00
	for megaco@ietf.org; Thu, 22 Jan 2004 13:27:12 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjjTt-0002Mq-00
	for megaco@ietf.org; Thu, 22 Jan 2004 13:23:06 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0MIM8n27884
	for <megaco@ietf.org>; Thu, 22 Jan 2004 13:22:09 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DNYBYFG2>; Thu, 22 Jan 2004 13:22:09 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E022914@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Aleksandr Ryabin <kengr@motorola.com>, sampathk@cisco.com, megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Thu, 22 Jan 2004 13:22:07 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Provisioning something other than 0 will lead to rejection by the MGC.
Further, provisioning is done at the MG's own risk, as there is no way the
MG can know ahead of time that the MGC supports the package in question.
 
Basically, the MG can have events provisioned, but all bets are off as to
whether the MGC will accept or reject the event.  My personal feeling is
that MGCs should ask for events they wish to see, and not rely upon any
"event provisioning".
 
Kevin


  _____  

From: Aleksandr Ryabin [mailto:kengr@motorola.com] 
Sent: Thursday, January 22, 2004 11:19 AM
To: sampathk@cisco.com; megaco@ietf.org
Subject: Re: [Megaco] Can chp/mgcon event be persistent event?


Hi,

Persistent events in MGCP are defined by package specs.
Provisioned events in MEGACO are configured by an MG operator.
As for any descriptor default EventsDescriptor values can be
provisioned on MG to be non-empty.

The only question here which RequestID to use for such pre-provisioned
events?
The common consensus on the list was that 0 is a reasonable default value to

use in such cases, but of course can also be provisioned to something else
by an MG operator.

Regards,
        Aleks

At 03:20 PM 1/21/2004, Sampath Komanduri wrote:


Hi all,
It was my understanding that Megaco doesn't allow any persistent events. If
my understanding is correct... Could someone pls. clarify what the following
paragraph in H.248.10 mean?

ITU-T Rec. H.248.10 (07/2001) 1

4.2 Events
        4.2.1 MGCongestion
                Event name: MGCon
                        EventID: mgcon, (0x0001)
                        Description:
This event occurs when the MG requires that the MGC start or finish load
reduction
towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the
MGC or provisioned.
                        EventsDescriptor Parameters: None
                        ObservedEventsDescriptor Parameters 
 
Thanks,
Sampath


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan 22 13:35:03 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02973
	for <megaco-archive@odin.ietf.org>; Thu, 22 Jan 2004 13:35:03 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajjf1-0006IP-FU
	for megaco-archive@odin.ietf.org; Thu, 22 Jan 2004 13:34:35 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MIYZaE024200
	for megaco-archive@odin.ietf.org; Thu, 22 Jan 2004 13:34:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajjf1-0006IF-9D
	for megaco-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 13:34:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02941
	for <megaco-web-archive@ietf.org>; Thu, 22 Jan 2004 13:34:32 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajjez-0002vT-00
	for megaco-web-archive@ietf.org; Thu, 22 Jan 2004 13:34:33 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjjdN-0002pC-00
	for megaco-web-archive@ietf.org; Thu, 22 Jan 2004 13:32:54 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajjaw-0002hz-00
	for megaco-web-archive@ietf.org; Thu, 22 Jan 2004 13:30:22 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajjad-0005lF-21; Thu, 22 Jan 2004 13:30:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjjZZ-0005i9-2C
	for megaco@optimus.ietf.org; Thu, 22 Jan 2004 13:29:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02767
	for <megaco@ietf.org>; Thu, 22 Jan 2004 13:28:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjjZM-0002f6-00
	for megaco@ietf.org; Thu, 22 Jan 2004 13:28:45 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjjXs-0002ZY-00
	for megaco@ietf.org; Thu, 22 Jan 2004 13:27:12 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjjTt-0002Mq-00
	for megaco@ietf.org; Thu, 22 Jan 2004 13:23:06 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0MIM8n27884
	for <megaco@ietf.org>; Thu, 22 Jan 2004 13:22:09 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DNYBYFG2>; Thu, 22 Jan 2004 13:22:09 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E022914@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Aleksandr Ryabin <kengr@motorola.com>, sampathk@cisco.com, megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Thu, 22 Jan 2004 13:22:07 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60

Provisioning something other than 0 will lead to rejection by the MGC.
Further, provisioning is done at the MG's own risk, as there is no way the
MG can know ahead of time that the MGC supports the package in question.
 
Basically, the MG can have events provisioned, but all bets are off as to
whether the MGC will accept or reject the event.  My personal feeling is
that MGCs should ask for events they wish to see, and not rely upon any
"event provisioning".
 
Kevin


  _____  

From: Aleksandr Ryabin [mailto:kengr@motorola.com] 
Sent: Thursday, January 22, 2004 11:19 AM
To: sampathk@cisco.com; megaco@ietf.org
Subject: Re: [Megaco] Can chp/mgcon event be persistent event?


Hi,

Persistent events in MGCP are defined by package specs.
Provisioned events in MEGACO are configured by an MG operator.
As for any descriptor default EventsDescriptor values can be
provisioned on MG to be non-empty.

The only question here which RequestID to use for such pre-provisioned
events?
The common consensus on the list was that 0 is a reasonable default value to

use in such cases, but of course can also be provisioned to something else
by an MG operator.

Regards,
        Aleks

At 03:20 PM 1/21/2004, Sampath Komanduri wrote:


Hi all,
It was my understanding that Megaco doesn't allow any persistent events. If
my understanding is correct... Could someone pls. clarify what the following
paragraph in H.248.10 mean?

ITU-T Rec. H.248.10 (07/2001) 1

4.2 Events
        4.2.1 MGCongestion
                Event name: MGCon
                        EventID: mgcon, (0x0001)
                        Description:
This event occurs when the MG requires that the MGC start or finish load
reduction
towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the
MGC or provisioned.
                        EventsDescriptor Parameters: None
                        ObservedEventsDescriptor Parameters 
 
Thanks,
Sampath


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan 22 13:48:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03584
	for <megaco-archive@lists.ietf.org>; Thu, 22 Jan 2004 13:48:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajjs1-0007Fb-C4; Thu, 22 Jan 2004 13:48:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajjr4-0007Dx-0D
	for megaco@optimus.ietf.org; Thu, 22 Jan 2004 13:47:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03463
	for <megaco@ietf.org>; Thu, 22 Jan 2004 13:46:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajjr1-0003SC-00
	for megaco@ietf.org; Thu, 22 Jan 2004 13:46:59 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajjq6-0003Qp-00
	for megaco@ietf.org; Thu, 22 Jan 2004 13:46:03 -0500
Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajjpj-0003PR-00
	for megaco@ietf.org; Thu, 22 Jan 2004 13:45:39 -0500
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <XM89X9HK>; Thu, 22 Jan 2004 13:45:37 -0500
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA03506348@wench.telica.com>
From: Carl Rutter <crutter@telica.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        Aleksandr Ryabin
	 <kengr@motorola.com>, sampathk@cisco.com,
        megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Thu, 22 Jan 2004 13:45:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

I guess my only concern here is the overhead
involved in the MGC asking for events in some cases.
ie) High-Density Gateway running CAS.
As densities increase we may want to foster a 
better MG event provisioning approach.

Carl

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Thursday, January 22, 2004 1:22 PM
To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?


Provisioning something other than 0 will lead to rejection by the MGC.
Further, provisioning is done at the MG's own risk, as there is no way the
MG can know ahead of time that the MGC supports the package in question.
 
Basically, the MG can have events provisioned, but all bets are off as to
whether the MGC will accept or reject the event.  My personal feeling is
that MGCs should ask for events they wish to see, and not rely upon any
"event provisioning".
 
Kevin


  _____  

From: Aleksandr Ryabin [mailto:kengr@motorola.com] 
Sent: Thursday, January 22, 2004 11:19 AM
To: sampathk@cisco.com; megaco@ietf.org
Subject: Re: [Megaco] Can chp/mgcon event be persistent event?


Hi,

Persistent events in MGCP are defined by package specs.
Provisioned events in MEGACO are configured by an MG operator.
As for any descriptor default EventsDescriptor values can be
provisioned on MG to be non-empty.

The only question here which RequestID to use for such pre-provisioned
events?
The common consensus on the list was that 0 is a reasonable default value to

use in such cases, but of course can also be provisioned to something else
by an MG operator.

Regards,
        Aleks

At 03:20 PM 1/21/2004, Sampath Komanduri wrote:


Hi all,
It was my understanding that Megaco doesn't allow any persistent events. If
my understanding is correct... Could someone pls. clarify what the following
paragraph in H.248.10 mean?

ITU-T Rec. H.248.10 (07/2001) 1

4.2 Events
        4.2.1 MGCongestion
                Event name: MGCon
                        EventID: mgcon, (0x0001)
                        Description:
This event occurs when the MG requires that the MGC start or finish load
reduction
towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the
MGC or provisioned.
                        EventsDescriptor Parameters: None
                        ObservedEventsDescriptor Parameters 
 
Thanks,
Sampath


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan 22 13:51:20 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04137
	for <megaco-archive@odin.ietf.org>; Thu, 22 Jan 2004 13:51:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajjum-0007b2-HK
	for megaco-archive@odin.ietf.org; Thu, 22 Jan 2004 13:50:52 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MIoqHk029194
	for megaco-archive@odin.ietf.org; Thu, 22 Jan 2004 13:50:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajjum-0007an-Cg
	for megaco-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 13:50:52 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03971
	for <megaco-web-archive@ietf.org>; Thu, 22 Jan 2004 13:50:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajjuj-000419-00
	for megaco-web-archive@ietf.org; Thu, 22 Jan 2004 13:50:49 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajjt8-0003iC-00
	for megaco-web-archive@ietf.org; Thu, 22 Jan 2004 13:49:11 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajjs1-0003W7-00
	for megaco-web-archive@ietf.org; Thu, 22 Jan 2004 13:48:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajjs1-0007Fb-C4; Thu, 22 Jan 2004 13:48:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajjr4-0007Dx-0D
	for megaco@optimus.ietf.org; Thu, 22 Jan 2004 13:47:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03463
	for <megaco@ietf.org>; Thu, 22 Jan 2004 13:46:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajjr1-0003SC-00
	for megaco@ietf.org; Thu, 22 Jan 2004 13:46:59 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajjq6-0003Qp-00
	for megaco@ietf.org; Thu, 22 Jan 2004 13:46:03 -0500
Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajjpj-0003PR-00
	for megaco@ietf.org; Thu, 22 Jan 2004 13:45:39 -0500
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <XM89X9HK>; Thu, 22 Jan 2004 13:45:37 -0500
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA03506348@wench.telica.com>
From: Carl Rutter <crutter@telica.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        Aleksandr Ryabin
	 <kengr@motorola.com>, sampathk@cisco.com,
        megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Thu, 22 Jan 2004 13:45:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

I guess my only concern here is the overhead
involved in the MGC asking for events in some cases.
ie) High-Density Gateway running CAS.
As densities increase we may want to foster a 
better MG event provisioning approach.

Carl

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Thursday, January 22, 2004 1:22 PM
To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?


Provisioning something other than 0 will lead to rejection by the MGC.
Further, provisioning is done at the MG's own risk, as there is no way the
MG can know ahead of time that the MGC supports the package in question.
 
Basically, the MG can have events provisioned, but all bets are off as to
whether the MGC will accept or reject the event.  My personal feeling is
that MGCs should ask for events they wish to see, and not rely upon any
"event provisioning".
 
Kevin


  _____  

From: Aleksandr Ryabin [mailto:kengr@motorola.com] 
Sent: Thursday, January 22, 2004 11:19 AM
To: sampathk@cisco.com; megaco@ietf.org
Subject: Re: [Megaco] Can chp/mgcon event be persistent event?


Hi,

Persistent events in MGCP are defined by package specs.
Provisioned events in MEGACO are configured by an MG operator.
As for any descriptor default EventsDescriptor values can be
provisioned on MG to be non-empty.

The only question here which RequestID to use for such pre-provisioned
events?
The common consensus on the list was that 0 is a reasonable default value to

use in such cases, but of course can also be provisioned to something else
by an MG operator.

Regards,
        Aleks

At 03:20 PM 1/21/2004, Sampath Komanduri wrote:


Hi all,
It was my understanding that Megaco doesn't allow any persistent events. If
my understanding is correct... Could someone pls. clarify what the following
paragraph in H.248.10 mean?

ITU-T Rec. H.248.10 (07/2001) 1

4.2 Events
        4.2.1 MGCongestion
                Event name: MGCon
                        EventID: mgcon, (0x0001)
                        Description:
This event occurs when the MG requires that the MGC start or finish load
reduction
towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the
MGC or provisioned.
                        EventsDescriptor Parameters: None
                        ObservedEventsDescriptor Parameters 
 
Thanks,
Sampath


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan 22 13:52:35 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04399
	for <megaco-archive@lists.ietf.org>; Thu, 22 Jan 2004 13:52:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajjvy-0007qC-K4; Thu, 22 Jan 2004 13:52:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajjvr-0007mt-Jt
	for megaco@optimus.ietf.org; Thu, 22 Jan 2004 13:51:59 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04304
	for <megaco@ietf.org>; Thu, 22 Jan 2004 13:51:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajjvp-0004SQ-00
	for megaco@ietf.org; Thu, 22 Jan 2004 13:51:57 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajjuk-00041c-00
	for megaco@ietf.org; Thu, 22 Jan 2004 13:50:57 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjjtD-0003da-00
	for megaco@ietf.org; Thu, 22 Jan 2004 13:49:16 -0500
Received: from SAMPATHKW2K03 (dhcp-171-71-9-200.cisco.com [171.71.9.200])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0MImgff013951;
	Thu, 22 Jan 2004 10:48:42 -0800 (PST)
Reply-To: <sampathk@cisco.com>
From: "Sampath Komanduri" <sampathk@cisco.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'Aleksandr Ryabin'" <kengr@motorola.com>, <megaco@ietf.org>
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Thu, 22 Jan 2004 10:48:42 -0800
Organization: Cisco Systems
Message-ID: <006101c3e118$5bdcfd60$81f847ab@SAMPATHKW2K03>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0062_01C3E0D5.4DB9BD60"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0E022914@zrtpd0jq.us.nortel.com>
Importance: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0062_01C3E0D5.4DB9BD60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Aleks and Kevin,
Thanks for responding. I do understand that in the absence of MGC
requested event, if MG has to generate a notification, it would use
RequestID 0. However, I don't see anything with respect to RequestID 0
handling in the spec. other than the following text in Section 7.2.7:
    "Procedures for sending Notify commands with RequestID equal to 0
are for futher study."
 
a) What is the action *required* by the MGC upon recieving a notify with
requestID 0?
    1) Is MGC supposed to do what it would have done if it had
explicitly asked for the eventNotification? In our example, is MGC
"required" to take the *same actions* to reduce congestion on MG (upon
receipt of unsolicited notification) which it would have taken if MGC
had "solicited" the notification? OR
    2) MGC must just respond to the Notification and *not* do anything
with respect to helping MG in reducing the congestion.
    3) MGC can choose to *not* to even respond to the Notify? I hope
this is not the case, since it would result in a DISCONNECTED
association.
 
b) Which events qualify to be notified to MGC with RequestID 0?
    Only events on ROOT? Only event on ROOT and Analog lines? Any
events?
 
It would be good to see some supporting text in the Spec. if the authors
decide to leave the support of persistent events in Megaco.
 
Thanks,
Sampath

 
 -----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] 
Sent: Thursday, January 22, 2004 10:22 AM
To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?


Provisioning something other than 0 will lead to rejection by the MGC.
Further, provisioning is done at the MG's own risk, as there is no way
the MG can know ahead of time that the MGC supports the package in
question.
 
Basically, the MG can have events provisioned, but all bets are off as
to whether the MGC will accept or reject the event.  My personal feeling
is that MGCs should ask for events they wish to see, and not rely upon
any "event provisioning".
 
Kevin


  _____  

From: Aleksandr Ryabin [mailto:kengr@motorola.com] 
Sent: Thursday, January 22, 2004 11:19 AM
To: sampathk@cisco.com; megaco@ietf.org
Subject: Re: [Megaco] Can chp/mgcon event be persistent event?


Hi,

Persistent events in MGCP are defined by package specs.
Provisioned events in MEGACO are configured by an MG operator.
As for any descriptor default EventsDescriptor values can be
provisioned on MG to be non-empty.

The only question here which RequestID to use for such pre-provisioned
events?
The common consensus on the list was that 0 is a reasonable default
value to 
use in such cases, but of course can also be provisioned to something
else
by an MG operator.

Regards,
        Aleks

At 03:20 PM 1/21/2004, Sampath Komanduri wrote:


Hi all,
It was my understanding that Megaco doesn't allow any persistent events.
If my understanding is correct... Could someone pls. clarify what the
following paragraph in H.248.10 mean?

ITU-T Rec. H.248.10 (07/2001) 1

4.2 Events
        4.2.1 MGCongestion
                Event name: MGCon
                        EventID: mgcon, (0x0001)
                        Description:
This event occurs when the MG requires that the MGC start or finish load
reduction
towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the
MGC or provisioned.
                        EventsDescriptor Parameters: None
                        ObservedEventsDescriptor Parameters 
 
Thanks,
Sampath


------=_NextPart_000_0062_01C3E0D5.4DB9BD60
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =
size=3D2>Aleks=20
and Kevin,</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =
size=3D2>Thanks=20
for responding. I do understand that in the absence of MGC requested =
event, if=20
MG has to generate a notification, it would use RequestID 0. However, I =
don't=20
see anything with respect to RequestID 0 handling in the spec. other =
than the=20
following text in Section 7.2.7:</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =

size=3D2>&nbsp;&nbsp;&nbsp; "Procedures for sending Notify commands with =
RequestID=20
equal to 0 are for futher study."</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =
size=3D2>a)=20
What is the action *required* by the MGC upon recieving a notify with =
requestID=20
0?</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004>&nbsp;&nbsp;&nbsp; <FONT =
face=3DArial=20
color=3D#0000ff size=3D2>1) Is MGC supposed to do what it would have =
done if it had=20
explicitly asked for the eventNotification? In our example, is MGC =
"required" to=20
take the *same actions* to reduce congestion on MG (upon receipt of =
unsolicited=20
notification) which it would have taken if MGC had "solicited" the =
notification?=20
OR</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004>&nbsp;&nbsp;&nbsp; <FONT =
face=3DArial=20
color=3D#0000ff size=3D2>2) MGC must just respond to the Notification =
and *not* do=20
anything with respect to helping MG in reducing the=20
congestion.</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004>&nbsp;&nbsp;&nbsp; <FONT =
face=3DArial=20
color=3D#0000ff size=3D2>3) MGC can choose to *not* to even respond to =
the Notify? I=20
hope this is not the case, since it would result in a DISCONNECTED=20
association.</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =
size=3D2>b)=20
Which events qualify to be notified to MGC with RequestID =
0?</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004>&nbsp;&nbsp;&nbsp; <FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Only events on ROOT? Only event on ROOT and =
Analog lines?=20
Any events?</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =
size=3D2>It=20
would be good to see some supporting text in the Spec. if the authors =
decide to=20
leave the support of persistent events in Megaco.</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Sampath</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma><FONT size=3D2><SPAN class=3D675573018-22012004><FONT =
face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma><FONT size=3D2><SPAN=20
  class=3D675573018-22012004>&nbsp;</SPAN>-----Original=20
  Message-----<BR><B>From:</B> Kevin Boyle =
[mailto:kboyle@nortelnetworks.com]=20
  <BR><B>Sent:</B> Thursday, January 22, 2004 10:22 AM<BR><B>To:</B> =
Aleksandr=20
  Ryabin; sampathk@cisco.com; megaco@ietf.org<BR><B>Subject:</B> RE: =
[Megaco]=20
  Can chp/mgcon event be persistent event?<BR><BR></DIV></FONT></FONT>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D124351718-22012004><FONT =
face=3DArial=20
  size=3D2>Provisioning something other than 0 will lead to rejection by =
the=20
  MGC.&nbsp; Further, provisioning is done at the MG's own risk, as =
there is no=20
  way the MG can know ahead of time that the MGC supports the package in =

  question.</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D124351718-22012004><FONT =
face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D124351718-22012004><FONT =
face=3DArial=20
  size=3D2>Basically, the MG can have events provisioned, but all bets =
are off as=20
  to whether the MGC will accept or reject the event.&nbsp; My personal =
feeling=20
  is that MGCs should ask for events they wish to see, and not rely upon =
any=20
  "event provisioning".</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D124351718-22012004><FONT =
face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D124351718-22012004><FONT =
face=3DArial=20
  size=3D2>Kevin</FONT></SPAN></DIV><BR>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
    <HR tabIndex=3D-1>
    <FONT face=3DTahoma size=3D2><B>From:</B> Aleksandr Ryabin=20
    [mailto:kengr@motorola.com] <BR><B>Sent:</B> Thursday, January 22, =
2004=20
    11:19 AM<BR><B>To:</B> sampathk@cisco.com;=20
    megaco@ietf.org<BR><B>Subject:</B> Re: [Megaco] Can chp/mgcon event =
be=20
    persistent event?<BR></FONT><BR></DIV>
    <DIV></DIV>Hi,<BR><BR>Persistent events in MGCP are defined by =
package=20
    specs.<BR>Provisioned events in MEGACO are configured by an MG=20
    operator.<BR>As for any descriptor default EventsDescriptor values =
can=20
    be<BR>provisioned on MG to be non-empty.<BR><BR>The only question =
here which=20
    RequestID to use for such pre-provisioned events?<BR>The common =
consensus on=20
    the list was that 0 is a reasonable default value to <BR>use in such =
cases,=20
    but of course can also be provisioned to something else<BR>by an MG=20
    =
operator.<BR><BR>Regards,<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;</X-TAB>Aleks<BR><BR>At=20
    03:20 PM 1/21/2004, Sampath Komanduri wrote:<BR>
    <BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite"><FONT face=3Darial =
size=3D2>Hi=20
      all,<BR>It was my understanding that Megaco doesn't allow any =
persistent=20
      events. If my understanding is correct... Could someone pls. =
clarify what=20
      the following paragraph in H.248.10 mean?<BR><BR>ITU-T Rec. =
H.248.10=20
      (07/2001) 1</FONT><BR><FONT face=3Darial size=3D2><BR>4.2=20
      Events<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.2.1=20
      =
MGCongestion<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      Event name:=20
      =
MGCon<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      EventID: mgcon,=20
      =
(0x0001)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
      Description:<BR>This event occurs when the MG requires that the =
MGC start=20
      or finish load reduction<BR>towards the MG or to adjust the Load =
Reduction=20
      Percentage. <B><U>The event is ordered by the<BR>MGC or=20
      =
provisioned.</U></B><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
      EventsDescriptor Parameters:=20
      =
None<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
      ObservedEventsDescriptor Parameters </FONT><BR>&nbsp;<BR><FONT =
face=3Darial=20
      size=3D2>Thanks,</FONT><BR><FONT face=3Darial=20
  =
size=3D2>Sampath</FONT></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HT=
ML>

------=_NextPart_000_0062_01C3E0D5.4DB9BD60--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan 22 13:55:11 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04793
	for <megaco-archive@odin.ietf.org>; Thu, 22 Jan 2004 13:55:11 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjjyV-0008MI-Ao
	for megaco-archive@odin.ietf.org; Thu, 22 Jan 2004 13:54:43 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MIshu5032123
	for megaco-archive@odin.ietf.org; Thu, 22 Jan 2004 13:54:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjjyU-0008Lx-F2
	for megaco-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 13:54:42 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04723
	for <megaco-web-archive@ietf.org>; Thu, 22 Jan 2004 13:54:39 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjjyS-00054i-00
	for megaco-web-archive@ietf.org; Thu, 22 Jan 2004 13:54:40 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjjxL-0004ul-00
	for megaco-web-archive@ietf.org; Thu, 22 Jan 2004 13:53:32 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjjwC-0004Z0-00
	for megaco-web-archive@ietf.org; Thu, 22 Jan 2004 13:52:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajjvy-0007qC-K4; Thu, 22 Jan 2004 13:52:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajjvr-0007mt-Jt
	for megaco@optimus.ietf.org; Thu, 22 Jan 2004 13:51:59 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04304
	for <megaco@ietf.org>; Thu, 22 Jan 2004 13:51:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajjvp-0004SQ-00
	for megaco@ietf.org; Thu, 22 Jan 2004 13:51:57 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajjuk-00041c-00
	for megaco@ietf.org; Thu, 22 Jan 2004 13:50:57 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjjtD-0003da-00
	for megaco@ietf.org; Thu, 22 Jan 2004 13:49:16 -0500
Received: from SAMPATHKW2K03 (dhcp-171-71-9-200.cisco.com [171.71.9.200])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0MImgff013951;
	Thu, 22 Jan 2004 10:48:42 -0800 (PST)
Reply-To: <sampathk@cisco.com>
From: "Sampath Komanduri" <sampathk@cisco.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'Aleksandr Ryabin'" <kengr@motorola.com>, <megaco@ietf.org>
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Thu, 22 Jan 2004 10:48:42 -0800
Organization: Cisco Systems
Message-ID: <006101c3e118$5bdcfd60$81f847ab@SAMPATHKW2K03>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0062_01C3E0D5.4DB9BD60"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0E022914@zrtpd0jq.us.nortel.com>
Importance: Normal
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_0062_01C3E0D5.4DB9BD60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Aleks and Kevin,
Thanks for responding. I do understand that in the absence of MGC
requested event, if MG has to generate a notification, it would use
RequestID 0. However, I don't see anything with respect to RequestID 0
handling in the spec. other than the following text in Section 7.2.7:
    "Procedures for sending Notify commands with RequestID equal to 0
are for futher study."
 
a) What is the action *required* by the MGC upon recieving a notify with
requestID 0?
    1) Is MGC supposed to do what it would have done if it had
explicitly asked for the eventNotification? In our example, is MGC
"required" to take the *same actions* to reduce congestion on MG (upon
receipt of unsolicited notification) which it would have taken if MGC
had "solicited" the notification? OR
    2) MGC must just respond to the Notification and *not* do anything
with respect to helping MG in reducing the congestion.
    3) MGC can choose to *not* to even respond to the Notify? I hope
this is not the case, since it would result in a DISCONNECTED
association.
 
b) Which events qualify to be notified to MGC with RequestID 0?
    Only events on ROOT? Only event on ROOT and Analog lines? Any
events?
 
It would be good to see some supporting text in the Spec. if the authors
decide to leave the support of persistent events in Megaco.
 
Thanks,
Sampath

 
 -----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] 
Sent: Thursday, January 22, 2004 10:22 AM
To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?


Provisioning something other than 0 will lead to rejection by the MGC.
Further, provisioning is done at the MG's own risk, as there is no way
the MG can know ahead of time that the MGC supports the package in
question.
 
Basically, the MG can have events provisioned, but all bets are off as
to whether the MGC will accept or reject the event.  My personal feeling
is that MGCs should ask for events they wish to see, and not rely upon
any "event provisioning".
 
Kevin


  _____  

From: Aleksandr Ryabin [mailto:kengr@motorola.com] 
Sent: Thursday, January 22, 2004 11:19 AM
To: sampathk@cisco.com; megaco@ietf.org
Subject: Re: [Megaco] Can chp/mgcon event be persistent event?


Hi,

Persistent events in MGCP are defined by package specs.
Provisioned events in MEGACO are configured by an MG operator.
As for any descriptor default EventsDescriptor values can be
provisioned on MG to be non-empty.

The only question here which RequestID to use for such pre-provisioned
events?
The common consensus on the list was that 0 is a reasonable default
value to 
use in such cases, but of course can also be provisioned to something
else
by an MG operator.

Regards,
        Aleks

At 03:20 PM 1/21/2004, Sampath Komanduri wrote:


Hi all,
It was my understanding that Megaco doesn't allow any persistent events.
If my understanding is correct... Could someone pls. clarify what the
following paragraph in H.248.10 mean?

ITU-T Rec. H.248.10 (07/2001) 1

4.2 Events
        4.2.1 MGCongestion
                Event name: MGCon
                        EventID: mgcon, (0x0001)
                        Description:
This event occurs when the MG requires that the MGC start or finish load
reduction
towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the
MGC or provisioned.
                        EventsDescriptor Parameters: None
                        ObservedEventsDescriptor Parameters 
 
Thanks,
Sampath


------=_NextPart_000_0062_01C3E0D5.4DB9BD60
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =
size=3D2>Aleks=20
and Kevin,</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =
size=3D2>Thanks=20
for responding. I do understand that in the absence of MGC requested =
event, if=20
MG has to generate a notification, it would use RequestID 0. However, I =
don't=20
see anything with respect to RequestID 0 handling in the spec. other =
than the=20
following text in Section 7.2.7:</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =

size=3D2>&nbsp;&nbsp;&nbsp; "Procedures for sending Notify commands with =
RequestID=20
equal to 0 are for futher study."</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =
size=3D2>a)=20
What is the action *required* by the MGC upon recieving a notify with =
requestID=20
0?</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004>&nbsp;&nbsp;&nbsp; <FONT =
face=3DArial=20
color=3D#0000ff size=3D2>1) Is MGC supposed to do what it would have =
done if it had=20
explicitly asked for the eventNotification? In our example, is MGC =
"required" to=20
take the *same actions* to reduce congestion on MG (upon receipt of =
unsolicited=20
notification) which it would have taken if MGC had "solicited" the =
notification?=20
OR</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004>&nbsp;&nbsp;&nbsp; <FONT =
face=3DArial=20
color=3D#0000ff size=3D2>2) MGC must just respond to the Notification =
and *not* do=20
anything with respect to helping MG in reducing the=20
congestion.</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004>&nbsp;&nbsp;&nbsp; <FONT =
face=3DArial=20
color=3D#0000ff size=3D2>3) MGC can choose to *not* to even respond to =
the Notify? I=20
hope this is not the case, since it would result in a DISCONNECTED=20
association.</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =
size=3D2>b)=20
Which events qualify to be notified to MGC with RequestID =
0?</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004>&nbsp;&nbsp;&nbsp; <FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Only events on ROOT? Only event on ROOT and =
Analog lines?=20
Any events?</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =
size=3D2>It=20
would be good to see some supporting text in the Spec. if the authors =
decide to=20
leave the support of persistent events in Megaco.</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D675573018-22012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Sampath</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma><FONT size=3D2><SPAN class=3D675573018-22012004><FONT =
face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma><FONT size=3D2><SPAN=20
  class=3D675573018-22012004>&nbsp;</SPAN>-----Original=20
  Message-----<BR><B>From:</B> Kevin Boyle =
[mailto:kboyle@nortelnetworks.com]=20
  <BR><B>Sent:</B> Thursday, January 22, 2004 10:22 AM<BR><B>To:</B> =
Aleksandr=20
  Ryabin; sampathk@cisco.com; megaco@ietf.org<BR><B>Subject:</B> RE: =
[Megaco]=20
  Can chp/mgcon event be persistent event?<BR><BR></DIV></FONT></FONT>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D124351718-22012004><FONT =
face=3DArial=20
  size=3D2>Provisioning something other than 0 will lead to rejection by =
the=20
  MGC.&nbsp; Further, provisioning is done at the MG's own risk, as =
there is no=20
  way the MG can know ahead of time that the MGC supports the package in =

  question.</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D124351718-22012004><FONT =
face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D124351718-22012004><FONT =
face=3DArial=20
  size=3D2>Basically, the MG can have events provisioned, but all bets =
are off as=20
  to whether the MGC will accept or reject the event.&nbsp; My personal =
feeling=20
  is that MGCs should ask for events they wish to see, and not rely upon =
any=20
  "event provisioning".</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D124351718-22012004><FONT =
face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D124351718-22012004><FONT =
face=3DArial=20
  size=3D2>Kevin</FONT></SPAN></DIV><BR>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
    <HR tabIndex=3D-1>
    <FONT face=3DTahoma size=3D2><B>From:</B> Aleksandr Ryabin=20
    [mailto:kengr@motorola.com] <BR><B>Sent:</B> Thursday, January 22, =
2004=20
    11:19 AM<BR><B>To:</B> sampathk@cisco.com;=20
    megaco@ietf.org<BR><B>Subject:</B> Re: [Megaco] Can chp/mgcon event =
be=20
    persistent event?<BR></FONT><BR></DIV>
    <DIV></DIV>Hi,<BR><BR>Persistent events in MGCP are defined by =
package=20
    specs.<BR>Provisioned events in MEGACO are configured by an MG=20
    operator.<BR>As for any descriptor default EventsDescriptor values =
can=20
    be<BR>provisioned on MG to be non-empty.<BR><BR>The only question =
here which=20
    RequestID to use for such pre-provisioned events?<BR>The common =
consensus on=20
    the list was that 0 is a reasonable default value to <BR>use in such =
cases,=20
    but of course can also be provisioned to something else<BR>by an MG=20
    =
operator.<BR><BR>Regards,<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;</X-TAB>Aleks<BR><BR>At=20
    03:20 PM 1/21/2004, Sampath Komanduri wrote:<BR>
    <BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite"><FONT face=3Darial =
size=3D2>Hi=20
      all,<BR>It was my understanding that Megaco doesn't allow any =
persistent=20
      events. If my understanding is correct... Could someone pls. =
clarify what=20
      the following paragraph in H.248.10 mean?<BR><BR>ITU-T Rec. =
H.248.10=20
      (07/2001) 1</FONT><BR><FONT face=3Darial size=3D2><BR>4.2=20
      Events<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.2.1=20
      =
MGCongestion<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      Event name:=20
      =
MGCon<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      EventID: mgcon,=20
      =
(0x0001)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
      Description:<BR>This event occurs when the MG requires that the =
MGC start=20
      or finish load reduction<BR>towards the MG or to adjust the Load =
Reduction=20
      Percentage. <B><U>The event is ordered by the<BR>MGC or=20
      =
provisioned.</U></B><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
      EventsDescriptor Parameters:=20
      =
None<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
      ObservedEventsDescriptor Parameters </FONT><BR>&nbsp;<BR><FONT =
face=3Darial=20
      size=3D2>Thanks,</FONT><BR><FONT face=3Darial=20
  =
size=3D2>Sampath</FONT></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HT=
ML>

------=_NextPart_000_0062_01C3E0D5.4DB9BD60--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan 22 14:03:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05013
	for <megaco-archive@lists.ietf.org>; Thu, 22 Jan 2004 14:03:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajk6X-0000Rs-K7; Thu, 22 Jan 2004 14:03:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajk6K-0000Nq-3Y
	for megaco@optimus.ietf.org; Thu, 22 Jan 2004 14:02:53 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05007
	for <megaco@ietf.org>; Thu, 22 Jan 2004 14:02:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajk6C-0005Mc-00
	for megaco@ietf.org; Thu, 22 Jan 2004 14:02:40 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajk5N-0005LW-00
	for megaco@ietf.org; Thu, 22 Jan 2004 14:01:51 -0500
Received: from ftpbox.mot.com ([129.188.136.101])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajk4U-0005KK-00
	for megaco@ietf.org; Thu, 22 Jan 2004 14:00:54 -0500
Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242])
	by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i0MJ0Kmq018566;
	Thu, 22 Jan 2004 12:00:20 -0700 (MST)
Received: from smilevm.motorola.com ([10.14.25.162])
	by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i0MIrS1Q028627;
	Thu, 22 Jan 2004 12:53:29 -0600
Message-Id: <5.2.1.1.0.20040122134523.0527a6d8@IL06EXM13.corp.mot.com>
X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Thu, 22 Jan 2004 13:53:03 -0500
To: "Kevin Boyle"<kboyle@nortelnetworks.com>, <megaco@ietf.org>
From: Aleksandr Ryabin <kengr@motorola.com>
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Cc: sampathk@cisco.com
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0E022914@zrtpd0jq.us.norte
 l.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_562241210==.ALT"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE 
	autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

--=====================_562241210==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

0 is an arbitrary number and not better then anything else.
As long as an MG and an MGC have a bilateral agreement
what the number is everyone will be happy.

I agree that generally pre-provisioned events should be avoided,
but in certain cases events pre-provisioning can have benefits.

Consider a large MG which supports CAS and for some reason
termination wildcarding is not an option for requesting initial events.
In this case pre-provisioning of events will avoid huge number of Modifies
after a cold boot otherwise needed to be exchanged in order to
setup/arm every termination for CAS.

         Aleks

At 01:22 PM 1/22/2004, Kevin Boyle wrote:
>Provisioning something other than 0 will lead to rejection by the 
>MGC.  Further, provisioning is done at the MG's own risk, as there is no 
>way the MG can know ahead of time that the MGC supports the package in 
>question.
>
>Basically, the MG can have events provisioned, but all bets are off as to 
>whether the MGC will accept or reject the event.  My personal feeling is 
>that MGCs should ask for events they wish to see, and not rely upon any 
>"event provisioning".
>
>Kevin
>
>
>----------
>From: Aleksandr Ryabin [mailto:kengr@motorola.com]
>Sent: Thursday, January 22, 2004 11:19 AM
>To: sampathk@cisco.com; megaco@ietf.org
>Subject: Re: [Megaco] Can chp/mgcon event be persistent event?
>
>Hi,
>
>Persistent events in MGCP are defined by package specs.
>Provisioned events in MEGACO are configured by an MG operator.
>As for any descriptor default EventsDescriptor values can be
>provisioned on MG to be non-empty.
>
>The only question here which RequestID to use for such pre-provisioned events?
>The common consensus on the list was that 0 is a reasonable default value to
>use in such cases, but of course can also be provisioned to something else
>by an MG operator.
>
>Regards,
>         Aleks
>
>At 03:20 PM 1/21/2004, Sampath Komanduri wrote:
>>Hi all,
>>It was my understanding that Megaco doesn't allow any persistent events. 
>>If my understanding is correct... Could someone pls. clarify what the 
>>following paragraph in H.248.10 mean?
>>
>>ITU-T Rec. H.248.10 (07/2001) 1
>>
>>4.2 Events
>>         4.2.1 MGCongestion
>>                 Event name: MGCon
>>                         EventID: mgcon, (0x0001)
>>                         Description:
>>This event occurs when the MG requires that the MGC start or finish load 
>>reduction
>>towards the MG or to adjust the Load Reduction Percentage. The event is 
>>ordered by the
>>MGC or provisioned.
>>                         EventsDescriptor Parameters: None
>>                         ObservedEventsDescriptor Parameters
>>
>>Thanks,
>>Sampath

--=====================_562241210==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
0 is an arbitrary number and not better then anything else.<br>
As long as an MG and an MGC have a bilateral agreement <br>
what the number is everyone will be happy.<br><br>
I agree that generally pre-provisioned events should be avoided, <br>
but in certain cases events pre-provisioning can have benefits.<br><br>
Consider a large MG which supports CAS and for some reason <br>
termination wildcarding is not an option for requesting initial
events.<br>
In this case pre-provisioning of events will avoid huge number of
Modifies<br>
after a cold boot otherwise needed to be exchanged in order to <br>
setup/arm every termination for CAS.<br><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Aleks<br><br>
At 01:22 PM 1/22/2004, Kevin Boyle wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2>Provisioning
something other than 0 will lead to rejection by the MGC.&nbsp; Further,
provisioning is done at the MG's own risk, as there is no way the MG can
know ahead of time that the MGC supports the package in
question.</font><br>
&nbsp;<br>
<font face="arial" size=2>Basically, the MG can have events provisioned,
but all bets are off as to whether the MGC will accept or reject the
event.&nbsp; My personal feeling is that MGCs should ask for events they
wish to see, and not rely upon any &quot;event
provisioning&quot;.</font><br>
&nbsp;<br>
<font face="arial" size=2>Kevin</font><br><br>

<dl><hr>

<dd><font face="tahoma" size=2>From:</b> Aleksandr Ryabin
[<a href="mailto:kengr@motorola.com" eudora="autourl">mailto:kengr@motorola.com</a>]
<br>

<dd>Sent:</b> Thursday, January 22, 2004 11:19 AM<br>

<dd>To:</b> sampathk@cisco.com; megaco@ietf.org<br>

<dd>Subject:</b> Re: [Megaco] Can chp/mgcon event be persistent
event?<br>
</font><br>

<dd>Hi,<br><br>

<dd>Persistent events in MGCP are defined by package specs.<br>

<dd>Provisioned events in MEGACO are configured by an MG operator.<br>

<dd>As for any descriptor default EventsDescriptor values can be<br>

<dd>provisioned on MG to be non-empty.<br><br>

<dd>The only question here which RequestID to use for such
pre-provisioned events?<br>

<dd>The common consensus on the list was that 0 is a reasonable default
value to <br>

<dd>use in such cases, but of course can also be provisioned to something
else<br>

<dd>by an MG operator.<br><br>

<dd>Regards,<br>

<dd><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Aleks<br><br>

<dd>At 03:20 PM 1/21/2004, Sampath Komanduri wrote:<br>
<blockquote type=cite class=cite cite>
<dd><font face="arial" size=2>Hi all,<br>

<dd>It was my understanding that Megaco doesn't allow any persistent
events. If my understanding is correct... Could someone pls. clarify what
the following paragraph in H.248.10 mean?<br><br>

<dd>ITU-T Rec. H.248.10 (07/2001) 1</font><br>
<font face="arial" size=2><br>

<dd>4.2 Events<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.2.1 MGCongestion<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Event name: MGCon<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventID: mgcon, (0x0001)<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Description:<br>

<dd>This event occurs when the MG requires that the MGC start or finish
load reduction<br>

<dd>towards the MG or to adjust the Load Reduction Percentage. The event
is ordered by the<br>

<dd>MGC or provisioned.</u></b><br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventsDescriptor Parameters: None<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ObservedEventsDescriptor Parameters </font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2>Thanks,</font><br>

<dd><font face="arial" size=2>Sampath</font></blockquote>
</dl></blockquote></body>
</html>

--=====================_562241210==.ALT--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan 22 14:06:54 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05060
	for <megaco-archive@odin.ietf.org>; Thu, 22 Jan 2004 14:06:54 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajk9r-0001AI-6o
	for megaco-archive@odin.ietf.org; Thu, 22 Jan 2004 14:06:27 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MJ6RNF004476
	for megaco-archive@odin.ietf.org; Thu, 22 Jan 2004 14:06:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajk9r-0001A7-3W
	for megaco-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 14:06:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05053
	for <megaco-web-archive@ietf.org>; Thu, 22 Jan 2004 14:06:24 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajk9j-0005TL-00
	for megaco-web-archive@ietf.org; Thu, 22 Jan 2004 14:06:19 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajk7S-0005PV-00
	for megaco-web-archive@ietf.org; Thu, 22 Jan 2004 14:03:59 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajk6q-0005NF-00
	for megaco-web-archive@ietf.org; Thu, 22 Jan 2004 14:03:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajk6X-0000Rs-K7; Thu, 22 Jan 2004 14:03:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajk6K-0000Nq-3Y
	for megaco@optimus.ietf.org; Thu, 22 Jan 2004 14:02:53 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05007
	for <megaco@ietf.org>; Thu, 22 Jan 2004 14:02:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajk6C-0005Mc-00
	for megaco@ietf.org; Thu, 22 Jan 2004 14:02:40 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajk5N-0005LW-00
	for megaco@ietf.org; Thu, 22 Jan 2004 14:01:51 -0500
Received: from ftpbox.mot.com ([129.188.136.101])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajk4U-0005KK-00
	for megaco@ietf.org; Thu, 22 Jan 2004 14:00:54 -0500
Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242])
	by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i0MJ0Kmq018566;
	Thu, 22 Jan 2004 12:00:20 -0700 (MST)
Received: from smilevm.motorola.com ([10.14.25.162])
	by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i0MIrS1Q028627;
	Thu, 22 Jan 2004 12:53:29 -0600
Message-Id: <5.2.1.1.0.20040122134523.0527a6d8@IL06EXM13.corp.mot.com>
X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Thu, 22 Jan 2004 13:53:03 -0500
To: "Kevin Boyle"<kboyle@nortelnetworks.com>, <megaco@ietf.org>
From: Aleksandr Ryabin <kengr@motorola.com>
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Cc: sampathk@cisco.com
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0E022914@zrtpd0jq.us.norte
 l.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_562241210==.ALT"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE 
	autolearn=no version=2.60

--=====================_562241210==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

0 is an arbitrary number and not better then anything else.
As long as an MG and an MGC have a bilateral agreement
what the number is everyone will be happy.

I agree that generally pre-provisioned events should be avoided,
but in certain cases events pre-provisioning can have benefits.

Consider a large MG which supports CAS and for some reason
termination wildcarding is not an option for requesting initial events.
In this case pre-provisioning of events will avoid huge number of Modifies
after a cold boot otherwise needed to be exchanged in order to
setup/arm every termination for CAS.

         Aleks

At 01:22 PM 1/22/2004, Kevin Boyle wrote:
>Provisioning something other than 0 will lead to rejection by the 
>MGC.  Further, provisioning is done at the MG's own risk, as there is no 
>way the MG can know ahead of time that the MGC supports the package in 
>question.
>
>Basically, the MG can have events provisioned, but all bets are off as to 
>whether the MGC will accept or reject the event.  My personal feeling is 
>that MGCs should ask for events they wish to see, and not rely upon any 
>"event provisioning".
>
>Kevin
>
>
>----------
>From: Aleksandr Ryabin [mailto:kengr@motorola.com]
>Sent: Thursday, January 22, 2004 11:19 AM
>To: sampathk@cisco.com; megaco@ietf.org
>Subject: Re: [Megaco] Can chp/mgcon event be persistent event?
>
>Hi,
>
>Persistent events in MGCP are defined by package specs.
>Provisioned events in MEGACO are configured by an MG operator.
>As for any descriptor default EventsDescriptor values can be
>provisioned on MG to be non-empty.
>
>The only question here which RequestID to use for such pre-provisioned events?
>The common consensus on the list was that 0 is a reasonable default value to
>use in such cases, but of course can also be provisioned to something else
>by an MG operator.
>
>Regards,
>         Aleks
>
>At 03:20 PM 1/21/2004, Sampath Komanduri wrote:
>>Hi all,
>>It was my understanding that Megaco doesn't allow any persistent events. 
>>If my understanding is correct... Could someone pls. clarify what the 
>>following paragraph in H.248.10 mean?
>>
>>ITU-T Rec. H.248.10 (07/2001) 1
>>
>>4.2 Events
>>         4.2.1 MGCongestion
>>                 Event name: MGCon
>>                         EventID: mgcon, (0x0001)
>>                         Description:
>>This event occurs when the MG requires that the MGC start or finish load 
>>reduction
>>towards the MG or to adjust the Load Reduction Percentage. The event is 
>>ordered by the
>>MGC or provisioned.
>>                         EventsDescriptor Parameters: None
>>                         ObservedEventsDescriptor Parameters
>>
>>Thanks,
>>Sampath

--=====================_562241210==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
0 is an arbitrary number and not better then anything else.<br>
As long as an MG and an MGC have a bilateral agreement <br>
what the number is everyone will be happy.<br><br>
I agree that generally pre-provisioned events should be avoided, <br>
but in certain cases events pre-provisioning can have benefits.<br><br>
Consider a large MG which supports CAS and for some reason <br>
termination wildcarding is not an option for requesting initial
events.<br>
In this case pre-provisioning of events will avoid huge number of
Modifies<br>
after a cold boot otherwise needed to be exchanged in order to <br>
setup/arm every termination for CAS.<br><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Aleks<br><br>
At 01:22 PM 1/22/2004, Kevin Boyle wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2>Provisioning
something other than 0 will lead to rejection by the MGC.&nbsp; Further,
provisioning is done at the MG's own risk, as there is no way the MG can
know ahead of time that the MGC supports the package in
question.</font><br>
&nbsp;<br>
<font face="arial" size=2>Basically, the MG can have events provisioned,
but all bets are off as to whether the MGC will accept or reject the
event.&nbsp; My personal feeling is that MGCs should ask for events they
wish to see, and not rely upon any &quot;event
provisioning&quot;.</font><br>
&nbsp;<br>
<font face="arial" size=2>Kevin</font><br><br>

<dl><hr>

<dd><font face="tahoma" size=2>From:</b> Aleksandr Ryabin
[<a href="mailto:kengr@motorola.com" eudora="autourl">mailto:kengr@motorola.com</a>]
<br>

<dd>Sent:</b> Thursday, January 22, 2004 11:19 AM<br>

<dd>To:</b> sampathk@cisco.com; megaco@ietf.org<br>

<dd>Subject:</b> Re: [Megaco] Can chp/mgcon event be persistent
event?<br>
</font><br>

<dd>Hi,<br><br>

<dd>Persistent events in MGCP are defined by package specs.<br>

<dd>Provisioned events in MEGACO are configured by an MG operator.<br>

<dd>As for any descriptor default EventsDescriptor values can be<br>

<dd>provisioned on MG to be non-empty.<br><br>

<dd>The only question here which RequestID to use for such
pre-provisioned events?<br>

<dd>The common consensus on the list was that 0 is a reasonable default
value to <br>

<dd>use in such cases, but of course can also be provisioned to something
else<br>

<dd>by an MG operator.<br><br>

<dd>Regards,<br>

<dd><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Aleks<br><br>

<dd>At 03:20 PM 1/21/2004, Sampath Komanduri wrote:<br>
<blockquote type=cite class=cite cite>
<dd><font face="arial" size=2>Hi all,<br>

<dd>It was my understanding that Megaco doesn't allow any persistent
events. If my understanding is correct... Could someone pls. clarify what
the following paragraph in H.248.10 mean?<br><br>

<dd>ITU-T Rec. H.248.10 (07/2001) 1</font><br>
<font face="arial" size=2><br>

<dd>4.2 Events<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.2.1 MGCongestion<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Event name: MGCon<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventID: mgcon, (0x0001)<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Description:<br>

<dd>This event occurs when the MG requires that the MGC start or finish
load reduction<br>

<dd>towards the MG or to adjust the Load Reduction Percentage. The event
is ordered by the<br>

<dd>MGC or provisioned.</u></b><br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventsDescriptor Parameters: None<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ObservedEventsDescriptor Parameters </font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2>Thanks,</font><br>

<dd><font face="arial" size=2>Sampath</font></blockquote>
</dl></blockquote></body>
</html>

--=====================_562241210==.ALT--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan 22 14:24:28 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05545
	for <megaco-archive@lists.ietf.org>; Thu, 22 Jan 2004 14:24:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjkQr-0002b5-8U; Thu, 22 Jan 2004 14:24:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjkQc-0002am-Ix
	for megaco@optimus.ietf.org; Thu, 22 Jan 2004 14:23:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05524
	for <megaco@ietf.org>; Thu, 22 Jan 2004 14:23:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjkQV-0006C4-00
	for megaco@ietf.org; Thu, 22 Jan 2004 14:23:39 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjkNt-000677-00
	for megaco@ietf.org; Thu, 22 Jan 2004 14:20:59 -0500
Received: from motgate3.mot.com ([144.189.100.103])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjkL9-000617-00
	for megaco@ietf.org; Thu, 22 Jan 2004 14:18:07 -0500
Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231])
	by motgate3.mot.com (Motorola/Motgate3) with ESMTP id i0MJGV7U012194;
	Thu, 22 Jan 2004 12:16:31 -0700 (MST)
Received: from smilevm.motorola.com ([10.14.25.162])
	by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i0MJErSS005951;
	Thu, 22 Jan 2004 13:14:54 -0600
Message-Id: <5.2.1.1.0.20040122141012.0338dbd8@IL06EXM13.corp.mot.com>
X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Thu, 22 Jan 2004 14:15:38 -0500
To: <sampathk@cisco.com>, <megaco@ietf.org>
From: Aleksandr Ryabin <kengr@motorola.com>
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
In-Reply-To: <006101c3e118$5bdcfd60$81f847ab@SAMPATHKW2K03>
References: <ABA227A15B80D511BD1A00508BF93A1C0E022914@zrtpd0jq.us.nortel.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_563596448==.ALT"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=HTML_20_30,HTML_FONTCOLOR_BLUE,
	HTML_MESSAGE autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

--=====================_563596448==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi Sampath,

a) MGC can ether accept it, i.e. 1), or reject with error 458 (Unexpected 
Event/RequestID).
b) Any

Regards,
         Aleks

At 01:48 PM 1/22/2004, Sampath Komanduri wrote:
>Aleks and Kevin,
>Thanks for responding. I do understand that in the absence of MGC 
>requested event, if MG has to generate a notification, it would use 
>RequestID 0. However, I don't see anything with respect to RequestID 0 
>handling in the spec. other than the following text in Section 7.2.7:
>     "Procedures for sending Notify commands with RequestID equal to 0 are 
> for futher study."
>
>a) What is the action *required* by the MGC upon recieving a notify with 
>requestID 0?
>     1) Is MGC supposed to do what it would have done if it had explicitly 
> asked for the eventNotification? In our example, is MGC "required" to 
> take the *same actions* to reduce congestion on MG (upon receipt of 
> unsolicited notification) which it would have taken if MGC had 
> "solicited" the notification? OR
>     2) MGC must just respond to the Notification and *not* do anything 
> with respect to helping MG in reducing the congestion.
>     3) MGC can choose to *not* to even respond to the Notify? I hope this 
> is not the case, since it would result in a DISCONNECTED association.
>
>b) Which events qualify to be notified to MGC with RequestID 0?
>     Only events on ROOT? Only event on ROOT and Analog lines? Any events?
>
>It would be good to see some supporting text in the Spec. if the authors 
>decide to leave the support of persistent events in Megaco.
>
>Thanks,
>Sampath
>
>  -----Original Message-----
>From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>Sent: Thursday, January 22, 2004 10:22 AM
>To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
>Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
>
>Provisioning something other than 0 will lead to rejection by the 
>MGC.  Further, provisioning is done at the MG's own risk, as there is no 
>way the MG can know ahead of time that the MGC supports the package in 
>question.
>
>Basically, the MG can have events provisioned, but all bets are off as to 
>whether the MGC will accept or reject the event.  My personal feeling is 
>that MGCs should ask for events they wish to see, and not rely upon any 
>"event provisioning".
>
>Kevin
>
>
>----------
>From: Aleksandr Ryabin [mailto:kengr@motorola.com]
>Sent: Thursday, January 22, 2004 11:19 AM
>To: sampathk@cisco.com; megaco@ietf.org
>Subject: Re: [Megaco] Can chp/mgcon event be persistent event?
>
>Hi,
>
>Persistent events in MGCP are defined by package specs.
>Provisioned events in MEGACO are configured by an MG operator.
>As for any descriptor default EventsDescriptor values can be
>provisioned on MG to be non-empty.
>
>The only question here which RequestID to use for such pre-provisioned events?
>The common consensus on the list was that 0 is a reasonable default value to
>use in such cases, but of course can also be provisioned to something else
>by an MG operator.
>
>Regards,
>         Aleks
>
>At 03:20 PM 1/21/2004, Sampath Komanduri wrote:
>>Hi all,
>>It was my understanding that Megaco doesn't allow any persistent events. 
>>If my understanding is correct... Could someone pls. clarify what the 
>>following paragraph in H.248.10 mean?
>>
>>ITU-T Rec. H.248.10 (07/2001) 1
>>
>>4.2 Events
>>         4.2.1 MGCongestion
>>                 Event name: MGCon
>>                         EventID: mgcon, (0x0001)
>>                         Description:
>>This event occurs when the MG requires that the MGC start or finish load 
>>reduction
>>towards the MG or to adjust the Load Reduction Percentage. The event is 
>>ordered by the
>>MGC or provisioned.
>>                         EventsDescriptor Parameters: None
>>                         ObservedEventsDescriptor Parameters
>>
>>Thanks,
>>Sampath

--=====================_563596448==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Hi Sampath,<br><br>
a) MGC can ether accept it, i.e. 1), or reject with error 458 (Unexpected
Event/RequestID).<br>
b) Any<br><br>
Regards,<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Aleks<br><br>
At 01:48 PM 1/22/2004, Sampath Komanduri wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2 color="#0000FF">Aleks
and Kevin,</font><br>
<font face="arial" size=2 color="#0000FF">Thanks for responding. I do
understand that in the absence of MGC requested event, if MG has to
generate a notification, it would use RequestID 0. However, I don't see
anything with respect to RequestID 0 handling in the spec. other than the
following text in Section 7.2.7:</font><br>
<font face="arial" size=2 color="#0000FF">&nbsp;&nbsp;&nbsp;
&quot;Procedures for sending Notify commands with RequestID equal to 0
are for futher study.&quot;</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">a) What is the action
*required* by the MGC upon recieving a notify with requestID 0?<br>
</font>&nbsp;&nbsp;&nbsp; <font face="arial" size=2 color="#0000FF">1) Is
MGC supposed to do what it would have done if it had explicitly asked for
the eventNotification? In our example, is MGC &quot;required&quot; to
take the *same actions* to reduce congestion on MG (upon receipt of
unsolicited notification) which it would have taken if MGC had
&quot;solicited&quot; the notification? OR</font><br>
&nbsp;&nbsp;&nbsp; <font face="arial" size=2 color="#0000FF">2) MGC must
just respond to the Notification and *not* do anything with respect to
helping MG in reducing the congestion.</font><br>
&nbsp;&nbsp;&nbsp; <font face="arial" size=2 color="#0000FF">3) MGC can
choose to *not* to even respond to the Notify? I hope this is not the
case, since it would result in a DISCONNECTED association.</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">b) Which events qualify to be
notified to MGC with RequestID 0?</font><br>
&nbsp;&nbsp;&nbsp; <font face="arial" size=2 color="#0000FF">Only events
on ROOT? Only event on ROOT and Analog lines? Any events?<br>
</font>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">It would be good to see some
supporting text in the Spec. if the authors decide to leave the support
of persistent events in Megaco.</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Thanks,</font><br>
<font face="arial" size=2 color="#0000FF">Sampath</font><br>

<dl>
<dd><font face="arial" size=2 color="#0000FF">&nbsp;</font><br>

<dd><font face="tahoma" size=2>&nbsp;-----Original Message-----<br>

<dd>From:</b> Kevin Boyle
[<a href="mailto:kboyle@nortelnetworks.com" eudora="autourl">mailto:kboyle@nortelnetworks.com</a>]
<br>

<dd>Sent:</b> Thursday, January 22, 2004 10:22 AM<br>

<dd>To:</b> Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org<br>

<dd>Subject:</b> RE: [Megaco] Can chp/mgcon event be persistent
event?<br><br>
</font>
<dd><font face="arial" size=2>Provisioning something other than 0 will
lead to rejection by the MGC.&nbsp; Further, provisioning is done at the
MG's own risk, as there is no way the MG can know ahead of time that the
MGC supports the package in question.</font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2>Basically, the MG can have events
provisioned, but all bets are off as to whether the MGC will accept or
reject the event.&nbsp; My personal feeling is that MGCs should ask for
events they wish to see, and not rely upon any &quot;event
provisioning&quot;.</font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2>Kevin</font><br><br>
<hr>

<dd><font face="tahoma" size=2>From:</b> Aleksandr Ryabin
[<a href="mailto:kengr@motorola.com" eudora="autourl">mailto:kengr@motorola.com</a>]
<br>

<dd>Sent:</b> Thursday, January 22, 2004 11:19 AM<br>

<dd>To:</b> sampathk@cisco.com; megaco@ietf.org<br>

<dd>Subject:</b> Re: [Megaco] Can chp/mgcon event be persistent
event?<br>
</font><br>

<dd>Hi,<br><br>

<dd>Persistent events in MGCP are defined by package specs.<br>

<dd>Provisioned events in MEGACO are configured by an MG operator.<br>

<dd>As for any descriptor default EventsDescriptor values can be<br>

<dd>provisioned on MG to be non-empty.<br><br>

<dd>The only question here which RequestID to use for such
pre-provisioned events?<br>

<dd>The common consensus on the list was that 0 is a reasonable default
value to <br>

<dd>use in such cases, but of course can also be provisioned to something
else<br>

<dd>by an MG operator.<br><br>

<dd>Regards,<br>

<dd><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Aleks<br><br>

<dd>At 03:20 PM 1/21/2004, Sampath Komanduri wrote:<br>
<blockquote type=cite class=cite cite>
<dd><font face="arial" size=2>Hi all,<br>

<dd>It was my understanding that Megaco doesn't allow any persistent
events. If my understanding is correct... Could someone pls. clarify what
the following paragraph in H.248.10 mean?<br><br>

<dd>ITU-T Rec. H.248.10 (07/2001) 1</font><br>
<font face="arial" size=2><br>

<dd>4.2 Events<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.2.1 MGCongestion<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Event name: MGCon<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventID: mgcon, (0x0001)<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Description:<br>

<dd>This event occurs when the MG requires that the MGC start or finish
load reduction<br>

<dd>towards the MG or to adjust the Load Reduction Percentage. The event
is ordered by the<br>

<dd>MGC or provisioned.</u></b><br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventsDescriptor Parameters: None<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ObservedEventsDescriptor Parameters </font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2>Thanks,</font><br>

<dd><font face="arial" size=2>Sampath</font></blockquote>
</dl></blockquote></body>
</html>

--=====================_563596448==.ALT--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan 22 14:31:07 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05721
	for <megaco-archive@odin.ietf.org>; Thu, 22 Jan 2004 14:31:07 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjkXI-0003Gg-1M
	for megaco-archive@odin.ietf.org; Thu, 22 Jan 2004 14:30:40 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MJUdQX012556
	for megaco-archive@odin.ietf.org; Thu, 22 Jan 2004 14:30:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjkXH-0003GR-SM
	for megaco-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 14:30:39 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05705
	for <megaco-web-archive@ietf.org>; Thu, 22 Jan 2004 14:30:31 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjkX5-000158-00
	for megaco-web-archive@ietf.org; Thu, 22 Jan 2004 14:30:27 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjkTd-0006Jb-00
	for megaco-web-archive@ietf.org; Thu, 22 Jan 2004 14:26:55 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjkR9-0006Cl-00
	for megaco-web-archive@ietf.org; Thu, 22 Jan 2004 14:24:19 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjkQr-0002b5-8U; Thu, 22 Jan 2004 14:24:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjkQc-0002am-Ix
	for megaco@optimus.ietf.org; Thu, 22 Jan 2004 14:23:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05524
	for <megaco@ietf.org>; Thu, 22 Jan 2004 14:23:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjkQV-0006C4-00
	for megaco@ietf.org; Thu, 22 Jan 2004 14:23:39 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjkNt-000677-00
	for megaco@ietf.org; Thu, 22 Jan 2004 14:20:59 -0500
Received: from motgate3.mot.com ([144.189.100.103])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjkL9-000617-00
	for megaco@ietf.org; Thu, 22 Jan 2004 14:18:07 -0500
Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231])
	by motgate3.mot.com (Motorola/Motgate3) with ESMTP id i0MJGV7U012194;
	Thu, 22 Jan 2004 12:16:31 -0700 (MST)
Received: from smilevm.motorola.com ([10.14.25.162])
	by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i0MJErSS005951;
	Thu, 22 Jan 2004 13:14:54 -0600
Message-Id: <5.2.1.1.0.20040122141012.0338dbd8@IL06EXM13.corp.mot.com>
X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Thu, 22 Jan 2004 14:15:38 -0500
To: <sampathk@cisco.com>, <megaco@ietf.org>
From: Aleksandr Ryabin <kengr@motorola.com>
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
In-Reply-To: <006101c3e118$5bdcfd60$81f847ab@SAMPATHKW2K03>
References: <ABA227A15B80D511BD1A00508BF93A1C0E022914@zrtpd0jq.us.nortel.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_563596448==.ALT"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=HTML_20_30,HTML_FONTCOLOR_BLUE,
	HTML_MESSAGE autolearn=no version=2.60

--=====================_563596448==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi Sampath,

a) MGC can ether accept it, i.e. 1), or reject with error 458 (Unexpected 
Event/RequestID).
b) Any

Regards,
         Aleks

At 01:48 PM 1/22/2004, Sampath Komanduri wrote:
>Aleks and Kevin,
>Thanks for responding. I do understand that in the absence of MGC 
>requested event, if MG has to generate a notification, it would use 
>RequestID 0. However, I don't see anything with respect to RequestID 0 
>handling in the spec. other than the following text in Section 7.2.7:
>     "Procedures for sending Notify commands with RequestID equal to 0 are 
> for futher study."
>
>a) What is the action *required* by the MGC upon recieving a notify with 
>requestID 0?
>     1) Is MGC supposed to do what it would have done if it had explicitly 
> asked for the eventNotification? In our example, is MGC "required" to 
> take the *same actions* to reduce congestion on MG (upon receipt of 
> unsolicited notification) which it would have taken if MGC had 
> "solicited" the notification? OR
>     2) MGC must just respond to the Notification and *not* do anything 
> with respect to helping MG in reducing the congestion.
>     3) MGC can choose to *not* to even respond to the Notify? I hope this 
> is not the case, since it would result in a DISCONNECTED association.
>
>b) Which events qualify to be notified to MGC with RequestID 0?
>     Only events on ROOT? Only event on ROOT and Analog lines? Any events?
>
>It would be good to see some supporting text in the Spec. if the authors 
>decide to leave the support of persistent events in Megaco.
>
>Thanks,
>Sampath
>
>  -----Original Message-----
>From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>Sent: Thursday, January 22, 2004 10:22 AM
>To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
>Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
>
>Provisioning something other than 0 will lead to rejection by the 
>MGC.  Further, provisioning is done at the MG's own risk, as there is no 
>way the MG can know ahead of time that the MGC supports the package in 
>question.
>
>Basically, the MG can have events provisioned, but all bets are off as to 
>whether the MGC will accept or reject the event.  My personal feeling is 
>that MGCs should ask for events they wish to see, and not rely upon any 
>"event provisioning".
>
>Kevin
>
>
>----------
>From: Aleksandr Ryabin [mailto:kengr@motorola.com]
>Sent: Thursday, January 22, 2004 11:19 AM
>To: sampathk@cisco.com; megaco@ietf.org
>Subject: Re: [Megaco] Can chp/mgcon event be persistent event?
>
>Hi,
>
>Persistent events in MGCP are defined by package specs.
>Provisioned events in MEGACO are configured by an MG operator.
>As for any descriptor default EventsDescriptor values can be
>provisioned on MG to be non-empty.
>
>The only question here which RequestID to use for such pre-provisioned events?
>The common consensus on the list was that 0 is a reasonable default value to
>use in such cases, but of course can also be provisioned to something else
>by an MG operator.
>
>Regards,
>         Aleks
>
>At 03:20 PM 1/21/2004, Sampath Komanduri wrote:
>>Hi all,
>>It was my understanding that Megaco doesn't allow any persistent events. 
>>If my understanding is correct... Could someone pls. clarify what the 
>>following paragraph in H.248.10 mean?
>>
>>ITU-T Rec. H.248.10 (07/2001) 1
>>
>>4.2 Events
>>         4.2.1 MGCongestion
>>                 Event name: MGCon
>>                         EventID: mgcon, (0x0001)
>>                         Description:
>>This event occurs when the MG requires that the MGC start or finish load 
>>reduction
>>towards the MG or to adjust the Load Reduction Percentage. The event is 
>>ordered by the
>>MGC or provisioned.
>>                         EventsDescriptor Parameters: None
>>                         ObservedEventsDescriptor Parameters
>>
>>Thanks,
>>Sampath

--=====================_563596448==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Hi Sampath,<br><br>
a) MGC can ether accept it, i.e. 1), or reject with error 458 (Unexpected
Event/RequestID).<br>
b) Any<br><br>
Regards,<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Aleks<br><br>
At 01:48 PM 1/22/2004, Sampath Komanduri wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2 color="#0000FF">Aleks
and Kevin,</font><br>
<font face="arial" size=2 color="#0000FF">Thanks for responding. I do
understand that in the absence of MGC requested event, if MG has to
generate a notification, it would use RequestID 0. However, I don't see
anything with respect to RequestID 0 handling in the spec. other than the
following text in Section 7.2.7:</font><br>
<font face="arial" size=2 color="#0000FF">&nbsp;&nbsp;&nbsp;
&quot;Procedures for sending Notify commands with RequestID equal to 0
are for futher study.&quot;</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">a) What is the action
*required* by the MGC upon recieving a notify with requestID 0?<br>
</font>&nbsp;&nbsp;&nbsp; <font face="arial" size=2 color="#0000FF">1) Is
MGC supposed to do what it would have done if it had explicitly asked for
the eventNotification? In our example, is MGC &quot;required&quot; to
take the *same actions* to reduce congestion on MG (upon receipt of
unsolicited notification) which it would have taken if MGC had
&quot;solicited&quot; the notification? OR</font><br>
&nbsp;&nbsp;&nbsp; <font face="arial" size=2 color="#0000FF">2) MGC must
just respond to the Notification and *not* do anything with respect to
helping MG in reducing the congestion.</font><br>
&nbsp;&nbsp;&nbsp; <font face="arial" size=2 color="#0000FF">3) MGC can
choose to *not* to even respond to the Notify? I hope this is not the
case, since it would result in a DISCONNECTED association.</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">b) Which events qualify to be
notified to MGC with RequestID 0?</font><br>
&nbsp;&nbsp;&nbsp; <font face="arial" size=2 color="#0000FF">Only events
on ROOT? Only event on ROOT and Analog lines? Any events?<br>
</font>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">It would be good to see some
supporting text in the Spec. if the authors decide to leave the support
of persistent events in Megaco.</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Thanks,</font><br>
<font face="arial" size=2 color="#0000FF">Sampath</font><br>

<dl>
<dd><font face="arial" size=2 color="#0000FF">&nbsp;</font><br>

<dd><font face="tahoma" size=2>&nbsp;-----Original Message-----<br>

<dd>From:</b> Kevin Boyle
[<a href="mailto:kboyle@nortelnetworks.com" eudora="autourl">mailto:kboyle@nortelnetworks.com</a>]
<br>

<dd>Sent:</b> Thursday, January 22, 2004 10:22 AM<br>

<dd>To:</b> Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org<br>

<dd>Subject:</b> RE: [Megaco] Can chp/mgcon event be persistent
event?<br><br>
</font>
<dd><font face="arial" size=2>Provisioning something other than 0 will
lead to rejection by the MGC.&nbsp; Further, provisioning is done at the
MG's own risk, as there is no way the MG can know ahead of time that the
MGC supports the package in question.</font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2>Basically, the MG can have events
provisioned, but all bets are off as to whether the MGC will accept or
reject the event.&nbsp; My personal feeling is that MGCs should ask for
events they wish to see, and not rely upon any &quot;event
provisioning&quot;.</font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2>Kevin</font><br><br>
<hr>

<dd><font face="tahoma" size=2>From:</b> Aleksandr Ryabin
[<a href="mailto:kengr@motorola.com" eudora="autourl">mailto:kengr@motorola.com</a>]
<br>

<dd>Sent:</b> Thursday, January 22, 2004 11:19 AM<br>

<dd>To:</b> sampathk@cisco.com; megaco@ietf.org<br>

<dd>Subject:</b> Re: [Megaco] Can chp/mgcon event be persistent
event?<br>
</font><br>

<dd>Hi,<br><br>

<dd>Persistent events in MGCP are defined by package specs.<br>

<dd>Provisioned events in MEGACO are configured by an MG operator.<br>

<dd>As for any descriptor default EventsDescriptor values can be<br>

<dd>provisioned on MG to be non-empty.<br><br>

<dd>The only question here which RequestID to use for such
pre-provisioned events?<br>

<dd>The common consensus on the list was that 0 is a reasonable default
value to <br>

<dd>use in such cases, but of course can also be provisioned to something
else<br>

<dd>by an MG operator.<br><br>

<dd>Regards,<br>

<dd><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Aleks<br><br>

<dd>At 03:20 PM 1/21/2004, Sampath Komanduri wrote:<br>
<blockquote type=cite class=cite cite>
<dd><font face="arial" size=2>Hi all,<br>

<dd>It was my understanding that Megaco doesn't allow any persistent
events. If my understanding is correct... Could someone pls. clarify what
the following paragraph in H.248.10 mean?<br><br>

<dd>ITU-T Rec. H.248.10 (07/2001) 1</font><br>
<font face="arial" size=2><br>

<dd>4.2 Events<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.2.1 MGCongestion<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Event name: MGCon<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventID: mgcon, (0x0001)<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Description:<br>

<dd>This event occurs when the MG requires that the MGC start or finish
load reduction<br>

<dd>towards the MG or to adjust the Load Reduction Percentage. The event
is ordered by the<br>

<dd>MGC or provisioned.</u></b><br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventsDescriptor Parameters: None<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ObservedEventsDescriptor Parameters </font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2>Thanks,</font><br>

<dd><font face="arial" size=2>Sampath</font></blockquote>
</dl></blockquote></body>
</html>

--=====================_563596448==.ALT--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan 23 03:28:38 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18240
	for <megaco-archive@lists.ietf.org>; Fri, 23 Jan 2004 03:28:38 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjwfZ-0002Fu-9V; Fri, 23 Jan 2004 03:28:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajwet-00027f-4i
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 03:27:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18213
	for <megaco@ietf.org>; Fri, 23 Jan 2004 03:27:12 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajweg-0004B3-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:27:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajwdh-00049Q-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:26:05 -0500
Received: from [202.41.97.50] (helo=u1.doe.ernet.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjwbW-00047d-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:23:51 -0500
Received: from uucp-relay-delhi.ernet.in (uucp-relay-delhi.ernet.in [202.41.97.134])
	by u1.doe.ernet.in (8.12.8/8.12.8) with ESMTP id i0N8Ei3h013392
	for <megaco@ietf.org>; Fri, 23 Jan 2004 13:44:54 +0530
Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0)
	id OAA05304; Fri, 23 Jan 2004 14:03:29 -0500 (GMT)
>Received: from cancer.cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4)
	id NAA21577; Fri, 23 Jan 2004 13:46:01 -0500
Message-ID: <4010D62B.F77D536F@cdotd.ernet.in>
Date: Fri, 23 Jan 2004 13:37:08 +0530
From: manish rathi <rathi@cdotd.ernet.in>
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.11.00 9000/785)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco <megaco@ietf.org>
Received: from cdotd by vikram.eis.ernet.in; Fri, 23 Jan 2004 14:03 GMT
Content-Type: multipart/alternative;
 boundary="------------F963944CA893DA5F6D209504"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_MESSAGE,
	MSGID_FROM_MTA_HEADER autolearn=no version=2.60
Subject: [Megaco] query
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


--------------F963944CA893DA5F6D209504
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

hi,
Cd u tell me whether any changes required in megaco for 3G mobile
switching center(MSC).
Is there any additional package support?


Thanks
Regards
Manish

--
Things work out best for those who make the best use of it.



--------------F963944CA893DA5F6D209504
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
hi,
<br>Cd u tell me whether any changes required in megaco for 3G mobile switching
center(MSC).
<br>Is there any additional package support?
<br>&nbsp;
<p>Thanks
<br>Regards
<br>Manish
<pre>--&nbsp;
Things work out best for those who make the best use of it.</pre>
&nbsp;</html>

--------------F963944CA893DA5F6D209504--



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan 23 03:32:36 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18365
	for <megaco-archive@odin.ietf.org>; Fri, 23 Jan 2004 03:32:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjwjW-0002eB-GV
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 03:32:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N8W6kp010174
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 03:32:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjwjW-0002dn-0K
	for megaco-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 03:32:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18337
	for <megaco-web-archive@ietf.org>; Fri, 23 Jan 2004 03:32:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjwjT-0004Mh-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 03:32:03 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajwgt-0004HL-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 03:29:23 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajwfv-0004C4-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 03:28:23 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjwfZ-0002Fu-9V; Fri, 23 Jan 2004 03:28:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajwet-00027f-4i
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 03:27:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18213
	for <megaco@ietf.org>; Fri, 23 Jan 2004 03:27:12 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajweg-0004B3-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:27:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajwdh-00049Q-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:26:05 -0500
Received: from [202.41.97.50] (helo=u1.doe.ernet.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjwbW-00047d-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:23:51 -0500
Received: from uucp-relay-delhi.ernet.in (uucp-relay-delhi.ernet.in [202.41.97.134])
	by u1.doe.ernet.in (8.12.8/8.12.8) with ESMTP id i0N8Ei3h013392
	for <megaco@ietf.org>; Fri, 23 Jan 2004 13:44:54 +0530
Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0)
	id OAA05304; Fri, 23 Jan 2004 14:03:29 -0500 (GMT)
>Received: from cancer.cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4)
	id NAA21577; Fri, 23 Jan 2004 13:46:01 -0500
Message-ID: <4010D62B.F77D536F@cdotd.ernet.in>
Date: Fri, 23 Jan 2004 13:37:08 +0530
From: manish rathi <rathi@cdotd.ernet.in>
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.11.00 9000/785)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco <megaco@ietf.org>
Received: from cdotd by vikram.eis.ernet.in; Fri, 23 Jan 2004 14:03 GMT
Content-Type: multipart/alternative;
 boundary="------------F963944CA893DA5F6D209504"
Subject: [Megaco] query
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_MESSAGE,
	MSGID_FROM_MTA_HEADER autolearn=no version=2.60


--------------F963944CA893DA5F6D209504
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

hi,
Cd u tell me whether any changes required in megaco for 3G mobile
switching center(MSC).
Is there any additional package support?


Thanks
Regards
Manish

--
Things work out best for those who make the best use of it.



--------------F963944CA893DA5F6D209504
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
hi,
<br>Cd u tell me whether any changes required in megaco for 3G mobile switching
center(MSC).
<br>Is there any additional package support?
<br>&nbsp;
<p>Thanks
<br>Regards
<br>Manish
<pre>--&nbsp;
Things work out best for those who make the best use of it.</pre>
&nbsp;</html>

--------------F963944CA893DA5F6D209504--



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan 23 03:51:33 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19400
	for <megaco-archive@lists.ietf.org>; Fri, 23 Jan 2004 03:51:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajx1r-0004Gl-Eo; Fri, 23 Jan 2004 03:51:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajx1L-0004Dx-8f
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 03:50:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19242
	for <megaco@ietf.org>; Fri, 23 Jan 2004 03:50:28 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajx1I-0005rF-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:50:28 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajx0J-0005jK-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:49:28 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjwzK-0005be-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:48:26 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0N8lp520752
	for <megaco@ietf.org>; Fri, 23 Jan 2004 03:47:51 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DNYBYPZF>; Fri, 23 Jan 2004 03:47:51 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E0753B5@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Aleksandr Ryabin <kengr@motorola.com>, sampathk@cisco.com, megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Fri, 23 Jan 2004 03:47:51 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Provisioned events and persistent events are two different things.
Persistent events (in the world of MG control) implies that MGCs
automatically know about those events and will handle them at any time --
that is, MGs can depend on having those events handled.  Provisioned events
are items that the MG is set up to detect, but that the MG CANNOT depend on
having handled, as the MGC may not even support the package in question.
 
One other point: MGCs are not required to take any particular action with
regard to a Notify command.  If the Notify comes from a registered MG, then
the MGC ought to reply either affirmatively or with an error.  If the Notify
comes from an unregistered entity, then the MGC reserves the right to send
an error or not respond at all.
 
The key point is that MGs cannot depend upon any particular MGC behavior
when it comes to provisioned events.
 
Kevin


  _____  

From: Aleksandr Ryabin [mailto:kengr@motorola.com] 
Sent: Thursday, January 22, 2004 2:16 PM
To: sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?


Hi Sampath,

a) MGC can ether accept it, i.e. 1), or reject with error 458 (Unexpected
Event/RequestID).
b) Any

Regards,
        Aleks

At 01:48 PM 1/22/2004, Sampath Komanduri wrote:


Aleks and Kevin,
Thanks for responding. I do understand that in the absence of MGC requested
event, if MG has to generate a notification, it would use RequestID 0.
However, I don't see anything with respect to RequestID 0 handling in the
spec. other than the following text in Section 7.2.7:
    "Procedures for sending Notify commands with RequestID equal to 0 are
for futher study."
 
a) What is the action *required* by the MGC upon recieving a notify with
requestID 0?
    1) Is MGC supposed to do what it would have done if it had explicitly
asked for the eventNotification? In our example, is MGC "required" to take
the *same actions* to reduce congestion on MG (upon receipt of unsolicited
notification) which it would have taken if MGC had "solicited" the
notification? OR
    2) MGC must just respond to the Notification and *not* do anything with
respect to helping MG in reducing the congestion.
    3) MGC can choose to *not* to even respond to the Notify? I hope this is
not the case, since it would result in a DISCONNECTED association.
 
b) Which events qualify to be notified to MGC with RequestID 0?
    Only events on ROOT? Only event on ROOT and Analog lines? Any events?
 
It would be good to see some supporting text in the Spec. if the authors
decide to leave the support of persistent events in Megaco.
 
Thanks,
Sampath



  

 -----Original Message-----


From: Kevin Boyle [mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> ] 


Sent: Thursday, January 22, 2004 10:22 AM


To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org


Subject: RE: [Megaco] Can chp/mgcon event be persistent event?



Provisioning something other than 0 will lead to rejection by the MGC.
Further, provisioning is done at the MG's own risk, as there is no way the
MG can know ahead of time that the MGC supports the package in question.



  

Basically, the MG can have events provisioned, but all bets are off as to
whether the MGC will accept or reject the event.  My personal feeling is
that MGCs should ask for events they wish to see, and not rely upon any
"event provisioning".



  

Kevin



  _____  

From: Aleksandr Ryabin [mailto:kengr@motorola.com
<mailto:kengr@motorola.com> ] 


Sent: Thursday, January 22, 2004 11:19 AM


To: sampathk@cisco.com; megaco@ietf.org


Subject: Re: [Megaco] Can chp/mgcon event be persistent event?



Hi,



Persistent events in MGCP are defined by package specs.


Provisioned events in MEGACO are configured by an MG operator.


As for any descriptor default EventsDescriptor values can be


provisioned on MG to be non-empty.



The only question here which RequestID to use for such pre-provisioned
events?


The common consensus on the list was that 0 is a reasonable default value to



use in such cases, but of course can also be provisioned to something else


by an MG operator.



Regards,


        Aleks



At 03:20 PM 1/21/2004, Sampath Komanduri wrote:



Hi all,


It was my understanding that Megaco doesn't allow any persistent events. If
my understanding is correct... Could someone pls. clarify what the following
paragraph in H.248.10 mean?



ITU-T Rec. H.248.10 (07/2001) 1



4.2 Events


        4.2.1 MGCongestion


                Event name: MGCon


                        EventID: mgcon, (0x0001)


                        Description:


This event occurs when the MG requires that the MGC start or finish load
reduction


towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the


MGC or provisioned.


                        EventsDescriptor Parameters: None


                        ObservedEventsDescriptor Parameters 



  

Thanks,


Sampath


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From megaco-admin@ietf.org  Fri Jan 23 03:52:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19447
	for <megaco-archive@lists.ietf.org>; Fri, 23 Jan 2004 03:52:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajx2n-0004Oh-Db; Fri, 23 Jan 2004 03:52:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajx2L-0004O0-3f
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 03:51:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19398
	for <megaco@ietf.org>; Fri, 23 Jan 2004 03:51:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajx2I-0005xJ-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:51:30 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajx1U-0005t2-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:50:40 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajx0b-0005iG-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:49:45 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0N8nF808153
	for <megaco@ietf.org>; Fri, 23 Jan 2004 03:49:15 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DNYBYPZ2>; Fri, 23 Jan 2004 03:49:15 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E0753B7@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: manish rathi <rathi@cdotd.ernet.in>, megaco <megaco@ietf.org>
Subject: RE: [Megaco] query
Date: Fri, 23 Jan 2004 03:49:15 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

3GPP has done quite a bit of work on defining MSC function utilizing H.248
as the base protocol.  I would suggest contacting 3GPP for further
information on protocol and package requirements.
 
Kevin


  _____  

From: manish rathi [mailto:rathi@cdotd.ernet.in] 
Sent: Friday, January 23, 2004 3:07 AM
To: megaco
Subject: [Megaco] query


hi, 
Cd u tell me whether any changes required in megaco for 3G mobile switching
center(MSC). 
Is there any additional package support? 
  

Thanks 
Regards 
Manish 

-- 

Things work out best for those who make the best use of it.
  


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From megaco-admin@ietf.org  Fri Jan 23 03:54:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19542
	for <megaco-archive@lists.ietf.org>; Fri, 23 Jan 2004 03:54:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajx4j-0004Zq-MF; Fri, 23 Jan 2004 03:54:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajx4B-0004YS-Nt
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 03:53:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19501
	for <megaco@ietf.org>; Fri, 23 Jan 2004 03:53:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajx49-00062H-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:53:25 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajx3F-000605-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:52:29 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajx2J-0005vh-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:51:31 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0N8p1808232
	for <megaco@ietf.org>; Fri, 23 Jan 2004 03:51:01 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DNYBYPZK>; Fri, 23 Jan 2004 03:51:01 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E0753B8@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Carl Rutter <crutter@telica.com>, Aleksandr Ryabin
	 <kengr@motorola.com>,
        sampathk@cisco.com, megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Fri, 23 Jan 2004 03:51:01 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

The MGC is capable of sending a wildcarded Modify command requesting the MG
look for events on multiple terminations.  To reduce the message reply size,
the MGC can request a wildcarded response as well.  Is there some further
problem?

Kevin 

-----Original Message-----
From: Carl Rutter [mailto:crutter@telica.com] 
Sent: Thursday, January 22, 2004 1:46 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Aleksandr Ryabin; sampathk@cisco.com;
megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?

I guess my only concern here is the overhead involved in the MGC asking for
events in some cases.
ie) High-Density Gateway running CAS.
As densities increase we may want to foster a better MG event provisioning
approach.

Carl

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Thursday, January 22, 2004 1:22 PM
To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?


Provisioning something other than 0 will lead to rejection by the MGC.
Further, provisioning is done at the MG's own risk, as there is no way the
MG can know ahead of time that the MGC supports the package in question.
 
Basically, the MG can have events provisioned, but all bets are off as to
whether the MGC will accept or reject the event.  My personal feeling is
that MGCs should ask for events they wish to see, and not rely upon any
"event provisioning".
 
Kevin


  _____  

From: Aleksandr Ryabin [mailto:kengr@motorola.com]
Sent: Thursday, January 22, 2004 11:19 AM
To: sampathk@cisco.com; megaco@ietf.org
Subject: Re: [Megaco] Can chp/mgcon event be persistent event?


Hi,

Persistent events in MGCP are defined by package specs.
Provisioned events in MEGACO are configured by an MG operator.
As for any descriptor default EventsDescriptor values can be
provisioned on MG to be non-empty.

The only question here which RequestID to use for such pre-provisioned
events?
The common consensus on the list was that 0 is a reasonable default value to

use in such cases, but of course can also be provisioned to something else
by an MG operator.

Regards,
        Aleks

At 03:20 PM 1/21/2004, Sampath Komanduri wrote:


Hi all,
It was my understanding that Megaco doesn't allow any persistent events. If
my understanding is correct... Could someone pls. clarify what the following
paragraph in H.248.10 mean?

ITU-T Rec. H.248.10 (07/2001) 1

4.2 Events
        4.2.1 MGCongestion
                Event name: MGCon
                        EventID: mgcon, (0x0001)
                        Description:
This event occurs when the MG requires that the MGC start or finish load
reduction
towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the
MGC or provisioned.
                        EventsDescriptor Parameters: None
                        ObservedEventsDescriptor Parameters 
 
Thanks,
Sampath


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From megaco-admin@ietf.org  Fri Jan 23 04:06:32 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19721
	for <megaco-archive@lists.ietf.org>; Fri, 23 Jan 2004 04:06:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjxGM-0005Zq-V9; Fri, 23 Jan 2004 04:06:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjxFt-0005Z0-S4
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 04:05:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19715
	for <megaco@ietf.org>; Fri, 23 Jan 2004 04:05:31 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjxFm-0006HL-00
	for megaco@ietf.org; Fri, 23 Jan 2004 04:05:26 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjxDp-0006G0-00
	for megaco@ietf.org; Fri, 23 Jan 2004 04:03:26 -0500
Received: from ind-iport-1-sec.cisco.com ([64.104.129.9] helo=ind-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjxD1-0006EY-00
	for megaco@ietf.org; Fri, 23 Jan 2004 04:02:36 -0500
Received: from india-core-1.cisco.com (64.104.129.221)
  by ind-iport-1.cisco.com with ESMTP; 23 Jan 2004 20:02:08 +0530
Received: from cisco.com (samrat.cisco.com [192.135.241.21])
	by india-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0N91WLo011278;
	Fri, 23 Jan 2004 01:01:34 -0800 (PST)
Received: from aniljw2k02 (dhcp-10-77-5-168.cisco.com [10.77.5.168])
	by cisco.com (8.11.2/8.8.8) with ESMTP id i0N91Rs25682;
	Fri, 23 Jan 2004 14:31:27 +0530 (IST)
Reply-To: <anilj@cisco.com>
From: "Anil Jangam" <anilj@cisco.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'manish rathi'" <rathi@cdotd.ernet.in>, "'megaco'" <megaco@ietf.org>
Subject: RE: [Megaco] query
Date: Fri, 23 Jan 2004 14:31:33 +0530
Message-ID: <005801c3e18f$7fcd9be0$a8054d0a@apac.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-reply-to: <ABA227A15B80D511BD1A00508BF93A1C0E0753B7@zrtpd0jq.us.nortel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Importance: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

See the 3GPP standard ETSI TS 129 232, which is definiton of the
protocol to be used on the Media Gateway Controller (MGC) - Media
Gateway(MGW) interface. This is called as 'Mc" interface. Also there is
one more standard ETSI TS 123 205, if you need some more information.


> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On 
> Behalf Of Kevin Boyle
> Sent: Friday, January 23, 2004 2:19 PM
> To: manish rathi; megaco
> Subject: RE: [Megaco] query
> 
> 
> 3GPP has done quite a bit of work on defining MSC function 
> utilizing H.248 as the base protocol.  I would suggest 
> contacting 3GPP for further information on protocol and 
> package requirements.
>  
> Kevin
> 
> 
>   _____  
> 
> From: manish rathi [mailto:rathi@cdotd.ernet.in] 
> Sent: Friday, January 23, 2004 3:07 AM
> To: megaco
> Subject: [Megaco] query
> 
> 
> hi, 
> Cd u tell me whether any changes required in megaco for 3G 
> mobile switching center(MSC). 
> Is there any additional package support? 
>   
> 
> Thanks 
> Regards 
> Manish 
> 
> -- 
> 
> Things work out best for those who make the best use of it.
>   
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan 23 04:11:21 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19789
	for <megaco-archive@odin.ietf.org>; Fri, 23 Jan 2004 04:11:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjxL3-00064B-BM
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 04:10:53 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N9Arp8023320
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 04:10:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjxL2-000643-QD
	for megaco-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 04:10:52 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19777
	for <megaco-web-archive@ietf.org>; Fri, 23 Jan 2004 04:10:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjxKv-0006Wj-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 04:10:45 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjxJ0-0006NG-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 04:08:47 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjxGd-0006Jb-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 04:06:19 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjxGM-0005Zq-V9; Fri, 23 Jan 2004 04:06:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjxFt-0005Z0-S4
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 04:05:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19715
	for <megaco@ietf.org>; Fri, 23 Jan 2004 04:05:31 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjxFm-0006HL-00
	for megaco@ietf.org; Fri, 23 Jan 2004 04:05:26 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjxDp-0006G0-00
	for megaco@ietf.org; Fri, 23 Jan 2004 04:03:26 -0500
Received: from ind-iport-1-sec.cisco.com ([64.104.129.9] helo=ind-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjxD1-0006EY-00
	for megaco@ietf.org; Fri, 23 Jan 2004 04:02:36 -0500
Received: from india-core-1.cisco.com (64.104.129.221)
  by ind-iport-1.cisco.com with ESMTP; 23 Jan 2004 20:02:08 +0530
Received: from cisco.com (samrat.cisco.com [192.135.241.21])
	by india-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0N91WLo011278;
	Fri, 23 Jan 2004 01:01:34 -0800 (PST)
Received: from aniljw2k02 (dhcp-10-77-5-168.cisco.com [10.77.5.168])
	by cisco.com (8.11.2/8.8.8) with ESMTP id i0N91Rs25682;
	Fri, 23 Jan 2004 14:31:27 +0530 (IST)
Reply-To: <anilj@cisco.com>
From: "Anil Jangam" <anilj@cisco.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'manish rathi'" <rathi@cdotd.ernet.in>, "'megaco'" <megaco@ietf.org>
Subject: RE: [Megaco] query
Date: Fri, 23 Jan 2004 14:31:33 +0530
Message-ID: <005801c3e18f$7fcd9be0$a8054d0a@apac.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-reply-to: <ABA227A15B80D511BD1A00508BF93A1C0E0753B7@zrtpd0jq.us.nortel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

See the 3GPP standard ETSI TS 129 232, which is definiton of the
protocol to be used on the Media Gateway Controller (MGC) - Media
Gateway(MGW) interface. This is called as 'Mc" interface. Also there is
one more standard ETSI TS 123 205, if you need some more information.


> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On 
> Behalf Of Kevin Boyle
> Sent: Friday, January 23, 2004 2:19 PM
> To: manish rathi; megaco
> Subject: RE: [Megaco] query
> 
> 
> 3GPP has done quite a bit of work on defining MSC function 
> utilizing H.248 as the base protocol.  I would suggest 
> contacting 3GPP for further information on protocol and 
> package requirements.
>  
> Kevin
> 
> 
>   _____  
> 
> From: manish rathi [mailto:rathi@cdotd.ernet.in] 
> Sent: Friday, January 23, 2004 3:07 AM
> To: megaco
> Subject: [Megaco] query
> 
> 
> hi, 
> Cd u tell me whether any changes required in megaco for 3G 
> mobile switching center(MSC). 
> Is there any additional package support? 
>   
> 
> Thanks 
> Regards 
> Manish 
> 
> -- 
> 
> Things work out best for those who make the best use of it.
>   
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From exim@www1.ietf.org  Fri Jan 23 04:17:35 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19991
	for <megaco-archive@odin.ietf.org>; Fri, 23 Jan 2004 04:17:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjxR0-0006Js-6J
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 04:17:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N9H22c024290
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 04:17:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjxQz-0006Jh-NP
	for megaco-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 04:17:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19961
	for <megaco-web-archive@ietf.org>; Fri, 23 Jan 2004 04:16:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjxQm-0006tI-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 04:16:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjxLF-0006XN-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 04:11:06 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjxJ4-0006Lr-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 04:08:50 -0500
Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org)
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1Ajx4l-0002VW-LU
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 03:54:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajx4j-0004Zq-MF; Fri, 23 Jan 2004 03:54:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajx4B-0004YS-Nt
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 03:53:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19501
	for <megaco@ietf.org>; Fri, 23 Jan 2004 03:53:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajx49-00062H-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:53:25 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajx3F-000605-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:52:29 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajx2J-0005vh-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:51:31 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0N8p1808232
	for <megaco@ietf.org>; Fri, 23 Jan 2004 03:51:01 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DNYBYPZK>; Fri, 23 Jan 2004 03:51:01 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E0753B8@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Carl Rutter <crutter@telica.com>, Aleksandr Ryabin
	 <kengr@motorola.com>,
        sampathk@cisco.com, megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Fri, 23 Jan 2004 03:51:01 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60

The MGC is capable of sending a wildcarded Modify command requesting the MG
look for events on multiple terminations.  To reduce the message reply size,
the MGC can request a wildcarded response as well.  Is there some further
problem?

Kevin 

-----Original Message-----
From: Carl Rutter [mailto:crutter@telica.com] 
Sent: Thursday, January 22, 2004 1:46 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Aleksandr Ryabin; sampathk@cisco.com;
megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?

I guess my only concern here is the overhead involved in the MGC asking for
events in some cases.
ie) High-Density Gateway running CAS.
As densities increase we may want to foster a better MG event provisioning
approach.

Carl

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Thursday, January 22, 2004 1:22 PM
To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?


Provisioning something other than 0 will lead to rejection by the MGC.
Further, provisioning is done at the MG's own risk, as there is no way the
MG can know ahead of time that the MGC supports the package in question.
 
Basically, the MG can have events provisioned, but all bets are off as to
whether the MGC will accept or reject the event.  My personal feeling is
that MGCs should ask for events they wish to see, and not rely upon any
"event provisioning".
 
Kevin


  _____  

From: Aleksandr Ryabin [mailto:kengr@motorola.com]
Sent: Thursday, January 22, 2004 11:19 AM
To: sampathk@cisco.com; megaco@ietf.org
Subject: Re: [Megaco] Can chp/mgcon event be persistent event?


Hi,

Persistent events in MGCP are defined by package specs.
Provisioned events in MEGACO are configured by an MG operator.
As for any descriptor default EventsDescriptor values can be
provisioned on MG to be non-empty.

The only question here which RequestID to use for such pre-provisioned
events?
The common consensus on the list was that 0 is a reasonable default value to

use in such cases, but of course can also be provisioned to something else
by an MG operator.

Regards,
        Aleks

At 03:20 PM 1/21/2004, Sampath Komanduri wrote:


Hi all,
It was my understanding that Megaco doesn't allow any persistent events. If
my understanding is correct... Could someone pls. clarify what the following
paragraph in H.248.10 mean?

ITU-T Rec. H.248.10 (07/2001) 1

4.2 Events
        4.2.1 MGCongestion
                Event name: MGCon
                        EventID: mgcon, (0x0001)
                        Description:
This event occurs when the MG requires that the MGC start or finish load
reduction
towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the
MGC or provisioned.
                        EventsDescriptor Parameters: None
                        ObservedEventsDescriptor Parameters 
 
Thanks,
Sampath


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From exim@www1.ietf.org  Fri Jan 23 04:19:07 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20062
	for <megaco-archive@odin.ietf.org>; Fri, 23 Jan 2004 04:19:07 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjxSV-0006SF-47
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 04:18:35 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N9IZ2X024805
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 04:18:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjxSU-0006S0-UX
	for megaco-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 04:18:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20030
	for <megaco-web-archive@ietf.org>; Fri, 23 Jan 2004 04:18:22 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjxSD-00070B-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 04:18:17 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjxN4-0006cG-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 04:12:59 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjxJf-0006Lu-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 04:09:27 -0500
Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org)
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1Ajx2o-0002LW-II
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 03:52:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajx2n-0004Oh-Db; Fri, 23 Jan 2004 03:52:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajx2L-0004O0-3f
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 03:51:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19398
	for <megaco@ietf.org>; Fri, 23 Jan 2004 03:51:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajx2I-0005xJ-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:51:30 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajx1U-0005t2-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:50:40 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajx0b-0005iG-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:49:45 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0N8nF808153
	for <megaco@ietf.org>; Fri, 23 Jan 2004 03:49:15 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DNYBYPZ2>; Fri, 23 Jan 2004 03:49:15 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E0753B7@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: manish rathi <rathi@cdotd.ernet.in>, megaco <megaco@ietf.org>
Subject: RE: [Megaco] query
Date: Fri, 23 Jan 2004 03:49:15 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60

3GPP has done quite a bit of work on defining MSC function utilizing H.248
as the base protocol.  I would suggest contacting 3GPP for further
information on protocol and package requirements.
 
Kevin


  _____  

From: manish rathi [mailto:rathi@cdotd.ernet.in] 
Sent: Friday, January 23, 2004 3:07 AM
To: megaco
Subject: [Megaco] query


hi, 
Cd u tell me whether any changes required in megaco for 3G mobile switching
center(MSC). 
Is there any additional package support? 
  

Thanks 
Regards 
Manish 

-- 

Things work out best for those who make the best use of it.
  


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From exim@www1.ietf.org  Fri Jan 23 04:21:13 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20182
	for <megaco-archive@odin.ietf.org>; Fri, 23 Jan 2004 04:21:13 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjxUc-0006fw-2k
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 04:20:46 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N9KjHm025654
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 04:20:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjxUb-0006fh-LF
	for megaco-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 04:20:45 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20154
	for <megaco-web-archive@ietf.org>; Fri, 23 Jan 2004 04:20:42 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjxUT-00079h-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 04:20:37 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjxQ4-0006lZ-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 04:16:05 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjxKD-0006Lr-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 04:10:01 -0500
Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org)
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1Ajx1u-0002G3-PT
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 03:51:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajx1r-0004Gl-Eo; Fri, 23 Jan 2004 03:51:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ajx1L-0004Dx-8f
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 03:50:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19242
	for <megaco@ietf.org>; Fri, 23 Jan 2004 03:50:28 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ajx1I-0005rF-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:50:28 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ajx0J-0005jK-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:49:28 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjwzK-0005be-00
	for megaco@ietf.org; Fri, 23 Jan 2004 03:48:26 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0N8lp520752
	for <megaco@ietf.org>; Fri, 23 Jan 2004 03:47:51 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DNYBYPZF>; Fri, 23 Jan 2004 03:47:51 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E0753B5@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Aleksandr Ryabin <kengr@motorola.com>, sampathk@cisco.com, megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Fri, 23 Jan 2004 03:47:51 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60

Provisioned events and persistent events are two different things.
Persistent events (in the world of MG control) implies that MGCs
automatically know about those events and will handle them at any time --
that is, MGs can depend on having those events handled.  Provisioned events
are items that the MG is set up to detect, but that the MG CANNOT depend on
having handled, as the MGC may not even support the package in question.
 
One other point: MGCs are not required to take any particular action with
regard to a Notify command.  If the Notify comes from a registered MG, then
the MGC ought to reply either affirmatively or with an error.  If the Notify
comes from an unregistered entity, then the MGC reserves the right to send
an error or not respond at all.
 
The key point is that MGs cannot depend upon any particular MGC behavior
when it comes to provisioned events.
 
Kevin


  _____  

From: Aleksandr Ryabin [mailto:kengr@motorola.com] 
Sent: Thursday, January 22, 2004 2:16 PM
To: sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?


Hi Sampath,

a) MGC can ether accept it, i.e. 1), or reject with error 458 (Unexpected
Event/RequestID).
b) Any

Regards,
        Aleks

At 01:48 PM 1/22/2004, Sampath Komanduri wrote:


Aleks and Kevin,
Thanks for responding. I do understand that in the absence of MGC requested
event, if MG has to generate a notification, it would use RequestID 0.
However, I don't see anything with respect to RequestID 0 handling in the
spec. other than the following text in Section 7.2.7:
    "Procedures for sending Notify commands with RequestID equal to 0 are
for futher study."
 
a) What is the action *required* by the MGC upon recieving a notify with
requestID 0?
    1) Is MGC supposed to do what it would have done if it had explicitly
asked for the eventNotification? In our example, is MGC "required" to take
the *same actions* to reduce congestion on MG (upon receipt of unsolicited
notification) which it would have taken if MGC had "solicited" the
notification? OR
    2) MGC must just respond to the Notification and *not* do anything with
respect to helping MG in reducing the congestion.
    3) MGC can choose to *not* to even respond to the Notify? I hope this is
not the case, since it would result in a DISCONNECTED association.
 
b) Which events qualify to be notified to MGC with RequestID 0?
    Only events on ROOT? Only event on ROOT and Analog lines? Any events?
 
It would be good to see some supporting text in the Spec. if the authors
decide to leave the support of persistent events in Megaco.
 
Thanks,
Sampath



  

 -----Original Message-----


From: Kevin Boyle [mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> ] 


Sent: Thursday, January 22, 2004 10:22 AM


To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org


Subject: RE: [Megaco] Can chp/mgcon event be persistent event?



Provisioning something other than 0 will lead to rejection by the MGC.
Further, provisioning is done at the MG's own risk, as there is no way the
MG can know ahead of time that the MGC supports the package in question.



  

Basically, the MG can have events provisioned, but all bets are off as to
whether the MGC will accept or reject the event.  My personal feeling is
that MGCs should ask for events they wish to see, and not rely upon any
"event provisioning".



  

Kevin



  _____  

From: Aleksandr Ryabin [mailto:kengr@motorola.com
<mailto:kengr@motorola.com> ] 


Sent: Thursday, January 22, 2004 11:19 AM


To: sampathk@cisco.com; megaco@ietf.org


Subject: Re: [Megaco] Can chp/mgcon event be persistent event?



Hi,



Persistent events in MGCP are defined by package specs.


Provisioned events in MEGACO are configured by an MG operator.


As for any descriptor default EventsDescriptor values can be


provisioned on MG to be non-empty.



The only question here which RequestID to use for such pre-provisioned
events?


The common consensus on the list was that 0 is a reasonable default value to



use in such cases, but of course can also be provisioned to something else


by an MG operator.



Regards,


        Aleks



At 03:20 PM 1/21/2004, Sampath Komanduri wrote:



Hi all,


It was my understanding that Megaco doesn't allow any persistent events. If
my understanding is correct... Could someone pls. clarify what the following
paragraph in H.248.10 mean?



ITU-T Rec. H.248.10 (07/2001) 1



4.2 Events


        4.2.1 MGCongestion


                Event name: MGCon


                        EventID: mgcon, (0x0001)


                        Description:


This event occurs when the MG requires that the MGC start or finish load
reduction


towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the


MGC or provisioned.


                        EventsDescriptor Parameters: None


                        ObservedEventsDescriptor Parameters 



  

Thanks,


Sampath


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan 23 07:52:31 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28417
	for <megaco-archive@lists.ietf.org>; Fri, 23 Jan 2004 07:52:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak0n2-0000Ft-Qp; Fri, 23 Jan 2004 07:52:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak0mc-0000Ex-UF
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 07:51:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28388
	for <megaco@ietf.org>; Fri, 23 Jan 2004 07:51:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak0mc-0003c9-00
	for megaco@ietf.org; Fri, 23 Jan 2004 07:51:34 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ak0lg-0003bR-00
	for megaco@ietf.org; Fri, 23 Jan 2004 07:50:37 -0500
Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak0l2-0003ah-00
	for megaco@ietf.org; Fri, 23 Jan 2004 07:49:56 -0500
Received: from UPSTAIRSPC ([10.0.201.16]) by wench.telica.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XM89YDC3; Fri, 23 Jan 2004 07:49:55 -0500
From: "Carl Rutter" <crutter@telica.com>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>,
        "Aleksandr Ryabin" <kengr@motorola.com>, <sampathk@cisco.com>,
        <megaco@ietf.org>
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Fri, 23 Jan 2004 07:50:13 -0500
Message-ID: <GBEBJGNFEADJDNANKJIKGEELCAAA.crutter@telica.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-reply-to: <ABA227A15B80D511BD1A00508BF93A1C0E0753B5@zrtpd0jq.us.nortel.com>
Importance: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Kevin,

How would the MGC request a persistent event?
I think this is what we are looking for.
Events that hang around even after the
termination is subtracted back to the NULL context.

Thx,
Carl

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
Kevin Boyle
Sent: Friday, January 23, 2004 3:48 AM
To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?


Provisioned events and persistent events are two different things.
Persistent events (in the world of MG control) implies that MGCs
automatically know about those events and will handle them at any time --
that is, MGs can depend on having those events handled.  Provisioned events
are items that the MG is set up to detect, but that the MG CANNOT depend on
having handled, as the MGC may not even support the package in question.

One other point: MGCs are not required to take any particular action with
regard to a Notify command.  If the Notify comes from a registered MG, then
the MGC ought to reply either affirmatively or with an error.  If the Notify
comes from an unregistered entity, then the MGC reserves the right to send
an error or not respond at all.

The key point is that MGs cannot depend upon any particular MGC behavior
when it comes to provisioned events.

Kevin


  _____

From: Aleksandr Ryabin [mailto:kengr@motorola.com]
Sent: Thursday, January 22, 2004 2:16 PM
To: sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?


Hi Sampath,

a) MGC can ether accept it, i.e. 1), or reject with error 458 (Unexpected
Event/RequestID).
b) Any

Regards,
        Aleks

At 01:48 PM 1/22/2004, Sampath Komanduri wrote:


Aleks and Kevin,
Thanks for responding. I do understand that in the absence of MGC requested
event, if MG has to generate a notification, it would use RequestID 0.
However, I don't see anything with respect to RequestID 0 handling in the
spec. other than the following text in Section 7.2.7:
    "Procedures for sending Notify commands with RequestID equal to 0 are
for futher study."

a) What is the action *required* by the MGC upon recieving a notify with
requestID 0?
    1) Is MGC supposed to do what it would have done if it had explicitly
asked for the eventNotification? In our example, is MGC "required" to take
the *same actions* to reduce congestion on MG (upon receipt of unsolicited
notification) which it would have taken if MGC had "solicited" the
notification? OR
    2) MGC must just respond to the Notification and *not* do anything with
respect to helping MG in reducing the congestion.
    3) MGC can choose to *not* to even respond to the Notify? I hope this is
not the case, since it would result in a DISCONNECTED association.

b) Which events qualify to be notified to MGC with RequestID 0?
    Only events on ROOT? Only event on ROOT and Analog lines? Any events?

It would be good to see some supporting text in the Spec. if the authors
decide to leave the support of persistent events in Megaco.

Thanks,
Sampath





 -----Original Message-----


From: Kevin Boyle [mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> ]


Sent: Thursday, January 22, 2004 10:22 AM


To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org


Subject: RE: [Megaco] Can chp/mgcon event be persistent event?



Provisioning something other than 0 will lead to rejection by the MGC.
Further, provisioning is done at the MG's own risk, as there is no way the
MG can know ahead of time that the MGC supports the package in question.





Basically, the MG can have events provisioned, but all bets are off as to
whether the MGC will accept or reject the event.  My personal feeling is
that MGCs should ask for events they wish to see, and not rely upon any
"event provisioning".





Kevin



  _____

From: Aleksandr Ryabin [mailto:kengr@motorola.com
<mailto:kengr@motorola.com> ]


Sent: Thursday, January 22, 2004 11:19 AM


To: sampathk@cisco.com; megaco@ietf.org


Subject: Re: [Megaco] Can chp/mgcon event be persistent event?



Hi,



Persistent events in MGCP are defined by package specs.


Provisioned events in MEGACO are configured by an MG operator.


As for any descriptor default EventsDescriptor values can be


provisioned on MG to be non-empty.



The only question here which RequestID to use for such pre-provisioned
events?


The common consensus on the list was that 0 is a reasonable default value to



use in such cases, but of course can also be provisioned to something else


by an MG operator.



Regards,


        Aleks



At 03:20 PM 1/21/2004, Sampath Komanduri wrote:



Hi all,


It was my understanding that Megaco doesn't allow any persistent events. If
my understanding is correct... Could someone pls. clarify what the following
paragraph in H.248.10 mean?



ITU-T Rec. H.248.10 (07/2001) 1



4.2 Events


        4.2.1 MGCongestion


                Event name: MGCon


                        EventID: mgcon, (0x0001)


                        Description:


This event occurs when the MG requires that the MGC start or finish load
reduction


towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the


MGC or provisioned.


                        EventsDescriptor Parameters: None


                        ObservedEventsDescriptor Parameters





Thanks,


Sampath


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From megaco-admin@ietf.org  Fri Jan 23 07:55:32 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28503
	for <megaco-archive@lists.ietf.org>; Fri, 23 Jan 2004 07:55:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak0py-0000eR-Ux; Fri, 23 Jan 2004 07:55:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak0pX-0000Uo-BE
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 07:54:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28472
	for <megaco@ietf.org>; Fri, 23 Jan 2004 07:54:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak0pW-0003em-00
	for megaco@ietf.org; Fri, 23 Jan 2004 07:54:34 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ak0ob-0003dv-00
	for megaco@ietf.org; Fri, 23 Jan 2004 07:53:38 -0500
Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak0o5-0003dJ-00
	for megaco@ietf.org; Fri, 23 Jan 2004 07:53:05 -0500
Received: from UPSTAIRSPC ([10.0.201.16]) by wench.telica.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XM89YDCY; Fri, 23 Jan 2004 07:53:02 -0500
From: "Carl Rutter" <crutter@telica.com>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>,
        "Carl Rutter" <crutter@telica.com>,
        "Aleksandr Ryabin" <kengr@motorola.com>, <sampathk@cisco.com>,
        <megaco@ietf.org>
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Fri, 23 Jan 2004 07:53:21 -0500
Message-ID: <GBEBJGNFEADJDNANKJIKKEELCAAA.crutter@telica.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0010_01C3E185.F89CEE40"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-reply-to: <ABA227A15B80D511BD1A00508BF93A1C0E0753B8@zrtpd0jq.us.nortel.com>
Importance: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01C3E185.F89CEE40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: [Megaco] Can chp/mgcon event be persistent event?Yea,

On a large scale system we may want to apply different events
to many different T1s as they go back to the null context.
You mentioned persistent events from the MGC which
sounds like something we are looking for.

Thx,
Carl
  -----Original Message-----
  From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
  Sent: Friday, January 23, 2004 3:51 AM
  To: Carl Rutter; Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
  Subject: RE: [Megaco] Can chp/mgcon event be persistent event?


  The MGC is capable of sending a wildcarded Modify command requesting the
MG look for events on multiple terminations.  To reduce the message reply
size, the MGC can request a wildcarded response as well.  Is there some
further problem?

  Kevin

  -----Original Message-----
  From: Carl Rutter [mailto:crutter@telica.com]
  Sent: Thursday, January 22, 2004 1:46 PM
  To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Aleksandr Ryabin; sampathk@cisco.com;
megaco@ietf.org
  Subject: RE: [Megaco] Can chp/mgcon event be persistent event?

  I guess my only concern here is the overhead involved in the MGC asking
for events in some cases.
  ie) High-Density Gateway running CAS.
  As densities increase we may want to foster a better MG event provisioning
approach.

  Carl

  -----Original Message-----
  From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
  Sent: Thursday, January 22, 2004 1:22 PM
  To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
  Subject: RE: [Megaco] Can chp/mgcon event be persistent event?



  Provisioning something other than 0 will lead to rejection by the MGC.
  Further, provisioning is done at the MG's own risk, as there is no way the
MG can know ahead of time that the MGC supports the package in question.


  Basically, the MG can have events provisioned, but all bets are off as to
whether the MGC will accept or reject the event.  My personal feeling is
that MGCs should ask for events they wish to see, and not rely upon any
"event provisioning".


  Kevin



    _____

  From: Aleksandr Ryabin [mailto:kengr@motorola.com]
  Sent: Thursday, January 22, 2004 11:19 AM
  To: sampathk@cisco.com; megaco@ietf.org
  Subject: Re: [Megaco] Can chp/mgcon event be persistent event?



  Hi,

  Persistent events in MGCP are defined by package specs.
  Provisioned events in MEGACO are configured by an MG operator.
  As for any descriptor default EventsDescriptor values can be
  provisioned on MG to be non-empty.

  The only question here which RequestID to use for such pre-provisioned
  events?
  The common consensus on the list was that 0 is a reasonable default value
to

  use in such cases, but of course can also be provisioned to something else
  by an MG operator.

  Regards,
          Aleks

  At 03:20 PM 1/21/2004, Sampath Komanduri wrote:



  Hi all,
  It was my understanding that Megaco doesn't allow any persistent events.
If
  my understanding is correct... Could someone pls. clarify what the
following
  paragraph in H.248.10 mean?

  ITU-T Rec. H.248.10 (07/2001) 1

  4.2 Events
          4.2.1 MGCongestion
                  Event name: MGCon
                          EventID: mgcon, (0x0001)
                          Description:
  This event occurs when the MG requires that the MGC start or finish load
  reduction
  towards the MG or to adjust the Load Reduction Percentage. The event is
  ordered by the
  MGC or provisioned.
                          EventsDescriptor Parameters: None
                          ObservedEventsDescriptor Parameters

  Thanks,
  Sampath



  _______________________________________________
  Megaco mailing list
  Megaco@ietf.org
  https://www1.ietf.org/mailman/listinfo/megaco

------=_NextPart_000_0010_01C3E185.F89CEE40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [Megaco] Can chp/mgcon event be persistent =
event?</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D226485012-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Yea,</FONT></SPAN></DIV>
<DIV><SPAN class=3D226485012-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D226485012-23012004><FONT face=3DArial color=3D#0000ff =
size=3D2>On a=20
large scale system we may want to apply different events =
</FONT></SPAN></DIV>
<DIV><SPAN class=3D226485012-23012004><FONT face=3DArial color=3D#0000ff =
size=3D2>to=20
many different T1s as they go back to the null =
context.</FONT></SPAN></DIV>
<DIV><SPAN class=3D226485012-23012004><FONT face=3DArial color=3D#0000ff =
size=3D2>You=20
mentioned persistent events from the MGC which </FONT></SPAN></DIV>
<DIV><SPAN class=3D226485012-23012004><FONT face=3DArial color=3D#0000ff =
size=3D2>sounds=20
like something we are looking for.</FONT></SPAN></DIV>
<DIV><SPAN class=3D226485012-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D226485012-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Thx,</FONT></SPAN></DIV>
<DIV><SPAN class=3D226485012-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Carl</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Kevin Boyle=20
  [mailto:kboyle@nortelnetworks.com]<BR><B>Sent:</B> Friday, January 23, =
2004=20
  3:51 AM<BR><B>To:</B> Carl Rutter; Aleksandr Ryabin; =
sampathk@cisco.com;=20
  megaco@ietf.org<BR><B>Subject:</B> RE: [Megaco] Can chp/mgcon event be =

  persistent event?<BR><BR></FONT></DIV>
  <P><FONT size=3D2>The MGC is capable of sending a wildcarded Modify =
command=20
  requesting the MG look for events on multiple terminations.&nbsp; To =
reduce=20
  the message reply size, the MGC can request a wildcarded response as=20
  well.&nbsp; Is there some further problem?</FONT></P>
  <P><FONT size=3D2>Kevin </FONT></P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: Carl=20
  Rutter [<A =
href=3D"mailto:crutter@telica.com">mailto:crutter@telica.com</A>]=20
  </FONT><BR><FONT size=3D2>Sent: Thursday, January 22, 2004 1:46 =
PM</FONT>=20
  <BR><FONT size=3D2>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Aleksandr =
Ryabin;=20
  sampathk@cisco.com; megaco@ietf.org</FONT> <BR><FONT size=3D2>Subject: =
RE:=20
  [Megaco] Can chp/mgcon event be persistent event?</FONT> </P>
  <P><FONT size=3D2>I guess my only concern here is the overhead =
involved in the=20
  MGC asking for events in some cases.</FONT> <BR><FONT size=3D2>ie) =
High-Density=20
  Gateway running CAS.</FONT> <BR><FONT size=3D2>As densities increase =
we may want=20
  to foster a better MG event provisioning approach.</FONT> </P>
  <P><FONT size=3D2>Carl</FONT> </P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: Kevin=20
  Boyle [<A=20
  =
href=3D"mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.co=
m</A>]</FONT>=20
  <BR><FONT size=3D2>Sent: Thursday, January 22, 2004 1:22 PM</FONT> =
<BR><FONT=20
  size=3D2>To: Aleksandr Ryabin; sampathk@cisco.com; =
megaco@ietf.org</FONT>=20
  <BR><FONT size=3D2>Subject: RE: [Megaco] Can chp/mgcon event be =
persistent=20
  event?</FONT> </P><BR>
  <P><FONT size=3D2>Provisioning something other than 0 will lead to =
rejection by=20
  the MGC.</FONT> <BR><FONT size=3D2>Further, provisioning is done at =
the MG's own=20
  risk, as there is no way the MG can know ahead of time that the MGC =
supports=20
  the package in question.</FONT></P>
  <P><FONT size=3D2></FONT> <BR><FONT size=3D2>Basically, the MG can =
have events=20
  provisioned, but all bets are off as to whether the MGC will accept or =
reject=20
  the event.&nbsp; My personal feeling is that MGCs should ask for =
events they=20
  wish to see, and not rely upon any "event provisioning".</FONT></P>
  <P><FONT size=3D2></FONT> <BR><FONT size=3D2>Kevin</FONT> </P><BR>
  <P><FONT size=3D2>&nbsp; _____&nbsp; </FONT></P>
  <P><FONT size=3D2>From: Aleksandr Ryabin [<A=20
  =
href=3D"mailto:kengr@motorola.com">mailto:kengr@motorola.com</A>]</FONT> =

  <BR><FONT size=3D2>Sent: Thursday, January 22, 2004 11:19 AM</FONT> =
<BR><FONT=20
  size=3D2>To: sampathk@cisco.com; megaco@ietf.org</FONT> <BR><FONT=20
  size=3D2>Subject: Re: [Megaco] Can chp/mgcon event be persistent =
event?</FONT>=20
  </P><BR>
  <P><FONT size=3D2>Hi,</FONT> </P>
  <P><FONT size=3D2>Persistent events in MGCP are defined by package =
specs.</FONT>=20
  <BR><FONT size=3D2>Provisioned events in MEGACO are configured by an =
MG=20
  operator.</FONT> <BR><FONT size=3D2>As for any descriptor default=20
  EventsDescriptor values can be</FONT> <BR><FONT size=3D2>provisioned =
on MG to be=20
  non-empty.</FONT> </P>
  <P><FONT size=3D2>The only question here which RequestID to use for =
such=20
  pre-provisioned</FONT> <BR><FONT size=3D2>events?</FONT> <BR><FONT =
size=3D2>The=20
  common consensus on the list was that 0 is a reasonable default value=20
  to</FONT> </P>
  <P><FONT size=3D2>use in such cases, but of course can also be =
provisioned to=20
  something else</FONT> <BR><FONT size=3D2>by an MG operator.</FONT> =
</P>
  <P><FONT size=3D2>Regards,</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Aleks</FONT> </P>
  <P><FONT size=3D2>At 03:20 PM 1/21/2004, Sampath Komanduri =
wrote:</FONT>=20
</P><BR>
  <P><FONT size=3D2>Hi all,</FONT> <BR><FONT size=3D2>It was my =
understanding that=20
  Megaco doesn't allow any persistent events. If</FONT> <BR><FONT =
size=3D2>my=20
  understanding is correct... Could someone pls. clarify what the=20
  following</FONT> <BR><FONT size=3D2>paragraph in H.248.10 mean?</FONT> =
</P>
  <P><FONT size=3D2>ITU-T Rec. H.248.10 (07/2001) 1</FONT> </P>
  <P><FONT size=3D2>4.2 Events</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.2.1 =
MGCongestion</FONT>=20
  <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Event name: MGCon</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  EventID: mgcon, (0x0001)</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  Description:</FONT> <BR><FONT size=3D2>This event occurs when the MG =
requires=20
  that the MGC start or finish load</FONT> <BR><FONT =
size=3D2>reduction</FONT>=20
  <BR><FONT size=3D2>towards the MG or to adjust the Load Reduction =
Percentage.=20
  The event is</FONT> <BR><FONT size=3D2>ordered by the</FONT> <BR><FONT =

  size=3D2>MGC or provisioned.</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  EventsDescriptor Parameters: None</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  ObservedEventsDescriptor Parameters </FONT><BR><FONT =
size=3D2>&nbsp;</FONT>=20
  <BR><FONT size=3D2>Thanks,</FONT> <BR><FONT size=3D2>Sampath</FONT> =
</P><BR>
  <P><FONT =
size=3D2>_______________________________________________</FONT>=20
  <BR><FONT size=3D2>Megaco mailing list</FONT> <BR><FONT=20
  size=3D2>Megaco@ietf.org</FONT> <BR><FONT size=3D2><A=20
  href=3D"https://www1.ietf.org/mailman/listinfo/megaco"=20
  =
target=3D_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> =

</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0010_01C3E185.F89CEE40--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan 23 07:57:15 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28691
	for <megaco-archive@odin.ietf.org>; Fri, 23 Jan 2004 07:57:15 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak0re-0000oL-9X
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 07:56:46 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NCukHR003113
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 07:56:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak0re-0000o8-2o
	for megaco-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 07:56:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28558
	for <megaco-web-archive@ietf.org>; Fri, 23 Jan 2004 07:56:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak0rc-0003s1-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 07:56:44 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ak0qZ-0003h6-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 07:55:40 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak0pe-0003fj-02
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 07:54:42 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak0n2-0000Ft-Qp; Fri, 23 Jan 2004 07:52:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak0mc-0000Ex-UF
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 07:51:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28388
	for <megaco@ietf.org>; Fri, 23 Jan 2004 07:51:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak0mc-0003c9-00
	for megaco@ietf.org; Fri, 23 Jan 2004 07:51:34 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ak0lg-0003bR-00
	for megaco@ietf.org; Fri, 23 Jan 2004 07:50:37 -0500
Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak0l2-0003ah-00
	for megaco@ietf.org; Fri, 23 Jan 2004 07:49:56 -0500
Received: from UPSTAIRSPC ([10.0.201.16]) by wench.telica.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XM89YDC3; Fri, 23 Jan 2004 07:49:55 -0500
From: "Carl Rutter" <crutter@telica.com>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>,
        "Aleksandr Ryabin" <kengr@motorola.com>, <sampathk@cisco.com>,
        <megaco@ietf.org>
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Fri, 23 Jan 2004 07:50:13 -0500
Message-ID: <GBEBJGNFEADJDNANKJIKGEELCAAA.crutter@telica.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-reply-to: <ABA227A15B80D511BD1A00508BF93A1C0E0753B5@zrtpd0jq.us.nortel.com>
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Kevin,

How would the MGC request a persistent event?
I think this is what we are looking for.
Events that hang around even after the
termination is subtracted back to the NULL context.

Thx,
Carl

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
Kevin Boyle
Sent: Friday, January 23, 2004 3:48 AM
To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?


Provisioned events and persistent events are two different things.
Persistent events (in the world of MG control) implies that MGCs
automatically know about those events and will handle them at any time --
that is, MGs can depend on having those events handled.  Provisioned events
are items that the MG is set up to detect, but that the MG CANNOT depend on
having handled, as the MGC may not even support the package in question.

One other point: MGCs are not required to take any particular action with
regard to a Notify command.  If the Notify comes from a registered MG, then
the MGC ought to reply either affirmatively or with an error.  If the Notify
comes from an unregistered entity, then the MGC reserves the right to send
an error or not respond at all.

The key point is that MGs cannot depend upon any particular MGC behavior
when it comes to provisioned events.

Kevin


  _____

From: Aleksandr Ryabin [mailto:kengr@motorola.com]
Sent: Thursday, January 22, 2004 2:16 PM
To: sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?


Hi Sampath,

a) MGC can ether accept it, i.e. 1), or reject with error 458 (Unexpected
Event/RequestID).
b) Any

Regards,
        Aleks

At 01:48 PM 1/22/2004, Sampath Komanduri wrote:


Aleks and Kevin,
Thanks for responding. I do understand that in the absence of MGC requested
event, if MG has to generate a notification, it would use RequestID 0.
However, I don't see anything with respect to RequestID 0 handling in the
spec. other than the following text in Section 7.2.7:
    "Procedures for sending Notify commands with RequestID equal to 0 are
for futher study."

a) What is the action *required* by the MGC upon recieving a notify with
requestID 0?
    1) Is MGC supposed to do what it would have done if it had explicitly
asked for the eventNotification? In our example, is MGC "required" to take
the *same actions* to reduce congestion on MG (upon receipt of unsolicited
notification) which it would have taken if MGC had "solicited" the
notification? OR
    2) MGC must just respond to the Notification and *not* do anything with
respect to helping MG in reducing the congestion.
    3) MGC can choose to *not* to even respond to the Notify? I hope this is
not the case, since it would result in a DISCONNECTED association.

b) Which events qualify to be notified to MGC with RequestID 0?
    Only events on ROOT? Only event on ROOT and Analog lines? Any events?

It would be good to see some supporting text in the Spec. if the authors
decide to leave the support of persistent events in Megaco.

Thanks,
Sampath





 -----Original Message-----


From: Kevin Boyle [mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> ]


Sent: Thursday, January 22, 2004 10:22 AM


To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org


Subject: RE: [Megaco] Can chp/mgcon event be persistent event?



Provisioning something other than 0 will lead to rejection by the MGC.
Further, provisioning is done at the MG's own risk, as there is no way the
MG can know ahead of time that the MGC supports the package in question.





Basically, the MG can have events provisioned, but all bets are off as to
whether the MGC will accept or reject the event.  My personal feeling is
that MGCs should ask for events they wish to see, and not rely upon any
"event provisioning".





Kevin



  _____

From: Aleksandr Ryabin [mailto:kengr@motorola.com
<mailto:kengr@motorola.com> ]


Sent: Thursday, January 22, 2004 11:19 AM


To: sampathk@cisco.com; megaco@ietf.org


Subject: Re: [Megaco] Can chp/mgcon event be persistent event?



Hi,



Persistent events in MGCP are defined by package specs.


Provisioned events in MEGACO are configured by an MG operator.


As for any descriptor default EventsDescriptor values can be


provisioned on MG to be non-empty.



The only question here which RequestID to use for such pre-provisioned
events?


The common consensus on the list was that 0 is a reasonable default value to



use in such cases, but of course can also be provisioned to something else


by an MG operator.



Regards,


        Aleks



At 03:20 PM 1/21/2004, Sampath Komanduri wrote:



Hi all,


It was my understanding that Megaco doesn't allow any persistent events. If
my understanding is correct... Could someone pls. clarify what the following
paragraph in H.248.10 mean?



ITU-T Rec. H.248.10 (07/2001) 1



4.2 Events


        4.2.1 MGCongestion


                Event name: MGCon


                        EventID: mgcon, (0x0001)


                        Description:


This event occurs when the MG requires that the MGC start or finish load
reduction


towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the


MGC or provisioned.


                        EventsDescriptor Parameters: None


                        ObservedEventsDescriptor Parameters





Thanks,


Sampath


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From exim@www1.ietf.org  Fri Jan 23 07:58:12 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28856
	for <megaco-archive@odin.ietf.org>; Fri, 23 Jan 2004 07:58:12 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak0sZ-0000rA-SU
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 07:57:43 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NCvh4V003286
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 07:57:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak0sZ-0000qv-Ou
	for megaco-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 07:57:43 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28838
	for <megaco-web-archive@ietf.org>; Fri, 23 Jan 2004 07:57:41 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak0sY-00040C-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 07:57:42 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ak0rW-0003rT-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 07:56:42 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak0pz-0003fu-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 07:55:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak0py-0000eR-Ux; Fri, 23 Jan 2004 07:55:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak0pX-0000Uo-BE
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 07:54:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28472
	for <megaco@ietf.org>; Fri, 23 Jan 2004 07:54:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak0pW-0003em-00
	for megaco@ietf.org; Fri, 23 Jan 2004 07:54:34 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ak0ob-0003dv-00
	for megaco@ietf.org; Fri, 23 Jan 2004 07:53:38 -0500
Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak0o5-0003dJ-00
	for megaco@ietf.org; Fri, 23 Jan 2004 07:53:05 -0500
Received: from UPSTAIRSPC ([10.0.201.16]) by wench.telica.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XM89YDCY; Fri, 23 Jan 2004 07:53:02 -0500
From: "Carl Rutter" <crutter@telica.com>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>,
        "Carl Rutter" <crutter@telica.com>,
        "Aleksandr Ryabin" <kengr@motorola.com>, <sampathk@cisco.com>,
        <megaco@ietf.org>
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Fri, 23 Jan 2004 07:53:21 -0500
Message-ID: <GBEBJGNFEADJDNANKJIKKEELCAAA.crutter@telica.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0010_01C3E185.F89CEE40"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-reply-to: <ABA227A15B80D511BD1A00508BF93A1C0E0753B8@zrtpd0jq.us.nortel.com>
Importance: Normal
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01C3E185.F89CEE40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: [Megaco] Can chp/mgcon event be persistent event?Yea,

On a large scale system we may want to apply different events
to many different T1s as they go back to the null context.
You mentioned persistent events from the MGC which
sounds like something we are looking for.

Thx,
Carl
  -----Original Message-----
  From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
  Sent: Friday, January 23, 2004 3:51 AM
  To: Carl Rutter; Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
  Subject: RE: [Megaco] Can chp/mgcon event be persistent event?


  The MGC is capable of sending a wildcarded Modify command requesting the
MG look for events on multiple terminations.  To reduce the message reply
size, the MGC can request a wildcarded response as well.  Is there some
further problem?

  Kevin

  -----Original Message-----
  From: Carl Rutter [mailto:crutter@telica.com]
  Sent: Thursday, January 22, 2004 1:46 PM
  To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Aleksandr Ryabin; sampathk@cisco.com;
megaco@ietf.org
  Subject: RE: [Megaco] Can chp/mgcon event be persistent event?

  I guess my only concern here is the overhead involved in the MGC asking
for events in some cases.
  ie) High-Density Gateway running CAS.
  As densities increase we may want to foster a better MG event provisioning
approach.

  Carl

  -----Original Message-----
  From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
  Sent: Thursday, January 22, 2004 1:22 PM
  To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
  Subject: RE: [Megaco] Can chp/mgcon event be persistent event?



  Provisioning something other than 0 will lead to rejection by the MGC.
  Further, provisioning is done at the MG's own risk, as there is no way the
MG can know ahead of time that the MGC supports the package in question.


  Basically, the MG can have events provisioned, but all bets are off as to
whether the MGC will accept or reject the event.  My personal feeling is
that MGCs should ask for events they wish to see, and not rely upon any
"event provisioning".


  Kevin



    _____

  From: Aleksandr Ryabin [mailto:kengr@motorola.com]
  Sent: Thursday, January 22, 2004 11:19 AM
  To: sampathk@cisco.com; megaco@ietf.org
  Subject: Re: [Megaco] Can chp/mgcon event be persistent event?



  Hi,

  Persistent events in MGCP are defined by package specs.
  Provisioned events in MEGACO are configured by an MG operator.
  As for any descriptor default EventsDescriptor values can be
  provisioned on MG to be non-empty.

  The only question here which RequestID to use for such pre-provisioned
  events?
  The common consensus on the list was that 0 is a reasonable default value
to

  use in such cases, but of course can also be provisioned to something else
  by an MG operator.

  Regards,
          Aleks

  At 03:20 PM 1/21/2004, Sampath Komanduri wrote:



  Hi all,
  It was my understanding that Megaco doesn't allow any persistent events.
If
  my understanding is correct... Could someone pls. clarify what the
following
  paragraph in H.248.10 mean?

  ITU-T Rec. H.248.10 (07/2001) 1

  4.2 Events
          4.2.1 MGCongestion
                  Event name: MGCon
                          EventID: mgcon, (0x0001)
                          Description:
  This event occurs when the MG requires that the MGC start or finish load
  reduction
  towards the MG or to adjust the Load Reduction Percentage. The event is
  ordered by the
  MGC or provisioned.
                          EventsDescriptor Parameters: None
                          ObservedEventsDescriptor Parameters

  Thanks,
  Sampath



  _______________________________________________
  Megaco mailing list
  Megaco@ietf.org
  https://www1.ietf.org/mailman/listinfo/megaco

------=_NextPart_000_0010_01C3E185.F89CEE40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [Megaco] Can chp/mgcon event be persistent =
event?</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D226485012-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Yea,</FONT></SPAN></DIV>
<DIV><SPAN class=3D226485012-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D226485012-23012004><FONT face=3DArial color=3D#0000ff =
size=3D2>On a=20
large scale system we may want to apply different events =
</FONT></SPAN></DIV>
<DIV><SPAN class=3D226485012-23012004><FONT face=3DArial color=3D#0000ff =
size=3D2>to=20
many different T1s as they go back to the null =
context.</FONT></SPAN></DIV>
<DIV><SPAN class=3D226485012-23012004><FONT face=3DArial color=3D#0000ff =
size=3D2>You=20
mentioned persistent events from the MGC which </FONT></SPAN></DIV>
<DIV><SPAN class=3D226485012-23012004><FONT face=3DArial color=3D#0000ff =
size=3D2>sounds=20
like something we are looking for.</FONT></SPAN></DIV>
<DIV><SPAN class=3D226485012-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D226485012-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Thx,</FONT></SPAN></DIV>
<DIV><SPAN class=3D226485012-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Carl</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Kevin Boyle=20
  [mailto:kboyle@nortelnetworks.com]<BR><B>Sent:</B> Friday, January 23, =
2004=20
  3:51 AM<BR><B>To:</B> Carl Rutter; Aleksandr Ryabin; =
sampathk@cisco.com;=20
  megaco@ietf.org<BR><B>Subject:</B> RE: [Megaco] Can chp/mgcon event be =

  persistent event?<BR><BR></FONT></DIV>
  <P><FONT size=3D2>The MGC is capable of sending a wildcarded Modify =
command=20
  requesting the MG look for events on multiple terminations.&nbsp; To =
reduce=20
  the message reply size, the MGC can request a wildcarded response as=20
  well.&nbsp; Is there some further problem?</FONT></P>
  <P><FONT size=3D2>Kevin </FONT></P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: Carl=20
  Rutter [<A =
href=3D"mailto:crutter@telica.com">mailto:crutter@telica.com</A>]=20
  </FONT><BR><FONT size=3D2>Sent: Thursday, January 22, 2004 1:46 =
PM</FONT>=20
  <BR><FONT size=3D2>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Aleksandr =
Ryabin;=20
  sampathk@cisco.com; megaco@ietf.org</FONT> <BR><FONT size=3D2>Subject: =
RE:=20
  [Megaco] Can chp/mgcon event be persistent event?</FONT> </P>
  <P><FONT size=3D2>I guess my only concern here is the overhead =
involved in the=20
  MGC asking for events in some cases.</FONT> <BR><FONT size=3D2>ie) =
High-Density=20
  Gateway running CAS.</FONT> <BR><FONT size=3D2>As densities increase =
we may want=20
  to foster a better MG event provisioning approach.</FONT> </P>
  <P><FONT size=3D2>Carl</FONT> </P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: Kevin=20
  Boyle [<A=20
  =
href=3D"mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.co=
m</A>]</FONT>=20
  <BR><FONT size=3D2>Sent: Thursday, January 22, 2004 1:22 PM</FONT> =
<BR><FONT=20
  size=3D2>To: Aleksandr Ryabin; sampathk@cisco.com; =
megaco@ietf.org</FONT>=20
  <BR><FONT size=3D2>Subject: RE: [Megaco] Can chp/mgcon event be =
persistent=20
  event?</FONT> </P><BR>
  <P><FONT size=3D2>Provisioning something other than 0 will lead to =
rejection by=20
  the MGC.</FONT> <BR><FONT size=3D2>Further, provisioning is done at =
the MG's own=20
  risk, as there is no way the MG can know ahead of time that the MGC =
supports=20
  the package in question.</FONT></P>
  <P><FONT size=3D2></FONT> <BR><FONT size=3D2>Basically, the MG can =
have events=20
  provisioned, but all bets are off as to whether the MGC will accept or =
reject=20
  the event.&nbsp; My personal feeling is that MGCs should ask for =
events they=20
  wish to see, and not rely upon any "event provisioning".</FONT></P>
  <P><FONT size=3D2></FONT> <BR><FONT size=3D2>Kevin</FONT> </P><BR>
  <P><FONT size=3D2>&nbsp; _____&nbsp; </FONT></P>
  <P><FONT size=3D2>From: Aleksandr Ryabin [<A=20
  =
href=3D"mailto:kengr@motorola.com">mailto:kengr@motorola.com</A>]</FONT> =

  <BR><FONT size=3D2>Sent: Thursday, January 22, 2004 11:19 AM</FONT> =
<BR><FONT=20
  size=3D2>To: sampathk@cisco.com; megaco@ietf.org</FONT> <BR><FONT=20
  size=3D2>Subject: Re: [Megaco] Can chp/mgcon event be persistent =
event?</FONT>=20
  </P><BR>
  <P><FONT size=3D2>Hi,</FONT> </P>
  <P><FONT size=3D2>Persistent events in MGCP are defined by package =
specs.</FONT>=20
  <BR><FONT size=3D2>Provisioned events in MEGACO are configured by an =
MG=20
  operator.</FONT> <BR><FONT size=3D2>As for any descriptor default=20
  EventsDescriptor values can be</FONT> <BR><FONT size=3D2>provisioned =
on MG to be=20
  non-empty.</FONT> </P>
  <P><FONT size=3D2>The only question here which RequestID to use for =
such=20
  pre-provisioned</FONT> <BR><FONT size=3D2>events?</FONT> <BR><FONT =
size=3D2>The=20
  common consensus on the list was that 0 is a reasonable default value=20
  to</FONT> </P>
  <P><FONT size=3D2>use in such cases, but of course can also be =
provisioned to=20
  something else</FONT> <BR><FONT size=3D2>by an MG operator.</FONT> =
</P>
  <P><FONT size=3D2>Regards,</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Aleks</FONT> </P>
  <P><FONT size=3D2>At 03:20 PM 1/21/2004, Sampath Komanduri =
wrote:</FONT>=20
</P><BR>
  <P><FONT size=3D2>Hi all,</FONT> <BR><FONT size=3D2>It was my =
understanding that=20
  Megaco doesn't allow any persistent events. If</FONT> <BR><FONT =
size=3D2>my=20
  understanding is correct... Could someone pls. clarify what the=20
  following</FONT> <BR><FONT size=3D2>paragraph in H.248.10 mean?</FONT> =
</P>
  <P><FONT size=3D2>ITU-T Rec. H.248.10 (07/2001) 1</FONT> </P>
  <P><FONT size=3D2>4.2 Events</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.2.1 =
MGCongestion</FONT>=20
  <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Event name: MGCon</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  EventID: mgcon, (0x0001)</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  Description:</FONT> <BR><FONT size=3D2>This event occurs when the MG =
requires=20
  that the MGC start or finish load</FONT> <BR><FONT =
size=3D2>reduction</FONT>=20
  <BR><FONT size=3D2>towards the MG or to adjust the Load Reduction =
Percentage.=20
  The event is</FONT> <BR><FONT size=3D2>ordered by the</FONT> <BR><FONT =

  size=3D2>MGC or provisioned.</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  EventsDescriptor Parameters: None</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  ObservedEventsDescriptor Parameters </FONT><BR><FONT =
size=3D2>&nbsp;</FONT>=20
  <BR><FONT size=3D2>Thanks,</FONT> <BR><FONT size=3D2>Sampath</FONT> =
</P><BR>
  <P><FONT =
size=3D2>_______________________________________________</FONT>=20
  <BR><FONT size=3D2>Megaco mailing list</FONT> <BR><FONT=20
  size=3D2>Megaco@ietf.org</FONT> <BR><FONT size=3D2><A=20
  href=3D"https://www1.ietf.org/mailman/listinfo/megaco"=20
  =
target=3D_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> =

</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0010_01C3E185.F89CEE40--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan 23 08:51:31 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00415
	for <megaco-archive@lists.ietf.org>; Fri, 23 Jan 2004 08:51:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak1iA-0005UI-R1; Fri, 23 Jan 2004 08:51:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak1ht-0005Tf-2Q
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 08:50:45 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00403
	for <megaco@ietf.org>; Fri, 23 Jan 2004 08:50:42 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak1hr-00068k-00
	for megaco@ietf.org; Fri, 23 Jan 2004 08:50:43 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ak1gt-00066s-00
	for megaco@ietf.org; Fri, 23 Jan 2004 08:49:44 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak1ga-00065B-00
	for megaco@ietf.org; Fri, 23 Jan 2004 08:49:24 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0NDmq504548
	for <megaco@ietf.org>; Fri, 23 Jan 2004 08:48:52 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DNYBYSJS>; Fri, 23 Jan 2004 08:48:53 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E0E97F4@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Carl Rutter <crutter@telica.com>, Aleksandr Ryabin
	 <kengr@motorola.com>,
        sampathk@cisco.com, megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Fri, 23 Jan 2004 08:48:51 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

There is no concept of a persistent event in H.248.  The way to do this
would be to modify the termination with a new Events descriptor upon its
subtraction.  One possibility would be:

!/1 [12.34.56.78]:2944 T=123{C=12{S=term{}},C=-{MF=term{E=123{pkg/event}}}}

Kevin

-----Original Message-----
From: Carl Rutter [mailto:crutter@telica.com] 
Sent: Friday, January 23, 2004 7:50 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Aleksandr Ryabin; sampathk@cisco.com;
megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?

Kevin,

How would the MGC request a persistent event?
I think this is what we are looking for.
Events that hang around even after the
termination is subtracted back to the NULL context.

Thx,
Carl

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Kevin
Boyle
Sent: Friday, January 23, 2004 3:48 AM
To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?


Provisioned events and persistent events are two different things.
Persistent events (in the world of MG control) implies that MGCs
automatically know about those events and will handle them at any time --
that is, MGs can depend on having those events handled.  Provisioned events
are items that the MG is set up to detect, but that the MG CANNOT depend on
having handled, as the MGC may not even support the package in question.

One other point: MGCs are not required to take any particular action with
regard to a Notify command.  If the Notify comes from a registered MG, then
the MGC ought to reply either affirmatively or with an error.  If the Notify
comes from an unregistered entity, then the MGC reserves the right to send
an error or not respond at all.

The key point is that MGs cannot depend upon any particular MGC behavior
when it comes to provisioned events.

Kevin


  _____

From: Aleksandr Ryabin [mailto:kengr@motorola.com]
Sent: Thursday, January 22, 2004 2:16 PM
To: sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?


Hi Sampath,

a) MGC can ether accept it, i.e. 1), or reject with error 458 (Unexpected
Event/RequestID).
b) Any

Regards,
        Aleks

At 01:48 PM 1/22/2004, Sampath Komanduri wrote:


Aleks and Kevin,
Thanks for responding. I do understand that in the absence of MGC requested
event, if MG has to generate a notification, it would use RequestID 0.
However, I don't see anything with respect to RequestID 0 handling in the
spec. other than the following text in Section 7.2.7:
    "Procedures for sending Notify commands with RequestID equal to 0 are
for futher study."

a) What is the action *required* by the MGC upon recieving a notify with
requestID 0?
    1) Is MGC supposed to do what it would have done if it had explicitly
asked for the eventNotification? In our example, is MGC "required" to take
the *same actions* to reduce congestion on MG (upon receipt of unsolicited
notification) which it would have taken if MGC had "solicited" the
notification? OR
    2) MGC must just respond to the Notification and *not* do anything with
respect to helping MG in reducing the congestion.
    3) MGC can choose to *not* to even respond to the Notify? I hope this is
not the case, since it would result in a DISCONNECTED association.

b) Which events qualify to be notified to MGC with RequestID 0?
    Only events on ROOT? Only event on ROOT and Analog lines? Any events?

It would be good to see some supporting text in the Spec. if the authors
decide to leave the support of persistent events in Megaco.

Thanks,
Sampath





 -----Original Message-----


From: Kevin Boyle [mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> ]


Sent: Thursday, January 22, 2004 10:22 AM


To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org


Subject: RE: [Megaco] Can chp/mgcon event be persistent event?



Provisioning something other than 0 will lead to rejection by the MGC.
Further, provisioning is done at the MG's own risk, as there is no way the
MG can know ahead of time that the MGC supports the package in question.





Basically, the MG can have events provisioned, but all bets are off as to
whether the MGC will accept or reject the event.  My personal feeling is
that MGCs should ask for events they wish to see, and not rely upon any
"event provisioning".





Kevin



  _____

From: Aleksandr Ryabin [mailto:kengr@motorola.com
<mailto:kengr@motorola.com> ]


Sent: Thursday, January 22, 2004 11:19 AM


To: sampathk@cisco.com; megaco@ietf.org


Subject: Re: [Megaco] Can chp/mgcon event be persistent event?



Hi,



Persistent events in MGCP are defined by package specs.


Provisioned events in MEGACO are configured by an MG operator.


As for any descriptor default EventsDescriptor values can be


provisioned on MG to be non-empty.



The only question here which RequestID to use for such pre-provisioned
events?


The common consensus on the list was that 0 is a reasonable default value to



use in such cases, but of course can also be provisioned to something else


by an MG operator.



Regards,


        Aleks



At 03:20 PM 1/21/2004, Sampath Komanduri wrote:



Hi all,


It was my understanding that Megaco doesn't allow any persistent events. If
my understanding is correct... Could someone pls. clarify what the following
paragraph in H.248.10 mean?



ITU-T Rec. H.248.10 (07/2001) 1



4.2 Events


        4.2.1 MGCongestion


                Event name: MGCon


                        EventID: mgcon, (0x0001)


                        Description:


This event occurs when the MG requires that the MGC start or finish load
reduction


towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the


MGC or provisioned.


                        EventsDescriptor Parameters: None


                        ObservedEventsDescriptor Parameters





Thanks,


Sampath


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan 23 08:53:13 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00491
	for <megaco-archive@odin.ietf.org>; Fri, 23 Jan 2004 08:53:13 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak1jp-0005cw-Sv
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 08:52:45 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NDqjj7021630
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 08:52:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak1jp-0005cn-Nh
	for megaco-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 08:52:45 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00478
	for <megaco-web-archive@ietf.org>; Fri, 23 Jan 2004 08:52:42 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak1jo-0006El-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 08:52:44 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ak1is-0006CG-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 08:51:47 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak1iA-00069q-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 08:51:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak1iA-0005UI-R1; Fri, 23 Jan 2004 08:51:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak1ht-0005Tf-2Q
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 08:50:45 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00403
	for <megaco@ietf.org>; Fri, 23 Jan 2004 08:50:42 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak1hr-00068k-00
	for megaco@ietf.org; Fri, 23 Jan 2004 08:50:43 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ak1gt-00066s-00
	for megaco@ietf.org; Fri, 23 Jan 2004 08:49:44 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak1ga-00065B-00
	for megaco@ietf.org; Fri, 23 Jan 2004 08:49:24 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0NDmq504548
	for <megaco@ietf.org>; Fri, 23 Jan 2004 08:48:52 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DNYBYSJS>; Fri, 23 Jan 2004 08:48:53 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E0E97F4@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Carl Rutter <crutter@telica.com>, Aleksandr Ryabin
	 <kengr@motorola.com>,
        sampathk@cisco.com, megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Fri, 23 Jan 2004 08:48:51 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60

There is no concept of a persistent event in H.248.  The way to do this
would be to modify the termination with a new Events descriptor upon its
subtraction.  One possibility would be:

!/1 [12.34.56.78]:2944 T=123{C=12{S=term{}},C=-{MF=term{E=123{pkg/event}}}}

Kevin

-----Original Message-----
From: Carl Rutter [mailto:crutter@telica.com] 
Sent: Friday, January 23, 2004 7:50 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Aleksandr Ryabin; sampathk@cisco.com;
megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?

Kevin,

How would the MGC request a persistent event?
I think this is what we are looking for.
Events that hang around even after the
termination is subtracted back to the NULL context.

Thx,
Carl

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Kevin
Boyle
Sent: Friday, January 23, 2004 3:48 AM
To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?


Provisioned events and persistent events are two different things.
Persistent events (in the world of MG control) implies that MGCs
automatically know about those events and will handle them at any time --
that is, MGs can depend on having those events handled.  Provisioned events
are items that the MG is set up to detect, but that the MG CANNOT depend on
having handled, as the MGC may not even support the package in question.

One other point: MGCs are not required to take any particular action with
regard to a Notify command.  If the Notify comes from a registered MG, then
the MGC ought to reply either affirmatively or with an error.  If the Notify
comes from an unregistered entity, then the MGC reserves the right to send
an error or not respond at all.

The key point is that MGs cannot depend upon any particular MGC behavior
when it comes to provisioned events.

Kevin


  _____

From: Aleksandr Ryabin [mailto:kengr@motorola.com]
Sent: Thursday, January 22, 2004 2:16 PM
To: sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?


Hi Sampath,

a) MGC can ether accept it, i.e. 1), or reject with error 458 (Unexpected
Event/RequestID).
b) Any

Regards,
        Aleks

At 01:48 PM 1/22/2004, Sampath Komanduri wrote:


Aleks and Kevin,
Thanks for responding. I do understand that in the absence of MGC requested
event, if MG has to generate a notification, it would use RequestID 0.
However, I don't see anything with respect to RequestID 0 handling in the
spec. other than the following text in Section 7.2.7:
    "Procedures for sending Notify commands with RequestID equal to 0 are
for futher study."

a) What is the action *required* by the MGC upon recieving a notify with
requestID 0?
    1) Is MGC supposed to do what it would have done if it had explicitly
asked for the eventNotification? In our example, is MGC "required" to take
the *same actions* to reduce congestion on MG (upon receipt of unsolicited
notification) which it would have taken if MGC had "solicited" the
notification? OR
    2) MGC must just respond to the Notification and *not* do anything with
respect to helping MG in reducing the congestion.
    3) MGC can choose to *not* to even respond to the Notify? I hope this is
not the case, since it would result in a DISCONNECTED association.

b) Which events qualify to be notified to MGC with RequestID 0?
    Only events on ROOT? Only event on ROOT and Analog lines? Any events?

It would be good to see some supporting text in the Spec. if the authors
decide to leave the support of persistent events in Megaco.

Thanks,
Sampath





 -----Original Message-----


From: Kevin Boyle [mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> ]


Sent: Thursday, January 22, 2004 10:22 AM


To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org


Subject: RE: [Megaco] Can chp/mgcon event be persistent event?



Provisioning something other than 0 will lead to rejection by the MGC.
Further, provisioning is done at the MG's own risk, as there is no way the
MG can know ahead of time that the MGC supports the package in question.





Basically, the MG can have events provisioned, but all bets are off as to
whether the MGC will accept or reject the event.  My personal feeling is
that MGCs should ask for events they wish to see, and not rely upon any
"event provisioning".





Kevin



  _____

From: Aleksandr Ryabin [mailto:kengr@motorola.com
<mailto:kengr@motorola.com> ]


Sent: Thursday, January 22, 2004 11:19 AM


To: sampathk@cisco.com; megaco@ietf.org


Subject: Re: [Megaco] Can chp/mgcon event be persistent event?



Hi,



Persistent events in MGCP are defined by package specs.


Provisioned events in MEGACO are configured by an MG operator.


As for any descriptor default EventsDescriptor values can be


provisioned on MG to be non-empty.



The only question here which RequestID to use for such pre-provisioned
events?


The common consensus on the list was that 0 is a reasonable default value to



use in such cases, but of course can also be provisioned to something else


by an MG operator.



Regards,


        Aleks



At 03:20 PM 1/21/2004, Sampath Komanduri wrote:



Hi all,


It was my understanding that Megaco doesn't allow any persistent events. If
my understanding is correct... Could someone pls. clarify what the following
paragraph in H.248.10 mean?



ITU-T Rec. H.248.10 (07/2001) 1



4.2 Events


        4.2.1 MGCongestion


                Event name: MGCon


                        EventID: mgcon, (0x0001)


                        Description:


This event occurs when the MG requires that the MGC start or finish load
reduction


towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the


MGC or provisioned.


                        EventsDescriptor Parameters: None


                        ObservedEventsDescriptor Parameters





Thanks,


Sampath


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan 23 09:01:32 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01304
	for <megaco-archive@lists.ietf.org>; Fri, 23 Jan 2004 09:01:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak1rr-0006EW-0j; Fri, 23 Jan 2004 09:01:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak1rS-00068I-A1
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 09:00:38 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01207
	for <megaco@ietf.org>; Fri, 23 Jan 2004 09:00:35 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak1rQ-00073U-00
	for megaco@ietf.org; Fri, 23 Jan 2004 09:00:36 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ak1qX-0006xR-00
	for megaco@ietf.org; Fri, 23 Jan 2004 08:59:44 -0500
Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak1ph-0006qj-00
	for megaco@ietf.org; Fri, 23 Jan 2004 08:58:49 -0500
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <XM89YDSF>; Fri, 23 Jan 2004 08:58:47 -0500
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA0350634F@wench.telica.com>
From: Carl Rutter <crutter@telica.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        Carl Rutter
	 <crutter@telica.com>,
        Aleksandr Ryabin <kengr@motorola.com>, sampathk@cisco.com,
        megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Fri, 23 Jan 2004 08:58:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3E1B8.FF856E34"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3E1B8.FF856E34
Content-Type: text/plain;
	charset="iso-8859-1"

OK,
 
Provisioned events have not been well defined per the RFC and
only rscID 0 can be used.  To your point
these should be avoided since the MGC may not know about them.
So maybe in the future we could have a mechanism so that the
MGC could specify pesistent events to the MG.  There could be
different flavors, one being reappy event when transistioning to the 
NULL context etc. Provisioned events would not be allowed. 
Comments?
 
Carl
 
 
-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Friday, January 23, 2004 8:49 AM
To: Carl Rutter; Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?



There is no concept of a persistent event in H.248.  The way to do this
would be to modify the termination with a new Events descriptor upon its
subtraction.  One possibility would be:

!/1 [12.34.56.78]:2944 T=123{C=12{S=term{}},C=-{MF=term{E=123{pkg/event}}}} 

Kevin 

-----Original Message----- 
From: Carl Rutter [ mailto:crutter@telica.com <mailto:crutter@telica.com> ] 
Sent: Friday, January 23, 2004 7:50 AM 
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Aleksandr Ryabin; sampathk@cisco.com;
megaco@ietf.org 
Subject: RE: [Megaco] Can chp/mgcon event be persistent event? 

Kevin, 

How would the MGC request a persistent event? 
I think this is what we are looking for. 
Events that hang around even after the 
termination is subtracted back to the NULL context. 

Thx, 
Carl 

-----Original Message----- 
From: megaco-admin@ietf.org [ mailto:megaco-admin@ietf.org
<mailto:megaco-admin@ietf.org> ]On Behalf Of Kevin Boyle 
Sent: Friday, January 23, 2004 3:48 AM 
To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org 
Subject: RE: [Megaco] Can chp/mgcon event be persistent event? 


Provisioned events and persistent events are two different things. 
Persistent events (in the world of MG control) implies that MGCs
automatically know about those events and will handle them at any time --
that is, MGs can depend on having those events handled.  Provisioned events
are items that the MG is set up to detect, but that the MG CANNOT depend on
having handled, as the MGC may not even support the package in question.

One other point: MGCs are not required to take any particular action with
regard to a Notify command.  If the Notify comes from a registered MG, then
the MGC ought to reply either affirmatively or with an error.  If the Notify
comes from an unregistered entity, then the MGC reserves the right to send
an error or not respond at all.

The key point is that MGs cannot depend upon any particular MGC behavior
when it comes to provisioned events. 

Kevin 


  _____ 

From: Aleksandr Ryabin [ mailto:kengr@motorola.com
<mailto:kengr@motorola.com> ] 
Sent: Thursday, January 22, 2004 2:16 PM 
To: sampathk@cisco.com; megaco@ietf.org 
Subject: RE: [Megaco] Can chp/mgcon event be persistent event? 


Hi Sampath, 

a) MGC can ether accept it, i.e. 1), or reject with error 458 (Unexpected
Event/RequestID). 
b) Any 

Regards, 
        Aleks 

At 01:48 PM 1/22/2004, Sampath Komanduri wrote: 


Aleks and Kevin, 
Thanks for responding. I do understand that in the absence of MGC requested
event, if MG has to generate a notification, it would use RequestID 0.

However, I don't see anything with respect to RequestID 0 handling in the
spec. other than the following text in Section 7.2.7:

    "Procedures for sending Notify commands with RequestID equal to 0 are
for futher study." 

a) What is the action *required* by the MGC upon recieving a notify with
requestID 0? 
    1) Is MGC supposed to do what it would have done if it had explicitly
asked for the eventNotification? In our example, is MGC "required" to take
the *same actions* to reduce congestion on MG (upon receipt of unsolicited

notification) which it would have taken if MGC had "solicited" the
notification? OR 
    2) MGC must just respond to the Notification and *not* do anything with
respect to helping MG in reducing the congestion.

    3) MGC can choose to *not* to even respond to the Notify? I hope this is
not the case, since it would result in a DISCONNECTED association.

b) Which events qualify to be notified to MGC with RequestID 0? 
    Only events on ROOT? Only event on ROOT and Analog lines? Any events? 

It would be good to see some supporting text in the Spec. if the authors
decide to leave the support of persistent events in Megaco.

Thanks, 
Sampath 





 -----Original Message----- 


From: Kevin Boyle [ mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com>  < mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> > ] 


Sent: Thursday, January 22, 2004 10:22 AM 


To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org 


Subject: RE: [Megaco] Can chp/mgcon event be persistent event? 



Provisioning something other than 0 will lead to rejection by the MGC. 
Further, provisioning is done at the MG's own risk, as there is no way the
MG can know ahead of time that the MGC supports the package in question.





Basically, the MG can have events provisioned, but all bets are off as to
whether the MGC will accept or reject the event.  My personal feeling is
that MGCs should ask for events they wish to see, and not rely upon any
"event provisioning".





Kevin 



  _____ 

From: Aleksandr Ryabin [ mailto:kengr@motorola.com
<mailto:kengr@motorola.com>  < mailto:kengr@motorola.com
<mailto:kengr@motorola.com> > ] 


Sent: Thursday, January 22, 2004 11:19 AM 


To: sampathk@cisco.com; megaco@ietf.org 


Subject: Re: [Megaco] Can chp/mgcon event be persistent event? 



Hi, 



Persistent events in MGCP are defined by package specs. 


Provisioned events in MEGACO are configured by an MG operator. 


As for any descriptor default EventsDescriptor values can be 


provisioned on MG to be non-empty. 



The only question here which RequestID to use for such pre-provisioned
events? 


The common consensus on the list was that 0 is a reasonable default value to




use in such cases, but of course can also be provisioned to something else 


by an MG operator. 



Regards, 


        Aleks 



At 03:20 PM 1/21/2004, Sampath Komanduri wrote: 



Hi all, 


It was my understanding that Megaco doesn't allow any persistent events. If
my understanding is correct... Could someone pls. clarify what the following
paragraph in H.248.10 mean?



ITU-T Rec. H.248.10 (07/2001) 1 



4.2 Events 


        4.2.1 MGCongestion 


                Event name: MGCon 


                        EventID: mgcon, (0x0001) 


                        Description: 


This event occurs when the MG requires that the MGC start or finish load
reduction 


towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the 


MGC or provisioned. 


                        EventsDescriptor Parameters: None 


                        ObservedEventsDescriptor Parameters 





Thanks, 


Sampath 


_______________________________________________ 
Megaco mailing list 
Megaco@ietf.org 
https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  


------_=_NextPart_001_01C3E1B8.FF856E34
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [Megaco] Can chp/mgcon event be persistent event?</TITLE>

<META content="MSHTML 6.00.2800.1106" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff 
size=2>OK,</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff 
size=2>Provisioned events have not been well defined per the RFC 
and</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff size=2>only 
rscID 0 can be used.&nbsp; To your point</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff size=2>these 
should be avoided since the MGC may not know about them.</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff size=2>So 
maybe in the future we could have a mechanism so that the</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff size=2>MGC 
could specify pesistent events to the MG.&nbsp; There could 
be</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff 
size=2>different flavors, one being reappy event when transistioning to the 
</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff size=2>NULL 
context etc.&nbsp;Provisioned events would not be 
allowed.&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff 
size=2>Comments?</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff 
size=2>Carl</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Kevin Boyle 
[mailto:kboyle@nortelnetworks.com]<BR><B>Sent:</B> Friday, January 23, 2004 8:49 
AM<BR><B>To:</B> Carl Rutter; Aleksandr Ryabin; sampathk@cisco.com; 
megaco@ietf.org<BR><B>Subject:</B> RE: [Megaco] Can chp/mgcon event be 
persistent event?<BR><BR></FONT></DIV>
<P><FONT size=2>There is no concept of a persistent event in H.248.&nbsp; The 
way to do this would be to modify the termination with a new Events descriptor 
upon its subtraction.&nbsp; One possibility would be:</FONT></P>
<P><FONT size=2>!/1 [12.34.56.78]:2944 
T=123{C=12{S=term{}},C=-{MF=term{E=123{pkg/event}}}}</FONT> </P>
<P><FONT size=2>Kevin</FONT> </P>
<P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Carl 
Rutter [<A href="mailto:crutter@telica.com">mailto:crutter@telica.com</A>] 
</FONT><BR><FONT size=2>Sent: Friday, January 23, 2004 7:50 AM</FONT> <BR><FONT 
size=2>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Aleksandr Ryabin; sampathk@cisco.com; 
megaco@ietf.org</FONT> <BR><FONT size=2>Subject: RE: [Megaco] Can chp/mgcon 
event be persistent event?</FONT> </P>
<P><FONT size=2>Kevin,</FONT> </P>
<P><FONT size=2>How would the MGC request a persistent event?</FONT> <BR><FONT 
size=2>I think this is what we are looking for.</FONT> <BR><FONT size=2>Events 
that hang around even after the</FONT> <BR><FONT size=2>termination is 
subtracted back to the NULL context.</FONT> </P>
<P><FONT size=2>Thx,</FONT> <BR><FONT size=2>Carl</FONT> </P>
<P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
megaco-admin@ietf.org [<A 
href="mailto:megaco-admin@ietf.org">mailto:megaco-admin@ietf.org</A>]On Behalf 
Of Kevin Boyle</FONT> <BR><FONT size=2>Sent: Friday, January 23, 2004 3:48 
AM</FONT> <BR><FONT size=2>To: Aleksandr Ryabin; sampathk@cisco.com; 
megaco@ietf.org</FONT> <BR><FONT size=2>Subject: RE: [Megaco] Can chp/mgcon 
event be persistent event?</FONT> </P><BR>
<P><FONT size=2>Provisioned events and persistent events are two different 
things.</FONT> <BR><FONT size=2>Persistent events (in the world of MG control) 
implies that MGCs automatically know about those events and will handle them at 
any time -- that is, MGs can depend on having those events handled.&nbsp; 
Provisioned events are items that the MG is set up to detect, but that the MG 
CANNOT depend on having handled, as the MGC may not even support the package in 
question.</FONT></P>
<P><FONT size=2>One other point: MGCs are not required to take any particular 
action with regard to a Notify command.&nbsp; If the Notify comes from a 
registered MG, then the MGC ought to reply either affirmatively or with an 
error.&nbsp; If the Notify comes from an unregistered entity, then the MGC 
reserves the right to send an error or not respond at all.</FONT></P>
<P><FONT size=2>The key point is that MGs cannot depend upon any particular MGC 
behavior when it comes to provisioned events.</FONT> </P>
<P><FONT size=2>Kevin</FONT> </P><BR>
<P><FONT size=2>&nbsp; _____</FONT> </P>
<P><FONT size=2>From: Aleksandr Ryabin [<A 
href="mailto:kengr@motorola.com">mailto:kengr@motorola.com</A>]</FONT> <BR><FONT 
size=2>Sent: Thursday, January 22, 2004 2:16 PM</FONT> <BR><FONT size=2>To: 
sampathk@cisco.com; megaco@ietf.org</FONT> <BR><FONT size=2>Subject: RE: 
[Megaco] Can chp/mgcon event be persistent event?</FONT> </P><BR>
<P><FONT size=2>Hi Sampath,</FONT> </P>
<P><FONT size=2>a) MGC can ether accept it, i.e. 1), or reject with error 458 
(Unexpected Event/RequestID).</FONT> <BR><FONT size=2>b) Any</FONT> </P>
<P><FONT size=2>Regards,</FONT> <BR><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Aleks</FONT> </P>
<P><FONT size=2>At 01:48 PM 1/22/2004, Sampath Komanduri wrote:</FONT> </P><BR>
<P><FONT size=2>Aleks and Kevin,</FONT> <BR><FONT size=2>Thanks for responding. 
I do understand that in the absence of MGC requested event, if MG has to 
generate a notification, it would use RequestID 0.</FONT></P>
<P><FONT size=2>However, I don't see anything with respect to RequestID 0 
handling in the spec. other than the following text in Section 7.2.7:</FONT></P>
<P><FONT size=2>&nbsp;&nbsp;&nbsp; "Procedures for sending Notify commands with 
RequestID equal to 0 are for futher study."</FONT> </P>
<P><FONT size=2>a) What is the action *required* by the MGC upon recieving a 
notify with requestID 0?</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; 1) Is MGC 
supposed to do what it would have done if it had explicitly asked for the 
eventNotification? In our example, is MGC "required" to take the *same actions* 
to reduce congestion on MG (upon receipt of unsolicited</FONT></P>
<P><FONT size=2>notification) which it would have taken if MGC had "solicited" 
the notification? OR</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; 2) MGC must just 
respond to the Notification and *not* do anything with respect to helping MG in 
reducing the congestion.</FONT></P>
<P><FONT size=2>&nbsp;&nbsp;&nbsp; 3) MGC can choose to *not* to even respond to 
the Notify? I hope this is not the case, since it would result in a DISCONNECTED 
association.</FONT></P>
<P><FONT size=2>b) Which events qualify to be notified to MGC with RequestID 
0?</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; Only events on ROOT? Only event on 
ROOT and Analog lines? Any events?</FONT> </P>
<P><FONT size=2>It would be good to see some supporting text in the Spec. if the 
authors decide to leave the support of persistent events in Megaco.</FONT></P>
<P><FONT size=2>Thanks,</FONT> <BR><FONT size=2>Sampath</FONT> 
</P><BR><BR><BR><BR>
<P><FONT size=2>&nbsp;-----Original Message-----</FONT> </P><BR>
<P><FONT size=2>From: Kevin Boyle [<A 
href="mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.com</A> 
&lt;<A 
href="mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.com</A>&gt; 
]</FONT> </P><BR>
<P><FONT size=2>Sent: Thursday, January 22, 2004 10:22 AM</FONT> </P><BR>
<P><FONT size=2>To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org</FONT> 
</P><BR>
<P><FONT size=2>Subject: RE: [Megaco] Can chp/mgcon event be persistent 
event?</FONT> </P><BR><BR>
<P><FONT size=2>Provisioning something other than 0 will lead to rejection by 
the MGC.</FONT> <BR><FONT size=2>Further, provisioning is done at the MG's own 
risk, as there is no way the MG can know ahead of time that the MGC supports the 
package in question.</FONT></P><BR><BR><BR><BR>
<P><FONT size=2>Basically, the MG can have events provisioned, but all bets are 
off as to whether the MGC will accept or reject the event.&nbsp; My personal 
feeling is that MGCs should ask for events they wish to see, and not rely upon 
any "event provisioning".</FONT></P><BR><BR><BR><BR>
<P><FONT size=2>Kevin</FONT> </P><BR><BR>
<P><FONT size=2>&nbsp; _____</FONT> </P>
<P><FONT size=2>From: Aleksandr Ryabin [<A 
href="mailto:kengr@motorola.com">mailto:kengr@motorola.com</A> &lt;<A 
href="mailto:kengr@motorola.com">mailto:kengr@motorola.com</A>&gt; ]</FONT> 
</P><BR>
<P><FONT size=2>Sent: Thursday, January 22, 2004 11:19 AM</FONT> </P><BR>
<P><FONT size=2>To: sampathk@cisco.com; megaco@ietf.org</FONT> </P><BR>
<P><FONT size=2>Subject: Re: [Megaco] Can chp/mgcon event be persistent 
event?</FONT> </P><BR><BR>
<P><FONT size=2>Hi,</FONT> </P><BR><BR>
<P><FONT size=2>Persistent events in MGCP are defined by package specs.</FONT> 
</P><BR>
<P><FONT size=2>Provisioned events in MEGACO are configured by an MG 
operator.</FONT> </P><BR>
<P><FONT size=2>As for any descriptor default EventsDescriptor values can 
be</FONT> </P><BR>
<P><FONT size=2>provisioned on MG to be non-empty.</FONT> </P><BR><BR>
<P><FONT size=2>The only question here which RequestID to use for such 
pre-provisioned events?</FONT> </P><BR>
<P><FONT size=2>The common consensus on the list was that 0 is a reasonable 
default value to</FONT> </P><BR><BR>
<P><FONT size=2>use in such cases, but of course can also be provisioned to 
something else</FONT> </P><BR>
<P><FONT size=2>by an MG operator.</FONT> </P><BR><BR>
<P><FONT size=2>Regards,</FONT> </P><BR>
<P><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Aleks</FONT> 
</P><BR><BR>
<P><FONT size=2>At 03:20 PM 1/21/2004, Sampath Komanduri wrote:</FONT> 
</P><BR><BR>
<P><FONT size=2>Hi all,</FONT> </P><BR>
<P><FONT size=2>It was my understanding that Megaco doesn't allow any persistent 
events. If my understanding is correct... Could someone pls. clarify what the 
following paragraph in H.248.10 mean?</FONT></P><BR><BR>
<P><FONT size=2>ITU-T Rec. H.248.10 (07/2001) 1</FONT> </P><BR><BR>
<P><FONT size=2>4.2 Events</FONT> </P><BR>
<P><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.2.1 
MGCongestion</FONT> </P><BR>
<P><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Event name: MGCon</FONT> </P><BR>
<P><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
EventID: mgcon, (0x0001)</FONT> </P><BR>
<P><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Description:</FONT> </P><BR>
<P><FONT size=2>This event occurs when the MG requires that the MGC start or 
finish load reduction</FONT> </P><BR>
<P><FONT size=2>towards the MG or to adjust the Load Reduction Percentage. The 
event is ordered by the</FONT> </P><BR>
<P><FONT size=2>MGC or provisioned.</FONT> </P><BR>
<P><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
EventsDescriptor Parameters: None</FONT> </P><BR>
<P><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
ObservedEventsDescriptor Parameters</FONT> </P><BR><BR><BR><BR>
<P><FONT size=2>Thanks,</FONT> </P><BR>
<P><FONT size=2>Sampath</FONT> </P><BR>
<P><FONT size=2>_______________________________________________</FONT> <BR><FONT 
size=2>Megaco mailing list</FONT> <BR><FONT size=2>Megaco@ietf.org</FONT> 
<BR><FONT size=2><A href="https://www1.ietf.org/mailman/listinfo/megaco" 
target=_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> 
</P></BODY></HTML>

------_=_NextPart_001_01C3E1B8.FF856E34--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan 23 09:24:43 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01935
	for <megaco-archive@odin.ietf.org>; Fri, 23 Jan 2004 09:24:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak2EJ-0007iO-5l
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 09:24:15 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NEOF2W029650
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 09:24:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak2EJ-0007i9-1s
	for megaco-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 09:24:15 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01760
	for <megaco-web-archive@ietf.org>; Fri, 23 Jan 2004 09:24:10 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak2EF-00008n-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 09:24:11 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ak2Ca-0007dp-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 09:22:30 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak2BJ-0007V0-02
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 09:21:09 -0500
Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org)
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1Ak1ru-0005S7-St
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 09:01:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak1rr-0006EW-0j; Fri, 23 Jan 2004 09:01:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak1rS-00068I-A1
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 09:00:38 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01207
	for <megaco@ietf.org>; Fri, 23 Jan 2004 09:00:35 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak1rQ-00073U-00
	for megaco@ietf.org; Fri, 23 Jan 2004 09:00:36 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ak1qX-0006xR-00
	for megaco@ietf.org; Fri, 23 Jan 2004 08:59:44 -0500
Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak1ph-0006qj-00
	for megaco@ietf.org; Fri, 23 Jan 2004 08:58:49 -0500
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <XM89YDSF>; Fri, 23 Jan 2004 08:58:47 -0500
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA0350634F@wench.telica.com>
From: Carl Rutter <crutter@telica.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        Carl Rutter
	 <crutter@telica.com>,
        Aleksandr Ryabin <kengr@motorola.com>, sampathk@cisco.com,
        megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Fri, 23 Jan 2004 08:58:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3E1B8.FF856E34"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3E1B8.FF856E34
Content-Type: text/plain;
	charset="iso-8859-1"

OK,
 
Provisioned events have not been well defined per the RFC and
only rscID 0 can be used.  To your point
these should be avoided since the MGC may not know about them.
So maybe in the future we could have a mechanism so that the
MGC could specify pesistent events to the MG.  There could be
different flavors, one being reappy event when transistioning to the 
NULL context etc. Provisioned events would not be allowed. 
Comments?
 
Carl
 
 
-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Friday, January 23, 2004 8:49 AM
To: Carl Rutter; Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?



There is no concept of a persistent event in H.248.  The way to do this
would be to modify the termination with a new Events descriptor upon its
subtraction.  One possibility would be:

!/1 [12.34.56.78]:2944 T=123{C=12{S=term{}},C=-{MF=term{E=123{pkg/event}}}} 

Kevin 

-----Original Message----- 
From: Carl Rutter [ mailto:crutter@telica.com <mailto:crutter@telica.com> ] 
Sent: Friday, January 23, 2004 7:50 AM 
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Aleksandr Ryabin; sampathk@cisco.com;
megaco@ietf.org 
Subject: RE: [Megaco] Can chp/mgcon event be persistent event? 

Kevin, 

How would the MGC request a persistent event? 
I think this is what we are looking for. 
Events that hang around even after the 
termination is subtracted back to the NULL context. 

Thx, 
Carl 

-----Original Message----- 
From: megaco-admin@ietf.org [ mailto:megaco-admin@ietf.org
<mailto:megaco-admin@ietf.org> ]On Behalf Of Kevin Boyle 
Sent: Friday, January 23, 2004 3:48 AM 
To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org 
Subject: RE: [Megaco] Can chp/mgcon event be persistent event? 


Provisioned events and persistent events are two different things. 
Persistent events (in the world of MG control) implies that MGCs
automatically know about those events and will handle them at any time --
that is, MGs can depend on having those events handled.  Provisioned events
are items that the MG is set up to detect, but that the MG CANNOT depend on
having handled, as the MGC may not even support the package in question.

One other point: MGCs are not required to take any particular action with
regard to a Notify command.  If the Notify comes from a registered MG, then
the MGC ought to reply either affirmatively or with an error.  If the Notify
comes from an unregistered entity, then the MGC reserves the right to send
an error or not respond at all.

The key point is that MGs cannot depend upon any particular MGC behavior
when it comes to provisioned events. 

Kevin 


  _____ 

From: Aleksandr Ryabin [ mailto:kengr@motorola.com
<mailto:kengr@motorola.com> ] 
Sent: Thursday, January 22, 2004 2:16 PM 
To: sampathk@cisco.com; megaco@ietf.org 
Subject: RE: [Megaco] Can chp/mgcon event be persistent event? 


Hi Sampath, 

a) MGC can ether accept it, i.e. 1), or reject with error 458 (Unexpected
Event/RequestID). 
b) Any 

Regards, 
        Aleks 

At 01:48 PM 1/22/2004, Sampath Komanduri wrote: 


Aleks and Kevin, 
Thanks for responding. I do understand that in the absence of MGC requested
event, if MG has to generate a notification, it would use RequestID 0.

However, I don't see anything with respect to RequestID 0 handling in the
spec. other than the following text in Section 7.2.7:

    "Procedures for sending Notify commands with RequestID equal to 0 are
for futher study." 

a) What is the action *required* by the MGC upon recieving a notify with
requestID 0? 
    1) Is MGC supposed to do what it would have done if it had explicitly
asked for the eventNotification? In our example, is MGC "required" to take
the *same actions* to reduce congestion on MG (upon receipt of unsolicited

notification) which it would have taken if MGC had "solicited" the
notification? OR 
    2) MGC must just respond to the Notification and *not* do anything with
respect to helping MG in reducing the congestion.

    3) MGC can choose to *not* to even respond to the Notify? I hope this is
not the case, since it would result in a DISCONNECTED association.

b) Which events qualify to be notified to MGC with RequestID 0? 
    Only events on ROOT? Only event on ROOT and Analog lines? Any events? 

It would be good to see some supporting text in the Spec. if the authors
decide to leave the support of persistent events in Megaco.

Thanks, 
Sampath 





 -----Original Message----- 


From: Kevin Boyle [ mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com>  < mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> > ] 


Sent: Thursday, January 22, 2004 10:22 AM 


To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org 


Subject: RE: [Megaco] Can chp/mgcon event be persistent event? 



Provisioning something other than 0 will lead to rejection by the MGC. 
Further, provisioning is done at the MG's own risk, as there is no way the
MG can know ahead of time that the MGC supports the package in question.





Basically, the MG can have events provisioned, but all bets are off as to
whether the MGC will accept or reject the event.  My personal feeling is
that MGCs should ask for events they wish to see, and not rely upon any
"event provisioning".





Kevin 



  _____ 

From: Aleksandr Ryabin [ mailto:kengr@motorola.com
<mailto:kengr@motorola.com>  < mailto:kengr@motorola.com
<mailto:kengr@motorola.com> > ] 


Sent: Thursday, January 22, 2004 11:19 AM 


To: sampathk@cisco.com; megaco@ietf.org 


Subject: Re: [Megaco] Can chp/mgcon event be persistent event? 



Hi, 



Persistent events in MGCP are defined by package specs. 


Provisioned events in MEGACO are configured by an MG operator. 


As for any descriptor default EventsDescriptor values can be 


provisioned on MG to be non-empty. 



The only question here which RequestID to use for such pre-provisioned
events? 


The common consensus on the list was that 0 is a reasonable default value to




use in such cases, but of course can also be provisioned to something else 


by an MG operator. 



Regards, 


        Aleks 



At 03:20 PM 1/21/2004, Sampath Komanduri wrote: 



Hi all, 


It was my understanding that Megaco doesn't allow any persistent events. If
my understanding is correct... Could someone pls. clarify what the following
paragraph in H.248.10 mean?



ITU-T Rec. H.248.10 (07/2001) 1 



4.2 Events 


        4.2.1 MGCongestion 


                Event name: MGCon 


                        EventID: mgcon, (0x0001) 


                        Description: 


This event occurs when the MG requires that the MGC start or finish load
reduction 


towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the 


MGC or provisioned. 


                        EventsDescriptor Parameters: None 


                        ObservedEventsDescriptor Parameters 





Thanks, 


Sampath 


_______________________________________________ 
Megaco mailing list 
Megaco@ietf.org 
https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  


------_=_NextPart_001_01C3E1B8.FF856E34
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [Megaco] Can chp/mgcon event be persistent event?</TITLE>

<META content="MSHTML 6.00.2800.1106" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff 
size=2>OK,</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff 
size=2>Provisioned events have not been well defined per the RFC 
and</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff size=2>only 
rscID 0 can be used.&nbsp; To your point</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff size=2>these 
should be avoided since the MGC may not know about them.</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff size=2>So 
maybe in the future we could have a mechanism so that the</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff size=2>MGC 
could specify pesistent events to the MG.&nbsp; There could 
be</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff 
size=2>different flavors, one being reappy event when transistioning to the 
</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff size=2>NULL 
context etc.&nbsp;Provisioned events would not be 
allowed.&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff 
size=2>Comments?</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff 
size=2>Carl</FONT></SPAN></DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=195125313-23012004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Kevin Boyle 
[mailto:kboyle@nortelnetworks.com]<BR><B>Sent:</B> Friday, January 23, 2004 8:49 
AM<BR><B>To:</B> Carl Rutter; Aleksandr Ryabin; sampathk@cisco.com; 
megaco@ietf.org<BR><B>Subject:</B> RE: [Megaco] Can chp/mgcon event be 
persistent event?<BR><BR></FONT></DIV>
<P><FONT size=2>There is no concept of a persistent event in H.248.&nbsp; The 
way to do this would be to modify the termination with a new Events descriptor 
upon its subtraction.&nbsp; One possibility would be:</FONT></P>
<P><FONT size=2>!/1 [12.34.56.78]:2944 
T=123{C=12{S=term{}},C=-{MF=term{E=123{pkg/event}}}}</FONT> </P>
<P><FONT size=2>Kevin</FONT> </P>
<P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Carl 
Rutter [<A href="mailto:crutter@telica.com">mailto:crutter@telica.com</A>] 
</FONT><BR><FONT size=2>Sent: Friday, January 23, 2004 7:50 AM</FONT> <BR><FONT 
size=2>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Aleksandr Ryabin; sampathk@cisco.com; 
megaco@ietf.org</FONT> <BR><FONT size=2>Subject: RE: [Megaco] Can chp/mgcon 
event be persistent event?</FONT> </P>
<P><FONT size=2>Kevin,</FONT> </P>
<P><FONT size=2>How would the MGC request a persistent event?</FONT> <BR><FONT 
size=2>I think this is what we are looking for.</FONT> <BR><FONT size=2>Events 
that hang around even after the</FONT> <BR><FONT size=2>termination is 
subtracted back to the NULL context.</FONT> </P>
<P><FONT size=2>Thx,</FONT> <BR><FONT size=2>Carl</FONT> </P>
<P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
megaco-admin@ietf.org [<A 
href="mailto:megaco-admin@ietf.org">mailto:megaco-admin@ietf.org</A>]On Behalf 
Of Kevin Boyle</FONT> <BR><FONT size=2>Sent: Friday, January 23, 2004 3:48 
AM</FONT> <BR><FONT size=2>To: Aleksandr Ryabin; sampathk@cisco.com; 
megaco@ietf.org</FONT> <BR><FONT size=2>Subject: RE: [Megaco] Can chp/mgcon 
event be persistent event?</FONT> </P><BR>
<P><FONT size=2>Provisioned events and persistent events are two different 
things.</FONT> <BR><FONT size=2>Persistent events (in the world of MG control) 
implies that MGCs automatically know about those events and will handle them at 
any time -- that is, MGs can depend on having those events handled.&nbsp; 
Provisioned events are items that the MG is set up to detect, but that the MG 
CANNOT depend on having handled, as the MGC may not even support the package in 
question.</FONT></P>
<P><FONT size=2>One other point: MGCs are not required to take any particular 
action with regard to a Notify command.&nbsp; If the Notify comes from a 
registered MG, then the MGC ought to reply either affirmatively or with an 
error.&nbsp; If the Notify comes from an unregistered entity, then the MGC 
reserves the right to send an error or not respond at all.</FONT></P>
<P><FONT size=2>The key point is that MGs cannot depend upon any particular MGC 
behavior when it comes to provisioned events.</FONT> </P>
<P><FONT size=2>Kevin</FONT> </P><BR>
<P><FONT size=2>&nbsp; _____</FONT> </P>
<P><FONT size=2>From: Aleksandr Ryabin [<A 
href="mailto:kengr@motorola.com">mailto:kengr@motorola.com</A>]</FONT> <BR><FONT 
size=2>Sent: Thursday, January 22, 2004 2:16 PM</FONT> <BR><FONT size=2>To: 
sampathk@cisco.com; megaco@ietf.org</FONT> <BR><FONT size=2>Subject: RE: 
[Megaco] Can chp/mgcon event be persistent event?</FONT> </P><BR>
<P><FONT size=2>Hi Sampath,</FONT> </P>
<P><FONT size=2>a) MGC can ether accept it, i.e. 1), or reject with error 458 
(Unexpected Event/RequestID).</FONT> <BR><FONT size=2>b) Any</FONT> </P>
<P><FONT size=2>Regards,</FONT> <BR><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Aleks</FONT> </P>
<P><FONT size=2>At 01:48 PM 1/22/2004, Sampath Komanduri wrote:</FONT> </P><BR>
<P><FONT size=2>Aleks and Kevin,</FONT> <BR><FONT size=2>Thanks for responding. 
I do understand that in the absence of MGC requested event, if MG has to 
generate a notification, it would use RequestID 0.</FONT></P>
<P><FONT size=2>However, I don't see anything with respect to RequestID 0 
handling in the spec. other than the following text in Section 7.2.7:</FONT></P>
<P><FONT size=2>&nbsp;&nbsp;&nbsp; "Procedures for sending Notify commands with 
RequestID equal to 0 are for futher study."</FONT> </P>
<P><FONT size=2>a) What is the action *required* by the MGC upon recieving a 
notify with requestID 0?</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; 1) Is MGC 
supposed to do what it would have done if it had explicitly asked for the 
eventNotification? In our example, is MGC "required" to take the *same actions* 
to reduce congestion on MG (upon receipt of unsolicited</FONT></P>
<P><FONT size=2>notification) which it would have taken if MGC had "solicited" 
the notification? OR</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; 2) MGC must just 
respond to the Notification and *not* do anything with respect to helping MG in 
reducing the congestion.</FONT></P>
<P><FONT size=2>&nbsp;&nbsp;&nbsp; 3) MGC can choose to *not* to even respond to 
the Notify? I hope this is not the case, since it would result in a DISCONNECTED 
association.</FONT></P>
<P><FONT size=2>b) Which events qualify to be notified to MGC with RequestID 
0?</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; Only events on ROOT? Only event on 
ROOT and Analog lines? Any events?</FONT> </P>
<P><FONT size=2>It would be good to see some supporting text in the Spec. if the 
authors decide to leave the support of persistent events in Megaco.</FONT></P>
<P><FONT size=2>Thanks,</FONT> <BR><FONT size=2>Sampath</FONT> 
</P><BR><BR><BR><BR>
<P><FONT size=2>&nbsp;-----Original Message-----</FONT> </P><BR>
<P><FONT size=2>From: Kevin Boyle [<A 
href="mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.com</A> 
&lt;<A 
href="mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.com</A>&gt; 
]</FONT> </P><BR>
<P><FONT size=2>Sent: Thursday, January 22, 2004 10:22 AM</FONT> </P><BR>
<P><FONT size=2>To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org</FONT> 
</P><BR>
<P><FONT size=2>Subject: RE: [Megaco] Can chp/mgcon event be persistent 
event?</FONT> </P><BR><BR>
<P><FONT size=2>Provisioning something other than 0 will lead to rejection by 
the MGC.</FONT> <BR><FONT size=2>Further, provisioning is done at the MG's own 
risk, as there is no way the MG can know ahead of time that the MGC supports the 
package in question.</FONT></P><BR><BR><BR><BR>
<P><FONT size=2>Basically, the MG can have events provisioned, but all bets are 
off as to whether the MGC will accept or reject the event.&nbsp; My personal 
feeling is that MGCs should ask for events they wish to see, and not rely upon 
any "event provisioning".</FONT></P><BR><BR><BR><BR>
<P><FONT size=2>Kevin</FONT> </P><BR><BR>
<P><FONT size=2>&nbsp; _____</FONT> </P>
<P><FONT size=2>From: Aleksandr Ryabin [<A 
href="mailto:kengr@motorola.com">mailto:kengr@motorola.com</A> &lt;<A 
href="mailto:kengr@motorola.com">mailto:kengr@motorola.com</A>&gt; ]</FONT> 
</P><BR>
<P><FONT size=2>Sent: Thursday, January 22, 2004 11:19 AM</FONT> </P><BR>
<P><FONT size=2>To: sampathk@cisco.com; megaco@ietf.org</FONT> </P><BR>
<P><FONT size=2>Subject: Re: [Megaco] Can chp/mgcon event be persistent 
event?</FONT> </P><BR><BR>
<P><FONT size=2>Hi,</FONT> </P><BR><BR>
<P><FONT size=2>Persistent events in MGCP are defined by package specs.</FONT> 
</P><BR>
<P><FONT size=2>Provisioned events in MEGACO are configured by an MG 
operator.</FONT> </P><BR>
<P><FONT size=2>As for any descriptor default EventsDescriptor values can 
be</FONT> </P><BR>
<P><FONT size=2>provisioned on MG to be non-empty.</FONT> </P><BR><BR>
<P><FONT size=2>The only question here which RequestID to use for such 
pre-provisioned events?</FONT> </P><BR>
<P><FONT size=2>The common consensus on the list was that 0 is a reasonable 
default value to</FONT> </P><BR><BR>
<P><FONT size=2>use in such cases, but of course can also be provisioned to 
something else</FONT> </P><BR>
<P><FONT size=2>by an MG operator.</FONT> </P><BR><BR>
<P><FONT size=2>Regards,</FONT> </P><BR>
<P><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Aleks</FONT> 
</P><BR><BR>
<P><FONT size=2>At 03:20 PM 1/21/2004, Sampath Komanduri wrote:</FONT> 
</P><BR><BR>
<P><FONT size=2>Hi all,</FONT> </P><BR>
<P><FONT size=2>It was my understanding that Megaco doesn't allow any persistent 
events. If my understanding is correct... Could someone pls. clarify what the 
following paragraph in H.248.10 mean?</FONT></P><BR><BR>
<P><FONT size=2>ITU-T Rec. H.248.10 (07/2001) 1</FONT> </P><BR><BR>
<P><FONT size=2>4.2 Events</FONT> </P><BR>
<P><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.2.1 
MGCongestion</FONT> </P><BR>
<P><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Event name: MGCon</FONT> </P><BR>
<P><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
EventID: mgcon, (0x0001)</FONT> </P><BR>
<P><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Description:</FONT> </P><BR>
<P><FONT size=2>This event occurs when the MG requires that the MGC start or 
finish load reduction</FONT> </P><BR>
<P><FONT size=2>towards the MG or to adjust the Load Reduction Percentage. The 
event is ordered by the</FONT> </P><BR>
<P><FONT size=2>MGC or provisioned.</FONT> </P><BR>
<P><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
EventsDescriptor Parameters: None</FONT> </P><BR>
<P><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
ObservedEventsDescriptor Parameters</FONT> </P><BR><BR><BR><BR>
<P><FONT size=2>Thanks,</FONT> </P><BR>
<P><FONT size=2>Sampath</FONT> </P><BR>
<P><FONT size=2>_______________________________________________</FONT> <BR><FONT 
size=2>Megaco mailing list</FONT> <BR><FONT size=2>Megaco@ietf.org</FONT> 
<BR><FONT size=2><A href="https://www1.ietf.org/mailman/listinfo/megaco" 
target=_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> 
</P></BODY></HTML>

------_=_NextPart_001_01C3E1B8.FF856E34--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan 23 12:56:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13450
	for <megaco-archive@lists.ietf.org>; Fri, 23 Jan 2004 12:56:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak5XG-0006OX-7N; Fri, 23 Jan 2004 12:56:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak5Wz-0006NK-RU
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 12:55:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13431
	for <megaco@ietf.org>; Fri, 23 Jan 2004 12:55:41 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak5Wy-0003yG-00
	for megaco@ietf.org; Fri, 23 Jan 2004 12:55:44 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ak5W1-0003w9-00
	for megaco@ietf.org; Fri, 23 Jan 2004 12:54:47 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak5V8-0003tu-00
	for megaco@ietf.org; Fri, 23 Jan 2004 12:53:50 -0500
Received: from SAMPATHKW2K03 (sjc-vpn4-646.cisco.com [10.21.82.134])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0NHr95k029290;
	Fri, 23 Jan 2004 09:53:12 -0800 (PST)
Reply-To: <sampathk@cisco.com>
From: "Sampath Komanduri" <sampathk@cisco.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'Carl Rutter'" <crutter@telica.com>,
        "'Aleksandr Ryabin'" <kengr@motorola.com>, <megaco@ietf.org>
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Fri, 23 Jan 2004 09:53:08 -0800
Organization: Cisco Systems
Message-ID: <001801c3e1d9$c5788a70$220110ac@SAMPATHKW2K03>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0019_01C3E196.B7554A70"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-reply-to: <ABA227A15B80D511BD1A00508BF93A1C0E0753B8@zrtpd0jq.us.nortel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Importance: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=HTML_20_30,HTML_FONTCOLOR_BLUE,
	HTML_MESSAGE autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0019_01C3E196.B7554A70
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Yes Kevin,
There are other problems as well. For large MG's which are configured in
a redundant setup, these events have to be journaled on a per event per
termination basis every time they change. 
 
Example for CAS calls:
Across switchovers, in order to maintain *at least* the calls where the
voice path is cut-through, MG has to journal
on-hook/off-hook/idle/clear-forward/clear-backward events (based on the
variants supported on different terminations/lines) or MGC has to re-arm
the terminations with all these events.
At that time the wild-carded Modify trick may not work since different
terminations will be in different stages of call setup. MG and MGC have
to exchange lot of messages in order come in sync. with each other.
 
Regarding provisioned vs.. persistent events, I don't see any difference
between them. From MG's point of view, both are same and it would be
better if it can expect that such notifications are handled by MGC in
the same way as they were for solicited events.
 
Another note: Your statement that "MG doesn't know which package is
configured on MGC" is only partly true. The user who is "provisioning"
the event and/or package on termination (on MG)  *must* know that these
events would be generated towards MGC and if it is supported by MGC. 
There are only two possibilities:
    a) If H.248 gives user the ability to "provision" events on MG, it
*should expect* the user to know whether MGC supports this package or
not. Thereby implicitly telling the MG that MG should notify MGC upon
detection of these events.
    b) If H.248 wants to hide these details i.e. which package is
supported by MG/MGC (I don't know how it can do that) from user, we
shouldn't allow even the "provisioned" events in the protocol model.
 
Rgds,
Sampath
 

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] 
Sent: Friday, January 23, 2004 12:51 AM
To: Carl Rutter; Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?



The MGC is capable of sending a wildcarded Modify command requesting the
MG look for events on multiple terminations.  To reduce the message
reply size, the MGC can request a wildcarded response as well.  Is there
some further problem?

Kevin 

-----Original Message----- 
From: Carl Rutter [mailto:crutter@telica.com] 
Sent: Thursday, January 22, 2004 1:46 PM 
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Aleksandr Ryabin;
sampathk@cisco.com; megaco@ietf.org 
Subject: RE: [Megaco] Can chp/mgcon event be persistent event? 

I guess my only concern here is the overhead involved in the MGC asking
for events in some cases. 
ie) High-Density Gateway running CAS. 
As densities increase we may want to foster a better MG event
provisioning approach. 

Carl 

-----Original Message----- 
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] 
Sent: Thursday, January 22, 2004 1:22 PM 
To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org 
Subject: RE: [Megaco] Can chp/mgcon event be persistent event? 


Provisioning something other than 0 will lead to rejection by the MGC. 
Further, provisioning is done at the MG's own risk, as there is no way
the MG can know ahead of time that the MGC supports the package in
question.


Basically, the MG can have events provisioned, but all bets are off as
to whether the MGC will accept or reject the event.  My personal feeling
is that MGCs should ask for events they wish to see, and not rely upon
any "event provisioning".


Kevin 


  _____  

From: Aleksandr Ryabin [mailto:kengr@motorola.com] 
Sent: Thursday, January 22, 2004 11:19 AM 
To: sampathk@cisco.com; megaco@ietf.org 
Subject: Re: [Megaco] Can chp/mgcon event be persistent event? 


Hi, 

Persistent events in MGCP are defined by package specs. 
Provisioned events in MEGACO are configured by an MG operator. 
As for any descriptor default EventsDescriptor values can be 
provisioned on MG to be non-empty. 

The only question here which RequestID to use for such pre-provisioned 
events? 
The common consensus on the list was that 0 is a reasonable default
value to 

use in such cases, but of course can also be provisioned to something
else 
by an MG operator. 

Regards, 
        Aleks 

At 03:20 PM 1/21/2004, Sampath Komanduri wrote: 


Hi all, 
It was my understanding that Megaco doesn't allow any persistent events.
If 
my understanding is correct... Could someone pls. clarify what the
following 
paragraph in H.248.10 mean? 

ITU-T Rec. H.248.10 (07/2001) 1 

4.2 Events 
        4.2.1 MGCongestion 
                Event name: MGCon 
                        EventID: mgcon, (0x0001) 
                        Description: 
This event occurs when the MG requires that the MGC start or finish load

reduction 
towards the MG or to adjust the Load Reduction Percentage. The event is 
ordered by the 
MGC or provisioned. 
                        EventsDescriptor Parameters: None 
                        ObservedEventsDescriptor Parameters 
  
Thanks, 
Sampath 


_______________________________________________ 
Megaco mailing list 
Megaco@ietf.org 
https://www1.ietf.org/mailman/listinfo/megaco 


------=_NextPart_000_0019_01C3E196.B7554A70
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =
size=3D2>Yes=20
Kevin,</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =
size=3D2>There=20
are other problems as well. For large MG's which are configured in a =
redundant=20
setup, these events have to be journaled on a per event per=20
termination&nbsp;basis every time they change. </FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Example for CAS calls:</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =
size=3D2>Across=20
switchovers, in order to maintain *at least* the calls&nbsp;where the =
voice path=20
is cut-through, MG has to journal=20
on-hook/off-hook/idle/clear-forward/clear-backward events (based on the =
variants=20
supported on different terminations/lines)&nbsp;or MGC has to re-arm the =

terminations with all these events.</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =
size=3D2>At=20
that time the wild-carded Modify trick may not work since different =
terminations=20
will be in different stages of call setup. MG and MGC have to exchange =
lot of=20
messages in order come in sync. with each other.</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Regarding provisioned vs.. persistent events, I don't see any =
difference=20
between them. From MG's point of view, both are same and it would be =
better if=20
it can expect that such notifications are handled by MGC in the same way =
as they=20
were for solicited events.</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Another note: Your statement that "MG doesn't know which =
package is=20
configured on MGC" is only partly true. The user who is "provisioning" =
the event=20
and/or package on termination (on MG) &nbsp;*must* know that these =
events would=20
be generated towards MGC and if it is supported by MGC. =
</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =
size=3D2>There=20
are only two possibilities:</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004>&nbsp;&nbsp;&nbsp; <FONT =
face=3DArial=20
color=3D#0000ff size=3D2>a) If H.248 gives user the ability to =
"provision" events on=20
MG, it *should expect* the user to know whether MGC supports this =
package or=20
not. Thereby implicitly telling the MG that MG should notify MGC upon =
detection=20
of these events.</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004>&nbsp;&nbsp;&nbsp; <FONT =
face=3DArial=20
color=3D#0000ff size=3D2>b) If H.248 wants to hide these details i.e. =
which package=20
is supported by MG/MGC (I don't know how it can do that) from user, we =
shouldn't=20
allow even the "provisioned" events in the protocol =
model.</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Rgds,</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Sampath</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Kevin Boyle=20
  [mailto:kboyle@nortelnetworks.com] <BR><B>Sent:</B> Friday, January =
23, 2004=20
  12:51 AM<BR><B>To:</B> Carl Rutter; Aleksandr Ryabin; =
sampathk@cisco.com;=20
  megaco@ietf.org<BR><B>Subject:</B> RE: [Megaco] Can chp/mgcon event be =

  persistent event?<BR><BR></FONT></DIV>
  <P><FONT size=3D2>The MGC is capable of sending a wildcarded Modify =
command=20
  requesting the MG look for events on multiple terminations.&nbsp; To =
reduce=20
  the message reply size, the MGC can request a wildcarded response as=20
  well.&nbsp; Is there some further problem?</FONT></P>
  <P><FONT size=3D2>Kevin </FONT></P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: Carl=20
  Rutter [<A =
href=3D"mailto:crutter@telica.com">mailto:crutter@telica.com</A>]=20
  </FONT><BR><FONT size=3D2>Sent: Thursday, January 22, 2004 1:46 =
PM</FONT>=20
  <BR><FONT size=3D2>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Aleksandr =
Ryabin;=20
  sampathk@cisco.com; megaco@ietf.org</FONT> <BR><FONT size=3D2>Subject: =
RE:=20
  [Megaco] Can chp/mgcon event be persistent event?</FONT> </P>
  <P><FONT size=3D2>I guess my only concern here is the overhead =
involved in the=20
  MGC asking for events in some cases.</FONT> <BR><FONT size=3D2>ie) =
High-Density=20
  Gateway running CAS.</FONT> <BR><FONT size=3D2>As densities increase =
we may want=20
  to foster a better MG event provisioning approach.</FONT> </P>
  <P><FONT size=3D2>Carl</FONT> </P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: Kevin=20
  Boyle [<A=20
  =
href=3D"mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.co=
m</A>]</FONT>=20
  <BR><FONT size=3D2>Sent: Thursday, January 22, 2004 1:22 PM</FONT> =
<BR><FONT=20
  size=3D2>To: Aleksandr Ryabin; sampathk@cisco.com; =
megaco@ietf.org</FONT>=20
  <BR><FONT size=3D2>Subject: RE: [Megaco] Can chp/mgcon event be =
persistent=20
  event?</FONT> </P><BR>
  <P><FONT size=3D2>Provisioning something other than 0 will lead to =
rejection by=20
  the MGC.</FONT> <BR><FONT size=3D2>Further, provisioning is done at =
the MG's own=20
  risk, as there is no way the MG can know ahead of time that the MGC =
supports=20
  the package in question.</FONT></P>
  <P><FONT size=3D2></FONT> <BR><FONT size=3D2>Basically, the MG can =
have events=20
  provisioned, but all bets are off as to whether the MGC will accept or =
reject=20
  the event.&nbsp; My personal feeling is that MGCs should ask for =
events they=20
  wish to see, and not rely upon any "event provisioning".</FONT></P>
  <P><FONT size=3D2></FONT> <BR><FONT size=3D2>Kevin</FONT> </P><BR>
  <P><FONT size=3D2>&nbsp; _____&nbsp; </FONT></P>
  <P><FONT size=3D2>From: Aleksandr Ryabin [<A=20
  =
href=3D"mailto:kengr@motorola.com">mailto:kengr@motorola.com</A>]</FONT> =

  <BR><FONT size=3D2>Sent: Thursday, January 22, 2004 11:19 AM</FONT> =
<BR><FONT=20
  size=3D2>To: sampathk@cisco.com; megaco@ietf.org</FONT> <BR><FONT=20
  size=3D2>Subject: Re: [Megaco] Can chp/mgcon event be persistent =
event?</FONT>=20
  </P><BR>
  <P><FONT size=3D2>Hi,</FONT> </P>
  <P><FONT size=3D2>Persistent events in MGCP are defined by package =
specs.</FONT>=20
  <BR><FONT size=3D2>Provisioned events in MEGACO are configured by an =
MG=20
  operator.</FONT> <BR><FONT size=3D2>As for any descriptor default=20
  EventsDescriptor values can be</FONT> <BR><FONT size=3D2>provisioned =
on MG to be=20
  non-empty.</FONT> </P>
  <P><FONT size=3D2>The only question here which RequestID to use for =
such=20
  pre-provisioned</FONT> <BR><FONT size=3D2>events?</FONT> <BR><FONT =
size=3D2>The=20
  common consensus on the list was that 0 is a reasonable default value=20
  to</FONT> </P>
  <P><FONT size=3D2>use in such cases, but of course can also be =
provisioned to=20
  something else</FONT> <BR><FONT size=3D2>by an MG operator.</FONT> =
</P>
  <P><FONT size=3D2>Regards,</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Aleks</FONT> </P>
  <P><FONT size=3D2>At 03:20 PM 1/21/2004, Sampath Komanduri =
wrote:</FONT>=20
</P><BR>
  <P><FONT size=3D2>Hi all,</FONT> <BR><FONT size=3D2>It was my =
understanding that=20
  Megaco doesn't allow any persistent events. If</FONT> <BR><FONT =
size=3D2>my=20
  understanding is correct... Could someone pls. clarify what the=20
  following</FONT> <BR><FONT size=3D2>paragraph in H.248.10 mean?</FONT> =
</P>
  <P><FONT size=3D2>ITU-T Rec. H.248.10 (07/2001) 1</FONT> </P>
  <P><FONT size=3D2>4.2 Events</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.2.1 =
MGCongestion</FONT>=20
  <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Event name: MGCon</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  EventID: mgcon, (0x0001)</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  Description:</FONT> <BR><FONT size=3D2>This event occurs when the MG =
requires=20
  that the MGC start or finish load</FONT> <BR><FONT =
size=3D2>reduction</FONT>=20
  <BR><FONT size=3D2>towards the MG or to adjust the Load Reduction =
Percentage.=20
  The event is</FONT> <BR><FONT size=3D2>ordered by the</FONT> <BR><FONT =

  size=3D2>MGC or provisioned.</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  EventsDescriptor Parameters: None</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  ObservedEventsDescriptor Parameters </FONT><BR><FONT =
size=3D2>&nbsp;</FONT>=20
  <BR><FONT size=3D2>Thanks,</FONT> <BR><FONT size=3D2>Sampath</FONT> =
</P><BR>
  <P><FONT =
size=3D2>_______________________________________________</FONT>=20
  <BR><FONT size=3D2>Megaco mailing list</FONT> <BR><FONT=20
  size=3D2>Megaco@ietf.org</FONT> <BR><FONT size=3D2><A=20
  href=3D"https://www1.ietf.org/mailman/listinfo/megaco"=20
  =
target=3D_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> =

</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0019_01C3E196.B7554A70--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan 23 12:58:20 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13565
	for <megaco-archive@odin.ietf.org>; Fri, 23 Jan 2004 12:58:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak5Z3-0006Yt-To
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 12:57:54 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NHvrPC025219
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 12:57:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak5Z3-0006Yg-OB
	for megaco-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 12:57:53 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13545
	for <megaco-web-archive@ietf.org>; Fri, 23 Jan 2004 12:57:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak5Z1-00046S-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 12:57:51 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ak5YB-00043Q-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 12:57:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak5XF-00040f-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 12:56:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak5XG-0006OX-7N; Fri, 23 Jan 2004 12:56:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ak5Wz-0006NK-RU
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 12:55:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13431
	for <megaco@ietf.org>; Fri, 23 Jan 2004 12:55:41 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak5Wy-0003yG-00
	for megaco@ietf.org; Fri, 23 Jan 2004 12:55:44 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ak5W1-0003w9-00
	for megaco@ietf.org; Fri, 23 Jan 2004 12:54:47 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ak5V8-0003tu-00
	for megaco@ietf.org; Fri, 23 Jan 2004 12:53:50 -0500
Received: from SAMPATHKW2K03 (sjc-vpn4-646.cisco.com [10.21.82.134])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0NHr95k029290;
	Fri, 23 Jan 2004 09:53:12 -0800 (PST)
Reply-To: <sampathk@cisco.com>
From: "Sampath Komanduri" <sampathk@cisco.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'Carl Rutter'" <crutter@telica.com>,
        "'Aleksandr Ryabin'" <kengr@motorola.com>, <megaco@ietf.org>
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?
Date: Fri, 23 Jan 2004 09:53:08 -0800
Organization: Cisco Systems
Message-ID: <001801c3e1d9$c5788a70$220110ac@SAMPATHKW2K03>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0019_01C3E196.B7554A70"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-reply-to: <ABA227A15B80D511BD1A00508BF93A1C0E0753B8@zrtpd0jq.us.nortel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Importance: Normal
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=HTML_20_30,HTML_FONTCOLOR_BLUE,
	HTML_MESSAGE autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_0019_01C3E196.B7554A70
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Yes Kevin,
There are other problems as well. For large MG's which are configured in
a redundant setup, these events have to be journaled on a per event per
termination basis every time they change. 
 
Example for CAS calls:
Across switchovers, in order to maintain *at least* the calls where the
voice path is cut-through, MG has to journal
on-hook/off-hook/idle/clear-forward/clear-backward events (based on the
variants supported on different terminations/lines) or MGC has to re-arm
the terminations with all these events.
At that time the wild-carded Modify trick may not work since different
terminations will be in different stages of call setup. MG and MGC have
to exchange lot of messages in order come in sync. with each other.
 
Regarding provisioned vs.. persistent events, I don't see any difference
between them. From MG's point of view, both are same and it would be
better if it can expect that such notifications are handled by MGC in
the same way as they were for solicited events.
 
Another note: Your statement that "MG doesn't know which package is
configured on MGC" is only partly true. The user who is "provisioning"
the event and/or package on termination (on MG)  *must* know that these
events would be generated towards MGC and if it is supported by MGC. 
There are only two possibilities:
    a) If H.248 gives user the ability to "provision" events on MG, it
*should expect* the user to know whether MGC supports this package or
not. Thereby implicitly telling the MG that MG should notify MGC upon
detection of these events.
    b) If H.248 wants to hide these details i.e. which package is
supported by MG/MGC (I don't know how it can do that) from user, we
shouldn't allow even the "provisioned" events in the protocol model.
 
Rgds,
Sampath
 

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] 
Sent: Friday, January 23, 2004 12:51 AM
To: Carl Rutter; Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?



The MGC is capable of sending a wildcarded Modify command requesting the
MG look for events on multiple terminations.  To reduce the message
reply size, the MGC can request a wildcarded response as well.  Is there
some further problem?

Kevin 

-----Original Message----- 
From: Carl Rutter [mailto:crutter@telica.com] 
Sent: Thursday, January 22, 2004 1:46 PM 
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Aleksandr Ryabin;
sampathk@cisco.com; megaco@ietf.org 
Subject: RE: [Megaco] Can chp/mgcon event be persistent event? 

I guess my only concern here is the overhead involved in the MGC asking
for events in some cases. 
ie) High-Density Gateway running CAS. 
As densities increase we may want to foster a better MG event
provisioning approach. 

Carl 

-----Original Message----- 
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] 
Sent: Thursday, January 22, 2004 1:22 PM 
To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org 
Subject: RE: [Megaco] Can chp/mgcon event be persistent event? 


Provisioning something other than 0 will lead to rejection by the MGC. 
Further, provisioning is done at the MG's own risk, as there is no way
the MG can know ahead of time that the MGC supports the package in
question.


Basically, the MG can have events provisioned, but all bets are off as
to whether the MGC will accept or reject the event.  My personal feeling
is that MGCs should ask for events they wish to see, and not rely upon
any "event provisioning".


Kevin 


  _____  

From: Aleksandr Ryabin [mailto:kengr@motorola.com] 
Sent: Thursday, January 22, 2004 11:19 AM 
To: sampathk@cisco.com; megaco@ietf.org 
Subject: Re: [Megaco] Can chp/mgcon event be persistent event? 


Hi, 

Persistent events in MGCP are defined by package specs. 
Provisioned events in MEGACO are configured by an MG operator. 
As for any descriptor default EventsDescriptor values can be 
provisioned on MG to be non-empty. 

The only question here which RequestID to use for such pre-provisioned 
events? 
The common consensus on the list was that 0 is a reasonable default
value to 

use in such cases, but of course can also be provisioned to something
else 
by an MG operator. 

Regards, 
        Aleks 

At 03:20 PM 1/21/2004, Sampath Komanduri wrote: 


Hi all, 
It was my understanding that Megaco doesn't allow any persistent events.
If 
my understanding is correct... Could someone pls. clarify what the
following 
paragraph in H.248.10 mean? 

ITU-T Rec. H.248.10 (07/2001) 1 

4.2 Events 
        4.2.1 MGCongestion 
                Event name: MGCon 
                        EventID: mgcon, (0x0001) 
                        Description: 
This event occurs when the MG requires that the MGC start or finish load

reduction 
towards the MG or to adjust the Load Reduction Percentage. The event is 
ordered by the 
MGC or provisioned. 
                        EventsDescriptor Parameters: None 
                        ObservedEventsDescriptor Parameters 
  
Thanks, 
Sampath 


_______________________________________________ 
Megaco mailing list 
Megaco@ietf.org 
https://www1.ietf.org/mailman/listinfo/megaco 


------=_NextPart_000_0019_01C3E196.B7554A70
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =
size=3D2>Yes=20
Kevin,</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =
size=3D2>There=20
are other problems as well. For large MG's which are configured in a =
redundant=20
setup, these events have to be journaled on a per event per=20
termination&nbsp;basis every time they change. </FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Example for CAS calls:</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =
size=3D2>Across=20
switchovers, in order to maintain *at least* the calls&nbsp;where the =
voice path=20
is cut-through, MG has to journal=20
on-hook/off-hook/idle/clear-forward/clear-backward events (based on the =
variants=20
supported on different terminations/lines)&nbsp;or MGC has to re-arm the =

terminations with all these events.</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =
size=3D2>At=20
that time the wild-carded Modify trick may not work since different =
terminations=20
will be in different stages of call setup. MG and MGC have to exchange =
lot of=20
messages in order come in sync. with each other.</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Regarding provisioned vs.. persistent events, I don't see any =
difference=20
between them. From MG's point of view, both are same and it would be =
better if=20
it can expect that such notifications are handled by MGC in the same way =
as they=20
were for solicited events.</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Another note: Your statement that "MG doesn't know which =
package is=20
configured on MGC" is only partly true. The user who is "provisioning" =
the event=20
and/or package on termination (on MG) &nbsp;*must* know that these =
events would=20
be generated towards MGC and if it is supported by MGC. =
</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =
size=3D2>There=20
are only two possibilities:</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004>&nbsp;&nbsp;&nbsp; <FONT =
face=3DArial=20
color=3D#0000ff size=3D2>a) If H.248 gives user the ability to =
"provision" events on=20
MG, it *should expect* the user to know whether MGC supports this =
package or=20
not. Thereby implicitly telling the MG that MG should notify MGC upon =
detection=20
of these events.</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004>&nbsp;&nbsp;&nbsp; <FONT =
face=3DArial=20
color=3D#0000ff size=3D2>b) If H.248 wants to hide these details i.e. =
which package=20
is supported by MG/MGC (I don't know how it can do that) from user, we =
shouldn't=20
allow even the "provisioned" events in the protocol =
model.</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Rgds,</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Sampath</FONT></SPAN></DIV>
<DIV><SPAN class=3D687195916-23012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Kevin Boyle=20
  [mailto:kboyle@nortelnetworks.com] <BR><B>Sent:</B> Friday, January =
23, 2004=20
  12:51 AM<BR><B>To:</B> Carl Rutter; Aleksandr Ryabin; =
sampathk@cisco.com;=20
  megaco@ietf.org<BR><B>Subject:</B> RE: [Megaco] Can chp/mgcon event be =

  persistent event?<BR><BR></FONT></DIV>
  <P><FONT size=3D2>The MGC is capable of sending a wildcarded Modify =
command=20
  requesting the MG look for events on multiple terminations.&nbsp; To =
reduce=20
  the message reply size, the MGC can request a wildcarded response as=20
  well.&nbsp; Is there some further problem?</FONT></P>
  <P><FONT size=3D2>Kevin </FONT></P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: Carl=20
  Rutter [<A =
href=3D"mailto:crutter@telica.com">mailto:crutter@telica.com</A>]=20
  </FONT><BR><FONT size=3D2>Sent: Thursday, January 22, 2004 1:46 =
PM</FONT>=20
  <BR><FONT size=3D2>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Aleksandr =
Ryabin;=20
  sampathk@cisco.com; megaco@ietf.org</FONT> <BR><FONT size=3D2>Subject: =
RE:=20
  [Megaco] Can chp/mgcon event be persistent event?</FONT> </P>
  <P><FONT size=3D2>I guess my only concern here is the overhead =
involved in the=20
  MGC asking for events in some cases.</FONT> <BR><FONT size=3D2>ie) =
High-Density=20
  Gateway running CAS.</FONT> <BR><FONT size=3D2>As densities increase =
we may want=20
  to foster a better MG event provisioning approach.</FONT> </P>
  <P><FONT size=3D2>Carl</FONT> </P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: Kevin=20
  Boyle [<A=20
  =
href=3D"mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.co=
m</A>]</FONT>=20
  <BR><FONT size=3D2>Sent: Thursday, January 22, 2004 1:22 PM</FONT> =
<BR><FONT=20
  size=3D2>To: Aleksandr Ryabin; sampathk@cisco.com; =
megaco@ietf.org</FONT>=20
  <BR><FONT size=3D2>Subject: RE: [Megaco] Can chp/mgcon event be =
persistent=20
  event?</FONT> </P><BR>
  <P><FONT size=3D2>Provisioning something other than 0 will lead to =
rejection by=20
  the MGC.</FONT> <BR><FONT size=3D2>Further, provisioning is done at =
the MG's own=20
  risk, as there is no way the MG can know ahead of time that the MGC =
supports=20
  the package in question.</FONT></P>
  <P><FONT size=3D2></FONT> <BR><FONT size=3D2>Basically, the MG can =
have events=20
  provisioned, but all bets are off as to whether the MGC will accept or =
reject=20
  the event.&nbsp; My personal feeling is that MGCs should ask for =
events they=20
  wish to see, and not rely upon any "event provisioning".</FONT></P>
  <P><FONT size=3D2></FONT> <BR><FONT size=3D2>Kevin</FONT> </P><BR>
  <P><FONT size=3D2>&nbsp; _____&nbsp; </FONT></P>
  <P><FONT size=3D2>From: Aleksandr Ryabin [<A=20
  =
href=3D"mailto:kengr@motorola.com">mailto:kengr@motorola.com</A>]</FONT> =

  <BR><FONT size=3D2>Sent: Thursday, January 22, 2004 11:19 AM</FONT> =
<BR><FONT=20
  size=3D2>To: sampathk@cisco.com; megaco@ietf.org</FONT> <BR><FONT=20
  size=3D2>Subject: Re: [Megaco] Can chp/mgcon event be persistent =
event?</FONT>=20
  </P><BR>
  <P><FONT size=3D2>Hi,</FONT> </P>
  <P><FONT size=3D2>Persistent events in MGCP are defined by package =
specs.</FONT>=20
  <BR><FONT size=3D2>Provisioned events in MEGACO are configured by an =
MG=20
  operator.</FONT> <BR><FONT size=3D2>As for any descriptor default=20
  EventsDescriptor values can be</FONT> <BR><FONT size=3D2>provisioned =
on MG to be=20
  non-empty.</FONT> </P>
  <P><FONT size=3D2>The only question here which RequestID to use for =
such=20
  pre-provisioned</FONT> <BR><FONT size=3D2>events?</FONT> <BR><FONT =
size=3D2>The=20
  common consensus on the list was that 0 is a reasonable default value=20
  to</FONT> </P>
  <P><FONT size=3D2>use in such cases, but of course can also be =
provisioned to=20
  something else</FONT> <BR><FONT size=3D2>by an MG operator.</FONT> =
</P>
  <P><FONT size=3D2>Regards,</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Aleks</FONT> </P>
  <P><FONT size=3D2>At 03:20 PM 1/21/2004, Sampath Komanduri =
wrote:</FONT>=20
</P><BR>
  <P><FONT size=3D2>Hi all,</FONT> <BR><FONT size=3D2>It was my =
understanding that=20
  Megaco doesn't allow any persistent events. If</FONT> <BR><FONT =
size=3D2>my=20
  understanding is correct... Could someone pls. clarify what the=20
  following</FONT> <BR><FONT size=3D2>paragraph in H.248.10 mean?</FONT> =
</P>
  <P><FONT size=3D2>ITU-T Rec. H.248.10 (07/2001) 1</FONT> </P>
  <P><FONT size=3D2>4.2 Events</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.2.1 =
MGCongestion</FONT>=20
  <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Event name: MGCon</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  EventID: mgcon, (0x0001)</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  Description:</FONT> <BR><FONT size=3D2>This event occurs when the MG =
requires=20
  that the MGC start or finish load</FONT> <BR><FONT =
size=3D2>reduction</FONT>=20
  <BR><FONT size=3D2>towards the MG or to adjust the Load Reduction =
Percentage.=20
  The event is</FONT> <BR><FONT size=3D2>ordered by the</FONT> <BR><FONT =

  size=3D2>MGC or provisioned.</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  EventsDescriptor Parameters: None</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  ObservedEventsDescriptor Parameters </FONT><BR><FONT =
size=3D2>&nbsp;</FONT>=20
  <BR><FONT size=3D2>Thanks,</FONT> <BR><FONT size=3D2>Sampath</FONT> =
</P><BR>
  <P><FONT =
size=3D2>_______________________________________________</FONT>=20
  <BR><FONT size=3D2>Megaco mailing list</FONT> <BR><FONT=20
  size=3D2>Megaco@ietf.org</FONT> <BR><FONT size=3D2><A=20
  href=3D"https://www1.ietf.org/mailman/listinfo/megaco"=20
  =
target=3D_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> =

</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0019_01C3E196.B7554A70--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan 23 22:12:28 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09118
	for <megaco-archive@lists.ietf.org>; Fri, 23 Jan 2004 22:12:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AkEDJ-0001K6-0N; Fri, 23 Jan 2004 22:12:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AkECN-0001JV-IR
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 22:11:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09090
	for <megaco@ietf.org>; Fri, 23 Jan 2004 22:10:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AkECK-00058q-00
	for megaco@ietf.org; Fri, 23 Jan 2004 22:11:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AkEBN-000582-00
	for megaco@ietf.org; Fri, 23 Jan 2004 22:10:02 -0500
Received: from smtp-27.ig.com.br ([200.226.132.159])
	by ietf-mx with smtp (Exim 4.12)
	id 1AkEAb-00056F-00
	for megaco@ietf.org; Fri, 23 Jan 2004 22:09:13 -0500
Received: (qmail 2924 invoked from network); 24 Jan 2004 03:06:45 -0000
Received: from unknown (HELO tipkpfqazswj71) (200.151.172.202)
  by smtp-27.ig.com.br with SMTP; 24 Jan 2004 03:06:45 -0000
Message-ID: <000601c3e227$53d7cf40$caac97c8@tipkpfqazswj71>
From: "luka" <luka682@ig.com.br>
To: <megaco@ietf.org>
Date: Fri, 23 Jan 2004 23:55:34 -0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0008_01C3E20C.6415C8A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS,
	HTML_50_60,HTML_MESSAGE autolearn=no version=2.60
Subject: [Megaco] Megaco vs MGCP
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01C3E20C.6415C8A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi, All !

 I am quite new at studing Megaco/H.248 therefore I have some elementary =
questions.    =20
=20
1 - When should we use Megaco instead of MGCP ?=20

2 - Why Megaco has been developed?What was the reason to its =
development?   =20

3- I=B4d like to get information about the comparison MGCP model vs =
Megaco model .=20

Is there any interesting site or paper on Internet that I can find out =
about this.?  =20

Could you please give me a help?

Regards

Luka
------=_NextPart_000_0008_01C3E20C.6415C8A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1264" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi, All !</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;I am quite new at studing=20
Megaco/H.248&nbsp;therefore I have some&nbsp;elementary questions.=20
&nbsp;&nbsp;&nbsp;&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>1 -&nbsp;When&nbsp;should we use=20
Megaco&nbsp;instead of MGCP ?&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2 - Why&nbsp;Megaco has=20
been&nbsp;developed?What&nbsp;was the reason to&nbsp;its=20
development?&nbsp;&nbsp;&nbsp;&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>3- I=B4d like to get information about =
the comparison=20
MGCP model vs Megaco model . </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Is there any interesting site or paper =
on=20
Internet&nbsp;that I&nbsp;can find out&nbsp;about=20
this.?&nbsp;&nbsp;&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Could you please&nbsp;give me a =
help?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Luka</FONT></DIV></BODY></HTML>

------=_NextPart_000_0008_01C3E20C.6415C8A0--



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan 23 22:13:33 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09152
	for <megaco-archive@odin.ietf.org>; Fri, 23 Jan 2004 22:13:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AkEEM-0001Td-Tj
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 22:13:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0O3D6qW005673
	for megaco-archive@odin.ietf.org; Fri, 23 Jan 2004 22:13:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AkEEM-0001TQ-Pd
	for megaco-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 22:13:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09146
	for <megaco-web-archive@ietf.org>; Fri, 23 Jan 2004 22:13:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AkEEJ-0005D0-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 22:13:03 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AkEDW-0005Bp-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 22:12:14 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AkEDH-0005AI-00
	for megaco-web-archive@ietf.org; Fri, 23 Jan 2004 22:11:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AkEDJ-0001K6-0N; Fri, 23 Jan 2004 22:12:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AkECN-0001JV-IR
	for megaco@optimus.ietf.org; Fri, 23 Jan 2004 22:11:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09090
	for <megaco@ietf.org>; Fri, 23 Jan 2004 22:10:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AkECK-00058q-00
	for megaco@ietf.org; Fri, 23 Jan 2004 22:11:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AkEBN-000582-00
	for megaco@ietf.org; Fri, 23 Jan 2004 22:10:02 -0500
Received: from smtp-27.ig.com.br ([200.226.132.159])
	by ietf-mx with smtp (Exim 4.12)
	id 1AkEAb-00056F-00
	for megaco@ietf.org; Fri, 23 Jan 2004 22:09:13 -0500
Received: (qmail 2924 invoked from network); 24 Jan 2004 03:06:45 -0000
Received: from unknown (HELO tipkpfqazswj71) (200.151.172.202)
  by smtp-27.ig.com.br with SMTP; 24 Jan 2004 03:06:45 -0000
Message-ID: <000601c3e227$53d7cf40$caac97c8@tipkpfqazswj71>
From: "luka" <luka682@ig.com.br>
To: <megaco@ietf.org>
Date: Fri, 23 Jan 2004 23:55:34 -0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0008_01C3E20C.6415C8A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Subject: [Megaco] Megaco vs MGCP
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS,
	HTML_50_60,HTML_MESSAGE autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01C3E20C.6415C8A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi, All !

 I am quite new at studing Megaco/H.248 therefore I have some elementary =
questions.    =20
=20
1 - When should we use Megaco instead of MGCP ?=20

2 - Why Megaco has been developed?What was the reason to its =
development?   =20

3- I=B4d like to get information about the comparison MGCP model vs =
Megaco model .=20

Is there any interesting site or paper on Internet that I can find out =
about this.?  =20

Could you please give me a help?

Regards

Luka
------=_NextPart_000_0008_01C3E20C.6415C8A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1264" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi, All !</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;I am quite new at studing=20
Megaco/H.248&nbsp;therefore I have some&nbsp;elementary questions.=20
&nbsp;&nbsp;&nbsp;&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>1 -&nbsp;When&nbsp;should we use=20
Megaco&nbsp;instead of MGCP ?&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2 - Why&nbsp;Megaco has=20
been&nbsp;developed?What&nbsp;was the reason to&nbsp;its=20
development?&nbsp;&nbsp;&nbsp;&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>3- I=B4d like to get information about =
the comparison=20
MGCP model vs Megaco model . </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Is there any interesting site or paper =
on=20
Internet&nbsp;that I&nbsp;can find out&nbsp;about=20
this.?&nbsp;&nbsp;&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Could you please&nbsp;give me a =
help?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Luka</FONT></DIV></BODY></HTML>

------=_NextPart_000_0008_01C3E20C.6415C8A0--



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Sat Jan 24 03:18:34 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29982
	for <megaco-archive@lists.ietf.org>; Sat, 24 Jan 2004 03:18:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AkIzS-0005SV-LK; Sat, 24 Jan 2004 03:18:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AkIyg-0005Qo-2S
	for megaco@optimus.ietf.org; Sat, 24 Jan 2004 03:17:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29952
	for <megaco@ietf.org>; Sat, 24 Jan 2004 03:17:12 -0500 (EST)
From: assingh@hss.hns.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AkIyd-0000S3-00
	for megaco@ietf.org; Sat, 24 Jan 2004 03:17:12 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AkIxh-0000Q6-00
	for megaco@ietf.org; Sat, 24 Jan 2004 03:16:13 -0500
Received: from [203.200.71.140] (helo=spark.hss.co.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AkIwk-0000KM-00
	for megaco@ietf.org; Sat, 24 Jan 2004 03:15:14 -0500
Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i0O8BchT019301;
	Sat, 24 Jan 2004 13:41:39 +0530 (IST)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id i0O8D1Y05578;
	Sat, 24 Jan 2004 13:43:01 +0530 (IST)
Subject: Re: [Megaco] Megaco vs MGCP
To: "luka" <luka682@ig.com.br>
Cc: <megaco@ietf.org>
Date: Sat, 24 Jan 2004 13:37:59 +0530
Message-ID: <OFA315A430.2EF7C65F-ON65256E25.002C5CA6@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 24/01/2004
 01:33:05 PM
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=4.3 required=5.0 tests=MAILTO_TO_SPAM_ADDR,
	NO_REAL_NAME,ROUND_THE_WORLD_LOCAL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable





Hi Luka,

Have a look on White Paper "Use of MEGACO vis-=E0-vis MGCP to build a G=
ateway
Solution"
at the following link.

http://hssworld.com/whitepapers/voppapers.htm

Thanks
Ashish

Hughes Software Systems
www.hssworld.com






"luka" <luka682@ig.com.br>@ietf.org on 01/24/2004 07:25:34 AM

Sent by:    megaco-admin@ietf.org


To:    <megaco@ietf.org>
cc:

Subject:    [Megaco] Megaco vs MGCP



Hi, All !

=A0I am quite new at studing  Megaco/H.248=A0therefore I have some=A0el=
ementary
questions.

1 -=A0When=A0should we use  Megaco=A0instead of MGCP ?

2 - Why=A0Megaco has  been=A0developed?What=A0was the reason to=A0its
development?

3- I=B4d like to get information about the comparison  MGCP model vs Me=
gaco
model .

Is there any interesting site or paper on  Internet=A0that I=A0can find=

out=A0about  this.?

Could you please=A0give me a help?

Regards

Luka
=



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Sat Jan 24 03:19:50 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00034
	for <megaco-archive@odin.ietf.org>; Sat, 24 Jan 2004 03:19:50 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AkJ0i-0005aQ-Qe
	for megaco-archive@odin.ietf.org; Sat, 24 Jan 2004 03:19:21 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0O8JKrW021473
	for megaco-archive@odin.ietf.org; Sat, 24 Jan 2004 03:19:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AkJ0i-0005aD-97
	for megaco-web-archive@optimus.ietf.org; Sat, 24 Jan 2004 03:19:20 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00031
	for <megaco-web-archive@ietf.org>; Sat, 24 Jan 2004 03:19:18 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AkJ0g-0000X5-00
	for megaco-web-archive@ietf.org; Sat, 24 Jan 2004 03:19:18 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AkIzi-0000VK-00
	for megaco-web-archive@ietf.org; Sat, 24 Jan 2004 03:18:19 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AkIzU-0000TQ-00
	for megaco-web-archive@ietf.org; Sat, 24 Jan 2004 03:18:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AkIzS-0005SV-LK; Sat, 24 Jan 2004 03:18:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AkIyg-0005Qo-2S
	for megaco@optimus.ietf.org; Sat, 24 Jan 2004 03:17:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29952
	for <megaco@ietf.org>; Sat, 24 Jan 2004 03:17:12 -0500 (EST)
From: assingh@hss.hns.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AkIyd-0000S3-00
	for megaco@ietf.org; Sat, 24 Jan 2004 03:17:12 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AkIxh-0000Q6-00
	for megaco@ietf.org; Sat, 24 Jan 2004 03:16:13 -0500
Received: from [203.200.71.140] (helo=spark.hss.co.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AkIwk-0000KM-00
	for megaco@ietf.org; Sat, 24 Jan 2004 03:15:14 -0500
Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i0O8BchT019301;
	Sat, 24 Jan 2004 13:41:39 +0530 (IST)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id i0O8D1Y05578;
	Sat, 24 Jan 2004 13:43:01 +0530 (IST)
Subject: Re: [Megaco] Megaco vs MGCP
To: "luka" <luka682@ig.com.br>
Cc: <megaco@ietf.org>
Date: Sat, 24 Jan 2004 13:37:59 +0530
Message-ID: <OFA315A430.2EF7C65F-ON65256E25.002C5CA6@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 24/01/2004
 01:33:05 PM
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=4.3 required=5.0 tests=MAILTO_TO_SPAM_ADDR,
	NO_REAL_NAME,ROUND_THE_WORLD_LOCAL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable





Hi Luka,

Have a look on White Paper "Use of MEGACO vis-=E0-vis MGCP to build a G=
ateway
Solution"
at the following link.

http://hssworld.com/whitepapers/voppapers.htm

Thanks
Ashish

Hughes Software Systems
www.hssworld.com






"luka" <luka682@ig.com.br>@ietf.org on 01/24/2004 07:25:34 AM

Sent by:    megaco-admin@ietf.org


To:    <megaco@ietf.org>
cc:

Subject:    [Megaco] Megaco vs MGCP



Hi, All !

=A0I am quite new at studing  Megaco/H.248=A0therefore I have some=A0el=
ementary
questions.

1 -=A0When=A0should we use  Megaco=A0instead of MGCP ?

2 - Why=A0Megaco has  been=A0developed?What=A0was the reason to=A0its
development?

3- I=B4d like to get information about the comparison  MGCP model vs Me=
gaco
model .

Is there any interesting site or paper on  Internet=A0that I=A0can find=

out=A0about  this.?

Could you please=A0give me a help?

Regards

Luka
=



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Jan 26 04:29:32 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26023
	for <megaco-archive@lists.ietf.org>; Mon, 26 Jan 2004 04:29:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Al33F-0005KF-KS; Mon, 26 Jan 2004 04:29:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Al331-0005Jo-0o
	for megaco@optimus.ietf.org; Mon, 26 Jan 2004 04:28:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26020
	for <megaco@ietf.org>; Mon, 26 Jan 2004 04:28:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Al32y-0007J8-00
	for megaco@ietf.org; Mon, 26 Jan 2004 04:28:44 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Al321-0007Hr-00
	for megaco@ietf.org; Mon, 26 Jan 2004 04:27:45 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Al31X-0007Ft-00
	for megaco@ietf.org; Mon, 26 Jan 2004 04:27:15 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0Q9Qjg22622
	for <megaco@ietf.org>; Mon, 26 Jan 2004 04:26:45 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DNYBZJA8>; Mon, 26 Jan 2004 04:26:46 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E12CF0E@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: luka <luka682@ig.com.br>, megaco@ietf.org
Subject: RE: [Megaco] Megaco vs MGCP
Date: Mon, 26 Jan 2004 04:26:42 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR 
	autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Comments inline. [KJBII]
 
Kevin


  _____  

From: luka [mailto:luka682@ig.com.br] 
Sent: Friday, January 23, 2004 8:56 PM
To: megaco@ietf.org
Subject: [Megaco] Megaco vs MGCP


Hi, All !
 
 I am quite new at studing Megaco/H.248 therefore I have some elementary
questions.     
 
1 - When should we use Megaco instead of MGCP ? 
[KJBII] Megaco can be used anywhere that MGCP would apply.  The reverse is
not necessarily true.  Keep in mind that Megaco is the international
standard for Media Gateway control, whereas MGCP is not a standard. 
 
2 - Why Megaco has been developed?What was the reason to its development?
[KJBII] Megaco was designed to provide Media Gateway control allowing
deployment of a wide variety of multimedia services.  It was the result of
many months of international cooperation and hard work. 
 
3- I´d like to get information about the comparison MGCP model vs Megaco
model . 
[KJBII] The biggest difference between the two is the connection model.
MGCP encapsulates connection information into the endpoint.  This allows
easy set-up of one-to-one connections, but makes one-to-many or many-to-one
connections difficult or impossible.  H.248 decomposes the MGCP endpoint
into terminations, decoupling the packet-side connection from the
physical-side terminal.  This makes H.248 uniquely capable in the realm of
multimedia distribution and conferencing, while still maintaining ease of
setup for one-to-one connections.
 
Is there any interesting site or paper on Internet that I can find out about
this.?   
 
Could you please give me a help?
 
Regards
 
Luka


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Mon Jan 26 04:35:26 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26245
	for <megaco-archive@odin.ietf.org>; Mon, 26 Jan 2004 04:35:25 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Al38y-0005aj-Jh
	for megaco-archive@odin.ietf.org; Mon, 26 Jan 2004 04:34:57 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0Q9YuKi021492
	for megaco-archive@odin.ietf.org; Mon, 26 Jan 2004 04:34:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Al38y-0005aZ-3q
	for megaco-web-archive@optimus.ietf.org; Mon, 26 Jan 2004 04:34:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26173
	for <megaco-web-archive@ietf.org>; Mon, 26 Jan 2004 04:34:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Al38v-0007ZP-00
	for megaco-web-archive@ietf.org; Mon, 26 Jan 2004 04:34:53 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Al37z-0007Uo-00
	for megaco-web-archive@ietf.org; Mon, 26 Jan 2004 04:33:56 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Al37d-0007Rr-09
	for megaco-web-archive@ietf.org; Mon, 26 Jan 2004 04:33:33 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Al33F-0005KF-KS; Mon, 26 Jan 2004 04:29:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Al331-0005Jo-0o
	for megaco@optimus.ietf.org; Mon, 26 Jan 2004 04:28:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26020
	for <megaco@ietf.org>; Mon, 26 Jan 2004 04:28:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Al32y-0007J8-00
	for megaco@ietf.org; Mon, 26 Jan 2004 04:28:44 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Al321-0007Hr-00
	for megaco@ietf.org; Mon, 26 Jan 2004 04:27:45 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Al31X-0007Ft-00
	for megaco@ietf.org; Mon, 26 Jan 2004 04:27:15 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0Q9Qjg22622
	for <megaco@ietf.org>; Mon, 26 Jan 2004 04:26:45 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DNYBZJA8>; Mon, 26 Jan 2004 04:26:46 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E12CF0E@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: luka <luka682@ig.com.br>, megaco@ietf.org
Subject: RE: [Megaco] Megaco vs MGCP
Date: Mon, 26 Jan 2004 04:26:42 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR 
	autolearn=no version=2.60

Comments inline. [KJBII]
 
Kevin


  _____  

From: luka [mailto:luka682@ig.com.br] 
Sent: Friday, January 23, 2004 8:56 PM
To: megaco@ietf.org
Subject: [Megaco] Megaco vs MGCP


Hi, All !
 
 I am quite new at studing Megaco/H.248 therefore I have some elementary
questions.     
 
1 - When should we use Megaco instead of MGCP ? 
[KJBII] Megaco can be used anywhere that MGCP would apply.  The reverse is
not necessarily true.  Keep in mind that Megaco is the international
standard for Media Gateway control, whereas MGCP is not a standard. 
 
2 - Why Megaco has been developed?What was the reason to its development?
[KJBII] Megaco was designed to provide Media Gateway control allowing
deployment of a wide variety of multimedia services.  It was the result of
many months of international cooperation and hard work. 
 
3- I´d like to get information about the comparison MGCP model vs Megaco
model . 
[KJBII] The biggest difference between the two is the connection model.
MGCP encapsulates connection information into the endpoint.  This allows
easy set-up of one-to-one connections, but makes one-to-many or many-to-one
connections difficult or impossible.  H.248 decomposes the MGCP endpoint
into terminations, decoupling the packet-side connection from the
physical-side terminal.  This makes H.248 uniquely capable in the realm of
multimedia distribution and conferencing, while still maintaining ease of
setup for one-to-one connections.
 
Is there any interesting site or paper on Internet that I can find out about
this.?   
 
Could you please give me a help?
 
Regards
 
Luka


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Jan 27 15:37:33 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22656
	for <megaco-archive@lists.ietf.org>; Tue, 27 Jan 2004 15:37:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AlZxE-0001jw-Rl; Tue, 27 Jan 2004 15:37:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AlZwI-0001hq-3t
	for megaco@optimus.ietf.org; Tue, 27 Jan 2004 15:36:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22640
	for <megaco@ietf.org>; Tue, 27 Jan 2004 15:35:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AlZwG-0005Wg-00
	for megaco@ietf.org; Tue, 27 Jan 2004 15:36:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AlZvE-0005UI-00
	for megaco@ietf.org; Tue, 27 Jan 2004 15:34:57 -0500
Received: from syd-iport-1.cisco.com ([64.104.193.196])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AlZux-0005Ro-00
	for megaco@ietf.org; Tue, 27 Jan 2004 15:34:39 -0500
Received: from bej-core-1.cisco.com (64.104.160.31)
  by syd-iport-1.cisco.com with ESMTP; 27 Jan 2004 12:41:32 +0000
Received: from SAMPATHKW2K03 (dhcp-171-71-9-200.cisco.com [171.71.9.200])
	by bej-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0RKWPcc021492
	for <megaco@ietf.org>; Wed, 28 Jan 2004 04:32:26 +0800 (CST)
Reply-To: <sampathk@cisco.com>
From: "Sampath Komanduri" <sampathk@cisco.com>
To: <megaco@ietf.org>
Date: Tue, 27 Jan 2004 12:33:56 -0800
Organization: Cisco Systems
Message-ID: <001f01c3e514$e4454f40$c80947ab@SAMPATHKW2K03>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0020_01C3E4D1.D6220F40"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE 
	autolearn=no version=2.60
Subject: [Megaco] Provisioned events handling
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0020_01C3E4D1.D6220F40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi all,
Following the discussions on applicability of provisioned events, I
wanted to raised further questions on the handling of provisioned events
on MG and MGC.
 
On MG:

1.	Is it correct to assume that events as well as all the related
parameters can be provisioned on MG? Or are events should be
provisionable only with the default values (if package doesn't specify
the parameters of event to be provisionable on MG)?
2.	What should be MG's behavior, if MG specifies the same event
with same/different parameters? Does the MGC specified value take
preference? 
Properties that are configurable on MG can be overwritten by MGC,
however if the user changes this configuration, it overrides the MGC
specified value. Should the handling of provisioned events and related
parameters be same?
3.	Is MG supposed to stop playing of signals upon detection of
provisioned event on the termination? Since MGC may not be aware of the
fact that some event is provisioned on MG, handling the provisioned
event like handling of MGC requested events might impact the call-flows
(as seen and expected by MGC).
4.	How should the event buffering supposed to work with the
existence of provisioned events on a termination? The event buffer
mechanism will be impacted if MGC ignores/rejects the provisioned event
notification. Similarly, in Case event buffering is going on and
provisioned event may not be reported to MGC, as this event will not
exist in the event buffer descriptor.

 
On MGC:

1.	After AUDITing a termination, if MGC finds that there are events
on the termination that it didn't request, what is it supposed to do?
Should the future commands to MG keep the presence of these events on
termination in mind?
2.	Assuming that MGC is aware of the fact that events are
provisioned on a termination on MG: Should the MGC take the same actions
on receiving notification of provisioned events as it would have upon
notification of event for an explicit request from MGC?

Pls. respond. 
One form or the other, a final word (or section) on handling of
provisioned events in H.248 will be appreciated.
 
Thanks,
Sampath

------=_NextPart_000_0020_01C3E4D1.D6220F40
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D434450120-27012004><FONT face=3DArial size=3D2>Hi=20
all,</FONT></SPAN></DIV>
<DIV><SPAN class=3D434450120-27012004><FONT face=3DArial =
size=3D2>Following the=20
discussions on applicability of provisioned events, I wanted to raised =
further=20
questions on the handling of provisioned events on MG and=20
MGC.</FONT></SPAN></DIV>
<DIV><SPAN class=3D434450120-27012004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D434450120-27012004><FONT face=3DArial size=3D2>On=20
MG:</FONT></SPAN></DIV>
<OL>
  <LI><SPAN class=3D434450120-27012004><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
  face=3DArial>Is it correct to assume that events as well as all the =
related=20
  parameters can be provisioned on MG? Or are events should be =
provisionable=20
  only with the default values (if package doesn't specify the =
parameters of=20
  event to be provisionable on MG)?</FONT></SPAN></SPAN></LI>
  <LI><SPAN class=3D434450120-27012004><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
  face=3DArial>What&nbsp;should be MG's behavior, if MG specifies the =
same event=20
  with same/different parameters?&nbsp;Does the MGC specified value take =

  preference? <BR></FONT></SPAN></SPAN><SPAN =
class=3D434450120-27012004><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
  face=3DArial>Properties that are configurable on MG can be overwritten =
by MGC,=20
  however if the user changes this configuration, it overrides the MGC =
specified=20
  value. Should the handling of provisioned events and related =
parameters be=20
  same?</FONT></SPAN></SPAN></LI>
  <LI><SPAN class=3D434450120-27012004><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
  face=3DArial>Is MG supposed to stop playing of signals upon detection =
of=20
  provisioned event on the termination? Since MGC may not be aware of =
the fact=20
  that some event is provisioned on MG, handling the provisioned event =
like=20
  handling of MGC requested events might impact the call-flows (as seen =
and=20
  expected by MGC).</FONT></SPAN></SPAN></LI>
  <LI><SPAN class=3D434450120-27012004><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
  face=3DArial>How should the event buffering supposed to work with the =
existence=20
  of provisioned events on a termination? The event buffer mechanism =
will be=20
  impacted if MGC ignores/rejects the provisioned event notification. =
Similarly,=20
  i</FONT></SPAN></SPAN><SPAN class=3D434450120-27012004><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial>n Case=20
  event buffering is going on and provisioned event may not be reported =
to MGC,=20
  as this event will not exist in the event buffer=20
  descriptor.</FONT></SPAN></SPAN></SPAN></LI></OL>
<DIV><SPAN class=3D434450120-27012004><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT=20
face=3DArial></FONT></SPAN></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D434450120-27012004><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial>On=20
MGC:</FONT></SPAN></SPAN></SPAN></DIV>
<OL>
  <LI><SPAN class=3D434450120-27012004><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
  face=3DArial>After AUDITing a termination, if MGC finds that there are =
events on=20
  the termination that it didn't request, what is it supposed to do? =
Should the=20
  future commands to MG keep the presence of these events on termination =
in=20
  mind?</FONT></SPAN></SPAN></LI>
  <LI><SPAN class=3D434450120-27012004><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
  face=3DArial>Assuming that MGC is aware of the fact that events are =
provisioned=20
  on a termination on MG: Should the MGC take the same actions on =
receiving=20
  notification of provisioned events as it would have upon notification =
of event=20
  for an explicit request from MGC?</FONT></SPAN></SPAN></LI></OL>
<DIV><SPAN class=3D434450120-27012004><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: =
AR-SA"></SPAN></SPAN><SPAN=20
class=3D434450120-27012004><FONT face=3DArial size=3D2>Pls. respond.=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D434450120-27012004><FONT face=3DArial size=3D2>One =
form or the=20
other, a final word (or section) on handling of provisioned events in =
H.248 will=20
be appreciated.</FONT></SPAN></DIV>
<DIV><SPAN class=3D434450120-27012004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D434450120-27012004><FONT face=3DArial=20
size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D434450120-27012004><FONT face=3DArial=20
size=3D2>Sampath</FONT></SPAN></DIV></BODY></HTML>

------=_NextPart_000_0020_01C3E4D1.D6220F40--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Tue Jan 27 15:39:24 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22681
	for <megaco-archive@odin.ietf.org>; Tue, 27 Jan 2004 15:39:24 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AlZz6-000294-Ci
	for megaco-archive@odin.ietf.org; Tue, 27 Jan 2004 15:38:56 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RKcuCW008240
	for megaco-archive@odin.ietf.org; Tue, 27 Jan 2004 15:38:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AlZz6-00028p-6L
	for megaco-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 15:38:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22678
	for <megaco-web-archive@ietf.org>; Tue, 27 Jan 2004 15:38:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AlZz4-0005e0-00
	for megaco-web-archive@ietf.org; Tue, 27 Jan 2004 15:38:54 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AlZy8-0005bv-00
	for megaco-web-archive@ietf.org; Tue, 27 Jan 2004 15:37:57 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AlZxI-0005ZR-00
	for megaco-web-archive@ietf.org; Tue, 27 Jan 2004 15:37:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AlZxE-0001jw-Rl; Tue, 27 Jan 2004 15:37:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AlZwI-0001hq-3t
	for megaco@optimus.ietf.org; Tue, 27 Jan 2004 15:36:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22640
	for <megaco@ietf.org>; Tue, 27 Jan 2004 15:35:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AlZwG-0005Wg-00
	for megaco@ietf.org; Tue, 27 Jan 2004 15:36:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AlZvE-0005UI-00
	for megaco@ietf.org; Tue, 27 Jan 2004 15:34:57 -0500
Received: from syd-iport-1.cisco.com ([64.104.193.196])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AlZux-0005Ro-00
	for megaco@ietf.org; Tue, 27 Jan 2004 15:34:39 -0500
Received: from bej-core-1.cisco.com (64.104.160.31)
  by syd-iport-1.cisco.com with ESMTP; 27 Jan 2004 12:41:32 +0000
Received: from SAMPATHKW2K03 (dhcp-171-71-9-200.cisco.com [171.71.9.200])
	by bej-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0RKWPcc021492
	for <megaco@ietf.org>; Wed, 28 Jan 2004 04:32:26 +0800 (CST)
Reply-To: <sampathk@cisco.com>
From: "Sampath Komanduri" <sampathk@cisco.com>
To: <megaco@ietf.org>
Date: Tue, 27 Jan 2004 12:33:56 -0800
Organization: Cisco Systems
Message-ID: <001f01c3e514$e4454f40$c80947ab@SAMPATHKW2K03>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0020_01C3E4D1.D6220F40"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Subject: [Megaco] Provisioned events handling
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE 
	autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_0020_01C3E4D1.D6220F40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi all,
Following the discussions on applicability of provisioned events, I
wanted to raised further questions on the handling of provisioned events
on MG and MGC.
 
On MG:

1.	Is it correct to assume that events as well as all the related
parameters can be provisioned on MG? Or are events should be
provisionable only with the default values (if package doesn't specify
the parameters of event to be provisionable on MG)?
2.	What should be MG's behavior, if MG specifies the same event
with same/different parameters? Does the MGC specified value take
preference? 
Properties that are configurable on MG can be overwritten by MGC,
however if the user changes this configuration, it overrides the MGC
specified value. Should the handling of provisioned events and related
parameters be same?
3.	Is MG supposed to stop playing of signals upon detection of
provisioned event on the termination? Since MGC may not be aware of the
fact that some event is provisioned on MG, handling the provisioned
event like handling of MGC requested events might impact the call-flows
(as seen and expected by MGC).
4.	How should the event buffering supposed to work with the
existence of provisioned events on a termination? The event buffer
mechanism will be impacted if MGC ignores/rejects the provisioned event
notification. Similarly, in Case event buffering is going on and
provisioned event may not be reported to MGC, as this event will not
exist in the event buffer descriptor.

 
On MGC:

1.	After AUDITing a termination, if MGC finds that there are events
on the termination that it didn't request, what is it supposed to do?
Should the future commands to MG keep the presence of these events on
termination in mind?
2.	Assuming that MGC is aware of the fact that events are
provisioned on a termination on MG: Should the MGC take the same actions
on receiving notification of provisioned events as it would have upon
notification of event for an explicit request from MGC?

Pls. respond. 
One form or the other, a final word (or section) on handling of
provisioned events in H.248 will be appreciated.
 
Thanks,
Sampath

------=_NextPart_000_0020_01C3E4D1.D6220F40
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D434450120-27012004><FONT face=3DArial size=3D2>Hi=20
all,</FONT></SPAN></DIV>
<DIV><SPAN class=3D434450120-27012004><FONT face=3DArial =
size=3D2>Following the=20
discussions on applicability of provisioned events, I wanted to raised =
further=20
questions on the handling of provisioned events on MG and=20
MGC.</FONT></SPAN></DIV>
<DIV><SPAN class=3D434450120-27012004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D434450120-27012004><FONT face=3DArial size=3D2>On=20
MG:</FONT></SPAN></DIV>
<OL>
  <LI><SPAN class=3D434450120-27012004><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
  face=3DArial>Is it correct to assume that events as well as all the =
related=20
  parameters can be provisioned on MG? Or are events should be =
provisionable=20
  only with the default values (if package doesn't specify the =
parameters of=20
  event to be provisionable on MG)?</FONT></SPAN></SPAN></LI>
  <LI><SPAN class=3D434450120-27012004><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
  face=3DArial>What&nbsp;should be MG's behavior, if MG specifies the =
same event=20
  with same/different parameters?&nbsp;Does the MGC specified value take =

  preference? <BR></FONT></SPAN></SPAN><SPAN =
class=3D434450120-27012004><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
  face=3DArial>Properties that are configurable on MG can be overwritten =
by MGC,=20
  however if the user changes this configuration, it overrides the MGC =
specified=20
  value. Should the handling of provisioned events and related =
parameters be=20
  same?</FONT></SPAN></SPAN></LI>
  <LI><SPAN class=3D434450120-27012004><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
  face=3DArial>Is MG supposed to stop playing of signals upon detection =
of=20
  provisioned event on the termination? Since MGC may not be aware of =
the fact=20
  that some event is provisioned on MG, handling the provisioned event =
like=20
  handling of MGC requested events might impact the call-flows (as seen =
and=20
  expected by MGC).</FONT></SPAN></SPAN></LI>
  <LI><SPAN class=3D434450120-27012004><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
  face=3DArial>How should the event buffering supposed to work with the =
existence=20
  of provisioned events on a termination? The event buffer mechanism =
will be=20
  impacted if MGC ignores/rejects the provisioned event notification. =
Similarly,=20
  i</FONT></SPAN></SPAN><SPAN class=3D434450120-27012004><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial>n Case=20
  event buffering is going on and provisioned event may not be reported =
to MGC,=20
  as this event will not exist in the event buffer=20
  descriptor.</FONT></SPAN></SPAN></SPAN></LI></OL>
<DIV><SPAN class=3D434450120-27012004><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT=20
face=3DArial></FONT></SPAN></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D434450120-27012004><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial>On=20
MGC:</FONT></SPAN></SPAN></SPAN></DIV>
<OL>
  <LI><SPAN class=3D434450120-27012004><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
  face=3DArial>After AUDITing a termination, if MGC finds that there are =
events on=20
  the termination that it didn't request, what is it supposed to do? =
Should the=20
  future commands to MG keep the presence of these events on termination =
in=20
  mind?</FONT></SPAN></SPAN></LI>
  <LI><SPAN class=3D434450120-27012004><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
  face=3DArial>Assuming that MGC is aware of the fact that events are =
provisioned=20
  on a termination on MG: Should the MGC take the same actions on =
receiving=20
  notification of provisioned events as it would have upon notification =
of event=20
  for an explicit request from MGC?</FONT></SPAN></SPAN></LI></OL>
<DIV><SPAN class=3D434450120-27012004><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: =
AR-SA"></SPAN></SPAN><SPAN=20
class=3D434450120-27012004><FONT face=3DArial size=3D2>Pls. respond.=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D434450120-27012004><FONT face=3DArial size=3D2>One =
form or the=20
other, a final word (or section) on handling of provisioned events in =
H.248 will=20
be appreciated.</FONT></SPAN></DIV>
<DIV><SPAN class=3D434450120-27012004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D434450120-27012004><FONT face=3DArial=20
size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D434450120-27012004><FONT face=3DArial=20
size=3D2>Sampath</FONT></SPAN></DIV></BODY></HTML>

------=_NextPart_000_0020_01C3E4D1.D6220F40--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Jan 27 18:57:55 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01082
	for <megaco-archive@lists.ietf.org>; Tue, 27 Jan 2004 18:57:55 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ald5A-0005ND-NI; Tue, 27 Jan 2004 18:57:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Al8pL-00071L-5D
	for megaco@optimus.ietf.org; Mon, 26 Jan 2004 10:39:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09894
	for <megaco@ietf.org>; Mon, 26 Jan 2004 10:38:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Al8pI-0003VF-00
	for megaco@ietf.org; Mon, 26 Jan 2004 10:39:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Al8oN-0003TJ-00
	for megaco@ietf.org; Mon, 26 Jan 2004 10:38:04 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Al8nW-0003Ol-00
	for megaco@ietf.org; Mon, 26 Jan 2004 10:37:10 -0500
Received: from cisco.com (sjc-vpn2-663.cisco.com [10.21.114.151])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0QFaa5k018841;
	Mon, 26 Jan 2004 07:36:36 -0800 (PST)
Message-ID: <40153403.126315A7@cisco.com>
Date: Mon, 26 Jan 2004 10:36:35 -0500
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kevin Boyle <kboyle@nortelnetworks.com>
CC: luka <luka682@ig.com.br>, megaco@ietf.org
Subject: Re: [Megaco] Megaco vs MGCP
References: <ABA227A15B80D511BD1A00508BF93A1C0E12CF0E@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=iso-8859-1
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR 
	autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA09895
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable



Kevin Boyle wrote:

> Comments inline. [KJBII]
>
> Kevin
>
>   _____
>
> From: luka [mailto:luka682@ig.com.br]
> Sent: Friday, January 23, 2004 8:56 PM
> To: megaco@ietf.org
> Subject: [Megaco] Megaco vs MGCP
>
> Hi, All !
>
>  I am quite new at studing Megaco/H.248 therefore I have some elementar=
y
> questions.
>
> 1 - When should we use Megaco instead of MGCP ?
> [KJBII] Megaco can be used anywhere that MGCP would apply.  The reverse=
 is
> not necessarily true.

Well, actually it is (I have yet to hear about an application that could =
be
supported by Megaco, but not MGCP), but starting that debate again is pro=
bably
neither fruitful, nor appropriate for this reflector.

> Keep in mind that Megaco is the international
> standard for Media Gateway control, whereas MGCP is not a standard.

However, keep in mind, that MGCP is the de facto industry standard. Also,=
 the
NCS and TGCP profiles of MGCP are mandated by PacketCable and hence are n=
eeded
in the cable industry. Also both NCS and TGCP are full-blown ANSI and ITU=
-T
standards (J.162 and J.171).


>
> 2 - Why Megaco has been developed?What was the reason to its developmen=
t?
> [KJBII] Megaco was designed to provide Media Gateway control allowing
> deployment of a wide variety of multimedia services.  It was the result=
 of
> many months of international cooperation and hard work.
>
> 3- I=B4d like to get information about the comparison MGCP model vs Meg=
aco
> model .
> [KJBII] The biggest difference between the two is the connection model.
> MGCP encapsulates connection information into the endpoint.  This allow=
s
> easy set-up of one-to-one connections, but makes one-to-many or many-to=
-one
> connections difficult or impossible.

On the contrary. A single endpoint easily supports multiple connections a=
nd
hence it is done very easily in MGCP (some would even argue easier than i=
n
Megaco).

This is however a pointless discussion. Bottom line is what MGCP and Mega=
co are
two different solutions to the same problem. Some people prefer Megaco, s=
ome
prefer MGCP. They each have their pros and cons, but in the end, they can=
 both
solve the same set of problems.

-- Flemming




_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Tue Jan 27 19:18:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03616
	for <megaco-archive@odin.ietf.org>; Tue, 27 Jan 2004 19:18:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AldP7-0004d8-TY
	for megaco-archive@odin.ietf.org; Tue, 27 Jan 2004 19:18:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0I1Ah017785
	for megaco-archive@odin.ietf.org; Tue, 27 Jan 2004 19:18:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AldP7-0004cg-KA
	for megaco-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:18:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03484
	for <megaco-web-archive@ietf.org>; Tue, 27 Jan 2004 19:17:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AldP6-00074B-00
	for megaco-web-archive@ietf.org; Tue, 27 Jan 2004 19:18:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AldMv-0006YQ-00
	for megaco-web-archive@ietf.org; Tue, 27 Jan 2004 19:15:46 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AldKb-0005tK-00
	for megaco-web-archive@ietf.org; Tue, 27 Jan 2004 19:13:21 -0500
Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org)
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1Ald5M-000480-3x
	for megaco-web-archive@ietf.org; Tue, 27 Jan 2004 18:57:37 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ald5A-0005ND-NI; Tue, 27 Jan 2004 18:57:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Al8pL-00071L-5D
	for megaco@optimus.ietf.org; Mon, 26 Jan 2004 10:39:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09894
	for <megaco@ietf.org>; Mon, 26 Jan 2004 10:38:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Al8pI-0003VF-00
	for megaco@ietf.org; Mon, 26 Jan 2004 10:39:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Al8oN-0003TJ-00
	for megaco@ietf.org; Mon, 26 Jan 2004 10:38:04 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Al8nW-0003Ol-00
	for megaco@ietf.org; Mon, 26 Jan 2004 10:37:10 -0500
Received: from cisco.com (sjc-vpn2-663.cisco.com [10.21.114.151])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0QFaa5k018841;
	Mon, 26 Jan 2004 07:36:36 -0800 (PST)
Message-ID: <40153403.126315A7@cisco.com>
Date: Mon, 26 Jan 2004 10:36:35 -0500
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kevin Boyle <kboyle@nortelnetworks.com>
CC: luka <luka682@ig.com.br>, megaco@ietf.org
Subject: Re: [Megaco] Megaco vs MGCP
References: <ABA227A15B80D511BD1A00508BF93A1C0E12CF0E@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA09895
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR 
	autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable



Kevin Boyle wrote:

> Comments inline. [KJBII]
>
> Kevin
>
>   _____
>
> From: luka [mailto:luka682@ig.com.br]
> Sent: Friday, January 23, 2004 8:56 PM
> To: megaco@ietf.org
> Subject: [Megaco] Megaco vs MGCP
>
> Hi, All !
>
>  I am quite new at studing Megaco/H.248 therefore I have some elementar=
y
> questions.
>
> 1 - When should we use Megaco instead of MGCP ?
> [KJBII] Megaco can be used anywhere that MGCP would apply.  The reverse=
 is
> not necessarily true.

Well, actually it is (I have yet to hear about an application that could =
be
supported by Megaco, but not MGCP), but starting that debate again is pro=
bably
neither fruitful, nor appropriate for this reflector.

> Keep in mind that Megaco is the international
> standard for Media Gateway control, whereas MGCP is not a standard.

However, keep in mind, that MGCP is the de facto industry standard. Also,=
 the
NCS and TGCP profiles of MGCP are mandated by PacketCable and hence are n=
eeded
in the cable industry. Also both NCS and TGCP are full-blown ANSI and ITU=
-T
standards (J.162 and J.171).


>
> 2 - Why Megaco has been developed?What was the reason to its developmen=
t?
> [KJBII] Megaco was designed to provide Media Gateway control allowing
> deployment of a wide variety of multimedia services.  It was the result=
 of
> many months of international cooperation and hard work.
>
> 3- I=B4d like to get information about the comparison MGCP model vs Meg=
aco
> model .
> [KJBII] The biggest difference between the two is the connection model.
> MGCP encapsulates connection information into the endpoint.  This allow=
s
> easy set-up of one-to-one connections, but makes one-to-many or many-to=
-one
> connections difficult or impossible.

On the contrary. A single endpoint easily supports multiple connections a=
nd
hence it is done very easily in MGCP (some would even argue easier than i=
n
Megaco).

This is however a pointless discussion. Bottom line is what MGCP and Mega=
co are
two different solutions to the same problem. Some people prefer Megaco, s=
ome
prefer MGCP. They each have their pros and cons, but in the end, they can=
 both
solve the same set of problems.

-- Flemming




_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan 28 05:39:31 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24333
	for <megaco-archive@lists.ietf.org>; Wed, 28 Jan 2004 05:39:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aln65-0002Iy-9P; Wed, 28 Jan 2004 05:39:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AldmY-0007ls-0H
	for megaco@optimus.ietf.org; Tue, 27 Jan 2004 19:42:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06434
	for <megaco@ietf.org>; Tue, 27 Jan 2004 19:42:10 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AldmW-0003EP-00
	for megaco@ietf.org; Tue, 27 Jan 2004 19:42:12 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aldlh-0003Ak-00
	for megaco@ietf.org; Tue, 27 Jan 2004 19:41:21 -0500
Received: from main.gmane.org ([80.91.224.249])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aldl5-00035l-00
	for megaco@ietf.org; Tue, 27 Jan 2004 19:40:43 -0500
Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1Aldl5-0005he-00
	for <megaco@ietf.org>; Wed, 28 Jan 2004 01:40:43 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: megaco@ietf.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 1Alded-0005eE-00
	for <gmane-ietf-megaco@m.gmane.org>; Wed, 28 Jan 2004 01:34:03 +0100
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1Alded-0002US-00
	for <gmane-ietf-megaco@m.gmane.org>; Wed, 28 Jan 2004 01:34:03 +0100
From: Samuel Tardieu <sam@rfc1149.net>
Date: Wed, 28 Jan 2004 01:33:19 +0100
Organization: Avian Carrier & Friends
Lines: 15
Message-ID: <87r7xknc8g.fsf@beeblebrox.enst.fr>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Complaints-To: usenet@sea.gmane.org
User-Agent: T-gnus/6.16.2 (based on Gnus v5.10.2) (revision 02) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI)
Cancel-Lock: sha1:wLIXg2Bv0O8XWBBFkBfA4236ulo=
X-Leafnode-NNTP-Posting-Host: 3ffe:304:103:111:200:39ff:fe25:3aa2
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Subject: [Megaco] Megaco, caller id and VoIP
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hi.

I am discovering Megaco and I have a few (probably trivial)
questions:

  - in a VoIP only application, is it possible to use a textual string
    instead of digits to designate the recipient?

  - at what time will the caller id and the callee id be presented to
    the callee (e.g., to let a MG which acts as a gateway to another
    system present the callee phone number to the external system)

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan 28 05:40:54 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24367
	for <megaco-archive@odin.ietf.org>; Wed, 28 Jan 2004 05:40:54 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aln7T-0002TQ-Hs
	for megaco-archive@odin.ietf.org; Wed, 28 Jan 2004 05:40:28 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SAeRYf009502
	for megaco-archive@odin.ietf.org; Wed, 28 Jan 2004 05:40:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aln7T-0002TB-Al
	for megaco-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 05:40:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24353
	for <megaco-web-archive@ietf.org>; Wed, 28 Jan 2004 05:40:23 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aln7P-0002gE-00
	for megaco-web-archive@ietf.org; Wed, 28 Jan 2004 05:40:23 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aln6Y-0002c4-00
	for megaco-web-archive@ietf.org; Wed, 28 Jan 2004 05:39:31 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aln65-0002Xk-00
	for megaco-web-archive@ietf.org; Wed, 28 Jan 2004 05:39:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aln65-0002Iy-9P; Wed, 28 Jan 2004 05:39:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AldmY-0007ls-0H
	for megaco@optimus.ietf.org; Tue, 27 Jan 2004 19:42:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06434
	for <megaco@ietf.org>; Tue, 27 Jan 2004 19:42:10 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AldmW-0003EP-00
	for megaco@ietf.org; Tue, 27 Jan 2004 19:42:12 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aldlh-0003Ak-00
	for megaco@ietf.org; Tue, 27 Jan 2004 19:41:21 -0500
Received: from main.gmane.org ([80.91.224.249])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aldl5-00035l-00
	for megaco@ietf.org; Tue, 27 Jan 2004 19:40:43 -0500
Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1Aldl5-0005he-00
	for <megaco@ietf.org>; Wed, 28 Jan 2004 01:40:43 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: megaco@ietf.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 1Alded-0005eE-00
	for <gmane-ietf-megaco@m.gmane.org>; Wed, 28 Jan 2004 01:34:03 +0100
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1Alded-0002US-00
	for <gmane-ietf-megaco@m.gmane.org>; Wed, 28 Jan 2004 01:34:03 +0100
From: Samuel Tardieu <sam@rfc1149.net>
Date: Wed, 28 Jan 2004 01:33:19 +0100
Organization: Avian Carrier & Friends
Lines: 15
Message-ID: <87r7xknc8g.fsf@beeblebrox.enst.fr>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Complaints-To: usenet@sea.gmane.org
User-Agent: T-gnus/6.16.2 (based on Gnus v5.10.2) (revision 02) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI)
Cancel-Lock: sha1:wLIXg2Bv0O8XWBBFkBfA4236ulo=
X-Leafnode-NNTP-Posting-Host: 3ffe:304:103:111:200:39ff:fe25:3aa2
Subject: [Megaco] Megaco, caller id and VoIP
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

Hi.

I am discovering Megaco and I have a few (probably trivial)
questions:

  - in a VoIP only application, is it possible to use a textual string
    instead of digits to designate the recipient?

  - at what time will the caller id and the callee id be presented to
    the callee (e.g., to let a MG which acts as a gateway to another
    system present the callee phone number to the external system)

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan 28 14:49:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23202
	for <megaco-archive@lists.ietf.org>; Wed, 28 Jan 2004 14:49:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AlvgL-0002XF-AI; Wed, 28 Jan 2004 14:49:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Alvg3-0002Wr-1Q
	for megaco@optimus.ietf.org; Wed, 28 Jan 2004 14:48:43 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23182
	for <megaco@ietf.org>; Wed, 28 Jan 2004 14:48:39 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Alvg0-0002b4-00
	for megaco@ietf.org; Wed, 28 Jan 2004 14:48:40 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Alvf4-0002Vc-00
	for megaco@ietf.org; Wed, 28 Jan 2004 14:47:42 -0500
Received: from [65.198.40.5] (helo=mails.conexion.com.py)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AlveA-0002Ks-00
	for megaco@ietf.org; Wed, 28 Jan 2004 14:46:46 -0500
Received: from carlos ([65.198.40.11])
	by mails.conexion.com.py (8.12.8/8.12.8) with SMTP id i0SJnTK1002933
	for <megaco@ietf.org>; Wed, 28 Jan 2004 16:49:29 -0300
Message-ID: <001201c3e5b7$643f1ee0$6600a8c0@carlos>
From: =?iso-8859-1?Q?Carlos_Rodr=EDguez_Alcal=E1_Villagra?= <crav@conexion.com.py>
To: <megaco@ietf.org>
Date: Wed, 28 Jan 2004 16:57:11 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000F_01C3E5BF.C5DAF040"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300
X-ConeXion-MailScanner-Information: Please contact the ISP for more information
X-ConeXion-MailScanner: Found to be clean
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,DATE_IN_PAST_03_06,
	HTML_40_50,HTML_MESSAGE autolearn=no version=2.60
Subject: [Megaco] busy tone
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C3E5BF.C5DAF040
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Where I can find some examples of analog-call-flow when G2 is busy??
thanks
In another words if I have two gateway GW1 and GW2 and one line of GW1 =
want to comunicate with a line in GW2 and this line is busy in that =
moment???


------=_NextPart_000_000F_01C3E5BF.C5DAF040
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2734.1600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Where I can find some examples of =
analog-call-flow=20
when G2 is busy??</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>In another words if I have two gateway =
GW1 and GW2=20
and one line of GW1 want to comunicate with a line in GW2 and this line =
is busy=20
in that moment???</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_000F_01C3E5BF.C5DAF040--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan 28 14:51:18 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23320
	for <megaco-archive@odin.ietf.org>; Wed, 28 Jan 2004 14:51:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Alvi4-0002hk-8I
	for megaco-archive@odin.ietf.org; Wed, 28 Jan 2004 14:50:51 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SJompq010392
	for megaco-archive@odin.ietf.org; Wed, 28 Jan 2004 14:50:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Alvi4-0002hX-3Z
	for megaco-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 14:50:48 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23310
	for <megaco-web-archive@ietf.org>; Wed, 28 Jan 2004 14:50:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Alvi1-0002pK-00
	for megaco-web-archive@ietf.org; Wed, 28 Jan 2004 14:50:45 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Alvh8-0002j8-00
	for megaco-web-archive@ietf.org; Wed, 28 Jan 2004 14:49:51 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AlvgK-0002de-00
	for megaco-web-archive@ietf.org; Wed, 28 Jan 2004 14:49:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AlvgL-0002XF-AI; Wed, 28 Jan 2004 14:49:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Alvg3-0002Wr-1Q
	for megaco@optimus.ietf.org; Wed, 28 Jan 2004 14:48:43 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23182
	for <megaco@ietf.org>; Wed, 28 Jan 2004 14:48:39 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Alvg0-0002b4-00
	for megaco@ietf.org; Wed, 28 Jan 2004 14:48:40 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Alvf4-0002Vc-00
	for megaco@ietf.org; Wed, 28 Jan 2004 14:47:42 -0500
Received: from [65.198.40.5] (helo=mails.conexion.com.py)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AlveA-0002Ks-00
	for megaco@ietf.org; Wed, 28 Jan 2004 14:46:46 -0500
Received: from carlos ([65.198.40.11])
	by mails.conexion.com.py (8.12.8/8.12.8) with SMTP id i0SJnTK1002933
	for <megaco@ietf.org>; Wed, 28 Jan 2004 16:49:29 -0300
Message-ID: <001201c3e5b7$643f1ee0$6600a8c0@carlos>
From: =?iso-8859-1?Q?Carlos_Rodr=EDguez_Alcal=E1_Villagra?= <crav@conexion.com.py>
To: <megaco@ietf.org>
Date: Wed, 28 Jan 2004 16:57:11 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000F_01C3E5BF.C5DAF040"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300
X-ConeXion-MailScanner-Information: Please contact the ISP for more information
X-ConeXion-MailScanner: Found to be clean
Subject: [Megaco] busy tone
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,DATE_IN_PAST_03_06,
	HTML_30_40,HTML_MESSAGE autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C3E5BF.C5DAF040
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Where I can find some examples of analog-call-flow when G2 is busy??
thanks
In another words if I have two gateway GW1 and GW2 and one line of GW1 =
want to comunicate with a line in GW2 and this line is busy in that =
moment???


------=_NextPart_000_000F_01C3E5BF.C5DAF040
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2734.1600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Where I can find some examples of =
analog-call-flow=20
when G2 is busy??</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>In another words if I have two gateway =
GW1 and GW2=20
and one line of GW1 want to comunicate with a line in GW2 and this line =
is busy=20
in that moment???</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_000F_01C3E5BF.C5DAF040--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan 28 19:40:32 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09535
	for <megaco-archive@lists.ietf.org>; Wed, 28 Jan 2004 19:40:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am0E0-0006RQ-5s; Wed, 28 Jan 2004 19:40:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am0Do-0006QH-0b
	for megaco@optimus.ietf.org; Wed, 28 Jan 2004 19:39:52 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09517
	for <megaco@ietf.org>; Wed, 28 Jan 2004 19:39:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am0Dm-0002ga-00
	for megaco@ietf.org; Wed, 28 Jan 2004 19:39:50 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Am0Cs-0002bT-00
	for megaco@ietf.org; Wed, 28 Jan 2004 19:38:54 -0500
Received: from main.gmane.org ([80.91.224.249])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am0C0-0002Va-00
	for megaco@ietf.org; Wed, 28 Jan 2004 19:38:00 -0500
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1Am0Bv-00049z-00
	for <megaco@ietf.org>; Thu, 29 Jan 2004 01:37:55 +0100
Received: from willow.rfc1149.net ([81.56.47.149])
        by news.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <megaco@ietf.org>; Thu Jan 29 00:37:55 2004
X-Injected-Via-Gmane: http://gmane.org/
To: megaco@ietf.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 1Am0Bt-00049r-00
	for <gmane-ietf-megaco@m.gmane.org>; Thu, 29 Jan 2004 01:37:53 +0100
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1Am0Bt-0000C8-00
	for <gmane-ietf-megaco@m.gmane.org>; Thu, 29 Jan 2004 01:37:53 +0100
From: Samuel Tardieu <sam@rfc1149.net>
Date: Thu, 29 Jan 2004 01:37:50 +0100
Organization: Avian Carrier & Friends
Lines: 19
Message-ID: <874qufy4gx.fsf@beeblebrox.enst.fr>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Complaints-To: usenet@sea.gmane.org
Gmane-NNTP-Posting-Host: willow.rfc1149.net
User-Agent: T-gnus/6.16.2 (based on Gnus v5.10.2) (revision 02) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI)
Cancel-Lock: sha1:2jBkA7oyYz4Qd932zUcZUsHYgkU=
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Subject: [Megaco] Mandatory serviceChangeReason parameter?
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

In the ASN.1 description of RFC3525, I understand that the
serviceChangeReason parameter is mandatory:

      serviceChangeReason     Value,
   -- A serviceChangeReason consists of a numeric reason code
   -- and an optional text description.

However, in appendix I, the example does not mention one:

   ServiceChange = ROOT {Services {
       Method=Restart,
       ServiceChangeAddress=55555, Profile=ResGW/1}
   }

Is there an error in the example?

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan 28 19:42:19 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09593
	for <megaco-archive@odin.ietf.org>; Wed, 28 Jan 2004 19:42:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am0Fk-0006k4-8o
	for megaco-archive@odin.ietf.org; Wed, 28 Jan 2004 19:41:52 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0T0fqGG025910
	for megaco-archive@odin.ietf.org; Wed, 28 Jan 2004 19:41:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am0Fk-0006jp-5O
	for megaco-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 19:41:52 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09581
	for <megaco-web-archive@ietf.org>; Wed, 28 Jan 2004 19:41:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am0Fi-0002rb-00
	for megaco-web-archive@ietf.org; Wed, 28 Jan 2004 19:41:50 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Am0El-0002mG-00
	for megaco-web-archive@ietf.org; Wed, 28 Jan 2004 19:40:52 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am0E0-0002hR-00
	for megaco-web-archive@ietf.org; Wed, 28 Jan 2004 19:40:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am0E0-0006RQ-5s; Wed, 28 Jan 2004 19:40:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am0Do-0006QH-0b
	for megaco@optimus.ietf.org; Wed, 28 Jan 2004 19:39:52 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09517
	for <megaco@ietf.org>; Wed, 28 Jan 2004 19:39:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am0Dm-0002ga-00
	for megaco@ietf.org; Wed, 28 Jan 2004 19:39:50 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Am0Cs-0002bT-00
	for megaco@ietf.org; Wed, 28 Jan 2004 19:38:54 -0500
Received: from main.gmane.org ([80.91.224.249])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am0C0-0002Va-00
	for megaco@ietf.org; Wed, 28 Jan 2004 19:38:00 -0500
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1Am0Bv-00049z-00
	for <megaco@ietf.org>; Thu, 29 Jan 2004 01:37:55 +0100
Received: from willow.rfc1149.net ([81.56.47.149])
        by news.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <megaco@ietf.org>; Thu Jan 29 00:37:55 2004
X-Injected-Via-Gmane: http://gmane.org/
To: megaco@ietf.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 1Am0Bt-00049r-00
	for <gmane-ietf-megaco@m.gmane.org>; Thu, 29 Jan 2004 01:37:53 +0100
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1Am0Bt-0000C8-00
	for <gmane-ietf-megaco@m.gmane.org>; Thu, 29 Jan 2004 01:37:53 +0100
From: Samuel Tardieu <sam@rfc1149.net>
Date: Thu, 29 Jan 2004 01:37:50 +0100
Organization: Avian Carrier & Friends
Lines: 19
Message-ID: <874qufy4gx.fsf@beeblebrox.enst.fr>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Complaints-To: usenet@sea.gmane.org
Gmane-NNTP-Posting-Host: willow.rfc1149.net
User-Agent: T-gnus/6.16.2 (based on Gnus v5.10.2) (revision 02) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI)
Cancel-Lock: sha1:2jBkA7oyYz4Qd932zUcZUsHYgkU=
Subject: [Megaco] Mandatory serviceChangeReason parameter?
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

In the ASN.1 description of RFC3525, I understand that the
serviceChangeReason parameter is mandatory:

      serviceChangeReason     Value,
   -- A serviceChangeReason consists of a numeric reason code
   -- and an optional text description.

However, in appendix I, the example does not mention one:

   ServiceChange = ROOT {Services {
       Method=Restart,
       ServiceChangeAddress=55555, Profile=ResGW/1}
   }

Is there an error in the example?

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Jan 28 23:19:31 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17680
	for <megaco-archive@lists.ietf.org>; Wed, 28 Jan 2004 23:19:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am3du-00085w-CY; Wed, 28 Jan 2004 23:19:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am3d0-0007uW-QO
	for megaco@optimus.ietf.org; Wed, 28 Jan 2004 23:18:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17621
	for <megaco@ietf.org>; Wed, 28 Jan 2004 23:18:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am3cy-0001Tl-00
	for megaco@ietf.org; Wed, 28 Jan 2004 23:18:05 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Am3cR-0001MK-00
	for megaco@ietf.org; Wed, 28 Jan 2004 23:17:31 -0500
Received: from sym.gdsz.cncnet.net ([210.21.224.29] helo=szsmtp.utstar.com.cn)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am3bL-0000yc-00
	for megaco@ietf.org; Wed, 28 Jan 2004 23:16:23 -0500
Received: from sznssrasool ([172.19.17.174])
	by szsmtp.utstar.com.cn (8.11.6/8.11.1) with SMTP id i0T3rab07122;
	Thu, 29 Jan 2004 11:53:36 +0800
Message-ID: <001001c3e61b$e51aa520$c1a110ac@cn.utstarcom.com>
From: "Rasool Wani" <rasool.wani@utstar.com>
To: <megaco@ietf.org>, "Samuel Tardieu" <sam@rfc1149.net>
References: <874qufy4gx.fsf@beeblebrox.enst.fr>
Subject: Re: [Megaco] Mandatory serviceChangeReason parameter?
Date: Thu, 29 Jan 2004 11:56:37 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Value is SEQUENCE OF Octet String.
A value of zero Octet String can be transmitted.


----- Original Message ----- 
From: "Samuel Tardieu" <sam@rfc1149.net>
To: <megaco@ietf.org>
Sent: Thursday, January 29, 2004 8:37 AM
Subject: [Megaco] Mandatory serviceChangeReason parameter?


> In the ASN.1 description of RFC3525, I understand that the
> serviceChangeReason parameter is mandatory:
> 
>       serviceChangeReason     Value,
>    -- A serviceChangeReason consists of a numeric reason code
>    -- and an optional text description.
> 
> However, in appendix I, the example does not mention one:
> 
>    ServiceChange = ROOT {Services {
>        Method=Restart,
>        ServiceChangeAddress=55555, Profile=ResGW/1}
>    }
> 
> Is there an error in the example?
> 
>   Sam
> -- 
> Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Wed Jan 28 23:21:28 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17732
	for <megaco-archive@odin.ietf.org>; Wed, 28 Jan 2004 23:21:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am3fo-0008Dm-4d
	for megaco-archive@odin.ietf.org; Wed, 28 Jan 2004 23:21:00 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0T4L0lG031596
	for megaco-archive@odin.ietf.org; Wed, 28 Jan 2004 23:21:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am3fn-0008DX-TH
	for megaco-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 23:20:59 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17723
	for <megaco-web-archive@ietf.org>; Wed, 28 Jan 2004 23:20:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am3fl-0001ld-00
	for megaco-web-archive@ietf.org; Wed, 28 Jan 2004 23:20:58 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Am3eo-0001fk-00
	for megaco-web-archive@ietf.org; Wed, 28 Jan 2004 23:19:59 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am3dv-0001aJ-00
	for megaco-web-archive@ietf.org; Wed, 28 Jan 2004 23:19:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am3du-00085w-CY; Wed, 28 Jan 2004 23:19:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am3d0-0007uW-QO
	for megaco@optimus.ietf.org; Wed, 28 Jan 2004 23:18:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17621
	for <megaco@ietf.org>; Wed, 28 Jan 2004 23:18:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am3cy-0001Tl-00
	for megaco@ietf.org; Wed, 28 Jan 2004 23:18:05 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Am3cR-0001MK-00
	for megaco@ietf.org; Wed, 28 Jan 2004 23:17:31 -0500
Received: from sym.gdsz.cncnet.net ([210.21.224.29] helo=szsmtp.utstar.com.cn)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am3bL-0000yc-00
	for megaco@ietf.org; Wed, 28 Jan 2004 23:16:23 -0500
Received: from sznssrasool ([172.19.17.174])
	by szsmtp.utstar.com.cn (8.11.6/8.11.1) with SMTP id i0T3rab07122;
	Thu, 29 Jan 2004 11:53:36 +0800
Message-ID: <001001c3e61b$e51aa520$c1a110ac@cn.utstarcom.com>
From: "Rasool Wani" <rasool.wani@utstar.com>
To: <megaco@ietf.org>, "Samuel Tardieu" <sam@rfc1149.net>
References: <874qufy4gx.fsf@beeblebrox.enst.fr>
Subject: Re: [Megaco] Mandatory serviceChangeReason parameter?
Date: Thu, 29 Jan 2004 11:56:37 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Value is SEQUENCE OF Octet String.
A value of zero Octet String can be transmitted.


----- Original Message ----- 
From: "Samuel Tardieu" <sam@rfc1149.net>
To: <megaco@ietf.org>
Sent: Thursday, January 29, 2004 8:37 AM
Subject: [Megaco] Mandatory serviceChangeReason parameter?


> In the ASN.1 description of RFC3525, I understand that the
> serviceChangeReason parameter is mandatory:
> 
>       serviceChangeReason     Value,
>    -- A serviceChangeReason consists of a numeric reason code
>    -- and an optional text description.
> 
> However, in appendix I, the example does not mention one:
> 
>    ServiceChange = ROOT {Services {
>        Method=Restart,
>        ServiceChangeAddress=55555, Profile=ResGW/1}
>    }
> 
> Is there an error in the example?
> 
>   Sam
> -- 
> Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan 29 04:36:12 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09785
	for <megaco-archive@lists.ietf.org>; Thu, 29 Jan 2004 04:36:12 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am8Zi-0005rS-U2; Thu, 29 Jan 2004 04:35:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am8Yt-0005qQ-Qw
	for megaco@optimus.ietf.org; Thu, 29 Jan 2004 04:34:11 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09683
	for <megaco@ietf.org>; Thu, 29 Jan 2004 04:34:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am8Yq-0002eI-00
	for megaco@ietf.org; Thu, 29 Jan 2004 04:34:09 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Am8Xx-0002ZJ-00
	for megaco@ietf.org; Thu, 29 Jan 2004 04:33:13 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am8Xj-0002Sw-00
	for megaco@ietf.org; Thu, 29 Jan 2004 04:32:59 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0T9WTf18466
	for <megaco@ietf.org>; Thu, 29 Jan 2004 04:32:29 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DXM05DBZ>; Thu, 29 Jan 2004 04:32:30 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E30A081@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Carlos Rodríguez Alcalá Villagra <crav@conexion.com.py>, megaco@ietf.org
Subject: RE: [Megaco] busy tone
Date: Thu, 29 Jan 2004 04:32:30 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

I would seek the guidance of local regulations and standards for busy
treatment in your target market.  Typically, the originator is rerouted to
an announcement or tone indicating the busy status of the terminating party,
though local requirements may differ.
 
Kevin


  _____  

From: Carlos Rodríguez Alcalá Villagra [mailto:crav@conexion.com.py] 
Sent: Wednesday, January 28, 2004 10:57 AM
To: megaco@ietf.org
Subject: [Megaco] busy tone


Where I can find some examples of analog-call-flow when G2 is busy??
thanks
In another words if I have two gateway GW1 and GW2 and one line of GW1 want
to comunicate with a line in GW2 and this line is busy in that moment???
 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan 29 04:37:45 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10047
	for <megaco-archive@odin.ietf.org>; Thu, 29 Jan 2004 04:37:45 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am8bs-0006AQ-RY
	for megaco-archive@odin.ietf.org; Thu, 29 Jan 2004 04:37:17 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0T9bGWv023703
	for megaco-archive@odin.ietf.org; Thu, 29 Jan 2004 04:37:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am8bs-0006A6-6E
	for megaco-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 04:37:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09959
	for <megaco-web-archive@ietf.org>; Thu, 29 Jan 2004 04:37:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am8bp-00034X-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 04:37:13 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Am8b2-0002v0-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 04:36:25 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am8aM-0002mu-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 04:35:42 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am8Zi-0005rS-U2; Thu, 29 Jan 2004 04:35:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am8Yt-0005qQ-Qw
	for megaco@optimus.ietf.org; Thu, 29 Jan 2004 04:34:11 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09683
	for <megaco@ietf.org>; Thu, 29 Jan 2004 04:34:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am8Yq-0002eI-00
	for megaco@ietf.org; Thu, 29 Jan 2004 04:34:09 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Am8Xx-0002ZJ-00
	for megaco@ietf.org; Thu, 29 Jan 2004 04:33:13 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am8Xj-0002Sw-00
	for megaco@ietf.org; Thu, 29 Jan 2004 04:32:59 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0T9WTf18466
	for <megaco@ietf.org>; Thu, 29 Jan 2004 04:32:29 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DXM05DBZ>; Thu, 29 Jan 2004 04:32:30 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E30A081@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Carlos Rodríguez Alcalá Villagra <crav@conexion.com.py>, megaco@ietf.org
Subject: RE: [Megaco] busy tone
Date: Thu, 29 Jan 2004 04:32:30 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60

I would seek the guidance of local regulations and standards for busy
treatment in your target market.  Typically, the originator is rerouted to
an announcement or tone indicating the busy status of the terminating party,
though local requirements may differ.
 
Kevin


  _____  

From: Carlos Rodríguez Alcalá Villagra [mailto:crav@conexion.com.py] 
Sent: Wednesday, January 28, 2004 10:57 AM
To: megaco@ietf.org
Subject: [Megaco] busy tone


Where I can find some examples of analog-call-flow when G2 is busy??
thanks
In another words if I have two gateway GW1 and GW2 and one line of GW1 want
to comunicate with a line in GW2 and this line is busy in that moment???
 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan 29 04:41:16 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10338
	for <megaco-archive@lists.ietf.org>; Thu, 29 Jan 2004 04:41:16 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am8ec-0006Zq-Op; Thu, 29 Jan 2004 04:40:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am8e5-0006Xb-7X
	for megaco@optimus.ietf.org; Thu, 29 Jan 2004 04:39:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10213
	for <megaco@ietf.org>; Thu, 29 Jan 2004 04:39:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am8e2-0003Rn-00
	for megaco@ietf.org; Thu, 29 Jan 2004 04:39:30 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Am8d8-0003Im-00
	for megaco@ietf.org; Thu, 29 Jan 2004 04:38:34 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am8ca-00037B-00
	for megaco@ietf.org; Thu, 29 Jan 2004 04:38:00 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0T9bUp19201
	for <megaco@ietf.org>; Thu, 29 Jan 2004 04:37:30 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DXM05DB0>; Thu, 29 Jan 2004 04:37:31 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E30A082@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Rasool Wani <rasool.wani@utstar.com>, megaco@ietf.org,
        Samuel Tardieu
	 <sam@rfc1149.net>
Subject: RE: [Megaco] Mandatory serviceChangeReason parameter?
Date: Thu, 29 Jan 2004 04:37:30 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

ServiceChangeReason is mandatory.  The example in Appendix I has an error.

It is important to note that the Appendix is not normative text.  It only
provides guidance as to one possible protocol use, but should not be taken
as mandatory usage.

Kevin 

-----Original Message-----
From: Rasool Wani [mailto:rasool.wani@utstar.com] 
Sent: Wednesday, January 28, 2004 10:57 PM
To: megaco@ietf.org; Samuel Tardieu
Subject: Re: [Megaco] Mandatory serviceChangeReason parameter?

Value is SEQUENCE OF Octet String.
A value of zero Octet String can be transmitted.


----- Original Message -----
From: "Samuel Tardieu" <sam@rfc1149.net>
To: <megaco@ietf.org>
Sent: Thursday, January 29, 2004 8:37 AM
Subject: [Megaco] Mandatory serviceChangeReason parameter?


> In the ASN.1 description of RFC3525, I understand that the
> serviceChangeReason parameter is mandatory:
> 
>       serviceChangeReason     Value,
>    -- A serviceChangeReason consists of a numeric reason code
>    -- and an optional text description.
> 
> However, in appendix I, the example does not mention one:
> 
>    ServiceChange = ROOT {Services {
>        Method=Restart,
>        ServiceChangeAddress=55555, Profile=ResGW/1}
>    }
> 
> Is there an error in the example?
> 
>   Sam
> -- 
> Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan 29 04:42:44 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10383
	for <megaco-archive@odin.ietf.org>; Thu, 29 Jan 2004 04:42:44 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am8gi-0006my-O9
	for megaco-archive@odin.ietf.org; Thu, 29 Jan 2004 04:42:16 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0T9gGFZ026090
	for megaco-archive@odin.ietf.org; Thu, 29 Jan 2004 04:42:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am8gi-0006mj-CL
	for megaco-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 04:42:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10368
	for <megaco-web-archive@ietf.org>; Thu, 29 Jan 2004 04:42:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am8gf-0003lR-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 04:42:13 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Am8fe-0003f8-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 04:41:11 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am8fG-0003Zi-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 04:40:46 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am8ec-0006Zq-Op; Thu, 29 Jan 2004 04:40:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Am8e5-0006Xb-7X
	for megaco@optimus.ietf.org; Thu, 29 Jan 2004 04:39:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10213
	for <megaco@ietf.org>; Thu, 29 Jan 2004 04:39:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am8e2-0003Rn-00
	for megaco@ietf.org; Thu, 29 Jan 2004 04:39:30 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Am8d8-0003Im-00
	for megaco@ietf.org; Thu, 29 Jan 2004 04:38:34 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Am8ca-00037B-00
	for megaco@ietf.org; Thu, 29 Jan 2004 04:38:00 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0T9bUp19201
	for <megaco@ietf.org>; Thu, 29 Jan 2004 04:37:30 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DXM05DB0>; Thu, 29 Jan 2004 04:37:31 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E30A082@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Rasool Wani <rasool.wani@utstar.com>, megaco@ietf.org,
        Samuel Tardieu
	 <sam@rfc1149.net>
Subject: RE: [Megaco] Mandatory serviceChangeReason parameter?
Date: Thu, 29 Jan 2004 04:37:30 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60

ServiceChangeReason is mandatory.  The example in Appendix I has an error.

It is important to note that the Appendix is not normative text.  It only
provides guidance as to one possible protocol use, but should not be taken
as mandatory usage.

Kevin 

-----Original Message-----
From: Rasool Wani [mailto:rasool.wani@utstar.com] 
Sent: Wednesday, January 28, 2004 10:57 PM
To: megaco@ietf.org; Samuel Tardieu
Subject: Re: [Megaco] Mandatory serviceChangeReason parameter?

Value is SEQUENCE OF Octet String.
A value of zero Octet String can be transmitted.


----- Original Message -----
From: "Samuel Tardieu" <sam@rfc1149.net>
To: <megaco@ietf.org>
Sent: Thursday, January 29, 2004 8:37 AM
Subject: [Megaco] Mandatory serviceChangeReason parameter?


> In the ASN.1 description of RFC3525, I understand that the
> serviceChangeReason parameter is mandatory:
> 
>       serviceChangeReason     Value,
>    -- A serviceChangeReason consists of a numeric reason code
>    -- and an optional text description.
> 
> However, in appendix I, the example does not mention one:
> 
>    ServiceChange = ROOT {Services {
>        Method=Restart,
>        ServiceChangeAddress=55555, Profile=ResGW/1}
>    }
> 
> Is there an error in the example?
> 
>   Sam
> -- 
> Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan 29 06:41:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13425
	for <megaco-archive@lists.ietf.org>; Thu, 29 Jan 2004 06:41:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmAXe-00007T-K1; Thu, 29 Jan 2004 06:41:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmAWt-0008VS-67
	for megaco@optimus.ietf.org; Thu, 29 Jan 2004 06:40:15 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13409
	for <megaco@ietf.org>; Thu, 29 Jan 2004 06:40:10 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmAWp-00004J-00
	for megaco@ietf.org; Thu, 29 Jan 2004 06:40:11 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmAVr-0007mu-00
	for megaco@ietf.org; Thu, 29 Jan 2004 06:39:12 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmAVK-0007bz-00
	for megaco@ietf.org; Thu, 29 Jan 2004 06:38:38 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0TBc8k24699
	for <megaco@ietf.org>; Thu, 29 Jan 2004 06:38:08 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DXM05DLB>; Thu, 29 Jan 2004 06:38:09 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E30A099@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Samuel Tardieu <sam@rfc1149.net>, megaco@ietf.org
Subject: RE: [Megaco] Megaco, caller id and VoIP
Date: Thu, 29 Jan 2004 06:38:07 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Caller ID destined for CPE equipment is passed according to H.248.23.  This
specifies that the CallerID info is passed as hex data formatted in
accordance with the generally accepted CLASS modem requirements.

For other applications, other methods are necessary.  For instance, if ISUP
is being utilized, the caller information is passed out of band utilizing
methods outlined in the Q-series of ITU Recommendations.

You should explore the requirements of your locality for appropriate methods
to use to pass this info and the timing of those methods based upon your
application.

Kevin

-----Original Message-----
From: Samuel Tardieu [mailto:sam@rfc1149.net] 
Sent: Tuesday, January 27, 2004 7:33 PM
To: megaco@ietf.org
Subject: [Megaco] Megaco, caller id and VoIP

Hi.

I am discovering Megaco and I have a few (probably trivial)
questions:

  - in a VoIP only application, is it possible to use a textual string
    instead of digits to designate the recipient?

  - at what time will the caller id and the callee id be presented to
    the callee (e.g., to let a MG which acts as a gateway to another
    system present the callee phone number to the external system)

  Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan 29 06:42:45 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13460
	for <megaco-archive@odin.ietf.org>; Thu, 29 Jan 2004 06:42:45 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmAYt-0000Kq-1H
	for megaco-archive@odin.ietf.org; Thu, 29 Jan 2004 06:42:19 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TBgJZk001282
	for megaco-archive@odin.ietf.org; Thu, 29 Jan 2004 06:42:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmAYs-0000Kb-T7
	for megaco-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 06:42:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13456
	for <megaco-web-archive@ietf.org>; Thu, 29 Jan 2004 06:42:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmAYo-0000FS-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 06:42:14 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmAXp-0000A7-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 06:41:14 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmAXc-00004g-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 06:41:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmAXe-00007T-K1; Thu, 29 Jan 2004 06:41:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmAWt-0008VS-67
	for megaco@optimus.ietf.org; Thu, 29 Jan 2004 06:40:15 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13409
	for <megaco@ietf.org>; Thu, 29 Jan 2004 06:40:10 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmAWp-00004J-00
	for megaco@ietf.org; Thu, 29 Jan 2004 06:40:11 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmAVr-0007mu-00
	for megaco@ietf.org; Thu, 29 Jan 2004 06:39:12 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmAVK-0007bz-00
	for megaco@ietf.org; Thu, 29 Jan 2004 06:38:38 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0TBc8k24699
	for <megaco@ietf.org>; Thu, 29 Jan 2004 06:38:08 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DXM05DLB>; Thu, 29 Jan 2004 06:38:09 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E30A099@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Samuel Tardieu <sam@rfc1149.net>, megaco@ietf.org
Subject: RE: [Megaco] Megaco, caller id and VoIP
Date: Thu, 29 Jan 2004 06:38:07 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60

Caller ID destined for CPE equipment is passed according to H.248.23.  This
specifies that the CallerID info is passed as hex data formatted in
accordance with the generally accepted CLASS modem requirements.

For other applications, other methods are necessary.  For instance, if ISUP
is being utilized, the caller information is passed out of band utilizing
methods outlined in the Q-series of ITU Recommendations.

You should explore the requirements of your locality for appropriate methods
to use to pass this info and the timing of those methods based upon your
application.

Kevin

-----Original Message-----
From: Samuel Tardieu [mailto:sam@rfc1149.net] 
Sent: Tuesday, January 27, 2004 7:33 PM
To: megaco@ietf.org
Subject: [Megaco] Megaco, caller id and VoIP

Hi.

I am discovering Megaco and I have a few (probably trivial)
questions:

  - in a VoIP only application, is it possible to use a textual string
    instead of digits to designate the recipient?

  - at what time will the caller id and the callee id be presented to
    the callee (e.g., to let a MG which acts as a gateway to another
    system present the callee phone number to the external system)

  Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan 29 06:49:27 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13698
	for <megaco-archive@lists.ietf.org>; Thu, 29 Jan 2004 06:49:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmAfN-0000iv-37; Thu, 29 Jan 2004 06:49:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmAed-0000Yj-V5
	for megaco@optimus.ietf.org; Thu, 29 Jan 2004 06:48:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13618
	for <megaco@ietf.org>; Thu, 29 Jan 2004 06:48:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmAeZ-0000qk-00
	for megaco@ietf.org; Thu, 29 Jan 2004 06:48:11 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmAdg-0000l6-00
	for megaco@ietf.org; Thu, 29 Jan 2004 06:47:16 -0500
Received: from main.gmane.org ([80.91.224.249])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmAcj-0000eS-00
	for megaco@ietf.org; Thu, 29 Jan 2004 06:46:17 -0500
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1AmAcd-0001Lp-00
	for <megaco@ietf.org>; Thu, 29 Jan 2004 12:46:12 +0100
Received: from willow.rfc1149.net ([81.56.47.149])
        by news.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <megaco@ietf.org>; Thu Jan 29 11:46:12 2004
X-Injected-Via-Gmane: http://gmane.org/
To: megaco@ietf.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 1AmAcb-0001La-00
	for <gmane-ietf-megaco@m.gmane.org>; Thu, 29 Jan 2004 12:46:09 +0100
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1AmAcb-0000eN-00
	for <gmane-ietf-megaco@m.gmane.org>; Thu, 29 Jan 2004 12:46:09 +0100
From: Samuel Tardieu <sam@rfc1149.net>
Date: Thu, 29 Jan 2004 12:43:55 +0100
Organization: Avian Carrier & Friends
Lines: 15
Message-ID: <8765evrnd0.fsf@beeblebrox.enst.fr>
References: <874qufy4gx.fsf@beeblebrox.enst.fr> <001001c3e61b$e51aa520$c1a110ac@cn.utstarcom.com>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Complaints-To: usenet@sea.gmane.org
Gmane-NNTP-Posting-Host: willow.rfc1149.net
User-Agent: T-gnus/6.16.2 (based on Gnus v5.10.2) (revision 02) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI)
Cancel-Lock: sha1:5+d33D/zjP31Vj252uN2ijToPH4=
X-Leafnode-NNTP-Posting-Host: 3ffe:304:103:111:200:39ff:fe25:3aa2
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Subject: [Megaco] Re: Mandatory serviceChangeReason parameter?
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

>>>>> "Rasool" == Rasool Wani <rasool.wani@utstar.com> writes:

> Value is SEQUENCE OF Octet String.  A value of zero Octet String can
> be transmitted.

This is not how I understand the comment in the grammar:

   -- The serviceChangeReason SHALL be a string consisting of
   -- a decimal reason code, optionally followed by a single
   -- space character and a textual description string.
   -- This string is first BER-encoded as an IA5String.

 Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan 29 06:50:49 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13817
	for <megaco-archive@odin.ietf.org>; Thu, 29 Jan 2004 06:50:49 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmAgh-0000wr-RW
	for megaco-archive@odin.ietf.org; Thu, 29 Jan 2004 06:50:23 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TBoNcD003639
	for megaco-archive@odin.ietf.org; Thu, 29 Jan 2004 06:50:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmAgh-0000wc-NE
	for megaco-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 06:50:23 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13789
	for <megaco-web-archive@ietf.org>; Thu, 29 Jan 2004 06:50:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmAgd-000143-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 06:50:19 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmAfh-0000xP-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 06:49:21 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmAfK-0000rQ-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 06:48:58 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmAfN-0000iv-37; Thu, 29 Jan 2004 06:49:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmAed-0000Yj-V5
	for megaco@optimus.ietf.org; Thu, 29 Jan 2004 06:48:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13618
	for <megaco@ietf.org>; Thu, 29 Jan 2004 06:48:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmAeZ-0000qk-00
	for megaco@ietf.org; Thu, 29 Jan 2004 06:48:11 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmAdg-0000l6-00
	for megaco@ietf.org; Thu, 29 Jan 2004 06:47:16 -0500
Received: from main.gmane.org ([80.91.224.249])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmAcj-0000eS-00
	for megaco@ietf.org; Thu, 29 Jan 2004 06:46:17 -0500
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1AmAcd-0001Lp-00
	for <megaco@ietf.org>; Thu, 29 Jan 2004 12:46:12 +0100
Received: from willow.rfc1149.net ([81.56.47.149])
        by news.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <megaco@ietf.org>; Thu Jan 29 11:46:12 2004
X-Injected-Via-Gmane: http://gmane.org/
To: megaco@ietf.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 1AmAcb-0001La-00
	for <gmane-ietf-megaco@m.gmane.org>; Thu, 29 Jan 2004 12:46:09 +0100
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1AmAcb-0000eN-00
	for <gmane-ietf-megaco@m.gmane.org>; Thu, 29 Jan 2004 12:46:09 +0100
From: Samuel Tardieu <sam@rfc1149.net>
Date: Thu, 29 Jan 2004 12:43:55 +0100
Organization: Avian Carrier & Friends
Lines: 15
Message-ID: <8765evrnd0.fsf@beeblebrox.enst.fr>
References: <874qufy4gx.fsf@beeblebrox.enst.fr> <001001c3e61b$e51aa520$c1a110ac@cn.utstarcom.com>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Complaints-To: usenet@sea.gmane.org
Gmane-NNTP-Posting-Host: willow.rfc1149.net
User-Agent: T-gnus/6.16.2 (based on Gnus v5.10.2) (revision 02) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI)
Cancel-Lock: sha1:5+d33D/zjP31Vj252uN2ijToPH4=
X-Leafnode-NNTP-Posting-Host: 3ffe:304:103:111:200:39ff:fe25:3aa2
Subject: [Megaco] Re: Mandatory serviceChangeReason parameter?
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

>>>>> "Rasool" == Rasool Wani <rasool.wani@utstar.com> writes:

> Value is SEQUENCE OF Octet String.  A value of zero Octet String can
> be transmitted.

This is not how I understand the comment in the grammar:

   -- The serviceChangeReason SHALL be a string consisting of
   -- a decimal reason code, optionally followed by a single
   -- space character and a textual description string.
   -- This string is first BER-encoded as an IA5String.

 Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan 29 06:53:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13952
	for <megaco-archive@lists.ietf.org>; Thu, 29 Jan 2004 06:53:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmAjG-00016I-91; Thu, 29 Jan 2004 06:53:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmAie-00015K-3d
	for megaco@optimus.ietf.org; Thu, 29 Jan 2004 06:52:24 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13895
	for <megaco@ietf.org>; Thu, 29 Jan 2004 06:52:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmAiZ-0001HH-00
	for megaco@ietf.org; Thu, 29 Jan 2004 06:52:20 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmAhc-0001Bl-00
	for megaco@ietf.org; Thu, 29 Jan 2004 06:51:21 -0500
Received: from main.gmane.org ([80.91.224.249])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmAh1-00015e-00
	for megaco@ietf.org; Thu, 29 Jan 2004 06:50:43 -0500
Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1AmAh2-0001Nu-00
	for <megaco@ietf.org>; Thu, 29 Jan 2004 12:50:44 +0100
Received: from willow.rfc1149.net ([81.56.47.149])
        by news.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <megaco@ietf.org>; Thu Jan 29 11:50:44 2004
X-Injected-Via-Gmane: http://gmane.org/
To: megaco@ietf.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 1AmAcd-0001Lh-00
	for <gmane-ietf-megaco@m.gmane.org>; Thu, 29 Jan 2004 12:46:11 +0100
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1AmAcd-0000eS-00
	for <gmane-ietf-megaco@m.gmane.org>; Thu, 29 Jan 2004 12:46:11 +0100
From: Samuel Tardieu <sam@rfc1149.net>
Date: Thu, 29 Jan 2004 12:44:59 +0100
Organization: Avian Carrier & Friends
Lines: 14
Message-ID: <871xpjrnb8.fsf@beeblebrox.enst.fr>
References: <ABA227A15B80D511BD1A00508BF93A1C0E30A082@zrtpd0jq.us.nortel.com>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Complaints-To: usenet@sea.gmane.org
Gmane-NNTP-Posting-Host: willow.rfc1149.net
User-Agent: T-gnus/6.16.2 (based on Gnus v5.10.2) (revision 02) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI)
Cancel-Lock: sha1:Mnf873Q2RQLRJ2kXndOITFs9Ig0=
X-Leafnode-NNTP-Posting-Host: 3ffe:304:103:111:200:39ff:fe25:3aa2
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Subject: [Megaco] Re: Mandatory serviceChangeReason parameter?
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

>>>>> "Kevin" == Kevin Boyle <kboyle@nortelnetworks.com> writes:

> ServiceChangeReason is mandatory.  The example in Appendix I has an
> error.  It is important to note that the Appendix is not normative
> text.  It only provides guidance as to one possible protocol use,
> but should not be taken as mandatory usage.

Sure, but as I guess many people, I started to play with Megaco by
encoding/decoding the example given in the RFC :-) Any chance to have
a corrected example in Megaco v2 ? (if it is not too late)

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan 29 06:54:41 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14023
	for <megaco-archive@odin.ietf.org>; Thu, 29 Jan 2004 06:54:41 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmAkR-0001FO-Vr
	for megaco-archive@odin.ietf.org; Thu, 29 Jan 2004 06:54:16 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TBsF8d004788
	for megaco-archive@odin.ietf.org; Thu, 29 Jan 2004 06:54:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmAkR-0001F9-Se
	for megaco-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 06:54:15 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13991
	for <megaco-web-archive@ietf.org>; Thu, 29 Jan 2004 06:54:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmAkN-0001T6-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 06:54:11 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmAjP-0001NE-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 06:53:12 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmAjD-0001IN-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 06:52:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmAjG-00016I-91; Thu, 29 Jan 2004 06:53:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmAie-00015K-3d
	for megaco@optimus.ietf.org; Thu, 29 Jan 2004 06:52:24 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13895
	for <megaco@ietf.org>; Thu, 29 Jan 2004 06:52:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmAiZ-0001HH-00
	for megaco@ietf.org; Thu, 29 Jan 2004 06:52:20 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmAhc-0001Bl-00
	for megaco@ietf.org; Thu, 29 Jan 2004 06:51:21 -0500
Received: from main.gmane.org ([80.91.224.249])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmAh1-00015e-00
	for megaco@ietf.org; Thu, 29 Jan 2004 06:50:43 -0500
Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1AmAh2-0001Nu-00
	for <megaco@ietf.org>; Thu, 29 Jan 2004 12:50:44 +0100
Received: from willow.rfc1149.net ([81.56.47.149])
        by news.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <megaco@ietf.org>; Thu Jan 29 11:50:44 2004
X-Injected-Via-Gmane: http://gmane.org/
To: megaco@ietf.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 1AmAcd-0001Lh-00
	for <gmane-ietf-megaco@m.gmane.org>; Thu, 29 Jan 2004 12:46:11 +0100
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1AmAcd-0000eS-00
	for <gmane-ietf-megaco@m.gmane.org>; Thu, 29 Jan 2004 12:46:11 +0100
From: Samuel Tardieu <sam@rfc1149.net>
Date: Thu, 29 Jan 2004 12:44:59 +0100
Organization: Avian Carrier & Friends
Lines: 14
Message-ID: <871xpjrnb8.fsf@beeblebrox.enst.fr>
References: <ABA227A15B80D511BD1A00508BF93A1C0E30A082@zrtpd0jq.us.nortel.com>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Complaints-To: usenet@sea.gmane.org
Gmane-NNTP-Posting-Host: willow.rfc1149.net
User-Agent: T-gnus/6.16.2 (based on Gnus v5.10.2) (revision 02) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI)
Cancel-Lock: sha1:Mnf873Q2RQLRJ2kXndOITFs9Ig0=
X-Leafnode-NNTP-Posting-Host: 3ffe:304:103:111:200:39ff:fe25:3aa2
Subject: [Megaco] Re: Mandatory serviceChangeReason parameter?
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

>>>>> "Kevin" == Kevin Boyle <kboyle@nortelnetworks.com> writes:

> ServiceChangeReason is mandatory.  The example in Appendix I has an
> error.  It is important to note that the Appendix is not normative
> text.  It only provides guidance as to one possible protocol use,
> but should not be taken as mandatory usage.

Sure, but as I guess many people, I started to play with Megaco by
encoding/decoding the example given in the RFC :-) Any chance to have
a corrected example in Megaco v2 ? (if it is not too late)

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan 29 08:52:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17424
	for <megaco-archive@lists.ietf.org>; Thu, 29 Jan 2004 08:52:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmCaP-0008U9-42; Thu, 29 Jan 2004 08:52:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmCZi-0008RZ-K4
	for megaco@optimus.ietf.org; Thu, 29 Jan 2004 08:51:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17413
	for <megaco@ietf.org>; Thu, 29 Jan 2004 08:51:16 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmCZh-00067m-00
	for megaco@ietf.org; Thu, 29 Jan 2004 08:51:17 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmCYi-00062J-00
	for megaco@ietf.org; Thu, 29 Jan 2004 08:50:17 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmCXn-0005rz-00
	for megaco@ietf.org; Thu, 29 Jan 2004 08:49:19 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0TDmmm04794
	for <megaco@ietf.org>; Thu, 29 Jan 2004 08:48:48 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DXM0510M>; Thu, 29 Jan 2004 08:48:49 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E30A21C@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Samuel Tardieu <sam@rfc1149.net>, megaco@ietf.org
Subject: RE: [Megaco] Re: Mandatory serviceChangeReason parameter?
Date: Thu, 29 Jan 2004 08:48:48 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

The Corrigendum for V2 has gone for consent.  If there are no objections, I
will enter this as the first item in the new IG which would get Approved in
November.

Kevin

-----Original Message-----
From: Samuel Tardieu [mailto:sam@rfc1149.net] 
Sent: Thursday, January 29, 2004 6:45 AM
To: megaco@ietf.org
Subject: [Megaco] Re: Mandatory serviceChangeReason parameter?

>>>>> "Kevin" == Kevin Boyle <kboyle@nortelnetworks.com> writes:

> ServiceChangeReason is mandatory.  The example in Appendix I has an 
> error.  It is important to note that the Appendix is not normative 
> text.  It only provides guidance as to one possible protocol use, but 
> should not be taken as mandatory usage.

Sure, but as I guess many people, I started to play with Megaco by
encoding/decoding the example given in the RFC :-) Any chance to have a
corrected example in Megaco v2 ? (if it is not too late)

  Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan 29 09:02:54 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18008
	for <megaco-archive@odin.ietf.org>; Thu, 29 Jan 2004 09:02:54 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmCkU-0000XY-Hn
	for megaco-archive@odin.ietf.org; Thu, 29 Jan 2004 09:02:26 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TE2Q3g002070
	for megaco-archive@odin.ietf.org; Thu, 29 Jan 2004 09:02:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmCkU-0000XJ-Ay
	for megaco-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 09:02:26 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17875
	for <megaco-web-archive@ietf.org>; Thu, 29 Jan 2004 09:02:23 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmCkS-0007Wp-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 09:02:24 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmCjR-0007H9-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 09:01:22 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmCie-0007BN-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 09:00:32 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1AmCaR-0006St-HC
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 08:52:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmCaP-0008U9-42; Thu, 29 Jan 2004 08:52:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmCZi-0008RZ-K4
	for megaco@optimus.ietf.org; Thu, 29 Jan 2004 08:51:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17413
	for <megaco@ietf.org>; Thu, 29 Jan 2004 08:51:16 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmCZh-00067m-00
	for megaco@ietf.org; Thu, 29 Jan 2004 08:51:17 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmCYi-00062J-00
	for megaco@ietf.org; Thu, 29 Jan 2004 08:50:17 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmCXn-0005rz-00
	for megaco@ietf.org; Thu, 29 Jan 2004 08:49:19 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0TDmmm04794
	for <megaco@ietf.org>; Thu, 29 Jan 2004 08:48:48 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DXM0510M>; Thu, 29 Jan 2004 08:48:49 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E30A21C@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Samuel Tardieu <sam@rfc1149.net>, megaco@ietf.org
Subject: RE: [Megaco] Re: Mandatory serviceChangeReason parameter?
Date: Thu, 29 Jan 2004 08:48:48 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60

The Corrigendum for V2 has gone for consent.  If there are no objections, I
will enter this as the first item in the new IG which would get Approved in
November.

Kevin

-----Original Message-----
From: Samuel Tardieu [mailto:sam@rfc1149.net] 
Sent: Thursday, January 29, 2004 6:45 AM
To: megaco@ietf.org
Subject: [Megaco] Re: Mandatory serviceChangeReason parameter?

>>>>> "Kevin" == Kevin Boyle <kboyle@nortelnetworks.com> writes:

> ServiceChangeReason is mandatory.  The example in Appendix I has an 
> error.  It is important to note that the Appendix is not normative 
> text.  It only provides guidance as to one possible protocol use, but 
> should not be taken as mandatory usage.

Sure, but as I guess many people, I started to play with Megaco by
encoding/decoding the example given in the RFC :-) Any chance to have a
corrected example in Megaco v2 ? (if it is not too late)

  Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan 29 10:14:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22547
	for <megaco-archive@lists.ietf.org>; Thu, 29 Jan 2004 10:14:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmDrk-0003OX-Nh; Thu, 29 Jan 2004 10:14:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmDrE-0003Gy-SN
	for megaco@optimus.ietf.org; Thu, 29 Jan 2004 10:13:28 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22435
	for <megaco@ietf.org>; Thu, 29 Jan 2004 10:13:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmDrC-00017X-00
	for megaco@ietf.org; Thu, 29 Jan 2004 10:13:26 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmDqY-00010w-00
	for megaco@ietf.org; Thu, 29 Jan 2004 10:12:47 -0500
Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmDpo-0000rh-00
	for megaco@ietf.org; Thu, 29 Jan 2004 10:12:00 -0500
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <DS9HHHQA>; Thu, 29 Jan 2004 10:11:59 -0500
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA03506373@wench.telica.com>
From: Carl Rutter <crutter@telica.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        Samuel Tardieu
	 <sam@rfc1149.net>, megaco@ietf.org
Subject: RE: [Megaco] Re: Mandatory serviceChangeReason parameter?
Date: Thu, 29 Jan 2004 10:11:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

As a general question to the group
I'd like to get an idea how quickly
companies and Stack vendors are and will be adding V2
support.

Thx,
Carl

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
Kevin Boyle
Sent: Thursday, January 29, 2004 8:49 AM
To: Samuel Tardieu; megaco@ietf.org
Subject: RE: [Megaco] Re: Mandatory serviceChangeReason parameter?


The Corrigendum for V2 has gone for consent.  If there are no objections, I
will enter this as the first item in the new IG which would get Approved in
November.

Kevin

-----Original Message-----
From: Samuel Tardieu [mailto:sam@rfc1149.net] 
Sent: Thursday, January 29, 2004 6:45 AM
To: megaco@ietf.org
Subject: [Megaco] Re: Mandatory serviceChangeReason parameter?

>>>>> "Kevin" == Kevin Boyle <kboyle@nortelnetworks.com> writes:

> ServiceChangeReason is mandatory.  The example in Appendix I has an 
> error.  It is important to note that the Appendix is not normative 
> text.  It only provides guidance as to one possible protocol use, but 
> should not be taken as mandatory usage.

Sure, but as I guess many people, I started to play with Megaco by
encoding/decoding the example given in the RFC :-) Any chance to have a
corrected example in Megaco v2 ? (if it is not too late)

  Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan 29 10:16:00 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22837
	for <megaco-archive@odin.ietf.org>; Thu, 29 Jan 2004 10:16:00 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmDtF-00042o-Fq
	for megaco-archive@odin.ietf.org; Thu, 29 Jan 2004 10:15:33 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TFFXNW015540
	for megaco-archive@odin.ietf.org; Thu, 29 Jan 2004 10:15:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmDtF-00042Z-Ch
	for megaco-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 10:15:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22784
	for <megaco-web-archive@ietf.org>; Thu, 29 Jan 2004 10:15:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmDtD-0001Oy-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 10:15:31 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmDsQ-0001J4-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 10:14:43 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmDrk-0001B5-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 10:14:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmDrk-0003OX-Nh; Thu, 29 Jan 2004 10:14:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmDrE-0003Gy-SN
	for megaco@optimus.ietf.org; Thu, 29 Jan 2004 10:13:28 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22435
	for <megaco@ietf.org>; Thu, 29 Jan 2004 10:13:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmDrC-00017X-00
	for megaco@ietf.org; Thu, 29 Jan 2004 10:13:26 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmDqY-00010w-00
	for megaco@ietf.org; Thu, 29 Jan 2004 10:12:47 -0500
Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmDpo-0000rh-00
	for megaco@ietf.org; Thu, 29 Jan 2004 10:12:00 -0500
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <DS9HHHQA>; Thu, 29 Jan 2004 10:11:59 -0500
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA03506373@wench.telica.com>
From: Carl Rutter <crutter@telica.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        Samuel Tardieu
	 <sam@rfc1149.net>, megaco@ietf.org
Subject: RE: [Megaco] Re: Mandatory serviceChangeReason parameter?
Date: Thu, 29 Jan 2004 10:11:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60

As a general question to the group
I'd like to get an idea how quickly
companies and Stack vendors are and will be adding V2
support.

Thx,
Carl

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
Kevin Boyle
Sent: Thursday, January 29, 2004 8:49 AM
To: Samuel Tardieu; megaco@ietf.org
Subject: RE: [Megaco] Re: Mandatory serviceChangeReason parameter?


The Corrigendum for V2 has gone for consent.  If there are no objections, I
will enter this as the first item in the new IG which would get Approved in
November.

Kevin

-----Original Message-----
From: Samuel Tardieu [mailto:sam@rfc1149.net] 
Sent: Thursday, January 29, 2004 6:45 AM
To: megaco@ietf.org
Subject: [Megaco] Re: Mandatory serviceChangeReason parameter?

>>>>> "Kevin" == Kevin Boyle <kboyle@nortelnetworks.com> writes:

> ServiceChangeReason is mandatory.  The example in Appendix I has an 
> error.  It is important to note that the Appendix is not normative 
> text.  It only provides guidance as to one possible protocol use, but 
> should not be taken as mandatory usage.

Sure, but as I guess many people, I started to play with Megaco by
encoding/decoding the example given in the RFC :-) Any chance to have a
corrected example in Megaco v2 ? (if it is not too late)

  Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan 29 12:26:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02754
	for <megaco-archive@lists.ietf.org>; Thu, 29 Jan 2004 12:26:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmFuV-00068i-O7; Thu, 29 Jan 2004 12:24:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmFgT-0004qY-6A
	for megaco@optimus.ietf.org; Thu, 29 Jan 2004 12:10:29 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01915
	for <megaco@ietf.org>; Thu, 29 Jan 2004 12:10:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmFgR-00025E-00
	for megaco@ietf.org; Thu, 29 Jan 2004 12:10:27 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmFfa-0001zs-00
	for megaco@ietf.org; Thu, 29 Jan 2004 12:09:34 -0500
Received: from main.gmane.org ([80.91.224.249])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmFf1-0001tn-00
	for megaco@ietf.org; Thu, 29 Jan 2004 12:09:00 -0500
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1AmFf1-0004c8-00
	for <megaco@ietf.org>; Thu, 29 Jan 2004 18:08:59 +0100
Received: from willow.rfc1149.net ([81.56.47.149])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <megaco@ietf.org>; Thu Jan 29 17:08:59 2004
Received: from sam by willow.rfc1149.net with local (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <megaco@ietf.org>; Thu Jan 29 17:08:59 2004
X-Injected-Via-Gmane: http://gmane.org/
To: megaco@ietf.org
From: Samuel Tardieu <sam@rfc1149.net>
Date: Thu, 29 Jan 2004 18:05:39 +0100
Organization: Avian Carrier & Friends
Lines: 11
Message-ID: <87r7xilm70.fsf@beeblebrox.enst.fr>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Complaints-To: usenet@sea.gmane.org
Gmane-NNTP-Posting-Host: willow.rfc1149.net
User-Agent: T-gnus/6.16.2 (based on Gnus v5.10.2) (revision 02) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI)
Cancel-Lock: sha1:+eePgVKa41zC58Nos2E1hVRYee0=
X-Leafnode-NNTP-Posting-Host: 3ffe:304:103:a2:200:39ff:fe25:3aa2
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Subject: [Megaco] Question on al/on(strict=state)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

In step 3 of the example in Appendix I, there is:

  Events = 2222 {al/of(strict=state)}

Where does strict=state appear in the grammar? What kind of field is
this? I read that this is an EventDescriptor parameter earlier in the
RFC, but in this case shouldn't it appear between {} instead of ()?

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan 29 12:45:42 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04263
	for <megaco-archive@odin.ietf.org>; Thu, 29 Jan 2004 12:45:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmGE7-0001sx-H8
	for megaco-archive@odin.ietf.org; Thu, 29 Jan 2004 12:45:15 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0THjFPI007243
	for megaco-archive@odin.ietf.org; Thu, 29 Jan 2004 12:45:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmGE7-0001sk-EH
	for megaco-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 12:45:15 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04132
	for <megaco-web-archive@ietf.org>; Thu, 29 Jan 2004 12:45:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmGE5-000731-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 12:45:13 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmGCb-0006iz-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 12:43:42 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmGBN-0006Oa-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 12:42:25 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmFuV-00068i-O7; Thu, 29 Jan 2004 12:24:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmFgT-0004qY-6A
	for megaco@optimus.ietf.org; Thu, 29 Jan 2004 12:10:29 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01915
	for <megaco@ietf.org>; Thu, 29 Jan 2004 12:10:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmFgR-00025E-00
	for megaco@ietf.org; Thu, 29 Jan 2004 12:10:27 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmFfa-0001zs-00
	for megaco@ietf.org; Thu, 29 Jan 2004 12:09:34 -0500
Received: from main.gmane.org ([80.91.224.249])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmFf1-0001tn-00
	for megaco@ietf.org; Thu, 29 Jan 2004 12:09:00 -0500
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1AmFf1-0004c8-00
	for <megaco@ietf.org>; Thu, 29 Jan 2004 18:08:59 +0100
Received: from willow.rfc1149.net ([81.56.47.149])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <megaco@ietf.org>; Thu Jan 29 17:08:59 2004
Received: from sam by willow.rfc1149.net with local (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <megaco@ietf.org>; Thu Jan 29 17:08:59 2004
X-Injected-Via-Gmane: http://gmane.org/
To: megaco@ietf.org
From: Samuel Tardieu <sam@rfc1149.net>
Date: Thu, 29 Jan 2004 18:05:39 +0100
Organization: Avian Carrier & Friends
Lines: 11
Message-ID: <87r7xilm70.fsf@beeblebrox.enst.fr>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Complaints-To: usenet@sea.gmane.org
Gmane-NNTP-Posting-Host: willow.rfc1149.net
User-Agent: T-gnus/6.16.2 (based on Gnus v5.10.2) (revision 02) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI)
Cancel-Lock: sha1:+eePgVKa41zC58Nos2E1hVRYee0=
X-Leafnode-NNTP-Posting-Host: 3ffe:304:103:a2:200:39ff:fe25:3aa2
Subject: [Megaco] Question on al/on(strict=state)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

In step 3 of the example in Appendix I, there is:

  Events = 2222 {al/of(strict=state)}

Where does strict=state appear in the grammar? What kind of field is
this? I read that this is an EventDescriptor parameter earlier in the
RFC, but in this case shouldn't it appear between {} instead of ()?

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Jan 29 15:08:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14016
	for <megaco-archive@lists.ietf.org>; Thu, 29 Jan 2004 15:08:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmISI-0008Jg-QN; Thu, 29 Jan 2004 15:08:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmIS2-00089M-Hv
	for megaco@optimus.ietf.org; Thu, 29 Jan 2004 15:07:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13920
	for <megaco@ietf.org>; Thu, 29 Jan 2004 15:07:42 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmIRz-0002El-00
	for megaco@ietf.org; Thu, 29 Jan 2004 15:07:43 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmIR7-00026i-00
	for megaco@ietf.org; Thu, 29 Jan 2004 15:06:50 -0500
Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmIQN-0001ue-00
	for megaco@ietf.org; Thu, 29 Jan 2004 15:06:03 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0TK5Nl10904
	for <megaco@ietf.org>; Thu, 29 Jan 2004 14:05:24 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA20900; Thu, 29 Jan 2004 15:05:21 -0500 (EST)
Cc: megaco@ietf.org
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA20891; Thu, 29 Jan 2004 15:05:19 -0500 (EST)
Message-ID: <401967F7.6060202@bell-labs.com>
Date: Thu, 29 Jan 2004 15:07:19 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kevin Boyle <kboyle@nortelnetworks.com>
Original-CC: megaco@ietf.org
Subject: Re: [Megaco] Re: Mandatory serviceChangeReason parameter?
References: <ABA227A15B80D511BD1A00508BF93A1C0E30A21C@zrtpd0jq.us.nortel.com>
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0E30A21C@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Kevin Boyle wrote:

> The Corrigendum for V2 has gone for consent.  If there are no objections, I
> will enter this as the first item in the new IG which would get Approved in
> November.
> 
> Kevin


Kevin,

Here are some typos I posted recently that should be addressed as well.

> I was reading the V2 doc and spotted the following minor items...
> 
> In Annex B, auditItem was added to serviceChangeParm.  The
> at-most-once comment doesn't really apply to auditItem;
> possibly to the elements of auditItem.
> 
> In Annex B, where indAudterminationAudit was added to X
> there's a typo -- an extra paren.
> 
> In Annex A, where comments discuss "X-" and "X+", there's
> a typo/problem with the "-".
> 
> In Appendix I, the call flow examples all show "MEGACO/1"
> instead of "MEGACO/2".  Also the registration ServiceChange
> message does not use the mandatory ServiceChangeVersion param.
> 
>   (From 11.3: "A ServiceChange command from a MG that registers
>   with an MGC shall contain the version number of the protocol
>   supported by the MG in the ServiceChangeVersion parameter.")
> 
> -troy 



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Thu Jan 29 15:10:05 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14246
	for <megaco-archive@odin.ietf.org>; Thu, 29 Jan 2004 15:10:05 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmITq-0000kW-L1
	for megaco-archive@odin.ietf.org; Thu, 29 Jan 2004 15:09:38 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TK9cmB002876
	for megaco-archive@odin.ietf.org; Thu, 29 Jan 2004 15:09:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmITq-0000kJ-HH
	for megaco-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 15:09:38 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14185
	for <megaco-web-archive@ietf.org>; Thu, 29 Jan 2004 15:09:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmITn-0002Th-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 15:09:35 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmISu-0002Ma-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 15:08:41 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmISH-0002Fn-00
	for megaco-web-archive@ietf.org; Thu, 29 Jan 2004 15:08:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmISI-0008Jg-QN; Thu, 29 Jan 2004 15:08:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmIS2-00089M-Hv
	for megaco@optimus.ietf.org; Thu, 29 Jan 2004 15:07:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13920
	for <megaco@ietf.org>; Thu, 29 Jan 2004 15:07:42 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmIRz-0002El-00
	for megaco@ietf.org; Thu, 29 Jan 2004 15:07:43 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmIR7-00026i-00
	for megaco@ietf.org; Thu, 29 Jan 2004 15:06:50 -0500
Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmIQN-0001ue-00
	for megaco@ietf.org; Thu, 29 Jan 2004 15:06:03 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0TK5Nl10904
	for <megaco@ietf.org>; Thu, 29 Jan 2004 14:05:24 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA20900; Thu, 29 Jan 2004 15:05:21 -0500 (EST)
Cc: megaco@ietf.org
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA20891; Thu, 29 Jan 2004 15:05:19 -0500 (EST)
Message-ID: <401967F7.6060202@bell-labs.com>
Date: Thu, 29 Jan 2004 15:07:19 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kevin Boyle <kboyle@nortelnetworks.com>
Original-CC: megaco@ietf.org
Subject: Re: [Megaco] Re: Mandatory serviceChangeReason parameter?
References: <ABA227A15B80D511BD1A00508BF93A1C0E30A21C@zrtpd0jq.us.nortel.com>
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0E30A21C@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Kevin Boyle wrote:

> The Corrigendum for V2 has gone for consent.  If there are no objections, I
> will enter this as the first item in the new IG which would get Approved in
> November.
> 
> Kevin


Kevin,

Here are some typos I posted recently that should be addressed as well.

> I was reading the V2 doc and spotted the following minor items...
> 
> In Annex B, auditItem was added to serviceChangeParm.  The
> at-most-once comment doesn't really apply to auditItem;
> possibly to the elements of auditItem.
> 
> In Annex B, where indAudterminationAudit was added to X
> there's a typo -- an extra paren.
> 
> In Annex A, where comments discuss "X-" and "X+", there's
> a typo/problem with the "-".
> 
> In Appendix I, the call flow examples all show "MEGACO/1"
> instead of "MEGACO/2".  Also the registration ServiceChange
> message does not use the mandatory ServiceChangeVersion param.
> 
>   (From 11.3: "A ServiceChange command from a MG that registers
>   with an MGC shall contain the version number of the protocol
>   supported by the MG in the ServiceChangeVersion parameter.")
> 
> -troy 



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan 30 03:50:36 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03038
	for <megaco-archive@lists.ietf.org>; Fri, 30 Jan 2004 03:50:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmULk-00063G-CF; Fri, 30 Jan 2004 03:50:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmUKp-00060f-2i
	for megaco@optimus.ietf.org; Fri, 30 Jan 2004 03:49:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02978
	for <megaco@ietf.org>; Fri, 30 Jan 2004 03:49:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmUKm-0005eJ-00
	for megaco@ietf.org; Fri, 30 Jan 2004 03:49:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmUK4-0005XW-00
	for megaco@ietf.org; Fri, 30 Jan 2004 03:48:21 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmUJY-0005LN-00
	for megaco@ietf.org; Fri, 30 Jan 2004 03:47:48 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0U8lCH01756
	for <megaco@ietf.org>; Fri, 30 Jan 2004 03:47:13 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DXM05ZKB>; Fri, 30 Jan 2004 03:47:13 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E3EE9FC@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Troy Cauble <troy@bell-labs.com>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Re: Mandatory serviceChangeReason parameter?
Date: Fri, 30 Jan 2004 03:47:12 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Thanks.  I will bring these up as editorial issues with the TSB so that
these are corrected in the published version.

Kevin 

-----Original Message-----
From: Troy Cauble [mailto:troy@bell-labs.com] 
Sent: Thursday, January 29, 2004 3:07 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: megaco@ietf.org
Subject: Re: [Megaco] Re: Mandatory serviceChangeReason parameter?

Kevin Boyle wrote:

> The Corrigendum for V2 has gone for consent.  If there are no 
> objections, I will enter this as the first item in the new IG which 
> would get Approved in November.
> 
> Kevin


Kevin,

Here are some typos I posted recently that should be addressed as well.

> I was reading the V2 doc and spotted the following minor items...
> 
> In Annex B, auditItem was added to serviceChangeParm.  The 
> at-most-once comment doesn't really apply to auditItem; possibly to 
> the elements of auditItem.
> 
> In Annex B, where indAudterminationAudit was added to X there's a typo 
> -- an extra paren.
> 
> In Annex A, where comments discuss "X-" and "X+", there's a 
> typo/problem with the "-".
> 
> In Appendix I, the call flow examples all show "MEGACO/1"
> instead of "MEGACO/2".  Also the registration ServiceChange message 
> does not use the mandatory ServiceChangeVersion param.
> 
>   (From 11.3: "A ServiceChange command from a MG that registers
>   with an MGC shall contain the version number of the protocol
>   supported by the MG in the ServiceChangeVersion parameter.")
> 
> -troy



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From megaco-admin@ietf.org  Fri Jan 30 03:51:33 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03077
	for <megaco-archive@lists.ietf.org>; Fri, 30 Jan 2004 03:51:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmUMi-0006Jc-NJ; Fri, 30 Jan 2004 03:51:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmULk-00063P-Pn
	for megaco@optimus.ietf.org; Fri, 30 Jan 2004 03:50:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03010
	for <megaco@ietf.org>; Fri, 30 Jan 2004 03:50:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmULi-0005lK-00
	for megaco@ietf.org; Fri, 30 Jan 2004 03:50:02 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmUKn-0005ed-00
	for megaco@ietf.org; Fri, 30 Jan 2004 03:49:06 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmUKG-0005Us-00
	for megaco@ietf.org; Fri, 30 Jan 2004 03:48:32 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0U8m1714808
	for <megaco@ietf.org>; Fri, 30 Jan 2004 03:48:02 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DXM05ZKF>; Fri, 30 Jan 2004 03:48:02 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E3EE9FD@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Samuel Tardieu <sam@rfc1149.net>, megaco@ietf.org
Subject: RE: [Megaco] Question on al/on(strict=state)
Date: Fri, 30 Jan 2004 03:48:02 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

The Appendix is an example, and is subject to typos.  Please reference the
specification for the appropriate grammar.

Kevin 

-----Original Message-----
From: Samuel Tardieu [mailto:sam@rfc1149.net] 
Sent: Thursday, January 29, 2004 12:06 PM
To: megaco@ietf.org
Subject: [Megaco] Question on al/on(strict=state)

In step 3 of the example in Appendix I, there is:

  Events = 2222 {al/of(strict=state)}

Where does strict=state appear in the grammar? What kind of field is this? I
read that this is an EventDescriptor parameter earlier in the RFC, but in
this case shouldn't it appear between {} instead of ()?

  Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan 30 03:52:31 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03126
	for <megaco-archive@odin.ietf.org>; Fri, 30 Jan 2004 03:52:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmUNe-0006dC-K0
	for megaco-archive@odin.ietf.org; Fri, 30 Jan 2004 03:52:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U8q2tA025487
	for megaco-archive@odin.ietf.org; Fri, 30 Jan 2004 03:52:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmUNd-0006d0-Ib
	for megaco-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 03:52:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03105
	for <megaco-web-archive@ietf.org>; Fri, 30 Jan 2004 03:51:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmUNa-00060c-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 03:51:58 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmUMe-0005sb-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 03:51:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmULm-0005lr-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 03:50:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmULk-00063G-CF; Fri, 30 Jan 2004 03:50:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmUKp-00060f-2i
	for megaco@optimus.ietf.org; Fri, 30 Jan 2004 03:49:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02978
	for <megaco@ietf.org>; Fri, 30 Jan 2004 03:49:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmUKm-0005eJ-00
	for megaco@ietf.org; Fri, 30 Jan 2004 03:49:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmUK4-0005XW-00
	for megaco@ietf.org; Fri, 30 Jan 2004 03:48:21 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmUJY-0005LN-00
	for megaco@ietf.org; Fri, 30 Jan 2004 03:47:48 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0U8lCH01756
	for <megaco@ietf.org>; Fri, 30 Jan 2004 03:47:13 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DXM05ZKB>; Fri, 30 Jan 2004 03:47:13 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E3EE9FC@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Troy Cauble <troy@bell-labs.com>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Re: Mandatory serviceChangeReason parameter?
Date: Fri, 30 Jan 2004 03:47:12 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60

Thanks.  I will bring these up as editorial issues with the TSB so that
these are corrected in the published version.

Kevin 

-----Original Message-----
From: Troy Cauble [mailto:troy@bell-labs.com] 
Sent: Thursday, January 29, 2004 3:07 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: megaco@ietf.org
Subject: Re: [Megaco] Re: Mandatory serviceChangeReason parameter?

Kevin Boyle wrote:

> The Corrigendum for V2 has gone for consent.  If there are no 
> objections, I will enter this as the first item in the new IG which 
> would get Approved in November.
> 
> Kevin


Kevin,

Here are some typos I posted recently that should be addressed as well.

> I was reading the V2 doc and spotted the following minor items...
> 
> In Annex B, auditItem was added to serviceChangeParm.  The 
> at-most-once comment doesn't really apply to auditItem; possibly to 
> the elements of auditItem.
> 
> In Annex B, where indAudterminationAudit was added to X there's a typo 
> -- an extra paren.
> 
> In Annex A, where comments discuss "X-" and "X+", there's a 
> typo/problem with the "-".
> 
> In Appendix I, the call flow examples all show "MEGACO/1"
> instead of "MEGACO/2".  Also the registration ServiceChange message 
> does not use the mandatory ServiceChangeVersion param.
> 
>   (From 11.3: "A ServiceChange command from a MG that registers
>   with an MGC shall contain the version number of the protocol
>   supported by the MG in the ServiceChangeVersion parameter.")
> 
> -troy



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From exim@www1.ietf.org  Fri Jan 30 03:53:31 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03226
	for <megaco-archive@odin.ietf.org>; Fri, 30 Jan 2004 03:53:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmUOc-0006fQ-OK
	for megaco-archive@odin.ietf.org; Fri, 30 Jan 2004 03:53:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U8r26F025620
	for megaco-archive@odin.ietf.org; Fri, 30 Jan 2004 03:53:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmUOb-0006f9-Mc
	for megaco-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 03:53:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03160
	for <megaco-web-archive@ietf.org>; Fri, 30 Jan 2004 03:52:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmUOZ-0006B3-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 03:52:59 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmUNb-00060m-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 03:52:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmUMh-0005sp-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 03:51:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmUMi-0006Jc-NJ; Fri, 30 Jan 2004 03:51:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmULk-00063P-Pn
	for megaco@optimus.ietf.org; Fri, 30 Jan 2004 03:50:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03010
	for <megaco@ietf.org>; Fri, 30 Jan 2004 03:50:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmULi-0005lK-00
	for megaco@ietf.org; Fri, 30 Jan 2004 03:50:02 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmUKn-0005ed-00
	for megaco@ietf.org; Fri, 30 Jan 2004 03:49:06 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmUKG-0005Us-00
	for megaco@ietf.org; Fri, 30 Jan 2004 03:48:32 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0U8m1714808
	for <megaco@ietf.org>; Fri, 30 Jan 2004 03:48:02 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DXM05ZKF>; Fri, 30 Jan 2004 03:48:02 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E3EE9FD@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Samuel Tardieu <sam@rfc1149.net>, megaco@ietf.org
Subject: RE: [Megaco] Question on al/on(strict=state)
Date: Fri, 30 Jan 2004 03:48:02 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60

The Appendix is an example, and is subject to typos.  Please reference the
specification for the appropriate grammar.

Kevin 

-----Original Message-----
From: Samuel Tardieu [mailto:sam@rfc1149.net] 
Sent: Thursday, January 29, 2004 12:06 PM
To: megaco@ietf.org
Subject: [Megaco] Question on al/on(strict=state)

In step 3 of the example in Appendix I, there is:

  Events = 2222 {al/of(strict=state)}

Where does strict=state appear in the grammar? What kind of field is this? I
read that this is an EventDescriptor parameter earlier in the RFC, but in
this case shouldn't it appear between {} instead of ()?

  Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan 30 05:01:36 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05285
	for <megaco-archive@lists.ietf.org>; Fri, 30 Jan 2004 05:01:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmVST-0002P0-5v; Fri, 30 Jan 2004 05:01:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmVRR-0002Lq-BH
	for megaco@optimus.ietf.org; Fri, 30 Jan 2004 05:00:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05231
	for <megaco@ietf.org>; Fri, 30 Jan 2004 04:59:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmVRO-0006Df-00
	for megaco@ietf.org; Fri, 30 Jan 2004 04:59:58 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmVQS-00067g-00
	for megaco@ietf.org; Fri, 30 Jan 2004 04:59:01 -0500
Received: from marvin.enst.fr ([137.194.161.2] helo=mail.rfc1149.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmVPc-00061R-00
	for megaco@ietf.org; Fri, 30 Jan 2004 04:58:08 -0500
Received: from beeblebrox.rfc1149.net (beeblebrox-tun.enst.fr [137.194.161.40])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "beeblebrox.rfc1149.net", Issuer "Top-level signer" (verified OK))
	by mail.rfc1149.net (Postfix) with ESMTP
	id 7EBBAA80B1; Fri, 30 Jan 2004 10:58:01 +0100 (CET)
Received: by beeblebrox.rfc1149.net (Postfix, from userid 1000)
	id 8C5F03D6; Fri, 30 Jan 2004 10:58:00 +0100 (CET)
Date: Fri, 30 Jan 2004 10:58:00 +0100
To: Kevin Boyle <kboyle@nortelnetworks.com>
Cc: megaco@ietf.org
Subject: Re: [Megaco] Question on al/on(strict=state)
References: <ABA227A15B80D511BD1A00508BF93A1C0E3EE9FD@zrtpd0jq.us.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0E3EE9FD@zrtpd0jq.us.nortel.com>
User-Agent: Mutt/1.5.5.1i
From: Samuel Tardieu <sam@rfc1149.net>
Organization: RFC 1149 (see http://www.rfc1149.net/)
Precedence: special-delivery
X-WWW: http://www.rfc1149.net/sam
X-Mail-Processing: Sam's procmail tools
X-Jabber: <sam@amessage.de> (see http://www.jabber.org/)
X-OpenPGP-Fingerprint: 79C0 AE3C CEA8 F17B 0EF1  45A5 F133 2241 1B80 ADE6 (see http://www.gnupg.org/)
X-Sam-Laptop: yes
Message-Id: <2004-01-30-10-58-00+trackit+sam@rfc1149.net>
Content-Transfer-Encoding: quoted-printable
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

On 30/01, Kevin Boyle wrote:

| The Appendix is an example, and is subject to typos.  Please reference =
the
| specification for the appropriate grammar.

I understand that. However, why keep the appendix if its content is not
only not normative but also misleading because it is bogus?

  Sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan 30 05:03:40 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05355
	for <megaco-archive@odin.ietf.org>; Fri, 30 Jan 2004 05:03:40 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmVUW-0002dp-Lf
	for megaco-archive@odin.ietf.org; Fri, 30 Jan 2004 05:03:13 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UA3Ccw010152
	for megaco-archive@odin.ietf.org; Fri, 30 Jan 2004 05:03:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmVUV-0002dd-Mo
	for megaco-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 05:03:11 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05338
	for <megaco-web-archive@ietf.org>; Fri, 30 Jan 2004 05:03:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmVUS-0006dm-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 05:03:08 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmVTS-0006Tz-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 05:02:07 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmVSU-0006MA-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 05:01:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmVST-0002P0-5v; Fri, 30 Jan 2004 05:01:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmVRR-0002Lq-BH
	for megaco@optimus.ietf.org; Fri, 30 Jan 2004 05:00:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05231
	for <megaco@ietf.org>; Fri, 30 Jan 2004 04:59:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmVRO-0006Df-00
	for megaco@ietf.org; Fri, 30 Jan 2004 04:59:58 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmVQS-00067g-00
	for megaco@ietf.org; Fri, 30 Jan 2004 04:59:01 -0500
Received: from marvin.enst.fr ([137.194.161.2] helo=mail.rfc1149.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmVPc-00061R-00
	for megaco@ietf.org; Fri, 30 Jan 2004 04:58:08 -0500
Received: from beeblebrox.rfc1149.net (beeblebrox-tun.enst.fr [137.194.161.40])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "beeblebrox.rfc1149.net", Issuer "Top-level signer" (verified OK))
	by mail.rfc1149.net (Postfix) with ESMTP
	id 7EBBAA80B1; Fri, 30 Jan 2004 10:58:01 +0100 (CET)
Received: by beeblebrox.rfc1149.net (Postfix, from userid 1000)
	id 8C5F03D6; Fri, 30 Jan 2004 10:58:00 +0100 (CET)
Date: Fri, 30 Jan 2004 10:58:00 +0100
To: Kevin Boyle <kboyle@nortelnetworks.com>
Cc: megaco@ietf.org
Subject: Re: [Megaco] Question on al/on(strict=state)
References: <ABA227A15B80D511BD1A00508BF93A1C0E3EE9FD@zrtpd0jq.us.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0E3EE9FD@zrtpd0jq.us.nortel.com>
User-Agent: Mutt/1.5.5.1i
From: Samuel Tardieu <sam@rfc1149.net>
Organization: RFC 1149 (see http://www.rfc1149.net/)
Precedence: special-delivery
X-WWW: http://www.rfc1149.net/sam
X-Mail-Processing: Sam's procmail tools
X-Jabber: <sam@amessage.de> (see http://www.jabber.org/)
X-OpenPGP-Fingerprint: 79C0 AE3C CEA8 F17B 0EF1  45A5 F133 2241 1B80 ADE6 (see http://www.gnupg.org/)
X-Sam-Laptop: yes
Message-Id: <2004-01-30-10-58-00+trackit+sam@rfc1149.net>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

On 30/01, Kevin Boyle wrote:

| The Appendix is an example, and is subject to typos.  Please reference =
the
| specification for the appropriate grammar.

I understand that. However, why keep the appendix if its content is not
only not normative but also misleading because it is bogus?

  Sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan 30 05:07:33 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05557
	for <megaco-archive@lists.ietf.org>; Fri, 30 Jan 2004 05:07:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmVYF-0002xx-9J; Fri, 30 Jan 2004 05:07:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmVXO-0002tJ-SI
	for megaco@optimus.ietf.org; Fri, 30 Jan 2004 05:06:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05523
	for <megaco@ietf.org>; Fri, 30 Jan 2004 05:06:06 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmVXK-00074l-00
	for megaco@ietf.org; Fri, 30 Jan 2004 05:06:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmVWQ-0006xa-00
	for megaco@ietf.org; Fri, 30 Jan 2004 05:05:10 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmVVW-0006h7-00
	for megaco@ietf.org; Fri, 30 Jan 2004 05:04:14 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0UA3il18508
	for <megaco@ietf.org>; Fri, 30 Jan 2004 05:03:44 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DXM05ZMZ>; Fri, 30 Jan 2004 05:03:45 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E3EEA01@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Samuel Tardieu <sam@rfc1149.net>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Question on al/on(strict=state)
Date: Fri, 30 Jan 2004 05:03:44 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

I suggest that if you have problems with the Appendix that you bring a
contribution to the next SG16 meeting suggesting we correct it.  We do our
best trying to ensure the Appendix reflects the specification, but we have
been very busy in recent meetings, and instead of concentrating on
informative text we chose to concentrate on the normative text with the
limited time we had.

The whole point of informative text is that it is NOT BINDING.  Those who
are implementing H.248 would be well served to design their implementations
according to the text of the specification.

Kevin

-----Original Message-----
From: Samuel Tardieu [mailto:sam@rfc1149.net] 
Sent: Friday, January 30, 2004 4:58 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: megaco@ietf.org
Subject: Re: [Megaco] Question on al/on(strict=state)

On 30/01, Kevin Boyle wrote:

| The Appendix is an example, and is subject to typos.  Please reference 
| the specification for the appropriate grammar.

I understand that. However, why keep the appendix if its content is not only
not normative but also misleading because it is bogus?

  Sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan 30 05:09:37 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05692
	for <megaco-archive@odin.ietf.org>; Fri, 30 Jan 2004 05:09:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmVaF-0003GP-W2
	for megaco-archive@odin.ietf.org; Fri, 30 Jan 2004 05:09:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UA96ZN012521
	for megaco-archive@odin.ietf.org; Fri, 30 Jan 2004 05:09:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmVaC-0003Ff-E3
	for megaco-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 05:09:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05632
	for <megaco-web-archive@ietf.org>; Fri, 30 Jan 2004 05:09:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmVa9-0007Uz-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 05:09:01 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmVZD-0007Lq-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 05:08:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmVYF-0007CG-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 05:07:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmVYF-0002xx-9J; Fri, 30 Jan 2004 05:07:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmVXO-0002tJ-SI
	for megaco@optimus.ietf.org; Fri, 30 Jan 2004 05:06:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05523
	for <megaco@ietf.org>; Fri, 30 Jan 2004 05:06:06 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmVXK-00074l-00
	for megaco@ietf.org; Fri, 30 Jan 2004 05:06:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmVWQ-0006xa-00
	for megaco@ietf.org; Fri, 30 Jan 2004 05:05:10 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmVVW-0006h7-00
	for megaco@ietf.org; Fri, 30 Jan 2004 05:04:14 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0UA3il18508
	for <megaco@ietf.org>; Fri, 30 Jan 2004 05:03:44 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DXM05ZMZ>; Fri, 30 Jan 2004 05:03:45 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E3EEA01@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Samuel Tardieu <sam@rfc1149.net>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Question on al/on(strict=state)
Date: Fri, 30 Jan 2004 05:03:44 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60

I suggest that if you have problems with the Appendix that you bring a
contribution to the next SG16 meeting suggesting we correct it.  We do our
best trying to ensure the Appendix reflects the specification, but we have
been very busy in recent meetings, and instead of concentrating on
informative text we chose to concentrate on the normative text with the
limited time we had.

The whole point of informative text is that it is NOT BINDING.  Those who
are implementing H.248 would be well served to design their implementations
according to the text of the specification.

Kevin

-----Original Message-----
From: Samuel Tardieu [mailto:sam@rfc1149.net] 
Sent: Friday, January 30, 2004 4:58 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: megaco@ietf.org
Subject: Re: [Megaco] Question on al/on(strict=state)

On 30/01, Kevin Boyle wrote:

| The Appendix is an example, and is subject to typos.  Please reference 
| the specification for the appropriate grammar.

I understand that. However, why keep the appendix if its content is not only
not normative but also misleading because it is bogus?

  Sam


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan 30 06:31:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09693
	for <megaco-archive@lists.ietf.org>; Fri, 30 Jan 2004 06:31:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmWrX-0000En-0M; Fri, 30 Jan 2004 06:31:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmWqd-0000Bq-NG
	for megaco@optimus.ietf.org; Fri, 30 Jan 2004 06:30:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09651
	for <megaco@ietf.org>; Fri, 30 Jan 2004 06:30:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmWqZ-00032U-00
	for megaco@ietf.org; Fri, 30 Jan 2004 06:30:03 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmWpf-0002we-00
	for megaco@ietf.org; Fri, 30 Jan 2004 06:29:07 -0500
Received: from protext02.itu.ch ([156.106.192.19] helo=itu.ch)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmWpP-0002qE-01
	for megaco@ietf.org; Fri, 30 Jan 2004 06:28:51 -0500
Received: from protext02.exadir.itu.ch ([156.106.192.19]) by itu.ch with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 30 Jan 2004 12:28:24 +0100
Received: From mail6.itu.ch ([156.106.192.22]) by protext02.exadir.itu.ch (WebShield SMTP v4.5 MR1a);
	id 1075462103396; Fri, 30 Jan 2004 12:28:23 +0100
Received: from ericsson.com ([156.106.205.233])
	by mail6.itu.ch (8.12.10/8.12.10) with ESMTP id i0UBSMvD273148;
	Fri, 30 Jan 2004 12:28:22 +0100 (MET)
Message-ID: <401A3B8A.30706@ericsson.com>
Date: Fri, 30 Jan 2004 22:10:02 +1100
From: Christian Groves <Christian.Groves@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Samuel Tardieu <sam@rfc1149.net>
CC: Kevin Boyle <kboyle@nortelnetworks.com>, megaco@ietf.org
Subject: Re: [Megaco] Question on al/on(strict=state)
References: <ABA227A15B80D511BD1A00508BF93A1C0E3EEA01@zrtpd0jq.us.nortel.com>
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0E3EEA01@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Jan 2004 11:28:24.0193 (UTC) FILETIME=[2C246F10:01C3E724]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hello Sam,

Call Flows are informative. They are narrow focussed, do not reflect all 
implementations or all the information that is required. It is an impossible 
task to document all call flow scenarios. Any implementation that is based on 
informative calls flows is almost certainly "bogus".

Regards, Christian

Kevin Boyle wrote:

> I suggest that if you have problems with the Appendix that you bring a
> contribution to the next SG16 meeting suggesting we correct it.  We do our
> best trying to ensure the Appendix reflects the specification, but we have
> been very busy in recent meetings, and instead of concentrating on
> informative text we chose to concentrate on the normative text with the
> limited time we had.
> 
> The whole point of informative text is that it is NOT BINDING.  Those who
> are implementing H.248 would be well served to design their implementations
> according to the text of the specification.
> 
> Kevin
> 
> -----Original Message-----
> From: Samuel Tardieu [mailto:sam@rfc1149.net] 
> Sent: Friday, January 30, 2004 4:58 AM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Question on al/on(strict=state)
> 
> On 30/01, Kevin Boyle wrote:
> 
> | The Appendix is an example, and is subject to typos.  Please reference 
> | the specification for the appropriate grammar.
> 
> I understand that. However, why keep the appendix if its content is not only
> not normative but also misleading because it is bogus?
> 
>   Sam
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan 30 06:33:32 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09849
	for <megaco-archive@odin.ietf.org>; Fri, 30 Jan 2004 06:33:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmWtV-0000UN-Q1
	for megaco-archive@odin.ietf.org; Fri, 30 Jan 2004 06:33:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UBX5Fp001864
	for megaco-archive@odin.ietf.org; Fri, 30 Jan 2004 06:33:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmWtV-0000Tz-5r
	for megaco-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 06:33:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09738
	for <megaco-web-archive@ietf.org>; Fri, 30 Jan 2004 06:33:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmWtR-0003PG-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 06:33:01 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmWsT-0003Ej-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 06:32:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmWrU-00038C-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 06:31:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmWrX-0000En-0M; Fri, 30 Jan 2004 06:31:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmWqd-0000Bq-NG
	for megaco@optimus.ietf.org; Fri, 30 Jan 2004 06:30:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09651
	for <megaco@ietf.org>; Fri, 30 Jan 2004 06:30:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmWqZ-00032U-00
	for megaco@ietf.org; Fri, 30 Jan 2004 06:30:03 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmWpf-0002we-00
	for megaco@ietf.org; Fri, 30 Jan 2004 06:29:07 -0500
Received: from protext02.itu.ch ([156.106.192.19] helo=itu.ch)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmWpP-0002qE-01
	for megaco@ietf.org; Fri, 30 Jan 2004 06:28:51 -0500
Received: from protext02.exadir.itu.ch ([156.106.192.19]) by itu.ch with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 30 Jan 2004 12:28:24 +0100
Received: From mail6.itu.ch ([156.106.192.22]) by protext02.exadir.itu.ch (WebShield SMTP v4.5 MR1a);
	id 1075462103396; Fri, 30 Jan 2004 12:28:23 +0100
Received: from ericsson.com ([156.106.205.233])
	by mail6.itu.ch (8.12.10/8.12.10) with ESMTP id i0UBSMvD273148;
	Fri, 30 Jan 2004 12:28:22 +0100 (MET)
Message-ID: <401A3B8A.30706@ericsson.com>
Date: Fri, 30 Jan 2004 22:10:02 +1100
From: Christian Groves <Christian.Groves@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Samuel Tardieu <sam@rfc1149.net>
CC: Kevin Boyle <kboyle@nortelnetworks.com>, megaco@ietf.org
Subject: Re: [Megaco] Question on al/on(strict=state)
References: <ABA227A15B80D511BD1A00508BF93A1C0E3EEA01@zrtpd0jq.us.nortel.com>
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0E3EEA01@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Jan 2004 11:28:24.0193 (UTC) FILETIME=[2C246F10:01C3E724]
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello Sam,

Call Flows are informative. They are narrow focussed, do not reflect all 
implementations or all the information that is required. It is an impossible 
task to document all call flow scenarios. Any implementation that is based on 
informative calls flows is almost certainly "bogus".

Regards, Christian

Kevin Boyle wrote:

> I suggest that if you have problems with the Appendix that you bring a
> contribution to the next SG16 meeting suggesting we correct it.  We do our
> best trying to ensure the Appendix reflects the specification, but we have
> been very busy in recent meetings, and instead of concentrating on
> informative text we chose to concentrate on the normative text with the
> limited time we had.
> 
> The whole point of informative text is that it is NOT BINDING.  Those who
> are implementing H.248 would be well served to design their implementations
> according to the text of the specification.
> 
> Kevin
> 
> -----Original Message-----
> From: Samuel Tardieu [mailto:sam@rfc1149.net] 
> Sent: Friday, January 30, 2004 4:58 AM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Question on al/on(strict=state)
> 
> On 30/01, Kevin Boyle wrote:
> 
> | The Appendix is an example, and is subject to typos.  Please reference 
> | the specification for the appropriate grammar.
> 
> I understand that. However, why keep the appendix if its content is not only
> not normative but also misleading because it is bogus?
> 
>   Sam
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan 30 07:27:56 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09692
	for <megaco-archive@lists.ietf.org>; Fri, 30 Jan 2004 06:31:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmWrW-0000EL-6j; Fri, 30 Jan 2004 06:31:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmWqd-0000Bk-31
	for megaco@optimus.ietf.org; Fri, 30 Jan 2004 06:30:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09648
	for <megaco@ietf.org>; Fri, 30 Jan 2004 06:30:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmWqZ-00032P-00
	for megaco@ietf.org; Fri, 30 Jan 2004 06:30:03 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmWpe-0002wW-00
	for megaco@ietf.org; Fri, 30 Jan 2004 06:29:07 -0500
Received: from protext02.itu.ch ([156.106.192.19] helo=itu.ch)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmWpP-0002qE-00
	for megaco@ietf.org; Fri, 30 Jan 2004 06:28:51 -0500
Received: from protext02.exadir.itu.ch ([156.106.192.19]) by itu.ch with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 30 Jan 2004 12:28:21 +0100
Received: From mail6.itu.ch ([156.106.192.22]) by protext02.exadir.itu.ch (WebShield SMTP v4.5 MR1a);
	id 1075462096349; Fri, 30 Jan 2004 12:28:16 +0100
Received: from ericsson.com ([156.106.205.233])
	by mail6.itu.ch (8.12.10/8.12.10) with ESMTP id i0UBSFvD273361;
	Fri, 30 Jan 2004 12:28:15 +0100 (MET)
Message-ID: <401A381B.7060600@ericsson.com>
Date: Fri, 30 Jan 2004 21:55:23 +1100
From: Christian Groves <Christian.Groves@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sampathk@cisco.com
CC: megaco@ietf.org
Subject: Re: [Megaco] Provisioned events handling
References: <001f01c3e514$e4454f40$c80947ab@SAMPATHKW2K03>
In-Reply-To: <001f01c3e514$e4454f40$c80947ab@SAMPATHKW2K03>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Jan 2004 11:28:21.0411 (UTC) FILETIME=[2A7BEF30:01C3E724]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hello Sampath,

The Mg handling of provisioned events is exactly the same as normal events. A 
MGC will either be provisioned with knowledge (ie. request ID) of the 
provisioned event or it should be prepared to find out in an audit (which it 
should already be able to do). So that is why there's no fuss made over this in 
the specification. Please see my replies below [CHG].

Regards, Christian

Sampath Komanduri wrote:

> Hi all,
> Following the discussions on applicability of provisioned events, I 
> wanted to raised further questions on the handling of provisioned events 
> on MG and MGC.
>  
> On MG:
> 
>    1. Is it correct to assume that events as well as all the related
>       parameters can be provisioned on MG? Or are events should be
>       provisionable only with the default values (if package doesn't
>       specify the parameters of event to be provisionable on MG)?
[CHG] Yes
>    2. What should be MG's behavior, if MG specifies the same event with
>       same/different parameters? Does the MGC specified value take
>       preference?
>       Properties that are configurable on MG can be overwritten by MGC,
>       however if the user changes this configuration, it overrides the
>       MGC specified value. Should the handling of provisioned events and
>       related parameters be same?
[CHG] For read/write properties/events etc. the MGC always has the control to 
override.

>    3. Is MG supposed to stop playing of signals upon detection of
>       provisioned event on the termination? Since MGC may not be aware
>       of the fact that some event is provisioned on MG, handling the
>       provisioned event like handling of MGC requested events might
>       impact the call-flows (as seen and expected by MGC).
[CHG] Normal event handling takes place.

>    4. How should the event buffering supposed to work with the existence
>       of provisioned events on a termination? The event buffer mechanism
>       will be impacted if MGC ignores/rejects the provisioned event
>       notification. Similarly, in Case event buffering is going on and
>       provisioned event may not be reported to MGC, as this event will
>       not exist in the event buffer descriptor.
[CHG] Normal event buffering takes place.
> 
>  
> On MGC:
> 
>    1. After AUDITing a termination, if MGC finds that there are events
>       on the termination that it didn't request, what is it supposed to
>       do? Should the future commands to MG keep the presence of these
>       events on termination in mind?
[CHG] Yes
>    2. Assuming that MGC is aware of the fact that events are provisioned
>       on a termination on MG: Should the MGC take the same actions on
>       receiving notification of provisioned events as it would have upon
>       notification of event for an explicit request from MGC?
[CHG] Yes
> 
> Pls. respond.
> One form or the other, a final word (or section) on handling of 
> provisioned events in H.248 will be appreciated.
>  
> Thanks,
> Sampath



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan 30 07:27:57 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09850
	for <megaco-archive@odin.ietf.org>; Fri, 30 Jan 2004 06:33:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmWtV-0000Ui-VH
	for megaco-archive@odin.ietf.org; Fri, 30 Jan 2004 06:33:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UBX5P1001894
	for megaco-archive@odin.ietf.org; Fri, 30 Jan 2004 06:33:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmWtV-0000UT-Rn
	for megaco-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 06:33:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09741
	for <megaco-web-archive@ietf.org>; Fri, 30 Jan 2004 06:33:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmWtR-0003PM-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 06:33:01 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmWsU-0003Er-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 06:32:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmWrV-00038D-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 06:31:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmWrW-0000EL-6j; Fri, 30 Jan 2004 06:31:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmWqd-0000Bk-31
	for megaco@optimus.ietf.org; Fri, 30 Jan 2004 06:30:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09648
	for <megaco@ietf.org>; Fri, 30 Jan 2004 06:30:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmWqZ-00032P-00
	for megaco@ietf.org; Fri, 30 Jan 2004 06:30:03 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmWpe-0002wW-00
	for megaco@ietf.org; Fri, 30 Jan 2004 06:29:07 -0500
Received: from protext02.itu.ch ([156.106.192.19] helo=itu.ch)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmWpP-0002qE-00
	for megaco@ietf.org; Fri, 30 Jan 2004 06:28:51 -0500
Received: from protext02.exadir.itu.ch ([156.106.192.19]) by itu.ch with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 30 Jan 2004 12:28:21 +0100
Received: From mail6.itu.ch ([156.106.192.22]) by protext02.exadir.itu.ch (WebShield SMTP v4.5 MR1a);
	id 1075462096349; Fri, 30 Jan 2004 12:28:16 +0100
Received: from ericsson.com ([156.106.205.233])
	by mail6.itu.ch (8.12.10/8.12.10) with ESMTP id i0UBSFvD273361;
	Fri, 30 Jan 2004 12:28:15 +0100 (MET)
Message-ID: <401A381B.7060600@ericsson.com>
Date: Fri, 30 Jan 2004 21:55:23 +1100
From: Christian Groves <Christian.Groves@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sampathk@cisco.com
CC: megaco@ietf.org
Subject: Re: [Megaco] Provisioned events handling
References: <001f01c3e514$e4454f40$c80947ab@SAMPATHKW2K03>
In-Reply-To: <001f01c3e514$e4454f40$c80947ab@SAMPATHKW2K03>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Jan 2004 11:28:21.0411 (UTC) FILETIME=[2A7BEF30:01C3E724]
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello Sampath,

The Mg handling of provisioned events is exactly the same as normal events. A 
MGC will either be provisioned with knowledge (ie. request ID) of the 
provisioned event or it should be prepared to find out in an audit (which it 
should already be able to do). So that is why there's no fuss made over this in 
the specification. Please see my replies below [CHG].

Regards, Christian

Sampath Komanduri wrote:

> Hi all,
> Following the discussions on applicability of provisioned events, I 
> wanted to raised further questions on the handling of provisioned events 
> on MG and MGC.
>  
> On MG:
> 
>    1. Is it correct to assume that events as well as all the related
>       parameters can be provisioned on MG? Or are events should be
>       provisionable only with the default values (if package doesn't
>       specify the parameters of event to be provisionable on MG)?
[CHG] Yes
>    2. What should be MG's behavior, if MG specifies the same event with
>       same/different parameters? Does the MGC specified value take
>       preference?
>       Properties that are configurable on MG can be overwritten by MGC,
>       however if the user changes this configuration, it overrides the
>       MGC specified value. Should the handling of provisioned events and
>       related parameters be same?
[CHG] For read/write properties/events etc. the MGC always has the control to 
override.

>    3. Is MG supposed to stop playing of signals upon detection of
>       provisioned event on the termination? Since MGC may not be aware
>       of the fact that some event is provisioned on MG, handling the
>       provisioned event like handling of MGC requested events might
>       impact the call-flows (as seen and expected by MGC).
[CHG] Normal event handling takes place.

>    4. How should the event buffering supposed to work with the existence
>       of provisioned events on a termination? The event buffer mechanism
>       will be impacted if MGC ignores/rejects the provisioned event
>       notification. Similarly, in Case event buffering is going on and
>       provisioned event may not be reported to MGC, as this event will
>       not exist in the event buffer descriptor.
[CHG] Normal event buffering takes place.
> 
>  
> On MGC:
> 
>    1. After AUDITing a termination, if MGC finds that there are events
>       on the termination that it didn't request, what is it supposed to
>       do? Should the future commands to MG keep the presence of these
>       events on termination in mind?
[CHG] Yes
>    2. Assuming that MGC is aware of the fact that events are provisioned
>       on a termination on MG: Should the MGC take the same actions on
>       receiving notification of provisioned events as it would have upon
>       notification of event for an explicit request from MGC?
[CHG] Yes
> 
> Pls. respond.
> One form or the other, a final word (or section) on handling of 
> provisioned events in H.248 will be appreciated.
>  
> Thanks,
> Sampath



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan 30 11:15:33 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23897
	for <megaco-archive@lists.ietf.org>; Fri, 30 Jan 2004 11:15:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmbIO-0000pH-8d; Fri, 30 Jan 2004 11:15:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmbHf-0000Zw-Dv
	for megaco@optimus.ietf.org; Fri, 30 Jan 2004 11:14:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23874
	for <megaco@ietf.org>; Fri, 30 Jan 2004 11:14:16 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmbHe-0000iz-00
	for megaco@ietf.org; Fri, 30 Jan 2004 11:14:18 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmbGm-0000bx-00
	for megaco@ietf.org; Fri, 30 Jan 2004 11:13:24 -0500
Received: from ext-proxy-1.ftel.co.uk ([192.65.220.99])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmbG4-0000MK-00
	for megaco@ietf.org; Fri, 30 Jan 2004 11:12:40 -0500
Received: from utility-1.ftel.co.uk (utility-1.ftel.co.uk [193.112.172.10])
	by ext-proxy-1.ftel.co.uk (8.12.10/8.12.9/Revision:1.91/relay-in/ssl/db) with ESMTP id i0UGBvXi014543;
	Fri, 30 Jan 2004 16:11:57 GMT
Received: from DALLAPTOP (dhcp-172-16-48-64.ftel.co.uk [172.16.48.64])
	by utility-1.ftel.co.uk (8.12.9+Sun/8.12.9/Revision:1.90/db) with SMTP id i0UGBoNk002769;
	Fri, 30 Jan 2004 16:11:51 GMT
Message-ID: <005201c3e74b$c597cfd0$403010ac@DALLAPTOP>
From: "Dal Chohan" <D.Chohan@ftel.co.uk>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>,
        "Troy Cauble" <troy@bell-labs.com>
Cc: <megaco@ietf.org>
References: <ABA227A15B80D511BD1A00508BF93A1C0E3EE9FC@zrtpd0jq.us.nortel.com>
Subject: Re: [Megaco] Re: Mandatory serviceChangeReason parameter?
Date: Fri, 30 Jan 2004 16:11:48 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Kevin,

A point for clarification on this email - I assume that the first two flows
in Appendix I (i.e. ServiceChange Comand and the Service Change Reply) will
still specify "MEGACO/1".

By the clause 11.3 does not explicitly state that the "Service Change Reply"
should also be encoded as version 1. It would be useful to make this clear
in the procedures of clause 11.3.


Regards,


Dal Chohan


----- Original Message ----- 
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: "Troy Cauble" <troy@bell-labs.com>
Cc: <megaco@ietf.org>
Sent: Friday, January 30, 2004 8:47 AM
Subject: RE: [Megaco] Re: Mandatory serviceChangeReason parameter?


> Thanks.  I will bring these up as editorial issues with the TSB so that
> these are corrected in the published version.
>
> Kevin
>
> -----Original Message-----
> From: Troy Cauble [mailto:troy@bell-labs.com]
> Sent: Thursday, January 29, 2004 3:07 PM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Re: Mandatory serviceChangeReason parameter?
>
> Kevin Boyle wrote:
>
> > The Corrigendum for V2 has gone for consent.  If there are no
> > objections, I will enter this as the first item in the new IG which
> > would get Approved in November.
> >
> > Kevin
>
>
> Kevin,
>
> Here are some typos I posted recently that should be addressed as well.
>
> > I was reading the V2 doc and spotted the following minor items...
> >
> > In Annex B, auditItem was added to serviceChangeParm.  The
> > at-most-once comment doesn't really apply to auditItem; possibly to
> > the elements of auditItem.
> >
> > In Annex B, where indAudterminationAudit was added to X there's a typo
> > -- an extra paren.
> >
> > In Annex A, where comments discuss "X-" and "X+", there's a
> > typo/problem with the "-".
> >
> > In Appendix I, the call flow examples all show "MEGACO/1"
> > instead of "MEGACO/2".  Also the registration ServiceChange message
> > does not use the mandatory ServiceChangeVersion param.
> >
> >   (From 11.3: "A ServiceChange command from a MG that registers
> >   with an MGC shall contain the version number of the protocol
> >   supported by the MG in the ServiceChangeVersion parameter.")
> >
> > -troy
>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan 30 11:17:44 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24036
	for <megaco-archive@odin.ietf.org>; Fri, 30 Jan 2004 11:17:44 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmbKU-0004Bv-42
	for megaco-archive@odin.ietf.org; Fri, 30 Jan 2004 11:17:16 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UGHEjF016107
	for megaco-archive@odin.ietf.org; Fri, 30 Jan 2004 11:17:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmbKU-0004Bi-0h
	for megaco-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 11:17:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24014
	for <megaco-web-archive@ietf.org>; Fri, 30 Jan 2004 11:17:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmbKT-00014F-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 11:17:13 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmbJU-0000wm-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 11:16:13 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmbIh-0000kK-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 11:15:23 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmbIO-0000pH-8d; Fri, 30 Jan 2004 11:15:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmbHf-0000Zw-Dv
	for megaco@optimus.ietf.org; Fri, 30 Jan 2004 11:14:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23874
	for <megaco@ietf.org>; Fri, 30 Jan 2004 11:14:16 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmbHe-0000iz-00
	for megaco@ietf.org; Fri, 30 Jan 2004 11:14:18 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmbGm-0000bx-00
	for megaco@ietf.org; Fri, 30 Jan 2004 11:13:24 -0500
Received: from ext-proxy-1.ftel.co.uk ([192.65.220.99])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmbG4-0000MK-00
	for megaco@ietf.org; Fri, 30 Jan 2004 11:12:40 -0500
Received: from utility-1.ftel.co.uk (utility-1.ftel.co.uk [193.112.172.10])
	by ext-proxy-1.ftel.co.uk (8.12.10/8.12.9/Revision:1.91/relay-in/ssl/db) with ESMTP id i0UGBvXi014543;
	Fri, 30 Jan 2004 16:11:57 GMT
Received: from DALLAPTOP (dhcp-172-16-48-64.ftel.co.uk [172.16.48.64])
	by utility-1.ftel.co.uk (8.12.9+Sun/8.12.9/Revision:1.90/db) with SMTP id i0UGBoNk002769;
	Fri, 30 Jan 2004 16:11:51 GMT
Message-ID: <005201c3e74b$c597cfd0$403010ac@DALLAPTOP>
From: "Dal Chohan" <D.Chohan@ftel.co.uk>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>,
        "Troy Cauble" <troy@bell-labs.com>
Cc: <megaco@ietf.org>
References: <ABA227A15B80D511BD1A00508BF93A1C0E3EE9FC@zrtpd0jq.us.nortel.com>
Subject: Re: [Megaco] Re: Mandatory serviceChangeReason parameter?
Date: Fri, 30 Jan 2004 16:11:48 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Kevin,

A point for clarification on this email - I assume that the first two flows
in Appendix I (i.e. ServiceChange Comand and the Service Change Reply) will
still specify "MEGACO/1".

By the clause 11.3 does not explicitly state that the "Service Change Reply"
should also be encoded as version 1. It would be useful to make this clear
in the procedures of clause 11.3.


Regards,


Dal Chohan


----- Original Message ----- 
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: "Troy Cauble" <troy@bell-labs.com>
Cc: <megaco@ietf.org>
Sent: Friday, January 30, 2004 8:47 AM
Subject: RE: [Megaco] Re: Mandatory serviceChangeReason parameter?


> Thanks.  I will bring these up as editorial issues with the TSB so that
> these are corrected in the published version.
>
> Kevin
>
> -----Original Message-----
> From: Troy Cauble [mailto:troy@bell-labs.com]
> Sent: Thursday, January 29, 2004 3:07 PM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Re: Mandatory serviceChangeReason parameter?
>
> Kevin Boyle wrote:
>
> > The Corrigendum for V2 has gone for consent.  If there are no
> > objections, I will enter this as the first item in the new IG which
> > would get Approved in November.
> >
> > Kevin
>
>
> Kevin,
>
> Here are some typos I posted recently that should be addressed as well.
>
> > I was reading the V2 doc and spotted the following minor items...
> >
> > In Annex B, auditItem was added to serviceChangeParm.  The
> > at-most-once comment doesn't really apply to auditItem; possibly to
> > the elements of auditItem.
> >
> > In Annex B, where indAudterminationAudit was added to X there's a typo
> > -- an extra paren.
> >
> > In Annex A, where comments discuss "X-" and "X+", there's a
> > typo/problem with the "-".
> >
> > In Appendix I, the call flow examples all show "MEGACO/1"
> > instead of "MEGACO/2".  Also the registration ServiceChange message
> > does not use the mandatory ServiceChangeVersion param.
> >
> >   (From 11.3: "A ServiceChange command from a MG that registers
> >   with an MGC shall contain the version number of the protocol
> >   supported by the MG in the ServiceChangeVersion parameter.")
> >
> > -troy
>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan 30 11:29:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24815
	for <megaco-archive@lists.ietf.org>; Fri, 30 Jan 2004 11:29:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmbVu-0005ss-RX; Fri, 30 Jan 2004 11:29:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmbVE-0005qz-BM
	for megaco@optimus.ietf.org; Fri, 30 Jan 2004 11:28:20 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24726
	for <megaco@ietf.org>; Fri, 30 Jan 2004 11:28:17 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmbVD-0002Yu-00
	for megaco@ietf.org; Fri, 30 Jan 2004 11:28:19 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmbUQ-0002QL-00
	for megaco@ietf.org; Fri, 30 Jan 2004 11:27:31 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmbTZ-000290-00
	for megaco@ietf.org; Fri, 30 Jan 2004 11:26:37 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0UGQ5X06818
	for <megaco@ietf.org>; Fri, 30 Jan 2004 11:26:05 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DXM06B45>; Fri, 30 Jan 2004 11:26:05 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E3EF3D6@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Dal Chohan <D.Chohan@ftel.co.uk>, Troy Cauble <troy@bell-labs.com>,
        Samuel Tardieu <sam@rfc1149.net>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Re: Mandatory serviceChangeReason parameter?
Date: Fri, 30 Jan 2004 11:26:05 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

I have submitted the changes mentioned by Troy and Samuel as last-second
editorial revisions to the TSB.  It is now too late to make any changes to
the Corrigendum as it has Consented.

I can affirm that the first two messages in the example flow start MEGACO/1,
in compliance with the registration and version negotiation procedures.

Kevin

-----Original Message-----
From: Dal Chohan [mailto:D.Chohan@ftel.co.uk] 
Sent: Friday, January 30, 2004 11:12 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Troy Cauble
Cc: megaco@ietf.org
Subject: Re: [Megaco] Re: Mandatory serviceChangeReason parameter?

Kevin,

A point for clarification on this email - I assume that the first two flows
in Appendix I (i.e. ServiceChange Comand and the Service Change Reply) will
still specify "MEGACO/1".

By the clause 11.3 does not explicitly state that the "Service Change Reply"
should also be encoded as version 1. It would be useful to make this clear
in the procedures of clause 11.3.


Regards,


Dal Chohan


----- Original Message -----
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: "Troy Cauble" <troy@bell-labs.com>
Cc: <megaco@ietf.org>
Sent: Friday, January 30, 2004 8:47 AM
Subject: RE: [Megaco] Re: Mandatory serviceChangeReason parameter?


> Thanks.  I will bring these up as editorial issues with the TSB so that
> these are corrected in the published version.
>
> Kevin
>
> -----Original Message-----
> From: Troy Cauble [mailto:troy@bell-labs.com]
> Sent: Thursday, January 29, 2004 3:07 PM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Re: Mandatory serviceChangeReason parameter?
>
> Kevin Boyle wrote:
>
> > The Corrigendum for V2 has gone for consent.  If there are no
> > objections, I will enter this as the first item in the new IG which
> > would get Approved in November.
> >
> > Kevin
>
>
> Kevin,
>
> Here are some typos I posted recently that should be addressed as well.
>
> > I was reading the V2 doc and spotted the following minor items...
> >
> > In Annex B, auditItem was added to serviceChangeParm.  The
> > at-most-once comment doesn't really apply to auditItem; possibly to
> > the elements of auditItem.
> >
> > In Annex B, where indAudterminationAudit was added to X there's a typo
> > -- an extra paren.
> >
> > In Annex A, where comments discuss "X-" and "X+", there's a
> > typo/problem with the "-".
> >
> > In Appendix I, the call flow examples all show "MEGACO/1"
> > instead of "MEGACO/2".  Also the registration ServiceChange message
> > does not use the mandatory ServiceChangeVersion param.
> >
> >   (From 11.3: "A ServiceChange command from a MG that registers
> >   with an MGC shall contain the version number of the protocol
> >   supported by the MG in the ServiceChangeVersion parameter.")
> >
> > -troy
>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan 30 11:31:00 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24959
	for <megaco-archive@odin.ietf.org>; Fri, 30 Jan 2004 11:31:00 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmbXM-0006hP-7J
	for megaco-archive@odin.ietf.org; Fri, 30 Jan 2004 11:30:32 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UGUW8a025750
	for megaco-archive@odin.ietf.org; Fri, 30 Jan 2004 11:30:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmbXM-0006hF-3W
	for megaco-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 11:30:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24944
	for <megaco-web-archive@ietf.org>; Fri, 30 Jan 2004 11:30:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmbXL-0002tc-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 11:30:31 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmbWS-0002kg-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 11:29:37 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmbVu-0002bh-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 11:29:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmbVu-0005ss-RX; Fri, 30 Jan 2004 11:29:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmbVE-0005qz-BM
	for megaco@optimus.ietf.org; Fri, 30 Jan 2004 11:28:20 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24726
	for <megaco@ietf.org>; Fri, 30 Jan 2004 11:28:17 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmbVD-0002Yu-00
	for megaco@ietf.org; Fri, 30 Jan 2004 11:28:19 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmbUQ-0002QL-00
	for megaco@ietf.org; Fri, 30 Jan 2004 11:27:31 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmbTZ-000290-00
	for megaco@ietf.org; Fri, 30 Jan 2004 11:26:37 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0UGQ5X06818
	for <megaco@ietf.org>; Fri, 30 Jan 2004 11:26:05 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DXM06B45>; Fri, 30 Jan 2004 11:26:05 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0E3EF3D6@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Dal Chohan <D.Chohan@ftel.co.uk>, Troy Cauble <troy@bell-labs.com>,
        Samuel Tardieu <sam@rfc1149.net>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Re: Mandatory serviceChangeReason parameter?
Date: Fri, 30 Jan 2004 11:26:05 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60

I have submitted the changes mentioned by Troy and Samuel as last-second
editorial revisions to the TSB.  It is now too late to make any changes to
the Corrigendum as it has Consented.

I can affirm that the first two messages in the example flow start MEGACO/1,
in compliance with the registration and version negotiation procedures.

Kevin

-----Original Message-----
From: Dal Chohan [mailto:D.Chohan@ftel.co.uk] 
Sent: Friday, January 30, 2004 11:12 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Troy Cauble
Cc: megaco@ietf.org
Subject: Re: [Megaco] Re: Mandatory serviceChangeReason parameter?

Kevin,

A point for clarification on this email - I assume that the first two flows
in Appendix I (i.e. ServiceChange Comand and the Service Change Reply) will
still specify "MEGACO/1".

By the clause 11.3 does not explicitly state that the "Service Change Reply"
should also be encoded as version 1. It would be useful to make this clear
in the procedures of clause 11.3.


Regards,


Dal Chohan


----- Original Message -----
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: "Troy Cauble" <troy@bell-labs.com>
Cc: <megaco@ietf.org>
Sent: Friday, January 30, 2004 8:47 AM
Subject: RE: [Megaco] Re: Mandatory serviceChangeReason parameter?


> Thanks.  I will bring these up as editorial issues with the TSB so that
> these are corrected in the published version.
>
> Kevin
>
> -----Original Message-----
> From: Troy Cauble [mailto:troy@bell-labs.com]
> Sent: Thursday, January 29, 2004 3:07 PM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Re: Mandatory serviceChangeReason parameter?
>
> Kevin Boyle wrote:
>
> > The Corrigendum for V2 has gone for consent.  If there are no
> > objections, I will enter this as the first item in the new IG which
> > would get Approved in November.
> >
> > Kevin
>
>
> Kevin,
>
> Here are some typos I posted recently that should be addressed as well.
>
> > I was reading the V2 doc and spotted the following minor items...
> >
> > In Annex B, auditItem was added to serviceChangeParm.  The
> > at-most-once comment doesn't really apply to auditItem; possibly to
> > the elements of auditItem.
> >
> > In Annex B, where indAudterminationAudit was added to X there's a typo
> > -- an extra paren.
> >
> > In Annex A, where comments discuss "X-" and "X+", there's a
> > typo/problem with the "-".
> >
> > In Appendix I, the call flow examples all show "MEGACO/1"
> > instead of "MEGACO/2".  Also the registration ServiceChange message
> > does not use the mandatory ServiceChangeVersion param.
> >
> >   (From 11.3: "A ServiceChange command from a MG that registers
> >   with an MGC shall contain the version number of the protocol
> >   supported by the MG in the ServiceChangeVersion parameter.")
> >
> > -troy
>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Jan 30 11:59:29 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27890
	for <megaco-archive@lists.ietf.org>; Fri, 30 Jan 2004 11:59:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ambyv-0001m1-1r; Fri, 30 Jan 2004 11:59:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmbyE-0001kf-3a
	for megaco@optimus.ietf.org; Fri, 30 Jan 2004 11:58:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27818
	for <megaco@ietf.org>; Fri, 30 Jan 2004 11:58:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmbyC-0007HE-00
	for megaco@ietf.org; Fri, 30 Jan 2004 11:58:16 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmbxH-000788-00
	for megaco@ietf.org; Fri, 30 Jan 2004 11:57:21 -0500
Received: from ext-proxy-2.ftel.co.uk ([192.65.220.98])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmbwN-0006sp-00
	for megaco@ietf.org; Fri, 30 Jan 2004 11:56:23 -0500
Received: from utility-1.ftel.co.uk (utility-1.ftel.co.uk [193.112.172.10])
	by ext-proxy-2.ftel.co.uk (8.12.10/8.12.9/Revision:1.91/relay-in/ssl/db) with ESMTP id i0UGtfMu013721;
	Fri, 30 Jan 2004 16:55:42 GMT
Received: from DALLAPTOP (dhcp-172-16-48-64.ftel.co.uk [172.16.48.64])
	by utility-1.ftel.co.uk (8.12.9+Sun/8.12.9/Revision:1.90/db) with SMTP id i0UGtZNk004198;
	Fri, 30 Jan 2004 16:55:36 GMT
Message-ID: <006101c3e751$e20ff650$403010ac@DALLAPTOP>
From: "Dal Chohan" <D.Chohan@ftel.co.uk>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>,
        "Troy Cauble" <troy@bell-labs.com>, "Samuel Tardieu" <sam@rfc1149.net>
Cc: <megaco@ietf.org>
References: <ABA227A15B80D511BD1A00508BF93A1C0E3EF3D6@zrtpd0jq.us.nortel.com>
Subject: Re: [Megaco] Re: Mandatory serviceChangeReason parameter?
Date: Fri, 30 Jan 2004 16:55:33 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_005E_01C3E751.E0459690"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE 
	autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_005E_01C3E751.E0459690
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: [Megaco] Re: Mandatory serviceChangeReason parameter?In the next IG =
do you plan to modify clause 11.3 to specify that the "Service Change =
Reply"  should also be encoded as version 1.=20

Dal Chohan



----- Original Message -----=20
  From: Kevin Boyle=20
  To: Dal Chohan ; Troy Cauble ; Samuel Tardieu=20
  Cc: megaco@ietf.org=20
  Sent: Friday, January 30, 2004 4:26 PM
  Subject: RE: [Megaco] Re: Mandatory serviceChangeReason parameter?


  I have submitted the changes mentioned by Troy and Samuel as =
last-second editorial revisions to the TSB.  It is now too late to make =
any changes to the Corrigendum as it has Consented.

  I can affirm that the first two messages in the example flow start =
MEGACO/1, in compliance with the registration and version negotiation =
procedures.

  Kevin=20

  -----Original Message-----=20
  From: Dal Chohan [mailto:D.Chohan@ftel.co.uk]=20
  Sent: Friday, January 30, 2004 11:12 AM=20
  To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Troy Cauble=20
  Cc: megaco@ietf.org=20
  Subject: Re: [Megaco] Re: Mandatory serviceChangeReason parameter?=20

  Kevin,=20

  A point for clarification on this email - I assume that the first two =
flows in Appendix I (i.e. ServiceChange Comand and the Service Change =
Reply) will still specify "MEGACO/1".

  By the clause 11.3 does not explicitly state that the "Service Change =
Reply"=20
  should also be encoded as version 1. It would be useful to make this =
clear in the procedures of clause 11.3.=20



  Regards,=20



  Dal Chohan=20



  ----- Original Message -----=20
  From: "Kevin Boyle" <kboyle@nortelnetworks.com>=20
  To: "Troy Cauble" <troy@bell-labs.com>=20
  Cc: <megaco@ietf.org>=20
  Sent: Friday, January 30, 2004 8:47 AM=20
  Subject: RE: [Megaco] Re: Mandatory serviceChangeReason parameter?=20



  > Thanks.  I will bring these up as editorial issues with the TSB so =
that=20
  > these are corrected in the published version.=20
  >=20
  > Kevin=20
  >=20
  > -----Original Message-----=20
  > From: Troy Cauble [mailto:troy@bell-labs.com]=20
  > Sent: Thursday, January 29, 2004 3:07 PM=20
  > To: Boyle, Kevin [NCRTP:3Z40:EXCH]=20
  > Cc: megaco@ietf.org=20
  > Subject: Re: [Megaco] Re: Mandatory serviceChangeReason parameter?=20
  >=20
  > Kevin Boyle wrote:=20
  >=20
  > > The Corrigendum for V2 has gone for consent.  If there are no=20
  > > objections, I will enter this as the first item in the new IG =
which=20
  > > would get Approved in November.=20
  > >=20
  > > Kevin=20
  >=20
  >=20
  > Kevin,=20
  >=20
  > Here are some typos I posted recently that should be addressed as =
well.=20
  >=20
  > > I was reading the V2 doc and spotted the following minor items...=20
  > >=20
  > > In Annex B, auditItem was added to serviceChangeParm.  The=20
  > > at-most-once comment doesn't really apply to auditItem; possibly =
to=20
  > > the elements of auditItem.=20
  > >=20
  > > In Annex B, where indAudterminationAudit was added to X there's a =
typo=20
  > > -- an extra paren.=20
  > >=20
  > > In Annex A, where comments discuss "X-" and "X+", there's a=20
  > > typo/problem with the "-".=20
  > >=20
  > > In Appendix I, the call flow examples all show "MEGACO/1"=20
  > > instead of "MEGACO/2".  Also the registration ServiceChange =
message=20
  > > does not use the mandatory ServiceChangeVersion param.=20
  > >=20
  > >   (From 11.3: "A ServiceChange command from a MG that registers=20
  > >   with an MGC shall contain the version number of the protocol=20
  > >   supported by the MG in the ServiceChangeVersion parameter.")=20
  > >=20
  > > -troy=20
  >=20
  >=20
  >=20
  > _______________________________________________=20
  > Megaco mailing list=20
  > Megaco@ietf.org=20
  > https://www1.ietf.org/mailman/listinfo/megaco=20
  >=20

------=_NextPart_000_005E_01C3E751.E0459690
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [Megaco] Re: Mandatory serviceChangeReason =
parameter?</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>In the next IG do you plan&nbsp;<FONT =
size=3D2>to=20
modify clause 11.3 to specify that the "Service Change =
Reply"</FONT>&nbsp; <FONT=20
size=3D2>should also be encoded as version 1. </FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Dal Chohan</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>----- Original Message ----- </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dkboyle@nortelnetworks.com=20
  href=3D"mailto:kboyle@nortelnetworks.com">Kevin Boyle</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3DD.Chohan@ftel.co.uk=20
  href=3D"mailto:D.Chohan@ftel.co.uk">Dal Chohan</A> ; <A =
title=3Dtroy@bell-labs.com=20
  href=3D"mailto:troy@bell-labs.com">Troy Cauble</A> ; <A =
title=3Dsam@rfc1149.net=20
  href=3D"mailto:sam@rfc1149.net">Samuel Tardieu</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A title=3Dmegaco@ietf.org=20
  href=3D"mailto:megaco@ietf.org">megaco@ietf.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, January 30, 2004 =
4:26=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [Megaco] Re: =
Mandatory=20
  serviceChangeReason parameter?</DIV>
  <DIV><BR></DIV>
  <P><FONT size=3D2>I have submitted the changes mentioned by Troy and =
Samuel as=20
  last-second editorial revisions to the TSB.&nbsp; It is now too late =
to make=20
  any changes to the Corrigendum as it has Consented.</FONT></P>
  <P><FONT size=3D2>I can affirm that the first two messages in the =
example flow=20
  start MEGACO/1, in compliance with the registration and version =
negotiation=20
  procedures.</FONT></P>
  <P><FONT size=3D2>Kevin</FONT> </P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: Dal=20
  Chohan [<A =
href=3D"mailto:D.Chohan@ftel.co.uk">mailto:D.Chohan@ftel.co.uk</A>]=20
  </FONT><BR><FONT size=3D2>Sent: Friday, January 30, 2004 11:12 =
AM</FONT>=20
  <BR><FONT size=3D2>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Troy =
Cauble</FONT>=20
  <BR><FONT size=3D2>Cc: <A=20
  href=3D"mailto:megaco@ietf.org">megaco@ietf.org</A></FONT> <BR><FONT=20
  size=3D2>Subject: Re: [Megaco] Re: Mandatory serviceChangeReason=20
  parameter?</FONT> </P>
  <P><FONT size=3D2>Kevin,</FONT> </P>
  <P><FONT size=3D2>A point for clarification on this email - I assume =
that the=20
  first two flows in Appendix I (i.e. ServiceChange Comand and the =
Service=20
  Change Reply) will still specify "MEGACO/1".</FONT></P>
  <P><FONT size=3D2>By the clause 11.3 does not explicitly state that =
the "Service=20
  Change Reply"</FONT> <BR><FONT size=3D2>should also be encoded as =
version 1. It=20
  would be useful to make this clear in the procedures of clause =
11.3.</FONT>=20
  </P><BR>
  <P><FONT size=3D2>Regards,</FONT> </P><BR>
  <P><FONT size=3D2>Dal Chohan</FONT> </P><BR>
  <P><FONT size=3D2>----- Original Message -----</FONT> <BR><FONT =
size=3D2>From:=20
  "Kevin Boyle" &lt;kboyle@nortelnetworks.com&gt;</FONT> <BR><FONT =
size=3D2>To:=20
  "Troy Cauble" &lt;troy@bell-labs.com&gt;</FONT> <BR><FONT size=3D2>Cc: =

  &lt;megaco@ietf.org&gt;</FONT> <BR><FONT size=3D2>Sent: Friday, =
January 30, 2004=20
  8:47 AM</FONT> <BR><FONT size=3D2>Subject: RE: [Megaco] Re: Mandatory=20
  serviceChangeReason parameter?</FONT> </P><BR>
  <P><FONT size=3D2>&gt; Thanks.&nbsp; I will bring these up as =
editorial issues=20
  with the TSB so that</FONT> <BR><FONT size=3D2>&gt; these are =
corrected in the=20
  published version.</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  Kevin</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; =
-----Original=20
  Message-----</FONT> <BR><FONT size=3D2>&gt; From: Troy Cauble [<A=20
  =
href=3D"mailto:troy@bell-labs.com">mailto:troy@bell-labs.com</A>]</FONT> =

  <BR><FONT size=3D2>&gt; Sent: Thursday, January 29, 2004 3:07 =
PM</FONT>=20
  <BR><FONT size=3D2>&gt; To: Boyle, Kevin [NCRTP:3Z40:EXCH]</FONT> =
<BR><FONT=20
  size=3D2>&gt; Cc: megaco@ietf.org</FONT> <BR><FONT size=3D2>&gt; =
Subject: Re:=20
  [Megaco] Re: Mandatory serviceChangeReason parameter?</FONT> <BR><FONT =

  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; Kevin Boyle wrote:</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; The Corrigendum for =
V2 has gone=20
  for consent.&nbsp; If there are no</FONT> <BR><FONT size=3D2>&gt; &gt; =

  objections, I will enter this as the first item in the new IG =
which</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; would get Approved in November.</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; Kevin</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  Kevin,</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; =
Here are some=20
  typos I posted recently that should be addressed as well.</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; I was reading the V2 =
doc and=20
  spotted the following minor items...</FONT> <BR><FONT size=3D2>&gt; =
&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; In Annex B, auditItem was added to=20
  serviceChangeParm.&nbsp; The</FONT> <BR><FONT size=3D2>&gt; &gt; =
at-most-once=20
  comment doesn't really apply to auditItem; possibly to</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; the elements of auditItem.</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; In Annex B, where=20
  indAudterminationAudit was added to X there's a typo</FONT> <BR><FONT=20
  size=3D2>&gt; &gt; -- an extra paren.</FONT> <BR><FONT size=3D2>&gt; =
&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; In Annex A, where comments discuss "X-" =
and "X+",=20
  there's a</FONT> <BR><FONT size=3D2>&gt; &gt; typo/problem with the =
"-".</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; In =
Appendix I,=20
  the call flow examples all show "MEGACO/1"</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  instead of "MEGACO/2".&nbsp; Also the registration ServiceChange=20
  message</FONT> <BR><FONT size=3D2>&gt; &gt; does not use the mandatory =

  ServiceChangeVersion param.</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp;&nbsp; (From 11.3: "A ServiceChange command =
from a MG=20
  that registers</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;&nbsp; with an =
MGC shall=20
  contain the version number of the protocol</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp;&nbsp; supported by the MG in the ServiceChangeVersion=20
  parameter.")</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; -troy</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;</FONT>=20
  <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;=20
  _______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
  Megaco mailing list</FONT> <BR><FONT size=3D2>&gt; =
Megaco@ietf.org</FONT>=20
  <BR><FONT size=3D2>&gt; <A =
href=3D"https://www1.ietf.org/mailman/listinfo/megaco"=20
  =
target=3D_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> =

  <BR><FONT size=3D2>&gt;</FONT> </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_005E_01C3E751.E0459690--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From exim@www1.ietf.org  Fri Jan 30 12:00:56 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28009
	for <megaco-archive@odin.ietf.org>; Fri, 30 Jan 2004 12:00:56 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Amc0L-0002Kt-3c
	for megaco-archive@odin.ietf.org; Fri, 30 Jan 2004 12:00:29 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UH0TuC008969
	for megaco-archive@odin.ietf.org; Fri, 30 Jan 2004 12:00:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Amc0K-0002Ka-Up
	for megaco-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 12:00:28 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27971
	for <megaco-web-archive@ietf.org>; Fri, 30 Jan 2004 12:00:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Amc0J-0007a5-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 12:00:27 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmbzP-0007S2-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 11:59:33 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ambyv-0007Jo-00
	for megaco-web-archive@ietf.org; Fri, 30 Jan 2004 11:59:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ambyv-0001m1-1r; Fri, 30 Jan 2004 11:59:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AmbyE-0001kf-3a
	for megaco@optimus.ietf.org; Fri, 30 Jan 2004 11:58:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27818
	for <megaco@ietf.org>; Fri, 30 Jan 2004 11:58:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmbyC-0007HE-00
	for megaco@ietf.org; Fri, 30 Jan 2004 11:58:16 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AmbxH-000788-00
	for megaco@ietf.org; Fri, 30 Jan 2004 11:57:21 -0500
Received: from ext-proxy-2.ftel.co.uk ([192.65.220.98])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AmbwN-0006sp-00
	for megaco@ietf.org; Fri, 30 Jan 2004 11:56:23 -0500
Received: from utility-1.ftel.co.uk (utility-1.ftel.co.uk [193.112.172.10])
	by ext-proxy-2.ftel.co.uk (8.12.10/8.12.9/Revision:1.91/relay-in/ssl/db) with ESMTP id i0UGtfMu013721;
	Fri, 30 Jan 2004 16:55:42 GMT
Received: from DALLAPTOP (dhcp-172-16-48-64.ftel.co.uk [172.16.48.64])
	by utility-1.ftel.co.uk (8.12.9+Sun/8.12.9/Revision:1.90/db) with SMTP id i0UGtZNk004198;
	Fri, 30 Jan 2004 16:55:36 GMT
Message-ID: <006101c3e751$e20ff650$403010ac@DALLAPTOP>
From: "Dal Chohan" <D.Chohan@ftel.co.uk>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>,
        "Troy Cauble" <troy@bell-labs.com>, "Samuel Tardieu" <sam@rfc1149.net>
Cc: <megaco@ietf.org>
References: <ABA227A15B80D511BD1A00508BF93A1C0E3EF3D6@zrtpd0jq.us.nortel.com>
Subject: Re: [Megaco] Re: Mandatory serviceChangeReason parameter?
Date: Fri, 30 Jan 2004 16:55:33 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_005E_01C3E751.E0459690"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE 
	autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_005E_01C3E751.E0459690
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: [Megaco] Re: Mandatory serviceChangeReason parameter?In the next IG =
do you plan to modify clause 11.3 to specify that the "Service Change =
Reply"  should also be encoded as version 1.=20

Dal Chohan



----- Original Message -----=20
  From: Kevin Boyle=20
  To: Dal Chohan ; Troy Cauble ; Samuel Tardieu=20
  Cc: megaco@ietf.org=20
  Sent: Friday, January 30, 2004 4:26 PM
  Subject: RE: [Megaco] Re: Mandatory serviceChangeReason parameter?


  I have submitted the changes mentioned by Troy and Samuel as =
last-second editorial revisions to the TSB.  It is now too late to make =
any changes to the Corrigendum as it has Consented.

  I can affirm that the first two messages in the example flow start =
MEGACO/1, in compliance with the registration and version negotiation =
procedures.

  Kevin=20

  -----Original Message-----=20
  From: Dal Chohan [mailto:D.Chohan@ftel.co.uk]=20
  Sent: Friday, January 30, 2004 11:12 AM=20
  To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Troy Cauble=20
  Cc: megaco@ietf.org=20
  Subject: Re: [Megaco] Re: Mandatory serviceChangeReason parameter?=20

  Kevin,=20

  A point for clarification on this email - I assume that the first two =
flows in Appendix I (i.e. ServiceChange Comand and the Service Change =
Reply) will still specify "MEGACO/1".

  By the clause 11.3 does not explicitly state that the "Service Change =
Reply"=20
  should also be encoded as version 1. It would be useful to make this =
clear in the procedures of clause 11.3.=20



  Regards,=20



  Dal Chohan=20



  ----- Original Message -----=20
  From: "Kevin Boyle" <kboyle@nortelnetworks.com>=20
  To: "Troy Cauble" <troy@bell-labs.com>=20
  Cc: <megaco@ietf.org>=20
  Sent: Friday, January 30, 2004 8:47 AM=20
  Subject: RE: [Megaco] Re: Mandatory serviceChangeReason parameter?=20



  > Thanks.  I will bring these up as editorial issues with the TSB so =
that=20
  > these are corrected in the published version.=20
  >=20
  > Kevin=20
  >=20
  > -----Original Message-----=20
  > From: Troy Cauble [mailto:troy@bell-labs.com]=20
  > Sent: Thursday, January 29, 2004 3:07 PM=20
  > To: Boyle, Kevin [NCRTP:3Z40:EXCH]=20
  > Cc: megaco@ietf.org=20
  > Subject: Re: [Megaco] Re: Mandatory serviceChangeReason parameter?=20
  >=20
  > Kevin Boyle wrote:=20
  >=20
  > > The Corrigendum for V2 has gone for consent.  If there are no=20
  > > objections, I will enter this as the first item in the new IG =
which=20
  > > would get Approved in November.=20
  > >=20
  > > Kevin=20
  >=20
  >=20
  > Kevin,=20
  >=20
  > Here are some typos I posted recently that should be addressed as =
well.=20
  >=20
  > > I was reading the V2 doc and spotted the following minor items...=20
  > >=20
  > > In Annex B, auditItem was added to serviceChangeParm.  The=20
  > > at-most-once comment doesn't really apply to auditItem; possibly =
to=20
  > > the elements of auditItem.=20
  > >=20
  > > In Annex B, where indAudterminationAudit was added to X there's a =
typo=20
  > > -- an extra paren.=20
  > >=20
  > > In Annex A, where comments discuss "X-" and "X+", there's a=20
  > > typo/problem with the "-".=20
  > >=20
  > > In Appendix I, the call flow examples all show "MEGACO/1"=20
  > > instead of "MEGACO/2".  Also the registration ServiceChange =
message=20
  > > does not use the mandatory ServiceChangeVersion param.=20
  > >=20
  > >   (From 11.3: "A ServiceChange command from a MG that registers=20
  > >   with an MGC shall contain the version number of the protocol=20
  > >   supported by the MG in the ServiceChangeVersion parameter.")=20
  > >=20
  > > -troy=20
  >=20
  >=20
  >=20
  > _______________________________________________=20
  > Megaco mailing list=20
  > Megaco@ietf.org=20
  > https://www1.ietf.org/mailman/listinfo/megaco=20
  >=20

------=_NextPart_000_005E_01C3E751.E0459690
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [Megaco] Re: Mandatory serviceChangeReason =
parameter?</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>In the next IG do you plan&nbsp;<FONT =
size=3D2>to=20
modify clause 11.3 to specify that the "Service Change =
Reply"</FONT>&nbsp; <FONT=20
size=3D2>should also be encoded as version 1. </FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Dal Chohan</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>----- Original Message ----- </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dkboyle@nortelnetworks.com=20
  href=3D"mailto:kboyle@nortelnetworks.com">Kevin Boyle</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3DD.Chohan@ftel.co.uk=20
  href=3D"mailto:D.Chohan@ftel.co.uk">Dal Chohan</A> ; <A =
title=3Dtroy@bell-labs.com=20
  href=3D"mailto:troy@bell-labs.com">Troy Cauble</A> ; <A =
title=3Dsam@rfc1149.net=20
  href=3D"mailto:sam@rfc1149.net">Samuel Tardieu</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A title=3Dmegaco@ietf.org=20
  href=3D"mailto:megaco@ietf.org">megaco@ietf.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, January 30, 2004 =
4:26=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [Megaco] Re: =
Mandatory=20
  serviceChangeReason parameter?</DIV>
  <DIV><BR></DIV>
  <P><FONT size=3D2>I have submitted the changes mentioned by Troy and =
Samuel as=20
  last-second editorial revisions to the TSB.&nbsp; It is now too late =
to make=20
  any changes to the Corrigendum as it has Consented.</FONT></P>
  <P><FONT size=3D2>I can affirm that the first two messages in the =
example flow=20
  start MEGACO/1, in compliance with the registration and version =
negotiation=20
  procedures.</FONT></P>
  <P><FONT size=3D2>Kevin</FONT> </P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: Dal=20
  Chohan [<A =
href=3D"mailto:D.Chohan@ftel.co.uk">mailto:D.Chohan@ftel.co.uk</A>]=20
  </FONT><BR><FONT size=3D2>Sent: Friday, January 30, 2004 11:12 =
AM</FONT>=20
  <BR><FONT size=3D2>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Troy =
Cauble</FONT>=20
  <BR><FONT size=3D2>Cc: <A=20
  href=3D"mailto:megaco@ietf.org">megaco@ietf.org</A></FONT> <BR><FONT=20
  size=3D2>Subject: Re: [Megaco] Re: Mandatory serviceChangeReason=20
  parameter?</FONT> </P>
  <P><FONT size=3D2>Kevin,</FONT> </P>
  <P><FONT size=3D2>A point for clarification on this email - I assume =
that the=20
  first two flows in Appendix I (i.e. ServiceChange Comand and the =
Service=20
  Change Reply) will still specify "MEGACO/1".</FONT></P>
  <P><FONT size=3D2>By the clause 11.3 does not explicitly state that =
the "Service=20
  Change Reply"</FONT> <BR><FONT size=3D2>should also be encoded as =
version 1. It=20
  would be useful to make this clear in the procedures of clause =
11.3.</FONT>=20
  </P><BR>
  <P><FONT size=3D2>Regards,</FONT> </P><BR>
  <P><FONT size=3D2>Dal Chohan</FONT> </P><BR>
  <P><FONT size=3D2>----- Original Message -----</FONT> <BR><FONT =
size=3D2>From:=20
  "Kevin Boyle" &lt;kboyle@nortelnetworks.com&gt;</FONT> <BR><FONT =
size=3D2>To:=20
  "Troy Cauble" &lt;troy@bell-labs.com&gt;</FONT> <BR><FONT size=3D2>Cc: =

  &lt;megaco@ietf.org&gt;</FONT> <BR><FONT size=3D2>Sent: Friday, =
January 30, 2004=20
  8:47 AM</FONT> <BR><FONT size=3D2>Subject: RE: [Megaco] Re: Mandatory=20
  serviceChangeReason parameter?</FONT> </P><BR>
  <P><FONT size=3D2>&gt; Thanks.&nbsp; I will bring these up as =
editorial issues=20
  with the TSB so that</FONT> <BR><FONT size=3D2>&gt; these are =
corrected in the=20
  published version.</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  Kevin</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; =
-----Original=20
  Message-----</FONT> <BR><FONT size=3D2>&gt; From: Troy Cauble [<A=20
  =
href=3D"mailto:troy@bell-labs.com">mailto:troy@bell-labs.com</A>]</FONT> =

  <BR><FONT size=3D2>&gt; Sent: Thursday, January 29, 2004 3:07 =
PM</FONT>=20
  <BR><FONT size=3D2>&gt; To: Boyle, Kevin [NCRTP:3Z40:EXCH]</FONT> =
<BR><FONT=20
  size=3D2>&gt; Cc: megaco@ietf.org</FONT> <BR><FONT size=3D2>&gt; =
Subject: Re:=20
  [Megaco] Re: Mandatory serviceChangeReason parameter?</FONT> <BR><FONT =

  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; Kevin Boyle wrote:</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; The Corrigendum for =
V2 has gone=20
  for consent.&nbsp; If there are no</FONT> <BR><FONT size=3D2>&gt; &gt; =

  objections, I will enter this as the first item in the new IG =
which</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; would get Approved in November.</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; Kevin</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  Kevin,</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; =
Here are some=20
  typos I posted recently that should be addressed as well.</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; I was reading the V2 =
doc and=20
  spotted the following minor items...</FONT> <BR><FONT size=3D2>&gt; =
&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; In Annex B, auditItem was added to=20
  serviceChangeParm.&nbsp; The</FONT> <BR><FONT size=3D2>&gt; &gt; =
at-most-once=20
  comment doesn't really apply to auditItem; possibly to</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; the elements of auditItem.</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; In Annex B, where=20
  indAudterminationAudit was added to X there's a typo</FONT> <BR><FONT=20
  size=3D2>&gt; &gt; -- an extra paren.</FONT> <BR><FONT size=3D2>&gt; =
&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; In Annex A, where comments discuss "X-" =
and "X+",=20
  there's a</FONT> <BR><FONT size=3D2>&gt; &gt; typo/problem with the =
"-".</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; In =
Appendix I,=20
  the call flow examples all show "MEGACO/1"</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  instead of "MEGACO/2".&nbsp; Also the registration ServiceChange=20
  message</FONT> <BR><FONT size=3D2>&gt; &gt; does not use the mandatory =

  ServiceChangeVersion param.</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp;&nbsp; (From 11.3: "A ServiceChange command =
from a MG=20
  that registers</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;&nbsp; with an =
MGC shall=20
  contain the version number of the protocol</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp;&nbsp; supported by the MG in the ServiceChangeVersion=20
  parameter.")</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; -troy</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;</FONT>=20
  <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;=20
  _______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
  Megaco mailing list</FONT> <BR><FONT size=3D2>&gt; =
Megaco@ietf.org</FONT>=20
  <BR><FONT size=3D2>&gt; <A =
href=3D"https://www1.ietf.org/mailman/listinfo/megaco"=20
  =
target=3D_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> =

  <BR><FONT size=3D2>&gt;</FONT> </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_005E_01C3E751.E0459690--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco