From owner-megaco@fore.com Tue May 1 03:03:02 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21169 for ; Tue, 1 May 2001 03:03:02 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA25206; Tue, 1 May 2001 02:48:35 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA13394 for megaco-list; Tue, 1 May 2001 02:46:56 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA13387 for ; Tue, 1 May 2001 02:46:54 -0400 (EDT) Received: from smtp010.mail.yahoo.com (smtp010.mail.yahoo.com [216.136.173.30]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id CAA25097 for ; Tue, 1 May 2001 02:46:50 -0400 (EDT) Received: from unknown (HELO c294084b) (24.1.127.153) by smtp.mail.vip.sc5.yahoo.com with SMTP; 1 May 2001 06:46:52 -0000 X-Apparently-From: Message-ID: <006901c0d209$68966800$0200a8c0@c294084b> From: "Patrick Lam" To: , Subject: Any SS7/ISUP/BICC newsgroup or mailing list out there? Date: Mon, 30 Apr 2001 23:39:00 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0066_01C0D1CE.BB3BCAE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0066_01C0D1CE.BB3BCAE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all: Sorry that if this is not the right list to ask this question, but I = have tried so many things without success. Does anyone know of any SS7/ISUP/BICC focused ng or ml out there? Thanks very much in advance, Patrick. ------=_NextPart_000_0066_01C0D1CE.BB3BCAE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all:
 
Sorry that if this is not the right = list to ask=20 this question, but I have tried so many things without = success.
 
Does anyone know of any SS7/ISUP/BICC = focused ng or=20 ml out there?
 
Thanks very much in = advance,
 
Patrick.
------=_NextPart_000_0066_01C0D1CE.BB3BCAE0-- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-megaco@fore.com Tue May 1 07:22:11 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23083 for ; Tue, 1 May 2001 07:22:11 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA03493; Tue, 1 May 2001 07:09:34 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA02158 for megaco-list; Tue, 1 May 2001 07:02:05 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA02144 for ; Tue, 1 May 2001 07:02:03 -0400 (EDT) Received: from mail.bhartitelesoft.com ([202.56.229.147]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA03182 for ; Tue, 1 May 2001 07:01:52 -0400 (EDT) Received: from sarju (taquila [202.56.229.146]) by mail.bhartitelesoft.com (8.11.0/8.11.0) with SMTP id f41B1Yb05906 for ; Tue, 1 May 2001 16:31:36 +0530 Message-ID: <00df01c0d22a$96477a20$240310ac@bhartitelesoft.com> Reply-To: "Sarju Garg" From: "Sarju Garg" To: "'megaco'" Subject: How to get SPI Date: Tue, 1 May 2001 16:06:26 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DB_01C0D258.ACF58360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00DB_01C0D258.ACF58360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi List, My question is related to getting the SPI value in the Interim AH = security Header. There are two ways: 1. Is there any fixed value to be used for SPI for Interim AH or 2. The value is there in the SAD present in MGC and need to be = determined by MG while security association is created? Which one is used normally in implementations? If 2 is the case, how = (protocol messages) and when to create a security association? TIA Sarju ------=_NextPart_000_00DB_01C0D258.ACF58360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi List,
 
My question is related to getting the = SPI value in=20 the Interim AH security Header. There are two ways:
1. Is there any fixed value to be used = for SPI for=20 Interim AH  or
2. The value is there in the SAD = present in MGC and=20  need to be determined by MG while security association is=20 created?
 
Which one is used normally in = implementations? If 2=20 is the case, how (protocol messages) and when to create a security=20 association?
 
TIA
Sarju
------=_NextPart_000_00DB_01C0D258.ACF58360-- From owner-megaco@fore.com Tue May 1 08:35:15 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24626 for ; Tue, 1 May 2001 08:35:14 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA06467; Tue, 1 May 2001 08:19:00 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA09891 for megaco-list; Tue, 1 May 2001 08:16:22 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA09880 for ; Tue, 1 May 2001 08:16:21 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 08:16:14 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F505@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Long'" , megaco@fore.com Subject: RE: "Does anybody really know what time it is?" :-) Date: Tue, 1 May 2001 08:16:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Yes, I think a fixed timestamp is fine. Yes, you must deal with the other guy's notion of time being ahead or behind yours. When we get to "torture" tests, we should test time issues. Note that to make sensible event detection work, you need a nominally correct time increase (that is, whatever you start with, it needs to go up in approximately correct increments). Brian > -----Original Message----- > From: Paul Long [mailto:plong@ipdialog.com] > Sent: Monday, April 30, 2001 6:33 PM > To: megaco@fore.com > Subject: RE: "Does anybody really know what time it is?" :-) > > > Brian, > > Can't time be relative, as in RTP? > > 5.1/RFC1889: "The initial value of the timestamp is random..." > 6.3.1/RFC1889: "A sender that can keep track of elapsed time > but has no > notion of wallclock time may use the elapsed time since > joining the session > instead." > Moreover, 6.3.1/RFC1889: "A sender that has no notion of wallclock or > elapsed time may set the NTP timestamp to zero." Woohoo! :-) > > Since it is already unlikely that a received timestamp will > _exactly_ match > the receiving entity's clock at the time it is decoded--it'll > be off either > a few milliseconds, several minutes, or maybe several days if > the time was > simply set wrong--the receiver should probably apply a delta > to normalize > the time (if this is even important at all to the entity). > Therefore, why > can't we use a rule similar to the one in 6.3.1/RFC1889? For > example, the > timestamp in an MG's ServiceChange/Restart command could be > 20010101T00000000, and all subsequent timestamps reported by > the MG will be > relative to that. Otherwise, how can a lowly consumer device > know the time? > When was the last time you plugged in an analogue telephone > that wouldn't > work until you set the time? > > Hmmm... You know, it looks like we're already covered in this > regard. Take a > look at this passage from 7.2.8/H.248 (emphasis mine): "The optional > TimeStamp parameter specifies the actual time >>>as kept by > the sender<<<. > It can be used by the responder to determine how its notion of time > >>>differs<<< from that of its correspondent." So I think my > suggestion of > using an arbitrary beginning timestamp, e.g., > 20010101T00000000, completely > fulfills the requirement that "The TimeStamp parameter shall > be sent with a > registration command..." As a matter of fact, this may have > been what you > meant in your reply by "the MGs notion of time." > > Okay, the timestamp stays in! However, it's interesting to > note that we > weren't encoding a timestamp at the last interop, and none of the MGCs > complained. > > Paul Long > ipDialog, Inc. > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Monday, April 30, 2001 4:40 PM > To: 'Paul Long'; megaco@fore.com > Subject: RE: "Does anybody really know what time it is?" :-) > > > The MGC needs to know the MGs notion of time because network > time is not > constant, and things like timestamps for Notify are important. > > Nearly every gateway and phone I've looked at has a time of > day clock, YMMV. > > Brian > > > -----Original Message----- > > From: Paul Long [mailto:plong@ipdialog.com] > > Sent: Monday, April 30, 2001 2:40 PM > > To: megaco@fore.com > > Subject: "Does anybody really know what time it is?" :-) > > > > > > (Sorry about the possibly obscure reference in the Subject > > line to an old > > song by the band, Chicago.) > > > > I just noticed this requirement, and I have a rather big > > problem with it. > > Some MGs will not be maintaining a "wall clock," e.g., there > > will be no > > interface for the user to set the time or specify the current time > > zone--it's just a simple, lightweight telephone for Pete's > > sake--so how can > > such an MG satisfy this requirement? > > > > 7.2.8: "The TimeStamp parameter shall be sent with a registration > > command..." > > > > Can this requirement be relaxed to a "should?" Otherwise, an > > MG will have to > > contact some kind of UTC time server or require the user to > > configure it > > with the correct time before it can be used, neither of which > > are reasonable > > solutions, IMO. > > > > Paul Long > > ipDialog, Inc. > > > From owner-megaco@fore.com Tue May 1 08:51:22 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25046 for ; Tue, 1 May 2001 08:51:22 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA07998; Tue, 1 May 2001 08:38:58 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA13736 for megaco-list; Tue, 1 May 2001 08:36:31 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA13732 for ; Tue, 1 May 2001 08:36:30 -0400 (EDT) Received: from mail-lod.audiocodes.com ([212.143.19.162]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA07768 for ; Tue, 1 May 2001 08:36:24 -0400 (EDT) Received: by MAIL-LOD with Internet Mail Service (5.5.2653.19) id ; Tue, 1 May 2001 15:36:43 +0200 Message-ID: <3F2E96E0B800D511821E00306E062AE404BD1B@MAIL-LOD> From: Nurit Shenhar To: "'Megaco (E-mail)" Subject: RE: "Does anybody really know what time it is?" :-) Date: Tue, 1 May 2001 15:36:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi We had a discussion about the time issue at the second half of January 2001. (see subject: TimeStamp in registration replies). In this discussion we said that the TimeStamp should be added to the ServiceChangeReply, and can be used to set the MG clock according to the MGC clock. Was anything done about it? Nurit -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, May 01, 2001 2:16 PM To: 'Paul Long'; megaco@fore.com Subject: RE: "Does anybody really know what time it is?" :-) Yes, I think a fixed timestamp is fine. Yes, you must deal with the other guy's notion of time being ahead or behind yours. When we get to "torture" tests, we should test time issues. Note that to make sensible event detection work, you need a nominally correct time increase (that is, whatever you start with, it needs to go up in approximately correct increments). Brian > -----Original Message----- > From: Paul Long [mailto:plong@ipdialog.com] > Sent: Monday, April 30, 2001 6:33 PM > To: megaco@fore.com > Subject: RE: "Does anybody really know what time it is?" :-) > > > Brian, > > Can't time be relative, as in RTP? > > 5.1/RFC1889: "The initial value of the timestamp is random..." > 6.3.1/RFC1889: "A sender that can keep track of elapsed time > but has no > notion of wallclock time may use the elapsed time since > joining the session > instead." > Moreover, 6.3.1/RFC1889: "A sender that has no notion of wallclock or > elapsed time may set the NTP timestamp to zero." Woohoo! :-) > > Since it is already unlikely that a received timestamp will > _exactly_ match > the receiving entity's clock at the time it is decoded--it'll > be off either > a few milliseconds, several minutes, or maybe several days if > the time was > simply set wrong--the receiver should probably apply a delta > to normalize > the time (if this is even important at all to the entity). > Therefore, why > can't we use a rule similar to the one in 6.3.1/RFC1889? For > example, the > timestamp in an MG's ServiceChange/Restart command could be > 20010101T00000000, and all subsequent timestamps reported by > the MG will be > relative to that. Otherwise, how can a lowly consumer device > know the time? > When was the last time you plugged in an analogue telephone > that wouldn't > work until you set the time? > > Hmmm... You know, it looks like we're already covered in this > regard. Take a > look at this passage from 7.2.8/H.248 (emphasis mine): "The optional > TimeStamp parameter specifies the actual time >>>as kept by > the sender<<<. > It can be used by the responder to determine how its notion of time > >>>differs<<< from that of its correspondent." So I think my > suggestion of > using an arbitrary beginning timestamp, e.g., > 20010101T00000000, completely > fulfills the requirement that "The TimeStamp parameter shall > be sent with a > registration command..." As a matter of fact, this may have > been what you > meant in your reply by "the MGs notion of time." > > Okay, the timestamp stays in! However, it's interesting to > note that we > weren't encoding a timestamp at the last interop, and none of the MGCs > complained. > > Paul Long > ipDialog, Inc. > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Monday, April 30, 2001 4:40 PM > To: 'Paul Long'; megaco@fore.com > Subject: RE: "Does anybody really know what time it is?" :-) > > > The MGC needs to know the MGs notion of time because network > time is not > constant, and things like timestamps for Notify are important. > > Nearly every gateway and phone I've looked at has a time of > day clock, YMMV. > > Brian > > > -----Original Message----- > > From: Paul Long [mailto:plong@ipdialog.com] > > Sent: Monday, April 30, 2001 2:40 PM > > To: megaco@fore.com > > Subject: "Does anybody really know what time it is?" :-) > > > > > > (Sorry about the possibly obscure reference in the Subject > > line to an old > > song by the band, Chicago.) > > > > I just noticed this requirement, and I have a rather big > > problem with it. > > Some MGs will not be maintaining a "wall clock," e.g., there > > will be no > > interface for the user to set the time or specify the current time > > zone--it's just a simple, lightweight telephone for Pete's > > sake--so how can > > such an MG satisfy this requirement? > > > > 7.2.8: "The TimeStamp parameter shall be sent with a registration > > command..." > > > > Can this requirement be relaxed to a "should?" Otherwise, an > > MG will have to > > contact some kind of UTC time server or require the user to > > configure it > > with the correct time before it can be used, neither of which > > are reasonable > > solutions, IMO. > > > > Paul Long > > ipDialog, Inc. > > > From owner-megaco@fore.com Tue May 1 10:40:33 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28985 for ; Tue, 1 May 2001 10:40:33 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA17957; Tue, 1 May 2001 10:28:15 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA08537 for megaco-list; Tue, 1 May 2001 10:27:11 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08515 for ; Tue, 1 May 2001 10:27:08 -0400 (EDT) Received: from mail.mediatrix.com (mail.mediatrix.com [205.237.248.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA17791 for ; Tue, 1 May 2001 10:27:04 -0400 (EDT) Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 10:22:58 -0400 Message-ID: From: Steven Weisz To: "Megaco Mailing List (E-mail)" Subject: Question regarding Wildcarding of TermationIds Date: Tue, 1 May 2001 10:22:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi List, I have two quick questions on wildcarding in TerminationIds. 1) Can we have more than one "*" or "$" in a termination Id? 2) is it legal to have "//" or "///" etc? Thanks, Steven Weisz From owner-megaco@fore.com Tue May 1 10:47:23 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29253 for ; Tue, 1 May 2001 10:47:22 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16999; Tue, 1 May 2001 10:20:05 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA05389 for megaco-list; Tue, 1 May 2001 10:18:20 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA05373 for ; Tue, 1 May 2001 10:18:18 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA16769 for ; Tue, 1 May 2001 10:18:15 -0400 (EDT) Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id KAA00811; Tue, 1 May 2001 10:18:12 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Tue, 1 May 2001 10:18:01 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 May 2001 10:18:02 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110250CA5B@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'megaco'" Cc: "'Christian Groves'" Subject: FW: [Fwd: RE: ServiceChange mandatory vs optional parameters] Date: Tue, 1 May 2001 10:17:51 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Forwarded to the official list. -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com] Sent: Tuesday, May 01, 2001 1:32 AM To: MEGACO@marvin.corpeast.baynetworks.com Subject: [Fwd: RE: ServiceChange mandatory vs optional parameters] G'Day Chuong, As required doesn't mean optional. It means use each parameter "as required" so if Reason and Method are always required you use them in such a way. Christian -------- Original Message -------- Subject: RE: ServiceChange mandatory vs optional parameters Date: Wed, 11 Apr 2001 16:16:29 +0200 From: "Marcello Pantaleo (EED)" To: "'Chuong Nguyen'" CC: "'megaco@fore.com'" Hi Chuong,I think you're right. Also: in section 7.2.8 ServiceChangeMethod and ServiceChangeReason are not optional apparently in ASN.1 only ServiceChangeMethod is not optionalI guess an alignement is needed here.Regards,Marcello -----Original Message----- From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com] Sent: Friday, April 06, 2001 4:40 PM To: 'megaco@fore.com' Subject: ServiceChange mandatory vs optional parameters Hi ALL, 7.2.8 ServiceChange The ServiceChangeDescriptor contains the following parameters as required: * ServiceChangeMethod * ServiceChangeReason * ServiceChangeDelay * ServiceChangeAddress * ServiceChangeProfile * ServiceChangeVersion * ServiceChangeMgcId * TimeStamp The "as required" implies all the above parameters are optional. But the description for each parameter indicated that only ServiceChangeDelay, ServiceChangeAddress, ServiceChangeProfile, ServiceChangeVersion, ServiceChangeMgcId and TimeStamp are optional. The ABNF also specified serviceChangeParm = (serviceChangeMethod / serviceChangeReason / serviceChangeDelay / serviceChangeAddress / serviceChangeProfile / extension / TimeStamp / serviceChangeMgcId / serviceChangeVersion ) I agreed that for ServiceChangeReplyDescriptor the above can be optional. But for ServiceChangeRequest is it still true that all serviceChangeParm are optional? Can an MG send a ServiceChangeRequest w/o METHOD - for example a ServiceChangeRequest w/just serviceChangeAddress or TimeStamp? Thanks Chuong -- Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 **** The opinions expressed are not those of Alcatel USA, Inc **** From owner-megaco@fore.com Tue May 1 10:48:50 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29385 for ; Tue, 1 May 2001 10:48:49 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18773; Tue, 1 May 2001 10:35:45 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA10381 for megaco-list; Tue, 1 May 2001 10:34:39 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10377 for ; Tue, 1 May 2001 10:34:37 -0400 (EDT) Received: from mail.mediatrix.com (mail.mediatrix.com [205.237.248.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18611 for ; Tue, 1 May 2001 10:34:34 -0400 (EDT) Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 10:30:28 -0400 Message-ID: From: Steven Weisz To: "Megaco Mailing List (E-mail)" Subject: Question regarding Wildcarding of TermationIds Date: Tue, 1 May 2001 10:30:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi List, I have two quick questions on wildcarding in TerminationIds. 1) Can we have more than one "*" or "$" in a termination Id? 2) is it legal to have "//" or "///" etc? Thanks, Steven Weisz From owner-megaco@fore.com Tue May 1 11:34:07 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01414 for ; Tue, 1 May 2001 11:34:06 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22222; Tue, 1 May 2001 11:10:07 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA19460 for megaco-list; Tue, 1 May 2001 11:08:54 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA19430 for ; Tue, 1 May 2001 11:08:50 -0400 (EDT) Received: from zrtps06u.us.nortel.com (zrtps06u.nortelnetworks.com [47.140.48.52]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22024 for ; Tue, 1 May 2001 11:08:46 -0400 (EDT) Received: from zrtps06s.us.nortel.com (zrtps06s.us.nortel.com [47.140.48.50]) by zrtps06u.us.nortel.com (8.8.8+Sun/8.8.8) with ESMTP id LAA28723 for ; Tue, 1 May 2001 11:07:10 -0400 (EDT) Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Tue, 1 May 2001 11:09:27 -0400 Received: from zrtpd0jn.us.nortel.com ([47.140.202.35]) by zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KBNDQ1ZF; Tue, 1 May 2001 11:08:29 -0400 Received: from americasm01.nt.com (kboyle.us.nortel.com [47.142.150.95]) by zrtpd0jn.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id J5XGPZGA; Tue, 1 May 2001 11:08:30 -0400 Message-ID: <3AEED118.4E544712@americasm01.nt.com> Date: Tue, 01 May 2001 11:07:04 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Kevin Boyle" Organization: Nortel Networks X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nurit Shenhar CC: "'Megaco (E-mail)" Subject: Re: "Does anybody really know what time it is?" :-) References: <3F2E96E0B800D511821E00306E062AE404BD1B@MAIL-LOD> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit All, We may want to be fairly careful here about monkeying with the time in the MG. Caller ID (or any display feature that includes the time, for that matter) will be dependant on knowing the time difference between the MGC and the MG. Since there is no requirement that the MG and the MGC be in the same time zone, the MGC will need to know what the differential between itself and the MG is, in order to deliver the local time of the set with the display payload. One could provision the differential into the the MGC, or one could calculate the differential based upon the timestamp sent from the MG upon registration. Since registration already requires a timestamp, this is a way to determine the differential without adding provisioning requirements upon the MGC. Kevin Nurit Shenhar wrote: > Hi > > We had a discussion about the time issue at the second half of January 2001. > (see subject: TimeStamp in registration replies). In this discussion we said > that the TimeStamp should be added to the ServiceChangeReply, and can be > used to set the MG clock according to the MGC clock. Was anything done about > it? > > Nurit > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, May 01, 2001 2:16 PM > To: 'Paul Long'; megaco@fore.com > Subject: RE: "Does anybody really know what time it is?" :-) > > Yes, I think a fixed timestamp is fine. > > Yes, you must deal with the other guy's notion of time being > ahead or behind yours. > > When we get to "torture" tests, we should test time issues. > > Note that to make sensible event detection work, you > need a nominally correct time increase (that is, > whatever you start with, it needs to go up in approximately > correct increments). > > Brian > > > -----Original Message----- > > From: Paul Long [mailto:plong@ipdialog.com] > > Sent: Monday, April 30, 2001 6:33 PM > > To: megaco@fore.com > > Subject: RE: "Does anybody really know what time it is?" :-) > > > > > > Brian, > > > > Can't time be relative, as in RTP? > > > > 5.1/RFC1889: "The initial value of the timestamp is random..." > > 6.3.1/RFC1889: "A sender that can keep track of elapsed time > > but has no > > notion of wallclock time may use the elapsed time since > > joining the session > > instead." > > Moreover, 6.3.1/RFC1889: "A sender that has no notion of wallclock or > > elapsed time may set the NTP timestamp to zero." Woohoo! :-) > > > > Since it is already unlikely that a received timestamp will > > _exactly_ match > > the receiving entity's clock at the time it is decoded--it'll > > be off either > > a few milliseconds, several minutes, or maybe several days if > > the time was > > simply set wrong--the receiver should probably apply a delta > > to normalize > > the time (if this is even important at all to the entity). > > Therefore, why > > can't we use a rule similar to the one in 6.3.1/RFC1889? For > > example, the > > timestamp in an MG's ServiceChange/Restart command could be > > 20010101T00000000, and all subsequent timestamps reported by > > the MG will be > > relative to that. Otherwise, how can a lowly consumer device > > know the time? > > When was the last time you plugged in an analogue telephone > > that wouldn't > > work until you set the time? > > > > Hmmm... You know, it looks like we're already covered in this > > regard. Take a > > look at this passage from 7.2.8/H.248 (emphasis mine): "The optional > > TimeStamp parameter specifies the actual time >>>as kept by > > the sender<<<. > > It can be used by the responder to determine how its notion of time > > >>>differs<<< from that of its correspondent." So I think my > > suggestion of > > using an arbitrary beginning timestamp, e.g., > > 20010101T00000000, completely > > fulfills the requirement that "The TimeStamp parameter shall > > be sent with a > > registration command..." As a matter of fact, this may have > > been what you > > meant in your reply by "the MGs notion of time." > > > > Okay, the timestamp stays in! However, it's interesting to > > note that we > > weren't encoding a timestamp at the last interop, and none of the MGCs > > complained. > > > > Paul Long > > ipDialog, Inc. > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Monday, April 30, 2001 4:40 PM > > To: 'Paul Long'; megaco@fore.com > > Subject: RE: "Does anybody really know what time it is?" :-) > > > > > > The MGC needs to know the MGs notion of time because network > > time is not > > constant, and things like timestamps for Notify are important. > > > > Nearly every gateway and phone I've looked at has a time of > > day clock, YMMV. > > > > Brian > > > > > -----Original Message----- > > > From: Paul Long [mailto:plong@ipdialog.com] > > > Sent: Monday, April 30, 2001 2:40 PM > > > To: megaco@fore.com > > > Subject: "Does anybody really know what time it is?" :-) > > > > > > > > > (Sorry about the possibly obscure reference in the Subject > > > line to an old > > > song by the band, Chicago.) > > > > > > I just noticed this requirement, and I have a rather big > > > problem with it. > > > Some MGs will not be maintaining a "wall clock," e.g., there > > > will be no > > > interface for the user to set the time or specify the current time > > > zone--it's just a simple, lightweight telephone for Pete's > > > sake--so how can > > > such an MG satisfy this requirement? > > > > > > 7.2.8: "The TimeStamp parameter shall be sent with a registration > > > command..." > > > > > > Can this requirement be relaxed to a "should?" Otherwise, an > > > MG will have to > > > contact some kind of UTC time server or require the user to > > > configure it > > > with the correct time before it can be used, neither of which > > > are reasonable > > > solutions, IMO. > > > > > > Paul Long > > > ipDialog, Inc. > > > > > From owner-megaco@fore.com Tue May 1 12:35:58 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03272 for ; Tue, 1 May 2001 12:35:57 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA28109; Tue, 1 May 2001 12:15:53 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA04710 for megaco-list; Tue, 1 May 2001 12:14:46 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA04695 for ; Tue, 1 May 2001 12:14:44 -0400 (EDT) Received: from texlog2.texas.rr.com ([24.93.35.223]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA27919 for ; Tue, 1 May 2001 12:14:41 -0400 (EDT) Received: from plong (cs666831-163.austin.rr.com [66.68.31.163]) by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f41GEedQ002431 for ; Tue, 1 May 2001 11:14:40 -0500 (CDT) From: "Paul Long" To: Subject: RE: "Does anybody really know what time it is?" :-) Date: Tue, 1 May 2001 11:14:33 -0500 Message-ID: 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: <4FBEA8857476D311A03300204840E1CF01A6F505@whq-msgusr-02.pit.comms.marconi.com> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Brian, Right, I agree, the timestamps from a sender must be internal consistent. For an MG, they must be correct relative to the first timestamp in the registration request; for an MGC, the registration reply. They represent the sender's own _notion_ of time, as per the standard, and not necessarilly absolute time. Paul Long ipDialog, Inc. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, May 01, 2001 7:16 AM To: 'Paul Long'; megaco@fore.com Subject: RE: "Does anybody really know what time it is?" :-) Yes, I think a fixed timestamp is fine. Yes, you must deal with the other guy's notion of time being ahead or behind yours. When we get to "torture" tests, we should test time issues. Note that to make sensible event detection work, you need a nominally correct time increase (that is, whatever you start with, it needs to go up in approximately correct increments). Brian From owner-megaco@fore.com Tue May 1 12:43:16 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03507 for ; Tue, 1 May 2001 12:43:16 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA27327; Tue, 1 May 2001 12:09:20 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA02698 for megaco-list; Tue, 1 May 2001 12:07:32 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA02691 for ; Tue, 1 May 2001 12:07:31 -0400 (EDT) Received: from texlog2.texas.rr.com ([24.93.35.223]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA27124 for ; Tue, 1 May 2001 12:07:27 -0400 (EDT) Received: from plong (cs666831-163.austin.rr.com [66.68.31.163]) by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f41G7PdQ027415 for ; Tue, 1 May 2001 11:07:26 -0500 (CDT) From: "Paul Long" To: "'Megaco \(E-mail\)" Subject: RE: "Does anybody really know what time it is?" :-) Date: Tue, 1 May 2001 11:07:19 -0500 Message-ID: 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: <3F2E96E0B800D511821E00306E062AE404BD1B@MAIL-LOD> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Nurit, The timestamp is already required in the ServiceChange request _and_ response. I left out the last three words of this sentence in my previous post. 7.2.8/H.248: "The TimeStamp parameter shall be sent with a registration command and its response." Paul Long ipDialog, Inc. -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Nurit Shenhar Sent: Tuesday, May 01, 2001 8:37 AM To: 'Megaco (E-mail) Subject: RE: "Does anybody really know what time it is?" :-) Hi We had a discussion about the time issue at the second half of January 2001. (see subject: TimeStamp in registration replies). In this discussion we said that the TimeStamp should be added to the ServiceChangeReply, and can be used to set the MG clock according to the MGC clock. Was anything done about it? Nurit From owner-megaco@fore.com Tue May 1 13:03:30 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04049 for ; Tue, 1 May 2001 13:03:30 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA00278; Tue, 1 May 2001 12:41:48 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA09813 for megaco-list; Tue, 1 May 2001 12:40:48 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA09802 for ; Tue, 1 May 2001 12:40:46 -0400 (EDT) Received: from texlog2.texas.rr.com ([24.93.35.223]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA00107 for ; Tue, 1 May 2001 12:40:42 -0400 (EDT) Received: from plong (cs666831-163.austin.rr.com [66.68.31.163]) by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f41GefdQ023283 for ; Tue, 1 May 2001 11:40:42 -0500 (CDT) From: "Paul Long" To: "'Megaco \(E-mail\)" Subject: RE: "Does anybody really know what time it is?" :-) Date: Tue, 1 May 2001 11:40:34 -0500 Message-ID: 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: <3AEED118.4E544712@americasm01.nt.com> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Kevin, I just don't want the consumer to have to set the time and time zone on his or her phone before it can be used. Maybe in v2 we could add an optional field to ServiceChange that indicates what time zone the sender is in. (This would most likely just be used by the MG, but I see no reason why the MGC couldn't encode it, too.) We could still allow the timestamps to be relative, though, from both the MG and MGC, although the MGC is likely to encode absolute time. If the MG does not encode the timezone field either because it has not been set yet or it does not support this feature, the MGC knows not to display ostensibly local time. The MGC could either display UTC time or no time at all. How about that? Paul Long ipDialog, Inc. -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Kevin Boyle Sent: Tuesday, May 01, 2001 10:07 AM To: Nurit Shenhar Cc: 'Megaco (E-mail) Subject: Re: "Does anybody really know what time it is?" :-) All, We may want to be fairly careful here about monkeying with the time in the MG. Caller ID (or any display feature that includes the time, for that matter) will be dependant on knowing the time difference between the MGC and the MG. Since there is no requirement that the MG and the MGC be in the same time zone, the MGC will need to know what the differential between itself and the MG is, in order to deliver the local time of the set with the display payload. One could provision the differential into the the MGC, or one could calculate the differential based upon the timestamp sent from the MG upon registration. Since registration already requires a timestamp, this is a way to determine the differential without adding provisioning requirements upon the MGC. Kevin From owner-megaco@fore.com Tue May 1 13:07:47 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04198 for ; Tue, 1 May 2001 13:07:47 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA01154; Tue, 1 May 2001 12:50:36 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA11029 for megaco-list; Tue, 1 May 2001 12:49:34 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA11021 for ; Tue, 1 May 2001 12:49:32 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id MAA00941 for ; Tue, 1 May 2001 12:49:29 -0400 (EDT) Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id MAA16770; Tue, 1 May 2001 12:49:27 -0400 Received: from zmers013 (actually zmers013.ca.nortel.com) by zcars04f.ca.nortel.com; Tue, 1 May 2001 12:49:14 -0400 Received: from nortelnetworks.com (actually acart1bu.ca.nortel.com) by zmers013; Tue, 1 May 2001 12:41:45 -0400 Message-ID: <3AEEE731.22AE517F@nortelnetworks.com> Date: Tue, 01 May 2001 12:41:21 -0400 From: "Tom-PT Taylor" Organization: Nortel Networks X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Sundareswaram PV , megaco@fore.com Subject: Re: what to do for Syntax Error?? References: <13D467F625FAD511AE2A00D0B7B917D71B927F@BRAHMA01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit You have to pass the partial list to the upper layers if it contains executable elements (context properties, commands). Sundareswaram PV wrote: > > Hi All, > Incase if there happens to be a syntax error inthe transactionlist. > if we have partially succeedded in parsing the list, do we need to ask the > MGC to resend the complete message or do we need to pass the partial list to > the upper layers. > > regards, > Sundar. From owner-megaco@fore.com Tue May 1 13:44:59 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05398 for ; Tue, 1 May 2001 13:44:59 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04673; Tue, 1 May 2001 13:29:30 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA19407 for megaco-list; Tue, 1 May 2001 13:28:01 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19398 for ; Tue, 1 May 2001 13:27:59 -0400 (EDT) Received: from texlog2.texas.rr.com ([24.93.35.223]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04487 for ; Tue, 1 May 2001 13:27:55 -0400 (EDT) Received: from plong (cs666831-163.austin.rr.com [66.68.31.163]) by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f41HRsdQ025119 for ; Tue, 1 May 2001 12:27:55 -0500 (CDT) From: "Paul Long" To: "'Megaco \(E-mail\)" Subject: RE: "Does anybody really know what time it is?" :-) Date: Tue, 1 May 2001 12:27:47 -0500 Message-ID: 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: <3F2E96E0B800D511821E00306E062AE404BD1B@MAIL-LOD> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Nurit, Hey, it just occurred to me that the MG can't use the MGC timestamp to set its own clock at least for the just-established association because the MG has already reported its "time base" in the (required) timestamp it previously sent to the MGC in its ServiceChange registration request. It would have to unregister first and then re-register in order to use the new setting. Maybe that was the intent, though. You know, the more I think about it, the more convinced I am that there is no reason to encode absolute time. Not even that it should be optional, or it would be nice if a sender were able to, etc., but that there is really no value in absolute time because the receiving entity will always apply a delta to normalize the senders' time to its own. What does seem to be needed, though, is some way for a receiver to know what time zone it and the sender is in. But note that this feature would just be useful and not essential. Paul Long ipDialog, Inc. -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Nurit Shenhar Sent: Tuesday, May 01, 2001 8:37 AM To: 'Megaco (E-mail) Subject: RE: "Does anybody really know what time it is?" :-) Hi We had a discussion about the time issue at the second half of January 2001. (see subject: TimeStamp in registration replies). In this discussion we said that the TimeStamp should be added to the ServiceChangeReply, and can be used to set the MG clock according to the MGC clock. Was anything done about it? Nurit From owner-megaco@fore.com Tue May 1 14:30:04 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06865 for ; Tue, 1 May 2001 14:30:04 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07443; Tue, 1 May 2001 13:58:16 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA25600 for megaco-list; Tue, 1 May 2001 13:57:08 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA25596 for ; Tue, 1 May 2001 13:57:07 -0400 (EDT) Received: from dnsmx1rrc.telcordia.com (dnsmx1rrc.telcordia.com [128.96.20.41]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07255 for ; Tue, 1 May 2001 13:57:03 -0400 (EDT) Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com [128.96.244.1]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with SMTP id NAA19178 for ; Tue, 1 May 2001 13:52:05 -0400 (EDT) Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256A3F.006226A1 ; Tue, 1 May 2001 13:52:04 -0400 X-Lotus-FromDomain: TELCORDIA From: "Paul W. Roder" To: megaco@fore.com Message-ID: <85256A3F.006224A3.00@notes950.cc.telcordia.com> Date: Tue, 1 May 2001 13:51:57 -0400 Subject: Providing Ringback from the Calling MG versus the Called MG Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk On 4/24/2001 Dave Sclarsky wrote, in "RE: Mode Property for a Termination", "As to your question about mode, well, in the Megaco model, it is not the 'terminating exchange' (remote MG?) that plays ringback. Look at the Modify for A4444 in step 16. Here the MGC tells the caller's MG to play ringback locally, using the signal cg/rt. Here both physical terminations are initially set to sendReceive. The ephemeral on the calling side is set to receive, and the ephemeral on the called side is set to sendReceive. The MGC doesn't set the calling side's ephemeral to sendReceive until the called party goes off hook." I wanted to clarify one point that Dave made about which MG or 'exchange' provides ringback (also known as "inband audible ringing") to the calling party. Dave said that "in the Megaco model it is not the 'terminating exchange' (remote MG?) that plays ringback", and that the caller's MG plays ringback locally based on MGC instruction. My understanding was that the ringback signal could be provided by the calling party's MG (as in the Appendix A Example Call Flows), the called party's MG (if the called party were served by an MG) or by a called switch in the PSTN/GSTN, if the call terminated there after leaving the VoIP or VoATM network through a "Trunk Gateway" MG. In each case, the MGC would have to determine where the ringback signal should come from and send instructions to the calling and called party MGs accordingly. For example, if the MGC determined that ringback should come from the called party's PSTN switch, it could set the calling party MG's ephemeral termination to "Receive Only" and the called party MG's ephemeral and physical terminations to "Send/Receive" (where the physical termination is a TDM PSTN trunk on the PSTN side of the called MG), in anticipation of an inband audible ringing tone or called network announcement being returned by that called PSTN switch. I realize that there are advocates of having the calling party's MG always generate ringback, and others (like me) who advocate having it generated by the called party's MG or by the called PSTN switch. But the key point is that Megaco does not require that the ringback signal be provided by the calling party's MG. The ringback or ring tone signal (cg/rt) is defined as part of the Call Progress Tones Generator Package in Annex E, and Annex E does not dictate which MG (calling, called, or neither) is responsible for generating it. There are reasons for having the called party MG/PSTN switch generate the ringback signal on calls to PSTN, such as 1) allowing for in-band tones and announcements to be passed back before answer from the called PSTN switch to the calling party, without having the calling MG apply a ringback signal on top of them, and 2) ensuring that there is a voice path "cut through" from the called party back to the calling party before the call is answered. If this path is not cut-through, the called party could answer the call, say "Hello?", and get no response, since the calling MG is still waiting for an answer indication from the MGC (which may be lost or delayed), playing the ringback tone to the calling party, and not passing the inband voice information on to the calling party. (Note: In North American PSTNs today, the ringback signal is typically generated by the called switch instead of the called switch for these reasons.) So - isn't it more accurate to say that in the Megaco model, the ringback tone can be generated by the calling MG, the called MG, or a remote PSTN switch? I think that the use of the calling MG in the Example Call Flows is a legitimate example, but it's not the only Megaco-compliant way of sending ringback to the calling party. Paul Roder Telcordia Technologies proder2@telcordia.com Dave Sclarsky on 04/24/2001 10:19:10 AM To: "'Sarju Garg'" , megaco@fore.com cc: (bcc: Paul W. Roder/Telcordia) Subject: RE: Mode Property for a Termination Sarju, Yes, the example call flow isn't perfect (e.g. in step 17, the reply from MGC uses NULL context even though the transaction used context 5000). As to your question about mode, well, in the Megaco model, it is not the 'terminating exchange' (remote MG?) that plays ringback. Look at the Modify for A4444 in step 16. Here the MGC tells the caller's MG to play ringback locally, using the signal cg/rt. Here both physical terminations are initially set to sendReceive. The ephemeral on the calling side is set to receive, and the ephemeral on the called side is set to sendReceive. The MGC doesn't set the calling side's ephemeral to sendReceive until the called party goes off hook. One other important point is that signals are NOT affected by Mode. The MGC could have left the calling physical termination as inactive and still played ringback (or busy, or whatever)! DaveS. RadiSys Corporation [formerly S-Link Corp.] -----Original Message----- From: Sarju Garg [mailto:sarju@bhartitelesoft.com] Sent: Tuesday, April 24, 2001 7:38 AM To: megaco@fore.com Subject: Mode Property for a Termination Hi Lists, I have a query related to the call flow (Appendix A section A.1.2 step 12) shown in the H.248 document. Why is the mode of the termination A4444 not set to sendonly? Since the default state is inactive, then how will the caller hear the RBT applied by the terminating exchange (if mode!=sendonly)? Also mode in step 3 is set to send/recv. Why is that so? We do not need to set mode now. Let it be inactive and change mode only in step 12 to sendonly TIA Sarju From owner-megaco@fore.com Tue May 1 14:32:11 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06904 for ; Tue, 1 May 2001 14:32:11 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA08586; Tue, 1 May 2001 14:09:27 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA29326 for megaco-list; Tue, 1 May 2001 14:08:29 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA29318 for ; Tue, 1 May 2001 14:08:28 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 14:08:20 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F513@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Steven Weisz'" , "Megaco Mailing List (E-mail)" Subject: RE: Question regarding Wildcarding of TermationIds Date: Tue, 1 May 2001 14:08:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hmmmm, I think you can have more than one of each. I was going to say only one of choose, but that's not right: foo$/$ should be legal, I think. Brian > -----Original Message----- > From: Steven Weisz [mailto:sweisz@mediatrix.com] > Sent: Tuesday, May 01, 2001 10:23 AM > To: Megaco Mailing List (E-mail) > Subject: Question regarding Wildcarding of TermationIds > > > Hi List, > > I have two quick questions on wildcarding in TerminationIds. > > 1) Can we have more than one "*" or "$" in a termination Id? > > 2) is it legal to have "//" or "///" etc? > > Thanks, > > Steven Weisz > From owner-megaco@fore.com Tue May 1 14:34:53 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06933 for ; Tue, 1 May 2001 14:34:48 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA09499; Tue, 1 May 2001 14:16:40 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA00968 for megaco-list; Tue, 1 May 2001 14:15:29 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA00962 for ; Tue, 1 May 2001 14:15:28 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 14:15:20 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F514@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul W. Roder'" , megaco@fore.com Subject: RE: Providing Ringback from the Calling MG versus the Called MG Date: Tue, 1 May 2001 14:15:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Megaco the protocol is designed so that it can support "local" ringback, or "remote" (in band) ringback. A given set of implementations have to have consistent assumptions about that to work. This is the stuff profiles are made of. Some examples: The MG implements the ringback signal towards the ephemeral the near MG hears it from the far MG inband The MG implements the ringback signal towards the external (physical) interface, the local device hears it directly Neither MG implements ringback. There is a tones and announcements generator that generates ringback. When the line is answered, the MGC instructs the "near" MG to switch it's media flow from the tones and announcements server to the far MG Megaco can support all of these models. Brian > -----Original Message----- > From: Paul W. Roder [mailto:proder2@telcordia.com] > Sent: Tuesday, May 01, 2001 1:52 PM > To: megaco@fore.com > Subject: Providing Ringback from the Calling MG versus the Called MG > > > > > On 4/24/2001 Dave Sclarsky wrote, in "RE: Mode Property for a > Termination", > > "As to your question about mode, well, in the Megaco model, > it is not the > 'terminating exchange' (remote MG?) that plays ringback. > Look at the Modify > for A4444 in step 16. Here the MGC tells the caller's MG to > play ringback > locally, using the signal cg/rt. Here both physical terminations are > initially set to sendReceive. The ephemeral on the calling > side is set to > receive, and the ephemeral on the called side is set to > sendReceive. The > MGC doesn't set the calling side's ephemeral to sendReceive > until the called > party goes off hook." > > I wanted to clarify one point that Dave made about which MG > or 'exchange' > provides ringback (also known as "inband audible ringing") to > the calling party. > Dave said that "in the Megaco model it is not the > 'terminating exchange' > (remote MG?) that plays ringback", and that the caller's MG > plays ringback > locally > based on MGC instruction. > > My understanding was that the ringback signal could be > provided by the calling > party's MG (as in the Appendix A Example Call Flows), the > called party's MG > (if the called party were served by an MG) or by a called > switch in the > PSTN/GSTN, if the call terminated there after leaving the > VoIP or VoATM network > through a > "Trunk Gateway" MG. In each case, the MGC would have to > determine where the > ringback signal should come from and send instructions to the > calling and called > party MGs accordingly. > > For example, if the MGC determined that ringback should come > from the called > party's PSTN switch, it could set the calling party MG's > ephemeral termination > to "Receive Only" and the called party MG's ephemeral and > physical terminations > to "Send/Receive" (where the physical termination is a TDM > PSTN trunk on the > PSTN side of the called MG), in anticipation of an inband > audible ringing tone > or called network announcement being returned by that called > PSTN switch. > > I realize that there are advocates of having the calling > party's MG always > generate ringback, and others (like me) who advocate having > it generated by the > called party's MG or by the called PSTN switch. But the key > point is that > Megaco does not require that the ringback signal be provided > by the calling > party's MG. The ringback or ring tone signal (cg/rt) is > defined as part of the > Call Progress Tones Generator Package in Annex E, and Annex > E does not dictate > which MG (calling, called, or neither) is responsible for > generating it. > > There are reasons for having the called party MG/PSTN switch > generate the > ringback signal on calls to PSTN, such as 1) allowing for > in-band tones and > announcements to be passed back before answer from the called > PSTN switch to the > calling party, without having the calling MG apply a ringback > signal on top of > them, and 2) ensuring that there is a voice path "cut > through" from the called > party back to the calling party before the call is answered. > If this path is not > cut-through, the called party could answer the call, say > "Hello?", and get no > response, since the calling MG is still waiting for an answer > indication from > the MGC (which may be lost or delayed), playing the ringback > tone to the calling > party, and not passing the inband voice information on to the > calling party. > (Note: In North American PSTNs today, the ringback signal is > typically generated > by the called switch instead of the called switch for these reasons.) > > So - isn't it more accurate to say that in the Megaco model, > the ringback tone > can be generated by the calling MG, the called MG, or a > remote PSTN switch? I > think that the use of the calling MG in the Example Call > Flows is a legitimate > example, but it's not the only Megaco-compliant way of > sending ringback to the > calling party. > > Paul Roder > Telcordia Technologies > proder2@telcordia.com > > > > > > Dave Sclarsky on 04/24/2001 10:19:10 AM > > To: "'Sarju Garg'" , megaco@fore.com > cc: (bcc: Paul W. Roder/Telcordia) > Subject: RE: Mode Property for a Termination > > > > > Sarju, > > Yes, the example call flow isn't perfect (e.g. in step 17, > the reply from > MGC uses NULL context even though the transaction used context 5000). > > As to your question about mode, well, in the Megaco model, it > is not the > 'terminating exchange' (remote MG?) that plays ringback. > Look at the Modify > for A4444 in step 16. Here the MGC tells the caller's MG to > play ringback > locally, using the signal cg/rt. Here both physical terminations are > initially set to sendReceive. The ephemeral on the calling > side is set to > receive, and the ephemeral on the called side is set to > sendReceive. The > MGC doesn't set the calling side's ephemeral to sendReceive > until the called > party goes off hook. > > One other important point is that signals are NOT affected by > Mode. The MGC > could have left the calling physical termination as inactive and still > played ringback (or busy, or whatever)! > > DaveS. > RadiSys Corporation [formerly S-Link Corp.] > > -----Original Message----- > From: Sarju Garg [mailto:sarju@bhartitelesoft.com] > Sent: Tuesday, April 24, 2001 7:38 AM > To: megaco@fore.com > Subject: Mode Property for a Termination > > > Hi Lists, > > I have a query related to the call flow (Appendix A section > A.1.2 step 12) > shown in the H.248 document. Why is the mode of the > termination A4444 not > set to sendonly? Since the default state is inactive, then > how will the > caller hear the RBT applied by the terminating exchange (if > mode!=sendonly)? > Also mode in step 3 is set to send/recv. Why is that so? We > do not need to > set mode now. Let it be inactive and change mode only in step > 12 to sendonly > TIA > Sarju > > > > From owner-megaco@fore.com Tue May 1 16:25:37 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09528 for ; Tue, 1 May 2001 16:25:32 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA17536; Tue, 1 May 2001 15:50:32 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA20630 for megaco-list; Tue, 1 May 2001 15:48:53 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA20624 for ; Tue, 1 May 2001 15:48:51 -0400 (EDT) Received: from slink12.ss7-link.com (mail.ss7-link.com [209.204.106.218]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA17357 for ; Tue, 1 May 2001 15:48:47 -0400 (EDT) Received: by SLINK12 with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 15:48:49 -0400 Message-ID: From: Dave Sclarsky To: "'Paul W. Roder'" , megaco@fore.com Subject: RE: Providing Ringback from the Calling MG versus the Called MG Date: Tue, 1 May 2001 15:48:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Paul, You are absolutely correct. I should have said: ...it is not "necessarily" the 'terminating exchange'... Sorry if I implied that it couldn't be! DaveS. -----Original Message----- From: Paul W. Roder [mailto:proder2@telcordia.com] Sent: Tuesday, May 01, 2001 1:52 PM To: megaco@fore.com Subject: Providing Ringback from the Calling MG versus the Called MG On 4/24/2001 Dave Sclarsky wrote, in "RE: Mode Property for a Termination", "As to your question about mode, well, in the Megaco model, it is not the 'terminating exchange' (remote MG?) that plays ringback. Look at the Modify for A4444 in step 16. Here the MGC tells the caller's MG to play ringback locally, using the signal cg/rt. Here both physical terminations are initially set to sendReceive. The ephemeral on the calling side is set to receive, and the ephemeral on the called side is set to sendReceive. The MGC doesn't set the calling side's ephemeral to sendReceive until the called party goes off hook." I wanted to clarify one point that Dave made about which MG or 'exchange' provides ringback (also known as "inband audible ringing") to the calling party. Dave said that "in the Megaco model it is not the 'terminating exchange' (remote MG?) that plays ringback", and that the caller's MG plays ringback locally based on MGC instruction. My understanding was that the ringback signal could be provided by the calling party's MG (as in the Appendix A Example Call Flows), the called party's MG (if the called party were served by an MG) or by a called switch in the PSTN/GSTN, if the call terminated there after leaving the VoIP or VoATM network through a "Trunk Gateway" MG. In each case, the MGC would have to determine where the ringback signal should come from and send instructions to the calling and called party MGs accordingly. For example, if the MGC determined that ringback should come from the called party's PSTN switch, it could set the calling party MG's ephemeral termination to "Receive Only" and the called party MG's ephemeral and physical terminations to "Send/Receive" (where the physical termination is a TDM PSTN trunk on the PSTN side of the called MG), in anticipation of an inband audible ringing tone or called network announcement being returned by that called PSTN switch. I realize that there are advocates of having the calling party's MG always generate ringback, and others (like me) who advocate having it generated by the called party's MG or by the called PSTN switch. But the key point is that Megaco does not require that the ringback signal be provided by the calling party's MG. The ringback or ring tone signal (cg/rt) is defined as part of the Call Progress Tones Generator Package in Annex E, and Annex E does not dictate which MG (calling, called, or neither) is responsible for generating it. There are reasons for having the called party MG/PSTN switch generate the ringback signal on calls to PSTN, such as 1) allowing for in-band tones and announcements to be passed back before answer from the called PSTN switch to the calling party, without having the calling MG apply a ringback signal on top of them, and 2) ensuring that there is a voice path "cut through" from the called party back to the calling party before the call is answered. If this path is not cut-through, the called party could answer the call, say "Hello?", and get no response, since the calling MG is still waiting for an answer indication from the MGC (which may be lost or delayed), playing the ringback tone to the calling party, and not passing the inband voice information on to the calling party. (Note: In North American PSTNs today, the ringback signal is typically generated by the called switch instead of the called switch for these reasons.) So - isn't it more accurate to say that in the Megaco model, the ringback tone can be generated by the calling MG, the called MG, or a remote PSTN switch? I think that the use of the calling MG in the Example Call Flows is a legitimate example, but it's not the only Megaco-compliant way of sending ringback to the calling party. Paul Roder Telcordia Technologies proder2@telcordia.com Dave Sclarsky on 04/24/2001 10:19:10 AM To: "'Sarju Garg'" , megaco@fore.com cc: (bcc: Paul W. Roder/Telcordia) Subject: RE: Mode Property for a Termination Sarju, Yes, the example call flow isn't perfect (e.g. in step 17, the reply from MGC uses NULL context even though the transaction used context 5000). As to your question about mode, well, in the Megaco model, it is not the 'terminating exchange' (remote MG?) that plays ringback. Look at the Modify for A4444 in step 16. Here the MGC tells the caller's MG to play ringback locally, using the signal cg/rt. Here both physical terminations are initially set to sendReceive. The ephemeral on the calling side is set to receive, and the ephemeral on the called side is set to sendReceive. The MGC doesn't set the calling side's ephemeral to sendReceive until the called party goes off hook. One other important point is that signals are NOT affected by Mode. The MGC could have left the calling physical termination as inactive and still played ringback (or busy, or whatever)! DaveS. RadiSys Corporation [formerly S-Link Corp.] -----Original Message----- From: Sarju Garg [mailto:sarju@bhartitelesoft.com] Sent: Tuesday, April 24, 2001 7:38 AM To: megaco@fore.com Subject: Mode Property for a Termination Hi Lists, I have a query related to the call flow (Appendix A section A.1.2 step 12) shown in the H.248 document. Why is the mode of the termination A4444 not set to sendonly? Since the default state is inactive, then how will the caller hear the RBT applied by the terminating exchange (if mode!=sendonly)? Also mode in step 3 is set to send/recv. Why is that so? We do not need to set mode now. Let it be inactive and change mode only in step 12 to sendonly TIA Sarju From owner-megaco@fore.com Tue May 1 18:10:16 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11323 for ; Tue, 1 May 2001 18:10:16 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA25867; Tue, 1 May 2001 17:36:39 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA12675 for megaco-list; Tue, 1 May 2001 17:35:12 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA12644 for ; Tue, 1 May 2001 17:35:08 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA25686 for ; Tue, 1 May 2001 17:35:06 -0400 (EDT) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f41LZ7V09937 for ; Tue, 1 May 2001 17:35:07 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f41LZ7B09919 for ; Tue, 1 May 2001 17:35:07 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id RAA05744; Tue, 1 May 2001 17:35:03 -0400 (EDT) Cc: MEGACO list Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id RAA05735; Tue, 1 May 2001 17:35:02 -0400 (EDT) Message-ID: <3AEF2B95.249DF4F0@lucent.com> Date: Tue, 01 May 2001 17:33:09 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Christian Groves Original-CC: MEGACO list Subject: Re: [FINAL;)] Re: encoding package values as ANBF VALUES References: <3AE8A218.D53C7C94@lucent.com> <3AE9110F.5CD95DAB@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Christain et. al., Ugh. I need to ammend my own proposal. My limitations on Enums were too strict for many existing package definitions. Changes below. -troy Christian Groves wrote: > > G'Day Troy, > > Just back from holidays and you already have work for me......but no > arguments is what I like so i'll add the text to the IG. > > Cheers, Christian > > Troy Cauble wrote: > > > > Christian, > > > > Since nobody argued, I guess it's final:) > > Can I get an Amen from the Keeper of the Additions? > > > > Proposed addition below. > > > > -troy > > > > > two lines about "Boolean values".> > > > > ; NOTE -- The ABNF in this section uses the VALUE construct (or lists of > > ; VALUE constructs) to encode various package element values (properties, > > ; signal parameters, etc.). The types of these values vary and are > > ; specified the relevant package definition. Several such types are > > ; described in section 12.2. > > ; > > ; The ABNF specification for VALUE allows a quotedString form or a > > ; collection of SafeChars. The encoding of package element values into > > ; ABNF VALUES is specified below. If a type's encoding allows characters > > ; other than SafeChars, the quotedString form MUST be used for all values > > ; of that type, even for specific values that consist only of SafeChars. > > ; > > ; String: A string MUST use the quotedString form of VALUE and can > > ; contain anything allowable in the quotedString form. > > ; > > ; Integer, Double, and Unsigned Integer: Decimal values can be encoded > > ; using characters 0-9. Hexadecimal values must be prefixed with '0x' > > ; and can use characters 0-9,a-f,A-F. An octal format is not supported. > > ; Negative integers start with '-' and MUST be Decimal. The SafeChar > > ; form of VALUE MUST be used. > > ; > > ; Character: A UTF-8 encoding of a single letter surrounded by double > > ; quotes. > > ; > > ; Enumeration: An enumeration can be encoded from alphanumerics > > ; and the underscore character. The SafeChar form of VALUE MUST > > ; be used. Change the three lines above to: ; Enumeration: An enumeration MUST use the SafeChar form of VALUE ; and can contain anything allowable in the SafeChar form. > > ; > > ; Boolean: Boolean values are encoded as "on" and "off" and are > > ; case insensitive. The SafeChar form of VALUE MUST be used. > > ; > > ; Future types: It is expected that packages will define types > > ; beyond these initial types. Any defined types MUST fit within > > ; the ANBF specification of VALUE. Specifically, if a type's encoding > > ; allows characters other than SafeChars, the quotedString form MUST > > ; be used for all values of that type, even for specific values that > > ; consist only of SafeChars. > > ; > > ; Note that there is no way to use the double quote character within > > ; a value. > > > > From owner-megaco@fore.com Tue May 1 19:17:51 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12223 for ; Tue, 1 May 2001 19:17:51 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA29743; Tue, 1 May 2001 18:44:17 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA22831 for megaco-list; Tue, 1 May 2001 18:42:40 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA22827 for ; Tue, 1 May 2001 18:42:38 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA29584 for ; Tue, 1 May 2001 18:42:36 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f41MgcN05884 for ; Tue, 1 May 2001 18:42:38 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f41Mgbp05875 for ; Tue, 1 May 2001 18:42:37 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id SAA10442; Tue, 1 May 2001 18:42:21 -0400 (EDT) To: gunnar.hellstrom@era.ericsson.se, gparsons@nortelnetworks.com, jraff@brooktrout.com, rspitzer@telogy.com, MEGACO list Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id SAA10418; Tue, 1 May 2001 18:42:16 -0400 (EDT) Message-ID: <3AEF3B55.2B54AE48@lucent.com> Date: Tue, 01 May 2001 18:40:21 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Original-To: gunnar.hellstrom@era.ericsson.se, gparsons@nortelnetworks.com, jraff@brooktrout.com, rspitzer@telogy.com, MEGACO list Subject: Annex F typos Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Authors & List, I have found the following typos and possible typos in the ITU 11/00 version of Annex F. Only some of these exist in draft-ietf-megaco-h248f-01.txt. Entries marked by * cause subsequent entries to differ between the two documents. I have not generally checked the values in the two documents against each other. Don't you love two standards organizations? Which one is the real thing? -troy F.7.1.4 PropertyID number jumps to 0x06 (suspicious). F.8.1.2 neglects to specify "Defined in:" or "Characteristics:". F.8.1.3 and F.8.1.6 have the same PropertyID string (v8bsup). F.8.2.1 dtt values DTMF and Sig share the same ID number (0x0B). * dtt value V8BIS has ID number 0x20 instead of 0x1A (suspicious). F.8.3.4 V8bsn values MRdrl and CRel share an ID number (0x06). * V8bsn values CReh and CRdi share an ID number (0x07). * F.9.1.1 and F.9.1.2 have the same PropertyID number (0x01). F.9.1.2 "T.30V34" uses "." where other don't (suspicious). F.10.1.1 and F.10.1.2 have the same PropertyID number (0x01). From owner-megaco@fore.com Wed May 2 00:04:06 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17429 for ; Wed, 2 May 2001 00:04:06 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA10027; Tue, 1 May 2001 23:30:53 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA22685 for megaco-list; Tue, 1 May 2001 23:27:39 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA22681 for ; Tue, 1 May 2001 23:27:38 -0400 (EDT) Received: from hotmail.com (f138.law14.hotmail.com [64.4.21.138]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA09867 for ; Tue, 1 May 2001 23:27:35 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 1 May 2001 20:27:36 -0700 Received: from 211.152.231.114 by lw14fd.law14.hotmail.msn.com with HTTP; Wed, 02 May 2001 03:27:36 GMT X-Originating-IP: [211.152.231.114] From: "mu lj" To: megaco@fore.com Subject: question about stream Date: Wed, 02 May 2001 11:27:36 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Message-ID: X-OriginalArrivalTime: 02 May 2001 03:27:36.0702 (UTC) FILETIME=[D55F61E0:01C0D2B7] Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk hi all: Does Multiple streams exiting a termination mean blend voice in here? If I want to add a new stream in a termination including a stream, which command (ADD and Modify) should be used? Regards Lingjiang Mu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-megaco@fore.com Wed May 2 00:23:15 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17630 for ; Wed, 2 May 2001 00:23:15 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA10763; Tue, 1 May 2001 23:50:17 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA24639 for megaco-list; Tue, 1 May 2001 23:49:23 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA24635 for ; Tue, 1 May 2001 23:49:21 -0400 (EDT) Received: from blant003.satyam.com ([208.220.245.72]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id XAA10669 for ; Tue, 1 May 2001 23:49:12 -0400 (EDT) Received: from 208.220.245.70 by blant003.satyam.com (InterScan E-Mail VirusWall NT); Wed, 02 May 2001 09:17:48 +0530 Received: by BLANT002 with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 09:19:07 +0530 Message-ID: From: Mintu_Shah To: megaco@fore.com Date: Wed, 2 May 2001 09:19:07 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk unsubscribe From owner-megaco@fore.com Wed May 2 00:50:39 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17882 for ; Wed, 2 May 2001 00:50:39 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA11904; Wed, 2 May 2001 00:17:18 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA27345 for megaco-list; Wed, 2 May 2001 00:16:22 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA27337 for ; Wed, 2 May 2001 00:16:21 -0400 (EDT) Received: from ish7.ericsson.com.au ([203.61.155.111]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA11801 for ; Wed, 2 May 2001 00:16:13 -0400 (EDT) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA13307 for ; Wed, 2 May 2001 14:15:44 +1000 (EST) Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA24895 for ; Wed, 2 May 2001 14:15:44 +1000 (EST) Message-ID: <3AEF89FF.9201795@ericsson.com> Date: Wed, 02 May 2001 14:15:59 +1000 From: Christian Groves X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: megaco ietf Subject: Comments on [Fwd: I-D ACTION:draft-taylor-megaco-enhalpkgs-00.txt] Content-Type: multipart/mixed; boundary="------------BDCC7B64847EF756A6FA2219" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------BDCC7B64847EF756A6FA2219 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit G'Day Mike, I've had a look through the following package and have a few comments. o Please allocate binary signal,event and property IDs. There's no reason why these cannot be done in the first release of a package. o Why is termination state used for the Current Pulse Count, Pulse Count Since Last Report ? I thought that local control would be the proper place for these. These relate to the media and are of interest between an MGC and MG. Aren't these really statistics? o Shouldn't the Periodic report event have an observed event for the number of pulses? Cheers, Christian -------- Original Message -------- Subject: I-D ACTION:draft-taylor-megaco-enhalpkgs-00.txt Date: Thu, 26 Apr 2001 07:21:23 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; CC: megaco@fore.com A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Megaco/H.248 Enhanced Analog Line Packages Author(s) : M. Taylor, C. Brown Filename : draft-taylor-megaco-enhalpkgs-00.txt Pages : 10 Date : 25-Apr-01 This document provides proposed definitions for two supplemental packages for Megaco/H.248. These packages address support of functionality for standard and enhanced telephony services delivered over analog line terminations, including line-side answer supervision and the delivery of call metering pulses A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-taylor-megaco-enhalpkgs-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-taylor-megaco-enhalpkgs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-taylor-megaco-enhalpkgs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------BDCC7B64847EF756A6FA2219 Content-Type: Message/External-body; name="draft-taylor-megaco-enhalpkgs-00.txt" Content-Disposition: inline; filename="draft-taylor-megaco-enhalpkgs-00.txt" Content-Transfer-Encoding: 7bit --------------BDCC7B64847EF756A6FA2219-- From owner-megaco@fore.com Wed May 2 01:39:39 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22234 for ; Wed, 2 May 2001 01:39:39 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA13627; Wed, 2 May 2001 01:06:34 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA01649 for megaco-list; Wed, 2 May 2001 01:05:15 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA01643 for ; Wed, 2 May 2001 01:05:13 -0400 (EDT) Received: from ws9.cdotb.ernet.in ([202.41.72.121]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA13517 for ; Wed, 2 May 2001 01:04:17 -0400 (EDT) Received: from jnana.cdotb.ernet.in (IDENT:titty@[192.168.51.214]) by ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id KAA19344 for ; Wed, 2 May 2001 10:24:36 +0500 (GMT+0500) Message-ID: <3AEF872F.2CC4AA31@jnana.cdotb.ernet.in> Date: Wed, 02 May 2001 09:33:59 +0530 From: Titty Thomas Reply-To: titty@cdotb.ernet.in Organization: Centre for Development of Telematics X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.4.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: megaco mail list Subject: Error in transaction reply. Content-Type: multipart/alternative; boundary="------------8AD422F3DC98275D0F9EC4A7" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk --------------8AD422F3DC98275D0F9EC4A7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, If there is an error in transaction reply, what will the receiver of the reply do. How can he report back to the sender that the reply was an error. And what will happen if the reply had some values chosen by the sender (eg. reply for a command with $ ) and the value is in error. Regards, - Titty -- +------------------------------------------------------------------+ |Two roads diverged in a wood, and I took the one less traveled by,| |And that has made all the difference. | +------------------------------------------------------------------+ --------------8AD422F3DC98275D0F9EC4A7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all,
 
    If there is an error in transaction reply, what will the receiver of the reply do. How

can he report back to the sender that the reply was an error. And what will happen if

the reply had some values chosen by the sender (eg. reply for a command with $ ) and the

value is in error.

Regards,

- Titty
 
  

-- 
+------------------------------------------------------------------+
|Two roads diverged in a wood, and I took the one less traveled by,| 
|And that has made all the difference.                             |
+------------------------------------------------------------------+
  --------------8AD422F3DC98275D0F9EC4A7-- From owner-megaco@fore.com Wed May 2 02:44:48 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02550 for ; Wed, 2 May 2001 02:44:48 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA15985; Wed, 2 May 2001 02:09:36 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA07507 for megaco-list; Wed, 2 May 2001 02:08:09 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA07500 for ; Wed, 2 May 2001 02:08:07 -0400 (EDT) Received: from ish7.ericsson.com.au ([203.61.155.111]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA15766 for ; Wed, 2 May 2001 02:07:58 -0400 (EDT) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id QAA26297; Wed, 2 May 2001 16:06:21 +1000 (EST) Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA25845; Wed, 2 May 2001 16:06:17 +1000 (EST) Message-ID: <3AEFA3E3.44EEC579@ericsson.com> Date: Wed, 02 May 2001 16:06:27 +1000 From: Christian Groves X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Troy Cauble CC: gunnar.hellstrom@era.ericsson.se, gparsons@nortelnetworks.com, jraff@brooktrout.com, rspitzer@telogy.com, MEGACO list Subject: Re: Annex F typos References: <3AEF3B55.2B54AE48@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit G'Day Troy, Annex F authors, Please see my replies below. Christian Troy Cauble wrote: > > Authors & List, > > I have found the following typos and possible typos in the > ITU 11/00 version of Annex F. > > Only some of these exist in draft-ietf-megaco-h248f-01.txt. > > Entries marked by * cause subsequent entries to differ between > the two documents. > > I have not generally checked the values in the two documents > against each other. > > Don't you love two standards organizations? > Which one is the real thing? > > -troy > > F.7.1.4 PropertyID number jumps to 0x06 (suspicious). [CHG] Not wrong just misses a number > > F.8.1.2 neglects to specify "Defined in:" or "Characteristics:". [CHG] Yes this seems to be the case. I leave it to the authors to specify the correct values. > > F.8.1.3 and F.8.1.6 have the same PropertyID string (v8bsup). [CHG] Yes. The authors can specify an appropriate name. > > F.8.2.1 dtt values DTMF and Sig share the same ID number (0x0B). * > dtt value V8BIS has ID number 0x20 instead of 0x1A (suspicious). [CHG] This is already fixed in the implementors' guide additions. > > F.8.3.4 V8bsn values MRdrl and CRel share an ID number (0x06). * > V8bsn values CReh and CRdi share an ID number (0x07). * [CHG] This is already fixed in the implementors' guide additions. > > F.9.1.1 and F.9.1.2 have the same PropertyID number (0x01). [CHG] Yes. May I suggest ftrpt (0x0004)? > > F.9.1.2 "T.30V34" uses "." where other don't (suspicious). [CHG] No opinion. > > F.10.1.1 and F.10.1.2 have the same PropertyID number (0x01). [CHG] Yes. May I suggest ipftrpt (0x0007) From owner-megaco@fore.com Wed May 2 03:09:49 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02771 for ; Wed, 2 May 2001 03:09:48 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA17920; Wed, 2 May 2001 02:36:16 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA11069 for megaco-list; Wed, 2 May 2001 02:35:09 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA11065 for ; Wed, 2 May 2001 02:35:07 -0400 (EDT) Received: from nt-mail.tlv.radvision.com ([212.143.185.30]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA17778 for ; Wed, 2 May 2001 02:35:03 -0400 (EDT) Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 09:35:52 +0300 Message-ID: From: Ami Amir To: Paul Long , "'Megaco (E-mail)" Subject: RE: "Does anybody really know what time it is?" :-) Date: Wed, 2 May 2001 09:35:52 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi I've been following the discussion with great interest. We should learn from the mobile network's experience. When you switch on your phone - wherever you are, the NETWORK provides you with the local time that is displayed on your screen. This functionally makes the most sense. Keep in mind that timestamp might be very important for billing (e.g. day/night rates), intelligent call redirects etc. To apply to MEGACO - to my mind it makes sense that the MGC is the device that sets the clock for the MG. I am not familiar enough with H.248 to propose how this should be implemented, but it seems to me that the current MG registration has already a time stamp. If that is the case, maybe there should be a way for an MGC to reset the MG clock to its own timestamp? Ami -----Original Message----- From: Paul Long [mailto:plong@ipdialog.com] Sent: Tuesday, May 01, 2001 8:28 PM To: 'Megaco (E-mail) Subject: RE: "Does anybody really know what time it is?" :-) Nurit, Hey, it just occurred to me that the MG can't use the MGC timestamp to set its own clock at least for the just-established association because the MG has already reported its "time base" in the (required) timestamp it previously sent to the MGC in its ServiceChange registration request. It would have to unregister first and then re-register in order to use the new setting. Maybe that was the intent, though. You know, the more I think about it, the more convinced I am that there is no reason to encode absolute time. Not even that it should be optional, or it would be nice if a sender were able to, etc., but that there is really no value in absolute time because the receiving entity will always apply a delta to normalize the senders' time to its own. What does seem to be needed, though, is some way for a receiver to know what time zone it and the sender is in. But note that this feature would just be useful and not essential. Paul Long ipDialog, Inc. -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Nurit Shenhar Sent: Tuesday, May 01, 2001 8:37 AM To: 'Megaco (E-mail) Subject: RE: "Does anybody really know what time it is?" :-) Hi We had a discussion about the time issue at the second half of January 2001. (see subject: TimeStamp in registration replies). In this discussion we said that the TimeStamp should be added to the ServiceChangeReply, and can be used to set the MG clock according to the MGC clock. Was anything done about it? Nurit From owner-megaco@fore.com Wed May 2 03:21:07 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02893 for ; Wed, 2 May 2001 03:21:07 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA19790; Wed, 2 May 2001 02:50:28 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA12298 for megaco-list; Wed, 2 May 2001 02:49:27 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA12293 for ; Wed, 2 May 2001 02:49:25 -0400 (EDT) Received: from blant003.satyam.com ([208.220.245.72]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id CAA19568 for ; Wed, 2 May 2001 02:49:15 -0400 (EDT) Received: from 208.220.245.70 by blant003.satyam.com (InterScan E-Mail VirusWall NT); Wed, 02 May 2001 11:58:40 +0530 Received: by BLANT002 with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 12:00:00 +0530 Message-ID: From: Mintu_Shah To: "'megaco@fore.com'" Date: Wed, 2 May 2001 11:59:59 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk unsubscribe From owner-megaco@fore.com Wed May 2 08:02:24 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06958 for ; Wed, 2 May 2001 08:02:19 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA01845; Wed, 2 May 2001 07:35:51 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA02140 for megaco-list; Wed, 2 May 2001 07:31:22 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA02136 for ; Wed, 2 May 2001 07:31:20 -0400 (EDT) Received: from mail.bhartitelesoft.com ([202.56.229.147]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA01563 for ; Wed, 2 May 2001 07:31:11 -0400 (EDT) Received: from sarju (taquila [202.56.229.146]) by mail.bhartitelesoft.com (8.11.0/8.11.0) with SMTP id f42BFWb18570; Wed, 2 May 2001 16:45:33 +0530 Message-ID: <006801c0d2f5$babad200$240310ac@bhartitelesoft.com> Reply-To: "Sarju Garg" From: "Sarju Garg" To: "Chris Rigano" Cc: "'megaco'" References: <4FC0DB7A48D6D41193930000F81AC9BE642790@zrtpd00x.us.nortel.com> Subject: Re: How to get SPI Date: Wed, 2 May 2001 16:20:33 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0065_01C0D323.D017A320" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0065_01C0D323.D017A320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chris, List, Thanks Chris for the information. I did not find the procedure of = exchanging SPI between two hosts. SPI is a constant and defined in SAD. = So there is no calculation involved in it. I want to know the procedure = at MG of obtaining the SPI value from MGC which will then be used for = sending the first transaction (registration request) to MGC. TIA Sarju ----- Original Message -----=20 From: Chris Rigano=20 To: 'Sarju Garg'=20 Sent: Wednesday, May 02, 2001 3:57 AM Subject: RE: How to get SPI Hi TIA, =20 the IETF IPSEC AH and I believe ESP documents out line SPI = calculation. I still don't understand the logic of duplicating IPSEC in = Megaco. =20 Best regards, =20 Chris -----Original Message----- From: Sarju Garg [mailto:sarju@bhartitelesoft.com] Sent: Tuesday, May 01, 2001 6:36 AM To: 'megaco' Subject: How to get SPI Hi List, My question is related to getting the SPI value in the Interim AH = security Header. There are two ways: 1. Is there any fixed value to be used for SPI for Interim AH or 2. The value is there in the SAD present in MGC and need to be = determined by MG while security association is created? Which one is used normally in implementations? If 2 is the case, how = (protocol messages) and when to create a security association? TIA Sarju ------=_NextPart_000_0065_01C0D323.D017A320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Chris, List,
 
Thanks Chris for the information. I did = not find=20 the procedure of exchanging SPI between two hosts. SPI is a constant and = defined=20 in SAD. So there is no calculation involved in it. I want to know the = procedure=20 at MG of obtaining the SPI value from MGC which will then be used for = sending=20 the first transaction (registration request) to MGC.
 
TIA
Sarju
----- Original Message -----
From:=20 Chris Rigano
To: 'Sarju=20 Garg'
Sent: Wednesday, May 02, 2001 = 3:57=20 AM
Subject: RE: How to get = SPI

Hi=20 TIA,
 
the=20 IETF IPSEC AH and I believe ESP documents out line SPI calculation. I = still=20 don't understand the logic of duplicating IPSEC in = Megaco.
 
Best=20 regards,
 
Chris
-----Original Message-----
From: Sarju Garg [mailto:sarju@bhartitelesoft.com<= /A>]
Sent:=20 Tuesday, May 01, 2001 6:36 AM
To: = 'megaco'
Subject: How=20 to get SPI

Hi List,
 
My question is related to getting = the SPI value=20 in the Interim AH security Header. There are two ways:
1. Is there any fixed value to be = used for SPI=20 for Interim AH  or
2. The value is there in the SAD = present in MGC=20 and  need to be determined by MG while security association is=20 created?
 
Which one is used normally in = implementations?=20 If 2 is the case, how (protocol messages) and when to create a = security=20 association?
 
TIA
Sarju
------=_NextPart_000_0065_01C0D323.D017A320-- From owner-megaco@fore.com Wed May 2 08:16:07 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07367 for ; Wed, 2 May 2001 08:16:07 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA03067; Wed, 2 May 2001 07:59:47 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA05724 for megaco-list; Wed, 2 May 2001 07:59:12 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA05718 for ; Wed, 2 May 2001 07:59:10 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 07:59:03 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F521@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Ami Amir'" , Paul Long , "'Megaco (E-mail)" Subject: RE: "Does anybody really know what time it is?" :-) Date: Wed, 2 May 2001 07:59:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk I have two mobiles. One gets time from the network (Qualcom, CDMA/Sprint PCS) the other has a local notion of time (Motorola, GSM/VoiceStream). If you want the device to use the MGC's notion of time, you can, use the reply of the ServiceChange to get it. Doesn't solve the basic issue that the MG initiates the ServiceChange, and it sends it's notion of time, the MGC replies with it's notion of time. I do think that, while you might want it to be different, it's okay, and the idea of using a fixed time (with the correct timezone) is acceptable. Brian > -----Original Message----- > From: Ami Amir [mailto:Amir@tlv.radvision.com] > Sent: Wednesday, May 02, 2001 2:36 AM > To: Paul Long; 'Megaco (E-mail) > Subject: RE: "Does anybody really know what time it is?" :-) > > > Hi > > I've been following the discussion with great interest. > > We should learn from the mobile network's experience. When > you switch on > your phone - wherever you are, the NETWORK provides you with > the local time > that is displayed on your screen. This functionally makes the > most sense. > > Keep in mind that timestamp might be very important for billing (e.g. > day/night rates), intelligent call redirects etc. > > To apply to MEGACO - to my mind it makes sense that the MGC > is the device > that sets the clock for the MG. I am not familiar enough with H.248 to > propose how this should be implemented, but it seems to me > that the current > MG registration has already a time stamp. If that is the > case, maybe there > should be a way for an MGC to reset the MG clock to its own timestamp? > > Ami > > -----Original Message----- > From: Paul Long [mailto:plong@ipdialog.com] > Sent: Tuesday, May 01, 2001 8:28 PM > To: 'Megaco (E-mail) > Subject: RE: "Does anybody really know what time it is?" :-) > > Nurit, > > Hey, it just occurred to me that the MG can't use the MGC > timestamp to set > its own clock at least for the just-established association > because the MG > has already reported its "time base" in the (required) timestamp it > previously sent to the MGC in its ServiceChange registration > request. It > would have to unregister first and then re-register in order > to use the new > setting. Maybe that was the intent, though. > > You know, the more I think about it, the more convinced I am > that there is > no reason to encode absolute time. Not even that it should be > optional, or > it would be nice if a sender were able to, etc., but that > there is really no > value in absolute time because the receiving entity will > always apply a > delta to normalize the senders' time to its own. What does seem to be > needed, though, is some way for a receiver to know what time > zone it and the > sender is in. But note that this feature would just be useful and not > essential. > > Paul Long > ipDialog, Inc. > > -----Original Message----- > From: owner-megaco@pit.comms.marconi.com > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Nurit Shenhar > Sent: Tuesday, May 01, 2001 8:37 AM > To: 'Megaco (E-mail) > Subject: RE: "Does anybody really know what time it is?" :-) > > > Hi > > We had a discussion about the time issue at the second half > of January 2001. > (see subject: TimeStamp in registration replies). In this > discussion we said > that the TimeStamp should be added to the ServiceChangeReply, > and can be > used to set the MG clock according to the MGC clock. Was > anything done about > it? > > Nurit > From owner-megaco@fore.com Wed May 2 09:58:31 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11415 for ; Wed, 2 May 2001 09:58:17 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA11650; Wed, 2 May 2001 09:38:18 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA29016 for megaco-list; Wed, 2 May 2001 09:37:06 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA29009 for ; Wed, 2 May 2001 09:37:05 -0400 (EDT) Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA11461 for ; Wed, 2 May 2001 09:37:02 -0400 (EDT) Received: from MBRAHMANAPALLY ([64.69.123.123]) by huginn.ctccom.net (Mirapoint) with SMTP id ACC14018; Wed, 2 May 2001 09:34:23 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: , "'megaco mail list'" Subject: RE: Error in transaction reply. Date: Wed, 2 May 2001 09:39:47 -0400 Message-ID: <006401c0d30d$5b1ee1c0$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0065_01C0D2EB.D40D41C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3AEF872F.2CC4AA31@jnana.cdotb.ernet.in> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0065_01C0D2EB.D40D41C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Titty, In normal circumstances, even if the MGC retransmit its transaction-request the same transaction response is received from MG. IMO the MGC can treat the error transaction response as error response from MG. Regards Madhubabu -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Titty Thomas Sent: Wednesday, May 02, 2001 12:04 AM To: megaco mail list Subject: Error in transaction reply. Hi all, If there is an error in transaction reply, what will the receiver of the reply do. How can he report back to the sender that the reply was an error. And what will happen if the reply had some values chosen by the sender (eg. reply for a command with $ ) and the value is in error. Regards, - Titty -- +------------------------------------------------------------------+ |Two roads diverged in a wood, and I took the one less traveled by,| |And that has made all the difference. | +------------------------------------------------------------------+ ------=_NextPart_000_0065_01C0D2EB.D40D41C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Titty,
 
In=20 normal circumstances, even if the MGC retransmit its transaction-request = the=20 same transaction response is received from MG. IMO the MGC can = treat the=20 error transaction response as error response from MG. =
Regards
Madhubabu

 -----Original = Message-----
From:=20 owner-megaco@pit.comms.marconi.com=20 [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Titty=20 Thomas
Sent: Wednesday, May 02, 2001 12:04 AM
To: = megaco=20 mail list
Subject: Error in transaction = reply.

Hi all,
 
    If there is = an=20 error in transaction reply, what will the receiver of the reply do. = How=20

can he report back to the sender that the reply was an error. And = what will=20 happen if=20

the reply had some values chosen by the sender (eg. reply for a = command=20 with $ ) and the=20

value is in error.=20

Regards,=20

- Titty
 
  

-- 
+------------------------------------------------------------------+
|Two roads diverged in a wood, and I took the one less traveled =
by,| 
|And that has made all the =
difference.          &n=
bsp;           &nb=
sp;      |
+------------------------------------------------------------------+ =20
------=_NextPart_000_0065_01C0D2EB.D40D41C0-- From owner-megaco@fore.com Wed May 2 10:00:03 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11491 for ; Wed, 2 May 2001 09:59:57 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA10063; Wed, 2 May 2001 09:23:17 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA23860 for megaco-list; Wed, 2 May 2001 09:20:16 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA23837 for ; Wed, 2 May 2001 09:19:49 -0400 (EDT) Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA09575 for ; Wed, 2 May 2001 09:19:44 -0400 (EDT) Received: from MBRAHMANAPALLY ([64.69.123.123]) by huginn.ctccom.net (Mirapoint) with SMTP id ACC13713; Wed, 2 May 2001 09:19:44 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: "'mu lj'" , Subject: RE: question about stream Date: Wed, 2 May 2001 09:25:08 -0400 Message-ID: <006301c0d30b$4f625800$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit hi Mu, According to section 7.1.6 "Streams are created by specifying a new StreamID on one of the terminations in a Context. A stream is deleted by setting empty Local and Remote descriptors for the stream with ReserveGroup and ReserveValue in LocalControl set to "false" on all terminations in the context that previously supported that stream.". This need not be in Add command as Add is meant to add terminations to context and nothing related to stream. Hence a new stream can be created in either of Add or Modify. (in Move also). Regards Madhubabu -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of mu lj Sent: Tuesday, May 01, 2001 11:28 PM To: megaco@fore.com Subject: question about stream hi all: Does Multiple streams exiting a termination mean blend voice in here? If I want to add a new stream in a termination including a stream, which command (ADD and Modify) should be used? Regards Lingjiang Mu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-megaco@fore.com Wed May 2 10:16:59 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12248 for ; Wed, 2 May 2001 10:16:59 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA12160; Wed, 2 May 2001 09:42:14 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA00323 for megaco-list; Wed, 2 May 2001 09:41:29 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA00311 for ; Wed, 2 May 2001 09:41:28 -0400 (EDT) Received: from mail.mediatrix.com (mail.mediatrix.com [205.237.248.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA12004 for ; Wed, 2 May 2001 09:41:26 -0400 (EDT) Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 09:37:25 -0400 Message-ID: From: =?iso-8859-1?Q?Fran=E7ois_Berard?= To: "'Rosen, Brian'" , Steven Weisz , "Megaco Mailing List (E-mail)" Subject: RE: Question regarding Wildcarding of TermationIds Date: Wed, 2 May 2001 09:37:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Brian, Can a wildcard match multiple hierarchal levels? For example, would a*b/c*d match with aa/bb/cc/dd? Thanks, Francois -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, May 01, 2001 2:08 PM To: 'Steven Weisz'; Megaco Mailing List (E-mail) Subject: RE: Question regarding Wildcarding of TermationIds Hmmmm, I think you can have more than one of each. I was going to say only one of choose, but that's not right: foo$/$ should be legal, I think. Brian > -----Original Message----- > From: Steven Weisz [mailto:sweisz@mediatrix.com] > Sent: Tuesday, May 01, 2001 10:23 AM > To: Megaco Mailing List (E-mail) > Subject: Question regarding Wildcarding of TermationIds > > > Hi List, > > I have two quick questions on wildcarding in TerminationIds. > > 1) Can we have more than one "*" or "$" in a termination Id? > > 2) is it legal to have "//" or "///" etc? > > Thanks, > > Steven Weisz > From owner-megaco@fore.com Wed May 2 10:31:33 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12680 for ; Wed, 2 May 2001 10:31:28 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA13614; Wed, 2 May 2001 09:55:05 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA03879 for megaco-list; Wed, 2 May 2001 09:54:20 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA03863 for ; Wed, 2 May 2001 09:54:18 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 09:54:10 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F526@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: =?iso-8859-1?Q?=27Fran=E7ois_Berard=27?= , Steven Weisz , "Megaco Mailing List (E-mail)" Subject: RE: Question regarding Wildcarding of TermationIds Date: Wed, 2 May 2001 09:54:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.pit.comms.marconi.com id JAA03868 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id JAA13614 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA12680 Yes, it's a straightforward string wildcard. Also note that the protocol assigns no significance to the "/" character in a terminationId. Brian > -----Original Message----- > From: François Berard [mailto:fberard@mediatrix.com] > Sent: Wednesday, May 02, 2001 9:37 AM > To: 'Rosen, Brian'; Steven Weisz; Megaco Mailing List (E-mail) > Subject: RE: Question regarding Wildcarding of TermationIds > > > Brian, > > Can a wildcard match multiple hierarchal levels? For example, > would a*b/c*d > match with aa/bb/cc/dd? > > Thanks, > Francois > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, May 01, 2001 2:08 PM > To: 'Steven Weisz'; Megaco Mailing List (E-mail) > Subject: RE: Question regarding Wildcarding of TermationIds > > > Hmmmm, I think you can have more than one of each. > I was going to say only one of choose, but that's not > right: > foo$/$ > should be legal, I think. > > Brian > > > -----Original Message----- > > From: Steven Weisz [mailto:sweisz@mediatrix.com] > > Sent: Tuesday, May 01, 2001 10:23 AM > > To: Megaco Mailing List (E-mail) > > Subject: Question regarding Wildcarding of TermationIds > > > > > > Hi List, > > > > I have two quick questions on wildcarding in TerminationIds. > > > > 1) Can we have more than one "*" or "$" in a termination Id? > > > > 2) is it legal to have "//" or "///" etc? > > > > Thanks, > > > > Steven Weisz > > > From owner-megaco@fore.com Wed May 2 11:45:04 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15218 for ; Wed, 2 May 2001 11:44:50 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24189; Wed, 2 May 2001 11:44:10 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA03743 for megaco-list; Wed, 2 May 2001 11:42:19 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03712 for ; Wed, 2 May 2001 11:42:16 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id LAA23923 for ; Wed, 2 May 2001 11:42:12 -0400 (EDT) Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id LAA03060; Wed, 2 May 2001 11:42:10 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Wed, 2 May 2001 11:41:53 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 11:41:41 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110250CA82@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'titty@cdotb.ernet.in'" , megaco mail list Subject: RE: Error in transaction reply. Date: Wed, 2 May 2001 11:41:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D31E.615E6630" X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk 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_01C0D31E.615E6630 Content-Type: text/plain; charset="iso-8859-1" There's a general principle, that there is no point in replying to an error response pointing out the error because that could create an error loop. All that is possible is to try to reset things to a known state or, if things get too bad, discontinue the association. -----Original Message----- From: Titty Thomas [mailto:titty@jnana.cdotb.ernet.in] Sent: Wednesday, May 02, 2001 12:04 AM To: megaco mail list Subject: Error in transaction reply. Hi all, If there is an error in transaction reply, what will the receiver of the reply do. How can he report back to the sender that the reply was an error. And what will happen if the reply had some values chosen by the sender (eg. reply for a command with $ ) and the value is in error. Regards, - Titty -- +------------------------------------------------------------------+ |Two roads diverged in a wood, and I took the one less traveled by,| |And that has made all the difference. | +------------------------------------------------------------------+ ------_=_NextPart_001_01C0D31E.615E6630 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
There's a general principle, that there is = no point in=20 replying to an error response pointing out the error because that could = create=20 an error loop.  All that is possible is to try to reset things to = a known=20 state or, if things get too bad, discontinue the=20 association.
-----Original Message-----
From: Titty Thomas=20 [mailto:titty@jnana.cdotb.ernet.in]
Sent: Wednesday, May = 02, 2001=20 12:04 AM
To: megaco mail list
Subject: Error in=20 transaction reply.

Hi all,
 =20
    If there is an error in transaction reply, = what will=20 the receiver of the reply do. How=20

can he report back to the sender that the reply was an error. And = what will=20 happen if=20

the reply had some values chosen by the sender (eg. reply for a = command=20 with $ ) and the=20

value is in error.=20

Regards,=20

- Titty
 
  

-- 
+------------------------------------------------------------------+
|Two roads diverged in a wood, and I took the one less traveled =
by,| 
|And that has made all the =
difference.          &=
nbsp;           &=
nbsp;      |
+------------------------------------------------------------------+ =20


------_=_NextPart_001_01C0D31E.615E6630--


From owner-megaco@fore.com  Wed May  2 13:04:35 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17382
	for ; Wed, 2 May 2001 13:04:34 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA01133;
	Wed, 2 May 2001 13:03:51 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA22217
	for megaco-list; Wed, 2 May 2001 13:02:42 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA22213
	for ; Wed, 2 May 2001 13:02:41 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id NAA00949
	for ; Wed, 2 May 2001 13:02:39 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id NAA09889; Wed, 2 May 2001 13:02:36 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Wed, 2 May 2001 13:02:24 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 2 May 2001 13:02:26 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CA88@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: =?iso-8859-1?Q?=27Fran=E7ois_Berard=27?= ,
        "'Rosen, Brian'" ,
        Steven Weisz ,
        "Megaco Mailing List (E-mail)" 
Subject: RE: Question regarding Wildcarding of TermationIds
Date: Wed, 2 May 2001 13:02:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D329.A51B3F00"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D329.A51B3F00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Yes, because the syntax doesn't actually recognize hierarchy: "/" is =
just
another character.=20

> -----Original Message-----
> From: Fran=E7ois Berard [mailto:fberard@mediatrix.com]
> Sent: Wednesday, May 02, 2001 9:37 AM
> To: 'Rosen, Brian'; Steven Weisz; Megaco Mailing List (E-mail)
> Subject: RE: Question regarding Wildcarding of TermationIds
>=20
>=20
> Brian,
>=20
> Can a wildcard match multiple hierarchal levels? For example,=20
> would a*b/c*d
> match with aa/bb/cc/dd?
>=20
> Thanks,
> Francois
>=20
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Tuesday, May 01, 2001 2:08 PM
> To: 'Steven Weisz'; Megaco Mailing List (E-mail)
> Subject: RE: Question regarding Wildcarding of TermationIds
>=20
>=20
> Hmmmm, I think you can have more than one of each.
> I was going to say only one of choose, but that's not
> right:
> 	foo$/$=20
> should be legal, I think.
>=20
> Brian
>=20
> > -----Original Message-----
> > From: Steven Weisz [mailto:sweisz@mediatrix.com]
> > Sent: Tuesday, May 01, 2001 10:23 AM
> > To: Megaco Mailing List (E-mail)
> > Subject: Question regarding Wildcarding of TermationIds
> >=20
> >=20
> > Hi List,
> >=20
> > I have two quick questions on wildcarding in TerminationIds.
> >=20
> > 1) Can we have more than one "*" or "$" in a termination Id?
> >=20
> > 2) is it legal to have "//" or "///" etc?
> >=20
> > Thanks,=20
> >=20
> > Steven Weisz
> >=20
>=20

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






RE: Question regarding Wildcarding of TermationIds




Yes, because the syntax doesn't actually recognize =
hierarchy: "/" is just another character. 




> -----Original Message-----

> From: Fran=E7ois Berard [mailto:fberard@mediatrix.com]<=
/FONT>

> Sent: Wednesday, May 02, 2001 9:37 AM

> To: 'Rosen, Brian'; Steven Weisz; Megaco =
Mailing List (E-mail)

> Subject: RE: Question regarding Wildcarding of =
TermationIds

> 

> 

> Brian,

> 

> Can a wildcard match multiple hierarchal =
levels? For example, 

> would a*b/c*d

> match with aa/bb/cc/dd?

> 

> Thanks,

> Francois

> 

> -----Original Message-----

> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]

> Sent: Tuesday, May 01, 2001 2:08 PM

> To: 'Steven Weisz'; Megaco Mailing List =
(E-mail)

> Subject: RE: Question regarding Wildcarding of =
TermationIds

> 

> 

> Hmmmm, I think you can have more than one of =
each.

> I was going to say only one of choose, but =
that's not

> right:

>       foo$/$ 

> should be legal, I think.

> 

> Brian

> 

> > -----Original Message-----

> > From: Steven Weisz [mailto:sweisz@mediatrix.com]

> > Sent: Tuesday, May 01, 2001 10:23 =
AM

> > To: Megaco Mailing List (E-mail)

> > Subject: Question regarding Wildcarding of =
TermationIds

> > 

> > 

> > Hi List,

> > 

> > I have two quick questions on wildcarding =
in TerminationIds.

> > 

> > 1) Can we have more than one "*" =
or "$" in a termination Id?

> > 

> > 2) is it legal to have "//" or =
"///" etc?

> > 

> > Thanks, 

> > 

> > Steven Weisz

> > 

> 





------_=_NextPart_001_01C0D329.A51B3F00--


From owner-megaco@fore.com  Wed May  2 13:51:56 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18580
	for ; Wed, 2 May 2001 13:51:55 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05602;
	Wed, 2 May 2001 13:51:13 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA02937
	for megaco-list; Wed, 2 May 2001 13:50:17 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA02922
	for ; Wed, 2 May 2001 13:50:15 -0400 (EDT)
Received: from texlog2.texas.rr.com ([24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05452
	for ; Wed, 2 May 2001 13:50:13 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f42Ho8dQ017680
	for ; Wed, 2 May 2001 12:50:12 -0500 (CDT)
From: "Paul Long" 
To: "'Megaco \(E-mail\)" 
Subject: RE: "Does anybody really know what time it is?" :-)
Date: Wed, 2 May 2001 12:50:11 -0500
Message-ID: 
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)
Importance: Normal
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ami,

In my mind, the timestamps don't need to be synched at all, and, in
particular, an MG's clock never needs to be set by the user or an MGC. In
order to display the local time on an MG--which is the only goal I think we
are all actually trying to achieve here--the MGC must simply know what time
zone the MG is in. Period. The MGC doesn't even need the MG's timestamps
because it can use it's own time base, adjusted for the MG's time zone. The
downside to this is that the MG itself will not have a sense of local time.
If it loses the association with an MGC, it can't display the time. But
isn't this the whole point of Megaco/H.248--to produce an extremely
lightweight MG? If we want a local-time feature in the MG that is setable by
the MGC, we need to add a new feature to the protocol, IMO.

BTW, "What time zone the MG is in," is kinda misleading because it implies a
location-based UTC offset. For example, the space program uses various UTC
offsets that are relative to an event, e.g., MET, rather than a location.
Cool, huh? Megaco being used on the space station or Mars (lotta end-to-end
delay, though). :-)

Paul Long
ipDialog, Inc.

-----Original Message-----
From: Ami Amir [mailto:Amir@tlv.radvision.com]
Sent: Wednesday, May 02, 2001 1:36 AM
To: Paul Long; 'Megaco (E-mail)
Subject: RE: "Does anybody really know what time it is?" :-)


Hi

I've been following the discussion with great interest.

We should learn from the mobile network's experience. When you switch on
your phone - wherever you are, the NETWORK provides you with the local time
that is displayed on your screen. This functionally makes the most sense.

Keep in mind that timestamp might be very important for billing (e.g.
day/night rates), intelligent call redirects etc.

To apply to MEGACO - to my mind it makes sense that the MGC is the device
that sets the clock for the MG. I am not familiar enough with H.248 to
propose how this should be implemented, but it seems to me that the current
MG registration has already a time stamp. If that is the case, maybe there
should be a way for an MGC to reset the MG clock to its own timestamp?

Ami



From owner-megaco@fore.com  Wed May  2 13:53:13 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18642
	for ; Wed, 2 May 2001 13:53:13 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05882;
	Wed, 2 May 2001 13:52:30 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA03305
	for megaco-list; Wed, 2 May 2001 13:51:39 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA03297
	for ; Wed, 2 May 2001 13:51:37 -0400 (EDT)
Received: from texlog2.texas.rr.com ([24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05689
	for ; Wed, 2 May 2001 13:51:34 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f42HpYdQ019234
	for ; Wed, 2 May 2001 12:51:34 -0500 (CDT)
From: "Paul Long" 
To: "'Megaco \(E-mail\)" 
Subject: RE: "Does anybody really know what time it is?" :-)
Date: Wed, 2 May 2001 12:51:37 -0500
Message-ID: 
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)
Importance: Normal
In-Reply-To: <4FBEA8857476D311A03300204840E1CF01A6F521@whq-msgusr-02.pit.comms.marconi.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Brian,

As you say, the MG has already commited to a timebase via its ServiceChange
request by the time it receives the MGC's timestamp in the ServiceChange
reply. Therefore, for the MG to synch its own clock to the MGC's clock, the
MG would have to unregister and then re-register with the new, synched
timestamp. That's certainly technically feasible and compliant behavior but
probably isn't a practical solution due to the added bandwidth and delay.
Plus, I don't see what this actually buys you. Woohoo, your timestamps are
synched! :-)

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Wednesday, May 02, 2001 6:59 AM
To: 'Ami Amir'; Paul Long; 'Megaco (E-mail)
Subject: RE: "Does anybody really know what time it is?" :-)


I have two mobiles.  One gets time from the network (Qualcom, CDMA/Sprint
PCS)
the other has a local notion of time (Motorola, GSM/VoiceStream).

If you want the device to use the MGC's notion of time, you can,
use the reply of the ServiceChange to get it.

Doesn't solve the basic issue that the MG initiates the ServiceChange,
and it sends it's notion of time, the MGC replies with it's notion of
time.  I do think that, while you might want it to be different,
it's okay, and the idea of using a fixed time (with the correct
timezone) is acceptable.

Brian



From owner-megaco@fore.com  Wed May  2 14:21:24 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19250
	for ; Wed, 2 May 2001 14:21:24 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA08362;
	Wed, 2 May 2001 14:20:44 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA09363
	for megaco-list; Wed, 2 May 2001 14:19:50 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA09354
	for ; Wed, 2 May 2001 14:19:49 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 2 May 2001 14:19:41 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F53A@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Paul Long'" , "'Megaco (E-mail)" 
Subject: RE: "Does anybody really know what time it is?" :-)
Date: Wed, 2 May 2001 14:19:48 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

I intended that the MG continue to use it's 
own "notion" of time (starting from a fixed reference on
the initial ServiceChange) for the purposes of
Megaco.  I can use the MGC notion of time for any other
purpose it may need time for.

Brian

> -----Original Message-----
> From: Paul Long [mailto:plong@ipdialog.com]
> Sent: Wednesday, May 02, 2001 1:52 PM
> To: 'Megaco (E-mail)
> Subject: RE: "Does anybody really know what time it is?" :-)
> 
> 
> Brian,
> 
> As you say, the MG has already commited to a timebase via its 
> ServiceChange
> request by the time it receives the MGC's timestamp in the 
> ServiceChange
> reply. Therefore, for the MG to synch its own clock to the 
> MGC's clock, the
> MG would have to unregister and then re-register with the new, synched
> timestamp. That's certainly technically feasible and 
> compliant behavior but
> probably isn't a practical solution due to the added 
> bandwidth and delay.
> Plus, I don't see what this actually buys you. Woohoo, your 
> timestamps are
> synched! :-)
> 
> Paul Long
> ipDialog, Inc.
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> Sent: Wednesday, May 02, 2001 6:59 AM
> To: 'Ami Amir'; Paul Long; 'Megaco (E-mail)
> Subject: RE: "Does anybody really know what time it is?" :-)
> 
> 
> I have two mobiles.  One gets time from the network (Qualcom, 
> CDMA/Sprint
> PCS)
> the other has a local notion of time (Motorola, GSM/VoiceStream).
> 
> If you want the device to use the MGC's notion of time, you can,
> use the reply of the ServiceChange to get it.
> 
> Doesn't solve the basic issue that the MG initiates the ServiceChange,
> and it sends it's notion of time, the MGC replies with it's notion of
> time.  I do think that, while you might want it to be different,
> it's okay, and the idea of using a fixed time (with the correct
> timezone) is acceptable.
> 
> Brian
> 


From owner-megaco@fore.com  Wed May  2 14:32:17 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19563
	for ; Wed, 2 May 2001 14:32:17 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA09518;
	Wed, 2 May 2001 14:31:31 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA12013
	for megaco-list; Wed, 2 May 2001 14:30:41 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA11998
	for ; Wed, 2 May 2001 14:30:38 -0400 (EDT)
Received: from texlog2.texas.rr.com ([24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA09372
	for ; Wed, 2 May 2001 14:30:35 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f42IUYdQ027090
	for ; Wed, 2 May 2001 13:30:35 -0500 (CDT)
From: "Paul Long" 
To: "'Megaco \(E-mail\)" 
Subject: RE: "Does anybody really know what time it is?" :-)
Date: Wed, 2 May 2001 13:30:37 -0500
Message-ID: 
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)
Importance: Normal
In-Reply-To: <4FBEA8857476D311A03300204840E1CF01A6F53A@whq-msgusr-02.pit.comms.marconi.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Brian,

Both the MG and MGC equally have their own notion of time. If we want the
MGC to maintain absolute UTC time so the MG can depend on it for, e.g.,
local time display, we need to state that in the standard. Currently,
neither timestamps are necessarily absolute.

Paul

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Wednesday, May 02, 2001 1:20 PM
To: 'Paul Long'; 'Megaco (E-mail)
Subject: RE: "Does anybody really know what time it is?" :-)


I intended that the MG continue to use it's
own "notion" of time (starting from a fixed reference on
the initial ServiceChange) for the purposes of
Megaco.  I can use the MGC notion of time for any other
purpose it may need time for.

Brian



From owner-megaco@fore.com  Wed May  2 14:56:03 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20067
	for ; Wed, 2 May 2001 14:56:00 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA11715;
	Wed, 2 May 2001 14:55:03 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA17976
	for megaco-list; Wed, 2 May 2001 14:54:10 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA17970
	for ; Wed, 2 May 2001 14:54:09 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 2 May 2001 14:54:01 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F53D@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Paul Long'" , "'Megaco (E-mail)" 
Subject: RE: "Does anybody really know what time it is?" :-)
Date: Wed, 2 May 2001 14:54:08 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Outside of the spec.  Could be part of a profile.

Brian

> -----Original Message-----
> From: Paul Long [mailto:plong@ipdialog.com]
> Sent: Wednesday, May 02, 2001 2:31 PM
> To: 'Megaco (E-mail)
> Subject: RE: "Does anybody really know what time it is?" :-)
> 
> 
> Brian,
> 
> Both the MG and MGC equally have their own notion of time. If 
> we want the
> MGC to maintain absolute UTC time so the MG can depend on it 
> for, e.g.,
> local time display, we need to state that in the standard. Currently,
> neither timestamps are necessarily absolute.
> 
> Paul
> 
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Wednesday, May 02, 2001 1:20 PM
> To: 'Paul Long'; 'Megaco (E-mail)
> Subject: RE: "Does anybody really know what time it is?" :-)
> 
> 
> I intended that the MG continue to use it's
> own "notion" of time (starting from a fixed reference on
> the initial ServiceChange) for the purposes of
> Megaco.  I can use the MGC notion of time for any other
> purpose it may need time for.
> 
> Brian
> 


From owner-megaco@fore.com  Wed May  2 15:25:55 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20820
	for ; Wed, 2 May 2001 15:25:55 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA14628;
	Wed, 2 May 2001 15:25:10 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA24716
	for megaco-list; Wed, 2 May 2001 15:23:57 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24705
	for ; Wed, 2 May 2001 15:23:52 -0400 (EDT)
Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA14384
	for ; Wed, 2 May 2001 15:23:49 -0400 (EDT)
Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1])
	by ihemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f42JNoD12607
	for ; Wed, 2 May 2001 15:23:50 -0400 (EDT)
Received: from ihgp.ih.lucent.com (h135-1-53-23.lucent.com [135.1.53.23])
	by ihemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f42JNon12598
	for ; Wed, 2 May 2001 15:23:50 -0400 (EDT)
Received: by ihgp.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id OAA06161; Wed, 2 May 2001 14:23:48 -0500 (CDT)
Received: from il0015varney2.lucent.com by ihgp.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id OAA06072; Wed, 2 May 2001 14:23:44 -0500 (CDT)
Message-Id: <4.3.2.7.2.20010502130647.00a81380@ihmail.ih.lucent.com>
X-Sender: varney@ihmail.ih.lucent.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 02 May 2001 14:23:36 -0500
To: megaco@fore.com
From: Al Varney 
Subject: Re: Providing Ringback from the Calling MG versus the Called MG
In-Reply-To: <85256A3F.006224A3.00@notes950.cc.telcordia.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


At 13:51 05/01/2001 -0400, Paul W. Roder wrote:




I wanted to clarify one point that Dave made
about which MG or 'exchange'

provides ringback (also known as "inband audible ringing") to
the calling party.

Dave said that  "in the Megaco model it is not the 'terminating
exchange'

(remote MG?) that plays ringback", and that the caller's MG plays
ringback

locally

based on MGC instruction.


   I believe the official name in ITU-T is "Ringing
Tone", with a footnote that the term "ringback" is a
common synonym in the USA.  Ringback was a term used in access
technologies (PABXs, modems) and it became more official when ISDN (also
an access technology) adopted the term.  Telcordia uses
"audible ring tone" in their early Bell-System-sourced
documentation when describing the tone (see SR-2275).  In the Bell
System, "ringbank" was a means of alerting the originating
switchboard operator from a terminating switchboard, and later for E911
operators attempts to re-ring a dropped caller.  The common terms in
ESS/Cross-bar were "ringing" (for the called-party signal) and
"audible ringing" (for the calling-party tone). -- End of
history.




There are reasons for having the called party
MG/PSTN switch generate the

ringback signal on calls to PSTN, such as 1) allowing for in-band tones
and

announcements to be passed back before answer from the called PSTN switch
to the

calling party, without having the calling MG apply a ringback signal on
top of

them, and 2) ensuring that there is a  voice path "cut
through" from the called

party back to the calling party before the call is
answered.


   I've noted these reasons in a largely-ignored ITU-T
contribution last year, where a key sentence read:

             
The PSTN does not, in general, provide a reliable out-of-band indication
of

             
when Alerting of the called party is occurring.



    Absent such an indicator, calls TO the PSTN
have to support your "terminating ring" model, or they are just
guessing the called party is being alerted.  The contribution also
indicated that voice-over-packet networks are responsible for GENERATING
Ring Tone and cutting through an audio path to an incoming PSTN network
when they are the terminating network (that is, the calling PSTN will NOT
be generating that tone itself).  In many cases, call failure
announcements must also come from the terminating network (without Answer
being signaled).



   The SIP folks seem to have finally realized this -- see
Section 4 (about page 96) of:

          
<draft-ietf-sip-call-flows-04.txt>          





(Note: In North American PSTNs today,
the ringback signal is typically generated

by the called switch instead of the called switch for these
reasons.)
                                  
^^^^^^^^^^^^^^^^^^   calling switch, right?



   Rest assured that this the case in every country's
PSTN.  Even in the case of bandwidth-starved cellular networks, an
originating mobile caller always gets a reverse audio path over which
he/she can hear the Ringing Tone (or whatever) supplied by a PSTN
terminating network.  If supplying Ring Tone at the calling terminal
were possible, you'd think it would be done in cellular networks. 
Why those bandwidth-rich packet networks want to make things so
complicated has always puzzled me....



   [N.B.:  I realize some vendors of mobile equipment are
working on standards for doing calling-terminal Ring Tone (even
country-specific tones).  It can work for called-parties that are
KNOWN to correctly indicate when the called party is being alerted, such
as another 'modern' mobile network not interconnected by the PSTN. 
But it will be a long time before it will work for every called
party.]



Al Varney - Lucent Technologies, but just my opinion





From owner-megaco@fore.com  Wed May  2 15:44:10 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21264
	for ; Wed, 2 May 2001 15:44:10 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA16277;
	Wed, 2 May 2001 15:43:28 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA29003
	for megaco-list; Wed, 2 May 2001 15:42:38 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA28987
	for ; Wed, 2 May 2001 15:42:35 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id PAA16141
	for ; Wed, 2 May 2001 15:42:32 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id PAA24495; Wed, 2 May 2001 15:42:30 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Wed, 2 May 2001 15:42:18 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 2 May 2001 15:42:20 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CA8F@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'megaco'" 
Cc: "'Chuong.Nguyen@usa.alcatel.com'" 
Subject: Re: draft-taylor-mmusic-sdptdm-00.txt
Date: Wed, 2 May 2001 15:42:19 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hi Chuong.

>Date: Fri, 27 Apr 2001 11:14:27 -0500
>From: Chuong Nguyen 
>
>Tom>
>
>Thanks for finally getting this out.
>I hope this finally put to rest the issue of whether LocalControl (thus
>TDM package is needed)
>or Local Descriptor (thus TDM SDP) is used to describe TDM termination.
>
>I have some questions below:
>
>From sdptdm draft
>
>      1. Set media = "application" if Transmission Mode is not
>         "circuit", or if Information Transfer Capability is
>         "unrestricted digital information" or "restricted digital
>         information".
>
  Is this like "unrestricted 64k data" call?
>How does one distingush between RFC2327 media, "application" vs
>"data"?  Should a "unrestricted 64k data" call be considered having a
>media = "application" or "data"?

[PTT] "Unrestricted 64k data" is one of the cases covered here.  The reason
I chose "application" rather than "data" is because of the distinction made
by RFC 2327:

    'The difference between "application" and "data" is
     that the former is a media flow such as whiteboard information, and
     the latter is bulk-data transfer such as multicasting of program
     executables which will not typically be displayed to the user.'

I think what we're talking about is a media flow.


>      2. If Transmission Mode is "circuit" and Information Transfer
>         Capability is "Speech" or "3.1 kHz audio", set media =
>         "audio".
>
>      3. If Transmission Mode is "circuit" and Information Transfer
>         Capability is "Unrestricted digital information with tones and
>         announcements", set media = "audio" while the call is being
>         set up, then set it to "application".

  I don't quite follow this.
>Does MGC send an ADD to originating MG w/media = "audio" and
>then a MODIFY w/media = "application" to originating MG after
>terminating MG is established?
>Or do you mean originally the call was audio and switch to
>application if ITC needs to be changed due to tone or announcemets?

[PTT] I mean the former.  The intent of the codepoint is apparently that the
endpoint has to be prepared to receive tones and announcements during call
setup, but after that it's a matter of a data flow (specified by media type
"application" as discussed above).

>      4. If Transmission Mode is "circuit" and Information Transfer
>         Capability is "Video", set media = "application".
>         "Application" is more appropriate than "video" as a MIME type
>         because the bit stream carries more than just video and an
>         application tool is required to interpret it.
>
>
>
>Thanks
>Chuong


Tom Taylor
Multimedia Control and Applications Standards
Ph.  +1 613 736 0961
taylor@nortelnetworks.com 


From owner-megaco@fore.com  Wed May  2 16:17:13 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22261
	for ; Wed, 2 May 2001 16:17:13 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA19174;
	Wed, 2 May 2001 16:16:21 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA06897
	for megaco-list; Wed, 2 May 2001 16:15:19 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA06885
	for ; Wed, 2 May 2001 16:15:17 -0400 (EDT)
Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA19007
	for ; Wed, 2 May 2001 16:15:14 -0400 (EDT)
Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com [128.96.244.1])
	by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id QAA04590;
	Wed, 2 May 2001 16:09:53 -0400 (EDT)
Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256A40.006EC44C ; Wed, 2 May 2001 16:09:52 -0400
X-Lotus-FromDomain: TELCORDIA
From: "Paul W. Roder" 
To: Al Varney , megaco@fore.com
Message-ID: <85256A40.006EC110.00@notes950.cc.telcordia.com>
Date: Wed, 2 May 2001 16:09:43 -0400
Subject: Re: Providing Ringback from the Calling MG versus the Called MG
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk



(Note: In North American PSTNs today, the ringback signal is typically generated
by the called switch instead of the called switch for these reasons.)
                                   ^^^^^^^^^^^^^^^^^^   calling switch, right?

Right you are.  I should have been more careful in my typing - and I should have
 proofread that earlier message before I posted it to the list!

Thanks,

Paul Roder
Telcordia Technologies




From owner-megaco@fore.com  Wed May  2 17:03:35 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23441
	for ; Wed, 2 May 2001 17:03:34 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA23002;
	Wed, 2 May 2001 17:02:44 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA17004
	for megaco-list; Wed, 2 May 2001 17:01:29 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA16983
	for ; Wed, 2 May 2001 17:01:27 -0400 (EDT)
Received: from tomts6-srv.bellnexxia.net (tomts6.bellnexxia.net [209.226.175.26])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA22787
	for ; Wed, 2 May 2001 17:01:21 -0400 (EDT)
Received: from desk ([64.230.146.219]) by tomts6-srv.bellnexxia.net
          (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP
          id <20010502210122.QTPB7009.tomts6-srv.bellnexxia.net@desk>;
          Wed, 2 May 2001 17:01:22 -0400
From: "Vance Shipley" 
To: "Al Varney" 
Cc: 
Subject: RE: Providing Ringback from the Calling MG versus the Called MG
Date: Wed, 2 May 2001 17:00:36 -0400
Message-ID: 
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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <4.3.2.7.2.20010502130647.00a81380@ihmail.ih.lucent.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Al Varney writes:
}
}   [N.B.:  I realize some vendors of mobile equipment are working on 
} standards for doing calling-terminal Ring Tone (even country-specific
} tones).  It can work for called-parties that are KNOWN to correctly 
} indicate when the called party is being alerted, such as another 
} 'modern' mobile network not interconnected by the PSTN.  But it will 
} be a long time before it will work for every called party.]


Isn't this written into both ISUP and Q.931?  

In ISUP the Backward Call Indicators tell whether the call is end-to-end
ISUP and whether the terminating access is ISDN.  They also tell when 
interworking has been encountered (i.e. inband signaling).

Is it reasonable to assume that calling-terminal Ring Tone is possible 
when an end-to-end ISUP connection exists?

	-Vance


From owner-megaco@fore.com  Wed May  2 21:45:52 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29104
	for ; Wed, 2 May 2001 21:45:51 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA06925;
	Wed, 2 May 2001 21:45:03 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA23758
	for megaco-list; Wed, 2 May 2001 21:42:25 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA23754
	for ; Wed, 2 May 2001 21:42:24 -0400 (EDT)
Received: from mail3.atl.bellsouth.net (mail3.atl.bellsouth.net [207.203.120.22])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA06764
	for ; Wed, 2 May 2001 21:42:20 -0400 (EDT)
Received: from gatech804 (adsl-61-161-106.atl.bellsouth.net [208.61.161.106])
	by mail3.atl.bellsouth.net (3.3.5alt/0.75.2) with SMTP id VAA20616;
	Wed, 2 May 2001 21:42:21 -0400 (EDT)
From: "Donald Hansil" 
To: "Steven Weisz" ,
        "Megaco Mailing List \(E-mail\)" 
Subject: RE: Question regarding Wildcarding of TermationIds
Date: Wed, 2 May 2001 21:42:20 -0400
Message-ID: 
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: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Does anyone know how to unsubscribe to this mailing list?


-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Steven Weisz
Sent: Tuesday, May 01, 2001 10:30 AM
To: Megaco Mailing List (E-mail)
Subject: Question regarding Wildcarding of TermationIds

Hi List,

I have two quick questions on wildcarding in TerminationIds.

1) Can we have more than one "*" or "$" in a termination Id?

2) is it legal to have "//" or "///" etc?

Thanks,

Steven Weisz



From owner-megaco@fore.com  Thu May  3 00:05:50 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA01759
	for ; Thu, 3 May 2001 00:05:50 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA10942;
	Thu, 3 May 2001 00:05:00 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA03775
	for megaco-list; Thu, 3 May 2001 00:02:13 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA03771
	for ; Thu, 3 May 2001 00:02:12 -0400 (EDT)
From: rezhirpavai@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA10793
	for ; Thu, 3 May 2001 00:02:05 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f433wef17094;
	Thu, 3 May 2001 09:28:40 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A41.00146AA6 ; Thu, 3 May 2001 09:13:00 +0530
X-Lotus-FromDomain: HSS
To: "Madhu Babu Brahmanapally" 
cc: titty@cdotb.ernet.in, "'megaco mail list'" 
Message-ID: <65256A41.0014664B.00@sandesh.hss.hns.com>
Date: Thu, 3 May 2001 09:20:15 +0530
Subject: RE: Error in transaction reply.
Mime-Version: 1.0
Content-type: multipart/mixed;
	Boundary="0__=xekXhKm18ECVyd6lyT5MkyjB5goPo6IScrQ2dacgcMbIw7xgufBdg0DD"
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

--0__=xekXhKm18ECVyd6lyT5MkyjB5goPo6IScrQ2dacgcMbIw7xgufBdg0DD
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Hello Madhu,
     If the MGC assumes that the transaction response containing a parse error
is a transaction reply with error, then this would lead to discrepancy between
the states of MG and MGC. The MGC would assume that the MG has not processed the
request whereas the MG would have processed the request and would have possibly
changed the termination state.

                                         Regards,
                                         R. Ezhirpavai





"Madhu Babu Brahmanapally"  on 05/02/2001 07:09:47 PM

To:   titty@cdotb.ernet.in, "'megaco mail list'" 
cc:    (bcc: R Ezhirpavai/HSS)

Subject:  RE: Error in transaction reply.




Hi Titty,

In normal circumstances, even if the MGC retransmit its transaction-request
the same transaction response is received from MG. IMO the MGC can treat the
error transaction response as error response from MG.
Regards
Madhubabu

 -----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Titty Thomas
Sent: Wednesday, May 02, 2001 12:04 AM
To: megaco mail list
Subject: Error in transaction reply.


  Hi all,

      If there is an error in transaction reply, what will the receiver of
the reply do. How
  can he report back to the sender that the reply was an error. And what
will happen if

  the reply had some values chosen by the sender (eg. reply for a command
with $ ) and the

  value is in error.

  Regards,

  - Titty



--
+------------------------------------------------------------------+
|Two roads diverged in a wood, and I took the one less traveled by,|
|And that has made all the difference.                             |
+------------------------------------------------------------------+



--0__=xekXhKm18ECVyd6lyT5MkyjB5goPo6IScrQ2dacgcMbIw7xgufBdg0DD
Content-type: text/html;
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U
RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPg0KDQoNCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA1LjAwLjMxMDMuMTAwMCIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElW
PjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9MDk2MjAy
ODEzLTAyMDUyMDAxPkhpIA0KVGl0dHksPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg
Y29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTA5NjIwMjgxMy0w
MjA1MjAwMT48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAw
MGZmIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTA5NjIwMjgxMy0wMjA1MjAwMT5JbiAN
Cm5vcm1hbCBjaXJjdW1zdGFuY2VzLCBldmVuIGlmIHRoZSBNR0MgcmV0cmFuc21pdCBpdHMgdHJh
bnNhY3Rpb24tcmVxdWVzdCB0aGUgDQpzYW1lIHRyYW5zYWN0aW9uIHJlc3BvbnNlIGlzIHJlY2Vp
dmVkIGZyb20gTUcuIElNTyB0aGUgTUdDJm5ic3A7Y2FuIHRyZWF0IHRoZSANCmVycm9yIHRyYW5z
YWN0aW9uIHJlc3BvbnNlIGFzIGVycm9yIHJlc3BvbnNlIGZyb20gTUcuIDwvU1BBTj48L0ZPTlQ+
PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4g
DQpjbGFzcz0wOTYyMDI4MTMtMDIwNTIwMDE+UmVnYXJkczwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8
RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz0w
OTYyMDI4MTMtMDIwNTIwMDE+TWFkaHViYWJ1PC9TUEFOPjwvRk9OVD48Rk9OVCBjb2xvcj0jMDAw
MGZmIGZhY2U9QXJpYWwgDQpzaXplPTI+PFNQQU4gY2xhc3M9MDk2MjAyODEzLTAyMDUyMDAxPjwv
U1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTA5NjIwMjgxMy0wMjA1MjAwMT48
L1NQQU4+PEZPTlQgZmFjZT1UYWhvbWE+PEJSPjwvRk9OVD48Rk9OVCANCmZhY2U9VGFob21hPjxG
T05UIHNpemU9Mj48U1BBTiANCmNsYXNzPTA5NjIwMjgxMy0wMjA1MjAwMT4mbmJzcDs8L1NQQU4+
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+RnJvbTo8L0I+IA0Kb3duZXItbWVnYWNv
QHBpdC5jb21tcy5tYXJjb25pLmNvbSANClttYWlsdG86b3duZXItbWVnYWNvQHBpdC5jb21tcy5t
YXJjb25pLmNvbV08Qj5PbiBCZWhhbGYgT2YgPC9CPlRpdHR5IA0KVGhvbWFzPEJSPjxCPlNlbnQ6
PC9CPiBXZWRuZXNkYXksIE1heSAwMiwgMjAwMSAxMjowNCBBTTxCUj48Qj5Ubzo8L0I+IG1lZ2Fj
byANCm1haWwgbGlzdDxCUj48Qj5TdWJqZWN0OjwvQj4gRXJyb3IgaW4gdHJhbnNhY3Rpb24gcmVw
bHkuPEJSPjxCUj48L0RJVj48L0ZPTlQ+DQo8QkxPQ0tRVU9URT48L0ZPTlQ+SGkgYWxsLCA8QlI+
Jm5ic3A7IDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgSWYgdGhlcmUgaXMgYW4gDQogIGVycm9yIGlu
IHRyYW5zYWN0aW9uIHJlcGx5LCB3aGF0IHdpbGwgdGhlIHJlY2VpdmVyIG9mIHRoZSByZXBseSBk
by4gSG93IA0KICA8UD5jYW4gaGUgcmVwb3J0IGJhY2sgdG8gdGhlIHNlbmRlciB0aGF0IHRoZSBy
ZXBseSB3YXMgYW4gZXJyb3IuIEFuZCB3aGF0IHdpbGwgDQogIGhhcHBlbiBpZiANCiAgPFA+dGhl
IHJlcGx5IGhhZCBzb21lIHZhbHVlcyBjaG9zZW4gYnkgdGhlIHNlbmRlciAoZWcuIHJlcGx5IGZv
ciBhIGNvbW1hbmQgDQogIHdpdGggJCZuYnNwOykgYW5kIHRoZSANCiAgPFA+dmFsdWUgaXMgaW4g
ZXJyb3IuIA0KICA8UD5SZWdhcmRzLCANCiAgPFA+LSBUaXR0eSA8QlI+Jm5ic3A7IDxCUj4mbmJz
cDsgPFBSRT4tLSZuYnNwOw0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCnxUd28gcm9hZHMgZGl2ZXJnZWQgaW4gYSB3
b29kLCBhbmQgSSB0b29rIHRoZSBvbmUgbGVzcyB0cmF2ZWxlZCBieSx8Jm5ic3A7DQp8QW5kIHRo
YXQgaGFzIG1hZGUgYWxsIHRoZSBkaWZmZXJlbmNlLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8DQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKzwvUFJFPiZuYnNwOyAN
CjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K

--0__=xekXhKm18ECVyd6lyT5MkyjB5goPo6IScrQ2dacgcMbIw7xgufBdg0DD--



From owner-megaco@fore.com  Thu May  3 00:24:26 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA01931
	for ; Thu, 3 May 2001 00:24:26 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA11857;
	Thu, 3 May 2001 00:23:36 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA05229
	for megaco-list; Thu, 3 May 2001 00:21:20 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA05225
	for ; Thu, 3 May 2001 00:21:19 -0400 (EDT)
Received: from brahma01.netbrahma.com ([164.164.70.67])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA11686
	for ; Thu, 3 May 2001 00:21:13 -0400 (EDT)
Received: by BRAHMA01 with Internet Mail Service (5.5.2653.19)
	id ; Thu, 3 May 2001 09:51:18 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D7106F98@BRAHMA01>
From: Atanu Mondal 
To: Madhu Babu Brahmanapally ,
        "'rezhirpavai@hss.hns.com'" 
Cc: titty@cdotb.ernet.in, "'megaco mail list'" 
Subject: RE: Error in transaction reply.
Date: Thu, 3 May 2001 09:51:09 +0530 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hello Rezhirpavai,
So how does it matter.. The MGC will again retransmit the transaction,
whereas the MG since it has stored the transaction id will simply discard
the message and send a reply to MGC...

Regards
Atanu

> ----------
> From: 	rezhirpavai@hss.hns.com[SMTP:rezhirpavai@hss.hns.com]
> Sent: 	Thursday, May 03, 2001 9:20 AM
> To: 	Madhu Babu Brahmanapally
> Cc: 	titty@cdotb.ernet.in; 'megaco mail list'
> Subject: 	RE: Error in transaction reply.
> 
> <>
> 
> 
> Hello Madhu,
>      If the MGC assumes that the transaction response containing a parse
> error
> is a transaction reply with error, then this would lead to discrepancy
> between
> the states of MG and MGC. The MGC would assume that the MG has not
> processed the
> request whereas the MG would have processed the request and would have
> possibly
> changed the termination state.
> 
>                                          Regards,
>                                          R. Ezhirpavai
> 
> 
> 
> 
> 
> "Madhu Babu Brahmanapally"  on 05/02/2001 07:09:47
> PM
> 
> To:   titty@cdotb.ernet.in, "'megaco mail list'" 
> cc:    (bcc: R Ezhirpavai/HSS)
> 
> Subject:  RE: Error in transaction reply.
> 
> 
> 
> 
> Hi Titty,
> 
> In normal circumstances, even if the MGC retransmit its
> transaction-request
> the same transaction response is received from MG. IMO the MGC can treat
> the
> error transaction response as error response from MG.
> Regards
> Madhubabu
> 
>  -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Titty Thomas
> Sent: Wednesday, May 02, 2001 12:04 AM
> To: megaco mail list
> Subject: Error in transaction reply.
> 
> 
>   Hi all,
> 
>       If there is an error in transaction reply, what will the receiver of
> the reply do. How
>   can he report back to the sender that the reply was an error. And what
> will happen if
> 
>   the reply had some values chosen by the sender (eg. reply for a command
> with $ ) and the
> 
>   value is in error.
> 
>   Regards,
> 
>   - Titty
> 
> 
> 
> --
> +------------------------------------------------------------------+
> |Two roads diverged in a wood, and I took the one less traveled by,|
> |And that has made all the difference.                             |
> +------------------------------------------------------------------+
> 
> 
> 


From owner-megaco@fore.com  Thu May  3 00:46:23 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02141
	for ; Thu, 3 May 2001 00:46:23 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA12634;
	Thu, 3 May 2001 00:45:25 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA06969
	for megaco-list; Thu, 3 May 2001 00:42:06 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA06964
	for ; Thu, 3 May 2001 00:42:05 -0400 (EDT)
From: rezhirpavai@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA12479
	for ; Thu, 3 May 2001 00:41:55 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f434coA19245;
	Thu, 3 May 2001 10:08:50 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A41.00181809 ; Thu, 3 May 2001 09:53:10 +0530
X-Lotus-FromDomain: HSS
To: Atanu Mondal 
cc: Madhu Babu Brahmanapally , titty@cdotb.ernet.in,
        "'megaco mail list'" 
Message-ID: <65256A41.0018031D.00@sandesh.hss.hns.com>
Date: Thu, 3 May 2001 09:52:54 +0530
Subject: RE: Error in transaction reply.
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk



Hello Atanu,
     On getting back a valid transaction reply, the MGC would stop the
retransmission timer irrespective of whether it contains an error descriptor or
not. Hence it cannot retransmit with the same transaction id. It can though
construct a new transaction request and send to MG again, but probably the new
response may again have a parse error.

                                         Regards,
                                         R. Ezhirpavai





Atanu Mondal  on 05/03/2001 09:51:09 AM

To:   Madhu Babu Brahmanapally , R Ezhirpavai/HSS@HSS
cc:   titty@cdotb.ernet.in, "'megaco mail list'" 

Subject:  RE: Error in transaction reply.




Hello Rezhirpavai,
So how does it matter.. The MGC will again retransmit the transaction,
whereas the MG since it has stored the transaction id will simply discard
the message and send a reply to MGC...

Regards
Atanu

> ----------
> From:   rezhirpavai@hss.hns.com[SMTP:rezhirpavai@hss.hns.com]
> Sent:   Thursday, May 03, 2001 9:20 AM
> To:     Madhu Babu Brahmanapally
> Cc:     titty@cdotb.ernet.in; 'megaco mail list'
> Subject:     RE: Error in transaction reply.
>
> <>
>
>
> Hello Madhu,
>      If the MGC assumes that the transaction response containing a parse
> error
> is a transaction reply with error, then this would lead to discrepancy
> between
> the states of MG and MGC. The MGC would assume that the MG has not
> processed the
> request whereas the MG would have processed the request and would have
> possibly
> changed the termination state.
>
>                                          Regards,
>                                          R. Ezhirpavai
>
>
>
>
>
> "Madhu Babu Brahmanapally"  on 05/02/2001 07:09:47
> PM
>
> To:   titty@cdotb.ernet.in, "'megaco mail list'" 
> cc:    (bcc: R Ezhirpavai/HSS)
>
> Subject:  RE: Error in transaction reply.
>
>
>
>
> Hi Titty,
>
> In normal circumstances, even if the MGC retransmit its
> transaction-request
> the same transaction response is received from MG. IMO the MGC can treat
> the
> error transaction response as error response from MG.
> Regards
> Madhubabu
>
>  -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Titty Thomas
> Sent: Wednesday, May 02, 2001 12:04 AM
> To: megaco mail list
> Subject: Error in transaction reply.
>
>
>   Hi all,
>
>       If there is an error in transaction reply, what will the receiver of
> the reply do. How
>   can he report back to the sender that the reply was an error. And what
> will happen if
>
>   the reply had some values chosen by the sender (eg. reply for a command
> with $ ) and the
>
>   value is in error.
>
>   Regards,
>
>   - Titty
>
>
>
> --
> +------------------------------------------------------------------+
> |Two roads diverged in a wood, and I took the one less traveled by,|
> |And that has made all the difference.                             |
> +------------------------------------------------------------------+
>
>
>






From owner-megaco@fore.com  Thu May  3 00:52:27 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02171
	for ; Thu, 3 May 2001 00:52:26 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA12951;
	Thu, 3 May 2001 00:51:37 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA07437
	for megaco-list; Thu, 3 May 2001 00:49:39 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA07433
	for ; Thu, 3 May 2001 00:49:38 -0400 (EDT)
Received: from ws9.cdotb.ernet.in ([202.41.72.121])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA12810
	for ; Thu, 3 May 2001 00:48:28 -0400 (EDT)
Received: from jnana.cdotb.ernet.in (IDENT:titty@[192.168.51.214])
	by ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id JAA03860;
	Thu, 3 May 2001 09:59:03 +0500 (GMT+0500)
Message-ID: <3AF0D2D3.A7E40370@jnana.cdotb.ernet.in>
Date: Thu, 03 May 2001 09:09:00 +0530
From: Titty Thomas 
Reply-To: titty@cdotb.ernet.in
Organization: Centre for Development of Telematics
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.4.1 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: rezhirpavai@hss.hns.com
CC: Madhu Babu Brahmanapally , titty@cdotb.ernet.in,
        "'megaco mail list'" 
Subject: Re: Error in transaction reply.
References: <65256A41.0014664B.00@sandesh.hss.hns.com>
Content-Type: multipart/alternative;
 boundary="------------C07BA3B7C46EA6529804CCA8"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------C07BA3B7C46EA6529804CCA8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi ,

    In this case one of the options can be to audit the MG and find out its state.

Regards,
-- Titty

rezhirpavai@hss.hns.com wrote:

> Hello Madhu,
>      If the MGC assumes that the transaction response containing a parse error
> is a transaction reply with error, then this would lead to discrepancy between
> the states of MG and MGC. The MGC would assume that the MG has not processed the
> request whereas the MG would have processed the request and would have possibly
> changed the termination state.
>
>                                          Regards,
>                                          R. Ezhirpavai
>
> "Madhu Babu Brahmanapally"  on 05/02/2001 07:09:47 PM
>
> To:   titty@cdotb.ernet.in, "'megaco mail list'" 
> cc:    (bcc: R Ezhirpavai/HSS)
>
> Subject:  RE: Error in transaction reply.
>
> Hi Titty,
>
> In normal circumstances, even if the MGC retransmit its transaction-request
> the same transaction response is received from MG. IMO the MGC can treat the
> error transaction response as error response from MG.
> Regards
> Madhubabu
>
>  -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Titty Thomas
> Sent: Wednesday, May 02, 2001 12:04 AM
> To: megaco mail list
> Subject: Error in transaction reply.
>
>   Hi all,
>
>       If there is an error in transaction reply, what will the receiver of
> the reply do. How
>   can he report back to the sender that the reply was an error. And what
> will happen if
>
>   the reply had some values chosen by the sender (eg. reply for a command
> with $ ) and the
>
>   value is in error.
>
>   Regards,
>
>   - Titty
>
> --
> +------------------------------------------------------------------+
> |Two roads diverged in a wood, and I took the one less traveled by,|
> |And that has made all the difference.                             |
> +------------------------------------------------------------------+
>
>   ------------------------------------------------------------------------
>                   Name: att1.htm
>    att1.htm       Type: Hypertext Markup Language (text/html)
>               Encoding: base64
>            Description: Internet HTML

--
+------------------------------------------------------------------+
|Two roads diverged in a wood, and I took the one less traveled by,|
|And that has made all the difference.                             |
+------------------------------------------------------------------+



--------------C07BA3B7C46EA6529804CCA8
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hi ,

 

    In this case one of the options can be to audit
the MG and find out its state.

Regards,

-- Titty

rezhirpavai@hss.hns.com wrote:

Hello Madhu,

     If the MGC assumes that the transaction response
containing a parse error

is a transaction reply with error, then this would lead to discrepancy
between

the states of MG and MGC. The MGC would assume that the MG has not
processed the

request whereas the MG would have processed the request and would have
possibly

changed the termination state.

                                        
Regards,

                                        
R. Ezhirpavai

"Madhu Babu Brahmanapally" <madhubabu@kenetec.com> on 05/02/2001
07:09:47 PM

To:   titty@cdotb.ernet.in, "'megaco mail list'" <megaco@fore.com>

cc:    (bcc: R Ezhirpavai/HSS)

Subject:  RE: Error in transaction reply.

Hi Titty,

In normal circumstances, even if the MGC retransmit its transaction-request

the same transaction response is received from MG. IMO the MGC can
treat the

error transaction response as error response from MG.

Regards

Madhubabu

 -----Original Message-----

From: owner-megaco@pit.comms.marconi.com

[mailto:owner-megaco@pit.comms.marconi.com]On
Behalf Of Titty Thomas

Sent: Wednesday, May 02, 2001 12:04 AM

To: megaco mail list

Subject: Error in transaction reply.

  Hi all,

      If there is an error in transaction reply,
what will the receiver of

the reply do. How

  can he report back to the sender that the reply was an error.
And what

will happen if

  the reply had some values chosen by the sender (eg. reply for
a command

with $ ) and the

  value is in error.

  Regards,

  - Titty

--

+------------------------------------------------------------------+

|Two roads diverged in a wood, and I took the one less traveled by,|

|And that has made all the difference.                            
|

+------------------------------------------------------------------+

  ------------------------------------------------------------------------

                 
Name: att1.htm

   att1.htm       Type: Hypertext
Markup Language (text/html)

             
Encoding: base64

           Description:
Internet HTML



-- 
+------------------------------------------------------------------+
|Two roads diverged in a wood, and I took the one less traveled by,| 
|And that has made all the difference.                             |
+------------------------------------------------------------------+

 

--------------C07BA3B7C46EA6529804CCA8--



From owner-megaco@fore.com  Thu May  3 06:03:52 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA17987
	for ; Thu, 3 May 2001 06:03:51 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA23251;
	Thu, 3 May 2001 06:02:47 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id GAA05667
	for megaco-list; Thu, 3 May 2001 06:01:21 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA05653
	for ; Thu, 3 May 2001 06:01:18 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA23122
	for ; Thu, 3 May 2001 06:01:14 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1])
	by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f43A1Gi24146
	for ; Thu, 3 May 2001 06:01:16 -0400 (EDT)
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f43A1F824132
	for ; Thu, 3 May 2001 06:01:16 -0400 (EDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 3 May 2001 12:01:14 +0200
Message-ID: 
From: "Bemmel, Jeroen van (Jeroen)" 
To: "'megaco@fore.com'" 
Subject: Relationship Annex C values <=> package Property ID's
Date: Thu, 3 May 2001 12:01:06 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C0D3B7.F80B9B40"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_000_01C0D3B7.F80B9B40
Content-Type: text/plain;
	charset="iso-8859-1"

Hello all,
 
The relationship between value tags in Annex C and attribute identifiers in
packages is unclear and confusing to me:
 
For instance, Annex C defines PropertyID Jitterbuff = 100D, an unsigned
integer 0-65535 representing time in ms
Networkpackage defines Property ID jit = 0x0007 as an attribute to the
LocalControlDescriptor
 
1) Am I correct in assuming that the Annex C value is meant to be assigned
to LocalControlDescriptor.JitterBuffer ?
 
2) If so, how come some of the other Annex C Property IDs are not defined as
attributes anywhere?
 
3) And, if these attributes are not defined, then where is the MG supposed
to keep state information to report when receiving an audit request
    for all terminations (eg step 19 in Appendix A - Example call flows,
resulting in a report of the RTP IP address (amongst others)) ?
 
 
Jeroen van Bemmel
Developer New Technologies
 

------_=_NextPart_000_01C0D3B7.F80B9B40
Content-Type: application/octet-stream;
	name="Bemmel, Jeroen van (Jeroen).vcf"
Content-Disposition: attachment;
	filename="Bemmel, Jeroen van (Jeroen).vcf"

BEGIN:VCARD
VERSION:2.1
N:Bemmel;Jeroen
FN:Bemmel, Jeroen van (Jeroen)
TEL;WORK;VOICE:+31 356875706
ADR;WORK:;215;Capitool 5;Enschede;;7521-PL;Netherlands
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:215=0D=0ACapitool 5=0D=0AEnschede 7521-PL=0D=0ANetherlands
EMAIL;PREF;INTERNET:jbemmel@lucent.com
REV:20010330T104531Z
END:VCARD

------_=_NextPart_000_01C0D3B7.F80B9B40--


From owner-megaco@fore.com  Thu May  3 07:22:01 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18720
	for ; Thu, 3 May 2001 07:22:01 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA26498;
	Thu, 3 May 2001 07:20:59 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA15490
	for megaco-list; Thu, 3 May 2001 07:19:47 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA15482
	for ; Thu, 3 May 2001 07:19:45 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA26390
	for ; Thu, 3 May 2001 07:19:40 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f43BJhR08338
	for ; Thu, 3 May 2001 07:19:43 -0400 (EDT)
Received: from hzsaa01.nl.lucent.com (h135-85-34-95.lucent.com [135.85.34.95])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f43BJgO08332
	for ; Thu, 3 May 2001 07:19:42 -0400 (EDT)
Received: from lucent.com (hzsgp36.nl.lucent.com) by hzsaa01.nl.lucent.com (4.1/SMI-4.1)
	id AA06732; Thu, 3 May 01 13:19:37 +0200
Message-Id: <3AF13EC8.F0FD5975@lucent.com>
Date: Thu, 03 May 2001 13:19:37 +0200
From: Willem van Willigenburg 
Organization: Lucent Technologies
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4  (WinNT; U)
X-Accept-Language: en
Mime-Version: 1.0
To: megaco@fore.com
Subject: SDP equivalents ANNEX C.11 only for session?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello,


Looking at Annex C.11, more specifically at PropertyID  SDP_A, I read that SDP_A
is used for "session attributes".

Does this exclude the usage of SDP_A for media attributes as specified in rfc
2327?

Or should the text be changed to allow the usage of  SDP_A also for media
attributes?

(this question can also be raised for other lines in the media descriptor:

        i=* (media title)
        c=* (connection information - optional if included at session-level)
        b=* (bandwidth information)
        k=* (encryption key)
        a=* (zero or more media attribute lines) ??? SDP_A???

)


With kind regards



Willem van Willigenburg






From owner-megaco@fore.com  Thu May  3 08:51:03 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21417
	for ; Thu, 3 May 2001 08:51:03 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA02239;
	Thu, 3 May 2001 08:50:02 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA07710
	for megaco-list; Thu, 3 May 2001 08:47:16 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA07699
	for ; Thu, 3 May 2001 08:47:14 -0400 (EDT)
Received: from lmmx1.fl.icn.siemens.com (lmmx1.fl.icn.siemens.com [192.132.51.129])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA01933
	for ; Thu, 3 May 2001 08:47:11 -0400 (EDT)
Received: from lmyr210a.lm.ssc.siemens.com (lmyr210a.lm.ssc.siemens.com [165.218.224.44])
	by lmmx1.fl.icn.siemens.com (8.9.3/8.9.3) with ESMTP id IAA19839;
	Thu, 3 May 2001 08:44:50 -0400 (EDT)
Received: by lmyr210a.lm.ssc.siemens.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 3 May 2001 08:47:11 -0400
Message-ID: <637FAED82678D311AFAE0008C791D2498F358C@lmyr227a.lm.ssc.siemens.com>
From: "Groom, William" 
To: "'Dan Elbert'" ,
        "'megaco@fore.com'"
	 
Subject: RE: MGC failure
Date: Thu, 3 May 2001 08:46:45 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Dan,

With regards to the first part of your question. I hope the following helps.

Clarification Of Problem:

When the MGC restarts (including O/S) all associations to the MG are lost.
No messages can be sent from the MGC to the MG until the MG has sent a SC
(restart message on root).

If the connection is TCP, then the MG will get to know about the MGC restart
(eventually) and can go through its normal restart processing to
re-establisg MGC connections. 

If UDP, then the MG is oblivious to the MGC restart.  The action taken by
the MG will depend upon the state of the MG at the time of the MGC restart.
I.E.

1. MG is active carrying traffic. In this state the MG will timeout the MGC,
break existing MGC associations and reconnect. This is fine.

2. MG is already trying to connect. This is also fine.

3. MG is Down (offline). This is fine since it will establish connection
upon restart.

4. MG is Idle (No calls in progress). A trunking MG will remain in this
state forever, until some manual intervention takes place. This is the main
concern we are trying to address. Other gateway's (E.G. Residential) will
detect signals that will eventually lead to a timeout of the MGC and
connection re-establishment taking place.

Two Possible Proposals (there maybe others)

1. Heartbeat Message

I believe a package has been proposed where the MG heartbeats the MGC
(signal on root). I have not seen any proposal nor do I know of the status
of such a proposal. Perhaps someone (Brian) could comment on this.

2. Using Service Change Message

I have not seen this proposal, but cannot see why it would not work.

Upon startup of the MGC, a UDP SC message could be sent to each MG with the
ServiceChangeMgcId set to the MGC IP address. To the MG, this message will
look like a handover of the MGC to itself. 

Note this message is not a connection request, just a message to inform the
MG to re-establish new MGC connections.



The first option is preferred (but none standard) as it caters for the
problem where the MGC goes down and stays down.


Regards
Bill Groom
Siemens

-----Original Message-----
From: Dan Elbert [mailto:DElbert@radvision.com]
Sent: Thursday, April 26, 2001 5:06 PM
To: 'megaco@fore.com'
Subject: MGC failure


Assume that the MGC goes down and up again.
Is there any way for the MGC to indicate the MGs that they need to send a
SVC, or is only the MGs responsibility to have some sort or "keep alive"
(e.g. by sending a noop SVC if nothing is coming from the MGC in a long
time). ?
Note that the MGC doesn't know what port the MG is using.
Related to this, what is the standard response if the MGC receives a Notify
from an MG that is not registered ? ( Because it was registered and then MGC
went down and up again) . Should it send a reply with an error so the MG
knows that it must send a SVC, or just ignore it ?

Thanks,
Dan Elbert
RADVISION


From owner-megaco@fore.com  Thu May  3 09:11:27 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22038
	for ; Thu, 3 May 2001 09:11:27 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA04078;
	Thu, 3 May 2001 09:10:38 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA13626
	for megaco-list; Thu, 3 May 2001 09:09:42 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA13609
	for ; Thu, 3 May 2001 09:09:40 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 3 May 2001 09:09:31 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F54A@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Donald Hansil'" ,
        "Megaco Mailing List (E-mail)" 
Subject: RE: Question regarding Wildcarding of TermationIds
Date: Thu, 3 May 2001 09:09:39 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

You got a message telling you how to do this when you subscribed,
if you did so recently, or when we moved the list to fore.com.
You did save that message, right?

You send a message to majordomo@fore.com, specifying
unsubscribe megaco
as the BODY of the message

You will get a message from majordomo telling you that you are
off the list.

Brian

> -----Original Message-----
> From: Donald Hansil [mailto:d_hansil@bellsouth.net]
> Sent: Wednesday, May 02, 2001 9:42 PM
> To: Steven Weisz; Megaco Mailing List (E-mail)
> Subject: RE: Question regarding Wildcarding of TermationIds
> 
> 
> Does anyone know how to unsubscribe to this mailing list?
> 
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Steven Weisz
> Sent: Tuesday, May 01, 2001 10:30 AM
> To: Megaco Mailing List (E-mail)
> Subject: Question regarding Wildcarding of TermationIds
> 
> Hi List,
> 
> I have two quick questions on wildcarding in TerminationIds.
> 
> 1) Can we have more than one "*" or "$" in a termination Id?
> 
> 2) is it legal to have "//" or "///" etc?
> 
> Thanks,
> 
> Steven Weisz
> 


From owner-megaco@fore.com  Thu May  3 09:20:04 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22361
	for ; Thu, 3 May 2001 09:20:02 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05117;
	Thu, 3 May 2001 09:19:14 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA16175
	for megaco-list; Thu, 3 May 2001 09:18:29 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA16103
	for ; Thu, 3 May 2001 09:18:27 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 3 May 2001 09:18:11 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F54B@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'titty@cdotb.ernet.in'" , rezhirpavai@hss.hns.com
Cc: Madhu Babu Brahmanapally ,
        "'megaco mail list'"
	 
Subject: RE: Error in transaction reply.
Date: Thu, 3 May 2001 09:18:17 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0D3D3.840C4250"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D3D3.840C4250
Content-Type: text/plain;
	charset="iso-8859-1"

I'm beginning to think that maybe we ought to do something about this.
 
First of all, every one of these discussions around syntax errors often
misses
a real important point
    There is basically no recovery possible for the error
This is because there is no way either end is going to change the SYNTAX
of the message it sends as a result of an error.  It's going to take the
offending
programmer to do that (20 lashes with a wet noodle please).  Your only
real recourse is:
    Don't do whatever caused that problem to happen, until the software is
fixed
 
Now, having said that, real systems often have problems and vendors need
a way to figure out what happened and even customers need a way to figure
out that something wrong happened so they at least have a shot at a
workaround.
 
The best solution I can come up with is a real change to the protocol, and
I'm not
at all wild about proposing something that actually changes things, but here
goes:
 
Send a TransactionAck (even if you are using a reliable transport) with an
error
message.
 
Of course, you could get a syntax error on a transactionAck!  I think we can
either ignore that possibility, or allow the Ack the other way.  I'd vote
the former.
 
Brian

-----Original Message-----
From: Titty Thomas [mailto:titty@jnana.cdotb.ernet.in]
Sent: Wednesday, May 02, 2001 11:39 PM
To: rezhirpavai@hss.hns.com
Cc: Madhu Babu Brahmanapally; titty@cdotb.ernet.in; 'megaco mail list'
Subject: Re: Error in transaction reply.


Hi , 
  
    In this case one of the options can be to audit the MG and find out its
state. 

Regards, 
-- Titty 


rezhirpavai@hss.hns.com wrote: 


Hello Madhu, 
     If the MGC assumes that the transaction response containing a parse
error 
is a transaction reply with error, then this would lead to discrepancy
between 
the states of MG and MGC. The MGC would assume that the MG has not processed
the 
request whereas the MG would have processed the request and would have
possibly 
changed the termination state. 

                                         Regards, 
                                         R. Ezhirpavai 


"Madhu Babu Brahmanapally"  on 05/02/2001 07:09:47 PM



To:   titty@cdotb.ernet.in, "'megaco mail list'"  
cc:    (bcc: R Ezhirpavai/HSS) 


Subject:  RE: Error in transaction reply. 


Hi Titty, 


In normal circumstances, even if the MGC retransmit its transaction-request 
the same transaction response is received from MG. IMO the MGC can treat the

error transaction response as error response from MG. 
Regards 
Madhubabu 


 -----Original Message----- 
From: owner-megaco@pit.comms.marconi.com 
[ mailto:owner-megaco@pit.comms.marconi.com
 ]On Behalf Of Titty Thomas 
Sent: Wednesday, May 02, 2001 12:04 AM 
To: megaco mail list 
Subject: Error in transaction reply. 


  Hi all, 


      If there is an error in transaction reply, what will the receiver of 
the reply do. How 
  can he report back to the sender that the reply was an error. And what 
will happen if 


  the reply had some values chosen by the sender (eg. reply for a command 
with $ ) and the 


  value is in error. 


  Regards, 


  - Titty 


-- 
+------------------------------------------------------------------+ 
|Two roads diverged in a wood, and I took the one less traveled by,| 
|And that has made all the difference.                             | 
+------------------------------------------------------------------+ 


  ------------------------------------------------------------------------ 
                  Name: att1.htm 
   att1.htm       Type: Hypertext Markup Language (text/html) 
              Encoding: base64 
           Description: Internet HTML

-- 

+------------------------------------------------------------------+

|Two roads diverged in a wood, and I took the one less traveled by,| 

|And that has made all the difference.                             |

+------------------------------------------------------------------+
  


------_=_NextPart_001_01C0D3D3.840C4250
Content-Type: text/html;
	charset="iso-8859-1"









I'm beginning 
to think that maybe we ought to do something about this.


 


First of all, 
every one of these discussions around syntax errors often 
misses


a real 
important point


    There is basically no recovery 
possible for the error


This is 
because there is no way either end is going to change the 
SYNTAX


of the 
message it sends as a result of an error.  It's going to take the 
offending


programmer to 
do that (20 lashes with a wet noodle please).  Your 
only


real recourse 
is:


    Don't do whatever caused that 
problem to happen, until the software is fixed


 


Now, having 
said that, real systems often have problems and vendors need


a way to 
figure out what happened and even customers need a way to 
figure


out that 
something wrong happened so they at least have a shot at a 
workaround.


 


The best 
solution I can come up with is a real change to the protocol, and I'm 
not


at all wild 
about proposing something that actually changes things, but here 
goes:


 


Send a 
TransactionAck (even if you are using a reliable transport) with an 
error


message.


 


Of course, 
you could get a syntax error on a transactionAck!  I think we 
can


either ignore 
that possibility, or allow the Ack the other way.  I'd vote the 
former.


 


Brian



  
-----Original Message-----
From: Titty Thomas 
  [mailto:titty@jnana.cdotb.ernet.in]
Sent: Wednesday, May 02, 2001 
  11:39 PM
To: rezhirpavai@hss.hns.com
Cc: Madhu Babu 
  Brahmanapally; titty@cdotb.ernet.in; 'megaco mail list'
Subject: Re: 
  Error in transaction reply.

Hi , 
  
  
    In this case one of the options can be to audit the MG 
  and find out its state. 
  
Regards, 
-- Titty 
  
rezhirpavai@hss.hns.com wrote: 
  
Hello Madhu, 
     If the MGC 
    assumes that the transaction response containing a parse error 
is a 
    transaction reply with error, then this would lead to discrepancy between 
    
the states of MG and MGC. The MGC would assume that the MG has not 
    processed the 
request whereas the MG would have processed the request 
    and would have possibly 
changed the termination state. 
    
                                         
    Regards, 
    
                                         
    R. Ezhirpavai 
    
"Madhu Babu Brahmanapally" <madhubabu@kenetec.com> on 05/02/2001 
    07:09:47 PM 
    
To:   titty@cdotb.ernet.in, "'megaco mail list'" 
    <megaco@fore.com> 
cc:    (bcc: R Ezhirpavai/HSS) 
    
Subject:  RE: Error in transaction reply. 
    
Hi Titty, 
    
In normal circumstances, even if the MGC retransmit its 
    transaction-request 
the same transaction response is received from MG. 
    IMO the MGC can treat the 
error transaction response as error response 
    from MG. 
Regards 
Madhubabu 
    
 -----Original Message----- 
From: 
    owner-megaco@pit.comms.marconi.com 
[mailto:owner-megaco@pit.comms.marconi.com]On 
    Behalf Of Titty Thomas 
Sent: Wednesday, May 02, 2001 12:04 AM 
To: 
    megaco mail list 
Subject: Error in transaction reply. 
    
  Hi all, 
    
      If there is an error in transaction reply, 
    what will the receiver of 
the reply do. How 
  can he report 
    back to the sender that the reply was an error. And what 
will happen if 
    
  the reply had some values chosen by the sender (eg. reply for a 
    command 
with $ ) and the 
    
  value is in error. 
    
  Regards, 
    
  - Titty 
    
-- 
    
+------------------------------------------------------------------+ 
    
|Two roads diverged in a wood, and I took the one less traveled by,| 
    
|And that has made all the 
    difference.                             
    | 
+------------------------------------------------------------------+ 
    
  
    ------------------------------------------------------------------------ 
    
                  
    Name: att1.htm 
   att1.htm       
    Type: Hypertext Markup Language (text/html) 
    
              
    Encoding: base64 
    
           
    Description: Internet HTML
-- 
+------------------------------------------------------------------+
|Two roads diverged in a wood, and I took the one less traveled by,| 
|And that has made all the difference.                             |
+------------------------------------------------------------------+
  



------_=_NextPart_001_01C0D3D3.840C4250--


From owner-megaco@fore.com  Thu May  3 09:27:53 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22738
	for ; Thu, 3 May 2001 09:27:53 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05934;
	Thu, 3 May 2001 09:27:06 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA18426
	for megaco-list; Thu, 3 May 2001 09:26:04 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA18416
	for ; Thu, 3 May 2001 09:26:03 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 3 May 2001 09:25:53 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F54C@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Groom, William'" ,
        "'Dan Elbert'"
	 ,
        "'megaco@fore.com'" 
Subject: RE: MGC failure
Date: Thu, 3 May 2001 09:26:01 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Heartbeats have been discussed for some time.

Any message sent from one end to the other gets a reply, so
any message can be a heartbeat message.  It doesn't
require any special package or protocol feature.

Suppose the MGC wants to know if MGs are alive
	Periodically send a message to it that doesn't do anything (NOP)
Same idea for the MG - periodically send the MGC a message.
Smart implementations would have a timer that is reset by any
transaction request or reply from the other side.

For the MGC, there are a plethora of nops.  Empty Audit is
an obvious one.

For the MG, there are fewer choices, but you CAN send a service
change that doesn't change any state.

Brian

> -----Original Message-----
> From: Groom, William [mailto:William.Groom@icn.siemens.com]
> Sent: Thursday, May 03, 2001 8:47 AM
> To: 'Dan Elbert'; 'megaco@fore.com'
> Subject: RE: MGC failure
> 
> 
> Dan,
> 
> With regards to the first part of your question. I hope the 
> following helps.
> 
> Clarification Of Problem:
> 
> When the MGC restarts (including O/S) all associations to the 
> MG are lost.
> No messages can be sent from the MGC to the MG until the MG 
> has sent a SC
> (restart message on root).
> 
> If the connection is TCP, then the MG will get to know about 
> the MGC restart
> (eventually) and can go through its normal restart processing to
> re-establisg MGC connections. 
> 
> If UDP, then the MG is oblivious to the MGC restart.  The 
> action taken by
> the MG will depend upon the state of the MG at the time of 
> the MGC restart.
> I.E.
> 
> 1. MG is active carrying traffic. In this state the MG will 
> timeout the MGC,
> break existing MGC associations and reconnect. This is fine.
> 
> 2. MG is already trying to connect. This is also fine.
> 
> 3. MG is Down (offline). This is fine since it will establish 
> connection
> upon restart.
> 
> 4. MG is Idle (No calls in progress). A trunking MG will 
> remain in this
> state forever, until some manual intervention takes place. 
> This is the main
> concern we are trying to address. Other gateway's (E.G. 
> Residential) will
> detect signals that will eventually lead to a timeout of the MGC and
> connection re-establishment taking place.
> 
> Two Possible Proposals (there maybe others)
> 
> 1. Heartbeat Message
> 
> I believe a package has been proposed where the MG heartbeats the MGC
> (signal on root). I have not seen any proposal nor do I know 
> of the status
> of such a proposal. Perhaps someone (Brian) could comment on this.
> 
> 2. Using Service Change Message
> 
> I have not seen this proposal, but cannot see why it would not work.
> 
> Upon startup of the MGC, a UDP SC message could be sent to 
> each MG with the
> ServiceChangeMgcId set to the MGC IP address. To the MG, this 
> message will
> look like a handover of the MGC to itself. 
> 
> Note this message is not a connection request, just a message 
> to inform the
> MG to re-establish new MGC connections.
> 
> 
> 
> The first option is preferred (but none standard) as it caters for the
> problem where the MGC goes down and stays down.
> 
> 
> Regards
> Bill Groom
> Siemens
> 
> -----Original Message-----
> From: Dan Elbert [mailto:DElbert@radvision.com]
> Sent: Thursday, April 26, 2001 5:06 PM
> To: 'megaco@fore.com'
> Subject: MGC failure
> 
> 
> Assume that the MGC goes down and up again.
> Is there any way for the MGC to indicate the MGs that they 
> need to send a
> SVC, or is only the MGs responsibility to have some sort or 
> "keep alive"
> (e.g. by sending a noop SVC if nothing is coming from the MGC 
> in a long
> time). ?
> Note that the MGC doesn't know what port the MG is using.
> Related to this, what is the standard response if the MGC 
> receives a Notify
> from an MG that is not registered ? ( Because it was 
> registered and then MGC
> went down and up again) . Should it send a reply with an 
> error so the MG
> knows that it must send a SVC, or just ignore it ?
> 
> Thanks,
> Dan Elbert
> RADVISION
> 


From owner-megaco@fore.com  Thu May  3 09:34:41 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22957
	for ; Thu, 3 May 2001 09:34:41 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA06760;
	Thu, 3 May 2001 09:33:52 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA20921
	for megaco-list; Thu, 3 May 2001 09:32:59 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA20913
	for ; Thu, 3 May 2001 09:32:57 -0400 (EDT)
Received: from ns02.newbridge.com (ns02.newbridge.com [192.75.23.75])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id JAA06610
	for ; Thu, 3 May 2001 09:32:55 -0400 (EDT)
Received: (qmail 2423 invoked from network); 3 May 2001 13:31:08 -0000
Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76)
  by ns02.newbridge.com with SMTP; 3 May 2001 13:31:08 -0000
Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for megaco@fore.com; Thu, 3 May 2001 09:30:15 -0400
Received: from alcatel.com ([138.120.45.50]) by kanmail02.ca.newbridge.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAA471C;
          Thu, 3 May 2001 09:30:14 -0400
Message-Id: <3AF15D65.24F069B0@alcatel.com>
Date: Thu, 03 May 2001 09:30:14 -0400
From: Ian Leighton 
Organization: Alcatel CID
X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Groom, William" 
CC: "'Dan Elbert'" ,
        "'megaco@fore.com'" 
Subject: Re: MGC failure
References: <637FAED82678D311AFAE0008C791D2498F358C@lmyr227a.lm.ssc.siemens.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi William

Can you explain what timeout you are referring to in problem 1.

Although my understanding of the spec is limited, I believe that
events are not a mandatory part of the spec. If this is true then
problem 1 is not  solved by the MG sending SC.

Regards
Ian

"Groom, William" wrote:

> Dan,
>
> With regards to the first part of your question. I hope the following helps.
>
> Clarification Of Problem:
>
> When the MGC restarts (including O/S) all associations to the MG are lost.
> No messages can be sent from the MGC to the MG until the MG has sent a SC
> (restart message on root).
>
> If the connection is TCP, then the MG will get to know about the MGC restart
> (eventually) and can go through its normal restart processing to
> re-establisg MGC connections.
>
> If UDP, then the MG is oblivious to the MGC restart.  The action taken by
> the MG will depend upon the state of the MG at the time of the MGC restart.
> I.E.
>
> 1. MG is active carrying traffic. In this state the MG will timeout the MGC,
> break existing MGC associations and reconnect. This is fine.
>
> 2. MG is already trying to connect. This is also fine.
>
> 3. MG is Down (offline). This is fine since it will establish connection
> upon restart.
>
> 4. MG is Idle (No calls in progress). A trunking MG will remain in this
> state forever, until some manual intervention takes place. This is the main
> concern we are trying to address. Other gateway's (E.G. Residential) will
> detect signals that will eventually lead to a timeout of the MGC and
> connection re-establishment taking place.
>
> Two Possible Proposals (there maybe others)
>
> 1. Heartbeat Message
>
> I believe a package has been proposed where the MG heartbeats the MGC
> (signal on root). I have not seen any proposal nor do I know of the status
> of such a proposal. Perhaps someone (Brian) could comment on this.
>
> 2. Using Service Change Message
>
> I have not seen this proposal, but cannot see why it would not work.
>
> Upon startup of the MGC, a UDP SC message could be sent to each MG with the
> ServiceChangeMgcId set to the MGC IP address. To the MG, this message will
> look like a handover of the MGC to itself.
>
> Note this message is not a connection request, just a message to inform the
> MG to re-establish new MGC connections.
>
> The first option is preferred (but none standard) as it caters for the
> problem where the MGC goes down and stays down.
>
> Regards
> Bill Groom
> Siemens
>
> -----Original Message-----
> From: Dan Elbert [mailto:DElbert@radvision.com]
> Sent: Thursday, April 26, 2001 5:06 PM
> To: 'megaco@fore.com'
> Subject: MGC failure
>
> Assume that the MGC goes down and up again.
> Is there any way for the MGC to indicate the MGs that they need to send a
> SVC, or is only the MGs responsibility to have some sort or "keep alive"
> (e.g. by sending a noop SVC if nothing is coming from the MGC in a long
> time). ?
> Note that the MGC doesn't know what port the MG is using.
> Related to this, what is the standard response if the MGC receives a Notify
> from an MG that is not registered ? ( Because it was registered and then MGC
> went down and up again) . Should it send a reply with an error so the MG
> knows that it must send a SVC, or just ignore it ?
>
> Thanks,
> Dan Elbert
> RADVISION



From owner-megaco@fore.com  Thu May  3 10:05:28 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24490
	for ; Thu, 3 May 2001 10:05:28 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10027;
	Thu, 3 May 2001 10:04:39 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA00696
	for megaco-list; Thu, 3 May 2001 10:03:15 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA00685
	for ; Thu, 3 May 2001 10:03:13 -0400 (EDT)
Received: from lmmx1.fl.icn.siemens.com (lmmx1.fl.icn.siemens.com [192.132.51.129])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA09775
	for ; Thu, 3 May 2001 10:03:10 -0400 (EDT)
Received: from lmyr210a.lm.ssc.siemens.com (lmyr210a.lm.ssc.siemens.com [165.218.224.44])
	by lmmx1.fl.icn.siemens.com (8.9.3/8.9.3) with ESMTP id KAA26477;
	Thu, 3 May 2001 10:00:47 -0400 (EDT)
Received: by lmyr210a.lm.ssc.siemens.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 3 May 2001 10:03:09 -0400
Message-ID: <637FAED82678D311AFAE0008C791D2498F358D@lmyr227a.lm.ssc.siemens.com>
From: "Groom, William" 
To: "'Ian Leighton'" 
Cc: "'Dan Elbert'" ,
        "'megaco@fore.com'"
	 
Subject: RE: MGC failure
Date: Thu, 3 May 2001 10:02:47 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Ian,

I was referring to the normal guard timer when the MG sends a Notify or
Service Change request to the MGC. The transaction will be repeated a number
of times before the MG gives up.

I think Brian's response is fine. MGC could use an audit request, while MG
will use a Nop request (E.G. trunk gateway could send a SC on a DS0 with
service restored). I assume the specific heartbeat message will differ based
up the MG vendor and MG type. Provided it is allowed by the MGC then all
should be well.

To avoid un-necessary traffic flows, it is preferred that the MG should only
send the heartbeat if no communication has been received from the MGC for a
period of time.

Regards

Bill Groom

-----Original Message-----
From: Ian Leighton [mailto:ian.leighton@alcatel.com]
Sent: Thursday, May 03, 2001 9:30 AM
To: Groom, William
Cc: 'Dan Elbert'; 'megaco@fore.com'
Subject: Re: MGC failure


Hi William

Can you explain what timeout you are referring to in problem 1.

Although my understanding of the spec is limited, I believe that
events are not a mandatory part of the spec. If this is true then
problem 1 is not  solved by the MG sending SC.

Regards
Ian

"Groom, William" wrote:

> Dan,
>
> With regards to the first part of your question. I hope the following
helps.
>
> Clarification Of Problem:
>
> When the MGC restarts (including O/S) all associations to the MG are lost.
> No messages can be sent from the MGC to the MG until the MG has sent a SC
> (restart message on root).
>
> If the connection is TCP, then the MG will get to know about the MGC
restart
> (eventually) and can go through its normal restart processing to
> re-establisg MGC connections.
>
> If UDP, then the MG is oblivious to the MGC restart.  The action taken by
> the MG will depend upon the state of the MG at the time of the MGC
restart.
> I.E.
>
> 1. MG is active carrying traffic. In this state the MG will timeout the
MGC,
> break existing MGC associations and reconnect. This is fine.
>
> 2. MG is already trying to connect. This is also fine.
>
> 3. MG is Down (offline). This is fine since it will establish connection
> upon restart.
>
> 4. MG is Idle (No calls in progress). A trunking MG will remain in this
> state forever, until some manual intervention takes place. This is the
main
> concern we are trying to address. Other gateway's (E.G. Residential) will
> detect signals that will eventually lead to a timeout of the MGC and
> connection re-establishment taking place.
>
> Two Possible Proposals (there maybe others)
>
> 1. Heartbeat Message
>
> I believe a package has been proposed where the MG heartbeats the MGC
> (signal on root). I have not seen any proposal nor do I know of the status
> of such a proposal. Perhaps someone (Brian) could comment on this.
>
> 2. Using Service Change Message
>
> I have not seen this proposal, but cannot see why it would not work.
>
> Upon startup of the MGC, a UDP SC message could be sent to each MG with
the
> ServiceChangeMgcId set to the MGC IP address. To the MG, this message will
> look like a handover of the MGC to itself.
>
> Note this message is not a connection request, just a message to inform
the
> MG to re-establish new MGC connections.
>
> The first option is preferred (but none standard) as it caters for the
> problem where the MGC goes down and stays down.
>
> Regards
> Bill Groom
> Siemens
>
> -----Original Message-----
> From: Dan Elbert [mailto:DElbert@radvision.com]
> Sent: Thursday, April 26, 2001 5:06 PM
> To: 'megaco@fore.com'
> Subject: MGC failure
>
> Assume that the MGC goes down and up again.
> Is there any way for the MGC to indicate the MGs that they need to send a
> SVC, or is only the MGs responsibility to have some sort or "keep alive"
> (e.g. by sending a noop SVC if nothing is coming from the MGC in a long
> time). ?
> Note that the MGC doesn't know what port the MG is using.
> Related to this, what is the standard response if the MGC receives a
Notify
> from an MG that is not registered ? ( Because it was registered and then
MGC
> went down and up again) . Should it send a reply with an error so the MG
> knows that it must send a SVC, or just ignore it ?
>
> Thanks,
> Dan Elbert
> RADVISION


From owner-megaco@fore.com  Thu May  3 10:19:03 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25156
	for ; Thu, 3 May 2001 10:19:02 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11656;
	Thu, 3 May 2001 10:18:19 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA04682
	for megaco-list; Thu, 3 May 2001 10:16:49 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04670
	for ; Thu, 3 May 2001 10:16:48 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA11413
	for ; Thu, 3 May 2001 10:16:45 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id KAA08616; Thu, 3 May 2001 10:16:43 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Thu, 3 May 2001 10:16:18 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 3 May 2001 10:16:19 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CA9F@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Bemmel, Jeroen van (Jeroen)'" ,
        "'megaco@fore.com'" 
Subject: RE: Relationship Annex C values <=> package Property ID's
Date: Thu, 3 May 2001 10:16:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D3DB.9D209270"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D3DB.9D209270
Content-Type: text/plain;
	charset="iso-8859-1"

I have never fully understood the use of Annex C, so I can't give the
authoritative word on how it works.  Perhaps we need a discussion to clarify
the matter.

Here is my view of the nature of Annex C:

1) Annex C consists of properties which belong in various descriptors.  An
open action item is to specify the appropriate descriptor for each property.

2) Annex C is technically "package 0", which is available only for binary
encoding.  It represents relatively early thinking in the development of the
protocol.  To the extent to which it can be superseded by other packages, it
should be, both because the other packages group properties, signals, etc.
which should be implemented together and because the other packages provide
both text and binary encoding in the same place.

3) A considerable part of Annex C is devoted to bearer-related properties,
which belong in the Local and Remote descriptors.  (This statement is
subject to debate, but it can be justified on the grounds that it provides a
better fit with SIP than putting the properties into LocalControl.)  To
provide text-encoded equivalents, these properties have to be added to SDP.
Hence the importance in my mind of the ATM and TDM SDP extensions.

4) One of the thrusts behind Annex C was the concept of "native encoding".
This means that the values following the tags are allowed to be lifted from
a variety of other protocols.  I was startled the other day to learn that
you could ship PER-encoded H.245 inside Megaco/H.248, but I can't contradict
that notion: Annex C simply doesn't provide enough detail to accept or
reject it.  I will point out that there is a certain amount of modification
of Q.931-related values in Annex C, as an example, because the individual
values are unpacked from the octets within which Q.931 encodes them and
shifted to align with the octet boundary.  I see this as inconsistent with
simply taking globs of H.245 "as is" and shipping them to the other end, but
anything is possible with prior agreement.

5) I was never clear on what should follow the SDP-related tags.  To be
consistent with the H.245 approach, I suppose what would follow would be the
actual SDP text strings, but I don't know.

In conclusion: I think we need a clearer view of how Annex C is to be used
in general, we need to replace at least some of the Annex with properties
defined in other packages, and we need to specify which descriptors the
remaining properties should go in.

> -----Original Message-----
> From: Bemmel, Jeroen van (Jeroen) [mailto:jbemmel@lucent.com]
> Sent: Thursday, May 03, 2001 6:01 AM
> To: 'megaco@fore.com'
> Subject: Relationship Annex C values <=> package Property ID's
> 
> 
> Hello all,
>  
> The relationship between value tags in Annex C and attribute 
> identifiers in
> packages is unclear and confusing to me:
>  
> For instance, Annex C defines PropertyID Jitterbuff = 100D, 
> an unsigned
> integer 0-65535 representing time in ms
> Networkpackage defines Property ID jit = 0x0007 as an attribute to the
> LocalControlDescriptor
>  
> 1) Am I correct in assuming that the Annex C value is meant 
> to be assigned
> to LocalControlDescriptor.JitterBuffer ?
>  
> 2) If so, how come some of the other Annex C Property IDs are 
> not defined as
> attributes anywhere?
>  
> 3) And, if these attributes are not defined, then where is 
> the MG supposed
> to keep state information to report when receiving an audit request
>     for all terminations (eg step 19 in Appendix A - Example 
> call flows,
> resulting in a report of the RTP IP address (amongst others)) ?
>  
>  
> Jeroen van Bemmel
> Developer New Technologies
>  
> 

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






RE: Relationship Annex C values <=3D> package Property =
ID's




I have never fully understood the use of Annex C, so =
I can't give the authoritative word on how it works.  Perhaps we =
need a discussion to clarify the matter.



Here is my view of the nature of Annex C:




1) Annex C consists of properties which belong in =
various descriptors.  An open action item is to specify the =
appropriate descriptor for each property.



2) Annex C is technically "package 0", =
which is available only for binary encoding.  It represents =
relatively early thinking in the development of the protocol.  To =
the extent to which it can be superseded by other packages, it should =
be, both because the other packages group properties, signals, etc. =
which should be implemented together and because the other packages =
provide both text and binary encoding in the same place.



3) A considerable part of Annex C is devoted to =
bearer-related properties, which belong in the Local and Remote =
descriptors.  (This statement is subject to debate, but it can be =
justified on the grounds that it provides a better fit with SIP than =
putting the properties into LocalControl.)  To provide =
text-encoded equivalents, these properties have to be added to =
SDP.  Hence the importance in my mind of the ATM and TDM SDP =
extensions.



4) One of the thrusts behind Annex C was the concept =
of "native encoding".  This means that the values =
following the tags are allowed to be lifted from a variety of other =
protocols.  I was startled the other day to learn that you could =
ship PER-encoded H.245 inside Megaco/H.248, but I can't contradict that =
notion: Annex C simply doesn't provide enough detail to accept or =
reject it.  I will point out that there is a certain amount of =
modification of Q.931-related values in Annex C, as an example, because =
the individual values are unpacked from the octets within which Q.931 =
encodes them and shifted to align with the octet boundary.  I see =
this as inconsistent with simply taking globs of H.245 "as =
is" and shipping them to the other end, but anything is possible =
with prior agreement.



5) I was never clear on what should follow the =
SDP-related tags.  To be consistent with the H.245 approach, I =
suppose what would follow would be the actual SDP text strings, but I =
don't know.



In conclusion: I think we need a clearer view of how =
Annex C is to be used in general, we need to replace at least some of =
the Annex with properties defined in other packages, and we need to =
specify which descriptors the remaining properties should go =
in.



> -----Original Message-----

> From: Bemmel, Jeroen van (Jeroen) [mailto:jbemmel@lucent.com]=


> Sent: Thursday, May 03, 2001 6:01 AM

> To: 'megaco@fore.com'

> Subject: Relationship Annex C values =
<=3D> package Property ID's

> 

> 

> Hello all,

>  

> The relationship between value tags in Annex C =
and attribute 

> identifiers in

> packages is unclear and confusing to me:

>  

> For instance, Annex C defines PropertyID =
Jitterbuff =3D 100D, 

> an unsigned

> integer 0-65535 representing time in ms

> Networkpackage defines Property ID jit =3D =
0x0007 as an attribute to the

> LocalControlDescriptor

>  

> 1) Am I correct in assuming that the Annex C =
value is meant 

> to be assigned

> to LocalControlDescriptor.JitterBuffer ?

>  

> 2) If so, how come some of the other Annex C =
Property IDs are 

> not defined as

> attributes anywhere?

>  

> 3) And, if these attributes are not defined, =
then where is 

> the MG supposed

> to keep state information to report when =
receiving an audit request

>     for all terminations =
(eg step 19 in Appendix A - Example 

> call flows,

> resulting in a report of the RTP IP address =
(amongst others)) ?

>  

>  

> Jeroen van Bemmel

> Developer New Technologies

>  

> 





------_=_NextPart_001_01C0D3DB.9D209270--


From owner-megaco@fore.com  Thu May  3 10:21:10 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25224
	for ; Thu, 3 May 2001 10:21:09 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11939;
	Thu, 3 May 2001 10:20:25 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA05503
	for megaco-list; Thu, 3 May 2001 10:19:39 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA05498
	for ; Thu, 3 May 2001 10:19:37 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA11811
	for ; Thu, 3 May 2001 10:19:34 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id KAA08894; Thu, 3 May 2001 10:19:33 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Thu, 3 May 2001 10:19:15 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 3 May 2001 10:19:16 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CAA0@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Donald Hansil'" ,
        Steven Weisz ,
        "Megaco Mailing List (E-mail)" 
Subject: RE: Question regarding Wildcarding of TermationIds
Date: Thu, 3 May 2001 10:19:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D3DC.06E5E750"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D3DC.06E5E750
Content-Type: text/plain;
	charset="iso-8859-1"

You send a message to majordomo@fore.com.  Leave the subject line blank.
Within the message, place one line: "unsubscribe megaco" (without quotes).
If this does not work because your address doesn't match the one you
subscribed with, send a note to me (not the whole list) and I will
unsubscribe you.

> -----Original Message-----
> From: Donald Hansil [mailto:d_hansil@bellsouth.net]
> Sent: Wednesday, May 02, 2001 9:42 PM
> To: Steven Weisz; Megaco Mailing List (E-mail)
> Subject: RE: Question regarding Wildcarding of TermationIds
> 
> 
> Does anyone know how to unsubscribe to this mailing list?
> 
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Steven Weisz
> Sent: Tuesday, May 01, 2001 10:30 AM
> To: Megaco Mailing List (E-mail)
> Subject: Question regarding Wildcarding of TermationIds
> 
> Hi List,
> 
> I have two quick questions on wildcarding in TerminationIds.
> 
> 1) Can we have more than one "*" or "$" in a termination Id?
> 
> 2) is it legal to have "//" or "///" etc?
> 
> Thanks,
> 
> Steven Weisz
> 
> 

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






RE: Question regarding Wildcarding of TermationIds




You send a message to majordomo@fore.com.  Leave =
the subject line blank.  Within the message, place one line: =
"unsubscribe megaco" (without quotes).  If this does not =
work because your address doesn't match the one you subscribed with, =
send a note to me (not the whole list) and I will unsubscribe =
you.



> -----Original Message-----

> From: Donald Hansil [mailto:d_hansil@bellsouth.net=
]

> Sent: Wednesday, May 02, 2001 9:42 PM

> To: Steven Weisz; Megaco Mailing List =
(E-mail)

> Subject: RE: Question regarding Wildcarding of =
TermationIds

> 

> 

> Does anyone know how to unsubscribe to this =
mailing list?

> 

> 

> -----Original Message-----

> From: owner-megaco@pit.comms.marconi.com

> [mailto:owner-megaco@p=
it.comms.marconi.com]On Behalf Of Steven Weisz

> Sent: Tuesday, May 01, 2001 10:30 AM

> To: Megaco Mailing List (E-mail)

> Subject: Question regarding Wildcarding of =
TermationIds

> 

> Hi List,

> 

> I have two quick questions on wildcarding in =
TerminationIds.

> 

> 1) Can we have more than one "*" or =
"$" in a termination Id?

> 

> 2) is it legal to have "//" or =
"///" etc?

> 

> Thanks,

> 

> Steven Weisz

> 

> 





------_=_NextPart_001_01C0D3DC.06E5E750--


From owner-megaco@fore.com  Thu May  3 10:33:47 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25713
	for ; Thu, 3 May 2001 10:33:47 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13438;
	Thu, 3 May 2001 10:32:57 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA09389
	for megaco-list; Thu, 3 May 2001 10:31:49 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA09383
	for ; Thu, 3 May 2001 10:31:48 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 3 May 2001 10:31:38 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F555@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Tom-PT Taylor'" ,
        "'Bemmel, Jeroen van (Jeroen)'" ,
        "'megaco@fore.com'"
	 
Subject: RE: Relationship Annex C values <=> package Property ID's
Date: Thu, 3 May 2001 10:31:46 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0D3DD.C80444D0"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D3DD.C80444D0
Content-Type: text/plain;
	charset="iso-8859-1"

Wow, shows just how out of sync we all are -- Tom and I usually have the
same view of these kinds of things.
 
I thought Annex C is ONLY used in remote and local when binary encoding.
It replaces SDP.  When you text encode, you use SDP in remote and local,
when you binary encode you use Annex C in Remote and Local
 
It's not a "package" because you don't use any of the Annex C tags in
LocalControl
or TerminationState, and you don't ever use any other package defined
elements
in local and remote.  There was a certain amount of effort put into making
sure
whatever you could say in SDP, there was an equivalent in Annex C.
 
Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Thursday, May 03, 2001 10:16 AM
To: 'Bemmel, Jeroen van (Jeroen)'; 'megaco@fore.com'
Subject: RE: Relationship Annex C values <=> package Property ID's



I have never fully understood the use of Annex C, so I can't give the
authoritative word on how it works.  Perhaps we need a discussion to clarify
the matter.

Here is my view of the nature of Annex C: 

1) Annex C consists of properties which belong in various descriptors.  An
open action item is to specify the appropriate descriptor for each property.

2) Annex C is technically "package 0", which is available only for binary
encoding.  It represents relatively early thinking in the development of the
protocol.  To the extent to which it can be superseded by other packages, it
should be, both because the other packages group properties, signals, etc.
which should be implemented together and because the other packages provide
both text and binary encoding in the same place.

3) A considerable part of Annex C is devoted to bearer-related properties,
which belong in the Local and Remote descriptors.  (This statement is
subject to debate, but it can be justified on the grounds that it provides a
better fit with SIP than putting the properties into LocalControl.)  To
provide text-encoded equivalents, these properties have to be added to SDP.
Hence the importance in my mind of the ATM and TDM SDP extensions.

4) One of the thrusts behind Annex C was the concept of "native encoding".
This means that the values following the tags are allowed to be lifted from
a variety of other protocols.  I was startled the other day to learn that
you could ship PER-encoded H.245 inside Megaco/H.248, but I can't contradict
that notion: Annex C simply doesn't provide enough detail to accept or
reject it.  I will point out that there is a certain amount of modification
of Q.931-related values in Annex C, as an example, because the individual
values are unpacked from the octets within which Q.931 encodes them and
shifted to align with the octet boundary.  I see this as inconsistent with
simply taking globs of H.245 "as is" and shipping them to the other end, but
anything is possible with prior agreement.

5) I was never clear on what should follow the SDP-related tags.  To be
consistent with the H.245 approach, I suppose what would follow would be the
actual SDP text strings, but I don't know.

In conclusion: I think we need a clearer view of how Annex C is to be used
in general, we need to replace at least some of the Annex with properties
defined in other packages, and we need to specify which descriptors the
remaining properties should go in.

> -----Original Message----- 
> From: Bemmel, Jeroen van (Jeroen) [ mailto:jbemmel@lucent.com
 ] 
> Sent: Thursday, May 03, 2001 6:01 AM 
> To: 'megaco@fore.com' 
> Subject: Relationship Annex C values <=> package Property ID's 
> 
> 
> Hello all, 
>  
> The relationship between value tags in Annex C and attribute 
> identifiers in 
> packages is unclear and confusing to me: 
>  
> For instance, Annex C defines PropertyID Jitterbuff = 100D, 
> an unsigned 
> integer 0-65535 representing time in ms 
> Networkpackage defines Property ID jit = 0x0007 as an attribute to the 
> LocalControlDescriptor 
>  
> 1) Am I correct in assuming that the Annex C value is meant 
> to be assigned 
> to LocalControlDescriptor.JitterBuffer ? 
>  
> 2) If so, how come some of the other Annex C Property IDs are 
> not defined as 
> attributes anywhere? 
>  
> 3) And, if these attributes are not defined, then where is 
> the MG supposed 
> to keep state information to report when receiving an audit request 
>     for all terminations (eg step 19 in Appendix A - Example 
> call flows, 
> resulting in a report of the RTP IP address (amongst others)) ? 
>  
>  
> Jeroen van Bemmel 
> Developer New Technologies 
>  
> 


------_=_NextPart_001_01C0D3DD.C80444D0
Content-Type: text/html;
	charset="iso-8859-1"




RE: Relationship Annex C values <=> package Property ID's




Wow, shows 
just how out of sync we all are -- Tom and I usually have 
the


same view of 
these kinds of things.


 


I thought 
Annex C is ONLY used in remote and local when binary 
encoding.


It replaces 
SDP.  When you text encode, you use SDP in remote and 
local,


when you 
binary encode you use Annex C in Remote and Local


 


It's not a 
"package" because you don't use any of the Annex C tags in 
LocalControl


or 
TerminationState, and you don't ever use any other package defined 
elements


in local and 
remote.  There was a certain amount of effort put into making 
sure


whatever you 
could say in SDP, there was an equivalent in Annex C.


 


Brian



  
-----Original Message-----
From: Tom-PT Taylor 
  [mailto:taylor@nortelnetworks.com]
Sent: Thursday, May 03, 2001 
  10:16 AM
To: 'Bemmel, Jeroen van (Jeroen)'; 
  'megaco@fore.com'
Subject: RE: Relationship Annex C values <=> 
  package Property ID's


  
I have never fully understood the use of Annex C, so I can't 
  give the authoritative word on how it works.  Perhaps we need a 
  discussion to clarify the matter.

  
Here is my view of the nature of Annex C: 

  
1) Annex C consists of properties which belong in various 
  descriptors.  An open action item is to specify the appropriate 
  descriptor for each property.

  
2) Annex C is technically "package 0", which is available only 
  for binary encoding.  It represents relatively early thinking in the 
  development of the protocol.  To the extent to which it can be superseded 
  by other packages, it should be, both because the other packages group 
  properties, signals, etc. which should be implemented together and because the 
  other packages provide both text and binary encoding in the same 
  place.

  
3) A considerable part of Annex C is devoted to bearer-related 
  properties, which belong in the Local and Remote descriptors.  (This 
  statement is subject to debate, but it can be justified on the grounds that it 
  provides a better fit with SIP than putting the properties into 
  LocalControl.)  To provide text-encoded equivalents, these properties 
  have to be added to SDP.  Hence the importance in my mind of the ATM and 
  TDM SDP extensions.

  
4) One of the thrusts behind Annex C was the concept of 
  "native encoding".  This means that the values following the tags are 
  allowed to be lifted from a variety of other protocols.  I was startled 
  the other day to learn that you could ship PER-encoded H.245 inside 
  Megaco/H.248, but I can't contradict that notion: Annex C simply doesn't 
  provide enough detail to accept or reject it.  I will point out that 
  there is a certain amount of modification of Q.931-related values in Annex C, 
  as an example, because the individual values are unpacked from the octets 
  within which Q.931 encodes them and shifted to align with the octet 
  boundary.  I see this as inconsistent with simply taking globs of H.245 
  "as is" and shipping them to the other end, but anything is possible with 
  prior agreement.

  
5) I was never clear on what should follow the SDP-related 
  tags.  To be consistent with the H.245 approach, I suppose what would 
  follow would be the actual SDP text strings, but I don't know.

  
In conclusion: I think we need a clearer view of how Annex C 
  is to be used in general, we need to replace at least some of the Annex with 
  properties defined in other packages, and we need to specify which descriptors 
  the remaining properties should go in.

  
> -----Original Message----- 
> 
  From: Bemmel, Jeroen van (Jeroen) [mailto:jbemmel@lucent.com] 
  
> Sent: Thursday, May 03, 2001 6:01 AM 
> To: 'megaco@fore.com' 
> Subject: 
  Relationship Annex C values <=> package Property ID's 
> 
> 
> Hello 
  all, 
>  
> The 
  relationship between value tags in Annex C and attribute 
> identifiers in 
> packages is unclear 
  and confusing to me: 
>  
> For instance, Annex C defines PropertyID Jitterbuff = 100D, 
  
> an unsigned 
> integer 
  0-65535 representing time in ms 
> Networkpackage 
  defines Property ID jit = 0x0007 as an attribute to the 
> LocalControlDescriptor 
>  
  
> 1) Am I correct in assuming that the Annex C 
  value is meant 
> to be assigned 
> to LocalControlDescriptor.JitterBuffer ? 
>  
> 2) If so, how come some of the 
  other Annex C Property IDs are 
> not defined 
  as 
> attributes anywhere? 
>  
> 3) And, if these attributes are 
  not defined, then where is 
> the MG supposed 
  
> to keep state information to report when receiving an 
  audit request 
>     for all 
  terminations (eg step 19 in Appendix A - Example 
> 
  call flows, 
> resulting in a report of the RTP IP 
  address (amongst others)) ? 
>  
  
>  
> Jeroen van 
  Bemmel 
> Developer New Technologies 
  
>  
> 



------_=_NextPart_001_01C0D3DD.C80444D0--


From owner-megaco@fore.com  Thu May  3 10:45:47 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26121
	for ; Thu, 3 May 2001 10:45:47 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14961;
	Thu, 3 May 2001 10:44:58 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA13196
	for megaco-list; Thu, 3 May 2001 10:43:56 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13184
	for ; Thu, 3 May 2001 10:43:54 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14796
	for ; Thu, 3 May 2001 10:43:51 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1])
	by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f43EhpK19322
	for ; Thu, 3 May 2001 10:43:51 -0400 (EDT)
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f43EhoS19277
	for ; Thu, 3 May 2001 10:43:50 -0400 (EDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 3 May 2001 16:43:49 +0200
Message-ID: 
From: "Bemmel, Jeroen van (Jeroen)" 
To: "'Rosen, Brian'" ,
        "'Tom-PT Taylor'"
	 ,
        "Bemmel, Jeroen van (Jeroen)"
	 ,
        "'megaco@fore.com'" 
Subject: RE: Relationship Annex C values <=> package Property ID's
Date: Thu, 3 May 2001 16:43:43 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

That still leaves the question about where the state information should go,
regardless of the type of encoding used
 
I noticed that none of the packages defined so far defines any attributes
for local or remote. However, does this mean it is not allowed?


From owner-megaco@fore.com  Thu May  3 10:53:10 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26442
	for ; Thu, 3 May 2001 10:53:09 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15889;
	Thu, 3 May 2001 10:52:23 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA15446
	for megaco-list; Thu, 3 May 2001 10:51:30 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15436
	for ; Thu, 3 May 2001 10:51:28 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15742
	for ; Thu, 3 May 2001 10:51:25 -0400 (EDT)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f43EpMO17071
	for ; Thu, 3 May 2001 16:51:23 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu May 03 16:51:21 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Thu, 3 May 2001 16:51:21 +0200
Message-ID: <795A014AF92DD21182AF0008C7A404320B070375@esealnt117>
From: "Alf Heidermark (UAB)" 
To: "'Megaco (E-mail)" 
Subject: MTP 3 interworking
Date: Thu, 3 May 2001 16:51:14 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

When studying some network scenario for a certain network, we see a need for evolve the signalling transport from SS7 MTP3B in an ATM environment to the use of SCTP in Ip enviroenment. To provide this we see a need for M3UA on top of SCTP We have also see that M3UA supports a flexible implementation scenarios. Therefore some addition indicating the use of M3UA on top of SCTP needs to specified in Annex H in H.248. 


From owner-megaco@fore.com  Thu May  3 11:19:32 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27138
	for ; Thu, 3 May 2001 11:19:31 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18956;
	Thu, 3 May 2001 11:18:39 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA24013
	for megaco-list; Thu, 3 May 2001 11:17:25 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23992
	for ; Thu, 3 May 2001 11:17:23 -0400 (EDT)
Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18748
	for ; Thu, 3 May 2001 11:17:20 -0400 (EDT)
Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1])
	by alemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f43FHLK28054
	for ; Thu, 3 May 2001 11:17:22 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by alemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f43FHL928038
	for ; Thu, 3 May 2001 11:17:21 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA22556; Thu, 3 May 2001 11:17:20 -0400 (EDT)
Cc: "'Tom-PT Taylor'" ,
        "'Bemmel, Jeroen van (Jeroen)'" ,
        "'megaco@fore.com'" 
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA22523; Thu, 3 May 2001 11:17:16 -0400 (EDT)
Message-ID: <3AF17608.48ACC612@lucent.com>
Date: Thu, 03 May 2001 11:15:21 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" 
Original-CC: "'Tom-PT Taylor'" ,
        "'Bemmel, Jeroen van (Jeroen)'" ,
        "'megaco@fore.com'" 
Subject: Re: Relationship Annex C values <=> package Property ID's
References: <4FBEA8857476D311A03300204840E1CF01A6F555@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: multipart/alternative;
 boundary="------------9A50D243F1A972EF9F465C55"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------9A50D243F1A972EF9F465C55
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Section C.11 is a line by line SDP replacement.  Some of the other Annex C
items seem to be alternative encodings of information that could be encoded
as SDP.

IMHO, if any Annex C items don't have corresponding SDP elements, they
should be removed.  It is fundamentally wrong to have features that are only
accessible to the ASN.1 encoding of the protocol.  We should be striving
for uniformity.

People who need the non-SDP supported features currently in Annex C
should be developing Packages, rather than going with an ASN.1 only
solution.

Can we seek out  and remove non-SDP supported features in Annex C?

-troy


"Rosen, Brian" wrote:

>  Wow, shows just how out of sync we all are -- Tom and I usually have thesame
> view of these kinds of things.I thought Annex C is ONLY used in remote and
> local when binary encoding.It replaces SDP.  When you text encode, you use
> SDP in remote and local,when you binary encode you use Annex C in Remote and
> LocalIt's not a "package" because you don't use any of the Annex C tags in
> LocalControlor TerminationState, and you don't ever use any other package
> defined elementsin local and remote.  There was a certain amount of effort
> put into making surewhatever you could say in SDP, there was an equivalent in
> Annex C.Brian
>
>      -----Original Message-----
>      From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>      Sent: Thursday, May 03, 2001 10:16 AM
>      To: 'Bemmel, Jeroen van (Jeroen)'; 'megaco@fore.com'
>      Subject: RE: Relationship Annex C values <=> package Property ID's
>
>      I have never fully understood the use of Annex C, so I can't give
>      the authoritative word on how it works.  Perhaps we need a
>      discussion to clarify the matter.
>
>      Here is my view of the nature of Annex C:
>
>      1) Annex C consists of properties which belong in various
>      descriptors.  An open action item is to specify the appropriate
>      descriptor for each property.
>
>      2) Annex C is technically "package 0", which is available only for
>      binary encoding.  It represents relatively early thinking in the
>      development of the protocol.  To the extent to which it can be
>      superseded by other packages, it should be, both because the other
>      packages group properties, signals, etc. which should be
>      implemented together and because the other packages provide both
>      text and binary encoding in the same place.
>
>      3) A considerable part of Annex C is devoted to bearer-related
>      properties, which belong in the Local and Remote descriptors.
>      (This statement is subject to debate, but it can be justified on
>      the grounds that it provides a better fit with SIP than putting the
>      properties into LocalControl.)  To provide text-encoded
>      equivalents, these properties have to be added to SDP.  Hence the
>      importance in my mind of the ATM and TDM SDP extensions.
>
>      4) One of the thrusts behind Annex C was the concept of "native
>      encoding".  This means that the values following the tags are
>      allowed to be lifted from a variety of other protocols.  I was
>      startled the other day to learn that you could ship PER-encoded
>      H.245 inside Megaco/H.248, but I can't contradict that notion:
>      Annex C simply doesn't provide enough detail to accept or reject
>      it.  I will point out that there is a certain amount of
>      modification of Q.931-related values in Annex C, as an example,
>      because the individual values are unpacked from the octets within
>      which Q.931 encodes them and shifted to align with the octet
>      boundary.  I see this as inconsistent with simply taking globs of
>      H.245 "as is" and shipping them to the other end, but anything is
>      possible with prior agreement.
>
>      5) I was never clear on what should follow the SDP-related tags.
>      To be consistent with the H.245 approach, I suppose what would
>      follow would be the actual SDP text strings, but I don't know.
>
>      In conclusion: I think we need a clearer view of how Annex C is to
>      be used in general, we need to replace at least some of the Annex
>      with properties defined in other packages, and we need to specify
>      which descriptors the remaining properties should go in.
>
>      > -----Original Message-----
>      > From: Bemmel, Jeroen van (Jeroen) [mailto:jbemmel@lucent.com]
>      > Sent: Thursday, May 03, 2001 6:01 AM
>      > To: 'megaco@fore.com'
>      > Subject: Relationship Annex C values <=> package Property ID's
>      >
>      >
>      > Hello all,
>      >
>      > The relationship between value tags in Annex C and attribute
>      > identifiers in
>      > packages is unclear and confusing to me:
>      >
>      > For instance, Annex C defines PropertyID Jitterbuff = 100D,
>      > an unsigned
>      > integer 0-65535 representing time in ms
>      > Networkpackage defines Property ID jit = 0x0007 as an attribute
>      to the
>      > LocalControlDescriptor
>      >
>      > 1) Am I correct in assuming that the Annex C value is meant
>      > to be assigned
>      > to LocalControlDescriptor.JitterBuffer ?
>      >
>      > 2) If so, how come some of the other Annex C Property IDs are
>      > not defined as
>      > attributes anywhere?
>      >
>      > 3) And, if these attributes are not defined, then where is
>      > the MG supposed
>      > to keep state information to report when receiving an audit
>      request
>      >     for all terminations (eg step 19 in Appendix A - Example
>      > call flows,
>      > resulting in a report of the RTP IP address (amongst others)) ?
>      >
>      >
>      > Jeroen van Bemmel
>      > Developer New Technologies
>      >
>      >
>

--------------9A50D243F1A972EF9F465C55
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

Section C.11 is a line by line SDP replacement.  Some of the other
Annex C

items seem to be alternative encodings of information that could
be encoded

as SDP.

IMHO, if any Annex C items don't have corresponding SDP elements, they

should be removed.  It is fundamentally wrong to have features
that are only

accessible to the ASN.1 encoding of the protocol.  We should be
striving

for uniformity.

People who need the non-SDP supported features currently in Annex C

should be developing Packages, rather than going with an ASN.1 only

solution.

Can we seek out  and remove non-SDP supported features in Annex
C?

-troy

 

"Rosen, Brian" wrote:

 Wow,
shows just how out of sync we all are -- Tom and I usually have thesame
view of these kinds of things.I
thought Annex C is ONLY used in remote and local when binary encoding.It
replaces SDP.  When you text encode, you use SDP in remote and local,when
you binary encode you use Annex C in Remote and LocalIt's
not a "package" because you don't use any of the Annex C tags in LocalControlor
TerminationState, and you don't ever use any other package defined elementsin
local and remote.  There was a certain amount of effort put into making
surewhatever
you could say in SDP, there was an equivalent in Annex C.Brian



-----Original
Message-----

From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]

Sent: Thursday, May 03, 2001
10:16 AM

To: 'Bemmel, Jeroen van (Jeroen)';
'megaco@fore.com'

Subject: RE: Relationship
Annex C values <=> package Property ID's

 

I have never fully understood the use of Annex C, so I can't
give the authoritative word on how it works.  Perhaps we need a discussion
to clarify the matter.

Here is my view of the nature of Annex C:

1) Annex C consists of properties which belong in various
descriptors.  An open action item is to specify the appropriate descriptor
for each property.

2) Annex C is technically "package 0", which is available
only for binary encoding.  It represents relatively early thinking
in the development of the protocol.  To the extent to which it can
be superseded by other packages, it should be, both because the other packages
group properties, signals, etc. which should be implemented together and
because the other packages provide both text and binary encoding in the
same place.

3) A considerable part of Annex C is devoted to bearer-related
properties, which belong in the Local and Remote descriptors.  (This
statement is subject to debate, but it can be justified on the grounds
that it provides a better fit with SIP than putting the properties into
LocalControl.)  To provide text-encoded equivalents, these properties
have to be added to SDP.  Hence the importance in my mind of the ATM
and TDM SDP extensions.

4) One of the thrusts behind Annex C was the concept of
"native encoding".  This means that the values following the tags
are allowed to be lifted from a variety of other protocols.  I was
startled the other day to learn that you could ship PER-encoded H.245 inside
Megaco/H.248, but I can't contradict that notion: Annex C simply doesn't
provide enough detail to accept or reject it.  I will point out that
there is a certain amount of modification of Q.931-related values in Annex
C, as an example, because the individual values are unpacked from the octets
within which Q.931 encodes them and shifted to align with the octet boundary. 
I see this as inconsistent with simply taking globs of H.245 "as is" and
shipping them to the other end, but anything is possible with prior agreement.

5) I was never clear on what should follow the SDP-related
tags.  To be consistent with the H.245 approach, I suppose what would
follow would be the actual SDP text strings, but I don't know.

In conclusion: I think we need a clearer view of how Annex
C is to be used in general, we need to replace at least some of the Annex
with properties defined in other packages, and we need to specify which
descriptors the remaining properties should go in.

> -----Original Message-----

> From: Bemmel, Jeroen van (Jeroen) [mailto:jbemmel@lucent.com]

> Sent: Thursday, May 03, 2001 6:01 AM

> To: 'megaco@fore.com'

> Subject: Relationship Annex C values <=> package
Property ID's

>

>

> Hello all,

>

> The relationship between value tags in Annex C and
attribute

> identifiers in

> packages is unclear and confusing to me:

>

> For instance, Annex C defines PropertyID Jitterbuff
= 100D,

> an unsigned

> integer 0-65535 representing time in ms

> Networkpackage defines Property ID jit = 0x0007 as
an attribute to the

> LocalControlDescriptor

>

> 1) Am I correct in assuming that the Annex C value
is meant

> to be assigned

> to LocalControlDescriptor.JitterBuffer ?

>

> 2) If so, how come some of the other Annex C Property
IDs are

> not defined as

> attributes anywhere?

>

> 3) And, if these attributes are not defined, then where
is

> the MG supposed

> to keep state information to report when receiving
an audit request

>     for all terminations (eg step
19 in Appendix A - Example

> call flows,

> resulting in a report of the RTP IP address (amongst
others)) ?

>

>

> Jeroen van Bemmel

> Developer New Technologies

>

>





--------------9A50D243F1A972EF9F465C55--



From owner-megaco@fore.com  Thu May  3 11:55:22 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28068
	for ; Thu, 3 May 2001 11:55:22 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23087;
	Thu, 3 May 2001 11:54:33 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA07470
	for megaco-list; Thu, 3 May 2001 11:53:21 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA07320
	for ; Thu, 3 May 2001 11:52:40 -0400 (EDT)
Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22785
	for ; Thu, 3 May 2001 11:52:29 -0400 (EDT)
Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1])
	by alemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f43FqUK09704
	for ; Thu, 3 May 2001 11:52:30 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by alemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f43FqU909699
	for ; Thu, 3 May 2001 11:52:30 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA26772; Thu, 3 May 2001 11:52:28 -0400 (EDT)
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA26768; Thu, 3 May 2001 11:52:27 -0400 (EDT)
Message-ID: <3AF17E48.4952ACFD@lucent.com>
Date: Thu, 03 May 2001 11:50:32 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: MEGACO list 
Subject: multiple digitmaps
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


MEGACO/1 [12.12.12.12]:12345
Transaction = 1030 {Context = - {Modify = ROOT {
  DigitMap = Pin {(xxxx|xxxxxx)},
  DigitMap = UserId {(xxxxxx)},
  DigitMap = Dialplan0 {(0|00|911|1xxxxxxxxxx|Exx|[2-9]xxxxxx|9011x.)}
}}}


Multiple digitmaps in Add/Move/Modify parameters are 
currently illegal based on comments in Annex A and B.  
This seems pretty useful.


Proposal:

In Annex B, rewrite the comment above the "ammParameter" spec as:
	; at-most-once except for digitMapDescriptor.

In Annex A, rewrite the comment in the "AmmRequest" spec as:
	-- At most one descriptor of each type (see AmmDescriptor)
	-- allowed in the sequence, except for DigitMapDescriptor.


-troy


From owner-megaco@fore.com  Thu May  3 12:01:03 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28335
	for ; Thu, 3 May 2001 12:01:03 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA23756;
	Thu, 3 May 2001 12:00:14 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA09789
	for megaco-list; Thu, 3 May 2001 11:59:15 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA09752
	for ; Thu, 3 May 2001 11:57:52 -0400 (EDT)
From: rezhirpavai@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23444
	for ; Thu, 3 May 2001 11:57:45 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f43Fm9r12800;
	Thu, 3 May 2001 21:18:09 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A41.00555EB8 ; Thu, 3 May 2001 21:02:28 +0530
X-Lotus-FromDomain: HSS
To: "Rosen, Brian" 
cc: "'titty@cdotb.ernet.in'" ,
        Madhu Babu Brahmanapally ,
        "'megaco mail list'" 
Message-ID: <65256A41.00555D11.00@sandesh.hss.hns.com>
Date: Thu, 3 May 2001 21:09:51 +0530
Subject: RE: Error in transaction reply.
Mime-Version: 1.0
Content-type: multipart/mixed;
	Boundary="0__=nlk7A1TsKMpGBdXBgTvoV7LIGkwwIsFe3ICm44s4EFjEgVTmn2L44J5v"
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

--0__=nlk7A1TsKMpGBdXBgTvoV7LIGkwwIsFe3ICm44s4EFjEgVTmn2L44J5v
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Hello,
     There could be an alternative to
"Of course, you could get a syntax error on a transactionAck!  I think we can
either ignore that possibility, or allow the Ack the other way.  I'd vote
the former."
The MG at this point just needs to know whether the MGC has processed the
response or not. Thus it needs to know only the transaction id for the response
which had failed. So the transactionAck with error descriptor could be replaced
with a subtractTransaction which contains just the transaction id. If the MG
understands the subtractTransaction token and the transaction id, it could undo
the changes. If it fails to decode the token or the transaction id, anyhow a
message level error should be generated in which case the action for handling a
message level error would come into action.

                                         Regards,
                                         R. Ezhirpavai






"Rosen, Brian"  on 05/03/2001 06:48:17 PM

To:   "'titty@cdotb.ernet.in'" , R Ezhirpavai/HSS@HSS
cc:   Madhu Babu Brahmanapally , "'megaco mail list'"
      

Subject:  RE: Error in transaction reply.




I'm beginning to think that maybe we ought to do something about this.

First of all, every one of these discussions around syntax errors often
misses
a real important point
    There is basically no recovery possible for the error
This is because there is no way either end is going to change the SYNTAX
of the message it sends as a result of an error.  It's going to take the
offending
programmer to do that (20 lashes with a wet noodle please).  Your only
real recourse is:
    Don't do whatever caused that problem to happen, until the software is
fixed

Now, having said that, real systems often have problems and vendors need
a way to figure out what happened and even customers need a way to figure
out that something wrong happened so they at least have a shot at a
workaround.

The best solution I can come up with is a real change to the protocol, and
I'm not
at all wild about proposing something that actually changes things, but here
goes:

Send a TransactionAck (even if you are using a reliable transport) with an
error
message.

Of course, you could get a syntax error on a transactionAck!  I think we can
either ignore that possibility, or allow the Ack the other way.  I'd vote
the former.

Brian

-----Original Message-----
From: Titty Thomas [mailto:titty@jnana.cdotb.ernet.in]
Sent: Wednesday, May 02, 2001 11:39 PM
To: rezhirpavai@hss.hns.com
Cc: Madhu Babu Brahmanapally; titty@cdotb.ernet.in; 'megaco mail list'
Subject: Re: Error in transaction reply.


Hi ,

    In this case one of the options can be to audit the MG and find out its
state.

Regards,
-- Titty


rezhirpavai@hss.hns.com wrote:


Hello Madhu,
     If the MGC assumes that the transaction response containing a parse
error
is a transaction reply with error, then this would lead to discrepancy
between
the states of MG and MGC. The MGC would assume that the MG has not processed
the
request whereas the MG would have processed the request and would have
possibly
changed the termination state.

                                         Regards,
                                         R. Ezhirpavai


"Madhu Babu Brahmanapally"  on 05/02/2001 07:09:47 PM



To:   titty@cdotb.ernet.in, "'megaco mail list'" 
cc:    (bcc: R Ezhirpavai/HSS)


Subject:  RE: Error in transaction reply.


Hi Titty,


In normal circumstances, even if the MGC retransmit its transaction-request
the same transaction response is received from MG. IMO the MGC can treat the

error transaction response as error response from MG.
Regards
Madhubabu


 -----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[ mailto:owner-megaco@pit.comms.marconi.com
 ]On Behalf Of Titty Thomas
Sent: Wednesday, May 02, 2001 12:04 AM
To: megaco mail list
Subject: Error in transaction reply.


  Hi all,


      If there is an error in transaction reply, what will the receiver of
the reply do. How
  can he report back to the sender that the reply was an error. And what
will happen if


  the reply had some values chosen by the sender (eg. reply for a command
with $ ) and the


  value is in error.


  Regards,


  - Titty


--
+------------------------------------------------------------------+
|Two roads diverged in a wood, and I took the one less traveled by,|
|And that has made all the difference.                             |
+------------------------------------------------------------------+


  ------------------------------------------------------------------------
                  Name: att1.htm
   att1.htm       Type: Hypertext Markup Language (text/html)
              Encoding: base64
           Description: Internet HTML

--

+------------------------------------------------------------------+

|Two roads diverged in a wood, and I took the one less traveled by,|

|And that has made all the difference.                             |

+------------------------------------------------------------------+




--0__=nlk7A1TsKMpGBdXBgTvoV7LIGkwwIsFe3ICm44s4EFjEgVTmn2L44J5v
Content-type: text/html;
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U
RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+DQoNCg0KPE1FVEEgY29udGVudD0i
TVNIVE1MIDUuMDAuMjkyMC4wIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWT4NCjxESVY+
PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsPjxTUEFOIGNsYXNzPTkwNTA2MTExMy0wMzA1
MjAwMT5JJ20gYmVnaW5uaW5nIA0KdG8gdGhpbmsgdGhhdCBtYXliZSB3ZSBvdWdodCB0byBkbyBz
b21ldGhpbmcgYWJvdXQgdGhpcy48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xv
cj0jMDAwMGZmIGZhY2U9QXJpYWw+PFNQQU4gDQpjbGFzcz05MDUwNjExMTMtMDMwNTIwMDE+PC9T
UEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFy
aWFsPjxTUEFOIGNsYXNzPTkwNTA2MTExMy0wMzA1MjAwMT5GaXJzdCBvZiBhbGwsIA0KZXZlcnkg
b25lIG9mIHRoZXNlIGRpc2N1c3Npb25zIGFyb3VuZCBzeW50YXggZXJyb3JzIG9mdGVuIA0KbWlz
c2VzPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFy
aWFsPjxTUEFOIGNsYXNzPTkwNTA2MTExMy0wMzA1MjAwMT5hIHJlYWwgDQppbXBvcnRhbnQgcG9p
bnQ8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJp
YWw+PFNQQU4gDQpjbGFzcz05MDUwNjExMTMtMDMwNTIwMDE+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo
ZXJlIGlzIGJhc2ljYWxseSBubyByZWNvdmVyeSANCnBvc3NpYmxlIGZvciB0aGUgZXJyb3I8L1NQ
QU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWw+PFNQ
QU4gY2xhc3M9OTA1MDYxMTEzLTAzMDUyMDAxPlRoaXMgaXMgDQpiZWNhdXNlIHRoZXJlIGlzIG5v
IHdheSBlaXRoZXIgZW5kIGlzIGdvaW5nIHRvIGNoYW5nZSB0aGUgDQpTWU5UQVg8L1NQQU4+PC9G
T05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWw+PFNQQU4gY2xh
c3M9OTA1MDYxMTEzLTAzMDUyMDAxPm9mIHRoZSANCm1lc3NhZ2UgaXQgc2VuZHMgYXMgYSByZXN1
bHQgb2YgYW4gZXJyb3IuJm5ic3A7IEl0J3MgZ29pbmcgdG8gdGFrZSB0aGUgDQpvZmZlbmRpbmc8
L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWw+
PFNQQU4gY2xhc3M9OTA1MDYxMTEzLTAzMDUyMDAxPnByb2dyYW1tZXIgdG8gDQpkbyB0aGF0ICgy
MCBsYXNoZXMgd2l0aCBhIHdldCBub29kbGUgcGxlYXNlKS4mbmJzcDsgWW91ciANCm9ubHk8L1NQ
QU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWw+PFNQ
QU4gY2xhc3M9OTA1MDYxMTEzLTAzMDUyMDAxPnJlYWwgcmVjb3Vyc2UgDQppczo8L1NQQU4+PC9G
T05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWw+PFNQQU4gDQpj
bGFzcz05MDUwNjExMTMtMDMwNTIwMDE+Jm5ic3A7Jm5ic3A7Jm5ic3A7IERvbid0IGRvIHdoYXRl
dmVyIGNhdXNlZCB0aGF0IA0KcHJvYmxlbSB0byBoYXBwZW4sIHVudGlsIHRoZSBzb2Z0d2FyZSBp
cyBmaXhlZDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFj
ZT1BcmlhbD48U1BBTiANCmNsYXNzPTkwNTA2MTExMy0wMzA1MjAwMT48L1NQQU4+PC9GT05UPiZu
YnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWw+PFNQQU4gY2xh
c3M9OTA1MDYxMTEzLTAzMDUyMDAxPk5vdywgaGF2aW5nIA0Kc2FpZCB0aGF0LCByZWFsIHN5c3Rl
bXMgb2Z0ZW4gaGF2ZSBwcm9ibGVtcyBhbmQgdmVuZG9ycyBuZWVkPC9TUEFOPjwvRk9OVD48L0RJ
Vj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsPjxTUEFOIGNsYXNzPTkwNTA2
MTExMy0wMzA1MjAwMT5hIHdheSB0byANCmZpZ3VyZSBvdXQgd2hhdCBoYXBwZW5lZCBhbmQgZXZl
biBjdXN0b21lcnMgbmVlZCBhIHdheSB0byANCmZpZ3VyZTwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8
RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbD48U1BBTiBjbGFzcz05MDUwNjExMTMt
MDMwNTIwMDE+b3V0IHRoYXQgDQpzb21ldGhpbmcgd3JvbmcgaGFwcGVuZWQgc28gdGhleSBhdCBs
ZWFzdCBoYXZlIGEgc2hvdCBhdCBhIA0Kd29ya2Fyb3VuZC48L1NQQU4+PC9GT05UPjwvRElWPg0K
PERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWw+PFNQQU4gDQpjbGFzcz05MDUwNjEx
MTMtMDMwNTIwMDE+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9
IzAwMDBmZiBmYWNlPUFyaWFsPjxTUEFOIGNsYXNzPTkwNTA2MTExMy0wMzA1MjAwMT5UaGUgYmVz
dCANCnNvbHV0aW9uIEkgY2FuIGNvbWUgdXAgd2l0aCBpcyBhIHJlYWwgY2hhbmdlIHRvIHRoZSBw
cm90b2NvbCwgYW5kIEknbSANCm5vdDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNv
bG9yPSMwMDAwZmYgZmFjZT1BcmlhbD48U1BBTiBjbGFzcz05MDUwNjExMTMtMDMwNTIwMDE+YXQg
YWxsIHdpbGQgDQphYm91dCBwcm9wb3Npbmcgc29tZXRoaW5nIHRoYXQgYWN0dWFsbHkgY2hhbmdl
cyB0aGluZ3MsIGJ1dCBoZXJlIA0KZ29lczo8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9O
VCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWw+PFNQQU4gDQpjbGFzcz05MDUwNjExMTMtMDMwNTIw
MDE+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBm
YWNlPUFyaWFsPjxTUEFOIGNsYXNzPTkwNTA2MTExMy0wMzA1MjAwMT5TZW5kIGEgDQpUcmFuc2Fj
dGlvbkFjayAoZXZlbiBpZiB5b3UgYXJlIHVzaW5nIGEgcmVsaWFibGUgdHJhbnNwb3J0KSB3aXRo
IGFuIA0KZXJyb3I8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZm
IGZhY2U9QXJpYWw+PFNQQU4gDQpjbGFzcz05MDUwNjExMTMtMDMwNTIwMDE+bWVzc2FnZS48L1NQ
QU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWw+PFNQ
QU4gDQpjbGFzcz05MDUwNjExMTMtMDMwNTIwMDE+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4N
CjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsPjxTUEFOIGNsYXNzPTkwNTA2MTEx
My0wMzA1MjAwMT5PZiBjb3Vyc2UsIA0KeW91IGNvdWxkIGdldCBhIHN5bnRheCBlcnJvciBvbiBh
IHRyYW5zYWN0aW9uQWNrISZuYnNwOyBJIHRoaW5rIHdlIA0KY2FuPC9TUEFOPjwvRk9OVD48L0RJ
Vj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsPjxTUEFOIGNsYXNzPTkwNTA2
MTExMy0wMzA1MjAwMT5laXRoZXIgaWdub3JlIA0KdGhhdCBwb3NzaWJpbGl0eSwgb3IgYWxsb3cg
dGhlIEFjayB0aGUgb3RoZXIgd2F5LiZuYnNwOyBJJ2Qgdm90ZSB0aGUgDQpmb3JtZXIuPC9TUEFO
PjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsPjxTUEFO
IA0KY2xhc3M9OTA1MDYxMTEzLTAzMDUyMDAxPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8
RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbD48U1BBTiANCmNsYXNzPTkwNTA2MTEx
My0wMzA1MjAwMT5CcmlhbjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8QkxPQ0tRVU9URSANCnN0eWxl
PSJCT1JERVItTEVGVDogIzAwMDBmZiAycHggc29saWQ7IE1BUkdJTi1MRUZUOiA1cHg7IFBBRERJ
TkctTEVGVDogNXB4Ij4NCiAgPERJViBhbGlnbj1sZWZ0IGNsYXNzPU91dGxvb2tNZXNzYWdlSGVh
ZGVyIGRpcj1sdHI+PEZPTlQgZmFjZT1UYWhvbWEgDQogIHNpemU9Mj4tLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gVGl0dHkgVGhvbWFzIA0KICBbbWFpbHRvOnRpdHR5
QGpuYW5hLmNkb3RiLmVybmV0LmluXTxCUj48Qj5TZW50OjwvQj4gV2VkbmVzZGF5LCBNYXkgMDIs
IDIwMDEgDQogIDExOjM5IFBNPEJSPjxCPlRvOjwvQj4gcmV6aGlycGF2YWlAaHNzLmhucy5jb208
QlI+PEI+Q2M6PC9CPiBNYWRodSBCYWJ1IA0KICBCcmFobWFuYXBhbGx5OyB0aXR0eUBjZG90Yi5l
cm5ldC5pbjsgJ21lZ2FjbyBtYWlsIGxpc3QnPEJSPjxCPlN1YmplY3Q6PC9CPiBSZTogDQogIEVy
cm9yIGluIHRyYW5zYWN0aW9uIHJlcGx5LjxCUj48QlI+PC9ESVY+PC9GT05UPkhpICwgPEJSPiZu
YnNwOyANCiAgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBJbiB0aGlzIGNhc2Ugb25lIG9mIHRoZSBv
cHRpb25zIGNhbiBiZSB0byBhdWRpdCB0aGUgTUcgDQogIGFuZCBmaW5kIG91dCBpdHMgc3RhdGUu
IA0KICA8UD5SZWdhcmRzLCA8QlI+LS0gVGl0dHkgDQogIDxQPnJlemhpcnBhdmFpQGhzcy5obnMu
Y29tIHdyb3RlOiANCiAgPEJMT0NLUVVPVEUgVFlQRT0iQ0lURSI+SGVsbG8gTWFkaHUsIDxCUj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSWYgdGhlIE1HQyANCiAgICBhc3N1bWVzIHRoYXQgdGhl
IHRyYW5zYWN0aW9uIHJlc3BvbnNlIGNvbnRhaW5pbmcgYSBwYXJzZSBlcnJvciA8QlI+aXMgYSAN
CiAgICB0cmFuc2FjdGlvbiByZXBseSB3aXRoIGVycm9yLCB0aGVuIHRoaXMgd291bGQgbGVhZCB0
byBkaXNjcmVwYW5jeSBiZXR3ZWVuIA0KICAgIDxCUj50aGUgc3RhdGVzIG9mIE1HIGFuZCBNR0Mu
IFRoZSBNR0Mgd291bGQgYXNzdW1lIHRoYXQgdGhlIE1HIGhhcyBub3QgDQogICAgcHJvY2Vzc2Vk
IHRoZSA8QlI+cmVxdWVzdCB3aGVyZWFzIHRoZSBNRyB3b3VsZCBoYXZlIHByb2Nlc3NlZCB0aGUg
cmVxdWVzdCANCiAgICBhbmQgd291bGQgaGF2ZSBwb3NzaWJseSA8QlI+Y2hhbmdlZCB0aGUgdGVy
bWluYXRpb24gc3RhdGUuIA0KICAgIDxQPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICBSZWdhcmRzLCANCiAg
ICA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgIFIuIEV6aGlycGF2YWkgDQogICAgPFA+Ik1hZGh1IEJh
YnUgQnJhaG1hbmFwYWxseSIgJmx0O21hZGh1YmFidUBrZW5ldGVjLmNvbSZndDsgb24gMDUvMDIv
MjAwMSANCiAgICAwNzowOTo0NyBQTSANCiAgICA8UD5UbzombmJzcDsmbmJzcDsgdGl0dHlAY2Rv
dGIuZXJuZXQuaW4sICInbWVnYWNvIG1haWwgbGlzdCciIA0KICAgICZsdDttZWdhY29AZm9yZS5j
b20mZ3Q7IDxCUj5jYzombmJzcDsmbmJzcDsmbmJzcDsgKGJjYzogUiBFemhpcnBhdmFpL0hTUykg
DQogICAgPFA+U3ViamVjdDombmJzcDsgUkU6IEVycm9yIGluIHRyYW5zYWN0aW9uIHJlcGx5LiAN
CiAgICA8UD5IaSBUaXR0eSwgDQogICAgPFA+SW4gbm9ybWFsIGNpcmN1bXN0YW5jZXMsIGV2ZW4g
aWYgdGhlIE1HQyByZXRyYW5zbWl0IGl0cyANCiAgICB0cmFuc2FjdGlvbi1yZXF1ZXN0IDxCUj50
aGUgc2FtZSB0cmFuc2FjdGlvbiByZXNwb25zZSBpcyByZWNlaXZlZCBmcm9tIE1HLiANCiAgICBJ
TU8gdGhlIE1HQyBjYW4gdHJlYXQgdGhlIDxCUj5lcnJvciB0cmFuc2FjdGlvbiByZXNwb25zZSBh
cyBlcnJvciByZXNwb25zZSANCiAgICBmcm9tIE1HLiA8QlI+UmVnYXJkcyA8QlI+TWFkaHViYWJ1
IA0KICAgIDxQPiZuYnNwOy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIDxCUj5Gcm9tOiANCiAg
ICBvd25lci1tZWdhY29AcGl0LmNvbW1zLm1hcmNvbmkuY29tIDxCUj5bPEEgDQogICAgaHJlZj0i
bWFpbHRvOm93bmVyLW1lZ2Fjb0BwaXQuY29tbXMubWFyY29uaS5jb20iPm1haWx0bzpvd25lci1t
ZWdhY29AcGl0LmNvbW1zLm1hcmNvbmkuY29tPC9BPl1PbiANCiAgICBCZWhhbGYgT2YgVGl0dHkg
VGhvbWFzIDxCUj5TZW50OiBXZWRuZXNkYXksIE1heSAwMiwgMjAwMSAxMjowNCBBTSA8QlI+VG86
IA0KICAgIG1lZ2FjbyBtYWlsIGxpc3QgPEJSPlN1YmplY3Q6IEVycm9yIGluIHRyYW5zYWN0aW9u
IHJlcGx5LiANCiAgICA8UD4mbmJzcDsgSGkgYWxsLCANCiAgICA8UD4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgSWYgdGhlcmUgaXMgYW4gZXJyb3IgaW4gdHJhbnNhY3Rpb24gcmVwbHks
IA0KICAgIHdoYXQgd2lsbCB0aGUgcmVjZWl2ZXIgb2YgPEJSPnRoZSByZXBseSBkby4gSG93IDxC
Uj4mbmJzcDsgY2FuIGhlIHJlcG9ydCANCiAgICBiYWNrIHRvIHRoZSBzZW5kZXIgdGhhdCB0aGUg
cmVwbHkgd2FzIGFuIGVycm9yLiBBbmQgd2hhdCA8QlI+d2lsbCBoYXBwZW4gaWYgDQogICAgPFA+
Jm5ic3A7IHRoZSByZXBseSBoYWQgc29tZSB2YWx1ZXMgY2hvc2VuIGJ5IHRoZSBzZW5kZXIgKGVn
LiByZXBseSBmb3IgYSANCiAgICBjb21tYW5kIDxCUj53aXRoICQgKSBhbmQgdGhlIA0KICAgIDxQ
PiZuYnNwOyB2YWx1ZSBpcyBpbiBlcnJvci4gDQogICAgPFA+Jm5ic3A7IFJlZ2FyZHMsIA0KICAg
IDxQPiZuYnNwOyAtIFRpdHR5IA0KICAgIDxQPi0tIA0KICAgIDxCUj4rLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCiAg
ICA8QlI+fFR3byByb2FkcyBkaXZlcmdlZCBpbiBhIHdvb2QsIGFuZCBJIHRvb2sgdGhlIG9uZSBs
ZXNzIHRyYXZlbGVkIGJ5LHwgDQogICAgPEJSPnxBbmQgdGhhdCBoYXMgbWFkZSBhbGwgdGhlIA0K
ICAgIGRpZmZlcmVuY2UuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IA0KICAgIHwgPEJSPistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgIDxQPiZuYnNwOyANCiAg
ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0gDQogICAgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyANCiAgICBOYW1lOiBhdHQxLmh0bSA8QlI+Jm5ic3A7Jm5ic3A7IGF0
dDEuaHRtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgIFR5cGU6IEh5
cGVydGV4dCBNYXJrdXAgTGFuZ3VhZ2UgKHRleHQvaHRtbCkgDQogICAgPEJSPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyANCiAgICBFbmNvZGluZzogYmFzZTY0IA0KICAgIDxCUj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAgRGVz
Y3JpcHRpb246IEludGVybmV0IEhUTUw8L1A+PC9CTE9DS1FVT1RFPjxQUkU+LS0mbmJzcDsNCist
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0rDQp8VHdvIHJvYWRzIGRpdmVyZ2VkIGluIGEgd29vZCwgYW5kIEkgdG9vayB0aGUg
b25lIGxlc3MgdHJhdmVsZWQgYnksfCZuYnNwOw0KfEFuZCB0aGF0IGhhcyBtYWRlIGFsbCB0aGUg
ZGlmZmVyZW5jZS4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgfA0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSs8L1BSRT4mbmJzcDsgDQo8L0JMT0NLUVVPVEU+PC9CT0RZ
PjwvSFRNTD4NCg0K

--0__=nlk7A1TsKMpGBdXBgTvoV7LIGkwwIsFe3ICm44s4EFjEgVTmn2L44J5v--



From owner-megaco@fore.com  Thu May  3 14:39:04 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02924
	for ; Thu, 3 May 2001 14:39:04 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA09111;
	Thu, 3 May 2001 14:38:13 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA02545
	for megaco-list; Thu, 3 May 2001 14:36:22 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA01877
	for ; Thu, 3 May 2001 14:36:20 -0400 (EDT)
Received: from mail.mediatrix.com (mail.mediatrix.com [205.237.248.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA08664
	for ; Thu, 3 May 2001 14:34:50 -0400 (EDT)
Received: from temp (66-4-254-64.enter-net.com [64.254.4.66]) by mail.mediatrix.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id JP7MX1RX; Thu, 3 May 2001 14:30:55 -0400
From: "Olivier Larouche" 
To: "megagco" 
Subject: Using default or last value for a property
Date: Thu, 3 May 2001 14:35:22 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0029_01C0D3DE.4908AE40"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-MS-TNEF-Correlator: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0029_01C0D3DE.4908AE40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

In a termination state descriptor, if the (optionnal) service state property
is absent, is it assumed to use the default value, or the previous value? 
Is there a general rule for properties in order to determine the use of a
default or previous value?

Thanks,

Olivier Larouche


------=_NextPart_000_0029_01C0D3DE.4908AE40
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Disposition: attachment;
	filename="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IhYSAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHBQADAA4AIwAAAAQAFQEB
A5AGAGQFAAAiAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB
AAAAKwAAAFVzaW5nIGRlZmF1bHQgb3IgbGFzdCB2YWx1ZSBmb3IgYSBwcm9wZXJ0eQAAAgFxAAEA
AAAWAAAAAcDT/8zoHvi+cT/HEdWq1gDgKXQR/QAAAgEdDAEAAAAdAAAAU01UUDpPTEFST1VDSEVA
TUVESUFUUklYLkNPTQAAAAALAAEOAAAAAEAABg4AIoXC/9PAAQIBCg4BAAAAGAAAAAAAAAA8HoeW
ndLUEaqlAOApdBH9woAAAAsAHw4BAAAAAgEJEAEAAABaAQAAVgEAAMsBAABMWkZ1/6k/IQMACgBy
Y3BnMTI1BjIA+Atgbmc0MTCeNQH3AqQD4wIAY2gKwGBzZXQwIAcTAoB9JQqBdgiQd2sLgGQ0nQxg
YwBQCwMLtSBJA6AoYSB0BJBtC4BhdLJpAiAgcwGQFCAgAQCzBPQFsCwgBpAUEGgVIJwobwUwFKEU
cGwpFNBbBJASIGMVIBTkcANgcPkEkHR5FfAEIAGgESACMKsV4QQgaQVAYQQQdQeA4mQUEG8gdREg
FiMBAehhdWwFQHYHQApQFeD3BbEWMhgQZRIgCGAEIBtj9j8K4wqASQQgFjEJcBPxzmcJ8ASQB0Ag
chsgFSD/AhAFwBgVCJAZYQOgBbAEgd8aIgEAFCQahBpibxYQFABfGuYfMxxrHUQdRFQQ8G54a3Ms
I+oK9A8CD1AzYDMgT2xpEiEFwEz3CsAIYBDgZSV+D0IdRBHhAgApoAAACwABgAggBgAAAAAAwAAA
AAAAAEYAAAAAA4UAAAAAAAADAASACCAGAAAAAADAAAAAAAAARgAAAABShQAA+W8BAB4ABoAIIAYA
AAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADkuMAALAAqACCAGAAAAAADAAAAAAAAARgAAAACC
hQAAAQAAAAsAN4AIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwA5gAggBgAAAAAAwAAAAAAA
AEYAAAAAEIUAAAAAAAADADqACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAO4AIIAYAAAAA
AMAAAAAAAABGAAAAABiFAAAAAAAAAwBbgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAG6A
CCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAIB+A8BAAAAEAAAADweh5ad0tQRqqUA4Cl0Ef0C
AfoPAQAAABAAAAA8HoeWndLUEaqlAOApdBH9AgH7DwEAAACTAAAAAAAAADihuxAF5RAaobsIACsq
VsIAAFBTVFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcV0lOTlRcUHJvZmlsZXNc
b2xhcm91Y2hlXExvY2FsIFNldHRpbmdzXEFwcGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91dGxv
b2tcb3V0bG9vay5wc3QAAAMA/g8FAAAAAwANNP03AAACAX8AAQAAADcAAAA8TkVCQktLS0ZETVBP
S09PQ0lNQ1BJRUhOQ0JBQS5vbGFyb3VjaGVAbWVkaWF0cml4LmNvbT4AAAMABhAcQBdiAwAHEOYA
AAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAASU5BVEVSTUlOQVRJT05TVEFURURFU0NSSVBU
T1IsSUZUSEUoT1BUSU9OTkFMKVNFUlZJQ0VTVEFURVBST1BFUlRZSVNBQlNFTlQsSVNJVEFTU1VN
RURUT1VTRVRIRURFRkFVTAAAAACmLA==

------=_NextPart_000_0029_01C0D3DE.4908AE40--



From owner-megaco@fore.com  Thu May  3 14:55:32 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03372
	for ; Thu, 3 May 2001 14:55:31 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA11062;
	Thu, 3 May 2001 14:54:43 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA08703
	for megaco-list; Thu, 3 May 2001 14:53:41 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA08659
	for ; Thu, 3 May 2001 14:53:35 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA10887
	for ; Thu, 3 May 2001 14:53:31 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f43IrWT17026
	for ; Thu, 3 May 2001 14:53:32 -0400 (EDT)
Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2])
	by hoemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f43IrW117018;
	Thu, 3 May 2001 14:53:32 -0400 (EDT)
Received: from lucent.com (pctla [135.3.130.39])
	by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id OAA10000;
	Thu, 3 May 2001 14:53:30 -0400 (EDT)
Message-ID: <3AF1A958.97617C54@lucent.com>
Date: Thu, 03 May 2001 14:54:17 -0400
From: Terry L Anderson 
Organization: Lucent Technologies
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Troy Cauble 
CC: "Rosen, Brian" ,
        "'Tom-PT Taylor'" ,
        "'Bemmel, Jeroen van (Jeroen)'" ,
        "'megaco@fore.com'" 
Subject: Re: Relationship Annex C values <=> package Property ID's
References: <4FBEA8857476D311A03300204840E1CF01A6F555@whq-msgusr-02.pit.comms.marconi.com> <3AF17608.48ACC612@lucent.com>
Content-Type: multipart/mixed;
 boundary="------------2BB1B6A7CD6B267410B1F306"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.
--------------2BB1B6A7CD6B267410B1F306
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Troy Cauble wrote:

>
> Section C.11 is a line by line SDP replacement.  Some of the other
> Annex C
> items seem to be alternative encodings of information that could be
> encoded
> as SDP.
>
> IMHO, if any Annex C items don't have corresponding SDP elements, they
>
> should be removed.  It is fundamentally wrong to have features that
> are only
> accessible to the ASN.1 encoding of the protocol.  We should be
> striving
> for uniformity.

They should agree, but this can be fixed as you suggest (remove Annex C
item) or by ADDing SDP.  Many can be added through 'a=' attributes in
SDP and RFCs can add these as was suggested in
draft-ietf-mmusics-sdp-atm-05 or recent draft-taylor-mmusic-sdptdm-00
do.  Many of these in Annex C and not yet in SDP are vital for
configuring specific termination types.  These could be added through
packages to LocalControl but this makes it more difficult for them to be
media specific.  SDP allows the parameter to apply to only specific
choices of the multiple proposed media.

Removing them would seriously affect backward compatibility and so
probably not possible.

>
>
> People who need the non-SDP supported features currently in Annex C
> should be developing Packages, rather than going with an ASN.1 only
> solution.
>
> Can we seek out  and remove non-SDP supported features in Annex C?
>
> -troy
>
>
> "Rosen, Brian" wrote:
>
>> Wow, shows just how out of sync we all are -- Tom and I usually have
>> thesame view of these kinds of things.I thought Annex C is ONLY used
>> in remote and local when binary encoding.It replaces SDP.  When you
>> text encode, you use SDP in remote and local,when you binary encode
>> you use Annex C in Remote and LocalIt's not a "package" because you
>> don't use any of the Annex C tags in LocalControlor
>> TerminationState, and you don't ever use any other package defined
>> elementsin local and remote.  There was a certain amount of effort
>> put into making surewhatever you could say in SDP, there was an
>> equivalent in Annex C.Brian
>>
>>      -----Original Message-----
>>      From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>>      Sent: Thursday, May 03, 2001 10:16 AM
>>      To: 'Bemmel, Jeroen van (Jeroen)'; 'megaco@fore.com'
>>      Subject: RE: Relationship Annex C values <=> package
>>      Property ID's
>>      I have never fully understood the use of Annex C, so I
>>      can't give the authoritative word on how it works.
>>      Perhaps we need a discussion to clarify the matter.
>>
>>      Here is my view of the nature of Annex C:
>>
>>      1) Annex C consists of properties which belong in various
>>      descriptors.  An open action item is to specify the
>>      appropriate descriptor for each property.
>>
>>      2) Annex C is technically "package 0", which is available
>>      only for binary encoding.  It represents relatively early
>>      thinking in the development of the protocol.  To the
>>      extent to which it can be superseded by other packages, it
>>      should be, both because the other packages group
>>      properties, signals, etc. which should be implemented
>>      together and because the other packages provide both text
>>      and binary encoding in the same place.
>>
>>      3) A considerable part of Annex C is devoted to
>>      bearer-related properties, which belong in the Local and
>>      Remote descriptors.  (This statement is subject to debate,
>>      but it can be justified on the grounds that it provides a
>>      better fit with SIP than putting the properties into
>>      LocalControl.)  To provide text-encoded equivalents, these
>>      properties have to be added to SDP.  Hence the importance
>>      in my mind of the ATM and TDM SDP extensions.
>>
>>      4) One of the thrusts behind Annex C was the concept of
>>      "native encoding".  This means that the values following
>>      the tags are allowed to be lifted from a variety of other
>>      protocols.  I was startled the other day to learn that you
>>      could ship PER-encoded H.245 inside Megaco/H.248, but I
>>      can't contradict that notion: Annex C simply doesn't
>>      provide enough detail to accept or reject it.  I will
>>      point out that there is a certain amount of modification
>>      of Q.931-related values in Annex C, as an example, because
>>      the individual values are unpacked from the octets within
>>      which Q.931 encodes them and shifted to align with the
>>      octet boundary.  I see this as inconsistent with simply
>>      taking globs of H.245 "as is" and shipping them to the
>>      other end, but anything is possible with prior agreement.
>>
>>      5) I was never clear on what should follow the SDP-related
>>      tags.  To be consistent with the H.245 approach, I suppose
>>      what would follow would be the actual SDP text strings,
>>      but I don't know.
>>
>>      In conclusion: I think we need a clearer view of how Annex
>>      C is to be used in general, we need to replace at least
>>      some of the Annex with properties defined in other
>>      packages, and we need to specify which descriptors the
>>      remaining properties should go in.
>>
>>      > -----Original Message-----
>>      > From: Bemmel, Jeroen van (Jeroen)
>>      [mailto:jbemmel@lucent.com]
>>      > Sent: Thursday, May 03, 2001 6:01 AM
>>      > To: 'megaco@fore.com'
>>      > Subject: Relationship Annex C values <=> package
>>      Property ID's
>>      >
>>      >
>>      > Hello all,
>>      >
>>      > The relationship between value tags in Annex C and
>>      attribute
>>      > identifiers in
>>      > packages is unclear and confusing to me:
>>      >
>>      > For instance, Annex C defines PropertyID Jitterbuff =
>>      100D,
>>      > an unsigned
>>      > integer 0-65535 representing time in ms
>>      > Networkpackage defines Property ID jit = 0x0007 as an
>>      attribute to the
>>      > LocalControlDescriptor
>>      >
>>      > 1) Am I correct in assuming that the Annex C value is
>>      meant
>>      > to be assigned
>>      > to LocalControlDescriptor.JitterBuffer ?
>>      >
>>      > 2) If so, how come some of the other Annex C Property
>>      IDs are
>>      > not defined as
>>      > attributes anywhere?
>>      >
>>      > 3) And, if these attributes are not defined, then where
>>      is
>>      > the MG supposed
>>      > to keep state information to report when receiving an
>>      audit request
>>      >     for all terminations (eg step 19 in Appendix A -
>>      Example
>>      > call flows,
>>      > resulting in a report of the RTP IP address (amongst
>>      others)) ?
>>      >
>>      >
>>      > Jeroen van Bemmel
>>      > Developer New Technologies
>>      >
>>      >
>>
--
------------------------------------------------------------
Terry L Anderson              mailto:tla@lucent.com
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla


--------------2BB1B6A7CD6B267410B1F306
Content-Type: text/x-vcard; charset=us-ascii;
 name="tla.vcf"
Content-Description: Card for Terry L Anderson
Content-Disposition: attachment;
 filename="tla.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Anderson;Terry L
tel;fax:908.582.6729
tel;work:908.582.7013
x-mozilla-html:TRUE
url:http://its.lucent.com/~tla
org:Lucent / InterNetworking Systems;VoIP Access Networks
version:2.1
email;internet:tla@lucent.com
title:DMTS
note:http://www.gti.net/tla  or http://teton.mh.lucent.com/~tla (Lucent internal)
adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA
x-mozilla-cpt:;21296
fn:Terry L Anderson
end:vcard

--------------2BB1B6A7CD6B267410B1F306--



From owner-megaco@fore.com  Thu May  3 15:13:25 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04501
	for ; Thu, 3 May 2001 15:13:25 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA12806;
	Thu, 3 May 2001 15:12:35 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA13948
	for megaco-list; Thu, 3 May 2001 15:11:36 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA13885
	for ; Thu, 3 May 2001 15:11:30 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA12603
	for ; Thu, 3 May 2001 15:11:22 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.123])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACD16027;
	Thu, 3 May 2001 15:04:13 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Troy Cauble'" ,
        "'Rosen, Brian'" 
Cc: "'Tom-PT Taylor'" ,
        "'Bemmel, Jeroen van \(Jeroen\)'" ,
        
Subject: RE: Relationship Annex C values <=> package Property ID's
Date: Thu, 3 May 2001 15:09:30 -0400
Message-ID: <009f01c0d404$958430c0$c500a8c0@MBRAHMANAPALLY>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00A0_01C0D3E3.0E7290C0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <3AF17608.48ACC612@lucent.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00A0_01C0D3E3.0E7290C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit



Its true that the Annex C lists many properties that are not there in SDP.
Apart from that there are properties like JitterBuffer (As pointed by
Bemmel), Echo Cancellation, Gain Control which are present both as
properties of package and in Annex C. If say, JitterBuffer property appears
both in Local Control Descriptor (PACKAGE DEFINED) and in local descriptor
(ANNEX C), then the one specified in the Local descriptor should be
discarded. The same was the case with mode parameter which can appear both
in the local control descriptor and SDP. A statement can be added in the IG
to mention that if the properties appears twice (I'm not sure whether Error
code "456 - Parameter or Property appears twice in this Descriptor" is valid
here) , then the local control descriptor defined once takes the precedence.

Regards
Madhubabu
  -----Original Message-----
  From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Troy Cauble
  Sent: Thursday, May 03, 2001 11:15 AM
  To: Rosen, Brian
  Cc: 'Tom-PT Taylor'; 'Bemmel, Jeroen van (Jeroen)'; 'megaco@fore.com'
  Subject: Re: Relationship Annex C values <=> package Property ID's



  Section C.11 is a line by line SDP replacement.  Some of the other Annex C
  items seem to be alternative encodings of information that could be
encoded
  as SDP.
  IMHO, if any Annex C items don't have corresponding SDP elements, they
  should be removed.  It is fundamentally wrong to have features that are
only
  accessible to the ASN.1 encoding of the protocol.  We should be striving
  for uniformity.

  People who need the non-SDP supported features currently in Annex C
  should be developing Packages, rather than going with an ASN.1 only
  solution.

  Can we seek out  and remove non-SDP supported features in Annex C?

  -troy


  "Rosen, Brian" wrote:

     Wow, shows just how out of sync we all are -- Tom and I usually have
thesame view of these kinds of things.I thought Annex C is ONLY used in
remote and local when binary encoding.It replaces SDP.  When you text
encode, you use SDP in remote and local,when you binary encode you use Annex
C in Remote and LocalIt's not a "package" because you don't use any of the
Annex C tags in LocalControlor TerminationState, and you don't ever use any
other package defined elementsin local and remote.  There was a certain
amount of effort put into making surewhatever you could say in SDP, there
was an equivalent in Annex C.Brian
      -----Original Message-----
      From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
      Sent: Thursday, May 03, 2001 10:16 AM
      To: 'Bemmel, Jeroen van (Jeroen)'; 'megaco@fore.com'
      Subject: RE: Relationship Annex C values <=> package Property ID's

      I have never fully understood the use of Annex C, so I can't give the
authoritative word on how it works.  Perhaps we need a discussion to clarify
the matter.
      Here is my view of the nature of Annex C:

      1) Annex C consists of properties which belong in various descriptors.
An open action item is to specify the appropriate descriptor for each
property.

      2) Annex C is technically "package 0", which is available only for
binary encoding.  It represents relatively early thinking in the development
of the protocol.  To the extent to which it can be superseded by other
packages, it should be, both because the other packages group properties,
signals, etc. which should be implemented together and because the other
packages provide both text and binary encoding in the same place.

      3) A considerable part of Annex C is devoted to bearer-related
properties, which belong in the Local and Remote descriptors.  (This
statement is subject to debate, but it can be justified on the grounds that
it provides a better fit with SIP than putting the properties into
LocalControl.)  To provide text-encoded equivalents, these properties have
to be added to SDP.  Hence the importance in my mind of the ATM and TDM SDP
extensions.

      4) One of the thrusts behind Annex C was the concept of "native
encoding".  This means that the values following the tags are allowed to be
lifted from a variety of other protocols.  I was startled the other day to
learn that you could ship PER-encoded H.245 inside Megaco/H.248, but I can't
contradict that notion: Annex C simply doesn't provide enough detail to
accept or reject it.  I will point out that there is a certain amount of
modification of Q.931-related values in Annex C, as an example, because the
individual values are unpacked from the octets within which Q.931 encodes
them and shifted to align with the octet boundary.  I see this as
inconsistent with simply taking globs of H.245 "as is" and shipping them to
the other end, but anything is possible with prior agreement.

      5) I was never clear on what should follow the SDP-related tags.  To
be consistent with the H.245 approach, I suppose what would follow would be
the actual SDP text strings, but I don't know.

      In conclusion: I think we need a clearer view of how Annex C is to be
used in general, we need to replace at least some of the Annex with
properties defined in other packages, and we need to specify which
descriptors the remaining properties should go in.

      > -----Original Message-----
      > From: Bemmel, Jeroen van (Jeroen) [mailto:jbemmel@lucent.com]
      > Sent: Thursday, May 03, 2001 6:01 AM
      > To: 'megaco@fore.com'
      > Subject: Relationship Annex C values <=> package Property ID's
      >
      >
      > Hello all,
      >
      > The relationship between value tags in Annex C and attribute
      > identifiers in
      > packages is unclear and confusing to me:
      >
      > For instance, Annex C defines PropertyID Jitterbuff = 100D,
      > an unsigned
      > integer 0-65535 representing time in ms
      > Networkpackage defines Property ID jit = 0x0007 as an attribute to
the
      > LocalControlDescriptor
      >
      > 1) Am I correct in assuming that the Annex C value is meant
      > to be assigned
      > to LocalControlDescriptor.JitterBuffer ?
      >
      > 2) If so, how come some of the other Annex C Property IDs are
      > not defined as
      > attributes anywhere?
      >
      > 3) And, if these attributes are not defined, then where is
      > the MG supposed
      > to keep state information to report when receiving an audit request
      >     for all terminations (eg step 19 in Appendix A - Example
      > call flows,
      > resulting in a report of the RTP IP address (amongst others)) ?
      >
      >
      > Jeroen van Bemmel
      > Developer New Technologies
      >
      >


------=_NextPart_000_00A0_01C0D3E3.0E7290C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









 


 


Its=20
true that the Annex C lists many properties that are not there in SDP. =
Apart=20
from that there are properties like JitterBuffer (As pointed by Bemmel), =
Echo=20
Cancellation, Gain Control which are present both as properties of =
package and=20
in Annex C. If say, JitterBuffer property appears both in Local Control=20
Descriptor (PACKAGE DEFINED) and in local descriptor (ANNEX C), then the =
one=20
specified in the Local descriptor should be discarded. The same was the =
case=20
with mode parameter which can appear both in the local control =
descriptor and=20
SDP. A statement can be added in the IG to mention that if the =
properties=20
appears twice (I'm not sure whether Error code "456 - Parameter or =
Property=20
appears twice in this Descriptor" is valid here) , then the local =
control=20
descriptor defined once takes the precedence.


 


Regards


Madhubabu



  
-----Original Message-----
From:=20
  owner-megaco@pit.comms.marconi.com=20
  [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Troy=20
  Cauble
Sent: Thursday, May 03, 2001 11:15 AM
To: =
Rosen,=20
  Brian
Cc: 'Tom-PT Taylor'; 'Bemmel, Jeroen van (Jeroen)';=20
  'megaco@fore.com'
Subject: Re: Relationship Annex C values =
<=3D>=20
  package Property ID's

  
Section C.11 is a =
line by=20
  line SDP replacement.  Some of the other Annex C 
items seem =
to be=20
  alternative encodings of information that could be encoded 
as =
SDP.=20
  
IMHO, if any Annex C items don't have corresponding SDP elements, =
they=20
  
should be removed.  It is fundamentally wrong to have =
features that=20
  are only 
accessible to the ASN.1 encoding of the protocol.  =
We should=20
  be striving 
for uniformity.=20
  
People who need the non-SDP supported features currently in Annex C =

  
should be developing Packages, rather than going with an ASN.1 =
only=20
  
solution.=20
  
Can we seek out  and remove non-SDP supported features in =
Annex C?=20
  
-troy 
 =20
  
"Rosen, Brian" wrote:=20
  
 Wow, shows just how out of sync =
we all are --=20
    Tom and I usually have thesame view of=20
    these kinds of things.I thought Annex C is ONLY used in =
remote and=20
    local when binary encoding.It replaces=20
    SDP.  When you text encode, you use SDP in remote and=20
    local,when you binary encode you use =
Annex C in=20
    Remote and LocalIt's not a "package" because you =
don't use=20
    any of the Annex C tags in LocalControlor=20
    TerminationState, and you don't ever use any other package defined=20
    elementsin local and remote.  There =
was a=20
    certain amount of effort put into making =
surewhatever you=20
    could say in SDP, there was an equivalent in Annex=20
    C.Brian=20
    
      
-----Original Message----- 
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.co=
m]=20
      
Sent: Thursday, May =
03, 2001=20
      10:16 AM 
To:=20
      'Bemmel, Jeroen van (Jeroen)'; 'megaco@fore.com' =

Subject: RE: Relationship =
Annex C values=20
      <=3D> package Property ID's =

 
I have never fully understood the use of Annex C, so I =
can't give=20
      the authoritative word on how it works.  Perhaps we need a =
discussion=20
      to clarify the matter.=20
      
Here is my view of the nature of Annex =
C:=20
      
1) Annex C consists of properties which belong =
in various=20
      descriptors.  An open action item is to specify the =
appropriate=20
      descriptor for each property.=20
      
2) Annex C is technically "package 0", which is =
available=20
      only for binary encoding.  It represents relatively early =
thinking in=20
      the development of the protocol.  To the extent to which it =
can be=20
      superseded by other packages, it should be, both because the other =

      packages group properties, signals, etc. which should be =
implemented=20
      together and because the other packages provide both text and =
binary=20
      encoding in the same place.=20
      
3) A considerable part of Annex C is devoted to =

      bearer-related properties, which belong in the Local and Remote=20
      descriptors.  (This statement is subject to debate, but it =
can be=20
      justified on the grounds that it provides a better fit with SIP =
than=20
      putting the properties into LocalControl.)  To provide =
text-encoded=20
      equivalents, these properties have to be added to SDP.  Hence =
the=20
      importance in my mind of the ATM and TDM SDP extensions.=20
      
4) One of the thrusts behind Annex C was the =
concept of=20
      "native encoding".  This means that the values following the =
tags are=20
      allowed to be lifted from a variety of other protocols.  I =
was=20
      startled the other day to learn that you could ship PER-encoded =
H.245=20
      inside Megaco/H.248, but I can't contradict that notion: Annex C =
simply=20
      doesn't provide enough detail to accept or reject it.  I will =
point=20
      out that there is a certain amount of modification of =
Q.931-related values=20
      in Annex C, as an example, because the individual values are =
unpacked from=20
      the octets within which Q.931 encodes them and shifted to align =
with the=20
      octet boundary.  I see this as inconsistent with simply =
taking globs=20
      of H.245 "as is" and shipping them to the other end, but anything =
is=20
      possible with prior agreement.=20
      
5) I was never clear on what should follow the=20
      SDP-related tags.  To be consistent with the H.245 approach, =
I=20
      suppose what would follow would be the actual SDP text strings, =
but I=20
      don't know.=20
      
In conclusion: I think we need a clearer view =
of how=20
      Annex C is to be used in general, we need to replace at least some =
of the=20
      Annex with properties defined in other packages, and we need to =
specify=20
      which descriptors the remaining properties should go in.=20
      
> -----Original Message----- =

> From: Bemmel, Jeroen van (Jeroen) [mailto:jbemmel@lucent.com] =

      
> Sent: Thursday, May 03, 2001 6:01 =
AM=20
      
> To: 'megaco@fore.com' 
>=20
      Subject: Relationship Annex C values <=3D> package Property=20
      ID's 
> 
>=20
      
> Hello all, 
>=20
      
> The relationship between value tags in =
Annex C and=20
      attribute 
> identifiers in =

> packages is unclear and confusing to me: =

> 
> For instance, Annex =
C defines=20
      PropertyID Jitterbuff =3D 100D, 
> an =

      unsigned 
> integer 0-65535 =
representing time=20
      in ms 
> Networkpackage defines =
Property ID jit=20
      =3D 0x0007 as an attribute to the 
>=20
      LocalControlDescriptor 
> =

> 1) Am I correct in assuming that the Annex C value =
is=20
      meant 
> to be assigned =

> to LocalControlDescriptor.JitterBuffer ? =

> 
> 2) If so, how come =
some of the=20
      other Annex C Property IDs are 
> not =
defined=20
      as 
> attributes anywhere? =

> 
> 3) And, if these =
attributes are=20
      not defined, then where is 
> the MG=20
      supposed 
> to keep state information =
to report=20
      when receiving an audit request 
>     for all terminations (eg =
step 19 in=20
      Appendix A - Example 
> call =
flows,=20
      
> resulting in a report of the RTP IP =
address=20
      (amongst others)) ? 
> =

> 
> Jeroen van =
Bemmel=20
      
> Developer New Technologies =

> 
>


------=_NextPart_000_00A0_01C0D3E3.0E7290C0--



From owner-megaco@fore.com  Thu May  3 15:34:29 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05019
	for ; Thu, 3 May 2001 15:34:29 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA15047;
	Thu, 3 May 2001 15:33:39 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA21645
	for megaco-list; Thu, 3 May 2001 15:32:46 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA21601
	for ; Thu, 3 May 2001 15:32:43 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id PAA14870
	for ; Thu, 3 May 2001 15:32:36 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id PAA07538; Thu, 3 May 2001 15:32:34 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Thu, 3 May 2001 15:32:21 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 3 May 2001 15:32:24 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CAA5@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Troy Cauble'" , MEGACO list 
Subject: RE: multiple digitmaps
Date: Thu, 3 May 2001 15:32:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D407.C266A3E0"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D407.C266A3E0
Content-Type: text/plain;
	charset="iso-8859-1"

You're right.  I think we intended this.  Does anyone object?   

> -----Original Message-----
> From: Troy Cauble [mailto:troy@lucent.com]
> Sent: Thursday, May 03, 2001 11:51 AM
> To: MEGACO list
> Subject: multiple digitmaps
> 
> 
> 
> MEGACO/1 [12.12.12.12]:12345
> Transaction = 1030 {Context = - {Modify = ROOT {
>   DigitMap = Pin {(xxxx|xxxxxx)},
>   DigitMap = UserId {(xxxxxx)},
>   DigitMap = Dialplan0 {(0|00|911|1xxxxxxxxxx|Exx|[2-9]xxxxxx|9011x.)}
> }}}
> 
> 
> Multiple digitmaps in Add/Move/Modify parameters are 
> currently illegal based on comments in Annex A and B.  
> This seems pretty useful.
> 
> 
> Proposal:
> 
> In Annex B, rewrite the comment above the "ammParameter" spec as:
> 	; at-most-once except for digitMapDescriptor.
> 
> In Annex A, rewrite the comment in the "AmmRequest" spec as:
> 	-- At most one descriptor of each type (see AmmDescriptor)
> 	-- allowed in the sequence, except for DigitMapDescriptor.
> 
> 
> -troy
> 

------_=_NextPart_001_01C0D407.C266A3E0
Content-Type: text/html;
	charset="iso-8859-1"






RE: multiple digitmaps 




You're right.  I think we intended this.  Does anyone object?   




> -----Original Message-----

> From: Troy Cauble [mailto:troy@lucent.com]

> Sent: Thursday, May 03, 2001 11:51 AM

> To: MEGACO list

> Subject: multiple digitmaps

> 

> 

> 

> MEGACO/1 [12.12.12.12]:12345

> Transaction = 1030 {Context = - {Modify = ROOT {

>   DigitMap = Pin {(xxxx|xxxxxx)},

>   DigitMap = UserId {(xxxxxx)},

>   DigitMap = Dialplan0 {(0|00|911|1xxxxxxxxxx|Exx|[2-9]xxxxxx|9011x.)}

> }}}

> 

> 

> Multiple digitmaps in Add/Move/Modify parameters are 

> currently illegal based on comments in Annex A and B.  

> This seems pretty useful.

> 

> 

> Proposal:

> 

> In Annex B, rewrite the comment above the "ammParameter" spec as:

>       ; at-most-once except for digitMapDescriptor.

> 

> In Annex A, rewrite the comment in the "AmmRequest" spec as:

>       -- At most one descriptor of each type (see AmmDescriptor)

>       -- allowed in the sequence, except for DigitMapDescriptor.

> 

> 

> -troy

> 





------_=_NextPart_001_01C0D407.C266A3E0--


From owner-megaco@fore.com  Thu May  3 15:36:34 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05452
	for ; Thu, 3 May 2001 15:36:33 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA15402;
	Thu, 3 May 2001 15:35:43 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA22268
	for megaco-list; Thu, 3 May 2001 15:34:30 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA22241
	for ; Thu, 3 May 2001 15:34:28 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA15201
	for ; Thu, 3 May 2001 15:34:23 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1])
	by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f43JYPf05080
	for ; Thu, 3 May 2001 15:34:25 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f43JYOV05055
	for ; Thu, 3 May 2001 15:34:24 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA17376; Thu, 3 May 2001 15:34:22 -0400 (EDT)
Cc: "Rosen, Brian" ,
        "'Tom-PT Taylor'" ,
        "'Bemmel, Jeroen van (Jeroen)'" ,
        "'megaco@fore.com'" 
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA17327; Thu, 3 May 2001 15:34:18 -0400 (EDT)
Message-ID: <3AF1B248.B712C546@lucent.com>
Date: Thu, 03 May 2001 15:32:24 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Terry L Anderson 
Original-CC: "Rosen, Brian" ,
        "'Tom-PT Taylor'" ,
        "'Bemmel, Jeroen van (Jeroen)'" ,
        "'megaco@fore.com'" 
Subject: Re: Relationship Annex C values <=> package Property ID's
References: <4FBEA8857476D311A03300204840E1CF01A6F555@whq-msgusr-02.pit.comms.marconi.com> <3AF17608.48ACC612@lucent.com> <3AF1A958.97617C54@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Terry L Anderson wrote:
> 
> Troy Cauble wrote:
> 
> >
> > Section C.11 is a line by line SDP replacement.  Some of the other
> > Annex C
> > items seem to be alternative encodings of information that could be
> > encoded
> > as SDP.
> >
> > IMHO, if any Annex C items don't have corresponding SDP elements, they
> >
> > should be removed.  It is fundamentally wrong to have features that
> > are only
> > accessible to the ASN.1 encoding of the protocol.  We should be
> > striving
> > for uniformity.
> 
> They should agree, but this can be fixed as you suggest (remove Annex C
> item) or by ADDing SDP.  Many can be added through 'a=' attributes in
> SDP and RFCs can add these as was suggested in
> draft-ietf-mmusics-sdp-atm-05 or recent draft-taylor-mmusic-sdptdm-00
> do.  Many of these in Annex C and not yet in SDP are vital for
> configuring specific termination types.  These could be added through
> packages to LocalControl but this makes it more difficult for them to be
> media specific.  SDP allows the parameter to apply to only specific
> choices of the multiple proposed media.
> 
> Removing them would seriously affect backward compatibility and so
> probably not possible.


I had forgotten that the things in the Local and Remote Descriptors
are not Properties.  Packages won't work here.

So for LD & RD non-properties in Annex C that are not yet in SDP, 
people will have a choice between using ASN.1 encoding only or 
influencing the evolution of SDP.

Consider the reverse direction.  How will new items that come out 
of the evolution of SDP make it into Annex C for ASN.1 encoding?  
Do we need a formal mechanism (like Packages) to extend Annex C?

On the other hand, the IG ammended the intro to Annex C to 
say that (some of?) the Annex C non-properties apply to the
LocalControlDescriptor.  (But nothing tells us which ones.)

I would argue that any Annex C items that apply to the LCD
*ARE* Properties, and should be removed from Annex C and moved
to Packages.  Otherwise how will they be encoded as text?

-troy


> >
> >
> > People who need the non-SDP supported features currently in Annex C
> > should be developing Packages, rather than going with an ASN.1 only
> > solution.
> >
> > Can we seek out  and remove non-SDP supported features in Annex C?
> >
> > -troy
> >
> >


From owner-megaco@fore.com  Thu May  3 16:02:25 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06867
	for ; Thu, 3 May 2001 16:02:24 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA18030;
	Thu, 3 May 2001 16:01:25 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA00810
	for megaco-list; Thu, 3 May 2001 15:58:29 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA00797
	for ; Thu, 3 May 2001 15:58:26 -0400 (EDT)
Received: from slink12.ss7-link.com (mail.ss7-link.com [209.204.106.218])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA17680
	for ; Thu, 3 May 2001 15:58:23 -0400 (EDT)
Received: by SLINK12 with Internet Mail Service (5.5.2650.21)
	id ; Thu, 3 May 2001 15:58:25 -0400
Message-ID: 
From: Dave Sclarsky 
To: "'Tom-PT Taylor'" ,
        "'Troy Cauble'"
	 , MEGACO list 
Subject: RE: multiple digitmaps
Date: Thu, 3 May 2001 15:58:18 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0D40B.6980A390"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D40B.6980A390
Content-Type: text/plain;
	charset="iso-8859-1"

This will break [at least one :-( ] current implementations.  Are you
proposing to change this for v1, or could it wait till v2?
 
DaveS.

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Thursday, May 03, 2001 3:32 PM
To: 'Troy Cauble'; MEGACO list
Subject: RE: multiple digitmaps



You're right.  I think we intended this.  Does anyone object?   

> -----Original Message----- 
> From: Troy Cauble [ mailto:troy@lucent.com  ] 
> Sent: Thursday, May 03, 2001 11:51 AM 
> To: MEGACO list 
> Subject: multiple digitmaps 
> 
> 
> 
> MEGACO/1 [12.12.12.12]:12345 
> Transaction = 1030 {Context = - {Modify = ROOT { 
>   DigitMap = Pin {(xxxx|xxxxxx)}, 
>   DigitMap = UserId {(xxxxxx)}, 
>   DigitMap = Dialplan0 {(0|00|911|1xxxxxxxxxx|Exx|[2-9]xxxxxx|9011x.)} 
> }}} 
> 
> 
> Multiple digitmaps in Add/Move/Modify parameters are 
> currently illegal based on comments in Annex A and B.  
> This seems pretty useful. 
> 
> 
> Proposal: 
> 
> In Annex B, rewrite the comment above the "ammParameter" spec as: 
>       ; at-most-once except for digitMapDescriptor. 
> 
> In Annex A, rewrite the comment in the "AmmRequest" spec as: 
>       -- At most one descriptor of each type (see AmmDescriptor) 
>       -- allowed in the sequence, except for DigitMapDescriptor. 
> 
> 
> -troy 
> 


------_=_NextPart_001_01C0D40B.6980A390
Content-Type: text/html;
	charset="iso-8859-1"




RE: multiple digitmaps




This 
will break [at least one :-( ] current implementations.  Are you proposing 
to change this for v1, or could it wait till v2?


 


DaveS.



  
-----Original Message-----
From: Tom-PT Taylor 
  [mailto:taylor@nortelnetworks.com]
Sent: Thursday, May 03, 2001 3:32 
  PM
To: 'Troy Cauble'; MEGACO list
Subject: RE: multiple 
  digitmaps


  
You're right.  I think we intended this.  Does 
  anyone object?   

  
> -----Original Message----- 
> 
  From: Troy Cauble [mailto:troy@lucent.com] 
> Sent: Thursday, May 03, 2001 11:51 AM 
> 
  To: MEGACO list 
> Subject: multiple 
  digitmaps 
> 
> 
  
> 
> MEGACO/1 
  [12.12.12.12]:12345 
> Transaction = 1030 {Context = 
  - {Modify = ROOT { 
>   DigitMap = Pin 
  {(xxxx|xxxxxx)}, 
>   DigitMap = UserId 
  {(xxxxxx)}, 
>   DigitMap = Dialplan0 
  {(0|00|911|1xxxxxxxxxx|Exx|[2-9]xxxxxx|9011x.)} 
> 
  }}} 
> 
> 
> Multiple digitmaps in Add/Move/Modify parameters are 
  
> currently illegal based on comments in Annex A 
  and B.  
> This seems pretty useful. 
  
> 
> 
> Proposal: 
> 
> In Annex B, rewrite the comment above the "ammParameter" spec 
  as: 
>       ; at-most-once 
  except for digitMapDescriptor. 
> 
> In Annex A, rewrite the comment in the "AmmRequest" spec 
  as: 
>       -- At most one 
  descriptor of each type (see AmmDescriptor) 
> 
        -- allowed in the sequence, except for 
  DigitMapDescriptor. 
> 
> 
  
> -troy 
> 



------_=_NextPart_001_01C0D40B.6980A390--


From owner-megaco@fore.com  Thu May  3 16:06:06 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07287
	for ; Thu, 3 May 2001 16:06:05 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA18530;
	Thu, 3 May 2001 16:05:17 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA02730
	for megaco-list; Thu, 3 May 2001 16:04:33 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA02719
	for ; Thu, 3 May 2001 16:04:31 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA18413
	for ; Thu, 3 May 2001 16:04:27 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.123])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACD16482;
	Thu, 3 May 2001 15:57:25 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Tom-PT Taylor'" ,
        "'Troy Cauble'" ,
        "'MEGACO list'" 
Subject: RE: multiple digitmaps
Date: Thu, 3 May 2001 16:02:42 -0400
Message-ID: <00af01c0d40c$04066d40$c500a8c0@MBRAHMANAPALLY>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00B0_01C0D3EA.7CF4CD40"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <28560036253BD41191A10000F8BCBD110250CAA5@zcard00g.ca.nortel.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00B0_01C0D3EA.7CF4CD40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: multiple digitmapsNeed to add text for this feature in section 7.1.14,
else its not known unless one looks into the grammar.

Regards
Madhubabu
  -----Original Message-----
  From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Tom-PT Taylor
  Sent: Thursday, May 03, 2001 3:32 PM
  To: 'Troy Cauble'; MEGACO list
  Subject: RE: multiple digitmaps


  You're right.  I think we intended this.  Does anyone object?

  > -----Original Message-----
  > From: Troy Cauble [mailto:troy@lucent.com]
  > Sent: Thursday, May 03, 2001 11:51 AM
  > To: MEGACO list
  > Subject: multiple digitmaps
  >
  >
  >
  > MEGACO/1 [12.12.12.12]:12345
  > Transaction = 1030 {Context = - {Modify = ROOT

  >   DigitMap = Pin {(xxxx|xxxxxx)},
  >   DigitMap = UserId {(xxxxxx)},
  >   DigitMap = Dialplan0 {(0|00|911|1xxxxxxxxxx|Exx|[2-9]xxxxxx|9011x.)}
  > }}}
  >
  >
  > Multiple digitmaps in Add/Move/Modify parameters are
  > currently illegal based on comments in Annex A and B.
  > This seems pretty useful.
  >
  >
  > Proposal:
  >
  > In Annex B, rewrite the comment above the "ammParameter" spec as:
  >       ; at-most-once except for digitMapDescriptor.
  >
  > In Annex A, rewrite the comment in the "AmmRequest" spec as:
  >       -- At most one descriptor of each type (see AmmDescriptor)
  >       -- allowed in the sequence, except for DigitMapDescriptor.
  >
  >
  > -troy
  >


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




RE: multiple digitmaps




Need=20
to add text for this feature in section 7.1.14, else its not known =
unless one=20
looks into the grammar.


 


Regards


Madhubabu



  
-----Original Message-----
From:=20
  owner-megaco@pit.comms.marconi.com=20
  [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Tom-PT=20
  Taylor
Sent: Thursday, May 03, 2001 3:32 PM
To: =
'Troy=20
  Cauble'; MEGACO list
Subject: RE: multiple=20
  digitmaps


  
You're right.  I think we intended this.  =
Does=20
  anyone object?   

  
> -----Original Message----- 
>=20
  From: Troy Cauble [mailto:troy@lucent.com] =

> Sent: Thursday, May 03, 2001 11:51 AM 
>=20
  To: MEGACO list 
> Subject: multiple=20
  digitmaps 
> 
>=20
  
> 
> MEGACO/1 =

  [12.12.12.12]:12345 
> Transaction =3D =
1030 {Context =3D=20
  - {Modify =3D ROOT { 
>   =
DigitMap =3D Pin=20
  {(xxxx|xxxxxx)}, 
>   DigitMap =
=3D UserId=20
  {(xxxxxx)}, 
>   DigitMap =3D =
Dialplan0=20
  {(0|00|911|1xxxxxxxxxx|Exx|[2-9]xxxxxx|9011x.)} 
>=20
  }}} 
> 
> =

> Multiple digitmaps in Add/Move/Modify parameters are=20
  
> currently illegal based on comments in =
Annex A=20
  and B.  
> This seems pretty =
useful.=20
  
> 
> =

> Proposal: 
> =

> In Annex B, rewrite the comment above the "ammParameter" =
spec=20
  as: 
>       ; =
at-most-once=20
  except for digitMapDescriptor. 
> =

> In Annex A, rewrite the comment in the "AmmRequest" spec =

  as: 
>       -- =
At most one=20
  descriptor of each type (see AmmDescriptor) 
>=20
        -- allowed in the sequence, except for=20
  DigitMapDescriptor. 
> 
>=20
  
> -troy 
>=20



------=_NextPart_000_00B0_01C0D3EA.7CF4CD40--



From owner-megaco@fore.com  Fri May  4 00:17:04 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20683
	for ; Fri, 4 May 2001 00:17:03 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA14356;
	Fri, 4 May 2001 00:15:38 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA18713
	for megaco-list; Fri, 4 May 2001 00:12:14 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA18709
	for ; Fri, 4 May 2001 00:12:13 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA14188
	for ; Fri, 4 May 2001 00:12:09 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1])
	by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f444C5k08042
	for ; Fri, 4 May 2001 00:12:06 -0400 (EDT)
Received: from ihgp.ih.lucent.com (h135-1-53-23.lucent.com [135.1.53.23])
	by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f444AD907047
	for ; Fri, 4 May 2001 00:12:04 -0400 (EDT)
Received: by ihgp.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id XAA24892; Thu, 3 May 2001 23:10:12 -0500 (CDT)
To: megaco@fore.com
Received: from il0015varney2.lucent.com by ihgp.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id XAA24879; Thu, 3 May 2001 23:10:09 -0500 (CDT)
Message-Id: <4.3.2.7.2.20010503221620.00d01ae0@ihmail.ih.lucent.com>
X-Sender: varney@ihmail.ih.lucent.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 03 May 2001 23:10:05 -0500
Original-To: 
From: Al Varney 
Subject: RE: Providing Ringback from the Calling MG versus the Called MG
In-Reply-To: 
References: <4.3.2.7.2.20010502130647.00a81380@ihmail.ih.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

At 17:00 05/02/2001 -0400, Vance Shipley wrote:
>Al Varney writes:
>}
>}   [N.B.:  I realize some vendors of mobile equipment are working on
>} standards for doing calling-terminal Ring Tone (even country-specific
>} tones).  It can work for called-parties that are KNOWN to correctly
>} indicate when the called party is being alerted, such as another
>} 'modern' mobile network not interconnected by the PSTN.  But it will
>} be a long time before it will work for every called party.]
>
>
>Isn't this written into both ISUP and Q.931?

    Yes, but the indication is there as friendly advice for display 
purposes (in my opinion).
ISUP has several sections called "Completion of Transmission Path" -- are 
you going to ignore that part of ISUP and rely only on the ACM/CallProgress 
message content? :)  Look at Q.764, section 2.1.2.1 d), for example.

    Even with both ISUP and Q.931 together, the terminating switch is 
REQUIRED to transmit back Ring Tone (Q.699/T1.609) even to an originating 
Q.931 caller.  Switches are allowed to bridge in announcements/tones at any 
time prior to sending back Answer (look at some of the INAP 
interactions).  They are allowed to change their minds even after properly 
indicating an alerting situation via ACM (for example, a problem with the 
access interface or POTS line can be detected AFTER ringing begins -- power 
cross tests can fail, ring pre-trip can occur, etc.).  These rare 
situations aren't easy to cover in standards.

    Even if all the terminating-access stuff worked in a way that permitted 
a well-educated guess at status, there are cases where maintenance/overload 
controls can force the injection of an internal announcement without Answer 
-- and it's ISUP-all-the-way, right?  (These should not have "subscriber 
free", I admit.)

>In ISUP the Backward Call Indicators tell whether the call is end-to-end
>ISUP and whether the terminating access is ISDN.  They also tell when
>interworking has been encountered (i.e. inband signaling).
>
>Is it reasonable to assume that calling-terminal Ring Tone is possible
>when an end-to-end ISUP connection exists?

    It may be reasonable -- but my field experience says switches RELY on 
the knowledge that, no matter what, there is a reverse audio path over 
which they can inform the caller of call progress (or lack thereof).  I 
know of no testing anywhere that assures every switch implementation of SS7 
will NEVER send non-Ring-tone audio after returning an ACM indicating 
ISUP-all-the-way and "subscriber free".  In fact, Q.764 section 2.1.4.1 
makes it pretty plain that those indications are sent after all called 
party digits have been received and the subscriber is determined to be 
free.  The exchange is not required to assure that the access network (such 
as GR-303/V5.2) is actually alerting the subscriber before returning ACM.

---
    I'll reverse the argument -- show me a circuit-switching standard that 
indicates the circumstances where a calling terminal must provide Ring 
Tone, because the audio path is delayed until answer.  Or even one that 
doesn't provide a reverse audio path for voice calls.

    As I've also mentioned, if this were easily done, why in the world 
don't mobile networks do so today?  Wouldn't it allow them to increase 
number of call attempts per cell site?  And why this concept so desirable 
in a packet network??

Al Varney - Lucent Technologies, but just my opinion




From owner-megaco@fore.com  Fri May  4 00:24:42 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20991
	for ; Fri, 4 May 2001 00:24:42 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA14816;
	Fri, 4 May 2001 00:23:03 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA19624
	for megaco-list; Fri, 4 May 2001 00:20:49 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA19620
	for ; Fri, 4 May 2001 00:20:47 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA14674
	for ; Fri, 4 May 2001 00:20:41 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA19364;
	Fri, 4 May 2001 14:20:07 +1000 (EST)
Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA28912;
	Fri, 4 May 2001 14:20:06 +1000 (EST)
Message-ID: <3AF22E08.757117C5@ericsson.com>
Date: Fri, 04 May 2001 14:20:24 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Troy Cauble 
CC: Terry L Anderson ,
        "Rosen, Brian" ,
        "'Tom-PT Taylor'" ,
        "'Bemmel, Jeroen van (Jeroen)'" ,
        "'megaco@fore.com'" 
Subject: Re: Relationship Annex C values <=> package Property ID's
References: <4FBEA8857476D311A03300204840E1CF01A6F555@whq-msgusr-02.pit.comms.marconi.com> <3AF17608.48ACC612@lucent.com> <3AF1A958.97617C54@lucent.com> <3AF1B248.B712C546@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Annex C can be extended by people making contributions and adding new
parameters. New versions of Annex C can be worked upon if people want
new information elements. 

I'd prefer not to revisit a discussions that we had 1999 on the use of
native tags, SDP etc. We chose to have 2 different schemes. Being 2
different encodings schemes there will always be differences as SDP has
a life of its own as well as Annex C. Both SDP and Annex C are buckets
for information elements. You pick and choose to use the ones you want.

Technically a package could extend annex C because all properties in the
binary version of H.248 take the form of package:property=value. Annex C
is package 0. Termination State, Local Control, Local and Remote all
have this encoding in the binary version. Which I think is rather handy. 

I never did see why in the text encoding why local control, termination
state, local and remote must be coded differently. We have what we have.

Christian

Troy Cauble wrote:
> 
> Terry L Anderson wrote:
> >
> > Troy Cauble wrote:
> >
> > >
> > > Section C.11 is a line by line SDP replacement.  Some of the other
> > > Annex C
> > > items seem to be alternative encodings of information that could be
> > > encoded
> > > as SDP.
> > >
> > > IMHO, if any Annex C items don't have corresponding SDP elements, they
> > >
> > > should be removed.  It is fundamentally wrong to have features that
> > > are only
> > > accessible to the ASN.1 encoding of the protocol.  We should be
> > > striving
> > > for uniformity.
> >
> > They should agree, but this can be fixed as you suggest (remove Annex C
> > item) or by ADDing SDP.  Many can be added through 'a=' attributes in
> > SDP and RFCs can add these as was suggested in
> > draft-ietf-mmusics-sdp-atm-05 or recent draft-taylor-mmusic-sdptdm-00
> > do.  Many of these in Annex C and not yet in SDP are vital for
> > configuring specific termination types.  These could be added through
> > packages to LocalControl but this makes it more difficult for them to be
> > media specific.  SDP allows the parameter to apply to only specific
> > choices of the multiple proposed media.
> >
> > Removing them would seriously affect backward compatibility and so
> > probably not possible.
> 
> I had forgotten that the things in the Local and Remote Descriptors
> are not Properties.  Packages won't work here.
> 
> So for LD & RD non-properties in Annex C that are not yet in SDP,
> people will have a choice between using ASN.1 encoding only or
> influencing the evolution of SDP.
> 
> Consider the reverse direction.  How will new items that come out
> of the evolution of SDP make it into Annex C for ASN.1 encoding?
> Do we need a formal mechanism (like Packages) to extend Annex C?
> 
> On the other hand, the IG ammended the intro to Annex C to
> say that (some of?) the Annex C non-properties apply to the
> LocalControlDescriptor.  (But nothing tells us which ones.)
> 
> I would argue that any Annex C items that apply to the LCD
> *ARE* Properties, and should be removed from Annex C and moved
> to Packages.  Otherwise how will they be encoded as text?
> 
> -troy
> 
> > >
> > >
> > > People who need the non-SDP supported features currently in Annex C
> > > should be developing Packages, rather than going with an ASN.1 only
> > > solution.
> > >
> > > Can we seek out  and remove non-SDP supported features in Annex C?
> > >
> > > -troy
> > >
> > >


From owner-megaco@fore.com  Fri May  4 00:34:24 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21096
	for ; Fri, 4 May 2001 00:34:23 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA15378;
	Fri, 4 May 2001 00:32:58 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA20746
	for megaco-list; Fri, 4 May 2001 00:30:42 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA20739
	for ; Fri, 4 May 2001 00:30:41 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA15183
	for ; Fri, 4 May 2001 00:30:18 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA20309;
	Fri, 4 May 2001 14:28:57 +1000 (EST)
Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA00461;
	Fri, 4 May 2001 14:28:54 +1000 (EST)
Message-ID: <3AF23019.B787A53C@ericsson.com>
Date: Fri, 04 May 2001 14:29:13 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rezhirpavai@hss.hns.com
CC: "Rosen, Brian" ,
        "'titty@cdotb.ernet.in'" ,
        Madhu Babu Brahmanapally ,
        "'megaco mail list'" 
Subject: Re: Error in transaction reply.
References: <65256A41.00555D11.00@sandesh.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

I think Brian has a valid point. If you have a syntax error you can't
recover - there's something fundamentally wrong with the stack.
Depending where the actual syntax error is you may not even be able to
send anything sensible back. The side that detects the error in a
transaction reply should notify the appropriate O&M systems. As Brian
points out what happens if the ack has an error.

Christian 

rezhirpavai@hss.hns.com wrote:
> 
> Hello,
>      There could be an alternative to
> "Of course, you could get a syntax error on a transactionAck!  I think we can
> either ignore that possibility, or allow the Ack the other way.  I'd vote
> the former."
> The MG at this point just needs to know whether the MGC has processed the
> response or not. Thus it needs to know only the transaction id for the response
> which had failed. So the transactionAck with error descriptor could be replaced
> with a subtractTransaction which contains just the transaction id. If the MG
> understands the subtractTransaction token and the transaction id, it could undo
> the changes. If it fails to decode the token or the transaction id, anyhow a
> message level error should be generated in which case the action for handling a
> message level error would come into action.
> 
>                                          Regards,
>                                          R. Ezhirpavai
> 
> "Rosen, Brian"  on 05/03/2001 06:48:17 PM
> 
> To:   "'titty@cdotb.ernet.in'" , R Ezhirpavai/HSS@HSS
> cc:   Madhu Babu Brahmanapally , "'megaco mail list'"
>       
> 
> Subject:  RE: Error in transaction reply.
> 
> I'm beginning to think that maybe we ought to do something about this.
> 
> First of all, every one of these discussions around syntax errors often
> misses
> a real important point
>     There is basically no recovery possible for the error
> This is because there is no way either end is going to change the SYNTAX
> of the message it sends as a result of an error.  It's going to take the
> offending
> programmer to do that (20 lashes with a wet noodle please).  Your only
> real recourse is:
>     Don't do whatever caused that problem to happen, until the software is
> fixed
> 
> Now, having said that, real systems often have problems and vendors need
> a way to figure out what happened and even customers need a way to figure
> out that something wrong happened so they at least have a shot at a
> workaround.
> 
> The best solution I can come up with is a real change to the protocol, and
> I'm not
> at all wild about proposing something that actually changes things, but here
> goes:
> 
> Send a TransactionAck (even if you are using a reliable transport) with an
> error
> message.
> 
> Of course, you could get a syntax error on a transactionAck!  I think we can
> either ignore that possibility, or allow the Ack the other way.  I'd vote
> the former.
> 
> Brian
> 
> -----Original Message-----
> From: Titty Thomas [mailto:titty@jnana.cdotb.ernet.in]
> Sent: Wednesday, May 02, 2001 11:39 PM
> To: rezhirpavai@hss.hns.com
> Cc: Madhu Babu Brahmanapally; titty@cdotb.ernet.in; 'megaco mail list'
> Subject: Re: Error in transaction reply.
> 
> Hi ,
> 
>     In this case one of the options can be to audit the MG and find out its
> state.
> 
> Regards,
> -- Titty
> 
> rezhirpavai@hss.hns.com wrote:
> 
> Hello Madhu,
>      If the MGC assumes that the transaction response containing a parse
> error
> is a transaction reply with error, then this would lead to discrepancy
> between
> the states of MG and MGC. The MGC would assume that the MG has not processed
> the
> request whereas the MG would have processed the request and would have
> possibly
> changed the termination state.
> 
>                                          Regards,
>                                          R. Ezhirpavai
> 
> "Madhu Babu Brahmanapally"  on 05/02/2001 07:09:47 PM
> 
> To:   titty@cdotb.ernet.in, "'megaco mail list'" 
> cc:    (bcc: R Ezhirpavai/HSS)
> 
> Subject:  RE: Error in transaction reply.
> 
> Hi Titty,
> 
> In normal circumstances, even if the MGC retransmit its transaction-request
> the same transaction response is received from MG. IMO the MGC can treat the
> 
> error transaction response as error response from MG.
> Regards
> Madhubabu
> 
>  -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [ mailto:owner-megaco@pit.comms.marconi.com
>  ]On Behalf Of Titty Thomas
> Sent: Wednesday, May 02, 2001 12:04 AM
> To: megaco mail list
> Subject: Error in transaction reply.
> 
>   Hi all,
> 
>       If there is an error in transaction reply, what will the receiver of
> the reply do. How
>   can he report back to the sender that the reply was an error. And what
> will happen if
> 
>   the reply had some values chosen by the sender (eg. reply for a command
> with $ ) and the
> 
>   value is in error.
> 
>   Regards,
> 
>   - Titty
> 
> --
> +------------------------------------------------------------------+
> |Two roads diverged in a wood, and I took the one less traveled by,|
> |And that has made all the difference.                             |
> +------------------------------------------------------------------+
> 
>   ------------------------------------------------------------------------
>                   Name: att1.htm
>    att1.htm       Type: Hypertext Markup Language (text/html)
>               Encoding: base64
>            Description: Internet HTML
> 
> --
> 
> +------------------------------------------------------------------+
> 
> |Two roads diverged in a wood, and I took the one less traveled by,|
> 
> |And that has made all the difference.                             |
> 
> +------------------------------------------------------------------+
> 
>   ------------------------------------------------------------------------
>                   Name: att1.htm
>    att1.htm       Type: Hypertext Markup Language (text/html)
>               Encoding: base64
>            Description: Internet HTML


From owner-megaco@fore.com  Fri May  4 07:28:49 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09056
	for ; Fri, 4 May 2001 07:28:48 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA02287;
	Fri, 4 May 2001 07:27:16 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA10466
	for megaco-list; Fri, 4 May 2001 07:24:10 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA10461
	for ; Fri, 4 May 2001 07:24:09 -0400 (EDT)
Received: from localhost (213.237.12.37.adsl.ynoe.worldonline.dk [213.237.12.37])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id HAA02037
	for ; Fri, 4 May 2001 07:23:46 -0400 (EDT)
Message-Id: <200105041123.HAA02037@mailgate.pit.comms.marconi.com>
Content-Type: text/html
X-Source: web mail
X-Form: AdrMsg.html
From: Gridcomp 
To: megaco@fore.com
Date: Fri, 14 Apr 2000 00:07:30
Subject: Reduce your Software Development Cost
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

					
				
				
				
				
				
				
				

				  
				    

				      
				        

				      		
				      
				        
 
				        

				        
 

				      		
				    

				    

				      
				        
 
				        
 

				        


				        

				        
 
				        

				        
 

				        

				          

				            Is
				              time running out for your  software development project?
				              
				              
 

				          

				          

				            Are
				              you looking for Off shore project development?
				              
				              

				              
				              
				              

				          

				          

				            
				              
Do
				              you have to cut cost?

				              
 But
				              you must continue innovating? 

				              
Must
				              design and develop new products?

				              
 

				          

				          

				            
				            
				          

				        

				      		
				      
				       
				        
				
				              
				
				          

				            

				              
				              Is
				              time running out for your  software development project?
				                
				            

				            

				              
				              Are
				              you looking for Off shore project development?
				                
				            

				            

				              
				              Do
				              you have to cut cost? 
				            

				            

				              
				              But
				              you must continue innovating? 
				            

				            

				              
				              Must
				              design and develop new products?
				            

				          

				          

				


				Gridcomp
				is
				on-site consulting and offshore development company. We design, develop,
				implement
				and support E-Business Solutions. Practically right from the start of IT
				boom, software development companies from USA, have used off-shore development
				company resources from other countries. We created Gridcomp Inc. exactly for
				the companies interested in 
				offshore development. We believe in providing high quality yet inexpensive
				offshore development services with qualified on-site consultants for deployment
				of technology solutions for our clients in USA, enhancing their competitiveness.
				

				
Gridcomp is
				one of the fast growing software services and product Development Company
				specializing in leading technologies.

				
  
				
 Gridcomp International, Inc.

				          

				            

				              »  
				              Enterprise Application
				Integration  
				            

				            

				              »  
				              Distributed Business Computing     
				            

				            

				              »  
				              Business Intelligence
				    
				            

				            

				              »  
				              E-Commerce  
				              
				            

				          

				

				
Why Gridcomp International Inc. is suitable
				for your software development requirement? 

				

				High reliability, High service level, Moderate prices, Wide range of services,
				Speedy project implementation, High degree of confidentiality, Very simple
				scheme for customer interaction, Constant working resource availability

				

				For more information visit our web page: 
				Click here

				          

				            

				              »  
				              
				Our    distinctive competence lies in the focused range of services we provide.
				                     
				            

				            

				              »  
				              
				We    believe that our thrust should be in specific areas where we can add
				    significant value.         
				            

				            

				              »  
				              
				We    created Gridcomp Inc. exactly for the companies interested in offshore
				    development.         
				            

				            

				              »  
				              
				The    Gridcomp business model adopts a true software factory approach.
				     
				            

				            

				              »  
				              
				Our    pool of on-site consultants is in turn backed by the offshore development
				    center that executes offshore projects and also provides a 24/7 technical
				    support desk.    
				            

				            

				              »  
				              Our
				                India Development Centers are located at Ahmedabad, India.
				                Gridcomp plans to leverage the Software Park to provide
				                dedicated development centers for clients worldwide. 
				            

				          

				

				

				Our Services are divided into this areas

				          

				            

				              »  
				              
				Off-Shore Software Development 
				            

				            

				              
				              
				                
>

				               Why    Offshore?
				    
				            

				            

				              »  
				              
				On-site consulting 
				            

				            

				              
				              
				                
>

				               Why    On-site?
				    
				            

				            

				              »  
				              
				 Technology Solutions
				            

				            

				              
				              >
				               Enterprise
				                Application Integration
				    
				            

				            

				              
				              >
				              Mobile
				                Integration Solutions
				    
				            

				            

				              
				              >
				              CAD
				                / CAM Engineering Solutions
				    
				            

				            

				              
				              >
				              E-Commerce
				    
				            

				            

				              
				              >
				              ASIC
				                / FPGA design
				    
				            

				            

				              »  
				              
				Technology Marketing
				    
				            

				            

				              
				              >
				              Marketing    Collateral Services 
				    
				            

				            

				              
				              >
				              
				   Preparing marketing presentations Preparing technical presentations
				            

				            

				              
				              >
				              
				   Technical Marketing Collateral 
				Product    Training manuals 
				 
				    
				            

				            

				              
				              >
				              
				Competitive analysis for products Design 
				            

				            

				              
				              >
				              Development    of   product demo (Hardware & Software)  
				            

				            

				              
				              >
				               Technical
				    support 
				            

				            

				              
				              >
				               Analysis
				and    summary data of customer inquiries
				            

				          

				

				

				Strategic advantages of software development in India

				          

				            

				              »  
				              Significant  reduction in costs   
				            

				            

				              »  
				              Competitive rates for contracting charges that are less than 50% of USA rates!   
				            

				            

				              »  
				              
				No overheads.   
				            

				            

				              »  
				              
				No general and administrative costs.    
				            

				            

				              »  
				              
				No space requirements.    
				            

				            

				              »  
				              
				No facilities costs (such as rent, utilities, maintenance) 
				            

				            

				              »  
				              
				No recruiting or human resources costs.    
				            

				            

				              »  
				              
				Availability of highly educated and skilled professionals 
				            

				            

				              »  
				              
				India has the second largest pool of English-speaking technical talent. 
				  
				            

				            

				              »  
				              
				  Shortened development time frames.    
				            

				            

				              »  
				              
				Strong work ethics. 
				            

				            

				              »  
				              
				Scope for development to take place 24 hours a day because of the different
				time zones.
				            

				            

				              »  
				              
				Full control over the project being developed in India by keeping in touch with the development team
				                through high-speed communication links. 
				  
				            

				            

				              »  
				              Easier procedure for movement of hardware and software 
				            

				            

				              
				              
				            

				          

				

				For more details log on to our web page: 
				Click here

				

				

				Our interaction model are as follows

				          

				            

				              
				Via Local Manager 
				                
				              <
				              Client
				              >
				              Via Off-shore Manager 
				            

				            

				              (USA office)
				               (India Development Center)
				            

				          

				

				

				Goals of our Company
				

				

				One of the most important goals of our Company is to create the most comfortable
				conditions for customers. We have developed 
				plans that are most convenient for our clients (the details about the
				customized plans log on our web-page.
				 

				

				
We offer also a wide selection of planning
				and budgeting models for our services. The most widely used models are as
				follows: Project-Based
				Plan & Time-Based Plan.

				

				Nevertheless, if your company requires other operating rules, we would be
				glad to oblige.

				

				Our main goal is to make a client's life easier. We solve most of the technical
				problems internally within our Company, so a client is usually only informed
				that the project is implemented. When necessary, however, our specialists are
				ready to supply technical consulting of any depth concerning the project; this
				approach allows a client to be aware of as many project implementation
				details. 

				

				
Our
				Strengths

				
Our core competency is software / hardware engineers with these skills: 

				          

				            

				              »  
				              Software programming skills:
				    Java, J2EE, Java
				    Beans, EJB, JSP, JINI, XML, WAP, WML, J2ME, UML-Rational Rose,
				    C, C++, VC++, C # and Visual basic.
				            

				            

				              »  
				              Application
				    Servers: BEA
				    Web Logic, IBM Web Sphere, Sun Java Web server, Apache, Oracle 9i
				    Application Server.
				            

				            

				              »  
				              Client
				    / Server and Data Base technology – CORBA, Oracle, Sybase, SQL server, Power Builder.
				            

				            

				              »  
				              Web Based Technology – Java, COM,
				                DCOM, Perl, CGI, HTML, XML.
				            

				            

				              »  
				              Operating system internals – UNIX, Solaris, NT, Windows 95
				            

				            

				              »  
				              Network management/administration –
				                SNMP, Routers, switches, bridges, DSL, Frame relay, ATM
				            

				            

				              »  
				              System administration – Unix, NT,
				    Win 2000, Solaris, Linux
				            

				            

				              »  
				              Networking / Telecommunication software – TCP/IP protocol suite, ISDN,
				                xDSL, ATM, Frame relay, SNMP, LAN, WAN protocols
				            

				          

				

				

				For further information please contact at
				

				

				 706 Colorado Ave, Suite C11, Palo
				Alto, CA 94303, USA

				         Telephone: +01-650-494-0613
				

				       Fax:+01-240-
				371-0543

				
e-mail:
				sales@gridcompintl.com  

				e-mail: 
				support@gridcompintl.com

				        

				        

				      		
				    

				  
				
				  

				
				
				
This
				is not meant to be an unsolicited email.....

				Under Bills 1618
				Title III passed by the 105th US Congress this mail cannot be considered spam as long as 

				 we include contact information and
				a method to be removed from our mailing list.

				
				
If
				you like an email or list of email address(es) to be removed from the mailing list, 

				 please
				reply to this e-mail with a subject REMOVE and list
				the email address(es) 

				 in the body of your reply message. We
				will make sure that you do not receive further messages.

				We sincerely apologize for any inconvenience caused
				to you.

				
							
			


From owner-megaco@fore.com  Fri May  4 09:19:55 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11868
	for ; Fri, 4 May 2001 09:19:53 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA08990;
	Fri, 4 May 2001 09:19:04 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA02190
	for megaco-list; Fri, 4 May 2001 09:15:43 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA02185
	for ; Fri, 4 May 2001 09:15:41 -0400 (EDT)
Received: from web13205.mail.yahoo.com (web13205.mail.yahoo.com [216.136.174.190])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id JAA08615
	for ; Fri, 4 May 2001 09:15:37 -0400 (EDT)
Message-ID: <20010504131539.93021.qmail@web13205.mail.yahoo.com>
Received: from [132.245.3.163] by web13205.mail.yahoo.com; Fri, 04 May 2001 06:15:39 PDT
Date: Fri, 4 May 2001 06:15:39 -0700 (PDT)
From: Mc Keny 
Subject: priority for contexts
To: megaco@fore.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


Hi,

why does the MG need to handle a number of contexts
incase of a Restart?

Thanks
Mac

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/


From owner-megaco@fore.com  Fri May  4 09:44:26 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12317
	for ; Fri, 4 May 2001 09:44:21 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA11368;
	Fri, 4 May 2001 09:43:31 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA09098
	for megaco-list; Fri, 4 May 2001 09:42:29 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA09087
	for ; Fri, 4 May 2001 09:42:27 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id JAA11184
	for ; Fri, 4 May 2001 09:42:24 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id JAA18901; Fri, 4 May 2001 09:42:22 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Fri, 4 May 2001 09:42:13 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 4 May 2001 09:42:17 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CAAA@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Dave Sclarsky'" ,
        "'Troy Cauble'" , MEGACO list 
Subject: RE: multiple digitmaps
Date: Fri, 4 May 2001 09:42:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D4A0.078CD5A0"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D4A0.078CD5A0
Content-Type: text/plain;
	charset="iso-8859-1"

This is one of those grey-area things.  Given that it would break an
implementation, I guess we should hold off.

-----Original Message-----
From: Dave Sclarsky [mailto:Dave.Sclarsky@radisys.com]
Sent: Thursday, May 03, 2001 3:58 PM
To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Troy Cauble'; MEGACO list
Subject: RE: multiple digitmaps


This will break [at least one :-( ] current implementations.  Are you
proposing to change this for v1, or could it wait till v2?
 
DaveS.

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Thursday, May 03, 2001 3:32 PM
To: 'Troy Cauble'; MEGACO list
Subject: RE: multiple digitmaps



You're right.  I think we intended this.  Does anyone object?   

> -----Original Message----- 
> From: Troy Cauble [ mailto:troy@lucent.com  ] 
> Sent: Thursday, May 03, 2001 11:51 AM 
> To: MEGACO list 
> Subject: multiple digitmaps 
> 
> 
> 
> MEGACO/1 [12.12.12.12]:12345 
> Transaction = 1030 {Context = - {Modify = ROOT { 
>   DigitMap = Pin {(xxxx|xxxxxx)}, 
>   DigitMap = UserId {(xxxxxx)}, 
>   DigitMap = Dialplan0 {(0|00|911|1xxxxxxxxxx|Exx|[2-9]xxxxxx|9011x.)} 
> }}} 
> 
> 
> Multiple digitmaps in Add/Move/Modify parameters are 
> currently illegal based on comments in Annex A and B.  
> This seems pretty useful. 
> 
> 
> Proposal: 
> 
> In Annex B, rewrite the comment above the "ammParameter" spec as: 
>       ; at-most-once except for digitMapDescriptor. 
> 
> In Annex A, rewrite the comment in the "AmmRequest" spec as: 
>       -- At most one descriptor of each type (see AmmDescriptor) 
>       -- allowed in the sequence, except for DigitMapDescriptor. 
> 
> 
> -troy 
> 


------_=_NextPart_001_01C0D4A0.078CD5A0
Content-Type: text/html;
	charset="iso-8859-1"




RE: multiple digitmaps




This 
is one of those grey-area things.  Given that it would break an 
implementation, I guess we should hold off.



  
-----Original Message-----
From: Dave Sclarsky 
  [mailto:Dave.Sclarsky@radisys.com]
Sent: Thursday, May 03, 2001 3:58 
  PM
To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Troy Cauble'; MEGACO 
  list
Subject: RE: multiple digitmaps


  
This 
  will break [at least one :-( ] current implementations.  Are you 
  proposing to change this for v1, or could it wait 
  till v2?

  
 

  
DaveS.

  

    
-----Original Message-----
From: Tom-PT Taylor 
    [mailto:taylor@nortelnetworks.com]
Sent: Thursday, May 03, 2001 
    3:32 PM
To: 'Troy Cauble'; MEGACO list
Subject: RE: 
    multiple digitmaps


    
You're right.  I think we intended this.  Does 
    anyone object?   

    
> -----Original Message----- 
> 
    From: Troy Cauble [mailto:troy@lucent.com] 
> Sent: Thursday, May 03, 2001 11:51 AM 
> To: MEGACO list 
> Subject: multiple 
    digitmaps 
> 
> 
    
> 
> MEGACO/1 
    [12.12.12.12]:12345 
> Transaction = 1030 {Context 
    = - {Modify = ROOT { 
>   DigitMap = Pin 
    {(xxxx|xxxxxx)}, 
>   DigitMap = UserId 
    {(xxxxxx)}, 
>   DigitMap = Dialplan0 
    {(0|00|911|1xxxxxxxxxx|Exx|[2-9]xxxxxx|9011x.)} 
> 
    }}} 
> 
> 
    
> Multiple digitmaps in Add/Move/Modify 
    parameters are 
> currently illegal based on 
    comments in Annex A and B.  
> This seems 
    pretty useful. 
> 
> 
    
> Proposal: 
> 
    
> In Annex B, rewrite the comment above the 
    "ammParameter" spec as: 
> 
          ; at-most-once except for 
    digitMapDescriptor. 
> 
> In Annex A, rewrite the comment in the "AmmRequest" spec 
    as: 
>       -- At most 
    one descriptor of each type (see AmmDescriptor) 
> 
          -- allowed in the sequence, except for 
    DigitMapDescriptor. 
> 
> 
> -troy 
> 
    


------_=_NextPart_001_01C0D4A0.078CD5A0--


From owner-megaco@fore.com  Fri May  4 09:59:59 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12606
	for ; Fri, 4 May 2001 09:59:44 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA12771;
	Fri, 4 May 2001 09:58:53 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA13521
	for megaco-list; Fri, 4 May 2001 09:58:17 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA13512
	for ; Fri, 4 May 2001 09:58:15 -0400 (EDT)
From: financial_success1@excite.com
Received: from ns1.pivot.net (ns1.pivot.net [208.130.42.121])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA12667
	for ; Fri, 4 May 2001 09:58:12 -0400 (EDT)
Received: from pivot.net (stan001b-p2-200.cybertours.com [208.161.16.200])
	by ns1.pivot.net (8.11.0/8.11.0) with SMTP id f44DrVK21133;
	Fri, 4 May 2001 09:53:32 -0400 (EDT)
Received: from mailhost.debtfree.com(alt1.lost.com(208.9.77.65)) by debtfree.com (8.8.5/8.6.5) with SMTP id GAA09418 for ; Fri, 04 May 2001 09:21:36 -0600 (EST)
Date: Fri, 04 May 01 09:21:36 EST
To: success@debtfree.com
Subject: Proven Opportunity! NRQY
Message-ID: <199702170025.BAA08567@lost.com>
Reply-To: succsess@debtfree.com
X-UIDL: 246932563a79b123fgt456a8a9b
Comments: Authenticated sender is 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


              E-WORK AT HOME USING YOUR COMPUTER!!!

_________________________________________________________________

Dear Friend,

You can earn $46,000 or more in next the 90 days sending e-mail.
Seem impossible? Read on for details (no, there is no "catch")... Truly this program works.
Just think how it will feel to be debt free and able to do the things you want to do. You have
nothing to lose and everything to gain.

_________________________________________________________________

                      "AS SEEN ON NATIONAL T.V."

Thank you for your time and Interest.

This is the letter you've been reading about in the news lately.

Due to the popularity of this letter on the Internet, a major nightly news program recently
devoted an entire show to the investigation of the program described below, to see if it really
can make people money.
The show also investigated whether or not the program was legal.Their findings proved once
and for all that there are, absolutely no Laws prohibiting the participation in the program. This
has helped to Show people that this is a simple, harmless
and fun way
to make some extra money at home. The results of this show has been truly remarkable. So
many people are participating that those involved are doing, much better than ever before.
Since everyone makes more as more people try it out, it's been
very exciting to be a part of lately. You will understand once you experience it.

                           "HERE IT IS BELOW"
_________________________________________________________________

*** Print This Now For Future Reference ***

The following income opportunity is one you may be interested in taking a look at. It can be
started with VERY LITTLE investment and the income return is TREMENDOUS!!!

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

If you would like to make at least $46,000 in less than 90 days!

Please read the enclosed program...THEN READ IT AGAIN!!!

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY. It does not
require you to come into contact with people, do any hard work, and best of all, you never
have to leave the house except to get the mail. If you believe that someday you'll get that big
break that you've been waiting for, THIS IS IT! Simply
follow the instructions, and your dreams will come true.
This multi-level e-mail order marketing program works perfectly...100% EVERY TIME. E-mail is
the sales tool of the future. Take advantage of this non-commercialized method of advertising
NOW!!! The longer you wait,  the more people will
be doing business using e-mail. Get your piece of this action!!!
MULTI-LEVEL MARKETING (MLM) has finally gained respectability. It
is being taught in the Harvard Business School, and both Stanford Research and the Wall
Street Journal have stated that between 50% and 65% of all goods and services will be sold
through multi-level methods by the mid to late 1990's.

This is a Multi-Billion Dollar industry and of the 3,500,000 Millionaires in the WORLD, 20% (
700,000) made their fortune in the last several years in MLM. Moreover, statistics show that
over 100 people become millionaires everyday through
Multi-Level Marketing.

You may have heard this story before, but over the summer Donald Trump (A MULTI-
BILLIONAIRE, ONE OF THE WEALTHIEST MEN IN THE WORLD) made an appearance on
the David Letterman show. Dave asked him what he
would do if he lost everything and had to start over from scratch. Without hesitating, Trump
said he would find a good network marketing company and get to work. The audience started
to hoot and boo him. He looked out at the audience and
deadpanned his response "That's why I'm sitting up here and you are all sitting out there!"

With network marketing you have two sources of income. Direct Commissions from sales you
make yourself and commissions from sales made by people you introduce to the business.
Residual income is the secret of the wealthy. It means
investing time or money once and getting paid again and again and again. In network
marketing, it also means getting paid for the work of others.

This program is currently being utilized in more than 50 different countries across the world.
The enclosed INF0RMATION is something I almost let slip through my fingers. Fortunately,
sometime later I re-read everything and gave some thought and study to it.

My name is Johnathon Rourke. Two years ago, the corporation I worked at for the past twelve
years downsized and my position was eliminated. After unproductive job interviews, I decided
to open my own business. Over the past year, I
incurred many unforeseen financial problems. I owed my family, friends and creditors over
$35,000.
The economy was taking a toll on my business and I just couldn't seem to make ends meet. I
had to refinance and borrow against my home to support my family and struggling business.

AT THAT MOMENT something significant happened in my life and I am
writing to share the experience in hopes that this will change your life FOREVER
FINANCIALLY!!!
In mid December, I received this program via e-mail. Six month's prior to receiving this program I
had been sending away for INF0RMATION on various business opportunities. All of the
programs I received, in my opinion, were not cost
effective. They were either too difficult for me to comprehend or the initial investment was too
much for me to risk to see if they would work or not.
One claimed that I would make a million dollars in one year...it didn't tell me I'd have to write a
book to make it! But like I was saying, in December of 1997 I received this program. I didn't
send for it, or ask for it, they just got my name off a
mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I
was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING
PHENOMENON. I could invest as much as I wanted to start,
without putting me
further into debt. After I got a pencil and paper and figured it out, I would at least get my money
back. But like most of you I was still a little skeptical and a little worried about the legal aspects
of it all. So I checked it out with the U.S. Post Office
(1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After determining the
program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT."

Initially I sent out 100,000 e-mails. It cost me about $15 for my time on-line. The great thing
about e-mail is that I don't need any money for printing to send out the program, and because
all of my orders are fulfilled via e-mail, the only expense is
my time. I
am telling you like it is, I hope it doesn't turn you off, but I promised myself that I would not "rip-
off" anyone, no matter how much money it cost me.
In less than one week, I was starting to receive orders for REPORT #1. By January 13, I had
received 26 orders for REPORT #1. Your goal is to "RECEIVE at least 20 ORDERS FOR
REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T,
SEND OUT MORE PROGRAMS UNTIL YOU DO!"
My first step in making $46,000 in 90 days was done.
By January 30, I had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT
LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE
PROGRAMS UNTIL YOU DO. ONCE YOU
HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $46,000
GOAL." Well, I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and
relaxed.
By March 1, of my e-mailing of 100,000, I received $58,000 with more coming in every day. I
paid off ALL my debts and bought a much needed new car.
Please take time to read the attached program, IT WILL CHANGE YOUR
LIFE FOREVER!!!

Remember, it won't work if you don't try it. This program does work, but you must follow it
EXACTLY! Especially the rules of not trying to place your name in a different place. It won't
work, you'll lose out on a lot of money! In order for this
program to work, you must meet your goal of 20+ orders For REPORT #1, and 100+ orders for
REPORT #2 and you will make $46,000 or more in 90 days. I AM LIVING PROOF THAT IT
WORKS!!!
If you choose not to participate in this program, I am sorry. It really is a great opportunity with
little cost or risk to you. If you choose to participate, follow the program and you will be on your
way to financial security. If you are a fellow business
owner and are if financial trouble like I was, or you want to start your own business, consider
this a sign.
I DID!
Sincerely,
Johnathon Rourke

         A PERSONAL NOTE FROM THE ORIGINATOR OF THISPROGRAM:

By the time you have read the enclosed program and reports, you should have concluded that
an amateur could, not have created such a program, and one that is legal. Let me tell you a
little about myself. I had a profitable business for 10 years.
Then in 1979 my business began falling off. I was doing the same things that were previously
successful for me, but it wasn't working. Finally, I figured it out. It wasn't me, it was the
economy. Inflation and recession had replaced the stable
economy that had been with us since 1945.
I don't have to tell you what happened to the unemployment rate...because many of you know
from first hand experience. There were more failures and bankruptcies than ever before. The
middle class was vanishing. Those who knew what they
were doing invested wisely and moved up. Those who did not, including those who never had
anything to save or invest, were moving down into the ranks of the poor.
As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER."
The traditional methods of making money will never allow you to "move up" or "get rich",
inflation will see to that. You have just received INF0RMATION that can give you financial
freedom for the rest of your life, with "NO RISK" and "JUST A
LITTLE BIT OF EFFORT." You can make more money in the next few months than you have
ever imagined.
I should also point out that I will not see a penny of this money, nor anyone else who has
provided a testimonial for this program. I have already made over 4 MILLION DOLLARS! I
have retired from the program after sending out over
1,600,000 programs. Now I have several offices that make this and several other programs
here and over seas.
Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works
exceedingly well as it is now. Remember to e-mail a copy of this exciting report to everyone you
can think of. One of the people you send this to may
send out 100,000 or more...and your name will be on every one of them! Remember though,
the more you send out the more potential customers you will reach. So my friend, I have given
you the ideas, INF0RMATION, materials and
opportunity to become financially independent, IT IS UP TO YOU NOW!  "THINK ABOUT IT"
Before you delete this program from your mailbox, as I almost did, take a little time to read it and
REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU
participate. Figure out the worst possible response and
no matter how you
calculate it, you will still make a lot of money! You will definitely get back what you invested.
Any doubts you have will vanish when your first orders come in. IT WORKS!

Jody Jacobs, Richmond, VA.
HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS
OF DOLLAR$ INSTRUCTIONS:

This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could
use up to $46,000 or more in the next 90 days. Before you say, "BULL... ", please read this
program carefully. This is not a chain letter, but a
perfectly legal money making opportunity. Basically, this is what you do:  As with all multi-level
businesses, we build our business by recruiting new partners and selling our products. Because
of the
global nature of the Internet, you will be able to recruit new multi-level business partners from all
over the world, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY
MAIL AND ARE FILLED BY E-MAIL, so you are
not involved in personal selling. You do it privately in your own home, store or office. This is the
GREATEST
Multi-Level Mail Order Marketing anywhere. This is what you MUST do:
1. Order all 5 reports shown on the list below (you can't sell them if you don't order them).
a. For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE
ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of
a problem) to the person whose name
appears on the list next to the report.
MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL
PROBLEMS!
b. When you place your order, make sure you order each of the five reports. You will need all
five reports so that you can save them on your computer and resell them.
c. Within a few days you will receive, via e-mail, each of the five reports. Save them on your
computer so they will be accessible for you to send to the 1,000's of people who will order them
from you.
2. IMPORTANT-- DO NOT alter the names of the people who are listed next to each report, or
their sequence on the list, in any way other than is instructed below in steps "a" through "g" or
you will lose out on the majority of your profits. Once
you understand the way this works, you'll also see how it doesn't work if you change it.
Remember this method  has been tested, and if you alter it, it will not work.
a. Look below for the listing of available reports.

b. After you've ordered the five reports, take this advertisement and REM0VE the name and
address under REPORT #5. This person has made it through the cycle and is no doubt
counting their $46,000! Also, change the name of the company,
the address, and the REM0VE e-mail address on the  top of this document to your own.

c. Move the name and address under REPORT #4 down to REPORT #5.

d. Move the name and address under REPORT #3 down to REPORT #4.

e. Move the name and address under REPORT #2 down to REPORT #3.

f. Move the name and address under REPORT #1 down to REPORT #2.

g. Insert your name/address in the REPORT #1 position. Please make sure you copy every
name and address ACCURATELY!

3. Take this entire letter, including the modified list of names, and save it to your computer.
Make NO changes to the instruction portion of this letter. Your cost to participate in this is
practically nothing (surely you can afford $25). You obviously
already have an Internet connection and e-mail is FREE! To assist you with marketing your
business on the internet, the 5 Reports you purchase will provide you with invaluable marketing
INF0RMATION which includes how to send bulk e-
mails, where to find thousands of Free classified ads and much, much more. In addition you will
be provided with INFORMATION on Internet

Marketing Clubs such as INTERNET MARKETING RESOURCES(IMR): This is
one the Premiere Internet marketing clubs on the INTERNET. This club provides a forum
where Internet marketers from all over the world can exchange ideas and secrets on Internet
Marketing. In addition, members of this club are provided
free Internet
marketing tools and services for the Do-Yourself-Internet-Marketer. They will provide you with
free bulk e-mail software and up to 1,000,000 fresh e-mail addresses each week. This club will
provide you with hundreds of free resources which
include: How to obtain
free web sites, how to obtain top rankings in search engines for your web-site, how to send
bulk e-mail into AOL and Compuserve, how to market your products on news groups, free
classified ads, electronic malls, bulletin boards, banner ads
and much more.
There are two primary methods of building your downline:
METHOD #1: SENDING BULK E-MAIL
Let's say that you decide to start small, just to see how it goes, and we'll assume you and all
those involved send out only 2,000 programs each. Let's also assume that the mailing receives
a 0.3% response. Using a good list the response could be
much better. Also, many people will send out hundreds of thousands of programs instead of
2,000. But continuing with this example, you send out only 2,000 programs. With a 0.3%
response, that is only 6 orders for REPORT #1. Those 6
people respond by sending out 2,000 programs each for a total of 12,000. Out of those 0.3%,
36 people respond and order
REPORT #2. Those 36 mails out 2,000 programs each for a total of  72,000. The 0.3%
response to that is 216 orders for REPORT #3. Those 216 send out 2,000 programs each for a
432,000 total. The 0.3%response to that is 1,296 orders
for REPORT #4. Those 1,296 send out 2,000 programs each for a 2,592,000 total. The 0.3%
response to that is 7,776 orders for REPORT #5. That's 7,776 $5 bills for you, CASH!!! Your
total income in this example is $30 + $180 +
$1,080+ $6,480 + $38,880 for a total of  $46,650!!!
REMEMBER FRIEND, THIS IS ASSUMING 1,994 OUT OF THE 2,000 PEOPLE
YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE
TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT
OUT 100,000 PROGRAMS INSTEAD
OF 2,000.
Believe me, many people will do just that, and more! By the way, your cost to participate in this
is practically nothing. You obviously already have an Internet connection and e-mail is FREE!!!
REPORT #2 and #5 will show you the best methods
for bulk emailing,
tell you where to obtain free bulk e-mail software and where to obtain e-mail lists and show you
how to send out 1,000,000 e-mails for free.
METHOD #2 - PLACING FREE ADS ON THE INTERNET
1. Advertising on the 'Net is very, very inexpensive, and there are HUNDREDS of FREE
places to advertise. Let's say you decide to start  small just to see how well it works. Assume
your goal is to get ONLY 6 people to participate on your
first level. (Placing a
lot of FREE ads on the Internet will EASILY get a larger response.) Also assume that everyone
else in YOUR ORGANIZATION gets ONLY 6 downlink members. Follow this example to
achieve the STAGGERING results below.
1st level--your 6 members with $5 ($5 x  6)........................$30
2nd level--6 members from those 6 ($5 x 36)....................$180
3rd level--6 members from those 36 ($5 x 216)............ $1,080
4th level--6 members from those 216 ($5 x 1,296)....... $6,480
5th level--6 members from those 1,296 ($5 x 7,776)... $38,880
……………….................................................$46,650
_________________________________________________________________

Remember friends, this assumes that the people who participate only recruit 6 people each.
Think for a moment what would happen if they got 20  people to participate! Many people will
get 100's of participants! THINK ABOUT IT!  For every
$5.00 you receive, all you must do is e-mail them the report they ordered.
THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS!
This will guarantee that the e-mail THEY send out, with YOUR name and address on it, will be
prompt because they can't advertise until they receive the report!
_________________________________________________________________

AVAILABLE REPORTS
*** Order Each REPORT by NUMBER and NAME ***
Notes:  ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT CHECKS NOT
ACCEPTED ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL Make sure the cash is
concealed by wrapping it in at least two
sheets of paper.
On one of those sheets of paper, include: (a) the number & name of the report you are ordering,
(b) your e-mail address, and  (c)your name & postal address.

PLACE YOUR ORDER FOR THESE REPORTS NOW:
REPORT #1 "The Insider's Guide to Advertising for Free on the Internet"
ORDER REPORT #1 FROM:
Carolynne R. Barela
20 Libby Pines Rd.
Standish, ME 04084-6317


REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet"
ORDER REPORT #2 FROM:
Glen Mercer
Bay Roberts, NF
Canada
A0A  1G0

REPORT #3 "The Secrets to Multilevel Marketing on the Internet"
ORDER REPORT #3 FROM:
David Horn
Heath Adv.
40 Grove Street, Ste. 435
Wellesley, MA  02482

REPORT #4 "How to become a Millionaire utilizing the Power of
Multilevel Marketing and the Internet"
ORDER REPORT #4 FROM:
ZT Corp
13237 Montfort, Ste. 301
Dallas, TX  75240

REPORT #5 "How to SEND 1,000,000 e-mails for FREE"
ORDER REPORT #5 FROM:
Gary Goldman
6476 Bellevue Drive
Conyers, GA 30094
There currently more than 175,000,000 people online worldwide!
******* TIPS FOR SUCCESS *******

* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow
the directions accurately.

* Send for the five reports IMMEDIATELY so you will have them when
the orders start coming in because:

When you receive a $5 order, you MUST send out the requested product/report.

* ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE.

* Be patient and persistent with this program. If you follow the instructions exactly, your results
WILL BE SUCCESSFUL!

* ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED!

******* YOUR SUCCESS GUIDELINES *******

Follow these guidelines to guarantee your success:
If you don't receive 20 orders for REPORT #1 within two weeks,continue advertising or
sending e-mails until you do. Then, a couple of weeks later you should receive at least 100
orders for REPORT#2. If you don't,  continue advertising or
sending e-mails
until you do.

Once you have received 100 or more orders for REPORT #2, YOU CAN
RELAX, because the system is already working for you, and the cash will Continue to roll in!

THIS IS IMPORTANT TO REMEMBER:
Every time your name is moved down on the list, you are placed in
front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS
by watching which report people are ordering from you. If you want
to generate more income, send another batch of e-mails or continue
placing ads and start the whole process again! There is no limit
to the income you will generate from this business!

Before you make your decision as to whether or not you participate
in this program. Please answer one question. DO YOU WANT TO CHANGE
YOUR LIFE?
If the answer is yes, please look at the following facts about this program:
1. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO
PRODUCE!

2. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO SHIP!

3. YOU ARE SELLING A PRODUCT, WHICH DOES NOT COST YOU ANYTHING TO
ADVERTISE!
4. YOU ARE UTILIZING THE POWER OF THE INTERNET AND THE POWER OF
MULTI-LEVEL MARKETING TO DISTRIBUTE YOUR PRODUCT ALL OVER THE
WORLD!
5. YOUR ONLY EXPENSES OTHER THAN YOUR INITIAL $25 INVESTMENT IS
YOUR TIME!
6. VIRTUALLY ALL OF THE INCOME YOU GENERATE FROM THIS PROGRAM IS PURE
PROFIT!
7. THIS PROGRAM WILL CHANGE YOUR LIFE FOREVER.

******* T E S T I M O N I A L S *******
This program does work, but you must follow it EXACTLY! Especially
the rule of not trying to place your name in a different position, it won't  work and you'll lose a lot
of potential income. I'm living proof that it works. It really is a great opportunity to make
relatively easy money, with little cost to you. If you do
choose to participate, follow the program exactly, and you'll be on your way to financial
security.

Fred Dellaca, Westport, New Zealand

My name is Mitchell. My wife, Jody, and I live in Chicago, IL. I am a  cost accountant with a
major U.S. Corporation and I make pretty good money. When I received the program I
grumbled to Jody about receiving "junk mail." I made fun of the
whole thing,
spouting my knowledge of the population and percentages involved. I "knew" it wouldn't work.
Jody totally ignored my supposed intelligence and jumped in with both feet. I made merciless
fun of her, and was ready to lay the old "I told you so"
on her when the thing didn't work... well, the laugh was on me! Within two weeks she had
received over 50 responses. Within 45 days she had received over $147,200 in $5 bills! I was
shocked! I was sure that I had it all figured and that it
wouldn't work. I AM a believer now. I have joined Jody in her "hobby." I did have seven more
years until retirement, but I think of the "rat race" and it's not for me. We owe it all to MLM.

Mitchell Wolf MD., Chicago, IL

The main reason for this letter is to convince you that this system is honest, lawful, extremely
profitable, and is a way to get a large amount of money in a short time. I was approached
several times before I checked this out. I joined just to see
what one could expect in return for the minimal effort and money required. To my astonishment,
I received $36,470.00 in the first 14 weeks, with money still coming in.

Sincerely yours,
Pam Hedland Halmstad, Sweden

Not being the gambling type, it took me several weeks to make up my mind to participate in this
plan. But conservative that I am, I decided that the initial investment was so little that there was
just no way that I wouldn't get enough orders to at
least get my money back. I surprised when I  found my medium-size post office box crammed
with orders! For a while, it got so overloaded that I had to start picking up my mail at the
window. I'll make more money this year than any 10 years of
my life before. The nice thing about this deal is that it doesn't matter where people live. There
simply isn't a better investment with a faster return.
Dan Sondstrom, Alberta, Canada

I had received this program before. I deleted it, but later I wondered if I shouldn't have given it
a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was
e-mailed another program,.11 months passed then it
came...I didn't delete this one!...I made more than $41,000 on the first try!!

Mohamed, Cairo, Egypt
=======================================================
''I had received this program before. I deleted it, but later I wondered
if I should have given it a try. Of course, I had no idea who to contact to
get another copy, so I had to wait until I was e-mailed again by someone
else.........11 months passed then it luckily came again...... I did not
delete this one! I made more than $490,000 on my first try and all the
money came within 22 weeks."
Susan De Suza, New York, N.Y.
=======================================================
''It really is a great opportunity to make relatively easy money with
little cost to you. I followed the simple instructions carefully and
within 10 days the money started to come in. My first month I made
$20,560.00 and by the end of third month my total cash count was
$362,840.00. Life is beautiful, Thanx to internet.".
Fred Dellaca, Westport, New Zealand
=======================================================
ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL
FREEDOM! NOW IS THE TIME FOR YOUR TURN.

DECISIVE ACTION YIELDS POWERFUL RESULTS!!!!

If you have any questions of the legality of this program, contact the
Office of Associate Director for Marketing Practices, Federal Trade
Commission, Bureau of Consumer Protection, Washington, D.C.

All our mailings are sent complying to the proposed United States Federal
requirements for commercial e-mail: Section 301 Paragraph (a)(2)(C) of S.
618.

Per Section 301, Paragraph (a)(2)(C) of S. 618, further transmissions to
you by the sender may be stopped at NO COST to you by forwarding this e-mail
the e-mail address noted below.
If you have received this by mistake and do not wish to remain in my address book, please just
send me a
note.  You will be removed immediately. mail to: debfree_remove@excite.com






Get your FREE download of MSN Explorer at http://explorer.msn.com


From owner-megaco@fore.com  Fri May  4 10:20:48 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13059
	for ; Fri, 4 May 2001 10:20:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15048;
	Fri, 4 May 2001 10:19:52 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA19744
	for megaco-list; Fri, 4 May 2001 10:18:33 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19739
	for ; Fri, 4 May 2001 10:18:32 -0400 (EDT)
Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14855
	for ; Fri, 4 May 2001 10:18:28 -0400 (EDT)
Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1])
	by alemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f44EITQ21001
	for ; Fri, 4 May 2001 10:18:29 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by alemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f44EIT320977
	for ; Fri, 4 May 2001 10:18:29 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id KAA19171; Fri, 4 May 2001 10:18:27 -0400 (EDT)
Cc: "'Dave Sclarsky'" ,
        MEGACO list 
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id KAA19149; Fri, 4 May 2001 10:18:25 -0400 (EDT)
Message-ID: <3AF2B9BE.E6BAFCAF@lucent.com>
Date: Fri, 04 May 2001 10:16:30 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom-PT Taylor 
Original-CC: "'Dave Sclarsky'" ,
        MEGACO list 
Subject: Re: multiple digitmaps
References: <28560036253BD41191A10000F8BCBD110250CAAA@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Given the changes we see on this list every week, I'm
suprised at the pushback for a minor parsing change.
But I guess you have to have to draw a line somewhere.

The currently legal alternative is to wrap N DigitMapDescriptors 
in N Add/Move/Modifys.  Not a massive inconvenience, just 
a minor ugliness.  (So I hope the breakage you're worried 
about is just in your parsing, not your ability to hold 
more than one DigitMap.)

-troy


> This is one of those grey-area things.  Given that it would break an implementation, I guess we should hold off.
> 
>     -----Original Message-----
>     From: Dave Sclarsky [mailto:Dave.Sclarsky@radisys.com]
>     Sent: Thursday, May 03, 2001 3:58 PM
>     To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Troy Cauble'; MEGACO list
>     Subject: RE: multiple digitmaps
> 
>     This will break [at least one :-( ] current implementations.  Are you proposing to change this for v1, or could it wait till v2?
>      
>     DaveS.
> 
>         -----Original Message-----
>         From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>         Sent: Thursday, May 03, 2001 3:32 PM
>         To: 'Troy Cauble'; MEGACO list
>         Subject: RE: multiple digitmaps
> 
>         You're right.  I think we intended this.  Does anyone object?   
> 
>         > -----Original Message----- 
>         > From: Troy Cauble [mailto:troy@lucent.com] 
>         > Sent: Thursday, May 03, 2001 11:51 AM 
>         > To: MEGACO list 
>         > Subject: multiple digitmaps 
>         > 
>         > 
>         > 
>         > MEGACO/1 [12.12.12.12]:12345 
>         > Transaction = 1030 {Context = - {Modify = ROOT { 
>         >   DigitMap = Pin {(xxxx|xxxxxx)}, 
>         >   DigitMap = UserId {(xxxxxx)}, 
>         >   DigitMap = Dialplan0 {(0|00|911|1xxxxxxxxxx|Exx|[2-9]xxxxxx|9011x.)} 
>         > }}} 
>         > 
>         > 
>         > Multiple digitmaps in Add/Move/Modify parameters are 
>         > currently illegal based on comments in Annex A and B.  
>         > This seems pretty useful. 
>         > 
>         > 
>         > Proposal: 
>         > 
>         > In Annex B, rewrite the comment above the "ammParameter" spec as: 
>         >       ; at-most-once except for digitMapDescriptor. 
>         > 
>         > In Annex A, rewrite the comment in the "AmmRequest" spec as: 
>         >       -- At most one descriptor of each type (see AmmDescriptor) 
>         >       -- allowed in the sequence, except for DigitMapDescriptor. 
>         > 
>         > 
>         > -troy 
>         >


From owner-megaco@fore.com  Fri May  4 11:26:28 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14260
	for ; Fri, 4 May 2001 11:26:13 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA21110;
	Fri, 4 May 2001 11:25:24 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA08715
	for megaco-list; Fri, 4 May 2001 11:23:54 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08711
	for ; Fri, 4 May 2001 11:23:53 -0400 (EDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA20929
	for ; Fri, 4 May 2001 11:23:49 -0400 (EDT)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id KAA08452
	for ; Fri, 4 May 2001 10:23:48 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f44FNlT09497
	for ; Fri, 4 May 2001 10:23:47 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f44FNC116020
	for ; Fri, 4 May 2001 10:23:12 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f44FNCO04362
	for ; Fri, 4 May 2001 10:23:12 -0500 (CDT)
Message-ID: <3AF2C960.6C61D1FF@usa.alcatel.com>
Date: Fri, 04 May 2001 10:23:12 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "'megaco@fore.com'" 
Subject: TCP + RFC1006
Content-Type: multipart/alternative;
 boundary="------------DECE0A0FA46496D9555549BE"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------DECE0A0FA46496D9555549BE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom

Can I get an understanding of how RFC works?

Megaco RFC3015 specifies the use of TCP+RFC1006.

If I go to the IETF.org and try to get RFC1006, it is not available any
more.
(I was able to get it last year.)

The IETF index page shows the following:

1006 ISO transport services on top of the TCP: Version 3. M.T. Rose,
     D.E. Cass. May-01-1987. (Format: TXT=31935 bytes) (Obsoletes
RFC0983)
     (Updated by RFC2126) (Also STD0035) (Status: STANDARD)

2126 ISO Transport Service on top of TCP (ITOT). Y. Pouffary, A.
     Young. March 1997. (Format: TXT=51032 bytes) (Updates RFC1006)
     (Status: PROPOSED STANDARD)

Now the questions are:

1) Did RFC2126 supersed RFC1006?
2) If yes, how does it affect Megaco RFC3015?

3) Does Megaco implementation automatically go w/the latest RFC that
replaces RFC1006?

4) If Megaco implementation has to stick w/RFC1006, how does one get a
copy of it?

5) Is there an IETF understanding if an RFC (say RFCa) references
another RFC (say RFCb),
     implementator of RFCa will have to always upgrade their
implementation if RFCb was
     obsoleted by a newer RFC?

     I see ITU H.248 also reference IETF RFC.  So what does ITU
understanding of how
     obsolete RFC affect ITU implementation?

Personally I think we ought to remove TCP from Megaco.


Thanks
Chuong


--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------DECE0A0FA46496D9555549BE
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Tom

Can I get an understanding of how RFC works?

Megaco RFC3015 specifies the use of TCP+RFC1006.

If I go to the IETF.org and try to get RFC1006, it is not available
any more.

(I was able to get it last year.)

The IETF index page shows the following:

1006 ISO transport services on top of the TCP: Version 3. M.T. Rose,

     D.E. Cass. May-01-1987. (Format: TXT=31935
bytes) (Obsoletes RFC0983)

     (Updated by RFC2126) (Also STD0035) (Status:
STANDARD)

2126 ISO Transport Service on top of TCP (ITOT). Y. Pouffary, A.

     Young. March 1997. (Format: TXT=51032 bytes)
(Updates RFC1006)

     (Status: PROPOSED STANDARD)

Now the questions are:

1) Did RFC2126 supersed RFC1006?

2) If yes, how does it affect Megaco RFC3015?

3) Does Megaco implementation automatically go w/the latest RFC that
replaces RFC1006?

 

4) If Megaco implementation has to stick w/RFC1006, how does one get
a copy of it?

5) Is there an IETF understanding if an RFC (say RFCa) references
another RFC (say RFCb),

     implementator of RFCa will have to always
upgrade their implementation if RFCb was

     obsoleted by a newer RFC?

     I see ITU H.248 also reference IETF RFC. 
So what does ITU understanding of how

     obsolete RFC affect ITU implementation?

Personally I think we ought to remove TCP from Megaco.

 

Thanks

Chuong

 

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------DECE0A0FA46496D9555549BE--



From owner-megaco@fore.com  Fri May  4 11:47:47 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14859
	for ; Fri, 4 May 2001 11:47:42 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22962;
	Fri, 4 May 2001 11:46:38 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA12223
	for megaco-list; Fri, 4 May 2001 11:40:13 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA12119
	for ; Fri, 4 May 2001 11:39:46 -0400 (EDT)
Received: from slink12.ss7-link.com (mail.ss7-link.com [209.204.106.218])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22273
	for ; Fri, 4 May 2001 11:39:41 -0400 (EDT)
Received: by SLINK12 with Internet Mail Service (5.5.2650.21)
	id ; Fri, 4 May 2001 11:39:43 -0400
Message-ID: 
From: Dave Sclarsky 
To: "'Troy Cauble'" ,
        Tom-PT Taylor
	 
Cc: MEGACO list 
Subject: RE: multiple digitmaps
Date: Fri, 4 May 2001 11:39:42 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Troy,

I guess we made certain assumptions in our design, for example, a "message"
could contain an unlimited number of transactions.  A transaction could
contain an unlimited number of actions.  An action could contain an
unlimited number of commands.  But a command can only contain at-most-one of
each descriptor.  So it isn't the parser that breaks, it's the internal
representation of a command.  We do support N modifies, each with 1
digitmapdescriptor.

I don't really like holding back progress for one implementation (even if
its mine!)...but I suspect that there are also others that will need at
least minor tweaks for this to work.  So, given the fact that the workaround
isn't all that bad, doesn't it seem reasonable to hold off until v2?

DaveS.

-----Original Message-----
From: Troy Cauble [mailto:troy@lucent.com]
Sent: Friday, May 04, 2001 10:17 AM
To: Tom-PT Taylor
Cc: 'Dave Sclarsky'; MEGACO list
Subject: Re: multiple digitmaps




Given the changes we see on this list every week, I'm
suprised at the pushback for a minor parsing change.
But I guess you have to have to draw a line somewhere.

The currently legal alternative is to wrap N DigitMapDescriptors 
in N Add/Move/Modifys.  Not a massive inconvenience, just 
a minor ugliness.  (So I hope the breakage you're worried 
about is just in your parsing, not your ability to hold 
more than one DigitMap.)

-troy


> This is one of those grey-area things.  Given that it would break an
implementation, I guess we should hold off.
> 
>     -----Original Message-----
>     From: Dave Sclarsky [mailto:Dave.Sclarsky@radisys.com]
>     Sent: Thursday, May 03, 2001 3:58 PM
>     To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Troy Cauble'; MEGACO list
>     Subject: RE: multiple digitmaps
> 
>     This will break [at least one :-( ] current implementations.  Are you
proposing to change this for v1, or could it wait till v2?
>      
>     DaveS.
> 
>         -----Original Message-----
>         From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>         Sent: Thursday, May 03, 2001 3:32 PM
>         To: 'Troy Cauble'; MEGACO list
>         Subject: RE: multiple digitmaps
> 
>         You're right.  I think we intended this.  Does anyone object?   
> 
>         > -----Original Message----- 
>         > From: Troy Cauble [mailto:troy@lucent.com] 
>         > Sent: Thursday, May 03, 2001 11:51 AM 
>         > To: MEGACO list 
>         > Subject: multiple digitmaps 
>         > 
>         > 
>         > 
>         > MEGACO/1 [12.12.12.12]:12345 
>         > Transaction = 1030 {Context = - {Modify = ROOT { 
>         >   DigitMap = Pin {(xxxx|xxxxxx)}, 
>         >   DigitMap = UserId {(xxxxxx)}, 
>         >   DigitMap = Dialplan0
{(0|00|911|1xxxxxxxxxx|Exx|[2-9]xxxxxx|9011x.)} 
>         > }}} 
>         > 
>         > 
>         > Multiple digitmaps in Add/Move/Modify parameters are 
>         > currently illegal based on comments in Annex A and B.  
>         > This seems pretty useful. 
>         > 
>         > 
>         > Proposal: 
>         > 
>         > In Annex B, rewrite the comment above the "ammParameter" spec
as: 
>         >       ; at-most-once except for digitMapDescriptor. 
>         > 
>         > In Annex A, rewrite the comment in the "AmmRequest" spec as: 
>         >       -- At most one descriptor of each type (see AmmDescriptor)

>         >       -- allowed in the sequence, except for DigitMapDescriptor.

>         > 
>         > 
>         > -troy 
>         >


From owner-megaco@fore.com  Fri May  4 11:52:42 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14981
	for ; Fri, 4 May 2001 11:52:37 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23492;
	Fri, 4 May 2001 11:51:49 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA15198
	for megaco-list; Fri, 4 May 2001 11:51:10 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA15192
	for ; Fri, 4 May 2001 11:51:09 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 4 May 2001 11:50:57 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F55F@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Chuong Nguyen'" ,
        "'megaco@fore.com'"
	 
Subject: RE: TCP + RFC1006
Date: Fri, 4 May 2001 11:51:07 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0D4B2.086E08B0"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D4B2.086E08B0
Content-Type: text/plain;
	charset="iso-8859-1"

Worked for me:
ftp://ftp.isi.edu/in-notes/rfc1006.txt
 
 
also known as STD35
 
RFCs are never "removed", they are all around.  They get superceded.
 
The part we care about (TPKT) wasn't touched by 2126.
 
You DON'T get an automatic upgrade when your reference changes.
 
Brian
 

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Friday, May 04, 2001 11:23 AM
To: 'megaco@fore.com'
Subject: TCP + RFC1006


Tom 

Can I get an understanding of how RFC works? 


Megaco RFC3015 specifies the use of TCP+RFC1006. 


If I go to the IETF.org and try to get RFC1006, it is not available any
more. 
(I was able to get it last year.) 


The IETF index page shows the following: 


1006 ISO transport services on top of the TCP: Version 3. M.T. Rose, 
     D.E. Cass. May-01-1987. (Format: TXT=31935 bytes) (Obsoletes RFC0983) 
     (Updated by RFC2126) (Also STD0035) (Status: STANDARD) 


2126 ISO Transport Service on top of TCP (ITOT). Y. Pouffary, A. 
     Young. March 1997. (Format: TXT=51032 bytes) (Updates RFC1006) 
     (Status: PROPOSED STANDARD) 


Now the questions are: 


1) Did RFC2126 supersed RFC1006? 
2) If yes, how does it affect Megaco RFC3015? 


3) Does Megaco implementation automatically go w/the latest RFC that
replaces RFC1006? 
  
4) If Megaco implementation has to stick w/RFC1006, how does one get a copy
of it? 


5) Is there an IETF understanding if an RFC (say RFCa) references another
RFC (say RFCb), 
     implementator of RFCa will have to always upgrade their implementation
if RFCb was 
     obsoleted by a newer RFC? 


     I see ITU H.248 also reference IETF RFC.  So what does ITU
understanding of how 
     obsolete RFC affect ITU implementation? 


Personally I think we ought to remove TCP from Megaco. 
  


Thanks 
Chuong 
  

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


------_=_NextPart_001_01C0D4B2.086E08B0
Content-Type: text/html;
	charset="iso-8859-1"









Worked for 
me:



 


also known as 
STD35


 


RFCs are 
never "removed", they are all around.  They get 
superceded.


 


The part we 
care about (TPKT) wasn't touched by 2126.


 


You DON'T get 
an automatic upgrade when your reference changes.


 


Brian


 



  
-----Original Message-----
From: Chuong Nguyen 
  [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Friday, May 04, 2001 
  11:23 AM
To: 'megaco@fore.com'
Subject: TCP + 
  RFC1006

Tom 
  
Can I get an understanding of how RFC works? 
  
Megaco RFC3015 specifies the use of TCP+RFC1006. 
  
If I go to the IETF.org and try to get RFC1006, it is not available 
  any more. 
(I was able to get it last year.) 
  
The IETF index page shows the following: 
  
1006 ISO transport services on top of the TCP: Version 3. M.T. Rose, 
  
     D.E. Cass. May-01-1987. (Format: TXT=31935 bytes) 
  (Obsoletes RFC0983) 
     (Updated by RFC2126) (Also 
  STD0035) (Status: STANDARD) 
  
2126 ISO Transport Service on top of TCP (ITOT). Y. Pouffary, A. 
  
     Young. March 1997. (Format: TXT=51032 bytes) 
  (Updates RFC1006) 
     (Status: PROPOSED STANDARD) 
  
Now the questions are: 
  
1) Did RFC2126 supersed RFC1006? 
2) If yes, how does it affect Megaco 
  RFC3015? 
  
3) Does Megaco implementation automatically go w/the latest RFC that 
  replaces RFC1006? 
  
4) If Megaco implementation has to stick 
  w/RFC1006, how does one get a copy of it? 
  
5) Is there an IETF understanding if an RFC (say RFCa) references 
  another RFC (say RFCb), 
     implementator of RFCa 
  will have to always upgrade their implementation if RFCb was 
  
     obsoleted by a newer RFC? 
  
     I see ITU H.248 also reference IETF 
  RFC.  So what does ITU understanding of how 
     
  obsolete RFC affect ITU implementation? 
  
Personally I think we ought to remove TCP from Megaco. 
  
  
Thanks 
Chuong 
  
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  



------_=_NextPart_001_01C0D4B2.086E08B0--


From owner-megaco@fore.com  Fri May  4 12:13:03 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15639
	for ; Fri, 4 May 2001 12:12:51 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA25106;
	Fri, 4 May 2001 12:12:00 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA20172
	for megaco-list; Fri, 4 May 2001 12:10:59 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA20167
	for ; Fri, 4 May 2001 12:10:58 -0400 (EDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA24925
	for ; Fri, 4 May 2001 12:10:54 -0400 (EDT)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id LAA19985
	for ; Fri, 4 May 2001 11:10:55 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f44GAsT26338
	for ; Fri, 4 May 2001 11:10:54 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f44GAD123041
	for ; Fri, 4 May 2001 11:10:13 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f44GADO06568
	for ; Fri, 4 May 2001 11:10:13 -0500 (CDT)
Message-ID: <3AF2D465.3353693C@usa.alcatel.com>
Date: Fri, 04 May 2001 11:10:13 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "'megaco@fore.com'" 
Subject: Re: TCP + RFC1006
References: <4FBEA8857476D311A03300204840E1CF01A6F55F@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: multipart/alternative;
 boundary="------------8F7BF882AC5C1EBCC9FA0977"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------8F7BF882AC5C1EBCC9FA0977
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks

I couldn't get it from your link.
But I was able to get via STD35 via an internal archive.

I was trying to get it from http://www.ietf.org/rfc.html which just give
me a blank page.


"Rosen, Brian" wrote:

> Worked for me:ftp://ftp.isi.edu/in-notes/rfc1006.txtalso known as
> STD35RFCs are never "removed", they are all around.  They get
> superceded.The part we care about (TPKT) wasn't touched by 2126.You
> DON'T get an automatic upgrade when your reference changes.Brian
>
>      -----Original Message-----
>      From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
>      Sent: Friday, May 04, 2001 11:23 AM
>      To: 'megaco@fore.com'
>      Subject: TCP + RFC1006
>      Tom
>
>      Can I get an understanding of how RFC works?
>
>      Megaco RFC3015 specifies the use of TCP+RFC1006.
>
>      If I go to the IETF.org and try to get RFC1006, it is not
>      available any more.
>      (I was able to get it last year.)
>
>      The IETF index page shows the following:
>
>      1006 ISO transport services on top of the TCP: Version 3.
>      M.T. Rose,
>           D.E. Cass. May-01-1987. (Format: TXT=31935 bytes)
>      (Obsoletes RFC0983)
>           (Updated by RFC2126) (Also STD0035) (Status: STANDARD)
>
>      2126 ISO Transport Service on top of TCP (ITOT). Y.
>      Pouffary, A.
>           Young. March 1997. (Format: TXT=51032 bytes) (Updates
>      RFC1006)
>           (Status: PROPOSED STANDARD)
>
>      Now the questions are:
>
>      1) Did RFC2126 supersed RFC1006?
>      2) If yes, how does it affect Megaco RFC3015?
>
>      3) Does Megaco implementation automatically go w/the latest
>      RFC that replaces RFC1006?
>
>      4) If Megaco implementation has to stick w/RFC1006, how does
>      one get a copy of it?
>
>      5) Is there an IETF understanding if an RFC (say RFCa)
>      references another RFC (say RFCb),
>           implementator of RFCa will have to always upgrade their
>      implementation if RFCb was
>           obsoleted by a newer RFC?
>
>           I see ITU H.248 also reference IETF RFC.  So what does
>      ITU understanding of how
>           obsolete RFC affect ITU implementation?
>
>      Personally I think we ought to remove TCP from Megaco.
>
>
>      Thanks
>      Chuong
>
>
>      --
>        Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>        1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>        **** The opinions expressed are not those of Alcatel USA, Inc ****
>
>
>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------8F7BF882AC5C1EBCC9FA0977
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Thanks

I couldn't get it from your link.

But I was able to get via STD35 via an internal archive.

I was trying to get it from http://www.ietf.org/rfc.html which
just give me a blank page.

 

"Rosen, Brian" wrote:

Worked
for me:ftp://ftp.isi.edu/in-notes/rfc1006.txtalso
known as STD35RFCs
are never "removed", they are all around.  They get superceded.The
part we care about (TPKT) wasn't touched by 2126.You
DON'T get an automatic upgrade when your reference changes.Brian



-----Original
Message-----

From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]

Sent: Friday, May 04, 2001
11:23 AM

To: 'megaco@fore.com'

Subject: TCP + RFC1006

Tom

Can I get an understanding of how RFC works?

Megaco RFC3015 specifies the use of TCP+RFC1006.

If I go to the IETF.org and try to get RFC1006, it is not available
any more.

(I was able to get it last year.)

The IETF index page shows the following:

1006 ISO transport services on top of the TCP: Version 3. M.T. Rose,

     D.E. Cass. May-01-1987. (Format: TXT=31935
bytes) (Obsoletes RFC0983)

     (Updated by RFC2126) (Also STD0035) (Status:
STANDARD)

2126 ISO Transport Service on top of TCP (ITOT). Y. Pouffary, A.

     Young. March 1997. (Format: TXT=51032 bytes)
(Updates RFC1006)

     (Status: PROPOSED STANDARD)

Now the questions are:

1) Did RFC2126 supersed RFC1006?

2) If yes, how does it affect Megaco RFC3015?

3) Does Megaco implementation automatically go w/the latest RFC that
replaces RFC1006?

4) If Megaco implementation has to stick w/RFC1006, how does one get
a copy of it?

5) Is there an IETF understanding if an RFC (say RFCa) references another
RFC (say RFCb),

     implementator of RFCa will have to always
upgrade their implementation if RFCb was

     obsoleted by a newer RFC?

     I see ITU H.248 also reference IETF RFC. 
So what does ITU understanding of how

     obsolete RFC affect ITU implementation?

Personally I think we ought to remove TCP from Megaco.

 

Thanks

Chuong

 

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 





-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------8F7BF882AC5C1EBCC9FA0977--



From owner-megaco@fore.com  Fri May  4 12:13:44 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15700
	for ; Fri, 4 May 2001 12:13:40 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA25272;
	Fri, 4 May 2001 12:12:50 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA20242
	for megaco-list; Fri, 4 May 2001 12:11:34 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA20235
	for ; Fri, 4 May 2001 12:11:32 -0400 (EDT)
Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA24992
	for ; Fri, 4 May 2001 12:11:28 -0400 (EDT)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.9.3/8.9.3) id MAA26502;
	Fri, 4 May 2001 12:11:18 -0400 (EDT)
Date: Fri, 4 May 2001 12:11:18 -0400 (EDT)
From: Scott Bradner 
Message-Id: <200105041611.MAA26502@newdev.harvard.edu>
To: Chuong.Nguyen@usa.alcatel.com, megaco@fore.com
Subject: Re: TCP + RFC1006
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

> If I go to the IETF.org and try to get RFC1006, it is not available any

you might want to try again - RFCs once published are available forever
(or as close to it as we can deal with)


http://www.ietf.org/rfc/rfc1006.txt

Scott


From owner-megaco@fore.com  Fri May  4 12:52:12 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16755
	for ; Fri, 4 May 2001 12:52:12 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA27907;
	Fri, 4 May 2001 12:51:20 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA27198
	for megaco-list; Fri, 4 May 2001 12:50:21 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA27188
	for ; Fri, 4 May 2001 12:50:19 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 4 May 2001 12:50:07 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F56B@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Chuong Nguyen'" ,
        "'megaco@fore.com'"
	 
Subject: RE: TCP + RFC1006
Date: Fri, 4 May 2001 12:50:17 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0D4BA.4C081EA0"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D4BA.4C081EA0
Content-Type: text/plain;
	charset="iso-8859-1"

Okay, I understand your problem.  Try it again, and SCROLL DOWN.
 
For whatever reason, there is a bunch of CRLFs before the text starts on
this document!!!
 
Brian

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Friday, May 04, 2001 12:10 PM
To: 'megaco@fore.com'
Subject: Re: TCP + RFC1006


Thanks 

I couldn't get it from your link. 
But I was able to get via STD35 via an internal archive. 


I was trying to get it from http://www.ietf.org/rfc.html
  which just give me a blank page. 
  


"Rosen, Brian" wrote: 


Worked for me: ftp://ftp.isi.edu/in-notes/rfc1006.txt
 also known as STD35RFCs are never
"removed", they are all around.  They get superceded.The part we care about
(TPKT) wasn't touched by 2126.You DON'T get an automatic upgrade when your
reference changes.Brian 

-----Original Message----- 
From: Chuong Nguyen [ mailto:Chuong.Nguyen@usa.alcatel.com
 ] 
Sent: Friday, May 04, 2001 11:23 AM 
To: 'megaco@fore.com' 
Subject: TCP + RFC1006
Tom 

Can I get an understanding of how RFC works? 


Megaco RFC3015 specifies the use of TCP+RFC1006. 


If I go to the IETF.org and try to get RFC1006, it is not available any
more. 
(I was able to get it last year.) 


The IETF index page shows the following: 


1006 ISO transport services on top of the TCP: Version 3. M.T. Rose, 
     D.E. Cass. May-01-1987. (Format: TXT=31935 bytes) (Obsoletes RFC0983) 
     (Updated by RFC2126) (Also STD0035) (Status: STANDARD) 


2126 ISO Transport Service on top of TCP (ITOT). Y. Pouffary, A. 
     Young. March 1997. (Format: TXT=51032 bytes) (Updates RFC1006) 
     (Status: PROPOSED STANDARD) 


Now the questions are: 


1) Did RFC2126 supersed RFC1006? 
2) If yes, how does it affect Megaco RFC3015? 


3) Does Megaco implementation automatically go w/the latest RFC that
replaces RFC1006? 


4) If Megaco implementation has to stick w/RFC1006, how does one get a copy
of it? 


5) Is there an IETF understanding if an RFC (say RFCa) references another
RFC (say RFCb), 
     implementator of RFCa will have to always upgrade their implementation
if RFCb was 
     obsoleted by a newer RFC? 


     I see ITU H.248 also reference IETF RFC.  So what does ITU
understanding of how 
     obsolete RFC affect ITU implementation? 


Personally I think we ought to remove TCP from Megaco. 
  


Thanks 
Chuong 
  

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


------_=_NextPart_001_01C0D4BA.4C081EA0
Content-Type: text/html;
	charset="iso-8859-1"









Okay, I 
understand your problem.  Try it again, and SCROLL 
DOWN.


 


For whatever 
reason, there is a bunch of CRLFs before the text starts on this 
document!!!


 


Brian



  
-----Original Message-----
From: Chuong Nguyen 
  [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Friday, May 04, 2001 
  12:10 PM
To: 'megaco@fore.com'
Subject: Re: TCP + 
  RFC1006

Thanks 
  
I couldn't get it from your link. 
But I was able to get via STD35 
  via an internal archive. 
  
I was trying to get it from http://www.ietf.org/rfc.html which 
  just give me a blank page. 
  
  
"Rosen, Brian" wrote: 
  
Worked for me:ftp://ftp.isi.edu/in-notes/rfc1006.txtalso 
    known as STD35RFCs are never "removed", they are all 
    around.  They get superceded.The part we 
    care about (TPKT) wasn't touched by 2126.You DON'T get 
    an automatic upgrade when your reference changes.Brian 
    

      
-----Original Message----- 
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com] 
      
Sent: Friday, May 04, 2001 
      11:23 AM 
To: 
      'megaco@fore.com' 
Subject: TCP + RFC1006
Tom 
      
Can I get an understanding of how RFC works? 
      
Megaco RFC3015 specifies the use of TCP+RFC1006. 
      
If I go to the IETF.org and try to get RFC1006, it is not available any 
      more. 
(I was able to get it last year.) 
      
The IETF index page shows the following: 
      
1006 ISO transport services on top of the TCP: Version 3. M.T. Rose, 
      
     D.E. Cass. May-01-1987. (Format: TXT=31935 
      bytes) (Obsoletes RFC0983) 
     (Updated by 
      RFC2126) (Also STD0035) (Status: STANDARD) 
      
2126 ISO Transport Service on top of TCP (ITOT). Y. Pouffary, A. 
      
     Young. March 1997. (Format: TXT=51032 bytes) 
      (Updates RFC1006) 
     (Status: PROPOSED STANDARD) 

      
Now the questions are: 
      
1) Did RFC2126 supersed RFC1006? 
2) If yes, how does it affect 
      Megaco RFC3015? 
      
3) Does Megaco implementation automatically go w/the latest RFC that 
      replaces RFC1006? 
      
4) If Megaco implementation has to stick w/RFC1006, how does one get a 
      copy of it? 
      
5) Is there an IETF understanding if an RFC (say RFCa) references 
      another RFC (say RFCb), 
     implementator of RFCa 
      will have to always upgrade their implementation if RFCb was 
      
     obsoleted by a newer RFC? 
      
     I see ITU H.248 also reference IETF RFC.  
      So what does ITU understanding of how 
     
      obsolete RFC affect ITU implementation? 
      
Personally I think we ought to remove TCP from Megaco. 
  
      
Thanks 
Chuong 
  
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
 
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  



------_=_NextPart_001_01C0D4BA.4C081EA0--


From owner-megaco@fore.com  Fri May  4 13:09:43 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17110
	for ; Fri, 4 May 2001 13:09:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA29439;
	Fri, 4 May 2001 13:08:53 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA02347
	for megaco-list; Fri, 4 May 2001 13:07:56 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA02323
	for ; Fri, 4 May 2001 13:07:53 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA29241
	for ; Fri, 4 May 2001 13:07:49 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id <2XWA0AAA>; Fri, 4 May 2001 12:08:25 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD9494524FA2C@RADVPOST>
From: Dan Elbert 
To: "'Rosen, Brian'" ,
        "'megaco@fore.com'"
	 
Subject: RE: MGC failure
Date: Fri, 4 May 2001 12:08:20 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

What would be an MG ServiceChange that doesn't change the state ?
Using an "extension" ServiceChangeMethod ?
Maybe this has to be defined in the protocol as there is a risk of causing
interoperability problems if the MGC doesn't interpret the MG SVC rigth.

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Thursday, May 03, 2001 9:26 AM
To: 'Groom, William'; 'Dan Elbert'; 'megaco@fore.com'
Subject: RE: MGC failure


Heartbeats have been discussed for some time.

Any message sent from one end to the other gets a reply, so
any message can be a heartbeat message.  It doesn't
require any special package or protocol feature.

Suppose the MGC wants to know if MGs are alive
	Periodically send a message to it that doesn't do anything (NOP)
Same idea for the MG - periodically send the MGC a message.
Smart implementations would have a timer that is reset by any
transaction request or reply from the other side.

For the MGC, there are a plethora of nops.  Empty Audit is
an obvious one.

For the MG, there are fewer choices, but you CAN send a service
change that doesn't change any state.

Brian

> -----Original Message-----
> From: Groom, William [mailto:William.Groom@icn.siemens.com]
> Sent: Thursday, May 03, 2001 8:47 AM
> To: 'Dan Elbert'; 'megaco@fore.com'
> Subject: RE: MGC failure
> 
> 
> Dan,
> 
> With regards to the first part of your question. I hope the 
> following helps.
> 
> Clarification Of Problem:
> 
> When the MGC restarts (including O/S) all associations to the 
> MG are lost.
> No messages can be sent from the MGC to the MG until the MG 
> has sent a SC
> (restart message on root).
> 
> If the connection is TCP, then the MG will get to know about 
> the MGC restart
> (eventually) and can go through its normal restart processing to
> re-establisg MGC connections. 
> 
> If UDP, then the MG is oblivious to the MGC restart.  The 
> action taken by
> the MG will depend upon the state of the MG at the time of 
> the MGC restart.
> I.E.
> 
> 1. MG is active carrying traffic. In this state the MG will 
> timeout the MGC,
> break existing MGC associations and reconnect. This is fine.
> 
> 2. MG is already trying to connect. This is also fine.
> 
> 3. MG is Down (offline). This is fine since it will establish 
> connection
> upon restart.
> 
> 4. MG is Idle (No calls in progress). A trunking MG will 
> remain in this
> state forever, until some manual intervention takes place. 
> This is the main
> concern we are trying to address. Other gateway's (E.G. 
> Residential) will
> detect signals that will eventually lead to a timeout of the MGC and
> connection re-establishment taking place.
> 
> Two Possible Proposals (there maybe others)
> 
> 1. Heartbeat Message
> 
> I believe a package has been proposed where the MG heartbeats the MGC
> (signal on root). I have not seen any proposal nor do I know 
> of the status
> of such a proposal. Perhaps someone (Brian) could comment on this.
> 
> 2. Using Service Change Message
> 
> I have not seen this proposal, but cannot see why it would not work.
> 
> Upon startup of the MGC, a UDP SC message could be sent to 
> each MG with the
> ServiceChangeMgcId set to the MGC IP address. To the MG, this 
> message will
> look like a handover of the MGC to itself. 
> 
> Note this message is not a connection request, just a message 
> to inform the
> MG to re-establish new MGC connections.
> 
> 
> 
> The first option is preferred (but none standard) as it caters for the
> problem where the MGC goes down and stays down.
> 
> 
> Regards
> Bill Groom
> Siemens
> 
> -----Original Message-----
> From: Dan Elbert [mailto:DElbert@radvision.com]
> Sent: Thursday, April 26, 2001 5:06 PM
> To: 'megaco@fore.com'
> Subject: MGC failure
> 
> 
> Assume that the MGC goes down and up again.
> Is there any way for the MGC to indicate the MGs that they 
> need to send a
> SVC, or is only the MGs responsibility to have some sort or 
> "keep alive"
> (e.g. by sending a noop SVC if nothing is coming from the MGC 
> in a long
> time). ?
> Note that the MGC doesn't know what port the MG is using.
> Related to this, what is the standard response if the MGC 
> receives a Notify
> from an MG that is not registered ? ( Because it was 
> registered and then MGC
> went down and up again) . Should it send a reply with an 
> error so the MG
> knows that it must send a SVC, or just ignore it ?
> 
> Thanks,
> Dan Elbert
> RADVISION
> 


From owner-megaco@fore.com  Fri May  4 14:24:51 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18517
	for ; Fri, 4 May 2001 14:24:51 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA06837;
	Fri, 4 May 2001 14:23:55 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA27801
	for megaco-list; Fri, 4 May 2001 14:22:28 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA27787
	for ; Fri, 4 May 2001 14:22:25 -0400 (EDT)
Received: from mail.mediatrix.com (mail.mediatrix.com [205.237.248.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA06636
	for ; Fri, 4 May 2001 14:22:21 -0400 (EDT)
Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 4 May 2001 14:18:34 -0400
Message-ID: 
From: Jean-Francois Lepine 
To: =?iso-8859-1?Q?Fran=E7ois_Berard?= ,
        Megaco Mailing List ,
        Olivier Larouche
	 ,
        Paul Lemay , Steven Weisz 
Subject: Root Termination Events
Date: Fri, 4 May 2001 14:18:23 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.pit.comms.marconi.com id OAA27790
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id OAA06837
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA18517

Hello,

In a media gateway context where all semi-permanent terminations are of the
same type (e.g. analog line), is it right to request analog line events at
the Root Termination rather than at each and every temination (e.g. off-hook
detect).

Jean-François Lépine
Mediatrix Telecom, Inc.



From owner-megaco@fore.com  Sat May  5 08:07:53 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13732
	for ; Sat, 5 May 2001 08:07:52 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA24931;
	Sat, 5 May 2001 08:07:03 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA25996
	for megaco-list; Sat, 5 May 2001 08:04:45 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA25982
	for ; Sat, 5 May 2001 08:04:43 -0400 (EDT)
From: gyj6@prth1.webace.com.au
Received: from prth1.webace.com.au ([203.101.45.5])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA24793
	for ; Sat, 5 May 2001 08:04:35 -0400 (EDT)
Received: from prth1.webace.com.au (TNTPool155.vegasnet.net [208.147.127.155])
	by prth1.webace.com.au (8.8.8/8.8.8) with SMTP id UAA03515;
	Sat, 5 May 2001 20:05:26 +0800 (WST)
	(envelope-from gyj6)
Message-Id: <200105051205.UAA03515@prth1.webace.com.au>
Received: from sorley2@minster.ca by judso@sesto.ca (8.8.5/8.6.5) with SMTP id GAA07603 for ; Sat, 05 May 2001 03:39:13 -0600 (EST)
To: judso.sesto.ca@prth1.webace.com.au
Date: Sat, 05 May 01 03:39:13 EST
Subject: hi
Reply-To: judso@sesto.ca
Comments: Authenticated sender is 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Like to gamble?  Then come to the number 1 rated online casino
on the Interenet!  This is the casino that you saw on CNN that
directly challenged Las Vegas!

Play for fun or play for money.  Free $20 in chips with
your initial deposit.

http://63.167.32.245/members8/acesup/download.html


To be removed go to:  http://www.websurfking.net/homewealth/remove.html



From owner-megaco@fore.com  Sun May  6 11:29:02 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11688
	for ; Sun, 6 May 2001 11:29:02 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22518;
	Sun, 6 May 2001 11:28:13 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA23891
	for megaco-list; Sun, 6 May 2001 11:22:40 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23887
	for ; Sun, 6 May 2001 11:22:38 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id LAA22367
	for ; Sun, 6 May 2001 11:22:36 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id LAA14374; Sun, 6 May 2001 11:22:19 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Sun, 6 May 2001 11:22:21 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Sun, 6 May 2001 11:22:23 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CAB3@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Jean-Francois Lepine'" ,
        =?iso-8859-1?Q?Fran=E7ois_Berard?= ,
        Megaco Mailing List ,
        Olivier Larouche ,
        Paul Lemay , Steven Weisz 
Subject: RE: Root Termination Events
Date: Sun, 6 May 2001 11:22:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D640.5831E5D0"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D640.5831E5D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

No, events relate to specific terminations.  You can use wildcarding to
address all terminations at once, if you need to.

> -----Original Message-----
> From: Jean-Francois Lepine [mailto:jflepine@mediatrix.com]
> Sent: Friday, May 04, 2001 2:18 PM
> To: Fran=E7ois Berard; Megaco Mailing List; Olivier Larouche;=20
> Paul Lemay;
> Steven Weisz
> Subject: Root Termination Events
>=20
>=20
> Hello,
>=20
> In a media gateway context where all semi-permanent=20
> terminations are of the
> same type (e.g. analog line), is it right to request analog=20
> line events at
> the Root Termination rather than at each and every temination=20
> (e.g. off-hook
> detect).
>=20
> Jean-Fran=E7ois L=E9pine
> Mediatrix Telecom, Inc.
>=20
>=20

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






RE: Root Termination Events




No, events relate to specific terminations.  You =
can use wildcarding to address all terminations at once, if you need =
to.



> -----Original Message-----

> From: Jean-Francois Lepine [mailto:jflepine@mediatrix.com=
]

> Sent: Friday, May 04, 2001 2:18 PM

> To: Fran=E7ois Berard; Megaco Mailing List; =
Olivier Larouche; 

> Paul Lemay;

> Steven Weisz

> Subject: Root Termination Events

> 

> 

> Hello,

> 

> In a media gateway context where all =
semi-permanent 

> terminations are of the

> same type (e.g. analog line), is it right to =
request analog 

> line events at

> the Root Termination rather than at each and =
every temination 

> (e.g. off-hook

> detect).

> 

> Jean-Fran=E7ois L=E9pine

> Mediatrix Telecom, Inc.

> 

> 





------_=_NextPart_001_01C0D640.5831E5D0--


From owner-megaco@fore.com  Sun May  6 21:11:22 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15661
	for ; Sun, 6 May 2001 21:11:22 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA02693;
	Sun, 6 May 2001 21:10:35 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA12040
	for megaco-list; Sun, 6 May 2001 21:08:40 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA12036
	for ; Sun, 6 May 2001 21:08:38 -0400 (EDT)
Received: from texlog2.texas.rr.com ([24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA02590
	for ; Sun, 6 May 2001 21:08:35 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f47183dQ027434
	for ; Sun, 6 May 2001 20:08:34 -0500 (CDT)
From: "Paul Long" 
To: 
Subject: ALF?
Date: Sun, 6 May 2001 20:08:36 -0500
Message-ID: 
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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

I was thinking that the "ALF" part of "UDP/ALF" referred to a specific
protocol, e.g., a simple retransmission protocol, or some kind of
standardized framing, e.g., TPKT; however, it seems to be just a loose
concept and not embodied in a separate RFC or somesuch. Is this correct? Is
there a distinction being made between UDP and UDP/ALF? My best guess is
that, in Megaco/H.248, ALF is just the retransmission scheme described in
Annex D and nothing more, right?

Paul Long
ipDialog, Inc.



From owner-megaco@fore.com  Sun May  6 23:17:35 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18221
	for ; Sun, 6 May 2001 23:17:35 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA04886;
	Sun, 6 May 2001 23:16:44 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA15568
	for megaco-list; Sun, 6 May 2001 23:15:12 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA15564
	for ; Sun, 6 May 2001 23:15:10 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA04686
	for ; Sun, 6 May 2001 23:15:02 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA07332;
	Mon, 7 May 2001 13:14:51 +1000 (EST)
Received: from ericsson.com (7-122.epa.ericsson.se [146.11.7.122])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA17094;
	Mon, 7 May 2001 13:14:48 +1000 (EST)
Message-ID: <3AF5F7BC.ACF24439@ericsson.com>
Date: Mon, 07 May 2001 11:17:48 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Troy Cauble 
CC: "Tulpule, Naren" ,
        "'megaco@fore.com'" 
Subject: Re: MID syntax in Implementors' Guide v5
References:  <3AC928EC.C8A425C4@ericsson.com> <3AE99507.C1CCC195@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day Troy,

I'll update the IG to reflect option 1.

Cheers, Christian

Troy Cauble wrote:
> 
> Christian,
> 
> I prefer Narenda's first option because it puts the critical detail
> in the ABNF syntax, instead of in a comment.
> 
> Also, I'd remove the "; portNumber NOT allowed in MID" comment
> because it's confusing (They are allowed, just not by themselves.)
> and unnecessary  (The syntax provides the needed restriction.).
> 
> -troy
> 
> Christian Groves wrote:
> >
> > G'Day Naren,
> >
> > I'm glad someone commented on this one. Having the mID referenced by
> > servicechange was a quick way of adding the MTP3 address. I don't have a
> > preference for either of your proposals. Any text gurus have a
> > preference?
> >
> > Cheers, Christian
> >
> > "Tulpule, Naren" wrote:
> > >
> > > Hi Christian, list,
> > >   in section 1.29 The ABNF given is:
> > > B.2 ABNF syntax specification
> > > ...
> > > mId                  = ([( domainAddress / domainName )]
> > >         [":" portNumber]) / mtpAddress / deviceName...
> > > serviceChangeAddress = ServiceChangeAddressToken EQUAL mIdVALUE
> > >
> > > It should either be
> > >
> > > B.2 ABNF syntax specification
> > >
> > > ; portNumber NOT allowed in MID
> > > mId                  = (( domainAddress / domainName )
> > >         [":" portNumber]) / mtpAddress / deviceName...
> > > serviceChangeAddress = ServiceChangeAddressToken EQUAL (mId / portNumber)
> > >
> > > OR
> > >
> > > B.2 ABNF syntax specification
> > > ...
> > > ; portNumber allowed in MID
> > > mId                  = (( domainAddress / domainName )
> > >         [":" portNumber]) / mtpAddress / deviceName / portNumber
> > > serviceChangeAddress = ServiceChangeAddressToken EQUAL mId
> > >
> > > We can decide on either one. As it is currently given, a portNumber alone in
> > > MID or ServiceChangeAddress would look like ":12345".
> > > (Besides, the current syntax would allow an empty MID).
> > >
> > > These views are mine alone, not those of Intel, Trillium or Mr Barrett.
> > > -- Naren
> > > Narendra C. Tulpule         310-442-9222
> > > SMTS, Trillium (an Intel company)
> > > 12100 Wislshire Bl #1800 Los Angeles CA 90025




From owner-megaco@fore.com  Sun May  6 23:17:40 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18231
	for ; Sun, 6 May 2001 23:17:40 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA04904;
	Sun, 6 May 2001 23:16:50 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA15589
	for megaco-list; Sun, 6 May 2001 23:15:30 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA15585
	for ; Sun, 6 May 2001 23:15:28 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA04710
	for ; Sun, 6 May 2001 23:15:23 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA07346;
	Mon, 7 May 2001 13:14:55 +1000 (EST)
Received: from ericsson.com (7-122.epa.ericsson.se [146.11.7.122])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA17116;
	Mon, 7 May 2001 13:14:54 +1000 (EST)
Message-ID: <3AF5FAAA.7CC8F912@ericsson.com>
Date: Mon, 07 May 2001 11:30:18 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" 
CC: "'Paul Long'" , megaco@fore.com
Subject: Re: Wherefore out thou Error Descriptor?
References: <4FBEA8857476D311A03300204840E1CF01A6F4D3@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day Brian, Paul,

..snip..
> >So I guess the more general rule is that an error
> > descriptor should be
> > returned at the "lowest level" that is semantically
> > appropriate for that
> > particular error and that is possible given any parsing
> > problems with the
> > original request. I know that each of us should be able to
> > understand at
> > which level an error descriptor should be returned, but it
> > would be very
> > helpful if this information was agreed upon and present in the
> > RFC/Recommendation.
> I agree

Any takers for documenting this? It seems a quite a bit of work and
probably would need quite thourough review. I don't have time to draft
this as I'm finalising the IG this week for submission for approval in
SG16.

Regards, Christian




From owner-megaco@fore.com  Sun May  6 23:18:36 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18244
	for ; Sun, 6 May 2001 23:18:35 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA05082;
	Sun, 6 May 2001 23:17:45 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA15634
	for megaco-list; Sun, 6 May 2001 23:16:36 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA15628
	for ; Sun, 6 May 2001 23:16:35 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA04831
	for ; Sun, 6 May 2001 23:16:31 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA07382;
	Mon, 7 May 2001 13:15:09 +1000 (EST)
Received: from ericsson.com (7-122.epa.ericsson.se [146.11.7.122])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA17305;
	Mon, 7 May 2001 13:15:08 +1000 (EST)
Message-ID: <3AF60A93.A49A1AD1@ericsson.com>
Date: Mon, 07 May 2001 12:38:11 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Long 
CC: megaco ietf 
Subject: Re: ALF?
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day Paul,

ALF is small furry alien.... (sorry I couldn't help myself).

Application Layer Framing as you say is not a protocol. Its use in
Megaco/H.248 came out of IETF meeting in 99. Some parties were arguing
for separation between H.248/Megaco and its transports other were
arguing a tighter coupling. ALF is the later. Brian is the expert on
this.

Cheers, Christian

Paul Long wrote:
> 
> I was thinking that the "ALF" part of "UDP/ALF" referred to a specific
> protocol, e.g., a simple retransmission protocol, or some kind of
> standardized framing, e.g., TPKT; however, it seems to be just a loose
> concept and not embodied in a separate RFC or somesuch. Is this correct? Is
> there a distinction being made between UDP and UDP/ALF? My best guess is
> that, in Megaco/H.248, ALF is just the retransmission scheme described in
> Annex D and nothing more, right?
> 
> Paul Long
> ipDialog, Inc.




From owner-megaco@fore.com  Sun May  6 23:18:56 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18255
	for ; Sun, 6 May 2001 23:18:56 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA05121;
	Sun, 6 May 2001 23:18:01 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA15623
	for megaco-list; Sun, 6 May 2001 23:16:27 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA15619
	for ; Sun, 6 May 2001 23:16:26 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA04801
	for ; Sun, 6 May 2001 23:16:21 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA07354;
	Mon, 7 May 2001 13:14:59 +1000 (EST)
Received: from ericsson.com (7-122.epa.ericsson.se [146.11.7.122])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA17166;
	Mon, 7 May 2001 13:14:57 +1000 (EST)
Message-ID: <3AF5FBB1.B665ECA5@ericsson.com>
Date: Mon, 07 May 2001 11:34:41 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Brian C. Wiles" 
CC: megaco ietf 
Subject: Re: RFC 3015 Errors
References: <5.1.0.14.2.20010421113638.00aa7a08@pop.valueweb.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day Brian,

Points 1 and 2 are already covered by the H.248/Megaco implementors'
Guide. With regards to point 3 these may be addressed in a future
RFC/recommendation currently the best think to look at would be H.225
(from memory) where this was copied from.

Cheers, Christian

"Brian C. Wiles" wrote:
> 
>    Forgive me if this has already been addressed because the list archive
> ends at February.  I've noticed that the ASN.1 description in RFC 3015 has
> at least a few missing lines and at least one ambiguity.
> 
>    1.)  The top line of the definition for the IP4Address on Page 84 is
> missing, but its contents are defined:
> 
>          Currently, it reads:
> 
> {
>    address         OCTET STRING (SIZE(4)),
>    portNumber      INTEGER(0..65535) OPTIONAL
> }
> 
>          I believe it should read:
> 
> IP4Address ::= SEQUENCE
> {
>    address         OCTET STRING (SIZE(4)),
>    portNumber      INTEGER(0..65535) OPTIONAL
> }
> 
>    2.)  The definition for ServiceChangeParm on Page 97 seems to be missing
> a "..." extension marker.
> 
>    3.)  The H221NonStandard structure on Page 98 contains a t35CountryCode1
> and t35CountryCode2 in addition to the t35Extension.  Isn't there supposed
> to be only one CountryCode byte plus the Extension?  If all 3 are intended,
> what should the values be for a company in the US (Country Code B500)?
> 
>    Shouldn't these be addressed in a future RFC to ensure manufacturers are
> compatible?  Or, am I completely off base here? :)  Thanks.
>          -Brian
> 
> ---
> Brian C. Wiles
> Chief Executive Officer
> StreamComm
> +1 (916) 501-4349
> http://www.streamcomm.com




From owner-megaco@fore.com  Sun May  6 23:49:41 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18883
	for ; Sun, 6 May 2001 23:49:40 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA06139;
	Sun, 6 May 2001 23:48:37 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA17059
	for megaco-list; Sun, 6 May 2001 23:47:43 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA17055
	for ; Sun, 6 May 2001 23:47:42 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA06060
	for ; Sun, 6 May 2001 23:47:34 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA10507
	for ; Mon, 7 May 2001 13:46:12 +1000 (EST)
Received: from ericsson.com (7-122.epa.ericsson.se [146.11.7.122])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA23797
	for ; Mon, 7 May 2001 13:46:12 +1000 (EST)
Message-ID: <3AF61A8F.2A7F033E@ericsson.com>
Date: Mon, 07 May 2001 13:46:23 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco ietf 
Subject: Notifies on a Termination / IG sect. 6.22
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day all,

The IG chapter 6.22  removed the recommendation "On a given Termination,
there should normally be at most one outstanding Notify command at any
time" from H.248 chapter 9.1. However the chapter states "This document
does not mandate that the underlying
transport protocol guarantees the sequencing of transactions sent to an
entity.  This property tends to maximize the timeliness of actions, but
it has a few drawbacks. 
For example:"

I can't remember the discussion around this. It seems to me that UDP
will still have a problem with sequencing and this isn't covered
anywhere in the document. Can someone explain why this isn't a problem?

Otherwise i'll make an update to Annex D or 9.1 stating the exception
for UDP transports.

Cheers, Christian


From owner-megaco@fore.com  Mon May  7 00:49:49 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19348
	for ; Mon, 7 May 2001 00:49:49 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA07665;
	Mon, 7 May 2001 00:49:00 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA19907
	for megaco-list; Mon, 7 May 2001 00:48:11 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA19903
	for ; Mon, 7 May 2001 00:48:09 -0400 (EDT)
Received: from brahma01.netbrahma.com ([164.164.70.67])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA07590
	for ; Mon, 7 May 2001 00:48:04 -0400 (EDT)
Received: from netbrahma.com (172.16.72.98 [172.16.72.98]) by brahma01.netbrahma.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id KJ84QJFM; Mon, 7 May 2001 10:18:03 +0530
Message-ID: <3AF62A90.6F1BE05E@netbrahma.com>
Date: Mon, 07 May 2001 10:24:40 +0530
From: Atanu Mondal 
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-6.1.1 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Groves , megaco@fore.com
Subject: Re: RFC 3015 Errors
References: <5.1.0.14.2.20010421113638.00aa7a08@pop.valueweb.net> <3AF5FBB1.B665ECA5@ericsson.com>
Content-Type: multipart/alternative;
 boundary="------------6E1BED1AE629D43B3461519E"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------6E1BED1AE629D43B3461519E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Can anybody tell me where this H.248/Megaco Implementor's guide is available ?

Regards
Atanu


Christian Groves wrote:

> G'Day Brian,
>
> Points 1 and 2 are already covered by the H.248/Megaco implementors'
> Guide. With regards to point 3 these may be addressed in a future
> RFC/recommendation currently the best think to look at would be H.225
> (from memory) where this was copied from.
>

--------------6E1BED1AE629D43B3461519E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Can anybody tell me where this H.248/Megaco Implementor's guide is available
?

Regards

Atanu

 

Christian Groves wrote:

G'Day Brian,

Points 1 and 2 are already covered by the H.248/Megaco implementors'

Guide. With regards to point 3 these may be addressed in a future

RFC/recommendation currently the best think to look at would be H.225

(from memory) where this was copied from.

 



--------------6E1BED1AE629D43B3461519E--



From owner-megaco@fore.com  Mon May  7 09:04:58 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10005
	for ; Mon, 7 May 2001 09:04:58 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA22607;
	Mon, 7 May 2001 08:59:06 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA27333
	for megaco-list; Mon, 7 May 2001 08:54:40 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA27318
	for ; Mon, 7 May 2001 08:54:38 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA22148
	for ; Mon, 7 May 2001 08:54:38 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACD28107;
	Mon, 7 May 2001 08:54:26 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Atanu Mondal'" ,
        "'Christian Groves'" ,
        
Subject: RE: RFC 3015 Errors
Date: Mon, 7 May 2001 08:59:25 -0400
Message-ID: <010d01c0d6f5$8c522860$c500a8c0@MBRAHMANAPALLY>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_010E_01C0D6D4.05408860"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <3AF62A90.6F1BE05E@netbrahma.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

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

Atanu,

ftp://standards.nortelnetworks.com/megaco/docs/Approved/
is the location from which I got the IG.
Regards
Madhubabu
  -----Original Message-----
  From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Atanu Mondal
  Sent: Monday, May 07, 2001 12:55 AM
  To: Christian Groves; megaco@fore.com
  Subject: Re: RFC 3015 Errors


  Can anybody tell me where this H.248/Megaco Implementor's guide is
available ?
  Regards
  Atanu


  Christian Groves wrote:

    G'Day Brian,
    Points 1 and 2 are already covered by the H.248/Megaco implementors'
    Guide. With regards to point 3 these may be addressed in a future
    RFC/recommendation currently the best think to look at would be H.225
    (from memory) where this was copied from.



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









Atanu,


 


ftp://s=
tandards.nortelnetworks.com/megaco/docs/Approved/


is the=20
location from which I got the IG.


Regards


Madhubabu



  
-----Original Message-----
From:=20
  owner-megaco@pit.comms.marconi.com=20
  [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Atanu=20
  Mondal
Sent: Monday, May 07, 2001 12:55 AM
To: =
Christian=20
  Groves; megaco@fore.com
Subject: Re: RFC 3015=20
  Errors

Can anybody tell me where this H.248/Megaco =

  Implementor's guide is available ?=20
  
Regards 
Atanu 
 =20
  
Christian Groves wrote:=20
  
G'Day Brian,=20
    
Points 1 and 2 are already covered by the H.248/Megaco =
implementors'=20
    
Guide. With regards to point 3 these may be addressed in a =
future=20
    
RFC/recommendation currently the best think to look at would be =
H.225=20
    
(from memory) where this was copied from. 
 


------=_NextPart_000_010E_01C0D6D4.05408860--



From owner-megaco@fore.com  Mon May  7 09:23:51 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10728
	for ; Mon, 7 May 2001 09:23:50 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA24122;
	Mon, 7 May 2001 09:15:23 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA01321
	for megaco-list; Mon, 7 May 2001 09:11:54 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA01271
	for ; Mon, 7 May 2001 09:11:41 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 7 May 2001 09:11:26 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F573@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Christian Groves'" ,
        megaco ietf
	 
Subject: RE: Notifies on a Termination / IG sect. 6.22
Date: Mon, 7 May 2001 09:11:40 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Christian

Do you have notes about why the recommendation from the chapter?
I don't remember it.  Timestamps do let you order Notifies of course.
but I seem to recall that there is another problem, although I
can't dredge up the actual problem out of my leaky brain.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Sunday, May 06, 2001 11:46 PM
> To: megaco ietf
> Subject: Notifies on a Termination / IG sect. 6.22
> 
> 
> G'Day all,
> 
> The IG chapter 6.22  removed the recommendation "On a given 
> Termination,
> there should normally be at most one outstanding Notify command at any
> time" from H.248 chapter 9.1. However the chapter states 
> "This document
> does not mandate that the underlying
> transport protocol guarantees the sequencing of transactions 
> sent to an
> entity.  This property tends to maximize the timeliness of 
> actions, but
> it has a few drawbacks. 
> For example:"
> 
> I can't remember the discussion around this. It seems to me that UDP
> will still have a problem with sequencing and this isn't covered
> anywhere in the document. Can someone explain why this isn't 
> a problem?
> 
> Otherwise i'll make an update to Annex D or 9.1 stating the exception
> for UDP transports.
> 
> Cheers, Christian
> 


From owner-megaco@fore.com  Mon May  7 09:26:55 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10846
	for ; Mon, 7 May 2001 09:26:50 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA23811;
	Mon, 7 May 2001 09:13:33 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA00399
	for megaco-list; Mon, 7 May 2001 09:08:45 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA00393
	for ; Mon, 7 May 2001 09:08:44 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 7 May 2001 09:08:30 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F572@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Paul Long'" , megaco@fore.com
Subject: RE: ALF?
Date: Mon, 7 May 2001 09:08:44 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

ALF is a set of techniques that allow an application, as opposed 
to a stack, affect how messages are sent to the other side.  
A typical ALF technique is to allow an application to change the 
order of messages sent when there is a queue AFTER it has queued 
them.  There is no spec.

You can JUST follow the procedures in Annex D, and nothing more,
or you can do some other things that might improve performance for
a particular application, but you can't do something that violates
the protocol specification.

Brian

> -----Original Message-----
> From: Paul Long [mailto:plong@ipdialog.com]
> Sent: Sunday, May 06, 2001 9:09 PM
> To: megaco@fore.com
> Subject: ALF?
> 
> 
> I was thinking that the "ALF" part of "UDP/ALF" referred to a specific
> protocol, e.g., a simple retransmission protocol, or some kind of
> standardized framing, e.g., TPKT; however, it seems to be just a loose
> concept and not embodied in a separate RFC or somesuch. Is 
> this correct? Is
> there a distinction being made between UDP and UDP/ALF? My 
> best guess is
> that, in Megaco/H.248, ALF is just the retransmission scheme 
> described in
> Annex D and nothing more, right?
> 
> Paul Long
> ipDialog, Inc.
> 


From owner-megaco@fore.com  Mon May  7 10:34:01 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13154
	for ; Mon, 7 May 2001 10:34:01 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA28028;
	Mon, 7 May 2001 10:21:02 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA14338
	for megaco-list; Mon, 7 May 2001 10:17:11 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14330
	for ; Mon, 7 May 2001 10:17:08 -0400 (EDT)
Received: from pine.cyberpathinc.com ([38.246.253.128])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA27845
	for ; Mon, 7 May 2001 10:17:08 -0400 (EDT)
Received: from YSHA (ysha [172.30.30.41])
	by pine.cyberpathinc.com (8.9.3+Sun/8.9.3) with SMTP id KAA08955
	for ; Mon, 7 May 2001 10:19:27 -0400 (EDT)
Received: by YSHA with Microsoft Mail
	id <01C0D6DE.E534CB20@YSHA>; Mon, 7 May 2001 10:17:18 -0400
Message-ID: <01C0D6DE.E534CB20@YSHA>
From: YouLing Sha 
To: "'megaco@fore.com'" 
Subject: MGC
Date: Mon, 7 May 2001 10:17:17 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.pit.comms.marconi.com id KAA14331
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi,

We are a Voice Gateway vendor and currently implementing Megaco MG in our Gateway. We are looking for either MGC simulators or a real MGC to test our MG, and MGC partnership for business development. Please respond to ysha@cyberpathinc.com if you are interested.
Thanks.

Regards,
YouLing Sha
CyberPath Inc.
(732) 463-7700 ext. 304
ysha@cyberpathinc.com



From owner-megaco@fore.com  Mon May  7 13:13:55 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16977
	for ; Mon, 7 May 2001 13:13:54 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA11988;
	Mon, 7 May 2001 13:12:22 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA22476
	for megaco-list; Mon, 7 May 2001 13:08:33 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA22464
	for ; Mon, 7 May 2001 13:08:32 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id NAA11590
	for ; Mon, 7 May 2001 13:08:31 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id NAA08794; Mon, 7 May 2001 13:08:28 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Mon, 7 May 2001 13:08:18 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Mon, 7 May 2001 13:08:22 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CAC5@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Christian Groves'" ,
        Troy Cauble 
Cc: Terry L Anderson ,
        "Rosen, Brian" ,
        "'Bemmel, Jeroen van (Jeroen)'" ,
        "'megaco@fore.com'" 
Subject: RE: Relationship Annex C values <=> package Property ID's
Date: Mon, 7 May 2001 13:08:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D718.4F7AD1D0"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D718.4F7AD1D0
Content-Type: text/plain;
	charset="iso-8859-1"

One way or another, we have an open issue here.  On the basis of your
position, we have to identify which descriptor(s) each element of Annex C
can appear in.  I will volunteer to create a contribution for the SG 16
meeting, to be added to the Implementor's Guide, unless someone else wants
to do it.

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Friday, May 04, 2001 12:20 AM
> To: Troy Cauble
> Cc: Terry L Anderson; Rosen, Brian; Taylor, Tom-PT [NORSE:B881:EXCH];
> 'Bemmel, Jeroen van (Jeroen)'; 'megaco@fore.com'
> Subject: Re: Relationship Annex C values <=> package Property ID's
> 
> 
> Annex C can be extended by people making contributions and adding new
> parameters. New versions of Annex C can be worked upon if people want
> new information elements. 
> 
> I'd prefer not to revisit a discussions that we had 1999 on the use of
> native tags, SDP etc. We chose to have 2 different schemes. Being 2
> different encodings schemes there will always be differences 
> as SDP has
> a life of its own as well as Annex C. Both SDP and Annex C are buckets
> for information elements. You pick and choose to use the ones 
> you want.
> 
> Technically a package could extend annex C because all 
> properties in the
> binary version of H.248 take the form of 
> package:property=value. Annex C
> is package 0. Termination State, Local Control, Local and Remote all
> have this encoding in the binary version. Which I think is 
> rather handy. 
> 
> I never did see why in the text encoding why local control, 
> termination
> state, local and remote must be coded differently. We have 
> what we have.
> 
> Christian
> 
> Troy Cauble wrote:
> > 
> > Terry L Anderson wrote:
> > >
> > > Troy Cauble wrote:
> > >
> > > >
> > > > Section C.11 is a line by line SDP replacement.  Some 
> of the other
> > > > Annex C
> > > > items seem to be alternative encodings of information 
> that could be
> > > > encoded
> > > > as SDP.
> > > >
> > > > IMHO, if any Annex C items don't have corresponding SDP 
> elements, they
> > > >
> > > > should be removed.  It is fundamentally wrong to have 
> features that
> > > > are only
> > > > accessible to the ASN.1 encoding of the protocol.  We should be
> > > > striving
> > > > for uniformity.
> > >
> > > They should agree, but this can be fixed as you suggest 
> (remove Annex C
> > > item) or by ADDing SDP.  Many can be added through 'a=' 
> attributes in
> > > SDP and RFCs can add these as was suggested in
> > > draft-ietf-mmusics-sdp-atm-05 or recent 
> draft-taylor-mmusic-sdptdm-00
> > > do.  Many of these in Annex C and not yet in SDP are vital for
> > > configuring specific termination types.  These could be 
> added through
> > > packages to LocalControl but this makes it more difficult 
> for them to be
> > > media specific.  SDP allows the parameter to apply to 
> only specific
> > > choices of the multiple proposed media.
> > >
> > > Removing them would seriously affect backward compatibility and so
> > > probably not possible.
> > 
> > I had forgotten that the things in the Local and Remote Descriptors
> > are not Properties.  Packages won't work here.
> > 
> > So for LD & RD non-properties in Annex C that are not yet in SDP,
> > people will have a choice between using ASN.1 encoding only or
> > influencing the evolution of SDP.
> > 
> > Consider the reverse direction.  How will new items that come out
> > of the evolution of SDP make it into Annex C for ASN.1 encoding?
> > Do we need a formal mechanism (like Packages) to extend Annex C?
> > 
> > On the other hand, the IG ammended the intro to Annex C to
> > say that (some of?) the Annex C non-properties apply to the
> > LocalControlDescriptor.  (But nothing tells us which ones.)
> > 
> > I would argue that any Annex C items that apply to the LCD
> > *ARE* Properties, and should be removed from Annex C and moved
> > to Packages.  Otherwise how will they be encoded as text?
> > 
> > -troy
> > 
> > > >
> > > >
> > > > People who need the non-SDP supported features 
> currently in Annex C
> > > > should be developing Packages, rather than going with 
> an ASN.1 only
> > > > solution.
> > > >
> > > > Can we seek out  and remove non-SDP supported features 
> in Annex C?
> > > >
> > > > -troy
> > > >
> > > >
> 

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






RE: Relationship Annex C values <=3D> package Property =
ID's




One way or another, we have an open issue here.  =
On the basis of your position, we have to identify which descriptor(s) =
each element of Annex C can appear in.  I will volunteer to create =
a contribution for the SG 16 meeting, to be added to the Implementor's =
Guide, unless someone else wants to do it.



> -----Original Message-----

> From: Christian Groves [mailto:Christian.Groves@er=
icsson.com]

> Sent: Friday, May 04, 2001 12:20 AM

> To: Troy Cauble

> Cc: Terry L Anderson; Rosen, Brian; Taylor, =
Tom-PT [NORSE:B881:EXCH];

> 'Bemmel, Jeroen van (Jeroen)'; =
'megaco@fore.com'

> Subject: Re: Relationship Annex C values =
<=3D> package Property ID's

> 

> 

> Annex C can be extended by people making =
contributions and adding new

> parameters. New versions of Annex C can be =
worked upon if people want

> new information elements. 

> 

> I'd prefer not to revisit a discussions that we =
had 1999 on the use of

> native tags, SDP etc. We chose to have 2 =
different schemes. Being 2

> different encodings schemes there will always =
be differences 

> as SDP has

> a life of its own as well as Annex C. Both SDP =
and Annex C are buckets

> for information elements. You pick and choose =
to use the ones 

> you want.

> 

> Technically a package could extend annex C =
because all 

> properties in the

> binary version of H.248 take the form of =


> package:property=3Dvalue. Annex C

> is package 0. Termination State, Local Control, =
Local and Remote all

> have this encoding in the binary version. Which =
I think is 

> rather handy. 

> 

> I never did see why in the text encoding why =
local control, 

> termination

> state, local and remote must be coded =
differently. We have 

> what we have.

> 

> Christian

> 

> Troy Cauble wrote:

> > 

> > Terry L Anderson wrote:

> > >

> > > Troy Cauble wrote:

> > >

> > > >

> > > > Section C.11 is a line by line =
SDP replacement.  Some 

> of the other

> > > > Annex C

> > > > items seem to be alternative =
encodings of information 

> that could be

> > > > encoded

> > > > as SDP.

> > > >

> > > > IMHO, if any Annex C items don't =
have corresponding SDP 

> elements, they

> > > >

> > > > should be removed.  It is =
fundamentally wrong to have 

> features that

> > > > are only

> > > > accessible to the ASN.1 encoding =
of the protocol.  We should be

> > > > striving

> > > > for uniformity.

> > >

> > > They should agree, but this can be =
fixed as you suggest 

> (remove Annex C

> > > item) or by ADDing SDP.  Many =
can be added through 'a=3D' 

> attributes in

> > > SDP and RFCs can add these as was =
suggested in

> > > draft-ietf-mmusics-sdp-atm-05 or =
recent 

> draft-taylor-mmusic-sdptdm-00

> > > do.  Many of these in Annex C =
and not yet in SDP are vital for

> > > configuring specific termination =
types.  These could be 

> added through

> > > packages to LocalControl but this =
makes it more difficult 

> for them to be

> > > media specific.  SDP allows the =
parameter to apply to 

> only specific

> > > choices of the multiple proposed =
media.

> > >

> > > Removing them would seriously affect =
backward compatibility and so

> > > probably not possible.

> > 

> > I had forgotten that the things in the =
Local and Remote Descriptors

> > are not Properties.  Packages won't =
work here.

> > 

> > So for LD & RD non-properties in Annex =
C that are not yet in SDP,

> > people will have a choice between using =
ASN.1 encoding only or

> > influencing the evolution of SDP.

> > 

> > Consider the reverse direction.  How =
will new items that come out

> > of the evolution of SDP make it into Annex =
C for ASN.1 encoding?

> > Do we need a formal mechanism (like =
Packages) to extend Annex C?

> > 

> > On the other hand, the IG ammended the =
intro to Annex C to

> > say that (some of?) the Annex C =
non-properties apply to the

> > LocalControlDescriptor.  (But nothing =
tells us which ones.)

> > 

> > I would argue that any Annex C items that =
apply to the LCD

> > *ARE* Properties, and should be removed =
from Annex C and moved

> > to Packages.  Otherwise how will they =
be encoded as text?

> > 

> > -troy

> > 

> > > >

> > > >

> > > > People who need the non-SDP =
supported features 

> currently in Annex C

> > > > should be developing Packages, =
rather than going with 

> an ASN.1 only

> > > > solution.

> > > >

> > > > Can we seek out  and remove =
non-SDP supported features 

> in Annex C?

> > > >

> > > > -troy

> > > >

> > > >

> 





------_=_NextPart_001_01C0D718.4F7AD1D0--


From owner-megaco@fore.com  Mon May  7 17:22:57 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22645
	for ; Mon, 7 May 2001 17:22:57 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA04050;
	Mon, 7 May 2001 17:15:42 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA20676
	for megaco-list; Mon, 7 May 2001 17:14:36 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA20657
	for ; Mon, 7 May 2001 17:14:30 -0400 (EDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA03905
	for ; Mon, 7 May 2001 17:14:28 -0400 (EDT)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA26799
	for ; Mon, 7 May 2001 16:14:29 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f47LEST25422
	for ; Mon, 7 May 2001 16:14:28 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f47LDY129418
	for ; Mon, 7 May 2001 16:13:34 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f47LDYO19325
	for ; Mon, 7 May 2001 16:13:34 -0500 (CDT)
Message-ID: <3AF70FFE.65526F6A@usa.alcatel.com>
Date: Mon, 07 May 2001 16:13:34 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "'megaco@fore.com'" 
Subject: IP Type of Service
Content-Type: multipart/alternative;
 boundary="------------3BAC47484823B19A7CA750DC"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------3BAC47484823B19A7CA750DC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All

In MGCP, MGC can specify IP Type of Service to the MG.
Do we have an equivalent in Megaco?

Is there or has anyone defined a package for IP Type of Service?

Thanks
Chuong

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------3BAC47484823B19A7CA750DC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



All

In MGCP, MGC can specify IP Type of Service to the MG.

Do we have an equivalent in Megaco?

Is there or has anyone defined a package for IP Type of Service?

Thanks

Chuong

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------3BAC47484823B19A7CA750DC--



From owner-megaco@fore.com  Mon May  7 21:21:48 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25964
	for ; Mon, 7 May 2001 21:21:47 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA14449;
	Mon, 7 May 2001 21:16:01 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA13930
	for megaco-list; Mon, 7 May 2001 21:14:37 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA13926
	for ; Mon, 7 May 2001 21:14:36 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id VAA14318
	for ; Mon, 7 May 2001 21:14:34 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id VAA13072; Mon, 7 May 2001 21:14:32 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Mon, 7 May 2001 21:14:31 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Mon, 7 May 2001 21:14:33 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CAD3@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Chuong Nguyen'" ,
        "'megaco@fore.com'" 
Subject: RE: IP Type of Service
Date: Mon, 7 May 2001 21:14:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D75C.3CADA570"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D75C.3CADA570
Content-Type: text/plain;
	charset="iso-8859-1"

No such package has yet been defined.
 
Various QOS architectures can be imagined.  Each would give rise to its own
package, since the MGC-MG information flow would differ from one
architecture to the next.  One question: unless the MG is itself the edge
router, won't the ToS be ignored when the media packets reach the latter?

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Monday, May 07, 2001 5:14 PM
To: 'megaco@fore.com'
Subject: IP Type of Service


All 

In MGCP, MGC can specify IP Type of Service to the MG. 
Do we have an equivalent in Megaco? 


Is there or has anyone defined a package for IP Type of Service? 


Thanks 
Chuong 

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


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









No=20
such package has yet been defined.


 


Various QOS architectures can be =
imagined.  Each=20
would give rise to its own package, since the MGC-MG information flow =
would=20
differ from one architecture to the next.  One question: unless =
the MG is=20
itself the edge router, won't the ToS be ignored when the media packets =
reach=20
the latter?


  
-----Original Message-----
From: Chuong Nguyen=20
  [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Monday, May =
07, 2001=20
  5:14 PM
To: 'megaco@fore.com'
Subject: IP Type of =

  Service

All=20
  
In MGCP, MGC can specify IP Type of Service to the MG. =

Do we=20
  have an equivalent in Megaco?=20
  
Is there or has anyone defined a package for IP Type of =
Service?=20
  
Thanks 
Chuong 
-- 
  Alcatel USA, =
Inc           &nb=
sp; Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas =
75075           =
Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc =
****
 =20



------_=_NextPart_001_01C0D75C.3CADA570--


From owner-megaco@fore.com  Tue May  8 03:26:47 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA16784
	for ; Tue, 8 May 2001 03:26:47 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA24349;
	Tue, 8 May 2001 03:19:04 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id DAA04604
	for megaco-list; Tue, 8 May 2001 03:16:24 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA04600
	for ; Tue, 8 May 2001 03:16:23 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA24250
	for ; Tue, 8 May 2001 03:16:19 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id RAA21084;
	Tue, 8 May 2001 17:15:24 +1000 (EST)
Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id RAA22716;
	Tue, 8 May 2001 17:15:22 +1000 (EST)
Message-ID: <3AF79D07.F23B816A@ericsson.com>
Date: Tue, 08 May 2001 17:15:19 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" 
CC: megaco ietf 
Subject: Re: Notifies on a Termination / IG sect. 6.22
References: <4FBEA8857476D311A03300204840E1CF01A6F573@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day Brian,

I don't have any other notes apart from what's in the description field.
I do see it has desirable behaviour to be able to have multiple notifies
and I agree with the change. The only problem is with UDP and
unsequenced delivery. Ie. you get a digits in a series of notifies. You
definately want them in the right order. Even with timestamps how long
do you have to wait when you receive an event before you can be sure
that you don't get another event with an earlier timestamp? This will
lead to problems.

Cheers, Christian

"Rosen, Brian" wrote:
> 
> Christian
> 
> Do you have notes about why the recommendation from the chapter?
> I don't remember it.  Timestamps do let you order Notifies of course.
> but I seem to recall that there is another problem, although I
> can't dredge up the actual problem out of my leaky brain.
> 
> Brian
> 
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Sunday, May 06, 2001 11:46 PM
> > To: megaco ietf
> > Subject: Notifies on a Termination / IG sect. 6.22
> >
> >
> > G'Day all,
> >
> > The IG chapter 6.22  removed the recommendation "On a given
> > Termination,
> > there should normally be at most one outstanding Notify command at any
> > time" from H.248 chapter 9.1. However the chapter states
> > "This document
> > does not mandate that the underlying
> > transport protocol guarantees the sequencing of transactions
> > sent to an
> > entity.  This property tends to maximize the timeliness of
> > actions, but
> > it has a few drawbacks.
> > For example:"
> >
> > I can't remember the discussion around this. It seems to me that UDP
> > will still have a problem with sequencing and this isn't covered
> > anywhere in the document. Can someone explain why this isn't
> > a problem?
> >
> > Otherwise i'll make an update to Annex D or 9.1 stating the exception
> > for UDP transports.
> >
> > Cheers, Christian
> >


From owner-megaco@fore.com  Tue May  8 07:57:46 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19293
	for ; Tue, 8 May 2001 07:57:45 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA05885;
	Tue, 8 May 2001 07:51:54 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA01968
	for megaco-list; Tue, 8 May 2001 07:50:21 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA01958
	for ; Tue, 8 May 2001 07:50:19 -0400 (EDT)
Received: from mail.bhartitelesoft.com ([202.56.229.147])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA05783
	for ; Tue, 8 May 2001 07:50:12 -0400 (EDT)
Received: from sarju (taquila [202.56.229.146])
	by mail.bhartitelesoft.com (8.11.0/8.11.0) with SMTP id f48BnH524733
	for ; Tue, 8 May 2001 17:19:17 +0530
Message-ID: <007401c0d7b1$84331f60$240310ac@bhartitelesoft.com>
Reply-To: "Sarju Garg" 
From: "Sarju Garg" 
To: "'megaco'" 
Subject: ServiceChange Command
Date: Tue, 8 May 2001 16:53:46 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0071_01C0D7DF.72F7DFA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0071_01C0D7DF.72F7DFA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi List,

I have some doubts related to ServiceChange Command. They are as =
follows:
1. Is ServiceChangeReason mandatory parameter in ServiceChangeCommand ?
2. Is version Negotiation required? I mean should I send =
ServiceChangeVersion in the first message (ServiceChangeMethod=3D =
RESTART ) as meant by first line of Sec 11.3 or I can do without version =
negotiation?

TIA
Sarju

------=_NextPart_000_0071_01C0D7DF.72F7DFA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi List,


 


I have some doubts related to =
ServiceChange=20
Command. They are as follows:


1. Is ServiceChangeReason mandatory =
parameter in=20
ServiceChangeCommand ?


2. Is version Negotiation required? I =
mean should I=20
send ServiceChangeVersion in the first message (ServiceChangeMethod=3D =
RESTART )=20
as meant by first line of Sec 11.3 or I can do without version=20
negotiation?


 


TIA


Sarju


------=_NextPart_000_0071_01C0D7DF.72F7DFA0--



From owner-megaco@fore.com  Tue May  8 08:17:50 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19646
	for ; Tue, 8 May 2001 08:17:49 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA07056;
	Tue, 8 May 2001 08:10:34 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA04475
	for megaco-list; Tue, 8 May 2001 08:09:45 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA04461
	for ; Tue, 8 May 2001 08:09:42 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 8 May 2001 08:09:27 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F58A@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Tom-PT Taylor'" ,
        "'Chuong Nguyen'"
	 ,
        "'megaco@fore.com'" 
Subject: RE: IP Type of Service
Date: Tue, 8 May 2001 08:09:42 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0D7B7.C38ABB90"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D7B7.C38ABB90
Content-Type: text/plain;
	charset="iso-8859-1"

TOS should not be ignored at the edge router if the router is configured to
enable DiffServ.  
 
It would be pretty simple to create one package that had the appropriate
controls for
DiffServ and 802.1p.  RSVP needs it's own package because there is
messaging,
and you at least an event or two
 
The former could be an enumeration: QosMarking, that had values None, TOS
and
FramePriority, plus another integer, Value.  That would suffice I think,
although you
could conceivably get more clever with DiffServ.
 
Shall I write something up along those lines?  
 
RSVP takes some more work.  Any volunteers?
 
Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Monday, May 07, 2001 9:15 PM
To: 'Chuong Nguyen'; 'megaco@fore.com'
Subject: RE: IP Type of Service


No such package has yet been defined.
 
Various QOS architectures can be imagined.  Each would give rise to its own
package, since the MGC-MG information flow would differ from one
architecture to the next.  One question: unless the MG is itself the edge
router, won't the ToS be ignored when the media packets reach the latter?

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Monday, May 07, 2001 5:14 PM
To: 'megaco@fore.com'
Subject: IP Type of Service


All 

In MGCP, MGC can specify IP Type of Service to the MG. 
Do we have an equivalent in Megaco? 


Is there or has anyone defined a package for IP Type of Service? 


Thanks 
Chuong 

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


------_=_NextPart_001_01C0D7B7.C38ABB90
Content-Type: text/html;
	charset="iso-8859-1"









TOS should 
not be ignored at the edge router if the router is configured 
to


enable 
DiffServ.  


 


It would be 
pretty simple to create one package that had the appropriate controls 
for


DiffServ and 
802.1p.  RSVP needs it's own package because there is 
messaging,


and you at 
least an event or two


 


The former 
could be an enumeration: QosMarking, that had values None, TOS 
and


FramePriority, plus another integer, Value.  That 
would suffice I think, although you


could 
conceivably get more clever with DiffServ.


 


Shall I 
write something up along those lines?  


 


RSVP takes 
some more work.  Any volunteers?


 


Brian



  
-----Original Message-----
From: Tom-PT Taylor 
  [mailto:taylor@nortelnetworks.com]
Sent: Monday, May 07, 2001 9:15 
  PM
To: 'Chuong Nguyen'; 'megaco@fore.com'
Subject: RE: IP 
  Type of Service


  
No 
  such package has yet been defined.

  
 

  
Various QOS architectures can be imagined.  Each 
  would give rise to its own package, since the MGC-MG information flow would 
  differ from one architecture to the next.  One question: unless the MG is 
  itself the edge router, won't the ToS be ignored when the media packets reach 
  the latter?

  

    
-----Original Message-----
From: Chuong Nguyen 
    [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Monday, May 07, 2001 
    5:14 PM
To: 'megaco@fore.com'
Subject: IP Type of 
    Service

All 
    
In MGCP, MGC can specify IP Type of Service to the MG. 
Do 
    we have an equivalent in Megaco? 
    
Is there or has anyone defined a package for IP Type of Service? 
    
Thanks 
Chuong 
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  
  


------_=_NextPart_001_01C0D7B7.C38ABB90--


From owner-megaco@fore.com  Tue May  8 09:28:44 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21456
	for ; Tue, 8 May 2001 09:28:44 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA13333;
	Tue, 8 May 2001 09:21:29 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA18101
	for megaco-list; Tue, 8 May 2001 09:19:36 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA18094
	for ; Tue, 8 May 2001 09:19:35 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA13074
	for ; Tue, 8 May 2001 09:19:34 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACE02367;
	Tue, 8 May 2001 09:19:17 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Rosen, Brian'" ,
        "'Tom-PT Taylor'" ,
        "'Chuong Nguyen'" , 
Subject: RE: IP Type of Service
Date: Tue, 8 May 2001 09:24:10 -0400
Message-ID: <013601c0d7c2$2b7ccb80$c500a8c0@MBRAHMANAPALLY>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0137_01C0D7A0.A46B2B80"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <4FBEA8857476D311A03300204840E1CF01A6F58A@whq-msgusr-02.pit.comms.marconi.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0137_01C0D7A0.A46B2B80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi All,

The default TOS type should be defined on the ROOT termination for the
default TOS used for all media packets generated from the MG. There should
be a method (might be through some property) of specifying stream level TOS
bits.

I'm interested to work on RSVP.

Regards
Madhubabu
  -----Original Message-----
  From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
  Sent: Tuesday, May 08, 2001 8:10 AM
  To: 'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco@fore.com'
  Subject: RE: IP Type of Service


  TOS should not be ignored at the edge router if the router is configured
to
  enable DiffServ.

  It would be pretty simple to create one package that had the appropriate
controls for
  DiffServ and 802.1p.  RSVP needs it's own package because there is
messaging,
  and you at least an event or two

  The former could be an enumeration: QosMarking, that had values None, TOS
and
  FramePriority, plus another integer, Value.  That would suffice I think,
although you
  could conceivably get more clever with DiffServ.

  Shall I write something up along those lines?

  RSVP takes some more work.  Any volunteers?

  Brian
    -----Original Message-----
    From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
    Sent: Monday, May 07, 2001 9:15 PM
    To: 'Chuong Nguyen'; 'megaco@fore.com'
    Subject: RE: IP Type of Service


    No such package has yet been defined.

    Various QOS architectures can be imagined.  Each would give rise to its
own package, since the MGC-MG information flow would differ from one
architecture to the next.  One question: unless the MG is itself the edge
router, won't the ToS be ignored when the media packets reach the latter?
      -----Original Message-----
      From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
      Sent: Monday, May 07, 2001 5:14 PM
      To: 'megaco@fore.com'
      Subject: IP Type of Service


      All
      In MGCP, MGC can specify IP Type of Service to the MG.
      Do we have an equivalent in Megaco?

      Is there or has anyone defined a package for IP Type of Service?

      Thanks
      Chuong

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****


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









Hi=20
All,


 


The=20
default TOS type should be defined on the ROOT termination for the =
default TOS=20
used for all media packets generated from the MG. There should be a =
method=20
(might be through some property) of specifying stream level TOS bits.=20



 


I'm=20
interested to work on RSVP. 


 


Regards


Madhubabu



  
-----Original Message-----
From:=20
  owner-megaco@pit.comms.marconi.com=20
  [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen,=20
  Brian
Sent: Tuesday, May 08, 2001 8:10 AM
To: =
'Tom-PT=20
  Taylor'; 'Chuong Nguyen'; 'megaco@fore.com'
Subject: RE: IP =
Type of=20
  Service


  
TOS should=20
  not be ignored at the edge router if the router is configured=20
  to

  
enable=20
  DiffServ.  

  
 

  
It would be=20
  pretty simple to create one package that had the appropriate controls=20
  for

  
DiffServ=20
  and 802.1p.  RSVP needs it's own package because there is=20
  messaging,

  
and you at=20
  least an event or two

  
 

  
The former=20
  could be an enumeration: QosMarking, that had values None, TOS=20
  and

  
FramePriority, plus another integer, =
Value. =20
  That would suffice I think, although you

  
could=20
  conceivably get more clever with DiffServ.

  
 

  
Shall I write something up along those =

  lines?  

  
 

  
RSVP takes=20
  some more work.  Any volunteers?

  
 

  
Brian

  
    
-----Original Message-----
From: Tom-PT Taylor=20
    [mailto:taylor@nortelnetworks.com]
Sent: Monday, May 07, =
2001 9:15=20
    PM
To: 'Chuong Nguyen'; =
'megaco@fore.com'
Subject: RE:=20
    IP Type of Service


    
No=20
    such package has yet been defined.

    
 

    
Various QOS architectures can be =
imagined. =20
    Each would give rise to its own package, since the MGC-MG =
information flow=20
    would differ from one architecture to the next.  One question: =
unless=20
    the MG is itself the edge router, won't the ToS be ignored when the =
media=20
    packets reach the latter?

    
      
-----Original Message-----
From: Chuong Nguyen=20
      [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Monday, May =
07,=20
      2001 5:14 PM
To: 'megaco@fore.com'
Subject: IP =
Type of=20
      Service

All=20
      
In MGCP, MGC can specify IP Type of Service to the =
MG. 
Do=20
      we have an equivalent in Megaco?=20
      
Is there or has anyone defined a package for IP Type of =
Service?=20
      
Thanks 
Chuong 
-- 
  Alcatel USA, =
Inc           &nbs=
p; Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas =
75075           =
Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc =
****
 =20
    


------=_NextPart_000_0137_01C0D7A0.A46B2B80--



From owner-megaco@fore.com  Tue May  8 09:32:32 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21710
	for ; Tue, 8 May 2001 09:32:32 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA13812;
	Tue, 8 May 2001 09:25:08 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA19781
	for megaco-list; Tue, 8 May 2001 09:24:05 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA19725
	for ; Tue, 8 May 2001 09:24:02 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 8 May 2001 09:23:42 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F58C@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Madhu Babu Brahmanapally'" ,
        "'Tom-PT Taylor'"
	 ,
        "'Chuong Nguyen'"
	 , megaco@fore.com
Subject: RE: IP Type of Service
Date: Tue, 8 May 2001 09:23:56 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0D7C2.22614080"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D7C2.22614080
Content-Type: text/plain;
	charset="iso-8859-1"

I don't agree.  The TOS for a particular stream should be set on that
stream, not
on the MG as a whole.  For example, if I have a multimedia MG, I will want
to set
the priority of voice higher than video, and video higher than normal.  If I
implement a
Multilevel Pre-emption and Priority scheme, some calls will have higher
priority than
others.  The TOS/frame priority has to be per stream.
 
Brian

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Tuesday, May 08, 2001 9:24 AM
To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; megaco@fore.com
Subject: RE: IP Type of Service


Hi All,
 
The default TOS type should be defined on the ROOT termination for the
default TOS used for all media packets generated from the MG. There should
be a method (might be through some property) of specifying stream level TOS
bits. 
 
I'm interested to work on RSVP. 
 
Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Tuesday, May 08, 2001 8:10 AM
To: 'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco@fore.com'
Subject: RE: IP Type of Service


TOS should not be ignored at the edge router if the router is configured to
enable DiffServ.  
 
It would be pretty simple to create one package that had the appropriate
controls for
DiffServ and 802.1p.  RSVP needs it's own package because there is
messaging,
and you at least an event or two
 
The former could be an enumeration: QosMarking, that had values None, TOS
and
FramePriority, plus another integer, Value.  That would suffice I think,
although you
could conceivably get more clever with DiffServ.
 
Shall I write something up along those lines?  
 
RSVP takes some more work.  Any volunteers?
 
Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Monday, May 07, 2001 9:15 PM
To: 'Chuong Nguyen'; 'megaco@fore.com'
Subject: RE: IP Type of Service


No such package has yet been defined.
 
Various QOS architectures can be imagined.  Each would give rise to its own
package, since the MGC-MG information flow would differ from one
architecture to the next.  One question: unless the MG is itself the edge
router, won't the ToS be ignored when the media packets reach the latter?

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Monday, May 07, 2001 5:14 PM
To: 'megaco@fore.com'
Subject: IP Type of Service


All 

In MGCP, MGC can specify IP Type of Service to the MG. 
Do we have an equivalent in Megaco? 


Is there or has anyone defined a package for IP Type of Service? 


Thanks 
Chuong 

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


------_=_NextPart_001_01C0D7C2.22614080
Content-Type: text/html;
	charset="iso-8859-1"









I don't 
agree.  The TOS for a particular stream should be set on that stream, 
not


on the MG as 
a whole.  For example, if I have a multimedia MG, I will want to 
set


the priority 
of voice higher than video, and video higher than normal.  If I implement 
a


Multilevel 
Pre-emption and Priority scheme, some calls will have higher priority 
than


others.  
The TOS/frame priority has to be per stream.


 


Brian



  
-----Original Message-----
From: Madhu Babu Brahmanapally 
  [mailto:madhubabu@kenetec.com]
Sent: Tuesday, May 08, 2001 9:24 
  AM
To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; 
  megaco@fore.com
Subject: RE: IP Type of Service


  
Hi 
  All,

  
 

  
The 
  default TOS type should be defined on the ROOT termination for the default TOS 
  used for all media packets generated from the MG. There should be a method 
  (might be through some property) of specifying stream level TOS bits. 
  

  
 

  
I'm 
  interested to work on RSVP. 

  
 

  
Regards

  
Madhubabu

  

    
-----Original Message-----
From: 
    owner-megaco@pit.comms.marconi.com 
    [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, 
    Brian
Sent: Tuesday, May 08, 2001 8:10 AM
To: 'Tom-PT 
    Taylor'; 'Chuong Nguyen'; 'megaco@fore.com'
Subject: RE: IP Type 
    of Service


    
TOS 
    should not be ignored at the edge router if the router is configured 
    to

    
enable 
    DiffServ.  

    
 

    
It would 
    be pretty simple to create one package that had the appropriate controls 
    for

    
DiffServ 
    and 802.1p.  RSVP needs it's own package because there is 
    messaging,

    
and you 
    at least an event or two

    
 

    
The 
    former could be an enumeration: QosMarking, that had values None, TOS 
    and

    
FramePriority, plus another integer, Value.  
    That would suffice I think, although you

    
could 
    conceivably get more clever with DiffServ.

    
 

    
Shall I write something up along those 
    lines?  

    
 

    
RSVP 
    takes some more work.  Any volunteers?

    
 

    
Brian

    

      
-----Original Message-----
From: Tom-PT Taylor 
      [mailto:taylor@nortelnetworks.com]
Sent: Monday, May 07, 2001 
      9:15 PM
To: 'Chuong Nguyen'; 
      'megaco@fore.com'
Subject: RE: IP Type of 
      Service


      
No such package has yet been 
      defined.

      
 

      
Various QOS architectures can be imagined.  
      Each would give rise to its own package, since the MGC-MG information flow 
      would differ from one architecture to the next.  One question: unless 
      the MG is itself the edge router, won't the ToS be ignored when the media 
      packets reach the latter?

      

        
-----Original Message-----
From: Chuong Nguyen 
        [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Monday, May 07, 
        2001 5:14 PM
To: 'megaco@fore.com'
Subject: IP Type 
        of Service

All 
        
In MGCP, MGC can specify IP Type of Service to the MG. 
        
Do we have an equivalent in Megaco? 
        
Is there or has anyone defined a package for IP Type of Service? 

        
Thanks 
Chuong 
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  
      


------_=_NextPart_001_01C0D7C2.22614080--


From owner-megaco@fore.com  Tue May  8 10:06:54 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23098
	for ; Tue, 8 May 2001 10:06:54 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA17461;
	Tue, 8 May 2001 09:59:09 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA28730
	for megaco-list; Tue, 8 May 2001 09:57:59 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA28722
	for ; Tue, 8 May 2001 09:57:58 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA17213
	for ; Tue, 8 May 2001 09:57:56 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACE02843;
	Tue, 8 May 2001 09:57:04 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Rosen, Brian'" ,
        "'Tom-PT Taylor'" ,
        "'Chuong Nguyen'" , 
Subject: RE: IP Type of Service
Date: Tue, 8 May 2001 10:01:58 -0400
Message-ID: <014601c0d7c7$72ebe5a0$c500a8c0@MBRAHMANAPALLY>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0147_01C0D7A5.EBDA45A0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <4FBEA8857476D311A03300204840E1CF01A6F58C@whq-msgusr-02.pit.comms.marconi.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0147_01C0D7A5.EBDA45A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Brian,
I agree that there should be stream level TOS, I even mentioned that in my
mail. This needs to be sent from the MGC when that particular stream is
established. But if the TOS is having a constant value for every stream, its
an overhead to send it for each stream as and when it is created. The
default TOS defined on ROOT will be taken as the default value for all the
streams unless overwritten by the MGC while stream creation, thus defining
the gateway level TOS. The other alternative of the same is to have a
default value for the TOS defined in the LocalControlDescriptor, which
again defines the default TOS used across the system.  But this will remain
as the provisioned default, whose value cannot be changed by the MGC during
runtime, unless a property is defined on the ROOT.


Regards
Madhubabu
  -----Original Message-----
  From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
  Sent: Tuesday, May 08, 2001 9:24 AM
  To: 'Madhu Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen';
megaco@fore.com
  Subject: RE: IP Type of Service


  I don't agree.  The TOS for a particular stream should be set on that
stream, not
  on the MG as a whole.  For example, if I have a multimedia MG, I will want
to set
  the priority of voice higher than video, and video higher than normal.  If
I implement a
  Multilevel Pre-emption and Priority scheme, some calls will have higher
priority than
  others.  The TOS/frame priority has to be per stream.

  Brian
    -----Original Message-----
    From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
    Sent: Tuesday, May 08, 2001 9:24 AM
    To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; megaco@fore.com
    Subject: RE: IP Type of Service


    Hi All,

    The default TOS type should be defined on the ROOT termination for the
default TOS used for all media packets generated from the MG. There should
be a method (might be through some property) of specifying stream level TOS
bits.

    I'm interested to work on RSVP.

    Regards
    Madhubabu
      -----Original Message-----
      From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
      Sent: Tuesday, May 08, 2001 8:10 AM
      To: 'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco@fore.com'
      Subject: RE: IP Type of Service


      TOS should not be ignored at the edge router if the router is
configured to
      enable DiffServ.

      It would be pretty simple to create one package that had the
appropriate controls for
      DiffServ and 802.1p.  RSVP needs it's own package because there is
messaging,
      and you at least an event or two

      The former could be an enumeration: QosMarking, that had values None,
TOS and
      FramePriority, plus another integer, Value.  That would suffice I
think, although you
      could conceivably get more clever with DiffServ.

      Shall I write something up along those lines?

      RSVP takes some more work.  Any volunteers?

      Brian
        -----Original Message-----
        From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
        Sent: Monday, May 07, 2001 9:15 PM
        To: 'Chuong Nguyen'; 'megaco@fore.com'
        Subject: RE: IP Type of Service


        No such package has yet been defined.

        Various QOS architectures can be imagined.  Each would give rise to
its own package, since the MGC-MG information flow would differ from one
architecture to the next.  One question: unless the MG is itself the edge
router, won't the ToS be ignored when the media packets reach the latter?
          -----Original Message-----
          From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
          Sent: Monday, May 07, 2001 5:14 PM
          To: 'megaco@fore.com'
          Subject: IP Type of Service


          All
          In MGCP, MGC can specify IP Type of Service to the MG.
          Do we have an equivalent in Megaco?

          Is there or has anyone defined a package for IP Type of Service?

          Thanks
          Chuong

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****


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









Hi=20
Brian,


I=20
agree that there should be stream level TOS, I even mentioned that =
in my=20
mail. This needs to be sent from the MGC when that particular stream is=20
established. But if the TOS is having a constant value for every stream, =
its an=20
overhead to send it for each stream as and when it is created. The =
default TOS=20
defined on ROOT will be taken as the default value for all the streams =
unless=20
overwritten by the MGC while stream creation, thus defining the gateway =
level=20
TOS. The other alternative of the same is to have a default value for =
the TOS=20
defined in the LocalControlDescriptor, which  again defines the default =
TOS used=20
across the system.  But this will remain as the provisioned =
default, whose=20
value cannot be changed by the MGC during runtime, unless a property is =
defined=20
on the ROOT.


 


 


Regards


Madhubabu



  
-----Original Message-----
From:=20
  owner-megaco@pit.comms.marconi.com=20
  [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen,=20
  Brian
Sent: Tuesday, May 08, 2001 9:24 AM
To: =
'Madhu Babu=20
  Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen';=20
  megaco@fore.com
Subject: RE: IP Type of =
Service


  
I don't=20
  agree.  The TOS for a particular stream should be set on that =
stream,=20
  not

  
on the MG=20
  as a whole.  For example, if I have a multimedia MG, I will want =
to=20
  set

  
the=20
  priority of voice higher than video, and video higher than =
normal.  If I=20
  implement a

  
Multilevel=20
  Pre-emption and Priority scheme, some calls will have higher priority=20
  than

  
others.  The TOS/frame priority has to =
be per=20
  stream.

  
 

  
Brian

  
    
-----Original Message-----
From: Madhu Babu =
Brahmanapally=20
    [mailto:madhubabu@kenetec.com]
Sent: Tuesday, May 08, 2001 =
9:24=20
    AM
To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen';=20
    megaco@fore.com
Subject: RE: IP Type of=20
    Service


    
Hi=20
    All,

    
 

    
The default TOS type should be defined on =
the ROOT=20
    termination for the default TOS used for all media packets generated =
from=20
    the MG. There should be a method (might be through some property) of =

    specifying stream level TOS bits. 

    
 

    
I'm interested to work on RSVP.=20


    
 

    
Regards

    
Madhubabu

    

      
-----Original Message-----
From:=20
      owner-megaco@pit.comms.marconi.com=20
      [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of =
Rosen,=20
      Brian
Sent: Tuesday, May 08, 2001 8:10 AM
To: =
'Tom-PT=20
      Taylor'; 'Chuong Nguyen'; 'megaco@fore.com'
Subject: RE: =
IP Type=20
      of Service


      
TOS=20
      should not be ignored at the edge router if the router is =
configured=20
      to

      
enable=20
      DiffServ.  

      
 

      
It=20
      would be pretty simple to create one package that had the =
appropriate=20
      controls for

      
DiffServ and 802.1p.  RSVP needs =
it's own=20
      package because there is messaging,

      
and you=20
      at least an event or two

      
 

      
The=20
      former could be an enumeration: QosMarking, that had values None, =
TOS=20
      and

      
FramePriority, plus another integer, =
Value. =20
      That would suffice I think, although you

      
could=20
      conceivably get more clever with DiffServ.

      
 

      
Shall I write something up along =
those=20
      lines?  

      
 

      
RSVP=20
      takes some more work.  Any volunteers?

      
 

      
Brian

      
        
-----Original Message-----
From: Tom-PT =
Taylor=20
        [mailto:taylor@nortelnetworks.com]
Sent: Monday, May =
07, 2001=20
        9:15 PM
To: 'Chuong Nguyen';=20
        'megaco@fore.com'
Subject: RE: IP Type of=20
        Service


        
No such package has yet been=20
        defined.

        
 

        
Various QOS architectures can be=20
        imagined.  Each would give rise to its own package, since =
the=20
        MGC-MG information flow would differ from one architecture to =
the=20
        next.  One question: unless the MG is itself the edge =
router, won't=20
        the ToS be ignored when the media packets reach the=20
        latter?

        
          
-----Original Message-----
From: Chuong =
Nguyen=20
          [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Monday, =
May 07,=20
          2001 5:14 PM
To: =
'megaco@fore.com'
Subject: IP=20
          Type of Service

All=20
          
In MGCP, MGC can specify IP Type of Service to =
the MG.=20
          
Do we have an equivalent in Megaco?=20
          
Is there or has anyone defined a package for IP Type =
of=20
          Service?=20
          
Thanks 
Chuong 
-- 
  Alcatel USA, =
Inc           &nbs=
p; Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas =
75075           =
Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc =
****
 =20
        =

<=
/HTML>

------=_NextPart_000_0147_01C0D7A5.EBDA45A0--



From owner-megaco@fore.com  Tue May  8 10:16:14 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23672
	for ; Tue, 8 May 2001 10:16:14 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18955;
	Tue, 8 May 2001 10:08:50 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA02438
	for megaco-list; Tue, 8 May 2001 10:07:40 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA02434
	for ; Tue, 8 May 2001 10:07:39 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA18736
	for ; Tue, 8 May 2001 10:07:36 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id KAA15670; Tue, 8 May 2001 10:07:33 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 8 May 2001 10:07:19 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Tue, 8 May 2001 10:07:21 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CADC@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Madhu Babu Brahmanapally'" ,
        "'Rosen, Brian'" ,
        "'Chuong Nguyen'" ,
        megaco 
Subject: RE: IP Type of Service
Date: Tue, 8 May 2001 10:07:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D7C8.2E8E4280"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D7C8.2E8E4280
Content-Type: text/plain;
	charset="iso-8859-1"

That makes sense.

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Tuesday, May 08, 2001 10:08 AM
To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B881:EXCH]; 'Chuong Nguyen';
megaco
Subject: RE: IP Type of Service


Hi All,
Another suggestion. Why cant the SDP be extended to incorporate a TOS
parameter/attribute so that all the protocols(SIP,Megaco,MGCP) that use SDP
need not define extra properties/parameter for supporting this. 
 
Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Tuesday, May 08, 2001 9:24 AM
To: 'Madhu Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen';
megaco@fore.com
Subject: RE: IP Type of Service


I don't agree.  The TOS for a particular stream should be set on that
stream, not
on the MG as a whole.  For example, if I have a multimedia MG, I will want
to set
the priority of voice higher than video, and video higher than normal.  If I
implement a
Multilevel Pre-emption and Priority scheme, some calls will have higher
priority than
others.  The TOS/frame priority has to be per stream.
 
Brian

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Tuesday, May 08, 2001 9:24 AM
To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; megaco@fore.com
Subject: RE: IP Type of Service


Hi All,
 
The default TOS type should be defined on the ROOT termination for the
default TOS used for all media packets generated from the MG. There should
be a method (might be through some property) of specifying stream level TOS
bits. 
 
I'm interested to work on RSVP. 
 
Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Tuesday, May 08, 2001 8:10 AM
To: 'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco@fore.com'
Subject: RE: IP Type of Service


TOS should not be ignored at the edge router if the router is configured to
enable DiffServ.  
 
It would be pretty simple to create one package that had the appropriate
controls for
DiffServ and 802.1p.  RSVP needs it's own package because there is
messaging,
and you at least an event or two
 
The former could be an enumeration: QosMarking, that had values None, TOS
and
FramePriority, plus another integer, Value.  That would suffice I think,
although you
could conceivably get more clever with DiffServ.
 
Shall I write something up along those lines?  
 
RSVP takes some more work.  Any volunteers?
 
Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Monday, May 07, 2001 9:15 PM
To: 'Chuong Nguyen'; 'megaco@fore.com'
Subject: RE: IP Type of Service


No such package has yet been defined.
 
Various QOS architectures can be imagined.  Each would give rise to its own
package, since the MGC-MG information flow would differ from one
architecture to the next.  One question: unless the MG is itself the edge
router, won't the ToS be ignored when the media packets reach the latter?

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Monday, May 07, 2001 5:14 PM
To: 'megaco@fore.com'
Subject: IP Type of Service


All 

In MGCP, MGC can specify IP Type of Service to the MG. 
Do we have an equivalent in Megaco? 


Is there or has anyone defined a package for IP Type of Service? 


Thanks 
Chuong 

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


------_=_NextPart_001_01C0D7C8.2E8E4280
Content-Type: text/html;
	charset="iso-8859-1"









That 
makes sense.



  
-----Original Message-----
From: Madhu Babu Brahmanapally 
  [mailto:madhubabu@kenetec.com]
Sent: Tuesday, May 08, 2001 10:08 
  AM
To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B881:EXCH]; 'Chuong 
  Nguyen'; megaco
Subject: RE: IP Type of Service


  
Hi 
  All,

  
Another suggestion. Why cant the SDP be extended 
  to incorporate a TOS parameter/attribute so that all the 
  protocols(SIP,Megaco,MGCP) that use SDP need not define extra 
  properties/parameter for supporting this. 

  
 

  
Regards

  
Madhubabu

  

    
-----Original Message-----
From: 
    owner-megaco@pit.comms.marconi.com 
    [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, 
    Brian
Sent: Tuesday, May 08, 2001 9:24 AM
To: 'Madhu 
    Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen'; 
    megaco@fore.com
Subject: RE: IP Type of 
    Service


    
I don't 
    agree.  The TOS for a particular stream should be set on that stream, 
    not

    
on the MG 
    as a whole.  For example, if I have a multimedia MG, I will want to 
    set

    
the 
    priority of voice higher than video, and video higher than normal.  If 
    I implement a

    
Multilevel Pre-emption and Priority scheme, some 
    calls will have higher priority than

    
others.  The TOS/frame priority has to be per 
    stream.

    
 

    
Brian

    

      
-----Original Message-----
From: Madhu Babu Brahmanapally 
      [mailto:madhubabu@kenetec.com]
Sent: Tuesday, May 08, 2001 9:24 
      AM
To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; 
      megaco@fore.com
Subject: RE: IP Type of 
      Service


      
Hi All,

      
 

      
The default TOS type should be defined on the 
      ROOT termination for the default TOS used for all media packets generated 
      from the MG. There should be a method (might be through some property) of 
      specifying stream level TOS bits. 

      
 

      
I'm interested to work on RSVP. 
      

      
 

      
Regards

      
Madhubabu

      

        
-----Original Message-----
From: 
        owner-megaco@pit.comms.marconi.com 
        [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, 
        Brian
Sent: Tuesday, May 08, 2001 8:10 AM
To: 
        'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco@fore.com'
Subject: 
        RE: IP Type of Service


        
TOS 
        should not be ignored at the edge router if the router is configured 
        to

        
enable DiffServ.  

        
 

        
It 
        would be pretty simple to create one package that had the appropriate 
        controls for

        
DiffServ and 802.1p.  RSVP needs it's own 
        package because there is messaging,

        
and 
        you at least an event or two

        
 

        
The 
        former could be an enumeration: QosMarking, that had values None, TOS 
        and

        
FramePriority, plus another integer, 
        Value.  That would suffice I think, although 
you

        
could 
        conceivably get more clever with DiffServ.

        
 

        
Shall I write something up along those 
        lines?  

        
 

        
RSVP 
        takes some more work.  Any volunteers?

        
 

        
Brian

        

          
-----Original Message-----
From: Tom-PT Taylor 
          [mailto:taylor@nortelnetworks.com]
Sent: Monday, May 07, 
          2001 9:15 PM
To: 'Chuong Nguyen'; 
          'megaco@fore.com'
Subject: RE: IP Type of 
          Service


          
No such package has yet been 
          defined.

          
 

          
Various QOS architectures can be 
          imagined.  Each would give rise to its own package, since the 
          MGC-MG information flow would differ from one architecture to the 
          next.  One question: unless the MG is itself the edge router, 
          won't the ToS be ignored when the media packets reach the 
          latter?

          

            
-----Original Message-----
From: Chuong Nguyen 
            [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Monday, May 
            07, 2001 5:14 PM
To: 'megaco@fore.com'
Subject: 
            IP Type of Service

All 
            
In MGCP, MGC can specify IP Type of Service to the MG. 
            
Do we have an equivalent in Megaco? 
            
Is there or has anyone defined a package for IP Type of 
            Service? 
            
Thanks 
Chuong 
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  
          


------_=_NextPart_001_01C0D7C8.2E8E4280--


From owner-megaco@fore.com  Tue May  8 10:22:39 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24128
	for ; Tue, 8 May 2001 10:22:38 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18632;
	Tue, 8 May 2001 10:07:09 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA01623
	for megaco-list; Tue, 8 May 2001 10:06:22 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA01564
	for ; Tue, 8 May 2001 10:05:21 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18342
	for ; Tue, 8 May 2001 10:05:19 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACE02922;
	Tue, 8 May 2001 10:03:11 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Rosen, Brian'" ,
        "'Tom-PT Taylor'" ,
        "'Chuong Nguyen'" , 
Subject: RE: IP Type of Service
Date: Tue, 8 May 2001 10:08:04 -0400
Message-ID: <014b01c0d7c8$4d2c8c10$c500a8c0@MBRAHMANAPALLY>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_014C_01C0D7A6.C61AEC10"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <4FBEA8857476D311A03300204840E1CF01A6F58C@whq-msgusr-02.pit.comms.marconi.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_014C_01C0D7A6.C61AEC10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi All,
Another suggestion. Why cant the SDP be extended to incorporate a TOS
parameter/attribute so that all the protocols(SIP,Megaco,MGCP) that use SDP
need not define extra properties/parameter for supporting this.

Regards
Madhubabu
  -----Original Message-----
  From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
  Sent: Tuesday, May 08, 2001 9:24 AM
  To: 'Madhu Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen';
megaco@fore.com
  Subject: RE: IP Type of Service


  I don't agree.  The TOS for a particular stream should be set on that
stream, not
  on the MG as a whole.  For example, if I have a multimedia MG, I will want
to set
  the priority of voice higher than video, and video higher than normal.  If
I implement a
  Multilevel Pre-emption and Priority scheme, some calls will have higher
priority than
  others.  The TOS/frame priority has to be per stream.

  Brian
    -----Original Message-----
    From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
    Sent: Tuesday, May 08, 2001 9:24 AM
    To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; megaco@fore.com
    Subject: RE: IP Type of Service


    Hi All,

    The default TOS type should be defined on the ROOT termination for the
default TOS used for all media packets generated from the MG. There should
be a method (might be through some property) of specifying stream level TOS
bits.

    I'm interested to work on RSVP.

    Regards
    Madhubabu
      -----Original Message-----
      From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
      Sent: Tuesday, May 08, 2001 8:10 AM
      To: 'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco@fore.com'
      Subject: RE: IP Type of Service


      TOS should not be ignored at the edge router if the router is
configured to
      enable DiffServ.

      It would be pretty simple to create one package that had the
appropriate controls for
      DiffServ and 802.1p.  RSVP needs it's own package because there is
messaging,
      and you at least an event or two

      The former could be an enumeration: QosMarking, that had values None,
TOS and
      FramePriority, plus another integer, Value.  That would suffice I
think, although you
      could conceivably get more clever with DiffServ.

      Shall I write something up along those lines?

      RSVP takes some more work.  Any volunteers?

      Brian
        -----Original Message-----
        From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
        Sent: Monday, May 07, 2001 9:15 PM
        To: 'Chuong Nguyen'; 'megaco@fore.com'
        Subject: RE: IP Type of Service


        No such package has yet been defined.

        Various QOS architectures can be imagined.  Each would give rise to
its own package, since the MGC-MG information flow would differ from one
architecture to the next.  One question: unless the MG is itself the edge
router, won't the ToS be ignored when the media packets reach the latter?
          -----Original Message-----
          From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
          Sent: Monday, May 07, 2001 5:14 PM
          To: 'megaco@fore.com'
          Subject: IP Type of Service


          All
          In MGCP, MGC can specify IP Type of Service to the MG.
          Do we have an equivalent in Megaco?

          Is there or has anyone defined a package for IP Type of Service?

          Thanks
          Chuong

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****


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









Hi=20
All,


Another suggestion. Why cant the SDP be =
extended=20
to incorporate a TOS parameter/attribute so that all the=20
protocols(SIP,Megaco,MGCP) that use SDP need not define extra=20
properties/parameter for supporting this. 


 


Regards


Madhubabu



  
-----Original Message-----
From:=20
  owner-megaco@pit.comms.marconi.com=20
  [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen,=20
  Brian
Sent: Tuesday, May 08, 2001 9:24 AM
To: =
'Madhu Babu=20
  Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen';=20
  megaco@fore.com
Subject: RE: IP Type of =
Service


  
I don't=20
  agree.  The TOS for a particular stream should be set on that =
stream,=20
  not

  
on the MG=20
  as a whole.  For example, if I have a multimedia MG, I will want =
to=20
  set

  
the=20
  priority of voice higher than video, and video higher than =
normal.  If I=20
  implement a

  
Multilevel=20
  Pre-emption and Priority scheme, some calls will have higher priority=20
  than

  
others.  The TOS/frame priority has to =
be per=20
  stream.

  
 

  
Brian

  
    
-----Original Message-----
From: Madhu Babu =
Brahmanapally=20
    [mailto:madhubabu@kenetec.com]
Sent: Tuesday, May 08, 2001 =
9:24=20
    AM
To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen';=20
    megaco@fore.com
Subject: RE: IP Type of=20
    Service


    
Hi=20
    All,

    
 

    
The default TOS type should be defined on =
the ROOT=20
    termination for the default TOS used for all media packets generated =
from=20
    the MG. There should be a method (might be through some property) of =

    specifying stream level TOS bits. 

    
 

    
I'm interested to work on RSVP.=20


    
 

    
Regards

    
Madhubabu

    

      
-----Original Message-----
From:=20
      owner-megaco@pit.comms.marconi.com=20
      [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of =
Rosen,=20
      Brian
Sent: Tuesday, May 08, 2001 8:10 AM
To: =
'Tom-PT=20
      Taylor'; 'Chuong Nguyen'; 'megaco@fore.com'
Subject: RE: =
IP Type=20
      of Service


      
TOS=20
      should not be ignored at the edge router if the router is =
configured=20
      to

      
enable=20
      DiffServ.  

      
 

      
It=20
      would be pretty simple to create one package that had the =
appropriate=20
      controls for

      
DiffServ and 802.1p.  RSVP needs =
it's own=20
      package because there is messaging,

      
and you=20
      at least an event or two

      
 

      
The=20
      former could be an enumeration: QosMarking, that had values None, =
TOS=20
      and

      
FramePriority, plus another integer, =
Value. =20
      That would suffice I think, although you

      
could=20
      conceivably get more clever with DiffServ.

      
 

      
Shall I write something up along =
those=20
      lines?  

      
 

      
RSVP=20
      takes some more work.  Any volunteers?

      
 

      
Brian

      
        
-----Original Message-----
From: Tom-PT =
Taylor=20
        [mailto:taylor@nortelnetworks.com]
Sent: Monday, May =
07, 2001=20
        9:15 PM
To: 'Chuong Nguyen';=20
        'megaco@fore.com'
Subject: RE: IP Type of=20
        Service


        
No such package has yet been=20
        defined.

        
 

        
Various QOS architectures can be=20
        imagined.  Each would give rise to its own package, since =
the=20
        MGC-MG information flow would differ from one architecture to =
the=20
        next.  One question: unless the MG is itself the edge =
router, won't=20
        the ToS be ignored when the media packets reach the=20
        latter?

        
          
-----Original Message-----
From: Chuong =
Nguyen=20
          [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Monday, =
May 07,=20
          2001 5:14 PM
To: =
'megaco@fore.com'
Subject: IP=20
          Type of Service

All=20
          
In MGCP, MGC can specify IP Type of Service to =
the MG.=20
          
Do we have an equivalent in Megaco?=20
          
Is there or has anyone defined a package for IP Type =
of=20
          Service?=20
          
Thanks 
Chuong 
-- 
  Alcatel USA, =
Inc           &nbs=
p; Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas =
75075           =
Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc =
****
 =20
        =

<=
/HTML>

------=_NextPart_000_014C_01C0D7A6.C61AEC10--



From owner-megaco@fore.com  Tue May  8 10:23:48 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24189
	for ; Tue, 8 May 2001 10:23:47 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19923;
	Tue, 8 May 2001 10:16:01 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA04203
	for megaco-list; Tue, 8 May 2001 10:14:58 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04167;
	Tue, 8 May 2001 10:14:51 -0400 (EDT)
From: this_is_it@yahoo.com
Received: from nm. ([61.140.254.9])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA19724;
	Tue, 8 May 2001 10:14:49 -0400 (EDT)
Received: from yahoo.com by nm. (SMI-8.6/SMI-SVR4)
	id WAA17096; Tue, 8 May 2001 22:03:51 +0900
Subject: No charge!!
Date: Tue, 8 May 2001 10:13:56
Message-Id: <458.886632.490694@yahoo.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Apparently-To: 
Apparently-To: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id KAA19923
Content-Transfer-Encoding: quoted-printable






WORD PUZZLE LOVERS=97



=20
    =20
    =20
    =20
    =20
    =20
    =20
    =20
    =20
    

  
=20
      
=
~ WORD=20
        PUZZLE LOVERS ~ 

      
 

    		
  

  
=20
      
Do you like double acrostics?

      
We=20
        Want To Send You, a FREE Sample?

    		
  

  
=20
      
 

      
    
        
  • Do you like them big with lots of meat=
 in them?=20
          
    
        
    • 
      

      
Our puzzles average well over 250 letters. Most=
 published=20
        puzzles have around 200.

      
 

      
    
        
  • Do you like them really tough and chal=
lenging?=20
          
    • 
      

      
 We dig deep for our clues and once in a while =
we stick=20
        in a real off-the-wall doozer

      

      
 

    		
  

  
=20
      
If you answer YES,=
 we have=20
        the acrostics for you! 

    		
  

  
=20
      
 

      
 

      
* We offer a subscription service.<=
/u> *

    		
  

  
=20
      
=20
        
Our=
 Subscribers=20
          receive five new mind-ben=
ders every=20
          month 

        
 and they are delivered right into their m=
ailbox.

        
 

      

    		
  

  
=20
      
Would You Like us to Send=
 You, a FREE=20
        Sample?

      

    		
  

  
=20
      
=20
        
Yes, I want=20
          to learn more about your Puzzles=
.

        
Please click below 

      

    		
    =20
      
=20
        
I am not interested; take me off your lis=
t.

        
Please click=20
          below

      

    		
  

  
=20
      =20
          

        
 
          =20
            
          
           
           
          =20
            
          
           
        

      

      
 

      
 

      
 

      
 

      
 

      
 

      
 

      
 

      
 

      
 

      
 

      
 

      
 

      
 

      
 

      
 

      
 

      
 

      
 

      
 

      
 

    		
  



=20
    

  
=20
      
 

      
 

      
 

    		
    =20
      
Our=20
        puzzles, [word puzzles for the connoisseur] start out with a lite=
rary=20
        quote. We use all the letters in the quote and create clues. The =
first=20
        letters of the clues spell out the author=92s name and the title =
of the=20
        source of the quote. The letters of the clue words are numbered a=
nd correspond=20
        to squares in the accompanying grid. Filling in the grid reveals =
the quotation.=20
        

      
Sound=20
        complicated? 

      
Well=20
        maybe a little, but that's where the solving fun comes in.

      
 

      
 

    		
     
  



=20
    

  
=20
      
=20
        
Yes,=20
          I want to learn more about your Puzzles and=20
          I want to receive a FREE =
sample.

        
Please=20
          click below

      

    		
    =20
      
=20
        
 

        

    		
  



=20
    

  
=20
      
    
     
  



=20
    =20
    

  
=20
      

        
Please=20
          include your Name and US Mailing Address including Zip Code. 

        
 

  

  
=20
      
=20
        
 

        
I=20
          am not interested; take me off your list.

        
Please=20
          click below

      

    		
     
  



=20
    

  
=20
      
    
     
  




 


 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0   =20






From owner-megaco@fore.com  Tue May  8 11:00:47 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26119
	for ; Tue, 8 May 2001 11:00:46 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA22477;
	Tue, 8 May 2001 10:36:46 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA10711
	for megaco-list; Tue, 8 May 2001 10:34:57 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10695
	for ; Tue, 8 May 2001 10:34:55 -0400 (EDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA22170
	for ; Tue, 8 May 2001 10:34:53 -0400 (EDT)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA26780
	for ; Tue, 8 May 2001 09:34:54 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f48EYsT03463
	for ; Tue, 8 May 2001 09:34:54 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f48EXp116710
	for ; Tue, 8 May 2001 09:33:51 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f48EXpO20885
	for ; Tue, 8 May 2001 09:33:52 -0500 (CDT)
Message-ID: <3AF803CF.D44F556C@usa.alcatel.com>
Date: Tue, 08 May 2001 09:33:51 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "'megaco@fore.com'" 
Subject: Re: IP Type of Service
References: <28560036253BD41191A10000F8BCBD110250CADC@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------29695B9E2F135784C3ED4B44"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------29695B9E2F135784C3ED4B44
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Right now I don't have any preference w/package vs SDP extension.
Which is quicker to be considered as acceptable for Standardization?
Is there any difference in the IETF process vs ITU process?

But I am concern w/the concept of doing an AuditCapability to see what
package does
an MG support.  Said there was an SDP extension for ToS, how does an MGC
knows
that the MG supports ToS?

It looks like "Profile" would be more useful than AuditCapability on
package to find
MG capability.




Tom-PT Taylor wrote:

> That makes sense.
>
>      -----Original Message-----
>      From: Madhu Babu Brahmanapally
>      [mailto:madhubabu@kenetec.com]
>      Sent: Tuesday, May 08, 2001 10:08 AM
>      To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B881:EXCH];
>      'Chuong Nguyen'; megaco
>      Subject: RE: IP Type of Service
>      Hi All,Another suggestion. Why cant the SDP be extended to
>      incorporate a TOS parameter/attribute so that all the
>      protocols(SIP,Megaco,MGCP) that use SDP need not define
>      extra properties/parameter for supporting
>      this. RegardsMadhubabu
>
>           -----Original Message-----
>           From: owner-megaco@pit.comms.marconi.com
>           [mailto:owner-megaco@pit.comms.marconi.com]On
>           Behalf Of Rosen, Brian
>           Sent: Tuesday, May 08, 2001 9:24 AM
>           To: 'Madhu Babu Brahmanapally'; 'Tom-PT Taylor';
>           'Chuong Nguyen'; megaco@fore.com
>           Subject: RE: IP Type of Service
>           I don't agree.  The TOS for a particular stream
>           should be set on that stream, noton the MG as a
>           whole.  For example, if I have a multimedia MG, I
>           will want to setthe priority of voice higher than
>           video, and video higher than normal.  If I
>           implement aMultilevel Pre-emption and Priority
>           scheme, some calls will have higher priority
>           thanothers.  The TOS/frame priority has to be per
>           stream.Brian
>
>                -----Original Message-----
>                From: Madhu Babu Brahmanapally
>                [mailto:madhubabu@kenetec.com]
>                Sent: Tuesday, May 08, 2001 9:24 AM
>                To: 'Rosen, Brian'; 'Tom-PT Taylor';
>                'Chuong Nguyen'; megaco@fore.com
>                Subject: RE: IP Type of Service
>                Hi All,The default TOS type should be
>                defined on the ROOT termination for the
>                default TOS used for all media packets
>                generated from the MG. There should be a
>                method (might be through some property)
>                of specifying stream level TOS bits. I'm
>                interested to work on
>                RSVP. RegardsMadhubabu
>
>                     -----Original Message-----
>                     From:
>                     owner-megaco@pit.comms.marconi.com
>                     [mailto:owner-megaco@pit.comms.marconi.com]On
>                     Behalf Of Rosen, Brian
>                     Sent: Tuesday, May 08, 2001
>                     8:10 AM
>                     To: 'Tom-PT Taylor'; 'Chuong
>                     Nguyen'; 'megaco@fore.com'
>                     Subject: RE: IP Type of
>                     Service
>                     TOS should not be ignored at
>                     the edge router if the router
>                     is configured toenable
>                     DiffServ. It would be pretty
>                     simple to create one package
>                     that had the appropriate
>                     controls forDiffServ and
>                     802.1p.  RSVP needs it's own
>                     package because there is
>                     messaging,and you at least an
>                     event or twoThe former could
>                     be an enumeration: QosMarking,
>                     that had values None, TOS
>                     andFramePriority, plus another
>                     integer, Value.  That would
>                     suffice I think, although
>                     youcould conceivably get more
>                     clever with DiffServ.Shall I
>                     write something up along those
>                     lines? RSVP takes some more
>                     work.  Any volunteers?Brian
>
>                          -----Original
>                          Message-----
>                          From: Tom-PT Taylor
>                          [mailto:taylor@nortelnetworks.com]
>
>                          Sent: Monday, May
>                          07, 2001 9:15 PM
>                          To: 'Chuong Nguyen';
>                          'megaco@fore.com'
>                          Subject: RE: IP Type
>                          of Service
>                          No such package has
>                          yet been
>                          defined.Various QOS
>                          architectures can be
>                          imagined.  Each
>                          would give rise to
>                          its own package,
>                          since the MGC-MG
>                          information flow
>                          would differ from
>                          one architecture to
>                          the next.  One
>                          question: unless the
>                          MG is itself the
>                          edge router, won't
>                          the ToS be ignored
>                          when the media
>                          packets reach the
>                          latter?
>
>
>                               ----Original
>                               Message-----
>
>                               From:
>                               Chuong
>                               Nguyen
>                               [mailto:Chuong.Nguyen@usa.alcatel.com]
>
>                               Sent:
>                               Monday,
>                               May 07,
>                               2001 5:14
>                               PM
>                               To:
>                               'megaco@fore.com'
>
>                               Subject:
>                               IP Type of
>                               Service
>                               All
>
>                               In MGCP,
>                               MGC can
>                               specify IP
>                               Type of
>                               Service to
>                               the MG.
>                               Do we have
>                               an
>                               equivalent
>                               in Megaco?
>
>                               Is there
>                               or has
>                               anyone
>                               defined a
>                               package
>                               for IP
>                               Type of
>                               Service?
>
>                               Thanks
>                               Chuong
>
>                               --
>                                 Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>                                 1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>                                 **** The opinions expressed are not those of Alcatel USA, Inc ****
>
>
>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------29695B9E2F135784C3ED4B44
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

Right now I don't have any preference w/package vs SDP extension.

Which is quicker to be considered as acceptable for Standardization?

Is there any difference in the IETF process vs ITU process?

But I am concern w/the concept of doing an AuditCapability to see
what package does

an MG support.  Said there was an SDP extension for ToS, how does
an MGC knows

that the MG supports ToS?

It looks like "Profile" would be more useful than AuditCapability on
package to find

MG capability.

 

 

 

Tom-PT Taylor wrote:

That
makes sense.



-----Original
Message-----

From: Madhu Babu Brahmanapally
[mailto:madhubabu@kenetec.com]

Sent: Tuesday, May 08, 2001
10:08 AM

To: 'Rosen, Brian'; Taylor,
Tom-PT [NORSE:B881:EXCH]; 'Chuong Nguyen'; megaco

Subject: RE: IP Type of Service

Hi
All,Another suggestion. Why cant
the SDP be extended to incorporate a TOS parameter/attribute so that all
the protocols(SIP,Megaco,MGCP) that use SDP need not define extra properties/parameter
for supporting this. RegardsMadhubabu



-----Original
Message-----

From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian

Sent: Tuesday, May 08, 2001
9:24 AM

To: 'Madhu Babu Brahmanapally';
'Tom-PT Taylor'; 'Chuong Nguyen'; megaco@fore.com

Subject: RE: IP Type of Service

I
don't agree.  The TOS for a particular stream should be set on that
stream, noton the MG as a whole. 
For example, if I have a multimedia MG, I will want to setthe
priority of voice higher than video, and video higher than normal. 
If I implement aMultilevel Pre-emption
and Priority scheme, some calls will have higher priority thanothers. 
The TOS/frame priority has to be per stream.Brian



-----Original
Message-----

From: Madhu Babu Brahmanapally
[mailto:madhubabu@kenetec.com]

Sent: Tuesday, May 08, 2001
9:24 AM

To: 'Rosen, Brian'; 'Tom-PT
Taylor'; 'Chuong Nguyen'; megaco@fore.com

Subject: RE: IP Type of Service

Hi
All,The
default TOS type should be defined on the ROOT termination for the default
TOS used for all media packets generated from the MG. There should be a
method (might be through some property) of specifying stream level TOS
bits. I'm
interested to work on RSVP. RegardsMadhubabu



-----Original
Message-----

From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian

Sent: Tuesday, May 08, 2001
8:10 AM

To: 'Tom-PT Taylor'; 'Chuong
Nguyen'; 'megaco@fore.com'

Subject: RE: IP Type of Service

TOS
should not be ignored at the edge router if the router is configured toenable
DiffServ. It
would be pretty simple to create one package that had the appropriate controls
forDiffServ and 802.1p. 
RSVP needs it's own package because there is messaging,and
you at least an event or twoThe
former could be an enumeration: QosMarking, that had values None, TOS andFramePriority,
plus another integer, Value.  That would suffice I think, although
youcould conceivably get more clever
with DiffServ.Shall
I write something up along those lines? RSVP
takes some more work.  Any volunteers?Brian



-----Original
Message-----

From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]

Sent: Monday, May 07, 2001
9:15 PM

To: 'Chuong Nguyen'; 'megaco@fore.com'

Subject: RE: IP Type of Service

No
such package has yet been defined.Various
QOS architectures can be imagined.  Each would give rise to its own
package, since the MGC-MG information flow would differ from one architecture
to the next.  One question: unless the MG is itself the edge router,
won't the ToS be ignored when the media packets reach the latter?



-----Original
Message-----

From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]

Sent: Monday, May 07, 2001
5:14 PM

To: 'megaco@fore.com'

Subject: IP Type of Service

All

In MGCP, MGC can specify IP Type of Service to the MG.

Do we have an equivalent in Megaco?

Is there or has anyone defined a package for IP Type of Service?

Thanks

Chuong

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 















-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------29695B9E2F135784C3ED4B44--



From owner-megaco@fore.com  Tue May  8 11:17:56 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26883
	for ; Tue, 8 May 2001 11:17:56 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25660;
	Tue, 8 May 2001 11:05:21 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA20492
	for megaco-list; Tue, 8 May 2001 11:04:18 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA20452
	for ; Tue, 8 May 2001 11:04:07 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25366
	for ; Tue, 8 May 2001 11:04:05 -0400 (EDT)
Received: from KGUNDAMARAJU ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACK01814;
	Tue, 8 May 2001 11:02:14 -0400 (EDT)
Message-ID: <003501c0d7d0$635d1d30$ae00a8c0@KGUNDAMARAJU>
From: "Krishna Gundamaraju" 
To: "Tom-PT Taylor" 
Cc: 
References: <28560036253BD41191A10000F8BCBD110250CADC@zcard00g.ca.nortel.com>
Subject: Re: IP Type of Service
Date: Tue, 8 May 2001 11:05:58 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0032_01C0D7AE.DC0FD3C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

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

    Assuming that the SDP is extended to specify the TOS value for a =
stream, what should a MG do if this parameter is missing in the SDP sent =
from MGC? I think the protocol should also specify what should happen if =
TOS info is missing in the SDP received.=20

    If both of the above options are available(MEGACO means of =
specifying TOS and SDP way of specifying TOS), the protocol specified =
option should take precedence over the one specified in SDP, as done for =
mode parameter.

    So, as pointed by Madhu, I think we need

1). The capability to specify a default value of TOS for the MG (either =
as a property of the root termination or some other means).
2). The capability to specify the TOS value on per stream basis.

Regards
Krishna G

  ----- Original Message -----=20
  From: Tom-PT Taylor=20
  To: 'Madhu Babu Brahmanapally' ; 'Rosen, Brian' ; 'Chuong Nguyen' ; =
megaco=20
  Sent: Tuesday, May 08, 2001 10:07 AM
  Subject: RE: IP Type of Service


  That makes sense.
    -----Original Message-----
    From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
    Sent: Tuesday, May 08, 2001 10:08 AM
    To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B881:EXCH]; 'Chuong =
Nguyen'; megaco
    Subject: RE: IP Type of Service


    Hi All,
    Another suggestion. Why cant the SDP be extended to incorporate a =
TOS parameter/attribute so that all the protocols(SIP,Megaco,MGCP) that =
use SDP need not define extra properties/parameter for supporting this.=20
    =20
    Regards
    Madhubabu
      -----Original Message-----
      From: owner-megaco@pit.comms.marconi.com =
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
      Sent: Tuesday, May 08, 2001 9:24 AM
      To: 'Madhu Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen'; =
megaco@fore.com
      Subject: RE: IP Type of Service


      I don't agree.  The TOS for a particular stream should be set on =
that stream, not
      on the MG as a whole.  For example, if I have a multimedia MG, I =
will want to set
      the priority of voice higher than video, and video higher than =
normal.  If I implement a
      Multilevel Pre-emption and Priority scheme, some calls will have =
higher priority than
      others.  The TOS/frame priority has to be per stream.
      =20
      Brian
        -----Original Message-----
        From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
        Sent: Tuesday, May 08, 2001 9:24 AM
        To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; =
megaco@fore.com
        Subject: RE: IP Type of Service


        Hi All,
        =20
        The default TOS type should be defined on the ROOT termination =
for the default TOS used for all media packets generated from the MG. =
There should be a method (might be through some property) of specifying =
stream level TOS bits.=20
        =20
        I'm interested to work on RSVP.=20
        =20
        Regards
        Madhubabu
          -----Original Message-----
          From: owner-megaco@pit.comms.marconi.com =
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
          Sent: Tuesday, May 08, 2001 8:10 AM
          To: 'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco@fore.com'
          Subject: RE: IP Type of Service


          TOS should not be ignored at the edge router if the router is =
configured to
          enable DiffServ. =20
          =20
          It would be pretty simple to create one package that had the =
appropriate controls for
          DiffServ and 802.1p.  RSVP needs it's own package because =
there is messaging,
          and you at least an event or two
          =20
          The former could be an enumeration: QosMarking, that had =
values None, TOS and
          FramePriority, plus another integer, Value.  That would =
suffice I think, although you
          could conceivably get more clever with DiffServ.
          =20
          Shall I write something up along those lines? =20
          =20
          RSVP takes some more work.  Any volunteers?
          =20
          Brian
            -----Original Message-----
            From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
            Sent: Monday, May 07, 2001 9:15 PM
            To: 'Chuong Nguyen'; 'megaco@fore.com'
            Subject: RE: IP Type of Service


            No such package has yet been defined.
            =20
            Various QOS architectures can be imagined.  Each would give =
rise to its own package, since the MGC-MG information flow would differ =
from one architecture to the next.  One question: unless the MG is =
itself the edge router, won't the ToS be ignored when the media packets =
reach the latter?
              -----Original Message-----
              From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
              Sent: Monday, May 07, 2001 5:14 PM
              To: 'megaco@fore.com'
              Subject: IP Type of Service


              All=20
              In MGCP, MGC can specify IP Type of Service to the MG.=20
              Do we have an equivalent in Megaco?=20

              Is there or has anyone defined a package for IP Type of =
Service?=20

              Thanks=20
              Chuong=20

--=20
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
               =20

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









    Assuming that the =
SDP is=20
extended to specify the TOS value for a stream, what should a MG do if =
this=20
parameter is missing in the SDP sent from MGC? I think the protocol =
should also=20
specify what should happen if TOS info is missing in the SDP =
received.=20



 


    If both of the above =
options are=20
available(MEGACO means of specifying TOS and SDP way of specifying TOS), =
the=20
protocol specified option should take precedence over the one specified =
in SDP,=20
as done for mode parameter.


 


    So, as =
pointed by=20
Madhu, I think we need


 


1). The capability to specify a =
default value=20
of TOS for the MG (either as a property of the root=20
termination or some other =
means).


2). The capability to specify the TOS =
value on per=20
stream basis.


 


Regards


Krishna G


 


  
----- Original Message ----- 

  From:=20
  Tom-PT Taylor 
  
To: 'Madhu Babu=20
  Brahmanapally' ; 'Rosen, Brian' ; 'Chuong Nguyen' ; megaco =


  
Sent: Tuesday, May 08, 2001 =
10:07=20
AM

  
Subject: RE: IP Type of =
Service

  


  
That=20
  makes sense.

  
    
-----Original Message-----
From: Madhu Babu =
Brahmanapally=20
    [mailto:madhubabu@kenetec.com]Sent:=20
    Tuesday, May 08, 2001 10:08 AM
To: 'Rosen, Brian'; Taylor, =
Tom-PT=20
    [NORSE:B881:EXCH]; 'Chuong Nguyen'; megaco
Subject: RE: IP =
Type of=20
    Service


    
Hi=20
    All,

    
Another suggestion. Why cant the SDP =
be=20
    extended to incorporate a TOS parameter/attribute so that all the=20
    protocols(SIP,Megaco,MGCP) that use SDP need not define extra=20
    properties/parameter for supporting this. 

    
 

    
Regards

    
Madhubabu

    

      
-----Original Message-----
From: owner-megaco@pit.comms=
.marconi.com=20
      [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of =
Rosen,=20
      Brian
Sent: Tuesday, May 08, 2001 9:24 AM
To: =
'Madhu=20
      Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen';=20
      megaco@fore.com
Subject: RE: IP Type of=20
      Service


      
I don't=20
      agree.  The TOS for a particular stream should be set on that =
stream,=20
      not

      
on the=20
      MG as a whole.  For example, if I have a multimedia MG, I =
will want=20
      to set

      
the=20
      priority of voice higher than video, and video higher than =
normal. =20
      If I implement a

      
Multilevel Pre-emption and Priority =
scheme, some=20
      calls will have higher priority than

      
others.  The TOS/frame priority =
has to be=20
      per stream.

      
 

      
Brian

      
        
-----Original Message-----
From: Madhu Babu=20
        Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: =
Tuesday,=20
        May 08, 2001 9:24 AM
To: 'Rosen, Brian'; 'Tom-PT =
Taylor';=20
        'Chuong Nguyen'; megaco@fore.com
Subject: RE: IP Type =
of=20
        Service


        
Hi All,

        
 

        
The default TOS type should be =
defined on the=20
        ROOT termination for the default TOS used for all media packets=20
        generated from the MG. There should be a method (might be =
through some=20
        property) of specifying stream level TOS bits. =


        
 

        
I'm interested to work on RSVP.=20
        

        
 

        
Regards

        
Madhubabu

        

          
-----Original Message-----
From:=20
          owner-megaco@pit.comms.marconi.com=20
          [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of =
Rosen,=20
          Brian
Sent: Tuesday, May 08, 2001 8:10 =
AM
To:=20
          'Tom-PT Taylor'; 'Chuong Nguyen'; =
'megaco@fore.com'
Subject:=20
          RE: IP Type of Service


          
TOS=20
          should not be ignored at the edge router if the router is =
configured=20
          to

          
enable DiffServ.  =


          
 

          
It=20
          would be pretty simple to create one package that had the =
appropriate=20
          controls for

          
DiffServ and 802.1p.  RSVP =
needs it's=20
          own package because there is messaging,

          
and=20
          you at least an event or two

          
 

          
The=20
          former could be an enumeration: QosMarking, that had values =
None, TOS=20
          and

          
FramePriority, plus another =
integer,=20
          Value.  That would suffice I think, although=20
          you

          
could conceivably get more clever =
with=20
          DiffServ.

          
 

          
Shall I write something up =
along those=20
          lines?  

          
 

          
RSVP takes some more work.  =
Any=20
          volunteers?

          
 

          
Brian

          
            
-----Original Message-----
From: Tom-PT =
Taylor=20
            [mailto:taylor@nortelnetworks.com]
Sent: Monday, =
May 07,=20
            2001 9:15 PM
To: 'Chuong Nguyen';=20
            'megaco@fore.com'
Subject: RE: IP Type of=20
            Service


            
No such package has yet been=20
            defined.

            
 

            
Various QOS architectures can be=20
            imagined.  Each would give rise to its own package, =
since the=20
            MGC-MG information flow would differ from one architecture =
to the=20
            next.  One question: unless the MG is itself the edge =
router,=20
            won't the ToS be ignored when the media packets reach the=20
            latter?

            
              
-----Original =
Message-----
From:=20
              Chuong Nguyen=20
              [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: =
Monday, May=20
              07, 2001 5:14 PM
To:=20
              'megaco@fore.com'
Subject: IP Type of=20
              Service

All=20
              
In MGCP, MGC can specify IP Type of Service =
to the=20
              MG. 
Do we have an equivalent in Megaco?=20
              
Is there or has anyone defined a package for =
IP Type of=20
              Service?=20
              
Thanks 
Chuong 
-- 
  Alcatel USA, =
Inc           &nbs=
p; Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas =
75075           =
Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc =
****
 =20
            =



------=_NextPart_000_0032_01C0D7AE.DC0FD3C0--



From owner-megaco@fore.com  Tue May  8 15:25:07 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05394
	for ; Tue, 8 May 2001 15:25:06 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA17990;
	Tue, 8 May 2001 15:18:10 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA19367
	for megaco-list; Tue, 8 May 2001 15:13:13 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA19355
	for ; Tue, 8 May 2001 15:13:11 -0400 (EDT)
Received: from mail.mediatrix.com (mail.mediatrix.com [205.237.248.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA17403
	for ; Tue, 8 May 2001 15:13:09 -0400 (EDT)
Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 8 May 2001 15:09:41 -0400
Message-ID: 
From: Steven Weisz 
To: "Megaco Mailing List (E-mail)" 
Subject: ABNF Question: digit maps
Date: Tue, 8 May 2001 15:09:38 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hi List,

I have a quick question concerning digit map embedded in a requested event.
Specifically, if you look at the ABNF the embedded digit map is defined as

eventDM = DigitMapToken (( EQUAL digitMapName ) / (LBRKT digitMapValue
RBRKT))

and a digit map descriptor is defined as:

digitMapDescriptor = DigitMapToken EQUAL (( LBRKT digitMapValue RBRKT ) / 
		         ( digitMapName [LBRKT digitMapValue RBRKT] ))

It obvious that they are very similar, as I believe was intended but there
is one thing that is bothering me in eventDM. That is it seems to me that
the EQUAL should be right after DigitMapToken as is the case in
digitMapDescriptor. So we would instead have:

eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT digitMapValue
RBRKT))

Does this make sense?

Thanks,

Steve



From owner-megaco@fore.com  Tue May  8 16:43:22 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07259
	for ; Tue, 8 May 2001 16:43:22 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA25833;
	Tue, 8 May 2001 16:36:03 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA11253
	for megaco-list; Tue, 8 May 2001 16:34:46 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA11236
	for ; Tue, 8 May 2001 16:34:42 -0400 (EDT)
Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA25656
	for ; Tue, 8 May 2001 16:34:39 -0400 (EDT)
Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6])
	by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id QAA11555;
	Tue, 8 May 2001 16:25:07 -0400 (EDT)
Subject: RE: IP Type of Service
To: "Rosen, Brian" 
Cc: megaco 
From: "Petros N. Mouchtaris" 
Date: Tue, 8 May 2001 16:25:31 -0400
Message-ID: 
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 05/08/2001 04:25:32 PM
MIME-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=85256A46006FBCCE8f9e8a93df938690918c85256A46006FBCCE"
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

--0__=85256A46006FBCCE8f9e8a93df938690918c85256A46006FBCCE
Content-type: text/plain; charset=us-ascii


Brian,

Actually there was a long discussion on this topic last year on the mailing
list i.e. whether MGC should be able to signal an MG which TOS bit to use.
The whole topic ended up being dropped. Check the archive for e-mails with
title "MG and DiffServ".

By the way, Flemming had volunteered to do some work but I assume it didn't
have high enough priority.

Excerpt from e-mail:

"Tom-PT Taylor wrote:

                    > You are correct that packages should be drawn up (and/or SDP defined) to
                    > allow QOS parameter setting.  Volunteers?

                    Sure - I can put a package proposal together.

                    -- Flemming

Petros





"Rosen, Brian"  on 05/08/2001 03:29:44 PM

To:   "'Tom-PT Taylor'" , "'Madhu Babu
      Brahmanapally'" , "Rosen, Brian"
      , "'Chuong Nguyen'"
      , megaco 
cc:    (bcc: Petros N. Mouchtaris/Telcordia)
Subject:  RE: IP Type of Service



I'll look into this.  I agree.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, May 08, 2001 10:07 AM
To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen'; megaco
Subject: RE: IP Type of Service


That makes sense.

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Tuesday, May 08, 2001 10:08 AM
To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B881:EXCH]; 'Chuong Nguyen';
megaco
Subject: RE: IP Type of Service


Hi All,
Another suggestion. Why cant the SDP be extended to incorporate a TOS
parameter/attribute so that all the protocols(SIP,Megaco,MGCP) that use SDP
need not define extra properties/parameter for supporting this.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Tuesday, May 08, 2001 9:24 AM
To: 'Madhu Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen';
megaco@fore.com
Subject: RE: IP Type of Service


I don't agree.  The TOS for a particular stream should be set on that
stream, not
on the MG as a whole.  For example, if I have a multimedia MG, I will want
to set
the priority of voice higher than video, and video higher than normal.  If
I
implement a
Multilevel Pre-emption and Priority scheme, some calls will have higher
priority than
others.  The TOS/frame priority has to be per stream.

Brian

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Tuesday, May 08, 2001 9:24 AM
To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; megaco@fore.com
Subject: RE: IP Type of Service


Hi All,

The default TOS type should be defined on the ROOT termination for the
default TOS used for all media packets generated from the MG. There should
be a method (might be through some property) of specifying stream level TOS
bits.

I'm interested to work on RSVP.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Tuesday, May 08, 2001 8:10 AM
To: 'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco@fore.com'
Subject: RE: IP Type of Service


TOS should not be ignored at the edge router if the router is configured to
enable DiffServ.

It would be pretty simple to create one package that had the appropriate
controls for
DiffServ and 802.1p.  RSVP needs it's own package because there is
messaging,
and you at least an event or two

The former could be an enumeration: QosMarking, that had values None, TOS
and
FramePriority, plus another integer, Value.  That would suffice I think,
although you
could conceivably get more clever with DiffServ.

Shall I write something up along those lines?

RSVP takes some more work.  Any volunteers?

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Monday, May 07, 2001 9:15 PM
To: 'Chuong Nguyen'; 'megaco@fore.com'
Subject: RE: IP Type of Service


No such package has yet been defined.

Various QOS architectures can be imagined.  Each would give rise to its own
package, since the MGC-MG information flow would differ from one
architecture to the next.  One question: unless the MG is itself the edge
router, won't the ToS be ignored when the media packets reach the latter?

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Monday, May 07, 2001 5:14 PM
To: 'megaco@fore.com'
Subject: IP Type of Service


All

In MGCP, MGC can specify IP Type of Service to the MG.
Do we have an equivalent in Megaco?


Is there or has anyone defined a package for IP Type of Service?


Thanks
Chuong

--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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



--0__=85256A46006FBCCE8f9e8a93df938690918c85256A46006FBCCE
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U
RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+DQoNCg0KPE1FVEEgY29udGVudD0i
TVNIVE1MIDUuMDAuMjkyMC4wIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWT4NCjxESVY+
PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsPjxTUEFOIGNsYXNzPTg0MjQwMTExOC0wODA1
MjAwMT5JJ2xsIGxvb2sgDQppbnRvIHRoaXMuJm5ic3A7IEkgYWdyZWUuPC9TUEFOPjwvRk9OVD48
L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsPjxTUEFOIA0KY2xhc3M9
ODQyNDAxMTE4LTA4MDUyMDAxPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U
IGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbD48U1BBTiANCmNsYXNzPTg0MjQwMTExOC0wODA1MjAw
MT5CcmlhbjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8QkxPQ0tRVU9URSANCnN0eWxlPSJCT1JERVIt
TEVGVDogIzAwMDBmZiAycHggc29saWQ7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdIVDog
MHB4OyBQQURESU5HLUxFRlQ6IDVweCI+DQogIDxESVYgYWxpZ249bGVmdCBjbGFzcz1PdXRsb29r
TWVzc2FnZUhlYWRlciBkaXI9bHRyPjxGT05UIGZhY2U9VGFob21hIA0KICBzaXplPTI+LS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+RnJvbTo8L0I+IFRvbS1QVCBUYXlsb3IgDQogIFtt
YWlsdG86dGF5bG9yQG5vcnRlbG5ldHdvcmtzLmNvbV08QlI+PEI+U2VudDo8L0I+IFR1ZXNkYXks
IE1heSAwOCwgMjAwMSAxMDowNyANCiAgQU08QlI+PEI+VG86PC9CPiAnTWFkaHUgQmFidSBCcmFo
bWFuYXBhbGx5JzsgJ1Jvc2VuLCBCcmlhbic7ICdDaHVvbmcgTmd1eWVuJzsgDQogIG1lZ2FjbzxC
Uj48Qj5TdWJqZWN0OjwvQj4gUkU6IElQIFR5cGUgb2YgU2VydmljZTxCUj48QlI+PC9ESVY+PC9G
T05UPg0KICA8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4g
Y2xhc3M9MjQ1NDcwNjE0LTA4MDUyMDAxPlRoYXQgDQogIG1ha2VzIHNlbnNlLjwvU1BBTj48L0ZP
TlQ+PC9ESVY+DQogIDxCTE9DS1FVT1RFIA0KICBzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwZmYg
MnB4IHNvbGlkOyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweDsgUEFERElORy1M
RUZUOiA1cHgiPg0KICAgIDxESVYgYWxpZ249bGVmdCBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRl
ciBkaXI9bHRyPjxGT05UIGZhY2U9VGFob21hIA0KICAgIHNpemU9Mj4tLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gTWFkaHUgQmFidSBCcmFobWFuYXBhbGx5IA0KICAg
IFttYWlsdG86bWFkaHViYWJ1QGtlbmV0ZWMuY29tXTxCUj48Qj5TZW50OjwvQj4gVHVlc2RheSwg
TWF5IDA4LCAyMDAxIDEwOjA4IA0KICAgIEFNPEJSPjxCPlRvOjwvQj4gJ1Jvc2VuLCBCcmlhbic7
IFRheWxvciwgVG9tLVBUIFtOT1JTRTpCODgxOkVYQ0hdOyAnQ2h1b25nIA0KICAgIE5ndXllbic7
IG1lZ2FjbzxCUj48Qj5TdWJqZWN0OjwvQj4gUkU6IElQIFR5cGUgb2YgDQogICAgU2VydmljZTxC
Uj48QlI+PC9ESVY+PC9GT05UPg0KICAgIDxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFy
aWFsIHNpemU9Mj48U1BBTiBjbGFzcz0wMjE1MTAzMTQtMDgwNTIwMDE+SGkgDQogICAgQWxsLDwv
U1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJp
YWwgc2l6ZT0yPjxTUEFOIA0KICAgIGNsYXNzPTAyMTUxMDMxNC0wODA1MjAwMT5Bbm90aGVyIHN1
Z2dlc3Rpb24uIFdoeSZuYnNwO2NhbnQgdGhlIFNEUCBiZSANCiAgICBleHRlbmRlZCB0byBpbmNv
cnBvcmF0ZSBhIFRPUyBwYXJhbWV0ZXIvYXR0cmlidXRlIHNvIHRoYXQgYWxsIHRoZSANCiAgICBw
cm90b2NvbHMoU0lQLE1lZ2FjbyxNR0NQKSB0aGF0IHVzZSBTRFAgbmVlZCBub3QgZGVmaW5lIGV4
dHJhIA0KICAgIHByb3BlcnRpZXMvcGFyYW1ldGVyIGZvciBzdXBwb3J0aW5nIHRoaXMuIDwvU1BB
Tj48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwg
c2l6ZT0yPjxTUEFOIA0KICAgIGNsYXNzPTAyMTUxMDMxNC0wODA1MjAwMT48L1NQQU4+PC9GT05U
PiZuYnNwOzwvRElWPg0KICAgIDxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsIHNp
emU9Mj48U1BBTiANCiAgICBjbGFzcz0wMjE1MTAzMTQtMDgwNTIwMDE+UmVnYXJkczwvU1BBTj48
L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6
ZT0yPjxTUEFOIA0KICAgIGNsYXNzPTAyMTUxMDMxNC0wODA1MjAwMT5NYWRodWJhYnU8L1NQQU4+
PC9GT05UPjwvRElWPg0KICAgIDxCTE9DS1FVT1RFIHN0eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+
DQogICAgICA8RElWIGFsaWduPWxlZnQgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgZGlyPWx0
cj48Rk9OVCBmYWNlPVRhaG9tYSANCiAgICAgIHNpemU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLTxCUj48Qj5Gcm9tOjwvQj4gDQogICAgICBvd25lci1tZWdhY29AcGl0LmNvbW1zLm1hcmNv
bmkuY29tIA0KICAgICAgW21haWx0bzpvd25lci1tZWdhY29AcGl0LmNvbW1zLm1hcmNvbmkuY29t
XTxCPk9uIEJlaGFsZiBPZiA8L0I+Um9zZW4sIA0KICAgICAgQnJpYW48QlI+PEI+U2VudDo8L0I+
IFR1ZXNkYXksIE1heSAwOCwgMjAwMSA5OjI0IEFNPEJSPjxCPlRvOjwvQj4gJ01hZGh1IA0KICAg
ICAgQmFidSBCcmFobWFuYXBhbGx5JzsgJ1RvbS1QVCBUYXlsb3InOyAnQ2h1b25nIE5ndXllbic7
IA0KICAgICAgbWVnYWNvQGZvcmUuY29tPEJSPjxCPlN1YmplY3Q6PC9CPiBSRTogSVAgVHlwZSBv
ZiANCiAgICAgIFNlcnZpY2U8QlI+PEJSPjwvRElWPjwvRk9OVD4NCiAgICAgIDxESVY+PEZPTlQg
Y29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsPjxTUEFOIGNsYXNzPTI2OTA2MjIxMy0wODA1MjAwMT5J
IGRvbid0IA0KICAgICAgYWdyZWUuJm5ic3A7IFRoZSBUT1MgZm9yIGEgcGFydGljdWxhciBzdHJl
YW0gc2hvdWxkIGJlIHNldCBvbiB0aGF0IHN0cmVhbSwgDQogICAgICBub3Q8L1NQQU4+PC9GT05U
PjwvRElWPg0KICAgICAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWw+PFNQQU4g
Y2xhc3M9MjY5MDYyMjEzLTA4MDUyMDAxPm9uIHRoZSANCiAgICAgIE1HIGFzIGEgd2hvbGUuJm5i
c3A7IEZvciBleGFtcGxlLCBpZiBJIGhhdmUgYSBtdWx0aW1lZGlhIE1HLCBJIHdpbGwgd2FudCAN
CiAgICAgIHRvIHNldDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgICA8RElWPjxGT05UIGNvbG9y
PSMwMDAwZmYgZmFjZT1BcmlhbD48U1BBTiBjbGFzcz0yNjkwNjIyMTMtMDgwNTIwMDE+dGhlIA0K
ICAgICAgcHJpb3JpdHkgb2Ygdm9pY2UgaGlnaGVyIHRoYW4gdmlkZW8sIGFuZCB2aWRlbyBoaWdo
ZXIgdGhhbiBub3JtYWwuJm5ic3A7IA0KICAgICAgSWYgSSBpbXBsZW1lbnQgYTwvU1BBTj48L0ZP
TlQ+PC9ESVY+DQogICAgICA8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbD48U1BB
TiANCiAgICAgIGNsYXNzPTI2OTA2MjIxMy0wODA1MjAwMT5NdWx0aWxldmVsIFByZS1lbXB0aW9u
IGFuZCBQcmlvcml0eSBzY2hlbWUsIHNvbWUgDQogICAgICBjYWxscyB3aWxsIGhhdmUgaGlnaGVy
IHByaW9yaXR5IHRoYW48L1NQQU4+PC9GT05UPjwvRElWPg0KICAgICAgPERJVj48Rk9OVCBjb2xv
cj0jMDAwMGZmIGZhY2U9QXJpYWw+PFNQQU4gDQogICAgICBjbGFzcz0yNjkwNjIyMTMtMDgwNTIw
MDE+b3RoZXJzLiZuYnNwOyBUaGUgVE9TL2ZyYW1lIHByaW9yaXR5IGhhcyB0byBiZSANCiAgICAg
IHBlciBzdHJlYW0uPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgY29sb3I9
IzAwMDBmZiBmYWNlPUFyaWFsPjxTUEFOIA0KICAgICAgY2xhc3M9MjY5MDYyMjEzLTA4MDUyMDAx
PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgICA8RElWPjxGT05UIGNvbG9yPSMwMDAw
ZmYgZmFjZT1BcmlhbD48U1BBTiANCiAgICAgIGNsYXNzPTI2OTA2MjIxMy0wODA1MjAwMT5Ccmlh
bjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgICA8QkxPQ0tRVU9URSANCiAgICAgIHN0eWxlPSJC
T1JERVItTEVGVDogIzAwMDBmZiAycHggc29saWQ7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1S
SUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweCI+DQogICAgICAgIDxESVYgYWxpZ249bGVmdCBj
bGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBkaXI9bHRyPjxGT05UIGZhY2U9VGFob21hIA0KICAg
ICAgICBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+RnJvbTo8L0I+IE1h
ZGh1IEJhYnUgDQogICAgICAgIEJyYWhtYW5hcGFsbHkgW21haWx0bzptYWRodWJhYnVAa2VuZXRl
Yy5jb21dPEJSPjxCPlNlbnQ6PC9CPiBUdWVzZGF5LCANCiAgICAgICAgTWF5IDA4LCAyMDAxIDk6
MjQgQU08QlI+PEI+VG86PC9CPiAnUm9zZW4sIEJyaWFuJzsgJ1RvbS1QVCBUYXlsb3InOyANCiAg
ICAgICAgJ0NodW9uZyBOZ3V5ZW4nOyBtZWdhY29AZm9yZS5jb208QlI+PEI+U3ViamVjdDo8L0I+
IFJFOiBJUCBUeXBlIG9mIA0KICAgICAgICBTZXJ2aWNlPEJSPjxCUj48L0RJVj48L0ZPTlQ+DQog
ICAgICAgIDxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiAN
CiAgICAgICAgY2xhc3M9Mjk5MTgxNjEzLTA4MDUyMDAxPkhpIEFsbCw8L1NQQU4+PC9GT05UPjwv
RElWPg0KICAgICAgICA8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+
PFNQQU4gDQogICAgICAgIGNsYXNzPTI5OTE4MTYxMy0wODA1MjAwMT48L1NQQU4+PC9GT05UPiZu
YnNwOzwvRElWPg0KICAgICAgICA8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBz
aXplPTI+PFNQQU4gDQogICAgICAgIGNsYXNzPTI5OTE4MTYxMy0wODA1MjAwMT5UaGUgZGVmYXVs
dCBUT1MgdHlwZSBzaG91bGQgYmUgZGVmaW5lZCBvbiB0aGUgDQogICAgICAgIFJPT1QgdGVybWlu
YXRpb24gZm9yIHRoZSBkZWZhdWx0IFRPUyB1c2VkIGZvciBhbGwgbWVkaWEgcGFja2V0cyANCiAg
ICAgICAgZ2VuZXJhdGVkIGZyb20gdGhlIE1HLiBUaGVyZSBzaG91bGQgYmUgYSBtZXRob2QgKG1p
Z2h0IGJlIHRocm91Z2ggc29tZSANCiAgICAgICAgcHJvcGVydHkpIG9mIHNwZWNpZnlpbmcgc3Ry
ZWFtIGxldmVsIFRPUyBiaXRzLiA8L1NQQU4+PC9GT05UPjwvRElWPg0KICAgICAgICA8RElWPjxG
T05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogICAgICAgIGNsYXNz
PTI5OTE4MTYxMy0wODA1MjAwMT48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICAgICAgICA8
RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogICAgICAg
IGNsYXNzPTI5OTE4MTYxMy0wODA1MjAwMT5JJ20gaW50ZXJlc3RlZCB0byB3b3JrIG9uIFJTVlAu
IA0KICAgICAgICA8L1NQQU4+PC9GT05UPjwvRElWPg0KICAgICAgICA8RElWPjxGT05UIGNvbG9y
PSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogICAgICAgIGNsYXNzPTI5OTE4MTYx
My0wODA1MjAwMT48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICAgICAgICA8RElWPjxGT05U
IGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogICAgICAgIGNsYXNzPTI5
OTE4MTYxMy0wODA1MjAwMT5SZWdhcmRzPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgICAgICAgPERJ
Vj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICAgICAgICBj
bGFzcz0yOTkxODE2MTMtMDgwNTIwMDE+TWFkaHViYWJ1PC9TUEFOPjwvRk9OVD48L0RJVj4NCiAg
ICAgICAgPEJMT0NLUVVPVEUgc3R5bGU9Ik1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICAgICAgICA8
RElWIGFsaWduPWxlZnQgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgZGlyPWx0cj48Rk9OVCBm
YWNlPVRhaG9tYSANCiAgICAgICAgICBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08
QlI+PEI+RnJvbTo8L0I+IA0KICAgICAgICAgIG93bmVyLW1lZ2Fjb0BwaXQuY29tbXMubWFyY29u
aS5jb20gDQogICAgICAgICAgW21haWx0bzpvd25lci1tZWdhY29AcGl0LmNvbW1zLm1hcmNvbmku
Y29tXTxCPk9uIEJlaGFsZiBPZiA8L0I+Um9zZW4sIA0KICAgICAgICAgIEJyaWFuPEJSPjxCPlNl
bnQ6PC9CPiBUdWVzZGF5LCBNYXkgMDgsIDIwMDEgODoxMCBBTTxCUj48Qj5Ubzo8L0I+IA0KICAg
ICAgICAgICdUb20tUFQgVGF5bG9yJzsgJ0NodW9uZyBOZ3V5ZW4nOyAnbWVnYWNvQGZvcmUuY29t
JzxCUj48Qj5TdWJqZWN0OjwvQj4gDQogICAgICAgICAgUkU6IElQIFR5cGUgb2YgU2VydmljZTxC
Uj48QlI+PC9ESVY+PC9GT05UPg0KICAgICAgICAgIDxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBm
YWNlPUFyaWFsPjxTUEFOIGNsYXNzPTM3NzUyMDExMi0wODA1MjAwMT5UT1MgDQogICAgICAgICAg
c2hvdWxkIG5vdCBiZSBpZ25vcmVkIGF0IHRoZSBlZGdlIHJvdXRlciBpZiB0aGUgcm91dGVyIGlz
IGNvbmZpZ3VyZWQgDQogICAgICAgICAgdG88L1NQQU4+PC9GT05UPjwvRElWPg0KICAgICAgICAg
IDxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsPjxTUEFOIA0KICAgICAgICAgIGNs
YXNzPTM3NzUyMDExMi0wODA1MjAwMT5lbmFibGUgRGlmZlNlcnYuJm5ic3A7IDwvU1BBTj48L0ZP
TlQ+PC9ESVY+DQogICAgICAgICAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWw+
PFNQQU4gDQogICAgICAgICAgY2xhc3M9Mzc3NTIwMTEyLTA4MDUyMDAxPjwvU1BBTj48L0ZPTlQ+
Jm5ic3A7PC9ESVY+DQogICAgICAgICAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJp
YWw+PFNQQU4gY2xhc3M9Mzc3NTIwMTEyLTA4MDUyMDAxPkl0IA0KICAgICAgICAgIHdvdWxkIGJl
IHByZXR0eSBzaW1wbGUgdG8gY3JlYXRlIG9uZSBwYWNrYWdlIHRoYXQgaGFkIHRoZSBhcHByb3By
aWF0ZSANCiAgICAgICAgICBjb250cm9scyBmb3I8L1NQQU4+PC9GT05UPjwvRElWPg0KICAgICAg
ICAgIDxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsPjxTUEFOIA0KICAgICAgICAg
IGNsYXNzPTM3NzUyMDExMi0wODA1MjAwMT5EaWZmU2VydiBhbmQgODAyLjFwLiZuYnNwOyBSU1ZQ
IG5lZWRzIGl0J3MgDQogICAgICAgICAgb3duIHBhY2thZ2UgYmVjYXVzZSB0aGVyZSBpcyBtZXNz
YWdpbmcsPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgICAgICAgICA8RElWPjxGT05UIGNvbG9yPSMw
MDAwZmYgZmFjZT1BcmlhbD48U1BBTiBjbGFzcz0zNzc1MjAxMTItMDgwNTIwMDE+YW5kIA0KICAg
ICAgICAgIHlvdSBhdCBsZWFzdCBhbiBldmVudCBvciB0d288L1NQQU4+PC9GT05UPjwvRElWPg0K
ICAgICAgICAgIDxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsPjxTUEFOIA0KICAg
ICAgICAgIGNsYXNzPTM3NzUyMDExMi0wODA1MjAwMT48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElW
Pg0KICAgICAgICAgIDxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsPjxTUEFOIGNs
YXNzPTM3NzUyMDExMi0wODA1MjAwMT5UaGUgDQogICAgICAgICAgZm9ybWVyIGNvdWxkIGJlIGFu
IGVudW1lcmF0aW9uOiBRb3NNYXJraW5nLCB0aGF0IGhhZCB2YWx1ZXMgTm9uZSwgVE9TIA0KICAg
ICAgICAgIGFuZDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgICAgICAgPERJVj48Rk9OVCBjb2xv
cj0jMDAwMGZmIGZhY2U9QXJpYWw+PFNQQU4gDQogICAgICAgICAgY2xhc3M9Mzc3NTIwMTEyLTA4
MDUyMDAxPkZyYW1lUHJpb3JpdHksIHBsdXMgYW5vdGhlciBpbnRlZ2VyLCANCiAgICAgICAgICBW
YWx1ZS4mbmJzcDsgVGhhdCB3b3VsZCBzdWZmaWNlIEkgdGhpbmssIGFsdGhvdWdoIA0KICAgICAg
ICAgIHlvdTwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgICAgICAgPERJVj48Rk9OVCBjb2xvcj0j
MDAwMGZmIGZhY2U9QXJpYWw+PFNQQU4gDQogICAgICAgICAgY2xhc3M9Mzc3NTIwMTEyLTA4MDUy
MDAxPmNvdWxkIGNvbmNlaXZhYmx5IGdldCBtb3JlIGNsZXZlciB3aXRoIA0KICAgICAgICAgIERp
ZmZTZXJ2LjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgICAgICAgPERJVj48Rk9OVCBjb2xvcj0j
MDAwMGZmIGZhY2U9QXJpYWw+PFNQQU4gDQogICAgICAgICAgY2xhc3M9Mzc3NTIwMTEyLTA4MDUy
MDAxPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgICAgICAgPERJVj48Rk9OVCBjb2xv
cj0jMDAwMGZmIGZhY2U9QXJpYWw+PFNQQU4gDQogICAgICAgICAgY2xhc3M9Mzc3NTIwMTEyLTA4
MDUyMDAxPlNoYWxsJm5ic3A7SSB3cml0ZSBzb21ldGhpbmcgdXAgYWxvbmcgdGhvc2UgDQogICAg
ICAgICAgbGluZXM/Jm5ic3A7IDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgICAgICAgPERJVj48
Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWw+PFNQQU4gDQogICAgICAgICAgY2xhc3M9Mzc3
NTIwMTEyLTA4MDUyMDAxPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgICAgICAgPERJ
Vj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWw+PFNQQU4gDQogICAgICAgICAgY2xhc3M9
Mzc3NTIwMTEyLTA4MDUyMDAxPlJTVlAgdGFrZXMgc29tZSBtb3JlIHdvcmsuJm5ic3A7IEFueSAN
CiAgICAgICAgICB2b2x1bnRlZXJzPzwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgICAgICAgPERJ
Vj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWw+PFNQQU4gDQogICAgICAgICAgY2xhc3M9
Mzc3NTIwMTEyLTA4MDUyMDAxPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgICAgICAg
PERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWw+PFNQQU4gDQogICAgICAgICAgY2xh
c3M9Mzc3NTIwMTEyLTA4MDUyMDAxPkJyaWFuPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgICAgICAg
ICA8QkxPQ0tRVU9URSANCiAgICAgICAgICBzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwZmYgMnB4
IHNvbGlkOyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweDsgUEFERElORy1MRUZU
OiA1cHgiPg0KICAgICAgICAgICAgPERJViBhbGlnbj1sZWZ0IGNsYXNzPU91dGxvb2tNZXNzYWdl
SGVhZGVyIGRpcj1sdHI+PEZPTlQgZmFjZT1UYWhvbWEgDQogICAgICAgICAgICBzaXplPTI+LS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+RnJvbTo8L0I+IFRvbS1QVCBUYXlsb3IgDQog
ICAgICAgICAgICBbbWFpbHRvOnRheWxvckBub3J0ZWxuZXR3b3Jrcy5jb21dPEJSPjxCPlNlbnQ6
PC9CPiBNb25kYXksIE1heSAwNywgDQogICAgICAgICAgICAyMDAxIDk6MTUgUE08QlI+PEI+VG86
PC9CPiAnQ2h1b25nIE5ndXllbic7IA0KICAgICAgICAgICAgJ21lZ2Fjb0Bmb3JlLmNvbSc8QlI+
PEI+U3ViamVjdDo8L0I+IFJFOiBJUCBUeXBlIG9mIA0KICAgICAgICAgICAgU2VydmljZTxCUj48
QlI+PC9ESVY+PC9GT05UPg0KICAgICAgICAgICAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZh
Y2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICAgICAgICAgICAgY2xhc3M9ODM0MDMwODAxLTA4MDUy
MDAxPk5vIHN1Y2ggcGFja2FnZSBoYXMgeWV0IGJlZW4gDQogICAgICAgICAgICBkZWZpbmVkLjwv
U1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgICAgICAgICA8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYg
ZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogICAgICAgICAgICBjbGFzcz04MzQwMzA4MDEtMDgw
NTIwMDE+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICAgICAgICAgIDxESVY+PEZPTlQg
Y29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgICAgICAgICAgIGNsYXNz
PTgzNDAzMDgwMS0wODA1MjAwMT5WYXJpb3VzIFFPUyBhcmNoaXRlY3R1cmVzIGNhbiBiZSANCiAg
ICAgICAgICAgIGltYWdpbmVkLiZuYnNwOyBFYWNoIHdvdWxkIGdpdmUgcmlzZSB0byBpdHMgb3du
IHBhY2thZ2UsIHNpbmNlIHRoZSANCiAgICAgICAgICAgIE1HQy1NRyBpbmZvcm1hdGlvbiBmbG93
IHdvdWxkIGRpZmZlciBmcm9tIG9uZSBhcmNoaXRlY3R1cmUgdG8gdGhlIA0KICAgICAgICAgICAg
bmV4dC4mbmJzcDsgT25lIHF1ZXN0aW9uOiB1bmxlc3MgdGhlIE1HIGlzIGl0c2VsZiB0aGUgZWRn
ZSByb3V0ZXIsIA0KICAgICAgICAgICAgd29uJ3QgdGhlIFRvUyBiZSBpZ25vcmVkIHdoZW4gdGhl
IG1lZGlhIHBhY2tldHMgcmVhY2ggdGhlIA0KICAgICAgICAgICAgbGF0dGVyPzwvU1BBTj48L0ZP
TlQ+PC9ESVY+DQogICAgICAgICAgICA8QkxPQ0tRVU9URSANCiAgICAgICAgICAgIHN0eWxlPSJC
T1JERVItTEVGVDogIzAwMDBmZiAycHggc29saWQ7IE1BUkdJTi1MRUZUOiA1cHg7IFBBRERJTkct
TEVGVDogNXB4Ij4NCiAgICAgICAgICAgICAgPERJViBhbGlnbj1sZWZ0IGNsYXNzPU91dGxvb2tN
ZXNzYWdlSGVhZGVyIGRpcj1sdHI+PEZPTlQgDQogICAgICAgICAgICAgIGZhY2U9VGFob21hIHNp
emU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gDQogICAgICAg
ICAgICAgIENodW9uZyBOZ3V5ZW4gDQogICAgICAgICAgICAgIFttYWlsdG86Q2h1b25nLk5ndXll
bkB1c2EuYWxjYXRlbC5jb21dPEJSPjxCPlNlbnQ6PC9CPiBNb25kYXksIE1heSANCiAgICAgICAg
ICAgICAgMDcsIDIwMDEgNToxNCBQTTxCUj48Qj5Ubzo8L0I+IA0KICAgICAgICAgICAgICAnbWVn
YWNvQGZvcmUuY29tJzxCUj48Qj5TdWJqZWN0OjwvQj4gSVAgVHlwZSBvZiANCiAgICAgICAgICAg
ICAgU2VydmljZTxCUj48QlI+PC9ESVY+PC9GT05UPkFsbCANCiAgICAgICAgICAgICAgPFA+SW4g
TUdDUCwgTUdDJm5ic3A7Y2FuIHNwZWNpZnkgSVAmbmJzcDtUeXBlIG9mIFNlcnZpY2UgdG8gdGhl
IA0KICAgICAgICAgICAgICBNRy4gPEJSPkRvIHdlIGhhdmUgYW4gZXF1aXZhbGVudCBpbiBNZWdh
Y28/IA0KICAgICAgICAgICAgICA8UD5JcyB0aGVyZSBvciBoYXMgYW55b25lIGRlZmluZWQgYSBw
YWNrYWdlIGZvciBJUCZuYnNwO1R5cGUgb2YgDQogICAgICAgICAgICAgIFNlcnZpY2U/IA0KICAg
ICAgICAgICAgICA8UD5UaGFua3MgPEJSPkNodW9uZyA8UFJFPi0tJm5ic3A7DQombmJzcDsgQWxj
YXRlbCBVU0EsIEluYyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJbnRlcm5ldDogQ2h1b25nLk5ndXllbkB1c2Eu
YWxjYXRlbC5jb20NCiZuYnNwOyAxMDAwIENvaXQgUm9hZCBQbGFubywgVGV4YXMgNzUwNzUmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
UGhvbmU6Jm5ic3A7Jm5ic3A7Jm5ic3A7ICg5NzIpIDUxOS00NjEzDQombmJzcDsgKioqKiBUaGUg
b3BpbmlvbnMgZXhwcmVzc2VkIGFyZSBub3QgdGhvc2Ugb2YgQWxjYXRlbCBVU0EsIEluYyAqKioq
PC9QUkU+Jm5ic3A7IA0KICAgICAgICAgICAgPC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT48L0JM
T0NLUVVPVEU+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+PC9CTE9DS1FV
T1RFPjwvQk9EWT48L0hUTUw+DQoNCg==

--0__=85256A46006FBCCE8f9e8a93df938690918c85256A46006FBCCE--



From owner-megaco@fore.com  Tue May  8 17:14:38 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07888
	for ; Tue, 8 May 2001 17:14:37 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA19493;
	Tue, 8 May 2001 15:31:05 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA24129
	for megaco-list; Tue, 8 May 2001 15:29:48 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24114
	for ; Tue, 8 May 2001 15:29:46 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 8 May 2001 15:29:29 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F58F@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Tom-PT Taylor'" ,
        "'Madhu Babu Brahmanapally'" ,
        "Rosen, Brian"
	 ,
        "'Chuong Nguyen'"
	 ,
        megaco 
Subject: RE: IP Type of Service
Date: Tue, 8 May 2001 15:29:44 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0D7F5.3C856B70"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D7F5.3C856B70
Content-Type: text/plain;
	charset="iso-8859-1"

I'll look into this.  I agree.
 
Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, May 08, 2001 10:07 AM
To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen'; megaco
Subject: RE: IP Type of Service


That makes sense.

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Tuesday, May 08, 2001 10:08 AM
To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B881:EXCH]; 'Chuong Nguyen';
megaco
Subject: RE: IP Type of Service


Hi All,
Another suggestion. Why cant the SDP be extended to incorporate a TOS
parameter/attribute so that all the protocols(SIP,Megaco,MGCP) that use SDP
need not define extra properties/parameter for supporting this. 
 
Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Tuesday, May 08, 2001 9:24 AM
To: 'Madhu Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen';
megaco@fore.com
Subject: RE: IP Type of Service


I don't agree.  The TOS for a particular stream should be set on that
stream, not
on the MG as a whole.  For example, if I have a multimedia MG, I will want
to set
the priority of voice higher than video, and video higher than normal.  If I
implement a
Multilevel Pre-emption and Priority scheme, some calls will have higher
priority than
others.  The TOS/frame priority has to be per stream.
 
Brian

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Tuesday, May 08, 2001 9:24 AM
To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; megaco@fore.com
Subject: RE: IP Type of Service


Hi All,
 
The default TOS type should be defined on the ROOT termination for the
default TOS used for all media packets generated from the MG. There should
be a method (might be through some property) of specifying stream level TOS
bits. 
 
I'm interested to work on RSVP. 
 
Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Tuesday, May 08, 2001 8:10 AM
To: 'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco@fore.com'
Subject: RE: IP Type of Service


TOS should not be ignored at the edge router if the router is configured to
enable DiffServ.  
 
It would be pretty simple to create one package that had the appropriate
controls for
DiffServ and 802.1p.  RSVP needs it's own package because there is
messaging,
and you at least an event or two
 
The former could be an enumeration: QosMarking, that had values None, TOS
and
FramePriority, plus another integer, Value.  That would suffice I think,
although you
could conceivably get more clever with DiffServ.
 
Shall I write something up along those lines?  
 
RSVP takes some more work.  Any volunteers?
 
Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Monday, May 07, 2001 9:15 PM
To: 'Chuong Nguyen'; 'megaco@fore.com'
Subject: RE: IP Type of Service


No such package has yet been defined.
 
Various QOS architectures can be imagined.  Each would give rise to its own
package, since the MGC-MG information flow would differ from one
architecture to the next.  One question: unless the MG is itself the edge
router, won't the ToS be ignored when the media packets reach the latter?

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Monday, May 07, 2001 5:14 PM
To: 'megaco@fore.com'
Subject: IP Type of Service


All 

In MGCP, MGC can specify IP Type of Service to the MG. 
Do we have an equivalent in Megaco? 


Is there or has anyone defined a package for IP Type of Service? 


Thanks 
Chuong 

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


------_=_NextPart_001_01C0D7F5.3C856B70
Content-Type: text/html;
	charset="iso-8859-1"









I'll look 
into this.  I agree.


 


Brian



  
-----Original Message-----
From: Tom-PT Taylor 
  [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, May 08, 2001 10:07 
  AM
To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen'; 
  megaco
Subject: RE: IP Type of Service


  
That 
  makes sense.

  

    
-----Original Message-----
From: Madhu Babu Brahmanapally 
    [mailto:madhubabu@kenetec.com]
Sent: Tuesday, May 08, 2001 10:08 
    AM
To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B881:EXCH]; 'Chuong 
    Nguyen'; megaco
Subject: RE: IP Type of 
    Service


    
Hi 
    All,

    
Another suggestion. Why cant the SDP be 
    extended to incorporate a TOS parameter/attribute so that all the 
    protocols(SIP,Megaco,MGCP) that use SDP need not define extra 
    properties/parameter for supporting this. 

    
 

    
Regards

    
Madhubabu

    

      
-----Original Message-----
From: 
      owner-megaco@pit.comms.marconi.com 
      [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, 
      Brian
Sent: Tuesday, May 08, 2001 9:24 AM
To: 'Madhu 
      Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen'; 
      megaco@fore.com
Subject: RE: IP Type of 
      Service


      
I don't 
      agree.  The TOS for a particular stream should be set on that stream, 
      not

      
on the 
      MG as a whole.  For example, if I have a multimedia MG, I will want 
      to set

      
the 
      priority of voice higher than video, and video higher than normal.  
      If I implement a

      
Multilevel Pre-emption and Priority scheme, some 
      calls will have higher priority than

      
others.  The TOS/frame priority has to be 
      per stream.

      
 

      
Brian

      

        
-----Original Message-----
From: Madhu Babu 
        Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Tuesday, 
        May 08, 2001 9:24 AM
To: 'Rosen, Brian'; 'Tom-PT Taylor'; 
        'Chuong Nguyen'; megaco@fore.com
Subject: RE: IP Type of 
        Service


        
Hi All,

        
 

        
The default TOS type should be defined on the 
        ROOT termination for the default TOS used for all media packets 
        generated from the MG. There should be a method (might be through some 
        property) of specifying stream level TOS bits. 

        
 

        
I'm interested to work on RSVP. 
        

        
 

        
Regards

        
Madhubabu

        

          
-----Original Message-----
From: 
          owner-megaco@pit.comms.marconi.com 
          [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, 
          Brian
Sent: Tuesday, May 08, 2001 8:10 AM
To: 
          'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco@fore.com'
Subject: 
          RE: IP Type of Service


          
TOS 
          should not be ignored at the edge router if the router is configured 
          to

          
enable DiffServ.  

          
 

          
It 
          would be pretty simple to create one package that had the appropriate 
          controls for

          
DiffServ and 802.1p.  RSVP needs it's 
          own package because there is messaging,

          
and 
          you at least an event or two

          
 

          
The 
          former could be an enumeration: QosMarking, that had values None, TOS 
          and

          
FramePriority, plus another integer, 
          Value.  That would suffice I think, although 
          you

          
could conceivably get more clever with 
          DiffServ.

          
 

          
Shall I write something up along those 
          lines?  

          
 

          
RSVP takes some more work.  Any 
          volunteers?

          
 

          
Brian

          

            
-----Original Message-----
From: Tom-PT Taylor 
            [mailto:taylor@nortelnetworks.com]
Sent: Monday, May 07, 
            2001 9:15 PM
To: 'Chuong Nguyen'; 
            'megaco@fore.com'
Subject: RE: IP Type of 
            Service


            
No such package has yet been 
            defined.

            
 

            
Various QOS architectures can be 
            imagined.  Each would give rise to its own package, since the 
            MGC-MG information flow would differ from one architecture to the 
            next.  One question: unless the MG is itself the edge router, 
            won't the ToS be ignored when the media packets reach the 
            latter?

            

              
-----Original Message-----
From: 
              Chuong Nguyen 
              [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Monday, May 
              07, 2001 5:14 PM
To: 
              'megaco@fore.com'
Subject: IP Type of 
              Service

All 
              
In MGCP, MGC can specify IP Type of Service to the 
              MG. 
Do we have an equivalent in Megaco? 
              
Is there or has anyone defined a package for IP Type of 
              Service? 
              
Thanks 
Chuong 
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  
            


------_=_NextPart_001_01C0D7F5.3C856B70--


From owner-megaco@fore.com  Wed May  9 02:05:13 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28947
	for ; Wed, 9 May 2001 02:05:12 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA20904;
	Wed, 9 May 2001 01:46:17 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA06553
	for megaco-list; Wed, 9 May 2001 01:44:15 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA06458
	for ; Wed, 9 May 2001 01:44:12 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA20439
	for ; Wed, 9 May 2001 01:43:58 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id PAA06589;
	Wed, 9 May 2001 15:41:05 +1000 (EST)
Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA04859;
	Wed, 9 May 2001 15:41:03 +1000 (EST)
Message-ID: <3AF8D867.591A42A3@ericsson.com>
Date: Wed, 09 May 2001 15:40:55 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Petros N. Mouchtaris" 
CC: "Rosen, Brian" , megaco ,
        SG16 ,
        Oskar vanDeventer 
Subject: Re: IP Type of Service
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

I think that any work on QoS parameters should be aligned with the work
occuring in ETSI Tiphon, ITU SG16, ITU SG11 etc. There's been a
considerable amount of effort in trying to come up with common
parameters for QoS. Any solution should tap into this.

Cheers, Christian

"Petros N. Mouchtaris" wrote:
> 
> Brian,
> 
> Actually there was a long discussion on this topic last year on the mailing
> list i.e. whether MGC should be able to signal an MG which TOS bit to use.
> The whole topic ended up being dropped. Check the archive for e-mails with
> title "MG and DiffServ".
> 
> By the way, Flemming had volunteered to do some work but I assume it didn't
> have high enough priority.
> 
> Excerpt from e-mail:
> 
> "Tom-PT Taylor wrote:
> 
>                     > You are correct that packages should be drawn up (and/or SDP defined) to
>                     > allow QOS parameter setting.  Volunteers?
> 
>                     Sure - I can put a package proposal together.
> 
>                     -- Flemming
> 
> Petros
> 
> "Rosen, Brian"  on 05/08/2001 03:29:44 PM
> 
> To:   "'Tom-PT Taylor'" , "'Madhu Babu
>       Brahmanapally'" , "Rosen, Brian"
>       , "'Chuong Nguyen'"
>       , megaco 
> cc:    (bcc: Petros N. Mouchtaris/Telcordia)
> Subject:  RE: IP Type of Service
> 
> I'll look into this.  I agree.
> 
> Brian
> 
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Tuesday, May 08, 2001 10:07 AM
> To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen'; megaco
> Subject: RE: IP Type of Service
> 
> That makes sense.
> 
> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Tuesday, May 08, 2001 10:08 AM
> To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B881:EXCH]; 'Chuong Nguyen';
> megaco
> Subject: RE: IP Type of Service
> 
> Hi All,
> Another suggestion. Why cant the SDP be extended to incorporate a TOS
> parameter/attribute so that all the protocols(SIP,Megaco,MGCP) that use SDP
> need not define extra properties/parameter for supporting this.
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> Sent: Tuesday, May 08, 2001 9:24 AM
> To: 'Madhu Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen';
> megaco@fore.com
> Subject: RE: IP Type of Service
> 
> I don't agree.  The TOS for a particular stream should be set on that
> stream, not
> on the MG as a whole.  For example, if I have a multimedia MG, I will want
> to set
> the priority of voice higher than video, and video higher than normal.  If
> I
> implement a
> Multilevel Pre-emption and Priority scheme, some calls will have higher
> priority than
> others.  The TOS/frame priority has to be per stream.
> 
> Brian
> 
> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Tuesday, May 08, 2001 9:24 AM
> To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; megaco@fore.com
> Subject: RE: IP Type of Service
> 
> Hi All,
> 
> The default TOS type should be defined on the ROOT termination for the
> default TOS used for all media packets generated from the MG. There should
> be a method (might be through some property) of specifying stream level TOS
> bits.
> 
> I'm interested to work on RSVP.
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> Sent: Tuesday, May 08, 2001 8:10 AM
> To: 'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco@fore.com'
> Subject: RE: IP Type of Service
> 
> TOS should not be ignored at the edge router if the router is configured to
> enable DiffServ.
> 
> It would be pretty simple to create one package that had the appropriate
> controls for
> DiffServ and 802.1p.  RSVP needs it's own package because there is
> messaging,
> and you at least an event or two
> 
> The former could be an enumeration: QosMarking, that had values None, TOS
> and
> FramePriority, plus another integer, Value.  That would suffice I think,
> although you
> could conceivably get more clever with DiffServ.
> 
> Shall I write something up along those lines?
> 
> RSVP takes some more work.  Any volunteers?
> 
> Brian
> 
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Monday, May 07, 2001 9:15 PM
> To: 'Chuong Nguyen'; 'megaco@fore.com'
> Subject: RE: IP Type of Service
> 
> No such package has yet been defined.
> 
> Various QOS architectures can be imagined.  Each would give rise to its own
> package, since the MGC-MG information flow would differ from one
> architecture to the next.  One question: unless the MG is itself the edge
> router, won't the ToS be ignored when the media packets reach the latter?
> 
> -----Original Message-----
> From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> Sent: Monday, May 07, 2001 5:14 PM
> To: 'megaco@fore.com'
> Subject: IP Type of Service
> 
> All
> 
> In MGCP, MGC can specify IP Type of Service to the MG.
> Do we have an equivalent in Megaco?
> 
> Is there or has anyone defined a package for IP Type of Service?
> 
> Thanks
> Chuong
> 
> --
> 
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
> 
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
> 
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
> 
>   ------------------------------------------------------------------------
>                Name: att1.htm
>    att1.htm    Type: Hypertext Markup Language (text/html)
>            Encoding: base64


From owner-megaco@fore.com  Wed May  9 02:11:16 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00672
	for ; Wed, 9 May 2001 02:11:16 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA21158;
	Wed, 9 May 2001 01:50:56 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA07376
	for megaco-list; Wed, 9 May 2001 01:50:25 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA07372
	for ; Wed, 9 May 2001 01:50:24 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA21075
	for ; Wed, 9 May 2001 01:50:20 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id PAA06508;
	Wed, 9 May 2001 15:40:13 +1000 (EST)
Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA04598;
	Wed, 9 May 2001 15:40:11 +1000 (EST)
Message-ID: <3AF8D832.E727C159@ericsson.com>
Date: Wed, 09 May 2001 15:40:02 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco ietf 
CC: Tom-PT Taylor , Glen Freundlich 
Subject: Implementors' Guide Update Editor's last Call
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day all,

The H.248 Series Implementors' Guide has been updated to revision 6.

It can be found at:
ftp://standard.pictel.com/avc-site/Incoming/
files:
TD-xxx_H248_Implementors_Additions_v6.doc
TD-xxx_H248_Implementors_Additions_v6.pdf

This revision contains the Approved Implementors' Guide and the
Implementors' Guide Additions v5 with some other changes. The changes
are detailed in the document.

This is an editors' last call. Please provide comments on this draft by
Monday the 13th as a revision 7 will be stored on the 14th and sent to
SG16 for approval at the Porto Seguro meeting. If you have a comment on
a correction please provide the detailed solution or exact changes that
you would like to see.

Cheers, Christian


From owner-megaco@fore.com  Wed May  9 04:59:08 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02222
	for ; Wed, 9 May 2001 04:59:07 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA28441;
	Wed, 9 May 2001 04:49:42 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id EAA09672
	for megaco-list; Wed, 9 May 2001 04:47:41 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA09656
	for ; Wed, 9 May 2001 04:47:39 -0400 (EDT)
Received: from brahma01.netbrahma.com ([164.164.70.67])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA28274
	for ; Wed, 9 May 2001 04:47:30 -0400 (EDT)
Received: by BRAHMA01 with Internet Mail Service (5.5.2653.19)
	id ; Wed, 9 May 2001 14:17:23 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D7106FAC@BRAHMA01>
From: Atanu Mondal 
To: "'megaco@fore.com'" 
Date: Wed, 9 May 2001 14:17:22 +0530 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hi all,
I need some clarifications over sending msg's over TCP. Should RFC 1006
should be implemented totally over TCP, or only the messages are formed into
TPKT packets with header mentioned in RFC1006 and sent over the TCP.

Also , do we require any TCP server to run on the gateway... i.e at any
point of time can a need arise where a call agent wants to make a connection
to a gateway.

Regards
Atanu


From owner-megaco@fore.com  Wed May  9 05:31:02 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02648
	for ; Wed, 9 May 2001 05:31:02 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA00428;
	Wed, 9 May 2001 05:25:17 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA14875
	for megaco-list; Wed, 9 May 2001 05:24:39 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA14853
	for ; Wed, 9 May 2001 05:24:36 -0400 (EDT)
Received: from gatekeeper.cam.virata.com (gatekeeper.virata.com [194.129.40.2])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA00317
	for ; Wed, 9 May 2001 05:24:34 -0400 (EDT)
Received: from boletus.cam.virata.com (boletus.cam.virata.com [192.168.219.9])
	by gatekeeper.cam.virata.com (8.9.3/8.8.5) with ESMTP id KAA16639
	for ; Wed, 9 May 2001 10:24:40 +0100
Received: from fileserv.ta.virata.com (fileserv.ta.virata.com [10.65.0.254])
	by boletus.cam.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id KAA17236
	for ; Wed, 9 May 2001 10:24:28 +0100
Received: by fileserv.ta.virata.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 9 May 2001 11:25:50 +0200
Message-ID: 
From: "Ternovsky, Igor" 
To: megaco@fore.com
Cc: "Simons, Jay" 
Subject: MEGACO interop?
Date: Wed, 9 May 2001 11:25:47 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="windows-1252"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


Hi all,

Is MEGACO interop planned in the coming months?

Thanks,
Igor
==================================
Igor Ternovsky         	iternovsky@virata.com
Virata Israel          	tel. +972 9 9717414
2 Haharoshet Street   
Kfar-Saba, 44641, Israel 



From owner-megaco@fore.com  Wed May  9 08:03:42 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04372
	for ; Wed, 9 May 2001 08:03:42 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA06528;
	Wed, 9 May 2001 07:56:42 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA04402
	for megaco-list; Wed, 9 May 2001 07:54:31 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA04356
	for ; Wed, 9 May 2001 07:54:24 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 9 May 2001 07:54:03 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F5A0@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Ternovsky, Igor'" , megaco@fore.com
Cc: "Simons, Jay" 
Subject: RE: MEGACO interop?
Date: Wed, 9 May 2001 07:54:20 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="windows-1252"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Yes.  I had planned early August, but IETF-51 is August 5-10th.
I'm not sure yet if it will be earlier or later.
It will be held at UNH, as the first two will.

Brian

> -----Original Message-----
> From: Ternovsky, Igor [mailto:ITernovsky@virata.com]
> Sent: Wednesday, May 09, 2001 5:26 AM
> To: megaco@fore.com
> Cc: Simons, Jay
> Subject: MEGACO interop?
> 
> 
> 
> Hi all,
> 
> Is MEGACO interop planned in the coming months?
> 
> Thanks,
> Igor
> ==================================
> Igor Ternovsky         	iternovsky@virata.com
> Virata Israel          	tel. +972 9 9717414
> 2 Haharoshet Street   
> Kfar-Saba, 44641, Israel 
> 


From owner-megaco@fore.com  Wed May  9 08:05:26 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04406
	for ; Wed, 9 May 2001 08:05:25 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA06954;
	Wed, 9 May 2001 07:58:28 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA05886
	for megaco-list; Wed, 9 May 2001 07:57:20 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA05857
	for ; Wed, 9 May 2001 07:57:15 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 9 May 2001 07:56:56 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F5A1@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Atanu Mondal'" ,
        "'megaco@fore.com'"
	 
Subject: RE: 
Date: Wed, 9 May 2001 07:57:13 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

You only need TPKT.  See the archives for messages
about this topic - common errors in implementation
were noted at the interop events.

We do NOT require a TCP server at the gateway.
This is one reason the MG starts the control
association negotiation.  You open a bidirectional
TCP channel, and it stays up for the duration of
the control association.  All messages go through
that channel.

Brian

> -----Original Message-----
> From: Atanu Mondal [mailto:ATANUM@netbrahma.com]
> Sent: Wednesday, May 09, 2001 4:47 AM
> To: 'megaco@fore.com'
> Subject: 
> 
> 
> Hi all,
> I need some clarifications over sending msg's over TCP. 
> Should RFC 1006
> should be implemented totally over TCP, or only the messages 
> are formed into
> TPKT packets with header mentioned in RFC1006 and sent over the TCP.
> 
> Also , do we require any TCP server to run on the gateway... 
> i.e at any
> point of time can a need arise where a call agent wants to 
> make a connection
> to a gateway.
> 
> Regards
> Atanu
> 


From owner-megaco@fore.com  Wed May  9 11:01:56 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10415
	for ; Wed, 9 May 2001 11:01:51 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23750;
	Wed, 9 May 2001 10:54:45 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA26142
	for megaco-list; Wed, 9 May 2001 10:53:04 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26134
	for ; Wed, 9 May 2001 10:53:03 -0400 (EDT)
Received: from small-3.inet.it ([212.239.0.39])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23511
	for ; Wed, 9 May 2001 10:53:00 -0400 (EDT)
Received: (from trusted@localhost)
	by small-3.inet.it (8.11.1/8.11.1) id f49Er1U93960
	for ; Wed, 9 May 2001 16:53:01 +0200
Received: from unknown(212.141.41.126) by small-3.inet.it via I-SMTP
	id queue/s-212.141.41.126-flZ3ya; Wed May  9 16:53:00 2001
From: "Dolman Aradori" 
To: 
Subject: Information about call set up
Date: Wed, 9 May 2001 16:55:00 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_002C_01C0D8A8.C8C36D90"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-MS-TNEF-Correlator: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_002C_01C0D8A8.C8C36D90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Good evening. I hope that someone of you can help me. 
Suppose that there is a RGw in a costumer site that manages two or more POTS interfaces and I want
to call a telephone attested to this device. How a MGC can determine the destination terminal of the
connection??
I mean, MGC analyses the digits and so it can determines that the RGw manages the called number
pool. But, is the same device that individuate the analog termination that corresponds to the called
number?? If not, which device has to individuate the POTS interface at which the called terminal is
attested??

Could someone provide me a link to documentation that talks about this problem??

Thanks for the help,

	Dolman Aradori

______________________________

 Dolman Aradori
 Consultant

 ICT Consulting
 Via Vittor Pisani, 22
 20124 Milano 

 Phone: +39 02 67642245
 Fax: +39 0267642243
 Mobile: +39 335 7505653
______________________________





------=_NextPart_000_002C_01C0D8A8.C8C36D90
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Disposition: attachment;
	filename="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IgAOAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHBQAJABAANgAAAAMALwEB
A5AGABwHAAAiAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB
AAAAHgAAAEluZm9ybWF0aW9uIGFib3V0IGNhbGwgc2V0IHVwAAAAAgFxAAEAAAAWAAAAAcDYmAT6
7RAL5kRLEdWtYwBQBJI7bAAAAgEdDAEAAAAVAAAAU01UUDpBUkFET1JJQElDVEMuSVQAAAAACwAB
DgAAAABAAAYOADRs4ZfYwAECAQoOAQAAABgAAAAAAAAAegbEkCAV1BGkeQAAhh6cIsKAAAALAB8O
AQAAAAIBCRABAAAAMAMAACwDAABLBQAATFpGdQRi7TwDAAoAcmNwZzEyNRYyAPgLYG4OEDAzM08B
9wKkA2MCAGNoCsBz8GV0MCAHbQKDAFAD1b8HEwKDDlAD1BDJE0V9CoGSdgiQd2sLgGQ0DGAOYwBQ
CwMLtDQgR28xBHAgZXYJ8AuAZy4AIEkgaG9wZSDWdBDwBUBzA3BlAiAYoJBvZiB5CGAgYwOR4Ghl
bHAgB4AYMAqiwQqAU3VwcG8RIBi0TxjABJAYoAQAIGEH8EePB+ALgByBBaBzdHUHgJsFwACQdBil
A4FhZweReHR3bxmABcAEYBwxUJxPVAXwC4Ad8HJmANDvB5EAcBegGFB3AHAb4R8QHRoAbAMgHJAd
8GxlcP8YcBlhGOAd8B1gCYAhUhjAnxxhAQAVwCBwGDBIbwfgcRyQTUdDGfMBACAhbX8LgBiiGKAB
AB1gC4AY4Gl/AiAh8SVSB0AZgiWyBaBu5RlgYyZiPz8a1BhQB4DNAHAsJIMegWx5ESAe0fklwmln
HeAglBkQHFAFQP8k2yoCG9Qcox53J4IhoSMBem4dgGIdoRtgBvAYMEKcdXQpMBxhJbJzYQeAlyOl
GLQWEWkVwGR1GODzJZQpkm9nJqYmZBjSBaH9CXBzG2AWIB7RI0It3ShQ0xhAGaBuby9RdyNwEOD/
MDYQ8DQjMQ4fvCKRNiU0eb8mtxxiIrUoVhrUCFFsKvJ9GTRwA2AxQRigMBEckGzFC4BrIVJkb2Md
gQIw8zLZAZBsaxxxBuAvQCNU0z2hAmBlbTvsVBDwPpDfBCACEAXAJbIaQiw8CgyC3CBEBvADggcQ
YT7wBRDvPAUSowwBGuNfRv9HykPLjQ8ENAwSE9MxOCADMPcPBhKRRM5iC8VJTQCgSlT+NkrNCFAA
gDzgAZACMAxAj0y7PBRKMUqTSUNUT4bvGAFMnAOyToFWBzBUIQJArQWxUAQAAHBpKTAyDlDvU3QB
0A4gF1BNAxAAcB8QBzwKH6AiUjogKzM5ACAwMiA2NzY0iVVgNDVTZUZheFfm91h1S2BTdE1BUAMQ
V9UPYAA1IDc1MDU2Nf9LYUZvXZ9IjxbmQ8sa4xWBAgBhoAsAAYAIIAYAAAAAAMAAAAAAAABGAAAA
AAOFAAAAAAAAAwADgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAeACCAGAAAAAADAAAAA
AAAARgAAAABShQAAfW4BAB4ACYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADkuMAAL
AA2ACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsAOoAIIAYAAAAAAMAAAAAAAABGAAAAAA6F
AAAAAAAAAwA8gAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADAD2ACCAGAAAAAADAAAAAAAAA
RgAAAAAYhQAAAAAAAAsAW4AIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwBcgAggBgAAAAAA
wAAAAAAAAEYAAAAAAYUAAAAAAAACAfgPAQAAABAAAAB6BsSQIBXUEaR5AACGHpwiAgH6DwEAAAAQ
AAAAegbEkCAV1BGkeQAAhh6cIgIB+w8BAAAAkQAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQ
UlguRExMAAAAAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XFdJTk5UXFByb2ZpbGVzXGFyYWRvcmlc
TG9jYWwgU2V0dGluZ3NcQXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0bG9va1xvdXRsb29r
LnBzdAAAAAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAvAAAAPE5FQkJLRUhKSEtBR0VDSU9MTURI
QUVFRENKQUEuYXJhZG9yaUBpY3RjLml0PgAAAwAGEEK4aTADAAcQsAIAAAMAEBAAAAAAAwAREB4A
AAAeAAgQAQAAAGUAAABHT09ERVZFTklOR0lIT1BFVEhBVFNPTUVPTkVPRllPVUNBTkhFTFBNRVNV
UFBPU0VUSEFUVEhFUkVJU0FSR1dJTkFDT1NUVU1FUlNJVEVUSEFUTUFOQUdFU1RXT09STU9SRVBP
AAAAALu7

------=_NextPart_000_002C_01C0D8A8.C8C36D90--



From owner-megaco@fore.com  Wed May  9 11:27:41 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11958
	for ; Wed, 9 May 2001 11:27:41 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26535;
	Wed, 9 May 2001 11:20:27 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA04321
	for megaco-list; Wed, 9 May 2001 11:19:38 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA04314;
	Wed, 9 May 2001 11:19:36 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26353;
	Wed, 9 May 2001 11:19:33 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACH06478;
	Wed, 9 May 2001 11:19:30 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: , 
Subject: RE: Information about call set up
Date: Wed, 9 May 2001 11:24:16 -0400
Message-ID: <001901c0d89c$1cf5c320$c500a8c0@MBRAHMANAPALLY>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_001A_01C0D87A.95E42320"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-MS-TNEF-Correlator: 000000002C5F3B69627DBC4EABBD3FF89123E39F24A06E00
In-Reply-To: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_001A_01C0D87A.95E42320
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Dolman,

In RGW each Termination can have a phone number. This phone number is a
known to both the user and external world. The Termination Name is used only
between the MG and MGC. (Infact the RGW users need not know that there is a
name associated with their phone). If any call arrives for that phone number
MGC uses the TerminationId of that phone and generate necessary commands.
The MGC should have the mapping between the number and the TerminationIDs
used in Megaco messages. Apart form these If the MGC needs to keep some
information based on the Analog ports it can do it (The protocol doesn't say
how you map these numbers/ ports/ TerminationIDs).  I hope this answer your
query. 

Regards
Madhubabu

>  -----Original Message-----
> From: 	owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com] 
> Sent:	Wednesday, May 09, 2001 10:55 AM
> To:	megaco@fore.com
> Subject:	Information about call set up
> 
> Good evening. I hope that someone of you can help me. 
> Suppose that there is a RGw in a costumer site that manages two or more
> POTS interfaces and I want to call a telephone attested to this device.
> How a MGC can determine the destination terminal of the connection??
> I mean, MGC analyses the digits and so it can determines that the RGw
> manages the called number pool. But, is the same device that individuate
> the analog termination that corresponds to the called number?? If not,
> which device has to individuate the POTS interface at which the called
> terminal is attested??
> 
> Could someone provide me a link to documentation that talks about this
> problem??
> 
> Thanks for the help,
> 
> 	Dolman Aradori
> 
> ______________________________
> 
>  Dolman Aradori
>  Consultant
> 
>  ICT Consulting
>  Via Vittor Pisani, 22
>  20124 Milano 
> 
>  Phone: +39 02 67642245
>  Fax: +39 0267642243
>  Mobile: +39 335 7505653
> ______________________________
> 
> 
> 
> 

------=_NextPart_000_001A_01C0D87A.95E42320
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Disposition: attachment;
	filename="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IhEPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHBQAJAAsAGAAAAAMADAEB
A5AGAEQKAAAmAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA
AAAAHgBwAAEAAAAeAAAASW5mb3JtYXRpb24gYWJvdXQgY2FsbCBzZXQgdXAAAAACAXEAAQAAABsA
AAABwNiYBPrtEAvmREsR1a1jAFAEkjtsAACn0dAAAgEdDAEAAAAbAAAAU01UUDpNQURIVUJBQlVA
S0VORVRFQy5DT00AAAsAAQ4AAAAAQAAGDgBoThKc2MABAgEKDgEAAAAYAAAAAAAAACxfO2lifbxO
q70/+JEj45/CgAAAAwAUDgEAAAALAB8OAQAAAAIBCRABAAAA7QUAAOkFAAAqCgAATFpGdY8mOSID
AAoAcmNwZzEyNRYyAPgLYG4OEDAzM08B9wKkA+MCAGNoCsBz8GV0MCAHEwKDAFADVB8QyQdtAoMO
UBBmcHJxsxSBErhhaANxAoMzA8bNEXV9CoAIyCA7CW8OMJY1AoAKgXYIkHdrC4C0ZDQMYGMAUAsD
YxIC2QvEIEQG8AOBLAqiCoQFCoBJA6BSR1cgZS0A0GgTMASQbQuAYXQyaQIgIGMDkRDwdmVQIGEg
cBYwbh9QbtZ1BtAEkC4TMGgEAB+LhiAgkR9wa25vdwOg6HRvIAbgdB4AIpAfUC51ESAFwABwZB3A
eHSTBJEHQCB3BbBsZCBS8x9QHipOYQeAIYIjASNw2QIgbHkiYBEwdwnhIrOsTUcjQydwQyBQKB1g
/mYA0AVAIsIdkiMCBCAfwP8mMSHwBUAh4iKxHoAisglwlyGEHnAlsWEEEG9jBzBvI7AjcAPwIpRp
BcAfkym5IFBJZiNBJpAe4GwDIP8KwAUQH0AEIAIQBcAqcyDL3yfhIvIEICLCHilJJkEtsHsvKSNS
ZwnwBJAsISmBYz0HkHMKwC3xA3ADgWRz6yR0MEJzFjB1JFAfFCLC6QDAcHALgGcmqyElI1KdMN5E
JfULgAXQZWcA0N8iUAeBM/AzEDSxQQqxBUD9LuFtIrIRIC2SJzQwYCmS6zCxIlBrCeBwNVADcCXB
dyhQO4EehGIrwCYzIrNB9SPhbzbAcAkRBCAsgB7T9mQiUEBhKCSSFSAigCvw5wbwQMEHkG4nBUAz
8CaQexYwB+B5CGA2Uju1H/Rzfi8/9ERgOJwtcS2QQsFwfzYCIZIAgCbgBcBDEQXAce8KUDQQIFAc
qlI6EQsgELBBHLNNYWRodT7AYocMcBy5CvRsaTM2AUBvG3ABQEGCBZB0EfML8DQfRfBLMA8TTLAU
ZDE2IOotThJPBRBnHmEDIDoAfzqTThMcpkv0S8ELE0v2aTAtMTQ0AUBLQDE4jjABQAzQUbNiIEYD
YXY6AzAMkmIRUCIBBJAtyweAOiJANpB0LjRCNLCdAMByBaADAFTiIFsAwNsDECJAOlPvVP9dR/ZS
4GsGYAIwOlNmVwmAH8BzmmRCoCwF0EKhMDlawNEB0DAxIA9AOhnQEWB6TVjXVFZwU2ZW9S7hZfdX
kljYSdBqTCFZpyhBPje/AaAIYEByLjERISLwcEosn1A/TCJLRA8GTFdHbwRw/x3AH0ADAA8gLYFG
JiqRPbLPH7Ix8UMSHuNlbD2QB4D3R+Ze8DaAbzvxKn4dkAfg5znRH3AFoHN0IAAhYQCQ/zNxKnMD
gTqyIjAkICZQBcDjBGAq8VBPVAXwC4Ajse8oYQeRI1JGEHcAcCiRIlD/LhQiMGhAPYAyhAJAB5As
Mr8iQUaDAQAaQDPAIFBIKkH/H3AwQkCTETAeMzYEAQBrUP8eZnMkI/Ex8x9QVYEzoR6S/D8/HQU6
YRxxMDNscSaA/TCWZE6BQDEjUivgQFdzFv8wsiqUapNsZ3VyLiEpsiE090AABvAgUEJg4FrAIJEi
wj8z8CWxcaRplBqRLpBpZP51M2IiwneCP9F0pXRUKoL7BaEJcHNAADSRcRR7zXZA9y2SKeFawHcg
gB3xfjUQ8P89E37+baxwgYQVgml0pyGS/3CldkYcpAhRNaFnBkGBfzFnNkEfUktAbmsiMkDQY89r
cQIwgMkBkGxrIaFgw+dGg0GBAmBlbYncIHAAcP+OQS7khNFoQRybDIIcJRFhf0mgBbAAoBy0FrMM
ARyzX/+U75W6SisPBFKyC6RSIEzX/WSyM5K+U7CUOZeIAKCYRP9N8JjMCFAAgDWQAZACMAxAx5qr
WOWYZUlDVJ12NqH3mowDsk3hVgcwohECQAWx9lAEAABwaVtBDlChZAHQ+w4gTMBNAxAAcCJQHKpt
kCMfolNAKzM5WxAyIJA2NzY0o1A0NaFVeEZheKXWpmUWwKFkTR+PQAMQpcUPYFvwNzUw+DU2NZQv
q1+WT5PTTHQXSi4KgBfBAK+QAAAAHgBCEAEAAAAvAAAAPE5FQkJLRUhKSEtBR0VDSU9MTURIQUVF
RENKQUEuYXJhZG9yaUBpY3RjLml0PgAAAwAJWQMAAAALAACACCAGAAAAAADAAAAAAAAARgAAAAAD
hQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAA
AEYAAAAAUoUAAH1uAQAeAAmACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAACwAN
gAggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAEAAAALABGACCAGAAAAAADAAAAAAAAARgAAAAAGhQAA
AAAAAAMAEoAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwAbgAggBgAAAAAAwAAAAAAAAEYA
AAAADoUAAAAAAAADAByACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAHoAIIAYAAAAAAMAA
AAAAAABGAAAAABiFAAAAAAAAAgH4DwEAAAAQAAAALF87aWJ9vE6rvT/4kSPjnwIB+g8BAAAAEAAA
ACxfO2lifbxOq70/+JEj458CAfsPAQAAAJwAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAbXNwc3Qu
ZGxsAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XERvY3VtZW50cyBhbmQgU2V0dGluZ3NcTUJyYWht
YW5hcGFsbHlcTG9jYWwgU2V0dGluZ3NcQXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0bG9v
a1xtYWlsYm94LnBzdAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAxAAAAMDAwMDAwMDAyQzVGM0I2
OTYyN0RCQzRFQUJCRDNGRjg5MTIzRTM5RjI0QTA2RTAwAAAAAAMABhCiWe6NAwAHEKMFAAADABAQ
AAAAAAMAERAjAAAAHgAIEAEAAABlAAAARE9MTUFOLElOUkdXRUFDSFRFUk1JTkFUSU9OQ0FOSEFW
RUFQSE9ORU5VTUJFUlRISVNQSE9ORU5VTUJFUklTQUtOT1dOVE9CT1RIVEhFVVNFUkFOREVYVEVS
TkFMV09STERUSAAAAABN5Q==

------=_NextPart_000_001A_01C0D87A.95E42320--



From owner-megaco@fore.com  Wed May  9 11:47:45 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13046
	for ; Wed, 9 May 2001 11:47:32 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA28511;
	Wed, 9 May 2001 11:37:13 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA08880
	for megaco-list; Wed, 9 May 2001 11:36:20 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08868
	for ; Wed, 9 May 2001 11:36:18 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id LAA28352
	for ; Wed, 9 May 2001 11:36:15 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id LAA08066; Wed, 9 May 2001 11:36:12 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 9 May 2001 11:36:00 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 9 May 2001 11:26:37 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CAE6@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Dolman Aradori'" , megaco 
Subject: RE: Information about call set up
Date: Wed, 9 May 2001 11:26:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D89C.6C5C9B00"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D89C.6C5C9B00
Content-Type: text/plain;
	charset="iso-8859-1"

There has to be a table on the MGC which links telephone numbers to
terminationIDs.  At this point, that table is set up by configuration rather
than discovery.  

>  -----Original Message-----
> From: 	Dolman Aradori [mailto:aradori@ictc.it] 
> Sent:	Wednesday, May 09, 2001 10:55 AM
> To:	megaco
> Subject:	Information about call set up
> 
> Good evening. I hope that someone of you can help me. 
> Suppose that there is a RGw in a costumer site that manages two or more
> POTS interfaces and I want to call a telephone attested to this device.
> How a MGC can determine the destination terminal of the connection??
> I mean, MGC analyses the digits and so it can determines that the RGw
> manages the called number pool. But, is the same device that individuate
> the analog termination that corresponds to the called number?? If not,
> which device has to individuate the POTS interface at which the called
> terminal is attested??
> 
> Could someone provide me a link to documentation that talks about this
> problem??
> 
> Thanks for the help,
> 
> 	Dolman Aradori
> 
> ______________________________
> 
>  Dolman Aradori
>  Consultant
> 
>  ICT Consulting
>  Via Vittor Pisani, 22
>  20124 Milano 
> 
>  Phone: +39 02 67642245
>  Fax: +39 0267642243
>  Mobile: +39 335 7505653
> ______________________________
> 
> 
> 
> 

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






RE: Information about call set up




There has to be a =
table on the MGC which links telephone numbers to terminationIDs.  =
At this point, that table is set up by configuration rather than =
discovery.  


    

     -----Original Message-----

    From:   Dolman Aradori [mailto:aradori@ictc.it] 

    Sent:   =
Wednesday, May 09, 2001 10:55 AM

    To:     megaco

    Subject:        Information about call set =
up

    


    Good evening. I hope that someone of =
you can help me. 

    Suppose that there is a RGw in a =
costumer site that manages two or more POTS interfaces and I want to =
call a telephone attested to this device. How a MGC can determine the =
destination terminal of the connection??
    


    I mean, MGC analyses the digits and =
so it can determines that the RGw manages the called number pool. But, =
is the same device that individuate the analog termination that =
corresponds to the called number?? If not, which device has to =
individuate the POTS interface at which the called terminal is =
attested??
    


    Could someone provide me a link to =
documentation that talks about this problem??

    


    Thanks for the help,

    


            Dolman Aradori

    


    ______________________________

    


     Dolman Aradori

     Consultant

    


     ICT Consulting

     Via Vittor Pisani, 22

     20124 Milano 

    


     Phone: +39 02 67642245

     Fax: +39 0267642243

     Mobile: +39 335 7505653

    ______________________________

    

    

    

    




------_=_NextPart_001_01C0D89C.6C5C9B00--


From owner-megaco@fore.com  Wed May  9 12:22:08 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14865
	for ; Wed, 9 May 2001 12:22:08 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA02559;
	Wed, 9 May 2001 12:14:14 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA18837
	for megaco-list; Wed, 9 May 2001 12:12:55 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA18820
	for ; Wed, 9 May 2001 12:12:51 -0400 (EDT)
Received: from web13206.mail.yahoo.com (web13206.mail.yahoo.com [216.136.174.191])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id MAA02410
	for ; Wed, 9 May 2001 12:12:49 -0400 (EDT)
Message-ID: <20010509161249.30902.qmail@web13206.mail.yahoo.com>
Received: from [132.245.3.163] by web13206.mail.yahoo.com; Wed, 09 May 2001 09:12:49 PDT
Date: Wed, 9 May 2001 09:12:49 -0700 (PDT)
From: Mc Keny 
Subject: Information about call set up
To: megaco@fore.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


The RG is an IP device and MGC controls it using its
IP address. The PTOS interface is an anlog termination
on that gateway. Now, when the MGC has a the called
no, it maps that to this termination on the gateway.
This configuration is maintained as part of MGC data.

I guess this is in general how a MGC functions with
different types of gateways (not just RG).


 -----Original Message----- 
From:   Dolman Aradori [mailto:aradori@ictc.it] 
Sent:   Wednesday, May 09, 2001 10:55 AM 
To:     megaco 
Subject:        Information about call set up 

Good evening. I hope that someone of you can help me. 
Suppose that there is a RGw in a costumer site that
manages two or more POTS interfaces and I want to call
a telephone attested to this device. How a MGC can
determine the destination terminal of the connection??

I mean, MGC analyses the digits and so it can
determines that the RGw manages the called number
pool. But, is the same device that individuate the
analog termination that corresponds to the called
number?? If not, which device has to individuate the
POTS interface at which the called terminal is
attested??

Could someone provide me a link to documentation that
talks about this problem?? 

Thanks for the help, 

        Dolman Aradori 

______________________________ 

 Dolman Aradori 
 Consultant 

 ICT Consulting 
 Via Vittor Pisani, 22 
 20124 Milano 

 Phone: +39 02 67642245 
 Fax: +39 0267642243 
 Mobile: +39 335 7505653 
______________________________


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/


From owner-megaco@fore.com  Wed May  9 13:12:56 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17679
	for ; Wed, 9 May 2001 13:12:55 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07556;
	Wed, 9 May 2001 13:06:29 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA01259
	for megaco-list; Wed, 9 May 2001 13:05:40 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA01252
	for ; Wed, 9 May 2001 13:05:38 -0400 (EDT)
Received: from mail.mediatrix.com (mail.mediatrix.com [205.237.248.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07368
	for ; Wed, 9 May 2001 13:05:35 -0400 (EDT)
Received: from PLEMAY (66-4-254-64.enter-net.com [64.254.4.66]) by mail.mediatrix.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id JP7MXJTN; Wed, 9 May 2001 13:01:11 -0400
Reply-To: 
From: "Paul Lemay" 
To: 
Subject: Re: Root Termination Events
Date: Wed, 9 May 2001 13:03:05 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
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 V5.50.4133.2400
Importance: Normal
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id NAA07556
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA17679

Hello,

In order to address all terminations at once, is it right to say that we
have to use wildcarding to address all Context as well?

Thanks in advance.

> From: owner-megaco@pit.comms.marconi.com on behalf of Tom-PT Taylor
> [taylor@nortelnetworks.com]
> Sent: Friday, May 04, 2001 16:08 PM
> To: 'megaco'
> Subject: Root Termination Events

> No, events relate to specific terminations.  You can use wildcarding to
address all terminations at once, if > you need to.

> -----Original Message-----
> From: Jean-Francois Lepine [mailto:jflepine@mediatrix.com]
> Sent: Friday, May 04, 2001 2:18 PM
> To: François Berard; Megaco Mailing List; Olivier Larouche;
> Paul Lemay;
> Steven Weisz
> Subject: Root Termination Events
>
>
> Hello,
>
> In a media gateway context where all semi-permanent
> terminations are of the
> same type (e.g. analog line), is it right to request analog
> line events at
> the Root Termination rather than at each and every temination
> (e.g. off-hook
> detect).
>
> Jean-François Lépine
> Mediatrix Telecom, Inc.
>
>



From owner-megaco@fore.com  Wed May  9 14:10:07 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19804
	for ; Wed, 9 May 2001 14:10:07 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14709;
	Wed, 9 May 2001 14:03:07 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA17319
	for megaco-list; Wed, 9 May 2001 14:02:09 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA17304
	for ; Wed, 9 May 2001 14:02:07 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14530
	for ; Wed, 9 May 2001 14:02:05 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACH08058;
	Wed, 9 May 2001 14:02:02 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: 
Subject: PICS for Megaco
Date: Wed, 9 May 2001 14:06:48 -0400
Message-ID: <002601c0d8b2$d1a602b0$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi All,
Is there any Protocol Implementation Conformance Statement (PICS) for
Megaco. When can a specific vendor say that his implementation confirms to
the protocol specifications.
Regards
Madhubabu



From owner-megaco@fore.com  Wed May  9 18:00:24 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26645
	for ; Wed, 9 May 2001 18:00:20 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA06916;
	Wed, 9 May 2001 17:53:09 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA15091
	for megaco-list; Wed, 9 May 2001 17:52:01 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15087
	for ; Wed, 9 May 2001 17:52:00 -0400 (EDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA06778
	for ; Wed, 9 May 2001 17:51:57 -0400 (EDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA16136
	for ; Wed, 9 May 2001 16:51:58 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f49LpvC03630
	for ; Wed, 9 May 2001 16:51:57 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f49Lpq124087
	for ; Wed, 9 May 2001 16:51:53 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f49LprO01655
	for ; Wed, 9 May 2001 16:51:53 -0500 (CDT)
Message-ID: <3AF9BBF8.772333B8@usa.alcatel.com>
Date: Wed, 09 May 2001 16:51:53 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "'megaco@fore.com'" 
Subject: Re: Implementors' Guide Update Editor's last Call Section 11.2
References: <3AF8D832.E727C159@ericsson.com>
Content-Type: multipart/alternative;
 boundary="------------E57412AE88B512FFF0EB8D80"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------E57412AE88B512FFF0EB8D80
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Christian


Section 11.2 ServiceChange Address and Ports
There is some confusion on  when to use either ServiceChange Address or
ServiceChange MGCID. The text below offers some advice on

[Begin Clarification]
1) The use of ServiceChangeAddress is not encouraged

  Why is the use not encouraged?

2) MGCs must be able to cope with ServiceChangeAddress with either a full
address or just a port number in the case of TCP transport.

  Do you mean UDP transport?
               And ServiceChangeAddress does not apply to TCP?


  I don't see any text regarding the clarification of when one or the
other should be used.
The Standard text already has something like:

ServiceChangeAddress
   and ServiceChangeMgcId parameters must not both be present in the
   ServiceChangeDescriptor or the ServiceChangeResultDescriptor.  The
   ServiceChangeAddress provides an address to be used within the
   context of the association currently being negotiated, while the
   ServiceChangeMgcId provides an alternate address where the MG should
   seek to establish another association.


Christian Groves wrote:

> G'Day all,
>
> The H.248 Series Implementors' Guide has been updated to revision 6.
>
> It can be found at:
> ftp://standard.pictel.com/avc-site/Incoming/
> files:
> TD-xxx_H248_Implementors_Additions_v6.doc
> TD-xxx_H248_Implementors_Additions_v6.pdf
>
> This revision contains the Approved Implementors' Guide and the
> Implementors' Guide Additions v5 with some other changes. The changes
> are detailed in the document.
>
> This is an editors' last call. Please provide comments on this draft by
> Monday the 13th as a revision 7 will be stored on the 14th and sent to
> SG16 for approval at the Porto Seguro meeting. If you have a comment on
> a correction please provide the detailed solution or exact changes that
> you would like to see.
>
> Cheers, Christian

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------E57412AE88B512FFF0EB8D80
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Christian

 

Section 11.2 ServiceChange Address and Ports

There is some confusion on  when to use either ServiceChange
Address or ServiceChange MGCID. The text below offers some advice on

[Begin Clarification]

1) The use of ServiceChangeAddress is not encouraged

<cnn>  Why is the use not encouraged?

2) MGCs must be able to cope with ServiceChangeAddress with either
a full address or just a port number in the case of TCP transport.

<cnn>  Do you mean UDP transport?

              
And ServiceChangeAddress does not apply to TCP?

 

<cnn>  I don't see any text regarding the clarification
of when one or the other should be used.

The Standard text already has something like:

ServiceChangeAddress

   and ServiceChangeMgcId parameters must not both be
present in the

   ServiceChangeDescriptor or the ServiceChangeResultDescriptor. 
The

   ServiceChangeAddress provides an address to be used
within the

   context of the association currently being negotiated,
while the

   ServiceChangeMgcId provides an alternate address where
the MG should

   seek to establish another association.

 

Christian Groves wrote:

G'Day all,

The H.248 Series Implementors' Guide has been updated to revision 6.

It can be found at:

ftp://standard.pictel.com/avc-site/Incoming/

files:

TD-xxx_H248_Implementors_Additions_v6.doc

TD-xxx_H248_Implementors_Additions_v6.pdf

This revision contains the Approved Implementors' Guide and the

Implementors' Guide Additions v5 with some other changes. The changes

are detailed in the document.

This is an editors' last call. Please provide comments on this draft
by

Monday the 13th as a revision 7 will be stored on the 14th and sent
to

SG16 for approval at the Porto Seguro meeting. If you have a comment
on

a correction please provide the detailed solution or exact changes
that

you would like to see.

Cheers, Christian



-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------E57412AE88B512FFF0EB8D80--



From owner-megaco@fore.com  Wed May  9 18:17:28 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27244
	for ; Wed, 9 May 2001 18:17:27 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA08089;
	Wed, 9 May 2001 18:10:21 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA17751
	for megaco-list; Wed, 9 May 2001 18:09:45 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA17747
	for ; Wed, 9 May 2001 18:09:44 -0400 (EDT)
Received: from pavilion (a24b31n80client230.hawaii.rr.com [24.31.80.230])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA07997
	for ; Wed, 9 May 2001 18:09:39 -0400 (EDT)
Message-ID: <1391200153922134690@pavilion>
X-EM-Version: 5, 0, 0, 19
X-EM-Registration: #01B0530810E603002D00
X-Priority: 3
X-MSMail-Priority: Normal
From: "Mitchell" 
To: megaco@fore.com
Subject: Business/Employment Opportunity
Date: Wed, 9 May 2001 12:01:34 -1000
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.pit.comms.marconi.com id SAA17748
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 8bit

Dear Friend:

"Making over half million dollars every 4 to 5 months from your
home for an investment of only $25 U.S. Dollars expense one
time"

THANKS TO THE COMPUTER AGE AND THE INTERNET!
===============================================

BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !!

Before you say "Bull" , please read the following. This is the
letter you have been hearing about on the news lately. Due to the
popularity of this letter on the internet, a national weekly news
program recently devoted an entire show to the investigation of
this program described below , to see if it really can make people
money.

The show also investigated whether or not the program was legal.
Their findings proved once and for all that there are "absolutely
no laws prohibiting the participation in the program and if people
can follow the simple instructions, they are bound to make
some mega bucks with only $25 out of pocket cost".

DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT
THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING
BETTER THAN EVER.

This is what one had to say:

"Thanks to this profitable opportunity. I was approached
many times before but each time I passed on it. I am so glad
I finally joined just to see what one could expect in return
for the minimal effort and money required. To my astonishment, I
received total $ 610,470.00 in 21 weeks, with money still
coming in".
Pam Hedland, Fort Lee, New Jersey.

-------------------------------------------------------------------------

Here is another testimonial:

"This program has been around for a long time but I never
believed in it. But one day when I received this again in
the mail I decided to gamble my $25 on it. I followed thesimple instructions and walaa ..... 3 weeks later the money
started to come in. First month I only made $240.00 but
the next 2 months after that I made a total of $290,000.00.
So far, in the past 8 months by re-entering the program,I
have made over $710,000.00 and I am playing it again.
The key to success in this program is to follow the simple
steps and NOT change anything ."

More testimonials later but first,

****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE *******

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make at least $500,000 every 4 to 5 months
easily and comfortably, please read the following...THEN READ
IT AGAIN and AGAIN !!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR
FINANCIAL DREAMS WILL COME TRUE, GUARANTEED!

INSTRUCTIONS:

**** Order all 5 reports shown on the list below.

**** For each report, send $5 CASH, THE NAME & NUMBER OF THE
REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS
to the person whose name appears ON THAT LIST next to the report.
MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE
TOP LEFT CORNER in case of any mail problems.

**** When you place your order, make sure you order each of the 5
reports. You will need all 5 reports so that you can save them on your 
computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00.

**** Within a few days you will receive, via e-mail, each of the 5
reports from these 5 different individuals. Save them on your computer
so they will be accessible for you to send to the 1,000's of people
who will order them from you. Also make a floppy of these
reports and keep it on your desk in case something happen to your
computer.

****.IMPORTANT - DO NOT alter the names of the people who are
listed next to each report, or their sequence on the list, in
any way other than what is instructed below in steps 1 through6 or you will loose out on majority of your profits. Once you
understand the way this works, you will also see how it does not work if you 
change it.

Remember, this method has been tested, and if you alter, it
will NOT work!!! People have tried to put their friends/relatives names
on all five thinking they could get all the money. But it does not work this 
way. Believe us, we all have tried to be greedy and then nothing happened. 
So Do Not try to change anything other than what is instructed. Because if 
you do, it will not work for you. Remember, honesty reaps the reward!!!

1.. After you have ordered all 5 reports, take this advertisement
and REMOVE the name & address of the person in REPORT # 5. This
person has made it through the cycle and is no doubt counting
their fortune.

2.... Move the name & address in REPORT # 4 down TO REPORT # 5.

3.... Move the name & address in REPORT # 3 down TO REPORT # 4.

4.... Move the name & address in REPORT # 2 down TO REPORT # 3.

5.... Move the name & address in REPORT # 1 down TO REPORT # 2

6.... Insert YOUR name & address in the REPORT # 1 Position.

PLEASE MAKE SURE you copy every name & address ACCURATELY !
=========================================================

Take this entire letter, with the modified list of names, and save
it on your computer. DO NOT MAKE ANY OTHER CHANGES.
Save this on a disk as well just in case if you loose any data.

To assist you with marketing your business on the internet, the
5 reports you purchase will provide you with invaluable
marketing information which includes how to send bulk e-mails legally,
where to find thousands of free classified ads and much more.

There are 2 Primary methods to get this venture going:

METHOD # 1 : BY SENDING BULK E-MAIL LEGALLY
============================================
let's say that you decide to start small, just to see how it
goes, and we will assume You and those involved send out only
5,000 e-mails each. Let's also assume that the mailing receive only a0.2% response (the response could be much better but lets just
say it is only 0.2% . Also many people will send out hundreds of
thousands e-mails instead of only 5,000 each).

Continuing with this example, you send out only 5,000 e-mails.
With a 0.2% response, that is only 10 orders for report # 1.
Those 10 people responded by sending out 5,000 e-mail
each for a total of 50,000. Out of those 50,000 e-mails only
0.2% responded with orders. That's = 100 people responded
and ordered Report # 2. Those 100 people mail out 5,000
e-mails each for a total of 500,000 e-mails. The 0.2% response
to that is 1000 orders for Report # 3. Those 1000 people send
out 5,000 e-mails each for a total of 5 million e-mails sent out.
The 0.2% response to that is 10,000 orders for Report # 4.
Those 10,000 people send out 5,000 e-mails each for a total of
50,000,000 (50 million) e-mails. The 0.2% response to that is
100,000 orders for Report # 5.

THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million).

Your total income in this example is:
1..... $50 +
2..... $500 +
3..... $5,000 +
4..... $50,000 +
5..... $500,000 ......... Grand Total = $555,550.00

NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE
OUT THE WORST POSSIBLE RESPONSES AND NO MATTER
HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF
MONEY !

------------------------------------------------------------------------------

REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE
ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for
a moment what would happen if everyone, or half or even one 4th
of those people mailed 100,000 e-mails each or more? There are
over 250 million people on the internet worldwide and counting.
Believe me, many people will do just that, and more!

METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET
===================================================
Advertising on the net is very very inexpensive and there are
hundreds of FREE places to advertise. Placing a lot of free adson the internet will easily get a larger response. We strongly
suggest you start with Method # 1 and add METHOD # 2 as you go
along.

For every $5 you receive, all you must do is e-mail them the Report
they ordered. That's it . Always provide same day service on all
orders. This will guarantee that the e-mail they send out, with your
name and address on it, will be prompt because they can not advertise until 
they receive the report.

_____________________ AVAILABLE REPORTS_____________________

ORDER EACH REPORT BY ITS NUMBER & NAME ONLY.

Notes: Always send $5 cash (U.S. CURRENCY) for each Report.
Checks NOT accepted. Make sure the cash is concealed by wrapping
it in at least 2 sheets of paper. On one of those sheets of paper,
Write the NUMBER & the NAME of the Report you are ordering, YOUR
E-MAIL ADDRESS and your name and postal address.

PLACE YOUR ORDER FOR THESE REPORTS NOW :
==============================================
REPORT #1, "The Insider's Guide to Sending
Bulk E-mail on the Internet"

ORDER REPORT #1 FROM:

G. Donaldson
P.O. Box 25884
Honolulu, Hawaii 96825-0884


don't forget to provide a permanent e-mail address in clear writing (better 
typed) to receive the reports. We had problems in delivery e-mails before!!!

==============================================
REPORT #2 "The Insider's Guide to Advertising for Free on the
Internet"
ORDER REPORT #2 FROM:

Vijay Paul
C-291, Second Floor
Defence Colony
New Delhi - 110024
INDIA

==============================================
REPORT #3 "The Secrets to Multilevel Marketing on the Internet"
ORDER REPORT #3 FROM:

JD
P.O.Box 1114
Des Plaines, IL 60017
USA

==============================================
REPORT #4 "How to become a Millionaire utilizing the Power of
Multilevel Marketing and the Internet"
ORDER REPORT #4 FROM:

J Santi
833 Walter Ave
Des Plaines, IL 60016
USA

==============================================
REPORT #5 "How to SEND 1,000,000 e-mails for FREE"
ORDER REPORT #5 FROM:

Elaine Rix
138 Dundas Street, West, #243
Toronto, Ontario
Canada M5G 1C3

==============================================
There are currently more than 250,000,000 people online
worldwide!

$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$

Follow these guidelines to guarantee your success:

If you do not receive at least 10 orders for Report #1 within 2
weeks, continue sending e-mails until you do.

After you have received 10 orders, 2 to 3 weeks after that
you should receive 100 orders or more for REPORT # 2.
If you did not, continue advertising or sending e-mails until
you do.
Once you have received 100 or more orders for Report # 2,
YOU CAN RELAX, because the system is already working for
you , and the cash will continue to roll in !

THIS IS IMPORTANT TO REMEMBER : Every time your name is
moved down on the list, you are placed in front of a different report.
You can KEEP TRACK of your PROGRESS by watching which
report people are ordering from you. IF YOU WANT TO GENERATE
MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND
START THE WHOLE PROCESS AGAIN. There is NO LIMIT to
the income you can generate from this business !!!
____________________________________________________

FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS
PROGRAM:

You have just received information that can give you financial
freedom for the rest of your life, with NO RISK and JUST A
LITTLE BIT OF EFFORT. You can make more money in the
next few weeks and months than you have ever imagined.

Follow the program EXACTLY AS INSTRUCTED. Do Not change
it in any way. It works exceedingly well as it is now.
Remember to e-mail a copy of this exciting report after you
have put your name and address in Report #1 and moved others to
#2...........# 5 as instructed above. One of the people you send this to may 
send out 100,000 or more e-mails and your name will be on everyone of them. 
Remember though, the more you send out the more potential customers you will 
reach.

So my friend, I have given you the ideas, information,
materials and opportunity to become financially independent. IT IS UP TO YOU 
NOW !

************** MORE TESTIMONIALS ****************

"My name is Mitchell. My wife , Jody and I live in Chicago.
I am an accountant with a major U.S. Corporation and I
make pretty good money. When I received this program I grumbled
to Jody about receiving ''junk mail''. I made fun of the
whole thing, spouting my knowledge of the population and
percentages involved. I ''knew'' it wouldn't work. Jody
totally ignored my supposed intelligence and few days later she jumped in 
with both feet. I made merciless fun of her, and was ready to
lay the old ''I told you so'' on her when the thing didn'twork. Well, the laugh was on me! Within 3 weeks she had received
50 responses. Within the next 45 days she had received a
total of $ 147,200.00 all cash! I was shocked. I have
joined Jody in her ''hobby''."
Mitchell Wolf,
Chicago, Illinois

------------------------------------------------------------

"Not being the gambling type, it took me several weeks to
make up my mind to participate in this plan. But conservative that
I am, I decided that the initial investment was so little
that there was just no way that I wouldn't get enough orders to at
least get my money back.

I was surprised when I found my medium size post office box
crammed with orders. I made $319,210.00 in the first 12
weeks. The nice thing about this deal is that it does not matter
where people live. There simply isn't a better investment
with a faster return and so big."
Dan Sondstrom, Alberta,
Canada

-----------------------------------------------------------

"I had received this program before. I deleted it, but
later I wondered if I should have given it a try. Of course, I had
no idea who to contact to get another copy, so I had to wait
until I was e-mailed again by someone else.........11 months
passed then it luckily came again...... I did not delete this
one! I made more than $490,000 on my first try and all the
money came within 22 weeks".
Susan De Suza,
New York, N.Y.

----------------------------------------------------

"It really is a great opportunity to make relatively easy
money with little cost to you. I followed the simple
instructions carefully and within 10 days the money
started to come in. My first month I made $ 20,560.00
and by the end of third month my total cash count was
$ 362,840.00. Life is beautiful, Thanx to internet".
Fred Dellaca, Westport,
New Zealand
------------------------------------------------------------


ORDER YOUR REPORTS TODAY AND GET STARTED ON
YOUR ROAD TO FINANCIAL FREEDOM !

=======================================================

If you have any questions of the legality of this program, contact the
Office of Associate Director for Marketing Practices, Federal Trade
Commission, Bureau of Consumer Protection, Washington, D.C.


Under Bill s.1618 TITLE III passed by the 105th US Congress this
letter cannot be considered spam as long as the sender includes
contact information and a method of removal.
This is one time e-mail transmission. No request for removal is
necessary.

------------------------------------------------------------
This message is sent in compliance of the new email
Bill HR 1910. Under Bill HR 1910 passed by the 106th
US Congress on May 24, 1999, this message cannot be
considered Spam as long as we include the way to be
removed. Per Section HR 1910, Please type "REMOVE" in
the subject line and reply to this email. All removal
requests are handled personally an immediately once
received.









From owner-megaco@fore.com  Wed May  9 18:26:33 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27611
	for ; Wed, 9 May 2001 18:26:28 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA08984;
	Wed, 9 May 2001 18:20:44 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA19384
	for megaco-list; Wed, 9 May 2001 18:19:59 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA19380
	for ; Wed, 9 May 2001 18:19:58 -0400 (EDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA08855
	for ; Wed, 9 May 2001 18:19:55 -0400 (EDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id RAA20360
	for ; Wed, 9 May 2001 17:19:56 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f49MJuC10624
	for ; Wed, 9 May 2001 17:19:56 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f49MJf127756
	for ; Wed, 9 May 2001 17:19:41 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f49MJfO01662
	for ; Wed, 9 May 2001 17:19:41 -0500 (CDT)
Message-ID: <3AF9C27D.99FD20CD@usa.alcatel.com>
Date: Wed, 09 May 2001 17:19:41 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Implementors' Guide Update Editor's last Call Section 6.58
References: <3AF8D832.E727C159@ericsson.com>
Content-Type: multipart/alternative;
 boundary="------------3062104EF607782DDE0127BC"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------3062104EF607782DDE0127BC
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id SAA08984
Content-Transfer-Encoding: quoted-printable

Christian

6.58 TimeStamp in registration replies
=B7 If the Timestamp is not sent by either the MG or the MGC, both sides
shall keep their original time base.

Does this now imply that TimeStamp is not required in ServiceChange
registration?

Megaco Text
The TimeStamp parameter shall be sent with a registration command and its
response.

----
Something else
ServiceChangeVersion in Megaco Text

   *  ServiceChangeVersion, if the responder wishes to negotiate the
      version of the protocol to be used for the association.

But ABNF
   ;at-most-once. Version is REQUIRED on first ServiceChange response
   servChgReplyParm     =3D (serviceChangeAddress / serviceChangeMgcId /
                          serviceChangeProfile / serviceChangeVersion )


Also it seems that if Version is REQUIRED for first ServiceChange
response,
wouldn't Version be required for first ServiceChange request?

Thanks
Chuong

Christian Groves wrote:

> G'Day all,
>
> The H.248 Series Implementors' Guide has been updated to revision 6.
>
> It can be found at:
> ftp://standard.pictel.com/avc-site/Incoming/
> files:
> TD-xxx_H248_Implementors_Additions_v6.doc
> TD-xxx_H248_Implementors_Additions_v6.pdf
>
> This revision contains the Approved Implementors' Guide and the
> Implementors' Guide Additions v5 with some other changes. The changes
> are detailed in the document.
>
> This is an editors' last call. Please provide comments on this draft by
> Monday the 13th as a revision 7 will be stored on the 14th and sent to
> SG16 for approval at the Porto Seguro meeting. If you have a comment on
> a correction please provide the detailed solution or exact changes that
> you would like to see.
>
> Cheers, Christian

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------3062104EF607782DDE0127BC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Christian

6.58 TimeStamp in registration replies

· If the Timestamp is not sent by either the MG or the MGC,
both sides shall keep their original time base.

Does this now imply that TimeStamp is not required in ServiceChange
registration?

Megaco Text

The TimeStamp parameter shall be sent with a registration command
and its response.

----

Something else

ServiceChangeVersion in Megaco Text

   *  ServiceChangeVersion, if the responder wishes
to negotiate the

      version of the protocol to be used
for the association.

But ABNF

   ;at-most-once. Version is REQUIRED on first ServiceChange
response

   servChgReplyParm     = (serviceChangeAddress
/ serviceChangeMgcId /

                         
serviceChangeProfile / serviceChangeVersion )

 

Also it seems that if Version is REQUIRED for first ServiceChange response,

wouldn't Version be required for first ServiceChange request?

Thanks

Chuong

Christian Groves wrote:

G'Day all,

The H.248 Series Implementors' Guide has been updated to revision 6.

It can be found at:

ftp://standard.pictel.com/avc-site/Incoming/

files:

TD-xxx_H248_Implementors_Additions_v6.doc

TD-xxx_H248_Implementors_Additions_v6.pdf

This revision contains the Approved Implementors' Guide and the

Implementors' Guide Additions v5 with some other changes. The changes

are detailed in the document.

This is an editors' last call. Please provide comments on this draft
by

Monday the 13th as a revision 7 will be stored on the 14th and sent
to

SG16 for approval at the Porto Seguro meeting. If you have a comment
on

a correction please provide the detailed solution or exact changes
that

you would like to see.

Cheers, Christian



-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------3062104EF607782DDE0127BC--



From owner-megaco@fore.com  Wed May  9 18:32:27 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27811
	for ; Wed, 9 May 2001 18:32:27 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA01774;
	Wed, 9 May 2001 16:50:16 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA01944
	for megaco-list; Wed, 9 May 2001 16:47:12 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA01933
	for ; Wed, 9 May 2001 16:47:10 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id QAA01409
	for ; Wed, 9 May 2001 16:47:07 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id QAA05040; Wed, 9 May 2001 16:47:04 -0400
Received: from ztcfd004.ca.nortel.com by zcars04e.nortelnetworks.com;
          Wed, 9 May 2001 16:47:00 -0400
Received: by ztcfd004.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 9 May 2001 16:47:00 -0400
Message-ID: <45D2A43C1913D51180F40000F89CB874062DF5@nrtpde0a.us.nortel.com>
From: "Michael Brown" 
To: "Petros N. Mouchtaris" 
Cc: megaco , SG16 ,
        Oskar vanDeventer 
Subject: RE: IP Type of Service
Date: Wed, 9 May 2001 16:46:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D8C9.30CDBE70"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D8C9.30CDBE70
Content-Type: text/plain;
	charset="iso-8859-1"

There are at least four contributions to the upcoming Study Group 11 meeting
(May 14-May 25)related to this topic. If you have ITU TIES access, they are
under Delayed Contributions 207, 212, 214, and 215.

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com]
Sent: Wednesday, May 09, 2001 1:41 AM
To: Petros N. Mouchtaris
Cc: Rosen, Brian; megaco; SG16; Oskar vanDeventer
Subject: Re: IP Type of Service


I think that any work on QoS parameters should be aligned with the work
occuring in ETSI Tiphon, ITU SG16, ITU SG11 etc. There's been a
considerable amount of effort in trying to come up with common
parameters for QoS. Any solution should tap into this.

Cheers, Christian

"Petros N. Mouchtaris" wrote:
> 
> Brian,
> 
> Actually there was a long discussion on this topic last year on the
mailing
> list i.e. whether MGC should be able to signal an MG which TOS bit to use.
> The whole topic ended up being dropped. Check the archive for e-mails with
> title "MG and DiffServ".
> 
> By the way, Flemming had volunteered to do some work but I assume it
didn't
> have high enough priority.
> 
> Excerpt from e-mail:
> 
> "Tom-PT Taylor wrote:
> 
>                     > You are correct that packages should be drawn up
(and/or SDP defined) to
>                     > allow QOS parameter setting.  Volunteers?
> 
>                     Sure - I can put a package proposal together.
> 
>                     -- Flemming
> 
> Petros
> 
> "Rosen, Brian"  on 05/08/2001 03:29:44 PM
> 
> To:   "'Tom-PT Taylor'" , "'Madhu Babu
>       Brahmanapally'" , "Rosen, Brian"
>       , "'Chuong Nguyen'"
>       , megaco 
> cc:    (bcc: Petros N. Mouchtaris/Telcordia)
> Subject:  RE: IP Type of Service
> 
> I'll look into this.  I agree.
> 
> Brian
> 
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Tuesday, May 08, 2001 10:07 AM
> To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen'; megaco
> Subject: RE: IP Type of Service
> 
> That makes sense.
> 
> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Tuesday, May 08, 2001 10:08 AM
> To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B881:EXCH]; 'Chuong Nguyen';
> megaco
> Subject: RE: IP Type of Service
> 
> Hi All,
> Another suggestion. Why cant the SDP be extended to incorporate a TOS
> parameter/attribute so that all the protocols(SIP,Megaco,MGCP) that use
SDP
> need not define extra properties/parameter for supporting this.
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> Sent: Tuesday, May 08, 2001 9:24 AM
> To: 'Madhu Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen';
> megaco@fore.com
> Subject: RE: IP Type of Service
> 
> I don't agree.  The TOS for a particular stream should be set on that
> stream, not
> on the MG as a whole.  For example, if I have a multimedia MG, I will want
> to set
> the priority of voice higher than video, and video higher than normal.  If
> I
> implement a
> Multilevel Pre-emption and Priority scheme, some calls will have higher
> priority than
> others.  The TOS/frame priority has to be per stream.
> 
> Brian
> 
> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Tuesday, May 08, 2001 9:24 AM
> To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; megaco@fore.com
> Subject: RE: IP Type of Service
> 
> Hi All,
> 
> The default TOS type should be defined on the ROOT termination for the
> default TOS used for all media packets generated from the MG. There should
> be a method (might be through some property) of specifying stream level
TOS
> bits.
> 
> I'm interested to work on RSVP.
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> Sent: Tuesday, May 08, 2001 8:10 AM
> To: 'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco@fore.com'
> Subject: RE: IP Type of Service
> 
> TOS should not be ignored at the edge router if the router is configured
to
> enable DiffServ.
> 
> It would be pretty simple to create one package that had the appropriate
> controls for
> DiffServ and 802.1p.  RSVP needs it's own package because there is
> messaging,
> and you at least an event or two
> 
> The former could be an enumeration: QosMarking, that had values None, TOS
> and
> FramePriority, plus another integer, Value.  That would suffice I think,
> although you
> could conceivably get more clever with DiffServ.
> 
> Shall I write something up along those lines?
> 
> RSVP takes some more work.  Any volunteers?
> 
> Brian
> 
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Monday, May 07, 2001 9:15 PM
> To: 'Chuong Nguyen'; 'megaco@fore.com'
> Subject: RE: IP Type of Service
> 
> No such package has yet been defined.
> 
> Various QOS architectures can be imagined.  Each would give rise to its
own
> package, since the MGC-MG information flow would differ from one
> architecture to the next.  One question: unless the MG is itself the edge
> router, won't the ToS be ignored when the media packets reach the latter?
> 
> -----Original Message-----
> From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> Sent: Monday, May 07, 2001 5:14 PM
> To: 'megaco@fore.com'
> Subject: IP Type of Service
> 
> All
> 
> In MGCP, MGC can specify IP Type of Service to the MG.
> Do we have an equivalent in Megaco?
> 
> Is there or has anyone defined a package for IP Type of Service?
> 
> Thanks
> Chuong
> 
> --
> 
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
> 
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
> 
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
> 
>   ------------------------------------------------------------------------
>                Name: att1.htm
>    att1.htm    Type: Hypertext Markup Language (text/html)
>            Encoding: base64

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






RE: IP Type of Service




There are at least four contributions to the upcoming =
Study Group 11 meeting (May 14-May 25)related to this topic. If you =
have ITU TIES access, they are under Delayed Contributions 207, 212, =
214, and 215.



-----Original Message-----

From: Christian Groves [mailto:Christian.Groves@er=
icsson.com]

Sent: Wednesday, May 09, 2001 1:41 AM

To: Petros N. Mouchtaris

Cc: Rosen, Brian; megaco; SG16; Oskar =
vanDeventer

Subject: Re: IP Type of Service






I think that any work on QoS parameters should be =
aligned with the work

occuring in ETSI Tiphon, ITU SG16, ITU SG11 etc. =
There's been a

considerable amount of effort in trying to come up =
with common

parameters for QoS. Any solution should tap into =
this.




Cheers, Christian




"Petros N. Mouchtaris" wrote:

> 

> Brian,

> 

> Actually there was a long discussion on this =
topic last year on the mailing

> list i.e. whether MGC should be able to signal =
an MG which TOS bit to use.

> The whole topic ended up being dropped. Check =
the archive for e-mails with

> title "MG and DiffServ".

> 

> By the way, Flemming had volunteered to do some =
work but I assume it didn't

> have high enough priority.

> 

> Excerpt from e-mail:

> 

> "Tom-PT Taylor wrote:

> 

>          =
;           > You =
are correct that packages should be drawn up (and/or SDP defined) =
to

>          =
;           > =
allow QOS parameter setting.  Volunteers?

> 

>          =
;           Sure - I =
can put a package proposal together.

> 

>          =
;           -- =
Flemming

> 

> Petros

> 

> "Rosen, Brian" =
<Brian.Rosen@marconi.com> on 05/08/2001 03:29:44 PM

> 

> To:   "'Tom-PT Taylor'" =
<taylor@nortelnetworks.com>, "'Madhu Babu

>       =
Brahmanapally'" <madhubabu@kenetec.com>, "Rosen, =
Brian"

>       =
<Brian.Rosen@marconi.com>, "'Chuong Nguyen'"

>       =
<Chuong.Nguyen@usa.alcatel.com>, megaco =
<megaco@fore.com>

> cc:    (bcc: Petros N. =
Mouchtaris/Telcordia)

> Subject:  RE: IP Type of Service

> 

> I'll look into this.  I agree.

> 

> Brian

> 

> -----Original Message-----

> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c=
om]

> Sent: Tuesday, May 08, 2001 10:07 AM

> To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; =
'Chuong Nguyen'; megaco

> Subject: RE: IP Type of Service

> 

> That makes sense.

> 

> -----Original Message-----

> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]<=
/FONT>

> Sent: Tuesday, May 08, 2001 10:08 AM

> To: 'Rosen, Brian'; Taylor, Tom-PT =
[NORSE:B881:EXCH]; 'Chuong Nguyen';

> megaco

> Subject: RE: IP Type of Service

> 

> Hi All,

> Another suggestion. Why cant the SDP be =
extended to incorporate a TOS

> parameter/attribute so that all the =
protocols(SIP,Megaco,MGCP) that use SDP

> need not define extra properties/parameter for =
supporting this.

> 

> Regards

> Madhubabu

> 

> -----Original Message-----

> From: owner-megaco@pit.comms.marconi.com

> [mailto:owner-megaco@p=
it.comms.marconi.com]On Behalf Of Rosen, Brian

> Sent: Tuesday, May 08, 2001 9:24 AM

> To: 'Madhu Babu Brahmanapally'; 'Tom-PT =
Taylor'; 'Chuong Nguyen';

> megaco@fore.com

> Subject: RE: IP Type of Service

> 

> I don't agree.  The TOS for a particular =
stream should be set on that

> stream, not

> on the MG as a whole.  For example, if I =
have a multimedia MG, I will want

> to set

> the priority of voice higher than video, and =
video higher than normal.  If

> I

> implement a

> Multilevel Pre-emption and Priority scheme, =
some calls will have higher

> priority than

> others.  The TOS/frame priority has to be =
per stream.

> 

> Brian

> 

> -----Original Message-----

> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]<=
/FONT>

> Sent: Tuesday, May 08, 2001 9:24 AM

> To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong =
Nguyen'; megaco@fore.com

> Subject: RE: IP Type of Service

> 

> Hi All,

> 

> The default TOS type should be defined on the =
ROOT termination for the

> default TOS used for all media packets =
generated from the MG. There should

> be a method (might be through some property) of =
specifying stream level TOS

> bits.

> 

> I'm interested to work on RSVP.

> 

> Regards

> Madhubabu

> 

> -----Original Message-----

> From: owner-megaco@pit.comms.marconi.com

> [mailto:owner-megaco@p=
it.comms.marconi.com]On Behalf Of Rosen, Brian

> Sent: Tuesday, May 08, 2001 8:10 AM

> To: 'Tom-PT Taylor'; 'Chuong Nguyen'; =
'megaco@fore.com'

> Subject: RE: IP Type of Service

> 

> TOS should not be ignored at the edge router if =
the router is configured to

> enable DiffServ.

> 

> It would be pretty simple to create one package =
that had the appropriate

> controls for

> DiffServ and 802.1p.  RSVP needs it's own =
package because there is

> messaging,

> and you at least an event or two

> 

> The former could be an enumeration: QosMarking, =
that had values None, TOS

> and

> FramePriority, plus another integer, =
Value.  That would suffice I think,

> although you

> could conceivably get more clever with =
DiffServ.

> 

> Shall I write something up along those =
lines?

> 

> RSVP takes some more work.  Any =
volunteers?

> 

> Brian

> 

> -----Original Message-----

> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c=
om]

> Sent: Monday, May 07, 2001 9:15 PM

> To: 'Chuong Nguyen'; 'megaco@fore.com'

> Subject: RE: IP Type of Service

> 

> No such package has yet been defined.

> 

> Various QOS architectures can be =
imagined.  Each would give rise to its own

> package, since the MGC-MG information flow =
would differ from one

> architecture to the next.  One question: =
unless the MG is itself the edge

> router, won't the ToS be ignored when the media =
packets reach the latter?

> 

> -----Original Message-----

> From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.a=
lcatel.com]

> Sent: Monday, May 07, 2001 5:14 PM

> To: 'megaco@fore.com'

> Subject: IP Type of Service

> 

> All

> 

> In MGCP, MGC can specify IP Type of Service to =
the MG.

> Do we have an equivalent in Megaco?

> 

> Is there or has anyone defined a package for IP =
Type of Service?

> 

> Thanks

> Chuong

> 

> --

> 

>   Alcatel USA, =
Inc           &nb=
sp; Internet: Chuong.Nguyen@usa.alcatel.com

> 

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

> 

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

> 

>   =
------------------------------------------------------------------------=


>          =
;      Name: att1.htm

>    att1.htm    =
Type: Hypertext Markup Language (text/html)

>          =
;  Encoding: base64





------_=_NextPart_001_01C0D8C9.30CDBE70--


From owner-megaco@fore.com  Wed May  9 19:31:53 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29134
	for ; Wed, 9 May 2001 19:31:52 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA12725;
	Wed, 9 May 2001 19:26:07 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id TAA27834
	for megaco-list; Wed, 9 May 2001 19:24:49 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA27830
	for ; Wed, 9 May 2001 19:24:48 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA12583
	for ; Wed, 9 May 2001 19:24:45 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACH10401;
	Wed, 9 May 2001 19:24:46 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: 
Subject: Error Code 505
Date: Wed, 9 May 2001 19:29:31 -0400
Message-ID: <004d01c0d8df$e6d1f540$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

HI All,

The Error code 505 description is "Transaction Request Received before a
ServiceChange Reply has been received", does the ServiceChange reply here
mean the ServiceChange reply on ROOT termination? or is this valid for other
terminations also. I think the intention is here is ServiceChange for ROOT
termination. Comments??

Regards
Madhubabu



From owner-megaco@fore.com  Wed May  9 20:16:04 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29741
	for ; Wed, 9 May 2001 20:16:03 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA15135;
	Wed, 9 May 2001 20:09:03 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA02302
	for megaco-list; Wed, 9 May 2001 20:08:19 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA02297
	for ; Wed, 9 May 2001 20:08:17 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA15020
	for ; Wed, 9 May 2001 20:08:14 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACH10518;
	Wed, 9 May 2001 20:08:15 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: 
Subject: order of responses.
Date: Wed, 9 May 2001 20:13:00 -0400
Message-ID: <004e01c0d8e5$f9ec7eb0$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi All,
Is the following response valid?????
MGC--------->MG
   MEGACO/1 [216.33.33.61]: 27000
   Transaction = 1243 {
     Context = 2 {
       Modify = TermB {
         Signals { }}
       Modify = EphB {
          Media {
            LocalControl {
              Mode = sendrecv}
                   Remote {
   v=0
   c=IN IP4 192.168.0.160
   m=audio 50000 RTP/AVP 4
                   }
               } ; RTP profile for G723 is 4
           }
       }
     }
   }

and the response from MG-------->MGC is


   MEGACO/1 [207.176.47.89]: 26000
   Reply = 1243 {
      Context = 2 {Modify = TermB, Modify = EphB}
   }

In this example Modify TermB is first executed in the MG and then the Modify
for EphB. Is it valid that the MG after the command execution send response
first for EphB and then for TermB.

Regards
Madhubabu



From owner-megaco@fore.com  Wed May  9 22:30:33 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02416
	for ; Wed, 9 May 2001 22:30:33 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA22111;
	Wed, 9 May 2001 22:24:56 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id WAA14816
	for megaco-list; Wed, 9 May 2001 22:23:55 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA14812
	for ; Wed, 9 May 2001 22:23:53 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA21972
	for ; Wed, 9 May 2001 22:23:49 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id MAA14503;
	Thu, 10 May 2001 12:22:28 +1000 (EST)
Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA05548;
	Thu, 10 May 2001 12:22:28 +1000 (EST)
Message-ID: <3AF9FB61.8C2CB3F7@ericsson.com>
Date: Thu, 10 May 2001 12:22:25 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Madhu Babu Brahmanapally 
CC: megaco@fore.com
Subject: Re: Error Code 505
References: <004d01c0d8df$e6d1f540$c500a8c0@MBRAHMANAPALLY>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

I'd say this is valid also for terminations than root. A servicechange
can be applied to individual terminations and this error code is to
guard trying to change termination characteristics before they have
restarted.

Christian

Madhu Babu Brahmanapally wrote:
> 
> HI All,
> 
> The Error code 505 description is "Transaction Request Received before a
> ServiceChange Reply has been received", does the ServiceChange reply here
> mean the ServiceChange reply on ROOT termination? or is this valid for other
> terminations also. I think the intention is here is ServiceChange for ROOT
> termination. Comments??
> 
> Regards
> Madhubabu


From owner-megaco@fore.com  Wed May  9 23:44:56 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04279
	for ; Wed, 9 May 2001 23:44:55 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA25491;
	Wed, 9 May 2001 23:34:17 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA20518
	for megaco-list; Wed, 9 May 2001 23:33:32 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA20514
	for ; Wed, 9 May 2001 23:33:30 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id XAA25314
	for ; Wed, 9 May 2001 23:33:27 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id XAA03490; Wed, 9 May 2001 23:33:25 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Wed, 9 May 2001 23:33:28 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 9 May 2001 23:33:30 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CAEF@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Madhu Babu Brahmanapally'" ,
        megaco 
Subject: RE: PICS for Megaco
Date: Wed, 9 May 2001 23:33:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D901.FA25CD70"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D901.FA25CD70
Content-Type: text/plain;
	charset="ISO-8859-1"

TIPHON began to work on PICS for some very simple situations.

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Wednesday, May 09, 2001 2:07 PM
> To: megaco
> Subject: PICS for Megaco
> 
> 
> Hi All,
> Is there any Protocol Implementation Conformance Statement (PICS) for
> Megaco. When can a specific vendor say that his 
> implementation confirms to
> the protocol specifications.
> Regards
> Madhubabu
> 
> 

------_=_NextPart_001_01C0D901.FA25CD70
Content-Type: text/html;
	charset="ISO-8859-1"






RE: PICS for Megaco




TIPHON began to work on PICS for some very simple situations.




> -----Original Message-----

> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]

> Sent: Wednesday, May 09, 2001 2:07 PM

> To: megaco

> Subject: PICS for Megaco

> 

> 

> Hi All,

> Is there any Protocol Implementation Conformance Statement (PICS) for

> Megaco. When can a specific vendor say that his 

> implementation confirms to

> the protocol specifications.

> Regards

> Madhubabu

> 

> 





------_=_NextPart_001_01C0D901.FA25CD70--


From owner-megaco@fore.com  Wed May  9 23:44:57 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04289
	for ; Wed, 9 May 2001 23:44:57 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA25463;
	Wed, 9 May 2001 23:34:12 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA20502
	for megaco-list; Wed, 9 May 2001 23:32:59 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA20498
	for ; Wed, 9 May 2001 23:32:58 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id XAA25303
	for ; Wed, 9 May 2001 23:32:54 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id XAA03474; Wed, 9 May 2001 23:32:52 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Wed, 9 May 2001 23:32:55 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 9 May 2001 23:32:57 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CAEE@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'plemay'" , Megaco 
Subject: RE: Root Termination Events
Date: Wed, 9 May 2001 23:32:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D901.E6B12E60"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D901.E6B12E60
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Yes, that's right.

> -----Original Message-----
> From: Paul Lemay [mailto:plemay@mediatrix.com]
> Sent: Wednesday, May 09, 2001 1:03 PM
> To: Megaco
> Subject: Re: Root Termination Events
>=20
>=20
> Hello,
>=20
> In order to address all terminations at once, is it right to=20
> say that we
> have to use wildcarding to address all Context as well?
>=20
> Thanks in advance.
>=20
> > From: owner-megaco@pit.comms.marconi.com on behalf of Tom-PT Taylor
> > [taylor@nortelnetworks.com]
> > Sent: Friday, May 04, 2001 16:08 PM
> > To: 'megaco'
> > Subject: Root Termination Events
>=20
> > No, events relate to specific terminations.  You can use=20
> wildcarding to
> address all terminations at once, if > you need to.
>=20
> > -----Original Message-----
> > From: Jean-Francois Lepine [mailto:jflepine@mediatrix.com]
> > Sent: Friday, May 04, 2001 2:18 PM
> > To: Fran=E7ois Berard; Megaco Mailing List; Olivier Larouche;
> > Paul Lemay;
> > Steven Weisz
> > Subject: Root Termination Events
> >
> >
> > Hello,
> >
> > In a media gateway context where all semi-permanent
> > terminations are of the
> > same type (e.g. analog line), is it right to request analog
> > line events at
> > the Root Termination rather than at each and every temination
> > (e.g. off-hook
> > detect).
> >
> > Jean-Fran=E7ois L=E9pine
> > Mediatrix Telecom, Inc.
> >
> >
>=20
>=20

------_=_NextPart_001_01C0D901.E6B12E60
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Root Termination Events




Yes, that's right.




> -----Original Message-----

> From: Paul Lemay [mailto:plemay@mediatrix.com]

> Sent: Wednesday, May 09, 2001 1:03 PM

> To: Megaco

> Subject: Re: Root Termination Events

> 

> 

> Hello,

> 

> In order to address all terminations at once, =
is it right to 

> say that we

> have to use wildcarding to address all Context =
as well?

> 

> Thanks in advance.

> 

> > From: owner-megaco@pit.comms.marconi.com =
on behalf of Tom-PT Taylor

> > [taylor@nortelnetworks.com]

> > Sent: Friday, May 04, 2001 16:08 PM

> > To: 'megaco'

> > Subject: Root Termination Events

> 

> > No, events relate to specific =
terminations.  You can use 

> wildcarding to

> address all terminations at once, if > you =
need to.

> 

> > -----Original Message-----

> > From: Jean-Francois Lepine [mailto:jflepine@mediatrix.com=
]

> > Sent: Friday, May 04, 2001 2:18 PM

> > To: Fran=E7ois Berard; Megaco Mailing =
List; Olivier Larouche;

> > Paul Lemay;

> > Steven Weisz

> > Subject: Root Termination Events

> >

> >

> > Hello,

> >

> > In a media gateway context where all =
semi-permanent

> > terminations are of the

> > same type (e.g. analog line), is it right =
to request analog

> > line events at

> > the Root Termination rather than at each =
and every temination

> > (e.g. off-hook

> > detect).

> >

> > Jean-Fran=E7ois L=E9pine

> > Mediatrix Telecom, Inc.

> >

> >

> 

> 





------_=_NextPart_001_01C0D901.E6B12E60--


From owner-megaco@fore.com  Wed May  9 23:49:02 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04390
	for ; Wed, 9 May 2001 23:49:01 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA25940;
	Wed, 9 May 2001 23:41:58 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA21052
	for megaco-list; Wed, 9 May 2001 23:41:27 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA21048
	for ; Wed, 9 May 2001 23:41:26 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id XAA25861
	for ; Wed, 9 May 2001 23:41:22 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id XAA03667; Wed, 9 May 2001 23:41:20 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 9 May 2001 23:41:22 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 9 May 2001 23:41:25 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CAF0@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "Michael Brown" ,
        "Petros N. Mouchtaris" 
Cc: megaco , SG16 ,
        Oskar vanDeventer 
Subject: RE: IP Type of Service
Date: Wed, 9 May 2001 23:41:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D903.14E7F8D0"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D903.14E7F8D0
Content-Type: text/plain;
	charset="ISO-8859-1"

However, any changes to SDP have to be done in the IETF, and since QOS
relates to media streams, it really has to be done in SDP as well as
anywhere else the ITU-T and other bodies see fit to put it.

-----Original Message-----
From: Brown, Michael [NC1:GW10:EXCH] 
Sent: Wednesday, May 09, 2001 4:47 PM
To: Petros N. Mouchtaris
Cc: megaco; SG16; Oskar vanDeventer
Subject: RE: IP Type of Service


There are at least four contributions to the upcoming Study Group 11 meeting
(May 14-May 25)related to this topic. If you have ITU TIES access, they are
under Delayed Contributions 207, 212, 214, and 215.
-----Original Message----- 
From: Christian Groves [mailto:Christian.Groves@ericsson.com] 
Sent: Wednesday, May 09, 2001 1:41 AM 
To: Petros N. Mouchtaris 
Cc: Rosen, Brian; megaco; SG16; Oskar vanDeventer 
Subject: Re: IP Type of Service 


I think that any work on QoS parameters should be aligned with the work 
occuring in ETSI Tiphon, ITU SG16, ITU SG11 etc. There's been a 
considerable amount of effort in trying to come up with common 
parameters for QoS. Any solution should tap into this. 
Cheers, Christian 
"Petros N. Mouchtaris" wrote: 
> 
> Brian, 
> 
> Actually there was a long discussion on this topic last year on the
mailing 
> list i.e. whether MGC should be able to signal an MG which TOS bit to use.

> The whole topic ended up being dropped. Check the archive for e-mails with

> title "MG and DiffServ". 
> 
> By the way, Flemming had volunteered to do some work but I assume it
didn't 
> have high enough priority. 
> 
> Excerpt from e-mail: 
> 
> "Tom-PT Taylor wrote: 
> 
>                     > You are correct that packages should be drawn up
(and/or SDP defined) to 
>                     > allow QOS parameter setting.  Volunteers? 
> 
>                     Sure - I can put a package proposal together. 
> 
>                     -- Flemming 
> 
> Petros 
> 
> "Rosen, Brian"  on 05/08/2001 03:29:44 PM 
> 
> To:   "'Tom-PT Taylor'" , "'Madhu Babu 
>       Brahmanapally'" , "Rosen, Brian" 
>       , "'Chuong Nguyen'" 
>       , megaco  
> cc:    (bcc: Petros N. Mouchtaris/Telcordia) 
> Subject:  RE: IP Type of Service 
> 
> I'll look into this.  I agree. 
> 
> Brian 
> 
> -----Original Message----- 
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] 
> Sent: Tuesday, May 08, 2001 10:07 AM 
> To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen'; megaco 
> Subject: RE: IP Type of Service 
> 
> That makes sense. 
> 
> -----Original Message----- 
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] 
> Sent: Tuesday, May 08, 2001 10:08 AM 
> To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B881:EXCH]; 'Chuong Nguyen'; 
> megaco 
> Subject: RE: IP Type of Service 
> 
> Hi All, 
> Another suggestion. Why cant the SDP be extended to incorporate a TOS 
> parameter/attribute so that all the protocols(SIP,Megaco,MGCP) that use
SDP 
> need not define extra properties/parameter for supporting this. 
> 
> Regards 
> Madhubabu 
> 
> -----Original Message----- 
> From: owner-megaco@pit.comms.marconi.com 
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian 
> Sent: Tuesday, May 08, 2001 9:24 AM 
> To: 'Madhu Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen'; 
> megaco@fore.com 
> Subject: RE: IP Type of Service 
> 
> I don't agree.  The TOS for a particular stream should be set on that 
> stream, not 
> on the MG as a whole.  For example, if I have a multimedia MG, I will want

> to set 
> the priority of voice higher than video, and video higher than normal.  If

> I 
> implement a 
> Multilevel Pre-emption and Priority scheme, some calls will have higher 
> priority than 
> others.  The TOS/frame priority has to be per stream. 
> 
> Brian 
> 
> -----Original Message----- 
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] 
> Sent: Tuesday, May 08, 2001 9:24 AM 
> To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; megaco@fore.com 
> Subject: RE: IP Type of Service 
> 
> Hi All, 
> 
> The default TOS type should be defined on the ROOT termination for the 
> default TOS used for all media packets generated from the MG. There should

> be a method (might be through some property) of specifying stream level
TOS 
> bits. 
> 
> I'm interested to work on RSVP. 
> 
> Regards 
> Madhubabu 
> 
> -----Original Message----- 
> From: owner-megaco@pit.comms.marconi.com 
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian 
> Sent: Tuesday, May 08, 2001 8:10 AM 
> To: 'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco@fore.com' 
> Subject: RE: IP Type of Service 
> 
> TOS should not be ignored at the edge router if the router is configured
to 
> enable DiffServ. 
> 
> It would be pretty simple to create one package that had the appropriate 
> controls for 
> DiffServ and 802.1p.  RSVP needs it's own package because there is 
> messaging, 
> and you at least an event or two 
> 
> The former could be an enumeration: QosMarking, that had values None, TOS 
> and 
> FramePriority, plus another integer, Value.  That would suffice I think, 
> although you 
> could conceivably get more clever with DiffServ. 
> 
> Shall I write something up along those lines? 
> 
> RSVP takes some more work.  Any volunteers? 
> 
> Brian 
> 
> -----Original Message----- 
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] 
> Sent: Monday, May 07, 2001 9:15 PM 
> To: 'Chuong Nguyen'; 'megaco@fore.com' 
> Subject: RE: IP Type of Service 
> 
> No such package has yet been defined. 
> 
> Various QOS architectures can be imagined.  Each would give rise to its
own 
> package, since the MGC-MG information flow would differ from one 
> architecture to the next.  One question: unless the MG is itself the edge 
> router, won't the ToS be ignored when the media packets reach the latter? 
> 
> -----Original Message----- 
> From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com] 
> Sent: Monday, May 07, 2001 5:14 PM 
> To: 'megaco@fore.com' 
> Subject: IP Type of Service 
> 
> All 
> 
> In MGCP, MGC can specify IP Type of Service to the MG. 
> Do we have an equivalent in Megaco? 
> 
> Is there or has anyone defined a package for IP Type of Service? 
> 
> Thanks 
> Chuong 
> 
> -- 
> 
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com 
> 
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613 
> 
>   **** The opinions expressed are not those of Alcatel USA, Inc **** 
> 
>   ------------------------------------------------------------------------

>                Name: att1.htm 
>    att1.htm    Type: Hypertext Markup Language (text/html) 
>            Encoding: base64 

------_=_NextPart_001_01C0D903.14E7F8D0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: IP Type of Service




However, any changes to SDP have to be done in the =
IETF, and since QOS relates to media streams, it really has to be done =
in SDP as well as anywhere else the ITU-T and other bodies see fit to =
put it.



-----Original Message-----

From: Brown, Michael [NC1:GW10:EXCH] 

Sent: Wednesday, May 09, 2001 4:47 PM

To: Petros N. Mouchtaris

Cc: megaco; SG16; Oskar vanDeventer

Subject: RE: IP Type of Service






There are at least four contributions to the upcoming =
Study Group 11 meeting (May 14-May 25)related to this topic. If you =
have ITU TIES access, they are under Delayed Contributions 207, 212, =
214, and 215.



-----Original Message----- 

From: Christian Groves [mailto:Christian.Groves@er=
icsson.com] 

Sent: Wednesday, May 09, 2001 1:41 AM 

To: Petros N. Mouchtaris 

Cc: Rosen, Brian; megaco; SG16; Oskar vanDeventer =


Subject: Re: IP Type of Service 






I think that any work on QoS parameters should be =
aligned with the work 

occuring in ETSI Tiphon, ITU SG16, ITU SG11 etc. =
There's been a 

considerable amount of effort in trying to come up =
with common 

parameters for QoS. Any solution should tap into =
this. 

Cheers, Christian 

"Petros N. Mouchtaris" wrote: 

> 

> Brian, 

> 

> Actually there was a long discussion on this =
topic last year on the mailing 

> list i.e. whether MGC should be able to signal =
an MG which TOS bit to use. 

> The whole topic ended up being dropped. Check =
the archive for e-mails with 

> title "MG and DiffServ". 

> 

> By the way, Flemming had volunteered to do some =
work but I assume it didn't 

> have high enough priority. 

> 

> Excerpt from e-mail: 

> 

> "Tom-PT Taylor wrote: 

> 

>          =
;           > You =
are correct that packages should be drawn up (and/or SDP defined) to =


>          =
;           > =
allow QOS parameter setting.  Volunteers? 

> 

>          =
;           Sure - I =
can put a package proposal together. 

> 

>          =
;           -- =
Flemming 

> 

> Petros 

> 

> "Rosen, Brian" =
<Brian.Rosen@marconi.com> on 05/08/2001 03:29:44 PM 

> 

> To:   "'Tom-PT Taylor'" =
<taylor@nortelnetworks.com>, "'Madhu Babu 

>       =
Brahmanapally'" <madhubabu@kenetec.com>, "Rosen, =
Brian" 

>       =
<Brian.Rosen@marconi.com>, "'Chuong Nguyen'" 

>       =
<Chuong.Nguyen@usa.alcatel.com>, megaco <megaco@fore.com> =


> cc:    (bcc: Petros N. =
Mouchtaris/Telcordia) 

> Subject:  RE: IP Type of Service 

> 

> I'll look into this.  I agree. 

> 

> Brian 

> 

> -----Original Message----- 

> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c=
om] 

> Sent: Tuesday, May 08, 2001 10:07 AM 

> To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; =
'Chuong Nguyen'; megaco 

> Subject: RE: IP Type of Service 

> 

> That makes sense. 

> 

> -----Original Message----- 

> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] =


> Sent: Tuesday, May 08, 2001 10:08 AM 

> To: 'Rosen, Brian'; Taylor, Tom-PT =
[NORSE:B881:EXCH]; 'Chuong Nguyen'; 

> megaco 

> Subject: RE: IP Type of Service 

> 

> Hi All, 

> Another suggestion. Why cant the SDP be =
extended to incorporate a TOS 

> parameter/attribute so that all the =
protocols(SIP,Megaco,MGCP) that use SDP 

> need not define extra properties/parameter for =
supporting this. 

> 

> Regards 

> Madhubabu 

> 

> -----Original Message----- 

> From: owner-megaco@pit.comms.marconi.com =


> [mailto:owner-megaco@p=
it.comms.marconi.com]On Behalf Of Rosen, Brian 

> Sent: Tuesday, May 08, 2001 9:24 AM 

> To: 'Madhu Babu Brahmanapally'; 'Tom-PT =
Taylor'; 'Chuong Nguyen'; 

> megaco@fore.com 

> Subject: RE: IP Type of Service 

> 

> I don't agree.  The TOS for a particular =
stream should be set on that 

> stream, not 

> on the MG as a whole.  For example, if I =
have a multimedia MG, I will want 

> to set 

> the priority of voice higher than video, and =
video higher than normal.  If 

> I 

> implement a 

> Multilevel Pre-emption and Priority scheme, =
some calls will have higher 

> priority than 

> others.  The TOS/frame priority has to be =
per stream. 

> 

> Brian 

> 

> -----Original Message----- 

> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] =


> Sent: Tuesday, May 08, 2001 9:24 AM 

> To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong =
Nguyen'; megaco@fore.com 

> Subject: RE: IP Type of Service 

> 

> Hi All, 

> 

> The default TOS type should be defined on the =
ROOT termination for the 

> default TOS used for all media packets =
generated from the MG. There should 

> be a method (might be through some property) of =
specifying stream level TOS 

> bits. 

> 

> I'm interested to work on RSVP. 

> 

> Regards 

> Madhubabu 

> 

> -----Original Message----- 

> From: owner-megaco@pit.comms.marconi.com =


> [mailto:owner-megaco@p=
it.comms.marconi.com]On Behalf Of Rosen, Brian 

> Sent: Tuesday, May 08, 2001 8:10 AM 

> To: 'Tom-PT Taylor'; 'Chuong Nguyen'; =
'megaco@fore.com' 

> Subject: RE: IP Type of Service 

> 

> TOS should not be ignored at the edge router if =
the router is configured to 

> enable DiffServ. 

> 

> It would be pretty simple to create one package =
that had the appropriate 

> controls for 

> DiffServ and 802.1p.  RSVP needs it's own =
package because there is 

> messaging, 

> and you at least an event or two 

> 

> The former could be an enumeration: QosMarking, =
that had values None, TOS 

> and 

> FramePriority, plus another integer, =
Value.  That would suffice I think, 

> although you 

> could conceivably get more clever with =
DiffServ. 

> 

> Shall I write something up along those lines? =


> 

> RSVP takes some more work.  Any =
volunteers? 

> 

> Brian 

> 

> -----Original Message----- 

> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c=
om] 

> Sent: Monday, May 07, 2001 9:15 PM 

> To: 'Chuong Nguyen'; 'megaco@fore.com' 

> Subject: RE: IP Type of Service 

> 

> No such package has yet been defined. 

> 

> Various QOS architectures can be =
imagined.  Each would give rise to its own 

> package, since the MGC-MG information flow =
would differ from one 

> architecture to the next.  One question: =
unless the MG is itself the edge 

> router, won't the ToS be ignored when the media =
packets reach the latter? 

> 

> -----Original Message----- 

> From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.a=
lcatel.com] 

> Sent: Monday, May 07, 2001 5:14 PM 

> To: 'megaco@fore.com' 

> Subject: IP Type of Service 

> 

> All 

> 

> In MGCP, MGC can specify IP Type of Service to =
the MG. 

> Do we have an equivalent in Megaco? 

> 

> Is there or has anyone defined a package for IP =
Type of Service? 

> 

> Thanks 

> Chuong 

> 

> -- 

> 

>   Alcatel USA, =
Inc           &nb=
sp; Internet: Chuong.Nguyen@usa.alcatel.com 

> 

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

> 

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

> 

>   =
------------------------------------------------------------------------=
 

>          =
;      Name: att1.htm 

>    att1.htm    =
Type: Hypertext Markup Language (text/html) 

>          =
;  Encoding: base64 





------_=_NextPart_001_01C0D903.14E7F8D0--


From owner-megaco@fore.com  Wed May  9 23:59:05 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04484
	for ; Wed, 9 May 2001 23:59:05 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA26507;
	Wed, 9 May 2001 23:53:26 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA22002
	for megaco-list; Wed, 9 May 2001 23:52:48 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA21998
	for ; Wed, 9 May 2001 23:52:46 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id XAA26432
	for ; Wed, 9 May 2001 23:52:43 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id XAA03885; Wed, 9 May 2001 23:52:41 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Wed, 9 May 2001 23:52:40 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 9 May 2001 23:52:42 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CAF1@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Madhu Babu Brahmanapally'" ,
        megaco 
Subject: RE: order of responses.
Date: Wed, 9 May 2001 23:52:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D904.A84EFFA0"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D904.A84EFFA0
Content-Type: text/plain;
	charset="ISO-8859-1"

No, because commands must be executed in order of appearance, and creation
of the response can be considerted part of "execution".

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Wednesday, May 09, 2001 8:13 PM
> To: megaco
> Subject: order of responses.
> 
> 
> Hi All,
> Is the following response valid?????
> MGC--------->MG
>    MEGACO/1 [216.33.33.61]: 27000
>    Transaction = 1243 {
>      Context = 2 {
>        Modify = TermB {
>          Signals { }}
>        Modify = EphB {
>           Media {
>             LocalControl {
>               Mode = sendrecv}
>                    Remote {
>    v=0
>    c=IN IP4 192.168.0.160
>    m=audio 50000 RTP/AVP 4
>                    }
>                } ; RTP profile for G723 is 4
>            }
>        }
>      }
>    }
> 
> and the response from MG-------->MGC is
> 
> 
>    MEGACO/1 [207.176.47.89]: 26000
>    Reply = 1243 {
>       Context = 2 {Modify = TermB, Modify = EphB}
>    }
> 
> In this example Modify TermB is first executed in the MG and 
> then the Modify
> for EphB. Is it valid that the MG after the command execution 
> send response
> first for EphB and then for TermB.
> 
> Regards
> Madhubabu
> 
> 
> --------------------------------------------------------------
> -----------
> This email server is running an evaluation copy of the 
> MailShield anti-
> spam software. Please contact your email administrator if you have any
> questions about this message. MailShield product info: 
www.mailshield.com

------_=_NextPart_001_01C0D904.A84EFFA0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: order of responses.




No, because commands must be executed in order of =
appearance, and creation of the response can be considerted part of =
"execution".



> -----Original Message-----

> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]<=
/FONT>

> Sent: Wednesday, May 09, 2001 8:13 PM

> To: megaco

> Subject: order of responses.

> 

> 

> Hi All,

> Is the following response valid?????

> MGC--------->MG

>    MEGACO/1 [216.33.33.61]: =
27000

>    Transaction =3D 1243 {

>      Context =3D 2 =
{

>        =
Modify =3D TermB {

>          =
Signals { }}

>        =
Modify =3D EphB {

>          =
; Media {

>          =
;   LocalControl {

>          =
;     Mode =3D sendrecv}

>          =
;          Remote {

>    v=3D0

>    c=3DIN IP4 =
192.168.0.160

>    m=3Daudio 50000 RTP/AVP =
4

>          =
;          }

>          =
;      } ; RTP profile for G723 is 4

>          =
;  }

>        =
}

>      }

>    }

> 

> and the response from MG-------->MGC =
is

> 

> 

>    MEGACO/1 [207.176.47.89]: =
26000

>    Reply =3D 1243 {

>       Context =3D =
2 {Modify =3D TermB, Modify =3D EphB}

>    }

> 

> In this example Modify TermB is first executed =
in the MG and 

> then the Modify

> for EphB. Is it valid that the MG after the =
command execution 

> send response

> first for EphB and then for TermB.

> 

> Regards

> Madhubabu

> 

> 

> =
--------------------------------------------------------------

> -----------

> This email server is running an evaluation copy =
of the 

> MailShield anti-

> spam software. Please contact your email =
administrator if you have any

> questions about this message. MailShield =
product info: 

www.mailshield.com





------_=_NextPart_001_01C0D904.A84EFFA0--


From owner-megaco@fore.com  Thu May 10 00:02:22 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04532
	for ; Thu, 10 May 2001 00:02:21 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA26756;
	Wed, 9 May 2001 23:56:42 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA22226
	for megaco-list; Wed, 9 May 2001 23:56:12 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA22222
	for ; Wed, 9 May 2001 23:56:11 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id XAA26681
	for ; Wed, 9 May 2001 23:56:07 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id XAA03959; Wed, 9 May 2001 23:56:05 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 9 May 2001 23:56:07 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 9 May 2001 23:56:10 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CAF2@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Christian Groves'" ,
        Madhu Babu Brahmanapally 
Cc: megaco@fore.com
Subject: RE: Error Code 505
Date: Wed, 9 May 2001 23:56:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D905.24638660"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D905.24638660
Content-Type: text/plain;
	charset="ISO-8859-1"

All we're talking about is response to a ServiceChange here -- not a
subsequent ServiceChange indicating a reversion to the previous state.  I
would suggest that 505 should apply only to ServiceChange on ROOT, not
because I have an immediate counter-example for the alternative, but because
it feels like it would be easy to construct a counter-example.

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Wednesday, May 09, 2001 10:22 PM
> To: Madhu Babu Brahmanapally
> Cc: megaco@fore.com
> Subject: Re: Error Code 505
> 
> 
> I'd say this is valid also for terminations than root. A servicechange
> can be applied to individual terminations and this error code is to
> guard trying to change termination characteristics before they have
> restarted.
> 
> Christian
> 
> Madhu Babu Brahmanapally wrote:
> > 
> > HI All,
> > 
> > The Error code 505 description is "Transaction Request 
> Received before a
> > ServiceChange Reply has been received", does the 
> ServiceChange reply here
> > mean the ServiceChange reply on ROOT termination? or is 
> this valid for other
> > terminations also. I think the intention is here is 
> ServiceChange for ROOT
> > termination. Comments??
> > 
> > Regards
> > Madhubabu
> 

------_=_NextPart_001_01C0D905.24638660
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Error Code 505




All we're talking about is response to a =
ServiceChange here -- not a subsequent ServiceChange indicating a =
reversion to the previous state.  I would suggest that 505 should =
apply only to ServiceChange on ROOT, not because I have an immediate =
counter-example for the alternative, but because it feels like it would =
be easy to construct a counter-example.



> -----Original Message-----

> From: Christian Groves [mailto:Christian.Groves@er=
icsson.com]

> Sent: Wednesday, May 09, 2001 10:22 PM

> To: Madhu Babu Brahmanapally

> Cc: megaco@fore.com

> Subject: Re: Error Code 505

> 

> 

> I'd say this is valid also for terminations =
than root. A servicechange

> can be applied to individual terminations and =
this error code is to

> guard trying to change termination =
characteristics before they have

> restarted.

> 

> Christian

> 

> Madhu Babu Brahmanapally wrote:

> > 

> > HI All,

> > 

> > The Error code 505 description is =
"Transaction Request 

> Received before a

> > ServiceChange Reply has been =
received", does the 

> ServiceChange reply here

> > mean the ServiceChange reply on ROOT =
termination? or is 

> this valid for other

> > terminations also. I think the intention =
is here is 

> ServiceChange for ROOT

> > termination. Comments??

> > 

> > Regards

> > Madhubabu

> 





------_=_NextPart_001_01C0D905.24638660--


From owner-megaco@fore.com  Thu May 10 00:48:26 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04952
	for ; Thu, 10 May 2001 00:48:26 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA29066;
	Thu, 10 May 2001 00:42:36 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA26455
	for megaco-list; Thu, 10 May 2001 00:41:45 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA26447
	for ; Thu, 10 May 2001 00:41:43 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA28947
	for ; Thu, 10 May 2001 00:41:38 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA28574;
	Thu, 10 May 2001 14:41:38 +1000 (EST)
Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA11642;
	Thu, 10 May 2001 14:41:37 +1000 (EST)
Message-ID: <3AFA1BFC.F8419921@ericsson.com>
Date: Thu, 10 May 2001 14:41:32 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom-PT Taylor 
CC: Madhu Babu Brahmanapally , megaco@fore.com
Subject: Re: Error Code 505
References: <28560036253BD41191A10000F8BCBD110250CAF2@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

You lost me on the first sentence of your reply. Why can't ServiceChange
bring up a range of termination for the first time? I don't see any
overriding reason that this must only apply to ROOT. 

Christian

Tom-PT Taylor wrote:
> 
> All we're talking about is response to a ServiceChange here -- not a
> subsequent ServiceChange indicating a reversion to the previous
> state.  I would suggest that 505 should apply only to ServiceChange on
> ROOT, not because I have an immediate counter-example for the
> alternative, but because it feels like it would be easy to construct a
> counter-example.
> 
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Wednesday, May 09, 2001 10:22 PM
> > To: Madhu Babu Brahmanapally
> > Cc: megaco@fore.com
> > Subject: Re: Error Code 505
> >
> >
> > I'd say this is valid also for terminations than root. A
> servicechange
> > can be applied to individual terminations and this error code is to
> > guard trying to change termination characteristics before they have
> > restarted.
> >
> > Christian
> >
> > Madhu Babu Brahmanapally wrote:
> > >
> > > HI All,
> > >
> > > The Error code 505 description is "Transaction Request
> > Received before a
> > > ServiceChange Reply has been received", does the
> > ServiceChange reply here
> > > mean the ServiceChange reply on ROOT termination? or is
> > this valid for other
> > > terminations also. I think the intention is here is
> > ServiceChange for ROOT
> > > termination. Comments??
> > >
> > > Regards
> > > Madhubabu
> >


From owner-megaco@fore.com  Thu May 10 01:06:07 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05256
	for ; Thu, 10 May 2001 01:06:07 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA29837;
	Thu, 10 May 2001 00:59:06 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA27626
	for megaco-list; Thu, 10 May 2001 00:58:26 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA27622
	for ; Thu, 10 May 2001 00:58:25 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id AAA29738
	for ; Thu, 10 May 2001 00:58:21 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id AAA05776; Thu, 10 May 2001 00:58:19 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Thu, 10 May 2001 00:58:12 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 10 May 2001 00:58:14 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CAF6@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Christian Groves'" 
Cc: Madhu Babu Brahmanapally , megaco@fore.com
Subject: RE: Error Code 505
Date: Thu, 10 May 2001 00:58:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D90D.CEF04930"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D90D.CEF04930
Content-Type: text/plain;
	charset="ISO-8859-1"

Let me put the opposite question: has anyone up to now thought that
terminations are only in service after a ServiceChange announcing their
presence?  I think I can see a possible use for such a convention with ATM,
but I don't see it applying to any other type of termination.

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Thursday, May 10, 2001 12:42 AM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]
> Cc: Madhu Babu Brahmanapally; megaco@fore.com
> Subject: Re: Error Code 505
> 
> 
> You lost me on the first sentence of your reply. Why can't 
> ServiceChange
> bring up a range of termination for the first time? I don't see any
> overriding reason that this must only apply to ROOT. 
> 
> Christian
> 
> Tom-PT Taylor wrote:
> > 
> > All we're talking about is response to a ServiceChange here -- not a
> > subsequent ServiceChange indicating a reversion to the previous
> > state.  I would suggest that 505 should apply only to 
> ServiceChange on
> > ROOT, not because I have an immediate counter-example for the
> > alternative, but because it feels like it would be easy to 
> construct a
> > counter-example.
> > 
> > > -----Original Message-----
> > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > > Sent: Wednesday, May 09, 2001 10:22 PM
> > > To: Madhu Babu Brahmanapally
> > > Cc: megaco@fore.com
> > > Subject: Re: Error Code 505
> > >
> > >
> > > I'd say this is valid also for terminations than root. A
> > servicechange
> > > can be applied to individual terminations and this error 
> code is to
> > > guard trying to change termination characteristics before 
> they have
> > > restarted.
> > >
> > > Christian
> > >
> > > Madhu Babu Brahmanapally wrote:
> > > >
> > > > HI All,
> > > >
> > > > The Error code 505 description is "Transaction Request
> > > Received before a
> > > > ServiceChange Reply has been received", does the
> > > ServiceChange reply here
> > > > mean the ServiceChange reply on ROOT termination? or is
> > > this valid for other
> > > > terminations also. I think the intention is here is
> > > ServiceChange for ROOT
> > > > termination. Comments??
> > > >
> > > > Regards
> > > > Madhubabu
> > >
> 

------_=_NextPart_001_01C0D90D.CEF04930
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Error Code 505




Let me put the opposite question: has anyone up to =
now thought that terminations are only in service after a ServiceChange =
announcing their presence?  I think I can see a possible use for =
such a convention with ATM, but I don't see it applying to any other =
type of termination.



> -----Original Message-----

> From: Christian Groves [mailto:Christian.Groves@er=
icsson.com]

> Sent: Thursday, May 10, 2001 12:42 AM

> To: Taylor, Tom-PT [NORSE:B881:EXCH]

> Cc: Madhu Babu Brahmanapally; =
megaco@fore.com

> Subject: Re: Error Code 505

> 

> 

> You lost me on the first sentence of your =
reply. Why can't 

> ServiceChange

> bring up a range of termination for the first =
time? I don't see any

> overriding reason that this must only apply to =
ROOT. 

> 

> Christian

> 

> Tom-PT Taylor wrote:

> > 

> > All we're talking about is response to a =
ServiceChange here -- not a

> > subsequent ServiceChange indicating a =
reversion to the previous

> > state.  I would suggest that 505 =
should apply only to 

> ServiceChange on

> > ROOT, not because I have an immediate =
counter-example for the

> > alternative, but because it feels like it =
would be easy to 

> construct a

> > counter-example.

> > 

> > > -----Original Message-----

> > > From: Christian Groves [mailto:Christian.Groves@er=
icsson.com]

> > > Sent: Wednesday, May 09, 2001 10:22 =
PM

> > > To: Madhu Babu Brahmanapally

> > > Cc: megaco@fore.com

> > > Subject: Re: Error Code 505

> > >

> > >

> > > I'd say this is valid also for =
terminations than root. A

> > servicechange

> > > can be applied to individual =
terminations and this error 

> code is to

> > > guard trying to change termination =
characteristics before 

> they have

> > > restarted.

> > >

> > > Christian

> > >

> > > Madhu Babu Brahmanapally =
wrote:

> > > >

> > > > HI All,

> > > >

> > > > The Error code 505 description =
is "Transaction Request

> > > Received before a

> > > > ServiceChange Reply has been =
received", does the

> > > ServiceChange reply here

> > > > mean the ServiceChange reply on =
ROOT termination? or is

> > > this valid for other

> > > > terminations also. I think the =
intention is here is

> > > ServiceChange for ROOT

> > > > termination. Comments??

> > > >

> > > > Regards

> > > > Madhubabu

> > >

> 





------_=_NextPart_001_01C0D90D.CEF04930--


From owner-megaco@fore.com  Thu May 10 01:31:28 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08523
	for ; Thu, 10 May 2001 01:31:28 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA00799;
	Thu, 10 May 2001 01:24:31 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA29760
	for megaco-list; Thu, 10 May 2001 01:23:45 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA29756
	for ; Thu, 10 May 2001 01:23:44 -0400 (EDT)
Received: from kice3.kice.re.kr ([210.102.127.253])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA00704
	for ; Thu, 10 May 2001 01:23:38 -0400 (EDT)
Received: from cheerful.com (igfs.kice.re.kr [192.168.1.1]) by kice3.kice.re.kr (8.8.8/8.8.8) with SMTP id OAA09373; Thu, 10 May 2001 14:08:50 +0900 (KST)
Message-Id: <200105100508.OAA09373@kice3.kice.re.kr>
Date: Thu, 10 May 01 00:23:33 EST
From: "Mike" 
To: Friend@public.com
Subject: Beijing 9.9 cents per minute, London 7 cents
Reply-To: cheaplongdistance@cheerful.com
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Never any extra fees.   
Instant, rechargeable account number.    

Taiwan - Taipei      8.4 cents per minute
China - Beijing      9.9 cents per minute
Hong Kong            7 cents per minute
Indonesia - Jkt      10 cents per minute
South Korea          9 cents per minute
Japan - Tokyo        9 cents per minute
Malaysia - KL        10 cents per minute
Mexico City          11 cents per minute

FOR MORE INFO:
To access our easy-to-use website, 
Simply REPLY to this Email, with "rates" in the "Subject" Line.


To be PERMANENTLY REMOVED from our mail list, you must reply, with 
"REMOVE" in the --> "SUBJECT" Line!

Under Bill S.1618 Title III passed by the 105th U.S. Congress this letter cannot 
be considered, labeled, or treated as "illegal" unsolicited commercial e-mail 
(spam) as long as:
1.  It contains contact information (the site itself)
2.  It contains a remove link.



From owner-megaco@fore.com  Thu May 10 01:35:45 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09152
	for ; Thu, 10 May 2001 01:35:45 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA01419;
	Thu, 10 May 2001 01:29:57 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA00280
	for megaco-list; Thu, 10 May 2001 01:29:07 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA00266
	for ; Thu, 10 May 2001 01:29:05 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA01199
	for ; Thu, 10 May 2001 01:28:55 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA00331;
	Thu, 10 May 2001 14:58:10 +1000 (EST)
Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA15777;
	Thu, 10 May 2001 14:57:59 +1000 (EST)
Message-ID: <3AF9FAD5.1F488ADB@ericsson.com>
Date: Thu, 10 May 2001 12:20:05 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Chuong Nguyen 
CC: "'megaco@fore.com'" 
Subject: Re: Implementors' Guide Update Editor's last Call Section 11.2
References: <3AF8D832.E727C159@ericsson.com> <3AF9BBF8.772333B8@usa.alcatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day Chuong, 

Please see my replies below.

Cheers, Christian

Chuong Nguyen wrote:
> 
> Christian
> 
> 
> Section 11.2 ServiceChange Address and Ports
> There is some confusion on  when to use either ServiceChange Address
> or ServiceChange MGCID. The text below offers some advice on
> 
> [Begin Clarification]
> 1) The use of ServiceChangeAddress is not encouraged
> 
>   Why is the use not encouraged?
[CHG] This was in the approved IG. The issue was that the
ServiceChangeMgcID and the ServiceChangeAddress carried essentially the
same information. So ServiceChangeMgcID was favoured.

> 
> 2) MGCs must be able to cope with ServiceChangeAddress with either a
> full address or just a port number in the case of TCP transport.
> 
>   Do you mean UDP transport?
>                And ServiceChangeAddress does not apply to TCP?
[CHG] ServiceChangeAddress applies to all. The "or" relates TCP to the
port number. I guess you could remove the "in the case of TCP transport"
part.

> 
> 
>   I don't see any text regarding the clarification of when one or
> the other should be used.
> The Standard text already has something like:
> 
> ServiceChangeAddress
>    and ServiceChangeMgcId parameters must not both be present in the
>    ServiceChangeDescriptor or the ServiceChangeResultDescriptor.  The
>    ServiceChangeAddress provides an address to be used within the
>    context of the association currently being negotiated, while the
>    ServiceChangeMgcId provides an alternate address where the MG
> should
>    seek to establish another association.
[CHG] That's why we put the note in favouring MGcID.

> 
> 
> Christian Groves wrote:
> 
> > G'Day all,
> >
> > The H.248 Series Implementors' Guide has been updated to revision 6.
> >
> > It can be found at:
> > ftp://standard.pictel.com/avc-site/Incoming/
> > files:
> > TD-xxx_H248_Implementors_Additions_v6.doc
> > TD-xxx_H248_Implementors_Additions_v6.pdf
> >
> > This revision contains the Approved Implementors' Guide and the
> > Implementors' Guide Additions v5 with some other changes. The
> > changes
> > are detailed in the document.
> >
> > This is an editors' last call. Please provide comments on this draft
> > by
> > Monday the 13th as a revision 7 will be stored on the 14th and sent
> > to
> > SG16 for approval at the Porto Seguro meeting. If you have a comment
> > on
> > a correction please provide the detailed solution or exact changes
> > that
> > you would like to see.
> >
> > Cheers, Christian
> 
> --
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
> 
>




From owner-megaco@fore.com  Thu May 10 01:36:07 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09206
	for ; Thu, 10 May 2001 01:36:06 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA01213;
	Thu, 10 May 2001 01:29:00 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA00192
	for megaco-list; Thu, 10 May 2001 01:28:27 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA00188
	for ; Thu, 10 May 2001 01:28:25 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA01106
	for ; Thu, 10 May 2001 01:28:20 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA00371;
	Thu, 10 May 2001 14:58:22 +1000 (EST)
Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA15772;
	Thu, 10 May 2001 14:57:57 +1000 (EST)
Message-ID: <3AF9F936.F7DF2B63@ericsson.com>
Date: Thu, 10 May 2001 12:13:10 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Chuong Nguyen 
CC: megaco@fore.com
Subject: Re: Implementors' Guide Update Editor's last Call Section 6.58
References: <3AF8D832.E727C159@ericsson.com> <3AF9C27D.99FD20CD@usa.alcatel.com>
Content-Type: text/plain; charset=iso-8859-1
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id BAA01213
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA09206

G'Day Chuong,

Please see my comments below.

Cheers, Christian

Chuong Nguyen wrote:
> 
> Christian
> 
> 6.58 TimeStamp in registration replies
> · If the Timestamp is not sent by either the MG or the MGC, both sides
> shall keep their original time base.
> 
> Does this now imply that TimeStamp is not required in ServiceChange
> registration?

[CHG] No I don't believe it does. The start of this paragraph has always
stated "The optional Timestamp...." so there is no change.


> 
> Megaco Text
> The TimeStamp parameter shall be sent with a registration command and
> its response.
> 
> ----
> Something else
> ServiceChangeVersion in Megaco Text
> 
>    *  ServiceChangeVersion, if the responder wishes to negotiate the
>       version of the protocol to be used for the association.
> 
> But ABNF
>    ;at-most-once. Version is REQUIRED on first ServiceChange response
>    servChgReplyParm     = (serviceChangeAddress / serviceChangeMgcId /
> 
>                           serviceChangeProfile / serviceChangeVersion
> )
> 
> 
> Also it seems that if Version is REQUIRED for first ServiceChange
> response,
> wouldn't Version be required for first ServiceChange request?
[CHG] I would remove the comment about Version. Chapter 11.3 gives the
rules for when version is sent. There's no point in doubling up. Its not
a syntax issue its a procedural issue. Anybody have a problem with
removing the Version part of the comment?

> 
> Thanks
> Chuong
> 
> Christian Groves wrote:
> 
> > G'Day all,
> >
> > The H.248 Series Implementors' Guide has been updated to revision 6.
> >
> > It can be found at:
> > ftp://standard.pictel.com/avc-site/Incoming/
> > files:
> > TD-xxx_H248_Implementors_Additions_v6.doc
> > TD-xxx_H248_Implementors_Additions_v6.pdf
> >
> > This revision contains the Approved Implementors' Guide and the
> > Implementors' Guide Additions v5 with some other changes. The
> > changes
> > are detailed in the document.
> >
> > This is an editors' last call. Please provide comments on this draft
> > by
> > Monday the 13th as a revision 7 will be stored on the 14th and sent
> > to
> > SG16 for approval at the Porto Seguro meeting. If you have a comment
> > on
> > a correction please provide the detailed solution or exact changes
> > that
> > you would like to see.
> >
> > Cheers, Christian
> 
> --
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
> 
>




From owner-megaco@fore.com  Thu May 10 02:48:23 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20154
	for ; Thu, 10 May 2001 02:48:23 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA04686;
	Thu, 10 May 2001 02:42:41 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA06307
	for megaco-list; Thu, 10 May 2001 02:40:44 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA06300
	for ; Thu, 10 May 2001 02:40:42 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA04549
	for ; Thu, 10 May 2001 02:40:38 -0400 (EDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4A6eeN13762
	for ; Thu, 10 May 2001 08:40:40 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu May 10 08:40:28 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Thu, 10 May 2001 08:40:39 +0200
Message-ID: <795A014AF92DD21182AF0008C7A404320B070397@esealnt117>
From: "Alf Heidermark (UAB)" 
To: "'Tom-PT Taylor'" ,
        "'Christian Groves'"
	 
Cc: Madhu Babu Brahmanapally , megaco@fore.com
Subject: RE: Error Code 505
Date: Thu, 10 May 2001 08:40:31 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

First of all It applies for rott and If you have a TDM termination that has been out of service. It comes no back to service and sends a SEC. I do not think that the termination shall take any commands into considwration until SEC reply is received. In these case it sends error code 505 

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: den 10 maj 2001 06:58
To: 'Christian Groves'
Cc: Madhu Babu Brahmanapally; megaco@fore.com
Subject: RE: Error Code 505



Let me put the opposite question: has anyone up to now thought that terminations are only in service after a ServiceChange announcing their presence?  I think I can see a possible use for such a convention with ATM, but I don't see it applying to any other type of termination.

> -----Original Message----- 
> From: Christian Groves [ mailto:Christian.Groves@ericsson.com  ] 
> Sent: Thursday, May 10, 2001 12:42 AM 
> To: Taylor, Tom-PT [NORSE:B881:EXCH] 
> Cc: Madhu Babu Brahmanapally; megaco@fore.com 
> Subject: Re: Error Code 505 
> 
> 
> You lost me on the first sentence of your reply. Why can't 
> ServiceChange 
> bring up a range of termination for the first time? I don't see any 
> overriding reason that this must only apply to ROOT. 
> 
> Christian 
> 
> Tom-PT Taylor wrote: 
> > 
> > All we're talking about is response to a ServiceChange here -- not a 
> > subsequent ServiceChange indicating a reversion to the previous 
> > state.  I would suggest that 505 should apply only to 
> ServiceChange on 
> > ROOT, not because I have an immediate counter-example for the 
> > alternative, but because it feels like it would be easy to 
> construct a 
> > counter-example. 
> > 
> > > -----Original Message----- 
> > > From: Christian Groves [ mailto:Christian.Groves@ericsson.com  ] 
> > > Sent: Wednesday, May 09, 2001 10:22 PM 
> > > To: Madhu Babu Brahmanapally 
> > > Cc: megaco@fore.com 
> > > Subject: Re: Error Code 505 
> > > 
> > > 
> > > I'd say this is valid also for terminations than root. A 
> > servicechange 
> > > can be applied to individual terminations and this error 
> code is to 
> > > guard trying to change termination characteristics before 
> they have 
> > > restarted. 
> > > 
> > > Christian 
> > > 
> > > Madhu Babu Brahmanapally wrote: 
> > > > 
> > > > HI All, 
> > > > 
> > > > The Error code 505 description is "Transaction Request 
> > > Received before a 
> > > > ServiceChange Reply has been received", does the 
> > > ServiceChange reply here 
> > > > mean the ServiceChange reply on ROOT termination? or is 
> > > this valid for other 
> > > > terminations also. I think the intention is here is 
> > > ServiceChange for ROOT 
> > > > termination. Comments?? 
> > > > 
> > > > Regards 
> > > > Madhubabu 
> > > 
> 



From owner-megaco@fore.com  Thu May 10 03:26:43 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20510
	for ; Thu, 10 May 2001 03:26:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA06520;
	Thu, 10 May 2001 03:20:49 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id DAA09870
	for megaco-list; Thu, 10 May 2001 03:19:57 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA09863
	for ; Thu, 10 May 2001 03:19:55 -0400 (EDT)
Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA06417
	for ; Thu, 10 May 2001 03:19:50 -0400 (EDT)
Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1])
	by ihemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4A7JrV14651
	for ; Thu, 10 May 2001 03:19:53 -0400 (EDT)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
	by ihemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4A7Jqa14637
	for ; Thu, 10 May 2001 03:19:52 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id JAA00095; Thu, 10 May 2001 09:19:51 +0200 (MET DST)
Cc: Michael Brown ,
        "Petros N. Mouchtaris" ,
        megaco , SG16 ,
        Oskar vanDeventer 
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id JAA29974; Thu, 10 May 2001 09:19:46 +0200 (MET DST)
Message-ID: <3AFA419A.DF9A8B8C@lucent.com>
Date: Thu, 10 May 2001 09:22:02 +0200
From: Paul Sijben 
Organization: Lucent technologies, The Netherlands
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom-PT Taylor 
Original-CC: Michael Brown ,
        "Petros N. Mouchtaris" ,
        megaco , SG16 ,
        Oskar vanDeventer 
Subject: Re: IP Type of Service
References: <28560036253BD41191A10000F8BCBD110250CAF0@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

I believe setting of ToS is very specific for the deployment of the gateway
initiating the call. I would be more in favour of a more generic QoS
description that can be used by the MG to determine which ToS value to set
using its local policies.

I suggested something like this in Pittsburgh but was shot down over the use
of the word "domain" or so and the contents of the request (generic QoS
description in SDP) seems to have been lost.

I'll be happy to try and write something like this up over the next few weeks.

Paul

> Tom-PT Taylor wrote:
> 
> However, any changes to SDP have to be done in the IETF, and since QOS
> relates to media streams, it really has to be done in SDP as well as
> anywhere else the ITU-T and other bodies see fit to put it.
> 
> -----Original Message-----
> From: Brown, Michael [NC1:GW10:EXCH]
> Sent: Wednesday, May 09, 2001 4:47 PM
> To: Petros N. Mouchtaris
> Cc: megaco; SG16; Oskar vanDeventer
> Subject: RE: IP Type of Service
> 
> There are at least four contributions to the upcoming Study Group 11 meeting
> (May 14-May 25)related to this topic. If you have ITU TIES access, they are
> under Delayed Contributions 207, 212, 214, and 215.
> 
> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Wednesday, May 09, 2001 1:41 AM
> To: Petros N. Mouchtaris
> Cc: Rosen, Brian; megaco; SG16; Oskar vanDeventer
> Subject: Re: IP Type of Service
> 
> I think that any work on QoS parameters should be aligned with the work
> occuring in ETSI Tiphon, ITU SG16, ITU SG11 etc. There's been a
> considerable amount of effort in trying to come up with common
> parameters for QoS. Any solution should tap into this.
> Cheers, Christian
> "Petros N. Mouchtaris" wrote:
> >
> > Brian,
> >
> > Actually there was a long discussion on this topic last year on the
> mailing
> > list i.e. whether MGC should be able to signal an MG which TOS bit to use.
> 
> > The whole topic ended up being dropped. Check the archive for e-mails with
> 
> > title "MG and DiffServ".
> >
> > By the way, Flemming had volunteered to do some work but I assume it
> didn't
> > have high enough priority.
> >
> > Excerpt from e-mail:
> >
> > "Tom-PT Taylor wrote:
> >
> >                     > You are correct that packages should be drawn up
> (and/or SDP defined) to
> >                     > allow QOS parameter setting.  Volunteers?
> >
> >                     Sure - I can put a package proposal together.
> >
> >                     -- Flemming
> >
> > Petros
> >
> > "Rosen, Brian"  on 05/08/2001 03:29:44 PM
> >
> > To:   "'Tom-PT Taylor'" , "'Madhu Babu
> >       Brahmanapally'" , "Rosen, Brian"
> >       , "'Chuong Nguyen'"
> >       , megaco 
> > cc:    (bcc: Petros N. Mouchtaris/Telcordia)
> > Subject:  RE: IP Type of Service
> >
> > I'll look into this.  I agree.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Tuesday, May 08, 2001 10:07 AM
> > To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen'; megaco
> > Subject: RE: IP Type of Service
> >
> > That makes sense.
> >
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > Sent: Tuesday, May 08, 2001 10:08 AM
> > To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B881:EXCH]; 'Chuong Nguyen';
> > megaco
> > Subject: RE: IP Type of Service
> >
> > Hi All,
> > Another suggestion. Why cant the SDP be extended to incorporate a TOS
> > parameter/attribute so that all the protocols(SIP,Megaco,MGCP) that use
> SDP
> > need not define extra properties/parameter for supporting this.
> >
> > Regards
> > Madhubabu
> >
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> > Sent: Tuesday, May 08, 2001 9:24 AM
> > To: 'Madhu Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen';
> > megaco@fore.com
> > Subject: RE: IP Type of Service
> >
> > I don't agree.  The TOS for a particular stream should be set on that
> > stream, not
> > on the MG as a whole.  For example, if I have a multimedia MG, I will want
> 
> > to set
> > the priority of voice higher than video, and video higher than normal.  If
> 
> > I
> > implement a
> > Multilevel Pre-emption and Priority scheme, some calls will have higher
> > priority than
> > others.  The TOS/frame priority has to be per stream.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > Sent: Tuesday, May 08, 2001 9:24 AM
> > To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; megaco@fore.com
> > Subject: RE: IP Type of Service
> >
> > Hi All,
> >
> > The default TOS type should be defined on the ROOT termination for the
> > default TOS used for all media packets generated from the MG. There should
> 
> > be a method (might be through some property) of specifying stream level
> TOS
> > bits.
> >
> > I'm interested to work on RSVP.
> >
> > Regards
> > Madhubabu
> >
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> > Sent: Tuesday, May 08, 2001 8:10 AM
> > To: 'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco@fore.com'
> > Subject: RE: IP Type of Service
> >
> > TOS should not be ignored at the edge router if the router is configured
> to
> > enable DiffServ.
> >
> > It would be pretty simple to create one package that had the appropriate
> > controls for
> > DiffServ and 802.1p.  RSVP needs it's own package because there is
> > messaging,
> > and you at least an event or two
> >
> > The former could be an enumeration: QosMarking, that had values None, TOS
> > and
> > FramePriority, plus another integer, Value.  That would suffice I think,
> > although you
> > could conceivably get more clever with DiffServ.
> >
> > Shall I write something up along those lines?
> >
> > RSVP takes some more work.  Any volunteers?
> >
> > Brian
> >
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Monday, May 07, 2001 9:15 PM
> > To: 'Chuong Nguyen'; 'megaco@fore.com'
> > Subject: RE: IP Type of Service
> >
> > No such package has yet been defined.
> >
> > Various QOS architectures can be imagined.  Each would give rise to its
> own
> > package, since the MGC-MG information flow would differ from one
> > architecture to the next.  One question: unless the MG is itself the edge
> > router, won't the ToS be ignored when the media packets reach the latter?
> >
> > -----Original Message-----
> > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > Sent: Monday, May 07, 2001 5:14 PM
> > To: 'megaco@fore.com'
> > Subject: IP Type of Service
> >
> > All
> >
> > In MGCP, MGC can specify IP Type of Service to the MG.
> > Do we have an equivalent in Megaco?
> >
> > Is there or has anyone defined a package for IP Type of Service?
> >
> > Thanks
> > Chuong
> >
> > --
> >
> >   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
> >
> >   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
> >
> >   **** The opinions expressed are not those of Alcatel USA, Inc ****
> >
> >   ------------------------------------------------------------------------
> 
> >                Name: att1.htm
> >    att1.htm    Type: Hypertext Markup Language (text/html)
> >            Encoding: base64

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Message:+31 848702874			
Forward Looking Work     Fax: +31 208702874
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)


From owner-megaco@fore.com  Thu May 10 08:32:11 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24074
	for ; Thu, 10 May 2001 08:32:10 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA21667;
	Thu, 10 May 2001 08:23:58 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA18633
	for megaco-list; Thu, 10 May 2001 08:21:59 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA18628
	for ; Thu, 10 May 2001 08:21:57 -0400 (EDT)
Received: from eins.siemens.at (eins.siemens.at [193.81.246.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA21498
	for ; Thu, 10 May 2001 08:21:54 -0400 (EDT)
Received: from scesie13.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at  with ESMTP id f4ACMR218813
	for ; Thu, 10 May 2001 14:22:27 +0200
Received: (from smap@localhost)
	by scesie13.sie.siemens.at (8.9.3/8.9.3) id OAA12264
	for ; Thu, 10 May 2001 14:22:28 +0200 (MET DST)
Received: from vies194a.sie.siemens.at(158.226.134.124) by scesie13 via smap (V2.0beta)
	id xma007046; Thu, 10 May 01 14:19:31 +0200
Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2650.21)
	id ; Thu, 10 May 2001 14:18:54 +0200
Message-ID: 
From: Winter Johannes 
To: megaco@fore.com
Subject: Notifications
Date: Thu, 10 May 2001 14:18:54 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hi List,

I have a short question about notifications sent from the MG to the MGC: 

The communication between MGC and MG is always realized by the exchange of
Transaction Request messages (sent by the MGC) and Transaction Reply
messages (sent by the MG).  The Transaction messages include the
corresponding Command Requests and Replys. 

Is this the same for notifications sent by the MG to the MGC? 
So, does the MG set up a Transaction request (including a NotifyRequest,
Annex A)  with a Transaction ID and receive a corresponding Transaction
reply (with a NotifyReply, optional an empty SEQUENCE) from the MGC? 

If this is true, should section 7.2.7 not changed to:

...
[TerminationID]
[,ErrorDescriptor]
	Notify (TerminationID,
		ObservedEventsDescriptor,
		[ErrorDescriptor])
...


regards

Johannes Winter
Siemens AG Austria



From owner-megaco@fore.com  Thu May 10 09:37:40 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26304
	for ; Thu, 10 May 2001 09:37:26 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA27087;
	Thu, 10 May 2001 09:30:50 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA00474
	for megaco-list; Thu, 10 May 2001 09:27:30 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA00077
	for ; Thu, 10 May 2001 09:20:12 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id JAA25962
	for ; Thu, 10 May 2001 09:15:06 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id JAA27718; Thu, 10 May 2001 09:13:00 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Thu, 10 May 2001 09:12:57 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 10 May 2001 09:12:58 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CAF9@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Winter Johannes'" , megaco@fore.com
Subject: RE: Notifications
Date: Thu, 10 May 2001 09:12:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D952.EEA2B480"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D952.EEA2B480
Content-Type: text/plain;
	charset="ISO-8859-1"

The basic point is reasonable.  We should look carefully at the case where
an errorDescriptor is returned because of a full buffer.

> -----Original Message-----
> From: Winter Johannes [mailto:johannes.winter@siemens.at]
> Sent: Thursday, May 10, 2001 8:19 AM
> To: megaco@fore.com
> Subject: Notifications
> 
> 
> Hi List,
> 
> I have a short question about notifications sent from the MG 
> to the MGC: 
> 
> The communication between MGC and MG is always realized by 
> the exchange of
> Transaction Request messages (sent by the MGC) and Transaction Reply
> messages (sent by the MG).  The Transaction messages include the
> corresponding Command Requests and Replys. 
> 
> Is this the same for notifications sent by the MG to the MGC? 
> So, does the MG set up a Transaction request (including a 
> NotifyRequest,
> Annex A)  with a Transaction ID and receive a corresponding 
> Transaction
> reply (with a NotifyReply, optional an empty SEQUENCE) from the MGC? 
> 
> If this is true, should section 7.2.7 not changed to:
> 
> ...
> [TerminationID]
> [,ErrorDescriptor]
> 	Notify (TerminationID,
> 		ObservedEventsDescriptor,
> 		[ErrorDescriptor])
> ...
> 
> 
> regards
> 
> Johannes Winter
> Siemens AG Austria
> 
> 

------_=_NextPart_001_01C0D952.EEA2B480
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Notifications




The basic point is reasonable.  We should look =
carefully at the case where an errorDescriptor is returned because of a =
full buffer.



> -----Original Message-----

> From: Winter Johannes [mailto:johannes.winter@siemen=
s.at]

> Sent: Thursday, May 10, 2001 8:19 AM

> To: megaco@fore.com

> Subject: Notifications

> 

> 

> Hi List,

> 

> I have a short question about notifications =
sent from the MG 

> to the MGC: 

> 

> The communication between MGC and MG is always =
realized by 

> the exchange of

> Transaction Request messages (sent by the MGC) =
and Transaction Reply

> messages (sent by the MG).  The =
Transaction messages include the

> corresponding Command Requests and Replys. =


> 

> Is this the same for notifications sent by the =
MG to the MGC? 

> So, does the MG set up a Transaction request =
(including a 

> NotifyRequest,

> Annex A)  with a Transaction ID and =
receive a corresponding 

> Transaction

> reply (with a NotifyReply, optional an empty =
SEQUENCE) from the MGC? 

> 

> If this is true, should section 7.2.7 not =
changed to:

> 

> ...

> [TerminationID]

> [,ErrorDescriptor]

>       Notify =
(TerminationID,

>       =
        =
ObservedEventsDescriptor,

>       =
        [ErrorDescriptor])

> ...

> 

> 

> regards

> 

> Johannes Winter

> Siemens AG Austria

> 

> 





------_=_NextPart_001_01C0D952.EEA2B480--


From owner-megaco@fore.com  Thu May 10 09:46:34 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26709
	for ; Thu, 10 May 2001 09:46:29 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA28437;
	Thu, 10 May 2001 09:40:29 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA04627
	for megaco-list; Thu, 10 May 2001 09:37:57 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA04618
	for ; Thu, 10 May 2001 09:37:55 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA28077
	for ; Thu, 10 May 2001 09:37:52 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACH12408;
	Thu, 10 May 2001 09:37:20 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Tom-PT Taylor'" ,
        "'Christian Groves'" 
Cc: 
Subject: RE: Error Code 505
Date: Thu, 10 May 2001 09:42:02 -0400
Message-ID: <006601c0d956$fef5cb70$c500a8c0@MBRAHMANAPALLY>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0067_01C0D935.77E42B70"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <28560036253BD41191A10000F8BCBD110250CAF6@zcard00g.ca.nortel.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0067_01C0D935.77E42B70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: Error Code 505The Error code 521 (Termination is "service changeing") is
no more used. I think the error code Termination is "service Changeing"  and
'Command received before restart response' are functionally merged into the
'Transaction Request received before a service change reply has been
received'.

But if we map the two different scenarios into one error response, we may
not preserve the granular information of actual reason of failure.

Regards
Madhubabu
  -----Original Message-----
  From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
  Sent: Thursday, May 10, 2001 12:58 AM
  To: 'Christian Groves'
  Cc: Madhu Babu Brahmanapally; megaco@fore.com
  Subject: RE: Error Code 505


  Let me put the opposite question: has anyone up to now thought that
terminations are only in service after a ServiceChange announcing their
presence?  I think I can see a possible use for such a convention with ATM,
but I don't see it applying to any other type of termination.

  > -----Original Message-----
  > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
  > Sent: Thursday, May 10, 2001 12:42 AM
  > To: Taylor, Tom-PT [NORSE:B881:EXCH]
  > Cc: Madhu Babu Brahmanapally; megaco@fore.com
  > Subject: Re: Error Code 505
  >
  >
  > You lost me on the first sentence of your reply. Why can't
  > ServiceChange
  > bring up a range of termination for the first time? I don't see any
  > overriding reason that this must only apply to ROOT.
  >
  > Christian
  >
  > Tom-PT Taylor wrote:
  > >
  > > All we're talking about is response to a ServiceChange here -- not a
  > > subsequent ServiceChange indicating a reversion to the previous
  > > state.  I would suggest that 505 should apply only to
  > ServiceChange on
  > > ROOT, not because I have an immediate counter-example for the
  > > alternative, but because it feels like it would be easy to
  > construct a
  > > counter-example.
  > >
  > > > -----Original Message-----
  > > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
  > > > Sent: Wednesday, May 09, 2001 10:22 PM
  > > > To: Madhu Babu Brahmanapally
  > > > Cc: megaco@fore.com
  > > > Subject: Re: Error Code 505
  > > >
  > > >
  > > > I'd say this is valid also for terminations than root. A
  > > servicechange
  > > > can be applied to individual terminations and this error
  > code is to
  > > > guard trying to change termination characteristics before
  > they have
  > > > restarted.
  > > >
  > > > Christian
  > > >
  > > > Madhu Babu Brahmanapally wrote:
  > > > >
  > > > > HI All,
  > > > >
  > > > > The Error code 505 description is "Transaction Request
  > > > Received before a
  > > > > ServiceChange Reply has been received", does the
  > > > ServiceChange reply here
  > > > > mean the ServiceChange reply on ROOT termination? or is
  > > > this valid for other
  > > > > terminations also. I think the intention is here is
  > > > ServiceChange for ROOT
  > > > > termination. Comments??
  > > > >
  > > > > Regards
  > > > > Madhubabu
  > > >
  >


------=_NextPart_000_0067_01C0D935.77E42B70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




RE: Error Code 505




The=20
Error code 521 (Termination is "service changeing") is no more used. I =
think the=20
error code Termination is "service Changeing"  and 'Command =
received before=20
restart response' are functionally merged into the 'Transaction Request =
received=20
before a service change reply has been received'. 


 


But if=20
we map the two different scenarios into one error response, we may not =
preserve=20
the granular information of actual reason of =
failure.


 


Regards


Madhubabu



  
-----Original Message-----
From: Tom-PT Taylor=20
  [mailto:taylor@nortelnetworks.com]
Sent: Thursday, May 10, =
2001=20
  12:58 AM
To: 'Christian Groves'
Cc: Madhu Babu=20
  Brahmanapally; megaco@fore.com
Subject: RE: Error Code=20
  505


  
Let me put the opposite question: has anyone up to =
now thought=20
  that terminations are only in service after a ServiceChange announcing =
their=20
  presence?  I think I can see a possible use for such a convention =
with=20
  ATM, but I don't see it applying to any other type of =
termination.

  
> -----Original Message----- 
>=20
  From: Christian Groves [mailto:Christian.Groves@eri=
csson.com]=20
  
> Sent: Thursday, May 10, 2001 12:42 AM =

> To: Taylor, Tom-PT [NORSE:B881:EXCH] 
>=20
  Cc: Madhu Babu Brahmanapally; megaco@fore.com 
>=20
  Subject: Re: Error Code 505 
> =

> 
> You lost me on the first =
sentence of=20
  your reply. Why can't 
> =
ServiceChange=20
  
> bring up a range of termination for the first =
time? I=20
  don't see any 
> overriding reason that =
this must=20
  only apply to ROOT. 
> 
>=20
  Christian 
> 
> Tom-PT=20
  Taylor wrote: 
> > 
>=20
  > All we're talking about is response to a ServiceChange here -- =
not=20
  a 
> > subsequent ServiceChange =
indicating a=20
  reversion to the previous 
> > =
state.  I=20
  would suggest that 505 should apply only to 
>=20
  ServiceChange on 
> > ROOT, not because =
I have an=20
  immediate counter-example for the 
> >=20
  alternative, but because it feels like it would be easy to =

> construct a 
> >=20
  counter-example. 
> > 
> > > -----Original Message----- 
>=20
  > > From: Christian Groves [mailto:Christian.Groves@eri=
csson.com]=20
  
> > > Sent: Wednesday, May 09, 2001 10:22 =
PM=20
  
> > > To: Madhu Babu Brahmanapally =

> > > Cc: megaco@fore.com 
> >=20
  > Subject: Re: Error Code 505 
> > =
>=20
  
> > > 
> > =
> I'd say=20
  this is valid also for terminations than root. A 
>=20
  > servicechange 
> > > can be =
applied to=20
  individual terminations and this error 
> =
code is=20
  to 
> > > guard trying to change =
termination=20
  characteristics before 
> they have =

> > > restarted. 
> > =
>=20
  
> > > Christian 
> >=20
  > 
> > > Madhu Babu Brahmanapally =

  wrote: 
> > > > 
> > > > HI All, 
> =
> >=20
  > 
> > > > The Error code 505=20
  description is "Transaction Request 
> =
> >=20
  Received before a 
> > > > =
ServiceChange=20
  Reply has been received", does the 
> > =
>=20
  ServiceChange reply here 
> > > > =
mean the=20
  ServiceChange reply on ROOT termination? or is 
>=20
  > > this valid for other 
> > =
> >=20
  terminations also. I think the intention is here is 
> > > ServiceChange for ROOT 
> >=20
  > > termination. Comments?? 
> > =
>=20
  > 
> > > > Regards =

> > > > Madhubabu 
> =
>=20
  > 
> =



------=_NextPart_000_0067_01C0D935.77E42B70--



From owner-megaco@fore.com  Thu May 10 09:58:36 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27123
	for ; Thu, 10 May 2001 09:58:30 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA29947;
	Thu, 10 May 2001 09:52:23 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA08576
	for megaco-list; Thu, 10 May 2001 09:49:45 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA08565
	for ; Thu, 10 May 2001 09:49:44 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA29641
	for ; Thu, 10 May 2001 09:49:41 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACH12540;
	Thu, 10 May 2001 09:49:26 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Winter Johannes'" , 
Cc: 
Subject: RE: Notifications
Date: Thu, 10 May 2001 09:54:06 -0400
Message-ID: <007401c0d958$afc078f0$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi All,

When multiple commands are sent from MGC/MG, there can be error in any of
the commands. The return parameter shown in the command APIs (Section 7.2.1
to 7.2.8) doesn't have any error descriptor. I think [,ErrorDescriptor] can
be part of the descriptors listed as return parameters of each command.

Regards
Madhubabu
-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Winter Johannes
Sent: Thursday, May 10, 2001 8:19 AM
To: megaco@fore.com
Subject: Notifications


Hi List,

I have a short question about notifications sent from the MG to the MGC:

The communication between MGC and MG is always realized by the exchange of
Transaction Request messages (sent by the MGC) and Transaction Reply
messages (sent by the MG).  The Transaction messages include the
corresponding Command Requests and Replys.

Is this the same for notifications sent by the MG to the MGC?
So, does the MG set up a Transaction request (including a NotifyRequest,
Annex A)  with a Transaction ID and receive a corresponding Transaction
reply (with a NotifyReply, optional an empty SEQUENCE) from the MGC?

If this is true, should section 7.2.7 not changed to:

...
[TerminationID]
[,ErrorDescriptor]
	Notify (TerminationID,
		ObservedEventsDescriptor,
		[ErrorDescriptor])
...


regards

Johannes Winter
Siemens AG Austria



From owner-megaco@fore.com  Thu May 10 10:35:29 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28777
	for ; Thu, 10 May 2001 10:35:27 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04071;
	Thu, 10 May 2001 10:26:32 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA21107
	for megaco-list; Thu, 10 May 2001 10:24:02 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21089
	for ; Thu, 10 May 2001 10:23:59 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com ([47.103.122.66])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03804
	for ; Thu, 10 May 2001 10:23:55 -0400 (EDT)
Received: from zrtps06s.us.nortel.com (zrtps06s.us.nortel.com [47.140.48.50])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA27220
	for ; Thu, 10 May 2001 09:24:40 -0500 (CDT)
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com;
          Thu, 10 May 2001 10:24:46 -0400
Received: from zrtpd0jn.us.nortel.com ([47.140.202.35]) 
          by zrtpd004.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id K2181MB2; Thu, 10 May 2001 10:23:44 -0400
Received: from americasm01.nt.com (kboyle.us.nortel.com [47.142.150.95]) 
          by zrtpd0jn.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id J5XGP97A; Thu, 10 May 2001 10:23:45 -0400
Message-ID: <3AFAA427.AD6A355E@americasm01.nt.com>
Date: Thu, 10 May 2001 10:22:31 -0400
X-Sybari-Space: 00000000 00000000 00000000
From: "Kevin Boyle" 
Organization: Nortel Networks
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Madhu Babu Brahmanapally 
CC: "'Winter Johannes'" , megaco ,
        "Tom-PT Taylor" 
Subject: Re: Notifications
References: <007401c0d958$afc078f0$c500a8c0@MBRAHMANAPALLY>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

I believe that there is a note in the IG that states that Error descriptors can
be returned where appropriate, but are not shown in the sample API.

Kevin

Madhu Babu Brahmanapally wrote:

> Hi All,
>
> When multiple commands are sent from MGC/MG, there can be error in any of
> the commands. The return parameter shown in the command APIs (Section 7.2.1
> to 7.2.8) doesn't have any error descriptor. I think [,ErrorDescriptor] can
> be part of the descriptors listed as return parameters of each command.
>
> Regards
> Madhubabu
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Winter Johannes
> Sent: Thursday, May 10, 2001 8:19 AM
> To: megaco@fore.com
> Subject: Notifications
>
> Hi List,
>
> I have a short question about notifications sent from the MG to the MGC:
>
> The communication between MGC and MG is always realized by the exchange of
> Transaction Request messages (sent by the MGC) and Transaction Reply
> messages (sent by the MG).  The Transaction messages include the
> corresponding Command Requests and Replys.
>
> Is this the same for notifications sent by the MG to the MGC?
> So, does the MG set up a Transaction request (including a NotifyRequest,
> Annex A)  with a Transaction ID and receive a corresponding Transaction
> reply (with a NotifyReply, optional an empty SEQUENCE) from the MGC?
>
> If this is true, should section 7.2.7 not changed to:
>
> ...
> [TerminationID]
> [,ErrorDescriptor]
>         Notify (TerminationID,
>                 ObservedEventsDescriptor,
>                 [ErrorDescriptor])
> ...
>
> regards
>
> Johannes Winter
> Siemens AG Austria



From owner-megaco@fore.com  Thu May 10 10:49:12 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29265
	for ; Thu, 10 May 2001 10:49:08 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA27740;
	Thu, 10 May 2001 09:35:07 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA03339
	for megaco-list; Thu, 10 May 2001 09:32:35 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA03319
	for ; Thu, 10 May 2001 09:32:31 -0400 (EDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA27309
	for ; Thu, 10 May 2001 09:32:28 -0400 (EDT)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id IAA21877
	for ; Thu, 10 May 2001 08:32:29 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4ADWST05071
	for ; Thu, 10 May 2001 08:32:28 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4ADVY122399
	for ; Thu, 10 May 2001 08:31:34 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4ADVYO02787
	for ; Thu, 10 May 2001 08:31:34 -0500 (CDT)
Message-ID: <3AFA9836.159BA1F2@usa.alcatel.com>
Date: Thu, 10 May 2001 08:31:34 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Implementors' Guide Update Editor's last Call Section 6.58
References: <3AF8D832.E727C159@ericsson.com> <3AF9C27D.99FD20CD@usa.alcatel.com> <3AF9F936.F7DF2B63@ericsson.com>
Content-Type: multipart/alternative;
 boundary="------------A1D11EF48CCBCE65E5FCF2E2"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------A1D11EF48CCBCE65E5FCF2E2
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id JAA27740
Content-Transfer-Encoding: quoted-printable

See comments below:

Christian Groves wrote:

> G'Day Chuong,
>
> Please see my comments below.
>
> Cheers, Christian
>
> Chuong Nguyen wrote:
> >
> > Christian
> >
> > 6.58 TimeStamp in registration replies
> > =B7 If the Timestamp is not sent by either the MG or the MGC, both si=
des
> > shall keep their original time base.
> >
> > Does this now imply that TimeStamp is not required in ServiceChange
> > registration?
>
> [CHG] No I don't believe it does. The start of this paragraph has alway=
s
> stated "The optional Timestamp...." so there is no change.
>
> >
> > Megaco Text
> > The TimeStamp parameter shall be sent with a registration command and
> > its response.
> >

  What about the above sentence quoted from Section 7.2.8 in the
paragraph where
               registration is described.  The use of the word "shall"
implies "required" to me.

              The paragraph where the word "optional" was used - to me it
meant that not
              all ServiceChange Method requires TimeStamp.  Then follow b=
y
the "registration"
              paragraph which describes how registration is done which
states that TimeStamp
              is required for registration.

             But the change in the IG implies that TimeStamp is not
required in "registration"
             And that is all I am trying to point out.

Thanks
Chuong

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------A1D11EF48CCBCE65E5FCF2E2
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



See comments below:

Christian Groves wrote:

G'Day Chuong,

Please see my comments below.

Cheers, Christian

Chuong Nguyen wrote:

>

> Christian

>

> 6.58 TimeStamp in registration replies

> · If the Timestamp is not sent by either the MG or the MGC,
both sides

> shall keep their original time base.

>

> Does this now imply that TimeStamp is not required in ServiceChange

> registration?

[CHG] No I don't believe it does. The start of this paragraph has always

stated "The optional Timestamp...." so there is no change.

>

> Megaco Text

> The TimeStamp parameter shall be sent with a registration command
and

> its response.

>

<cnn>  What about the above sentence quoted from Section 7.2.8
in the paragraph where

              
registration is described.  The use of the word "shall" implies "required"
to me.

             
The paragraph where the word "optional" was used - to me it meant that
not

             
all ServiceChange Method requires TimeStamp.  Then follow by the "registration"

             
paragraph which describes how registration is done which states that TimeStamp

             
is required for registration.

            
But the change in the IG implies that TimeStamp is not required in "registration"

            
And that is all I am trying to point out.

Thanks

Chuong

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------A1D11EF48CCBCE65E5FCF2E2--



From owner-megaco@fore.com  Thu May 10 10:51:54 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29366
	for ; Thu, 10 May 2001 10:51:52 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA02248;
	Thu, 10 May 2001 10:10:30 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA15455
	for megaco-list; Thu, 10 May 2001 10:07:28 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15093
	for ; Thu, 10 May 2001 10:07:21 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA01786
	for ; Thu, 10 May 2001 10:06:38 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id KAA05458; Thu, 10 May 2001 10:06:35 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 10 May 2001 10:06:19 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 10 May 2001 10:06:21 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CAFB@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Madhu Babu Brahmanapally'" ,
        "'Christian Groves'" 
Cc: megaco 
Subject: RE: Error Code 505
Date: Thu, 10 May 2001 10:06:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D95A.637BDDC0"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D95A.637BDDC0
Content-Type: text/plain;
	charset="ISO-8859-1"

Sorry, I took the usage with respect to ROOT as a given.  I and Christian (I
believe) were talking about the hypothesis that after ROOT comes up,
individual terminations are out of service until they, too, have been
signalled in-service through a ServiceChange exchange.  As your message
shows and mine was meant to point out, this is not the behaviour people are
currently assuming.  Of course, maybe I misunderstood Christian in the first
place.

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Thursday, May 10, 2001 9:47 AM
To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Christian Groves'
Cc: megaco
Subject: RE: Error Code 505


Hi Tom,
Why is this valid only for ATM? The general assumption is that as soon as
the ROOT ServiceChange is complete, all the terminations (irrespective of
type) provisioned at both MG and MGC are in-service. Unless followed by any
ServiceChange for those terminations whose state is out-of-service.
 
Regards
Madhubabu
 
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Thursday, May 10, 2001 12:58 AM
To: 'Christian Groves'
Cc: Madhu Babu Brahmanapally; megaco@fore.com
Subject: RE: Error Code 505


Let me put the opposite question: has anyone up to now thought that
terminations are only in service after a ServiceChange announcing their
presence?  I think I can see a possible use for such a convention with ATM,
but I don't see it applying to any other type of termination.
> -----Original Message----- 
> From: Christian Groves [mailto:Christian.Groves@ericsson.com] 
> Sent: Thursday, May 10, 2001 12:42 AM 
> To: Taylor, Tom-PT [NORSE:B881:EXCH] 
> Cc: Madhu Babu Brahmanapally; megaco@fore.com 
> Subject: Re: Error Code 505 
> 
> 
> You lost me on the first sentence of your reply. Why can't 
> ServiceChange 
> bring up a range of termination for the first time? I don't see any 
> overriding reason that this must only apply to ROOT. 
> 
> Christian 
> 
> Tom-PT Taylor wrote: 
> > 
> > All we're talking about is response to a ServiceChange here -- not a 
> > subsequent ServiceChange indicating a reversion to the previous 
> > state.  I would suggest that 505 should apply only to 
> ServiceChange on 
> > ROOT, not because I have an immediate counter-example for the 
> > alternative, but because it feels like it would be easy to 
> construct a 
> > counter-example. 
> > 
> > > -----Original Message----- 
> > > From: Christian Groves [mailto:Christian.Groves@ericsson.com] 
> > > Sent: Wednesday, May 09, 2001 10:22 PM 
> > > To: Madhu Babu Brahmanapally 
> > > Cc: megaco@fore.com 
> > > Subject: Re: Error Code 505 
> > > 
> > > 
> > > I'd say this is valid also for terminations than root. A 
> > servicechange 
> > > can be applied to individual terminations and this error 
> code is to 
> > > guard trying to change termination characteristics before 
> they have 
> > > restarted. 
> > > 
> > > Christian 
> > > 
> > > Madhu Babu Brahmanapally wrote: 
> > > > 
> > > > HI All, 
> > > > 
> > > > The Error code 505 description is "Transaction Request 
> > > Received before a 
> > > > ServiceChange Reply has been received", does the 
> > > ServiceChange reply here 
> > > > mean the ServiceChange reply on ROOT termination? or is 
> > > this valid for other 
> > > > terminations also. I think the intention is here is 
> > > ServiceChange for ROOT 
> > > > termination. Comments?? 
> > > > 
> > > > Regards 
> > > > Madhubabu 
> > > 
> 

------_=_NextPart_001_01C0D95A.637BDDC0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Error Code 505




Sorry, I took the usage with respect to ROOT as a =
given.  I and Christian (I believe) were talking about the =
hypothesis that after ROOT comes up, individual terminations are out of =
service until they, too, have been signalled in-service through a =
ServiceChange exchange.  As your message shows and mine was meant =
to point out, this is not the behaviour people are currently =
assuming.  Of course, maybe I misunderstood Christian in the first =
place.



-----Original Message-----

From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]<=
/FONT>

Sent: Thursday, May 10, 2001 9:47 AM

To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Christian =
Groves'

Cc: megaco

Subject: RE: Error Code 505






Hi Tom,

Why is this valid only for ATM? The general =
assumption is that as soon as the ROOT ServiceChange is complete, all =
the terminations (irrespective of type) provisioned at both MG and MGC =
are in-service. Unless followed by any ServiceChange for those =
terminations whose state is out-of-service.



 

Regards

Madhubabu

 

-----Original Message-----

From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c=
om]

Sent: Thursday, May 10, 2001 12:58 AM

To: 'Christian Groves'

Cc: Madhu Babu Brahmanapally; megaco@fore.com

Subject: RE: Error Code 505






Let me put the opposite question: has anyone up to =
now thought that terminations are only in service after a ServiceChange =
announcing their presence?  I think I can see a possible use for =
such a convention with ATM, but I don't see it applying to any other =
type of termination.



> -----Original Message----- 

> From: Christian Groves [mailto:Christian.Groves@er=
icsson.com] 

> Sent: Thursday, May 10, 2001 12:42 AM 

> To: Taylor, Tom-PT [NORSE:B881:EXCH] 

> Cc: Madhu Babu Brahmanapally; megaco@fore.com =


> Subject: Re: Error Code 505 

> 

> 

> You lost me on the first sentence of your =
reply. Why can't 

> ServiceChange 

> bring up a range of termination for the first =
time? I don't see any 

> overriding reason that this must only apply to =
ROOT. 

> 

> Christian 

> 

> Tom-PT Taylor wrote: 

> > 

> > All we're talking about is response to a =
ServiceChange here -- not a 

> > subsequent ServiceChange indicating a =
reversion to the previous 

> > state.  I would suggest that 505 =
should apply only to 

> ServiceChange on 

> > ROOT, not because I have an immediate =
counter-example for the 

> > alternative, but because it feels like it =
would be easy to 

> construct a 

> > counter-example. 

> > 

> > > -----Original Message----- 

> > > From: Christian Groves [mailto:Christian.Groves@er=
icsson.com] 

> > > Sent: Wednesday, May 09, 2001 10:22 =
PM 

> > > To: Madhu Babu Brahmanapally 

> > > Cc: megaco@fore.com 

> > > Subject: Re: Error Code 505 

> > > 

> > > 

> > > I'd say this is valid also for =
terminations than root. A 

> > servicechange 

> > > can be applied to individual =
terminations and this error 

> code is to 

> > > guard trying to change termination =
characteristics before 

> they have 

> > > restarted. 

> > > 

> > > Christian 

> > > 

> > > Madhu Babu Brahmanapally wrote: =


> > > > 

> > > > HI All, 

> > > > 

> > > > The Error code 505 description =
is "Transaction Request 

> > > Received before a 

> > > > ServiceChange Reply has been =
received", does the 

> > > ServiceChange reply here 

> > > > mean the ServiceChange reply on =
ROOT termination? or is 

> > > this valid for other 

> > > > terminations also. I think the =
intention is here is 

> > > ServiceChange for ROOT 

> > > > termination. Comments?? 

> > > > 

> > > > Regards 

> > > > Madhubabu 

> > > 

> 





------_=_NextPart_001_01C0D95A.637BDDC0--


From owner-megaco@fore.com  Thu May 10 10:53:09 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29405
	for ; Thu, 10 May 2001 10:53:05 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA06474;
	Thu, 10 May 2001 10:47:01 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA27573
	for megaco-list; Thu, 10 May 2001 10:44:19 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA27567
	for ; Thu, 10 May 2001 10:44:17 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA06163
	for ; Thu, 10 May 2001 10:44:14 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id KAA10307; Thu, 10 May 2001 10:44:11 -0400
Received: from ztcfd004.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 10 May 2001 10:43:52 -0400
Received: by ztcfd004.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 10 May 2001 10:43:52 -0400
Message-ID: <45D2A43C1913D51180F40000F89CB874062DFA@nrtpde0a.us.nortel.com>
From: "Michael Brown" 
To: "Petros N. Mouchtaris" 
Cc: megaco , SG16 ,
        Oskar vanDeventer 
Subject: RE: IP Type of Service
Date: Thu, 10 May 2001 10:43:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D95F.A0AB1120"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D95F.A0AB1120
Content-Type: text/plain;
	charset="iso-8859-1"

The contributions do indeed suggest that the work in SG 11 be coordinated
with SG 16 and IETF.

-----Original Message-----
From: Taylor, Tom-PT [NORSE:B881:EXCH] 
Sent: Wednesday, May 09, 2001 11:41 PM
To: Brown, Michael [NC1:GW10:EXCH]; Petros N. Mouchtaris
Cc: megaco; SG16; Oskar vanDeventer
Subject: RE: IP Type of Service


However, any changes to SDP have to be done in the IETF, and since QOS
relates to media streams, it really has to be done in SDP as well as
anywhere else the ITU-T and other bodies see fit to put it.

-----Original Message-----
From: Brown, Michael [NC1:GW10:EXCH] 
Sent: Wednesday, May 09, 2001 4:47 PM
To: Petros N. Mouchtaris
Cc: megaco; SG16; Oskar vanDeventer
Subject: RE: IP Type of Service


There are at least four contributions to the upcoming Study Group 11 meeting
(May 14-May 25)related to this topic. If you have ITU TIES access, they are
under Delayed Contributions 207, 212, 214, and 215.
-----Original Message----- 
From: Christian Groves [mailto:Christian.Groves@ericsson.com] 
Sent: Wednesday, May 09, 2001 1:41 AM 
To: Petros N. Mouchtaris 
Cc: Rosen, Brian; megaco; SG16; Oskar vanDeventer 
Subject: Re: IP Type of Service 


I think that any work on QoS parameters should be aligned with the work 
occuring in ETSI Tiphon, ITU SG16, ITU SG11 etc. There's been a 
considerable amount of effort in trying to come up with common 
parameters for QoS. Any solution should tap into this. 
Cheers, Christian 
"Petros N. Mouchtaris" wrote: 
> 
> Brian, 
> 
> Actually there was a long discussion on this topic last year on the
mailing 
> list i.e. whether MGC should be able to signal an MG which TOS bit to use.

> The whole topic ended up being dropped. Check the archive for e-mails with

> title "MG and DiffServ". 
> 
> By the way, Flemming had volunteered to do some work but I assume it
didn't 
> have high enough priority. 
> 
> Excerpt from e-mail: 
> 
> "Tom-PT Taylor wrote: 
> 
>                     > You are correct that packages should be drawn up
(and/or SDP defined) to 
>                     > allow QOS parameter setting.  Volunteers? 
> 
>                     Sure - I can put a package proposal together. 
> 
>                     -- Flemming 
> 
> Petros 
> 
> "Rosen, Brian"  on 05/08/2001 03:29:44 PM 
> 
> To:   "'Tom-PT Taylor'" , "'Madhu Babu 
>       Brahmanapally'" , "Rosen, Brian" 
>       , "'Chuong Nguyen'" 
>       , megaco  
> cc:    (bcc: Petros N. Mouchtaris/Telcordia) 
> Subject:  RE: IP Type of Service 
> 
> I'll look into this.  I agree. 
> 
> Brian 
> 
> -----Original Message----- 
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] 
> Sent: Tuesday, May 08, 2001 10:07 AM 
> To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen'; megaco 
> Subject: RE: IP Type of Service 
> 
> That makes sense. 
> 
> -----Original Message----- 
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] 
> Sent: Tuesday, May 08, 2001 10:08 AM 
> To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B881:EXCH]; 'Chuong Nguyen'; 
> megaco 
> Subject: RE: IP Type of Service 
> 
> Hi All, 
> Another suggestion. Why cant the SDP be extended to incorporate a TOS 
> parameter/attribute so that all the protocols(SIP,Megaco,MGCP) that use
SDP 
> need not define extra properties/parameter for supporting this. 
> 
> Regards 
> Madhubabu 
> 
> -----Original Message----- 
> From: owner-megaco@pit.comms.marconi.com 
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian 
> Sent: Tuesday, May 08, 2001 9:24 AM 
> To: 'Madhu Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen'; 
> megaco@fore.com 
> Subject: RE: IP Type of Service 
> 
> I don't agree.  The TOS for a particular stream should be set on that 
> stream, not 
> on the MG as a whole.  For example, if I have a multimedia MG, I will want

> to set 
> the priority of voice higher than video, and video higher than normal.  If

> I 
> implement a 
> Multilevel Pre-emption and Priority scheme, some calls will have higher 
> priority than 
> others.  The TOS/frame priority has to be per stream. 
> 
> Brian 
> 
> -----Original Message----- 
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] 
> Sent: Tuesday, May 08, 2001 9:24 AM 
> To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; megaco@fore.com 
> Subject: RE: IP Type of Service 
> 
> Hi All, 
> 
> The default TOS type should be defined on the ROOT termination for the 
> default TOS used for all media packets generated from the MG. There should

> be a method (might be through some property) of specifying stream level
TOS 
> bits. 
> 
> I'm interested to work on RSVP. 
> 
> Regards 
> Madhubabu 
> 
> -----Original Message----- 
> From: owner-megaco@pit.comms.marconi.com 
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian 
> Sent: Tuesday, May 08, 2001 8:10 AM 
> To: 'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco@fore.com' 
> Subject: RE: IP Type of Service 
> 
> TOS should not be ignored at the edge router if the router is configured
to 
> enable DiffServ. 
> 
> It would be pretty simple to create one package that had the appropriate 
> controls for 
> DiffServ and 802.1p.  RSVP needs it's own package because there is 
> messaging, 
> and you at least an event or two 
> 
> The former could be an enumeration: QosMarking, that had values None, TOS 
> and 
> FramePriority, plus another integer, Value.  That would suffice I think, 
> although you 
> could conceivably get more clever with DiffServ. 
> 
> Shall I write something up along those lines? 
> 
> RSVP takes some more work.  Any volunteers? 
> 
> Brian 
> 
> -----Original Message----- 
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] 
> Sent: Monday, May 07, 2001 9:15 PM 
> To: 'Chuong Nguyen'; 'megaco@fore.com' 
> Subject: RE: IP Type of Service 
> 
> No such package has yet been defined. 
> 
> Various QOS architectures can be imagined.  Each would give rise to its
own 
> package, since the MGC-MG information flow would differ from one 
> architecture to the next.  One question: unless the MG is itself the edge 
> router, won't the ToS be ignored when the media packets reach the latter? 
> 
> -----Original Message----- 
> From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com] 
> Sent: Monday, May 07, 2001 5:14 PM 
> To: 'megaco@fore.com' 
> Subject: IP Type of Service 
> 
> All 
> 
> In MGCP, MGC can specify IP Type of Service to the MG. 
> Do we have an equivalent in Megaco? 
> 
> Is there or has anyone defined a package for IP Type of Service? 
> 
> Thanks 
> Chuong 
> 
> -- 
> 
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com 
> 
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613 
> 
>   **** The opinions expressed are not those of Alcatel USA, Inc **** 
> 
>   ------------------------------------------------------------------------

>                Name: att1.htm 
>    att1.htm    Type: Hypertext Markup Language (text/html) 
>            Encoding: base64 

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






RE: IP Type of Service




The contributions do indeed suggest that the work in =
SG 11 be coordinated with SG 16 and IETF.




-----Original Message-----

From: Taylor, Tom-PT [NORSE:B881:EXCH] 

Sent: Wednesday, May 09, 2001 11:41 PM

To: Brown, Michael [NC1:GW10:EXCH]; Petros N. =
Mouchtaris

Cc: megaco; SG16; Oskar vanDeventer

Subject: RE: IP Type of Service






However, any changes to SDP have to be done in the =
IETF, and since QOS relates to media streams, it really has to be done =
in SDP as well as anywhere else the ITU-T and other bodies see fit to =
put it.



-----Original Message-----

From: Brown, Michael [NC1:GW10:EXCH] 

Sent: Wednesday, May 09, 2001 4:47 PM

To: Petros N. Mouchtaris

Cc: megaco; SG16; Oskar vanDeventer

Subject: RE: IP Type of Service






There are at least four contributions to the upcoming =
Study Group 11 meeting (May 14-May 25)related to this topic. If you =
have ITU TIES access, they are under Delayed Contributions 207, 212, =
214, and 215.



-----Original Message----- 

From: Christian Groves [mailto:Christian.Groves@er=
icsson.com] 

Sent: Wednesday, May 09, 2001 1:41 AM 

To: Petros N. Mouchtaris 

Cc: Rosen, Brian; megaco; SG16; Oskar vanDeventer =


Subject: Re: IP Type of Service 






I think that any work on QoS parameters should be =
aligned with the work 

occuring in ETSI Tiphon, ITU SG16, ITU SG11 etc. =
There's been a 

considerable amount of effort in trying to come up =
with common 

parameters for QoS. Any solution should tap into =
this. 

Cheers, Christian 

"Petros N. Mouchtaris" wrote: 

> 

> Brian, 

> 

> Actually there was a long discussion on this =
topic last year on the mailing 

> list i.e. whether MGC should be able to signal =
an MG which TOS bit to use. 

> The whole topic ended up being dropped. Check =
the archive for e-mails with 

> title "MG and DiffServ". 

> 

> By the way, Flemming had volunteered to do some =
work but I assume it didn't 

> have high enough priority. 

> 

> Excerpt from e-mail: 

> 

> "Tom-PT Taylor wrote: 

> 

>          =
;           > You =
are correct that packages should be drawn up (and/or SDP defined) to =


>          =
;           > =
allow QOS parameter setting.  Volunteers? 

> 

>          =
;           Sure - I =
can put a package proposal together. 

> 

>          =
;           -- =
Flemming 

> 

> Petros 

> 

> "Rosen, Brian" =
<Brian.Rosen@marconi.com> on 05/08/2001 03:29:44 PM 

> 

> To:   "'Tom-PT Taylor'" =
<taylor@nortelnetworks.com>, "'Madhu Babu 

>       =
Brahmanapally'" <madhubabu@kenetec.com>, "Rosen, =
Brian" 

>       =
<Brian.Rosen@marconi.com>, "'Chuong Nguyen'" 

>       =
<Chuong.Nguyen@usa.alcatel.com>, megaco <megaco@fore.com> =


> cc:    (bcc: Petros N. =
Mouchtaris/Telcordia) 

> Subject:  RE: IP Type of Service 

> 

> I'll look into this.  I agree. 

> 

> Brian 

> 

> -----Original Message----- 

> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c=
om] 

> Sent: Tuesday, May 08, 2001 10:07 AM 

> To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; =
'Chuong Nguyen'; megaco 

> Subject: RE: IP Type of Service 

> 

> That makes sense. 

> 

> -----Original Message----- 

> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] =


> Sent: Tuesday, May 08, 2001 10:08 AM 

> To: 'Rosen, Brian'; Taylor, Tom-PT =
[NORSE:B881:EXCH]; 'Chuong Nguyen'; 

> megaco 

> Subject: RE: IP Type of Service 

> 

> Hi All, 

> Another suggestion. Why cant the SDP be =
extended to incorporate a TOS 

> parameter/attribute so that all the =
protocols(SIP,Megaco,MGCP) that use SDP 

> need not define extra properties/parameter for =
supporting this. 

> 

> Regards 

> Madhubabu 

> 

> -----Original Message----- 

> From: owner-megaco@pit.comms.marconi.com =


> [mailto:owner-megaco@p=
it.comms.marconi.com]On Behalf Of Rosen, Brian 

> Sent: Tuesday, May 08, 2001 9:24 AM 

> To: 'Madhu Babu Brahmanapally'; 'Tom-PT =
Taylor'; 'Chuong Nguyen'; 

> megaco@fore.com 

> Subject: RE: IP Type of Service 

> 

> I don't agree.  The TOS for a particular =
stream should be set on that 

> stream, not 

> on the MG as a whole.  For example, if I =
have a multimedia MG, I will want 

> to set 

> the priority of voice higher than video, and =
video higher than normal.  If 

> I 

> implement a 

> Multilevel Pre-emption and Priority scheme, =
some calls will have higher 

> priority than 

> others.  The TOS/frame priority has to be =
per stream. 

> 

> Brian 

> 

> -----Original Message----- 

> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] =


> Sent: Tuesday, May 08, 2001 9:24 AM 

> To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong =
Nguyen'; megaco@fore.com 

> Subject: RE: IP Type of Service 

> 

> Hi All, 

> 

> The default TOS type should be defined on the =
ROOT termination for the 

> default TOS used for all media packets =
generated from the MG. There should 

> be a method (might be through some property) of =
specifying stream level TOS 

> bits. 

> 

> I'm interested to work on RSVP. 

> 

> Regards 

> Madhubabu 

> 

> -----Original Message----- 

> From: owner-megaco@pit.comms.marconi.com =


> [mailto:owner-megaco@p=
it.comms.marconi.com]On Behalf Of Rosen, Brian 

> Sent: Tuesday, May 08, 2001 8:10 AM 

> To: 'Tom-PT Taylor'; 'Chuong Nguyen'; =
'megaco@fore.com' 

> Subject: RE: IP Type of Service 

> 

> TOS should not be ignored at the edge router if =
the router is configured to 

> enable DiffServ. 

> 

> It would be pretty simple to create one package =
that had the appropriate 

> controls for 

> DiffServ and 802.1p.  RSVP needs it's own =
package because there is 

> messaging, 

> and you at least an event or two 

> 

> The former could be an enumeration: QosMarking, =
that had values None, TOS 

> and 

> FramePriority, plus another integer, =
Value.  That would suffice I think, 

> although you 

> could conceivably get more clever with =
DiffServ. 

> 

> Shall I write something up along those lines? =


> 

> RSVP takes some more work.  Any =
volunteers? 

> 

> Brian 

> 

> -----Original Message----- 

> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c=
om] 

> Sent: Monday, May 07, 2001 9:15 PM 

> To: 'Chuong Nguyen'; 'megaco@fore.com' 

> Subject: RE: IP Type of Service 

> 

> No such package has yet been defined. 

> 

> Various QOS architectures can be =
imagined.  Each would give rise to its own 

> package, since the MGC-MG information flow =
would differ from one 

> architecture to the next.  One question: =
unless the MG is itself the edge 

> router, won't the ToS be ignored when the media =
packets reach the latter? 

> 

> -----Original Message----- 

> From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.a=
lcatel.com] 

> Sent: Monday, May 07, 2001 5:14 PM 

> To: 'megaco@fore.com' 

> Subject: IP Type of Service 

> 

> All 

> 

> In MGCP, MGC can specify IP Type of Service to =
the MG. 

> Do we have an equivalent in Megaco? 

> 

> Is there or has anyone defined a package for IP =
Type of Service? 

> 

> Thanks 

> Chuong 

> 

> -- 

> 

>   Alcatel USA, =
Inc           &nb=
sp; Internet: Chuong.Nguyen@usa.alcatel.com 

> 

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

> 

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

> 

>   =
------------------------------------------------------------------------=
 

>          =
;      Name: att1.htm 

>    att1.htm    =
Type: Hypertext Markup Language (text/html) 

>          =
;  Encoding: base64 





------_=_NextPart_001_01C0D95F.A0AB1120--


From owner-megaco@fore.com  Thu May 10 10:57:15 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29592
	for ; Thu, 10 May 2001 10:57:11 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA06845;
	Thu, 10 May 2001 10:49:07 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA28269
	for megaco-list; Thu, 10 May 2001 10:46:17 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA28250
	for ; Thu, 10 May 2001 10:46:15 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA06333
	for ; Thu, 10 May 2001 10:46:07 -0400 (EDT)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f4AEk8O29795
	for ; Thu, 10 May 2001 16:46:08 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu May 10 16:45:40 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Thu, 10 May 2001 16:40:45 +0200
Message-ID: <795A014AF92DD21182AF0008C7A404320B0703A2@esealnt117>
From: "Alf Heidermark (UAB)" 
To: "'Krishna Gundamaraju'" ,
        Tom-PT Taylor
	 ,
        "'Madhu Babu Brahmanapally'"
	 ,
        "'Christian Groves'"
	 
Cc: megaco 
Subject: RE: Error Code 505
Date: Thu, 10 May 2001 16:45:36 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hello
 
If you look in the proposed Annex L you can find for different service change reason what the state of each concened terminastions is. 

-----Original Message-----
From: Krishna Gundamaraju [mailto:krishna.gundamaraju@kenetec.com]
Sent: den 10 maj 2001 16:38
To: Tom-PT Taylor; 'Madhu Babu Brahmanapally'; 'Christian Groves'
Cc: megaco
Subject: Re: Error Code 505


Hi All,
 
    All along we were thinking that the ROOT ServiceChange implies that all the provisioned terminations are inservice. The Protocol should clearly state what is the correct behavior as otherwise there could be very serious interoperability issues.
 
Regards,
Krishna G

----- Original Message ----- 
From: Tom-PT Taylor   
To: 'Madhu   Babu Brahmanapally' ; 'Christian Groves'   
Cc: megaco   
Sent: Thursday, May 10, 2001 10:06 AM
Subject: RE: Error Code 505


Sorry, I took the usage with respect to ROOT as a given.  I and Christian (I believe) were talking about the hypothesis that after ROOT comes up, individual terminations are out of service until they, too, have been signalled in-service through a ServiceChange exchange.  As your message shows and mine was meant to point out, this is not the behaviour people are currently assuming.  Of course, maybe I misunderstood Christian in the first place.

-----Original Message----- 
From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com  ] 
Sent: Thursday, May 10, 2001 9:47 AM 
To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Christian Groves' 
Cc: megaco 
Subject: RE: Error Code 505 


Hi Tom, 
Why is this valid only for ATM? The general assumption is that as soon as the ROOT ServiceChange is complete, all the terminations (irrespective of type) provisioned at both MG and MGC are in-service. Unless followed by any ServiceChange for those terminations whose state is out-of-service.

  
Regards 
Madhubabu 
  
-----Original Message----- 
From: Tom-PT Taylor [ mailto:taylor@nortelnetworks.com  ] 
Sent: Thursday, May 10, 2001 12:58 AM 
To: 'Christian Groves' 
Cc: Madhu Babu Brahmanapally; megaco@fore.com 
Subject: RE: Error Code 505 


Let me put the opposite question: has anyone up to now thought that terminations are only in service after a ServiceChange announcing their presence?  I think I can see a possible use for such a convention with ATM, but I don't see it applying to any other type of termination.

> -----Original Message----- 
> From: Christian Groves [ mailto:Christian.Groves@ericsson.com  ] 
> Sent: Thursday, May 10, 2001 12:42 AM 
> To: Taylor, Tom-PT [NORSE:B881:EXCH] 
> Cc: Madhu Babu Brahmanapally; megaco@fore.com 
> Subject: Re: Error Code 505 
> 
> 
> You lost me on the first sentence of your reply. Why can't 
> ServiceChange 
> bring up a range of termination for the first time? I don't see any 
> overriding reason that this must only apply to ROOT. 
> 
> Christian 
> 
> Tom-PT Taylor wrote: 
> > 
> > All we're talking about is response to a ServiceChange here -- not a 
> > subsequent ServiceChange indicating a reversion to the previous 
> > state.  I would suggest that 505 should apply only to 
> ServiceChange on 
> > ROOT, not because I have an immediate counter-example for the 
> > alternative, but because it feels like it would be easy to 
> construct a 
> > counter-example. 
> > 
> > > -----Original Message----- 
> > > From: Christian Groves [ mailto:Christian.Groves@ericsson.com  ] 
> > > Sent: Wednesday, May 09, 2001 10:22 PM 
> > > To: Madhu Babu Brahmanapally 
> > > Cc: megaco@fore.com 
> > > Subject: Re: Error Code 505 
> > > 
> > > 
> > > I'd say this is valid also for terminations than root. A 
> > servicechange 
> > > can be applied to individual terminations and this error 
> code is to 
> > > guard trying to change termination characteristics before 
> they have 
> > > restarted. 
> > > 
> > > Christian 
> > > 
> > > Madhu Babu Brahmanapally wrote: 
> > > > 
> > > > HI All, 
> > > > 
> > > > The Error code 505 description is "Transaction Request 
> > > Received before a 
> > > > ServiceChange Reply has been received", does the 
> > > ServiceChange reply here 
> > > > mean the ServiceChange reply on ROOT termination? or is 
> > > this valid for other 
> > > > terminations also. I think the intention is here is 
> > > ServiceChange for ROOT 
> > > > termination. Comments?? 
> > > > 
> > > > Regards 
> > > > Madhubabu 
> > > 
> 



From owner-megaco@fore.com  Thu May 10 11:00:22 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29746
	for ; Thu, 10 May 2001 11:00:19 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07484;
	Thu, 10 May 2001 10:54:16 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA00632
	for megaco-list; Thu, 10 May 2001 10:51:35 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA00598
	for ; Thu, 10 May 2001 10:51:26 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07140
	for ; Thu, 10 May 2001 10:51:22 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4AEpOK20811
	for ; Thu, 10 May 2001 10:51:24 -0400 (EDT)
Received: from openetsrv.ho.lucent.com (h135-17-127-229.lucent.com [135.17.127.229])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4AEpNu20796
	for ; Thu, 10 May 2001 10:51:23 -0400 (EDT)
Received: from openetpc011 by openetsrv.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id KAA14211; Thu, 10 May 2001 10:46:06 -0400 (EDT)
From: "Raju" 
To: 
Subject: 'EventBufferDescriptor' event handling 
Date: Thu, 10 May 2001 10:59:28 -0400
Message-ID: 
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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,

This is attempt to resume the discussion on EventBufferDescriptor(EBD),
EventDescriptor(ED), EveventBufferControl(EBC) handling.

According to H.248 standard Add/Modify/Move commands can have both ED and
EBD (with EBC set to LockStep).


I guess the Gateways should process the events as follows:
1. An Event is detected
2. If ED is present
     Do regular processing (may result in Notify)
     If Notify is done
          if EBD is present and EBC is LockStep
                deactivate the ED (and this  'activates' EBD)
   else
     if EBD is present and EBC set to LockStep
        Buffer events (no Notify)
    Goto Step 1
3. These buffered events, if any, are processed when a new ED is loaded.
    The processing of these events is very similar to regular events.
    Steps in processing events in EB:
    a. Activate new ED
    b. For each event in EBD goto Step 2.
        This time (also) Step 2 might result in deactivating ED and
(re)activating the EBD if a Notify happens.
         The digitMap rules (partial match, no match, timing(?)) apply while
handling the EBD events, i.e. If the EBD events result in partial match,
         this partial match string is also used (not discarded!) for the
digitMap when new (DTMF) events are detected.


Please send your comments.
Thanks
Raju



Date:         Fri, 19 Jan 2001 10:54:47 +0530
Reply-To:     sgautam@HSS.HNS.COM
Sender:       "Media Gateway Control (megaco)"
              
From:         Sandeep Gautam 
Subject:      Re: FW: [MEGACO] Questions relating event processing and
LockStep
X-To:         Tom-PT Taylor 
Content-type: text/plain; charset=us-ascii

G' Day Tom,

I think there are still some issues that remain unresolved.

I. The scenerio that you are referring to ( starting from step 0) assumes
that
events descriptor was active and EBCP was set to lockstep. What happens when
the
EBD was active and EBCP was set to lockstep ? Is it a NO OP or do we start
from
step 0. Starting from step 0 seems more consistent approach.

II. You referred to activation of embedded ED in step 4, leading to step 4a,
where we return to step 1. This seems a consistent solution. But this is not
the
only occasion that an embeedded ED can become activated. An embedded ED may
become activated in step 9 (i.e when an event in the FIFO buffer matches the
new
ED, and the new ED contains and embedded ED for that event). This would lead
to
a step 9a, where we should return  to step 8a (a new ED is activated).

III. Theonly other quabble is with regard to step 10. I guess, to follow a
more
consistent approach, we should rephrase this as---
step 10: If an event was matched in step 9, it is reported to MGC and
processing
returns to step 4 If an event was not matched, processing returns to step 0.
This way we will be ensuring that the MGC always knows the exact time when
the
buffering of events had started. (i.e. after the first event notification
was
sent for the ED).
Maybe we should add the algorithm for EBCP lockstep processing in the
implementor's guide.

Thanx.

Regards,
Sandy G






>
>    Hi All,
>    A couple of things about LockStep use doesn't seems clear
> to me in the
>    text:
>
>    "If the value of the EventBufferControl property equals LockStep,
>    following detection of such an event, normal handling of events is
>    suspended. Any event which is subsequently detected and
> occurs in the
>    EventBuffer Descriptor is added to the end of the
> EventBuffer (a FIFO
>    queue), along with the time that it was detected."
>
>    It seems from this that the first event that is detected after
> EventBufferControl
>    is set to LockStep is still process normally, and only
> subsequent events
> are added
>    to the buffer. Is this true ? If so, what is the purpose
> of this behavior
> ?

[PTT] This is not true.  Here is what happens, step by step:
   (0) An EventsDescriptor is active and the MG is waiting for an event.
   (1) Event is detected.
   (2) Event is checked against the currently active EventsDescriptor and
found to be present.  (If it is not present in the EventsDescriptor, it is
ignored, and the system returns to step (0)).
   (3) Event is reported to the MGC.
   (4) The current EventsDescriptor is deactivated.
   (5) Another event is detected.
   (6) Event is checked against the EventBufferDescriptor and found to be
present.
   (7) Event is placed in the EventBuffer.
    [other events may be detected and queued in the EventBuffer.]
   (8+} A new EventsDescriptor is activated.
   (9) The queued events in the EventBuffer are checked in sequence against
the new EventsDescriptor and discarded until a match is found.  Events which
arrived after the matching one are left untouched in the EventBuffer.
   (10) The matching event (if any) is reported to the MGC and the cycle
goes back to step (4).

As you can see, the event detected in step (5) gets different treatment from
the event detected in step (1).


>
>    "The MG SHALL wait for a new EventsDescriptor to be loaded.
>    A new EventsDescriptor can be loaded either as the result of
>    receiving a command with a new EventsDescriptor, or by activating
>    an embedded EventsDescriptor."
>
>    How can an embedded EventsDescriptor get activated ? The
> EventBuffer
> Descriptor syntax
>    doesn't include embedded EventsDescriptor. Is this an
> omission ? If not,
> please explain
>    how can an embedded EventsDescriptor be activated.

[PTT] This covers the case when an embedded EventsDescriptor was present in
the EventsDescriptor which was initially active.  In other words, step (4)
above should actually be followed by step (4a): If the EventsDescriptor just
deactivated contained an embedded EventsDescriptor, the latter becomes
active and processing returns to step (0).
>
>    Thanks
>
>    Dan Elbert
>    RADVISION
>





From owner-megaco@fore.com  Thu May 10 11:08:47 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00052
	for ; Thu, 10 May 2001 11:08:45 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA29289;
	Thu, 10 May 2001 09:46:51 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA06328
	for megaco-list; Thu, 10 May 2001 09:43:17 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA06276
	for ; Thu, 10 May 2001 09:42:43 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA28746
	for ; Thu, 10 May 2001 09:42:38 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACH12465;
	Thu, 10 May 2001 09:42:27 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Tom-PT Taylor'" ,
        "'Christian Groves'" 
Cc: 
Subject: RE: Error Code 505
Date: Thu, 10 May 2001 09:47:09 -0400
Message-ID: <006f01c0d957$b641ed90$c500a8c0@MBRAHMANAPALLY>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0070_01C0D936.2F304D90"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <28560036253BD41191A10000F8BCBD110250CAF6@zcard00g.ca.nortel.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0070_01C0D936.2F304D90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: Error Code 505Hi Tom,
Why is this valid only for ATM? The general assumption is that as soon as
the ROOT ServiceChange is complete, all the terminations (irrespective of
type) provisioned at both MG and MGC are in-service. Unless followed by any
ServiceChange for those terminations whose state is out-of-service.

Regards
Madhubabu

  -----Original Message-----
  From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
  Sent: Thursday, May 10, 2001 12:58 AM
  To: 'Christian Groves'
  Cc: Madhu Babu Brahmanapally; megaco@fore.com
  Subject: RE: Error Code 505


  Let me put the opposite question: has anyone up to now thought that
terminations are only in service after a ServiceChange announcing their
presence?  I think I can see a possible use for such a convention with ATM,
but I don't see it applying to any other type of termination.

  > -----Original Message-----
  > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
  > Sent: Thursday, May 10, 2001 12:42 AM
  > To: Taylor, Tom-PT [NORSE:B881:EXCH]
  > Cc: Madhu Babu Brahmanapally; megaco@fore.com
  > Subject: Re: Error Code 505
  >
  >
  > You lost me on the first sentence of your reply. Why can't
  > ServiceChange
  > bring up a range of termination for the first time? I don't see any
  > overriding reason that this must only apply to ROOT.
  >
  > Christian
  >
  > Tom-PT Taylor wrote:
  > >
  > > All we're talking about is response to a ServiceChange here -- not a
  > > subsequent ServiceChange indicating a reversion to the previous
  > > state.  I would suggest that 505 should apply only to
  > ServiceChange on
  > > ROOT, not because I have an immediate counter-example for the
  > > alternative, but because it feels like it would be easy to
  > construct a
  > > counter-example.
  > >
  > > > -----Original Message-----
  > > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
  > > > Sent: Wednesday, May 09, 2001 10:22 PM
  > > > To: Madhu Babu Brahmanapally
  > > > Cc: megaco@fore.com
  > > > Subject: Re: Error Code 505
  > > >
  > > >
  > > > I'd say this is valid also for terminations than root. A
  > > servicechange
  > > > can be applied to individual terminations and this error
  > code is to
  > > > guard trying to change termination characteristics before
  > they have
  > > > restarted.
  > > >
  > > > Christian
  > > >
  > > > Madhu Babu Brahmanapally wrote:
  > > > >
  > > > > HI All,
  > > > >
  > > > > The Error code 505 description is "Transaction Request
  > > > Received before a
  > > > > ServiceChange Reply has been received", does the
  > > > ServiceChange reply here
  > > > > mean the ServiceChange reply on ROOT termination? or is
  > > > this valid for other
  > > > > terminations also. I think the intention is here is
  > > > ServiceChange for ROOT
  > > > > termination. Comments??
  > > > >
  > > > > Regards
  > > > > Madhubabu
  > > >
  >


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




RE: Error Code 505




Hi=20
Tom,


Why is=20
this valid only for ATM? The general assumption is that as soon as the =
ROOT=20
ServiceChange is complete, all the terminations (irrespective of type)=20
provisioned at both MG and MGC are in-service. Unless followed by any=20
ServiceChange for those terminations whose state is=20
out-of-service.


 


Regards


Madhubabu


 



  
-----Original Message-----
From: Tom-PT Taylor=20
  [mailto:taylor@nortelnetworks.com]
Sent: Thursday, May 10, =
2001=20
  12:58 AM
To: 'Christian Groves'
Cc: Madhu Babu=20
  Brahmanapally; megaco@fore.com
Subject: RE: Error Code=20
  505


  
Let me put the opposite question: has anyone up to =
now thought=20
  that terminations are only in service after a ServiceChange announcing =
their=20
  presence?  I think I can see a possible use for such a convention =
with=20
  ATM, but I don't see it applying to any other type of =
termination.

  
> -----Original Message----- 
>=20
  From: Christian Groves [mailto:Christian.Groves@eri=
csson.com]=20
  
> Sent: Thursday, May 10, 2001 12:42 AM =

> To: Taylor, Tom-PT [NORSE:B881:EXCH] 
>=20
  Cc: Madhu Babu Brahmanapally; megaco@fore.com 
>=20
  Subject: Re: Error Code 505 
> =

> 
> You lost me on the first =
sentence of=20
  your reply. Why can't 
> =
ServiceChange=20
  
> bring up a range of termination for the first =
time? I=20
  don't see any 
> overriding reason that =
this must=20
  only apply to ROOT. 
> 
>=20
  Christian 
> 
> Tom-PT=20
  Taylor wrote: 
> > 
>=20
  > All we're talking about is response to a ServiceChange here -- =
not=20
  a 
> > subsequent ServiceChange =
indicating a=20
  reversion to the previous 
> > =
state.  I=20
  would suggest that 505 should apply only to 
>=20
  ServiceChange on 
> > ROOT, not because =
I have an=20
  immediate counter-example for the 
> >=20
  alternative, but because it feels like it would be easy to =

> construct a 
> >=20
  counter-example. 
> > 
> > > -----Original Message----- 
>=20
  > > From: Christian Groves [mailto:Christian.Groves@eri=
csson.com]=20
  
> > > Sent: Wednesday, May 09, 2001 10:22 =
PM=20
  
> > > To: Madhu Babu Brahmanapally =

> > > Cc: megaco@fore.com 
> >=20
  > Subject: Re: Error Code 505 
> > =
>=20
  
> > > 
> > =
> I'd say=20
  this is valid also for terminations than root. A 
>=20
  > servicechange 
> > > can be =
applied to=20
  individual terminations and this error 
> =
code is=20
  to 
> > > guard trying to change =
termination=20
  characteristics before 
> they have =

> > > restarted. 
> > =
>=20
  
> > > Christian 
> >=20
  > 
> > > Madhu Babu Brahmanapally =

  wrote: 
> > > > 
> > > > HI All, 
> =
> >=20
  > 
> > > > The Error code 505=20
  description is "Transaction Request 
> =
> >=20
  Received before a 
> > > > =
ServiceChange=20
  Reply has been received", does the 
> > =
>=20
  ServiceChange reply here 
> > > > =
mean the=20
  ServiceChange reply on ROOT termination? or is 
>=20
  > > this valid for other 
> > =
> >=20
  terminations also. I think the intention is here is 
> > > ServiceChange for ROOT 
> >=20
  > > termination. Comments?? 
> > =
>=20
  > 
> > > > Regards =

> > > > Madhubabu 
> =
>=20
  > 
> =



------=_NextPart_000_0070_01C0D936.2F304D90--



From owner-megaco@fore.com  Thu May 10 11:11:41 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00130
	for ; Thu, 10 May 2001 11:11:35 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08953;
	Thu, 10 May 2001 11:05:36 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA04844
	for megaco-list; Thu, 10 May 2001 11:03:00 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA04831
	for ; Thu, 10 May 2001 11:02:57 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id LAA08596
	for ; Thu, 10 May 2001 11:02:54 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id LAA12846; Thu, 10 May 2001 11:02:51 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Thu, 10 May 2001 11:02:35 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 10 May 2001 11:02:36 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CAFF@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'megaco'" 
Subject: NITS Reviewer Wanted -- CAS Signalling draft
Date: Thu, 10 May 2001 11:02:17 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

I did not exactly cover myself in glory when I forwarded the enhanced tones
package to the IESG after our list Last Call -- there were a number of minor
deficiencies which meant the draft had to be recycled a couple of times.  In
preparation for list Last Call on draft-manyfolks-megaco-caspackage-00.txt,
therefore, I would ask for one or two "nits" reviewers to go through and
make sure everything is in good shape.

Tom Taylor
Multimedia Control and Applications Standards
Ph.  +1 613 736 0961
taylor@nortelnetworks.com 


From owner-megaco@fore.com  Thu May 10 11:18:46 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00296
	for ; Thu, 10 May 2001 11:18:45 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA10044;
	Thu, 10 May 2001 11:12:39 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA07538
	for megaco-list; Thu, 10 May 2001 11:10:05 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA07519
	for ; Thu, 10 May 2001 11:10:02 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA09618
	for ; Thu, 10 May 2001 11:10:00 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACH13321;
	Thu, 10 May 2001 11:09:03 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Alf Heidermark \(UAB\)'" ,
        "'Krishna Gundamaraju'" ,
        "'Tom-PT Taylor'" ,
        "'Christian Groves'" 
Cc: "'megaco'" 
Subject: RE: Error Code 505
Date: Thu, 10 May 2001 11:13:45 -0400
Message-ID: <009101c0d963$cf217540$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <795A014AF92DD21182AF0008C7A404320B0703A2@esealnt117>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi All,
In the protocol, there should be a mention that if ServiceChange for ROOT is
received from MG, it is implied(or not implied) that all the terminations
that are provisioned at both MG and MGC  are inservice(or out-of-service).
"I think this particular statement is missing in the protocol."

IMHO the MG need not send further InService messages for each termination,
as the ROOT ServiceChange should imply this.  But for any new terminations
that are not provisioned the MG has to specifically send ServiceChange with
"in-service".

Regards
Madhubabu

-----Original Message-----
From: Alf Heidermark (UAB) [mailto:Alf.Heidermark@uab.ericsson.se]
Sent: Thursday, May 10, 2001 10:46 AM
To: 'Krishna Gundamaraju'; Tom-PT Taylor; 'Madhu Babu Brahmanapally';
'Christian Groves'
Cc: megaco
Subject: RE: Error Code 505


Hello

If you look in the proposed Annex L you can find for different service
change reason what the state of each concened terminastions is.

-----Original Message-----
From: Krishna Gundamaraju [mailto:krishna.gundamaraju@kenetec.com]
Sent: den 10 maj 2001 16:38
To: Tom-PT Taylor; 'Madhu Babu Brahmanapally'; 'Christian Groves'
Cc: megaco
Subject: Re: Error Code 505


Hi All,

    All along we were thinking that the ROOT ServiceChange implies that all
the provisioned terminations are inservice. The Protocol should clearly
state what is the correct behavior as otherwise there could be very serious
interoperability issues.

Regards,
Krishna G

----- Original Message -----
From: Tom-PT Taylor 
To: 'Madhu   Babu Brahmanapally' ; 'Christian
Groves' 
Cc: megaco 
Sent: Thursday, May 10, 2001 10:06 AM
Subject: RE: Error Code 505


Sorry, I took the usage with respect to ROOT as a given.  I and Christian (I
believe) were talking about the hypothesis that after ROOT comes up,
individual terminations are out of service until they, too, have been
signalled in-service through a ServiceChange exchange.  As your message
shows and mine was meant to point out, this is not the behaviour people are
currently assuming.  Of course, maybe I misunderstood Christian in the first
place.

-----Original Message-----
From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com
 ]
Sent: Thursday, May 10, 2001 9:47 AM
To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Christian Groves'
Cc: megaco
Subject: RE: Error Code 505


Hi Tom,
Why is this valid only for ATM? The general assumption is that as soon as
the ROOT ServiceChange is complete, all the terminations (irrespective of
type) provisioned at both MG and MGC are in-service. Unless followed by any
ServiceChange for those terminations whose state is out-of-service.


Regards
Madhubabu

-----Original Message-----
From: Tom-PT Taylor [ mailto:taylor@nortelnetworks.com
 ]
Sent: Thursday, May 10, 2001 12:58 AM
To: 'Christian Groves'
Cc: Madhu Babu Brahmanapally; megaco@fore.com
Subject: RE: Error Code 505


Let me put the opposite question: has anyone up to now thought that
terminations are only in service after a ServiceChange announcing their
presence?  I think I can see a possible use for such a convention with ATM,
but I don't see it applying to any other type of termination.

> -----Original Message-----
> From: Christian Groves [ mailto:Christian.Groves@ericsson.com
 ]
> Sent: Thursday, May 10, 2001 12:42 AM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]
> Cc: Madhu Babu Brahmanapally; megaco@fore.com
> Subject: Re: Error Code 505
>
>
> You lost me on the first sentence of your reply. Why can't
> ServiceChange
> bring up a range of termination for the first time? I don't see any
> overriding reason that this must only apply to ROOT.
>
> Christian
>
> Tom-PT Taylor wrote:
> >
> > All we're talking about is response to a ServiceChange here -- not a
> > subsequent ServiceChange indicating a reversion to the previous
> > state.  I would suggest that 505 should apply only to
> ServiceChange on
> > ROOT, not because I have an immediate counter-example for the
> > alternative, but because it feels like it would be easy to
> construct a
> > counter-example.
> >
> > > -----Original Message-----
> > > From: Christian Groves [ mailto:Christian.Groves@ericsson.com
 ]
> > > Sent: Wednesday, May 09, 2001 10:22 PM
> > > To: Madhu Babu Brahmanapally
> > > Cc: megaco@fore.com
> > > Subject: Re: Error Code 505
> > >
> > >
> > > I'd say this is valid also for terminations than root. A
> > servicechange
> > > can be applied to individual terminations and this error
> code is to
> > > guard trying to change termination characteristics before
> they have
> > > restarted.
> > >
> > > Christian
> > >
> > > Madhu Babu Brahmanapally wrote:
> > > >
> > > > HI All,
> > > >
> > > > The Error code 505 description is "Transaction Request
> > > Received before a
> > > > ServiceChange Reply has been received", does the
> > > ServiceChange reply here
> > > > mean the ServiceChange reply on ROOT termination? or is
> > > this valid for other
> > > > terminations also. I think the intention is here is
> > > ServiceChange for ROOT
> > > > termination. Comments??
> > > >
> > > > Regards
> > > > Madhubabu
> > >
>



From owner-megaco@fore.com  Thu May 10 11:33:07 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00669
	for ; Thu, 10 May 2001 11:33:06 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA11430;
	Thu, 10 May 2001 11:23:34 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA10930
	for megaco-list; Thu, 10 May 2001 11:21:02 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA10905
	for ; Thu, 10 May 2001 11:20:58 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA11114
	for ; Thu, 10 May 2001 11:20:54 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACH13445;
	Thu, 10 May 2001 11:20:37 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Tom-PT Taylor'" ,
        "'megaco'" 
Subject: RE: NITS Reviewer Wanted -- CAS Signalling draft
Date: Thu, 10 May 2001 11:25:19 -0400
Message-ID: <009201c0d965$6cadaee0$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <28560036253BD41191A10000F8BCBD110250CAFF@zcard00g.ca.nortel.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

HI Tom,
Is the R2 package becoming a part of this CAS package or as a separate
RFC???

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Tom-PT Taylor
Sent: Thursday, May 10, 2001 11:02 AM
To: 'megaco'
Subject: NITS Reviewer Wanted -- CAS Signalling draft


I did not exactly cover myself in glory when I forwarded the enhanced tones
package to the IESG after our list Last Call -- there were a number of minor
deficiencies which meant the draft had to be recycled a couple of times.  In
preparation for list Last Call on draft-manyfolks-megaco-caspackage-00.txt,
therefore, I would ask for one or two "nits" reviewers to go through and
make sure everything is in good shape.

Tom Taylor
Multimedia Control and Applications Standards
Ph.  +1 613 736 0961
taylor@nortelnetworks.com



From owner-megaco@fore.com  Thu May 10 11:34:39 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00722
	for ; Thu, 10 May 2001 11:34:39 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA05890;
	Thu, 10 May 2001 10:42:01 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA25820
	for megaco-list; Thu, 10 May 2001 10:39:07 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA25804
	for ; Thu, 10 May 2001 10:39:05 -0400 (EDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA05463
	for ; Thu, 10 May 2001 10:39:01 -0400 (EDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA22050
	for ; Thu, 10 May 2001 09:39:02 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4AEd1C06053
	for ; Thu, 10 May 2001 09:39:01 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4AEcl101485
	for ; Thu, 10 May 2001 09:38:47 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4AEclO02829
	for ; Thu, 10 May 2001 09:38:47 -0500 (CDT)
Message-ID: <3AFAA7F7.9E85FA3F@usa.alcatel.com>
Date: Thu, 10 May 2001 09:38:47 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Implementors' Guide Update Editor's last Call Section 11.2
Content-Type: multipart/alternative;
 boundary="------------C50AB2F2E270A71EE38DD62A"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------C50AB2F2E270A71EE38DD62A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

G'Day Christian
Please see comments below":


G'Day Chuong,

Please see my replies below.

Cheers, Christian

Chuong Nguyen wrote:
>
> Christian
>
>
> Section 11.2 ServiceChange Address and Ports
> There is some confusion on  when to use either ServiceChange Address
> or ServiceChange MGCID. The text below offers some advice on
>
> [Begin Clarification]
> 1) The use of ServiceChangeAddress is not encouraged
>
>   Why is the use not encouraged?
[CHG] This was in the approved IG. The issue was that the
ServiceChangeMgcID and the ServiceChangeAddress carried essentially the
same information. So ServiceChangeMgcID was favoured.

  Now I am really confused.  As I had quoted below the difference
between
              ServiceChangeAddress and ServiceChangeMgcID.  They both
have different
              purpose.
              For UDP ServiceChangeAddress is used to tell each other
what port# to use
              for further communication.
              ServiceChangeMgcID is for MGC to tell MG to seek another
MGC to service it.

             It is not one is prefer over the other.  It is more like
how it should be used.

             I think that the confusion must have occured when
ServiceChangeAddress was changed
             in the ABNF from VAULE to mID which is something else that
I want to address later.

             Your comment about ServiceChangeMgcId was favoured over
ServiceChangeAddress
              does not make sense to me.

             For example, MG sends ServiceChange Restart to MGC1.

             Case 1:  MGC1 does not want to service MG.
             MGC1 sends Reply back w/ServiceChangeMgcId of MGC2.
             Thus telling MG to try MGC2.

             Case 2: MGC1 will service MG but want MG to use port #
10000 for further communication.
             MGC1 replies w/ServiceChangeAddress containing port#10000.
              Now ServiceChangeAddress ABNF has been changed in IGv6
section B.2

                   serviceChangeAddress = ServiceChangeAddressToken
EQUAL ( mId / portNumber )

               So MGC1 can either specify "ServiceChangeAddress=10000"
or
                "ServiceChangeAddress=10.10.10.10:10000"

            From the above example, I don't see how ServiceChangeMgcId
is favoured over
            ServiceChangeAddress.



>
> 2) MGCs must be able to cope with ServiceChangeAddress with either a
> full address or just a port number in the case of TCP transport.
>
>   Do you mean UDP transport?
>                And ServiceChangeAddress does not apply to TCP?
[CHG] ServiceChangeAddress applies to all. The "or" relates TCP to the
port number. I guess you could remove the "in the case of TCP transport"

part.

  I think we went over this already on the List and Brian has
indicated the following:
              If TCP is used ServiceChangeAddress would be ignored if
included in the msg.
              And I agree w/him that there is no point in changing port#
for TCP which will
              require a new TCP connection towards the MGC.

              Maybe Brian can clarify this again?

>
>
>   I don't see any text regarding the clarification of when one or

> the other should be used.
> The Standard text already has something like:
>
> ServiceChangeAddress
>    and ServiceChangeMgcId parameters must not both be present in the
>    ServiceChangeDescriptor or the ServiceChangeResultDescriptor.  The
>    ServiceChangeAddress provides an address to be used within the
>    context of the association currently being negotiated, while the
>    ServiceChangeMgcId provides an alternate address where the MG
> should
>    seek to establish another association.
[CHG] That's why we put the note in favouring MGcID.

  See comments above.
              The only thing that I see wrong is that Section 7.2.8 is
missing the description of
              ServiceChangeMgcId in a separate paragraph like the other
parameters.
              ServiceChangeMgcId description is buried in the
ServiceChangeAddress description
              plus subsequent paragraphs describing ServiceChange
Registration.





--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------C50AB2F2E270A71EE38DD62A
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



G'Day Christian

Please see comments below":

 

G'Day Chuong,

Please see my replies below.

Cheers, Christian

Chuong Nguyen wrote:

>

> Christian

>

>

> Section 11.2 ServiceChange Address and Ports

> There is some confusion on  when to use either ServiceChange
Address

> or ServiceChange MGCID. The text below offers some advice on

>

> [Begin Clarification]

> 1) The use of ServiceChangeAddress is not encouraged

>

> <cnn>  Why is the use not encouraged?

[CHG] This was in the approved IG. The issue was that the

ServiceChangeMgcID and the ServiceChangeAddress carried essentially
the

same information. So ServiceChangeMgcID was favoured.

<cnn>  Now I am really confused.  As I had quoted
below the difference between

             
ServiceChangeAddress and ServiceChangeMgcID.  They both have different

             
purpose.

             
For UDP ServiceChangeAddress is used to tell each other what port# to use

             
for further communication.

             
ServiceChangeMgcID is for MGC to tell MG to seek another MGC to
service it.

            
It is not one is prefer over the other.  It is more like how it should
be used.

            
I think that the confusion must have occured when ServiceChangeAddress
was changed

            
in the ABNF from VAULE to mID which is something else that I want
to address later.

            
Your comment about ServiceChangeMgcId was favoured over ServiceChangeAddress

             
does not make sense to me.

            
For example, MG sends ServiceChange Restart to MGC1.

            
Case 1:  MGC1 does not want to service MG.

            
MGC1 sends Reply back w/ServiceChangeMgcId of MGC2.

            
Thus telling MG to try MGC2.

            
Case 2: MGC1 will service MG but want MG to use port # 10000 for further
communication.

            
MGC1 replies w/ServiceChangeAddress containing port#10000.

             
Now ServiceChangeAddress ABNF has been changed in IGv6 section B.2

                  
serviceChangeAddress = ServiceChangeAddressToken EQUAL ( mId / portNumber
)

              
So MGC1 can either specify "ServiceChangeAddress=10000" or

               
"ServiceChangeAddress=10.10.10.10:10000"

            From
the above example, I don't see how ServiceChangeMgcId is favoured
over

           
ServiceChangeAddress.

 

>

> 2) MGCs must be able to cope with ServiceChangeAddress with either
a

> full address or just a port number in the case of TCP transport.

>

> <cnn>  Do you mean UDP transport?

>               
And ServiceChangeAddress does not apply to TCP?

[CHG] ServiceChangeAddress applies to all. The "or" relates TCP to
the

port number. I guess you could remove the "in the case of TCP transport"

part.

<cnn>  I think we went over this already on the List and
Brian has indicated the following:

             
If TCP is used ServiceChangeAddress would be ignored if included in the
msg.

             
And I agree w/him that there is no point in changing port# for TCP which
will

             
require a new TCP connection towards the MGC.

             
Maybe Brian can clarify this again?

>

>

> <cnn>  I don't see any text regarding the clarification of
when one or

> the other should be used.

> The Standard text already has something like:

>

> ServiceChangeAddress

>    and ServiceChangeMgcId parameters must not both
be present in the

>    ServiceChangeDescriptor or the ServiceChangeResultDescriptor. 
The

>    ServiceChangeAddress provides an address to be
used within the

>    context of the association currently being negotiated,
while the

>    ServiceChangeMgcId provides an alternate address
where the MG

> should

>    seek to establish another association.

[CHG] That's why we put the note in favouring MGcID.

<cnn>  See comments above.

             
The only thing that I see wrong is that Section 7.2.8 is missing the
description of

             
ServiceChangeMgcId in a separate paragraph like the other parameters.

             
ServiceChangeMgcId description is buried in the ServiceChangeAddress description

             
plus subsequent paragraphs describing ServiceChange Registration.

 

 

 

 

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------C50AB2F2E270A71EE38DD62A--



From owner-megaco@fore.com  Thu May 10 11:37:25 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00823
	for ; Thu, 10 May 2001 11:37:22 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA05414;
	Thu, 10 May 2001 10:38:48 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA24728
	for megaco-list; Thu, 10 May 2001 10:35:42 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24691
	for ; Thu, 10 May 2001 10:35:28 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04990
	for ; Thu, 10 May 2001 10:35:25 -0400 (EDT)
Received: from KGUNDAMARAJU ([64.69.123.121])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACH13004;
	Thu, 10 May 2001 10:34:17 -0400 (EDT)
Message-ID: <00c701c0d95e$cd167c50$ae00a8c0@KGUNDAMARAJU>
From: "Krishna Gundamaraju" 
To: "Tom-PT Taylor" ,
        "'Madhu Babu Brahmanapally'" ,
        "'Christian Groves'" 
Cc: "megaco" 
References: <28560036253BD41191A10000F8BCBD110250CAFB@zcard00g.ca.nortel.com>
Subject: Re: Error Code 505
Date: Thu, 10 May 2001 10:37:55 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00C4_01C0D93D.45B0C8E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00C4_01C0D93D.45B0C8E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: Error Code 505Hi All,

    All along we were thinking that the ROOT ServiceChange implies that =
all the provisioned terminations are inservice. The Protocol should =
clearly state what is the correct behavior as otherwise there could be =
very serious interoperability issues.

Regards,
Krishna G
  ----- Original Message -----=20
  From: Tom-PT Taylor=20
  To: 'Madhu Babu Brahmanapally' ; 'Christian Groves'=20
  Cc: megaco=20
  Sent: Thursday, May 10, 2001 10:06 AM
  Subject: RE: Error Code 505


  Sorry, I took the usage with respect to ROOT as a given.  I and =
Christian (I believe) were talking about the hypothesis that after ROOT =
comes up, individual terminations are out of service until they, too, =
have been signalled in-service through a ServiceChange exchange.  As =
your message shows and mine was meant to point out, this is not the =
behaviour people are currently assuming.  Of course, maybe I =
misunderstood Christian in the first place.

  -----Original Message-----=20
  From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]=20
  Sent: Thursday, May 10, 2001 9:47 AM=20
  To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Christian Groves'=20
  Cc: megaco=20
  Subject: RE: Error Code 505=20



  Hi Tom,=20
  Why is this valid only for ATM? The general assumption is that as soon =
as the ROOT ServiceChange is complete, all the terminations =
(irrespective of type) provisioned at both MG and MGC are in-service. =
Unless followed by any ServiceChange for those terminations whose state =
is out-of-service.

   =20
  Regards=20
  Madhubabu=20
   =20
  -----Original Message-----=20
  From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]=20
  Sent: Thursday, May 10, 2001 12:58 AM=20
  To: 'Christian Groves'=20
  Cc: Madhu Babu Brahmanapally; megaco@fore.com=20
  Subject: RE: Error Code 505=20



  Let me put the opposite question: has anyone up to now thought that =
terminations are only in service after a ServiceChange announcing their =
presence?  I think I can see a possible use for such a convention with =
ATM, but I don't see it applying to any other type of termination.

  > -----Original Message-----=20
  > From: Christian Groves [mailto:Christian.Groves@ericsson.com]=20
  > Sent: Thursday, May 10, 2001 12:42 AM=20
  > To: Taylor, Tom-PT [NORSE:B881:EXCH]=20
  > Cc: Madhu Babu Brahmanapally; megaco@fore.com=20
  > Subject: Re: Error Code 505=20
  >=20
  >=20
  > You lost me on the first sentence of your reply. Why can't=20
  > ServiceChange=20
  > bring up a range of termination for the first time? I don't see any=20
  > overriding reason that this must only apply to ROOT.=20
  >=20
  > Christian=20
  >=20
  > Tom-PT Taylor wrote:=20
  > >=20
  > > All we're talking about is response to a ServiceChange here -- not =
a=20
  > > subsequent ServiceChange indicating a reversion to the previous=20
  > > state.  I would suggest that 505 should apply only to=20
  > ServiceChange on=20
  > > ROOT, not because I have an immediate counter-example for the=20
  > > alternative, but because it feels like it would be easy to=20
  > construct a=20
  > > counter-example.=20
  > >=20
  > > > -----Original Message-----=20
  > > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]=20
  > > > Sent: Wednesday, May 09, 2001 10:22 PM=20
  > > > To: Madhu Babu Brahmanapally=20
  > > > Cc: megaco@fore.com=20
  > > > Subject: Re: Error Code 505=20
  > > >=20
  > > >=20
  > > > I'd say this is valid also for terminations than root. A=20
  > > servicechange=20
  > > > can be applied to individual terminations and this error=20
  > code is to=20
  > > > guard trying to change termination characteristics before=20
  > they have=20
  > > > restarted.=20
  > > >=20
  > > > Christian=20
  > > >=20
  > > > Madhu Babu Brahmanapally wrote:=20
  > > > >=20
  > > > > HI All,=20
  > > > >=20
  > > > > The Error code 505 description is "Transaction Request=20
  > > > Received before a=20
  > > > > ServiceChange Reply has been received", does the=20
  > > > ServiceChange reply here=20
  > > > > mean the ServiceChange reply on ROOT termination? or is=20
  > > > this valid for other=20
  > > > > terminations also. I think the intention is here is=20
  > > > ServiceChange for ROOT=20
  > > > > termination. Comments??=20
  > > > >=20
  > > > > Regards=20
  > > > > Madhubabu=20
  > > >=20
  >=20


------=_NextPart_000_00C4_01C0D93D.45B0C8E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


RE: Error Code 505






Hi All,


 


    All along we =
were thinking=20
that the ROOT ServiceChange implies that all the provisioned =
terminations=20
are inservice. The Protocol should clearly state what is the correct =
behavior as=20
otherwise there could be very serious interoperability =
issues.


 


Regards,


Krishna G


  
----- Original Message ----- 

  From:=20
  Tom-PT Taylor 
  
To: 'Madhu Babu=20
  Brahmanapally' ; 'Christian Groves' 

  
Cc: megaco 

  
Sent: Thursday, May 10, 2001 =
10:06=20
  AM

  
Subject: RE: Error Code =
505

  


  
Sorry, I took the usage with respect to ROOT as a =
given. =20
  I and Christian (I believe) were talking about the hypothesis that =
after ROOT=20
  comes up, individual terminations are out of service until they, too, =
have=20
  been signalled in-service through a ServiceChange exchange.  As =
your=20
  message shows and mine was meant to point out, this is not the =
behaviour=20
  people are currently assuming.  Of course, maybe I misunderstood=20
  Christian in the first place.

  
-----Original Message----- 
From: Madhu=20
  Babu Brahmanapally [mailto:madhubabu@kenetec.com]=20
  
Sent: Thursday, May 10, 2001 9:47 AM =

To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Christian =
Groves'=20
  
Cc: megaco 
Subject: RE: =
Error Code=20
  505 


  
Hi Tom, 
Why is this valid =
only for=20
  ATM? The general assumption is that as soon as the ROOT ServiceChange =
is=20
  complete, all the terminations (irrespective of type) provisioned at =
both MG=20
  and MGC are in-service. Unless followed by any ServiceChange for those =

  terminations whose state is out-of-service.

  
  
Regards =

Madhubabu 
  
-----Original Message----- 
From: =
Tom-PT Taylor=20
  [mailto:taylor@nortelnetworks.co=
m]=20
  
Sent: Thursday, May 10, 2001 12:58 AM =

To: 'Christian Groves' 
Cc: Madhu =
Babu=20
  Brahmanapally; megaco@fore.com 
Subject: RE: =
Error Code=20
  505 


  
Let me put the opposite question: has anyone up to =
now thought=20
  that terminations are only in service after a ServiceChange announcing =
their=20
  presence?  I think I can see a possible use for such a convention =
with=20
  ATM, but I don't see it applying to any other type of =
termination.

  
> -----Original Message----- 
>=20
  From: Christian Groves [mailto:Christian.Groves@eri=
csson.com]=20
  
> Sent: Thursday, May 10, 2001 12:42 AM=20
  
> To: Taylor, Tom-PT [NORSE:B881:EXCH]=20
  
> Cc: Madhu Babu Brahmanapally; =
megaco@fore.com=20
  
> Subject: Re: Error Code 505 =

> 
> 
> You lost=20
  me on the first sentence of your reply. Why can't 
>=20
  ServiceChange 
> bring up a range of =
termination for=20
  the first time? I don't see any 
> =
overriding reason=20
  that this must only apply to ROOT. 
>=20
  
> Christian 
>=20
  
> Tom-PT Taylor wrote: 
>=20
  > 
> > All we're talking about is =
response to=20
  a ServiceChange here -- not a 
> > =
subsequent=20
  ServiceChange indicating a reversion to the previous 
> > state.  I would suggest that 505 should apply =
only to=20
  
> ServiceChange on 
>=20
  > ROOT, not because I have an immediate counter-example for the=20
  
> > alternative, but because it feels =
like it=20
  would be easy to 
> construct a =

> > counter-example. 
> =
>=20
  
> > > -----Original Message-----=20
  
> > > From: Christian Groves [mailto:Christian.Groves@eri=
csson.com]=20
  
> > > Sent: Wednesday, May 09, 2001 =
10:22 PM=20
  
> > > To: Madhu Babu Brahmanapally=20
  
> > > Cc: megaco@fore.com =

> > > Subject: Re: Error Code 505 
>=20
  > > 
> > > 
>=20
  > > I'd say this is valid also for terminations than root. A=20
  
> > servicechange 
>=20
  > > can be applied to individual terminations and this error=20
  
> code is to 
> > >=20
  guard trying to change termination characteristics before =

> they have 
> > > =
restarted.=20
  
> > > 
> > >=20
  Christian 
> > > 
>=20
  > > Madhu Babu Brahmanapally wrote: 
> >=20
  > > 
> > > > HI All, =

> > > > 
> > > =
> The=20
  Error code 505 description is "Transaction Request 
> > > Received before a 
> > >=20
  > ServiceChange Reply has been received", does the 
> > > ServiceChange reply here 
>=20
  > > > mean the ServiceChange reply on ROOT termination? or is =

  
> > > this valid for other =

> > > > terminations also. I think the intention =
is here is=20
  
> > > ServiceChange for ROOT =

> > > > termination. Comments?? 
> > > > 
> > > =
> Regards=20
  
> > > > Madhubabu =

> > > 
>=20



------=_NextPart_000_00C4_01C0D93D.45B0C8E0--



From owner-megaco@fore.com  Thu May 10 12:01:10 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01443
	for ; Thu, 10 May 2001 12:01:08 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA14939;
	Thu, 10 May 2001 11:54:52 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA21605
	for megaco-list; Thu, 10 May 2001 11:52:03 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA21599
	for ; Thu, 10 May 2001 11:52:02 -0400 (EDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA14616
	for ; Thu, 10 May 2001 11:51:59 -0400 (EDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id KAA17499
	for ; Thu, 10 May 2001 10:52:00 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4AFpxC03088
	for ; Thu, 10 May 2001 10:51:59 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4AFpm112952
	for ; Thu, 10 May 2001 10:51:48 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4AFpmO02842
	for ; Thu, 10 May 2001 10:51:48 -0500 (CDT)
Message-ID: <3AFAB913.3D993EEB@usa.alcatel.com>
Date: Thu, 10 May 2001 10:51:48 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Error Code 505
References: <28560036253BD41191A10000F8BCBD110250CAF2@zcard00g.ca.nortel.com> <3AFA1BFC.F8419921@ericsson.com>
Content-Type: multipart/alternative;
 boundary="------------17EC5A027D38527D1DEDE4F1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------17EC5A027D38527D1DEDE4F1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


505 was only intended for Cold Start use and not subsequent ServiceChange?

Megaco Standard

Section 11.2 Cold Start

   It is possible that the reply to a ServiceChange with Restart will be
   lost, and a command will be received by the MG prior to the receipt
   of the ServiceChange response.  The MG shall issue error 505 -
   Command Received before Restart Response.

I believe this was the intend of 505 but Annex L wording for 505 sort of
broaden the scope
of 505.
The original intend was to let MGC knows that MG has not successfully
established
an association w/MGC so it can't honor any request from MGC.

I think AnnexL 505 description needs to be reworded to match the original
intend of 505
as quoted from Section 11.2 above.

Chuong


Christian Groves wrote:

> You lost me on the first sentence of your reply. Why can't ServiceChange
> bring up a range of termination for the first time? I don't see any
> overriding reason that this must only apply to ROOT.
>
> Christian
>
> Tom-PT Taylor wrote:
> >
> > All we're talking about is response to a ServiceChange here -- not a
> > subsequent ServiceChange indicating a reversion to the previous
> > state.  I would suggest that 505 should apply only to ServiceChange on
> > ROOT, not because I have an immediate counter-example for the
> > alternative, but because it feels like it would be easy to construct a
> > counter-example.
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > > Sent: Wednesday, May 09, 2001 10:22 PM
> > > To: Madhu Babu Brahmanapally
> > > Cc: megaco@fore.com
> > > Subject: Re: Error Code 505
> > >
> > >
> > > I'd say this is valid also for terminations than root. A
> > servicechange
> > > can be applied to individual terminations and this error code is to
> > > guard trying to change termination characteristics before they have
> > > restarted.
> > >
> > > Christian
> > >
> > > Madhu Babu Brahmanapally wrote:
> > > >
> > > > HI All,
> > > >
> > > > The Error code 505 description is "Transaction Request
> > > Received before a
> > > > ServiceChange Reply has been received", does the
> > > ServiceChange reply here
> > > > mean the ServiceChange reply on ROOT termination? or is
> > > this valid for other
> > > > terminations also. I think the intention is here is
> > > ServiceChange for ROOT
> > > > termination. Comments??
> > > >
> > > > Regards
> > > > Madhubabu
> > >

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------17EC5A027D38527D1DEDE4F1
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

505 was only intended for Cold Start use and not subsequent ServiceChange?

Megaco Standard

Section 11.2 Cold Start

   It is possible that the reply to a ServiceChange with
Restart will be

   lost, and a command will be received by the MG prior
to the receipt

   of the ServiceChange response.  The MG shall issue
error 505 -

   Command Received before Restart Response.

I believe this was the intend of 505 but Annex L wording for 505
sort of broaden the scope

of 505.

The original intend was to let MGC knows that MG has not successfully
established

an association w/MGC so it can't honor any request from MGC.

I think AnnexL 505 description needs to be reworded to match the
original intend of 505

as quoted from Section 11.2 above.

Chuong

 

Christian Groves wrote:

You lost me on the first sentence of your reply.
Why can't ServiceChange

bring up a range of termination for the first time? I don't see any

overriding reason that this must only apply to ROOT.

Christian

Tom-PT Taylor wrote:

>

> All we're talking about is response to a ServiceChange here -- not
a

> subsequent ServiceChange indicating a reversion to the previous

> state.  I would suggest that 505 should apply only to ServiceChange
on

> ROOT, not because I have an immediate counter-example for the

> alternative, but because it feels like it would be easy to construct
a

> counter-example.

>

> > -----Original Message-----

> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]

> > Sent: Wednesday, May 09, 2001 10:22 PM

> > To: Madhu Babu Brahmanapally

> > Cc: megaco@fore.com

> > Subject: Re: Error Code 505

> >

> >

> > I'd say this is valid also for terminations than root. A

> servicechange

> > can be applied to individual terminations and this error code is
to

> > guard trying to change termination characteristics before they
have

> > restarted.

> >

> > Christian

> >

> > Madhu Babu Brahmanapally wrote:

> > >

> > > HI All,

> > >

> > > The Error code 505 description is "Transaction Request

> > Received before a

> > > ServiceChange Reply has been received", does the

> > ServiceChange reply here

> > > mean the ServiceChange reply on ROOT termination? or is

> > this valid for other

> > > terminations also. I think the intention is here is

> > ServiceChange for ROOT

> > > termination. Comments??

> > >

> > > Regards

> > > Madhubabu

> >



-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------17EC5A027D38527D1DEDE4F1--



From owner-megaco@fore.com  Thu May 10 12:09:16 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01650
	for ; Thu, 10 May 2001 12:09:15 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA15710;
	Thu, 10 May 2001 12:00:17 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA23314
	for megaco-list; Thu, 10 May 2001 11:57:40 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23289
	for ; Thu, 10 May 2001 11:57:35 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id LAA15353
	for ; Thu, 10 May 2001 11:57:30 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id LAA19078; Thu, 10 May 2001 11:57:27 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 10 May 2001 11:57:05 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 10 May 2001 11:57:07 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB00@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Madhu Babu Brahmanapally'" ,
        "'Alf Heidermark (UAB)'" ,
        "'Krishna Gundamaraju'" ,
        "'Christian Groves'" 
Cc: "'megaco'" 
Subject: RE: Error Code 505
Date: Thu, 10 May 2001 11:57:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D969.DC470810"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D969.DC470810
Content-Type: text/plain;
	charset="ISO-8859-1"

Careful about that last statement.  Do you really want a ServiceChange every
time an RTP connection is created?

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Thursday, May 10, 2001 11:14 AM
> To: 'Alf Heidermark (UAB)'; 'Krishna Gundamaraju'; Taylor, Tom-PT
> [NORSE:B881:EXCH]; 'Christian Groves'
> Cc: 'megaco'
> Subject: RE: Error Code 505
> 
> 
> Hi All,
> In the protocol, there should be a mention that if 
> ServiceChange for ROOT is
> received from MG, it is implied(or not implied) that all the 
> terminations
> that are provisioned at both MG and MGC  are inservice(or 
> out-of-service).
> "I think this particular statement is missing in the protocol."
> 
> IMHO the MG need not send further InService messages for each 
> termination,
> as the ROOT ServiceChange should imply this.  But for any new 
> terminations
> that are not provisioned the MG has to specifically send 
> ServiceChange with
> "in-service".
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: Alf Heidermark (UAB) [mailto:Alf.Heidermark@uab.ericsson.se]
> Sent: Thursday, May 10, 2001 10:46 AM
> To: 'Krishna Gundamaraju'; Tom-PT Taylor; 'Madhu Babu Brahmanapally';
> 'Christian Groves'
> Cc: megaco
> Subject: RE: Error Code 505
> 
> 
> Hello
> 
> If you look in the proposed Annex L you can find for different service
> change reason what the state of each concened terminastions is.
> 
> -----Original Message-----
> From: Krishna Gundamaraju [mailto:krishna.gundamaraju@kenetec.com]
> Sent: den 10 maj 2001 16:38
> To: Tom-PT Taylor; 'Madhu Babu Brahmanapally'; 'Christian Groves'
> Cc: megaco
> Subject: Re: Error Code 505
> 
> 
> Hi All,
> 
>     All along we were thinking that the ROOT ServiceChange 
> implies that all
> the provisioned terminations are inservice. The Protocol 
> should clearly
> state what is the correct behavior as otherwise there could 
> be very serious
> interoperability issues.
> 
> Regards,
> Krishna G
> 
> ----- Original Message -----
> From: Tom-PT Taylor 
> To: 'Madhu   Babu 
> Brahmanapally' ; 'Christian
> Groves' 
> Cc: megaco 
> Sent: Thursday, May 10, 2001 10:06 AM
> Subject: RE: Error Code 505
> 
> 
> Sorry, I took the usage with respect to ROOT as a given.  I 
> and Christian (I
> believe) were talking about the hypothesis that after ROOT comes up,
> individual terminations are out of service until they, too, have been
> signalled in-service through a ServiceChange exchange.  As 
> your message
> shows and mine was meant to point out, this is not the 
> behaviour people are
> currently assuming.  Of course, maybe I misunderstood 
> Christian in the first
> place.
> 
> -----Original Message-----
> From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com
>  ]
> Sent: Thursday, May 10, 2001 9:47 AM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Christian Groves'
> Cc: megaco
> Subject: RE: Error Code 505
> 
> 
> Hi Tom,
> Why is this valid only for ATM? The general assumption is 
> that as soon as
> the ROOT ServiceChange is complete, all the terminations 
> (irrespective of
> type) provisioned at both MG and MGC are in-service. Unless 
> followed by any
> ServiceChange for those terminations whose state is out-of-service.
> 
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: Tom-PT Taylor [ mailto:taylor@nortelnetworks.com
>  ]
> Sent: Thursday, May 10, 2001 12:58 AM
> To: 'Christian Groves'
> Cc: Madhu Babu Brahmanapally; megaco@fore.com
> Subject: RE: Error Code 505
> 
> 
> Let me put the opposite question: has anyone up to now thought that
> terminations are only in service after a ServiceChange 
> announcing their
> presence?  I think I can see a possible use for such a 
> convention with ATM,
> but I don't see it applying to any other type of termination.
> 
> > -----Original Message-----
> > From: Christian Groves [ mailto:Christian.Groves@ericsson.com
>  ]
> > Sent: Thursday, May 10, 2001 12:42 AM
> > To: Taylor, Tom-PT [NORSE:B881:EXCH]
> > Cc: Madhu Babu Brahmanapally; megaco@fore.com
> > Subject: Re: Error Code 505
> >
> >
> > You lost me on the first sentence of your reply. Why can't
> > ServiceChange
> > bring up a range of termination for the first time? I don't see any
> > overriding reason that this must only apply to ROOT.
> >
> > Christian
> >
> > Tom-PT Taylor wrote:
> > >
> > > All we're talking about is response to a ServiceChange 
> here -- not a
> > > subsequent ServiceChange indicating a reversion to the previous
> > > state.  I would suggest that 505 should apply only to
> > ServiceChange on
> > > ROOT, not because I have an immediate counter-example for the
> > > alternative, but because it feels like it would be easy to
> > construct a
> > > counter-example.
> > >
> > > > -----Original Message-----
> > > > From: Christian Groves [ mailto:Christian.Groves@ericsson.com
>  ]
> > > > Sent: Wednesday, May 09, 2001 10:22 PM
> > > > To: Madhu Babu Brahmanapally
> > > > Cc: megaco@fore.com
> > > > Subject: Re: Error Code 505
> > > >
> > > >
> > > > I'd say this is valid also for terminations than root. A
> > > servicechange
> > > > can be applied to individual terminations and this error
> > code is to
> > > > guard trying to change termination characteristics before
> > they have
> > > > restarted.
> > > >
> > > > Christian
> > > >
> > > > Madhu Babu Brahmanapally wrote:
> > > > >
> > > > > HI All,
> > > > >
> > > > > The Error code 505 description is "Transaction Request
> > > > Received before a
> > > > > ServiceChange Reply has been received", does the
> > > > ServiceChange reply here
> > > > > mean the ServiceChange reply on ROOT termination? or is
> > > > this valid for other
> > > > > terminations also. I think the intention is here is
> > > > ServiceChange for ROOT
> > > > > termination. Comments??
> > > > >
> > > > > Regards
> > > > > Madhubabu
> > > >
> >
> 
> 

------_=_NextPart_001_01C0D969.DC470810
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Error Code 505




Careful about that last statement.  Do you =
really want a ServiceChange every time an RTP connection is =
created?




> -----Original Message-----

> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]<=
/FONT>

> Sent: Thursday, May 10, 2001 11:14 AM

> To: 'Alf Heidermark (UAB)'; 'Krishna =
Gundamaraju'; Taylor, Tom-PT

> [NORSE:B881:EXCH]; 'Christian Groves'

> Cc: 'megaco'

> Subject: RE: Error Code 505

> 

> 

> Hi All,

> In the protocol, there should be a mention that =
if 

> ServiceChange for ROOT is

> received from MG, it is implied(or not implied) =
that all the 

> terminations

> that are provisioned at both MG and MGC  =
are inservice(or 

> out-of-service).

> "I think this particular statement is =
missing in the protocol."

> 

> IMHO the MG need not send further InService =
messages for each 

> termination,

> as the ROOT ServiceChange should imply =
this.  But for any new 

> terminations

> that are not provisioned the MG has to =
specifically send 

> ServiceChange with

> "in-service".

> 

> Regards

> Madhubabu

> 

> -----Original Message-----

> From: Alf Heidermark (UAB) [mailto:Alf.Heidermark@uab=
.ericsson.se]

> Sent: Thursday, May 10, 2001 10:46 AM

> To: 'Krishna Gundamaraju'; Tom-PT Taylor; =
'Madhu Babu Brahmanapally';

> 'Christian Groves'

> Cc: megaco

> Subject: RE: Error Code 505

> 

> 

> Hello

> 

> If you look in the proposed Annex L you can =
find for different service

> change reason what the state of each concened =
terminastions is.

> 

> -----Original Message-----

> From: Krishna Gundamaraju [mailto:krishna.gundamara=
ju@kenetec.com]

> Sent: den 10 maj 2001 16:38

> To: Tom-PT Taylor; 'Madhu Babu Brahmanapally'; =
'Christian Groves'

> Cc: megaco

> Subject: Re: Error Code 505

> 

> 

> Hi All,

> 

>     All along we were =
thinking that the ROOT ServiceChange 

> implies that all

> the provisioned terminations are inservice. The =
Protocol 

> should clearly

> state what is the correct behavior as otherwise =
there could 

> be very serious

> interoperability issues.

> 

> Regards,

> Krishna G

> 

> ----- Original Message -----

> From: Tom-PT Taylor <mailto:taylor@nortelnetworks.c=
om>

> To: 'Madhu  <mailto:madhubabu@kenetec.com&g=
t; Babu 

> Brahmanapally' ; 'Christian

> Groves' <mailto:Christian.Groves@er=
icsson.com>

> Cc: megaco <mailto:megaco@fore.com>

> Sent: Thursday, May 10, 2001 10:06 AM

> Subject: RE: Error Code 505

> 

> 

> Sorry, I took the usage with respect to ROOT as =
a given.  I 

> and Christian (I

> believe) were talking about the hypothesis that =
after ROOT comes up,

> individual terminations are out of service =
until they, too, have been

> signalled in-service through a ServiceChange =
exchange.  As 

> your message

> shows and mine was meant to point out, this is =
not the 

> behaviour people are

> currently assuming.  Of course, maybe I =
misunderstood 

> Christian in the first

> place.

> 

> -----Original Message-----

> From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com

> <mailto:madhubabu@kenetec.com&g=
t; ]

> Sent: Thursday, May 10, 2001 9:47 AM

> To: Taylor, Tom-PT [NORSE:B881:EXCH]; =
'Christian Groves'

> Cc: megaco

> Subject: RE: Error Code 505

> 

> 

> Hi Tom,

> Why is this valid only for ATM? The general =
assumption is 

> that as soon as

> the ROOT ServiceChange is complete, all the =
terminations 

> (irrespective of

> type) provisioned at both MG and MGC are =
in-service. Unless 

> followed by any

> ServiceChange for those terminations whose =
state is out-of-service.

> 

> 

> Regards

> Madhubabu

> 

> -----Original Message-----

> From: Tom-PT Taylor [ mailto:taylor@nortelnetworks.c=
om

> <mailto:taylor@nortelnetworks.c=
om> ]

> Sent: Thursday, May 10, 2001 12:58 AM

> To: 'Christian Groves'

> Cc: Madhu Babu Brahmanapally; =
megaco@fore.com

> Subject: RE: Error Code 505

> 

> 

> Let me put the opposite question: has anyone up =
to now thought that

> terminations are only in service after a =
ServiceChange 

> announcing their

> presence?  I think I can see a possible =
use for such a 

> convention with ATM,

> but I don't see it applying to any other type =
of termination.

> 

> > -----Original Message-----

> > From: Christian Groves [ mailto:Christian.Groves@er=
icsson.com

> <mailto:Christian.Groves@er=
icsson.com> ]

> > Sent: Thursday, May 10, 2001 12:42 =
AM

> > To: Taylor, Tom-PT =
[NORSE:B881:EXCH]

> > Cc: Madhu Babu Brahmanapally; =
megaco@fore.com

> > Subject: Re: Error Code 505

> >

> >

> > You lost me on the first sentence of your =
reply. Why can't

> > ServiceChange

> > bring up a range of termination for the =
first time? I don't see any

> > overriding reason that this must only =
apply to ROOT.

> >

> > Christian

> >

> > Tom-PT Taylor wrote:

> > >

> > > All we're talking about is response =
to a ServiceChange 

> here -- not a

> > > subsequent ServiceChange indicating a =
reversion to the previous

> > > state.  I would suggest that 505 =
should apply only to

> > ServiceChange on

> > > ROOT, not because I have an immediate =
counter-example for the

> > > alternative, but because it feels =
like it would be easy to

> > construct a

> > > counter-example.

> > >

> > > > -----Original =
Message-----

> > > > From: Christian Groves [ mailto:Christian.Groves@er=
icsson.com

> <mailto:Christian.Groves@er=
icsson.com> ]

> > > > Sent: Wednesday, May 09, 2001 =
10:22 PM

> > > > To: Madhu Babu =
Brahmanapally

> > > > Cc: megaco@fore.com

> > > > Subject: Re: Error Code =
505

> > > >

> > > >

> > > > I'd say this is valid also for =
terminations than root. A

> > > servicechange

> > > > can be applied to individual =
terminations and this error

> > code is to

> > > > guard trying to change =
termination characteristics before

> > they have

> > > > restarted.

> > > >

> > > > Christian

> > > >

> > > > Madhu Babu Brahmanapally =
wrote:

> > > > >

> > > > > HI All,

> > > > >

> > > > > The Error code 505 =
description is "Transaction Request

> > > > Received before a

> > > > > ServiceChange Reply has =
been received", does the

> > > > ServiceChange reply here

> > > > > mean the ServiceChange =
reply on ROOT termination? or is

> > > > this valid for other

> > > > > terminations also. I think =
the intention is here is

> > > > ServiceChange for ROOT

> > > > > termination. =
Comments??

> > > > >

> > > > > Regards

> > > > > Madhubabu

> > > >

> >

> 

> 





------_=_NextPart_001_01C0D969.DC470810--


From owner-megaco@fore.com  Thu May 10 12:22:19 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02056
	for ; Thu, 10 May 2001 12:22:18 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA17435;
	Thu, 10 May 2001 12:15:18 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA27563
	for megaco-list; Thu, 10 May 2001 12:12:44 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA27558
	for ; Thu, 10 May 2001 12:12:42 -0400 (EDT)
Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA17157
	for ; Thu, 10 May 2001 12:12:39 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4AG6Zu3015409;
	Thu, 10 May 2001 11:07:04 -0500
From: "Paul Long" 
To: 
Cc: 
Subject: RE: Implementors' Guide Update Editor's last Call Section 6.58
Date: Thu, 10 May 2001 11:07:06 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <3AF9F936.F7DF2B63@ericsson.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id MAA17435
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA02056

Christian,

We were just talking about timestamps on the reflector a week ago. I wished
I had seen this. Item 6.58 changes their semantics considerably. Previously,
service-change timestamps were merely, well, timestamps. This proposal now
makes a service-change timestamp sent by an MGC into a set-time feature on
the MG. I guess this is okay. Hmmm... The MGC won't really know _when_ the
possibly new time base takes effect in the MG, though. The MG may have
already sent messages (and RTP packets?) containing timestamps using its old
time base, so there will be an indefinite period after an MGC sends its
set-time timestamp that it will not know whether the timestamps being
reported by the MG are using the new time base or not. The timestamps will
therefore be ambiguous for an ambiguous amount of time. I guess the MGC will
just have to deal with this the best it can.

Maybe this should be rethought. Personally, I think the IG should just
repair the ASN.1 and ABNF syntax and leave the semantics alone in section
7.2.8.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Christian Groves
Sent: Wednesday, May 09, 2001 9:13 PM
To: Chuong Nguyen
Cc: megaco@fore.com
Subject: Re: Implementors' Guide Update Editor's last Call Section 6.58


G'Day Chuong,

Please see my comments below.

Cheers, Christian

Chuong Nguyen wrote:
>
> Christian
>
> 6.58 TimeStamp in registration replies
> · If the Timestamp is not sent by either the MG or the MGC, both sides
> shall keep their original time base.
>
> Does this now imply that TimeStamp is not required in ServiceChange
> registration?

[CHG] No I don't believe it does. The start of this paragraph has always
stated "The optional Timestamp...." so there is no change.


>
> Megaco Text
> The TimeStamp parameter shall be sent with a registration command and
> its response.



From owner-megaco@fore.com  Thu May 10 12:25:38 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02188
	for ; Thu, 10 May 2001 12:25:37 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA18087;
	Thu, 10 May 2001 12:19:40 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA28611
	for megaco-list; Thu, 10 May 2001 12:16:42 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA28603
	for ; Thu, 10 May 2001 12:16:40 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA17624
	for ; Thu, 10 May 2001 12:16:37 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACH13972;
	Thu, 10 May 2001 12:13:34 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Tom-PT Taylor'" ,
        "'Alf Heidermark \(UAB\)'" ,
        "'Krishna Gundamaraju'" ,
        "'Christian Groves'" 
Cc: "'megaco'" 
Subject: RE: Error Code 505
Date: Thu, 10 May 2001 12:18:16 -0400
Message-ID: <009801c0d96c$d2511b40$c500a8c0@MBRAHMANAPALLY>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0099_01C0D94B.4B3F7B40"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <28560036253BD41191A10000F8BCBD110250CB00@zcard00g.ca.nortel.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0099_01C0D94B.4B3F7B40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: Error Code 505Hi All,
I don't mean the Ephemeral here.
Regards
Madhubabu

  -----Original Message-----
  From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
  Sent: Thursday, May 10, 2001 11:57 AM
  To: 'Madhu Babu Brahmanapally'; 'Alf Heidermark (UAB)'; 'Krishna
Gundamaraju'; 'Christian Groves'
  Cc: 'megaco'
  Subject: RE: Error Code 505


  Careful about that last statement.  Do you really want a ServiceChange
every time an RTP connection is created?

  > -----Original Message-----
  > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
  > Sent: Thursday, May 10, 2001 11:14 AM
  > To: 'Alf Heidermark (UAB)'; 'Krishna Gundamaraju'; Taylor, Tom-PT
  > [NORSE:B881:EXCH]; 'Christian Groves'
  > Cc: 'megaco'
  > Subject: RE: Error Code 505
  >
  >
  > Hi All,
  > In the protocol, there should be a mention that if
  > ServiceChange for ROOT is
  > received from MG, it is implied(or not implied) that all the
  > terminations
  > that are provisioned at both MG and MGC  are inservice(or
  > out-of-service).
  > "I think this particular statement is missing in the protocol."
  >
  > IMHO the MG need not send further InService messages for each
  > termination,
  > as the ROOT ServiceChange should imply this.  But for any new
  > terminations
  > that are not provisioned the MG has to specifically send
  > ServiceChange with
  > "in-service".
  >
  > Regards
  > Madhubabu
  >
  > -----Original Message-----
  > From: Alf Heidermark (UAB) [mailto:Alf.Heidermark@uab.ericsson.se]
  > Sent: Thursday, May 10, 2001 10:46 AM
  > To: 'Krishna Gundamaraju'; Tom-PT Taylor; 'Madhu Babu Brahmanapally';
  > 'Christian Groves'
  > Cc: megaco
  > Subject: RE: Error Code 505
  >
  >
  > Hello
  >
  > If you look in the proposed Annex L you can find for different service
  > change reason what the state of each concened terminastions is.
  >
  > -----Original Message-----
  > From: Krishna Gundamaraju [mailto:krishna.gundamaraju@kenetec.com]
  > Sent: den 10 maj 2001 16:38
  > To: Tom-PT Taylor; 'Madhu Babu Brahmanapally'; 'Christian Groves'
  > Cc: megaco
  > Subject: Re: Error Code 505
  >
  >
  > Hi All,
  >
  >     All along we were thinking that the ROOT ServiceChange
  > implies that all
  > the provisioned terminations are inservice. The Protocol
  > should clearly
  > state what is the correct behavior as otherwise there could
  > be very serious
  > interoperability issues.
  >
  > Regards,
  > Krishna G
  >
  > ----- Original Message -----
  > From: Tom-PT Taylor 
  > To: 'Madhu   Babu
  > Brahmanapally' ; 'Christian
  > Groves' 
  > Cc: megaco 
  > Sent: Thursday, May 10, 2001 10:06 AM
  > Subject: RE: Error Code 505
  >
  >
  > Sorry, I took the usage with respect to ROOT as a given.  I
  > and Christian (I
  > believe) were talking about the hypothesis that after ROOT comes up,
  > individual terminations are out of service until they, too, have been
  > signalled in-service through a ServiceChange exchange.  As
  > your message
  > shows and mine was meant to point out, this is not the
  > behaviour people are
  > currently assuming.  Of course, maybe I misunderstood
  > Christian in the first
  > place.
  >
  > -----Original Message-----
  > From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com
  >  ]
  > Sent: Thursday, May 10, 2001 9:47 AM
  > To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Christian Groves'
  > Cc: megaco
  > Subject: RE: Error Code 505
  >
  >
  > Hi Tom,
  > Why is this valid only for ATM? The general assumption is
  > that as soon as
  > the ROOT ServiceChange is complete, all the terminations
  > (irrespective of
  > type) provisioned at both MG and MGC are in-service. Unless
  > followed by any
  > ServiceChange for those terminations whose state is out-of-service.
  >
  >
  > Regards
  > Madhubabu
  >
  > -----Original Message-----
  > From: Tom-PT Taylor [ mailto:taylor@nortelnetworks.com
  >  ]
  > Sent: Thursday, May 10, 2001 12:58 AM
  > To: 'Christian Groves'
  > Cc: Madhu Babu Brahmanapally; megaco@fore.com
  > Subject: RE: Error Code 505
  >
  >
  > Let me put the opposite question: has anyone up to now thought that
  > terminations are only in service after a ServiceChange
  > announcing their
  > presence?  I think I can see a possible use for such a
  > convention with ATM,
  > but I don't see it applying to any other type of termination.
  >
  > > -----Original Message-----
  > > From: Christian Groves [ mailto:Christian.Groves@ericsson.com
  >  ]
  > > Sent: Thursday, May 10, 2001 12:42 AM
  > > To: Taylor, Tom-PT [NORSE:B881:EXCH]
  > > Cc: Madhu Babu Brahmanapally; megaco@fore.com
  > > Subject: Re: Error Code 505
  > >
  > >
  > > You lost me on the first sentence of your reply. Why can't
  > > ServiceChange
  > > bring up a range of termination for the first time? I don't see any
  > > overriding reason that this must only apply to ROOT.
  > >
  > > Christian
  > >
  > > Tom-PT Taylor wrote:
  > > >
  > > > All we're talking about is response to a ServiceChange
  > here -- not a
  > > > subsequent ServiceChange indicating a reversion to the previous
  > > > state.  I would suggest that 505 should apply only to
  > > ServiceChange on
  > > > ROOT, not because I have an immediate counter-example for the
  > > > alternative, but because it feels like it would be easy to
  > > construct a
  > > > counter-example.
  > > >
  > > > > -----Original Message-----
  > > > > From: Christian Groves [ mailto:Christian.Groves@ericsson.com
  >  ]
  > > > > Sent: Wednesday, May 09, 2001 10:22 PM
  > > > > To: Madhu Babu Brahmanapally
  > > > > Cc: megaco@fore.com
  > > > > Subject: Re: Error Code 505
  > > > >
  > > > >
  > > > > I'd say this is valid also for terminations than root. A
  > > > servicechange
  > > > > can be applied to individual terminations and this error
  > > code is to
  > > > > guard trying to change termination characteristics before
  > > they have
  > > > > restarted.
  > > > >
  > > > > Christian
  > > > >
  > > > > Madhu Babu Brahmanapally wrote:
  > > > > >
  > > > > > HI All,
  > > > > >
  > > > > > The Error code 505 description is "Transaction Request
  > > > > Received before a
  > > > > > ServiceChange Reply has been received", does the
  > > > > ServiceChange reply here
  > > > > > mean the ServiceChange reply on ROOT termination? or is
  > > > > this valid for other
  > > > > > terminations also. I think the intention is here is
  > > > > ServiceChange for ROOT
  > > > > > termination. Comments??
  > > > > >
  > > > > > Regards
  > > > > > Madhubabu
  > > > >
  > >
  >
  >


------=_NextPart_000_0099_01C0D94B.4B3F7B40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




RE: Error Code 505




Hi=20
All,


I=20
don't mean the Ephemeral here. 


Regards


Madhubabu


 



  
-----Original Message-----
From: Tom-PT Taylor=20
  [mailto:taylor@nortelnetworks.com]
Sent: Thursday, May 10, =
2001=20
  11:57 AM
To: 'Madhu Babu Brahmanapally'; 'Alf Heidermark =
(UAB)';=20
  'Krishna Gundamaraju'; 'Christian Groves'
Cc:=20
  'megaco'
Subject: RE: Error Code 505


  
Careful about that last statement.  Do you =
really want a=20
  ServiceChange every time an RTP connection is created? 

  
> -----Original Message----- 
>=20
  From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]=20
  
> Sent: Thursday, May 10, 2001 11:14 AM =

> To: 'Alf Heidermark (UAB)'; 'Krishna Gundamaraju'; =
Taylor,=20
  Tom-PT 
> [NORSE:B881:EXCH]; 'Christian=20
  Groves' 
> Cc: 'megaco' 
>=20
  Subject: RE: Error Code 505 
> =

> 
> Hi All, 
>=20
  In the protocol, there should be a mention that if 
> ServiceChange for ROOT is 
> =
received=20
  from MG, it is implied(or not implied) that all the 
> terminations 
> that are =
provisioned at=20
  both MG and MGC  are inservice(or 
>=20
  out-of-service). 
> "I think this =
particular=20
  statement is missing in the protocol." 
>=20
  
> IMHO the MG need not send further =
InService=20
  messages for each 
> termination, =

> as the ROOT ServiceChange should imply this.  But =
for any new=20
  
> terminations 
> that=20
  are not provisioned the MG has to specifically send 
> ServiceChange with 
>=20
  "in-service". 
> 
>=20
  Regards 
> Madhubabu 
>=20
  
> -----Original Message----- =

> From: Alf Heidermark (UAB) [mailto:Alf.Heidermark@uab.=
ericsson.se]=20
  
> Sent: Thursday, May 10, 2001 10:46 AM =

> To: 'Krishna Gundamaraju'; Tom-PT Taylor; 'Madhu Babu=20
  Brahmanapally'; 
> 'Christian =
Groves'=20
  
> Cc: megaco 
> =
Subject: RE:=20
  Error Code 505 
> 
>=20
  
> Hello 
>=20
  
> If you look in the proposed Annex L you =
can find=20
  for different service 
> change reason =
what the=20
  state of each concened terminastions is. 
>=20
  
> -----Original Message----- =

> From: Krishna Gundamaraju [mailto:krishna.gundamaraj=
u@kenetec.com]=20
  
> Sent: den 10 maj 2001 16:38 
>=20
  To: Tom-PT Taylor; 'Madhu Babu Brahmanapally'; 'Christian =
Groves'=20
  
> Cc: megaco 
> =
Subject: Re:=20
  Error Code 505 
> 
>=20
  
> Hi All, 
>=20
  
>     All along we =
were=20
  thinking that the ROOT ServiceChange 
> =
implies that=20
  all 
> the provisioned terminations are =
inservice.=20
  The Protocol 
> should clearly =

> state what is the correct behavior as otherwise there =
could=20
  
> be very serious 
>=20
  interoperability issues. 
> =

> Regards, 
> Krishna G =

> 
> ----- Original Message =
-----=20
  
> From: Tom-PT Taylor <mailto:taylor@nortelnetworks.co=
m>=20
  
> To: 'Madhu  <mailto:madhubabu@kenetec.com>=
; Babu=20
  
> Brahmanapally' ; 'Christian =

> Groves' <mailto:Christian.Groves@eri=
csson.com>=20
  
> Cc: megaco <mailto:megaco@fore.com> =

> Sent: Thursday, May 10, 2001 10:06 AM 
>=20
  Subject: RE: Error Code 505 
> =

> 
> Sorry, I took the usage =
with respect=20
  to ROOT as a given.  I 
> and =
Christian=20
  (I 
> believe) were talking about the =
hypothesis=20
  that after ROOT comes up, 
> individual =
terminations=20
  are out of service until they, too, have been 
>=20
  signalled in-service through a ServiceChange exchange.  As=20
  
> your message 
> shows=20
  and mine was meant to point out, this is not the 
>=20
  behaviour people are 
> currently =
assuming.  Of=20
  course, maybe I misunderstood 
> Christian =
in the=20
  first 
> place. 
>=20
  
> -----Original Message----- =

> From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com=20
  
> <mailto:madhubabu@kenetec.com>=
;=20
  ] 
> Sent: Thursday, May 10, 2001 9:47 =
AM=20
  
> To: Taylor, Tom-PT [NORSE:B881:EXCH]; =
'Christian=20
  Groves' 
> Cc: megaco 
>=20
  Subject: RE: Error Code 505 
> =

> 
> Hi Tom, 
>=20
  Why is this valid only for ATM? The general assumption is =

> that as soon as 
> the ROOT=20
  ServiceChange is complete, all the terminations 
>=20
  (irrespective of 
> type) provisioned at =
both MG and=20
  MGC are in-service. Unless 
> followed by =
any=20
  
> ServiceChange for those terminations whose =
state is=20
  out-of-service. 
> 
>=20
  
> Regards 
>=20
  Madhubabu 
> 
>=20
  -----Original Message----- 
> From: Tom-PT =
Taylor [=20
  mailto:taylor@nortelnetworks.co=
m=20
  
> <mailto:taylor@nortelnetworks.co=
m>=20
  ] 
> Sent: Thursday, May 10, 2001 12:58 =
AM=20
  
> To: 'Christian Groves' 
> Cc:=20
  Madhu Babu Brahmanapally; megaco@fore.com 
>=20
  Subject: RE: Error Code 505 
> =

> 
> Let me put the opposite =
question: has=20
  anyone up to now thought that 
> =
terminations are=20
  only in service after a ServiceChange 
> =
announcing=20
  their 
> presence?  I think I can see =
a=20
  possible use for such a 
> convention with =

  ATM, 
> but I don't see it applying to any =
other=20
  type of termination. 
> 
>=20
  > -----Original Message----- 
> > =
From:=20
  Christian Groves [ mailto:Christian.Groves@eri=
csson.com=20
  
> <mailto:Christian.Groves@eri=
csson.com>=20
  ] 
> > Sent: Thursday, May 10, 2001 =
12:42=20
  AM 
> > To: Taylor, Tom-PT=20
  [NORSE:B881:EXCH] 
> > Cc: Madhu Babu=20
  Brahmanapally; megaco@fore.com 
> > =
Subject: Re:=20
  Error Code 505 
> > 
>=20
  > 
> > You lost me on the first =
sentence of=20
  your reply. Why can't 
> > =
ServiceChange=20
  
> > bring up a range of termination for the =
first time?=20
  I don't see any 
> > overriding reason =
that this=20
  must only apply to ROOT. 
> > =

> > Christian 
> =
> 
> > Tom-PT Taylor wrote: 
> =
>=20
  > 
> > > All we're talking about =
is=20
  response to a ServiceChange 
> here -- not =
a=20
  
> > > subsequent ServiceChange indicating =
a=20
  reversion to the previous 
> > > =
state. =20
  I would suggest that 505 should apply only to 
>=20
  > ServiceChange on 
> > > ROOT, =
not because=20
  I have an immediate counter-example for the 
> >=20
  > alternative, but because it feels like it would be easy to =

  
> > construct a 
> > >=20
  counter-example. 
> > > =

> > > > -----Original Message----- =

> > > > From: Christian Groves [ mailto:Christian.Groves@eri=
csson.com=20
  
> <mailto:Christian.Groves@eri=
csson.com>=20
  ] 
> > > > Sent: Wednesday, May =
09, 2001=20
  10:22 PM 
> > > > To: Madhu Babu=20
  Brahmanapally 
> > > > Cc:=20
  megaco@fore.com 
> > > > Subject: =
Re: Error=20
  Code 505 
> > > > =

> > > > 
> > > =
> I'd say=20
  this is valid also for terminations than root. A 
>=20
  > > servicechange 
> > > > =
can be=20
  applied to individual terminations and this error 
>=20
  > code is to 
> > > > guard =
trying to=20
  change termination characteristics before 
> >=20
  they have 
> > > > =
restarted.=20
  
> > > > 
> =
> >=20
  > Christian 
> > > > =

> > > > Madhu Babu Brahmanapally wrote: =

> > > > > 
> > =
> >=20
  > HI All, 
> > > > > =

> > > > > The Error code 505 description is =
"Transaction=20
  Request 
> > > > Received before =
a=20
  
> > > > > ServiceChange Reply has =
been=20
  received", does the 
> > > > =
ServiceChange=20
  reply here 
> > > > > mean the =

  ServiceChange reply on ROOT termination? or is 
>=20
  > > > this valid for other 
> =
> >=20
  > > terminations also. I think the intention is here is =

> > > > ServiceChange for ROOT 
>=20
  > > > > termination. Comments?? 
> >=20
  > > > 
> > > > > =
Regards=20
  
> > > > > Madhubabu 
> > > > 
> =
> 
> 
> =



------=_NextPart_000_0099_01C0D94B.4B3F7B40--



From owner-megaco@fore.com  Thu May 10 13:14:34 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03876
	for ; Thu, 10 May 2001 13:14:34 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA23459;
	Thu, 10 May 2001 13:07:22 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA10967
	for megaco-list; Thu, 10 May 2001 13:04:11 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA10950
	for ; Thu, 10 May 2001 13:04:07 -0400 (EDT)
Received: from rwcxch02.clarent.com ([208.205.112.130])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA22999
	for ; Thu, 10 May 2001 13:04:03 -0400 (EDT)
Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 10 May 2001 10:00:29 -0700
Message-ID: <6374EFC78443D41197DD00508B5C35DD03EDEE58@rwcxch02.clarent.com>
From: Richard Brennan 
To: Madhu Babu Brahmanapally 
Cc: megaco@fore.com
Subject: RE: PICS for Megaco
Date: Thu, 10 May 2001 10:00:28 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

The draft ETSI-TIPHON PICS documents are available on the ETSI-TIPHON DocBox
server:

H.248 Protocol Implementation Conformance Statement (PICS) proforma for the
support of physically decomposed multimedia gateway
http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg6/DTS0601
7-1

H.248 Test Suite Structure and Test Purposes for the support of physically
decomposed multimedia gateways
http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg6/DTS0601
7-2

H.248 Abstract Test Suite and PIXIT proforma for the support of physically
decomposed multimedia gateways
http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg6/DTS0601
7-3

These documents will be reviewed, discussed (and in some cases... approved)
at several upcoming ETSI-TIPHON meetings:
http://www.etsi.org/tiphon/meetings_info.htm

TIPHON WG6	21-22 May 2001     Sophia Antipolis  FR
TIPHON-23	9-13 July 2001     Sophia Antipolis  FR 

==================================================
Richard Brennan - Chair, ETSI-TIPHON WG3
Clarent Corporation           Tel: +1 650 481-2906
==================================================


-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Wednesday, May 09, 2001 11:07 AM
To: megaco@fore.com
Subject: PICS for Megaco


Hi All,
Is there any Protocol Implementation Conformance Statement (PICS) for
Megaco. When can a specific vendor say that his implementation confirms to
the protocol specifications.
Regards
Madhubabu


From owner-megaco@fore.com  Thu May 10 13:37:18 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04561
	for ; Thu, 10 May 2001 13:37:17 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA26246;
	Thu, 10 May 2001 13:31:22 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA17806
	for megaco-list; Thu, 10 May 2001 13:28:48 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA17798
	for ; Thu, 10 May 2001 13:28:46 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA25879
	for ; Thu, 10 May 2001 13:28:42 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4AHSh507384
	for ; Thu, 10 May 2001 13:28:43 -0400 (EDT)
Received: from ihgp.ih.lucent.com (h135-1-53-23.lucent.com [135.1.53.23])
	by hoemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4AHSgA07341
	for ; Thu, 10 May 2001 13:28:42 -0400 (EDT)
Received: by ihgp.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id MAA02180; Thu, 10 May 2001 12:28:38 -0500 (CDT)
To: megaco@fore.com
Received: from il0015varney2.lucent.com by ihgp.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id MAA02158; Thu, 10 May 2001 12:28:17 -0500 (CDT)
Message-Id: <4.3.2.7.2.20010510121752.00cb26c0@ihmail.ih.lucent.com>
X-Sender: varney@ihmail.ih.lucent.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 10 May 2001 12:28:09 -0500
Original-To: 
From: Al Varney 
Subject: RE: Implementors' Guide Update Editor's last Call Section 6.58
In-Reply-To: 
References: <3AF9F936.F7DF2B63@ericsson.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

At 11:07 05/10/2001 -0500, Paul Long wrote:

>Maybe this should be rethought. Personally, I think the IG should just
>repair the ASN.1 and ABNF syntax and leave the semantics alone in section
>7.2.8.

    I agree that having the "current" MGC force a time-base change at the 
MG (as a requirement) should be rethought.  Do we really want to preclude 
an MC operating with multiple MGCs (with differing ideas about time)? -- I 
thought 3GPP was looking at just such a mechanism (at a somewhat higher 
level, but "based on" H.248.  BICC is supporting the idea of multiple nodes 
controlling a BIWF -- and that interface is "based on H.248".

    Should an MG give a (new) MGC that kind of control?  A trunking MG?  An 
announcement MG?

    I don't see any advantage in REQUIRING the MG to change/synchronize 
with the current MGC.  An MG without access to another time server, and 
with no recent contact with an MGC, might wish to re-set its 
time-base.  But why not allow the MG to decide.

    So far as I can tell, NOTHING BREAKS if the MG retains its own local 
time base forever --- regardless of how far off it might be from "world time".

Just my opinion,

Al Varney - Lucent Technologies  +1 630 224-7493    varney@lucent.com



From owner-megaco@fore.com  Thu May 10 14:03:52 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05248
	for ; Thu, 10 May 2001 14:03:52 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA28744;
	Thu, 10 May 2001 13:56:29 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA24143
	for megaco-list; Thu, 10 May 2001 13:53:52 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA24139
	for ; Thu, 10 May 2001 13:53:51 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA28507
	for ; Thu, 10 May 2001 13:53:48 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4AHrKdQ001917
	for ; Thu, 10 May 2001 12:53:48 -0500 (CDT)
From: "Paul Long" 
To: "megaco ietf" 
Subject: RE: Implementors' Guide Update Editor's last Call
Date: Thu, 10 May 2001 12:53:50 -0500
Message-ID: 
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)
Importance: Normal
In-Reply-To: <3AF8D832.E727C159@ericsson.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Christian,

My comments:

Item 6.16: Concatenation (e.g., A B) already takes precedence over the
alternative operator (e.g., A / B), so the proposed parentheses are
redundant. (See 3.10/RFC2234.) I guess it doesn't hurt to add them, but this
is technically a clarification and not a correction so it should go in
section 7.

Item 6.58: Inserting the text, "For UDP as a transport," precludes an MG
that uses TCP from also using ServiceChangeAddress. Not that _I_ want to do
such a thing, but is this a necessary constraint? Was this intended?

Item 11.6: I know this is only clarifying text, but you should probably
change "Parsers should accept whitespace..." to "Parsers shall accept
whitespace..."

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Christian Groves
Sent: Wednesday, May 09, 2001 12:40 AM
To: megaco ietf
Cc: Tom-PT Taylor; Glen Freundlich
Subject: Implementors' Guide Update Editor's last Call


G'Day all,

The H.248 Series Implementors' Guide has been updated to revision 6.

It can be found at:
ftp://standard.pictel.com/avc-site/Incoming/
files:
TD-xxx_H248_Implementors_Additions_v6.doc
TD-xxx_H248_Implementors_Additions_v6.pdf

This revision contains the Approved Implementors' Guide and the
Implementors' Guide Additions v5 with some other changes. The changes
are detailed in the document.

This is an editors' last call. Please provide comments on this draft by
Monday the 13th as a revision 7 will be stored on the 14th and sent to
SG16 for approval at the Porto Seguro meeting. If you have a comment on
a correction please provide the detailed solution or exact changes that
you would like to see.

Cheers, Christian



From owner-megaco@fore.com  Thu May 10 14:09:18 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05372
	for ; Thu, 10 May 2001 14:09:18 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA29490;
	Thu, 10 May 2001 14:03:32 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA25878
	for megaco-list; Thu, 10 May 2001 14:00:53 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA25845
	for ; Thu, 10 May 2001 14:00:46 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA29167
	for ; Thu, 10 May 2001 14:00:42 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4AI0gdQ004705
	for ; Thu, 10 May 2001 13:00:42 -0500 (CDT)
From: "Paul Long" 
To: 
Subject: RE: Implementors' Guide Update Editor's last Call Section 6.58
Date: Thu, 10 May 2001 13:00:44 -0500
Message-ID: 
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)
Importance: Normal
In-Reply-To: <4.3.2.7.2.20010510121752.00cb26c0@ihmail.ih.lucent.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Al,

I've mentioned this before, but remember that for an MG to change its time
base to, for example, the one implied by the MGC's timestamp, it must
unregister and then re-register in order to indicate the change to the MGC.
An MG could do this if it wanted to, of course, but sounds like a real waste
of bandwidth and delay.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Al Varney
Sent: Thursday, May 10, 2001 12:28 PM
To: megaco@fore.com
Subject: RE: Implementors' Guide Update Editor's last Call Section 6.58


At 11:07 05/10/2001 -0500, Paul Long wrote:

>Maybe this should be rethought. Personally, I think the IG should just
>repair the ASN.1 and ABNF syntax and leave the semantics alone in section
>7.2.8.

    I agree that having the "current" MGC force a time-base change at the
MG (as a requirement) should be rethought.  Do we really want to preclude
an MC operating with multiple MGCs (with differing ideas about time)? -- I
thought 3GPP was looking at just such a mechanism (at a somewhat higher
level, but "based on" H.248.  BICC is supporting the idea of multiple nodes
controlling a BIWF -- and that interface is "based on H.248".

    Should an MG give a (new) MGC that kind of control?  A trunking MG?  An
announcement MG?

    I don't see any advantage in REQUIRING the MG to change/synchronize
with the current MGC.  An MG without access to another time server, and
with no recent contact with an MGC, might wish to re-set its
time-base.  But why not allow the MG to decide.

    So far as I can tell, NOTHING BREAKS if the MG retains its own local
time base forever --- regardless of how far off it might be from "world
time".

Just my opinion,

Al Varney - Lucent Technologies  +1 630 224-7493    varney@lucent.com



From owner-megaco@fore.com  Thu May 10 14:33:04 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05857
	for ; Thu, 10 May 2001 14:33:04 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA01929;
	Thu, 10 May 2001 14:27:10 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA02514
	for megaco-list; Thu, 10 May 2001 14:23:46 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA02508
	for ; Thu, 10 May 2001 14:23:45 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA01516
	for ; Thu, 10 May 2001 14:23:41 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4AINedQ014031
	for ; Thu, 10 May 2001 13:23:41 -0500 (CDT)
From: "Paul Long" 
To: 
Subject: From whence they came?
Date: Thu, 10 May 2001 13:23:43 -0500
Message-ID: 
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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Item 6.85 got me thinking about the following passages in the spec.

7.2.8: "...replies and pending indications must be sent to the address from
which the corresponding requests originated."
9: "...responses ... must always be sent back to the address which was the
source of the corresponding request."

Are they referring to the source address in the IP header and source port in
the UDP and TCP headers, or are they referring to the mID in the message
header?

Paul Long
ipDialog, Inc.



From owner-megaco@fore.com  Thu May 10 15:02:30 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06269
	for ; Thu, 10 May 2001 15:02:29 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA04362;
	Thu, 10 May 2001 14:52:50 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA10503
	for megaco-list; Thu, 10 May 2001 14:50:15 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA10485
	for ; Thu, 10 May 2001 14:50:12 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id OAA03981
	for ; Thu, 10 May 2001 14:50:09 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id OAA08136; Thu, 10 May 2001 14:50:03 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 10 May 2001 14:49:35 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 10 May 2001 14:49:37 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB06@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Paul Long'" , megaco 
Subject: RE: From whence they came?
Date: Thu, 10 May 2001 14:49:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D981.F265A490"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D981.F265A490
Content-Type: text/plain;
	charset="ISO-8859-1"

They refer to the source address in the IP header and source port in the
TCP/UDP/SCTP headers.  mID is just a tag to identify the peer in an
association.

> -----Original Message-----
> From: Paul Long [mailto:plong@ipdialog.com]
> Sent: Thursday, May 10, 2001 2:24 PM
> To: megaco
> Subject: From whence they came?
> 
> 
> Item 6.85 got me thinking about the following passages in the spec.
> 
> 7.2.8: "...replies and pending indications must be sent to 
> the address from
> which the corresponding requests originated."
> 9: "...responses ... must always be sent back to the address 
> which was the
> source of the corresponding request."
> 
> Are they referring to the source address in the IP header and 
> source port in
> the UDP and TCP headers, or are they referring to the mID in 
> the message
> header?
> 
> Paul Long
> ipDialog, Inc.
> 
> 

------_=_NextPart_001_01C0D981.F265A490
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: From whence they came?




They refer to the source address in the IP header and =
source port in the TCP/UDP/SCTP headers.  mID is just a tag to =
identify the peer in an association.



> -----Original Message-----

> From: Paul Long [mailto:plong@ipdialog.com]=


> Sent: Thursday, May 10, 2001 2:24 PM

> To: megaco

> Subject: From whence they came?

> 

> 

> Item 6.85 got me thinking about the following =
passages in the spec.

> 

> 7.2.8: "...replies and pending indications =
must be sent to 

> the address from

> which the corresponding requests =
originated."

> 9: "...responses ... must always be sent =
back to the address 

> which was the

> source of the corresponding =
request."

> 

> Are they referring to the source address in the =
IP header and 

> source port in

> the UDP and TCP headers, or are they referring =
to the mID in 

> the message

> header?

> 

> Paul Long

> ipDialog, Inc.

> 

> 





------_=_NextPart_001_01C0D981.F265A490--


From owner-megaco@fore.com  Thu May 10 15:19:26 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06535
	for ; Thu, 10 May 2001 15:19:26 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA06334;
	Thu, 10 May 2001 15:11:20 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA15902
	for megaco-list; Thu, 10 May 2001 15:08:48 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA15873
	for ; Thu, 10 May 2001 15:08:45 -0400 (EDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA06057
	for ; Thu, 10 May 2001 15:08:41 -0400 (EDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA14900
	for ; Thu, 10 May 2001 14:08:43 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4AJ8gC29535
	for ; Thu, 10 May 2001 14:08:42 -0500 (CDT)
Message-ID: <3AFAE686.28F73C96@usa.alcatel.com>
Date: Thu, 10 May 2001 14:05:42 -0500
From: Albert Frankovich 
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Embedded Event Descriptor
Content-Type: multipart/mixed;
 boundary="------------E6C5696EE88422C4455C701A"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.
--------------E6C5696EE88422C4455C701A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

Case #1.
MGC sets up an embedded event descriptor in the NULL context
to issue dial tone, report on-hook/off-hook and collect digits.
Now the subscriber goes off-hook followed immediately by an on-hook.
The termination is  in the NULL context.

Question:  Will the original event descriptors that were setup by the
MGC still be in effect or does the MGC still have to rearm the MG
with the embedded event?


Case #2.
This question is related to Case #1.
MG has collected digits and reported them to the MGC.
The termination is not in the NULL context.
Now the subscriber goes on-hook followed immediately by an off-hook
within the Suspend/Resume time.

Question:  Will the Subscriber hear dial tone from the original embedded

event or will it no longer be active?


Thanks
Al




--------------E6C5696EE88422C4455C701A
Content-Type: text/x-vcard; charset=us-ascii;
 name="afrankov.vcf"
Content-Description: Card for Albert Frankovich
Content-Disposition: attachment;
 filename="afrankov.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Frankovich;Albert
tel;work:972-519-4131
x-mozilla-html:FALSE
org:AlcatelUSA
adr:;;;Plano;TX;75075;
version:2.1
email;internet:afrankov@usa.alcatel.com
title:SFTWR DEV ENG SR
x-mozilla-cpt:;-4112
fn:Albert Frankovich
end:vcard

--------------E6C5696EE88422C4455C701A--



From owner-megaco@fore.com  Thu May 10 15:42:17 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06895
	for ; Thu, 10 May 2001 15:42:17 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA08506;
	Thu, 10 May 2001 15:35:09 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA21681
	for megaco-list; Thu, 10 May 2001 15:31:56 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA21673
	for ; Thu, 10 May 2001 15:31:55 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA08101
	for ; Thu, 10 May 2001 15:31:51 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACH15862;
	Thu, 10 May 2001 15:31:37 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Albert Frankovich'" , 
Subject: RE: Embedded Event Descriptor
Date: Thu, 10 May 2001 15:36:19 -0400
Message-ID: <001f01c0d988$7cf19280$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <3AFAE686.28F73C96@usa.alcatel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Al,
Comments below [Madhu]

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Albert
Frankovich
Sent: Thursday, May 10, 2001 3:06 PM
To: megaco@fore.com
Subject: Embedded Event Descriptor


Hello,

Case #1.
MGC sets up an embedded event descriptor in the NULL context
to issue dial tone, report on-hook/off-hook and collect digits.
Now the subscriber goes off-hook followed immediately by an on-hook.
The termination is  in the NULL context.

Question:  Will the original event descriptors that were setup by the
MGC still be in effect or does the MGC still have to rearm the MG
with the embedded event?
[Madhu] The embedded descriptor will be active until another event
descriptor is sent by the MGC. In you example if the embedded descriptor has
al/of, al/on and dd/ce {with some digit map name}. This event descriptor
will be active till another is sent. Hence if users goes offhook after
onhook, then also the offhook gets reported.
"The theory is that the event descriptor will be active even after reporting
events that are present in it".

Case #2.
This question is related to Case #1.
MG has collected digits and reported them to the MGC.
The termination is not in the NULL context.
Now the subscriber goes on-hook followed immediately by an off-hook
within the Suspend/Resume time.

Question:  Will the Subscriber hear dial tone from the original embedded
event or will it no longer be active?
[Madhu] The event reporting mechanism doesn't depend whether the Termination
is in Null context or active context. Its is solely based on the event
descriptor. If the event descriptor is same as the in case#1, the user will
not hear dial tone if he/she goes offhook immediately after onhook.



Thanks
Al



Regards
Madhubabu



From owner-megaco@fore.com  Thu May 10 16:46:30 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07994
	for ; Thu, 10 May 2001 16:46:29 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA15259;
	Thu, 10 May 2001 16:40:43 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA10176
	for megaco-list; Thu, 10 May 2001 16:38:04 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA10167
	for ; Thu, 10 May 2001 16:38:02 -0400 (EDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA15131
	for ; Thu, 10 May 2001 16:37:58 -0400 (EDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id PAA27514
	for ; Thu, 10 May 2001 15:38:00 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4AKc0C28333
	for ; Thu, 10 May 2001 15:38:00 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4AKbS120163
	for ; Thu, 10 May 2001 15:37:28 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4AKbSO02999
	for ; Thu, 10 May 2001 15:37:28 -0500 (CDT)
Message-ID: <3AFAFC08.2B687E94@usa.alcatel.com>
Date: Thu, 10 May 2001 15:37:28 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Embedded Event Descriptor
References: <001f01c0d988$7cf19280$c500a8c0@MBRAHMANAPALLY>
Content-Type: multipart/alternative;
 boundary="------------A8174A08338D67F33AB9D041"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------A8174A08338D67F33AB9D041
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Well, there is a lot more here than meets the eye.
Lets set aside how this transaction is formed in the first place and the race
condition issue
involved w/something like.

Questions inserted below:

Madhu Babu Brahmanapally wrote:

> Hi Al,
> Comments below [Madhu]
>
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Albert
> Frankovich
> Sent: Thursday, May 10, 2001 3:06 PM
> To: megaco@fore.com
> Subject: Embedded Event Descriptor
>
> Hello,
>
> Case #1.
> MGC sets up an embedded event descriptor in the NULL context
> to issue dial tone, report on-hook/off-hook and collect digits.
> Now the subscriber goes off-hook followed immediately by an on-hook.
> The termination is  in the NULL context.
>
> Question:  Will the original event descriptors that were setup by the
> MGC still be in effect or does the MGC still have to rearm the MG
> with the embedded event?
> [Madhu] The embedded descriptor will be active until another event
> descriptor is sent by the MGC. In you example if the embedded descriptor has
> al/of, al/on and dd/ce {with some digit map name}. This event descriptor
> will be active till another is sent. Hence if users goes offhook after
> onhook, then also the offhook gets reported.
> "The theory is that the event descriptor will be active even after reporting
> events that are present in it".
>
> Case #2.
> This question is related to Case #1.
> MG has collected digits and reported them to the MGC.
> The termination is not in the NULL context.
> Now the subscriber goes on-hook followed immediately by an off-hook
> within the Suspend/Resume time.
>

  Does "within the Suspend/Resume time" mean that the call is not being
released?
               Thus termination should not be subtracted from the context.

               Is the question really - if termination is not Subtracted from
the context,
               shouldn't the event descriptor still be valid?

              Or is the question about whether an event has to be rearmed once
MG has
              detected the event?  That is does MGC have to tell MG to detect
eventA again
              if MG notified MGC that eventA has been detected?




>
> Question:  Will the Subscriber hear dial tone from the original embedded
> event or will it no longer be active?
> [Madhu] The event reporting mechanism doesn't depend whether the Termination
> is in Null context or active context. Its is solely based on the event
> descriptor. If the event descriptor is same as the in case#1, the user will
> not hear dial tone if he/she goes offhook immediately after onhook.
>
> Thanks
> Al
>
> Regards
> Madhubabu

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------A8174A08338D67F33AB9D041
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

Well, there is a lot more here than meets the eye.

Lets set aside how this transaction is formed in the first place and
the race condition issue

involved w/something like.

Questions inserted below:

Madhu Babu Brahmanapally wrote:

Hi Al,

Comments below [Madhu]

-----Original Message-----

From: owner-megaco@pit.comms.marconi.com

[mailto:owner-megaco@pit.comms.marconi.com]On
Behalf Of Albert

Frankovich

Sent: Thursday, May 10, 2001 3:06 PM

To: megaco@fore.com

Subject: Embedded Event Descriptor

Hello,

Case #1.

MGC sets up an embedded event descriptor in the NULL context

to issue dial tone, report on-hook/off-hook and collect digits.

Now the subscriber goes off-hook followed immediately by an on-hook.

The termination is  in the NULL context.

Question:  Will the original event descriptors that were setup
by the

MGC still be in effect or does the MGC still have to rearm the MG

with the embedded event?

[Madhu] The embedded descriptor will be active until another event

descriptor is sent by the MGC. In you example if the embedded descriptor
has

al/of, al/on and dd/ce {with some digit map name}. This event descriptor

will be active till another is sent. Hence if users goes offhook after

onhook, then also the offhook gets reported.

"The theory is that the event descriptor will be active even after
reporting

events that are present in it".

Case #2.

This question is related to Case #1.

MG has collected digits and reported them to the MGC.

The termination is not in the NULL context.

Now the subscriber goes on-hook followed immediately by an off-hook

within the Suspend/Resume time.

 

<cnn>  Does "within the Suspend/Resume time" mean that the call
is not being released?

              
Thus termination should not be subtracted from the context.

              
Is the question really - if termination is not Subtracted from the context,

              
shouldn't the event descriptor still be valid?

             
Or is the question about whether an event has to be rearmed once MG has

             
detected the event?  That is does MGC have to tell MG to detect eventA
again

             
if MG notified MGC that eventA has been detected?

 

 

 

 

Question:  Will the Subscriber hear dial tone from the original
embedded

event or will it no longer be active?

[Madhu] The event reporting mechanism doesn't depend whether the Termination

is in Null context or active context. Its is solely based on the event

descriptor. If the event descriptor is same as the in case#1, the user
will

not hear dial tone if he/she goes offhook immediately after onhook.

Thanks

Al

Regards

Madhubabu



-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------A8174A08338D67F33AB9D041--



From owner-megaco@fore.com  Thu May 10 17:24:00 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08542
	for ; Thu, 10 May 2001 17:23:59 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA17109;
	Thu, 10 May 2001 17:16:53 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA15483
	for megaco-list; Thu, 10 May 2001 17:12:45 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15477
	for ; Thu, 10 May 2001 17:12:42 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA16790
	for ; Thu, 10 May 2001 17:12:38 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4ALCec13481
	for ; Thu, 10 May 2001 17:12:40 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4ALCea13477
	for ; Thu, 10 May 2001 17:12:40 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id RAA18982; Thu, 10 May 2001 17:12:14 -0400 (EDT)
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id RAA18978; Thu, 10 May 2001 17:12:14 -0400 (EDT)
Message-ID: <3AFB03BA.B39E53D6@lucent.com>
Date: Thu, 10 May 2001 17:10:18 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: MEGACO list 
Subject: empty quotedString ?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Greetings,

Can we change

   quotedString         = DQUOTE 1*(SafeChar / RestChar/ WSP) DQUOTE

to

   quotedString         = DQUOTE  *(SafeChar / RestChar/ WSP) DQUOTE

?

In general, I think it's pretty reasonable. 
And specifically, section E.6.2 says under parameter "ds", 
"string of digit map symbols (possibly empty) returned as 
a quoted string".

-troy


From owner-megaco@fore.com  Thu May 10 17:38:47 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08686
	for ; Thu, 10 May 2001 17:38:46 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA18008;
	Thu, 10 May 2001 17:33:03 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA18300
	for megaco-list; Thu, 10 May 2001 17:30:51 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA18292
	for ; Thu, 10 May 2001 17:30:49 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA17849
	for ; Thu, 10 May 2001 17:30:45 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4ALUedQ028122
	for ; Thu, 10 May 2001 16:30:40 -0500 (CDT)
From: "Paul Long" 
To: "MEGACO list" 
Subject: RE: empty quotedString ?
Date: Thu, 10 May 2001 16:30:42 -0500
Message-ID: 
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
In-Reply-To: <3AFB03BA.B39E53D6@lucent.com>
Importance: Normal
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Troy,

Sounds reasonable to me, especially considering that the ASN.1 allows the
equivalent of an empty string.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Troy Cauble
Sent: Thursday, May 10, 2001 4:10 PM
To: MEGACO list
Subject: empty quotedString ?




Greetings,

Can we change

   quotedString         = DQUOTE 1*(SafeChar / RestChar/ WSP) DQUOTE

to

   quotedString         = DQUOTE  *(SafeChar / RestChar/ WSP) DQUOTE

?

In general, I think it's pretty reasonable.
And specifically, section E.6.2 says under parameter "ds",
"string of digit map symbols (possibly empty) returned as
a quoted string".

-troy



From owner-megaco@fore.com  Thu May 10 17:48:22 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08808
	for ; Thu, 10 May 2001 17:48:21 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA18562;
	Thu, 10 May 2001 17:42:34 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA19372
	for megaco-list; Thu, 10 May 2001 17:40:12 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA19367
	for ; Thu, 10 May 2001 17:40:09 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA18378
	for ; Thu, 10 May 2001 17:40:05 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4ALe5dQ001232
	for ; Thu, 10 May 2001 16:40:06 -0500 (CDT)
From: "Paul Long" 
To: "megaco" 
Subject: RE: From whence they came?
Date: Thu, 10 May 2001 16:40:07 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001A_01C0D96F.DF67E860"
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
In-Reply-To: <28560036253BD41191A10000F8BCBD110250CB06@zcard00g.ca.nortel.com>
Importance: Normal
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_001A_01C0D96F.DF67E860
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: From whence they came?Tom,

Okay, then, and this may be a stupid question, but what is the difference
between "the peer in an association" and the source of a message? IOW, under
what circumstances might they be different? The reason I was confused was
probably because in H.323 the source of a message is of absolutely no
consequence.

Paul Long
ipDialog, Inc.
  -----Original Message-----
  From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
  Sent: Thursday, May 10, 2001 1:50 PM
  To: 'Paul Long'; megaco
  Subject: RE: From whence they came?


  They refer to the source address in the IP header and source port in the
TCP/UDP/SCTP headers.  mID is just a tag to identify the peer in an
association.

  > -----Original Message-----
  > From: Paul Long [mailto:plong@ipdialog.com]
  > Sent: Thursday, May 10, 2001 2:24 PM
  > To: megaco
  > Subject: From whence they came?
  >
  >
  > Item 6.85 got me thinking about the following passages in the spec.
  >
  > 7.2.8: "...replies and pending indications must be sent to
  > the address from
  > which the corresponding requests originated."
  > 9: "...responses ... must always be sent back to the address
  > which was the
  > source of the corresponding request."
  >
  > Are they referring to the source address in the IP header and
  > source port in
  > the UDP and TCP headers, or are they referring to the mID in
  > the message
  > header?
  >
  > Paul Long
  > ipDialog, Inc.


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


RE: From whence they came?




Tom,


 


Okay,=20
then, and this may be a stupid question, but what is the difference =
between "the=20
peer in an association" and the source of a message? IOW, under what=20
circumstances might they be different? The reason I was confused was =
probably=20
because in H.323 the source of a message is of absolutely no=20
consequence.


 


Paul=20
Long


ipDialog, Inc.



  
-----Original Message-----
From: Tom-PT Taylor=20
  [mailto:taylor@nortelnetworks.com]
Sent: Thursday, May 10, =
2001 1:50=20
  PM
To: 'Paul Long'; megaco
Subject: RE: From =
whence they=20
  came?


  
They refer to the source address in the IP header =
and source=20
  port in the TCP/UDP/SCTP headers.  mID is just a tag to identify =
the peer=20
  in an association.

  
> -----Original Message----- 
>=20
  From: Paul Long [mailto:plong@ipdialog.com] =

  
> Sent: Thursday, May 10, 2001 2:24 PM =

> To: megaco 
> Subject: From =
whence they=20
  came? 
> 
>=20
  
> Item 6.85 got me thinking about the =
following=20
  passages in the spec. 
> 
> 7.2.8: "...replies and pending indications must be sent =
to=20
  
> the address from 
>=20
  which the corresponding requests originated." 
> 9:=20
  "...responses ... must always be sent back to the address =

> which was the 
> source of =
the=20
  corresponding request." 
> =

> Are they referring to the source address in the IP =
header and=20
  
> source port in 
> the=20
  UDP and TCP headers, or are they referring to the mID in =

> the message 
> =
header? 
> 
> Paul Long =

> ipDialog, Inc.


------=_NextPart_000_001A_01C0D96F.DF67E860--



From owner-megaco@fore.com  Thu May 10 19:05:50 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09731
	for ; Thu, 10 May 2001 19:05:50 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA24504;
	Thu, 10 May 2001 18:58:37 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA02222
	for megaco-list; Thu, 10 May 2001 18:56:07 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA02216
	for ; Thu, 10 May 2001 18:56:05 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id SAA24200
	for ; Thu, 10 May 2001 18:56:01 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id SAA02832; Thu, 10 May 2001 18:55:59 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Thu, 10 May 2001 18:55:50 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 10 May 2001 18:55:51 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB0C@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Paul Long'" , megaco 
Subject: RE: From whence they came?
Date: Thu, 10 May 2001 18:55:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D9A4.5C218B20"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D9A4.5C218B20
Content-Type: text/plain;
	charset="ISO-8859-1"

It's partly the difference between a physical and a logical unit in a
load-sharing architecture where the separate units have different addresses.
There's also the possibility that a single physical unit has multiple
network interfaces.  Using the address as received in the header is
important because it gives a beter chnace of the response getting back
through any intervening firewall.

-----Original Message-----
From: Paul Long [mailto:plong@ipdialog.com]
Sent: Thursday, May 10, 2001 5:40 PM
To: megaco
Subject: RE: From whence they came?


Tom,
 
Okay, then, and this may be a stupid question, but what is the difference
between "the peer in an association" and the source of a message? IOW, under
what circumstances might they be different? The reason I was confused was
probably because in H.323 the source of a message is of absolutely no
consequence.
 
Paul Long
ipDialog, Inc.

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Thursday, May 10, 2001 1:50 PM
To: 'Paul Long'; megaco
Subject: RE: From whence they came?



They refer to the source address in the IP header and source port in the
TCP/UDP/SCTP headers.  mID is just a tag to identify the peer in an
association.

> -----Original Message----- 
> From: Paul Long [ mailto:plong@ipdialog.com  ] 
> Sent: Thursday, May 10, 2001 2:24 PM 
> To: megaco 
> Subject: From whence they came? 
> 
> 
> Item 6.85 got me thinking about the following passages in the spec. 
> 
> 7.2.8: "...replies and pending indications must be sent to 
> the address from 
> which the corresponding requests originated." 
> 9: "...responses ... must always be sent back to the address 
> which was the 
> source of the corresponding request." 
> 
> Are they referring to the source address in the IP header and 
> source port in 
> the UDP and TCP headers, or are they referring to the mID in 
> the message 
> header? 
> 
> Paul Long 
> ipDialog, Inc.


------_=_NextPart_001_01C0D9A4.5C218B20
Content-Type: text/html;
	charset="ISO-8859-1"




RE: From whence they came?




It's 
partly the difference between a physical and a logical unit in a load-sharing 
architecture where the separate units have different addresses.  There's 
also the possibility that a single physical unit has multiple network 
interfaces.  Using the address as received in the header is important 
because it gives a beter chnace of the response getting back through any 
intervening firewall.



  
-----Original Message-----
From: Paul Long 
  [mailto:plong@ipdialog.com]
Sent: Thursday, May 10, 2001 5:40 
  PM
To: megaco
Subject: RE: From whence they 
  came?


  
Tom,

  
 

  
Okay, then, and this may be a stupid question, but what is the 
  difference between "the peer in an association" and the source of a message? 
  IOW, under what circumstances might they be different? The reason I was 
  confused was probably because in H.323 the source of a message is of 
  absolutely no consequence.

  
 

  
Paul 
  Long

  
ipDialog, Inc.

  

    
-----Original Message-----
From: Tom-PT Taylor 
    [mailto:taylor@nortelnetworks.com]
Sent: Thursday, May 10, 2001 
    1:50 PM
To: 'Paul Long'; megaco
Subject: RE: From whence 
    they came?


    
They refer to the source address in the IP header and source 
    port in the TCP/UDP/SCTP headers.  mID is just a tag to identify the 
    peer in an association.

    
> -----Original Message----- 
> 
    From: Paul Long [mailto:plong@ipdialog.com] 
    
> Sent: Thursday, May 10, 2001 2:24 PM 
> To: megaco 
> Subject: From whence 
    they came? 
> 
> 
    
> Item 6.85 got me thinking about the following 
    passages in the spec. 
> 
> 7.2.8: "...replies and pending indications must be sent to 
    
> the address from 
> 
    which the corresponding requests originated." 
> 
    9: "...responses ... must always be sent back to the address 
    
> which was the 
> 
    source of the corresponding request." 
> 
    
> Are they referring to the source address in the 
    IP header and 
> source port in 
> the UDP and TCP headers, or are they referring to the mID in 
    
> the message 
> 
    header? 
> 
> Paul 
    Long 
> ipDialog, 
Inc.


------_=_NextPart_001_01C0D9A4.5C218B20--


From owner-megaco@fore.com  Thu May 10 19:08:28 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09753
	for ; Thu, 10 May 2001 19:08:28 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA24848;
	Thu, 10 May 2001 19:02:24 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id TAA02824
	for megaco-list; Thu, 10 May 2001 19:00:30 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA02820
	for ; Thu, 10 May 2001 19:00:28 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA24696
	for ; Thu, 10 May 2001 19:00:24 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4AN0Qv04439
	for ; Thu, 10 May 2001 19:00:26 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4AN0QU04435
	for ; Thu, 10 May 2001 19:00:26 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id TAA20242; Thu, 10 May 2001 19:00:25 -0400 (EDT)
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id TAA20238; Thu, 10 May 2001 19:00:25 -0400 (EDT)
Message-ID: <3AFB1D14.8A83521A@lucent.com>
Date: Thu, 10 May 2001 18:58:28 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Implementors' Guide Update Editor's last Call Section 6.58
References: <3AF9F936.F7DF2B63@ericsson.com> <4.3.2.7.2.20010510121752.00cb26c0@ihmail.ih.lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


I strongly agree.  There is no need synchronize 
the MG and MGC's sense of time.

-troy


Al Varney wrote:
> 
> At 11:07 05/10/2001 -0500, Paul Long wrote:
> 
> >Maybe this should be rethought. Personally, I think the IG should just
> >repair the ASN.1 and ABNF syntax and leave the semantics alone in section
> >7.2.8.
> 
>     I agree that having the "current" MGC force a time-base change at the
> MG (as a requirement) should be rethought.  Do we really want to preclude
> an MC operating with multiple MGCs (with differing ideas about time)? -- I
> thought 3GPP was looking at just such a mechanism (at a somewhat higher
> level, but "based on" H.248.  BICC is supporting the idea of multiple nodes
> controlling a BIWF -- and that interface is "based on H.248".
> 
>     Should an MG give a (new) MGC that kind of control?  A trunking MG?  An
> announcement MG?
> 
>     I don't see any advantage in REQUIRING the MG to change/synchronize
> with the current MGC.  An MG without access to another time server, and
> with no recent contact with an MGC, might wish to re-set its
> time-base.  But why not allow the MG to decide.
> 
>     So far as I can tell, NOTHING BREAKS if the MG retains its own local
> time base forever --- regardless of how far off it might be from "world time".
> 
> Just my opinion,
> 
> Al Varney - Lucent Technologies  +1 630 224-7493    varney@lucent.com


From owner-megaco@fore.com  Thu May 10 19:38:48 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10161
	for ; Thu, 10 May 2001 19:38:48 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA26788;
	Thu, 10 May 2001 19:31:47 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id TAA06274
	for megaco-list; Thu, 10 May 2001 19:29:33 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA06270
	for ; Thu, 10 May 2001 19:29:31 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id TAA26577
	for ; Thu, 10 May 2001 19:29:27 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id TAA03586; Thu, 10 May 2001 19:29:25 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Thu, 10 May 2001 19:29:28 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 10 May 2001 19:29:29 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB0D@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Troy Cauble'" , megaco@fore.com
Subject: RE: Implementors' Guide Update Editor's last Call Section 6.58 [F INAL]
Date: Thu, 10 May 2001 19:29:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D9A9.0E6E6470"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D9A9.0E6E6470
Content-Type: text/plain;
	charset="ISO-8859-1"

Let's call that a consensus.

> -----Original Message-----
> From: Troy Cauble [mailto:troy@lucent.com]
> Sent: Thursday, May 10, 2001 6:58 PM
> To: megaco@fore.com
> Subject: Re: Implementors' Guide Update Editor's last Call 
> Section 6.58
> 
> 
> 
> I strongly agree.  There is no need synchronize 
> the MG and MGC's sense of time.
> 
> -troy
> 
> 
> Al Varney wrote:
> > 
> > At 11:07 05/10/2001 -0500, Paul Long wrote:
> > 
> > >Maybe this should be rethought. Personally, I think the IG 
> should just
> > >repair the ASN.1 and ABNF syntax and leave the semantics 
> alone in section
> > >7.2.8.
> > 
> >     I agree that having the "current" MGC force a time-base 
> change at the
> > MG (as a requirement) should be rethought.  Do we really 
> want to preclude
> > an MC operating with multiple MGCs (with differing ideas 
> about time)? -- I
> > thought 3GPP was looking at just such a mechanism (at a 
> somewhat higher
> > level, but "based on" H.248.  BICC is supporting the idea 
> of multiple nodes
> > controlling a BIWF -- and that interface is "based on H.248".
> > 
> >     Should an MG give a (new) MGC that kind of control?  A 
> trunking MG?  An
> > announcement MG?
> > 
> >     I don't see any advantage in REQUIRING the MG to 
> change/synchronize
> > with the current MGC.  An MG without access to another time 
> server, and
> > with no recent contact with an MGC, might wish to re-set its
> > time-base.  But why not allow the MG to decide.
> > 
> >     So far as I can tell, NOTHING BREAKS if the MG retains 
> its own local
> > time base forever --- regardless of how far off it might be 
> from "world time".
> > 
> > Just my opinion,
> > 
> > Al Varney - Lucent Technologies  +1 630 224-7493    
> varney@lucent.com
> 

------_=_NextPart_001_01C0D9A9.0E6E6470
Content-Type: text/html;
	charset="ISO-8859-1"






RE: Implementors' Guide Update Editor's last Call Section 6.58 [FINAL]




Let's call that a consensus.




> -----Original Message-----

> From: Troy Cauble [mailto:troy@lucent.com]

> Sent: Thursday, May 10, 2001 6:58 PM

> To: megaco@fore.com

> Subject: Re: Implementors' Guide Update Editor's last Call 

> Section 6.58

> 

> 

> 

> I strongly agree.  There is no need synchronize 

> the MG and MGC's sense of time.

> 

> -troy

> 

> 

> Al Varney wrote:

> > 

> > At 11:07 05/10/2001 -0500, Paul Long wrote:

> > 

> > >Maybe this should be rethought. Personally, I think the IG 

> should just

> > >repair the ASN.1 and ABNF syntax and leave the semantics 

> alone in section

> > >7.2.8.

> > 

> >     I agree that having the "current" MGC force a time-base 

> change at the

> > MG (as a requirement) should be rethought.  Do we really 

> want to preclude

> > an MC operating with multiple MGCs (with differing ideas 

> about time)? -- I

> > thought 3GPP was looking at just such a mechanism (at a 

> somewhat higher

> > level, but "based on" H.248.  BICC is supporting the idea 

> of multiple nodes

> > controlling a BIWF -- and that interface is "based on H.248".

> > 

> >     Should an MG give a (new) MGC that kind of control?  A 

> trunking MG?  An

> > announcement MG?

> > 

> >     I don't see any advantage in REQUIRING the MG to 

> change/synchronize

> > with the current MGC.  An MG without access to another time 

> server, and

> > with no recent contact with an MGC, might wish to re-set its

> > time-base.  But why not allow the MG to decide.

> > 

> >     So far as I can tell, NOTHING BREAKS if the MG retains 

> its own local

> > time base forever --- regardless of how far off it might be 

> from "world time".

> > 

> > Just my opinion,

> > 

> > Al Varney - Lucent Technologies  +1 630 224-7493    

> varney@lucent.com

> 





------_=_NextPart_001_01C0D9A9.0E6E6470--


From owner-megaco@fore.com  Thu May 10 20:10:42 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10409
	for ; Thu, 10 May 2001 20:10:42 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA29228;
	Thu, 10 May 2001 20:03:15 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA10185
	for megaco-list; Thu, 10 May 2001 20:00:46 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA10179
	for ; Thu, 10 May 2001 20:00:44 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA28966
	for ; Thu, 10 May 2001 20:00:40 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4B00edQ022351;
	Thu, 10 May 2001 19:00:40 -0500 (CDT)
From: "Paul Long" 
To: "Christian Groves" ,
        "megaco ietf" 
Subject: RE: Implementors' Guide Update Editor's last Call
Date: Thu, 10 May 2001 19:00:42 -0500
Message-ID: 
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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <3AF8D832.E727C159@ericsson.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Christian,

I've got a few more additions. Is it too late? These are mostly just a
summary of the things I've had resolved recently on the reflector. Here are
HTML and Word pages of the same content. (The HTML page doesn't render too
well using Netscape. I guess because it was generated by Word. :-)

http://www.packetizer.com/people/plong/IGContribs.htm
http://www.packetizer.com/people/plong/IGContribs.doc

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Christian Groves
Sent: Wednesday, May 09, 2001 12:40 AM
To: megaco ietf
Cc: Tom-PT Taylor; Glen Freundlich
Subject: Implementors' Guide Update Editor's last Call


G'Day all,

The H.248 Series Implementors' Guide has been updated to revision 6.

It can be found at:
ftp://standard.pictel.com/avc-site/Incoming/
files:
TD-xxx_H248_Implementors_Additions_v6.doc
TD-xxx_H248_Implementors_Additions_v6.pdf

This revision contains the Approved Implementors' Guide and the
Implementors' Guide Additions v5 with some other changes. The changes
are detailed in the document.

This is an editors' last call. Please provide comments on this draft by
Monday the 13th as a revision 7 will be stored on the 14th and sent to
SG16 for approval at the Porto Seguro meeting. If you have a comment on
a correction please provide the detailed solution or exact changes that
you would like to see.

Cheers, Christian



From owner-megaco@fore.com  Thu May 10 20:13:17 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10470
	for ; Thu, 10 May 2001 20:13:17 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA29664;
	Thu, 10 May 2001 20:07:37 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA10836
	for megaco-list; Thu, 10 May 2001 20:05:36 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA10832
	for ; Thu, 10 May 2001 20:05:35 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id UAA29462
	for ; Thu, 10 May 2001 20:05:31 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id UAA04374; Thu, 10 May 2001 20:05:29 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 10 May 2001 20:05:31 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 10 May 2001 20:05:33 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB0E@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'megaco'" 
Subject: Annex C Descriptor Assignments
Date: Thu, 10 May 2001 20:05:32 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Here is the contribution to SG 16 I've drafted on the subject of descriptor
assignments for the Annex C properties.

TITLE:	Descriptors For Megaco/H.248 Annex C Properties
___________________


INTRODUCTION

Megaco/H.248 Annex C defines a set of properties relating to media streams.
As such, these properties may appear:
·	in the LocalControl descriptor, if they are local interest only, or
·	in the Local and Remote descriptors, if they must be coordinated
between the local and remote Media Gateways.

Megaco/H.248 Annex C currently fails to indicate which alternative applies
to each of the properties specified within the Annex.  This contribution
argues that the H.248 Implementor's Guide should be updated to reflect such
an assignment.  The contribution goes on to derive principles for making the
assignment decision, and then applies those principles to derive a detailed
set of  descriptor assignments for all of the properties in the Annex.

 

NEED FOR A STANDARDIZED PROPERTY ASSIGNMENT

This section presents a semantic and a syntactic argument for standardizing
the assignment of properties to descriptors in Annex C.  At the semantic
level, it is essential that the assignment to descriptors be the same for a
given property, regardless of the H.248 protocol encoding.  Otherwise one
encounters a semantic mismatch between encodings, such that with respect to
a given property asymmetric flow descriptions are possible in one encoding
and not the other.  Such a mismatch may be introduced by general usage or by
explicit adoption of Annex C properties in standards created by bodies other
than the IETF Megaco Working Group or Study Group 16.

At the syntactic level, assignment of specific properties to specific
descriptors simplifies parser construction by adding predictability to
message construction.
A final argument in favour of adding explicit descriptor assignments is that
Annex C, as "Package 0", should conform as much as possible to the
documentation rules for packages.  This includes documentation of the
descriptor to which each property should be assigned.

ASSIGNMENT PRINCIPLES
 
The basic criterion for descriptor assignment was indicated in the
introduction: whether or not the property concerned must be coordinated with
the remote Media Gateway.
However, some borderline cases will require the use of subsidiary criteria.
The first such criterion was suggested in the previous section: assurance
that the assignment is the same for both text and binary (Annex C)
encodings.  Because the text encoding for the Local and Remote descriptors
is tied to SDP (RFC 2327), this means that at the very least the mandatory
properties found in RFC 2327 should  be assigned to the Local and Remote
descriptors rather than LocalControl.  Properties which are optional in SDP
may be placed in LocalControl if this makes sense, but the assignment must
be the same in both the text and the binary encodings.

There is a further possible criterion: is there a potential requirement  for
a given property to have a different value for each direction of flow, and
will it be technically feasible to meet that requirement?  If so, the
property should be assigned to Local/Remote rather than LocalControl.

DETAILED ASSIGNMENTS

The following table proposes detailed assignments for the Annex C
properties.  The "Remarks" column indicates criteria used where the
assignment was not immediately obvious.

[Rather than repeat the tables, let me summarize by saying that almost
everything goes into Local/Remote.  Here are the exceptional cases:

Table C.1: Transmission mode (tag 1002) should perhaps be deprecated because
the Mode property in LocalControl carries the same information.  This is
equivalent to saying that the SDP in Local and Remote should not include any
of the directionality attributes.  People may want to comment.

Table C.1: Gain (tag 100C) and Jitterbuff (tag 100D) are placed in
LocalControl (of local interest only)

Table C.9: Modem (tag 901B) goes into the Modem Descriptor.  Actually it
should be deprecated because the necessary codepoints have already been
defined in the Modem descriptor.

Table C.9: DialledN (tag 901F) and DiallingN (tag 9020) go into LocalControl
because they do not require end-to-end coordination at the media level.]

Tom Taylor
Multimedia Control and Applications Standards
Ph.  +1 613 736 0961
taylor@nortelnetworks.com 


From owner-megaco@fore.com  Thu May 10 20:36:59 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10719
	for ; Thu, 10 May 2001 20:36:59 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA01611;
	Thu, 10 May 2001 20:29:56 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA13843
	for megaco-list; Thu, 10 May 2001 20:27:53 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA13839
	for ; Thu, 10 May 2001 20:27:52 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA01413
	for ; Thu, 10 May 2001 20:27:48 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4B0RjdQ003167
	for ; Thu, 10 May 2001 19:27:45 -0500 (CDT)
From: "Paul Long" 
To: "megaco" 
Subject: RE: From whence they came?
Date: Thu, 10 May 2001 19:27:47 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0006_01C0D987.4B8FC6E0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <28560036253BD41191A10000F8BCBD110250CB0C@zcard00g.ca.nortel.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01C0D987.4B8FC6E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: From whence they came?Tom,

Hmmm... Taking a closer look at the spec, I see that the mID in the message
prolog is just used by the receiver as a logical identifier for the sender
and that, in particular, the IP-address forms just have syntactical
value--they are never used as IP addresses, per se. It looks like these mIDs
are only used when paired up with transaction identifiers to uniquely
identify transactions, scoped to the receiver. Is this correct? Scary
thought, but, as long as the sender takes care by using an IP address that
another sender will not use, it appears that the IP address in a message mID
doesn't have to have any relationship to the actual network interface of the
sender. Am I right?

Paul Long
ipDialog, Inc.
  -----Original Message-----
  From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
  Sent: Thursday, May 10, 2001 5:56 PM
  To: 'Paul Long'; megaco
  Subject: RE: From whence they came?


  It's partly the difference between a physical and a logical unit in a
load-sharing architecture where the separate units have different addresses.
There's also the possibility that a single physical unit has multiple
network interfaces.  Using the address as received in the header is
important because it gives a beter chnace of the response getting back
through any intervening firewall.
    -----Original Message-----
    From: Paul Long [mailto:plong@ipdialog.com]
    Sent: Thursday, May 10, 2001 5:40 PM
    To: megaco
    Subject: RE: From whence they came?


    Tom,

    Okay, then, and this may be a stupid question, but what is the
difference between "the peer in an association" and the source of a message?
IOW, under what circumstances might they be different? The reason I was
confused was probably because in H.323 the source of a message is of
absolutely no consequence.

    Paul Long
    ipDialog, Inc.

------=_NextPart_000_0006_01C0D987.4B8FC6E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


RE: From whence they came?




Tom,


 


Hmmm... Taking a closer look at the spec, I see that =
the mID in=20
the message prolog is just used by the receiver as a =
logical identifier for=20
the sender and that, in particular, the IP-address forms just have =
syntactical=20
value--they are never used as IP addresses, per se. It looks like these =
mIDs are=20
only used when paired up with transaction identifiers to uniquely =
identify=20
transactions, scoped to the receiver. Is this correct? Scary thought, =
but, as=20
long as the sender takes care by using an IP address that another =
sender=20
will not use, it appears that the IP address in a message mID =
doesn't have=20
to have any relationship to the actual network interface of the sender. =
Am I=20
right?


 


Paul=20
Long


ipDialog, Inc.



  
-----Original Message-----
From: Tom-PT Taylor=20
  [mailto:taylor@nortelnetworks.com]
Sent: Thursday, May 10, =
2001 5:56=20
  PM
To: 'Paul Long'; megaco
Subject: RE: From =
whence they=20
  came?


  
It's=20
  partly the difference between a physical and a logical unit in a =
load-sharing=20
  architecture where the separate units have different addresses.  =
There's=20
  also the possibility that a single physical unit has multiple network=20
  interfaces.  Using the address as received in the header is =
important=20
  because it gives a beter chnace of the response getting back through =
any=20
  intervening firewall.

  

    
-----Original Message-----
From: Paul Long=20
    [mailto:plong@ipdialog.com]
Sent: Thursday, May 10, 2001 =
5:40=20
    PM
To: megaco
Subject: RE: From whence they=20
    came?


    
Tom,

    
 

    
Okay, then, and this may be a stupid question, but what is =
the=20
    difference between "the peer in an association" and the source of a =
message?=20
    IOW, under what circumstances might they be different? The reason I =
was=20
    confused was probably because in H.323 the source of a =
message is=20
    of absolutely no consequence.

    
 

    
Paul Long

    
ipDialog,=20
Inc.


------=_NextPart_000_0006_01C0D987.4B8FC6E0--



From owner-megaco@fore.com  Thu May 10 21:24:39 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11216
	for ; Thu, 10 May 2001 21:24:39 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA04070;
	Thu, 10 May 2001 21:18:59 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA18270
	for megaco-list; Thu, 10 May 2001 21:16:06 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA18261
	for ; Thu, 10 May 2001 21:16:05 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA03843
	for ; Thu, 10 May 2001 21:15:58 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA07607;
	Fri, 11 May 2001 11:13:33 +1000 (EST)
Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA15475;
	Fri, 11 May 2001 11:13:31 +1000 (EST)
Message-ID: <3AFB3CB9.F9048DAF@ericsson.com>
Date: Fri, 11 May 2001 11:13:29 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kevin Boyle 
CC: Madhu Babu Brahmanapally ,
        "'Winter Johannes'" ,
        megaco , Tom-PT Taylor 
Subject: Re: Notifications
References: <007401c0d958$afc078f0$c500a8c0@MBRAHMANAPALLY> <3AFAA427.AD6A355E@americasm01.nt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello, 

As Kevin pointed out. This is covered in the IG 6.33.

Christian

Kevin Boyle wrote:
> 
> I believe that there is a note in the IG that states that Error descriptors can
> be returned where appropriate, but are not shown in the sample API.
> 
> Kevin
> 
> Madhu Babu Brahmanapally wrote:
> 
> > Hi All,
> >
> > When multiple commands are sent from MGC/MG, there can be error in any of
> > the commands. The return parameter shown in the command APIs (Section 7.2.1
> > to 7.2.8) doesn't have any error descriptor. I think [,ErrorDescriptor] can
> > be part of the descriptors listed as return parameters of each command.
> >
> > Regards
> > Madhubabu
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Winter Johannes
> > Sent: Thursday, May 10, 2001 8:19 AM
> > To: megaco@fore.com
> > Subject: Notifications
> >
> > Hi List,
> >
> > I have a short question about notifications sent from the MG to the MGC:
> >
> > The communication between MGC and MG is always realized by the exchange of
> > Transaction Request messages (sent by the MGC) and Transaction Reply
> > messages (sent by the MG).  The Transaction messages include the
> > corresponding Command Requests and Replys.
> >
> > Is this the same for notifications sent by the MG to the MGC?
> > So, does the MG set up a Transaction request (including a NotifyRequest,
> > Annex A)  with a Transaction ID and receive a corresponding Transaction
> > reply (with a NotifyReply, optional an empty SEQUENCE) from the MGC?
> >
> > If this is true, should section 7.2.7 not changed to:
> >
> > ...
> > [TerminationID]
> > [,ErrorDescriptor]
> >         Notify (TerminationID,
> >                 ObservedEventsDescriptor,
> >                 [ErrorDescriptor])
> > ...
> >
> > regards
> >
> > Johannes Winter
> > Siemens AG Austria


From owner-megaco@fore.com  Thu May 10 21:30:23 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11293
	for ; Thu, 10 May 2001 21:30:23 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA04489;
	Thu, 10 May 2001 21:24:39 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA18999
	for megaco-list; Thu, 10 May 2001 21:22:43 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA18995
	for ; Thu, 10 May 2001 21:22:41 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA04331
	for ; Thu, 10 May 2001 21:22:35 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA08738;
	Fri, 11 May 2001 11:21:15 +1000 (EST)
Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA17607;
	Fri, 11 May 2001 11:21:15 +1000 (EST)
Message-ID: <3AFB3E89.F97EF7A4@ericsson.com>
Date: Fri, 11 May 2001 11:21:13 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom-PT Taylor 
CC: "'Troy Cauble'" , megaco@fore.com
Subject: Re: Implementors' Guide Update Editor's last Call Section 6.58 [F INAL]
References: <28560036253BD41191A10000F8BCBD110250CB0D@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day Tom,

Just to clarify - the consensus is to remove the text regarding 7.2.8
from 6.58 TimeStamp in registration replies?

Cheers, Christian

Tom-PT Taylor wrote:
> 
> Let's call that a consensus.
> 
> > -----Original Message-----
> > From: Troy Cauble [mailto:troy@lucent.com]
> > Sent: Thursday, May 10, 2001 6:58 PM
> > To: megaco@fore.com
> > Subject: Re: Implementors' Guide Update Editor's last Call
> > Section 6.58
> >
> >
> >
> > I strongly agree.  There is no need synchronize
> > the MG and MGC's sense of time.
> >
> > -troy
> >
> >
> > Al Varney wrote:
> > >
> > > At 11:07 05/10/2001 -0500, Paul Long wrote:
> > >
> > > >Maybe this should be rethought. Personally, I think the IG
> > should just
> > > >repair the ASN.1 and ABNF syntax and leave the semantics
> > alone in section
> > > >7.2.8.
> > >
> > >     I agree that having the "current" MGC force a time-base
> > change at the
> > > MG (as a requirement) should be rethought.  Do we really
> > want to preclude
> > > an MC operating with multiple MGCs (with differing ideas
> > about time)? -- I
> > > thought 3GPP was looking at just such a mechanism (at a
> > somewhat higher
> > > level, but "based on" H.248.  BICC is supporting the idea
> > of multiple nodes
> > > controlling a BIWF -- and that interface is "based on H.248".
> > >
> > >     Should an MG give a (new) MGC that kind of control?  A
> > trunking MG?  An
> > > announcement MG?
> > >
> > >     I don't see any advantage in REQUIRING the MG to
> > change/synchronize
> > > with the current MGC.  An MG without access to another time
> > server, and
> > > with no recent contact with an MGC, might wish to re-set its
> > > time-base.  But why not allow the MG to decide.
> > >
> > >     So far as I can tell, NOTHING BREAKS if the MG retains
> > its own local
> > > time base forever --- regardless of how far off it might be
> > from "world time".
> > >
> > > Just my opinion,
> > >
> > > Al Varney - Lucent Technologies  +1 630 224-7493
> > varney@lucent.com
> >


From owner-megaco@fore.com  Thu May 10 21:33:57 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11591
	for ; Thu, 10 May 2001 21:33:57 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA04658;
	Thu, 10 May 2001 21:25:30 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA19067
	for megaco-list; Thu, 10 May 2001 21:23:18 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA19062
	for ; Thu, 10 May 2001 21:23:16 -0400 (EDT)
Received: from rumor.cps.intel.com (rumor.cps.intel.com [192.102.198.242])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA04353
	for ; Thu, 10 May 2001 21:23:12 -0400 (EDT)
Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205])
	by rumor.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.38 2001/05/09 12:49:45 root Exp $) with SMTP id BAA19417;
	Fri, 11 May 2001 01:23:04 GMT
Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 11 May 2001 01:23:07 0000 (GMT)
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 10 May 2001 18:23:06 -0700
Message-ID: 
From: "Kaul, Bharat" 
To: "'Paul Long'" , megaco 
Subject: RE: From whence they came?
Date: Thu, 10 May 2001 18:23:05 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0D9B8.EE04DD80"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0D9B8.EE04DD80
Content-Type: text/plain;
	charset="iso-8859-1"

Yes Paul, that is the intention. 
 
Besides MID can syntactically be defined as domain name also. In that case,
you still need to send it to the source transport address. Conceptually, in
such a case MID again becomes a logical identifier only. So, there shouldn't
be any issues.
 
- Bharat

-----Original Message-----
From: Paul Long [mailto:plong@ipdialog.com]
Sent: Thursday, May 10, 2001 5:28 PM
To: megaco
Subject: RE: From whence they came?


Tom,
 
Hmmm... Taking a closer look at the spec, I see that the mID in the message
prolog is just used by the receiver as a logical identifier for the sender
and that, in particular, the IP-address forms just have syntactical
value--they are never used as IP addresses, per se. It looks like these mIDs
are only used when paired up with transaction identifiers to uniquely
identify transactions, scoped to the receiver. Is this correct? Scary
thought, but, as long as the sender takes care by using an IP address that
another sender will not use, it appears that the IP address in a message mID
doesn't have to have any relationship to the actual network interface of the
sender. Am I right?
 
Paul Long
ipDialog, Inc.

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Thursday, May 10, 2001 5:56 PM
To: 'Paul Long'; megaco
Subject: RE: From whence they came?


It's partly the difference between a physical and a logical unit in a
load-sharing architecture where the separate units have different addresses.
There's also the possibility that a single physical unit has multiple
network interfaces.  Using the address as received in the header is
important because it gives a beter chnace of the response getting back
through any intervening firewall.

-----Original Message-----
From: Paul Long [mailto:plong@ipdialog.com]
Sent: Thursday, May 10, 2001 5:40 PM
To: megaco
Subject: RE: From whence they came?


Tom,
 
Okay, then, and this may be a stupid question, but what is the difference
between "the peer in an association" and the source of a message? IOW, under
what circumstances might they be different? The reason I was confused was
probably because in H.323 the source of a message is of absolutely no
consequence.
 
Paul Long
ipDialog, Inc.


------_=_NextPart_001_01C0D9B8.EE04DD80
Content-Type: text/html;
	charset="iso-8859-1"




RE: From whence they came?




Yes 
Paul, that is the intention. 


 


Besides MID can syntactically be defined as domain name 
also. In that case, you still need to send it to the source transport address. 
Conceptually, in such a case MID again becomes a logical identifier only. So, 
there shouldn't be any issues.


 


- 
Bharat



  
-----Original Message-----
From: Paul Long 
  [mailto:plong@ipdialog.com]
Sent: Thursday, May 10, 2001 5:28 
  PM
To: megaco
Subject: RE: From whence they 
  came?


  
Tom,

  
 

  
Hmmm... Taking a closer look at the spec, I see that the mID 
  in the message prolog is just used by the receiver as a 
  logical identifier for the sender and that, in particular, the IP-address 
  forms just have syntactical value--they are never used as IP addresses, per 
  se. It looks like these mIDs are only used when paired up with transaction 
  identifiers to uniquely identify transactions, scoped to the receiver. Is this 
  correct? Scary thought, but, as long as the sender takes care by using an 
  IP address that another sender will not use, it appears that the IP address in 
  a message mID doesn't have to have any relationship to the actual network 
  interface of the sender. Am I right?

  
 

  
Paul 
  Long

  
ipDialog, Inc.

  

    
-----Original Message-----
From: Tom-PT Taylor 
    [mailto:taylor@nortelnetworks.com]
Sent: Thursday, May 10, 2001 
    5:56 PM
To: 'Paul Long'; megaco
Subject: RE: From whence 
    they came?


    
It's partly the difference between a physical and a 
    logical unit in a load-sharing architecture where the separate units have 
    different addresses.  There's also the possibility that a single 
    physical unit has multiple network interfaces.  Using the address as 
    received in the header is important because it gives a beter chnace of the 
    response getting back through any intervening firewall.

    

      
-----Original Message-----
From: Paul Long 
      [mailto:plong@ipdialog.com]
Sent: Thursday, May 10, 2001 5:40 
      PM
To: megaco
Subject: RE: From whence they 
      came?


      
Tom,

      
 

      
Okay, then, and this may be a stupid question, but what is the 
      difference between "the peer in an association" and the source of a 
      message? IOW, under what circumstances might they be different? The reason 
      I was confused was probably because in H.323 the source of a 
      message is of absolutely no consequence.

      
 

      
Paul Long

      
ipDialog, 
Inc.


------_=_NextPart_001_01C0D9B8.EE04DD80--



From owner-megaco@fore.com  Thu May 10 23:28:44 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14758
	for ; Thu, 10 May 2001 23:28:44 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA10832;
	Thu, 10 May 2001 23:22:57 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA29133
	for megaco-list; Thu, 10 May 2001 23:19:22 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA29121
	for ; Thu, 10 May 2001 23:19:20 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA10289
	for ; Thu, 10 May 2001 23:19:14 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA20878;
	Fri, 11 May 2001 13:17:54 +1000 (EST)
Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA00894;
	Fri, 11 May 2001 13:17:53 +1000 (EST)
Message-ID: <3AFB4EA6.643FA029@ericsson.com>
Date: Fri, 11 May 2001 12:29:58 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom-PT Taylor 
CC: megaco ietf 
Subject: Re: NITS Reviewer Wanted -- CAS Signalling draft
References: <28560036253BD41191A10000F8BCBD110250CAFF@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day Tom,

I had a quick scan through and there's a few nits from a H.248 point of
view. I can do one of the reviews but I probably won't be able to do a
detailed review for a week or so (we'll be at the same meeting). I think
before finally last calling this is may be warranted to send it to SG11
/ SG16 for comment to get nits on the technical content.

Cheers, Christian

Tom-PT Taylor wrote:
> 
> I did not exactly cover myself in glory when I forwarded the enhanced tones
> package to the IESG after our list Last Call -- there were a number of minor
> deficiencies which meant the draft had to be recycled a couple of times.  In
> preparation for list Last Call on draft-manyfolks-megaco-caspackage-00.txt,
> therefore, I would ask for one or two "nits" reviewers to go through and
> make sure everything is in good shape.
> 
> Tom Taylor
> Multimedia Control and Applications Standards
> Ph.  +1 613 736 0961
> taylor@nortelnetworks.com




From owner-megaco@fore.com  Thu May 10 23:28:48 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14768
	for ; Thu, 10 May 2001 23:28:48 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA10850;
	Thu, 10 May 2001 23:23:02 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA29134
	for megaco-list; Thu, 10 May 2001 23:19:23 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA29125
	for ; Thu, 10 May 2001 23:19:21 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA10296
	for ; Thu, 10 May 2001 23:19:15 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA20882;
	Fri, 11 May 2001 13:17:55 +1000 (EST)
Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA00900;
	Fri, 11 May 2001 13:17:54 +1000 (EST)
Message-ID: <3AFB5011.78D7BDA7@ericsson.com>
Date: Fri, 11 May 2001 12:36:01 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Long 
CC: MEGACO list 
Subject: Re: empty quotedString ?
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day,

I'll add the proposed change to 6.55 of the IG.

Cheers, Christian

Paul Long wrote:
> 
> Troy,
> 
> Sounds reasonable to me, especially considering that the ASN.1 allows the
> equivalent of an empty string.
> 
> Paul Long
> ipDialog, Inc.
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Troy Cauble
> Sent: Thursday, May 10, 2001 4:10 PM
> To: MEGACO list
> Subject: empty quotedString ?
> 
> Greetings,
> 
> Can we change
> 
>    quotedString         = DQUOTE 1*(SafeChar / RestChar/ WSP) DQUOTE
> 
> to
> 
>    quotedString         = DQUOTE  *(SafeChar / RestChar/ WSP) DQUOTE
> 
> ?
> 
> In general, I think it's pretty reasonable.
> And specifically, section E.6.2 says under parameter "ds",
> "string of digit map symbols (possibly empty) returned as
> a quoted string".
> 
> -troy




From owner-megaco@fore.com  Thu May 10 23:30:11 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14847
	for ; Thu, 10 May 2001 23:30:11 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA10855;
	Thu, 10 May 2001 23:23:03 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA29128
	for megaco-list; Thu, 10 May 2001 23:19:22 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA29117
	for ; Thu, 10 May 2001 23:19:18 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA10285
	for ; Thu, 10 May 2001 23:19:12 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA20874;
	Fri, 11 May 2001 13:17:53 +1000 (EST)
Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA00883;
	Fri, 11 May 2001 13:17:52 +1000 (EST)
Message-ID: <3AFB47AD.310F4078@ericsson.com>
Date: Fri, 11 May 2001 12:00:13 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Long 
CC: megaco ietf 
Subject: Re: Implementors' Guide Update Editor's last Call
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day Paul,

These additions look OK to me with the following comments:
ALF not defined:
The note you propose should be in D.1 I've also modified the text:
"ALF is a set of techniques that allow an application, as opposed to a
stack, to affect how messages are sent to the other side. A typical ALF
technique is to allow an application to change the order of messages
sent when there is a queue AFTER it has queued them.  There is no formal
specification for ALF. The procedures in Annex D.1 define ALF behaviour
for the H.248 protocol."

Source Address:
Added a "For example" at the front of the changed line. Section 9 we've
tried to keep as transport independent as possible.

TimeStamp in registration request and reply:
I've added this to the existing 6.58 correction.

Error Descriptor location:
I've added this to the existing 6.33 correction.

Cheers, Christian



Paul Long wrote:
> 
> Christian,
> 
> I've got a few more additions. Is it too late? These are mostly just a
> summary of the things I've had resolved recently on the reflector. Here are
> HTML and Word pages of the same content. (The HTML page doesn't render too
> well using Netscape. I guess because it was generated by Word. :-)
> 
> http://www.packetizer.com/people/plong/IGContribs.htm
> http://www.packetizer.com/people/plong/IGContribs.doc
> 
> Paul Long
> ipDialog, Inc.
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Christian Groves
> Sent: Wednesday, May 09, 2001 12:40 AM
> To: megaco ietf
> Cc: Tom-PT Taylor; Glen Freundlich
> Subject: Implementors' Guide Update Editor's last Call
> 
> G'Day all,
> 
> The H.248 Series Implementors' Guide has been updated to revision 6.
> 
> It can be found at:
> ftp://standard.pictel.com/avc-site/Incoming/
> files:
> TD-xxx_H248_Implementors_Additions_v6.doc
> TD-xxx_H248_Implementors_Additions_v6.pdf
> 
> This revision contains the Approved Implementors' Guide and the
> Implementors' Guide Additions v5 with some other changes. The changes
> are detailed in the document.
> 
> This is an editors' last call. Please provide comments on this draft by
> Monday the 13th as a revision 7 will be stored on the 14th and sent to
> SG16 for approval at the Porto Seguro meeting. If you have a comment on
> a correction please provide the detailed solution or exact changes that
> you would like to see.
> 
> Cheers, Christian




From owner-megaco@fore.com  Thu May 10 23:30:21 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14886
	for ; Thu, 10 May 2001 23:30:21 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA10895;
	Thu, 10 May 2001 23:23:11 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA29168
	for megaco-list; Thu, 10 May 2001 23:19:37 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA29154
	for ; Thu, 10 May 2001 23:19:31 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA10315
	for ; Thu, 10 May 2001 23:19:26 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA20889;
	Fri, 11 May 2001 13:18:01 +1000 (EST)
Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA00908;
	Fri, 11 May 2001 13:17:56 +1000 (EST)
Message-ID: <3AFB568D.FB11ADC1@ericsson.com>
Date: Fri, 11 May 2001 13:03:41 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Chuong Nguyen 
CC: megaco@fore.com
Subject: Re: Implementors' Guide Update Editor's last Call Section 6.58
References: <3AF8D832.E727C159@ericsson.com> <3AF9C27D.99FD20CD@usa.alcatel.com> <3AF9F936.F7DF2B63@ericsson.com> <3AFA9836.159BA1F2@usa.alcatel.com>
Content-Type: text/plain; charset=iso-8859-1
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id XAA10895
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA14886

G'Day Chuong,

Your problem has been fixed with the removal of update to the 7.2.8
text.

Cheers, Christian

Chuong Nguyen wrote:
> 
> See comments below:
> 
> Christian Groves wrote:
> 
> > G'Day Chuong,
> >
> > Please see my comments below.
> >
> > Cheers, Christian
> >
> > Chuong Nguyen wrote:
> > >
> > > Christian
> > >
> > > 6.58 TimeStamp in registration replies
> > > · If the Timestamp is not sent by either the MG or the MGC, both
> > sides
> > > shall keep their original time base.
> > >
> > > Does this now imply that TimeStamp is not required in
> > ServiceChange
> > > registration?
> >
> > [CHG] No I don't believe it does. The start of this paragraph has
> > always
> > stated "The optional Timestamp...." so there is no change.
> >
> > >
> > > Megaco Text
> > > The TimeStamp parameter shall be sent with a registration command
> > and
> > > its response.
> > >
> 
>   What about the above sentence quoted from Section 7.2.8 in the
> paragraph where
>                registration is described.  The use of the word "shall"
> implies "required" to me.
> 
>               The paragraph where the word "optional" was used - to me
> it meant that not
>               all ServiceChange Method requires TimeStamp.  Then
> follow by the "registration"
>               paragraph which describes how registration is done which
> states that TimeStamp
>               is required for registration.
> 
>              But the change in the IG implies that TimeStamp is not
> required in "registration"
>              And that is all I am trying to point out.
> 
> Thanks
> Chuong
> 
> --
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
> 
>



From owner-megaco@fore.com  Thu May 10 23:30:44 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14974
	for ; Thu, 10 May 2001 23:30:44 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA10994;
	Thu, 10 May 2001 23:23:39 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA29247
	for megaco-list; Thu, 10 May 2001 23:20:10 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA29237
	for ; Thu, 10 May 2001 23:20:08 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA10346
	for ; Thu, 10 May 2001 23:20:02 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA20886;
	Fri, 11 May 2001 13:17:56 +1000 (EST)
Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA00904;
	Fri, 11 May 2001 13:17:55 +1000 (EST)
Message-ID: <3AFB519F.D5407CE5@ericsson.com>
Date: Fri, 11 May 2001 12:42:39 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Long 
CC: megaco ietf , bharat@trillium.com
Subject: Re: Implementors' Guide Update Editor's last Call
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day Paul,

Please my comments below.

Cheers, Christian

Paul Long wrote:
> 
> Christian,
> 
> My comments:
> 
> Item 6.16: Concatenation (e.g., A B) already takes precedence over the
> alternative operator (e.g., A / B), so the proposed parentheses are
> redundant. (See 3.10/RFC2234.) I guess it doesn't hurt to add them, but this
> is technically a clarification and not a correction so it should go in
> section 7.

[CHG] Its not a clarification as it changes the syntax. As it was
already approved in the first IG I do not particular want to change it
was its not broken.

> 
> Item 6.58: Inserting the text, "For UDP as a transport," precludes an MG
> that uses TCP from also using ServiceChangeAddress. Not that _I_ want to do
> such a thing, but is this a necessary constraint? Was this intended?

[CHG] Bharat asked this to be added so he can answer you on this. I'm
quite happy to remove the "UDP as a transport" because I don't like
trying H.248/Megaco procedures to transports.

> 
> Item 11.6: I know this is only clarifying text, but you should probably
> change "Parsers should accept whitespace..." to "Parsers shall accept
> whitespace..."
[CHG] Any complaints from ABNF gurus on this? Tom what's your call?

> 
> Paul Long
> ipDialog, Inc.
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Christian Groves
> Sent: Wednesday, May 09, 2001 12:40 AM
> To: megaco ietf
> Cc: Tom-PT Taylor; Glen Freundlich
> Subject: Implementors' Guide Update Editor's last Call
> 
> G'Day all,
> 
> The H.248 Series Implementors' Guide has been updated to revision 6.
> 
> It can be found at:
> ftp://standard.pictel.com/avc-site/Incoming/
> files:
> TD-xxx_H248_Implementors_Additions_v6.doc
> TD-xxx_H248_Implementors_Additions_v6.pdf
> 
> This revision contains the Approved Implementors' Guide and the
> Implementors' Guide Additions v5 with some other changes. The changes
> are detailed in the document.
> 
> This is an editors' last call. Please provide comments on this draft by
> Monday the 13th as a revision 7 will be stored on the 14th and sent to
> SG16 for approval at the Porto Seguro meeting. If you have a comment on
> a correction please provide the detailed solution or exact changes that
> you would like to see.
> 
> Cheers, Christian




From owner-megaco@fore.com  Fri May 11 01:10:01 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17064
	for ; Fri, 11 May 2001 01:10:00 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA17849;
	Fri, 11 May 2001 01:04:22 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA10292
	for megaco-list; Fri, 11 May 2001 01:01:59 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA10286
	for ; Fri, 11 May 2001 01:01:57 -0400 (EDT)
From: bestrates3@turbomail.net
Received: from gy.scgwjt.com ([61.139.58.72])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA17734
	for ; Fri, 11 May 2001 01:01:51 -0400 (EDT)
Received: from www.turbomail.net (slip-32-101-129-233.mn.us.prserv.net [32.101.129.233]) by gy.scgwjt.com (8.8.5/SCO5) with SMTP id NAA18127 for ; Fri, 11 May 2001 13:02:17 -0400 (EDT)
To: 
Date: Fri, 11 May 2001 03:31:31
Message-Id: <342.675335.877647@www.turbomail.net>
Subject: Free Insurace Quote - Best Rates Possible!
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Best Life Insurance, Lowest Cost!
Shop, Compare and Save
Save up to 70% on your current term life insurance

1  Answer a few questions
2  Receive the 15 lowest quotes
3  Choose a policy and apply online
 
http://www.websurfking.net/quote

You'll have 15 custom quotes from the nation's
top insurance companies in less than 1 minute!

It's fast, easy and FREE
Click Here to Compare Rates!

http://www.websurfking.net/quote

To be removed from our mailing please visit
http://www.websurfking.net/quote/remove.html
 
 
 
 
 
 
 
 
 
 
 
 
 


From owner-megaco@fore.com  Fri May 11 03:23:51 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01733
	for ; Fri, 11 May 2001 03:23:51 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA23853;
	Fri, 11 May 2001 03:16:49 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id DAA22538
	for megaco-list; Fri, 11 May 2001 03:13:51 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA22534
	for ; Fri, 11 May 2001 03:13:50 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA23709
	for ; Fri, 11 May 2001 03:13:45 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4B7Dlu26491
	for ; Fri, 11 May 2001 03:13:47 -0400 (EDT)
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by hoemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4B7Dkk26474
	for ; Fri, 11 May 2001 03:13:47 -0400 (EDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 11 May 2001 09:13:45 +0200
Message-ID: 
From: "Bemmel, Jeroen van (Jeroen)" 
To: "'Tom-PT Taylor'" ,
        "'megaco'"
	 
Subject: RE: Annex C Descriptor Assignments
Date: Fri, 11 May 2001 09:13:45 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

That is what I had in mind too. But isn't it cumbersome to have such a large
'package 0'?
Is it likely for a Media Gateway to support all those properties?

I would suggest to split the attributes in Annex C over multiple packages,
eg put IPaddress/port in the RTP package (or perhaps some other newly
defined package), ATM related properties in another package, etc


From owner-megaco@fore.com  Fri May 11 05:31:03 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02904
	for ; Fri, 11 May 2001 05:31:03 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA00448;
	Fri, 11 May 2001 05:24:57 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA05192
	for megaco-list; Fri, 11 May 2001 05:22:10 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA05188
	for ; Fri, 11 May 2001 05:22:08 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA00322
	for ; Fri, 11 May 2001 05:22:05 -0400 (EDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4B9M5N17925
	for ; Fri, 11 May 2001 11:22:05 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri May 11 11:21:53 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 11 May 2001 11:16:58 +0200
Message-ID: <795A014AF92DD21182AF0008C7A404320B0703A6@esealnt117>
From: "Alf Heidermark (UAB)" 
To: "'Madhu Babu Brahmanapally'" ,
        "Alf Heidermark (UAB)" ,
        "'Krishna Gundamaraju'" ,
        "'Tom-PT Taylor'"
	 ,
        "'Christian Groves'"
	 
Cc: "'megaco'" 
Subject: RE: Error Code 505
Date: Fri, 11 May 2001 11:21:45 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

In my understanding there are some situations where you cannot say anything about the provisioned termination states. An example in disconnected where I assume you keep the termination states and does not default them. I still think you have to take case by case as done in Annex l.
-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: den 10 maj 2001 17:14
To: 'Alf Heidermark (UAB)'; 'Krishna Gundamaraju'; 'Tom-PT Taylor';
'Christian Groves'
Cc: 'megaco'
Subject: RE: Error Code 505


Hi All,
In the protocol, there should be a mention that if ServiceChange for ROOT is
received from MG, it is implied(or not implied) that all the terminations
that are provisioned at both MG and MGC  are inservice(or out-of-service).
"I think this particular statement is missing in the protocol."

IMHO the MG need not send further InService messages for each termination,
as the ROOT ServiceChange should imply this.  But for any new terminations
that are not provisioned the MG has to specifically send ServiceChange with
"in-service".

Regards
Madhubabu

-----Original Message-----
From: Alf Heidermark (UAB) [mailto:Alf.Heidermark@uab.ericsson.se]
Sent: Thursday, May 10, 2001 10:46 AM
To: 'Krishna Gundamaraju'; Tom-PT Taylor; 'Madhu Babu Brahmanapally';
'Christian Groves'
Cc: megaco
Subject: RE: Error Code 505


Hello

If you look in the proposed Annex L you can find for different service
change reason what the state of each concened terminastions is.

-----Original Message-----
From: Krishna Gundamaraju [mailto:krishna.gundamaraju@kenetec.com]
Sent: den 10 maj 2001 16:38
To: Tom-PT Taylor; 'Madhu Babu Brahmanapally'; 'Christian Groves'
Cc: megaco
Subject: Re: Error Code 505


Hi All,

    All along we were thinking that the ROOT ServiceChange implies that all
the provisioned terminations are inservice. The Protocol should clearly
state what is the correct behavior as otherwise there could be very serious
interoperability issues.

Regards,
Krishna G

----- Original Message -----
From: Tom-PT Taylor 
To: 'Madhu   Babu Brahmanapally' ; 'Christian
Groves' 
Cc: megaco 
Sent: Thursday, May 10, 2001 10:06 AM
Subject: RE: Error Code 505


Sorry, I took the usage with respect to ROOT as a given.  I and Christian (I
believe) were talking about the hypothesis that after ROOT comes up,
individual terminations are out of service until they, too, have been
signalled in-service through a ServiceChange exchange.  As your message
shows and mine was meant to point out, this is not the behaviour people are
currently assuming.  Of course, maybe I misunderstood Christian in the first
place.

-----Original Message-----
From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com
 ]
Sent: Thursday, May 10, 2001 9:47 AM
To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Christian Groves'
Cc: megaco
Subject: RE: Error Code 505


Hi Tom,
Why is this valid only for ATM? The general assumption is that as soon as
the ROOT ServiceChange is complete, all the terminations (irrespective of
type) provisioned at both MG and MGC are in-service. Unless followed by any
ServiceChange for those terminations whose state is out-of-service.


Regards
Madhubabu

-----Original Message-----
From: Tom-PT Taylor [ mailto:taylor@nortelnetworks.com
 ]
Sent: Thursday, May 10, 2001 12:58 AM
To: 'Christian Groves'
Cc: Madhu Babu Brahmanapally; megaco@fore.com
Subject: RE: Error Code 505


Let me put the opposite question: has anyone up to now thought that
terminations are only in service after a ServiceChange announcing their
presence?  I think I can see a possible use for such a convention with ATM,
but I don't see it applying to any other type of termination.

> -----Original Message-----
> From: Christian Groves [ mailto:Christian.Groves@ericsson.com
 ]
> Sent: Thursday, May 10, 2001 12:42 AM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]
> Cc: Madhu Babu Brahmanapally; megaco@fore.com
> Subject: Re: Error Code 505
>
>
> You lost me on the first sentence of your reply. Why can't
> ServiceChange
> bring up a range of termination for the first time? I don't see any
> overriding reason that this must only apply to ROOT.
>
> Christian
>
> Tom-PT Taylor wrote:
> >
> > All we're talking about is response to a ServiceChange here -- not a
> > subsequent ServiceChange indicating a reversion to the previous
> > state.  I would suggest that 505 should apply only to
> ServiceChange on
> > ROOT, not because I have an immediate counter-example for the
> > alternative, but because it feels like it would be easy to
> construct a
> > counter-example.
> >
> > > -----Original Message-----
> > > From: Christian Groves [ mailto:Christian.Groves@ericsson.com
 ]
> > > Sent: Wednesday, May 09, 2001 10:22 PM
> > > To: Madhu Babu Brahmanapally
> > > Cc: megaco@fore.com
> > > Subject: Re: Error Code 505
> > >
> > >
> > > I'd say this is valid also for terminations than root. A
> > servicechange
> > > can be applied to individual terminations and this error
> code is to
> > > guard trying to change termination characteristics before
> they have
> > > restarted.
> > >
> > > Christian
> > >
> > > Madhu Babu Brahmanapally wrote:
> > > >
> > > > HI All,
> > > >
> > > > The Error code 505 description is "Transaction Request
> > > Received before a
> > > > ServiceChange Reply has been received", does the
> > > ServiceChange reply here
> > > > mean the ServiceChange reply on ROOT termination? or is
> > > this valid for other
> > > > terminations also. I think the intention is here is
> > > ServiceChange for ROOT
> > > > termination. Comments??
> > > >
> > > > Regards
> > > > Madhubabu
> > >
>


From owner-megaco@fore.com  Fri May 11 08:32:08 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06299
	for ; Fri, 11 May 2001 08:32:08 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA08564;
	Fri, 11 May 2001 08:25:06 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA26511
	for megaco-list; Fri, 11 May 2001 08:22:10 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA26502
	for ; Fri, 11 May 2001 08:22:08 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id IAA08249
	for ; Fri, 11 May 2001 08:22:05 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id IAA21542; Fri, 11 May 2001 08:22:01 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Fri, 11 May 2001 08:21:40 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 11 May 2001 08:21:41 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB11@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Bemmel, Jeroen van (Jeroen)'" ,
        "'megaco'" 
Subject: RE: Annex C Descriptor Assignments
Date: Fri, 11 May 2001 08:21:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DA14.EE3DC300"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DA14.EE3DC300
Content-Type: text/plain;
	charset="ISO-8859-1"

This has been discussed.  The agreement is that an implementation can pick
and choose amongst the elements of Annex C that it supports.

The peculiar aspect of Annex C is that (as my submission indicates)
practically all of it must be realized on the text side as SDP extensions
rather than Megaco/H.248 packages.

> -----Original Message-----
> From: Bemmel, Jeroen van (Jeroen) [mailto:jbemmel@lucent.com]
> Sent: Friday, May 11, 2001 3:14 AM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'megaco'
> Subject: RE: Annex C Descriptor Assignments
> 
> 
> That is what I had in mind too. But isn't it cumbersome to 
> have such a large
> 'package 0'?
> Is it likely for a Media Gateway to support all those properties?
> 
> I would suggest to split the attributes in Annex C over 
> multiple packages,
> eg put IPaddress/port in the RTP package (or perhaps some other newly
> defined package), ATM related properties in another package, etc
> 

------_=_NextPart_001_01C0DA14.EE3DC300
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Annex C Descriptor Assignments




This has been discussed.  The agreement is that =
an implementation can pick and choose amongst the elements of Annex C =
that it supports.



The peculiar aspect of Annex C is that (as my =
submission indicates) practically all of it must be realized on the =
text side as SDP extensions rather than Megaco/H.248 =
packages.



> -----Original Message-----

> From: Bemmel, Jeroen van (Jeroen) [mailto:jbemmel@lucent.com]=


> Sent: Friday, May 11, 2001 3:14 AM

> To: Taylor, Tom-PT [NORSE:B881:EXCH]; =
'megaco'

> Subject: RE: Annex C Descriptor =
Assignments

> 

> 

> That is what I had in mind too. But isn't it =
cumbersome to 

> have such a large

> 'package 0'?

> Is it likely for a Media Gateway to support all =
those properties?

> 

> I would suggest to split the attributes in =
Annex C over 

> multiple packages,

> eg put IPaddress/port in the RTP package (or =
perhaps some other newly

> defined package), ATM related properties in =
another package, etc

> 





------_=_NextPart_001_01C0DA14.EE3DC300--


From owner-megaco@fore.com  Fri May 11 08:53:01 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07113
	for ; Fri, 11 May 2001 08:53:00 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA10457;
	Fri, 11 May 2001 08:45:54 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA00925
	for megaco-list; Fri, 11 May 2001 08:43:34 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA00912
	for ; Fri, 11 May 2001 08:43:32 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id IAA10158
	for ; Fri, 11 May 2001 08:43:29 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id IAA23719; Fri, 11 May 2001 08:43:26 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 11 May 2001 08:43:12 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 11 May 2001 08:43:15 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB13@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Paul Long'" , megaco 
Subject: RE: From whence they came?
Date: Fri, 11 May 2001 08:43:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DA17.F1DC3F20"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DA17.F1DC3F20
Content-Type: text/plain;
	charset="ISO-8859-1"

Basically, yes.  It's probably better to use a domain name rather than an
address as an mID tag.

-----Original Message-----
From: Paul Long [mailto:plong@ipdialog.com]
Sent: Thursday, May 10, 2001 8:28 PM
To: megaco
Subject: RE: From whence they came?


Tom,
 
Hmmm... Taking a closer look at the spec, I see that the mID in the message
prolog is just used by the receiver as a logical identifier for the sender
and that, in particular, the IP-address forms just have syntactical
value--they are never used as IP addresses, per se. It looks like these mIDs
are only used when paired up with transaction identifiers to uniquely
identify transactions, scoped to the receiver. Is this correct? Scary
thought, but, as long as the sender takes care by using an IP address that
another sender will not use, it appears that the IP address in a message mID
doesn't have to have any relationship to the actual network interface of the
sender. Am I right?
 
Paul Long
ipDialog, Inc.

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Thursday, May 10, 2001 5:56 PM
To: 'Paul Long'; megaco
Subject: RE: From whence they came?


It's partly the difference between a physical and a logical unit in a
load-sharing architecture where the separate units have different addresses.
There's also the possibility that a single physical unit has multiple
network interfaces.  Using the address as received in the header is
important because it gives a beter chnace of the response getting back
through any intervening firewall.

-----Original Message-----
From: Paul Long [mailto:plong@ipdialog.com]
Sent: Thursday, May 10, 2001 5:40 PM
To: megaco
Subject: RE: From whence they came?


Tom,
 
Okay, then, and this may be a stupid question, but what is the difference
between "the peer in an association" and the source of a message? IOW, under
what circumstances might they be different? The reason I was confused was
probably because in H.323 the source of a message is of absolutely no
consequence.
 
Paul Long
ipDialog, Inc.


------_=_NextPart_001_01C0DA17.F1DC3F20
Content-Type: text/html;
	charset="ISO-8859-1"




RE: From whence they came?




Basically, yes.  It's probably better to use a 
domain name rather than an address as an mID tag.



  
-----Original Message-----
From: Paul Long 
  [mailto:plong@ipdialog.com]
Sent: Thursday, May 10, 2001 8:28 
  PM
To: megaco
Subject: RE: From whence they 
  came?


  
Tom,

  
 

  
Hmmm... Taking a closer look at the spec, I see that the mID 
  in the message prolog is just used by the receiver as a 
  logical identifier for the sender and that, in particular, the IP-address 
  forms just have syntactical value--they are never used as IP addresses, per 
  se. It looks like these mIDs are only used when paired up with transaction 
  identifiers to uniquely identify transactions, scoped to the receiver. Is this 
  correct? Scary thought, but, as long as the sender takes care by using an 
  IP address that another sender will not use, it appears that the IP address in 
  a message mID doesn't have to have any relationship to the actual network 
  interface of the sender. Am I right?

  
 

  
Paul 
  Long

  
ipDialog, Inc.

  

    
-----Original Message-----
From: Tom-PT Taylor 
    [mailto:taylor@nortelnetworks.com]
Sent: Thursday, May 10, 2001 
    5:56 PM
To: 'Paul Long'; megaco
Subject: RE: From whence 
    they came?


    
It's partly the difference between a physical and a 
    logical unit in a load-sharing architecture where the separate units have 
    different addresses.  There's also the possibility that a single 
    physical unit has multiple network interfaces.  Using the address as 
    received in the header is important because it gives a beter chnace of the 
    response getting back through any intervening firewall.

    

      
-----Original Message-----
From: Paul Long 
      [mailto:plong@ipdialog.com]
Sent: Thursday, May 10, 2001 5:40 
      PM
To: megaco
Subject: RE: From whence they 
      came?


      
Tom,

      
 

      
Okay, then, and this may be a stupid question, but what is the 
      difference between "the peer in an association" and the source of a 
      message? IOW, under what circumstances might they be different? The reason 
      I was confused was probably because in H.323 the source of a 
      message is of absolutely no consequence.

      
 

      
Paul Long

      
ipDialog, 
Inc.


------_=_NextPart_001_01C0DA17.F1DC3F20--


From owner-megaco@fore.com  Fri May 11 09:46:15 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09356
	for ; Fri, 11 May 2001 09:46:14 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA15738;
	Fri, 11 May 2001 09:40:34 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA16256
	for megaco-list; Fri, 11 May 2001 09:37:42 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA16250
	for ; Fri, 11 May 2001 09:37:40 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA15371
	for ; Fri, 11 May 2001 09:37:36 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4BDbadQ000643
	for ; Fri, 11 May 2001 08:37:36 -0500 (CDT)
From: "Paul Long" 
To: 
Subject: RE: Implementors' Guide Update Editor's last Call Section 6.58 [F INAL]
Date: Fri, 11 May 2001 08:37:37 -0500
Message-ID: 
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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <3AFB3E89.F97EF7A4@ericsson.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Tom,

Correct, but leave the ASN.1 and ABNF syntax corrections.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Christian Groves
Sent: Thursday, May 10, 2001 8:21 PM
To: Tom-PT Taylor
Cc: 'Troy Cauble'; megaco@fore.com
Subject: Re: Implementors' Guide Update Editor's last Call Section 6.58
[F INAL]


G'Day Tom,

Just to clarify - the consensus is to remove the text regarding 7.2.8
from 6.58 TimeStamp in registration replies?

Cheers, Christian


From owner-megaco@fore.com  Fri May 11 09:59:14 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10063
	for ; Fri, 11 May 2001 09:59:14 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA17022;
	Fri, 11 May 2001 09:53:29 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA20569
	for megaco-list; Fri, 11 May 2001 09:51:29 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA20551
	for ; Fri, 11 May 2001 09:51:26 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA16791
	for ; Fri, 11 May 2001 09:51:22 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4BDpNd25314
	for ; Fri, 11 May 2001 09:51:23 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4BDpN225304
	for ; Fri, 11 May 2001 09:51:23 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id JAA26270; Fri, 11 May 2001 09:51:05 -0400 (EDT)
To: Christian Groves ,
        MEGACO list 
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id JAA26256; Fri, 11 May 2001 09:50:53 -0400 (EDT)
Message-ID: <3AFBEDCA.E33E1EE@lucent.com>
Date: Fri, 11 May 2001 09:48:58 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Original-To: Christian Groves ,
        MEGACO list 
Subject: Re: Implementors' Guide Update Editor's last Call Section 6.83
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


Christian,

I please put this change into 6.83.
My original version breaks many existing packages.

-troy



-------- Original Message --------
Subject: Re: [FINAL;)] Re: encoding package values as ANBF VALUES
Date: Tue, 01 May 2001 17:33:09 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
To: Christian Groves 
CC: MEGACO list 
References: <3AE8A218.D53C7C94@lucent.com> <3AE9110F.5CD95DAB@ericsson.com>


Christain et. al.,

Ugh.  I need to ammend my own proposal.  
My limitations on Enums were too strict 
for many existing package definitions.  

Changes below.

-troy



Christian Groves wrote:
> 
> G'Day Troy,
> 
> Just back from holidays and you already have work for me......but no
> arguments is what I like so i'll add the text to the IG.
> 
> Cheers, Christian
> 
> Troy Cauble wrote:
> >
> > Christian,
> >
> > Since nobody argued, I guess it's final:)
> > Can I get an Amen from the Keeper of the Additions?
> >
> > Proposed addition below.
> >
> > -troy
> >
> >  >  two lines about "Boolean values".>
> >
> > ; NOTE -- The ABNF in this section uses the VALUE construct (or lists of
> > ; VALUE constructs) to encode various package element values (properties,
> > ; signal parameters, etc.).  The types of these values vary and are
> > ; specified the relevant package definition.  Several such types are
> > ; described in section 12.2.
> > ;
> > ; The ABNF specification for VALUE allows a quotedString form or a
> > ; collection of SafeChars.  The encoding of package element values into
> > ; ABNF VALUES is specified below.  If a type's encoding allows characters
> > ; other than SafeChars, the quotedString form MUST be used for all values
> > ; of that type, even for specific values that consist only of SafeChars.
> > ;
> > ; String:  A string MUST use the quotedString form of VALUE and can
> > ; contain anything allowable in the quotedString form.
> > ;
> > ; Integer, Double, and Unsigned Integer:  Decimal values can be encoded
> > ; using characters 0-9.  Hexadecimal values must be prefixed with '0x'
> > ; and can use characters 0-9,a-f,A-F.  An octal format is not supported.
> > ; Negative integers start with '-' and MUST be Decimal.  The SafeChar
> > ; form of VALUE MUST be used.
> > ;
> > ; Character:  A UTF-8 encoding of a single letter surrounded by double
> > ; quotes.
> > ;
> > ; Enumeration:  An enumeration can be encoded from alphanumerics
> > ; and the underscore character.  The SafeChar form of VALUE MUST
> > ; be used.

Change the three lines above to:

; Enumeration:  An enumeration MUST use the SafeChar form of VALUE
; and can contain anything allowable in the SafeChar form.


> > ;
> > ; Boolean:  Boolean values are encoded as "on" and "off" and are
> > ; case insensitive.  The SafeChar form of VALUE MUST be used.
> > ;
> > ; Future types:  It is expected that packages will define types
> > ; beyond these initial types.  Any defined types MUST fit within
> > ; the ANBF specification of VALUE.  Specifically, if a type's encoding
> > ; allows characters other than SafeChars, the quotedString form MUST
> > ; be used for all values of that type, even for specific values that
> > ; consist only of SafeChars.
> > ;
> > ; Note that there is no way to use the double quote character within
> > ; a value.
> >
> > 


From owner-megaco@fore.com  Fri May 11 10:06:39 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10355
	for ; Fri, 11 May 2001 10:06:39 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA17795;
	Fri, 11 May 2001 10:00:53 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA22513
	for megaco-list; Fri, 11 May 2001 09:58:17 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA22492
	for ; Fri, 11 May 2001 09:58:15 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 11 May 2001 09:57:52 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F5C7@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Tom-PT Taylor'" ,
        "'megaco'"
	 
Subject: RE: Annex C Descriptor Assignments
Date: Fri, 11 May 2001 09:58:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Before we deal with the details of this, I question the premise:
  I think that Annex C ONLY is used in 
	binary encoding  and
	in local and remote (NOT localControl or TerminationState)
I think the I-G might state that better.
I think that if there are some things that don't belong in remote
  and local, they should be removed and possibly made part of a package,
  because you don't use Annex C in LocalControl

Brian





Here is the contribution to SG 16 I've drafted on the subject of descript=
or
assignments for the Annex C properties.

TITLE:	Descriptors For Megaco/H.248 Annex C Properties
___________________


INTRODUCTION

Megaco/H.248 Annex C defines a set of properties relating to media stream=
s.
As such, these properties may appear:
=B7	in the LocalControl descriptor, if they are local interest only, or
=B7	in the Local and Remote descriptors, if they must be coordinated
between the local and remote Media Gateways.

Megaco/H.248 Annex C currently fails to indicate which alternative applie=
s
to each of the properties specified within the Annex.  This contribution
argues that the H.248 Implementor's Guide should be updated to reflect su=
ch
an assignment.  The contribution goes on to derive principles for making =
the
assignment decision, and then applies those principles to derive a detail=
ed
set of  descriptor assignments for all of the properties in the Annex.

=20

NEED FOR A STANDARDIZED PROPERTY ASSIGNMENT

This section presents a semantic and a syntactic argument for standardizi=
ng
the assignment of properties to descriptors in Annex C.  At the semantic
level, it is essential that the assignment to descriptors be the same for=
 a
given property, regardless of the H.248 protocol encoding.  Otherwise one
encounters a semantic mismatch between encodings, such that with respect =
to
a given property asymmetric flow descriptions are possible in one encodin=
g
and not the other.  Such a mismatch may be introduced by general usage or=
 by
explicit adoption of Annex C properties in standards created by bodies ot=
her
than the IETF Megaco Working Group or Study Group 16.

At the syntactic level, assignment of specific properties to specific
descriptors simplifies parser construction by adding predictability to
message construction.
A final argument in favour of adding explicit descriptor assignments is t=
hat
Annex C, as "Package 0", should conform as much as possible to the
documentation rules for packages.  This includes documentation of the
descriptor to which each property should be assigned.

ASSIGNMENT PRINCIPLES
=20
The basic criterion for descriptor assignment was indicated in the
introduction: whether or not the property concerned must be coordinated w=
ith
the remote Media Gateway.
However, some borderline cases will require the use of subsidiary criteri=
a.
The first such criterion was suggested in the previous section: assurance
that the assignment is the same for both text and binary (Annex C)
encodings.  Because the text encoding for the Local and Remote descriptor=
s
is tied to SDP (RFC 2327), this means that at the very least the mandator=
y
properties found in RFC 2327 should  be assigned to the Local and Remote
descriptors rather than LocalControl.  Properties which are optional in S=
DP
may be placed in LocalControl if this makes sense, but the assignment mus=
t
be the same in both the text and the binary encodings.

There is a further possible criterion: is there a potential requirement  =
for
a given property to have a different value for each direction of flow, an=
d
will it be technically feasible to meet that requirement?  If so, the
property should be assigned to Local/Remote rather than LocalControl.

DETAILED ASSIGNMENTS

The following table proposes detailed assignments for the Annex C
properties.  The "Remarks" column indicates criteria used where the
assignment was not immediately obvious.

[Rather than repeat the tables, let me summarize by saying that almost
everything goes into Local/Remote.  Here are the exceptional cases:

Table C.1: Transmission mode (tag 1002) should perhaps be deprecated beca=
use
the Mode property in LocalControl carries the same information.  This is
equivalent to saying that the SDP in Local and Remote should not include =
any
of the directionality attributes.  People may want to comment.

Table C.1: Gain (tag 100C) and Jitterbuff (tag 100D) are placed in
LocalControl (of local interest only)

Table C.9: Modem (tag 901B) goes into the Modem Descriptor.  Actually it
should be deprecated because the necessary codepoints have already been
defined in the Modem descriptor.

Table C.9: DialledN (tag 901F) and DiallingN (tag 9020) go into LocalCont=
rol
because they do not require end-to-end coordination at the media level.]

Tom Taylor
Multimedia Control and Applications Standards
Ph.  +1 613 736 0961
taylor@nortelnetworks.com=20


From owner-megaco@fore.com  Fri May 11 10:12:06 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10559
	for ; Fri, 11 May 2001 10:12:05 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18554;
	Fri, 11 May 2001 10:06:15 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA24397
	for megaco-list; Fri, 11 May 2001 10:03:57 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24314
	for ; Fri, 11 May 2001 10:03:45 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 11 May 2001 10:03:23 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F5C8@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Christian Groves'" ,
        Paul Long
	 
Cc: megaco ietf 
Subject: RE: Implementors' Guide Update Editor's last Call
Date: Fri, 11 May 2001 10:03:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Maybe "The procedures in Annex D.1 contain a minimum suggested set of
ALF behaviors".

D.1 does not use shall or must very much.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Thursday, May 10, 2001 10:00 PM
> To: Paul Long
> Cc: megaco ietf
> Subject: Re: Implementors' Guide Update Editor's last Call
> 
> 
> G'Day Paul,
> 
> These additions look OK to me with the following comments:
> ALF not defined:
> The note you propose should be in D.1 I've also modified the text:
> "ALF is a set of techniques that allow an application, as opposed to a
> stack, to affect how messages are sent to the other side. A 
> typical ALF
> technique is to allow an application to change the order of messages
> sent when there is a queue AFTER it has queued them.  There 
> is no formal
> specification for ALF. The procedures in Annex D.1 define ALF 
> behaviour
> for the H.248 protocol."
> 
> Source Address:
> Added a "For example" at the front of the changed line. 
> Section 9 we've
> tried to keep as transport independent as possible.
> 
> TimeStamp in registration request and reply:
> I've added this to the existing 6.58 correction.
> 
> Error Descriptor location:
> I've added this to the existing 6.33 correction.
> 
> Cheers, Christian
> 
> 
> 
> Paul Long wrote:
> > 
> > Christian,
> > 
> > I've got a few more additions. Is it too late? These are 
> mostly just a
> > summary of the things I've had resolved recently on the 
> reflector. Here are
> > HTML and Word pages of the same content. (The HTML page 
> doesn't render too
> > well using Netscape. I guess because it was generated by Word. :-)
> > 
> > http://www.packetizer.com/people/plong/IGContribs.htm
> > http://www.packetizer.com/people/plong/IGContribs.doc
> > 
> > Paul Long
> > ipDialog, Inc.
> > 
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of 
> Christian Groves
> > Sent: Wednesday, May 09, 2001 12:40 AM
> > To: megaco ietf
> > Cc: Tom-PT Taylor; Glen Freundlich
> > Subject: Implementors' Guide Update Editor's last Call
> > 
> > G'Day all,
> > 
> > The H.248 Series Implementors' Guide has been updated to revision 6.
> > 
> > It can be found at:
> > ftp://standard.pictel.com/avc-site/Incoming/
> > files:
> > TD-xxx_H248_Implementors_Additions_v6.doc
> > TD-xxx_H248_Implementors_Additions_v6.pdf
> > 
> > This revision contains the Approved Implementors' Guide and the
> > Implementors' Guide Additions v5 with some other changes. 
> The changes
> > are detailed in the document.
> > 
> > This is an editors' last call. Please provide comments on 
> this draft by
> > Monday the 13th as a revision 7 will be stored on the 14th 
> and sent to
> > SG16 for approval at the Porto Seguro meeting. If you have 
> a comment on
> > a correction please provide the detailed solution or exact 
> changes that
> > you would like to see.
> > 
> > Cheers, Christian
> 
> 


From owner-megaco@fore.com  Fri May 11 10:12:11 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10569
	for ; Fri, 11 May 2001 10:12:11 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18553;
	Fri, 11 May 2001 10:06:15 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA24190
	for megaco-list; Fri, 11 May 2001 10:03:43 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24137
	for ; Fri, 11 May 2001 10:03:28 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA18140
	for ; Fri, 11 May 2001 10:03:23 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id KAA04973; Fri, 11 May 2001 10:03:20 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 11 May 2001 10:03:01 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 11 May 2001 10:03:03 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB1A@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Rosen, Brian'" , "'megaco'" 
Subject: RE: Annex C Descriptor Assignments
Date: Fri, 11 May 2001 10:03:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DA23.16B9A6B0"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DA23.16B9A6B0
Content-Type: text/plain;
	charset="ISO-8859-1"

Given my findings, I would agree with you.  Let's see what other people have
to say.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Friday, May 11, 2001 9:58 AM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'megaco'
> Subject: RE: Annex C Descriptor Assignments
> 
> 
> Before we deal with the details of this, I question the premise:
>   I think that Annex C ONLY is used in 
> 	binary encoding  and
> 	in local and remote (NOT localControl or TerminationState)
> I think the I-G might state that better.
> I think that if there are some things that don't belong in remote
>   and local, they should be removed and possibly made part of 
> a package,
>   because you don't use Annex C in LocalControl
> 
> Brian
> 
> 
> 
> 
> 
> Here is the contribution to SG 16 I've drafted on the subject 
> of descript=
> or
> assignments for the Annex C properties.
> 
> TITLE:	Descriptors For Megaco/H.248 Annex C Properties
> ___________________
> 
> 
> INTRODUCTION
> 
> Megaco/H.248 Annex C defines a set of properties relating to 
> media stream=
> s.
> As such, these properties may appear:
> =B7	in the LocalControl descriptor, if they are local 
> interest only, or
> =B7	in the Local and Remote descriptors, if they must be coordinated
> between the local and remote Media Gateways.
> 
> Megaco/H.248 Annex C currently fails to indicate which 
> alternative applie=
> s
> to each of the properties specified within the Annex.  This 
> contribution
> argues that the H.248 Implementor's Guide should be updated 
> to reflect su=
> ch
> an assignment.  The contribution goes on to derive principles 
> for making =
> the
> assignment decision, and then applies those principles to 
> derive a detail=
> ed
> set of  descriptor assignments for all of the properties in the Annex.
> 
> =20
> 
> NEED FOR A STANDARDIZED PROPERTY ASSIGNMENT
> 
> This section presents a semantic and a syntactic argument for 
> standardizi=
> ng
> the assignment of properties to descriptors in Annex C.  At 
> the semantic
> level, it is essential that the assignment to descriptors be 
> the same for=
>  a
> given property, regardless of the H.248 protocol encoding.  
> Otherwise one
> encounters a semantic mismatch between encodings, such that 
> with respect =
> to
> a given property asymmetric flow descriptions are possible in 
> one encodin=
> g
> and not the other.  Such a mismatch may be introduced by 
> general usage or=
>  by
> explicit adoption of Annex C properties in standards created 
> by bodies ot=
> her
> than the IETF Megaco Working Group or Study Group 16.
> 
> At the syntactic level, assignment of specific properties to specific
> descriptors simplifies parser construction by adding predictability to
> message construction.
> A final argument in favour of adding explicit descriptor 
> assignments is t=
> hat
> Annex C, as "Package 0", should conform as much as possible to the
> documentation rules for packages.  This includes documentation of the
> descriptor to which each property should be assigned.
> 
> ASSIGNMENT PRINCIPLES
> =20
> The basic criterion for descriptor assignment was indicated in the
> introduction: whether or not the property concerned must be 
> coordinated w=
> ith
> the remote Media Gateway.
> However, some borderline cases will require the use of 
> subsidiary criteri=
> a.
> The first such criterion was suggested in the previous 
> section: assurance
> that the assignment is the same for both text and binary (Annex C)
> encodings.  Because the text encoding for the Local and 
> Remote descriptor=
> s
> is tied to SDP (RFC 2327), this means that at the very least 
> the mandator=
> y
> properties found in RFC 2327 should  be assigned to the Local 
> and Remote
> descriptors rather than LocalControl.  Properties which are 
> optional in S=
> DP
> may be placed in LocalControl if this makes sense, but the 
> assignment mus=
> t
> be the same in both the text and the binary encodings.
> 
> There is a further possible criterion: is there a potential 
> requirement  =
> for
> a given property to have a different value for each direction 
> of flow, an=
> d
> will it be technically feasible to meet that requirement?  If so, the
> property should be assigned to Local/Remote rather than LocalControl.
> 
> DETAILED ASSIGNMENTS
> 
> The following table proposes detailed assignments for the Annex C
> properties.  The "Remarks" column indicates criteria used where the
> assignment was not immediately obvious.
> 
> [Rather than repeat the tables, let me summarize by saying that almost
> everything goes into Local/Remote.  Here are the exceptional cases:
> 
> Table C.1: Transmission mode (tag 1002) should perhaps be 
> deprecated beca=
> use
> the Mode property in LocalControl carries the same 
> information.  This is
> equivalent to saying that the SDP in Local and Remote should 
> not include =
> any
> of the directionality attributes.  People may want to comment.
> 
> Table C.1: Gain (tag 100C) and Jitterbuff (tag 100D) are placed in
> LocalControl (of local interest only)
> 
> Table C.9: Modem (tag 901B) goes into the Modem Descriptor.  
> Actually it
> should be deprecated because the necessary codepoints have 
> already been
> defined in the Modem descriptor.
> 
> Table C.9: DialledN (tag 901F) and DiallingN (tag 9020) go 
> into LocalCont=
> rol
> because they do not require end-to-end coordination at the 
> media level.]
> 
> Tom Taylor
> Multimedia Control and Applications Standards
> Ph.  +1 613 736 0961
> taylor@nortelnetworks.com=20
> 

------_=_NextPart_001_01C0DA23.16B9A6B0
Content-Type: text/html;
	charset="ISO-8859-1"






RE: Annex C Descriptor Assignments




Given my findings, I would agree with you.  Let's see what other people have to say.




> -----Original Message-----

> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]

> Sent: Friday, May 11, 2001 9:58 AM

> To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'megaco'

> Subject: RE: Annex C Descriptor Assignments

> 

> 

> Before we deal with the details of this, I question the premise:

>   I think that Annex C ONLY is used in 

>       binary encoding  and

>       in local and remote (NOT localControl or TerminationState)

> I think the I-G might state that better.

> I think that if there are some things that don't belong in remote

>   and local, they should be removed and possibly made part of 

> a package,

>   because you don't use Annex C in LocalControl

> 

> Brian

> 

> 

> 

> 

> 

> Here is the contribution to SG 16 I've drafted on the subject 

> of descript=

> or

> assignments for the Annex C properties.

> 

> TITLE:        Descriptors For Megaco/H.248 Annex C Properties

> ___________________

> 

> 

> INTRODUCTION

> 

> Megaco/H.248 Annex C defines a set of properties relating to 

> media stream=

> s.

> As such, these properties may appear:

> =B7   in the LocalControl descriptor, if they are local 

> interest only, or

> =B7   in the Local and Remote descriptors, if they must be coordinated

> between the local and remote Media Gateways.

> 

> Megaco/H.248 Annex C currently fails to indicate which 

> alternative applie=

> s

> to each of the properties specified within the Annex.  This 

> contribution

> argues that the H.248 Implementor's Guide should be updated 

> to reflect su=

> ch

> an assignment.  The contribution goes on to derive principles 

> for making =

> the

> assignment decision, and then applies those principles to 

> derive a detail=

> ed

> set of  descriptor assignments for all of the properties in the Annex.

> 

> =20

> 

> NEED FOR A STANDARDIZED PROPERTY ASSIGNMENT

> 

> This section presents a semantic and a syntactic argument for 

> standardizi=

> ng

> the assignment of properties to descriptors in Annex C.  At 

> the semantic

> level, it is essential that the assignment to descriptors be 

> the same for=

>  a

> given property, regardless of the H.248 protocol encoding.  

> Otherwise one

> encounters a semantic mismatch between encodings, such that 

> with respect =

> to

> a given property asymmetric flow descriptions are possible in 

> one encodin=

> g

> and not the other.  Such a mismatch may be introduced by 

> general usage or=

>  by

> explicit adoption of Annex C properties in standards created 

> by bodies ot=

> her

> than the IETF Megaco Working Group or Study Group 16.

> 

> At the syntactic level, assignment of specific properties to specific

> descriptors simplifies parser construction by adding predictability to

> message construction.

> A final argument in favour of adding explicit descriptor 

> assignments is t=

> hat

> Annex C, as "Package 0", should conform as much as possible to the

> documentation rules for packages.  This includes documentation of the

> descriptor to which each property should be assigned.

> 

> ASSIGNMENT PRINCIPLES

> =20

> The basic criterion for descriptor assignment was indicated in the

> introduction: whether or not the property concerned must be 

> coordinated w=

> ith

> the remote Media Gateway.

> However, some borderline cases will require the use of 

> subsidiary criteri=

> a.

> The first such criterion was suggested in the previous 

> section: assurance

> that the assignment is the same for both text and binary (Annex C)

> encodings.  Because the text encoding for the Local and 

> Remote descriptor=

> s

> is tied to SDP (RFC 2327), this means that at the very least 

> the mandator=

> y

> properties found in RFC 2327 should  be assigned to the Local 

> and Remote

> descriptors rather than LocalControl.  Properties which are 

> optional in S=

> DP

> may be placed in LocalControl if this makes sense, but the 

> assignment mus=

> t

> be the same in both the text and the binary encodings.

> 

> There is a further possible criterion: is there a potential 

> requirement  =

> for

> a given property to have a different value for each direction 

> of flow, an=

> d

> will it be technically feasible to meet that requirement?  If so, the

> property should be assigned to Local/Remote rather than LocalControl.

> 

> DETAILED ASSIGNMENTS

> 

> The following table proposes detailed assignments for the Annex C

> properties.  The "Remarks" column indicates criteria used where the

> assignment was not immediately obvious.

> 

> [Rather than repeat the tables, let me summarize by saying that almost

> everything goes into Local/Remote.  Here are the exceptional cases:

> 

> Table C.1: Transmission mode (tag 1002) should perhaps be 

> deprecated beca=

> use

> the Mode property in LocalControl carries the same 

> information.  This is

> equivalent to saying that the SDP in Local and Remote should 

> not include =

> any

> of the directionality attributes.  People may want to comment.

> 

> Table C.1: Gain (tag 100C) and Jitterbuff (tag 100D) are placed in

> LocalControl (of local interest only)

> 

> Table C.9: Modem (tag 901B) goes into the Modem Descriptor.  

> Actually it

> should be deprecated because the necessary codepoints have 

> already been

> defined in the Modem descriptor.

> 

> Table C.9: DialledN (tag 901F) and DiallingN (tag 9020) go 

> into LocalCont=

> rol

> because they do not require end-to-end coordination at the 

> media level.]

> 

> Tom Taylor

> Multimedia Control and Applications Standards

> Ph.  +1 613 736 0961

> taylor@nortelnetworks.com=20

> 





------_=_NextPart_001_01C0DA23.16B9A6B0--


From owner-megaco@fore.com  Fri May 11 10:41:11 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11574
	for ; Fri, 11 May 2001 10:41:10 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21560;
	Fri, 11 May 2001 10:35:13 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA04126
	for megaco-list; Fri, 11 May 2001 10:32:46 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04122
	for ; Fri, 11 May 2001 10:32:44 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21283
	for ; Fri, 11 May 2001 10:32:40 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4BEWg703791
	for ; Fri, 11 May 2001 10:32:42 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4BEWgc03784
	for ; Fri, 11 May 2001 10:32:42 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id KAA26972; Fri, 11 May 2001 10:32:23 -0400 (EDT)
Cc: "'Rosen, Brian'" , "'megaco'" 
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id KAA26958; Fri, 11 May 2001 10:32:21 -0400 (EDT)
Message-ID: <3AFBF782.AB45289E@lucent.com>
Date: Fri, 11 May 2001 10:30:26 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom-PT Taylor 
Original-CC: "'Rosen, Brian'" , "'megaco'" 
Subject: Re: Annex C Descriptor Assignments
References: <28560036253BD41191A10000F8BCBD110250CB1A@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


Yes!

Annex C  -- binary only -- LD & RD only.
SDP -- text only -- LD & RD only.
Packages -- binary AND text -- NOT in LD & RD.

It's great that Tom found so few exceptions.  
That makes it feasible to move them out into 
packages.

I would like to drop the "Package 0" terminology though.
The word "package" implies many things that Annex C is not.

-troy


> Tom-PT Taylor wrote:
> 
> Given my findings, I would agree with you.  Let's see what other people have
> to say.
> 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > Sent: Friday, May 11, 2001 9:58 AM
> > To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'megaco'
> > Subject: RE: Annex C Descriptor Assignments
> >
> >
> > Before we deal with the details of this, I question the premise:
> >   I think that Annex C ONLY is used in
> >       binary encoding  and
> >       in local and remote (NOT localControl or TerminationState)
> > I think the I-G might state that better.
> > I think that if there are some things that don't belong in remote
> >   and local, they should be removed and possibly made part of
> > a package,
> >   because you don't use Annex C in LocalControl
> >
> > Brian
> >
> >
> >
> >
> >
> > Here is the contribution to SG 16 I've drafted on the subject
> > of descript=
> > or
> > assignments for the Annex C properties.
> >
> > TITLE:        Descriptors For Megaco/H.248 Annex C Properties
> > ___________________
> >
> >
> > INTRODUCTION
> >
> > Megaco/H.248 Annex C defines a set of properties relating to
> > media stream=
> > s.
> > As such, these properties may appear:
> > =B7   in the LocalControl descriptor, if they are local
> > interest only, or
> > =B7   in the Local and Remote descriptors, if they must be coordinated
> > between the local and remote Media Gateways.
> >
> > Megaco/H.248 Annex C currently fails to indicate which
> > alternative applie=
> > s
> > to each of the properties specified within the Annex.  This
> > contribution
> > argues that the H.248 Implementor's Guide should be updated
> > to reflect su=
> > ch
> > an assignment.  The contribution goes on to derive principles
> > for making =
> > the
> > assignment decision, and then applies those principles to
> > derive a detail=
> > ed
> > set of  descriptor assignments for all of the properties in the Annex.
> >
> > =20
> >
> > NEED FOR A STANDARDIZED PROPERTY ASSIGNMENT
> >
> > This section presents a semantic and a syntactic argument for
> > standardizi=
> > ng
> > the assignment of properties to descriptors in Annex C.  At
> > the semantic
> > level, it is essential that the assignment to descriptors be
> > the same for=
> >  a
> > given property, regardless of the H.248 protocol encoding.
> > Otherwise one
> > encounters a semantic mismatch between encodings, such that
> > with respect =
> > to
> > a given property asymmetric flow descriptions are possible in
> > one encodin=
> > g
> > and not the other.  Such a mismatch may be introduced by
> > general usage or=
> >  by
> > explicit adoption of Annex C properties in standards created
> > by bodies ot=
> > her
> > than the IETF Megaco Working Group or Study Group 16.
> >
> > At the syntactic level, assignment of specific properties to specific
> > descriptors simplifies parser construction by adding predictability to
> > message construction.
> > A final argument in favour of adding explicit descriptor
> > assignments is t=
> > hat
> > Annex C, as "Package 0", should conform as much as possible to the
> > documentation rules for packages.  This includes documentation of the
> > descriptor to which each property should be assigned.
> >
> > ASSIGNMENT PRINCIPLES
> > =20
> > The basic criterion for descriptor assignment was indicated in the
> > introduction: whether or not the property concerned must be
> > coordinated w=
> > ith
> > the remote Media Gateway.
> > However, some borderline cases will require the use of
> > subsidiary criteri=
> > a.
> > The first such criterion was suggested in the previous
> > section: assurance
> > that the assignment is the same for both text and binary (Annex C)
> > encodings.  Because the text encoding for the Local and
> > Remote descriptor=
> > s
> > is tied to SDP (RFC 2327), this means that at the very least
> > the mandator=
> > y
> > properties found in RFC 2327 should  be assigned to the Local
> > and Remote
> > descriptors rather than LocalControl.  Properties which are
> > optional in S=
> > DP
> > may be placed in LocalControl if this makes sense, but the
> > assignment mus=
> > t
> > be the same in both the text and the binary encodings.
> >
> > There is a further possible criterion: is there a potential
> > requirement  =
> > for
> > a given property to have a different value for each direction
> > of flow, an=
> > d
> > will it be technically feasible to meet that requirement?  If so, the
> > property should be assigned to Local/Remote rather than LocalControl.
> >
> > DETAILED ASSIGNMENTS
> >
> > The following table proposes detailed assignments for the Annex C
> > properties.  The "Remarks" column indicates criteria used where the
> > assignment was not immediately obvious.
> >
> > [Rather than repeat the tables, let me summarize by saying that almost
> > everything goes into Local/Remote.  Here are the exceptional cases:
> >
> > Table C.1: Transmission mode (tag 1002) should perhaps be
> > deprecated beca=
> > use
> > the Mode property in LocalControl carries the same
> > information.  This is
> > equivalent to saying that the SDP in Local and Remote should
> > not include =
> > any
> > of the directionality attributes.  People may want to comment.
> >
> > Table C.1: Gain (tag 100C) and Jitterbuff (tag 100D) are placed in
> > LocalControl (of local interest only)
> >
> > Table C.9: Modem (tag 901B) goes into the Modem Descriptor.
> > Actually it
> > should be deprecated because the necessary codepoints have
> > already been
> > defined in the Modem descriptor.
> >
> > Table C.9: DialledN (tag 901F) and DiallingN (tag 9020) go
> > into LocalCont=
> > rol
> > because they do not require end-to-end coordination at the
> > media level.]
> >
> > Tom Taylor
> > Multimedia Control and Applications Standards
> > Ph.  +1 613 736 0961
> > taylor@nortelnetworks.com=20
> >


From owner-megaco@fore.com  Fri May 11 10:42:44 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11636
	for ; Fri, 11 May 2001 10:42:44 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21816;
	Fri, 11 May 2001 10:36:36 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA04404
	for megaco-list; Fri, 11 May 2001 10:33:50 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04315
	for ; Fri, 11 May 2001 10:33:34 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21317
	for ; Fri, 11 May 2001 10:33:19 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Fri, 11 May 2001 09:34:36 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD9494524FA3C@RADVPOST>
From: Dan Elbert 
To: "'megaco@fore.com'" 
Subject: RE: Implementors' Guide Update Editor's last Call
Date: Fri, 11 May 2001 09:34:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0DA27.80042970"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DA27.80042970
Content-Type: text/plain;
	charset="iso-8859-1"

Can we have this in the Implementor's Guide ?
 
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Wednesday, April 11, 2001 12:06 AM
To: 'Dan Elbert'; 'megaco@fore.com'
Subject: RE: Use of "strict" parameter [FINAL?]
 
We only had one comment, from Nurit Shenhar.  He and you are the consensus:
"state" is default, and the "init" parameter MUST be reported back when
strict is set to state.
 
 -----Original Message-----
From: Dan Elbert [mailto:DElbert@radvision.com]
Sent: Thursday, April 05, 2001 11:38 AM
To: 'megaco@fore.com'
Subject: RE: Use of "strict" parameter
Hi
Any conclusion in this issue ? Seems like a candidate for causing
interoperability problems...
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, March 13, 2001 10:37 AM
To: 'Dan Elbert'; 'megaco@fore.com'
Subject: RE: Use of "strict" parameter
Hi.  Answers below. 
> -----Original Message----- 
> From: Dan Elbert [ mailto:DElbert@radvision.com
 ] 
> Sent: Friday, March 02, 2001 12:17 PM 
> To: 'megaco@fore.com' 
> Subject: Use of "strict" parameter 
> 
> 
> Hi All 
> 
> 1. What is the default behavior of the MG if the "strict" 
> parameter is not 
> set ( for events onhook, offhook of al package) ? 
> I'd suggest "state" since this allows to convey the maximal 
> information back 
> to the MGC. 
[PTT] We should choose whatever reflects the most frequent usage -- defaults
are there to save effort.  For people who don't want to look it up, "state"
means that if a line is already on/off-hook when told to watch for
on/off-hook, the corresponding state transition event will be reported.
Does this seem like the most likely setting?
> 
> 2. What is the correct use of the "exact" value for the 
> "strict" parameter ? 
> If the termination is already in the required state, I 
> understand that 
> this setting will cause the termination not to send the event 
> but to keep 
> waiting for it. Is this correct ? Seems like in this case there is 
> a risk of the MGC getting out of synch with the MG. 
[PTT] 
Your description of behaviour is correct.  There could be circumstances
where the MGC wants to use this one, for instance, to tell the MG to watch
for off-hook as a final step of call cleardown, where the line may still be
off-hook from the previous call.
> 
> 3. If the "init" parameter is not set when reporting a hook 
> event, should 
> this be considered the same as if it was set to "False" ? 
> (this is what makes more sense to me). Or is this a required 
> parameter ? (I 
> don't think that anybody was setting this in the interop...) 
[PTT] 
We need agreement on this, particularly when the "state" setting is used.
Comments, people? 
> 
> Thanks, 
> 
> Dan Elbert 
> 

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












RE: Use of "strict" parameter










C=
an we
have this in the Implementor’s Guide =
?



<=
![if =
!supportEmptyParas]> 
=



-----Original Message-----

From: Tom-PT Taylor
[mailto:taylor@nortelnetworks.com]

Sent: Wednesday, April =
11, 2001
12:06 AM

To: 'Dan Elbert';
'megaco@fore.com'

Subject: RE: Use of
"strict" parameter [FINAL?]



 



We only had one comment, from =
Nurit
Shenhar.  He and you are the consensus: "state" is =
default, and
the "init" parameter MUST be reported back when strict is set =
to
state.



 =




 -----Ori=
ginal
Message-----

From: Dan Elbert
[mailto:DElbert@radvision.com]

Sent: Thursday, April =
05, 2001
11:38 AM

To: =
'megaco@fore.com'

Subject: RE: Use of
"strict" parameter






Hi=
=




Any conclusion =
in this
issue ? Seems like a candidate for causing interoperability =
problems...=










-----Original
Message-----

From: Tom-PT Taylor =
[mailto:taylor@nortelnetworks.com]

Sent: Tuesday, March 13, =
2001
10:37 AM

To: 'Dan Elbert';
'megaco@fore.com'

Subject: RE: Use of
"strict" parameter



Hi. 
Answers below. =




>
-----Original Message----- 

> From: Dan Elbert [mailto:DElbert@radvision.com] 

> Sent: Friday, March 02, 2001 12:17 =
PM 

> To: 'megaco@fore.com' 

> Subject: Use of "strict" =
parameter 

> 

> 

> Hi All 

> 

> 1. What is the default behavior of the MG if the
"strict" 

> parameter is not 

> set ( for events onhook, offhook of al package) =
? 

> I'd suggest "state" since this allows to =
convey the
maximal 

> information back 

> to the MGC. 



[PTT] We
should choose whatever reflects the most frequent usage -- defaults are =
there
to save effort.  For people who don't want to look it up,
"state" means that if a line is already on/off-hook when told =
to
watch for on/off-hook, the corresponding state transition event will be
reported.  Does this seem like the most likely =
setting?=




> 

> 2. What is the correct use of the "exact" =
value for
the 

> "strict" parameter ? 

> If the termination is already in the required state, =
I 

> understand that 

> this setting will cause the termination not to send =
the event


> but to keep 

> waiting for it. Is this correct ? Seems like in this =
case
there is =


> a risk of the MGC getting out of synch with the =
MG. =




[PTT] 

Your description of behaviour is correct.  There =
could be
circumstances where the MGC wants to use this one, for instance, to =
tell the MG
to watch for off-hook as a final step of call cleardown, where the line =
may
still be off-hook from the previous call.=




> 

> 3. If the "init" parameter is not set when
reporting a hook 

> event, should 

> this be considered the same as if it was set to
"False" ? 

> (this is what makes more sense to me). Or is this a =
required 

> parameter ? (I 

> don't think that anybody was setting this in the =
interop...) =




[PTT] 

We need agreement on this, particularly when the =
"state"
setting is used.  Comments, people? 

> 

> Thanks, 

> 

> Dan Elbert 

> 












------_=_NextPart_001_01C0DA27.80042970--


From owner-megaco@fore.com  Fri May 11 10:54:32 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11965
	for ; Fri, 11 May 2001 10:54:31 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23430;
	Fri, 11 May 2001 10:48:46 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA07953
	for megaco-list; Fri, 11 May 2001 10:46:10 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07914
	for ; Fri, 11 May 2001 10:45:58 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA22803
	for ; Fri, 11 May 2001 10:45:53 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4BEjs716633
	for ; Fri, 11 May 2001 10:45:54 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4BEjsc16624
	for ; Fri, 11 May 2001 10:45:54 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id KAA27489; Fri, 11 May 2001 10:45:41 -0400 (EDT)
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id KAA27485; Fri, 11 May 2001 10:45:40 -0400 (EDT)
Message-ID: <3AFBFAA1.62EEB48C@lucent.com>
Date: Fri, 11 May 2001 10:43:45 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: MEGACO list 
Subject: IG Update 9.1 question
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


The IG update 9.1 description seems to say that 
ANY signal's type may be changed to any other 
signal type by SignalType= .

Is this correct?

-troy


From owner-megaco@fore.com  Fri May 11 10:54:36 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11976
	for ; Fri, 11 May 2001 10:54:36 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23102;
	Fri, 11 May 2001 10:47:15 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA07410
	for megaco-list; Fri, 11 May 2001 10:44:27 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07395
	for ; Fri, 11 May 2001 10:44:24 -0400 (EDT)
From: vibansal@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA22650
	for ; Fri, 11 May 2001 10:44:19 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4BEjIN22468;
	Fri, 11 May 2001 20:15:19 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A49.004F99FB ; Fri, 11 May 2001 19:59:27 +0530
X-Lotus-FromDomain: HSS
To: "Tom-PT Taylor" 
cc: "'Paul Long'" , megaco 
Message-ID: <65256A49.004F968B.00@sandesh.hss.hns.com>
Date: Fri, 11 May 2001 20:13:02 +0530
Subject: RE: From whence they came?
Mime-Version: 1.0
Content-type: multipart/mixed;
	Boundary="0__=YWX0sfAHsLmUNEjW6eDVrGKKh1eaXgXXiII9eYqFQEJQ965pPIOAyMO5"
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

--0__=YWX0sfAHsLmUNEjW6eDVrGKKh1eaXgXXiII9eYqFQEJQ965pPIOAyMO5
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Hello Tom,
     Does that mean that from a host with IP1 as the IP address, a Megaco
message
can be sent to the peer with an MId as IP2? Should the receiving entity not
compare the
source IP address and the IP address in the message header (assuming the mID is
represented by IP address)?

Regards,
Vivek





"Tom-PT Taylor"  on 05/11/2001 06:13:14 PM

To:   "'Paul Long'" , megaco 
cc:    (bcc: Vivek Bansal/HSS)

Subject:  RE: From whence they came?




Basically, yes.  It's probably better to use a domain name rather than an
address as an mID tag.

-----Original Message-----
From: Paul Long [mailto:plong@ipdialog.com]
Sent: Thursday, May 10, 2001 8:28 PM
To: megaco
Subject: RE: From whence they came?


Tom,

Hmmm... Taking a closer look at the spec, I see that the mID in the message
prolog is just used by the receiver as a logical identifier for the sender
and that, in particular, the IP-address forms just have syntactical
value--they are never used as IP addresses, per se. It looks like these mIDs
are only used when paired up with transaction identifiers to uniquely
identify transactions, scoped to the receiver. Is this correct? Scary
thought, but, as long as the sender takes care by using an IP address that
another sender will not use, it appears that the IP address in a message mID
doesn't have to have any relationship to the actual network interface of the
sender. Am I right?

Paul Long
ipDialog, Inc.

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Thursday, May 10, 2001 5:56 PM
To: 'Paul Long'; megaco
Subject: RE: From whence they came?


It's partly the difference between a physical and a logical unit in a
load-sharing architecture where the separate units have different addresses.
There's also the possibility that a single physical unit has multiple
network interfaces.  Using the address as received in the header is
important because it gives a beter chnace of the response getting back
through any intervening firewall.

-----Original Message-----
From: Paul Long [mailto:plong@ipdialog.com]
Sent: Thursday, May 10, 2001 5:40 PM
To: megaco
Subject: RE: From whence they came?


Tom,

Okay, then, and this may be a stupid question, but what is the difference
between "the peer in an association" and the source of a message? IOW, under
what circumstances might they be different? The reason I was confused was
probably because in H.323 the source of a message is of absolutely no
consequence.

Paul Long
ipDialog, Inc.



--0__=YWX0sfAHsLmUNEjW6eDVrGKKh1eaXgXXiII9eYqFQEJQ965pPIOAyMO5
Content-type: text/html;
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U
RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9SVNPLTg4NTktMSI+DQo8VElUTEU+UkU6IEZyb20gd2hl
bmNlIHRoZXkgY2FtZT88L1RJVExFPg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4wMC4zMTAz
LjEwMDAiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZPg0KPERJVj48Rk9OVCBjb2xvcj0j
MDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NTk3MzA0MjEyLTExMDUyMDAx
PkJhc2ljYWxseSwgeWVzLiZuYnNwOyBJdCdzIHByb2JhYmx5IGJldHRlciB0byB1c2UgYSANCmRv
bWFpbiBuYW1lIHJhdGhlciB0aGFuIGFuIGFkZHJlc3MgYXMgYW4gbUlEIHRhZy48L1NQQU4+PC9G
T05UPjwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJCT1JERVItTEVGVDogIzAw
MDBmZiAycHggc29saWQ7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4OyBQQURE
SU5HLUxFRlQ6IDVweCI+DQogIDxESVYgYWxpZ249bGVmdCBjbGFzcz1PdXRsb29rTWVzc2FnZUhl
YWRlciBkaXI9bHRyPjxGT05UIGZhY2U9VGFob21hIA0KICBzaXplPTI+LS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS08QlI+PEI+RnJvbTo8L0I+IFBhdWwgTG9uZyANCiAgW21haWx0bzpwbG9uZ0Bp
cGRpYWxvZy5jb21dPEJSPjxCPlNlbnQ6PC9CPiBUaHVyc2RheSwgTWF5IDEwLCAyMDAxIDg6Mjgg
DQogIFBNPEJSPjxCPlRvOjwvQj4gbWVnYWNvPEJSPjxCPlN1YmplY3Q6PC9CPiBSRTogRnJvbSB3
aGVuY2UgdGhleSANCiAgY2FtZT88QlI+PEJSPjwvRElWPjwvRk9OVD4NCiAgPERJVj48U1BBTiBj
bGFzcz01MjAzODExMDAtMTEwNTIwMDE+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsIA0K
ICBzaXplPTI+VG9tLDwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9NTIw
MzgxMTAwLTExMDUyMDAxPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCANCiAgc2l6ZT0y
PjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9NTIwMzgxMTAw
LTExMDUyMDAxPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCANCiAgc2l6ZT0yPkhtbW0u
Li4gVGFraW5nJm5ic3A7YSBjbG9zZXImbmJzcDtsb29rIGF0IHRoZSBzcGVjLCBJIHNlZSB0aGF0
IHRoZSBtSUQgDQogIGluIHRoZSBtZXNzYWdlIHByb2xvZyBpcyBqdXN0IHVzZWQgYnkgdGhlIHJl
Y2VpdmVyIGFzIGEgDQogIGxvZ2ljYWwmbmJzcDtpZGVudGlmaWVyIGZvciB0aGUgc2VuZGVyIGFu
ZCB0aGF0LCBpbiBwYXJ0aWN1bGFyLCB0aGUgSVAtYWRkcmVzcyANCiAgZm9ybXMganVzdCBoYXZl
IHN5bnRhY3RpY2FsIHZhbHVlLS10aGV5IGFyZSBuZXZlciB1c2VkIGFzIElQIGFkZHJlc3Nlcywg
cGVyIA0KICBzZS4gSXQgbG9va3MgbGlrZSB0aGVzZSBtSURzIGFyZSBvbmx5IHVzZWQgd2hlbiBw
YWlyZWQgdXAgd2l0aCB0cmFuc2FjdGlvbiANCiAgaWRlbnRpZmllcnMgdG8gdW5pcXVlbHkgaWRl
bnRpZnkgdHJhbnNhY3Rpb25zLCBzY29wZWQgdG8gdGhlIHJlY2VpdmVyLiBJcyB0aGlzIA0KICBj
b3JyZWN0PyBTY2FyeSB0aG91Z2h0LCBidXQsIGFzIGxvbmcgYXMgdGhlIHNlbmRlciB0YWtlcyBj
YXJlIGJ5IHVzaW5nJm5ic3A7YW4gDQogIElQIGFkZHJlc3MgdGhhdCBhbm90aGVyIHNlbmRlciB3
aWxsIG5vdCB1c2UsIGl0IGFwcGVhcnMgdGhhdCB0aGUgSVAgYWRkcmVzcyBpbiANCiAgYSBtZXNz
YWdlJm5ic3A7bUlEIGRvZXNuJ3QgaGF2ZSB0byBoYXZlIGFueSByZWxhdGlvbnNoaXAgdG8gdGhl
IGFjdHVhbCBuZXR3b3JrIA0KICBpbnRlcmZhY2Ugb2YgdGhlIHNlbmRlci4gQW0gSSByaWdodD88
L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTUyMDM4MTEwMC0xMTA1MjAw
MT48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgDQogIHNpemU9Mj48L0ZPTlQ+PC9TUEFO
PiZuYnNwOzwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTUyMDM4MTEwMC0xMTA1MjAwMT48Rk9O
VCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPlBhdWwgDQogIExvbmc8L0ZPTlQ+PC9T
UEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTUyMDM4MTEwMC0xMTA1MjAwMT48Rk9OVCBj
b2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgDQogIHNpemU9Mj5pcERpYWxvZywgSW5jLjwvRk9OVD48
L1NQQU4+PC9ESVY+DQogIDxCTE9DS1FVT1RFIGRpcj1sdHIgc3R5bGU9Ik1BUkdJTi1SSUdIVDog
MHB4Ij4NCiAgICA8RElWIGFsaWduPWxlZnQgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgZGly
PWx0cj48Rk9OVCBmYWNlPVRhaG9tYSANCiAgICBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS08QlI+PEI+RnJvbTo8L0I+IFRvbS1QVCBUYXlsb3IgDQogICAgW21haWx0bzp0YXlsb3JA
bm9ydGVsbmV0d29ya3MuY29tXTxCUj48Qj5TZW50OjwvQj4gVGh1cnNkYXksIE1heSAxMCwgMjAw
MSANCiAgICA1OjU2IFBNPEJSPjxCPlRvOjwvQj4gJ1BhdWwgTG9uZyc7IG1lZ2FjbzxCUj48Qj5T
dWJqZWN0OjwvQj4gUkU6IEZyb20gd2hlbmNlIA0KICAgIHRoZXkgY2FtZT88QlI+PEJSPjwvRk9O
VD48L0RJVj4NCiAgICA8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+
PFNQQU4gDQogICAgY2xhc3M9MjU3Mzc0NzIyLTEwMDUyMDAxPkl0J3MgcGFydGx5IHRoZSBkaWZm
ZXJlbmNlIGJldHdlZW4gYSBwaHlzaWNhbCBhbmQgYSANCiAgICBsb2dpY2FsIHVuaXQgaW4gYSBs
b2FkLXNoYXJpbmcgYXJjaGl0ZWN0dXJlIHdoZXJlIHRoZSBzZXBhcmF0ZSB1bml0cyBoYXZlIA0K
ICAgIGRpZmZlcmVudCBhZGRyZXNzZXMuJm5ic3A7IFRoZXJlJ3MgYWxzbyB0aGUgcG9zc2liaWxp
dHkgdGhhdCBhIHNpbmdsZSANCiAgICBwaHlzaWNhbCB1bml0IGhhcyBtdWx0aXBsZSBuZXR3b3Jr
IGludGVyZmFjZXMuJm5ic3A7IFVzaW5nIHRoZSBhZGRyZXNzIGFzIA0KICAgIHJlY2VpdmVkIGlu
IHRoZSBoZWFkZXIgaXMgaW1wb3J0YW50IGJlY2F1c2UgaXQgZ2l2ZXMgYSBiZXRlciBjaG5hY2Ug
b2YgdGhlIA0KICAgIHJlc3BvbnNlIGdldHRpbmcgYmFjayB0aHJvdWdoIGFueSBpbnRlcnZlbmlu
ZyBmaXJld2FsbC48L1NQQU4+PC9GT05UPjwvRElWPg0KICAgIDxCTE9DS1FVT1RFIGRpcj1sdHIg
DQogICAgc3R5bGU9IkJPUkRFUi1MRUZUOiAjMDAwMGZmIDJweCBzb2xpZDsgTUFSR0lOLUxFRlQ6
IDVweDsgTUFSR0lOLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4Ij4NCiAgICAgIDxESVYg
YWxpZ249bGVmdCBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBkaXI9bHRyPjxGT05UIGZhY2U9
VGFob21hIA0KICAgICAgc2l6ZT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPjxCPkZy
b206PC9CPiBQYXVsIExvbmcgDQogICAgICBbbWFpbHRvOnBsb25nQGlwZGlhbG9nLmNvbV08QlI+
PEI+U2VudDo8L0I+IFRodXJzZGF5LCBNYXkgMTAsIDIwMDEgNTo0MCANCiAgICAgIFBNPEJSPjxC
PlRvOjwvQj4gbWVnYWNvPEJSPjxCPlN1YmplY3Q6PC9CPiBSRTogRnJvbSB3aGVuY2UgdGhleSAN
CiAgICAgIGNhbWU/PEJSPjxCUj48L0RJVj48L0ZPTlQ+DQogICAgICA8RElWPjxTUEFOIGNsYXNz
PTcwMDMxMzIyMS0xMDA1MjAwMT48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgDQogICAg
ICBzaXplPTI+VG9tLDwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgICA8RElWPjxTUEFOIGNsYXNz
PTcwMDMxMzIyMS0xMDA1MjAwMT48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgDQogICAg
ICBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+PFNQQU4gY2xh
c3M9NzAwMzEzMjIxLTEwMDUyMDAxPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCANCiAg
ICAgIHNpemU9Mj5Pa2F5LCB0aGVuLCBhbmQgdGhpcyBtYXkgYmUgYSBzdHVwaWQgcXVlc3Rpb24s
IGJ1dCB3aGF0IGlzIHRoZSANCiAgICAgIGRpZmZlcmVuY2UgYmV0d2VlbiAidGhlIHBlZXIgaW4g
YW4gYXNzb2NpYXRpb24iIGFuZCB0aGUgc291cmNlIG9mIGEgDQogICAgICBtZXNzYWdlPyBJT1cs
IHVuZGVyIHdoYXQgY2lyY3Vtc3RhbmNlcyBtaWdodCB0aGV5IGJlIGRpZmZlcmVudD8gVGhlIHJl
YXNvbiANCiAgICAgIEkgd2FzIGNvbmZ1c2VkIHdhcyBwcm9iYWJseSBiZWNhdXNlIGluJm5ic3A7
SC4zMjMmbmJzcDt0aGUgc291cmNlIG9mIGEgDQogICAgICBtZXNzYWdlIGlzIG9mIGFic29sdXRl
bHkgbm8gY29uc2VxdWVuY2UuPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICAgIDxESVY+PFNQQU4g
Y2xhc3M9NzAwMzEzMjIxLTEwMDUyMDAxPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCAN
CiAgICAgIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgICAgPERJVj48U1BB
TiBjbGFzcz03MDAzMTMyMjEtMTAwNTIwMDE+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFs
IA0KICAgICAgc2l6ZT0yPlBhdWwgTG9uZzwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgICA8RElW
PjxTUEFOIGNsYXNzPTcwMDMxMzIyMS0xMDA1MjAwMT48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9
QXJpYWwgDQogICAgICBzaXplPTI+aXBEaWFsb2csIA0KSW5jLjwvRk9OVD48L1NQQU4+PC9ESVY+
PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg0K


--0__=YWX0sfAHsLmUNEjW6eDVrGKKh1eaXgXXiII9eYqFQEJQ965pPIOAyMO5--



From owner-megaco@fore.com  Fri May 11 10:57:27 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12022
	for ; Fri, 11 May 2001 10:57:27 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23719;
	Fri, 11 May 2001 10:50:04 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA08433
	for megaco-list; Fri, 11 May 2001 10:47:18 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08384
	for ; Fri, 11 May 2001 10:47:15 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23066
	for ; Fri, 11 May 2001 10:47:07 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4BEl6dQ000179
	for ; Fri, 11 May 2001 09:47:06 -0500 (CDT)
From: "Paul Long" 
To: "megaco ietf" 
Subject: RE: Implementors' Guide Update Editor's last Call
Date: Fri, 11 May 2001 09:47:08 -0500
Message-ID: 
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)
Importance: Normal
In-Reply-To: <3AFB519F.D5407CE5@ericsson.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Christian,

Here are my responses to your comments.

Item 6.16: It won't hurt to leave those parentheses in, but they do not
change the syntax. ABNF concatenation has higher precendence (are
"stickier") than alternation so these two constructs express exactly the
same thing:
	digitMapRange        = ("x" /  LWSP "[" LWSP digitLetter LWSP "]" LWSP )
	digitMapRange        = ("x" / (LWSP "[" LWSP digitLetter LWSP "]" LWSP))
A good analogy are the addition and multiplication operators in C. In the
same way that the above expressions are equivalent, so are the following
expressions equivalent:
	X = A +  B * C * D * E;
	X = A + (B * C * D * E);
Notice that in addition to digitMapRange, the hexpart, alternativeValue,
digitMap, and EOL constructs all exploit this ABNF precedence rule. If you
believe that digitMapRange needs to be fixed, then these other constructs
also need to be fixed.

Here is the relevant text from RFC2234:
>>>>
3.10 Operator Precedence

   The various mechanisms described above have the following precedence,
   from highest (binding tightest) at the top, to lowest and loosest at
   the bottom:

        Strings, Names formation
        Comment
        Value range
        Repetition
        Grouping, Optional
        Concatenation
        Alternative
<<<<

Also, the outer parentheses around a rule definition may debatably improve
readability but are not required. Kinda bugs me that sometimes they are
used, sometimes they are not. Not a big deal but stylistically inconsistent.
This is the convention I'd personally like to see applied consistently
throughout the ABNF:
	digitMapRange        = "x" /  LWSP "[" LWSP digitLetter LWSP "]" LWSP


Item 6.58: Are we limiting the specification of a ServiceChangeAddress to
just UDP because it would be "too hard" to implement for TCP (a couple more
states in a state machine?) or because there is an inherent reason why it
only makes sense to use it with an unreliable channel? If the latter, let's
call it an "unreliable channel" and not "UDP," thus removing
transport-specific text from the spec; if the former, I'd recommend we
remove the limitation altogether and revert back to the original text.


Item 11.6: The problem I have with saying that "Parsers >>should<< accept
whitespace..." (emphasis mine) is that this appears to be backing off the
requirement in the ABNF that parsers _shall_ accept white space. See the
second LWSP, below? At best, this sounds funny; at worst, contradictory.
	localDescriptor      = LocalToken LBRKT octetString RBRKT
	LBRKT                = LWSP %x7B LWSP


(Re: "G'Day". Like, are you an Aussie or something? :-)

Paul Long
ipDialog, Inc.

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com]
Sent: Thursday, May 10, 2001 9:43 PM
To: Paul Long
Cc: megaco ietf; bharat@trillium.com
Subject: Re: Implementors' Guide Update Editor's last Call


G'Day Paul,

Please my comments below.

Cheers, Christian

Paul Long wrote:
>
> Christian,
>
> My comments:
>
> Item 6.16: Concatenation (e.g., A B) already takes precedence over the
> alternative operator (e.g., A / B), so the proposed parentheses are
> redundant. (See 3.10/RFC2234.) I guess it doesn't hurt to add them, but
this
> is technically a clarification and not a correction so it should go in
> section 7.

[CHG] Its not a clarification as it changes the syntax. As it was
already approved in the first IG I do not particular want to change it
was its not broken.

>
> Item 6.58: Inserting the text, "For UDP as a transport," precludes an MG
> that uses TCP from also using ServiceChangeAddress. Not that _I_ want to
do
> such a thing, but is this a necessary constraint? Was this intended?

[CHG] Bharat asked this to be added so he can answer you on this. I'm
quite happy to remove the "UDP as a transport" because I don't like
trying H.248/Megaco procedures to transports.

>
> Item 11.6: I know this is only clarifying text, but you should probably
> change "Parsers should accept whitespace..." to "Parsers shall accept
> whitespace..."
[CHG] Any complaints from ABNF gurus on this? Tom what's your call?

>
> Paul Long
> ipDialog, Inc.



From owner-megaco@fore.com  Fri May 11 11:03:58 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12291
	for ; Fri, 11 May 2001 11:03:58 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24702;
	Fri, 11 May 2001 10:57:51 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA11302
	for megaco-list; Fri, 11 May 2001 10:55:27 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11289
	for ; Fri, 11 May 2001 10:55:26 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24400
	for ; Fri, 11 May 2001 10:55:21 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4BEtLdQ004943
	for ; Fri, 11 May 2001 09:55:21 -0500 (CDT)
From: "Paul Long" 
To: "megaco" 
Subject: RE: From whence they came?
Date: Fri, 11 May 2001 09:55:22 -0500
Message-ID: 
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)
Importance: Normal
In-Reply-To: <65256A49.004F968B.00@sandesh.hss.hns.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Vivek,

Let Tom answer of course but, if I understand it correctly now, yes, only
use the mID to _logically identify_ the source of the message. Never treat
it like an IP address in any way. The mID is really only used to scope the
transaction identifiers. The only reason why IP addresses in particular are
allowed is apparently because they guarantee some uniqueness and not because
they provide the actual network location of the sender. It's just a
coincidence that they often (always? sometimes?) are the same as the actual
transport address from which the message was sent.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: vibansal@hss.hns.com [mailto:vibansal@hss.hns.com]
Sent: Friday, May 11, 2001 9:43 AM
To: Tom-PT Taylor
Cc: 'Paul Long'; megaco
Subject: RE: From whence they came?




Hello Tom,
     Does that mean that from a host with IP1 as the IP address, a Megaco
message
can be sent to the peer with an MId as IP2? Should the receiving entity not
compare the
source IP address and the IP address in the message header (assuming the mID
is
represented by IP address)?

Regards,
Vivek





"Tom-PT Taylor"  on 05/11/2001 06:13:14 PM

To:   "'Paul Long'" , megaco 
cc:    (bcc: Vivek Bansal/HSS)

Subject:  RE: From whence they came?




Basically, yes.  It's probably better to use a domain name rather than an
address as an mID tag.

-----Original Message-----
From: Paul Long [mailto:plong@ipdialog.com]
Sent: Thursday, May 10, 2001 8:28 PM
To: megaco
Subject: RE: From whence they came?


Tom,

Hmmm... Taking a closer look at the spec, I see that the mID in the message
prolog is just used by the receiver as a logical identifier for the sender
and that, in particular, the IP-address forms just have syntactical
value--they are never used as IP addresses, per se. It looks like these mIDs
are only used when paired up with transaction identifiers to uniquely
identify transactions, scoped to the receiver. Is this correct? Scary
thought, but, as long as the sender takes care by using an IP address that
another sender will not use, it appears that the IP address in a message mID
doesn't have to have any relationship to the actual network interface of the
sender. Am I right?

Paul Long
ipDialog, Inc.



From owner-megaco@fore.com  Fri May 11 11:50:27 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13621
	for ; Fri, 11 May 2001 11:50:27 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA02716;
	Fri, 11 May 2001 11:44:31 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA01399
	for megaco-list; Fri, 11 May 2001 11:41:31 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA01374
	for ; Fri, 11 May 2001 11:41:25 -0400 (EDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA01982
	for ; Fri, 11 May 2001 11:41:20 -0400 (EDT)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id KAA18709
	for ; Fri, 11 May 2001 10:41:13 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4BFf9T08297
	for ; Fri, 11 May 2001 10:41:09 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4BFew122875
	for ; Fri, 11 May 2001 10:40:59 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4BFexO10526
	for ; Fri, 11 May 2001 10:40:59 -0500 (CDT)
Message-ID: <3AFC080A.4494AE69@usa.alcatel.com>
Date: Fri, 11 May 2001 10:40:59 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: FW: SDP fmtp parameters
References: <28560036253BD41191A10000F8BCBD110250C7D0@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------D362AFC91F8CE41660F79801"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------D362AFC91F8CE41660F79801
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id LAA02716
Content-Transfer-Encoding: quoted-printable


ZhouZichun

The example is not entirely correct.
 It is describing a TDM termination setting but trying to use RTP SDP
which is not
meant to describe TDM setting.

But to focus just on what "VAD=3DX-NNVAD" means.
I think it is trying to say that if voice is detected (VAD), do whatever
the experimental (X-)
NNVAD is defined to do.

Also "a=3Dfmtp:PCMU" is incorrect.
Probably should be something like "a=3Dfmtp:0"


Chuong

Tom-PT Taylor wrote:

> Forwarded to the official Megaco list, now moved to Megaco@fore.com.
>
> -----Original Message-----
> From: zhzc@yahoo.com.cn [mailto:zhzc@yahoo.com.cn]
> Sent: Thursday, March 15, 2001 4:03 AM
> To: MEGACO@marvin.corpeast.baynetworks.com
> Subject: SDP fmtp parameters
>
> Hi,
>     There is a parameter 'VAD=3DX-NNVAD' in MEGACO
> example:
>
>  Local {
>         v=3D0
>         c=3DIN IP4 $
>         m=3Daudio $ RTP/AVP 0
>         a=3Dfmtp:PCMU VAD=3DX-NNVAD;special voice activity
>                            ; detection algorithm
>       }
>
>    The SDP tells us the option after 'fmtp' is  specific parameter>. Unfortunately I cann't find the
> way to explain it. I searched it through Internet,
> only the MEGACO was found which use the string
> 'VAD=3DX-NNVAD'.
>    Anybody telling me will deserve my deeply
> appreciate.
>    Thanks!
>
>    ZhouZichun
>
> _________________________________________________________
> Do You Yahoo!? =B5=C7=C2=BC=C3=E2=B7=D1=D1=C5=BB=A2=B5=E7=D3=CA! http:/=
/mail.yahoo.com.cn
> =B4=B4=BD=A8=D1=C5=BB=A2=BE=E3=C0=D6=B2=BF=A3=AC=D5=E6=CE=D2=B8=F6=D0=D4=
=BE=A1=CA=A9=D5=B9=A3=A1http://cn.clubs.yahoo.com

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------D362AFC91F8CE41660F79801
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

ZhouZichun

The example is not entirely correct.

 It is describing a TDM termination setting but trying to
use RTP SDP which is not

meant to describe TDM setting.

But to focus just on what "VAD=X-NNVAD" means.

I think it is trying to say that if voice is detected (VAD), do
whatever the experimental (X-)

NNVAD is defined to do.

Also "a=fmtp:PCMU" is incorrect.

Probably should be something like "a=fmtp:0"

 

Chuong

Tom-PT Taylor wrote:

Forwarded to the official Megaco list, now moved
to Megaco@fore.com.

-----Original Message-----

From: zhzc@yahoo.com.cn [mailto:zhzc@yahoo.com.cn]

Sent: Thursday, March 15, 2001 4:03 AM

To: MEGACO@marvin.corpeast.baynetworks.com

Subject: SDP fmtp parameters

Hi,

    There is a parameter 'VAD=X-NNVAD' in MEGACO

example:

 Local {

        v=0

        c=IN IP4 $

        m=audio $ RTP/AVP 0

        a=fmtp:PCMU VAD=X-NNVAD;special
voice activity

                          
; detection algorithm

      }

   The SDP tells us the option after 'fmtp' is <format

specific parameter>. Unfortunately I cann't find the

way to explain it. I searched it through Internet,

only the MEGACO was found which use the string

'VAD=X-NNVAD'.

   Anybody telling me will deserve my deeply

appreciate.

   Thanks!

   ZhouZichun

_________________________________________________________

Do You Yahoo!? µÇ¼Ãâ·ÑÑÅ»¢µçÓÊ!
http://mail.yahoo.com.cn

´´½¨ÑÅ»¢¾ãÀÖ²¿£¬ÕæÎÒ¸öÐÔ¾¡Ê©Õ¹£¡http://cn.clubs.yahoo.com



-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------D362AFC91F8CE41660F79801--



From owner-megaco@fore.com  Fri May 11 12:07:32 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14197
	for ; Fri, 11 May 2001 12:07:32 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA05712;
	Fri, 11 May 2001 12:00:16 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA07672
	for megaco-list; Fri, 11 May 2001 11:57:15 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA07654
	for ; Fri, 11 May 2001 11:57:13 -0400 (EDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA05081
	for ; Fri, 11 May 2001 11:57:09 -0400 (EDT)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id KAA16372
	for ; Fri, 11 May 2001 10:57:11 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4BFvAT13959
	for ; Fri, 11 May 2001 10:57:10 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4BFul124878
	for ; Fri, 11 May 2001 10:56:47 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4BFumO10537
	for ; Fri, 11 May 2001 10:56:48 -0500 (CDT)
Message-ID: <3AFC0BBF.381AD419@usa.alcatel.com>
Date: Fri, 11 May 2001 10:56:47 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Service change method query
References: <000901c0cd8c$c4ae32c0$c500a8c0@MBRAHMANAPALLY>
Content-Type: multipart/alternative;
 boundary="------------F372A60F77BFCADAE0726EF0"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------F372A60F77BFCADAE0726EF0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


There is another difference why Handoff should be used instead of Restart by
the MG
when MG tries to connect to the new MGC.

I think the intend was to let the new MGC knows that MG stills has calls in
contexts.
Therefore either new MGC does an Audit towards MG to rebuild all necessary
info about MG or use either SIP, SIP-T, BICC, gods know what to get whatever
info it needs from old MGC before it goes out of service.

Chuong


Madhu Babu Brahmanapally wrote:

> HI Vivek,
>
> In page 57, First paragraph, its mentioned that the MGC may return a
> ServiceChangeMgcId describing the MGC to be contacted. It is also mentioned
> that MG will "REISSUE" the service change command to the new MGC specified.
> Hence, the service Change method to be used should be  "restart" only. This
> shouldn't be treated as a handoff initiated by the MGC. The MG is just
> retrying the same registration with the new MGC.
>
> Handoff is used by MGC when the it is going out of service. When the MG
> attempts to establish a new association with the newly specified MGC it uses
> the Handoff method.
>
> Regards
> Madhubabu
>
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of
> vibansal@hss.hns.com
> Sent: Tuesday, April 24, 2001 8:23 AM
> To: megaco@fore.com
> Subject: Service change method query
>
> Hi All
>
> In the first service change request from MG, if the MGC replies with the
> MGCidtotry, then with what service change method and reason does MG send the
> request to new MGC?
>
> There could be two possibilities:
> 1. Since this is same as a Handoff scenario, MG can use Handoff method.
> 2. Since it was the first registration request, MG can use Restart method.
>
> Kindly clearify this.
>
> Regards
> Vivek Bansal
> Hughes Software System

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------F372A60F77BFCADAE0726EF0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

There is another difference why Handoff should be used instead of Restart
by the MG

when MG tries to connect to the new MGC.

I think the intend was to let the new MGC knows that MG stills
has calls in contexts.

Therefore either new MGC does an Audit towards MG to rebuild all necessary

info about MG or use either SIP, SIP-T, BICC, gods know what to get
whatever

info it needs from old MGC before it goes out of service.

Chuong

 

Madhu Babu Brahmanapally wrote:

HI Vivek,

In page 57, First paragraph, its mentioned that the MGC may return a

ServiceChangeMgcId describing the MGC to be contacted. It is also mentioned

that MG will "REISSUE" the service change command to the new MGC specified.

Hence, the service Change method to be used should be  "restart"
only. This

shouldn't be treated as a handoff initiated by the MGC. The MG is just

retrying the same registration with the new MGC.

Handoff is used by MGC when the it is going out of service. When the
MG

attempts to establish a new association with the newly specified MGC
it uses

the Handoff method.

Regards

Madhubabu

-----Original Message-----

From: owner-megaco@pit.comms.marconi.com

[mailto:owner-megaco@pit.comms.marconi.com]On
Behalf Of

vibansal@hss.hns.com

Sent: Tuesday, April 24, 2001 8:23 AM

To: megaco@fore.com

Subject: Service change method query

Hi All

In the first service change request from MG, if the MGC replies with
the

MGCidtotry, then with what service change method and reason does MG
send the

request to new MGC?

There could be two possibilities:

1. Since this is same as a Handoff scenario, MG can use Handoff method.

2. Since it was the first registration request, MG can use Restart
method.

Kindly clearify this.

Regards

Vivek Bansal

Hughes Software System



-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------F372A60F77BFCADAE0726EF0--



From owner-megaco@fore.com  Fri May 11 12:37:10 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14915
	for ; Fri, 11 May 2001 12:37:09 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA10757;
	Fri, 11 May 2001 12:29:47 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA18681
	for megaco-list; Fri, 11 May 2001 12:26:52 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA18661
	for ; Fri, 11 May 2001 12:26:49 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id MAA10177
	for ; Fri, 11 May 2001 12:26:44 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id MAA22168; Fri, 11 May 2001 12:26:41 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 11 May 2001 12:26:37 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 11 May 2001 12:26:40 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB1B@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'vibansal@hss.hns.com'" 
Cc: "'Paul Long'" , megaco 
Subject: RE: From whence they came?
Date: Fri, 11 May 2001 12:26:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DA37.26B7A580"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DA37.26B7A580
Content-Type: text/plain;
	charset="ISO-8859-1"

It's a matter of historical development of our understanding of mID,
perhaps, but your example is correct.  There should be no comparison of
actual source with mID.  Your example could have arisen because of a
behind-the-scenes (invisible to the MGC) hot switchover from one MG to its
mate, or because a cluster of physical devices are sharing the load of one
control session, or because the host has multiple network interfaces or ...

> -----Original Message-----
> From: vibansal@hss.hns.com [mailto:vibansal@hss.hns.com]
> Sent: Friday, May 11, 2001 10:43 AM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]
> Cc: 'Paul Long'; megaco
> Subject: RE: From whence they came?
> 
> 
> 
> 
> Hello Tom,
>      Does that mean that from a host with IP1 as the IP 
> address, a Megaco
> message
> can be sent to the peer with an MId as IP2? Should the 
> receiving entity not
> compare the
> source IP address and the IP address in the message header 
> (assuming the mID is
> represented by IP address)?
> 
> Regards,
> Vivek
> 
> 
> 
> 
> 
> "Tom-PT Taylor"  on 05/11/2001 06:13:14 PM
> 
> To:   "'Paul Long'" , megaco 
> cc:    (bcc: Vivek Bansal/HSS)
> 
> Subject:  RE: From whence they came?
> 
> 
> 
> 
> Basically, yes.  It's probably better to use a domain name 
> rather than an
> address as an mID tag.
> 
> -----Original Message-----
> From: Paul Long [mailto:plong@ipdialog.com]
> Sent: Thursday, May 10, 2001 8:28 PM
> To: megaco
> Subject: RE: From whence they came?
> 
> 
> Tom,
> 
> Hmmm... Taking a closer look at the spec, I see that the mID 
> in the message
> prolog is just used by the receiver as a logical identifier 
> for the sender
> and that, in particular, the IP-address forms just have syntactical
> value--they are never used as IP addresses, per se. It looks 
> like these mIDs
> are only used when paired up with transaction identifiers to uniquely
> identify transactions, scoped to the receiver. Is this correct? Scary
> thought, but, as long as the sender takes care by using an IP 
> address that
> another sender will not use, it appears that the IP address 
> in a message mID
> doesn't have to have any relationship to the actual network 
> interface of the
> sender. Am I right?
> 
> Paul Long
> ipDialog, Inc.
> 
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Thursday, May 10, 2001 5:56 PM
> To: 'Paul Long'; megaco
> Subject: RE: From whence they came?
> 
> 
> It's partly the difference between a physical and a logical unit in a
> load-sharing architecture where the separate units have 
> different addresses.
> There's also the possibility that a single physical unit has multiple
> network interfaces.  Using the address as received in the header is
> important because it gives a beter chnace of the response getting back
> through any intervening firewall.
> 
> -----Original Message-----
> From: Paul Long [mailto:plong@ipdialog.com]
> Sent: Thursday, May 10, 2001 5:40 PM
> To: megaco
> Subject: RE: From whence they came?
> 
> 
> Tom,
> 
> Okay, then, and this may be a stupid question, but what is 
> the difference
> between "the peer in an association" and the source of a 
> message? IOW, under
> what circumstances might they be different? The reason I was 
> confused was
> probably because in H.323 the source of a message is of absolutely no
> consequence.
> 
> Paul Long
> ipDialog, Inc.
> 
> 
> 

------_=_NextPart_001_01C0DA37.26B7A580
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: From whence they came?




It's a matter of historical development of our =
understanding of mID, perhaps, but your example is correct.  There =
should be no comparison of actual source with mID.  Your example =
could have arisen because of a behind-the-scenes (invisible to the MGC) =
hot switchover from one MG to its mate, or because a cluster of =
physical devices are sharing the load of one control session, or =
because the host has multiple network interfaces or ...



> -----Original Message-----

> From: vibansal@hss.hns.com [mailto:vibansal@hss.hns.com]

> Sent: Friday, May 11, 2001 10:43 AM

> To: Taylor, Tom-PT [NORSE:B881:EXCH]

> Cc: 'Paul Long'; megaco

> Subject: RE: From whence they came?

> 

> 

> 

> 

> Hello Tom,

>      Does that mean =
that from a host with IP1 as the IP 

> address, a Megaco

> message

> can be sent to the peer with an MId as IP2? =
Should the 

> receiving entity not

> compare the

> source IP address and the IP address in the =
message header 

> (assuming the mID is

> represented by IP address)?

> 

> Regards,

> Vivek

> 

> 

> 

> 

> 

> "Tom-PT Taylor" =
<taylor@nortelnetworks.com> on 05/11/2001 06:13:14 PM

> 

> To:   "'Paul Long'" =
<plong@ipdialog.com>, megaco <megaco@fore.com>

> cc:    (bcc: Vivek =
Bansal/HSS)

> 

> Subject:  RE: From whence they =
came?

> 

> 

> 

> 

> Basically, yes.  It's probably better to =
use a domain name 

> rather than an

> address as an mID tag.

> 

> -----Original Message-----

> From: Paul Long [mailto:plong@ipdialog.com]=


> Sent: Thursday, May 10, 2001 8:28 PM

> To: megaco

> Subject: RE: From whence they came?

> 

> 

> Tom,

> 

> Hmmm... Taking a closer look at the spec, I see =
that the mID 

> in the message

> prolog is just used by the receiver as a =
logical identifier 

> for the sender

> and that, in particular, the IP-address forms =
just have syntactical

> value--they are never used as IP addresses, per =
se. It looks 

> like these mIDs

> are only used when paired up with transaction =
identifiers to uniquely

> identify transactions, scoped to the receiver. =
Is this correct? Scary

> thought, but, as long as the sender takes care =
by using an IP 

> address that

> another sender will not use, it appears that =
the IP address 

> in a message mID

> doesn't have to have any relationship to the =
actual network 

> interface of the

> sender. Am I right?

> 

> Paul Long

> ipDialog, Inc.

> 

> -----Original Message-----

> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c=
om]

> Sent: Thursday, May 10, 2001 5:56 PM

> To: 'Paul Long'; megaco

> Subject: RE: From whence they came?

> 

> 

> It's partly the difference between a physical =
and a logical unit in a

> load-sharing architecture where the separate =
units have 

> different addresses.

> There's also the possibility that a single =
physical unit has multiple

> network interfaces.  Using the address as =
received in the header is

> important because it gives a beter chnace of =
the response getting back

> through any intervening firewall.

> 

> -----Original Message-----

> From: Paul Long [mailto:plong@ipdialog.com]=


> Sent: Thursday, May 10, 2001 5:40 PM

> To: megaco

> Subject: RE: From whence they came?

> 

> 

> Tom,

> 

> Okay, then, and this may be a stupid question, =
but what is 

> the difference

> between "the peer in an association" =
and the source of a 

> message? IOW, under

> what circumstances might they be different? The =
reason I was 

> confused was

> probably because in H.323 the source of a =
message is of absolutely no

> consequence.

> 

> Paul Long

> ipDialog, Inc.

> 

> 

> 





------_=_NextPart_001_01C0DA37.26B7A580--


From owner-megaco@fore.com  Fri May 11 12:51:13 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15241
	for ; Fri, 11 May 2001 12:51:13 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA13329;
	Fri, 11 May 2001 12:45:16 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA23451
	for megaco-list; Fri, 11 May 2001 12:40:33 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA23447
	for ; Fri, 11 May 2001 12:40:32 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id MAA12497
	for ; Fri, 11 May 2001 12:40:28 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id MAA23212; Fri, 11 May 2001 12:40:25 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 11 May 2001 12:40:16 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 11 May 2001 12:40:19 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB1D@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Chuong Nguyen'" , megaco@fore.com
Subject: RE: Service change method query
Date: Fri, 11 May 2001 12:40:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DA39.0DADAA10"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DA39.0DADAA10
Content-Type: text/plain;
	charset="ISO-8859-1"

But Madhu makes the valid point that this is an initial registration attempt
by the MG which has been redirected by the first MGC it tried.  The MG
doesn't necessarily have any calls in progress.

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Friday, May 11, 2001 11:57 AM
To: megaco@fore.com
Subject: Re: Service change method query


  
There is another difference why Handoff should be used instead of Restart by
the MG 
when MG tries to connect to the new MGC. 

I think the intend was to let the new MGC knows that MG stills has calls in
contexts. 
Therefore either new MGC does an Audit towards MG to rebuild all necessary 
info about MG or use either SIP, SIP-T, BICC, gods know what to get whatever

info it needs from old MGC before it goes out of service. 


Chuong 
  


Madhu Babu Brahmanapally wrote: 


HI Vivek, 

In page 57, First paragraph, its mentioned that the MGC may return a 
ServiceChangeMgcId describing the MGC to be contacted. It is also mentioned 
that MG will "REISSUE" the service change command to the new MGC specified. 
Hence, the service Change method to be used should be  "restart" only. This 
shouldn't be treated as a handoff initiated by the MGC. The MG is just 
retrying the same registration with the new MGC. 


Handoff is used by MGC when the it is going out of service. When the MG 
attempts to establish a new association with the newly specified MGC it uses

the Handoff method. 


Regards 
Madhubabu 


-----Original Message----- 
From: owner-megaco@pit.comms.marconi.com 
[ mailto:owner-megaco@pit.comms.marconi.com
 ]On Behalf Of 
vibansal@hss.hns.com 
Sent: Tuesday, April 24, 2001 8:23 AM 
To: megaco@fore.com 
Subject: Service change method query 


Hi All 


In the first service change request from MG, if the MGC replies with the 
MGCidtotry, then with what service change method and reason does MG send the

request to new MGC? 


There could be two possibilities: 
1. Since this is same as a Handoff scenario, MG can use Handoff method. 
2. Since it was the first registration request, MG can use Restart method. 


Kindly clearify this. 


Regards 
Vivek Bansal 
Hughes Software System

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


------_=_NextPart_001_01C0DA39.0DADAA10
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable









But=20
Madhu makes the valid point that this is an initial registration =
attempt by the=20
MG which has been redirected by the first MGC it tried.  The MG =
doesn't=20
necessarily have any calls in progress.


  
-----Original Message-----
From: Chuong Nguyen=20
  [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Friday, May =
11, 2001=20
  11:57 AM
To: megaco@fore.com
Subject: Re: Service =
change=20
  method query

  
There is another =
difference why=20
  Handoff should be used instead of Restart by the MG 
when MG tries =
to=20
  connect to the new MGC.=20
  
I think the intend was to let the new MGC knows that MG =
stills has=20
  calls in contexts. 
Therefore either new MGC does an Audit towards =
MG to=20
  rebuild all necessary 
info about MG or use either SIP, SIP-T, =
BICC, gods=20
  know what to get whatever 
info it needs from old MGC before it =
goes out of=20
  service.=20
  
Chuong 
 =20
  
Madhu Babu Brahmanapally wrote:=20
  
HI Vivek,=20
    
In page 57, First paragraph, its mentioned that the MGC may =
return a=20
    
ServiceChangeMgcId describing the MGC to be contacted. It is =
also=20
    mentioned 
that MG will "REISSUE" the service change command to =
the new=20
    MGC specified. 
Hence, the service Change method to be used =
should=20
    be  "restart" only. This 
shouldn't be treated as a handoff =

    initiated by the MGC. The MG is just 
retrying the same =
registration with=20
    the new MGC.=20
    
Handoff is used by MGC when the it is going out of service. When =
the MG=20
    
attempts to establish a new association with the newly =
specified MGC it=20
    uses 
the Handoff method.=20
    
Regards 
Madhubabu=20
    
-----Original Message----- 
From: =
owner-megaco@pit.comms.marconi.com=20
    
[mailto:owner-megaco@p=
it.comms.marconi.com]On=20
    Behalf Of 
vibansal@hss.hns.com 
Sent: Tuesday, April 24, =
2001 8:23 AM=20
    
To: megaco@fore.com 
Subject: Service change method query=20
    
Hi All=20
    
In the first service change request from MG, if the MGC replies =
with the=20
    
MGCidtotry, then with what service change method and reason =
does MG send=20
    the 
request to new MGC?=20
    
There could be two possibilities: 
1. Since this is same as a =
Handoff=20
    scenario, MG can use Handoff method. 
2. Since it was the first=20
    registration request, MG can use Restart method.=20
    
Kindly clearify this.=20
    
Regards 
Vivek Bansal 
Hughes Software =
System
-- 
  Alcatel USA, =
Inc           &nb=
sp; Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas =
75075           =
Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc =
****
 =20


------_=_NextPart_001_01C0DA39.0DADAA10--


From owner-megaco@fore.com  Fri May 11 13:11:29 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15688
	for ; Fri, 11 May 2001 13:11:29 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA15249;
	Fri, 11 May 2001 13:00:52 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA29009
	for megaco-list; Fri, 11 May 2001 12:58:04 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA28971
	for ; Fri, 11 May 2001 12:57:31 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id MAA14635
	for ; Fri, 11 May 2001 12:57:26 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id MAA24560; Fri, 11 May 2001 12:57:19 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 11 May 2001 12:57:06 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 11 May 2001 12:57:09 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB1E@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Troy Cauble'" 
Cc: "'Rosen, Brian'" , "'megaco'" 
Subject: RE: Annex C Descriptor Assignments
Date: Fri, 11 May 2001 12:57:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DA3B.658FC360"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DA3B.658FC360
Content-Type: text/plain;
	charset="ISO-8859-1"

It looks like I should completely rewrite my contribution to express exactly
this.  Any other comments?  (Christian may be in the air already, in which
case I'll talk to him in Geneva next week.)

> -----Original Message-----
> From: Troy Cauble [mailto:troy@lucent.com]
> Sent: Friday, May 11, 2001 10:30 AM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]
> Cc: 'Rosen, Brian'; 'megaco'
> Subject: Re: Annex C Descriptor Assignments
> 
> 
> 
> Yes!
> 
> Annex C  -- binary only -- LD & RD only.
> SDP -- text only -- LD & RD only.
> Packages -- binary AND text -- NOT in LD & RD.
> 
> It's great that Tom found so few exceptions.  
> That makes it feasible to move them out into 
> packages.
> 
> I would like to drop the "Package 0" terminology though.
> The word "package" implies many things that Annex C is not.
> 
> -troy
> 
> 
> > Tom-PT Taylor wrote:
> > 
> > Given my findings, I would agree with you.  Let's see what 
> other people have
> > to say.
> > 
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > Sent: Friday, May 11, 2001 9:58 AM
> > > To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'megaco'
> > > Subject: RE: Annex C Descriptor Assignments
> > >
> > >
> > > Before we deal with the details of this, I question the premise:
> > >   I think that Annex C ONLY is used in
> > >       binary encoding  and
> > >       in local and remote (NOT localControl or TerminationState)
> > > I think the I-G might state that better.
> > > I think that if there are some things that don't belong in remote
> > >   and local, they should be removed and possibly made part of
> > > a package,
> > >   because you don't use Annex C in LocalControl
> > >
> > > Brian
> > >
> > >
> > >
> > >
> > >
> > > Here is the contribution to SG 16 I've drafted on the subject
> > > of descript=
> > > or
> > > assignments for the Annex C properties.
> > >
> > > TITLE:        Descriptors For Megaco/H.248 Annex C Properties
> > > ___________________
> > >
> > >
> > > INTRODUCTION
> > >
> > > Megaco/H.248 Annex C defines a set of properties relating to
> > > media stream=
> > > s.
> > > As such, these properties may appear:
> > > =B7   in the LocalControl descriptor, if they are local
> > > interest only, or
> > > =B7   in the Local and Remote descriptors, if they must 
> be coordinated
> > > between the local and remote Media Gateways.
> > >
> > > Megaco/H.248 Annex C currently fails to indicate which
> > > alternative applie=
> > > s
> > > to each of the properties specified within the Annex.  This
> > > contribution
> > > argues that the H.248 Implementor's Guide should be updated
> > > to reflect su=
> > > ch
> > > an assignment.  The contribution goes on to derive principles
> > > for making =
> > > the
> > > assignment decision, and then applies those principles to
> > > derive a detail=
> > > ed
> > > set of  descriptor assignments for all of the properties 
> in the Annex.
> > >
> > > =20
> > >
> > > NEED FOR A STANDARDIZED PROPERTY ASSIGNMENT
> > >
> > > This section presents a semantic and a syntactic argument for
> > > standardizi=
> > > ng
> > > the assignment of properties to descriptors in Annex C.  At
> > > the semantic
> > > level, it is essential that the assignment to descriptors be
> > > the same for=
> > >  a
> > > given property, regardless of the H.248 protocol encoding.
> > > Otherwise one
> > > encounters a semantic mismatch between encodings, such that
> > > with respect =
> > > to
> > > a given property asymmetric flow descriptions are possible in
> > > one encodin=
> > > g
> > > and not the other.  Such a mismatch may be introduced by
> > > general usage or=
> > >  by
> > > explicit adoption of Annex C properties in standards created
> > > by bodies ot=
> > > her
> > > than the IETF Megaco Working Group or Study Group 16.
> > >
> > > At the syntactic level, assignment of specific properties 
> to specific
> > > descriptors simplifies parser construction by adding 
> predictability to
> > > message construction.
> > > A final argument in favour of adding explicit descriptor
> > > assignments is t=
> > > hat
> > > Annex C, as "Package 0", should conform as much as possible to the
> > > documentation rules for packages.  This includes 
> documentation of the
> > > descriptor to which each property should be assigned.
> > >
> > > ASSIGNMENT PRINCIPLES
> > > =20
> > > The basic criterion for descriptor assignment was indicated in the
> > > introduction: whether or not the property concerned must be
> > > coordinated w=
> > > ith
> > > the remote Media Gateway.
> > > However, some borderline cases will require the use of
> > > subsidiary criteri=
> > > a.
> > > The first such criterion was suggested in the previous
> > > section: assurance
> > > that the assignment is the same for both text and binary (Annex C)
> > > encodings.  Because the text encoding for the Local and
> > > Remote descriptor=
> > > s
> > > is tied to SDP (RFC 2327), this means that at the very least
> > > the mandator=
> > > y
> > > properties found in RFC 2327 should  be assigned to the Local
> > > and Remote
> > > descriptors rather than LocalControl.  Properties which are
> > > optional in S=
> > > DP
> > > may be placed in LocalControl if this makes sense, but the
> > > assignment mus=
> > > t
> > > be the same in both the text and the binary encodings.
> > >
> > > There is a further possible criterion: is there a potential
> > > requirement  =
> > > for
> > > a given property to have a different value for each direction
> > > of flow, an=
> > > d
> > > will it be technically feasible to meet that requirement? 
>  If so, the
> > > property should be assigned to Local/Remote rather than 
> LocalControl.
> > >
> > > DETAILED ASSIGNMENTS
> > >
> > > The following table proposes detailed assignments for the Annex C
> > > properties.  The "Remarks" column indicates criteria used 
> where the
> > > assignment was not immediately obvious.
> > >
> > > [Rather than repeat the tables, let me summarize by 
> saying that almost
> > > everything goes into Local/Remote.  Here are the 
> exceptional cases:
> > >
> > > Table C.1: Transmission mode (tag 1002) should perhaps be
> > > deprecated beca=
> > > use
> > > the Mode property in LocalControl carries the same
> > > information.  This is
> > > equivalent to saying that the SDP in Local and Remote should
> > > not include =
> > > any
> > > of the directionality attributes.  People may want to comment.
> > >
> > > Table C.1: Gain (tag 100C) and Jitterbuff (tag 100D) are placed in
> > > LocalControl (of local interest only)
> > >
> > > Table C.9: Modem (tag 901B) goes into the Modem Descriptor.
> > > Actually it
> > > should be deprecated because the necessary codepoints have
> > > already been
> > > defined in the Modem descriptor.
> > >
> > > Table C.9: DialledN (tag 901F) and DiallingN (tag 9020) go
> > > into LocalCont=
> > > rol
> > > because they do not require end-to-end coordination at the
> > > media level.]
> > >
> > > Tom Taylor
> > > Multimedia Control and Applications Standards
> > > Ph.  +1 613 736 0961
> > > taylor@nortelnetworks.com=20
> > >
> 

------_=_NextPart_001_01C0DA3B.658FC360
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Annex C Descriptor Assignments




It looks like I should completely rewrite my =
contribution to express exactly this.  Any other comments?  =
(Christian may be in the air already, in which case I'll talk to him in =
Geneva next week.)



> -----Original Message-----

> From: Troy Cauble [mailto:troy@lucent.com]

> Sent: Friday, May 11, 2001 10:30 AM

> To: Taylor, Tom-PT [NORSE:B881:EXCH]

> Cc: 'Rosen, Brian'; 'megaco'

> Subject: Re: Annex C Descriptor =
Assignments

> 

> 

> 

> Yes!

> 

> Annex C  -- binary only -- LD & RD =
only.

> SDP -- text only -- LD & RD only.

> Packages -- binary AND text -- NOT in LD & =
RD.

> 

> It's great that Tom found so few =
exceptions.  

> That makes it feasible to move them out into =


> packages.

> 

> I would like to drop the "Package 0" =
terminology though.

> The word "package" implies many =
things that Annex C is not.

> 

> -troy

> 

> 

> > Tom-PT Taylor wrote:

> > 

> > Given my findings, I would agree with =
you.  Let's see what 

> other people have

> > to say.

> > 

> > > -----Original Message-----

> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]

> > > Sent: Friday, May 11, 2001 9:58 =
AM

> > > To: Taylor, Tom-PT [NORSE:B881:EXCH]; =
'megaco'

> > > Subject: RE: Annex C Descriptor =
Assignments

> > >

> > >

> > > Before we deal with the details of =
this, I question the premise:

> > >   I think that Annex C ONLY =
is used in

> > >       =
binary encoding  and

> > >       =
in local and remote (NOT localControl or TerminationState)

> > > I think the I-G might state that =
better.

> > > I think that if there are some things =
that don't belong in remote

> > >   and local, they should be =
removed and possibly made part of

> > > a package,

> > >   because you don't use =
Annex C in LocalControl

> > >

> > > Brian

> > >

> > >

> > >

> > >

> > >

> > > Here is the contribution to SG 16 =
I've drafted on the subject

> > > of descript=3D

> > > or

> > > assignments for the Annex C =
properties.

> > >

> > > =
TITLE:        Descriptors For =
Megaco/H.248 Annex C Properties

> > > ___________________

> > >

> > >

> > > INTRODUCTION

> > >

> > > Megaco/H.248 Annex C defines a set of =
properties relating to

> > > media stream=3D

> > > s.

> > > As such, these properties may =
appear:

> > > =3DB7   in the LocalControl =
descriptor, if they are local

> > > interest only, or

> > > =3DB7   in the Local and =
Remote descriptors, if they must 

> be coordinated

> > > between the local and remote Media =
Gateways.

> > >

> > > Megaco/H.248 Annex C currently fails =
to indicate which

> > > alternative applie=3D

> > > s

> > > to each of the properties specified =
within the Annex.  This

> > > contribution

> > > argues that the H.248 Implementor's =
Guide should be updated

> > > to reflect su=3D

> > > ch

> > > an assignment.  The contribution =
goes on to derive principles

> > > for making =3D

> > > the

> > > assignment decision, and then applies =
those principles to

> > > derive a detail=3D

> > > ed

> > > set of  descriptor assignments =
for all of the properties 

> in the Annex.

> > >

> > > =3D20

> > >

> > > NEED FOR A STANDARDIZED PROPERTY =
ASSIGNMENT

> > >

> > > This section presents a semantic and =
a syntactic argument for

> > > standardizi=3D

> > > ng

> > > the assignment of properties to =
descriptors in Annex C.  At

> > > the semantic

> > > level, it is essential that the =
assignment to descriptors be

> > > the same for=3D

> > >  a

> > > given property, regardless of the =
H.248 protocol encoding.

> > > Otherwise one

> > > encounters a semantic mismatch =
between encodings, such that

> > > with respect =3D

> > > to

> > > a given property asymmetric flow =
descriptions are possible in

> > > one encodin=3D

> > > g

> > > and not the other.  Such a =
mismatch may be introduced by

> > > general usage or=3D

> > >  by

> > > explicit adoption of Annex C =
properties in standards created

> > > by bodies ot=3D

> > > her

> > > than the IETF Megaco Working Group or =
Study Group 16.

> > >

> > > At the syntactic level, assignment of =
specific properties 

> to specific

> > > descriptors simplifies parser =
construction by adding 

> predictability to

> > > message construction.

> > > A final argument in favour of adding =
explicit descriptor

> > > assignments is t=3D

> > > hat

> > > Annex C, as "Package 0", =
should conform as much as possible to the

> > > documentation rules for =
packages.  This includes 

> documentation of the

> > > descriptor to which each property =
should be assigned.

> > >

> > > ASSIGNMENT PRINCIPLES

> > > =3D20

> > > The basic criterion for descriptor =
assignment was indicated in the

> > > introduction: whether or not the =
property concerned must be

> > > coordinated w=3D

> > > ith

> > > the remote Media Gateway.

> > > However, some borderline cases will =
require the use of

> > > subsidiary criteri=3D

> > > a.

> > > The first such criterion was =
suggested in the previous

> > > section: assurance

> > > that the assignment is the same for =
both text and binary (Annex C)

> > > encodings.  Because the text =
encoding for the Local and

> > > Remote descriptor=3D

> > > s

> > > is tied to SDP (RFC 2327), this means =
that at the very least

> > > the mandator=3D

> > > y

> > > properties found in RFC 2327 =
should  be assigned to the Local

> > > and Remote

> > > descriptors rather than =
LocalControl.  Properties which are

> > > optional in S=3D

> > > DP

> > > may be placed in LocalControl if this =
makes sense, but the

> > > assignment mus=3D

> > > t

> > > be the same in both the text and the =
binary encodings.

> > >

> > > There is a further possible =
criterion: is there a potential

> > > requirement  =3D

> > > for

> > > a given property to have a different =
value for each direction

> > > of flow, an=3D

> > > d

> > > will it be technically feasible to =
meet that requirement? 

>  If so, the

> > > property should be assigned to =
Local/Remote rather than 

> LocalControl.

> > >

> > > DETAILED ASSIGNMENTS

> > >

> > > The following table proposes detailed =
assignments for the Annex C

> > > properties.  The =
"Remarks" column indicates criteria used 

> where the

> > > assignment was not immediately =
obvious.

> > >

> > > [Rather than repeat the tables, let =
me summarize by 

> saying that almost

> > > everything goes into =
Local/Remote.  Here are the 

> exceptional cases:

> > >

> > > Table C.1: Transmission mode (tag =
1002) should perhaps be

> > > deprecated beca=3D

> > > use

> > > the Mode property in LocalControl =
carries the same

> > > information.  This is

> > > equivalent to saying that the SDP in =
Local and Remote should

> > > not include =3D

> > > any

> > > of the directionality =
attributes.  People may want to comment.

> > >

> > > Table C.1: Gain (tag 100C) and =
Jitterbuff (tag 100D) are placed in

> > > LocalControl (of local interest =
only)

> > >

> > > Table C.9: Modem (tag 901B) goes into =
the Modem Descriptor.

> > > Actually it

> > > should be deprecated because the =
necessary codepoints have

> > > already been

> > > defined in the Modem =
descriptor.

> > >

> > > Table C.9: DialledN (tag 901F) and =
DiallingN (tag 9020) go

> > > into LocalCont=3D

> > > rol

> > > because they do not require =
end-to-end coordination at the

> > > media level.]

> > >

> > > Tom Taylor

> > > Multimedia Control and Applications =
Standards

> > > Ph.  +1 613 736 0961

> > > taylor@nortelnetworks.com=3D20

> > >

> 





------_=_NextPart_001_01C0DA3B.658FC360--


From owner-megaco@fore.com  Fri May 11 13:24:00 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16072
	for ; Fri, 11 May 2001 13:23:59 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA16957;
	Fri, 11 May 2001 13:13:34 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA03464
	for megaco-list; Fri, 11 May 2001 13:10:45 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA03439
	for ; Fri, 11 May 2001 13:10:32 -0400 (EDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA16445
	for ; Fri, 11 May 2001 13:10:28 -0400 (EDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id MAA09208
	for ; Fri, 11 May 2001 12:09:15 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4BH99C06683
	for ; Fri, 11 May 2001 12:09:09 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4BH8V103797
	for ; Fri, 11 May 2001 12:08:31 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4BH8VO13897
	for ; Fri, 11 May 2001 12:08:31 -0500 (CDT)
Message-ID: <3AFC1C8F.35BC3049@usa.alcatel.com>
Date: Fri, 11 May 2001 12:08:31 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Service change method query
References: <28560036253BD41191A10000F8BCBD110250CB1D@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------EC3F5A93213ACA01F5F89325"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------EC3F5A93213ACA01F5F89325
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I am agreeing w/Madhu that for initial registration it should be Restart
if MGC redirects.

I was just expanding on Handoff and how new MGC should deals w/Restart
vs Handoff
which to new MGC is like a new registration and not a re-registration.


Tom-PT Taylor wrote:

> But Madhu makes the valid point that this is an initial registration
> attempt by the MG which has been redirected by the first MGC it
> tried.  The MG doesn't necessarily have any calls in progress.
>
>      -----Original Message-----
>      From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
>      Sent: Friday, May 11, 2001 11:57 AM
>      To: megaco@fore.com
>      Subject: Re: Service change method query
>
>
>      There is another difference why Handoff should be used
>      instead of Restart by the MG
>      when MG tries to connect to the new MGC.
>
>      I think the intend was to let the new MGC knows that MG
>      stills has calls in contexts.
>      Therefore either new MGC does an Audit towards MG to rebuild
>      all necessary
>      info about MG or use either SIP, SIP-T, BICC, gods know what
>      to get whatever
>      info it needs from old MGC before it goes out of service.
>
>      Chuong
>
>
>      Madhu Babu Brahmanapally wrote:
>
>     > HI Vivek,
>     >
>     > In page 57, First paragraph, its mentioned that the MGC
>     > may return a
>     > ServiceChangeMgcId describing the MGC to be contacted. It
>     > is also mentioned
>     > that MG will "REISSUE" the service change command to the
>     > new MGC specified.
>     > Hence, the service Change method to be used should be
>     > "restart" only. This
>     > shouldn't be treated as a handoff initiated by the MGC.
>     > The MG is just
>     > retrying the same registration with the new MGC.
>     >
>     > Handoff is used by MGC when the it is going out of
>     > service. When the MG
>     > attempts to establish a new association with the newly
>     > specified MGC it uses
>     > the Handoff method.
>     >
>     > Regards
>     > Madhubabu
>     >
>     > -----Original Message-----
>     > From: owner-megaco@pit.comms.marconi.com
>     > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of
>     > vibansal@hss.hns.com
>     > Sent: Tuesday, April 24, 2001 8:23 AM
>     > To: megaco@fore.com
>     > Subject: Service change method query
>     >
>     > Hi All
>     >
>     > In the first service change request from MG, if the MGC
>     > replies with the
>     > MGCidtotry, then with what service change method and
>     > reason does MG send the
>     > request to new MGC?
>     >
>     > There could be two possibilities:
>     > 1. Since this is same as a Handoff scenario, MG can use
>     > Handoff method.
>     > 2. Since it was the first registration request, MG can use
>     > Restart method.
>     >
>     > Kindly clearify this.
>     >
>     > Regards
>     > Vivek Bansal
>     > Hughes Software System
>
>      --
>        Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>        1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>        **** The opinions expressed are not those of Alcatel USA, Inc ****
>
>
>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------EC3F5A93213ACA01F5F89325
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



I am agreeing w/Madhu that for initial registration it should be Restart
if MGC redirects.

I was just expanding on Handoff and how new MGC should deals w/Restart
vs Handoff

which to new MGC is like a new registration and not a re-registration.

 

Tom-PT Taylor wrote:

But
Madhu makes the valid point that this is an initial registration attempt
by the MG which has been redirected by the first MGC it tried.  The
MG doesn't necessarily have any calls in progress.



-----Original
Message-----

From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]

Sent: Friday, May 11, 2001
11:57 AM

To: megaco@fore.com

Subject: Re: Service change
method query




There is another difference why Handoff should be used instead of
Restart by the MG

when MG tries to connect to the new MGC.

I think the intend was to let the new MGC knows that MG stills has calls
in contexts.

Therefore either new MGC does an Audit towards MG to rebuild all necessary

info about MG or use either SIP, SIP-T, BICC, gods know what to get
whatever

info it needs from old MGC before it goes out of service.

Chuong

 

Madhu Babu Brahmanapally wrote:

HI Vivek,

In page 57, First paragraph, its mentioned that the MGC may return a

ServiceChangeMgcId describing the MGC to be contacted. It is also mentioned

that MG will "REISSUE" the service change command to the new MGC specified.

Hence, the service Change method to be used should be  "restart"
only. This

shouldn't be treated as a handoff initiated by the MGC. The MG is just

retrying the same registration with the new MGC.

Handoff is used by MGC when the it is going out of service. When the
MG

attempts to establish a new association with the newly specified MGC
it uses

the Handoff method.

Regards

Madhubabu

-----Original Message-----

From: owner-megaco@pit.comms.marconi.com

[mailto:owner-megaco@pit.comms.marconi.com]On
Behalf Of

vibansal@hss.hns.com

Sent: Tuesday, April 24, 2001 8:23 AM

To: megaco@fore.com

Subject: Service change method query

Hi All

In the first service change request from MG, if the MGC replies with
the

MGCidtotry, then with what service change method and reason does MG
send the

request to new MGC?

There could be two possibilities:

1. Since this is same as a Handoff scenario, MG can use Handoff method.

2. Since it was the first registration request, MG can use Restart
method.

Kindly clearify this.

Regards

Vivek Bansal

Hughes Software System



-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 





-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------EC3F5A93213ACA01F5F89325--



From owner-megaco@fore.com  Fri May 11 13:43:44 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16727
	for ; Fri, 11 May 2001 13:43:44 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19671;
	Fri, 11 May 2001 13:36:22 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA10317
	for megaco-list; Fri, 11 May 2001 13:33:33 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA10307
	for ; Fri, 11 May 2001 13:33:31 -0400 (EDT)
Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19297
	for ; Fri, 11 May 2001 13:33:27 -0400 (EDT)
Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200])
	by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.38 2001/05/09 12:49:45 root Exp $) with SMTP id RAA12565;
	Fri, 11 May 2001 17:33:20 GMT
Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.200
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 11 May 2001 17:33:20 0000 (GMT)
Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 11 May 2001 10:33:18 -0700
Message-ID: 
From: "Kaul, Bharat" 
To: "'Christian Groves'" ,
        Paul Long
	 
Cc: megaco ietf 
Subject: RE: Implementors' Guide Update Editor's last Call
Date: Fri, 11 May 2001 10:32:51 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hi Paul,

  For 6.58 in implementation guide the reason it is UDP only is that for an
MG using TCP as transport it is of no use to have ServiceChange Address
specified in it as MG does not have a TCP server where MGC will connect to.
This implies  for TCP as transport MGC should not look at ServiceChange
Address either. The standards didn't say any of this anywhere and there is a
whole series of emails on this indicating possibility of interop issues. And
in order to end this silence of the standards, the part was added in
implementors guide.  

- Bharat

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com]
Sent: Thursday, May 10, 2001 7:43 PM
To: Paul Long
Cc: megaco ietf; bharat@trillium.com
Subject: Re: Implementors' Guide Update Editor's last Call


G'Day Paul,

Please my comments below.

Cheers, Christian

Paul Long wrote:
> 
> Christian,
> 
> My comments:
> 
> Item 6.16: Concatenation (e.g., A B) already takes precedence over the
> alternative operator (e.g., A / B), so the proposed parentheses are
> redundant. (See 3.10/RFC2234.) I guess it doesn't hurt to add them, but
this
> is technically a clarification and not a correction so it should go in
> section 7.

[CHG] Its not a clarification as it changes the syntax. As it was
already approved in the first IG I do not particular want to change it
was its not broken.

> 
> Item 6.58: Inserting the text, "For UDP as a transport," precludes an MG
> that uses TCP from also using ServiceChangeAddress. Not that _I_ want to
do
> such a thing, but is this a necessary constraint? Was this intended?

[CHG] Bharat asked this to be added so he can answer you on this. I'm
quite happy to remove the "UDP as a transport" because I don't like
trying H.248/Megaco procedures to transports.

> 
> Item 11.6: I know this is only clarifying text, but you should probably
> change "Parsers should accept whitespace..." to "Parsers shall accept
> whitespace..."
[CHG] Any complaints from ABNF gurus on this? Tom what's your call?

> 
> Paul Long
> ipDialog, Inc.
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Christian Groves
> Sent: Wednesday, May 09, 2001 12:40 AM
> To: megaco ietf
> Cc: Tom-PT Taylor; Glen Freundlich
> Subject: Implementors' Guide Update Editor's last Call
> 
> G'Day all,
> 
> The H.248 Series Implementors' Guide has been updated to revision 6.
> 
> It can be found at:
> ftp://standard.pictel.com/avc-site/Incoming/
> files:
> TD-xxx_H248_Implementors_Additions_v6.doc
> TD-xxx_H248_Implementors_Additions_v6.pdf
> 
> This revision contains the Approved Implementors' Guide and the
> Implementors' Guide Additions v5 with some other changes. The changes
> are detailed in the document.
> 
> This is an editors' last call. Please provide comments on this draft by
> Monday the 13th as a revision 7 will be stored on the 14th and sent to
> SG16 for approval at the Porto Seguro meeting. If you have a comment on
> a correction please provide the detailed solution or exact changes that
> you would like to see.
> 
> Cheers, Christian





From owner-megaco@fore.com  Fri May 11 14:03:53 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17333
	for ; Fri, 11 May 2001 14:03:52 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA21660;
	Fri, 11 May 2001 13:52:36 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA14687
	for megaco-list; Fri, 11 May 2001 13:50:22 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA14615
	for ; Fri, 11 May 2001 13:50:18 -0400 (EDT)
Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA21341
	for ; Fri, 11 May 2001 13:50:08 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4BHo8u3030196
	for ; Fri, 11 May 2001 12:50:08 -0500
From: "Paul Long" 
To: "megaco ietf" 
Subject: RE: Implementors' Guide Update Editor's last Call
Date: Fri, 11 May 2001 12:50:08 -0500
Message-ID: 
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: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bharat,

But if an MG specified a ServiceChangeAddress, that would imply that it
would indeed be able to listen on that port for a TCP connection to be
established. I just don't understand why we need to constrain something in
the standard that will naturally be controlled by the signaling entity.
Basically, if you can't do something, don't signal that you can. Maybe you
are saying that an MG cannot inherently ever be a "TCP server." Is that it?
If so, why can't it?

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Kaul, Bharat
Sent: Friday, May 11, 2001 12:33 PM
To: 'Christian Groves'; Paul Long
Cc: megaco ietf
Subject: RE: Implementors' Guide Update Editor's last Call


Hi Paul,

  For 6.58 in implementation guide the reason it is UDP only is that for an
MG using TCP as transport it is of no use to have ServiceChange Address
specified in it as MG does not have a TCP server where MGC will connect to.
This implies  for TCP as transport MGC should not look at ServiceChange
Address either. The standards didn't say any of this anywhere and there is a
whole series of emails on this indicating possibility of interop issues. And
in order to end this silence of the standards, the part was added in
implementors guide.

- Bharat



From owner-megaco@fore.com  Fri May 11 14:41:09 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18025
	for ; Fri, 11 May 2001 14:41:08 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA25879;
	Fri, 11 May 2001 14:29:55 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA23661
	for megaco-list; Fri, 11 May 2001 14:26:59 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA23649
	for ; Fri, 11 May 2001 14:26:57 -0400 (EDT)
Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA25398
	for ; Fri, 11 May 2001 14:26:53 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4BIQru3014250
	for ; Fri, 11 May 2001 13:26:54 -0500
From: "Paul Long" 
To: "megaco ietf" 
Subject: RE: Implementors' Guide Update Editor's last Call
Date: Fri, 11 May 2001 13:26:55 -0500
Message-ID: 
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)
Importance: Normal
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bharat,

Someone just told me via private email that the problem isn't necessarily
with the MG but with the MGC. We don't want to require the MGC to ever have
to initiate a connection to the MG, and this would otherwise be the only
situation where it would have to. I don't have to understand why, I'll just
assume that there are real good reasons. :-)

How about changing the wording, then. I thought the original sentence was
kind of awkward, anyway. How about changing from this:

"For UDP as a transport, the MG may specify the transport
ServiceChangeAddress to be used by the MGC for sending messages in the
ServiceChangeAddress parameter in the input ServiceChangeDescriptor."

to this:

"In the ServiceChangeAddress parameter of the ServiceChangeDescriptor, the
MG may specify the transport address to be used by the MGC for sending
request messages.  So that the MGC does not have to initiate a new
connection, however, the MG shall not specify a ServiceChangeAddress if the
association is using a reliable, connection-oriented transport."

This explains the requirement somewhat and eliminates the reference to a
particular transport. I would have just said, "connection-oriented
protocol," since that would mean TCP in the case of IP, but that term is not
used elsewhere in the spec, so I also said "reliable." From a quick online
search, it appears that "reliable" and "connection-oriented" are synonymous,
but we can state both just to be absolutely clear. What do you think about
this new wording?

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Paul Long
Sent: Friday, May 11, 2001 12:50 PM
To: megaco ietf
Subject: RE: Implementors' Guide Update Editor's last Call


Bharat,

But if an MG specified a ServiceChangeAddress, that would imply that it
would indeed be able to listen on that port for a TCP connection to be
established. I just don't understand why we need to constrain something in
the standard that will naturally be controlled by the signaling entity.
Basically, if you can't do something, don't signal that you can. Maybe you
are saying that an MG cannot inherently ever be a "TCP server." Is that it?
If so, why can't it?

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Kaul, Bharat
Sent: Friday, May 11, 2001 12:33 PM
To: 'Christian Groves'; Paul Long
Cc: megaco ietf
Subject: RE: Implementors' Guide Update Editor's last Call


Hi Paul,

  For 6.58 in implementation guide the reason it is UDP only is that for an
MG using TCP as transport it is of no use to have ServiceChange Address
specified in it as MG does not have a TCP server where MGC will connect to.
This implies  for TCP as transport MGC should not look at ServiceChange
Address either. The standards didn't say any of this anywhere and there is a
whole series of emails on this indicating possibility of interop issues. And
in order to end this silence of the standards, the part was added in
implementors guide.

- Bharat



From owner-megaco@fore.com  Fri May 11 15:03:09 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18422
	for ; Fri, 11 May 2001 15:03:09 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA29153;
	Fri, 11 May 2001 14:57:20 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA01419
	for megaco-list; Fri, 11 May 2001 14:54:53 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA01406
	for ; Fri, 11 May 2001 14:54:51 -0400 (EDT)
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA28839
	for ; Fri, 11 May 2001 14:54:47 -0400 (EDT)
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.38 2001/05/09 12:49:45 root Exp $) with SMTP id SAA26204;
	Fri, 11 May 2001 18:54:48 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 11 May 2001 18:54:48 0000 (GMT)
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 11 May 2001 11:54:45 -0700
Message-ID: 
From: "Kaul, Bharat" 
To: "'Paul Long'" , megaco ietf 
Subject: RE: Implementors' Guide Update Editor's last Call
Date: Fri, 11 May 2001 11:54:43 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Paul,

Effectively yes..MG shouldn't have a TCP server for Version 1.0 of the
protocol. MG having a TCP server doesn't mean anything as MGC are not
supposed to have capability to initiate connections.

Currently MGs contact MGC and then they communicate. This implies
essentially MGC doesn't need to have the capability to contact MGC.
Outlining the same in the standards keeps life simple as MGC don't need to
deal with these possibilities and build intelligence to initiate
connections. 

Instead of taking an approach where, "if you can't do something, don't
signal that you can",  I think it should be if you want to use a particular
port in TCP, open your connection from there.  And MGs are fully capable of
doing so.

And I am not so sure that protocal can remain indifferent to underlying
protocol. Our retransmission strategies for should be different for TCP and
UDP. And similarly tomorrow with SCTP in picture, suddenly we need to deal
with associations and streams.

- Bharat

-----Original Message-----
From: Paul Long [mailto:plong@ipdialog.com]
Sent: Friday, May 11, 2001 10:50 AM
To: megaco ietf
Subject: RE: Implementors' Guide Update Editor's last Call


Bharat,

But if an MG specified a ServiceChangeAddress, that would imply that it
would indeed be able to listen on that port for a TCP connection to be
established. I just don't understand why we need to constrain something in
the standard that will naturally be controlled by the signaling entity.
Basically, if you can't do something, don't signal that you can. Maybe you
are saying that an MG cannot inherently ever be a "TCP server." Is that it?
If so, why can't it?

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Kaul, Bharat
Sent: Friday, May 11, 2001 12:33 PM
To: 'Christian Groves'; Paul Long
Cc: megaco ietf
Subject: RE: Implementors' Guide Update Editor's last Call


Hi Paul,

  For 6.58 in implementation guide the reason it is UDP only is that for an
MG using TCP as transport it is of no use to have ServiceChange Address
specified in it as MG does not have a TCP server where MGC will connect to.
This implies  for TCP as transport MGC should not look at ServiceChange
Address either. The standards didn't say any of this anywhere and there is a
whole series of emails on this indicating possibility of interop issues. And
in order to end this silence of the standards, the part was added in
implementors guide.

- Bharat




From owner-megaco@fore.com  Fri May 11 15:05:08 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18470
	for ; Fri, 11 May 2001 15:05:08 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA29577;
	Fri, 11 May 2001 14:59:23 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA01820
	for megaco-list; Fri, 11 May 2001 14:56:33 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA01815
	for ; Fri, 11 May 2001 14:56:31 -0400 (EDT)
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA29010
	for ; Fri, 11 May 2001 14:56:27 -0400 (EDT)
Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.38 2001/05/09 12:49:45 root Exp $) with SMTP id SAA26725;
	Fri, 11 May 2001 18:56:28 GMT
Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 11 May 2001 18:56:28 0000 (GMT)
Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 11 May 2001 11:56:27 -0700
Message-ID: 
From: "Kaul, Bharat" 
To: "'Paul Long'" , megaco ietf 
Subject: RE: Implementors' Guide Update Editor's last Call
Date: Fri, 11 May 2001 11:56:24 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Agreed ...that is a good suggestion :)

-----Original Message-----
From: Paul Long [mailto:plong@ipdialog.com]
Sent: Friday, May 11, 2001 11:27 AM
To: megaco ietf
Subject: RE: Implementors' Guide Update Editor's last Call


Bharat,

Someone just told me via private email that the problem isn't necessarily
with the MG but with the MGC. We don't want to require the MGC to ever have
to initiate a connection to the MG, and this would otherwise be the only
situation where it would have to. I don't have to understand why, I'll just
assume that there are real good reasons. :-)

How about changing the wording, then. I thought the original sentence was
kind of awkward, anyway. How about changing from this:

"For UDP as a transport, the MG may specify the transport
ServiceChangeAddress to be used by the MGC for sending messages in the
ServiceChangeAddress parameter in the input ServiceChangeDescriptor."

to this:

"In the ServiceChangeAddress parameter of the ServiceChangeDescriptor, the
MG may specify the transport address to be used by the MGC for sending
request messages.  So that the MGC does not have to initiate a new
connection, however, the MG shall not specify a ServiceChangeAddress if the
association is using a reliable, connection-oriented transport."

This explains the requirement somewhat and eliminates the reference to a
particular transport. I would have just said, "connection-oriented
protocol," since that would mean TCP in the case of IP, but that term is not
used elsewhere in the spec, so I also said "reliable." From a quick online
search, it appears that "reliable" and "connection-oriented" are synonymous,
but we can state both just to be absolutely clear. What do you think about
this new wording?

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Paul Long
Sent: Friday, May 11, 2001 12:50 PM
To: megaco ietf
Subject: RE: Implementors' Guide Update Editor's last Call


Bharat,

But if an MG specified a ServiceChangeAddress, that would imply that it
would indeed be able to listen on that port for a TCP connection to be
established. I just don't understand why we need to constrain something in
the standard that will naturally be controlled by the signaling entity.
Basically, if you can't do something, don't signal that you can. Maybe you
are saying that an MG cannot inherently ever be a "TCP server." Is that it?
If so, why can't it?

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Kaul, Bharat
Sent: Friday, May 11, 2001 12:33 PM
To: 'Christian Groves'; Paul Long
Cc: megaco ietf
Subject: RE: Implementors' Guide Update Editor's last Call


Hi Paul,

  For 6.58 in implementation guide the reason it is UDP only is that for an
MG using TCP as transport it is of no use to have ServiceChange Address
specified in it as MG does not have a TCP server where MGC will connect to.
This implies  for TCP as transport MGC should not look at ServiceChange
Address either. The standards didn't say any of this anywhere and there is a
whole series of emails on this indicating possibility of interop issues. And
in order to end this silence of the standards, the part was added in
implementors guide.

- Bharat




From owner-megaco@fore.com  Fri May 11 15:57:10 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19370
	for ; Fri, 11 May 2001 15:57:10 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA03523;
	Fri, 11 May 2001 15:40:53 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA13281
	for megaco-list; Fri, 11 May 2001 15:38:13 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA13272
	for ; Fri, 11 May 2001 15:38:11 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA03251
	for ; Fri, 11 May 2001 15:38:07 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4BJc7dQ006891
	for ; Fri, 11 May 2001 14:38:07 -0500 (CDT)
From: "Paul Long" 
To: 
Subject: Where messages are sent
Date: Fri, 11 May 2001 14:38:09 -0500
Message-ID: 
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
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Here is a spreadsheet in two formats (same cavetas apply as my previous
posting) showing where messages are sent based on the ServiceChange
descriptors, the source of the request, and possibly the mID. Please take a
look at it. Make sure I have all of the scenarios correctly described and
especially note the highlighted cells because they show my interpretation of
Bharat's item 6.85 in the IG. I recommend that the two sentences inserted by
the correction be removed because that would mean that the mID does indeed
carry a valid IP address which will be used as an IP address, and I don't
understand what the prupose of this exception is.

http://www.packetizer.com/people/plong/wohin.htm
http://www.packetizer.com/people/plong/wohin.xls

Paul Long
ipDialog, Inc.



From owner-megaco@fore.com  Fri May 11 16:02:00 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19479
	for ; Fri, 11 May 2001 16:01:59 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA04620;
	Fri, 11 May 2001 15:52:26 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA16047
	for megaco-list; Fri, 11 May 2001 15:50:11 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA16039
	for ; Fri, 11 May 2001 15:50:10 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA04389
	for ; Fri, 11 May 2001 15:50:05 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4BJo7B06492
	for ; Fri, 11 May 2001 15:50:07 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4BJo6Q06472
	for ; Fri, 11 May 2001 15:50:06 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA03720; Fri, 11 May 2001 15:50:02 -0400 (EDT)
Cc: megaco ietf , Tom-PT Taylor ,
        Glen Freundlich 
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA03711; Fri, 11 May 2001 15:50:01 -0400 (EDT)
Message-ID: <3AFC41F5.1B8F898B@lucent.com>
Date: Fri, 11 May 2001 15:48:05 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Groves 
Original-CC: megaco ietf , Tom-PT Taylor ,
        Glen Freundlich 
Subject: Re: Implementors' Guide Update Editor's last Call 7.2
References: <3AF8D832.E727C159@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Christian Groves wrote:
> 
> G'Day all,
> 
> The H.248 Series Implementors' Guide has been updated to revision 6.
> 
> It can be found at:
> ftp://standard.pictel.com/avc-site/Incoming/
> files:
> TD-xxx_H248_Implementors_Additions_v6.doc
> TD-xxx_H248_Implementors_Additions_v6.pdf
> 
> This revision contains the Approved Implementors' Guide and the
> Implementors' Guide Additions v5 with some other changes. The changes
> are detailed in the document.
> 
> This is an editors' last call. Please provide comments on this draft by
> Monday the 13th as a revision 7 will be stored on the 14th and sent to
> SG16 for approval at the Porto Seguro meeting. If you have a comment on
> a correction please provide the detailed solution or exact changes that
> you would like to see.
> 
> Cheers, Christian

The header for section 7.2 is a copy of the header for 7.1.
7.2 addresses a different issue.

-troy


From owner-megaco@fore.com  Fri May 11 17:42:22 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21182
	for ; Fri, 11 May 2001 17:42:22 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA14014;
	Fri, 11 May 2001 17:27:10 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA07414
	for megaco-list; Fri, 11 May 2001 17:23:17 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA07406
	for ; Fri, 11 May 2001 17:23:15 -0400 (EDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA13439
	for ; Fri, 11 May 2001 17:23:11 -0400 (EDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA28474;
	Fri, 11 May 2001 16:23:13 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4BLNCC15198;
	Fri, 11 May 2001 16:23:12 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4BLMO105801;
	Fri, 11 May 2001 16:22:24 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4BLMOO13971;
	Fri, 11 May 2001 16:22:24 -0500 (CDT)
Message-ID: <3AFC580F.E51A1A4D@usa.alcatel.com>
Date: Fri, 11 May 2001 16:22:23 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kaul, Bharat" 
CC: "'Paul Long'" , megaco ietf 
Subject: Re: Implementors' Guide Update Editor's last Call
References: 
Content-Type: multipart/alternative;
 boundary="------------65A5A7E67385B06230CC857F"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------65A5A7E67385B06230CC857F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Do we also need words for the Reply by MGC?



> "For UDP as a transport, the MG may specify the transport
> ServiceChangeAddress to be used by the MGC for sending messages in the
> ServiceChangeAddress parameter in the input ServiceChangeDescriptor."
>
> to this:
>
> "In the ServiceChangeAddress parameter of the ServiceChangeDescriptor, the
> MG may specify the transport address to be used by the MGC for sending
> request messages.  So that the MGC does not have to initiate a new
> connection, however, the MG shall not specify a ServiceChangeAddress if the
> association is using a reliable, connection-oriented transport."
>
> This explains the requirement somewhat and eliminates the reference to a
> particular transport. I would have just said, "connection-oriented
> protocol," since that would mean TCP in the case of IP, but that term is not
> used elsewhere in the spec, so I also said "reliable." From a quick online
> search, it appears that "reliable" and "connection-oriented" are synonymous,
> but we can state both just to be absolutely clear. What do you think about
> this new wording?
>
> Paul Long
> ipDialog, Inc.
>
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Paul Long
> Sent: Friday, May 11, 2001 12:50 PM
> To: megaco ietf
> Subject: RE: Implementors' Guide Update Editor's last Call
>
> Bharat,
>
> But if an MG specified a ServiceChangeAddress, that would imply that it
> would indeed be able to listen on that port for a TCP connection to be
> established. I just don't understand why we need to constrain something in
> the standard that will naturally be controlled by the signaling entity.
> Basically, if you can't do something, don't signal that you can. Maybe you
> are saying that an MG cannot inherently ever be a "TCP server." Is that it?
> If so, why can't it?
>
> Paul Long
> ipDialog, Inc.
>
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Kaul, Bharat
> Sent: Friday, May 11, 2001 12:33 PM
> To: 'Christian Groves'; Paul Long
> Cc: megaco ietf
> Subject: RE: Implementors' Guide Update Editor's last Call
>
> Hi Paul,
>
>   For 6.58 in implementation guide the reason it is UDP only is that for an
> MG using TCP as transport it is of no use to have ServiceChange Address
> specified in it as MG does not have a TCP server where MGC will connect to.
> This implies  for TCP as transport MGC should not look at ServiceChange
> Address either. The standards didn't say any of this anywhere and there is a
> whole series of emails on this indicating possibility of interop issues. And
> in order to end this silence of the standards, the part was added in
> implementors guide.
>
> - Bharat

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------65A5A7E67385B06230CC857F
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Do we also need words for the Reply by MGC?

 

 

"For UDP as a transport, the MG may specify the transport

ServiceChangeAddress to be used by the MGC for sending messages in
the

ServiceChangeAddress parameter in the input ServiceChangeDescriptor."

to this:

"In the ServiceChangeAddress parameter of the ServiceChangeDescriptor,
the

MG may specify the transport address to be used by the MGC for sending

request messages.  So that the MGC does not have to initiate a
new

connection, however, the MG shall not specify a ServiceChangeAddress
if the

association is using a reliable, connection-oriented transport."

This explains the requirement somewhat and eliminates the reference
to a

particular transport. I would have just said, "connection-oriented

protocol," since that would mean TCP in the case of IP, but that term
is not

used elsewhere in the spec, so I also said "reliable." From a quick
online

search, it appears that "reliable" and "connection-oriented" are synonymous,

but we can state both just to be absolutely clear. What do you think
about

this new wording?

Paul Long

ipDialog, Inc.

-----Original Message-----

From: owner-megaco@pit.comms.marconi.com

[mailto:owner-megaco@pit.comms.marconi.com]On
Behalf Of Paul Long

Sent: Friday, May 11, 2001 12:50 PM

To: megaco ietf

Subject: RE: Implementors' Guide Update Editor's last Call

Bharat,

But if an MG specified a ServiceChangeAddress, that would imply that
it

would indeed be able to listen on that port for a TCP connection to
be

established. I just don't understand why we need to constrain something
in

the standard that will naturally be controlled by the signaling entity.

Basically, if you can't do something, don't signal that you can. Maybe
you

are saying that an MG cannot inherently ever be a "TCP server." Is
that it?

If so, why can't it?

Paul Long

ipDialog, Inc.

-----Original Message-----

From: owner-megaco@pit.comms.marconi.com

[mailto:owner-megaco@pit.comms.marconi.com]On
Behalf Of Kaul, Bharat

Sent: Friday, May 11, 2001 12:33 PM

To: 'Christian Groves'; Paul Long

Cc: megaco ietf

Subject: RE: Implementors' Guide Update Editor's last Call

Hi Paul,

  For 6.58 in implementation guide the reason it is UDP only is
that for an

MG using TCP as transport it is of no use to have ServiceChange Address

specified in it as MG does not have a TCP server where MGC will connect
to.

This implies  for TCP as transport MGC should not look at ServiceChange

Address either. The standards didn't say any of this anywhere and there
is a

whole series of emails on this indicating possibility of interop issues.
And

in order to end this silence of the standards, the part was added in

implementors guide.

- Bharat



-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------65A5A7E67385B06230CC857F--



From owner-megaco@fore.com  Fri May 11 17:51:45 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21377
	for ; Fri, 11 May 2001 17:51:44 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15612;
	Fri, 11 May 2001 17:44:41 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA09980
	for megaco-list; Fri, 11 May 2001 17:39:13 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA09969
	for ; Fri, 11 May 2001 17:39:11 -0400 (EDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15027
	for ; Fri, 11 May 2001 17:39:06 -0400 (EDT)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA05344
	for ; Fri, 11 May 2001 16:39:09 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4BLd8T16081
	for ; Fri, 11 May 2001 16:39:08 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4BLcI107732
	for ; Fri, 11 May 2001 16:38:18 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4BLcIO13981
	for ; Fri, 11 May 2001 16:38:18 -0500 (CDT)
Message-ID: <3AFC5BCA.D65FB138@usa.alcatel.com>
Date: Fri, 11 May 2001 16:38:18 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Implementors' Guide Update Editor's last Call - MGC failure
References: <0D5BBF5D638DD4119E3400508BD9494524FA40@RADVPOST>
Content-Type: multipart/alternative;
 boundary="------------5ED25BB1E40D0AF03C36D7B8"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------5ED25BB1E40D0AF03C36D7B8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


--------------5ED25BB1E40D0AF03C36D7B8
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




 

The intend was not to use ROOT but a fully specified terminationID
or even better a

known invalid terminationID (A bogus terminationID that the sender
knows is not valid and is

used specifically for heartbeat purpose).  The idea is to get
some kind of responses.

"poll" do you mean heartbeat like msg to from MG to MGC or something
else here.

Where did you see that Restart w/ROOT is used as a heartbeat/poll?

 

Chuong

Dan Elbert wrote:






Hi







After
reviewing the issue of MGC failure ( when the MG is connected trough UDP
) I believe that there is no satisfactory way for the MG to poll the MGC
to see if the MGC is still alive. Using a ServiceChange with "Restart"
method and termination id of "root" may cause the MGC to assume that the
MG restarted and can affect the state of a call in progress.


I
think that it would be good to add a ServiceChange method "noop" :





Noop
: Can be used by the MG (with unreliable protocols) to obtain a response
from the MGC or detect a communication failure. When receiving this SVC
the MGC should take no action other that reply.





If
this is not acceptable, then I think that some clarification is needed
as when a SVC with restart method should be considered "noop" by the MGC.





Dan
Elbert


RADVISION







-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 



--------------5ED25BB1E40D0AF03C36D7B8--



From owner-megaco@fore.com  Fri May 11 17:57:50 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21513
	for ; Fri, 11 May 2001 17:57:50 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15927;
	Fri, 11 May 2001 17:47:02 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA10715
	for megaco-list; Fri, 11 May 2001 17:43:10 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA10541
	for ; Fri, 11 May 2001 17:42:47 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15362
	for ; Fri, 11 May 2001 17:42:43 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4BLghdQ002983
	for ; Fri, 11 May 2001 16:42:43 -0500 (CDT)
From: "Paul Long" 
To: "megaco ietf" 
Subject: RE: Implementors' Guide Update Editor's last Call
Date: Fri, 11 May 2001 16:42:46 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0006_01C0DA39.686DEF00"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <3AFC580F.E51A1A4D@usa.alcatel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01C0DA39.686DEF00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Chuong,

I was under the impression that the MG is always able to establish a
connection. Therefore, the MGC may specify a ServiceChangeAddress regardless
of whether it is using a connection-oriented or connectionless transport for
a given association. An MG must therefore always be able to close the
current connection and establish a new one upon receipt of
ServiceChangeAddress from the MGC with a port number that is different than
the current one. Note that the new connection continues the current
association, so re-registration is not appropriate.

Paul Long
ipDialog, Inc.
  -----Original Message-----
  From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Chuong Nguyen
  Sent: Friday, May 11, 2001 4:22 PM
  To: Kaul, Bharat
  Cc: 'Paul Long'; megaco ietf
  Subject: Re: Implementors' Guide Update Editor's last Call


  Do we also need words for the Reply by MGC?


    "For UDP as a transport, the MG may specify the transport
    ServiceChangeAddress to be used by the MGC for sending messages in the
    ServiceChangeAddress parameter in the input ServiceChangeDescriptor."
    to this:

    "In the ServiceChangeAddress parameter of the ServiceChangeDescriptor,
the
    MG may specify the transport address to be used by the MGC for sending
    request messages.  So that the MGC does not have to initiate a new
    connection, however, the MG shall not specify a ServiceChangeAddress if
the
    association is using a reliable, connection-oriented transport."

    This explains the requirement somewhat and eliminates the reference to a
    particular transport. I would have just said, "connection-oriented
    protocol," since that would mean TCP in the case of IP, but that term is
not
    used elsewhere in the spec, so I also said "reliable." From a quick
online
    search, it appears that "reliable" and "connection-oriented" are
synonymous,
    but we can state both just to be absolutely clear. What do you think
about
    this new wording?

    Paul Long
    ipDialog, Inc.


------=_NextPart_000_0006_01C0DA39.686DEF00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Chuong,


 


I was=20
under the impression that the MG is always able to establish a=20
connection. Therefore, the MGC may specify a ServiceChangeAddress=20
regardless of whether it is using a connection-oriented or =
connectionless=20
transport for a given association. An MG must therefore =
always be=20
able to close the current connection and establish a new one upon =
receipt of=20
ServiceChangeAddress from the MGC with a port number that is =
different than=20
the current one. Note that the new connection continues the current =
association,=20
so re-registration is not appropriate.


 


Paul=20
Long


ipDialog, Inc.



  
-----Original Message-----
From:=20
  owner-megaco@pit.comms.marconi.com=20
  [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Chuong=20
  Nguyen
Sent: Friday, May 11, 2001 4:22 PM
To: =
Kaul,=20
  Bharat
Cc: 'Paul Long'; megaco ietf
Subject: Re:=20
  Implementors' Guide Update Editor's last Call

Do =
we also=20
  need words for the Reply by MGC? 
  
 =20
  
"For UDP as a transport, the MG may specify =
the=20
    transport 
ServiceChangeAddress to be used by the MGC for sending =

    messages in the 
ServiceChangeAddress parameter in the input=20
    ServiceChangeDescriptor."=20
    
to this:=20
    
"In the ServiceChangeAddress parameter of the =
ServiceChangeDescriptor,=20
    the 
MG may specify the transport address to be used by the MGC =
for=20
    sending 
request messages.  So that the MGC does not have to =

    initiate a new 
connection, however, the MG shall not specify a=20
    ServiceChangeAddress if the 
association is using a reliable,=20
    connection-oriented transport."=20
    
This explains the requirement somewhat and eliminates the =
reference to a=20
    
particular transport. I would have just said, =
"connection-oriented=20
    
protocol," since that would mean TCP in the case of IP, but that =
term is=20
    not 
used elsewhere in the spec, so I also said "reliable." From =
a quick=20
    online 
search, it appears that "reliable" and =
"connection-oriented" are=20
    synonymous, 
but we can state both just to be absolutely clear. =
What do=20
    you think about 
this new wording?=20
    
Paul Long 
ipDialog, =
Inc.


------=_NextPart_000_0006_01C0DA39.686DEF00--



From owner-megaco@fore.com  Fri May 11 18:10:46 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21790
	for ; Fri, 11 May 2001 18:10:45 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA16948;
	Fri, 11 May 2001 17:59:29 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA12929
	for megaco-list; Fri, 11 May 2001 17:55:31 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA12921
	for ; Fri, 11 May 2001 17:55:29 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA16593
	for ; Fri, 11 May 2001 17:55:25 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Fri, 11 May 2001 16:56:41 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD9494524FA42@RADVPOST>
From: Dan Elbert 
To: "'megaco@fore.com'" ,
        "'Chuong Nguyen'"
	 
Subject: RE: Implementors' Guide Update Editor's last Call - MGC failure
Date: Fri, 11 May 2001 16:56:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0DA65.4236BED0"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DA65.4236BED0
Content-Type: text/plain;
	charset="iso-8859-1"

Using a fully specified terminationID can disrupt the operation of the
termination (for example if the termination is in a call).
It's not clear what a "bogus" termination is, if the MGC receives a SVC from
an MG termination it can assume that this termination is real and start
sending audits or commands.
Yes, by poll I mean some type of heartbeat as the MG needs to know if the
MGC is alive.
Brian Rosen suggested in the past to use SVC with Restart method for this
purpose, I don't think that there was any mantion if this should be done
with id=root or other.
 
Dan
 
-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Friday, May 11, 2001 5:38 PM
To: megaco@fore.com
Subject: Re: Implementors' Guide Update Editor's last Call - MGC failure
 
  
The intend was not to use ROOT but a fully specified terminationID or even
better a 
known invalid terminationID (A bogus terminationID that the sender knows is
not valid and is 
used specifically for heartbeat purpose).  The idea is to get some kind of
responses. 
"poll" do you mean heartbeat like msg to from MG to MGC or something else
here. 
Where did you see that Restart w/ROOT is used as a heartbeat/poll? 
  
Chuong 
Dan Elbert wrote: 
Hi
After reviewing the issue of MGC failure ( when the MG is connected trough
UDP ) I believe that there is no satisfactory way for the MG to poll the MGC
to see if the MGC is still alive. Using a ServiceChange with "Restart"
method and termination id of "root" may cause the MGC to assume that the MG
restarted and can affect the state of a call in progress. 
I think that it would be good to add a ServiceChange method "noop" : 
Noop : Can be used by the MG (with unreliable protocols) to obtain a
response from the MGC or detect a communication failure. When receiving this
SVC the MGC should take no action other that reply. 
If this is not acceptable, then I think that some clarification is needed as
when a SVC with restart method should be considered "noop" by the MGC. 
Dan Elbert 
RADVISION 
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  

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






















Using a fully specified terminationID can disrupt the operation =
of the
termination (for example if the termination is in a =
call).



It’s not clear what a “bogus” termination is, =
if the MGC receives a SVC
from an MG termination it can assume that this termination is real and =
start
sending audits or commands.



Yes, by poll I mean some type of heartbeat as the MG needs to =
know if
the MGC is alive.



Brian Rosen suggested in the past to use SVC with Restart method =
for
this purpose, I don’t think that there was any mantion if this =
should be done
with id=3Droot or other.



 
=



Dan



 
=



-----Original
Message-----

From: Chuong Nguyen
[mailto:Chuong.Nguyen@usa.alcatel.com]

Sent: Friday, May 11, =
2001 5:38 PM

To: megaco@fore.com

Subject: Re: =
Implementors' Guide
Update Editor's last Call - MGC failure



 



  

The intend was not to use ROOT but a fully specified terminationID or =
even
better a 

known invalid terminationID (A bogus terminationID that the sender =
knows is not
valid and is 

used specifically for heartbeat purpose).  The idea is to get some =
kind of
responses. 



"poll" do you mean =
heartbeat
like msg to from MG to MGC or something else here. =




Where did you see that Restart =
w/ROOT is
used as a heartbeat/poll? 

  



Chuong =




Dan Elbert wrote: =
=




Hi=




After reviewing the issue of MGC =
failure ( when
the MG is connected trough UDP ) I believe that there is no =
satisfactory way
for the MG to poll the MGC to see if the MGC is still alive. Using a
ServiceChange with "Restart" method and termination id of
"root" may cause the MGC to assume that the MG restarted and =
can affect
the state of a call in progress. 



I think that it would be good to =
add a
ServiceChange method "noop" =
: =




Noop : Can be used by the MG =
(with
unreliable protocols) to obtain a response from the MGC or detect a
communication failure. When receiving this SVC the MGC should take no =
action
other that reply. 



If this is not acceptable, then I =
think
that some clarification is needed as when a SVC with restart method =
should be
considered "noop" by the =
MGC. =




Dan =
Elbert =




RADVISION =




-- =

  Alcatel USA, =
Inc           &nb=
sp; Internet: Chuong.Nguyen@usa.alcatel.com=

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

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




  =










------_=_NextPart_001_01C0DA65.4236BED0--


From owner-megaco@fore.com  Fri May 11 18:37:14 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22190
	for ; Fri, 11 May 2001 18:37:14 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA13721;
	Fri, 11 May 2001 17:25:53 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA06894
	for megaco-list; Fri, 11 May 2001 17:19:53 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA06889
	for ; Fri, 11 May 2001 17:19:51 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA13200
	for ; Fri, 11 May 2001 17:19:47 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Fri, 11 May 2001 16:21:04 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD9494524FA40@RADVPOST>
From: Dan Elbert 
To: "'megaco@fore.com'" 
Subject: Re: Implementors' Guide Update Editor's last Call - MGC failure
Date: Fri, 11 May 2001 16:21:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0DA60.48C04690"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DA60.48C04690
Content-Type: text/plain;
	charset="iso-8859-1"

Hi
 
After reviewing the issue of MGC failure ( when the MG is connected trough
UDP ) I believe that there is no satisfactory way for the MG to poll the MGC
to see if the MGC is still alive. Using a ServiceChange with "Restart"
method and termination id of "root" may cause the MGC to assume that the MG
restarted and can affect the state of a call in progress.
I think that it would be good to add a ServiceChange method "noop" :
 
Noop : Can be used by the MG (with unreliable protocols) to obtain a
response from the MGC or detect a communication failure. When receiving this
SVC the MGC should take no action other that reply.
 
If this is not acceptable, then I think that some clarification is needed as
when a SVC with restart method should be considered "noop" by the MGC.
 
Dan Elbert
RADVISION
 

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












RE: Use of "strict" parameter











Hi<=
/o:p>



 



After =
reviewing
the issue of MGC failure ( when the MG is connected trough UDP ) I =
believe that
there is no satisfactory way for the MG to poll the MGC to see if the =
MGC is
still alive. Using a ServiceChange with “Restart” method =
and termination id of “root”
may cause the MGC to assume that the MG restarted and can affect the =
state of a
call in progress.



I think that it would be good to add a ServiceChange =
method “noop”
:



 
=



Noop : Can be used by the MG (with unreliable =
protocols) to
obtain a response from the MGC or detect a communication failure. When
receiving this SVC the MGC should take no action other that =
reply.



 
=



If this is not acceptable, then I think that some =
clarification
is needed as when a SVC with restart method should be considered =
“noop” by the
MGC.



 
=



Dan Elbert



RADVISION



 
=









------_=_NextPart_001_01C0DA60.48C04690--


From owner-megaco@fore.com  Fri May 11 18:39:43 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22239
	for ; Fri, 11 May 2001 18:39:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA19293;
	Fri, 11 May 2001 18:32:23 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA17446
	for megaco-list; Fri, 11 May 2001 18:28:12 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA17440
	for ; Fri, 11 May 2001 18:28:10 -0400 (EDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA19002
	for ; Fri, 11 May 2001 18:28:06 -0400 (EDT)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id RAA14070
	for ; Fri, 11 May 2001 17:28:08 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4BMS7T25480
	for ; Fri, 11 May 2001 17:28:07 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4BMRB113839
	for ; Fri, 11 May 2001 17:27:11 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4BMRBO14002
	for ; Fri, 11 May 2001 17:27:11 -0500 (CDT)
Message-ID: <3AFC673F.46B24B49@usa.alcatel.com>
Date: Fri, 11 May 2001 17:27:11 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Implementors' Guide Update Editor's last Call
References: 
Content-Type: multipart/alternative;
 boundary="------------E117303F1D4755DE5EB907F4"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------E117303F1D4755DE5EB907F4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


This goes way back.  I thought some where back (way back in the archive)
for TCP,
it was OK to include ServiceChangeAddress and it would be ignored.

Ok I will go along w/the understanding.
It is just strange that we specify something for MG but not MGC because
there is an
understanding that MG is never the TCP server but MGC is.
So for TCP MGC can specify the ServiceChangeAddress in the Reply but not
MG.

Chuong

Paul Long wrote:

> Chuong,I was under the impression that the MG is always able to
> establish a connection. Therefore, the MGC may specify a
> ServiceChangeAddress regardless of whether it is using a
> connection-oriented or connectionless transport for a given
> association. An MG must therefore always be able to close the current
> connection and establish a new one upon receipt of
> ServiceChangeAddress from the MGC with a port number that is different
> than the current one. Note that the new connection continues the
> current association, so re-registration is not appropriate.Paul
> LongipDialog, Inc.
>
>      -----Original Message-----
>      From: owner-megaco@pit.comms.marconi.com
>      [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of
>      Chuong Nguyen
>      Sent: Friday, May 11, 2001 4:22 PM
>      To: Kaul, Bharat
>      Cc: 'Paul Long'; megaco ietf
>      Subject: Re: Implementors' Guide Update Editor's last Call
>      Do we also need words for the Reply by MGC?
>
>
>
>     > "For UDP as a transport, the MG may specify the transport
>     > ServiceChangeAddress to be used by the MGC for sending
>     > messages in the
>     > ServiceChangeAddress parameter in the input
>     > ServiceChangeDescriptor."
>     >
>     > to this:
>     >
>     > "In the ServiceChangeAddress parameter of the
>     > ServiceChangeDescriptor, the
>     > MG may specify the transport address to be used by the MGC
>     > for sending
>     > request messages.  So that the MGC does not have to
>     > initiate a new
>     > connection, however, the MG shall not specify a
>     > ServiceChangeAddress if the
>     > association is using a reliable, connection-oriented
>     > transport."
>     >
>     > This explains the requirement somewhat and eliminates the
>     > reference to a
>     > particular transport. I would have just said,
>     > "connection-oriented
>     > protocol," since that would mean TCP in the case of IP,
>     > but that term is not
>     > used elsewhere in the spec, so I also said "reliable."
>     > From a quick online
>     > search, it appears that "reliable" and
>     > "connection-oriented" are synonymous,
>     > but we can state both just to be absolutely clear. What do
>     > you think about
>     > this new wording?
>     >
>     > Paul Long
>     > ipDialog, Inc.
>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------E117303F1D4755DE5EB907F4
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

This goes way back.  I thought some where back (way back
in the archive) for TCP,

it was OK to include ServiceChangeAddress and it would be ignored.

Ok I will go along w/the understanding.

It is just strange that we specify something for MG but not MGC because
there is an

understanding that MG is never the TCP server but MGC is.

So for TCP MGC can specify the ServiceChangeAddress in the Reply
but not MG.

Chuong

Paul Long wrote:

Chuong,I
was under the impression that the MG is always able to establish a connection.
Therefore, the MGC may specify a ServiceChangeAddress regardless of whether
it is using a connection-oriented or connectionless transport for a given
association. An MG must therefore always be able to close the current connection
and establish a new one upon receipt of ServiceChangeAddress from the MGC
with a port number that is different than the current one. Note that the
new connection continues the current association, so re-registration is
not appropriate.Paul LongipDialog,
Inc.



-----Original
Message-----

From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Chuong Nguyen

Sent: Friday, May 11, 2001
4:22 PM

To: Kaul, Bharat

Cc: 'Paul Long'; megaco ietf

Subject: Re: Implementors'
Guide Update Editor's last Call

Do we also need words for the Reply by MGC?

 

 

"For UDP as a transport, the MG may specify the
transport

ServiceChangeAddress to be used by the MGC for sending messages in
the

ServiceChangeAddress parameter in the input ServiceChangeDescriptor."

to this:

"In the ServiceChangeAddress parameter of the ServiceChangeDescriptor,
the

MG may specify the transport address to be used by the MGC for sending

request messages.  So that the MGC does not have to initiate a
new

connection, however, the MG shall not specify a ServiceChangeAddress
if the

association is using a reliable, connection-oriented transport."

This explains the requirement somewhat and eliminates the reference
to a

particular transport. I would have just said, "connection-oriented

protocol," since that would mean TCP in the case of IP, but that term
is not

used elsewhere in the spec, so I also said "reliable." From a quick
online

search, it appears that "reliable" and "connection-oriented" are synonymous,

but we can state both just to be absolutely clear. What do you think
about

this new wording?

Paul Long

ipDialog, Inc.







-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------E117303F1D4755DE5EB907F4--



From owner-megaco@fore.com  Sat May 12 09:35:51 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16723
	for ; Sat, 12 May 2001 09:35:51 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA28732;
	Sat, 12 May 2001 09:28:43 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA23345
	for megaco-list; Sat, 12 May 2001 09:22:03 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA23340
	for ; Sat, 12 May 2001 09:22:01 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA28534
	for ; Sat, 12 May 2001 09:21:57 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4CDLw908341
	for ; Sat, 12 May 2001 06:21:58 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f4CDLww24554
	for ; Sat, 12 May 2001 06:21:58 -0700 (PDT)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id GAA24421 for ; Sat, 12 May 2001 06:21:57 -0700 (PDT)
Message-ID: <3AFD3935.2A05195D@cisco.com>
Date: Sat, 12 May 2001 09:23:01 -0400
From: Flemming Andreasen 
Organization: Cisco Systems
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "megaco@fore.com" 
Subject: MGCP 1.0bis -01 now available
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Greetings

We now have an updated version of the MGCP 1.0bis draft available at:


http://search.ietf.org/internet-drafts/draft-andreasen-mgcp-rfc2705bis-01.txt

Section 7.1 lists the changes made since the -00 version.

If you have any questions or comments on the I-D, please send e-mail to
the mgcp list at "mgcp@pulver.com".

If you are not subscribed to this list but would like to, please send an
e-mail to "majordomo@pulver.com" with "subscribe mgcp" in the body.


Regards

            Flemming



PS: We also have the MS-Word source document used to generate the I-D
available at

    http://www.softswitch.org/attachments/RFC2705bis-010510.doc

where changes made since the -00 version (except grammar and some purely
editorial changes) appear with a red font.


--
Flemming Andreasen
Cisco Systems




From owner-megaco@fore.com  Sun May 13 06:21:51 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08931
	for ; Sun, 13 May 2001 06:21:51 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA06890;
	Sun, 13 May 2001 06:13:24 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id GAA28829
	for megaco-list; Sun, 13 May 2001 06:03:09 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA28823
	for ; Sun, 13 May 2001 06:03:07 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id GAA06509
	for ; Sun, 13 May 2001 06:03:06 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id GAA21726; Sun, 13 May 2001 06:03:01 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Sun, 13 May 2001 06:03:04 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Sun, 13 May 2001 06:03:06 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB32@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'megaco'" 
Cc: "'iesg-secretary@ietf.org'" ,
        "'scott bradner'" 
Subject: FW: Resubmission of draft to Megaco Working Group - draft-boyle-m 
         egaco-tonepkgs-04.txt
Date: Sun, 13 May 2001 06:03:03 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

When this appears, please check it out and make sure there are no further
concerns.

Tom Taylor
Multimedia Control and Applications Standards
Ph.  +1 613 736 0961
taylor@nortelnetworks.com 


>  -----Original Message-----
> From: 	Brown, Michael [NC1:GW10:EXCH]  
> Sent:	Friday, May 11, 2001 6:39 PM
> To:	'internet-drafts@ietf.org'
> Cc:	Taylor, Tom-PT [NORSE:B881:EXCH]; Boyle, Kevin [NCRTP:3Z70:EXCH]
> Subject:	Resubmission of draft to Megaco Working Group -
> draft-boyle-megaco-tonepkgs-04.txt
> 
> Please find attached the draft, draft-boyle-megaco-tonepkgs-04.txt. This
> draft is resubmitted for the consideration of the Megaco WG. The reason
> for the reissue of the draft was to address comments received during IESG
> Last Call. The changes that have been made in no way affect the
> functionality or procedures as defined in the previous version of the
> packages.
> A brief summary of the changes:
> 1.) Changes to reflect the intention that several of the packages (Package
> IDs 0x0023 - 0x0028) were to be identical in the functionality,
> specification of package components such as signalids/toneids, and usage
> of these packages with respect to packages defined in conjunction with
> ITU-T Study Group 11.
> 2.) Changes to add missing binary encoding values for signalids/toneids
> and parameters in several packages in the draft.
> 3.) Add a clarification statement in the Security Section of the draft.
> 4.) Add an IANA Considerations section to reflect the need for
> registration of the packages and to clarify the relationship between these
> packages and the packages defined in conjunction with ITU-T Study Group
> 11.
> 5.) Modify Acknowledgements Section to appropriately reflect contributors
> to the draft.
> Regards, 
> Michael Brown 
> Nortel Networks
> 
> 
> 
> 
> 
> 
> 
> 


From owner-megaco@fore.com  Mon May 14 05:16:28 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05762
	for ; Mon, 14 May 2001 05:16:28 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA06058;
	Mon, 14 May 2001 05:10:33 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA13922
	for megaco-list; Mon, 14 May 2001 05:04:09 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA13915
	for ; Mon, 14 May 2001 05:04:07 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA05429
	for ; Mon, 14 May 2001 05:03:53 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id TAA26228;
	Mon, 14 May 2001 19:02:33 +1000 (EST)
Received: from ericsson.com ([164.48.166.25])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id TAA18329;
	Mon, 14 May 2001 19:02:17 +1000 (EST)
Message-ID: <3AFECF23.5C24A720@ericsson.com>
Date: Mon, 14 May 2001 04:14:59 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom-PT Taylor 
CC: "'Troy Cauble'" , "'megaco'" 
Subject: Re: Annex C Descriptor Assignments
References: <28560036253BD41191A10000F8BCBD110250CB1E@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day Tom,

I think we can talk about this in Geneva. I don't want to drop the
"package 0" terminology as its how Annex C is coded. Its a fundamental
part. I'm not sure either that you've identified everything for Local
Control. I'm not in favour of this work as I believe Annex C is a bucket
of information elements much like SDP. Information elements are optional
to implement as they are in SDP. These were fundamental principles when
the 2 encodings were introduced. It should be up to profiles and
documents like Q.1950 to tell you what elements to use in what
situations.

Cheers, Christian

Tom-PT Taylor wrote:
> 
> It looks like I should completely rewrite my contribution to express
> exactly this.  Any other comments?  (Christian may be in the air
> already, in which case I'll talk to him in Geneva next week.)
> 
> > -----Original Message-----
> > From: Troy Cauble [mailto:troy@lucent.com]
> > Sent: Friday, May 11, 2001 10:30 AM
> > To: Taylor, Tom-PT [NORSE:B881:EXCH]
> > Cc: 'Rosen, Brian'; 'megaco'
> > Subject: Re: Annex C Descriptor Assignments
> >
> >
> >
> > Yes!
> >
> > Annex C  -- binary only -- LD & RD only.
> > SDP -- text only -- LD & RD only.
> > Packages -- binary AND text -- NOT in LD & RD.
> >
> > It's great that Tom found so few exceptions.
> > That makes it feasible to move them out into
> > packages.
> >
> > I would like to drop the "Package 0" terminology though.
> > The word "package" implies many things that Annex C is not.
> >
> > -troy
> >
> >
> > > Tom-PT Taylor wrote:
> > >
> > > Given my findings, I would agree with you.  Let's see what
> > other people have
> > > to say.
> > >
> > > > -----Original Message-----
> > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > > Sent: Friday, May 11, 2001 9:58 AM
> > > > To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'megaco'
> > > > Subject: RE: Annex C Descriptor Assignments
> > > >
> > > >
> > > > Before we deal with the details of this, I question the premise:
> 
> > > >   I think that Annex C ONLY is used in
> > > >       binary encoding  and
> > > >       in local and remote (NOT localControl or TerminationState)
> 
> > > > I think the I-G might state that better.
> > > > I think that if there are some things that don't belong in
> remote
> > > >   and local, they should be removed and possibly made part of
> > > > a package,
> > > >   because you don't use Annex C in LocalControl
> > > >
> > > > Brian
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Here is the contribution to SG 16 I've drafted on the subject
> > > > of descript=
> > > > or
> > > > assignments for the Annex C properties.
> > > >
> > > > TITLE:        Descriptors For Megaco/H.248 Annex C Properties
> > > > ___________________
> > > >
> > > >
> > > > INTRODUCTION
> > > >
> > > > Megaco/H.248 Annex C defines a set of properties relating to
> > > > media stream=
> > > > s.
> > > > As such, these properties may appear:
> > > > =B7   in the LocalControl descriptor, if they are local
> > > > interest only, or
> > > > =B7   in the Local and Remote descriptors, if they must
> > be coordinated
> > > > between the local and remote Media Gateways.
> > > >
> > > > Megaco/H.248 Annex C currently fails to indicate which
> > > > alternative applie=
> > > > s
> > > > to each of the properties specified within the Annex.  This
> > > > contribution
> > > > argues that the H.248 Implementor's Guide should be updated
> > > > to reflect su=
> > > > ch
> > > > an assignment.  The contribution goes on to derive principles
> > > > for making =
> > > > the
> > > > assignment decision, and then applies those principles to
> > > > derive a detail=
> > > > ed
> > > > set of  descriptor assignments for all of the properties
> > in the Annex.
> > > >
> > > > =20
> > > >
> > > > NEED FOR A STANDARDIZED PROPERTY ASSIGNMENT
> > > >
> > > > This section presents a semantic and a syntactic argument for
> > > > standardizi=
> > > > ng
> > > > the assignment of properties to descriptors in Annex C.  At
> > > > the semantic
> > > > level, it is essential that the assignment to descriptors be
> > > > the same for=
> > > >  a
> > > > given property, regardless of the H.248 protocol encoding.
> > > > Otherwise one
> > > > encounters a semantic mismatch between encodings, such that
> > > > with respect =
> > > > to
> > > > a given property asymmetric flow descriptions are possible in
> > > > one encodin=
> > > > g
> > > > and not the other.  Such a mismatch may be introduced by
> > > > general usage or=
> > > >  by
> > > > explicit adoption of Annex C properties in standards created
> > > > by bodies ot=
> > > > her
> > > > than the IETF Megaco Working Group or Study Group 16.
> > > >
> > > > At the syntactic level, assignment of specific properties
> > to specific
> > > > descriptors simplifies parser construction by adding
> > predictability to
> > > > message construction.
> > > > A final argument in favour of adding explicit descriptor
> > > > assignments is t=
> > > > hat
> > > > Annex C, as "Package 0", should conform as much as possible to
> the
> > > > documentation rules for packages.  This includes
> > documentation of the
> > > > descriptor to which each property should be assigned.
> > > >
> > > > ASSIGNMENT PRINCIPLES
> > > > =20
> > > > The basic criterion for descriptor assignment was indicated in
> the
> > > > introduction: whether or not the property concerned must be
> > > > coordinated w=
> > > > ith
> > > > the remote Media Gateway.
> > > > However, some borderline cases will require the use of
> > > > subsidiary criteri=
> > > > a.
> > > > The first such criterion was suggested in the previous
> > > > section: assurance
> > > > that the assignment is the same for both text and binary (Annex
> C)
> > > > encodings.  Because the text encoding for the Local and
> > > > Remote descriptor=
> > > > s
> > > > is tied to SDP (RFC 2327), this means that at the very least
> > > > the mandator=
> > > > y
> > > > properties found in RFC 2327 should  be assigned to the Local
> > > > and Remote
> > > > descriptors rather than LocalControl.  Properties which are
> > > > optional in S=
> > > > DP
> > > > may be placed in LocalControl if this makes sense, but the
> > > > assignment mus=
> > > > t
> > > > be the same in both the text and the binary encodings.
> > > >
> > > > There is a further possible criterion: is there a potential
> > > > requirement  =
> > > > for
> > > > a given property to have a different value for each direction
> > > > of flow, an=
> > > > d
> > > > will it be technically feasible to meet that requirement?
> >  If so, the
> > > > property should be assigned to Local/Remote rather than
> > LocalControl.
> > > >
> > > > DETAILED ASSIGNMENTS
> > > >
> > > > The following table proposes detailed assignments for the Annex
> C
> > > > properties.  The "Remarks" column indicates criteria used
> > where the
> > > > assignment was not immediately obvious.
> > > >
> > > > [Rather than repeat the tables, let me summarize by
> > saying that almost
> > > > everything goes into Local/Remote.  Here are the
> > exceptional cases:
> > > >
> > > > Table C.1: Transmission mode (tag 1002) should perhaps be
> > > > deprecated beca=
> > > > use
> > > > the Mode property in LocalControl carries the same
> > > > information.  This is
> > > > equivalent to saying that the SDP in Local and Remote should
> > > > not include =
> > > > any
> > > > of the directionality attributes.  People may want to comment.
> > > >
> > > > Table C.1: Gain (tag 100C) and Jitterbuff (tag 100D) are placed
> in
> > > > LocalControl (of local interest only)
> > > >
> > > > Table C.9: Modem (tag 901B) goes into the Modem Descriptor.
> > > > Actually it
> > > > should be deprecated because the necessary codepoints have
> > > > already been
> > > > defined in the Modem descriptor.
> > > >
> > > > Table C.9: DialledN (tag 901F) and DiallingN (tag 9020) go
> > > > into LocalCont=
> > > > rol
> > > > because they do not require end-to-end coordination at the
> > > > media level.]
> > > >
> > > > Tom Taylor
> > > > Multimedia Control and Applications Standards
> > > > Ph.  +1 613 736 0961
> > > > taylor@nortelnetworks.com=20
> > > >
> >




From owner-megaco@fore.com  Mon May 14 05:20:04 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05814
	for ; Mon, 14 May 2001 05:20:04 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA06095;
	Mon, 14 May 2001 05:10:43 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA13789
	for megaco-list; Mon, 14 May 2001 05:02:47 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA13779
	for ; Mon, 14 May 2001 05:02:45 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA05351
	for ; Mon, 14 May 2001 05:02:40 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id TAA26174;
	Mon, 14 May 2001 19:01:38 +1000 (EST)
Received: from ericsson.com ([164.48.166.25])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id TAA18215;
	Mon, 14 May 2001 19:01:27 +1000 (EST)
Message-ID: <3AFEC590.C0CF99A8@ericsson.com>
Date: Mon, 14 May 2001 03:34:08 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Troy Cauble 
CC: MEGACO list 
Subject: Re: IG Update 9.1 question
References: <3AFBFAA1.62EEB48C@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Yes this is correct. The Signal Type may be over ridden.

Christian

Troy Cauble wrote:
> 
> The IG update 9.1 description seems to say that
> ANY signal's type may be changed to any other
> signal type by SignalType= .
> 
> Is this correct?
> 
> -troy




From owner-megaco@fore.com  Mon May 14 05:21:30 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05833
	for ; Mon, 14 May 2001 05:21:30 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA06075;
	Mon, 14 May 2001 05:10:38 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA13904
	for megaco-list; Mon, 14 May 2001 05:03:56 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA13895
	for ; Mon, 14 May 2001 05:03:54 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA05421
	for ; Mon, 14 May 2001 05:03:49 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id TAA26216;
	Mon, 14 May 2001 19:02:11 +1000 (EST)
Received: from ericsson.com ([164.48.166.25])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id TAA18301;
	Mon, 14 May 2001 19:02:00 +1000 (EST)
Message-ID: <3AFECA4B.28936A1@ericsson.com>
Date: Mon, 14 May 2001 03:54:19 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Chuong Nguyen 
CC: megaco@fore.com
Subject: Re: Implementors' Guide Update Editor's last Call
References:  <3AFC673F.46B24B49@usa.alcatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day Tom,

Do you want to try a FINAL on this thread? I must say I'm confused what
people want. The line about a MGC never initiating a servicechange has
thrown me.

Cheers, Christian

Chuong Nguyen wrote:
> 
> 
> This goes way back.  I thought some where back (way back in the
> archive) for TCP,
> it was OK to include ServiceChangeAddress and it would be ignored.
> 
> Ok I will go along w/the understanding.
> It is just strange that we specify something for MG but not MGC
> because there is an
> understanding that MG is never the TCP server but MGC is.
> So for TCP MGC can specify the ServiceChangeAddress in the Reply but
> not MG.
> 
> Chuong
> 
> Paul Long wrote:
> 
> > Chuong,I was under the impression that the MG is always able to
> > establish a connection. Therefore, the MGC may specify a
> > ServiceChangeAddress regardless of whether it is using a
> > connection-oriented or connectionless transport for a given
> > association. An MG must therefore always be able to close the
> > current connection and establish a new one upon receipt of
> > ServiceChangeAddress from the MGC with a port number that is
> > different than the current one. Note that the new connection
> > continues the current association, so re-registration is not
> > appropriate.Paul LongipDialog, Inc.
> >
> >      -----Original Message-----
> >      From: owner-megaco@pit.comms.marconi.com
> >      [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of
> >      Chuong Nguyen
> >      Sent: Friday, May 11, 2001 4:22 PM
> >      To: Kaul, Bharat
> >      Cc: 'Paul Long'; megaco ietf
> >      Subject: Re: Implementors' Guide Update Editor's last Call
> >      Do we also need words for the Reply by MGC?
> >
> >
> >
> >     > "For UDP as a transport, the MG may specify the
> >     > transport
> >     > ServiceChangeAddress to be used by the MGC for sending
> >     > messages in the
> >     > ServiceChangeAddress parameter in the input
> >     > ServiceChangeDescriptor."
> >     >
> >     > to this:
> >     >
> >     > "In the ServiceChangeAddress parameter of the
> >     > ServiceChangeDescriptor, the
> >     > MG may specify the transport address to be used by the
> >     > MGC for sending
> >     > request messages.  So that the MGC does not have to
> >     > initiate a new
> >     > connection, however, the MG shall not specify a
> >     > ServiceChangeAddress if the
> >     > association is using a reliable, connection-oriented
> >     > transport."
> >     >
> >     > This explains the requirement somewhat and eliminates
> >     > the reference to a
> >     > particular transport. I would have just said,
> >     > "connection-oriented
> >     > protocol," since that would mean TCP in the case of IP,
> >     > but that term is not
> >     > used elsewhere in the spec, so I also said "reliable."
> >     > From a quick online
> >     > search, it appears that "reliable" and
> >     > "connection-oriented" are synonymous,
> >     > but we can state both just to be absolutely clear. What
> >     > do you think about
> >     > this new wording?
> >     >
> >     > Paul Long
> >     > ipDialog, Inc.
> >
> --
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
> 
>




From owner-megaco@fore.com  Mon May 14 05:21:47 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05843
	for ; Mon, 14 May 2001 05:21:46 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA06062;
	Mon, 14 May 2001 05:10:34 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA13863
	for megaco-list; Mon, 14 May 2001 05:03:21 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA13859
	for ; Mon, 14 May 2001 05:03:20 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA05385
	for ; Mon, 14 May 2001 05:03:15 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id TAA26201;
	Mon, 14 May 2001 19:01:54 +1000 (EST)
Received: from ericsson.com ([164.48.166.25])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id TAA18249;
	Mon, 14 May 2001 19:01:44 +1000 (EST)
Message-ID: <3AFEC972.381FBD47@ericsson.com>
Date: Mon, 14 May 2001 03:50:42 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Long 
CC: megaco ietf 
Subject: Re: Implementors' Guide Update Editor's last Call
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day Paul,

For items 6.16 and 11.6 i'll let Tom make the call on what he wants
here. I'm more of a ASN1 supporter so I'd prefer somebody who did the
ABNF to make the calls on it in this case.
6.58 is being discussed in another thread.

Cheers, Christian

PS: Yes the G'Day is a give away, I'm an Aussie.

Paul Long wrote:
> 
> Christian,
> 
> Here are my responses to your comments.
> 
> Item 6.16: It won't hurt to leave those parentheses in, but they do not
> change the syntax. ABNF concatenation has higher precendence (are
> "stickier") than alternation so these two constructs express exactly the
> same thing:
>         digitMapRange        = ("x" /  LWSP "[" LWSP digitLetter LWSP "]" LWSP )
>         digitMapRange        = ("x" / (LWSP "[" LWSP digitLetter LWSP "]" LWSP))
> A good analogy are the addition and multiplication operators in C. In the
> same way that the above expressions are equivalent, so are the following
> expressions equivalent:
>         X = A +  B * C * D * E;
>         X = A + (B * C * D * E);
> Notice that in addition to digitMapRange, the hexpart, alternativeValue,
> digitMap, and EOL constructs all exploit this ABNF precedence rule. If you
> believe that digitMapRange needs to be fixed, then these other constructs
> also need to be fixed.
> 
> Here is the relevant text from RFC2234:
> >>>>
> 3.10 Operator Precedence
> 
>    The various mechanisms described above have the following precedence,
>    from highest (binding tightest) at the top, to lowest and loosest at
>    the bottom:
> 
>         Strings, Names formation
>         Comment
>         Value range
>         Repetition
>         Grouping, Optional
>         Concatenation
>         Alternative
> <<<<
> 
> Also, the outer parentheses around a rule definition may debatably improve
> readability but are not required. Kinda bugs me that sometimes they are
> used, sometimes they are not. Not a big deal but stylistically inconsistent.
> This is the convention I'd personally like to see applied consistently
> throughout the ABNF:
>         digitMapRange        = "x" /  LWSP "[" LWSP digitLetter LWSP "]" LWSP
> 
> Item 6.58: Are we limiting the specification of a ServiceChangeAddress to
> just UDP because it would be "too hard" to implement for TCP (a couple more
> states in a state machine?) or because there is an inherent reason why it
> only makes sense to use it with an unreliable channel? If the latter, let's
> call it an "unreliable channel" and not "UDP," thus removing
> transport-specific text from the spec; if the former, I'd recommend we
> remove the limitation altogether and revert back to the original text.
> 
> Item 11.6: The problem I have with saying that "Parsers >>should<< accept
> whitespace..." (emphasis mine) is that this appears to be backing off the
> requirement in the ABNF that parsers _shall_ accept white space. See the
> second LWSP, below? At best, this sounds funny; at worst, contradictory.
>         localDescriptor      = LocalToken LBRKT octetString RBRKT
>         LBRKT                = LWSP %x7B LWSP
> 
> (Re: "G'Day". Like, are you an Aussie or something? :-)
> 
> Paul Long
> ipDialog, Inc.
> 
> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Thursday, May 10, 2001 9:43 PM
> To: Paul Long
> Cc: megaco ietf; bharat@trillium.com
> Subject: Re: Implementors' Guide Update Editor's last Call
> 
> G'Day Paul,
> 
> Please my comments below.
> 
> Cheers, Christian
> 
> Paul Long wrote:
> >
> > Christian,
> >
> > My comments:
> >
> > Item 6.16: Concatenation (e.g., A B) already takes precedence over the
> > alternative operator (e.g., A / B), so the proposed parentheses are
> > redundant. (See 3.10/RFC2234.) I guess it doesn't hurt to add them, but
> this
> > is technically a clarification and not a correction so it should go in
> > section 7.
> 
> [CHG] Its not a clarification as it changes the syntax. As it was
> already approved in the first IG I do not particular want to change it
> was its not broken.
> 
> >
> > Item 6.58: Inserting the text, "For UDP as a transport," precludes an MG
> > that uses TCP from also using ServiceChangeAddress. Not that _I_ want to
> do
> > such a thing, but is this a necessary constraint? Was this intended?
> 
> [CHG] Bharat asked this to be added so he can answer you on this. I'm
> quite happy to remove the "UDP as a transport" because I don't like
> trying H.248/Megaco procedures to transports.
> 
> >
> > Item 11.6: I know this is only clarifying text, but you should probably
> > change "Parsers should accept whitespace..." to "Parsers shall accept
> > whitespace..."
> [CHG] Any complaints from ABNF gurus on this? Tom what's your call?
> 
> >
> > Paul Long
> > ipDialog, Inc.




From owner-megaco@fore.com  Mon May 14 08:33:01 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08620
	for ; Mon, 14 May 2001 08:33:00 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA16032;
	Mon, 14 May 2001 07:54:57 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA03676
	for megaco-list; Mon, 14 May 2001 07:49:56 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA03668
	for ; Mon, 14 May 2001 07:49:55 -0400 (EDT)
From: prjain@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA15641
	for ; Mon, 14 May 2001 07:49:51 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4EBp2o28908;
	Mon, 14 May 2001 17:21:03 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A4C.003FA470 ; Mon, 14 May 2001 17:05:08 +0530
X-Lotus-FromDomain: HSS
To: Chuong Nguyen , megaco@fore.com
Message-ID: <65256A4C.003FA3D3.00@sandesh.hss.hns.com>
Date: Mon, 14 May 2001 17:12:40 +0530
Subject: Re: Service change method query
Mime-Version: 1.0
Content-type: multipart/mixed;
	Boundary="0__=5S5f4IJ8EptJyS0nMaLfsldehtZmwoWkMX1EpeE7lnj7xFj6wtCnaBRA"
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

--0__=5S5f4IJ8EptJyS0nMaLfsldehtZmwoWkMX1EpeE7lnj7xFj6wtCnaBRA
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Hi,
I think the meaning of handoff is that MGC is not able to handle the MG who is
either trying to register or with which MGC was communicating with and thus MGC
is re-directing the gateway to a new one. Now whether it happens at initial
phase or at subsequent stages during the life-cycle of the association between
the two, method should always be handoff. The "Service Change Reason" should be
able to convey whether it was a "Cold Boot" or "Warm Boot" or "Service Restored"
or anything else.

In your case, what shall be the Service Change Reason while sending the command
to the re-directed MGC with proposed method as "Restart"? Would it be "MGC
directed change" or the same as that sent in the Service Change request to the
first MGC?
If it is not "MGC directed change", the new MGC will not come to know about the
re-direction at all. This seems to be inappropriate as MG is a Slave entity and
everything happening at MG should be known to MGC.

I would say either "method" or "reason" should be present  in the re-directed
request to convey the information that MG was re-directed (since MGC may take
some action based on this whether the request is re-directed or not). And as per
my understanding, it is the "method" field which should convey this.

And the "reason" field should convey the type of recovery whether it was cold
boot or warm boot etc if it happens at start-up. Moreover at subsequent stages,
the reason should be "MGC Impending Failure".


Please clarify.
Regards,
Prashant Jain





Chuong Nguyen  on 05/11/2001 11:08:31 PM

To:   megaco@fore.com
cc:    (bcc: Prashant Jain/HSS)

Subject:  Re: Service change method query




I am agreeing w/Madhu that for initial registration it should be Restart
if MGC redirects.

I was just expanding on Handoff and how new MGC should deals w/Restart
vs Handoff
which to new MGC is like a new registration and not a re-registration.


Tom-PT Taylor wrote:

> But Madhu makes the valid point that this is an initial registration
> attempt by the MG which has been redirected by the first MGC it
> tried.  The MG doesn't necessarily have any calls in progress.
>
>      -----Original Message-----
>      From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
>      Sent: Friday, May 11, 2001 11:57 AM
>      To: megaco@fore.com
>      Subject: Re: Service change method query
>
>
>      There is another difference why Handoff should be used
>      instead of Restart by the MG
>      when MG tries to connect to the new MGC.
>
>      I think the intend was to let the new MGC knows that MG
>      stills has calls in contexts.
>      Therefore either new MGC does an Audit towards MG to rebuild
>      all necessary
>      info about MG or use either SIP, SIP-T, BICC, gods know what
>      to get whatever
>      info it needs from old MGC before it goes out of service.
>
>      Chuong
>
>
>      Madhu Babu Brahmanapally wrote:
>
>     > HI Vivek,
>     >
>     > In page 57, First paragraph, its mentioned that the MGC
>     > may return a
>     > ServiceChangeMgcId describing the MGC to be contacted. It
>     > is also mentioned
>     > that MG will "REISSUE" the service change command to the
>     > new MGC specified.
>     > Hence, the service Change method to be used should be
>     > "restart" only. This
>     > shouldn't be treated as a handoff initiated by the MGC.
>     > The MG is just
>     > retrying the same registration with the new MGC.
>     >
>     > Handoff is used by MGC when the it is going out of
>     > service. When the MG
>     > attempts to establish a new association with the newly
>     > specified MGC it uses
>     > the Handoff method.
>     >
>     > Regards
>     > Madhubabu
>     >
>     > -----Original Message-----
>     > From: owner-megaco@pit.comms.marconi.com
>     > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of
>     > vibansal@hss.hns.com
>     > Sent: Tuesday, April 24, 2001 8:23 AM
>     > To: megaco@fore.com
>     > Subject: Service change method query
>     >
>     > Hi All
>     >
>     > In the first service change request from MG, if the MGC
>     > replies with the
>     > MGCidtotry, then with what service change method and
>     > reason does MG send the
>     > request to new MGC?
>     >
>     > There could be two possibilities:
>     > 1. Since this is same as a Handoff scenario, MG can use
>     > Handoff method.
>     > 2. Since it was the first registration request, MG can use
>     > Restart method.
>     >
>     > Kindly clearify this.
>     >
>     > Regards
>     > Vivek Bansal
>     > Hughes Software System
>
>      --
>        Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>        1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>        **** The opinions expressed are not those of Alcatel USA, Inc ****
>
>
>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****




--0__=5S5f4IJ8EptJyS0nMaLfsldehtZmwoWkMX1EpeE7lnj7xFj6wtCnaBRA
Content-type: text/html;
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwv
L2VuIj4NCjxodG1sPg0KSSZuYnNwO2FtIGFncmVlaW5nIHcvTWFkaHUgdGhhdCBmb3IgaW5pdGlh
bCByZWdpc3RyYXRpb24gaXQgc2hvdWxkIGJlIFJlc3RhcnQNCmlmIE1HQyZuYnNwO3JlZGlyZWN0
cy4NCjxwPkkmbmJzcDt3YXMganVzdCBleHBhbmRpbmcgb24gSGFuZG9mZiBhbmQgaG93IG5ldyBN
R0Mgc2hvdWxkIGRlYWxzIHcvUmVzdGFydA0KdnMgSGFuZG9mZg0KPGJyPndoaWNoIHRvIG5ldyBN
R0MgaXMgbGlrZSBhIG5ldyByZWdpc3RyYXRpb24gYW5kIG5vdCBhIHJlLXJlZ2lzdHJhdGlvbi4N
Cjxicj4mbmJzcDsNCjxwPlRvbS1QVCBUYXlsb3Igd3JvdGU6DQo8YmxvY2txdW90ZSBUWVBFPUNJ
VEU+PHNwYW4gY2xhc3M9MzU3MTczODE2LTExMDUyMDAxPjxmb250IGZhY2U9IkFyaWFsIj48Zm9u
dCBjb2xvcj0iIzAwMDBGRiI+PGZvbnQgc2l6ZT0tMT5CdXQNCk1hZGh1IG1ha2VzIHRoZSB2YWxp
ZCBwb2ludCB0aGF0IHRoaXMgaXMgYW4gaW5pdGlhbCByZWdpc3RyYXRpb24gYXR0ZW1wdA0KYnkg
dGhlIE1HIHdoaWNoIGhhcyBiZWVuIHJlZGlyZWN0ZWQgYnkgdGhlIGZpcnN0IE1HQyBpdCB0cmll
ZC4mbmJzcDsgVGhlDQpNRyBkb2Vzbid0IG5lY2Vzc2FyaWx5IGhhdmUgYW55IGNhbGxzIGluIHBy
b2dyZXNzLjwvZm9udD48L2ZvbnQ+PC9mb250Pjwvc3Bhbj4NCjxibG9ja3F1b3RlIA0Kc3R5bGU9
IkJPUkRFUi1MRUZUOiAjMDAwMGZmIDJweCBzb2xpZDsgTUFSR0lOLUxFRlQ6IDVweDsgUEFERElO
Ry1MRUZUOiA1cHgiPg0KPGRpdiBjbGFzcz0iT3V0bG9va01lc3NhZ2VIZWFkZXIiIGRpcj0ibHRy
Ij48Zm9udCBmYWNlPSJUYWhvbWEiPjxmb250IHNpemU9LTE+LS0tLS1PcmlnaW5hbA0KTWVzc2Fn
ZS0tLS0tPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBmYWNlPSJUYWhvbWEiPjxmb250IHNpemU9
LTE+PGI+RnJvbTo8L2I+IENodW9uZyBOZ3V5ZW4gWzxBIEhSRUY9Im1haWx0bzpDaHVvbmcuTmd1
eWVuQHVzYS5hbGNhdGVsLmNvbSI+bWFpbHRvOkNodW9uZy5OZ3V5ZW5AdXNhLmFsY2F0ZWwuY29t
PC9BPl08L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGZhY2U9IlRhaG9tYSI+PGZvbnQgc2l6ZT0t
MT48Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXkgMTEsIDIwMDENCjExOjU3IEFNPC9mb250PjwvZm9u
dD4NCjxicj48Zm9udCBmYWNlPSJUYWhvbWEiPjxmb250IHNpemU9LTE+PGI+VG86PC9iPiBtZWdh
Y29AZm9yZS5jb208L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGZhY2U9IlRhaG9tYSI+PGZvbnQg
c2l6ZT0tMT48Yj5TdWJqZWN0OjwvYj4gUmU6IFNlcnZpY2UgY2hhbmdlDQptZXRob2QgcXVlcnk8
L2ZvbnQ+PC9mb250PjwvZGl2Pg0KDQo8cD48YnI+VGhlcmUgaXMgYW5vdGhlciBkaWZmZXJlbmNl
IHdoeSBIYW5kb2ZmIHNob3VsZCBiZSB1c2VkIGluc3RlYWQgb2YNClJlc3RhcnQgYnkgdGhlIE1H
DQo8YnI+d2hlbiBNRyB0cmllcyB0byBjb25uZWN0IHRvIHRoZSBuZXcgTUdDLg0KPHA+SSB0aGlu
ayB0aGUgaW50ZW5kIHdhcyB0byBsZXQgdGhlIG5ldyBNR0Mga25vd3MgdGhhdCBNRyBzdGlsbHMg
aGFzIGNhbGxzDQppbiBjb250ZXh0cy4NCjxicj5UaGVyZWZvcmUgZWl0aGVyIG5ldyBNR0MgZG9l
cyBhbiBBdWRpdCB0b3dhcmRzIE1HIHRvIHJlYnVpbGQgYWxsIG5lY2Vzc2FyeQ0KPGJyPmluZm8g
YWJvdXQgTUcgb3IgdXNlIGVpdGhlciBTSVAsIFNJUC1ULCBCSUNDLCBnb2RzIGtub3cgd2hhdCB0
byBnZXQNCndoYXRldmVyDQo8YnI+aW5mbyBpdCBuZWVkcyBmcm9tIG9sZCBNR0MgYmVmb3JlIGl0
IGdvZXMgb3V0IG9mIHNlcnZpY2UuDQo8cD5DaHVvbmcNCjxicj4mbmJzcDsNCjxwPk1hZGh1IEJh
YnUgQnJhaG1hbmFwYWxseSB3cm90ZToNCjxibG9ja3F1b3RlIFRZUEU9IkNJVEUiPkhJIFZpdmVr
LA0KPHA+SW4gcGFnZSA1NywgRmlyc3QgcGFyYWdyYXBoLCBpdHMgbWVudGlvbmVkIHRoYXQgdGhl
IE1HQyBtYXkgcmV0dXJuIGENCjxicj5TZXJ2aWNlQ2hhbmdlTWdjSWQgZGVzY3JpYmluZyB0aGUg
TUdDIHRvIGJlIGNvbnRhY3RlZC4gSXQgaXMgYWxzbyBtZW50aW9uZWQNCjxicj50aGF0IE1HIHdp
bGwgIlJFSVNTVUUiIHRoZSBzZXJ2aWNlIGNoYW5nZSBjb21tYW5kIHRvIHRoZSBuZXcgTUdDIHNw
ZWNpZmllZC4NCjxicj5IZW5jZSwgdGhlIHNlcnZpY2UgQ2hhbmdlIG1ldGhvZCB0byBiZSB1c2Vk
IHNob3VsZCBiZSZuYnNwOyAicmVzdGFydCINCm9ubHkuIFRoaXMNCjxicj5zaG91bGRuJ3QgYmUg
dHJlYXRlZCBhcyBhIGhhbmRvZmYgaW5pdGlhdGVkIGJ5IHRoZSBNR0MuIFRoZSBNRyBpcyBqdXN0
DQo8YnI+cmV0cnlpbmcgdGhlIHNhbWUgcmVnaXN0cmF0aW9uIHdpdGggdGhlIG5ldyBNR0MuDQo8
cD5IYW5kb2ZmIGlzIHVzZWQgYnkgTUdDIHdoZW4gdGhlIGl0IGlzIGdvaW5nIG91dCBvZiBzZXJ2
aWNlLiBXaGVuIHRoZQ0KTUcNCjxicj5hdHRlbXB0cyB0byBlc3RhYmxpc2ggYSBuZXcgYXNzb2Np
YXRpb24gd2l0aCB0aGUgbmV3bHkgc3BlY2lmaWVkIE1HQw0KaXQgdXNlcw0KPGJyPnRoZSBIYW5k
b2ZmIG1ldGhvZC4NCjxwPlJlZ2FyZHMNCjxicj5NYWRodWJhYnUNCjxwPi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQo8YnI+RnJvbTogb3duZXItbWVnYWNvQHBpdC5jb21tcy5tYXJjb25pLmNv
bQ0KPGJyPls8YSBocmVmPSJtYWlsdG86b3duZXItbWVnYWNvQHBpdC5jb21tcy5tYXJjb25pLmNv
bSI+bWFpbHRvOm93bmVyLW1lZ2Fjb0BwaXQuY29tbXMubWFyY29uaS5jb208L2E+XU9uDQpCZWhh
bGYgT2YNCjxicj52aWJhbnNhbEBoc3MuaG5zLmNvbQ0KPGJyPlNlbnQ6IFR1ZXNkYXksIEFwcmls
IDI0LCAyMDAxIDg6MjMgQU0NCjxicj5UbzogbWVnYWNvQGZvcmUuY29tDQo8YnI+U3ViamVjdDog
U2VydmljZSBjaGFuZ2UgbWV0aG9kIHF1ZXJ5DQo8cD5IaSBBbGwNCjxwPkluIHRoZSBmaXJzdCBz
ZXJ2aWNlIGNoYW5nZSByZXF1ZXN0IGZyb20gTUcsIGlmIHRoZSBNR0MgcmVwbGllcyB3aXRoDQp0
aGUNCjxicj5NR0NpZHRvdHJ5LCB0aGVuIHdpdGggd2hhdCBzZXJ2aWNlIGNoYW5nZSBtZXRob2Qg
YW5kIHJlYXNvbiBkb2VzIE1HDQpzZW5kIHRoZQ0KPGJyPnJlcXVlc3QgdG8gbmV3IE1HQz8NCjxw
PlRoZXJlIGNvdWxkIGJlIHR3byBwb3NzaWJpbGl0aWVzOg0KPGJyPjEuIFNpbmNlIHRoaXMgaXMg
c2FtZSBhcyBhIEhhbmRvZmYgc2NlbmFyaW8sIE1HIGNhbiB1c2UgSGFuZG9mZiBtZXRob2QuDQo8
YnI+Mi4gU2luY2UgaXQgd2FzIHRoZSBmaXJzdCByZWdpc3RyYXRpb24gcmVxdWVzdCwgTUcgY2Fu
IHVzZSBSZXN0YXJ0DQptZXRob2QuDQo8cD5LaW5kbHkgY2xlYXJpZnkgdGhpcy4NCjxwPlJlZ2Fy
ZHMNCjxicj5WaXZlayBCYW5zYWwNCjxicj5IdWdoZXMgU29mdHdhcmUgU3lzdGVtPC9ibG9ja3F1
b3RlPg0KDQo8cHJlPi0tJm5ic3A7DQombmJzcDsgQWxjYXRlbCBVU0EsIEluYyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBJbnRlcm5ldDogQ2h1b25nLk5ndXllbkB1c2EuYWxjYXRlbC5jb20NCiZuYnNwOyAxMDAw
IENvaXQgUm9hZCBQbGFubywgVGV4YXMgNzUwNzUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUGhvbmU6Jm5ic3A7Jm5ic3A7Jm5ic3A7
ICg5NzIpIDUxOS00NjEzDQombmJzcDsgKioqKiBUaGUgb3BpbmlvbnMgZXhwcmVzc2VkIGFyZSBu
b3QgdGhvc2Ugb2YgQWxjYXRlbCBVU0EsIEluYyAqKioqPC9wcmU+DQombmJzcDs8L2Jsb2NrcXVv
dGU+DQo8L2Jsb2NrcXVvdGU+DQoNCjxwcmU+LS0mbmJzcDsNCiZuYnNwOyBBbGNhdGVsIFVTQSwg
SW5jJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IEludGVybmV0OiBDaHVvbmcuTmd1eWVuQHVzYS5hbGNhdGVsLmNv
bQ0KJm5ic3A7IDEwMDAgQ29pdCBSb2FkIFBsYW5vLCBUZXhhcyA3NTA3NSZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQaG9uZTombmJz
cDsmbmJzcDsmbmJzcDsgKDk3MikgNTE5LTQ2MTMNCiZuYnNwOyAqKioqIFRoZSBvcGluaW9ucyBl
eHByZXNzZWQgYXJlIG5vdCB0aG9zZSBvZiBBbGNhdGVsIFVTQSwgSW5jICoqKio8L3ByZT4NCiZu
YnNwOzwvaHRtbD4NCg0K

--0__=5S5f4IJ8EptJyS0nMaLfsldehtZmwoWkMX1EpeE7lnj7xFj6wtCnaBRA--



From owner-megaco@fore.com  Mon May 14 10:26:59 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13272
	for ; Mon, 14 May 2001 10:26:59 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA29307;
	Mon, 14 May 2001 10:15:03 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA12094
	for megaco-list; Mon, 14 May 2001 10:11:57 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA12084
	for ; Mon, 14 May 2001 10:11:56 -0400 (EDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA28997
	for ; Mon, 14 May 2001 10:11:53 -0400 (EDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA03741
	for ; Mon, 14 May 2001 09:11:53 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4EEBrC06379
	for ; Mon, 14 May 2001 09:11:53 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4EEBg105384
	for ; Mon, 14 May 2001 09:11:42 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4EEBgO17928
	for ; Mon, 14 May 2001 09:11:42 -0500 (CDT)
Message-ID: <3AFFE79E.68754CF8@usa.alcatel.com>
Date: Mon, 14 May 2001 09:11:42 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Service change method query
References: <65256A4C.003FA3D3.00@sandesh.hss.hns.com>
Content-Type: multipart/alternative;
 boundary="------------07AE560563E39C0813B67CD0"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------07AE560563E39C0813B67CD0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

First I think Section 11.2 Cold Start already covers what Method should be used
even for
redirection during registration - Restart.

Secondly, Section 11.5 Failure of MGC already covers HandOff.
   In partial failure, or manual maintenance reasons, an MGC may wish to
   direct its controlled MGs to use a different MGC.  To do so, it sends
   a ServiceChange method to the MG with a "HandOff" method, and its
   designated replacement in ServiceChangeMgcId. The MG should send a
   ServiceChange message with a "Handoff" method and a "MGC directed
   change" reason to the designated MGC.

"Manual maintenance" is not the same as Registration redirection which is done
automatically w/o operator's intervention.

To me "Manual maintenance" is the MGC operator moving the MG to another MGC
for whatever reason the operator wants to do it.

See additonal comments below:
Chuong

prjain@hss.hns.com wrote:

> Hi,
> I think the meaning of handoff is that MGC is not able to handle the MG who is
> either trying to register or with which MGC was communicating with and thus MGC
> is re-directing the gateway to a new one. Now whether it happens at initial
> phase or at subsequent stages during the life-cycle of the association between
> the two, method should always be handoff. The "Service Change Reason" should be
> able to convey whether it was a "Cold Boot" or "Warm Boot" or "Service Restored"
> or anything else.
>
> In your case, what shall be the Service Change Reason while sending the command
> to the re-directed MGC with proposed method as "Restart"? Would it be "MGC
> directed change" or the same as that sent in the Service Change request to the
> first MGC?

  According to 11.2 and if it was a Cold Start then Cold Boot.

>
> If it is not "MGC directed change", the new MGC will not come to know about the
> re-direction at all. This seems to be inappropriate as MG is a Slave entity and
> everything happening at MG should be known to MGC.

 The new MGC has to be provisioned to handle MG in the first place before it
              accepts the MG registration.  Just because an MG sends a
ServiceChange w/
             "MGC directed change", it does not mean that the MGC has to accept
that MG.
             It is still up to the MGC to accept the MG registration.
             Now what does the MGC use to determine whether to accept the MG.
             It is definitely not just based on "MGC directed change" Reason.
             If I am an operator of the MGCs, I would want a little more control
over which MG
             registration to accept by either some provisioning and coordination
between MGCs
             before the HandOff even occurrs.


>
>
> I would say either "method" or "reason" should be present  in the re-directed
> request to convey the information that MG was re-directed (since MGC may take
> some action based on this whether the request is re-directed or not). And as per
> my understanding, it is the "method" field which should convey this.
>
> And the "reason" field should convey the type of recovery whether it was cold
> boot or warm boot etc if it happens at start-up. Moreover at subsequent stages,
> the reason should be "MGC Impending Failure".
>
> Please clarify.
> Regards,
> Prashant Jain
>
> Chuong Nguyen  on 05/11/2001 11:08:31 PM
>
> To:   megaco@fore.com
> cc:    (bcc: Prashant Jain/HSS)
>
> Subject:  Re: Service change method query
>
> I am agreeing w/Madhu that for initial registration it should be Restart
> if MGC redirects.
>
> I was just expanding on Handoff and how new MGC should deals w/Restart
> vs Handoff
> which to new MGC is like a new registration and not a re-registration.
>
> Tom-PT Taylor wrote:
>
> > But Madhu makes the valid point that this is an initial registration
> > attempt by the MG which has been redirected by the first MGC it
> > tried.  The MG doesn't necessarily have any calls in progress.
> >
> >      -----Original Message-----
> >      From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> >      Sent: Friday, May 11, 2001 11:57 AM
> >      To: megaco@fore.com
> >      Subject: Re: Service change method query
> >
> >
> >      There is another difference why Handoff should be used
> >      instead of Restart by the MG
> >      when MG tries to connect to the new MGC.
> >
> >      I think the intend was to let the new MGC knows that MG
> >      stills has calls in contexts.
> >      Therefore either new MGC does an Audit towards MG to rebuild
> >      all necessary
> >      info about MG or use either SIP, SIP-T, BICC, gods know what
> >      to get whatever
> >      info it needs from old MGC before it goes out of service.
> >
> >      Chuong
> >
> >
> >      Madhu Babu Brahmanapally wrote:
> >
> >     > HI Vivek,
> >     >
> >     > In page 57, First paragraph, its mentioned that the MGC
> >     > may return a
> >     > ServiceChangeMgcId describing the MGC to be contacted. It
> >     > is also mentioned
> >     > that MG will "REISSUE" the service change command to the
> >     > new MGC specified.
> >     > Hence, the service Change method to be used should be
> >     > "restart" only. This
> >     > shouldn't be treated as a handoff initiated by the MGC.
> >     > The MG is just
> >     > retrying the same registration with the new MGC.
> >     >
> >     > Handoff is used by MGC when the it is going out of
> >     > service. When the MG
> >     > attempts to establish a new association with the newly
> >     > specified MGC it uses
> >     > the Handoff method.
> >     >
> >     > Regards
> >     > Madhubabu
> >     >
> >     > -----Original Message-----
> >     > From: owner-megaco@pit.comms.marconi.com
> >     > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of
> >     > vibansal@hss.hns.com
> >     > Sent: Tuesday, April 24, 2001 8:23 AM
> >     > To: megaco@fore.com
> >     > Subject: Service change method query
> >     >
> >     > Hi All
> >     >
> >     > In the first service change request from MG, if the MGC
> >     > replies with the
> >     > MGCidtotry, then with what service change method and
> >     > reason does MG send the
> >     > request to new MGC?
> >     >
> >     > There could be two possibilities:
> >     > 1. Since this is same as a Handoff scenario, MG can use
> >     > Handoff method.
> >     > 2. Since it was the first registration request, MG can use
> >     > Restart method.
> >     >
> >     > Kindly clearify this.
> >     >
> >     > Regards
> >     > Vivek Bansal
> >     > Hughes Software System
> >
> >      --
> >        Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
> >        1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
> >        **** The opinions expressed are not those of Alcatel USA, Inc ****
> >
> >
> >
> --
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>
>   ------------------------------------------------------------------------
>                   Name: att1.htm
>    att1.htm       Type: Hypertext Markup Language (text/html)
>               Encoding: base64
>            Description: Internet HTML

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------07AE560563E39C0813B67CD0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



First I think Section 11.2 Cold Start already covers what Method should
be used even for

redirection during registration - Restart.

Secondly, Section 11.5 Failure of MGC already covers HandOff.

   In partial failure, or manual maintenance reasons,
an MGC may wish to

   direct its controlled MGs to use a different MGC. 
To do so, it sends

   a ServiceChange method to the MG with a "HandOff" method,
and its

   designated replacement in ServiceChangeMgcId. The MG
should send a

   ServiceChange message with a "Handoff" method and a
"MGC directed

   change" reason to the designated MGC.

"Manual maintenance" is not the same as Registration redirection which
is done

automatically w/o operator's intervention.

To me "Manual maintenance" is the MGC operator moving the MG to
another MGC

for whatever reason the operator wants to do it.

See additonal comments below:

Chuong

prjain@hss.hns.com wrote:

Hi,

I think the meaning of handoff is that MGC is not able to handle the
MG who is

either trying to register or with which MGC was communicating with
and thus MGC

is re-directing the gateway to a new one. Now whether it happens at
initial

phase or at subsequent stages during the life-cycle of the association
between

the two, method should always be handoff. The "Service Change Reason"
should be

able to convey whether it was a "Cold Boot" or "Warm Boot" or "Service
Restored"

or anything else.

In your case, what shall be the Service Change Reason while sending
the command

to the re-directed MGC with proposed method as "Restart"? Would it
be "MGC

directed change" or the same as that sent in the Service Change request
to the

first MGC?

<cnn>  According to 11.2 and if it was a Cold Start then Cold Boot.

 

If it is not "MGC directed change", the new MGC will not come to know
about the

re-direction at all. This seems to be inappropriate as MG is a Slave
entity and

everything happening at MG should be known to MGC.

<cnn> The new MGC has to be provisioned to handle MG in the first place
before it

             
accepts the MG registration.  Just because an MG sends a ServiceChange
w/

            
"MGC directed change", it does not mean that the MGC has to accept
that MG.

            
It is still up to the MGC to accept the MG registration.

            
Now what does the MGC use to determine whether to accept the MG.

            
It is definitely not just based on "MGC directed change" Reason.

            
If I am an operator of the MGCs, I would want a little more control
over which MG

            
registration to accept by either some provisioning and coordination between
MGCs

            
before the HandOff even occurrs.

 

 

I would say either "method" or "reason" should be present  in the
re-directed

request to convey the information that MG was re-directed (since MGC
may take

some action based on this whether the request is re-directed or not).
And as per

my understanding, it is the "method" field which should convey this.

And the "reason" field should convey the type of recovery whether it
was cold

boot or warm boot etc if it happens at start-up. Moreover at subsequent
stages,

the reason should be "MGC Impending Failure".

Please clarify.

Regards,

Prashant Jain

Chuong Nguyen <Chuong.Nguyen@usa.alcatel.com> on 05/11/2001 11:08:31
PM

To:   megaco@fore.com

cc:    (bcc: Prashant Jain/HSS)

Subject:  Re: Service change method query

I am agreeing w/Madhu that for initial registration it should be Restart

if MGC redirects.

I was just expanding on Handoff and how new MGC should deals w/Restart

vs Handoff

which to new MGC is like a new registration and not a re-registration.

Tom-PT Taylor wrote:

> But Madhu makes the valid point that this is an initial registration

> attempt by the MG which has been redirected by the first MGC it

> tried.  The MG doesn't necessarily have any calls in progress.

>

>      -----Original Message-----

>      From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]

>      Sent: Friday, May 11, 2001 11:57 AM

>      To: megaco@fore.com

>      Subject: Re: Service change method
query

>

>

>      There is another difference why Handoff
should be used

>      instead of Restart by the MG

>      when MG tries to connect to the new
MGC.

>

>      I think the intend was to let the new
MGC knows that MG

>      stills has calls in contexts.

>      Therefore either new MGC does an Audit
towards MG to rebuild

>      all necessary

>      info about MG or use either SIP, SIP-T,
BICC, gods know what

>      to get whatever

>      info it needs from old MGC before it
goes out of service.

>

>      Chuong

>

>

>      Madhu Babu Brahmanapally wrote:

>

>     > HI Vivek,

>     >

>     > In page 57, First paragraph, its mentioned
that the MGC

>     > may return a

>     > ServiceChangeMgcId describing the MGC to
be contacted. It

>     > is also mentioned

>     > that MG will "REISSUE" the service change
command to the

>     > new MGC specified.

>     > Hence, the service Change method to be
used should be

>     > "restart" only. This

>     > shouldn't be treated as a handoff initiated
by the MGC.

>     > The MG is just

>     > retrying the same registration with the
new MGC.

>     >

>     > Handoff is used by MGC when the it is going
out of

>     > service. When the MG

>     > attempts to establish a new association
with the newly

>     > specified MGC it uses

>     > the Handoff method.

>     >

>     > Regards

>     > Madhubabu

>     >

>     > -----Original Message-----

>     > From: owner-megaco@pit.comms.marconi.com

>     > [mailto:owner-megaco@pit.comms.marconi.com]On
Behalf Of

>     > vibansal@hss.hns.com

>     > Sent: Tuesday, April 24, 2001 8:23 AM

>     > To: megaco@fore.com

>     > Subject: Service change method query

>     >

>     > Hi All

>     >

>     > In the first service change request from
MG, if the MGC

>     > replies with the

>     > MGCidtotry, then with what service change
method and

>     > reason does MG send the

>     > request to new MGC?

>     >

>     > There could be two possibilities:

>     > 1. Since this is same as a Handoff scenario,
MG can use

>     > Handoff method.

>     > 2. Since it was the first registration
request, MG can use

>     > Restart method.

>     >

>     > Kindly clearify this.

>     >

>     > Regards

>     > Vivek Bansal

>     > Hughes Software System

>

>      --

>        Alcatel USA, Inc            
Internet: Chuong.Nguyen@usa.alcatel.com

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

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

>

>

>

--

  Alcatel USA, Inc            
Internet: Chuong.Nguyen@usa.alcatel.com

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

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

  ------------------------------------------------------------------------

                 
Name: att1.htm

   att1.htm       Type: Hypertext
Markup Language (text/html)

             
Encoding: base64

           Description:
Internet HTML



-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------07AE560563E39C0813B67CD0--



From owner-megaco@fore.com  Mon May 14 12:11:05 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16487
	for ; Mon, 14 May 2001 12:11:04 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA10746;
	Mon, 14 May 2001 12:02:39 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA17009
	for megaco-list; Mon, 14 May 2001 11:59:45 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA17002
	for ; Mon, 14 May 2001 11:59:43 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 14 May 2001 11:59:16 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F5E8@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Dan Elbert'" ,
        "'megaco@fore.com'"
	 ,
        "'Chuong Nguyen'" 
Subject: RE: Implementors' Guide Update Editor's last Call - MGC failure
Date: Mon, 14 May 2001 11:59:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0DC8E.E1830220"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DC8E.E1830220
Content-Type: text/plain;
	charset="ISO-8859-1"

I think that a restart of a termination that is already in service should be
treated 
as a nop by an MGC.
 
I have no objection to adding an explicit no-op method, but I don't think it
is needed.
 
Brian
-----Original Message-----
From: Dan Elbert [mailto:DElbert@radvision.com]
Sent: Friday, May 11, 2001 5:57 PM
To: 'megaco@fore.com'; 'Chuong Nguyen'
Subject: RE: Implementors' Guide Update Editor's last Call - MGC failure


Using a fully specified terminationID can disrupt the operation of the
termination (for example if the termination is in a call).
It's not clear what a "bogus" termination is, if the MGC receives a SVC from
an MG termination it can assume that this termination is real and start
sending audits or commands.
Yes, by poll I mean some type of heartbeat as the MG needs to know if the
MGC is alive.
Brian Rosen suggested in the past to use SVC with Restart method for this
purpose, I don't think that there was any mantion if this should be done
with id=root or other.
 
Dan
 
-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Friday, May 11, 2001 5:38 PM
To: megaco@fore.com
Subject: Re: Implementors' Guide Update Editor's last Call - MGC failure
 

The intend was not to use ROOT but a fully specified terminationID or even
better a 
known invalid terminationID (A bogus terminationID that the sender knows is
not valid and is 
used specifically for heartbeat purpose).  The idea is to get some kind of
responses. 
"poll" do you mean heartbeat like msg to from MG to MGC or something else
here. 
Where did you see that Restart w/ROOT is used as a heartbeat/poll? 
  
Chuong 
Dan Elbert wrote: 
Hi
After reviewing the issue of MGC failure ( when the MG is connected trough
UDP ) I believe that there is no satisfactory way for the MG to poll the MGC
to see if the MGC is still alive. Using a ServiceChange with "Restart"
method and termination id of "root" may cause the MGC to assume that the MG
restarted and can affect the state of a call in progress. 
I think that it would be good to add a ServiceChange method "noop" : 
Noop : Can be used by the MG (with unreliable protocols) to obtain a
response from the MGC or detect a communication failure. When receiving this
SVC the MGC should take no action other that reply. 
If this is not acceptable, then I think that some clarification is needed as
when a SVC with restart method should be considered "noop" by the MGC. 
Dan Elbert 
RADVISION 
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  

------_=_NextPart_001_01C0DC8E.E1830220
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable













I think that=20
a restart of a termination that is already in service should be treated =




as a nop=20
by=20
an MGC.


 


I have no=20
objection to adding an explicit no-op method, but I don't think it is=20
needed.


 


Brian



  
-----Original Message-----
From: Dan Elbert=20
  [mailto:DElbert@radvision.com]
Sent: Friday, May 11, 2001 =
5:57=20
  PM
To: 'megaco@fore.com'; 'Chuong =
Nguyen'
Subject: RE:=20
  Implementors' Guide Update Editor's last Call - MGC=20
  failure


  

  
Using=20
  a fully specified terminationID can disrupt the operation of the =
termination=20
  (for example if the termination is in a=20
  call).

  
It’s=20
  not clear what a “bogus” termination is, if the MGC =
receives a SVC from an MG=20
  termination it can assume that this termination is real and start =
sending=20
  audits or commands.

  
Yes,=20
  by poll I mean some type of heartbeat as the MG needs to know if the =
MGC is=20
  alive.

  
Brian=20
  Rosen suggested in the past to use SVC with Restart method for this =
purpose, I=20
  don’t think that there was any mantion if this should be done =
with id=3Droot or=20
  other.

  
 
=

  
Dan

  
 
=

  
-----Original=20
  Message-----
From: =
Chuong=20
  Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Friday, May 11, 2001 =
5:38=20
  PM
To:=20
  megaco@fore.com
Subject: Re:=20
  Implementors' Guide Update Editor's last Call - MGC =
failure

  
 

  
 =

The intend=20
  was not to use ROOT but a fully specified terminationID or even =
better a=20
  
known invalid terminationID (A bogus terminationID that the =
sender knows=20
  is not valid and is 
used specifically for heartbeat =
purpose).  The=20
  idea is to get some kind of responses. 

  
"poll" do you =
mean=20
  heartbeat like msg to from MG to MGC or something else here.=20
  

  
Where did you =
see that=20
  Restart w/ROOT is used as a heartbeat/poll? 
  =


  
Chuong =


  
Dan Elbert =
wrote:=20
  

  
Hi

  
After=20
  reviewing the issue of MGC failure ( when the MG is connected trough =
UDP ) I=20
  believe that there is no satisfactory way for the MG to poll the MGC =
to see if=20
  the MGC is still alive. Using a ServiceChange with "Restart" method =
and=20
  termination id of "root" may cause the MGC to assume that the MG =
restarted and=20
  can affect the state of a call in =
progress. 

  
I=20
  think that it would be good to add a ServiceChange method "noop"=20
  : 

  
Noop=20
  : Can be used by the MG (with unreliable protocols) to obtain a =
response from=20
  the MGC or detect a communication failure. When receiving this SVC =
the MGC=20
  should take no action other that =
reply. 

  
If=20
  this is not acceptable, then I think that some clarification is =
needed as when=20
  a SVC with restart method should be considered "noop" by the=20
  MGC. 

  
Dan=20
  Elbert 

  
RADVISION 
-- 
  Alcatel USA, =
Inc           &nb=
sp; Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, =
Texas 75075           =
Phone:    (972) 519-4613
  **** The opinions =
expressed are not those of Alcatel USA, Inc ****

  
 =20
  


------_=_NextPart_001_01C0DC8E.E1830220--


From owner-megaco@fore.com  Mon May 14 12:18:29 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16669
	for ; Mon, 14 May 2001 12:18:29 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA11852;
	Mon, 14 May 2001 12:11:41 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA20312
	for megaco-list; Mon, 14 May 2001 12:09:27 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA20290
	for ; Mon, 14 May 2001 12:09:22 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA11535
	for ; Mon, 14 May 2001 12:09:18 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Mon, 14 May 2001 11:10:32 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD9494524FA48@RADVPOST>
From: Dan Elbert 
To: "'Rosen, Brian'" ,
        Dan Elbert
	 ,
        "'megaco@fore.com'" ,
        "'Chuong Nguyen'" 
Subject: RE: Implementors' Guide Update Editor's last Call - MGC failure
Date: Mon, 14 May 2001 11:10:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0DC90.6291D660"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DC90.6291D660
Content-Type: text/plain;
	charset="iso-8859-1"

OK, then maybe we can have some wording to that effect in the Implementor's
guide. 
I still think that in some scenarios this may be confusing or require
greater complexity in the MGC . ( for example if the termination sends a SVC
going down, but is not received by the MGC, and immediately a SVC with
restart which is received, so in this case the state of the MG is not the
same.
But then of course the first SVC (down) will be retransmitted and the MGC
will have to deal with it in some way...)
 
-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Monday, May 14, 2001 12:00 PM
To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen'
Subject: RE: Implementors' Guide Update Editor's last Call - MGC failure
 
I think that a restart of a termination that is already in service should be
treated 
as a nop by an MGC.
 
I have no objection to adding an explicit no-op method, but I don't think it
is needed.
 
Brian
-----Original Message-----
From: Dan Elbert [mailto:DElbert@radvision.com]
Sent: Friday, May 11, 2001 5:57 PM
To: 'megaco@fore.com'; 'Chuong Nguyen'
Subject: RE: Implementors' Guide Update Editor's last Call - MGC failure
Using a fully specified terminationID can disrupt the operation of the
termination (for example if the termination is in a call).
It's not clear what a "bogus" termination is, if the MGC receives a SVC from
an MG termination it can assume that this termination is real and start
sending audits or commands.
Yes, by poll I mean some type of heartbeat as the MG needs to know if the
MGC is alive.
Brian Rosen suggested in the past to use SVC with Restart method for this
purpose, I don't think that there was any mantion if this should be done
with id=root or other.
 
Dan
 
-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Friday, May 11, 2001 5:38 PM
To: megaco@fore.com
Subject: Re: Implementors' Guide Update Editor's last Call - MGC failure
 

The intend was not to use ROOT but a fully specified terminationID or even
better a 
known invalid terminationID (A bogus terminationID that the sender knows is
not valid and is 
used specifically for heartbeat purpose).  The idea is to get some kind of
responses. 
"poll" do you mean heartbeat like msg to from MG to MGC or something else
here. 
Where did you see that Restart w/ROOT is used as a heartbeat/poll? 
  
Chuong 
Dan Elbert wrote: 
Hi
After reviewing the issue of MGC failure ( when the MG is connected trough
UDP ) I believe that there is no satisfactory way for the MG to poll the MGC
to see if the MGC is still alive. Using a ServiceChange with "Restart"
method and termination id of "root" may cause the MGC to assume that the MG
restarted and can affect the state of a call in progress. 
I think that it would be good to add a ServiceChange method "noop" : 
Noop : Can be used by the MG (with unreliable protocols) to obtain a
response from the MGC or detect a communication failure. When receiving this
SVC the MGC should take no action other that reply. 
If this is not acceptable, then I think that some clarification is needed as
when a SVC with restart method should be considered "noop" by the MGC. 
Dan Elbert 
RADVISION 
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  

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






















OK, then maybe we can have some wording to that effect in the =
Implementor’s
guide. 



I still think that in some scenarios this may be confusing or =
require greater
complexity in the MGC . ( for example if the termination sends a SVC =
going down,
but is not received by the MGC, and immediately a SVC with restart =
which is received,
so in this case the state of the MG is not the =
same.



But then of course the first SVC (down) will be retransmitted =
and the
MGC will have to deal with it in some =
way…)



 
=



-----Original
Message-----

From: Rosen, Brian
[mailto:Brian.Rosen@marconi.com]

Sent: Monday, May 14, =
2001 12:00
PM

To: 'Dan Elbert';
'megaco@fore.com'; 'Chuong Nguyen'

Subject: RE: =
Implementors' Guide
Update Editor's last Call - MGC failure



 



I think that a =
restart of
a termination that is already in service should be treated =
=




as a nop by an =
MGC.=




 =




I have no =
objection to
adding an explicit no-op method, but I don't think it is =
needed.=




 =




Brian=







-----Original
Message-----

From: Dan Elbert =
[mailto:DElbert@radvision.com]

Sent: Friday, May 11, =
2001 5:57 PM

To: 'megaco@fore.com'; =
'Chuong
Nguyen'

Subject: RE: =
Implementors' Guide
Update Editor's last Call - MGC failure=




U=
sing a
fully specified terminationID can disrupt the operation of the =
termination (for
example if the termination is in a =
call).



I=
t’s not
clear what a “bogus” termination is, if the MGC receives a =
SVC from an MG
termination it can assume that this termination is real and start =
sending
audits or commands.



Y=
es, by
poll I mean some type of heartbeat as the MG needs to know if the MGC =
is alive.



B=
rian
Rosen suggested in the past to use SVC with Restart method for this =
purpose, I
don’t think that there was any mantion if this should be done =
with id=3Droot or
other.



&=
nbsp;



D=
an



&=
nbsp;









-----Original Message-----

From: Chuong Nguyen
[mailto:Chuong.Nguyen@usa.alcatel.com]

Sent: Friday, May 11, =
2001 5:38 PM

To: megaco@fore.com

Subject: Re: =
Implementors' Guide
Update Editor's last Call - MGC failure=




 =






The intend was not to use ROOT but a fully specified terminationID or =
even
better a 

known invalid terminationID (A bogus terminationID that the sender =
knows is not
valid and is 

used specifically for heartbeat purpose).  The idea is to get some =
kind of
responses. 



"poll"
do you mean heartbeat like msg to from MG to MGC or something else =
here. =




Where did you
see that Restart w/ROOT is used as a heartbeat/poll? 

  



Chuong =




Dan Elbert
wrote: 









Hi=




After reviewing the issue =
of MGC
failure ( when the MG is connected trough UDP ) I believe that there is =
no
satisfactory way for the MG to poll the MGC to see if the MGC is still =
alive.
Using a ServiceChange with "Restart" method and termination =
id of
"root" may cause the MGC to assume that the MG restarted and =
can
affect the state of a call in progress. =




I think =
that it
would be good to add a ServiceChange method "noop" =
: =




Noop
: Can be used by the MG (with unreliable protocols) to obtain a =
response from
the MGC or detect a communication failure. When receiving this SVC the =
MGC should
take no action other that reply. =




If
this is not acceptable, then I think that some clarification is needed =
as when
a SVC with restart method should be considered "noop" by the =
MGC. =




Dan
Elbert 



RADVISIO=
N =







-- =

  Alcatel USA, =
Inc           &nb=
sp; Internet: Chuong.Nguyen@usa.alcatel.com=

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

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




  =













------_=_NextPart_001_01C0DC90.6291D660--


From owner-megaco@fore.com  Mon May 14 12:22:21 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16784
	for ; Mon, 14 May 2001 12:22:20 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA12345;
	Mon, 14 May 2001 12:15:41 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA21468
	for megaco-list; Mon, 14 May 2001 12:13:23 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA21452
	for ; Mon, 14 May 2001 12:13:21 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA12112
	for ; Mon, 14 May 2001 12:13:18 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Mon, 14 May 2001 11:14:32 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD9494524FA4A@RADVPOST>
From: Dan Elbert 
To: "'Rosen, Brian'" ,
        Dan Elbert
	 ,
        "'megaco@fore.com'" ,
        "'Chuong Nguyen'" 
Subject: RE: Implementors' Guide Update Editor's last Call - MGC failure
Date: Mon, 14 May 2001 11:14:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0DC90.F16CBAD0"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DC90.F16CBAD0
Content-Type: text/plain;
	charset="iso-8859-1"

Another thing  : Can I then use a restart of the "root" termination to poll
the MGC ? It seems to me more clean that to just use any termination.
 
 
 
-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Monday, May 14, 2001 12:00 PM
To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen'
Subject: RE: Implementors' Guide Update Editor's last Call - MGC failure
 
I think that a restart of a termination that is already in service should be
treated 
as a nop by an MGC.
 
I have no objection to adding an explicit no-op method, but I don't think it
is needed.
 
Brian
-----Original Message-----
From: Dan Elbert [mailto:DElbert@radvision.com]
Sent: Friday, May 11, 2001 5:57 PM
To: 'megaco@fore.com'; 'Chuong Nguyen'
Subject: RE: Implementors' Guide Update Editor's last Call - MGC failure
Using a fully specified terminationID can disrupt the operation of the
termination (for example if the termination is in a call).
It's not clear what a "bogus" termination is, if the MGC receives a SVC from
an MG termination it can assume that this termination is real and start
sending audits or commands.
Yes, by poll I mean some type of heartbeat as the MG needs to know if the
MGC is alive.
Brian Rosen suggested in the past to use SVC with Restart method for this
purpose, I don't think that there was any mantion if this should be done
with id=root or other.
 
Dan
 
-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Friday, May 11, 2001 5:38 PM
To: megaco@fore.com
Subject: Re: Implementors' Guide Update Editor's last Call - MGC failure
 

The intend was not to use ROOT but a fully specified terminationID or even
better a 
known invalid terminationID (A bogus terminationID that the sender knows is
not valid and is 
used specifically for heartbeat purpose).  The idea is to get some kind of
responses. 
"poll" do you mean heartbeat like msg to from MG to MGC or something else
here. 
Where did you see that Restart w/ROOT is used as a heartbeat/poll? 
  
Chuong 
Dan Elbert wrote: 
Hi
After reviewing the issue of MGC failure ( when the MG is connected trough
UDP ) I believe that there is no satisfactory way for the MG to poll the MGC
to see if the MGC is still alive. Using a ServiceChange with "Restart"
method and termination id of "root" may cause the MGC to assume that the MG
restarted and can affect the state of a call in progress. 
I think that it would be good to add a ServiceChange method "noop" : 
Noop : Can be used by the MG (with unreliable protocols) to obtain a
response from the MGC or detect a communication failure. When receiving this
SVC the MGC should take no action other that reply. 
If this is not acceptable, then I think that some clarification is needed as
when a SVC with restart method should be considered "noop" by the MGC. 
Dan Elbert 
RADVISION 
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  

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






















Another thing  : =
Can I then
use a restart of the “root” termination to poll the MGC ? =
It seems to me more
clean that to just use any =
termination.



 
=



 
=



 
=



-----Original
Message-----

From: Rosen, Brian
[mailto:Brian.Rosen@marconi.com]

Sent: Monday, May 14, =
2001 12:00
PM

To: 'Dan Elbert';
'megaco@fore.com'; 'Chuong Nguyen'

Subject: RE: =
Implementors' Guide
Update Editor's last Call - MGC failure



 



I think that a =
restart of
a termination that is already in service should be treated =
=




as a nop by an =
MGC.=




 =




I have no =
objection to
adding an explicit no-op method, but I don't think it is =
needed.=




 =




Brian=







-----Original
Message-----

From: Dan Elbert
[mailto:DElbert@radvision.com]

Sent: Friday, May 11, =
2001 5:57 PM

To: 'megaco@fore.com'; =
'Chuong
Nguyen'

Subject: RE: =
Implementors' Guide
Update Editor's last Call - MGC failure=




U=
sing a
fully specified terminationID can disrupt the operation of the =
termination (for
example if the termination is in a =
call).



I=
t’s not
clear what a “bogus” termination is, if the MGC receives a =
SVC from an MG
termination it can assume that this termination is real and start =
sending
audits or commands.



Y=
es, by
poll I mean some type of heartbeat as the MG needs to know if the MGC =
is alive.



B=
rian
Rosen suggested in the past to use SVC with Restart method for this =
purpose, I
don’t think that there was any mantion if this should be done =
with id=3Droot or
other.



&=
nbsp;



D=
an



&=
nbsp;









-----Original Message-----

From: Chuong Nguyen
[mailto:Chuong.Nguyen@usa.alcatel.com]

Sent: Friday, May 11, =
2001 5:38 PM

To: megaco@fore.com

Subject: Re: =
Implementors' Guide
Update Editor's last Call - MGC failure=




 =






The intend was not to use ROOT but a fully specified terminationID or =
even
better a 

known invalid terminationID (A bogus terminationID that the sender =
knows is not
valid and is 

used specifically for heartbeat purpose).  The idea is to get some =
kind of
responses. 



"poll"
do you mean heartbeat like msg to from MG to MGC or something else =
here. =




Where did you
see that Restart w/ROOT is used as a heartbeat/poll? 

  



Chuong =




Dan Elbert
wrote: 









Hi=




After reviewing the issue =
of MGC
failure ( when the MG is connected trough UDP ) I believe that there is =
no
satisfactory way for the MG to poll the MGC to see if the MGC is still =
alive.
Using a ServiceChange with "Restart" method and termination =
id of
"root" may cause the MGC to assume that the MG restarted and =
can
affect the state of a call in progress. =




I think =
that it
would be good to add a ServiceChange method "noop" =
: =




Noop
: Can be used by the MG (with unreliable protocols) to obtain a =
response from
the MGC or detect a communication failure. When receiving this SVC the =
MGC should
take no action other that reply. =




If
this is not acceptable, then I think that some clarification is needed =
as when
a SVC with restart method should be considered "noop" by the =
MGC. =




Dan
Elbert 



RADVISIO=
N =







-- =

  Alcatel USA, =
Inc           &nb=
sp; Internet: Chuong.Nguyen@usa.alcatel.com=

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

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




  =













------_=_NextPart_001_01C0DC90.F16CBAD0--


From owner-megaco@fore.com  Mon May 14 12:30:28 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17105
	for ; Mon, 14 May 2001 12:30:27 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA13364;
	Mon, 14 May 2001 12:24:16 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA23438
	for megaco-list; Mon, 14 May 2001 12:22:02 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA23430
	for ; Mon, 14 May 2001 12:22:00 -0400 (EDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA13039
	for ; Mon, 14 May 2001 12:21:57 -0400 (EDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id LAA28928
	for ; Mon, 14 May 2001 11:21:52 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4EGLqC26589
	for ; Mon, 14 May 2001 11:21:52 -0500 (CDT)
Received: from cls10ws1.ssd.usa.alcatel.com (cls10ws1.ssd.usa.alcatel.com [143.209.236.68])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4EGLV122826
	for ; Mon, 14 May 2001 11:21:31 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by cls10ws1.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA02573
	for ; Mon, 14 May 2001 11:21:30 -0500 (CDT)
Message-ID: <3B00060A.F734E846@usa.alcatel.com>
Date: Mon, 14 May 2001 11:21:30 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Implementors' Guide Update Editor's last Call - MGC failure
References: <0D5BBF5D638DD4119E3400508BD9494524FA4A@RADVPOST>
Content-Type: multipart/alternative;
 boundary="------------68ECC3E55A9A9080DCE7DFE4"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------68ECC3E55A9A9080DCE7DFE4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


--------------68ECC3E55A9A9080DCE7DFE4
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




 

To me definitely NOT.

How will MGC knows that it is a registration restarts vs a poll?

Don't tell me that one can use Reason Code since Reason Code has to
be IANA registered

before it can be widely used.

But since anyone can register w/IANA at any time, it only means that
it might not be supported by

everyone.

Chuong

 

Dan Elbert wrote:






Another
thing : Can I then use a restart
of the "root" termination to poll the MGC ? It seems to me more clean that
to just use any termination.













-----Original
Message-----

From:
Rosen, Brian [mailto:Brian.Rosen@marconi.com]

Sent:
Monday, May 14, 2001 12:00 PM

To:
'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen'

Subject:
RE: Implementors' Guide Update Editor's last Call - MGC failure





I
think that a restart of a termination that is already in service should
be treated 


as
a nop by an MGC.





I
have no objection to adding an explicit no-op method, but I don't think
it is needed.





Brian



-----Original
Message-----




From:
Dan Elbert [mailto:DElbert@radvision.com]

Sent:
Friday, May 11, 2001 5:57 PM

To:
'megaco@fore.com'; 'Chuong Nguyen'

Subject:
RE: Implementors' Guide Update Editor's last Call - MGC failure


Using
a fully specified terminationID can disrupt the operation of the termination
(for example if the termination is in a call).


It's
not clear what a "bogus" termination is, if the MGC receives a SVC from
an MG termination it can assume that this termination is real and start
sending audits or commands.


Yes,
by poll I mean some type of heartbeat as the MG needs to know if the MGC
is alive.


Brian
Rosen suggested in the past to use SVC with Restart method for this purpose,
I don't think that there was any mantion if this should be done with id=root
or other.





Dan







-----Original
Message-----




From:
Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]

Sent:
Friday, May 11, 2001 5:38 PM

To:
megaco@fore.com

Subject:
Re: Implementors' Guide Update Editor's last Call - MGC failure







The
intend was not to use ROOT but a fully specified terminationID or even
better a

known
invalid terminationID (A bogus terminationID that the sender knows is not
valid and is

used
specifically for heartbeat purpose).  The idea is to get some kind
of responses. 


"poll"
do you mean heartbeat like msg to from MG to MGC or something else here. 


Where
did you see that Restart w/ROOT is used as a heartbeat/poll?




Chuong 


Dan
Elbert wrote: 





Hi



After
reviewing the issue of MGC failure ( when the MG is connected trough UDP
) I believe that there is no satisfactory way for the MG to poll the MGC
to see if the MGC is still alive. Using a ServiceChange with "Restart"
method and termination id of "root" may cause the MGC to assume that the
MG restarted and can affect the state of a call in progress.




I
think that it would be good to add a ServiceChange method "noop" :


Noop
: Can be used by the MG (with unreliable protocols) to obtain a response
from the MGC or detect a communication failure. When receiving this SVC
the MGC should take no action other that reply.


If
this is not acceptable, then I think that some clarification is needed
as when a SVC with restart method should be considered "noop" by the MGC.


Dan
Elbert


RADVISION





-- 



  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com



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



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












-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 



--------------68ECC3E55A9A9080DCE7DFE4--



From owner-megaco@fore.com  Mon May 14 12:39:17 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17420
	for ; Mon, 14 May 2001 12:39:17 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA14386;
	Mon, 14 May 2001 12:30:56 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA25334
	for megaco-list; Mon, 14 May 2001 12:28:46 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA25324
	for ; Mon, 14 May 2001 12:28:44 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA14094
	for ; Mon, 14 May 2001 12:28:41 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Mon, 14 May 2001 11:29:54 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD9494524FA4B@RADVPOST>
From: Dan Elbert 
To: megaco@fore.com, "'Chuong Nguyen'" 
Subject: RE: Implementors' Guide Update Editor's last Call - MGC failure
Date: Mon, 14 May 2001 11:29:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0DC93.1A040C30"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DC93.1A040C30
Content-Type: text/plain;
	charset="iso-8859-1"

Well I was just following the logic that a restart of a termination already
in service is a noop. Is the root termination a special case ? .  The
problem with poll vs restart is the same in any case.
 
-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Monday, May 14, 2001 12:22 PM
To: megaco@fore.com
Subject: Re: Implementors' Guide Update Editor's last Call - MGC failure
 
  
To me definitely NOT. 
How will MGC knows that it is a registration restarts vs a poll? 
Don't tell me that one can use Reason Code since Reason Code has to be IANA
registered 
before it can be widely used. 
But since anyone can register w/IANA at any time, it only means that it
might not be supported by 
everyone. 
Chuong 
  
Dan Elbert wrote: 
Another thing : Can I then use a restart of the "root" termination to poll
the MGC ? It seems to me more clean that to just use any termination.
-----Original Message----- 
From: Rosen, Brian [ mailto:Brian.Rosen@marconi.com
 ] 
Sent: Monday, May 14, 2001 12:00 PM 
To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen' 
Subject: RE: Implementors' Guide Update Editor's last Call - MGC failure 
I think that a restart of a termination that is already in service should be
treated  
as a nop by an MGC. 
I have no objection to adding an explicit no-op method, but I don't think it
is needed. 
Brian 
-----Original Message-----

From: Dan Elbert [ mailto:DElbert@radvision.com
 ] 
Sent: Friday, May 11, 2001 5:57 PM 
To: 'megaco@fore.com'; 'Chuong Nguyen' 
Subject: RE: Implementors' Guide Update Editor's last Call - MGC failure 
Using a fully specified terminationID can disrupt the operation of the
termination (for example if the termination is in a call). 
It's not clear what a "bogus" termination is, if the MGC receives a SVC from
an MG termination it can assume that this termination is real and start
sending audits or commands. 
Yes, by poll I mean some type of heartbeat as the MG needs to know if the
MGC is alive. 
Brian Rosen suggested in the past to use SVC with Restart method for this
purpose, I don't think that there was any mantion if this should be done
with id=root or other. 
Dan 
-----Original Message-----

From: Chuong Nguyen [ mailto:Chuong.Nguyen@usa.alcatel.com
 ] 
Sent: Friday, May 11, 2001 5:38 PM 
To: megaco@fore.com 
Subject: Re: Implementors' Guide Update Editor's last Call - MGC failure 

The intend was not to use ROOT but a fully specified terminationID or even
better a 
known invalid terminationID (A bogus terminationID that the sender knows is
not valid and is 
used specifically for heartbeat purpose).  The idea is to get some kind of
responses.  
"poll" do you mean heartbeat like msg to from MG to MGC or something else
here.  
Where did you see that Restart w/ROOT is used as a heartbeat/poll? 


Chuong  
Dan Elbert wrote: 
Hi
After reviewing the issue of MGC failure ( when the MG is connected trough
UDP ) I believe that there is no satisfactory way for the MG to poll the MGC
to see if the MGC is still alive. Using a ServiceChange with "Restart"
method and termination id of "root" may cause the MGC to assume that the MG
restarted and can affect the state of a call in progress.
I think that it would be good to add a ServiceChange method "noop" : 
Noop : Can be used by the MG (with unreliable protocols) to obtain a
response from the MGC or detect a communication failure. When receiving this
SVC the MGC should take no action other that reply. 
If this is not acceptable, then I think that some clarification is needed as
when a SVC with restart method should be considered "noop" by the MGC. 
Dan Elbert 
RADVISION
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  

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






















W=
ell I was
just following the logic that a restart of a termination already in =
service is
a noop. Is the root termination a special case ? .  The problem with poll vs restart is the same in any =
case.



<=
![if =
!supportEmptyParas]> 
=



-----Original
Message-----

From: Chuong Nguyen
[mailto:Chuong.Nguyen@usa.alcatel.com]

Sent: Monday, May 14, =
2001 12:22
PM

To: megaco@fore.com

Subject: Re: =
Implementors' Guide
Update Editor's last Call - MGC failure



 



  

To me definitely NOT. 

How will MGC knows that it is a registration restarts vs a poll? 

Don't tell me that one can use Reason Code since Reason Code has to be =
IANA
registered 

before it can be widely used. 

But since anyone can register w/IANA at any time, it only means that it =
might
not be supported by 

everyone. 



Chuong 

  



Dan Elbert wrote: =
=





 
  
 
Another thing : Can I then use a restart of the
"root" termination to poll the MGC ? It seems to me more =
clean that
to just use any termination.=




-----Original
Message----- 

From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] 

Sent: Monday, May 14, 2001 12:00 PM 

To:=
 'Dan Elbert'; 'megaco@fore.com'; 'Chuong =
Nguyen' 

Subject: RE: Implementors' Guide Update Editor's last Call - MGC =
failure =




I
think that a restart of a termination that is already in service should =
be
treated  



as a nop
by an MGC.
=




I
have no objection to adding an explicit no-op method, but I don't think =
it is
needed. =




Bri=
an =







-----Original
Message-----











From: Dan Elbert [mailto:DElbert@radvision.com]<=
/span> 

Sent: Friday, May 11, 2001 5:57 PM 

To: 'megaco@fore.com'; 'Chuong Nguyen' 

Subject:<=
/font> RE: Implementors' Guide Update Editor's last Call - MGC =
failure =










Us=
ing a
fully specified terminationID can disrupt the operation of the =
termination (for
example if the termination is in a =
call). =




It=
's not
clear what a "bogus" termination is, if the MGC receives a =
SVC from
an MG termination it can assume that this termination is real and start =
sending
audits or commands. 



Ye=
s, by
poll I mean some type of heartbeat as the MG needs to know if the MGC =
is alive. =




Br=
ian Rosen
suggested in the past to use SVC with Restart method for this purpose, =
I don't
think that there was any mantion if this should be done with id=3Droot =
or other. =




Da=
n =










--=
---Original
Message-----











From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.a=
lcatel.com] 

Sent: Friday, May 11, 2001 5:38 PM 

To: megaco@fore.com 

Subject:<=
/font> Re: Implementors' Guide Update Editor's last Call - MGC =
failure =












The intend was not to use ROOT but a fully specified terminationID or =
even
better a 

known invalid terminationID (A bogus terminationID that the sender =
knows is not
valid and is 

used specifically for heartbeat purpose).  The idea is to get some =
kind of
responses.  =




"poll"
do you mean heartbeat like msg to from MG to MGC or something else =
here. 
=




Where
did you see that Restart w/ROOT is used as a heartbeat/poll? 







Chuong 
=




Dan
Elbert wrote: =










Hi=




After reviewing the issue of MGC =
failure ( when
the MG is connected trough UDP ) I believe that there is no =
satisfactory way
for the MG to poll the MGC to see if the MGC is still alive. Using a
ServiceChange with "Restart" method and termination id of &quo=
t;root"
may cause the MGC to assume that the MG restarted and can affect the =
state of a
call in progress.=




I think =
that it
would be good to add a ServiceChange method "noop" =
: =




Noop
: Can be used by the MG (with unreliable protocols) to obtain a =
response from
the MGC or detect a communication failure. When receiving this SVC the =
MGC
should take no action other that =
reply. =




If
this is not acceptable, then I think that some clarification is needed =
as when
a SVC with restart method should be considered "noop" by the =
MGC. =




Dan
Elbert 



RADVISIO=
N=







-- =
=

  =
Alcatel USA, =
Inc           &nb=
sp; Internet: =
Chuong.Nguyen@usa.alcatel.com=

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

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




-- =

  Alcatel USA, =
Inc           &nb=
sp; Internet: Chuong.Nguyen@usa.alcatel.com=

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

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




  









------_=_NextPart_001_01C0DC93.1A040C30--


From owner-megaco@fore.com  Mon May 14 13:01:36 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18120
	for ; Mon, 14 May 2001 13:01:36 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA16913;
	Mon, 14 May 2001 12:54:08 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA01750
	for megaco-list; Mon, 14 May 2001 12:51:51 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA01745
	for ; Mon, 14 May 2001 12:51:50 -0400 (EDT)
Received: from ertpg15e1.nortelnetworks.com (ertpg15e1.nortelnetworks.com [47.234.0.36])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id MAA16479
	for ; Mon, 14 May 2001 12:51:47 -0400 (EDT)
Received: from zrtps06s.us.nortel.com by ertpg15e1.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id MAA19028; Mon, 14 May 2001 12:51:48 -0400
Received: from zrtpd00y.us.nortel.com by zrtps06s.us.nortel.com;
          Mon, 14 May 2001 12:52:35 -0400
Received: from zrtpd0jn.us.nortel.com ([47.140.202.35]) 
          by zrtpd00y.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id K8NQ79CM; Mon, 14 May 2001 12:51:32 -0400
Received: from americasm01.nt.com (kboyle.us.nortel.com [47.142.150.95]) 
          by zrtpd0jn.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id J5XGQBNV; Mon, 14 May 2001 12:51:33 -0400
Message-ID: <3B000CC1.8A53839B@americasm01.nt.com>
Date: Mon, 14 May 2001 12:50:09 -0400
X-Sybari-Space: 00000000 00000000 00000000
From: "Kevin Boyle" 
Organization: Nortel Networks
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dan Elbert 
CC: megaco@fore.com, "'Chuong Nguyen'" 
Subject: Re: Implementors' Guide Update Editor's last Call - MGC failure
References: <0D5BBF5D638DD4119E3400508BD9494524FA4B@RADVPOST>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Yes.  Root is a special case.  Restart on Root, if it is already in
service, implies that the MG has gone out of service and returned, and
that anything that was happening previously is lost.  This was discussed
on an earlier thread.

Kevin

Dan Elbert wrote:

> Well I was just following the logic that a restart of a termination
> already in service is a noop. Is the root termination a special case ?
> . The problem with poll vs restart is the same in any case.
>
> -----Original Message-----
> From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> Sent: Monday, May 14, 2001 12:22 PM
> To: megaco@fore.com
> Subject: Re: Implementors' Guide Update Editor's last Call - MGC
> failure
>
>
> To me definitely NOT.
> How will MGC knows that it is a registration restarts vs a poll?
> Don't tell me that one can use Reason Code since Reason Code has to be
> IANA registered
> before it can be widely used.
> But since anyone can register w/IANA at any time, it only means that
> it might not be supported by
> everyone.
>
> Chuong
>
> Dan Elbert wrote:
>
> Another thing : Can I then use a restart of the "root" termination to
> poll the MGC ? It seems to me more clean that to just use any
> termination.
>
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Monday, May 14, 2001 12:00 PM
> To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen'
> Subject: RE: Implementors' Guide Update Editor's last Call - MGC
> failure
>
> I think that a restart of a termination that is already in service
> should be treated
>
> as a nop by an MGC.
>
> I have no objection to adding an explicit no-op method, but I don't
> think it is needed.
>
> Brian
> -----Original Message-----
>
> From: Dan Elbert [mailto:DElbert@radvision.com]
> Sent: Friday, May 11, 2001 5:57 PM
> To: 'megaco@fore.com'; 'Chuong Nguyen'
> Subject: RE: Implementors' Guide Update Editor's last Call - MGC
> failure
> Using a fully specified terminationID can disrupt the operation of the
> termination (for example if the termination is in a call).
>
> It's not clear what a "bogus" termination is, if the MGC receives a
> SVC from an MG termination it can assume that this termination is real
> and start sending audits or commands.
>
> Yes, by poll I mean some type of heartbeat as the MG needs to know if
> the MGC is alive.
>
> Brian Rosen suggested in the past to use SVC with Restart method for
> this purpose, I don't think that there was any mantion if this should
> be done with id=root or other.
>
> Dan
> -----Original Message-----
>
> From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> Sent: Friday, May 11, 2001 5:38 PM
> To: megaco@fore.com
> Subject: Re: Implementors' Guide Update Editor's last Call - MGC
> failure
>
> The intend was not to use ROOT but a fully specified terminationID or
> even better a
> known invalid terminationID (A bogus terminationID that the sender
> knows is not valid and is
> used specifically for heartbeat purpose).  The idea is to get some
> kind of responses.
>
> "poll" do you mean heartbeat like msg to from MG to MGC or something
> else here.
>
> Where did you see that Restart w/ROOT is used as a heartbeat/poll?
>
> Chuong
>
> Dan Elbert wrote:
> Hi
>
> After reviewing the issue of MGC failure ( when the MG is connected
> trough UDP ) I believe that there is no satisfactory way for the MG to
> poll the MGC to see if the MGC is still alive. Using a ServiceChange
> with "Restart" method and termination id of "root" may cause the MGC
> to assume that the MG restarted and can affect the state of a call in
> progress.
>
> I think that it would be good to add a ServiceChange method "noop" :
>
> Noop : Can be used by the MG (with unreliable protocols) to obtain a
> response from the MGC or detect a communication failure. When
> receiving this SVC the MGC should take no action other that reply.
>
> If this is not acceptable, then I think that some clarification is
> needed as when a SVC with restart method should be considered "noop"
> by the MGC.
>
> Dan Elbert
>
> RADVISION
>
> --
>
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>
> --
>
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>



From owner-megaco@fore.com  Tue May 15 02:10:38 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17677
	for ; Tue, 15 May 2001 02:10:38 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA13308;
	Tue, 15 May 2001 02:04:55 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA26055
	for megaco-list; Tue, 15 May 2001 02:00:47 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA26051
	for ; Tue, 15 May 2001 02:00:46 -0400 (EDT)
Received: from hotmail.com (f260.law14.hotmail.com [64.4.20.135])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA12844
	for ; Tue, 15 May 2001 02:00:41 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 14 May 2001 23:00:43 -0700
Received: from 211.152.231.114 by lw14fd.law14.hotmail.msn.com with HTTP;	Tue, 15 May 2001 06:00:42 GMT
X-Originating-IP: [211.152.231.114]
From: "mu lj" 
To: megaco@fore.com
Subject: question about profile
Date: Tue, 15 May 2001 14:00:42 +0800
Mime-Version: 1.0
Content-Type: text/plain; charset=gb2312; format=flowed
Message-ID: 
X-OriginalArrivalTime: 15 May 2001 06:00:43.0171 (UTC) FILETIME=[604E0F30:01C0DD04]
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

hi all:
I have some doubts related to profile. They are as follows
1. what is profile formate? 
2. how to use profile in ServiceChangeProfile?

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.



From owner-megaco@fore.com  Tue May 15 04:09:48 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18694
	for ; Tue, 15 May 2001 04:09:47 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA18681;
	Tue, 15 May 2001 04:03:44 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id DAA07807
	for megaco-list; Tue, 15 May 2001 03:59:24 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA07795
	for ; Tue, 15 May 2001 03:59:22 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id DAA18455
	for ; Tue, 15 May 2001 03:59:17 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id DAA28781; Tue, 15 May 2001 03:59:14 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 15 May 2001 03:59:01 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Tue, 15 May 2001 03:59:03 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB44@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "Kevin Boyle" ,
        Dan Elbert 
Cc: megaco@fore.com, "'Chuong Nguyen'" 
Subject: Polls of MGC (was RE: Implementors' Guide Update Editor's last Ca ll - 
         MGC failure)
Date: Tue, 15 May 2001 03:59:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DD14.E75DC320"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DD14.E75DC320
Content-Type: text/plain;
	charset="ISO-8859-1"

Let's follow through the logic here.  A restart implies loss of state.  I
don't care whether you're talking ROOT or a real termination.  It would be
inconsistent to declare restart of the latter a no-op.

I'd suggest the safest poll would be a NOTIFY with no events and a bogus
requestID in it.  The MGC has to answer, even if only to return an error,
but the NOTIFY doesn't change anything.

> -----Original Message-----
> From: Boyle, Kevin [NCRTP:3Z70:EXCH] 
> Sent: Monday, May 14, 2001 12:50 PM
> To: Dan Elbert
> Cc: megaco@fore.com; 'Chuong Nguyen'
> Subject: Re: Implementors' Guide Update Editor's last Call - 
> MGC failure
> 
> 
> Yes.  Root is a special case.  Restart on Root, if it is already in
> service, implies that the MG has gone out of service and returned, and
> that anything that was happening previously is lost.  This 
> was discussed
> on an earlier thread.
> 
> Kevin
> 
> Dan Elbert wrote:
> 
> > Well I was just following the logic that a restart of a termination
> > already in service is a noop. Is the root termination a 
> special case ?
> > . The problem with poll vs restart is the same in any case.
> >
> > -----Original Message-----
> > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > Sent: Monday, May 14, 2001 12:22 PM
> > To: megaco@fore.com
> > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
> > failure
> >
> >
> > To me definitely NOT.
> > How will MGC knows that it is a registration restarts vs a poll?
> > Don't tell me that one can use Reason Code since Reason 
> Code has to be
> > IANA registered
> > before it can be widely used.
> > But since anyone can register w/IANA at any time, it only means that
> > it might not be supported by
> > everyone.
> >
> > Chuong
> >
> > Dan Elbert wrote:
> >
> > Another thing : Can I then use a restart of the "root" 
> termination to
> > poll the MGC ? It seems to me more clean that to just use any
> > termination.
> >
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > Sent: Monday, May 14, 2001 12:00 PM
> > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen'
> > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
> > failure
> >
> > I think that a restart of a termination that is already in service
> > should be treated
> >
> > as a nop by an MGC.
> >
> > I have no objection to adding an explicit no-op method, but I don't
> > think it is needed.
> >
> > Brian
> > -----Original Message-----
> >
> > From: Dan Elbert [mailto:DElbert@radvision.com]
> > Sent: Friday, May 11, 2001 5:57 PM
> > To: 'megaco@fore.com'; 'Chuong Nguyen'
> > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
> > failure
> > Using a fully specified terminationID can disrupt the 
> operation of the
> > termination (for example if the termination is in a call).
> >
> > It's not clear what a "bogus" termination is, if the MGC receives a
> > SVC from an MG termination it can assume that this 
> termination is real
> > and start sending audits or commands.
> >
> > Yes, by poll I mean some type of heartbeat as the MG needs 
> to know if
> > the MGC is alive.
> >
> > Brian Rosen suggested in the past to use SVC with Restart method for
> > this purpose, I don't think that there was any mantion if 
> this should
> > be done with id=root or other.
> >
> > Dan
> > -----Original Message-----
> >
> > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > Sent: Friday, May 11, 2001 5:38 PM
> > To: megaco@fore.com
> > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
> > failure
> >
> > The intend was not to use ROOT but a fully specified 
> terminationID or
> > even better a
> > known invalid terminationID (A bogus terminationID that the sender
> > knows is not valid and is
> > used specifically for heartbeat purpose).  The idea is to get some
> > kind of responses.
> >
> > "poll" do you mean heartbeat like msg to from MG to MGC or something
> > else here.
> >
> > Where did you see that Restart w/ROOT is used as a heartbeat/poll?
> >
> > Chuong
> >
> > Dan Elbert wrote:
> > Hi
> >
> > After reviewing the issue of MGC failure ( when the MG is connected
> > trough UDP ) I believe that there is no satisfactory way 
> for the MG to
> > poll the MGC to see if the MGC is still alive. Using a ServiceChange
> > with "Restart" method and termination id of "root" may cause the MGC
> > to assume that the MG restarted and can affect the state of 
> a call in
> > progress.
> >
> > I think that it would be good to add a ServiceChange method "noop" :
> >
> > Noop : Can be used by the MG (with unreliable protocols) to obtain a
> > response from the MGC or detect a communication failure. When
> > receiving this SVC the MGC should take no action other that reply.
> >
> > If this is not acceptable, then I think that some clarification is
> > needed as when a SVC with restart method should be considered "noop"
> > by the MGC.
> >
> > Dan Elbert
> >
> > RADVISION
> >
> > --
> >
> >   Alcatel USA, Inc             Internet: 
> Chuong.Nguyen@usa.alcatel.com
> >
> >   1000 Coit Road Plano, Texas 75075           Phone:    
> (972) 519-4613
> >
> >   **** The opinions expressed are not those of Alcatel USA, Inc ****
> >
> > --
> >
> >   Alcatel USA, Inc             Internet: 
> Chuong.Nguyen@usa.alcatel.com
> >
> >   1000 Coit Road Plano, Texas 75075           Phone:    
> (972) 519-4613
> >
> >   **** The opinions expressed are not those of Alcatel USA, Inc ****
> >
> 
> 

------_=_NextPart_001_01C0DD14.E75DC320
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






Polls of MGC (was RE: Implementors' Guide Update Editor's last =
Call - MGC failure)




Let's follow through the logic here.  A restart =
implies loss of state.  I don't care whether you're talking ROOT =
or a real termination.  It would be inconsistent to declare =
restart of the latter a no-op.



I'd suggest the safest poll would be a NOTIFY with no =
events and a bogus requestID in it.  The MGC has to answer, even =
if only to return an error, but the NOTIFY doesn't change =
anything.



> -----Original Message-----

> From: Boyle, Kevin [NCRTP:3Z70:EXCH] 

> Sent: Monday, May 14, 2001 12:50 PM

> To: Dan Elbert

> Cc: megaco@fore.com; 'Chuong Nguyen'

> Subject: Re: Implementors' Guide Update =
Editor's last Call - 

> MGC failure

> 

> 

> Yes.  Root is a special case.  =
Restart on Root, if it is already in

> service, implies that the MG has gone out of =
service and returned, and

> that anything that was happening previously is =
lost.  This 

> was discussed

> on an earlier thread.

> 

> Kevin

> 

> Dan Elbert wrote:

> 

> > Well I was just following the logic that a =
restart of a termination

> > already in service is a noop. Is the root =
termination a 

> special case ?

> > . The problem with poll vs restart is the =
same in any case.

> >

> > -----Original Message-----

> > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.a=
lcatel.com]

> > Sent: Monday, May 14, 2001 12:22 PM

> > To: megaco@fore.com

> > Subject: Re: Implementors' Guide Update =
Editor's last Call - MGC

> > failure

> >

> >

> > To me definitely NOT.

> > How will MGC knows that it is a =
registration restarts vs a poll?

> > Don't tell me that one can use Reason Code =
since Reason 

> Code has to be

> > IANA registered

> > before it can be widely used.

> > But since anyone can register w/IANA at =
any time, it only means that

> > it might not be supported by

> > everyone.

> >

> > Chuong

> >

> > Dan Elbert wrote:

> >

> > Another thing : Can I then use a restart =
of the "root" 

> termination to

> > poll the MGC ? It seems to me more clean =
that to just use any

> > termination.

> >

> > -----Original Message-----

> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]

> > Sent: Monday, May 14, 2001 12:00 PM

> > To: 'Dan Elbert'; 'megaco@fore.com'; =
'Chuong Nguyen'

> > Subject: RE: Implementors' Guide Update =
Editor's last Call - MGC

> > failure

> >

> > I think that a restart of a termination =
that is already in service

> > should be treated

> >

> > as a nop by an MGC.

> >

> > I have no objection to adding an explicit =
no-op method, but I don't

> > think it is needed.

> >

> > Brian

> > -----Original Message-----

> >

> > From: Dan Elbert [mailto:DElbert@radvision.com]<=
/FONT>

> > Sent: Friday, May 11, 2001 5:57 PM

> > To: 'megaco@fore.com'; 'Chuong =
Nguyen'

> > Subject: RE: Implementors' Guide Update =
Editor's last Call - MGC

> > failure

> > Using a fully specified terminationID can =
disrupt the 

> operation of the

> > termination (for example if the =
termination is in a call).

> >

> > It's not clear what a "bogus" =
termination is, if the MGC receives a

> > SVC from an MG termination it can assume =
that this 

> termination is real

> > and start sending audits or =
commands.

> >

> > Yes, by poll I mean some type of heartbeat =
as the MG needs 

> to know if

> > the MGC is alive.

> >

> > Brian Rosen suggested in the past to use =
SVC with Restart method for

> > this purpose, I don't think that there was =
any mantion if 

> this should

> > be done with id=3Droot or other.

> >

> > Dan

> > -----Original Message-----

> >

> > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.a=
lcatel.com]

> > Sent: Friday, May 11, 2001 5:38 PM

> > To: megaco@fore.com

> > Subject: Re: Implementors' Guide Update =
Editor's last Call - MGC

> > failure

> >

> > The intend was not to use ROOT but a fully =
specified 

> terminationID or

> > even better a

> > known invalid terminationID (A bogus =
terminationID that the sender

> > knows is not valid and is

> > used specifically for heartbeat =
purpose).  The idea is to get some

> > kind of responses.

> >

> > "poll" do you mean heartbeat =
like msg to from MG to MGC or something

> > else here.

> >

> > Where did you see that Restart w/ROOT is =
used as a heartbeat/poll?

> >

> > Chuong

> >

> > Dan Elbert wrote:

> > Hi

> >

> > After reviewing the issue of MGC failure ( =
when the MG is connected

> > trough UDP ) I believe that there is no =
satisfactory way 

> for the MG to

> > poll the MGC to see if the MGC is still =
alive. Using a ServiceChange

> > with "Restart" method and =
termination id of "root" may cause the MGC

> > to assume that the MG restarted and can =
affect the state of 

> a call in

> > progress.

> >

> > I think that it would be good to add a =
ServiceChange method "noop" :

> >

> > Noop : Can be used by the MG (with =
unreliable protocols) to obtain a

> > response from the MGC or detect a =
communication failure. When

> > receiving this SVC the MGC should take no =
action other that reply.

> >

> > If this is not acceptable, then I think =
that some clarification is

> > needed as when a SVC with restart method =
should be considered "noop"

> > by the MGC.

> >

> > Dan Elbert

> >

> > RADVISION

> >

> > --

> >

> >   Alcatel USA, =
Inc           &nb=
sp; Internet: 

> Chuong.Nguyen@usa.alcatel.com

> >

> >   1000 Coit Road Plano, Texas =
75075           =
Phone:    

> (972) 519-4613

> >

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

> >

> > --

> >

> >   Alcatel USA, =
Inc           &nb=
sp; Internet: 

> Chuong.Nguyen@usa.alcatel.com

> >

> >   1000 Coit Road Plano, Texas =
75075           =
Phone:    

> (972) 519-4613

> >

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

> >

> 

> 





------_=_NextPart_001_01C0DD14.E75DC320--


From owner-megaco@fore.com  Tue May 15 04:14:16 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18745
	for ; Tue, 15 May 2001 04:14:15 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA18981;
	Tue, 15 May 2001 04:07:17 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id EAA08176
	for megaco-list; Tue, 15 May 2001 04:04:29 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA08168
	for ; Tue, 15 May 2001 04:04:27 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id EAA18769
	for ; Tue, 15 May 2001 04:04:23 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id EAA28878; Tue, 15 May 2001 04:04:20 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 15 May 2001 04:04:22 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Tue, 15 May 2001 04:04:24 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB45@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'mu lj'" , megaco@fore.com
Subject: RE: question about profile
Date: Tue, 15 May 2001 04:04:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DD15.A799CC60"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DD15.A799CC60
Content-Type: text/plain;
	charset="gb2312"

Hi.

> -----Original Message-----
> From: mu lj [mailto:dtxlymlj@hotmail.com]
> Sent: Tuesday, May 15, 2001 2:01 AM
> To: megaco@fore.com
> Subject: question about profile
> 
> 
> hi all:
> I have some doubts related to profile. They are as follows
> 1. what is profile formate?

ServiceChangeProfile = ProfileToken EQUAL NAME SLASH Version 
Version              = 1*2(DIGIT)
NAME                 = ALPHA *63(ALPHA / DIGIT / "_" )

> 2. how to use profile in ServiceChangeProfile?

The use of profiles has deliberately been left unspecified.  The intent is
that profiles and their use are defined by other fora.  For an example of a
profile, look at the TIA-initiated RFC 3054.
 
> 
> ______________________________________________________________
> ___________
> Get Your Private, Free E-mail from MSN Hotmail at 
> http://www.hotmail.com.
> 
> 

------_=_NextPart_001_01C0DD15.A799CC60
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable






RE: question about profile




Hi.




> -----Original Message-----

> From: mu lj [mailto:dtxlymlj@hotmail.com]

> Sent: Tuesday, May 15, 2001 2:01 AM

> To: megaco@fore.com

> Subject: question about profile

> 

> 

> hi all:

> I have some doubts related to profile. They are =
as follows

> 1. what is profile formate?




ServiceChangeProfile =3D ProfileToken EQUAL NAME =
SLASH Version 

Version         &n=
bsp;    =3D 1*2(DIGIT)

NAME          =
;       =3D ALPHA *63(ALPHA / DIGIT / =
"_" )




> 2. how to use profile in =
ServiceChangeProfile?




The use of profiles has deliberately been left =
unspecified.  The intent is that profiles and their use are =
defined by other fora.  For an example of a profile, look at the =
TIA-initiated RFC 3054.



 

> 

> =
______________________________________________________________

> ___________

> Get Your Private, Free E-mail from MSN Hotmail =
at 

> http://www.hotmail.com.

> 

> 





------_=_NextPart_001_01C0DD15.A799CC60--


From owner-megaco@fore.com  Tue May 15 07:12:28 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20813
	for ; Tue, 15 May 2001 07:12:27 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA29386;
	Tue, 15 May 2001 07:05:22 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA00838
	for megaco-list; Tue, 15 May 2001 07:02:03 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA00833
	for ; Tue, 15 May 2001 07:02:02 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA29099
	for ; Tue, 15 May 2001 07:01:59 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20219;
	Tue, 15 May 2001 07:01:51 -0400 (EDT)
Message-Id: <200105151101.HAA20219@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: megaco@fore.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-boyle-megaco-tonepkgs-04.txt
Date: Tue, 15 May 2001 07:01:51 -0400
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Media Gateway Control Working Group of the IETF.

	Title		: Supplemental Tones Packages for Megaco/H.248
	Author(s)	: K. Boyle, C. Brown, S. Cornel, S. Doyle, M. Kumar
	Filename	: draft-boyle-megaco-tonepkgs-04.txt
	Pages		: 34
	Date		: 14-May-01
	
This document provides proposed definitions for several supplemental
packages for Megaco/H.248. These packages address support of
functionality for basic and enhanced telephony services.  This
document is the updated version of the tones packages presented
originally in draft-brown-megaco-supplpkgs-00.txt.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-boyle-megaco-tonepkgs-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-boyle-megaco-tonepkgs-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-boyle-megaco-tonepkgs-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010514102854.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-boyle-megaco-tonepkgs-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-boyle-megaco-tonepkgs-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010514102854.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-megaco@fore.com  Tue May 15 07:58:49 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22627
	for ; Tue, 15 May 2001 07:58:47 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA02858;
	Tue, 15 May 2001 07:51:37 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA09279
	for megaco-list; Tue, 15 May 2001 07:49:02 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA09265
	for ; Tue, 15 May 2001 07:49:00 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 15 May 2001 07:48:31 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F5F4@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Tom-PT Taylor'" ,
        Kevin Boyle
	 ,
        Dan Elbert 
Cc: megaco@fore.com, "'Chuong Nguyen'" 
Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's las
	t Ca ll -  MGC failure)
Date: Tue, 15 May 2001 07:48:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0DD35.06C36DD0"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DD35.06C36DD0
Content-Type: text/plain;
	charset="ISO-8859-1"

I don't think a restart of an already in service termination can imply loss
of state;
you would have to take it down and then bring it up to have loss of state.
 
I do think we want a real no-op, and not something that generates an error.
If you insist in can't be restart of an inservice termination, then we
should
add the no-op method.
 
Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, May 15, 2001 3:59 AM
To: Kevin Boyle; Dan Elbert
Cc: megaco@fore.com; 'Chuong Nguyen'
Subject: Polls of MGC (was RE: Implementors' Guide Update Editor's last Ca
ll - MGC failure)



Let's follow through the logic here.  A restart implies loss of state.  I
don't care whether you're talking ROOT or a real termination.  It would be
inconsistent to declare restart of the latter a no-op.

I'd suggest the safest poll would be a NOTIFY with no events and a bogus
requestID in it.  The MGC has to answer, even if only to return an error,
but the NOTIFY doesn't change anything.

> -----Original Message----- 
> From: Boyle, Kevin [NCRTP:3Z70:EXCH] 
> Sent: Monday, May 14, 2001 12:50 PM 
> To: Dan Elbert 
> Cc: megaco@fore.com; 'Chuong Nguyen' 
> Subject: Re: Implementors' Guide Update Editor's last Call - 
> MGC failure 
> 
> 
> Yes.  Root is a special case.  Restart on Root, if it is already in 
> service, implies that the MG has gone out of service and returned, and 
> that anything that was happening previously is lost.  This 
> was discussed 
> on an earlier thread. 
> 
> Kevin 
> 
> Dan Elbert wrote: 
> 
> > Well I was just following the logic that a restart of a termination 
> > already in service is a noop. Is the root termination a 
> special case ? 
> > . The problem with poll vs restart is the same in any case. 
> > 
> > -----Original Message----- 
> > From: Chuong Nguyen [ mailto:Chuong.Nguyen@usa.alcatel.com
 ] 
> > Sent: Monday, May 14, 2001 12:22 PM 
> > To: megaco@fore.com 
> > Subject: Re: Implementors' Guide Update Editor's last Call - MGC 
> > failure 
> > 
> > 
> > To me definitely NOT. 
> > How will MGC knows that it is a registration restarts vs a poll? 
> > Don't tell me that one can use Reason Code since Reason 
> Code has to be 
> > IANA registered 
> > before it can be widely used. 
> > But since anyone can register w/IANA at any time, it only means that 
> > it might not be supported by 
> > everyone. 
> > 
> > Chuong 
> > 
> > Dan Elbert wrote: 
> > 
> > Another thing : Can I then use a restart of the "root" 
> termination to 
> > poll the MGC ? It seems to me more clean that to just use any 
> > termination. 
> > 
> > -----Original Message----- 
> > From: Rosen, Brian [ mailto:Brian.Rosen@marconi.com
 ] 
> > Sent: Monday, May 14, 2001 12:00 PM 
> > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen' 
> > Subject: RE: Implementors' Guide Update Editor's last Call - MGC 
> > failure 
> > 
> > I think that a restart of a termination that is already in service 
> > should be treated 
> > 
> > as a nop by an MGC. 
> > 
> > I have no objection to adding an explicit no-op method, but I don't 
> > think it is needed. 
> > 
> > Brian 
> > -----Original Message----- 
> > 
> > From: Dan Elbert [ mailto:DElbert@radvision.com
 ] 
> > Sent: Friday, May 11, 2001 5:57 PM 
> > To: 'megaco@fore.com'; 'Chuong Nguyen' 
> > Subject: RE: Implementors' Guide Update Editor's last Call - MGC 
> > failure 
> > Using a fully specified terminationID can disrupt the 
> operation of the 
> > termination (for example if the termination is in a call). 
> > 
> > It's not clear what a "bogus" termination is, if the MGC receives a 
> > SVC from an MG termination it can assume that this 
> termination is real 
> > and start sending audits or commands. 
> > 
> > Yes, by poll I mean some type of heartbeat as the MG needs 
> to know if 
> > the MGC is alive. 
> > 
> > Brian Rosen suggested in the past to use SVC with Restart method for 
> > this purpose, I don't think that there was any mantion if 
> this should 
> > be done with id=root or other. 
> > 
> > Dan 
> > -----Original Message----- 
> > 
> > From: Chuong Nguyen [ mailto:Chuong.Nguyen@usa.alcatel.com
 ] 
> > Sent: Friday, May 11, 2001 5:38 PM 
> > To: megaco@fore.com 
> > Subject: Re: Implementors' Guide Update Editor's last Call - MGC 
> > failure 
> > 
> > The intend was not to use ROOT but a fully specified 
> terminationID or 
> > even better a 
> > known invalid terminationID (A bogus terminationID that the sender 
> > knows is not valid and is 
> > used specifically for heartbeat purpose).  The idea is to get some 
> > kind of responses. 
> > 
> > "poll" do you mean heartbeat like msg to from MG to MGC or something 
> > else here. 
> > 
> > Where did you see that Restart w/ROOT is used as a heartbeat/poll? 
> > 
> > Chuong 
> > 
> > Dan Elbert wrote: 
> > Hi 
> > 
> > After reviewing the issue of MGC failure ( when the MG is connected 
> > trough UDP ) I believe that there is no satisfactory way 
> for the MG to 
> > poll the MGC to see if the MGC is still alive. Using a ServiceChange 
> > with "Restart" method and termination id of "root" may cause the MGC 
> > to assume that the MG restarted and can affect the state of 
> a call in 
> > progress. 
> > 
> > I think that it would be good to add a ServiceChange method "noop" : 
> > 
> > Noop : Can be used by the MG (with unreliable protocols) to obtain a 
> > response from the MGC or detect a communication failure. When 
> > receiving this SVC the MGC should take no action other that reply. 
> > 
> > If this is not acceptable, then I think that some clarification is 
> > needed as when a SVC with restart method should be considered "noop" 
> > by the MGC. 
> > 
> > Dan Elbert 
> > 
> > RADVISION 
> > 
> > -- 
> > 
> >   Alcatel USA, Inc             Internet: 
> Chuong.Nguyen@usa.alcatel.com 
> > 
> >   1000 Coit Road Plano, Texas 75075           Phone:    
> (972) 519-4613 
> > 
> >   **** The opinions expressed are not those of Alcatel USA, Inc **** 
> > 
> > -- 
> > 
> >   Alcatel USA, Inc             Internet: 
> Chuong.Nguyen@usa.alcatel.com 
> > 
> >   1000 Coit Road Plano, Texas 75075           Phone:    
> (972) 519-4613 
> > 
> >   **** The opinions expressed are not those of Alcatel USA, Inc **** 
> > 
> 
> 


------_=_NextPart_001_01C0DD35.06C36DD0
Content-Type: text/html;
	charset="ISO-8859-1"




Polls of MGC (was RE: Implementors' Guide Update Editor's last Call - MGC failure)






I don't think 
a restart of an already in service termination can imply loss of 
state;


you would 
have to take it down and then bring it up to have loss of 
state.


 


I do think we 
want a real no-op, and not something that generates an 
error.


If you insist 
in can't be restart of an inservice termination, then we 
should


add the no-op 
method.


 


Brian



  
-----Original Message-----
From: Tom-PT Taylor 
  [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, May 15, 2001 3:59 
  AM
To: Kevin Boyle; Dan Elbert
Cc: megaco@fore.com; 
  'Chuong Nguyen'
Subject: Polls of MGC (was RE: Implementors' Guide 
  Update Editor's last Ca ll - MGC failure)


  
Let's follow through the logic here.  A restart implies 
  loss of state.  I don't care whether you're talking ROOT or a real 
  termination.  It would be inconsistent to declare restart of the latter a 
  no-op.

  
I'd suggest the safest poll would be a NOTIFY with no events 
  and a bogus requestID in it.  The MGC has to answer, even if only to 
  return an error, but the NOTIFY doesn't change anything.

  
> -----Original Message----- 
> 
  From: Boyle, Kevin [NCRTP:3Z70:EXCH] 
> Sent: 
  Monday, May 14, 2001 12:50 PM 
> To: Dan 
  Elbert 
> Cc: megaco@fore.com; 'Chuong 
  Nguyen' 
> Subject: Re: Implementors' Guide Update 
  Editor's last Call - 
> MGC failure 
> 
> 
> 
  Yes.  Root is a special case.  Restart on Root, if it is already 
  in 
> service, implies that the MG has gone out of 
  service and returned, and 
> that anything that was 
  happening previously is lost.  This 
> was 
  discussed 
> on an earlier thread. 
> 
> Kevin 
> 
  
> Dan Elbert wrote: 
> 
  
> > Well I was just following the logic that a 
  restart of a termination 
> > already in service 
  is a noop. Is the root termination a 
> special case 
  ? 
> > . The problem with poll vs restart is the 
  same in any case. 
> > 
> > -----Original Message----- 
> > 
  From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com] 
  
> > Sent: Monday, May 14, 2001 12:22 PM 
  
> > To: megaco@fore.com 
> 
  > Subject: Re: Implementors' Guide Update Editor's last Call - MGC 
  
> > failure 
> > 
  
> > 
> > To me definitely 
  NOT. 
> > How will MGC knows that it is a 
  registration restarts vs a poll? 
> > Don't tell 
  me that one can use Reason Code since Reason 
> Code 
  has to be 
> > IANA registered 
> > before it can be widely used. 
> 
  > But since anyone can register w/IANA at any time, it only means 
  that 
> > it might not be supported by 
  
> > everyone. 
> > 
  
> > Chuong 
> > 
  
> > Dan Elbert wrote: 
> 
  > 
> > Another thing : Can I then use a 
  restart of the "root" 
> termination to 
  
> > poll the MGC ? It seems to me more clean that to 
  just use any 
> > termination. 
> > 
> > -----Original 
  Message----- 
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] 
  
> > Sent: Monday, May 14, 2001 12:00 PM 
  
> > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong 
  Nguyen' 
> > Subject: RE: Implementors' Guide 
  Update Editor's last Call - MGC 
> > 
  failure 
> > 
> > I 
  think that a restart of a termination that is already in service 
  
> > should be treated 
> 
  > 
> > as a nop by an MGC. 
> > 
> > I have no objection to 
  adding an explicit no-op method, but I don't 
> > 
  think it is needed. 
> > 
> > Brian 
> > -----Original 
  Message----- 
> > 
> 
  > From: Dan Elbert [mailto:DElbert@radvision.com] 
  
> > Sent: Friday, May 11, 2001 5:57 PM 
> > To: 'megaco@fore.com'; 'Chuong Nguyen' 
> > Subject: RE: Implementors' Guide Update Editor's last Call - 
  MGC 
> > failure 
> 
  > Using a fully specified terminationID can disrupt the 
> operation of the 
> > termination 
  (for example if the termination is in a call). 
> 
  > 
> > It's not clear what a "bogus" 
  termination is, if the MGC receives a 
> > SVC 
  from an MG termination it can assume that this 
> 
  termination is real 
> > and start sending audits 
  or commands. 
> > 
> 
  > Yes, by poll I mean some type of heartbeat as the MG needs 
  
> to know if 
> > the 
  MGC is alive. 
> > 
> 
  > Brian Rosen suggested in the past to use SVC with Restart method 
  for 
> > this purpose, I don't think that there 
  was any mantion if 
> this should 
> > be done with id=root or other. 
> 
  > 
> > Dan 
> > 
  -----Original Message----- 
> > 
> > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com] 
  
> > Sent: Friday, May 11, 2001 5:38 PM 
> > To: megaco@fore.com 
> > 
  Subject: Re: Implementors' Guide Update Editor's last Call - MGC 
  
> > failure 
> > 
  
> > The intend was not to use ROOT but a fully 
  specified 
> terminationID or 
> > even better a 
> > known invalid 
  terminationID (A bogus terminationID that the sender 
> > knows is not valid and is 
> > 
  used specifically for heartbeat purpose).  The idea is to get some 
  
> > kind of responses. 
> 
  > 
> > "poll" do you mean heartbeat like msg 
  to from MG to MGC or something 
> > else 
  here. 
> > 
> > 
  Where did you see that Restart w/ROOT is used as a heartbeat/poll? 
  
> > 
> > Chuong 
  
> > 
> > Dan Elbert 
  wrote: 
> > Hi 
> 
  > 
> > After reviewing the issue of MGC 
  failure ( when the MG is connected 
> > trough 
  UDP ) I believe that there is no satisfactory way 
> 
  for the MG to 
> > poll the MGC to see if the MGC 
  is still alive. Using a ServiceChange 
> > with 
  "Restart" method and termination id of "root" may cause the MGC 
  
> > to assume that the MG restarted and can affect the 
  state of 
> a call in 
> 
  > progress. 
> > 
> 
  > I think that it would be good to add a ServiceChange method "noop" 
  : 
> > 
> > Noop : 
  Can be used by the MG (with unreliable protocols) to obtain a 
> > response from the MGC or detect a communication failure. 
  When 
> > receiving this SVC the MGC should take 
  no action other that reply. 
> > 
> > If this is not acceptable, then I think that some 
  clarification is 
> > needed as when a SVC with 
  restart method should be considered "noop" 
> > 
  by the MGC. 
> > 
> 
  > Dan Elbert 
> > 
> 
  > RADVISION 
> > 
> 
  > -- 
> > 
> 
  >   Alcatel USA, 
  Inc             
  Internet: 
> Chuong.Nguyen@usa.alcatel.com 
  
> > 
> >   1000 
  Coit Road Plano, Texas 
  75075           
  Phone:    
> (972) 519-4613 
  
> > 
> >   **** 
  The opinions expressed are not those of Alcatel USA, Inc **** 
> > 
> > -- 
> > 
> >   Alcatel USA, 
  Inc             
  Internet: 
> Chuong.Nguyen@usa.alcatel.com 
  
> > 
> >   1000 
  Coit Road Plano, Texas 
  75075           
  Phone:    
> (972) 519-4613 
  
> > 
> >   **** 
  The opinions expressed are not those of Alcatel USA, Inc **** 
> > 
> 
> 
  


------_=_NextPart_001_01C0DD35.06C36DD0--


From owner-megaco@fore.com  Tue May 15 08:07:26 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22788
	for ; Tue, 15 May 2001 08:07:25 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA03596;
	Tue, 15 May 2001 08:00:06 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA10710
	for megaco-list; Tue, 15 May 2001 07:57:11 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA10693
	for ; Tue, 15 May 2001 07:57:08 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 15 May 2001 07:56:39 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F5F5@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Tom-PT Taylor'" ,
        Kevin Boyle
	 ,
        Dan Elbert 
Cc: megaco@fore.com, "'Chuong Nguyen'" 
Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's las
	t Ca ll -  MGC failure)
Date: Tue, 15 May 2001 07:57:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

If you don't want to create the noop method, we can go 
back to a package.

   
   PackageID: nop (0x00xx) 
   Version: 1 
   Extends: None 
    
   Description: No op event.  Can be used for testing or MG poll of MGC. 
    
Properties 
    
   None 
    
Events 
    
   noop 
   ----- 
   EventID:     noop (0x0001) 
    
   No op event 
    
   Events Descriptor Parameters: 
    
        Interval 
        ------------- 
        ParameterID: delay (0x0001) 
         
        Description: delay in milliseconds to generate event.
	      if not specified, MG may choose any value. 0 implies
		 immediate response.  
        Possible Values: INTEGER

Brian 

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, May 15, 2001 3:59 AM
To: Kevin Boyle; Dan Elbert
Cc: megaco@fore.com; 'Chuong Nguyen'
Subject: Polls of MGC (was RE: Implementors' Guide Update Editor's last Ca
ll - MGC failure)


Let's follow through the logic here.  A restart implies loss of state.  I
don't care whether you're talking ROOT or a real termination.  It would be
inconsistent to declare restart of the latter a no-op.
I'd suggest the safest poll would be a NOTIFY with no events and a bogus
requestID in it.  The MGC has to answer, even if only to return an error,
but the NOTIFY doesn't change anything.
> -----Original Message----- 
> From: Boyle, Kevin [NCRTP:3Z70:EXCH] 
> Sent: Monday, May 14, 2001 12:50 PM 
> To: Dan Elbert 
> Cc: megaco@fore.com; 'Chuong Nguyen' 
> Subject: Re: Implementors' Guide Update Editor's last Call - 
> MGC failure 
> 
> 
> Yes.  Root is a special case.  Restart on Root, if it is already in 
> service, implies that the MG has gone out of service and returned, and 
> that anything that was happening previously is lost.  This 
> was discussed 
> on an earlier thread. 
> 
> Kevin 
> 
> Dan Elbert wrote: 
> 
> > Well I was just following the logic that a restart of a termination 
> > already in service is a noop. Is the root termination a 
> special case ? 
> > . The problem with poll vs restart is the same in any case. 
> > 
> > -----Original Message----- 
> > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com] 
> > Sent: Monday, May 14, 2001 12:22 PM 
> > To: megaco@fore.com 
> > Subject: Re: Implementors' Guide Update Editor's last Call - MGC 
> > failure 
> > 
> > 
> > To me definitely NOT. 
> > How will MGC knows that it is a registration restarts vs a poll? 
> > Don't tell me that one can use Reason Code since Reason 
> Code has to be 
> > IANA registered 
> > before it can be widely used. 
> > But since anyone can register w/IANA at any time, it only means that 
> > it might not be supported by 
> > everyone. 
> > 
> > Chuong 
> > 
> > Dan Elbert wrote: 
> > 
> > Another thing : Can I then use a restart of the "root" 
> termination to 
> > poll the MGC ? It seems to me more clean that to just use any 
> > termination. 
> > 
> > -----Original Message----- 
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] 
> > Sent: Monday, May 14, 2001 12:00 PM 
> > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen' 
> > Subject: RE: Implementors' Guide Update Editor's last Call - MGC 
> > failure 
> > 
> > I think that a restart of a termination that is already in service 
> > should be treated 
> > 
> > as a nop by an MGC. 
> > 
> > I have no objection to adding an explicit no-op method, but I don't 
> > think it is needed. 
> > 
> > Brian 
> > -----Original Message----- 
> > 
> > From: Dan Elbert [mailto:DElbert@radvision.com] 
> > Sent: Friday, May 11, 2001 5:57 PM 
> > To: 'megaco@fore.com'; 'Chuong Nguyen' 
> > Subject: RE: Implementors' Guide Update Editor's last Call - MGC 
> > failure 
> > Using a fully specified terminationID can disrupt the 
> operation of the 
> > termination (for example if the termination is in a call). 
> > 
> > It's not clear what a "bogus" termination is, if the MGC receives a 
> > SVC from an MG termination it can assume that this 
> termination is real 
> > and start sending audits or commands. 
> > 
> > Yes, by poll I mean some type of heartbeat as the MG needs 
> to know if 
> > the MGC is alive. 
> > 
> > Brian Rosen suggested in the past to use SVC with Restart method for 
> > this purpose, I don't think that there was any mantion if 
> this should 
> > be done with id=root or other. 
> > 
> > Dan 
> > -----Original Message----- 
> > 
> > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com] 
> > Sent: Friday, May 11, 2001 5:38 PM 
> > To: megaco@fore.com 
> > Subject: Re: Implementors' Guide Update Editor's last Call - MGC 
> > failure 
> > 
> > The intend was not to use ROOT but a fully specified 
> terminationID or 
> > even better a 
> > known invalid terminationID (A bogus terminationID that the sender 
> > knows is not valid and is 
> > used specifically for heartbeat purpose).  The idea is to get some 
> > kind of responses. 
> > 
> > "poll" do you mean heartbeat like msg to from MG to MGC or something 
> > else here. 
> > 
> > Where did you see that Restart w/ROOT is used as a heartbeat/poll? 
> > 
> > Chuong 
> > 
> > Dan Elbert wrote: 
> > Hi 
> > 
> > After reviewing the issue of MGC failure ( when the MG is connected 
> > trough UDP ) I believe that there is no satisfactory way 
> for the MG to 
> > poll the MGC to see if the MGC is still alive. Using a ServiceChange 
> > with "Restart" method and termination id of "root" may cause the MGC 
> > to assume that the MG restarted and can affect the state of 
> a call in 
> > progress. 
> > 
> > I think that it would be good to add a ServiceChange method "noop" : 
> > 
> > Noop : Can be used by the MG (with unreliable protocols) to obtain a 
> > response from the MGC or detect a communication failure. When 
> > receiving this SVC the MGC should take no action other that reply. 
> > 
> > If this is not acceptable, then I think that some clarification is 
> > needed as when a SVC with restart method should be considered "noop" 
> > by the MGC. 
> > 
> > Dan Elbert 
> > 
> > RADVISION 
> > 
> > -- 
> > 
> >   Alcatel USA, Inc             Internet: 
> Chuong.Nguyen@usa.alcatel.com 
> > 
> >   1000 Coit Road Plano, Texas 75075           Phone:    
> (972) 519-4613 
> > 
> >   **** The opinions expressed are not those of Alcatel USA, Inc **** 
> > 
> > -- 
> > 
> >   Alcatel USA, Inc             Internet: 
> Chuong.Nguyen@usa.alcatel.com 
> > 
> >   1000 Coit Road Plano, Texas 75075           Phone:    
> (972) 519-4613 
> > 
> >   **** The opinions expressed are not those of Alcatel USA, Inc **** 
> > 
> 
> 


From owner-megaco@fore.com  Tue May 15 09:20:55 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25730
	for ; Tue, 15 May 2001 09:20:55 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA09877;
	Tue, 15 May 2001 09:14:16 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA00640
	for megaco-list; Tue, 15 May 2001 09:10:10 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA00625
	for ; Tue, 15 May 2001 09:10:08 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA09443
	for ; Tue, 15 May 2001 09:10:05 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACO10921;
	Tue, 15 May 2001 09:08:21 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Rosen, Brian'" ,
        "'Tom-PT Taylor'" ,
        "'Kevin Boyle'" ,
        "'Dan Elbert'" 
Cc: , "'Chuong Nguyen'" 
Subject: RE: Polls of MGC (was RE: Implementers' Guide Update Editor's last Ca ll -  MGC failure)
Date: Tue, 15 May 2001 09:12:39 -0400
Message-ID: <00cf01c0dd40$b86499a0$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <4FBEA8857476D311A03300204840E1CF01A6F5F5@whq-msgusr-02.pit.comms.marconi.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi All,
If this event is defined in a new package, does the MGC needs to send this
event in the event descriptor...or is this an exception of the normal event
detection behavior?
Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Tuesday, May 15, 2001 7:57 AM
To: 'Tom-PT Taylor'; Kevin Boyle; Dan Elbert
Cc: megaco@fore.com; 'Chuong Nguyen'
Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's
last Ca ll - MGC failure)


If you don't want to create the noop method, we can go
back to a package.


   PackageID: nop (0x00xx)
   Version: 1
   Extends: None

   Description: No op event.  Can be used for testing or MG poll of MGC.

Properties

   None

Events

   noop
   -----
   EventID:     noop (0x0001)

   No op event

   Events Descriptor Parameters:

        Interval
        -------------
        ParameterID: delay (0x0001)

        Description: delay in milliseconds to generate event.
	      if not specified, MG may choose any value. 0 implies
		 immediate response.
        Possible Values: INTEGER

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, May 15, 2001 3:59 AM
To: Kevin Boyle; Dan Elbert
Cc: megaco@fore.com; 'Chuong Nguyen'
Subject: Polls of MGC (was RE: Implementors' Guide Update Editor's last Ca
ll - MGC failure)


Let's follow through the logic here.  A restart implies loss of state.  I
don't care whether you're talking ROOT or a real termination.  It would be
inconsistent to declare restart of the latter a no-op.
I'd suggest the safest poll would be a NOTIFY with no events and a bogus
requestID in it.  The MGC has to answer, even if only to return an error,
but the NOTIFY doesn't change anything.
> -----Original Message-----
> From: Boyle, Kevin [NCRTP:3Z70:EXCH]
> Sent: Monday, May 14, 2001 12:50 PM
> To: Dan Elbert
> Cc: megaco@fore.com; 'Chuong Nguyen'
> Subject: Re: Implementors' Guide Update Editor's last Call -
> MGC failure
>
>
> Yes.  Root is a special case.  Restart on Root, if it is already in
> service, implies that the MG has gone out of service and returned, and
> that anything that was happening previously is lost.  This
> was discussed
> on an earlier thread.
>
> Kevin
>
> Dan Elbert wrote:
>
> > Well I was just following the logic that a restart of a termination
> > already in service is a noop. Is the root termination a
> special case ?
> > . The problem with poll vs restart is the same in any case.
> >
> > -----Original Message-----
> > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > Sent: Monday, May 14, 2001 12:22 PM
> > To: megaco@fore.com
> > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
> > failure
> >
> >
> > To me definitely NOT.
> > How will MGC knows that it is a registration restarts vs a poll?
> > Don't tell me that one can use Reason Code since Reason
> Code has to be
> > IANA registered
> > before it can be widely used.
> > But since anyone can register w/IANA at any time, it only means that
> > it might not be supported by
> > everyone.
> >
> > Chuong
> >
> > Dan Elbert wrote:
> >
> > Another thing : Can I then use a restart of the "root"
> termination to
> > poll the MGC ? It seems to me more clean that to just use any
> > termination.
> >
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > Sent: Monday, May 14, 2001 12:00 PM
> > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen'
> > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
> > failure
> >
> > I think that a restart of a termination that is already in service
> > should be treated
> >
> > as a nop by an MGC.
> >
> > I have no objection to adding an explicit no-op method, but I don't
> > think it is needed.
> >
> > Brian
> > -----Original Message-----
> >
> > From: Dan Elbert [mailto:DElbert@radvision.com]
> > Sent: Friday, May 11, 2001 5:57 PM
> > To: 'megaco@fore.com'; 'Chuong Nguyen'
> > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
> > failure
> > Using a fully specified terminationID can disrupt the
> operation of the
> > termination (for example if the termination is in a call).
> >
> > It's not clear what a "bogus" termination is, if the MGC receives a
> > SVC from an MG termination it can assume that this
> termination is real
> > and start sending audits or commands.
> >
> > Yes, by poll I mean some type of heartbeat as the MG needs
> to know if
> > the MGC is alive.
> >
> > Brian Rosen suggested in the past to use SVC with Restart method for
> > this purpose, I don't think that there was any mantion if
> this should
> > be done with id=root or other.
> >
> > Dan
> > -----Original Message-----
> >
> > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > Sent: Friday, May 11, 2001 5:38 PM
> > To: megaco@fore.com
> > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
> > failure
> >
> > The intend was not to use ROOT but a fully specified
> terminationID or
> > even better a
> > known invalid terminationID (A bogus terminationID that the sender
> > knows is not valid and is
> > used specifically for heartbeat purpose).  The idea is to get some
> > kind of responses.
> >
> > "poll" do you mean heartbeat like msg to from MG to MGC or something
> > else here.
> >
> > Where did you see that Restart w/ROOT is used as a heartbeat/poll?
> >
> > Chuong
> >
> > Dan Elbert wrote:
> > Hi
> >
> > After reviewing the issue of MGC failure ( when the MG is connected
> > trough UDP ) I believe that there is no satisfactory way
> for the MG to
> > poll the MGC to see if the MGC is still alive. Using a ServiceChange
> > with "Restart" method and termination id of "root" may cause the MGC
> > to assume that the MG restarted and can affect the state of
> a call in
> > progress.
> >
> > I think that it would be good to add a ServiceChange method "noop" :
> >
> > Noop : Can be used by the MG (with unreliable protocols) to obtain a
> > response from the MGC or detect a communication failure. When
> > receiving this SVC the MGC should take no action other that reply.
> >
> > If this is not acceptable, then I think that some clarification is
> > needed as when a SVC with restart method should be considered "noop"
> > by the MGC.
> >
> > Dan Elbert
> >
> > RADVISION
> >
> > --
> >
> >   Alcatel USA, Inc             Internet:
> Chuong.Nguyen@usa.alcatel.com
> >
> >   1000 Coit Road Plano, Texas 75075           Phone:
> (972) 519-4613
> >
> >   **** The opinions expressed are not those of Alcatel USA, Inc ****
> >
> > --
> >
> >   Alcatel USA, Inc             Internet:
> Chuong.Nguyen@usa.alcatel.com
> >
> >   1000 Coit Road Plano, Texas 75075           Phone:
> (972) 519-4613
> >
> >   **** The opinions expressed are not those of Alcatel USA, Inc ****
> >
>
>



From owner-megaco@fore.com  Tue May 15 09:22:53 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25787
	for ; Tue, 15 May 2001 09:22:52 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA10051;
	Tue, 15 May 2001 09:15:01 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA00871
	for megaco-list; Tue, 15 May 2001 09:11:18 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA00864
	for ; Tue, 15 May 2001 09:11:16 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 15 May 2001 09:10:48 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F5FC@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Madhu Babu Brahmanapally'" ,
        "'Tom-PT Taylor'"
	 ,
        "'Kevin Boyle'" ,
        "'Dan Elbert'" 
Cc: megaco@fore.com, "'Chuong Nguyen'" 
Subject: RE: Polls of MGC (was RE: Implementers' Guide Update Editor's las
	t Ca ll -  MGC failure)
Date: Tue, 15 May 2001 09:11:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

It would be a real package (would need approval).  You would have
to put it in the event descriptor, but I think that is right -
you don't want the MGC getting events it didn't expect.

Brian

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Tuesday, May 15, 2001 9:13 AM
> To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Kevin Boyle'; 'Dan Elbert'
> Cc: megaco@fore.com; 'Chuong Nguyen'
> Subject: RE: Polls of MGC (was RE: Implementers' Guide Update Editor's
> last Ca ll - MGC failure)
> 
> 
> Hi All,
> If this event is defined in a new package, does the MGC needs 
> to send this
> event in the event descriptor...or is this an exception of 
> the normal event
> detection behavior?
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> Sent: Tuesday, May 15, 2001 7:57 AM
> To: 'Tom-PT Taylor'; Kevin Boyle; Dan Elbert
> Cc: megaco@fore.com; 'Chuong Nguyen'
> Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's
> last Ca ll - MGC failure)
> 
> 
> If you don't want to create the noop method, we can go
> back to a package.
> 
> 
>    PackageID: nop (0x00xx)
>    Version: 1
>    Extends: None
> 
>    Description: No op event.  Can be used for testing or MG 
> poll of MGC.
> 
> Properties
> 
>    None
> 
> Events
> 
>    noop
>    -----
>    EventID:     noop (0x0001)
> 
>    No op event
> 
>    Events Descriptor Parameters:
> 
>         Interval
>         -------------
>         ParameterID: delay (0x0001)
> 
>         Description: delay in milliseconds to generate event.
> 	      if not specified, MG may choose any value. 0 implies
> 		 immediate response.
>         Possible Values: INTEGER
> 
> Brian
> 
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Tuesday, May 15, 2001 3:59 AM
> To: Kevin Boyle; Dan Elbert
> Cc: megaco@fore.com; 'Chuong Nguyen'
> Subject: Polls of MGC (was RE: Implementors' Guide Update 
> Editor's last Ca
> ll - MGC failure)
> 
> 
> Let's follow through the logic here.  A restart implies loss 
> of state.  I
> don't care whether you're talking ROOT or a real termination. 
>  It would be
> inconsistent to declare restart of the latter a no-op.
> I'd suggest the safest poll would be a NOTIFY with no events 
> and a bogus
> requestID in it.  The MGC has to answer, even if only to 
> return an error,
> but the NOTIFY doesn't change anything.
> > -----Original Message-----
> > From: Boyle, Kevin [NCRTP:3Z70:EXCH]
> > Sent: Monday, May 14, 2001 12:50 PM
> > To: Dan Elbert
> > Cc: megaco@fore.com; 'Chuong Nguyen'
> > Subject: Re: Implementors' Guide Update Editor's last Call -
> > MGC failure
> >
> >
> > Yes.  Root is a special case.  Restart on Root, if it is already in
> > service, implies that the MG has gone out of service and 
> returned, and
> > that anything that was happening previously is lost.  This
> > was discussed
> > on an earlier thread.
> >
> > Kevin
> >
> > Dan Elbert wrote:
> >
> > > Well I was just following the logic that a restart of a 
> termination
> > > already in service is a noop. Is the root termination a
> > special case ?
> > > . The problem with poll vs restart is the same in any case.
> > >
> > > -----Original Message-----
> > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > > Sent: Monday, May 14, 2001 12:22 PM
> > > To: megaco@fore.com
> > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
> > > failure
> > >
> > >
> > > To me definitely NOT.
> > > How will MGC knows that it is a registration restarts vs a poll?
> > > Don't tell me that one can use Reason Code since Reason
> > Code has to be
> > > IANA registered
> > > before it can be widely used.
> > > But since anyone can register w/IANA at any time, it only 
> means that
> > > it might not be supported by
> > > everyone.
> > >
> > > Chuong
> > >
> > > Dan Elbert wrote:
> > >
> > > Another thing : Can I then use a restart of the "root"
> > termination to
> > > poll the MGC ? It seems to me more clean that to just use any
> > > termination.
> > >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > Sent: Monday, May 14, 2001 12:00 PM
> > > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen'
> > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
> > > failure
> > >
> > > I think that a restart of a termination that is already in service
> > > should be treated
> > >
> > > as a nop by an MGC.
> > >
> > > I have no objection to adding an explicit no-op method, 
> but I don't
> > > think it is needed.
> > >
> > > Brian
> > > -----Original Message-----
> > >
> > > From: Dan Elbert [mailto:DElbert@radvision.com]
> > > Sent: Friday, May 11, 2001 5:57 PM
> > > To: 'megaco@fore.com'; 'Chuong Nguyen'
> > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
> > > failure
> > > Using a fully specified terminationID can disrupt the
> > operation of the
> > > termination (for example if the termination is in a call).
> > >
> > > It's not clear what a "bogus" termination is, if the MGC 
> receives a
> > > SVC from an MG termination it can assume that this
> > termination is real
> > > and start sending audits or commands.
> > >
> > > Yes, by poll I mean some type of heartbeat as the MG needs
> > to know if
> > > the MGC is alive.
> > >
> > > Brian Rosen suggested in the past to use SVC with Restart 
> method for
> > > this purpose, I don't think that there was any mantion if
> > this should
> > > be done with id=root or other.
> > >
> > > Dan
> > > -----Original Message-----
> > >
> > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > > Sent: Friday, May 11, 2001 5:38 PM
> > > To: megaco@fore.com
> > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
> > > failure
> > >
> > > The intend was not to use ROOT but a fully specified
> > terminationID or
> > > even better a
> > > known invalid terminationID (A bogus terminationID that the sender
> > > knows is not valid and is
> > > used specifically for heartbeat purpose).  The idea is to get some
> > > kind of responses.
> > >
> > > "poll" do you mean heartbeat like msg to from MG to MGC 
> or something
> > > else here.
> > >
> > > Where did you see that Restart w/ROOT is used as a heartbeat/poll?
> > >
> > > Chuong
> > >
> > > Dan Elbert wrote:
> > > Hi
> > >
> > > After reviewing the issue of MGC failure ( when the MG is 
> connected
> > > trough UDP ) I believe that there is no satisfactory way
> > for the MG to
> > > poll the MGC to see if the MGC is still alive. Using a 
> ServiceChange
> > > with "Restart" method and termination id of "root" may 
> cause the MGC
> > > to assume that the MG restarted and can affect the state of
> > a call in
> > > progress.
> > >
> > > I think that it would be good to add a ServiceChange 
> method "noop" :
> > >
> > > Noop : Can be used by the MG (with unreliable protocols) 
> to obtain a
> > > response from the MGC or detect a communication failure. When
> > > receiving this SVC the MGC should take no action other that reply.
> > >
> > > If this is not acceptable, then I think that some clarification is
> > > needed as when a SVC with restart method should be 
> considered "noop"
> > > by the MGC.
> > >
> > > Dan Elbert
> > >
> > > RADVISION
> > >
> > > --
> > >
> > >   Alcatel USA, Inc             Internet:
> > Chuong.Nguyen@usa.alcatel.com
> > >
> > >   1000 Coit Road Plano, Texas 75075           Phone:
> > (972) 519-4613
> > >
> > >   **** The opinions expressed are not those of Alcatel 
> USA, Inc ****
> > >
> > > --
> > >
> > >   Alcatel USA, Inc             Internet:
> > Chuong.Nguyen@usa.alcatel.com
> > >
> > >   1000 Coit Road Plano, Texas 75075           Phone:
> > (972) 519-4613
> > >
> > >   **** The opinions expressed are not those of Alcatel 
> USA, Inc ****
> > >
> >
> >
> 


From owner-megaco@fore.com  Tue May 15 09:40:23 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26661
	for ; Tue, 15 May 2001 09:40:22 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA11683;
	Tue, 15 May 2001 09:30:09 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA04593
	for megaco-list; Tue, 15 May 2001 09:25:06 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA04555
	for ; Tue, 15 May 2001 09:25:00 -0400 (EDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA11123
	for ; Tue, 15 May 2001 09:24:55 -0400 (EDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id IAA27240
	for ; Tue, 15 May 2001 08:24:56 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4FDOtC09286
	for ; Tue, 15 May 2001 08:24:55 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4FDO9108235
	for ; Tue, 15 May 2001 08:24:09 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4FDO9O19196
	for ; Tue, 15 May 2001 08:24:09 -0500 (CDT)
Message-ID: <3B012DF9.365A5D4A@usa.alcatel.com>
Date: Tue, 15 May 2001 08:24:09 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Polls of MGC (was RE: Implementers' Guide Update Editor's last Ca ll 
 -  MGC failure)
References: <4FBEA8857476D311A03300204840E1CF01A6F5FC@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: multipart/alternative;
 boundary="------------0B022C3760FCA8494258366E"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------0B022C3760FCA8494258366E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Notify goes from MG to MGC.
MGC does not send Notify.

So how does MGC poll the MG?
If we are making the assumption that by MGC requesting an event from MG, we

are saying that MGC is sort of polling MG too.

But what if MG does not support this package?

Chuong



"Rosen, Brian" wrote:

> It would be a real package (would need approval).  You would have
> to put it in the event descriptor, but I think that is right -
> you don't want the MGC getting events it didn't expect.
>
> Brian
>
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > Sent: Tuesday, May 15, 2001 9:13 AM
> > To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Kevin Boyle'; 'Dan Elbert'
> > Cc: megaco@fore.com; 'Chuong Nguyen'
> > Subject: RE: Polls of MGC (was RE: Implementers' Guide Update Editor's
> > last Ca ll - MGC failure)
> >
> >
> > Hi All,
> > If this event is defined in a new package, does the MGC needs
> > to send this
> > event in the event descriptor...or is this an exception of
> > the normal event
> > detection behavior?
> > Regards
> > Madhubabu
> >
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> > Sent: Tuesday, May 15, 2001 7:57 AM
> > To: 'Tom-PT Taylor'; Kevin Boyle; Dan Elbert
> > Cc: megaco@fore.com; 'Chuong Nguyen'
> > Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's
> > last Ca ll - MGC failure)
> >
> >
> > If you don't want to create the noop method, we can go
> > back to a package.
> >
> >
> >    PackageID: nop (0x00xx)
> >    Version: 1
> >    Extends: None
> >
> >    Description: No op event.  Can be used for testing or MG
> > poll of MGC.
> >
> > Properties
> >
> >    None
> >
> > Events
> >
> >    noop
> >    -----
> >    EventID:     noop (0x0001)
> >
> >    No op event
> >
> >    Events Descriptor Parameters:
> >
> >         Interval
> >         -------------
> >         ParameterID: delay (0x0001)
> >
> >         Description: delay in milliseconds to generate event.
> >             if not specified, MG may choose any value. 0 implies
> >                immediate response.
> >         Possible Values: INTEGER
> >
> > Brian
> >
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Tuesday, May 15, 2001 3:59 AM
> > To: Kevin Boyle; Dan Elbert
> > Cc: megaco@fore.com; 'Chuong Nguyen'
> > Subject: Polls of MGC (was RE: Implementors' Guide Update
> > Editor's last Ca
> > ll - MGC failure)
> >
> >
> > Let's follow through the logic here.  A restart implies loss
> > of state.  I
> > don't care whether you're talking ROOT or a real termination.
> >  It would be
> > inconsistent to declare restart of the latter a no-op.
> > I'd suggest the safest poll would be a NOTIFY with no events
> > and a bogus
> > requestID in it.  The MGC has to answer, even if only to
> > return an error,
> > but the NOTIFY doesn't change anything.
> > > -----Original Message-----
> > > From: Boyle, Kevin [NCRTP:3Z70:EXCH]
> > > Sent: Monday, May 14, 2001 12:50 PM
> > > To: Dan Elbert
> > > Cc: megaco@fore.com; 'Chuong Nguyen'
> > > Subject: Re: Implementors' Guide Update Editor's last Call -
> > > MGC failure
> > >
> > >
> > > Yes.  Root is a special case.  Restart on Root, if it is already in
> > > service, implies that the MG has gone out of service and
> > returned, and
> > > that anything that was happening previously is lost.  This
> > > was discussed
> > > on an earlier thread.
> > >
> > > Kevin
> > >
> > > Dan Elbert wrote:
> > >
> > > > Well I was just following the logic that a restart of a
> > termination
> > > > already in service is a noop. Is the root termination a
> > > special case ?
> > > > . The problem with poll vs restart is the same in any case.
> > > >
> > > > -----Original Message-----
> > > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > > > Sent: Monday, May 14, 2001 12:22 PM
> > > > To: megaco@fore.com
> > > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
> > > > failure
> > > >
> > > >
> > > > To me definitely NOT.
> > > > How will MGC knows that it is a registration restarts vs a poll?
> > > > Don't tell me that one can use Reason Code since Reason
> > > Code has to be
> > > > IANA registered
> > > > before it can be widely used.
> > > > But since anyone can register w/IANA at any time, it only
> > means that
> > > > it might not be supported by
> > > > everyone.
> > > >
> > > > Chuong
> > > >
> > > > Dan Elbert wrote:
> > > >
> > > > Another thing : Can I then use a restart of the "root"
> > > termination to
> > > > poll the MGC ? It seems to me more clean that to just use any
> > > > termination.
> > > >
> > > > -----Original Message-----
> > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > > Sent: Monday, May 14, 2001 12:00 PM
> > > > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen'
> > > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
> > > > failure
> > > >
> > > > I think that a restart of a termination that is already in service
> > > > should be treated
> > > >
> > > > as a nop by an MGC.
> > > >
> > > > I have no objection to adding an explicit no-op method,
> > but I don't
> > > > think it is needed.
> > > >
> > > > Brian
> > > > -----Original Message-----
> > > >
> > > > From: Dan Elbert [mailto:DElbert@radvision.com]
> > > > Sent: Friday, May 11, 2001 5:57 PM
> > > > To: 'megaco@fore.com'; 'Chuong Nguyen'
> > > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
> > > > failure
> > > > Using a fully specified terminationID can disrupt the
> > > operation of the
> > > > termination (for example if the termination is in a call).
> > > >
> > > > It's not clear what a "bogus" termination is, if the MGC
> > receives a
> > > > SVC from an MG termination it can assume that this
> > > termination is real
> > > > and start sending audits or commands.
> > > >
> > > > Yes, by poll I mean some type of heartbeat as the MG needs
> > > to know if
> > > > the MGC is alive.
> > > >
> > > > Brian Rosen suggested in the past to use SVC with Restart
> > method for
> > > > this purpose, I don't think that there was any mantion if
> > > this should
> > > > be done with id=root or other.
> > > >
> > > > Dan
> > > > -----Original Message-----
> > > >
> > > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > > > Sent: Friday, May 11, 2001 5:38 PM
> > > > To: megaco@fore.com
> > > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
> > > > failure
> > > >
> > > > The intend was not to use ROOT but a fully specified
> > > terminationID or
> > > > even better a
> > > > known invalid terminationID (A bogus terminationID that the sender
> > > > knows is not valid and is
> > > > used specifically for heartbeat purpose).  The idea is to get some
> > > > kind of responses.
> > > >
> > > > "poll" do you mean heartbeat like msg to from MG to MGC
> > or something
> > > > else here.
> > > >
> > > > Where did you see that Restart w/ROOT is used as a heartbeat/poll?
> > > >
> > > > Chuong
> > > >
> > > > Dan Elbert wrote:
> > > > Hi
> > > >
> > > > After reviewing the issue of MGC failure ( when the MG is
> > connected
> > > > trough UDP ) I believe that there is no satisfactory way
> > > for the MG to
> > > > poll the MGC to see if the MGC is still alive. Using a
> > ServiceChange
> > > > with "Restart" method and termination id of "root" may
> > cause the MGC
> > > > to assume that the MG restarted and can affect the state of
> > > a call in
> > > > progress.
> > > >
> > > > I think that it would be good to add a ServiceChange
> > method "noop" :
> > > >
> > > > Noop : Can be used by the MG (with unreliable protocols)
> > to obtain a
> > > > response from the MGC or detect a communication failure. When
> > > > receiving this SVC the MGC should take no action other that reply.
> > > >
> > > > If this is not acceptable, then I think that some clarification is
> > > > needed as when a SVC with restart method should be
> > considered "noop"
> > > > by the MGC.
> > > >
> > > > Dan Elbert
> > > >
> > > > RADVISION
> > > >
> > > > --
> > > >
> > > >   Alcatel USA, Inc             Internet:
> > > Chuong.Nguyen@usa.alcatel.com
> > > >
> > > >   1000 Coit Road Plano, Texas 75075           Phone:
> > > (972) 519-4613
> > > >
> > > >   **** The opinions expressed are not those of Alcatel
> > USA, Inc ****
> > > >
> > > > --
> > > >
> > > >   Alcatel USA, Inc             Internet:
> > > Chuong.Nguyen@usa.alcatel.com
> > > >
> > > >   1000 Coit Road Plano, Texas 75075           Phone:
> > > (972) 519-4613
> > > >
> > > >   **** The opinions expressed are not those of Alcatel
> > USA, Inc ****
> > > >
> > >
> > >
> >

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------0B022C3760FCA8494258366E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

Notify goes from MG to MGC.

MGC does not send Notify.

So how does MGC poll the MG?

If we are making the assumption that by MGC requesting an event from
MG, we

are saying that MGC is sort of polling MG too.

But what if MG does not support this package?

Chuong

 

 

"Rosen, Brian" wrote:

It would be a real package (would need approval). 
You would have

to put it in the event descriptor, but I think that is right -

you don't want the MGC getting events it didn't expect.

Brian

> -----Original Message-----

> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]

> Sent: Tuesday, May 15, 2001 9:13 AM

> To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Kevin Boyle'; 'Dan Elbert'

> Cc: megaco@fore.com; 'Chuong Nguyen'

> Subject: RE: Polls of MGC (was RE: Implementers' Guide Update Editor's

> last Ca ll - MGC failure)

>

>

> Hi All,

> If this event is defined in a new package, does the MGC needs

> to send this

> event in the event descriptor...or is this an exception of

> the normal event

> detection behavior?

> Regards

> Madhubabu

>

> -----Original Message-----

> From: owner-megaco@pit.comms.marconi.com

> [mailto:owner-megaco@pit.comms.marconi.com]On
Behalf Of Rosen, Brian

> Sent: Tuesday, May 15, 2001 7:57 AM

> To: 'Tom-PT Taylor'; Kevin Boyle; Dan Elbert

> Cc: megaco@fore.com; 'Chuong Nguyen'

> Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's

> last Ca ll - MGC failure)

>

>

> If you don't want to create the noop method, we can go

> back to a package.

>

>

>    PackageID: nop (0x00xx)

>    Version: 1

>    Extends: None

>

>    Description: No op event.  Can be used for
testing or MG

> poll of MGC.

>

> Properties

>

>    None

>

> Events

>

>    noop

>    -----

>    EventID:     noop (0x0001)

>

>    No op event

>

>    Events Descriptor Parameters:

>

>         Interval

>         -------------

>         ParameterID: delay
(0x0001)

>

>         Description: delay
in milliseconds to generate event.

>            
if not specified, MG may choose any value. 0 implies

>               
immediate response.

>         Possible Values:
INTEGER

>

> Brian

>

> -----Original Message-----

> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]

> Sent: Tuesday, May 15, 2001 3:59 AM

> To: Kevin Boyle; Dan Elbert

> Cc: megaco@fore.com; 'Chuong Nguyen'

> Subject: Polls of MGC (was RE: Implementors' Guide Update

> Editor's last Ca

> ll - MGC failure)

>

>

> Let's follow through the logic here.  A restart implies loss

> of state.  I

> don't care whether you're talking ROOT or a real termination.

>  It would be

> inconsistent to declare restart of the latter a no-op.

> I'd suggest the safest poll would be a NOTIFY with no events

> and a bogus

> requestID in it.  The MGC has to answer, even if only to

> return an error,

> but the NOTIFY doesn't change anything.

> > -----Original Message-----

> > From: Boyle, Kevin [NCRTP:3Z70:EXCH]

> > Sent: Monday, May 14, 2001 12:50 PM

> > To: Dan Elbert

> > Cc: megaco@fore.com; 'Chuong Nguyen'

> > Subject: Re: Implementors' Guide Update Editor's last Call -

> > MGC failure

> >

> >

> > Yes.  Root is a special case.  Restart on Root, if it
is already in

> > service, implies that the MG has gone out of service and

> returned, and

> > that anything that was happening previously is lost.  This

> > was discussed

> > on an earlier thread.

> >

> > Kevin

> >

> > Dan Elbert wrote:

> >

> > > Well I was just following the logic that a restart of a

> termination

> > > already in service is a noop. Is the root termination a

> > special case ?

> > > . The problem with poll vs restart is the same in any case.

> > >

> > > -----Original Message-----

> > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]

> > > Sent: Monday, May 14, 2001 12:22 PM

> > > To: megaco@fore.com

> > > Subject: Re: Implementors' Guide Update Editor's last Call -
MGC

> > > failure

> > >

> > >

> > > To me definitely NOT.

> > > How will MGC knows that it is a registration restarts vs a poll?

> > > Don't tell me that one can use Reason Code since Reason

> > Code has to be

> > > IANA registered

> > > before it can be widely used.

> > > But since anyone can register w/IANA at any time, it only

> means that

> > > it might not be supported by

> > > everyone.

> > >

> > > Chuong

> > >

> > > Dan Elbert wrote:

> > >

> > > Another thing : Can I then use a restart of the "root"

> > termination to

> > > poll the MGC ? It seems to me more clean that to just use any

> > > termination.

> > >

> > > -----Original Message-----

> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]

> > > Sent: Monday, May 14, 2001 12:00 PM

> > > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen'

> > > Subject: RE: Implementors' Guide Update Editor's last Call -
MGC

> > > failure

> > >

> > > I think that a restart of a termination that is already in service

> > > should be treated

> > >

> > > as a nop by an MGC.

> > >

> > > I have no objection to adding an explicit no-op method,

> but I don't

> > > think it is needed.

> > >

> > > Brian

> > > -----Original Message-----

> > >

> > > From: Dan Elbert [mailto:DElbert@radvision.com]

> > > Sent: Friday, May 11, 2001 5:57 PM

> > > To: 'megaco@fore.com'; 'Chuong Nguyen'

> > > Subject: RE: Implementors' Guide Update Editor's last Call -
MGC

> > > failure

> > > Using a fully specified terminationID can disrupt the

> > operation of the

> > > termination (for example if the termination is in a call).

> > >

> > > It's not clear what a "bogus" termination is, if the MGC

> receives a

> > > SVC from an MG termination it can assume that this

> > termination is real

> > > and start sending audits or commands.

> > >

> > > Yes, by poll I mean some type of heartbeat as the MG needs

> > to know if

> > > the MGC is alive.

> > >

> > > Brian Rosen suggested in the past to use SVC with Restart

> method for

> > > this purpose, I don't think that there was any mantion if

> > this should

> > > be done with id=root or other.

> > >

> > > Dan

> > > -----Original Message-----

> > >

> > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]

> > > Sent: Friday, May 11, 2001 5:38 PM

> > > To: megaco@fore.com

> > > Subject: Re: Implementors' Guide Update Editor's last Call -
MGC

> > > failure

> > >

> > > The intend was not to use ROOT but a fully specified

> > terminationID or

> > > even better a

> > > known invalid terminationID (A bogus terminationID that the sender

> > > knows is not valid and is

> > > used specifically for heartbeat purpose).  The idea is to
get some

> > > kind of responses.

> > >

> > > "poll" do you mean heartbeat like msg to from MG to MGC

> or something

> > > else here.

> > >

> > > Where did you see that Restart w/ROOT is used as a heartbeat/poll?

> > >

> > > Chuong

> > >

> > > Dan Elbert wrote:

> > > Hi

> > >

> > > After reviewing the issue of MGC failure ( when the MG is

> connected

> > > trough UDP ) I believe that there is no satisfactory way

> > for the MG to

> > > poll the MGC to see if the MGC is still alive. Using a

> ServiceChange

> > > with "Restart" method and termination id of "root" may

> cause the MGC

> > > to assume that the MG restarted and can affect the state of

> > a call in

> > > progress.

> > >

> > > I think that it would be good to add a ServiceChange

> method "noop" :

> > >

> > > Noop : Can be used by the MG (with unreliable protocols)

> to obtain a

> > > response from the MGC or detect a communication failure. When

> > > receiving this SVC the MGC should take no action other that reply.

> > >

> > > If this is not acceptable, then I think that some clarification
is

> > > needed as when a SVC with restart method should be

> considered "noop"

> > > by the MGC.

> > >

> > > Dan Elbert

> > >

> > > RADVISION

> > >

> > > --

> > >

> > >   Alcatel USA, Inc            
Internet:

> > Chuong.Nguyen@usa.alcatel.com

> > >

> > >   1000 Coit Road Plano, Texas 75075          
Phone:

> > (972) 519-4613

> > >

> > >   **** The opinions expressed are not those of Alcatel

> USA, Inc ****

> > >

> > > --

> > >

> > >   Alcatel USA, Inc            
Internet:

> > Chuong.Nguyen@usa.alcatel.com

> > >

> > >   1000 Coit Road Plano, Texas 75075          
Phone:

> > (972) 519-4613

> > >

> > >   **** The opinions expressed are not those of Alcatel

> USA, Inc ****

> > >

> >

> >

>



-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------0B022C3760FCA8494258366E--



From owner-megaco@fore.com  Tue May 15 10:01:07 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27618
	for ; Tue, 15 May 2001 10:01:06 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA14221;
	Tue, 15 May 2001 09:52:37 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA13637
	for megaco-list; Tue, 15 May 2001 09:50:24 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA13631
	for ; Tue, 15 May 2001 09:50:22 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 15 May 2001 09:49:54 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F600@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Chuong Nguyen'" , megaco@fore.com
Subject: RE: Polls of MGC (was RE: Implementers' Guide Update Editor's las
	t Ca ll  -  MGC failure)
Date: Tue, 15 May 2001 09:50:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0DD45.FA7753A0"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DD45.FA7753A0
Content-Type: text/plain;
	charset="ISO-8859-1"

This thread is about an MG poll of MGC, not the other way.  An MGC poll of
MG is
easy (audit of packages is an easy one).  Yes, both sides would have to
implement
the package for it to work.  That is why I like the original ServiceChange
idea.
The package is just an "easy out" if we don't do something with SC.

Brian
 

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Tuesday, May 15, 2001 9:24 AM
To: megaco@fore.com
Subject: Re: Polls of MGC (was RE: Implementers' Guide Update Editor's last
Ca ll - MGC failure)


  

Notify goes from MG to MGC. 
MGC does not send Notify. 


So how does MGC poll the MG? 
If we are making the assumption that by MGC requesting an event from MG, we 
are saying that MGC is sort of polling MG too. 


But what if MG does not support this package? 


Chuong 
  
  


"Rosen, Brian" wrote: 


It would be a real package (would need approval).  You would have 
to put it in the event descriptor, but I think that is right - 
you don't want the MGC getting events it didn't expect. 

Brian 


> -----Original Message----- 
> From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com
 ] 
> Sent: Tuesday, May 15, 2001 9:13 AM 
> To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Kevin Boyle'; 'Dan Elbert' 
> Cc: megaco@fore.com; 'Chuong Nguyen' 
> Subject: RE: Polls of MGC (was RE: Implementers' Guide Update Editor's 
> last Ca ll - MGC failure) 
> 
> 
> Hi All, 
> If this event is defined in a new package, does the MGC needs 
> to send this 
> event in the event descriptor...or is this an exception of 
> the normal event 
> detection behavior? 
> Regards 
> Madhubabu 
> 
> -----Original Message----- 
> From: owner-megaco@pit.comms.marconi.com 
> [ mailto:owner-megaco@pit.comms.marconi.com
 ]On Behalf Of Rosen, Brian 
> Sent: Tuesday, May 15, 2001 7:57 AM 
> To: 'Tom-PT Taylor'; Kevin Boyle; Dan Elbert 
> Cc: megaco@fore.com; 'Chuong Nguyen' 
> Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's 
> last Ca ll - MGC failure) 
> 
> 
> If you don't want to create the noop method, we can go 
> back to a package. 
> 
> 
>    PackageID: nop (0x00xx) 
>    Version: 1 
>    Extends: None 
> 
>    Description: No op event.  Can be used for testing or MG 
> poll of MGC. 
> 
> Properties 
> 
>    None 
> 
> Events 
> 
>    noop 
>    ----- 
>    EventID:     noop (0x0001) 
> 
>    No op event 
> 
>    Events Descriptor Parameters: 
> 
>         Interval 
>         ------------- 
>         ParameterID: delay (0x0001) 
> 
>         Description: delay in milliseconds to generate event. 
>             if not specified, MG may choose any value. 0 implies 
>                immediate response. 
>         Possible Values: INTEGER 
> 
> Brian 
> 
> -----Original Message----- 
> From: Tom-PT Taylor [ mailto:taylor@nortelnetworks.com
 ] 
> Sent: Tuesday, May 15, 2001 3:59 AM 
> To: Kevin Boyle; Dan Elbert 
> Cc: megaco@fore.com; 'Chuong Nguyen' 
> Subject: Polls of MGC (was RE: Implementors' Guide Update 
> Editor's last Ca 
> ll - MGC failure) 
> 
> 
> Let's follow through the logic here.  A restart implies loss 
> of state.  I 
> don't care whether you're talking ROOT or a real termination. 
>  It would be 
> inconsistent to declare restart of the latter a no-op. 
> I'd suggest the safest poll would be a NOTIFY with no events 
> and a bogus 
> requestID in it.  The MGC has to answer, even if only to 
> return an error, 
> but the NOTIFY doesn't change anything. 
> > -----Original Message----- 
> > From: Boyle, Kevin [NCRTP:3Z70:EXCH] 
> > Sent: Monday, May 14, 2001 12:50 PM 
> > To: Dan Elbert 
> > Cc: megaco@fore.com; 'Chuong Nguyen' 
> > Subject: Re: Implementors' Guide Update Editor's last Call - 
> > MGC failure 
> > 
> > 
> > Yes.  Root is a special case.  Restart on Root, if it is already in 
> > service, implies that the MG has gone out of service and 
> returned, and 
> > that anything that was happening previously is lost.  This 
> > was discussed 
> > on an earlier thread. 
> > 
> > Kevin 
> > 
> > Dan Elbert wrote: 
> > 
> > > Well I was just following the logic that a restart of a 
> termination 
> > > already in service is a noop. Is the root termination a 
> > special case ? 
> > > . The problem with poll vs restart is the same in any case. 
> > > 
> > > -----Original Message----- 
> > > From: Chuong Nguyen [ mailto:Chuong.Nguyen@usa.alcatel.com
 ] 
> > > Sent: Monday, May 14, 2001 12:22 PM 
> > > To: megaco@fore.com 
> > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC 
> > > failure 
> > > 
> > > 
> > > To me definitely NOT. 
> > > How will MGC knows that it is a registration restarts vs a poll? 
> > > Don't tell me that one can use Reason Code since Reason 
> > Code has to be 
> > > IANA registered 
> > > before it can be widely used. 
> > > But since anyone can register w/IANA at any time, it only 
> means that 
> > > it might not be supported by 
> > > everyone. 
> > > 
> > > Chuong 
> > > 
> > > Dan Elbert wrote: 
> > > 
> > > Another thing : Can I then use a restart of the "root" 
> > termination to 
> > > poll the MGC ? It seems to me more clean that to just use any 
> > > termination. 
> > > 
> > > -----Original Message----- 
> > > From: Rosen, Brian [ mailto:Brian.Rosen@marconi.com
 ] 
> > > Sent: Monday, May 14, 2001 12:00 PM 
> > > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen' 
> > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC 
> > > failure 
> > > 
> > > I think that a restart of a termination that is already in service 
> > > should be treated 
> > > 
> > > as a nop by an MGC. 
> > > 
> > > I have no objection to adding an explicit no-op method, 
> but I don't 
> > > think it is needed. 
> > > 
> > > Brian 
> > > -----Original Message----- 
> > > 
> > > From: Dan Elbert [ mailto:DElbert@radvision.com
 ] 
> > > Sent: Friday, May 11, 2001 5:57 PM 
> > > To: 'megaco@fore.com'; 'Chuong Nguyen' 
> > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC 
> > > failure 
> > > Using a fully specified terminationID can disrupt the 
> > operation of the 
> > > termination (for example if the termination is in a call). 
> > > 
> > > It's not clear what a "bogus" termination is, if the MGC 
> receives a 
> > > SVC from an MG termination it can assume that this 
> > termination is real 
> > > and start sending audits or commands. 
> > > 
> > > Yes, by poll I mean some type of heartbeat as the MG needs 
> > to know if 
> > > the MGC is alive. 
> > > 
> > > Brian Rosen suggested in the past to use SVC with Restart 
> method for 
> > > this purpose, I don't think that there was any mantion if 
> > this should 
> > > be done with id=root or other. 
> > > 
> > > Dan 
> > > -----Original Message----- 
> > > 
> > > From: Chuong Nguyen [ mailto:Chuong.Nguyen@usa.alcatel.com
 ] 
> > > Sent: Friday, May 11, 2001 5:38 PM 
> > > To: megaco@fore.com 
> > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC 
> > > failure 
> > > 
> > > The intend was not to use ROOT but a fully specified 
> > terminationID or 
> > > even better a 
> > > known invalid terminationID (A bogus terminationID that the sender 
> > > knows is not valid and is 
> > > used specifically for heartbeat purpose).  The idea is to get some 
> > > kind of responses. 
> > > 
> > > "poll" do you mean heartbeat like msg to from MG to MGC 
> or something 
> > > else here. 
> > > 
> > > Where did you see that Restart w/ROOT is used as a heartbeat/poll? 
> > > 
> > > Chuong 
> > > 
> > > Dan Elbert wrote: 
> > > Hi 
> > > 
> > > After reviewing the issue of MGC failure ( when the MG is 
> connected 
> > > trough UDP ) I believe that there is no satisfactory way 
> > for the MG to 
> > > poll the MGC to see if the MGC is still alive. Using a 
> ServiceChange 
> > > with "Restart" method and termination id of "root" may 
> cause the MGC 
> > > to assume that the MG restarted and can affect the state of 
> > a call in 
> > > progress. 
> > > 
> > > I think that it would be good to add a ServiceChange 
> method "noop" : 
> > > 
> > > Noop : Can be used by the MG (with unreliable protocols) 
> to obtain a 
> > > response from the MGC or detect a communication failure. When 
> > > receiving this SVC the MGC should take no action other that reply. 
> > > 
> > > If this is not acceptable, then I think that some clarification is 
> > > needed as when a SVC with restart method should be 
> considered "noop" 
> > > by the MGC. 
> > > 
> > > Dan Elbert 
> > > 
> > > RADVISION 
> > > 
> > > -- 
> > > 
> > >   Alcatel USA, Inc             Internet: 
> > Chuong.Nguyen@usa.alcatel.com 
> > > 
> > >   1000 Coit Road Plano, Texas 75075           Phone: 
> > (972) 519-4613 
> > > 
> > >   **** The opinions expressed are not those of Alcatel 
> USA, Inc **** 
> > > 
> > > -- 
> > > 
> > >   Alcatel USA, Inc             Internet: 
> > Chuong.Nguyen@usa.alcatel.com 
> > > 
> > >   1000 Coit Road Plano, Texas 75075           Phone: 
> > (972) 519-4613 
> > > 
> > >   **** The opinions expressed are not those of Alcatel 
> USA, Inc **** 
> > > 
> > 
> > 
>

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


------_=_NextPart_001_01C0DD45.FA7753A0
Content-Type: text/html;
	charset="ISO-8859-1"









This thread is about an MG poll of MGC, not 
the other way.  An MGC poll of MG is


easy (audit of packages is an easy 
one).  Yes, both sides would have to implement


the package for it to work.  That is 
why I like the original ServiceChange idea.
The package is just an "easy out" 
if we don't do something with SC.

Brian


 



  
-----Original Message-----
From: Chuong Nguyen 
  [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Tuesday, May 15, 2001 
  9:24 AM
To: megaco@fore.com
Subject: Re: Polls of MGC (was 
  RE: Implementers' Guide Update Editor's last Ca ll - MGC 
  failure)

  
  
Notify goes from MG to MGC. 
MGC does not send Notify. 
  
So how does MGC poll the MG? 
If we are making the assumption that by 
  MGC requesting an event from MG, we 
are saying that MGC is sort of polling 
  MG too. 
  
But what if MG does not support this package? 
  
Chuong 
  
  
  
"Rosen, Brian" wrote: 
  
It would be a real package (would need 
    approval).  You would have 
to put it in the event descriptor, but I 
    think that is right - 
you don't want the MGC getting events it didn't 
    expect. 
    
Brian 
    
> -----Original Message----- 
> From: Madhu Babu Brahmanapally 
    [mailto:madhubabu@kenetec.com] 
    
> Sent: Tuesday, May 15, 2001 9:13 AM 
> To: 'Rosen, Brian'; 
    'Tom-PT Taylor'; 'Kevin Boyle'; 'Dan Elbert' 
> Cc: megaco@fore.com; 
    'Chuong Nguyen' 
> Subject: RE: Polls of MGC (was RE: Implementers' 
    Guide Update Editor's 
> last Ca ll - MGC failure) 
> 
> 
    
> Hi All, 
> If this event is defined in a new package, does 
    the MGC needs 
> to send this 
> event in the event 
    descriptor...or is this an exception of 
> the normal event 
> 
    detection behavior? 
> Regards 
> Madhubabu 
> 
> 
    -----Original Message----- 
> From: owner-megaco@pit.comms.marconi.com 
    
> [mailto:owner-megaco@pit.comms.marconi.com]On 
    Behalf Of Rosen, Brian 
> Sent: Tuesday, May 15, 2001 7:57 AM 
> 
    To: 'Tom-PT Taylor'; Kevin Boyle; Dan Elbert 
> Cc: megaco@fore.com; 
    'Chuong Nguyen' 
> Subject: RE: Polls of MGC (was RE: Implementors' 
    Guide Update Editor's 
> last Ca ll - MGC failure) 
> 
> 
    
> If you don't want to create the noop method, we can go 
> 
    back to a package. 
> 
> 
>    PackageID: 
    nop (0x00xx) 
>    Version: 1 
    
>    Extends: None 
> 
>    
    Description: No op event.  Can be used for testing or MG 
> poll 
    of MGC. 
> 
> Properties 
> 
>    
    None 
> 
> Events 
> 
>    noop 
    
>    ----- 
>    
    EventID:     noop (0x0001) 
> 
    
>    No op event 
> 
>    
    Events Descriptor Parameters: 
> 
    
>         Interval 
    
>         ------------- 
    
>         ParameterID: delay 
    (0x0001) 
> 
>         
    Description: delay in milliseconds to generate event. 
    
>             
    if not specified, MG may choose any value. 0 implies 
    
>                
    immediate response. 
>         
    Possible Values: INTEGER 
> 
> Brian 
> 
> 
    -----Original Message----- 
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] 
    
> Sent: Tuesday, May 15, 2001 3:59 AM 
> To: Kevin Boyle; Dan 
    Elbert 
> Cc: megaco@fore.com; 'Chuong Nguyen' 
> Subject: Polls 
    of MGC (was RE: Implementors' Guide Update 
> Editor's last Ca 
    
> ll - MGC failure) 
> 
> 
> Let's follow through 
    the logic here.  A restart implies loss 
> of state.  I 
    
> don't care whether you're talking ROOT or a real termination. 
    
>  It would be 
> inconsistent to declare restart of the 
    latter a no-op. 
> I'd suggest the safest poll would be a NOTIFY with 
    no events 
> and a bogus 
> requestID in it.  The MGC has 
    to answer, even if only to 
> return an error, 
> but the NOTIFY 
    doesn't change anything. 
> > -----Original Message----- 
> 
    > From: Boyle, Kevin [NCRTP:3Z70:EXCH] 
> > Sent: Monday, May 
    14, 2001 12:50 PM 
> > To: Dan Elbert 
> > Cc: 
    megaco@fore.com; 'Chuong Nguyen' 
> > Subject: Re: Implementors' 
    Guide Update Editor's last Call - 
> > MGC failure 
> > 
    
> > 
> > Yes.  Root is a special case.  Restart 
    on Root, if it is already in 
> > service, implies that the MG has 
    gone out of service and 
> returned, and 
> > that anything 
    that was happening previously is lost.  This 
> > was 
    discussed 
> > on an earlier thread. 
> > 
> > 
    Kevin 
> > 
> > Dan Elbert wrote: 
> > 
> 
    > > Well I was just following the logic that a restart of a 
> 
    termination 
> > > already in service is a noop. Is the root 
    termination a 
> > special case ? 
> > > . The problem 
    with poll vs restart is the same in any case. 
> > > 
> 
    > > -----Original Message----- 
> > > From: Chuong Nguyen 
    [mailto:Chuong.Nguyen@usa.alcatel.com] 
    
> > > Sent: Monday, May 14, 2001 12:22 PM 
> > > 
    To: megaco@fore.com 
> > > Subject: Re: Implementors' Guide 
    Update Editor's last Call - MGC 
> > > failure 
> > 
    > 
> > > 
> > > To me definitely NOT. 
> 
    > > How will MGC knows that it is a registration restarts vs a poll? 
    
> > > Don't tell me that one can use Reason Code since Reason 
    
> > Code has to be 
> > > IANA registered 
> 
    > > before it can be widely used. 
> > > But since anyone 
    can register w/IANA at any time, it only 
> means that 
> > 
    > it might not be supported by 
> > > everyone. 
> > 
    > 
> > > Chuong 
> > > 
> > > Dan 
    Elbert wrote: 
> > > 
> > > Another thing : Can I 
    then use a restart of the "root" 
> > termination to 
> > 
    > poll the MGC ? It seems to me more clean that to just use any 
> 
    > > termination. 
> > > 
> > > -----Original 
    Message----- 
> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] 
    
> > > Sent: Monday, May 14, 2001 12:00 PM 
> > > 
    To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen' 
> > > 
    Subject: RE: Implementors' Guide Update Editor's last Call - MGC 
> 
    > > failure 
> > > 
> > > I think that a 
    restart of a termination that is already in service 
> > > 
    should be treated 
> > > 
> > > as a nop by an MGC. 
    
> > > 
> > > I have no objection to adding an 
    explicit no-op method, 
> but I don't 
> > > think it is 
    needed. 
> > > 
> > > Brian 
> > > 
    -----Original Message----- 
> > > 
> > > From: Dan 
    Elbert [mailto:DElbert@radvision.com] 
    
> > > Sent: Friday, May 11, 2001 5:57 PM 
> > > To: 
    'megaco@fore.com'; 'Chuong Nguyen' 
> > > Subject: RE: 
    Implementors' Guide Update Editor's last Call - MGC 
> > > 
    failure 
> > > Using a fully specified terminationID can disrupt 
    the 
> > operation of the 
> > > termination (for 
    example if the termination is in a call). 
> > > 
> > 
    > It's not clear what a "bogus" termination is, if the MGC 
> 
    receives a 
> > > SVC from an MG termination it can assume that 
    this 
> > termination is real 
> > > and start sending 
    audits or commands. 
> > > 
> > > Yes, by poll I 
    mean some type of heartbeat as the MG needs 
> > to know if 
    
> > > the MGC is alive. 
> > > 
> > > 
    Brian Rosen suggested in the past to use SVC with Restart 
> method 
    for 
> > > this purpose, I don't think that there was any 
    mantion if 
> > this should 
> > > be done with id=root 
    or other. 
> > > 
> > > Dan 
> > > 
    -----Original Message----- 
> > > 
> > > From: 
    Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com] 
    
> > > Sent: Friday, May 11, 2001 5:38 PM 
> > > To: 
    megaco@fore.com 
> > > Subject: Re: Implementors' Guide Update 
    Editor's last Call - MGC 
> > > failure 
> > > 
    
> > > The intend was not to use ROOT but a fully specified 
    
> > terminationID or 
> > > even better a 
> 
    > > known invalid terminationID (A bogus terminationID that the sender 
    
> > > knows is not valid and is 
> > > used 
    specifically for heartbeat purpose).  The idea is to get some 
> 
    > > kind of responses. 
> > > 
> > > "poll" do 
    you mean heartbeat like msg to from MG to MGC 
> or something 
> 
    > > else here. 
> > > 
> > > Where did you see 
    that Restart w/ROOT is used as a heartbeat/poll? 
> > > 
> 
    > > Chuong 
> > > 
> > > Dan Elbert wrote: 
    
> > > Hi 
> > > 
> > > After reviewing 
    the issue of MGC failure ( when the MG is 
> connected 
> > 
    > trough UDP ) I believe that there is no satisfactory way 
> > 
    for the MG to 
> > > poll the MGC to see if the MGC is still 
    alive. Using a 
> ServiceChange 
> > > with "Restart" 
    method and termination id of "root" may 
> cause the MGC 
> > 
    > to assume that the MG restarted and can affect the state of 
> 
    > a call in 
> > > progress. 
> > > 
> > 
    > I think that it would be good to add a ServiceChange 
> method 
    "noop" : 
> > > 
> > > Noop : Can be used by the MG 
    (with unreliable protocols) 
> to obtain a 
> > > response 
    from the MGC or detect a communication failure. When 
> > > 
    receiving this SVC the MGC should take no action other that reply. 
> 
    > > 
> > > If this is not acceptable, then I think that 
    some clarification is 
> > > needed as when a SVC with restart 
    method should be 
> considered "noop" 
> > > by the MGC. 
    
> > > 
> > > Dan Elbert 
> > > 
> 
    > > RADVISION 
> > > 
> > > -- 
> > 
    > 
> > >   Alcatel USA, 
    Inc             
    Internet: 
> > Chuong.Nguyen@usa.alcatel.com 
> > > 
    
> > >   1000 Coit Road Plano, Texas 
    75075           Phone: 
    
> > (972) 519-4613 
> > > 
> > 
    >   **** The opinions expressed are not those of Alcatel 
    
> USA, Inc **** 
> > > 
> > > -- 
> 
    > > 
> > >   Alcatel USA, 
    Inc             
    Internet: 
> > Chuong.Nguyen@usa.alcatel.com 
> > > 
    
> > >   1000 Coit Road Plano, Texas 
    75075           Phone: 
    
> > (972) 519-4613 
> > > 
> > 
    >   **** The opinions expressed are not those of Alcatel 
    
> USA, Inc **** 
> > > 
> > 
> > 
    
>
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  



------_=_NextPart_001_01C0DD45.FA7753A0--


From owner-megaco@fore.com  Tue May 15 10:44:50 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29017
	for ; Tue, 15 May 2001 10:44:50 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18191;
	Tue, 15 May 2001 10:32:43 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA24931
	for megaco-list; Tue, 15 May 2001 10:29:06 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24923
	for ; Tue, 15 May 2001 10:29:05 -0400 (EDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA17831
	for ; Tue, 15 May 2001 10:29:00 -0400 (EDT)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA13984
	for ; Tue, 15 May 2001 09:29:00 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4FESvT29514
	for ; Tue, 15 May 2001 09:28:57 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4FESD117563
	for ; Tue, 15 May 2001 09:28:13 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4FESDO19224
	for ; Tue, 15 May 2001 09:28:13 -0500 (CDT)
Message-ID: <3B013CFD.3215FCEF@usa.alcatel.com>
Date: Tue, 15 May 2001 09:28:13 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Polls of MGC (was RE: Implementers' Guide Update Editor's last Ca 
 ll  -  MGC failure)
References: <4FBEA8857476D311A03300204840E1CF01A6F600@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: multipart/alternative;
 boundary="------------B94AF9AFAB3F6E186E892C4A"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------B94AF9AFAB3F6E186E892C4A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


If the Standard is going to specify a poll mechanism, let's do it right
and specify it for
both MG and MGC.

A package that only satisfies MG and might not be supported by everyone
does not sound
like a very good specification.

An audit of packages can give varying messages size from MG which can be
a performance
issue to the MGC.

SC is definitely the way to go where a small known fixed size simple
Request/Reply is
all that is needed for polling purpose.

Is this strictly a UDP issue or is the intend that TCP implementation
would need the polling
too?

Chuong

"Rosen, Brian" wrote:

> This thread is about an MG poll of MGC, not the other way.  An MGC
> poll of MG iseasy (audit of packages is an easy one).  Yes, both sides
> would have to implementthe package for it to work.  That is why I like
> the original ServiceChange idea.
> The package is just an "easy out" if we don't do something with SC.
>
> Brian
>
>      -----Original Message-----
>      From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
>      Sent: Tuesday, May 15, 2001 9:24 AM
>      To: megaco@fore.com
>      Subject: Re: Polls of MGC (was RE: Implementers' Guide
>      Update Editor's last Ca ll - MGC failure)
>      Notify goes from MG to MGC.
>      MGC does not send Notify.
>
>      So how does MGC poll the MG?
>      If we are making the assumption that by MGC requesting an
>      event from MG, we
>      are saying that MGC is sort of polling MG too.
>
>      But what if MG does not support this package?
>
>      Chuong
>
>
>
>      "Rosen, Brian" wrote:
>
>     > It would be a real package (would need approval).  You
>     > would have
>     > to put it in the event descriptor, but I think that is
>     > right -
>     > you don't want the MGC getting events it didn't expect.
>     >
>     > Brian
>     >
>     > > -----Original Message-----
>     > > From: Madhu Babu Brahmanapally
>     > [mailto:madhubabu@kenetec.com]
>     > > Sent: Tuesday, May 15, 2001 9:13 AM
>     > > To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Kevin Boyle'; 'Dan
>     > Elbert'
>     > > Cc: megaco@fore.com; 'Chuong Nguyen'
>     > > Subject: RE: Polls of MGC (was RE: Implementers' Guide
>     > Update Editor's
>     > > last Ca ll - MGC failure)
>     > >
>     > >
>     > > Hi All,
>     > > If this event is defined in a new package, does the MGC
>     > needs
>     > > to send this
>     > > event in the event descriptor...or is this an exception
>     > of
>     > > the normal event
>     > > detection behavior?
>     > > Regards
>     > > Madhubabu
>     > >
>     > > -----Original Message-----
>     > > From: owner-megaco@pit.comms.marconi.com
>     > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of
>     > Rosen, Brian
>     > > Sent: Tuesday, May 15, 2001 7:57 AM
>     > > To: 'Tom-PT Taylor'; Kevin Boyle; Dan Elbert
>     > > Cc: megaco@fore.com; 'Chuong Nguyen'
>     > > Subject: RE: Polls of MGC (was RE: Implementors' Guide
>     > Update Editor's
>     > > last Ca ll - MGC failure)
>     > >
>     > >
>     > > If you don't want to create the noop method, we can go
>     > > back to a package.
>     > >
>     > >
>     > >    PackageID: nop (0x00xx)
>     > >    Version: 1
>     > >    Extends: None
>     > >
>     > >    Description: No op event.  Can be used for testing or
>     > MG
>     > > poll of MGC.
>     > >
>     > > Properties
>     > >
>     > >    None
>     > >
>     > > Events
>     > >
>     > >    noop
>     > >    -----
>     > >    EventID:     noop (0x0001)
>     > >
>     > >    No op event
>     > >
>     > >    Events Descriptor Parameters:
>     > >
>     > >         Interval
>     > >         -------------
>     > >         ParameterID: delay (0x0001)
>     > >
>     > >         Description: delay in milliseconds to generate
>     > event.
>     > >             if not specified, MG may choose any value. 0
>     > implies
>     > >                immediate response.
>     > >         Possible Values: INTEGER
>     > >
>     > > Brian
>     > >
>     > > -----Original Message-----
>     > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>     > > Sent: Tuesday, May 15, 2001 3:59 AM
>     > > To: Kevin Boyle; Dan Elbert
>     > > Cc: megaco@fore.com; 'Chuong Nguyen'
>     > > Subject: Polls of MGC (was RE: Implementors' Guide
>     > Update
>     > > Editor's last Ca
>     > > ll - MGC failure)
>     > >
>     > >
>     > > Let's follow through the logic here.  A restart implies
>     > loss
>     > > of state.  I
>     > > don't care whether you're talking ROOT or a real
>     > termination.
>     > >  It would be
>     > > inconsistent to declare restart of the latter a no-op.
>     > > I'd suggest the safest poll would be a NOTIFY with no
>     > events
>     > > and a bogus
>     > > requestID in it.  The MGC has to answer, even if only to
>     >
>     > > return an error,
>     > > but the NOTIFY doesn't change anything.
>     > > > -----Original Message-----
>     > > > From: Boyle, Kevin [NCRTP:3Z70:EXCH]
>     > > > Sent: Monday, May 14, 2001 12:50 PM
>     > > > To: Dan Elbert
>     > > > Cc: megaco@fore.com; 'Chuong Nguyen'
>     > > > Subject: Re: Implementors' Guide Update Editor's last
>     > Call -
>     > > > MGC failure
>     > > >
>     > > >
>     > > > Yes.  Root is a special case.  Restart on Root, if it
>     > is already in
>     > > > service, implies that the MG has gone out of service
>     > and
>     > > returned, and
>     > > > that anything that was happening previously is lost.
>     > This
>     > > > was discussed
>     > > > on an earlier thread.
>     > > >
>     > > > Kevin
>     > > >
>     > > > Dan Elbert wrote:
>     > > >
>     > > > > Well I was just following the logic that a restart
>     > of a
>     > > termination
>     > > > > already in service is a noop. Is the root
>     > termination a
>     > > > special case ?
>     > > > > . The problem with poll vs restart is the same in
>     > any case.
>     > > > >
>     > > > > -----Original Message-----
>     > > > > From: Chuong Nguyen
>     > [mailto:Chuong.Nguyen@usa.alcatel.com]
>     > > > > Sent: Monday, May 14, 2001 12:22 PM
>     > > > > To: megaco@fore.com
>     > > > > Subject: Re: Implementors' Guide Update Editor's
>     > last Call - MGC
>     > > > > failure
>     > > > >
>     > > > >
>     > > > > To me definitely NOT.
>     > > > > How will MGC knows that it is a registration
>     > restarts vs a poll?
>     > > > > Don't tell me that one can use Reason Code since
>     > Reason
>     > > > Code has to be
>     > > > > IANA registered
>     > > > > before it can be widely used.
>     > > > > But since anyone can register w/IANA at any time, it
>     > only
>     > > means that
>     > > > > it might not be supported by
>     > > > > everyone.
>     > > > >
>     > > > > Chuong
>     > > > >
>     > > > > Dan Elbert wrote:
>     > > > >
>     > > > > Another thing : Can I then use a restart of the
>     > "root"
>     > > > termination to
>     > > > > poll the MGC ? It seems to me more clean that to
>     > just use any
>     > > > > termination.
>     > > > >
>     > > > > -----Original Message-----
>     > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
>     > > > > Sent: Monday, May 14, 2001 12:00 PM
>     > > > > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen'
>     >
>     > > > > Subject: RE: Implementors' Guide Update Editor's
>     > last Call - MGC
>     > > > > failure
>     > > > >
>     > > > > I think that a restart of a termination that is
>     > already in service
>     > > > > should be treated
>     > > > >
>     > > > > as a nop by an MGC.
>     > > > >
>     > > > > I have no objection to adding an explicit no-op
>     > method,
>     > > but I don't
>     > > > > think it is needed.
>     > > > >
>     > > > > Brian
>     > > > > -----Original Message-----
>     > > > >
>     > > > > From: Dan Elbert [mailto:DElbert@radvision.com]
>     > > > > Sent: Friday, May 11, 2001 5:57 PM
>     > > > > To: 'megaco@fore.com'; 'Chuong Nguyen'
>     > > > > Subject: RE: Implementors' Guide Update Editor's
>     > last Call - MGC
>     > > > > failure
>     > > > > Using a fully specified terminationID can disrupt
>     > the
>     > > > operation of the
>     > > > > termination (for example if the termination is in a
>     > call).
>     > > > >
>     > > > > It's not clear what a "bogus" termination is, if the
>     > MGC
>     > > receives a
>     > > > > SVC from an MG termination it can assume that this
>     > > > termination is real
>     > > > > and start sending audits or commands.
>     > > > >
>     > > > > Yes, by poll I mean some type of heartbeat as the MG
>     > needs
>     > > > to know if
>     > > > > the MGC is alive.
>     > > > >
>     > > > > Brian Rosen suggested in the past to use SVC with
>     > Restart
>     > > method for
>     > > > > this purpose, I don't think that there was any
>     > mantion if
>     > > > this should
>     > > > > be done with id=root or other.
>     > > > >
>     > > > > Dan
>     > > > > -----Original Message-----
>     > > > >
>     > > > > From: Chuong Nguyen
>     > [mailto:Chuong.Nguyen@usa.alcatel.com]
>     > > > > Sent: Friday, May 11, 2001 5:38 PM
>     > > > > To: megaco@fore.com
>     > > > > Subject: Re: Implementors' Guide Update Editor's
>     > last Call - MGC
>     > > > > failure
>     > > > >
>     > > > > The intend was not to use ROOT but a fully specified
>     >
>     > > > terminationID or
>     > > > > even better a
>     > > > > known invalid terminationID (A bogus terminationID
>     > that the sender
>     > > > > knows is not valid and is
>     > > > > used specifically for heartbeat purpose).  The idea
>     > is to get some
>     > > > > kind of responses.
>     > > > >
>     > > > > "poll" do you mean heartbeat like msg to from MG to
>     > MGC
>     > > or something
>     > > > > else here.
>     > > > >
>     > > > > Where did you see that Restart w/ROOT is used as a
>     > heartbeat/poll?
>     > > > >
>     > > > > Chuong
>     > > > >
>     > > > > Dan Elbert wrote:
>     > > > > Hi
>     > > > >
>     > > > > After reviewing the issue of MGC failure ( when the
>     > MG is
>     > > connected
>     > > > > trough UDP ) I believe that there is no satisfactory
>     > way
>     > > > for the MG to
>     > > > > poll the MGC to see if the MGC is still alive. Using
>     > a
>     > > ServiceChange
>     > > > > with "Restart" method and termination id of "root"
>     > may
>     > > cause the MGC
>     > > > > to assume that the MG restarted and can affect the
>     > state of
>     > > > a call in
>     > > > > progress.
>     > > > >
>     > > > > I think that it would be good to add a ServiceChange
>     >
>     > > method "noop" :
>     > > > >
>     > > > > Noop : Can be used by the MG (with unreliable
>     > protocols)
>     > > to obtain a
>     > > > > response from the MGC or detect a communication
>     > failure. When
>     > > > > receiving this SVC the MGC should take no action
>     > other that reply.
>     > > > >
>     > > > > If this is not acceptable, then I think that some
>     > clarification is
>     > > > > needed as when a SVC with restart method should be
>     > > considered "noop"
>     > > > > by the MGC.
>     > > > >
>     > > > > Dan Elbert
>     > > > >
>     > > > > RADVISION
>     > > > >
>     > > > > --
>     > > > >
>     > > > >   Alcatel USA, Inc             Internet:
>     > > > Chuong.Nguyen@usa.alcatel.com
>     > > > >
>     > > > >   1000 Coit Road Plano, Texas 75075           Phone:
>     >
>     > > > (972) 519-4613
>     > > > >
>     > > > >   **** The opinions expressed are not those of
>     > Alcatel
>     > > USA, Inc ****
>     > > > >
>     > > > > --
>     > > > >
>     > > > >   Alcatel USA, Inc             Internet:
>     > > > Chuong.Nguyen@usa.alcatel.com
>     > > > >
>     > > > >   1000 Coit Road Plano, Texas 75075           Phone:
>     >
>     > > > (972) 519-4613
>     > > > >
>     > > > >   **** The opinions expressed are not those of
>     > Alcatel
>     > > USA, Inc ****
>     > > > >
>     > > >
>     > > >
>     > >
>
>      --
>        Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>        1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>        **** The opinions expressed are not those of Alcatel USA, Inc ****
>
>
>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------B94AF9AFAB3F6E186E892C4A
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

If the Standard is going to specify a poll mechanism, let's do it right
and specify it for

both MG and MGC.

A package that only satisfies MG and might not be supported by everyone
does not sound

like a very good specification.

An audit of packages can give varying messages size from MG which can
be a performance

issue to the MGC.

SC is definitely the way to go where a small known fixed size simple
Request/Reply is

all that is needed for polling purpose.

Is this strictly a UDP issue or is the intend that TCP implementation
would need the polling

too?

Chuong

"Rosen, Brian" wrote:

This thread is about
an MG poll of MGC, not the other way.  An MGC poll of MG iseasy
(audit of packages is an easy one).  Yes, both sides would have to
implementthe package for it to work. 
That is why I like the original ServiceChange idea.

The package is just an "easy out" if we don't do something with SC.

Brian



-----Original
Message-----

From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]

Sent: Tuesday, May 15, 2001
9:24 AM

To: megaco@fore.com

Subject: Re: Polls of MGC
(was RE: Implementers' Guide Update Editor's last Ca ll - MGC failure)

Notify goes from MG to MGC.

MGC does not send Notify.

So how does MGC poll the MG?

If we are making the assumption that by MGC requesting an event from
MG, we

are saying that MGC is sort of polling MG too.

But what if MG does not support this package?

Chuong

 

 

"Rosen, Brian" wrote:

It would be a real package (would need approval). 
You would have

to put it in the event descriptor, but I think that is right -

you don't want the MGC getting events it didn't expect.

Brian

> -----Original Message-----

> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]

> Sent: Tuesday, May 15, 2001 9:13 AM

> To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Kevin Boyle'; 'Dan Elbert'

> Cc: megaco@fore.com; 'Chuong Nguyen'

> Subject: RE: Polls of MGC (was RE: Implementers' Guide Update Editor's

> last Ca ll - MGC failure)

>

>

> Hi All,

> If this event is defined in a new package, does the MGC needs

> to send this

> event in the event descriptor...or is this an exception of

> the normal event

> detection behavior?

> Regards

> Madhubabu

>

> -----Original Message-----

> From: owner-megaco@pit.comms.marconi.com

> [mailto:owner-megaco@pit.comms.marconi.com]On
Behalf Of Rosen, Brian

> Sent: Tuesday, May 15, 2001 7:57 AM

> To: 'Tom-PT Taylor'; Kevin Boyle; Dan Elbert

> Cc: megaco@fore.com; 'Chuong Nguyen'

> Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's

> last Ca ll - MGC failure)

>

>

> If you don't want to create the noop method, we can go

> back to a package.

>

>

>    PackageID: nop (0x00xx)

>    Version: 1

>    Extends: None

>

>    Description: No op event.  Can be used for
testing or MG

> poll of MGC.

>

> Properties

>

>    None

>

> Events

>

>    noop

>    -----

>    EventID:     noop (0x0001)

>

>    No op event

>

>    Events Descriptor Parameters:

>

>         Interval

>         -------------

>         ParameterID: delay
(0x0001)

>

>         Description: delay
in milliseconds to generate event.

>            
if not specified, MG may choose any value. 0 implies

>               
immediate response.

>         Possible Values:
INTEGER

>

> Brian

>

> -----Original Message-----

> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]

> Sent: Tuesday, May 15, 2001 3:59 AM

> To: Kevin Boyle; Dan Elbert

> Cc: megaco@fore.com; 'Chuong Nguyen'

> Subject: Polls of MGC (was RE: Implementors' Guide Update

> Editor's last Ca

> ll - MGC failure)

>

>

> Let's follow through the logic here.  A restart implies loss

> of state.  I

> don't care whether you're talking ROOT or a real termination.

>  It would be

> inconsistent to declare restart of the latter a no-op.

> I'd suggest the safest poll would be a NOTIFY with no events

> and a bogus

> requestID in it.  The MGC has to answer, even if only to

> return an error,

> but the NOTIFY doesn't change anything.

> > -----Original Message-----

> > From: Boyle, Kevin [NCRTP:3Z70:EXCH]

> > Sent: Monday, May 14, 2001 12:50 PM

> > To: Dan Elbert

> > Cc: megaco@fore.com; 'Chuong Nguyen'

> > Subject: Re: Implementors' Guide Update Editor's last Call -

> > MGC failure

> >

> >

> > Yes.  Root is a special case.  Restart on Root, if it
is already in

> > service, implies that the MG has gone out of service and

> returned, and

> > that anything that was happening previously is lost.  This

> > was discussed

> > on an earlier thread.

> >

> > Kevin

> >

> > Dan Elbert wrote:

> >

> > > Well I was just following the logic that a restart of a

> termination

> > > already in service is a noop. Is the root termination a

> > special case ?

> > > . The problem with poll vs restart is the same in any case.

> > >

> > > -----Original Message-----

> > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]

> > > Sent: Monday, May 14, 2001 12:22 PM

> > > To: megaco@fore.com

> > > Subject: Re: Implementors' Guide Update Editor's last Call -
MGC

> > > failure

> > >

> > >

> > > To me definitely NOT.

> > > How will MGC knows that it is a registration restarts vs a poll?

> > > Don't tell me that one can use Reason Code since Reason

> > Code has to be

> > > IANA registered

> > > before it can be widely used.

> > > But since anyone can register w/IANA at any time, it only

> means that

> > > it might not be supported by

> > > everyone.

> > >

> > > Chuong

> > >

> > > Dan Elbert wrote:

> > >

> > > Another thing : Can I then use a restart of the "root"

> > termination to

> > > poll the MGC ? It seems to me more clean that to just use any

> > > termination.

> > >

> > > -----Original Message-----

> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]

> > > Sent: Monday, May 14, 2001 12:00 PM

> > > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen'

> > > Subject: RE: Implementors' Guide Update Editor's last Call -
MGC

> > > failure

> > >

> > > I think that a restart of a termination that is already in service

> > > should be treated

> > >

> > > as a nop by an MGC.

> > >

> > > I have no objection to adding an explicit no-op method,

> but I don't

> > > think it is needed.

> > >

> > > Brian

> > > -----Original Message-----

> > >

> > > From: Dan Elbert [mailto:DElbert@radvision.com]

> > > Sent: Friday, May 11, 2001 5:57 PM

> > > To: 'megaco@fore.com'; 'Chuong Nguyen'

> > > Subject: RE: Implementors' Guide Update Editor's last Call -
MGC

> > > failure

> > > Using a fully specified terminationID can disrupt the

> > operation of the

> > > termination (for example if the termination is in a call).

> > >

> > > It's not clear what a "bogus" termination is, if the MGC

> receives a

> > > SVC from an MG termination it can assume that this

> > termination is real

> > > and start sending audits or commands.

> > >

> > > Yes, by poll I mean some type of heartbeat as the MG needs

> > to know if

> > > the MGC is alive.

> > >

> > > Brian Rosen suggested in the past to use SVC with Restart

> method for

> > > this purpose, I don't think that there was any mantion if

> > this should

> > > be done with id=root or other.

> > >

> > > Dan

> > > -----Original Message-----

> > >

> > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]

> > > Sent: Friday, May 11, 2001 5:38 PM

> > > To: megaco@fore.com

> > > Subject: Re: Implementors' Guide Update Editor's last Call -
MGC

> > > failure

> > >

> > > The intend was not to use ROOT but a fully specified

> > terminationID or

> > > even better a

> > > known invalid terminationID (A bogus terminationID that the sender

> > > knows is not valid and is

> > > used specifically for heartbeat purpose).  The idea is to
get some

> > > kind of responses.

> > >

> > > "poll" do you mean heartbeat like msg to from MG to MGC

> or something

> > > else here.

> > >

> > > Where did you see that Restart w/ROOT is used as a heartbeat/poll?

> > >

> > > Chuong

> > >

> > > Dan Elbert wrote:

> > > Hi

> > >

> > > After reviewing the issue of MGC failure ( when the MG is

> connected

> > > trough UDP ) I believe that there is no satisfactory way

> > for the MG to

> > > poll the MGC to see if the MGC is still alive. Using a

> ServiceChange

> > > with "Restart" method and termination id of "root" may

> cause the MGC

> > > to assume that the MG restarted and can affect the state of

> > a call in

> > > progress.

> > >

> > > I think that it would be good to add a ServiceChange

> method "noop" :

> > >

> > > Noop : Can be used by the MG (with unreliable protocols)

> to obtain a

> > > response from the MGC or detect a communication failure. When

> > > receiving this SVC the MGC should take no action other that reply.

> > >

> > > If this is not acceptable, then I think that some clarification
is

> > > needed as when a SVC with restart method should be

> considered "noop"

> > > by the MGC.

> > >

> > > Dan Elbert

> > >

> > > RADVISION

> > >

> > > --

> > >

> > >   Alcatel USA, Inc            
Internet:

> > Chuong.Nguyen@usa.alcatel.com

> > >

> > >   1000 Coit Road Plano, Texas 75075          
Phone:

> > (972) 519-4613

> > >

> > >   **** The opinions expressed are not those of Alcatel

> USA, Inc ****

> > >

> > > --

> > >

> > >   Alcatel USA, Inc            
Internet:

> > Chuong.Nguyen@usa.alcatel.com

> > >

> > >   1000 Coit Road Plano, Texas 75075          
Phone:

> > (972) 519-4613

> > >

> > >   **** The opinions expressed are not those of Alcatel

> USA, Inc ****

> > >

> >

> >

>



-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 





-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------B94AF9AFAB3F6E186E892C4A--



From owner-megaco@fore.com  Tue May 15 11:00:35 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29470
	for ; Tue, 15 May 2001 11:00:34 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20453;
	Tue, 15 May 2001 10:53:48 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA01875
	for megaco-list; Tue, 15 May 2001 10:51:25 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA01863
	for ; Tue, 15 May 2001 10:51:23 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20168
	for ; Tue, 15 May 2001 10:51:19 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACO12580;
	Tue, 15 May 2001 10:51:18 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: 
Subject: RE: Polls of MGC (was RE: Implementers' Guide Update Editor's last Ca ll  -  MGC failure)
Date: Tue, 15 May 2001 10:55:35 -0400
Message-ID: <00fe01c0dd4f$19bcc390$c500a8c0@MBRAHMANAPALLY>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00FF_01C0DD2D.92AB2390"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <4FBEA8857476D311A03300204840E1CF01A6F600@whq-msgusr-02.pit.comms.marconi.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00FF_01C0DD2D.92AB2390
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi All,
Sorry for the basic question. Can anyone help me out to explain, why the MG
needs to send a Heartbeat message towards the MGC??? There can be two cases
when this heartbeat "may" be generated.
1) When calls are going on.
2) When there are no active calls.

In case 1) The messages exchanged itself servers the purpose.
In case 2) Since there are no messages that are exchanged this may be the
time when the MG needs to send a heartbeat. But if lets say this "noop"
event is generated from MG(assuming MGC already requested this in events
descriptor), if the MGC is not active it is anyhow not going to generate
Notify Response. The same thing will happen when any other notify is sent
from MG to MGC, in all the cases the MG will be aware that the MGC is not
active (if there is no response from MGC). I'm not clear how defining
another event will help the MG. Again the protocol should say how often
these heartbeats needs to be generated from MG to MGC, etc.

Regards
Madhubabu
  -----Original Message-----
  From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
  Sent: Tuesday, May 15, 2001 9:50 AM
  To: 'Chuong Nguyen'; megaco@fore.com
  Subject: RE: Polls of MGC (was RE: Implementers' Guide Update Editor's
last Ca ll - MGC failure)


  This thread is about an MG poll of MGC, not the other way.  An MGC poll of
MG is
  easy (audit of packages is an easy one).  Yes, both sides would have to
implement
  the package for it to work.  That is why I like the original ServiceChange
idea.
  The package is just an "easy out" if we don't do something with SC.

  Brian

    -----Original Message-----
    From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
    Sent: Tuesday, May 15, 2001 9:24 AM
    To: megaco@fore.com
    Subject: Re: Polls of MGC (was RE: Implementers' Guide Update Editor's
last Ca ll - MGC failure)



    Notify goes from MG to MGC.
    MGC does not send Notify.

    So how does MGC poll the MG?
    If we are making the assumption that by MGC requesting an event from MG,
we
    are saying that MGC is sort of polling MG too.

    But what if MG does not support this package?

    Chuong



    "Rosen, Brian" wrote:

      It would be a real package (would need approval).  You would have
      to put it in the event descriptor, but I think that is right -
      you don't want the MGC getting events it didn't expect.
      Brian

      > -----Original Message-----
      > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
      > Sent: Tuesday, May 15, 2001 9:13 AM
      > To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Kevin Boyle'; 'Dan Elbert'
      > Cc: megaco@fore.com; 'Chuong Nguyen'
      > Subject: RE: Polls of MGC (was RE: Implementers' Guide Update
Editor's
      > last Ca ll - MGC failure)
      >
      >
      > Hi All,
      > If this event is defined in a new package, does the MGC needs
      > to send this
      > event in the event descriptor...or is this an exception of
      > the normal event
      > detection behavior?
      > Regards
      > Madhubabu
      >
      > -----Original Message-----
      > From: owner-megaco@pit.comms.marconi.com
      > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
      > Sent: Tuesday, May 15, 2001 7:57 AM
      > To: 'Tom-PT Taylor'; Kevin Boyle; Dan Elbert
      > Cc: megaco@fore.com; 'Chuong Nguyen'
      > Subject: RE: Polls of MGC (was RE: Implementors' Guide Update
Editor's
      > last Ca ll - MGC failure)
      >
      >
      > If you don't want to create the noop method, we can go
      > back to a package.
      >
      >
      >    PackageID: nop (0x00xx)
      >    Version: 1
      >    Extends: None
      >
      >    Description: No op event.  Can be used for testing or MG
      > poll of MGC.
      >
      > Properties
      >
      >    None
      >
      > Events
      >
      >    noop
      >    -----
      >    EventID:     noop (0x0001)
      >
      >    No op event
      >
      >    Events Descriptor Parameters:
      >
      >         Interval
      >         -------------
      >         ParameterID: delay (0x0001)
      >
      >         Description: delay in milliseconds to generate event.
      >             if not specified, MG may choose any value. 0 implies
      >                immediate response.
      >         Possible Values: INTEGER
      >
      > Brian
      >
      > -----Original Message-----
      > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
      > Sent: Tuesday, May 15, 2001 3:59 AM
      > To: Kevin Boyle; Dan Elbert
      > Cc: megaco@fore.com; 'Chuong Nguyen'
      > Subject: Polls of MGC (was RE: Implementors' Guide Update
      > Editor's last Ca
      > ll - MGC failure)
      >
      >
      > Let's follow through the logic here.  A restart implies loss
      > of state.  I
      > don't care whether you're talking ROOT or a real termination.
      >  It would be
      > inconsistent to declare restart of the latter a no-op.
      > I'd suggest the safest poll would be a NOTIFY with no events
      > and a bogus
      > requestID in it.  The MGC has to answer, even if only to
      > return an error,
      > but the NOTIFY doesn't change anything.
      > > -----Original Message-----
      > > From: Boyle, Kevin [NCRTP:3Z70:EXCH]
      > > Sent: Monday, May 14, 2001 12:50 PM
      > > To: Dan Elbert
      > > Cc: megaco@fore.com; 'Chuong Nguyen'
      > > Subject: Re: Implementors' Guide Update Editor's last Call -
      > > MGC failure
      > >
      > >
      > > Yes.  Root is a special case.  Restart on Root, if it is already
in
      > > service, implies that the MG has gone out of service and
      > returned, and
      > > that anything that was happening previously is lost.  This
      > > was discussed
      > > on an earlier thread.
      > >
      > > Kevin
      > >
      > > Dan Elbert wrote:
      > >
      > > > Well I was just following the logic that a restart of a
      > termination
      > > > already in service is a noop. Is the root termination a
      > > special case ?
      > > > . The problem with poll vs restart is the same in any case.
      > > >
      > > > -----Original Message-----
      > > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
      > > > Sent: Monday, May 14, 2001 12:22 PM
      > > > To: megaco@fore.com
      > > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
      > > > failure
      > > >
      > > >
      > > > To me definitely NOT.
      > > > How will MGC knows that it is a registration restarts vs a poll?
      > > > Don't tell me that one can use Reason Code since Reason
      > > Code has to be
      > > > IANA registered
      > > > before it can be widely used.
      > > > But since anyone can register w/IANA at any time, it only
      > means that
      > > > it might not be supported by
      > > > everyone.
      > > >
      > > > Chuong
      > > >
      > > > Dan Elbert wrote:
      > > >
      > > > Another thing : Can I then use a restart of the "root"
      > > termination to
      > > > poll the MGC ? It seems to me more clean that to just use any
      > > > termination.
      > > >
      > > > -----Original Message-----
      > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
      > > > Sent: Monday, May 14, 2001 12:00 PM
      > > > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen'
      > > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
      > > > failure
      > > >
      > > > I think that a restart of a termination that is already in
service
      > > > should be treated
      > > >
      > > > as a nop by an MGC.
      > > >
      > > > I have no objection to adding an explicit no-op method,
      > but I don't
      > > > think it is needed.
      > > >
      > > > Brian
      > > > -----Original Message-----
      > > >
      > > > From: Dan Elbert [mailto:DElbert@radvision.com]
      > > > Sent: Friday, May 11, 2001 5:57 PM
      > > > To: 'megaco@fore.com'; 'Chuong Nguyen'
      > > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
      > > > failure
      > > > Using a fully specified terminationID can disrupt the
      > > operation of the
      > > > termination (for example if the termination is in a call).
      > > >
      > > > It's not clear what a "bogus" termination is, if the MGC
      > receives a
      > > > SVC from an MG termination it can assume that this
      > > termination is real
      > > > and start sending audits or commands.
      > > >
      > > > Yes, by poll I mean some type of heartbeat as the MG needs
      > > to know if
      > > > the MGC is alive.
      > > >
      > > > Brian Rosen suggested in the past to use SVC with Restart
      > method for
      > > > this purpose, I don't think that there was any mantion if
      > > this should
      > > > be done with id=root or other.
      > > >
      > > > Dan
      > > > -----Original Message-----
      > > >
      > > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
      > > > Sent: Friday, May 11, 2001 5:38 PM
      > > > To: megaco@fore.com
      > > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
      > > > failure
      > > >
      > > > The intend was not to use ROOT but a fully specified
      > > terminationID or
      > > > even better a
      > > > known invalid terminationID (A bogus terminationID that the
sender
      > > > knows is not valid and is
      > > > used specifically for heartbeat purpose).  The idea is to get
some
      > > > kind of responses.
      > > >
      > > > "poll" do you mean heartbeat like msg to from MG to MGC
      > or something
      > > > else here.
      > > >
      > > > Where did you see that Restart w/ROOT is used as a
heartbeat/poll?
      > > >
      > > > Chuong
      > > >
      > > > Dan Elbert wrote:
      > > > Hi
      > > >
      > > > After reviewing the issue of MGC failure ( when the MG is
      > connected
      > > > trough UDP ) I believe that there is no satisfactory way
      > > for the MG to
      > > > poll the MGC to see if the MGC is still alive. Using a
      > ServiceChange
      > > > with "Restart" method and termination id of "root" may
      > cause the MGC
      > > > to assume that the MG restarted and can affect the state of
      > > a call in
      > > > progress.
      > > >
      > > > I think that it would be good to add a ServiceChange
      > method "noop" :
      > > >
      > > > Noop : Can be used by the MG (with unreliable protocols)
      > to obtain a
      > > > response from the MGC or detect a communication failure. When
      > > > receiving this SVC the MGC should take no action other that
reply.
      > > >
      > > > If this is not acceptable, then I think that some clarification
is
      > > > needed as when a SVC with restart method should be
      > considered "noop"
      > > > by the MGC.
      > > >
      > > > Dan Elbert
      > > >
      > > > RADVISION
      > > >
      > > > --
      > > >
      > > >   Alcatel USA, Inc             Internet:
      > > Chuong.Nguyen@usa.alcatel.com
      > > >
      > > >   1000 Coit Road Plano, Texas 75075           Phone:
      > > (972) 519-4613
      > > >
      > > >   **** The opinions expressed are not those of Alcatel
      > USA, Inc ****
      > > >
      > > > --
      > > >
      > > >   Alcatel USA, Inc             Internet:
      > > Chuong.Nguyen@usa.alcatel.com
      > > >
      > > >   1000 Coit Road Plano, Texas 75075           Phone:
      > > (972) 519-4613
      > > >
      > > >   **** The opinions expressed are not those of Alcatel
      > USA, Inc ****
      > > >
      > >
      > >
      >

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****


------=_NextPart_000_00FF_01C0DD2D.92AB2390
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi=20
All,


Sorry=20
for the basic question. Can anyone help me out to explain, why the MG =
needs to=20
send a Heartbeat message towards the MGC??? There can be two cases when =
this=20
heartbeat "may" be generated.


1)=20
When calls are going on.


2)=20
When there are no active calls.


 


In=20
case 1) The messages exchanged itself servers the =
purpose.


In=20
case 2) Since there are no messages that are exchanged this may be the =
time when=20
the MG needs to send a heartbeat. But if lets say this "noop" event is =
generated=20
from MG(assuming MGC already requested this in events descriptor), if =
the MGC is=20
not active it is anyhow not going to generate Notify Response. The same=20
thing will happen when any other notify is sent from MG to MGC, in =
all the=20
cases the MG will be aware that the MGC is not active (if there is no =
response=20
from MGC). I'm not clear how defining another event will help the MG. =
Again the=20
protocol should say how often these heartbeats needs to be generated =
from MG to=20
MGC, etc. 


 


Regards


Madhubabu



  
-----Original Message-----
From:=20
  owner-megaco@pit.comms.marconi.com=20
  [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen,=20
  Brian
Sent: Tuesday, May 15, 2001 9:50 AM
To: =
'Chuong=20
  Nguyen'; megaco@fore.com
Subject: RE: Polls of MGC (was RE:=20
  Implementers' Guide Update Editor's last Ca ll - MGC=20
  failure)


  
This thread is about an MG poll =
of MGC,=20
  not the other way.  An MGC poll of MG is

  
easy (audit of packages is an =
easy=20
  one).  Yes, both sides would have to implement

  
the package for it to =
work.  That is=20
  why I like the original ServiceChange idea.
The package is just an =
"easy=20
  out" if we don't do something with SC.

Brian

  
 

  
    
-----Original Message-----
From: Chuong Nguyen=20
    [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Tuesday, May =
15, 2001=20
    9:24 AM
To: megaco@fore.com
Subject: Re: Polls =
of MGC=20
    (was RE: Implementers' Guide Update Editor's last Ca ll - MGC=20
    failure)

 =20
    
Notify goes from MG to MGC. 
MGC does not send Notify.=20
    
So how does MGC poll the MG? 
If we are making the assumption =
that by=20
    MGC requesting an event from MG, we 
are saying that MGC is sort =
of=20
    polling MG too.=20
    
But what if MG does not support this package?=20
    
Chuong 
  
 =20
    
"Rosen, Brian" wrote:=20
    
It would be a real package (would need=20
      approval).  You would have 
to put it in the event =
descriptor, but=20
      I think that is right - 
you don't want the MGC getting events =
it=20
      didn't expect.=20
      
Brian=20
      
> -----Original Message----- 
> From: Madhu Babu =
Brahmanapally=20
      [mailto:madhubabu@kenetec.com]=20
      
> Sent: Tuesday, May 15, 2001 9:13 AM 
> To: 'Rosen, =
Brian';=20
      'Tom-PT Taylor'; 'Kevin Boyle'; 'Dan Elbert' 
> Cc: =
megaco@fore.com;=20
      'Chuong Nguyen' 
> Subject: RE: Polls of MGC (was RE: =
Implementers'=20
      Guide Update Editor's 
> last Ca ll - MGC failure) 
> =

>=20
      
> Hi All, 
> If this event is defined in a new =
package, does=20
      the MGC needs 
> to send this 
> event in the event=20
      descriptor...or is this an exception of 
> the normal event =

>=20
      detection behavior? 
> Regards 
> Madhubabu 
> =

>=20
      -----Original Message----- 
> From:=20
      owner-megaco@pit.comms.marconi.com 
> [mailto:owner-megaco@pi=
t.comms.marconi.com]On=20
      Behalf Of Rosen, Brian 
> Sent: Tuesday, May 15, 2001 7:57 =
AM=20
      
> To: 'Tom-PT Taylor'; Kevin Boyle; Dan Elbert 
> Cc: =

      megaco@fore.com; 'Chuong Nguyen' 
> Subject: RE: Polls of =
MGC (was=20
      RE: Implementors' Guide Update Editor's 
> last Ca ll - MGC =
failure)=20
      
> 
> 
> If you don't want to create the noop =
method, we=20
      can go 
> back to a package. 
> 
>=20
      
>    PackageID: nop (0x00xx)=20
      
>    Version: 1 
>    =
Extends:=20
      None 
> 
>    Description: No op =
event. =20
      Can be used for testing or MG 
> poll of MGC. 
> =

>=20
      Properties 
> 
>    None 
> =

>=20
      Events 
> 
>    noop =

>   =20
      ----- 
>    EventID:     =
noop=20
      (0x0001) 
> 
>    No op event 
>=20
      
>    Events Descriptor Parameters: 
>=20
      
>         Interval=20
      
>         =
-------------=20
      
>         =
ParameterID:=20
      delay (0x0001) 
>=20
      
>         =
Description:=20
      delay in milliseconds to generate event.=20
      =

>           =
; =20
      if not specified, MG may choose any value. 0 implies=20
      =

>           =
;    =20
      immediate response.=20
      
>         Possible =
Values:=20
      INTEGER 
> 
> Brian 
> 
> -----Original=20
      Message----- 
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.co=
m]=20
      
> Sent: Tuesday, May 15, 2001 3:59 AM 
> To: Kevin =
Boyle; Dan=20
      Elbert 
> Cc: megaco@fore.com; 'Chuong Nguyen' 
> =
Subject:=20
      Polls of MGC (was RE: Implementors' Guide Update 
> Editor's =
last Ca=20
      
> ll - MGC failure) 
> 
> 
> Let's follow =
through=20
      the logic here.  A restart implies loss 
> of =
state.  I=20
      
> don't care whether you're talking ROOT or a real =
termination.=20
      
>  It would be 
> inconsistent to declare =
restart of the=20
      latter a no-op. 
> I'd suggest the safest poll would be a =
NOTIFY=20
      with no events 
> and a bogus 
> requestID in =
it.  The=20
      MGC has to answer, even if only to 
> return an error, =

> but=20
      the NOTIFY doesn't change anything. 
> > -----Original=20
      Message----- 
> > From: Boyle, Kevin [NCRTP:3Z70:EXCH] =

>=20
      > Sent: Monday, May 14, 2001 12:50 PM 
> > To: Dan =
Elbert=20
      
> > Cc: megaco@fore.com; 'Chuong Nguyen' 
> > =
Subject:=20
      Re: Implementors' Guide Update Editor's last Call - 
> > =
MGC=20
      failure 
> > 
> > 
> > Yes.  Root =
is a=20
      special case.  Restart on Root, if it is already in 
> =
>=20
      service, implies that the MG has gone out of service and 
>=20
      returned, and 
> > that anything that was happening =
previously is=20
      lost.  This 
> > was discussed 
> > on an =
earlier=20
      thread. 
> > 
> > Kevin 
> > 
> =
> Dan=20
      Elbert wrote: 
> > 
> > > Well I was just =
following=20
      the logic that a restart of a 
> termination 
> > =
>=20
      already in service is a noop. Is the root termination a 
> =
>=20
      special case ? 
> > > . The problem with poll vs =
restart is=20
      the same in any case. 
> > > 
> > > =
-----Original=20
      Message----- 
> > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.al=
catel.com]=20
      
> > > Sent: Monday, May 14, 2001 12:22 PM 
> =
> >=20
      To: megaco@fore.com 
> > > Subject: Re: Implementors' =
Guide=20
      Update Editor's last Call - MGC 
> > > failure =

> >=20
      > 
> > > 
> > > To me definitely NOT. =

>=20
      > > How will MGC knows that it is a registration restarts vs =
a poll?=20
      
> > > Don't tell me that one can use Reason Code =
since Reason=20
      
> > Code has to be 
> > > IANA registered =

>=20
      > > before it can be widely used. 
> > > But =
since=20
      anyone can register w/IANA at any time, it only 
> means =
that=20
      
> > > it might not be supported by 
> > > =

      everyone. 
> > > 
> > > Chuong 
> =
> >=20
      
> > > Dan Elbert wrote: 
> > > 
> =
> >=20
      Another thing : Can I then use a restart of the "root" 
> =
>=20
      termination to 
> > > poll the MGC ? It seems to me =
more clean=20
      that to just use any 
> > > termination. 
> > =
>=20
      
> > > -----Original Message----- 
> > > =
From:=20
      Rosen, Brian [mailto:Brian.Rosen@marconi.com]=20
      
> > > Sent: Monday, May 14, 2001 12:00 PM 
> =
> >=20
      To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen' 
> > =
>=20
      Subject: RE: Implementors' Guide Update Editor's last Call - MGC =

>=20
      > > failure 
> > > 
> > > I think =
that a=20
      restart of a termination that is already in service 
> > =
>=20
      should be treated 
> > > 
> > > as a nop =
by an=20
      MGC. 
> > > 
> > > I have no objection to =
adding=20
      an explicit no-op method, 
> but I don't 
> > > =
think it=20
      is needed. 
> > > 
> > > Brian 
> =
> >=20
      -----Original Message----- 
> > > 
> > > =
From: Dan=20
      Elbert [mailto:DElbert@radvision.com]=20
      
> > > Sent: Friday, May 11, 2001 5:57 PM 
> =
> >=20
      To: 'megaco@fore.com'; 'Chuong Nguyen' 
> > > Subject: =
RE:=20
      Implementors' Guide Update Editor's last Call - MGC 
> > =
>=20
      failure 
> > > Using a fully specified terminationID =
can=20
      disrupt the 
> > operation of the 
> > > =
termination=20
      (for example if the termination is in a call). 
> > > =

>=20
      > > It's not clear what a "bogus" termination is, if the MGC =

      
> receives a 
> > > SVC from an MG termination =
it can=20
      assume that this 
> > termination is real 
> > =
> and=20
      start sending audits or commands. 
> > > 
> > =
>=20
      Yes, by poll I mean some type of heartbeat as the MG needs =

> >=20
      to know if 
> > > the MGC is alive. 
> > > =

      
> > > Brian Rosen suggested in the past to use SVC =
with=20
      Restart 
> method for 
> > > this purpose, I =
don't think=20
      that there was any mantion if 
> > this should 
> =
> >=20
      be done with id=3Droot or other. 
> > > 
> > =
> Dan=20
      
> > > -----Original Message----- 
> > > =

>=20
      > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.al=
catel.com]=20
      
> > > Sent: Friday, May 11, 2001 5:38 PM 
> =
> >=20
      To: megaco@fore.com 
> > > Subject: Re: Implementors' =
Guide=20
      Update Editor's last Call - MGC 
> > > failure =

> >=20
      > 
> > > The intend was not to use ROOT but a fully =

      specified 
> > terminationID or 
> > > even =
better a=20
      
> > > known invalid terminationID (A bogus =
terminationID that=20
      the sender 
> > > knows is not valid and is 
> =
> >=20
      used specifically for heartbeat purpose).  The idea is to get =
some=20
      
> > > kind of responses. 
> > > 
> =
>=20
      > "poll" do you mean heartbeat like msg to from MG to MGC =

> or=20
      something 
> > > else here. 
> > > =

> >=20
      > Where did you see that Restart w/ROOT is used as a =
heartbeat/poll?=20
      
> > > 
> > > Chuong 
> > > =

>=20
      > > Dan Elbert wrote: 
> > > Hi 
> > =
>=20
      
> > > After reviewing the issue of MGC failure ( when =
the MG=20
      is 
> connected 
> > > trough UDP ) I believe =
that there=20
      is no satisfactory way 
> > for the MG to 
> > =
> poll=20
      the MGC to see if the MGC is still alive. Using a 
> =
ServiceChange=20
      
> > > with "Restart" method and termination id of =
"root" may=20
      
> cause the MGC 
> > > to assume that the MG =
restarted=20
      and can affect the state of 
> > a call in 
> > =
>=20
      progress. 
> > > 
> > > I think that it =
would be=20
      good to add a ServiceChange 
> method "noop" : 
> > =
>=20
      
> > > Noop : Can be used by the MG (with unreliable=20
      protocols) 
> to obtain a 
> > > response from =
the MGC=20
      or detect a communication failure. When 
> > > =
receiving this=20
      SVC the MGC should take no action other that reply. 
> > =
>=20
      
> > > If this is not acceptable, then I think that =
some=20
      clarification is 
> > > needed as when a SVC with =
restart=20
      method should be 
> considered "noop" 
> > > by =
the MGC.=20
      
> > > 
> > > Dan Elbert 
> > =
>=20
      
> > > RADVISION 
> > > 
> > > =
--=20
      
> > > 
> > >   Alcatel USA,=20
      =
Inc           &nbs=
p;=20
      Internet: 
> > Chuong.Nguyen@usa.alcatel.com 
> =
> >=20
      
> > >   1000 Coit Road Plano, Texas=20
      75075           =
Phone:=20
      
> > (972) 519-4613 
> > > 
> >=20
      >   **** The opinions expressed are not those of =
Alcatel=20
      
> USA, Inc **** 
> > > 
> > > -- =

>=20
      > > 
> > >   Alcatel USA,=20
      =
Inc           &nbs=
p;=20
      Internet: 
> > Chuong.Nguyen@usa.alcatel.com 
> =
> >=20
      
> > >   1000 Coit Road Plano, Texas=20
      75075           =
Phone:=20
      
> > (972) 519-4613 
> > > 
> >=20
      >   **** The opinions expressed are not those of =
Alcatel=20
      
> USA, Inc **** 
> > > 
> > 
> =
>=20
      
>
-- 
  Alcatel USA, =
Inc           &nbs=
p; Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas =
75075           =
Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc =
****
 =20
  


------=_NextPart_000_00FF_01C0DD2D.92AB2390--



From owner-megaco@fore.com  Tue May 15 11:04:54 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29592
	for ; Tue, 15 May 2001 11:04:54 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20025;
	Tue, 15 May 2001 10:50:29 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA00983
	for megaco-list; Tue, 15 May 2001 10:48:09 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA00963
	for ; Tue, 15 May 2001 10:48:06 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19713
	for ; Tue, 15 May 2001 10:48:01 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Tue, 15 May 2001 09:49:14 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD949458110CB@RADVPOST>
From: Dan Elbert 
To: "'Chuong Nguyen'" , megaco@fore.com
Subject: RE: Polls of MGC (was RE: Implementers' Guide Update Editor's las
	t Ca  ll  -  MGC failure)
Date: Tue, 15 May 2001 09:49:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0DD4E.356AC070"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DD4E.356AC070
Content-Type: text/plain;
	charset="iso-8859-1"

This is only needed for UDP, in TCP you always know when the connection is
lost.
I don't think the MGC needs to poll, it can always detect the MG loss when
trying to do something. In any case if it detects that the MG is down there
is no much it can do. 
The MG in the other hand needs to know if it needs to reestablish the
connection to the MGC ( or try to connect a backup MGC).
I still think that SVC with method "noop" is the simplest solution , and
every MGC should support this either with a reply (if it implements the
method) or with an error (if it doesn't know it). The spec allows for the
use of "extension" SVC methods.
 
Dan Elbert
RADVISION
 
-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Tuesday, May 15, 2001 10:28 AM
To: megaco@fore.com
Subject: Re: Polls of MGC (was RE: Implementers' Guide Update Editor's last
Ca ll - MGC failure)
 
  
If the Standard is going to specify a poll mechanism, let's do it right and
specify it for 
both MG and MGC. 
A package that only satisfies MG and might not be supported by everyone does
not sound 
like a very good specification. 
An audit of packages can give varying messages size from MG which can be a
performance 
issue to the MGC. 
SC is definitely the way to go where a small known fixed size simple
Request/Reply is 
all that is needed for polling purpose. 
Is this strictly a UDP issue or is the intend that TCP implementation would
need the polling 
too? 
Chuong 
"Rosen, Brian" wrote: 
This thread is about an MG poll of MGC, not the other way.  An MGC poll of
MG iseasy (audit of packages is an easy one).  Yes, both sides would have to
implementthe package for it to work.  That is why I like the original
ServiceChange idea. 
The package is just an "easy out" if we don't do something with SC. 
Brian 
-----Original Message----- 
From: Chuong Nguyen [ mailto:Chuong.Nguyen@usa.alcatel.com
 ] 
Sent: Tuesday, May 15, 2001 9:24 AM 
To: megaco@fore.com 
Subject: Re: Polls of MGC (was RE: Implementers' Guide Update Editor's last
Ca ll - MGC failure)
Notify goes from MG to MGC. 
MGC does not send Notify. 
So how does MGC poll the MG? 
If we are making the assumption that by MGC requesting an event from MG, we 
are saying that MGC is sort of polling MG too. 
But what if MG does not support this package? 
Chuong 
  
  
"Rosen, Brian" wrote: 
It would be a real package (would need approval).  You would have 
to put it in the event descriptor, but I think that is right - 
you don't want the MGC getting events it didn't expect. 
Brian 
> -----Original Message----- 
> From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com
 ] 
> Sent: Tuesday, May 15, 2001 9:13 AM 
> To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Kevin Boyle'; 'Dan Elbert' 
> Cc: megaco@fore.com; 'Chuong Nguyen' 
> Subject: RE: Polls of MGC (was RE: Implementers' Guide Update Editor's 
> last Ca ll - MGC failure) 
> 
> 
> Hi All, 
> If this event is defined in a new package, does the MGC needs 
> to send this 
> event in the event descriptor...or is this an exception of 
> the normal event 
> detection behavior? 
> Regards 
> Madhubabu 
> 
> -----Original Message----- 
> From: owner-megaco@pit.comms.marconi.com 
> [ mailto:owner-megaco@pit.comms.marconi.com
 ]On Behalf Of Rosen, Brian 
> Sent: Tuesday, May 15, 2001 7:57 AM 
> To: 'Tom-PT Taylor'; Kevin Boyle; Dan Elbert 
> Cc: megaco@fore.com; 'Chuong Nguyen' 
> Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's 
> last Ca ll - MGC failure) 
> 
> 
> If you don't want to create the noop method, we can go 
> back to a package. 
> 
> 
>    PackageID: nop (0x00xx) 
>    Version: 1 
>    Extends: None 
> 
>    Description: No op event.  Can be used for testing or MG 
> poll of MGC. 
> 
> Properties 
> 
>    None 
> 
> Events 
> 
>    noop 
>    ----- 
>    EventID:     noop (0x0001) 
> 
>    No op event 
> 
>    Events Descriptor Parameters: 
> 
>         Interval 
>         ------------- 
>         ParameterID: delay (0x0001) 
> 
>         Description: delay in milliseconds to generate event. 
>             if not specified, MG may choose any value. 0 implies 
>                immediate response. 
>         Possible Values: INTEGER 
> 
> Brian 
> 
> -----Original Message----- 
> From: Tom-PT Taylor [ mailto:taylor@nortelnetworks.com
 ] 
> Sent: Tuesday, May 15, 2001 3:59 AM 
> To: Kevin Boyle; Dan Elbert 
> Cc: megaco@fore.com; 'Chuong Nguyen' 
> Subject: Polls of MGC (was RE: Implementors' Guide Update 
> Editor's last Ca 
> ll - MGC failure) 
> 
> 
> Let's follow through the logic here.  A restart implies loss 
> of state.  I 
> don't care whether you're talking ROOT or a real termination. 
>  It would be 
> inconsistent to declare restart of the latter a no-op. 
> I'd suggest the safest poll would be a NOTIFY with no events 
> and a bogus 
> requestID in it.  The MGC has to answer, even if only to 
> return an error, 
> but the NOTIFY doesn't change anything. 
> > -----Original Message----- 
> > From: Boyle, Kevin [NCRTP:3Z70:EXCH] 
> > Sent: Monday, May 14, 2001 12:50 PM 
> > To: Dan Elbert 
> > Cc: megaco@fore.com; 'Chuong Nguyen' 
> > Subject: Re: Implementors' Guide Update Editor's last Call - 
> > MGC failure 
> > 
> > 
> > Yes.  Root is a special case.  Restart on Root, if it is already in 
> > service, implies that the MG has gone out of service and 
> returned, and 
> > that anything that was happening previously is lost.  This 
> > was discussed 
> > on an earlier thread. 
> > 
> > Kevin 
> > 
> > Dan Elbert wrote: 
> > 
> > > Well I was just following the logic that a restart of a 
> termination 
> > > already in service is a noop. Is the root termination a 
> > special case ? 
> > > . The problem with poll vs restart is the same in any case. 
> > > 
> > > -----Original Message----- 
> > > From: Chuong Nguyen [ mailto:Chuong.Nguyen@usa.alcatel.com
 ] 
> > > Sent: Monday, May 14, 2001 12:22 PM 
> > > To: megaco@fore.com 
> > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC 
> > > failure 
> > > 
> > > 
> > > To me definitely NOT. 
> > > How will MGC knows that it is a registration restarts vs a poll? 
> > > Don't tell me that one can use Reason Code since Reason 
> > Code has to be 
> > > IANA registered 
> > > before it can be widely used. 
> > > But since anyone can register w/IANA at any time, it only 
> means that 
> > > it might not be supported by 
> > > everyone. 
> > > 
> > > Chuong 
> > > 
> > > Dan Elbert wrote: 
> > > 
> > > Another thing : Can I then use a restart of the "root" 
> > termination to 
> > > poll the MGC ? It seems to me more clean that to just use any 
> > > termination. 
> > > 
> > > -----Original Message----- 
> > > From: Rosen, Brian [ mailto:Brian.Rosen@marconi.com
 ] 
> > > Sent: Monday, May 14, 2001 12:00 PM 
> > > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen' 
> > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC 
> > > failure 
> > > 
> > > I think that a restart of a termination that is already in service 
> > > should be treated 
> > > 
> > > as a nop by an MGC. 
> > > 
> > > I have no objection to adding an explicit no-op method, 
> but I don't 
> > > think it is needed. 
> > > 
> > > Brian 
> > > -----Original Message----- 
> > > 
> > > From: Dan Elbert [ mailto:DElbert@radvision.com
 ] 
> > > Sent: Friday, May 11, 2001 5:57 PM 
> > > To: 'megaco@fore.com'; 'Chuong Nguyen' 
> > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC 
> > > failure 
> > > Using a fully specified terminationID can disrupt the 
> > operation of the 
> > > termination (for example if the termination is in a call). 
> > > 
> > > It's not clear what a "bogus" termination is, if the MGC 
> receives a 
> > > SVC from an MG termination it can assume that this 
> > termination is real 
> > > and start sending audits or commands. 
> > > 
> > > Yes, by poll I mean some type of heartbeat as the MG needs 
> > to know if 
> > > the MGC is alive. 
> > > 
> > > Brian Rosen suggested in the past to use SVC with Restart 
> method for 
> > > this purpose, I don't think that there was any mantion if 
> > this should 
> > > be done with id=root or other. 
> > > 
> > > Dan 
> > > -----Original Message----- 
> > > 
> > > From: Chuong Nguyen [ mailto:Chuong.Nguyen@usa.alcatel.com
 ] 
> > > Sent: Friday, May 11, 2001 5:38 PM 
> > > To: megaco@fore.com 
> > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC 
> > > failure 
> > > 
> > > The intend was not to use ROOT but a fully specified 
> > terminationID or 
> > > even better a 
> > > known invalid terminationID (A bogus terminationID that the sender 
> > > knows is not valid and is 
> > > used specifically for heartbeat purpose).  The idea is to get some 
> > > kind of responses. 
> > > 
> > > "poll" do you mean heartbeat like msg to from MG to MGC 
> or something 
> > > else here. 
> > > 
> > > Where did you see that Restart w/ROOT is used as a heartbeat/poll? 
> > > 
> > > Chuong 
> > > 
> > > Dan Elbert wrote: 
> > > Hi 
> > > 
> > > After reviewing the issue of MGC failure ( when the MG is 
> connected 
> > > trough UDP ) I believe that there is no satisfactory way 
> > for the MG to 
> > > poll the MGC to see if the MGC is still alive. Using a 
> ServiceChange 
> > > with "Restart" method and termination id of "root" may 
> cause the MGC 
> > > to assume that the MG restarted and can affect the state of 
> > a call in 
> > > progress. 
> > > 
> > > I think that it would be good to add a ServiceChange 
> method "noop" : 
> > > 
> > > Noop : Can be used by the MG (with unreliable protocols) 
> to obtain a 
> > > response from the MGC or detect a communication failure. When 
> > > receiving this SVC the MGC should take no action other that reply. 
> > > 
> > > If this is not acceptable, then I think that some clarification is 
> > > needed as when a SVC with restart method should be 
> considered "noop" 
> > > by the MGC. 
> > > 
> > > Dan Elbert 
> > > 
> > > RADVISION 
> > > 
> > > -- 
> > > 
> > >   Alcatel USA, Inc             Internet: 
> > Chuong.Nguyen@usa.alcatel.com 
> > > 
> > >   1000 Coit Road Plano, Texas 75075           Phone: 
> > (972) 519-4613 
> > > 
> > >   **** The opinions expressed are not those of Alcatel 
> USA, Inc **** 
> > > 
> > > -- 
> > > 
> > >   Alcatel USA, Inc             Internet: 
> > Chuong.Nguyen@usa.alcatel.com 
> > > 
> > >   1000 Coit Road Plano, Texas 75075           Phone: 
> > (972) 519-4613 
> > > 
> > >   **** The opinions expressed are not those of Alcatel 
> USA, Inc **** 
> > > 
> > 
> > 
>
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
 
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
 

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






















T=
his is
only needed for UDP, in TCP you always know when the connection is =
lost.



I=
 don’t
think the MGC needs to poll, it can always detect the MG loss when =
trying to do
something. In any case if it detects that the MG is down there is no =
much it
can do. 



T=
he MG in
the other hand needs to know if it needs to reestablish the connection =
to the
MGC ( or try to connect a backup =
MGC).



I=
 still
think that SVC with method “noop” is the simplest solution =
, and every MGC
should support this either with a reply (if it implements the method) =
or with
an error (if it doesn’t know it). The spec allows for the use of =
“extension”
SVC methods.



<=
![if =
!supportEmptyParas]> 
=



D=
an Elbert



R=
ADVISION



<=
![if =
!supportEmptyParas]> 
=



-----Original
Message-----

From: Chuong Nguyen
[mailto:Chuong.Nguyen@usa.alcatel.com]

Sent: Tuesday, May 15, =
2001 10:28
AM

To: megaco@fore.com

Subject: Re: Polls of =
MGC (was RE:
Implementers' Guide Update Editor's last Ca ll - MGC =
failure)



 



  

If the Standard is going to specify a poll mechanism, let's do it right =
and
specify it for 

both MG and MGC. 



A package that only satisfies MG =
and might
not be supported by everyone does not sound 

like a very good specification. =




An audit of packages can give =
varying
messages size from MG which can be a performance 

issue to the MGC. 



SC is definitely the way to go =
where a
small known fixed size simple Request/Reply is 

all that is needed for polling purpose. =




Is this strictly a =
UDP issue or is
the intend that TCP implementation would need the polling 

too? 



Chuong =




"Rosen, Brian" wrote: =
=




This thread is about an MG poll =
of MGC,
not the other way.  An MGC poll of MG iseasy (audit of packages is =
an easy
one).  Yes, both sides would have to implementthe package for it =
to
work.  That is why I like the original ServiceChange idea. 

The package is just an "easy out" if we don't do something =
with SC. =




Brian =







-----Original Message----- 

From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.a=
lcatel.com] 

Sent: Tuesday, May 15, 2001 9:24 AM 

To: megaco@fore.com 

Subject:<=
/font> Re: Polls of MGC (was RE: Implementers' Guide Update =
Editor's
last Ca ll - MGC failure)=




Notify
goes from MG to MGC. 

MGC does not send Notify. =




So
how does MGC poll the MG? 

If we are making the assumption that by MGC requesting an event from =
MG, we 

are saying that MGC is sort of polling MG too. =




But
what if MG does not support this package? =




Chuong


  

  



"Rosen,
Brian" wrote: 









It
would be a real package (would need approval).  You would have =


to put it in the event descriptor, but I think that is right - 

you don't want the MGC getting events it didn't expect. =
=




Brian
=




>
-----Original Message----- 

> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]


> Sent: Tuesday, May 15, 2001 9:13 AM 

> To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Kevin Boyle'; 'Dan Elbert' =


> Cc: megaco@fore.com; 'Chuong Nguyen' 

> Subject: RE: Polls of MGC (was RE: Implementers' Guide Update =
Editor's 

> last Ca ll - MGC failure) 

> 

> 

> Hi All, 

> If this event is defined in a new package, does the MGC needs 

> to send this 

> event in the event descriptor...or is this an exception of 

> the normal event 

> detection behavior? 

> Regards 

> Madhubabu 

> 

> -----Original Message----- 

> From: owner-megaco@pit.comms.marconi.com 

> [mailto:owner-megaco@p=
it.comms.marconi.com]On
Behalf Of Rosen, Brian 

> Sent: Tuesday, May 15, 2001 7:57 AM 

> To: 'Tom-PT Taylor'; Kevin Boyle; Dan Elbert 

> Cc: megaco@fore.com; 'Chuong Nguyen' 

> Subject: RE: Polls of MGC (was RE: Implementors' Guide Update =
Editor's 

> last Ca ll - MGC failure) 

> 

> 

> If you don't want to create the noop method, we can go 

> back to a package. 

> 

> 

>    PackageID: nop (0x00xx) 

>    Version: 1 

>    Extends: None 

> 

>    Description: No op event.  Can be used for =
testing
or MG 

> poll of MGC. 

> 

> Properties 

> 

>    None 

> 

> Events 

> 

>    noop 

>    ----- 

>    EventID:     noop (0x0001) =


> 

>    No op event 

> 

>    Events Descriptor Parameters: 

> 

>         Interval 

>         ------------- 

>         ParameterID: delay
(0x0001) 

> 

>         Description: delay =
in
milliseconds to generate event. 

>           &n=
bsp; if
not specified, MG may choose any value. 0 implies 

>           &n=
bsp;   
immediate response. 

>         Possible Values: =
INTEGER 

> 

> Brian 

> 

> -----Original Message----- 

> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c=
om]


> Sent: Tuesday, May 15, 2001 3:59 AM 

> To: Kevin Boyle; Dan Elbert 

> Cc: megaco@fore.com; 'Chuong Nguyen' 

> Subject: Polls of MGC (was RE: Implementors' Guide Update 

> Editor's last Ca 

> ll - MGC failure) 

> 

> 

> Let's follow through the logic here.  A restart implies loss =


> of state.  I 

> don't care whether you're talking ROOT or a real termination. 

>  It would be 

> inconsistent to declare restart of the latter a no-op. 

> I'd suggest the safest poll would be a NOTIFY with no events 

> and a bogus 

> requestID in it.  The MGC has to answer, even if only to 

> return an error, 

> but the NOTIFY doesn't change anything. 

> > -----Original Message----- 

> > From: Boyle, Kevin [NCRTP:3Z70:EXCH] 

> > Sent: Monday, May 14, 2001 12:50 PM 

> > To: Dan Elbert 

> > Cc: megaco@fore.com; 'Chuong Nguyen' 

> > Subject: Re: Implementors' Guide Update Editor's last Call - =


> > MGC failure 

> > 

> > 

> > Yes.  Root is a special case.  Restart on Root, if =
it is
already in 

> > service, implies that the MG has gone out of service and 

> returned, and 

> > that anything that was happening previously is lost.  =
This 

> > was discussed 

> > on an earlier thread. 

> > 

> > Kevin 

> > 

> > Dan Elbert wrote: 

> > 

> > > Well I was just following the logic that a restart of a =


> termination 

> > > already in service is a noop. Is the root termination a =


> > special case ? 

> > > . The problem with poll vs restart is the same in any =
case. 

> > > 

> > > -----Original Message----- 

> > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.a=
lcatel.com]


> > > Sent: Monday, May 14, 2001 12:22 PM 

> > > To: megaco@fore.com 

> > > Subject: Re: Implementors' Guide Update Editor's last =
Call - MGC


> > > failure 

> > > 

> > > 

> > > To me definitely NOT. 

> > > How will MGC knows that it is a registration restarts vs =
a poll?


> > > Don't tell me that one can use Reason Code since Reason =


> > Code has to be 

> > > IANA registered 

> > > before it can be widely used. 

> > > But since anyone can register w/IANA at any time, it =
only 

> means that 

> > > it might not be supported by 

> > > everyone. 

> > > 

> > > Chuong 

> > > 

> > > Dan Elbert wrote: 

> > > 

> > > Another thing : Can I then use a restart of the =
"root"


> > termination to 

> > > poll the MGC ? It seems to me more clean that to just =
use any 

> > > termination. 

> > > 

> > > -----Original Message----- 

> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]


> > > Sent: Monday, May 14, 2001 12:00 PM 

> > > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen' =


> > > Subject: RE: Implementors' Guide Update Editor's last =
Call - MGC


> > > failure 

> > > 

> > > I think that a restart of a termination that is already =
in
service 

> > > should be treated 

> > > 

> > > as a nop by an MGC. 

> > > 

> > > I have no objection to adding an explicit no-op method, =


> but I don't 

> > > think it is needed. 

> > > 

> > > Brian 

> > > -----Original Message----- 

> > > 

> > > From: Dan Elbert [mailto:DElbert@radvision.com]


> > > Sent: Friday, May 11, 2001 5:57 PM 

> > > To: 'megaco@fore.com'; 'Chuong Nguyen' 

> > > Subject: RE: Implementors' Guide Update Editor's last =
Call - MGC


> > > failure 

> > > Using a fully specified terminationID can disrupt the =


> > operation of the 

> > > termination (for example if the termination is in a =
call). 

> > > 

> > > It's not clear what a "bogus" termination is, =
if the
MGC 

> receives a 

> > > SVC from an MG termination it can assume that this 

> > termination is real 

> > > and start sending audits or commands. 

> > > 

> > > Yes, by poll I mean some type of heartbeat as the MG =
needs 

> > to know if 

> > > the MGC is alive. 

> > > 

> > > Brian Rosen suggested in the past to use SVC with =
Restart 

> method for 

> > > this purpose, I don't think that there was any mantion =
if 

> > this should 

> > > be done with id=3Droot or other. 

> > > 

> > > Dan 

> > > -----Original Message----- 

> > > 

> > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.a=
lcatel.com]


> > > Sent: Friday, May 11, 2001 5:38 PM 

> > > To: megaco@fore.com 

> > > Subject: Re: Implementors' Guide Update Editor's last =
Call - MGC


> > > failure 

> > > 

> > > The intend was not to use ROOT but a fully specified =


> > terminationID or 

> > > even better a 

> > > known invalid terminationID (A bogus terminationID that =
the
sender 

> > > knows is not valid and is 

> > > used specifically for heartbeat purpose).  The idea =
is to
get some 

> > > kind of responses. 

> > > 

> > > "poll" do you mean heartbeat like msg to from =
MG to
MGC 

> or something 

> > > else here. 

> > > 

> > > Where did you see that Restart w/ROOT is used as a
heartbeat/poll? 

> > > 

> > > Chuong 

> > > 

> > > Dan Elbert wrote: 

> > > Hi 

> > > 

> > > After reviewing the issue of MGC failure ( when the MG =
is 

> connected 

> > > trough UDP ) I believe that there is no satisfactory way =


> > for the MG to 

> > > poll the MGC to see if the MGC is still alive. Using a =


> ServiceChange 

> > > with "Restart" method and termination id of
"root" may 

> cause the MGC 

> > > to assume that the MG restarted and can affect the state =
of 

> > a call in 

> > > progress. 

> > > 

> > > I think that it would be good to add a ServiceChange =


> method "noop" : 

> > > 

> > > Noop : Can be used by the MG (with unreliable protocols) =


> to obtain a 

> > > response from the MGC or detect a communication failure. =
When 

> > > receiving this SVC the MGC should take no action other =
that
reply. 

> > > 

> > > If this is not acceptable, then I think that some =
clarification
is 

> > > needed as when a SVC with restart method should be 

> considered "noop" 

> > > by the MGC. 

> > > 

> > > Dan Elbert 

> > > 

> > > RADVISION 

> > > 

> > > -- 

> > > 

> > >   Alcatel USA,
Inc           &nb=
sp;
Internet: 

> > Chuong.Nguyen@usa.alcatel.com 

> > > 

> > >   1000 Coit Road Plano, Texas
75075           =
Phone: 

> > (972) 519-4613 

> > > 

> > >   **** The opinions expressed are not those of =
Alcatel


> USA, Inc **** 

> > > 

> > > -- 

> > > 

> > >   Alcatel USA,
Inc           &nb=
sp;
Internet: 

> > Chuong.Nguyen@usa.alcatel.com 

> > > 

> > >   1000 Coit Road Plano, Texas
75075           =
Phone: 

> > (972) 519-4613 

> > > 

> > >   **** The opinions expressed are not those of =
Alcatel


> USA, Inc **** 

> > > 

> > 

> > 

>






-- =

  Alcatel USA, =
Inc           &nb=
sp; Internet: Chuong.Nguyen@usa.alcatel.com=

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

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




 =







-- =

  Alcatel USA, =
Inc           &nb=
sp; Internet: Chuong.Nguyen@usa.alcatel.com=

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

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




 =










------_=_NextPart_001_01C0DD4E.356AC070--


From owner-megaco@fore.com  Tue May 15 11:10:23 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29708
	for ; Tue, 15 May 2001 11:10:22 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA21457;
	Tue, 15 May 2001 11:03:12 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA04260
	for megaco-list; Tue, 15 May 2001 11:00:52 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA04255
	for ; Tue, 15 May 2001 11:00:50 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA21121
	for ; Tue, 15 May 2001 11:00:46 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4FF0edQ020832
	for ; Tue, 15 May 2001 10:00:41 -0500 (CDT)
From: "Paul Long" 
To: 
Subject: RE: Polls of MGC
Date: Tue, 15 May 2001 10:00:42 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0004_01C0DD25.E6DDD500"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <0D5BBF5D638DD4119E3400508BD949458110CB@RADVPOST>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0004_01C0DD25.E6DDD500
Content-Type: text/plain;
	charset="iso-8859-1"
X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id LAA21457
Content-Transfer-Encoding: quoted-printable

Dan,

If the MGC knew that an MG was down, it could free up resources related t=
o
that association. That's about the only benefit I can see. However, that =
may
be reason enough to have an explicit MGC-to-MG polling mechanism.

Paul Long
ipDialog, Inc.
  -----Original Message-----
  From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dan Elbert
  Sent: Tuesday, May 15, 2001 9:49 AM
  To: 'Chuong Nguyen'; megaco@fore.com
  Subject: RE: Polls of MGC (was RE: Implementers' Guide Update Editor's
last Ca ll - MGC failure)


  This is only needed for UDP, in TCP you always know when the connection=
 is
lost.

  I don=92t think the MGC needs to poll, it can always detect the MG loss=
 when
trying to do something. In any case if it detects that the MG is down the=
re
is no much it can do.

  The MG in the other hand needs to know if it needs to reestablish the
connection to the MGC ( or try to connect a backup MGC).

  I still think that SVC with method =93noop=94 is the simplest solution =
, and
every MGC should support this either with a reply (if it implements the
method) or with an error (if it doesn=92t know it). The spec allows for t=
he
use of =93extension=94 SVC methods.



  Dan Elbert

  RADVISION



  -----Original Message-----
  From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
  Sent: Tuesday, May 15, 2001 10:28 AM
  To: megaco@fore.com
  Subject: Re: Polls of MGC (was RE: Implementers' Guide Update Editor's
last Ca ll - MGC failure)




  If the Standard is going to specify a poll mechanism, let's do it right
and specify it for
  both MG and MGC.

  A package that only satisfies MG and might not be supported by everyone
does not sound
  like a very good specification.

  An audit of packages can give varying messages size from MG which can b=
e a
performance
  issue to the MGC.

  SC is definitely the way to go where a small known fixed size simple
Request/Reply is
  all that is needed for polling purpose.

  Is this strictly a UDP issue or is the intend that TCP implementation
would need the polling
  too?

  Chuong

  "Rosen, Brian" wrote:

  This thread is about an MG poll of MGC, not the other way.  An MGC poll=
 of
MG iseasy (audit of packages is an easy one).  Yes, both sides would have=
 to
implementthe package for it to work.  That is why I like the original
ServiceChange idea.
  The package is just an "easy out" if we don't do something with SC.

  Brian

  -----Original Message-----
  From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
  Sent: Tuesday, May 15, 2001 9:24 AM
  To: megaco@fore.com
  Subject: Re: Polls of MGC (was RE: Implementers' Guide Update Editor's
last Ca ll - MGC failure)

  Notify goes from MG to MGC.
  MGC does not send Notify.

  So how does MGC poll the MG?
  If we are making the assumption that by MGC requesting an event from MG=
,
we
  are saying that MGC is sort of polling MG too.

  But what if MG does not support this package?

  Chuong



  "Rosen, Brian" wrote:

  It would be a real package (would need approval).  You would have
  to put it in the event descriptor, but I think that is right -
  you don't want the MGC getting events it didn't expect.

  Brian

  > -----Original Message-----
  > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
  > Sent: Tuesday, May 15, 2001 9:13 AM
  > To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Kevin Boyle'; 'Dan Elbert'
  > Cc: megaco@fore.com; 'Chuong Nguyen'
  > Subject: RE: Polls of MGC (was RE: Implementers' Guide Update Editor'=
s
  > last Ca ll - MGC failure)
  >
  >
  > Hi All,
  > If this event is defined in a new package, does the MGC needs
  > to send this
  > event in the event descriptor...or is this an exception of
  > the normal event
  > detection behavior?
  > Regards
  > Madhubabu
  >
  > -----Original Message-----
  > From: owner-megaco@pit.comms.marconi.com
  > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
  > Sent: Tuesday, May 15, 2001 7:57 AM
  > To: 'Tom-PT Taylor'; Kevin Boyle; Dan Elbert
  > Cc: megaco@fore.com; 'Chuong Nguyen'
  > Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor'=
s
  > last Ca ll - MGC failure)
  >
  >
  > If you don't want to create the noop method, we can go
  > back to a package.
  >
  >
  >    PackageID: nop (0x00xx)
  >    Version: 1
  >    Extends: None
  >
  >    Description: No op event.  Can be used for testing or MG
  > poll of MGC.
  >
  > Properties
  >
  >    None
  >
  > Events
  >
  >    noop
  >    -----
  >    EventID:     noop (0x0001)
  >
  >    No op event
  >
  >    Events Descriptor Parameters:
  >
  >         Interval
  >         -------------
  >         ParameterID: delay (0x0001)
  >
  >         Description: delay in milliseconds to generate event.
  >             if not specified, MG may choose any value. 0 implies
  >                immediate response.
  >         Possible Values: INTEGER
  >
  > Brian
  >
  > -----Original Message-----
  > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
  > Sent: Tuesday, May 15, 2001 3:59 AM
  > To: Kevin Boyle; Dan Elbert
  > Cc: megaco@fore.com; 'Chuong Nguyen'
  > Subject: Polls of MGC (was RE: Implementors' Guide Update
  > Editor's last Ca
  > ll - MGC failure)
  >
  >
  > Let's follow through the logic here.  A restart implies loss
  > of state.  I
  > don't care whether you're talking ROOT or a real termination.
  >  It would be
  > inconsistent to declare restart of the latter a no-op.
  > I'd suggest the safest poll would be a NOTIFY with no events
  > and a bogus
  > requestID in it.  The MGC has to answer, even if only to
  > return an error,
  > but the NOTIFY doesn't change anything.
  > > -----Original Message-----
  > > From: Boyle, Kevin [NCRTP:3Z70:EXCH]
  > > Sent: Monday, May 14, 2001 12:50 PM
  > > To: Dan Elbert
  > > Cc: megaco@fore.com; 'Chuong Nguyen'
  > > Subject: Re: Implementors' Guide Update Editor's last Call -
  > > MGC failure
  > >
  > >
  > > Yes.  Root is a special case.  Restart on Root, if it is already in
  > > service, implies that the MG has gone out of service and
  > returned, and
  > > that anything that was happening previously is lost.  This
  > > was discussed
  > > on an earlier thread.
  > >
  > > Kevin
  > >
  > > Dan Elbert wrote:
  > >
  > > > Well I was just following the logic that a restart of a
  > termination
  > > > already in service is a noop. Is the root termination a
  > > special case ?
  > > > . The problem with poll vs restart is the same in any case.
  > > >
  > > > -----Original Message-----
  > > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
  > > > Sent: Monday, May 14, 2001 12:22 PM
  > > > To: megaco@fore.com
  > > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
  > > > failure
  > > >
  > > >
  > > > To me definitely NOT.
  > > > How will MGC knows that it is a registration restarts vs a poll?
  > > > Don't tell me that one can use Reason Code since Reason
  > > Code has to be
  > > > IANA registered
  > > > before it can be widely used.
  > > > But since anyone can register w/IANA at any time, it only
  > means that
  > > > it might not be supported by
  > > > everyone.
  > > >
  > > > Chuong
  > > >
  > > > Dan Elbert wrote:
  > > >
  > > > Another thing : Can I then use a restart of the "root"
  > > termination to
  > > > poll the MGC ? It seems to me more clean that to just use any
  > > > termination.
  > > >
  > > > -----Original Message-----
  > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
  > > > Sent: Monday, May 14, 2001 12:00 PM
  > > > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen'
  > > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
  > > > failure
  > > >
  > > > I think that a restart of a termination that is already in servic=
e
  > > > should be treated
  > > >
  > > > as a nop by an MGC.
  > > >
  > > > I have no objection to adding an explicit no-op method,
  > but I don't
  > > > think it is needed.
  > > >
  > > > Brian
  > > > -----Original Message-----
  > > >
  > > > From: Dan Elbert [mailto:DElbert@radvision.com]
  > > > Sent: Friday, May 11, 2001 5:57 PM
  > > > To: 'megaco@fore.com'; 'Chuong Nguyen'
  > > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
  > > > failure
  > > > Using a fully specified terminationID can disrupt the
  > > operation of the
  > > > termination (for example if the termination is in a call).
  > > >
  > > > It's not clear what a "bogus" termination is, if the MGC
  > receives a
  > > > SVC from an MG termination it can assume that this
  > > termination is real
  > > > and start sending audits or commands.
  > > >
  > > > Yes, by poll I mean some type of heartbeat as the MG needs
  > > to know if
  > > > the MGC is alive.
  > > >
  > > > Brian Rosen suggested in the past to use SVC with Restart
  > method for
  > > > this purpose, I don't think that there was any mantion if
  > > this should
  > > > be done with id=3Droot or other.
  > > >
  > > > Dan
  > > > -----Original Message-----
  > > >
  > > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
  > > > Sent: Friday, May 11, 2001 5:38 PM
  > > > To: megaco@fore.com
  > > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
  > > > failure
  > > >
  > > > The intend was not to use ROOT but a fully specified
  > > terminationID or
  > > > even better a
  > > > known invalid terminationID (A bogus terminationID that the sende=
r
  > > > knows is not valid and is
  > > > used specifically for heartbeat purpose).  The idea is to get som=
e
  > > > kind of responses.
  > > >
  > > > "poll" do you mean heartbeat like msg to from MG to MGC
  > or something
  > > > else here.
  > > >
  > > > Where did you see that Restart w/ROOT is used as a heartbeat/poll=
?
  > > >
  > > > Chuong
  > > >
  > > > Dan Elbert wrote:
  > > > Hi
  > > >
  > > > After reviewing the issue of MGC failure ( when the MG is
  > connected
  > > > trough UDP ) I believe that there is no satisfactory way
  > > for the MG to
  > > > poll the MGC to see if the MGC is still alive. Using a
  > ServiceChange
  > > > with "Restart" method and termination id of "root" may
  > cause the MGC
  > > > to assume that the MG restarted and can affect the state of
  > > a call in
  > > > progress.
  > > >
  > > > I think that it would be good to add a ServiceChange
  > method "noop" :
  > > >
  > > > Noop : Can be used by the MG (with unreliable protocols)
  > to obtain a
  > > > response from the MGC or detect a communication failure. When
  > > > receiving this SVC the MGC should take no action other that reply.
  > > >
  > > > If this is not acceptable, then I think that some clarification i=
s
  > > > needed as when a SVC with restart method should be
  > considered "noop"
  > > > by the MGC.
  > > >
  > > > Dan Elbert
  > > >
  > > > RADVISION
  > > >
  > > > --
  > > >
  > > >   Alcatel USA, Inc             Internet:
  > > Chuong.Nguyen@usa.alcatel.com
  > > >
  > > >   1000 Coit Road Plano, Texas 75075           Phone:
  > > (972) 519-4613
  > > >
  > > >   **** The opinions expressed are not those of Alcatel
  > USA, Inc ****
  > > >
  > > > --
  > > >
  > > >   Alcatel USA, Inc             Internet:
  > > Chuong.Nguyen@usa.alcatel.com
  > > >
  > > >   1000 Coit Road Plano, Texas 75075           Phone:
  > > (972) 519-4613
  > > >
  > > >   **** The opinions expressed are not those of Alcatel
  > USA, Inc ****
  > > >
  > >
  > >
  >

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****


--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



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











Dan,


 


If the=20
MGC knew that an MG was down, it could free up resources related to that =

association. That's about the only benefit I can see. However, that may =
be=20
reason enough to have an explicit MGC-to-MG polling=20
mechanism.


 


Paul=20
Long


ipDialog, Inc.



  
-----Original Message-----
From:=20
  owner-megaco@pit.comms.marconi.com=20
  [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dan=20
  Elbert
Sent: Tuesday, May 15, 2001 9:49 AM
To: =
'Chuong=20
  Nguyen'; megaco@fore.com
Subject: RE: Polls of MGC (was RE:=20
  Implementers' Guide Update Editor's last Ca ll - MGC=20
  failure)


  

  
This=20
  is only needed for UDP, in TCP you always know when the connection is=20
  lost.

  
I=20
  don’t think the MGC needs to poll, it can always detect the MG =
loss when=20
  trying to do something. In any case if it detects that the MG is down =
there is=20
  no much it can do. 

  
The MG=20
  in the other hand needs to know if it needs to reestablish the =
connection to=20
  the MGC ( or try to connect a backup =
MGC).

  
I=20
  still think that SVC with method “noop” is the simplest =
solution , and every=20
  MGC should support this either with a reply (if it implements the =
method) or=20
  with an error (if it doesn’t know it). The spec allows for the =
use of=20
  “extension” SVC =
methods.

  
 

  
Dan=20
  Elbert

  
RADVISION

  
 

  
-----Original=20
  Message-----
From: =
Chuong=20
  Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Tuesday, May 15, 2001 =
10:28=20
  AM
To:=20
  megaco@fore.com
Subject: Re:=20
  Polls of MGC (was RE: Implementers' Guide Update Editor's last Ca ll - =
MGC=20
  failure)

  
 

  
 =

If the=20
  Standard is going to specify a poll mechanism, let's do it right and =
specify=20
  it for 
both MG and MGC. 

  
A package that =
only=20
  satisfies MG and might not be supported by everyone does not sound =

like a=20
  very good specification. 

  
An audit of =
packages can=20
  give varying messages size from MG which can be a performance =

issue to the=20
  MGC. 

  
SC is =
definitely the way to=20
  go where a small known fixed size simple Request/Reply is 
all that =
is=20
  needed for polling purpose. 

  
Is this =
strictly a=20
  UDP issue or is the intend that TCP implementation would =
need the=20
  polling 
too? 

  
Chuong =


  
"Rosen, Brian" =
wrote:=20
  

  
This thread is about an MG =
poll of MGC,=20
  not the other way.  An MGC poll of MG iseasy (audit of packages =
is an=20
  easy one).  Yes, both sides would have to implementthe package =
for it to=20
  work.  That is why I like the original ServiceChange idea. =

The=20
  package is just an "easy out" if we don't do something with SC.=20
  

  
Brian=20
  

  
  
-----Original=20
  Message-----=20
  
From: Chuong =
Nguyen [mailto:Chuong.Nguyen@usa.al=
catel.com] 
Sent: Tuesday, =
May 15,=20
  2001 9:24 AM=20
  
To:=20
  megaco@fore.com=20
  
Subject: Re: =
Polls of MGC=20
  (was RE: Implementers' Guide Update Editor's last Ca ll - MGC=20
  failure)

  
Notify goes from MG to MGC. =

MGC does=20
  not send Notify. 

  So how does MGC poll the MG? =

If we=20
  are making the assumption that by MGC requesting an event from MG, we =

are=20
  saying that MGC is sort of polling MG too. 

  But what if MG does not =
support this=20
  package? 

  Chuong 
  
 =20
  

  "Rosen, Brian" wrote:=20
  

  
  
It would be a real package =
(would need=20
  approval).  You would have 
to put it in the event descriptor, =
but I=20
  think that is right - 
you don't want the MGC getting events it =
didn't=20
  expect. 

  Brian 

  > -----Original =
Message----- 
>=20
  From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] =

>=20
  Sent: Tuesday, May 15, 2001 9:13 AM 
> To: 'Rosen, Brian'; =
'Tom-PT=20
  Taylor'; 'Kevin Boyle'; 'Dan Elbert' 
> Cc: megaco@fore.com; =
'Chuong=20
  Nguyen' 
> Subject: RE: Polls of MGC (was RE: Implementers' =
Guide Update=20
  Editor's 
> last Ca ll - MGC failure) 
> 
> 
> =
Hi All,=20
  
> If this event is defined in a new package, does the MGC needs =

  
> to send this 
> event in the event descriptor...or is =
this an=20
  exception of 
> the normal event 
> detection behavior? =

>=20
  Regards 
> Madhubabu 
> 
> -----Original =
Message-----=20
  
> From: owner-megaco@pit.comms.marconi.com 
> [mailto:owner-megaco@pi=
t.comms.marconi.com]On=20
  Behalf Of Rosen, Brian 
> Sent: Tuesday, May 15, 2001 7:57 AM =

>=20
  To: 'Tom-PT Taylor'; Kevin Boyle; Dan Elbert 
> Cc: =
megaco@fore.com;=20
  'Chuong Nguyen' 
> Subject: RE: Polls of MGC (was RE: =
Implementors'=20
  Guide Update Editor's 
> last Ca ll - MGC failure) 
> =

>=20
  
> If you don't want to create the noop method, we can go =

> back=20
  to a package. 
> 
> 
>    PackageID: =
nop=20
  (0x00xx) 
>    Version: 1 =

>   =20
  Extends: None 
> 
>    Description: No op=20
  event.  Can be used for testing or MG 
> poll of MGC. =

>=20
  
> Properties 
> 
>    None 
> =

>=20
  Events 
> 
>    noop =

>   =20
  ----- 
>    EventID:     noop =

  (0x0001) 
> 
>    No op event 
>=20
  
>    Events Descriptor Parameters: 
>=20
  
>         Interval=20
  
>         ------------- =

  
>         ParameterID: =
delay=20
  (0x0001) 
> =

>        =20
  Description: delay in milliseconds to generate event.=20
  =

>           =
; =20
  if not specified, MG may choose any value. 0 implies=20
  =

>           =
;    =20
  immediate response. =

>        =20
  Possible Values: INTEGER 
> 
> Brian 
> 
>=20
  -----Original Message----- 
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.co=
m]=20
  
> Sent: Tuesday, May 15, 2001 3:59 AM 
> To: Kevin Boyle; =
Dan=20
  Elbert 
> Cc: megaco@fore.com; 'Chuong Nguyen' 
> Subject: =
Polls=20
  of MGC (was RE: Implementors' Guide Update 
> Editor's last Ca =

>=20
  ll - MGC failure) 
> 
> 
> Let's follow through the =
logic=20
  here.  A restart implies loss 
> of state.  I 
> =
don't=20
  care whether you're talking ROOT or a real termination. 
>  =
It=20
  would be 
> inconsistent to declare restart of the latter a =
no-op.=20
  
> I'd suggest the safest poll would be a NOTIFY with no events =

>=20
  and a bogus 
> requestID in it.  The MGC has to answer, =
even if=20
  only to 
> return an error, 
> but the NOTIFY doesn't =
change=20
  anything. 
> > -----Original Message----- 
> > From: =
Boyle,=20
  Kevin [NCRTP:3Z70:EXCH] 
> > Sent: Monday, May 14, 2001 12:50 =
PM=20
  
> > To: Dan Elbert 
> > Cc: megaco@fore.com; =
'Chuong=20
  Nguyen' 
> > Subject: Re: Implementors' Guide Update Editor's =
last=20
  Call - 
> > MGC failure 
> > 
> > 
> =
>=20
  Yes.  Root is a special case.  Restart on Root, if it is =
already in=20
  
> > service, implies that the MG has gone out of service and =

  
> returned, and 
> > that anything that was happening=20
  previously is lost.  This 
> > was discussed 
> =
> on an=20
  earlier thread. 
> > 
> > Kevin 
> > =

> >=20
  Dan Elbert wrote: 
> > 
> > > Well I was just =
following=20
  the logic that a restart of a 
> termination 
> > > =
already=20
  in service is a noop. Is the root termination a 
> > special =
case ?=20
  
> > > . The problem with poll vs restart is the same in =
any case.=20
  
> > > 
> > > -----Original Message----- =

> >=20
  > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.al=
catel.com]=20
  
> > > Sent: Monday, May 14, 2001 12:22 PM 
> > =
> To:=20
  megaco@fore.com 
> > > Subject: Re: Implementors' Guide =
Update=20
  Editor's last Call - MGC 
> > > failure 
> > > =

  
> > > 
> > > To me definitely NOT. 
> =
> >=20
  How will MGC knows that it is a registration restarts vs a poll? =

> >=20
  > Don't tell me that one can use Reason Code since Reason 
> =
>=20
  Code has to be 
> > > IANA registered 
> > > =
before it=20
  can be widely used. 
> > > But since anyone can register =
w/IANA at=20
  any time, it only 
> means that 
> > > it might not =
be=20
  supported by 
> > > everyone. 
> > > 
> =
>=20
  > Chuong 
> > > 
> > > Dan Elbert wrote: =

>=20
  > > 
> > > Another thing : Can I then use a restart =
of the=20
  "root" 
> > termination to 
> > > poll the MGC ? =
It seems=20
  to me more clean that to just use any 
> > > termination. =

>=20
  > > 
> > > -----Original Message----- 
> > =
>=20
  From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]=20
  
> > > Sent: Monday, May 14, 2001 12:00 PM 
> > =
> To:=20
  'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen' 
> > > =
Subject:=20
  RE: Implementors' Guide Update Editor's last Call - MGC 
> > =
>=20
  failure 
> > > 
> > > I think that a restart =
of a=20
  termination that is already in service 
> > > should be =
treated=20
  
> > > 
> > > as a nop by an MGC. 
> =
> >=20
  
> > > I have no objection to adding an explicit no-op =
method,=20
  
> but I don't 
> > > think it is needed. 
> =
> >=20
  
> > > Brian 
> > > -----Original Message----- =

  
> > > 
> > > From: Dan Elbert [mailto:DElbert@radvision.com] =

>=20
  > > Sent: Friday, May 11, 2001 5:57 PM 
> > > To:=20
  'megaco@fore.com'; 'Chuong Nguyen' 
> > > Subject: RE:=20
  Implementors' Guide Update Editor's last Call - MGC 
> > > =
failure=20
  
> > > Using a fully specified terminationID can disrupt =
the=20
  
> > operation of the 
> > > termination (for =
example if=20
  the termination is in a call). 
> > > 
> > > =
It's not=20
  clear what a "bogus" termination is, if the MGC 
> receives a =

>=20
  > > SVC from an MG termination it can assume that this 
> =
>=20
  termination is real 
> > > and start sending audits or =
commands.=20
  
> > > 
> > > Yes, by poll I mean some type of =

  heartbeat as the MG needs 
> > to know if 
> > > =
the MGC=20
  is alive. 
> > > 
> > > Brian Rosen suggested =
in the=20
  past to use SVC with Restart 
> method for 
> > > =
this=20
  purpose, I don't think that there was any mantion if 
> > =
this should=20
  
> > > be done with id=3Droot or other. 
> > > =

>=20
  > > Dan 
> > > -----Original Message----- 
> =
> >=20
  
> > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.al=
catel.com]=20
  
> > > Sent: Friday, May 11, 2001 5:38 PM 
> > =
> To:=20
  megaco@fore.com 
> > > Subject: Re: Implementors' Guide =
Update=20
  Editor's last Call - MGC 
> > > failure 
> > > =

  
> > > The intend was not to use ROOT but a fully =
specified=20
  
> > terminationID or 
> > > even better a =

> >=20
  > known invalid terminationID (A bogus terminationID that the =
sender=20
  
> > > knows is not valid and is 
> > > used=20
  specifically for heartbeat purpose).  The idea is to get some =

>=20
  > > kind of responses. 
> > > 
> > > =
"poll" do=20
  you mean heartbeat like msg to from MG to MGC 
> or something =

>=20
  > > else here. 
> > > 
> > > Where did =
you see=20
  that Restart w/ROOT is used as a heartbeat/poll? 
> > > =

>=20
  > > Chuong 
> > > 
> > > Dan Elbert =
wrote:=20
  
> > > Hi 
> > > 
> > > After =
reviewing=20
  the issue of MGC failure ( when the MG is 
> connected 
> =
>=20
  > trough UDP ) I believe that there is no satisfactory way 
> =
>=20
  for the MG to 
> > > poll the MGC to see if the MGC is =
still=20
  alive. Using a 
> ServiceChange 
> > > with =
"Restart" method=20
  and termination id of "root" may 
> cause the MGC 
> > =
> to=20
  assume that the MG restarted and can affect the state of 
> > =
a call=20
  in 
> > > progress. 
> > > 
> > > =
I think=20
  that it would be good to add a ServiceChange 
> method "noop" : =

>=20
  > > 
> > > Noop : Can be used by the MG (with =
unreliable=20
  protocols) 
> to obtain a 
> > > response from the =
MGC or=20
  detect a communication failure. When 
> > > receiving this =
SVC the=20
  MGC should take no action other that reply. 
> > > =

> >=20
  > If this is not acceptable, then I think that some clarification =
is=20
  
> > > needed as when a SVC with restart method should be =

>=20
  considered "noop" 
> > > by the MGC. 
> > > =

>=20
  > > Dan Elbert 
> > > 
> > > RADVISION =

>=20
  > > 
> > > -- 
> > > 
> >=20
  >   Alcatel USA,=20
  =
Inc           &nbs=
p;=20
  Internet: 
> > Chuong.Nguyen@usa.alcatel.com 
> > =
>=20
  
> > >   1000 Coit Road Plano, Texas=20
  75075           =
Phone:=20
  
> > (972) 519-4613 
> > > 
> > =
>  =20
  **** The opinions expressed are not those of Alcatel 
> USA, Inc =
****=20
  
> > > 
> > > -- 
> > > 
> =
>=20
  >   Alcatel USA,=20
  =
Inc           &nbs=
p;=20
  Internet: 
> > Chuong.Nguyen@usa.alcatel.com 
> > =
>=20
  
> > >   1000 Coit Road Plano, Texas=20
  75075           =
Phone:=20
  
> > (972) 519-4613 
> > > 
> > =
>  =20
  **** The opinions expressed are not those of Alcatel 
> USA, Inc =
****=20
  
> > > 
> > 
> > =

>

  
-- 
  Alcatel USA, =
Inc           &nbs=
p; Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, =
Texas 75075           =
Phone:    (972) 519-4613
  **** The opinions =
expressed are not those of Alcatel USA, Inc ****

  
 
-- 
  Alcatel =
USA, =
Inc           &nbs=
p; Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, =
Texas 75075           =
Phone:    (972) 519-4613
  **** The opinions =
expressed are not those of Alcatel USA, Inc ****

  
 


------=_NextPart_000_0004_01C0DD25.E6DDD500--



From owner-megaco@fore.com  Tue May 15 11:46:35 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00640
	for ; Tue, 15 May 2001 11:46:35 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25367;
	Tue, 15 May 2001 11:40:07 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA15557
	for megaco-list; Tue, 15 May 2001 11:36:54 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA15553
	for ; Tue, 15 May 2001 11:36:53 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24928
	for ; Tue, 15 May 2001 11:36:49 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id BAA07542;
	Wed, 16 May 2001 01:36:14 +1000 (EST)
Received: from ericsson.com ([164.48.166.7])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id BAA09776;
	Wed, 16 May 2001 01:36:05 +1000 (EST)
Message-ID: <3B013832.DE5C9C41@ericsson.com>
Date: Wed, 16 May 2001 00:07:46 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: jeffg@catapult.com
CC: "ggf@avaya.com" , megaco ietf 
Subject: Re: IPv4 address improperly defined
References: <3B000BA3.1A9714DA@catapult.com>
Content-Type: text/plain; charset=iso-8859-1
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id LAA25367
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA00640

Hello Jeff,

Thankyou for your email. It is a bug that was missed. I have added the
following to the Implementors' Guide to cover this:
6.88 Error in ABNF IPv4 address syntax

Description:	The value of the Ipv4 is incorrect. It should be 0..255 not
0.225.
Reference:	Subject: IPv4 address improperly defined
Date: Mon, 14 May 2001 12:45:24 -0400
From: jeffg@catapult.com
To: "ggf@avaya.com" , Christian.Groves@ericsson.com
 [Begin Correction]
B.2 ABNF Syntax Specification
…
V4hex                = 1*3(DIGIT) ; "0".."2255"

…
[End Correction]

Regards, Christian

jeffg@catapult.com wrote:
> 
> Hi,
> 
> I would assume that you've already discovered this bug, but if not...
> 
> -Jeff Gilles
> Catapult Communications
> 
>   ------------------------------------------------------------------------
>                   Name: Erratum.doc
>    Erratum.doc    Type: Microsoft Word Document (application/msword)
>               Encoding: base64




From owner-megaco@fore.com  Wed May 16 02:57:29 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00154
	for ; Wed, 16 May 2001 02:57:09 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA18190;
	Wed, 16 May 2001 02:51:17 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA03244
	for megaco-list; Wed, 16 May 2001 02:47:44 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA03240
	for ; Wed, 16 May 2001 02:47:42 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id CAA18055
	for ; Wed, 16 May 2001 02:47:37 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id CAA05099; Wed, 16 May 2001 02:47:34 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Wed, 16 May 2001 02:47:22 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 16 May 2001 02:47:24 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB4D@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Rosen, Brian'" ,
        "Kevin Boyle" ,
        Dan Elbert 
Cc: megaco@fore.com, "'Chuong Nguyen'" 
Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's las t Ca 
         ll - MGC failure)
Date: Wed, 16 May 2001 02:47:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DDD4.0ECA0620"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DDD4.0ECA0620
Content-Type: text/plain;
	charset="ISO-8859-1"

I started to formulate a response along these lines myself yesterday.  I was
worried about event side-effects: they stop signals, and if you're in
Lockstep mode reporting of other events is delayed.  But there's a simple
answer to that: have the event reported from ROOT or from a special
termination like my NAS outgoing call termination. 

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Tuesday, May 15, 2001 7:57 AM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]; Boyle, Kevin [NCRTP:3Z70:EXCH];
> Dan Elbert
> Cc: megaco@fore.com; 'Chuong Nguyen'
> Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's
> las t Ca ll - MGC failure)
> 
> 
> If you don't want to create the noop method, we can go 
> back to a package.
> 
>    
>    PackageID: nop (0x00xx) 
>    Version: 1 
>    Extends: None 
>     
>    Description: No op event.  Can be used for testing or MG 
> poll of MGC. 
>     
> Properties 
>     
>    None 
>     
> Events 
>     
>    noop 
>    ----- 
>    EventID:     noop (0x0001) 
>     
>    No op event 
>     
>    Events Descriptor Parameters: 
>     
>         Interval 
>         ------------- 
>         ParameterID: delay (0x0001) 
>          
>         Description: delay in milliseconds to generate event.
> 	      if not specified, MG may choose any value. 0 implies
> 		 immediate response.  
>         Possible Values: INTEGER
> 
> Brian 
> 
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Tuesday, May 15, 2001 3:59 AM
> To: Kevin Boyle; Dan Elbert
> Cc: megaco@fore.com; 'Chuong Nguyen'
> Subject: Polls of MGC (was RE: Implementors' Guide Update 
> Editor's last Ca
> ll - MGC failure)
> 
> 
> Let's follow through the logic here.  A restart implies loss 
> of state.  I
> don't care whether you're talking ROOT or a real termination. 
>  It would be
> inconsistent to declare restart of the latter a no-op.
> I'd suggest the safest poll would be a NOTIFY with no events 
> and a bogus
> requestID in it.  The MGC has to answer, even if only to 
> return an error,
> but the NOTIFY doesn't change anything.
> > -----Original Message----- 
> > From: Boyle, Kevin [NCRTP:3Z70:EXCH] 
> > Sent: Monday, May 14, 2001 12:50 PM 
> > To: Dan Elbert 
> > Cc: megaco@fore.com; 'Chuong Nguyen' 
> > Subject: Re: Implementors' Guide Update Editor's last Call - 
> > MGC failure 
> > 
> > 
> > Yes.  Root is a special case.  Restart on Root, if it is already in 
> > service, implies that the MG has gone out of service and 
> returned, and 
> > that anything that was happening previously is lost.  This 
> > was discussed 
> > on an earlier thread. 
> > 
> > Kevin 
> > 
> > Dan Elbert wrote: 
> > 
> > > Well I was just following the logic that a restart of a 
> termination 
> > > already in service is a noop. Is the root termination a 
> > special case ? 
> > > . The problem with poll vs restart is the same in any case. 
> > > 
> > > -----Original Message----- 
> > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com] 
> > > Sent: Monday, May 14, 2001 12:22 PM 
> > > To: megaco@fore.com 
> > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC 
> > > failure 
> > > 
> > > 
> > > To me definitely NOT. 
> > > How will MGC knows that it is a registration restarts vs a poll? 
> > > Don't tell me that one can use Reason Code since Reason 
> > Code has to be 
> > > IANA registered 
> > > before it can be widely used. 
> > > But since anyone can register w/IANA at any time, it only 
> means that 
> > > it might not be supported by 
> > > everyone. 
> > > 
> > > Chuong 
> > > 
> > > Dan Elbert wrote: 
> > > 
> > > Another thing : Can I then use a restart of the "root" 
> > termination to 
> > > poll the MGC ? It seems to me more clean that to just use any 
> > > termination. 
> > > 
> > > -----Original Message----- 
> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] 
> > > Sent: Monday, May 14, 2001 12:00 PM 
> > > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen' 
> > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC 
> > > failure 
> > > 
> > > I think that a restart of a termination that is already 
> in service 
> > > should be treated 
> > > 
> > > as a nop by an MGC. 
> > > 
> > > I have no objection to adding an explicit no-op method, 
> but I don't 
> > > think it is needed. 
> > > 
> > > Brian 
> > > -----Original Message----- 
> > > 
> > > From: Dan Elbert [mailto:DElbert@radvision.com] 
> > > Sent: Friday, May 11, 2001 5:57 PM 
> > > To: 'megaco@fore.com'; 'Chuong Nguyen' 
> > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC 
> > > failure 
> > > Using a fully specified terminationID can disrupt the 
> > operation of the 
> > > termination (for example if the termination is in a call). 
> > > 
> > > It's not clear what a "bogus" termination is, if the MGC 
> receives a 
> > > SVC from an MG termination it can assume that this 
> > termination is real 
> > > and start sending audits or commands. 
> > > 
> > > Yes, by poll I mean some type of heartbeat as the MG needs 
> > to know if 
> > > the MGC is alive. 
> > > 
> > > Brian Rosen suggested in the past to use SVC with Restart 
> method for 
> > > this purpose, I don't think that there was any mantion if 
> > this should 
> > > be done with id=root or other. 
> > > 
> > > Dan 
> > > -----Original Message----- 
> > > 
> > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com] 
> > > Sent: Friday, May 11, 2001 5:38 PM 
> > > To: megaco@fore.com 
> > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC 
> > > failure 
> > > 
> > > The intend was not to use ROOT but a fully specified 
> > terminationID or 
> > > even better a 
> > > known invalid terminationID (A bogus terminationID that 
> the sender 
> > > knows is not valid and is 
> > > used specifically for heartbeat purpose).  The idea is to 
> get some 
> > > kind of responses. 
> > > 
> > > "poll" do you mean heartbeat like msg to from MG to MGC 
> or something 
> > > else here. 
> > > 
> > > Where did you see that Restart w/ROOT is used as a 
> heartbeat/poll? 
> > > 
> > > Chuong 
> > > 
> > > Dan Elbert wrote: 
> > > Hi 
> > > 
> > > After reviewing the issue of MGC failure ( when the MG is 
> connected 
> > > trough UDP ) I believe that there is no satisfactory way 
> > for the MG to 
> > > poll the MGC to see if the MGC is still alive. Using a 
> ServiceChange 
> > > with "Restart" method and termination id of "root" may 
> cause the MGC 
> > > to assume that the MG restarted and can affect the state of 
> > a call in 
> > > progress. 
> > > 
> > > I think that it would be good to add a ServiceChange 
> method "noop" : 
> > > 
> > > Noop : Can be used by the MG (with unreliable protocols) 
> to obtain a 
> > > response from the MGC or detect a communication failure. When 
> > > receiving this SVC the MGC should take no action other 
> that reply. 
> > > 
> > > If this is not acceptable, then I think that some 
> clarification is 
> > > needed as when a SVC with restart method should be 
> considered "noop" 
> > > by the MGC. 
> > > 
> > > Dan Elbert 
> > > 
> > > RADVISION 
> > > 
> > > -- 
> > > 
> > >   Alcatel USA, Inc             Internet: 
> > Chuong.Nguyen@usa.alcatel.com 
> > > 
> > >   1000 Coit Road Plano, Texas 75075           Phone:    
> > (972) 519-4613 
> > > 
> > >   **** The opinions expressed are not those of Alcatel 
> USA, Inc **** 
> > > 
> > > -- 
> > > 
> > >   Alcatel USA, Inc             Internet: 
> > Chuong.Nguyen@usa.alcatel.com 
> > > 
> > >   1000 Coit Road Plano, Texas 75075           Phone:    
> > (972) 519-4613 
> > > 
> > >   **** The opinions expressed are not those of Alcatel 
> USA, Inc **** 
> > > 
> > 
> > 
> 

------_=_NextPart_001_01C0DDD4.0ECA0620
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Polls of MGC (was RE: Implementors' Guide Update Editor's =
las t Ca  ll - MGC failure)




I started to formulate a response along these lines =
myself yesterday.  I was worried about event side-effects: they =
stop signals, and if you're in Lockstep mode reporting of other events =
is delayed.  But there's a simple answer to that: have the event =
reported from ROOT or from a special termination like my NAS outgoing =
call termination. 



> -----Original Message-----

> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]

> Sent: Tuesday, May 15, 2001 7:57 AM

> To: Taylor, Tom-PT [NORSE:B881:EXCH]; Boyle, =
Kevin [NCRTP:3Z70:EXCH];

> Dan Elbert

> Cc: megaco@fore.com; 'Chuong Nguyen'

> Subject: RE: Polls of MGC (was RE: =
Implementors' Guide Update Editor's

> las t Ca ll - MGC failure)

> 

> 

> If you don't want to create the noop method, we =
can go 

> back to a package.

> 

>    

>    PackageID: nop (0x00xx) =


>    Version: 1 

>    Extends: None 

>     

>    Description: No op =
event.  Can be used for testing or MG 

> poll of MGC. 

>     

> Properties 

>     

>    None 

>     

> Events 

>     

>    noop 

>    ----- 

>    =
EventID:     noop (0x0001) 

>     

>    No op event 

>     

>    Events Descriptor Parameters: =


>     

>         =
Interval 

>         =
------------- 

>         =
ParameterID: delay (0x0001) 

>          =


>         =
Description: delay in milliseconds to generate event.

>       =
      if not specified, MG may choose any =
value. 0 implies

>       =
         immediate =
response.  

>         =
Possible Values: INTEGER

> 

> Brian 

> 

> -----Original Message-----

> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c=
om]

> Sent: Tuesday, May 15, 2001 3:59 AM

> To: Kevin Boyle; Dan Elbert

> Cc: megaco@fore.com; 'Chuong Nguyen'

> Subject: Polls of MGC (was RE: Implementors' =
Guide Update 

> Editor's last Ca

> ll - MGC failure)

> 

> 

> Let's follow through the logic here.  A =
restart implies loss 

> of state.  I

> don't care whether you're talking ROOT or a =
real termination. 

>  It would be

> inconsistent to declare restart of the latter a =
no-op.

> I'd suggest the safest poll would be a NOTIFY =
with no events 

> and a bogus

> requestID in it.  The MGC has to answer, =
even if only to 

> return an error,

> but the NOTIFY doesn't change anything.

> > -----Original Message----- 

> > From: Boyle, Kevin [NCRTP:3Z70:EXCH] =


> > Sent: Monday, May 14, 2001 12:50 PM =


> > To: Dan Elbert 

> > Cc: megaco@fore.com; 'Chuong Nguyen' =


> > Subject: Re: Implementors' Guide Update =
Editor's last Call - 

> > MGC failure 

> > 

> > 

> > Yes.  Root is a special case.  =
Restart on Root, if it is already in 

> > service, implies that the MG has gone out =
of service and 

> returned, and 

> > that anything that was happening =
previously is lost.  This 

> > was discussed 

> > on an earlier thread. 

> > 

> > Kevin 

> > 

> > Dan Elbert wrote: 

> > 

> > > Well I was just following the logic =
that a restart of a 

> termination 

> > > already in service is a noop. Is the =
root termination a 

> > special case ? 

> > > . The problem with poll vs restart is =
the same in any case. 

> > > 

> > > -----Original Message----- 

> > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.a=
lcatel.com] 

> > > Sent: Monday, May 14, 2001 12:22 PM =


> > > To: megaco@fore.com 

> > > Subject: Re: Implementors' Guide =
Update Editor's last Call - MGC 

> > > failure 

> > > 

> > > 

> > > To me definitely NOT. 

> > > How will MGC knows that it is a =
registration restarts vs a poll? 

> > > Don't tell me that one can use Reason =
Code since Reason 

> > Code has to be 

> > > IANA registered 

> > > before it can be widely used. 

> > > But since anyone can register w/IANA =
at any time, it only 

> means that 

> > > it might not be supported by 

> > > everyone. 

> > > 

> > > Chuong 

> > > 

> > > Dan Elbert wrote: 

> > > 

> > > Another thing : Can I then use a =
restart of the "root" 

> > termination to 

> > > poll the MGC ? It seems to me more =
clean that to just use any 

> > > termination. 

> > > 

> > > -----Original Message----- 

> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] 

> > > Sent: Monday, May 14, 2001 12:00 PM =


> > > To: 'Dan Elbert'; 'megaco@fore.com'; =
'Chuong Nguyen' 

> > > Subject: RE: Implementors' Guide =
Update Editor's last Call - MGC 

> > > failure 

> > > 

> > > I think that a restart of a =
termination that is already 

> in service 

> > > should be treated 

> > > 

> > > as a nop by an MGC. 

> > > 

> > > I have no objection to adding an =
explicit no-op method, 

> but I don't 

> > > think it is needed. 

> > > 

> > > Brian 

> > > -----Original Message----- 

> > > 

> > > From: Dan Elbert [mailto:DElbert@radvision.com] =


> > > Sent: Friday, May 11, 2001 5:57 PM =


> > > To: 'megaco@fore.com'; 'Chuong =
Nguyen' 

> > > Subject: RE: Implementors' Guide =
Update Editor's last Call - MGC 

> > > failure 

> > > Using a fully specified terminationID =
can disrupt the 

> > operation of the 

> > > termination (for example if the =
termination is in a call). 

> > > 

> > > It's not clear what a =
"bogus" termination is, if the MGC 

> receives a 

> > > SVC from an MG termination it can =
assume that this 

> > termination is real 

> > > and start sending audits or commands. =


> > > 

> > > Yes, by poll I mean some type of =
heartbeat as the MG needs 

> > to know if 

> > > the MGC is alive. 

> > > 

> > > Brian Rosen suggested in the past to =
use SVC with Restart 

> method for 

> > > this purpose, I don't think that =
there was any mantion if 

> > this should 

> > > be done with id=3Droot or other. =


> > > 

> > > Dan 

> > > -----Original Message----- 

> > > 

> > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.a=
lcatel.com] 

> > > Sent: Friday, May 11, 2001 5:38 PM =


> > > To: megaco@fore.com 

> > > Subject: Re: Implementors' Guide =
Update Editor's last Call - MGC 

> > > failure 

> > > 

> > > The intend was not to use ROOT but a =
fully specified 

> > terminationID or 

> > > even better a 

> > > known invalid terminationID (A bogus =
terminationID that 

> the sender 

> > > knows is not valid and is 

> > > used specifically for heartbeat =
purpose).  The idea is to 

> get some 

> > > kind of responses. 

> > > 

> > > "poll" do you mean =
heartbeat like msg to from MG to MGC 

> or something 

> > > else here. 

> > > 

> > > Where did you see that Restart w/ROOT =
is used as a 

> heartbeat/poll? 

> > > 

> > > Chuong 

> > > 

> > > Dan Elbert wrote: 

> > > Hi 

> > > 

> > > After reviewing the issue of MGC =
failure ( when the MG is 

> connected 

> > > trough UDP ) I believe that there is =
no satisfactory way 

> > for the MG to 

> > > poll the MGC to see if the MGC is =
still alive. Using a 

> ServiceChange 

> > > with "Restart" method and =
termination id of "root" may 

> cause the MGC 

> > > to assume that the MG restarted and =
can affect the state of 

> > a call in 

> > > progress. 

> > > 

> > > I think that it would be good to add =
a ServiceChange 

> method "noop" : 

> > > 

> > > Noop : Can be used by the MG (with =
unreliable protocols) 

> to obtain a 

> > > response from the MGC or detect a =
communication failure. When 

> > > receiving this SVC the MGC should =
take no action other 

> that reply. 

> > > 

> > > If this is not acceptable, then I =
think that some 

> clarification is 

> > > needed as when a SVC with restart =
method should be 

> considered "noop" 

> > > by the MGC. 

> > > 

> > > Dan Elbert 

> > > 

> > > RADVISION 

> > > 

> > > -- 

> > > 

> > >   Alcatel USA, =
Inc           &nb=
sp; Internet: 

> > Chuong.Nguyen@usa.alcatel.com 

> > > 

> > >   1000 Coit Road Plano, =
Texas 75075           =
Phone:    

> > (972) 519-4613 

> > > 

> > >   **** The opinions =
expressed are not those of Alcatel 

> USA, Inc **** 

> > > 

> > > -- 

> > > 

> > >   Alcatel USA, =
Inc           &nb=
sp; Internet: 

> > Chuong.Nguyen@usa.alcatel.com 

> > > 

> > >   1000 Coit Road Plano, =
Texas 75075           =
Phone:    

> > (972) 519-4613 

> > > 

> > >   **** The opinions =
expressed are not those of Alcatel 

> USA, Inc **** 

> > > 

> > 

> > 

> 





------_=_NextPart_001_01C0DDD4.0ECA0620--


From owner-megaco@fore.com  Wed May 16 04:50:28 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01506
	for ; Wed, 16 May 2001 04:50:22 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA21583;
	Wed, 16 May 2001 04:44:29 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id EAA26731
	for megaco-list; Wed, 16 May 2001 04:41:21 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA26714
	for ; Wed, 16 May 2001 04:41:19 -0400 (EDT)
From: irianman@excite.com
Received: from portal.gsspro.com.tw ([211.72.252.240])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA21420
	for ; Wed, 16 May 2001 04:41:15 -0400 (EDT)
Received: from mx1.fan.net.au ([216.97.194.1]) by portal.gsspro.com.tw  with Microsoft SMTPSVC(5.5.1877.197.19);
	 Wed, 16 May 2001 01:47:25 +0800
Message-ID: <00004af24b6c$000012d2$000025a5@mx1.kikakuya.ne.jp>
To: 
Subject: CAREER AND INVESTMENT OPPORTUNITY
Date: Tue, 15 May 2001 06:32:22 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

VENTURE CAPITAL BUSINESS,
CAREER AND INVESTMENT OPPORTUNITY
 
Our company, through our expanding partner network
and in conjunction with varied and substantial investment
groups, provides venture capital, capital leasing 
services, equity and debt funding to corporate 
clients nationwide.
 
We are currently expanding our system and are seeking
a professional person as a partner, who in turn will
qualify clients for our services in their geographic
 area.  There is no selling involved.  Qualified 
clients come to us.
 
This opportunity will appeal to an entrepreneurial
individual that is seriously seeking a potential 
six figure income, along with a challenging and 
satisfying career and one that can led to financial
security in an extraordinary and exciting growth 
industry.
 
A strong general business background is a necessity.
 
Our program entails interacting with CEO's of 
emerging growth companies and assessing and qualifying
their financial needs.
 
If accepted as a partner, there is an $9,750 investment
required.
 
To review an extensive package of information, please call 
our voice mail system at 214-346-2138 and leave your 
complete name, telephone number and email address.  
We will email you back with complete information so 
you may review our partnership program in extensive 
detail.

 








To be removed you must put your email address in the subject line and send 
e-mail to : lando85@excite.com


From owner-megaco@fore.com  Wed May 16 08:28:27 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05499
	for ; Wed, 16 May 2001 08:28:22 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA29648;
	Wed, 16 May 2001 08:21:17 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA25418
	for megaco-list; Wed, 16 May 2001 08:17:55 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA25365
	for ; Wed, 16 May 2001 08:17:50 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id IAA29399
	for ; Wed, 16 May 2001 08:17:43 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id IAA17274; Wed, 16 May 2001 08:17:38 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Wed, 16 May 2001 08:17:31 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 16 May 2001 08:17:33 -0400
Message-ID: <28560036253BD41191A10000F8BCBD1104998EF9@zcard00g.ca.nortel.com>
From: "Rajesh Jain" 
To: megaco@fore.com
Subject: Subcribe
Date: Wed, 16 May 2001 08:17:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DE02.2DDD1BA0"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DE02.2DDD1BA0
Content-Type: text/plain

Please subscribe me (rajain@nortelnetworks.com).

------_=_NextPart_001_01C0DE02.2DDD1BA0
Content-Type: text/html






Subcribe




Please subscribe me (rajain@nortelnetworks.com).





------_=_NextPart_001_01C0DE02.2DDD1BA0--


From owner-megaco@fore.com  Wed May 16 09:34:00 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08457
	for ; Wed, 16 May 2001 09:33:55 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA04763;
	Wed, 16 May 2001 09:26:43 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA10212
	for megaco-list; Wed, 16 May 2001 09:25:18 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA10197
	for ; Wed, 16 May 2001 09:25:16 -0400 (EDT)
Received: from brahma01.netbrahma.com ([164.164.70.67])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA04523
	for ; Wed, 16 May 2001 09:25:09 -0400 (EDT)
Received: by BRAHMA01 with Internet Mail Service (5.5.2653.19)
	id ; Wed, 16 May 2001 18:54:49 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D72ECA80@BRAHMA01>
From: Prasad Nayak 
To: "'megaco@fore.com'" 
Subject: Context Request
Date: Wed, 16 May 2001 18:54:48 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hello,
  I am confused with the ASN.1 and ABNF format of context Request. In ASN.1
syntax specification (sectionA.2), it said that "topologyReq SEQUENCE OF
TopologyRequest OPTIONAL".  In ABNF, ContextProperty contains
topologyDescriptor and no where its said that it is a list of
topologyDescriptor.

I am refering RFC 2885.
Can anyone help me in solving this problem.
Thanks in advance
Prasad


From owner-megaco@fore.com  Wed May 16 17:12:05 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19347
	for ; Wed, 16 May 2001 17:12:05 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA13389;
	Wed, 16 May 2001 17:06:26 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA26520
	for megaco-list; Wed, 16 May 2001 17:02:43 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA26504
	for ; Wed, 16 May 2001 17:02:41 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA13028
	for ; Wed, 16 May 2001 17:02:36 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4GL2cH29482
	for ; Wed, 16 May 2001 17:02:38 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4GL2bV29474
	for ; Wed, 16 May 2001 17:02:37 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id RAA11575; Wed, 16 May 2001 17:02:33 -0400 (EDT)
From: Preeti Sharma 
Received: from wink.ho.lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id RAA11570; Wed, 16 May 2001 17:02:32 -0400 (EDT)
Message-ID: <3B02E32F.FBDB0638@wink.ho.lucent.com>
Date: Wed, 16 May 2001 16:29:35 -0400
Original-From: Preeti Sharma 
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD compaq  (Win98; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: megaco@fore.com
Subject: Use of CHOOSE as a TerminationID
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi All,
    I have a very basic question:

    If CHOOSE ($)  is recieved as a TerminationID by the MG, can the MG
then assume that it
    refers to an ephemeral termination. I tend to believe so as the text
in Section 7.2.1 says :

   "The Terminationis 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."

     Also CHOOSE can be used for a TerminationID only in the ADD
command.

     Hence I infer that CHOOSE implies an ephemeral Termination.

     Can someone please clarify this.

 Regards.
 Preeti.





From owner-megaco@fore.com  Wed May 16 17:28:32 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19578
	for ; Wed, 16 May 2001 17:28:31 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA14678;
	Wed, 16 May 2001 17:22:42 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA00071
	for megaco-list; Wed, 16 May 2001 17:20:26 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA00067
	for ; Wed, 16 May 2001 17:20:25 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA14466
	for ; Wed, 16 May 2001 17:20:20 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4GLKMu14307
	for ; Wed, 16 May 2001 17:20:22 -0400 (EDT)
Received: from openetsrv.ho.lucent.com (h135-17-127-229.lucent.com [135.17.127.229])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4GLKLZ14303
	for ; Wed, 16 May 2001 17:20:21 -0400 (EDT)
Received: from openetpc011 by openetsrv.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id RAA08848; Wed, 16 May 2001 17:14:58 -0400 (EDT)
From: "Raju" 
To: "Preeti Sharma" , 
Subject: RE: Use of CHOOSE as a TerminationID
Date: Wed, 16 May 2001 17:28:40 -0400
Message-ID: 
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)
In-Reply-To: <3B02E32F.FBDB0638@wink.ho.lucent.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Importance: Normal
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

You should also 'qualify' the CHOOSE with some character, so that the
Gateway knows what type of Ephemeral it has to create,
like  R$ for RTP and N$ for NAS termination.

Although the type of ephemeral can be determined from the descriptors, to
avoid ambiguity and make it clear
it's better to (under)specify termination Ids with some prefix ( like 'R$'
or 'N$' ).


-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Preeti Sharma
Sent: Wednesday, May 16, 2001 4:30 PM
To: megaco@fore.com
Subject: Use of CHOOSE as a TerminationID

Hi All,
    I have a very basic question:

    If CHOOSE ($)  is recieved as a TerminationID by the MG, can the MG
then assume that it
    refers to an ephemeral termination. I tend to believe so as the text
in Section 7.2.1 says :

   "The Terminationis 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."

     Also CHOOSE can be used for a TerminationID only in the ADD
command.

     Hence I infer that CHOOSE implies an ephemeral Termination.

     Can someone please clarify this.

 Regards.
 Preeti.





From owner-megaco@fore.com  Thu May 17 00:31:46 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA26248
	for ; Thu, 17 May 2001 00:31:45 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA29120;
	Thu, 17 May 2001 00:24:43 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA04287
	for megaco-list; Thu, 17 May 2001 00:19:56 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA04283
	for ; Thu, 17 May 2001 00:19:54 -0400 (EDT)
From: knayar@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA28905
	for ; Thu, 17 May 2001 00:19:47 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4H4Kre28479;
	Thu, 17 May 2001 09:50:53 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A4F.00166DD6 ; Thu, 17 May 2001 09:34:59 +0530
X-Lotus-FromDomain: HSS
To: "Tom-PT Taylor" 
cc: "'Rosen, Brian'" ,
        "Kevin Boyle" ,
        Dan Elbert , megaco@fore.com,
        "'Chuong Nguyen'" 
Message-ID: <65256A4F.00166B3A.00@sandesh.hss.hns.com>
Date: Thu, 17 May 2001 09:42:26 +0530
Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's las
	 t Ca ll - MGC failure)
Mime-Version: 1.0
Content-type: multipart/mixed;
	Boundary="0__=fLxYR4zDqldJodf0S9NaivKn5zf79L1vuVh5dZ32R0WBiHmUKnEacd4S"
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

--0__=fLxYR4zDqldJodf0S9NaivKn5zf79L1vuVh5dZ32R0WBiHmUKnEacd4S
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Hi Tom, Brian

Following this thread of discussion.....
If we introduce an event "noop"...the MG is dependent upon MGC to enable this
event (by sending the event descriptor with noop event).
The very basic reason, as Dan and Chuong earlier pointed was that MG should be
able to "poll" MGC.
According to my understanding (please correct me if I am wrong) "polling" means
an action to be initiated by the MG independent of MGC enabling an event or not.
Hence, SVC (method - noop on root) seems to be a better idea than an event (noop
on root).

-Kapil Nayar
Hughes Software Systems




"Tom-PT Taylor"  on 05/16/2001 12:17:21 PM

To:   "'Rosen, Brian'" , "Kevin Boyle"
      , Dan Elbert 
cc:   megaco@fore.com, "'Chuong Nguyen'"  (bcc:
      Kapil Nayar/HSS)

Subject:  RE: Polls of MGC (was RE: Implementors' Guide Update Editor's las t Ca
      ll - MGC failure)




I started to formulate a response along these lines myself yesterday.  I was
worried about event side-effects: they stop signals, and if you're in
Lockstep mode reporting of other events is delayed.  But there's a simple
answer to that: have the event reported from ROOT or from a special
termination like my NAS outgoing call termination.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Tuesday, May 15, 2001 7:57 AM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]; Boyle, Kevin [NCRTP:3Z70:EXCH];
> Dan Elbert
> Cc: megaco@fore.com; 'Chuong Nguyen'
> Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's
> las t Ca ll - MGC failure)
>
>
> If you don't want to create the noop method, we can go
> back to a package.
>
>
>    PackageID: nop (0x00xx)
>    Version: 1
>    Extends: None
>
>    Description: No op event.  Can be used for testing or MG
> poll of MGC.
>
> Properties
>
>    None
>
> Events
>
>    noop
>    -----
>    EventID:     noop (0x0001)
>
>    No op event
>
>    Events Descriptor Parameters:
>
>         Interval
>         -------------
>         ParameterID: delay (0x0001)
>
>         Description: delay in milliseconds to generate event.
>          if not specified, MG may choose any value. 0 implies
>          immediate response.
>         Possible Values: INTEGER
>
> Brian
>
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Tuesday, May 15, 2001 3:59 AM
> To: Kevin Boyle; Dan Elbert
> Cc: megaco@fore.com; 'Chuong Nguyen'
> Subject: Polls of MGC (was RE: Implementors' Guide Update
> Editor's last Ca
> ll - MGC failure)
>
>
> Let's follow through the logic here.  A restart implies loss
> of state.  I
> don't care whether you're talking ROOT or a real termination.
>  It would be
> inconsistent to declare restart of the latter a no-op.
> I'd suggest the safest poll would be a NOTIFY with no events
> and a bogus
> requestID in it.  The MGC has to answer, even if only to
> return an error,
> but the NOTIFY doesn't change anything.
> > -----Original Message-----
> > From: Boyle, Kevin [NCRTP:3Z70:EXCH]
> > Sent: Monday, May 14, 2001 12:50 PM
> > To: Dan Elbert
> > Cc: megaco@fore.com; 'Chuong Nguyen'
> > Subject: Re: Implementors' Guide Update Editor's last Call -
> > MGC failure
> >
> >
> > Yes.  Root is a special case.  Restart on Root, if it is already in
> > service, implies that the MG has gone out of service and
> returned, and
> > that anything that was happening previously is lost.  This
> > was discussed
> > on an earlier thread.
> >
> > Kevin
> >
> > Dan Elbert wrote:
> >
> > > Well I was just following the logic that a restart of a
> termination
> > > already in service is a noop. Is the root termination a
> > special case ?
> > > . The problem with poll vs restart is the same in any case.
> > >
> > > -----Original Message-----
> > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > > Sent: Monday, May 14, 2001 12:22 PM
> > > To: megaco@fore.com
> > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
> > > failure
> > >
> > >
> > > To me definitely NOT.
> > > How will MGC knows that it is a registration restarts vs a poll?
> > > Don't tell me that one can use Reason Code since Reason
> > Code has to be
> > > IANA registered
> > > before it can be widely used.
> > > But since anyone can register w/IANA at any time, it only
> means that
> > > it might not be supported by
> > > everyone.
> > >
> > > Chuong
> > >
> > > Dan Elbert wrote:
> > >
> > > Another thing : Can I then use a restart of the "root"
> > termination to
> > > poll the MGC ? It seems to me more clean that to just use any
> > > termination.
> > >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > Sent: Monday, May 14, 2001 12:00 PM
> > > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen'
> > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
> > > failure
> > >
> > > I think that a restart of a termination that is already
> in service
> > > should be treated
> > >
> > > as a nop by an MGC.
> > >
> > > I have no objection to adding an explicit no-op method,
> but I don't
> > > think it is needed.
> > >
> > > Brian
> > > -----Original Message-----
> > >
> > > From: Dan Elbert [mailto:DElbert@radvision.com]
> > > Sent: Friday, May 11, 2001 5:57 PM
> > > To: 'megaco@fore.com'; 'Chuong Nguyen'
> > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
> > > failure
> > > Using a fully specified terminationID can disrupt the
> > operation of the
> > > termination (for example if the termination is in a call).
> > >
> > > It's not clear what a "bogus" termination is, if the MGC
> receives a
> > > SVC from an MG termination it can assume that this
> > termination is real
> > > and start sending audits or commands.
> > >
> > > Yes, by poll I mean some type of heartbeat as the MG needs
> > to know if
> > > the MGC is alive.
> > >
> > > Brian Rosen suggested in the past to use SVC with Restart
> method for
> > > this purpose, I don't think that there was any mantion if
> > this should
> > > be done with id=root or other.
> > >
> > > Dan
> > > -----Original Message-----
> > >
> > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > > Sent: Friday, May 11, 2001 5:38 PM
> > > To: megaco@fore.com
> > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
> > > failure
> > >
> > > The intend was not to use ROOT but a fully specified
> > terminationID or
> > > even better a
> > > known invalid terminationID (A bogus terminationID that
> the sender
> > > knows is not valid and is
> > > used specifically for heartbeat purpose).  The idea is to
> get some
> > > kind of responses.
> > >
> > > "poll" do you mean heartbeat like msg to from MG to MGC
> or something
> > > else here.
> > >
> > > Where did you see that Restart w/ROOT is used as a
> heartbeat/poll?
> > >
> > > Chuong
> > >
> > > Dan Elbert wrote:
> > > Hi
> > >
> > > After reviewing the issue of MGC failure ( when the MG is
> connected
> > > trough UDP ) I believe that there is no satisfactory way
> > for the MG to
> > > poll the MGC to see if the MGC is still alive. Using a
> ServiceChange
> > > with "Restart" method and termination id of "root" may
> cause the MGC
> > > to assume that the MG restarted and can affect the state of
> > a call in
> > > progress.
> > >
> > > I think that it would be good to add a ServiceChange
> method "noop" :
> > >
> > > Noop : Can be used by the MG (with unreliable protocols)
> to obtain a
> > > response from the MGC or detect a communication failure. When
> > > receiving this SVC the MGC should take no action other
> that reply.
> > >
> > > If this is not acceptable, then I think that some
> clarification is
> > > needed as when a SVC with restart method should be
> considered "noop"
> > > by the MGC.
> > >
> > > Dan Elbert
> > >
> > > RADVISION
> > >
> > > --
> > >
> > >   Alcatel USA, Inc             Internet:
> > Chuong.Nguyen@usa.alcatel.com
> > >
> > >   1000 Coit Road Plano, Texas 75075           Phone:
> > (972) 519-4613
> > >
> > >   **** The opinions expressed are not those of Alcatel
> USA, Inc ****
> > >
> > > --
> > >
> > >   Alcatel USA, Inc             Internet:
> > Chuong.Nguyen@usa.alcatel.com
> > >
> > >   1000 Coit Road Plano, Texas 75075           Phone:
> > (972) 519-4613
> > >
> > >   **** The opinions expressed are not those of Alcatel
> USA, Inc ****
> > >
> >
> >
>


--0__=fLxYR4zDqldJodf0S9NaivKn5zf79L1vuVh5dZ32R0WBiHmUKnEacd4S
Content-type: text/html;
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U
PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NC41OSI+DQo8VElUTEU+UkU6IFBv
bGxzIG9mIE1HQyAod2FzIFJFOiBJbXBsZW1lbnRvcnMnIEd1aWRlIFVwZGF0ZSBFZGl0b3IncyBs
YXMgdCBDYSAgbGwgLSBNR0MgZmFpbHVyZSk8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxQ
PjxGT05UIFNJWkU9Mj5JIHN0YXJ0ZWQgdG8gZm9ybXVsYXRlIGEgcmVzcG9uc2UgYWxvbmcgdGhl
c2UgbGluZXMgbXlzZWxmIHllc3RlcmRheS4mbmJzcDsgSSB3YXMgd29ycmllZCBhYm91dCBldmVu
dCBzaWRlLWVmZmVjdHM6IHRoZXkgc3RvcCBzaWduYWxzLCBhbmQgaWYgeW91J3JlIGluIExvY2tz
dGVwIG1vZGUgcmVwb3J0aW5nIG9mIG90aGVyIGV2ZW50cyBpcyBkZWxheWVkLiZuYnNwOyBCdXQg
dGhlcmUncyBhIHNpbXBsZSBhbnN3ZXIgdG8gdGhhdDogaGF2ZSB0aGUgZXZlbnQgcmVwb3J0ZWQg
ZnJvbSBST09UIG9yIGZyb20gYSBzcGVjaWFsIHRlcm1pbmF0aW9uIGxpa2UgbXkgTkFTIG91dGdv
aW5nIGNhbGwgdGVybWluYXRpb24uIDwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4mZ3Q7
IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7
IEZyb206IFJvc2VuLCBCcmlhbiBbPEEgSFJFRj0ibWFpbHRvOkJyaWFuLlJvc2VuQG1hcmNvbmku
Y29tIj5tYWlsdG86QnJpYW4uUm9zZW5AbWFyY29uaS5jb208L0E+XTwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+Jmd0OyBTZW50OiBUdWVzZGF5LCBNYXkgMTUsIDIwMDEgNzo1NyBBTTwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBUbzogVGF5bG9yLCBUb20tUFQgW05PUlNFOkI4ODE6RVhD
SF07IEJveWxlLCBLZXZpbiBbTkNSVFA6M1o3MDpFWENIXTs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsgRGFuIEVsYmVydDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBDYzogbWVn
YWNvQGZvcmUuY29tOyAnQ2h1b25nIE5ndXllbic8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn
dDsgU3ViamVjdDogUkU6IFBvbGxzIG9mIE1HQyAod2FzIFJFOiBJbXBsZW1lbnRvcnMnIEd1aWRl
IFVwZGF0ZSBFZGl0b3InczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBsYXMgdCBDYSBs
bCAtIE1HQyBmYWlsdXJlKTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IElmIHlv
dSBkb24ndCB3YW50IHRvIGNyZWF0ZSB0aGUgbm9vcCBtZXRob2QsIHdlIGNhbiBnbyA8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgYmFjayB0byBhIHBhY2thZ2UuPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNw
OyZuYnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsg
UGFja2FnZUlEOiBub3AgKDB4MDB4eCkgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IFZlcnNpb246IDEgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IEV4dGVuZHM6IE5vbmUgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBEZXNjcmlwdGlvbjogTm8gb3AgZXZlbnQuJm5ic3A7IENh
biBiZSB1c2VkIGZvciB0ZXN0aW5nIG9yIE1HIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0
OyBwb2xsIG9mIE1HQy4gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBQcm9wZXJ0aWVzIDwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgTm9uZSA8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IEV2ZW50cyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn
dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vb3AgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IC0tLS0tIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNw
OyZuYnNwOyZuYnNwOyBFdmVudElEOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBub29wICgweDAw
MDEpIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgTm8gb3Ag
ZXZlbnQgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBFdmVu
dHMgRGVzY3JpcHRvciBQYXJhbWV0ZXJzOiA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEludGVydmFsIDwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAtLS0tLS0tLS0tLS0tIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQ
YXJhbWV0ZXJJRDogZGVsYXkgKDB4MDAwMSkgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBEZXNjcmlwdGlvbjogZGVsYXkgaW4gbWlsbGlzZWNvbmRzIHRv
IGdlbmVyYXRlIGV2ZW50LjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlmIG5v
dCBzcGVjaWZpZWQsIE1HIG1heSBjaG9vc2UgYW55IHZhbHVlLiAwIGltcGxpZXM8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbW1lZGlhdGUgcmVz
cG9uc2UuJm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQb3NzaWJsZSBWYWx1ZXM6IElOVEVH
RVI8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj4mZ3Q7IEJyaWFuIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yPiZndDsgRnJvbTogVG9tLVBUIFRheWxvciBbPEEgSFJFRj0ibWFpbHRvOnRh
eWxvckBub3J0ZWxuZXR3b3Jrcy5jb20iPm1haWx0bzp0YXlsb3JAbm9ydGVsbmV0d29ya3MuY29t
PC9BPl08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgU2VudDogVHVlc2RheSwgTWF5IDE1
LCAyMDAxIDM6NTkgQU08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgVG86IEtldmluIEJv
eWxlOyBEYW4gRWxiZXJ0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IENjOiBtZWdhY29A
Zm9yZS5jb207ICdDaHVvbmcgTmd1eWVuJzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBT
dWJqZWN0OiBQb2xscyBvZiBNR0MgKHdhcyBSRTogSW1wbGVtZW50b3JzJyBHdWlkZSBVcGRhdGUg
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IEVkaXRvcidzIGxhc3QgQ2E8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yPiZndDsgbGwgLSBNR0MgZmFpbHVyZSk8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTI+Jmd0OyBMZXQncyBmb2xsb3cgdGhyb3VnaCB0aGUgbG9naWMgaGVyZS4mbmJz
cDsgQSByZXN0YXJ0IGltcGxpZXMgbG9zcyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg
b2Ygc3RhdGUuJm5ic3A7IEk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgZG9uJ3QgY2Fy
ZSB3aGV0aGVyIHlvdSdyZSB0YWxraW5nIFJPT1Qgb3IgYSByZWFsIHRlcm1pbmF0aW9uLiA8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsgSXQgd291bGQgYmU8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yPiZndDsgaW5jb25zaXN0ZW50IHRvIGRlY2xhcmUgcmVzdGFydCBvZiB0aGUg
bGF0dGVyIGEgbm8tb3AuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IEknZCBzdWdnZXN0
IHRoZSBzYWZlc3QgcG9sbCB3b3VsZCBiZSBhIE5PVElGWSB3aXRoIG5vIGV2ZW50cyA8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgYW5kIGEgYm9ndXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsgcmVxdWVzdElEIGluIGl0LiZuYnNwOyBUaGUgTUdDIGhhcyB0byBhbnN3ZXIsIGV2
ZW4gaWYgb25seSB0byA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgcmV0dXJuIGFuIGVy
cm9yLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBidXQgdGhlIE5PVElGWSBkb2Vzbid0
IGNoYW5nZSBhbnl0aGluZy48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAtLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0
OyBGcm9tOiBCb3lsZSwgS2V2aW4gW05DUlRQOjNaNzA6RVhDSF0gPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9Mj4mZ3Q7ICZndDsgU2VudDogTW9uZGF5LCBNYXkgMTQsIDIwMDEgMTI6NTAgUE0gPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgVG86IERhbiBFbGJlcnQgPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgQ2M6IG1lZ2Fjb0Bmb3JlLmNvbTsgJ0NodW9uZyBO
Z3V5ZW4nIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBJ
bXBsZW1lbnRvcnMnIEd1aWRlIFVwZGF0ZSBFZGl0b3IncyBsYXN0IENhbGwgLSA8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBNR0MgZmFpbHVyZSA8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPiZndDsgJmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyA8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBZZXMuJm5ic3A7IFJvb3QgaXMgYSBzcGVj
aWFsIGNhc2UuJm5ic3A7IFJlc3RhcnQgb24gUm9vdCwgaWYgaXQgaXMgYWxyZWFkeSBpbiA8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBzZXJ2aWNlLCBpbXBsaWVzIHRoYXQgdGhl
IE1HIGhhcyBnb25lIG91dCBvZiBzZXJ2aWNlIGFuZCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
PiZndDsgcmV0dXJuZWQsIGFuZCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyB0
aGF0IGFueXRoaW5nIHRoYXQgd2FzIGhhcHBlbmluZyBwcmV2aW91c2x5IGlzIGxvc3QuJm5ic3A7
IFRoaXMgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgd2FzIGRpc2N1c3NlZCA8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBvbiBhbiBlYXJsaWVyIHRocmVhZC4g
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9Mj4mZ3Q7ICZndDsgS2V2aW4gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsg
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgRGFuIEVsYmVydCB3cm90ZTogPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj4mZ3Q7ICZndDsgJmd0OyBXZWxsIEkgd2FzIGp1c3QgZm9sbG93aW5nIHRoZSBsb2dpYyB0aGF0
IGEgcmVzdGFydCBvZiBhIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB0ZXJtaW5hdGlv
biA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IGFscmVhZHkgaW4gc2Vy
dmljZSBpcyBhIG5vb3AuIElzIHRoZSByb290IHRlcm1pbmF0aW9uIGEgPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9Mj4mZ3Q7ICZndDsgc3BlY2lhbCBjYXNlID8gPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9Mj4mZ3Q7ICZndDsgJmd0OyAuIFRoZSBwcm9ibGVtIHdpdGggcG9sbCB2cyByZXN0YXJ0IGlz
IHRoZSBzYW1lIGluIGFueSBjYXNlLiA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0
OyAmZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0
OyBGcm9tOiBDaHVvbmcgTmd1eWVuIFs8QSBIUkVGPSJtYWlsdG86Q2h1b25nLk5ndXllbkB1c2Eu
YWxjYXRlbC5jb20iPm1haWx0bzpDaHVvbmcuTmd1eWVuQHVzYS5hbGNhdGVsLmNvbTwvQT5dIDwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgU2VudDogTW9uZGF5LCBNYXkg
MTQsIDIwMDEgMTI6MjIgUE0gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0
OyBUbzogbWVnYWNvQGZvcmUuY29tIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7
ICZndDsgU3ViamVjdDogUmU6IEltcGxlbWVudG9ycycgR3VpZGUgVXBkYXRlIEVkaXRvcidzIGxh
c3QgQ2FsbCAtIE1HQyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IGZh
aWx1cmUgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyA8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
Jmd0OyAmZ3Q7ICZndDsgVG8gbWUgZGVmaW5pdGVseSBOT1QuIDwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTI+Jmd0OyAmZ3Q7ICZndDsgSG93IHdpbGwgTUdDIGtub3dzIHRoYXQgaXQgaXMgYSByZWdp
c3RyYXRpb24gcmVzdGFydHMgdnMgYSBwb2xsPyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn
dDsgJmd0OyAmZ3Q7IERvbid0IHRlbGwgbWUgdGhhdCBvbmUgY2FuIHVzZSBSZWFzb24gQ29kZSBz
aW5jZSBSZWFzb24gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgQ29kZSBoYXMg
dG8gYmUgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyBJQU5BIHJlZ2lz
dGVyZWQgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyBiZWZvcmUgaXQg
Y2FuIGJlIHdpZGVseSB1c2VkLiA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAm
Z3Q7IEJ1dCBzaW5jZSBhbnlvbmUgY2FuIHJlZ2lzdGVyIHcvSUFOQSBhdCBhbnkgdGltZSwgaXQg
b25seSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgbWVhbnMgdGhhdCA8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IGl0IG1pZ2h0IG5vdCBiZSBzdXBwb3J0ZWQg
YnkgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyBldmVyeW9uZS4gPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPiZndDsgJmd0OyAmZ3Q7IENodW9uZyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn
dDsgJmd0OyAmZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgRGFu
IEVsYmVydCB3cm90ZTogPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyA8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IEFub3RoZXIgdGhpbmcgOiBD
YW4gSSB0aGVuIHVzZSBhIHJlc3RhcnQgb2YgdGhlICZxdW90O3Jvb3QmcXVvdDsgPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgdGVybWluYXRpb24gdG8gPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyBwb2xsIHRoZSBNR0MgPyBJdCBzZWVtcyB0byBtZSBt
b3JlIGNsZWFuIHRoYXQgdG8ganVzdCB1c2UgYW55IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
Jmd0OyAmZ3Q7ICZndDsgdGVybWluYXRpb24uIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0
OyAmZ3Q7ICZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyAtLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0
OyAmZ3Q7IEZyb206IFJvc2VuLCBCcmlhbiBbPEEgSFJFRj0ibWFpbHRvOkJyaWFuLlJvc2VuQG1h
cmNvbmkuY29tIj5tYWlsdG86QnJpYW4uUm9zZW5AbWFyY29uaS5jb208L0E+XSA8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IFNlbnQ6IE1vbmRheSwgTWF5IDE0LCAyMDAx
IDEyOjAwIFBNIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgVG86ICdE
YW4gRWxiZXJ0JzsgJ21lZ2Fjb0Bmb3JlLmNvbSc7ICdDaHVvbmcgTmd1eWVuJyA8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IFN1YmplY3Q6IFJFOiBJbXBsZW1lbnRvcnMn
IEd1aWRlIFVwZGF0ZSBFZGl0b3IncyBsYXN0IENhbGwgLSBNR0MgPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyBmYWlsdXJlIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
Jmd0OyAmZ3Q7ICZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyBJ
IHRoaW5rIHRoYXQgYSByZXN0YXJ0IG9mIGEgdGVybWluYXRpb24gdGhhdCBpcyBhbHJlYWR5IDwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBpbiBzZXJ2aWNlIDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgc2hvdWxkIGJlIHRyZWF0ZWQgPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg
Jmd0OyAmZ3Q7IGFzIGEgbm9wIGJ5IGFuIE1HQy4gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m
Z3Q7ICZndDsgJmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IEkg
aGF2ZSBubyBvYmplY3Rpb24gdG8gYWRkaW5nIGFuIGV4cGxpY2l0IG5vLW9wIG1ldGhvZCwgPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGJ1dCBJIGRvbid0IDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgdGhpbmsgaXQgaXMgbmVlZGVkLiA8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0
OyAmZ3Q7ICZndDsgQnJpYW4gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0
OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn
dDsgJmd0OyAmZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgRnJv
bTogRGFuIEVsYmVydCBbPEEgSFJFRj0ibWFpbHRvOkRFbGJlcnRAcmFkdmlzaW9uLmNvbSI+bWFp
bHRvOkRFbGJlcnRAcmFkdmlzaW9uLmNvbTwvQT5dIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
Jmd0OyAmZ3Q7ICZndDsgU2VudDogRnJpZGF5LCBNYXkgMTEsIDIwMDEgNTo1NyBQTSA8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IFRvOiAnbWVnYWNvQGZvcmUuY29tJzsg
J0NodW9uZyBOZ3V5ZW4nIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsg
U3ViamVjdDogUkU6IEltcGxlbWVudG9ycycgR3VpZGUgVXBkYXRlIEVkaXRvcidzIGxhc3QgQ2Fs
bCAtIE1HQyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IGZhaWx1cmUg
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyBVc2luZyBhIGZ1bGx5IHNw
ZWNpZmllZCB0ZXJtaW5hdGlvbklEIGNhbiBkaXNydXB0IHRoZSA8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPiZndDsgJmd0OyBvcGVyYXRpb24gb2YgdGhlIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTI+Jmd0OyAmZ3Q7ICZndDsgdGVybWluYXRpb24gKGZvciBleGFtcGxlIGlmIHRoZSB0ZXJtaW5h
dGlvbiBpcyBpbiBhIGNhbGwpLiA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAm
Z3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgSXQncyBub3QgY2xl
YXIgd2hhdCBhICZxdW90O2JvZ3VzJnF1b3Q7IHRlcm1pbmF0aW9uIGlzLCBpZiB0aGUgTUdDIDwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyByZWNlaXZlcyBhIDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgU1ZDIGZyb20gYW4gTUcgdGVybWluYXRpb24gaXQgY2Fu
IGFzc3VtZSB0aGF0IHRoaXMgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgdGVy
bWluYXRpb24gaXMgcmVhbCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7
IGFuZCBzdGFydCBzZW5kaW5nIGF1ZGl0cyBvciBjb21tYW5kcy4gPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0
OyAmZ3Q7IFllcywgYnkgcG9sbCBJIG1lYW4gc29tZSB0eXBlIG9mIGhlYXJ0YmVhdCBhcyB0aGUg
TUcgbmVlZHMgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgdG8ga25vdyBpZiA8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IHRoZSBNR0MgaXMgYWxpdmUu
IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyBCcmlhbiBSb3NlbiBzdWdnZXN0ZWQgaW4gdGhlIHBh
c3QgdG8gdXNlIFNWQyB3aXRoIFJlc3RhcnQgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7
IG1ldGhvZCBmb3IgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyB0aGlz
IHB1cnBvc2UsIEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGVyZSB3YXMgYW55IG1hbnRpb24gaWYgPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgdGhpcyBzaG91bGQgPC9GT05UPg0KPEJS
PjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyBiZSBkb25lIHdpdGggaWQ9cm9vdCBvciBvdGhl
ci4gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyA8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IERhbiA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
PiZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIDwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7
ICZndDsgJmd0OyBGcm9tOiBDaHVvbmcgTmd1eWVuIFs8QSBIUkVGPSJtYWlsdG86Q2h1b25nLk5n
dXllbkB1c2EuYWxjYXRlbC5jb20iPm1haWx0bzpDaHVvbmcuTmd1eWVuQHVzYS5hbGNhdGVsLmNv
bTwvQT5dIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgU2VudDogRnJp
ZGF5LCBNYXkgMTEsIDIwMDEgNTozOCBQTSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg
Jmd0OyAmZ3Q7IFRvOiBtZWdhY29AZm9yZS5jb20gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m
Z3Q7ICZndDsgJmd0OyBTdWJqZWN0OiBSZTogSW1wbGVtZW50b3JzJyBHdWlkZSBVcGRhdGUgRWRp
dG9yJ3MgbGFzdCBDYWxsIC0gTUdDIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7
ICZndDsgZmFpbHVyZSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IDwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgVGhlIGludGVuZCB3YXMgbm90
IHRvIHVzZSBST09UIGJ1dCBhIGZ1bGx5IHNwZWNpZmllZCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsgJmd0OyB0ZXJtaW5hdGlvbklEIG9yIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
Jmd0OyAmZ3Q7ICZndDsgZXZlbiBiZXR0ZXIgYSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn
dDsgJmd0OyAmZ3Q7IGtub3duIGludmFsaWQgdGVybWluYXRpb25JRCAoQSBib2d1cyB0ZXJtaW5h
dGlvbklEIHRoYXQgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHRoZSBzZW5kZXIgPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyBrbm93cyBpcyBub3QgdmFsaWQg
YW5kIGlzIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgdXNlZCBzcGVj
aWZpY2FsbHkgZm9yIGhlYXJ0YmVhdCBwdXJwb3NlKS4mbmJzcDsgVGhlIGlkZWEgaXMgdG8gPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGdldCBzb21lIDwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTI+Jmd0OyAmZ3Q7ICZndDsga2luZCBvZiByZXNwb25zZXMuIDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZn
dDsgJmd0OyAmcXVvdDtwb2xsJnF1b3Q7IGRvIHlvdSBtZWFuIGhlYXJ0YmVhdCBsaWtlIG1zZyB0
byBmcm9tIE1HIHRvIE1HQyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgb3Igc29tZXRo
aW5nIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgZWxzZSBoZXJlLiA8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgV2hlcmUgZGlkIHlvdSBzZWUgdGhhdCBSZXN0YXJ0IHcv
Uk9PVCBpcyB1c2VkIGFzIGEgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGhlYXJ0YmVh
dC9wb2xsPyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IDwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgQ2h1b25nIDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZn
dDsgJmd0OyBEYW4gRWxiZXJ0IHdyb3RlOiA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg
Jmd0OyAmZ3Q7IEhpIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyBBZnRlciByZXZpZXdpbmcgdGhl
IGlzc3VlIG9mIE1HQyBmYWlsdXJlICggd2hlbiB0aGUgTUcgaXMgPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9Mj4mZ3Q7IGNvbm5lY3RlZCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0
OyAmZ3Q7IHRyb3VnaCBVRFAgKSBJIGJlbGlldmUgdGhhdCB0aGVyZSBpcyBubyBzYXRpc2ZhY3Rv
cnkgd2F5IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGZvciB0aGUgTUcgdG8g
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyBwb2xsIHRoZSBNR0MgdG8g
c2VlIGlmIHRoZSBNR0MgaXMgc3RpbGwgYWxpdmUuIFVzaW5nIGEgPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9Mj4mZ3Q7IFNlcnZpY2VDaGFuZ2UgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7
ICZndDsgJmd0OyB3aXRoICZxdW90O1Jlc3RhcnQmcXVvdDsgbWV0aG9kIGFuZCB0ZXJtaW5hdGlv
biBpZCBvZiAmcXVvdDtyb290JnF1b3Q7IG1heSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn
dDsgY2F1c2UgdGhlIE1HQyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7
IHRvIGFzc3VtZSB0aGF0IHRoZSBNRyByZXN0YXJ0ZWQgYW5kIGNhbiBhZmZlY3QgdGhlIHN0YXRl
IG9mIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGEgY2FsbCBpbiA8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IHByb2dyZXNzLiA8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0
OyAmZ3Q7ICZndDsgSSB0aGluayB0aGF0IGl0IHdvdWxkIGJlIGdvb2QgdG8gYWRkIGEgU2Vydmlj
ZUNoYW5nZSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgbWV0aG9kICZxdW90O25vb3Am
cXVvdDsgOiA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IDwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgTm9vcCA6IENhbiBiZSB1c2VkIGJ5IHRo
ZSBNRyAod2l0aCB1bnJlbGlhYmxlIHByb3RvY29scykgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj4mZ3Q7IHRvIG9idGFpbiBhIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZn
dDsgcmVzcG9uc2UgZnJvbSB0aGUgTUdDIG9yIGRldGVjdCBhIGNvbW11bmljYXRpb24gZmFpbHVy
ZS4gV2hlbiA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IHJlY2Vpdmlu
ZyB0aGlzIFNWQyB0aGUgTUdDIHNob3VsZCB0YWtlIG5vIGFjdGlvbiBvdGhlciA8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yPiZndDsgdGhhdCByZXBseS4gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj4mZ3Q7ICZndDsgJmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7
IElmIHRoaXMgaXMgbm90IGFjY2VwdGFibGUsIHRoZW4gSSB0aGluayB0aGF0IHNvbWUgPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGNsYXJpZmljYXRpb24gaXMgPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyBuZWVkZWQgYXMgd2hlbiBhIFNWQyB3aXRoIHJlc3Rh
cnQgbWV0aG9kIHNob3VsZCBiZSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgY29uc2lk
ZXJlZCAmcXVvdDtub29wJnF1b3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7
ICZndDsgYnkgdGhlIE1HQy4gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0
OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IERhbiBFbGJlcnQgPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPiZndDsgJmd0OyAmZ3Q7IFJBRFZJU0lPTiA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
PiZndDsgJmd0OyAmZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsg
LS0gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyA8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7IEFsY2F0ZWwgVVNBLCBJbmMm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgSW50ZXJuZXQ6IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAm
Z3Q7IENodW9uZy5OZ3V5ZW5AdXNhLmFsY2F0ZWwuY29tIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTI+Jmd0OyAmZ3Q7ICZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0
OyZuYnNwOyZuYnNwOyAxMDAwIENvaXQgUm9hZCBQbGFubywgVGV4YXMgNzUwNzUmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUGhvbmU6
Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICg5
NzIpIDUxOS00NjEzIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyAqKioqIFRo
ZSBvcGluaW9ucyBleHByZXNzZWQgYXJlIG5vdCB0aG9zZSBvZiBBbGNhdGVsIDwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTI+Jmd0OyBVU0EsIEluYyAqKioqIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTI+Jmd0OyAmZ3Q7ICZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0
OyAtLSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IDwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsgQWxjYXRlbCBVU0EsIElu
YyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBJbnRlcm5ldDogPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7
ICZndDsgQ2h1b25nLk5ndXllbkB1c2EuYWxjYXRlbC5jb20gPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9Mj4mZ3Q7ICZndDsgJmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAm
Z3Q7Jm5ic3A7Jm5ic3A7IDEwMDAgQ29pdCBSb2FkIFBsYW5vLCBUZXhhcyA3NTA3NSZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQaG9u
ZTombmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsg
KDk3MikgNTE5LTQ2MTMgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyA8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7ICoqKiog
VGhlIG9waW5pb25zIGV4cHJlc3NlZCBhcmUgbm90IHRob3NlIG9mIEFsY2F0ZWwgPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFVTQSwgSW5jICoqKiogPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9Mj4mZ3Q7ICZndDsgJmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyA8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsgPC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+DQo=

--0__=fLxYR4zDqldJodf0S9NaivKn5zf79L1vuVh5dZ32R0WBiHmUKnEacd4S--



From owner-megaco@fore.com  Thu May 17 04:32:56 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12164
	for ; Thu, 17 May 2001 04:32:55 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA05276;
	Thu, 17 May 2001 04:27:15 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id EAA18374
	for megaco-list; Thu, 17 May 2001 04:23:38 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA18366
	for ; Thu, 17 May 2001 04:23:36 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id EAA05085
	for ; Thu, 17 May 2001 04:23:32 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id EAA00425; Thu, 17 May 2001 04:22:20 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Thu, 17 May 2001 04:22:24 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 17 May 2001 04:22:25 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB5E@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'knayar@hss.hns.com'" 
Cc: "'Rosen, Brian'" ,
        "Kevin Boyle" ,
        Dan Elbert , megaco@fore.com,
        "'Chuong Nguyen'" 
Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's las t Ca 
         ll - MGC failure)
Date: Thu, 17 May 2001 04:22:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DEAA.80210C70"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DEAA.80210C70
Content-Type: text/plain;
	charset="ISO-8859-1"

It is essential that the MGC be able to control the process -- typically it
will have many MGs to manage, and must be able to keep the polling load down
to a tolerable level.  That's why I favour an event-based approach.

> -----Original Message-----
> From: knayar@hss.hns.com [mailto:knayar@hss.hns.com]
> Sent: Thursday, May 17, 2001 12:12 AM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]
> Cc: 'Rosen, Brian'; Boyle, Kevin [NCRTP:3Z70:EXCH]; Dan Elbert;
> megaco@fore.com; 'Chuong Nguyen'
> Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's
> las t Ca ll - MGC failure)
> 
> 
> 
> 
> Hi Tom, Brian
> 
> Following this thread of discussion.....
> If we introduce an event "noop"...the MG is dependent upon 
> MGC to enable this
> event (by sending the event descriptor with noop event).
> The very basic reason, as Dan and Chuong earlier pointed was 
> that MG should be
> able to "poll" MGC.
> According to my understanding (please correct me if I am 
> wrong) "polling" means
> an action to be initiated by the MG independent of MGC 
> enabling an event or not.
> Hence, SVC (method - noop on root) seems to be a better idea 
> than an event (noop
> on root).
> 
> -Kapil Nayar
> Hughes Software Systems
> 
> 
> 
> 
> "Tom-PT Taylor"  on 05/16/2001 12:17:21 PM
> 
> To:   "'Rosen, Brian'" , "Kevin Boyle"
>       , Dan Elbert 
> cc:   megaco@fore.com, "'Chuong Nguyen'" 
>  (bcc:
>       Kapil Nayar/HSS)
> 
> Subject:  RE: Polls of MGC (was RE: Implementors' Guide 
> Update Editor's las t Ca
>       ll - MGC failure)
> 
> 
> 
> 
> I started to formulate a response along these lines myself 
> yesterday.  I was
> worried about event side-effects: they stop signals, and if you're in
> Lockstep mode reporting of other events is delayed.  But 
> there's a simple
> answer to that: have the event reported from ROOT or from a special
> termination like my NAS outgoing call termination.
> 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > Sent: Tuesday, May 15, 2001 7:57 AM
> > To: Taylor, Tom-PT [NORSE:B881:EXCH]; Boyle, Kevin 
> [NCRTP:3Z70:EXCH];
> > Dan Elbert
> > Cc: megaco@fore.com; 'Chuong Nguyen'
> > Subject: RE: Polls of MGC (was RE: Implementors' Guide 
> Update Editor's
> > las t Ca ll - MGC failure)
> >
> >
> > If you don't want to create the noop method, we can go
> > back to a package.
> >
> >
> >    PackageID: nop (0x00xx)
> >    Version: 1
> >    Extends: None
> >
> >    Description: No op event.  Can be used for testing or MG
> > poll of MGC.
> >
> > Properties
> >
> >    None
> >
> > Events
> >
> >    noop
> >    -----
> >    EventID:     noop (0x0001)
> >
> >    No op event
> >
> >    Events Descriptor Parameters:
> >
> >         Interval
> >         -------------
> >         ParameterID: delay (0x0001)
> >
> >         Description: delay in milliseconds to generate event.
> >          if not specified, MG may choose any value. 0 implies
> >          immediate response.
> >         Possible Values: INTEGER
> >
> > Brian
> >
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Tuesday, May 15, 2001 3:59 AM
> > To: Kevin Boyle; Dan Elbert
> > Cc: megaco@fore.com; 'Chuong Nguyen'
> > Subject: Polls of MGC (was RE: Implementors' Guide Update
> > Editor's last Ca
> > ll - MGC failure)
> >
> >
> > Let's follow through the logic here.  A restart implies loss
> > of state.  I
> > don't care whether you're talking ROOT or a real termination.
> >  It would be
> > inconsistent to declare restart of the latter a no-op.
> > I'd suggest the safest poll would be a NOTIFY with no events
> > and a bogus
> > requestID in it.  The MGC has to answer, even if only to
> > return an error,
> > but the NOTIFY doesn't change anything.
> > > -----Original Message-----
> > > From: Boyle, Kevin [NCRTP:3Z70:EXCH]
> > > Sent: Monday, May 14, 2001 12:50 PM
> > > To: Dan Elbert
> > > Cc: megaco@fore.com; 'Chuong Nguyen'
> > > Subject: Re: Implementors' Guide Update Editor's last Call -
> > > MGC failure
> > >
> > >
> > > Yes.  Root is a special case.  Restart on Root, if it is 
> already in
> > > service, implies that the MG has gone out of service and
> > returned, and
> > > that anything that was happening previously is lost.  This
> > > was discussed
> > > on an earlier thread.
> > >
> > > Kevin
> > >
> > > Dan Elbert wrote:
> > >
> > > > Well I was just following the logic that a restart of a
> > termination
> > > > already in service is a noop. Is the root termination a
> > > special case ?
> > > > . The problem with poll vs restart is the same in any case.
> > > >
> > > > -----Original Message-----
> > > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > > > Sent: Monday, May 14, 2001 12:22 PM
> > > > To: megaco@fore.com
> > > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
> > > > failure
> > > >
> > > >
> > > > To me definitely NOT.
> > > > How will MGC knows that it is a registration restarts vs a poll?
> > > > Don't tell me that one can use Reason Code since Reason
> > > Code has to be
> > > > IANA registered
> > > > before it can be widely used.
> > > > But since anyone can register w/IANA at any time, it only
> > means that
> > > > it might not be supported by
> > > > everyone.
> > > >
> > > > Chuong
> > > >
> > > > Dan Elbert wrote:
> > > >
> > > > Another thing : Can I then use a restart of the "root"
> > > termination to
> > > > poll the MGC ? It seems to me more clean that to just use any
> > > > termination.
> > > >
> > > > -----Original Message-----
> > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > > Sent: Monday, May 14, 2001 12:00 PM
> > > > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen'
> > > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
> > > > failure
> > > >
> > > > I think that a restart of a termination that is already
> > in service
> > > > should be treated
> > > >
> > > > as a nop by an MGC.
> > > >
> > > > I have no objection to adding an explicit no-op method,
> > but I don't
> > > > think it is needed.
> > > >
> > > > Brian
> > > > -----Original Message-----
> > > >
> > > > From: Dan Elbert [mailto:DElbert@radvision.com]
> > > > Sent: Friday, May 11, 2001 5:57 PM
> > > > To: 'megaco@fore.com'; 'Chuong Nguyen'
> > > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
> > > > failure
> > > > Using a fully specified terminationID can disrupt the
> > > operation of the
> > > > termination (for example if the termination is in a call).
> > > >
> > > > It's not clear what a "bogus" termination is, if the MGC
> > receives a
> > > > SVC from an MG termination it can assume that this
> > > termination is real
> > > > and start sending audits or commands.
> > > >
> > > > Yes, by poll I mean some type of heartbeat as the MG needs
> > > to know if
> > > > the MGC is alive.
> > > >
> > > > Brian Rosen suggested in the past to use SVC with Restart
> > method for
> > > > this purpose, I don't think that there was any mantion if
> > > this should
> > > > be done with id=root or other.
> > > >
> > > > Dan
> > > > -----Original Message-----
> > > >
> > > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > > > Sent: Friday, May 11, 2001 5:38 PM
> > > > To: megaco@fore.com
> > > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
> > > > failure
> > > >
> > > > The intend was not to use ROOT but a fully specified
> > > terminationID or
> > > > even better a
> > > > known invalid terminationID (A bogus terminationID that
> > the sender
> > > > knows is not valid and is
> > > > used specifically for heartbeat purpose).  The idea is to
> > get some
> > > > kind of responses.
> > > >
> > > > "poll" do you mean heartbeat like msg to from MG to MGC
> > or something
> > > > else here.
> > > >
> > > > Where did you see that Restart w/ROOT is used as a
> > heartbeat/poll?
> > > >
> > > > Chuong
> > > >
> > > > Dan Elbert wrote:
> > > > Hi
> > > >
> > > > After reviewing the issue of MGC failure ( when the MG is
> > connected
> > > > trough UDP ) I believe that there is no satisfactory way
> > > for the MG to
> > > > poll the MGC to see if the MGC is still alive. Using a
> > ServiceChange
> > > > with "Restart" method and termination id of "root" may
> > cause the MGC
> > > > to assume that the MG restarted and can affect the state of
> > > a call in
> > > > progress.
> > > >
> > > > I think that it would be good to add a ServiceChange
> > method "noop" :
> > > >
> > > > Noop : Can be used by the MG (with unreliable protocols)
> > to obtain a
> > > > response from the MGC or detect a communication failure. When
> > > > receiving this SVC the MGC should take no action other
> > that reply.
> > > >
> > > > If this is not acceptable, then I think that some
> > clarification is
> > > > needed as when a SVC with restart method should be
> > considered "noop"
> > > > by the MGC.
> > > >
> > > > Dan Elbert
> > > >
> > > > RADVISION
> > > >
> > > > --
> > > >
> > > >   Alcatel USA, Inc             Internet:
> > > Chuong.Nguyen@usa.alcatel.com
> > > >
> > > >   1000 Coit Road Plano, Texas 75075           Phone:
> > > (972) 519-4613
> > > >
> > > >   **** The opinions expressed are not those of Alcatel
> > USA, Inc ****
> > > >
> > > > --
> > > >
> > > >   Alcatel USA, Inc             Internet:
> > > Chuong.Nguyen@usa.alcatel.com
> > > >
> > > >   1000 Coit Road Plano, Texas 75075           Phone:
> > > (972) 519-4613
> > > >
> > > >   **** The opinions expressed are not those of Alcatel
> > USA, Inc ****
> > > >
> > >
> > >
> >
> 
> 

------_=_NextPart_001_01C0DEAA.80210C70
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Polls of MGC (was RE: Implementors' Guide Update Editor's =
las t Ca  ll - MGC failure)




It is essential that the MGC be able to control the =
process -- typically it will have many MGs to manage, and must be able =
to keep the polling load down to a tolerable level.  That's why I =
favour an event-based approach.



> -----Original Message-----

> From: knayar@hss.hns.com [mailto:knayar@hss.hns.com]=


> Sent: Thursday, May 17, 2001 12:12 AM

> To: Taylor, Tom-PT [NORSE:B881:EXCH]

> Cc: 'Rosen, Brian'; Boyle, Kevin =
[NCRTP:3Z70:EXCH]; Dan Elbert;

> megaco@fore.com; 'Chuong Nguyen'

> Subject: RE: Polls of MGC (was RE: =
Implementors' Guide Update Editor's

> las t Ca ll - MGC failure)

> 

> 

> 

> 

> Hi Tom, Brian

> 

> Following this thread of discussion.....

> If we introduce an event "noop"...the =
MG is dependent upon 

> MGC to enable this

> event (by sending the event descriptor with =
noop event).

> The very basic reason, as Dan and Chuong =
earlier pointed was 

> that MG should be

> able to "poll" MGC.

> According to my understanding (please correct =
me if I am 

> wrong) "polling" means

> an action to be initiated by the MG independent =
of MGC 

> enabling an event or not.

> Hence, SVC (method - noop on root) seems to be =
a better idea 

> than an event (noop

> on root).

> 

> -Kapil Nayar

> Hughes Software Systems

> 

> 

> 

> 

> "Tom-PT Taylor" =
<taylor@nortelnetworks.com> on 05/16/2001 12:17:21 PM

> 

> To:   "'Rosen, Brian'" =
<Brian.Rosen@marconi.com>, "Kevin Boyle"

>       =
<kboyle@nortelnetworks.com>, Dan Elbert =
<DElbert@radvision.com>

> cc:   megaco@fore.com, "'Chuong =
Nguyen'" 

> <Chuong.Nguyen@usa.alcatel.com> =
(bcc:

>       Kapil =
Nayar/HSS)

> 

> Subject:  RE: Polls of MGC (was RE: =
Implementors' Guide 

> Update Editor's las t Ca

>       ll - MGC =
failure)

> 

> 

> 

> 

> I started to formulate a response along these =
lines myself 

> yesterday.  I was

> worried about event side-effects: they stop =
signals, and if you're in

> Lockstep mode reporting of other events is =
delayed.  But 

> there's a simple

> answer to that: have the event reported from =
ROOT or from a special

> termination like my NAS outgoing call =
termination.

> 

> > -----Original Message-----

> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]

> > Sent: Tuesday, May 15, 2001 7:57 AM

> > To: Taylor, Tom-PT [NORSE:B881:EXCH]; =
Boyle, Kevin 

> [NCRTP:3Z70:EXCH];

> > Dan Elbert

> > Cc: megaco@fore.com; 'Chuong =
Nguyen'

> > Subject: RE: Polls of MGC (was RE: =
Implementors' Guide 

> Update Editor's

> > las t Ca ll - MGC failure)

> >

> >

> > If you don't want to create the noop =
method, we can go

> > back to a package.

> >

> >

> >    PackageID: nop =
(0x00xx)

> >    Version: 1

> >    Extends: None

> >

> >    Description: No op =
event.  Can be used for testing or MG

> > poll of MGC.

> >

> > Properties

> >

> >    None

> >

> > Events

> >

> >    noop

> >    -----

> >    =
EventID:     noop (0x0001)

> >

> >    No op event

> >

> >    Events Descriptor =
Parameters:

> >

> =
>         Interval

> =
>         =
-------------

> =
>         ParameterID: delay =
(0x0001)

> >

> =
>         Description: delay =
in milliseconds to generate event.

> =
>          if not =
specified, MG may choose any value. 0 implies

> =
>          immediate =
response.

> =
>         Possible Values: =
INTEGER

> >

> > Brian

> >

> > -----Original Message-----

> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c=
om]

> > Sent: Tuesday, May 15, 2001 3:59 AM

> > To: Kevin Boyle; Dan Elbert

> > Cc: megaco@fore.com; 'Chuong =
Nguyen'

> > Subject: Polls of MGC (was RE: =
Implementors' Guide Update

> > Editor's last Ca

> > ll - MGC failure)

> >

> >

> > Let's follow through the logic here.  =
A restart implies loss

> > of state.  I

> > don't care whether you're talking ROOT or =
a real termination.

> >  It would be

> > inconsistent to declare restart of the =
latter a no-op.

> > I'd suggest the safest poll would be a =
NOTIFY with no events

> > and a bogus

> > requestID in it.  The MGC has to =
answer, even if only to

> > return an error,

> > but the NOTIFY doesn't change =
anything.

> > > -----Original Message-----

> > > From: Boyle, Kevin =
[NCRTP:3Z70:EXCH]

> > > Sent: Monday, May 14, 2001 12:50 =
PM

> > > To: Dan Elbert

> > > Cc: megaco@fore.com; 'Chuong =
Nguyen'

> > > Subject: Re: Implementors' Guide =
Update Editor's last Call -

> > > MGC failure

> > >

> > >

> > > Yes.  Root is a special =
case.  Restart on Root, if it is 

> already in

> > > service, implies that the MG has gone =
out of service and

> > returned, and

> > > that anything that was happening =
previously is lost.  This

> > > was discussed

> > > on an earlier thread.

> > >

> > > Kevin

> > >

> > > Dan Elbert wrote:

> > >

> > > > Well I was just following the =
logic that a restart of a

> > termination

> > > > already in service is a noop. Is =
the root termination a

> > > special case ?

> > > > . The problem with poll vs =
restart is the same in any case.

> > > >

> > > > -----Original =
Message-----

> > > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.a=
lcatel.com]

> > > > Sent: Monday, May 14, 2001 12:22 =
PM

> > > > To: megaco@fore.com

> > > > Subject: Re: Implementors' Guide =
Update Editor's last Call - MGC

> > > > failure

> > > >

> > > >

> > > > To me definitely NOT.

> > > > How will MGC knows that it is a =
registration restarts vs a poll?

> > > > Don't tell me that one can use =
Reason Code since Reason

> > > Code has to be

> > > > IANA registered

> > > > before it can be widely =
used.

> > > > But since anyone can register =
w/IANA at any time, it only

> > means that

> > > > it might not be supported =
by

> > > > everyone.

> > > >

> > > > Chuong

> > > >

> > > > Dan Elbert wrote:

> > > >

> > > > Another thing : Can I then use a =
restart of the "root"

> > > termination to

> > > > poll the MGC ? It seems to me =
more clean that to just use any

> > > > termination.

> > > >

> > > > -----Original =
Message-----

> > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]

> > > > Sent: Monday, May 14, 2001 12:00 =
PM

> > > > To: 'Dan Elbert'; =
'megaco@fore.com'; 'Chuong Nguyen'

> > > > Subject: RE: Implementors' Guide =
Update Editor's last Call - MGC

> > > > failure

> > > >

> > > > I think that a restart of a =
termination that is already

> > in service

> > > > should be treated

> > > >

> > > > as a nop by an MGC.

> > > >

> > > > I have no objection to adding an =
explicit no-op method,

> > but I don't

> > > > think it is needed.

> > > >

> > > > Brian

> > > > -----Original =
Message-----

> > > >

> > > > From: Dan Elbert [mailto:DElbert@radvision.com]<=
/FONT>

> > > > Sent: Friday, May 11, 2001 5:57 =
PM

> > > > To: 'megaco@fore.com'; 'Chuong =
Nguyen'

> > > > Subject: RE: Implementors' Guide =
Update Editor's last Call - MGC

> > > > failure

> > > > Using a fully specified =
terminationID can disrupt the

> > > operation of the

> > > > termination (for example if the =
termination is in a call).

> > > >

> > > > It's not clear what a =
"bogus" termination is, if the MGC

> > receives a

> > > > SVC from an MG termination it =
can assume that this

> > > termination is real

> > > > and start sending audits or =
commands.

> > > >

> > > > Yes, by poll I mean some type of =
heartbeat as the MG needs

> > > to know if

> > > > the MGC is alive.

> > > >

> > > > Brian Rosen suggested in the =
past to use SVC with Restart

> > method for

> > > > this purpose, I don't think that =
there was any mantion if

> > > this should

> > > > be done with id=3Droot or =
other.

> > > >

> > > > Dan

> > > > -----Original =
Message-----

> > > >

> > > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.a=
lcatel.com]

> > > > Sent: Friday, May 11, 2001 5:38 =
PM

> > > > To: megaco@fore.com

> > > > Subject: Re: Implementors' Guide =
Update Editor's last Call - MGC

> > > > failure

> > > >

> > > > The intend was not to use ROOT =
but a fully specified

> > > terminationID or

> > > > even better a

> > > > known invalid terminationID (A =
bogus terminationID that

> > the sender

> > > > knows is not valid and is

> > > > used specifically for heartbeat =
purpose).  The idea is to

> > get some

> > > > kind of responses.

> > > >

> > > > "poll" do you mean =
heartbeat like msg to from MG to MGC

> > or something

> > > > else here.

> > > >

> > > > Where did you see that Restart =
w/ROOT is used as a

> > heartbeat/poll?

> > > >

> > > > Chuong

> > > >

> > > > Dan Elbert wrote:

> > > > Hi

> > > >

> > > > After reviewing the issue of MGC =
failure ( when the MG is

> > connected

> > > > trough UDP ) I believe that =
there is no satisfactory way

> > > for the MG to

> > > > poll the MGC to see if the MGC =
is still alive. Using a

> > ServiceChange

> > > > with "Restart" method =
and termination id of "root" may

> > cause the MGC

> > > > to assume that the MG restarted =
and can affect the state of

> > > a call in

> > > > progress.

> > > >

> > > > I think that it would be good to =
add a ServiceChange

> > method "noop" :

> > > >

> > > > Noop : Can be used by the MG =
(with unreliable protocols)

> > to obtain a

> > > > response from the MGC or detect =
a communication failure. When

> > > > receiving this SVC the MGC =
should take no action other

> > that reply.

> > > >

> > > > If this is not acceptable, then =
I think that some

> > clarification is

> > > > needed as when a SVC with =
restart method should be

> > considered "noop"

> > > > by the MGC.

> > > >

> > > > Dan Elbert

> > > >

> > > > RADVISION

> > > >

> > > > --

> > > >

> > > >   Alcatel USA, =
Inc           &nb=
sp; Internet:

> > > Chuong.Nguyen@usa.alcatel.com

> > > >

> > > >   1000 Coit Road =
Plano, Texas =
75075           =
Phone:

> > > (972) 519-4613

> > > >

> > > >   **** The opinions =
expressed are not those of Alcatel

> > USA, Inc ****

> > > >

> > > > --

> > > >

> > > >   Alcatel USA, =
Inc           &nb=
sp; Internet:

> > > Chuong.Nguyen@usa.alcatel.com

> > > >

> > > >   1000 Coit Road =
Plano, Texas =
75075           =
Phone:

> > > (972) 519-4613

> > > >

> > > >   **** The opinions =
expressed are not those of Alcatel

> > USA, Inc ****

> > > >

> > >

> > >

> >

> 

> 





------_=_NextPart_001_01C0DEAA.80210C70--


From owner-megaco@fore.com  Thu May 17 07:49:06 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14222
	for ; Thu, 17 May 2001 07:49:05 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA11957;
	Thu, 17 May 2001 07:43:21 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA04573
	for megaco-list; Thu, 17 May 2001 07:38:07 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA04567
	for ; Thu, 17 May 2001 07:38:06 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id HAA11558
	for ; Thu, 17 May 2001 07:38:01 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id HAA14884; Thu, 17 May 2001 07:37:57 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 17 May 2001 07:37:45 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 17 May 2001 07:37:48 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB62@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Prasad Nayak'" ,
        "'megaco@fore.com'" 
Subject: RE: Context Request
Date: Thu, 17 May 2001 07:37:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DEC5.CBB193B0"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DEC5.CBB193B0
Content-Type: text/plain;
	charset="ISO-8859-1"

This has been corrected in the Implementor's Guide.  You should be referring
at the least to RFC 3015, and you should also refer to the H.248
Implementor's Guide (official copy at
http://www.itu.int/itudoc/itu-t/com16/implgd), since it contains approved
corrections to the specification.

> -----Original Message-----
> From: Prasad Nayak [mailto:PrasadN@netbrahma.com]
> Sent: Wednesday, May 16, 2001 9:25 AM
> To: 'megaco@fore.com'
> Subject: Context Request
> 
> 
> Hello,
>   I am confused with the ASN.1 and ABNF format of context 
> Request. In ASN.1
> syntax specification (sectionA.2), it said that "topologyReq 
> SEQUENCE OF
> TopologyRequest OPTIONAL".  In ABNF, ContextProperty contains
> topologyDescriptor and no where its said that it is a list of
> topologyDescriptor.
> 
> I am refering RFC 2885.
> Can anyone help me in solving this problem.
> Thanks in advance
> Prasad
> 

------_=_NextPart_001_01C0DEC5.CBB193B0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Context Request




This has been corrected in the Implementor's =
Guide.  You should be referring at the least to RFC 3015, and you =
should also refer to the H.248 Implementor's Guide (official copy at http://www.itu.int/itudoc/itu-t/com16/implgd), =
since it contains approved corrections to the specification.



> -----Original Message-----

> From: Prasad Nayak [mailto:PrasadN@netbrahma.com]<=
/FONT>

> Sent: Wednesday, May 16, 2001 9:25 AM

> To: 'megaco@fore.com'

> Subject: Context Request

> 

> 

> Hello,

>   I am confused with the ASN.1 and =
ABNF format of context 

> Request. In ASN.1

> syntax specification (sectionA.2), it said that =
"topologyReq 

> SEQUENCE OF

> TopologyRequest OPTIONAL".  In ABNF, =
ContextProperty contains

> topologyDescriptor and no where its said that =
it is a list of

> topologyDescriptor.

> 

> I am refering RFC 2885.

> Can anyone help me in solving this =
problem.

> Thanks in advance

> Prasad

> 





------_=_NextPart_001_01C0DEC5.CBB193B0--


From owner-megaco@fore.com  Thu May 17 07:54:37 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14388
	for ; Thu, 17 May 2001 07:54:37 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA12235;
	Thu, 17 May 2001 07:46:55 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA06348
	for megaco-list; Thu, 17 May 2001 07:43:54 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA06336
	for ; Thu, 17 May 2001 07:43:53 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id HAA12040
	for ; Thu, 17 May 2001 07:43:48 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id HAA16218; Thu, 17 May 2001 07:43:44 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Thu, 17 May 2001 07:43:38 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 17 May 2001 07:43:40 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB63@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Preeti Sharma'" , megaco@fore.com
Subject: RE: Use of CHOOSE as a TerminationID
Date: Thu, 17 May 2001 07:43:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DEC6.9CFB0000"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DEC6.9CFB0000
Content-Type: text/plain;
	charset="ISO-8859-1"

Certainly when the text you quote was drafted, people had ephemerals in
mind.  In theory if Local and Remote described a TDM circuit, the MG would
probably have to choose from amongst the TDM circuits it supported, but this
doesn't seem too useful unless all the circuits go to the same destination.

A CHOOSE is embedded in a partial name, of course, is a reasonable way to
ask the MG to choose from a specific set of terminations, whether that set
be provisioned or ephemeral.

> -----Original Message-----
> From: Preeti Sharma [mailto:preetis@lucent.com]
> Sent: Wednesday, May 16, 2001 4:30 PM
> To: megaco@fore.com
> Subject: Use of CHOOSE as a TerminationID
> 
> 
> Hi All,
>     I have a very basic question:
> 
>     If CHOOSE ($)  is recieved as a TerminationID by the MG, 
> can the MG
> then assume that it
>     refers to an ephemeral termination. I tend to believe so 
> as the text
> in Section 7.2.1 says :
> 
>    "The Terminationis 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."
> 
>      Also CHOOSE can be used for a TerminationID only in the ADD
> command.
> 
>      Hence I infer that CHOOSE implies an ephemeral Termination.
> 
>      Can someone please clarify this.
> 
>  Regards.
>  Preeti.
> 
> 
> 
> 

------_=_NextPart_001_01C0DEC6.9CFB0000
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Use of CHOOSE as a TerminationID




Certainly when the text you quote was drafted, people =
had ephemerals in mind.  In theory if Local and Remote described a =
TDM circuit, the MG would probably have to choose from amongst the TDM =
circuits it supported, but this doesn't seem too useful unless all the =
circuits go to the same destination.



A CHOOSE is embedded in a partial name, of course, is =
a reasonable way to ask the MG to choose from a specific set of =
terminations, whether that set be provisioned or ephemeral.



> -----Original Message-----

> From: Preeti Sharma [mailto:preetis@lucent.com]=


> Sent: Wednesday, May 16, 2001 4:30 PM

> To: megaco@fore.com

> Subject: Use of CHOOSE as a =
TerminationID

> 

> 

> Hi All,

>     I have a very basic =
question:

> 

>     If CHOOSE ($)  is =
recieved as a TerminationID by the MG, 

> can the MG

> then assume that it

>     refers to an ephemeral =
termination. I tend to believe so 

> as the text

> in Section 7.2.1 says :

> 

>    "The Terminationis =
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."

> 

>      Also CHOOSE can =
be used for a TerminationID only in the ADD

> command.

> 

>      Hence I infer =
that CHOOSE implies an ephemeral Termination.

> 

>      Can someone =
please clarify this.

> 

>  Regards.

>  Preeti.

> 

> 

> 

> 





------_=_NextPart_001_01C0DEC6.9CFB0000--


From owner-megaco@fore.com  Thu May 17 09:51:32 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17566
	for ; Thu, 17 May 2001 09:51:31 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA21223;
	Thu, 17 May 2001 09:42:30 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA00821
	for megaco-list; Thu, 17 May 2001 09:37:16 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA00813
	for ; Thu, 17 May 2001 09:37:14 -0400 (EDT)
From: knayar@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA20521
	for ; Thu, 17 May 2001 09:36:54 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4HDZ0u20580;
	Thu, 17 May 2001 19:05:01 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A4F.004928A6 ; Thu, 17 May 2001 18:49:05 +0530
X-Lotus-FromDomain: HSS
To: "Tom-PT Taylor" 
cc: "'Rosen, Brian'" ,
        "Kevin Boyle" ,
        Dan Elbert , megaco@fore.com,
        "'Chuong Nguyen'" 
Message-ID: <65256A4F.004923B4.00@sandesh.hss.hns.com>
Date: Thu, 17 May 2001 18:56:27 +0530
Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's las
	 t Ca ll - MGC failure)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk



Hi Tom

I agree to your concern about keeping the polling load down to a tolerable
level.
But, I suppose the MG would send a "noop" SVC to MGC under the following
scenarios:
1.   MG timedout waiting for a reply from MGC.
     Normally, this case is handled by retransmission of the request before
interpretting that the MGC communication is lost.
     Some MG implementations might not want to resort to "noop" SVC at this
point and simply go on with recovery process after losing an MGC.
2.   MGC didnot send any request for a long time.
     MGC is not talking to this MG for a long time.....so anyhow this "noop"
should not contribute to load at MGC from this MG.
     Moreover, we can define a Base Root package property...."normalMGCIdleTime"
which indicates the timeout value for polling the MGC.
     This value would be read-write...provisioned at MG initially as well as
settable by MGC at run time....
     this will help MGC to indicate to MG whenever MGC wants to go idle so that
MG doesnot bother MGC by sending "noop" SVC.
3.......I could not think of any other scenario....

Well actually there is another positive feature....if we extend this "noop" SVC
to be sent by MGC to MG (and not just MG to MGC), we might be able to device a
method of polling MG from MGC perspective.....

-Kapil Nayar
Hughes Software Systems



It is essential that the MGC be able to control the process -- typically it
will have many MGs to manage, and must be able to keep the polling load down
to a tolerable level.  That's why I favour an event-based approach.

> -----Original Message-----
> From: knayar@hss.hns.com [mailto:knayar@hss.hns.com]
> Sent: Thursday, May 17, 2001 12:12 AM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]
> Cc: 'Rosen, Brian'; Boyle, Kevin [NCRTP:3Z70:EXCH]; Dan Elbert;
> megaco@fore.com; 'Chuong Nguyen'
> Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's
> las t Ca ll - MGC failure)
>
>
>
>
> Hi Tom, Brian
>
> Following this thread of discussion.....
> If we introduce an event "noop"...the MG is dependent upon
> MGC to enable this
> event (by sending the event descriptor with noop event).
> The very basic reason, as Dan and Chuong earlier pointed was
> that MG should be
> able to "poll" MGC.
> According to my understanding (please correct me if I am
> wrong) "polling" means
> an action to be initiated by the MG independent of MGC
> enabling an event or not.
> Hence, SVC (method - noop on root) seems to be a better idea
> than an event (noop
> on root).
>
> -Kapil Nayar
> Hughes Software Systems
>
>
>
>
> "Tom-PT Taylor"  on 05/16/2001 12:17:21 PM
>
> To:   "'Rosen, Brian'" , "Kevin Boyle"
>       , Dan Elbert 
> cc:   megaco@fore.com, "'Chuong Nguyen'"
>  (bcc:
>       Kapil Nayar/HSS)
>
> Subject:  RE: Polls of MGC (was RE: Implementors' Guide
> Update Editor's las t Ca
>       ll - MGC failure)
>
>
>
>
> I started to formulate a response along these lines myself
> yesterday.  I was
> worried about event side-effects: they stop signals, and if you're in
> Lockstep mode reporting of other events is delayed.  But
> there's a simple
> answer to that: have the event reported from ROOT or from a special
> termination like my NAS outgoing call termination.
>
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > Sent: Tuesday, May 15, 2001 7:57 AM
> > To: Taylor, Tom-PT [NORSE:B881:EXCH]; Boyle, Kevin
> [NCRTP:3Z70:EXCH];
> > Dan Elbert
> > Cc: megaco@fore.com; 'Chuong Nguyen'
> > Subject: RE: Polls of MGC (was RE: Implementors' Guide
> Update Editor's
> > las t Ca ll - MGC failure)
> >
> >
> > If you don't want to create the noop method, we can go
> > back to a package.
> >
> >
> >    PackageID: nop (0x00xx)
> >    Version: 1
> >    Extends: None
> >
> >    Description: No op event.  Can be used for testing or MG
> > poll of MGC.
> >
> > Properties
> >
> >    None
> >
> > Events
> >
> >    noop
> >    -----
> >    EventID:     noop (0x0001)
> >
> >    No op event
> >
> >    Events Descriptor Parameters:
> >
> >         Interval
> >         -------------
> >         ParameterID: delay (0x0001)
> >
> >         Description: delay in milliseconds to generate event.
> >          if not specified, MG may choose any value. 0 implies
> >          immediate response.
> >         Possible Values: INTEGER
> >
> > Brian
> >
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Tuesday, May 15, 2001 3:59 AM
> > To: Kevin Boyle; Dan Elbert
> > Cc: megaco@fore.com; 'Chuong Nguyen'
> > Subject: Polls of MGC (was RE: Implementors' Guide Update
> > Editor's last Ca
> > ll - MGC failure)
> >
> >
> > Let's follow through the logic here.  A restart implies loss
> > of state.  I
> > don't care whether you're talking ROOT or a real termination.
> >  It would be
> > inconsistent to declare restart of the latter a no-op.
> > I'd suggest the safest poll would be a NOTIFY with no events
> > and a bogus
> > requestID in it.  The MGC has to answer, even if only to
> > return an error,
> > but the NOTIFY doesn't change anything.
> > > -----Original Message-----
> > > From: Boyle, Kevin [NCRTP:3Z70:EXCH]
> > > Sent: Monday, May 14, 2001 12:50 PM
> > > To: Dan Elbert
> > > Cc: megaco@fore.com; 'Chuong Nguyen'
> > > Subject: Re: Implementors' Guide Update Editor's last Call -
> > > MGC failure
> > >
> > >
> > > Yes.  Root is a special case.  Restart on Root, if it is
> already in
> > > service, implies that the MG has gone out of service and
> > returned, and
> > > that anything that was happening previously is lost.  This
> > > was discussed
> > > on an earlier thread.
> > >
> > > Kevin
> > >
> > > Dan Elbert wrote:
> > >
> > > > Well I was just following the logic that a restart of a
> > termination
> > > > already in service is a noop. Is the root termination a
> > > special case ?
> > > > . The problem with poll vs restart is the same in any case.
> > > >
> > > > -----Original Message-----
> > > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > > > Sent: Monday, May 14, 2001 12:22 PM
> > > > To: megaco@fore.com
> > > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
> > > > failure
> > > >
> > > >
> > > > To me definitely NOT.
> > > > How will MGC knows that it is a registration restarts vs a poll?
> > > > Don't tell me that one can use Reason Code since Reason
> > > Code has to be
> > > > IANA registered
> > > > before it can be widely used.
> > > > But since anyone can register w/IANA at any time, it only
> > means that
> > > > it might not be supported by
> > > > everyone.
> > > >
> > > > Chuong
> > > >
> > > > Dan Elbert wrote:
> > > >
> > > > Another thing : Can I then use a restart of the "root"
> > > termination to
> > > > poll the MGC ? It seems to me more clean that to just use any
> > > > termination.
> > > >
> > > > -----Original Message-----
> > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > > Sent: Monday, May 14, 2001 12:00 PM
> > > > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen'
> > > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
> > > > failure
> > > >
> > > > I think that a restart of a termination that is already
> > in service
> > > > should be treated
> > > >
> > > > as a nop by an MGC.
> > > >
> > > > I have no objection to adding an explicit no-op method,
> > but I don't
> > > > think it is needed.
> > > >
> > > > Brian
> > > > -----Original Message-----
> > > >
> > > > From: Dan Elbert [mailto:DElbert@radvision.com]
> > > > Sent: Friday, May 11, 2001 5:57 PM
> > > > To: 'megaco@fore.com'; 'Chuong Nguyen'
> > > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
> > > > failure
> > > > Using a fully specified terminationID can disrupt the
> > > operation of the
> > > > termination (for example if the termination is in a call).
> > > >
> > > > It's not clear what a "bogus" termination is, if the MGC
> > receives a
> > > > SVC from an MG termination it can assume that this
> > > termination is real
> > > > and start sending audits or commands.
> > > >
> > > > Yes, by poll I mean some type of heartbeat as the MG needs
> > > to know if
> > > > the MGC is alive.
> > > >
> > > > Brian Rosen suggested in the past to use SVC with Restart
> > method for
> > > > this purpose, I don't think that there was any mantion if
> > > this should
> > > > be done with id=root or other.
> > > >
> > > > Dan
> > > > -----Original Message-----
> > > >
> > > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > > > Sent: Friday, May 11, 2001 5:38 PM
> > > > To: megaco@fore.com
> > > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
> > > > failure
> > > >
> > > > The intend was not to use ROOT but a fully specified
> > > terminationID or
> > > > even better a
> > > > known invalid terminationID (A bogus terminationID that
> > the sender
> > > > knows is not valid and is
> > > > used specifically for heartbeat purpose).  The idea is to
> > get some
> > > > kind of responses.
> > > >
> > > > "poll" do you mean heartbeat like msg to from MG to MGC
> > or something
> > > > else here.
> > > >
> > > > Where did you see that Restart w/ROOT is used as a
> > heartbeat/poll?
> > > >
> > > > Chuong
> > > >
> > > > Dan Elbert wrote:
> > > > Hi
> > > >
> > > > After reviewing the issue of MGC failure ( when the MG is
> > connected
> > > > trough UDP ) I believe that there is no satisfactory way
> > > for the MG to
> > > > poll the MGC to see if the MGC is still alive. Using a
> > ServiceChange
> > > > with "Restart" method and termination id of "root" may
> > cause the MGC
> > > > to assume that the MG restarted and can affect the state of
> > > a call in
> > > > progress.
> > > >
> > > > I think that it would be good to add a ServiceChange
> > method "noop" :
> > > >
> > > > Noop : Can be used by the MG (with unreliable protocols)
> > to obtain a
> > > > response from the MGC or detect a communication failure. When
> > > > receiving this SVC the MGC should take no action other
> > that reply.
> > > >
> > > > If this is not acceptable, then I think that some
> > clarification is
> > > > needed as when a SVC with restart method should be
> > considered "noop"
> > > > by the MGC.
> > > >
> > > > Dan Elbert
> > > >
> > > > RADVISION
> > > >
> > > > --
> > > >
> > > >   Alcatel USA, Inc             Internet:
> > > Chuong.Nguyen@usa.alcatel.com
> > > >
> > > >   1000 Coit Road Plano, Texas 75075           Phone:
> > > (972) 519-4613
> > > >
> > > >   **** The opinions expressed are not those of Alcatel
> > USA, Inc ****
> > > >
> > > > --
> > > >
> > > >   Alcatel USA, Inc             Internet:
> > > Chuong.Nguyen@usa.alcatel.com
> > > >
> > > >   1000 Coit Road Plano, Texas 75075           Phone:
> > > (972) 519-4613
> > > >
> > > >   **** The opinions expressed are not those of Alcatel
> > USA, Inc ****
> > > >
> > >
> > >
> >
>
>




From owner-megaco@fore.com  Thu May 17 10:00:03 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17791
	for ; Thu, 17 May 2001 10:00:03 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA22169;
	Thu, 17 May 2001 09:50:30 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA04623
	for megaco-list; Thu, 17 May 2001 09:48:29 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA04494
	for ; Thu, 17 May 2001 09:48:25 -0400 (EDT)
Received: from ns02.newbridge.com (ns02.newbridge.com [192.75.23.75])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id JAA21893
	for ; Thu, 17 May 2001 09:48:07 -0400 (EDT)
Received: (qmail 1419 invoked from network); 17 May 2001 13:46:18 -0000
Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76)
  by ns02.newbridge.com with SMTP; 17 May 2001 13:46:18 -0000
Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for megaco@fore.com; Thu, 17 May 2001 09:44:03 -0400
Received: from alcatel.com ([138.120.45.84]) by kanmail01.ca.newbridge.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAA15B3
          for ; Thu, 17 May 2001 09:44:02 -0400
Message-Id: <3B03D5A1.45F53882@alcatel.com>
Date: Thu, 17 May 2001 09:44:01 -0400
From: Paul Rheaume 
Organization: Alcatel CID
X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: MEGACO 
Subject: Megaco Interop using Voice over ATM
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

List,

We are interrested in taking our Trunking Gateways solution using Voice
over ATM to the upcoming Megaco interop. But first we want to know if
other vendors of this type of equipment will be there.

Anybody out there? Please respond to the list indicating your interrest.

Regards,
Paul


From owner-megaco@fore.com  Thu May 17 10:08:52 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17966
	for ; Thu, 17 May 2001 10:08:52 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23432;
	Thu, 17 May 2001 10:02:53 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA08131
	for megaco-list; Thu, 17 May 2001 10:00:42 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08122
	for ; Thu, 17 May 2001 10:00:40 -0400 (EDT)
From: knayar@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23139
	for ; Thu, 17 May 2001 10:00:33 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4HE1S421337;
	Thu, 17 May 2001 19:31:28 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A4F.004B9427 ; Thu, 17 May 2001 19:15:31 +0530
X-Lotus-FromDomain: HSS
To: "Tom-PT Taylor" 
cc: megaco@fore.com
Message-ID: <65256A4F.004B7805.00@sandesh.hss.hns.com>
Date: Thu, 17 May 2001 19:17:48 +0530
Subject: TDM support in SDP
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk



Hi Tom

I had a query on the interpretation of the MEGACO termination Id as per the new
draft.

It talks about a TDM bearer comprising of 64kbit/s channel(s) and addressing of
TDM bearers thru' termination id mecahnism in MEGACO. So, does that mean that a
physical termination in MEGACO may comprise of multiple 64kbps channels ?
But, then the draft also mentions while describing the NUL addressing scheme,
that MEGACO assumes each bearer channel (i.e., 64kbps) to be represented by a
termination id and information about multiple channels to be located in the MUX
descriptor.
Can you clarify.....
and also if multiple 64kbps channels are represented by one termination id, is
this a static mapping provisioned at the MG as well as the MGC.

Thanks,
-Kapil Nayar
Hughes Software Systems




From owner-megaco@fore.com  Thu May 17 10:20:36 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18191
	for ; Thu, 17 May 2001 10:20:35 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24598;
	Thu, 17 May 2001 10:13:09 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA10833
	for megaco-list; Thu, 17 May 2001 10:09:52 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10826
	for ; Thu, 17 May 2001 10:09:51 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24119
	for ; Thu, 17 May 2001 10:09:46 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1])
	by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4HE9hK04992
	for ; Thu, 17 May 2001 10:09:43 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4HE9gH04971
	for ; Thu, 17 May 2001 10:09:42 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id KAA18370; Thu, 17 May 2001 10:09:40 -0400 (EDT)
From: Preeti Sharma 
Cc: "'Preeti Sharma'" , megaco@fore.com
Received: from wink.ho.lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id KAA18330; Thu, 17 May 2001 10:09:35 -0400 (EDT)
Message-ID: <3B03D2BF.EB652251@wink.ho.lucent.com>
Date: Thu, 17 May 2001 09:31:44 -0400
Original-From: Preeti Sharma 
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD compaq  (Win98; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Tom-PT Taylor 
Original-CC: "'Preeti Sharma'" , megaco@fore.com
Subject: Re: Use of CHOOSE as a TerminationID
References: <28560036253BD41191A10000F8BCBD110250CB63@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Why would I use CHOOSE embedded in a partial name, wouldn't I use
WILDCARD instead ?
 Also I can use CHOOSE only for an ADD command.
 So would I say :
  1.   Add = xyz/* {
    or
 2.    Add =  xyz/$ {

 if say I want to choose a circuit from a trunk group "xyz".
 If the answer is 1. then WILDCARD works  like " choose from the
existing pool".
 CHOOSE would work more like "Create a new one".

 And since ephemeral terminations are the only ones being created and
destroyed CHOOSE
 should be used for them only.

 Preeti.

Tom-PT Taylor wrote:

>
>
> Certainly when the text you quote was drafted, people had ephemerals
> in mind.  In theory if Local and Remote described a TDM circuit, the
> MG would probably have to choose from amongst the TDM circuits it
> supported, but this doesn't seem too useful unless all the circuits go
> to the same destination.
>
> A CHOOSE is embedded in a partial name, of course, is a reasonable way
> to ask the MG to choose from a specific set of terminations, whether
> that set be provisioned or ephemeral.
>
> > -----Original Message-----
> > From: Preeti Sharma [mailto:preetis@lucent.com]
> > Sent: Wednesday, May 16, 2001 4:30 PM
> > To: megaco@fore.com
> > Subject: Use of CHOOSE as a TerminationID
> >
> >
> > Hi All,
> >     I have a very basic question:
> >
> >     If CHOOSE ($)  is recieved as a TerminationID by the MG,
> > can the MG
> > then assume that it
> >     refers to an ephemeral termination. I tend to believe so
> > as the text
> > in Section 7.2.1 says :
> >
> >    "The Terminationis 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."
> >
> >      Also CHOOSE can be used for a TerminationID only in the ADD
> > command.
> >
> >      Hence I infer that CHOOSE implies an ephemeral Termination.
> >
> >      Can someone please clarify this.
> >
> >  Regards.
> >  Preeti.
> >
> >
> >
> >



From owner-megaco@fore.com  Thu May 17 10:30:20 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18356
	for ; Thu, 17 May 2001 10:30:19 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA25851;
	Thu, 17 May 2001 10:24:23 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA15351
	for megaco-list; Thu, 17 May 2001 10:22:19 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15343
	for ; Thu, 17 May 2001 10:22:18 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 17 May 2001 10:21:45 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F62D@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Preeti Sharma'" 
Cc: megaco@fore.com
Subject: RE: Use of CHOOSE as a TerminationID
Date: Thu, 17 May 2001 10:22:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Because WILDCARD may get you multiple terminationIDs, and thus
result in inadvertent behavior, while CHOOSE gets you one.

If you have terminationIds xyx/1, xyz/2 and xyz3, then
Add=T*
results in xyx/1, xyz/2 and xyz3 all being added to the context.
Add=T$
results in one of xyx/1, xyz/2 and xyz3 (choice is up to the MG) 
being added.

Brian

> -----Original Message-----
> From: Preeti Sharma [mailto:preetis@lucent.com]
> Sent: Thursday, May 17, 2001 9:32 AM
> To: Tom-PT Taylor
> Cc: 'Preeti Sharma'; megaco@fore.com
> Subject: Re: Use of CHOOSE as a TerminationID
> 
> 
> Why would I use CHOOSE embedded in a partial name, wouldn't I use
> WILDCARD instead ?
>  Also I can use CHOOSE only for an ADD command.
>  So would I say :
>   1.   Add = xyz/* {
>     or
>  2.    Add =  xyz/$ {
> 
>  if say I want to choose a circuit from a trunk group "xyz".
>  If the answer is 1. then WILDCARD works  like " choose from the
> existing pool".
>  CHOOSE would work more like "Create a new one".
> 
>  And since ephemeral terminations are the only ones being created and
> destroyed CHOOSE
>  should be used for them only.
> 
>  Preeti.
> 
> Tom-PT Taylor wrote:
> 
> >
> >
> > Certainly when the text you quote was drafted, people had ephemerals
> > in mind.  In theory if Local and Remote described a TDM circuit, the
> > MG would probably have to choose from amongst the TDM circuits it
> > supported, but this doesn't seem too useful unless all the 
> circuits go
> > to the same destination.
> >
> > A CHOOSE is embedded in a partial name, of course, is a 
> reasonable way
> > to ask the MG to choose from a specific set of terminations, whether
> > that set be provisioned or ephemeral.
> >
> > > -----Original Message-----
> > > From: Preeti Sharma [mailto:preetis@lucent.com]
> > > Sent: Wednesday, May 16, 2001 4:30 PM
> > > To: megaco@fore.com
> > > Subject: Use of CHOOSE as a TerminationID
> > >
> > >
> > > Hi All,
> > >     I have a very basic question:
> > >
> > >     If CHOOSE ($)  is recieved as a TerminationID by the MG,
> > > can the MG
> > > then assume that it
> > >     refers to an ephemeral termination. I tend to believe so
> > > as the text
> > > in Section 7.2.1 says :
> > >
> > >    "The Terminationis 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."
> > >
> > >      Also CHOOSE can be used for a TerminationID only in the ADD
> > > command.
> > >
> > >      Hence I infer that CHOOSE implies an ephemeral Termination.
> > >
> > >      Can someone please clarify this.
> > >
> > >  Regards.
> > >  Preeti.
> > >
> > >
> > >
> > >
> 


From owner-megaco@fore.com  Thu May 17 10:44:35 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18805
	for ; Thu, 17 May 2001 10:44:35 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26420;
	Thu, 17 May 2001 10:28:18 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA16309
	for megaco-list; Thu, 17 May 2001 10:25:39 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16298
	for ; Thu, 17 May 2001 10:25:36 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26031
	for ; Thu, 17 May 2001 10:25:31 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1])
	by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4HEPWK23119
	for ; Thu, 17 May 2001 10:25:32 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4HEPVH23099
	for ; Thu, 17 May 2001 10:25:32 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id KAA18598; Thu, 17 May 2001 10:25:28 -0400 (EDT)
From: Preeti Sharma 
Cc: "'Preeti Sharma'" , megaco@fore.com
Received: from wink.ho.lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id KAA18574; Thu, 17 May 2001 10:25:22 -0400 (EDT)
Message-ID: <3B03D66C.F267D5A7@wink.ho.lucent.com>
Date: Thu, 17 May 2001 09:47:25 -0400
Original-From: Preeti Sharma 
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD compaq  (Win98; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: "Rosen, Brian" 
Original-CC: "'Preeti Sharma'" , megaco@fore.com
Subject: Re: Use of CHOOSE as a TerminationID
References: <4FBEA8857476D311A03300204840E1CF01A6F62D@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Thanks, didn't think of that...
 Preeti.

"Rosen, Brian" wrote:

> Because WILDCARD may get you multiple terminationIDs, and thus
> result in inadvertent behavior, while CHOOSE gets you one.
>
> If you have terminationIds xyx/1, xyz/2 and xyz3, then
> Add=T*
> results in xyx/1, xyz/2 and xyz3 all being added to the context.
> Add=T$
> results in one of xyx/1, xyz/2 and xyz3 (choice is up to the MG)
> being added.
>
> Brian
>
> > -----Original Message-----
> > From: Preeti Sharma [mailto:preetis@lucent.com]
> > Sent: Thursday, May 17, 2001 9:32 AM
> > To: Tom-PT Taylor
> > Cc: 'Preeti Sharma'; megaco@fore.com
> > Subject: Re: Use of CHOOSE as a TerminationID
> >
> >
> > Why would I use CHOOSE embedded in a partial name, wouldn't I use
> > WILDCARD instead ?
> >  Also I can use CHOOSE only for an ADD command.
> >  So would I say :
> >   1.   Add = xyz/* {
> >     or
> >  2.    Add =  xyz/$ {
> >
> >  if say I want to choose a circuit from a trunk group "xyz".
> >  If the answer is 1. then WILDCARD works  like " choose from the
> > existing pool".
> >  CHOOSE would work more like "Create a new one".
> >
> >  And since ephemeral terminations are the only ones being created and
> > destroyed CHOOSE
> >  should be used for them only.
> >
> >  Preeti.
> >
> > Tom-PT Taylor wrote:
> >
> > >
> > >
> > > Certainly when the text you quote was drafted, people had ephemerals
> > > in mind.  In theory if Local and Remote described a TDM circuit, the
> > > MG would probably have to choose from amongst the TDM circuits it
> > > supported, but this doesn't seem too useful unless all the
> > circuits go
> > > to the same destination.
> > >
> > > A CHOOSE is embedded in a partial name, of course, is a
> > reasonable way
> > > to ask the MG to choose from a specific set of terminations, whether
> > > that set be provisioned or ephemeral.
> > >
> > > > -----Original Message-----
> > > > From: Preeti Sharma [mailto:preetis@lucent.com]
> > > > Sent: Wednesday, May 16, 2001 4:30 PM
> > > > To: megaco@fore.com
> > > > Subject: Use of CHOOSE as a TerminationID
> > > >
> > > >
> > > > Hi All,
> > > >     I have a very basic question:
> > > >
> > > >     If CHOOSE ($)  is recieved as a TerminationID by the MG,
> > > > can the MG
> > > > then assume that it
> > > >     refers to an ephemeral termination. I tend to believe so
> > > > as the text
> > > > in Section 7.2.1 says :
> > > >
> > > >    "The Terminationis 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."
> > > >
> > > >      Also CHOOSE can be used for a TerminationID only in the ADD
> > > > command.
> > > >
> > > >      Hence I infer that CHOOSE implies an ephemeral Termination.
> > > >
> > > >      Can someone please clarify this.
> > > >
> > > >  Regards.
> > > >  Preeti.
> > > >
> > > >
> > > >
> > > >
> >



From owner-megaco@fore.com  Thu May 17 10:46:14 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18835
	for ; Thu, 17 May 2001 10:46:13 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26949;
	Thu, 17 May 2001 10:32:31 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA17880
	for megaco-list; Thu, 17 May 2001 10:30:26 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA17874
	for ; Thu, 17 May 2001 10:30:25 -0400 (EDT)
Received: from web12902.mail.yahoo.com (web12902.mail.yahoo.com [216.136.174.69])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA26695
	for ; Thu, 17 May 2001 10:30:19 -0400 (EDT)
Message-ID: <20010517143020.9039.qmail@web12902.mail.yahoo.com>
Received: from [203.190.136.98] by web12902.mail.yahoo.com; Thu, 17 May 2001 15:30:20 BST
Date: Thu, 17 May 2001 15:30:20 +0100 (BST)
From: =?iso-8859-1?q?Sarika=20Gupta?= 
Subject: MG-MGC failure query
To: megaco@fore.com
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi,
There is a little confusion over ServiceChange message
with "failover" method.
In H248 Section 7.2.8, about failover it is written
"sent from MG to MGC to indicate the primary MG is out
of service and a secondary MG is taking over".

However in the same doc Section 11.5 (Failure of MGC),
it is written that in case the MG is not able to
contact its MGC, it sends a ServiceChange message with
"failover" method to the secondary MGC with "MGC
Impending Failure".
Can somebody clarify this??

Regards
Sarika

____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie


From owner-megaco@fore.com  Thu May 17 10:50:08 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18953
	for ; Thu, 17 May 2001 10:50:07 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA28006;
	Thu, 17 May 2001 10:44:13 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA20214
	for megaco-list; Thu, 17 May 2001 10:34:40 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20181
	for ; Thu, 17 May 2001 10:34:35 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA27179
	for ; Thu, 17 May 2001 10:34:30 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4HEYVG02641
	for ; Thu, 17 May 2001 10:34:31 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4HEYU402622
	for ; Thu, 17 May 2001 10:34:30 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id KAA18793; Thu, 17 May 2001 10:34:28 -0400 (EDT)
From: Preeti Sharma 
Cc: "'Preeti Sharma'" , megaco@fore.com,
        Brian.Rosen@marconi.com
Received: from wink.ho.lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id KAA18770; Thu, 17 May 2001 10:34:27 -0400 (EDT)
Message-ID: <3B03D88A.428CD179@wink.ho.lucent.com>
Date: Thu, 17 May 2001 09:56:26 -0400
Original-From: Preeti Sharma 
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD compaq  (Win98; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Tom-PT Taylor 
Original-CC: "'Preeti Sharma'" , megaco@fore.com,
        Brian.Rosen@marconi.com
Subject: Re: Use of CHOOSE as a TerminationID
References: <28560036253BD41191A10000F8BCBD110250CB63@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

In that case the text in Section 7.2.1 is in a way misleading.

Tom-PT Taylor wrote:

>
>
> Certainly when the text you quote was drafted, people had ephemerals
> in mind.  In theory if Local and Remote described a TDM circuit, the
> MG would probably have to choose from amongst the TDM circuits it
> supported, but this doesn't seem too useful unless all the circuits go
> to the same destination.
>
> A CHOOSE is embedded in a partial name, of course, is a reasonable way
> to ask the MG to choose from a specific set of terminations, whether
> that set be provisioned or ephemeral.
>
> > -----Original Message-----
> > From: Preeti Sharma [mailto:preetis@lucent.com]
> > Sent: Wednesday, May 16, 2001 4:30 PM
> > To: megaco@fore.com
> > Subject: Use of CHOOSE as a TerminationID
> >
> >
> > Hi All,
> >     I have a very basic question:
> >
> >     If CHOOSE ($)  is recieved as a TerminationID by the MG,
> > can the MG
> > then assume that it
> >     refers to an ephemeral termination. I tend to believe so
> > as the text
> > in Section 7.2.1 says :
> >
> >    "The Terminationis 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."
> >
> >      Also CHOOSE can be used for a TerminationID only in the ADD
> > command.
> >
> >      Hence I infer that CHOOSE implies an ephemeral Termination.
> >
> >      Can someone please clarify this.
> >
> >  Regards.
> >  Preeti.
> >
> >
> >
> >



From owner-megaco@fore.com  Thu May 17 14:24:21 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24166
	for ; Thu, 17 May 2001 14:24:16 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA15464;
	Thu, 17 May 2001 14:18:26 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA18602
	for megaco-list; Thu, 17 May 2001 14:15:15 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA18592
	for ; Thu, 17 May 2001 14:15:13 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA15126
	for ; Thu, 17 May 2001 14:15:08 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4HIF9L11222
	for ; Thu, 17 May 2001 14:15:09 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4HIF9b11213
	for ; Thu, 17 May 2001 14:15:09 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id OAA04702; Thu, 17 May 2001 14:15:07 -0400 (EDT)
Cc: "'Preeti Sharma'" , megaco@fore.com
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id OAA04675; Thu, 17 May 2001 14:15:04 -0400 (EDT)
Message-ID: <3B0414B2.EC056EF@lucent.com>
Date: Thu, 17 May 2001 14:13:06 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom-PT Taylor 
Original-CC: "'Preeti Sharma'" , megaco@fore.com
Subject: Re: Use of CHOOSE as a TerminationID
References: <28560036253BD41191A10000F8BCBD110250CB63@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



The text Preeti quoted has already been replaced in the IG;
the new text does not imply that CHOOSE implies ephemeral.



I've always thought that this CHOOSE syntax leaves a lot
of room for error & causes more work than the "elegance"
is worth.  To support the protocol, an MG must handle CHOOSE 
and can not assume it means ephemeral (unless perhaps a profile 
says differently).

So the MG must DEDUCE the type of termination intended from clues
in the descriptors, with no guarantee there will be enough
clues to narrow it to one type!  Why don't we just have the 
MGC *TELL* the MG what TYPE of termination it wants instead 
of making the MG *DEDUCE* it?  

I understand that it's desired that the protocol be transport 
independent, but how is saying { Type=rtp } different from
setting a bunch of parameters that imply it?

I've asked this before and the answer is that the termination
can be an "empty container" and you won't know the TYPE until
it's filled to a certain point.

Well the MG has to return a NAME for the termination after the 
first CHOOSE reference.  And naming the termination will often
require mapping the type and sometimes more than that.  The schema 
itself might make the termination type obvious (RTP/1, TDM/2, etc.).  
Even if it's not obvious from the schema, the MGC has to know 
certain types of physical mappings (that A444 is the POTS line 
to my house).


-troy


> Tom-PT Taylor wrote:
> 
> Certainly when the text you quote was drafted, people had ephemerals in
> mind.  In theory if Local and Remote described a TDM circuit, the MG would
> probably have to choose from amongst the TDM circuits it supported, but this
> doesn't seem too useful unless all the circuits go to the same destination.
> 
> A CHOOSE is embedded in a partial name, of course, is a reasonable way to ask
> the MG to choose from a specific set of terminations, whether that set be
> provisioned or ephemeral.
> 
> > -----Original Message-----
> > From: Preeti Sharma [mailto:preetis@lucent.com]
> > Sent: Wednesday, May 16, 2001 4:30 PM
> > To: megaco@fore.com
> > Subject: Use of CHOOSE as a TerminationID
> >
> >
> > Hi All,
> >     I have a very basic question:
> >
> >     If CHOOSE ($)  is recieved as a TerminationID by the MG,
> > can the MG
> > then assume that it
> >     refers to an ephemeral termination. I tend to believe so
> > as the text
> > in Section 7.2.1 says :
> >
> >    "The Terminationis 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."
> >
> >      Also CHOOSE can be used for a TerminationID only in the ADD
> > command.
> >
> >      Hence I infer that CHOOSE implies an ephemeral Termination.
> >
> >      Can someone please clarify this.
> >
> >  Regards.
> >  Preeti.
> >
> >
> >
> >


From owner-megaco@fore.com  Thu May 17 14:32:26 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24281
	for ; Thu, 17 May 2001 14:32:26 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA16045;
	Thu, 17 May 2001 14:25:23 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA20308
	for megaco-list; Thu, 17 May 2001 14:23:20 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA20287
	for ; Thu, 17 May 2001 14:23:17 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA15839
	for ; Thu, 17 May 2001 14:23:12 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Thu, 17 May 2001 13:23:46 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD949458110E7@RADVPOST>
From: Dan Elbert 
To: megaco@fore.com
Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's las
	 t Ca ll - MGC failure)
Date: Thu, 17 May 2001 13:23:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

I think that using the "noop" SVC and having a Base Root package property to
control the polling is a good idea .

Dan Elbert
RADVISION

-----Original Message-----
From: knayar@hss.hns.com [mailto:knayar@hss.hns.com]
Sent: Thursday, May 17, 2001 9:26 AM
To: Tom-PT Taylor
Cc: 'Rosen, Brian'; Kevin Boyle; Dan Elbert; megaco@fore.com; 'Chuong
Nguyen'
Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's las t
Ca ll - MGC failure)


Hi Tom

I agree to your concern about keeping the polling load down to a tolerable
level.
But, I suppose the MG would send a "noop" SVC to MGC under the following
scenarios:
1.   MG timedout waiting for a reply from MGC.
     Normally, this case is handled by retransmission of the request before
interpretting that the MGC communication is lost.
     Some MG implementations might not want to resort to "noop" SVC at this
point and simply go on with recovery process after losing an MGC.
2.   MGC didnot send any request for a long time.
     MGC is not talking to this MG for a long time.....so anyhow this "noop"
should not contribute to load at MGC from this MG.
     Moreover, we can define a Base Root package
property...."normalMGCIdleTime"
which indicates the timeout value for polling the MGC.
     This value would be read-write...provisioned at MG initially as well as
settable by MGC at run time....
     this will help MGC to indicate to MG whenever MGC wants to go idle so
that
MG doesnot bother MGC by sending "noop" SVC.
3.......I could not think of any other scenario....

Well actually there is another positive feature....if we extend this "noop"
SVC
to be sent by MGC to MG (and not just MG to MGC), we might be able to device
a
method of polling MG from MGC perspective.....

-Kapil Nayar
Hughes Software Systems



It is essential that the MGC be able to control the process -- typically it
will have many MGs to manage, and must be able to keep the polling load down
to a tolerable level.  That's why I favour an event-based approach.

> -----Original Message-----
> From: knayar@hss.hns.com [mailto:knayar@hss.hns.com]
> Sent: Thursday, May 17, 2001 12:12 AM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]
> Cc: 'Rosen, Brian'; Boyle, Kevin [NCRTP:3Z70:EXCH]; Dan Elbert;
> megaco@fore.com; 'Chuong Nguyen'
> Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's
> las t Ca ll - MGC failure)
>
>
>
>
> Hi Tom, Brian
>
> Following this thread of discussion.....
> If we introduce an event "noop"...the MG is dependent upon
> MGC to enable this
> event (by sending the event descriptor with noop event).
> The very basic reason, as Dan and Chuong earlier pointed was
> that MG should be
> able to "poll" MGC.
> According to my understanding (please correct me if I am
> wrong) "polling" means
> an action to be initiated by the MG independent of MGC
> enabling an event or not.
> Hence, SVC (method - noop on root) seems to be a better idea
> than an event (noop
> on root).
>
> -Kapil Nayar
> Hughes Software Systems
>
>
>
>
> "Tom-PT Taylor"  on 05/16/2001 12:17:21 PM
>
> To:   "'Rosen, Brian'" , "Kevin Boyle"
>       , Dan Elbert 
> cc:   megaco@fore.com, "'Chuong Nguyen'"
>  (bcc:
>       Kapil Nayar/HSS)
>
> Subject:  RE: Polls of MGC (was RE: Implementors' Guide
> Update Editor's las t Ca
>       ll - MGC failure)
>
>
>
>
> I started to formulate a response along these lines myself
> yesterday.  I was
> worried about event side-effects: they stop signals, and if you're in
> Lockstep mode reporting of other events is delayed.  But
> there's a simple
> answer to that: have the event reported from ROOT or from a special
> termination like my NAS outgoing call termination.
>
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > Sent: Tuesday, May 15, 2001 7:57 AM
> > To: Taylor, Tom-PT [NORSE:B881:EXCH]; Boyle, Kevin
> [NCRTP:3Z70:EXCH];
> > Dan Elbert
> > Cc: megaco@fore.com; 'Chuong Nguyen'
> > Subject: RE: Polls of MGC (was RE: Implementors' Guide
> Update Editor's
> > las t Ca ll - MGC failure)
> >
> >
> > If you don't want to create the noop method, we can go
> > back to a package.
> >
> >
> >    PackageID: nop (0x00xx)
> >    Version: 1
> >    Extends: None
> >
> >    Description: No op event.  Can be used for testing or MG
> > poll of MGC.
> >
> > Properties
> >
> >    None
> >
> > Events
> >
> >    noop
> >    -----
> >    EventID:     noop (0x0001)
> >
> >    No op event
> >
> >    Events Descriptor Parameters:
> >
> >         Interval
> >         -------------
> >         ParameterID: delay (0x0001)
> >
> >         Description: delay in milliseconds to generate event.
> >          if not specified, MG may choose any value. 0 implies
> >          immediate response.
> >         Possible Values: INTEGER
> >
> > Brian
> >
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Tuesday, May 15, 2001 3:59 AM
> > To: Kevin Boyle; Dan Elbert
> > Cc: megaco@fore.com; 'Chuong Nguyen'
> > Subject: Polls of MGC (was RE: Implementors' Guide Update
> > Editor's last Ca
> > ll - MGC failure)
> >
> >
> > Let's follow through the logic here.  A restart implies loss
> > of state.  I
> > don't care whether you're talking ROOT or a real termination.
> >  It would be
> > inconsistent to declare restart of the latter a no-op.
> > I'd suggest the safest poll would be a NOTIFY with no events
> > and a bogus
> > requestID in it.  The MGC has to answer, even if only to
> > return an error,
> > but the NOTIFY doesn't change anything.
> > > -----Original Message-----
> > > From: Boyle, Kevin [NCRTP:3Z70:EXCH]
> > > Sent: Monday, May 14, 2001 12:50 PM
> > > To: Dan Elbert
> > > Cc: megaco@fore.com; 'Chuong Nguyen'
> > > Subject: Re: Implementors' Guide Update Editor's last Call -
> > > MGC failure
> > >
> > >
> > > Yes.  Root is a special case.  Restart on Root, if it is
> already in
> > > service, implies that the MG has gone out of service and
> > returned, and
> > > that anything that was happening previously is lost.  This
> > > was discussed
> > > on an earlier thread.
> > >
> > > Kevin
> > >
> > > Dan Elbert wrote:
> > >
> > > > Well I was just following the logic that a restart of a
> > termination
> > > > already in service is a noop. Is the root termination a
> > > special case ?
> > > > . The problem with poll vs restart is the same in any case.
> > > >
> > > > -----Original Message-----
> > > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > > > Sent: Monday, May 14, 2001 12:22 PM
> > > > To: megaco@fore.com
> > > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
> > > > failure
> > > >
> > > >
> > > > To me definitely NOT.
> > > > How will MGC knows that it is a registration restarts vs a poll?
> > > > Don't tell me that one can use Reason Code since Reason
> > > Code has to be
> > > > IANA registered
> > > > before it can be widely used.
> > > > But since anyone can register w/IANA at any time, it only
> > means that
> > > > it might not be supported by
> > > > everyone.
> > > >
> > > > Chuong
> > > >
> > > > Dan Elbert wrote:
> > > >
> > > > Another thing : Can I then use a restart of the "root"
> > > termination to
> > > > poll the MGC ? It seems to me more clean that to just use any
> > > > termination.
> > > >
> > > > -----Original Message-----
> > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > > Sent: Monday, May 14, 2001 12:00 PM
> > > > To: 'Dan Elbert'; 'megaco@fore.com'; 'Chuong Nguyen'
> > > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
> > > > failure
> > > >
> > > > I think that a restart of a termination that is already
> > in service
> > > > should be treated
> > > >
> > > > as a nop by an MGC.
> > > >
> > > > I have no objection to adding an explicit no-op method,
> > but I don't
> > > > think it is needed.
> > > >
> > > > Brian
> > > > -----Original Message-----
> > > >
> > > > From: Dan Elbert [mailto:DElbert@radvision.com]
> > > > Sent: Friday, May 11, 2001 5:57 PM
> > > > To: 'megaco@fore.com'; 'Chuong Nguyen'
> > > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC
> > > > failure
> > > > Using a fully specified terminationID can disrupt the
> > > operation of the
> > > > termination (for example if the termination is in a call).
> > > >
> > > > It's not clear what a "bogus" termination is, if the MGC
> > receives a
> > > > SVC from an MG termination it can assume that this
> > > termination is real
> > > > and start sending audits or commands.
> > > >
> > > > Yes, by poll I mean some type of heartbeat as the MG needs
> > > to know if
> > > > the MGC is alive.
> > > >
> > > > Brian Rosen suggested in the past to use SVC with Restart
> > method for
> > > > this purpose, I don't think that there was any mantion if
> > > this should
> > > > be done with id=root or other.
> > > >
> > > > Dan
> > > > -----Original Message-----
> > > >
> > > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > > > Sent: Friday, May 11, 2001 5:38 PM
> > > > To: megaco@fore.com
> > > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC
> > > > failure
> > > >
> > > > The intend was not to use ROOT but a fully specified
> > > terminationID or
> > > > even better a
> > > > known invalid terminationID (A bogus terminationID that
> > the sender
> > > > knows is not valid and is
> > > > used specifically for heartbeat purpose).  The idea is to
> > get some
> > > > kind of responses.
> > > >
> > > > "poll" do you mean heartbeat like msg to from MG to MGC
> > or something
> > > > else here.
> > > >
> > > > Where did you see that Restart w/ROOT is used as a
> > heartbeat/poll?
> > > >
> > > > Chuong
> > > >
> > > > Dan Elbert wrote:
> > > > Hi
> > > >
> > > > After reviewing the issue of MGC failure ( when the MG is
> > connected
> > > > trough UDP ) I believe that there is no satisfactory way
> > > for the MG to
> > > > poll the MGC to see if the MGC is still alive. Using a
> > ServiceChange
> > > > with "Restart" method and termination id of "root" may
> > cause the MGC
> > > > to assume that the MG restarted and can affect the state of
> > > a call in
> > > > progress.
> > > >
> > > > I think that it would be good to add a ServiceChange
> > method "noop" :
> > > >
> > > > Noop : Can be used by the MG (with unreliable protocols)
> > to obtain a
> > > > response from the MGC or detect a communication failure. When
> > > > receiving this SVC the MGC should take no action other
> > that reply.
> > > >
> > > > If this is not acceptable, then I think that some
> > clarification is
> > > > needed as when a SVC with restart method should be
> > considered "noop"
> > > > by the MGC.
> > > >
> > > > Dan Elbert
> > > >
> > > > RADVISION
> > > >
> > > > --
> > > >
> > > >   Alcatel USA, Inc             Internet:
> > > Chuong.Nguyen@usa.alcatel.com
> > > >
> > > >   1000 Coit Road Plano, Texas 75075           Phone:
> > > (972) 519-4613
> > > >
> > > >   **** The opinions expressed are not those of Alcatel
> > USA, Inc ****
> > > >
> > > > --
> > > >
> > > >   Alcatel USA, Inc             Internet:
> > > Chuong.Nguyen@usa.alcatel.com
> > > >
> > > >   1000 Coit Road Plano, Texas 75075           Phone:
> > > (972) 519-4613
> > > >
> > > >   **** The opinions expressed are not those of Alcatel
> > USA, Inc ****
> > > >
> > >
> > >
> >
>
>


From owner-megaco@fore.com  Thu May 17 16:17:48 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26322
	for ; Thu, 17 May 2001 16:17:48 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA24894;
	Thu, 17 May 2001 16:12:00 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA17059
	for megaco-list; Thu, 17 May 2001 16:07:55 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA17054
	for ; Thu, 17 May 2001 16:07:53 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id QAA24425
	for ; Thu, 17 May 2001 16:07:48 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id QAA17591; Thu, 17 May 2001 16:07:44 -0400
Received: from ztcfd004.ca.nortel.com by zcars04e.nortelnetworks.com;
          Thu, 17 May 2001 16:07:30 -0400
Received: by ztcfd004.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 17 May 2001 16:07:29 -0400
Message-ID: <45D2A43C1913D51180F40000F89CB874062E18@nrtpde0a.us.nortel.com>
From: "Michael Brown" 
To: megaco@fore.com
Subject: RE: MG-MGC failure query
Date: Thu, 17 May 2001 16:07:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DF0C.FF991D00"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DF0C.FF991D00
Content-Type: text/plain;
	charset="iso-8859-1"

The text has been fixed as per the latest version (6) of the Implementer's
Guide. The following sentence was added to the text in 7.2.8.

"This serviceChange method is also sent from the MG to the MGC when the MG
detects that MGC has failed."

-----Original Message-----
From: Sarika Gupta [mailto:sargupta@yahoo.com]
Sent: Thursday, May 17, 2001 10:30 AM
To: megaco@fore.com
Subject: MG-MGC failure query


Hi,
There is a little confusion over ServiceChange message
with "failover" method.
In H248 Section 7.2.8, about failover it is written
"sent from MG to MGC to indicate the primary MG is out
of service and a secondary MG is taking over".

However in the same doc Section 11.5 (Failure of MGC),
it is written that in case the MG is not able to
contact its MGC, it sends a ServiceChange message with
"failover" method to the secondary MGC with "MGC
Impending Failure".
Can somebody clarify this??

Regards
Sarika

____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie

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






RE: MG-MGC failure query




The text has been fixed as per the latest version (6) =
of the Implementer's Guide. The following sentence was added to the =
text in 7.2.8.



"This serviceChange method is also sent from the =
MG to the MGC when the MG detects that MGC has failed."




-----Original Message-----

From: Sarika Gupta [mailto:sargupta@yahoo.com]=


Sent: Thursday, May 17, 2001 10:30 AM

To: megaco@fore.com

Subject: MG-MGC failure query






Hi,

There is a little confusion over ServiceChange =
message

with "failover" method.

In H248 Section 7.2.8, about failover it is =
written

"sent from MG to MGC to indicate the primary MG =
is out

of service and a secondary MG is taking =
over".




However in the same doc Section 11.5 (Failure of =
MGC),

it is written that in case the MG is not able =
to

contact its MGC, it sends a ServiceChange message =
with

"failover" method to the secondary MGC =
with "MGC

Impending Failure".

Can somebody clarify this??




Regards

Sarika




____________________________________________________________

Do You Yahoo!?

Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk

or your free @yahoo.ie address at http://mail.yahoo.ie





------_=_NextPart_001_01C0DF0C.FF991D00--


From owner-megaco@fore.com  Thu May 17 19:16:23 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28615
	for ; Thu, 17 May 2001 19:16:23 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA07338;
	Thu, 17 May 2001 19:10:24 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id TAA19559
	for megaco-list; Thu, 17 May 2001 19:07:51 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA19555
	for ; Thu, 17 May 2001 19:07:50 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA07214
	for ; Thu, 17 May 2001 19:07:44 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4HN7k518429
	for ; Thu, 17 May 2001 19:07:46 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4HN7jB18418
	for ; Thu, 17 May 2001 19:07:46 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id TAA11836; Thu, 17 May 2001 19:07:44 -0400 (EDT)
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id TAA11832; Thu, 17 May 2001 19:07:43 -0400 (EDT)
Message-ID: <3B045949.CFB19358@lucent.com>
Date: Thu, 17 May 2001 19:05:45 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: MEGACO list 
Subject: SDP and ';' comments
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


Megaco wankers :)

At least one of the messages in Appendix A
has SDP with an H.248 style comment:


                        Local { 
v=0 
c=IN IP4 $ 
m=audio $ RTP/AVP 0 
a=fmtp:PCMU VAD=X-NNVAD ; special voice activity  
                           ; detection algorithm 
                        } 


I assume we're not imposing these comments on SDP in general.
But in this example it's the last line of SDP and the comments 
could be part of RBRKT.

localDescriptor      = LocalToken LBRKT octetString RBRKT
RBRKT                = LWSP %x7D LWSP
LWSP                 = *( WSP / COMMENT / EOL )

But unless ';' is specifically not allowed in SDP (which I doubt),
allowing these comments will make it impossible to extract 
the SDP portion without fully parsing it.  I think it 
would be best if we could do that.

Could we say no comments between the braces?
Or no comments on the same lines as SDP?
Or no comments from the start of the SDP
to the RBRKT?

Maybe 

localDescriptor      = LocalToken LBRKT octetString RBRKT2
remoteDescriptor     = RemoteToken LBRKT octetString RBRKT2
RBRKT2               = LWSP2 %x7D LWSP
LWSP2                = *( WSP / EOL )

??

-troy


From owner-megaco@fore.com  Thu May 17 20:53:15 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29514
	for ; Thu, 17 May 2001 20:53:14 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA11113;
	Thu, 17 May 2001 20:46:20 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA25928
	for megaco-list; Thu, 17 May 2001 20:42:27 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA25922
	for ; Thu, 17 May 2001 20:42:25 -0400 (EDT)
Received: from rumor.cps.intel.com (rumor.cps.intel.com [192.102.198.242])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA10877
	for ; Thu, 17 May 2001 20:42:19 -0400 (EDT)
Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205])
	by rumor.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.38 2001/05/09 12:49:45 root Exp $) with SMTP id AAA07690;
	Fri, 18 May 2001 00:42:11 GMT
Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 18 May 2001 00:42:14 0000 (GMT)
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 17 May 2001 17:42:13 -0700
Message-ID: 
From: "Tulpule, Naren" 
To: "'Troy Cauble'" , MEGACO list 
Subject: RE: SDP and ';' comments
Date: Thu, 17 May 2001 17:42:10 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


Megaco wankers :)
[NAREN] Hey now, it's not Friday evening yet, Troy :-)
Check out
http://standards.nortelnetworks.com/scripts/wa.exe?A2=ind0009&L=MEGACO&P=R25
962 point (3).
This has come up before.
(If the link doesn't work try "search archives" with "SDP comment")
So what if it's the last line of SDP - it still violates SDP syntax before
the all important newline. It's just a Bad Example.
We don't need the rule that you propose, because SDP last line (a= or
whichever) is ALWAYS supposed to end with newline.



At least one of the messages in Appendix A
has SDP with an H.248 style comment:


                        Local { 
v=0 
c=IN IP4 $ 
m=audio $ RTP/AVP 0 
a=fmtp:PCMU VAD=X-NNVAD ; special voice activity  
                           ; detection algorithm 
                        } 


I assume we're not imposing these comments on SDP in general.
But in this example it's the last line of SDP and the comments 
could be part of RBRKT.

localDescriptor      = LocalToken LBRKT octetString RBRKT
RBRKT                = LWSP %x7D LWSP
LWSP                 = *( WSP / COMMENT / EOL )

But unless ';' is specifically not allowed in SDP (which I doubt),
allowing these comments will make it impossible to extract 
the SDP portion without fully parsing it.  I think it 
would be best if we could do that.

Could we say no comments between the braces?
Or no comments on the same lines as SDP?
Or no comments from the start of the SDP
to the RBRKT?

Maybe 

localDescriptor      = LocalToken LBRKT octetString RBRKT2
remoteDescriptor     = RemoteToken LBRKT octetString RBRKT2
RBRKT2               = LWSP2 %x7D LWSP
LWSP2                = *( WSP / EOL )

??

-troy



From owner-megaco@fore.com  Fri May 18 01:39:47 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07467
	for ; Fri, 18 May 2001 01:39:46 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA19870;
	Fri, 18 May 2001 01:34:13 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA13242
	for megaco-list; Fri, 18 May 2001 01:32:24 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA13238
	for ; Fri, 18 May 2001 01:32:22 -0400 (EDT)
Received: from mail.bhartitelesoft.com ([202.56.229.147])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA19749
	for ; Fri, 18 May 2001 01:32:13 -0400 (EDT)
Received: from sarju (taquila [202.56.229.146])
	by mail.bhartitelesoft.com (8.11.0/8.11.0) with SMTP id f4I5X6K16618
	for ; Fri, 18 May 2001 11:03:10 +0530
Message-ID: <001101c0df5c$89e14100$240310ac@bhartitelesoft.com>
Reply-To: "Sarju Garg" 
From: "Sarju Garg" 
To: "MEGACO list" 
References: <3B045949.CFB19358@lucent.com>
Subject: Use of Comment in MEGACO Grammer
Date: Fri, 18 May 2001 11:06:44 +0530
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 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,

I have a doubt regarding COMMENT rule. I see that we can insert comments in
the MEGACO message. What is the use of such comments? What to do if one
receive a message having comments? When to send comments?

TIA
Sarju




From owner-megaco@fore.com  Fri May 18 08:34:47 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24614
	for ; Fri, 18 May 2001 08:34:47 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA04376;
	Fri, 18 May 2001 08:26:53 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA20223
	for megaco-list; Fri, 18 May 2001 08:25:57 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA20219
	for ; Fri, 18 May 2001 08:25:56 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA04214
	for ; Fri, 18 May 2001 08:25:50 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id WAA02295;
	Fri, 18 May 2001 22:24:29 +1000 (EST)
Received: from ericsson.com ([164.48.166.24])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id WAA21048;
	Fri, 18 May 2001 22:23:57 +1000 (EST)
Message-ID: <3B051437.BC49CBC1@ericsson.com>
Date: Fri, 18 May 2001 22:23:19 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "'Troy Cauble'" 
CC: MEGACO list 
Subject: Re: SDP and ';' comments
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear Troy,

Please be aware that "wanker" is not a term of endearment in Australia
or most of Europe. Actually it may be a good way of addressing someone
if you don't want a very positive response.

Christian

"Tulpule, Naren" wrote:
> 
> Megaco wankers :)
> [NAREN] Hey now, it's not Friday evening yet, Troy :-)
> Check out
> http://standards.nortelnetworks.com/scripts/wa.exe?A2=ind0009&L=MEGACO&P=R25
> 962 point (3).
> This has come up before.
> (If the link doesn't work try "search archives" with "SDP comment")
> So what if it's the last line of SDP - it still violates SDP syntax before
> the all important newline. It's just a Bad Example.
> We don't need the rule that you propose, because SDP last line (a= or
> whichever) is ALWAYS supposed to end with newline.
> 
> 
> 
> At least one of the messages in Appendix A
> has SDP with an H.248 style comment:
> 
>                         Local {
> v=0
> c=IN IP4 $
> m=audio $ RTP/AVP 0
> a=fmtp:PCMU VAD=X-NNVAD ; special voice activity
>                            ; detection algorithm
>                         }
> 
> I assume we're not imposing these comments on SDP in general.
> But in this example it's the last line of SDP and the comments
> could be part of RBRKT.
> 
> localDescriptor      = LocalToken LBRKT octetString RBRKT
> RBRKT                = LWSP %x7D LWSP
> LWSP                 = *( WSP / COMMENT / EOL )
> 
> But unless ';' is specifically not allowed in SDP (which I doubt),
> allowing these comments will make it impossible to extract
> the SDP portion without fully parsing it.  I think it
> would be best if we could do that.
> 
> Could we say no comments between the braces?
> Or no comments on the same lines as SDP?
> Or no comments from the start of the SDP
> to the RBRKT?
> 
> Maybe
> 
> localDescriptor      = LocalToken LBRKT octetString RBRKT2
> remoteDescriptor     = RemoteToken LBRKT octetString RBRKT2
> RBRKT2               = LWSP2 %x7D LWSP
> LWSP2                = *( WSP / EOL )
> 
> ??
> 
> -troy


From owner-megaco@fore.com  Fri May 18 08:35:54 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24677
	for ; Fri, 18 May 2001 08:35:54 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA04172;
	Fri, 18 May 2001 08:25:35 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA19693
	for megaco-list; Fri, 18 May 2001 08:23:22 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA19689
	for ; Fri, 18 May 2001 08:23:20 -0400 (EDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA03972
	for ; Fri, 18 May 2001 08:23:14 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id WAA02275
	for ; Fri, 18 May 2001 22:23:10 +1000 (EST)
Received: from ericsson.com ([164.48.166.24])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id WAA20988
	for ; Fri, 18 May 2001 22:22:46 +1000 (EST)
Message-ID: <3B04DAAC.29AFA9A3@ericsson.com>
Date: Fri, 18 May 2001 18:17:48 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Polls of MGC
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day,

I'd really like to understand the network scenario for adding this
polling.
As I see it the MGC can determine that an MG is down. ie. It issues a
command and gets no response. It can take the appropriate action.
Likewise the MG can determine when the MGC is down in the same way.
Except that if the MGC its connected to is down the MG can't do much.
Remember the MGC is the Master and the MG is the slave.

I really don't see the benefit of the MG doing periodic polling. It will
find something is wrong when it tries to signal the MGC.

Without going to Servicechange methods, reasons etc. What's the benefit?

Cheers, Christian




From owner-megaco@fore.com  Fri May 18 08:59:11 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25551
	for ; Fri, 18 May 2001 08:59:11 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA06143;
	Fri, 18 May 2001 08:51:14 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA24150
	for megaco-list; Fri, 18 May 2001 08:49:49 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA24144
	for ; Fri, 18 May 2001 08:49:47 -0400 (EDT)
Received: from ns02.newbridge.com (ns02.newbridge.com [192.75.23.75])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id IAA05994
	for ; Fri, 18 May 2001 08:49:42 -0400 (EDT)
Received: (qmail 25422 invoked from network); 18 May 2001 12:47:54 -0000
Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76)
  by ns02.newbridge.com with SMTP; 18 May 2001 12:47:54 -0000
Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for megaco@fore.com; Fri, 18 May 2001 08:48:00 -0400
Received: from alcatel.com ([138.120.45.50]) by kanmail02.ca.newbridge.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAA3341;
          Fri, 18 May 2001 08:47:59 -0400
Message-Id: <3B0519FF.6D984DDD@alcatel.com>
Date: Fri, 18 May 2001 08:47:59 -0400
From: Ian Leighton 
Organization: Alcatel CID
X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Groves 
CC: megaco@fore.com
Subject: Re: Polls of MGC
References:  <3B04DAAC.29AFA9A3@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

It was my understanding that the poll was required so that
the MG can determine whether or not to initiated MGC Failure
proceedures described in Section 11.5.

Regards
Ian

Christian Groves wrote:

> G'Day,
>
> I'd really like to understand the network scenario for adding this
> polling.
> As I see it the MGC can determine that an MG is down. ie. It issues a
> command and gets no response. It can take the appropriate action.
> Likewise the MG can determine when the MGC is down in the same way.
> Except that if the MGC its connected to is down the MG can't do much.
> Remember the MGC is the Master and the MG is the slave.
>
> I really don't see the benefit of the MG doing periodic polling. It will
> find something is wrong when it tries to signal the MGC.
>
> Without going to Servicechange methods, reasons etc. What's the benefit?
>
> Cheers, Christian



From owner-megaco@fore.com  Fri May 18 09:02:03 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25645
	for ; Fri, 18 May 2001 09:02:02 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA06611;
	Fri, 18 May 2001 08:54:14 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA24660
	for megaco-list; Fri, 18 May 2001 08:52:50 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA24654
	for ; Fri, 18 May 2001 08:52:49 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 08:52:15 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F638@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Christian Groves'" , megaco@fore.com
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 08:52:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Christian

Everyone agrees that the way the MGC finds out if an MG is down is
to send a message and look for a response.  There are quite
a few messages an MGC could use.  I've suggested an audit.

Everyone also agrees that the way the MG finds out if the MGC is down
is to send a message and get a response.  It would presumably have
some timer that is reset by any message from the MGC.  If the timer
expired, it would send a message (a poll), and look for a reply.

There are two issues:
1. What message do you send?  MGs only send two messages, ServiceChange
and Notify.  The first series of messages on this thread talked about 
using SC as the message.  The issue is how to construct an SC
which does not change the MGCs notion of the MG state (ie behave
as a no-op).  The second set of messages talked about using Notify
as the poll

2. How fast do you poll? The MGC really ought to be able to control 
the frequency of polls, which would depend on how many MGs it was 
controlling.  For this reason, we have been talking about using Notify, 
with an interval parameter, which would be set by the MGC to control 
the polling.  Using SC, even if you could, there is no way for the
MGC to control the polling rate.

If the MGC is down, the MG can do the right thing, which is to contact
an alternate MGC for service.  

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Friday, May 18, 2001 4:18 AM
> To: megaco@fore.com
> Subject: Re: Polls of MGC
> 
> 
> G'Day,
> 
> I'd really like to understand the network scenario for adding this
> polling.
> As I see it the MGC can determine that an MG is down. ie. It issues a
> command and gets no response. It can take the appropriate action.
> Likewise the MG can determine when the MGC is down in the same way.
> Except that if the MGC its connected to is down the MG can't do much.
> Remember the MGC is the Master and the MG is the slave.
> 
> I really don't see the benefit of the MG doing periodic 
> polling. It will
> find something is wrong when it tries to signal the MGC.
> 
> Without going to Servicechange methods, reasons etc. What's 
> the benefit?
> 
> Cheers, Christian
> 
> 


From owner-megaco@fore.com  Fri May 18 09:41:15 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26778
	for ; Fri, 18 May 2001 09:41:15 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA10526;
	Fri, 18 May 2001 09:32:37 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA03608
	for megaco-list; Fri, 18 May 2001 09:30:24 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA03596
	for ; Fri, 18 May 2001 09:30:23 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA10210
	for ; Fri, 18 May 2001 09:30:18 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IDUJR02763
	for ; Fri, 18 May 2001 09:30:19 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IDUIW02759
	for ; Fri, 18 May 2001 09:30:18 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id JAA15931; Fri, 18 May 2001 09:30:15 -0400 (EDT)
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id JAA15927; Fri, 18 May 2001 09:30:14 -0400 (EDT)
Message-ID: <3B052371.17C20C2@lucent.com>
Date: Fri, 18 May 2001 09:28:17 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: MEGACO list 
Subject: Re: SDP and ';' comments
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


Good point!  SDP does require the newline!
-troy

"Tulpule, Naren" wrote:
> 
> Megaco wankers :)
> [NAREN] Hey now, it's not Friday evening yet, Troy :-)
> Check out
> http://standards.nortelnetworks.com/scripts/wa.exe?A2=ind0009&L=MEGACO&P=R25
> 962 point (3).
> This has come up before.
> (If the link doesn't work try "search archives" with "SDP comment")
> So what if it's the last line of SDP - it still violates SDP syntax before
> the all important newline. It's just a Bad Example.
> We don't need the rule that you propose, because SDP last line (a= or
> whichever) is ALWAYS supposed to end with newline.
> 
> 
> 
> At least one of the messages in Appendix A
> has SDP with an H.248 style comment:
> 
>                         Local {
> v=0
> c=IN IP4 $
> m=audio $ RTP/AVP 0
> a=fmtp:PCMU VAD=X-NNVAD ; special voice activity
>                            ; detection algorithm
>                         }
> 
> I assume we're not imposing these comments on SDP in general.
> But in this example it's the last line of SDP and the comments
> could be part of RBRKT.


From owner-megaco@fore.com  Fri May 18 09:45:13 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26875
	for ; Fri, 18 May 2001 09:45:12 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA11416;
	Fri, 18 May 2001 09:39:16 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA05484
	for megaco-list; Fri, 18 May 2001 09:37:49 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05475
	for ; Fri, 18 May 2001 09:37:47 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA11157
	for ; Fri, 18 May 2001 09:37:41 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IDbgR11080
	for ; Fri, 18 May 2001 09:37:43 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IDbgW11071
	for ; Fri, 18 May 2001 09:37:42 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id JAA16091; Fri, 18 May 2001 09:37:39 -0400 (EDT)
Cc: MEGACO list 
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id JAA16082; Fri, 18 May 2001 09:37:38 -0400 (EDT)
Message-ID: <3B05252D.23D7491@lucent.com>
Date: Fri, 18 May 2001 09:35:41 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Groves 
Original-CC: MEGACO list 
Subject: Re: SDP and ';' comments
References:  <3B051437.BC49CBC1@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


Yikes!  Sorry, all.  No offense intended.  
That's what I get for trying to crack wise.

I knew the origins were derogatory, but I thought it
was now in casual use.  I guess it just sounds "funny"
to us in the US, but it's still "fighting words" elsewhere.

Sorry again!
-troy

Christian Groves wrote:
> 
> Dear Troy,
> 
> Please be aware that "wanker" is not a term of endearment in Australia
> or most of Europe. Actually it may be a good way of addressing someone
> if you don't want a very positive response.
> 
> Christian
> 
> >
> > Megaco wankers :)


From owner-megaco@fore.com  Fri May 18 09:51:07 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27072
	for ; Fri, 18 May 2001 09:51:07 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA12071;
	Fri, 18 May 2001 09:43:46 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA06463
	for megaco-list; Fri, 18 May 2001 09:40:53 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA06459
	for ; Fri, 18 May 2001 09:40:52 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA11694
	for ; Fri, 18 May 2001 09:40:46 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 08:41:14 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD949458110F3@RADVPOST>
From: Dan Elbert 
To: megaco@fore.com
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 08:41:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Using SVC, the MGC could control the poll frequency by setting the value of
a property of the root termination (I assume the the poll is done with the
root termination id ).

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Friday, May 18, 2001 8:53 AM
To: 'Christian Groves'; megaco@fore.com
Subject: RE: Polls of MGC

Christian

Everyone agrees that the way the MGC finds out if an MG is down is
to send a message and look for a response.  There are quite
a few messages an MGC could use.  I've suggested an audit.

Everyone also agrees that the way the MG finds out if the MGC is down
is to send a message and get a response.  It would presumably have
some timer that is reset by any message from the MGC.  If the timer
expired, it would send a message (a poll), and look for a reply.

There are two issues:
1. What message do you send?  MGs only send two messages, ServiceChange
and Notify.  The first series of messages on this thread talked about
using SC as the message.  The issue is how to construct an SC
which does not change the MGCs notion of the MG state (ie behave
as a no-op).  The second set of messages talked about using Notify
as the poll

2. How fast do you poll? The MGC really ought to be able to control
the frequency of polls, which would depend on how many MGs it was
controlling.  For this reason, we have been talking about using Notify,
with an interval parameter, which would be set by the MGC to control
the polling.  Using SC, even if you could, there is no way for the
MGC to control the polling rate.

If the MGC is down, the MG can do the right thing, which is to contact
an alternate MGC for service. 

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Friday, May 18, 2001 4:18 AM
> To: megaco@fore.com
> Subject: Re: Polls of MGC
>
>
> G'Day,
>
> I'd really like to understand the network scenario for adding this
> polling.
> As I see it the MGC can determine that an MG is down. ie. It issues a
> command and gets no response. It can take the appropriate action.
> Likewise the MG can determine when the MGC is down in the same way.
> Except that if the MGC its connected to is down the MG can't do much.
> Remember the MGC is the Master and the MG is the slave.
>
> I really don't see the benefit of the MG doing periodic
> polling. It will
> find something is wrong when it tries to signal the MGC.
>
> Without going to Servicechange methods, reasons etc. What's
> the benefit?
>
> Cheers, Christian
>
>


From owner-megaco@fore.com  Fri May 18 09:53:21 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27088
	for ; Fri, 18 May 2001 09:53:21 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA12484;
	Fri, 18 May 2001 09:47:07 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA07447
	for megaco-list; Fri, 18 May 2001 09:44:51 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA07344
	for ; Fri, 18 May 2001 09:44:38 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA12154
	for ; Fri, 18 May 2001 09:44:26 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACS11765;
	Fri, 18 May 2001 09:44:25 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Rosen, Brian'" ,
        "'Christian Groves'" ,
        
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 09:48:30 -0400
Message-ID: <021a01c0dfa1$395319d0$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <4FBEA8857476D311A03300204840E1CF01A6F638@whq-msgusr-02.pit.comms.marconi.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Brian/list,
Even today without the Polling mechanism the MG can follow the MGC failure
procedures defined in Section 11.5. So, what is the additional gain by
sending another message to the MGC and then initiating the failure
procedures.

When this polling needs to be done??
1) When there is no activity between MG and MGC OR
2) When any command generated from MG is not acknowledged by the MGC with
any response?

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Friday, May 18, 2001 8:53 AM
To: 'Christian Groves'; megaco@fore.com
Subject: RE: Polls of MGC


Christian

Everyone agrees that the way the MGC finds out if an MG is down is
to send a message and look for a response.  There are quite
a few messages an MGC could use.  I've suggested an audit.

Everyone also agrees that the way the MG finds out if the MGC is down
is to send a message and get a response.  It would presumably have
some timer that is reset by any message from the MGC.  If the timer
expired, it would send a message (a poll), and look for a reply.

There are two issues:
1. What message do you send?  MGs only send two messages, ServiceChange
and Notify.  The first series of messages on this thread talked about
using SC as the message.  The issue is how to construct an SC
which does not change the MGCs notion of the MG state (ie behave
as a no-op).  The second set of messages talked about using Notify
as the poll

2. How fast do you poll? The MGC really ought to be able to control
the frequency of polls, which would depend on how many MGs it was
controlling.  For this reason, we have been talking about using Notify,
with an interval parameter, which would be set by the MGC to control
the polling.  Using SC, even if you could, there is no way for the
MGC to control the polling rate.

If the MGC is down, the MG can do the right thing, which is to contact
an alternate MGC for service.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Friday, May 18, 2001 4:18 AM
> To: megaco@fore.com
> Subject: Re: Polls of MGC
>
>
> G'Day,
>
> I'd really like to understand the network scenario for adding this
> polling.
> As I see it the MGC can determine that an MG is down. ie. It issues a
> command and gets no response. It can take the appropriate action.
> Likewise the MG can determine when the MGC is down in the same way.
> Except that if the MGC its connected to is down the MG can't do much.
> Remember the MGC is the Master and the MG is the slave.
>
> I really don't see the benefit of the MG doing periodic
> polling. It will
> find something is wrong when it tries to signal the MGC.
>
> Without going to Servicechange methods, reasons etc. What's
> the benefit?
>
> Cheers, Christian
>
>



From owner-megaco@fore.com  Fri May 18 10:02:38 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27260
	for ; Fri, 18 May 2001 10:02:38 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA13382;
	Fri, 18 May 2001 09:55:24 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA09914
	for megaco-list; Fri, 18 May 2001 09:54:18 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA09910
	for ; Fri, 18 May 2001 09:54:17 -0400 (EDT)
From: knayar@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA13135
	for ; Fri, 18 May 2001 09:53:51 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4IDscq23721;
	Fri, 18 May 2001 19:24:38 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A50.004AF0F7 ; Fri, 18 May 2001 19:08:33 +0530
X-Lotus-FromDomain: HSS
To: "Rosen, Brian" 
cc: "'Christian Groves'" , megaco@fore.com
Message-ID: <65256A50.004AED4D.00@sandesh.hss.hns.com>
Date: Fri, 18 May 2001 19:16:00 +0530
Subject: RE: Polls of MGC
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk



Hi Brian

I think what Christian is pointing out is that do we really need polling......
The question is that in case of unreliable transport protocol like UDP whether
the MGC ( or MG) should be allowed to wait for timeout of "a reply to a valid
request message" (like ADD, MODIFY etc. from MGC and NOTIFY, SVC from MG) to
detect failure of the other end. Or else, there should be a mechanism in built
in the MEGACO protocol to detect a MG or MGC failure....seems a better option
though it has an added overhead of polling.

Now, if we decide to introduce polling......the next issue is how to add
one.....
There are two proposals....
1.   Through a notify...event "noop" with a delay parameter which controls the
frequency of polling.
     But, this I think has a dependency that this poll can only be initiated by
MGC thru' activation of an event descriptor.
2.   Alternatively, we can use Service Change with "noop" method and add a
property to Base Root package "normalMGCIdleTime....or normalMGCPollTime". This
is the polling timeout duration provisioned at MG and settable by MGC at
runtime.
If MGC sets the value of this timer at runtime, MG should restart the polling
timer. Additionally, we can put a guideline that in case the MG or MGC receives
either a valid request or a valid reply from the other end within a polling
interval, the SVC "noop" need not be sent at the expiry of that polling
interval. Since service change can be sent by both MG and MGC this gives a
suitable solution for polling.

The concern about controlling the polling thru' MGC is addressed suitable by
both the alternatives.

Thanks,
-Kapil Nayar
Hughes Software Systems





"Rosen, Brian"  on 05/18/2001 06:22:46 PM

To:   "'Christian Groves'" , megaco@fore.com
cc:    (bcc: Kapil Nayar/HSS)

Subject:  RE: Polls of MGC




Christian

Everyone agrees that the way the MGC finds out if an MG is down is
to send a message and look for a response.  There are quite
a few messages an MGC could use.  I've suggested an audit.

Everyone also agrees that the way the MG finds out if the MGC is down
is to send a message and get a response.  It would presumably have
some timer that is reset by any message from the MGC.  If the timer
expired, it would send a message (a poll), and look for a reply.

There are two issues:
1. What message do you send?  MGs only send two messages, ServiceChange
and Notify.  The first series of messages on this thread talked about
using SC as the message.  The issue is how to construct an SC
which does not change the MGCs notion of the MG state (ie behave
as a no-op).  The second set of messages talked about using Notify
as the poll

2. How fast do you poll? The MGC really ought to be able to control
the frequency of polls, which would depend on how many MGs it was
controlling.  For this reason, we have been talking about using Notify,
with an interval parameter, which would be set by the MGC to control
the polling.  Using SC, even if you could, there is no way for the
MGC to control the polling rate.

If the MGC is down, the MG can do the right thing, which is to contact
an alternate MGC for service.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Friday, May 18, 2001 4:18 AM
> To: megaco@fore.com
> Subject: Re: Polls of MGC
>
>
> G'Day,
>
> I'd really like to understand the network scenario for adding this
> polling.
> As I see it the MGC can determine that an MG is down. ie. It issues a
> command and gets no response. It can take the appropriate action.
> Likewise the MG can determine when the MGC is down in the same way.
> Except that if the MGC its connected to is down the MG can't do much.
> Remember the MGC is the Master and the MG is the slave.
>
> I really don't see the benefit of the MG doing periodic
> polling. It will
> find something is wrong when it tries to signal the MGC.
>
> Without going to Servicechange methods, reasons etc. What's
> the benefit?
>
> Cheers, Christian
>
>






From owner-megaco@fore.com  Fri May 18 10:10:21 2001
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27453
	for ; Fri, 18 May 2001 10:10:21 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14378;
	Fri, 18 May 2001 10:02:44 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA11705
	for megaco-list; Fri, 18 May 2001 10:01:47 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11701
	for ; Fri, 18 May 2001 10:01:46 -0400 (EDT)
Received: from mail-gwy (smtp.ibasis.net [140.239.177.22])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA14242
	for ; Fri, 18 May 2001 10:01:40 -0400 (EDT)
Received: from exchange_10.ibasis.net ([10.1.1.110])
 by mail-gwy (NAVIEG 2.1 bld 63) with SMTP id M2001051810013612885
 for ; Fri, 18 May 2001 10:01:36 -0400
Received: by EXCHANGE_10 with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 09:56:59 -0400
Message-ID: <201701842255D4118AC10008C74B7EDA150003@exchange.vipcalling.com>
From: Wenxin Ma 
To: megaco@fore.com
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 09:54:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hi,

Is the pulling of MGC similar to "keep alive" between Gateway and Gatekeeper
in H.323?

Regards,

Wenxin

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Friday, May 18, 2001 9:49 AM
To: 'Rosen, Brian'; 'Christian Groves'; megaco@fore.com
Subject: RE: Polls of MGC


Hi Brian/list,
Even today without the Polling mechanism the MG can follow the MGC failure
procedures defined in Section 11.5. So, what is the additional gain by
sending another message to the MGC and then initiating the failure
procedures.

When this polling needs to be done??
1) When there is no activity between MG and MGC OR
2) When any command generated from MG is not acknowledged by the MGC with
any response?

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Friday, May 18, 2001 8:53 AM
To: 'Christian Groves'; megaco@fore.com
Subject: RE: Polls of MGC


Christian

Everyone agrees that the way the MGC finds out if an MG is down is
to send a message and look for a response.  There are quite
a few messages an MGC could use.  I've suggested an audit.

Everyone also agrees that the way the MG finds out if the MGC is down
is to send a message and get a response.  It would presumably have
some timer that is reset by any message from the MGC.  If the timer
expired, it would send a message (a poll), and look for a reply.

There are two issues:
1. What message do you send?  MGs only send two messages, ServiceChange
and Notify.  The first series of messages on this thread talked about
using SC as the message.  The issue is how to construct an SC
which does not change the MGCs notion of the MG state (ie behave
as a no-op).  The second set of messages talked about using Notify
as the poll

2. How fast do you poll? The MGC really ought to be able to control
the frequency of polls, which would depend on how many MGs it was
controlling.  For this reason, we have been talking about using Notify,
with an interval parameter, which would be set by the MGC to control
the polling.  Using SC, even if you could, there is no way for the
MGC to control the polling rate.

If the MGC is down, the MG can do the right thing, which is to contact
an alternate MGC for service.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Friday, May 18, 2001 4:18 AM
> To: megaco@fore.com
> Subject: Re: Polls of MGC
>
>
> G'Day,
>
> I'd really like to understand the network scenario for adding this
> polling.
> As I see it the MGC can determine that an MG is down. ie. It issues a
> command and gets no response. It can take the appropriate action.
> Likewise the MG can determine when the MGC is down in the same way.
> Except that if the MGC its connected to is down the MG can't do much.
> Remember the MGC is the Master and the MG is the slave.
>
> I really don't see the benefit of the MG doing periodic
> polling. It will
> find something is wrong when it tries to signal the MGC.
>
> Without going to Servicechange methods, reasons etc. What's
> the benefit?
>
> Cheers, Christian
>
>


From owner-megaco@fore.com  Fri May 18 10:54:27 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28159
	for ; Fri, 18 May 2001 10:54:27 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19434;
	Fri, 18 May 2001 10:47:16 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA22099
	for megaco-list; Fri, 18 May 2001 10:46:14 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA22076
	for ; Fri, 18 May 2001 10:46:11 -0400 (EDT)
Received: from slink12.ss7-link.com (mail.ss7-link.com [209.204.106.218])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19235
	for ; Fri, 18 May 2001 10:45:59 -0400 (EDT)
Received: by SLINK12 with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 10:46:00 -0400
Message-ID: 
From: Dave Sclarsky 
To: "'Madhu Babu Brahmanapally'" ,
        "'megaco@fore.com'" 
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 10:45:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Madhubabu,

Sorry, I failed to answer your original question - polling only needs to be
done when there is no activity between MG and MGC.

The problem with HANDOFF is that it assumes that the MGC is alive enough
(and its NIC is still working, its NIC cable didn't come unplugged or get
cut, etc.) to send it!  In any case, the protocol must provide some
mechanism to allow the MG to switch to the new MGC ASAP.  If there is no
other Megaco activity, polling is the only option (at least for UDP and TCP,
but not for SCTP)!

DaveS.



-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Friday, May 18, 2001 10:28 AM
To: 'Dave Sclarsky'
Subject: RE: Polls of MGC


HI Dave,
I agree that both the MGC and the MG needs to be sync whether a Standby MGC
takeover a MGC OR a redundant MG takes over the actual MG. As you suggested
in case of MGC going down, it has to generate a HANDOFF service change
command towards the MG indicating the MG to establish a new control
association with the newly specified address in the "MgcIdToTry" field. All
these cases are already taken care by the protocol (cases like MG taken over
by Redundant MG or MGC taken over by a standby MGC).

The Polls of MGC is something the MG needs to initiate. The trigger for this
is lack of response from the MGC for a specific Notify command. If the MGC
is really down then the next Notify with the poll event will also not be
acknowledged by the MGC. So, I think there is no concrete gain by defining a
new event and adding addition processing logic(which IMO is overhead). If
the MGC is not down and the response of the first Notify is lost because of
the Network congestion...then the same can happen with the Notify with the
"poll" event. Then it merely ends like probability of message lost over a
unreliable network. At least iam not able to convince myself why this
polling mechanism is advantageous for the MG/MGC.(or enabling the MG to
circumvent the MGC failure).

Regards
Madhubabu

-----Original Message-----
From: Dave Sclarsky [mailto:Dave.Sclarsky@radisys.com]
Sent: Friday, May 18, 2001 10:07 AM
To: 'Madhu Babu Brahmanapally'
Subject: RE: Polls of MGC


Madhubabu,
If an MGC goes down and its standby takes over, the MGs don't notice until
they have a notify to send.  This could be a long time (middle of the night
on a ResGW).  In the meantime, what happens if the new MGC needs to make a
call to a quiescent MG?  The MGC cannot initiate a control association, so
the physical terminations are effectively lost from the network until one of
them generates an event!
DaveS.

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Friday, May 18, 2001 9:49 AM
To: 'Rosen, Brian'; 'Christian Groves'; megaco@fore.com
Subject: RE: Polls of MGC


Hi Brian/list,
Even today without the Polling mechanism the MG can follow the MGC failure
procedures defined in Section 11.5. So, what is the additional gain by
sending another message to the MGC and then initiating the failure
procedures.

When this polling needs to be done??
1) When there is no activity between MG and MGC OR
2) When any command generated from MG is not acknowledged by the MGC with
any response?

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Friday, May 18, 2001 8:53 AM
To: 'Christian Groves'; megaco@fore.com
Subject: RE: Polls of MGC


Christian

Everyone agrees that the way the MGC finds out if an MG is down is
to send a message and look for a response.  There are quite
a few messages an MGC could use.  I've suggested an audit.

Everyone also agrees that the way the MG finds out if the MGC is down
is to send a message and get a response.  It would presumably have
some timer that is reset by any message from the MGC.  If the timer
expired, it would send a message (a poll), and look for a reply.

There are two issues:
1. What message do you send?  MGs only send two messages, ServiceChange
and Notify.  The first series of messages on this thread talked about
using SC as the message.  The issue is how to construct an SC
which does not change the MGCs notion of the MG state (ie behave
as a no-op).  The second set of messages talked about using Notify
as the poll

2. How fast do you poll? The MGC really ought to be able to control
the frequency of polls, which would depend on how many MGs it was
controlling.  For this reason, we have been talking about using Notify,
with an interval parameter, which would be set by the MGC to control
the polling.  Using SC, even if you could, there is no way for the
MGC to control the polling rate.

If the MGC is down, the MG can do the right thing, which is to contact
an alternate MGC for service.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Friday, May 18, 2001 4:18 AM
> To: megaco@fore.com
> Subject: Re: Polls of MGC
>
>
> G'Day,
>
> I'd really like to understand the network scenario for adding this
> polling.
> As I see it the MGC can determine that an MG is down. ie. It issues a
> command and gets no response. It can take the appropriate action.
> Likewise the MG can determine when the MGC is down in the same way.
> Except that if the MGC its connected to is down the MG can't do much.
> Remember the MGC is the Master and the MG is the slave.
>
> I really don't see the benefit of the MG doing periodic
> polling. It will
> find something is wrong when it tries to signal the MGC.
>
> Without going to Servicechange methods, reasons etc. What's
> the benefit?
>
> Cheers, Christian
>
>


From owner-megaco@fore.com  Fri May 18 10:55:37 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28192
	for ; Fri, 18 May 2001 10:55:37 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19100;
	Fri, 18 May 2001 10:45:13 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA21516
	for megaco-list; Fri, 18 May 2001 10:43:22 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21509
	for ; Fri, 18 May 2001 10:43:21 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 10:42:46 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F63E@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Madhu Babu Brahmanapally'" , megaco@fore.com
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 10:43:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

The problem exists when there is no normal message flow between the
MG and the MGC.  This could be common (all idle lines).  If there is
messaging, then you don't need the poll.

The 11.5 mechanisms would be used when you determine the MGC is
not available. This discussion is how you determine that.  You would
also initiate the failure procedures if you did not get a response
from the MGC (after all the repetitions failed, of course). 

Brian


> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Friday, May 18, 2001 9:49 AM
> To: 'Rosen, Brian'; 'Christian Groves'; megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> Hi Brian/list,
> Even today without the Polling mechanism the MG can follow 
> the MGC failure
> procedures defined in Section 11.5. So, what is the additional gain by
> sending another message to the MGC and then initiating the failure
> procedures.
> 
> When this polling needs to be done??
> 1) When there is no activity between MG and MGC OR
> 2) When any command generated from MG is not acknowledged by 
> the MGC with
> any response?
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> Sent: Friday, May 18, 2001 8:53 AM
> To: 'Christian Groves'; megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> Christian
> 
> Everyone agrees that the way the MGC finds out if an MG is down is
> to send a message and look for a response.  There are quite
> a few messages an MGC could use.  I've suggested an audit.
> 
> Everyone also agrees that the way the MG finds out if the MGC is down
> is to send a message and get a response.  It would presumably have
> some timer that is reset by any message from the MGC.  If the timer
> expired, it would send a message (a poll), and look for a reply.
> 
> There are two issues:
> 1. What message do you send?  MGs only send two messages, 
> ServiceChange
> and Notify.  The first series of messages on this thread talked about
> using SC as the message.  The issue is how to construct an SC
> which does not change the MGCs notion of the MG state (ie behave
> as a no-op).  The second set of messages talked about using Notify
> as the poll
> 
> 2. How fast do you poll? The MGC really ought to be able to control
> the frequency of polls, which would depend on how many MGs it was
> controlling.  For this reason, we have been talking about 
> using Notify,
> with an interval parameter, which would be set by the MGC to control
> the polling.  Using SC, even if you could, there is no way for the
> MGC to control the polling rate.
> 
> If the MGC is down, the MG can do the right thing, which is to contact
> an alternate MGC for service.
> 
> Brian
> 
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Friday, May 18, 2001 4:18 AM
> > To: megaco@fore.com
> > Subject: Re: Polls of MGC
> >
> >
> > G'Day,
> >
> > I'd really like to understand the network scenario for adding this
> > polling.
> > As I see it the MGC can determine that an MG is down. ie. 
> It issues a
> > command and gets no response. It can take the appropriate action.
> > Likewise the MG can determine when the MGC is down in the same way.
> > Except that if the MGC its connected to is down the MG 
> can't do much.
> > Remember the MGC is the Master and the MG is the slave.
> >
> > I really don't see the benefit of the MG doing periodic
> > polling. It will
> > find something is wrong when it tries to signal the MGC.
> >
> > Without going to Servicechange methods, reasons etc. What's
> > the benefit?
> >
> > Cheers, Christian
> >
> >
> 


From owner-megaco@fore.com  Fri May 18 11:01:20 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28321
	for ; Fri, 18 May 2001 11:01:19 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20365;
	Fri, 18 May 2001 10:53:45 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA23576
	for megaco-list; Fri, 18 May 2001 10:52:10 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23569
	for ; Fri, 18 May 2001 10:52:08 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 10:51:34 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F63F@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'knayar@hss.hns.com'" 
Cc: megaco@fore.com
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 10:52:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This discussion is not specifically detecting failure of the
MGC by timeout of response to a message.  It has to do with
detecting failure of the MGC when there is no message flow.
The poll CREATES a message for the purpose of seeing if it
can get a response.  If, during the processing of the poll,
it gets no response, then it initiates failover procedures
as documented. "No Response" to the poll is exactly the same
as no response to a normal message.

It is possible to use SC if you add a no-op method.  It is 
possible to control frequency at the MGC by having a settable
parameter on root.  That is, to me, an acceptable answer,
but adding the no-op actually changes the protocol.  
The advantage of the package with the event is that it's a normal 
package, and can be standardized without modifying RFC3015
and Recommendation H.248.  Trying to do this with an "Implementor's
Guide" seems to me to be stretching the definition of "Guide"
pretty far.  Alternatively, this can be deferred to a future
revision.

Brian



> -----Original Message-----
> From: knayar@hss.hns.com [mailto:knayar@hss.hns.com]
> Sent: Friday, May 18, 2001 9:46 AM
> To: Rosen, Brian
> Cc: 'Christian Groves'; megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> 
> 
> Hi Brian
> 
> I think what Christian is pointing out is that do we really 
> need polling......
> The question is that in case of unreliable transport protocol 
> like UDP whether
> the MGC ( or MG) should be allowed to wait for timeout of "a 
> reply to a valid
> request message" (like ADD, MODIFY etc. from MGC and NOTIFY, 
> SVC from MG) to
> detect failure of the other end. Or else, there should be a 
> mechanism in built
> in the MEGACO protocol to detect a MG or MGC failure....seems 
> a better option
> though it has an added overhead of polling.
> 
> Now, if we decide to introduce polling......the next issue is 
> how to add
> one.....
> There are two proposals....
> 1.   Through a notify...event "noop" with a delay parameter 
> which controls the
> frequency of polling.
>      But, this I think has a dependency that this poll can 
> only be initiated by
> MGC thru' activation of an event descriptor.
> 2.   Alternatively, we can use Service Change with "noop" 
> method and add a
> property to Base Root package "normalMGCIdleTime....or 
> normalMGCPollTime". This
> is the polling timeout duration provisioned at MG and 
> settable by MGC at
> runtime.
> If MGC sets the value of this timer at runtime, MG should 
> restart the polling
> timer. Additionally, we can put a guideline that in case the 
> MG or MGC receives
> either a valid request or a valid reply from the other end 
> within a polling
> interval, the SVC "noop" need not be sent at the expiry of 
> that polling
> interval. Since service change can be sent by both MG and MGC 
> this gives a
> suitable solution for polling.
> 
> The concern about controlling the polling thru' MGC is 
> addressed suitable by
> both the alternatives.
> 
> Thanks,
> -Kapil Nayar
> Hughes Software Systems
> 
> 
> 
> 
> 
> "Rosen, Brian"  on 05/18/2001 06:22:46 PM
> 
> To:   "'Christian Groves'" , 
> megaco@fore.com
> cc:    (bcc: Kapil Nayar/HSS)
> 
> Subject:  RE: Polls of MGC
> 
> 
> 
> 
> Christian
> 
> Everyone agrees that the way the MGC finds out if an MG is down is
> to send a message and look for a response.  There are quite
> a few messages an MGC could use.  I've suggested an audit.
> 
> Everyone also agrees that the way the MG finds out if the MGC is down
> is to send a message and get a response.  It would presumably have
> some timer that is reset by any message from the MGC.  If the timer
> expired, it would send a message (a poll), and look for a reply.
> 
> There are two issues:
> 1. What message do you send?  MGs only send two messages, 
> ServiceChange
> and Notify.  The first series of messages on this thread talked about
> using SC as the message.  The issue is how to construct an SC
> which does not change the MGCs notion of the MG state (ie behave
> as a no-op).  The second set of messages talked about using Notify
> as the poll
> 
> 2. How fast do you poll? The MGC really ought to be able to control
> the frequency of polls, which would depend on how many MGs it was
> controlling.  For this reason, we have been talking about 
> using Notify,
> with an interval parameter, which would be set by the MGC to control
> the polling.  Using SC, even if you could, there is no way for the
> MGC to control the polling rate.
> 
> If the MGC is down, the MG can do the right thing, which is to contact
> an alternate MGC for service.
> 
> Brian
> 
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Friday, May 18, 2001 4:18 AM
> > To: megaco@fore.com
> > Subject: Re: Polls of MGC
> >
> >
> > G'Day,
> >
> > I'd really like to understand the network scenario for adding this
> > polling.
> > As I see it the MGC can determine that an MG is down. ie. 
> It issues a
> > command and gets no response. It can take the appropriate action.
> > Likewise the MG can determine when the MGC is down in the same way.
> > Except that if the MGC its connected to is down the MG 
> can't do much.
> > Remember the MGC is the Master and the MG is the slave.
> >
> > I really don't see the benefit of the MG doing periodic
> > polling. It will
> > find something is wrong when it tries to signal the MGC.
> >
> > Without going to Servicechange methods, reasons etc. What's
> > the benefit?
> >
> > Cheers, Christian
> >
> >
> 
> 
> 
> 


From owner-megaco@fore.com  Fri May 18 11:13:51 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28528
	for ; Fri, 18 May 2001 11:13:50 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22139;
	Fri, 18 May 2001 11:07:09 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA26816
	for megaco-list; Fri, 18 May 2001 11:06:10 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26807
	for ; Fri, 18 May 2001 11:06:08 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA21937
	for ; Fri, 18 May 2001 11:06:02 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 10:06:36 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD949458110F7@RADVPOST>
From: Dan Elbert 
To: "'megaco@fore.com'" 
Subject: Use of ServiceChange from MGC to MG
Date: Fri, 18 May 2001 10:06:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hi 

The Media Gateway Controller may indicate that Termination(s) shall be taken
out of or returned to service.
1. What is the meaning of the MGC taking down a termination ? Does it means
that the termination is substracted from any active context and all signal
are stopped and no events are detected ?
2. What methods are used for taking the MG down and up ? I'd say Graceful
and Restart. Is this OK ?
3. Is this applicable also to the root termination ? I would say no because
if the root termination "goes down" then logically the MG may not be able to
receive any more MGC commands.

Thanks,

Dan Elbert
RADVISION


From owner-megaco@fore.com  Fri May 18 11:22:14 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28708
	for ; Fri, 18 May 2001 11:22:14 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23075;
	Fri, 18 May 2001 11:13:13 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA28182
	for megaco-list; Fri, 18 May 2001 11:12:10 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA28167
	for ; Fri, 18 May 2001 11:12:08 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22881
	for ; Fri, 18 May 2001 11:12:02 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 10:12:36 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD949458110F8@RADVPOST>
From: Dan Elbert 
To: megaco@fore.com
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 10:12:28 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

In the protocol it says that the ServiceChange method can also be "Another
value whose meaning is mutually understood between the MG and the MGC" so I
think that specifying a "noop" value in the Implementor's guide is covered
under this. 
The problem with the package is that it has to be implemented by both sides
to work, and making the package "mandatory" also implies a modification of
the spec.
The SVC will work even if only the MG implements it, because the MGC should
reply to this even if the method is unknown to him.

Dan

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Friday, May 18, 2001 10:52 AM
To: 'knayar@hss.hns.com'
Cc: megaco@fore.com
Subject: RE: Polls of MGC

This discussion is not specifically detecting failure of the
MGC by timeout of response to a message.  It has to do with
detecting failure of the MGC when there is no message flow.
The poll CREATES a message for the purpose of seeing if it
can get a response.  If, during the processing of the poll,
it gets no response, then it initiates failover procedures
as documented. "No Response" to the poll is exactly the same
as no response to a normal message.

It is possible to use SC if you add a no-op method.  It is
possible to control frequency at the MGC by having a settable
parameter on root.  That is, to me, an acceptable answer,
but adding the no-op actually changes the protocol. 
The advantage of the package with the event is that it's a normal
package, and can be standardized without modifying RFC3015
and Recommendation H.248.  Trying to do this with an "Implementor's
Guide" seems to me to be stretching the definition of "Guide"
pretty far.  Alternatively, this can be deferred to a future
revision.

Brian



> -----Original Message-----
> From: knayar@hss.hns.com [mailto:knayar@hss.hns.com]
> Sent: Friday, May 18, 2001 9:46 AM
> To: Rosen, Brian
> Cc: 'Christian Groves'; megaco@fore.com
> Subject: RE: Polls of MGC
>
>
>
>
> Hi Brian
>
> I think what Christian is pointing out is that do we really
> need polling......
> The question is that in case of unreliable transport protocol
> like UDP whether
> the MGC ( or MG) should be allowed to wait for timeout of "a
> reply to a valid
> request message" (like ADD, MODIFY etc. from MGC and NOTIFY,
> SVC from MG) to
> detect failure of the other end. Or else, there should be a
> mechanism in built
> in the MEGACO protocol to detect a MG or MGC failure....seems
> a better option
> though it has an added overhead of polling.
>
> Now, if we decide to introduce polling......the next issue is
> how to add
> one.....
> There are two proposals....
> 1.   Through a notify...event "noop" with a delay parameter
> which controls the
> frequency of polling.
>      But, this I think has a dependency that this poll can
> only be initiated by
> MGC thru' activation of an event descriptor.
> 2.   Alternatively, we can use Service Change with "noop"
> method and add a
> property to Base Root package "normalMGCIdleTime....or
> normalMGCPollTime". This
> is the polling timeout duration provisioned at MG and
> settable by MGC at
> runtime.
> If MGC sets the value of this timer at runtime, MG should
> restart the polling
> timer. Additionally, we can put a guideline that in case the
> MG or MGC receives
> either a valid request or a valid reply from the other end
> within a polling
> interval, the SVC "noop" need not be sent at the expiry of
> that polling
> interval. Since service change can be sent by both MG and MGC
> this gives a
> suitable solution for polling.
>
> The concern about controlling the polling thru' MGC is
> addressed suitable by
> both the alternatives.
>
> Thanks,
> -Kapil Nayar
> Hughes Software Systems
>
>
>
>
>
> "Rosen, Brian"  on 05/18/2001 06:22:46 PM
>
> To:   "'Christian Groves'" ,
> megaco@fore.com
> cc:    (bcc: Kapil Nayar/HSS)
>
> Subject:  RE: Polls of MGC
>
>
>
>
> Christian
>
> Everyone agrees that the way the MGC finds out if an MG is down is
> to send a message and look for a response.  There are quite
> a few messages an MGC could use.  I've suggested an audit.
>
> Everyone also agrees that the way the MG finds out if the MGC is down
> is to send a message and get a response.  It would presumably have
> some timer that is reset by any message from the MGC.  If the timer
> expired, it would send a message (a poll), and look for a reply.
>
> There are two issues:
> 1. What message do you send?  MGs only send two messages,
> ServiceChange
> and Notify.  The first series of messages on this thread talked about
> using SC as the message.  The issue is how to construct an SC
> which does not change the MGCs notion of the MG state (ie behave
> as a no-op).  The second set of messages talked about using Notify
> as the poll
>
> 2. How fast do you poll? The MGC really ought to be able to control
> the frequency of polls, which would depend on how many MGs it was
> controlling.  For this reason, we have been talking about
> using Notify,
> with an interval parameter, which would be set by the MGC to control
> the polling.  Using SC, even if you could, there is no way for the
> MGC to control the polling rate.
>
> If the MGC is down, the MG can do the right thing, which is to contact
> an alternate MGC for service.
>
> Brian
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Friday, May 18, 2001 4:18 AM
> > To: megaco@fore.com
> > Subject: Re: Polls of MGC
> >
> >
> > G'Day,
> >
> > I'd really like to understand the network scenario for adding this
> > polling.
> > As I see it the MGC can determine that an MG is down. ie.
> It issues a
> > command and gets no response. It can take the appropriate action.
> > Likewise the MG can determine when the MGC is down in the same way.
> > Except that if the MGC its connected to is down the MG
> can't do much.
> > Remember the MGC is the Master and the MG is the slave.
> >
> > I really don't see the benefit of the MG doing periodic
> > polling. It will
> > find something is wrong when it tries to signal the MGC.
> >
> > Without going to Servicechange methods, reasons etc. What's
> > the benefit?
> >
> > Cheers, Christian
> >
> >
>
>
>
>


From owner-megaco@fore.com  Fri May 18 11:25:56 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28738
	for ; Fri, 18 May 2001 11:25:55 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23280;
	Fri, 18 May 2001 11:14:24 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA28582
	for megaco-list; Fri, 18 May 2001 11:13:06 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA28563
	for ; Fri, 18 May 2001 11:13:03 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23029
	for ; Fri, 18 May 2001 11:12:57 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IFCtC18387
	for ; Fri, 18 May 2001 11:12:55 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IFCs718379
	for ; Fri, 18 May 2001 11:12:54 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA17452; Fri, 18 May 2001 11:12:53 -0400 (EDT)
Cc: megaco@fore.com
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA17443; Fri, 18 May 2001 11:12:52 -0400 (EDT)
Message-ID: <3B053B7E.B777E546@lucent.com>
Date: Fri, 18 May 2001 11:10:54 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Groves 
Original-CC: megaco@fore.com
Subject: Re: Polls of MGC
References:  <3B04DAAC.29AFA9A3@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Christian Groves wrote:
> 
> G'Day,
> 
> I'd really like to understand the network scenario for adding this
> polling.
> As I see it the MGC can determine that an MG is down. ie. It issues a
> command and gets no response. It can take the appropriate action.
> Likewise the MG can determine when the MGC is down in the same way.
> Except that if the MGC its connected to is down the MG can't do much.
> Remember the MGC is the Master and the MG is the slave.

MGCP/NCS has a failover scheme involving multiple DNS entries.  Basically 
if the MG can't reach the MGC after X tries, it checks the DNS entry for 
another IP address and tries it.  (Actually it's fairly complicated with
attempt counts and timers, etc., but that's the idea.)

Any failover method needs to consider security.  It's not very good
if the MG accepts messages that say "I'm your MGC now" from anyone.


> I really don't see the benefit of the MG doing periodic polling. It will
> find something is wrong when it tries to signal the MGC.

I don't see the benefit either.  It'll find out when it tries to 
communicate something. Before then, it didn't need to know.  
The MGC might come back online before the MG needs it.  

Picture 5000 MGs polling an MGC.  That's a lot of traffic.  
If the MGC is down for 5 minutes, 5000 MGs detect it and 
switch over *somehow* to the backup MGC, then need to be 
switched back to the original.  That's a lot of traffic too.
If you let the MGs handle the problem as needed, maybe only 
a handful would have needed to.


> Without going to Servicechange methods, reasons etc. What's the benefit?
> 
> Cheers, Christian


From owner-megaco@fore.com  Fri May 18 11:34:16 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28857
	for ; Fri, 18 May 2001 11:34:16 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23909;
	Fri, 18 May 2001 11:18:45 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA00008
	for megaco-list; Fri, 18 May 2001 11:17:11 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA29986
	for ; Fri, 18 May 2001 11:17:00 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23634
	for ; Fri, 18 May 2001 11:16:54 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IFGtC22852
	for ; Fri, 18 May 2001 11:16:55 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IFGt722822
	for ; Fri, 18 May 2001 11:16:55 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA17687; Fri, 18 May 2001 11:16:54 -0400 (EDT)
Cc: "'knayar@hss.hns.com'" , megaco@fore.com
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA17673; Fri, 18 May 2001 11:16:52 -0400 (EDT)
Message-ID: <3B053C6E.99C589EE@lucent.com>
Date: Fri, 18 May 2001 11:14:54 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" 
Original-CC: "'knayar@hss.hns.com'" , megaco@fore.com
Subject: Re: Polls of MGC
References: <4FBEA8857476D311A03300204840E1CF01A6F63F@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Rosen, Brian" wrote:
> 
> This discussion is not specifically detecting failure of the
> MGC by timeout of response to a message.  It has to do with
> detecting failure of the MGC when there is no message flow.

Brian,

I think the question is why do we *NEED* to detect failure
when there is no message flow?  Why not wait and detect it
when the MG tries to send something?  (From the MGs view,
nothing has failed yet!)

-troy


From owner-megaco@fore.com  Fri May 18 11:36:43 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28936
	for ; Fri, 18 May 2001 11:36:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24962;
	Fri, 18 May 2001 11:25:23 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA02062
	for megaco-list; Fri, 18 May 2001 11:23:57 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA02044
	for ; Fri, 18 May 2001 11:23:54 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 11:23:20 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F641@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Dan Elbert'" , megaco@fore.com
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 11:23:51 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

If you add a method in the Implementor's Guide, that's a change to
the spec.  If you do it in something like a profile, it wouldn't be.

You need a parameter so the MGC can control rates.  That would have
to be in a package, and both sides would have to implement it.

Brian

> -----Original Message-----
> From: Dan Elbert [mailto:DElbert@radvision.com]
> Sent: Friday, May 18, 2001 11:12 AM
> To: megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> In the protocol it says that the ServiceChange method can 
> also be "Another
> value whose meaning is mutually understood between the MG and 
> the MGC" so I
> think that specifying a "noop" value in the Implementor's 
> guide is covered
> under this. 
> The problem with the package is that it has to be implemented 
> by both sides
> to work, and making the package "mandatory" also implies a 
> modification of
> the spec.
> The SVC will work even if only the MG implements it, because 
> the MGC should
> reply to this even if the method is unknown to him.
> 
> Dan
> 
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Friday, May 18, 2001 10:52 AM
> To: 'knayar@hss.hns.com'
> Cc: megaco@fore.com
> Subject: RE: Polls of MGC
> 
> This discussion is not specifically detecting failure of the
> MGC by timeout of response to a message.  It has to do with
> detecting failure of the MGC when there is no message flow.
> The poll CREATES a message for the purpose of seeing if it
> can get a response.  If, during the processing of the poll,
> it gets no response, then it initiates failover procedures
> as documented. "No Response" to the poll is exactly the same
> as no response to a normal message.
> 
> It is possible to use SC if you add a no-op method.  It is
> possible to control frequency at the MGC by having a settable
> parameter on root.  That is, to me, an acceptable answer,
> but adding the no-op actually changes the protocol. 
> The advantage of the package with the event is that it's a normal
> package, and can be standardized without modifying RFC3015
> and Recommendation H.248.  Trying to do this with an "Implementor's
> Guide" seems to me to be stretching the definition of "Guide"
> pretty far.  Alternatively, this can be deferred to a future
> revision.
> 
> Brian
> 
> 
> 
> > -----Original Message-----
> > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com]
> > Sent: Friday, May 18, 2001 9:46 AM
> > To: Rosen, Brian
> > Cc: 'Christian Groves'; megaco@fore.com
> > Subject: RE: Polls of MGC
> >
> >
> >
> >
> > Hi Brian
> >
> > I think what Christian is pointing out is that do we really
> > need polling......
> > The question is that in case of unreliable transport protocol
> > like UDP whether
> > the MGC ( or MG) should be allowed to wait for timeout of "a
> > reply to a valid
> > request message" (like ADD, MODIFY etc. from MGC and NOTIFY,
> > SVC from MG) to
> > detect failure of the other end. Or else, there should be a
> > mechanism in built
> > in the MEGACO protocol to detect a MG or MGC failure....seems
> > a better option
> > though it has an added overhead of polling.
> >
> > Now, if we decide to introduce polling......the next issue is
> > how to add
> > one.....
> > There are two proposals....
> > 1.   Through a notify...event "noop" with a delay parameter
> > which controls the
> > frequency of polling.
> >      But, this I think has a dependency that this poll can
> > only be initiated by
> > MGC thru' activation of an event descriptor.
> > 2.   Alternatively, we can use Service Change with "noop"
> > method and add a
> > property to Base Root package "normalMGCIdleTime....or
> > normalMGCPollTime". This
> > is the polling timeout duration provisioned at MG and
> > settable by MGC at
> > runtime.
> > If MGC sets the value of this timer at runtime, MG should
> > restart the polling
> > timer. Additionally, we can put a guideline that in case the
> > MG or MGC receives
> > either a valid request or a valid reply from the other end
> > within a polling
> > interval, the SVC "noop" need not be sent at the expiry of
> > that polling
> > interval. Since service change can be sent by both MG and MGC
> > this gives a
> > suitable solution for polling.
> >
> > The concern about controlling the polling thru' MGC is
> > addressed suitable by
> > both the alternatives.
> >
> > Thanks,
> > -Kapil Nayar
> > Hughes Software Systems
> >
> >
> >
> >
> >
> > "Rosen, Brian"  on 05/18/2001 06:22:46 PM
> >
> > To:   "'Christian Groves'" ,
> > megaco@fore.com
> > cc:    (bcc: Kapil Nayar/HSS)
> >
> > Subject:  RE: Polls of MGC
> >
> >
> >
> >
> > Christian
> >
> > Everyone agrees that the way the MGC finds out if an MG is down is
> > to send a message and look for a response.  There are quite
> > a few messages an MGC could use.  I've suggested an audit.
> >
> > Everyone also agrees that the way the MG finds out if the 
> MGC is down
> > is to send a message and get a response.  It would presumably have
> > some timer that is reset by any message from the MGC.  If the timer
> > expired, it would send a message (a poll), and look for a reply.
> >
> > There are two issues:
> > 1. What message do you send?  MGs only send two messages,
> > ServiceChange
> > and Notify.  The first series of messages on this thread 
> talked about
> > using SC as the message.  The issue is how to construct an SC
> > which does not change the MGCs notion of the MG state (ie behave
> > as a no-op).  The second set of messages talked about using Notify
> > as the poll
> >
> > 2. How fast do you poll? The MGC really ought to be able to control
> > the frequency of polls, which would depend on how many MGs it was
> > controlling.  For this reason, we have been talking about
> > using Notify,
> > with an interval parameter, which would be set by the MGC to control
> > the polling.  Using SC, even if you could, there is no way for the
> > MGC to control the polling rate.
> >
> > If the MGC is down, the MG can do the right thing, which is 
> to contact
> > an alternate MGC for service.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > > Sent: Friday, May 18, 2001 4:18 AM
> > > To: megaco@fore.com
> > > Subject: Re: Polls of MGC
> > >
> > >
> > > G'Day,
> > >
> > > I'd really like to understand the network scenario for adding this
> > > polling.
> > > As I see it the MGC can determine that an MG is down. ie.
> > It issues a
> > > command and gets no response. It can take the appropriate action.
> > > Likewise the MG can determine when the MGC is down in the 
> same way.
> > > Except that if the MGC its connected to is down the MG
> > can't do much.
> > > Remember the MGC is the Master and the MG is the slave.
> > >
> > > I really don't see the benefit of the MG doing periodic
> > > polling. It will
> > > find something is wrong when it tries to signal the MGC.
> > >
> > > Without going to Servicechange methods, reasons etc. What's
> > > the benefit?
> > >
> > > Cheers, Christian
> > >
> > >
> >
> >
> >
> >
> 


From owner-megaco@fore.com  Fri May 18 11:37:55 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28956
	for ; Fri, 18 May 2001 11:37:54 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25124;
	Fri, 18 May 2001 11:26:22 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA02253
	for megaco-list; Fri, 18 May 2001 11:24:40 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA02246
	for ; Fri, 18 May 2001 11:24:38 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24793
	for ; Fri, 18 May 2001 11:24:32 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 10:25:06 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD949458110F9@RADVPOST>
From: Dan Elbert 
To: "'Troy Cauble'" 
Cc: megaco@fore.com
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 10:25:01 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

The difference with MGCP is that in MGCP when the MGC comes up it know how
to contact the MGs ( they listen in a default or configured port) , but in
Megaco the MGC only knows the MG port after the MG connects to it. If the
MGC goes down normally this information can be saved, but if it fails and
this information is lost, in some situations there is no way for the MG and
MGC to connect to each other again.

Dan

-----Original Message-----
From: Troy Cauble [mailto:troy@lucent.com]
Sent: Friday, May 18, 2001 11:11 AM
To: Christian Groves
Cc: megaco@fore.com
Subject: Re: Polls of MGC

Christian Groves wrote:
>
> G'Day,
>
> I'd really like to understand the network scenario for adding this
> polling.
> As I see it the MGC can determine that an MG is down. ie. It issues a
> command and gets no response. It can take the appropriate action.
> Likewise the MG can determine when the MGC is down in the same way.
> Except that if the MGC its connected to is down the MG can't do much.
> Remember the MGC is the Master and the MG is the slave.

MGCP/NCS has a failover scheme involving multiple DNS entries.  Basically
if the MG can't reach the MGC after X tries, it checks the DNS entry for
another IP address and tries it.  (Actually it's fairly complicated with
attempt counts and timers, etc., but that's the idea.)

Any failover method needs to consider security.  It's not very good
if the MG accepts messages that say "I'm your MGC now" from anyone.


> I really don't see the benefit of the MG doing periodic polling. It will
> find something is wrong when it tries to signal the MGC.

I don't see the benefit either.  It'll find out when it tries to
communicate something. Before then, it didn't need to know. 
The MGC might come back online before the MG needs it. 

Picture 5000 MGs polling an MGC.  That's a lot of traffic. 
If the MGC is down for 5 minutes, 5000 MGs detect it and
switch over *somehow* to the backup MGC, then need to be
switched back to the original.  That's a lot of traffic too.
If you let the MGs handle the problem as needed, maybe only
a handful would have needed to.


> Without going to Servicechange methods, reasons etc. What's the benefit?
>
> Cheers, Christian


From owner-megaco@fore.com  Fri May 18 11:38:35 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28985
	for ; Fri, 18 May 2001 11:38:35 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24670;
	Fri, 18 May 2001 11:23:47 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA01653
	for megaco-list; Fri, 18 May 2001 11:22:35 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA01645
	for ; Fri, 18 May 2001 11:22:33 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 11:21:59 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F640@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Troy Cauble'" 
Cc: "'knayar@hss.hns.com'" , megaco@fore.com
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 11:22:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Y'know, I've asked myself that.  I'm not sure I'd use it IFF
the whole process of finding an MGC and getting back up was fast
enough to not cause problems with subscribers.

My conclusion is that it COULD take a long time, and thus I think
finding it out sooner is better.  I don't feel so strongly that
I think we just GOTTA change the protocol.

Brian

> -----Original Message-----
> From: Troy Cauble [mailto:troy@lucent.com]
> Sent: Friday, May 18, 2001 11:15 AM
> To: Rosen, Brian
> Cc: 'knayar@hss.hns.com'; megaco@fore.com
> Subject: Re: Polls of MGC
> 
> 
> "Rosen, Brian" wrote:
> > 
> > This discussion is not specifically detecting failure of the
> > MGC by timeout of response to a message.  It has to do with
> > detecting failure of the MGC when there is no message flow.
> 
> Brian,
> 
> I think the question is why do we *NEED* to detect failure
> when there is no message flow?  Why not wait and detect it
> when the MG tries to send something?  (From the MGs view,
> nothing has failed yet!)
> 
> -troy
> 


From owner-megaco@fore.com  Fri May 18 11:41:37 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29080
	for ; Fri, 18 May 2001 11:41:36 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26160;
	Fri, 18 May 2001 11:33:35 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA03994
	for megaco-list; Fri, 18 May 2001 11:32:12 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03986
	for ; Fri, 18 May 2001 11:32:11 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id LAA25890
	for ; Fri, 18 May 2001 11:32:04 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id LAA09661; Fri, 18 May 2001 11:31:59 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Fri, 18 May 2001 11:31:44 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 18 May 2001 11:31:46 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB71@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Dan Elbert'" ,
        "'megaco@fore.com'" 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Fri, 18 May 2001 11:31:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DFAF.A3C4ABE0"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DFAF.A3C4ABE0
Content-Type: text/plain;
	charset="ISO-8859-1"

Hi.

> -----Original Message-----
> From: Dan Elbert [mailto:DElbert@radvision.com]
> Sent: Friday, May 18, 2001 11:06 AM
> To: 'megaco@fore.com'
> Subject: Use of ServiceChange from MGC to MG
> 
> 
> Hi 
> 
> The Media Gateway Controller may indicate that Termination(s) 
> shall be taken
> out of or returned to service.
> 1. What is the meaning of the MGC taking down a termination ? 
> Does it means
> that the termination is substracted from any active context 
> and all signal
> are stopped and no events are detected ?

Yes

> 2. What methods are used for taking the MG down and up ? I'd 
> say Graceful
> and Restart. Is this OK ?

"Taking the MG down" to me means doing a ServiceChange on ROOT at the MG.
It's possible the MGC might do that to an MG, but most likely in that case
that it would be done under manual control (i.e. the network is set up such
that control of MGs is exercised through the MGC).  I don't see this as a
typical maintence arrangement.

> 3. Is this applicable also to the root termination ? I would 
> say no because
> if the root termination "goes down" then logically the MG may 
> not be able to
> receive any more MGC commands.

Upon recovery the MG would follow normal start-up procedures to establish a
new control association.

> 
> Thanks,
> 
> Dan Elbert
> RADVISION
> 

------_=_NextPart_001_01C0DFAF.A3C4ABE0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Use of ServiceChange from MGC to MG




Hi.




> -----Original Message-----

> From: Dan Elbert [mailto:DElbert@radvision.com]<=
/FONT>

> Sent: Friday, May 18, 2001 11:06 AM

> To: 'megaco@fore.com'

> Subject: Use of ServiceChange from MGC to =
MG

> 

> 

> Hi 

> 

> The Media Gateway Controller may indicate that =
Termination(s) 

> shall be taken

> out of or returned to service.

> 1. What is the meaning of the MGC taking down a =
termination ? 

> Does it means

> that the termination is substracted from any =
active context 

> and all signal

> are stopped and no events are detected ?




Yes




> 2. What methods are used for taking the MG down =
and up ? I'd 

> say Graceful

> and Restart. Is this OK ?




"Taking the MG down" to me means doing a =
ServiceChange on ROOT at the MG.

It's possible the MGC might do that to an MG, but =
most likely in that case that it would be done under manual control =
(i.e. the network is set up such that control of MGs is exercised =
through the MGC).  I don't see this as a typical maintence =
arrangement.



> 3. Is this applicable also to the root =
termination ? I would 

> say no because

> if the root termination "goes down" =
then logically the MG may 

> not be able to

> receive any more MGC commands.




Upon recovery the MG would follow normal start-up =
procedures to establish a new control association.




> 

> Thanks,

> 

> Dan Elbert

> RADVISION

> 





------_=_NextPart_001_01C0DFAF.A3C4ABE0--


From owner-megaco@fore.com  Fri May 18 11:42:49 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29133
	for ; Fri, 18 May 2001 11:42:49 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26005;
	Fri, 18 May 2001 11:32:40 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA03860
	for megaco-list; Fri, 18 May 2001 11:31:21 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03854
	for ; Fri, 18 May 2001 11:31:18 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25781
	for ; Fri, 18 May 2001 11:31:12 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACS13178;
	Fri, 18 May 2001 11:31:12 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Dan Elbert'" , 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Fri, 18 May 2001 11:35:16 -0400
Message-ID: <023d01c0dfb0$23b645c0$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <0D5BBF5D638DD4119E3400508BD949458110F7@RADVPOST>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

HI Dan,
Comments below [Madhu]

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dan Elbert
Sent: Friday, May 18, 2001 11:06 AM
To: 'megaco@fore.com'
Subject: Use of ServiceChange from MGC to MG


Hi

The Media Gateway Controller may indicate that Termination(s) shall be taken
out of or returned to service.

1. What is the meaning of the MGC taking down a termination ? Does it means
that the termination is substracted from any active context and all signal
are stopped and no events are detected ?
[Madhu] IMO its similar to the situation where MG generates such
servicechange.
The signals to be stopped and no event detection.
Will be useful in
1) Residential Gateway - Where the user profile is not encouraging and the
MGC doesn't
want to entertain any messages generated from the MG for that endpoint.
2) Trunking gateway - Remove some of the trunks from the initial provisioned
trunks.

2. What methods are used for taking the MG down and up ? I'd say Graceful
and Restart. Is this OK ?
[Madhu] I think Graceful is a mean by which MG can say to MGC that this
particular termination
shouldn't be used for further calls. Graceful has no meaning when MGC
generates this. I think the
methods should be "forced" and "restart".

3. Is this applicable also to the root termination ? I would say no because
if the root termination "goes down" then logically the MG may not be able to
receive any more MGC commands.
[Madhu] Yes. Your argument is correct.

Thanks,

Dan Elbert
RADVISION



From owner-megaco@fore.com  Fri May 18 11:46:47 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29250
	for ; Fri, 18 May 2001 11:46:47 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26957;
	Fri, 18 May 2001 11:39:53 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA05049
	for megaco-list; Fri, 18 May 2001 11:37:27 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA05043
	for ; Fri, 18 May 2001 11:37:26 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 11:36:51 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F643@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Tom-PT Taylor'" ,
        "'Dan Elbert'"
	 ,
        "'megaco@fore.com'" 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Fri, 18 May 2001 11:37:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0DFB0.6DFE14A0"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DFB0.6DFE14A0
Content-Type: text/plain;
	charset="ISO-8859-1"

One thing I think is incorrect here is the "Subtracted from any active
contexts" part.  I believe we defined the protocol so that this NEVER
happens
as a side-effect.  The termination may actually be out of service, but both
the MG and the MGC have it in a context if it was when the termination was
taken out of service.
 
It is always incumbant on the MGC to do the subtract explicitly.
 
The ONLY exception to this is restart of the MG; all contexts are lost.
 
Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Friday, May 18, 2001 11:32 AM
To: 'Dan Elbert'; 'megaco@fore.com'
Subject: RE: Use of ServiceChange from MGC to MG



Hi. 

> -----Original Message----- 
> From: Dan Elbert [ mailto:DElbert@radvision.com
 ] 
> Sent: Friday, May 18, 2001 11:06 AM 
> To: 'megaco@fore.com' 
> Subject: Use of ServiceChange from MGC to MG 
> 
> 
> Hi 
> 
> The Media Gateway Controller may indicate that Termination(s) 
> shall be taken 
> out of or returned to service. 
> 1. What is the meaning of the MGC taking down a termination ? 
> Does it means 
> that the termination is substracted from any active context 
> and all signal 
> are stopped and no events are detected ? 

Yes 

> 2. What methods are used for taking the MG down and up ? I'd 
> say Graceful 
> and Restart. Is this OK ? 

"Taking the MG down" to me means doing a ServiceChange on ROOT at the MG. 
It's possible the MGC might do that to an MG, but most likely in that case
that it would be done under manual control (i.e. the network is set up such
that control of MGs is exercised through the MGC).  I don't see this as a
typical maintence arrangement.

> 3. Is this applicable also to the root termination ? I would 
> say no because 
> if the root termination "goes down" then logically the MG may 
> not be able to 
> receive any more MGC commands. 

Upon recovery the MG would follow normal start-up procedures to establish a
new control association. 

> 
> Thanks, 
> 
> Dan Elbert 
> RADVISION 
> 


------_=_NextPart_001_01C0DFB0.6DFE14A0
Content-Type: text/html;
	charset="ISO-8859-1"




RE: Use of ServiceChange from MGC to MG




One thing I 
think is incorrect here is the "Subtracted from any active


contexts" 
part.  I believe we defined the protocol so that this NEVER 
happens


as a 
side-effect.  The termination may actually be out of service, but 
both


the MG and 
the MGC have it in a context if it was when the termination 
was


taken out of 
service.


 


It is always 
incumbant on the MGC to do the subtract explicitly.


 


The ONLY 
exception to this is restart of the MG; all contexts are 
lost.


 


Brian



  
-----Original Message-----
From: Tom-PT Taylor 
  [mailto:taylor@nortelnetworks.com]
Sent: Friday, May 18, 2001 11:32 
  AM
To: 'Dan Elbert'; 'megaco@fore.com'
Subject: RE: Use of 
  ServiceChange from MGC to MG


  
Hi. 

  
> -----Original Message----- 
> 
  From: Dan Elbert [mailto:DElbert@radvision.com] 
  
> Sent: Friday, May 18, 2001 11:06 AM 
> To: 'megaco@fore.com' 
> Subject: Use of 
  ServiceChange from MGC to MG 
> 
> 
> Hi 
> 
  
> The Media Gateway Controller may indicate that 
  Termination(s) 
> shall be taken 
> out of or returned to service. 
> 1. 
  What is the meaning of the MGC taking down a termination ? 
> Does it means 
> that the termination is 
  substracted from any active context 
> and all 
  signal 
> are stopped and no events are detected 
  ? 

  
Yes 

  
> 2. What methods are used for taking the MG down and up ? 
  I'd 
> say Graceful 
> and 
  Restart. Is this OK ? 

  
"Taking the MG down" to me means doing a ServiceChange on ROOT 
  at the MG. 
It's possible the MGC might do that to an 
  MG, but most likely in that case that it would be done under manual control 
  (i.e. the network is set up such that control of MGs is exercised through the 
  MGC).  I don't see this as a typical maintence arrangement.

  
> 3. Is this applicable also to the root termination ? I 
  would 
> say no because 
> 
  if the root termination "goes down" then logically the MG may 
> not be able to 
> receive any more MGC 
  commands. 

  
Upon recovery the MG would follow normal start-up procedures 
  to establish a new control association. 

  
> 
> Thanks, 
> 
> Dan Elbert 
> RADVISION 
> 



------_=_NextPart_001_01C0DFB0.6DFE14A0--


From owner-megaco@fore.com  Fri May 18 11:50:38 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29372
	for ; Fri, 18 May 2001 11:50:38 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27384;
	Fri, 18 May 2001 11:42:46 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA06188
	for megaco-list; Fri, 18 May 2001 11:41:56 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA06173
	for ; Fri, 18 May 2001 11:41:53 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27234
	for ; Fri, 18 May 2001 11:41:47 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IFfmC22182
	for ; Fri, 18 May 2001 11:41:48 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IFfm722178
	for ; Fri, 18 May 2001 11:41:48 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA18325; Fri, 18 May 2001 11:41:46 -0400 (EDT)
Cc: "'knayar@hss.hns.com'" , megaco@fore.com
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA18311; Fri, 18 May 2001 11:41:44 -0400 (EDT)
Message-ID: <3B054242.5C227B4F@lucent.com>
Date: Fri, 18 May 2001 11:39:46 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" 
Original-CC: "'knayar@hss.hns.com'" , megaco@fore.com
Subject: Re: Polls of MGC
References: <4FBEA8857476D311A03300204840E1CF01A6F640@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Rosen, Brian" wrote:
> 
> Y'know, I've asked myself that.  I'm not sure I'd use it IFF
> the whole process of finding an MGC and getting back up was fast
> enough to not cause problems with subscribers.

I haven't followed this thread enough to know if the "process"
is even known yet.  (I mostly obsess on the parsing issues.)

I think the MGCP/NCS use of DNS is fairly good, but I doubt 
the timer & count values are such that, for example, it's not
visible to a user in a residential gateway situation.

But MGC failure will be a non-frequent event, so I think
that some small amount of recovery time is OK and better than
the alternative of polling.


> My conclusion is that it COULD take a long time, and thus I think
> finding it out sooner is better.  I don't feel so strongly that
> I think we just GOTTA change the protocol.


In terms of the "process" being fast:  How fast is it
going to be for the MGs that need to get through to a new MGC 
because they're trying to put a call though, when 2000 MGs with
no immediate beat them to it because of their polling cycle.

I think that polling is a bad idea in either direction.

-troy

> 
> Brian
> 
> > -----Original Message-----
> > From: Troy Cauble [mailto:troy@lucent.com]
> > Sent: Friday, May 18, 2001 11:15 AM
> > To: Rosen, Brian
> > Cc: 'knayar@hss.hns.com'; megaco@fore.com
> > Subject: Re: Polls of MGC
> >
> >
> > "Rosen, Brian" wrote:
> > >
> > > This discussion is not specifically detecting failure of the
> > > MGC by timeout of response to a message.  It has to do with
> > > detecting failure of the MGC when there is no message flow.
> >
> > Brian,
> >
> > I think the question is why do we *NEED* to detect failure
> > when there is no message flow?  Why not wait and detect it
> > when the MG tries to send something?  (From the MGs view,
> > nothing has failed yet!)
> >
> > -troy
> >


From owner-megaco@fore.com  Fri May 18 11:55:20 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29470
	for ; Fri, 18 May 2001 11:55:19 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA28161;
	Fri, 18 May 2001 11:47:42 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA07194
	for megaco-list; Fri, 18 May 2001 11:46:05 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA07190
	for ; Fri, 18 May 2001 11:46:03 -0400 (EDT)
Received: from slink12.ss7-link.com (mail.ss7-link.com [209.204.106.218])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27856
	for ; Fri, 18 May 2001 11:45:58 -0400 (EDT)
Received: by SLINK12 with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 11:46:00 -0400
Message-ID: 
From: Dave Sclarsky 
To: "'Rosen, Brian'" ,
        "'knayar@hss.hns.com'"
	 
Cc: megaco@fore.com
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 11:45:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Brian,
I agree that adding a package is a simpler process than changing the specs.
But I still have one nagging problem with making this an event on ROOT -
does it prevent any future package from defining signals on ROOT?  Maybe the
interaction of events and signals is reason enough to avoid defining either
of them in packages for use on ROOT.
Do you see this as a potential problem?
DaveS.

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Friday, May 18, 2001 10:52 AM
To: 'knayar@hss.hns.com'
Cc: megaco@fore.com
Subject: RE: Polls of MGC


This discussion is not specifically detecting failure of the
MGC by timeout of response to a message.  It has to do with
detecting failure of the MGC when there is no message flow.
The poll CREATES a message for the purpose of seeing if it
can get a response.  If, during the processing of the poll,
it gets no response, then it initiates failover procedures
as documented. "No Response" to the poll is exactly the same
as no response to a normal message.

It is possible to use SC if you add a no-op method.  It is 
possible to control frequency at the MGC by having a settable
parameter on root.  That is, to me, an acceptable answer,
but adding the no-op actually changes the protocol.  
The advantage of the package with the event is that it's a normal 
package, and can be standardized without modifying RFC3015
and Recommendation H.248.  Trying to do this with an "Implementor's
Guide" seems to me to be stretching the definition of "Guide"
pretty far.  Alternatively, this can be deferred to a future
revision.

Brian



> -----Original Message-----
> From: knayar@hss.hns.com [mailto:knayar@hss.hns.com]
> Sent: Friday, May 18, 2001 9:46 AM
> To: Rosen, Brian
> Cc: 'Christian Groves'; megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> 
> 
> Hi Brian
> 
> I think what Christian is pointing out is that do we really 
> need polling......
> The question is that in case of unreliable transport protocol 
> like UDP whether
> the MGC ( or MG) should be allowed to wait for timeout of "a 
> reply to a valid
> request message" (like ADD, MODIFY etc. from MGC and NOTIFY, 
> SVC from MG) to
> detect failure of the other end. Or else, there should be a 
> mechanism in built
> in the MEGACO protocol to detect a MG or MGC failure....seems 
> a better option
> though it has an added overhead of polling.
> 
> Now, if we decide to introduce polling......the next issue is 
> how to add
> one.....
> There are two proposals....
> 1.   Through a notify...event "noop" with a delay parameter 
> which controls the
> frequency of polling.
>      But, this I think has a dependency that this poll can 
> only be initiated by
> MGC thru' activation of an event descriptor.
> 2.   Alternatively, we can use Service Change with "noop" 
> method and add a
> property to Base Root package "normalMGCIdleTime....or 
> normalMGCPollTime". This
> is the polling timeout duration provisioned at MG and 
> settable by MGC at
> runtime.
> If MGC sets the value of this timer at runtime, MG should 
> restart the polling
> timer. Additionally, we can put a guideline that in case the 
> MG or MGC receives
> either a valid request or a valid reply from the other end 
> within a polling
> interval, the SVC "noop" need not be sent at the expiry of 
> that polling
> interval. Since service change can be sent by both MG and MGC 
> this gives a
> suitable solution for polling.
> 
> The concern about controlling the polling thru' MGC is 
> addressed suitable by
> both the alternatives.
> 
> Thanks,
> -Kapil Nayar
> Hughes Software Systems
> 
> 
> 
> 
> 
> "Rosen, Brian"  on 05/18/2001 06:22:46 PM
> 
> To:   "'Christian Groves'" , 
> megaco@fore.com
> cc:    (bcc: Kapil Nayar/HSS)
> 
> Subject:  RE: Polls of MGC
> 
> 
> 
> 
> Christian
> 
> Everyone agrees that the way the MGC finds out if an MG is down is
> to send a message and look for a response.  There are quite
> a few messages an MGC could use.  I've suggested an audit.
> 
> Everyone also agrees that the way the MG finds out if the MGC is down
> is to send a message and get a response.  It would presumably have
> some timer that is reset by any message from the MGC.  If the timer
> expired, it would send a message (a poll), and look for a reply.
> 
> There are two issues:
> 1. What message do you send?  MGs only send two messages, 
> ServiceChange
> and Notify.  The first series of messages on this thread talked about
> using SC as the message.  The issue is how to construct an SC
> which does not change the MGCs notion of the MG state (ie behave
> as a no-op).  The second set of messages talked about using Notify
> as the poll
> 
> 2. How fast do you poll? The MGC really ought to be able to control
> the frequency of polls, which would depend on how many MGs it was
> controlling.  For this reason, we have been talking about 
> using Notify,
> with an interval parameter, which would be set by the MGC to control
> the polling.  Using SC, even if you could, there is no way for the
> MGC to control the polling rate.
> 
> If the MGC is down, the MG can do the right thing, which is to contact
> an alternate MGC for service.
> 
> Brian
> 
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Friday, May 18, 2001 4:18 AM
> > To: megaco@fore.com
> > Subject: Re: Polls of MGC
> >
> >
> > G'Day,
> >
> > I'd really like to understand the network scenario for adding this
> > polling.
> > As I see it the MGC can determine that an MG is down. ie. 
> It issues a
> > command and gets no response. It can take the appropriate action.
> > Likewise the MG can determine when the MGC is down in the same way.
> > Except that if the MGC its connected to is down the MG 
> can't do much.
> > Remember the MGC is the Master and the MG is the slave.
> >
> > I really don't see the benefit of the MG doing periodic
> > polling. It will
> > find something is wrong when it tries to signal the MGC.
> >
> > Without going to Servicechange methods, reasons etc. What's
> > the benefit?
> >
> > Cheers, Christian
> >
> >
> 
> 
> 
> 


From owner-megaco@fore.com  Fri May 18 12:01:43 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29592
	for ; Fri, 18 May 2001 12:01:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA29260;
	Fri, 18 May 2001 11:54:08 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA08638
	for megaco-list; Fri, 18 May 2001 11:52:42 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08609
	for ; Fri, 18 May 2001 11:52:39 -0400 (EDT)
From: knayar@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA28802
	for ; Fri, 18 May 2001 11:52:26 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4IFre025712;
	Fri, 18 May 2001 21:23:40 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A50.0055D839 ; Fri, 18 May 2001 21:07:39 +0530
X-Lotus-FromDomain: HSS
To: Dan Elbert 
cc: megaco@fore.com
Message-ID: <65256A50.0055D7D1.00@sandesh.hss.hns.com>
Date: Fri, 18 May 2001 21:11:59 +0530
Subject: RE: Polls of MGC
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk



Hi Brian

If we have finally decided to add support for polling....there is another
suggestion
Add a service change reason "Poll" or "Noop" to be used with Service Change
Method "Restart"
I hope that doesn't change the spec....
And, add a new package BaseRootPoll package which extends BaseRoot Package.....
This way only those MGCs which support this new extended package can control the
polling frequency....else they just need to respond to the service change method
Restart reason Poll or Noop...

Thanks,
-Kapil Nayar
Hughes Software Systems





Dan Elbert  on 05/18/2001 08:42:28 PM

To:   megaco@fore.com
cc:    (bcc: Kapil Nayar/HSS)

Subject:  RE: Polls of MGC




In the protocol it says that the ServiceChange method can also be "Another
value whose meaning is mutually understood between the MG and the MGC" so I
think that specifying a "noop" value in the Implementor's guide is covered
under this.
The problem with the package is that it has to be implemented by both sides
to work, and making the package "mandatory" also implies a modification of
the spec.
The SVC will work even if only the MG implements it, because the MGC should
reply to this even if the method is unknown to him.

Dan

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Friday, May 18, 2001 10:52 AM
To: 'knayar@hss.hns.com'
Cc: megaco@fore.com
Subject: RE: Polls of MGC

This discussion is not specifically detecting failure of the
MGC by timeout of response to a message.  It has to do with
detecting failure of the MGC when there is no message flow.
The poll CREATES a message for the purpose of seeing if it
can get a response.  If, during the processing of the poll,
it gets no response, then it initiates failover procedures
as documented. "No Response" to the poll is exactly the same
as no response to a normal message.

It is possible to use SC if you add a no-op method.  It is
possible to control frequency at the MGC by having a settable
parameter on root.  That is, to me, an acceptable answer,
but adding the no-op actually changes the protocol.
The advantage of the package with the event is that it's a normal
package, and can be standardized without modifying RFC3015
and Recommendation H.248.  Trying to do this with an "Implementor's
Guide" seems to me to be stretching the definition of "Guide"
pretty far.  Alternatively, this can be deferred to a future
revision.

Brian



> -----Original Message-----
> From: knayar@hss.hns.com [mailto:knayar@hss.hns.com]
> Sent: Friday, May 18, 2001 9:46 AM
> To: Rosen, Brian
> Cc: 'Christian Groves'; megaco@fore.com
> Subject: RE: Polls of MGC
>
>
>
>
> Hi Brian
>
> I think what Christian is pointing out is that do we really
> need polling......
> The question is that in case of unreliable transport protocol
> like UDP whether
> the MGC ( or MG) should be allowed to wait for timeout of "a
> reply to a valid
> request message" (like ADD, MODIFY etc. from MGC and NOTIFY,
> SVC from MG) to
> detect failure of the other end. Or else, there should be a
> mechanism in built
> in the MEGACO protocol to detect a MG or MGC failure....seems
> a better option
> though it has an added overhead of polling.
>
> Now, if we decide to introduce polling......the next issue is
> how to add
> one.....
> There are two proposals....
> 1.   Through a notify...event "noop" with a delay parameter
> which controls the
> frequency of polling.
>      But, this I think has a dependency that this poll can
> only be initiated by
> MGC thru' activation of an event descriptor.
> 2.   Alternatively, we can use Service Change with "noop"
> method and add a
> property to Base Root package "normalMGCIdleTime....or
> normalMGCPollTime". This
> is the polling timeout duration provisioned at MG and
> settable by MGC at
> runtime.
> If MGC sets the value of this timer at runtime, MG should
> restart the polling
> timer. Additionally, we can put a guideline that in case the
> MG or MGC receives
> either a valid request or a valid reply from the other end
> within a polling
> interval, the SVC "noop" need not be sent at the expiry of
> that polling
> interval. Since service change can be sent by both MG and MGC
> this gives a
> suitable solution for polling.
>
> The concern about controlling the polling thru' MGC is
> addressed suitable by
> both the alternatives.
>
> Thanks,
> -Kapil Nayar
> Hughes Software Systems
>
>
>
>
>
> "Rosen, Brian"  on 05/18/2001 06:22:46 PM
>
> To:   "'Christian Groves'" ,
> megaco@fore.com
> cc:    (bcc: Kapil Nayar/HSS)
>
> Subject:  RE: Polls of MGC
>
>
>
>
> Christian
>
> Everyone agrees that the way the MGC finds out if an MG is down is
> to send a message and look for a response.  There are quite
> a few messages an MGC could use.  I've suggested an audit.
>
> Everyone also agrees that the way the MG finds out if the MGC is down
> is to send a message and get a response.  It would presumably have
> some timer that is reset by any message from the MGC.  If the timer
> expired, it would send a message (a poll), and look for a reply.
>
> There are two issues:
> 1. What message do you send?  MGs only send two messages,
> ServiceChange
> and Notify.  The first series of messages on this thread talked about
> using SC as the message.  The issue is how to construct an SC
> which does not change the MGCs notion of the MG state (ie behave
> as a no-op).  The second set of messages talked about using Notify
> as the poll
>
> 2. How fast do you poll? The MGC really ought to be able to control
> the frequency of polls, which would depend on how many MGs it was
> controlling.  For this reason, we have been talking about
> using Notify,
> with an interval parameter, which would be set by the MGC to control
> the polling.  Using SC, even if you could, there is no way for the
> MGC to control the polling rate.
>
> If the MGC is down, the MG can do the right thing, which is to contact
> an alternate MGC for service.
>
> Brian
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Friday, May 18, 2001 4:18 AM
> > To: megaco@fore.com
> > Subject: Re: Polls of MGC
> >
> >
> > G'Day,
> >
> > I'd really like to understand the network scenario for adding this
> > polling.
> > As I see it the MGC can determine that an MG is down. ie.
> It issues a
> > command and gets no response. It can take the appropriate action.
> > Likewise the MG can determine when the MGC is down in the same way.
> > Except that if the MGC its connected to is down the MG
> can't do much.
> > Remember the MGC is the Master and the MG is the slave.
> >
> > I really don't see the benefit of the MG doing periodic
> > polling. It will
> > find something is wrong when it tries to signal the MGC.
> >
> > Without going to Servicechange methods, reasons etc. What's
> > the benefit?
> >
> > Cheers, Christian
> >
> >
>
>
>
>






From owner-megaco@fore.com  Fri May 18 12:04:22 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29659
	for ; Fri, 18 May 2001 12:04:22 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA29873;
	Fri, 18 May 2001 11:58:20 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA09636
	for megaco-list; Fri, 18 May 2001 11:57:03 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA09621
	for ; Fri, 18 May 2001 11:57:01 -0400 (EDT)
From: knayar@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA29607
	for ; Fri, 18 May 2001 11:56:53 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4IFvnt25745;
	Fri, 18 May 2001 21:27:49 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A50.005639FA ; Fri, 18 May 2001 21:11:49 +0530
X-Lotus-FromDomain: HSS
To: Troy Cauble 
cc: Christian Groves , megaco@fore.com
Message-ID: <65256A50.005635A6.00@sandesh.hss.hns.com>
Date: Fri, 18 May 2001 21:19:08 +0530
Subject: Re: Polls of MGC
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk



Hi Troy

You have a very valid point......but what if the MGC goes down and doesnot come
up at all....the MGs (5000 of them) shall wait for
1. an event initiated by a subscriber action
2. a notify request sent to the MGC.
3. notify response timeout for configured "max number of retries" times
4. generate a new service change and get a valid response from another MGC
before they can service their respective subscriber's request..

Thanks,
-Kapil Nayar
Hughes Software Systems





Troy Cauble  on 05/18/2001 08:40:54 PM

Please respond to Troy Cauble 

To:   Christian Groves 
cc:   megaco@fore.com (bcc: Kapil Nayar/HSS)

Subject:  Re: Polls of MGC




Christian Groves wrote:
>
> G'Day,
>
> I'd really like to understand the network scenario for adding this
> polling.
> As I see it the MGC can determine that an MG is down. ie. It issues a
> command and gets no response. It can take the appropriate action.
> Likewise the MG can determine when the MGC is down in the same way.
> Except that if the MGC its connected to is down the MG can't do much.
> Remember the MGC is the Master and the MG is the slave.

MGCP/NCS has a failover scheme involving multiple DNS entries.  Basically
if the MG can't reach the MGC after X tries, it checks the DNS entry for
another IP address and tries it.  (Actually it's fairly complicated with
attempt counts and timers, etc., but that's the idea.)

Any failover method needs to consider security.  It's not very good
if the MG accepts messages that say "I'm your MGC now" from anyone.


> I really don't see the benefit of the MG doing periodic polling. It will
> find something is wrong when it tries to signal the MGC.

I don't see the benefit either.  It'll find out when it tries to
communicate something. Before then, it didn't need to know.
The MGC might come back online before the MG needs it.

Picture 5000 MGs polling an MGC.  That's a lot of traffic.
If the MGC is down for 5 minutes, 5000 MGs detect it and
switch over *somehow* to the backup MGC, then need to be
switched back to the original.  That's a lot of traffic too.
If you let the MGs handle the problem as needed, maybe only
a handful would have needed to.


> Without going to Servicechange methods, reasons etc. What's the benefit?
>
> Cheers, Christian








From owner-megaco@fore.com  Fri May 18 12:04:33 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29670
	for ; Fri, 18 May 2001 12:04:32 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA29893;
	Fri, 18 May 2001 11:58:25 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA09661
	for megaco-list; Fri, 18 May 2001 11:57:11 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA09655
	for ; Fri, 18 May 2001 11:57:09 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id LAA29644
	for ; Fri, 18 May 2001 11:57:03 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id LAA12205; Fri, 18 May 2001 11:56:59 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 18 May 2001 11:56:52 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 18 May 2001 11:56:55 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB72@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Rosen, Brian'" ,
        "'Dan Elbert'" ,
        "'megaco@fore.com'" 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Fri, 18 May 2001 11:56:51 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DFB3.27067AD0"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DFB3.27067AD0
Content-Type: text/plain;
	charset="ISO-8859-1"

I was thinking of what the colloquial expression "take down a termination"
might mean.  This expression is NOT defined in the protocol specification.
The precise answer to Dan's question 1 is that "taken out of service" means
that the ServiceState parameter in TerminationState is changed to "Out of
Service", with resulting constraints on what commands can be applied to it.
The phrase "taking down a termination" is not defined in the protocol, so
you have to ask whoever uses it what they mean.
 
 -----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Friday, May 18, 2001 11:37 AM
To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Dan Elbert'; 'megaco@fore.com'
Subject: RE: Use of ServiceChange from MGC to MG



One thing I think is incorrect here is the "Subtracted from any active
contexts" part.  I believe we defined the protocol so that this NEVER
happens
as a side-effect.  The termination may actually be out of service, but both
the MG and the MGC have it in a context if it was when the termination was
taken out of service.
 
It is always incumbant on the MGC to do the subtract explicitly.
 
The ONLY exception to this is restart of the MG; all contexts are lost.
 
Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Friday, May 18, 2001 11:32 AM
To: 'Dan Elbert'; 'megaco@fore.com'
Subject: RE: Use of ServiceChange from MGC to MG



Hi. 

> -----Original Message----- 
> From: Dan Elbert [ mailto:DElbert@radvision.com
 ] 
> Sent: Friday, May 18, 2001 11:06 AM 
> To: 'megaco@fore.com' 
> Subject: Use of ServiceChange from MGC to MG 
> 
> 
> Hi 
> 
> The Media Gateway Controller may indicate that Termination(s) 
> shall be taken 
> out of or returned to service. 
> 1. What is the meaning of the MGC taking down a termination ? 
> Does it means 
> that the termination is substracted from any active context 
> and all signal 
> are stopped and no events are detected ? 

Yes 

> 2. What methods are used for taking the MG down and up ? I'd 
> say Graceful 
> and Restart. Is this OK ? 

"Taking the MG down" to me means doing a ServiceChange on ROOT at the MG. 
It's possible the MGC might do that to an MG, but most likely in that case
that it would be done under manual control (i.e. the network is set up such
that control of MGs is exercised through the MGC).  I don't see this as a
typical maintence arrangement.

> 3. Is this applicable also to the root termination ? I would 
> say no because 
> if the root termination "goes down" then logically the MG may 
> not be able to 
> receive any more MGC commands. 

Upon recovery the MG would follow normal start-up procedures to establish a
new control association. 

> 
> Thanks, 
> 
> Dan Elbert 
> RADVISION 
> 


------_=_NextPart_001_01C0DFB3.27067AD0
Content-Type: text/html;
	charset="ISO-8859-1"




RE: Use of ServiceChange from MGC to MG




I was 
thinking of what the colloquial expression "take down a termination" might 
mean.  This expression is NOT defined in the protocol specification.  
The precise answer to Dan's question 1 is that "taken out of service" means 
that the ServiceState parameter in TerminationState is changed to "Out of 
Service", with resulting constraints on what commands can be applied to 
it.  The phrase "taking down a termination" is not defined in the protocol, 
so you have to ask whoever uses it what they mean.


 


 -----Original Message-----
From: 
Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Friday, May 18, 
2001 11:37 AM
To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Dan Elbert'; 
'megaco@fore.com'
Subject: RE: Use of ServiceChange from MGC to 
MG




  
One thing I 
  think is incorrect here is the "Subtracted from any active

  
contexts" 
  part.  I believe we defined the protocol so that this NEVER 
  happens

  
as a 
  side-effect.  The termination may actually be out of service, but 
  both

  
the MG and 
  the MGC have it in a context if it was when the termination 
  was

  
taken out 
  of service.

  
 

  
It is 
  always incumbant on the MGC to do the subtract explicitly.

  
 

  
The ONLY 
  exception to this is restart of the MG; all contexts are 
  lost.

  
 

  
Brian

  

    
-----Original Message-----
From: Tom-PT Taylor 
    [mailto:taylor@nortelnetworks.com]
Sent: Friday, May 18, 2001 
    11:32 AM
To: 'Dan Elbert'; 'megaco@fore.com'
Subject: 
    RE: Use of ServiceChange from MGC to MG


    
Hi. 

    
> -----Original Message----- 
> 
    From: Dan Elbert [mailto:DElbert@radvision.com] 
    
> Sent: Friday, May 18, 2001 11:06 AM 
> To: 'megaco@fore.com' 
> Subject: Use 
    of ServiceChange from MGC to MG 
> 
    
> 
> Hi 
    
> 
> The Media Gateway 
    Controller may indicate that Termination(s) 
> 
    shall be taken 
> out of or returned to 
    service. 
> 1. What is the meaning of the MGC 
    taking down a termination ? 
> Does it 
    means 
> that the termination is substracted from 
    any active context 
> and all signal 
    
> are stopped and no events are detected ? 

    
Yes 

    
> 2. What methods are used for taking the MG down and up 
    ? I'd 
> say Graceful 
> 
    and Restart. Is this OK ? 

    
"Taking the MG down" to me means doing a ServiceChange on 
    ROOT at the MG. 
It's possible the MGC might do that 
    to an MG, but most likely in that case that it would be done under manual 
    control (i.e. the network is set up such that control of MGs is exercised 
    through the MGC).  I don't see this as a typical maintence 
    arrangement.

    
> 3. Is this applicable also to the root termination ? I 
    would 
> say no because 
> if the root termination "goes down" then logically the MG may 
    
> not be able to 
> 
    receive any more MGC commands. 

    
Upon recovery the MG would follow normal start-up procedures 
    to establish a new control association. 

    
> 
> Thanks, 
> 
> Dan Elbert 
> RADVISION 
> 



------_=_NextPart_001_01C0DFB3.27067AD0--


From owner-megaco@fore.com  Fri May 18 12:05:04 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29699
	for ; Fri, 18 May 2001 12:05:04 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20407;
	Fri, 18 May 2001 10:53:54 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA23611
	for megaco-list; Fri, 18 May 2001 10:52:20 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23596
	for ; Fri, 18 May 2001 10:52:17 -0400 (EDT)
Received: from ns02.newbridge.com (ns02.newbridge.com [192.75.23.75])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA20028
	for ; Fri, 18 May 2001 10:52:11 -0400 (EDT)
Received: (qmail 3361 invoked from network); 18 May 2001 14:49:23 -0000
Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76)
  by ns02.newbridge.com with SMTP; 18 May 2001 14:49:23 -0000
Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for megaco@fore.com; Fri, 18 May 2001 10:48:28 -0400
Received: from alcatel.com ([138.120.45.50]) by kanmail02.ca.newbridge.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAA2C4B
          for ; Fri, 18 May 2001 10:48:27 -0400
Message-Id: <3B05363B.9A545D22@alcatel.com>
Date: Fri, 18 May 2001 10:48:27 -0400
From: Ian Leighton 
Organization: Alcatel CID
X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Polls of MGC
References: <65256A50.004AED4D.00@sandesh.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Unless I'am missing something, polling is a requirement for
Trunking MG's which are registered and the MGC fails. The
Trunking MG  application does not require Notify messaging and
ServiceChange messages are sent infrequently (eg. on facility
failures). Without polling how would the Trunking MG
initiate re-registration proceedures with its list of alternate
(and primary) MGC's.

Regards
Ian

knayar@hss.hns.com wrote:

> Hi Brian
>
> I think what Christian is pointing out is that do we really need polling......
> The question is that in case of unreliable transport protocol like UDP whether
> the MGC ( or MG) should be allowed to wait for timeout of "a reply to a valid
> request message" (like ADD, MODIFY etc. from MGC and NOTIFY, SVC from MG) to
> detect failure of the other end. Or else, there should be a mechanism in built
> in the MEGACO protocol to detect a MG or MGC failure....seems a better option
> though it has an added overhead of polling.
>
> Now, if we decide to introduce polling......the next issue is how to add
> one.....
> There are two proposals....
> 1.   Through a notify...event "noop" with a delay parameter which controls the
> frequency of polling.
>      But, this I think has a dependency that this poll can only be initiated by
> MGC thru' activation of an event descriptor.
> 2.   Alternatively, we can use Service Change with "noop" method and add a
> property to Base Root package "normalMGCIdleTime....or normalMGCPollTime". This
> is the polling timeout duration provisioned at MG and settable by MGC at
> runtime.
> If MGC sets the value of this timer at runtime, MG should restart the polling
> timer. Additionally, we can put a guideline that in case the MG or MGC receives
> either a valid request or a valid reply from the other end within a polling
> interval, the SVC "noop" need not be sent at the expiry of that polling
> interval. Since service change can be sent by both MG and MGC this gives a
> suitable solution for polling.
>
> The concern about controlling the polling thru' MGC is addressed suitable by
> both the alternatives.
>
> Thanks,
> -Kapil Nayar
> Hughes Software Systems
>
> "Rosen, Brian"  on 05/18/2001 06:22:46 PM
>
> To:   "'Christian Groves'" , megaco@fore.com
> cc:    (bcc: Kapil Nayar/HSS)
>
> Subject:  RE: Polls of MGC
>
> Christian
>
> Everyone agrees that the way the MGC finds out if an MG is down is
> to send a message and look for a response.  There are quite
> a few messages an MGC could use.  I've suggested an audit.
>
> Everyone also agrees that the way the MG finds out if the MGC is down
> is to send a message and get a response.  It would presumably have
> some timer that is reset by any message from the MGC.  If the timer
> expired, it would send a message (a poll), and look for a reply.
>
> There are two issues:
> 1. What message do you send?  MGs only send two messages, ServiceChange
> and Notify.  The first series of messages on this thread talked about
> using SC as the message.  The issue is how to construct an SC
> which does not change the MGCs notion of the MG state (ie behave
> as a no-op).  The second set of messages talked about using Notify
> as the poll
>
> 2. How fast do you poll? The MGC really ought to be able to control
> the frequency of polls, which would depend on how many MGs it was
> controlling.  For this reason, we have been talking about using Notify,
> with an interval parameter, which would be set by the MGC to control
> the polling.  Using SC, even if you could, there is no way for the
> MGC to control the polling rate.
>
> If the MGC is down, the MG can do the right thing, which is to contact
> an alternate MGC for service.
>
> Brian
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Friday, May 18, 2001 4:18 AM
> > To: megaco@fore.com
> > Subject: Re: Polls of MGC
> >
> >
> > G'Day,
> >
> > I'd really like to understand the network scenario for adding this
> > polling.
> > As I see it the MGC can determine that an MG is down. ie. It issues a
> > command and gets no response. It can take the appropriate action.
> > Likewise the MG can determine when the MGC is down in the same way.
> > Except that if the MGC its connected to is down the MG can't do much.
> > Remember the MGC is the Master and the MG is the slave.
> >
> > I really don't see the benefit of the MG doing periodic
> > polling. It will
> > find something is wrong when it tries to signal the MGC.
> >
> > Without going to Servicechange methods, reasons etc. What's
> > the benefit?
> >
> > Cheers, Christian
> >
> >



From owner-megaco@fore.com  Fri May 18 12:11:13 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29860
	for ; Fri, 18 May 2001 12:11:13 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA00826;
	Fri, 18 May 2001 12:05:24 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA11599
	for megaco-list; Fri, 18 May 2001 12:04:11 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA11577
	for ; Fri, 18 May 2001 12:04:08 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA00654
	for ; Fri, 18 May 2001 12:04:03 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IG44m17049
	for ; Fri, 18 May 2001 12:04:04 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IG44d17043
	for ; Fri, 18 May 2001 12:04:04 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id MAA18696; Fri, 18 May 2001 12:03:45 -0400 (EDT)
Cc: megaco@fore.com
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id MAA18687; Fri, 18 May 2001 12:03:44 -0400 (EDT)
Message-ID: <3B054769.AE2F786F@lucent.com>
Date: Fri, 18 May 2001 12:01:45 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Dan Elbert 
Original-CC: megaco@fore.com
Subject: Re: Polls of MGC
References: <0D5BBF5D638DD4119E3400508BD949458110F9@RADVPOST>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


Then that's the problem:)
Have the MGs use a default or configured port also.
Seriously, why not?

Polling is BAD.

-troy


(BTW, I wasn't really proposing that we use the MGCP/NCS
 DNS based mechanism.  I was just responding to Christian's
 comment that the "MG can't do much" when it detects failure.
 A quick peek at section 9 shows me the H.248 mechanism:
 "The MGC is provisioned with a name or address of a primary and
 zero or more secondary MGCs".)




Dan Elbert wrote:
> 
> The difference with MGCP is that in MGCP when the MGC comes up it know how
> to contact the MGs ( they listen in a default or configured port) , but in
> Megaco the MGC only knows the MG port after the MG connects to it. If the
> MGC goes down normally this information can be saved, but if it fails and
> this information is lost, in some situations there is no way for the MG and
> MGC to connect to each other again.
> 
> Dan
> 
> -----Original Message-----
> From: Troy Cauble [mailto:troy@lucent.com]
> Sent: Friday, May 18, 2001 11:11 AM
> To: Christian Groves
> Cc: megaco@fore.com
> Subject: Re: Polls of MGC
> 
> Christian Groves wrote:
> >
> > G'Day,
> >
> > I'd really like to understand the network scenario for adding this
> > polling.
> > As I see it the MGC can determine that an MG is down. ie. It issues a
> > command and gets no response. It can take the appropriate action.
> > Likewise the MG can determine when the MGC is down in the same way.
> > Except that if the MGC its connected to is down the MG can't do much.
> > Remember the MGC is the Master and the MG is the slave.
> 
> MGCP/NCS has a failover scheme involving multiple DNS entries.  Basically
> if the MG can't reach the MGC after X tries, it checks the DNS entry for
> another IP address and tries it.  (Actually it's fairly complicated with
> attempt counts and timers, etc., but that's the idea.)
> 
> Any failover method needs to consider security.  It's not very good
> if the MG accepts messages that say "I'm your MGC now" from anyone.
> 
> > I really don't see the benefit of the MG doing periodic polling. It will
> > find something is wrong when it tries to signal the MGC.
> 
> I don't see the benefit either.  It'll find out when it tries to
> communicate something. Before then, it didn't need to know.
> The MGC might come back online before the MG needs it.
> 
> Picture 5000 MGs polling an MGC.  That's a lot of traffic.
> If the MGC is down for 5 minutes, 5000 MGs detect it and
> switch over *somehow* to the backup MGC, then need to be
> switched back to the original.  That's a lot of traffic too.
> If you let the MGs handle the problem as needed, maybe only
> a handful would have needed to.
> 
> > Without going to Servicechange methods, reasons etc. What's the benefit?
> >
> > Cheers, Christian


From owner-megaco@fore.com  Fri May 18 12:14:15 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29944
	for ; Fri, 18 May 2001 12:14:15 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA01173;
	Fri, 18 May 2001 12:08:21 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA12203
	for megaco-list; Fri, 18 May 2001 12:07:21 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA12199
	for ; Fri, 18 May 2001 12:07:19 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA01028
	for ; Fri, 18 May 2001 12:07:13 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 11:07:47 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD949458110FE@RADVPOST>
From: Dan Elbert 
To: "'megaco@fore.com'" 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Fri, 18 May 2001 11:07:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0DFB4.ADE77B70"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DFB4.ADE77B70
Content-Type: text/plain;
	charset="iso-8859-1"

You are right, but then this is yet an additional case, and the question
would be what happen with a termination in an active context if the
ServiceState is set to "Out of Service" , does it stays in the context, do
the streams get disconnected, etc.
But my question refered to a termination receiving a ServiceChange from the
MGC with method "Forced" ( or "Graceful" ) which should be somehow
equivalent.
 
Dan
 
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Friday, May 18, 2001 11:57 AM
To: 'Rosen, Brian'; 'Dan Elbert'; 'megaco@fore.com'
Subject: RE: Use of ServiceChange from MGC to MG
 
I was thinking of what the colloquial expression "take down a termination"
might mean.  This expression is NOT defined in the protocol specification.
The precise answer to Dan's question 1 is that "taken out of service" means
that the ServiceState parameter in TerminationState is changed to "Out of
Service", with resulting constraints on what commands can be applied to it.
The phrase "taking down a termination" is not defined in the protocol, so
you have to ask whoever uses it what they mean.
 
 -----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Friday, May 18, 2001 11:37 AM
To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Dan Elbert'; 'megaco@fore.com'
Subject: RE: Use of ServiceChange from MGC to MG
One thing I think is incorrect here is the "Subtracted from any active
contexts" part.  I believe we defined the protocol so that this NEVER
happens
as a side-effect.  The termination may actually be out of service, but both
the MG and the MGC have it in a context if it was when the termination was
taken out of service.
 
It is always incumbant on the MGC to do the subtract explicitly.
 
The ONLY exception to this is restart of the MG; all contexts are lost.
 
Brian
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Friday, May 18, 2001 11:32 AM
To: 'Dan Elbert'; 'megaco@fore.com'
Subject: RE: Use of ServiceChange from MGC to MG
Hi. 
> -----Original Message----- 
> From: Dan Elbert [ mailto:DElbert@radvision.com
 ] 
> Sent: Friday, May 18, 2001 11:06 AM 
> To: 'megaco@fore.com' 
> Subject: Use of ServiceChange from MGC to MG 
> 
> 
> Hi 
> 
> The Media Gateway Controller may indicate that Termination(s) 
> shall be taken 
> out of or returned to service. 
> 1. What is the meaning of the MGC taking down a termination ? 
> Does it means 
> that the termination is substracted from any active context 
> and all signal 
> are stopped and no events are detected ? 
Yes 
> 2. What methods are used for taking the MG down and up ? I'd 
> say Graceful 
> and Restart. Is this OK ? 
"Taking the MG down" to me means doing a ServiceChange on ROOT at the MG. 
It's possible the MGC might do that to an MG, but most likely in that case
that it would be done under manual control (i.e. the network is set up such
that control of MGs is exercised through the MGC).  I don't see this as a
typical maintence arrangement.
> 3. Is this applicable also to the root termination ? I would 
> say no because 
> if the root termination "goes down" then logically the MG may 
> not be able to 
> receive any more MGC commands. 
Upon recovery the MG would follow normal start-up procedures to establish a
new control association. 
> 
> Thanks, 
> 
> Dan Elbert 
> RADVISION 
> 

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












RE: Use of ServiceChange from MGC to MG










Y=
ou are right,
but then this is yet an additional case, and the question would be what =
happen
with a termination in an active context if the ServiceState is set to =
“Out of
Service” , does it stays in the context, do the streams get =
disconnected, etc.



B=
ut my
question refered to a termination receiving a ServiceChange from the =
MGC with
method “Forced” ( or “Graceful” ) which should =
be somehow equivalent.



<=
![if =
!supportEmptyParas]> 
=



D=
an



<=
![if =
!supportEmptyParas]> 
=



-----Original
Message-----

From: Tom-PT Taylor
[mailto:taylor@nortelnetworks.com]

Sent: Friday, May 18, =
2001 11:57
AM

To: 'Rosen, Brian'; 'Dan =
Elbert';
'megaco@fore.com'

Subject: RE: Use of =
ServiceChange
from MGC to MG



 



I was thinking =
of what
the colloquial expression "take down a termination" might =
mean. 
This expression is NOT defined in the protocol specification.  The =
precise
answer to Dan's question 1 is that "taken out of =
service" means
that the ServiceState parameter in TerminationState is changed to =
"Out of
Service", with resulting constraints on what commands can be =
applied to
it.  The phrase "taking down a termination" is not =
defined in
the protocol, so you have to ask whoever uses it what they =
mean.=




 =




 -----Ori=
ginal
Message-----

From: Rosen, Brian
[mailto:Brian.Rosen@marconi.com]

Sent: Friday, May 18, =
2001 11:37
AM

To: Taylor, Tom-PT
[NORSE:B881:EXCH]; 'Dan Elbert'; 'megaco@fore.com'

Subject: RE: Use of =
ServiceChange
from MGC to MG






One
thing I think is incorrect here is the "Subtracted from any =
active=




contexts"
part.  I believe we defined the protocol so that this NEVER =
happens=




as a
side-effect.  The termination may actually be out of service, but =
both=




the MG
and the MGC have it in a context if it was when the termination =
was=




taken
out of service.



 =




It is
always incumbant on the MGC to do the subtract =
explicitly.=




 =




The ONLY
exception to this is restart of the MG; all contexts are =
lost.=




 =




Brian=










-----Original
Message-----

From: Tom-PT Taylor
[mailto:taylor@nortelnetworks.com]

Sent: Friday, May 18, =
2001 11:32
AM

To: 'Dan Elbert';
'megaco@fore.com'

Subject: RE: Use of =
ServiceChange
from MGC to MG



Hi. =




>
-----Original Message----- 

> From: Dan Elbert [mailto:DElbert@radvision.com]<=
/span> 

> Sent: Friday, May 18, 2001 11:06 =
AM 

> To: 'megaco@fore.com' 

> Subject: Use of ServiceChange from MGC to =
MG 

> 

> 

> Hi 

> 

> The Media Gateway Controller may indicate that =
Termination(s)


> shall be taken 

> out of or returned to service. 

> 1. What is the meaning of the MGC taking down a =
termination ?


> Does it means 

> that the termination is substracted from any active =
context 

> and all signal 

> are stopped and no events are detected =
? =




Yes =




> 2. What
methods are used for taking the MG down and up ? I'd =


> say Graceful 

> and Restart. Is this OK ? 



"Taking
the MG down" to me means doing a ServiceChange on ROOT at the =
MG. 

It's possible the MGC might do that to an MG, but most =
likely in
that case that it would be done under manual control (i.e. the network =
is set
up such that control of MGs is exercised through the MGC).  I =
don't see
this as a typical maintence arrangement.=




> 3. Is
this applicable also to the root termination ? I would =


> say no because 

> if the root termination "goes down" then =
logically
the MG may 

> not be able to 

> receive any more MGC commands. =




Upon recovery
the MG would follow normal start-up procedures to establish a new =
control
association. =




> 

> Thanks, 

> 

> Dan Elbert 

> RADVISION 

> 












------_=_NextPart_001_01C0DFB4.ADE77B70--


From owner-megaco@fore.com  Fri May 18 12:29:42 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00398
	for ; Fri, 18 May 2001 12:29:41 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA02589;
	Fri, 18 May 2001 12:22:43 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA14963
	for megaco-list; Fri, 18 May 2001 12:21:52 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA14947
	for ; Fri, 18 May 2001 12:21:50 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA02474
	for ; Fri, 18 May 2001 12:21:45 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 11:22:19 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD949458110FF@RADVPOST>
From: Dan Elbert 
To: "'megaco@fore.com'" 
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 11:22:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Well, in the implementers guide is specified  ( in 7.2.8 ) :

For UDP as a transport, the MG may specify the transport
ServiceChangeAddress to be used by the MGC for sending messages in the
ServiceChangeAddress parameter in the input ServiceChangeDescriptor.. If the
transport ServiceChangeAddress parameter is not present, then the MGC shall
use the source transport address (mId) used by the MG for sending commands
in subsequent communication with the MG.

Using a configured port may limit flexibility, but maybe is a better
solution.

-----Original Message-----
From: Troy Cauble [mailto:troy@lucent.com]
Sent: Friday, May 18, 2001 12:02 PM
To: Dan Elbert
Cc: megaco@fore.com
Subject: Re: Polls of MGC


Then that's the problem:)
Have the MGs use a default or configured port also.
Seriously, why not?

Polling is BAD.

-troy


(BTW, I wasn't really proposing that we use the MGCP/NCS
 DNS based mechanism.  I was just responding to Christian's
 comment that the "MG can't do much" when it detects failure.
 A quick peek at section 9 shows me the H.248 mechanism:
 "The MGC is provisioned with a name or address of a primary and
 zero or more secondary MGCs".)




Dan Elbert wrote:
>
> The difference with MGCP is that in MGCP when the MGC comes up it know how
> to contact the MGs ( they listen in a default or configured port) , but in
> Megaco the MGC only knows the MG port after the MG connects to it. If the
> MGC goes down normally this information can be saved, but if it fails and
> this information is lost, in some situations there is no way for the MG
and
> MGC to connect to each other again.
>
> Dan
>
> -----Original Message-----
> From: Troy Cauble [mailto:troy@lucent.com]
> Sent: Friday, May 18, 2001 11:11 AM
> To: Christian Groves
> Cc: megaco@fore.com
> Subject: Re: Polls of MGC
>
> Christian Groves wrote:
> >
> > G'Day,
> >
> > I'd really like to understand the network scenario for adding this
> > polling.
> > As I see it the MGC can determine that an MG is down. ie. It issues a
> > command and gets no response. It can take the appropriate action.
> > Likewise the MG can determine when the MGC is down in the same way.
> > Except that if the MGC its connected to is down the MG can't do much.
> > Remember the MGC is the Master and the MG is the slave.
>
> MGCP/NCS has a failover scheme involving multiple DNS entries.  Basically
> if the MG can't reach the MGC after X tries, it checks the DNS entry for
> another IP address and tries it.  (Actually it's fairly complicated with
> attempt counts and timers, etc., but that's the idea.)
>
> Any failover method needs to consider security.  It's not very good
> if the MG accepts messages that say "I'm your MGC now" from anyone.
>
> > I really don't see the benefit of the MG doing periodic polling. It will
> > find something is wrong when it tries to signal the MGC.
>
> I don't see the benefit either.  It'll find out when it tries to
> communicate something. Before then, it didn't need to know.
> The MGC might come back online before the MG needs it.
>
> Picture 5000 MGs polling an MGC.  That's a lot of traffic.
> If the MGC is down for 5 minutes, 5000 MGs detect it and
> switch over *somehow* to the backup MGC, then need to be
> switched back to the original.  That's a lot of traffic too.
> If you let the MGs handle the problem as needed, maybe only
> a handful would have needed to.
>
> > Without going to Servicechange methods, reasons etc. What's the benefit?
> >
> > Cheers, Christian


From owner-megaco@fore.com  Fri May 18 12:49:55 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01088
	for ; Fri, 18 May 2001 12:49:55 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA04105;
	Fri, 18 May 2001 12:44:14 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA19491
	for megaco-list; Fri, 18 May 2001 12:43:19 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA19481
	for ; Fri, 18 May 2001 12:43:17 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA03989
	for ; Fri, 18 May 2001 12:43:11 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4IGhAdQ020074
	for ; Fri, 18 May 2001 11:43:11 -0500 (CDT)
From: "Paul Long" 
To: 
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 11:43:12 -0500
Message-ID: 
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: <0D5BBF5D638DD4119E3400508BD949458110FF@RADVPOST>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dan,

The latter part of that passage concerns me because we just discussed the
fact that the mID is never _used_ as an actual IP address. It is merely a
lexeme that uniquely identifies the sending entity and has no other semantic
value. This passage would change that. I recommend nuking it.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dan Elbert
Sent: Friday, May 18, 2001 11:22 AM
To: 'megaco@fore.com'
Subject: RE: Polls of MGC


Well, in the implementers guide is specified  ( in 7.2.8 ) :

For UDP as a transport, the MG may specify the transport
ServiceChangeAddress to be used by the MGC for sending messages in the
ServiceChangeAddress parameter in the input ServiceChangeDescriptor.. If the
transport ServiceChangeAddress parameter is not present, then the MGC shall
use the source transport address (mId) used by the MG for sending commands
in subsequent communication with the MG.

Using a configured port may limit flexibility, but maybe is a better
solution.



From owner-megaco@fore.com  Fri May 18 12:56:20 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01301
	for ; Fri, 18 May 2001 12:56:20 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA04519;
	Fri, 18 May 2001 12:48:53 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA20315
	for megaco-list; Fri, 18 May 2001 12:47:49 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA20311
	for ; Fri, 18 May 2001 12:47:47 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id MAA04397
	for ; Fri, 18 May 2001 12:47:41 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id MAA16177; Fri, 18 May 2001 12:47:37 -0400
Received: from ztcfd004.ca.nortel.com by zcars04e.nortelnetworks.com;
          Fri, 18 May 2001 12:47:24 -0400
Received: by ztcfd004.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 18 May 2001 12:47:24 -0400
Message-ID: <45D2A43C1913D51180F40000F89CB87404DC0D@nrtpde0a.us.nortel.com>
From: "David Stonehouse" 
To: "'Troy Cauble'" , MEGACO list ,
        "'Tulpule, Naren'" 
Subject: RE: SDP and ';' comments
Date: Fri, 18 May 2001 12:47:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DFBA.31D3F760"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DFBA.31D3F760
Content-Type: text/plain;
	charset="iso-8859-1"

The resolution to Troy's initial statement is not only because of the way an
SDP ends, but also in the way that the octetString terminal will force the
Megaco parser to pull everything up to the '}' into the octetString.  The
net result is even though the official definition of RBRKT allows for a
comment in front or behind, in this case, there will never be any LWSP
(including comments) for the Megaco parser to parse before the '}'.  The
resulting octetString is what will get passed to the SDP parser.  If this
string fails to parse according to SDP syntax, then the message should be
rejected for bad syntax (including any trailing Megaco comment ';').

So, even if the comment were added after the newline but before the '}', it
is still bad syntax because it falls under SDP parsing rules.  (A parser may
want to be liberal in accepting this, but that's beside the point.)

Pasting from Naren's post from last September (for which I never saw any
responses):

    4. escaping "}" in SDP strings
            I don't know if  "}" can appear in SDP attribute or VcId or
other
    values. Nonetheless to be safe, especially on the MGC side when you
might
    just want to treat SDP description as opaque, why not delimit the the
    description with a line that starts with "==" (two "=" symbols) or a
similar
    illegal combination? Using "\}" is really not feasible.

The issue isn't that "}" could appear in SDP - it's whether "\}" could
appear in SDP.  If it can not, then it is okay for the Megaco parser to
translate the "\}" to "}", and pass the resulting string to the SDP parser.


Dave


-----Original Message-----
From: Troy Cauble [mailto:troy@lucent.com]
Sent: Friday, May 18, 2001 9:28 AM
To: MEGACO list
Subject: Re: SDP and ';' comments



Good point!  SDP does require the newline!
-troy

"Tulpule, Naren" wrote:
> 
> Megaco wankers :)
> [NAREN] Hey now, it's not Friday evening yet, Troy :-)
> Check out
>
http://standards.nortelnetworks.com/scripts/wa.exe?A2=ind0009&L=MEGACO&P=R25
> 962 point (3).
> This has come up before.
> (If the link doesn't work try "search archives" with "SDP comment")
> So what if it's the last line of SDP - it still violates SDP syntax before
> the all important newline. It's just a Bad Example.
> We don't need the rule that you propose, because SDP last line (a= or
> whichever) is ALWAYS supposed to end with newline.
> 
> 
> 
> At least one of the messages in Appendix A
> has SDP with an H.248 style comment:
> 
>                         Local {
> v=0
> c=IN IP4 $
> m=audio $ RTP/AVP 0
> a=fmtp:PCMU VAD=X-NNVAD ; special voice activity
>                            ; detection algorithm
>                         }
> 
> I assume we're not imposing these comments on SDP in general.
> But in this example it's the last line of SDP and the comments
> could be part of RBRKT.

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






RE: SDP and ';' comments




The resolution to Troy's initial statement is not =
only because of the way an SDP ends, but also in the way that the =
octetString terminal will force the Megaco parser to pull everything up =
to the '}' into the octetString.  The net result is even though =
the official definition of RBRKT allows for a comment in front or =
behind, in this case, there will never be any LWSP (including comments) =
for the Megaco parser to parse before the '}'.  The resulting =
octetString is what will get passed to the SDP parser.  If this =
string fails to parse according to SDP syntax, then the message should =
be rejected for bad syntax (including any trailing Megaco comment =
';').



So, even if the comment were added after the newline =
but before the '}', it is still bad syntax because it falls under SDP =
parsing rules.  (A parser may want to be liberal in accepting =
this, but that's beside the point.)



Pasting from Naren's post from last September (for =
which I never saw any responses):




    4. escaping "}" in SDP =
strings

          &nb=
sp; I don't know if  "}" can appear in SDP attribute or =
VcId or other

    values. Nonetheless to be safe, =
especially on the MGC side when you might

    just want to treat SDP =
description as opaque, why not delimit the the

    description with a line that =
starts with "=3D=3D" (two "=3D" symbols) or a =
similar

    illegal combination? Using =
"\}" is really not feasible.




The issue isn't that "}" could appear in =
SDP - it's whether "\}" could appear in SDP.  If it can =
not, then it is okay for the Megaco parser to translate the =
"\}" to "}", and pass the resulting string to the =
SDP parser.  



Dave






-----Original Message-----

From: Troy Cauble [mailto:troy@lucent.com]

Sent: Friday, May 18, 2001 9:28 AM

To: MEGACO list

Subject: Re: SDP and ';' comments








Good point!  SDP does require the =
newline!

-troy




"Tulpule, Naren" wrote:

> 

> Megaco wankers :)

> [NAREN] Hey now, it's not Friday evening yet, =
Troy :-)

> Check out

> http://standards.nortelnetworks.com/scripts/wa.exe?A2=3D=
ind0009&L=3DMEGACO&P=3DR25

> 962 point (3).

> This has come up before.

> (If the link doesn't work try "search =
archives" with "SDP comment")

> So what if it's the last line of SDP - it still =
violates SDP syntax before

> the all important newline. It's just a Bad =
Example.

> We don't need the rule that you propose, =
because SDP last line (a=3D or

> whichever) is ALWAYS supposed to end with =
newline.

> 

> <end of comments, Troy's original message =
below>

> 

> At least one of the messages in Appendix =
A

> has SDP with an H.248 style comment:

> 

>          =
;            =
;   Local {

> v=3D0

> c=3DIN IP4 $

> m=3Daudio $ RTP/AVP 0

> a=3Dfmtp:PCMU VAD=3DX-NNVAD ; special voice =
activity

>          =
;            =
;      ; detection algorithm

>          =
;            =
;   }

> 

> I assume we're not imposing these comments on =
SDP in general.

> But in this example it's the last line of SDP =
and the comments

> could be part of RBRKT.





------_=_NextPart_001_01C0DFBA.31D3F760--


From owner-megaco@fore.com  Fri May 18 12:56:58 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01332
	for ; Fri, 18 May 2001 12:56:57 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA04799;
	Fri, 18 May 2001 12:51:08 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA20673
	for megaco-list; Fri, 18 May 2001 12:50:15 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA20644
	for ; Fri, 18 May 2001 12:50:03 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA04660
	for ; Fri, 18 May 2001 12:49:57 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4IGnvdQ022413
	for ; Fri, 18 May 2001 11:49:57 -0500 (CDT)
From: "Paul Long" 
To: 
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 11:49:59 -0500
Message-ID: 
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: <3B054242.5C227B4F@lucent.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Troy,

I was leaning towards the no-polling camp, but then I thought about a
situation that hasn't been mentioned yet. We could just wait until the
subscriber attempts to place a call to find an available MGC, but what about
incoming calls? If the MGC is down, that subscriber cannot be reached until
after he or she attempts to place a call. For that reason alone, I think we
need a MG-to-MGC polling mechanism.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Troy Cauble
Sent: Friday, May 18, 2001 10:40 AM
To: Rosen, Brian
Cc: 'knayar@hss.hns.com'; megaco@fore.com
Subject: Re: Polls of MGC


"Rosen, Brian" wrote:
>
> Y'know, I've asked myself that.  I'm not sure I'd use it IFF
> the whole process of finding an MGC and getting back up was fast
> enough to not cause problems with subscribers.

I haven't followed this thread enough to know if the "process"
is even known yet.  (I mostly obsess on the parsing issues.)

I think the MGCP/NCS use of DNS is fairly good, but I doubt
the timer & count values are such that, for example, it's not
visible to a user in a residential gateway situation.

But MGC failure will be a non-frequent event, so I think
that some small amount of recovery time is OK and better than
the alternative of polling.


> My conclusion is that it COULD take a long time, and thus I think
> finding it out sooner is better.  I don't feel so strongly that
> I think we just GOTTA change the protocol.


In terms of the "process" being fast:  How fast is it
going to be for the MGs that need to get through to a new MGC
because they're trying to put a call though, when 2000 MGs with
no immediate beat them to it because of their polling cycle.

I think that polling is a bad idea in either direction.

-troy



From owner-megaco@fore.com  Fri May 18 12:58:52 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01453
	for ; Fri, 18 May 2001 12:58:51 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA28181;
	Fri, 18 May 2001 11:47:48 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA07188
	for megaco-list; Fri, 18 May 2001 11:46:01 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA07184
	for ; Fri, 18 May 2001 11:45:59 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27850
	for ; Fri, 18 May 2001 11:45:54 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 10:46:28 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD949458110FA@RADVPOST>
From: Dan Elbert 
To: "'megaco@fore.com'" 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Fri, 18 May 2001 10:46:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0DFB1.B29EC950"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DFB1.B29EC950
Content-Type: text/plain;
	charset="iso-8859-1"

See below
 
-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Friday, May 18, 2001 11:37 AM
To: 'Tom-PT Taylor'; 'Dan Elbert'; 'megaco@fore.com'
Subject: RE: Use of ServiceChange from MGC to MG
 
One thing I think is incorrect here is the "Subtracted from any active
contexts" part.  I believe we defined the protocol so that this NEVER
happens
as a side-effect.  The termination may actually be out of service, but both
the MG and the MGC have it in a context if it was when the termination was
taken out of service.
 
[Dan] So what is the meaning of making a termination in a context "out of
service" ? Does it gets disconnected from all the media streams ?
 
It is always incumbant on the MGC to do the subtract explicitly.
 
The ONLY exception to this is restart of the MG; all contexts are lost.
 
[Dan] So you agree that is possible for the MGC to take the "root"
termination down and up again .
 
Brian
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Friday, May 18, 2001 11:32 AM
To: 'Dan Elbert'; 'megaco@fore.com'
Subject: RE: Use of ServiceChange from MGC to MG
Hi. 
> -----Original Message----- 
> From: Dan Elbert [ mailto:DElbert@radvision.com
 ] 
> Sent: Friday, May 18, 2001 11:06 AM 
> To: 'megaco@fore.com' 
> Subject: Use of ServiceChange from MGC to MG 
> 
> 
> Hi 
> 
> The Media Gateway Controller may indicate that Termination(s) 
> shall be taken 
> out of or returned to service. 
> 1. What is the meaning of the MGC taking down a termination ? 
> Does it means 
> that the termination is substracted from any active context 
> and all signal 
> are stopped and no events are detected ? 
Yes 
> 2. What methods are used for taking the MG down and up ? I'd 
> say Graceful 
> and Restart. Is this OK ? 
"Taking the MG down" to me means doing a ServiceChange on ROOT at the MG. 
It's possible the MGC might do that to an MG, but most likely in that case
that it would be done under manual control (i.e. the network is set up such
that control of MGs is exercised through the MGC).  I don't see this as a
typical maintence arrangement.
> 3. Is this applicable also to the root termination ? I would 
> say no because 
> if the root termination "goes down" then logically the MG may 
> not be able to 
> receive any more MGC commands. 
Upon recovery the MG would follow normal start-up procedures to establish a
new control association. 
> 
> Thanks, 
> 
> Dan Elbert 
> RADVISION 
> 

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












RE: Use of ServiceChange from MGC to MG










S=
ee below



<=
![if =
!supportEmptyParas]> 
=



-----Original
Message-----

From: Rosen, Brian
[mailto:Brian.Rosen@marconi.com]

Sent: Friday, May 18, =
2001 11:37
AM

To: 'Tom-PT Taylor'; =
'Dan Elbert';
'megaco@fore.com'

Subject: RE: Use of =
ServiceChange
from MGC to MG



 



One thing I =
think is
incorrect here is the "Subtracted from any =
active=




contexts"
part.  I believe we defined the protocol so that this NEVER =
happens=




as a =
side-effect. 
The termination may actually be out of service, but =
both=




the MG and the =
MGC have
it in a context if it was when the termination was=




taken out of =
service.



<=
![if =
!supportEmptyParas]> 
=



[=
Dan] So what
is the meaning of making a termination in a context “out of =
service” ? Does it
gets disconnected from all the media streams =
?



 =




It is always =
incumbant on
the MGC to do the subtract explicitly.=




 =




The ONLY =
exception to
this is restart of the MG; all contexts are lost.



<=
![if =
!supportEmptyParas]> 
=



[=
Dan] So
you agree that is possible for the MGC to take the “root” =
termination down and
up again .



 =




Brian=







-----Original
Message-----

From: Tom-PT Taylor
[mailto:taylor@nortelnetworks.com]

Sent: Friday, May 18, =
2001 11:32
AM

To: 'Dan Elbert';
'megaco@fore.com'

Subject: RE: Use of =
ServiceChange
from MGC to MG



Hi. =




>
-----Original Message----- 

> From: Dan Elbert [mailto:DElbert@radvision.com]<=
/span> 

> Sent: Friday, May 18, 2001 11:06 =
AM 

> To: 'megaco@fore.com' 

> Subject: Use of ServiceChange from MGC to =
MG 

> 

> 

> Hi 

> 

> The Media Gateway Controller may indicate that =
Termination(s)


> shall be taken 

> out of or returned to service. 

> 1. What is the meaning of the MGC taking down a =
termination ?


> Does it means 

> that the termination is substracted from any active =
context 

> and all signal 

> are stopped and no events are detected =
? =




Yes =




> 2. What
methods are used for taking the MG down and up ? I'd =


> say Graceful 

> and Restart. Is this OK ? 



"Taking
the MG down" to me means doing a ServiceChange on ROOT at the =
MG. 

It's possible the MGC might do that to an MG, but most =
likely in
that case that it would be done under manual control (i.e. the network =
is set
up such that control of MGs is exercised through the MGC).  I =
don't see
this as a typical maintence arrangement.=




> 3. Is
this applicable also to the root termination ? I would =


> say no because 

> if the root termination "goes down" then =
logically
the MG may 

> not be able to 

> receive any more MGC commands. =




Upon recovery
the MG would follow normal start-up procedures to establish a new =
control
association. =




> 

> Thanks, 

> 

> Dan Elbert 

> RADVISION 

> 












------_=_NextPart_001_01C0DFB1.B29EC950--


From owner-megaco@fore.com  Fri May 18 13:10:52 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01911
	for ; Fri, 18 May 2001 13:10:52 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05830;
	Fri, 18 May 2001 13:05:03 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA23569
	for megaco-list; Fri, 18 May 2001 13:04:04 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA23564
	for ; Fri, 18 May 2001 13:04:02 -0400 (EDT)
Received: from ertpg15e1.nortelnetworks.com (ertpg15e1.nortelnetworks.com [47.234.0.36])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id NAA05699
	for ; Fri, 18 May 2001 13:03:57 -0400 (EDT)
Received: from zrtps06s.us.nortel.com by ertpg15e1.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id NAA16148; Fri, 18 May 2001 13:03:53 -0400
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com;
          Fri, 18 May 2001 13:04:37 -0400
Received: from zrtpd0jn.us.nortel.com ([47.140.202.35]) 
          by zrtpd004.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id LDQVPVSW; Fri, 18 May 2001 13:03:33 -0400
Received: from americasm01.nt.com (kboyle.us.nortel.com [47.142.150.95]) 
          by zrtpd0jn.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id J5XGQ15W; Fri, 18 May 2001 13:03:33 -0400
Message-ID: <3B0555A2.224FECF3@americasm01.nt.com>
Date: Fri, 18 May 2001 13:02:26 -0400
X-Sybari-Space: 00000000 00000000 00000000
From: "Kevin Boyle" 
Organization: Nortel Networks
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: knayar@hss.hns.com
CC: Dan Elbert , megaco@fore.com
Subject: Re: Polls of MGC
References: <65256A50.0055D7D1.00@sandesh.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

If you are really intent on polling, why not just have the MGC send noop messages
(like empty audit requests) every so often, and the lack of messaging from an MGC
would indicate failure.  I see no reason for the MG to need to poll the MGC.

In fact, the MGC can send the poll message if it hasn't sent anything to that
particular MG for a certain amount of time.  Then, if the MG doesn't receive a
message within a predetermined time, it can begin searching for a new MGC.

This solution would require no extensions to the protocol.

Kevin

knayar@hss.hns.com wrote:

> Hi Brian
>
> If we have finally decided to add support for polling....there is another
> suggestion
> Add a service change reason "Poll" or "Noop" to be used with Service Change
> Method "Restart"
> I hope that doesn't change the spec....
> And, add a new package BaseRootPoll package which extends BaseRoot Package.....
> This way only those MGCs which support this new extended package can control the
> polling frequency....else they just need to respond to the service change method
> Restart reason Poll or Noop...
>
> Thanks,
> -Kapil Nayar
> Hughes Software Systems
>
> Dan Elbert  on 05/18/2001 08:42:28 PM
>
> To:   megaco@fore.com
> cc:    (bcc: Kapil Nayar/HSS)
>
> Subject:  RE: Polls of MGC
>
> In the protocol it says that the ServiceChange method can also be "Another
> value whose meaning is mutually understood between the MG and the MGC" so I
> think that specifying a "noop" value in the Implementor's guide is covered
> under this.
> The problem with the package is that it has to be implemented by both sides
> to work, and making the package "mandatory" also implies a modification of
> the spec.
> The SVC will work even if only the MG implements it, because the MGC should
> reply to this even if the method is unknown to him.
>
> Dan
>
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Friday, May 18, 2001 10:52 AM
> To: 'knayar@hss.hns.com'
> Cc: megaco@fore.com
> Subject: RE: Polls of MGC
>
> This discussion is not specifically detecting failure of the
> MGC by timeout of response to a message.  It has to do with
> detecting failure of the MGC when there is no message flow.
> The poll CREATES a message for the purpose of seeing if it
> can get a response.  If, during the processing of the poll,
> it gets no response, then it initiates failover procedures
> as documented. "No Response" to the poll is exactly the same
> as no response to a normal message.
>
> It is possible to use SC if you add a no-op method.  It is
> possible to control frequency at the MGC by having a settable
> parameter on root.  That is, to me, an acceptable answer,
> but adding the no-op actually changes the protocol.
> The advantage of the package with the event is that it's a normal
> package, and can be standardized without modifying RFC3015
> and Recommendation H.248.  Trying to do this with an "Implementor's
> Guide" seems to me to be stretching the definition of "Guide"
> pretty far.  Alternatively, this can be deferred to a future
> revision.
>
> Brian
>
> > -----Original Message-----
> > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com]
> > Sent: Friday, May 18, 2001 9:46 AM
> > To: Rosen, Brian
> > Cc: 'Christian Groves'; megaco@fore.com
> > Subject: RE: Polls of MGC
> >
> >
> >
> >
> > Hi Brian
> >
> > I think what Christian is pointing out is that do we really
> > need polling......
> > The question is that in case of unreliable transport protocol
> > like UDP whether
> > the MGC ( or MG) should be allowed to wait for timeout of "a
> > reply to a valid
> > request message" (like ADD, MODIFY etc. from MGC and NOTIFY,
> > SVC from MG) to
> > detect failure of the other end. Or else, there should be a
> > mechanism in built
> > in the MEGACO protocol to detect a MG or MGC failure....seems
> > a better option
> > though it has an added overhead of polling.
> >
> > Now, if we decide to introduce polling......the next issue is
> > how to add
> > one.....
> > There are two proposals....
> > 1.   Through a notify...event "noop" with a delay parameter
> > which controls the
> > frequency of polling.
> >      But, this I think has a dependency that this poll can
> > only be initiated by
> > MGC thru' activation of an event descriptor.
> > 2.   Alternatively, we can use Service Change with "noop"
> > method and add a
> > property to Base Root package "normalMGCIdleTime....or
> > normalMGCPollTime". This
> > is the polling timeout duration provisioned at MG and
> > settable by MGC at
> > runtime.
> > If MGC sets the value of this timer at runtime, MG should
> > restart the polling
> > timer. Additionally, we can put a guideline that in case the
> > MG or MGC receives
> > either a valid request or a valid reply from the other end
> > within a polling
> > interval, the SVC "noop" need not be sent at the expiry of
> > that polling
> > interval. Since service change can be sent by both MG and MGC
> > this gives a
> > suitable solution for polling.
> >
> > The concern about controlling the polling thru' MGC is
> > addressed suitable by
> > both the alternatives.
> >
> > Thanks,
> > -Kapil Nayar
> > Hughes Software Systems
> >
> >
> >
> >
> >
> > "Rosen, Brian"  on 05/18/2001 06:22:46 PM
> >
> > To:   "'Christian Groves'" ,
> > megaco@fore.com
> > cc:    (bcc: Kapil Nayar/HSS)
> >
> > Subject:  RE: Polls of MGC
> >
> >
> >
> >
> > Christian
> >
> > Everyone agrees that the way the MGC finds out if an MG is down is
> > to send a message and look for a response.  There are quite
> > a few messages an MGC could use.  I've suggested an audit.
> >
> > Everyone also agrees that the way the MG finds out if the MGC is down
> > is to send a message and get a response.  It would presumably have
> > some timer that is reset by any message from the MGC.  If the timer
> > expired, it would send a message (a poll), and look for a reply.
> >
> > There are two issues:
> > 1. What message do you send?  MGs only send two messages,
> > ServiceChange
> > and Notify.  The first series of messages on this thread talked about
> > using SC as the message.  The issue is how to construct an SC
> > which does not change the MGCs notion of the MG state (ie behave
> > as a no-op).  The second set of messages talked about using Notify
> > as the poll
> >
> > 2. How fast do you poll? The MGC really ought to be able to control
> > the frequency of polls, which would depend on how many MGs it was
> > controlling.  For this reason, we have been talking about
> > using Notify,
> > with an interval parameter, which would be set by the MGC to control
> > the polling.  Using SC, even if you could, there is no way for the
> > MGC to control the polling rate.
> >
> > If the MGC is down, the MG can do the right thing, which is to contact
> > an alternate MGC for service.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > > Sent: Friday, May 18, 2001 4:18 AM
> > > To: megaco@fore.com
> > > Subject: Re: Polls of MGC
> > >
> > >
> > > G'Day,
> > >
> > > I'd really like to understand the network scenario for adding this
> > > polling.
> > > As I see it the MGC can determine that an MG is down. ie.
> > It issues a
> > > command and gets no response. It can take the appropriate action.
> > > Likewise the MG can determine when the MGC is down in the same way.
> > > Except that if the MGC its connected to is down the MG
> > can't do much.
> > > Remember the MGC is the Master and the MG is the slave.
> > >
> > > I really don't see the benefit of the MG doing periodic
> > > polling. It will
> > > find something is wrong when it tries to signal the MGC.
> > >
> > > Without going to Servicechange methods, reasons etc. What's
> > > the benefit?
> > >
> > > Cheers, Christian
> > >
> > >
> >
> >
> >
> >



From owner-megaco@fore.com  Fri May 18 13:14:49 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02084
	for ; Fri, 18 May 2001 13:14:48 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA06181;
	Fri, 18 May 2001 13:07:02 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA23796
	for megaco-list; Fri, 18 May 2001 13:05:29 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA23789
	for ; Fri, 18 May 2001 13:05:28 -0400 (EDT)
From: rezhirpavai@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05887
	for ; Fri, 18 May 2001 13:05:20 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4IH5vv26176;
	Fri, 18 May 2001 22:35:59 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A50.005C718A ; Fri, 18 May 2001 22:19:43 +0530
X-Lotus-FromDomain: HSS
To: "Madhu Babu Brahmanapally" 
cc: "'Dan Elbert'" , megaco@fore.com
Message-ID: <65256A50.005C6CAF.00@sandesh.hss.hns.com>
Date: Fri, 18 May 2001 22:25:23 +0530
Subject: RE: Use of ServiceChange from MGC to MG
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk



Hello Madhu,
     In the second point you have mentioned about the methods for taking the MG
down as "forced" and restart".  If the MG itself wants to indicate about its
going down, then it can either send "graceful" or "forced", but if the MGC wants
to bring down its association with the MG then it needs to send service change
on ROOT with "forced". "Restart" from MGC on ROOT termination is not valid.  In
this case the MG needs to itself send service change to any secondary MGC or to
the same primary MGC (if secondary MGC are configured) after restart avalance
timer.


                                         Regards,
                                         R. Ezhirpavai





"Madhu Babu Brahmanapally"  on 05/18/2001 09:05:16 PM

To:   "'Dan Elbert'" , megaco@fore.com
cc:    (bcc: R Ezhirpavai/HSS)

Subject:  RE: Use of ServiceChange from MGC to MG




HI Dan,
Comments below [Madhu]

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dan Elbert
Sent: Friday, May 18, 2001 11:06 AM
To: 'megaco@fore.com'
Subject: Use of ServiceChange from MGC to MG


Hi

The Media Gateway Controller may indicate that Termination(s) shall be taken
out of or returned to service.

1. What is the meaning of the MGC taking down a termination ? Does it means
that the termination is substracted from any active context and all signal
are stopped and no events are detected ?
[Madhu] IMO its similar to the situation where MG generates such
servicechange.
The signals to be stopped and no event detection.
Will be useful in
1) Residential Gateway - Where the user profile is not encouraging and the
MGC doesn't
want to entertain any messages generated from the MG for that endpoint.
2) Trunking gateway - Remove some of the trunks from the initial provisioned
trunks.

2. What methods are used for taking the MG down and up ? I'd say Graceful
and Restart. Is this OK ?
[Madhu] I think Graceful is a mean by which MG can say to MGC that this
particular termination
shouldn't be used for further calls. Graceful has no meaning when MGC
generates this. I think the
methods should be "forced" and "restart".

3. Is this applicable also to the root termination ? I would say no because
if the root termination "goes down" then logically the MG may not be able to
receive any more MGC commands.
[Madhu] Yes. Your argument is correct.

Thanks,

Dan Elbert
RADVISION







From owner-megaco@fore.com  Fri May 18 13:15:40 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02152
	for ; Fri, 18 May 2001 13:15:40 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA06030;
	Fri, 18 May 2001 13:06:05 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA23673
	for megaco-list; Fri, 18 May 2001 13:04:48 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA23665
	for ; Fri, 18 May 2001 13:04:46 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 13:04:12 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F644@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Paul Long'" , megaco@fore.com
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 13:04:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a whole other problem.

If the calling party is on the same MG as the called party,
then the MG discovers the MGC is down by having the notify of
off hook (or equivalent), as we have been talking about, or the poll.

If the calling party is on a different MG, but the same MGC,
then the calling party will discover the MGC is down as above.

If the calling party is on a different MG and that MG is on a
different MGC, then the calling MGC will discover the MGC is down.

In all cases, the calling party gets a busy or other error,
and the called party is blissfully unaware of a missed call.

Brian

> -----Original Message-----
> From: Paul Long [mailto:plong@ipdialog.com]
> Sent: Friday, May 18, 2001 12:50 PM
> To: megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> Troy,
> 
> I was leaning towards the no-polling camp, but then I thought about a
> situation that hasn't been mentioned yet. We could just wait until the
> subscriber attempts to place a call to find an available MGC, 
> but what about
> incoming calls? If the MGC is down, that subscriber cannot be 
> reached until
> after he or she attempts to place a call. For that reason 
> alone, I think we
> need a MG-to-MGC polling mechanism.
> 
> Paul Long
> ipDialog, Inc.
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Troy Cauble
> Sent: Friday, May 18, 2001 10:40 AM
> To: Rosen, Brian
> Cc: 'knayar@hss.hns.com'; megaco@fore.com
> Subject: Re: Polls of MGC
> 
> 
> "Rosen, Brian" wrote:
> >
> > Y'know, I've asked myself that.  I'm not sure I'd use it IFF
> > the whole process of finding an MGC and getting back up was fast
> > enough to not cause problems with subscribers.
> 
> I haven't followed this thread enough to know if the "process"
> is even known yet.  (I mostly obsess on the parsing issues.)
> 
> I think the MGCP/NCS use of DNS is fairly good, but I doubt
> the timer & count values are such that, for example, it's not
> visible to a user in a residential gateway situation.
> 
> But MGC failure will be a non-frequent event, so I think
> that some small amount of recovery time is OK and better than
> the alternative of polling.
> 
> 
> > My conclusion is that it COULD take a long time, and thus I think
> > finding it out sooner is better.  I don't feel so strongly that
> > I think we just GOTTA change the protocol.
> 
> 
> In terms of the "process" being fast:  How fast is it
> going to be for the MGs that need to get through to a new MGC
> because they're trying to put a call though, when 2000 MGs with
> no immediate beat them to it because of their polling cycle.
> 
> I think that polling is a bad idea in either direction.
> 
> -troy
> 


From owner-megaco@fore.com  Fri May 18 13:19:51 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02314
	for ; Fri, 18 May 2001 13:19:50 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA06952;
	Fri, 18 May 2001 13:14:04 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA25536
	for megaco-list; Fri, 18 May 2001 13:12:53 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA25524
	for ; Fri, 18 May 2001 13:12:51 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 13:12:16 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F645@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Dave Sclarsky'" ,
        "'knayar@hss.hns.com'"
	 
Cc: megaco@fore.com
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 13:12:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

I suppose.  I haven't yet come up with a reason for signal on
root, although if the folks that want signals to create external
signalling (the example is ATM SVC creation triggered by a signal
on a termination) get the definition of a signal extended that way, that
opens u a whole new set of things you may define signals for, and
since signals are defined in packages, that could end up causing
interaction problems with the poll event.

Given the level of discussion, maybe we should punt for now.
A profile could define a new method for ServiceChange, and a package
on root for the interval.  So, any systems that weren't happy with the
"wait until you need it to worry about a failed MGC" idea have a
way.  We might want to get some more real experience with things like
failure recovery time before we really standardize a method.

I've also offered another idea - define a restart of an already
up termination to be a no-op.  That IS something the Implementors
Guide can do - the behavior is not specified, you can reasonably
interpret a restart of an up termination as a no-op, and we could
make it so in the I-G.  We would need the package for the interval,
but that is easy.

Brian

> -----Original Message-----
> From: Dave Sclarsky [mailto:Dave.Sclarsky@radisys.com]
> Sent: Friday, May 18, 2001 11:46 AM
> To: 'Rosen, Brian'; 'knayar@hss.hns.com'
> Cc: megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> Brian,
> I agree that adding a package is a simpler process than 
> changing the specs.
> But I still have one nagging problem with making this an 
> event on ROOT -
> does it prevent any future package from defining signals on 
> ROOT?  Maybe the
> interaction of events and signals is reason enough to avoid 
> defining either
> of them in packages for use on ROOT.
> Do you see this as a potential problem?
> DaveS.
> 
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Friday, May 18, 2001 10:52 AM
> To: 'knayar@hss.hns.com'
> Cc: megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> This discussion is not specifically detecting failure of the
> MGC by timeout of response to a message.  It has to do with
> detecting failure of the MGC when there is no message flow.
> The poll CREATES a message for the purpose of seeing if it
> can get a response.  If, during the processing of the poll,
> it gets no response, then it initiates failover procedures
> as documented. "No Response" to the poll is exactly the same
> as no response to a normal message.
> 
> It is possible to use SC if you add a no-op method.  It is 
> possible to control frequency at the MGC by having a settable
> parameter on root.  That is, to me, an acceptable answer,
> but adding the no-op actually changes the protocol.  
> The advantage of the package with the event is that it's a normal 
> package, and can be standardized without modifying RFC3015
> and Recommendation H.248.  Trying to do this with an "Implementor's
> Guide" seems to me to be stretching the definition of "Guide"
> pretty far.  Alternatively, this can be deferred to a future
> revision.
> 
> Brian
> 
> 
> 
> > -----Original Message-----
> > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com]
> > Sent: Friday, May 18, 2001 9:46 AM
> > To: Rosen, Brian
> > Cc: 'Christian Groves'; megaco@fore.com
> > Subject: RE: Polls of MGC
> > 
> > 
> > 
> > 
> > Hi Brian
> > 
> > I think what Christian is pointing out is that do we really 
> > need polling......
> > The question is that in case of unreliable transport protocol 
> > like UDP whether
> > the MGC ( or MG) should be allowed to wait for timeout of "a 
> > reply to a valid
> > request message" (like ADD, MODIFY etc. from MGC and NOTIFY, 
> > SVC from MG) to
> > detect failure of the other end. Or else, there should be a 
> > mechanism in built
> > in the MEGACO protocol to detect a MG or MGC failure....seems 
> > a better option
> > though it has an added overhead of polling.
> > 
> > Now, if we decide to introduce polling......the next issue is 
> > how to add
> > one.....
> > There are two proposals....
> > 1.   Through a notify...event "noop" with a delay parameter 
> > which controls the
> > frequency of polling.
> >      But, this I think has a dependency that this poll can 
> > only be initiated by
> > MGC thru' activation of an event descriptor.
> > 2.   Alternatively, we can use Service Change with "noop" 
> > method and add a
> > property to Base Root package "normalMGCIdleTime....or 
> > normalMGCPollTime". This
> > is the polling timeout duration provisioned at MG and 
> > settable by MGC at
> > runtime.
> > If MGC sets the value of this timer at runtime, MG should 
> > restart the polling
> > timer. Additionally, we can put a guideline that in case the 
> > MG or MGC receives
> > either a valid request or a valid reply from the other end 
> > within a polling
> > interval, the SVC "noop" need not be sent at the expiry of 
> > that polling
> > interval. Since service change can be sent by both MG and MGC 
> > this gives a
> > suitable solution for polling.
> > 
> > The concern about controlling the polling thru' MGC is 
> > addressed suitable by
> > both the alternatives.
> > 
> > Thanks,
> > -Kapil Nayar
> > Hughes Software Systems
> > 
> > 
> > 
> > 
> > 
> > "Rosen, Brian"  on 05/18/2001 06:22:46 PM
> > 
> > To:   "'Christian Groves'" , 
> > megaco@fore.com
> > cc:    (bcc: Kapil Nayar/HSS)
> > 
> > Subject:  RE: Polls of MGC
> > 
> > 
> > 
> > 
> > Christian
> > 
> > Everyone agrees that the way the MGC finds out if an MG is down is
> > to send a message and look for a response.  There are quite
> > a few messages an MGC could use.  I've suggested an audit.
> > 
> > Everyone also agrees that the way the MG finds out if the 
> MGC is down
> > is to send a message and get a response.  It would presumably have
> > some timer that is reset by any message from the MGC.  If the timer
> > expired, it would send a message (a poll), and look for a reply.
> > 
> > There are two issues:
> > 1. What message do you send?  MGs only send two messages, 
> > ServiceChange
> > and Notify.  The first series of messages on this thread 
> talked about
> > using SC as the message.  The issue is how to construct an SC
> > which does not change the MGCs notion of the MG state (ie behave
> > as a no-op).  The second set of messages talked about using Notify
> > as the poll
> > 
> > 2. How fast do you poll? The MGC really ought to be able to control
> > the frequency of polls, which would depend on how many MGs it was
> > controlling.  For this reason, we have been talking about 
> > using Notify,
> > with an interval parameter, which would be set by the MGC to control
> > the polling.  Using SC, even if you could, there is no way for the
> > MGC to control the polling rate.
> > 
> > If the MGC is down, the MG can do the right thing, which is 
> to contact
> > an alternate MGC for service.
> > 
> > Brian
> > 
> > > -----Original Message-----
> > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > > Sent: Friday, May 18, 2001 4:18 AM
> > > To: megaco@fore.com
> > > Subject: Re: Polls of MGC
> > >
> > >
> > > G'Day,
> > >
> > > I'd really like to understand the network scenario for adding this
> > > polling.
> > > As I see it the MGC can determine that an MG is down. ie. 
> > It issues a
> > > command and gets no response. It can take the appropriate action.
> > > Likewise the MG can determine when the MGC is down in the 
> same way.
> > > Except that if the MGC its connected to is down the MG 
> > can't do much.
> > > Remember the MGC is the Master and the MG is the slave.
> > >
> > > I really don't see the benefit of the MG doing periodic
> > > polling. It will
> > > find something is wrong when it tries to signal the MGC.
> > >
> > > Without going to Servicechange methods, reasons etc. What's
> > > the benefit?
> > >
> > > Cheers, Christian
> > >
> > >
> > 
> > 
> > 
> > 
> 


From owner-megaco@fore.com  Fri May 18 13:26:52 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02598
	for ; Fri, 18 May 2001 13:26:51 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07436;
	Fri, 18 May 2001 13:19:23 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA26655
	for megaco-list; Fri, 18 May 2001 13:18:27 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA26650
	for ; Fri, 18 May 2001 13:18:25 -0400 (EDT)
Received: from slink12.ss7-link.com (mail.ss7-link.com [209.204.106.218])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07345
	for ; Fri, 18 May 2001 13:18:20 -0400 (EDT)
Received: by SLINK12 with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 13:18:22 -0400
Message-ID: 
From: Dave Sclarsky 
To: "'Rosen, Brian'" ,
        "'Troy Cauble'"
	 
Cc: "'knayar@hss.hns.com'" , megaco@fore.com
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 13:18:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Brian,
We cannot let the MGs wait until they need to send something before learning
that an MGC went down.  You could have a ResGW disconnected from the network
all night!  What if Johnny at college needs to call home at 3am to bail him
out of jail?  Dad's controlling MGC won't be able to make his phone ring
because Dad hasn't made a call since the MGC restarted!  I guess if you're
Johnny's dad this is a good thing :-)

DaveS.

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Friday, May 18, 2001 11:22 AM
To: 'Troy Cauble'
Cc: 'knayar@hss.hns.com'; megaco@fore.com
Subject: RE: Polls of MGC


Y'know, I've asked myself that.  I'm not sure I'd use it IFF
the whole process of finding an MGC and getting back up was fast
enough to not cause problems with subscribers.

My conclusion is that it COULD take a long time, and thus I think
finding it out sooner is better.  I don't feel so strongly that
I think we just GOTTA change the protocol.

Brian

> -----Original Message-----
> From: Troy Cauble [mailto:troy@lucent.com]
> Sent: Friday, May 18, 2001 11:15 AM
> To: Rosen, Brian
> Cc: 'knayar@hss.hns.com'; megaco@fore.com
> Subject: Re: Polls of MGC
> 
> 
> "Rosen, Brian" wrote:
> > 
> > This discussion is not specifically detecting failure of the
> > MGC by timeout of response to a message.  It has to do with
> > detecting failure of the MGC when there is no message flow.
> 
> Brian,
> 
> I think the question is why do we *NEED* to detect failure
> when there is no message flow?  Why not wait and detect it
> when the MG tries to send something?  (From the MGs view,
> nothing has failed yet!)
> 
> -troy
> 


From owner-megaco@fore.com  Fri May 18 13:28:36 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02718
	for ; Fri, 18 May 2001 13:28:35 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07915;
	Fri, 18 May 2001 13:22:52 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA27187
	for megaco-list; Fri, 18 May 2001 13:21:22 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA27179
	for ; Fri, 18 May 2001 13:21:20 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07635
	for ; Fri, 18 May 2001 13:21:14 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4IHLEdQ002899
	for ; Fri, 18 May 2001 12:21:14 -0500 (CDT)
From: "Paul Long" 
To: 
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 12:21:16 -0500
Message-ID: 
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: <4FBEA8857476D311A03300204840E1CF01A6F644@whq-msgusr-02.pit.comms.marconi.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Brian,

The last two cases are what I'm talking about. The called MG will miss the
call because its MGC is down and it hasn't realized it yet in order to find
an alternate MGC. The MG didn't, of course, care if the MGC was down when
there was no activity, but, unlike placing an outgoing call, the activity of
a subscriber calling it from another MG will not cause the MG to find an
alternate MGC. I'm just saying that by polling the MGC or receiving a
keep-alive from the MGC, as someone just recommended, the MG would
substantially decrease the chance of a subscriber missing a call due to a
failed MGC.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Friday, May 18, 2001 12:05 PM
To: 'Paul Long'; megaco@fore.com
Subject: RE: Polls of MGC


This is a whole other problem.

If the calling party is on the same MG as the called party,
then the MG discovers the MGC is down by having the notify of
off hook (or equivalent), as we have been talking about, or the poll.

If the calling party is on a different MG, but the same MGC,
then the calling party will discover the MGC is down as above.

If the calling party is on a different MG and that MG is on a
different MGC, then the calling MGC will discover the MGC is down.

In all cases, the calling party gets a busy or other error,
and the called party is blissfully unaware of a missed call.

Brian



From owner-megaco@fore.com  Fri May 18 13:28:49 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02737
	for ; Fri, 18 May 2001 13:28:48 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07727;
	Fri, 18 May 2001 13:21:47 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA27106
	for megaco-list; Fri, 18 May 2001 13:20:47 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA27098
	for ; Fri, 18 May 2001 13:20:46 -0400 (EDT)
From: rezhirpavai@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07576
	for ; Fri, 18 May 2001 13:20:38 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4IHLaS26251;
	Fri, 18 May 2001 22:51:36 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A50.005DE527 ; Fri, 18 May 2001 22:35:35 +0530
X-Lotus-FromDomain: HSS
To: "Rosen, Brian" 
cc: "'Tom-PT Taylor'" ,
        "'Dan Elbert'" ,
        "'megaco@fore.com'" 
Message-ID: <65256A50.005DE2CE.00@sandesh.hss.hns.com>
Date: Fri, 18 May 2001 22:43:04 +0530
Subject: RE: Use of ServiceChange from MGC to MG
Mime-Version: 1.0
Content-type: multipart/mixed;
	Boundary="0__=NnVc90piiOZqWlKiEb8cFbzr94GKWuIJeJ5YhSFmWzlnqiSHKJidpolQ"
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

--0__=NnVc90piiOZqWlKiEb8cFbzr94GKWuIJeJ5YhSFmWzlnqiSHKJidpolQ
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Hello Brain,
     Since the MGC is the controller of the call, shouldn't the MGC explicitly
subtract the call from the context before taking the termination out of service?
In what scenarios would the MGC take the termination out of service and then
subtract it from the call explicitly.

     Taking it a bit further, if the MGC sends service change with "forced" on
ROOT termination, should the MG still wait for the contexts on all terminations
to be subtracted explicitly by the MGC before going down?


                                         Regards,
                                         R. Ezhirpavai





"Rosen, Brian"  on 05/18/2001 09:07:21 PM

To:   "'Tom-PT Taylor'" , "'Dan Elbert'"
      , "'megaco@fore.com'" 
cc:    (bcc: R Ezhirpavai/HSS)

Subject:  RE: Use of ServiceChange from MGC to MG




One thing I think is incorrect here is the "Subtracted from any active
contexts" part.  I believe we defined the protocol so that this NEVER
happens
as a side-effect.  The termination may actually be out of service, but both
the MG and the MGC have it in a context if it was when the termination was
taken out of service.

It is always incumbant on the MGC to do the subtract explicitly.

The ONLY exception to this is restart of the MG; all contexts are lost.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Friday, May 18, 2001 11:32 AM
To: 'Dan Elbert'; 'megaco@fore.com'
Subject: RE: Use of ServiceChange from MGC to MG



Hi.

> -----Original Message-----
> From: Dan Elbert [ mailto:DElbert@radvision.com
 ]
> Sent: Friday, May 18, 2001 11:06 AM
> To: 'megaco@fore.com'
> Subject: Use of ServiceChange from MGC to MG
>
>
> Hi
>
> The Media Gateway Controller may indicate that Termination(s)
> shall be taken
> out of or returned to service.
> 1. What is the meaning of the MGC taking down a termination ?
> Does it means
> that the termination is substracted from any active context
> and all signal
> are stopped and no events are detected ?

Yes

> 2. What methods are used for taking the MG down and up ? I'd
> say Graceful
> and Restart. Is this OK ?

"Taking the MG down" to me means doing a ServiceChange on ROOT at the MG.
It's possible the MGC might do that to an MG, but most likely in that case
that it would be done under manual control (i.e. the network is set up such
that control of MGs is exercised through the MGC).  I don't see this as a
typical maintence arrangement.

> 3. Is this applicable also to the root termination ? I would
> say no because
> if the root termination "goes down" then logically the MG may
> not be able to
> receive any more MGC commands.

Upon recovery the MG would follow normal start-up procedures to establish a
new control association.

>
> Thanks,
>
> Dan Elbert
> RADVISION
>



--0__=NnVc90piiOZqWlKiEb8cFbzr94GKWuIJeJ5YhSFmWzlnqiSHKJidpolQ
Content-type: text/html;
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U
RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9SVNPLTg4NTktMSI+DQo8VElUTEU+UkU6IFVzZSBvZiBT
ZXJ2aWNlQ2hhbmdlIGZyb20gTUdDIHRvIE1HPC9USVRMRT4NCg0KPE1FVEEgY29udGVudD0iTVNI
VE1MIDUuNTAuNDUyMi4xODAwIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWT4NCjxESVY+
PFNQQU4gY2xhc3M9NjIyMzAzNTE1LTE4MDUyMDAxPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAw
MDBmZj5PbmUgdGhpbmcgSSANCnRoaW5rIGlzIGluY29ycmVjdCBoZXJlIGlzIHRoZSAiU3VidHJh
Y3RlZCBmcm9tIGFueSBhY3RpdmU8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFz
cz02MjIzMDM1MTUtMTgwNTIwMDE+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmPmNvbnRl
eHRzIiANCnBhcnQuJm5ic3A7IEkgYmVsaWV2ZSB3ZSBkZWZpbmVkIHRoZSBwcm90b2NvbCBzbyB0
aGF0IHRoaXMgTkVWRVIgDQpoYXBwZW5zPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4g
Y2xhc3M9NjIyMzAzNTE1LTE4MDUyMDAxPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZj5h
cyBhIA0Kc2lkZS1lZmZlY3QuJm5ic3A7IFRoZSB0ZXJtaW5hdGlvbiBtYXkgYWN0dWFsbHkgYmUg
b3V0IG9mIHNlcnZpY2UsIGJ1dCANCmJvdGg8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BB
TiBjbGFzcz02MjIzMDM1MTUtMTgwNTIwMDE+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZm
PnRoZSBNRyBhbmQgDQp0aGUgTUdDIGhhdmUgaXQgaW4gYSBjb250ZXh0IGlmIGl0IHdhcyB3aGVu
IHRoZSB0ZXJtaW5hdGlvbiANCndhczwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNs
YXNzPTYyMjMwMzUxNS0xODA1MjAwMT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmY+dGFr
ZW4gb3V0IG9mIA0Kc2VydmljZS48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFz
cz02MjIzMDM1MTUtMTgwNTIwMDE+PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPSMwMDAwZmY+PC9G
T05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9NjIyMzAzNTE1LTE4MDUy
MDAxPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZj5JdCBpcyBhbHdheXMgDQppbmN1bWJh
bnQgb24gdGhlIE1HQyB0byBkbyB0aGUgc3VidHJhY3QgZXhwbGljaXRseS48L0ZPTlQ+PC9TUEFO
PjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz02MjIzMDM1MTUtMTgwNTIwMDE+PEZPTlQgZmFjZT1B
cmlhbCANCmNvbG9yPSMwMDAwZmY+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQ
QU4gY2xhc3M9NjIyMzAzNTE1LTE4MDUyMDAxPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBm
Zj5UaGUgT05MWSANCmV4Y2VwdGlvbiB0byB0aGlzIGlzIHJlc3RhcnQgb2YgdGhlIE1HOyBhbGwg
Y29udGV4dHMgYXJlIA0KbG9zdC48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFz
cz02MjIzMDM1MTUtMTgwNTIwMDE+PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPSMwMDAwZmY+PC9G
T05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9NjIyMzAzNTE1LTE4MDUy
MDAxPjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmPkJyaWFuPC9GT05UPjwvU1BBTj48
L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFERElORy1MRUZUOiA1cHg7IE1B
UkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMGZmIDJweCBzb2xpZDsgTUFSR0lOLVJJ
R0hUOiAwcHgiPg0KICA8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVyIGRpcj1sdHIgYWxp
Z249bGVmdD48Rk9OVCBmYWNlPVRhaG9tYSANCiAgc2l6ZT0yPi0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tPEJSPjxCPkZyb206PC9CPiBUb20tUFQgVGF5bG9yIA0KICBbbWFpbHRvOnRheWxvckBu
b3J0ZWxuZXR3b3Jrcy5jb21dPEJSPjxCPlNlbnQ6PC9CPiBGcmlkYXksIE1heSAxOCwgMjAwMSAx
MTozMiANCiAgQU08QlI+PEI+VG86PC9CPiAnRGFuIEVsYmVydCc7ICdtZWdhY29AZm9yZS5jb20n
PEJSPjxCPlN1YmplY3Q6PC9CPiBSRTogVXNlIG9mIA0KICBTZXJ2aWNlQ2hhbmdlIGZyb20gTUdD
IHRvIE1HPEJSPjxCUj48L0ZPTlQ+PC9ESVY+DQogIDxQPjxGT05UIHNpemU9Mj5IaS48L0ZPTlQ+
IDwvUD4NCiAgPFA+PEZPTlQgc2l6ZT0yPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08
L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyANCiAgRnJvbTogRGFuIEVsYmVydCBbPEEgDQog
IGhyZWY9Im1haWx0bzpERWxiZXJ0QHJhZHZpc2lvbi5jb20iPm1haWx0bzpERWxiZXJ0QHJhZHZp
c2lvbi5jb208L0E+XTwvRk9OVD4gDQogIDxCUj48Rk9OVCBzaXplPTI+Jmd0OyBTZW50OiBGcmlk
YXksIE1heSAxOCwgMjAwMSAxMTowNiBBTTwvRk9OVD4gPEJSPjxGT05UIA0KICBzaXplPTI+Jmd0
OyBUbzogJ21lZ2Fjb0Bmb3JlLmNvbSc8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyBTdWJq
ZWN0OiBVc2Ugb2YgDQogIFNlcnZpY2VDaGFuZ2UgZnJvbSBNR0MgdG8gTUc8L0ZPTlQ+IDxCUj48
Rk9OVCBzaXplPTI+Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIA0KICBzaXplPTI+Jmd0OyA8L0ZPTlQ+
PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IEhpIDwvRk9OVD48QlI+PEZPTlQgc2l6ZT0yPiZndDsgDQog
IDwvRk9OVD48QlI+PEZPTlQgc2l6ZT0yPiZndDsgVGhlIE1lZGlhIEdhdGV3YXkgQ29udHJvbGxl
ciBtYXkgaW5kaWNhdGUgdGhhdCANCiAgVGVybWluYXRpb24ocykgPC9GT05UPjxCUj48Rk9OVCBz
aXplPTI+Jmd0OyBzaGFsbCBiZSB0YWtlbjwvRk9OVD4gPEJSPjxGT05UIA0KICBzaXplPTI+Jmd0
OyBvdXQgb2Ygb3IgcmV0dXJuZWQgdG8gc2VydmljZS48L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+
Jmd0OyAxLiANCiAgV2hhdCBpcyB0aGUgbWVhbmluZyBvZiB0aGUgTUdDIHRha2luZyBkb3duIGEg
dGVybWluYXRpb24gPyA8L0ZPTlQ+PEJSPjxGT05UIA0KICBzaXplPTI+Jmd0OyBEb2VzIGl0IG1l
YW5zPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgdGhhdCB0aGUgdGVybWluYXRpb24gaXMg
DQogIHN1YnN0cmFjdGVkIGZyb20gYW55IGFjdGl2ZSBjb250ZXh0IDwvRk9OVD48QlI+PEZPTlQg
c2l6ZT0yPiZndDsgYW5kIGFsbCANCiAgc2lnbmFsPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZn
dDsgYXJlIHN0b3BwZWQgYW5kIG5vIGV2ZW50cyBhcmUgZGV0ZWN0ZWQgDQogID88L0ZPTlQ+IDwv
UD4NCiAgPFA+PEZPTlQgc2l6ZT0yPlllczwvRk9OVD4gPC9QPg0KICA8UD48Rk9OVCBzaXplPTI+
Jmd0OyAyLiBXaGF0IG1ldGhvZHMgYXJlIHVzZWQgZm9yIHRha2luZyB0aGUgTUcgZG93biBhbmQg
dXAgPyANCiAgSSdkIDwvRk9OVD48QlI+PEZPTlQgc2l6ZT0yPiZndDsgc2F5IEdyYWNlZnVsPC9G
T05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgYW5kIA0KICBSZXN0YXJ0LiBJcyB0aGlzIE9LID88
L0ZPTlQ+IDwvUD4NCiAgPFA+PEZPTlQgc2l6ZT0yPiJUYWtpbmcgdGhlIE1HIGRvd24iIHRvIG1l
IG1lYW5zIGRvaW5nIGEgU2VydmljZUNoYW5nZSBvbiBST09UIA0KICBhdCB0aGUgTUcuPC9GT05U
PiA8QlI+PEZPTlQgc2l6ZT0yPkl0J3MgcG9zc2libGUgdGhlIE1HQyBtaWdodCBkbyB0aGF0IHRv
IGFuIA0KICBNRywgYnV0IG1vc3QgbGlrZWx5IGluIHRoYXQgY2FzZSB0aGF0IGl0IHdvdWxkIGJl
IGRvbmUgdW5kZXIgbWFudWFsIGNvbnRyb2wgDQogIChpLmUuIHRoZSBuZXR3b3JrIGlzIHNldCB1
cCBzdWNoIHRoYXQgY29udHJvbCBvZiBNR3MgaXMgZXhlcmNpc2VkIHRocm91Z2ggdGhlIA0KICBN
R0MpLiZuYnNwOyBJIGRvbid0IHNlZSB0aGlzIGFzIGEgdHlwaWNhbCBtYWludGVuY2UgYXJyYW5n
ZW1lbnQuPC9GT05UPjwvUD4NCiAgPFA+PEZPTlQgc2l6ZT0yPiZndDsgMy4gSXMgdGhpcyBhcHBs
aWNhYmxlIGFsc28gdG8gdGhlIHJvb3QgdGVybWluYXRpb24gPyBJIA0KICB3b3VsZCA8L0ZPTlQ+
PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IHNheSBubyBiZWNhdXNlPC9GT05UPiA8QlI+PEZPTlQgc2l6
ZT0yPiZndDsgDQogIGlmIHRoZSByb290IHRlcm1pbmF0aW9uICJnb2VzIGRvd24iIHRoZW4gbG9n
aWNhbGx5IHRoZSBNRyBtYXkgPC9GT05UPjxCUj48Rk9OVCANCiAgc2l6ZT0yPiZndDsgbm90IGJl
IGFibGUgdG88L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyByZWNlaXZlIGFueSBtb3JlIE1H
QyANCiAgY29tbWFuZHMuPC9GT05UPiA8L1A+DQogIDxQPjxGT05UIHNpemU9Mj5VcG9uIHJlY292
ZXJ5IHRoZSBNRyB3b3VsZCBmb2xsb3cgbm9ybWFsIHN0YXJ0LXVwIHByb2NlZHVyZXMgDQogIHRv
IGVzdGFibGlzaCBhIG5ldyBjb250cm9sIGFzc29jaWF0aW9uLjwvRk9OVD4gPC9QPg0KICA8UD48
Rk9OVCBzaXplPTI+Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IFRoYW5rcyw8L0ZP
TlQ+IDxCUj48Rk9OVCANCiAgc2l6ZT0yPiZndDsgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0
OyBEYW4gRWxiZXJ0PC9GT05UPiA8QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7IFJBRFZJU0lPTjwv
Rk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IA0KPC9GT05UPjwvUD48L0JMT0NLUVVPVEU+PC9C
T0RZPjwvSFRNTD4NCg0K

--0__=NnVc90piiOZqWlKiEb8cFbzr94GKWuIJeJ5YhSFmWzlnqiSHKJidpolQ--



From owner-megaco@fore.com  Fri May 18 13:36:19 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03086
	for ; Fri, 18 May 2001 13:36:18 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08743;
	Fri, 18 May 2001 13:30:07 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA28895
	for megaco-list; Fri, 18 May 2001 13:28:47 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA28885
	for ; Fri, 18 May 2001 13:28:45 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 13:28:11 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F646@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Dave Sclarsky'" ,
        "'Troy Cauble'"
	 
Cc: "'knayar@hss.hns.com'" , megaco@fore.com
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 13:28:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Right.  I just replied to another version of this and forgot the
point that Johnnies MGC will figure out that Dad's MGC is down,
and that can be fixed, but Dad's MG won't register with the
replacement MGC because it doesn't know (yet) to do so. 

See that message for options.  The package will work, I think,
pretty well (modulo the worry about signals).  So will the
profile defined no-op SC method, and declaring restart of an 
up termination to be a no-op.  It occurs to me that we could
make this more palateable by saying a gracefull restart of an
up termination with a time of -1 was defined to be a no-op.

Brian

> -----Original Message-----
> From: Dave Sclarsky [mailto:Dave.Sclarsky@radisys.com]
> Sent: Friday, May 18, 2001 1:18 PM
> To: 'Rosen, Brian'; 'Troy Cauble'
> Cc: 'knayar@hss.hns.com'; megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> Brian,
> We cannot let the MGs wait until they need to send something 
> before learning
> that an MGC went down.  You could have a ResGW disconnected 
> from the network
> all night!  What if Johnny at college needs to call home at 
> 3am to bail him
> out of jail?  Dad's controlling MGC won't be able to make his 
> phone ring
> because Dad hasn't made a call since the MGC restarted!  I 
> guess if you're
> Johnny's dad this is a good thing :-)
> 
> DaveS.
> 
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Friday, May 18, 2001 11:22 AM
> To: 'Troy Cauble'
> Cc: 'knayar@hss.hns.com'; megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> Y'know, I've asked myself that.  I'm not sure I'd use it IFF
> the whole process of finding an MGC and getting back up was fast
> enough to not cause problems with subscribers.
> 
> My conclusion is that it COULD take a long time, and thus I think
> finding it out sooner is better.  I don't feel so strongly that
> I think we just GOTTA change the protocol.
> 
> Brian
> 
> > -----Original Message-----
> > From: Troy Cauble [mailto:troy@lucent.com]
> > Sent: Friday, May 18, 2001 11:15 AM
> > To: Rosen, Brian
> > Cc: 'knayar@hss.hns.com'; megaco@fore.com
> > Subject: Re: Polls of MGC
> > 
> > 
> > "Rosen, Brian" wrote:
> > > 
> > > This discussion is not specifically detecting failure of the
> > > MGC by timeout of response to a message.  It has to do with
> > > detecting failure of the MGC when there is no message flow.
> > 
> > Brian,
> > 
> > I think the question is why do we *NEED* to detect failure
> > when there is no message flow?  Why not wait and detect it
> > when the MG tries to send something?  (From the MGs view,
> > nothing has failed yet!)
> > 
> > -troy
> > 
> 


From owner-megaco@fore.com  Fri May 18 13:37:55 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03193
	for ; Fri, 18 May 2001 13:37:54 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08845;
	Fri, 18 May 2001 13:30:42 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA28962
	for megaco-list; Fri, 18 May 2001 13:29:13 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA28957
	for ; Fri, 18 May 2001 13:29:12 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08577
	for ; Fri, 18 May 2001 13:29:06 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 12:28:20 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD94945811101@RADVPOST>
From: Dan Elbert 
To: megaco@fore.com
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 12:28:16 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

I thought that by source transport address it was meant the IP address and
port where the message actually came from. Am I wrong ? Is this the address
in the message header ?

Dan

-----Original Message-----
From: Paul Long [mailto:plong@ipdialog.com]
Sent: Friday, May 18, 2001 12:43 PM
To: megaco@fore.com
Subject: RE: Polls of MGC

Dan,

The latter part of that passage concerns me because we just discussed the
fact that the mID is never _used_ as an actual IP address. It is merely a
lexeme that uniquely identifies the sending entity and has no other semantic
value. This passage would change that. I recommend nuking it.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dan Elbert
Sent: Friday, May 18, 2001 11:22 AM
To: 'megaco@fore.com'
Subject: RE: Polls of MGC


Well, in the implementers guide is specified  ( in 7.2.8 ) :

For UDP as a transport, the MG may specify the transport
ServiceChangeAddress to be used by the MGC for sending messages in the
ServiceChangeAddress parameter in the input ServiceChangeDescriptor.. If the
transport ServiceChangeAddress parameter is not present, then the MGC shall
use the source transport address (mId) used by the MG for sending commands
in subsequent communication with the MG.

Using a configured port may limit flexibility, but maybe is a better
solution.


From owner-megaco@fore.com  Fri May 18 13:45:45 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05514
	for ; Fri, 18 May 2001 13:45:44 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA09960;
	Fri, 18 May 2001 13:39:57 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA01121
	for megaco-list; Fri, 18 May 2001 13:38:35 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA01115
	for ; Fri, 18 May 2001 13:38:33 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 13:37:59 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F647@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'rezhirpavai@hss.hns.com'" 
Cc: "'Tom-PT Taylor'" ,
        "'Dan Elbert'"
	 ,
        "'megaco@fore.com'" 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Fri, 18 May 2001 13:38:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

I said that - the MGC does the Subtract explicitly; just
taking the termination out of service DOES NOT implicitly do
a Subtract.  If you are arguing about the order of operations,
I would recommend the Subtract before the ServiceChange.

The usual drill for the MGC is first to subtract, then serviceChange
forced.  There really isn't any reason for the MGC to use Graceful.

The usual drill for the MG is to send Graceful, the MGC responds
with Subtract, then the MG makes the terminations out of
service after the subtract or at the latest, after the timeout.

A forced Restart on Root should happen immediately.

Brian

> -----Original Message-----
> From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
> Sent: Friday, May 18, 2001 1:13 PM
> To: Rosen, Brian
> Cc: 'Tom-PT Taylor'; 'Dan Elbert'; 'megaco@fore.com'
> Subject: RE: Use of ServiceChange from MGC to MG
> 
> 
> 
> 
> Hello Brain,
>      Since the MGC is the controller of the call, shouldn't 
> the MGC explicitly
> subtract the call from the context before taking the 
> termination out of service?
> In what scenarios would the MGC take the termination out of 
> service and then
> subtract it from the call explicitly.
> 
>      Taking it a bit further, if the MGC sends service change 
> with "forced" on
> ROOT termination, should the MG still wait for the contexts 
> on all terminations
> to be subtracted explicitly by the MGC before going down?
> 
> 
>                                          Regards,
>                                          R. Ezhirpavai
> 
> 
> 
> 
> 
> "Rosen, Brian"  on 05/18/2001 09:07:21 PM
> 
> To:   "'Tom-PT Taylor'" , "'Dan Elbert'"
>       , "'megaco@fore.com'" 
> cc:    (bcc: R Ezhirpavai/HSS)
> 
> Subject:  RE: Use of ServiceChange from MGC to MG
> 
> 
> 
> 
> One thing I think is incorrect here is the "Subtracted from any active
> contexts" part.  I believe we defined the protocol so that this NEVER
> happens
> as a side-effect.  The termination may actually be out of 
> service, but both
> the MG and the MGC have it in a context if it was when the 
> termination was
> taken out of service.
> 
> It is always incumbant on the MGC to do the subtract explicitly.
> 
> The ONLY exception to this is restart of the MG; all contexts 
> are lost.
> 
> Brian
> 
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Friday, May 18, 2001 11:32 AM
> To: 'Dan Elbert'; 'megaco@fore.com'
> Subject: RE: Use of ServiceChange from MGC to MG
> 
> 
> 
> Hi.
> 
> > -----Original Message-----
> > From: Dan Elbert [ mailto:DElbert@radvision.com
>  ]
> > Sent: Friday, May 18, 2001 11:06 AM
> > To: 'megaco@fore.com'
> > Subject: Use of ServiceChange from MGC to MG
> >
> >
> > Hi
> >
> > The Media Gateway Controller may indicate that Termination(s)
> > shall be taken
> > out of or returned to service.
> > 1. What is the meaning of the MGC taking down a termination ?
> > Does it means
> > that the termination is substracted from any active context
> > and all signal
> > are stopped and no events are detected ?
> 
> Yes
> 
> > 2. What methods are used for taking the MG down and up ? I'd
> > say Graceful
> > and Restart. Is this OK ?
> 
> "Taking the MG down" to me means doing a ServiceChange on 
> ROOT at the MG.
> It's possible the MGC might do that to an MG, but most likely 
> in that case
> that it would be done under manual control (i.e. the network 
> is set up such
> that control of MGs is exercised through the MGC).  I don't 
> see this as a
> typical maintence arrangement.
> 
> > 3. Is this applicable also to the root termination ? I would
> > say no because
> > if the root termination "goes down" then logically the MG may
> > not be able to
> > receive any more MGC commands.
> 
> Upon recovery the MG would follow normal start-up procedures 
> to establish a
> new control association.
> 
> >
> > Thanks,
> >
> > Dan Elbert
> > RADVISION
> >
> 
> 
> 


From owner-megaco@fore.com  Fri May 18 13:46:53 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05566
	for ; Fri, 18 May 2001 13:46:52 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA09763;
	Fri, 18 May 2001 13:38:55 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA00967
	for megaco-list; Fri, 18 May 2001 13:37:50 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA00944
	for ; Fri, 18 May 2001 13:37:46 -0400 (EDT)
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA09573
	for ; Fri, 18 May 2001 13:37:40 -0400 (EDT)
Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.39 2001/05/18 00:47:02 root Exp $) with SMTP id RAA07999;
	Fri, 18 May 2001 17:37:30 GMT
Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 18 May 2001 17:37:30 0000 (GMT)
Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 18 May 2001 10:37:29 -0700
Message-ID: 
From: "Tulpule, Naren" 
To: "'David Stonehouse'" ,
        MEGACO list
	 
Subject: RE: SDP and ';' comments
Date: Fri, 18 May 2001 10:37:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0DFC1.336A2390"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DFC1.336A2390
Content-Type: text/plain;
	charset="iso-8859-1"



The resolution to Troy's initial statement is not only because of the way an
SDP ends, but also in the way that the octetString terminal will force the
Megaco parser to pull everything up to the '}' into the octetString.  
[Naren] Depends on the parser implementation... when there's no doubt that
the so-called octetstring is nothing but SDP, so you may not need to call
the Megaco octetstring parser followed by the SDP parser - you can call the
SDP parser in place. In this case the SDP parser can terminate when it
cannot understand the beginning of a line.


Pasting from Naren's post from last September (for which I never saw any
responses): 

    4. escaping "}" in SDP strings 
            I don't know if  "}" can appear in SDP attribute or VcId or
other 
    values. Nonetheless to be safe, especially on the MGC side when you
might 
    just want to treat SDP description as opaque, why not delimit the the 
    description with a line that starts with "==" (two "=" symbols) or a
similar 
    illegal combination? Using "\}" is really not feasible. 

The issue isn't that "}" could appear in SDP - it's whether "\}" could
appear in SDP.  If it can not, then it is okay for the Megaco parser to
translate the "\}" to "}", and pass the resulting string to the SDP parser.

[Naren] So far I haven't seen either "}" or "\}" in SDP. The thing is, we
don't really need to impose any restrictions on SDP at all. Just start a new
line with something which cannot occur after EOL in SDP  and define that to
be the "end-of-SDP-start-of-Megaco" delimiter (e.g. "==") instead of RBRKT.
(For the aesthetes, RBRKT can still follow this delimiter).

These views are mine alone, not those of Intel or Trillium. 
-- Naren 
Narendra C. Tulpule         310-442-9222 
SMTS, Trillium (an Intel company) 
12100 Wislshire Bl #1800 Los Angeles CA 90025 


------_=_NextPart_001_01C0DFC1.336A2390
Content-Type: text/html;
	charset="iso-8859-1"




RE: SDP and ';' comments





  

  
The resolution to Troy's initial statement is not only because 
  of the way an SDP ends, but also in the way that the octetString terminal will 
  force the Megaco parser to pull everything up to the '}' into the 
  octetString.  
[Naren] Depends on the parser implementation... 
  when there's no doubt that the so-called octetstring is nothing but SDP, so 
  you may not need to call the Megaco octetstring parser followed by the SDP 
  parser - you can call the SDP parser in place. In this case the SDP parser can 
  terminate when it cannot understand the beginning of a 
  line.

  
Pasting from 
  Naren's post from last September (for which I never saw any responses): 
  

  
    4. escaping "}" in SDP strings 
  
            I 
  don't know if  "}" can appear in SDP attribute or VcId or other 
  
    values. Nonetheless to be safe, especially 
  on the MGC side when you might 
    just 
  want to treat SDP description as opaque, why not delimit the the 
  
    description with a line that starts with 
  "==" (two "=" symbols) or a similar 
    
  illegal combination? Using "\}" is really not feasible. 

  
The issue isn't that "}" could appear in SDP - it's whether 
  "\}" could appear in SDP.  If it can not, then it is okay for the Megaco 
  parser to translate the "\}" to "}", and pass the resulting string to the SDP 
  parser.  
[Naren] So far I haven't seen either "}" or "\}" 
  in SDP. The thing is, we don't really need to impose any restrictions on 
  SDP at all. Just start a new line with something which cannot occur 
  after EOL in SDP  and define that to be the 
  "end-of-SDP-start-of-Megaco" delimiter (e.g. "==") instead of RBRKT. (For the 
  aesthetes, RBRKT can still follow this delimiter).

  
These views are mine alone, not 
  those of Intel or Trillium. 
-- 
  Naren 
Narendra C. 
  Tulpule         310-442-9222 
  
SMTS, Trillium (an Intel 
  company) 
12100 Wislshire Bl 
  #1800 Los Angeles CA 90025 


------_=_NextPart_001_01C0DFC1.336A2390--



From owner-megaco@fore.com  Fri May 18 13:50:34 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06540
	for ; Fri, 18 May 2001 13:50:33 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA10260;
	Fri, 18 May 2001 13:41:53 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA01389
	for megaco-list; Fri, 18 May 2001 13:40:29 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA01381
	for ; Fri, 18 May 2001 13:40:27 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 13:39:53 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F648@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "Rosen, Brian" ,
        "'Dave Sclarsky'"
	 ,
        "'Troy Cauble'" 
Cc: "'knayar@hss.hns.com'" , megaco@fore.com
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 13:40:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Woops, there is no such thing as "Graceful Restart".  Just a
Restart with a time of -1 could do it.

Brian

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Friday, May 18, 2001 1:29 PM
> To: 'Dave Sclarsky'; 'Troy Cauble'
> Cc: 'knayar@hss.hns.com'; megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> Right.  I just replied to another version of this and forgot the
> point that Johnnies MGC will figure out that Dad's MGC is down,
> and that can be fixed, but Dad's MG won't register with the
> replacement MGC because it doesn't know (yet) to do so. 
> 
> See that message for options.  The package will work, I think,
> pretty well (modulo the worry about signals).  So will the
> profile defined no-op SC method, and declaring restart of an 
> up termination to be a no-op.  It occurs to me that we could
> make this more palateable by saying a gracefull restart of an
> up termination with a time of -1 was defined to be a no-op.
> 
> Brian
> 
> > -----Original Message-----
> > From: Dave Sclarsky [mailto:Dave.Sclarsky@radisys.com]
> > Sent: Friday, May 18, 2001 1:18 PM
> > To: 'Rosen, Brian'; 'Troy Cauble'
> > Cc: 'knayar@hss.hns.com'; megaco@fore.com
> > Subject: RE: Polls of MGC
> > 
> > 
> > Brian,
> > We cannot let the MGs wait until they need to send something 
> > before learning
> > that an MGC went down.  You could have a ResGW disconnected 
> > from the network
> > all night!  What if Johnny at college needs to call home at 
> > 3am to bail him
> > out of jail?  Dad's controlling MGC won't be able to make his 
> > phone ring
> > because Dad hasn't made a call since the MGC restarted!  I 
> > guess if you're
> > Johnny's dad this is a good thing :-)
> > 
> > DaveS.
> > 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > Sent: Friday, May 18, 2001 11:22 AM
> > To: 'Troy Cauble'
> > Cc: 'knayar@hss.hns.com'; megaco@fore.com
> > Subject: RE: Polls of MGC
> > 
> > 
> > Y'know, I've asked myself that.  I'm not sure I'd use it IFF
> > the whole process of finding an MGC and getting back up was fast
> > enough to not cause problems with subscribers.
> > 
> > My conclusion is that it COULD take a long time, and thus I think
> > finding it out sooner is better.  I don't feel so strongly that
> > I think we just GOTTA change the protocol.
> > 
> > Brian
> > 
> > > -----Original Message-----
> > > From: Troy Cauble [mailto:troy@lucent.com]
> > > Sent: Friday, May 18, 2001 11:15 AM
> > > To: Rosen, Brian
> > > Cc: 'knayar@hss.hns.com'; megaco@fore.com
> > > Subject: Re: Polls of MGC
> > > 
> > > 
> > > "Rosen, Brian" wrote:
> > > > 
> > > > This discussion is not specifically detecting failure of the
> > > > MGC by timeout of response to a message.  It has to do with
> > > > detecting failure of the MGC when there is no message flow.
> > > 
> > > Brian,
> > > 
> > > I think the question is why do we *NEED* to detect failure
> > > when there is no message flow?  Why not wait and detect it
> > > when the MG tries to send something?  (From the MGs view,
> > > nothing has failed yet!)
> > > 
> > > -troy
> > > 
> > 
> 


From owner-megaco@fore.com  Fri May 18 13:58:17 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08138
	for ; Fri, 18 May 2001 13:58:17 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA11333;
	Fri, 18 May 2001 13:49:55 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA03762
	for megaco-list; Fri, 18 May 2001 13:48:36 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA03741
	for ; Fri, 18 May 2001 13:48:33 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA11038
	for ; Fri, 18 May 2001 13:48:27 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACS15556;
	Fri, 18 May 2001 13:48:21 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: 
Cc: "'Dan Elbert'" , 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Fri, 18 May 2001 13:52:25 -0400
Message-ID: <025401c0dfc3$4cd1ab80$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <65256A50.005C6CAF.00@sandesh.hss.hns.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

HI Pavai,
I think second point address non-ROOT terminations. I don't think the MGC
can send ServiceChange on ROOT to either bring it down or up. (Of course
there is no restriction from the protocol that MGC cannot send ServiceChange
on ROOT...I think we may need some consensus on this from everyone).

Regards
Madhubabu

-----Original Message-----
From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
Sent: Friday, May 18, 2001 12:55 PM
To: Madhu Babu Brahmanapally
Cc: 'Dan Elbert'; megaco@fore.com
Subject: RE: Use of ServiceChange from MGC to MG




Hello Madhu,
     In the second point you have mentioned about the methods for taking the
MG
down as "forced" and restart".  If the MG itself wants to indicate about its
going down, then it can either send "graceful" or "forced", but if the MGC
wants
to bring down its association with the MG then it needs to send service
change
on ROOT with "forced". "Restart" from MGC on ROOT termination is not valid.
In
this case the MG needs to itself send service change to any secondary MGC or
to
the same primary MGC (if secondary MGC are configured) after restart
avalance
timer.


                                         Regards,
                                         R. Ezhirpavai





"Madhu Babu Brahmanapally"  on 05/18/2001 09:05:16 PM

To:   "'Dan Elbert'" , megaco@fore.com
cc:    (bcc: R Ezhirpavai/HSS)

Subject:  RE: Use of ServiceChange from MGC to MG




HI Dan,
Comments below [Madhu]

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dan Elbert
Sent: Friday, May 18, 2001 11:06 AM
To: 'megaco@fore.com'
Subject: Use of ServiceChange from MGC to MG


Hi

The Media Gateway Controller may indicate that Termination(s) shall be taken
out of or returned to service.

1. What is the meaning of the MGC taking down a termination ? Does it means
that the termination is substracted from any active context and all signal
are stopped and no events are detected ?
[Madhu] IMO its similar to the situation where MG generates such
servicechange.
The signals to be stopped and no event detection.
Will be useful in
1) Residential Gateway - Where the user profile is not encouraging and the
MGC doesn't
want to entertain any messages generated from the MG for that endpoint.
2) Trunking gateway - Remove some of the trunks from the initial provisioned
trunks.

2. What methods are used for taking the MG down and up ? I'd say Graceful
and Restart. Is this OK ?
[Madhu] I think Graceful is a mean by which MG can say to MGC that this
particular termination
shouldn't be used for further calls. Graceful has no meaning when MGC
generates this. I think the
methods should be "forced" and "restart".

3. Is this applicable also to the root termination ? I would say no because
if the root termination "goes down" then logically the MG may not be able to
receive any more MGC commands.
[Madhu] Yes. Your argument is correct.

Thanks,

Dan Elbert
RADVISION







From owner-megaco@fore.com  Fri May 18 14:17:01 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10474
	for ; Fri, 18 May 2001 14:17:01 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA12783;
	Fri, 18 May 2001 13:58:32 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA06625
	for megaco-list; Fri, 18 May 2001 13:57:14 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA06607
	for ; Fri, 18 May 2001 13:57:12 -0400 (EDT)
Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA12531
	for ; Fri, 18 May 2001 13:57:05 -0400 (EDT)
Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203])
	by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.39 2001/05/18 00:47:02 root Exp $) with SMTP id RAA00231;
	Fri, 18 May 2001 17:57:04 GMT
Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 18 May 2001 17:57:04 0000 (GMT)
Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 18 May 2001 10:57:02 -0700
Message-ID: 
From: "Kaul, Bharat" 
To: "'Dan Elbert'" ,
        "'megaco@fore.com'"
	 
Cc: "'Paul Long'" 
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 10:56:59 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Dan, 

 Paul has suggested changes to this passage....esentially UDP will be
replaced with Connection Less transport protocol and MID is just a logical
identifier i.e. it does not convey any transport address information. The
mention of MID in the passage is a typo.

For connection less transport, the intention is that MG can ask MGC to
communicate at some other port through ServiceChangeAddress. 

If ServiceChangeAddress is missing, then it is source transport address used
by MG to send the command. Essentially this is where it differs from MGCP
world.

- Bharat


-----Original Message-----
From: Dan Elbert [mailto:DElbert@radvision.com]
Sent: Friday, May 18, 2001 9:22 AM
To: 'megaco@fore.com'
Subject: RE: Polls of MGC


Well, in the implementers guide is specified  ( in 7.2.8 ) :

For UDP as a transport, the MG may specify the transport
ServiceChangeAddress to be used by the MGC for sending messages in the
ServiceChangeAddress parameter in the input ServiceChangeDescriptor.. If the
transport ServiceChangeAddress parameter is not present, then the MGC shall
use the source transport address (mId) used by the MG for sending commands
in subsequent communication with the MG.

Using a configured port may limit flexibility, but maybe is a better
solution.

-----Original Message-----
From: Troy Cauble [mailto:troy@lucent.com]
Sent: Friday, May 18, 2001 12:02 PM
To: Dan Elbert
Cc: megaco@fore.com
Subject: Re: Polls of MGC


Then that's the problem:)
Have the MGs use a default or configured port also.
Seriously, why not?

Polling is BAD.

-troy


(BTW, I wasn't really proposing that we use the MGCP/NCS
 DNS based mechanism.  I was just responding to Christian's
 comment that the "MG can't do much" when it detects failure.
 A quick peek at section 9 shows me the H.248 mechanism:
 "The MGC is provisioned with a name or address of a primary and
 zero or more secondary MGCs".)




Dan Elbert wrote:
>
> The difference with MGCP is that in MGCP when the MGC comes up it know how
> to contact the MGs ( they listen in a default or configured port) , but in
> Megaco the MGC only knows the MG port after the MG connects to it. If the
> MGC goes down normally this information can be saved, but if it fails and
> this information is lost, in some situations there is no way for the MG
and
> MGC to connect to each other again.
>
> Dan
>
> -----Original Message-----
> From: Troy Cauble [mailto:troy@lucent.com]
> Sent: Friday, May 18, 2001 11:11 AM
> To: Christian Groves
> Cc: megaco@fore.com
> Subject: Re: Polls of MGC
>
> Christian Groves wrote:
> >
> > G'Day,
> >
> > I'd really like to understand the network scenario for adding this
> > polling.
> > As I see it the MGC can determine that an MG is down. ie. It issues a
> > command and gets no response. It can take the appropriate action.
> > Likewise the MG can determine when the MGC is down in the same way.
> > Except that if the MGC its connected to is down the MG can't do much.
> > Remember the MGC is the Master and the MG is the slave.
>
> MGCP/NCS has a failover scheme involving multiple DNS entries.  Basically
> if the MG can't reach the MGC after X tries, it checks the DNS entry for
> another IP address and tries it.  (Actually it's fairly complicated with
> attempt counts and timers, etc., but that's the idea.)
>
> Any failover method needs to consider security.  It's not very good
> if the MG accepts messages that say "I'm your MGC now" from anyone.
>
> > I really don't see the benefit of the MG doing periodic polling. It will
> > find something is wrong when it tries to signal the MGC.
>
> I don't see the benefit either.  It'll find out when it tries to
> communicate something. Before then, it didn't need to know.
> The MGC might come back online before the MG needs it.
>
> Picture 5000 MGs polling an MGC.  That's a lot of traffic.
> If the MGC is down for 5 minutes, 5000 MGs detect it and
> switch over *somehow* to the backup MGC, then need to be
> switched back to the original.  That's a lot of traffic too.
> If you let the MGs handle the problem as needed, maybe only
> a handful would have needed to.
>
> > Without going to Servicechange methods, reasons etc. What's the benefit?
> >
> > Cheers, Christian



From owner-megaco@fore.com  Fri May 18 14:18:46 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10548
	for ; Fri, 18 May 2001 14:18:45 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13665;
	Fri, 18 May 2001 14:06:07 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA08267
	for megaco-list; Fri, 18 May 2001 14:03:00 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA08231
	for ; Fri, 18 May 2001 14:00:45 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13077
	for ; Fri, 18 May 2001 14:00:38 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACS15692;
	Fri, 18 May 2001 14:00:22 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Rosen, Brian'" , 
Cc: "'Tom-PT Taylor'" ,
        "'Dan Elbert'" , 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Fri, 18 May 2001 14:04:25 -0400
Message-ID: <025701c0dfc4$fa13a770$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <4FBEA8857476D311A03300204840E1CF01A6F647@whq-msgusr-02.pit.comms.marconi.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

HI Brian,
Do you mean that the MGC can send ServiceChange on ROOT with either
"Restart" or "Forced". I was in the impression that ROOT is some special
termination indicating the Whole MG and the MG uses it to registers itself
with the MGC. As you said "A forced Restart on Root should happen
immediately.", Is it your intention that the MG should initiate this
Restart???

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Friday, May 18, 2001 1:39 PM
To: 'rezhirpavai@hss.hns.com'
Cc: 'Tom-PT Taylor'; 'Dan Elbert'; 'megaco@fore.com'
Subject: RE: Use of ServiceChange from MGC to MG


I said that - the MGC does the Subtract explicitly; just
taking the termination out of service DOES NOT implicitly do
a Subtract.  If you are arguing about the order of operations,
I would recommend the Subtract before the ServiceChange.

The usual drill for the MGC is first to subtract, then serviceChange
forced.  There really isn't any reason for the MGC to use Graceful.

The usual drill for the MG is to send Graceful, the MGC responds
with Subtract, then the MG makes the terminations out of
service after the subtract or at the latest, after the timeout.

A forced Restart on Root should happen immediately.

Brian

> -----Original Message-----
> From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
> Sent: Friday, May 18, 2001 1:13 PM
> To: Rosen, Brian
> Cc: 'Tom-PT Taylor'; 'Dan Elbert'; 'megaco@fore.com'
> Subject: RE: Use of ServiceChange from MGC to MG
>
>
>
>
> Hello Brain,
>      Since the MGC is the controller of the call, shouldn't
> the MGC explicitly
> subtract the call from the context before taking the
> termination out of service?
> In what scenarios would the MGC take the termination out of
> service and then
> subtract it from the call explicitly.
>
>      Taking it a bit further, if the MGC sends service change
> with "forced" on
> ROOT termination, should the MG still wait for the contexts
> on all terminations
> to be subtracted explicitly by the MGC before going down?
>
>
>                                          Regards,
>                                          R. Ezhirpavai
>
>
>
>
>
> "Rosen, Brian"  on 05/18/2001 09:07:21 PM
>
> To:   "'Tom-PT Taylor'" , "'Dan Elbert'"
>       , "'megaco@fore.com'" 
> cc:    (bcc: R Ezhirpavai/HSS)
>
> Subject:  RE: Use of ServiceChange from MGC to MG
>
>
>
>
> One thing I think is incorrect here is the "Subtracted from any active
> contexts" part.  I believe we defined the protocol so that this NEVER
> happens
> as a side-effect.  The termination may actually be out of
> service, but both
> the MG and the MGC have it in a context if it was when the
> termination was
> taken out of service.
>
> It is always incumbant on the MGC to do the subtract explicitly.
>
> The ONLY exception to this is restart of the MG; all contexts
> are lost.
>
> Brian
>
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Friday, May 18, 2001 11:32 AM
> To: 'Dan Elbert'; 'megaco@fore.com'
> Subject: RE: Use of ServiceChange from MGC to MG
>
>
>
> Hi.
>
> > -----Original Message-----
> > From: Dan Elbert [ mailto:DElbert@radvision.com
>  ]
> > Sent: Friday, May 18, 2001 11:06 AM
> > To: 'megaco@fore.com'
> > Subject: Use of ServiceChange from MGC to MG
> >
> >
> > Hi
> >
> > The Media Gateway Controller may indicate that Termination(s)
> > shall be taken
> > out of or returned to service.
> > 1. What is the meaning of the MGC taking down a termination ?
> > Does it means
> > that the termination is substracted from any active context
> > and all signal
> > are stopped and no events are detected ?
>
> Yes
>
> > 2. What methods are used for taking the MG down and up ? I'd
> > say Graceful
> > and Restart. Is this OK ?
>
> "Taking the MG down" to me means doing a ServiceChange on
> ROOT at the MG.
> It's possible the MGC might do that to an MG, but most likely
> in that case
> that it would be done under manual control (i.e. the network
> is set up such
> that control of MGs is exercised through the MGC).  I don't
> see this as a
> typical maintence arrangement.
>
> > 3. Is this applicable also to the root termination ? I would
> > say no because
> > if the root termination "goes down" then logically the MG may
> > not be able to
> > receive any more MGC commands.
>
> Upon recovery the MG would follow normal start-up procedures
> to establish a
> new control association.
>
> >
> > Thanks,
> >
> > Dan Elbert
> > RADVISION
> >
>
>
>



From owner-megaco@fore.com  Fri May 18 14:21:16 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10610
	for ; Fri, 18 May 2001 14:21:16 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13874;
	Fri, 18 May 2001 14:07:15 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA09273
	for megaco-list; Fri, 18 May 2001 14:05:03 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA08925
	for ; Fri, 18 May 2001 14:02:25 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 14:01:44 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F64A@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Tulpule, Naren'" ,
        "'David Stonehouse'"
	 ,
        MEGACO list 
Subject: RE: SDP and ';' comments
Date: Fri, 18 May 2001 14:02:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0DFC4.ABE3C8F0"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DFC4.ABE3C8F0
Content-Type: text/plain;
	charset="ISO-8859-1"

A line that starts with "}" after a well formed line in SDP is an error.
So would be a line that started with ==.
 
Either you find the matching "}" in the Megaco parser, and pass the body to
the SDP parser, or you change the SDP parser to stop on the "}" and invoke
it
in-line.  Adding a == wouldn't change that except for not having to back up
the scanner on the }.  I don't want to change the protocol to add the "==".
 
Brian

-----Original Message-----
From: Tulpule, Naren [mailto:naren@trillium.com]
Sent: Friday, May 18, 2001 1:37 PM
To: 'David Stonehouse'; MEGACO list
Subject: RE: SDP and ';' comments





The resolution to Troy's initial statement is not only because of the way an
SDP ends, but also in the way that the octetString terminal will force the
Megaco parser to pull everything up to the '}' into the octetString.  
[Naren] Depends on the parser implementation... when there's no doubt that
the so-called octetstring is nothing but SDP, so you may not need to call
the Megaco octetstring parser followed by the SDP parser - you can call the
SDP parser in place. In this case the SDP parser can terminate when it
cannot understand the beginning of a line.


Pasting from Naren's post from last September (for which I never saw any
responses): 

    4. escaping "}" in SDP strings 
            I don't know if  "}" can appear in SDP attribute or VcId or
other 
    values. Nonetheless to be safe, especially on the MGC side when you
might 
    just want to treat SDP description as opaque, why not delimit the the 
    description with a line that starts with "==" (two "=" symbols) or a
similar 
    illegal combination? Using "\}" is really not feasible. 

The issue isn't that "}" could appear in SDP - it's whether "\}" could
appear in SDP.  If it can not, then it is okay for the Megaco parser to
translate the "\}" to "}", and pass the resulting string to the SDP parser.

[Naren] So far I haven't seen either "}" or "\}" in SDP. The thing is, we
don't really need to impose any restrictions on SDP at all. Just start a new
line with something which cannot occur after EOL in SDP  and define that to
be the "end-of-SDP-start-of-Megaco" delimiter (e.g. "==") instead of RBRKT.
(For the aesthetes, RBRKT can still follow this delimiter).

These views are mine alone, not those of Intel or Trillium. 
-- Naren 
Narendra C. Tulpule         310-442-9222 
SMTS, Trillium (an Intel company) 
12100 Wislshire Bl #1800 Los Angeles CA 90025 


------_=_NextPart_001_01C0DFC4.ABE3C8F0
Content-Type: text/html;
	charset="ISO-8859-1"




RE: SDP and ';' comments




A line that 
starts with "}" after a well formed line in SDP is an error.


So would be a 
line that started with ==.


 


Either you 
find the matching "}" in the Megaco parser, and pass the body 
to


the SDP 
parser, or you change the SDP parser to stop on the "}" and invoke 
it


in-line.  Adding a == wouldn't change 
that except for not having to back up


the scanner 
on the }.  I don't want to change the protocol to add the 
"==".


 


Brian



  
-----Original Message-----
From: Tulpule, Naren 
  [mailto:naren@trillium.com]
Sent: Friday, May 18, 2001 1:37 
  PM
To: 'David Stonehouse'; MEGACO list
Subject: RE: SDP 
  and ';' comments


  

    

    
The resolution to Troy's initial statement is not only 
    because of the way an SDP ends, but also in the way that the octetString 
    terminal will force the Megaco parser to pull everything up to the '}' into 
    the octetString.  
[Naren] Depends on the parser 
    implementation... when there's no doubt that the so-called octetstring is 
    nothing but SDP, so you may not need to call the Megaco octetstring parser 
    followed by the SDP parser - you can call the SDP parser in place. In this 
    case the SDP parser can terminate when it cannot understand the beginning of 
    a line.

    
Pasting 
    from Naren's post from last September (for which I never saw any 
    responses): 

    
    4. escaping "}" in SDP strings 
    
            I 
    don't know if  "}" can appear in SDP attribute or VcId or other 
    
    values. Nonetheless to be safe, 
    especially on the MGC side when you might 
    just want to treat SDP description as opaque, why 
    not delimit the the 
    description 
    with a line that starts with "==" (two "=" symbols) or a similar 
    
    illegal combination? Using "\}" is 
    really not feasible. 

    
The issue isn't that "}" could appear in SDP - it's whether 
    "\}" could appear in SDP.  If it can not, then it is okay for the 
    Megaco parser to translate the "\}" to "}", and pass the resulting string to 
    the SDP parser.  
[Naren] So far I haven't seen either "}" or 
    "\}" in SDP. The thing is, we don't really need to impose any 
    restrictions on SDP at all. Just start a new line with something which 
    cannot occur after EOL in SDP  and define that to be the 
    "end-of-SDP-start-of-Megaco" delimiter (e.g. "==") instead of RBRKT. (For 
    the aesthetes, RBRKT can still follow this 
    delimiter).

    
These views are mine alone, not 
    those of Intel or Trillium. 
-- Naren 
Narendra C. Tulpule         
    310-442-9222 
SMTS, 
    Trillium (an Intel company) 
12100 Wislshire Bl #1800 Los Angeles CA 90025 
    


------_=_NextPart_001_01C0DFC4.ABE3C8F0--


From owner-megaco@fore.com  Fri May 18 14:22:16 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10634
	for ; Fri, 18 May 2001 14:22:16 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13761;
	Fri, 18 May 2001 14:06:39 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA09641
	for megaco-list; Fri, 18 May 2001 14:04:57 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA09587
	for ; Fri, 18 May 2001 14:03:52 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 14:03:11 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F64B@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Madhu Babu Brahmanapally'" ,
        rezhirpavai@hss.hns.com
Cc: "'Dan Elbert'" , megaco@fore.com
Subject: RE: Use of ServiceChange from MGC to MG
Date: Fri, 18 May 2001 14:03:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

I think you can - it's an MGC invoked soft boot.

Brian

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Friday, May 18, 2001 1:52 PM
> To: rezhirpavai@hss.hns.com
> Cc: 'Dan Elbert'; megaco@fore.com
> Subject: RE: Use of ServiceChange from MGC to MG
> 
> 
> HI Pavai,
> I think second point address non-ROOT terminations. I don't 
> think the MGC
> can send ServiceChange on ROOT to either bring it down or up. 
> (Of course
> there is no restriction from the protocol that MGC cannot 
> send ServiceChange
> on ROOT...I think we may need some consensus on this from everyone).
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
> Sent: Friday, May 18, 2001 12:55 PM
> To: Madhu Babu Brahmanapally
> Cc: 'Dan Elbert'; megaco@fore.com
> Subject: RE: Use of ServiceChange from MGC to MG
> 
> 
> 
> 
> Hello Madhu,
>      In the second point you have mentioned about the methods 
> for taking the
> MG
> down as "forced" and restart".  If the MG itself wants to 
> indicate about its
> going down, then it can either send "graceful" or "forced", 
> but if the MGC
> wants
> to bring down its association with the MG then it needs to 
> send service
> change
> on ROOT with "forced". "Restart" from MGC on ROOT termination 
> is not valid.
> In
> this case the MG needs to itself send service change to any 
> secondary MGC or
> to
> the same primary MGC (if secondary MGC are configured) after restart
> avalance
> timer.
> 
> 
>                                          Regards,
>                                          R. Ezhirpavai
> 
> 
> 
> 
> 
> "Madhu Babu Brahmanapally"  on 
> 05/18/2001 09:05:16 PM
> 
> To:   "'Dan Elbert'" , megaco@fore.com
> cc:    (bcc: R Ezhirpavai/HSS)
> 
> Subject:  RE: Use of ServiceChange from MGC to MG
> 
> 
> 
> 
> HI Dan,
> Comments below [Madhu]
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dan Elbert
> Sent: Friday, May 18, 2001 11:06 AM
> To: 'megaco@fore.com'
> Subject: Use of ServiceChange from MGC to MG
> 
> 
> Hi
> 
> The Media Gateway Controller may indicate that Termination(s) 
> shall be taken
> out of or returned to service.
> 
> 1. What is the meaning of the MGC taking down a termination ? 
> Does it means
> that the termination is substracted from any active context 
> and all signal
> are stopped and no events are detected ?
> [Madhu] IMO its similar to the situation where MG generates such
> servicechange.
> The signals to be stopped and no event detection.
> Will be useful in
> 1) Residential Gateway - Where the user profile is not 
> encouraging and the
> MGC doesn't
> want to entertain any messages generated from the MG for that 
> endpoint.
> 2) Trunking gateway - Remove some of the trunks from the 
> initial provisioned
> trunks.
> 
> 2. What methods are used for taking the MG down and up ? I'd 
> say Graceful
> and Restart. Is this OK ?
> [Madhu] I think Graceful is a mean by which MG can say to MGC 
> that this
> particular termination
> shouldn't be used for further calls. Graceful has no meaning when MGC
> generates this. I think the
> methods should be "forced" and "restart".
> 
> 3. Is this applicable also to the root termination ? I would 
> say no because
> if the root termination "goes down" then logically the MG may 
> not be able to
> receive any more MGC commands.
> [Madhu] Yes. Your argument is correct.
> 
> Thanks,
> 
> Dan Elbert
> RADVISION
> 
> 
> 
> 
> 


From owner-megaco@fore.com  Fri May 18 14:22:45 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10659
	for ; Fri, 18 May 2001 14:22:44 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14603;
	Fri, 18 May 2001 14:12:34 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA11379
	for megaco-list; Fri, 18 May 2001 14:08:06 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA11370
	for ; Fri, 18 May 2001 14:08:04 -0400 (EDT)
Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13962
	for ; Fri, 18 May 2001 14:07:56 -0400 (EDT)
Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1])
	by ihemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4II7tT06258
	for ; Fri, 18 May 2001 14:07:55 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4II7tU06245
	for ; Fri, 18 May 2001 14:07:55 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id OAA21105; Fri, 18 May 2001 14:07:38 -0400 (EDT)
Cc: MEGACO list , "'Tulpule, Naren'" 
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id OAA21096; Fri, 18 May 2001 14:07:36 -0400 (EDT)
Message-ID: <3B056472.7E38EDEF@lucent.com>
Date: Fri, 18 May 2001 14:05:38 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: David Stonehouse 
Original-CC: MEGACO list , "'Tulpule, Naren'" 
Subject: Re: SDP and ';' comments
References: <45D2A43C1913D51180F40000F89CB87404DC0D@nrtpde0a.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

> David Stonehouse wrote:
> 
> The resolution to Troy's initial statement is not only because of the way an
> SDP ends, but also in the way that the octetString terminal will force the
> Megaco parser to pull everything up to the '}' into the octetString.  The net
> result is even though the official definition of RBRKT allows for a comment
> in front or behind, in this case, there will never be any LWSP (including
> comments) for the Megaco parser to parse before the '}'.  The resulting
> octetString is what will get passed to the SDP parser.  If this string fails
> to parse according to SDP syntax, then the message should be rejected for bad
> syntax (including any trailing Megaco comment ';').
> 
> So, even if the comment were added after the newline but before the '}', it
> is still bad syntax because it falls under SDP parsing rules.  (A parser may
> want to be liberal in accepting this, but that's beside the point.)

David,

While many parsers work this way, I don't think that using ABNF
implies that ambiguous text has to be applied to the preceding token.
That is, it's just as valid to associate the spaces in "}    }" with
the last RBRKT as the first.

So I think comments between the last line of SDP and the '}' are 
legal unless we explicitly document that they're not.


-troy


From owner-megaco@fore.com  Fri May 18 14:25:23 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10771
	for ; Fri, 18 May 2001 14:25:23 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14710;
	Fri, 18 May 2001 14:13:12 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA11375
	for megaco-list; Fri, 18 May 2001 14:08:05 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA11365
	for ; Fri, 18 May 2001 14:08:02 -0400 (EDT)
From: rezhirpavai@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13956
	for ; Fri, 18 May 2001 14:07:51 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4II7AY26587;
	Fri, 18 May 2001 23:37:10 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A50.00620FC8 ; Fri, 18 May 2001 23:21:05 +0530
X-Lotus-FromDomain: HSS
To: "Rosen, Brian" 
cc: "'Tom-PT Taylor'" ,
        "'Dan Elbert'" ,
        "'megaco@fore.com'" 
Message-ID: <65256A50.00620C85.00@sandesh.hss.hns.com>
Date: Fri, 18 May 2001 23:28:27 +0530
Subject: RE: Use of ServiceChange from MGC to MG
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk



Hello Brain,
     Yes, I was mentioning about the order of operations. IMHO, the protocol
should enforce the MGC to subtract the termination from context before putting
it out of service. If the MGC sends the service change for putting the
termination out of service, while the termination is in context, MG should send
back an error to the MGC, thus indicating to the MGC that the termination is in
context and any discripency between the MG and MGC may be resolved.

                                         Regards,
                                         R. Ezhirpavai





"Rosen, Brian"  on 05/18/2001 11:08:30 PM

To:   R Ezhirpavai/HSS@HSS
cc:   "'Tom-PT Taylor'" , "'Dan Elbert'"
      , "'megaco@fore.com'" 

Subject:  RE: Use of ServiceChange from MGC to MG




I said that - the MGC does the Subtract explicitly; just
taking the termination out of service DOES NOT implicitly do
a Subtract.  If you are arguing about the order of operations,
I would recommend the Subtract before the ServiceChange.

The usual drill for the MGC is first to subtract, then serviceChange
forced.  There really isn't any reason for the MGC to use Graceful.

The usual drill for the MG is to send Graceful, the MGC responds
with Subtract, then the MG makes the terminations out of
service after the subtract or at the latest, after the timeout.

A forced Restart on Root should happen immediately.

Brian

> -----Original Message-----
> From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
> Sent: Friday, May 18, 2001 1:13 PM
> To: Rosen, Brian
> Cc: 'Tom-PT Taylor'; 'Dan Elbert'; 'megaco@fore.com'
> Subject: RE: Use of ServiceChange from MGC to MG
>
>
>
>
> Hello Brain,
>      Since the MGC is the controller of the call, shouldn't
> the MGC explicitly
> subtract the call from the context before taking the
> termination out of service?
> In what scenarios would the MGC take the termination out of
> service and then
> subtract it from the call explicitly.
>
>      Taking it a bit further, if the MGC sends service change
> with "forced" on
> ROOT termination, should the MG still wait for the contexts
> on all terminations
> to be subtracted explicitly by the MGC before going down?
>
>
>                                          Regards,
>                                          R. Ezhirpavai
>
>
>
>
>
> "Rosen, Brian"  on 05/18/2001 09:07:21 PM
>
> To:   "'Tom-PT Taylor'" , "'Dan Elbert'"
>       , "'megaco@fore.com'" 
> cc:    (bcc: R Ezhirpavai/HSS)
>
> Subject:  RE: Use of ServiceChange from MGC to MG
>
>
>
>
> One thing I think is incorrect here is the "Subtracted from any active
> contexts" part.  I believe we defined the protocol so that this NEVER
> happens
> as a side-effect.  The termination may actually be out of
> service, but both
> the MG and the MGC have it in a context if it was when the
> termination was
> taken out of service.
>
> It is always incumbant on the MGC to do the subtract explicitly.
>
> The ONLY exception to this is restart of the MG; all contexts
> are lost.
>
> Brian
>
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Friday, May 18, 2001 11:32 AM
> To: 'Dan Elbert'; 'megaco@fore.com'
> Subject: RE: Use of ServiceChange from MGC to MG
>
>
>
> Hi.
>
> > -----Original Message-----
> > From: Dan Elbert [ mailto:DElbert@radvision.com
>  ]
> > Sent: Friday, May 18, 2001 11:06 AM
> > To: 'megaco@fore.com'
> > Subject: Use of ServiceChange from MGC to MG
> >
> >
> > Hi
> >
> > The Media Gateway Controller may indicate that Termination(s)
> > shall be taken
> > out of or returned to service.
> > 1. What is the meaning of the MGC taking down a termination ?
> > Does it means
> > that the termination is substracted from any active context
> > and all signal
> > are stopped and no events are detected ?
>
> Yes
>
> > 2. What methods are used for taking the MG down and up ? I'd
> > say Graceful
> > and Restart. Is this OK ?
>
> "Taking the MG down" to me means doing a ServiceChange on
> ROOT at the MG.
> It's possible the MGC might do that to an MG, but most likely
> in that case
> that it would be done under manual control (i.e. the network
> is set up such
> that control of MGs is exercised through the MGC).  I don't
> see this as a
> typical maintence arrangement.
>
> > 3. Is this applicable also to the root termination ? I would
> > say no because
> > if the root termination "goes down" then logically the MG may
> > not be able to
> > receive any more MGC commands.
>
> Upon recovery the MG would follow normal start-up procedures
> to establish a
> new control association.
>
> >
> > Thanks,
> >
> > Dan Elbert
> > RADVISION
> >
>
>
>






From owner-megaco@fore.com  Fri May 18 14:26:33 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10815
	for ; Fri, 18 May 2001 14:26:33 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA15625;
	Fri, 18 May 2001 14:20:08 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA13987
	for megaco-list; Fri, 18 May 2001 14:18:16 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13977
	for ; Fri, 18 May 2001 14:18:14 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA15305
	for ; Fri, 18 May 2001 14:18:07 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACS15987;
	Fri, 18 May 2001 14:17:59 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Rosen, Brian'" , 
Cc: "'Dan Elbert'" , 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Fri, 18 May 2001 14:22:03 -0400
Message-ID: <025a01c0dfc7$7046fbc0$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <4FBEA8857476D311A03300204840E1CF01A6F64B@whq-msgusr-02.pit.comms.marconi.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

There is no mention of this "unregistration" from the MGC in the protocol.
The protocol only address ServiceChange with ROOT termination ID as a means
of MG registering with the MGC but not the other way round. I was in the
impression that it is possible according to the grammar but nothing like
"un-registration" exists. (I'm not sure whether every one has the common
understanding of this "un-registration")

Regards
Madhubabu

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Friday, May 18, 2001 2:04 PM
To: 'Madhu Babu Brahmanapally'; rezhirpavai@hss.hns.com
Cc: 'Dan Elbert'; megaco@fore.com
Subject: RE: Use of ServiceChange from MGC to MG


I think you can - it's an MGC invoked soft boot.

Brian

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Friday, May 18, 2001 1:52 PM
> To: rezhirpavai@hss.hns.com
> Cc: 'Dan Elbert'; megaco@fore.com
> Subject: RE: Use of ServiceChange from MGC to MG
>
>
> HI Pavai,
> I think second point address non-ROOT terminations. I don't
> think the MGC
> can send ServiceChange on ROOT to either bring it down or up.
> (Of course
> there is no restriction from the protocol that MGC cannot
> send ServiceChange
> on ROOT...I think we may need some consensus on this from everyone).
>
> Regards
> Madhubabu
>
> -----Original Message-----
> From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
> Sent: Friday, May 18, 2001 12:55 PM
> To: Madhu Babu Brahmanapally
> Cc: 'Dan Elbert'; megaco@fore.com
> Subject: RE: Use of ServiceChange from MGC to MG
>
>
>
>
> Hello Madhu,
>      In the second point you have mentioned about the methods
> for taking the
> MG
> down as "forced" and restart".  If the MG itself wants to
> indicate about its
> going down, then it can either send "graceful" or "forced",
> but if the MGC
> wants
> to bring down its association with the MG then it needs to
> send service
> change
> on ROOT with "forced". "Restart" from MGC on ROOT termination
> is not valid.
> In
> this case the MG needs to itself send service change to any
> secondary MGC or
> to
> the same primary MGC (if secondary MGC are configured) after restart
> avalance
> timer.
>
>
>                                          Regards,
>                                          R. Ezhirpavai
>
>
>
>
>
> "Madhu Babu Brahmanapally"  on
> 05/18/2001 09:05:16 PM
>
> To:   "'Dan Elbert'" , megaco@fore.com
> cc:    (bcc: R Ezhirpavai/HSS)
>
> Subject:  RE: Use of ServiceChange from MGC to MG
>
>
>
>
> HI Dan,
> Comments below [Madhu]
>
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dan Elbert
> Sent: Friday, May 18, 2001 11:06 AM
> To: 'megaco@fore.com'
> Subject: Use of ServiceChange from MGC to MG
>
>
> Hi
>
> The Media Gateway Controller may indicate that Termination(s)
> shall be taken
> out of or returned to service.
>
> 1. What is the meaning of the MGC taking down a termination ?
> Does it means
> that the termination is substracted from any active context
> and all signal
> are stopped and no events are detected ?
> [Madhu] IMO its similar to the situation where MG generates such
> servicechange.
> The signals to be stopped and no event detection.
> Will be useful in
> 1) Residential Gateway - Where the user profile is not
> encouraging and the
> MGC doesn't
> want to entertain any messages generated from the MG for that
> endpoint.
> 2) Trunking gateway - Remove some of the trunks from the
> initial provisioned
> trunks.
>
> 2. What methods are used for taking the MG down and up ? I'd
> say Graceful
> and Restart. Is this OK ?
> [Madhu] I think Graceful is a mean by which MG can say to MGC
> that this
> particular termination
> shouldn't be used for further calls. Graceful has no meaning when MGC
> generates this. I think the
> methods should be "forced" and "restart".
>
> 3. Is this applicable also to the root termination ? I would
> say no because
> if the root termination "goes down" then logically the MG may
> not be able to
> receive any more MGC commands.
> [Madhu] Yes. Your argument is correct.
>
> Thanks,
>
> Dan Elbert
> RADVISION
>
>
>
>
>



From owner-megaco@fore.com  Fri May 18 14:27:29 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10868
	for ; Fri, 18 May 2001 14:27:28 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA15579;
	Fri, 18 May 2001 14:19:47 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA13407
	for megaco-list; Fri, 18 May 2001 14:16:55 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13385
	for ; Fri, 18 May 2001 14:16:52 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 14:16:17 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F64C@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'rezhirpavai@hss.hns.com'" 
Cc: "'Tom-PT Taylor'" ,
        "'Dan Elbert'"
	 ,
        "'megaco@fore.com'" 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Fri, 18 May 2001 14:16:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This has been discussed before.  The consensus at that time was that
the MGC needed to be able to force terminations out of service
regardless of the context state.  I don't want to force an ordering - it's
better if the MGC goofs and sends the ServiceChange first to actually
take the termination out of service then to not take it out of service and
return an error.

Brian

> -----Original Message-----
> From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
> Sent: Friday, May 18, 2001 1:58 PM
> To: Rosen, Brian
> Cc: 'Tom-PT Taylor'; 'Dan Elbert'; 'megaco@fore.com'
> Subject: RE: Use of ServiceChange from MGC to MG
> 
> 
> 
> 
> Hello Brain,
>      Yes, I was mentioning about the order of operations. 
> IMHO, the protocol
> should enforce the MGC to subtract the termination from 
> context before putting
> it out of service. If the MGC sends the service change for putting the
> termination out of service, while the termination is in 
> context, MG should send
> back an error to the MGC, thus indicating to the MGC that the 
> termination is in
> context and any discripency between the MG and MGC may be resolved.
> 
>                                          Regards,
>                                          R. Ezhirpavai
> 
> 
> 
> 
> 
> "Rosen, Brian"  on 05/18/2001 11:08:30 PM
> 
> To:   R Ezhirpavai/HSS@HSS
> cc:   "'Tom-PT Taylor'" , "'Dan Elbert'"
>       , "'megaco@fore.com'" 
> 
> Subject:  RE: Use of ServiceChange from MGC to MG
> 
> 
> 
> 
> I said that - the MGC does the Subtract explicitly; just
> taking the termination out of service DOES NOT implicitly do
> a Subtract.  If you are arguing about the order of operations,
> I would recommend the Subtract before the ServiceChange.
> 
> The usual drill for the MGC is first to subtract, then serviceChange
> forced.  There really isn't any reason for the MGC to use Graceful.
> 
> The usual drill for the MG is to send Graceful, the MGC responds
> with Subtract, then the MG makes the terminations out of
> service after the subtract or at the latest, after the timeout.
> 
> A forced Restart on Root should happen immediately.
> 
> Brian
> 
> > -----Original Message-----
> > From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
> > Sent: Friday, May 18, 2001 1:13 PM
> > To: Rosen, Brian
> > Cc: 'Tom-PT Taylor'; 'Dan Elbert'; 'megaco@fore.com'
> > Subject: RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> >
> > Hello Brain,
> >      Since the MGC is the controller of the call, shouldn't
> > the MGC explicitly
> > subtract the call from the context before taking the
> > termination out of service?
> > In what scenarios would the MGC take the termination out of
> > service and then
> > subtract it from the call explicitly.
> >
> >      Taking it a bit further, if the MGC sends service change
> > with "forced" on
> > ROOT termination, should the MG still wait for the contexts
> > on all terminations
> > to be subtracted explicitly by the MGC before going down?
> >
> >
> >                                          Regards,
> >                                          R. Ezhirpavai
> >
> >
> >
> >
> >
> > "Rosen, Brian"  on 05/18/2001 09:07:21 PM
> >
> > To:   "'Tom-PT Taylor'" , "'Dan Elbert'"
> >       , "'megaco@fore.com'" 
> > cc:    (bcc: R Ezhirpavai/HSS)
> >
> > Subject:  RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> >
> > One thing I think is incorrect here is the "Subtracted from 
> any active
> > contexts" part.  I believe we defined the protocol so that 
> this NEVER
> > happens
> > as a side-effect.  The termination may actually be out of
> > service, but both
> > the MG and the MGC have it in a context if it was when the
> > termination was
> > taken out of service.
> >
> > It is always incumbant on the MGC to do the subtract explicitly.
> >
> > The ONLY exception to this is restart of the MG; all contexts
> > are lost.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Friday, May 18, 2001 11:32 AM
> > To: 'Dan Elbert'; 'megaco@fore.com'
> > Subject: RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> > Hi.
> >
> > > -----Original Message-----
> > > From: Dan Elbert [ mailto:DElbert@radvision.com
> >  ]
> > > Sent: Friday, May 18, 2001 11:06 AM
> > > To: 'megaco@fore.com'
> > > Subject: Use of ServiceChange from MGC to MG
> > >
> > >
> > > Hi
> > >
> > > The Media Gateway Controller may indicate that Termination(s)
> > > shall be taken
> > > out of or returned to service.
> > > 1. What is the meaning of the MGC taking down a termination ?
> > > Does it means
> > > that the termination is substracted from any active context
> > > and all signal
> > > are stopped and no events are detected ?
> >
> > Yes
> >
> > > 2. What methods are used for taking the MG down and up ? I'd
> > > say Graceful
> > > and Restart. Is this OK ?
> >
> > "Taking the MG down" to me means doing a ServiceChange on
> > ROOT at the MG.
> > It's possible the MGC might do that to an MG, but most likely
> > in that case
> > that it would be done under manual control (i.e. the network
> > is set up such
> > that control of MGs is exercised through the MGC).  I don't
> > see this as a
> > typical maintence arrangement.
> >
> > > 3. Is this applicable also to the root termination ? I would
> > > say no because
> > > if the root termination "goes down" then logically the MG may
> > > not be able to
> > > receive any more MGC commands.
> >
> > Upon recovery the MG would follow normal start-up procedures
> > to establish a
> > new control association.
> >
> > >
> > > Thanks,
> > >
> > > Dan Elbert
> > > RADVISION
> > >
> >
> >
> >
> 
> 
> 
> 


From owner-megaco@fore.com  Fri May 18 14:36:10 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11242
	for ; Fri, 18 May 2001 14:36:09 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA16478;
	Fri, 18 May 2001 14:26:53 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA15422
	for megaco-list; Fri, 18 May 2001 14:24:27 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA15401
	for ; Fri, 18 May 2001 14:24:24 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 14:23:49 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F64E@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Madhu Babu Brahmanapally'" ,
        rezhirpavai@hss.hns.com
Cc: "'Dan Elbert'" , megaco@fore.com
Subject: RE: Use of ServiceChange from MGC to MG
Date: Fri, 18 May 2001 14:24:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Where do you get "unregistration"?

When sent from MG to MGC SC forced on Root means "I am going down" 
When sent from MGC to MG forced on Root means "go down"

And the corresponding Restart does the obvious thing.

There is an argument that this treads into management interface
territory.

Brian

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Friday, May 18, 2001 2:22 PM
> To: 'Rosen, Brian'; rezhirpavai@hss.hns.com
> Cc: 'Dan Elbert'; megaco@fore.com
> Subject: RE: Use of ServiceChange from MGC to MG
> 
> 
> There is no mention of this "unregistration" from the MGC in 
> the protocol.
> The protocol only address ServiceChange with ROOT termination 
> ID as a means
> of MG registering with the MGC but not the other way round. I 
> was in the
> impression that it is possible according to the grammar but 
> nothing like
> "un-registration" exists. (I'm not sure whether every one has 
> the common
> understanding of this "un-registration")
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Friday, May 18, 2001 2:04 PM
> To: 'Madhu Babu Brahmanapally'; rezhirpavai@hss.hns.com
> Cc: 'Dan Elbert'; megaco@fore.com
> Subject: RE: Use of ServiceChange from MGC to MG
> 
> 
> I think you can - it's an MGC invoked soft boot.
> 
> Brian
> 
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > Sent: Friday, May 18, 2001 1:52 PM
> > To: rezhirpavai@hss.hns.com
> > Cc: 'Dan Elbert'; megaco@fore.com
> > Subject: RE: Use of ServiceChange from MGC to MG
> >
> >
> > HI Pavai,
> > I think second point address non-ROOT terminations. I don't
> > think the MGC
> > can send ServiceChange on ROOT to either bring it down or up.
> > (Of course
> > there is no restriction from the protocol that MGC cannot
> > send ServiceChange
> > on ROOT...I think we may need some consensus on this from everyone).
> >
> > Regards
> > Madhubabu
> >
> > -----Original Message-----
> > From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
> > Sent: Friday, May 18, 2001 12:55 PM
> > To: Madhu Babu Brahmanapally
> > Cc: 'Dan Elbert'; megaco@fore.com
> > Subject: RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> >
> > Hello Madhu,
> >      In the second point you have mentioned about the methods
> > for taking the
> > MG
> > down as "forced" and restart".  If the MG itself wants to
> > indicate about its
> > going down, then it can either send "graceful" or "forced",
> > but if the MGC
> > wants
> > to bring down its association with the MG then it needs to
> > send service
> > change
> > on ROOT with "forced". "Restart" from MGC on ROOT termination
> > is not valid.
> > In
> > this case the MG needs to itself send service change to any
> > secondary MGC or
> > to
> > the same primary MGC (if secondary MGC are configured) after restart
> > avalance
> > timer.
> >
> >
> >                                          Regards,
> >                                          R. Ezhirpavai
> >
> >
> >
> >
> >
> > "Madhu Babu Brahmanapally"  on
> > 05/18/2001 09:05:16 PM
> >
> > To:   "'Dan Elbert'" , megaco@fore.com
> > cc:    (bcc: R Ezhirpavai/HSS)
> >
> > Subject:  RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> >
> > HI Dan,
> > Comments below [Madhu]
> >
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dan Elbert
> > Sent: Friday, May 18, 2001 11:06 AM
> > To: 'megaco@fore.com'
> > Subject: Use of ServiceChange from MGC to MG
> >
> >
> > Hi
> >
> > The Media Gateway Controller may indicate that Termination(s)
> > shall be taken
> > out of or returned to service.
> >
> > 1. What is the meaning of the MGC taking down a termination ?
> > Does it means
> > that the termination is substracted from any active context
> > and all signal
> > are stopped and no events are detected ?
> > [Madhu] IMO its similar to the situation where MG generates such
> > servicechange.
> > The signals to be stopped and no event detection.
> > Will be useful in
> > 1) Residential Gateway - Where the user profile is not
> > encouraging and the
> > MGC doesn't
> > want to entertain any messages generated from the MG for that
> > endpoint.
> > 2) Trunking gateway - Remove some of the trunks from the
> > initial provisioned
> > trunks.
> >
> > 2. What methods are used for taking the MG down and up ? I'd
> > say Graceful
> > and Restart. Is this OK ?
> > [Madhu] I think Graceful is a mean by which MG can say to MGC
> > that this
> > particular termination
> > shouldn't be used for further calls. Graceful has no 
> meaning when MGC
> > generates this. I think the
> > methods should be "forced" and "restart".
> >
> > 3. Is this applicable also to the root termination ? I would
> > say no because
> > if the root termination "goes down" then logically the MG may
> > not be able to
> > receive any more MGC commands.
> > [Madhu] Yes. Your argument is correct.
> >
> > Thanks,
> >
> > Dan Elbert
> > RADVISION
> >
> >
> >
> >
> >
> 


From owner-megaco@fore.com  Fri May 18 14:36:26 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11253
	for ; Fri, 18 May 2001 14:36:25 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA16214;
	Fri, 18 May 2001 14:24:57 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA15181
	for megaco-list; Fri, 18 May 2001 14:23:36 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA15176
	for ; Fri, 18 May 2001 14:23:34 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA16011
	for ; Fri, 18 May 2001 14:23:28 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACS16030;
	Fri, 18 May 2001 14:21:48 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: , "'Rosen, Brian'" 
Cc: "'Tom-PT Taylor'" ,
        "'Dan Elbert'" , 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Fri, 18 May 2001 14:25:51 -0400
Message-ID: <025b01c0dfc7$f83f0720$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <65256A50.00620C85.00@sandesh.hss.hns.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

HI Pavai,
I think the Subtract command is allowed for termination "out-of-service"
also. In effect, the Subtract only should bother whether the termination is
in Context or not. Subtract should not be bothered with the state of the
termination. If you are worried about the clearing of contexts, I think the
protocol already mentioned that this is MGC's responsibility. IMO the order
shouldn't matter and hence need not be enforced by the protocol.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of
rezhirpavai@hss.hns.com
Sent: Friday, May 18, 2001 1:58 PM
To: Rosen, Brian
Cc: 'Tom-PT Taylor'; 'Dan Elbert'; 'megaco@fore.com'
Subject: RE: Use of ServiceChange from MGC to MG




Hello Brain,
     Yes, I was mentioning about the order of operations. IMHO, the protocol
should enforce the MGC to subtract the termination from context before
putting
it out of service. If the MGC sends the service change for putting the
termination out of service, while the termination is in context, MG should
send
back an error to the MGC, thus indicating to the MGC that the termination is
in
context and any discripency between the MG and MGC may be resolved.

                                         Regards,
                                         R. Ezhirpavai





"Rosen, Brian"  on 05/18/2001 11:08:30 PM

To:   R Ezhirpavai/HSS@HSS
cc:   "'Tom-PT Taylor'" , "'Dan Elbert'"
      , "'megaco@fore.com'" 

Subject:  RE: Use of ServiceChange from MGC to MG




I said that - the MGC does the Subtract explicitly; just
taking the termination out of service DOES NOT implicitly do
a Subtract.  If you are arguing about the order of operations,
I would recommend the Subtract before the ServiceChange.

The usual drill for the MGC is first to subtract, then serviceChange
forced.  There really isn't any reason for the MGC to use Graceful.

The usual drill for the MG is to send Graceful, the MGC responds
with Subtract, then the MG makes the terminations out of
service after the subtract or at the latest, after the timeout.

A forced Restart on Root should happen immediately.

Brian

> -----Original Message-----
> From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
> Sent: Friday, May 18, 2001 1:13 PM
> To: Rosen, Brian
> Cc: 'Tom-PT Taylor'; 'Dan Elbert'; 'megaco@fore.com'
> Subject: RE: Use of ServiceChange from MGC to MG
>
>
>
>
> Hello Brain,
>      Since the MGC is the controller of the call, shouldn't
> the MGC explicitly
> subtract the call from the context before taking the
> termination out of service?
> In what scenarios would the MGC take the termination out of
> service and then
> subtract it from the call explicitly.
>
>      Taking it a bit further, if the MGC sends service change
> with "forced" on
> ROOT termination, should the MG still wait for the contexts
> on all terminations
> to be subtracted explicitly by the MGC before going down?
>
>
>                                          Regards,
>                                          R. Ezhirpavai
>
>
>
>
>
> "Rosen, Brian"  on 05/18/2001 09:07:21 PM
>
> To:   "'Tom-PT Taylor'" , "'Dan Elbert'"
>       , "'megaco@fore.com'" 
> cc:    (bcc: R Ezhirpavai/HSS)
>
> Subject:  RE: Use of ServiceChange from MGC to MG
>
>
>
>
> One thing I think is incorrect here is the "Subtracted from any active
> contexts" part.  I believe we defined the protocol so that this NEVER
> happens
> as a side-effect.  The termination may actually be out of
> service, but both
> the MG and the MGC have it in a context if it was when the
> termination was
> taken out of service.
>
> It is always incumbant on the MGC to do the subtract explicitly.
>
> The ONLY exception to this is restart of the MG; all contexts
> are lost.
>
> Brian
>
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Friday, May 18, 2001 11:32 AM
> To: 'Dan Elbert'; 'megaco@fore.com'
> Subject: RE: Use of ServiceChange from MGC to MG
>
>
>
> Hi.
>
> > -----Original Message-----
> > From: Dan Elbert [ mailto:DElbert@radvision.com
>  ]
> > Sent: Friday, May 18, 2001 11:06 AM
> > To: 'megaco@fore.com'
> > Subject: Use of ServiceChange from MGC to MG
> >
> >
> > Hi
> >
> > The Media Gateway Controller may indicate that Termination(s)
> > shall be taken
> > out of or returned to service.
> > 1. What is the meaning of the MGC taking down a termination ?
> > Does it means
> > that the termination is substracted from any active context
> > and all signal
> > are stopped and no events are detected ?
>
> Yes
>
> > 2. What methods are used for taking the MG down and up ? I'd
> > say Graceful
> > and Restart. Is this OK ?
>
> "Taking the MG down" to me means doing a ServiceChange on
> ROOT at the MG.
> It's possible the MGC might do that to an MG, but most likely
> in that case
> that it would be done under manual control (i.e. the network
> is set up such
> that control of MGs is exercised through the MGC).  I don't
> see this as a
> typical maintence arrangement.
>
> > 3. Is this applicable also to the root termination ? I would
> > say no because
> > if the root termination "goes down" then logically the MG may
> > not be able to
> > receive any more MGC commands.
>
> Upon recovery the MG would follow normal start-up procedures
> to establish a
> new control association.
>
> >
> > Thanks,
> >
> > Dan Elbert
> > RADVISION
> >
>
>
>






From owner-megaco@fore.com  Fri May 18 14:43:42 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11553
	for ; Fri, 18 May 2001 14:43:41 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA16835;
	Fri, 18 May 2001 14:29:23 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA16176
	for megaco-list; Fri, 18 May 2001 14:27:48 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA16167
	for ; Fri, 18 May 2001 14:27:46 -0400 (EDT)
Received: from ertpg15e1.nortelnetworks.com (ertpg15e1.nortelnetworks.com [47.234.0.36])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id OAA16580
	for ; Fri, 18 May 2001 14:27:36 -0400 (EDT)
Received: from zrtps06s.us.nortel.com by ertpg15e1.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id OAA29997; Fri, 18 May 2001 14:27:37 -0400
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com;
          Fri, 18 May 2001 14:28:02 -0400
Received: from zrtpd0jn.us.nortel.com ([47.140.202.35]) 
          by zrtpd004.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id LDQVPYLB; Fri, 18 May 2001 14:26:58 -0400
Received: from americasm01.nt.com (kboyle.us.nortel.com [47.142.150.95]) 
          by zrtpd0jn.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id J5XGQ18K; Fri, 18 May 2001 14:26:58 -0400
Message-ID: <3B05692F.4E690613@americasm01.nt.com>
Date: Fri, 18 May 2001 14:25:51 -0400
X-Sybari-Space: 00000000 00000000 00000000
From: "Kevin Boyle" 
Organization: Nortel Networks
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rezhirpavai@hss.hns.com
CC: "Rosen, Brian" ,
        "Tom-PT Taylor" ,
        "'Dan Elbert'" ,
        "'megaco@fore.com'" 
Subject: Re: Use of ServiceChange from MGC to MG
References: <65256A50.00620C85.00@sandesh.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Why?  What benefit is gained by setting this restriction?  Now, I would agree with
the idea that "out of service" also implies "inactive", thereby halting the
information flow on the streams.  However, I don't see any great problem with
allowing the out of service Modify command to precede the Subtract.  The MG is
supposed to leave terminations in context until explicitly subtracted, or the MG
restarts.

Kevin

rezhirpavai@hss.hns.com wrote:

> Hello Brain,
>      Yes, I was mentioning about the order of operations. IMHO, the protocol
> should enforce the MGC to subtract the termination from context before putting
> it out of service. If the MGC sends the service change for putting the
> termination out of service, while the termination is in context, MG should send
> back an error to the MGC, thus indicating to the MGC that the termination is in
> context and any discripency between the MG and MGC may be resolved.
>
>                                          Regards,
>                                          R. Ezhirpavai
>
> "Rosen, Brian"  on 05/18/2001 11:08:30 PM
>
> To:   R Ezhirpavai/HSS@HSS
> cc:   "'Tom-PT Taylor'" , "'Dan Elbert'"
>       , "'megaco@fore.com'" 
>
> Subject:  RE: Use of ServiceChange from MGC to MG
>
> I said that - the MGC does the Subtract explicitly; just
> taking the termination out of service DOES NOT implicitly do
> a Subtract.  If you are arguing about the order of operations,
> I would recommend the Subtract before the ServiceChange.
>
> The usual drill for the MGC is first to subtract, then serviceChange
> forced.  There really isn't any reason for the MGC to use Graceful.
>
> The usual drill for the MG is to send Graceful, the MGC responds
> with Subtract, then the MG makes the terminations out of
> service after the subtract or at the latest, after the timeout.
>
> A forced Restart on Root should happen immediately.
>
> Brian
>
> > -----Original Message-----
> > From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
> > Sent: Friday, May 18, 2001 1:13 PM
> > To: Rosen, Brian
> > Cc: 'Tom-PT Taylor'; 'Dan Elbert'; 'megaco@fore.com'
> > Subject: RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> >
> > Hello Brain,
> >      Since the MGC is the controller of the call, shouldn't
> > the MGC explicitly
> > subtract the call from the context before taking the
> > termination out of service?
> > In what scenarios would the MGC take the termination out of
> > service and then
> > subtract it from the call explicitly.
> >
> >      Taking it a bit further, if the MGC sends service change
> > with "forced" on
> > ROOT termination, should the MG still wait for the contexts
> > on all terminations
> > to be subtracted explicitly by the MGC before going down?
> >
> >
> >                                          Regards,
> >                                          R. Ezhirpavai
> >
> >
> >
> >
> >
> > "Rosen, Brian"  on 05/18/2001 09:07:21 PM
> >
> > To:   "'Tom-PT Taylor'" , "'Dan Elbert'"
> >       , "'megaco@fore.com'" 
> > cc:    (bcc: R Ezhirpavai/HSS)
> >
> > Subject:  RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> >
> > One thing I think is incorrect here is the "Subtracted from any active
> > contexts" part.  I believe we defined the protocol so that this NEVER
> > happens
> > as a side-effect.  The termination may actually be out of
> > service, but both
> > the MG and the MGC have it in a context if it was when the
> > termination was
> > taken out of service.
> >
> > It is always incumbant on the MGC to do the subtract explicitly.
> >
> > The ONLY exception to this is restart of the MG; all contexts
> > are lost.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Friday, May 18, 2001 11:32 AM
> > To: 'Dan Elbert'; 'megaco@fore.com'
> > Subject: RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> > Hi.
> >
> > > -----Original Message-----
> > > From: Dan Elbert [ mailto:DElbert@radvision.com
> >  ]
> > > Sent: Friday, May 18, 2001 11:06 AM
> > > To: 'megaco@fore.com'
> > > Subject: Use of ServiceChange from MGC to MG
> > >
> > >
> > > Hi
> > >
> > > The Media Gateway Controller may indicate that Termination(s)
> > > shall be taken
> > > out of or returned to service.
> > > 1. What is the meaning of the MGC taking down a termination ?
> > > Does it means
> > > that the termination is substracted from any active context
> > > and all signal
> > > are stopped and no events are detected ?
> >
> > Yes
> >
> > > 2. What methods are used for taking the MG down and up ? I'd
> > > say Graceful
> > > and Restart. Is this OK ?
> >
> > "Taking the MG down" to me means doing a ServiceChange on
> > ROOT at the MG.
> > It's possible the MGC might do that to an MG, but most likely
> > in that case
> > that it would be done under manual control (i.e. the network
> > is set up such
> > that control of MGs is exercised through the MGC).  I don't
> > see this as a
> > typical maintence arrangement.
> >
> > > 3. Is this applicable also to the root termination ? I would
> > > say no because
> > > if the root termination "goes down" then logically the MG may
> > > not be able to
> > > receive any more MGC commands.
> >
> > Upon recovery the MG would follow normal start-up procedures
> > to establish a
> > new control association.
> >
> > >
> > > Thanks,
> > >
> > > Dan Elbert
> > > RADVISION
> > >
> >
> >
> >



From owner-megaco@fore.com  Fri May 18 14:43:45 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11563
	for ; Fri, 18 May 2001 14:43:45 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA17689;
	Fri, 18 May 2001 14:37:02 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA18378
	for megaco-list; Fri, 18 May 2001 14:35:34 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA18344
	for ; Fri, 18 May 2001 14:35:29 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA17513
	for ; Fri, 18 May 2001 14:35:21 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACS16969;
	Fri, 18 May 2001 14:35:11 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Rosen, Brian'" , 
Cc: "'Dan Elbert'" , 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Fri, 18 May 2001 14:39:14 -0400
Message-ID: <025d01c0dfc9$d7430c90$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <4FBEA8857476D311A03300204840E1CF01A6F64E@whq-msgusr-02.pit.comms.marconi.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

HI Brian,

The control association between the MG and MGC is established using the
ServiceChange command from the MG with ROOT TerminationId. If the MGC
generates a ServiceChange command on ROOT with method Forced Method doesn't
this mean the breaking of the control association???
As you mentioned if the MG generates the SC forced on ROOT, it does imply
that the MG is going down...and I think it is the END of control association
between the MG and the MGC. The MG can register itself with some other MGC
which can be different from the initial one.

Regards
Madhubabu

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Friday, May 18, 2001 2:24 PM
To: 'Madhu Babu Brahmanapally'; rezhirpavai@hss.hns.com
Cc: 'Dan Elbert'; megaco@fore.com
Subject: RE: Use of ServiceChange from MGC to MG


Where do you get "unregistration"?

When sent from MG to MGC SC forced on Root means "I am going down"
When sent from MGC to MG forced on Root means "go down"

And the corresponding Restart does the obvious thing.

There is an argument that this treads into management interface
territory.

Brian

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Friday, May 18, 2001 2:22 PM
> To: 'Rosen, Brian'; rezhirpavai@hss.hns.com
> Cc: 'Dan Elbert'; megaco@fore.com
> Subject: RE: Use of ServiceChange from MGC to MG
>
>
> There is no mention of this "unregistration" from the MGC in
> the protocol.
> The protocol only address ServiceChange with ROOT termination
> ID as a means
> of MG registering with the MGC but not the other way round. I
> was in the
> impression that it is possible according to the grammar but
> nothing like
> "un-registration" exists. (I'm not sure whether every one has
> the common
> understanding of this "un-registration")
>
> Regards
> Madhubabu
>
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Friday, May 18, 2001 2:04 PM
> To: 'Madhu Babu Brahmanapally'; rezhirpavai@hss.hns.com
> Cc: 'Dan Elbert'; megaco@fore.com
> Subject: RE: Use of ServiceChange from MGC to MG
>
>
> I think you can - it's an MGC invoked soft boot.
>
> Brian
>
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > Sent: Friday, May 18, 2001 1:52 PM
> > To: rezhirpavai@hss.hns.com
> > Cc: 'Dan Elbert'; megaco@fore.com
> > Subject: RE: Use of ServiceChange from MGC to MG
> >
> >
> > HI Pavai,
> > I think second point address non-ROOT terminations. I don't
> > think the MGC
> > can send ServiceChange on ROOT to either bring it down or up.
> > (Of course
> > there is no restriction from the protocol that MGC cannot
> > send ServiceChange
> > on ROOT...I think we may need some consensus on this from everyone).
> >
> > Regards
> > Madhubabu
> >
> > -----Original Message-----
> > From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
> > Sent: Friday, May 18, 2001 12:55 PM
> > To: Madhu Babu Brahmanapally
> > Cc: 'Dan Elbert'; megaco@fore.com
> > Subject: RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> >
> > Hello Madhu,
> >      In the second point you have mentioned about the methods
> > for taking the
> > MG
> > down as "forced" and restart".  If the MG itself wants to
> > indicate about its
> > going down, then it can either send "graceful" or "forced",
> > but if the MGC
> > wants
> > to bring down its association with the MG then it needs to
> > send service
> > change
> > on ROOT with "forced". "Restart" from MGC on ROOT termination
> > is not valid.
> > In
> > this case the MG needs to itself send service change to any
> > secondary MGC or
> > to
> > the same primary MGC (if secondary MGC are configured) after restart
> > avalance
> > timer.
> >
> >
> >                                          Regards,
> >                                          R. Ezhirpavai
> >
> >
> >
> >
> >
> > "Madhu Babu Brahmanapally"  on
> > 05/18/2001 09:05:16 PM
> >
> > To:   "'Dan Elbert'" , megaco@fore.com
> > cc:    (bcc: R Ezhirpavai/HSS)
> >
> > Subject:  RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> >
> > HI Dan,
> > Comments below [Madhu]
> >
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dan Elbert
> > Sent: Friday, May 18, 2001 11:06 AM
> > To: 'megaco@fore.com'
> > Subject: Use of ServiceChange from MGC to MG
> >
> >
> > Hi
> >
> > The Media Gateway Controller may indicate that Termination(s)
> > shall be taken
> > out of or returned to service.
> >
> > 1. What is the meaning of the MGC taking down a termination ?
> > Does it means
> > that the termination is substracted from any active context
> > and all signal
> > are stopped and no events are detected ?
> > [Madhu] IMO its similar to the situation where MG generates such
> > servicechange.
> > The signals to be stopped and no event detection.
> > Will be useful in
> > 1) Residential Gateway - Where the user profile is not
> > encouraging and the
> > MGC doesn't
> > want to entertain any messages generated from the MG for that
> > endpoint.
> > 2) Trunking gateway - Remove some of the trunks from the
> > initial provisioned
> > trunks.
> >
> > 2. What methods are used for taking the MG down and up ? I'd
> > say Graceful
> > and Restart. Is this OK ?
> > [Madhu] I think Graceful is a mean by which MG can say to MGC
> > that this
> > particular termination
> > shouldn't be used for further calls. Graceful has no
> meaning when MGC
> > generates this. I think the
> > methods should be "forced" and "restart".
> >
> > 3. Is this applicable also to the root termination ? I would
> > say no because
> > if the root termination "goes down" then logically the MG may
> > not be able to
> > receive any more MGC commands.
> > [Madhu] Yes. Your argument is correct.
> >
> > Thanks,
> >
> > Dan Elbert
> > RADVISION
> >
> >
> >
> >
> >
>



From owner-megaco@fore.com  Fri May 18 14:43:56 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11577
	for ; Fri, 18 May 2001 14:43:56 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA17299;
	Fri, 18 May 2001 14:33:29 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA17143
	for megaco-list; Fri, 18 May 2001 14:31:26 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA17125
	for ; Fri, 18 May 2001 14:31:19 -0400 (EDT)
Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA17035
	for ; Fri, 18 May 2001 14:31:12 -0400 (EDT)
Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203])
	by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.39 2001/05/18 00:47:02 root Exp $) with SMTP id SAA09816;
	Fri, 18 May 2001 18:31:08 GMT
Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 18 May 2001 18:31:00 0000 (GMT)
Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 18 May 2001 11:30:56 -0700
Message-ID: 
From: "Tulpule, Naren" 
To: "'Rosen, Brian'" ,
        MEGACO list
	 
Subject: RE: SDP and ';' comments
Date: Fri, 18 May 2001 11:30:51 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0DFC8.AAB9CB10"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0DFC8.AAB9CB10
Content-Type: text/plain;
	charset="ISO-8859-1"

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]

A line that starts with "}" after a well formed line in SDP is an error.
So would be a line that started with ==.
 
Either you find the matching "}" in the Megaco parser, and pass the body to
the SDP parser, or you change the SDP parser to stop on the "}" and invoke
it
in-line.  Adding a == wouldn't change that except for not having to back up
the scanner on the }.  I don't want to change the protocol to add the "==".
 
[NAREN] Hi Brian, 
  you are right about "==" not adding any value even if it replaces "}" as
far as the SDP parser is concerned. It doesn't matter where the SDP parser
is called from, (1) inline by Megaco parser or (2) seperately after Megaco
parser gathers the SDP octetstring. RBRKT will serve just as well, as a
delimiter.
My confusion was, when does Megaco parser stop collecting the octetstring? 
Megaco says - when you see a "}" which is not preceded by a "\" (backslash).
Megaco parser should replace all "\}" in SDP string with "}" while decoding
and replace all "}" with "\}" while encoding SDP in Megaco messages. This is
a simpler rule but adds more processing (not to mention the fact SDP strings
cannot be passed directly to another protocol because Megaco has changed
them).
I'd say - this is unnecessary - For case (2) Megaco parser should stop
collecting the SDP string on seeing a line which cannot be the beginning of
an SDP line (again, doesn't matter if it is "==" or LWSP "}"). No
substitution of "}" by "\}" or vice versa is necessary in any case. For case
(1) SDP parser should terminate if it sees the Megaco delimiter instead of a
valid beginning of SDP line. This delimiter as defined by the Megaco ABNF is
(LWSP "}") (part of RBRKT). 
So, let us remove the requirement of substituting "}" by "\}". 
Do you agree?


------_=_NextPart_001_01C0DFC8.AAB9CB10
Content-Type: text/html;
	charset="ISO-8859-1"




RE: SDP and ';' comments





  
-----Original Message-----
From: Rosen, Brian 
  [mailto:Brian.Rosen@marconi.com]

  
A line that 
  starts with "}" after a well formed line in SDP is an 
  error.

  
So would be 
  a line that started with ==.

  
 

  
Either you 
  find the matching "}" in the Megaco parser, and pass the body 
  to

  
the SDP 
  parser, or you change the SDP parser to stop on the "}" and invoke 
  it

  
in-line.  Adding a == wouldn't change 
  that except for not having to back up

  
the scanner 
  on the }.  I don't want to change the protocol to add the 
  "==".

  
 

  
[NAREN] Hi Brian, 
  

  
  you are right 
  about "==" not adding any value even if it replaces "}" as far as the SDP 
  parser is concerned. It doesn't matter where the SDP parser is called from, 
  (1) inline by Megaco parser or (2) seperately after Megaco parser gathers the 
  SDP octetstring. RBRKT will serve just as well, as a 
  delimiter.

  
My confusion was, when 
  does Megaco parser stop collecting the octetstring? 

  
Megaco says - when you 
  see a "}" which is not preceded by a "\" (backslash). Megaco 
  parser should replace all "\}" in SDP string with "}" while decoding and 
  replace all "}" with "\}" while encoding SDP in Megaco messages. This is a 
  simpler rule but adds more processing (not to mention the fact SDP strings 
  cannot be passed directly to another protocol because Megaco has changed 
  them).

  
I'd say - this is 
  unnecessary - For case (2) Megaco parser should stop collecting the SDP string 
  on seeing a line which cannot be the beginning of an SDP line (again, doesn't 
  matter if it is "==" or LWSP "}"). No substitution of "}" by "\}" or vice 
  versa is necessary in any case. For case (1) SDP parser should terminate if it 
  sees the Megaco delimiter instead of a valid beginning of SDP line. This 
  delimiter as defined by the Megaco ABNF is (LWSP "}") (part of RBRKT). 
  

  
So, let us remove the 
  requirement of substituting "}" by "\}". 

  
Do you 
  agree?


------_=_NextPart_001_01C0DFC8.AAB9CB10--



From owner-megaco@fore.com  Fri May 18 15:12:22 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12441
	for ; Fri, 18 May 2001 15:12:22 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA20331;
	Fri, 18 May 2001 15:03:50 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA28019
	for megaco-list; Fri, 18 May 2001 15:02:46 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA27697
	for ; Fri, 18 May 2001 15:01:55 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA20037
	for ; Fri, 18 May 2001 15:01:49 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IJ1p226738
	for ; Fri, 18 May 2001 15:01:51 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IJ1po26728
	for ; Fri, 18 May 2001 15:01:51 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA23163; Fri, 18 May 2001 15:01:48 -0400 (EDT)
Cc: "'Rosen, Brian'" ,
        "'knayar@hss.hns.com'" , megaco@fore.com
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA23144; Fri, 18 May 2001 15:01:46 -0400 (EDT)
Message-ID: <3B057124.EB693805@lucent.com>
Date: Fri, 18 May 2001 14:59:48 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Dave Sclarsky 
Original-CC: "'Rosen, Brian'" ,
        "'knayar@hss.hns.com'" , megaco@fore.com
Subject: Re: Polls of MGC
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


If the MGC doesn't have the capability to save *SOME* information 
about the ResGW, like the mapping between it's IP address and 
Johnie's Dad's phone number, it will never work.

Given the capability to save this information, what information
can't it save?  What doesn't it know when it reboots?  Just
the port number?  Why not keep it simple and make it know
that too?

-troy


Polling is bad.
The traffic it causes is bad.
The logic of using it to solve this problem is bad.
It is bad enough to make people look for other protocols.



Dave Sclarsky wrote:
> 
> Brian,
> We cannot let the MGs wait until they need to send something before learning
> that an MGC went down.  You could have a ResGW disconnected from the network
> all night!  What if Johnny at college needs to call home at 3am to bail him
> out of jail?  Dad's controlling MGC won't be able to make his phone ring
> because Dad hasn't made a call since the MGC restarted!  I guess if you're
> Johnny's dad this is a good thing :-)
> 
> DaveS.
> 
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Friday, May 18, 2001 11:22 AM
> To: 'Troy Cauble'
> Cc: 'knayar@hss.hns.com'; megaco@fore.com
> Subject: RE: Polls of MGC
> 
> Y'know, I've asked myself that.  I'm not sure I'd use it IFF
> the whole process of finding an MGC and getting back up was fast
> enough to not cause problems with subscribers.
> 
> My conclusion is that it COULD take a long time, and thus I think
> finding it out sooner is better.  I don't feel so strongly that
> I think we just GOTTA change the protocol.
> 
> Brian
> 
> > -----Original Message-----
> > From: Troy Cauble [mailto:troy@lucent.com]
> > Sent: Friday, May 18, 2001 11:15 AM
> > To: Rosen, Brian
> > Cc: 'knayar@hss.hns.com'; megaco@fore.com
> > Subject: Re: Polls of MGC
> >
> >
> > "Rosen, Brian" wrote:
> > >
> > > This discussion is not specifically detecting failure of the
> > > MGC by timeout of response to a message.  It has to do with
> > > detecting failure of the MGC when there is no message flow.
> >
> > Brian,
> >
> > I think the question is why do we *NEED* to detect failure
> > when there is no message flow?  Why not wait and detect it
> > when the MG tries to send something?  (From the MGs view,
> > nothing has failed yet!)
> >
> > -troy
> >


From owner-megaco@fore.com  Fri May 18 15:14:15 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12570
	for ; Fri, 18 May 2001 15:14:14 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA19336;
	Fri, 18 May 2001 14:57:04 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA24722
	for megaco-list; Fri, 18 May 2001 14:55:00 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA24700
	for ; Fri, 18 May 2001 14:54:57 -0400 (EDT)
From: rezhirpavai@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA19075
	for ; Fri, 18 May 2001 14:54:49 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4IIsAI26844;
	Sat, 19 May 2001 00:24:10 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A50.00665F20 ; Sat, 19 May 2001 00:08:10 +0530
X-Lotus-FromDomain: HSS
To: "Kevin Boyle" 
cc: "Rosen, Brian" ,
        "Tom-PT Taylor" ,
        "'Dan Elbert'" ,
        "'megaco@fore.com'" 
Message-ID: <65256A50.00665D45.00@sandesh.hss.hns.com>
Date: Sat, 19 May 2001 00:15:42 +0530
Subject: Re: Use of ServiceChange from MGC to MG
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk



Hello,
     Consider that due to a discripency the MG still has the "termA" in context
and the MGC assumes that the termA is in NULL context. In this case the MGC
would send service change with forced and would not send any subtract, but MG is
still waiting for the call to terminate.

     By indicating that the MG should not remove it from context till it
receives a subtract, does it not imply that the MG should not stop the media
flow too?

                                         Regards,
                                         R. Ezhirpavai





"Kevin Boyle"  on 05/18/2001 11:55:51 PM

To:   R Ezhirpavai/HSS@HSS
cc:   "Rosen, Brian" , "Tom-PT Taylor"
      , "'Dan Elbert'" ,
      "'megaco@fore.com'" 

Subject:  Re: Use of ServiceChange from MGC to MG




Why?  What benefit is gained by setting this restriction?  Now, I would agree
with
the idea that "out of service" also implies "inactive", thereby halting the
information flow on the streams.  However, I don't see any great problem with
allowing the out of service Modify command to precede the Subtract.  The MG is
supposed to leave terminations in context until explicitly subtracted, or the MG
restarts.

Kevin

rezhirpavai@hss.hns.com wrote:

> Hello Brain,
>      Yes, I was mentioning about the order of operations. IMHO, the protocol
> should enforce the MGC to subtract the termination from context before putting
> it out of service. If the MGC sends the service change for putting the
> termination out of service, while the termination is in context, MG should
send
> back an error to the MGC, thus indicating to the MGC that the termination is
in
> context and any discripency between the MG and MGC may be resolved.
>
>                                          Regards,
>                                          R. Ezhirpavai
>
> "Rosen, Brian"  on 05/18/2001 11:08:30 PM
>
> To:   R Ezhirpavai/HSS@HSS
> cc:   "'Tom-PT Taylor'" , "'Dan Elbert'"
>       , "'megaco@fore.com'" 
>
> Subject:  RE: Use of ServiceChange from MGC to MG
>
> I said that - the MGC does the Subtract explicitly; just
> taking the termination out of service DOES NOT implicitly do
> a Subtract.  If you are arguing about the order of operations,
> I would recommend the Subtract before the ServiceChange.
>
> The usual drill for the MGC is first to subtract, then serviceChange
> forced.  There really isn't any reason for the MGC to use Graceful.
>
> The usual drill for the MG is to send Graceful, the MGC responds
> with Subtract, then the MG makes the terminations out of
> service after the subtract or at the latest, after the timeout.
>
> A forced Restart on Root should happen immediately.
>
> Brian
>
> > -----Original Message-----
> > From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
> > Sent: Friday, May 18, 2001 1:13 PM
> > To: Rosen, Brian
> > Cc: 'Tom-PT Taylor'; 'Dan Elbert'; 'megaco@fore.com'
> > Subject: RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> >
> > Hello Brain,
> >      Since the MGC is the controller of the call, shouldn't
> > the MGC explicitly
> > subtract the call from the context before taking the
> > termination out of service?
> > In what scenarios would the MGC take the termination out of
> > service and then
> > subtract it from the call explicitly.
> >
> >      Taking it a bit further, if the MGC sends service change
> > with "forced" on
> > ROOT termination, should the MG still wait for the contexts
> > on all terminations
> > to be subtracted explicitly by the MGC before going down?
> >
> >
> >                                          Regards,
> >                                          R. Ezhirpavai
> >
> >
> >
> >
> >
> > "Rosen, Brian"  on 05/18/2001 09:07:21 PM
> >
> > To:   "'Tom-PT Taylor'" , "'Dan Elbert'"
> >       , "'megaco@fore.com'" 
> > cc:    (bcc: R Ezhirpavai/HSS)
> >
> > Subject:  RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> >
> > One thing I think is incorrect here is the "Subtracted from any active
> > contexts" part.  I believe we defined the protocol so that this NEVER
> > happens
> > as a side-effect.  The termination may actually be out of
> > service, but both
> > the MG and the MGC have it in a context if it was when the
> > termination was
> > taken out of service.
> >
> > It is always incumbant on the MGC to do the subtract explicitly.
> >
> > The ONLY exception to this is restart of the MG; all contexts
> > are lost.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Friday, May 18, 2001 11:32 AM
> > To: 'Dan Elbert'; 'megaco@fore.com'
> > Subject: RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> > Hi.
> >
> > > -----Original Message-----
> > > From: Dan Elbert [ mailto:DElbert@radvision.com
> >  ]
> > > Sent: Friday, May 18, 2001 11:06 AM
> > > To: 'megaco@fore.com'
> > > Subject: Use of ServiceChange from MGC to MG
> > >
> > >
> > > Hi
> > >
> > > The Media Gateway Controller may indicate that Termination(s)
> > > shall be taken
> > > out of or returned to service.
> > > 1. What is the meaning of the MGC taking down a termination ?
> > > Does it means
> > > that the termination is substracted from any active context
> > > and all signal
> > > are stopped and no events are detected ?
> >
> > Yes
> >
> > > 2. What methods are used for taking the MG down and up ? I'd
> > > say Graceful
> > > and Restart. Is this OK ?
> >
> > "Taking the MG down" to me means doing a ServiceChange on
> > ROOT at the MG.
> > It's possible the MGC might do that to an MG, but most likely
> > in that case
> > that it would be done under manual control (i.e. the network
> > is set up such
> > that control of MGs is exercised through the MGC).  I don't
> > see this as a
> > typical maintence arrangement.
> >
> > > 3. Is this applicable also to the root termination ? I would
> > > say no because
> > > if the root termination "goes down" then logically the MG may
> > > not be able to
> > > receive any more MGC commands.
> >
> > Upon recovery the MG would follow normal start-up procedures
> > to establish a
> > new control association.
> >
> > >
> > > Thanks,
> > >
> > > Dan Elbert
> > > RADVISION
> > >
> >
> >
> >







From owner-megaco@fore.com  Fri May 18 15:14:40 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12587
	for ; Fri, 18 May 2001 15:14:40 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA20724;
	Fri, 18 May 2001 15:07:00 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA28780
	for megaco-list; Fri, 18 May 2001 15:05:22 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA28771
	for ; Fri, 18 May 2001 15:05:20 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA20507
	for ; Fri, 18 May 2001 15:05:14 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IJ5G229217
	for ; Fri, 18 May 2001 15:05:16 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IJ5Go29199
	for ; Fri, 18 May 2001 15:05:16 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA23319; Fri, 18 May 2001 15:05:13 -0400 (EDT)
Cc: "'Dave Sclarsky'" ,
        "'knayar@hss.hns.com'" , megaco@fore.com
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA23300; Fri, 18 May 2001 15:05:11 -0400 (EDT)
Message-ID: <3B0571F2.946191D8@lucent.com>
Date: Fri, 18 May 2001 15:03:14 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" 
Original-CC: "'Dave Sclarsky'" ,
        "'knayar@hss.hns.com'" , megaco@fore.com
Subject: Re: Polls of MGC
References: <4FBEA8857476D311A03300204840E1CF01A6F646@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Rosen, Brian" wrote:
> 
> Right.  I just replied to another version of this and forgot the
> point that Johnnies MGC will figure out that Dad's MGC is down,
> and that can be fixed, but Dad's MG won't register with the
> replacement MGC because it doesn't know (yet) to do so.

What doesn't the replacement MGC know?  Why doesn't it know it?
Let's make it remember!  Requiring the MG to register with the
new MGC is the problem.


> See that message for options.  The package will work, I think,
> pretty well (modulo the worry about signals).  So will the
> profile defined no-op SC method, and declaring restart of an
> up termination to be a no-op.  It occurs to me that we could
> make this more palateable by saying a gracefull restart of an
> up termination with a time of -1 was defined to be a no-op.
> 
> Brian


-troy

Polling is bad.
The traffic it causes is bad.
The logic of using it to solve this problem is bad.
It is bad enough to make people look for other protocols.


From owner-megaco@fore.com  Fri May 18 15:16:26 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12708
	for ; Fri, 18 May 2001 15:16:26 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA19661;
	Fri, 18 May 2001 14:58:54 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA24871
	for megaco-list; Fri, 18 May 2001 14:56:27 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA24840
	for ; Fri, 18 May 2001 14:55:17 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA19138
	for ; Fri, 18 May 2001 14:55:11 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IItD221009
	for ; Fri, 18 May 2001 14:55:13 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IItCo20998
	for ; Fri, 18 May 2001 14:55:12 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id OAA22929; Fri, 18 May 2001 14:55:10 -0400 (EDT)
Cc: megaco@fore.com
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id OAA22916; Fri, 18 May 2001 14:55:09 -0400 (EDT)
Message-ID: <3B056F97.6B684C0@lucent.com>
Date: Fri, 18 May 2001 14:53:11 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Long 
Original-CC: megaco@fore.com
Subject: Re: Polls of MGC
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Paul Long wrote:
> 
> Troy,
> 
> I was leaning towards the no-polling camp, but then I thought about a
> situation that hasn't been mentioned yet. We could just wait until the
> subscriber attempts to place a call to find an available MGC, but what about
> incoming calls? If the MGC is down, that subscriber cannot be reached until
> after he or she attempts to place a call. For that reason alone, I think we
> need a MG-to-MGC polling mechanism.
> 
> Paul Long
> ipDialog, Inc.

Paul,

*Why* can't that subscriber be reached?  What doesn't the backup MGC know?
Dan just pointed out to me the only hole I see:  the port number.

Reverse polling and notification is not the way to fix that.
Make it known to the MGC, via a "default or configurable" statement
in the docs.  The MGC knew the IP address right?  That would be 
shared with the backup MGC right?  Why wouldn't the port number 
be the same?

You guys don't have some vision of COMPLETE discovery and re-discovery
do you?

	Discovery of capabilities is nice.  But in the real world an
	MGC will have to be at least minimally configured for MGs.  
	Even if an MGC can find out that a box at IP address X is an 
	Y profile RG, or an Z profile TG, it'll have to be told some 
	details like what phone numbers map into an RG.  

	Even if it doesn't map to the outside world like an RG's phone 
	numbers, there are issues of trust.  Consider an announcement 
	server that does a standard package of announcements.  I would 
	expect an MGC to only use ones it's been told are OK, instead 
	of any one that signs up.  Otherwise it's a hack waiting to 
	happen -- "alternative" announcements.

Make the port number known the the MGC.


Polling is bad.
The traffic it causes is bad.
The logic of using it to solve this problem is bad.
It is bad enough to make people look for other protocols.


-troy


P.S.  I don't send e-mail to everyone I know once a minute
so I will know in advance if their e-mail is broken.

 

> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Troy Cauble
> Sent: Friday, May 18, 2001 10:40 AM
> To: Rosen, Brian
> Cc: 'knayar@hss.hns.com'; megaco@fore.com
> Subject: Re: Polls of MGC
> 
> "Rosen, Brian" wrote:
> >
> > Y'know, I've asked myself that.  I'm not sure I'd use it IFF
> > the whole process of finding an MGC and getting back up was fast
> > enough to not cause problems with subscribers.
> 
> I haven't followed this thread enough to know if the "process"
> is even known yet.  (I mostly obsess on the parsing issues.)
> 
> I think the MGCP/NCS use of DNS is fairly good, but I doubt
> the timer & count values are such that, for example, it's not
> visible to a user in a residential gateway situation.
> 
> But MGC failure will be a non-frequent event, so I think
> that some small amount of recovery time is OK and better than
> the alternative of polling.
> 
> > My conclusion is that it COULD take a long time, and thus I think
> > finding it out sooner is better.  I don't feel so strongly that
> > I think we just GOTTA change the protocol.
> 
> In terms of the "process" being fast:  How fast is it
> going to be for the MGs that need to get through to a new MGC
> because they're trying to put a call though, when 2000 MGs with
> no immediate beat them to it because of their polling cycle.
> 
> I think that polling is a bad idea in either direction.
> 
> -troy


From owner-megaco@fore.com  Fri May 18 15:20:18 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12803
	for ; Fri, 18 May 2001 15:20:17 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA21121;
	Fri, 18 May 2001 15:09:30 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA29300
	for megaco-list; Fri, 18 May 2001 15:07:22 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA29277
	for ; Fri, 18 May 2001 15:07:11 -0400 (EDT)
Received: from slink12.ss7-link.com (mail.ss7-link.com [209.204.106.218])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA20735
	for ; Fri, 18 May 2001 15:07:04 -0400 (EDT)
Received: by SLINK12 with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 15:07:06 -0400
Message-ID: 
From: Dave Sclarsky 
To: "'Troy Cauble'" ,
        Dave Sclarsky
	 
Cc: "'Rosen, Brian'" ,
        "'knayar@hss.hns.com'"
	 , megaco@fore.com
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 15:07:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Troy,

It doesn't matter what the new (or restarted) MGC knows or doesn't know.
Megaco defines that the control association between MG and MGC is ALWAYS
initiated by the MG.  Given that definition, Johnny's Dad's MG won't be
reachable by a new (or a restarted) MGC until the his MG notices the
failure.  We must define a way for it to know ASAP!

DaveS.

-----Original Message-----
From: Troy Cauble [mailto:troy@lucent.com]
Sent: Friday, May 18, 2001 3:00 PM
To: Dave Sclarsky
Cc: 'Rosen, Brian'; 'knayar@hss.hns.com'; megaco@fore.com
Subject: Re: Polls of MGC



If the MGC doesn't have the capability to save *SOME* information 
about the ResGW, like the mapping between it's IP address and 
Johnie's Dad's phone number, it will never work.

Given the capability to save this information, what information
can't it save?  What doesn't it know when it reboots?  Just
the port number?  Why not keep it simple and make it know
that too?

-troy


Polling is bad.
The traffic it causes is bad.
The logic of using it to solve this problem is bad.
It is bad enough to make people look for other protocols.



Dave Sclarsky wrote:
> 
> Brian,
> We cannot let the MGs wait until they need to send something before
learning
> that an MGC went down.  You could have a ResGW disconnected from the
network
> all night!  What if Johnny at college needs to call home at 3am to bail
him
> out of jail?  Dad's controlling MGC won't be able to make his phone ring
> because Dad hasn't made a call since the MGC restarted!  I guess if you're
> Johnny's dad this is a good thing :-)
> 
> DaveS.
> 
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Friday, May 18, 2001 11:22 AM
> To: 'Troy Cauble'
> Cc: 'knayar@hss.hns.com'; megaco@fore.com
> Subject: RE: Polls of MGC
> 
> Y'know, I've asked myself that.  I'm not sure I'd use it IFF
> the whole process of finding an MGC and getting back up was fast
> enough to not cause problems with subscribers.
> 
> My conclusion is that it COULD take a long time, and thus I think
> finding it out sooner is better.  I don't feel so strongly that
> I think we just GOTTA change the protocol.
> 
> Brian
> 
> > -----Original Message-----
> > From: Troy Cauble [mailto:troy@lucent.com]
> > Sent: Friday, May 18, 2001 11:15 AM
> > To: Rosen, Brian
> > Cc: 'knayar@hss.hns.com'; megaco@fore.com
> > Subject: Re: Polls of MGC
> >
> >
> > "Rosen, Brian" wrote:
> > >
> > > This discussion is not specifically detecting failure of the
> > > MGC by timeout of response to a message.  It has to do with
> > > detecting failure of the MGC when there is no message flow.
> >
> > Brian,
> >
> > I think the question is why do we *NEED* to detect failure
> > when there is no message flow?  Why not wait and detect it
> > when the MG tries to send something?  (From the MGs view,
> > nothing has failed yet!)
> >
> > -troy
> >


From owner-megaco@fore.com  Fri May 18 15:22:26 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12932
	for ; Fri, 18 May 2001 15:22:25 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14422;
	Fri, 18 May 2001 14:10:52 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA11006
	for megaco-list; Fri, 18 May 2001 14:06:59 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA10991
	for ; Fri, 18 May 2001 14:06:57 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13805
	for ; Fri, 18 May 2001 14:06:50 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4II6ndQ018586
	for ; Fri, 18 May 2001 13:06:50 -0500 (CDT)
From: "Paul Long" 
To: 
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 13:06:51 -0500
Message-ID: 
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: <0D5BBF5D638DD4119E3400508BD94945811101@RADVPOST>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dan,

The unanimous opinion on the recent "From whence they came?" thread was that
the mID is just a logical identifier and that even when in the IP-address
form it is not necessarilly the IP address from which the message was sent
or--more importantly--to which a reply should be sent. Look through the
spec, and you'll see that, other than the proposed passage to which I
referred in the IG, the mID is never used as an address but only as an
identifier. There are very good reasons why we should never signal addresses
within the Megaco protocol itself.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dan Elbert
Sent: Friday, May 18, 2001 12:28 PM
To: megaco@fore.com
Subject: RE: Polls of MGC


I thought that by source transport address it was meant the IP address and
port where the message actually came from. Am I wrong ? Is this the address
in the message header ?

Dan



From owner-megaco@fore.com  Fri May 18 15:23:23 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12970
	for ; Fri, 18 May 2001 15:23:23 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA21103;
	Fri, 18 May 2001 15:09:24 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA29310
	for megaco-list; Fri, 18 May 2001 15:07:22 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA29091
	for ; Fri, 18 May 2001 15:07:13 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 15:06:14 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F64F@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Troy Cauble'" , Paul Long 
Cc: megaco@fore.com
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 15:06:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

There is no way for the alternate MGC to take over control
of the MGs.  That is a design decision, and we made it because
of security concerns ("Hello, I'm your new boss, don't worry
about a thing")

Whether you know about port numbers or not, another MGC cannot
break into an existing control association.  There are ways that
you can build redundant MGCs that can do a takeover where the
MG is unaware of the takeover.  That is not the circumstance we
are discussing.

That means the MG is the one that discovers the MGC is dead, and
it needs a way to do that.  

Brian

> -----Original Message-----
> From: Troy Cauble [mailto:troy@lucent.com]
> Sent: Friday, May 18, 2001 2:53 PM
> To: Paul Long
> Cc: megaco@fore.com
> Subject: Re: Polls of MGC
> 
> 
> Paul Long wrote:
> > 
> > Troy,
> > 
> > I was leaning towards the no-polling camp, but then I 
> thought about a
> > situation that hasn't been mentioned yet. We could just 
> wait until the
> > subscriber attempts to place a call to find an available 
> MGC, but what about
> > incoming calls? If the MGC is down, that subscriber cannot 
> be reached until
> > after he or she attempts to place a call. For that reason 
> alone, I think we
> > need a MG-to-MGC polling mechanism.
> > 
> > Paul Long
> > ipDialog, Inc.
> 
> Paul,
> 
> *Why* can't that subscriber be reached?  What doesn't the 
> backup MGC know?
> Dan just pointed out to me the only hole I see:  the port number.
> 
> Reverse polling and notification is not the way to fix that.
> Make it known to the MGC, via a "default or configurable" statement
> in the docs.  The MGC knew the IP address right?  That would be 
> shared with the backup MGC right?  Why wouldn't the port number 
> be the same?
> 
> You guys don't have some vision of COMPLETE discovery and re-discovery
> do you?
> 
> 	Discovery of capabilities is nice.  But in the real world an
> 	MGC will have to be at least minimally configured for MGs.  
> 	Even if an MGC can find out that a box at IP address X is an 
> 	Y profile RG, or an Z profile TG, it'll have to be told some 
> 	details like what phone numbers map into an RG.  
> 
> 	Even if it doesn't map to the outside world like an RG's phone 
> 	numbers, there are issues of trust.  Consider an announcement 
> 	server that does a standard package of announcements.  I would 
> 	expect an MGC to only use ones it's been told are OK, instead 
> 	of any one that signs up.  Otherwise it's a hack waiting to 
> 	happen -- "alternative" announcements.
> 
> Make the port number known the the MGC.
> 
> 
> Polling is bad.
> The traffic it causes is bad.
> The logic of using it to solve this problem is bad.
> It is bad enough to make people look for other protocols.
> 
> 
> -troy
> 
> 
> P.S.  I don't send e-mail to everyone I know once a minute
> so I will know in advance if their e-mail is broken.
> 
>  
> 
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Troy Cauble
> > Sent: Friday, May 18, 2001 10:40 AM
> > To: Rosen, Brian
> > Cc: 'knayar@hss.hns.com'; megaco@fore.com
> > Subject: Re: Polls of MGC
> > 
> > "Rosen, Brian" wrote:
> > >
> > > Y'know, I've asked myself that.  I'm not sure I'd use it IFF
> > > the whole process of finding an MGC and getting back up was fast
> > > enough to not cause problems with subscribers.
> > 
> > I haven't followed this thread enough to know if the "process"
> > is even known yet.  (I mostly obsess on the parsing issues.)
> > 
> > I think the MGCP/NCS use of DNS is fairly good, but I doubt
> > the timer & count values are such that, for example, it's not
> > visible to a user in a residential gateway situation.
> > 
> > But MGC failure will be a non-frequent event, so I think
> > that some small amount of recovery time is OK and better than
> > the alternative of polling.
> > 
> > > My conclusion is that it COULD take a long time, and thus I think
> > > finding it out sooner is better.  I don't feel so strongly that
> > > I think we just GOTTA change the protocol.
> > 
> > In terms of the "process" being fast:  How fast is it
> > going to be for the MGs that need to get through to a new MGC
> > because they're trying to put a call though, when 2000 MGs with
> > no immediate beat them to it because of their polling cycle.
> > 
> > I think that polling is a bad idea in either direction.
> > 
> > -troy
> 


From owner-megaco@fore.com  Fri May 18 15:24:45 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13027
	for ; Fri, 18 May 2001 15:24:45 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA21973;
	Fri, 18 May 2001 15:15:53 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA00860
	for megaco-list; Fri, 18 May 2001 15:14:09 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA00851
	for ; Fri, 18 May 2001 15:14:07 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA21650
	for ; Fri, 18 May 2001 15:14:01 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACS18675;
	Fri, 18 May 2001 15:13:46 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: , "'Kevin Boyle'" 
Cc: "'Rosen, Brian'" ,
        "'Tom-PT Taylor'" ,
        "'Dan Elbert'" , 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Fri, 18 May 2001 15:17:49 -0400
Message-ID: <026501c0dfcf$3b1eea40$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <65256A50.00665D45.00@sandesh.hss.hns.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

HI Pavai,
The media flows also will stop when the ServiceChange is received by the MG
to put that termination out-of-service. Hence the question of the Endpoint
being in call is ruled-out. Second if the MGC is generating service change
for the termination that is in Active context, then it has to generate
Subtract also. If it doesn't there is a potential problem with the MGC
implementation.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of
rezhirpavai@hss.hns.com
Sent: Friday, May 18, 2001 2:46 PM
To: Kevin Boyle
Cc: Rosen, Brian; Tom-PT Taylor; 'Dan Elbert'; 'megaco@fore.com'
Subject: Re: Use of ServiceChange from MGC to MG




Hello,
     Consider that due to a discripency the MG still has the "termA" in
context
and the MGC assumes that the termA is in NULL context. In this case the MGC
would send service change with forced and would not send any subtract, but
MG is
still waiting for the call to terminate.

     By indicating that the MG should not remove it from context till it
receives a subtract, does it not imply that the MG should not stop the media
flow too?

                                         Regards,
                                         R. Ezhirpavai





"Kevin Boyle"  on 05/18/2001 11:55:51 PM

To:   R Ezhirpavai/HSS@HSS
cc:   "Rosen, Brian" , "Tom-PT Taylor"
      , "'Dan Elbert'" ,
      "'megaco@fore.com'" 

Subject:  Re: Use of ServiceChange from MGC to MG




Why?  What benefit is gained by setting this restriction?  Now, I would
agree
with
the idea that "out of service" also implies "inactive", thereby halting the
information flow on the streams.  However, I don't see any great problem
with
allowing the out of service Modify command to precede the Subtract.  The MG
is
supposed to leave terminations in context until explicitly subtracted, or
the MG
restarts.

Kevin

rezhirpavai@hss.hns.com wrote:

> Hello Brain,
>      Yes, I was mentioning about the order of operations. IMHO, the
protocol
> should enforce the MGC to subtract the termination from context before
putting
> it out of service. If the MGC sends the service change for putting the
> termination out of service, while the termination is in context, MG should
send
> back an error to the MGC, thus indicating to the MGC that the termination
is
in
> context and any discripency between the MG and MGC may be resolved.
>
>                                          Regards,
>                                          R. Ezhirpavai
>
> "Rosen, Brian"  on 05/18/2001 11:08:30 PM
>
> To:   R Ezhirpavai/HSS@HSS
> cc:   "'Tom-PT Taylor'" , "'Dan Elbert'"
>       , "'megaco@fore.com'" 
>
> Subject:  RE: Use of ServiceChange from MGC to MG
>
> I said that - the MGC does the Subtract explicitly; just
> taking the termination out of service DOES NOT implicitly do
> a Subtract.  If you are arguing about the order of operations,
> I would recommend the Subtract before the ServiceChange.
>
> The usual drill for the MGC is first to subtract, then serviceChange
> forced.  There really isn't any reason for the MGC to use Graceful.
>
> The usual drill for the MG is to send Graceful, the MGC responds
> with Subtract, then the MG makes the terminations out of
> service after the subtract or at the latest, after the timeout.
>
> A forced Restart on Root should happen immediately.
>
> Brian
>
> > -----Original Message-----
> > From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
> > Sent: Friday, May 18, 2001 1:13 PM
> > To: Rosen, Brian
> > Cc: 'Tom-PT Taylor'; 'Dan Elbert'; 'megaco@fore.com'
> > Subject: RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> >
> > Hello Brain,
> >      Since the MGC is the controller of the call, shouldn't
> > the MGC explicitly
> > subtract the call from the context before taking the
> > termination out of service?
> > In what scenarios would the MGC take the termination out of
> > service and then
> > subtract it from the call explicitly.
> >
> >      Taking it a bit further, if the MGC sends service change
> > with "forced" on
> > ROOT termination, should the MG still wait for the contexts
> > on all terminations
> > to be subtracted explicitly by the MGC before going down?
> >
> >
> >                                          Regards,
> >                                          R. Ezhirpavai
> >
> >
> >
> >
> >
> > "Rosen, Brian"  on 05/18/2001 09:07:21 PM
> >
> > To:   "'Tom-PT Taylor'" , "'Dan Elbert'"
> >       , "'megaco@fore.com'" 
> > cc:    (bcc: R Ezhirpavai/HSS)
> >
> > Subject:  RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> >
> > One thing I think is incorrect here is the "Subtracted from any active
> > contexts" part.  I believe we defined the protocol so that this NEVER
> > happens
> > as a side-effect.  The termination may actually be out of
> > service, but both
> > the MG and the MGC have it in a context if it was when the
> > termination was
> > taken out of service.
> >
> > It is always incumbant on the MGC to do the subtract explicitly.
> >
> > The ONLY exception to this is restart of the MG; all contexts
> > are lost.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Friday, May 18, 2001 11:32 AM
> > To: 'Dan Elbert'; 'megaco@fore.com'
> > Subject: RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> > Hi.
> >
> > > -----Original Message-----
> > > From: Dan Elbert [ mailto:DElbert@radvision.com
> >  ]
> > > Sent: Friday, May 18, 2001 11:06 AM
> > > To: 'megaco@fore.com'
> > > Subject: Use of ServiceChange from MGC to MG
> > >
> > >
> > > Hi
> > >
> > > The Media Gateway Controller may indicate that Termination(s)
> > > shall be taken
> > > out of or returned to service.
> > > 1. What is the meaning of the MGC taking down a termination ?
> > > Does it means
> > > that the termination is substracted from any active context
> > > and all signal
> > > are stopped and no events are detected ?
> >
> > Yes
> >
> > > 2. What methods are used for taking the MG down and up ? I'd
> > > say Graceful
> > > and Restart. Is this OK ?
> >
> > "Taking the MG down" to me means doing a ServiceChange on
> > ROOT at the MG.
> > It's possible the MGC might do that to an MG, but most likely
> > in that case
> > that it would be done under manual control (i.e. the network
> > is set up such
> > that control of MGs is exercised through the MGC).  I don't
> > see this as a
> > typical maintence arrangement.
> >
> > > 3. Is this applicable also to the root termination ? I would
> > > say no because
> > > if the root termination "goes down" then logically the MG may
> > > not be able to
> > > receive any more MGC commands.
> >
> > Upon recovery the MG would follow normal start-up procedures
> > to establish a
> > new control association.
> >
> > >
> > > Thanks,
> > >
> > > Dan Elbert
> > > RADVISION
> > >
> >
> >
> >







From owner-megaco@fore.com  Fri May 18 15:33:36 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13290
	for ; Fri, 18 May 2001 15:33:36 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA23362;
	Fri, 18 May 2001 15:27:25 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA03816
	for megaco-list; Fri, 18 May 2001 15:26:14 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA03808
	for ; Fri, 18 May 2001 15:26:12 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA23159
	for ; Fri, 18 May 2001 15:26:06 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IJQ7215520
	for ; Fri, 18 May 2001 15:26:07 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IJQ7o15508
	for ; Fri, 18 May 2001 15:26:07 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA23997; Fri, 18 May 2001 15:26:04 -0400 (EDT)
Cc: "'Rosen, Brian'" ,
        "'knayar@hss.hns.com'" , megaco@fore.com
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA23978; Fri, 18 May 2001 15:26:03 -0400 (EDT)
Message-ID: <3B0576D6.46975EDB@lucent.com>
Date: Fri, 18 May 2001 15:24:06 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Dave Sclarsky 
Original-CC: "'Rosen, Brian'" ,
        "'knayar@hss.hns.com'" , megaco@fore.com
Subject: Re: Polls of MGC
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dave Sclarsky wrote:
> 
> Troy,
> 
> It doesn't matter what the new (or restarted) MGC knows or doesn't know.
> Megaco defines that the control association between MG and MGC is ALWAYS
> initiated by the MG.  

Then this definition is the problem and should be revisited.

Polling is bad.

-troy

> Given that definition, Johnny's Dad's MG won't be
> reachable by a new (or a restarted) MGC until the his MG notices the
> failure.  We must define a way for it to know ASAP!


From owner-megaco@fore.com  Fri May 18 15:33:56 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13306
	for ; Fri, 18 May 2001 15:33:56 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA22198;
	Fri, 18 May 2001 15:17:30 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA00926
	for megaco-list; Fri, 18 May 2001 15:14:29 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA00922
	for ; Fri, 18 May 2001 15:14:28 -0400 (EDT)
Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA21705
	for ; Fri, 18 May 2001 15:14:22 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4IJEBu3007369
	for ; Fri, 18 May 2001 14:14:11 -0500
From: "Paul Long" 
To: 
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 14:14:23 -0500
Message-ID: 
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: <3B056F97.6B684C0@lucent.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Troy,

Yes, I was assuming that alternate MGCs would not be aware of the previous,
now-failed association. It seems like you are making an awful lot of
assumptions about those MGCs.

Regarding your email comment, our expectations vary according to the
communication medium. For example, I know that email may get lost or
delayed, so I factor that into my expectation of a timely reply. By
contrast, when I place a phone call, I fully expect to get an accurate and
immediate busy or ring signal.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: troy@lucent.com [mailto:troy@lucent.com]
Sent: Friday, May 18, 2001 1:53 PM
To: Paul Long
Cc: megaco@fore.com
Subject: Re: Polls of MGC


Paul Long wrote:
>
> Troy,
>
> I was leaning towards the no-polling camp, but then I thought about a
> situation that hasn't been mentioned yet. We could just wait until the
> subscriber attempts to place a call to find an available MGC, but what
about
> incoming calls? If the MGC is down, that subscriber cannot be reached
until
> after he or she attempts to place a call. For that reason alone, I think
we
> need a MG-to-MGC polling mechanism.
>
> Paul Long
> ipDialog, Inc.

Paul,

*Why* can't that subscriber be reached?  What doesn't the backup MGC know?
Dan just pointed out to me the only hole I see:  the port number.

Reverse polling and notification is not the way to fix that.
Make it known to the MGC, via a "default or configurable" statement
in the docs.  The MGC knew the IP address right?  That would be
shared with the backup MGC right?  Why wouldn't the port number
be the same?

You guys don't have some vision of COMPLETE discovery and re-discovery
do you?

	Discovery of capabilities is nice.  But in the real world an
	MGC will have to be at least minimally configured for MGs.
	Even if an MGC can find out that a box at IP address X is an
	Y profile RG, or an Z profile TG, it'll have to be told some
	details like what phone numbers map into an RG.

	Even if it doesn't map to the outside world like an RG's phone
	numbers, there are issues of trust.  Consider an announcement
	server that does a standard package of announcements.  I would
	expect an MGC to only use ones it's been told are OK, instead
	of any one that signs up.  Otherwise it's a hack waiting to
	happen -- "alternative" announcements.

Make the port number known the the MGC.


Polling is bad.
The traffic it causes is bad.
The logic of using it to solve this problem is bad.
It is bad enough to make people look for other protocols.


-troy


P.S.  I don't send e-mail to everyone I know once a minute
so I will know in advance if their e-mail is broken.



From owner-megaco@fore.com  Fri May 18 15:42:04 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13587
	for ; Fri, 18 May 2001 15:42:03 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA22907;
	Fri, 18 May 2001 15:24:13 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA03169
	for megaco-list; Fri, 18 May 2001 15:23:11 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA03161
	for ; Fri, 18 May 2001 15:23:10 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA22772
	for ; Fri, 18 May 2001 15:23:03 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IJN5213406
	for ; Fri, 18 May 2001 15:23:05 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IJN5o13396
	for ; Fri, 18 May 2001 15:23:05 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA23883; Fri, 18 May 2001 15:22:45 -0400 (EDT)
Cc: Paul Long , megaco@fore.com
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA23869; Fri, 18 May 2001 15:22:44 -0400 (EDT)
Message-ID: <3B05760E.24176B8A@lucent.com>
Date: Fri, 18 May 2001 15:20:46 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" 
Original-CC: Paul Long , megaco@fore.com
Subject: Re: Polls of MGC
References: <4FBEA8857476D311A03300204840E1CF01A6F64F@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Rosen, Brian" wrote:
> 
> There is no way for the alternate MGC to take over control
> of the MGs.  That is a design decision, and we made it because
> of security concerns ("Hello, I'm your new boss, don't worry
> about a thing")

Security isn't in *how* it's discovered.
Security is in what action is taken.

If the MG discovers his MGC is dead by polling, he
goes to his pre-configured list of secondary MGCs, yes?

How is this less secure than letting him accept
"I'm your new boss" from MGCs on that list?


> Whether you know about port numbers or not, another MGC cannot
> break into an existing control association.  There are ways that
> you can build redundant MGCs that can do a takeover where the
> MG is unaware of the takeover.  That is not the circumstance we
> are discussing.

Than what are we discussing???  If you can fix the problem without 
the MG knowing about it, why are discussing ways the MG can discover 
the problem ????


> That means the MG is the one that discovers the MGC is dead, and
> it needs a way to do that.

Polling is bad.

-troy


From owner-megaco@fore.com  Fri May 18 15:43:28 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13652
	for ; Fri, 18 May 2001 15:43:28 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24363;
	Fri, 18 May 2001 15:35:31 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA05814
	for megaco-list; Fri, 18 May 2001 15:34:01 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA05809
	for ; Fri, 18 May 2001 15:33:59 -0400 (EDT)
Received: from pine.cyberpathinc.com ([38.246.253.128])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24104
	for ; Fri, 18 May 2001 15:33:54 -0400 (EDT)
Received: from YSHA (ysha [172.30.30.41])
	by pine.cyberpathinc.com (8.9.3+Sun/8.9.3) with SMTP id PAA29482
	for ; Fri, 18 May 2001 15:36:06 -0400 (EDT)
Received: by YSHA with Microsoft Mail
	id <01C0DFB0.0274C8A0@YSHA>; Fri, 18 May 2001 15:34:21 -0400
Message-ID: <01C0DFB0.0274C8A0@YSHA>
From: YouLing Sha 
To: "'megaco@fore.com'" 
Subject: If resource of a termination is busy on a Non-Megaco call, what should MG do ?
Date: Fri, 18 May 2001 15:34:20 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

If a residentail gateway has a group of subscribers provisioned on the access side; 
and on the network side, it has GR-303 to the PSTN and Megaco to IP. The calls made 
by the subscribers from the access side can be routed to PSTN (using GR-303 not Megaco) 
or IP (using Megaco) based on some pre-defined routing creteria (say time based, 
digit based, or resource based).  

In MEGACO environment. MGC is the master and MG behaves as a slave.
Assuming the gateway has a subscriber (say A). Now if "A" is busy with a GR-303 
call to the PSTN (not going through the Megaco/MG on the gateway), 
and the MGC being unaware of it, sends an incoming call request to the gateway for "A", 
then the call has to be rejected because A is actually busy. 

The questions are:

1. What could be the error cause so that we could avoid any audit triggering
from the MGC. Because the audit correction might be termination out of
service or hook status change?
2. Could we make the Termination Out of service temporarily (during the
period it's in a call with some other interface)  by sending a Service
change to the MGC so that no incoming call request will come from MGC?

Your advise is highly appreciated.

Regards,
YouLing Sha



From owner-megaco@fore.com  Fri May 18 15:46:02 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13767
	for ; Fri, 18 May 2001 15:46:01 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA23685;
	Fri, 18 May 2001 15:29:27 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA04437
	for megaco-list; Fri, 18 May 2001 15:28:18 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA04432
	for ; Fri, 18 May 2001 15:28:16 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA23491
	for ; Fri, 18 May 2001 15:28:09 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4IJS9dQ011663
	for ; Fri, 18 May 2001 14:28:09 -0500 (CDT)
From: "Paul Long" 
To: "MEGACO list" 
Subject: RE: SDP and ';' comments
Date: Fri, 18 May 2001 14:28:11 -0500
Message-ID: 
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: <3B056472.7E38EDEF@lucent.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Troy,

I have to agree with David. Although RFC2234 (ABNF) does not actually state
whether scanning is left to right or right to left, I can't imagine any
parser scanning backwards like that. I think it is implied that each
component in a rule definition fully matches--from left to right--without
regard to what components may follow. Therefore, I think the trailing
comments are matched by the octetString and not by the RBRKT.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Troy Cauble
Sent: Friday, May 18, 2001 1:06 PM
To: David Stonehouse
Cc: MEGACO list; 'Tulpule, Naren'
Subject: Re: SDP and ';' comments


> David Stonehouse wrote:
>
> The resolution to Troy's initial statement is not only because of the way
an
> SDP ends, but also in the way that the octetString terminal will force the
> Megaco parser to pull everything up to the '}' into the octetString.  The
net
> result is even though the official definition of RBRKT allows for a
comment
> in front or behind, in this case, there will never be any LWSP (including
> comments) for the Megaco parser to parse before the '}'.  The resulting
> octetString is what will get passed to the SDP parser.  If this string
fails
> to parse according to SDP syntax, then the message should be rejected for
bad
> syntax (including any trailing Megaco comment ';').
>
> So, even if the comment were added after the newline but before the '}',
it
> is still bad syntax because it falls under SDP parsing rules.  (A parser
may
> want to be liberal in accepting this, but that's beside the point.)

David,

While many parsers work this way, I don't think that using ABNF
implies that ambiguous text has to be applied to the preceding token.
That is, it's just as valid to associate the spaces in "}    }" with
the last RBRKT as the first.

So I think comments between the last line of SDP and the '}' are
legal unless we explicitly document that they're not.


-troy



From owner-megaco@fore.com  Fri May 18 15:54:35 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13768
	for ; Fri, 18 May 2001 15:46:01 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24921;
	Fri, 18 May 2001 15:40:01 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA07157
	for megaco-list; Fri, 18 May 2001 15:38:45 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA07144
	for ; Fri, 18 May 2001 15:38:42 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24750
	for ; Fri, 18 May 2001 15:38:37 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IJcc225426
	for ; Fri, 18 May 2001 15:38:38 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IJcco25421
	for ; Fri, 18 May 2001 15:38:38 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA24428; Fri, 18 May 2001 15:38:35 -0400 (EDT)
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA24424; Fri, 18 May 2001 15:38:35 -0400 (EDT)
Message-ID: <3B0579C5.22956E08@lucent.com>
Date: Fri, 18 May 2001 15:36:37 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: MEGACO list 
Subject: Re: SDP and ';' comments
References: 
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



"Tulpule, Naren" wrote:



[Naren]
So far I haven't seen either "}" or "\}" in SDP. The thing is, we don't
really need to impose any restrictions on SDP at all. Just start a new
line with something which cannot occur after EOL in SDP  and define
that to be the "end-of-SDP-start-of-Megaco" delimiter (e.g. "==") instead
of RBRKT. (For the aesthetes, RBRKT can still follow this delimiter).







Very clean.  I like this idea a lot.  It saves quoting
the '}' characters.

The delimiter could even be whitespace.  Or any line that doesn't

match "[a-z]=".

But it's probably too late to get agreement on such a change.

-troy



From owner-megaco@fore.com  Fri May 18 15:54:35 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13766
	for ; Fri, 18 May 2001 15:46:01 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24317;
	Fri, 18 May 2001 15:35:18 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA05770
	for megaco-list; Fri, 18 May 2001 15:33:44 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA05744
	for ; Fri, 18 May 2001 15:33:40 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 15:33:01 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F656@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Troy Cauble'" ,
        Dave Sclarsky
	 
Cc: "'knayar@hss.hns.com'" , megaco@fore.com
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 15:33:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Troy

Keepalives have never been considered very bad when they have the
appropriate controls.  I don't know what systems you have worked on, but
most of the reliable systems I know have keepalives.

In this case, we CAN make it one-sided - the MGC makes sure that it
has some minimum message rate to the MGs it controls, or we can
let the MG send a message if, after some time the MGC determines,
it hasn't seen a message from the MGC.  Either way works.  Either way
should NOT be a big burden.  Note that you also can implement both,
and by sending messages from the MGC faster than the interval you
set on the MG, you won't ever see any of the MG initiated messages,
until something goes wrong. Then you will see ONE message from each
MG, and then, in a pretty random, and pretty spaced out way (if you
have done the right thing with MG setup on the MGC), you should see
them all move over to another MGC.

I'm not up for changing something that isn't broken

Keepalives are good for reliability.

Brian

Brian

> -----Original Message-----
> From: Troy Cauble [mailto:troy@lucent.com]
> Sent: Friday, May 18, 2001 3:24 PM
> To: Dave Sclarsky
> Cc: 'Rosen, Brian'; 'knayar@hss.hns.com'; megaco@fore.com
> Subject: Re: Polls of MGC
> 
> 
> Dave Sclarsky wrote:
> > 
> > Troy,
> > 
> > It doesn't matter what the new (or restarted) MGC knows or 
> doesn't know.
> > Megaco defines that the control association between MG and 
> MGC is ALWAYS
> > initiated by the MG.  
> 
> Then this definition is the problem and should be revisited.
> 
> Polling is bad.
> 
> -troy
> 
> > Given that definition, Johnny's Dad's MG won't be
> > reachable by a new (or a restarted) MGC until the his MG notices the
> > failure.  We must define a way for it to know ASAP!
> 


From owner-megaco@fore.com  Fri May 18 15:55:16 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14186
	for ; Fri, 18 May 2001 15:55:15 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA25827;
	Fri, 18 May 2001 15:46:52 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA08981
	for megaco-list; Fri, 18 May 2001 15:45:50 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA08967
	for ; Fri, 18 May 2001 15:45:47 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA25702
	for ; Fri, 18 May 2001 15:45:41 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4IJjfdQ016169
	for ; Fri, 18 May 2001 14:45:41 -0500 (CDT)
From: "Paul Long" 
To: 
Subject: RE: Polls of MGC
Date: Fri, 18 May 2001 14:45:43 -0500
Message-ID: 
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: <3B0576D6.46975EDB@lucent.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Troy,

Bad polling! Bad polling! You're a bad polling! Bad, bad, bad! :-) Sorry, I
couldn't resist.

I don't know the underlying protocols very well at all, but doesn't TCP
itself poll or send keep-alives? Isn't that how each side knows when the
connection is lost? How about mobile networks? Surely the phones and cell
nodes do something like this, too, don't they? It seems like when you get
away from a dedicated piece of wire from the phone (I'm thinking residential
MGs) to the local end-office switch, you're going to have to have some kind
of periodic signal to verify the connection with the controlling entity.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Troy Cauble
Sent: Friday, May 18, 2001 2:24 PM
To: Dave Sclarsky
Cc: 'Rosen, Brian'; 'knayar@hss.hns.com'; megaco@fore.com
Subject: Re: Polls of MGC


Dave Sclarsky wrote:
>
> Troy,
>
> It doesn't matter what the new (or restarted) MGC knows or doesn't know.
> Megaco defines that the control association between MG and MGC is ALWAYS
> initiated by the MG.

Then this definition is the problem and should be revisited.

Polling is bad.

-troy

> Given that definition, Johnny's Dad's MG won't be
> reachable by a new (or a restarted) MGC until the his MG notices the
> failure.  We must define a way for it to know ASAP!



From owner-megaco@fore.com  Fri May 18 15:57:44 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14264
	for ; Fri, 18 May 2001 15:57:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA26271;
	Fri, 18 May 2001 15:51:46 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA10015
	for megaco-list; Fri, 18 May 2001 15:50:44 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA09996
	for ; Fri, 18 May 2001 15:50:42 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 15:50:07 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F658@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'YouLing Sha'" ,
        "'megaco@fore.com'"
	 
Subject: RE: If resource of a termination is busy on a Non-Megaco call, wh
	at should MG do ?
Date: Fri, 18 May 2001 15:50:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

The protocol is not designed to cover such a case.  You can use
any error you would like, but unless an MGC has been designed to
deal with the concept that it is not a real client server arrangement
you are going to have trouble.  MGCs assume they are in complete
control of the terminations.

Probably what you want to do is define a package that 
adds an error, and possibly an event. Then you need to get the
MGC vendors to implement it.

A better idea is to make the GR-303 side a set of terminations
that the MGC controls.  Then the MGC can make "calls" between the
subscriber side and the GR-303 ports.  Also needs implementation
at the MGC, but you will probably find that.  You may actually want
the MG to appear to be two MGs, one that has the subscriber side
and one that has the GR-303 side.  You can easily shortcut the
network connections.  It also opens up nice possibilities of routing
calls from other MGs to the GR-303 ports.

Brian

> -----Original Message-----
> From: YouLing Sha [mailto:ysha@cpmail.cyberpathinc.com]
> Sent: Friday, May 18, 2001 3:34 PM
> To: 'megaco@fore.com'
> Subject: If resource of a termination is busy on a Non-Megaco 
> call, what
> should MG do ?
> 
> 
> Hi,
> 
> If a residentail gateway has a group of subscribers 
> provisioned on the access side; 
> and on the network side, it has GR-303 to the PSTN and Megaco 
> to IP. The calls made 
> by the subscribers from the access side can be routed to PSTN 
> (using GR-303 not Megaco) 
> or IP (using Megaco) based on some pre-defined routing 
> creteria (say time based, 
> digit based, or resource based).  
> 
> In MEGACO environment. MGC is the master and MG behaves as a slave.
> Assuming the gateway has a subscriber (say A). Now if "A" is 
> busy with a GR-303 
> call to the PSTN (not going through the Megaco/MG on the gateway), 
> and the MGC being unaware of it, sends an incoming call 
> request to the gateway for "A", 
> then the call has to be rejected because A is actually busy. 
> 
> The questions are:
> 
> 1. What could be the error cause so that we could avoid any 
> audit triggering
> from the MGC. Because the audit correction might be termination out of
> service or hook status change?
> 2. Could we make the Termination Out of service temporarily 
> (during the
> period it's in a call with some other interface)  by sending a Service
> change to the MGC so that no incoming call request will come from MGC?
> 
> Your advise is highly appreciated.
> 
> Regards,
> YouLing Sha
> 


From owner-megaco@fore.com  Fri May 18 16:25:52 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15296
	for ; Fri, 18 May 2001 16:25:52 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA27825;
	Fri, 18 May 2001 16:10:12 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA14204
	for megaco-list; Fri, 18 May 2001 16:08:43 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA14199
	for ; Fri, 18 May 2001 16:08:42 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA27604
	for ; Fri, 18 May 2001 16:08:36 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IK8bZ21093
	for ; Fri, 18 May 2001 16:08:37 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IK8bv21083
	for ; Fri, 18 May 2001 16:08:37 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id QAA25605; Fri, 18 May 2001 16:08:34 -0400 (EDT)
Cc: megaco@fore.com
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id QAA25596; Fri, 18 May 2001 16:08:33 -0400 (EDT)
Message-ID: <3B0580CC.B5231D7@lucent.com>
Date: Fri, 18 May 2001 16:06:36 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" 
Original-CC: megaco@fore.com
Subject: Re: Polls of MGC
References: <4FBEA8857476D311A03300204840E1CF01A6F656@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Rosen, Brian" wrote:
> 
> Troy
> 
> Keepalives have never been considered very bad when they have the
> appropriate controls.  I don't know what systems you have worked on, but
> most of the reliable systems I know have keepalives.

Not considered "very" bad ?  Just a little bad? :)

> I'm not up for changing something that isn't broken

The words "poll" and "keepalive" do not exist in the
H.248 document or the IG.  You are changing something.

-troy


From owner-megaco@fore.com  Fri May 18 16:27:43 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15383
	for ; Fri, 18 May 2001 16:27:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA28651;
	Fri, 18 May 2001 16:20:01 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA16819
	for megaco-list; Fri, 18 May 2001 16:19:04 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA16806
	for ; Fri, 18 May 2001 16:19:02 -0400 (EDT)
From: rezhirpavai@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA28524
	for ; Fri, 18 May 2001 16:18:54 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4IKJJf27280;
	Sat, 19 May 2001 01:49:19 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A50.006E2B8F ; Sat, 19 May 2001 01:33:21 +0530
X-Lotus-FromDomain: HSS
To: "Madhu Babu Brahmanapally" 
cc: "'Kevin Boyle'" ,
        "'Rosen, Brian'" ,
        "'Tom-PT Taylor'" ,
        "'Dan Elbert'" , megaco@fore.com
Message-ID: <65256A50.006E2A4A.00@sandesh.hss.hns.com>
Date: Sat, 19 May 2001 01:40:48 +0530
Subject: RE: Use of ServiceChange from MGC to MG
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk



Hello,
     If the media flow is stopped on receiving the SC, then why should it remain
in context? What is achieved by keeping it in context, though call is not going
on?
If it is just for stats information, why can't we add stats descriptor in
service change reply and in this way the MG would reply positively for the SC
and at the same time delete the context too without an explict subtract command.

                                         Regards,
                                         R. Ezhirpavai





"Madhu Babu Brahmanapally"  on 05/19/2001 12:47:49 AM

To:   R Ezhirpavai/HSS@HSS, "'Kevin Boyle'" 
cc:   "'Rosen, Brian'" , "'Tom-PT Taylor'"
      , "'Dan Elbert'" ,
      megaco@fore.com

Subject:  RE: Use of ServiceChange from MGC to MG




HI Pavai,
The media flows also will stop when the ServiceChange is received by the MG
to put that termination out-of-service. Hence the question of the Endpoint
being in call is ruled-out. Second if the MGC is generating service change
for the termination that is in Active context, then it has to generate
Subtract also. If it doesn't there is a potential problem with the MGC
implementation.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of
rezhirpavai@hss.hns.com
Sent: Friday, May 18, 2001 2:46 PM
To: Kevin Boyle
Cc: Rosen, Brian; Tom-PT Taylor; 'Dan Elbert'; 'megaco@fore.com'
Subject: Re: Use of ServiceChange from MGC to MG




Hello,
     Consider that due to a discripency the MG still has the "termA" in
context
and the MGC assumes that the termA is in NULL context. In this case the MGC
would send service change with forced and would not send any subtract, but
MG is
still waiting for the call to terminate.

     By indicating that the MG should not remove it from context till it
receives a subtract, does it not imply that the MG should not stop the media
flow too?

                                         Regards,
                                         R. Ezhirpavai





"Kevin Boyle"  on 05/18/2001 11:55:51 PM

To:   R Ezhirpavai/HSS@HSS
cc:   "Rosen, Brian" , "Tom-PT Taylor"
      , "'Dan Elbert'" ,
      "'megaco@fore.com'" 

Subject:  Re: Use of ServiceChange from MGC to MG




Why?  What benefit is gained by setting this restriction?  Now, I would
agree
with
the idea that "out of service" also implies "inactive", thereby halting the
information flow on the streams.  However, I don't see any great problem
with
allowing the out of service Modify command to precede the Subtract.  The MG
is
supposed to leave terminations in context until explicitly subtracted, or
the MG
restarts.

Kevin

rezhirpavai@hss.hns.com wrote:

> Hello Brain,
>      Yes, I was mentioning about the order of operations. IMHO, the
protocol
> should enforce the MGC to subtract the termination from context before
putting
> it out of service. If the MGC sends the service change for putting the
> termination out of service, while the termination is in context, MG should
send
> back an error to the MGC, thus indicating to the MGC that the termination
is
in
> context and any discripency between the MG and MGC may be resolved.
>
>                                          Regards,
>                                          R. Ezhirpavai
>
> "Rosen, Brian"  on 05/18/2001 11:08:30 PM
>
> To:   R Ezhirpavai/HSS@HSS
> cc:   "'Tom-PT Taylor'" , "'Dan Elbert'"
>       , "'megaco@fore.com'" 
>
> Subject:  RE: Use of ServiceChange from MGC to MG
>
> I said that - the MGC does the Subtract explicitly; just
> taking the termination out of service DOES NOT implicitly do
> a Subtract.  If you are arguing about the order of operations,
> I would recommend the Subtract before the ServiceChange.
>
> The usual drill for the MGC is first to subtract, then serviceChange
> forced.  There really isn't any reason for the MGC to use Graceful.
>
> The usual drill for the MG is to send Graceful, the MGC responds
> with Subtract, then the MG makes the terminations out of
> service after the subtract or at the latest, after the timeout.
>
> A forced Restart on Root should happen immediately.
>
> Brian
>
> > -----Original Message-----
> > From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
> > Sent: Friday, May 18, 2001 1:13 PM
> > To: Rosen, Brian
> > Cc: 'Tom-PT Taylor'; 'Dan Elbert'; 'megaco@fore.com'
> > Subject: RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> >
> > Hello Brain,
> >      Since the MGC is the controller of the call, shouldn't
> > the MGC explicitly
> > subtract the call from the context before taking the
> > termination out of service?
> > In what scenarios would the MGC take the termination out of
> > service and then
> > subtract it from the call explicitly.
> >
> >      Taking it a bit further, if the MGC sends service change
> > with "forced" on
> > ROOT termination, should the MG still wait for the contexts
> > on all terminations
> > to be subtracted explicitly by the MGC before going down?
> >
> >
> >                                          Regards,
> >                                          R. Ezhirpavai
> >
> >
> >
> >
> >
> > "Rosen, Brian"  on 05/18/2001 09:07:21 PM
> >
> > To:   "'Tom-PT Taylor'" , "'Dan Elbert'"
> >       , "'megaco@fore.com'" 
> > cc:    (bcc: R Ezhirpavai/HSS)
> >
> > Subject:  RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> >
> > One thing I think is incorrect here is the "Subtracted from any active
> > contexts" part.  I believe we defined the protocol so that this NEVER
> > happens
> > as a side-effect.  The termination may actually be out of
> > service, but both
> > the MG and the MGC have it in a context if it was when the
> > termination was
> > taken out of service.
> >
> > It is always incumbant on the MGC to do the subtract explicitly.
> >
> > The ONLY exception to this is restart of the MG; all contexts
> > are lost.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Friday, May 18, 2001 11:32 AM
> > To: 'Dan Elbert'; 'megaco@fore.com'
> > Subject: RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> > Hi.
> >
> > > -----Original Message-----
> > > From: Dan Elbert [ mailto:DElbert@radvision.com
> >  ]
> > > Sent: Friday, May 18, 2001 11:06 AM
> > > To: 'megaco@fore.com'
> > > Subject: Use of ServiceChange from MGC to MG
> > >
> > >
> > > Hi
> > >
> > > The Media Gateway Controller may indicate that Termination(s)
> > > shall be taken
> > > out of or returned to service.
> > > 1. What is the meaning of the MGC taking down a termination ?
> > > Does it means
> > > that the termination is substracted from any active context
> > > and all signal
> > > are stopped and no events are detected ?
> >
> > Yes
> >
> > > 2. What methods are used for taking the MG down and up ? I'd
> > > say Graceful
> > > and Restart. Is this OK ?
> >
> > "Taking the MG down" to me means doing a ServiceChange on
> > ROOT at the MG.
> > It's possible the MGC might do that to an MG, but most likely
> > in that case
> > that it would be done under manual control (i.e. the network
> > is set up such
> > that control of MGs is exercised through the MGC).  I don't
> > see this as a
> > typical maintence arrangement.
> >
> > > 3. Is this applicable also to the root termination ? I would
> > > say no because
> > > if the root termination "goes down" then logically the MG may
> > > not be able to
> > > receive any more MGC commands.
> >
> > Upon recovery the MG would follow normal start-up procedures
> > to establish a
> > new control association.
> >
> > >
> > > Thanks,
> > >
> > > Dan Elbert
> > > RADVISION
> > >
> >
> >
> >











From owner-megaco@fore.com  Fri May 18 16:37:13 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15709
	for ; Fri, 18 May 2001 16:37:12 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA29157;
	Fri, 18 May 2001 16:25:09 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA17593
	for megaco-list; Fri, 18 May 2001 16:23:55 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA17573
	for ; Fri, 18 May 2001 16:23:52 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA29004
	for ; Fri, 18 May 2001 16:23:46 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Fri, 18 May 2001 15:24:20 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD94945811104@RADVPOST>
From: Dan Elbert 
To: "'megaco@fore.com'" 
Subject: SVC of termination
Date: Fri, 18 May 2001 15:24:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hi

If an MGC receives a SVC with restart method from a particular termination
of some MG before receiving the SVC from the root termination of the same
MG, is this an error ? If so, what is the error code that the MGC should
return ?

Thanks,

Dan Elbert
RADVISION


From owner-megaco@fore.com  Fri May 18 17:36:48 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16839
	for ; Fri, 18 May 2001 17:36:47 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA02763;
	Fri, 18 May 2001 17:21:58 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA28342
	for megaco-list; Fri, 18 May 2001 17:20:23 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA28334
	for ; Fri, 18 May 2001 17:20:21 -0400 (EDT)
Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA02599
	for ; Fri, 18 May 2001 17:20:15 -0400 (EDT)
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.39 2001/05/18 00:47:02 root Exp $) with SMTP id VAA21046
	for ; Fri, 18 May 2001 21:20:17 GMT
Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 18 May 2001 21:20:13 0000 (GMT)
Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 18 May 2001 14:20:12 -0700
Message-ID: 
From: "Kaul, Bharat" 
To: megaco@fore.com
Subject: RE: Use of ServiceChange from MGC to MG
Date: Fri, 18 May 2001 14:20:03 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Brian/List,

Basic Question ...Why does MGC need to send "Forced", "Graceful" to MG with
Termination as ROOT ?

Why is it bringing down the MG ? As you pointed out, I would think it is a
management interface issue.

And did any on these situation even arise at interop ? This is first time I
am hearing MGC can send these methods in SVC


- Bharat




-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Friday, May 18, 2001 11:24 AM
To: 'Madhu Babu Brahmanapally'; rezhirpavai@hss.hns.com
Cc: 'Dan Elbert'; megaco@fore.com
Subject: RE: Use of ServiceChange from MGC to MG


Where do you get "unregistration"?

When sent from MG to MGC SC forced on Root means "I am going down" 
When sent from MGC to MG forced on Root means "go down"

And the corresponding Restart does the obvious thing.

There is an argument that this treads into management interface
territory.

Brian

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Friday, May 18, 2001 2:22 PM
> To: 'Rosen, Brian'; rezhirpavai@hss.hns.com
> Cc: 'Dan Elbert'; megaco@fore.com
> Subject: RE: Use of ServiceChange from MGC to MG
> 
> 
> There is no mention of this "unregistration" from the MGC in 
> the protocol.
> The protocol only address ServiceChange with ROOT termination 
> ID as a means
> of MG registering with the MGC but not the other way round. I 
> was in the
> impression that it is possible according to the grammar but 
> nothing like
> "un-registration" exists. (I'm not sure whether every one has 
> the common
> understanding of this "un-registration")
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Friday, May 18, 2001 2:04 PM
> To: 'Madhu Babu Brahmanapally'; rezhirpavai@hss.hns.com
> Cc: 'Dan Elbert'; megaco@fore.com
> Subject: RE: Use of ServiceChange from MGC to MG
> 
> 
> I think you can - it's an MGC invoked soft boot.
> 
> Brian
> 
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > Sent: Friday, May 18, 2001 1:52 PM
> > To: rezhirpavai@hss.hns.com
> > Cc: 'Dan Elbert'; megaco@fore.com
> > Subject: RE: Use of ServiceChange from MGC to MG
> >
> >
> > HI Pavai,
> > I think second point address non-ROOT terminations. I don't
> > think the MGC
> > can send ServiceChange on ROOT to either bring it down or up.
> > (Of course
> > there is no restriction from the protocol that MGC cannot
> > send ServiceChange
> > on ROOT...I think we may need some consensus on this from everyone).
> >
> > Regards
> > Madhubabu
> >
> > -----Original Message-----
> > From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
> > Sent: Friday, May 18, 2001 12:55 PM
> > To: Madhu Babu Brahmanapally
> > Cc: 'Dan Elbert'; megaco@fore.com
> > Subject: RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> >
> > Hello Madhu,
> >      In the second point you have mentioned about the methods
> > for taking the
> > MG
> > down as "forced" and restart".  If the MG itself wants to
> > indicate about its
> > going down, then it can either send "graceful" or "forced",
> > but if the MGC
> > wants
> > to bring down its association with the MG then it needs to
> > send service
> > change
> > on ROOT with "forced". "Restart" from MGC on ROOT termination
> > is not valid.
> > In
> > this case the MG needs to itself send service change to any
> > secondary MGC or
> > to
> > the same primary MGC (if secondary MGC are configured) after restart
> > avalance
> > timer.
> >
> >
> >                                          Regards,
> >                                          R. Ezhirpavai
> >
> >
> >
> >
> >
> > "Madhu Babu Brahmanapally"  on
> > 05/18/2001 09:05:16 PM
> >
> > To:   "'Dan Elbert'" , megaco@fore.com
> > cc:    (bcc: R Ezhirpavai/HSS)
> >
> > Subject:  RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> >
> > HI Dan,
> > Comments below [Madhu]
> >
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dan Elbert
> > Sent: Friday, May 18, 2001 11:06 AM
> > To: 'megaco@fore.com'
> > Subject: Use of ServiceChange from MGC to MG
> >
> >
> > Hi
> >
> > The Media Gateway Controller may indicate that Termination(s)
> > shall be taken
> > out of or returned to service.
> >
> > 1. What is the meaning of the MGC taking down a termination ?
> > Does it means
> > that the termination is substracted from any active context
> > and all signal
> > are stopped and no events are detected ?
> > [Madhu] IMO its similar to the situation where MG generates such
> > servicechange.
> > The signals to be stopped and no event detection.
> > Will be useful in
> > 1) Residential Gateway - Where the user profile is not
> > encouraging and the
> > MGC doesn't
> > want to entertain any messages generated from the MG for that
> > endpoint.
> > 2) Trunking gateway - Remove some of the trunks from the
> > initial provisioned
> > trunks.
> >
> > 2. What methods are used for taking the MG down and up ? I'd
> > say Graceful
> > and Restart. Is this OK ?
> > [Madhu] I think Graceful is a mean by which MG can say to MGC
> > that this
> > particular termination
> > shouldn't be used for further calls. Graceful has no 
> meaning when MGC
> > generates this. I think the
> > methods should be "forced" and "restart".
> >
> > 3. Is this applicable also to the root termination ? I would
> > say no because
> > if the root termination "goes down" then logically the MG may
> > not be able to
> > receive any more MGC commands.
> > [Madhu] Yes. Your argument is correct.
> >
> > Thanks,
> >
> > Dan Elbert
> > RADVISION
> >
> >
> >
> >
> >
> 



From owner-megaco@fore.com  Fri May 18 17:51:08 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17133
	for ; Fri, 18 May 2001 17:51:08 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA03326;
	Fri, 18 May 2001 17:29:45 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA29646
	for megaco-list; Fri, 18 May 2001 17:28:26 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA29638
	for ; Fri, 18 May 2001 17:28:24 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA03199
	for ; Fri, 18 May 2001 17:28:18 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4ILSKZ09682
	for ; Fri, 18 May 2001 17:28:20 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4ILSKv09678
	for ; Fri, 18 May 2001 17:28:20 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id RAA29545; Fri, 18 May 2001 17:28:19 -0400 (EDT)
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id RAA29541; Fri, 18 May 2001 17:28:18 -0400 (EDT)
Message-ID: <3B05937B.84699EFE@lucent.com>
Date: Fri, 18 May 2001 17:26:19 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: MEGACO list 
Subject: Annex F, ftmd package question
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


F.5 says:

 ''This Package extends the possible values of tone id in the
 "start tone detected" event.''

Is limiting them to "std" the intent?  
Should these values be valid for "ltd" and "etd" too?

-troy


From owner-megaco@fore.com  Fri May 18 20:15:43 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20156
	for ; Fri, 18 May 2001 20:15:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA08831;
	Fri, 18 May 2001 20:08:29 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA13473
	for megaco-list; Fri, 18 May 2001 20:06:30 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA13468
	for ; Fri, 18 May 2001 20:06:27 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA08741
	for ; Fri, 18 May 2001 20:06:20 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACS22250;
	Fri, 18 May 2001 20:06:04 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Kaul, Bharat'" , 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Fri, 18 May 2001 20:10:06 -0400
Message-ID: <027801c0dff8$0fe56830$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

HI All,

I posted similar query earlier. Even if we assume that the MGC can generate
ServiceChange Forced on ROOT, IMO any further messages from the MGC should
not be responded by the MG because the MGC has broken the control
association. Then the MG has to reinitiate the "registration" process with
the SC Restart on ROOT. (IMO The SC Restart on ROOT from MGC will have to
discarded by the MG)

My argument is that if the MG's  SC Restart on ROOT establishes the control
association then the MGC's SC Forced on ROOT should be treated as breaking
this association. Of course nothing regarding to this is mentioned in the
protocol. The only cases that are addressed in the protocol regarding usage
of SC with ROOT is the MGC using the SC generation with Handoff methods.

I agree that the MGC should be able to break the control association
but...the protocol should say this somewhere describing the usage of Root
TerminationId with ServiceChange.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Kaul, Bharat
Sent: Friday, May 18, 2001 5:20 PM
To: megaco@fore.com
Subject: RE: Use of ServiceChange from MGC to MG


Brian/List,

Basic Question ...Why does MGC need to send "Forced", "Graceful" to MG with
Termination as ROOT ?

Why is it bringing down the MG ? As you pointed out, I would think it is a
management interface issue.

And did any on these situation even arise at interop ? This is first time I
am hearing MGC can send these methods in SVC


- Bharat




-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Friday, May 18, 2001 11:24 AM
To: 'Madhu Babu Brahmanapally'; rezhirpavai@hss.hns.com
Cc: 'Dan Elbert'; megaco@fore.com
Subject: RE: Use of ServiceChange from MGC to MG


Where do you get "unregistration"?

When sent from MG to MGC SC forced on Root means "I am going down"
When sent from MGC to MG forced on Root means "go down"

And the corresponding Restart does the obvious thing.

There is an argument that this treads into management interface
territory.

Brian

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Friday, May 18, 2001 2:22 PM
> To: 'Rosen, Brian'; rezhirpavai@hss.hns.com
> Cc: 'Dan Elbert'; megaco@fore.com
> Subject: RE: Use of ServiceChange from MGC to MG
>
>
> There is no mention of this "unregistration" from the MGC in
> the protocol.
> The protocol only address ServiceChange with ROOT termination
> ID as a means
> of MG registering with the MGC but not the other way round. I
> was in the
> impression that it is possible according to the grammar but
> nothing like
> "un-registration" exists. (I'm not sure whether every one has
> the common
> understanding of this "un-registration")
>
> Regards
> Madhubabu
>
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Friday, May 18, 2001 2:04 PM
> To: 'Madhu Babu Brahmanapally'; rezhirpavai@hss.hns.com
> Cc: 'Dan Elbert'; megaco@fore.com
> Subject: RE: Use of ServiceChange from MGC to MG
>
>
> I think you can - it's an MGC invoked soft boot.
>
> Brian
>
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > Sent: Friday, May 18, 2001 1:52 PM
> > To: rezhirpavai@hss.hns.com
> > Cc: 'Dan Elbert'; megaco@fore.com
> > Subject: RE: Use of ServiceChange from MGC to MG
> >
> >
> > HI Pavai,
> > I think second point address non-ROOT terminations. I don't
> > think the MGC
> > can send ServiceChange on ROOT to either bring it down or up.
> > (Of course
> > there is no restriction from the protocol that MGC cannot
> > send ServiceChange
> > on ROOT...I think we may need some consensus on this from everyone).
> >
> > Regards
> > Madhubabu
> >
> > -----Original Message-----
> > From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
> > Sent: Friday, May 18, 2001 12:55 PM
> > To: Madhu Babu Brahmanapally
> > Cc: 'Dan Elbert'; megaco@fore.com
> > Subject: RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> >
> > Hello Madhu,
> >      In the second point you have mentioned about the methods
> > for taking the
> > MG
> > down as "forced" and restart".  If the MG itself wants to
> > indicate about its
> > going down, then it can either send "graceful" or "forced",
> > but if the MGC
> > wants
> > to bring down its association with the MG then it needs to
> > send service
> > change
> > on ROOT with "forced". "Restart" from MGC on ROOT termination
> > is not valid.
> > In
> > this case the MG needs to itself send service change to any
> > secondary MGC or
> > to
> > the same primary MGC (if secondary MGC are configured) after restart
> > avalance
> > timer.
> >
> >
> >                                          Regards,
> >                                          R. Ezhirpavai
> >
> >
> >
> >
> >
> > "Madhu Babu Brahmanapally"  on
> > 05/18/2001 09:05:16 PM
> >
> > To:   "'Dan Elbert'" , megaco@fore.com
> > cc:    (bcc: R Ezhirpavai/HSS)
> >
> > Subject:  RE: Use of ServiceChange from MGC to MG
> >
> >
> >
> >
> > HI Dan,
> > Comments below [Madhu]
> >
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dan Elbert
> > Sent: Friday, May 18, 2001 11:06 AM
> > To: 'megaco@fore.com'
> > Subject: Use of ServiceChange from MGC to MG
> >
> >
> > Hi
> >
> > The Media Gateway Controller may indicate that Termination(s)
> > shall be taken
> > out of or returned to service.
> >
> > 1. What is the meaning of the MGC taking down a termination ?
> > Does it means
> > that the termination is substracted from any active context
> > and all signal
> > are stopped and no events are detected ?
> > [Madhu] IMO its similar to the situation where MG generates such
> > servicechange.
> > The signals to be stopped and no event detection.
> > Will be useful in
> > 1) Residential Gateway - Where the user profile is not
> > encouraging and the
> > MGC doesn't
> > want to entertain any messages generated from the MG for that
> > endpoint.
> > 2) Trunking gateway - Remove some of the trunks from the
> > initial provisioned
> > trunks.
> >
> > 2. What methods are used for taking the MG down and up ? I'd
> > say Graceful
> > and Restart. Is this OK ?
> > [Madhu] I think Graceful is a mean by which MG can say to MGC
> > that this
> > particular termination
> > shouldn't be used for further calls. Graceful has no
> meaning when MGC
> > generates this. I think the
> > methods should be "forced" and "restart".
> >
> > 3. Is this applicable also to the root termination ? I would
> > say no because
> > if the root termination "goes down" then logically the MG may
> > not be able to
> > receive any more MGC commands.
> > [Madhu] Yes. Your argument is correct.
> >
> > Thanks,
> >
> > Dan Elbert
> > RADVISION
> >
> >
> >
> >
> >
>



From owner-megaco@fore.com  Sun May 20 07:32:08 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09194
	for ; Sun, 20 May 2001 07:32:08 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA02546;
	Sun, 20 May 2001 07:26:14 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA14787
	for megaco-list; Sun, 20 May 2001 07:19:05 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA14777
	for ; Sun, 20 May 2001 07:19:03 -0400 (EDT)
From: jk8@catweb_svr.labos.polymtl.ca
Received: from catweb_svr.labos.polymtl.ca (catweb_svr.labos.polymtl.ca [132.207.66.40])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA02386
	for ; Sun, 20 May 2001 07:19:02 -0400 (EDT)
Received: from catweb_svr.labos.polymtl.ca (ip179.las-vegas14.nv.pub-ip.psi.net [38.29.114.179]) by catweb_svr.labos.polymtl.ca (AIX4.3/UCB 8.8.8/8.8.8) with SMTP id HAA23856; Sun, 20 May 2001 07:08:53 -0400
Message-Id: <200105201108.HAA23856@catweb_svr.labos.polymtl.ca>
Received: from sorley2@minster.ca by judso@sesto.ca (8.8.5/8.6.5) with SMTP id GAA02427 for ; Sat, 19 May 2001 04:14:38 -0600 (EST)
To: judso.sesto.ca@catweb_svr.labos.polymtl.ca
Date: Sat, 19 May 01 04:14:38 EST
Subject: hi
Reply-To: sorley2@minster.ca
Comments: Authenticated sender is 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Like to gamble?  Then come to the number 1 rated online casino
on the Interenet!  This is the casino that you saw on CNN that
directly challenged Las Vegas!

Play for fun or play for money.  Free $20 in chips with
your initial deposit.

http://63.167.32.245/members8/acesup/download.html


To be removed go to:  http://www.websurfking.net/homewealth/remove.html



From owner-megaco@fore.com  Sun May 20 10:26:50 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10647
	for ; Sun, 20 May 2001 10:26:49 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04480;
	Sun, 20 May 2001 10:17:50 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA19283
	for megaco-list; Sun, 20 May 2001 10:16:28 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19279
	for ; Sun, 20 May 2001 10:16:26 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA04401
	for ; Sun, 20 May 2001 10:16:24 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id KAA17048; Sun, 20 May 2001 10:16:18 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Sun, 20 May 2001 10:16:21 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Sun, 20 May 2001 10:16:24 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB7E@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Dave Sclarsky'" ,
        "'Rosen, Brian'" ,
        "'Troy Cauble'" 
Cc: "'knayar@hss.hns.com'" , megaco@fore.com
Subject: RE: Polls of MGC
Date: Sun, 20 May 2001 10:16:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E137.7268B710"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E137.7268B710
Content-Type: text/plain;
	charset="ISO-8859-1"

If PSTN standards are used, failure of MGCs will be a rare event, and a
failure of any significant extent in the US will have to be reported to the
FCC.  Let's be realistic here.  I like Kevin's proposal of MGC-initiated
polling -- it keeps control of the process where it belongs.

> -----Original Message-----
> From: Dave Sclarsky [mailto:Dave.Sclarsky@radisys.com]
> Sent: Friday, May 18, 2001 1:18 PM
> To: 'Rosen, Brian'; 'Troy Cauble'
> Cc: 'knayar@hss.hns.com'; megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> Brian,
> We cannot let the MGs wait until they need to send something 
> before learning
> that an MGC went down.  You could have a ResGW disconnected 
> from the network
> all night!  What if Johnny at college needs to call home at 
> 3am to bail him
> out of jail?  Dad's controlling MGC won't be able to make his 
> phone ring
> because Dad hasn't made a call since the MGC restarted!  I 
> guess if you're
> Johnny's dad this is a good thing :-)
> 
> DaveS.
> 
> 

------_=_NextPart_001_01C0E137.7268B710
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Polls of MGC




If PSTN standards are used, failure of MGCs will be a =
rare event, and a failure of any significant extent in the US will have =
to be reported to the FCC.  Let's be realistic here.  I like =
Kevin's proposal of MGC-initiated polling -- it keeps control of the =
process where it belongs.



> -----Original Message-----

> From: Dave Sclarsky [mailto:Dave.Sclarsky@radisys.c=
om]

> Sent: Friday, May 18, 2001 1:18 PM

> To: 'Rosen, Brian'; 'Troy Cauble'

> Cc: 'knayar@hss.hns.com'; =
megaco@fore.com

> Subject: RE: Polls of MGC

> 

> 

> Brian,

> We cannot let the MGs wait until they need to =
send something 

> before learning

> that an MGC went down.  You could have a =
ResGW disconnected 

> from the network

> all night!  What if Johnny at college =
needs to call home at 

> 3am to bail him

> out of jail?  Dad's controlling MGC won't =
be able to make his 

> phone ring

> because Dad hasn't made a call since the MGC =
restarted!  I 

> guess if you're

> Johnny's dad this is a good thing :-)

> 

> DaveS.

> 

> 





------_=_NextPart_001_01C0E137.7268B710--


From owner-megaco@fore.com  Sun May 20 10:27:40 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10661
	for ; Sun, 20 May 2001 10:27:40 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04655;
	Sun, 20 May 2001 10:20:51 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA19384
	for megaco-list; Sun, 20 May 2001 10:20:18 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19378
	for ; Sun, 20 May 2001 10:20:16 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA04584
	for ; Sun, 20 May 2001 10:20:14 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id KAA17081; Sun, 20 May 2001 10:20:08 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Sun, 20 May 2001 10:20:11 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Sun, 20 May 2001 10:20:14 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB7F@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Rosen, Brian'" ,
        "'Dave Sclarsky'" ,
        "'Troy Cauble'" 
Cc: "'knayar@hss.hns.com'" , megaco@fore.com
Subject: RE: Polls of MGC
Date: Sun, 20 May 2001 10:20:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E137.FC2DE150"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E137.FC2DE150
Content-Type: text/plain;
	charset="ISO-8859-1"

If you're determined on this, you can prevent interaction problems by
defining an abstract termination other than ROOT whose job it is to report
the poll event.  I really don't buy the neutering of the RESTART method. 

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Friday, May 18, 2001 1:29 PM
> To: 'Dave Sclarsky'; 'Troy Cauble'
> Cc: 'knayar@hss.hns.com'; megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> Right.  I just replied to another version of this and forgot the
> point that Johnnies MGC will figure out that Dad's MGC is down,
> and that can be fixed, but Dad's MG won't register with the
> replacement MGC because it doesn't know (yet) to do so. 
> 
> See that message for options.  The package will work, I think,
> pretty well (modulo the worry about signals).  So will the
> profile defined no-op SC method, and declaring restart of an 
> up termination to be a no-op.  It occurs to me that we could
> make this more palateable by saying a gracefull restart of an
> up termination with a time of -1 was defined to be a no-op.
> 
> Brian
> 
> 

------_=_NextPart_001_01C0E137.FC2DE150
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Polls of MGC




If you're determined on this, you can prevent =
interaction problems by defining an abstract termination other than =
ROOT whose job it is to report the poll event.  I really don't buy =
the neutering of the RESTART method. 



> -----Original Message-----

> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]

> Sent: Friday, May 18, 2001 1:29 PM

> To: 'Dave Sclarsky'; 'Troy Cauble'

> Cc: 'knayar@hss.hns.com'; =
megaco@fore.com

> Subject: RE: Polls of MGC

> 

> 

> Right.  I just replied to another version =
of this and forgot the

> point that Johnnies MGC will figure out that =
Dad's MGC is down,

> and that can be fixed, but Dad's MG won't =
register with the

> replacement MGC because it doesn't know (yet) =
to do so. 

> 

> See that message for options.  The package =
will work, I think,

> pretty well (modulo the worry about =
signals).  So will the

> profile defined no-op SC method, and declaring =
restart of an 

> up termination to be a no-op.  It occurs =
to me that we could

> make this more palateable by saying a gracefull =
restart of an

> up termination with a time of -1 was defined to =
be a no-op.

> 

> Brian

> 

> 





------_=_NextPart_001_01C0E137.FC2DE150--


From owner-megaco@fore.com  Sun May 20 10:28:40 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10676
	for ; Sun, 20 May 2001 10:28:40 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04828;
	Sun, 20 May 2001 10:23:10 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA19452
	for megaco-list; Sun, 20 May 2001 10:22:28 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19444
	for ; Sun, 20 May 2001 10:22:26 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA04731
	for ; Sun, 20 May 2001 10:22:24 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id KAA17124; Sun, 20 May 2001 10:22:18 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Sun, 20 May 2001 10:22:23 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Sun, 20 May 2001 10:22:24 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB80@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Rosen, Brian'" ,
        "'rezhirpavai@hss.hns.com'" 
Cc: "'Dan Elbert'" ,
        "'megaco@fore.com'" 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Sun, 20 May 2001 10:22:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E138.49A80460"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E138.49A80460
Content-Type: text/plain;
	charset="ISO-8859-1"

The MGC could use GRACEFUL if the termination is an outgoing trunk which a
craftsperson at the MGC has seized.  The idea would be to give time for any
existing call to terminate, while preventing additional calls from being
assigned to the trunk.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Friday, May 18, 2001 1:39 PM
> To: 'rezhirpavai@hss.hns.com'
> Cc: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Dan Elbert'; 'megaco@fore.com'
> Subject: RE: Use of ServiceChange from MGC to MG
> 
> 
> I said that - the MGC does the Subtract explicitly; just
> taking the termination out of service DOES NOT implicitly do
> a Subtract.  If you are arguing about the order of operations,
> I would recommend the Subtract before the ServiceChange.
> 
> The usual drill for the MGC is first to subtract, then serviceChange
> forced.  There really isn't any reason for the MGC to use Graceful.
> 
> The usual drill for the MG is to send Graceful, the MGC responds
> with Subtract, then the MG makes the terminations out of
> service after the subtract or at the latest, after the timeout.
> 
> A forced Restart on Root should happen immediately.
> 
> Brian
> 

------_=_NextPart_001_01C0E138.49A80460
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Use of ServiceChange from MGC to MG




The MGC could use GRACEFUL if the termination is an =
outgoing trunk which a craftsperson at the MGC has seized.  The =
idea would be to give time for any existing call to terminate, while =
preventing additional calls from being assigned to the =
trunk.



> -----Original Message-----

> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]

> Sent: Friday, May 18, 2001 1:39 PM

> To: 'rezhirpavai@hss.hns.com'

> Cc: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Dan =
Elbert'; 'megaco@fore.com'

> Subject: RE: Use of ServiceChange from MGC to =
MG

> 

> 

> I said that - the MGC does the Subtract =
explicitly; just

> taking the termination out of service DOES NOT =
implicitly do

> a Subtract.  If you are arguing about the =
order of operations,

> I would recommend the Subtract before the =
ServiceChange.

> 

> The usual drill for the MGC is first to =
subtract, then serviceChange

> forced.  There really isn't any reason for =
the MGC to use Graceful.

> 

> The usual drill for the MG is to send Graceful, =
the MGC responds

> with Subtract, then the MG makes the =
terminations out of

> service after the subtract or at the latest, =
after the timeout.

> 

> A forced Restart on Root should happen =
immediately.

> 

> Brian

> 





------_=_NextPart_001_01C0E138.49A80460--


From owner-megaco@fore.com  Sun May 20 10:34:22 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10730
	for ; Sun, 20 May 2001 10:34:21 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA05035;
	Sun, 20 May 2001 10:26:24 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA19590
	for megaco-list; Sun, 20 May 2001 10:25:45 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19582
	for ; Sun, 20 May 2001 10:25:43 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA04954
	for ; Sun, 20 May 2001 10:25:41 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id KAA17156; Sun, 20 May 2001 10:25:35 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Sun, 20 May 2001 10:25:38 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Sun, 20 May 2001 10:25:41 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB81@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Madhu Babu Brahmanapally'" ,
        "'Rosen, Brian'" ,
        rezhirpavai 
Cc: "'Dan Elbert'" , megaco 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Sun, 20 May 2001 10:25:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E138.BE065C80"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E138.BE065C80
Content-Type: text/plain;
	charset="ISO-8859-1"

I think it is legitimate for the MGC to force an MG to do a restart, and the
logical way to do it is through the SC on ROOT.

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Friday, May 18, 2001 2:22 PM
> To: 'Rosen, Brian'; rezhirpavai
> Cc: 'Dan Elbert'; megaco
> Subject: RE: Use of ServiceChange from MGC to MG
> 
> 
> There is no mention of this "unregistration" from the MGC in 
> the protocol.
> The protocol only address ServiceChange with ROOT termination 
> ID as a means
> of MG registering with the MGC but not the other way round. I 
> was in the
> impression that it is possible according to the grammar but 
> nothing like
> "un-registration" exists. (I'm not sure whether every one has 
> the common
> understanding of this "un-registration")
> 
> Regards
> Madhubabu
> 
> 

------_=_NextPart_001_01C0E138.BE065C80
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Use of ServiceChange from MGC to MG




I think it is legitimate for the MGC to force an MG =
to do a restart, and the logical way to do it is through the SC on =
ROOT.



> -----Original Message-----

> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]<=
/FONT>

> Sent: Friday, May 18, 2001 2:22 PM

> To: 'Rosen, Brian'; rezhirpavai

> Cc: 'Dan Elbert'; megaco

> Subject: RE: Use of ServiceChange from MGC to =
MG

> 

> 

> There is no mention of this =
"unregistration" from the MGC in 

> the protocol.

> The protocol only address ServiceChange with =
ROOT termination 

> ID as a means

> of MG registering with the MGC but not the =
other way round. I 

> was in the

> impression that it is possible according to the =
grammar but 

> nothing like

> "un-registration" exists. (I'm not =
sure whether every one has 

> the common

> understanding of this =
"un-registration")

> 

> Regards

> Madhubabu

> 

> 





------_=_NextPart_001_01C0E138.BE065C80--


From owner-megaco@fore.com  Sun May 20 10:43:22 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10796
	for ; Sun, 20 May 2001 10:43:22 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA05355;
	Sun, 20 May 2001 10:37:10 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA19868
	for megaco-list; Sun, 20 May 2001 10:36:34 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19864
	for ; Sun, 20 May 2001 10:36:33 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA05262
	for ; Sun, 20 May 2001 10:36:31 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id KAA17293; Sun, 20 May 2001 10:36:25 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Sun, 20 May 2001 10:36:30 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Sun, 20 May 2001 10:36:31 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB82@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'YouLing Sha'" ,
        "'megaco@fore.com'" 
Subject: RE: If resource of a termination is busy on a Non-Megaco call, wh at 
         should MG do ?
Date: Sun, 20 May 2001 10:36:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E13A.41CCAFA0"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E13A.41CCAFA0
Content-Type: text/plain;
	charset="ISO-8859-1"

First observation: this mode of operation breaks the assumptions upon which
Megaco/H.248 is based: that each resource is controlled by only one virtual
MG.  In this case, the GR-303 connection is equivalent to a second virtual
MG competing with the one seen by the IP side MGC.

In this case, the best I could suggest is 503 Service Unavailable.  You
could also try 530 Temporary Network Failure.

> -----Original Message-----
> From: YouLing Sha [mailto:ysha@cpmail.cyberpathinc.com]
> Sent: Friday, May 18, 2001 3:34 PM
> To: 'megaco@fore.com'
> Subject: If resource of a termination is busy on a Non-Megaco 
> call, what
> should MG do ?
> 
> 
> Hi,
> 
> If a residentail gateway has a group of subscribers 
> provisioned on the access side; 
> and on the network side, it has GR-303 to the PSTN and Megaco 
> to IP. The calls made 
> by the subscribers from the access side can be routed to PSTN 
> (using GR-303 not Megaco) 
> or IP (using Megaco) based on some pre-defined routing 
> creteria (say time based, 
> digit based, or resource based).  
> 
> In MEGACO environment. MGC is the master and MG behaves as a slave.
> Assuming the gateway has a subscriber (say A). Now if "A" is 
> busy with a GR-303 
> call to the PSTN (not going through the Megaco/MG on the gateway), 
> and the MGC being unaware of it, sends an incoming call 
> request to the gateway for "A", 
> then the call has to be rejected because A is actually busy. 
> 
> The questions are:
> 
> 1. What could be the error cause so that we could avoid any 
> audit triggering
> from the MGC. Because the audit correction might be termination out of
> service or hook status change?
> 2. Could we make the Termination Out of service temporarily 
> (during the
> period it's in a call with some other interface)  by sending a Service
> change to the MGC so that no incoming call request will come from MGC?
> 
> Your advise is highly appreciated.
> 
> Regards,
> YouLing Sha
> 
> 

------_=_NextPart_001_01C0E13A.41CCAFA0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: If resource of a termination is busy on a Non-Megaco call, =
what should  MG do ?




First observation: this mode of operation breaks the =
assumptions upon which Megaco/H.248 is based: that each resource is =
controlled by only one virtual MG.  In this case, the GR-303 =
connection is equivalent to a second virtual MG competing with the one =
seen by the IP side MGC.



In this case, the best I could suggest is 503 Service =
Unavailable.  You could also try 530 Temporary Network =
Failure.




> -----Original Message-----

> From: YouLing Sha [mailto:ysha@cpmail.cyberpat=
hinc.com]

> Sent: Friday, May 18, 2001 3:34 PM

> To: 'megaco@fore.com'

> Subject: If resource of a termination is busy =
on a Non-Megaco 

> call, what

> should MG do ?

> 

> 

> Hi,

> 

> If a residentail gateway has a group of =
subscribers 

> provisioned on the access side; 

> and on the network side, it has GR-303 to the =
PSTN and Megaco 

> to IP. The calls made 

> by the subscribers from the access side can be =
routed to PSTN 

> (using GR-303 not Megaco) 

> or IP (using Megaco) based on some pre-defined =
routing 

> creteria (say time based, 

> digit based, or resource based).  

> 

> In MEGACO environment. MGC is the master and MG =
behaves as a slave.

> Assuming the gateway has a subscriber (say A). =
Now if "A" is 

> busy with a GR-303 

> call to the PSTN (not going through the =
Megaco/MG on the gateway), 

> and the MGC being unaware of it, sends an =
incoming call 

> request to the gateway for "A", =


> then the call has to be rejected because A is =
actually busy. 

> 

> The questions are:

> 

> 1. What could be the error cause so that we =
could avoid any 

> audit triggering

> from the MGC. Because the audit correction =
might be termination out of

> service or hook status change?

> 2. Could we make the Termination Out of service =
temporarily 

> (during the

> period it's in a call with some other =
interface)  by sending a Service

> change to the MGC so that no incoming call =
request will come from MGC?

> 

> Your advise is highly appreciated.

> 

> Regards,

> YouLing Sha

> 

> 





------_=_NextPart_001_01C0E13A.41CCAFA0--


From owner-megaco@fore.com  Sun May 20 10:47:01 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10822
	for ; Sun, 20 May 2001 10:47:00 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA05568;
	Sun, 20 May 2001 10:40:54 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA20008
	for megaco-list; Sun, 20 May 2001 10:40:22 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20004
	for ; Sun, 20 May 2001 10:40:21 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA05493
	for ; Sun, 20 May 2001 10:40:19 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id KAA17319; Sun, 20 May 2001 10:40:13 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Sun, 20 May 2001 10:40:03 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Sun, 20 May 2001 10:40:05 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB83@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'rezhirpavai@hss.hns.com'" ,
        Madhu Babu Brahmanapally 
Cc: "Kevin Boyle" ,
        "'Rosen, Brian'" ,
        "'Dan Elbert'" , megaco@fore.com
Subject: RE: Use of ServiceChange from MGC to MG
Date: Sun, 20 May 2001 10:40:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E13A.C22521A0"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E13A.C22521A0
Content-Type: text/plain;
	charset="ISO-8859-1"

I didn't realize the media flow stops on receipt on ServiceChange.  Where
does it say that in the spec?

> -----Original Message-----
> From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
> Sent: Friday, May 18, 2001 4:11 PM
> To: Madhu Babu Brahmanapally
> Cc: Boyle, Kevin [NCRTP:3Z70:EXCH]; 'Rosen, Brian'; Taylor, Tom-PT
> [NORSE:B881:EXCH]; 'Dan Elbert'; megaco@fore.com
> Subject: RE: Use of ServiceChange from MGC to MG
> 
> 
> 
> 
> Hello,
>      If the media flow is stopped on receiving the SC, then 
> why should it remain
> in context? What is achieved by keeping it in context, though 
> call is not going
> on?
> If it is just for stats information, why can't we add stats 
> descriptor in
> service change reply and in this way the MG would reply 
> positively for the SC
> and at the same time delete the context too without an 
> explict subtract command.
> 
>                                          Regards,
>                                          R. Ezhirpavai
> 

------_=_NextPart_001_01C0E13A.C22521A0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Use of ServiceChange from MGC to MG




I didn't realize the media flow stops on receipt on =
ServiceChange.  Where does it say that in the spec?




> -----Original Message-----

> From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]

> Sent: Friday, May 18, 2001 4:11 PM

> To: Madhu Babu Brahmanapally

> Cc: Boyle, Kevin [NCRTP:3Z70:EXCH]; 'Rosen, =
Brian'; Taylor, Tom-PT

> [NORSE:B881:EXCH]; 'Dan Elbert'; =
megaco@fore.com

> Subject: RE: Use of ServiceChange from MGC to =
MG

> 

> 

> 

> 

> Hello,

>      If the media flow =
is stopped on receiving the SC, then 

> why should it remain

> in context? What is achieved by keeping it in =
context, though 

> call is not going

> on?

> If it is just for stats information, why can't =
we add stats 

> descriptor in

> service change reply and in this way the MG =
would reply 

> positively for the SC

> and at the same time delete the context too =
without an 

> explict subtract command.

> 

>          =
;            =
;            =
;        Regards,

>          =
;            =
;            =
;        R. Ezhirpavai

> 





------_=_NextPart_001_01C0E13A.C22521A0--


From owner-megaco@fore.com  Sun May 20 10:51:15 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10851
	for ; Sun, 20 May 2001 10:51:15 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA05761;
	Sun, 20 May 2001 10:44:01 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA20114
	for megaco-list; Sun, 20 May 2001 10:43:27 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20108
	for ; Sun, 20 May 2001 10:43:26 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA05688
	for ; Sun, 20 May 2001 10:43:24 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id KAA17361; Sun, 20 May 2001 10:43:18 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Sun, 20 May 2001 10:43:21 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Sun, 20 May 2001 10:43:24 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB84@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Dan Elbert'" ,
        "'megaco@fore.com'" 
Subject: RE: SVC of termination
Date: Sun, 20 May 2001 10:43:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E13B.37BE43B0"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E13B.37BE43B0
Content-Type: text/plain;
	charset="ISO-8859-1"

It is an error.  The MGC could either ignore it or reply with error 504
Command Received From Unauthorized Entity.

> -----Original Message-----
> From: Dan Elbert [mailto:DElbert@radvision.com]
> Sent: Friday, May 18, 2001 4:24 PM
> To: 'megaco@fore.com'
> Subject: SVC of termination
> 
> 
> Hi
> 
> If an MGC receives a SVC with restart method from a 
> particular termination
> of some MG before receiving the SVC from the root termination 
> of the same
> MG, is this an error ? If so, what is the error code that the 
> MGC should
> return ?
> 
> Thanks,
> 
> Dan Elbert
> RADVISION
> 

------_=_NextPart_001_01C0E13B.37BE43B0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: SVC of termination




It is an error.  The MGC could either ignore it =
or reply with error 504 Command Received From Unauthorized =
Entity.




> -----Original Message-----

> From: Dan Elbert [mailto:DElbert@radvision.com]<=
/FONT>

> Sent: Friday, May 18, 2001 4:24 PM

> To: 'megaco@fore.com'

> Subject: SVC of termination

> 

> 

> Hi

> 

> If an MGC receives a SVC with restart method =
from a 

> particular termination

> of some MG before receiving the SVC from the =
root termination 

> of the same

> MG, is this an error ? If so, what is the error =
code that the 

> MGC should

> return ?

> 

> Thanks,

> 

> Dan Elbert

> RADVISION

> 





------_=_NextPart_001_01C0E13B.37BE43B0--


From owner-megaco@fore.com  Mon May 21 04:04:07 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03529
	for ; Mon, 21 May 2001 04:04:06 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA20291;
	Mon, 21 May 2001 03:54:39 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id DAA28217
	for megaco-list; Mon, 21 May 2001 03:50:40 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA28213
	for ; Mon, 21 May 2001 03:50:38 -0400 (EDT)
From: rezhirpavai@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA20143
	for ; Mon, 21 May 2001 03:50:35 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4L7pVr26580;
	Mon, 21 May 2001 13:21:32 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A53.0029B428 ; Mon, 21 May 2001 13:05:30 +0530
X-Lotus-FromDomain: HSS
To: "Tom-PT Taylor" 
cc: "'Rosen, Brian'" ,
        "'Dan Elbert'" ,
        "'megaco@fore.com'" 
Message-ID: <65256A53.0029ACA4.00@sandesh.hss.hns.com>
Date: Mon, 21 May 2001 12:55:57 +0530
Subject: RE: Use of ServiceChange from MGC to MG
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk



Hello Tom,
     Firstly can an MGC issue a SC with GRACEFUL?

If yes consider the actions at MG
- on receiving GRACEFUL with 0 delay for a non-ROOT termination: It needs to
wait for the call to get cleared, i.,e wait till it receives a SUBTRACT before
putting it OOS.
- on receiving FORCED for a non-ROOT termination: It still needs to wait for a
SUBTRACT, i.e wait for the call to get cleared gracefully.

Hence what is the difference between MG receiving a service change with graceful
or with forced?

                                              Regards,
                                              R. Ezhirpavai





"Tom-PT Taylor"  on 05/20/2001 07:52:23 PM

To:   "'Rosen, Brian'" , R Ezhirpavai/HSS@HSS
cc:   "'Dan Elbert'" , "'megaco@fore.com'"
      

Subject:  RE: Use of ServiceChange from MGC to MG




The MGC could use GRACEFUL if the termination is an outgoing trunk which a
craftsperson at the MGC has seized.  The idea would be to give time for any
existing call to terminate, while preventing additional calls from being
assigned to the trunk.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Friday, May 18, 2001 1:39 PM
> To: 'rezhirpavai@hss.hns.com'
> Cc: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Dan Elbert'; 'megaco@fore.com'
> Subject: RE: Use of ServiceChange from MGC to MG
>
>
> I said that - the MGC does the Subtract explicitly; just
> taking the termination out of service DOES NOT implicitly do
> a Subtract.  If you are arguing about the order of operations,
> I would recommend the Subtract before the ServiceChange.
>
> The usual drill for the MGC is first to subtract, then serviceChange
> forced.  There really isn't any reason for the MGC to use Graceful.
>
> The usual drill for the MG is to send Graceful, the MGC responds
> with Subtract, then the MG makes the terminations out of
> service after the subtract or at the latest, after the timeout.
>
> A forced Restart on Root should happen immediately.
>
> Brian
>








From owner-megaco@fore.com  Mon May 21 06:44:26 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04791
	for ; Mon, 21 May 2001 06:44:25 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA25555;
	Mon, 21 May 2001 06:38:09 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id GAA11162
	for megaco-list; Mon, 21 May 2001 06:36:28 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA11158
	for ; Mon, 21 May 2001 06:36:27 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id GAA25426
	for ; Mon, 21 May 2001 06:36:25 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id GAA01347; Mon, 21 May 2001 06:36:18 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Mon, 21 May 2001 06:36:03 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Mon, 21 May 2001 06:36:05 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CB8F@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'rezhirpavai@hss.hns.com'" 
Cc: "'Rosen, Brian'" ,
        "'Dan Elbert'" ,
        "'megaco@fore.com'" 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Mon, 21 May 2001 06:36:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E1E1.D5F8FDD0"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E1E1.D5F8FDD0
Content-Type: text/plain;
	charset="ISO-8859-1"

You're right: the only difference would be if the MGC asked for GRACEFUL
with a non-zero time delay.  I suspect the appropriate action in that case
is unspecified -- have to check the documentation.  It would be nice if that
meant "assign no new calls, but wait to set the state".

> -----Original Message-----
> From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
> Sent: Monday, May 21, 2001 3:26 AM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]
> Cc: 'Rosen, Brian'; 'Dan Elbert'; 'megaco@fore.com'
> Subject: RE: Use of ServiceChange from MGC to MG
> 
> 
> 
> 
> Hello Tom,
>      Firstly can an MGC issue a SC with GRACEFUL?
> 
> If yes consider the actions at MG
> - on receiving GRACEFUL with 0 delay for a non-ROOT 
> termination: It needs to
> wait for the call to get cleared, i.,e wait till it receives 
> a SUBTRACT before
> putting it OOS.
> - on receiving FORCED for a non-ROOT termination: It still 
> needs to wait for a
> SUBTRACT, i.e wait for the call to get cleared gracefully.
> 
> Hence what is the difference between MG receiving a service 
> change with graceful
> or with forced?
> 
>                                               Regards,
>                                               R. Ezhirpavai
> 
> 
> 
> 
> 
> "Tom-PT Taylor"  on 05/20/2001 07:52:23 PM
> 
> To:   "'Rosen, Brian'" , R Ezhirpavai/HSS@HSS
> cc:   "'Dan Elbert'" , "'megaco@fore.com'"
>       
> 
> Subject:  RE: Use of ServiceChange from MGC to MG
> 
> 
> 
> 
> The MGC could use GRACEFUL if the termination is an outgoing 
> trunk which a
> craftsperson at the MGC has seized.  The idea would be to 
> give time for any
> existing call to terminate, while preventing additional calls 
> from being
> assigned to the trunk.
> 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > Sent: Friday, May 18, 2001 1:39 PM
> > To: 'rezhirpavai@hss.hns.com'
> > Cc: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Dan Elbert'; 
> 'megaco@fore.com'
> > Subject: RE: Use of ServiceChange from MGC to MG
> >
> >
> > I said that - the MGC does the Subtract explicitly; just
> > taking the termination out of service DOES NOT implicitly do
> > a Subtract.  If you are arguing about the order of operations,
> > I would recommend the Subtract before the ServiceChange.
> >
> > The usual drill for the MGC is first to subtract, then serviceChange
> > forced.  There really isn't any reason for the MGC to use Graceful.
> >
> > The usual drill for the MG is to send Graceful, the MGC responds
> > with Subtract, then the MG makes the terminations out of
> > service after the subtract or at the latest, after the timeout.
> >
> > A forced Restart on Root should happen immediately.
> >
> > Brian
> >
> 
> 
> 
> 
> 
> 
> 

------_=_NextPart_001_01C0E1E1.D5F8FDD0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Use of ServiceChange from MGC to MG




You're right: the only difference would be if the MGC =
asked for GRACEFUL with a non-zero time delay.  I suspect the =
appropriate action in that case is unspecified -- have to check the =
documentation.  It would be nice if that meant "assign no new =
calls, but wait to set the state".



> -----Original Message-----

> From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]

> Sent: Monday, May 21, 2001 3:26 AM

> To: Taylor, Tom-PT [NORSE:B881:EXCH]

> Cc: 'Rosen, Brian'; 'Dan Elbert'; =
'megaco@fore.com'

> Subject: RE: Use of ServiceChange from MGC to =
MG

> 

> 

> 

> 

> Hello Tom,

>      Firstly can an =
MGC issue a SC with GRACEFUL?

> 

> If yes consider the actions at MG

> - on receiving GRACEFUL with 0 delay for a =
non-ROOT 

> termination: It needs to

> wait for the call to get cleared, i.,e wait =
till it receives 

> a SUBTRACT before

> putting it OOS.

> - on receiving FORCED for a non-ROOT =
termination: It still 

> needs to wait for a

> SUBTRACT, i.e wait for the call to get cleared =
gracefully.

> 

> Hence what is the difference between MG =
receiving a service 

> change with graceful

> or with forced?

> 

>          =
;            =
;            =
;            =
; Regards,

>          =
;            =
;            =
;            =
; R. Ezhirpavai

> 

> 

> 

> 

> 

> "Tom-PT Taylor" =
<taylor@nortelnetworks.com> on 05/20/2001 07:52:23 PM

> 

> To:   "'Rosen, Brian'" =
<Brian.Rosen@marconi.com>, R Ezhirpavai/HSS@HSS

> cc:   "'Dan Elbert'" =
<DElbert@radvision.com>, "'megaco@fore.com'"

>       =
<megaco@fore.com>

> 

> Subject:  RE: Use of ServiceChange from =
MGC to MG

> 

> 

> 

> 

> The MGC could use GRACEFUL if the termination =
is an outgoing 

> trunk which a

> craftsperson at the MGC has seized.  The =
idea would be to 

> give time for any

> existing call to terminate, while preventing =
additional calls 

> from being

> assigned to the trunk.

> 

> > -----Original Message-----

> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]

> > Sent: Friday, May 18, 2001 1:39 PM

> > To: 'rezhirpavai@hss.hns.com'

> > Cc: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Dan =
Elbert'; 

> 'megaco@fore.com'

> > Subject: RE: Use of ServiceChange from MGC =
to MG

> >

> >

> > I said that - the MGC does the Subtract =
explicitly; just

> > taking the termination out of service DOES =
NOT implicitly do

> > a Subtract.  If you are arguing about =
the order of operations,

> > I would recommend the Subtract before the =
ServiceChange.

> >

> > The usual drill for the MGC is first to =
subtract, then serviceChange

> > forced.  There really isn't any =
reason for the MGC to use Graceful.

> >

> > The usual drill for the MG is to send =
Graceful, the MGC responds

> > with Subtract, then the MG makes the =
terminations out of

> > service after the subtract or at the =
latest, after the timeout.

> >

> > A forced Restart on Root should happen =
immediately.

> >

> > Brian

> >

> 

> 

> 

> 

> 

> 

> 





------_=_NextPart_001_01C0E1E1.D5F8FDD0--


From owner-megaco@fore.com  Mon May 21 09:31:21 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09226
	for ; Mon, 21 May 2001 09:31:20 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA04573;
	Mon, 21 May 2001 09:23:46 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA04429
	for megaco-list; Mon, 21 May 2001 09:20:00 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA04394
	for ; Mon, 21 May 2001 09:19:56 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA04114
	for ; Mon, 21 May 2001 09:19:53 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACS26255;
	Mon, 21 May 2001 09:18:29 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Tom-PT Taylor'" , 
Cc: "'Rosen, Brian'" ,
        "'Dan Elbert'" , 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Mon, 21 May 2001 09:22:19 -0400
Message-ID: <029901c0e1f9$108bd640$c500a8c0@MBRAHMANAPALLY>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_029A_01C0E1D7.897A3640"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <28560036253BD41191A10000F8BCBD110250CB8F@zcard00g.ca.nortel.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_029A_01C0E1D7.897A3640
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: Use of ServiceChange from MGC to MGHI Tom/pavai,
The "graceful" method of SC doesn't convey additional information to
MG(except for the SC delay part of it). Tom mentioned "assign no new calls,
but wait to set the state", but it is the MGC that is aware of the calls not
MG. So what does it mean if MGC is indicating MG not to establish new
calls???

Regards
Madhubabu
  -----Original Message-----
  From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Tom-PT Taylor
  Sent: Monday, May 21, 2001 6:36 AM
  To: 'rezhirpavai@hss.hns.com'
  Cc: 'Rosen, Brian'; 'Dan Elbert'; 'megaco@fore.com'
  Subject: RE: Use of ServiceChange from MGC to MG


  You're right: the only difference would be if the MGC asked for GRACEFUL
with a non-zero time delay.  I suspect the appropriate action in that case
is unspecified -- have to check the documentation.  It would be nice if that
meant "assign no new calls, but wait to set the state".

  > -----Original Message-----
  > From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
  > Sent: Monday, May 21, 2001 3:26 AM
  > To: Taylor, Tom-PT [NORSE:B881:EXCH]
  > Cc: 'Rosen, Brian'; 'Dan Elbert'; 'megaco@fore.com'
  > Subject: RE: Use of ServiceChange from MGC to MG
  >
  >
  >
  >
  > Hello Tom,
  >      Firstly can an MGC issue a SC with GRACEFUL?
  >
  > If yes consider the actions at MG
  > - on receiving GRACEFUL with 0 delay for a non-ROOT
  > termination: It needs to
  > wait for the call to get cleared, i.,e wait till it receives
  > a SUBTRACT before
  > putting it OOS.
  > - on receiving FORCED for a non-ROOT termination: It still
  > needs to wait for a
  > SUBTRACT, i.e wait for the call to get cleared gracefully.
  >
  > Hence what is the difference between MG receiving a service
  > change with graceful
  > or with forced?
  >
  >                                               Regards,
  >                                               R. Ezhirpavai
  >
  >
  >
  >
  >
  > "Tom-PT Taylor"  on 05/20/2001 07:52:23 PM
  >
  > To:   "'Rosen, Brian'" , R Ezhirpavai/HSS@HSS
  > cc:   "'Dan Elbert'" , "'megaco@fore.com'"
  >       
  >
  > Subject:  RE: Use of ServiceChange from MGC to MG
  >
  >
  >
  >
  > The MGC could use GRACEFUL if the termination is an outgoing
  > trunk which a
  > craftsperson at the MGC has seized.  The idea would be to
  > give time for any
  > existing call to terminate, while preventing additional calls
  > from being
  > assigned to the trunk.
  >
  > > -----Original Message-----
  > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
  > > Sent: Friday, May 18, 2001 1:39 PM
  > > To: 'rezhirpavai@hss.hns.com'
  > > Cc: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Dan Elbert';
  > 'megaco@fore.com'
  > > Subject: RE: Use of ServiceChange from MGC to MG
  > >
  > >
  > > I said that - the MGC does the Subtract explicitly; just
  > > taking the termination out of service DOES NOT implicitly do
  > > a Subtract.  If you are arguing about the order of operations,
  > > I would recommend the Subtract before the ServiceChange.
  > >
  > > The usual drill for the MGC is first to subtract, then serviceChange
  > > forced.  There really isn't any reason for the MGC to use Graceful.
  > >
  > > The usual drill for the MG is to send Graceful, the MGC responds
  > > with Subtract, then the MG makes the terminations out of
  > > service after the subtract or at the latest, after the timeout.
  > >
  > > A forced Restart on Root should happen immediately.
  > >
  > > Brian
  > >
  >
  >
  >
  >
  >
  >
  >


------=_NextPart_000_029A_01C0E1D7.897A3640
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




RE: Use of ServiceChange from MGC to MG




HI=20
Tom/pavai,


The=20
"graceful" method of SC doesn't convey additional information to =
MG(except for=20
the SC delay part of it). Tom mentioned "assign no new calls, but wait =
to set=20
the state", but it is the MGC that is aware of the calls not MG. So what =
does it=20
mean if MGC is indicating MG not to establish new =
calls???


 


Regards


Madhubabu



  
-----Original Message-----
From:=20
  owner-megaco@pit.comms.marconi.com=20
  [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Tom-PT=20
  Taylor
Sent: Monday, May 21, 2001 6:36 AM
To:=20
  'rezhirpavai@hss.hns.com'
Cc: 'Rosen, Brian'; 'Dan Elbert';=20
  'megaco@fore.com'
Subject: RE: Use of ServiceChange from MGC =
to=20
  MG


  
You're right: the only difference would be if the =
MGC asked=20
  for GRACEFUL with a non-zero time delay.  I suspect the =
appropriate=20
  action in that case is unspecified -- have to check the =
documentation. =20
  It would be nice if that meant "assign no new calls, but wait to set =
the=20
  state".

  
> -----Original Message----- 
>=20
  From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]=20
  
> Sent: Monday, May 21, 2001 3:26 AM =

> To: Taylor, Tom-PT [NORSE:B881:EXCH] 
>=20
  Cc: 'Rosen, Brian'; 'Dan Elbert'; 'megaco@fore.com' 
> Subject: RE: Use of ServiceChange from MGC to MG =

> 
> 
>=20
  
> 
> Hello =
Tom,=20
  
>      Firstly can an =
MGC issue a=20
  SC with GRACEFUL? 
> 
> If=20
  yes consider the actions at MG 
> - on =
receiving=20
  GRACEFUL with 0 delay for a non-ROOT 
> =
termination:=20
  It needs to 
> wait for the call to get =
cleared,=20
  i.,e wait till it receives 
> a SUBTRACT=20
  before 
> putting it OOS. 
> - on receiving FORCED for a non-ROOT termination: It =
still=20
  
> needs to wait for a 
>=20
  SUBTRACT, i.e wait for the call to get cleared gracefully. =

> 
> Hence what is the =
difference between=20
  MG receiving a service 
> change with=20
  graceful 
> or with forced? =

> 
>          =
            &=
nbsp;           &n=
bsp;           =20
  Regards, 
>          =
            &=
nbsp;           &n=
bsp;           =20
  R. Ezhirpavai 
> 
>=20
  
> 
> =

> 
> "Tom-PT Taylor"=20
  <taylor@nortelnetworks.com> on 05/20/2001 07:52:23 PM =

> 
> To:   "'Rosen, =
Brian'"=20
  <Brian.Rosen@marconi.com>, R Ezhirpavai/HSS@HSS 
> cc:   "'Dan Elbert'" =
<DElbert@radvision.com>,=20
  "'megaco@fore.com'" 
>       =
<megaco@fore.com>=20
  
> 
> Subject:  =
RE: Use of=20
  ServiceChange from MGC to MG 
> =

> 
> 
>=20
  
> The MGC could use GRACEFUL if the =
termination is=20
  an outgoing 
> trunk which a =

> craftsperson at the MGC has seized.  The idea would =
be to=20
  
> give time for any 
>=20
  existing call to terminate, while preventing additional calls =

> from being 
> assigned to =
the=20
  trunk. 
> 
> =
>=20
  -----Original Message----- 
> > From: =
Rosen,=20
  Brian [mailto:Brian.Rosen@marconi.com]=20
  
> > Sent: Friday, May 18, 2001 1:39 PM =

> > To: 'rezhirpavai@hss.hns.com' 
>=20
  > Cc: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Dan Elbert'; =

> 'megaco@fore.com' 
> > =
Subject: RE:=20
  Use of ServiceChange from MGC to MG 
> =
>=20
  
> > 
> > I =
said that - the=20
  MGC does the Subtract explicitly; just 
> =
>=20
  taking the termination out of service DOES NOT implicitly do =

> > a Subtract.  If you are arguing about the =
order of=20
  operations, 
> > I would recommend the =
Subtract=20
  before the ServiceChange. 
> > =

> > The usual drill for the MGC is first to subtract, =
then=20
  serviceChange 
> > forced.  There =
really=20
  isn't any reason for the MGC to use Graceful. 
>=20
  > 
> > The usual drill for the MG is =
to send=20
  Graceful, the MGC responds 
> > with =
Subtract,=20
  then the MG makes the terminations out of 
> >=20
  service after the subtract or at the latest, after the timeout. =

  
> > 
> > A =
forced Restart=20
  on Root should happen immediately. 
> =
>=20
  
> > Brian 
> =
>=20
  
> 
> =

> 
> 
>=20
  
> 
>=20



------=_NextPart_000_029A_01C0E1D7.897A3640--



From owner-megaco@fore.com  Mon May 21 09:42:15 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09379
	for ; Mon, 21 May 2001 09:42:15 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05867;
	Mon, 21 May 2001 09:35:05 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA08681
	for megaco-list; Mon, 21 May 2001 09:34:09 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA08666
	for ; Mon, 21 May 2001 09:34:07 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05716
	for ; Mon, 21 May 2001 09:34:04 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACS26478;
	Mon, 21 May 2001 09:32:46 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Tom-PT Taylor'" , 
Cc: "'Kevin Boyle'" ,
        "'Rosen, Brian'" ,
        "'Dan Elbert'" , 
Subject: RE: Use of ServiceChange from MGC to MG
Date: Mon, 21 May 2001 09:36:36 -0400
Message-ID: <02a001c0e1fb$0f621160$c500a8c0@MBRAHMANAPALLY>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_02A1_01C0E1D9.88507160"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <28560036253BD41191A10000F8BCBD110250CB83@zcard00g.ca.nortel.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_02A1_01C0E1D9.88507160
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: Use of ServiceChange from MGC to MGHI All,
If the MGC/MG generates a SC "forced" on a termination, how can media flow
continue even if we say the termination is in out-of-service??? (IMO then
out-of-service doesn't have any meaning). As Tom Mentioned the protocol
explicitly should say about this.

Regards
Madhubabu
  -----Original Message-----
  From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
  Sent: Sunday, May 20, 2001 10:40 AM
  To: 'rezhirpavai@hss.hns.com'; Madhu Babu Brahmanapally
  Cc: Kevin Boyle; 'Rosen, Brian'; 'Dan Elbert'; megaco@fore.com
  Subject: RE: Use of ServiceChange from MGC to MG


  I didn't realize the media flow stops on receipt on ServiceChange.  Where
does it say that in the spec?

  > -----Original Message-----
  > From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
  > Sent: Friday, May 18, 2001 4:11 PM
  > To: Madhu Babu Brahmanapally
  > Cc: Boyle, Kevin [NCRTP:3Z70:EXCH]; 'Rosen, Brian'; Taylor, Tom-PT
  > [NORSE:B881:EXCH]; 'Dan Elbert'; megaco@fore.com
  > Subject: RE: Use of ServiceChange from MGC to MG
  >
  >
  >
  >
  > Hello,
  >      If the media flow is stopped on receiving the SC, then
  > why should it remain
  > in context? What is achieved by keeping it in context, though
  > call is not going
  > on?
  > If it is just for stats information, why can't we add stats
  > descriptor in
  > service change reply and in this way the MG would reply
  > positively for the SC
  > and at the same time delete the context too without an
  > explict subtract command.
  >
  >                                          Regards,
  >                                          R. Ezhirpavai
  >


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




RE: Use of ServiceChange from MGC to MG




HI=20
All,


If the=20
MGC/MG generates a SC "forced" on a termination, how can media flow =
continue=20
even if we say the termination is in out-of-service??? (IMO then =
out-of-service=20
doesn't have any meaning). As Tom Mentioned the protocol explicitly =
should say=20
about this.


 


Regards


Madhubabu



  
-----Original Message-----
From: Tom-PT Taylor=20
  [mailto:taylor@nortelnetworks.com]
Sent: Sunday, May 20, =
2001 10:40=20
  AM
To: 'rezhirpavai@hss.hns.com'; Madhu Babu=20
  Brahmanapally
Cc: Kevin Boyle; 'Rosen, Brian'; 'Dan Elbert'; =

  megaco@fore.com
Subject: RE: Use of ServiceChange from MGC =
to=20
  MG


  
I didn't realize the media flow stops on receipt on=20
  ServiceChange.  Where does it say that in the spec? 

  
> -----Original Message----- 
>=20
  From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]=20
  
> Sent: Friday, May 18, 2001 4:11 PM =

> To: Madhu Babu Brahmanapally 
> Cc:=20
  Boyle, Kevin [NCRTP:3Z70:EXCH]; 'Rosen, Brian'; Taylor, Tom-PT=20
  
> [NORSE:B881:EXCH]; 'Dan Elbert'; =
megaco@fore.com=20
  
> Subject: RE: Use of ServiceChange from MGC to =
MG=20
  
> 
> =

> 
> 
>=20
  Hello, 
>      If =
the media=20
  flow is stopped on receiving the SC, then 
> why=20
  should it remain 
> in context? What is =
achieved by=20
  keeping it in context, though 
> call is =
not=20
  going 
> on? 
> If it is=20
  just for stats information, why can't we add stats 
> descriptor in 
> service =
change reply=20
  and in this way the MG would reply 
> =
positively for=20
  the SC 
> and at the same time delete the =
context=20
  too without an 
> explict subtract =
command.=20
  
> 
>          =
            &=
nbsp;           &n=
bsp;      =20
  Regards, 
>          =
            &=
nbsp;           &n=
bsp;      =20
  R. Ezhirpavai 
>=20



------=_NextPart_000_02A1_01C0E1D9.88507160--



From owner-megaco@fore.com  Mon May 21 10:23:10 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10247
	for ; Mon, 21 May 2001 10:23:05 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10102;
	Mon, 21 May 2001 10:15:06 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA20741
	for megaco-list; Mon, 21 May 2001 10:14:17 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20682
	for ; Mon, 21 May 2001 10:14:10 -0400 (EDT)
From: rezhirpavai@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA09729
	for ; Mon, 21 May 2001 10:12:06 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4LEA7Y13272;
	Mon, 21 May 2001 19:40:07 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A53.004C5E11 ; Mon, 21 May 2001 19:24:08 +0530
X-Lotus-FromDomain: HSS
To: "Madhu Babu Brahmanapally" 
cc: "'Tom-PT Taylor'" ,
        "'Rosen, Brian'" ,
        "'Dan Elbert'" , megaco@fore.com
Message-ID: <65256A53.004C3D44.00@sandesh.hss.hns.com>
Date: Mon, 21 May 2001 19:21:39 +0530
Subject: RE: Use of ServiceChange from MGC to MG
Mime-Version: 1.0
Content-type: multipart/mixed;
	Boundary="0__=bLnpfyNUeMtdEhhjxjObDQibXRIuTQ3beJbj8JSZWlULkfvsRyvi5EmD"
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

--0__=bLnpfyNUeMtdEhhjxjObDQibXRIuTQ3beJbj8JSZWlULkfvsRyvi5EmD
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Hello,
     IMO, MG definitely needs to know about the termination state. Consider MGC
sends an Add with a partial choose as trunk1/$. So the MG would be required to
choose a free SCN termination whose termination name startes with trunk1/. Thus
if MGC requires that trunk1/2 should never be put in a call, MGC can restrict it
by sending SC.

     But since MGC is the controller of the call, IMHO, MGC should be restricted
to send SC with forced once the active call is cleared.

                                         Regards,
                                         R. Ezhirpavai





"Madhu Babu Brahmanapally"  on 05/21/2001 06:52:19 PM

To:   "'Tom-PT Taylor'" , R Ezhirpavai/HSS@HSS
cc:   "'Rosen, Brian'" , "'Dan Elbert'"
      , megaco@fore.com

Subject:  RE: Use of ServiceChange from MGC to MG




RE: Use of ServiceChange from MGC to MGHI Tom/pavai,
The "graceful" method of SC doesn't convey additional information to
MG(except for the SC delay part of it). Tom mentioned "assign no new calls,
but wait to set the state", but it is the MGC that is aware of the calls not
MG. So what does it mean if MGC is indicating MG not to establish new
calls???

Regards
Madhubabu
  -----Original Message-----
  From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Tom-PT Taylor
  Sent: Monday, May 21, 2001 6:36 AM
  To: 'rezhirpavai@hss.hns.com'
  Cc: 'Rosen, Brian'; 'Dan Elbert'; 'megaco@fore.com'
  Subject: RE: Use of ServiceChange from MGC to MG


  You're right: the only difference would be if the MGC asked for GRACEFUL
with a non-zero time delay.  I suspect the appropriate action in that case
is unspecified -- have to check the documentation.  It would be nice if that
meant "assign no new calls, but wait to set the state".

  > -----Original Message-----
  > From: rezhirpavai@hss.hns.com [mailto:rezhirpavai@hss.hns.com]
  > Sent: Monday, May 21, 2001 3:26 AM
  > To: Taylor, Tom-PT [NORSE:B881:EXCH]
  > Cc: 'Rosen, Brian'; 'Dan Elbert'; 'megaco@fore.com'
  > Subject: RE: Use of ServiceChange from MGC to MG
  >
  >
  >
  >
  > Hello Tom,
  >      Firstly can an MGC issue a SC with GRACEFUL?
  >
  > If yes consider the actions at MG
  > - on receiving GRACEFUL with 0 delay for a non-ROOT
  > termination: It needs to
  > wait for the call to get cleared, i.,e wait till it receives
  > a SUBTRACT before
  > putting it OOS.
  > - on receiving FORCED for a non-ROOT termination: It still
  > needs to wait for a
  > SUBTRACT, i.e wait for the call to get cleared gracefully.
  >
  > Hence what is the difference between MG receiving a service
  > change with graceful
  > or with forced?
  >
  >                                               Regards,
  >                                               R. Ezhirpavai
  >
  >
  >
  >
  >
  > "Tom-PT Taylor"  on 05/20/2001 07:52:23 PM
  >
  > To:   "'Rosen, Brian'" , R Ezhirpavai/HSS@HSS
  > cc:   "'Dan Elbert'" , "'megaco@fore.com'"
  >       
  >
  > Subject:  RE: Use of ServiceChange from MGC to MG
  >
  >
  >
  >
  > The MGC could use GRACEFUL if the termination is an outgoing
  > trunk which a
  > craftsperson at the MGC has seized.  The idea would be to
  > give time for any
  > existing call to terminate, while preventing additional calls
  > from being
  > assigned to the trunk.
  >
  > > -----Original Message-----
  > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
  > > Sent: Friday, May 18, 2001 1:39 PM
  > > To: 'rezhirpavai@hss.hns.com'
  > > Cc: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Dan Elbert';
  > 'megaco@fore.com'
  > > Subject: RE: Use of ServiceChange from MGC to MG
  > >
  > >
  > > I said that - the MGC does the Subtract explicitly; just
  > > taking the termination out of service DOES NOT implicitly do
  > > a Subtract.  If you are arguing about the order of operations,
  > > I would recommend the Subtract before the ServiceChange.
  > >
  > > The usual drill for the MGC is first to subtract, then serviceChange
  > > forced.  There really isn't any reason for the MGC to use Graceful.
  > >
  > > The usual drill for the MG is to send Graceful, the MGC responds
  > > with Subtract, then the MG makes the terminations out of
  > > service after the subtract or at the latest, after the timeout.
  > >
  > > A forced Restart on Root should happen immediately.
  > >
  > > Brian
  > >
  >
  >
  >
  >
  >
  >
  >



--0__=bLnpfyNUeMtdEhhjxjObDQibXRIuTQ3beJbj8JSZWlULkfvsRyvi5EmD
Content-type: text/html;
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U
RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+DQo8VElUTEU+UkU6IFVzZSBvZiBT
ZXJ2aWNlQ2hhbmdlIGZyb20gTUdDIHRvIE1HPC9USVRMRT4NCg0KPE1FVEEgY29udGVudD0iTVNI
VE1MIDUuMDAuMzEwMy4xMDAwIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWT4NCjxESVY+
PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz0xNjI0MTE4
MTMtMjEwNTIwMDE+SEkgDQpUb20vcGF2YWksPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZP
TlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz0xNjI0MTE4MTMt
MjEwNTIwMDE+VGhlIA0KImdyYWNlZnVsIiBtZXRob2Qgb2YgU0MgZG9lc24ndCBjb252ZXkgYWRk
aXRpb25hbCBpbmZvcm1hdGlvbiB0byBNRyhleGNlcHQgZm9yIA0KdGhlIFNDIGRlbGF5IHBhcnQg
b2YgaXQpLiBUb20gbWVudGlvbmVkICJhc3NpZ24gbm8gbmV3IGNhbGxzLCBidXQgd2FpdCB0byBz
ZXQgDQp0aGUgc3RhdGUiLCBidXQgaXQgaXMgdGhlIE1HQyB0aGF0IGlzIGF3YXJlIG9mIHRoZSBj
YWxscyBub3QgTUcuIFNvIHdoYXQgZG9lcyBpdCANCm1lYW4gaWYgTUdDIGlzIGluZGljYXRpbmcg
TUcgbm90IHRvIGVzdGFibGlzaCBuZXcgY2FsbHM/Pz88L1NQQU4+PC9GT05UPjwvRElWPg0KPERJ
Vj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9MTYy
NDExODEzLTIxMDUyMDAxPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNv
bG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz0xNjI0MTE4MTMtMjEw
NTIwMDE+UmVnYXJkczwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAw
ZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz0xNjI0MTE4MTMtMjEwNTIwMDE+TWFk
aHViYWJ1PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxCTE9DS1FVT1RFIHN0eWxlPSJNQVJHSU4tUklH
SFQ6IDBweCI+DQogIDxESVYgYWxpZ249bGVmdCBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBk
aXI9bHRyPjxGT05UIGZhY2U9VGFob21hIA0KICBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS08QlI+PEI+RnJvbTo8L0I+IA0KICBvd25lci1tZWdhY29AcGl0LmNvbW1zLm1hcmNvbmku
Y29tIA0KICBbbWFpbHRvOm93bmVyLW1lZ2Fjb0BwaXQuY29tbXMubWFyY29uaS5jb21dPEI+T24g
QmVoYWxmIE9mIDwvQj5Ub20tUFQgDQogIFRheWxvcjxCUj48Qj5TZW50OjwvQj4gTW9uZGF5LCBN
YXkgMjEsIDIwMDEgNjozNiBBTTxCUj48Qj5Ubzo8L0I+IA0KICAncmV6aGlycGF2YWlAaHNzLmhu
cy5jb20nPEJSPjxCPkNjOjwvQj4gJ1Jvc2VuLCBCcmlhbic7ICdEYW4gRWxiZXJ0JzsgDQogICdt
ZWdhY29AZm9yZS5jb20nPEJSPjxCPlN1YmplY3Q6PC9CPiBSRTogVXNlIG9mIFNlcnZpY2VDaGFu
Z2UgZnJvbSBNR0MgdG8gDQogIE1HPEJSPjxCUj48L0RJVj48L0ZPTlQ+DQogIDxQPjxGT05UIHNp
emU9Mj5Zb3UncmUgcmlnaHQ6IHRoZSBvbmx5IGRpZmZlcmVuY2Ugd291bGQgYmUgaWYgdGhlIE1H
QyBhc2tlZCANCiAgZm9yIEdSQUNFRlVMIHdpdGggYSBub24temVybyB0aW1lIGRlbGF5LiZuYnNw
OyBJIHN1c3BlY3QgdGhlIGFwcHJvcHJpYXRlIA0KICBhY3Rpb24gaW4gdGhhdCBjYXNlIGlzIHVu
c3BlY2lmaWVkIC0tIGhhdmUgdG8gY2hlY2sgdGhlIGRvY3VtZW50YXRpb24uJm5ic3A7IA0KICBJ
dCB3b3VsZCBiZSBuaWNlIGlmIHRoYXQgbWVhbnQgImFzc2lnbiBubyBuZXcgY2FsbHMsIGJ1dCB3
YWl0IHRvIHNldCB0aGUgDQogIHN0YXRlIi48L0ZPTlQ+PC9QPg0KICA8UD48Rk9OVCBzaXplPTI+
Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4m
Z3Q7IA0KICBGcm9tOiByZXpoaXJwYXZhaUBoc3MuaG5zLmNvbSBbPEEgDQogIGhyZWY9Im1haWx0
bzpyZXpoaXJwYXZhaUBoc3MuaG5zLmNvbSI+bWFpbHRvOnJlemhpcnBhdmFpQGhzcy5obnMuY29t
PC9BPl08L0ZPTlQ+IA0KICA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgU2VudDogTW9uZGF5LCBNYXkg
MjEsIDIwMDEgMzoyNiBBTTwvRk9OVD4gPEJSPjxGT05UIA0KICBzaXplPTI+Jmd0OyBUbzogVGF5
bG9yLCBUb20tUFQgW05PUlNFOkI4ODE6RVhDSF08L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0
OyANCiAgQ2M6ICdSb3NlbiwgQnJpYW4nOyAnRGFuIEVsYmVydCc7ICdtZWdhY29AZm9yZS5jb20n
PC9GT05UPiA8QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7IFN1YmplY3Q6IFJFOiBVc2Ugb2YgU2Vy
dmljZUNoYW5nZSBmcm9tIE1HQyB0byBNRzwvRk9OVD4gPEJSPjxGT05UIA0KICBzaXplPTI+Jmd0
OyA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IDwvRk9OVD48QlI+PEZPTlQgc2l6ZT0yPiZn
dDsgDQogIDwvRk9OVD48QlI+PEZPTlQgc2l6ZT0yPiZndDsgPC9GT05UPjxCUj48Rk9OVCBzaXpl
PTI+Jmd0OyBIZWxsbyBUb20sPC9GT05UPiANCiAgPEJSPjxGT05UIHNpemU9Mj4mZ3Q7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpcnN0bHkgY2FuIGFuIE1HQyBpc3N1ZSBhIA0KICBT
QyB3aXRoIEdSQUNFRlVMPzwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IDwvRk9OVD48QlI+
PEZPTlQgc2l6ZT0yPiZndDsgSWYgDQogIHllcyBjb25zaWRlciB0aGUgYWN0aW9ucyBhdCBNRzwv
Rk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IC0gb24gcmVjZWl2aW5nIA0KICBHUkFDRUZVTCB3
aXRoIDAgZGVsYXkgZm9yIGEgbm9uLVJPT1QgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0OyB0
ZXJtaW5hdGlvbjogDQogIEl0IG5lZWRzIHRvPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsg
d2FpdCBmb3IgdGhlIGNhbGwgdG8gZ2V0IGNsZWFyZWQsIA0KICBpLixlIHdhaXQgdGlsbCBpdCBy
ZWNlaXZlcyA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IGEgU1VCVFJBQ1QgDQogIGJlZm9y
ZTwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IHB1dHRpbmcgaXQgT09TLjwvRk9OVD4gPEJS
PjxGT05UIA0KICBzaXplPTI+Jmd0OyAtIG9uIHJlY2VpdmluZyBGT1JDRUQgZm9yIGEgbm9uLVJP
T1QgdGVybWluYXRpb246IEl0IHN0aWxsIA0KICA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7
IG5lZWRzIHRvIHdhaXQgZm9yIGE8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyANCiAgU1VC
VFJBQ1QsIGkuZSB3YWl0IGZvciB0aGUgY2FsbCB0byBnZXQgY2xlYXJlZCBncmFjZWZ1bGx5Ljwv
Rk9OVD4gPEJSPjxGT05UIA0KICBzaXplPTI+Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4m
Z3Q7IEhlbmNlIHdoYXQgaXMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiANCiAgTUcgcmVjZWl2aW5n
IGEgc2VydmljZSA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IGNoYW5nZSB3aXRoIA0KICBn
cmFjZWZ1bDwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IG9yIHdpdGggZm9yY2VkPzwvRk9O
VD4gPEJSPjxGT05UIA0KICBzaXplPTI+Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIA0KICBzaXplPTI+
Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAg
UmVnYXJkcyw8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6ZT0yPiZndDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIFIuIEV6aGlycGF2YWk8L0ZPTlQ+
IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IA0KICA8
L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IDwvRk9OVD48QlI+PEZPTlQgc2l6ZT0yPiZndDsg
PC9GT05UPjxCUj48Rk9OVCANCiAgc2l6ZT0yPiZndDsgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+
Jmd0OyAiVG9tLVBUIFRheWxvciIgDQogICZsdDt0YXlsb3JAbm9ydGVsbmV0d29ya3MuY29tJmd0
OyBvbiAwNS8yMC8yMDAxIDA3OjUyOjIzIFBNPC9GT05UPiA8QlI+PEZPTlQgDQogIHNpemU9Mj4m
Z3Q7IDwvRk9OVD48QlI+PEZPTlQgc2l6ZT0yPiZndDsgVG86Jm5ic3A7Jm5ic3A7ICInUm9zZW4s
IEJyaWFuJyIgDQogICZsdDtCcmlhbi5Sb3NlbkBtYXJjb25pLmNvbSZndDssIFIgRXpoaXJwYXZh
aS9IU1NASFNTPC9GT05UPiA8QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7IGNjOiZuYnNwOyZuYnNw
OyAiJ0RhbiBFbGJlcnQnIiAmbHQ7REVsYmVydEByYWR2aXNpb24uY29tJmd0OywgDQogICInbWVn
YWNvQGZvcmUuY29tJyI8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6ZT0yPiZndDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O21lZ2Fjb0Bmb3JlLmNvbSZndDs8L0ZPTlQ+
IA0KICA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0OyBT
dWJqZWN0OiZuYnNwOyBSRTogVXNlIG9mIA0KICBTZXJ2aWNlQ2hhbmdlIGZyb20gTUdDIHRvIE1H
PC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgPC9GT05UPjxCUj48Rk9OVCANCiAgc2l6ZT0y
PiZndDsgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9
Mj4mZ3Q7IA0KICA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IFRoZSBNR0MgY291bGQgdXNl
IEdSQUNFRlVMIGlmIHRoZSB0ZXJtaW5hdGlvbiBpcyANCiAgYW4gb3V0Z29pbmcgPC9GT05UPjxC
Uj48Rk9OVCBzaXplPTI+Jmd0OyB0cnVuayB3aGljaCBhPC9GT05UPiA8QlI+PEZPTlQgDQogIHNp
emU9Mj4mZ3Q7IGNyYWZ0c3BlcnNvbiBhdCB0aGUgTUdDIGhhcyBzZWl6ZWQuJm5ic3A7IFRoZSBp
ZGVhIHdvdWxkIGJlIHRvIA0KICA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IGdpdmUgdGlt
ZSBmb3IgYW55PC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgDQogIGV4aXN0aW5nIGNhbGwg
dG8gdGVybWluYXRlLCB3aGlsZSBwcmV2ZW50aW5nIGFkZGl0aW9uYWwgY2FsbHMgPC9GT05UPjxC
Uj48Rk9OVCANCiAgc2l6ZT0yPiZndDsgZnJvbSBiZWluZzwvRk9OVD4gPEJSPjxGT05UIHNpemU9
Mj4mZ3Q7IGFzc2lnbmVkIHRvIHRoZSANCiAgdHJ1bmsuPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0y
PiZndDsgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0OyAmZ3Q7IA0KICAtLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLTwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7ICZndDsgRnJvbTogUm9z
ZW4sIA0KICBCcmlhbiBbPEEgDQogIGhyZWY9Im1haWx0bzpCcmlhbi5Sb3NlbkBtYXJjb25pLmNv
bSI+bWFpbHRvOkJyaWFuLlJvc2VuQG1hcmNvbmkuY29tPC9BPl08L0ZPTlQ+IA0KICA8QlI+PEZP
TlQgc2l6ZT0yPiZndDsgJmd0OyBTZW50OiBGcmlkYXksIE1heSAxOCwgMjAwMSAxOjM5IFBNPC9G
T05UPiA8QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7ICZndDsgVG86ICdyZXpoaXJwYXZhaUBoc3Mu
aG5zLmNvbSc8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyANCiAgJmd0OyBDYzogVGF5bG9y
LCBUb20tUFQgW05PUlNFOkI4ODE6RVhDSF07ICdEYW4gRWxiZXJ0JzsgPC9GT05UPjxCUj48Rk9O
VCANCiAgc2l6ZT0yPiZndDsgJ21lZ2Fjb0Bmb3JlLmNvbSc8L0ZPTlQ+IDxCUj48Rk9OVCBzaXpl
PTI+Jmd0OyAmZ3Q7IFN1YmplY3Q6IFJFOiANCiAgVXNlIG9mIFNlcnZpY2VDaGFuZ2UgZnJvbSBN
R0MgdG8gTUc8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyAmZ3Q7PC9GT05UPiANCiAgPEJS
PjxGT05UIHNpemU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyAmZ3Q7
IEkgc2FpZCB0aGF0IC0gdGhlIA0KICBNR0MgZG9lcyB0aGUgU3VidHJhY3QgZXhwbGljaXRseTsg
anVzdDwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7ICZndDsgDQogIHRha2luZyB0aGUgdGVy
bWluYXRpb24gb3V0IG9mIHNlcnZpY2UgRE9FUyBOT1QgaW1wbGljaXRseSBkbzwvRk9OVD4gPEJS
PjxGT05UIA0KICBzaXplPTI+Jmd0OyAmZ3Q7IGEgU3VidHJhY3QuJm5ic3A7IElmIHlvdSBhcmUg
YXJndWluZyBhYm91dCB0aGUgb3JkZXIgb2YgDQogIG9wZXJhdGlvbnMsPC9GT05UPiA8QlI+PEZP
TlQgc2l6ZT0yPiZndDsgJmd0OyBJIHdvdWxkIHJlY29tbWVuZCB0aGUgU3VidHJhY3QgDQogIGJl
Zm9yZSB0aGUgU2VydmljZUNoYW5nZS48L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyAmZ3Q7
PC9GT05UPiA8QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7ICZndDsgVGhlIHVzdWFsIGRyaWxsIGZv
ciB0aGUgTUdDIGlzIGZpcnN0IHRvIHN1YnRyYWN0LCB0aGVuIA0KICBzZXJ2aWNlQ2hhbmdlPC9G
T05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgJmd0OyBmb3JjZWQuJm5ic3A7IFRoZXJlIHJlYWxs
eSANCiAgaXNuJ3QgYW55IHJlYXNvbiBmb3IgdGhlIE1HQyB0byB1c2UgR3JhY2VmdWwuPC9GT05U
PiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgDQogICZndDs8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+
Jmd0OyAmZ3Q7IFRoZSB1c3VhbCBkcmlsbCBmb3IgdGhlIE1HIGlzIHRvIHNlbmQgDQogIEdyYWNl
ZnVsLCB0aGUgTUdDIHJlc3BvbmRzPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgJmd0OyB3
aXRoIFN1YnRyYWN0LCANCiAgdGhlbiB0aGUgTUcgbWFrZXMgdGhlIHRlcm1pbmF0aW9ucyBvdXQg
b2Y8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyAmZ3Q7IA0KICBzZXJ2aWNlIGFmdGVyIHRo
ZSBzdWJ0cmFjdCBvciBhdCB0aGUgbGF0ZXN0LCBhZnRlciB0aGUgdGltZW91dC48L0ZPTlQ+IA0K
ICA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgJmd0OzwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7
ICZndDsgQSBmb3JjZWQgUmVzdGFydCANCiAgb24gUm9vdCBzaG91bGQgaGFwcGVuIGltbWVkaWF0
ZWx5LjwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+IA0KICA8QlI+PEZP
TlQgc2l6ZT0yPiZndDsgJmd0OyBCcmlhbjwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7ICZn
dDs8L0ZPTlQ+IA0KICA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgPC9GT05UPjxCUj48Rk9OVCBzaXpl
PTI+Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIA0KICBzaXplPTI+Jmd0OyA8L0ZPTlQ+PEJSPjxGT05U
IHNpemU9Mj4mZ3Q7IDwvRk9OVD48QlI+PEZPTlQgc2l6ZT0yPiZndDsgDQogIDwvRk9OVD48QlI+
PEZPTlQgc2l6ZT0yPiZndDsgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0OyANCjwvRk9OVD48
L1A+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo=

--0__=bLnpfyNUeMtdEhhjxjObDQibXRIuTQ3beJbj8JSZWlULkfvsRyvi5EmD--



From owner-megaco@fore.com  Mon May 21 10:25:29 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10294
	for ; Mon, 21 May 2001 10:25:24 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10500;
	Mon, 21 May 2001 10:17:58 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA21465
	for megaco-list; Mon, 21 May 2001 10:17:14 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21458
	for ; Mon, 21 May 2001 10:17:12 -0400 (EDT)
Received: from slink12.ss7-link.com (mail.ss7-link.com [209.204.106.218])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10351
	for ; Mon, 21 May 2001 10:17:09 -0400 (EDT)
Received: by SLINK12 with Internet Mail Service (5.5.2650.21)
	id ; Mon, 21 May 2001 10:17:10 -0400
Message-ID: 
From: Dave Sclarsky 
To: "'Tom-PT Taylor'" ,
        "'Rosen, Brian'"
	 ,
        "'Troy Cauble'" 
Cc: "'knayar@hss.hns.com'" , megaco@fore.com
Subject: RE: Polls of MGC
Date: Mon, 21 May 2001 10:17:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0E200.B8C9F8A0"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E200.B8C9F8A0
Content-Type: text/plain;
	charset="iso-8859-1"

Tom,
No matter how rare, the protocol must handle recovery from MGC failures.
I don't see a big difference between MGC initiated vs MG initiated polling.
Both cases require a writeable timeout value on the MG, which the MGC
can use to control the polling frequency. 
DaveS.

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Sunday, May 20, 2001 10:16 AM
To: 'Dave Sclarsky'; 'Rosen, Brian'; 'Troy Cauble'
Cc: 'knayar@hss.hns.com'; megaco@fore.com
Subject: RE: Polls of MGC



If PSTN standards are used, failure of MGCs will be a rare event, and a
failure of any significant extent in the US will have to be reported to the
FCC.  Let's be realistic here.  I like Kevin's proposal of MGC-initiated
polling -- it keeps control of the process where it belongs.

> -----Original Message----- 
> From: Dave Sclarsky [ mailto:Dave.Sclarsky@radisys.com
 ] 
> Sent: Friday, May 18, 2001 1:18 PM 
> To: 'Rosen, Brian'; 'Troy Cauble' 
> Cc: 'knayar@hss.hns.com'; megaco@fore.com 
> Subject: RE: Polls of MGC 
> 
> 
> Brian, 
> We cannot let the MGs wait until they need to send something 
> before learning 
> that an MGC went down.  You could have a ResGW disconnected 
> from the network 
> all night!  What if Johnny at college needs to call home at 
> 3am to bail him 
> out of jail?  Dad's controlling MGC won't be able to make his 
> phone ring 
> because Dad hasn't made a call since the MGC restarted!  I 
> guess if you're 
> Johnny's dad this is a good thing :-) 
> 
> DaveS. 
> 
> 


------_=_NextPart_001_01C0E200.B8C9F8A0
Content-Type: text/html;
	charset="iso-8859-1"




RE: Polls of MGC




Tom,


No 
matter how rare, the protocol must handle recovery from MGC 
failures.


I 
don't see a big difference between MGC initiated vs MG 
initiated polling.


Both 
cases require a writeable timeout value on the MG, which the 
MGC


can 
use to control the polling frequency. 


DaveS.



  
-----Original Message-----
From: Tom-PT Taylor 
  [mailto:taylor@nortelnetworks.com]
Sent: Sunday, May 20, 2001 10:16 
  AM
To: 'Dave Sclarsky'; 'Rosen, Brian'; 'Troy Cauble'
Cc: 
  'knayar@hss.hns.com'; megaco@fore.com
Subject: RE: Polls of 
  MGC


  
If PSTN standards are used, failure of MGCs will be a rare 
  event, and a failure of any significant extent in the US will have to be 
  reported to the FCC.  Let's be realistic here.  I like Kevin's 
  proposal of MGC-initiated polling -- it keeps control of the process where it 
  belongs.

  
> -----Original Message----- 
> 
  From: Dave Sclarsky [mailto:Dave.Sclarsky@radisys.com] 
  
> Sent: Friday, May 18, 2001 1:18 PM 
> To: 'Rosen, Brian'; 'Troy Cauble' 
> Cc: 
  'knayar@hss.hns.com'; megaco@fore.com 
> Subject: 
  RE: Polls of MGC 
> 
> 
  
> Brian, 
> We cannot let 
  the MGs wait until they need to send something 
> 
  before learning 
> that an MGC went down.  You 
  could have a ResGW disconnected 
> from the 
  network 
> all night!  What if Johnny at 
  college needs to call home at 
> 3am to bail 
  him 
> out of jail?  Dad's controlling MGC 
  won't be able to make his 
> phone ring 
  
> because Dad hasn't made a call since the MGC 
  restarted!  I 
> guess if you're 
  
> Johnny's dad this is a good thing :-) 
> 
> DaveS. 
> 
  
> 


------_=_NextPart_001_01C0E200.B8C9F8A0--


From owner-megaco@fore.com  Mon May 21 14:08:18 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15485
	for ; Mon, 21 May 2001 14:08:17 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA29771;
	Mon, 21 May 2001 14:01:55 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA03937
	for megaco-list; Mon, 21 May 2001 13:59:43 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA03913
	for ; Mon, 21 May 2001 13:58:59 -0400 (EDT)
Received: from hotmail.com (f93.law12.hotmail.com [64.4.19.93])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA29542
	for ; Mon, 21 May 2001 13:58:56 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 21 May 2001 10:58:56 -0700
Received: from 129.192.63.5 by lw12fd.law12.hotmail.msn.com with HTTP;	Mon, 21 May 2001 17:58:56 GMT
X-Originating-IP: [129.192.63.5]
From: "Hari Prasada babu Yenikapati" 
To: megaco@fore.com
Subject: Need help on H.248 Parser?.
Date: Mon, 21 May 2001 10:58:56 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 21 May 2001 17:58:56.0362 (UTC) FILETIME=[B453ACA0:01C0E21F]
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hi ,
  I got this mail-id from the web.I need your help.
Can anybody please tell me any site which gives a sample source code for 
H.248/Megaco parser?.Also, please give me some good resources/references 
which can help me in implementing H.248 parser.I really appreciate any help 
in this regard.

Thanks & Regards,
-hari.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com



From owner-megaco@fore.com  Mon May 21 22:52:54 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24229
	for ; Mon, 21 May 2001 22:52:54 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA29212;
	Mon, 21 May 2001 22:43:28 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id WAA00297
	for megaco-list; Mon, 21 May 2001 22:41:22 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA00293
	for ; Mon, 21 May 2001 22:41:21 -0400 (EDT)
Received: from mail.szutstar.com ([202.105.137.228])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA29105
	for ; Mon, 21 May 2001 22:41:16 -0400 (EDT)
Received: from leon-teng ([202.105.137.230])
	by mail.szutstar.com (8.11.1/8.11.1) with SMTP id f4M2c5R16296
	for ; Tue, 22 May 2001 10:38:05 +0800
Message-Id: <200105220238.f4M2c5R16296@mail.szutstar.com>
Date: Tue, 22 May 2001 10:44:32 +0800
From: "leon.teng" 
Reply-To: lteng@utstar.com
To: "megaco@fore.com" 
Subject: about Q.CBC
Organization: utstar
X-mailer: FoxMail 3.11 Release [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear megaco
     when i research on TS29.232( H.248 package for 3GPP), there always mentions a document-- Q.CBC(" draft Call Bearer Control Protocol"). This is a ITU-T draft and not published. I can't find it from internet. I really appreciate if anyone can help get it.
            leon.teng
            lteng@utstar.com



From owner-megaco@fore.com  Tue May 22 03:29:12 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11420
	for ; Tue, 22 May 2001 03:29:12 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA06056;
	Tue, 22 May 2001 03:23:33 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id DAA16511
	for megaco-list; Tue, 22 May 2001 03:22:02 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA16507
	for ; Tue, 22 May 2001 03:22:00 -0400 (EDT)
Received: from brahma01.netbrahma.com ([164.164.70.67])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA05953
	for ; Tue, 22 May 2001 03:21:48 -0400 (EDT)
Received: by BRAHMA01 with Internet Mail Service (5.5.2653.19)
	id ; Tue, 22 May 2001 12:51:14 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D7106FD3@BRAHMA01>
From: Atanu Mondal 
To: "'megaco@fore.com'" 
Cc: "'madhubabu@kenetec.com'" 
Date: Tue, 22 May 2001 12:51:13 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Dear List

The serviceChangeParm as described in ABNF spec is as below
serviceChangeParm = (serviceChangeMethod
/serviceChangeReason/serviceChangeDelay/serviceChangeAddress/serviceChangePr
ofile/extension/TimeStamp/serviceChangeMgcId/serviceChangeVersion )
 which makes all the parameters a s optional.

In ASN syntax the serviceChangeParm is described as below

serviceChangeParm ::= SEQUENCE
{
	serviceChangeMethod	ServiceChangeMethod,
	serviceChangeAddress	ServiceChangeAddress	OPTIONAL,
	serviceChangeVersion	INTEGER(0..99)		OPTIONAL,
	serviceChangeProfile	ServiceChangeProfile	OPTIONAL,
	serviceChangeReason	Value			
	serviceChangeDelay	INTEGER(0..4294967295) OPTIONAL,
	serviceChangeMgcId	MId 	OPTIONAL,
	timeStamp		TimeNotation	OPTIONAL,
	nonStandardData	NonStandardData	OPTIONAL,
}

Which makes the ServiceChangeMethod as compulsory and the rest optional.
What is the reason for this decrepency between the two version(ASN and ABNF)

If anybody can clarify the reason for this decrepency it will be very
helpful
Thanking in advance

Regards
Atanu


From owner-megaco@fore.com  Tue May 22 05:29:46 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12182
	for ; Tue, 22 May 2001 05:29:46 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA09889;
	Tue, 22 May 2001 05:24:07 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA25088
	for megaco-list; Tue, 22 May 2001 05:22:36 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA25084
	for ; Tue, 22 May 2001 05:22:34 -0400 (EDT)
From: akalra@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA09784
	for ; Tue, 22 May 2001 05:22:29 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4M9NQc08877
	for ; Tue, 22 May 2001 14:53:32 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A54.0032191A ; Tue, 22 May 2001 14:37:12 +0530
X-Lotus-FromDomain: HSS
To: megaco@fore.com
Message-ID: <65256A54.0031E786.00@sandesh.hss.hns.com>
Date: Tue, 22 May 2001 14:49:30 +0530
Subject: Clarification in RFC-3015 for domainAddress related to IPV6address
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk



Hi all,
     I am attaching the part where I feel some ambiguity,

   domainAddress        = "[" (IPv4address / IPv6address) "]"
   ;RFC2373 contains the definition of IP6Addresses.
   IPv6address          = hexpart [ ":" IPv4address ]
   IPv4address          = V4hex DOT V4hex DOT V4hex DOT V4hex
   V4hex                = 1*3(DIGIT) ; "0".."225"
   ; this production, while occurring in RFC2373, is not referenced
   ; IPv6prefix         = hexpart SLASH 1*2DIGIT
   hexpart               = hexseq "::" [ hexseq ] / "::" [ hexseq ] / hexseq
   hexseq               = hex4 *( ":" hex4)
   hex4                 = 1*4HEXDIG

Can anyone tell me whether my interpretation is correct or not?

The expansion of hexpart    is           either    hexseq "::" [ hexseq ]
                              or         "::" [ hexseq ]
                              or         hexseq

If I am correct then the expansion of
IPV6address  leads to         hexpart [ ":" IPV4address ]
and if I choose the first choice of hexpart then I get
     IPV6address    =    hexseq :: [ hexseq ] [ ":" IPV4address ]
since the second hexseq is optional so if I omit it then I get
     IPV6address    =    hexseq :: [ ":" IPV4address ]
and now if get a ":" and an IPV4address, then I get
     IPV6address    =    hexseq ::: IPV4address

which means that an IPV6address can be of the above type,
is this ":::" allowed like this.
Please see if my interpretation is right,
if it is then is the above expansion allowed.

regards/
Amit Kalra






From owner-megaco@fore.com  Tue May 22 11:05:15 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21561
	for ; Tue, 22 May 2001 11:05:14 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA00391;
	Tue, 22 May 2001 10:53:41 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA22457
	for megaco-list; Tue, 22 May 2001 10:48:26 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA22453
	for ; Tue, 22 May 2001 10:48:25 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA29855
	for ; Tue, 22 May 2001 10:48:22 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id KAA26776; Tue, 22 May 2001 10:48:16 -0400
Received: from ztcfd004.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 22 May 2001 10:47:59 -0400
Received: by ztcfd004.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Tue, 22 May 2001 10:48:00 -0400
Message-ID: <45D2A43C1913D51180F40000F89CB874062E21@nrtpde0a.us.nortel.com>
From: "Michael Brown" 
To: megaco@fore.com
Subject: RE: about Q.CBC
Date: Tue, 22 May 2001 10:47:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E2CE.2EFC4940"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E2CE.2EFC4940
Content-Type: text/plain;
	charset="gb2312"

It can be found at the following location. This document is currently
undergoing finalization at the SG 11 meeting in Geneva, so there may be some
(small) changes reflected from that meeting. Q.CBC is now know as Q.1950.
The other documents in this directory are related to the CBC protocol.

ftp://standards.nortelnetworks.com/megaco/docs/Current/ITU-SG11/

-----Original Message-----
From: leon.teng [mailto:lteng@utstar.com]
Sent: Monday, May 21, 2001 10:45 PM
To: megaco@fore.com
Subject: about Q.CBC


Dear megaco
     when i research on TS29.232( H.248 package for 3GPP), there always
mentions a document-- Q.CBC(" draft Call Bearer Control Protocol"). This is
a ITU-T draft and not published. I can't find it from internet. I really
appreciate if anyone can help get it.
            leon.teng
            lteng@utstar.com


------_=_NextPart_001_01C0E2CE.2EFC4940
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable






RE: about Q.CBC




It can be found at the following location. This =
document is currently undergoing finalization at the SG 11 meeting in =
Geneva, so there may be some (small) changes reflected from that =
meeting. Q.CBC is now know as Q.1950. The other documents in this =
directory are related to the CBC protocol.



ftp://standards.nortelnetworks.com/megaco/docs/Current=
/ITU-SG11/




-----Original Message-----

From: leon.teng [mailto:lteng@utstar.com]

Sent: Monday, May 21, 2001 10:45 PM

To: megaco@fore.com

Subject: about Q.CBC






Dear megaco

     when i research on =
TS29.232( H.248 package for 3GPP), there always mentions a document-- =
Q.CBC(" draft Call Bearer Control Protocol"). This is a ITU-T =
draft and not published. I can't find it from internet. I really =
appreciate if anyone can help get it.



          &nb=
sp; leon.teng

          &nb=
sp; lteng@utstar.com





------_=_NextPart_001_01C0E2CE.2EFC4940--


From owner-megaco@fore.com  Tue May 22 11:10:08 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21781
	for ; Tue, 22 May 2001 11:10:07 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA00820;
	Tue, 22 May 2001 10:56:48 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA24644
	for megaco-list; Tue, 22 May 2001 10:55:48 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24635
	for ; Tue, 22 May 2001 10:55:47 -0400 (EDT)
Received: from pine.cyberpathinc.com ([38.246.253.128])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA00676
	for ; Tue, 22 May 2001 10:55:43 -0400 (EDT)
Received: from YSHA (ysha [172.30.30.41])
	by pine.cyberpathinc.com (8.9.3+Sun/8.9.3) with SMTP id KAA02214;
	Tue, 22 May 2001 10:57:51 -0400 (EDT)
Received: by YSHA with Microsoft Mail
	id <01C0E2AD.D23656D0@YSHA>; Tue, 22 May 2001 10:56:15 -0400
Message-ID: <01C0E2AD.D23656D0@YSHA>
From: YouLing Sha 
To: "'megaco@fore.com'" 
Cc: "Youling Sha (E-mail)" 
Subject: how to pass the dialed string from one MG to another through MGC?
Date: Tue, 22 May 2001 10:55:58 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.pit.comms.marconi.com id KAA24637
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi,

If two MGs controlled by the same MGC, MG1 is the Gateway at the subscriber side, and MG2 is the Gateway with the connectivity to the PSTN. If a subscriber tries to make an outgoing call to the PSTN, MG1 forwards the dialed string to the MGC. The MGC, based on the dial plan, knows that this is a PSTN call and route it to MG2. In this case, there's no SS7 involved. 
The question is that how the original dialed string can be passed from the MGC to MG2 ? Is there an appropriate package to support this kind of situation? 
Please advice. Thanks.

Regards,
YouLing Sha
CyberPath Inc.
(732) 463-7700 ext. 304
ysha@cyberpathinc.com



From owner-megaco@fore.com  Tue May 22 11:48:11 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23208
	for ; Tue, 22 May 2001 11:48:10 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA04673;
	Tue, 22 May 2001 11:32:45 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA07219
	for megaco-list; Tue, 22 May 2001 11:31:25 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA07212
	for ; Tue, 22 May 2001 11:31:24 -0400 (EDT)
Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA04427
	for ; Tue, 22 May 2001 11:31:20 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4MFURu3010019
	for ; Tue, 22 May 2001 10:31:01 -0500
From: "Paul Long" 
To: 
Subject: RE: Clarification in RFC-3015 for domainAddress related to IPV6address
Date: Tue, 22 May 2001 10:31:19 -0500
Message-ID: 
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)
Importance: Normal
In-Reply-To: <65256A54.0031E786.00@sandesh.hss.hns.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Amit,

I believe you are correct. That idiom would be used when there are trailing
zeros in the IPv4 representation before an IPv6 representation. For example,
FFFF:::13.1.68.3 == FFFF:0:0:0:0:0:13.1.68.3 == FFFF:0:0:0:0:0:0D01:4403.
BTW, this syntax is nasty to parse. My lexer scans ahead and then nibbles
away at each end. :-)

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of
akalra@hss.hns.com
Sent: Tuesday, May 22, 2001 4:19 AM
To: megaco@fore.com
Subject: Clarification in RFC-3015 for domainAddress related to
IPV6address




Hi all,
     I am attaching the part where I feel some ambiguity,

   domainAddress        = "[" (IPv4address / IPv6address) "]"
   ;RFC2373 contains the definition of IP6Addresses.
   IPv6address          = hexpart [ ":" IPv4address ]
   IPv4address          = V4hex DOT V4hex DOT V4hex DOT V4hex
   V4hex                = 1*3(DIGIT) ; "0".."225"
   ; this production, while occurring in RFC2373, is not referenced
   ; IPv6prefix         = hexpart SLASH 1*2DIGIT
   hexpart               = hexseq "::" [ hexseq ] / "::" [ hexseq ] / hexseq
   hexseq               = hex4 *( ":" hex4)
   hex4                 = 1*4HEXDIG

Can anyone tell me whether my interpretation is correct or not?

The expansion of hexpart    is           either    hexseq "::" [ hexseq ]
                              or         "::" [ hexseq ]
                              or         hexseq

If I am correct then the expansion of
IPV6address  leads to         hexpart [ ":" IPV4address ]
and if I choose the first choice of hexpart then I get
     IPV6address    =    hexseq :: [ hexseq ] [ ":" IPV4address ]
since the second hexseq is optional so if I omit it then I get
     IPV6address    =    hexseq :: [ ":" IPV4address ]
and now if get a ":" and an IPV4address, then I get
     IPV6address    =    hexseq ::: IPV4address

which means that an IPV6address can be of the above type,
is this ":::" allowed like this.
Please see if my interpretation is right,
if it is then is the above expansion allowed.

regards/
Amit Kalra





From owner-megaco@fore.com  Tue May 22 12:10:53 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24012
	for ; Tue, 22 May 2001 12:10:52 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA06472;
	Tue, 22 May 2001 11:52:25 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA12782
	for megaco-list; Tue, 22 May 2001 11:51:02 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA12771
	for ; Tue, 22 May 2001 11:51:00 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id LAA06297
	for ; Tue, 22 May 2001 11:50:56 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id LAA05986; Tue, 22 May 2001 11:50:50 -0400
Received: from ztcfd004.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 22 May 2001 11:50:26 -0400
Received: by ztcfd004.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Tue, 22 May 2001 11:50:27 -0400
Message-ID: <45D2A43C1913D51180F40000F89CB874062E23@nrtpde0a.us.nortel.com>
From: "Michael Brown" 
To: "'megaco@fore.com'" 
Subject: RE: how to pass the dialed string from one MG to another through MGC?
Date: Tue, 22 May 2001 11:50:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E2D6.E783D7F0"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E2D6.E783D7F0
Content-Type: text/plain;
	charset="iso-8859-1"

The package(s) currently proposed are in :

Basic CAS packages

http://ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-00.txt

MF Tone Generation/Detection

http://ietf.org/internet-drafts/draft-bothwell-megaco-mftonepkgs-00.txt

These packages should be going to List Last Call soon. Comments are welcome.

Michael Brown

-----Original Message-----
From: YouLing Sha [mailto:ysha@cpmail.cyberpathinc.com]
Sent: Tuesday, May 22, 2001 10:56 AM
To: 'megaco@fore.com'
Cc: Youling Sha (E-mail)
Subject: how to pass the dialed string from one MG to another through
MGC?


Hi,

If two MGs controlled by the same MGC, MG1 is the Gateway at the subscriber
side, and MG2 is the Gateway with the connectivity to the PSTN. If a
subscriber tries to make an outgoing call to the PSTN, MG1 forwards the
dialed string to the MGC. The MGC, based on the dial plan, knows that this
is a PSTN call and route it to MG2. In this case, there's no SS7 involved. 
The question is that how the original dialed string can be passed from the
MGC to MG2 ? Is there an appropriate package to support this kind of
situation? 
Please advice. Thanks.

Regards,
YouLing Sha
CyberPath Inc.
(732) 463-7700 ext. 304
ysha@cyberpathinc.com


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






RE: how to pass the dialed string from one MG to another through =
MGC?




The package(s) currently proposed are in :




Basic CAS packages




http://ietf.org/internet-drafts/draft-manyfolks-megaco=
-caspackage-00.txt




MF Tone Generation/Detection




http://ietf.org/internet-drafts/draft-bothwell-megaco-=
mftonepkgs-00.txt




These packages should be going to List Last Call =
soon. Comments are welcome.




Michael Brown




-----Original Message-----

From: YouLing Sha [mailto:ysha@cpmail.cyberpat=
hinc.com]

Sent: Tuesday, May 22, 2001 10:56 AM

To: 'megaco@fore.com'

Cc: Youling Sha (E-mail)

Subject: how to pass the dialed string from one MG =
to another through

MGC?






Hi,




If two MGs controlled by the same MGC, MG1 is the =
Gateway at the subscriber side, and MG2 is the Gateway with the =
connectivity to the PSTN. If a subscriber tries to make an outgoing =
call to the PSTN, MG1 forwards the dialed string to the MGC. The MGC, =
based on the dial plan, knows that this is a PSTN call and route it to =
MG2. In this case, there's no SS7 involved. 



The question is that how the original dialed string =
can be passed from the MGC to MG2 ? Is there an appropriate package to =
support this kind of situation? 



Please advice. Thanks.




Regards,

YouLing Sha

CyberPath Inc.

(732) 463-7700 ext. 304

ysha@cyberpathinc.com





------_=_NextPart_001_01C0E2D6.E783D7F0--


From owner-megaco@fore.com  Tue May 22 14:06:08 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28138
	for ; Tue, 22 May 2001 14:06:08 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA17395;
	Tue, 22 May 2001 14:00:23 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA10971
	for megaco-list; Tue, 22 May 2001 13:58:52 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA10967
	for ; Tue, 22 May 2001 13:58:50 -0400 (EDT)
Received: from pine.cyberpathinc.com ([38.246.253.128])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA17207
	for ; Tue, 22 May 2001 13:58:46 -0400 (EDT)
Received: from YSHA (ysha [172.30.30.41])
	by pine.cyberpathinc.com (8.9.3+Sun/8.9.3) with SMTP id OAA12631;
	Tue, 22 May 2001 14:00:34 -0400 (EDT)
Received: by YSHA with Microsoft Mail
	id <01C0E2C7.589E42F0@YSHA>; Tue, 22 May 2001 13:58:57 -0400
Message-ID: <01C0E2C7.589E42F0@YSHA>
From: YouLing Sha 
To: "'Michael Brown'" ,
        "'megaco@fore.com'" 
Subject: RE: how to pass the dialed string from one MG to another through MGC?
Date: Tue, 22 May 2001 13:58:56 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Michael,

If using 'bcas', am I doing the right thing here? Some places I put "??" there. What should be the right IDs to use?
Thanks.

MG1 detects the digits dialed. A notify command is generated from MG1 to MGC. 
MG1 to MGC:
MEGACO/1 [11.22.33.44]: 12345
   Transaction = 2001 {
      Context = - {
          Notify = TermA {ObservedEvents =1111 {
            20010522T111111111:dd/ce {ds="5551212", Meth=??}}}
      }
   }

How the MGC passes the dialed string "5551212" to MG2 using the bcas or mfg package? Where the MG2 is the gateway to the PSTN.

MGC to MG2
MEGACO/1 [44.33.22.11]: 54321
   Transaction = 1002 {
      Context = - {
        Modify = Trunk1/line1 {
             Signals = { bcas/sz }
             Events = 1111 {bcas/?? Embed { signals {bcas/addr { ds = 5551212} }, Events=1112 { bcas/clear, bcas/ans}}} 
                                                     }
                     }

Regards,
YouLing Sha



-----Original Message-----
From:	Michael Brown [SMTP:C.Michael.Brown@nortelnetworks.com]
Sent:	Tuesday, May 22, 2001 11:50 AM
To:	'megaco@fore.com'
Subject:	RE: how to pass the dialed string from one MG to another through MGC?

The package(s) currently proposed are in :

Basic CAS packages

http://ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-00.txt

MF Tone Generation/Detection

http://ietf.org/internet-drafts/draft-bothwell-megaco-mftonepkgs-00.txt

These packages should be going to List Last Call soon. Comments are welcome.

Michael Brown

-----Original Message-----
From: YouLing Sha [mailto:ysha@cpmail.cyberpathinc.com]
Sent: Tuesday, May 22, 2001 10:56 AM
To: 'megaco@fore.com'
Cc: Youling Sha (E-mail)
Subject: how to pass the dialed string from one MG to another through
MGC?


Hi,

If two MGs controlled by the same MGC, MG1 is the Gateway at the subscriber
side, and MG2 is the Gateway with the connectivity to the PSTN. If a
subscriber tries to make an outgoing call to the PSTN, MG1 forwards the
dialed string to the MGC. The MGC, based on the dial plan, knows that this
is a PSTN call and route it to MG2. In this case, there's no SS7 involved. 
The question is that how the original dialed string can be passed from the
MGC to MG2 ? Is there an appropriate package to support this kind of
situation? 
Please advice. Thanks.

Regards,
YouLing Sha
CyberPath Inc.
(732) 463-7700 ext. 304
ysha@cyberpathinc.com

 << File: ATT00002.htm >> 


From owner-megaco@fore.com  Tue May 22 15:08:05 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01235
	for ; Tue, 22 May 2001 15:08:04 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA22337;
	Tue, 22 May 2001 14:59:40 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA27820
	for megaco-list; Tue, 22 May 2001 14:58:09 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA27815
	for ; Tue, 22 May 2001 14:58:08 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id OAA22134
	for ; Tue, 22 May 2001 14:58:04 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id OAA11506; Tue, 22 May 2001 14:57:59 -0400
Received: from ztcfd004.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 22 May 2001 14:57:54 -0400
Received: by ztcfd004.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Tue, 22 May 2001 14:57:55 -0400
Message-ID: <45D2A43C1913D51180F40000F89CB874062E27@nrtpde0a.us.nortel.com>
From: "Michael Brown" 
To: "'megaco@fore.com'" 
Subject: RE: how to pass the dialed string from one MG to another through MGC?
Date: Tue, 22 May 2001 14:57:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E2F1.1BD985D0"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E2F1.1BD985D0
Content-Type: text/plain;
	charset="iso-8859-1"


Comments inline
-----Original Message-----
From: YouLing Sha [mailto:ysha@cpmail.cyberpathinc.com]
Sent: Tuesday, May 22, 2001 1:59 PM
To: Brown, Michael [NC1:GW10:EXCH]; 'megaco@fore.com'
Subject: RE: how to pass the dialed string from one MG to another
through MGC?


Hi Michael,

If using 'bcas', am I doing the right thing here? Some places I put "??"
there. What should be the right IDs to use?
Thanks.

MG1 detects the digits dialed. A notify command is generated from MG1 to
MGC. 
MG1 to MGC:
MEGACO/1 [11.22.33.44]: 12345
   Transaction = 2001 {
      Context = - {
          Notify = TermA {ObservedEvents =1111 {
            20010522T111111111:dd/ce {ds="5551212", Meth=??}}}
      }
   }

[MB] The method parameter would be as specified in the DTMF detection
package. It indicates the reason which triggered the completion of the digit
map that was specified in the request to collect digits. So the value used
depends on how your digit map is set up and there really isn't a "right"
answer.

How the MGC passes the dialed string "5551212" to MG2 using the bcas or mfg
package? Where the MG2 is the gateway to the PSTN.

MGC to MG2
MEGACO/1 [44.33.22.11]: 54321
   Transaction = 1002 {
      Context = - {
        Modify = Trunk1/line1 {
             Signals = { bcas/sz }
             Events = 1111 {bcas/?? Embed { signals {bcas/addr { ds =
5551212} }, Events=1112 { bcas/clear, bcas/ans}}} 
                                                     }
                     }

[MB] The event you would be looking for where you've put the "??" is Start
Dial (sd). This is the trigger to begin outpulsing. The text in the draft
describes the behavior associated with this event for different trunk types.


Regards,
YouLing Sha



-----Original Message-----
From:	Michael Brown [SMTP:C.Michael.Brown@nortelnetworks.com]
Sent:	Tuesday, May 22, 2001 11:50 AM
To:	'megaco@fore.com'
Subject:	RE: how to pass the dialed string from one MG to another
through MGC?

The package(s) currently proposed are in :

Basic CAS packages

http://ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-00.txt

MF Tone Generation/Detection

http://ietf.org/internet-drafts/draft-bothwell-megaco-mftonepkgs-00.txt

These packages should be going to List Last Call soon. Comments are welcome.

Michael Brown

-----Original Message-----
From: YouLing Sha [mailto:ysha@cpmail.cyberpathinc.com]
Sent: Tuesday, May 22, 2001 10:56 AM
To: 'megaco@fore.com'
Cc: Youling Sha (E-mail)
Subject: how to pass the dialed string from one MG to another through
MGC?


Hi,

If two MGs controlled by the same MGC, MG1 is the Gateway at the subscriber
side, and MG2 is the Gateway with the connectivity to the PSTN. If a
subscriber tries to make an outgoing call to the PSTN, MG1 forwards the
dialed string to the MGC. The MGC, based on the dial plan, knows that this
is a PSTN call and route it to MG2. In this case, there's no SS7 involved. 
The question is that how the original dialed string can be passed from the
MGC to MG2 ? Is there an appropriate package to support this kind of
situation? 
Please advice. Thanks.

Regards,
YouLing Sha
CyberPath Inc.
(732) 463-7700 ext. 304
ysha@cyberpathinc.com

 << File: ATT00002.htm >> 

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






RE: how to pass the dialed string from one MG to another through =
MGC?






Comments inline

-----Original Message-----

From: YouLing Sha [mailto:ysha@cpmail.cyberpat=
hinc.com]

Sent: Tuesday, May 22, 2001 1:59 PM

To: Brown, Michael [NC1:GW10:EXCH]; =
'megaco@fore.com'

Subject: RE: how to pass the dialed string from one =
MG to another

through MGC?






Hi Michael,




If using 'bcas', am I doing the right thing here? =
Some places I put "??" there. What should be the right IDs to =
use?

Thanks.




MG1 detects the digits dialed. A notify command is =
generated from MG1 to MGC. 

MG1 to MGC:

MEGACO/1 [11.22.33.44]: 12345

   Transaction =3D 2001 {

      Context =3D - =
{

          Notify =
=3D TermA {ObservedEvents =3D1111 {

          &nb=
sp; 20010522T111111111:dd/ce {ds=3D"5551212", =
Meth=3D??}}}

      }

   }




[MB] The method parameter would be as specified in =
the DTMF detection package. It indicates the reason which triggered the =
completion of the digit map that was specified in the request to =
collect digits. So the value used depends on how your digit map is set =
up and there really isn't a "right" answer.



How the MGC passes the dialed string =
"5551212" to MG2 using the bcas or mfg package? Where the MG2 =
is the gateway to the PSTN.



MGC to MG2

MEGACO/1 [44.33.22.11]: 54321

   Transaction =3D 1002 {

      Context =3D - =
{

        Modify =
=3D Trunk1/line1 {

          &nb=
sp;  Signals =3D { bcas/sz }

          &nb=
sp;  Events =3D 1111 {bcas/?? Embed { signals {bcas/addr { ds =3D =
5551212} }, Events=3D1112 { bcas/clear, bcas/ans}}} 



          &nb=
sp;           &nb=
sp;           &nb=
sp;           &nb=
sp;      }

          &nb=
sp;          }




[MB] The event you would be looking for where you've =
put the "??" is Start Dial (sd). This is the trigger to begin =
outpulsing. The text in the draft describes the behavior associated =
with this event for different trunk types.





Regards,

YouLing Sha








-----Original Message-----

From:   Michael Brown =
[SMTP:C.Michael.Brown@nortelnetworks.com]

Sent:   Tuesday, May 22, 2001 11:50 =
AM

To:     'megaco@fore.com'

Subject:        =
RE: how to pass the dialed string from one MG to another through =
MGC?




The package(s) currently proposed are in :




Basic CAS packages




http://ietf.org/internet-drafts/draft-manyfolks-megaco=
-caspackage-00.txt




MF Tone Generation/Detection




http://ietf.org/internet-drafts/draft-bothwell-megaco-=
mftonepkgs-00.txt




These packages should be going to List Last Call =
soon. Comments are welcome.




Michael Brown




-----Original Message-----

From: YouLing Sha [mailto:ysha@cpmail.cyberpat=
hinc.com]

Sent: Tuesday, May 22, 2001 10:56 AM

To: 'megaco@fore.com'

Cc: Youling Sha (E-mail)

Subject: how to pass the dialed string from one MG =
to another through

MGC?






Hi,




If two MGs controlled by the same MGC, MG1 is the =
Gateway at the subscriber

side, and MG2 is the Gateway with the connectivity =
to the PSTN. If a

subscriber tries to make an outgoing call to the =
PSTN, MG1 forwards the

dialed string to the MGC. The MGC, based on the dial =
plan, knows that this

is a PSTN call and route it to MG2. In this case, =
there's no SS7 involved. 

The question is that how the original dialed string =
can be passed from the

MGC to MG2 ? Is there an appropriate package to =
support this kind of

situation? 

Please advice. Thanks.




Regards,

YouLing Sha

CyberPath Inc.

(732) 463-7700 ext. 304

ysha@cyberpathinc.com




 << File: ATT00002.htm >> 





------_=_NextPart_001_01C0E2F1.1BD985D0--


From owner-megaco@fore.com  Wed May 23 02:18:59 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24813
	for ; Wed, 23 May 2001 02:18:58 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA20318;
	Wed, 23 May 2001 02:09:20 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA28038
	for megaco-list; Wed, 23 May 2001 02:07:33 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA28034
	for ; Wed, 23 May 2001 02:07:32 -0400 (EDT)
From: hotnews@pet.softjoys.ru
Received: from inc.co.kr ([210.111.90.2])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA20213
	for ; Wed, 23 May 2001 02:07:29 -0400 (EDT)
Received: from pet.softjoys.ru [216.97.194.56] by inc.co.kr
  (SMTPD32-6.00) id A2E573018A; Wed, 23 May 2001 15:04:21 +0900
Message-ID: <000010bb34ae$00002038$00007e6e@pet.softjoys.ru>
To: 
Subject: HOT PLAY:  FXGP (otcbb) $0.74
Date: Tue, 22 May 2001 18:51:47 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: hotnews014@excite.com
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

HOT PLAY:  FXGP (otcbb) $0.74

SYMBOL:  FXGP (otcbb)
Current Price: $ .74
New Target Price: $4.75 - $5.00
52wk High:  $7.81
Float: 1million

U.S. State Department Sets Certification Testing for Finx Group's
Secure Portal System.
 
The FINX Group Inc. (OTC BB: FXGP) announced that its Secure
Portal System for high security applications, recently passed
the U.S. State Department's preliminary forced entry and
ballistics tests.

Lewis S. Schiller, chairman and chief executive officer, said
successful completion of the agency's stringent forced entry
and ballistics tests, as previously reported, paved the way for
final certification testing. The certification, when awarded, will
make possible State Department procurement for use in embassies,
consulates and other facilities around the world.
 
"We understand," Schiller added, "that with certification by the
State Department, other government markets may also be open to us."
 
The system is marketed by the FINX Group's subsidiary, Secure
Portal Systems Inc., under a license agreement with Georal
International Ltd., a world leader in such secure entry systems.
 
A person seeking entry to a facility through the circular, double-door
portal must first be positively identified through the use of advanced
electronic fingerprinting technology developed by another FINX
subsidiary, FMX Corp.
 
Once identity is verified, the nearest semi-circular door rotates
open, admitting the person to a chamber where sensors assure that
he or she is alone and carries no gun, knife or similar contraband,
all in a few seconds.


FINX GROUP INC (FXGP)- Broad Patent Covering Major Advance
in Electronic Fingerprinting - Awarded to Finx Group Subsidiary.
 
The FINX Group Inc., announced that its subsidiary, FMX Corp.,
has been awarded a broad patent covering significant advances
in electronic fingerprinting technology achieved by Michael
Schiller, its founder and president.

for details go to:  http://quote.yahoo.com/q?s=fxgp.ob&d=v1

We consider FXGP a STRONG BUY!!




DISCLAIMER: newpennies cautions that small and micro-cap stocks
are high-risk investments and that some or all investment dollars
can be lost. We suggest you consult a professional investment advisor
before purchasing any stock. All opinions expressed in this newsletter
are the opinions of newpennies. All information concerning
the company is received directly from company press releases.
We recommend you use the information found here as an initial
starting point for conducting your own research and conduct your own
due diligence on the featured company in order to determine your own
personal opinion of the company before investing. newpennies assumes
all information to be truthful and reliable; however, we cannot and do not
warrant or guarantee the accuracy of this information. All statements
contained herein are deemed to be factual as of the date of this report
and as such are subject to change without notice. newpennies is not an
Investment Advisor, Financial Planning Service or a Stock Brokerage
Firm and in accordance with such newpennies is not offering investment
advice or promoting any investment strategies. newpenniesis not offering
securities for sale or solicitation of any offer to buy or sell securities.
newpennies holds fifty thousand shares of this company profile. newpennies,
its affiliates, associates, relatives and anyone associated with newpennies
in any manner reserves the right to either buy or sell shares in the profiled
company's stock, either before the date of the profile, during the date of the
profile or at any time after the date of the profile. We have an inherent conflict
of interest by sending the newsletter at the same time we may own stock in
the same company. newpennies sincerely beleives that the company profiled
is a strong buy however we reserve the right to sell shares at anytime, even
during the time period in which we are profiling a company. newpennies may
profile companies trading in fast moving, volatile markets, and any reader
of this newsletter should observe the trading behavior of any profiled
company prior to investing.





if you wish to unsubscribe from this mailing please email  nomail928@excite.com




From owner-megaco@fore.com  Wed May 23 05:19:03 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29375
	for ; Wed, 23 May 2001 05:19:01 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA25662;
	Wed, 23 May 2001 05:13:19 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA04245
	for megaco-list; Wed, 23 May 2001 05:11:16 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA04240
	for ; Wed, 23 May 2001 05:11:15 -0400 (EDT)
From: akalra@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA25515
	for ; Wed, 23 May 2001 05:11:01 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4N9C2R10453;
	Wed, 23 May 2001 14:42:04 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A55.00311257 ; Wed, 23 May 2001 14:25:59 +0530
X-Lotus-FromDomain: HSS
To: "Paul Long" 
cc: megaco@fore.com
Message-ID: <65256A55.00310A91.00@sandesh.hss.hns.com>
Date: Wed, 23 May 2001 14:26:45 +0530
Subject: RE: Clarification in RFC-3015 for domainAddress related to
	 IPV6address
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk



Hi Paul,
     Thanks for the reply, can you provide some more clarification on:

The expansion of an IPV6address can be one of the following then.

      FFFF::
      FFFF::FFFF
      ::
      ::FFFF
      FFFF
      FFFF:::IPV4address
      FFFF::FFFF:IPV4address
      :::IPV4address
      ::FFFF:IPV4address
      FFFF:IPV4address


Going by the given expansion of hexpart and IPV6address rules in the grammar in
RFC 3015.
Are all the above cases valid for an IPV6address?

regards/
Amit









"Paul Long"  on 05/22/2001 09:01:19 PM

To:   megaco@fore.com
cc:    (bcc: Amit Kalra/HSS)

Subject:  RE: Clarification in RFC-3015 for domainAddress related to IPV6address




Amit,

I believe you are correct. That idiom would be used when there are trailing
zeros in the IPv4 representation before an IPv6 representation. For example,
FFFF:::13.1.68.3 == FFFF:0:0:0:0:0:13.1.68.3 == FFFF:0:0:0:0:0:0D01:4403.
BTW, this syntax is nasty to parse. My lexer scans ahead and then nibbles
away at each end. :-)

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of
akalra@hss.hns.com
Sent: Tuesday, May 22, 2001 4:19 AM
To: megaco@fore.com
Subject: Clarification in RFC-3015 for domainAddress related to
IPV6address




Hi all,
     I am attaching the part where I feel some ambiguity,

   domainAddress        = "[" (IPv4address / IPv6address) "]"
   ;RFC2373 contains the definition of IP6Addresses.
   IPv6address          = hexpart [ ":" IPv4address ]
   IPv4address          = V4hex DOT V4hex DOT V4hex DOT V4hex
   V4hex                = 1*3(DIGIT) ; "0".."225"
   ; this production, while occurring in RFC2373, is not referenced
   ; IPv6prefix         = hexpart SLASH 1*2DIGIT
   hexpart               = hexseq "::" [ hexseq ] / "::" [ hexseq ] / hexseq
   hexseq               = hex4 *( ":" hex4)
   hex4                 = 1*4HEXDIG

Can anyone tell me whether my interpretation is correct or not?

The expansion of hexpart    is           either    hexseq "::" [ hexseq ]
                              or         "::" [ hexseq ]
                              or         hexseq

If I am correct then the expansion of
IPV6address  leads to         hexpart [ ":" IPV4address ]
and if I choose the first choice of hexpart then I get
     IPV6address    =    hexseq :: [ hexseq ] [ ":" IPV4address ]
since the second hexseq is optional so if I omit it then I get
     IPV6address    =    hexseq :: [ ":" IPV4address ]
and now if get a ":" and an IPV4address, then I get
     IPV6address    =    hexseq ::: IPV4address

which means that an IPV6address can be of the above type,
is this ":::" allowed like this.
Please see if my interpretation is right,
if it is then is the above expansion allowed.

regards/
Amit Kalra









From owner-megaco@fore.com  Wed May 23 10:08:03 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05612
	for ; Wed, 23 May 2001 10:08:03 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA09749;
	Wed, 23 May 2001 09:51:23 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA19902
	for megaco-list; Wed, 23 May 2001 09:49:33 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA19896
	for ; Wed, 23 May 2001 09:49:32 -0400 (EDT)
Received: from ties.itu.ch (ties.itu.ch [156.106.192.33])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA09536
	for ; Wed, 23 May 2001 09:49:29 -0400 (EDT)
Received: from ericsson.com ([156.106.209.254])
	by ties.itu.ch (8.9.3/8.9.3) with ESMTP id PAA06389;
	Wed, 23 May 2001 15:48:51 +0200 (MET DST)
Message-ID: <3B0BBF9E.4340CCB7@ericsson.com>
Date: Wed, 23 May 2001 23:48:14 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Troy Cauble 
CC: Dave Sclarsky ,
        "'Rosen, Brian'" ,
        "'knayar@hss.hns.com'" , megaco@fore.com
Subject: Re: Polls of MGC
References:  <3B0576D6.46975EDB@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day Troy et all,

Sorry for the late support of No Polling. I still have not seen a
definitive reason that the MG needs to poll the MGC. We have defined a
master slave protocol with the MGC as the master. The MGC should be in
control of error situations. 

I believe that it's enough that the MG can detect that the MGC has gone
down when it try to signal using any appropriate H.248 Commands ie.
Add, Move, sub replies, Notify request, Service Change etc. Lack of
timely response will indicate failure. The MG can then re-register based
on this.

If you look at the common MG use cases:
1. The MG is a trunking gateway. In this scenario enough traffic will be
generated to maintain a reasonable flow of signalling to minimise the
time to detect errors. For a proper Telco solution you should also have
enough management systems/redundency to know what MGC to hand over to.

2. The MG is a residential gateway. Signalling traffic is not that great
but interaction is only needed with the MGC when the end-user does
something. Therefore the MG will find out about the failure at this
time. Why generate unessary signalling across limited BW links? There's
the avalanche problems mentioned earlier but more importantly someone
will have to pay for bandwidth this signalling takes which basically
serves no purpose.
Again in this scenario the MGC will hopefully be owned by someone who
wants to offer a decent service and has the necessary management
systems/reduncy. I do not envisage MG registration will take very long
on a small residential gateway. Its a ServiceChange request/response
round trip.

What ever the proposed package, service change reason/method, protocol
update polling is unecessary.

Cheers, Christian

Troy Cauble wrote:
> 
> Dave Sclarsky wrote:
> >
> > Troy,
> >
> > It doesn't matter what the new (or restarted) MGC knows or doesn't know.
> > Megaco defines that the control association between MG and MGC is ALWAYS
> > initiated by the MG.
> 
> Then this definition is the problem and should be revisited.
> 
> Polling is bad.
> 
> -troy
> 
> > Given that definition, Johnny's Dad's MG won't be
> > reachable by a new (or a restarted) MGC until the his MG notices the
> > failure.  We must define a way for it to know ASAP!


From owner-megaco@fore.com  Wed May 23 10:28:50 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05966
	for ; Wed, 23 May 2001 10:28:49 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA12315;
	Wed, 23 May 2001 10:16:42 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA26722
	for megaco-list; Wed, 23 May 2001 10:14:08 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26698
	for ; Wed, 23 May 2001 10:14:01 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11999
	for ; Wed, 23 May 2001 10:13:59 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACV05520;
	Wed, 23 May 2001 10:13:24 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Christian Groves'" ,
        "'Troy Cauble'" 
Cc: "'Dave Sclarsky'" ,
        "'Rosen, Brian'" , ,
        
Subject: RE: Polls of MGC
Date: Wed, 23 May 2001 10:17:05 -0400
Message-ID: <03d201c0e393$0bf04fd0$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <3B0BBF9E.4340CCB7@ericsson.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Groves/all,
Since that start of this thread, back of my mind I was not able to convince
myself why polling from MG is necessary (Infact I posted couple of mails
too) But since there was no response from the list I started thinking about
how polling can be advantageous. I ended up taking an example as follows.
For Ex: In a residential gateway when there is no communication between MG
and MGC for long Duration. If the Residential user goes offhook a Notify is
generated towards the MGC. If the MGC is down the MG initiates the
registration with other MGC. But after Registration with the MGC I think the
offhook event will not again be sent to the new MGC. Thus introducing a
chance of dropping one call (or calls originated at that time) when MGC is
down. I think polling will enable the MG to learn about the MGC's status and
thus enabling the MG to handle these calls originated from the MG.

Of course this doesn't eliminate the chance of dropping the call during the
inter-polling time.


I'm not sure how in case of Trunking gateway this is advantageous.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Christian Groves
Sent: Wednesday, May 23, 2001 9:48 AM
To: Troy Cauble
Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com'; megaco@fore.com
Subject: Re: Polls of MGC


G'Day Troy et all,

Sorry for the late support of No Polling. I still have not seen a
definitive reason that the MG needs to poll the MGC. We have defined a
master slave protocol with the MGC as the master. The MGC should be in
control of error situations.

I believe that it's enough that the MG can detect that the MGC has gone
down when it try to signal using any appropriate H.248 Commands ie.
Add, Move, sub replies, Notify request, Service Change etc. Lack of
timely response will indicate failure. The MG can then re-register based
on this.

If you look at the common MG use cases:
1. The MG is a trunking gateway. In this scenario enough traffic will be
generated to maintain a reasonable flow of signalling to minimise the
time to detect errors. For a proper Telco solution you should also have
enough management systems/redundency to know what MGC to hand over to.

2. The MG is a residential gateway. Signalling traffic is not that great
but interaction is only needed with the MGC when the end-user does
something. Therefore the MG will find out about the failure at this
time. Why generate unessary signalling across limited BW links? There's
the avalanche problems mentioned earlier but more importantly someone
will have to pay for bandwidth this signalling takes which basically
serves no purpose.
Again in this scenario the MGC will hopefully be owned by someone who
wants to offer a decent service and has the necessary management
systems/reduncy. I do not envisage MG registration will take very long
on a small residential gateway. Its a ServiceChange request/response
round trip.

What ever the proposed package, service change reason/method, protocol
update polling is unecessary.

Cheers, Christian

Troy Cauble wrote:
>
> Dave Sclarsky wrote:
> >
> > Troy,
> >
> > It doesn't matter what the new (or restarted) MGC knows or doesn't know.
> > Megaco defines that the control association between MG and MGC is ALWAYS
> > initiated by the MG.
>
> Then this definition is the problem and should be revisited.
>
> Polling is bad.
>
> -troy
>
> > Given that definition, Johnny's Dad's MG won't be
> > reachable by a new (or a restarted) MGC until the his MG notices the
> > failure.  We must define a way for it to know ASAP!



From owner-megaco@fore.com  Wed May 23 10:33:34 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06057
	for ; Wed, 23 May 2001 10:33:34 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13373;
	Wed, 23 May 2001 10:26:04 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA29594
	for megaco-list; Wed, 23 May 2001 10:23:30 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA29585
	for ; Wed, 23 May 2001 10:23:28 -0400 (EDT)
Received: from slink12.ss7-link.com (mail.ss7-link.com [209.204.106.218])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13078
	for ; Wed, 23 May 2001 10:23:26 -0400 (EDT)
Received: by SLINK12 with Internet Mail Service (5.5.2650.21)
	id ; Wed, 23 May 2001 10:23:27 -0400
Message-ID: 
From: Dave Sclarsky 
To: "'Christian Groves'" ,
        Troy Cauble
	 
Cc: Dave Sclarsky ,
        "'Rosen, Brian'"
	 ,
        "'knayar@hss.hns.com'" , megaco@fore.com
Subject: RE: Polls of MGC
Date: Wed, 23 May 2001 10:23:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Christian,
What happens when the MGC wants to ring a phone on an MG that is a ResGW,
but that MG still thinks tbat it is connected to a 'broken' MGC?
DaveS.

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Wednesday, May 23, 2001 9:48 AM
> To: Troy Cauble
> Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com'; 
> megaco@fore.com
> Subject: Re: Polls of MGC
> 
> 
> G'Day Troy et all,
> 
> Sorry for the late support of No Polling. I still have not seen a
> definitive reason that the MG needs to poll the MGC. We have defined a
> master slave protocol with the MGC as the master. The MGC should be in
> control of error situations. 
> 
> I believe that it's enough that the MG can detect that the 
> MGC has gone
> down when it try to signal using any appropriate H.248 Commands ie.
> Add, Move, sub replies, Notify request, Service Change etc. Lack of
> timely response will indicate failure. The MG can then 
> re-register based
> on this.
> 
> If you look at the common MG use cases:
> 1. The MG is a trunking gateway. In this scenario enough 
> traffic will be
> generated to maintain a reasonable flow of signalling to minimise the
> time to detect errors. For a proper Telco solution you should 
> also have
> enough management systems/redundency to know what MGC to hand over to.
> 
> 2. The MG is a residential gateway. Signalling traffic is not 
> that great
> but interaction is only needed with the MGC when the end-user does
> something. Therefore the MG will find out about the failure at this
> time. Why generate unessary signalling across limited BW 
> links? There's
> the avalanche problems mentioned earlier but more importantly someone
> will have to pay for bandwidth this signalling takes which basically
> serves no purpose.
> Again in this scenario the MGC will hopefully be owned by someone who
> wants to offer a decent service and has the necessary management
> systems/reduncy. I do not envisage MG registration will take very long
> on a small residential gateway. Its a ServiceChange request/response
> round trip.
> 
> What ever the proposed package, service change reason/method, protocol
> update polling is unecessary.
> 
> Cheers, Christian
> 
> Troy Cauble wrote:
> > 
> > Dave Sclarsky wrote:
> > >
> > > Troy,
> > >
> > > It doesn't matter what the new (or restarted) MGC knows 
> or doesn't know.
> > > Megaco defines that the control association between MG 
> and MGC is ALWAYS
> > > initiated by the MG.
> > 
> > Then this definition is the problem and should be revisited.
> > 
> > Polling is bad.
> > 
> > -troy
> > 
> > > Given that definition, Johnny's Dad's MG won't be
> > > reachable by a new (or a restarted) MGC until the his MG 
> notices the
> > > failure.  We must define a way for it to know ASAP!
> 


From owner-megaco@fore.com  Wed May 23 10:48:33 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06339
	for ; Wed, 23 May 2001 10:48:32 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14428;
	Wed, 23 May 2001 10:37:12 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA03511
	for megaco-list; Wed, 23 May 2001 10:34:24 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03312
	for ; Wed, 23 May 2001 10:34:06 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14046
	for ; Wed, 23 May 2001 10:33:36 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACV05838;
	Wed, 23 May 2001 10:33:25 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Dave Sclarsky'" ,
        "'Christian Groves'" ,
        "'Troy Cauble'" 
Cc: "'Rosen, Brian'" , ,
        
Subject: RE: Polls of MGC
Date: Wed, 23 May 2001 10:37:05 -0400
Message-ID: <03d801c0e395$d75a5e70$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

HI Dave,
If the MG is connected to the "broken" MGC how can it receive commands from
two MGC's. The MG should reinitiate the registration for accepting messages
from the new MGC.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dave Sclarsky
Sent: Wednesday, May 23, 2001 10:23 AM
To: 'Christian Groves'; Troy Cauble
Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com'; megaco@fore.com
Subject: RE: Polls of MGC


Christian,
What happens when the MGC wants to ring a phone on an MG that is a ResGW,
but that MG still thinks tbat it is connected to a 'broken' MGC?
DaveS.

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Wednesday, May 23, 2001 9:48 AM
> To: Troy Cauble
> Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
> megaco@fore.com
> Subject: Re: Polls of MGC
>
>
> G'Day Troy et all,
>
> Sorry for the late support of No Polling. I still have not seen a
> definitive reason that the MG needs to poll the MGC. We have defined a
> master slave protocol with the MGC as the master. The MGC should be in
> control of error situations.
>
> I believe that it's enough that the MG can detect that the
> MGC has gone
> down when it try to signal using any appropriate H.248 Commands ie.
> Add, Move, sub replies, Notify request, Service Change etc. Lack of
> timely response will indicate failure. The MG can then
> re-register based
> on this.
>
> If you look at the common MG use cases:
> 1. The MG is a trunking gateway. In this scenario enough
> traffic will be
> generated to maintain a reasonable flow of signalling to minimise the
> time to detect errors. For a proper Telco solution you should
> also have
> enough management systems/redundency to know what MGC to hand over to.
>
> 2. The MG is a residential gateway. Signalling traffic is not
> that great
> but interaction is only needed with the MGC when the end-user does
> something. Therefore the MG will find out about the failure at this
> time. Why generate unessary signalling across limited BW
> links? There's
> the avalanche problems mentioned earlier but more importantly someone
> will have to pay for bandwidth this signalling takes which basically
> serves no purpose.
> Again in this scenario the MGC will hopefully be owned by someone who
> wants to offer a decent service and has the necessary management
> systems/reduncy. I do not envisage MG registration will take very long
> on a small residential gateway. Its a ServiceChange request/response
> round trip.
>
> What ever the proposed package, service change reason/method, protocol
> update polling is unecessary.
>
> Cheers, Christian
>
> Troy Cauble wrote:
> >
> > Dave Sclarsky wrote:
> > >
> > > Troy,
> > >
> > > It doesn't matter what the new (or restarted) MGC knows
> or doesn't know.
> > > Megaco defines that the control association between MG
> and MGC is ALWAYS
> > > initiated by the MG.
> >
> > Then this definition is the problem and should be revisited.
> >
> > Polling is bad.
> >
> > -troy
> >
> > > Given that definition, Johnny's Dad's MG won't be
> > > reachable by a new (or a restarted) MGC until the his MG
> notices the
> > > failure.  We must define a way for it to know ASAP!
>



From owner-megaco@fore.com  Wed May 23 10:59:06 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06548
	for ; Wed, 23 May 2001 10:59:05 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15566;
	Wed, 23 May 2001 10:46:34 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA07318
	for megaco-list; Wed, 23 May 2001 10:44:15 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07312
	for ; Wed, 23 May 2001 10:44:14 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15282
	for ; Wed, 23 May 2001 10:44:12 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Wed, 23 May 2001 09:44:59 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD94945811131@RADVPOST>
From: Dan Elbert 
To: "'Madhu Babu Brahmanapally'" ,
        "'Dave Sclarsky'"
	 ,
        "'Christian Groves'"
	 ,
        "'Troy Cauble'" 
Cc: "'Rosen, Brian'" , knayar@hss.hns.com,
        megaco@fore.com
Subject: RE: Polls of MGC
Date: Wed, 23 May 2001 09:44:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hi
I think the scenario can be as following:
1. The MGC fails without being able to send a "Handoff"
2. Later on the MGC restarts or a backup MGC comes up
In this case the MGC can never contact the MG because it doesn't know where
the MG is listening.
So the problem stands if the MGC needs to contact the MG before the MG
becomes aware that the connection with the MGC has been lost.

Dan

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Wednesday, May 23, 2001 10:37 AM
To: 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
Subject: RE: Polls of MGC

HI Dave,
If the MG is connected to the "broken" MGC how can it receive commands from
two MGC's. The MG should reinitiate the registration for accepting messages
from the new MGC.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dave Sclarsky
Sent: Wednesday, May 23, 2001 10:23 AM
To: 'Christian Groves'; Troy Cauble
Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com'; megaco@fore.com
Subject: RE: Polls of MGC


Christian,
What happens when the MGC wants to ring a phone on an MG that is a ResGW,
but that MG still thinks tbat it is connected to a 'broken' MGC?
DaveS.

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Wednesday, May 23, 2001 9:48 AM
> To: Troy Cauble
> Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
> megaco@fore.com
> Subject: Re: Polls of MGC
>
>
> G'Day Troy et all,
>
> Sorry for the late support of No Polling. I still have not seen a
> definitive reason that the MG needs to poll the MGC. We have defined a
> master slave protocol with the MGC as the master. The MGC should be in
> control of error situations.
>
> I believe that it's enough that the MG can detect that the
> MGC has gone
> down when it try to signal using any appropriate H.248 Commands ie.
> Add, Move, sub replies, Notify request, Service Change etc. Lack of
> timely response will indicate failure. The MG can then
> re-register based
> on this.
>
> If you look at the common MG use cases:
> 1. The MG is a trunking gateway. In this scenario enough
> traffic will be
> generated to maintain a reasonable flow of signalling to minimise the
> time to detect errors. For a proper Telco solution you should
> also have
> enough management systems/redundency to know what MGC to hand over to.
>
> 2. The MG is a residential gateway. Signalling traffic is not
> that great
> but interaction is only needed with the MGC when the end-user does
> something. Therefore the MG will find out about the failure at this
> time. Why generate unessary signalling across limited BW
> links? There's
> the avalanche problems mentioned earlier but more importantly someone
> will have to pay for bandwidth this signalling takes which basically
> serves no purpose.
> Again in this scenario the MGC will hopefully be owned by someone who
> wants to offer a decent service and has the necessary management
> systems/reduncy. I do not envisage MG registration will take very long
> on a small residential gateway. Its a ServiceChange request/response
> round trip.
>
> What ever the proposed package, service change reason/method, protocol
> update polling is unecessary.
>
> Cheers, Christian
>
> Troy Cauble wrote:
> >
> > Dave Sclarsky wrote:
> > >
> > > Troy,
> > >
> > > It doesn't matter what the new (or restarted) MGC knows
> or doesn't know.
> > > Megaco defines that the control association between MG
> and MGC is ALWAYS
> > > initiated by the MG.
> >
> > Then this definition is the problem and should be revisited.
> >
> > Polling is bad.
> >
> > -troy
> >
> > > Given that definition, Johnny's Dad's MG won't be
> > > reachable by a new (or a restarted) MGC until the his MG
> notices the
> > > failure.  We must define a way for it to know ASAP!
>


From owner-megaco@fore.com  Wed May 23 11:37:32 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07452
	for ; Wed, 23 May 2001 11:37:31 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA19032;
	Wed, 23 May 2001 11:22:31 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA17752
	for megaco-list; Wed, 23 May 2001 11:18:52 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA17748
	for ; Wed, 23 May 2001 11:18:51 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18660
	for ; Wed, 23 May 2001 11:18:49 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACV06557;
	Wed, 23 May 2001 11:18:23 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Dan Elbert'" ,
        "'Dave Sclarsky'" ,
        "'Christian Groves'" ,
        "'Troy Cauble'" 
Cc: "'Rosen, Brian'" , ,
        
Subject: RE: Polls of MGC
Date: Wed, 23 May 2001 11:22:03 -0400
Message-ID: <03d901c0e39c$1f519ee0$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <0D5BBF5D638DD4119E3400508BD94945811131@RADVPOST>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Dan/all,

A related query...Can a new MGC indicate to MG that it is now taking over
instead of the old MGC( I don't see any  servicechange method described in
the protocol). Doesn't this introduce any security threat???.

Regards

Madhubabu

-----Original Message-----
From: Dan Elbert [mailto:DElbert@radvision.com]
Sent: Wednesday, May 23, 2001 10:45 AM
To: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; 'Christian Groves';
'Troy Cauble'
Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
Subject: RE: Polls of MGC


Hi
I think the scenario can be as following:
1. The MGC fails without being able to send a "Handoff"
2. Later on the MGC restarts or a backup MGC comes up
In this case the MGC can never contact the MG because it doesn't know where
the MG is listening.
So the problem stands if the MGC needs to contact the MG before the MG
becomes aware that the connection with the MGC has been lost.

Dan

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Wednesday, May 23, 2001 10:37 AM
To: 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
Subject: RE: Polls of MGC

HI Dave,
If the MG is connected to the "broken" MGC how can it receive commands from
two MGC's. The MG should reinitiate the registration for accepting messages
from the new MGC.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dave Sclarsky
Sent: Wednesday, May 23, 2001 10:23 AM
To: 'Christian Groves'; Troy Cauble
Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com'; megaco@fore.com
Subject: RE: Polls of MGC


Christian,
What happens when the MGC wants to ring a phone on an MG that is a ResGW,
but that MG still thinks tbat it is connected to a 'broken' MGC?
DaveS.

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Wednesday, May 23, 2001 9:48 AM
> To: Troy Cauble
> Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
> megaco@fore.com
> Subject: Re: Polls of MGC
>
>
> G'Day Troy et all,
>
> Sorry for the late support of No Polling. I still have not seen a
> definitive reason that the MG needs to poll the MGC. We have defined a
> master slave protocol with the MGC as the master. The MGC should be in
> control of error situations.
>
> I believe that it's enough that the MG can detect that the
> MGC has gone
> down when it try to signal using any appropriate H.248 Commands ie.
> Add, Move, sub replies, Notify request, Service Change etc. Lack of
> timely response will indicate failure. The MG can then
> re-register based
> on this.
>
> If you look at the common MG use cases:
> 1. The MG is a trunking gateway. In this scenario enough
> traffic will be
> generated to maintain a reasonable flow of signalling to minimise the
> time to detect errors. For a proper Telco solution you should
> also have
> enough management systems/redundency to know what MGC to hand over to.
>
> 2. The MG is a residential gateway. Signalling traffic is not
> that great
> but interaction is only needed with the MGC when the end-user does
> something. Therefore the MG will find out about the failure at this
> time. Why generate unessary signalling across limited BW
> links? There's
> the avalanche problems mentioned earlier but more importantly someone
> will have to pay for bandwidth this signalling takes which basically
> serves no purpose.
> Again in this scenario the MGC will hopefully be owned by someone who
> wants to offer a decent service and has the necessary management
> systems/reduncy. I do not envisage MG registration will take very long
> on a small residential gateway. Its a ServiceChange request/response
> round trip.
>
> What ever the proposed package, service change reason/method, protocol
> update polling is unecessary.
>
> Cheers, Christian
>
> Troy Cauble wrote:
> >
> > Dave Sclarsky wrote:
> > >
> > > Troy,
> > >
> > > It doesn't matter what the new (or restarted) MGC knows
> or doesn't know.
> > > Megaco defines that the control association between MG
> and MGC is ALWAYS
> > > initiated by the MG.
> >
> > Then this definition is the problem and should be revisited.
> >
> > Polling is bad.
> >
> > -troy
> >
> > > Given that definition, Johnny's Dad's MG won't be
> > > reachable by a new (or a restarted) MGC until the his MG
> notices the
> > > failure.  We must define a way for it to know ASAP!
>



From owner-megaco@fore.com  Wed May 23 11:41:11 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07581
	for ; Wed, 23 May 2001 11:41:10 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA19947;
	Wed, 23 May 2001 11:30:57 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA20757
	for megaco-list; Wed, 23 May 2001 11:28:36 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA20716
	for ; Wed, 23 May 2001 11:28:31 -0400 (EDT)
Received: from slink12.ss7-link.com (mail.ss7-link.com [209.204.106.218])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA19604
	for ; Wed, 23 May 2001 11:28:29 -0400 (EDT)
Received: by SLINK12 with Internet Mail Service (5.5.2650.21)
	id ; Wed, 23 May 2001 11:28:30 -0400
Message-ID: 
From: Dave Sclarsky 
To: "'Madhu Babu Brahmanapally'" ,
        "'Dan Elbert'"
	 ,
        Dave Sclarsky ,
        "'Christian Groves'" ,
        "'Troy Cauble'"
	 
Cc: "'Rosen, Brian'" , knayar@hss.hns.com,
        megaco@fore.com
Subject: RE: Polls of MGC
Date: Wed, 23 May 2001 11:28:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Madhubabu,
This is exactly the issue.  Since it is the MG that initiates the control
association, the new MGC cannot tell the MG anything.
DaveS.  

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Wednesday, May 23, 2001 11:22 AM
> To: 'Dan Elbert'; 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
> Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> Hi Dan/all,
> 
> A related query...Can a new MGC indicate to MG that it is now 
> taking over
> instead of the old MGC( I don't see any  servicechange method 
> described in
> the protocol). Doesn't this introduce any security threat???.
> 
> Regards
> 
> Madhubabu
> 
> -----Original Message-----
> From: Dan Elbert [mailto:DElbert@radvision.com]
> Sent: Wednesday, May 23, 2001 10:45 AM
> To: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; 'Christian Groves';
> 'Troy Cauble'
> Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> Hi
> I think the scenario can be as following:
> 1. The MGC fails without being able to send a "Handoff"
> 2. Later on the MGC restarts or a backup MGC comes up
> In this case the MGC can never contact the MG because it 
> doesn't know where
> the MG is listening.
> So the problem stands if the MGC needs to contact the MG before the MG
> becomes aware that the connection with the MGC has been lost.
> 
> Dan
> 
> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Wednesday, May 23, 2001 10:37 AM
> To: 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
> Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> Subject: RE: Polls of MGC
> 
> HI Dave,
> If the MG is connected to the "broken" MGC how can it receive 
> commands from
> two MGC's. The MG should reinitiate the registration for 
> accepting messages
> from the new MGC.
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dave Sclarsky
> Sent: Wednesday, May 23, 2001 10:23 AM
> To: 'Christian Groves'; Troy Cauble
> Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com'; 
> megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> Christian,
> What happens when the MGC wants to ring a phone on an MG that 
> is a ResGW,
> but that MG still thinks tbat it is connected to a 'broken' MGC?
> DaveS.
> 
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Wednesday, May 23, 2001 9:48 AM
> > To: Troy Cauble
> > Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
> > megaco@fore.com
> > Subject: Re: Polls of MGC
> >
> >
> > G'Day Troy et all,
> >
> > Sorry for the late support of No Polling. I still have not seen a
> > definitive reason that the MG needs to poll the MGC. We 
> have defined a
> > master slave protocol with the MGC as the master. The MGC 
> should be in
> > control of error situations.
> >
> > I believe that it's enough that the MG can detect that the
> > MGC has gone
> > down when it try to signal using any appropriate H.248 Commands ie.
> > Add, Move, sub replies, Notify request, Service Change etc. Lack of
> > timely response will indicate failure. The MG can then
> > re-register based
> > on this.
> >
> > If you look at the common MG use cases:
> > 1. The MG is a trunking gateway. In this scenario enough
> > traffic will be
> > generated to maintain a reasonable flow of signalling to 
> minimise the
> > time to detect errors. For a proper Telco solution you should
> > also have
> > enough management systems/redundency to know what MGC to 
> hand over to.
> >
> > 2. The MG is a residential gateway. Signalling traffic is not
> > that great
> > but interaction is only needed with the MGC when the end-user does
> > something. Therefore the MG will find out about the failure at this
> > time. Why generate unessary signalling across limited BW
> > links? There's
> > the avalanche problems mentioned earlier but more 
> importantly someone
> > will have to pay for bandwidth this signalling takes which basically
> > serves no purpose.
> > Again in this scenario the MGC will hopefully be owned by 
> someone who
> > wants to offer a decent service and has the necessary management
> > systems/reduncy. I do not envisage MG registration will 
> take very long
> > on a small residential gateway. Its a ServiceChange request/response
> > round trip.
> >
> > What ever the proposed package, service change 
> reason/method, protocol
> > update polling is unecessary.
> >
> > Cheers, Christian
> >
> > Troy Cauble wrote:
> > >
> > > Dave Sclarsky wrote:
> > > >
> > > > Troy,
> > > >
> > > > It doesn't matter what the new (or restarted) MGC knows
> > or doesn't know.
> > > > Megaco defines that the control association between MG
> > and MGC is ALWAYS
> > > > initiated by the MG.
> > >
> > > Then this definition is the problem and should be revisited.
> > >
> > > Polling is bad.
> > >
> > > -troy
> > >
> > > > Given that definition, Johnny's Dad's MG won't be
> > > > reachable by a new (or a restarted) MGC until the his MG
> > notices the
> > > > failure.  We must define a way for it to know ASAP!
> >
> 


From owner-megaco@fore.com  Wed May 23 12:26:20 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08924
	for ; Wed, 23 May 2001 12:26:19 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22391;
	Wed, 23 May 2001 11:54:18 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA26689
	for megaco-list; Wed, 23 May 2001 11:52:10 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26675
	for ; Wed, 23 May 2001 11:52:08 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22176
	for ; Wed, 23 May 2001 11:52:06 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACV07046;
	Wed, 23 May 2001 11:51:16 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Dave Sclarsky'" ,
        "'Dan Elbert'" ,
        "'Christian Groves'" ,
        "'Troy Cauble'" 
Cc: "'Rosen, Brian'" , ,
        
Subject: RE: Polls of MGC
Date: Wed, 23 May 2001 11:54:56 -0400
Message-ID: <03dd01c0e3a0$b73ec2b0$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Dave/all,
MG can reinitiate new control association due to two possible scenarios
1) MG does periodic (period to be decided) polling and identifies the MGC's
failure. OR
2) MG if doesn't receive response for any of its commands from the MGC.

But now the query is which one of the two needs to be followed???  AND
WHY???

Without any new addition (and w/o processing overhead in MG/MGC) in the
protocol the case (2) works. So, one need to asses the additional gain by
adding the new polling logic.




Regards
Madhubabu


-----Original Message-----
From: Dave Sclarsky [mailto:Dave.Sclarsky@radisys.com]
Sent: Wednesday, May 23, 2001 11:28 AM
To: 'Madhu Babu Brahmanapally'; 'Dan Elbert'; Dave Sclarsky; 'Christian
Groves'; 'Troy Cauble'
Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
Subject: RE: Polls of MGC


Madhubabu,
This is exactly the issue.  Since it is the MG that initiates the control
association, the new MGC cannot tell the MG anything.
DaveS.

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Wednesday, May 23, 2001 11:22 AM
> To: 'Dan Elbert'; 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
> Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> Subject: RE: Polls of MGC
>
>
> Hi Dan/all,
>
> A related query...Can a new MGC indicate to MG that it is now
> taking over
> instead of the old MGC( I don't see any  servicechange method
> described in
> the protocol). Doesn't this introduce any security threat???.
>
> Regards
>
> Madhubabu
>
> -----Original Message-----
> From: Dan Elbert [mailto:DElbert@radvision.com]
> Sent: Wednesday, May 23, 2001 10:45 AM
> To: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; 'Christian Groves';
> 'Troy Cauble'
> Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> Subject: RE: Polls of MGC
>
>
> Hi
> I think the scenario can be as following:
> 1. The MGC fails without being able to send a "Handoff"
> 2. Later on the MGC restarts or a backup MGC comes up
> In this case the MGC can never contact the MG because it
> doesn't know where
> the MG is listening.
> So the problem stands if the MGC needs to contact the MG before the MG
> becomes aware that the connection with the MGC has been lost.
>
> Dan
>
> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Wednesday, May 23, 2001 10:37 AM
> To: 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
> Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> Subject: RE: Polls of MGC
>
> HI Dave,
> If the MG is connected to the "broken" MGC how can it receive
> commands from
> two MGC's. The MG should reinitiate the registration for
> accepting messages
> from the new MGC.
>
> Regards
> Madhubabu
>
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dave Sclarsky
> Sent: Wednesday, May 23, 2001 10:23 AM
> To: 'Christian Groves'; Troy Cauble
> Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
> megaco@fore.com
> Subject: RE: Polls of MGC
>
>
> Christian,
> What happens when the MGC wants to ring a phone on an MG that
> is a ResGW,
> but that MG still thinks tbat it is connected to a 'broken' MGC?
> DaveS.
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Wednesday, May 23, 2001 9:48 AM
> > To: Troy Cauble
> > Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
> > megaco@fore.com
> > Subject: Re: Polls of MGC
> >
> >
> > G'Day Troy et all,
> >
> > Sorry for the late support of No Polling. I still have not seen a
> > definitive reason that the MG needs to poll the MGC. We
> have defined a
> > master slave protocol with the MGC as the master. The MGC
> should be in
> > control of error situations.
> >
> > I believe that it's enough that the MG can detect that the
> > MGC has gone
> > down when it try to signal using any appropriate H.248 Commands ie.
> > Add, Move, sub replies, Notify request, Service Change etc. Lack of
> > timely response will indicate failure. The MG can then
> > re-register based
> > on this.
> >
> > If you look at the common MG use cases:
> > 1. The MG is a trunking gateway. In this scenario enough
> > traffic will be
> > generated to maintain a reasonable flow of signalling to
> minimise the
> > time to detect errors. For a proper Telco solution you should
> > also have
> > enough management systems/redundency to know what MGC to
> hand over to.
> >
> > 2. The MG is a residential gateway. Signalling traffic is not
> > that great
> > but interaction is only needed with the MGC when the end-user does
> > something. Therefore the MG will find out about the failure at this
> > time. Why generate unessary signalling across limited BW
> > links? There's
> > the avalanche problems mentioned earlier but more
> importantly someone
> > will have to pay for bandwidth this signalling takes which basically
> > serves no purpose.
> > Again in this scenario the MGC will hopefully be owned by
> someone who
> > wants to offer a decent service and has the necessary management
> > systems/reduncy. I do not envisage MG registration will
> take very long
> > on a small residential gateway. Its a ServiceChange request/response
> > round trip.
> >
> > What ever the proposed package, service change
> reason/method, protocol
> > update polling is unecessary.
> >
> > Cheers, Christian
> >
> > Troy Cauble wrote:
> > >
> > > Dave Sclarsky wrote:
> > > >
> > > > Troy,
> > > >
> > > > It doesn't matter what the new (or restarted) MGC knows
> > or doesn't know.
> > > > Megaco defines that the control association between MG
> > and MGC is ALWAYS
> > > > initiated by the MG.
> > >
> > > Then this definition is the problem and should be revisited.
> > >
> > > Polling is bad.
> > >
> > > -troy
> > >
> > > > Given that definition, Johnny's Dad's MG won't be
> > > > reachable by a new (or a restarted) MGC until the his MG
> > notices the
> > > > failure.  We must define a way for it to know ASAP!
> >
>



From owner-megaco@fore.com  Wed May 23 12:33:24 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09105
	for ; Wed, 23 May 2001 12:33:23 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA25330;
	Wed, 23 May 2001 12:25:26 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA05314
	for megaco-list; Wed, 23 May 2001 12:23:06 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA05303
	for ; Wed, 23 May 2001 12:23:04 -0400 (EDT)
Received: from slink12.ss7-link.com (mail.ss7-link.com [209.204.106.218])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA25007
	for ; Wed, 23 May 2001 12:23:01 -0400 (EDT)
Received: by SLINK12 with Internet Mail Service (5.5.2650.21)
	id ; Wed, 23 May 2001 12:23:03 -0400
Message-ID: 
From: Dave Sclarsky 
To: "'Madhu Babu Brahmanapally'" ,
        Dave Sclarsky
	 ,
        "'Dan Elbert'" ,
        "'Christian Groves'" ,
        "'Troy Cauble'"
	 
Cc: "'Rosen, Brian'" , knayar@hss.hns.com,
        megaco@fore.com
Subject: RE: Polls of MGC
Date: Wed, 23 May 2001 12:22:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Madhubabu,

The assumption that (from Christians email below) "interaction is only
needed with the MGC when the end-user does something" ignores the
fact that sometimes the MGC needs to initiate an interaction because
an end-user on a DIFFERENT MG did something.

Here is a situation where case 2 is not sufficient:

 o UserX is connected to MG1 and UserY is connected to MG2.
 o MG1 and MG2 have established control associations with MGCPrimary.
 o UserY goes to sleep.
 o MGCPrimary goes down, and MGCSecondary takes over.
 o So far, neither MG has a control association to MGCSecondary.
 o UserX goes off-hook.
 o MG1 sends Notify to MGCPrimary.
 o MG1 notices that MGCPrimary is gone, and establishes with MGCSecondary.
 o UserX never hears dialtone and hangs up.
 o UserX goes off-hook again, hoping desperately to get dialtone.
 o MG1 sends Notify to MGCSecondary.
 o UserX hears dialtone, so dials the phone number of UserY.
 o MGCSecondary has no control association with MG2, so the phone never
rings!

We absolutely need some way for an MG to notice that an MGC has gone away
even
when there is no other activity.  Maybe this situation doesn't exists on a
Trunking Gateway, but there are other types of MGs in the network, and the
protocol must support all of them!

DaveS.

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Wednesday, May 23, 2001 11:55 AM
> To: 'Dave Sclarsky'; 'Dan Elbert'; 'Christian Groves'; 'Troy Cauble'
> Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> Hi Dave/all,
> MG can reinitiate new control association due to two possible 
> scenarios
> 1) MG does periodic (period to be decided) polling and 
> identifies the MGC's
> failure. OR
> 2) MG if doesn't receive response for any of its commands 
> from the MGC.
> 
> But now the query is which one of the two needs to be followed???  AND
> WHY???
> 
> Without any new addition (and w/o processing overhead in 
> MG/MGC) in the
> protocol the case (2) works. So, one need to asses the 
> additional gain by
> adding the new polling logic.
> 
> 
> 
> 
> Regards
> Madhubabu
> 
> 
> -----Original Message-----
> From: Dave Sclarsky [mailto:Dave.Sclarsky@radisys.com]
> Sent: Wednesday, May 23, 2001 11:28 AM
> To: 'Madhu Babu Brahmanapally'; 'Dan Elbert'; Dave Sclarsky; 
> 'Christian
> Groves'; 'Troy Cauble'
> Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> Madhubabu,
> This is exactly the issue.  Since it is the MG that initiates 
> the control
> association, the new MGC cannot tell the MG anything.
> DaveS.
> 
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > Sent: Wednesday, May 23, 2001 11:22 AM
> > To: 'Dan Elbert'; 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
> > Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> > Subject: RE: Polls of MGC
> >
> >
> > Hi Dan/all,
> >
> > A related query...Can a new MGC indicate to MG that it is now
> > taking over
> > instead of the old MGC( I don't see any  servicechange method
> > described in
> > the protocol). Doesn't this introduce any security threat???.
> >
> > Regards
> >
> > Madhubabu
> >
> > -----Original Message-----
> > From: Dan Elbert [mailto:DElbert@radvision.com]
> > Sent: Wednesday, May 23, 2001 10:45 AM
> > To: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; 'Christian Groves';
> > 'Troy Cauble'
> > Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> > Subject: RE: Polls of MGC
> >
> >
> > Hi
> > I think the scenario can be as following:
> > 1. The MGC fails without being able to send a "Handoff"
> > 2. Later on the MGC restarts or a backup MGC comes up
> > In this case the MGC can never contact the MG because it
> > doesn't know where
> > the MG is listening.
> > So the problem stands if the MGC needs to contact the MG 
> before the MG
> > becomes aware that the connection with the MGC has been lost.
> >
> > Dan
> >
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > Sent: Wednesday, May 23, 2001 10:37 AM
> > To: 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
> > Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> > Subject: RE: Polls of MGC
> >
> > HI Dave,
> > If the MG is connected to the "broken" MGC how can it receive
> > commands from
> > two MGC's. The MG should reinitiate the registration for
> > accepting messages
> > from the new MGC.
> >
> > Regards
> > Madhubabu
> >
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of 
> Dave Sclarsky
> > Sent: Wednesday, May 23, 2001 10:23 AM
> > To: 'Christian Groves'; Troy Cauble
> > Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
> > megaco@fore.com
> > Subject: RE: Polls of MGC
> >
> >
> > Christian,
> > What happens when the MGC wants to ring a phone on an MG that
> > is a ResGW,
> > but that MG still thinks tbat it is connected to a 'broken' MGC?
> > DaveS.
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > > Sent: Wednesday, May 23, 2001 9:48 AM
> > > To: Troy Cauble
> > > Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
> > > megaco@fore.com
> > > Subject: Re: Polls of MGC
> > >
> > >
> > > G'Day Troy et all,
> > >
> > > Sorry for the late support of No Polling. I still have not seen a
> > > definitive reason that the MG needs to poll the MGC. We
> > have defined a
> > > master slave protocol with the MGC as the master. The MGC
> > should be in
> > > control of error situations.
> > >
> > > I believe that it's enough that the MG can detect that the
> > > MGC has gone
> > > down when it try to signal using any appropriate H.248 
> Commands ie.
> > > Add, Move, sub replies, Notify request, Service Change 
> etc. Lack of
> > > timely response will indicate failure. The MG can then
> > > re-register based
> > > on this.
> > >
> > > If you look at the common MG use cases:
> > > 1. The MG is a trunking gateway. In this scenario enough
> > > traffic will be
> > > generated to maintain a reasonable flow of signalling to
> > minimise the
> > > time to detect errors. For a proper Telco solution you should
> > > also have
> > > enough management systems/redundency to know what MGC to
> > hand over to.
> > >
> > > 2. The MG is a residential gateway. Signalling traffic is not
> > > that great
> > > but interaction is only needed with the MGC when the end-user does
> > > something. Therefore the MG will find out about the 
> failure at this
> > > time. Why generate unessary signalling across limited BW
> > > links? There's
> > > the avalanche problems mentioned earlier but more
> > importantly someone
> > > will have to pay for bandwidth this signalling takes 
> which basically
> > > serves no purpose.
> > > Again in this scenario the MGC will hopefully be owned by
> > someone who
> > > wants to offer a decent service and has the necessary management
> > > systems/reduncy. I do not envisage MG registration will
> > take very long
> > > on a small residential gateway. Its a ServiceChange 
> request/response
> > > round trip.
> > >
> > > What ever the proposed package, service change
> > reason/method, protocol
> > > update polling is unecessary.
> > >
> > > Cheers, Christian
> > >
> > > Troy Cauble wrote:
> > > >
> > > > Dave Sclarsky wrote:
> > > > >
> > > > > Troy,
> > > > >
> > > > > It doesn't matter what the new (or restarted) MGC knows
> > > or doesn't know.
> > > > > Megaco defines that the control association between MG
> > > and MGC is ALWAYS
> > > > > initiated by the MG.
> > > >
> > > > Then this definition is the problem and should be revisited.
> > > >
> > > > Polling is bad.
> > > >
> > > > -troy
> > > >
> > > > > Given that definition, Johnny's Dad's MG won't be
> > > > > reachable by a new (or a restarted) MGC until the his MG
> > > notices the
> > > > > failure.  We must define a way for it to know ASAP!
> > >
> >
> 


From owner-megaco@fore.com  Wed May 23 12:34:52 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09154
	for ; Wed, 23 May 2001 12:34:52 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA25106;
	Wed, 23 May 2001 12:23:54 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA05029
	for megaco-list; Wed, 23 May 2001 12:21:27 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA05020
	for ; Wed, 23 May 2001 12:21:26 -0400 (EDT)
Received: from lmmx1.fl.icn.siemens.com (lmmx1.fl.icn.siemens.com [192.132.51.129])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA24899
	for ; Wed, 23 May 2001 12:21:23 -0400 (EDT)
Received: from lmyr210a.lm.ssc.siemens.com (lmyr210a.lm.ssc.siemens.com [165.218.224.44])
	by lmmx1.fl.icn.siemens.com (8.9.3/8.9.3) with ESMTP id MAA27998;
	Wed, 23 May 2001 12:17:50 -0400 (EDT)
Received: by lmyr210a.lm.ssc.siemens.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 23 May 2001 12:20:43 -0400
Message-ID: <637FAED82678D311AFAE0008C791D2490269972D@lmyr227a.lm.ssc.siemens.com>
From: "Knight, Ty" 
To: "'Madhu Babu Brahmanapally'" ,
        "'Dave Sclarsky'"
	 ,
        "'Dan Elbert'" ,
        "'Christian Groves'" ,
        "'Troy Cauble'"
	 
Cc: "'Rosen, Brian'" , knayar@hss.hns.com,
        megaco@fore.com
Subject: RE: Polls of MGC
Date: Wed, 23 May 2001 12:20:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hello Madhubabu / all,

#2 only works if there is active messaging. It seems to me that unless we
can guarantee that there is always message traffic from the MG to the MGC,
it alone is not a solution.  #1 is merely a way to guarantee traffic. 

A simple problematic scenario is as follows (for a trunking solution):

	1. MG after cold start is sending registration SvcChg to MGC. There
is no active callp.
	2. MGC accepts the association and sends the SvcChg reply to the MG.
Both are happy.
      3. Before any callp can be started, the MGC recovers.

The MG will never attempt to contact the MGC. It especially won't
re-register since it doesn't detect a problem. The MGC can't send a message
to the MG because the MGC has lost it's association data and doesn't know
which port to send it to.
	
Regards,
Ty

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Wednesday, May 23, 2001 11:55 AM
To: 'Dave Sclarsky'; 'Dan Elbert'; 'Christian Groves'; 'Troy Cauble'
Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
Subject: RE: Polls of MGC


Hi Dave/all,
MG can reinitiate new control association due to two possible scenarios
1) MG does periodic (period to be decided) polling and identifies the MGC's
failure. OR
2) MG if doesn't receive response for any of its commands from the MGC.

But now the query is which one of the two needs to be followed???  AND
WHY???

Without any new addition (and w/o processing overhead in MG/MGC) in the
protocol the case (2) works. So, one need to asses the additional gain by
adding the new polling logic.




Regards
Madhubabu


-----Original Message-----
From: Dave Sclarsky [mailto:Dave.Sclarsky@radisys.com]
Sent: Wednesday, May 23, 2001 11:28 AM
To: 'Madhu Babu Brahmanapally'; 'Dan Elbert'; Dave Sclarsky; 'Christian
Groves'; 'Troy Cauble'
Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
Subject: RE: Polls of MGC


Madhubabu,
This is exactly the issue.  Since it is the MG that initiates the control
association, the new MGC cannot tell the MG anything.
DaveS.

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Wednesday, May 23, 2001 11:22 AM
> To: 'Dan Elbert'; 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
> Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> Subject: RE: Polls of MGC
>
>
> Hi Dan/all,
>
> A related query...Can a new MGC indicate to MG that it is now
> taking over
> instead of the old MGC( I don't see any  servicechange method
> described in
> the protocol). Doesn't this introduce any security threat???.
>
> Regards
>
> Madhubabu
>
> -----Original Message-----
> From: Dan Elbert [mailto:DElbert@radvision.com]
> Sent: Wednesday, May 23, 2001 10:45 AM
> To: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; 'Christian Groves';
> 'Troy Cauble'
> Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> Subject: RE: Polls of MGC
>
>
> Hi
> I think the scenario can be as following:
> 1. The MGC fails without being able to send a "Handoff"
> 2. Later on the MGC restarts or a backup MGC comes up
> In this case the MGC can never contact the MG because it
> doesn't know where
> the MG is listening.
> So the problem stands if the MGC needs to contact the MG before the MG
> becomes aware that the connection with the MGC has been lost.
>
> Dan
>
> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Wednesday, May 23, 2001 10:37 AM
> To: 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
> Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> Subject: RE: Polls of MGC
>
> HI Dave,
> If the MG is connected to the "broken" MGC how can it receive
> commands from
> two MGC's. The MG should reinitiate the registration for
> accepting messages
> from the new MGC.
>
> Regards
> Madhubabu
>
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dave Sclarsky
> Sent: Wednesday, May 23, 2001 10:23 AM
> To: 'Christian Groves'; Troy Cauble
> Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
> megaco@fore.com
> Subject: RE: Polls of MGC
>
>
> Christian,
> What happens when the MGC wants to ring a phone on an MG that
> is a ResGW,
> but that MG still thinks tbat it is connected to a 'broken' MGC?
> DaveS.
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Wednesday, May 23, 2001 9:48 AM
> > To: Troy Cauble
> > Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
> > megaco@fore.com
> > Subject: Re: Polls of MGC
> >
> >
> > G'Day Troy et all,
> >
> > Sorry for the late support of No Polling. I still have not seen a
> > definitive reason that the MG needs to poll the MGC. We
> have defined a
> > master slave protocol with the MGC as the master. The MGC
> should be in
> > control of error situations.
> >
> > I believe that it's enough that the MG can detect that the
> > MGC has gone
> > down when it try to signal using any appropriate H.248 Commands ie.
> > Add, Move, sub replies, Notify request, Service Change etc. Lack of
> > timely response will indicate failure. The MG can then
> > re-register based
> > on this.
> >
> > If you look at the common MG use cases:
> > 1. The MG is a trunking gateway. In this scenario enough
> > traffic will be
> > generated to maintain a reasonable flow of signalling to
> minimise the
> > time to detect errors. For a proper Telco solution you should
> > also have
> > enough management systems/redundency to know what MGC to
> hand over to.
> >
> > 2. The MG is a residential gateway. Signalling traffic is not
> > that great
> > but interaction is only needed with the MGC when the end-user does
> > something. Therefore the MG will find out about the failure at this
> > time. Why generate unessary signalling across limited BW
> > links? There's
> > the avalanche problems mentioned earlier but more
> importantly someone
> > will have to pay for bandwidth this signalling takes which basically
> > serves no purpose.
> > Again in this scenario the MGC will hopefully be owned by
> someone who
> > wants to offer a decent service and has the necessary management
> > systems/reduncy. I do not envisage MG registration will
> take very long
> > on a small residential gateway. Its a ServiceChange request/response
> > round trip.
> >
> > What ever the proposed package, service change
> reason/method, protocol
> > update polling is unecessary.
> >
> > Cheers, Christian
> >
> > Troy Cauble wrote:
> > >
> > > Dave Sclarsky wrote:
> > > >
> > > > Troy,
> > > >
> > > > It doesn't matter what the new (or restarted) MGC knows
> > or doesn't know.
> > > > Megaco defines that the control association between MG
> > and MGC is ALWAYS
> > > > initiated by the MG.
> > >
> > > Then this definition is the problem and should be revisited.
> > >
> > > Polling is bad.
> > >
> > > -troy
> > >
> > > > Given that definition, Johnny's Dad's MG won't be
> > > > reachable by a new (or a restarted) MGC until the his MG
> > notices the
> > > > failure.  We must define a way for it to know ASAP!
> >
>


From owner-megaco@fore.com  Wed May 23 12:45:11 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09396
	for ; Wed, 23 May 2001 12:45:10 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA26198;
	Wed, 23 May 2001 12:35:08 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA07348
	for megaco-list; Wed, 23 May 2001 12:33:00 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA07340
	for ; Wed, 23 May 2001 12:32:58 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA26021
	for ; Wed, 23 May 2001 12:32:56 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4NGWsdQ008877
	for ; Wed, 23 May 2001 11:32:55 -0500 (CDT)
From: "Paul Long" 
To: 
Subject: RE: Clarification in RFC-3015 for domainAddress related to IPV6address
Date: Wed, 23 May 2001 11:32:53 -0500
Message-ID: 
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: <65256A55.00310A91.00@sandesh.hss.hns.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Amit,

Yes, as far as I understand, these are all syntactically correct. I'm not
familiar enough with IPv6 to know whether those particular values make
sense, but they are at least constructed correctly.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: akalra@hss.hns.com [mailto:akalra@hss.hns.com]
Sent: Wednesday, May 23, 2001 3:57 AM
To: Paul Long
Cc: megaco@fore.com
Subject: RE: Clarification in RFC-3015 for domainAddress related to
IPV6address




Hi Paul,
     Thanks for the reply, can you provide some more clarification on:

The expansion of an IPV6address can be one of the following then.

      FFFF::
      FFFF::FFFF
      ::
      ::FFFF
      FFFF
      FFFF:::IPV4address
      FFFF::FFFF:IPV4address
      :::IPV4address
      ::FFFF:IPV4address
      FFFF:IPV4address


Going by the given expansion of hexpart and IPV6address rules in the grammar
in
RFC 3015.
Are all the above cases valid for an IPV6address?

regards/
Amit



From owner-megaco@fore.com  Wed May 23 13:00:11 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09772
	for ; Wed, 23 May 2001 13:00:11 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA27756;
	Wed, 23 May 2001 12:52:05 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA11121
	for megaco-list; Wed, 23 May 2001 12:49:58 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA11113
	for ; Wed, 23 May 2001 12:49:57 -0400 (EDT)
Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA27555
	for ; Wed, 23 May 2001 12:49:54 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4NGnsu3027205
	for ; Wed, 23 May 2001 11:49:54 -0500
From: "Paul Long" 
To: 
Subject: RE: Polls of MGC
Date: Wed, 23 May 2001 11:49:51 -0500
Message-ID: 
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: <3B0BBF9E.4340CCB7@ericsson.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Christian,

As Dave said, your #2 does not consider an incoming call. It is therefore
_not_ true that "interaction is only needed with the MGC when the end-user
does something." Without periodic signaling between the MG and MGC whereby
the MG can detect MGC failure and switch to an operative MGC, incoming calls
will be missed after MGC failure and until there is end-user activity.
Period. Are you saying that this is satisfactory behavior given the penalty
of extra bandwidth consumption that periodic signaling would entail? That's
a valid position, but I want to be sure that you have taken this into
consideration. Maybe you and others are saying that losing an association is
like leaving the phone off the hook--the end user will miss incoming calls
until he or she needs to make a call.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Christian Groves
Sent: Wednesday, May 23, 2001 8:48 AM
To: Troy Cauble
Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com'; megaco@fore.com
Subject: Re: Polls of MGC


G'Day Troy et all,

Sorry for the late support of No Polling. I still have not seen a
definitive reason that the MG needs to poll the MGC. We have defined a
master slave protocol with the MGC as the master. The MGC should be in
control of error situations.

I believe that it's enough that the MG can detect that the MGC has gone
down when it try to signal using any appropriate H.248 Commands ie.
Add, Move, sub replies, Notify request, Service Change etc. Lack of
timely response will indicate failure. The MG can then re-register based
on this.

If you look at the common MG use cases:
1. The MG is a trunking gateway. In this scenario enough traffic will be
generated to maintain a reasonable flow of signalling to minimise the
time to detect errors. For a proper Telco solution you should also have
enough management systems/redundency to know what MGC to hand over to.

2. The MG is a residential gateway. Signalling traffic is not that great
but interaction is only needed with the MGC when the end-user does
something. Therefore the MG will find out about the failure at this
time. Why generate unessary signalling across limited BW links? There's
the avalanche problems mentioned earlier but more importantly someone
will have to pay for bandwidth this signalling takes which basically
serves no purpose.
Again in this scenario the MGC will hopefully be owned by someone who
wants to offer a decent service and has the necessary management
systems/reduncy. I do not envisage MG registration will take very long
on a small residential gateway. Its a ServiceChange request/response
round trip.

What ever the proposed package, service change reason/method, protocol
update polling is unecessary.

Cheers, Christian



From owner-megaco@fore.com  Wed May 23 15:04:23 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12290
	for ; Wed, 23 May 2001 15:04:22 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA07623;
	Wed, 23 May 2001 14:53:17 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA12251
	for megaco-list; Wed, 23 May 2001 14:49:55 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA12240
	for ; Wed, 23 May 2001 14:49:53 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id OAA07289
	for ; Wed, 23 May 2001 14:49:51 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id OAA12510; Wed, 23 May 2001 14:49:45 -0400
Received: from ztcfd004.ca.nortel.com by zcars04e.nortelnetworks.com;
          Wed, 23 May 2001 14:49:37 -0400
Received: by ztcfd004.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 23 May 2001 14:49:36 -0400
Message-ID: <45D2A43C1913D51180F40000F89CB874062E2D@nrtpde0a.us.nortel.com>
From: "Michael Brown" 
To: megaco@fore.com
Subject: RE: Polls of MGC
Date: Wed, 23 May 2001 14:49:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E3B9.1D82F330"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E3B9.1D82F330
Content-Type: text/plain;
	charset="iso-8859-1"

Hello all,

   Given all the traffic on this thread and that I was content that my
opinion was being expressed by others, I didn't feel compelled to post. But
since this topic seems to be going around again...

   I am also in the camp that polling BY the MG is unnecessary. Until
Christian's post, I think the biggest consideration that has not been taken
into account is that any reliable telephony system/network requires that
there is a robust network management system. IMHO, the scenarios proposed
that SEEM to point to using a polling mechanism (MGC has gone down and calls
to the MG will simply fail) will not happen. If an MGC crashes before being
able to a initiate graceful recovery/transition, it will not go unnoticed
from the network management perspective. This will (as suggested earlier) be
considered to be a "reportable" outage and I don't believe that any operator
or (potentially) regulatory agency is going to be content to say "it's OK...
service will be restored eventually".

   On the other hand in order to support the scenario in Megaco where the MG
autonomously detects an MGC outage and "rehomes" on a secondary MGC, there
have been a couple of proposals based on polling by the MGC (or lack
thereof) which would work quite nicely to address an outage. The idea of
defining a property on the ROOT of the MG for "MGC polling time" works very
well. Using this, the MG can determine that the MGC hasn't been
communicating as expected. The MG could use a ServiceChange with a
Disconnected method to attempt to contact the MGC. If that transaction
fails, the MG could then decide to go on to it's backup MGC.

  For the case where the network management system is responsible for
"monitoring" and correcting control association outages, the property could
be set such that the MG is not expecting polling or is set to a relatively
long time interval as an "emergency" backup.

  Either way, I think that this mechanism does address the issues and
doesn't require polling by the MG.

Michael Brown

-----Original Message-----
From: Knight, Ty [mailto:Ty.Knight@icn.siemens.com]
Sent: Wednesday, May 23, 2001 12:21 PM
To: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; 'Dan Elbert';
'Christian Groves'; 'Troy Cauble'
Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
Subject: RE: Polls of MGC


Hello Madhubabu / all,

#2 only works if there is active messaging. It seems to me that unless we
can guarantee that there is always message traffic from the MG to the MGC,
it alone is not a solution.  #1 is merely a way to guarantee traffic. 

A simple problematic scenario is as follows (for a trunking solution):

	1. MG after cold start is sending registration SvcChg to MGC. There
is no active callp.
	2. MGC accepts the association and sends the SvcChg reply to the MG.
Both are happy.
      3. Before any callp can be started, the MGC recovers.

The MG will never attempt to contact the MGC. It especially won't
re-register since it doesn't detect a problem. The MGC can't send a message
to the MG because the MGC has lost it's association data and doesn't know
which port to send it to.
	
Regards,
Ty

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Wednesday, May 23, 2001 11:55 AM
To: 'Dave Sclarsky'; 'Dan Elbert'; 'Christian Groves'; 'Troy Cauble'
Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
Subject: RE: Polls of MGC


Hi Dave/all,
MG can reinitiate new control association due to two possible scenarios
1) MG does periodic (period to be decided) polling and identifies the MGC's
failure. OR
2) MG if doesn't receive response for any of its commands from the MGC.

But now the query is which one of the two needs to be followed???  AND
WHY???

Without any new addition (and w/o processing overhead in MG/MGC) in the
protocol the case (2) works. So, one need to asses the additional gain by
adding the new polling logic.




Regards
Madhubabu


-----Original Message-----
From: Dave Sclarsky [mailto:Dave.Sclarsky@radisys.com]
Sent: Wednesday, May 23, 2001 11:28 AM
To: 'Madhu Babu Brahmanapally'; 'Dan Elbert'; Dave Sclarsky; 'Christian
Groves'; 'Troy Cauble'
Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
Subject: RE: Polls of MGC


Madhubabu,
This is exactly the issue.  Since it is the MG that initiates the control
association, the new MGC cannot tell the MG anything.
DaveS.

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Wednesday, May 23, 2001 11:22 AM
> To: 'Dan Elbert'; 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
> Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> Subject: RE: Polls of MGC
>
>
> Hi Dan/all,
>
> A related query...Can a new MGC indicate to MG that it is now
> taking over
> instead of the old MGC( I don't see any  servicechange method
> described in
> the protocol). Doesn't this introduce any security threat???.
>
> Regards
>
> Madhubabu
>
> -----Original Message-----
> From: Dan Elbert [mailto:DElbert@radvision.com]
> Sent: Wednesday, May 23, 2001 10:45 AM
> To: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; 'Christian Groves';
> 'Troy Cauble'
> Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> Subject: RE: Polls of MGC
>
>
> Hi
> I think the scenario can be as following:
> 1. The MGC fails without being able to send a "Handoff"
> 2. Later on the MGC restarts or a backup MGC comes up
> In this case the MGC can never contact the MG because it
> doesn't know where
> the MG is listening.
> So the problem stands if the MGC needs to contact the MG before the MG
> becomes aware that the connection with the MGC has been lost.
>
> Dan
>
> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Wednesday, May 23, 2001 10:37 AM
> To: 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
> Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> Subject: RE: Polls of MGC
>
> HI Dave,
> If the MG is connected to the "broken" MGC how can it receive
> commands from
> two MGC's. The MG should reinitiate the registration for
> accepting messages
> from the new MGC.
>
> Regards
> Madhubabu
>
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dave Sclarsky
> Sent: Wednesday, May 23, 2001 10:23 AM
> To: 'Christian Groves'; Troy Cauble
> Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
> megaco@fore.com
> Subject: RE: Polls of MGC
>
>
> Christian,
> What happens when the MGC wants to ring a phone on an MG that
> is a ResGW,
> but that MG still thinks tbat it is connected to a 'broken' MGC?
> DaveS.
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Wednesday, May 23, 2001 9:48 AM
> > To: Troy Cauble
> > Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
> > megaco@fore.com
> > Subject: Re: Polls of MGC
> >
> >
> > G'Day Troy et all,
> >
> > Sorry for the late support of No Polling. I still have not seen a
> > definitive reason that the MG needs to poll the MGC. We
> have defined a
> > master slave protocol with the MGC as the master. The MGC
> should be in
> > control of error situations.
> >
> > I believe that it's enough that the MG can detect that the
> > MGC has gone
> > down when it try to signal using any appropriate H.248 Commands ie.
> > Add, Move, sub replies, Notify request, Service Change etc. Lack of
> > timely response will indicate failure. The MG can then
> > re-register based
> > on this.
> >
> > If you look at the common MG use cases:
> > 1. The MG is a trunking gateway. In this scenario enough
> > traffic will be
> > generated to maintain a reasonable flow of signalling to
> minimise the
> > time to detect errors. For a proper Telco solution you should
> > also have
> > enough management systems/redundency to know what MGC to
> hand over to.
> >
> > 2. The MG is a residential gateway. Signalling traffic is not
> > that great
> > but interaction is only needed with the MGC when the end-user does
> > something. Therefore the MG will find out about the failure at this
> > time. Why generate unessary signalling across limited BW
> > links? There's
> > the avalanche problems mentioned earlier but more
> importantly someone
> > will have to pay for bandwidth this signalling takes which basically
> > serves no purpose.
> > Again in this scenario the MGC will hopefully be owned by
> someone who
> > wants to offer a decent service and has the necessary management
> > systems/reduncy. I do not envisage MG registration will
> take very long
> > on a small residential gateway. Its a ServiceChange request/response
> > round trip.
> >
> > What ever the proposed package, service change
> reason/method, protocol
> > update polling is unecessary.
> >
> > Cheers, Christian
> >
> > Troy Cauble wrote:
> > >
> > > Dave Sclarsky wrote:
> > > >
> > > > Troy,
> > > >
> > > > It doesn't matter what the new (or restarted) MGC knows
> > or doesn't know.
> > > > Megaco defines that the control association between MG
> > and MGC is ALWAYS
> > > > initiated by the MG.
> > >
> > > Then this definition is the problem and should be revisited.
> > >
> > > Polling is bad.
> > >
> > > -troy
> > >
> > > > Given that definition, Johnny's Dad's MG won't be
> > > > reachable by a new (or a restarted) MGC until the his MG
> > notices the
> > > > failure.  We must define a way for it to know ASAP!
> >
>

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






RE: Polls of MGC




Hello all,




   Given all the traffic on this thread and =
that I was content that my opinion was being expressed by others, I =
didn't feel compelled to post. But since this topic seems to be going =
around again...



   I am also in the camp that polling BY =
the MG is unnecessary. Until Christian's post, I think the biggest =
consideration that has not been taken into account is that any reliable =
telephony system/network requires that there is a robust network =
management system. IMHO, the scenarios proposed that SEEM to point to =
using a polling mechanism (MGC has gone down and calls to the MG will =
simply fail) will not happen. If an MGC crashes before being able to a =
initiate graceful recovery/transition, it will not go unnoticed from =
the network management perspective. This will (as suggested earlier) be =
considered to be a "reportable" outage and I don't believe =
that any operator or (potentially) regulatory agency is going to be =
content to say "it's OK... service will be restored =
eventually".



   On the other hand in order to support =
the scenario in Megaco where the MG autonomously detects an MGC outage =
and "rehomes" on a secondary MGC, there have been a couple of =
proposals based on polling by the MGC (or lack thereof) which would =
work quite nicely to address an outage. The idea of defining a property =
on the ROOT of the MG for "MGC polling time" works very well. =
Using this, the MG can determine that the MGC hasn't been communicating =
as expected. The MG could use a ServiceChange with a Disconnected =
method to attempt to contact the MGC. If that transaction fails, the MG =
could then decide to go on to it's backup MGC.



  For the case where the network management =
system is responsible for "monitoring" and correcting control =
association outages, the property could be set such that the MG is not =
expecting polling or is set to a relatively long time interval as an =
"emergency" backup.



  Either way, I think that this mechanism does =
address the issues and doesn't require polling by the MG.




Michael Brown




-----Original Message-----

From: Knight, Ty [mailto:Ty.Knight@icn.siemens.c=
om]

Sent: Wednesday, May 23, 2001 12:21 PM

To: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; =
'Dan Elbert';

'Christian Groves'; 'Troy Cauble'

Cc: 'Rosen, Brian'; knayar@hss.hns.com; =
megaco@fore.com

Subject: RE: Polls of MGC






Hello Madhubabu / all,




#2 only works if there is active messaging. It seems =
to me that unless we

can guarantee that there is always message traffic =
from the MG to the MGC,

it alone is not a solution.  #1 is merely a way =
to guarantee traffic. 




A simple problematic scenario is as follows (for a =
trunking solution):




        1. MG =
after cold start is sending registration SvcChg to MGC. There

is no active callp.

        2. MGC =
accepts the association and sends the SvcChg reply to the MG.

Both are happy.

      3. Before any callp =
can be started, the MGC recovers.




The MG will never attempt to contact the MGC. It =
especially won't

re-register since it doesn't detect a problem. The =
MGC can't send a message

to the MG because the MGC has lost it's association =
data and doesn't know

which port to send it to.

       =20

Regards,

Ty




-----Original Message-----

From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]<=
/FONT>

Sent: Wednesday, May 23, 2001 11:55 AM

To: 'Dave Sclarsky'; 'Dan Elbert'; 'Christian =
Groves'; 'Troy Cauble'

Cc: 'Rosen, Brian'; knayar@hss.hns.com; =
megaco@fore.com

Subject: RE: Polls of MGC






Hi Dave/all,

MG can reinitiate new control association due to two =
possible scenarios

1) MG does periodic (period to be decided) polling =
and identifies the MGC's

failure. OR

2) MG if doesn't receive response for any of its =
commands from the MGC.




But now the query is which one of the two needs to be =
followed???  AND

WHY???




Without any new addition (and w/o processing overhead =
in MG/MGC) in the

protocol the case (2) works. So, one need to asses =
the additional gain by

adding the new polling logic.










Regards

Madhubabu






-----Original Message-----

From: Dave Sclarsky [mailto:Dave.Sclarsky@radisys.c=
om]

Sent: Wednesday, May 23, 2001 11:28 AM

To: 'Madhu Babu Brahmanapally'; 'Dan Elbert'; Dave =
Sclarsky; 'Christian

Groves'; 'Troy Cauble'

Cc: 'Rosen, Brian'; knayar@hss.hns.com; =
megaco@fore.com

Subject: RE: Polls of MGC






Madhubabu,

This is exactly the issue.  Since it is the MG =
that initiates the control

association, the new MGC cannot tell the MG =
anything.

DaveS.




> -----Original Message-----

> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]<=
/FONT>

> Sent: Wednesday, May 23, 2001 11:22 AM

> To: 'Dan Elbert'; 'Dave Sclarsky'; 'Christian =
Groves'; 'Troy Cauble'

> Cc: 'Rosen, Brian'; knayar@hss.hns.com; =
megaco@fore.com

> Subject: RE: Polls of MGC

>

>

> Hi Dan/all,

>

> A related query...Can a new MGC indicate to MG =
that it is now

> taking over

> instead of the old MGC( I don't see any  =
servicechange method

> described in

> the protocol). Doesn't this introduce any =
security threat???.

>

> Regards

>

> Madhubabu

>

> -----Original Message-----

> From: Dan Elbert [mailto:DElbert@radvision.com]

> Sent: Wednesday, May 23, 2001 10:45 AM

> To: 'Madhu Babu Brahmanapally'; 'Dave =
Sclarsky'; 'Christian Groves';

> 'Troy Cauble'

> Cc: 'Rosen, Brian'; knayar@hss.hns.com; =
megaco@fore.com

> Subject: RE: Polls of MGC

>

>

> Hi

> I think the scenario can be as =
following:

> 1. The MGC fails without being able to send a =
"Handoff"

> 2. Later on the MGC restarts or a backup MGC =
comes up

> In this case the MGC can never contact the MG =
because it

> doesn't know where

> the MG is listening.

> So the problem stands if the MGC needs to =
contact the MG before the MG

> becomes aware that the connection with the MGC =
has been lost.

>

> Dan

>

> -----Original Message-----

> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]<=
/FONT>

> Sent: Wednesday, May 23, 2001 10:37 AM

> To: 'Dave Sclarsky'; 'Christian Groves'; 'Troy =
Cauble'

> Cc: 'Rosen, Brian'; knayar@hss.hns.com; =
megaco@fore.com

> Subject: RE: Polls of MGC

>

> HI Dave,

> If the MG is connected to the =
"broken" MGC how can it receive

> commands from

> two MGC's. The MG should reinitiate the =
registration for

> accepting messages

> from the new MGC.

>

> Regards

> Madhubabu

>

> -----Original Message-----

> From: owner-megaco@pit.comms.marconi.com

> [mailto:owner-megaco@p=
it.comms.marconi.com]On Behalf Of Dave Sclarsky

> Sent: Wednesday, May 23, 2001 10:23 AM

> To: 'Christian Groves'; Troy Cauble

> Cc: Dave Sclarsky; 'Rosen, Brian'; =
'knayar@hss.hns.com';

> megaco@fore.com

> Subject: RE: Polls of MGC

>

>

> Christian,

> What happens when the MGC wants to ring a phone =
on an MG that

> is a ResGW,

> but that MG still thinks tbat it is connected =
to a 'broken' MGC?

> DaveS.

>

> > -----Original Message-----

> > From: Christian Groves [mailto:Christian.Groves@er=
icsson.com]

> > Sent: Wednesday, May 23, 2001 9:48 =
AM

> > To: Troy Cauble

> > Cc: Dave Sclarsky; 'Rosen, Brian'; =
'knayar@hss.hns.com';

> > megaco@fore.com

> > Subject: Re: Polls of MGC

> >

> >

> > G'Day Troy et all,

> >

> > Sorry for the late support of No Polling. =
I still have not seen a

> > definitive reason that the MG needs to =
poll the MGC. We

> have defined a

> > master slave protocol with the MGC as the =
master. The MGC

> should be in

> > control of error situations.

> >

> > I believe that it's enough that the MG can =
detect that the

> > MGC has gone

> > down when it try to signal using any =
appropriate H.248 Commands ie.

> > Add, Move, sub replies, Notify request, =
Service Change etc. Lack of

> > timely response will indicate failure. The =
MG can then

> > re-register based

> > on this.

> >

> > If you look at the common MG use =
cases:

> > 1. The MG is a trunking gateway. In this =
scenario enough

> > traffic will be

> > generated to maintain a reasonable flow of =
signalling to

> minimise the

> > time to detect errors. For a proper Telco =
solution you should

> > also have

> > enough management systems/redundency to =
know what MGC to

> hand over to.

> >

> > 2. The MG is a residential gateway. =
Signalling traffic is not

> > that great

> > but interaction is only needed with the =
MGC when the end-user does

> > something. Therefore the MG will find out =
about the failure at this

> > time. Why generate unessary signalling =
across limited BW

> > links? There's

> > the avalanche problems mentioned earlier =
but more

> importantly someone

> > will have to pay for bandwidth this =
signalling takes which basically

> > serves no purpose.

> > Again in this scenario the MGC will =
hopefully be owned by

> someone who

> > wants to offer a decent service and has =
the necessary management

> > systems/reduncy. I do not envisage MG =
registration will

> take very long

> > on a small residential gateway. Its a =
ServiceChange request/response

> > round trip.

> >

> > What ever the proposed package, service =
change

> reason/method, protocol

> > update polling is unecessary.

> >

> > Cheers, Christian

> >

> > Troy Cauble wrote:

> > >

> > > Dave Sclarsky wrote:

> > > >

> > > > Troy,

> > > >

> > > > It doesn't matter what the new =
(or restarted) MGC knows

> > or doesn't know.

> > > > Megaco defines that the control =
association between MG

> > and MGC is ALWAYS

> > > > initiated by the MG.

> > >

> > > Then this definition is the problem =
and should be revisited.

> > >

> > > Polling is bad.

> > >

> > > -troy

> > >

> > > > Given that definition, Johnny's =
Dad's MG won't be

> > > > reachable by a new (or a =
restarted) MGC until the his MG

> > notices the

> > > > failure.  We must define a =
way for it to know ASAP!

> >

>





------_=_NextPart_001_01C0E3B9.1D82F330--


From owner-megaco@fore.com  Wed May 23 15:29:32 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12781
	for ; Wed, 23 May 2001 15:29:31 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA09860;
	Wed, 23 May 2001 15:18:39 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA19756
	for megaco-list; Wed, 23 May 2001 15:16:29 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA19726;
	Wed, 23 May 2001 15:16:24 -0400 (EDT)
From: fg4@uindy.edu.gr
Received: from finrod.uindy.edu.gr (finrod.uindy.edu.gr [193.92.167.1])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA09580;
	Wed, 23 May 2001 15:16:07 -0400 (EDT)
Received: from finrod.uindy.edu.gr (slip129-37-78-202.ny.us.prserv.net [129.37.78.202]) by finrod.uindy.edu.gr (8.8.8/8.6.12) with SMTP id WAA02630; Wed, 23 May 2001 22:46:43 -0200 (Etc/GMT)
Message-Id: <200105240046.WAA02630@finrod.uindy.edu.gr>
Received: from sorley2@minster.ca by judso@sesto.ca (8.8.5/8.6.5) with SMTP id GAA08504 for ; Tue, 22 May 2001 11:53:31 -0600 (EST)
To: judso.sesto.ca@finrod.uindy.edu.gr
Date: Tue, 22 May 01 11:53:31 EST
Subject: hi
Reply-To: back_ache40@yahoo.com
Comments: Authenticated sender is 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

TO BE REMOVED click here:  http://www.websurfking.net/homewealth/remove.html


Do you have back, muscle or joint problems?  

If so we would like to offer you the opportunity to discuss them with a health care professional at no charge.  

What do you have to lose besides your pain and discomfort?

Please hit reply with the word "HELP" in the subject.  "HELP" must be in the subject. Please include the following information in the email,Without this information we cannot help you:

Full Name  
 
Address 
     
City, State Zip 

 
Nearest Major City   


Area Code & Phone  

NOTE:  THIS IS FOR RESIDENTS OF THE U.S. ONLY


 



From owner-megaco@fore.com  Wed May 23 15:41:23 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13001
	for ; Wed, 23 May 2001 15:41:22 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA11140;
	Wed, 23 May 2001 15:31:34 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA22987
	for megaco-list; Wed, 23 May 2001 15:29:18 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA22970
	for ; Wed, 23 May 2001 15:29:16 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA10824
	for ; Wed, 23 May 2001 15:29:13 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACV10603;
	Wed, 23 May 2001 15:27:40 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Michael Brown'" , 
Subject: RE: Polls of MGC
Date: Wed, 23 May 2001 15:31:19 -0400
Message-ID: <03e201c0e3be$f1da4980$c500a8c0@MBRAHMANAPALLY>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_03E3_01C0E39D.6AC8A980"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <45D2A43C1913D51180F40000F89CB874062E2D@nrtpde0a.us.nortel.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_03E3_01C0E39D.6AC8A980
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: Polls of MGC
Yes, This seems to be logical. Define some property (MGC polling time) on
ROOT and if MGC didn't send any message/response for this duration then MG
will initiate SC with "disconnected" method. Else if MG receives
commands/responses from MGC this timer needs to be restarted at the MG with
the same defined duration. Thus avoiding any polling from the MG.

Regards
Madhubabu
  -----Original Message-----
  From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Michael Brown
  Sent: Wednesday, May 23, 2001 2:50 PM
  To: megaco@fore.com
  Subject: RE: Polls of MGC


  Hello all,

     Given all the traffic on this thread and that I was content that my
opinion was being expressed by others, I didn't feel compelled to post. But
since this topic seems to be going around again...

     I am also in the camp that polling BY the MG is unnecessary. Until
Christian's post, I think the biggest consideration that has not been taken
into account is that any reliable telephony system/network requires that
there is a robust network management system. IMHO, the scenarios proposed
that SEEM to point to using a polling mechanism (MGC has gone down and calls
to the MG will simply fail) will not happen. If an MGC crashes before being
able to a initiate graceful recovery/transition, it will not go unnoticed
from the network management perspective. This will (as suggested earlier) be
considered to be a "reportable" outage and I don't believe that any operator
or (potentially) regulatory agency is going to be content to say "it's OK...
service will be restored eventually".

     On the other hand in order to support the scenario in Megaco where the
MG autonomously detects an MGC outage and "rehomes" on a secondary MGC,
there have been a couple of proposals based on polling by the MGC (or lack
thereof) which would work quite nicely to address an outage. The idea of
defining a property on the ROOT of the MG for "MGC polling time" works very
well. Using this, the MG can determine that the MGC hasn't been
communicating as expected. The MG could use a ServiceChange with a
Disconnected method to attempt to contact the MGC. If that transaction
fails, the MG could then decide to go on to it's backup MGC.

    For the case where the network management system is responsible for
"monitoring" and correcting control association outages, the property could
be set such that the MG is not expecting polling or is set to a relatively
long time interval as an "emergency" backup.

    Either way, I think that this mechanism does address the issues and
doesn't require polling by the MG.

  Michael Brown

  -----Original Message-----
  From: Knight, Ty [mailto:Ty.Knight@icn.siemens.com]
  Sent: Wednesday, May 23, 2001 12:21 PM
  To: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; 'Dan Elbert';
  'Christian Groves'; 'Troy Cauble'
  Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
  Subject: RE: Polls of MGC



  Hello Madhubabu / all,

  #2 only works if there is active messaging. It seems to me that unless we
  can guarantee that there is always message traffic from the MG to the MGC,
  it alone is not a solution.  #1 is merely a way to guarantee traffic.

  A simple problematic scenario is as follows (for a trunking solution):

          1. MG after cold start is sending registration SvcChg to MGC.
There
  is no active callp.
          2. MGC accepts the association and sends the SvcChg reply to the
MG.
  Both are happy.
        3. Before any callp can be started, the MGC recovers.

  The MG will never attempt to contact the MGC. It especially won't
  re-register since it doesn't detect a problem. The MGC can't send a
message
  to the MG because the MGC has lost it's association data and doesn't know
  which port to send it to.

  Regards,
  Ty

  -----Original Message-----
  From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
  Sent: Wednesday, May 23, 2001 11:55 AM
  To: 'Dave Sclarsky'; 'Dan Elbert'; 'Christian Groves'; 'Troy Cauble'
  Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
  Subject: RE: Polls of MGC



  Hi Dave/all,
  MG can reinitiate new control association due to two possible scenarios
  1) MG does periodic (period to be decided) polling and identifies the
MGC's
  failure. OR
  2) MG if doesn't receive response for any of its commands from the MGC.

  But now the query is which one of the two needs to be followed???  AND
  WHY???

  Without any new addition (and w/o processing overhead in MG/MGC) in the
  protocol the case (2) works. So, one need to asses the additional gain by
  adding the new polling logic.





  Regards
  Madhubabu



  -----Original Message-----
  From: Dave Sclarsky [mailto:Dave.Sclarsky@radisys.com]
  Sent: Wednesday, May 23, 2001 11:28 AM
  To: 'Madhu Babu Brahmanapally'; 'Dan Elbert'; Dave Sclarsky; 'Christian
  Groves'; 'Troy Cauble'
  Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
  Subject: RE: Polls of MGC



  Madhubabu,
  This is exactly the issue.  Since it is the MG that initiates the control
  association, the new MGC cannot tell the MG anything.
  DaveS.

  > -----Original Message-----
  > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
  > Sent: Wednesday, May 23, 2001 11:22 AM
  > To: 'Dan Elbert'; 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
  > Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
  > Subject: RE: Polls of MGC
  >
  >
  > Hi Dan/all,
  >
  > A related query...Can a new MGC indicate to MG that it is now
  > taking over
  > instead of the old MGC( I don't see any  servicechange method
  > described in
  > the protocol). Doesn't this introduce any security threat???.
  >
  > Regards
  >
  > Madhubabu
  >
  > -----Original Message-----
  > From: Dan Elbert [mailto:DElbert@radvision.com]
  > Sent: Wednesday, May 23, 2001 10:45 AM
  > To: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; 'Christian Groves';
  > 'Troy Cauble'
  > Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
  > Subject: RE: Polls of MGC
  >
  >
  > Hi
  > I think the scenario can be as following:
  > 1. The MGC fails without being able to send a "Handoff"
  > 2. Later on the MGC restarts or a backup MGC comes up
  > In this case the MGC can never contact the MG because it
  > doesn't know where
  > the MG is listening.
  > So the problem stands if the MGC needs to contact the MG before the MG
  > becomes aware that the connection with the MGC has been lost.
  >
  > Dan
  >
  > -----Original Message-----
  > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
  > Sent: Wednesday, May 23, 2001 10:37 AM
  > To: 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
  > Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
  > Subject: RE: Polls of MGC
  >
  > HI Dave,
  > If the MG is connected to the "broken" MGC how can it receive
  > commands from
  > two MGC's. The MG should reinitiate the registration for
  > accepting messages
  > from the new MGC.
  >
  > Regards
  > Madhubabu
  >
  > -----Original Message-----
  > From: owner-megaco@pit.comms.marconi.com
  > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dave Sclarsky
  > Sent: Wednesday, May 23, 2001 10:23 AM
  > To: 'Christian Groves'; Troy Cauble
  > Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
  > megaco@fore.com
  > Subject: RE: Polls of MGC
  >
  >
  > Christian,
  > What happens when the MGC wants to ring a phone on an MG that
  > is a ResGW,
  > but that MG still thinks tbat it is connected to a 'broken' MGC?
  > DaveS.
  >
  > > -----Original Message-----
  > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
  > > Sent: Wednesday, May 23, 2001 9:48 AM
  > > To: Troy Cauble
  > > Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
  > > megaco@fore.com
  > > Subject: Re: Polls of MGC
  > >
  > >
  > > G'Day Troy et all,
  > >
  > > Sorry for the late support of No Polling. I still have not seen a
  > > definitive reason that the MG needs to poll the MGC. We
  > have defined a
  > > master slave protocol with the MGC as the master. The MGC
  > should be in
  > > control of error situations.
  > >
  > > I believe that it's enough that the MG can detect that the
  > > MGC has gone
  > > down when it try to signal using any appropriate H.248 Commands ie.
  > > Add, Move, sub replies, Notify request, Service Change etc. Lack of
  > > timely response will indicate failure. The MG can then
  > > re-register based
  > > on this.
  > >
  > > If you look at the common MG use cases:
  > > 1. The MG is a trunking gateway. In this scenario enough
  > > traffic will be
  > > generated to maintain a reasonable flow of signalling to
  > minimise the
  > > time to detect errors. For a proper Telco solution you should
  > > also have
  > > enough management systems/redundency to know what MGC to
  > hand over to.
  > >
  > > 2. The MG is a residential gateway. Signalling traffic is not
  > > that great
  > > but interaction is only needed with the MGC when the end-user does
  > > something. Therefore the MG will find out about the failure at this
  > > time. Why generate unessary signalling across limited BW
  > > links? There's
  > > the avalanche problems mentioned earlier but more
  > importantly someone
  > > will have to pay for bandwidth this signalling takes which basically
  > > serves no purpose.
  > > Again in this scenario the MGC will hopefully be owned by
  > someone who
  > > wants to offer a decent service and has the necessary management
  > > systems/reduncy. I do not envisage MG registration will
  > take very long
  > > on a small residential gateway. Its a ServiceChange request/response
  > > round trip.
  > >
  > > What ever the proposed package, service change
  > reason/method, protocol
  > > update polling is unecessary.
  > >
  > > Cheers, Christian
  > >
  > > Troy Cauble wrote:
  > > >
  > > > Dave Sclarsky wrote:
  > > > >
  > > > > Troy,
  > > > >
  > > > > It doesn't matter what the new (or restarted) MGC knows
  > > or doesn't know.
  > > > > Megaco defines that the control association between MG
  > > and MGC is ALWAYS
  > > > > initiated by the MG.
  > > >
  > > > Then this definition is the problem and should be revisited.
  > > >
  > > > Polling is bad.
  > > >
  > > > -troy
  > > >
  > > > > Given that definition, Johnny's Dad's MG won't be
  > > > > reachable by a new (or a restarted) MGC until the his MG
  > > notices the
  > > > > failure.  We must define a way for it to know ASAP!
  > >
  >


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




RE: Polls of MGC




 


Yes,=20
This seems to be logical. Define some property (MGC polling time) =
on ROOT=20
and if MGC didn't send any message/response for this duration =
then MG=20
will initiate SC with "disconnected" method. Else if MG receives=20
commands/responses from MGC this timer needs to be restarted at the MG =
with the=20
same defined duration. Thus avoiding any polling from the MG.=20



 


Regards


Madhubabu



  
-----Original Message-----
From:=20
  owner-megaco@pit.comms.marconi.com=20
  [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Michael =

  Brown
Sent: Wednesday, May 23, 2001 2:50 PM
To:=20
  megaco@fore.com
Subject: RE: Polls of =
MGC


  
Hello all, 

  
   Given all the traffic on this thread =
and that I=20
  was content that my opinion was being expressed by others, I didn't =
feel=20
  compelled to post. But since this topic seems to be going around=20
  again...

  
   I am also in the camp that polling BY =
the MG is=20
  unnecessary. Until Christian's post, I think the biggest consideration =
that=20
  has not been taken into account is that any reliable telephony =
system/network=20
  requires that there is a robust network management system. IMHO, the =
scenarios=20
  proposed that SEEM to point to using a polling mechanism (MGC has gone =
down=20
  and calls to the MG will simply fail) will not happen. If an MGC =
crashes=20
  before being able to a initiate graceful recovery/transition, it will =
not go=20
  unnoticed from the network management perspective. This will (as =
suggested=20
  earlier) be considered to be a "reportable" outage and I don't believe =
that=20
  any operator or (potentially) regulatory agency is going to be content =
to say=20
  "it's OK... service will be restored eventually".

  
   On the other hand in order to support =
the=20
  scenario in Megaco where the MG autonomously detects an MGC outage and =

  "rehomes" on a secondary MGC, there have been a couple of proposals =
based on=20
  polling by the MGC (or lack thereof) which would work quite nicely to =
address=20
  an outage. The idea of defining a property on the ROOT of the MG for =
"MGC=20
  polling time" works very well. Using this, the MG can determine that =
the MGC=20
  hasn't been communicating as expected. The MG could use a =
ServiceChange with a=20
  Disconnected method to attempt to contact the MGC. If that transaction =
fails,=20
  the MG could then decide to go on to it's backup MGC.

  
  For the case where the network management =
system is=20
  responsible for "monitoring" and correcting control association =
outages, the=20
  property could be set such that the MG is not expecting polling or is =
set to a=20
  relatively long time interval as an "emergency" backup.

  
  Either way, I think that this mechanism does =
address=20
  the issues and doesn't require polling by the MG. 

  
Michael Brown 

  
-----Original Message----- 
From:=20
  Knight, Ty [mailto:Ty.Knight@icn.siemens.co=
m]=20
  
Sent: Wednesday, May 23, 2001 12:21 PM =

To: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; 'Dan =
Elbert';=20
  
'Christian Groves'; 'Troy Cauble' 
Cc:=20
  'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com 
Subject: RE: Polls of MGC 


  
Hello Madhubabu / all, 

  
#2 only works if there is active messaging. It seems =
to me=20
  that unless we 
can guarantee that there is =
always=20
  message traffic from the MG to the MGC, 
it =
alone is=20
  not a solution.  #1 is merely a way to guarantee traffic. =


  
A simple problematic scenario is as follows (for a =
trunking=20
  solution): 

  
        1. MG =
after cold=20
  start is sending registration SvcChg to MGC. There 
is=20
  no active callp. 
        =
2. MGC accepts the association and sends the SvcChg reply to =
the=20
  MG. 
Both are happy. 
      3. Before any callp can be =
started, the=20
  MGC recovers. 

  
The MG will never attempt to contact the MGC. It =
especially=20
  won't 
re-register since it doesn't detect a =
problem.=20
  The MGC can't send a message 
to the MG =
because the MGC=20
  has lost it's association data and doesn't know 
which=20
  port to send it to. =

       =20
  
Regards, 
Ty 

  
-----Original Message----- 
From: Madhu=20
  Babu Brahmanapally [mailto:madhubabu@kenetec.com]=20
  
Sent: Wednesday, May 23, 2001 11:55 AM =

To: 'Dave Sclarsky'; 'Dan Elbert'; 'Christian Groves'; 'Troy=20
  Cauble' 
Cc: 'Rosen, Brian'; =
knayar@hss.hns.com;=20
  megaco@fore.com 
Subject: RE: Polls of =
MGC=20
  


  
Hi Dave/all, 
MG can =
reinitiate new=20
  control association due to two possible scenarios 
1)=20
  MG does periodic (period to be decided) polling and identifies the=20
  MGC's 
failure. OR 
2) MG if=20
  doesn't receive response for any of its commands from the MGC. =


  
But now the query is which one of the two needs to =
be=20
  followed???  AND 
WHY??? 

  
Without any new addition (and w/o processing =
overhead in=20
  MG/MGC) in the 
protocol the case (2) works. =
So, one=20
  need to asses the additional gain by 
adding =
the new=20
  polling logic. 




  
Regards 
Madhubabu =



  
-----Original Message----- 
From: Dave=20
  Sclarsky [mailto:Dave.Sclarsky@radisys.co=
m]=20
  
Sent: Wednesday, May 23, 2001 11:28 AM =

To: 'Madhu Babu Brahmanapally'; 'Dan Elbert'; Dave Sclarsky;=20
  'Christian 
Groves'; 'Troy Cauble' =

Cc: 'Rosen, Brian'; knayar@hss.hns.com; =
megaco@fore.com=20
  
Subject: RE: Polls of MGC 


  
Madhubabu, 
This is exactly =
the=20
  issue.  Since it is the MG that initiates the control =

association, the new MGC cannot tell the MG anything. =

DaveS. 

  
> -----Original Message----- 
>=20
  From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]=20
  
> Sent: Wednesday, May 23, 2001 11:22 AM =

> To: 'Dan Elbert'; 'Dave Sclarsky'; 'Christian Groves'; =
'Troy=20
  Cauble' 
> Cc: 'Rosen, Brian'; =
knayar@hss.hns.com;=20
  megaco@fore.com 
> Subject: RE: Polls of =
MGC=20
  
> 
> =

> Hi Dan/all, 
> =

> A related query...Can a new MGC indicate to MG that it =
is=20
  now 
> taking over 
>=20
  instead of the old MGC( I don't see any  servicechange =
method=20
  
> described in 
> =
the protocol).=20
  Doesn't this introduce any security threat???. 
> 
> Regards 
> 
> Madhubabu =

> 
> -----Original =
Message-----=20
  
> From: Dan Elbert [mailto:DElbert@radvision.com]=20
  
> Sent: Wednesday, May 23, 2001 10:45 AM =

> To: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; =
'Christian=20
  Groves'; 
> 'Troy Cauble' 
> Cc: 'Rosen, Brian'; knayar@hss.hns.com; =
megaco@fore.com=20
  
> Subject: RE: Polls of MGC 
> 
> 
>=20
  Hi 
> I think the scenario can be as=20
  following: 
> 1. The MGC fails without =
being able to=20
  send a "Handoff" 
> 2. Later on the MGC =
restarts or=20
  a backup MGC comes up 
> In this case the =
MGC can=20
  never contact the MG because it 
> doesn't =
know=20
  where 
> the MG is listening. =

> So the problem stands if the MGC needs to contact the MG =
before=20
  the MG 
> becomes aware that the =
connection with the=20
  MGC has been lost. 
> 
>=20
  Dan 
> 
> =
-----Original=20
  Message----- 
> From: Madhu Babu =
Brahmanapally [mailto:madhubabu@kenetec.com]=20
  
> Sent: Wednesday, May 23, 2001 10:37 AM =

> To: 'Dave Sclarsky'; 'Christian Groves'; 'Troy =
Cauble'=20
  
> Cc: 'Rosen, Brian'; knayar@hss.hns.com;=20
  megaco@fore.com 
> Subject: RE: Polls of =
MGC=20
  
> 
> HI Dave, =

> If the MG is connected to the "broken" MGC how can it=20
  receive 
> commands from 
> two MGC's. The MG should reinitiate the registration =
for=20
  
> accepting messages 
> from the=20
  new MGC. 
> 
> =

  Regards 
> Madhubabu 
> 
> -----Original =
Message-----=20
  
> From: =
owner-megaco@pit.comms.marconi.com=20
  
> [mailto:owner-megaco@pi=
t.comms.marconi.com]On=20
  Behalf Of Dave Sclarsky 
> Sent: =
Wednesday, May 23,=20
  2001 10:23 AM 
> To: 'Christian Groves'; =
Troy=20
  Cauble 
> Cc: Dave Sclarsky; 'Rosen, =
Brian';=20
  'knayar@hss.hns.com'; 
> =
megaco@fore.com=20
  
> Subject: RE: Polls of MGC 
> 
> 
>=20
  Christian, 
> What happens when the MGC =
wants to=20
  ring a phone on an MG that 
> is a =
ResGW,=20
  
> but that MG still thinks tbat it is connected =
to a=20
  'broken' MGC? 
> DaveS. 
> 
> > -----Original=20
  Message----- 
> > From: Christian =
Groves [mailto:Christian.Groves@eri=
csson.com]=20
  
> > Sent: Wednesday, May 23, 2001 9:48 =
AM=20
  
> > To: Troy Cauble 
> >=20
  Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com'; =

> > megaco@fore.com 
> > =
Subject:=20
  Re: Polls of MGC 
> > 
> > 
> > G'Day Troy et =
all,=20
  
> > 
> > Sorry =
for the=20
  late support of No Polling. I still have not seen a 
> > definitive reason that the MG needs to poll the =
MGC.=20
  We 
> have defined a 
>=20
  > master slave protocol with the MGC as the master. The MGC=20
  
> should be in 
> =
> control=20
  of error situations. 
> > =

> > I believe that it's enough that the MG can detect =
that=20
  the 
> > MGC has gone 
> > down when it try to signal using any appropriate =
H.248=20
  Commands ie. 
> > Add, Move, sub =
replies, Notify=20
  request, Service Change etc. Lack of 
> =
> timely=20
  response will indicate failure. The MG can then 
>=20
  > re-register based 
> > on =
this.=20
  
> > 
> > If =
you look at=20
  the common MG use cases: 
> > 1. The MG =
is a=20
  trunking gateway. In this scenario enough 
> >=20
  traffic will be 
> > generated to =
maintain a=20
  reasonable flow of signalling to 
> =
minimise=20
  the 
> > time to detect errors. For a =
proper=20
  Telco solution you should 
> > also =
have=20
  
> > enough management systems/redundency to =
know what=20
  MGC to 
> hand over to. 
>=20
  > 
> > 2. The MG is a residential =
gateway.=20
  Signalling traffic is not 
> > that =
great=20
  
> > but interaction is only needed with the =
MGC when=20
  the end-user does 
> > something. =
Therefore the=20
  MG will find out about the failure at this 
> >=20
  time. Why generate unessary signalling across limited BW =

> > links? There's 
> > =
the=20
  avalanche problems mentioned earlier but more 
>=20
  importantly someone 
> > will have to =
pay for=20
  bandwidth this signalling takes which basically 
>=20
  > serves no purpose. 
> > Again in =
this=20
  scenario the MGC will hopefully be owned by 
>=20
  someone who 
> > wants to offer a =
decent service=20
  and has the necessary management 
> >=20
  systems/reduncy. I do not envisage MG registration will =

> take very long 
> > on a =
small=20
  residential gateway. Its a ServiceChange request/response =

> > round trip. 
> =
>=20
  
> > What ever the proposed package, service=20
  change 
> reason/method, protocol =

> > update polling is unecessary. 
>=20
  > 
> > Cheers, Christian =

> > 
> > Troy Cauble =
wrote:=20
  
> > > 
> > =
> Dave=20
  Sclarsky wrote: 
> > > > =

> > > > Troy, 
> > =
>=20
  > 
> > > > It doesn't matter =
what the=20
  new (or restarted) MGC knows 
> > or =
doesn't=20
  know. 
> > > > Megaco defines =
that the=20
  control association between MG 
> > and =
MGC is=20
  ALWAYS 
> > > > initiated by the =
MG.=20
  
> > > 
> > =
> Then=20
  this definition is the problem and should be revisited. =

> > > 
> > > =
Polling is=20
  bad. 
> > > 
> >=20
  > -troy 
> > > 
>=20
  > > > Given that definition, Johnny's Dad's MG won't =
be=20
  
> > > > reachable by a new (or a =
restarted) MGC=20
  until the his MG 
> > notices =
the=20
  
> > > > failure.  We must define a =
way for=20
  it to know ASAP! 
> > 
> 


------=_NextPart_000_03E3_01C0E39D.6AC8A980--



From owner-megaco@fore.com  Wed May 23 18:15:44 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16469
	for ; Wed, 23 May 2001 18:15:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA21352;
	Wed, 23 May 2001 18:09:51 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA25248
	for megaco-list; Wed, 23 May 2001 18:06:11 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA25239
	for ; Wed, 23 May 2001 18:06:09 -0400 (EDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA21068
	for ; Wed, 23 May 2001 18:06:05 -0400 (EDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id RAA23645
	for ; Wed, 23 May 2001 17:06:07 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4NM67C11230
	for ; Wed, 23 May 2001 17:06:07 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4NM5O107172
	for ; Wed, 23 May 2001 17:05:24 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4NM5OO00333
	for ; Wed, 23 May 2001 17:05:24 -0500 (CDT)
Message-ID: <3B0C3424.A7EF56EE@usa.alcatel.com>
Date: Wed, 23 May 2001 17:05:24 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Polls of MGC
References: <03e201c0e3be$f1da4980$c500a8c0@MBRAHMANAPALLY>
Content-Type: multipart/alternative;
 boundary="------------2F803A2479241813F0223B64"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------2F803A2479241813F0223B64
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi All

This sounds good since SC Disconnected is defined to be used if MG
thinks it has
temporary lost it connection w/MGC.
So say that originally (for UDP), MGC has specified a
ServiceChangeAddress of 55555.
So MG was sending msgs to MGC at port 55555.

Now there is some disconnection, does MG send the SC Disconnected to
55555 or
2944?
Should MGC accept SC Disconnected on 2944 if it has specified 55555?

So far is it agreed that SC Restart, Failover, HandOff are registration
SCs thus
they always go to 2944?

(By the way no matter how you word it. It is still polling.)

What about MGC wanting to detect if MG is up or not?

In response to all the questions do we need polling, there are customers
that have
been asking if UDP is used how does MG and MGC know if each other are
down.
So if the customer wants it, are we going to say NO?


Chuong


Madhu Babu Brahmanapally wrote:

> Yes, This seems to be logical. Define some property (MGC polling time)
> on ROOT and if MGC didn't send any message/response for this duration
> then MG will initiate SC with "disconnected" method. Else if MG
> receives commands/responses from MGC this timer needs to be restarted
> at the MG with the same defined duration. Thus avoiding any polling
> from the MG. RegardsMadhubabu
>
>      -----Original Message-----
>      From: owner-megaco@pit.comms.marconi.com
>      [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of
>      Michael Brown
>      Sent: Wednesday, May 23, 2001 2:50 PM
>      To: megaco@fore.com
>      Subject: RE: Polls of MGC
>      Hello all,
>
>         Given all the traffic on this thread and that I was
>      content that my opinion was being expressed by others, I
>      didn't feel compelled to post. But since this topic seems to
>      be going around again...
>
>         I am also in the camp that polling BY the MG is
>      unnecessary. Until Christian's post, I think the biggest
>      consideration that has not been taken into account is that
>      any reliable telephony system/network requires that there is
>      a robust network management system. IMHO, the scenarios
>      proposed that SEEM to point to using a polling mechanism
>      (MGC has gone down and calls to the MG will simply fail)
>      will not happen. If an MGC crashes before being able to a
>      initiate graceful recovery/transition, it will not go
>      unnoticed from the network management perspective. This will
>      (as suggested earlier) be considered to be a "reportable"
>      outage and I don't believe that any operator or
>      (potentially) regulatory agency is going to be content to
>      say "it's OK... service will be restored eventually".
>
>         On the other hand in order to support the scenario in
>      Megaco where the MG autonomously detects an MGC outage and
>      "rehomes" on a secondary MGC, there have been a couple of
>      proposals based on polling by the MGC (or lack thereof)
>      which would work quite nicely to address an outage. The idea
>      of defining a property on the ROOT of the MG for "MGC
>      polling time" works very well. Using this, the MG can
>      determine that the MGC hasn't been communicating as
>      expected. The MG could use a ServiceChange with a
>      Disconnected method to attempt to contact the MGC. If that
>      transaction fails, the MG could then decide to go on to it's
>      backup MGC.
>
>        For the case where the network management system is
>      responsible for "monitoring" and correcting control
>      association outages, the property could be set such that the
>      MG is not expecting polling or is set to a relatively long
>      time interval as an "emergency" backup.
>
>        Either way, I think that this mechanism does address the
>      issues and doesn't require polling by the MG.
>
>      Michael Brown
>
>      -----Original Message-----
>      From: Knight, Ty [mailto:Ty.Knight@icn.siemens.com]
>      Sent: Wednesday, May 23, 2001 12:21 PM
>      To: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; 'Dan
>      Elbert';
>      'Christian Groves'; 'Troy Cauble'
>      Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
>      Subject: RE: Polls of MGC
>
>      Hello Madhubabu / all,
>
>      #2 only works if there is active messaging. It seems to me
>      that unless we
>      can guarantee that there is always message traffic from the
>      MG to the MGC,
>      it alone is not a solution.  #1 is merely a way to guarantee
>      traffic.
>
>      A simple problematic scenario is as follows (for a trunking
>      solution):
>
>              1. MG after cold start is sending registration
>      SvcChg to MGC. There
>      is no active callp.
>              2. MGC accepts the association and sends the SvcChg
>      reply to the MG.
>      Both are happy.
>            3. Before any callp can be started, the MGC recovers.
>
>      The MG will never attempt to contact the MGC. It especially
>      won't
>      re-register since it doesn't detect a problem. The MGC can't
>      send a message
>      to the MG because the MGC has lost it's association data and
>      doesn't know
>      which port to send it to.
>
>      Regards,
>      Ty
>
>      -----Original Message-----
>      From: Madhu Babu Brahmanapally
>      [mailto:madhubabu@kenetec.com]
>      Sent: Wednesday, May 23, 2001 11:55 AM
>      To: 'Dave Sclarsky'; 'Dan Elbert'; 'Christian Groves'; 'Troy
>      Cauble'
>      Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
>      Subject: RE: Polls of MGC
>
>      Hi Dave/all,
>      MG can reinitiate new control association due to two
>      possible scenarios
>      1) MG does periodic (period to be decided) polling and
>      identifies the MGC's
>      failure. OR
>      2) MG if doesn't receive response for any of its commands
>      from the MGC.
>
>      But now the query is which one of the two needs to be
>      followed???  AND
>      WHY???
>
>      Without any new addition (and w/o processing overhead in
>      MG/MGC) in the
>      protocol the case (2) works. So, one need to asses the
>      additional gain by
>      adding the new polling logic.
>
>
>
>      Regards
>      Madhubabu
>
>      -----Original Message-----
>      From: Dave Sclarsky [mailto:Dave.Sclarsky@radisys.com]
>      Sent: Wednesday, May 23, 2001 11:28 AM
>      To: 'Madhu Babu Brahmanapally'; 'Dan Elbert'; Dave Sclarsky;
>      'Christian
>      Groves'; 'Troy Cauble'
>      Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
>      Subject: RE: Polls of MGC
>
>      Madhubabu,
>      This is exactly the issue.  Since it is the MG that
>      initiates the control
>      association, the new MGC cannot tell the MG anything.
>      DaveS.
>
>      > -----Original Message-----
>      > From: Madhu Babu Brahmanapally
>      [mailto:madhubabu@kenetec.com]
>      > Sent: Wednesday, May 23, 2001 11:22 AM
>      > To: 'Dan Elbert'; 'Dave Sclarsky'; 'Christian Groves';
>      'Troy Cauble'
>      > Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
>      > Subject: RE: Polls of MGC
>      >
>      >
>      > Hi Dan/all,
>      >
>      > A related query...Can a new MGC indicate to MG that it is
>      now
>      > taking over
>      > instead of the old MGC( I don't see any  servicechange
>      method
>      > described in
>      > the protocol). Doesn't this introduce any security
>      threat???.
>      >
>      > Regards
>      >
>      > Madhubabu
>      >
>      > -----Original Message-----
>      > From: Dan Elbert [mailto:DElbert@radvision.com]
>      > Sent: Wednesday, May 23, 2001 10:45 AM
>      > To: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky';
>      'Christian Groves';
>      > 'Troy Cauble'
>      > Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
>      > Subject: RE: Polls of MGC
>      >
>      >
>      > Hi
>      > I think the scenario can be as following:
>      > 1. The MGC fails without being able to send a "Handoff"
>      > 2. Later on the MGC restarts or a backup MGC comes up
>      > In this case the MGC can never contact the MG because it
>      > doesn't know where
>      > the MG is listening.
>      > So the problem stands if the MGC needs to contact the MG
>      before the MG
>      > becomes aware that the connection with the MGC has been
>      lost.
>      >
>      > Dan
>      >
>      > -----Original Message-----
>      > From: Madhu Babu Brahmanapally
>      [mailto:madhubabu@kenetec.com]
>      > Sent: Wednesday, May 23, 2001 10:37 AM
>      > To: 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
>      > Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
>      > Subject: RE: Polls of MGC
>      >
>      > HI Dave,
>      > If the MG is connected to the "broken" MGC how can it
>      receive
>      > commands from
>      > two MGC's. The MG should reinitiate the registration for
>      > accepting messages
>      > from the new MGC.
>      >
>      > Regards
>      > Madhubabu
>      >
>      > -----Original Message-----
>      > From: owner-megaco@pit.comms.marconi.com
>      > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of
>      Dave Sclarsky
>      > Sent: Wednesday, May 23, 2001 10:23 AM
>      > To: 'Christian Groves'; Troy Cauble
>      > Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
>      > megaco@fore.com
>      > Subject: RE: Polls of MGC
>      >
>      >
>      > Christian,
>      > What happens when the MGC wants to ring a phone on an MG
>      that
>      > is a ResGW,
>      > but that MG still thinks tbat it is connected to a
>      'broken' MGC?
>      > DaveS.
>      >
>      > > -----Original Message-----
>      > > From: Christian Groves
>      [mailto:Christian.Groves@ericsson.com]
>      > > Sent: Wednesday, May 23, 2001 9:48 AM
>      > > To: Troy Cauble
>      > > Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
>
>      > > megaco@fore.com
>      > > Subject: Re: Polls of MGC
>      > >
>      > >
>      > > G'Day Troy et all,
>      > >
>      > > Sorry for the late support of No Polling. I still have
>      not seen a
>      > > definitive reason that the MG needs to poll the MGC. We
>      > have defined a
>      > > master slave protocol with the MGC as the master. The
>      MGC
>      > should be in
>      > > control of error situations.
>      > >
>      > > I believe that it's enough that the MG can detect that
>      the
>      > > MGC has gone
>      > > down when it try to signal using any appropriate H.248
>      Commands ie.
>      > > Add, Move, sub replies, Notify request, Service Change
>      etc. Lack of
>      > > timely response will indicate failure. The MG can then
>      > > re-register based
>      > > on this.
>      > >
>      > > If you look at the common MG use cases:
>      > > 1. The MG is a trunking gateway. In this scenario enough
>
>      > > traffic will be
>      > > generated to maintain a reasonable flow of signalling to
>
>      > minimise the
>      > > time to detect errors. For a proper Telco solution you
>      should
>      > > also have
>      > > enough management systems/redundency to know what MGC to
>
>      > hand over to.
>      > >
>      > > 2. The MG is a residential gateway. Signalling traffic
>      is not
>      > > that great
>      > > but interaction is only needed with the MGC when the
>      end-user does
>      > > something. Therefore the MG will find out about the
>      failure at this
>      > > time. Why generate unessary signalling across limited BW
>
>      > > links? There's
>      > > the avalanche problems mentioned earlier but more
>      > importantly someone
>      > > will have to pay for bandwidth this signalling takes
>      which basically
>      > > serves no purpose.
>      > > Again in this scenario the MGC will hopefully be owned
>      by
>      > someone who
>      > > wants to offer a decent service and has the necessary
>      management
>      > > systems/reduncy. I do not envisage MG registration will
>      > take very long
>      > > on a small residential gateway. Its a ServiceChange
>      request/response
>      > > round trip.
>      > >
>      > > What ever the proposed package, service change
>      > reason/method, protocol
>      > > update polling is unecessary.
>      > >
>      > > Cheers, Christian
>      > >
>      > > Troy Cauble wrote:
>      > > >
>      > > > Dave Sclarsky wrote:
>      > > > >
>      > > > > Troy,
>      > > > >
>      > > > > It doesn't matter what the new (or restarted) MGC
>      knows
>      > > or doesn't know.
>      > > > > Megaco defines that the control association between
>      MG
>      > > and MGC is ALWAYS
>      > > > > initiated by the MG.
>      > > >
>      > > > Then this definition is the problem and should be
>      revisited.
>      > > >
>      > > > Polling is bad.
>      > > >
>      > > > -troy
>      > > >
>      > > > > Given that definition, Johnny's Dad's MG won't be
>      > > > > reachable by a new (or a restarted) MGC until the
>      his MG
>      > > notices the
>      > > > > failure.  We must define a way for it to know ASAP!
>      > >
>      >
>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------2F803A2479241813F0223B64
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

Hi All

This sounds good since SC Disconnected is defined to be used if MG thinks
it has

temporary lost it connection w/MGC.

So say that originally (for UDP), MGC has specified a ServiceChangeAddress
of 55555.

So MG was sending msgs to MGC at port 55555.

Now there is some disconnection, does MG send the SC Disconnected to
55555 or

2944?

Should MGC accept SC Disconnected on 2944 if it has specified 55555?

So far is it agreed that SC Restart, Failover, HandOff are registration
SCs thus

they always go to 2944?

(By the way no matter how you word it. It is still polling.)

What about MGC wanting to detect if MG is up or not?

In response to all the questions do we need polling, there are customers
that have

been asking if UDP is used how does MG and MGC know if each other
are down.

So if the customer wants it, are we going to say NO?

 

Chuong

 

Madhu Babu Brahmanapally wrote:

Yes,
This seems to be logical. Define some property (MGC polling time) on ROOT
and if MGC didn't send any message/response for this duration then MG will
initiate SC with "disconnected" method. Else if MG receives commands/responses
from MGC this timer needs to be restarted at the MG with the same defined
duration. Thus avoiding any polling from the MG. RegardsMadhubabu



-----Original
Message-----

From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Michael
Brown

Sent: Wednesday, May 23, 2001
2:50 PM

To: megaco@fore.com

Subject: RE: Polls of MGC

Hello all,

   Given all the traffic on this thread and
that I was content that my opinion was being expressed by others, I didn't
feel compelled to post. But since this topic seems to be going around again...

   I am also in the camp that polling BY the
MG is unnecessary. Until Christian's post, I think the biggest consideration
that has not been taken into account is that any reliable telephony system/network
requires that there is a robust network management system. IMHO, the scenarios
proposed that SEEM to point to using a polling mechanism (MGC has gone
down and calls to the MG will simply fail) will not happen. If an MGC crashes
before being able to a initiate graceful recovery/transition, it will not
go unnoticed from the network management perspective. This will (as suggested
earlier) be considered to be a "reportable" outage and I don't believe
that any operator or (potentially) regulatory agency is going to be content
to say "it's OK... service will be restored eventually".

   On the other hand in order to support the
scenario in Megaco where the MG autonomously detects an MGC outage and
"rehomes" on a secondary MGC, there have been a couple of proposals based
on polling by the MGC (or lack thereof) which would work quite nicely to
address an outage. The idea of defining a property on the ROOT of the MG
for "MGC polling time" works very well. Using this, the MG can determine
that the MGC hasn't been communicating as expected. The MG could use a
ServiceChange with a Disconnected method to attempt to contact the MGC.
If that transaction fails, the MG could then decide to go on to it's backup
MGC.

  For the case where the network management system
is responsible for "monitoring" and correcting control association outages,
the property could be set such that the MG is not expecting polling or
is set to a relatively long time interval as an "emergency" backup.

  Either way, I think that this mechanism does address
the issues and doesn't require polling by the MG.

Michael Brown

-----Original Message-----

From: Knight, Ty [mailto:Ty.Knight@icn.siemens.com]

Sent: Wednesday, May 23, 2001 12:21 PM

To: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; 'Dan
Elbert';

'Christian Groves'; 'Troy Cauble'

Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com

Subject: RE: Polls of MGC

Hello Madhubabu / all,

#2 only works if there is active messaging. It seems to
me that unless we

can guarantee that there is always message traffic from
the MG to the MGC,

it alone is not a solution.  #1 is merely a way
to guarantee traffic.

A simple problematic scenario is as follows (for a trunking
solution):

        1. MG after
cold start is sending registration SvcChg to MGC. There

is no active callp.

        2. MGC accepts
the association and sends the SvcChg reply to the MG.

Both are happy.

      3. Before any callp can
be started, the MGC recovers.

The MG will never attempt to contact the MGC. It especially
won't

re-register since it doesn't detect a problem. The MGC
can't send a message

to the MG because the MGC has lost it's association data
and doesn't know

which port to send it to.

Regards,

Ty

-----Original Message-----

From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]

Sent: Wednesday, May 23, 2001 11:55 AM

To: 'Dave Sclarsky'; 'Dan Elbert'; 'Christian Groves';
'Troy Cauble'

Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com

Subject: RE: Polls of MGC

Hi Dave/all,

MG can reinitiate new control association due to two
possible scenarios

1) MG does periodic (period to be decided) polling and
identifies the MGC's

failure. OR

2) MG if doesn't receive response for any of its commands
from the MGC.

But now the query is which one of the two needs to be
followed???  AND

WHY???

Without any new addition (and w/o processing overhead
in MG/MGC) in the

protocol the case (2) works. So, one need to asses the
additional gain by

adding the new polling logic.

 

 

Regards

Madhubabu

-----Original Message-----

From: Dave Sclarsky [mailto:Dave.Sclarsky@radisys.com]

Sent: Wednesday, May 23, 2001 11:28 AM

To: 'Madhu Babu Brahmanapally'; 'Dan Elbert'; Dave Sclarsky;
'Christian

Groves'; 'Troy Cauble'

Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com

Subject: RE: Polls of MGC

Madhubabu,

This is exactly the issue.  Since it is the MG that
initiates the control

association, the new MGC cannot tell the MG anything.

DaveS.

> -----Original Message-----

> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]

> Sent: Wednesday, May 23, 2001 11:22 AM

> To: 'Dan Elbert'; 'Dave Sclarsky'; 'Christian Groves';
'Troy Cauble'

> Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com

> Subject: RE: Polls of MGC

>

>

> Hi Dan/all,

>

> A related query...Can a new MGC indicate to MG that
it is now

> taking over

> instead of the old MGC( I don't see any  servicechange
method

> described in

> the protocol). Doesn't this introduce any security
threat???.

>

> Regards

>

> Madhubabu

>

> -----Original Message-----

> From: Dan Elbert [mailto:DElbert@radvision.com]

> Sent: Wednesday, May 23, 2001 10:45 AM

> To: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; 'Christian
Groves';

> 'Troy Cauble'

> Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com

> Subject: RE: Polls of MGC

>

>

> Hi

> I think the scenario can be as following:

> 1. The MGC fails without being able to send a "Handoff"

> 2. Later on the MGC restarts or a backup MGC comes
up

> In this case the MGC can never contact the MG because
it

> doesn't know where

> the MG is listening.

> So the problem stands if the MGC needs to contact the
MG before the MG

> becomes aware that the connection with the MGC has
been lost.

>

> Dan

>

> -----Original Message-----

> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]

> Sent: Wednesday, May 23, 2001 10:37 AM

> To: 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'

> Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com

> Subject: RE: Polls of MGC

>

> HI Dave,

> If the MG is connected to the "broken" MGC how can
it receive

> commands from

> two MGC's. The MG should reinitiate the registration
for

> accepting messages

> from the new MGC.

>

> Regards

> Madhubabu

>

> -----Original Message-----

> From: owner-megaco@pit.comms.marconi.com

> [mailto:owner-megaco@pit.comms.marconi.com]On
Behalf Of Dave Sclarsky

> Sent: Wednesday, May 23, 2001 10:23 AM

> To: 'Christian Groves'; Troy Cauble

> Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';

> megaco@fore.com

> Subject: RE: Polls of MGC

>

>

> Christian,

> What happens when the MGC wants to ring a phone on
an MG that

> is a ResGW,

> but that MG still thinks tbat it is connected to a
'broken' MGC?

> DaveS.

>

> > -----Original Message-----

> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]

> > Sent: Wednesday, May 23, 2001 9:48 AM

> > To: Troy Cauble

> > Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';

> > megaco@fore.com

> > Subject: Re: Polls of MGC

> >

> >

> > G'Day Troy et all,

> >

> > Sorry for the late support of No Polling. I still
have not seen a

> > definitive reason that the MG needs to poll the MGC.
We

> have defined a

> > master slave protocol with the MGC as the master.
The MGC

> should be in

> > control of error situations.

> >

> > I believe that it's enough that the MG can detect
that the

> > MGC has gone

> > down when it try to signal using any appropriate
H.248 Commands ie.

> > Add, Move, sub replies, Notify request, Service Change
etc. Lack of

> > timely response will indicate failure. The MG can
then

> > re-register based

> > on this.

> >

> > If you look at the common MG use cases:

> > 1. The MG is a trunking gateway. In this scenario
enough

> > traffic will be

> > generated to maintain a reasonable flow of signalling
to

> minimise the

> > time to detect errors. For a proper Telco solution
you should

> > also have

> > enough management systems/redundency to know what
MGC to

> hand over to.

> >

> > 2. The MG is a residential gateway. Signalling traffic
is not

> > that great

> > but interaction is only needed with the MGC when
the end-user does

> > something. Therefore the MG will find out about the
failure at this

> > time. Why generate unessary signalling across limited
BW

> > links? There's

> > the avalanche problems mentioned earlier but more

> importantly someone

> > will have to pay for bandwidth this signalling takes
which basically

> > serves no purpose.

> > Again in this scenario the MGC will hopefully be
owned by

> someone who

> > wants to offer a decent service and has the necessary
management

> > systems/reduncy. I do not envisage MG registration
will

> take very long

> > on a small residential gateway. Its a ServiceChange
request/response

> > round trip.

> >

> > What ever the proposed package, service change

> reason/method, protocol

> > update polling is unecessary.

> >

> > Cheers, Christian

> >

> > Troy Cauble wrote:

> > >

> > > Dave Sclarsky wrote:

> > > >

> > > > Troy,

> > > >

> > > > It doesn't matter what the new (or restarted)
MGC knows

> > or doesn't know.

> > > > Megaco defines that the control association between
MG

> > and MGC is ALWAYS

> > > > initiated by the MG.

> > >

> > > Then this definition is the problem and should
be revisited.

> > >

> > > Polling is bad.

> > >

> > > -troy

> > >

> > > > Given that definition, Johnny's Dad's MG won't
be

> > > > reachable by a new (or a restarted) MGC until
the his MG

> > notices the

> > > > failure.  We must define a way for it to
know ASAP!

> >

>





-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------2F803A2479241813F0223B64--



From owner-megaco@fore.com  Wed May 23 23:42:18 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA22782
	for ; Wed, 23 May 2001 23:42:18 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA03370;
	Wed, 23 May 2001 23:35:07 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA25516
	for megaco-list; Wed, 23 May 2001 23:32:12 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA25512
	for ; Wed, 23 May 2001 23:32:10 -0400 (EDT)
Received: from smtp6ve.mailsrvcs.net (smtp6vepub.gte.net [206.46.170.27])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA03236
	for ; Wed, 23 May 2001 23:32:07 -0400 (EDT)
Received: from lucent.com (adsl-138-89-121-177.nnj.adsl.bellatlantic.net [138.89.121.177])
	by smtp6ve.mailsrvcs.net (8.9.1/8.9.1) with ESMTP id DAA24480829;
	Thu, 24 May 2001 03:37:15 GMT
Message-ID: <3B0C8058.65043888@lucent.com>
Date: Wed, 23 May 2001 23:30:32 -0400
From: Terry L Anderson 
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com, Christian.Groves@ericsson.com
Subject: Re: Polls of MGC
Content-Type: multipart/mixed;
 boundary="------------A5BF5E920F7CC395B3728CCE"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.
--------------A5BF5E920F7CC395B3728CCE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

(resending since my original seems not to have made it to the list)

MGC/MG relationship is indeed master/slave but registrations are only
initiated
from the MG end, so MGC being aware of loss of connectivity or an
alternate MGC
being aware that the primary is down does not allow reconnection to the
alternate - only the MG can take action to register with the alternate
(as in
11.5).  So it seems to me most important that MG detect failures (as it
is the
only one that can take action).  Its the MGC that can do little when it
detects
a failure.
MGC perhaps should make the decision as to whether failures should be
detected
and frequency of polling but it seems to me that MG should do the
polling.

For failures of a TCP link or MGC failure and recovery without loss of
state,
MGC may reestablish communications with a re-registration, but I don't
understand how an alternate MGC can take over after a primary failure
without MG

detecting the failure.

I did not think that an MG normally sent Add, Move, Subtract.  I believe
that
the only MG initiated transactions commonly used are Notify and
ServiceChange.
Thus during a quiet period (edge GW with SS7/ISUP signaling, no active
calls),
there would be no active events and so no reason to send either Notify
or
ServiceChange and so GW would be unaware that:
1. MGC has gone down
2. network has lost connectivity to MGC

In either case, without polling, MG would be unaware.  Yet registering
with
alternateMGC might allow it to handle calls.

I thought that the previously discussed methods for MGC and for MG
polling were
adequate but if we want to add a new mechanism, one could allow complete
control

from MGC end by adding a "timer" event through a package.  MGC could
activate
the timer event on say root termination and this would cause a notify
after the
MGC specified period.  MGC would detect failure by lack of this notify.
MG
would detect failure when the Notify received no reply.  MGC thus
decides
whether polling should occur, what period to use and there is only
polling
traffic in one direction but both ends detect failure.  It would be
improved if
the package specified that the timer was automatically reset by any
messages, so

it would fire only when no messages had been exchanged for the specified
time
(MGC would still detect failure by absense of any message for greater
than the
timer period, MG detect by failed reply).

Christian Groves wrote:

> G'Day Troy et all,
>
> Sorry for the late support of No Polling. I still have not seen a
> definitive reason that the MG needs to poll the MGC. We have defined a

> master slave protocol with the MGC as the master. The MGC should be in

> control of error situations.
>
> I believe that it's enough that the MG can detect that the MGC has
gone
> down when it try to signal using any appropriate H.248 Commands ie.
> Add, Move, sub replies, Notify request, Service Change etc. Lack of
> timely response will indicate failure. The MG can then re-register
based
> on this.
>
> If you look at the common MG use cases:
> 1. The MG is a trunking gateway. In this scenario enough traffic will
be
> generated to maintain a reasonable flow of signalling to minimise the
> time to detect errors. For a proper Telco solution you should also
have
> enough management systems/redundency to know what MGC to hand over to.

>
> 2. The MG is a residential gateway. Signalling traffic is not that
great
> but interaction is only needed with the MGC when the end-user does
> something. Therefore the MG will find out about the failure at this
> time. Why generate unessary signalling across limited BW links?
There's
> the avalanche problems mentioned earlier but more importantly someone
> will have to pay for bandwidth this signalling takes which basically
> serves no purpose.
> Again in this scenario the MGC will hopefully be owned by someone who
> wants to offer a decent service and has the necessary management
> systems/reduncy. I do not envisage MG registration will take very long

> on a small residential gateway. Its a ServiceChange request/response
> round trip.
>
> What ever the proposed package, service change reason/method, protocol

> update polling is unecessary.
>
> Cheers, Christian
>
> Troy Cauble wrote:
> >
> > Dave Sclarsky wrote:
> > >
> > > Troy,
> > >
> > > It doesn't matter what the new (or restarted) MGC knows or doesn't
know.
> > > Megaco defines that the control association between MG and MGC is
ALWAYS
> > > initiated by the MG.
> >
> > Then this definition is the problem and should be revisited.
> >
> > Polling is bad.
> >
> > -troy
> >
> > > Given that definition, Johnny's Dad's MG won't be
> > > reachable by a new (or a restarted) MGC until the his MG notices
the
> > > failure.  We must define a way for it to know ASAP!

--
-------------------------------------------------------
Terry L Anderson, DMTS                   tla@lucent.com
Lucent Technologies /INS/ Voice over IP Access Networks
Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
Voice:908 582-7013  FAX:908 582-6729
http://its.lucent.com/~tla  (Lucent internal)
http://www.gti.net/tla
-------------------------------------------------------


--------------A5BF5E920F7CC395B3728CCE
Content-Type: text/x-vcard; charset=us-ascii;
 name="tla.vcf"
Content-Description: Card for Terry L Anderson
Content-Disposition: attachment;
 filename="tla.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Anderson;Terry L
tel;fax:908.582.6729
tel;home:908.766.4463
tel;work:908.582.7013
x-mozilla-html:TRUE
url:http://www.gti.net/tla
org:Lucent Technologies;Voice over IP Access Networks / INS
version:2.1
email;internet:tla@lucent.com
title:DMTS
adr;quoted-printable:;;Rm 2B-121=0D=0A600 Mountain Av;Murray Hill;NJ;07974;USA
fn:Terry L Anderson
end:vcard

--------------A5BF5E920F7CC395B3728CCE--



From owner-megaco@fore.com  Thu May 24 00:41:56 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23701
	for ; Thu, 24 May 2001 00:41:56 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA05391;
	Thu, 24 May 2001 00:34:54 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA00737
	for megaco-list; Thu, 24 May 2001 00:34:03 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA00731
	for ; Thu, 24 May 2001 00:34:01 -0400 (EDT)
Received: from brahma01.netbrahma.com ([164.164.70.67])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA05274
	for ; Thu, 24 May 2001 00:33:53 -0400 (EDT)
Received: from ATANU ([172.16.72.98]) by brahma01.netbrahma.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id LQ032HMK; Thu, 24 May 2001 10:03:22 +0530
Message-ID: <006b01c0e40b$bab967e0$624810ac@netbrahma.com>
Reply-To: "atanum" 
From: "atanum" 
To: 
Subject: Clarification on ABNF and ASN definition on ServiceChange Param
Date: Thu, 24 May 2001 10:10:58 +0530
Organization: netbrahma
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 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

> Dear List
>
> The serviceChangeParm as described in ABNF spec is as below
> serviceChangeParm = (serviceChangeMethod
>
/serviceChangeReason/serviceChangeDelay/serviceChangeAddress/serviceChangePr
> ofile/extension/TimeStamp/serviceChangeMgcId/serviceChangeVersion )
>  which makes all the parameters a s optional.
>
> In ASN syntax the serviceChangeParm is described as below
>
> serviceChangeParm ::= SEQUENCE
> {
> serviceChangeMethod ServiceChangeMethod,
> serviceChangeAddress ServiceChangeAddress OPTIONAL,
> serviceChangeVersion INTEGER(0..99) OPTIONAL,
> serviceChangeProfile ServiceChangeProfile OPTIONAL,
> serviceChangeReason Value
> serviceChangeDelay INTEGER(0..4294967295) OPTIONAL,
> serviceChangeMgcId MId OPTIONAL,
> timeStamp TimeNotation OPTIONAL,
> nonStandardData NonStandardData OPTIONAL,
> }
>
> Which makes the ServiceChangeMethod as compulsory and the rest optional.
> What is the reason for this decrepency between the two version(ASN and
ABNF)
>
> If anybody can clarify the reason for this decrepency it will be very
> helpful
> Thanking in advance
>
> Regards
> Atanu



From owner-megaco@fore.com  Thu May 24 00:44:09 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23722
	for ; Thu, 24 May 2001 00:44:09 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA05178;
	Thu, 24 May 2001 00:33:18 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA00635
	for megaco-list; Thu, 24 May 2001 00:32:32 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA00631
	for ; Thu, 24 May 2001 00:32:30 -0400 (EDT)
Received: from brahma01.netbrahma.com ([164.164.70.67])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA05092
	for ; Thu, 24 May 2001 00:32:21 -0400 (EDT)
Received: from ATANU ([172.16.72.98]) by brahma01.netbrahma.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id LQ032HMG; Thu, 24 May 2001 10:01:49 +0530
Message-ID: <006401c0e40b$835fa2f0$624810ac@netbrahma.com>
Reply-To: "atanum" 
From: "atanum" 
To: 
References: <3B0C8058.65043888@lucent.com>
Subject: Re: Polls of MGC
Date: Thu, 24 May 2001 10:09:24 +0530
Organization: netbrahma
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 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,
How about defining a sanity punch message on the MGC end which will be sent
towards the MG at regular intervals if there is no standard message to
communicate to MG. In that case if a timer is defined in the root of the MG,
it cannot get timed out since even if there is no standard message coming
from the MGC, the sanity punch continues to reach which will restart the
timer of the MG. If the timer in the MG times out, it knows that the MGC is
down and it goes for registration with the secondary MGC....

Regards
Atanu





From owner-megaco@fore.com  Thu May 24 02:33:26 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06381
	for ; Thu, 24 May 2001 02:33:25 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA08386;
	Thu, 24 May 2001 02:26:02 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA07486
	for megaco-list; Thu, 24 May 2001 02:24:54 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA07482
	for ; Thu, 24 May 2001 02:24:52 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA08298
	for ; Thu, 24 May 2001 02:24:50 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4NImlt04176
	for ; Wed, 23 May 2001 14:48:47 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4NImlS04170
	for ; Wed, 23 May 2001 14:48:47 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id OAA11354; Wed, 23 May 2001 14:48:46 -0400 (EDT)
Cc: megaco@fore.com
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id OAA11345; Wed, 23 May 2001 14:48:44 -0400 (EDT)
Message-ID: <3B0C0595.9180C2A8@lucent.com>
Date: Wed, 23 May 2001 14:46:45 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Dave Sclarsky 
Original-CC: megaco@fore.com
Subject: Re: Polls of MGC
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dave Sclarsky wrote:
> 
> Madhubabu,
> 
> The assumption that (from Christians email below) "interaction is only
> needed with the MGC when the end-user does something" ignores the
> fact that sometimes the MGC needs to initiate an interaction because
> an end-user on a DIFFERENT MG did something.

Dave,

Yes, the receiving side MG cannot detect this type of error.
But the (new) MGC detects this type of error.  Why not give it
the mechanism to fix the situation instead of insisting
that the MG detect and fix it?

-troy


From owner-megaco@fore.com  Thu May 24 02:52:43 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07655
	for ; Thu, 24 May 2001 02:52:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA08950;
	Thu, 24 May 2001 02:45:45 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA08403
	for megaco-list; Thu, 24 May 2001 02:44:50 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA08399
	for ; Thu, 24 May 2001 02:44:48 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA08869
	for ; Thu, 24 May 2001 02:44:46 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4NIoqt04552
	for ; Wed, 23 May 2001 14:50:52 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4NIoqS04546
	for ; Wed, 23 May 2001 14:50:52 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id OAA11459; Wed, 23 May 2001 14:50:51 -0400 (EDT)
Cc: megaco@fore.com
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id OAA11450; Wed, 23 May 2001 14:50:50 -0400 (EDT)
Message-ID: <3B0C0612.11F56950@lucent.com>
Date: Wed, 23 May 2001 14:48:50 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Long 
Original-CC: megaco@fore.com
Subject: Re: Polls of MGC
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Paul Long wrote:
> 
> Christian,
> 
> As Dave said, your #2 does not consider an incoming call. It is therefore
> _not_ true that "interaction is only needed with the MGC when the end-user
> does something." Without periodic signaling between the MG and MGC whereby
> the MG can detect MGC failure and switch to an operative MGC, incoming calls
> will be missed after MGC failure and until there is end-user activity.
> Period. 

Only when you base your argument on the assumption that the MG 
is the only one that can repair the relationship.

The MGC can detect and fix this problem.

-troy

> Are you saying that this is satisfactory behavior given the penalty
> of extra bandwidth consumption that periodic signaling would entail? That's
> a valid position, but I want to be sure that you have taken this into
> consideration. Maybe you and others are saying that losing an association is
> like leaving the phone off the hook--the end user will miss incoming calls
> until he or she needs to make a call.
>


From owner-megaco@fore.com  Thu May 24 05:34:58 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09885
	for ; Thu, 24 May 2001 05:34:58 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA13493;
	Thu, 24 May 2001 05:26:59 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA19345
	for megaco-list; Thu, 24 May 2001 05:26:07 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA19341
	for ; Thu, 24 May 2001 05:26:06 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA13309
	for ; Thu, 24 May 2001 05:26:03 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4NH4kX20134
	for ; Wed, 23 May 2001 13:04:46 -0400 (EDT)
Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2])
	by hoemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4NH4BS19848;
	Wed, 23 May 2001 13:04:11 -0400 (EDT)
Received: from lucent.com (pctla [135.3.130.39])
	by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id NAA11031;
	Wed, 23 May 2001 13:04:10 -0400 (EDT)
Message-ID: <3B0BEE46.F3757A41@lucent.com>
Date: Wed, 23 May 2001 13:07:18 -0400
From: Terry L Anderson 
Organization: Lucent Technologies
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Groves , megaco@fore.com
Subject: Re: Polls of MGC
References:  <3B0576D6.46975EDB@lucent.com> <3B0BBF9E.4340CCB7@ericsson.com>
Content-Type: multipart/mixed;
 boundary="------------A8EF930A7EA2AC9F897C9074"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.
--------------A8EF930A7EA2AC9F897C9074
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

(resending since my original seems not to have made it to the list)

MGC/MG relationship is indeed master/slave but registrations are only initiated
from the MG end, so MGC being aware of loss of connectivity or an alternate MGC
being aware that the primary is down does not allow reconnection to the
alternate - only the MG can take action to register with the alternate (as in
11.5).  So it seems to me most important that MG detect failures (as it is the
only one that can take action).  Its the MGC that can do little when it detects
a failure.
MGC perhaps should make the decision as to whether failures should be detected
and frequency of polling but it seems to me that MG should do the polling.

For failures of a TCP link or MGC failure and recovery without loss of state,
MGC may reestablish communications with a re-registration, but I don't
understand how an alternate MGC can take over after a primary failure without MG

detecting the failure.

I did not think that an MG normally sent Add, Move, Subtract.  I believe that
the only MG initiated transactions commonly used are Notify and ServiceChange.
Thus during a quiet period (edge GW with SS7/ISUP signaling, no active calls),
there would be no active events and so no reason to send either Notify or
ServiceChange and so GW would be unaware that:
1. MGC has gone down
2. network has lost connectivity to MGC

In either case, without polling, MG would be unaware.  Yet registering with
alternateMGC might allow it to handle calls.

I thought that the previously discussed methods for MGC and for MG polling were
adequate but if we want to add a new mechanism, one could allow complete control

from MGC end by adding a "timer" event through a package.  MGC could activate
the timer event on say root termination and this would cause a notify after the
MGC specified period.  MGC would detect failure by lack of this notify.  MG
would detect failure when the Notify received no reply.  MGC thus decides
whether polling should occur, what period to use and there is only polling
traffic in one direction but both ends detect failure.  It would be improved if
the package specified that the timer was automatically reset by any messages, so

it would fire only when no messages had been exchanged for the specified time
(MGC would still detect failure by absense of any message for greater than the
timer period, MG detect by failed reply).

Christian Groves wrote:

> G'Day Troy et all,
>
> Sorry for the late support of No Polling. I still have not seen a
> definitive reason that the MG needs to poll the MGC. We have defined a
> master slave protocol with the MGC as the master. The MGC should be in
> control of error situations.
>
> I believe that it's enough that the MG can detect that the MGC has gone
> down when it try to signal using any appropriate H.248 Commands ie.
> Add, Move, sub replies, Notify request, Service Change etc. Lack of
> timely response will indicate failure. The MG can then re-register based
> on this.
>
> If you look at the common MG use cases:
> 1. The MG is a trunking gateway. In this scenario enough traffic will be
> generated to maintain a reasonable flow of signalling to minimise the
> time to detect errors. For a proper Telco solution you should also have
> enough management systems/redundency to know what MGC to hand over to.
>
> 2. The MG is a residential gateway. Signalling traffic is not that great
> but interaction is only needed with the MGC when the end-user does
> something. Therefore the MG will find out about the failure at this
> time. Why generate unessary signalling across limited BW links? There's
> the avalanche problems mentioned earlier but more importantly someone
> will have to pay for bandwidth this signalling takes which basically
> serves no purpose.
> Again in this scenario the MGC will hopefully be owned by someone who
> wants to offer a decent service and has the necessary management
> systems/reduncy. I do not envisage MG registration will take very long
> on a small residential gateway. Its a ServiceChange request/response
> round trip.
>
> What ever the proposed package, service change reason/method, protocol
> update polling is unecessary.
>
> Cheers, Christian
>
> Troy Cauble wrote:
> >
> > Dave Sclarsky wrote:
> > >
> > > Troy,
> > >
> > > It doesn't matter what the new (or restarted) MGC knows or doesn't know.
> > > Megaco defines that the control association between MG and MGC is ALWAYS
> > > initiated by the MG.
> >
> > Then this definition is the problem and should be revisited.
> >
> > Polling is bad.
> >
> > -troy
> >
> > > Given that definition, Johnny's Dad's MG won't be
> > > reachable by a new (or a restarted) MGC until the his MG notices the
> > > failure.  We must define a way for it to know ASAP!

--
------------------------------------------------------------
Terry L Anderson              mailto:tla@lucent.com
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla


--------------A8EF930A7EA2AC9F897C9074
Content-Type: text/x-vcard; charset=us-ascii;
 name="tla.vcf"
Content-Description: Card for Terry L Anderson
Content-Disposition: attachment;
 filename="tla.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Anderson;Terry L
tel;fax:908.582.6729
tel;work:908.582.7013
x-mozilla-html:TRUE
url:http://its.lucent.com/~tla
org:Lucent / InterNetworking Systems;VoIP Access Networks
version:2.1
email;internet:tla@lucent.com
title:DMTS
note:http://www.gti.net/tla  or http://teton.mh.lucent.com/~tla (Lucent internal)
adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA
x-mozilla-cpt:;21296
fn:Terry L Anderson
end:vcard

--------------A8EF930A7EA2AC9F897C9074--



From owner-megaco@fore.com  Thu May 24 05:35:04 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09895
	for ; Thu, 24 May 2001 05:35:03 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA13341;
	Thu, 24 May 2001 05:26:13 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA19158
	for megaco-list; Thu, 24 May 2001 05:24:34 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA19152
	for ; Thu, 24 May 2001 05:24:32 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA13186
	for ; Thu, 24 May 2001 05:24:30 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4NFwdQ27795
	for ; Wed, 23 May 2001 11:58:39 -0400 (EDT)
Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2])
	by hoemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4NFwd027789;
	Wed, 23 May 2001 11:58:39 -0400 (EDT)
Received: from lucent.com ([135.3.128.247])
	by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id LAA05336;
	Wed, 23 May 2001 11:58:38 -0400 (EDT)
Message-ID: <3B0BDDE3.CDA5FC9A@lucent.com>
Date: Wed, 23 May 2001 11:57:23 -0400
From: Terry L Anderson 
Organization: Lucent Technologies
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Groves 
CC: megaco@fore.com
Subject: Re: Polls of MGC
References:  <3B0576D6.46975EDB@lucent.com> <3B0BBF9E.4340CCB7@ericsson.com>
Content-Type: multipart/mixed;
 boundary="------------306CAE42C7FDE3BFA77BA355"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.
--------------306CAE42C7FDE3BFA77BA355
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

MGC/MG relationship is indeed master/slave but registrations are only initiated
from the MG end, so MGC being aware of loss of connectivity or an alternate MGC
being aware that the primary is down does not allow reconnection to the
alternate - only the MG can take action to register with the alternate (as in
11.5).  So it seems to me most important that MG detect failures (as it is the
only one that can take action).  MGC perhaps should make the decision as to
whether failures should be detected and frequency of polling but it seems to me
that MG should do the polling.

For failures of a TCP link or MGC failure and recovery without loss of state,
MGC may reestablish communications with a re-registration, but I don't
understand how an alternate MGC can take over after a primary failure without MG
detecting the failure.

I did not think that an MG normally sent Add, Move, Subtract.  I believe that
the only MG initiated transactions commonly used are Notify and ServiceChange.
Thus during a quiet period (edge GW with SS7/ISUP signaling, no active calls),
there would be no active events and so no reason to send either Notify or
ServiceChange and so GW would be unaware that:
1. MGC has gone down
2. network has lost connectivity to MGC

In either case, without polling, MG would be unaware.  Yet registering with
alternateMGC might allow it to handle calls.

I thought that the previously discussed methods for MGC and for MG polling were
adequate but if we want to add a new mechanism, one could allow complete control
from MGC end by adding a "timer" event through a package.  MGC could activate
the timer event on say root termination and this would cause a notify after the
MGC specified period.  MGC would detect failure by lack of this notify.  MG
would detect failure when the Notify received no reply.  MGC thus decides
whether polling should occur, what period to use and there is only polling
traffic in one direction but both ends detect failure.  It would be improved if
the package specified that the timer was automatically reset by any messages, so
it would fire only when no messages had been exchanged for the specified time
(MGC would still detect failure by absense of any message for greater than the
timer period, MG detect by failed reply).


Christian Groves wrote:

> G'Day Troy et all,
>
> Sorry for the late support of No Polling. I still have not seen a
> definitive reason that the MG needs to poll the MGC. We have defined a
> master slave protocol with the MGC as the master. The MGC should be in
> control of error situations.
>
> I believe that it's enough that the MG can detect that the MGC has gone
> down when it try to signal using any appropriate H.248 Commands ie.
> Add, Move, sub replies, Notify request, Service Change etc. Lack of
> timely response will indicate failure. The MG can then re-register based
> on this.
>
> If you look at the common MG use cases:
> 1. The MG is a trunking gateway. In this scenario enough traffic will be
> generated to maintain a reasonable flow of signalling to minimise the
> time to detect errors. For a proper Telco solution you should also have
> enough management systems/redundency to know what MGC to hand over to.
>
> 2. The MG is a residential gateway. Signalling traffic is not that great
> but interaction is only needed with the MGC when the end-user does
> something. Therefore the MG will find out about the failure at this
> time. Why generate unessary signalling across limited BW links? There's
> the avalanche problems mentioned earlier but more importantly someone
> will have to pay for bandwidth this signalling takes which basically
> serves no purpose.
> Again in this scenario the MGC will hopefully be owned by someone who
> wants to offer a decent service and has the necessary management
> systems/reduncy. I do not envisage MG registration will take very long
> on a small residential gateway. Its a ServiceChange request/response
> round trip.
>
> What ever the proposed package, service change reason/method, protocol
> update polling is unecessary.
>
> Cheers, Christian
>
> Troy Cauble wrote:
> >
> > Dave Sclarsky wrote:
> > >
> > > Troy,
> > >
> > > It doesn't matter what the new (or restarted) MGC knows or doesn't know.
> > > Megaco defines that the control association between MG and MGC is ALWAYS
> > > initiated by the MG.
> >
> > Then this definition is the problem and should be revisited.
> >
> > Polling is bad.
> >
> > -troy
> >
> > > Given that definition, Johnny's Dad's MG won't be
> > > reachable by a new (or a restarted) MGC until the his MG notices the
> > > failure.  We must define a way for it to know ASAP!

--
------------------------------------------------------------
Terry L Anderson              mailto:tla@lucent.com
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla


--------------306CAE42C7FDE3BFA77BA355
Content-Type: text/x-vcard; charset=us-ascii;
 name="tla.vcf"
Content-Description: Card for Terry L Anderson
Content-Disposition: attachment;
 filename="tla.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Anderson;Terry L
tel;fax:908.582.6729
tel;work:908.582.7013
x-mozilla-html:TRUE
url:http://its.lucent.com/~tla
org:Lucent / InterNetworking Systems;VoIP Access Networks
version:2.1
email;internet:tla@lucent.com
title:DMTS
note:http://www.gti.net/tla  or http://teton.mh.lucent.com/~tla (Lucent internal)
adr;quoted-printable:;;Rm 2B-121=0D=0A600 Mountain Ave;Murray Hill;NJ;07974;USA
x-mozilla-cpt:;7264
fn:Terry L Anderson
end:vcard

--------------306CAE42C7FDE3BFA77BA355--



From owner-megaco@fore.com  Thu May 24 06:18:18 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10145
	for ; Thu, 24 May 2001 06:18:18 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA14914;
	Thu, 24 May 2001 06:12:38 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id GAA23146
	for megaco-list; Thu, 24 May 2001 06:11:55 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA23142
	for ; Thu, 24 May 2001 06:11:54 -0400 (EDT)
Received: from ties.itu.ch (ties.itu.ch [156.106.192.33])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA14827
	for ; Thu, 24 May 2001 06:11:51 -0400 (EDT)
Received: from ericsson.com ([156.106.209.254])
	by ties.itu.ch (8.9.3/8.9.3) with ESMTP id MAA31356;
	Thu, 24 May 2001 12:11:33 +0200 (MET DST)
Message-ID: <3B0CD7B7.2471186C@ericsson.com>
Date: Thu, 24 May 2001 19:43:19 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dan Elbert 
CC: "'Madhu Babu Brahmanapally'" ,
        "'Dave Sclarsky'" ,
        "'Troy Cauble'" ,
        "'Rosen, Brian'" , knayar@hss.hns.com,
        megaco@fore.com
Subject: Re: Polls of MGC
References: <0D5BBF5D638DD4119E3400508BD94945811131@RADVPOST>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day Dan,

I don't understand "the MGc can never contact the MG because it doesn't
know where the MG is listening". The MGC should at least maintain the
state of registered MGs. This problem is not unique to the "polling"
situation described in 1 & 2. H248 clause 11.5 covers MGC failure.

If a MG is registered with a certain MGC to accept incoming calls then
its up to the operator of the MGC to provide an alternative in case of
failure. 11.5 describes how the new MGC can use the same identity.

On an outgoing call from the ResGW if it detects an MGC failure it can
always choose and register with another MGC in its list.

You could also use a reliable connection oriented transport and give
UDP/ALF a miss and solve your problems.

Christian

Dan Elbert wrote:
> 
> Hi
> I think the scenario can be as following:
> 1. The MGC fails without being able to send a "Handoff"
> 2. Later on the MGC restarts or a backup MGC comes up
> In this case the MGC can never contact the MG because it doesn't know where
> the MG is listening.
> So the problem stands if the MGC needs to contact the MG before the MG
> becomes aware that the connection with the MGC has been lost.
> 
> Dan
> 
> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Wednesday, May 23, 2001 10:37 AM
> To: 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
> Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> Subject: RE: Polls of MGC
> 
> HI Dave,
> If the MG is connected to the "broken" MGC how can it receive commands from
> two MGC's. The MG should reinitiate the registration for accepting messages
> from the new MGC.
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dave Sclarsky
> Sent: Wednesday, May 23, 2001 10:23 AM
> To: 'Christian Groves'; Troy Cauble
> Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com'; megaco@fore.com
> Subject: RE: Polls of MGC
> 
> Christian,
> What happens when the MGC wants to ring a phone on an MG that is a ResGW,
> but that MG still thinks tbat it is connected to a 'broken' MGC?
> DaveS.
> 
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Wednesday, May 23, 2001 9:48 AM
> > To: Troy Cauble
> > Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
> > megaco@fore.com
> > Subject: Re: Polls of MGC
> >
> >
> > G'Day Troy et all,
> >
> > Sorry for the late support of No Polling. I still have not seen a
> > definitive reason that the MG needs to poll the MGC. We have defined a
> > master slave protocol with the MGC as the master. The MGC should be in
> > control of error situations.
> >
> > I believe that it's enough that the MG can detect that the
> > MGC has gone
> > down when it try to signal using any appropriate H.248 Commands ie.
> > Add, Move, sub replies, Notify request, Service Change etc. Lack of
> > timely response will indicate failure. The MG can then
> > re-register based
> > on this.
> >
> > If you look at the common MG use cases:
> > 1. The MG is a trunking gateway. In this scenario enough
> > traffic will be
> > generated to maintain a reasonable flow of signalling to minimise the
> > time to detect errors. For a proper Telco solution you should
> > also have
> > enough management systems/redundency to know what MGC to hand over to.
> >
> > 2. The MG is a residential gateway. Signalling traffic is not
> > that great
> > but interaction is only needed with the MGC when the end-user does
> > something. Therefore the MG will find out about the failure at this
> > time. Why generate unessary signalling across limited BW
> > links? There's
> > the avalanche problems mentioned earlier but more importantly someone
> > will have to pay for bandwidth this signalling takes which basically
> > serves no purpose.
> > Again in this scenario the MGC will hopefully be owned by someone who
> > wants to offer a decent service and has the necessary management
> > systems/reduncy. I do not envisage MG registration will take very long
> > on a small residential gateway. Its a ServiceChange request/response
> > round trip.
> >
> > What ever the proposed package, service change reason/method, protocol
> > update polling is unecessary.
> >
> > Cheers, Christian
> >
> > Troy Cauble wrote:
> > >
> > > Dave Sclarsky wrote:
> > > >
> > > > Troy,
> > > >
> > > > It doesn't matter what the new (or restarted) MGC knows
> > or doesn't know.
> > > > Megaco defines that the control association between MG
> > and MGC is ALWAYS
> > > > initiated by the MG.
> > >
> > > Then this definition is the problem and should be revisited.
> > >
> > > Polling is bad.
> > >
> > > -troy
> > >
> > > > Given that definition, Johnny's Dad's MG won't be
> > > > reachable by a new (or a restarted) MGC until the his MG
> > notices the
> > > > failure.  We must define a way for it to know ASAP!
> >



From owner-megaco@fore.com  Thu May 24 10:07:08 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13839
	for ; Thu, 24 May 2001 10:07:07 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA27970;
	Thu, 24 May 2001 10:00:34 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA02139
	for megaco-list; Thu, 24 May 2001 09:58:53 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA02123
	for ; Thu, 24 May 2001 09:58:51 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA27734
	for ; Thu, 24 May 2001 09:58:47 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4ODwmm08300
	for ; Thu, 24 May 2001 09:58:48 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4ODwm908293
	for ; Thu, 24 May 2001 09:58:48 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id JAA19019; Thu, 24 May 2001 09:58:45 -0400 (EDT)
Cc: megaco@fore.com
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id JAA19000; Thu, 24 May 2001 09:58:44 -0400 (EDT)
Message-ID: <3B0D131E.FF8A9007@lucent.com>
Date: Thu, 24 May 2001 09:56:46 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Terry L Anderson 
Original-CC: megaco@fore.com
Subject: Re: Polls of MGC
References: <3B0C8058.65043888@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Terry L Anderson wrote:
> 
> (resending since my original seems not to have made it to the list)
> 
> MGC/MG relationship is indeed master/slave but registrations are only
> initiated
> from the MG end, so MGC being aware of loss of connectivity or an
> alternate MGC
> being aware that the primary is down does not allow reconnection to the
> alternate - only the MG can take action to register with the alternate
> (as in
> 11.5).  

Again, it seems much cleaner to fix this problem by changing
"registrations are only initiated from the MG end" statement.  
Why are MGC initiated regstrations considered so evil?

-troy

> So it seems to me most important that MG detect failures (as it
> is the
> only one that can take action).  Its the MGC that can do little when it
> detects
> a failure.
> MGC perhaps should make the decision as to whether failures should be
> detected
> and frequency of polling but it seems to me that MG should do the
> polling.
> 
> For failures of a TCP link or MGC failure and recovery without loss of
> state,
> MGC may reestablish communications with a re-registration, but I don't
> understand how an alternate MGC can take over after a primary failure
> without MG
> 
> detecting the failure.
> 
> I did not think that an MG normally sent Add, Move, Subtract.  I believe
> that
> the only MG initiated transactions commonly used are Notify and
> ServiceChange.
> Thus during a quiet period (edge GW with SS7/ISUP signaling, no active
> calls),
> there would be no active events and so no reason to send either Notify
> or
> ServiceChange and so GW would be unaware that:
> 1. MGC has gone down
> 2. network has lost connectivity to MGC
> 
> In either case, without polling, MG would be unaware.  Yet registering
> with
> alternateMGC might allow it to handle calls.
> 
> I thought that the previously discussed methods for MGC and for MG
> polling were
> adequate but if we want to add a new mechanism, one could allow complete
> control
> 
> from MGC end by adding a "timer" event through a package.  MGC could
> activate
> the timer event on say root termination and this would cause a notify
> after the
> MGC specified period.  MGC would detect failure by lack of this notify.
> MG
> would detect failure when the Notify received no reply.  MGC thus
> decides
> whether polling should occur, what period to use and there is only
> polling
> traffic in one direction but both ends detect failure.  It would be
> improved if
> the package specified that the timer was automatically reset by any
> messages, so
> 
> it would fire only when no messages had been exchanged for the specified
> time
> (MGC would still detect failure by absense of any message for greater
> than the
> timer period, MG detect by failed reply).
> 
> Christian Groves wrote:
> 
> > G'Day Troy et all,
> >
> > Sorry for the late support of No Polling. I still have not seen a
> > definitive reason that the MG needs to poll the MGC. We have defined a
> 
> > master slave protocol with the MGC as the master. The MGC should be in
> 
> > control of error situations.
> >
> > I believe that it's enough that the MG can detect that the MGC has
> gone
> > down when it try to signal using any appropriate H.248 Commands ie.
> > Add, Move, sub replies, Notify request, Service Change etc. Lack of
> > timely response will indicate failure. The MG can then re-register
> based
> > on this.
> >
> > If you look at the common MG use cases:
> > 1. The MG is a trunking gateway. In this scenario enough traffic will
> be
> > generated to maintain a reasonable flow of signalling to minimise the
> > time to detect errors. For a proper Telco solution you should also
> have
> > enough management systems/redundency to know what MGC to hand over to.
> 
> >
> > 2. The MG is a residential gateway. Signalling traffic is not that
> great
> > but interaction is only needed with the MGC when the end-user does
> > something. Therefore the MG will find out about the failure at this
> > time. Why generate unessary signalling across limited BW links?
> There's
> > the avalanche problems mentioned earlier but more importantly someone
> > will have to pay for bandwidth this signalling takes which basically
> > serves no purpose.
> > Again in this scenario the MGC will hopefully be owned by someone who
> > wants to offer a decent service and has the necessary management
> > systems/reduncy. I do not envisage MG registration will take very long
> 
> > on a small residential gateway. Its a ServiceChange request/response
> > round trip.
> >
> > What ever the proposed package, service change reason/method, protocol
> 
> > update polling is unecessary.
> >
> > Cheers, Christian
> >
> > Troy Cauble wrote:
> > >
> > > Dave Sclarsky wrote:
> > > >
> > > > Troy,
> > > >
> > > > It doesn't matter what the new (or restarted) MGC knows or doesn't
> know.
> > > > Megaco defines that the control association between MG and MGC is
> ALWAYS
> > > > initiated by the MG.
> > >
> > > Then this definition is the problem and should be revisited.
> > >
> > > Polling is bad.
> > >
> > > -troy
> > >
> > > > Given that definition, Johnny's Dad's MG won't be
> > > > reachable by a new (or a restarted) MGC until the his MG notices
> the
> > > > failure.  We must define a way for it to know ASAP!
> 
> --
> -------------------------------------------------------
> Terry L Anderson, DMTS                   tla@lucent.com
> Lucent Technologies /INS/ Voice over IP Access Networks
> Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
> Voice:908 582-7013  FAX:908 582-6729
> http://its.lucent.com/~tla  (Lucent internal)
> http://www.gti.net/tla
> -------------------------------------------------------


From owner-megaco@fore.com  Thu May 24 10:27:11 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14222
	for ; Thu, 24 May 2001 10:27:10 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA29665;
	Thu, 24 May 2001 10:17:43 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA08018
	for megaco-list; Thu, 24 May 2001 10:17:01 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07990
	for ; Thu, 24 May 2001 10:16:59 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 24 May 2001 10:16:16 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F68A@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Troy Cauble'" , Terry L Anderson 
Cc: megaco@fore.com
Subject: RE: Polls of MGC
Date: Thu, 24 May 2001 10:16:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Security implications.  
"Hello, I'm your new master. Don't worry, everything will be all right"

Brian

> -----Original Message-----
> From: Troy Cauble [mailto:troy@lucent.com]
> Sent: Thursday, May 24, 2001 9:57 AM
> To: Terry L Anderson
> Cc: megaco@fore.com
> Subject: Re: Polls of MGC
> 
> 
> Terry L Anderson wrote:
> > 
> > (resending since my original seems not to have made it to the list)
> > 
> > MGC/MG relationship is indeed master/slave but 
> registrations are only
> > initiated
> > from the MG end, so MGC being aware of loss of connectivity or an
> > alternate MGC
> > being aware that the primary is down does not allow 
> reconnection to the
> > alternate - only the MG can take action to register with 
> the alternate
> > (as in
> > 11.5).  
> 
> Again, it seems much cleaner to fix this problem by changing
> "registrations are only initiated from the MG end" statement.  
> Why are MGC initiated regstrations considered so evil?
> 
> -troy
> 
> > So it seems to me most important that MG detect failures (as it
> > is the
> > only one that can take action).  Its the MGC that can do 
> little when it
> > detects
> > a failure.
> > MGC perhaps should make the decision as to whether failures 
> should be
> > detected
> > and frequency of polling but it seems to me that MG should do the
> > polling.
> > 
> > For failures of a TCP link or MGC failure and recovery 
> without loss of
> > state,
> > MGC may reestablish communications with a re-registration, 
> but I don't
> > understand how an alternate MGC can take over after a 
> primary failure
> > without MG
> > 
> > detecting the failure.
> > 
> > I did not think that an MG normally sent Add, Move, 
> Subtract.  I believe
> > that
> > the only MG initiated transactions commonly used are Notify and
> > ServiceChange.
> > Thus during a quiet period (edge GW with SS7/ISUP 
> signaling, no active
> > calls),
> > there would be no active events and so no reason to send 
> either Notify
> > or
> > ServiceChange and so GW would be unaware that:
> > 1. MGC has gone down
> > 2. network has lost connectivity to MGC
> > 
> > In either case, without polling, MG would be unaware.  Yet 
> registering
> > with
> > alternateMGC might allow it to handle calls.
> > 
> > I thought that the previously discussed methods for MGC and for MG
> > polling were
> > adequate but if we want to add a new mechanism, one could 
> allow complete
> > control
> > 
> > from MGC end by adding a "timer" event through a package.  MGC could
> > activate
> > the timer event on say root termination and this would 
> cause a notify
> > after the
> > MGC specified period.  MGC would detect failure by lack of 
> this notify.
> > MG
> > would detect failure when the Notify received no reply.  MGC thus
> > decides
> > whether polling should occur, what period to use and there is only
> > polling
> > traffic in one direction but both ends detect failure.  It would be
> > improved if
> > the package specified that the timer was automatically reset by any
> > messages, so
> > 
> > it would fire only when no messages had been exchanged for 
> the specified
> > time
> > (MGC would still detect failure by absense of any message 
> for greater
> > than the
> > timer period, MG detect by failed reply).
> > 
> > Christian Groves wrote:
> > 
> > > G'Day Troy et all,
> > >
> > > Sorry for the late support of No Polling. I still have not seen a
> > > definitive reason that the MG needs to poll the MGC. We 
> have defined a
> > 
> > > master slave protocol with the MGC as the master. The MGC 
> should be in
> > 
> > > control of error situations.
> > >
> > > I believe that it's enough that the MG can detect that the MGC has
> > gone
> > > down when it try to signal using any appropriate H.248 
> Commands ie.
> > > Add, Move, sub replies, Notify request, Service Change 
> etc. Lack of
> > > timely response will indicate failure. The MG can then re-register
> > based
> > > on this.
> > >
> > > If you look at the common MG use cases:
> > > 1. The MG is a trunking gateway. In this scenario enough 
> traffic will
> > be
> > > generated to maintain a reasonable flow of signalling to 
> minimise the
> > > time to detect errors. For a proper Telco solution you should also
> > have
> > > enough management systems/redundency to know what MGC to 
> hand over to.
> > 
> > >
> > > 2. The MG is a residential gateway. Signalling traffic is not that
> > great
> > > but interaction is only needed with the MGC when the end-user does
> > > something. Therefore the MG will find out about the 
> failure at this
> > > time. Why generate unessary signalling across limited BW links?
> > There's
> > > the avalanche problems mentioned earlier but more 
> importantly someone
> > > will have to pay for bandwidth this signalling takes 
> which basically
> > > serves no purpose.
> > > Again in this scenario the MGC will hopefully be owned by 
> someone who
> > > wants to offer a decent service and has the necessary management
> > > systems/reduncy. I do not envisage MG registration will 
> take very long
> > 
> > > on a small residential gateway. Its a ServiceChange 
> request/response
> > > round trip.
> > >
> > > What ever the proposed package, service change 
> reason/method, protocol
> > 
> > > update polling is unecessary.
> > >
> > > Cheers, Christian
> > >
> > > Troy Cauble wrote:
> > > >
> > > > Dave Sclarsky wrote:
> > > > >
> > > > > Troy,
> > > > >
> > > > > It doesn't matter what the new (or restarted) MGC 
> knows or doesn't
> > know.
> > > > > Megaco defines that the control association between 
> MG and MGC is
> > ALWAYS
> > > > > initiated by the MG.
> > > >
> > > > Then this definition is the problem and should be revisited.
> > > >
> > > > Polling is bad.
> > > >
> > > > -troy
> > > >
> > > > > Given that definition, Johnny's Dad's MG won't be
> > > > > reachable by a new (or a restarted) MGC until the his 
> MG notices
> > the
> > > > > failure.  We must define a way for it to know ASAP!
> > 
> > --
> > -------------------------------------------------------
> > Terry L Anderson, DMTS                   tla@lucent.com
> > Lucent Technologies /INS/ Voice over IP Access Networks
> > Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
> > Voice:908 582-7013  FAX:908 582-6729
> > http://its.lucent.com/~tla  (Lucent internal)
> > http://www.gti.net/tla
> > -------------------------------------------------------
> 


From owner-megaco@fore.com  Thu May 24 10:41:52 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14407
	for ; Thu, 24 May 2001 10:41:51 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA01297;
	Thu, 24 May 2001 10:34:00 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA11958
	for megaco-list; Thu, 24 May 2001 10:33:08 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11954
	for ; Thu, 24 May 2001 10:33:07 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA01135
	for ; Thu, 24 May 2001 10:33:03 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Thu, 24 May 2001 09:33:54 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD9494581113C@RADVPOST>
From: Dan Elbert 
To: "'Christian Groves'" 
Cc: megaco@fore.com
Subject: RE: Polls of MGC
Date: Thu, 24 May 2001 09:33:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hi Christian
I was referring to the case were there is no redundancy or redundancy fails.
I was trying to see what is the minimal level of support that the protocol
has to provide. I think that you can have the same problem in TCP, i.e., the
connection was broken but you didn't detect it until trying to send a
Notify.
As other people pointed, one of the problems of waiting for the MG to send a
Notify to reconnect is when another party try to contact the disconnected
MG, and other problem is with specific MG's that will never generate
Notifies.
A final point that I'd like to make is that probably this issues will be
less important when we have very reliable MGCs, but they are very useful for
the development phase. That's why having some kind of parameter configurable
by the MGC will be very useful.

Dan

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com]
Sent: Thursday, May 24, 2001 5:43 AM
To: Dan Elbert
Cc: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; 'Troy Cauble'; 'Rosen,
Brian'; knayar@hss.hns.com; megaco@fore.com
Subject: Re: Polls of MGC

G'Day Dan,

I don't understand "the MGc can never contact the MG because it doesn't
know where the MG is listening". The MGC should at least maintain the
state of registered MGs. This problem is not unique to the "polling"
situation described in 1 & 2. H248 clause 11.5 covers MGC failure.

If a MG is registered with a certain MGC to accept incoming calls then
its up to the operator of the MGC to provide an alternative in case of
failure. 11.5 describes how the new MGC can use the same identity.

On an outgoing call from the ResGW if it detects an MGC failure it can
always choose and register with another MGC in its list.

You could also use a reliable connection oriented transport and give
UDP/ALF a miss and solve your problems.

Christian

Dan Elbert wrote:
>
> Hi
> I think the scenario can be as following:
> 1. The MGC fails without being able to send a "Handoff"
> 2. Later on the MGC restarts or a backup MGC comes up
> In this case the MGC can never contact the MG because it doesn't know
where
> the MG is listening.
> So the problem stands if the MGC needs to contact the MG before the MG
> becomes aware that the connection with the MGC has been lost.
>
> Dan
>
> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Wednesday, May 23, 2001 10:37 AM
> To: 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
> Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> Subject: RE: Polls of MGC
>
> HI Dave,
> If the MG is connected to the "broken" MGC how can it receive commands
from
> two MGC's. The MG should reinitiate the registration for accepting
messages
> from the new MGC.
>
> Regards
> Madhubabu
>
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dave Sclarsky
> Sent: Wednesday, May 23, 2001 10:23 AM
> To: 'Christian Groves'; Troy Cauble
> Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com'; megaco@fore.com
> Subject: RE: Polls of MGC
>
> Christian,
> What happens when the MGC wants to ring a phone on an MG that is a ResGW,
> but that MG still thinks tbat it is connected to a 'broken' MGC?
> DaveS.
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Wednesday, May 23, 2001 9:48 AM
> > To: Troy Cauble
> > Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
> > megaco@fore.com
> > Subject: Re: Polls of MGC
> >
> >
> > G'Day Troy et all,
> >
> > Sorry for the late support of No Polling. I still have not seen a
> > definitive reason that the MG needs to poll the MGC. We have defined a
> > master slave protocol with the MGC as the master. The MGC should be in
> > control of error situations.
> >
> > I believe that it's enough that the MG can detect that the
> > MGC has gone
> > down when it try to signal using any appropriate H.248 Commands ie.
> > Add, Move, sub replies, Notify request, Service Change etc. Lack of
> > timely response will indicate failure. The MG can then
> > re-register based
> > on this.
> >
> > If you look at the common MG use cases:
> > 1. The MG is a trunking gateway. In this scenario enough
> > traffic will be
> > generated to maintain a reasonable flow of signalling to minimise the
> > time to detect errors. For a proper Telco solution you should
> > also have
> > enough management systems/redundency to know what MGC to hand over to.
> >
> > 2. The MG is a residential gateway. Signalling traffic is not
> > that great
> > but interaction is only needed with the MGC when the end-user does
> > something. Therefore the MG will find out about the failure at this
> > time. Why generate unessary signalling across limited BW
> > links? There's
> > the avalanche problems mentioned earlier but more importantly someone
> > will have to pay for bandwidth this signalling takes which basically
> > serves no purpose.
> > Again in this scenario the MGC will hopefully be owned by someone who
> > wants to offer a decent service and has the necessary management
> > systems/reduncy. I do not envisage MG registration will take very long
> > on a small residential gateway. Its a ServiceChange request/response
> > round trip.
> >
> > What ever the proposed package, service change reason/method, protocol
> > update polling is unecessary.
> >
> > Cheers, Christian
> >
> > Troy Cauble wrote:
> > >
> > > Dave Sclarsky wrote:
> > > >
> > > > Troy,
> > > >
> > > > It doesn't matter what the new (or restarted) MGC knows
> > or doesn't know.
> > > > Megaco defines that the control association between MG
> > and MGC is ALWAYS
> > > > initiated by the MG.
> > >
> > > Then this definition is the problem and should be revisited.
> > >
> > > Polling is bad.
> > >
> > > -troy
> > >
> > > > Given that definition, Johnny's Dad's MG won't be
> > > > reachable by a new (or a restarted) MGC until the his MG
> > notices the
> > > > failure.  We must define a way for it to know ASAP!
> >


From owner-megaco@fore.com  Thu May 24 10:48:45 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14546
	for ; Thu, 24 May 2001 10:48:44 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA02133;
	Thu, 24 May 2001 10:41:10 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA13941
	for megaco-list; Thu, 24 May 2001 10:40:26 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13909
	for ; Thu, 24 May 2001 10:40:24 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA01994
	for ; Thu, 24 May 2001 10:40:19 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4OEeKI03454
	for ; Thu, 24 May 2001 10:40:20 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4OEeJs03424
	for ; Thu, 24 May 2001 10:40:20 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id KAA20664; Thu, 24 May 2001 10:40:16 -0400 (EDT)
Cc: Terry L Anderson , megaco@fore.com
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id KAA20640; Thu, 24 May 2001 10:40:14 -0400 (EDT)
Message-ID: <3B0D1CD8.26E01963@lucent.com>
Date: Thu, 24 May 2001 10:38:16 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" 
Original-CC: Terry L Anderson , megaco@fore.com
Subject: Re: Polls of MGC
References: <4FBEA8857476D311A03300204840E1CF01A6F68A@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


Brian,

How would an MG find a secure alternative to talk to?
By using it's pre-provisioned list, right?

If an MG accepts "I'm your new master" messages only
from MGCs on the same pre-provisioned list, the 
level of security is EXACTLY THE SAME.

-troy

"Rosen, Brian" wrote:
> 
> Security implications.
> "Hello, I'm your new master. Don't worry, everything will be all right"
> 
> Brian
> 
> > -----Original Message-----
> > From: Troy Cauble [mailto:troy@lucent.com]
> > Sent: Thursday, May 24, 2001 9:57 AM
> > To: Terry L Anderson
> > Cc: megaco@fore.com
> > Subject: Re: Polls of MGC
> >
> >
> > Terry L Anderson wrote:
> > >
> > > (resending since my original seems not to have made it to the list)
> > >
> > > MGC/MG relationship is indeed master/slave but
> > registrations are only
> > > initiated
> > > from the MG end, so MGC being aware of loss of connectivity or an
> > > alternate MGC
> > > being aware that the primary is down does not allow
> > reconnection to the
> > > alternate - only the MG can take action to register with
> > the alternate
> > > (as in
> > > 11.5).
> >
> > Again, it seems much cleaner to fix this problem by changing
> > "registrations are only initiated from the MG end" statement.
> > Why are MGC initiated regstrations considered so evil?
> >
> > -troy
> >
> > > So it seems to me most important that MG detect failures (as it
> > > is the
> > > only one that can take action).  Its the MGC that can do
> > little when it
> > > detects
> > > a failure.
> > > MGC perhaps should make the decision as to whether failures
> > should be
> > > detected
> > > and frequency of polling but it seems to me that MG should do the
> > > polling.
> > >
> > > For failures of a TCP link or MGC failure and recovery
> > without loss of
> > > state,
> > > MGC may reestablish communications with a re-registration,
> > but I don't
> > > understand how an alternate MGC can take over after a
> > primary failure
> > > without MG
> > >
> > > detecting the failure.
> > >
> > > I did not think that an MG normally sent Add, Move,
> > Subtract.  I believe
> > > that
> > > the only MG initiated transactions commonly used are Notify and
> > > ServiceChange.
> > > Thus during a quiet period (edge GW with SS7/ISUP
> > signaling, no active
> > > calls),
> > > there would be no active events and so no reason to send
> > either Notify
> > > or
> > > ServiceChange and so GW would be unaware that:
> > > 1. MGC has gone down
> > > 2. network has lost connectivity to MGC
> > >
> > > In either case, without polling, MG would be unaware.  Yet
> > registering
> > > with
> > > alternateMGC might allow it to handle calls.
> > >
> > > I thought that the previously discussed methods for MGC and for MG
> > > polling were
> > > adequate but if we want to add a new mechanism, one could
> > allow complete
> > > control
> > >
> > > from MGC end by adding a "timer" event through a package.  MGC could
> > > activate
> > > the timer event on say root termination and this would
> > cause a notify
> > > after the
> > > MGC specified period.  MGC would detect failure by lack of
> > this notify.
> > > MG
> > > would detect failure when the Notify received no reply.  MGC thus
> > > decides
> > > whether polling should occur, what period to use and there is only
> > > polling
> > > traffic in one direction but both ends detect failure.  It would be
> > > improved if
> > > the package specified that the timer was automatically reset by any
> > > messages, so
> > >
> > > it would fire only when no messages had been exchanged for
> > the specified
> > > time
> > > (MGC would still detect failure by absense of any message
> > for greater
> > > than the
> > > timer period, MG detect by failed reply).
> > >
> > > Christian Groves wrote:
> > >
> > > > G'Day Troy et all,
> > > >
> > > > Sorry for the late support of No Polling. I still have not seen a
> > > > definitive reason that the MG needs to poll the MGC. We
> > have defined a
> > >
> > > > master slave protocol with the MGC as the master. The MGC
> > should be in
> > >
> > > > control of error situations.
> > > >
> > > > I believe that it's enough that the MG can detect that the MGC has
> > > gone
> > > > down when it try to signal using any appropriate H.248
> > Commands ie.
> > > > Add, Move, sub replies, Notify request, Service Change
> > etc. Lack of
> > > > timely response will indicate failure. The MG can then re-register
> > > based
> > > > on this.
> > > >
> > > > If you look at the common MG use cases:
> > > > 1. The MG is a trunking gateway. In this scenario enough
> > traffic will
> > > be
> > > > generated to maintain a reasonable flow of signalling to
> > minimise the
> > > > time to detect errors. For a proper Telco solution you should also
> > > have
> > > > enough management systems/redundency to know what MGC to
> > hand over to.
> > >
> > > >
> > > > 2. The MG is a residential gateway. Signalling traffic is not that
> > > great
> > > > but interaction is only needed with the MGC when the end-user does
> > > > something. Therefore the MG will find out about the
> > failure at this
> > > > time. Why generate unessary signalling across limited BW links?
> > > There's
> > > > the avalanche problems mentioned earlier but more
> > importantly someone
> > > > will have to pay for bandwidth this signalling takes
> > which basically
> > > > serves no purpose.
> > > > Again in this scenario the MGC will hopefully be owned by
> > someone who
> > > > wants to offer a decent service and has the necessary management
> > > > systems/reduncy. I do not envisage MG registration will
> > take very long
> > >
> > > > on a small residential gateway. Its a ServiceChange
> > request/response
> > > > round trip.
> > > >
> > > > What ever the proposed package, service change
> > reason/method, protocol
> > >
> > > > update polling is unecessary.
> > > >
> > > > Cheers, Christian
> > > >
> > > > Troy Cauble wrote:
> > > > >
> > > > > Dave Sclarsky wrote:
> > > > > >
> > > > > > Troy,
> > > > > >
> > > > > > It doesn't matter what the new (or restarted) MGC
> > knows or doesn't
> > > know.
> > > > > > Megaco defines that the control association between
> > MG and MGC is
> > > ALWAYS
> > > > > > initiated by the MG.
> > > > >
> > > > > Then this definition is the problem and should be revisited.
> > > > >
> > > > > Polling is bad.
> > > > >
> > > > > -troy
> > > > >
> > > > > > Given that definition, Johnny's Dad's MG won't be
> > > > > > reachable by a new (or a restarted) MGC until the his
> > MG notices
> > > the
> > > > > > failure.  We must define a way for it to know ASAP!
> > >
> > > --
> > > -------------------------------------------------------
> > > Terry L Anderson, DMTS                   tla@lucent.com
> > > Lucent Technologies /INS/ Voice over IP Access Networks
> > > Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
> > > Voice:908 582-7013  FAX:908 582-6729
> > > http://its.lucent.com/~tla  (Lucent internal)
> > > http://www.gti.net/tla
> > > -------------------------------------------------------
> >


From owner-megaco@fore.com  Thu May 24 10:58:04 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14694
	for ; Thu, 24 May 2001 10:58:03 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03151;
	Thu, 24 May 2001 10:50:25 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA16366
	for megaco-list; Thu, 24 May 2001 10:49:29 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16361
	for ; Thu, 24 May 2001 10:49:28 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA02938
	for ; Thu, 24 May 2001 10:49:25 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACV18389;
	Thu, 24 May 2001 10:49:21 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Rosen, Brian'" ,
        "'Troy Cauble'" ,
        "'Terry L Anderson'" 
Cc: 
Subject: RE: Polls of MGC
Date: Thu, 24 May 2001 10:52:56 -0400
Message-ID: <043001c0e461$38afcd60$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <4FBEA8857476D311A03300204840E1CF01A6F68A@whq-msgusr-02.pit.comms.marconi.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Brian/all,
A Novice doubt. If the MG can say to MGC that "I'm your slave...please
control me", why not the MGC can say "I'm your new master". I think both MG
and MGC will know each other by pre-provisioning. Else any MG can register
to any MGC and any MGC can control any MG.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Thursday, May 24, 2001 10:17 AM
To: 'Troy Cauble'; Terry L Anderson
Cc: megaco@fore.com
Subject: RE: Polls of MGC


Security implications.
"Hello, I'm your new master. Don't worry, everything will be all right"

Brian

> -----Original Message-----
> From: Troy Cauble [mailto:troy@lucent.com]
> Sent: Thursday, May 24, 2001 9:57 AM
> To: Terry L Anderson
> Cc: megaco@fore.com
> Subject: Re: Polls of MGC
>
>
> Terry L Anderson wrote:
> >
> > (resending since my original seems not to have made it to the list)
> >
> > MGC/MG relationship is indeed master/slave but
> registrations are only
> > initiated
> > from the MG end, so MGC being aware of loss of connectivity or an
> > alternate MGC
> > being aware that the primary is down does not allow
> reconnection to the
> > alternate - only the MG can take action to register with
> the alternate
> > (as in
> > 11.5).
>
> Again, it seems much cleaner to fix this problem by changing
> "registrations are only initiated from the MG end" statement.
> Why are MGC initiated regstrations considered so evil?
>
> -troy
>
> > So it seems to me most important that MG detect failures (as it
> > is the
> > only one that can take action).  Its the MGC that can do
> little when it
> > detects
> > a failure.
> > MGC perhaps should make the decision as to whether failures
> should be
> > detected
> > and frequency of polling but it seems to me that MG should do the
> > polling.
> >
> > For failures of a TCP link or MGC failure and recovery
> without loss of
> > state,
> > MGC may reestablish communications with a re-registration,
> but I don't
> > understand how an alternate MGC can take over after a
> primary failure
> > without MG
> >
> > detecting the failure.
> >
> > I did not think that an MG normally sent Add, Move,
> Subtract.  I believe
> > that
> > the only MG initiated transactions commonly used are Notify and
> > ServiceChange.
> > Thus during a quiet period (edge GW with SS7/ISUP
> signaling, no active
> > calls),
> > there would be no active events and so no reason to send
> either Notify
> > or
> > ServiceChange and so GW would be unaware that:
> > 1. MGC has gone down
> > 2. network has lost connectivity to MGC
> >
> > In either case, without polling, MG would be unaware.  Yet
> registering
> > with
> > alternateMGC might allow it to handle calls.
> >
> > I thought that the previously discussed methods for MGC and for MG
> > polling were
> > adequate but if we want to add a new mechanism, one could
> allow complete
> > control
> >
> > from MGC end by adding a "timer" event through a package.  MGC could
> > activate
> > the timer event on say root termination and this would
> cause a notify
> > after the
> > MGC specified period.  MGC would detect failure by lack of
> this notify.
> > MG
> > would detect failure when the Notify received no reply.  MGC thus
> > decides
> > whether polling should occur, what period to use and there is only
> > polling
> > traffic in one direction but both ends detect failure.  It would be
> > improved if
> > the package specified that the timer was automatically reset by any
> > messages, so
> >
> > it would fire only when no messages had been exchanged for
> the specified
> > time
> > (MGC would still detect failure by absense of any message
> for greater
> > than the
> > timer period, MG detect by failed reply).
> >
> > Christian Groves wrote:
> >
> > > G'Day Troy et all,
> > >
> > > Sorry for the late support of No Polling. I still have not seen a
> > > definitive reason that the MG needs to poll the MGC. We
> have defined a
> >
> > > master slave protocol with the MGC as the master. The MGC
> should be in
> >
> > > control of error situations.
> > >
> > > I believe that it's enough that the MG can detect that the MGC has
> > gone
> > > down when it try to signal using any appropriate H.248
> Commands ie.
> > > Add, Move, sub replies, Notify request, Service Change
> etc. Lack of
> > > timely response will indicate failure. The MG can then re-register
> > based
> > > on this.
> > >
> > > If you look at the common MG use cases:
> > > 1. The MG is a trunking gateway. In this scenario enough
> traffic will
> > be
> > > generated to maintain a reasonable flow of signalling to
> minimise the
> > > time to detect errors. For a proper Telco solution you should also
> > have
> > > enough management systems/redundency to know what MGC to
> hand over to.
> >
> > >
> > > 2. The MG is a residential gateway. Signalling traffic is not that
> > great
> > > but interaction is only needed with the MGC when the end-user does
> > > something. Therefore the MG will find out about the
> failure at this
> > > time. Why generate unessary signalling across limited BW links?
> > There's
> > > the avalanche problems mentioned earlier but more
> importantly someone
> > > will have to pay for bandwidth this signalling takes
> which basically
> > > serves no purpose.
> > > Again in this scenario the MGC will hopefully be owned by
> someone who
> > > wants to offer a decent service and has the necessary management
> > > systems/reduncy. I do not envisage MG registration will
> take very long
> >
> > > on a small residential gateway. Its a ServiceChange
> request/response
> > > round trip.
> > >
> > > What ever the proposed package, service change
> reason/method, protocol
> >
> > > update polling is unecessary.
> > >
> > > Cheers, Christian
> > >
> > > Troy Cauble wrote:
> > > >
> > > > Dave Sclarsky wrote:
> > > > >
> > > > > Troy,
> > > > >
> > > > > It doesn't matter what the new (or restarted) MGC
> knows or doesn't
> > know.
> > > > > Megaco defines that the control association between
> MG and MGC is
> > ALWAYS
> > > > > initiated by the MG.
> > > >
> > > > Then this definition is the problem and should be revisited.
> > > >
> > > > Polling is bad.
> > > >
> > > > -troy
> > > >
> > > > > Given that definition, Johnny's Dad's MG won't be
> > > > > reachable by a new (or a restarted) MGC until the his
> MG notices
> > the
> > > > > failure.  We must define a way for it to know ASAP!
> >
> > --
> > -------------------------------------------------------
> > Terry L Anderson, DMTS                   tla@lucent.com
> > Lucent Technologies /INS/ Voice over IP Access Networks
> > Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
> > Voice:908 582-7013  FAX:908 582-6729
> > http://its.lucent.com/~tla  (Lucent internal)
> > http://www.gti.net/tla
> > -------------------------------------------------------
>



From owner-megaco@fore.com  Thu May 24 11:22:37 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15309
	for ; Thu, 24 May 2001 11:22:36 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA05279;
	Thu, 24 May 2001 11:10:53 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA23624
	for megaco-list; Thu, 24 May 2001 11:09:42 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23617
	for ; Thu, 24 May 2001 11:09:41 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 24 May 2001 11:08:59 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF04465451@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Madhu Babu Brahmanapally'" ,
        "'Troy Cauble'"
	 ,
        "'Terry L Anderson'" 
Cc: megaco@fore.com
Subject: RE: Polls of MGC
Date: Thu, 24 May 2001 11:09:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

There is a pretty fundamental difference between
	"Will you help me?"
and
	"I'm your new master"

We believed that the common case would be many slave MGs with limited
resources and fewer, more powerful MGCs.  In that environment,
making the MG the client and the MGC the server, authentication is
done by the server against the client, and not vice versa.

The whole protocol is based on this approach, and it is pretty uniform
about it.  If you allow it to change, for example as Troy suggests, breaks a
couple of things.  The most significant is TCP.  The protocol always
defines the MG as starting the connection.  This means the MG is
a TCP client, and never a TCP server.  If you allow the MGC to start
the association, then the MG would have to be a TCP server.  This is
not a good idea for small MGs.  It also breaks a set of simplifying
assumptions MGs can make about ServiceChange, and also about creating
security associations in IPSEC.

Brian

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Thursday, May 24, 2001 10:53 AM
> To: 'Rosen, Brian'; 'Troy Cauble'; 'Terry L Anderson'
> Cc: megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> Hi Brian/all,
> A Novice doubt. If the MG can say to MGC that "I'm your slave...please
> control me", why not the MGC can say "I'm your new master". I 
> think both MG
> and MGC will know each other by pre-provisioning. Else any MG 
> can register
> to any MGC and any MGC can control any MG.
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> Sent: Thursday, May 24, 2001 10:17 AM
> To: 'Troy Cauble'; Terry L Anderson
> Cc: megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> Security implications.
> "Hello, I'm your new master. Don't worry, everything will be 
> all right"
> 
> Brian
> 
> > -----Original Message-----
> > From: Troy Cauble [mailto:troy@lucent.com]
> > Sent: Thursday, May 24, 2001 9:57 AM
> > To: Terry L Anderson
> > Cc: megaco@fore.com
> > Subject: Re: Polls of MGC
> >
> >
> > Terry L Anderson wrote:
> > >
> > > (resending since my original seems not to have made it to 
> the list)
> > >
> > > MGC/MG relationship is indeed master/slave but
> > registrations are only
> > > initiated
> > > from the MG end, so MGC being aware of loss of connectivity or an
> > > alternate MGC
> > > being aware that the primary is down does not allow
> > reconnection to the
> > > alternate - only the MG can take action to register with
> > the alternate
> > > (as in
> > > 11.5).
> >
> > Again, it seems much cleaner to fix this problem by changing
> > "registrations are only initiated from the MG end" statement.
> > Why are MGC initiated regstrations considered so evil?
> >
> > -troy
> >
> > > So it seems to me most important that MG detect failures (as it
> > > is the
> > > only one that can take action).  Its the MGC that can do
> > little when it
> > > detects
> > > a failure.
> > > MGC perhaps should make the decision as to whether failures
> > should be
> > > detected
> > > and frequency of polling but it seems to me that MG should do the
> > > polling.
> > >
> > > For failures of a TCP link or MGC failure and recovery
> > without loss of
> > > state,
> > > MGC may reestablish communications with a re-registration,
> > but I don't
> > > understand how an alternate MGC can take over after a
> > primary failure
> > > without MG
> > >
> > > detecting the failure.
> > >
> > > I did not think that an MG normally sent Add, Move,
> > Subtract.  I believe
> > > that
> > > the only MG initiated transactions commonly used are Notify and
> > > ServiceChange.
> > > Thus during a quiet period (edge GW with SS7/ISUP
> > signaling, no active
> > > calls),
> > > there would be no active events and so no reason to send
> > either Notify
> > > or
> > > ServiceChange and so GW would be unaware that:
> > > 1. MGC has gone down
> > > 2. network has lost connectivity to MGC
> > >
> > > In either case, without polling, MG would be unaware.  Yet
> > registering
> > > with
> > > alternateMGC might allow it to handle calls.
> > >
> > > I thought that the previously discussed methods for MGC and for MG
> > > polling were
> > > adequate but if we want to add a new mechanism, one could
> > allow complete
> > > control
> > >
> > > from MGC end by adding a "timer" event through a package. 
>  MGC could
> > > activate
> > > the timer event on say root termination and this would
> > cause a notify
> > > after the
> > > MGC specified period.  MGC would detect failure by lack of
> > this notify.
> > > MG
> > > would detect failure when the Notify received no reply.  MGC thus
> > > decides
> > > whether polling should occur, what period to use and there is only
> > > polling
> > > traffic in one direction but both ends detect failure.  
> It would be
> > > improved if
> > > the package specified that the timer was automatically 
> reset by any
> > > messages, so
> > >
> > > it would fire only when no messages had been exchanged for
> > the specified
> > > time
> > > (MGC would still detect failure by absense of any message
> > for greater
> > > than the
> > > timer period, MG detect by failed reply).
> > >
> > > Christian Groves wrote:
> > >
> > > > G'Day Troy et all,
> > > >
> > > > Sorry for the late support of No Polling. I still have 
> not seen a
> > > > definitive reason that the MG needs to poll the MGC. We
> > have defined a
> > >
> > > > master slave protocol with the MGC as the master. The MGC
> > should be in
> > >
> > > > control of error situations.
> > > >
> > > > I believe that it's enough that the MG can detect that 
> the MGC has
> > > gone
> > > > down when it try to signal using any appropriate H.248
> > Commands ie.
> > > > Add, Move, sub replies, Notify request, Service Change
> > etc. Lack of
> > > > timely response will indicate failure. The MG can then 
> re-register
> > > based
> > > > on this.
> > > >
> > > > If you look at the common MG use cases:
> > > > 1. The MG is a trunking gateway. In this scenario enough
> > traffic will
> > > be
> > > > generated to maintain a reasonable flow of signalling to
> > minimise the
> > > > time to detect errors. For a proper Telco solution you 
> should also
> > > have
> > > > enough management systems/redundency to know what MGC to
> > hand over to.
> > >
> > > >
> > > > 2. The MG is a residential gateway. Signalling traffic 
> is not that
> > > great
> > > > but interaction is only needed with the MGC when the 
> end-user does
> > > > something. Therefore the MG will find out about the
> > failure at this
> > > > time. Why generate unessary signalling across limited BW links?
> > > There's
> > > > the avalanche problems mentioned earlier but more
> > importantly someone
> > > > will have to pay for bandwidth this signalling takes
> > which basically
> > > > serves no purpose.
> > > > Again in this scenario the MGC will hopefully be owned by
> > someone who
> > > > wants to offer a decent service and has the necessary management
> > > > systems/reduncy. I do not envisage MG registration will
> > take very long
> > >
> > > > on a small residential gateway. Its a ServiceChange
> > request/response
> > > > round trip.
> > > >
> > > > What ever the proposed package, service change
> > reason/method, protocol
> > >
> > > > update polling is unecessary.
> > > >
> > > > Cheers, Christian
> > > >
> > > > Troy Cauble wrote:
> > > > >
> > > > > Dave Sclarsky wrote:
> > > > > >
> > > > > > Troy,
> > > > > >
> > > > > > It doesn't matter what the new (or restarted) MGC
> > knows or doesn't
> > > know.
> > > > > > Megaco defines that the control association between
> > MG and MGC is
> > > ALWAYS
> > > > > > initiated by the MG.
> > > > >
> > > > > Then this definition is the problem and should be revisited.
> > > > >
> > > > > Polling is bad.
> > > > >
> > > > > -troy
> > > > >
> > > > > > Given that definition, Johnny's Dad's MG won't be
> > > > > > reachable by a new (or a restarted) MGC until the his
> > MG notices
> > > the
> > > > > > failure.  We must define a way for it to know ASAP!
> > >
> > > --
> > > -------------------------------------------------------
> > > Terry L Anderson, DMTS                   tla@lucent.com
> > > Lucent Technologies /INS/ Voice over IP Access Networks
> > > Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
> > > Voice:908 582-7013  FAX:908 582-6729
> > > http://its.lucent.com/~tla  (Lucent internal)
> > > http://www.gti.net/tla
> > > -------------------------------------------------------
> >
> 


From owner-megaco@fore.com  Thu May 24 12:35:31 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16793
	for ; Thu, 24 May 2001 12:35:30 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA11538;
	Thu, 24 May 2001 12:25:14 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA12424
	for megaco-list; Thu, 24 May 2001 12:21:43 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA12407
	for ; Thu, 24 May 2001 12:21:39 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA11184
	for ; Thu, 24 May 2001 12:21:36 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1])
	by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4OGLYf14173
	for ; Thu, 24 May 2001 12:21:34 -0400 (EDT)
Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2])
	by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4OGLYW14165;
	Thu, 24 May 2001 12:21:34 -0400 (EDT)
Received: from lucent.com (pctla [135.3.130.39])
	by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id MAA10162;
	Thu, 24 May 2001 12:21:32 -0400 (EDT)
Message-ID: <3B0D35C0.B43BA7F8@lucent.com>
Date: Thu, 24 May 2001 12:24:32 -0400
From: Terry L Anderson 
Organization: Lucent Technologies
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Groves 
CC: megaco@fore.com
Subject: Re: Polls of MGC
References: <0D5BBF5D638DD4119E3400508BD94945811131@RADVPOST> <3B0CD7B7.2471186C@ericsson.com>
Content-Type: multipart/mixed;
 boundary="------------8B3A3A86476AB7F04637997A"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.
--------------8B3A3A86476AB7F04637997A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

But Christian,

I agree that a recovered-after-failed MGC should be able to reestablish
communications (should have fault-tolerant state info), but you are ignoring the
case of a failed MGC where an alternate MGC might take over.  It might share
state with the failed MGC but CANNOT reestablish communications unless it assumes
the failed MGC's network address (then it is not really an alternate MGC - it is
part of a fault-tolerent MGC - probably a better idea but not the only choice
H.248 should support).

Even the case of altMGC taking over works for your ResGW case where GW is left
with an active event but for SS7 signaling where new calls are initiated at MGC
end and GW's have no active events when outside a call, recovery will never
occur.  So unless we believe there is no need to support altMGCs for recovery in
such systems, we need a way for MGs to become aware of primary MGC failure.

(we have customers insisting on this very feature)

Christian Groves wrote:

> G'Day Dan,
>
> I don't understand "the MGc can never contact the MG because it doesn't
> know where the MG is listening". The MGC should at least maintain the
> state of registered MGs. This problem is not unique to the "polling"
> situation described in 1 & 2. H248 clause 11.5 covers MGC failure.
>
> If a MG is registered with a certain MGC to accept incoming calls then
> its up to the operator of the MGC to provide an alternative in case of
> failure. 11.5 describes how the new MGC can use the same identity.
>
> On an outgoing call from the ResGW if it detects an MGC failure it can
> always choose and register with another MGC in its list.
>
> You could also use a reliable connection oriented transport and give
> UDP/ALF a miss and solve your problems.
>
> Christian
>
> Dan Elbert wrote:
> >
> > Hi
> > I think the scenario can be as following:
> > 1. The MGC fails without being able to send a "Handoff"
> > 2. Later on the MGC restarts or a backup MGC comes up
> > In this case the MGC can never contact the MG because it doesn't know where
> > the MG is listening.
> > So the problem stands if the MGC needs to contact the MG before the MG
> > becomes aware that the connection with the MGC has been lost.
> >
> > Dan
> >
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > Sent: Wednesday, May 23, 2001 10:37 AM
> > To: 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
> > Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> > Subject: RE: Polls of MGC
> >
> > HI Dave,
> > If the MG is connected to the "broken" MGC how can it receive commands from
> > two MGC's. The MG should reinitiate the registration for accepting messages
> > from the new MGC.
> >
> > Regards
> > Madhubabu
> >
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dave Sclarsky
> > Sent: Wednesday, May 23, 2001 10:23 AM
> > To: 'Christian Groves'; Troy Cauble
> > Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com'; megaco@fore.com
> > Subject: RE: Polls of MGC
> >
> > Christian,
> > What happens when the MGC wants to ring a phone on an MG that is a ResGW,
> > but that MG still thinks tbat it is connected to a 'broken' MGC?
> > DaveS.
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > > Sent: Wednesday, May 23, 2001 9:48 AM
> > > To: Troy Cauble
> > > Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
> > > megaco@fore.com
> > > Subject: Re: Polls of MGC
> > >
> > >
> > > G'Day Troy et all,
> > >
> > > Sorry for the late support of No Polling. I still have not seen a
> > > definitive reason that the MG needs to poll the MGC. We have defined a
> > > master slave protocol with the MGC as the master. The MGC should be in
> > > control of error situations.
> > >
> > > I believe that it's enough that the MG can detect that the
> > > MGC has gone
> > > down when it try to signal using any appropriate H.248 Commands ie.
> > > Add, Move, sub replies, Notify request, Service Change etc. Lack of
> > > timely response will indicate failure. The MG can then
> > > re-register based
> > > on this.
> > >
> > > If you look at the common MG use cases:
> > > 1. The MG is a trunking gateway. In this scenario enough
> > > traffic will be
> > > generated to maintain a reasonable flow of signalling to minimise the
> > > time to detect errors. For a proper Telco solution you should
> > > also have
> > > enough management systems/redundency to know what MGC to hand over to.
> > >
> > > 2. The MG is a residential gateway. Signalling traffic is not
> > > that great
> > > but interaction is only needed with the MGC when the end-user does
> > > something. Therefore the MG will find out about the failure at this
> > > time. Why generate unessary signalling across limited BW
> > > links? There's
> > > the avalanche problems mentioned earlier but more importantly someone
> > > will have to pay for bandwidth this signalling takes which basically
> > > serves no purpose.
> > > Again in this scenario the MGC will hopefully be owned by someone who
> > > wants to offer a decent service and has the necessary management
> > > systems/reduncy. I do not envisage MG registration will take very long
> > > on a small residential gateway. Its a ServiceChange request/response
> > > round trip.
> > >
> > > What ever the proposed package, service change reason/method, protocol
> > > update polling is unecessary.
> > >
> > > Cheers, Christian
> > >
> > > Troy Cauble wrote:
> > > >
> > > > Dave Sclarsky wrote:
> > > > >
> > > > > Troy,
> > > > >
> > > > > It doesn't matter what the new (or restarted) MGC knows
> > > or doesn't know.
> > > > > Megaco defines that the control association between MG
> > > and MGC is ALWAYS
> > > > > initiated by the MG.
> > > >
> > > > Then this definition is the problem and should be revisited.
> > > >
> > > > Polling is bad.
> > > >
> > > > -troy
> > > >
> > > > > Given that definition, Johnny's Dad's MG won't be
> > > > > reachable by a new (or a restarted) MGC until the his MG
> > > notices the
> > > > > failure.  We must define a way for it to know ASAP!
> > >

--
------------------------------------------------------------
Terry L Anderson              mailto:tla@lucent.com
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla


--------------8B3A3A86476AB7F04637997A
Content-Type: text/x-vcard; charset=us-ascii;
 name="tla.vcf"
Content-Description: Card for Terry L Anderson
Content-Disposition: attachment;
 filename="tla.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Anderson;Terry L
tel;fax:908.582.6729
tel;work:908.582.7013
x-mozilla-html:TRUE
url:http://its.lucent.com/~tla
org:Lucent / InterNetworking Systems;VoIP Access Networks
version:2.1
email;internet:tla@lucent.com
title:DMTS
note:http://www.gti.net/tla  or http://teton.mh.lucent.com/~tla (Lucent internal)
adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA
x-mozilla-cpt:;21296
fn:Terry L Anderson
end:vcard

--------------8B3A3A86476AB7F04637997A--



From owner-megaco@fore.com  Thu May 24 13:18:43 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17575
	for ; Thu, 24 May 2001 13:18:42 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA15192;
	Thu, 24 May 2001 13:11:15 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA23016
	for megaco-list; Thu, 24 May 2001 13:10:22 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA22998
	for ; Thu, 24 May 2001 13:10:02 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA14995
	for ; Thu, 24 May 2001 13:09:58 -0400 (EDT)
Received: from lnicolas-u5.cisco.com (lnicolas-u5.cisco.com [64.102.38.16])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4OHA0904534;
	Thu, 24 May 2001 10:10:00 -0700 (PDT)
Date: Thu, 24 May 2001 13:09:56 -0400 (EDT)
From: Laurent Nicolas 
To: Dan Elbert 
cc: "'Christian Groves'" , 
Subject: RE: Polls of MGC
In-Reply-To: <0D5BBF5D638DD4119E3400508BD9494581113C@RADVPOST>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Dan, the point is that for TCP or UDP we have a client/server model.
The MGC is the server, and stays in listen mode, waiting for clients to
initiate connections.  It is better to have the server on the MGC because
a server is more complex.
The MG then acts as a client and is supposed to initiate the TCP or UDP
connection with a MGC.

For TCP, liveness (or poll) is part of the protocol.  So if connectivity
is lost, the TCP client will detect it, and the MG can then try to
reestablish the connection with the same MGC or an alternate MGC.

For UDP, there is no liveness, so the application must take care of it if
required.  A way to achieve it (as already said), is for the MG to start
an inactivity timer when it receives something from the MGC.  If the MGC
is regularly polling the MG, then the MG will rearm this timer and has
nothing to do.  If the MG does not hear from the MGC, it can then initiate
a recovery procedure.

cheers, Laurent

On Thu, 24 May 2001, Dan Elbert wrote:

> Hi Christian
> I was referring to the case were there is no redundancy or redundancy fails.
> I was trying to see what is the minimal level of support that the protocol
> has to provide. I think that you can have the same problem in TCP, i.e., the
> connection was broken but you didn't detect it until trying to send a
> Notify.
> As other people pointed, one of the problems of waiting for the MG to send a
> Notify to reconnect is when another party try to contact the disconnected
> MG, and other problem is with specific MG's that will never generate
> Notifies.
> A final point that I'd like to make is that probably this issues will be
> less important when we have very reliable MGCs, but they are very useful for
> the development phase. That's why having some kind of parameter configurable
> by the MGC will be very useful.
>
> Dan
>
> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Thursday, May 24, 2001 5:43 AM
> To: Dan Elbert
> Cc: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; 'Troy Cauble'; 'Rosen,
> Brian'; knayar@hss.hns.com; megaco@fore.com
> Subject: Re: Polls of MGC
>
> G'Day Dan,
>
> I don't understand "the MGc can never contact the MG because it doesn't
> know where the MG is listening". The MGC should at least maintain the
> state of registered MGs. This problem is not unique to the "polling"
> situation described in 1 & 2. H248 clause 11.5 covers MGC failure.
>
> If a MG is registered with a certain MGC to accept incoming calls then
> its up to the operator of the MGC to provide an alternative in case of
> failure. 11.5 describes how the new MGC can use the same identity.
>
> On an outgoing call from the ResGW if it detects an MGC failure it can
> always choose and register with another MGC in its list.
>
> You could also use a reliable connection oriented transport and give
> UDP/ALF a miss and solve your problems.
>
> Christian
>
> Dan Elbert wrote:
> >
> > Hi
> > I think the scenario can be as following:
> > 1. The MGC fails without being able to send a "Handoff"
> > 2. Later on the MGC restarts or a backup MGC comes up
> > In this case the MGC can never contact the MG because it doesn't know
> where
> > the MG is listening.
> > So the problem stands if the MGC needs to contact the MG before the MG
> > becomes aware that the connection with the MGC has been lost.
> >
> > Dan
> >
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > Sent: Wednesday, May 23, 2001 10:37 AM
> > To: 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
> > Cc: 'Rosen, Brian'; knayar@hss.hns.com; megaco@fore.com
> > Subject: RE: Polls of MGC
> >
> > HI Dave,
> > If the MG is connected to the "broken" MGC how can it receive commands
> from
> > two MGC's. The MG should reinitiate the registration for accepting
> messages
> > from the new MGC.
> >
> > Regards
> > Madhubabu
> >
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Dave Sclarsky
> > Sent: Wednesday, May 23, 2001 10:23 AM
> > To: 'Christian Groves'; Troy Cauble
> > Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com'; megaco@fore.com
> > Subject: RE: Polls of MGC
> >
> > Christian,
> > What happens when the MGC wants to ring a phone on an MG that is a ResGW,
> > but that MG still thinks tbat it is connected to a 'broken' MGC?
> > DaveS.
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > > Sent: Wednesday, May 23, 2001 9:48 AM
> > > To: Troy Cauble
> > > Cc: Dave Sclarsky; 'Rosen, Brian'; 'knayar@hss.hns.com';
> > > megaco@fore.com
> > > Subject: Re: Polls of MGC
> > >
> > >
> > > G'Day Troy et all,
> > >
> > > Sorry for the late support of No Polling. I still have not seen a
> > > definitive reason that the MG needs to poll the MGC. We have defined a
> > > master slave protocol with the MGC as the master. The MGC should be in
> > > control of error situations.
> > >
> > > I believe that it's enough that the MG can detect that the
> > > MGC has gone
> > > down when it try to signal using any appropriate H.248 Commands ie.
> > > Add, Move, sub replies, Notify request, Service Change etc. Lack of
> > > timely response will indicate failure. The MG can then
> > > re-register based
> > > on this.
> > >
> > > If you look at the common MG use cases:
> > > 1. The MG is a trunking gateway. In this scenario enough
> > > traffic will be
> > > generated to maintain a reasonable flow of signalling to minimise the
> > > time to detect errors. For a proper Telco solution you should
> > > also have
> > > enough management systems/redundency to know what MGC to hand over to.
> > >
> > > 2. The MG is a residential gateway. Signalling traffic is not
> > > that great
> > > but interaction is only needed with the MGC when the end-user does
> > > something. Therefore the MG will find out about the failure at this
> > > time. Why generate unessary signalling across limited BW
> > > links? There's
> > > the avalanche problems mentioned earlier but more importantly someone
> > > will have to pay for bandwidth this signalling takes which basically
> > > serves no purpose.
> > > Again in this scenario the MGC will hopefully be owned by someone who
> > > wants to offer a decent service and has the necessary management
> > > systems/reduncy. I do not envisage MG registration will take very long
> > > on a small residential gateway. Its a ServiceChange request/response
> > > round trip.
> > >
> > > What ever the proposed package, service change reason/method, protocol
> > > update polling is unecessary.
> > >
> > > Cheers, Christian
> > >
> > > Troy Cauble wrote:
> > > >
> > > > Dave Sclarsky wrote:
> > > > >
> > > > > Troy,
> > > > >
> > > > > It doesn't matter what the new (or restarted) MGC knows
> > > or doesn't know.
> > > > > Megaco defines that the control association between MG
> > > and MGC is ALWAYS
> > > > > initiated by the MG.
> > > >
> > > > Then this definition is the problem and should be revisited.
> > > >
> > > > Polling is bad.
> > > >
> > > > -troy
> > > >
> > > > > Given that definition, Johnny's Dad's MG won't be
> > > > > reachable by a new (or a restarted) MGC until the his MG
> > > notices the
> > > > > failure.  We must define a way for it to know ASAP!
> > >
>



From owner-megaco@fore.com  Thu May 24 14:05:49 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18249
	for ; Thu, 24 May 2001 14:05:49 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA18993;
	Thu, 24 May 2001 13:52:29 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA04456
	for megaco-list; Thu, 24 May 2001 13:50:54 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04448
	for ; Thu, 24 May 2001 13:50:52 -0400 (EDT)
Received: from rumor.cps.intel.com (rumor.cps.intel.com [192.102.198.242])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA18721
	for ; Thu, 24 May 2001 13:50:48 -0400 (EDT)
Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205])
	by rumor.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.39 2001/05/18 00:47:02 root Exp $) with SMTP id RAA07982;
	Thu, 24 May 2001 17:50:12 GMT
Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Thu, 24 May 2001 17:50:14 0000 (GMT)
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 24 May 2001 10:50:12 -0700
Message-ID: 
From: "Kaul, Bharat" 
To: "'Laurent Nicolas'" ,
        Dan Elbert
	 
Cc: "'Christian Groves'" , megaco@fore.com
Subject: RE: Polls of MGC
Date: Thu, 24 May 2001 10:49:26 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


>For TCP, liveness (or poll) is part of the protocol.  So if connectivity
>is lost, the TCP client will detect it, and the MG can then try to
>reestablish the connection with the same MGC or an alternate MGC.

Currently what is a MG supposed to do if it loses a TCP connection ? Does it
attempt to re-establish the connection to same MGC a finite number of times
and send ServiceChange with "disconnected" (??) or does it switch over to
the next configured MGC ?

Protocol doesn't seem to say anything and I wonder why. It should say
something about this issue.

- Bharat




From owner-megaco@fore.com  Thu May 24 14:24:59 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18619
	for ; Thu, 24 May 2001 14:24:58 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19520;
	Thu, 24 May 2001 13:57:01 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA05761
	for megaco-list; Thu, 24 May 2001 13:55:39 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05753
	for ; Thu, 24 May 2001 13:55:37 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 24 May 2001 13:54:56 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF0446545D@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Kaul, Bharat'" ,
        "'Laurent Nicolas'"
	 ,
        Dan Elbert 
Cc: "'Christian Groves'" , megaco@fore.com
Subject: RE: Polls of MGC
Date: Thu, 24 May 2001 13:55:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Since networks vary a lot, the number of times you should retry can
vary a lot, and that is why we don't specify how many times to try,
or how long to wait.

Some networks will not want MGs to wait; if connectivity is lost,
they will want MGs to switch to a new MGC right away.  Others will have
the MG retry for some number of times, supplying Disconnect if after
a few tries, the MGC eventually responds.

Brian

> -----Original Message-----
> From: Kaul, Bharat [mailto:bharat@trillium.com]
> Sent: Thursday, May 24, 2001 1:49 PM
> To: 'Laurent Nicolas'; Dan Elbert
> Cc: 'Christian Groves'; megaco@fore.com
> Subject: RE: Polls of MGC
> 
> 
> 
> >For TCP, liveness (or poll) is part of the protocol.  So if 
> connectivity
> >is lost, the TCP client will detect it, and the MG can then try to
> >reestablish the connection with the same MGC or an alternate MGC.
> 
> Currently what is a MG supposed to do if it loses a TCP 
> connection ? Does it
> attempt to re-establish the connection to same MGC a finite 
> number of times
> and send ServiceChange with "disconnected" (??) or does it 
> switch over to
> the next configured MGC ?
> 
> Protocol doesn't seem to say anything and I wonder why. It should say
> something about this issue.
> 
> - Bharat
> 
> 


From owner-megaco@fore.com  Thu May 24 15:19:13 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19403
	for ; Thu, 24 May 2001 15:19:13 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA23575;
	Thu, 24 May 2001 14:47:01 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA18658
	for megaco-list; Thu, 24 May 2001 14:46:04 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA18646
	for ; Thu, 24 May 2001 14:46:01 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA23394
	for ; Thu, 24 May 2001 14:45:57 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACV21863;
	Thu, 24 May 2001 14:45:50 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Troy Cauble'" ,
        "'Rosen, Brian'" 
Cc: 
Subject: RE: Polls of MGC
Date: Thu, 24 May 2001 14:49:23 -0400
Message-ID: <001701c0e482$40e7ac20$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <3B0D4C76.4CE91F0B@lucent.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

HI Troy,
Even if you interpret the message from the new MGC as "I'm sorry to inform
you that your old master is ill.
	 Please verify this and find yourself another."

The new MGC itself is not secure how can we expect any triggers from this
unknown MGC (if not the handoff/any other registration commands). At least
if you try to find whether the old master is still active...this again will
give chance for "ping of death attack".

Regards
Madhubabu


-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Troy Cauble
Sent: Thursday, May 24, 2001 2:01 PM
To: Rosen, Brian
Cc: megaco@fore.com
Subject: Re: Polls of MGC


"Rosen, Brian" wrote:
>
> There is a pretty fundamental difference between
>         "Will you help me?"
> and
>         "I'm your new master"
>

Yes there is, but it's mostly your aggressive phrasing.
How about:
	"I'm sorry to inform you that your old master is ill.
	 Please verify that I am an acceptable new master."
or even
	"I'm sorry to inform you that your old master is ill.
	 Please verify this and find yourself another."

As implied by the latter one, the MG could register with
whoever it wants.  This message would just be a notification.

In fact there probably already is a ServiceChange message
that would work well for that.  The only change is that
when it gets that message from other than it's master, it
verifies that it's master is unreachable.


> We believed that the common case would be many slave MGs with limited
> resources and fewer, more powerful MGCs.  In that environment,
> making the MG the client and the MGC the server, authentication is
> done by the server against the client, and not vice versa.
>
> The whole protocol is based on this approach, and it is pretty uniform
> about it.  If you allow it to change, for example as Troy suggests, breaks
a
> couple of things.  The most significant is TCP.  The protocol always
> defines the MG as starting the connection.  This means the MG is
> a TCP client, and never a TCP server.  If you allow the MGC to start
> the association, then the MG would have to be a TCP server.  This is
> not a good idea for small MGs.  It also breaks a set of simplifying
> assumptions MGs can make about ServiceChange, and also about creating
> security associations in IPSEC.

Yes, a TCP only MG would need to accept TCP connections.
I really don't think that's a burden.


-troy


>
> Brian
>
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > Sent: Thursday, May 24, 2001 10:53 AM
> > To: 'Rosen, Brian'; 'Troy Cauble'; 'Terry L Anderson'
> > Cc: megaco@fore.com
> > Subject: RE: Polls of MGC
> >
> >
> > Hi Brian/all,
> > A Novice doubt. If the MG can say to MGC that "I'm your slave...please
> > control me", why not the MGC can say "I'm your new master". I
> > think both MG
> > and MGC will know each other by pre-provisioning. Else any MG
> > can register
> > to any MGC and any MGC can control any MG.
> >
> > Regards
> > Madhubabu
> >
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> > Sent: Thursday, May 24, 2001 10:17 AM
> > To: 'Troy Cauble'; Terry L Anderson
> > Cc: megaco@fore.com
> > Subject: RE: Polls of MGC
> >
> >
> > Security implications.
> > "Hello, I'm your new master. Don't worry, everything will be
> > all right"
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Troy Cauble [mailto:troy@lucent.com]
> > > Sent: Thursday, May 24, 2001 9:57 AM
> > > To: Terry L Anderson
> > > Cc: megaco@fore.com
> > > Subject: Re: Polls of MGC
> > >
> > >
> > > Terry L Anderson wrote:
> > > >
> > > > (resending since my original seems not to have made it to
> > the list)
> > > >
> > > > MGC/MG relationship is indeed master/slave but
> > > registrations are only
> > > > initiated
> > > > from the MG end, so MGC being aware of loss of connectivity or an
> > > > alternate MGC
> > > > being aware that the primary is down does not allow
> > > reconnection to the
> > > > alternate - only the MG can take action to register with
> > > the alternate
> > > > (as in
> > > > 11.5).
> > >
> > > Again, it seems much cleaner to fix this problem by changing
> > > "registrations are only initiated from the MG end" statement.
> > > Why are MGC initiated regstrations considered so evil?
> > >
> > > -troy
> > >
> > > > So it seems to me most important that MG detect failures (as it
> > > > is the
> > > > only one that can take action).  Its the MGC that can do
> > > little when it
> > > > detects
> > > > a failure.
> > > > MGC perhaps should make the decision as to whether failures
> > > should be
> > > > detected
> > > > and frequency of polling but it seems to me that MG should do the
> > > > polling.
> > > >
> > > > For failures of a TCP link or MGC failure and recovery
> > > without loss of
> > > > state,
> > > > MGC may reestablish communications with a re-registration,
> > > but I don't
> > > > understand how an alternate MGC can take over after a
> > > primary failure
> > > > without MG
> > > >
> > > > detecting the failure.
> > > >
> > > > I did not think that an MG normally sent Add, Move,
> > > Subtract.  I believe
> > > > that
> > > > the only MG initiated transactions commonly used are Notify and
> > > > ServiceChange.
> > > > Thus during a quiet period (edge GW with SS7/ISUP
> > > signaling, no active
> > > > calls),
> > > > there would be no active events and so no reason to send
> > > either Notify
> > > > or
> > > > ServiceChange and so GW would be unaware that:
> > > > 1. MGC has gone down
> > > > 2. network has lost connectivity to MGC
> > > >
> > > > In either case, without polling, MG would be unaware.  Yet
> > > registering
> > > > with
> > > > alternateMGC might allow it to handle calls.
> > > >
> > > > I thought that the previously discussed methods for MGC and for MG
> > > > polling were
> > > > adequate but if we want to add a new mechanism, one could
> > > allow complete
> > > > control
> > > >
> > > > from MGC end by adding a "timer" event through a package.
> >  MGC could
> > > > activate
> > > > the timer event on say root termination and this would
> > > cause a notify
> > > > after the
> > > > MGC specified period.  MGC would detect failure by lack of
> > > this notify.
> > > > MG
> > > > would detect failure when the Notify received no reply.  MGC thus
> > > > decides
> > > > whether polling should occur, what period to use and there is only
> > > > polling
> > > > traffic in one direction but both ends detect failure.
> > It would be
> > > > improved if
> > > > the package specified that the timer was automatically
> > reset by any
> > > > messages, so
> > > >
> > > > it would fire only when no messages had been exchanged for
> > > the specified
> > > > time
> > > > (MGC would still detect failure by absense of any message
> > > for greater
> > > > than the
> > > > timer period, MG detect by failed reply).
> > > >
> > > > Christian Groves wrote:
> > > >
> > > > > G'Day Troy et all,
> > > > >
> > > > > Sorry for the late support of No Polling. I still have
> > not seen a
> > > > > definitive reason that the MG needs to poll the MGC. We
> > > have defined a
> > > >
> > > > > master slave protocol with the MGC as the master. The MGC
> > > should be in
> > > >
> > > > > control of error situations.
> > > > >
> > > > > I believe that it's enough that the MG can detect that
> > the MGC has
> > > > gone
> > > > > down when it try to signal using any appropriate H.248
> > > Commands ie.
> > > > > Add, Move, sub replies, Notify request, Service Change
> > > etc. Lack of
> > > > > timely response will indicate failure. The MG can then
> > re-register
> > > > based
> > > > > on this.
> > > > >
> > > > > If you look at the common MG use cases:
> > > > > 1. The MG is a trunking gateway. In this scenario enough
> > > traffic will
> > > > be
> > > > > generated to maintain a reasonable flow of signalling to
> > > minimise the
> > > > > time to detect errors. For a proper Telco solution you
> > should also
> > > > have
> > > > > enough management systems/redundency to know what MGC to
> > > hand over to.
> > > >
> > > > >
> > > > > 2. The MG is a residential gateway. Signalling traffic
> > is not that
> > > > great
> > > > > but interaction is only needed with the MGC when the
> > end-user does
> > > > > something. Therefore the MG will find out about the
> > > failure at this
> > > > > time. Why generate unessary signalling across limited BW links?
> > > > There's
> > > > > the avalanche problems mentioned earlier but more
> > > importantly someone
> > > > > will have to pay for bandwidth this signalling takes
> > > which basically
> > > > > serves no purpose.
> > > > > Again in this scenario the MGC will hopefully be owned by
> > > someone who
> > > > > wants to offer a decent service and has the necessary management
> > > > > systems/reduncy. I do not envisage MG registration will
> > > take very long
> > > >
> > > > > on a small residential gateway. Its a ServiceChange
> > > request/response
> > > > > round trip.
> > > > >
> > > > > What ever the proposed package, service change
> > > reason/method, protocol
> > > >
> > > > > update polling is unecessary.
> > > > >
> > > > > Cheers, Christian
> > > > >
> > > > > Troy Cauble wrote:
> > > > > >
> > > > > > Dave Sclarsky wrote:
> > > > > > >
> > > > > > > Troy,
> > > > > > >
> > > > > > > It doesn't matter what the new (or restarted) MGC
> > > knows or doesn't
> > > > know.
> > > > > > > Megaco defines that the control association between
> > > MG and MGC is
> > > > ALWAYS
> > > > > > > initiated by the MG.
> > > > > >
> > > > > > Then this definition is the problem and should be revisited.
> > > > > >
> > > > > > Polling is bad.
> > > > > >
> > > > > > -troy
> > > > > >
> > > > > > > Given that definition, Johnny's Dad's MG won't be
> > > > > > > reachable by a new (or a restarted) MGC until the his
> > > MG notices
> > > > the
> > > > > > > failure.  We must define a way for it to know ASAP!
> > > >
> > > > --
> > > > -------------------------------------------------------
> > > > Terry L Anderson, DMTS                   tla@lucent.com
> > > > Lucent Technologies /INS/ Voice over IP Access Networks
> > > > Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
> > > > Voice:908 582-7013  FAX:908 582-6729
> > > > http://its.lucent.com/~tla  (Lucent internal)
> > > > http://www.gti.net/tla
> > > > -------------------------------------------------------
> > >
> >



From owner-megaco@fore.com  Thu May 24 16:00:28 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20032
	for ; Thu, 24 May 2001 16:00:28 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA20279;
	Thu, 24 May 2001 14:04:36 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA07982
	for megaco-list; Thu, 24 May 2001 14:03:34 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA07971
	for ; Thu, 24 May 2001 14:03:33 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA20127
	for ; Thu, 24 May 2001 14:03:28 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4OI3T917257
	for ; Thu, 24 May 2001 14:03:29 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4OI3S717245
	for ; Thu, 24 May 2001 14:03:29 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id OAA00414; Thu, 24 May 2001 14:03:26 -0400 (EDT)
Cc: megaco@fore.com
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id OAA00401; Thu, 24 May 2001 14:03:25 -0400 (EDT)
Message-ID: <3B0D4C76.4CE91F0B@lucent.com>
Date: Thu, 24 May 2001 14:01:26 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" 
Original-CC: megaco@fore.com
Subject: Re: Polls of MGC
References: <4FBEA8857476D311A03300204840E1CF04465451@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Rosen, Brian" wrote:
> 
> There is a pretty fundamental difference between
>         "Will you help me?"
> and
>         "I'm your new master"
> 

Yes there is, but it's mostly your aggressive phrasing.
How about:
	"I'm sorry to inform you that your old master is ill.
	 Please verify that I am an acceptable new master."
or even
	"I'm sorry to inform you that your old master is ill.  
	 Please verify this and find yourself another."

As implied by the latter one, the MG could register with
whoever it wants.  This message would just be a notification.

In fact there probably already is a ServiceChange message
that would work well for that.  The only change is that
when it gets that message from other than it's master, it
verifies that it's master is unreachable.


> We believed that the common case would be many slave MGs with limited
> resources and fewer, more powerful MGCs.  In that environment,
> making the MG the client and the MGC the server, authentication is
> done by the server against the client, and not vice versa.
> 
> The whole protocol is based on this approach, and it is pretty uniform
> about it.  If you allow it to change, for example as Troy suggests, breaks a
> couple of things.  The most significant is TCP.  The protocol always
> defines the MG as starting the connection.  This means the MG is
> a TCP client, and never a TCP server.  If you allow the MGC to start
> the association, then the MG would have to be a TCP server.  This is
> not a good idea for small MGs.  It also breaks a set of simplifying
> assumptions MGs can make about ServiceChange, and also about creating
> security associations in IPSEC.

Yes, a TCP only MG would need to accept TCP connections.
I really don't think that's a burden.


-troy


> 
> Brian
> 
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > Sent: Thursday, May 24, 2001 10:53 AM
> > To: 'Rosen, Brian'; 'Troy Cauble'; 'Terry L Anderson'
> > Cc: megaco@fore.com
> > Subject: RE: Polls of MGC
> >
> >
> > Hi Brian/all,
> > A Novice doubt. If the MG can say to MGC that "I'm your slave...please
> > control me", why not the MGC can say "I'm your new master". I
> > think both MG
> > and MGC will know each other by pre-provisioning. Else any MG
> > can register
> > to any MGC and any MGC can control any MG.
> >
> > Regards
> > Madhubabu
> >
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> > Sent: Thursday, May 24, 2001 10:17 AM
> > To: 'Troy Cauble'; Terry L Anderson
> > Cc: megaco@fore.com
> > Subject: RE: Polls of MGC
> >
> >
> > Security implications.
> > "Hello, I'm your new master. Don't worry, everything will be
> > all right"
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Troy Cauble [mailto:troy@lucent.com]
> > > Sent: Thursday, May 24, 2001 9:57 AM
> > > To: Terry L Anderson
> > > Cc: megaco@fore.com
> > > Subject: Re: Polls of MGC
> > >
> > >
> > > Terry L Anderson wrote:
> > > >
> > > > (resending since my original seems not to have made it to
> > the list)
> > > >
> > > > MGC/MG relationship is indeed master/slave but
> > > registrations are only
> > > > initiated
> > > > from the MG end, so MGC being aware of loss of connectivity or an
> > > > alternate MGC
> > > > being aware that the primary is down does not allow
> > > reconnection to the
> > > > alternate - only the MG can take action to register with
> > > the alternate
> > > > (as in
> > > > 11.5).
> > >
> > > Again, it seems much cleaner to fix this problem by changing
> > > "registrations are only initiated from the MG end" statement.
> > > Why are MGC initiated regstrations considered so evil?
> > >
> > > -troy
> > >
> > > > So it seems to me most important that MG detect failures (as it
> > > > is the
> > > > only one that can take action).  Its the MGC that can do
> > > little when it
> > > > detects
> > > > a failure.
> > > > MGC perhaps should make the decision as to whether failures
> > > should be
> > > > detected
> > > > and frequency of polling but it seems to me that MG should do the
> > > > polling.
> > > >
> > > > For failures of a TCP link or MGC failure and recovery
> > > without loss of
> > > > state,
> > > > MGC may reestablish communications with a re-registration,
> > > but I don't
> > > > understand how an alternate MGC can take over after a
> > > primary failure
> > > > without MG
> > > >
> > > > detecting the failure.
> > > >
> > > > I did not think that an MG normally sent Add, Move,
> > > Subtract.  I believe
> > > > that
> > > > the only MG initiated transactions commonly used are Notify and
> > > > ServiceChange.
> > > > Thus during a quiet period (edge GW with SS7/ISUP
> > > signaling, no active
> > > > calls),
> > > > there would be no active events and so no reason to send
> > > either Notify
> > > > or
> > > > ServiceChange and so GW would be unaware that:
> > > > 1. MGC has gone down
> > > > 2. network has lost connectivity to MGC
> > > >
> > > > In either case, without polling, MG would be unaware.  Yet
> > > registering
> > > > with
> > > > alternateMGC might allow it to handle calls.
> > > >
> > > > I thought that the previously discussed methods for MGC and for MG
> > > > polling were
> > > > adequate but if we want to add a new mechanism, one could
> > > allow complete
> > > > control
> > > >
> > > > from MGC end by adding a "timer" event through a package.
> >  MGC could
> > > > activate
> > > > the timer event on say root termination and this would
> > > cause a notify
> > > > after the
> > > > MGC specified period.  MGC would detect failure by lack of
> > > this notify.
> > > > MG
> > > > would detect failure when the Notify received no reply.  MGC thus
> > > > decides
> > > > whether polling should occur, what period to use and there is only
> > > > polling
> > > > traffic in one direction but both ends detect failure.
> > It would be
> > > > improved if
> > > > the package specified that the timer was automatically
> > reset by any
> > > > messages, so
> > > >
> > > > it would fire only when no messages had been exchanged for
> > > the specified
> > > > time
> > > > (MGC would still detect failure by absense of any message
> > > for greater
> > > > than the
> > > > timer period, MG detect by failed reply).
> > > >
> > > > Christian Groves wrote:
> > > >
> > > > > G'Day Troy et all,
> > > > >
> > > > > Sorry for the late support of No Polling. I still have
> > not seen a
> > > > > definitive reason that the MG needs to poll the MGC. We
> > > have defined a
> > > >
> > > > > master slave protocol with the MGC as the master. The MGC
> > > should be in
> > > >
> > > > > control of error situations.
> > > > >
> > > > > I believe that it's enough that the MG can detect that
> > the MGC has
> > > > gone
> > > > > down when it try to signal using any appropriate H.248
> > > Commands ie.
> > > > > Add, Move, sub replies, Notify request, Service Change
> > > etc. Lack of
> > > > > timely response will indicate failure. The MG can then
> > re-register
> > > > based
> > > > > on this.
> > > > >
> > > > > If you look at the common MG use cases:
> > > > > 1. The MG is a trunking gateway. In this scenario enough
> > > traffic will
> > > > be
> > > > > generated to maintain a reasonable flow of signalling to
> > > minimise the
> > > > > time to detect errors. For a proper Telco solution you
> > should also
> > > > have
> > > > > enough management systems/redundency to know what MGC to
> > > hand over to.
> > > >
> > > > >
> > > > > 2. The MG is a residential gateway. Signalling traffic
> > is not that
> > > > great
> > > > > but interaction is only needed with the MGC when the
> > end-user does
> > > > > something. Therefore the MG will find out about the
> > > failure at this
> > > > > time. Why generate unessary signalling across limited BW links?
> > > > There's
> > > > > the avalanche problems mentioned earlier but more
> > > importantly someone
> > > > > will have to pay for bandwidth this signalling takes
> > > which basically
> > > > > serves no purpose.
> > > > > Again in this scenario the MGC will hopefully be owned by
> > > someone who
> > > > > wants to offer a decent service and has the necessary management
> > > > > systems/reduncy. I do not envisage MG registration will
> > > take very long
> > > >
> > > > > on a small residential gateway. Its a ServiceChange
> > > request/response
> > > > > round trip.
> > > > >
> > > > > What ever the proposed package, service change
> > > reason/method, protocol
> > > >
> > > > > update polling is unecessary.
> > > > >
> > > > > Cheers, Christian
> > > > >
> > > > > Troy Cauble wrote:
> > > > > >
> > > > > > Dave Sclarsky wrote:
> > > > > > >
> > > > > > > Troy,
> > > > > > >
> > > > > > > It doesn't matter what the new (or restarted) MGC
> > > knows or doesn't
> > > > know.
> > > > > > > Megaco defines that the control association between
> > > MG and MGC is
> > > > ALWAYS
> > > > > > > initiated by the MG.
> > > > > >
> > > > > > Then this definition is the problem and should be revisited.
> > > > > >
> > > > > > Polling is bad.
> > > > > >
> > > > > > -troy
> > > > > >
> > > > > > > Given that definition, Johnny's Dad's MG won't be
> > > > > > > reachable by a new (or a restarted) MGC until the his
> > > MG notices
> > > > the
> > > > > > > failure.  We must define a way for it to know ASAP!
> > > >
> > > > --
> > > > -------------------------------------------------------
> > > > Terry L Anderson, DMTS                   tla@lucent.com
> > > > Lucent Technologies /INS/ Voice over IP Access Networks
> > > > Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
> > > > Voice:908 582-7013  FAX:908 582-6729
> > > > http://its.lucent.com/~tla  (Lucent internal)
> > > > http://www.gti.net/tla
> > > > -------------------------------------------------------
> > >
> >


From owner-megaco@fore.com  Thu May 24 18:46:02 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22235
	for ; Thu, 24 May 2001 18:46:02 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA08059;
	Thu, 24 May 2001 18:38:36 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA07336
	for megaco-list; Thu, 24 May 2001 18:37:08 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA07329
	for ; Thu, 24 May 2001 18:37:07 -0400 (EDT)
Received: from ertpg15e1.nortelnetworks.com (ertpg15e1.nortelnetworks.com [47.234.0.36])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id SAA07941
	for ; Thu, 24 May 2001 18:37:03 -0400 (EDT)
Received: from ertpg14e1.nortelnetworks.com by ertpg15e1.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id SAA15415; Thu, 24 May 2001 18:37:05 -0400
Received: from zrtpd00y.us.nortel.com by ertpg14e1.nortelnetworks.com;
          Thu, 24 May 2001 18:36:57 -0400
Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 24 May 2001 18:36:59 -0400
Message-ID: <4FC0DB7A48D6D41193930000F81AC9BE64284E@zrtpd00x.us.nortel.com>
From: "Chris Rigano" 
To: megaco@fore.com
Subject: Megaco/H.248 Employment Opportunities
Date: Thu, 24 May 2001 18:36:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E4A2.072BA6B0"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E4A2.072BA6B0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Everyone,

Does anyone know of any Megaco/H.248 related employment opportunities in
RTP/NC?

Many thanks,

Chris

Christopher P. Rigano
UE-9000MG
ESN 351-7116
crigano@nortelnetworks.com


------_=_NextPart_001_01C0E4A2.072BA6B0
Content-Type: text/html;
	charset="iso-8859-1"






Megaco/H.248 Employment Opportunities




Hi Everyone,




Does anyone know of any Megaco/H.248 related employment opportunities in RTP/NC?




Many thanks,




Chris




Christopher P. Rigano

UE-9000MG

ESN 351-7116

crigano@nortelnetworks.com





------_=_NextPart_001_01C0E4A2.072BA6B0--


From owner-megaco@fore.com  Fri May 25 06:21:14 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14266
	for ; Fri, 25 May 2001 06:21:13 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA27798;
	Fri, 25 May 2001 06:15:27 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id GAA27982
	for megaco-list; Fri, 25 May 2001 06:13:44 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA27972
	for ; Fri, 25 May 2001 06:13:41 -0400 (EDT)
Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id GAA27664
	for ; Fri, 25 May 2001 06:13:38 -0400 (EDT)
Received: (qmail 16450 invoked by alias); 25 May 2001 10:13:38 -0000
Delivered-To: GMX delivery to claudia%carmendorn@gmx.de
Received: (qmail 16441 invoked by uid 0); 25 May 2001 10:13:38 -0000
Date: Fri, 25 May 2001 12:13:38 +0200 (MEST)
From: Carmen Dornbach 
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Authenticated-Sender: #0010896236@gmx.net
X-Authenticated-IP: [195.93.64.171]
Message-ID: <29063.990785618@www31.gmx.net>
X-Mailer: WWW-Mail 1.5 (Global Message Exchange)
Content-Type: text/plain; charset="iso-8859-1"
To: claudia%CarmenDorn@gmx.de
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id GAA27798
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA14266

Hallo,

wir sind 9 heiße und hemmungslose Girls, nämlich Babette, Moni, Carola,
Angelique, Michelle, Jessica, Melissa, Iris und Sandra, die ein geiles tabuloses
Telefonat, oder bei gefallen einen heißen Seitensprung suchen. Ganz wie Du
willst :o)

Erreichen kannst Du uns direkt unter Telefonnummer: 019085/4794*

Am Telefon können wir uns gleich ein Date ausmachen. Oder hast Du etwa keine
Lust auf einen wilden One Night Stand ? Wir schon :o) ... also beeil Dich
.... fg

Wenn Du uns vorher sehen möchtest, dann schau einfach mal auf unserer
Homepage vorbei ... dort erfährst Du einiges mehr über uns ... www.datingfon.de 

Unsere intimsten Geheimnisse verraten wir Dir natürlich nur direkt ... wir
können sie Dir ja am Telefon ins Ohr flüstern ... 

Also alles ist möglich weil wir auf alles Lust haben und noch so vieles
ausprobieren wollen .... hoffentlich mit Dir. ... 019085/4794*

Lass uns nicht so lange warten ....

Bussi bis gleich Deine süssen Girls








(* E.p. DM 3,63/min.)

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

--
U2 Konzertreisen inkl. VIP-Package
Hier Eventreisen zur U2-Tour bei Getgo.de online buchen!
http://www.getgo.de/cgi-bin/TDoc.dll?doc=reisen/rei_kon_sta&affiliate=GMX



From owner-megaco@fore.com  Fri May 25 06:44:27 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14402
	for ; Fri, 25 May 2001 06:44:27 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA28509;
	Fri, 25 May 2001 06:38:48 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id GAA00124
	for megaco-list; Fri, 25 May 2001 06:38:10 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA00120
	for ; Fri, 25 May 2001 06:38:08 -0400 (EDT)
From: akalra@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA28430
	for ; Fri, 25 May 2001 06:38:02 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4PAcn022015;
	Fri, 25 May 2001 16:08:50 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A57.0039026E ; Fri, 25 May 2001 15:52:41 +0530
X-Lotus-FromDomain: HSS
To: "Paul Long" 
cc: megaco@fore.com
Message-ID: <65256A57.0038FEAB.00@sandesh.hss.hns.com>
Date: Fri, 25 May 2001 16:07:00 +0530
Subject: RE: Clarification in RFC-3015 for domainAddress related to
	 IPV6address
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk



Paul,
     I looked into the RFC for IPV6-------------------- RFC-2373.

   2. Due to some methods of allocating certain styles of IPv6
      addresses, it will be common for addresses to contain long strings
      of zero bits.  In order to make writing addresses containing zero
      bits easier a special syntax is available to compress the zeros.
      The use of "::" indicates multiple groups of 16-bits of zeros.
      The "::" can only appear once in an address.  The "::" can also be
      used to compress the leading and/or trailing zeros in an address.

      For example the following addresses:

         1080:0:0:0:8:800:200C:417A  a unicast address
         FF01:0:0:0:0:0:0:101        a multicast address
         0:0:0:0:0:0:0:1             the loopback address
         0:0:0:0:0:0:0:0             the unspecified addresses

      may be represented as:

         1080::8:800:200C:417A       a unicast address
         FF01::101                   a multicast address
         ::1                         the loopback address
         ::                          the unspecified addresses

   3. An alternative form that is sometimes more convenient when dealing
      with a mixed environment of IPv4 and IPv6 nodes is
      x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
      the six high-order 16-bit pieces of the address, and the 'd's are
      the decimal values of the four low-order 8-bit pieces of the
      address (standard IPv4 representation).  Examples:

         0:0:0:0:0:0:13.1.68.3

         0:0:0:0:0:FFFF:129.144.52.38

      or in compressed form:

         ::13.1.68.3

         ::FFFF:129.144.52.38

So I guess the IPV6address that I suggested are all allowed.

tx
amit





"Paul Long"  on 05/23/2001 10:02:53 PM

To:   megaco@fore.com
cc:    (bcc: Amit Kalra/HSS)

Subject:  RE: Clarification in RFC-3015 for domainAddress related to IPV6address




Amit,

Yes, as far as I understand, these are all syntactically correct. I'm not
familiar enough with IPv6 to know whether those particular values make
sense, but they are at least constructed correctly.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: akalra@hss.hns.com [mailto:akalra@hss.hns.com]
Sent: Wednesday, May 23, 2001 3:57 AM
To: Paul Long
Cc: megaco@fore.com
Subject: RE: Clarification in RFC-3015 for domainAddress related to
IPV6address




Hi Paul,
     Thanks for the reply, can you provide some more clarification on:

The expansion of an IPV6address can be one of the following then.

      FFFF::
      FFFF::FFFF
      ::
      ::FFFF
      FFFF
      FFFF:::IPV4address
      FFFF::FFFF:IPV4address
      :::IPV4address
      ::FFFF:IPV4address
      FFFF:IPV4address


Going by the given expansion of hexpart and IPV6address rules in the grammar
in
RFC 3015.
Are all the above cases valid for an IPV6address?

regards/
Amit







From owner-megaco@fore.com  Fri May 25 09:42:05 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17912
	for ; Fri, 25 May 2001 09:42:04 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05541;
	Fri, 25 May 2001 09:24:53 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA21599
	for megaco-list; Fri, 25 May 2001 09:23:21 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA21588
	for ; Fri, 25 May 2001 09:23:20 -0400 (EDT)
Received: from telesoft.indts.com ([164.164.71.52])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05296
	for ; Fri, 25 May 2001 09:23:13 -0400 (EDT)
Received: from indts_fs.indts.com (indts_fs [201.64.64.29])
	by telesoft.indts.com (8.8.7/8.8.7) with ESMTP id TAA03276
	for ; Fri, 25 May 2001 19:14:28 +0530
Received: by INDTS_FS with Internet Mail Service (5.5.2650.21)
	id ; Fri, 25 May 2001 18:59:52 +0530
Message-ID: 
From: Sudhansu 
To: megaco@fore.com
Date: Fri, 25 May 2001 18:59:50 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hi all,
Can anybody pl answer the following qn:
Suppose MGC wants to know the set of packages and the events,properties etc
in those packages realized by a termination in MG.How does it know?
I think in AuditValue command , it can only know the packages supported but
not all the relevant informations about that package like set of events ,
properties etc in that package. 

thanks and regds,

 Sudhansu Sabut 
 s/w Engineer 
 Ind-Telesoft Pvt. Ltd 
 Email : ssabut@indts.com 
              



From owner-megaco@fore.com  Fri May 25 09:44:03 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17947
	for ; Fri, 25 May 2001 09:44:03 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA06164;
	Fri, 25 May 2001 09:29:56 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA23045
	for megaco-list; Fri, 25 May 2001 09:29:09 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA23020
	for ; Fri, 25 May 2001 09:28:43 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 25 May 2001 09:28:41 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF0446546A@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Sudhansu'" , megaco@fore.com
Subject: RE: 
Date: Fri, 25 May 2001 09:28:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

If you implement any part of a package, you must implement all of the
package to be compliant (no protocol police will catch you if you
don't however).  Therefore, all you need to know is the name of the
package; you can then assume all of the properties, events, signals
and statistics defined in that package are available to you.

Brian

> -----Original Message-----
> From: Sudhansu [mailto:ssabut@indts.com]
> Sent: Friday, May 25, 2001 9:30 AM
> To: megaco@fore.com
> Subject: 
> 
> 
> Hi all,
> Can anybody pl answer the following qn:
> Suppose MGC wants to know the set of packages and the 
> events,properties etc
> in those packages realized by a termination in MG.How does it know?
> I think in AuditValue command , it can only know the packages 
> supported but
> not all the relevant informations about that package like set 
> of events ,
> properties etc in that package. 
> 
> thanks and regds,
> 
>  Sudhansu Sabut 
>  s/w Engineer 
>  Ind-Telesoft Pvt. Ltd 
>  Email : ssabut@indts.com 
>               
> 


From owner-megaco@fore.com  Fri May 25 09:51:23 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18069
	for ; Fri, 25 May 2001 09:51:22 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA07368;
	Fri, 25 May 2001 09:41:52 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA26761
	for megaco-list; Fri, 25 May 2001 09:41:08 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA26750
	for ; Fri, 25 May 2001 09:41:06 -0400 (EDT)
Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA07223
	for ; Fri, 25 May 2001 09:41:02 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ACV27839;
	Fri, 25 May 2001 09:41:03 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: 
Subject: quality alert
Date: Fri, 25 May 2001 09:44:33 -0400
Message-ID: <005901c0e520$d555ad50$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,
In the Section E.11.2 for the "quality alert" event it is mentioned that a
provisioned method is used to calculate the threshold for percent of quality
loss taking into consideration packet loss/ jitter / delay etc. Is there any
standard based methods for calculating these thresholds?(For
pre-provisioning at MG)

Regards
Madhubabu



From owner-megaco@fore.com  Fri May 25 10:06:29 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18336
	for ; Fri, 25 May 2001 10:06:28 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA08510;
	Fri, 25 May 2001 09:53:36 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA00130
	for megaco-list; Fri, 25 May 2001 09:52:50 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA00100
	for ; Fri, 25 May 2001 09:52:34 -0400 (EDT)
Received: from ertpg15e1.nortelnetworks.com (ertpg15e1.nortelnetworks.com [47.234.0.36])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id JAA08307
	for ; Fri, 25 May 2001 09:52:30 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by ertpg15e1.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id JAA00562; Fri, 25 May 2001 09:52:31 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 25 May 2001 09:52:05 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 25 May 2001 09:52:10 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CBBC@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Atanu Mondal'" ,
        "'megaco@fore.com'" 
Cc: "'madhubabu@kenetec.com'" 
Subject: RE:
Date: Fri, 25 May 2001 09:52:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E521.E19C1D00"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E521.E19C1D00
Content-Type: text/plain;
	charset="ISO-8859-1"

The text of the specification has to be given some consideration in
evaluating the grammar.  Section 7.2.8 describes the circumstances under
which the various parameters are required.  That said, you'll also notice
another difference between the ABNF and ASN.1: the latter imposes an order
on the presentation of parameters.

> -----Original Message-----
> From: Atanu Mondal [mailto:ATANUM@netbrahma.com]
> Sent: Tuesday, May 22, 2001 3:21 AM
> To: 'megaco@fore.com'
> Cc: 'madhubabu@kenetec.com'
> Subject: 
> 
> 
> Dear List
> 
> The serviceChangeParm as described in ABNF spec is as below
> serviceChangeParm = (serviceChangeMethod
> /serviceChangeReason/serviceChangeDelay/serviceChangeAddress/s
> erviceChangePr
> ofile/extension/TimeStamp/serviceChangeMgcId/serviceChangeVersion )
>  which makes all the parameters a s optional.
> 
> In ASN syntax the serviceChangeParm is described as below
> 
> serviceChangeParm ::= SEQUENCE
> {
> 	serviceChangeMethod	ServiceChangeMethod,
> 	serviceChangeAddress	ServiceChangeAddress	OPTIONAL,
> 	serviceChangeVersion	INTEGER(0..99)		OPTIONAL,
> 	serviceChangeProfile	ServiceChangeProfile	OPTIONAL,
> 	serviceChangeReason	Value			
> 	serviceChangeDelay	INTEGER(0..4294967295) OPTIONAL,
> 	serviceChangeMgcId	MId 	OPTIONAL,
> 	timeStamp		TimeNotation	OPTIONAL,
> 	nonStandardData	NonStandardData	OPTIONAL,
> }
> 
> Which makes the ServiceChangeMethod as compulsory and the 
> rest optional.
> What is the reason for this decrepency between the two 
> version(ASN and ABNF)
> 
> If anybody can clarify the reason for this decrepency it will be very
> helpful
> Thanking in advance
> 
> Regards
> Atanu
> 

------_=_NextPart_001_01C0E521.E19C1D00
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: 




The text of the specification has to be given some =
consideration in evaluating the grammar.  Section 7.2.8 describes =
the circumstances under which the various parameters are =
required.  That said, you'll also notice another difference =
between the ABNF and ASN.1: the latter imposes an order on the =
presentation of parameters.



> -----Original Message-----

> From: Atanu Mondal [mailto:ATANUM@netbrahma.com]

> Sent: Tuesday, May 22, 2001 3:21 AM

> To: 'megaco@fore.com'

> Cc: 'madhubabu@kenetec.com'

> Subject: 

> 

> 

> Dear List

> 

> The serviceChangeParm as described in ABNF spec =
is as below

> serviceChangeParm =3D =
(serviceChangeMethod

> =
/serviceChangeReason/serviceChangeDelay/serviceChangeAddress/s

> erviceChangePr

> =
ofile/extension/TimeStamp/serviceChangeMgcId/serviceChangeVersion =
)

>  which makes all the parameters a s =
optional.

> 

> In ASN syntax the serviceChangeParm is =
described as below

> 

> serviceChangeParm ::=3D SEQUENCE

> {

>       =
serviceChangeMethod     ServiceChangeMethod,

>       =
serviceChangeAddress    =
ServiceChangeAddress    OPTIONAL,

>       =
serviceChangeVersion    INTEGER(0..99)  =
        OPTIONAL,

>       =
serviceChangeProfile    =
ServiceChangeProfile    OPTIONAL,

>       =
serviceChangeReason     Value   =
        =
        

>       =
serviceChangeDelay      INTEGER(0..4294967295) =
OPTIONAL,

>       =
serviceChangeMgcId      MId     =
OPTIONAL,

>       =
timeStamp       =
        =
TimeNotation    OPTIONAL,

>       nonStandardData =
NonStandardData OPTIONAL,

> }

> 

> Which makes the ServiceChangeMethod as =
compulsory and the 

> rest optional.

> What is the reason for this decrepency between =
the two 

> version(ASN and ABNF)

> 

> If anybody can clarify the reason for this =
decrepency it will be very

> helpful

> Thanking in advance

> 

> Regards

> Atanu

> 





------_=_NextPart_001_01C0E521.E19C1D00--


From owner-megaco@fore.com  Fri May 25 11:38:00 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19704
	for ; Fri, 25 May 2001 11:38:00 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA15781;
	Fri, 25 May 2001 11:29:36 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA23449
	for megaco-list; Fri, 25 May 2001 11:28:26 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23429
	for ; Fri, 25 May 2001 11:28:22 -0400 (EDT)
Received: from ties.itu.ch (ties.itu.ch [156.106.192.33])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA15650
	for ; Fri, 25 May 2001 11:28:18 -0400 (EDT)
Received: from ericsson.com ([156.106.209.254])
	by ties.itu.ch (8.9.3/8.9.3) with ESMTP id RAA06216
	for ; Fri, 25 May 2001 17:28:19 +0200 (MET DST)
Message-ID: <3B0E5EC2.8CFAE9A5@ericsson.com>
Date: Fri, 25 May 2001 23:31:46 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco ietf 
Subject: H.248 Related Documents for the Porto Seguro meeting
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day, 

The email below has the details of H.248 related documents going for
approval at SG16. It contains the latest Implementors' Guide, H.248
Annex L and the Congestion Package. There are other H.248 related
documents in the directory below.

Regards, Christian

-------- Original Message --------
Subject: Documents for the Porto Seguro meeting
Date: Thu, 24 May 2001 19:16:08 +0900
From: OKUBO Sakae 
Reply-To: okubo@mxz.mesh.ne.jp
To: ITU-SG16@mailbag.cps.INTEL.COM

Dear SG16 experts,

The following documents have been placed at



for your review:

Title: H.248 Implementors' Guide for approval (D130)
File: DC-xxx_H248_Implementors_Additions_v7.doc
Source: Editor

Title: H.248 Annex L for approval (D128)
File: DC-xxx_Annex_L.doc
Source: Editor

Title: H.248 Annex M.2 Congestion Package for approval (D131)
File: DC-xxx_Load_Control_package_v1.doc
Source: Editor

Title: Extendable Context Properties for H.248 v2
File: DC-xxx_Context_Property_v2.doc
Source: LM Ericsson
Note: ABNF will be added

Title: Handling of multiple pending transactions in H.248
File: TD-xxx_Transaction_Pending.doc
Source: LM Ericsson

Title: H.248v2
File: TD-xxx_H248_v2.doc
Source: Editor

Best regards,

OKUBO Sakae
*********************************************************
Global Information and Telecommunication Institute (GITI)
Waseda University
29-7 Waseda University Bldg.
1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo
169-0051 Japan
        e-mail: okubo@giti.waseda.ac.jp
        Tel: +81 3 3204 8194
        Fax: +81 3 5286 3832
*********************************************************

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@mailbag.intel.com



From owner-megaco@fore.com  Fri May 25 16:09:14 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24183
	for ; Fri, 25 May 2001 16:09:14 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA02650;
	Fri, 25 May 2001 15:43:42 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA15659
	for megaco-list; Fri, 25 May 2001 15:39:14 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA15655
	for ; Fri, 25 May 2001 15:39:12 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA02289
	for ; Fri, 25 May 2001 15:39:08 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4PJdAk10515
	for ; Fri, 25 May 2001 15:39:10 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4PJd9U10502
	for ; Fri, 25 May 2001 15:39:09 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA19771; Fri, 25 May 2001 15:39:07 -0400 (EDT)
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id PAA19767; Fri, 25 May 2001 15:39:04 -0400 (EDT)
Message-ID: <3B0EB460.60601D6E@lucent.com>
Date: Fri, 25 May 2001 15:37:04 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: MEGACO list 
Subject: Annex F, ftmd package question
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



F.5 says:

 ''This Package extends the possible values of tone id in the
 "start tone detected" event.''

Is limiting them to "std" the intent?  
Should these values be valid for "ltd" and "etd" too?

-troy


From owner-megaco@fore.com  Fri May 25 22:09:54 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29749
	for ; Fri, 25 May 2001 22:09:54 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA15855;
	Fri, 25 May 2001 22:02:43 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id WAA22018
	for megaco-list; Fri, 25 May 2001 22:01:00 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA22014
	for ; Fri, 25 May 2001 22:00:58 -0400 (EDT)
Received: from zrc2s03g.nortelnetworks.com ([47.103.122.66])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA15751
	for ; Fri, 25 May 2001 22:00:53 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zrc2s03g.nortelnetworks.com (8.9.3+Sun/8.9.1) with ESMTP id VAA27446
	for ; Fri, 25 May 2001 21:01:57 -0500 (CDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Fri, 25 May 2001 22:00:53 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 25 May 2001 22:00:57 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CBC8@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Troy Cauble'" , MEGACO list 
Subject: RE: Annex F, ftmd package question
Date: Fri, 25 May 2001 22:00:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E587.B24FBE10"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E587.B24FBE10
Content-Type: text/plain;
	charset="ISO-8859-1"

I expect so, on the principle of integrity of package support.

> -----Original Message-----
> From: Troy Cauble [mailto:troy@lucent.com]
> Sent: Friday, May 25, 2001 3:37 PM
> To: MEGACO list
> Subject: Annex F, ftmd package question
> 
> 
> 
> 
> F.5 says:
> 
>  ''This Package extends the possible values of tone id in the
>  "start tone detected" event.''
> 
> Is limiting them to "std" the intent?  
> Should these values be valid for "ltd" and "etd" too?
> 
> -troy
> 

------_=_NextPart_001_01C0E587.B24FBE10
Content-Type: text/html;
	charset="ISO-8859-1"






RE: Annex F, ftmd package question




I expect so, on the principle of integrity of package support.




> -----Original Message-----

> From: Troy Cauble [mailto:troy@lucent.com]

> Sent: Friday, May 25, 2001 3:37 PM

> To: MEGACO list

> Subject: Annex F, ftmd package question

> 

> 

> 

> 

> F.5 says:

> 

>  ''This Package extends the possible values of tone id in the

>  "start tone detected" event.''

> 

> Is limiting them to "std" the intent?  

> Should these values be valid for "ltd" and "etd" too?

> 

> -troy

> 





------_=_NextPart_001_01C0E587.B24FBE10--


From owner-megaco@fore.com  Sat May 26 02:08:24 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12605
	for ; Sat, 26 May 2001 02:08:24 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA19499;
	Sat, 26 May 2001 02:01:23 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA02717
	for megaco-list; Sat, 26 May 2001 01:58:33 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA02713
	for ; Sat, 26 May 2001 01:58:32 -0400 (EDT)
From: vibansal@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA19413
	for ; Sat, 26 May 2001 01:58:26 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4Q5xiY06762
	for ; Sat, 26 May 2001 11:29:44 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A58.001F74AA ; Sat, 26 May 2001 11:13:34 +0530
X-Lotus-FromDomain: HSS
To: megaco@fore.com
Message-ID: <65256A58.001F7391.00@sandesh.hss.hns.com>
Date: Sat, 26 May 2001 11:28:03 +0530
Subject: Timer Problem
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk




Hi

Section D.1.4 indicates

Upon receipt of a final response following receipt of
   provisional responses, an immediate confirmation shall be sent, and
   normal repetition timers shall be used thereafter.

In the last it says normal repetition timers shall be used therafter. The
purpose of this timer is not clear.

Please clarify.

Regards
Vivek




From owner-megaco@fore.com  Sat May 26 07:55:49 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18279
	for ; Sat, 26 May 2001 07:55:49 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA23201;
	Sat, 26 May 2001 07:50:03 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA15117
	for megaco-list; Sat, 26 May 2001 07:48:02 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA15113
	for ; Sat, 26 May 2001 07:48:01 -0400 (EDT)
From: vibansal@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA23114
	for ; Sat, 26 May 2001 07:47:55 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4QBnCn12582
	for ; Sat, 26 May 2001 17:19:13 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A58.003F74AA ; Sat, 26 May 2001 17:03:06 +0530
X-Lotus-FromDomain: HSS
To: megaco@fore.com
Message-ID: <65256A58.003F72F6.00@sandesh.hss.hns.com>
Date: Sat, 26 May 2001 17:17:33 +0530
Subject: Version negotiation
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk




Hi

If the version negotiations fails at MG, then what should be the recovery
action. Protocols says close the netwrok connection and give error to MGC in
case of any transaction from MGC. But it does not specify what should MG do
after the failure. Should it try to contact the other provisioned MGCs. or is it
assumed that all the MGCs are configured with the same version and MG will not
be able to create association with them.

Please  clarify this.

Regards
Vivek




From owner-megaco@fore.com  Sat May 26 13:11:13 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20241
	for ; Sat, 26 May 2001 13:11:13 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA26395;
	Sat, 26 May 2001 12:59:54 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA26149
	for megaco-list; Sat, 26 May 2001 12:54:50 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA26142
	for ; Sat, 26 May 2001 12:54:49 -0400 (EDT)
Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA26285
	for ; Sat, 26 May 2001 12:54:44 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4QGshdQ027848
	for ; Sat, 26 May 2001 11:54:43 -0500 (CDT)
From: "Paul Long" 
To: 
Subject: RE: Timer Problem
Date: Sat, 26 May 2001 11:54:19 -0500
Message-ID: 
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: <65256A58.001F7391.00@sandesh.hss.hns.com>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Vivek,

This refers to the retransmission timer. When you receive a provisional
response, or Pending, you are required to use a "different," presumably
longer retransmission timer for that transaction (D.1.4: "Entities that
receive a Transaction Pending shall switch to a different repetition timer
for repeating requests."). When you receive the final response, you are
required to switch back to using the original ... oh, wait, I understand
what you're saying now. The final response terminates any future
retransmissions for that transaction, so there is nothing to switch back to.
Therefore, I think the latter part of the sentence that you cite (", and
normal repetition timers shall be used thereafter.") doesn't make sense and
should be removed.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of
vibansal@hss.hns.com
Sent: Saturday, May 26, 2001 12:58 AM
To: megaco@fore.com
Subject: Timer Problem





Hi

Section D.1.4 indicates

Upon receipt of a final response following receipt of
   provisional responses, an immediate confirmation shall be sent, and
   normal repetition timers shall be used thereafter.

In the last it says normal repetition timers shall be used therafter. The
purpose of this timer is not clear.

Please clarify.

Regards
Vivek



From owner-megaco@fore.com  Mon May 28 01:01:54 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16632
	for ; Mon, 28 May 2001 01:01:53 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA17367;
	Mon, 28 May 2001 00:56:12 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA10825
	for megaco-list; Mon, 28 May 2001 00:49:41 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA10817
	for ; Mon, 28 May 2001 00:49:39 -0400 (EDT)
From: vibansal@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA17228
	for ; Mon, 28 May 2001 00:49:24 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4S4nwq25172;
	Mon, 28 May 2001 10:19:59 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A5A.00191173 ; Mon, 28 May 2001 10:03:48 +0530
X-Lotus-FromDomain: HSS
To: "Paul Long" 
cc: megaco@fore.com
Message-ID: <65256A5A.00191031.00@sandesh.hss.hns.com>
Date: Mon, 28 May 2001 10:18:19 +0530
Subject: RE: Timer Problem
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk




Hi Paul

I think you are right. This does not make any sense and it should be removed.

Regards
Vivek Bansal






"Paul Long"  on 05/26/2001 10:24:19 PM

To:   megaco@fore.com
cc:    (bcc: Vivek Bansal/HSS)

Subject:  RE: Timer Problem




Vivek,

This refers to the retransmission timer. When you receive a provisional
response, or Pending, you are required to use a "different," presumably
longer retransmission timer for that transaction (D.1.4: "Entities that
receive a Transaction Pending shall switch to a different repetition timer
for repeating requests."). When you receive the final response, you are
required to switch back to using the original ... oh, wait, I understand
what you're saying now. The final response terminates any future
retransmissions for that transaction, so there is nothing to switch back to.
Therefore, I think the latter part of the sentence that you cite (", and
normal repetition timers shall be used thereafter.") doesn't make sense and
should be removed.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of
vibansal@hss.hns.com
Sent: Saturday, May 26, 2001 12:58 AM
To: megaco@fore.com
Subject: Timer Problem





Hi

Section D.1.4 indicates

Upon receipt of a final response following receipt of
   provisional responses, an immediate confirmation shall be sent, and
   normal repetition timers shall be used thereafter.

In the last it says normal repetition timers shall be used therafter. The
purpose of this timer is not clear.

Please clarify.

Regards
Vivek







From owner-megaco@fore.com  Mon May 28 15:59:05 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06685
	for ; Mon, 28 May 2001 15:59:05 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA07375;
	Mon, 28 May 2001 15:52:05 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA12261
	for megaco-list; Mon, 28 May 2001 15:48:48 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA12257
	for ; Mon, 28 May 2001 15:48:47 -0400 (EDT)
Received: from ertpg15e1.nortelnetworks.com (ertpg15e1.nortelnetworks.com [47.234.0.36])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id PAA07269
	for ; Mon, 28 May 2001 15:48:44 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by ertpg15e1.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id PAA24251; Mon, 28 May 2001 15:48:39 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Mon, 28 May 2001 15:48:21 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Mon, 28 May 2001 15:48:24 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CBDE@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'megaco@fore.com'" 
Cc: "'AVGALVAN@telmex.net'" 
Subject: FW: Question about rate-transmission
Date: Mon, 28 May 2001 15:48:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E7AF.262B7850"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E7AF.262B7850
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Forwarded to the official Megaco list at megaco@fore.com.

For a Network Access Server (NAS), the call is typically coming in on =
TDM to
be connected to an appropriate modem.  To support this application, it =
was
necessary to define TDM-related attributes in SDP.  See
draft-taylor-megaco-sdptdm-00.txt for more information.

Tom Taylor
Multimedia Control and Applications Standards
Ph.  +1 613 736 0961
taylor@nortelnetworks.com=20

-----Original Message-----
From: Villa Galv=E1n Ana Ivet [mailto:AVGALVAN@telmex.net]
Sent: Monday, May 28, 2001 2:54 PM
To: MEGACO@marvin.corpeast.baynetworks.com
Subject: Question about rate-transmission


Hi, all=20

    In  the MG Control Protocol Requirements document in the secction
11.2.5e (Network Access Server) the paragrah gives some examples about
calls, one of them is 56 Kbit/s synchronous call. I would like to know =
what
either the rate-transmission or the rate-user is?

Thanks.


------_=_NextPart_001_01C0E7AF.262B7850
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






FW: Question about rate-transmission




Forwarded to the official Megaco list at =
megaco@fore.com.




For a Network Access Server (NAS), the call is =
typically coming in on TDM to be connected to an appropriate =
modem.  To support this application, it was necessary to define =
TDM-related attributes in SDP.  See =
draft-taylor-megaco-sdptdm-00.txt for more information.



Tom Taylor

Multimedia Control and Applications Standards

Ph.  +1 613 736 0961

taylor@nortelnetworks.com 




-----Original Message-----

From: Villa Galv=E1n Ana Ivet [mailto:AVGALVAN@telmex.net]

Sent: Monday, May 28, 2001 2:54 PM

To: MEGACO@marvin.corpeast.baynetworks.com

Subject: Question about rate-transmission






Hi, all 




    In  the MG Control Protocol =
Requirements document in the secction

11.2.5e (Network Access Server) the paragrah gives =
some examples about

calls, one of them is 56 Kbit/s synchronous call. I =
would like to know what

either the rate-transmission or the rate-user =
is?




Thanks.





------_=_NextPart_001_01C0E7AF.262B7850--


From owner-megaco@fore.com  Mon May 28 18:26:52 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07678
	for ; Mon, 28 May 2001 18:26:51 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA09666;
	Mon, 28 May 2001 18:19:52 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA18849
	for megaco-list; Mon, 28 May 2001 18:18:27 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA18845
	for ; Mon, 28 May 2001 18:18:26 -0400 (EDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA09571
	for ; Mon, 28 May 2001 18:18:22 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id IAA28486
	for ; Tue, 29 May 2001 08:17:04 +1000 (EST)
Received: from ericsson.com ([130.100.249.219])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id IAA20133
	for ; Tue, 29 May 2001 08:17:47 +1000 (EST)
Message-ID: <3B12B729.6DB49D43@ericsson.com>
Date: Tue, 29 May 2001 06:38:01 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco ietf 
Subject: Re: Timer Problem
References: <65256A5A.00191031.00@sandesh.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day,

I believe that the text is currently OK. You cannot read a sentence in
the middle of a paragraph by itself. The first sentence states that you
move to a different timers the sentence that you quote below states that
you should move back to your normal (original) timers. I don't think
this needs any change.

Christian

vibansal@hss.hns.com wrote:
> 
> Hi Paul
> 
> I think you are right. This does not make any sense and it should be removed.
> 
> Regards
> Vivek Bansal
> 
> "Paul Long"  on 05/26/2001 10:24:19 PM
> 
> To:   megaco@fore.com
> cc:    (bcc: Vivek Bansal/HSS)
> 
> Subject:  RE: Timer Problem
> 
> Vivek,
> 
> This refers to the retransmission timer. When you receive a provisional
> response, or Pending, you are required to use a "different," presumably
> longer retransmission timer for that transaction (D.1.4: "Entities that
> receive a Transaction Pending shall switch to a different repetition timer
> for repeating requests."). When you receive the final response, you are
> required to switch back to using the original ... oh, wait, I understand
> what you're saying now. The final response terminates any future
> retransmissions for that transaction, so there is nothing to switch back to.
> Therefore, I think the latter part of the sentence that you cite (", and
> normal repetition timers shall be used thereafter.") doesn't make sense and
> should be removed.
> 
> Paul Long
> ipDialog, Inc.
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of
> vibansal@hss.hns.com
> Sent: Saturday, May 26, 2001 12:58 AM
> To: megaco@fore.com
> Subject: Timer Problem
> 
> Hi
> 
> Section D.1.4 indicates
> 
> Upon receipt of a final response following receipt of
>    provisional responses, an immediate confirmation shall be sent, and
>    normal repetition timers shall be used thereafter.
> 
> In the last it says normal repetition timers shall be used therafter. The
> purpose of this timer is not clear.
> 
> Please clarify.
> 
> Regards
> Vivek




From owner-megaco@fore.com  Mon May 28 19:33:52 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08114
	for ; Mon, 28 May 2001 19:33:52 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA10883;
	Mon, 28 May 2001 19:28:14 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id TAA22240
	for megaco-list; Mon, 28 May 2001 19:27:05 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA22229
	for ; Mon, 28 May 2001 19:27:03 -0400 (EDT)
Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA10802
	for ; Mon, 28 May 2001 19:27:00 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4SNQxu3012200
	for ; Mon, 28 May 2001 18:26:59 -0500
From: "Paul Long" 
To: "megaco ietf" 
Subject: RE: Timer Problem
Date: Mon, 28 May 2001 18:26:53 -0500
Message-ID: 
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)
In-Reply-To: <3B12B729.6DB49D43@ericsson.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Christian,

If you move back to the original timeout value, for what will you use it? If
transactions are independent of one another with regard to this
retransmission layer, once an entity receives a final response for a
transaction, there will be nothing left to time. Or are you saying that
timers for all transactions use the same timeout value, in which case moving
to the new and then back to the original timer value effects all
transactions? The text then makes more sense, but linking possibly parallel
transactions like this causes me greater concern.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Christian Groves
Sent: Monday, May 28, 2001 3:38 PM
To: megaco ietf
Subject: Re: Timer Problem


G'Day,

I believe that the text is currently OK. You cannot read a sentence in
the middle of a paragraph by itself. The first sentence states that you
move to a different timers the sentence that you quote below states that
you should move back to your normal (original) timers. I don't think
this needs any change.

Christian

vibansal@hss.hns.com wrote:
>
> Hi Paul
>
> I think you are right. This does not make any sense and it should be
removed.
>
> Regards
> Vivek Bansal
>
> "Paul Long"  on 05/26/2001 10:24:19 PM
>
> To:   megaco@fore.com
> cc:    (bcc: Vivek Bansal/HSS)
>
> Subject:  RE: Timer Problem
>
> Vivek,
>
> This refers to the retransmission timer. When you receive a provisional
> response, or Pending, you are required to use a "different," presumably
> longer retransmission timer for that transaction (D.1.4: "Entities that
> receive a Transaction Pending shall switch to a different repetition timer
> for repeating requests."). When you receive the final response, you are
> required to switch back to using the original ... oh, wait, I understand
> what you're saying now. The final response terminates any future
> retransmissions for that transaction, so there is nothing to switch back
to.
> Therefore, I think the latter part of the sentence that you cite (", and
> normal repetition timers shall be used thereafter.") doesn't make sense
and
> should be removed.
>
> Paul Long
> ipDialog, Inc.
>
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of
> vibansal@hss.hns.com
> Sent: Saturday, May 26, 2001 12:58 AM
> To: megaco@fore.com
> Subject: Timer Problem
>
> Hi
>
> Section D.1.4 indicates
>
> Upon receipt of a final response following receipt of
>    provisional responses, an immediate confirmation shall be sent, and
>    normal repetition timers shall be used thereafter.
>
> In the last it says normal repetition timers shall be used therafter. The
> purpose of this timer is not clear.
>
> Please clarify.
>
> Regards
> Vivek



From owner-megaco@fore.com  Tue May 29 08:30:52 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29981
	for ; Tue, 29 May 2001 08:30:51 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA26642;
	Tue, 29 May 2001 07:57:11 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA16301
	for megaco-list; Tue, 29 May 2001 07:51:24 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA16297
	for ; Tue, 29 May 2001 07:51:23 -0400 (EDT)
From: vibansal@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA26374
	for ; Tue, 29 May 2001 07:51:21 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4TBqXP12201
	for ; Tue, 29 May 2001 17:22:33 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A5B.003FBEF0 ; Tue, 29 May 2001 17:06:16 +0530
X-Lotus-FromDomain: HSS
To: megaco@fore.com
Message-ID: <65256A5B.003F9315.00@sandesh.hss.hns.com>
Date: Tue, 29 May 2001 16:29:23 +0530
Subject: Version negotiation
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk




Hi Christian,

Since nobody replied back to my mail so should I assume that in case the version
negotiations fails with MGC, then MG should try with the secondary MGCs. In this
case we need to make change in the text of the protocol.

Regards
Vivek Bansal


---------------------- Forwarded by Vivek Bansal/HSS on 05/29/2001 04:19 PM
---------------------------

To:   megaco@fore.com
cc:    (bcc: Sachin Sikri/HSS)

Subject:  Version negotiation







Hi

If the version negotiations fails at MG, then what should be the recovery
action. Protocols says close the netwrok connection and give error to MGC in
case of any transaction from MGC. But it does not specify what should MG do
after the failure. Should it try to contact the other provisioned MGCs. or is it
assumed that all the MGCs are configured with the same version and MG will not
be able to create association with them.

Please  clarify this.

Regards
Vivek









From owner-megaco@fore.com  Tue May 29 09:20:00 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00827
	for ; Tue, 29 May 2001 09:20:00 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA01802;
	Tue, 29 May 2001 09:02:42 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA02799
	for megaco-list; Tue, 29 May 2001 09:01:22 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA02679
	for ; Tue, 29 May 2001 09:01:20 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 29 May 2001 09:01:11 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF04465473@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'vibansal@hss.hns.com'" , megaco@fore.com
Subject: RE: Version negotiation
Date: Tue, 29 May 2001 08:58:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

The situation is pretty complicated, and the action taken may
depend on a lot of things.  There are several strategies an MG
could use, including trying secondary MGCs.  One of the variables
is what profile the MGC offers; if it offers the correct profile,
but it's version of Megaco is earlier, and the MG can deal with
the older version, then it might stay with the MGC, or, it might 
try secondary MGCs looking for a better fit.  

As there is only one version, I'd defer any text changes until this
is a real problem.

Brian

> -----Original Message-----
> From: vibansal@hss.hns.com [mailto:vibansal@hss.hns.com]
> Sent: Tuesday, May 29, 2001 6:59 AM
> To: megaco@fore.com
> Subject: Version negotiation
> 
> 
> 
> 
> 
> Hi Christian,
> 
> Since nobody replied back to my mail so should I assume that 
> in case the version
> negotiations fails with MGC, then MG should try with the 
> secondary MGCs. In this
> case we need to make change in the text of the protocol.
> 
> Regards
> Vivek Bansal
> 
> 
> ---------------------- Forwarded by Vivek Bansal/HSS on 
> 05/29/2001 04:19 PM
> ---------------------------
> 
> To:   megaco@fore.com
> cc:    (bcc: Sachin Sikri/HSS)
> 
> Subject:  Version negotiation
> 
> 
> 
> 
> 
> 
> 
> Hi
> 
> If the version negotiations fails at MG, then what should be 
> the recovery
> action. Protocols says close the netwrok connection and give 
> error to MGC in
> case of any transaction from MGC. But it does not specify 
> what should MG do
> after the failure. Should it try to contact the other 
> provisioned MGCs. or is it
> assumed that all the MGCs are configured with the same 
> version and MG will not
> be able to create association with them.
> 
> Please  clarify this.
> 
> Regards
> Vivek
> 
> 
> 
> 
> 
> 
> 


From owner-megaco@fore.com  Tue May 29 13:22:09 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07125
	for ; Tue, 29 May 2001 13:22:09 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA22206;
	Tue, 29 May 2001 12:49:28 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA04066
	for megaco-list; Tue, 29 May 2001 12:46:39 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA04062
	for ; Tue, 29 May 2001 12:46:37 -0400 (EDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA21942
	for ; Tue, 29 May 2001 12:46:34 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id CAA15516
	for ; Wed, 30 May 2001 02:45:16 +1000 (EST)
Received: from ericsson.com ([130.100.249.229])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id CAA13655
	for ; Wed, 30 May 2001 02:46:00 +1000 (EST)
Message-ID: <3B13C0EA.6B420DB2@ericsson.com>
Date: Wed, 30 May 2001 01:31:54 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco ietf 
Subject: Re: Timer Problem
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day Paul,

I'm not saying how you implement the timers - whether its per
transaction or per receiving entity. I just don't think that the
sentence is very contraversial. ie. At the start of the paragraph:
"Entities that receive a Transaction Pending shall switch to a different
repetition timer"
the sentence in question:
"and normal repetition timers shall be used thereafter."

So however you implement the entity which manages this, the sentence in
question is the clause which tells this entity to go back to its normal
timers. I think people are trying to read way too much in this. I'm
assuming that there's been plenty of TCP implementions of this already
which haven't caused this much fuss.
 
Cheers, Christian

Paul Long wrote:
> 
> Christian,
> 
> If you move back to the original timeout value, for what will you use it? If
> transactions are independent of one another with regard to this
> retransmission layer, once an entity receives a final response for a
> transaction, there will be nothing left to time. Or are you saying that
> timers for all transactions use the same timeout value, in which case moving
> to the new and then back to the original timer value effects all
> transactions? The text then makes more sense, but linking possibly parallel
> transactions like this causes me greater concern.
> 
> Paul Long
> ipDialog, Inc.
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Christian Groves
> Sent: Monday, May 28, 2001 3:38 PM
> To: megaco ietf
> Subject: Re: Timer Problem
> 
> G'Day,
> 
> I believe that the text is currently OK. You cannot read a sentence in
> the middle of a paragraph by itself. The first sentence states that you
> move to a different timers the sentence that you quote below states that
> you should move back to your normal (original) timers. I don't think
> this needs any change.
> 
> Christian
> 
> vibansal@hss.hns.com wrote:
> >
> > Hi Paul
> >
> > I think you are right. This does not make any sense and it should be
> removed.
> >
> > Regards
> > Vivek Bansal
> >
> > "Paul Long"  on 05/26/2001 10:24:19 PM
> >
> > To:   megaco@fore.com
> > cc:    (bcc: Vivek Bansal/HSS)
> >
> > Subject:  RE: Timer Problem
> >
> > Vivek,
> >
> > This refers to the retransmission timer. When you receive a provisional
> > response, or Pending, you are required to use a "different," presumably
> > longer retransmission timer for that transaction (D.1.4: "Entities that
> > receive a Transaction Pending shall switch to a different repetition timer
> > for repeating requests."). When you receive the final response, you are
> > required to switch back to using the original ... oh, wait, I understand
> > what you're saying now. The final response terminates any future
> > retransmissions for that transaction, so there is nothing to switch back
> to.
> > Therefore, I think the latter part of the sentence that you cite (", and
> > normal repetition timers shall be used thereafter.") doesn't make sense
> and
> > should be removed.
> >
> > Paul Long
> > ipDialog, Inc.
> >
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of
> > vibansal@hss.hns.com
> > Sent: Saturday, May 26, 2001 12:58 AM
> > To: megaco@fore.com
> > Subject: Timer Problem
> >
> > Hi
> >
> > Section D.1.4 indicates
> >
> > Upon receipt of a final response following receipt of
> >    provisional responses, an immediate confirmation shall be sent, and
> >    normal repetition timers shall be used thereafter.
> >
> > In the last it says normal repetition timers shall be used therafter. The
> > purpose of this timer is not clear.
> >
> > Please clarify.
> >
> > Regards
> > Vivek



From owner-megaco@fore.com  Tue May 29 17:12:32 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11265
	for ; Tue, 29 May 2001 17:12:31 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA12654;
	Tue, 29 May 2001 16:40:20 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA06725
	for megaco-list; Tue, 29 May 2001 16:38:55 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA06696
	for ; Tue, 29 May 2001 16:38:32 -0400 (EDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA12410
	for ; Tue, 29 May 2001 16:38:29 -0400 (EDT)
Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id PAA24709
	for ; Tue, 29 May 2001 15:38:31 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4TKcXw24836
	for ; Tue, 29 May 2001 15:38:33 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4TKbX115811
	for ; Tue, 29 May 2001 15:37:33 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4TKbXO23140
	for ; Tue, 29 May 2001 15:37:33 -0500 (CDT)
Message-ID: <3B14088D.F7359AD4@usa.alcatel.com>
Date: Tue, 29 May 2001 15:37:33 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Network Package
Content-Type: multipart/alternative;
 boundary="------------387481D5A936237EBA449DDA"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------387481D5A936237EBA449DDA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi All


Is it reasonable to assume that Network Package StatisticsID will never
be used directly?
That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os and
rtp/or respectiviely
since rtp package extends nt package.

I know that it is agreed that if a termination realizes rtp package, it
also realizes nt package
and either nt/.. or rtp/.. are valid packageName.

But if we allow, nt/... instead of rtp/.., are we saying that if MGC
receives nt/.., it has to
know whether it is for rtp or tmcd termination by the terminationID?


Furthermore, since tdmc package extends nt package, do "octet sent" (OS)
and "octet
received" (OR) really apply to tdm termination?

Also what does it mean for a TDM termination to realize the "NT" package
properties
of "Maximum Jitter Buffer"?

So a more general question, if a termination realizes a packageB that
extends
packageA and there are items in the packageA that does not make sense to

the termination what should MG/MGC do.

Take the above as an example and assuming that it does not make sense
for TDM
termination to have "OS" and "OR", what should MG return for
TDM termination
statistics if the termination realizes "TDMC" package?
Just "duration".

---
Said it is valid to have "OS" and "OR" for TDM.
IF MGC does a Subtract=* on a specific context w/1 TDM and 1
RTP termination,
is it valid for MG to return nt/dur, nt/os and nt/or for the
TDM termination and RTP
termination instead of tdmc/dur, ... vs rtp/dur ?

Thanks
Chuong




--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------387481D5A936237EBA449DDA
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hi All

 

Is it reasonable to assume that Network Package StatisticsID will never
be used directly?

That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os and
rtp/or respectiviely

since rtp package extends nt package.

I know that it is agreed that if a termination realizes rtp package,
it also realizes nt package

and either nt/.. or rtp/.. are valid packageName.

But if we allow, nt/... instead of rtp/.., are we saying that if MGC
receives nt/.., it has to

know whether it is for rtp or tmcd termination by the terminationID?

 

Furthermore, since tdmc package extends nt package, do "octet sent"
(OS) and "octet

received" (OR) really apply to tdm termination?

Also what does it mean for a TDM termination to realize the "NT"
package properties

of "Maximum Jitter Buffer"?

So a more general question, if a termination realizes a packageB that
extends

packageA and there are items in the packageA that does not make sense
to

the termination what should MG/MGC do.

Take the above as an example and assuming that it does not make sense
for TDM

termination to have "OS" and "OR", what should MG return for TDM termination

statistics if the termination realizes "TDMC" package?

Just "duration".

---

Said it is valid to have "OS" and "OR" for TDM.

IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP termination,

is it valid for MG to return nt/dur, nt/os and nt/or for the TDM termination
and RTP

termination instead of tdmc/dur, ... vs rtp/dur ?

Thanks

Chuong

 

 

 

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------387481D5A936237EBA449DDA--



From owner-megaco@fore.com  Tue May 29 17:25:06 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11418
	for ; Tue, 29 May 2001 17:25:05 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15700;
	Tue, 29 May 2001 17:17:03 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA16624
	for megaco-list; Tue, 29 May 2001 17:16:20 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA16617
	for ; Tue, 29 May 2001 17:16:18 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 29 May 2001 17:16:18 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF04465497@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Madhu Babu Brahmanapally'" ,
        "'Chuong Nguyen'"
	 
Cc: megaco@fore.com
Subject: RE: Network Package
Date: Tue, 29 May 2001 17:16:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0E884.9A006C60"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E884.9A006C60
Content-Type: text/plain;
	charset="iso-8859-1"

If you implement any part of a package, you implement all of it.
If a package extends any part of a package, it extends all of it.
 
What is not required is that if you implement a package that extends
another package that you have to "expose" the underlying package.
This means that if you implement rtp you don't have to expose nt.
If you list nt as one of the packages in an audit, then you have to
implement nt/dur.  
 
Brian

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Tuesday, May 29, 2001 5:15 PM
To: 'Chuong Nguyen'
Cc: megaco@fore.com
Subject: RE: Network Package


Hi chuong/all,
IMO if PackageB extends PackageA and if one of the statistic/property of
Package A is not valid for termination realizing packageB then there is no
reason why PackageB extends PackageA. Then PackageB shouldn't extend
PackageA (just only to reuse few properties/statistics) but should define
the same properties (Might be with different IDs) in packageB. 
 
I think the extension of packages is logical if the newly defined package
can inherit "all" the properties already defined in the base package and
also define new properties. 
 
In your example, I was in the impression that "OS" and "OR" can be
calculated as "The number of octet sent or received is equal to the duration
of the Termination, in seconds, multiplied by the sampling frequency,  8000
Hz.". (Of course this seems to be redundant info if the MGC is aware of the
sampling frequency). Isn't this the intention?????
 
 
-Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Chuong Nguyen
Sent: Tuesday, May 29, 2001 4:38 PM
To: megaco@fore.com
Subject: Network Package


Hi All 
  

Is it reasonable to assume that Network Package StatisticsID will never be
used directly? 
That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os and rtp/or
respectiviely 
since rtp package extends nt package. 


I know that it is agreed that if a termination realizes rtp package, it also
realizes nt package 
and either nt/.. or rtp/.. are valid packageName. 


But if we allow, nt/... instead of rtp/.., are we saying that if MGC
receives nt/.., it has to 
know whether it is for rtp or tmcd termination by the terminationID? 
  


Furthermore, since tdmc package extends nt package, do "octet sent" (OS) and
"octet 
received" (OR) really apply to tdm termination? 


Also what does it mean for a TDM termination to realize the "NT" package
properties 
of "Maximum Jitter Buffer"? 


So a more general question, if a termination realizes a packageB that
extends 
packageA and there are items in the packageA that does not make sense to 
the termination what should MG/MGC do. 


Take the above as an example and assuming that it does not make sense for
TDM 
termination to have "OS" and "OR", what should MG return for TDM termination

statistics if the termination realizes "TDMC" package? 
Just "duration". 


--- 
Said it is valid to have "OS" and "OR" for TDM. 
IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP
termination, 
is it valid for MG to return nt/dur, nt/os and nt/or for the TDM termination
and RTP 
termination instead of tdmc/dur, ... vs rtp/dur ? 


Thanks 
Chuong 
  
  
  

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


------_=_NextPart_001_01C0E884.9A006C60
Content-Type: text/html;
	charset="iso-8859-1"









If you 
implement any part of a package, you implement all of it.


If a package 
extends any part of a package, it extends all of it.


 


What is not 
required is that if you implement a package that extends


another 
package that you have to "expose" the underlying package.


This means 
that if you implement rtp you don't have to expose nt.


If you list 
nt as one of the packages in an audit, then you have to


implement 
nt/dur.  


 


Brian



  
-----Original Message-----
From: Madhu Babu Brahmanapally 
  [mailto:madhubabu@kenetec.com]
Sent: Tuesday, May 29, 2001 5:15 
  PM
To: 'Chuong Nguyen'
Cc: 
  megaco@fore.com
Subject: RE: Network Package


  
Hi 
  chuong/all,

  
IMO 
  if PackageB extends PackageA and if one of the statistic/property of Package A 
  is not valid for termination realizing packageB then there is no reason why 
  PackageB extends PackageA. Then PackageB shouldn't extend PackageA (just only 
  to reuse few properties/statistics) but should define the same properties 
  (Might be with different IDs) in packageB. 

  
 

  
I 
  think the extension of packages is logical if the newly defined package can 
  inherit "all" the properties already defined in the base package and also 
  define new properties. 

  
 

  
In 
  your example, I was in the impression that "OS" and "OR" can be calculated as 
  "The number of octet sent or received is equal to the duration of the 
  Termination, in seconds, multiplied by the sampling frequency,  8000 
  Hz.". (Of course this seems to be redundant info if the MGC is aware of the 
  sampling frequency). Isn't this the intention?????

  
 

  
 

  
-Regards

  
Madhubabu

  

    
-----Original Message-----
From: 
    owner-megaco@pit.comms.marconi.com 
    [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Chuong 
    Nguyen
Sent: Tuesday, May 29, 2001 4:38 PM
To: 
    megaco@fore.com
Subject: Network Package

Hi 
    All 
  
    
Is it reasonable to assume that Network Package StatisticsID will never 
    be used directly? 
That is nt/dur, nt/os and nt/or will normally be 
    rtp/dur, rtp/os and rtp/or respectiviely 
since rtp package extends nt 
    package. 
    
I know that it is agreed that if a termination realizes rtp package, 
    it also realizes nt package 
and either nt/.. or rtp/.. are valid 
    packageName. 
    
But if we allow, nt/... instead of rtp/.., are we saying that if MGC 
    receives nt/.., it has to 
know whether it is for rtp or tmcd termination 
    by the terminationID? 
  
    
Furthermore, since tdmc package extends nt package, do "octet sent" (OS) 
    and "octet 
received" (OR) really apply to tdm termination? 
    
Also what does it mean for a TDM termination to realize the "NT" 
    package properties 
of "Maximum Jitter Buffer"? 
    
So a more general question, if a termination realizes a packageB that 
    extends 
packageA and there are items in the packageA that does not make 
    sense to 
the termination what should MG/MGC do. 
    
Take the above as an example and assuming that it does not make sense for 
    TDM 
termination to have "OS" and "OR", what should MG return for 
    TDM termination 
statistics if the termination realizes "TDMC" 
    package? 
Just "duration". 
    
--- 
Said it is valid to have "OS" and "OR" for TDM. 
IF MGC 
    does a Subtract=* on a specific context w/1 TDM and 1 
    RTP termination, 
is it valid for MG to return nt/dur, nt/os and 
    nt/or for the TDM termination and RTP 
termination instead of 
    tdmc/dur, ... vs rtp/dur ? 
    
Thanks 
Chuong 
  
  
  
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  
  


------_=_NextPart_001_01C0E884.9A006C60--


From owner-megaco@fore.com  Tue May 29 17:34:06 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11600
	for ; Tue, 29 May 2001 17:34:01 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA14515;
	Tue, 29 May 2001 17:01:51 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA13539
	for megaco-list; Tue, 29 May 2001 17:01:06 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA13529
	for ; Tue, 29 May 2001 17:01:05 -0400 (EDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA14407
	for ; Tue, 29 May 2001 17:01:01 -0400 (EDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Tue, 29 May 2001 16:01:45 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD94945811151@RADVPOST>
From: Dan Elbert 
To: "'megaco@fore.com'" 
Subject: tdmc package question
Date: Tue, 29 May 2001 16:01:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hi
In the tdmc package, does the "gain" property refer to the output gain, the
input gain, or both?
Also, about the silence suppression, there was a discussion some time ago
but I don't believe it was satisfactorily resolved. 
So again the question is, I do I set the silence suppression (on/of) for the
text encoding?

Thanks
Dan Elbert
RADVISION



From owner-megaco@fore.com  Tue May 29 17:40:46 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11660
	for ; Tue, 29 May 2001 17:40:46 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA16615;
	Tue, 29 May 2001 17:29:36 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA19036
	for megaco-list; Tue, 29 May 2001 17:28:28 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA19021
	for ; Tue, 29 May 2001 17:28:26 -0400 (EDT)
Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA16472
	for ; Tue, 29 May 2001 17:28:24 -0400 (EDT)
Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1])
	by ihemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4TLSPu02469
	for ; Tue, 29 May 2001 17:28:25 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4TLSPL02457
	for ; Tue, 29 May 2001 17:28:25 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id RAA17210; Tue, 29 May 2001 17:28:24 -0400 (EDT)
Cc: megaco@fore.com
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id RAA17193; Tue, 29 May 2001 17:28:22 -0400 (EDT)
Message-ID: <3B1413FE.29330FC6@lucent.com>
Date: Tue, 29 May 2001 17:26:22 -0400
From: Troy Cauble 
Reply-To: Troy Cauble 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" 
Original-CC: megaco@fore.com
Subject: Re: Network Package
References: <4FBEA8857476D311A03300204840E1CF04465497@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

> 
> If you implement any part of a package, you implement all of it.
> If a package extends any part of a package, it extends all of it.

What do you mean by this statement?

Package A might have Signals and Events.
Are you saying Package B can't extend A's Signals
but not A's Events?  It can't extend the values
for Signal A1, without extending the values for
Event A7 ??

-troy

>  
> What is not required is that if you implement a package that extends
> another package that you have to "expose" the underlying package.
> This means that if you implement rtp you don't have to expose nt.
> If you list nt as one of the packages in an audit, then you have to
> implement nt/dur.  
>  
> Brian


From owner-megaco@fore.com  Tue May 29 17:44:30 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11703
	for ; Tue, 29 May 2001 17:44:27 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15254;
	Tue, 29 May 2001 17:13:00 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA15876
	for megaco-list; Tue, 29 May 2001 17:12:22 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15870
	for ; Tue, 29 May 2001 17:12:21 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15138
	for ; Tue, 29 May 2001 17:12:19 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.124])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACP39909;
	Tue, 29 May 2001 17:12:13 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Chuong Nguyen'" 
Cc: 
Subject: RE: Network Package
Date: Tue, 29 May 2001 17:15:22 -0400
Message-ID: <005801c0e884$790f0b10$c500a8c0@MBRAHMANAPALLY>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0059_01C0E862.F1FD6B10"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3B14088D.F7359AD4@usa.alcatel.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

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

Hi chuong/all,
IMO if PackageB extends PackageA and if one of the statistic/property of
Package A is not valid for termination realizing packageB then there is no
reason why PackageB extends PackageA. Then PackageB shouldn't extend
PackageA (just only to reuse few properties/statistics) but should define
the same properties (Might be with different IDs) in packageB.

I think the extension of packages is logical if the newly defined package
can inherit "all" the properties already defined in the base package and
also define new properties.

In your example, I was in the impression that "OS" and "OR" can be
calculated as "The number of octet sent or received is equal to the duration
of the Termination, in seconds, multiplied by the sampling frequency,  8000
Hz.". (Of course this seems to be redundant info if the MGC is aware of the
sampling frequency). Isn't this the intention?????


-Regards
Madhubabu
  -----Original Message-----
  From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Chuong Nguyen
  Sent: Tuesday, May 29, 2001 4:38 PM
  To: megaco@fore.com
  Subject: Network Package


  Hi All

  Is it reasonable to assume that Network Package StatisticsID will never be
used directly?
  That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os and
rtp/or respectiviely
  since rtp package extends nt package.

  I know that it is agreed that if a termination realizes rtp package, it
also realizes nt package
  and either nt/.. or rtp/.. are valid packageName.

  But if we allow, nt/... instead of rtp/.., are we saying that if MGC
receives nt/.., it has to
  know whether it is for rtp or tmcd termination by the terminationID?


  Furthermore, since tdmc package extends nt package, do "octet sent" (OS)
and "octet
  received" (OR) really apply to tdm termination?

  Also what does it mean for a TDM termination to realize the "NT" package
properties
  of "Maximum Jitter Buffer"?

  So a more general question, if a termination realizes a packageB that
extends
  packageA and there are items in the packageA that does not make sense to
  the termination what should MG/MGC do.

  Take the above as an example and assuming that it does not make sense for
TDM
  termination to have "OS" and "OR", what should MG return for TDM
termination
  statistics if the termination realizes "TDMC" package?
  Just "duration".

  ---
  Said it is valid to have "OS" and "OR" for TDM.
  IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP
termination,
  is it valid for MG to return nt/dur, nt/os and nt/or for the TDM
termination and RTP
  termination instead of tdmc/dur, ... vs rtp/dur ?

  Thanks
  Chuong




--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****


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









Hi=20
chuong/all,


IMO if=20
PackageB extends PackageA and if one of the statistic/property of =
Package A is=20
not valid for termination realizing packageB then there is no reason why =

PackageB extends PackageA. Then PackageB shouldn't extend PackageA (just =
only to=20
reuse few properties/statistics) but should define the same properties =
(Might be=20
with different IDs) in packageB. 


 


I=20
think the extension of packages is logical if the newly defined package =
can=20
inherit "all" the properties already defined in the base package and =
also define=20
new properties. 


 


In=20
your example, I was in the impression that "OS" and "OR" can be =
calculated as=20
"The number of octet sent or received is equal to the duration of the=20
Termination, in seconds, multiplied by the sampling frequency,  =
8000 Hz.".=20
(Of course this seems to be redundant info if the MGC is aware of the =
sampling=20
frequency). Isn't this the intention?????


 


 


-Regards


Madhubabu



  
-----Original Message-----
From:=20
  owner-megaco@pit.comms.marconi.com=20
  [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Chuong=20
  Nguyen
Sent: Tuesday, May 29, 2001 4:38 PM
To:=20
  megaco@fore.com
Subject: Network =
Package

Hi All=20
  
 =20
  
Is it reasonable to assume that Network Package StatisticsID will =
never be=20
  used directly? 
That is nt/dur, nt/os and nt/or will normally be =
rtp/dur,=20
  rtp/os and rtp/or respectiviely 
since rtp package extends nt =
package.=20
  
I know that it is agreed that if a termination realizes rtp =
package,=20
  it also realizes nt package 
and either nt/.. or rtp/.. are valid=20
  packageName.=20
  
But if we allow, nt/... instead of rtp/.., are we saying that if =
MGC=20
  receives nt/.., it has to 
know whether it is for rtp or tmcd =
termination=20
  by the terminationID? 
 =20
  
Furthermore, since tdmc package extends nt package, do "octet sent" =
(OS)=20
  and "octet 
received" (OR) really apply to tdm termination?=20
  
Also what does it mean for a TDM termination to realize the =
"NT"=20
  package properties 
of "Maximum Jitter Buffer"?=20
  
So a more general question, if a termination realizes a packageB =
that=20
  extends 
packageA and there are items in the packageA that does not =
make=20
  sense to 
the termination what should MG/MGC do.=20
  
Take the above as an example and assuming that it does not make =
sense for=20
  TDM 
termination to have "OS" and "OR", what should MG return for=20
  TDM termination 
statistics if the termination realizes "TDMC" =

  package? 
Just "duration".=20
  
--- 
Said it is valid to have "OS" and "OR" for TDM. 
IF =
MGC=20
  does a Subtract=3D* on a specific context w/1 TDM and 1=20
  RTP termination, 
is it valid for MG to return nt/dur, nt/os =
and nt/or=20
  for the TDM termination and RTP 
termination instead of =
tdmc/dur, ...=20
  vs rtp/dur ?=20
  
Thanks 
Chuong 
  
  
  
-- 
  Alcatel USA, =
Inc           &nbs=
p; Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas =
75075           =
Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc =
****
 =20



------=_NextPart_000_0059_01C0E862.F1FD6B10--



From owner-megaco@fore.com  Tue May 29 17:56:43 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11883
	for ; Tue, 29 May 2001 17:56:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA16807;
	Tue, 29 May 2001 17:30:40 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA19492
	for megaco-list; Tue, 29 May 2001 17:29:37 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA19477
	for ; Tue, 29 May 2001 17:29:35 -0400 (EDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA16595
	for ; Tue, 29 May 2001 17:29:31 -0400 (EDT)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA03947
	for ; Tue, 29 May 2001 16:29:33 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4TLTWT19590
	for ; Tue, 29 May 2001 16:29:32 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4TLTL122535
	for ; Tue, 29 May 2001 16:29:21 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4TLTLO24234
	for ; Tue, 29 May 2001 16:29:21 -0500 (CDT)
Message-ID: <3B1414B1.FA238EB1@usa.alcatel.com>
Date: Tue, 29 May 2001 16:29:21 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Network Package
References: <4FBEA8857476D311A03300204840E1CF04465497@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: multipart/alternative;
 boundary="------------BAC1C754A6C0EF61C766B9E9"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------BAC1C754A6C0EF61C766B9E9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Rosen, Brian" wrote:

> If you implement any part of a package, you implement all of it.If a
> package extends any part of a package, it extends all of it.

> What is not required is that if you implement a package that
> extendsanother package that you have to "expose" the underlying
> package.This means that if you implement rtp you don't have to expose
> nt.If you list nt as one of the packages in an audit, then you have
> toimplement nt/dur.

  I don't quite follow here.
               You seem to imply that nt/dur and rtp/dur are 2 different
things.
               I thought both nt/dur and rtp/dur are the same thing
w/the same value.
              If MG exposed nt, what should it return for duration -
nt/dur or rtp/dur?

Do you know the intend of tdmc/os and tdmc/or?
I thought the same as Madhubabu about how they are calculated.





> Brian
>
>      -----Original Message-----
>      From: Madhu Babu Brahmanapally
>      [mailto:madhubabu@kenetec.com]
>      Sent: Tuesday, May 29, 2001 5:15 PM
>      To: 'Chuong Nguyen'
>      Cc: megaco@fore.com
>      Subject: RE: Network Package
>      Hi chuong/all,IMO if PackageB extends PackageA and if one of
>      the statistic/property of Package A is not valid for
>      termination realizing packageB then there is no reason why
>      PackageB extends PackageA. Then PackageB shouldn't extend
>      PackageA (just only to reuse few properties/statistics) but
>      should define the same properties (Might be with different
>      IDs) in packageB. I think the extension of packages is
>      logical if the newly defined package can inherit "all" the
>      properties already defined in the base package and also
>      define new properties. In your example, I was in the
>      impression that "OS" and "OR" can be calculated as "The
>      number of octet sent or received is equal to the duration of
>      the Termination, in seconds, multiplied by the sampling
>      frequency,  8000 Hz.". (Of course this seems to be redundant
>      info if the MGC is aware of the sampling frequency). Isn't
>      this the intention?????-RegardsMadhubabu
>
>           -----Original Message-----
>           From: owner-megaco@pit.comms.marconi.com
>           [mailto:owner-megaco@pit.comms.marconi.com]On
>           Behalf Of Chuong Nguyen
>           Sent: Tuesday, May 29, 2001 4:38 PM
>           To: megaco@fore.com
>           Subject: Network Package
>           Hi All
>
>
>           Is it reasonable to assume that Network Package
>           StatisticsID will never be used directly?
>           That is nt/dur, nt/os and nt/or will normally be
>           rtp/dur, rtp/os and rtp/or respectiviely
>           since rtp package extends nt package.
>
>           I know that it is agreed that if a termination
>           realizes rtp package, it also realizes nt package
>           and either nt/.. or rtp/.. are valid packageName.
>
>           But if we allow, nt/... instead of rtp/.., are we
>           saying that if MGC receives nt/.., it has to
>           know whether it is for rtp or tmcd termination by
>           the terminationID?
>
>
>           Furthermore, since tdmc package extends nt
>           package, do "octet sent" (OS) and "octet
>           received" (OR) really apply to tdm termination?
>
>           Also what does it mean for a TDM termination to
>           realize the "NT" package properties
>           of "Maximum Jitter Buffer"?
>
>           So a more general question, if a termination
>           realizes a packageB that extends
>           packageA and there are items in the packageA that
>           does not make sense to
>           the termination what should MG/MGC do.
>
>           Take the above as an example and assuming that it
>           does not make sense for TDM
>           termination to have "OS" and "OR", what should MG
>           return for TDM termination
>           statistics if the termination realizes "TDMC"
>           package?
>           Just "duration".
>
>           ---
>           Said it is valid to have "OS" and "OR" for TDM.
>           IF MGC does a Subtract=* on a specific context w/1
>           TDM and 1 RTP termination,
>           is it valid for MG to return nt/dur, nt/os and
>           nt/or for the TDM termination and RTP
>           termination instead of tdmc/dur, ... vs rtp/dur ?
>
>           Thanks
>           Chuong
>
>
>
>
>           --
>             Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>             1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>             **** The opinions expressed are not those of Alcatel USA, Inc ****
>
>
>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------BAC1C754A6C0EF61C766B9E9
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



"Rosen, Brian" wrote:

If
you implement any part of a package, you implement all of it.If
a package extends any part of a package, it extends all of it.



What
is not required is that if you implement a package that extendsanother
package that you have to "expose" the underlying package.This
means that if you implement rtp you don't have to expose nt.If
you list nt as one of the packages in an audit, then you have toimplement
nt/dur.




<cnn>  I don't quite follow here.

              
You seem to imply that nt/dur and rtp/dur are 2 different things.

              
I thought both nt/dur and rtp/dur are the same thing w/the same value.

             
If MG exposed nt, what should it return for duration - nt/dur or rtp/dur?

Do you know the intend of tdmc/os and tdmc/or?

I thought the same as Madhubabu about how they are calculated.

 

 

 

 

Brian



-----Original
Message-----

From: Madhu Babu Brahmanapally
[mailto:madhubabu@kenetec.com]

Sent: Tuesday, May 29, 2001
5:15 PM

To: 'Chuong Nguyen'

Cc: megaco@fore.com

Subject: RE: Network Package

Hi
chuong/all,IMO if PackageB extends
PackageA and if one of the statistic/property of Package A is not valid
for termination realizing packageB then there is no reason why PackageB
extends PackageA. Then PackageB shouldn't extend PackageA (just only to
reuse few properties/statistics) but should define the same properties
(Might be with different IDs) in packageB. I
think the extension of packages is logical if the newly defined package
can inherit "all" the properties already defined in the base package and
also define new properties. In
your example, I was in the impression that "OS" and "OR" can be calculated
as "The number of octet sent or received is equal to the duration of the
Termination, in seconds, multiplied by the sampling frequency,  8000
Hz.". (Of course this seems to be redundant info if the MGC is aware of
the sampling frequency). Isn't this the intention?????-RegardsMadhubabu



-----Original
Message-----

From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Chuong Nguyen

Sent: Tuesday, May 29, 2001
4:38 PM

To: megaco@fore.com

Subject: Network Package

Hi All

 

Is it reasonable to assume that Network Package StatisticsID will never
be used directly?

That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os and
rtp/or respectiviely

since rtp package extends nt package.

I know that it is agreed that if a termination realizes rtp package,
it also realizes nt package

and either nt/.. or rtp/.. are valid packageName.

But if we allow, nt/... instead of rtp/.., are we saying that if MGC
receives nt/.., it has to

know whether it is for rtp or tmcd termination by the terminationID?

 

Furthermore, since tdmc package extends nt package, do "octet sent"
(OS) and "octet

received" (OR) really apply to tdm termination?

Also what does it mean for a TDM termination to realize the "NT" package
properties

of "Maximum Jitter Buffer"?

So a more general question, if a termination realizes a packageB that
extends

packageA and there are items in the packageA that does not make sense
to

the termination what should MG/MGC do.

Take the above as an example and assuming that it does not make sense
for TDM

termination to have "OS" and "OR", what should MG return for TDM termination

statistics if the termination realizes "TDMC" package?

Just "duration".

---

Said it is valid to have "OS" and "OR" for TDM.

IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP termination,

is it valid for MG to return nt/dur, nt/os and nt/or for the TDM termination
and RTP

termination instead of tdmc/dur, ... vs rtp/dur ?

Thanks

Chuong

 

 

 

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 







-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------BAC1C754A6C0EF61C766B9E9--



From owner-megaco@fore.com  Tue May 29 18:07:30 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12038
	for ; Tue, 29 May 2001 18:07:30 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA17481;
	Tue, 29 May 2001 17:38:56 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA21255
	for megaco-list; Tue, 29 May 2001 17:38:20 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA21233
	for ; Tue, 29 May 2001 17:38:18 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 29 May 2001 17:38:18 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF04465498@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Troy Cauble'" 
Cc: megaco@fore.com
Subject: RE: Network Package
Date: Tue, 29 May 2001 17:38:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

> > If you implement any part of a package, you implement all of it.
> > If a package extends any part of a package, it extends all of it.
> 
> What do you mean by this statement?
> 
> Package A might have Signals and Events.
> Are you saying Package B can't extend A's Signals
> but not A's Events?  It can't extend the values
> for Signal A1, without extending the values for
> Event A7 ??
Well, not the way you wrote it, but probably what you meant.
If Package A defines Signal A1 and Event A7, and Package
B extends Package A, then Signal B/A1 and event B/A7 are
defined, and must be implemented.  You don't have to "extend"
event A7, but you do have to implement it.

Brian 


From owner-megaco@fore.com  Tue May 29 18:22:38 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12163
	for ; Tue, 29 May 2001 18:22:38 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA18172;
	Tue, 29 May 2001 17:47:57 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA23033
	for megaco-list; Tue, 29 May 2001 17:47:07 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA23022
	for ; Tue, 29 May 2001 17:47:05 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 29 May 2001 17:47:06 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF04465499@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Chuong Nguyen'" , megaco@fore.com
Subject: RE: Network Package
Date: Tue, 29 May 2001 17:47:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0E888.E69785A0"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E888.E69785A0
Content-Type: text/plain;
	charset="iso-8859-1"

Well rtp/dur and nt/dur are "the same thing" in the sense that the mean the
same
thing, but if you implement (expose) both packages, then they are "separate"
statistics.  Using Events is perhaps easier to understand.  Suppose Package
A
implements event E1, and package B extends Package A, and a given
implementation
exposes both A and B, such that an audit of termination T1 returns
Packages{..A,B..}
 
You can say Add=T1{Events=123{B/E1}}
or you can say
Add=T1{Events=123{A/T1}}
or even
Add=T1{Events=123{A/T1,B/T1}}
 
In the latter, detection of the event would result in a notify of both.
 
Returning to statistics, the value would be the same, but they are separate
statistics.
 
Brian

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Tuesday, May 29, 2001 5:29 PM
To: megaco@fore.com
Subject: Re: Network Package


"Rosen, Brian" wrote: 

If you implement any part of a package, you implement all of it.If a package
extends any part of a package, it extends all of it.

What is not required is that if you implement a package that extendsanother
package that you have to "expose" the underlying package.This means that if
you implement rtp you don't have to expose nt.If you list nt as one of the
packages in an audit, then you have toimplement nt/dur.


  I don't quite follow here. 
               You seem to imply that nt/dur and rtp/dur are 2 different
things. 
               I thought both nt/dur and rtp/dur are the same thing w/the
same value. 
              If MG exposed nt, what should it return for duration - nt/dur
or rtp/dur? 


Do you know the intend of tdmc/os and tdmc/or? 
I thought the same as Madhubabu about how they are calculated. 
  
  
  
  


Brian 

-----Original Message----- 
From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com
 ] 
Sent: Tuesday, May 29, 2001 5:15 PM 
To: 'Chuong Nguyen' 
Cc: megaco@fore.com 
Subject: RE: Network Package
Hi chuong/all,IMO if PackageB extends PackageA and if one of the
statistic/property of Package A is not valid for termination realizing
packageB then there is no reason why PackageB extends PackageA. Then
PackageB shouldn't extend PackageA (just only to reuse few
properties/statistics) but should define the same properties (Might be with
different IDs) in packageB. I think the extension of packages is logical if
the newly defined package can inherit "all" the properties already defined
in the base package and also define new properties. In your example, I was
in the impression that "OS" and "OR" can be calculated as "The number of
octet sent or received is equal to the duration of the Termination, in
seconds, multiplied by the sampling frequency,  8000 Hz.". (Of course this
seems to be redundant info if the MGC is aware of the sampling frequency).
Isn't this the intention?????-RegardsMadhubabu 

-----Original Message----- 
From: owner-megaco@pit.comms.marconi.com [
mailto:owner-megaco@pit.comms.marconi.com
 ]On Behalf Of Chuong Nguyen 
Sent: Tuesday, May 29, 2001 4:38 PM 
To: megaco@fore.com 
Subject: Network Package
Hi All 
  

Is it reasonable to assume that Network Package StatisticsID will never be
used directly? 
That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os and rtp/or
respectiviely 
since rtp package extends nt package. 


I know that it is agreed that if a termination realizes rtp package, it also
realizes nt package 
and either nt/.. or rtp/.. are valid packageName. 


But if we allow, nt/... instead of rtp/.., are we saying that if MGC
receives nt/.., it has to 
know whether it is for rtp or tmcd termination by the terminationID? 
  


Furthermore, since tdmc package extends nt package, do "octet sent" (OS) and
"octet 
received" (OR) really apply to tdm termination? 


Also what does it mean for a TDM termination to realize the "NT" package
properties 
of "Maximum Jitter Buffer"? 


So a more general question, if a termination realizes a packageB that
extends 
packageA and there are items in the packageA that does not make sense to 
the termination what should MG/MGC do. 


Take the above as an example and assuming that it does not make sense for
TDM 
termination to have "OS" and "OR", what should MG return for TDM termination

statistics if the termination realizes "TDMC" package? 
Just "duration". 


--- 
Said it is valid to have "OS" and "OR" for TDM. 
IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP
termination, 
is it valid for MG to return nt/dur, nt/os and nt/or for the TDM termination
and RTP 
termination instead of tdmc/dur, ... vs rtp/dur ? 


Thanks 
Chuong 
  
  
  

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


------_=_NextPart_001_01C0E888.E69785A0
Content-Type: text/html;
	charset="iso-8859-1"









Well rtp/dur 
and nt/dur are "the same thing" in the sense that the mean the 
same


thing, but if 
you implement (expose) both packages, then they are 
"separate"


statistics.  Using Events is perhaps easier to 
understand.  Suppose Package A


implements 
event E1, and package B extends Package A, and a given 
implementation


exposes both 
A and B, such that an audit of termination T1 returns 
Packages{..A,B..}


 


You can say 
Add=T1{Events=123{B/E1}}


or you can 
say


Add=T1{Events=123{A/T1}}


or 
even


Add=T1{Events=123{A/T1,B/T1}}


 


In the 
latter, detection of the event would result in a notify of 
both.


 


Returning to 
statistics, the value would be the same, but they are 
separate


statistics.


 


Brian



  
-----Original Message-----
From: Chuong Nguyen 
  [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Tuesday, May 29, 2001 
  5:29 PM
To: megaco@fore.com
Subject: Re: Network 
  Package

"Rosen, Brian" wrote: 
  
If you implement any part of a package, you 
    implement all of it.If a package 
    extends any part of a package, it extends all of 
  it.

  
What is not 
    required is that if you implement a package that extendsanother package that you have to "expose" the 
    underlying package.This means that if 
    you implement rtp you don't have to expose nt.If you list nt as one of the packages in an audit, 
    then you have toimplement 
    nt/dur.

  

<cnn>  I don't quite follow here. 
  
               
  You seem to imply that nt/dur and rtp/dur are 2 different things. 
  
               
  I thought both nt/dur and rtp/dur are the same thing w/the same value. 
  
              
  If MG exposed nt, what should it return for duration - nt/dur or rtp/dur? 
  
Do you know the intend of tdmc/os and tdmc/or? 
I thought the same 
  as Madhubabu about how they are calculated. 
  
  
  
  
  
  
Brian 
    

      
-----Original Message----- 
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] 
      
Sent: Tuesday, May 29, 2001 
      5:15 PM 
To: 
      'Chuong Nguyen' 
Cc: megaco@fore.com 
Subject: RE: Network 
      Package
Hi chuong/all,IMO if PackageB extends PackageA and if one of 
      the statistic/property of Package A is not valid for termination realizing 
      packageB then there is no reason why PackageB extends PackageA. Then 
      PackageB shouldn't extend PackageA (just only to reuse few 
      properties/statistics) but should define the same properties (Might be 
      with different IDs) in packageB. I think the 
      extension of packages is logical if the newly defined package can inherit 
      "all" the properties already defined in the base package and also define 
      new properties. In your example, I was in the impression that 
      "OS" and "OR" can be calculated as "The number of octet sent or received 
      is equal to the duration of the Termination, in seconds, multiplied by the 
      sampling frequency,  8000 Hz.". (Of course this seems to be redundant 
      info if the MGC is aware of the sampling frequency). Isn't this the 
      intention?????-RegardsMadhubabu 
      

        
-----Original Message----- 
From: 
        owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On 
        Behalf Of Chuong Nguyen 
Sent: Tuesday, May 29, 2001 4:38 PM 
        
To: 
        megaco@fore.com 
Subject: Network Package
Hi All 
        
  
        
Is it reasonable to assume that Network Package StatisticsID will 
        never be used directly? 
That is nt/dur, nt/os and nt/or will 
        normally be rtp/dur, rtp/os and rtp/or respectiviely 
since rtp 
        package extends nt package. 
        
I know that it is agreed that if a termination realizes rtp package, 
        it also realizes nt package 
and either nt/.. or rtp/.. are valid 
        packageName. 
        
But if we allow, nt/... instead of rtp/.., are we saying that if MGC 
        receives nt/.., it has to 
know whether it is for rtp or tmcd 
        termination by the terminationID? 
  
        
Furthermore, since tdmc package extends nt package, do "octet sent" 
        (OS) and "octet 
received" (OR) really apply to tdm termination? 
        
Also what does it mean for a TDM termination to realize the "NT" 
        package properties 
of "Maximum Jitter Buffer"? 
        
So a more general question, if a termination realizes a packageB that 
        extends 
packageA and there are items in the packageA that does not 
        make sense to 
the termination what should MG/MGC do. 
        
Take the above as an example and assuming that it does not make sense 
        for TDM 
termination to have "OS" and "OR", what should MG return for 
        TDM termination 
statistics if the termination realizes "TDMC" 
        package? 
Just "duration". 
        
--- 
Said it is valid to have "OS" and "OR" for TDM. 
IF MGC 
        does a Subtract=* on a specific context w/1 TDM and 1 RTP termination, 
        
is it valid for MG to return nt/dur, nt/os and nt/or for the TDM 
        termination and RTP 
termination instead of tdmc/dur, ... vs rtp/dur 
        ? 
        
Thanks 
Chuong 
  
  
  
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
 
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  



------_=_NextPart_001_01C0E888.E69785A0--


From owner-megaco@fore.com  Tue May 29 19:09:27 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12524
	for ; Tue, 29 May 2001 19:09:27 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA20149;
	Tue, 29 May 2001 18:35:54 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA26555
	for megaco-list; Tue, 29 May 2001 18:16:37 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA26515
	for ; Tue, 29 May 2001 18:15:52 -0400 (EDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA19415
	for ; Tue, 29 May 2001 18:15:44 -0400 (EDT)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id RAA06398
	for ; Tue, 29 May 2001 17:15:34 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4TMFXT01915
	for ; Tue, 29 May 2001 17:15:33 -0500 (CDT)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4TMEx128081
	for ; Tue, 29 May 2001 17:14:59 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4TMExO24554
	for ; Tue, 29 May 2001 17:14:59 -0500 (CDT)
Message-ID: <3B141F63.3AB31744@usa.alcatel.com>
Date: Tue, 29 May 2001 17:14:59 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Network Package
References: <4FBEA8857476D311A03300204840E1CF04465499@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: multipart/alternative;
 boundary="------------ED17DE8563AF50A4F7D42416"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------ED17DE8563AF50A4F7D42416
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ok.  I follow you now but ....

IS this clearly stated somewhere?
This could be a nightmare for MGC to receive the same statistics value
via 2 different
parameter.  Talk about the overhead of parsing these text strings.

Can someone answer the question what does it mean for tdmc package to
extend nt package property of "Maximum Jitter Buffer"?

Thanks
Chuong


"Rosen, Brian" wrote:

> Well rtp/dur and nt/dur are "the same thing" in the sense that the
> mean the samething, but if you implement (expose) both packages, then
> they are "separate"statistics.  Using Events is perhaps easier to
> understand.  Suppose Package Aimplements event E1, and package B
> extends Package A, and a given implementationexposes both A and B,
> such that an audit of termination T1 returns Packages{..A,B..}You can
> say Add=T1{Events=123{B/E1}}or you can sayAdd=T1{Events=123{A/T1}}or
> evenAdd=T1{Events=123{A/T1,B/T1}}In the latter, detection of the event
> would result in a notify of both.Returning to statistics, the value
> would be the same, but they are separatestatistics.Brian
>
>      -----Original Message-----
>      From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
>      Sent: Tuesday, May 29, 2001 5:29 PM
>      To: megaco@fore.com
>      Subject: Re: Network Package
>      "Rosen, Brian" wrote:
>
>     > If you implement any part of a package, you implement all
>     > of it.If a package extends any part of a package, it
>     > extends all of it.
>
>     > What is not required is that if you implement a package
>     > that extendsanother package that you have to "expose" the
>     > underlying package.This means that if you implement rtp
>     > you don't have to expose nt.If you list nt as one of the
>     > packages in an audit, then you have toimplement nt/dur.
>
>
>        I don't quite follow here.
>                     You seem to imply that nt/dur and rtp/dur are
>      2 different things.
>                     I thought both nt/dur and rtp/dur are the
>      same thing w/the same value.
>                    If MG exposed nt, what should it return for
>      duration - nt/dur or rtp/dur?
>
>      Do you know the intend of tdmc/os and tdmc/or?
>      I thought the same as Madhubabu about how they are
>      calculated.
>
>
>
>
>
>     > Brian
>     >
>     >      -----Original Message-----
>     >      From: Madhu Babu Brahmanapally
>     >      [mailto:madhubabu@kenetec.com]
>     >      Sent: Tuesday, May 29, 2001 5:15 PM
>     >      To: 'Chuong Nguyen'
>     >      Cc: megaco@fore.com
>     >      Subject: RE: Network Package
>     >      Hi chuong/all,IMO if PackageB extends PackageA
>     >      and if one of the statistic/property of Package
>     >      A is not valid for termination realizing
>     >      packageB then there is no reason why PackageB
>     >      extends PackageA. Then PackageB shouldn't extend
>     >      PackageA (just only to reuse few
>     >      properties/statistics) but should define the
>     >      same properties (Might be with different IDs) in
>     >      packageB. I think the extension of packages is
>     >      logical if the newly defined package can inherit
>     >      "all" the properties already defined in the base
>     >      package and also define new properties. In your
>     >      example, I was in the impression that "OS" and
>     >      "OR" can be calculated as "The number of octet
>     >      sent or received is equal to the duration of the
>     >      Termination, in seconds, multiplied by the
>     >      sampling frequency,  8000 Hz.". (Of course this
>     >      seems to be redundant info if the MGC is aware
>     >      of the sampling frequency). Isn't this the
>     >      intention?????-RegardsMadhubabu
>     >
>     >           -----Original Message-----
>     >           From:
>     >           owner-megaco@pit.comms.marconi.com
>     >           [mailto:owner-megaco@pit.comms.marconi.com]On
>     >           Behalf Of Chuong Nguyen
>     >           Sent: Tuesday, May 29, 2001 4:38 PM
>     >           To: megaco@fore.com
>     >           Subject: Network Package
>     >           Hi All
>     >
>     >
>     >           Is it reasonable to assume that
>     >           Network Package StatisticsID will
>     >           never be used directly?
>     >           That is nt/dur, nt/os and nt/or will
>     >           normally be rtp/dur, rtp/os and rtp/or
>     >           respectiviely
>     >           since rtp package extends nt package.
>     >
>     >           I know that it is agreed that if a
>     >           termination realizes rtp package, it
>     >           also realizes nt package
>     >           and either nt/.. or rtp/.. are valid
>     >           packageName.
>     >
>     >           But if we allow, nt/... instead of
>     >           rtp/.., are we saying that if MGC
>     >           receives nt/.., it has to
>     >           know whether it is for rtp or tmcd
>     >           termination by the terminationID?
>     >
>     >
>     >           Furthermore, since tdmc package
>     >           extends nt package, do "octet sent"
>     >           (OS) and "octet
>     >           received" (OR) really apply to tdm
>     >           termination?
>     >
>     >           Also what does it mean for a TDM
>     >           termination to realize the "NT"
>     >           package properties
>     >           of "Maximum Jitter Buffer"?
>     >
>     >           So a more general question, if a
>     >           termination realizes a packageB that
>     >           extends
>     >           packageA and there are items in the
>     >           packageA that does not make sense to
>     >           the termination what should MG/MGC do.
>     >
>     >           Take the above as an example and
>     >           assuming that it does not make sense
>     >           for TDM
>     >           termination to have "OS" and "OR",
>     >           what should MG return for TDM
>     >           termination
>     >           statistics if the termination realizes
>     >           "TDMC" package?
>     >           Just "duration".
>     >
>     >           ---
>     >           Said it is valid to have "OS" and "OR"
>     >           for TDM.
>     >           IF MGC does a Subtract=* on a specific
>     >           context w/1 TDM and 1 RTP termination,
>     >
>     >           is it valid for MG to return nt/dur,
>     >           nt/os and nt/or for the TDM
>     >           termination and RTP
>     >           termination instead of tdmc/dur, ...
>     >           vs rtp/dur ?
>     >
>     >           Thanks
>     >           Chuong
>     >
>     >
>     >
>     >
>     >           --
>     >             Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>     >             1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>     >             **** The opinions expressed are not those of Alcatel USA, Inc ****
>     >
>     >
>     >
>      --
>        Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>        1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>        **** The opinions expressed are not those of Alcatel USA, Inc ****
>
>
>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------ED17DE8563AF50A4F7D42416
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Ok.  I follow you now but ....

IS this clearly stated somewhere?

This could be a nightmare for MGC to receive the same statistics value
via 2 different

parameter.  Talk about the overhead of parsing these text strings.

Can someone answer the question what does it mean for tdmc package
to

extend nt package property of "Maximum Jitter Buffer"?

Thanks

Chuong

 

"Rosen, Brian" wrote:

Well
rtp/dur and nt/dur are "the same thing" in the sense that the mean the
samething, but if you implement (expose)
both packages, then they are "separate"statistics. 
Using Events is perhaps easier to understand.  Suppose Package Aimplements
event E1, and package B extends Package A, and a given implementationexposes
both A and B, such that an audit of termination T1 returns Packages{..A,B..}You
can say Add=T1{Events=123{B/E1}}or
you can sayAdd=T1{Events=123{A/T1}}or
evenAdd=T1{Events=123{A/T1,B/T1}}In
the latter, detection of the event would result in a notify of both.Returning
to statistics, the value would be the same, but they are separatestatistics.Brian



-----Original
Message-----

From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]

Sent: Tuesday, May 29, 2001
5:29 PM

To: megaco@fore.com

Subject: Re: Network Package

"Rosen, Brian" wrote:

If
you implement any part of a package, you implement all of it.If
a package extends any part of a package, it extends all of it.



What
is not required is that if you implement a package that extendsanother
package that you have to "expose" the underlying package.This
means that if you implement rtp you don't have to expose nt.If
you list nt as one of the packages in an audit, then you have toimplement
nt/dur.




<cnn>  I don't quite follow here.

              
You seem to imply that nt/dur and rtp/dur are 2 different things.

              
I thought both nt/dur and rtp/dur are the same thing w/the same value.

             
If MG exposed nt, what should it return for duration - nt/dur or rtp/dur?

Do you know the intend of tdmc/os and tdmc/or?

I thought the same as Madhubabu about how they are calculated.

 

 

 

 

Brian



-----Original
Message-----

From: Madhu Babu Brahmanapally
[mailto:madhubabu@kenetec.com]

Sent: Tuesday, May 29, 2001
5:15 PM

To: 'Chuong Nguyen'

Cc: megaco@fore.com

Subject: RE: Network Package

Hi
chuong/all,IMO if PackageB
extends PackageA and if one of the statistic/property of Package A is not
valid for termination realizing packageB then there is no reason why PackageB
extends PackageA. Then PackageB shouldn't extend PackageA (just only to
reuse few properties/statistics) but should define the same properties
(Might be with different IDs) in packageB. I
think the extension of packages is logical if the newly defined package
can inherit "all" the properties already defined in the base package and
also define new properties. In
your example, I was in the impression that "OS" and "OR" can be calculated
as "The number of octet sent or received is equal to the duration of the
Termination, in seconds, multiplied by the sampling frequency,  8000
Hz.". (Of course this seems to be redundant info if the MGC is aware of
the sampling frequency). Isn't this the intention?????-RegardsMadhubabu



-----Original
Message-----

From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On
Behalf Of Chuong Nguyen

Sent: Tuesday, May 29, 2001
4:38 PM

To: megaco@fore.com

Subject: Network Package

Hi All

 

Is it reasonable to assume that Network Package StatisticsID will never
be used directly?

That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os and
rtp/or respectiviely

since rtp package extends nt package.

I know that it is agreed that if a termination realizes rtp package,
it also realizes nt package

and either nt/.. or rtp/.. are valid packageName.

But if we allow, nt/... instead of rtp/.., are we saying that if MGC
receives nt/.., it has to

know whether it is for rtp or tmcd termination by the terminationID?

 

Furthermore, since tdmc package extends nt package, do "octet sent"
(OS) and "octet

received" (OR) really apply to tdm termination?

Also what does it mean for a TDM termination to realize the "NT" package
properties

of "Maximum Jitter Buffer"?

So a more general question, if a termination realizes a packageB that
extends

packageA and there are items in the packageA that does not make sense
to

the termination what should MG/MGC do.

Take the above as an example and assuming that it does not make sense
for TDM

termination to have "OS" and "OR", what should MG return for TDM termination

statistics if the termination realizes "TDMC" package?

Just "duration".

---

Said it is valid to have "OS" and "OR" for TDM.

IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP termination,

is it valid for MG to return nt/dur, nt/os and nt/or for the TDM termination
and RTP

termination instead of tdmc/dur, ... vs rtp/dur ?

Thanks

Chuong

 

 

 

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 







-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 





-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------ED17DE8563AF50A4F7D42416--



From owner-megaco@fore.com  Tue May 29 20:12:23 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13035
	for ; Tue, 29 May 2001 20:12:23 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23032;
	Tue, 29 May 2001 20:02:38 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id TAA02439
	for megaco-list; Tue, 29 May 2001 19:19:19 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA02433
	for ; Tue, 29 May 2001 19:19:10 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA21624
	for ; Tue, 29 May 2001 19:19:08 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.124])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACP40584;
	Tue, 29 May 2001 19:16:08 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Rosen, Brian'" ,
        "'Chuong Nguyen'" , 
Subject: RE: Network Package
Date: Tue, 29 May 2001 19:19:15 -0400
Message-ID: <006c01c0e895$c7f5cdc0$c500a8c0@MBRAHMANAPALLY>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_006D_01C0E874.40E42DC0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <4FBEA8857476D311A03300204840E1CF04465499@whq-msgusr-02.pit.comms.marconi.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_006D_01C0E874.40E42DC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Brian/All,

Sorry for wrong information in my earlier mail.... Error code "456 -
Parameter or Property appears twice in this Descriptor" is present for
avoiding multiple instances of properties/parameters. If A/T1 and B/T1 mean
the same doesn't this fall into the above error category.

Regards
Madhubabu
  -----Original Message-----
  From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
  Sent: Tuesday, May 29, 2001 5:47 PM
  To: 'Chuong Nguyen'; megaco@fore.com
  Subject: RE: Network Package


  Well rtp/dur and nt/dur are "the same thing" in the sense that the mean
the same
  thing, but if you implement (expose) both packages, then they are
"separate"
  statistics.  Using Events is perhaps easier to understand.  Suppose
Package A
  implements event E1, and package B extends Package A, and a given
implementation
  exposes both A and B, such that an audit of termination T1 returns
Packages{..A,B..}

  You can say Add=T1{Events=123{B/E1}}
  or you can say
  Add=T1{Events=123{A/T1}}
  or even
  Add=T1{Events=123{A/T1,B/T1}}

  In the latter, detection of the event would result in a notify of both.

  Returning to statistics, the value would be the same, but they are
separate
  statistics.

  Brian
    -----Original Message-----
    From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
    Sent: Tuesday, May 29, 2001 5:29 PM
    To: megaco@fore.com
    Subject: Re: Network Package


    "Rosen, Brian" wrote:
      If you implement any part of a package, you implement all of it.If a
package extends any part of a package, it extends all of it.
      What is not required is that if you implement a package that
extendsanother package that you have to "expose" the underlying package.This
means that if you implement rtp you don't have to expose nt.If you list nt
as one of the packages in an audit, then you have toimplement nt/dur.

      I don't quite follow here.
                   You seem to imply that nt/dur and rtp/dur are 2 different
things.
                   I thought both nt/dur and rtp/dur are the same thing
w/the same value.
                  If MG exposed nt, what should it return for duration -
nt/dur or rtp/dur?

    Do you know the intend of tdmc/os and tdmc/or?
    I thought the same as Madhubabu about how they are calculated.





      Brian
        -----Original Message-----
        From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
        Sent: Tuesday, May 29, 2001 5:15 PM
        To: 'Chuong Nguyen'
        Cc: megaco@fore.com
        Subject: RE: Network Package
        Hi chuong/all,IMO if PackageB extends PackageA and if one of the
statistic/property of Package A is not valid for termination realizing
packageB then there is no reason why PackageB extends PackageA. Then
PackageB shouldn't extend PackageA (just only to reuse few
properties/statistics) but should define the same properties (Might be with
different IDs) in packageB. I think the extension of packages is logical if
the newly defined package can inherit "all" the properties already defined
in the base package and also define new properties. In your example, I was
in the impression that "OS" and "OR" can be calculated as "The number of
octet sent or received is equal to the duration of the Termination, in
seconds, multiplied by the sampling frequency,  8000 Hz.". (Of course this
seems to be redundant info if the MGC is aware of the sampling frequency).
Isn't this the intention?????-RegardsMadhubabu
          -----Original Message-----
          From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Chuong Nguyen
          Sent: Tuesday, May 29, 2001 4:38 PM
          To: megaco@fore.com
          Subject: Network Package
          Hi All

          Is it reasonable to assume that Network Package StatisticsID will
never be used directly?
          That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os
and rtp/or respectiviely
          since rtp package extends nt package.

          I know that it is agreed that if a termination realizes rtp
package, it also realizes nt package
          and either nt/.. or rtp/.. are valid packageName.

          But if we allow, nt/... instead of rtp/.., are we saying that if
MGC receives nt/.., it has to
          know whether it is for rtp or tmcd termination by the
terminationID?


          Furthermore, since tdmc package extends nt package, do "octet
sent" (OS) and "octet
          received" (OR) really apply to tdm termination?

          Also what does it mean for a TDM termination to realize the "NT"
package properties
          of "Maximum Jitter Buffer"?

          So a more general question, if a termination realizes a packageB
that extends
          packageA and there are items in the packageA that does not make
sense to
          the termination what should MG/MGC do.

          Take the above as an example and assuming that it does not make
sense for TDM
          termination to have "OS" and "OR", what should MG return for TDM
termination
          statistics if the termination realizes "TDMC" package?
          Just "duration".

          ---
          Said it is valid to have "OS" and "OR" for TDM.
          IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP
termination,
          is it valid for MG to return nt/dur, nt/os and nt/or for the TDM
termination and RTP
          termination instead of tdmc/dur, ... vs rtp/dur ?

          Thanks
          Chuong




--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****


------=_NextPart_000_006D_01C0E874.40E42DC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Brian/All,


 


Sorry=20
for wrong information in my earlier mail.... Error code "456 - Parameter =
or=20
Property appears twice in this Descriptor" is present for avoiding =
multiple=20
instances of properties/parameters. If A/T1 and B/T1 =
mean the same=20
doesn't this fall into the above error category. 


 


Regards


Madhubabu



  
-----Original Message-----
From:=20
  owner-megaco@pit.comms.marconi.com=20
  [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen,=20
  Brian
Sent: Tuesday, May 29, 2001 5:47 PM
To: =
'Chuong=20
  Nguyen'; megaco@fore.com
Subject: RE: Network=20
  Package


  
Well=20
  rtp/dur and nt/dur are "the same thing" in the sense that the mean the =

  same

  
thing, but=20
  if you implement (expose) both packages, then they are=20
  "separate"

  
statistics.  Using Events is perhaps easier to=20
  understand.  Suppose Package A

  
implements=20
  event E1, and package B extends Package A, and a given=20
  implementation

  
exposes=20
  both A and B, such that an audit of termination T1 returns=20
  Packages{..A,B..}

  
 

  
You can say=20
  Add=3DT1{Events=3D123{B/E1}}

  
or you can=20
  say

  
Add=3DT1{Events=3D123{A/T1}}

  
or=20
  even

  
Add=3DT1{Events=3D123{A/T1,B/T1}}

  
 

  
In the=20
  latter, detection of the event would result in a notify of=20
  both.

  
 

  
Returning=20
  to statistics, the value would be the same, but they are=20
  separate

  
statistics.

  
 

  
Brian

  
    
-----Original Message-----
From: Chuong Nguyen=20
    [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Tuesday, May =
29, 2001=20
    5:29 PM
To: megaco@fore.com
Subject: Re: Network =

    Package

"Rosen, Brian" wrote:=20
    
If you implement any part of a =
package, you=20
      implement all of it.If a =
package=20
      extends any part of a package, it extends all of=20
    it.

    
What is not=20
      required is that if you implement a package that =
extendsanother package that you have to =
"expose" the=20
      underlying package.This =
means that=20
      if you implement rtp you don't have to expose nt.If you list nt as one of the packages =
in an=20
      audit, then you have toimplement=20
      nt/dur.

    

<cnn>  I don't quite follow here.=20
    =

           &nb=
sp;  =20
    You seem to imply that nt/dur and rtp/dur are 2 different things.=20
    =

           &nb=
sp;  =20
    I thought both nt/dur and rtp/dur are the same thing w/the same =
value.=20
    =

           &nb=
sp; =20
    If MG exposed nt, what should it return for duration - nt/dur or =
rtp/dur?=20
    
Do you know the intend of tdmc/os and tdmc/or? 
I thought =
the=20
    same as Madhubabu about how they are calculated. 
  =

 =20
    
  
 =20
    
Brian=20
      

        
-----Original Message----- 
From: Madhu Babu =
Brahmanapally [mailto:madhubabu@kenetec.com]=20
        
Sent: Tuesday, =
May 29, 2001=20
        5:15 PM 
To:=20
        'Chuong Nguyen' 
Cc: megaco@fore.com 
Subject: RE: Network=20
        Package
Hi =
chuong/all,IMO if PackageB extends PackageA and =
if one of=20
        the statistic/property of Package A is not valid for termination =

        realizing packageB then there is no reason why PackageB extends=20
        PackageA. Then PackageB shouldn't extend PackageA (just only to =
reuse=20
        few properties/statistics) but should define the same properties =
(Might=20
        be with different IDs) in packageB. I think=20
        the extension of packages is logical if the newly defined =
package can=20
        inherit "all" the properties already defined in the base package =
and=20
        also define new properties. In your=20
        example, I was in the impression that "OS" and "OR" can be =
calculated as=20
        "The number of octet sent or received is equal to the duration =
of the=20
        Termination, in seconds, multiplied by the sampling =
frequency, =20
        8000 Hz.". (Of course this seems to be redundant info if the MGC =
is=20
        aware of the sampling frequency). Isn't this the=20
        intention?????-RegardsMadhubabu =

        

          
-----Original Message----- 
From:=20
          owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pi=
t.comms.marconi.com]On=20
          Behalf Of Chuong Nguyen 
Sent: Tuesday, May 29, 2001 4:38 =
PM=20
          
To:=20
          megaco@fore.com 
Subject: Network =
Package
Hi All=20
          
 =20
          
Is it reasonable to assume that Network Package =
StatisticsID will=20
          never be used directly? 
That is nt/dur, nt/os and nt/or =
will=20
          normally be rtp/dur, rtp/os and rtp/or respectiviely 
since =
rtp=20
          package extends nt package.=20
          
I know that it is agreed that if a termination realizes rtp =

          package, it also realizes nt package 
and either nt/.. or =
rtp/..=20
          are valid packageName.=20
          
But if we allow, nt/... instead of rtp/.., are we saying =
that if=20
          MGC receives nt/.., it has to 
know whether it is for rtp =
or tmcd=20
          termination by the terminationID? 
 =20
          
Furthermore, since tdmc package extends nt package, do =
"octet sent"=20
          (OS) and "octet 
received" (OR) really apply to tdm =
termination?=20
          
Also what does it mean for a TDM termination to realize the =
"NT"=20
          package properties 
of "Maximum Jitter Buffer"?=20
          
So a more general question, if a termination realizes a =
packageB=20
          that extends 
packageA and there are items in the packageA =
that=20
          does not make sense to 
the termination what should MG/MGC =
do.=20
          
Take the above as an example and assuming that it does not =
make=20
          sense for TDM 
termination to have "OS" and "OR", what =
should MG=20
          return for TDM termination 
statistics if the termination =
realizes=20
          "TDMC" package? 
Just "duration".=20
          
--- 
Said it is valid to have "OS" and "OR" for TDM. =

IF MGC=20
          does a Subtract=3D* on a specific context w/1 TDM and 1 RTP =
termination,=20
          
is it valid for MG to return nt/dur, nt/os and nt/or for =
the TDM=20
          termination and RTP 
termination instead of tdmc/dur, ... =
vs=20
          rtp/dur ?=20
          
Thanks 
Chuong 
  
  
  =

-- 
  Alcatel USA, =
Inc           &nbs=
p; Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas =
75075           =
Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc =
****
 
-- 
  Alcatel USA, =
Inc           &nbs=
p; Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas =
75075           =
Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc =
****
 =20
  


------=_NextPart_000_006D_01C0E874.40E42DC0--



From owner-megaco@fore.com  Tue May 29 20:49:31 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13312
	for ; Tue, 29 May 2001 20:49:30 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA24741;
	Tue, 29 May 2001 20:38:17 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id TAA02047
	for megaco-list; Tue, 29 May 2001 19:12:36 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA02043
	for ; Tue, 29 May 2001 19:12:35 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA21426
	for ; Tue, 29 May 2001 19:12:33 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.124])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACP40562;
	Tue, 29 May 2001 19:08:49 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Rosen, Brian'" ,
        "'Chuong Nguyen'" , 
Subject: RE: Network Package
Date: Tue, 29 May 2001 19:11:57 -0400
Message-ID: <006701c0e894$c2a5bf20$c500a8c0@MBRAHMANAPALLY>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0068_01C0E873.3B941F20"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <4FBEA8857476D311A03300204840E1CF04465499@whq-msgusr-02.pit.comms.marconi.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0068_01C0E873.3B941F20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

HI Brian/all,

In your example A/T1 and B/T1 actually mean to the MG for reporting of the
same event(I.e T1). But I think generating two notifies for this purpose is
unnecessary and doesn't carry any extra information. I think the reporting
should be either A/T1 or B/T1 as both mean the same. If they mean the same
why to provide redundant information to MGC???

Lets say a event descriptor has Events=123{A/a1, A/a1} (grammar allows this
and there is no statement restricting multiple occurrence of the same event)
does this leads to reporting of two Notifies from the MG?????? IMHO
reporting of single event is enough.

Related query: Is it valid to have multiple occurrence of the same signal/
event or properties in any of the descriptors ????


-Regards
Madhubabu
  -----Original Message-----
  From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
  Sent: Tuesday, May 29, 2001 5:47 PM
  To: 'Chuong Nguyen'; megaco@fore.com
  Subject: RE: Network Package


  Well rtp/dur and nt/dur are "the same thing" in the sense that the mean
the same
  thing, but if you implement (expose) both packages, then they are
"separate"
  statistics.  Using Events is perhaps easier to understand.  Suppose
Package A
  implements event E1, and package B extends Package A, and a given
implementation
  exposes both A and B, such that an audit of termination T1 returns
Packages{..A,B..}

  You can say Add=T1{Events=123{B/E1}}
  or you can say
  Add=T1{Events=123{A/T1}}
  or even
  Add=T1{Events=123{A/T1,B/T1}}

  In the latter, detection of the event would result in a notify of both.

  Returning to statistics, the value would be the same, but they are
separate
  statistics.

  Brian
    -----Original Message-----
    From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
    Sent: Tuesday, May 29, 2001 5:29 PM
    To: megaco@fore.com
    Subject: Re: Network Package


    "Rosen, Brian" wrote:
      If you implement any part of a package, you implement all of it.If a
package extends any part of a package, it extends all of it.
      What is not required is that if you implement a package that
extendsanother package that you have to "expose" the underlying package.This
means that if you implement rtp you don't have to expose nt.If you list nt
as one of the packages in an audit, then you have toimplement nt/dur.

      I don't quite follow here.
                   You seem to imply that nt/dur and rtp/dur are 2 different
things.
                   I thought both nt/dur and rtp/dur are the same thing
w/the same value.
                  If MG exposed nt, what should it return for duration -
nt/dur or rtp/dur?

    Do you know the intend of tdmc/os and tdmc/or?
    I thought the same as Madhubabu about how they are calculated.





      Brian
        -----Original Message-----
        From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
        Sent: Tuesday, May 29, 2001 5:15 PM
        To: 'Chuong Nguyen'
        Cc: megaco@fore.com
        Subject: RE: Network Package
        Hi chuong/all,IMO if PackageB extends PackageA and if one of the
statistic/property of Package A is not valid for termination realizing
packageB then there is no reason why PackageB extends PackageA. Then
PackageB shouldn't extend PackageA (just only to reuse few
properties/statistics) but should define the same properties (Might be with
different IDs) in packageB. I think the extension of packages is logical if
the newly defined package can inherit "all" the properties already defined
in the base package and also define new properties. In your example, I was
in the impression that "OS" and "OR" can be calculated as "The number of
octet sent or received is equal to the duration of the Termination, in
seconds, multiplied by the sampling frequency,  8000 Hz.". (Of course this
seems to be redundant info if the MGC is aware of the sampling frequency).
Isn't this the intention?????-RegardsMadhubabu
          -----Original Message-----
          From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Chuong Nguyen
          Sent: Tuesday, May 29, 2001 4:38 PM
          To: megaco@fore.com
          Subject: Network Package
          Hi All

          Is it reasonable to assume that Network Package StatisticsID will
never be used directly?
          That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os
and rtp/or respectiviely
          since rtp package extends nt package.

          I know that it is agreed that if a termination realizes rtp
package, it also realizes nt package
          and either nt/.. or rtp/.. are valid packageName.

          But if we allow, nt/... instead of rtp/.., are we saying that if
MGC receives nt/.., it has to
          know whether it is for rtp or tmcd termination by the
terminationID?


          Furthermore, since tdmc package extends nt package, do "octet
sent" (OS) and "octet
          received" (OR) really apply to tdm termination?

          Also what does it mean for a TDM termination to realize the "NT"
package properties
          of "Maximum Jitter Buffer"?

          So a more general question, if a termination realizes a packageB
that extends
          packageA and there are items in the packageA that does not make
sense to
          the termination what should MG/MGC do.

          Take the above as an example and assuming that it does not make
sense for TDM
          termination to have "OS" and "OR", what should MG return for TDM
termination
          statistics if the termination realizes "TDMC" package?
          Just "duration".

          ---
          Said it is valid to have "OS" and "OR" for TDM.
          IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP
termination,
          is it valid for MG to return nt/dur, nt/os and nt/or for the TDM
termination and RTP
          termination instead of tdmc/dur, ... vs rtp/dur ?

          Thanks
          Chuong




--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****


------=_NextPart_000_0068_01C0E873.3B941F20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









HI=20
Brian/all,


 


In=20
your example A/T1 and B/T1 actually mean to the MG for reporting of the =
same=20
event(I.e T1). But I think generating two notifies for this purpose is=20
unnecessary and doesn't carry any extra information. I think the =
reporting=20
should be either A/T1 or B/T1 as both mean the same. If they mean the =
same why=20
to provide redundant information to MGC???


 


Lets=20
say a event descriptor has Events=3D123{A/a1, A/a1} (grammar allows this =
and there=20
is no statement restricting multiple occurrence of the same event) does =
this=20
leads to reporting of two Notifies from the MG?????? IMHO reporting of=20
single event is enough. 


 


Related query: Is it valid =
to have=20
multiple occurrence of the same signal/ event or properties in any of =
the=20
descriptors ????


 


 


-Regards


Madhubabu



  
-----Original Message-----
From:=20
  owner-megaco@pit.comms.marconi.com=20
  [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen,=20
  Brian
Sent: Tuesday, May 29, 2001 5:47 PM
To: =
'Chuong=20
  Nguyen'; megaco@fore.com
Subject: RE: Network=20
  Package


  
Well=20
  rtp/dur and nt/dur are "the same thing" in the sense that the mean the =

  same

  
thing, but=20
  if you implement (expose) both packages, then they are=20
  "separate"

  
statistics.  Using Events is perhaps easier to=20
  understand.  Suppose Package A

  
implements=20
  event E1, and package B extends Package A, and a given=20
  implementation

  
exposes=20
  both A and B, such that an audit of termination T1 returns=20
  Packages{..A,B..}

  
 

  
You can say=20
  Add=3DT1{Events=3D123{B/E1}}

  
or you can=20
  say

  
Add=3DT1{Events=3D123{A/T1}}

  
or=20
  even

  
Add=3DT1{Events=3D123{A/T1,B/T1}}

  
 

  
In the=20
  latter, detection of the event would result in a notify of=20
  both.

  
 

  
Returning=20
  to statistics, the value would be the same, but they are=20
  separate

  
statistics.

  
 

  
Brian

  
    
-----Original Message-----
From: Chuong Nguyen=20
    [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Tuesday, May =
29, 2001=20
    5:29 PM
To: megaco@fore.com
Subject: Re: Network =

    Package

"Rosen, Brian" wrote:=20
    
If you implement any part of a =
package, you=20
      implement all of it.If a =
package=20
      extends any part of a package, it extends all of=20
    it.

    
What is not=20
      required is that if you implement a package that =
extendsanother package that you have to =
"expose" the=20
      underlying package.This =
means that=20
      if you implement rtp you don't have to expose nt.If you list nt as one of the packages =
in an=20
      audit, then you have toimplement=20
      nt/dur.

    

<cnn>  I don't quite follow here.=20
    =

           &nb=
sp;  =20
    You seem to imply that nt/dur and rtp/dur are 2 different things.=20
    =

           &nb=
sp;  =20
    I thought both nt/dur and rtp/dur are the same thing w/the same =
value.=20
    =

           &nb=
sp; =20
    If MG exposed nt, what should it return for duration - nt/dur or =
rtp/dur?=20
    
Do you know the intend of tdmc/os and tdmc/or? 
I thought =
the=20
    same as Madhubabu about how they are calculated. 
  =

 =20
    
  
 =20
    
Brian=20
      

        
-----Original Message----- 
From: Madhu Babu =
Brahmanapally [mailto:madhubabu@kenetec.com]=20
        
Sent: Tuesday, =
May 29, 2001=20
        5:15 PM 
To:=20
        'Chuong Nguyen' 
Cc: megaco@fore.com 
Subject: RE: Network=20
        Package
Hi =
chuong/all,IMO if PackageB extends PackageA and =
if one of=20
        the statistic/property of Package A is not valid for termination =

        realizing packageB then there is no reason why PackageB extends=20
        PackageA. Then PackageB shouldn't extend PackageA (just only to =
reuse=20
        few properties/statistics) but should define the same properties =
(Might=20
        be with different IDs) in packageB. I think=20
        the extension of packages is logical if the newly defined =
package can=20
        inherit "all" the properties already defined in the base package =
and=20
        also define new properties. In your=20
        example, I was in the impression that "OS" and "OR" can be =
calculated as=20
        "The number of octet sent or received is equal to the duration =
of the=20
        Termination, in seconds, multiplied by the sampling =
frequency, =20
        8000 Hz.". (Of course this seems to be redundant info if the MGC =
is=20
        aware of the sampling frequency). Isn't this the=20
        intention?????-RegardsMadhubabu =

        

          
-----Original Message----- 
From:=20
          owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pi=
t.comms.marconi.com]On=20
          Behalf Of Chuong Nguyen 
Sent: Tuesday, May 29, 2001 4:38 =
PM=20
          
To:=20
          megaco@fore.com 
Subject: Network =
Package
Hi All=20
          
 =20
          
Is it reasonable to assume that Network Package =
StatisticsID will=20
          never be used directly? 
That is nt/dur, nt/os and nt/or =
will=20
          normally be rtp/dur, rtp/os and rtp/or respectiviely 
since =
rtp=20
          package extends nt package.=20
          
I know that it is agreed that if a termination realizes rtp =

          package, it also realizes nt package 
and either nt/.. or =
rtp/..=20
          are valid packageName.=20
          
But if we allow, nt/... instead of rtp/.., are we saying =
that if=20
          MGC receives nt/.., it has to 
know whether it is for rtp =
or tmcd=20
          termination by the terminationID? 
 =20
          
Furthermore, since tdmc package extends nt package, do =
"octet sent"=20
          (OS) and "octet 
received" (OR) really apply to tdm =
termination?=20
          
Also what does it mean for a TDM termination to realize the =
"NT"=20
          package properties 
of "Maximum Jitter Buffer"?=20
          
So a more general question, if a termination realizes a =
packageB=20
          that extends 
packageA and there are items in the packageA =
that=20
          does not make sense to 
the termination what should MG/MGC =
do.=20
          
Take the above as an example and assuming that it does not =
make=20
          sense for TDM 
termination to have "OS" and "OR", what =
should MG=20
          return for TDM termination 
statistics if the termination =
realizes=20
          "TDMC" package? 
Just "duration".=20
          
--- 
Said it is valid to have "OS" and "OR" for TDM. =

IF MGC=20
          does a Subtract=3D* on a specific context w/1 TDM and 1 RTP =
termination,=20
          
is it valid for MG to return nt/dur, nt/os and nt/or for =
the TDM=20
          termination and RTP 
termination instead of tdmc/dur, ... =
vs=20
          rtp/dur ?=20
          
Thanks 
Chuong 
  
  
  =

-- 
  Alcatel USA, =
Inc           &nbs=
p; Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas =
75075           =
Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc =
****
 
-- 
  Alcatel USA, =
Inc           &nbs=
p; Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas =
75075           =
Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc =
****
 =20
  


------=_NextPart_000_0068_01C0E873.3B941F20--



From owner-megaco@fore.com  Tue May 29 21:30:44 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13675
	for ; Tue, 29 May 2001 21:30:44 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA26336;
	Tue, 29 May 2001 21:23:57 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA12684
	for megaco-list; Tue, 29 May 2001 21:22:47 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA12674
	for ; Tue, 29 May 2001 21:22:45 -0400 (EDT)
Received: from Mitel.COM ([216.191.234.101])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA26168
	for ; Tue, 29 May 2001 21:22:43 -0400 (EDT)
Received: from rndex50.software.mitel.com (rndex50 [134.199.17.160]) 
	by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id VAA26217;
	Tue, 29 May 2001 21:19:27 -0400 (EDT)
Received: by rndex50.kanata.mitel.com with Internet Mail Service (5.5.2448.0)
	id ; Tue, 29 May 2001 21:19:45 -0400
Message-ID: <9D6A470BD38ED311908000805F65B4EC04AE0931@rndex50.kanata.mitel.com>
From: "Blatherwick, Peter" 
To: "'Madhu Babu Brahmanapally'" ,
        "'Rosen, Brian'"
	 ,
        "'Chuong Nguyen'"
	 , megaco@fore.com
Subject: RE: Network Package
Date: Tue, 29 May 2001 21:19:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

See below, [PB] comments..  -- Peter

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: May 29, 2001 19:12
To: 'Rosen, Brian'; 'Chuong Nguyen'; megaco@fore.com
Subject: RE: Network Package


HI Brian/all,
 
In your example A/T1 and B/T1 actually mean to the MG for reporting of the same event(I.e T1). But I think generating two notifies for this purpose is unnecessary and doesn't carry any extra information. I think the reporting should be either A/T1 or B/T1 as both mean the same. If they mean the same why to provide redundant information to MGC??? 

[PB] No, if the MGC asks for both events A/T1 and B/T1, it should receive both when they occur (assuming both are exposed by the MG of course).  That's what the MGC asked for, and its in charge.   I agree this is redundant (actually likely the same physical event underlies both in general).  More complex to implement special case handling than to just do what was asked by the MGC.  

Lets say a event descriptor has Events=123{A/a1, A/a1} (grammar allows this and there is no statement restricting multiple occurrence of the same event) does this leads to reporting of two Notifies from the MG?????? IMHO reporting of single event is enough.  

[PB] This on is less clear, but I still believe MG should report both.  I see no harm, and likely more simplicity in MG design, to return both.  Again, if the MGC did not want both, it should not ask for both.   

Related query: Is it valid to have multiple occurrence of the same signal/ event or properties in any of the descriptors ????

[PB] As above, I see no reason why not.  Same logic applies.  (I have not double checked the syntax to verify this is actually allowed though...)

 
-Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Tuesday, May 29, 2001 5:47 PM
To: 'Chuong Nguyen'; megaco@fore.com
Subject: RE: Network Package


Well rtp/dur and nt/dur are "the same thing" in the sense that the mean the same
thing, but if you implement (expose) both packages, then they are "separate"
statistics.  Using Events is perhaps easier to understand.  Suppose Package A
implements event E1, and package B extends Package A, and a given implementation
exposes both A and B, such that an audit of termination T1 returns Packages{..A,B..}
 
You can say Add=T1{Events=123{B/E1}}
or you can say
Add=T1{Events=123{A/T1}}
or even
Add=T1{Events=123{A/T1,B/T1}}
 
In the latter, detection of the event would result in a notify of both.
 
Returning to statistics, the value would be the same, but they are separate
statistics.
 
Brian

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Tuesday, May 29, 2001 5:29 PM
To: megaco@fore.com
Subject: Re: Network Package


"Rosen, Brian" wrote: 

If you implement any part of a package, you implement all of it.If a package extends any part of a package, it extends all of it.

What is not required is that if you implement a package that extendsanother package that you have to "expose" the underlying package.This means that if you implement rtp you don't have to expose nt.If you list nt as one of the packages in an audit, then you have toimplement nt/dur.


  I don't quite follow here. 
               You seem to imply that nt/dur and rtp/dur are 2 different things. 
               I thought both nt/dur and rtp/dur are the same thing w/the same value. 
              If MG exposed nt, what should it return for duration - nt/dur or rtp/dur? 


Do you know the intend of tdmc/os and tdmc/or? 
I thought the same as Madhubabu about how they are calculated. 
  
  
  
  


Brian 

-----Original Message----- 
From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com  ] 
Sent: Tuesday, May 29, 2001 5:15 PM 
To: 'Chuong Nguyen' 
Cc: megaco@fore.com 
Subject: RE: Network Package
Hi chuong/all,IMO if PackageB extends PackageA and if one of the statistic/property of Package A is not valid for termination realizing packageB then there is no reason why PackageB extends PackageA. Then PackageB shouldn't extend PackageA (just only to reuse few properties/statistics) but should define the same properties (Might be with different IDs) in packageB. I think the extension of packages is logical if the newly defined package can inherit "all" the properties already defined in the base package and also define new properties. In your example, I was in the impression that "OS" and "OR" can be calculated as "The number of octet sent or received is equal to the duration of the Termination, in seconds, multiplied by the sampling frequency,  8000 Hz.". (Of course this seems to be redundant info if the MGC is aware of the sampling frequency). Isn't this the intention?????-RegardsMadhubabu 

-----Original Message----- 
From: owner-megaco@pit.comms.marconi.com [ mailto:owner-megaco@pit.comms.marconi.com  ]On Behalf Of Chuong Nguyen 
Sent: Tuesday, May 29, 2001 4:38 PM 
To: megaco@fore.com 
Subject: Network Package
Hi All 
  

Is it reasonable to assume that Network Package StatisticsID will never be used directly? 
That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os and rtp/or respectiviely 
since rtp package extends nt package. 


I know that it is agreed that if a termination realizes rtp package, it also realizes nt package 
and either nt/.. or rtp/.. are valid packageName. 


But if we allow, nt/... instead of rtp/.., are we saying that if MGC receives nt/.., it has to 
know whether it is for rtp or tmcd termination by the terminationID? 
  


Furthermore, since tdmc package extends nt package, do "octet sent" (OS) and "octet 
received" (OR) really apply to tdm termination? 


Also what does it mean for a TDM termination to realize the "NT" package properties 
of "Maximum Jitter Buffer"? 


So a more general question, if a termination realizes a packageB that extends 
packageA and there are items in the packageA that does not make sense to 
the termination what should MG/MGC do. 


Take the above as an example and assuming that it does not make sense for TDM 
termination to have "OS" and "OR", what should MG return for TDM termination 
statistics if the termination realizes "TDMC" package? 
Just "duration". 


--- 
Said it is valid to have "OS" and "OR" for TDM. 
IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP termination, 
is it valid for MG to return nt/dur, nt/os and nt/or for the TDM termination and RTP 
termination instead of tdmc/dur, ... vs rtp/dur ? 


Thanks 
Chuong 
  
  
  

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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



From owner-megaco@fore.com  Tue May 29 21:33:39 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13819
	for ; Tue, 29 May 2001 21:33:38 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA26294;
	Tue, 29 May 2001 21:23:43 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA12685
	for megaco-list; Tue, 29 May 2001 21:22:47 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA12678
	for ; Tue, 29 May 2001 21:22:46 -0400 (EDT)
Received: from Mitel.COM ([216.191.234.101])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA26169
	for ; Tue, 29 May 2001 21:22:43 -0400 (EDT)
Received: from rndex50.software.mitel.com (rndex50 [134.199.17.160]) 
	by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id VAA26307;
	Tue, 29 May 2001 21:21:58 -0400 (EDT)
Received: by rndex50.kanata.mitel.com with Internet Mail Service (5.5.2448.0)
	id ; Tue, 29 May 2001 21:22:16 -0400
Message-ID: <9D6A470BD38ED311908000805F65B4EC04AE0932@rndex50.kanata.mitel.com>
From: "Blatherwick, Peter" 
To: "'Madhu Babu Brahmanapally'" ,
        "'Rosen, Brian'"
	 ,
        "'Chuong Nguyen'"
	 , megaco@fore.com
Subject: RE: Network Package
Date: Tue, 29 May 2001 21:22:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

As in previous e-mail, just sent, I don't believe the below error should apply to the case of MGC requesting both A/T1 and B/T1.   MG is simply responding to the request.   May be a better case for using this if the request is for A/T1 and A/T1, but I still don't think so.  MG simply does as its told.  
-- Peter

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: May 29, 2001 19:19
To: 'Rosen, Brian'; 'Chuong Nguyen'; megaco@fore.com
Subject: RE: Network Package


Brian/All,
 
Sorry for wrong information in my earlier mail.... Error code "456 - Parameter or Property appears twice in this Descriptor" is present for avoiding multiple instances of properties/parameters. If A/T1 and B/T1 mean the same doesn't this fall into the above error category. 
 
Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Tuesday, May 29, 2001 5:47 PM
To: 'Chuong Nguyen'; megaco@fore.com
Subject: RE: Network Package


Well rtp/dur and nt/dur are "the same thing" in the sense that the mean the same
thing, but if you implement (expose) both packages, then they are "separate"
statistics.  Using Events is perhaps easier to understand.  Suppose Package A
implements event E1, and package B extends Package A, and a given implementation
exposes both A and B, such that an audit of termination T1 returns Packages{..A,B..}
 
You can say Add=T1{Events=123{B/E1}}
or you can say
Add=T1{Events=123{A/T1}}
or even
Add=T1{Events=123{A/T1,B/T1}}
 
In the latter, detection of the event would result in a notify of both.
 
Returning to statistics, the value would be the same, but they are separate
statistics.
 
Brian

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Tuesday, May 29, 2001 5:29 PM
To: megaco@fore.com
Subject: Re: Network Package


"Rosen, Brian" wrote: 

If you implement any part of a package, you implement all of it.If a package extends any part of a package, it extends all of it.

What is not required is that if you implement a package that extendsanother package that you have to "expose" the underlying package.This means that if you implement rtp you don't have to expose nt.If you list nt as one of the packages in an audit, then you have toimplement nt/dur.


  I don't quite follow here. 
               You seem to imply that nt/dur and rtp/dur are 2 different things. 
               I thought both nt/dur and rtp/dur are the same thing w/the same value. 
              If MG exposed nt, what should it return for duration - nt/dur or rtp/dur? 


Do you know the intend of tdmc/os and tdmc/or? 
I thought the same as Madhubabu about how they are calculated. 
  
  
  
  


Brian 

-----Original Message----- 
From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com  ] 
Sent: Tuesday, May 29, 2001 5:15 PM 
To: 'Chuong Nguyen' 
Cc: megaco@fore.com 
Subject: RE: Network Package
Hi chuong/all,IMO if PackageB extends PackageA and if one of the statistic/property of Package A is not valid for termination realizing packageB then there is no reason why PackageB extends PackageA. Then PackageB shouldn't extend PackageA (just only to reuse few properties/statistics) but should define the same properties (Might be with different IDs) in packageB. I think the extension of packages is logical if the newly defined package can inherit "all" the properties already defined in the base package and also define new properties. In your example, I was in the impression that "OS" and "OR" can be calculated as "The number of octet sent or received is equal to the duration of the Termination, in seconds, multiplied by the sampling frequency,  8000 Hz.". (Of course this seems to be redundant info if the MGC is aware of the sampling frequency). Isn't this the intention?????-RegardsMadhubabu 

-----Original Message----- 
From: owner-megaco@pit.comms.marconi.com [ mailto:owner-megaco@pit.comms.marconi.com  ]On Behalf Of Chuong Nguyen 
Sent: Tuesday, May 29, 2001 4:38 PM 
To: megaco@fore.com 
Subject: Network Package
Hi All 
  

Is it reasonable to assume that Network Package StatisticsID will never be used directly? 
That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os and rtp/or respectiviely 
since rtp package extends nt package. 


I know that it is agreed that if a termination realizes rtp package, it also realizes nt package 
and either nt/.. or rtp/.. are valid packageName. 


But if we allow, nt/... instead of rtp/.., are we saying that if MGC receives nt/.., it has to 
know whether it is for rtp or tmcd termination by the terminationID? 
  


Furthermore, since tdmc package extends nt package, do "octet sent" (OS) and "octet 
received" (OR) really apply to tdm termination? 


Also what does it mean for a TDM termination to realize the "NT" package properties 
of "Maximum Jitter Buffer"? 


So a more general question, if a termination realizes a packageB that extends 
packageA and there are items in the packageA that does not make sense to 
the termination what should MG/MGC do. 


Take the above as an example and assuming that it does not make sense for TDM 
termination to have "OS" and "OR", what should MG return for TDM termination 
statistics if the termination realizes "TDMC" package? 
Just "duration". 


--- 
Said it is valid to have "OS" and "OR" for TDM. 
IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP termination, 
is it valid for MG to return nt/dur, nt/os and nt/or for the TDM termination and RTP 
termination instead of tdmc/dur, ... vs rtp/dur ? 


Thanks 
Chuong 
  
  
  

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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



From owner-megaco@fore.com  Tue May 29 21:43:18 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14759
	for ; Tue, 29 May 2001 21:43:18 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA26944;
	Tue, 29 May 2001 21:36:09 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA13527
	for megaco-list; Tue, 29 May 2001 21:35:30 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA13522
	for ; Tue, 29 May 2001 21:35:28 -0400 (EDT)
Received: from Mitel.COM ([216.191.234.101])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA26857
	for ; Tue, 29 May 2001 21:35:25 -0400 (EDT)
Received: from rndex50.software.mitel.com (rndex50 [134.199.17.160]) 
	by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id VAA26965;
	Tue, 29 May 2001 21:35:07 -0400 (EDT)
Received: by rndex50.kanata.mitel.com with Internet Mail Service (5.5.2448.0)
	id ; Tue, 29 May 2001 21:35:26 -0400
Message-ID: <9D6A470BD38ED311908000805F65B4EC04AE0933@rndex50.kanata.mitel.com>
From: "Blatherwick, Peter" 
To: "'Chuong Nguyen'" , megaco@fore.com
Subject: RE: Network Package
Date: Tue, 29 May 2001 21:35:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

See below (and related responses to Madhubabu).   -- Peter

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: May 29, 2001 18:15
To: megaco@fore.com
Subject: Re: Network Package


Ok.  I follow you now but .... 

IS this clearly stated somewhere? 
This could be a nightmare for MGC to receive the same statistics value via 2 different 
parameter.  Talk about the overhead of parsing these text strings. 

[PB]  I believe this logic was given in the Implementors' Guide.  If it remains unclear, please let us all know what needs to be clarified.   

[PB] Yes, there would be double the overhead, but that's not really different overhead from MGC asking for 2 sets of statistics from different sources.  

 Can someone answer the question what does it mean for tdmc package to 
extend nt package property of "Maximum Jitter Buffer"?  

[PB] My opinion, not as author of the tdmc Package,  is the property should simply always be 0.  There is no jitter buffer.  I agree this is not a very interesting value, so if the MGC is not interested it should not ask, and if its software is designed to handle the general case of any package extending from nt, it better be able to handle 0 as the answer.  

Thanks 
Chuong 
  

"Rosen, Brian" wrote: 


Well rtp/dur and nt/dur are "the same thing" in the sense that the mean the samething, but if you implement (expose) both packages, then they are "separate"statistics.  Using Events is perhaps easier to understand.  Suppose Package Aimplements event E1, and package B extends Package A, and a given implementationexposes both A and B, such that an audit of termination T1 returns Packages{..A,B..}You can say Add=T1{Events=123{B/E1}}or you can sayAdd=T1{Events=123{A/T1}}or evenAdd=T1{Events=123{A/T1,B/T1}}In the latter, detection of the event would result in a notify of both.Returning to statistics, the value would be the same, but they are separatestatistics.Brian 

-----Original Message----- 
From: Chuong Nguyen [ mailto:Chuong.Nguyen@usa.alcatel.com  ] 
Sent: Tuesday, May 29, 2001 5:29 PM 
To: megaco@fore.com 
Subject: Re: Network Package
"Rosen, Brian" wrote: 

If you implement any part of a package, you implement all of it.If a package extends any part of a package, it extends all of it.

What is not required is that if you implement a package that extendsanother package that you have to "expose" the underlying package.This means that if you implement rtp you don't have to expose nt.If you list nt as one of the packages in an audit, then you have toimplement nt/dur.


  I don't quite follow here. 
               You seem to imply that nt/dur and rtp/dur are 2 different things. 
               I thought both nt/dur and rtp/dur are the same thing w/the same value. 
              If MG exposed nt, what should it return for duration - nt/dur or rtp/dur? 


Do you know the intend of tdmc/os and tdmc/or? 
I thought the same as Madhubabu about how they are calculated. 
  
  
  
  


Brian 

-----Original Message----- 
From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com  ] 
Sent: Tuesday, May 29, 2001 5:15 PM 
To: 'Chuong Nguyen' 
Cc: megaco@fore.com 
Subject: RE: Network Package
Hi chuong/all,IMO if PackageB extends PackageA and if one of the statistic/property of Package A is not valid for termination realizing packageB then there is no reason why PackageB extends PackageA. Then PackageB shouldn't extend PackageA (just only to reuse few properties/statistics) but should define the same properties (Might be with different IDs) in packageB. I think the extension of packages is logical if the newly defined package can inherit "all" the properties already defined in the base package and also define new properties. In your example, I was in the impression that "OS" and "OR" can be calculated as "The number of octet sent or received is equal to the duration of the Termination, in seconds, multiplied by the sampling frequency,  8000 Hz.". (Of course this seems to be redundant info if the MGC is aware of the sampling frequency). Isn't this the intention?????-RegardsMadhubabu 

-----Original Message----- 
From: owner-megaco@pit.comms.marconi.com [ mailto:owner-megaco@pit.comms.marconi.com  ]On Behalf Of Chuong Nguyen 
Sent: Tuesday, May 29, 2001 4:38 PM 
To: megaco@fore.com 
Subject: Network Package
Hi All 
  

Is it reasonable to assume that Network Package StatisticsID will never be used directly? 
That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os and rtp/or respectiviely 
since rtp package extends nt package. 


I know that it is agreed that if a termination realizes rtp package, it also realizes nt package 
and either nt/.. or rtp/.. are valid packageName. 


But if we allow, nt/... instead of rtp/.., are we saying that if MGC receives nt/.., it has to 
know whether it is for rtp or tmcd termination by the terminationID? 
  


Furthermore, since tdmc package extends nt package, do "octet sent" (OS) and "octet 
received" (OR) really apply to tdm termination? 


Also what does it mean for a TDM termination to realize the "NT" package properties 
of "Maximum Jitter Buffer"? 


So a more general question, if a termination realizes a packageB that extends 
packageA and there are items in the packageA that does not make sense to 
the termination what should MG/MGC do. 


Take the above as an example and assuming that it does not make sense for TDM 
termination to have "OS" and "OR", what should MG return for TDM termination 
statistics if the termination realizes "TDMC" package? 
Just "duration". 


--- 
Said it is valid to have "OS" and "OR" for TDM. 
IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP termination, 
is it valid for MG to return nt/dur, nt/os and nt/or for the TDM termination and RTP 
termination instead of tdmc/dur, ... vs rtp/dur ? 


Thanks 
Chuong 
  
  
  

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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

-- 

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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



From owner-megaco@fore.com  Tue May 29 21:52:13 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14797
	for ; Tue, 29 May 2001 21:52:12 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA27457;
	Tue, 29 May 2001 21:45:39 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA14154
	for megaco-list; Tue, 29 May 2001 21:45:06 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA14150
	for ; Tue, 29 May 2001 21:45:05 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA27382
	for ; Tue, 29 May 2001 21:45:02 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.124])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACP40860;
	Tue, 29 May 2001 21:44:27 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Blatherwick, Peter'" ,
        "'Chuong Nguyen'" , 
Subject: RE: Network Package
Date: Tue, 29 May 2001 21:47:34 -0400
Message-ID: <008001c0e8aa$7fe82ae0$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <9D6A470BD38ED311908000805F65B4EC04AE0933@rndex50.kanata.mitel.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Peter/All,
I think the better place for the "Maximum Jitter Buffer" is the RTP package
instead of the NT package. 0 can be the value for TDM terminations but...if
its the same value... no extra information is conveyed to MGC. Only RTP
package realizing terminations should use them.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Blatherwick,
Peter
Sent: Tuesday, May 29, 2001 9:35 PM
To: 'Chuong Nguyen'; megaco@fore.com
Subject: RE: Network Package


See below (and related responses to Madhubabu).   -- Peter

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: May 29, 2001 18:15
To: megaco@fore.com
Subject: Re: Network Package


Ok.  I follow you now but ....

IS this clearly stated somewhere?
This could be a nightmare for MGC to receive the same statistics value via 2
different
parameter.  Talk about the overhead of parsing these text strings.

[PB]  I believe this logic was given in the Implementors' Guide.  If it
remains unclear, please let us all know what needs to be clarified.

[PB] Yes, there would be double the overhead, but that's not really
different overhead from MGC asking for 2 sets of statistics from different
sources.

 Can someone answer the question what does it mean for tdmc package to
extend nt package property of "Maximum Jitter Buffer"?

[PB] My opinion, not as author of the tdmc Package,  is the property should
simply always be 0.  There is no jitter buffer.  I agree this is not a very
interesting value, so if the MGC is not interested it should not ask, and if
its software is designed to handle the general case of any package extending
from nt, it better be able to handle 0 as the answer.

Thanks
Chuong


"Rosen, Brian" wrote:


Well rtp/dur and nt/dur are "the same thing" in the sense that the mean the
samething, but if you implement (expose) both packages, then they are
"separate"statistics.  Using Events is perhaps easier to understand.
Suppose Package Aimplements event E1, and package B extends Package A, and a
given implementationexposes both A and B, such that an audit of termination
T1 returns Packages{..A,B..}You can say Add=T1{Events=123{B/E1}}or you can
sayAdd=T1{Events=123{A/T1}}or evenAdd=T1{Events=123{A/T1,B/T1}}In the
latter, detection of the event would result in a notify of both.Returning to
statistics, the value would be the same, but they are
separatestatistics.Brian

-----Original Message-----
From: Chuong Nguyen [ mailto:Chuong.Nguyen@usa.alcatel.com
 ]
Sent: Tuesday, May 29, 2001 5:29 PM
To: megaco@fore.com
Subject: Re: Network Package
"Rosen, Brian" wrote:

If you implement any part of a package, you implement all of it.If a package
extends any part of a package, it extends all of it.

What is not required is that if you implement a package that extendsanother
package that you have to "expose" the underlying package.This means that if
you implement rtp you don't have to expose nt.If you list nt as one of the
packages in an audit, then you have toimplement nt/dur.


  I don't quite follow here.
               You seem to imply that nt/dur and rtp/dur are 2 different
things.
               I thought both nt/dur and rtp/dur are the same thing w/the
same value.
              If MG exposed nt, what should it return for duration - nt/dur
or rtp/dur?


Do you know the intend of tdmc/os and tdmc/or?
I thought the same as Madhubabu about how they are calculated.






Brian

-----Original Message-----
From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com
 ]
Sent: Tuesday, May 29, 2001 5:15 PM
To: 'Chuong Nguyen'
Cc: megaco@fore.com
Subject: RE: Network Package
Hi chuong/all,IMO if PackageB extends PackageA and if one of the
statistic/property of Package A is not valid for termination realizing
packageB then there is no reason why PackageB extends PackageA. Then
PackageB shouldn't extend PackageA (just only to reuse few
properties/statistics) but should define the same properties (Might be with
different IDs) in packageB. I think the extension of packages is logical if
the newly defined package can inherit "all" the properties already defined
in the base package and also define new properties. In your example, I was
in the impression that "OS" and "OR" can be calculated as "The number of
octet sent or received is equal to the duration of the Termination, in
seconds, multiplied by the sampling frequency,  8000 Hz.". (Of course this
seems to be redundant info if the MGC is aware of the sampling frequency).
Isn't this the intention?????-RegardsMadhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
 mailto:owner-megaco@pit.comms.marconi.com
 ]On Behalf Of Chuong Nguyen
Sent: Tuesday, May 29, 2001 4:38 PM
To: megaco@fore.com
Subject: Network Package
Hi All


Is it reasonable to assume that Network Package StatisticsID will never be
used directly?
That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os and rtp/or
respectiviely
since rtp package extends nt package.


I know that it is agreed that if a termination realizes rtp package, it also
realizes nt package
and either nt/.. or rtp/.. are valid packageName.


But if we allow, nt/... instead of rtp/.., are we saying that if MGC
receives nt/.., it has to
know whether it is for rtp or tmcd termination by the terminationID?



Furthermore, since tdmc package extends nt package, do "octet sent" (OS) and
"octet
received" (OR) really apply to tdm termination?


Also what does it mean for a TDM termination to realize the "NT" package
properties
of "Maximum Jitter Buffer"?


So a more general question, if a termination realizes a packageB that
extends
packageA and there are items in the packageA that does not make sense to
the termination what should MG/MGC do.


Take the above as an example and assuming that it does not make sense for
TDM
termination to have "OS" and "OR", what should MG return for TDM termination
statistics if the termination realizes "TDMC" package?
Just "duration".


---
Said it is valid to have "OS" and "OR" for TDM.
IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP
termination,
is it valid for MG to return nt/dur, nt/os and nt/or for the TDM termination
and RTP
termination instead of tdmc/dur, ... vs rtp/dur ?


Thanks
Chuong




--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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




From owner-megaco@fore.com  Tue May 29 21:53:23 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14825
	for ; Tue, 29 May 2001 21:53:23 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA27226;
	Tue, 29 May 2001 21:41:57 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA13885
	for megaco-list; Tue, 29 May 2001 21:41:18 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA13881
	for ; Tue, 29 May 2001 21:41:16 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA27143
	for ; Tue, 29 May 2001 21:41:14 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.124])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACP40858;
	Tue, 29 May 2001 21:40:25 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Blatherwick, Peter'" ,
        "'Rosen, Brian'" ,
        "'Chuong Nguyen'" , 
Subject: RE: Network Package
Date: Tue, 29 May 2001 21:43:32 -0400
Message-ID: <007f01c0e8a9$ef9acab0$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <9D6A470BD38ED311908000805F65B4EC04AE0932@rndex50.kanata.mitel.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

HI Peter/All,

I agree that the MG does whatever is said by the MGC. But, if say Events
Descriptor is X,Y,Z and say X and Z means the same (Similar to the A/T1 and
B/T1). Now the MG while reporting the event in the Notify also has to check
events beyond match???? Is this fine???

1) Then this has to be true while buffering events in Events Buffer
according to Event Buffer descriptor and
2) While processing of new events descriptor when Event Buffer control is
lockstep.

But I see no such statement in the Protocol Text. If the intention of
matching of event is to match all the "synonyms" of the event. Then this
text needs to be specified in the IG at least to avoid any
misunderstandings.

Regards
Madhubabu


-----Original Message-----
From: Blatherwick, Peter [mailto:Peter_Blatherwick@Mitel.COM]
Sent: Tuesday, May 29, 2001 9:22 PM
To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen';
megaco@fore.com
Subject: RE: Network Package


As in previous e-mail, just sent, I don't believe the below error should
apply to the case of MGC requesting both A/T1 and B/T1.   MG is simply
responding to the request.   May be a better case for using this if the
request is for A/T1 and A/T1, but I still don't think so.  MG simply does as
its told.
-- Peter

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: May 29, 2001 19:19
To: 'Rosen, Brian'; 'Chuong Nguyen'; megaco@fore.com
Subject: RE: Network Package


Brian/All,

Sorry for wrong information in my earlier mail.... Error code "456 -
Parameter or Property appears twice in this Descriptor" is present for
avoiding multiple instances of properties/parameters. If A/T1 and B/T1 mean
the same doesn't this fall into the above error category.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Tuesday, May 29, 2001 5:47 PM
To: 'Chuong Nguyen'; megaco@fore.com
Subject: RE: Network Package


Well rtp/dur and nt/dur are "the same thing" in the sense that the mean the
same
thing, but if you implement (expose) both packages, then they are "separate"
statistics.  Using Events is perhaps easier to understand.  Suppose Package
A
implements event E1, and package B extends Package A, and a given
implementation
exposes both A and B, such that an audit of termination T1 returns
Packages{..A,B..}

You can say Add=T1{Events=123{B/E1}}
or you can say
Add=T1{Events=123{A/T1}}
or even
Add=T1{Events=123{A/T1,B/T1}}

In the latter, detection of the event would result in a notify of both.

Returning to statistics, the value would be the same, but they are separate
statistics.

Brian

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Tuesday, May 29, 2001 5:29 PM
To: megaco@fore.com
Subject: Re: Network Package


"Rosen, Brian" wrote:

If you implement any part of a package, you implement all of it.If a package
extends any part of a package, it extends all of it.

What is not required is that if you implement a package that extendsanother
package that you have to "expose" the underlying package.This means that if
you implement rtp you don't have to expose nt.If you list nt as one of the
packages in an audit, then you have toimplement nt/dur.


  I don't quite follow here.
               You seem to imply that nt/dur and rtp/dur are 2 different
things.
               I thought both nt/dur and rtp/dur are the same thing w/the
same value.
              If MG exposed nt, what should it return for duration - nt/dur
or rtp/dur?


Do you know the intend of tdmc/os and tdmc/or?
I thought the same as Madhubabu about how they are calculated.






Brian

-----Original Message-----
From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com
 ]
Sent: Tuesday, May 29, 2001 5:15 PM
To: 'Chuong Nguyen'
Cc: megaco@fore.com
Subject: RE: Network Package
Hi chuong/all,IMO if PackageB extends PackageA and if one of the
statistic/property of Package A is not valid for termination realizing
packageB then there is no reason why PackageB extends PackageA. Then
PackageB shouldn't extend PackageA (just only to reuse few
properties/statistics) but should define the same properties (Might be with
different IDs) in packageB. I think the extension of packages is logical if
the newly defined package can inherit "all" the properties already defined
in the base package and also define new properties. In your example, I was
in the impression that "OS" and "OR" can be calculated as "The number of
octet sent or received is equal to the duration of the Termination, in
seconds, multiplied by the sampling frequency,  8000 Hz.". (Of course this
seems to be redundant info if the MGC is aware of the sampling frequency).
Isn't this the intention?????-RegardsMadhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
 mailto:owner-megaco@pit.comms.marconi.com
 ]On Behalf Of Chuong Nguyen
Sent: Tuesday, May 29, 2001 4:38 PM
To: megaco@fore.com
Subject: Network Package
Hi All


Is it reasonable to assume that Network Package StatisticsID will never be
used directly?
That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os and rtp/or
respectiviely
since rtp package extends nt package.


I know that it is agreed that if a termination realizes rtp package, it also
realizes nt package
and either nt/.. or rtp/.. are valid packageName.


But if we allow, nt/... instead of rtp/.., are we saying that if MGC
receives nt/.., it has to
know whether it is for rtp or tmcd termination by the terminationID?



Furthermore, since tdmc package extends nt package, do "octet sent" (OS) and
"octet
received" (OR) really apply to tdm termination?


Also what does it mean for a TDM termination to realize the "NT" package
properties
of "Maximum Jitter Buffer"?


So a more general question, if a termination realizes a packageB that
extends
packageA and there are items in the packageA that does not make sense to
the termination what should MG/MGC do.


Take the above as an example and assuming that it does not make sense for
TDM
termination to have "OS" and "OR", what should MG return for TDM termination
statistics if the termination realizes "TDMC" package?
Just "duration".


---
Said it is valid to have "OS" and "OR" for TDM.
IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP
termination,
is it valid for MG to return nt/dur, nt/os and nt/or for the TDM termination
and RTP
termination instead of tdmc/dur, ... vs rtp/dur ?


Thanks
Chuong




--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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




From owner-megaco@fore.com  Tue May 29 22:14:12 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14950
	for ; Tue, 29 May 2001 22:14:12 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA28285;
	Tue, 29 May 2001 22:07:11 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id WAA15791
	for megaco-list; Tue, 29 May 2001 22:06:40 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA15786
	for ; Tue, 29 May 2001 22:06:39 -0400 (EDT)
Received: from Mitel.COM ([216.191.234.101])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA28216
	for ; Tue, 29 May 2001 22:06:36 -0400 (EDT)
Received: from rndex50.software.mitel.com (rndex50 [134.199.17.160]) 
	by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id WAA28794;
	Tue, 29 May 2001 22:06:18 -0400 (EDT)
Received: by rndex50.kanata.mitel.com with Internet Mail Service (5.5.2448.0)
	id ; Tue, 29 May 2001 22:06:37 -0400
Message-ID: <9D6A470BD38ED311908000805F65B4EC04AE0935@rndex50.kanata.mitel.com>
From: "Blatherwick, Peter" 
To: "'Madhu Babu Brahmanapally'" , megaco@fore.com
Subject: RE: Network Package
Date: Tue, 29 May 2001 22:06:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

You may be right (a flaw in the package hierarchy), but in practice its too late, the NT package is done.  Maybe version 2...
-- Peter

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: May 29, 2001 21:48
To: 'Blatherwick, Peter'; 'Chuong Nguyen'; megaco@fore.com
Subject: RE: Network Package


Hi Peter/All,
I think the better place for the "Maximum Jitter Buffer" is the RTP package
instead of the NT package. 0 can be the value for TDM terminations but...if
its the same value... no extra information is conveyed to MGC. Only RTP
package realizing terminations should use them.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Blatherwick,
Peter
Sent: Tuesday, May 29, 2001 9:35 PM
To: 'Chuong Nguyen'; megaco@fore.com
Subject: RE: Network Package


See below (and related responses to Madhubabu).   -- Peter

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: May 29, 2001 18:15
To: megaco@fore.com
Subject: Re: Network Package


Ok.  I follow you now but ....

IS this clearly stated somewhere?
This could be a nightmare for MGC to receive the same statistics value via 2
different
parameter.  Talk about the overhead of parsing these text strings.

[PB]  I believe this logic was given in the Implementors' Guide.  If it
remains unclear, please let us all know what needs to be clarified.

[PB] Yes, there would be double the overhead, but that's not really
different overhead from MGC asking for 2 sets of statistics from different
sources.

 Can someone answer the question what does it mean for tdmc package to
extend nt package property of "Maximum Jitter Buffer"?

[PB] My opinion, not as author of the tdmc Package,  is the property should
simply always be 0.  There is no jitter buffer.  I agree this is not a very
interesting value, so if the MGC is not interested it should not ask, and if
its software is designed to handle the general case of any package extending
from nt, it better be able to handle 0 as the answer.

Thanks
Chuong


"Rosen, Brian" wrote:


Well rtp/dur and nt/dur are "the same thing" in the sense that the mean the
samething, but if you implement (expose) both packages, then they are
"separate"statistics.  Using Events is perhaps easier to understand.
Suppose Package Aimplements event E1, and package B extends Package A, and a
given implementationexposes both A and B, such that an audit of termination
T1 returns Packages{..A,B..}You can say Add=T1{Events=123{B/E1}}or you can
sayAdd=T1{Events=123{A/T1}}or evenAdd=T1{Events=123{A/T1,B/T1}}In the
latter, detection of the event would result in a notify of both.Returning to
statistics, the value would be the same, but they are
separatestatistics.Brian

-----Original Message-----
From: Chuong Nguyen [ mailto:Chuong.Nguyen@usa.alcatel.com
 ]
Sent: Tuesday, May 29, 2001 5:29 PM
To: megaco@fore.com
Subject: Re: Network Package
"Rosen, Brian" wrote:

If you implement any part of a package, you implement all of it.If a package
extends any part of a package, it extends all of it.

What is not required is that if you implement a package that extendsanother
package that you have to "expose" the underlying package.This means that if
you implement rtp you don't have to expose nt.If you list nt as one of the
packages in an audit, then you have toimplement nt/dur.


  I don't quite follow here.
               You seem to imply that nt/dur and rtp/dur are 2 different
things.
               I thought both nt/dur and rtp/dur are the same thing w/the
same value.
              If MG exposed nt, what should it return for duration - nt/dur
or rtp/dur?


Do you know the intend of tdmc/os and tdmc/or?
I thought the same as Madhubabu about how they are calculated.






Brian

-----Original Message-----
From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com
 ]
Sent: Tuesday, May 29, 2001 5:15 PM
To: 'Chuong Nguyen'
Cc: megaco@fore.com
Subject: RE: Network Package
Hi chuong/all,IMO if PackageB extends PackageA and if one of the
statistic/property of Package A is not valid for termination realizing
packageB then there is no reason why PackageB extends PackageA. Then
PackageB shouldn't extend PackageA (just only to reuse few
properties/statistics) but should define the same properties (Might be with
different IDs) in packageB. I think the extension of packages is logical if
the newly defined package can inherit "all" the properties already defined
in the base package and also define new properties. In your example, I was
in the impression that "OS" and "OR" can be calculated as "The number of
octet sent or received is equal to the duration of the Termination, in
seconds, multiplied by the sampling frequency,  8000 Hz.". (Of course this
seems to be redundant info if the MGC is aware of the sampling frequency).
Isn't this the intention?????-RegardsMadhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
 mailto:owner-megaco@pit.comms.marconi.com
 ]On Behalf Of Chuong Nguyen
Sent: Tuesday, May 29, 2001 4:38 PM
To: megaco@fore.com
Subject: Network Package
Hi All


Is it reasonable to assume that Network Package StatisticsID will never be
used directly?
That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os and rtp/or
respectiviely
since rtp package extends nt package.


I know that it is agreed that if a termination realizes rtp package, it also
realizes nt package
and either nt/.. or rtp/.. are valid packageName.


But if we allow, nt/... instead of rtp/.., are we saying that if MGC
receives nt/.., it has to
know whether it is for rtp or tmcd termination by the terminationID?



Furthermore, since tdmc package extends nt package, do "octet sent" (OS) and
"octet
received" (OR) really apply to tdm termination?


Also what does it mean for a TDM termination to realize the "NT" package
properties
of "Maximum Jitter Buffer"?


So a more general question, if a termination realizes a packageB that
extends
packageA and there are items in the packageA that does not make sense to
the termination what should MG/MGC do.


Take the above as an example and assuming that it does not make sense for
TDM
termination to have "OS" and "OR", what should MG return for TDM termination
statistics if the termination realizes "TDMC" package?
Just "duration".


---
Said it is valid to have "OS" and "OR" for TDM.
IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP
termination,
is it valid for MG to return nt/dur, nt/os and nt/or for the TDM termination
and RTP
termination instead of tdmc/dur, ... vs rtp/dur ?


Thanks
Chuong




--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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



From owner-megaco@fore.com  Tue May 29 22:14:46 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14962
	for ; Tue, 29 May 2001 22:14:46 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA28100;
	Tue, 29 May 2001 22:05:26 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id WAA15677
	for megaco-list; Tue, 29 May 2001 22:04:52 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA15673
	for ; Tue, 29 May 2001 22:04:51 -0400 (EDT)
Received: from Mitel.COM ([216.191.234.101])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA28024
	for ; Tue, 29 May 2001 22:04:48 -0400 (EDT)
Received: from rndex50.software.mitel.com (rndex50 [134.199.17.160]) 
	by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id WAA28595;
	Tue, 29 May 2001 22:04:29 -0400 (EDT)
Received: by rndex50.kanata.mitel.com with Internet Mail Service (5.5.2448.0)
	id ; Tue, 29 May 2001 22:04:48 -0400
Message-ID: <9D6A470BD38ED311908000805F65B4EC04AE0934@rndex50.kanata.mitel.com>
From: "Blatherwick, Peter" 
To: "'Madhu Babu Brahmanapally'" , megaco@fore.com
Subject: RE: Network Package
Date: Tue, 29 May 2001 22:04:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Now I'm not so sure what you're getting at below -- what is different from previous examples.  I see the rules as completely general.  MG simply checks for events to report (redundant or not, doesn't care or even necessarily know), in the order requested, and for each one follows the buffering/reporting algorithm per current handling settings.  Perhaps a more explicit example?  

Re the IG, I don't think it explicitly mentions "synonyms" (nice term by the way ;-), but does give clear guidance on what is considered equivalent, how the MG exposes its interfaces, and how the MGC specifies what it wants.  Event reporting text in the core protocol document and/or IG I personally believe already are clear on how events are reported.  Since we are not talking about special cases, simply same handling for all events requested by MGC, I don't see that specific text is required.  My opinion.  

-- Peter

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: May 29, 2001 21:44
To: 'Blatherwick, Peter'; 'Rosen, Brian'; 'Chuong Nguyen';
megaco@fore.com
Subject: RE: Network Package


HI Peter/All,

I agree that the MG does whatever is said by the MGC. But, if say Events
Descriptor is X,Y,Z and say X and Z means the same (Similar to the A/T1 and
B/T1). Now the MG while reporting the event in the Notify also has to check
events beyond match???? Is this fine???

1) Then this has to be true while buffering events in Events Buffer
according to Event Buffer descriptor and
2) While processing of new events descriptor when Event Buffer control is
lockstep.

But I see no such statement in the Protocol Text. If the intention of
matching of event is to match all the "synonyms" of the event. Then this
text needs to be specified in the IG at least to avoid any
misunderstandings.

Regards
Madhubabu


-----Original Message-----
From: Blatherwick, Peter [mailto:Peter_Blatherwick@Mitel.COM]
Sent: Tuesday, May 29, 2001 9:22 PM
To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen';
megaco@fore.com
Subject: RE: Network Package


As in previous e-mail, just sent, I don't believe the below error should
apply to the case of MGC requesting both A/T1 and B/T1.   MG is simply
responding to the request.   May be a better case for using this if the
request is for A/T1 and A/T1, but I still don't think so.  MG simply does as
its told.
-- Peter

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: May 29, 2001 19:19
To: 'Rosen, Brian'; 'Chuong Nguyen'; megaco@fore.com
Subject: RE: Network Package


Brian/All,

Sorry for wrong information in my earlier mail.... Error code "456 -
Parameter or Property appears twice in this Descriptor" is present for
avoiding multiple instances of properties/parameters. If A/T1 and B/T1 mean
the same doesn't this fall into the above error category.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Tuesday, May 29, 2001 5:47 PM
To: 'Chuong Nguyen'; megaco@fore.com
Subject: RE: Network Package


Well rtp/dur and nt/dur are "the same thing" in the sense that the mean the
same
thing, but if you implement (expose) both packages, then they are "separate"
statistics.  Using Events is perhaps easier to understand.  Suppose Package
A
implements event E1, and package B extends Package A, and a given
implementation
exposes both A and B, such that an audit of termination T1 returns
Packages{..A,B..}

You can say Add=T1{Events=123{B/E1}}
or you can say
Add=T1{Events=123{A/T1}}
or even
Add=T1{Events=123{A/T1,B/T1}}

In the latter, detection of the event would result in a notify of both.

Returning to statistics, the value would be the same, but they are separate
statistics.

Brian

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Tuesday, May 29, 2001 5:29 PM
To: megaco@fore.com
Subject: Re: Network Package


"Rosen, Brian" wrote:

If you implement any part of a package, you implement all of it.If a package
extends any part of a package, it extends all of it.

What is not required is that if you implement a package that extendsanother
package that you have to "expose" the underlying package.This means that if
you implement rtp you don't have to expose nt.If you list nt as one of the
packages in an audit, then you have toimplement nt/dur.


  I don't quite follow here.
               You seem to imply that nt/dur and rtp/dur are 2 different
things.
               I thought both nt/dur and rtp/dur are the same thing w/the
same value.
              If MG exposed nt, what should it return for duration - nt/dur
or rtp/dur?


Do you know the intend of tdmc/os and tdmc/or?
I thought the same as Madhubabu about how they are calculated.






Brian

-----Original Message-----
From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com
 ]
Sent: Tuesday, May 29, 2001 5:15 PM
To: 'Chuong Nguyen'
Cc: megaco@fore.com
Subject: RE: Network Package
Hi chuong/all,IMO if PackageB extends PackageA and if one of the
statistic/property of Package A is not valid for termination realizing
packageB then there is no reason why PackageB extends PackageA. Then
PackageB shouldn't extend PackageA (just only to reuse few
properties/statistics) but should define the same properties (Might be with
different IDs) in packageB. I think the extension of packages is logical if
the newly defined package can inherit "all" the properties already defined
in the base package and also define new properties. In your example, I was
in the impression that "OS" and "OR" can be calculated as "The number of
octet sent or received is equal to the duration of the Termination, in
seconds, multiplied by the sampling frequency,  8000 Hz.". (Of course this
seems to be redundant info if the MGC is aware of the sampling frequency).
Isn't this the intention?????-RegardsMadhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
 mailto:owner-megaco@pit.comms.marconi.com
 ]On Behalf Of Chuong Nguyen
Sent: Tuesday, May 29, 2001 4:38 PM
To: megaco@fore.com
Subject: Network Package
Hi All


Is it reasonable to assume that Network Package StatisticsID will never be
used directly?
That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os and rtp/or
respectiviely
since rtp package extends nt package.


I know that it is agreed that if a termination realizes rtp package, it also
realizes nt package
and either nt/.. or rtp/.. are valid packageName.


But if we allow, nt/... instead of rtp/.., are we saying that if MGC
receives nt/.., it has to
know whether it is for rtp or tmcd termination by the terminationID?



Furthermore, since tdmc package extends nt package, do "octet sent" (OS) and
"octet
received" (OR) really apply to tdm termination?


Also what does it mean for a TDM termination to realize the "NT" package
properties
of "Maximum Jitter Buffer"?


So a more general question, if a termination realizes a packageB that
extends
packageA and there are items in the packageA that does not make sense to
the termination what should MG/MGC do.


Take the above as an example and assuming that it does not make sense for
TDM
termination to have "OS" and "OR", what should MG return for TDM termination
statistics if the termination realizes "TDMC" package?
Just "duration".


---
Said it is valid to have "OS" and "OR" for TDM.
IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP
termination,
is it valid for MG to return nt/dur, nt/os and nt/or for the TDM termination
and RTP
termination instead of tdmc/dur, ... vs rtp/dur ?


Thanks
Chuong




--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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



From owner-megaco@fore.com  Wed May 30 04:15:54 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03456
	for ; Wed, 30 May 2001 04:15:54 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA09793;
	Wed, 30 May 2001 04:08:42 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id EAA14024
	for megaco-list; Wed, 30 May 2001 04:06:00 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA13995;
	Wed, 30 May 2001 04:05:56 -0400 (EDT)
From: future33@turbomail.net
Received: from ultra10.beijixing.com.cn ([168.160.66.6])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA09580;
	Wed, 30 May 2001 04:05:43 -0400 (EDT)
Received: from www.turbomail.net ([32.103.26.101]) by
          ultra10.beijixing.com.cn (Netscape Messaging Server 4.15) with
          SMTP id GE52UN00.TVV; Wed, 30 May 2001 16:13:36 +0800 
Subject: Financial Security NOW!!
Date: Wed, 30 May 2001 00:28:18
Message-Id: <149.21371.899448@www.turbomail.net>
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Would you like to be secure in your financial future?

Have enough money to retire how you want to and when you want to?

Or even have the ability to send your children to the colleges of your choice, without 
regard to cost?

THE PROPER REAL ESTATE INVESTMENT MAY BE THE ANSWER! 

For additional information reply visit
http://www.fasthostnow.net/opportunity

You now have the opportunity to purchase real estate in one of the most progressive 
markets nationwide!

***Fully rented***
***In place Management***
***Priced $58,000 below construction cost***

You can own a beautiful brick apartment building for as little as $6,200 down.

**Enjoy a comfortable retirement**
**Save on taxes**
**Provide for your, or your children's future**

For additional information reply visit
http://www.fasthostnow.net/opportunity

To be removed from our mailing list please visit
http://www.fasthostnow.net/opportunity/remove.html
 
 
 
 
 
 
 
 
 
 
 
 
 


From owner-megaco@fore.com  Wed May 30 07:00:32 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05166
	for ; Wed, 30 May 2001 07:00:32 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA14946;
	Wed, 30 May 2001 06:50:36 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id GAA18204
	for megaco-list; Wed, 30 May 2001 06:47:44 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA18200
	for ; Wed, 30 May 2001 06:47:43 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA14791
	for ; Wed, 30 May 2001 06:47:41 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04926;
	Wed, 30 May 2001 06:47:23 -0400 (EDT)
Message-Id: <200105301047.GAA04926@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: megaco@fore.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-megaco-mib-02.txt
Date: Wed, 30 May 2001 06:47:22 -0400
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Media Gateway Control Working Group of the IETF.

	Title		: MEGACO MIB
	Author(s)	: M. Holdrege, I. Akramovich, C. Brown
	Filename	: draft-ietf-megaco-mib-02.txt
	Pages		: 25
	Date		: 29-May-01
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for use by the MEGACO/H.248
protocol operating on Media Gateways and Media Gateway Controllers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-megaco-mib-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-megaco-mib-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-megaco-mib-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010529142253.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-megaco-mib-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-megaco-mib-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010529142253.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-megaco@fore.com  Wed May 30 10:11:21 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11966
	for ; Wed, 30 May 2001 10:11:21 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA25231;
	Wed, 30 May 2001 09:38:51 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA15126
	for megaco-list; Wed, 30 May 2001 09:34:53 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA15052
	for ; Wed, 30 May 2001 09:34:50 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA24712
	for ; Wed, 30 May 2001 09:34:43 -0400 (EDT)
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f4UDYaE05371
	for ; Wed, 30 May 2001 09:34:36 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 30 May 2001 09:34:24 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 30 May 2001 09:34:27 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CBFB@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: megaco@fore.com
Subject: RE: I-D ACTION:draft-ietf-megaco-mib-02.txt
Date: Wed, 30 May 2001 09:34:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E90D.3EA34CF0"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E90D.3EA34CF0
Content-Type: text/plain;
	charset="ISO-8859-1"

I would like to explain briefly what has happened with this draft.
Basically it consists of a reorganization and extension of material
available in the initial draft (mib-00).  As such, it presents a coherent
view and may be the basis of a working MIB.  A word of warning comes along
with this: Matt Holdrege identified a lot of open issues two meetings ago,
and a number of these undoubtedly remain open.  I will get Matt's meeting
presentation and post it on the Megaco web site for people to examine.

Given the large effort Michael Brown and colleagues put into the latest
draft, Michael's name has been added to the authors' list and Michael has
taken over primary editorial responsibilities from Matt.  I know that this
has been a frustrating task for Matt due to lack of input from the WG.
Thanks to him and Ilya Akramovich for getting us started.  Now let's get
this done so we can stop showing a milestone that's two years late!

Tom Taylor
Multimedia Control and Applications Standards
Ph.  +1 613 736 0961
taylor@nortelnetworks.com  

> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Wednesday, May 30, 2001 6:47 AM
> To: IETF-Announce
> Cc: megaco@fore.com
> Subject: I-D ACTION:draft-ietf-megaco-mib-02.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Media Gateway Control 
> Working Group of the IETF.
> 
> 	Title		: MEGACO MIB
> 	Author(s)	: M. Holdrege, I. Akramovich, C. Brown
> 	Filename	: draft-ietf-megaco-mib-02.txt
> 	Pages		: 25
> 	Date		: 29-May-01
> 	
> This memo defines a portion of the Management Information Base (MIB)
> for use with network management protocols in the Internet community.
> In particular, it defines objects for use by the MEGACO/H.248
> protocol operating on Media Gateways and Media Gateway Controllers.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-megaco-mib-02.txt
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-megaco-mib-02.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-megaco-mib-02.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

------_=_NextPart_001_01C0E90D.3EA34CF0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: I-D ACTION:draft-ietf-megaco-mib-02.txt




I would like to explain briefly what has happened =
with this draft.  Basically it consists of a reorganization and =
extension of material available in the initial draft (mib-00).  As =
such, it presents a coherent view and may be the basis of a working =
MIB.  A word of warning comes along with this: Matt Holdrege =
identified a lot of open issues two meetings ago, and a number of these =
undoubtedly remain open.  I will get Matt's meeting presentation =
and post it on the Megaco web site for people to examine.



Given the large effort Michael Brown and colleagues =
put into the latest draft, Michael's name has been added to the =
authors' list and Michael has taken over primary editorial =
responsibilities from Matt.  I know that this has been a =
frustrating task for Matt due to lack of input from the WG.  =
Thanks to him and Ilya Akramovich for getting us started.  Now =
let's get this done so we can stop showing a milestone that's two years =
late!



Tom Taylor

Multimedia Control and Applications Standards

Ph.  +1 613 736 0961

taylor@nortelnetworks.com  




> -----Original Message-----

> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org=
]

> Sent: Wednesday, May 30, 2001 6:47 AM

> To: IETF-Announce

> Cc: megaco@fore.com

> Subject: I-D =
ACTION:draft-ietf-megaco-mib-02.txt

> 

> 

> A New Internet-Draft is available from the =
on-line 

> Internet-Drafts directories.

> This draft is a work item of the Media Gateway =
Control 

> Working Group of the IETF.

> 

>       =
Title           : MEGACO =
MIB

>       =
Author(s)       : M. Holdrege, I. =
Akramovich, C. Brown

>       =
Filename        : =
draft-ietf-megaco-mib-02.txt

>       =
Pages           : =
25

>       =
Date            : =
29-May-01

>       

> This memo defines a portion of the Management =
Information Base (MIB)

> for use with network management protocols in =
the Internet community.

> In particular, it defines objects for use by =
the MEGACO/H.248

> protocol operating on Media Gateways and Media =
Gateway Controllers.

> 

> A URL for this Internet-Draft is:

> http://www.ietf.org/internet-drafts/draft-ietf-megaco-=
mib-02.txt

> 

> Internet-Drafts are also available by anonymous =
FTP. Login 

> with the username

> "anonymous" and a password of your =
e-mail address. After logging in,

> type "cd internet-drafts" and =
then

>       "get =
draft-ietf-megaco-mib-02.txt".

> 

> A list of Internet-Drafts directories can be =
found in

> http://www.ietf.org/shadow.html 

> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

> 

> 

> Internet-Drafts can also be obtained by =
e-mail.

> 

> Send a message to:

>       =
mailserv@ietf.org.

> In the body type:

>       "FILE =
/internet-drafts/draft-ietf-megaco-mib-02.txt".

>       

> NOTE: The mail server at ietf.org can return =
the document in

>       MIME-encoded =
form by using the "mpack" utility.  To use this

>       feature, insert =
the command "ENCODING mime" before the =
"FILE"

>       command.  =
To decode the response(s), you will need "munpack" or

>       a MIME-compliant =
mail reader.  Different MIME-compliant 

> mail readers

>       exhibit =
different behavior, especially when dealing with

>       =
"multipart" MIME messages (i.e. documents which have been =
split

>       up into multiple =
messages), so check your local documentation on

>       how to =
manipulate these messages.

>       =
        

>       =
        

> Below is the data which will enable a MIME =
compliant mail reader

> implementation to automatically retrieve the =
ASCII version of the

> Internet-Draft.

> 





------_=_NextPart_001_01C0E90D.3EA34CF0--


From owner-megaco@fore.com  Wed May 30 10:56:03 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13722
	for ; Wed, 30 May 2001 10:56:03 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA02383;
	Wed, 30 May 2001 10:46:44 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA05763
	for megaco-list; Wed, 30 May 2001 10:45:25 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA05714
	for ; Wed, 30 May 2001 10:43:46 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA01998
	for ; Wed, 30 May 2001 10:43:44 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.124])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACP43255;
	Wed, 30 May 2001 10:42:56 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Blatherwick, Peter'" , 
Subject: RE: Network Package
Date: Wed, 30 May 2001 10:46:00 -0400
Message-ID: <00c501c0e917$3eee0600$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <9D6A470BD38ED311908000805F65B4EC04AE0934@rndex50.kanata.mitel.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

HI Peter/All,

Might be an implementation issue but let me put the same query with some
sample code.

The Section 7.1.9 Events Descriptor 4th paragraph,
"When an event is processed against the contents of an active Events
   descriptor and found to be present in that descriptor ("recognized"),
   the default action of the MG is to send a Notify command to the MG."

After interpretation, the statement above was implemented as follows

ProcessDetectedEvent( Event detected is passed)
{
  if ( Events Descriptor is active)
  {
      for ( each event in the events descriptor )
      {
           if ( match Found)
           {
                 GenerateNotifyTowardsMGC ( event, timestamp, RequestId,
etc...)
                 PostEventDetectionProcessing(Event Detected)
                 break;
           }
      }
  }
  else
     ProcessEventAccordingToEventsBufferDescriptor( Event detected is
passed)
}

Its true that the IG mentions about package extension, but no where (I mean
either in IG/protocol) its mentioned that if one event recognition matches
two events in the Events Descriptor...(at First I wondered how this was
possible...) there will be two Notify commands generated towards MGC.

IMHO Unless explicitly mentioned about the multiple Notifies for single
hardware event, the general interpretation of event matching will be some
thing as shown above...which is actually not the intent.

Regards
Madhubabu




-----Original Message-----
From: Blatherwick, Peter [mailto:Peter_Blatherwick@Mitel.COM]
Sent: Tuesday, May 29, 2001 10:05 PM
To: 'Madhu Babu Brahmanapally'; megaco@fore.com
Subject: RE: Network Package


Now I'm not so sure what you're getting at below -- what is different from
previous examples.  I see the rules as completely general.  MG simply checks
for events to report (redundant or not, doesn't care or even necessarily
know), in the order requested, and for each one follows the
buffering/reporting algorithm per current handling settings.  Perhaps a more
explicit example?

Re the IG, I don't think it explicitly mentions "synonyms" (nice term by the
way ;-), but does give clear guidance on what is considered equivalent, how
the MG exposes its interfaces, and how the MGC specifies what it wants.
Event reporting text in the core protocol document and/or IG I personally
believe already are clear on how events are reported.  Since we are not
talking about special cases, simply same handling for all events requested
by MGC, I don't see that specific text is required.  My opinion.

-- Peter

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: May 29, 2001 21:44
To: 'Blatherwick, Peter'; 'Rosen, Brian'; 'Chuong Nguyen';
megaco@fore.com
Subject: RE: Network Package


HI Peter/All,

I agree that the MG does whatever is said by the MGC. But, if say Events
Descriptor is X,Y,Z and say X and Z means the same (Similar to the A/T1 and
B/T1). Now the MG while reporting the event in the Notify also has to check
events beyond match???? Is this fine???

1) Then this has to be true while buffering events in Events Buffer
according to Event Buffer descriptor and
2) While processing of new events descriptor when Event Buffer control is
lockstep.

But I see no such statement in the Protocol Text. If the intention of
matching of event is to match all the "synonyms" of the event. Then this
text needs to be specified in the IG at least to avoid any
misunderstandings.

Regards
Madhubabu


-----Original Message-----
From: Blatherwick, Peter [mailto:Peter_Blatherwick@Mitel.COM]
Sent: Tuesday, May 29, 2001 9:22 PM
To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen';
megaco@fore.com
Subject: RE: Network Package


As in previous e-mail, just sent, I don't believe the below error should
apply to the case of MGC requesting both A/T1 and B/T1.   MG is simply
responding to the request.   May be a better case for using this if the
request is for A/T1 and A/T1, but I still don't think so.  MG simply does as
its told.
-- Peter

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: May 29, 2001 19:19
To: 'Rosen, Brian'; 'Chuong Nguyen'; megaco@fore.com
Subject: RE: Network Package


Brian/All,

Sorry for wrong information in my earlier mail.... Error code "456 -
Parameter or Property appears twice in this Descriptor" is present for
avoiding multiple instances of properties/parameters. If A/T1 and B/T1 mean
the same doesn't this fall into the above error category.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Tuesday, May 29, 2001 5:47 PM
To: 'Chuong Nguyen'; megaco@fore.com
Subject: RE: Network Package


Well rtp/dur and nt/dur are "the same thing" in the sense that the mean the
same
thing, but if you implement (expose) both packages, then they are "separate"
statistics.  Using Events is perhaps easier to understand.  Suppose Package
A
implements event E1, and package B extends Package A, and a given
implementation
exposes both A and B, such that an audit of termination T1 returns
Packages{..A,B..}

You can say Add=T1{Events=123{B/E1}}
or you can say
Add=T1{Events=123{A/T1}}
or even
Add=T1{Events=123{A/T1,B/T1}}

In the latter, detection of the event would result in a notify of both.

Returning to statistics, the value would be the same, but they are separate
statistics.

Brian

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Tuesday, May 29, 2001 5:29 PM
To: megaco@fore.com
Subject: Re: Network Package


"Rosen, Brian" wrote:

If you implement any part of a package, you implement all of it.If a package
extends any part of a package, it extends all of it.

What is not required is that if you implement a package that extendsanother
package that you have to "expose" the underlying package.This means that if
you implement rtp you don't have to expose nt.If you list nt as one of the
packages in an audit, then you have toimplement nt/dur.


  I don't quite follow here.
               You seem to imply that nt/dur and rtp/dur are 2 different
things.
               I thought both nt/dur and rtp/dur are the same thing w/the
same value.
              If MG exposed nt, what should it return for duration - nt/dur
or rtp/dur?


Do you know the intend of tdmc/os and tdmc/or?
I thought the same as Madhubabu about how they are calculated.






Brian

-----Original Message-----
From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com
 ]
Sent: Tuesday, May 29, 2001 5:15 PM
To: 'Chuong Nguyen'
Cc: megaco@fore.com
Subject: RE: Network Package
Hi chuong/all,IMO if PackageB extends PackageA and if one of the
statistic/property of Package A is not valid for termination realizing
packageB then there is no reason why PackageB extends PackageA. Then
PackageB shouldn't extend PackageA (just only to reuse few
properties/statistics) but should define the same properties (Might be with
different IDs) in packageB. I think the extension of packages is logical if
the newly defined package can inherit "all" the properties already defined
in the base package and also define new properties. In your example, I was
in the impression that "OS" and "OR" can be calculated as "The number of
octet sent or received is equal to the duration of the Termination, in
seconds, multiplied by the sampling frequency,  8000 Hz.". (Of course this
seems to be redundant info if the MGC is aware of the sampling frequency).
Isn't this the intention?????-RegardsMadhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
 mailto:owner-megaco@pit.comms.marconi.com
 ]On Behalf Of Chuong Nguyen
Sent: Tuesday, May 29, 2001 4:38 PM
To: megaco@fore.com
Subject: Network Package
Hi All


Is it reasonable to assume that Network Package StatisticsID will never be
used directly?
That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os and rtp/or
respectiviely
since rtp package extends nt package.


I know that it is agreed that if a termination realizes rtp package, it also
realizes nt package
and either nt/.. or rtp/.. are valid packageName.


But if we allow, nt/... instead of rtp/.., are we saying that if MGC
receives nt/.., it has to
know whether it is for rtp or tmcd termination by the terminationID?



Furthermore, since tdmc package extends nt package, do "octet sent" (OS) and
"octet
received" (OR) really apply to tdm termination?


Also what does it mean for a TDM termination to realize the "NT" package
properties
of "Maximum Jitter Buffer"?


So a more general question, if a termination realizes a packageB that
extends
packageA and there are items in the packageA that does not make sense to
the termination what should MG/MGC do.


Take the above as an example and assuming that it does not make sense for
TDM
termination to have "OS" and "OR", what should MG return for TDM termination
statistics if the termination realizes "TDMC" package?
Just "duration".


---
Said it is valid to have "OS" and "OR" for TDM.
IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP
termination,
is it valid for MG to return nt/dur, nt/os and nt/or for the TDM termination
and RTP
termination instead of tdmc/dur, ... vs rtp/dur ?


Thanks
Chuong




--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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



From owner-megaco@fore.com  Wed May 30 11:14:10 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14376
	for ; Wed, 30 May 2001 11:14:09 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03867;
	Wed, 30 May 2001 10:59:38 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA11234
	for megaco-list; Wed, 30 May 2001 10:58:45 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11222
	for ; Wed, 30 May 2001 10:58:43 -0400 (EDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03720
	for ; Wed, 30 May 2001 10:58:41 -0400 (EDT)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA07576
	for ; Wed, 30 May 2001 09:58:42 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4UEwfT23579
	for ; Wed, 30 May 2001 09:58:41 -0500 (CDT)
Received: from chili2.ssd.usa.alcatel.com (chili2.ssd.usa.alcatel.com [143.209.202.136])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4UEwB116329
	for ; Wed, 30 May 2001 09:58:11 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by chili2.ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with ESMTP id JAA04833
	for ; Wed, 30 May 2001 09:58:09 -0500 (CDT)
Message-ID: <3B150A80.538BB2B2@usa.alcatel.com>
Date: Wed, 30 May 2001 09:58:09 -0500
From: Chuong Nguyen 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: megaco@fore.com
Subject: Re: Network Package
References: <9D6A470BD38ED311908000805F65B4EC04AE0933@rndex50.kanata.mitel.com>
Content-Type: multipart/alternative;
 boundary="------------776FAE2BD7BAA28F3428CEA8"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


--------------776FAE2BD7BAA28F3428CEA8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


See comment below:


> IS this clearly stated somewhere?
> This could be a nightmare for MGC to receive the same statistics value via 2 different
> parameter.  Talk about the overhead of parsing these text strings.

>
>
> [PB]  I believe this logic was given in the Implementors' Guide.  If it remains unclear, please let us all know what needs to be clarified.
>

  Are you referring to the following in IGv6  Section 12.1?

When packages are extended, the properties, events, signals and statistics defined in the base package can be referred to using either the extended package name.  For example, if Package A defines event e1, and Package B extends Package A, then B/e1 is an event for a termination implementing Package B. By definition, the MG MUST also implement the base Package, but it optional to publish the base package as an allowed interface.  If it does publish A, then A would be reported on the Package Descriptor in AuditValue as well as B, and event A/e1 would be available on a termination.  If the MG does not publish A, then only B/e1 would be available.  If published through AuditValue, A/e1 and B/e1 are the same event.
For the purpose of improved interoperability and backward compatibility, the an MG MAY publish all Packages supported by its Terminations, including base Packages from which extended Packages are derived.  An exception to this is in cases where the base packages are expressly designed to be extended by others, not directly controlled, and may not have any function on their own or be nonsensical on their own, in which case the MG SHOULD NOT publish the base Packages.

  I don't see anything remotely stating what we are discussing about statistics and
               event reporting.   Specifically that one can get duplicate statistics.


>
> [PB] Yes, there would be double the overhead, but that's not really different overhead from MGC asking for 2 sets of statistics from different sources.
>

  I am using the case of Subtract Request which does not specify any parameter.
              Thus MG will reply w/all statistics in which case MGC will receive duplicate
              statistics.

>
>  Can someone answer the question what does it mean for tdmc package to
> extend nt package property of "Maximum Jitter Buffer"?
>
> [PB] My opinion, not as author of the tdmc Package,  is the property should simply always be 0.  There is no jitter buffer.  I agree this is not a very interesting value, so if the MGC is not interested it should not ask, and if its software is designed to handle the general case of any package extending from nt, it better be able to handle 0 as the answer.
>

  So in general if a package that extends another package and there is some parameters
               that might not apply, we do not flag it as an error but assume some default value
               and treat it as a nop?

              So does NT package qualify as a "base package" based on the definition of what
              a "base package" is as quoted above -

     An exception to this is in cases where the base packages are expressly designed to be extended by others, not directly controlled, and may not have any function on their own or be nonsensical on their own, in which case the MG SHOULD NOT publish the base Packages.

     Should something be added to each package to define whether it is a "base package"
     which meant that it can't be used on its own?

     NT package is one example to me since each termination that realizes this package must
     belong to some network type which should have its own network-type package (RTP,
     TDM, ATM, etc).



--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------776FAE2BD7BAA28F3428CEA8
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

See comment below:

 

IS this clearly stated somewhere?

This could be a nightmare for MGC to receive the same statistics value
via 2 different

parameter.  Talk about the overhead of parsing these text strings.



 

[PB]  I believe this logic was given in the Implementors' Guide. 
If it remains unclear, please let us all know what needs to be clarified.

 

<cnn>  Are you referring to the following in IGv6  Section
12.1?

When packages are extended, the properties, events, signals and statistics
defined in the base package can be referred to using either the extended
package name.  For example, if Package A defines event e1, and Package
B extends Package A, then B/e1 is an event for a termination implementing
Package B. By definition, the MG MUST also implement the base Package,
but it optional to publish the base package as an allowed interface. 
If it does publish A, then A would be reported on the Package Descriptor
in AuditValue as well as B, and event A/e1 would be available on a termination. 
If the MG does not publish A, then only B/e1 would be available. 
If published through AuditValue, A/e1 and B/e1 are the same event.

For the purpose of improved interoperability and backward compatibility,
the an MG MAY publish all Packages supported by its Terminations, including
base Packages from which extended Packages are derived.  An exception
to this is in cases where the base packages are expressly designed to be
extended by others, not directly controlled, and may not have any function
on their own or be nonsensical on their own, in which case the MG SHOULD
NOT publish the base Packages.

<cnn>  I don't see anything remotely stating what we are discussing
about statistics and

              
event reporting.   Specifically that one can get duplicate statistics.

 

 

[PB] Yes, there would be double the overhead, but that's not really
different overhead from MGC asking for 2 sets of statistics from different
sources.

 

<cnn>  I am using the case of Subtract Request which does
not specify any parameter.

             
Thus MG will reply w/all statistics in which case MGC will receive duplicate

             
statistics.

 

 Can someone answer the question what does it mean for tdmc package
to

extend nt package property of "Maximum Jitter Buffer"?

[PB] My opinion, not as author of the tdmc Package,  is the property
should simply always be 0.  There is no jitter buffer.  I agree
this is not a very interesting value, so if the MGC is not interested it
should not ask, and if its software is designed to handle the general case
of any package extending from nt, it better be able to handle 0 as the
answer.

 

<cnn>  So in general if a package that extends another package
and there is some parameters

              
that might not apply, we do not flag it as an error but assume some default
value

              
and treat it as a nop?

             
So does NT package qualify as a "base package" based on the definition
of what

             
a "base package" is as quoted above -

An exception to this is in cases where the base packages
are expressly designed to be extended by others, not directly controlled,
and may not have any function on their own or be nonsensical on their own,
in which case the MG SHOULD NOT publish the base Packages.

Should something be added to each package to define whether it is a
"base package"

which meant that it can't be used on its own?

NT package is one example to me since each termination that realizes
this package must

belong to some network type which should have its own network-type
package (RTP,

TDM, ATM, etc).

 

 



-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

 

--------------776FAE2BD7BAA28F3428CEA8--



From owner-megaco@fore.com  Wed May 30 13:41:01 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19300
	for ; Wed, 30 May 2001 13:41:00 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA17001;
	Wed, 30 May 2001 13:24:54 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA19068
	for megaco-list; Wed, 30 May 2001 13:23:13 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19050
	for ; Wed, 30 May 2001 13:23:10 -0400 (EDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA16757
	for ; Wed, 30 May 2001 13:23:07 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id DAA09033;
	Thu, 31 May 2001 03:22:10 +1000 (EST)
Received: from ericsson.com ([130.100.249.203])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id DAA09868;
	Thu, 31 May 2001 03:22:53 +1000 (EST)
Message-ID: <3B1501D1.905CA024@ericsson.com>
Date: Thu, 31 May 2001 00:21:05 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" 
CC: "'vibansal@hss.hns.com'" , megaco@fore.com
Subject: Re: Version negotiation
References: <4FBEA8857476D311A03300204840E1CF04465473@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

I agree with Brian. This is something "possibly" for v2. We have the
negotiation mechanism that we require and as backward compatibility is
required you should never have the case where you can't agree on a
version. If you can't agree on a version the it really depends on your
network scenario. I think the best thing to do is notify O&M.

Cheers, Christian

"Rosen, Brian" wrote:
> 
> The situation is pretty complicated, and the action taken may
> depend on a lot of things.  There are several strategies an MG
> could use, including trying secondary MGCs.  One of the variables
> is what profile the MGC offers; if it offers the correct profile,
> but it's version of Megaco is earlier, and the MG can deal with
> the older version, then it might stay with the MGC, or, it might
> try secondary MGCs looking for a better fit.
> 
> As there is only one version, I'd defer any text changes until this
> is a real problem.
> 
> Brian
> 
> > -----Original Message-----
> > From: vibansal@hss.hns.com [mailto:vibansal@hss.hns.com]
> > Sent: Tuesday, May 29, 2001 6:59 AM
> > To: megaco@fore.com
> > Subject: Version negotiation
> >
> >
> >
> >
> >
> > Hi Christian,
> >
> > Since nobody replied back to my mail so should I assume that
> > in case the version
> > negotiations fails with MGC, then MG should try with the
> > secondary MGCs. In this
> > case we need to make change in the text of the protocol.
> >
> > Regards
> > Vivek Bansal
> >
> >
> > ---------------------- Forwarded by Vivek Bansal/HSS on
> > 05/29/2001 04:19 PM
> > ---------------------------
> >
> > To:   megaco@fore.com
> > cc:    (bcc: Sachin Sikri/HSS)
> >
> > Subject:  Version negotiation
> >
> >
> >
> >
> >
> >
> >
> > Hi
> >
> > If the version negotiations fails at MG, then what should be
> > the recovery
> > action. Protocols says close the netwrok connection and give
> > error to MGC in
> > case of any transaction from MGC. But it does not specify
> > what should MG do
> > after the failure. Should it try to contact the other
> > provisioned MGCs. or is it
> > assumed that all the MGCs are configured with the same
> > version and MG will not
> > be able to create association with them.
> >
> > Please  clarify this.
> >
> > Regards
> > Vivek
> >
> >
> >
> >
> >
> >
> >




From owner-megaco@fore.com  Wed May 30 15:25:47 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22328
	for ; Wed, 30 May 2001 15:25:46 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA27596;
	Wed, 30 May 2001 15:13:20 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA16968
	for megaco-list; Wed, 30 May 2001 15:12:34 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA16944
	for ; Wed, 30 May 2001 15:12:31 -0400 (EDT)
Received: from mail.mediatrix.com (mail.mediatrix.com [205.237.248.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA27413
	for ; Wed, 30 May 2001 15:12:27 -0400 (EDT)
Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 30 May 2001 15:07:48 -0400
Message-ID: 
From: Steven Weisz 
To: "Megaco Mailing List (E-mail)" 
Subject: ABNF Question: digit maps embedded in events
Date: Wed, 30 May 2001 15:07:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hi List,

I asked this question a few weeks ago and still have not found an answer.
Does anyone have an opinion?

It is a quick question concerning a digit map embedded in a requested event.
Specifically, if you look at the ABNF the embedded digit map is defined as

eventDM = DigitMapToken (( EQUAL digitMapName ) / (LBRKT digitMapValue
RBRKT))

and a digit map descriptor is defined as:

digitMapDescriptor = DigitMapToken EQUAL (( LBRKT digitMapValue RBRKT ) / 
		         ( digitMapName [LBRKT digitMapValue RBRKT] ))

It obvious that they are very similar, as I believe was intended but there
is one thing that is bothering me in eventDM. That is it seems to me that
the EQUAL should be right after DigitMapToken as is the case in
digitMapDescriptor. So we would instead have:

eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT digitMapValue
RBRKT))

Does this make sense?

Thanks,

Steve



From owner-megaco@fore.com  Wed May 30 15:45:27 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22643
	for ; Wed, 30 May 2001 15:45:27 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA25759;
	Wed, 30 May 2001 14:54:27 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA12215
	for megaco-list; Wed, 30 May 2001 14:52:18 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA12211
	for ; Wed, 30 May 2001 14:52:17 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA25438
	for ; Wed, 30 May 2001 14:52:08 -0400 (EDT)
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f4UIpwE00306
	for ; Wed, 30 May 2001 14:51:58 -0400 (EDT)
Received: from ztcfd004.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 30 May 2001 14:52:00 -0400
Received: by ztcfd004.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 30 May 2001 14:52:00 -0400
Message-ID: <45D2A43C1913D51180F40000F89CB874062E58@nrtpde0a.us.nortel.com>
From: "Michael Brown" 
To: megaco@fore.com
Subject: RE: Network Package
Date: Wed, 30 May 2001 14:52:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E939.9C1F7990"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E939.9C1F7990
Content-Type: text/plain;
	charset="iso-8859-1"

Comments inline.

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Wednesday, May 30, 2001 10:58 AM
To: megaco@fore.com
Subject: Re: Network Package


  
See comment below: 
  

IS this clearly stated somewhere? 
This could be a nightmare for MGC to receive the same statistics value via 2
different 
parameter.  Talk about the overhead of parsing these text strings.

  

[PB]  I believe this logic was given in the Implementors' Guide.  If it
remains unclear, please let us all know what needs to be clarified. 
 

  Are you referring to the following in IGv6  Section 12.1? 

When packages are extended, the properties, events, signals and statistics
defined in the base package can be referred to using either the extended
package name.  For example, if Package A defines event e1, and Package B
extends Package A, then B/e1 is an event for a termination implementing
Package B. By definition, the MG MUST also implement the base Package, but
it optional to publish the base package as an allowed interface.  If it does
publish A, then A would be reported on the Package Descriptor in AuditValue
as well as B, and event A/e1 would be available on a termination.  If the MG
does not publish A, then only B/e1 would be available.  If published through
AuditValue, A/e1 and B/e1 are the same event. 
For the purpose of improved interoperability and backward compatibility, the
an MG MAY publish all Packages supported by its Terminations, including base
Packages from which extended Packages are derived.  An exception to this is
in cases where the base packages are expressly designed to be extended by
others, not directly controlled, and may not have any function on their own
or be nonsensical on their own, in which case the MG SHOULD NOT publish the
base Packages. 


  I don't see anything remotely stating what we are discussing about
statistics and 
               event reporting.   Specifically that one can get duplicate
statistics. 

[MB] I would disagree as I think the IG statements are definitely related
although perhaps not complete. There are two different issues here. First is
the case where the MGC is specifically asking for certain statistics. This
is covered by the spec along the lines of the earlier statements that the
MGC is in control and if it asks for something stupid, well, the MG should
do it. 

The second issue is a bit more problematic (the Subtract request resulting
in reporting of statistics); however, the behavior of the MG in reporting
statistics is based on which packages are "published" by the MG. If the MG
implementation publishes both a base package and a package that extends that
base package, then the default behavior would be to report both statistics.
I don't mean to say that it is a useful thing to do... just that it is what
will happen. The point is that IMO publishing both the packages is a poor
implementation choice on the part of the MG. So, this gets to your
question... do we need to document that this is a poor implementation
choice? I'm not really convinced that it is necessary.

[PB] Yes, there would be double the overhead, but that's not really
different overhead from MGC asking for 2 sets of statistics from different
sources. 
 

  I am using the case of Subtract Request which does not specify any
parameter. 
              Thus MG will reply w/all statistics in which case MGC will
receive duplicate 
              statistics.
[MB] Issue #2 above.  


 Can someone answer the question what does it mean for tdmc package to 
extend nt package property of "Maximum Jitter Buffer"? 

[PB] My opinion, not as author of the tdmc Package,  is the property should
simply always be 0.  There is no jitter buffer.  I agree this is not a very
interesting value, so if the MGC is not interested it should not ask, and if
its software is designed to handle the general case of any package extending
from nt, it better be able to handle 0 as the answer. 
 

  So in general if a package that extends another package and there is
some parameters 
               that might not apply, we do not flag it as an error but
assume some default value 
               and treat it as a nop? 

              So does NT package qualify as a "base package" based on the
definition of what 
              a "base package" is as quoted above - 


An exception to this is in cases where the base packages are expressly
designed to be extended by others, not directly controlled, and may not have
any function on their own or be nonsensical on their own, in which case the
MG SHOULD NOT publish the base Packages. 

Should something be added to each package to define whether it is a "base
package" 
which meant that it can't be used on its own? 


NT package is one example to me since each termination that realizes this
package must 
belong to some network type which should have its own network-type package
(RTP, 
TDM, ATM, etc).

  
[MB]  The fact is that the Jitter Buffer property WAS supposed to be moved
from the Network to the RTP package. Initially, there was only a network
package and it had all of the properties that now reside in RTP package.
After discussion about support of other network types, it was agreed that
the approach that you describe in the previous paragraph was the right one
and the RTP package was created. I don't remember why the Jitter Buffer
parameter didn't get moved, but this was pointed out at that time and the
intent was that it would be moved to the RTP package before publication of
the version 1 spec. Unfortunately, the change didn't get made and was
overlooked at the time of determination/Last Call. So, there we have it...
The Network package was supposed to be a generic base package, but it isn't
exactly. As far as what should be done, unfortunately, based on the existing
rules for versioning (which I think we should revisit), we aren't able to
simply remove the property from the Network package in a new version. So, I
think that the right thing is to include some text in the Network Package to
deprecate the use of the Jitter Buffer property there (I don't believe that
this would qualify as a new verion of the package) and upversion the RTP
package and add the property. (Just by the way, this upversioning of the
package would, I think, not necessarily have to wait for Version 2 of the
H.248 spec since versioning of a package is not necessarily tied to a
particular version of the base protocol.)

[MB] I think that your suggestion that in general we should handle this type
of error as a NOP really isn't a good rule of thumb as a "fix". It is OK as
a workaround, but the package should ultimately be fixed (or done right to
begin with :-) ).


 [MB] One other thing was about whether we should add something stating that
a package is a base package. I'm not adamantly opposed to the idea, but I
really don't think it's necessary. 

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

  


------_=_NextPart_001_01C0E939.9C1F7990
Content-Type: text/html;
	charset="iso-8859-1"









Comments inline.



  
-----Original Message-----
From: Chuong Nguyen 
  [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Wednesday, May 30, 2001 
  10:58 AM
To: megaco@fore.com
Subject: Re: Network 
  Package

  
See comment below: 
  
  
IS this clearly stated somewhere? 
This could be 
    a nightmare for MGC to receive the same statistics value via 2 different 
    
parameter.  Talk about the overhead of parsing these text 
  strings.

  
  
    
[PB]  I believe this logic was given in the Implementors' 
    Guide.  If it remains unclear, please let us all know what needs to be 
    clarified. 
 
<cnn>  Are you referring to 
  the following in IGv6  Section 12.1? 
  
When packages are extended, the properties, events, signals and 
  statistics defined in the base package can be referred to using either the 
  extended package name.  For example, if Package A defines event e1, and 
  Package B extends Package A, then B/e1 is an event for a termination 
  implementing Package B. By definition, the MG MUST also implement the base 
  Package, but it optional to publish the base package as an allowed 
  interface.  If it does publish A, then A would be reported on the Package 
  Descriptor in AuditValue as well as B, and event A/e1 would be available on a 
  termination.  If the MG does not publish A, then only B/e1 would be 
  available.  If published through AuditValue, A/e1 and B/e1 are the same 
  event. 
For the purpose of improved interoperability and backward 
  compatibility, the an MG MAY publish all Packages supported by its 
  Terminations, including base Packages from which extended Packages are 
  derived.  An exception to this is in cases where the base packages are 
  expressly designed to be extended by others, not directly controlled, and may 
  not have any function on their own or be nonsensical on their own, in which 
  case the MG SHOULD NOT publish the base Packages. 
  
<cnn>  I don't see anything remotely stating what we are 
  discussing about statistics and 
  
               
  event reporting.   Specifically that one can get duplicate 
  statistics. 

[MB] I would disagree as I think the IG 
  statements are definitely related although perhaps not complete. There are two 
  different issues here. First is the case where the MGC is specifically asking 
  for certain statistics. This is covered by the spec along the lines of the 
  earlier statements that the MGC is in control and if it asks for something 
  stupid, well, the MG should do it. 

  
The 
  second issue is a bit more problematic (the Subtract request resulting in 
  reporting of statistics); however, the behavior of the MG in reporting 
  statistics is based on which packages are "published" by the MG. If the MG 
  implementation publishes both a base package and a package that extends that 
  base package, then the default behavior would be to report both statistics. I 
  don't mean to say that it is a useful thing to do... just that it is what will 
  happen. The point is that IMO publishing both the packages is a poor 
  implementation choice on the part of the MG. So, this gets to your question... 
  do we need to document that this is a poor implementation choice? I'm not 
  really convinced that it is necessary.

  
[PB] Yes, there would be double the 
  overhead, but that's not really different overhead from MGC asking for 2 sets 
  of statistics from different sources. 
 
<cnn>  
  I am using the case of Subtract Request which does not specify any 
  parameter. 
  
              
  Thus MG will reply w/all statistics in which case MGC will receive duplicate 
  
              
  statistics.
[MB] Issue #2 above.  
  
 
 Can someone answer the question what does 
    it mean for tdmc package to 
extend nt package property of "Maximum 
    Jitter Buffer"? 
    
[PB] My opinion, not as author of the tdmc Package,  is the property 
    should simply always be 0.  There is no jitter buffer.  I agree 
    this is not a very interesting value, so if the MGC is not interested it 
    should not ask, and if its software is designed to handle the general case 
    of any package extending from nt, it better be able to handle 0 as the 
    answer. 
 
<cnn>  So in general if a 
  package that extends another package and there is some parameters 
  
               
  that might not apply, we do not flag it as an error but assume some default 
  value 
  
               
  and treat it as a nop? 
  
              
  So does NT package qualify as a "base package" based on the definition of what 
  
              
  a "base package" is as quoted above - 
  
An exception to this is in cases where the base packages are 
    expressly designed to be extended by others, not directly controlled, and 
    may not have any function on their own or be nonsensical on their own, in 
    which case the MG SHOULD NOT publish the base Packages. 
    
Should something be added to each package to define whether it is a "base 
    package" 
which meant that it can't be used on its own? 
    
NT package is one example to me since each termination that realizes this 
    package must 
belong to some network type which should have its own 
    network-type package (RTP, 
TDM, ATM, etc).

    
  
[MB]  The fact is that the Jitter Buffer property WAS 
    supposed to be moved from the Network to the RTP package. Initially, there 
    was only a network package and it had all of the properties that now reside 
    in RTP package. After discussion about support of other network types, 
    it was agreed that the approach that you describe in the previous paragraph 
    was the right one and the RTP package was created. I don't remember why the 
    Jitter Buffer parameter didn't get moved, but this was pointed out 
    at that time and the intent was that it would be moved to the RTP package 
    before publication of the version 1 spec. Unfortunately, the 
    change didn't get made and was overlooked at the time of 
    determination/Last Call. So, there we have it... The Network package was 
    supposed to be a generic base package, but it isn't exactly. As far as what 
    should be done, unfortunately, based on the existing rules for versioning 
    (which I think we should revisit), we aren't able to simply remove the 
    property from the Network package in a new version. So, I think that the 
    right thing is to include some text in the Network Package to deprecate the 
    use of the Jitter Buffer property there (I don't believe that this would 
    qualify as a new verion of the package) and upversion the RTP package 
    and add the property. (Just by the way, this upversioning of the 
    package would, I think, not necessarily have to wait for Version 2 of the 
    H.248 spec since versioning of a package is not necessarily tied to a 
    particular version of the base protocol.)

    
[MB] I think that your suggestion that in 
    general we should handle this type of error as a NOP really isn't a 
    good rule of thumb as a "fix". It is OK as a workaround, but the package 
    should ultimately be fixed (or done right to begin with :-) 
    ).

    

 [MB] One 
    other thing was about whether we should add something stating that a package 
    is a base package. I'm not adamantly opposed to the idea, but I really don't 
    think it's necessary. 

    
-- 
  Alcatel USA, 
    Inc             
    Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, 
    Texas 75075           
    Phone:    (972) 519-4613
  **** The opinions 
    expressed are not those of Alcatel USA, Inc ****
  



------_=_NextPart_001_01C0E939.9C1F7990--


From owner-megaco@fore.com  Wed May 30 15:53:05 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22769
	for ; Wed, 30 May 2001 15:53:04 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA00697;
	Wed, 30 May 2001 15:45:12 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA23999
	for megaco-list; Wed, 30 May 2001 15:44:31 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA23983
	for ; Wed, 30 May 2001 15:44:29 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 30 May 2001 15:44:29 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF044654AD@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Steven Weisz'" ,
        "Megaco Mailing List (E-mail)"
	 
Cc: "Tom Taylor (E-mail)" 
Subject: RE: ABNF Question: digit maps embedded in events
Date: Wed, 30 May 2001 15:44:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

I usually defer to Tom on any digitMap questions. 
I can't tell you how many hours I (and several others
including Abdullah Rayhan) spent pouring over the
ABNF to ferret out such problems.

Yes, I agree, it should be 
digitMap={...
and not
digitMap{...

I think this qualifies as a typo and deserves an IG entry.
Tom, do you agree?

Brian

> -----Original Message-----
> From: Steven Weisz [mailto:sweisz@mediatrix.com]
> Sent: Wednesday, May 30, 2001 3:08 PM
> To: Megaco Mailing List (E-mail)
> Subject: ABNF Question: digit maps embedded in events
> 
> 
> Hi List,
> 
> I asked this question a few weeks ago and still have not 
> found an answer.
> Does anyone have an opinion?
> 
> It is a quick question concerning a digit map embedded in a 
> requested event.
> Specifically, if you look at the ABNF the embedded digit map 
> is defined as
> 
> eventDM = DigitMapToken (( EQUAL digitMapName ) / (LBRKT digitMapValue
> RBRKT))
> 
> and a digit map descriptor is defined as:
> 
> digitMapDescriptor = DigitMapToken EQUAL (( LBRKT 
> digitMapValue RBRKT ) / 
> 		         ( digitMapName [LBRKT digitMapValue RBRKT] ))
> 
> It obvious that they are very similar, as I believe was 
> intended but there
> is one thing that is bothering me in eventDM. That is it 
> seems to me that
> the EQUAL should be right after DigitMapToken as is the case in
> digitMapDescriptor. So we would instead have:
> 
> eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT digitMapValue
> RBRKT))
> 
> Does this make sense?
> 
> Thanks,
> 
> Steve
> 


From owner-megaco@fore.com  Wed May 30 15:53:31 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22785
	for ; Wed, 30 May 2001 15:53:30 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA00499;
	Wed, 30 May 2001 15:44:10 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA23837
	for megaco-list; Wed, 30 May 2001 15:43:32 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA23824
	for ; Wed, 30 May 2001 15:43:30 -0400 (EDT)
Received: from sapphire.int.ipverse.com ([65.195.29.42])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA00381
	for ; Wed, 30 May 2001 15:43:27 -0400 (EDT)
Received: from matt.ipverse.com (MATT [10.1.1.220]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id L4T5HGLQ; Wed, 30 May 2001 12:43:22 -0700
Message-Id: <5.1.0.14.2.20010530124256.0240d790@mail.ipverse.com>
X-Sender: matt@mail.ipverse.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 30 May 2001 12:43:21 -0700
To: "Tom-PT Taylor" , megaco@fore.com
From: Matt Holdrege 
Subject: RE: I-D ACTION:draft-ietf-megaco-mib-02.txt
In-Reply-To: <28560036253BD41191A10000F8BCBD110250CBFB@zcard00g.ca.norte
 l.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

The issues I presented can be viewed here 
http://www.net-standards.org/MEGACO-mib.ppt


At 06:34 AM 5/30/2001, Tom-PT Taylor wrote:

>I would like to explain briefly what has happened with this 
>draft.  Basically it consists of a reorganization and extension of 
>material available in the initial draft (mib-00).  As such, it presents a 
>coherent view and may be the basis of a working MIB.  A word of warning 
>comes along with this: Matt Holdrege identified a lot of open issues two 
>meetings ago, and a number of these undoubtedly remain open.  I will get 
>Matt's meeting presentation and post it on the Megaco web site for people 
>to examine.
>
>Given the large effort Michael Brown and colleagues put into the latest 
>draft, Michael's name has been added to the authors' list and Michael has 
>taken over primary editorial responsibilities from Matt.  I know that this 
>has been a frustrating task for Matt due to lack of input from the 
>WG.  Thanks to him and Ilya Akramovich for getting us started.  Now let's 
>get this done so we can stop showing a milestone that's two years late!
>
>Tom Taylor
>Multimedia Control and Applications Standards
>Ph.  +1 613 736 0961
>taylor@nortelnetworks.com
>
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org 
> [mailto:Internet-Drafts@ietf.org]
> > Sent: Wednesday, May 30, 2001 6:47 AM
> > To: IETF-Announce
> > Cc: megaco@fore.com
> > Subject: I-D ACTION:draft-ietf-megaco-mib-02.txt
> >
> >
> > A New Internet-Draft is available from the on-line
> > Internet-Drafts directories.
> > This draft is a work item of the Media Gateway Control
> > Working Group of the IETF.
> >
> >       Title           : MEGACO MIB
> >       Author(s)       : M. Holdrege, I. Akramovich, C. Brown
> >       Filename        : draft-ietf-megaco-mib-02.txt
> >       Pages           : 25
> >       Date            : 29-May-01
> >
> > This memo defines a portion of the Management Information Base (MIB)
> > for use with network management protocols in the Internet community.
> > In particular, it defines objects for use by the MEGACO/H.248
> > protocol operating on Media Gateways and Media Gateway Controllers.
> >
> > A URL for this Internet-Draft is:
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-megaco-mib-02.txt 
>
> >
> > Internet-Drafts are also available by anonymous FTP. Login
> > with the username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> >       "get draft-ietf-megaco-mib-02.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt 
>
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> >       mailserv@ietf.org.
> > In the body type:
> >       "FILE /internet-drafts/draft-ietf-megaco-mib-02.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
> >       MIME-encoded form by using the "mpack" utility.  To use this
> >       feature, insert the command "ENCODING mime" before the "FILE"
> >       command.  To decode the response(s), you will need "munpack" or
> >       a MIME-compliant mail reader.  Different MIME-compliant
> > mail readers
> >       exhibit different behavior, especially when dealing with
> >       "multipart" MIME messages (i.e. documents which have been split
> >       up into multiple messages), so check your local documentation on
> >       how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >



From owner-megaco@fore.com  Wed May 30 16:01:01 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22925
	for ; Wed, 30 May 2001 16:01:00 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA29640;
	Wed, 30 May 2001 15:35:26 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA21951
	for megaco-list; Wed, 30 May 2001 15:34:46 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA21913
	for ; Wed, 30 May 2001 15:34:42 -0400 (EDT)
Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA29517
	for ; Wed, 30 May 2001 15:34:38 -0400 (EDT)
Received: from plong (cs666831-163.austin.rr.com [66.68.31.163])
	by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4UJYYu3001103
	for ; Wed, 30 May 2001 14:34:34 -0500
From: "Paul Long" 
To: "Megaco Mailing List \(E-mail\)" 
Subject: RE: ABNF Question: digit maps embedded in events
Date: Wed, 30 May 2001 14:34:30 -0500
Message-ID: 
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)
In-Reply-To: 
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Well, if you're just looking for someone to reply... :-)

I hadn't noticed this difference before, but your recommendation makes
sense. However, it is too late to change now, so it's a moot point.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Steven Weisz
Sent: Wednesday, May 30, 2001 2:08 PM
To: Megaco Mailing List (E-mail)
Subject: ABNF Question: digit maps embedded in events


Hi List,

I asked this question a few weeks ago and still have not found an answer.
Does anyone have an opinion?

It is a quick question concerning a digit map embedded in a requested event.
Specifically, if you look at the ABNF the embedded digit map is defined as

eventDM = DigitMapToken (( EQUAL digitMapName ) / (LBRKT digitMapValue
RBRKT))

and a digit map descriptor is defined as:

digitMapDescriptor = DigitMapToken EQUAL (( LBRKT digitMapValue RBRKT ) /
		         ( digitMapName [LBRKT digitMapValue RBRKT] ))

It obvious that they are very similar, as I believe was intended but there
is one thing that is bothering me in eventDM. That is it seems to me that
the EQUAL should be right after DigitMapToken as is the case in
digitMapDescriptor. So we would instead have:

eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT digitMapValue
RBRKT))

Does this make sense?

Thanks,

Steve



From owner-megaco@fore.com  Wed May 30 16:18:49 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23442
	for ; Wed, 30 May 2001 16:18:48 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA01660;
	Wed, 30 May 2001 15:53:19 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA25832
	for megaco-list; Wed, 30 May 2001 15:52:14 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA25813
	for ; Wed, 30 May 2001 15:52:12 -0400 (EDT)
Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA01539
	for ; Wed, 30 May 2001 15:52:09 -0400 (EDT)
Received: from MBRAHMANAPALLY ([64.69.123.124])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id ACP46504;
	Wed, 30 May 2001 15:51:51 -0400 (EDT)
From: "Madhu Babu Brahmanapally" 
To: "'Paul Long'" ,
        "'Megaco Mailing List \(E-mail\)'" 
Subject: RE: ABNF Question: digit maps embedded in events
Date: Wed, 30 May 2001 15:54:55 -0400
Message-ID: <00ff01c0e942$66745ff0$c500a8c0@MBRAHMANAPALLY>
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 CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: 
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

HI all,

But this a potential candidate for including in the next version of Megaco.
If not in IG might be some where else, so that we wont miss these.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Paul Long
Sent: Wednesday, May 30, 2001 3:35 PM
To: Megaco Mailing List (E-mail)
Subject: RE: ABNF Question: digit maps embedded in events


Well, if you're just looking for someone to reply... :-)

I hadn't noticed this difference before, but your recommendation makes
sense. However, it is too late to change now, so it's a moot point.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Steven Weisz
Sent: Wednesday, May 30, 2001 2:08 PM
To: Megaco Mailing List (E-mail)
Subject: ABNF Question: digit maps embedded in events


Hi List,

I asked this question a few weeks ago and still have not found an answer.
Does anyone have an opinion?

It is a quick question concerning a digit map embedded in a requested event.
Specifically, if you look at the ABNF the embedded digit map is defined as

eventDM = DigitMapToken (( EQUAL digitMapName ) / (LBRKT digitMapValue
RBRKT))

and a digit map descriptor is defined as:

digitMapDescriptor = DigitMapToken EQUAL (( LBRKT digitMapValue RBRKT ) /
		         ( digitMapName [LBRKT digitMapValue RBRKT] ))

It obvious that they are very similar, as I believe was intended but there
is one thing that is bothering me in eventDM. That is it seems to me that
the EQUAL should be right after DigitMapToken as is the case in
digitMapDescriptor. So we would instead have:

eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT digitMapValue
RBRKT))

Does this make sense?

Thanks,

Steve



From owner-megaco@fore.com  Wed May 30 16:40:44 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24127
	for ; Wed, 30 May 2001 16:40:44 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA03373;
	Wed, 30 May 2001 16:14:19 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA00375
	for megaco-list; Wed, 30 May 2001 16:12:06 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA00341
	for ; Wed, 30 May 2001 16:10:38 -0400 (EDT)
Received: from pine.cyberpathinc.com ([38.246.253.128])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA02977
	for ; Wed, 30 May 2001 16:10:35 -0400 (EDT)
Received: from YSHA (ysha [172.30.30.41])
	by pine.cyberpathinc.com (8.9.3+Sun/8.9.3) with SMTP id QAA07243;
	Wed, 30 May 2001 16:12:21 -0400 (EDT)
Received: by YSHA with Microsoft Mail
	id <01C0E923.1DC104D0@YSHA>; Wed, 30 May 2001 16:10:59 -0400
Message-ID: <01C0E923.1DC104D0@YSHA>
From: YouLing Sha 
To: "'Madhu Babu Brahmanapally'" ,
        "'Paul Long'"
	 ,
        "'Megaco Mailing List (E-mail)'"
	 
Subject: RE: ABNF Question: digit maps embedded in events
Date: Wed, 30 May 2001 16:10:43 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

By the way, does anyone know when the next version of Megaco is going to be available?

Regards,
YouLing Sha



-----Original Message-----
From:	Madhu Babu Brahmanapally [SMTP:madhubabu@kenetec.com]
Sent:	Wednesday, May 30, 2001 3:55 PM
To:	'Paul Long'; 'Megaco Mailing List (E-mail)'
Subject:	RE: ABNF Question: digit maps embedded in events

HI all,

But this a potential candidate for including in the next version of Megaco.
If not in IG might be some where else, so that we wont miss these.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Paul Long
Sent: Wednesday, May 30, 2001 3:35 PM
To: Megaco Mailing List (E-mail)
Subject: RE: ABNF Question: digit maps embedded in events


Well, if you're just looking for someone to reply... :-)

I hadn't noticed this difference before, but your recommendation makes
sense. However, it is too late to change now, so it's a moot point.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Steven Weisz
Sent: Wednesday, May 30, 2001 2:08 PM
To: Megaco Mailing List (E-mail)
Subject: ABNF Question: digit maps embedded in events


Hi List,

I asked this question a few weeks ago and still have not found an answer.
Does anyone have an opinion?

It is a quick question concerning a digit map embedded in a requested event.
Specifically, if you look at the ABNF the embedded digit map is defined as

eventDM = DigitMapToken (( EQUAL digitMapName ) / (LBRKT digitMapValue
RBRKT))

and a digit map descriptor is defined as:

digitMapDescriptor = DigitMapToken EQUAL (( LBRKT digitMapValue RBRKT ) /
		         ( digitMapName [LBRKT digitMapValue RBRKT] ))

It obvious that they are very similar, as I believe was intended but there
is one thing that is bothering me in eventDM. That is it seems to me that
the EQUAL should be right after DigitMapToken as is the case in
digitMapDescriptor. So we would instead have:

eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT digitMapValue
RBRKT))

Does this make sense?

Thanks,

Steve




From owner-megaco@fore.com  Wed May 30 16:57:12 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24508
	for ; Wed, 30 May 2001 16:57:12 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA04354;
	Wed, 30 May 2001 16:24:43 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA03757
	for megaco-list; Wed, 30 May 2001 16:22:32 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA03747
	for ; Wed, 30 May 2001 16:22:30 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA04130
	for ; Wed, 30 May 2001 16:22:27 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1])
	by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f4UKMSM18793
	for ; Wed, 30 May 2001 16:22:28 -0400 (EDT)
Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2])
	by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f4UKMPV18720;
	Wed, 30 May 2001 16:22:25 -0400 (EDT)
Received: from 7460gratta.ho.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id QAA03855; Wed, 30 May 2001 16:22:23 -0400
Message-Id: <200105302022.QAA03855@hotair.hobl.lucent.com>
From: "Greg Ratta" 
To: sob@harvard.edu, mankin@isi.edu
Date: Wed, 30 May 2001 16:22:23 -0400
MIME-Version: 1.0
Content-type: text/enriched; charset=ISO-8859-1
Content-transfer-encoding: Quoted-printable
Subject: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL
Reply-to: gratta@lucent.com
CC: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu,
        megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org,
        tsvwg@ietf.org, Yukio Hiramatsu ,
        rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch
X-mailer: Pegasus Mail for Win32 (v3.01d)
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: Quoted-printable

This message was agreed to at ITU-T Study Group 11 meeting 
(Geneva, May 2001) and is being transmitted on behalf of Yukio 
Hiramatsu, Chairman of ITU-T SG 11. For further technical 
clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 
1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com)


FULL TITLE:  Times New RomanPROPOSED JOINT ACTI=
VITY ON A GENERIC 
PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE 
CONTROL AND 0100,0100,0100SIGNALLING PROTOCOL DEVELO=
PMENT BASED 
ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES




rightCourier NewGene=
ral


rightWithin ITU-T SG11 work has started on 
requirements for a generic protocol mechanism 
for end-to-end QoS service control. It was 
agreed within SG11 to proceed with this work 
utilising deliverables of ETSI TIPHON on end-
to-end QoS service control as base material. 
It is the opinion of SG11 that this generic 
protocol mechanism for BICC intends to apply 
also to other protocols like SIP/SDP and 
H.323 next to generic extensions to the 
H.248/MEGACO protocol.


rightIt was noted that also QoS related work is=
 in 
progress in IETF. Please find attached an 
initial draft of the BICC CS3 signalling 
requirements for end-to-end QoS service 
control. Please note the rationale for this 
activity and the framework for end-to-end QoS 
service control and network QoS control. The 
framework illustrates the field of 
application of the QoS handling at different 
levels and the different protocols involved.



rightProposals on end-to-end QoS service contro=
l


rightIt is proposed to start a joint activity w=
ith 
IETF on a generic protocol mechanism for end-
to-end QoS service control. This refers to 
the potential work in IETF on the following 
topics:


right- Identification of the signalling 
requirements based on the ETSI TIPHON defined 
speech QoS service classes for VoIP and the 
signalling and control of end-to-end QoS for 
VoIP. The attachment provides the initial 
draft of the BICC CS3 signalling requirements 
for end-to-end QoS service control.


right- The definition of a generic call/bearer 
control mechanism in H.225/H.245, SIP/SDP and 
BICC CS3 for end-to-end QoS service control 
in the application plane.


right- The definition of generic extensions to 
H.248/MEGACO for end-to-end QoS service 
control between the application plane and the 
transport plane.


right- The translation between the generic 
protocol QoS information elements in 
H.248/MEGACO and the technology specific QoS 
parameters and QoS mechanisms in IP, ATM, 
MPLS, etc.



rightProposals on IP QoS classes and IP Transfe=
r 
Capabilities


rightITU-T SG11 would like to inform IETF that =
it 
is investigating signalling requirements for 
protocol development based on the IP Transfer 
Capabilities and IP QoS classes, as being 
defined by ITU-T SG13 in Y.1541 and Y.iptc. 
The plan is to build upon signalling 
approaches developed by IETF. We would like 
to stress that the work on IP QoS classes and 
IP Transfer Capabilities by ITU-T SG13 is co-
ordinated with IETF.


rightATTACHMENT	Initial draft text of the BICC 
CS3 signalling requirements for end-to-end 
QoS service control. 


rightThe ETSI specifications referenced as base=
 
material are available at the following URLs:


outETSI TS 301 329 part 2, 
http://docbox.etsi.org/tech-
org/tiphon/Document/tiphon/07-
drafts/wg5/_Published/DTS05009/V1.1.1/ts_10
1329-2v111p.doc


right- ETSI TS 301 329 part 3 see 
http://docbox.etsi.org/tech-
org/tiphon/Document/tiphon/07-
drafts/wg5/_Published/DTS05003/DTS05003v096.zi
p


rightFurther information about the ETSI TIPHON 
project is available at the following URL:


right- 
http://webapp.etsi.org/tbhomepage/TBDetails.as
p?TB_ID=3D291&TB_NAME=3DTIPHON

right__________________


rightBICC CS3 signalling requirements for end-t=
o-
end QoS service control


rightEDITORS=92 NOTE:	This requirements text fo=
r 
end-to-end QoS service control is a first 
draft text and requires extensive updating 
based on liaison activities with other groups


right1 Rationale


rightThe rationale of the BICC CS3 requirements=
 
for end-to-end service control is based on 
the analysis made by ETSI TIPHON (see the 
presentation available at the URL: 
http://docbox.etsi.org/tech-
org/tiphon/Document/tiphon/ARCHIVES/2000/05-
200012-
Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt
). It shows the inter-relationship between 
the different QoS factors that finally 
determine 

rightthe perceived speech quality by the end-
users. This perceived speech quality does not 
only depend on network quality of service 
(network packet loss, network jitter and 
network delay) but on the terminal 
implementation (jitter buffers and codec 
performance) as well. 

right 

rightA second rationale is that end-to-end QoS 
requirements can be regarded as end-to-end 
quality budgets related to the media flows. 
To achieve the required end-to-end QoS these 
quality budgets must be allocated between the 
domains, including the user equipment (see 
Figure 7 in ETSI TS 301 329 part 3). The 
Transport QoS Parameters specify the QoS 
budgets for each Transport Domain. It is 
assumed that the performance of each domain 
is statistically independent from any other.

right 

rightTherefore end-to-end QoS service control a=
t 
the call control level (i.e. application 
plane) is required based on generic 
signalling procedures in protocols like BICC, 
SIP/SDP, H.323 and H.248/MEGACO for end-to-
end QoS service control.



right2 Framework for end-to-end QoS service 
control and network QoS control.


rightA framework for QoS control may be conside=
red 
at different levels: call control (BICC, 
SIP/SDP, H.323), vertical control 
(H.248/MEGACO, CBC), bearer control (IP BCP) 
and bearer (DiffServ, IntServ/RSVP or 
MPLS/LDP).


right1) Call-control 


righta) End-to-end QoS service control is 
negotiated/communicated end-to-end at the 
call control level. ETSI TIPHON has defined a 
set of speech QoS classes, and signalling 
requirements and flows for this purpose. 


rightThe idea is that call control protocols ar=
e 
enhanced with a generic end-to-end QoS 
service control mechanism to negotiate these 
speech QoS classes and associated parameters 
(Maximum delay, Maximum packet delay 
variation, Maximum packet loss, Peak bit rate 
and Maximum packet size). 


rightSuch a generic end-to-end QoS service cont=
rol 
mechanism should be defined independent of 
the underlying technology (ATM or IP) and 
operate across network domains and including 
terminal characteristics to 
negotiate/communicate the requested listener 
speech quality that will be perceived by the 
end-users (i.e. "mouth-to-ear").


rightb) BICC (Q.190x) is one of the call contro=
l 
protocols that may be enhanced this way. 
Similar enhancements may be applicable to 
other call-control protocols like SIP/SDP and 
H.323.



right2) Vertical control 


righta) QoS service control is also 
negotiated/communicated at the vertical 
control level. The ETSI TIPHON defined 
signalling requirements and flows include the 
vertical interface. The idea is that vertical 
control protocols are enhanced to 
negotiate/communicate the QoS settings 
(Maximum delay, Maximum packet delay 
variation, Maximum packet loss, Peak bit rate 
and Maximum packet size) in the bearer core 
network based on generic H.248/MEGACO 
extensions.


rightThese QoS settings should be defined 
independent of the underlying technology (ATM 
or IP) of the bearer core network.


rightb) CBC (Q.1950) is one of the vertical 
control protocols that may be enhanced this 
way.



right3) Bearer control 


righta) Network QoS is negotiated/communicated =
at 
the bearer control level. ATM signalling does 
already intrinsically support network QoS. 
SG13 has recently defined IP QoS classes and 
IP Transfer Capabilities. 


rightThe idea is that bearer control protocols =
for 
IP are enhanced with a mechanism to negotiate 
the network QoS by using IP QoS classes and 
IP Transfer Capabilities. 


rightb) IP BCP (Q.1970) is an IP bearer control=
 
protocol that may be enhanced this way.



right4) Bearer 


righta) Network QoS is negotiated/communicated =
at 
the bearer level, i.e. as part of the 
protocols associated with the bearers in the 
core network. The idea is that IP QoS classes 
and IP Transfer Capabilties, as defined by 
SG13, are used to differentiate between 
different types of IP traffic.


rightb) IP QoS classes and IP Transfer 
Capabilities may be used to enhance existing 
IP mechanisms like DiffServ, IntServ/RSVP and 
MPLS/LDP.


right 

right3 QoS information flows applicable to BICC=



rightA general model is considered for QoS 
information flows with BICC when making a 
translation of the relevant parts in Figure 8 
in ETSI TS 301 329 part 3.

right 

rightSection 4 details the Q.BICC related QoS 
primitives and parameters based on the QoS 
primitives and parameters in the ETSI 
deliverable. Similarly, section 5 provides 
the Q.CBC related QoS primitives and 
parameters.



right4 Q.BICC related QoS primitives and parame=
ters


rightThe Q.BICC related QoS primitives and 
parameters are extracted from clause 8.1 and 
clause 8.2 of ETSI TS 101 329 part 3.


right4.1 Q.BICC related QoS primitives


rightThis information flow (QC2 in ETSI TS 101 =
329 
part 3) communicates the QoS related bearer 
information between the domains of different 
service providers. 


rightQ.BICC QoS request (Qbicc.QoSreq) requests=
 
the establishment of a bearer conforming to a 
particular ETSI TIPHON Class of Service or 
with defined QoS characteristics.


rightNOTE	Identical to QoSM request (QC2.QoSMre=
q) 
in ETSI TS 101 329 part 3 clause 8.1.1.


rightQ.BICC QoS confirm (Qbicc.QoSconf) 
acknowledges the creation of a bearer 
conforming to a requested ETSI TIPHON QoS 
Class or with specified QoS characteristics.


rightNOTE	Identical to QoSM confirm 
(QC2.QoSMconf) in ETSI TS 101 329 part 3 
clause 8.1.1.


rightQ.BICC QoS reject (Qbicc.QoSrej) rejects t=
he 
creation of a bearer conforming to a 
requested ETSI TIPHON QoS Class or with 
specified QoS characteristics.


rightNOTE	Identical to QoSM reject (QC2.QoSMrej=
) 
in ETSI TS 101 329 part 3 clause 8.1.1.


rightQ.BICC release request (Qbicc.QoSrelreq) 
requests the release of a bearer.


rightNOTE	Identical to QoSM release request 
(QC2.QoSMrelreq) in ETSI TS 101 329 part 3 
clause 8.1.1 and the release of a transport 
flow is already covered by existing Q.BICC 
procedures in Q.1902 series.


rightQoSM release confirm (Qbicc.QoSrelconf) 
confirms the release of a bearer.


rightNOTE	Identical to QoSM release confirm 
(QC2.QoSMrelconf) in ETSI TS 101 329 part 3 
clause 8.1.1 and the release of a transport 
flow is already covered by existing Q.BICC 
procedures in Q.1902 series.



right4.2 Q.BICC related QoS parameters


rightTable 1 lists the parameters used in the 
Q.BICC related QoS primitives not yet covered 
by the Q.BICC protocol. The deleted items 
refer to the information elements already 
covered by the BICC CS2 protocol in the 
Q.1902 series.


rightNOTE	The contents of Table 1 is an 
interpretation of the table in ETSI TS 101 
329 part 3 clause 8.2.3.


rightTable 1: Identification of Q.BICC related 
parameters for end-to-end QoS service control

rightQbicc.QoSreq		QoS Service Class			
Optional


right			Codec Type and Packetisation		
Mandatory


right			Transport QoS Parameters		Mandatory


right			Traffic Descriptor				Optional


right			Transport Addresses			Mandatory


right			Application Data Transport Protocol	
Optional [Default RTP]


right			Packet Transport Protocol			
Optional [Default UDP]


right			QoS Mechanism				Optional


rightQbicc.QoSconf		QoS Service Class			
Optional


right			Codec Type and Packetisation		
Mandatory


right			Transport QoS Parameters		Mandatory


right			Transport Addresses			Mandatory


right			Application Data Transport Protocol	
	Optional [Default RTP]


right			Packet Transport Protocol			
Optional [Default UDP]


rightQbicc.QoSrej		Reason [TBD]				
Mandatory



right5 Q.CBC related QoS primitives and paramet=
ers


rightThe Q.CBC related QoS primitives and 
parameters are extracted from clause 8.1 and 
clause 8.2 of ETSI TS 101 329 part 3.


right5.1 Q.CBC related QoS primitives 


rightThis information flow (QT2 in ETSI TS 101 =
329 
part 3) communicates the QoS related 
transport flow information between a service 
domain and an associated transport domain. 
This information contains the QoS related 
characteristics required of the transport 
flows that will carry the media flow and the 
properties of the media flow.


rightQ.CBC QoS request (Qcbc.QoSreq) requests t=
he 
establishment of a transport flow with 
defined QoS characteristics across a 
Transport Domain or the reservation of 
Transport Domain resource.


rightNOTE	Identical to TRM QoS request 
(QT2.TRMQreq) in ETSI TS 101 329 part 3 
clause 8.1.3.


rightQ.CBC QoS confirm (Qcbc.QoSconf) acknowled=
ges 
the creation of a requested transport flow or 
the reservation of Transport Domain resource.


rightNOTE	Identical to TRM QoS confirm 
(QT2.TRMQconf) in ETSI TS 101 329 part 3 
clause 8.1.3.


rightQ.CBC QoS reject (Qcbc.QoSrej) rejects the=
 
creation of a requested transport flow or the 
reservation of Transport Domain resource.


rightNOTE	Identical to TRM QoS reject 
(QT2.TRMQrej) in ETSI TS 101 329 part 3 
clause 8.1.3.


rightQ.CBC QoS release request (Qcbc.QoSrelreq)=
 
requests the release of a transport flow.


rightNOTE	Identical to TRM QoS release request 
(QT2.TRM QoS relreq) in ETSI TS 101 329 part 
3 clause 8.1.3. The release of a transport 
flow is already covered by the existing Q.CBC 
procedures in Q.1950.


rightQ.CBC QoS release confirm (Qcbc.QoSrelconf=
) 
confirms the release of a transport flow.


rightNOTE	Identical to TRM QoS release confirm 
(QT2.TRM QoS relconf) in ETSI TS 101 329 part 
3 clause 8.1.3. The release of a transport 
flow is already covered by the existing Q.CBC 
procedures in Q.1950.


rightQ.CBC QoS performance notification 
(Qcbc.QoSperfnotif) notifies the Service 
Domain of the performance of the Transport 
Domain in meeting the requested QoS levels.  
This may be a periodic event or an urgent 
alarm.  Note: this primitive is a management 
primitive and its use is for further study.


rightNOTE	Identical to TRM QoS performance 
notification (QT2.TRM QoS perfnotif) in ETSI 
TS 101 329 part 3 clause 8.1.3. For further 
study.



right5.2 Q.CBC related QoS parameters


rightTable 2 lists the parameters used in the 
Q.CBC related QoS primitives not yet covered 
by the Q.CBC protocol. The deleted items 
refer to the information elements already 
covered by the BICC CS2 protocol in Q.1950. 


rightNOTE	The contents of Table 2 is an 
interpretation of the table in ETSI TS 101 
329 part 3 clause 8.2.5.


rightTable 2: Identification of Q.CBC related 
parameters for end-to-end QoS service control


rightQT2.TRMQreq		Transport QoS Parameters		
Mandatory


right			Traffic Descriptor				Mandatory


right			Transport Addresses			Mandatory


right			Packet Transport Protocol			
Optional [Default UDP]


rightQT2.TRMQconf		Transport QoS Parameters		
Mandatory


right			Transport Addresses			Mandatory


right			Packet Transport Protocol			
Optional [Default UDP]


right			QoS Mechanism				Optional


rightQT2.TRMQrej		Reason [TBD]				Mandatory



right6 Parameter contents


rightTable 3 specifies the information to be 
covered by the parameters listed in sections 
4.2 and 5.2 based on the QoS parameter groups 
in ETSI TS 101 329 part 3 clause 8.2.1.


rightTable 3: Identification of parameter conte=
nts 
for end-to-end QoS service control


rightQoS Service Class	Describes the end-to-end=
 
ETSI TIPHON 		Best, High, Medium 

right			class of a bearer				or Best 
Effort


rightTransport QoS 		Specifies the QoS 
characteristics 		Maximum Delay

rightParameters		required of the transport flow=
 

right			carrying the media flow.			
Maximum Packet Delay Variation


right								Maximum Packet Loss


rightTraffic Descriptor		Characterises the 
resource 		Peak Bit 

right			requirements of an application data 

right			flow (excludes transport flow 		
Maximum Packet Size

right			resource requirements).


rightParameters specifying the ETSI TIPHON QoS 
Class as defined in ETSI TS 101 329 Part 2


rightThe maximum delay permitted (ms) over eith=
er 
a segment of the transport flow or the 
remaining part of the transport flow.


rightThe maximum packet delay variation permitt=
ed 
(ms) over either a segment of the transport 
flow or the remaining part of the transport 
flow.


rightThe maximum packet loss permitted (%) over=
 
either a segment of the transport flow or the 
remaining part of the transport flow. [N.B. 
This measure assumes randomly distributed 
packet loss]

rightMaximum bit rate (bit/s) of the media flow=
.


rightMaximum size of the media packets 



right7 Information flows and signalling procedu=
res 
for end-to-end QoS service control


rightEDITORS=92 NOTE	The information flows and 
signalling procedures for end-to-end QoS 
service control may be considered to follow 
the same principles as the already existing 
procedures for end-to-end codec negotiation 
in BICC CS1 and BICC CS2. Similarly mid-call 
procedures for end-to-end QoS modification 
and mid-call QoS modification may be 
considered because the perceived QoS is 
highly related to the codec type employed end-
to-end as part of the connection. The exact 
scope and properties of these procedures and 
protocol message flows needs further 
discussion.



Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protoc=
ols

Lucent Technologies
Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com


From owner-megaco@fore.com  Wed May 30 17:04:21 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24719
	for ; Wed, 30 May 2001 17:04:20 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA06800;
	Wed, 30 May 2001 16:53:47 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA09622
	for megaco-list; Wed, 30 May 2001 16:52:51 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA09608
	for ; Wed, 30 May 2001 16:52:49 -0400 (EDT)
Received: from Mitel.COM ([216.191.234.101])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA06648
	for ; Wed, 30 May 2001 16:52:46 -0400 (EDT)
Received: from rndex50.software.mitel.com (rndex50 [134.199.17.160]) 
	by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id QAA03391;
	Wed, 30 May 2001 16:52:26 -0400 (EDT)
Received: by rndex50.kanata.mitel.com with Internet Mail Service (5.5.2448.0)
	id ; Wed, 30 May 2001 16:52:45 -0400
Message-ID: <9D6A470BD38ED311908000805F65B4EC05554332@rndex50.kanata.mitel.com>
From: "Blatherwick, Peter" 
To: "'Madhu Babu Brahmanapally'" ,
        "Blatherwick, Peter" , megaco@fore.com
Subject: RE: Network Package
Date: Wed, 30 May 2001 16:52:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hmmm....  I still don't agree its unclear, and am hesitant to add description for special cases that actually aren't special at all, just odd MGC behavior.  My opinion.  (Just remove the BREAK and everything's ok.)
-- Peter

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: May 30, 2001 10:46
To: 'Blatherwick, Peter'; megaco@fore.com
Subject: RE: Network Package


HI Peter/All,

Might be an implementation issue but let me put the same query with some
sample code.

The Section 7.1.9 Events Descriptor 4th paragraph,
"When an event is processed against the contents of an active Events
   descriptor and found to be present in that descriptor ("recognized"),
   the default action of the MG is to send a Notify command to the MG."

After interpretation, the statement above was implemented as follows

ProcessDetectedEvent( Event detected is passed)
{
  if ( Events Descriptor is active)
  {
      for ( each event in the events descriptor )
      {
           if ( match Found)
           {
                 GenerateNotifyTowardsMGC ( event, timestamp, RequestId,
etc...)
                 PostEventDetectionProcessing(Event Detected)
                 break;
           }
      }
  }
  else
     ProcessEventAccordingToEventsBufferDescriptor( Event detected is
passed)
}

Its true that the IG mentions about package extension, but no where (I mean
either in IG/protocol) its mentioned that if one event recognition matches
two events in the Events Descriptor...(at First I wondered how this was
possible...) there will be two Notify commands generated towards MGC.

IMHO Unless explicitly mentioned about the multiple Notifies for single
hardware event, the general interpretation of event matching will be some
thing as shown above...which is actually not the intent.

Regards
Madhubabu




-----Original Message-----
From: Blatherwick, Peter [mailto:Peter_Blatherwick@Mitel.COM]
Sent: Tuesday, May 29, 2001 10:05 PM
To: 'Madhu Babu Brahmanapally'; megaco@fore.com
Subject: RE: Network Package


Now I'm not so sure what you're getting at below -- what is different from
previous examples.  I see the rules as completely general.  MG simply checks
for events to report (redundant or not, doesn't care or even necessarily
know), in the order requested, and for each one follows the
buffering/reporting algorithm per current handling settings.  Perhaps a more
explicit example?

Re the IG, I don't think it explicitly mentions "synonyms" (nice term by the
way ;-), but does give clear guidance on what is considered equivalent, how
the MG exposes its interfaces, and how the MGC specifies what it wants.
Event reporting text in the core protocol document and/or IG I personally
believe already are clear on how events are reported.  Since we are not
talking about special cases, simply same handling for all events requested
by MGC, I don't see that specific text is required.  My opinion.

-- Peter

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: May 29, 2001 21:44
To: 'Blatherwick, Peter'; 'Rosen, Brian'; 'Chuong Nguyen';
megaco@fore.com
Subject: RE: Network Package


HI Peter/All,

I agree that the MG does whatever is said by the MGC. But, if say Events
Descriptor is X,Y,Z and say X and Z means the same (Similar to the A/T1 and
B/T1). Now the MG while reporting the event in the Notify also has to check
events beyond match???? Is this fine???

1) Then this has to be true while buffering events in Events Buffer
according to Event Buffer descriptor and
2) While processing of new events descriptor when Event Buffer control is
lockstep.

But I see no such statement in the Protocol Text. If the intention of
matching of event is to match all the "synonyms" of the event. Then this
text needs to be specified in the IG at least to avoid any
misunderstandings.

Regards
Madhubabu


-----Original Message-----
From: Blatherwick, Peter [mailto:Peter_Blatherwick@Mitel.COM]
Sent: Tuesday, May 29, 2001 9:22 PM
To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen';
megaco@fore.com
Subject: RE: Network Package


As in previous e-mail, just sent, I don't believe the below error should
apply to the case of MGC requesting both A/T1 and B/T1.   MG is simply
responding to the request.   May be a better case for using this if the
request is for A/T1 and A/T1, but I still don't think so.  MG simply does as
its told.
-- Peter

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: May 29, 2001 19:19
To: 'Rosen, Brian'; 'Chuong Nguyen'; megaco@fore.com
Subject: RE: Network Package


Brian/All,

Sorry for wrong information in my earlier mail.... Error code "456 -
Parameter or Property appears twice in this Descriptor" is present for
avoiding multiple instances of properties/parameters. If A/T1 and B/T1 mean
the same doesn't this fall into the above error category.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Tuesday, May 29, 2001 5:47 PM
To: 'Chuong Nguyen'; megaco@fore.com
Subject: RE: Network Package


Well rtp/dur and nt/dur are "the same thing" in the sense that the mean the
same
thing, but if you implement (expose) both packages, then they are "separate"
statistics.  Using Events is perhaps easier to understand.  Suppose Package
A
implements event E1, and package B extends Package A, and a given
implementation
exposes both A and B, such that an audit of termination T1 returns
Packages{..A,B..}

You can say Add=T1{Events=123{B/E1}}
or you can say
Add=T1{Events=123{A/T1}}
or even
Add=T1{Events=123{A/T1,B/T1}}

In the latter, detection of the event would result in a notify of both.

Returning to statistics, the value would be the same, but they are separate
statistics.

Brian

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Tuesday, May 29, 2001 5:29 PM
To: megaco@fore.com
Subject: Re: Network Package


"Rosen, Brian" wrote:

If you implement any part of a package, you implement all of it.If a package
extends any part of a package, it extends all of it.

What is not required is that if you implement a package that extendsanother
package that you have to "expose" the underlying package.This means that if
you implement rtp you don't have to expose nt.If you list nt as one of the
packages in an audit, then you have toimplement nt/dur.


  I don't quite follow here.
               You seem to imply that nt/dur and rtp/dur are 2 different
things.
               I thought both nt/dur and rtp/dur are the same thing w/the
same value.
              If MG exposed nt, what should it return for duration - nt/dur
or rtp/dur?


Do you know the intend of tdmc/os and tdmc/or?
I thought the same as Madhubabu about how they are calculated.






Brian

-----Original Message-----
From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com
 ]
Sent: Tuesday, May 29, 2001 5:15 PM
To: 'Chuong Nguyen'
Cc: megaco@fore.com
Subject: RE: Network Package
Hi chuong/all,IMO if PackageB extends PackageA and if one of the
statistic/property of Package A is not valid for termination realizing
packageB then there is no reason why PackageB extends PackageA. Then
PackageB shouldn't extend PackageA (just only to reuse few
properties/statistics) but should define the same properties (Might be with
different IDs) in packageB. I think the extension of packages is logical if
the newly defined package can inherit "all" the properties already defined
in the base package and also define new properties. In your example, I was
in the impression that "OS" and "OR" can be calculated as "The number of
octet sent or received is equal to the duration of the Termination, in
seconds, multiplied by the sampling frequency,  8000 Hz.". (Of course this
seems to be redundant info if the MGC is aware of the sampling frequency).
Isn't this the intention?????-RegardsMadhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
 mailto:owner-megaco@pit.comms.marconi.com
 ]On Behalf Of Chuong Nguyen
Sent: Tuesday, May 29, 2001 4:38 PM
To: megaco@fore.com
Subject: Network Package
Hi All


Is it reasonable to assume that Network Package StatisticsID will never be
used directly?
That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os and rtp/or
respectiviely
since rtp package extends nt package.


I know that it is agreed that if a termination realizes rtp package, it also
realizes nt package
and either nt/.. or rtp/.. are valid packageName.


But if we allow, nt/... instead of rtp/.., are we saying that if MGC
receives nt/.., it has to
know whether it is for rtp or tmcd termination by the terminationID?



Furthermore, since tdmc package extends nt package, do "octet sent" (OS) and
"octet
received" (OR) really apply to tdm termination?


Also what does it mean for a TDM termination to realize the "NT" package
properties
of "Maximum Jitter Buffer"?


So a more general question, if a termination realizes a packageB that
extends
packageA and there are items in the packageA that does not make sense to
the termination what should MG/MGC do.


Take the above as an example and assuming that it does not make sense for
TDM
termination to have "OS" and "OR", what should MG return for TDM termination
statistics if the termination realizes "TDMC" package?
Just "duration".


---
Said it is valid to have "OS" and "OR" for TDM.
IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP
termination,
is it valid for MG to return nt/dur, nt/os and nt/or for the TDM termination
and RTP
termination instead of tdmc/dur, ... vs rtp/dur ?


Thanks
Chuong




--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


From owner-megaco@fore.com  Wed May 30 17:34:36 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25197
	for ; Wed, 30 May 2001 17:34:35 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA09240;
	Wed, 30 May 2001 17:24:05 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA15242
	for megaco-list; Wed, 30 May 2001 17:23:20 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15234
	for ; Wed, 30 May 2001 17:23:15 -0400 (EDT)
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA09109
	for ; Wed, 30 May 2001 17:23:12 -0400 (EDT)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4ULLMD18676;
	Wed, 30 May 2001 17:21:22 -0400 (EDT)
Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id RAA19071; Wed, 30 May 2001 17:20:06 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 30 May 2001 17:21:20 -0400
Message-ID: 
From: "Roy, Radhika R, ALCTA" 
To: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu
Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu,
        megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org,
        tsvwg@ietf.org, Yukio Hiramatsu
	 ,
        rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
        ITU-SG16@mailbag.cps.INTEL.COM
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
	ND-TO-END QOS SERVICE CONTROL
Date: Wed, 30 May 2001 17:21:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hi, Everyone:
 
Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards
for "End-to-End QOS for Multimedia Applications". Contributions are also
being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001
meeting.
 
Applications like H.323, SIP, H.324, H.310, and others will also be able to
use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be
able to use this when specs are fully developed and, TIPHON's QOS mechanisms
can also be used as one of the mechanisms for implementations.
 
BICC and MEGCAO/H.248 are only used as the protocol between the gateways,
NOT end-to-end (although SIP/H.323 or other protocols may be used between
the gateways).
 
The "End-to-End QOS for Multimedia Applications" of SG16 can also be termed
as "Application Layer QOS."
 
Q.F/16's end-to-end application layer QOS can also be implemented over the
network layer QOS like RSVP, DiffServe, and/or MPLS after proper mapping.
Similar is the case for the ATM network.
 
Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS)
may or may not have the end-to-end significance. For example, an IP network
may implement different QOS schemes in different domains (e.g., RVSP in one
domain, DiffServ in another domain). 
 
However, the application layer QOS is end-to-end that remains the same. For
example, an H.323 or SIP call that can traverse several IP domains where
each domain may implement its own network layer QOS schemes while the
H.323/SIP call carry the signaling messages and QOS parameters end-to-end
independent of the underlying network layer QOS mechanisms.
 
Let us work together.
 
Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Greg Ratta [mailto:gratta@lucent.com]
Sent: Wednesday, May 30, 2001 4:22 PM
To: sob@harvard.edu; mankin@isi.edu
Cc: diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu;
megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org;
Yukio Hiramatsu; rbuhrke@lucent.com; tsg11q8@ties.itu.ch;
tsg11q9@ties.itu.ch
Subject: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR
END-TO-END QOS SERVICE CONTROL



This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May
2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of
ITU-T SG 11. For further technical clarification, contact the Rapporteur for
Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK
mailto:rburke@lucent.com }rbuhrke@lucent.com) 


FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR
END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON
IP TRANSFER CAPABILITIES AND IP QOS CLASSES 




General



Within ITU-T SG11 work has started on requirements for a generic protocol
mechanism for end-to-end QoS service control. It was agreed within SG11 to
proceed with this work utilising deliverables of ETSI TIPHON on end- to-end
QoS service control as base material. It is the opinion of SG11 that this
generic protocol mechanism for BICC intends to apply also to other protocols
like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO
protocol.



It was noted that also QoS related work is in progress in IETF. Please find
attached an initial draft of the BICC CS3 signalling requirements for
end-to-end QoS service control. Please note the rationale for this activity
and the framework for end-to-end QoS service control and network QoS
control. The framework illustrates the field of application of the QoS
handling at different levels and the different protocols involved.




Proposals on end-to-end QoS service control



It is proposed to start a joint activity with IETF on a generic protocol
mechanism for end- to-end QoS service control. This refers to the potential
work in IETF on the following topics:



- Identification of the signalling requirements based on the ETSI TIPHON
defined speech QoS service classes for VoIP and the signalling and control
of end-to-end QoS for VoIP. The attachment provides the initial draft of the
BICC CS3 signalling requirements for end-to-end QoS service control.



- The definition of a generic call/bearer control mechanism in H.225/H.245,
SIP/SDP and BICC CS3 for end-to-end QoS service control in the application
plane.



- The definition of generic extensions to H.248/MEGACO for end-to-end QoS
service control between the application plane and the transport plane.



- The translation between the generic protocol QoS information elements in
H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms
in IP, ATM, MPLS, etc.




Proposals on IP QoS classes and IP Transfer Capabilities



ITU-T SG11 would like to inform IETF that it is investigating signalling
requirements for protocol development based on the IP Transfer Capabilities
and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The
plan is to build upon signalling approaches developed by IETF. We would like
to stress that the work on IP QoS classes and IP Transfer Capabilities by
ITU-T SG13 is co- ordinated with IETF.



ATTACHMENT      Initial draft text of the BICC CS3 signalling requirements
for end-to-end QoS service control. 



The ETSI specifications referenced as base material are available at the
following URLs:



ETSI TS 301 329 part 2, http://docbox.etsi.org/tech-
org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10
1329-2v111p.doc



- ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech-
org/tiphon/Document/tiphon/07-
drafts/wg5/_Published/DTS05003/DTS05003v096.zi p



Further information about the ETSI TIPHON project is available at the
following URL:



- http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON


__________________



BICC CS3 signalling requirements for end-to- end QoS service control



EDITORS' NOTE:  This requirements text for end-to-end QoS service control is
a first draft text and requires extensive updating based on liaison
activities with other groups



1 Rationale



The rationale of the BICC CS3 requirements for end-to-end service control is
based on the analysis made by ETSI TIPHON (see the presentation available at
the URL: http://docbox.etsi.org/tech-
org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012-
Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the
inter-relationship between the different QoS factors that finally determine 


the perceived speech quality by the end- users. This perceived speech
quality does not only depend on network quality of service (network packet
loss, network jitter and network delay) but on the terminal implementation
(jitter buffers and codec performance) as well. 





A second rationale is that end-to-end QoS requirements can be regarded as
end-to-end quality budgets related to the media flows. To achieve the
required end-to-end QoS these quality budgets must be allocated between the
domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part
3). The Transport QoS Parameters specify the QoS budgets for each Transport
Domain. It is assumed that the performance of each domain is statistically
independent from any other.





Therefore end-to-end QoS service control at the call control level (i.e.
application plane) is required based on generic signalling procedures in
protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS
service control.




2 Framework for end-to-end QoS service control and network QoS control.



A framework for QoS control may be considered at different levels: call
control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer
control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP).



1) Call-control 



a) End-to-end QoS service control is negotiated/communicated end-to-end at
the call control level. ETSI TIPHON has defined a set of speech QoS classes,
and signalling requirements and flows for this purpose. 



The idea is that call control protocols are enhanced with a generic
end-to-end QoS service control mechanism to negotiate these speech QoS
classes and associated parameters (Maximum delay, Maximum packet delay
variation, Maximum packet loss, Peak bit rate and Maximum packet size). 



Such a generic end-to-end QoS service control mechanism should be defined
independent of the underlying technology (ATM or IP) and operate across
network domains and including terminal characteristics to
negotiate/communicate the requested listener speech quality that will be
perceived by the end-users (i.e. "mouth-to-ear").



b) BICC (Q.190x) is one of the call control protocols that may be enhanced
this way. Similar enhancements may be applicable to other call-control
protocols like SIP/SDP and H.323.




2) Vertical control 



a) QoS service control is also negotiated/communicated at the vertical
control level. The ETSI TIPHON defined signalling requirements and flows
include the vertical interface. The idea is that vertical control protocols
are enhanced to negotiate/communicate the QoS settings (Maximum delay,
Maximum packet delay variation, Maximum packet loss, Peak bit rate and
Maximum packet size) in the bearer core network based on generic
H.248/MEGACO extensions.



These QoS settings should be defined independent of the underlying
technology (ATM or IP) of the bearer core network.



b) CBC (Q.1950) is one of the vertical control protocols that may be
enhanced this way.




3) Bearer control 



a) Network QoS is negotiated/communicated at the bearer control level. ATM
signalling does already intrinsically support network QoS. SG13 has recently
defined IP QoS classes and IP Transfer Capabilities. 



The idea is that bearer control protocols for IP are enhanced with a
mechanism to negotiate the network QoS by using IP QoS classes and IP
Transfer Capabilities. 



b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced
this way.




4) Bearer 



a) Network QoS is negotiated/communicated at the bearer level, i.e. as part
of the protocols associated with the bearers in the core network. The idea
is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are
used to differentiate between different types of IP traffic.



b) IP QoS classes and IP Transfer Capabilities may be used to enhance
existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP.






3 QoS information flows applicable to BICC



A general model is considered for QoS information flows with BICC when
making a translation of the relevant parts in Figure 8 in ETSI TS 301 329
part 3.





Section 4 details the Q.BICC related QoS primitives and parameters based on
the QoS primitives and parameters in the ETSI deliverable. Similarly,
section 5 provides the Q.CBC related QoS primitives and parameters.




4 Q.BICC related QoS primitives and parameters



The Q.BICC related QoS primitives and parameters are extracted from clause
8.1 and clause 8.2 of ETSI TS 101 329 part 3.



4.1 Q.BICC related QoS primitives



This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS
related bearer information between the domains of different service
providers. 



Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer
conforming to a particular ETSI TIPHON Class of Service or with defined QoS
characteristics.



NOTE    Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3
clause 8.1.1.



Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer
conforming to a requested ETSI TIPHON QoS Class or with specified QoS
characteristics.



NOTE    Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3
clause 8.1.1.



Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming
to a requested ETSI TIPHON QoS Class or with specified QoS characteristics.



NOTE    Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3
clause 8.1.1.



Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer.



NOTE    Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101
329 part 3 clause 8.1.1 and the release of a transport flow is already
covered by existing Q.BICC procedures in Q.1902 series.



QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer.



NOTE    Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101
329 part 3 clause 8.1.1 and the release of a transport flow is already
covered by existing Q.BICC procedures in Q.1902 series.




4.2 Q.BICC related QoS parameters



Table 1 lists the parameters used in the Q.BICC related QoS primitives not
yet covered by the Q.BICC protocol. The deleted items refer to the
information elements already covered by the BICC CS2 protocol in the Q.1902
series.



NOTE    The contents of Table 1 is an interpretation of the table in ETSI TS
101 329 part 3 clause 8.2.3.



Table 1: Identification of Q.BICC related parameters for end-to-end QoS
service control


Qbicc.QoSreq      QoS Service Class                 Optional



                  Codec Type and Packetisation          Mandatory



                  Transport QoS Parameters          Mandatory



                  Traffic Descriptor                    Optional



                  Transport Addresses                 Mandatory



                  Application Data Transport Protocol       Optional
[Default RTP]



                  Packet Transport Protocol Optional [Default UDP]



                  QoS Mechanism                   Optional



Qbicc.QoSconf         QoS Service Class             Optional



                  Codec Type and Packetisation          Mandatory



                  Transport QoS Parameters          Mandatory



                  Transport Addresses                 Mandatory



                  Application Data Transport Protocol       Optional
[Default RTP]



                  Packet Transport Protocol Optional [Default UDP]



Qbicc.QoSrej      Reason [TBD]                    Mandatory




5 Q.CBC related QoS primitives and parameters



The Q.CBC related QoS primitives and parameters are extracted from clause
8.1 and clause 8.2 of ETSI TS 101 329 part 3.



5.1 Q.CBC related QoS primitives 



This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS
related transport flow information between a service domain and an
associated transport domain. This information contains the QoS related
characteristics required of the transport flows that will carry the media
flow and the properties of the media flow.



Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport
flow with defined QoS characteristics across a Transport Domain or the
reservation of Transport Domain resource.



NOTE    Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3
clause 8.1.3.



Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested
transport flow or the reservation of Transport Domain resource.



NOTE    Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part
3 clause 8.1.3.



Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport
flow or the reservation of Transport Domain resource.



NOTE    Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3
clause 8.1.3.



Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a
transport flow.



NOTE    Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS
101 329 part 3 clause 8.1.3. The release of a transport flow is already
covered by the existing Q.CBC procedures in Q.1950.



Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a
transport flow.



NOTE    Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI
TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already
covered by the existing Q.CBC procedures in Q.1950.



Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service
Domain of the performance of the Transport Domain in meeting the requested
QoS levels. This may be a periodic event or an urgent alarm. Note: this
primitive is a management primitive and its use is for further study.



NOTE    Identical to TRM QoS performance notification (QT2.TRM QoS
perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study.




5.2 Q.CBC related QoS parameters



Table 2 lists the parameters used in the Q.CBC related QoS primitives not
yet covered by the Q.CBC protocol. The deleted items refer to the
information elements already covered by the BICC CS2 protocol in Q.1950. 



NOTE    The contents of Table 2 is an interpretation of the table in ETSI TS
101 329 part 3 clause 8.2.5.



Table 2: Identification of Q.CBC related parameters for end-to-end QoS
service control



QT2.TRMQreq         Transport QoS Parameters          Mandatory



                  Traffic Descriptor                    Mandatory



                  Transport Addresses                 Mandatory



                  Packet Transport Protocol Optional [Default UDP]



QT2.TRMQconf      Transport QoS Parameters              Mandatory



                  Transport Addresses                 Mandatory



                  Packet Transport Protocol Optional [Default UDP]



                  QoS Mechanism                   Optional



QT2.TRMQrej         Reason [TBD]                    Mandatory




6 Parameter contents



Table 3 specifies the information to be covered by the parameters listed in
sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329
part 3 clause 8.2.1.



Table 3: Identification of parameter contents for end-to-end QoS service
control



QoS Service Class       Describes the end-to-end ETSI TIPHON       Best,
High, Medium 


                  class of a beareror Best Effort



Transport QoS           Specifies the QoS characteristics          Maximum
Delay


Parameters          required of the transport flow 


                  carrying the media flow.                Maximum Packet
Delay Variation



                                        Maximum Packet Loss



Traffic Descriptor          Characterises the resource           Peak Bit 


                  requirements of an application data 


                  flow (excludes transport flow       Maximum Packet Size


                  resource requirements).



Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101
329 Part 2



The maximum delay permitted (ms) over either a segment of the transport flow
or the remaining part of the transport flow.



The maximum packet delay variation permitted (ms) over either a segment of
the transport flow or the remaining part of the transport flow.



The maximum packet loss permitted (%) over either a segment of the transport
flow or the remaining part of the transport flow. [N.B. This measure assumes
randomly distributed packet loss]


Maximum bit rate (bit/s) of the media flow.



Maximum size of the media packets 




7 Information flows and signalling procedures for end-to-end QoS service
control



EDITORS' NOTE   The information flows and signalling procedures for
end-to-end QoS service control may be considered to follow the same
principles as the already existing procedures for end-to-end codec
negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for
end-to-end QoS modification and mid-call QoS modification may be considered
because the perceived QoS is highly related to the codec type employed end-
to-end as part of the connection. The exact scope and properties of these
procedures and protocol message flows needs further discussion.




Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and
protocols 

Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196,
gratta@lucent.com



From owner-megaco@fore.com  Wed May 30 17:47:46 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25454
	for ; Wed, 30 May 2001 17:47:46 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA10374;
	Wed, 30 May 2001 17:34:35 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA17179
	for megaco-list; Wed, 30 May 2001 17:33:55 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA17143
	for ; Wed, 30 May 2001 17:33:51 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA10243
	for ; Wed, 30 May 2001 17:33:47 -0400 (EDT)
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f4ULXfE23873
	for ; Wed, 30 May 2001 17:33:41 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 30 May 2001 17:33:32 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 30 May 2001 17:33:36 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CC07@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'YouLing Sha'" ,
        "'Megaco Mailing List (E-mail)'" 
Subject: H.248v2
Date: Wed, 30 May 2001 17:33:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E950.2E202D10"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E950.2E202D10
Content-Type: text/plain;
	charset="ISO-8859-1"

Glen Freundlich (Rapporteur in charge of H.248) wants people to start
thinking seriously about H.248v2, so he has suggested a target date of early
next year (i.e. the next full SG 16 meeting).

> -----Original Message-----
> From: YouLing Sha [mailto:ysha@cpmail.cyberpathinc.com]
> Sent: Wednesday, May 30, 2001 4:11 PM
> To: 'Madhu Babu Brahmanapally'; 'Paul Long'; 'Megaco Mailing List
> (E-mail)'
> Subject: H.248v2
> 
> 
> By the way, does anyone know when the next version of Megaco 
> is going to be available?
> 
> Regards,
> YouLing Sha
> 
> 
> 
> -----Original Message-----
> From:	Madhu Babu Brahmanapally [SMTP:madhubabu@kenetec.com]
> Sent:	Wednesday, May 30, 2001 3:55 PM
> To:	'Paul Long'; 'Megaco Mailing List (E-mail)'
> Subject:	RE: ABNF Question: digit maps embedded in events
> 
> HI all,
> 
> But this a potential candidate for including in the next 
> version of Megaco.
> If not in IG might be some where else, so that we wont miss these.
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Paul Long
> Sent: Wednesday, May 30, 2001 3:35 PM
> To: Megaco Mailing List (E-mail)
> Subject: RE: ABNF Question: digit maps embedded in events
> 
> 
> Well, if you're just looking for someone to reply... :-)
> 
> I hadn't noticed this difference before, but your recommendation makes
> sense. However, it is too late to change now, so it's a moot point.
> 
> Paul Long
> ipDialog, Inc.
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Steven Weisz
> Sent: Wednesday, May 30, 2001 2:08 PM
> To: Megaco Mailing List (E-mail)
> Subject: ABNF Question: digit maps embedded in events
> 
> 
> Hi List,
> 
> I asked this question a few weeks ago and still have not 
> found an answer.
> Does anyone have an opinion?
> 
> It is a quick question concerning a digit map embedded in a 
> requested event.
> Specifically, if you look at the ABNF the embedded digit map 
> is defined as
> 
> eventDM = DigitMapToken (( EQUAL digitMapName ) / (LBRKT digitMapValue
> RBRKT))
> 
> and a digit map descriptor is defined as:
> 
> digitMapDescriptor = DigitMapToken EQUAL (( LBRKT 
> digitMapValue RBRKT ) /
> 		         ( digitMapName [LBRKT digitMapValue RBRKT] ))
> 
> It obvious that they are very similar, as I believe was 
> intended but there
> is one thing that is bothering me in eventDM. That is it 
> seems to me that
> the EQUAL should be right after DigitMapToken as is the case in
> digitMapDescriptor. So we would instead have:
> 
> eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT digitMapValue
> RBRKT))
> 
> Does this make sense?
> 
> Thanks,
> 
> Steve
> 
> 
> 

------_=_NextPart_001_01C0E950.2E202D10
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






H.248v2




Glen Freundlich (Rapporteur in charge of H.248) wants =
people to start thinking seriously about H.248v2, so he has suggested a =
target date of early next year (i.e. the next full SG 16 =
meeting).



> -----Original Message-----

> From: YouLing Sha [mailto:ysha@cpmail.cyberpat=
hinc.com]

> Sent: Wednesday, May 30, 2001 4:11 PM

> To: 'Madhu Babu Brahmanapally'; 'Paul Long'; =
'Megaco Mailing List

> (E-mail)'

> Subject: H.248v2

> 

> 

> By the way, does anyone know when the next =
version of Megaco 

> is going to be available?

> 

> Regards,

> YouLing Sha

> 

> 

> 

> -----Original Message-----

> From: Madhu Babu Brahmanapally =
[SMTP:madhubabu@kenetec.com]

> Sent: Wednesday, May 30, 2001 3:55 PM

> To:   'Paul Long'; 'Megaco Mailing =
List (E-mail)'

> Subject:      RE: ABNF =
Question: digit maps embedded in events

> 

> HI all,

> 

> But this a potential candidate for including in =
the next 

> version of Megaco.

> If not in IG might be some where else, so that =
we wont miss these.

> 

> Regards

> Madhubabu

> 

> -----Original Message-----

> From: owner-megaco@pit.comms.marconi.com

> [mailto:owner-megaco@p=
it.comms.marconi.com]On Behalf Of Paul Long

> Sent: Wednesday, May 30, 2001 3:35 PM

> To: Megaco Mailing List (E-mail)

> Subject: RE: ABNF Question: digit maps embedded =
in events

> 

> 

> Well, if you're just looking for someone to =
reply... :-)

> 

> I hadn't noticed this difference before, but =
your recommendation makes

> sense. However, it is too late to change now, =
so it's a moot point.

> 

> Paul Long

> ipDialog, Inc.

> 

> -----Original Message-----

> From: owner-megaco@pit.comms.marconi.com

> [mailto:owner-megaco@p=
it.comms.marconi.com]On Behalf Of Steven Weisz

> Sent: Wednesday, May 30, 2001 2:08 PM

> To: Megaco Mailing List (E-mail)

> Subject: ABNF Question: digit maps embedded in =
events

> 

> 

> Hi List,

> 

> I asked this question a few weeks ago and still =
have not 

> found an answer.

> Does anyone have an opinion?

> 

> It is a quick question concerning a digit map =
embedded in a 

> requested event.

> Specifically, if you look at the ABNF the =
embedded digit map 

> is defined as

> 

> eventDM =3D DigitMapToken (( EQUAL digitMapName =
) / (LBRKT digitMapValue

> RBRKT))

> 

> and a digit map descriptor is defined =
as:

> 

> digitMapDescriptor =3D DigitMapToken EQUAL (( =
LBRKT 

> digitMapValue RBRKT ) /

>       =
        =
         ( digitMapName [LBRKT =
digitMapValue RBRKT] ))

> 

> It obvious that they are very similar, as I =
believe was 

> intended but there

> is one thing that is bothering me in eventDM. =
That is it 

> seems to me that

> the EQUAL should be right after DigitMapToken =
as is the case in

> digitMapDescriptor. So we would instead =
have:

> 

> eventDM =3D DigitMapToken EQUAL (( digitMapName =
) / (LBRKT digitMapValue

> RBRKT))

> 

> Does this make sense?

> 

> Thanks,

> 

> Steve

> 

> 

> 





------_=_NextPart_001_01C0E950.2E202D10--


From owner-megaco@fore.com  Wed May 30 18:17:15 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26166
	for ; Wed, 30 May 2001 18:17:15 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA11004;
	Wed, 30 May 2001 17:42:24 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA18588
	for megaco-list; Wed, 30 May 2001 17:41:37 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA18576
	for ; Wed, 30 May 2001 17:41:34 -0400 (EDT)
Received: from Mitel.COM ([216.191.234.101])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA10877
	for ; Wed, 30 May 2001 17:41:32 -0400 (EDT)
Received: from rndex50.software.mitel.com (rndex50 [134.199.17.160]) 
	by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id RAA05359;
	Wed, 30 May 2001 17:14:18 -0400 (EDT)
Received: by rndex50.kanata.mitel.com with Internet Mail Service (5.5.2448.0)
	id ; Wed, 30 May 2001 17:14:37 -0400
Message-ID: <9D6A470BD38ED311908000805F65B4EC05554333@rndex50.kanata.mitel.com>
From: "Blatherwick, Peter" 
To: "'Michael Brown'" , megaco@fore.com
Subject: RE: Network Package
Date: Wed, 30 May 2001 17:14:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Basically, I agree with Mike's statements.  See a bit more below.  This is getting long, so I'll shut up (for now)...
-- Peter

-----Original Message-----
From: Michael Brown [mailto:C.Michael.Brown@nortelnetworks.com]
Sent: May 30, 2001 14:52
To: megaco@fore.com
Subject: RE: Network Package


Comments inline.

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Wednesday, May 30, 2001 10:58 AM
To: megaco@fore.com
Subject: Re: Network Package


  
See comment below: 
  

IS this clearly stated somewhere? 
This could be a nightmare for MGC to receive the same statistics value via 2 different 
parameter.  Talk about the overhead of parsing these text strings.

  

[PB]  I believe this logic was given in the Implementors' Guide.  If it remains unclear, please let us all know what needs to be clarified. 
 

  Are you referring to the following in IGv6  Section 12.1? 

When packages are extended, the properties, events, signals and statistics defined in the base package can be referred to using either the extended package name.  For example, if Package A defines event e1, and Package B extends Package A, then B/e1 is an event for a termination implementing Package B. By definition, the MG MUST also implement the base Package, but it optional to publish the base package as an allowed interface.  If it does publish A, then A would be reported on the Package Descriptor in AuditValue as well as B, and event A/e1 would be available on a termination.  If the MG does not publish A, then only B/e1 would be available.  If published through AuditValue, A/e1 and B/e1 are the same event. 
For the purpose of improved interoperability and backward compatibility, the an MG MAY publish all Packages supported by its Terminations, including base Packages from which extended Packages are derived.  An exception to this is in cases where the base packages are expressly designed to be extended by others, not directly controlled, and may not have any function on their own or be nonsensical on their own, in which case the MG SHOULD NOT publish the base Packages. 


  I don't see anything remotely stating what we are discussing about statistics and 
               event reporting.   Specifically that one can get duplicate statistics. 

[MB] I would disagree as I think the IG statements are definitely related although perhaps not complete. There are two different issues here. First is the case where the MGC is specifically asking for certain statistics. This is covered by the spec along the lines of the earlier statements that the MGC is in control and if it asks for something stupid, well, the MG should do it. 

The second issue is a bit more problematic (the Subtract request resulting in reporting of statistics); however, the behavior of the MG in reporting statistics is based on which packages are "published" by the MG. If the MG implementation publishes both a base package and a package that extends that base package, then the default behavior would be to report both statistics. I don't mean to say that it is a useful thing to do... just that it is what will happen. The point is that IMO publishing both the packages is a poor implementation choice on the part of the MG. So, this gets to your question... do we need to document that this is a poor implementation choice? I'm not really convinced that it is necessary. 

[PB] Agree both cases are actually something that should not happen anyway, at least for any reasonable circumstance I can see.  MG should not publish redundant Packages (only "leaf nodes" in general), but is free to do so if it wants.  One case where MG implementation might do this is to allow MGCs to use more advanced (extended) packages recently defined, while still allowing for less advanced ones (base packages) to be used by MGCs that don't know the extended ones.  In that case MGC would need to explicitly ask for which one it wants (as it normally would).  Other case could be where MGC sets Events=ALL, in which case the MGC should be ready to handle the flood, but I would not see this being done in a system where the flood would could actually be a problem (i.e inside small networks only, or where Package sets are know in advance not to be redundant or otherwise cause excess loads).  

[PB] Yes, there would be double the overhead, but that's not really different overhead from MGC asking for 2 sets of statistics from different sources. 
 

  I am using the case of Subtract Request which does not specify any parameter. 
              Thus MG will reply w/all statistics in which case MGC will receive duplicate 
              statistics.
[MB] Issue #2 above.  


 Can someone answer the question what does it mean for tdmc package to 
extend nt package property of "Maximum Jitter Buffer"? 

[PB] My opinion, not as author of the tdmc Package,  is the property should simply always be 0.  There is no jitter buffer.  I agree this is not a very interesting value, so if the MGC is not interested it should not ask, and if its software is designed to handle the general case of any package extending from nt, it better be able to handle 0 as the answer. 
 

  So in general if a package that extends another package and there is some parameters 
               that might not apply, we do not flag it as an error but assume some default value 
               and treat it as a nop? 

              So does NT package qualify as a "base package" based on the definition of what 
              a "base package" is as quoted above - 


An exception to this is in cases where the base packages are expressly designed to be extended by others, not directly controlled, and may not have any function on their own or be nonsensical on their own, in which case the MG SHOULD NOT publish the base Packages. 

Should something be added to each package to define whether it is a "base package" 
which meant that it can't be used on its own? 


NT package is one example to me since each termination that realizes this package must 
belong to some network type which should have its own network-type package (RTP, 
TDM, ATM, etc).


[MB]  The fact is that the Jitter Buffer property WAS supposed to be moved from the Network to the RTP package. Initially, there was only a network package and it had all of the properties that now reside in RTP package. After discussion about support of other network types, it was agreed that the approach that you describe in the previous paragraph was the right one and the RTP package was created. I don't remember why the Jitter Buffer parameter didn't get moved, but this was pointed out at that time and the intent was that it would be moved to the RTP package before publication of the version 1 spec. Unfortunately, the change didn't get made and was overlooked at the time of determination/Last Call. So, there we have it... The Network package was supposed to be a generic base package, but it isn't exactly. As far as what should be done, unfortunately, based on the existing rules for versioning (which I think we should revisit), we aren't able to simply remove the property f!
!
rom the Network package in a new version. So, I think that the right thing is to include some text in the Network Package to deprecate the use of the Jitter Buffer property there (I don't believe that this would qualify as a new verion of the package) and upversion the RTP package and add the property. (Just by the way, this upversioning of the package would, I think, not necessarily have to wait for Version 2 of the H.248 spec since versioning of a package is not necessarily tied to a particular version of the base protocol.)

[MB] I think that your suggestion that in general we should handle this type of error as a NOP really isn't a good rule of thumb as a "fix". It is OK as a workaround, but the package should ultimately be fixed (or done right to begin with :-) ).



 [PB] Disagree with "NOP".  Meaning of NOP to me is the requesting end (MGC) will see nothing come back, and could get confused as a result.  I prefer to return a value of some kind, even if its non-interesting (like 0 jitter buffer size for example).  Again, if you know its a meaningless value, then don't ask for it in the first place.  

 
 [MB] One other thing was about whether we should add something stating that a package is a base package. I'm not adamantly opposed to the idea, but I really don't think it's necessary.  

[PB] Personally I think its a REAL GOOD IDEA (note alternate IETF key words ;-) for packages intentionally designed to be base packages *only* to say so.   There are several example of this in the existing Annexes, used where the Package is not meant to be exposed, has no function on its own, or is non-sensible on its own.  (This is sorta like virtual classes in OO world.) 

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

  



From owner-megaco@fore.com  Wed May 30 18:54:09 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26927
	for ; Wed, 30 May 2001 18:54:08 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA13711;
	Wed, 30 May 2001 18:34:24 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA26623
	for megaco-list; Wed, 30 May 2001 18:31:52 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA26619
	for ; Wed, 30 May 2001 18:31:50 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA13550
	for ; Wed, 30 May 2001 18:31:47 -0400 (EDT)
Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4UMUBU11655;
	Wed, 30 May 2001 15:30:11 -0700 (PDT)
Message-Id: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com>
X-Sender: fred@mira-sjcm-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 30 May 2001 15:30:00 -0700
To: gratta@lucent.com
From: Fred Baker 
Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM
  FOR END-TO-END QOS SERVICE CONTROL
Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org,
        iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com,
        sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org,
        Yukio Hiramatsu , rbuhrke@lucent.com,
        tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
        John C Klensin , chair@ietf.org
In-Reply-To: <200105302022.QAA03855@hotair.hobl.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Greg:

The URLs in this note were all sent with what the ETSI machine considered 
to be 'malformed syntax'. Could you resend the correct URLs?

Fred



From owner-megaco@fore.com  Wed May 30 19:25:27 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27305
	for ; Wed, 30 May 2001 19:25:26 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA09713;
	Wed, 30 May 2001 17:28:02 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA15843
	for megaco-list; Wed, 30 May 2001 17:27:25 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15828
	for ; Wed, 30 May 2001 17:27:24 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA09604
	for ; Wed, 30 May 2001 17:27:21 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f4ULREE23540
	for ; Wed, 30 May 2001 17:27:14 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Wed, 30 May 2001 17:27:13 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 30 May 2001 17:27:16 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CC06@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Rosen, Brian'" ,
        "'Steven Weisz'" ,
        "Megaco Mailing List (E-mail)" 
Subject: RE: ABNF Question: digit maps embedded in events
Date: Wed, 30 May 2001 17:27:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E94F.4B37CC10"
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

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_01C0E94F.4B37CC10
Content-Type: text/plain;
	charset="ISO-8859-1"

Yes, and I suspect I'm the guilty typist.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Wednesday, May 30, 2001 3:44 PM
> To: 'Steven Weisz'; Megaco Mailing List (E-mail)
> Cc: Taylor, Tom-PT [NORSE:B881:EXCH]
> Subject: RE: ABNF Question: digit maps embedded in events
> 
> 
> I usually defer to Tom on any digitMap questions. 
> I can't tell you how many hours I (and several others
> including Abdullah Rayhan) spent pouring over the
> ABNF to ferret out such problems.
> 
> Yes, I agree, it should be 
> digitMap={...
> and not
> digitMap{...
> 
> I think this qualifies as a typo and deserves an IG entry.
> Tom, do you agree?
> 
> Brian
> 
> > -----Original Message-----
> > From: Steven Weisz [mailto:sweisz@mediatrix.com]
> > Sent: Wednesday, May 30, 2001 3:08 PM
> > To: Megaco Mailing List (E-mail)
> > Subject: ABNF Question: digit maps embedded in events
> > 
> > 
> > Hi List,
> > 
> > I asked this question a few weeks ago and still have not 
> > found an answer.
> > Does anyone have an opinion?
> > 
> > It is a quick question concerning a digit map embedded in a 
> > requested event.
> > Specifically, if you look at the ABNF the embedded digit map 
> > is defined as
> > 
> > eventDM = DigitMapToken (( EQUAL digitMapName ) / (LBRKT 
> digitMapValue
> > RBRKT))
> > 
> > and a digit map descriptor is defined as:
> > 
> > digitMapDescriptor = DigitMapToken EQUAL (( LBRKT 
> > digitMapValue RBRKT ) / 
> > 		         ( digitMapName [LBRKT digitMapValue RBRKT] ))
> > 
> > It obvious that they are very similar, as I believe was 
> > intended but there
> > is one thing that is bothering me in eventDM. That is it 
> > seems to me that
> > the EQUAL should be right after DigitMapToken as is the case in
> > digitMapDescriptor. So we would instead have:
> > 
> > eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT 
> digitMapValue
> > RBRKT))
> > 
> > Does this make sense?
> > 
> > Thanks,
> > 
> > Steve
> > 
> 

------_=_NextPart_001_01C0E94F.4B37CC10
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: ABNF Question: digit maps embedded in events




Yes, and I suspect I'm the guilty typist.




> -----Original Message-----

> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]

> Sent: Wednesday, May 30, 2001 3:44 PM

> To: 'Steven Weisz'; Megaco Mailing List =
(E-mail)

> Cc: Taylor, Tom-PT [NORSE:B881:EXCH]

> Subject: RE: ABNF Question: digit maps embedded =
in events

> 

> 

> I usually defer to Tom on any digitMap =
questions. 

> I can't tell you how many hours I (and several =
others

> including Abdullah Rayhan) spent pouring over =
the

> ABNF to ferret out such problems.

> 

> Yes, I agree, it should be 

> digitMap=3D{...

> and not

> digitMap{...

> 

> I think this qualifies as a typo and deserves =
an IG entry.

> Tom, do you agree?

> 

> Brian

> 

> > -----Original Message-----

> > From: Steven Weisz [mailto:sweisz@mediatrix.com]

> > Sent: Wednesday, May 30, 2001 3:08 =
PM

> > To: Megaco Mailing List (E-mail)

> > Subject: ABNF Question: digit maps =
embedded in events

> > 

> > 

> > Hi List,

> > 

> > I asked this question a few weeks ago and =
still have not 

> > found an answer.

> > Does anyone have an opinion?

> > 

> > It is a quick question concerning a digit =
map embedded in a 

> > requested event.

> > Specifically, if you look at the ABNF the =
embedded digit map 

> > is defined as

> > 

> > eventDM =3D DigitMapToken (( EQUAL =
digitMapName ) / (LBRKT 

> digitMapValue

> > RBRKT))

> > 

> > and a digit map descriptor is defined =
as:

> > 

> > digitMapDescriptor =3D DigitMapToken EQUAL =
(( LBRKT 

> > digitMapValue RBRKT ) / 

> >     =
        =
         ( digitMapName [LBRKT =
digitMapValue RBRKT] ))

> > 

> > It obvious that they are very similar, as =
I believe was 

> > intended but there

> > is one thing that is bothering me in =
eventDM. That is it 

> > seems to me that

> > the EQUAL should be right after =
DigitMapToken as is the case in

> > digitMapDescriptor. So we would instead =
have:

> > 

> > eventDM =3D DigitMapToken EQUAL (( =
digitMapName ) / (LBRKT 

> digitMapValue

> > RBRKT))

> > 

> > Does this make sense?

> > 

> > Thanks,

> > 

> > Steve

> > 

> 





------_=_NextPart_001_01C0E94F.4B37CC10--


From owner-megaco@fore.com  Wed May 30 19:58:34 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27686
	for ; Wed, 30 May 2001 19:58:34 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA17568;
	Wed, 30 May 2001 19:47:34 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id TAA05843
	for megaco-list; Wed, 30 May 2001 19:39:50 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA05805
	for ; Wed, 30 May 2001 19:39:42 -0400 (EDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA17253
	for ; Wed, 30 May 2001 19:39:36 -0400 (EDT)
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4UNdHZ03453;
	Wed, 30 May 2001 16:39:17 -0700 (PDT)
From: Bob Braden 
Received: (from braden@localhost)
	by gra.isi.edu (8.8.7/8.8.6) id XAA13198;
	Wed, 30 May 2001 23:39:17 GMT
Date: Wed, 30 May 2001 23:39:17 GMT
Message-Id: <200105302339.XAA13198@gra.isi.edu>
To: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, rrroy@att.com
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
	ND-TO-END QOS SERVICE CONTROL
Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu,
        megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org,
        tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com,
        tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
        ITU-SG16@mailbag.cps.INTEL.COM
X-Sun-Charset: US-ASCII
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


  *> From owner-issll@mercury.lcs.mit.edu  Wed May 30 14:59:58 2001
  *> From: "Roy, Radhika R, ALCTA" 
  *> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU
  *> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu,
  *>    megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org,
  *>    Yukio Hiramatsu
  *> 	 , rbuhrke@lucent.com,
  *>    tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM
  *> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
  *> 	ND-TO-END QOS SERVICE CONTROL
  *> Date: Wed, 30 May 2001 17:21:14 -0400
  *> MIME-Version: 1.0
  *> 
  *> Hi, Everyone:
  *>  
  *> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards
  *> for "End-to-End QOS for Multimedia Applications". Contributions are also
  *> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001
  *> meeting.

This is very confusing.   "End-to-End QOS for Multimedia Applications"
is an really important topic, but this topic must be a superset of
"End-to-End QOS signaling".  There are much harder problems than
signaling in providing E2E QoS.  Can you explain how signaling relates
to the title of this working party?

Thanks,

Bob Braden

  *>  
  *> Applications like H.323, SIP, H.324, H.310, and others will also be able to
  *> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be
  *> able to use this when specs are fully developed and, TIPHON's QOS mechanisms
  *> can also be used as one of the mechanisms for implementations.


From owner-megaco@fore.com  Thu May 31 02:20:49 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA14804
	for ; Thu, 31 May 2001 02:20:48 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA27393;
	Thu, 31 May 2001 02:12:48 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA17612
	for megaco-list; Thu, 31 May 2001 02:08:52 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA17608
	for ; Thu, 31 May 2001 02:08:50 -0400 (EDT)
Received: from smtp.huawei.com ([202.96.135.132])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA27256
	for ; Thu, 31 May 2001 02:08:46 -0400 (EDT)
Received: from s24087b ([10.105.28.1]) by smtp.huawei.com
          (Netscape Messaging Server 4.15) with SMTP id GE6RHT00.Q1J for
          ; Thu, 31 May 2001 14:03:29 +0800 
Message-ID: <008201c0e998$04df0780$011c690a@huawei.com.cn>
From: "Qiu Xiuping" 
To: 
Subject: Test - Please ignore it
Date: Thu, 31 May 2001 14:07:48 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mailman.pit.comms.marconi.com id CAA17609
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 8bit




From owner-megaco@fore.com  Thu May 31 02:36:33 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15994
	for ; Thu, 31 May 2001 02:36:33 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA27974;
	Thu, 31 May 2001 02:30:18 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA18715
	for megaco-list; Thu, 31 May 2001 02:27:57 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA18650;
	Thu, 31 May 2001 02:27:18 -0400 (EDT)
Received: from goldtelevision.nu ([212.41.206.148])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA27764;
	Thu, 31 May 2001 02:26:43 -0400 (EDT)
Received: from goldtelevision.nu (slip129-37-78-166.ny.us.prserv.net [129.37.78.166])
	by goldtelevision.nu (8.11.2/8.8.7) with SMTP id f4V6PaF04852;
	Thu, 31 May 2001 08:25:37 +0200
From: hnn@Goldtelevision
Message-Id: <200105310625.f4V6PaF04852@goldtelevision.nu>
Received: from ssw@mart.co.uk by alex@smarts.ca (8.8.5/8.6.5) with SMTP id GAA09420 for ; Thu, 31 May 2001 00:17:42 -0600 (EST)
To: alex@smarts.ca
Date: Thu, 31 May 01 00:17:42 EST
Subject: hi
Reply-To: ssw@mart.co.uk
Comments: Authenticated sender is 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Do you have back, muscle or joint problems?  

If so we would like to offer you the opportunity to discuss them with a health care professional at no charge.  

What do you have to lose besides your pain and discomfort?

http://www.westhousehosting.net/backache

To be removed please go to:

http://www.westhousehosting.net/backache/remove.html

HITTING REPLY WILL NOT GET YOU REMOVED NOR GET YOU MORE INFORMATION.  THIS IS AN OUTGOING EMAIL
ONLY.  REPLIES ARE NOT READ.

NOTE:  THIS IS FOR RESIDENTS OF THE U.S. ONLY


 



From owner-megaco@fore.com  Thu May 31 08:16:31 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21636
	for ; Thu, 31 May 2001 08:16:31 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA08992;
	Thu, 31 May 2001 08:10:07 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA17995
	for megaco-list; Thu, 31 May 2001 08:08:10 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA17978
	for ; Thu, 31 May 2001 08:08:08 -0400 (EDT)
From: knayar@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA08829
	for ; Thu, 31 May 2001 08:08:04 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4VC9LW17294
	for ; Thu, 31 May 2001 17:39:22 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A5D.00414501 ; Thu, 31 May 2001 17:22:55 +0530
X-Lotus-FromDomain: HSS
To: megaco@fore.com
Message-ID: <65256A5D.004141F2.00@sandesh.hss.hns.com>
Date: Thu, 31 May 2001 17:24:31 +0530
Subject: RE: Network Package
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk



Hi

Apart from the IG not mentioning about the "double notify", we have another
issue....
In case both the events in the ED have an embedded event descriptor(EED), which
EED should be activated.
Is it decided based upon the sequence of events in the ED ??
...if it is so we donot guarantee "double notify"...in case of EEDs...is it
right.

Would it not be appropriate to restrict the definition of A/E1 and B/E1 (in case
B extends a package A with event E1), to mean the same event...

How about restricting MG as well as MGC to expose only "leaf" packages (extended
packages) but to be lenient enough to accept both base as well as extended
package definitions....this would take care of any interoperability and
compatibilty issues too.
Hence, MGC would send only A/E1 in ED but can accept A/E1 and B/E1 in observed
ED.
and MG shall send only A/E1 in observed ED (or A in Audit response) and accept
B/E1 in ED etc.
Any comments..

-Kapil Nayar
Hughes Software Systems



HI Peter/All,

Might be an implementation issue but let me put the same query with some
sample code.

The Section 7.1.9 Events Descriptor 4th paragraph,
"When an event is processed against the contents of an active Events
   descriptor and found to be present in that descriptor ("recognized"),
   the default action of the MG is to send a Notify command to the MG."

After interpretation, the statement above was implemented as follows

ProcessDetectedEvent( Event detected is passed)
{
  if ( Events Descriptor is active)
  {
      for ( each event in the events descriptor )
      {
           if ( match Found)
           {
                 GenerateNotifyTowardsMGC ( event, timestamp, RequestId,
etc...)
                 PostEventDetectionProcessing(Event Detected)
                 break;
           }
      }
  }
  else
     ProcessEventAccordingToEventsBufferDescriptor( Event detected is
passed)
}

Its true that the IG mentions about package extension, but no where (I mean
either in IG/protocol) its mentioned that if one event recognition matches
two events in the Events Descriptor...(at First I wondered how this was
possible...) there will be two Notify commands generated towards MGC.

IMHO Unless explicitly mentioned about the multiple Notifies for single
hardware event, the general interpretation of event matching will be some
thing as shown above...which is actually not the intent.

Regards
Madhubabu




-----Original Message-----
From: Blatherwick, Peter [mailto:Peter_Blatherwick@Mitel.COM]
Sent: Tuesday, May 29, 2001 10:05 PM
To: 'Madhu Babu Brahmanapally'; megaco@fore.com
Subject: RE: Network Package


Now I'm not so sure what you're getting at below -- what is different from
previous examples.  I see the rules as completely general.  MG simply checks
for events to report (redundant or not, doesn't care or even necessarily
know), in the order requested, and for each one follows the
buffering/reporting algorithm per current handling settings.  Perhaps a more
explicit example?

Re the IG, I don't think it explicitly mentions "synonyms" (nice term by the
way ;-), but does give clear guidance on what is considered equivalent, how
the MG exposes its interfaces, and how the MGC specifies what it wants.
Event reporting text in the core protocol document and/or IG I personally
believe already are clear on how events are reported.  Since we are not
talking about special cases, simply same handling for all events requested
by MGC, I don't see that specific text is required.  My opinion.

-- Peter

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: May 29, 2001 21:44
To: 'Blatherwick, Peter'; 'Rosen, Brian'; 'Chuong Nguyen';
megaco@fore.com
Subject: RE: Network Package


HI Peter/All,

I agree that the MG does whatever is said by the MGC. But, if say Events
Descriptor is X,Y,Z and say X and Z means the same (Similar to the A/T1 and
B/T1). Now the MG while reporting the event in the Notify also has to check
events beyond match???? Is this fine???

1) Then this has to be true while buffering events in Events Buffer
according to Event Buffer descriptor and
2) While processing of new events descriptor when Event Buffer control is
lockstep.

But I see no such statement in the Protocol Text. If the intention of
matching of event is to match all the "synonyms" of the event. Then this
text needs to be specified in the IG at least to avoid any
misunderstandings.

Regards
Madhubabu


-----Original Message-----
From: Blatherwick, Peter [mailto:Peter_Blatherwick@Mitel.COM]
Sent: Tuesday, May 29, 2001 9:22 PM
To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen';
megaco@fore.com
Subject: RE: Network Package


As in previous e-mail, just sent, I don't believe the below error should
apply to the case of MGC requesting both A/T1 and B/T1.   MG is simply
responding to the request.   May be a better case for using this if the
request is for A/T1 and A/T1, but I still don't think so.  MG simply does as
its told.
-- Peter

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: May 29, 2001 19:19
To: 'Rosen, Brian'; 'Chuong Nguyen'; megaco@fore.com
Subject: RE: Network Package


Brian/All,

Sorry for wrong information in my earlier mail.... Error code "456 -
Parameter or Property appears twice in this Descriptor" is present for
avoiding multiple instances of properties/parameters. If A/T1 and B/T1 mean
the same doesn't this fall into the above error category.

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Tuesday, May 29, 2001 5:47 PM
To: 'Chuong Nguyen'; megaco@fore.com
Subject: RE: Network Package


Well rtp/dur and nt/dur are "the same thing" in the sense that the mean the
same
thing, but if you implement (expose) both packages, then they are "separate"
statistics.  Using Events is perhaps easier to understand.  Suppose Package
A
implements event E1, and package B extends Package A, and a given
implementation
exposes both A and B, such that an audit of termination T1 returns
Packages{..A,B..}

You can say Add=T1{Events=123{B/E1}}
or you can say
Add=T1{Events=123{A/T1}}
or even
Add=T1{Events=123{A/T1,B/T1}}

In the latter, detection of the event would result in a notify of both.

Returning to statistics, the value would be the same, but they are separate
statistics.

Brian

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Tuesday, May 29, 2001 5:29 PM
To: megaco@fore.com
Subject: Re: Network Package


"Rosen, Brian" wrote:

If you implement any part of a package, you implement all of it.If a package
extends any part of a package, it extends all of it.

What is not required is that if you implement a package that extendsanother
package that you have to "expose" the underlying package.This means that if
you implement rtp you don't have to expose nt.If you list nt as one of the
packages in an audit, then you have toimplement nt/dur.


  I don't quite follow here.
               You seem to imply that nt/dur and rtp/dur are 2 different
things.
               I thought both nt/dur and rtp/dur are the same thing w/the
same value.
              If MG exposed nt, what should it return for duration - nt/dur
or rtp/dur?


Do you know the intend of tdmc/os and tdmc/or?
I thought the same as Madhubabu about how they are calculated.






Brian

-----Original Message-----
From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com
 ]
Sent: Tuesday, May 29, 2001 5:15 PM
To: 'Chuong Nguyen'
Cc: megaco@fore.com
Subject: RE: Network Package
Hi chuong/all,IMO if PackageB extends PackageA and if one of the
statistic/property of Package A is not valid for termination realizing
packageB then there is no reason why PackageB extends PackageA. Then
PackageB shouldn't extend PackageA (just only to reuse few
properties/statistics) but should define the same properties (Might be with
different IDs) in packageB. I think the extension of packages is logical if
the newly defined package can inherit "all" the properties already defined
in the base package and also define new properties. In your example, I was
in the impression that "OS" and "OR" can be calculated as "The number of
octet sent or received is equal to the duration of the Termination, in
seconds, multiplied by the sampling frequency,  8000 Hz.". (Of course this
seems to be redundant info if the MGC is aware of the sampling frequency).
Isn't this the intention?????-RegardsMadhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
 mailto:owner-megaco@pit.comms.marconi.com
 ]On Behalf Of Chuong Nguyen
Sent: Tuesday, May 29, 2001 4:38 PM
To: megaco@fore.com
Subject: Network Package
Hi All


Is it reasonable to assume that Network Package StatisticsID will never be
used directly?
That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os and rtp/or
respectiviely
since rtp package extends nt package.


I know that it is agreed that if a termination realizes rtp package, it also
realizes nt package
and either nt/.. or rtp/.. are valid packageName.


But if we allow, nt/... instead of rtp/.., are we saying that if MGC
receives nt/.., it has to
know whether it is for rtp or tmcd termination by the terminationID?



Furthermore, since tdmc package extends nt package, do "octet sent" (OS) and
"octet
received" (OR) really apply to tdm termination?


Also what does it mean for a TDM termination to realize the "NT" package
properties
of "Maximum Jitter Buffer"?


So a more general question, if a termination realizes a packageB that
extends
packageA and there are items in the packageA that does not make sense to
the termination what should MG/MGC do.


Take the above as an example and assuming that it does not make sense for
TDM
termination to have "OS" and "OR", what should MG return for TDM termination
statistics if the termination realizes "TDMC" package?
Just "duration".


---
Said it is valid to have "OS" and "OR" for TDM.
IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP
termination,
is it valid for MG to return nt/dur, nt/os and nt/or for the TDM termination
and RTP
termination instead of tdmc/dur, ... vs rtp/dur ?


Thanks
Chuong




--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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


--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

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

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






From owner-megaco@fore.com  Thu May 31 08:41:07 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22424
	for ; Thu, 31 May 2001 08:41:07 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA10138;
	Thu, 31 May 2001 08:30:35 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA21065
	for megaco-list; Thu, 31 May 2001 08:28:45 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA21059
	for ; Thu, 31 May 2001 08:28:44 -0400 (EDT)
From: knayar@hss.hns.com
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA09941
	for ; Thu, 31 May 2001 08:28:39 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f4VCMZN18033;
	Thu, 31 May 2001 17:52:36 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A5D.00427D58 ; Thu, 31 May 2001 17:36:14 +0530
X-Lotus-FromDomain: HSS
To: "Blatherwick, Peter" 
cc: "'Michael Brown'" , megaco@fore.com
Message-ID: <65256A5D.004270DE.00@sandesh.hss.hns.com>
Date: Thu, 31 May 2001 17:39:20 +0530
Subject: RE: Network Package
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk



Hi Peter

A bit late in my response....
But, I agree with your suggestion of maxJitterBuf value to be 0 for TDMC
package.
If we look at the protocol document
"12.1.1   Package
*  Extends (Optional): A package may extend an existing package. The
      version of the original package must be specified. When a package
      extends another package it shall only add additional Properties,
      Events, Signals, Statistics and new possible values for an
      existing parameter described in the original package."

Can we define "new possible value" for maxJitterBuffer in TDMC package as 0.
We definitely, need to change the protocol document...but we can save on
addition/ deletion of properties...as discussed earlier.

Thanks,

-Kapil Nayar
Hughes Software Systems






"Blatherwick, Peter"  on 05/31/2001 02:44:28 AM

To:   "'Michael Brown'" , megaco@fore.com
cc:    (bcc: Kapil Nayar/HSS)

Subject:  RE: Network Package




Basically, I agree with Mike's statements.  See a bit more below.  This is
getting long, so I'll shut up (for now)...
-- Peter

-----Original Message-----
From: Michael Brown [mailto:C.Michael.Brown@nortelnetworks.com]
Sent: May 30, 2001 14:52
To: megaco@fore.com
Subject: RE: Network Package


Comments inline.

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Wednesday, May 30, 2001 10:58 AM
To: megaco@fore.com
Subject: Re: Network Package



See comment below:


IS this clearly stated somewhere?
This could be a nightmare for MGC to receive the same statistics value via 2
different
parameter.  Talk about the overhead of parsing these text strings.



[PB]  I believe this logic was given in the Implementors' Guide.  If it remains
unclear, please let us all know what needs to be clarified.


  Are you referring to the following in IGv6  Section 12.1?

When packages are extended, the properties, events, signals and statistics
defined in the base package can be referred to using either the extended package
name.  For example, if Package A defines event e1, and Package B extends Package
A, then B/e1 is an event for a termination implementing Package B. By
definition, the MG MUST also implement the base Package, but it optional to
publish the base package as an allowed interface.  If it does publish A, then A
would be reported on the Package Descriptor in AuditValue as well as B, and
event A/e1 would be available on a termination.  If the MG does not publish A,
then only B/e1 would be available.  If published through AuditValue, A/e1 and
B/e1 are the same event.
For the purpose of improved interoperability and backward compatibility, the an
MG MAY publish all Packages supported by its Terminations, including base
Packages from which extended Packages are derived.  An exception to this is in
cases where the base packages are expressly designed to be extended by others,
not directly controlled, and may not have any function on their own or be
nonsensical on their own, in which case the MG SHOULD NOT publish the base
Packages.


  I don't see anything remotely stating what we are discussing about
statistics and
               event reporting.   Specifically that one can get duplicate
statistics.

[MB] I would disagree as I think the IG statements are definitely related
although perhaps not complete. There are two different issues here. First is the
case where the MGC is specifically asking for certain statistics. This is
covered by the spec along the lines of the earlier statements that the MGC is in
control and if it asks for something stupid, well, the MG should do it.

The second issue is a bit more problematic (the Subtract request resulting in
reporting of statistics); however, the behavior of the MG in reporting
statistics is based on which packages are "published" by the MG. If the MG
implementation publishes both a base package and a package that extends that
base package, then the default behavior would be to report both statistics. I
don't mean to say that it is a useful thing to do... just that it is what will
happen. The point is that IMO publishing both the packages is a poor
implementation choice on the part of the MG. So, this gets to your question...
do we need to document that this is a poor implementation choice? I'm not really
convinced that it is necessary.

[PB] Agree both cases are actually something that should not happen anyway, at
least for any reasonable circumstance I can see.  MG should not publish
redundant Packages (only "leaf nodes" in general), but is free to do so if it
wants.  One case where MG implementation might do this is to allow MGCs to use
more advanced (extended) packages recently defined, while still allowing for
less advanced ones (base packages) to be used by MGCs that don't know the
extended ones.  In that case MGC would need to explicitly ask for which one it
wants (as it normally would).  Other case could be where MGC sets Events=ALL, in
which case the MGC should be ready to handle the flood, but I would not see this
being done in a system where the flood would could actually be a problem (i.e
inside small networks only, or where Package sets are know in advance not to be
redundant or otherwise cause excess loads).

[PB] Yes, there would be double the overhead, but that's not really different
overhead from MGC asking for 2 sets of statistics from different sources.


  I am using the case of Subtract Request which does not specify any
parameter.
              Thus MG will reply w/all statistics in which case MGC will receive
duplicate
              statistics.
[MB] Issue #2 above.


 Can someone answer the question what does it mean for tdmc package to
extend nt package property of "Maximum Jitter Buffer"?

[PB] My opinion, not as author of the tdmc Package,  is the property should
simply always be 0.  There is no jitter buffer.  I agree this is not a very
interesting value, so if the MGC is not interested it should not ask, and if its
software is designed to handle the general case of any package extending from
nt, it better be able to handle 0 as the answer.


  So in general if a package that extends another package and there is some
parameters
               that might not apply, we do not flag it as an error but assume
some default value
               and treat it as a nop?

              So does NT package qualify as a "base package" based on the
definition of what
              a "base package" is as quoted above -


An exception to this is in cases where the base packages are expressly designed
to be extended by others, not directly controlled, and may not have any function
on their own or be nonsensical on their own, in which case the MG SHOULD NOT
publish the base Packages.

Should something be added to each package to define whether it is a "base
package"
which meant that it can't be used on its own?


NT package is one example to me since each termination that realizes this
package must
belong to some network type which should have its own network-type package (RTP,
TDM, ATM, etc).


[MB]  The fact is that the Jitter Buffer property WAS supposed to be moved from
the Network to the RTP package. Initially, there was only a network package and
it had all of the properties that now reside in RTP package. After discussion
about support of other network types, it was agreed that the approach that you
describe in the previous paragraph was the right one and the RTP package was
created. I don't remember why the Jitter Buffer parameter didn't get moved, but
this was pointed out at that time and the intent was that it would be moved to
the RTP package before publication of the version 1 spec. Unfortunately, the
change didn't get made and was overlooked at the time of determination/Last
Call. So, there we have it... The Network package was supposed to be a generic
base package, but it isn't exactly. As far as what should be done,
unfortunately, based on the existing rules for versioning (which I think we
should revisit), we aren't able to simply remove the property!
 f!
!
rom the Network package in a new version. So, I think that the right thing is to
include some text in the Network Package to deprecate the use of the Jitter
Buffer property there (I don't believe that this would qualify as a new verion
of the package) and upversion the RTP package and add the property. (Just by the
way, this upversioning of the package would, I think, not necessarily have to
wait for Version 2 of the H.248 spec since versioning of a package is not
necessarily tied to a particular version of the base protocol.)

[MB] I think that your suggestion that in general we should handle this type of
error as a NOP really isn't a good rule of thumb as a "fix". It is OK as a
workaround, but the package should ultimately be fixed (or done right to begin
with :-) ).



 [PB] Disagree with "NOP".  Meaning of NOP to me is the requesting end (MGC)
will see nothing come back, and could get confused as a result.  I prefer to
return a value of some kind, even if its non-interesting (like 0 jitter buffer
size for example).  Again, if you know its a meaningless value, then don't ask
for it in the first place.


 [MB] One other thing was about whether we should add something stating that a
package is a base package. I'm not adamantly opposed to the idea, but I really
don't think it's necessary.

[PB] Personally I think its a REAL GOOD IDEA (note alternate IETF key words ;-)
for packages intentionally designed to be base packages *only* to say so.
There are several example of this in the existing Annexes, used where the
Package is not meant to be exposed, has no function on its own, or is
non-sensible on its own.  (This is sorta like virtual classes in OO world.)

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****









From owner-megaco@fore.com  Thu May 31 09:20:12 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23849
	for ; Thu, 31 May 2001 09:20:07 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA13620;
	Thu, 31 May 2001 09:12:17 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA01715
	for megaco-list; Thu, 31 May 2001 09:10:58 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA01704
	for ; Thu, 31 May 2001 09:10:56 -0400 (EDT)
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA13424
	for ; Thu, 31 May 2001 09:10:53 -0400 (EDT)
Received: from gab200r1.ems.att.com ([135.37.94.32])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VD8wC16127;
	Thu, 31 May 2001 09:08:58 -0400 (EDT)
Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id JAA04890; Thu, 31 May 2001 09:08:30 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 31 May 2001 09:08:52 -0400
Message-ID: 
From: "Roy, Radhika R, ALCTA" 
To: Bob Braden , gratta@lucent.com, sob@harvard.edu,
        mankin@isi.edu
Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu,
        megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org,
        tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com,
        tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
        ITU-SG16@mailbag.cps.INTEL.COM
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
	 ND-TO-END QOS SERVICE CONTROL
Date: Thu, 31 May 2001 09:08:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hi, Bob:

All applications (e.g., H.323, SIP) uses signaling messages among its
functional entities (e.g., terminal, agents, gatekeepers, proxies, gateways)
for communications.

The signaling messages that carry QOS parameters are treated as QOS
signaling messages. The applications like SIP and H.323 send signaling
messages end-to-end. H.323 uses H.225.0 RAS, Q.931, Annex G, and H.245
signaling protocols.  SIP also uses SDP as a part of the signaling messages.


The signaling messages that carry QOS related information can be treated as
"End-to-End QOS signaling" messages.

Kindly see the ongoing works of Q.F/16 of SG16. This will provide more
information related to your questions.

Hope this helps.

Best regards,
Radhika R. Roy

-----Original Message-----
From: Bob Braden [mailto:braden@ISI.EDU]
Sent: Wednesday, May 30, 2001 7:39 PM
To: gratta@lucent.com; sob@harvard.edu; mankin@ISI.EDU; Roy, Radhika R,
ALCTA
Cc: diffserv@ietf.org; iptel@lists.bell-labs.com;
issll@mercury.lcs.mit.edu; megaco@fore.com; sip@lists.bell-labs.com;
sipping@ietf.org; tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp;
rbuhrke@lucent.com; tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch;
ITU-SG16@mailbag.cps.INTEL.COM
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR
E ND-TO-END QOS SERVICE CONTROL



  *> From owner-issll@mercury.lcs.mit.edu  Wed May 30 14:59:58 2001
  *> From: "Roy, Radhika R, ALCTA" 
  *> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU
  *> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com,
issll@mercury.lcs.mit.edu,
  *>    megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org,
tsvwg@ietf.org,
  *>    Yukio Hiramatsu
  *> 	 , rbuhrke@lucent.com,
  *>    tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
ITU-SG16@mailbag.cps.INTEL.COM
  *> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM
FOR E
  *> 	ND-TO-END QOS SERVICE CONTROL
  *> Date: Wed, 30 May 2001 17:21:14 -0400
  *> MIME-Version: 1.0
  *> 
  *> Hi, Everyone:
  *>  
  *> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing
standards
  *> for "End-to-End QOS for Multimedia Applications". Contributions are
also
  *> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001
  *> meeting.

This is very confusing.   "End-to-End QOS for Multimedia Applications"
is an really important topic, but this topic must be a superset of
"End-to-End QOS signaling".  There are much harder problems than
signaling in providing E2E QoS.  Can you explain how signaling relates
to the title of this working party?

Thanks,

Bob Braden

  *>  
  *> Applications like H.323, SIP, H.324, H.310, and others will also be
able to
  *> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will
also be
  *> able to use this when specs are fully developed and, TIPHON's QOS
mechanisms
  *> can also be used as one of the mechanisms for implementations.


From owner-megaco@fore.com  Thu May 31 09:27:20 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24113
	for ; Thu, 31 May 2001 09:27:19 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA14115;
	Thu, 31 May 2001 09:16:26 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA02786
	for megaco-list; Thu, 31 May 2001 09:15:31 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA02778
	for ; Thu, 31 May 2001 09:15:29 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 31 May 2001 09:15:29 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF044654C5@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'knayar@hss.hns.com'" , megaco@fore.com
Subject: RE: Network Package
Date: Thu, 31 May 2001 09:15:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Like any protocol, you can misuse it.  The design of the protocol
can discourage misuse, but it can never eliminate it.  There is
nothing that prevents you from, for example, setting an event
descriptor that has the SAME event listed twice.

What should you do?  It's not an error in the sense that the
protocol declares it to be illegal.

The results are probably unpredictable.  That is okay.
We can't realistically fix stupid programs.  We can specify 
what happens in realistic situations.  There are reasonable
scenarios where an MG may wish to expose the underlying package,
but most don't make any sense.  If an MGC is stupid enough to
specify both events on the same termination, what it gets may be
a surprise.  I won't stay up nights worrying about it.

Brian

> -----Original Message-----
> From: knayar@hss.hns.com [mailto:knayar@hss.hns.com]
> Sent: Thursday, May 31, 2001 7:55 AM
> To: megaco@fore.com
> Subject: RE: Network Package
> 
> 
> 
> 
> Hi
> 
> Apart from the IG not mentioning about the "double notify", 
> we have another
> issue....
> In case both the events in the ED have an embedded event 
> descriptor(EED), which
> EED should be activated.
> Is it decided based upon the sequence of events in the ED ??
> ...if it is so we donot guarantee "double notify"...in case 
> of EEDs...is it
> right.
> 
> Would it not be appropriate to restrict the definition of 
> A/E1 and B/E1 (in case
> B extends a package A with event E1), to mean the same event...
> 
> How about restricting MG as well as MGC to expose only "leaf" 
> packages (extended
> packages) but to be lenient enough to accept both base as 
> well as extended
> package definitions....this would take care of any 
> interoperability and
> compatibilty issues too.
> Hence, MGC would send only A/E1 in ED but can accept A/E1 and 
> B/E1 in observed
> ED.
> and MG shall send only A/E1 in observed ED (or A in Audit 
> response) and accept
> B/E1 in ED etc.
> Any comments..
> 
> -Kapil Nayar
> Hughes Software Systems
> 
> 
> 
> HI Peter/All,
> 
> Might be an implementation issue but let me put the same 
> query with some
> sample code.
> 
> The Section 7.1.9 Events Descriptor 4th paragraph,
> "When an event is processed against the contents of an active Events
>    descriptor and found to be present in that descriptor 
> ("recognized"),
>    the default action of the MG is to send a Notify command 
> to the MG."
> 
> After interpretation, the statement above was implemented as follows
> 
> ProcessDetectedEvent( Event detected is passed)
> {
>   if ( Events Descriptor is active)
>   {
>       for ( each event in the events descriptor )
>       {
>            if ( match Found)
>            {
>                  GenerateNotifyTowardsMGC ( event, timestamp, 
> RequestId,
> etc...)
>                  PostEventDetectionProcessing(Event Detected)
>                  break;
>            }
>       }
>   }
>   else
>      ProcessEventAccordingToEventsBufferDescriptor( Event detected is
> passed)
> }
> 
> Its true that the IG mentions about package extension, but no 
> where (I mean
> either in IG/protocol) its mentioned that if one event 
> recognition matches
> two events in the Events Descriptor...(at First I wondered 
> how this was
> possible...) there will be two Notify commands generated towards MGC.
> 
> IMHO Unless explicitly mentioned about the multiple Notifies 
> for single
> hardware event, the general interpretation of event matching 
> will be some
> thing as shown above...which is actually not the intent.
> 
> Regards
> Madhubabu
> 
> 
> 
> 
> -----Original Message-----
> From: Blatherwick, Peter [mailto:Peter_Blatherwick@Mitel.COM]
> Sent: Tuesday, May 29, 2001 10:05 PM
> To: 'Madhu Babu Brahmanapally'; megaco@fore.com
> Subject: RE: Network Package
> 
> 
> Now I'm not so sure what you're getting at below -- what is 
> different from
> previous examples.  I see the rules as completely general.  
> MG simply checks
> for events to report (redundant or not, doesn't care or even 
> necessarily
> know), in the order requested, and for each one follows the
> buffering/reporting algorithm per current handling settings.  
> Perhaps a more
> explicit example?
> 
> Re the IG, I don't think it explicitly mentions "synonyms" 
> (nice term by the
> way ;-), but does give clear guidance on what is considered 
> equivalent, how
> the MG exposes its interfaces, and how the MGC specifies what 
> it wants.
> Event reporting text in the core protocol document and/or IG 
> I personally
> believe already are clear on how events are reported.  Since 
> we are not
> talking about special cases, simply same handling for all 
> events requested
> by MGC, I don't see that specific text is required.  My opinion.
> 
> -- Peter
> 
> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: May 29, 2001 21:44
> To: 'Blatherwick, Peter'; 'Rosen, Brian'; 'Chuong Nguyen';
> megaco@fore.com
> Subject: RE: Network Package
> 
> 
> HI Peter/All,
> 
> I agree that the MG does whatever is said by the MGC. But, if 
> say Events
> Descriptor is X,Y,Z and say X and Z means the same (Similar 
> to the A/T1 and
> B/T1). Now the MG while reporting the event in the Notify 
> also has to check
> events beyond match???? Is this fine???
> 
> 1) Then this has to be true while buffering events in Events Buffer
> according to Event Buffer descriptor and
> 2) While processing of new events descriptor when Event 
> Buffer control is
> lockstep.
> 
> But I see no such statement in the Protocol Text. If the intention of
> matching of event is to match all the "synonyms" of the 
> event. Then this
> text needs to be specified in the IG at least to avoid any
> misunderstandings.
> 
> Regards
> Madhubabu
> 
> 
> -----Original Message-----
> From: Blatherwick, Peter [mailto:Peter_Blatherwick@Mitel.COM]
> Sent: Tuesday, May 29, 2001 9:22 PM
> To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen';
> megaco@fore.com
> Subject: RE: Network Package
> 
> 
> As in previous e-mail, just sent, I don't believe the below 
> error should
> apply to the case of MGC requesting both A/T1 and B/T1.   MG is simply
> responding to the request.   May be a better case for using 
> this if the
> request is for A/T1 and A/T1, but I still don't think so.  MG 
> simply does as
> its told.
> -- Peter
> 
> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: May 29, 2001 19:19
> To: 'Rosen, Brian'; 'Chuong Nguyen'; megaco@fore.com
> Subject: RE: Network Package
> 
> 
> Brian/All,
> 
> Sorry for wrong information in my earlier mail.... Error code "456 -
> Parameter or Property appears twice in this Descriptor" is present for
> avoiding multiple instances of properties/parameters. If A/T1 
> and B/T1 mean
> the same doesn't this fall into the above error category.
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> Sent: Tuesday, May 29, 2001 5:47 PM
> To: 'Chuong Nguyen'; megaco@fore.com
> Subject: RE: Network Package
> 
> 
> Well rtp/dur and nt/dur are "the same thing" in the sense 
> that the mean the
> same
> thing, but if you implement (expose) both packages, then they 
> are "separate"
> statistics.  Using Events is perhaps easier to understand.  
> Suppose Package
> A
> implements event E1, and package B extends Package A, and a given
> implementation
> exposes both A and B, such that an audit of termination T1 returns
> Packages{..A,B..}
> 
> You can say Add=T1{Events=123{B/E1}}
> or you can say
> Add=T1{Events=123{A/T1}}
> or even
> Add=T1{Events=123{A/T1,B/T1}}
> 
> In the latter, detection of the event would result in a 
> notify of both.
> 
> Returning to statistics, the value would be the same, but 
> they are separate
> statistics.
> 
> Brian
> 
> -----Original Message-----
> From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> Sent: Tuesday, May 29, 2001 5:29 PM
> To: megaco@fore.com
> Subject: Re: Network Package
> 
> 
> "Rosen, Brian" wrote:
> 
> If you implement any part of a package, you implement all of 
> it.If a package
> extends any part of a package, it extends all of it.
> 
> What is not required is that if you implement a package that 
> extendsanother
> package that you have to "expose" the underlying package.This 
> means that if
> you implement rtp you don't have to expose nt.If you list nt 
> as one of the
> packages in an audit, then you have toimplement nt/dur.
> 
> 
>   I don't quite follow here.
>                You seem to imply that nt/dur and rtp/dur are 
> 2 different
> things.
>                I thought both nt/dur and rtp/dur are the same 
> thing w/the
> same value.
>               If MG exposed nt, what should it return for 
> duration - nt/dur
> or rtp/dur?
> 
> 
> Do you know the intend of tdmc/os and tdmc/or?
> I thought the same as Madhubabu about how they are calculated.
> 
> 
> 
> 
> 
> 
> Brian
> 
> -----Original Message-----
> From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com
>  ]
> Sent: Tuesday, May 29, 2001 5:15 PM
> To: 'Chuong Nguyen'
> Cc: megaco@fore.com
> Subject: RE: Network Package
> Hi chuong/all,IMO if PackageB extends PackageA and if one of the
> statistic/property of Package A is not valid for termination realizing
> packageB then there is no reason why PackageB extends PackageA. Then
> PackageB shouldn't extend PackageA (just only to reuse few
> properties/statistics) but should define the same properties 
> (Might be with
> different IDs) in packageB. I think the extension of packages 
> is logical if
> the newly defined package can inherit "all" the properties 
> already defined
> in the base package and also define new properties. In your 
> example, I was
> in the impression that "OS" and "OR" can be calculated as 
> "The number of
> octet sent or received is equal to the duration of the Termination, in
> seconds, multiplied by the sampling frequency,  8000 Hz.". 
> (Of course this
> seems to be redundant info if the MGC is aware of the 
> sampling frequency).
> Isn't this the intention?????-RegardsMadhubabu
> 
> -----Original Message-----
> From: owner-megaco@pit.comms.marconi.com
>  mailto:owner-megaco@pit.comms.marconi.com
>  ]On Behalf Of 
> Chuong Nguyen
> Sent: Tuesday, May 29, 2001 4:38 PM
> To: megaco@fore.com
> Subject: Network Package
> Hi All
> 
> 
> Is it reasonable to assume that Network Package StatisticsID 
> will never be
> used directly?
> That is nt/dur, nt/os and nt/or will normally be rtp/dur, 
> rtp/os and rtp/or
> respectiviely
> since rtp package extends nt package.
> 
> 
> I know that it is agreed that if a termination realizes rtp 
> package, it also
> realizes nt package
> and either nt/.. or rtp/.. are valid packageName.
> 
> 
> But if we allow, nt/... instead of rtp/.., are we saying that if MGC
> receives nt/.., it has to
> know whether it is for rtp or tmcd termination by the terminationID?
> 
> 
> 
> Furthermore, since tdmc package extends nt package, do "octet 
> sent" (OS) and
> "octet
> received" (OR) really apply to tdm termination?
> 
> 
> Also what does it mean for a TDM termination to realize the 
> "NT" package
> properties
> of "Maximum Jitter Buffer"?
> 
> 
> So a more general question, if a termination realizes a packageB that
> extends
> packageA and there are items in the packageA that does not 
> make sense to
> the termination what should MG/MGC do.
> 
> 
> Take the above as an example and assuming that it does not 
> make sense for
> TDM
> termination to have "OS" and "OR", what should MG return for 
> TDM termination
> statistics if the termination realizes "TDMC" package?
> Just "duration".
> 
> 
> ---
> Said it is valid to have "OS" and "OR" for TDM.
> IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP
> termination,
> is it valid for MG to return nt/dur, nt/os and nt/or for the 
> TDM termination
> and RTP
> termination instead of tdmc/dur, ... vs rtp/dur ?
> 
> 
> Thanks
> Chuong
> 
> 
> 
> 
> --
> 
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
> 
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
> 
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
> 
> 
> --
> 
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
> 
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
> 
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
> 
> 
> 
> 


From owner-megaco@fore.com  Thu May 31 11:30:47 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28697
	for ; Thu, 31 May 2001 11:30:47 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25921;
	Thu, 31 May 2001 11:15:42 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA09006
	for megaco-list; Thu, 31 May 2001 11:14:26 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08946
	for ; Thu, 31 May 2001 11:14:17 -0400 (EDT)
Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25644
	for ; Thu, 31 May 2001 11:14:13 -0400 (EDT)
Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw)
	by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1)
	id 155U91-00045U-00; Thu, 31 May 2001 16:13:51 +0100
Date: Thu, 31 May 2001 16:13:43 +0100 (BST)
From: Lloyd Wood 
X-Sender: eep1lw@phaestos.ee.surrey.ac.uk
Reply-To: Lloyd Wood 
To: Fred Baker 
cc: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org,
        iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com,
        sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org,
        Yukio Hiramatsu , rbuhrke@lucent.com,
        tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
        John C Klensin , chair@ietf.org
Subject: Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL
 MECHANISM FOR         END-TO-END QOS SERVICE CONTROL
In-Reply-To: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com>
Message-ID: 
Organization: speaking for none
X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/
X-no-archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan *155U91-00045U-00*ZWgRfZ3Wo52* http://duncanthrax.net/exiscan/
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

On Wed, 30 May 2001, Fred Baker wrote:

> Greg:
> 
> The URLs in this note were all sent with what the ETSI machine considered 
> to be 'malformed syntax'. Could you resend the correct URLs?

Just put all the parts together, removing unencoded
spaces; the reason for the breaks after the hyphens seems
obvious enough, but I'm at a loss to explain others. Here we go:

http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc

http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip

http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON

http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt

So http://docbox.etsi.org/ is passworded but docs can be retrieved by
advertised public direct url? Bizarre.

L.

PGP









From owner-megaco@fore.com  Thu May 31 11:46:06 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29253
	for ; Thu, 31 May 2001 11:46:05 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25627;
	Thu, 31 May 2001 11:14:07 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA07821
	for megaco-list; Thu, 31 May 2001 11:10:17 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA07794
	for ; Thu, 31 May 2001 11:10:13 -0400 (EDT)
Received: from ertpg15e1.nortelnetworks.com (ertpg15e1.nortelnetworks.com [47.234.0.36])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25267
	for ; Thu, 31 May 2001 11:10:10 -0400 (EDT)
Received: from ertpg14e1.nortelnetworks.com (zrtph06m [47.125.208.110])
	by ertpg15e1.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f4VFA6n20026
	for ; Thu, 31 May 2001 11:10:06 -0400 (EDT)
Received: from zrtpd004.us.nortel.com (actually zrtpd004) 
          by ertpg14e1.nortelnetworks.com; Thu, 31 May 2001 11:09:52 -0400
Received: from zrtpd0jn.us.nortel.com ([47.140.202.35]) 
          by zrtpd004.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id LDQVWF1M; Thu, 31 May 2001 11:09:44 -0400
Received: from americasm01.nt.com (kboyle.us.nortel.com [47.142.150.95]) 
          by zrtpd0jn.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id J5XGQLM5; Thu, 31 May 2001 11:09:45 -0400
Message-ID: <3B165E78.395FA845@americasm01.nt.com>
Date: Thu, 31 May 2001 11:08:40 -0400
X-Sybari-Space: 00000000 00000000 00000000
From: "Kevin Boyle" 
Organization: Nortel Networks
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" 
CC: "'knayar@hss.hns.com'" , megaco@fore.com
Subject: Re: Network Package
References: <4FBEA8857476D311A03300204840E1CF044654C5@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

All,

It is exactly these kinds of conundrums that prompted me to post some months
ago about the ability to address signals/etc. by the extension package ID.
Why is this necessary?  If you support an extension, then, by definition,
you support the base package.  So why not mandate that signals/etc. from the
base package be addressed by the base package?  This prevents such silliness
as getting multiple copies of a statistic (a/t1, b/t1).  Then the only time
there would be an overlap would be when there is a functional extension of
the signal/etc. by the extension, such as adding new values for a
parameter.  Then, if you wish to take advantage of the new values, it would
be addressed as the extension package.

To illustrate:

Package a: e1, e2{parm1=1,2,3}, s1, p1, t1
Package b extends a: e2{parm1=1,2,3,4}, e3, s2, p2, t2

These would then be addressed as:

a/e1
a/e2{parm1} (in this case, parm1 may only have value 1, 2, or 3)
b/e2{parm1} (in this case, parm1 may have value 1, 2, 3, or 4)
b/e3
a/s1
b/s2
a/p1
b/p2
a/t1
b/t2

This would reduce a lot of these redundancy problems when talking about
package extensions, and, it seems to me, is a very concise way of handling
extensions without having to "hide" packages in the MG.  Now, this certainly
does not handle multiple copies of the same event, but that would qualify
as, as Brian puts it, a "stupid program".

That's my two cents worth, anyway...

Kevin

"Rosen, Brian" wrote:

> Like any protocol, you can misuse it.  The design of the protocol
> can discourage misuse, but it can never eliminate it.  There is
> nothing that prevents you from, for example, setting an event
> descriptor that has the SAME event listed twice.
>
> What should you do?  It's not an error in the sense that the
> protocol declares it to be illegal.
>
> The results are probably unpredictable.  That is okay.
> We can't realistically fix stupid programs.  We can specify
> what happens in realistic situations.  There are reasonable
> scenarios where an MG may wish to expose the underlying package,
> but most don't make any sense.  If an MGC is stupid enough to
> specify both events on the same termination, what it gets may be
> a surprise.  I won't stay up nights worrying about it.
>
> Brian
>
> > -----Original Message-----
> > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com]
> > Sent: Thursday, May 31, 2001 7:55 AM
> > To: megaco@fore.com
> > Subject: RE: Network Package
> >
> >
> >
> >
> > Hi
> >
> > Apart from the IG not mentioning about the "double notify",
> > we have another
> > issue....
> > In case both the events in the ED have an embedded event
> > descriptor(EED), which
> > EED should be activated.
> > Is it decided based upon the sequence of events in the ED ??
> > ...if it is so we donot guarantee "double notify"...in case
> > of EEDs...is it
> > right.
> >
> > Would it not be appropriate to restrict the definition of
> > A/E1 and B/E1 (in case
> > B extends a package A with event E1), to mean the same event...
> >
> > How about restricting MG as well as MGC to expose only "leaf"
> > packages (extended
> > packages) but to be lenient enough to accept both base as
> > well as extended
> > package definitions....this would take care of any
> > interoperability and
> > compatibilty issues too.
> > Hence, MGC would send only A/E1 in ED but can accept A/E1 and
> > B/E1 in observed
> > ED.
> > and MG shall send only A/E1 in observed ED (or A in Audit
> > response) and accept
> > B/E1 in ED etc.
> > Any comments..
> >
> > -Kapil Nayar
> > Hughes Software Systems
> >
> >
> >
> > HI Peter/All,
> >
> > Might be an implementation issue but let me put the same
> > query with some
> > sample code.
> >
> > The Section 7.1.9 Events Descriptor 4th paragraph,
> > "When an event is processed against the contents of an active Events
> >    descriptor and found to be present in that descriptor
> > ("recognized"),
> >    the default action of the MG is to send a Notify command
> > to the MG."
> >
> > After interpretation, the statement above was implemented as follows
> >
> > ProcessDetectedEvent( Event detected is passed)
> > {
> >   if ( Events Descriptor is active)
> >   {
> >       for ( each event in the events descriptor )
> >       {
> >            if ( match Found)
> >            {
> >                  GenerateNotifyTowardsMGC ( event, timestamp,
> > RequestId,
> > etc...)
> >                  PostEventDetectionProcessing(Event Detected)
> >                  break;
> >            }
> >       }
> >   }
> >   else
> >      ProcessEventAccordingToEventsBufferDescriptor( Event detected is
> > passed)
> > }
> >
> > Its true that the IG mentions about package extension, but no
> > where (I mean
> > either in IG/protocol) its mentioned that if one event
> > recognition matches
> > two events in the Events Descriptor...(at First I wondered
> > how this was
> > possible...) there will be two Notify commands generated towards MGC.
> >
> > IMHO Unless explicitly mentioned about the multiple Notifies
> > for single
> > hardware event, the general interpretation of event matching
> > will be some
> > thing as shown above...which is actually not the intent.
> >
> > Regards
> > Madhubabu
> >
> >
> >
> >
> > -----Original Message-----
> > From: Blatherwick, Peter [mailto:Peter_Blatherwick@Mitel.COM]
> > Sent: Tuesday, May 29, 2001 10:05 PM
> > To: 'Madhu Babu Brahmanapally'; megaco@fore.com
> > Subject: RE: Network Package
> >
> >
> > Now I'm not so sure what you're getting at below -- what is
> > different from
> > previous examples.  I see the rules as completely general.
> > MG simply checks
> > for events to report (redundant or not, doesn't care or even
> > necessarily
> > know), in the order requested, and for each one follows the
> > buffering/reporting algorithm per current handling settings.
> > Perhaps a more
> > explicit example?
> >
> > Re the IG, I don't think it explicitly mentions "synonyms"
> > (nice term by the
> > way ;-), but does give clear guidance on what is considered
> > equivalent, how
> > the MG exposes its interfaces, and how the MGC specifies what
> > it wants.
> > Event reporting text in the core protocol document and/or IG
> > I personally
> > believe already are clear on how events are reported.  Since
> > we are not
> > talking about special cases, simply same handling for all
> > events requested
> > by MGC, I don't see that specific text is required.  My opinion.
> >
> > -- Peter
> >
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > Sent: May 29, 2001 21:44
> > To: 'Blatherwick, Peter'; 'Rosen, Brian'; 'Chuong Nguyen';
> > megaco@fore.com
> > Subject: RE: Network Package
> >
> >
> > HI Peter/All,
> >
> > I agree that the MG does whatever is said by the MGC. But, if
> > say Events
> > Descriptor is X,Y,Z and say X and Z means the same (Similar
> > to the A/T1 and
> > B/T1). Now the MG while reporting the event in the Notify
> > also has to check
> > events beyond match???? Is this fine???
> >
> > 1) Then this has to be true while buffering events in Events Buffer
> > according to Event Buffer descriptor and
> > 2) While processing of new events descriptor when Event
> > Buffer control is
> > lockstep.
> >
> > But I see no such statement in the Protocol Text. If the intention of
> > matching of event is to match all the "synonyms" of the
> > event. Then this
> > text needs to be specified in the IG at least to avoid any
> > misunderstandings.
> >
> > Regards
> > Madhubabu
> >
> >
> > -----Original Message-----
> > From: Blatherwick, Peter [mailto:Peter_Blatherwick@Mitel.COM]
> > Sent: Tuesday, May 29, 2001 9:22 PM
> > To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen';
> > megaco@fore.com
> > Subject: RE: Network Package
> >
> >
> > As in previous e-mail, just sent, I don't believe the below
> > error should
> > apply to the case of MGC requesting both A/T1 and B/T1.   MG is simply
> > responding to the request.   May be a better case for using
> > this if the
> > request is for A/T1 and A/T1, but I still don't think so.  MG
> > simply does as
> > its told.
> > -- Peter
> >
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > Sent: May 29, 2001 19:19
> > To: 'Rosen, Brian'; 'Chuong Nguyen'; megaco@fore.com
> > Subject: RE: Network Package
> >
> >
> > Brian/All,
> >
> > Sorry for wrong information in my earlier mail.... Error code "456 -
> > Parameter or Property appears twice in this Descriptor" is present for
> > avoiding multiple instances of properties/parameters. If A/T1
> > and B/T1 mean
> > the same doesn't this fall into the above error category.
> >
> > Regards
> > Madhubabu
> >
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> > Sent: Tuesday, May 29, 2001 5:47 PM
> > To: 'Chuong Nguyen'; megaco@fore.com
> > Subject: RE: Network Package
> >
> >
> > Well rtp/dur and nt/dur are "the same thing" in the sense
> > that the mean the
> > same
> > thing, but if you implement (expose) both packages, then they
> > are "separate"
> > statistics.  Using Events is perhaps easier to understand.
> > Suppose Package
> > A
> > implements event E1, and package B extends Package A, and a given
> > implementation
> > exposes both A and B, such that an audit of termination T1 returns
> > Packages{..A,B..}
> >
> > You can say Add=T1{Events=123{B/E1}}
> > or you can say
> > Add=T1{Events=123{A/T1}}
> > or even
> > Add=T1{Events=123{A/T1,B/T1}}
> >
> > In the latter, detection of the event would result in a
> > notify of both.
> >
> > Returning to statistics, the value would be the same, but
> > they are separate
> > statistics.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > Sent: Tuesday, May 29, 2001 5:29 PM
> > To: megaco@fore.com
> > Subject: Re: Network Package
> >
> >
> > "Rosen, Brian" wrote:
> >
> > If you implement any part of a package, you implement all of
> > it.If a package
> > extends any part of a package, it extends all of it.
> >
> > What is not required is that if you implement a package that
> > extendsanother
> > package that you have to "expose" the underlying package.This
> > means that if
> > you implement rtp you don't have to expose nt.If you list nt
> > as one of the
> > packages in an audit, then you have toimplement nt/dur.
> >
> >
> >   I don't quite follow here.
> >                You seem to imply that nt/dur and rtp/dur are
> > 2 different
> > things.
> >                I thought both nt/dur and rtp/dur are the same
> > thing w/the
> > same value.
> >               If MG exposed nt, what should it return for
> > duration - nt/dur
> > or rtp/dur?
> >
> >
> > Do you know the intend of tdmc/os and tdmc/or?
> > I thought the same as Madhubabu about how they are calculated.
> >
> >
> >
> >
> >
> >
> > Brian
> >
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com
> >  ]
> > Sent: Tuesday, May 29, 2001 5:15 PM
> > To: 'Chuong Nguyen'
> > Cc: megaco@fore.com
> > Subject: RE: Network Package
> > Hi chuong/all,IMO if PackageB extends PackageA and if one of the
> > statistic/property of Package A is not valid for termination realizing
> > packageB then there is no reason why PackageB extends PackageA. Then
> > PackageB shouldn't extend PackageA (just only to reuse few
> > properties/statistics) but should define the same properties
> > (Might be with
> > different IDs) in packageB. I think the extension of packages
> > is logical if
> > the newly defined package can inherit "all" the properties
> > already defined
> > in the base package and also define new properties. In your
> > example, I was
> > in the impression that "OS" and "OR" can be calculated as
> > "The number of
> > octet sent or received is equal to the duration of the Termination, in
> > seconds, multiplied by the sampling frequency,  8000 Hz.".
> > (Of course this
> > seems to be redundant info if the MGC is aware of the
> > sampling frequency).
> > Isn't this the intention?????-RegardsMadhubabu
> >
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> >  mailto:owner-megaco@pit.comms.marconi.com
> >  ]On Behalf Of
> > Chuong Nguyen
> > Sent: Tuesday, May 29, 2001 4:38 PM
> > To: megaco@fore.com
> > Subject: Network Package
> > Hi All
> >
> >
> > Is it reasonable to assume that Network Package StatisticsID
> > will never be
> > used directly?
> > That is nt/dur, nt/os and nt/or will normally be rtp/dur,
> > rtp/os and rtp/or
> > respectiviely
> > since rtp package extends nt package.
> >
> >
> > I know that it is agreed that if a termination realizes rtp
> > package, it also
> > realizes nt package
> > and either nt/.. or rtp/.. are valid packageName.
> >
> >
> > But if we allow, nt/... instead of rtp/.., are we saying that if MGC
> > receives nt/.., it has to
> > know whether it is for rtp or tmcd termination by the terminationID?
> >
> >
> >
> > Furthermore, since tdmc package extends nt package, do "octet
> > sent" (OS) and
> > "octet
> > received" (OR) really apply to tdm termination?
> >
> >
> > Also what does it mean for a TDM termination to realize the
> > "NT" package
> > properties
> > of "Maximum Jitter Buffer"?
> >
> >
> > So a more general question, if a termination realizes a packageB that
> > extends
> > packageA and there are items in the packageA that does not
> > make sense to
> > the termination what should MG/MGC do.
> >
> >
> > Take the above as an example and assuming that it does not
> > make sense for
> > TDM
> > termination to have "OS" and "OR", what should MG return for
> > TDM termination
> > statistics if the termination realizes "TDMC" package?
> > Just "duration".
> >
> >
> > ---
> > Said it is valid to have "OS" and "OR" for TDM.
> > IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP
> > termination,
> > is it valid for MG to return nt/dur, nt/os and nt/or for the
> > TDM termination
> > and RTP
> > termination instead of tdmc/dur, ... vs rtp/dur ?
> >
> >
> > Thanks
> > Chuong
> >
> >
> >
> >
> > --
> >
> >   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
> >
> >   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
> >
> >   **** The opinions expressed are not those of Alcatel USA, Inc ****
> >
> >
> > --
> >
> >   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
> >
> >   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
> >
> >   **** The opinions expressed are not those of Alcatel USA, Inc ****
> >
> >
> >
> >



From owner-megaco@fore.com  Thu May 31 12:00:17 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29927
	for ; Thu, 31 May 2001 12:00:17 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA28366;
	Thu, 31 May 2001 11:39:33 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA15374
	for megaco-list; Thu, 31 May 2001 11:38:20 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA15347
	for ; Thu, 31 May 2001 11:38:16 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 31 May 2001 11:38:16 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF044654D2@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Kevin Boyle'" 
Cc: "'knayar@hss.hns.com'" , megaco@fore.com
Subject: RE: Network Package
Date: Thu, 31 May 2001 11:38:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

I prefer the current design, where the extension inherits the
properties/events/signals/statistics from the base.
I think there are lots of cases where it's better to NOT expose
the base package.  Your proposal would disallow that possibility.
I think the duplication is not much of an issue.

Brian

> -----Original Message-----
> From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
> Sent: Thursday, May 31, 2001 11:09 AM
> To: Rosen, Brian
> Cc: 'knayar@hss.hns.com'; megaco@fore.com
> Subject: Re: Network Package
> 
> 
> All,
> 
> It is exactly these kinds of conundrums that prompted me to 
> post some months
> ago about the ability to address signals/etc. by the 
> extension package ID.
> Why is this necessary?  If you support an extension, then, by 
> definition,
> you support the base package.  So why not mandate that 
> signals/etc. from the
> base package be addressed by the base package?  This prevents 
> such silliness
> as getting multiple copies of a statistic (a/t1, b/t1).  Then 
> the only time
> there would be an overlap would be when there is a functional 
> extension of
> the signal/etc. by the extension, such as adding new values for a
> parameter.  Then, if you wish to take advantage of the new 
> values, it would
> be addressed as the extension package.
> 
> To illustrate:
> 
> Package a: e1, e2{parm1=1,2,3}, s1, p1, t1
> Package b extends a: e2{parm1=1,2,3,4}, e3, s2, p2, t2
> 
> These would then be addressed as:
> 
> a/e1
> a/e2{parm1} (in this case, parm1 may only have value 1, 2, or 3)
> b/e2{parm1} (in this case, parm1 may have value 1, 2, 3, or 4)
> b/e3
> a/s1
> b/s2
> a/p1
> b/p2
> a/t1
> b/t2
> 
> This would reduce a lot of these redundancy problems when 
> talking about
> package extensions, and, it seems to me, is a very concise 
> way of handling
> extensions without having to "hide" packages in the MG.  Now, 
> this certainly
> does not handle multiple copies of the same event, but that 
> would qualify
> as, as Brian puts it, a "stupid program".
> 
> That's my two cents worth, anyway...
> Kevin
> 
> "Rosen, Brian" wrote:
> 
> > Like any protocol, you can misuse it.  The design of the protocol
> > can discourage misuse, but it can never eliminate it.  There is
> > nothing that prevents you from, for example, setting an event
> > descriptor that has the SAME event listed twice.
> >
> > What should you do?  It's not an error in the sense that the
> > protocol declares it to be illegal.
> >
> > The results are probably unpredictable.  That is okay.
> > We can't realistically fix stupid programs.  We can specify
> > what happens in realistic situations.  There are reasonable
> > scenarios where an MG may wish to expose the underlying package,
> > but most don't make any sense.  If an MGC is stupid enough to
> > specify both events on the same termination, what it gets may be
> > a surprise.  I won't stay up nights worrying about it.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com]
> > > Sent: Thursday, May 31, 2001 7:55 AM
> > > To: megaco@fore.com
> > > Subject: RE: Network Package
> > >
> > >
> > >
> > >
> > > Hi
> > >
> > > Apart from the IG not mentioning about the "double notify",
> > > we have another
> > > issue....
> > > In case both the events in the ED have an embedded event
> > > descriptor(EED), which
> > > EED should be activated.
> > > Is it decided based upon the sequence of events in the ED ??
> > > ...if it is so we donot guarantee "double notify"...in case
> > > of EEDs...is it
> > > right.
> > >
> > > Would it not be appropriate to restrict the definition of
> > > A/E1 and B/E1 (in case
> > > B extends a package A with event E1), to mean the same event...
> > >
> > > How about restricting MG as well as MGC to expose only "leaf"
> > > packages (extended
> > > packages) but to be lenient enough to accept both base as
> > > well as extended
> > > package definitions....this would take care of any
> > > interoperability and
> > > compatibilty issues too.
> > > Hence, MGC would send only A/E1 in ED but can accept A/E1 and
> > > B/E1 in observed
> > > ED.
> > > and MG shall send only A/E1 in observed ED (or A in Audit
> > > response) and accept
> > > B/E1 in ED etc.
> > > Any comments..
> > >
> > > -Kapil Nayar
> > > Hughes Software Systems
> > >
> > >
> > >
> > > HI Peter/All,
> > >
> > > Might be an implementation issue but let me put the same
> > > query with some
> > > sample code.
> > >
> > > The Section 7.1.9 Events Descriptor 4th paragraph,
> > > "When an event is processed against the contents of an 
> active Events
> > >    descriptor and found to be present in that descriptor
> > > ("recognized"),
> > >    the default action of the MG is to send a Notify command
> > > to the MG."
> > >
> > > After interpretation, the statement above was implemented 
> as follows
> > >
> > > ProcessDetectedEvent( Event detected is passed)
> > > {
> > >   if ( Events Descriptor is active)
> > >   {
> > >       for ( each event in the events descriptor )
> > >       {
> > >            if ( match Found)
> > >            {
> > >                  GenerateNotifyTowardsMGC ( event, timestamp,
> > > RequestId,
> > > etc...)
> > >                  PostEventDetectionProcessing(Event Detected)
> > >                  break;
> > >            }
> > >       }
> > >   }
> > >   else
> > >      ProcessEventAccordingToEventsBufferDescriptor( Event 
> detected is
> > > passed)
> > > }
> > >
> > > Its true that the IG mentions about package extension, but no
> > > where (I mean
> > > either in IG/protocol) its mentioned that if one event
> > > recognition matches
> > > two events in the Events Descriptor...(at First I wondered
> > > how this was
> > > possible...) there will be two Notify commands generated 
> towards MGC.
> > >
> > > IMHO Unless explicitly mentioned about the multiple Notifies
> > > for single
> > > hardware event, the general interpretation of event matching
> > > will be some
> > > thing as shown above...which is actually not the intent.
> > >
> > > Regards
> > > Madhubabu
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Blatherwick, Peter [mailto:Peter_Blatherwick@Mitel.COM]
> > > Sent: Tuesday, May 29, 2001 10:05 PM
> > > To: 'Madhu Babu Brahmanapally'; megaco@fore.com
> > > Subject: RE: Network Package
> > >
> > >
> > > Now I'm not so sure what you're getting at below -- what is
> > > different from
> > > previous examples.  I see the rules as completely general.
> > > MG simply checks
> > > for events to report (redundant or not, doesn't care or even
> > > necessarily
> > > know), in the order requested, and for each one follows the
> > > buffering/reporting algorithm per current handling settings.
> > > Perhaps a more
> > > explicit example?
> > >
> > > Re the IG, I don't think it explicitly mentions "synonyms"
> > > (nice term by the
> > > way ;-), but does give clear guidance on what is considered
> > > equivalent, how
> > > the MG exposes its interfaces, and how the MGC specifies what
> > > it wants.
> > > Event reporting text in the core protocol document and/or IG
> > > I personally
> > > believe already are clear on how events are reported.  Since
> > > we are not
> > > talking about special cases, simply same handling for all
> > > events requested
> > > by MGC, I don't see that specific text is required.  My opinion.
> > >
> > > -- Peter
> > >
> > > -----Original Message-----
> > > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > > Sent: May 29, 2001 21:44
> > > To: 'Blatherwick, Peter'; 'Rosen, Brian'; 'Chuong Nguyen';
> > > megaco@fore.com
> > > Subject: RE: Network Package
> > >
> > >
> > > HI Peter/All,
> > >
> > > I agree that the MG does whatever is said by the MGC. But, if
> > > say Events
> > > Descriptor is X,Y,Z and say X and Z means the same (Similar
> > > to the A/T1 and
> > > B/T1). Now the MG while reporting the event in the Notify
> > > also has to check
> > > events beyond match???? Is this fine???
> > >
> > > 1) Then this has to be true while buffering events in 
> Events Buffer
> > > according to Event Buffer descriptor and
> > > 2) While processing of new events descriptor when Event
> > > Buffer control is
> > > lockstep.
> > >
> > > But I see no such statement in the Protocol Text. If the 
> intention of
> > > matching of event is to match all the "synonyms" of the
> > > event. Then this
> > > text needs to be specified in the IG at least to avoid any
> > > misunderstandings.
> > >
> > > Regards
> > > Madhubabu
> > >
> > >
> > > -----Original Message-----
> > > From: Blatherwick, Peter [mailto:Peter_Blatherwick@Mitel.COM]
> > > Sent: Tuesday, May 29, 2001 9:22 PM
> > > To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen';
> > > megaco@fore.com
> > > Subject: RE: Network Package
> > >
> > >
> > > As in previous e-mail, just sent, I don't believe the below
> > > error should
> > > apply to the case of MGC requesting both A/T1 and B/T1.   
> MG is simply
> > > responding to the request.   May be a better case for using
> > > this if the
> > > request is for A/T1 and A/T1, but I still don't think so.  MG
> > > simply does as
> > > its told.
> > > -- Peter
> > >
> > > -----Original Message-----
> > > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > > Sent: May 29, 2001 19:19
> > > To: 'Rosen, Brian'; 'Chuong Nguyen'; megaco@fore.com
> > > Subject: RE: Network Package
> > >
> > >
> > > Brian/All,
> > >
> > > Sorry for wrong information in my earlier mail.... Error 
> code "456 -
> > > Parameter or Property appears twice in this Descriptor" 
> is present for
> > > avoiding multiple instances of properties/parameters. If A/T1
> > > and B/T1 mean
> > > the same doesn't this fall into the above error category.
> > >
> > > Regards
> > > Madhubabu
> > >
> > > -----Original Message-----
> > > From: owner-megaco@pit.comms.marconi.com
> > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of 
> Rosen, Brian
> > > Sent: Tuesday, May 29, 2001 5:47 PM
> > > To: 'Chuong Nguyen'; megaco@fore.com
> > > Subject: RE: Network Package
> > >
> > >
> > > Well rtp/dur and nt/dur are "the same thing" in the sense
> > > that the mean the
> > > same
> > > thing, but if you implement (expose) both packages, then they
> > > are "separate"
> > > statistics.  Using Events is perhaps easier to understand.
> > > Suppose Package
> > > A
> > > implements event E1, and package B extends Package A, and a given
> > > implementation
> > > exposes both A and B, such that an audit of termination T1 returns
> > > Packages{..A,B..}
> > >
> > > You can say Add=T1{Events=123{B/E1}}
> > > or you can say
> > > Add=T1{Events=123{A/T1}}
> > > or even
> > > Add=T1{Events=123{A/T1,B/T1}}
> > >
> > > In the latter, detection of the event would result in a
> > > notify of both.
> > >
> > > Returning to statistics, the value would be the same, but
> > > they are separate
> > > statistics.
> > >
> > > Brian
> > >
> > > -----Original Message-----
> > > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > > Sent: Tuesday, May 29, 2001 5:29 PM
> > > To: megaco@fore.com
> > > Subject: Re: Network Package
> > >
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > If you implement any part of a package, you implement all of
> > > it.If a package
> > > extends any part of a package, it extends all of it.
> > >
> > > What is not required is that if you implement a package that
> > > extendsanother
> > > package that you have to "expose" the underlying package.This
> > > means that if
> > > you implement rtp you don't have to expose nt.If you list nt
> > > as one of the
> > > packages in an audit, then you have toimplement nt/dur.
> > >
> > >
> > >   I don't quite follow here.
> > >                You seem to imply that nt/dur and rtp/dur are
> > > 2 different
> > > things.
> > >                I thought both nt/dur and rtp/dur are the same
> > > thing w/the
> > > same value.
> > >               If MG exposed nt, what should it return for
> > > duration - nt/dur
> > > or rtp/dur?
> > >
> > >
> > > Do you know the intend of tdmc/os and tdmc/or?
> > > I thought the same as Madhubabu about how they are calculated.
> > >
> > >
> > >
> > >
> > >
> > >
> > > Brian
> > >
> > > -----Original Message-----
> > > From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com
> > >  ]
> > > Sent: Tuesday, May 29, 2001 5:15 PM
> > > To: 'Chuong Nguyen'
> > > Cc: megaco@fore.com
> > > Subject: RE: Network Package
> > > Hi chuong/all,IMO if PackageB extends PackageA and if one of the
> > > statistic/property of Package A is not valid for 
> termination realizing
> > > packageB then there is no reason why PackageB extends 
> PackageA. Then
> > > PackageB shouldn't extend PackageA (just only to reuse few
> > > properties/statistics) but should define the same properties
> > > (Might be with
> > > different IDs) in packageB. I think the extension of packages
> > > is logical if
> > > the newly defined package can inherit "all" the properties
> > > already defined
> > > in the base package and also define new properties. In your
> > > example, I was
> > > in the impression that "OS" and "OR" can be calculated as
> > > "The number of
> > > octet sent or received is equal to the duration of the 
> Termination, in
> > > seconds, multiplied by the sampling frequency,  8000 Hz.".
> > > (Of course this
> > > seems to be redundant info if the MGC is aware of the
> > > sampling frequency).
> > > Isn't this the intention?????-RegardsMadhubabu
> > >
> > > -----Original Message-----
> > > From: owner-megaco@pit.comms.marconi.com
> > >  mailto:owner-megaco@pit.comms.marconi.com
> > >  ]On Behalf Of
> > > Chuong Nguyen
> > > Sent: Tuesday, May 29, 2001 4:38 PM
> > > To: megaco@fore.com
> > > Subject: Network Package
> > > Hi All
> > >
> > >
> > > Is it reasonable to assume that Network Package StatisticsID
> > > will never be
> > > used directly?
> > > That is nt/dur, nt/os and nt/or will normally be rtp/dur,
> > > rtp/os and rtp/or
> > > respectiviely
> > > since rtp package extends nt package.
> > >
> > >
> > > I know that it is agreed that if a termination realizes rtp
> > > package, it also
> > > realizes nt package
> > > and either nt/.. or rtp/.. are valid packageName.
> > >
> > >
> > > But if we allow, nt/... instead of rtp/.., are we saying 
> that if MGC
> > > receives nt/.., it has to
> > > know whether it is for rtp or tmcd termination by the 
> terminationID?
> > >
> > >
> > >
> > > Furthermore, since tdmc package extends nt package, do "octet
> > > sent" (OS) and
> > > "octet
> > > received" (OR) really apply to tdm termination?
> > >
> > >
> > > Also what does it mean for a TDM termination to realize the
> > > "NT" package
> > > properties
> > > of "Maximum Jitter Buffer"?
> > >
> > >
> > > So a more general question, if a termination realizes a 
> packageB that
> > > extends
> > > packageA and there are items in the packageA that does not
> > > make sense to
> > > the termination what should MG/MGC do.
> > >
> > >
> > > Take the above as an example and assuming that it does not
> > > make sense for
> > > TDM
> > > termination to have "OS" and "OR", what should MG return for
> > > TDM termination
> > > statistics if the termination realizes "TDMC" package?
> > > Just "duration".
> > >
> > >
> > > ---
> > > Said it is valid to have "OS" and "OR" for TDM.
> > > IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP
> > > termination,
> > > is it valid for MG to return nt/dur, nt/os and nt/or for the
> > > TDM termination
> > > and RTP
> > > termination instead of tdmc/dur, ... vs rtp/dur ?
> > >
> > >
> > > Thanks
> > > Chuong
> > >
> > >
> > >
> > >
> > > --
> > >
> > >   Alcatel USA, Inc             Internet: 
> Chuong.Nguyen@usa.alcatel.com
> > >
> > >   1000 Coit Road Plano, Texas 75075           Phone:    
> (972) 519-4613
> > >
> > >   **** The opinions expressed are not those of Alcatel 
> USA, Inc ****
> > >
> > >
> > > --
> > >
> > >   Alcatel USA, Inc             Internet: 
> Chuong.Nguyen@usa.alcatel.com
> > >
> > >   1000 Coit Road Plano, Texas 75075           Phone:    
> (972) 519-4613
> > >
> > >   **** The opinions expressed are not those of Alcatel 
> USA, Inc ****
> > >
> > >
> > >
> > >
> 


From owner-megaco@fore.com  Thu May 31 12:31:32 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01063
	for ; Thu, 31 May 2001 12:31:31 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA00600;
	Thu, 31 May 2001 12:07:53 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA22417
	for megaco-list; Thu, 31 May 2001 12:06:50 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA22409
	for ; Thu, 31 May 2001 12:06:48 -0400 (EDT)
Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA00459
	for ; Thu, 31 May 2001 12:06:44 -0400 (EDT)
Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92])
	by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA34990;
	Thu, 31 May 2001 09:04:55 -0700
Received: from hursley.ibm.com ([9.29.3.174]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA20120; Thu, 31 May 2001 09:04:54 -0700
Message-ID: <3B166AFC.9DF4CD05@hursley.ibm.com>
Date: Thu, 31 May 2001 11:02:04 -0500
From: Brian E Carpenter 
Organization: IBM
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: gratta@lucent.com
CC: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org,
        iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com,
        sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org,
        Yukio Hiramatsu , rbuhrke@lucent.com,
        tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch
Subject: Re: [Diffserv] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM 
 FOR END-TO-END QOS SERVICE CONTROL
References: <200105302022.QAA03855@hotair.hobl.lucent.com>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.pit.comms.marconi.com id MAA22414
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id MAA00600
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA01063

Folks,

This is *not* a discussion item for the diffserv WG mailing list. This WG is not 
chartered to discuss signalling issues. Whether the ITU should work on this
and if so how it should collaborate with the IETF should be discussed at liaison
level, not on a list with a few hundred people. So please everybody drop this
discussion on the diffserv list and continue elswhere.

Regards
   Brian Carpenter
   diffserv co-chair

Greg Ratta wrote:
> 
> This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com)
> 
> FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES
> 
> General
> 
> Within ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol.
> 
> It was noted that also QoS related work is in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved.
> 
> Proposals on end-to-end QoS service control
> 
> It is proposed to start a joint activity with IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics:
> 
> - Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control.
> 
> - The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane.
> 
> - The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane.
> 
> - The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc.
> 
> Proposals on IP QoS classes and IP Transfer Capabilities
> 
> ITU-T SG11 would like to inform IETF that it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF.
> 
> ATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control.
> 
> The ETSI specifications referenced as base material are available at the following URLs:
> 
> ETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc
> 
> - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p
> 
> Further information about the ETSI TIPHON project is available at the following URL:
> 
> - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON
> __________________
> 
> BICC CS3 signalling requirements for end-to- end QoS service control
> 
> EDITORS’ NOTE: This requirements text for end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups
> 
> 1 Rationale
> 
> The rationale of the BICC CS3 requirements for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine
> the perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well.
> 
> A second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other.
> 
> Therefore end-to-end QoS service control at the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control.
> 
> 2 Framework for end-to-end QoS service control and network QoS control.
> 
> A framework for QoS control may be considered at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP).
> 
> 1) Call-control
> 
> a) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose.
> 
> The idea is that call control protocols are enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size).
> 
> Such a generic end-to-end QoS service control mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear").
> 
> b) BICC (Q.190x) is one of the call control protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323.
> 
> 2) Vertical control
> 
> a) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions.
> 
> These QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network.
> 
> b) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way.
> 
> 3) Bearer control
> 
> a) Network QoS is negotiated/communicated at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities.
> 
> The idea is that bearer control protocols for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities.
> 
> b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced this way.
> 
> 4) Bearer
> 
> a) Network QoS is negotiated/communicated at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic.
> 
> b) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP.
> 
> 3 QoS information flows applicable to BICC
> 
> A general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3.
> 
> Section 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters.
> 
> 4 Q.BICC related QoS primitives and parameters
> 
> The Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3.
> 
> 4.1 Q.BICC related QoS primitives
> 
> This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS related bearer information between the domains of different service providers.
> 
> Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics.
> 
> NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3 clause 8.1.1.
> 
> Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics.
> 
> NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1.
> 
> Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics.
> 
> NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3 clause 8.1.1.
> 
> Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer.
> 
> NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series.
> 
> QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer.
> 
> NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series.
> 
> 4.2 Q.BICC related QoS parameters
> 
> Table 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series.
> 
> NOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3.
> 
> Table 1: Identification of Q.BICC related parameters for end-to-end QoS service control
> Qbicc.QoSreq QoS Service Class Optional
> 
> Codec Type and Packetisation Mandatory
> 
> Transport QoS Parameters Mandatory
> 
> Traffic Descriptor Optional
> 
> Transport Addresses Mandatory
> 
> Application Data Transport Protocol Optional [Default RTP]
> 
> Packet Transport Protocol Optional [Default UDP]
> 
> QoS Mechanism Optional
> 
> Qbicc.QoSconf QoS Service Class Optional
> 
> Codec Type and Packetisation Mandatory
> 
> Transport QoS Parameters Mandatory
> 
> Transport Addresses Mandatory
> 
> Application Data Transport Protocol Optional [Default RTP]
> 
> Packet Transport Protocol Optional [Default UDP]
> 
> Qbicc.QoSrej Reason [TBD] Mandatory
> 
> 5 Q.CBC related QoS primitives and parameters
> 
> The Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3.
> 
> 5.1 Q.CBC related QoS primitives
> 
> This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow.
> 
> Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource.
> 
> NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3.
> 
> Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested transport flow or the reservation of Transport Domain resource.
> 
> NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3.
> 
> Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport flow or the reservation of Transport Domain resource.
> 
> NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3.
> 
> Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a transport flow.
> 
> NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950.
> 
> Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a transport flow.
> 
> NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950.
> 
> Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study.
> 
> NOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study.
> 
> 5.2 Q.CBC related QoS parameters
> 
> Table 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950.
> 
> NOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5.
> 
> Table 2: Identification of Q.CBC related parameters for end-to-end QoS service control
> 
> QT2.TRMQreq Transport QoS Parameters Mandatory
> 
> Traffic Descriptor Mandatory
> 
> Transport Addresses Mandatory
> 
> Packet Transport Protocol Optional [Default UDP]
> 
> QT2.TRMQconf Transport QoS Parameters Mandatory
> 
> Transport Addresses Mandatory
> 
> Packet Transport Protocol Optional [Default UDP]
> 
> QoS Mechanism Optional
> 
> QT2.TRMQrej Reason [TBD] Mandatory
> 
> 6 Parameter contents
> 
> Table 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1.
> 
> Table 3: Identification of parameter contents for end-to-end QoS service control
> 
> QoS Service Class Describes the end-to-end ETSI TIPHON Best, High, Medium
> class of a bearer or Best Effort
> 
> Transport QoS Specifies the QoS characteristics Maximum Delay
> Parameters required of the transport flow
> carrying the media flow. Maximum Packet Delay Variation
> 
> Maximum Packet Loss
> 
> Traffic Descriptor Characterises the resource Peak Bit
> requirements of an application data
> flow (excludes transport flow Maximum Packet Size
> resource requirements).
> 
> Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2
> 
> The maximum delay permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow.
> 
> The maximum packet delay variation permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow.
> 
> The maximum packet loss permitted (%) over either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss]
> Maximum bit rate (bit/s) of the media flow.
> 
> Maximum size of the media packets
> 
> 7 Information flows and signalling procedures for end-to-end QoS service control
> 
> EDITORS’ NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion.
> 
> Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols
> Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com
> 
> _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org


From owner-megaco@fore.com  Thu May 31 12:45:57 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01534
	for ; Thu, 31 May 2001 12:45:55 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA01137;
	Thu, 31 May 2001 12:13:35 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA23343
	for megaco-list; Thu, 31 May 2001 12:12:12 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA23332
	for ; Thu, 31 May 2001 12:12:10 -0400 (EDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id MAA00965
	for ; Thu, 31 May 2001 12:12:07 -0400 (EDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id ; Thu, 31 May 2001 17:11:33 +0100
To: Lloyd Wood 
cc: Fred Baker , gratta@lucent.com, sob@harvard.edu,
        mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com,
        issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com,
        sipping@ietf.org, tsvwg@ietf.org,
        Yukio Hiramatsu , rbuhrke@lucent.com,
        tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
        John C Klensin , chair@ietf.org,
        J.Crowcroft@cs.ucl.ac.uk
Subject: Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL 
         MECHANISM FOR END-TO-END QOS SERVICE CONTROL
In-reply-to: Your message of "Thu, 31 May 2001 16:13:43 BST." 
Date: Thu, 31 May 2001 17:11:29 +0100
Message-ID: <922.991325489@cs.ucl.ac.uk>
From: Jon Crowcroft 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk


so the talk seems to be dated dec 2001, and makes me wonder if the
tiphon folks have achieved a breakthru in QOS
with e2e delays better than 0ms.....

meanwhile, i stuck html versions of the files below at
ftp://cs.ucl.ac.uk/darpa/tiphon/
(prob. doesnt help non windoze users since the html is generated by
office 2000 apps so unless you have the unix internet explorer, too
bad)
In message ,
 Lloyd Wood typed:

 >>On Wed, 30 May 2001, Fred Baker wrote:
 >>
 >>> Greg:
 >>> 
 >>> The URLs in this note were all sent with what the ETSI machine considered 
 >>> to be 'malformed syntax'. Could you resend the correct URLs?
 >>
 >>Just put all the parts together, removing unencoded
 >>spaces; the reason for the breaks after the hyphens seems
 >>obvious enough, but I'm at a loss to explain others. Here we go:
 >>
 >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc
 >>
 >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip
 >>
 >>http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON
 >>
 >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt
 >>
 >>So http://docbox.etsi.org/ is passworded but docs can be retrieved by
 >>advertised public direct url? Bizarre.
 >>
 >>L.
 >>
 >>PGP
 >>
 >>
 >>
 >>
 >>
 >>
 >>

 cheers

   jon



From owner-megaco@fore.com  Thu May 31 13:26:45 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03091
	for ; Thu, 31 May 2001 13:26:44 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05585;
	Thu, 31 May 2001 13:14:39 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA07195
	for megaco-list; Thu, 31 May 2001 13:13:21 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07176
	for ; Thu, 31 May 2001 13:13:19 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05430
	for ; Thu, 31 May 2001 13:13:16 -0400 (EDT)
Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4VHBBU27133;
	Thu, 31 May 2001 10:11:12 -0700 (PDT)
Message-Id: <5.1.0.14.2.20010531095817.04c50ea8@mira-sjcm-2.cisco.com>
X-Sender: fred@mira-sjcm-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 31 May 2001 10:09:10 -0700
To: "Roy, Radhika R, ALCTA" 
From: Fred Baker 
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM
  FOR E ND-TO-END QOS SERVICE CONTROL
Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu,
        mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com,
        issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com,
        sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp,
        rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
        ITU-SG16@mailbag.cps.INTEL.COM
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote:
 >All applications (e.g., H.323, SIP) uses signaling messages
 >among its functional entities (e.g., terminal, agents,
 >gatekeepers, proxies, gateways) for communications.

I'm not sure we're on the same planet. Please help me out here.

I can think of a few applications that have agents, gatekeepers, proxies, 
and gateways, mostly resulting from the imposition of firewalls or 
authentication systems, or from legacy applications like imitating the 
telephone system in a data network. The only one that *requires* any kind 
of gateway, to my knowledge, is H.323 teleconferencing, which represents a 
paltry fraction of traffic according to most current measurements. Anything 
else (75% of Internet traffic is http or FTP, most of the rest is mail, on 
private LANs applications like NFS are pretty common, and even SIP can be 
done without a gateway between consenting systems) could be hooked up in 
separate systems on a LAN and made to work without any such signalling at all.

Could you be more specific on what QoS signalling is required by the world 
wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, 
calendaring, and so on? If not, could you be more specific about what "all" 
applications you have in mind?

And could you be more specific about what issues this proposal is 
addressing that have not already been addressed in de facto standards and 
deployed in operational systems? It would be very nice to understand what 
you are preparing to ask vendors to do, and whether operators are 
interested in deploying them.



From owner-megaco@fore.com  Thu May 31 14:03:13 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04195
	for ; Thu, 31 May 2001 14:03:12 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08058;
	Thu, 31 May 2001 13:42:37 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA14849
	for megaco-list; Thu, 31 May 2001 13:41:33 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA14834
	for ; Thu, 31 May 2001 13:41:31 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 31 May 2001 13:41:30 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF044654D4@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: diffserv@ietf.org, iptel@lists.bell-labs.com, megaco@fore.com,
        sip@lists.bell-labs.com, tsvwg@ietf.org
Cc: gratta@lucent.com, ITU-SG16@mailbag.cps.INTEL.COM
Subject: RE: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL M
	ECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
Date: Thu, 31 May 2001 13:41:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Folks, this thread may or may not be the start of something good or
evil, but it is going out to too many lists!

Please, as of now, let's move it to one, and only one list.
I nominate tsvwg.  If you are replying to any message on this
thread, PLEASE edit the to/cc to limit it to tsvwg@ietf.org

Brian

> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com]
> Sent: Thursday, May 31, 2001 1:09 PM
> To: Roy, Radhika R, ALCTA
> Cc: Bob Braden; gratta@lucent.com; sob@harvard.edu; mankin@isi.edu;
> diffserv@ietf.org; iptel@lists.bell-labs.com; 
> issll@mercury.lcs.mit.edu;
> megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org;
> tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com;
> tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; 
> ITU-SG16@mailbag.cps.INTEL.COM
> Subject: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL
> MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
> 
> 
> At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote:
>  >All applications (e.g., H.323, SIP) uses signaling messages
>  >among its functional entities (e.g., terminal, agents,
>  >gatekeepers, proxies, gateways) for communications.
> 
> I'm not sure we're on the same planet. Please help me out here.
> 
> I can think of a few applications that have agents, 
> gatekeepers, proxies, 
> and gateways, mostly resulting from the imposition of firewalls or 
> authentication systems, or from legacy applications like 
> imitating the 
> telephone system in a data network. The only one that 
> *requires* any kind 
> of gateway, to my knowledge, is H.323 teleconferencing, which 
> represents a 
> paltry fraction of traffic according to most current 
> measurements. Anything 
> else (75% of Internet traffic is http or FTP, most of the 
> rest is mail, on 
> private LANs applications like NFS are pretty common, and 
> even SIP can be 
> done without a gateway between consenting systems) could be 
> hooked up in 
> separate systems on a LAN and made to work without any such 
> signalling at all.
> 
> Could you be more specific on what QoS signalling is required 
> by the world 
> wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, 
> calendaring, and so on? If not, could you be more specific 
> about what "all" 
> applications you have in mind?
> 
> And could you be more specific about what issues this proposal is 
> addressing that have not already been addressed in de facto 
> standards and 
> deployed in operational systems? It would be very nice to 
> understand what 
> you are preparing to ask vendors to do, and whether operators are 
> interested in deploying them.
> 
> 
> 
> _______________________________________________
> Sipping mailing list
> Sipping@ietf.org
> http://www.ietf.org/mailman/listinfo/sipping
> 


From owner-megaco@fore.com  Thu May 31 14:08:12 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04328
	for ; Thu, 31 May 2001 14:08:12 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA09309;
	Thu, 31 May 2001 13:54:55 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA18181
	for megaco-list; Thu, 31 May 2001 13:53:50 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA18177
	for ; Thu, 31 May 2001 13:53:49 -0400 (EDT)
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA09148
	for ; Thu, 31 May 2001 13:53:46 -0400 (EDT)
Received: from gab200r1.ems.att.com ([135.37.94.32])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VHpPC24217;
	Thu, 31 May 2001 13:51:25 -0400 (EDT)
Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id NAA00157; Thu, 31 May 2001 13:51:00 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 31 May 2001 13:51:22 -0400
Message-ID: 
From: "Roy, Radhika R, ALCTA" 
To: Fred Baker 
Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu,
        mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com,
        issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com,
        sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp,
        rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
        ITU-SG16@mailbag.cps.INTEL.COM
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
	 ND-TO-END QOS SERVICE CONTROL
Date: Thu, 31 May 2001 13:51:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Hi, Baker:

It appears that a good amount discussion can be started to answer your
questions (what has being discussed for the last couple of years in the
ITU-T and TIPHON in particular). I am not trying to do so. Let me answer
your questions summarizing the key points as follows:

1. Broadly, all applications can be considered in two categories: a.
Real-time (e.g., audio, video [of H.323/SIP]) and b. Non-Real-time (e.g.,
data applications like file transfer, WWW, Mail, etc. - can a part of
H.323/SIP). 

The performance parameters of both real-time (audio, video) and
non-real-time (data) traffic can be abstracted in an universal way that can
be used by all applications (e.g., H.323, SIP, WWW, mail, etc). 

However, the signaling messages used by each application are
application-specific although the QOS parameters used by all of them still
remain same (e.g., H.323 might use RAS/Q.931/Annex-G/H.245 signaling
messages, SIP might use SDP). 

The QOS signaling messages that use QOS parameters can be termed as the
application layer QOS signaling messages and are sent on end-to-end basis
and the values of those QOS parameters do not change no matter what may be
the underlying transport networks (e.g., IP, ATM).

2. The network layer QOS signaling messages carried over the network may not
be end-to-end significance. For example, an end-to-end path of an IP network
may consist of RSVP, DiffServ, MPLS, and RSVP. So, the network layer QOS
parameters may get translated between the source-destination path and may
not remain the same what has been negotiated on end-to-end basis in the
application layer (item 1).

The problems that are being addressed are as follows:

A. How to develop the end-to-end QOS signaling mechanisms in the application
layer

B. How to relate the application layer QOS signaling to the network layer
QOS signaling (e.g., RSVP, DifServ, MPLS, etc.) so that one-to-one
consistency remain between the application and network layer QOS parameters.

Hope this may clarify some of your questions.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com]
Sent: Thursday, May 31, 2001 1:09 PM
To: Roy, Radhika R, ALCTA
Cc: Bob Braden; gratta@lucent.com; sob@harvard.edu; mankin@isi.edu;
diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu;
megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org;
tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com;
tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; ITU-SG16@mailbag.cps.INTEL.COM
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR
E ND-TO-END QOS SERVICE CONTROL


At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote:
 >All applications (e.g., H.323, SIP) uses signaling messages
 >among its functional entities (e.g., terminal, agents,
 >gatekeepers, proxies, gateways) for communications.

I'm not sure we're on the same planet. Please help me out here.

I can think of a few applications that have agents, gatekeepers, proxies, 
and gateways, mostly resulting from the imposition of firewalls or 
authentication systems, or from legacy applications like imitating the 
telephone system in a data network. The only one that *requires* any kind 
of gateway, to my knowledge, is H.323 teleconferencing, which represents a 
paltry fraction of traffic according to most current measurements. Anything 
else (75% of Internet traffic is http or FTP, most of the rest is mail, on 
private LANs applications like NFS are pretty common, and even SIP can be 
done without a gateway between consenting systems) could be hooked up in 
separate systems on a LAN and made to work without any such signalling at
all.

Could you be more specific on what QoS signalling is required by the world 
wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, 
calendaring, and so on? If not, could you be more specific about what "all" 
applications you have in mind?

And could you be more specific about what issues this proposal is 
addressing that have not already been addressed in de facto standards and 
deployed in operational systems? It would be very nice to understand what 
you are preparing to ask vendors to do, and whether operators are 
interested in deploying them.


From owner-megaco@fore.com  Thu May 31 15:09:07 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06414
	for ; Thu, 31 May 2001 15:09:07 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA14764;
	Thu, 31 May 2001 15:01:27 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA04494
	for megaco-list; Thu, 31 May 2001 14:56:53 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA04465
	for ; Thu, 31 May 2001 14:56:49 -0400 (EDT)
Received: from ertpg15e1.nortelnetworks.com (ertpg15e1.nortelnetworks.com [47.234.0.36])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14340
	for ; Thu, 31 May 2001 14:56:45 -0400 (EDT)
Received: from zrtps06s.us.nortel.com (zrtps06s.us.nortel.com [47.140.48.50])
	by ertpg15e1.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f4VIuUn07127
	for ; Thu, 31 May 2001 14:56:31 -0400 (EDT)
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com;
          Thu, 31 May 2001 14:57:26 -0400
Received: from zrtpd0jn.us.nortel.com ([47.140.202.35]) 
          by zrtpd004.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id LDQVWNA8; Thu, 31 May 2001 14:56:16 -0400
Received: from americasm01.nt.com (kboyle.us.nortel.com [47.142.150.95]) 
          by zrtpd0jn.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id J5XGQLTW; Thu, 31 May 2001 14:56:17 -0400
Message-ID: <3B169395.65E64E27@americasm01.nt.com>
Date: Thu, 31 May 2001 14:55:18 -0400
X-Sybari-Space: 00000000 00000000 00000000
From: "Kevin Boyle" 
Organization: Nortel Networks
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" 
CC: "'knayar@hss.hns.com'" , megaco@fore.com
Subject: Re: Network Package
References: <4FBEA8857476D311A03300204840E1CF044654D2@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: 
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

I am not sure I see what is gained by the hiding of base packages... they're
not really hidden it at all, they've just had their addressing scheme
changed.  This "hiding" lends itself to misuse in situations like the
statistics reporting concern expressed earlier in the thread, when that
could be prevented by just addressing the package items by their base
address.

I guess I'm looking for some usecases that are specifically addressed by the
ability to "hide" base packages.  Do any come to mind?

Kevin

"Rosen, Brian" wrote:

> I prefer the current design, where the extension inherits the
> properties/events/signals/statistics from the base.
> I think there are lots of cases where it's better to NOT expose
> the base package.  Your proposal would disallow that possibility.
> I think the duplication is not much of an issue.
>
> Brian
>
> > -----Original Message-----
> > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
> > Sent: Thursday, May 31, 2001 11:09 AM
> > To: Rosen, Brian
> > Cc: 'knayar@hss.hns.com'; megaco@fore.com
> > Subject: Re: Network Package
> >
> >
> > All,
> >
> > It is exactly these kinds of conundrums that prompted me to
> > post some months
> > ago about the ability to address signals/etc. by the
> > extension package ID.
> > Why is this necessary?  If you support an extension, then, by
> > definition,
> > you support the base package.  So why not mandate that
> > signals/etc. from the
> > base package be addressed by the base package?  This prevents
> > such silliness
> > as getting multiple copies of a statistic (a/t1, b/t1).  Then
> > the only time
> > there would be an overlap would be when there is a functional
> > extension of
> > the signal/etc. by the extension, such as adding new values for a
> > parameter.  Then, if you wish to take advantage of the new
> > values, it would
> > be addressed as the extension package.
> >
> > To illustrate:
> >
> > Package a: e1, e2{parm1=1,2,3}, s1, p1, t1
> > Package b extends a: e2{parm1=1,2,3,4}, e3, s2, p2, t2
> >
> > These would then be addressed as:
> >
> > a/e1
> > a/e2{parm1} (in this case, parm1 may only have value 1, 2, or 3)
> > b/e2{parm1} (in this case, parm1 may have value 1, 2, 3, or 4)
> > b/e3
> > a/s1
> > b/s2
> > a/p1
> > b/p2
> > a/t1
> > b/t2
> >
> > This would reduce a lot of these redundancy problems when
> > talking about
> > package extensions, and, it seems to me, is a very concise
> > way of handling
> > extensions without having to "hide" packages in the MG.  Now,
> > this certainly
> > does not handle multiple copies of the same event, but that
> > would qualify
> > as, as Brian puts it, a "stupid program".
> >
> > That's my two cents worth, anyway...
> > Kevin
> >

[snip]



From owner-megaco@fore.com  Thu May 31 16:38:31 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07755
	for ; Thu, 31 May 2001 16:38:31 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA21536;
	Thu, 31 May 2001 16:25:21 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA22460
	for megaco-list; Thu, 31 May 2001 16:19:25 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA22430
	for ; Thu, 31 May 2001 16:19:20 -0400 (EDT)
Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA20772
	for ; Thu, 31 May 2001 16:19:00 -0400 (EDT)
Received: from mailhub.ind.alcatel.com (mailhub [198.206.181.70])
	by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with ESMTP id NAA09972
	for ; Thu, 31 May 2001 13:18:49 -0700 (PDT)
X-Origination-Site: 
Received: from newman.xylan.com (localhost [127.0.0.1])
	by mailhub.ind.alcatel.com (8.9.3+Sun/8.9.3/(mailhub 3.2.4 [HUB])) with ESMTP id NAA06129
	for ; Thu, 31 May 2001 13:18:34 -0700 (PDT)
X-InterScan: Passed
Received: from ind.alcatel.com ([10.193.100.186]) by
          newman.xylan.com (Netscape Messaging Server 4.15) with ESMTP id
          GE7V2Y00.NFY for ; Thu, 31 May 2001 13:18:34 -0700 
Message-ID: <3B16A663.DF1B8D22@ind.alcatel.com>
Date: Thu, 31 May 2001 13:15:31 -0700
From: Isabelle Cnudde 
Organization: Alcatel
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "megaco megaco" 
Subject: [Fwd: VISAS call successfull in Telefonica Chile Trial (Alcatel 
 SoftSwitch).]
Content-Type: multipart/mixed;
 boundary="------------A1DC8C3D21EAA95E5AF6127A"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

This is a multi-part message in MIME format.
--------------A1DC8C3D21EAA95E5AF6127A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Some good news about our Visas in Latin America...

Isabelle
-- 
Isabelle Cnudde          -----------------     NGN - media gateway
tel: +1 408 957 6234    |  A L C A T E L  |    720 South Milpitas Blvd
fax: +1 408 941 1818     -----------------     Milpitas, CA 95035
mailto:Isabelle.Cnudde@ind.alcatel.com         USA
--------------A1DC8C3D21EAA95E5AF6127A
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: 
Received: from halfaro ([143.209.108.181]) by newman.xylan.com
          (Netscape Messaging Server 4.15) with SMTP id GE7QOL00.QBX; Thu,
          31 May 2001 11:43:33 -0700 
Reply-To: 
From: "Heber Alfaro" 
To: "Lieve Roseleth" ,
	 "Isabelle Cnudde" ,
	 "Karl Triebes" ,
	 "Manuela Simoes" 
Cc: "Heber Alfaro" ,
	 "Isaac Moreno" ,
	 "Nitin Jain" ,
	 "PV Venus" 
Subject: VISAS call successfull in Telefonica Chile Trial (Alcatel SoftSwitch).
Date: Thu, 31 May 2001 11:39:15 -0700
Message-ID: <005801c0ea00$febfdbe0$b56cd18f@sv.alcatel.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mozilla-Status2: 00000000
Content-Transfer-Encoding: 7bit

Hello All.

I have received news from Carlos Gonzalez (our technical support in the
trial for Telefonica Chile), saying that
they have finish the installation, and they have done the first call
successfull  between the Alcatel SoftSwitch and the
VISAS Gateways operating with this parameters:

Megaco V.1.0
Megaco TCP
G.711 codec
Standard Voice quality parameters.

He also told me that Lucent is facing problems to setup all their gear , and
now we were ready to
interop with them

this is a good news for all of us in PV-Venus, I'd like to thank Carlos and
Isaac for their job done here and
at Chile to make sure the VISAS GW works fine according to the test
requirements from TELEFONICA Chile.


Best Regards


--------------A1DC8C3D21EAA95E5AF6127A--



From owner-megaco@fore.com  Thu May 31 16:39:27 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07768
	for ; Thu, 31 May 2001 16:39:26 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA20892;
	Thu, 31 May 2001 16:20:23 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA20711
	for megaco-list; Thu, 31 May 2001 16:12:38 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA20695
	for ; Thu, 31 May 2001 16:12:35 -0400 (EDT)
Received: from Mitel.COM ([216.191.234.101])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA20210
	for ; Thu, 31 May 2001 16:12:30 -0400 (EDT)
Received: from rndex50.software.mitel.com (rndex50 [134.199.17.160]) 
	by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id QAA22791;
	Thu, 31 May 2001 16:10:57 -0400 (EDT)
Received: by rndex50.kanata.mitel.com with Internet Mail Service (5.5.2448.0)
	id ; Thu, 31 May 2001 16:11:16 -0400
Message-ID: <9D6A470BD38ED311908000805F65B4EC0555433A@rndex50.kanata.mitel.com>
From: "Blatherwick, Peter" 
To: "'knayar@hss.hns.com'" 
Cc: megaco@fore.com
Subject: RE: Network Package
Date: Thu, 31 May 2001 16:11:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk

Re below, NO, TDMC does not need to specify anything new, its a r/w integer value now.  We cannot override the values type.  TDMC would merely return 0 when read, fail with "invalid parameter" if MGC (foolishly) tried to set it to anything other than 0.  Latter action is perfectly valid for any package extended from NT, since clearly you can't set JIT to an arbitrarily large value on *any* MG.  

As previously stated, I disagree, the protocol does not need to be changed for this issue.  

-- Peter

-----Original Message-----
From: knayar@hss.hns.com [mailto:knayar@hss.hns.com]
Sent: May 31, 2001 08:09
To: Blatherwick, Peter
Cc: 'Michael Brown'; megaco@fore.com
Subject: RE: Network Package




Hi Peter

A bit late in my response....
But, I agree with your suggestion of maxJitterBuf value to be 0 for TDMC
package.
If we look at the protocol document
"12.1.1   Package
*  Extends (Optional): A package may extend an existing package. The
      version of the original package must be specified. When a package
      extends another package it shall only add additional Properties,
      Events, Signals, Statistics and new possible values for an
      existing parameter described in the original package."

Can we define "new possible value" for maxJitterBuffer in TDMC package as 0.
We definitely, need to change the protocol document...but we can save on
addition/ deletion of properties...as discussed earlier.

Thanks,

-Kapil Nayar
Hughes Software Systems






"Blatherwick, Peter"  on 05/31/2001 02:44:28 AM

To:   "'Michael Brown'" , megaco@fore.com
cc:    (bcc: Kapil Nayar/HSS)

Subject:  RE: Network Package




Basically, I agree with Mike's statements.  See a bit more below.  This is
getting long, so I'll shut up (for now)...
-- Peter

-----Original Message-----
From: Michael Brown [mailto:C.Michael.Brown@nortelnetworks.com]
Sent: May 30, 2001 14:52
To: megaco@fore.com
Subject: RE: Network Package


Comments inline.

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
Sent: Wednesday, May 30, 2001 10:58 AM
To: megaco@fore.com
Subject: Re: Network Package



See comment below:


IS this clearly stated somewhere?
This could be a nightmare for MGC to receive the same statistics value via 2
different
parameter.  Talk about the overhead of parsing these text strings.



[PB]  I believe this logic was given in the Implementors' Guide.  If it remains
unclear, please let us all know what needs to be clarified.


  Are you referring to the following in IGv6  Section 12.1?

When packages are extended, the properties, events, signals and statistics
defined in the base package can be referred to using either the extended package
name.  For example, if Package A defines event e1, and Package B extends Package
A, then B/e1 is an event for a termination implementing Package B. By
definition, the MG MUST also implement the base Package, but it optional to
publish the base package as an allowed interface.  If it does publish A, then A
would be reported on the Package Descriptor in AuditValue as well as B, and
event A/e1 would be available on a termination.  If the MG does not publish A,
then only B/e1 would be available.  If published through AuditValue, A/e1 and
B/e1 are the same event.
For the purpose of improved interoperability and backward compatibility, the an
MG MAY publish all Packages supported by its Terminations, including base
Packages from which extended Packages are derived.  An exception to this is in
cases where the base packages are expressly designed to be extended by others,
not directly controlled, and may not have any function on their own or be
nonsensical on their own, in which case the MG SHOULD NOT publish the base
Packages.


  I don't see anything remotely stating what we are discussing about
statistics and
               event reporting.   Specifically that one can get duplicate
statistics.

[MB] I would disagree as I think the IG statements are definitely related
although perhaps not complete. There are two different issues here. First is the
case where the MGC is specifically asking for certain statistics. This is
covered by the spec along the lines of the earlier statements that the MGC is in
control and if it asks for something stupid, well, the MG should do it.

The second issue is a bit more problematic (the Subtract request resulting in
reporting of statistics); however, the behavior of the MG in reporting
statistics is based on which packages are "published" by the MG. If the MG
implementation publishes both a base package and a package that extends that
base package, then the default behavior would be to report both statistics. I
don't mean to say that it is a useful thing to do... just that it is what will
happen. The point is that IMO publishing both the packages is a poor
implementation choice on the part of the MG. So, this gets to your question...
do we need to document that this is a poor implementation choice? I'm not really
convinced that it is necessary.

[PB] Agree both cases are actually something that should not happen anyway, at
least for any reasonable circumstance I can see.  MG should not publish
redundant Packages (only "leaf nodes" in general), but is free to do so if it
wants.  One case where MG implementation might do this is to allow MGCs to use
more advanced (extended) packages recently defined, while still allowing for
less advanced ones (base packages) to be used by MGCs that don't know the
extended ones.  In that case MGC would need to explicitly ask for which one it
wants (as it normally would).  Other case could be where MGC sets Events=ALL, in
which case the MGC should be ready to handle the flood, but I would not see this
being done in a system where the flood would could actually be a problem (i.e
inside small networks only, or where Package sets are know in advance not to be
redundant or otherwise cause excess loads).

[PB] Yes, there would be double the overhead, but that's not really different
overhead from MGC asking for 2 sets of statistics from different sources.


  I am using the case of Subtract Request which does not specify any
parameter.
              Thus MG will reply w/all statistics in which case MGC will receive
duplicate
              statistics.
[MB] Issue #2 above.


 Can someone answer the question what does it mean for tdmc package to
extend nt package property of "Maximum Jitter Buffer"?

[PB] My opinion, not as author of the tdmc Package,  is the property should
simply always be 0.  There is no jitter buffer.  I agree this is not a very
interesting value, so if the MGC is not interested it should not ask, and if its
software is designed to handle the general case of any package extending from
nt, it better be able to handle 0 as the answer.


  So in general if a package that extends another package and there is some
parameters
               that might not apply, we do not flag it as an error but assume
some default value
               and treat it as a nop?

              So does NT package qualify as a "base package" based on the
definition of what
              a "base package" is as quoted above -


An exception to this is in cases where the base packages are expressly designed
to be extended by others, not directly controlled, and may not have any function
on their own or be nonsensical on their own, in which case the MG SHOULD NOT
publish the base Packages.

Should something be added to each package to define whether it is a "base
package"
which meant that it can't be used on its own?


NT package is one example to me since each termination that realizes this
package must
belong to some network type which should have its own network-type package (RTP,
TDM, ATM, etc).


[MB]  The fact is that the Jitter Buffer property WAS supposed to be moved from
the Network to the RTP package. Initially, there was only a network package and
it had all of the properties that now reside in RTP package. After discussion
about support of other network types, it was agreed that the approach that you
describe in the previous paragraph was the right one and the RTP package was
created. I don't remember why the Jitter Buffer parameter didn't get moved, but
this was pointed out at that time and the intent was that it would be moved to
the RTP package before publication of the version 1 spec. Unfortunately, the
change didn't get made and was overlooked at the time of determination/Last
Call. So, there we have it... The Network package was supposed to be a generic
base package, but it isn't exactly. As far as what should be done,
unfortunately, based on the existing rules for versioning (which I think we
should revisit), we aren't able to simply remove the property!
 f!
!
rom the Network package in a new version. So, I think that the right thing is to
include some text in the Network Package to deprecate the use of the Jitter
Buffer property there (I don't believe that this would qualify as a new verion
of the package) and upversion the RTP package and add the property. (Just by the
way, this upversioning of the package would, I think, not necessarily have to
wait for Version 2 of the H.248 spec since versioning of a package is not
necessarily tied to a particular version of the base protocol.)

[MB] I think that your suggestion that in general we should handle this type of
error as a NOP really isn't a good rule of thumb as a "fix". It is OK as a
workaround, but the package should ultimately be fixed (or done right to begin
with :-) ).



 [PB] Disagree with "NOP".  Meaning of NOP to me is the requesting end (MGC)
will see nothing come back, and could get confused as a result.  I prefer to
return a value of some kind, even if its non-interesting (like 0 jitter buffer
size for example).  Again, if you know its a meaningless value, then don't ask
for it in the first place.


 [MB] One other thing was about whether we should add something stating that a
package is a base package. I'm not adamantly opposed to the idea, but I really
don't think it's necessary.

[PB] Personally I think its a REAL GOOD IDEA (note alternate IETF key words ;-)
for packages intentionally designed to be base packages *only* to say so.
There are several example of this in the existing Annexes, used where the
Package is not meant to be exposed, has no function on its own, or is
non-sensible on its own.  (This is sorta like virtual classes in OO world.)

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****








From owner-megaco@fore.com  Thu May 31 21:50:42 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12574
	for ; Thu, 31 May 2001 21:50:42 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA04403;
	Thu, 31 May 2001 21:42:52 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA29683
	for megaco-list; Thu, 31 May 2001 21:34:53 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA29677
	for ; Thu, 31 May 2001 21:34:51 -0400 (EDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA04167
	for ; Thu, 31 May 2001 21:34:40 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA28679;
	Fri, 1 Jun 2001 11:32:46 +1000 (EST)
Received: from ericsson.com ([130.100.249.223])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA20182;
	Fri, 1 Jun 2001 11:33:26 +1000 (EST)
Message-ID: <3B168A5E.C71F6FA2@ericsson.com>
Date: Fri, 01 Jun 2001 04:15:58 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom-PT Taylor 
CC: "'Rosen, Brian'" ,
        "'Steven Weisz'" ,
        "Megaco Mailing List (E-mail)" 
Subject: Re: ABNF Question: digit maps embedded in events
References: <28560036253BD41191A10000F8BCBD110250CC06@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Just in time. I'll add it to the implementors' guide.

Christian

Tom-PT Taylor wrote:
> 
> Yes, and I suspect I'm the guilty typist.
> 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > Sent: Wednesday, May 30, 2001 3:44 PM
> > To: 'Steven Weisz'; Megaco Mailing List (E-mail)
> > Cc: Taylor, Tom-PT [NORSE:B881:EXCH]
> > Subject: RE: ABNF Question: digit maps embedded in events
> >
> >
> > I usually defer to Tom on any digitMap questions.
> > I can't tell you how many hours I (and several others
> > including Abdullah Rayhan) spent pouring over the
> > ABNF to ferret out such problems.
> >
> > Yes, I agree, it should be
> > digitMap={...
> > and not
> > digitMap{...
> >
> > I think this qualifies as a typo and deserves an IG entry.
> > Tom, do you agree?
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Steven Weisz [mailto:sweisz@mediatrix.com]
> > > Sent: Wednesday, May 30, 2001 3:08 PM
> > > To: Megaco Mailing List (E-mail)
> > > Subject: ABNF Question: digit maps embedded in events
> > >
> > >
> > > Hi List,
> > >
> > > I asked this question a few weeks ago and still have not
> > > found an answer.
> > > Does anyone have an opinion?
> > >
> > > It is a quick question concerning a digit map embedded in a
> > > requested event.
> > > Specifically, if you look at the ABNF the embedded digit map
> > > is defined as
> > >
> > > eventDM = DigitMapToken (( EQUAL digitMapName ) / (LBRKT
> > digitMapValue
> > > RBRKT))
> > >
> > > and a digit map descriptor is defined as:
> > >
> > > digitMapDescriptor = DigitMapToken EQUAL (( LBRKT
> > > digitMapValue RBRKT ) /
> > >                      ( digitMapName [LBRKT digitMapValue RBRKT] ))
> 
> > >
> > > It obvious that they are very similar, as I believe was
> > > intended but there
> > > is one thing that is bothering me in eventDM. That is it
> > > seems to me that
> > > the EQUAL should be right after DigitMapToken as is the case in
> > > digitMapDescriptor. So we would instead have:
> > >
> > > eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT
> > digitMapValue
> > > RBRKT))
> > >
> > > Does this make sense?
> > >
> > > Thanks,
> > >
> > > Steve
> > >
> >




From owner-megaco@fore.com  Thu May 31 22:03:43 2001
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12750
	for ; Thu, 31 May 2001 22:03:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA04900;
	Thu, 31 May 2001 21:54:22 -0400 (EDT)
Received: (from majordom@localhost)
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA00496
	for megaco-list; Thu, 31 May 2001 21:47:05 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA00491
	for ; Thu, 31 May 2001 21:47:03 -0400 (EDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA04579
	for ; Thu, 31 May 2001 21:46:54 -0400 (EDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA00218;
	Fri, 1 Jun 2001 11:44:37 +1000 (EST)
Received: from ericsson.com ([130.100.249.223])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA22658;
	Fri, 1 Jun 2001 11:45:13 +1000 (EST)
Message-ID: <3B16F1AE.42A045C5@ericsson.com>
Date: Fri, 01 Jun 2001 11:36:46 +1000
From: Christian Groves 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" 
CC: "'knayar@hss.hns.com'" , megaco@fore.com
Subject: Re: Network Package
References: <4FBEA8857476D311A03300204840E1CF044654C5@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-megaco@pit.comms.marconi.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

G'Day Brian,

I fully agree. The protocol can't police all weird behaviour from the
MGC.

Cheers, Christian

"Rosen, Brian" wrote:
> 
> Like any protocol, you can misuse it.  The design of the protocol
> can discourage misuse, but it can never eliminate it.  There is
> nothing that prevents you from, for example, setting an event
> descriptor that has the SAME event listed twice.
> 
> What should you do?  It's not an error in the sense that the
> protocol declares it to be illegal.
> 
> The results are probably unpredictable.  That is okay.
> We can't realistically fix stupid programs.  We can specify
> what happens in realistic situations.  There are reasonable
> scenarios where an MG may wish to expose the underlying package,
> but most don't make any sense.  If an MGC is stupid enough to
> specify both events on the same termination, what it gets may be
> a surprise.  I won't stay up nights worrying about it.
> 
> Brian
> 
> > -----Original Message-----
> > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com]
> > Sent: Thursday, May 31, 2001 7:55 AM
> > To: megaco@fore.com
> > Subject: RE: Network Package
> >
> >
> >
> >
> > Hi
> >
> > Apart from the IG not mentioning about the "double notify",
> > we have another
> > issue....
> > In case both the events in the ED have an embedded event
> > descriptor(EED), which
> > EED should be activated.
> > Is it decided based upon the sequence of events in the ED ??
> > ...if it is so we donot guarantee "double notify"...in case
> > of EEDs...is it
> > right.
> >
> > Would it not be appropriate to restrict the definition of
> > A/E1 and B/E1 (in case
> > B extends a package A with event E1), to mean the same event...
> >
> > How about restricting MG as well as MGC to expose only "leaf"
> > packages (extended
> > packages) but to be lenient enough to accept both base as
> > well as extended
> > package definitions....this would take care of any
> > interoperability and
> > compatibilty issues too.
> > Hence, MGC would send only A/E1 in ED but can accept A/E1 and
> > B/E1 in observed
> > ED.
> > and MG shall send only A/E1 in observed ED (or A in Audit
> > response) and accept
> > B/E1 in ED etc.
> > Any comments..
> >
> > -Kapil Nayar
> > Hughes Software Systems
> >
> >
> >
> > HI Peter/All,
> >
> > Might be an implementation issue but let me put the same
> > query with some
> > sample code.
> >
> > The Section 7.1.9 Events Descriptor 4th paragraph,
> > "When an event is processed against the contents of an active Events
> >    descriptor and found to be present in that descriptor
> > ("recognized"),
> >    the default action of the MG is to send a Notify command
> > to the MG."
> >
> > After interpretation, the statement above was implemented as follows
> >
> > ProcessDetectedEvent( Event detected is passed)
> > {
> >   if ( Events Descriptor is active)
> >   {
> >       for ( each event in the events descriptor )
> >       {
> >            if ( match Found)
> >            {
> >                  GenerateNotifyTowardsMGC ( event, timestamp,
> > RequestId,
> > etc...)
> >                  PostEventDetectionProcessing(Event Detected)
> >                  break;
> >            }
> >       }
> >   }
> >   else
> >      ProcessEventAccordingToEventsBufferDescriptor( Event detected is
> > passed)
> > }
> >
> > Its true that the IG mentions about package extension, but no
> > where (I mean
> > either in IG/protocol) its mentioned that if one event
> > recognition matches
> > two events in the Events Descriptor...(at First I wondered
> > how this was
> > possible...) there will be two Notify commands generated towards MGC.
> >
> > IMHO Unless explicitly mentioned about the multiple Notifies
> > for single
> > hardware event, the general interpretation of event matching
> > will be some
> > thing as shown above...which is actually not the intent.
> >
> > Regards
> > Madhubabu
> >
> >
> >
> >
> > -----Original Message-----
> > From: Blatherwick, Peter [mailto:Peter_Blatherwick@Mitel.COM]
> > Sent: Tuesday, May 29, 2001 10:05 PM
> > To: 'Madhu Babu Brahmanapally'; megaco@fore.com
> > Subject: RE: Network Package
> >
> >
> > Now I'm not so sure what you're getting at below -- what is
> > different from
> > previous examples.  I see the rules as completely general.
> > MG simply checks
> > for events to report (redundant or not, doesn't care or even
> > necessarily
> > know), in the order requested, and for each one follows the
> > buffering/reporting algorithm per current handling settings.
> > Perhaps a more
> > explicit example?
> >
> > Re the IG, I don't think it explicitly mentions "synonyms"
> > (nice term by the
> > way ;-), but does give clear guidance on what is considered
> > equivalent, how
> > the MG exposes its interfaces, and how the MGC specifies what
> > it wants.
> > Event reporting text in the core protocol document and/or IG
> > I personally
> > believe already are clear on how events are reported.  Since
> > we are not
> > talking about special cases, simply same handling for all
> > events requested
> > by MGC, I don't see that specific text is required.  My opinion.
> >
> > -- Peter
> >
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > Sent: May 29, 2001 21:44
> > To: 'Blatherwick, Peter'; 'Rosen, Brian'; 'Chuong Nguyen';
> > megaco@fore.com
> > Subject: RE: Network Package
> >
> >
> > HI Peter/All,
> >
> > I agree that the MG does whatever is said by the MGC. But, if
> > say Events
> > Descriptor is X,Y,Z and say X and Z means the same (Similar
> > to the A/T1 and
> > B/T1). Now the MG while reporting the event in the Notify
> > also has to check
> > events beyond match???? Is this fine???
> >
> > 1) Then this has to be true while buffering events in Events Buffer
> > according to Event Buffer descriptor and
> > 2) While processing of new events descriptor when Event
> > Buffer control is
> > lockstep.
> >
> > But I see no such statement in the Protocol Text. If the intention of
> > matching of event is to match all the "synonyms" of the
> > event. Then this
> > text needs to be specified in the IG at least to avoid any
> > misunderstandings.
> >
> > Regards
> > Madhubabu
> >
> >
> > -----Original Message-----
> > From: Blatherwick, Peter [mailto:Peter_Blatherwick@Mitel.COM]
> > Sent: Tuesday, May 29, 2001 9:22 PM
> > To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen';
> > megaco@fore.com
> > Subject: RE: Network Package
> >
> >
> > As in previous e-mail, just sent, I don't believe the below
> > error should
> > apply to the case of MGC requesting both A/T1 and B/T1.   MG is simply
> > responding to the request.   May be a better case for using
> > this if the
> > request is for A/T1 and A/T1, but I still don't think so.  MG
> > simply does as
> > its told.
> > -- Peter
> >
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > Sent: May 29, 2001 19:19
> > To: 'Rosen, Brian'; 'Chuong Nguyen'; megaco@fore.com
> > Subject: RE: Network Package
> >
> >
> > Brian/All,
> >
> > Sorry for wrong information in my earlier mail.... Error code "456 -
> > Parameter or Property appears twice in this Descriptor" is present for
> > avoiding multiple instances of properties/parameters. If A/T1
> > and B/T1 mean
> > the same doesn't this fall into the above error category.
> >
> > Regards
> > Madhubabu
> >
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> > Sent: Tuesday, May 29, 2001 5:47 PM
> > To: 'Chuong Nguyen'; megaco@fore.com
> > Subject: RE: Network Package
> >
> >
> > Well rtp/dur and nt/dur are "the same thing" in the sense
> > that the mean the
> > same
> > thing, but if you implement (expose) both packages, then they
> > are "separate"
> > statistics.  Using Events is perhaps easier to understand.
> > Suppose Package
> > A
> > implements event E1, and package B extends Package A, and a given
> > implementation
> > exposes both A and B, such that an audit of termination T1 returns
> > Packages{..A,B..}
> >
> > You can say Add=T1{Events=123{B/E1}}
> > or you can say
> > Add=T1{Events=123{A/T1}}
> > or even
> > Add=T1{Events=123{A/T1,B/T1}}
> >
> > In the latter, detection of the event would result in a
> > notify of both.
> >
> > Returning to statistics, the value would be the same, but
> > they are separate
> > statistics.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> > Sent: Tuesday, May 29, 2001 5:29 PM
> > To: megaco@fore.com
> > Subject: Re: Network Package
> >
> >
> > "Rosen, Brian" wrote:
> >
> > If you implement any part of a package, you implement all of
> > it.If a package
> > extends any part of a package, it extends all of it.
> >
> > What is not required is that if you implement a package that
> > extendsanother
> > package that you have to "expose" the underlying package.This
> > means that if
> > you implement rtp you don't have to expose nt.If you list nt
> > as one of the
> > packages in an audit, then you have toimplement nt/dur.
> >
> >
> >   I don't quite follow here.
> >                You seem to imply that nt/dur and rtp/dur are
> > 2 different
> > things.
> >                I thought both nt/dur and rtp/dur are the same
> > thing w/the
> > same value.
> >               If MG exposed nt, what should it return for
> > duration - nt/dur
> > or rtp/dur?
> >
> >
> > Do you know the intend of tdmc/os and tdmc/or?
> > I thought the same as Madhubabu about how they are calculated.
> >
> >
> >
> >
> >
> >
> > Brian
> >
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [ mailto:madhubabu@kenetec.com
> >  ]
> > Sent: Tuesday, May 29, 2001 5:15 PM
> > To: 'Chuong Nguyen'
> > Cc: megaco@fore.com
> > Subject: RE: Network Package
> > Hi chuong/all,IMO if PackageB extends PackageA and if one of the
> > statistic/property of Package A is not valid for termination realizing
> > packageB then there is no reason why PackageB extends PackageA. Then
> > PackageB shouldn't extend PackageA (just only to reuse few
> > properties/statistics) but should define the same properties
> > (Might be with
> > different IDs) in packageB. I think the extension of packages
> > is logical if
> > the newly defined package can inherit "all" the properties
> > already defined
> > in the base package and also define new properties. In your
> > example, I was
> > in the impression that "OS" and "OR" can be calculated as
> > "The number of
> > octet sent or received is equal to the duration of the Termination, in
> > seconds, multiplied by the sampling frequency,  8000 Hz.".
> > (Of course this
> > seems to be redundant info if the MGC is aware of the
> > sampling frequency).
> > Isn't this the intention?????-RegardsMadhubabu
> >
> > -----Original Message-----
> > From: owner-megaco@pit.comms.marconi.com
> >  mailto:owner-megaco@pit.comms.marconi.com
> >  ]On Behalf Of
> > Chuong Nguyen
> > Sent: Tuesday, May 29, 2001 4:38 PM
> > To: megaco@fore.com
> > Subject: Network Package
> > Hi All
> >
> >
> > Is it reasonable to assume that Network Package StatisticsID
> > will never be
> > used directly?
> > That is nt/dur, nt/os and nt/or will normally be rtp/dur,
> > rtp/os and rtp/or
> > respectiviely
> > since rtp package extends nt package.
> >
> >
> > I know that it is agreed that if a termination realizes rtp
> > package, it also
> > realizes nt package
> > and either nt/.. or rtp/.. are valid packageName.
> >
> >
> > But if we allow, nt/... instead of rtp/.., are we saying that if MGC
> > receives nt/.., it has to
> > know whether it is for rtp or tmcd termination by the terminationID?
> >
> >
> >
> > Furthermore, since tdmc package extends nt package, do "octet
> > sent" (OS) and
> > "octet
> > received" (OR) really apply to tdm termination?
> >
> >
> > Also what does it mean for a TDM termination to realize the
> > "NT" package
> > properties
> > of "Maximum Jitter Buffer"?
> >
> >
> > So a more general question, if a termination realizes a packageB that
> > extends
> > packageA and there are items in the packageA that does not
> > make sense to
> > the termination what should MG/MGC do.
> >
> >
> > Take the above as an example and assuming that it does not
> > make sense for
> > TDM
> > termination to have "OS" and "OR", what should MG return for
> > TDM termination
> > statistics if the termination realizes "TDMC" package?
> > Just "duration".
> >
> >
> > ---
> > Said it is valid to have "OS" and "OR" for TDM.
> > IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP
> > termination,
> > is it valid for MG to return nt/dur, nt/os and nt/or for the
> > TDM termination
> > and RTP
> > termination instead of tdmc/dur, ... vs rtp/dur ?
> >
> >
> > Thanks
> > Chuong
> >
> >
> >
> >
> > --
> >
> >   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
> >
> >   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
> >
> >   **** The opinions expressed are not those of Alcatel USA, Inc ****
> >
> >
> > --
> >
> >   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
> >
> >   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
> >
> >   **** The opinions expressed are not those of Alcatel USA, Inc ****
> >
> >
> >
> >