From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 08:04:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14698 for ; Tue, 1 Aug 2000 08:04:19 -0400 (EDT) Received: from standards (47.234.32.16:2407) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83C9B@standards.nortelnetworks.com>; Tue, 1 Aug 2000 7:52:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1462 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 07:52:37 -0400 Received: from qhars002.nortel.com (47.101.112.102:46620) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83C9A@standards.nortelnetworks.com>; Tue, 1 Aug 2000 7:52:37 -0400 Received: from zrtps06s.us.nortel.com (actually 47.140.48.50) by qhars002.nortel.com; Tue, 1 Aug 2000 13:03:32 +0100 Received: from zmers013 (actually zmers013.ca.nortel.com) by zrtps06s.us.nortel.com; Tue, 1 Aug 2000 08:01:19 -0400 Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by zmers013; Tue, 1 Aug 2000 08:01:07 -0400 Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA14057 for ; Tue, 1 Aug 2000 15:00:12 +0300 (IDT) Received: from tl100h0c.elex.co.il by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id PAA06369; Tue, 1 Aug 2000 15:00:11 +0300 (IDT) Received: from tmx100.elex.co.il (rakefet@localhost [127.0.0.1]) by tl100h0c.elex.co.il with ESMTP (8.8.6 (PHNE_14041)/8.7.3) id PAA05401 for ; Tue, 1 Aug 2000 15:00:10 +0300 (IDT) X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Message-ID: <3986BBC9.C4D7A2DE@tmx100.elex.co.il> Date: Tue, 1 Aug 2000 15:00:09 +0300 Reply-To: "Prozan, Rakefet" Sender: "Media Gateway Control (megaco)" From: "Prozan, Rakefet" Organization: Telrad Ltd. Subject: pathNAME,serviceChangeParm To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, Can someone clarify these two definitions in ABNF? 1)pathNAME is defined as follows: pathNAME = ["*"] NAME * ("/" /"*"/ ALPHA / DIGIT /"_" / "$" ) ["@" pathDomainName ] In the related comment it is written that pathNAME must not exceed 64 chars. But NAME and pathDomainName can be 64 chars each one .So,in theory the MGC could get a pathNAME with more than 64 chars. So, I think that either there should be a slash between NAME and pathDomainName (which means NAME or pathDomainName),or pathNAME should be defined by a new type of maximum 64 chars. 2)Above the definition of serviceChangeParm there's no comment of "at-most-once". Does it mean that serviceChangeDescriptor can consist of (for example) more than one serviceChangeMethod? many thanks in advance, -- Rakefet Prozan, Team Manager, S/W Development Nortel SBU Telrad Networks ESN 828-3043 Email:rakefet.prozan@telrad.co.il """ -(o o)- +---------------------------------oOO--(_)--OOo--------------+ .oooO Oooo. -------------------------------( )---------( )------------ \ ( ) / \_) (_/ Have fun !!! From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 08:38:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23951 for ; Tue, 1 Aug 2000 08:38:57 -0400 (EDT) Received: from standards (47.234.32.16:4168) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83CC5@standards.nortelnetworks.com>; Tue, 1 Aug 2000 8:27:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1517 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 08:27:16 -0400 Received: from mars.hss.co.in (202.54.26.197:55782) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83CC4@standards.nortelnetworks.com>; Tue, 1 Aug 2000 8:27:11 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e71CdHq04846 for ; Tue, 1 Aug 2000 18:09:23 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525692E.00447041 ; Tue, 1 Aug 2000 17:57:31 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525692E.00446C1C.00@sandesh.hss.hns.com> Date: Tue, 1 Aug 2000 17:56:23 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Package descriptor for ROOT. To: MEGACO@STANDARDS.NORTELNETWORKS.COM MGC if intends to "audit" packages supported by MG on ROOT, does the response from MG indicates the packages supported on ROOT termination or "UNION" of packages supported on different terminations in MG? -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 09:09:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00700 for ; Tue, 1 Aug 2000 09:09:19 -0400 (EDT) Received: from standards (47.234.32.16:1830) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83CDF@standards.nortelnetworks.com>; Tue, 1 Aug 2000 8:57:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1549 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 08:57:26 -0400 Received: from mars.hss.co.in (202.54.26.197:56143) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83CDE@standards.nortelnetworks.com>; Tue, 1 Aug 2000 8:57:04 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e71D8Wq05443 for ; Tue, 1 Aug 2000 18:38:54 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525692E.00472047 ; Tue, 1 Aug 2000 18:26:53 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525692E.00471F20.00@sandesh.hss.hns.com> Date: Tue, 1 Aug 2000 18:31:44 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Audit of all digit maps. To: MEGACO@STANDARDS.NORTELNETWORKS.COM In section 7.2.5, its mentioned that "DigitMap requested in an AuditValue command with TerminationID ALL returns all DigitMaps in the gateway". But in section 7.1.14.1 its mentioned that "DigitMaps defined on the root Termination are global and can .....". 1)How is this possible that the definition of digit map is on ROOT and auditing the same uses TerminationID ALL?? 2)Does ALL TerminationID includes ROOT too?? 3)Cant the digit maps be audited on ROOT? If TerminationID ALL can be used for digit map audit, the response should contain the terminationID ALL instead of specifying the terminations. But this is in conflict with Table in section 7.2.5 which says that when TerminationID is Wildcard(ALL if *),irrespective of ContextID, all possible matchings of TerminationID should be returned. -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 09:29:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05068 for ; Tue, 1 Aug 2000 09:29:16 -0400 (EDT) Received: from standards (47.234.32.16:1830) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83D01@standards.nortelnetworks.com>; Tue, 1 Aug 2000 9:17:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1591 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 09:17:36 -0400 Received: from mars.hss.co.in (202.54.26.197:56313) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83D00@standards.nortelnetworks.com>; Tue, 1 Aug 2000 9:17:16 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e71DSYq05696 for ; Tue, 1 Aug 2000 18:58:41 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525692E.00490F19 ; Tue, 1 Aug 2000 18:47:59 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525692E.00490D9D.00@sandesh.hss.hns.com> Date: Tue, 1 Aug 2000 18:52:49 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Returning of multiple digit maps from MG. To: MEGACO@STANDARDS.NORTELNETWORKS.COM If MGC audits the global digit maps the reply from MG should include all the defined digit maps. The production for auditReturnParameter lists any of the possible descriptors returned from MG. But occurence of these descriptors shall not occur more than once except for digit map descriptor. This is not specified anywhere that except for digitmap descriptor no other descriptor can occur more than once. This should be specified in grammar. -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 09:35:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06593 for ; Tue, 1 Aug 2000 09:35:34 -0400 (EDT) Received: from standards (47.234.32.16:1830) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83D28@standards.nortelnetworks.com>; Tue, 1 Aug 2000 9:23:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1640 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 09:23:56 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83D27@standards.nortelnetworks.com>; Tue, 1 Aug 2000 9:23:56 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA29332; Tue, 1 Aug 2000 09:35:08 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05501; Tue, 1 Aug 2000 09:35:08 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Aug 2000 09:34:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF67864B@whq-msgusr-02.fore.com> Date: Tue, 1 Aug 2000 09:35:07 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Returning of multiple digit maps from MG. X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Thank you for noticing this and we should include some text. The behavior is what you suggest - you get multiple digitmap descriptors. Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Tuesday, August 01, 2000 9:23 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Returning of multiple digit maps from MG. > > > If MGC audits the global digit maps the reply from MG should > include all the > defined digit maps. The production for auditReturnParameter > lists any of the > possible descriptors returned from MG. But occurence of these > descriptors shall > not occur more than once except for digit map descriptor. > This is not specified > anywhere that except for digitmap descriptor no other > descriptor can occur more > than once. This should be specified in grammar. > -Madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 09:42:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08216 for ; Tue, 1 Aug 2000 09:42:51 -0400 (EDT) Received: from standards (47.234.32.16:1830) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83D42@standards.nortelnetworks.com>; Tue, 1 Aug 2000 9:31:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1673 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 09:31:11 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83D41@standards.nortelnetworks.com>; Tue, 1 Aug 2000 9:31:11 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA00011; Tue, 1 Aug 2000 09:42:22 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA07237; Tue, 1 Aug 2000 09:42:23 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Aug 2000 09:42:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF67864E@whq-msgusr-02.fore.com> Date: Tue, 1 Aug 2000 09:42:22 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Package descriptor for ROOT. X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Audit of packages on Root returns all packages implemented on the union of all termination -- it is the way you find out what possible packages the MG implements. Possibly additional words needed. Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Tuesday, August 01, 2000 8:26 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Package descriptor for ROOT. > > > MGC if intends to "audit" packages supported by MG on ROOT, does > the response from MG indicates the packages supported on ROOT > termination or "UNION" of packages supported on different > terminations in MG? > -Madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 09:44:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08664 for ; Tue, 1 Aug 2000 09:44:54 -0400 (EDT) Received: from standards (47.234.32.16:1830) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83D53@standards.nortelnetworks.com>; Tue, 1 Aug 2000 9:32:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1695 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 09:32:04 -0400 Received: from mars.hss.co.in (202.54.26.197:56465) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83D4E@standards.nortelnetworks.com>; Tue, 1 Aug 2000 9:31:59 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e71Dhjq05903 for ; Tue, 1 Aug 2000 19:13:52 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525692E.004A7348 ; Tue, 1 Aug 2000 19:03:11 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525692E.004A7232.00@sandesh.hss.hns.com> Date: Tue, 1 Aug 2000 19:07:03 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Audit of all digit maps. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Resend...lost somewhere.. In section 7.2.5, its mentioned that "DigitMap requested in an AuditValue command with TerminationID ALL returns all DigitMaps in the gateway". But in section 7.1.14.1 its mentioned that "DigitMaps defined on the root Termination are global and can .....". 1)How is this possible that the definition of digit map is on ROOT and auditing the same uses TerminationID ALL?? 2)Does ALL TerminationID includes ROOT too?? 3)Cant the digit maps be audited on ROOT? If TerminationID ALL can be used for digit map audit, the response should contain the terminationID ALL instead of specifying the terminations. But this is in conflict with Table in section 7.2.5 which says that when TerminationID is Wildcard(ALL if *),irrespective of ContextID, all possible matchings of TerminationID should be returned. -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 09:53:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10577 for ; Tue, 1 Aug 2000 09:53:24 -0400 (EDT) Received: from standards (47.234.32.16:1830) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83D74@standards.nortelnetworks.com>; Tue, 1 Aug 2000 9:41:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1737 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 09:41:45 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83D73@standards.nortelnetworks.com>; Tue, 1 Aug 2000 9:41:45 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA01206; Tue, 1 Aug 2000 09:52:57 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 JAA10390; Tue, 1 Aug 2000 09:52:57 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Aug 2000 09:52:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF67864F@whq-msgusr-02.fore.com> Date: Tue, 1 Aug 2000 09:52:33 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Audit of all digit maps. X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM > In section 7.2.5, its mentioned that "DigitMap requested in > an AuditValue > command with TerminationID ALL returns all DigitMaps in > the gateway". But in > section 7.1.14.1 its mentioned that "DigitMaps defined on the > root Termination > are global and can .....". > > 1)How is this possible that the definition of digit map is on > ROOT and auditing > the same uses TerminationID ALL?? ROOT is a named "termination", and distinguishable from "ALL" So if I define DigitMaps A on Root, B on term1 and C on term2, auditing digitmaps of Root gives you A, auditing ALL gives you A,B and C > 2)Does ALL TerminationID includes ROOT too?? Sure > 3)Cant the digit maps be audited on ROOT? Sure > > > If TerminationID ALL can be used for digit map audit, the > response should > contain the terminationID ALL instead of specifying the > terminations. But this > is in conflict with Table in section 7.2.5 which says that > when TerminationID is > Wildcard(ALL if *),irrespective of ContextID, all possible > matchings of > TerminationID should be returned. When you do this audit, you would get a number of responses. Each termination with defined digitmaps would return responses, and the root would return responses if there were global digitmaps. In my example you would get something three responses. Brian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 09:58:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11638 for ; Tue, 1 Aug 2000 09:58:02 -0400 (EDT) Received: from standards (47.234.32.16:1830) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83D8D@standards.nortelnetworks.com>; Tue, 1 Aug 2000 9:46:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1769 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 09:46:20 -0400 Received: from qhars002.nortel.com (47.101.112.102:62996) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83D8C@standards.nortelnetworks.com>; Tue, 1 Aug 2000 9:46:15 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Tue, 1 Aug 2000 14:52:18 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Tue, 1 Aug 2000 09:49:06 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 1 Aug 2000 09:49:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFFBBF.3D849E50" Message-ID: <28560036253BD41191A10000F8BCBD11480BD0@zcard00g.ca.nortel.com> Date: Tue, 1 Aug 2000 09:48:57 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: pathNAME,serviceChangeParm X-To: "Prozan, Rakefet [Partner:LOD:Telrad]" To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01BFFBBF.3D849E50 Content-Type: text/plain On your first point: the 64 character maximum for pathNAME is an additional constraint which must be checked after the individual components are checked. I can see your point, that it would be nice if the ABNF had made this automatic, but the comment achieves the desired effect. Your second point does identify an omission. As I see it, ServiceChangeParm should indeed have an "at most once" constraint. > -----Original Message----- > From: Prozan, Rakefet [Partner:LOD:Telrad] > Sent: Tuesday, August 01, 2000 8:00 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: pathNAME,serviceChangeParm > > Hi all, > > Can someone clarify these two definitions in ABNF? > > 1)pathNAME is defined as follows: > pathNAME = ["*"] NAME * ("/" /"*"/ ALPHA / DIGIT /"_" / "$" ) > ["@" pathDomainName ] > > In the related comment it is written that pathNAME must not exceed 64 > chars. But NAME and pathDomainName > can be 64 chars each one .So,in theory the MGC could get a pathNAME > with more than 64 chars. > So, I think that either there should be a slash between NAME and > pathDomainName > (which means NAME or pathDomainName),or pathNAME should be defined by a > new type of maximum 64 chars. > > 2)Above the definition of serviceChangeParm there's no comment of > "at-most-once". Does it mean that > serviceChangeDescriptor can consist of (for example) more than one > serviceChangeMethod? > > many thanks in advance, > > -- > Rakefet Prozan, > Team Manager, S/W Development > Nortel SBU > Telrad Networks > ESN 828-3043 Email:rakefet.prozan@telrad.co.il > > > """ > -(o o)- > +---------------------------------oOO--(_)--OOo--------------+ > > .oooO Oooo. > -------------------------------( )---------( )------------ > \ ( ) / > \_) (_/ > > Have fun !!! ------_=_NextPart_001_01BFFBBF.3D849E50 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: pathNAME,serviceChangeParm

On your first point: = the 64 character maximum for pathNAME is an additional constraint which = must be checked after the individual components are checked.  I = can see your point, that it would be nice if the ABNF had made this = automatic, but the comment achieves the desired effect.

Your second point = does identify an omission.  As I see it, ServiceChangeParm should = indeed have an "at most once" constraint.

    -----Original Message-----
    From:   Prozan, Rakefet [Partner:LOD:Telrad]
    Sent:   Tuesday, August 01, 2000 8:00 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = pathNAME,serviceChangeParm

    Hi all,

    Can someone clarify these two = definitions in ABNF?

    1)pathNAME is defined as = follows:
          = pathNAME =3D ["*"] NAME * ("/" /"*"/ = ALPHA / DIGIT /"_" / "$" )
             &nb= sp;            = ["@" pathDomainName ]

     In the related comment it is = written that pathNAME must not exceed 64
    chars. But  NAME and = pathDomainName
     can be 64 chars each one .So,in = theory the MGC could get a pathNAME
    with more than 64 chars.
     So, I think that either there = should be a slash between NAME and
    pathDomainName
     (which means NAME or = pathDomainName),or pathNAME should be defined by a
    new type of maximum 64 chars.

    2)Above the definition of = serviceChangeParm there's no comment of
    "at-most-once". Does it = mean that
      serviceChangeDescriptor can = consist of (for example) more than one
    serviceChangeMethod?

    many thanks in advance,

    --
    Rakefet Prozan,
    Team Manager, S/W Development
    Nortel SBU
    Telrad Networks
    ESN 828-3043   = Email:rakefet.prozan@telrad.co.il


             &nb= sp;           &nb= sp;           &nb= sp;     """
             &nb= sp;           &nb= sp;           &nb= sp;   -(o o)-
    +---------------------------------oOO--(_)--OOo----------= ----+

             &nb= sp;           &nb= sp;         = .oooO         Oooo.
    -------------------------------(   = )---------(   )------------
             &nb= sp;           &nb= sp;          \ = (           ) = /
             &nb= sp;           &nb= sp;           = \_)         (_/

    Have fun !!!

------_=_NextPart_001_01BFFBBF.3D849E50-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 10:07:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14726 for ; Tue, 1 Aug 2000 10:07:21 -0400 (EDT) Received: from standards (47.234.32.16:1830) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83DAA@standards.nortelnetworks.com>; Tue, 1 Aug 2000 9:55:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1806 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 09:55:13 -0400 Received: from mars.hss.co.in (202.54.26.197:56585) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83DA9@standards.nortelnetworks.com>; Tue, 1 Aug 2000 9:55:11 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e71E7cq06159 for ; Tue, 1 Aug 2000 19:37:40 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525692E.004B723D ; Tue, 1 Aug 2000 19:14:04 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525692E.004B7032.00@sandesh.hss.hns.com> Date: Tue, 1 Aug 2000 19:18:50 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Re: Package descriptor for ROOT. To: MEGACO@STANDARDS.NORTELNETWORKS.COM If Audit on ROOT returns all packages, how can MGC know that out of these which are actually valid for ROOT termination. This means that there is no mechanism to audit packages actually realized by ROOT and MGC assumes that based on the agreed profile. I don't see any benefit in getting a union of all packageIDs because the MGC has to anyhow audit the termination types to find which of these are implemented on physical and which on ephemeral I suggest that we should include the termination name schema auditing mechanism first introduced in v14 in base root package to audit the capabilities of termination type. "Rosen, Brian" on 08/01/2000 07:12:22 PM Please respond to "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Madhu B Babu/HSS) Subject: Re: Package descriptor for ROOT. Audit of packages on Root returns all packages implemented on the union of all termination -- it is the way you find out what possible packages the MG implements. Possibly additional words needed. Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Tuesday, August 01, 2000 8:26 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Package descriptor for ROOT. > > > MGC if intends to "audit" packages supported by MG on ROOT, does > the response from MG indicates the packages supported on ROOT > termination or "UNION" of packages supported on different > terminations in MG? > -Madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 10:07:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14735 for ; Tue, 1 Aug 2000 10:07:22 -0400 (EDT) Received: from standards (47.234.32.16:1830) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83DB0@standards.nortelnetworks.com>; Tue, 1 Aug 2000 9:55:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1811 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 09:55:27 -0400 Received: from qhars002.nortel.com (47.101.112.102:64329) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83DAF@standards.nortelnetworks.com>; Tue, 1 Aug 2000 9:55:26 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Tue, 1 Aug 2000 15:01:23 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Tue, 1 Aug 2000 10:00:41 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 1 Aug 2000 10:00:10 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480BD2@zcard00g.ca.nortel.com> Date: Tue, 1 Aug 2000 10:00:05 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Audit of all digit maps. X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM The brief answer is that where DigitMaps are concerned ROOT is a valid terminationID. This was done for convenience, since some dial plans may apply to the whole MG. However, it is also true that some dial plans may apply only to specific terminations. > -----Original Message----- > From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM] > Sent: Tuesday, August 01, 2000 9:02 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Audit of all digit maps. > > In section 7.2.5, its mentioned that "DigitMap requested in an > AuditValue > command with TerminationID ALL returns all DigitMaps in the gateway". > But in > section 7.1.14.1 its mentioned that "DigitMaps defined on the root > Termination > are global and can .....". > > 1)How is this possible that the definition of digit map is on ROOT and > auditing > the same uses TerminationID ALL?? > 2)Does ALL TerminationID includes ROOT too?? > 3)Cant the digit maps be audited on ROOT? > > > If TerminationID ALL can be used for digit map audit, the response should > contain the terminationID ALL instead of specifying the terminations. But > this > is in conflict with Table in section 7.2.5 which says that when > TerminationID is > Wildcard(ALL if *),irrespective of ContextID, all possible matchings of > TerminationID should be returned. > -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 10:07:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14754 for ; Tue, 1 Aug 2000 10:07:23 -0400 (EDT) Received: from standards (47.234.32.16:1830) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83DBA@standards.nortelnetworks.com>; Tue, 1 Aug 2000 9:55:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1824 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 09:55:36 -0400 Received: from qhars002.nortel.com (47.101.112.102:64330) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83DAE@standards.nortelnetworks.com>; Tue, 1 Aug 2000 9:55:23 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Tue, 1 Aug 2000 15:04:51 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Tue, 1 Aug 2000 08:55:03 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 1 Aug 2000 08:55:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFFBC0.13B1B850" Message-ID: <28560036253BD41191A10000F8BCBD11480BD1@zcard00g.ca.nortel.com> Date: Tue, 1 Aug 2000 08:54:57 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Package descriptor for ROOT. X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01BFFBC0.13B1B850 Content-Type: text/plain The resolution of this question in the past (e.g. in Oslo) was that an audit of packages on ROOT only reveals those packages supported by the ROOT termination. As far as I am concerned, the ultimate answer to the "auditing of ephemerals" question will be to define packages with ROOT termination properties which indicate the capability of the MG to support specific types of termination. These package properties could include naming patterns, interface identifiers (e.g. IPv4 or IPv6 addresses), and relevanr resource limits. Since I believe this, perhaps I should be the one to draw up first drafts of the packages I have in mind. > -----Original Message----- > From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM] > Sent: Tuesday, August 01, 2000 8:26 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Package descriptor for ROOT. > > MGC if intends to "audit" packages supported by MG on ROOT, does > the response from MG indicates the packages supported on ROOT > termination or "UNION" of packages supported on different > terminations in MG? > -Madhubabu ------_=_NextPart_001_01BFFBC0.13B1B850 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Package descriptor for ROOT.

The resolution of = this question in the past (e.g. in Oslo) was that an audit of packages = on ROOT only reveals those packages supported by the ROOT = termination.  As far as I am concerned, the ultimate answer to the = "auditing of ephemerals" question will be to define packages = with ROOT termination properties which indicate the capability of the = MG to support specific types of termination.  These package = properties could include naming patterns, interface identifiers (e.g. = IPv4 or IPv6 addresses), and relevanr resource limits.  Since I = believe this, perhaps I should be the one to draw up first drafts of = the packages I have in mind.

    -----Original Message-----
    From:   Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
    Sent:   Tuesday, August 01, 2000 8:26 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Package descriptor for ROOT.

    MGC if intends to "audit" = packages supported by MG on ROOT, does
    the response from MG indicates the = packages supported on ROOT
    termination or "UNION" of = packages supported on different
    terminations in MG?
    -Madhubabu

------_=_NextPart_001_01BFFBC0.13B1B850-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 10:31:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24792 for ; Tue, 1 Aug 2000 10:31:34 -0400 (EDT) Received: from standards (47.234.32.16:3109) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83E15@standards.nortelnetworks.com>; Tue, 1 Aug 2000 10:19:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1940 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 10:19:35 -0400 Received: from mars.hss.co.in (202.54.26.197:56817) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83E14@standards.nortelnetworks.com>; Tue, 1 Aug 2000 10:19:30 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e71EVmq06537 for ; Tue, 1 Aug 2000 20:01:53 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525692E.004ED8F2 ; Tue, 1 Aug 2000 19:51:13 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525692E.004ED864.00@sandesh.hss.hns.com> Date: Tue, 1 Aug 2000 19:56:04 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Response of action with only context properties To: MEGACO@STANDARDS.NORTELNETWORKS.COM If only context properties are specified in the request without any command, the response can't be sent if you don't specify the context properties in the response, whereas the idea is to send back in response only the stuff that contains either overspecified or under-specified values in the request. The grammar should be modified to make context properties optional. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 11:23:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08760 for ; Tue, 1 Aug 2000 11:23:56 -0400 (EDT) Received: from standards (47.234.32.16:3109) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83EDA@standards.nortelnetworks.com>; Tue, 1 Aug 2000 11:12:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2180 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 11:12:01 -0400 Received: from qhars002.nortel.com (47.101.112.102:41350) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83ED9@standards.nortelnetworks.com>; Tue, 1 Aug 2000 11:12:01 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Tue, 1 Aug 2000 16:07:18 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Tue, 1 Aug 2000 09:53:41 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 1 Aug 2000 09:53:36 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480BD7@zcard00g.ca.nortel.com> Date: Tue, 1 Aug 2000 09:53:33 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Response of action with only context properties X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Let me make something clear in response to this suggestion and others for modification of the Megaco grammar. Megaco version 1 is now a done deal -- the IESG approved the corresponding RFCs in May, and the ITU-T decided H.248 v1 last June. The most recent Last Call on draft-ietf-megaco-merged-01.txt was simply to create a single RFC reproducing the content of the ones approved in May. From now on, we are talking about errors in Megaco v1 (which I propose we capture in a living document, and which the ITU-T will capture in the H.248v1 Implementor's Guide), and possible future work for Megaco/H.248. I'll note that this latter topic is not within our current charter, but discussion could be useful to guide our AD's decision on whether we recharter. > -----Original Message----- > From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM] > Sent: Tuesday, August 01, 2000 10:26 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Response of action with only context properties > > If only context properties are specified in the request without any > command, the > response > can't be sent if you don't specify the context properties in the response, > whereas the idea > is to send back in response only the stuff that contains either > overspecified or > under-specified > values in the request. The grammar should be modified to make context > properties > optional. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 13:31:20 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10609 for ; Tue, 1 Aug 2000 13:31:19 -0400 (EDT) Received: from standards (47.234.32.16:1056) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83F50@standards.nortelnetworks.com>; Tue, 1 Aug 2000 13:19:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2330 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 13:19:10 -0400 Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83F4F@standards.nortelnetworks.com>; Tue, 1 Aug 2000 13:19:10 -0400 Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA06449; Tue, 1 Aug 2000 13:30:25 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA06432; Tue, 1 Aug 2000 13:30:24 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Aug 2000 19:30:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB087FC542@nl0006exch002u.nl.lucent.com> Date: Tue, 1 Aug 2000 19:30:16 +0200 Reply-To: "Wijnen, Bert (Bert)" Sender: "Media Gateway Control (megaco)" From: "Wijnen, Bert (Bert)" Subject: Invitation for JointNM meeting 9-11 August 200 X-To: iptel@lists.bell-labs.com, SIGTRAN@STANDARDS.NORTELNETWORKS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, Various technical people who normally attend Tiphon, ITU, ETSI, T1M1, have agreed to work together in a series of so called "Joint Network Management" meetings. They have also invited technical contribution from subject matter experts who are active in the IETF and other organisations. The relevant IETF Area Directors do encourage individual participation by subject matter experts, even though these meetings are not to be seen as formal IETF meetings. Individuals that attend should not be seen as speaking for the IETF or for IETF working groups but the ADs feel that anything that improves communication between groups working on simular issues is helpful The next meeting is Aug 9-11 in Torrance, California. Subject matter experts are invited to participate (on personal title). There is no need to register for the meeting, you can just show up at the Torrance Marriott. The proposed agenda and the "scope of activities" is attached. Bert Wijnen & Randy Bush Area Directors Operations and Management Scott Bradner, Area Director Transport -------------------------- ------------------------------------- AGENDA FOR JOINT NM MEETING AUGUST 9-11, 2000 NOTE ON SCOPE OF ACTIVITIES: Ongoing discussions have made it evident that there may some clarification required with respect to the scope of the activities within the Joint-NM Group (JNG). In a nutshell, the scope of the JNG includes all management aspects of IP and hybrid circuit switched/packet networks. At the first joint session it was agreed that priority will be given to VoIP services as several of the standards organizations participating in this effort are focusing on this service. The implications of this priority are that requirements will be analyzed with respect to VoIP and the management infrastructure required to support this service will be defined. However, whenever, it is evident that a particular management activity is useful for other applications it will be generalized to accommodate those services. In addition, at the NE or NM level there may be lots of functionality that is application agnostic, again this functionality will be defined in the appropriate manner. In addition, since the group is driven by contributions, contributions that address the broader problem will also be accepted. August 9, 2000 1. Approval of Agenda 2. Fault Management (for VoIP environment) (1 Day) * Alarm Reporting Requirements VoIP [Build on Results of May Meeting] * Abstract Information Model & Flows for Alarm Reporting Drafting Group to produce first cut of text may be established * Trouble-ticket Requirements for VoIP [Build on Results of May Meeting] * Abstract Information Model & Flows for Trouble Ticketing 3. Performance Management for the VoIP environment (1/2 day) * QoS environment for VoIP [Inpiut required from QoS Experts] * Traffic management requirements for VoIP [Build on Results of May Meeting] * Evaluation of Q,823 for the IP environment 4. Progress of Framework Documents (1/2 day) 5. New Business (IE Additional contributions received on topics) (1/4 day) 6. Work Plan for future meetings (1/4 day) 7. Meeting wrap up and call for contributions for August meeting ------------------------ more information may be available at: http://www.etsi.org/jointnm/jointnm.htm or at: http://list.etsi.fr/archives/jointnm.html From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 18:39:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23022 for ; Tue, 1 Aug 2000 18:39:41 -0400 (EDT) Received: from standards (47.234.32.16:4896) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8415A@standards.nortelnetworks.com>; Tue, 1 Aug 2000 18:27:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3000 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 18:27:54 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84159@standards.nortelnetworks.com>; Tue, 1 Aug 2000 18:17:54 -0400 Received: from cisco.com (sj-dial-1-249.cisco.com [171.68.179.250]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id PAA19752; Tue, 1 Aug 2000 15:29:01 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480BD1@zcard00g.ca.nortel.com> Content-Type: multipart/alternative; boundary="------------B0DECD3FBDF9C99623D0E283" Message-ID: <3987501B.2B2F9C7C@cisco.com> Date: Tue, 1 Aug 2000 18:32:59 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: Package descriptor for ROOT. X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------B0DECD3FBDF9C99623D0E283 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tom-PT Taylor wrote: > > > The resolution of this question in the past (e.g. in Oslo) was that an > audit of packages on ROOT only reveals those packages supported by the > ROOT termination. Contrary to Brian's response, that was my expectation as well, not least considering the following text in Section 6.2.5 (root termination): "* an AuditValue return - to examine the values of properties and statistics implemented on root" -- Flemming > > As far as I am concerned, the ultimate answer to the "auditing of > ephemerals" question will be to define packages with ROOT termination > properties which indicate the capability of the MG to support specific > types of termination. These package properties could include naming > patterns, interface identifiers (e.g. IPv4 or IPv6 addresses), and > relevanr resource limits. Since I believe this, perhaps I should be > the one to draw up first drafts of the packages I have in mind. > > -----Original Message----- > From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM] > Sent: Tuesday, August 01, 2000 8:26 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Package descriptor for ROOT. > > MGC if intends to "audit" packages supported by MG on ROOT, does > the response from MG indicates the packages supported on ROOT > termination or "UNION" of packages supported on different > terminations in MG? > -Madhubabu > -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 --------------B0DECD3FBDF9C99623D0E283 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Tom-PT Taylor wrote:

 

The resolution of this question in the past (e.g. in Oslo) was that an audit of packages on ROOT only reveals those packages supported by the ROOT termination.

Contrary to Brian's response, that was my expectation as well, not least considering the following text in Section 6.2.5 (root termination):

"* an AuditValue return - to examine the values of properties and statistics implemented on root"
 

-- Flemming
 

 
As far as I am concerned, the ultimate answer to the "auditing of ephemerals" question will be to define packages with ROOT termination properties which indicate the capability of the MG to support specific types of termination.  These package properties could include naming patterns, interface identifiers (e.g. IPv4 or IPv6 addresses), and relevanr resource limits.  Since I believe this, perhaps I should be the one to draw up first drafts of the packages I have in mind.
    -----Original Message-----
    From:  Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
    Sent:  Tuesday, August 01, 2000 8:26 AM
    To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       Package descriptor for ROOT.

    MGC if intends to "audit" packages supported by MG on ROOT, does
    the response from MG indicates the packages supported on ROOT
    termination or "UNION" of packages supported on different
    terminations in MG?
    -Madhubabu

--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839
  --------------B0DECD3FBDF9C99623D0E283-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 23:38:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23547 for ; Tue, 1 Aug 2000 23:38:28 -0400 (EDT) Received: from standards (47.234.32.16:1036) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB841C7@standards.nortelnetworks.com>; Tue, 1 Aug 2000 23:26:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3130 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 23:26:41 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB841C6@standards.nortelnetworks.com>; Tue, 1 Aug 2000 23:16:35 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e723Rnp28570; Wed, 2 Aug 2000 05:27:49 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id FAA09755; Wed, 2 Aug 2000 05:27:48 +0200 (MET DST) Received: from ericsson.com (rmt160157.am.ericsson.se [138.85.160.157]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id FAA06041; Wed, 2 Aug 2000 05:27:45 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF678627@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39851525.185AF622@ericsson.com> Date: Mon, 31 Jul 2000 15:56:53 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Auditing of ephemerals X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Brian and Flemming, I see my idea of how to audit non-instantiated ephemerals isn't willing too many supporters. I see 2 issues here. One is about naming schema and is now being covered in another thread. The second is how to audit euphemerals particularly non-instantiated euphemerals. Following Brian's premise that all provisioning is evil and those that do it should burn for eternity ;-). We need a way to audit the capabilities of the terminations in a MG. For physical terminations no problem as we have the NULL context. For euphemerals considering that the MGC knows the naming pattern we still need to be able to find what the termination can do, before we instantiate it. A euphemeral may not physcially exist in hardware but it will still have capabilities and values (packages) that are associated with it that can be used by the MGC. You have to audit it or the other alternative is to provision and not having to worry about heating for an eternity. I provided a thought of how this could be acheived in my previous emails. Does anyone else have an idea of how to do this? Cheers, Christian "Rosen, Brian" wrote: > > > > Firstly I agree that there's no requirement that ephemerals > > are named > > > RTP/* is was just an example. You'd know the naming pattern > > before you > > > did an audit. > > > > > > > Actually, part of the point is that you do *not* know the > > naming pattern, but > > want to learn it. Seems there's no way to do that so we will have to > > provision it. > Yes, well there was a big mess about learning naming patterns. > I had a suggestion, which was not accepted, no alternative > was offered, and so there is no way to learn the naming pattern > of any set of terminations. > > I think provisioning it is a very bad idea, but you have no > alternative. Sigh. > > > > > > > > > Secondly I don't see what stops you doing a wildcard audit > > (particularly > > > an audit capability) on non instantiated ephemerals. > > > > How can you audit something that doesn't exist ? > I agree, you can't > > > > > > If you use > > > ContextID ALL, wildcard the termination and ask for > > wildcard response > > > then you should be able to get whats wanted. The spec > > doesn't disallow > > > this. > > > > I think it does. The command is to be tried on all > > terminations matching the > > wildcard, so what do you do when there are no instantiations of some > > ephemeral termination type - I would expect nothing. > As would I > > > > > > > > You have to be able to do an auditvalue to see the value of the > > > packages that relate to the ephemeral. > > > > On an instantiated ephemeral - yes, but on an non-existent ephemeral ? > > > > > > > > > > > Cheers, Christian > > > > > > "Rosen, Brian" wrote: > > > > > > > > I don't agree with this answer. > > > > > > > > First of all, I don't think it is possible to do a wildcard audit > > > > of RTP/* unless there are some terminations that match > > (instantiated) > > > > > > > > Second, there is no requirement that rtp ephemerals are > > named RTP/* > > > > > > > > I think the answer is what I said, you audit packages. > > > > If there are more than one "rtp" package, so what, if your MGC > > > > implements a package that does some kind of rtp, then you > > can create > > > > rtp ephemerals. > > > > > > > > I'm not sure how you ever get into trouble here, because while I > > > > can see extending rtp (or atm), I can't see replacing it, and then > > > > having an MG implement two kinds of rtp. If they did, there would > > > > have to be something in SDP, or a parameter in LocalControl or > > > > TerminationState which told the gateway which one to create. > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Christian Groves > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Sent: 7/26/00 2:04 AM > > > > Subject: Re: Auditing of ephemerals > > > > > > > > G'Day Flemming, > > > > > > > > By auditing rtp/* and asking for a wildcard response it > > will give you > > > > the packages and properties for that class of termination > > without the > > > > need for instantiating each of the euphemeral terminations. > > > > > > > > Naming schemes can be provisioned to a certain extent and > > then auditing > > > > can give you the characteristics of named terminations. > > > > > > > > Cheers, Christian > > > > > > > > Flemming Andreasen wrote: > > > > > > > > > > "Rosen, Brian" wrote: > > > > > > > > > > > You audit packages. For example, if the MG > > implements RTP, then > > > > > > it implements the RTP package. Same with ATM. You > > audit packages > > > > of > > > > > > the whole gateway, of course. > > > > > > > > > > > > > > > > That doesn't sound particularly foolproof - who's to > > say I want to > > > > implement > > > > > *the* RTP package or *the* ATM package, etc. > > Nevertheless, it still > > > > leaves > > > > > me with a couple of questions: > > > > > > > > > > 1. How do I figure out the naming scheme used for these > > ephemeral > > > > > terminations, e.g. "rtp/{1,2,3,4}" ? > > > > > 2. If I have more than one type of ephemeral > > termination supported, > > > > how do I > > > > > figure out which one support what packages (without > > instantiating one > > > > of > > > > > course). > > > > > > > > > > -- Flemming > > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > -----Original Message----- > > > > > > From: Flemming Andreasen > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > Sent: 7/25/00 6:20 PM > > > > > > Subject: Auditing of ephemerals > > > > > > > > > > > > Once upon a time, we had quite a lot of discussion > > about how to > > > > audit > > > > > > ephemerals at startup time. We even had a suggestion > > in the Base > > > > Root > > > > > > Package aimed specifically at solving this, however > > it was removed > > > > later > > > > > > on and I can't remember if we ever came up with an > > alternative, > > > > hence my > > > > > > question: > > > > > > > > > > > > How does an MGC figure out what ephemerals an MG supports ? > > > > > > > > > > > > -- Flemming > > > > > > > > > > > > -- > > > > > > Flemming Andreasen Phone: +1 732 452 1667 > > > > > > Cisco Systems Fax: +1 240 359 5839 > > > > > > > > > > -- > > > > > Flemming Andreasen Phone: +1 732 452 1667 > > > > > Cisco Systems Fax: +1 240 359 5839 > > > > -- > > Flemming Andreasen Phone: +1 732 452 1667 > > Cisco Systems Fax: +1 240 359 5839 > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 2 08:56:06 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29540 for ; Wed, 2 Aug 2000 08:56:06 -0400 (EDT) Received: from standards (47.234.32.16:1961) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84320@standards.nortelnetworks.com>; Wed, 2 Aug 2000 8:43:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3560 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Aug 2000 08:43:57 -0400 Received: from qhars002.nortel.com (47.101.112.102:62052) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8431E@standards.nortelnetworks.com>; Wed, 2 Aug 2000 8:43:57 -0400 Received: from zrtps06s.us.nortel.com (actually 47.140.48.50) by qhars002.nortel.com; Wed, 2 Aug 2000 13:18:42 +0100 Received: from zmers013 (actually zmers013.ca.nortel.com) by zrtps06s.us.nortel.com; Wed, 2 Aug 2000 08:16:51 -0400 Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by zmers013; Wed, 2 Aug 2000 08:16:40 -0400 Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA10242 for ; Wed, 2 Aug 2000 15:15:36 +0300 (IDT) Received: from tl100h0c.elex.co.il by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id PAA09919; Wed, 2 Aug 2000 15:15:35 +0300 (IDT) Received: from tmx100.elex.co.il (rakefet@localhost [127.0.0.1]) by tl100h0c.elex.co.il with ESMTP (8.8.6 (PHNE_14041)/8.7.3) id PAA07282 for ; Wed, 2 Aug 2000 15:15:34 +0300 (IDT) X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Message-ID: <398810E5.FA0D93FC@tmx100.elex.co.il> Date: Wed, 2 Aug 2000 15:15:33 +0300 Reply-To: "Prozan, Rakefet" Sender: "Media Gateway Control (megaco)" From: "Prozan, Rakefet" Organization: Telrad Ltd. Subject: TerminationID To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, In A.1 "Coding of wildcards" it is written that:"Termination IDs consist of at most 64 bits". ASN.1 definition of Termination ID supports this, but in ABNF the definition of Termination ID is: TerminationID = "ROOT" / pathNAME / "$" / "*" . The problem is that pathNAME can consist of 64 CHARS. Can someone clarify this problem? many thanks in advance, -- Rakefet Prozan, Team Manager, S/W Development Nortel SBU Telrad Networks ESN 828-3043 Email:rakefet.prozan@telrad.co.il """ -(o o)- +---------------------------------oOO--(_)--OOo--------------+ .oooO Oooo. -------------------------------( )---------( )------------ \ ( ) / \_) (_/ Have fun !!! From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 2 09:17:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29546 for ; Wed, 2 Aug 2000 08:56:06 -0400 (EDT) Received: from standards (47.234.32.16:1961) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84324@standards.nortelnetworks.com>; Wed, 2 Aug 2000 8:43:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3565 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Aug 2000 08:43:57 -0400 Received: from qhars002.nortel.com (47.101.112.102:62053) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8431F@standards.nortelnetworks.com>; Wed, 2 Aug 2000 8:43:57 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Wed, 2 Aug 2000 13:44:32 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Wed, 2 Aug 2000 07:43:38 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 2 Aug 2000 07:43:34 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480BDE@zcard00g.ca.nortel.com> Date: Wed, 2 Aug 2000 07:43:31 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: FW: Interworking Problem To: MEGACO@STANDARDS.NORTELNETWORKS.COM Resend. > -----Original Message----- > From: Taylor, Tom-PT [NORSE:B901:EXCH] > Sent: Tuesday, August 01, 2000 11:18 AM > To: Tubagus Syamsudin; megaco > Subject: RE: Interworking Problem > > Answers below. Please note that Megaco and H.248 are identical protocols. > > -----Original Message----- > From: Tubagus Syamsudin [SMTP:bagus01@TELKOM.NET] > Sent: Tuesday, August 01, 2000 10:55 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Interworking Problem > > Dear All, > > I was learning VoIP technology, but for implementation, i still > confuse for some following problems : > > 1. If we have H.323 based network, and we want to combine with the > Megaco. How can H.323 accommodate that? > [PTT] > Megaco/H.248 is used on an interface which is not present in the > original H.323 architecture. This is the interface which is opened up > when an H.323 Gateway is decomposed into a call control part (the Media > Gateway Controller, MGC) and a part responsible for processing media (the > Media Gateway, MG). H.225.0 and H.245 protocols continue to be used > between H.323 Gateway, Gatekeeper, MC, and Endpoint functions. > > 2. What's the advantage of point 1 (combination of Megaco-H.323) > compare with H.323 total solution. > [PTT] > Various advantages have been suggested for Gateway decomposition. > The one I cite most often is extension of geographic reach: small MGs can > collect media traffic from a large number of local switching offices or > office sites, while the signalling gets directed to a central site, saving > on overall transmission costs. In any event, after much initial > discussion, the industry accepted the validity of gateway decomposition as > an engineering principle. > > 3. How is the flow of call set-up from point 1. > [PTT] > One of the things we must do is produce a document showing example > call flows. There is one example in Megaco/H.248 Appendix A. > > 4. Can Megaco used as stand alone protocol in the VoIP network, > cause we know that Megaco has handset, DTMF, and RTP packages, address > translation and routing function that can handle until end user. > [PTT] > Megaco is not intended for use between call control entities. It > could be the only protocol used if both parties to the call are within the > span of control of the same MGC. > > 5. If we have Megaco based network, and we want to use SIP as a call > set-up protocol, how to combine SIP protocol as part of Megaco. Is that > combination will become the specific package or there is another mechanism > in MGCP that accommodate that issue? > [PTT] > First, Megaco and MGCP are different (competing) protocols. > Secondly, no special accommodation is required -- Megaco is designed to be > independent of which signalling protocol is used between call control > entities. > > 6. Do you have a comparation between : > > a. Combination H.323 and Megaco > > b. Combination SIP and Megaco > > c. H.323 total solution > > Which one is technically the best ? > > [PTT] These are engineering alternatives. The choice is > dependent on the requirements to be met by the network you are trying to > design, particularly in terms of scale. > > Your kind explanation on the questions above would be highly > appreciated. Your answers are very important for me. > > Thank you very much for your cooperation and attention. We look > forward to hearing from you soon. > > Best regards > > Bagus. > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 2 10:02:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22289 for ; Wed, 2 Aug 2000 10:02:25 -0400 (EDT) Received: from standards (47.234.32.16:1407) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8439E@standards.nortelnetworks.com>; Wed, 2 Aug 2000 9:50:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3730 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Aug 2000 09:50:17 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8439D@standards.nortelnetworks.com>; Wed, 2 Aug 2000 9:50:12 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23796; Wed, 2 Aug 2000 10:01:27 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 KAA03069; Wed, 2 Aug 2000 10:01:27 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 Aug 2000 10:01:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF67865E@whq-msgusr-02.fore.com> Date: Wed, 2 Aug 2000 10:01:26 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: TerminationID X-To: "Prozan, Rakefet" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'm not clear what problem you refer to. A TerminationID in binary encoding is a bit string A TerminationID in text encoding is a character string The lengths are, of course, different. Does that answer the question? Brian > -----Original Message----- > From: Prozan, Rakefet [mailto:rakefet.prozan@telrad.co.il] > Sent: Wednesday, August 02, 2000 8:16 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: TerminationID > > > Hi all, > > In A.1 "Coding of wildcards" it is written that:"Termination > IDs consist > of at most > 64 bits". ASN.1 definition of Termination ID supports this, > but in ABNF > the definition of Termination ID > is: > TerminationID = "ROOT" / pathNAME / "$" / "*" . > > The problem is that pathNAME can consist of 64 CHARS. Can someone > clarify this problem? > > many thanks in advance, > > -- > Rakefet Prozan, > Team Manager, S/W Development > Nortel SBU > Telrad Networks > ESN 828-3043 Email:rakefet.prozan@telrad.co.il > > > """ > -(o o)- > +---------------------------------oOO--(_)--OOo--------------+ > > .oooO Oooo. > -------------------------------( )---------( )------------ > \ ( ) / > \_) (_/ > > Have fun !!! > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 2 10:28:20 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00727 for ; Wed, 2 Aug 2000 10:28:20 -0400 (EDT) Received: from standards (47.234.32.16:4159) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB843D0@standards.nortelnetworks.com>; Wed, 2 Aug 2000 10:16:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3793 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Aug 2000 10:16:24 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB843CF@standards.nortelnetworks.com>; Wed, 2 Aug 2000 10:16:23 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26392; Wed, 2 Aug 2000 10:27:39 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10286; Wed, 2 Aug 2000 10:27:39 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 Aug 2000 10:27:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF67865F@whq-msgusr-02.fore.com> Date: Wed, 2 Aug 2000 10:27:37 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Auditing of ephemerals X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM I see the problem, and as an architectural matter, I'd like to be able to achieve what you want to achieve. As a practical matter, knowing what packages are implemented on the MG is probably enough. You would have to have a situation where there was some kind of asymmetric split of capabilities on the gateway, where some ephemerals \ could do DTMF detect while others couldn't. I think that that is not practical, because there is no way (currently) to ask the gateway to create a specific kind of ephemeral - it's inferred in the media descriptor. I'll absolutely agree you need AT LEAST to be able to get the list of packages implemented on the gateway, but that's the other thread. Not being able to find out exactly what the MG can do (which packages on which terminations) is, I think, something we want. At the moment, it looks like something we would have to change. Linking the threads, I could propose in my name pattern package to have the package list as another parameter returned. That would give you what you are looking for. It would be annoying in that you would not get a Package descriptor, you would get a parameter of ROOT which had the list. It has the big advantage that it is not a change to the protocol. The most sweeping answer would be to define a wildcard command with wildcard response request which doesn't match any ephemerals to return the value of the ephemerals as if there were some. Another way is to define AuditCapabilities of Packages to do what we want. Brian > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > Sent: Monday, July 31, 2000 1:57 AM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Auditing of ephemerals > > > G'Day Brian and Flemming, > > I see my idea of how to audit non-instantiated ephemerals > isn't willing > too many supporters. I see 2 issues here. One is about naming > schema and > is now being covered in another thread. The second is how to audit > euphemerals particularly non-instantiated euphemerals. > > Following Brian's premise that all provisioning is evil and those that > do it should burn for eternity ;-). We need a way to audit the > capabilities of the terminations in a MG. For physical terminations no > problem as we have the NULL context. For euphemerals considering that > the MGC knows the naming pattern we still need to be able to find what > the termination can do, before we instantiate it. A euphemeral may not > physcially exist in hardware but it will still have capabilities and > values (packages) that are associated with it that can be used by the > MGC. You have to audit it or the other alternative is to provision and > not having to worry about heating for an eternity. > > I provided a thought of how this could be acheived in my previous > emails. Does anyone else have an idea of how to do this? > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > > > Firstly I agree that there's no requirement that ephemerals > > > are named > > > > RTP/* is was just an example. You'd know the naming pattern > > > before you > > > > did an audit. > > > > > > > > > > Actually, part of the point is that you do *not* know the > > > naming pattern, but > > > want to learn it. Seems there's no way to do that so we > will have to > > > provision it. > > Yes, well there was a big mess about learning naming patterns. > > I had a suggestion, which was not accepted, no alternative > > was offered, and so there is no way to learn the naming pattern > > of any set of terminations. > > > > I think provisioning it is a very bad idea, but you have no > > alternative. Sigh. > > > > > > > > > > > > > Secondly I don't see what stops you doing a wildcard audit > > > (particularly > > > > an audit capability) on non instantiated ephemerals. > > > > > > How can you audit something that doesn't exist ? > > I agree, you can't > > > > > > > > > If you use > > > > ContextID ALL, wildcard the termination and ask for > > > wildcard response > > > > then you should be able to get whats wanted. The spec > > > doesn't disallow > > > > this. > > > > > > I think it does. The command is to be tried on all > > > terminations matching the > > > wildcard, so what do you do when there are no > instantiations of some > > > ephemeral termination type - I would expect nothing. > > As would I > > > > > > > > > > > > You have to be able to do an auditvalue to see the value of the > > > > packages that relate to the ephemeral. > > > > > > On an instantiated ephemeral - yes, but on an > non-existent ephemeral ? > > > > > > > > > > > > > > > Cheers, Christian > > > > > > > > "Rosen, Brian" wrote: > > > > > > > > > > I don't agree with this answer. > > > > > > > > > > First of all, I don't think it is possible to do a > wildcard audit > > > > > of RTP/* unless there are some terminations that match > > > (instantiated) > > > > > > > > > > Second, there is no requirement that rtp ephemerals are > > > named RTP/* > > > > > > > > > > I think the answer is what I said, you audit packages. > > > > > If there are more than one "rtp" package, so what, if your MGC > > > > > implements a package that does some kind of rtp, then you > > > can create > > > > > rtp ephemerals. > > > > > > > > > > I'm not sure how you ever get into trouble here, > because while I > > > > > can see extending rtp (or atm), I can't see replacing > it, and then > > > > > having an MG implement two kinds of rtp. If they > did, there would > > > > > have to be something in SDP, or a parameter in LocalControl or > > > > > TerminationState which told the gateway which one to create. > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Christian Groves > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Sent: 7/26/00 2:04 AM > > > > > Subject: Re: Auditing of ephemerals > > > > > > > > > > G'Day Flemming, > > > > > > > > > > By auditing rtp/* and asking for a wildcard response it > > > will give you > > > > > the packages and properties for that class of termination > > > without the > > > > > need for instantiating each of the euphemeral terminations. > > > > > > > > > > Naming schemes can be provisioned to a certain extent and > > > then auditing > > > > > can give you the characteristics of named terminations. > > > > > > > > > > Cheers, Christian > > > > > > > > > > Flemming Andreasen wrote: > > > > > > > > > > > > "Rosen, Brian" wrote: > > > > > > > > > > > > > You audit packages. For example, if the MG > > > implements RTP, then > > > > > > > it implements the RTP package. Same with ATM. You > > > audit packages > > > > > of > > > > > > > the whole gateway, of course. > > > > > > > > > > > > > > > > > > > That doesn't sound particularly foolproof - who's to > > > say I want to > > > > > implement > > > > > > *the* RTP package or *the* ATM package, etc. > > > Nevertheless, it still > > > > > leaves > > > > > > me with a couple of questions: > > > > > > > > > > > > 1. How do I figure out the naming scheme used for these > > > ephemeral > > > > > > terminations, e.g. "rtp/{1,2,3,4}" ? > > > > > > 2. If I have more than one type of ephemeral > > > termination supported, > > > > > how do I > > > > > > figure out which one support what packages (without > > > instantiating one > > > > > of > > > > > > course). > > > > > > > > > > > > -- Flemming > > > > > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Flemming Andreasen > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > > Sent: 7/25/00 6:20 PM > > > > > > > Subject: Auditing of ephemerals > > > > > > > > > > > > > > Once upon a time, we had quite a lot of discussion > > > about how to > > > > > audit > > > > > > > ephemerals at startup time. We even had a suggestion > > > in the Base > > > > > Root > > > > > > > Package aimed specifically at solving this, however > > > it was removed > > > > > later > > > > > > > on and I can't remember if we ever came up with an > > > alternative, > > > > > hence my > > > > > > > question: > > > > > > > > > > > > > > How does an MGC figure out what ephemerals an MG > supports ? > > > > > > > > > > > > > > -- Flemming > > > > > > > > > > > > > > -- > > > > > > > Flemming Andreasen Phone: +1 732 452 1667 > > > > > > > Cisco Systems Fax: +1 240 359 5839 > > > > > > > > > > > > -- > > > > > > Flemming Andreasen Phone: +1 732 452 1667 > > > > > > Cisco Systems Fax: +1 240 359 5839 > > > > > > -- > > > Flemming Andreasen Phone: +1 732 452 1667 > > > Cisco Systems Fax: +1 240 359 5839 > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 2 10:40:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05000 for ; Wed, 2 Aug 2000 10:40:54 -0400 (EDT) Received: from standards (47.234.32.16:4159) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB843F5@standards.nortelnetworks.com>; Wed, 2 Aug 2000 10:28:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3839 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Aug 2000 10:28:58 -0400 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB843F4@standards.nortelnetworks.com>; Wed, 2 Aug 2000 10:28:58 -0400 Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA05338 for ; Wed, 2 Aug 2000 10:40:15 -0400 (EDT) Received: from electric.amc.bell-labs.com (h135-17-7-254.lucent.com [135.17.7.254]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA05330 for ; Wed, 2 Aug 2000 10:40:14 -0400 (EDT) Received: by electric.amc.bell-labs.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 Aug 2000 10:38:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 2 Aug 2000 10:38:26 -0400 Reply-To: "Raju, Makaraju" Sender: "Media Gateway Control (megaco)" From: "Raju, Makaraju" Subject: ServiceChange help needed ... X-cc: jagadish , "Nadathur, Srivathsan" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi all, When the GW comes up does it send any ServiceChange's to GWC indicating about the active Terminations? How does the GWC know about all the active terminations a GW has during startup? IPDC has a command RLS(Request for Line Status) to get the status of a line. Does Megaco has an equivalent command to request for line status? Or Can we do this with AuditValue/Notify commands? The actual problem here is: the GW might be configured for max # of terminations, but all of them may not be active during startup, GW only knows what are all active and some how GWC has to know this nformation. Thanks in advance for the help Raju From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 2 10:55:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09961 for ; Wed, 2 Aug 2000 10:55:53 -0400 (EDT) Received: from standards (47.234.32.16:4159) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84442@standards.nortelnetworks.com>; Wed, 2 Aug 2000 10:43:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3941 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Aug 2000 10:43:42 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84441@standards.nortelnetworks.com>; Wed, 2 Aug 2000 10:43:37 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA29004; Wed, 2 Aug 2000 10:54:51 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 KAA17281; Wed, 2 Aug 2000 10:54:50 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 Aug 2000 10:54:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF678663@whq-msgusr-02.fore.com> Date: Wed, 2 Aug 2000 10:54:48 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: ServiceChange help needed ... X-To: "Raju, Makaraju" To: MEGACO@STANDARDS.NORTELNETWORKS.COM When the MG comes up, it sends a ServiceChange to the MGC. That does not tell the MGC about active terminations. The MGC can Audit terminations in the MG to find out that information. In particular, it might do a wildcard audit of all contexts. That would result in a response that would list all active contexts, and the terminationIds of the terminations in those contexts. You can audit each termination to determine it's state. Brian > -----Original Message----- > From: Raju, Makaraju [mailto:mmraju@LUCENT.COM] > Sent: Wednesday, August 02, 2000 10:38 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: ServiceChange help needed ... > > > Hi all, > > When the GW comes up does it send any ServiceChange's to GWC > indicating > about the > active Terminations? > How does the GWC know about all the active terminations a GW > has during > startup? > > IPDC has a command RLS(Request for Line Status) to get the > status of a line. > Does Megaco has an equivalent command to request for line status? > Or Can we do this with AuditValue/Notify commands? > > The actual problem here is: the GW might be configured for max # of > terminations, but > all of them may not be active during startup, GW only knows > what are all > active and > some how GWC has to know this nformation. > > Thanks in advance for the help > Raju > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 2 12:43:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19068 for ; Wed, 2 Aug 2000 12:43:43 -0400 (EDT) Received: from standards (47.234.32.16:1887) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8452F@standards.nortelnetworks.com>; Wed, 2 Aug 2000 12:31:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4256 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Aug 2000 12:31:51 -0400 Received: from mail.mediatrix.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84522@standards.nortelnetworks.com>; Wed, 2 Aug 2000 12:21:51 -0400 Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 Aug 2000 12:28:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 2 Aug 2000 12:28:01 -0400 Reply-To: =?iso-8859-1?Q?Fran=E7ois_Berard?= Sender: "Media Gateway Control (megaco)" From: =?iso-8859-1?Q?Fran=E7ois_Berard?= Subject: MGCP Mailing List X-To: "rmwise@VSYS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Bob wrote (14/07/00): > The ISC/IETF relationship may not be a formal one, but if you are attempting > to implement MGCP in any "standard" way (quotes used on purpose - please - > no more emails!) you do have two options - ISC Device Control Working Group, > and CableLabs. Many vendors are presently working on MGCP products and RFC 2705 will probably need to be updated in a near future (at least to clarify a few things). Is the ISC Mailing list the right place to do this? Are the ISC and CableLabs mailing lists the only options for MGCP implementers? > I mention this to emphasize that > 0) MGCP is alive and well > 1) There are other fora for MGCP discussions > 2) This isn't the right place > 3) Clearly there is some interest about MGCP on this list, and it needs somewhere to go Thanks, Francois Berard From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 2 12:50:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21363 for ; Wed, 2 Aug 2000 12:50:54 -0400 (EDT) Received: from standards (47.234.32.16:1887) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84551@standards.nortelnetworks.com>; Wed, 2 Aug 2000 12:39:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4305 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Aug 2000 12:39:02 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84550@standards.nortelnetworks.com>; Wed, 2 Aug 2000 12:39:02 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA10068; Wed, 2 Aug 2000 12:50:17 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA17394; Wed, 2 Aug 2000 12:50:18 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 Aug 2000 12:50:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF67866D@whq-msgusr-02.fore.com> Date: Wed, 2 Aug 2000 12:50:15 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: MGCP Mailing List X-To: =?iso-8859-1?Q?=27Fran=E7ois_Berard=27?= To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Many vendors are presently working on MGCP products and RFC 2705 will > probably need to be updated in a near future (at least to > clarify a few > things). Is the ISC Mailing list the right place to do this? IETF can't really answer this, but I would say, yes, the ISC list is the place to discuss this. ISC is working on an update to 2705. > Are the ISC and > CableLabs mailing lists the only options for MGCP implementers? They are the ones that most people use I believe. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 2 15:36:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18785 for ; Wed, 2 Aug 2000 15:36:56 -0400 (EDT) Received: from standards (47.234.32.16:4294) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84616@standards.nortelnetworks.com>; Wed, 2 Aug 2000 15:24:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4543 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Aug 2000 15:24:58 -0400 Received: from web6404.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84604@standards.nortelnetworks.com>; Wed, 2 Aug 2000 15:14:57 -0400 Received: from [64.220.200.242] by web6404.mail.yahoo.com; Wed, 02 Aug 2000 12:26:13 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <20000802192613.17267.qmail@web6404.mail.yahoo.com> Date: Wed, 2 Aug 2000 12:26:13 -0700 Reply-To: =?iso-8859-1?q?S=20KA=20N?= Sender: "Media Gateway Control (megaco)" From: =?iso-8859-1?q?S=20KA=20N?= Subject: MG and DiffServ To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hi, Can you think of any relation between the MG and DiffServ? If a privately managed IP network is DiffServ compliant and suppose if the same network is going to be used for VoIP purposes also. Don't we require the MGs to be DiffServ compliant? Any help/comment would be appreciated. ...SKAN __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 2 16:38:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08578 for ; Wed, 2 Aug 2000 16:38:48 -0400 (EDT) Received: from standards (47.234.32.16:2479) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84639@standards.nortelnetworks.com>; Wed, 2 Aug 2000 16:26:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4610 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Aug 2000 16:26:59 -0400 Received: from repulse.cnchost.com (repulse.concentric.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84638@standards.nortelnetworks.com>; Wed, 2 Aug 2000 16:26:58 -0400 Received: from MATT.ascend.com (ts002d41.pit-pa.concentric.net [209.31.153.101]) by repulse.cnchost.com id QAA21318; Wed, 2 Aug 2000 16:37:48 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Errors-To: X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000802133530.00c20a30@pop3.ipverse.com> Date: Wed, 2 Aug 2000 13:36:56 -0700 Reply-To: Matt Holdrege Sender: "Media Gateway Control (megaco)" From: Matt Holdrege Subject: Re: MG and DiffServ X-To: S KA N To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <20000802192613.17267.qmail@web6404.mail.yahoo.com> At 12:26 PM 8/2/00 -0700, S KA N wrote: >Hi, > >Can you think of any relation between the MG and >DiffServ? > >If a privately managed IP network is DiffServ >compliant and suppose if the same network >is going to be used for VoIP purposes also. Don't >we require the MGs to be DiffServ compliant? Most MG's are already diffserv or TOS compliant. In any case you can't require a vendor to build something unless you plan to give them a lot of money. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 2 19:03:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27446 for ; Wed, 2 Aug 2000 19:03:02 -0400 (EDT) Received: from standards (47.234.32.16:1102) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB846CB@standards.nortelnetworks.com>; Wed, 2 Aug 2000 18:51:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4790 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Aug 2000 18:51:12 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB846BE@standards.nortelnetworks.com>; Wed, 2 Aug 2000 18:41:11 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e72MqTw28077 for ; Thu, 3 Aug 2000 00:52:29 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id AAA02037 for ; Thu, 3 Aug 2000 00:52:28 +0200 (MET DST) Received: from ericsson.com (rmt160143.am.ericsson.se [138.85.160.143]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id AAA07274 for ; Thu, 3 Aug 2000 00:52:26 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480BD1@zcard00g.ca.nortel.com> <3987501B.2B2F9C7C@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39882202.ED0D8EB@ericsson.com> Date: Wed, 2 Aug 2000 23:28:34 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Package descriptor for ROOT. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day all, I would have thought that as the "root termination" is not really a physical termination but relates to the MG as a whole that it would also support all the packages in a MG. ie. if you added a package to a termination you'd add it to the root termination. So I still support Brian's response. In effect you would get the union. Cheers, Christian Flemming Andreasen wrote: > > > > Tom-PT Taylor wrote: > > > > > > > The resolution of this question in the past (e.g. in Oslo) was that > > an audit of packages on ROOT only reveals those packages supported > > by the ROOT termination. > > Contrary to Brian's response, that was my expectation as well, not > least considering the following text in Section 6.2.5 (root > termination): > > "* an AuditValue return - to examine the values of properties and > statistics implemented on root" > > > -- Flemming > > > > > > > As far as I am concerned, the ultimate answer to the "auditing of > > ephemerals" question will be to define packages with ROOT > > termination properties which indicate the capability of the MG to > > support specific types of termination. These package properties > > could include naming patterns, interface identifiers (e.g. IPv4 or > > IPv6 addresses), and relevanr resource limits. Since I believe > > this, perhaps I should be the one to draw up first drafts of the > > packages I have in mind. > > > > -----Original Message----- > > From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM] > > Sent: Tuesday, August 01, 2000 8:26 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Package descriptor for ROOT. > > > > MGC if intends to "audit" packages supported by MG on ROOT, > > does > > the response from MG indicates the packages supported on ROOT > > termination or "UNION" of packages supported on different > > terminations in MG? > > -Madhubabu > > > -- > Flemming Andreasen Phone: +1 732 452 1667 > Cisco Systems Fax: +1 240 359 5839 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 2 19:28:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02873 for ; Wed, 2 Aug 2000 19:28:15 -0400 (EDT) Received: from standards (47.234.32.16:2810) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB846EE@standards.nortelnetworks.com>; Wed, 2 Aug 2000 19:16:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4853 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Aug 2000 19:16:33 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB846ED@standards.nortelnetworks.com>; Wed, 2 Aug 2000 19:06:33 -0400 Received: from cisco.com (rtp-dial-1-150.cisco.com [10.83.97.150]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id QAA06811; Wed, 2 Aug 2000 16:17:48 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480BD1@zcard00g.ca.nortel.com> <3987501B.2B2F9C7C@cisco.com> <39882202.ED0D8EB@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3988AD0B.4DE33914@cisco.com> Date: Wed, 2 Aug 2000 19:21:47 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: Package descriptor for ROOT. X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit So let me ask what you would do if asked to audit e.g. the EventsDescriptor on the ROOT termination ? There should at least be consistency between the answer to this question and package auditing on ROOT. -- Flemming Christian Groves wrote: > G'Day all, > > I would have thought that as the "root termination" is not really a > physical termination but relates to the MG as a whole that it would also > support all the packages in a MG. ie. if you added a package to a > termination you'd add it to the root termination. So I still support > Brian's response. In effect you would get the union. > > Cheers, Christian > > Flemming Andreasen wrote: > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > The resolution of this question in the past (e.g. in Oslo) was that > > > an audit of packages on ROOT only reveals those packages supported > > > by the ROOT termination. > > > > Contrary to Brian's response, that was my expectation as well, not > > least considering the following text in Section 6.2.5 (root > > termination): > > > > "* an AuditValue return - to examine the values of properties and > > statistics implemented on root" > > > > > > -- Flemming > > > > > > > > > > > > As far as I am concerned, the ultimate answer to the "auditing of > > > ephemerals" question will be to define packages with ROOT > > > termination properties which indicate the capability of the MG to > > > support specific types of termination. These package properties > > > could include naming patterns, interface identifiers (e.g. IPv4 or > > > IPv6 addresses), and relevanr resource limits. Since I believe > > > this, perhaps I should be the one to draw up first drafts of the > > > packages I have in mind. > > > > > > -----Original Message----- > > > From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM] > > > Sent: Tuesday, August 01, 2000 8:26 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Package descriptor for ROOT. > > > > > > MGC if intends to "audit" packages supported by MG on ROOT, > > > does > > > the response from MG indicates the packages supported on ROOT > > > termination or "UNION" of packages supported on different > > > terminations in MG? > > > -Madhubabu > > > > > -- > > Flemming Andreasen Phone: +1 732 452 1667 > > Cisco Systems Fax: +1 240 359 5839 > > -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 2 21:38:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09000 for ; Wed, 2 Aug 2000 21:37:59 -0400 (EDT) Received: from standards (47.234.32.16:1380) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84740@standards.nortelnetworks.com>; Wed, 2 Aug 2000 21:26:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4954 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Aug 2000 21:26:15 -0400 Received: from qhars002.nortel.com (47.101.112.102:49975) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8473F@standards.nortelnetworks.com>; Wed, 2 Aug 2000 21:26:15 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Thu, 3 Aug 2000 02:37:19 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Wed, 2 Aug 2000 20:34:47 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 2 Aug 2000 20:34:42 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480BE9@zcard00g.ca.nortel.com> Date: Wed, 2 Aug 2000 20:34:40 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: MG and DiffServ X-To: S KA N To: MEGACO@STANDARDS.NORTELNETWORKS.COM There's a difference between an operator's RFP requiring that their MGs support DiffServ and a protocol dependency on such support. Megaco has no such dependency. > -----Original Message----- > From: S KA N [SMTP:s_ka_n@YAHOO.COM] > Sent: Wednesday, August 02, 2000 3:26 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: MG and DiffServ > > Hi, > > Can you think of any relation between the MG and > DiffServ? > > If a privately managed IP network is DiffServ > compliant and suppose if the same network > is going to be used for VoIP purposes also. Don't > we require the MGs to be DiffServ compliant? > > Any help/comment would be appreciated. > > ...SKAN > > __________________________________________________ > Do You Yahoo!? > Kick off your party with Yahoo! Invites. > http://invites.yahoo.com/ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 2 22:15:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18997 for ; Wed, 2 Aug 2000 22:15:47 -0400 (EDT) Received: from standards (47.234.32.16:3038) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8476D@standards.nortelnetworks.com>; Wed, 2 Aug 2000 22:04:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5012 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Aug 2000 22:04:05 -0400 Received: from qhars002.nortel.com (47.101.112.102:51193) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8476C@standards.nortelnetworks.com>; Wed, 2 Aug 2000 22:04:05 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Thu, 3 Aug 2000 03:15:21 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Wed, 2 Aug 2000 22:04:38 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 2 Aug 2000 22:04:36 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480BEC@zcard00g.ca.nortel.com> Date: Wed, 2 Aug 2000 22:04:34 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Returning of multiple digit maps from MG. To: MEGACO@STANDARDS.NORTELNETWORKS.COM I actually noted this as an issue when we were in Last Call stage in the spring, but found that it had already been taken care of in the text. See the third paragraph of 7.2.5 AuditValue, which reads: The appropriate descriptors, with the current values for the Termination, are returned from AuditValue. Values appearing in multiple instances of a descriptor are defined to be alternate values supported, with each parameter in a descriptor considered independent. -----Original Message----- From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM] Sent: Tuesday, August 01, 2000 9:23 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Returning of multiple digit maps from MG. If MGC audits the global digit maps the reply from MG should include all the defined digit maps. The production for auditReturnParameter lists any of the possible descriptors returned from MG. But occurence of these descriptors shall not occur more than once except for digit map descriptor. This is not specified anywhere that except for digitmap descriptor no other descriptor can occur more than once. This should be specified in grammar. -Madhubabu Tom Taylor Lead Standards Developer Phone and FAX: +1 613 736 0961 E-mail: taylor@nortelnetworks.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 3 05:46:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08173 for ; Thu, 3 Aug 2000 05:46:15 -0400 (EDT) Received: from standards (47.234.32.16:2890) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8490A@standards.nortelnetworks.com>; Thu, 3 Aug 2000 5:34:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5532 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Aug 2000 05:34:29 -0400 Received: from mars.hss.co.in (202.54.26.197:40999) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84909@standards.nortelnetworks.com>; Thu, 3 Aug 2000 5:34:23 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e739kmq06036 for ; Thu, 3 Aug 2000 15:16:50 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256930.0034C251 ; Thu, 3 Aug 2000 15:06:16 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256930.0034C0A0.00@sandesh.hss.hns.com> Date: Thu, 3 Aug 2000 15:11:05 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Re: Package descriptor for ROOT. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Packages descriptor specifies the list of packages realized by a given termination. But if UNION of packages are used is it logical to say that packages like RTP,etc are realized by ROOT termination. And the association of packages for a given termination in no way is known by recieving a list of packages from MG. Do you mean to say that a RTP stream can be created on ROOT termination ?? -Madhubabu Christian Groves on 08/02/2000 06:58:34 PM Please respond to Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Madhu B Babu/HSS) Subject: Re: Package descriptor for ROOT. G'Day all, I would have thought that as the "root termination" is not really a physical termination but relates to the MG as a whole that it would also support all the packages in a MG. ie. if you added a package to a termination you'd add it to the root termination. So I still support Brian's response. In effect you would get the union. Cheers, Christian Flemming Andreasen wrote: > > > > Tom-PT Taylor wrote: > > > > > > > The resolution of this question in the past (e.g. in Oslo) was that > > an audit of packages on ROOT only reveals those packages supported > > by the ROOT termination. > > Contrary to Brian's response, that was my expectation as well, not > least considering the following text in Section 6.2.5 (root > termination): > > "* an AuditValue return - to examine the values of properties and > statistics implemented on root" > > > -- Flemming > > > > > > > As far as I am concerned, the ultimate answer to the "auditing of > > ephemerals" question will be to define packages with ROOT > > termination properties which indicate the capability of the MG to > > support specific types of termination. These package properties > > could include naming patterns, interface identifiers (e.g. IPv4 or > > IPv6 addresses), and relevanr resource limits. Since I believe > > this, perhaps I should be the one to draw up first drafts of the > > packages I have in mind. > > > > -----Original Message----- > > From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM] > > Sent: Tuesday, August 01, 2000 8:26 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Package descriptor for ROOT. > > > > MGC if intends to "audit" packages supported by MG on ROOT, > > does > > the response from MG indicates the packages supported on ROOT > > termination or "UNION" of packages supported on different > > terminations in MG? > > -Madhubabu > > > -- > Flemming Andreasen Phone: +1 732 452 1667 > Cisco Systems Fax: +1 240 359 5839 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 3 09:10:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23036 for ; Thu, 3 Aug 2000 09:10:26 -0400 (EDT) Received: from standards (47.234.32.16:1937) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8495D@standards.nortelnetworks.com>; Thu, 3 Aug 2000 8:58:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5629 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Aug 2000 08:58:22 -0400 Received: from mel.alcatel.fr (mail2.alcatel.fr) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8495C@standards.nortelnetworks.com>; Thu, 3 Aug 2000 8:58:22 -0400 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id PAA07950; Thu, 3 Aug 2000 15:09:03 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id PAA00309; Thu, 3 Aug 2000 15:08:11 +0200 (MET DST) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id PAA17556; Thu, 3 Aug 2000 15:09:27 +0200 (MET DST) Received: from ms.alcatel.fr ([188.9.247.87]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id PAA17278; Thu, 3 Aug 2000 15:09:24 +0200 (MET DST) X-Mailer: Mozilla 4.5 [fr] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480BE9@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39896F1E.F83BE01F@ms.alcatel.fr> Date: Thu, 3 Aug 2000 15:09:50 +0200 Reply-To: Thomas LEVY Sender: "Media Gateway Control (megaco)" From: Thomas LEVY Organization: Alcatel Subject: Re: MG and DiffServ X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, I am not quiet so definitive about that. It depends, what you mean with :"MGs support Diffserv". If you imagine a MG being able to handle a context wich modifies the QoS (i.e for Diffserv : to have output stream with packets having different DSCP than packets from input stream), you should rather express such a thing with Megaco (why not in the Stream Descriptor). I may also refer to Section 5.5 QoS/CoS from "Media Gateway Control Protocol Architecture and Requirements" document, it states that: "The protocol must support a means to change QoS during a connection...". So I believe that Megaco will have to consider this point. Any comments, Thomas LEVY, > There's a difference between an operator's RFP requiring that their MGs > support DiffServ and a protocol dependency on such support. Megaco has no > such dependency. > > > -----Original Message----- > > From: S KA N [SMTP:s_ka_n@YAHOO.COM] > > Sent: Wednesday, August 02, 2000 3:26 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: MG and DiffServ > > > > Hi, > > > > Can you think of any relation between the MG and > > DiffServ? > > > > If a privately managed IP network is DiffServ > > compliant and suppose if the same network > > is going to be used for VoIP purposes also. Don't > > we require the MGs to be DiffServ compliant? > > > > Any help/comment would be appreciated. > > > > ...SKAN > > > > __________________________________________________ > > Do You Yahoo!? > > Kick off your party with Yahoo! Invites. > > http://invites.yahoo.com/ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 3 09:53:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05179 for ; Thu, 3 Aug 2000 09:53:42 -0400 (EDT) Received: from standards (47.234.32.16:3746) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84991@standards.nortelnetworks.com>; Thu, 3 Aug 2000 9:41:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5696 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Aug 2000 09:41:52 -0400 Received: from qhars002.nortel.com (47.101.112.102:50419) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84990@standards.nortelnetworks.com>; Thu, 3 Aug 2000 9:41:52 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Thu, 3 Aug 2000 14:44:19 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Thu, 3 Aug 2000 08:41:12 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 3 Aug 2000 08:41:06 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480BEE@zcard00g.ca.nortel.com> Date: Thu, 3 Aug 2000 08:41:09 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: MG and DiffServ X-To: Thomas LEVY To: MEGACO@STANDARDS.NORTELNETWORKS.COM You are correct that packages should be drawn up (and/or SDP defined) to allow QOS parameter setting. Volunteers? > -----Original Message----- > From: Thomas LEVY [SMTP:thomas.levy@ms.alcatel.fr] > Sent: Thursday, August 03, 2000 9:10 AM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: MG and DiffServ > > Hi all, > > I am not quiet so definitive about that. > It depends, what you mean with :"MGs support Diffserv". > If you imagine a MG being able to handle a context wich modifies the QoS > (i.e > for Diffserv : to have output stream with packets having different DSCP > than > packets from input stream), you should rather express such a thing with > Megaco > (why not in the Stream Descriptor). > I may also refer to Section 5.5 QoS/CoS from "Media Gateway Control > Protocol > Architecture and Requirements" document, it states that: "The protocol > must > support a means to change QoS during a connection...". > So I believe that Megaco will have to consider this point. > > Any comments, > > Thomas LEVY, > > > There's a difference between an operator's RFP requiring that their MGs > > support DiffServ and a protocol dependency on such support. Megaco has > no > > such dependency. > > > > > -----Original Message----- > > > From: S KA N [SMTP:s_ka_n@YAHOO.COM] > > > Sent: Wednesday, August 02, 2000 3:26 PM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: MG and DiffServ > > > > > > Hi, > > > > > > Can you think of any relation between the MG and > > > DiffServ? > > > > > > If a privately managed IP network is DiffServ > > > compliant and suppose if the same network > > > is going to be used for VoIP purposes also. Don't > > > we require the MGs to be DiffServ compliant? > > > > > > Any help/comment would be appreciated. > > > > > > ...SKAN > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Kick off your party with Yahoo! Invites. > > > http://invites.yahoo.com/ > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 3 10:29:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20870 for ; Thu, 3 Aug 2000 10:29:44 -0400 (EDT) Received: from standards (47.234.32.16:1352) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB849E4@standards.nortelnetworks.com>; Thu, 3 Aug 2000 10:17:51 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5808 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Aug 2000 10:17:51 -0400 Received: from qhars002.nortel.com (47.101.112.102:55367) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB849E3@standards.nortelnetworks.com>; Thu, 3 Aug 2000 10:17:50 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Thu, 3 Aug 2000 15:21:32 +0100 Received: from zcard015.ca.nortel.com (actually zcard015) by ertpg14e1.nortelnetworks.com; Thu, 3 Aug 2000 10:21:02 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 3 Aug 2000 10:21:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFFD56.071F74A0" Message-ID: Date: Thu, 3 Aug 2000 10:20:51 -0400 Reply-To: Sophia Scoggins Sender: "Media Gateway Control (megaco)" From: Sophia Scoggins Subject: draft-scoggins-megaco-pktnetpkg-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01BFFD56.071F74A0 Content-Type: text/plain; charset="iso-8859-1" A new packetnetwork package from Michael Brown and myself will be posted in the megaco web site soon. I will send it to Tom Taylor for posting. This packetnetwork package is to allow the MGC to not aware of the bearer type for asking to establish a packet network connection. In the case of IP connectionless network, the package can be used to reserve RTP ports, but without the MGC to be aware of specific bearer dependent commands. Regards, Sophia For Mike Brown and myself ------_=_NextPart_001_01BFFD56.071F74A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-scoggins-megaco-pktnetpkg-00.txt

A new packetnetwork = package<draft-scoggins-megaco-pktnetpkg-00.txt> from Michael = Brown and myself will be posted in the megaco web site soon. I will = send it to Tom Taylor for posting.

This packetnetwork package is to allow = the MGC to not aware of the bearer type for asking to establish a = packet network connection. In the case of IP connectionless network, = the package can be used to reserve RTP ports, but without the MGC to be = aware of specific bearer dependent commands.


Regards, Sophia
For Mike Brown and myself

------_=_NextPart_001_01BFFD56.071F74A0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 3 12:31:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11945 for ; Thu, 3 Aug 2000 12:31:24 -0400 (EDT) Received: from standards (47.234.32.16:2167) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84A36@standards.nortelnetworks.com>; Thu, 3 Aug 2000 12:19:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5909 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Aug 2000 12:19:25 -0400 Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84A35@standards.nortelnetworks.com>; Thu, 3 Aug 2000 12:19:25 -0400 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA01788; Thu, 3 Aug 2000 09:31:02 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA18164; Thu, 3 Aug 2000 09:30:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <28560036253BD41191A10000F8BCBD11480BEE@zcard00g.ca.nortel.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Message-ID: <14729.40509.57507.678338@thomasm-u1.cisco.com> Date: Thu, 3 Aug 2000 09:30:53 -0700 Reply-To: Michael Thomas Sender: "Media Gateway Control (megaco)" From: Michael Thomas Subject: Re: MG and DiffServ X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <28560036253BD41191A10000F8BCBD11480BEE@zcard00g.ca.nortel.com> Content-Transfer-Encoding: 7bit Tom-PT Taylor writes: > You are correct that packages should be drawn up (and/or SDP defined) to > allow QOS parameter setting. Volunteers? If you ask me, it should be a property of the RTP package. Same with RSVP if it's not already there. Mike > > > -----Original Message----- > > From: Thomas LEVY [SMTP:thomas.levy@ms.alcatel.fr] > > Sent: Thursday, August 03, 2000 9:10 AM > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: MG and DiffServ > > > > Hi all, > > > > I am not quiet so definitive about that. > > It depends, what you mean with :"MGs support Diffserv". > > If you imagine a MG being able to handle a context wich modifies the QoS > > (i.e > > for Diffserv : to have output stream with packets having different DSCP > > than > > packets from input stream), you should rather express such a thing with > > Megaco > > (why not in the Stream Descriptor). > > I may also refer to Section 5.5 QoS/CoS from "Media Gateway Control > > Protocol > > Architecture and Requirements" document, it states that: "The protocol > > must > > support a means to change QoS during a connection...". > > So I believe that Megaco will have to consider this point. > > > > Any comments, > > > > Thomas LEVY, > > > > > There's a difference between an operator's RFP requiring that their MGs > > > support DiffServ and a protocol dependency on such support. Megaco has > > no > > > such dependency. > > > > > > > -----Original Message----- > > > > From: S KA N [SMTP:s_ka_n@YAHOO.COM] > > > > Sent: Wednesday, August 02, 2000 3:26 PM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: MG and DiffServ > > > > > > > > Hi, > > > > > > > > Can you think of any relation between the MG and > > > > DiffServ? > > > > > > > > If a privately managed IP network is DiffServ > > > > compliant and suppose if the same network > > > > is going to be used for VoIP purposes also. Don't > > > > we require the MGs to be DiffServ compliant? > > > > > > > > Any help/comment would be appreciated. > > > > > > > > ...SKAN > > > > > > > > __________________________________________________ > > > > Do You Yahoo!? > > > > Kick off your party with Yahoo! Invites. > > > > http://invites.yahoo.com/ > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 3 12:40:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15625 for ; Thu, 3 Aug 2000 12:40:42 -0400 (EDT) Received: from standards (47.234.32.16:2167) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84A51@standards.nortelnetworks.com>; Thu, 3 Aug 2000 12:28:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5908 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Aug 2000 12:28:49 -0400 Received: from relay1.alcatel.be (alc119.alcatel.be) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84A34@standards.nortelnetworks.com>; Thu, 3 Aug 2000 12:18:48 -0400 Received: from btm16s.se.bel.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id e73GUPP06341 for ; Thu, 3 Aug 2000 18:30:29 +0200 (MET DST) Received: from alcatel.be (btmpfc [138.203.32.78]) by btm16s.se.bel.alcatel.be (8.8.8+Sun/8.8.8+SUN) with ESMTP id SAA23641 for ; Thu, 3 Aug 2000 18:30:01 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480B48@zcard00g.ca.nortel.com> Content-Type: multipart/alternative; boundary="------------7DF512D0202B605AC1BF8906" Message-ID: <39899E09.FCA23E62@alcatel.be> Date: Thu, 3 Aug 2000 18:30:01 +0200 Reply-To: Nicolas Dramais Sender: "Media Gateway Control (megaco)" From: Nicolas Dramais Organization: Alcatel Subject: Re: draft-brown-supplpkgs-00.txt + special dial tone To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------7DF512D0202B605AC1BF8906 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hello, just two points : 1) what is going on with the draft-brown-supplpkgs-00.txt ? Although Tom has stated his will to make it a Megaco work item, I cannot see it appearing at Megaco work page : http://www.ietf.org/ids.by.wg/megaco.html 2) actually not a question but rather a proposal : special dial tone some supplementary services activated in a given user's profile may require the sending of a some kind of "special dial tone" different from the "standard dial tone" towards the user to remind him that a service is activated hopefully before he dials anything in. - one cannot create this special dial tone (spdt) starting from the dial tone signal defined in the Call Progress Tones Generator package presented in draft-ietf-megaco-merged-01.txt since its definition doesn't foresee additional parameters like frequency or cadence. - however, the spdt may dynamically be created on call basis starting from the generic and standardized dial tone and changing the frequency/cadence thanks to the Dynamic Tone Definition package presented in draft-ietf-megaco-h248j-00.txt. Although this seems to give a flexible solution, I think it is worth adding an official SignalID for a special dial tone within the Basic Services Tones Generation Package presented in draft-brown-supplpkgs-00.txt so that the same standardized SignalID is used all over the world for all enhanced service implementations which make use of such kind of special dial tone. I would define it in the following way: Basic Services Tones Generation Package (draft-brown-supplpkgs-00.txt): PackageID: srvtn Special Dial Tone SignalID: spdt (0x00??) Generate special dial tone. The physical characteristics of special dial tone is available in the gateway. Signal Type: Timeout. Duration: Provisioned. Additional Parameters : None. Any further input is warmly welcome. Kind regards, Nicolas Dramais, NGN - Alcatel SRD Antwerp, Belgium. Tom-PT Taylor wrote: > Please state any objections to making draft-brown-supplpkgs-00.txt a Megaco > work item. If I do not see any by Thursday I shall make it so. > > Tom Taylor > Lead Standards Developer > Phone and FAX: +1 613 736 0961 > E-mail: taylor@nortelnetworks.com --------------7DF512D0202B605AC1BF8906 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit hello,

just two points :

1) what is going on with the draft-brown-supplpkgs-00.txt ? Although Tom has stated his will to make it a Megaco work item, I cannot see it appearing at Megaco work page :
http://www.ietf.org/ids.by.wg/megaco.html

2) actually not a question but rather a proposal : special dial tone

some supplementary services activated in a given user's profile may require the sending of a some kind of "special dial tone" different from the "standard dial tone" towards the user to remind him that a service is activated hopefully before he dials anything in.

- one cannot create this special dial tone (spdt) starting from the dial tone signal defined in the Call Progress Tones Generator package presented in draft-ietf-megaco-merged-01.txt since its definition doesn't foresee additional parameters like frequency or cadence.

- however, the spdt may dynamically be created on call basis starting from the generic and standardized dial tone and changing the frequency/cadence thanks to the Dynamic Tone Definition package presented in draft-ietf-megaco-h248j-00.txt.
Although this seems to give a flexible solution, I think it is worth adding an official SignalID for a special dial tone within the Basic Services Tones Generation Package presented in draft-brown-supplpkgs-00.txt so that the same standardized SignalID is used all over the world for all enhanced service implementations which make use of such kind of special dial tone.

I would define it in the following way:
Basic Services Tones Generation Package (draft-brown-supplpkgs-00.txt):
PackageID: srvtn

Special Dial Tone
SignalID: spdt (0x00??)
Generate special dial tone. The physical characteristics of special dial tone is available in the gateway.
Signal Type: Timeout.
Duration: Provisioned.
Additional Parameters : None.

Any further input is warmly welcome.

Kind regards,
Nicolas Dramais, NGN - Alcatel SRD Antwerp, Belgium.
 
 
 

Tom-PT Taylor wrote:

Please state any objections to making draft-brown-supplpkgs-00.txt a Megaco
work item.  If I do not see any by Thursday I shall make it so.

Tom Taylor
Lead Standards Developer
Phone and FAX: +1 613 736 0961
E-mail: taylor@nortelnetworks.com

--------------7DF512D0202B605AC1BF8906-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 3 13:34:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04497 for ; Thu, 3 Aug 2000 13:34:33 -0400 (EDT) Received: from standards (47.234.32.16:4885) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84AC0@standards.nortelnetworks.com>; Thu, 3 Aug 2000 13:22:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6093 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Aug 2000 13:22:42 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84ABF@standards.nortelnetworks.com>; Thu, 3 Aug 2000 13:12:42 -0400 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Thu Aug 3 13:22:20 EDT 2000 Received: from zydeco.research.bell-labs.com ([135.104.120.150]) by grubby; Thu Aug 3 13:22:19 EDT 2000 Received: from street-hawk (street-hawk.research.bell-labs.com [135.104.120.76]) by zydeco.research.bell-labs.com (8.9.1/8.9.1) with SMTP id NAA00818; Thu, 3 Aug 2000 13:22:19 -0400 (EDT) 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Message-ID: <001f01bffd71$207a9720$4c786887@street-hawk.research.bell-labs.com> Date: Thu, 3 Aug 2000 13:34:50 -0400 Reply-To: Jagadish Kumar Sender: "Media Gateway Control (megaco)" From: Jagadish Kumar Subject: Issue regarding Gateway no loger able to sustain existing connections X-cc: jsegers@lucent.com, ggf@lucent.com, Sujay rao , Tom houghton , Srivatsan Nadathur , Raju To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, In H.248 when gateway is no longer able to maintain existing connections in a context or across contexts (for whatever reason it may be) how is it going to inform MGC regarding this. In MGCP/SGCP when something like this happens the Gateway can send delete connection command to the Gateway Controller. Is there is any equivalent scheme on this in H.248 Can somebody educate me on this??? I believe that Notify or Service change commands cannot be used for this condition. Thanks in advance. Jagadish From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 3 17:17:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14110 for ; Thu, 3 Aug 2000 17:17:49 -0400 (EDT) Received: from standards (47.234.32.16:1678) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84BEE@standards.nortelnetworks.com>; Thu, 3 Aug 2000 17:06:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6476 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Aug 2000 17:06:05 -0400 Received: from server.voxpath.com (gtw83.quickarrow.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84BE0@standards.nortelnetworks.com>; Thu, 3 Aug 2000 16:56:05 -0400 Received: by server.voxpath.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Aug 2000 16:08:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFFD8E.E7A0FBE0" Message-ID: <87E8BC00F62D544694FA8A369150BBB2E7CA@server.voxpath.com> Date: Thu, 3 Aug 2000 16:07:57 -0500 Reply-To: Jason Preston Sender: "Media Gateway Control (megaco)" From: Jason Preston Subject: SUBSCRIBE To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01BFFD8E.E7A0FBE0 Content-Type: text/plain; charset="iso-8859-1" SUBSCRIBE MEGACO ------_=_NextPart_000_01BFFD8E.E7A0FBE0 Content-Type: application/octet-stream; name="Jason Preston.vcf" Content-Disposition: attachment; filename="Jason Preston.vcf" BEGIN:VCARD VERSION:2.1 N:Preston;Jason FN:Jason Preston ORG:Voxpath Networks TEL;WORK;VOICE:(512)401-8200 x105 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;11675 Jollyville Rd=0D=0ASuite 300;Austin;TX;78759 LABEL;WORK;ENCODING=QUOTED-PRINTABLE:11675 Jollyville Rd=0D=0ASuite 300=0D=0AAustin, TX 78759 EMAIL;PREF;INTERNET:jpreston@voxpath.com REV:20000707T192720Z END:VCARD ------_=_NextPart_000_01BFFD8E.E7A0FBE0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 3 17:54:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24387 for ; Thu, 3 Aug 2000 17:54:38 -0400 (EDT) Received: from standards (47.234.32.16:1678) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84C21@standards.nortelnetworks.com>; Thu, 3 Aug 2000 17:42:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6544 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Aug 2000 17:42:50 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84C17@standards.nortelnetworks.com>; Thu, 3 Aug 2000 17:32:50 -0400 Received: from cisco.com (rtp-dial-1-31.cisco.com [10.83.97.31]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id OAA16211; Thu, 3 Aug 2000 14:44:05 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF67866D@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3989B800.4732FFA8@cisco.com> Date: Thu, 3 Aug 2000 14:20:48 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: MGCP Mailing List X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "Rosen, Brian" wrote: > > Many vendors are presently working on MGCP products and RFC 2705 will > > probably need to be updated in a near future (at least to > > clarify a few > > things). Is the ISC Mailing list the right place to do this? > IETF can't really answer this, but I would say, yes, the ISC list is the > place > to discuss this. ISC is working on an update to 2705. Also, you might want to use "mgcp@pulver.com". Send mail to "majordomo@pulver.com" with "subscribe mgcp" in the body to subscribe. > > > > Are the ISC and > > CableLabs mailing lists the only options for MGCP implementers? > They are the ones that most people use I believe. "mgcp@pulver.com" is used as well. -- Flemming > > > Brian -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 3 17:54:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24391 for ; Thu, 3 Aug 2000 17:54:38 -0400 (EDT) Received: from standards (47.234.32.16:1678) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84C2C@standards.nortelnetworks.com>; Thu, 3 Aug 2000 17:43:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6545 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Aug 2000 17:43:05 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84C18@standards.nortelnetworks.com>; Thu, 3 Aug 2000 17:33:05 -0400 Received: from cisco.com (rtp-dial-1-31.cisco.com [10.83.97.31]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id OAA16320; Thu, 3 Aug 2000 14:44:16 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480BE9@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3989B8CB.A6CFC364@cisco.com> Date: Thu, 3 Aug 2000 14:24:11 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: MG and DiffServ X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Nevertheless, having the ability to specify which diffserv codepoint an MG should use for a given media stream is fairly useful. -- Flemming Tom-PT Taylor wrote: > There's a difference between an operator's RFP requiring that their MGs > support DiffServ and a protocol dependency on such support. Megaco has no > such dependency. > > > -----Original Message----- > > From: S KA N [SMTP:s_ka_n@YAHOO.COM] > > Sent: Wednesday, August 02, 2000 3:26 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: MG and DiffServ > > > > Hi, > > > > Can you think of any relation between the MG and > > DiffServ? > > > > If a privately managed IP network is DiffServ > > compliant and suppose if the same network > > is going to be used for VoIP purposes also. Don't > > we require the MGs to be DiffServ compliant? > > > > Any help/comment would be appreciated. > > > > ...SKAN > > > > __________________________________________________ > > Do You Yahoo!? > > Kick off your party with Yahoo! Invites. > > http://invites.yahoo.com/ -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 3 19:44:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28020 for ; Thu, 3 Aug 2000 19:44:43 -0400 (EDT) Received: from standards (47.234.32.16:3534) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84C86@standards.nortelnetworks.com>; Thu, 3 Aug 2000 19:32:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6686 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Aug 2000 19:32:54 -0400 Received: from web6402.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84C84@standards.nortelnetworks.com>; Thu, 3 Aug 2000 19:22:53 -0400 Received: from [64.220.200.242] by web6402.mail.yahoo.com; Thu, 03 Aug 2000 16:34:14 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <20000803233414.2463.qmail@web6402.mail.yahoo.com> Date: Thu, 3 Aug 2000 16:34:14 -0700 Reply-To: =?iso-8859-1?q?S=20KA=20N?= Sender: "Media Gateway Control (megaco)" From: =?iso-8859-1?q?S=20KA=20N?= Subject: Re: MG and DiffServ X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hi There, If you can recall the meaning of DiffServ, its for implementing differentiated services in the Internet. Which basically means giving QoS to specially marked data traffic. Now if you look at the requirements specified in Section 5.5 of RFC2805, it says that the MGCP protocol should support the ability to specify QoS for the connection between MGs, etc. Any comment. ...SKAN > There's a difference between an operator's RFP > requiring that their MGs > support DiffServ and a protocol dependency on such > support. Megaco has no > such dependency. > > > -----Original Message----- > > From: S KA N [SMTP:s_ka_n@YAHOO.COM] > > Sent: Wednesday, August 02, 2000 3:26 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: MG and DiffServ > > > > Hi, > > > > Can you think of any relation between the MG and > > DiffServ? > > > > If a privately managed IP network is DiffServ > > compliant and suppose if the same network > > is going to be used for VoIP purposes also. Don't > > we require the MGs to be DiffServ compliant? > > > > Any help/comment would be appreciated. > > > > ...SKAN __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 3 21:04:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21308 for ; Thu, 3 Aug 2000 21:04:22 -0400 (EDT) Received: from standards (47.234.32.16:1644) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84CB6@standards.nortelnetworks.com>; Thu, 3 Aug 2000 20:52:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6744 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Aug 2000 20:52:38 -0400 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84CB5@standards.nortelnetworks.com>; Thu, 3 Aug 2000 20:52:38 -0400 Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA21418; Thu, 3 Aug 2000 18:04:15 -0700 (PDT) Received: from bfoster-nt (bfoster-dsl3.cisco.com [10.19.86.12]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id AFS11295; Thu, 3 Aug 2000 18:04:01 -0700 (PDT) X-Sender: bfoster@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.2.0.58.20000803175917.02209770@mira-sjc5-1.cisco.com> Date: Thu, 3 Aug 2000 18:01:22 -0700 Reply-To: Bill Foster Sender: "Media Gateway Control (megaco)" From: Bill Foster Subject: Re: MG and DiffServ X-To: S KA N To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <20000803233414.2463.qmail@web6402.mail.yahoo.com> Given that the MGC is often defining policy and QoS use is an important policy, it would be useful to have the capability. At 04:34 PM 8/3/00 -0700, S KA N wrote: >Hi There, > >If you can recall the meaning of DiffServ, its for >implementing differentiated services in the Internet. >Which basically means giving QoS to specially marked >data traffic. Now if you look at the requirements >specified in Section 5.5 of RFC2805, it says that >the MGCP protocol should support the ability to >specify QoS for the connection between MGs, etc. > >Any comment. > >...SKAN > > > > > There's a difference between an operator's RFP > > requiring that their MGs > > support DiffServ and a protocol dependency on such > > support. Megaco has no > > such dependency. > > > > > -----Original Message----- > > > From: S KA N [SMTP:s_ka_n@YAHOO.COM] > > > Sent: Wednesday, August 02, 2000 3:26 PM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: MG and DiffServ > > > > > > Hi, > > > > > > Can you think of any relation between the MG and > > > DiffServ? > > > > > > If a privately managed IP network is DiffServ > > > compliant and suppose if the same network > > > is going to be used for VoIP purposes also. Don't > > > we require the MGs to be DiffServ compliant? > > > > > > Any help/comment would be appreciated. > > > > > > ...SKAN > > >__________________________________________________ >Do You Yahoo!? >Kick off your party with Yahoo! Invites. >http://invites.yahoo.com/ ----------------------------- Bill Foster Phone: (408) 527-8791 Page: (800) 365-4578 Fax: (781) 998-6492 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 3 22:53:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08851 for ; Thu, 3 Aug 2000 22:53:23 -0400 (EDT) Received: from standards (47.234.32.16:1141) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84D07@standards.nortelnetworks.com>; Thu, 3 Aug 2000 22:41:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6838 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Aug 2000 22:41:35 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84D01@standards.nortelnetworks.com>; Thu, 3 Aug 2000 22:31:34 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e742gow12639; Fri, 4 Aug 2000 04:42:53 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA28560; Fri, 4 Aug 2000 04:42:49 +0200 (MET DST) Received: from ericsson.com (rmt160166.am.ericsson.se [138.85.160.166]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA08929; Fri, 4 Aug 2000 04:42:47 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480BD1@zcard00g.ca.nortel.com> <3987501B.2B2F9C7C@cisco.com> <39882202.ED0D8EB@ericsson.com> <3988AD0B.4DE33914@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39897AB2.561B9FA5@ericsson.com> Date: Thu, 3 Aug 2000 23:59:14 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Package descriptor for ROOT. X-To: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Flemming, I don't think I made myself clear. I don't support union as an automatic option as you allude to the EventsDescriptor below. I am saying that if you have a MG that supports a number of packages that you would provision the Root Termination with this complete set. I assume this would be done as the Root Termination represents the gateway. So you get back what is on root, not all the terminations in the MG. But having said that you could equally do an audit ALL and wildcard response. Cheers, Christian Flemming Andreasen wrote: > > So let me ask what you would do if asked to audit e.g. the EventsDescriptor > on the ROOT termination ? There should at least be consistency between the > answer to this question and package auditing on ROOT. > > -- Flemming > > Christian Groves wrote: > > > G'Day all, > > > > I would have thought that as the "root termination" is not really a > > physical termination but relates to the MG as a whole that it would also > > support all the packages in a MG. ie. if you added a package to a > > termination you'd add it to the root termination. So I still support > > Brian's response. In effect you would get the union. > > > > Cheers, Christian > > > > Flemming Andreasen wrote: > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > > The resolution of this question in the past (e.g. in Oslo) was that > > > > an audit of packages on ROOT only reveals those packages supported > > > > by the ROOT termination. > > > > > > Contrary to Brian's response, that was my expectation as well, not > > > least considering the following text in Section 6.2.5 (root > > > termination): > > > > > > "* an AuditValue return - to examine the values of properties and > > > statistics implemented on root" > > > > > > > > > -- Flemming > > > > > > > > > > > > > > > > > As far as I am concerned, the ultimate answer to the "auditing of > > > > ephemerals" question will be to define packages with ROOT > > > > termination properties which indicate the capability of the MG to > > > > support specific types of termination. These package properties > > > > could include naming patterns, interface identifiers (e.g. IPv4 or > > > > IPv6 addresses), and relevanr resource limits. Since I believe > > > > this, perhaps I should be the one to draw up first drafts of the > > > > packages I have in mind. > > > > > > > > -----Original Message----- > > > > From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM] > > > > Sent: Tuesday, August 01, 2000 8:26 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Package descriptor for ROOT. > > > > > > > > MGC if intends to "audit" packages supported by MG on ROOT, > > > > does > > > > the response from MG indicates the packages supported on ROOT > > > > termination or "UNION" of packages supported on different > > > > terminations in MG? > > > > -Madhubabu > > > > > > > -- > > > Flemming Andreasen Phone: +1 732 452 1667 > > > Cisco Systems Fax: +1 240 359 5839 > > > > > -- > Flemming Andreasen Phone: +1 732 452 1667 > Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 00:29:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10691 for ; Fri, 4 Aug 2000 00:29:19 -0400 (EDT) Received: from standards (47.234.32.16:3412) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84D49@standards.nortelnetworks.com>; Fri, 4 Aug 2000 0:17:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6927 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 00:17:32 -0400 Received: from mars.hss.co.in (202.54.26.197:50957) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84D48@standards.nortelnetworks.com>; Fri, 4 Aug 2000 0:17:30 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e744Tsq23957 for ; Fri, 4 Aug 2000 10:00:01 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256931.0017BD3A ; Fri, 4 Aug 2000 09:49:17 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256931.0017BA67.00@sandesh.hss.hns.com> Date: Fri, 4 Aug 2000 09:53:42 +0530 Reply-To: rezhirpavai@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: rezhirpavai@HSS.HNS.COM Subject: Query on the port numbers used To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello, Section 9 of draft-ietf-megaco-merged-01.txt specifies that port number 2944 should be the default port used for text encoding and 2945 should be default port for binary-encoding. It later says that these port numbers may be changed using the ServiceChangeAddress. On specifying different port numbers, do we have to maintain the same strategy of having different port numbers for text-encoding and binary-encoding or can the same port be used for both text and binary encoding. MGC shall identify whether to decode the text encoded data or binary encoded data based on the local+remote port and IP address pair. Regards, R. Ezhirpavai From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 00:35:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12602 for ; Fri, 4 Aug 2000 00:35:31 -0400 (EDT) Received: from standards (47.234.32.16:3412) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84D63@standards.nortelnetworks.com>; Fri, 4 Aug 2000 0:23:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6926 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 00:23:45 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84D47@standards.nortelnetworks.com>; Fri, 4 Aug 2000 0:13:45 -0400 Received: from cisco.com (rtp-dial-1-155.cisco.com [10.83.97.155]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id VAA24365; Thu, 3 Aug 2000 21:24:56 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480BEE@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <398A4687.3D5C7C14@cisco.com> Date: Fri, 4 Aug 2000 00:28:55 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: MG and DiffServ X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit 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 > > > > -----Original Message----- > > From: Thomas LEVY [SMTP:thomas.levy@ms.alcatel.fr] > > Sent: Thursday, August 03, 2000 9:10 AM > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: MG and DiffServ > > > > Hi all, > > > > I am not quiet so definitive about that. > > It depends, what you mean with :"MGs support Diffserv". > > If you imagine a MG being able to handle a context wich modifies the QoS > > (i.e > > for Diffserv : to have output stream with packets having different DSCP > > than > > packets from input stream), you should rather express such a thing with > > Megaco > > (why not in the Stream Descriptor). > > I may also refer to Section 5.5 QoS/CoS from "Media Gateway Control > > Protocol > > Architecture and Requirements" document, it states that: "The protocol > > must > > support a means to change QoS during a connection...". > > So I believe that Megaco will have to consider this point. > > > > Any comments, > > > > Thomas LEVY, > > > > > There's a difference between an operator's RFP requiring that their MGs > > > support DiffServ and a protocol dependency on such support. Megaco has > > no > > > such dependency. > > > > > > > -----Original Message----- > > > > From: S KA N [SMTP:s_ka_n@YAHOO.COM] > > > > Sent: Wednesday, August 02, 2000 3:26 PM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: MG and DiffServ > > > > > > > > Hi, > > > > > > > > Can you think of any relation between the MG and > > > > DiffServ? > > > > > > > > If a privately managed IP network is DiffServ > > > > compliant and suppose if the same network > > > > is going to be used for VoIP purposes also. Don't > > > > we require the MGs to be DiffServ compliant? > > > > > > > > Any help/comment would be appreciated. > > > > > > > > ...SKAN > > > > > > > > __________________________________________________ > > > > Do You Yahoo!? > > > > Kick off your party with Yahoo! Invites. > > > > http://invites.yahoo.com/ > > -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 01:27:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04058 for ; Fri, 4 Aug 2000 01:27:49 -0400 (EDT) Received: from standards (47.234.32.16:2417) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84DAA@standards.nortelnetworks.com>; Fri, 4 Aug 2000 1:15:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7039 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 01:15:59 -0400 Received: from marie.nada.co.kr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84D9D@standards.nortelnetworks.com>; Fri, 4 Aug 2000 1:05:58 -0400 Received: from vctest1 ([192.168.1.153]) by marie.nada.co.kr (8.9.3/8.9.3) with SMTP id OAA31029 for ; Fri, 4 Aug 2000 14:20:57 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CE_01BFFE1E.F0585CE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: <00d101bffdd3$811d6fa0$9901a8c0@nadatel.com> Date: Fri, 4 Aug 2000 14:19:02 +0900 Reply-To: Junyoung Heo Sender: "Media Gateway Control (megaco)" From: Junyoung Heo Subject: About mixing and topology To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_00CE_01BFFE1E.F0585CE0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SSBoYXZlIGp1c3QgcmVhZCBtZWdhY28gZHJhZnQgZG9jdW1uZXQuDQpJIHdpbGwgdXNlIG1lZ2Fj byBhcyBwcm90b2NvbCBiZXR3ZWVuIE1DIGFuZCBNUC4NCg0KSSBjaG9vc2UgbWVnYWNvIGJlY2F1 c2UgaXRzIHRvcG9sb2d5IHByb3BlcnR5Lg0KQnV0LCBJIGNhbid0IGZpbmQgaG93IHRvIGRlc2Ny aWJlIHRvcG9sb2d5IHRvIGVuYWJsZSBtaXhpbmcgYW1vbmcgdGVybWluYXRpb25zJyBkYXRhLg0K DQpIb3cgY2FuIEkgbWFrZSBpdD8NCg0KUmVnYXJkcywNCg0KSnVueW91bmcgSGVvDQoyMDAwLzA4 LzA0DQpLT1JFQQ0KDQo= ------=_NextPart_000_00CE_01BFFE1E.F0585CE0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MjAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgaGF2ZSBqdXN0 IHJlYWQgbWVnYWNvIGRyYWZ0IGRvY3VtbmV0LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPkkgd2lsbCB1c2UgbWVnYWNvIGFzJm5ic3A7cHJvdG9jb2wgYmV0d2VlbiBNQyBhbmQgDQpN UC48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSBj aG9vc2UgbWVnYWNvIGJlY2F1c2UgaXRzIHRvcG9sb2d5IHByb3BlcnR5LjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPkJ1dCwgSSBjYW4ndCBmaW5kIGhvdyB0byBkZXNjcmliZSB0b3Bv bG9neSB0byBlbmFibGUgbWl4aW5nIA0KYW1vbmcgdGVybWluYXRpb25zJyBkYXRhLjwvRk9OVD48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5Ib3cgY2FuIEkmbmJz cDttYWtlIGl0PzwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNp emU9Mj5SZWdhcmRzLDxCUj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5KdW55b3Vu ZyBIZW88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4yMDAwLzA4LzA0PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+S09SRUE8QlI+PC9ESVY+PC9GT05UPjwvQk9EWT48L0hU TUw+DQo= ------=_NextPart_000_00CE_01BFFE1E.F0585CE0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 08:07:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10193 for ; Fri, 4 Aug 2000 08:07:40 -0400 (EDT) Received: from standards (47.234.32.16:4312) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84F2E@standards.nortelnetworks.com>; Fri, 4 Aug 2000 7:55:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7564 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 07:55:41 -0400 Received: from mars.hss.co.in (202.54.26.197:60491) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84F2D@standards.nortelnetworks.com>; Fri, 4 Aug 2000 7:55:34 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e74C7mq08178 for ; Fri, 4 Aug 2000 17:37:54 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256931.0041A70D ; Fri, 4 Aug 2000 17:27:06 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256931.0041A51E.00@sandesh.hss.hns.com> Date: Fri, 4 Aug 2000 17:27:00 +0530 Reply-To: rpatil@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Rajendra Patil Subject: Calling Line Identification To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, How MEGACOsupports CLID display for residential gateway ? Thanks/ Rajendra From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 08:30:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15024 for ; Fri, 4 Aug 2000 08:30:01 -0400 (EDT) Received: from standards (47.234.32.16:4473) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84F50@standards.nortelnetworks.com>; Fri, 4 Aug 2000 8:18:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7606 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 08:18:11 -0400 Received: from mars.hss.co.in (202.54.26.197:60911) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84F4F@standards.nortelnetworks.com>; Fri, 4 Aug 2000 8:17:57 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e74CUCq08767 for ; Fri, 4 Aug 2000 18:00:18 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256931.0043B5E3 ; Fri, 4 Aug 2000 17:49:34 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256931.0043B470.00@sandesh.hss.hns.com> Date: Fri, 4 Aug 2000 17:53:05 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: RequestId in observed events descriptor. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, what is the RequestId that needs to be sent from MG when "observedevents" are Audited? In section 7.1.17 its specifies that "ObservedEvents contains the RequestIdentifier of the EventsDescriptor that triggered the notification" but this notification of observed events is not triggered by any events descriptor. and the event buffer descriptor doesnot have a requestid field. -Madhubabu. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 09:29:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03272 for ; Fri, 4 Aug 2000 09:29:27 -0400 (EDT) Received: from standards (47.234.32.16:2708) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84F83@standards.nortelnetworks.com>; Fri, 4 Aug 2000 9:17:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7672 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 09:17:10 -0400 Received: from diablo.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84F82@standards.nortelnetworks.com>; Fri, 4 Aug 2000 9:17:10 -0400 Received: from jmpolk-8k (ssh.cisco.com [171.69.10.34]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id GAA29793; Fri, 4 Aug 2000 06:28:30 -0700 (PDT) X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 References: <20000803233414.2463.qmail@web6402.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3244473==_.ALT" Message-ID: <4.1.20000804075747.01f2b440@diablo.cisco.com> Date: Fri, 4 Aug 2000 08:28:26 -0500 Reply-To: "James M. Polk" Sender: "Media Gateway Control (megaco)" From: "James M. Polk" Subject: Re: MG and DiffServ X-To: Bill Foster To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4.2.0.58.20000803175917.02209770@mira-sjc5-1.cisco.com> --=====================_3244473==_.ALT Content-Type: text/plain; charset="us-ascii" All Shouldn't this be defined by other mechanisms by default? For example, typically the MG is dumb and requires a config image from some TFTP server. A template config is usually utilized that should set the default DSCP to a value that likely won't change. This isn't a Protocol issue, I don't think, it's a semantics issue. Another example, the port the MG is physically connected to on the Enet Switch sets the traffic to a specific Voice VLAN. Again, this isn't a Protocol issue. Another example, the Enet Switch knows that a MG is what's attached to a specific port and sets all incoming traffic to a defined DSCP value -- again, not a Protocol issue. I think, typically, a Protocol deals with things that are negotiated. I yet don't see why a MG (IP Phone) which is almost always getting its config file(s) from a Server (MGC?) that it will yet need to have anything other than the one default value (even if that is EF marked) which that Domain Administrator assigns to all Voice traffic within that Domain. I believe the same should apply to a MG that's a PSTN to IP Gateway. There actually cannot be a priority change from the PSTN to the IP network in this example by law, if that IP Network is providing a Telecommunications Service (although I'm not sure that 'law' is the right word -- I just know MLPP cannot be run on the PSTN or like network-types). Therefore, all inbound IP Voice related traffic must have the same value as all other Voice traffic to those types of providers. I know Fred Baker is very resistant to the idea of Voice traffic having multiple Forwarding queue behaviors within an internetworking device (i.e. multiple levels of EF for dropping), so this would suggest the DSCP other than EF isn't preferred by him (and others). His belief - and I'm not yet sure it's correct in the long term - is that this is a session issue, not a forwarding issue; therefore this is an RSVP/COPS Prioritization issue, isn't it? At 06:01 PM 8/3/2000 -0700, Bill Foster wrote: >Given that the MGC is often defining policy and QoS use is an important >policy, it would be useful to have the capability. > >At 04:34 PM 8/3/00 -0700, S KA N wrote: >>Hi There, >> >>If you can recall the meaning of DiffServ, its for >>implementing differentiated services in the Internet. >>Which basically means giving QoS to specially marked >>data traffic. Now if you look at the requirements >>specified in Section 5.5 of RFC2805, it says that >>the MGCP protocol should support the ability to >>specify QoS for the connection between MGs, etc. >> >>Any comment. >> >>...SKAN >> >> >> >> > There's a difference between an operator's RFP >> > requiring that their MGs >> > support DiffServ and a protocol dependency on such >> > support. Megaco has no >> > such dependency. >> > >> > > -----Original Message----- >> > > From: S KA N [SMTP:s_ka_n@YAHOO.COM] >> > > Sent: Wednesday, August 02, 2000 3:26 PM >> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM >> > > Subject: MG and DiffServ >> > > >> > > Hi, >> > > >> > > Can you think of any relation between the MG and >> > > DiffServ? >> > > >> > > If a privately managed IP network is DiffServ >> > > compliant and suppose if the same network >> > > is going to be used for VoIP purposes also. Don't >> > > we require the MGs to be DiffServ compliant? >> > > >> > > Any help/comment would be appreciated. >> > > >> > > ...SKAN >> >> >>__________________________________________________ >>Do You Yahoo!? >>Kick off your party with Yahoo! Invites. >>http://invites.yahoo.com/ > >----------------------------- >Bill Foster >Phone: (408) 527-8791 >Page: (800) 365-4578 >Fax: (781) 998-6492 > ************************************* "At the end of the day... the most committed win!" James M. Polk Sr. Product Manager, Multiservice Architecture and Standards Enterprise Voice Business Unit Cisco Systems Dallas, Texas w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_3244473==_.ALT Content-Type: text/html; charset="us-ascii"
All

Shouldn't this be defined by other mechanisms by default?

For example, typically the MG is dumb and requires a config image from some TFTP server. A template config is usually utilized that should set the default DSCP to a value that likely won't change. This isn't a Protocol issue, I don't think, it's a semantics issue.

Another example, the port the MG is physically connected to on the Enet Switch sets the traffic to a specific Voice VLAN. Again, this isn't a Protocol issue.

Another example, the Enet Switch knows that a MG is what's attached to a specific port and sets all incoming traffic to a defined DSCP value -- again, not a Protocol issue.

I think, typically, a Protocol deals with things that are negotiated. I yet don't see why a MG (IP Phone) which is almost always getting its config file(s) from a Server (MGC?) that it will yet need to have anything other than the one default value (even if that is EF marked) which that Domain Administrator assigns to all Voice traffic within that Domain.

I believe the same should apply to a MG that's a PSTN to IP Gateway. There actually cannot be a priority change from the PSTN to the IP network in this example by law, if that IP Network is providing a Telecommunications Service (although I'm not sure that 'law' is the right word -- I just know MLPP cannot be run on the PSTN or like network-types). Therefore, all inbound IP Voice related traffic must have the same value as all other Voice traffic to those types of providers.

I know Fred Baker is very resistant to the idea of Voice traffic having multiple Forwarding queue behaviors within an internetworking device (i.e. multiple levels of EF for dropping), so this would suggest the DSCP other than EF isn't preferred by him (and others). His belief - and I'm not yet sure it's correct in the long term - is that this is a session issue, not a forwarding issue; therefore this is an RSVP/COPS Prioritization issue, isn't it?


At 06:01 PM 8/3/2000 -0700, Bill Foster wrote:
>Given that the MGC is often defining policy and QoS use is an important
>policy, it would be useful to have the capability.
>
>At 04:34 PM 8/3/00 -0700, S KA N wrote:
>>Hi There,
>>
>>If you can recall the meaning of DiffServ, its for
>>implementing differentiated services in the Internet.
>>Which basically means giving QoS to specially marked
>>data traffic. Now if you look at the requirements
>>specified in Section 5.5 of RFC2805, it says that
>>the MGCP protocol should support the ability to
>>specify QoS for the connection between MGs, etc.
>>
>>Any comment.
>>
>>...SKAN
>>
>>
>>
>> > There's a difference between an operator's RFP
>> > requiring that their MGs
>> > support DiffServ and a protocol dependency on such
>> > support.  Megaco has no
>> > such dependency.
>> >
>> > > -----Original Message-----
>> > > From:       S KA N [SMTP:s_ka_n@YAHOO.COM]
>> > > Sent:       Wednesday, August 02, 2000 3:26 PM
>> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>> > > Subject:    MG and DiffServ
>> > >
>> > > Hi,
>> > >
>> > > Can you think of any relation between the MG and
>> > > DiffServ?
>> > >
>> > > If a privately managed IP network is DiffServ
>> > > compliant and suppose if the same network
>> > > is going to be used for VoIP purposes also. Don't
>> > > we require the MGs to be DiffServ compliant?
>> > >
>> > > Any help/comment would be appreciated.
>> > >
>> > > ...SKAN
>>
>>
>>__________________________________________________
>>Do You Yahoo!?
>>Kick off your party with Yahoo! Invites.
>
>-----------------------------
>Bill Foster
>Phone: (408) 527-8791
>Page:   (800) 365-4578
>Fax:     (781) 998-6492
>

*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_3244473==_.ALT-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 09:46:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08875 for ; Fri, 4 Aug 2000 09:46:22 -0400 (EDT) Received: from standards (47.234.32.16:2708) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84FA4@standards.nortelnetworks.com>; Fri, 4 Aug 2000 9:34:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7716 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 09:34:29 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84FA3@standards.nortelnetworks.com>; Fri, 4 Aug 2000 9:34:29 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA29647; Fri, 4 Aug 2000 09:45:25 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 JAA28984; Fri, 4 Aug 2000 09:45:28 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 4 Aug 2000 09:45:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF67868E@whq-msgusr-02.fore.com> Date: Fri, 4 Aug 2000 09:45:26 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Query on the port numbers used X-To: "rezhirpavai@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM When the MG contacts the MGC, it will encode the message in one way. It will send a message, encoded in that way, to the correct port. The MGC would then know what encoding the MG wanted to use. If it wanted to move the association to a different port, it would do so with the reply. The encoding would be what the MG started with. Thus there is no need to have different text/binary port numbers in ServiceChange. Brian > -----Original Message----- > From: rezhirpavai@HSS.HNS.COM [mailto:rezhirpavai@HSS.HNS.COM] > Sent: Friday, August 04, 2000 12:24 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Query on the port numbers used > > > Hello, > Section 9 of draft-ietf-megaco-merged-01.txt specifies that port > number 2944 should be the default port used for text encoding and 2945 > should be default port for binary-encoding. It later says > that these port > numbers may be changed using the ServiceChangeAddress. > > On specifying different port numbers, do we have to maintain > the same strategy of having different port numbers for > text-encoding and > binary-encoding or can the same port be used for both text and binary > encoding. MGC shall identify whether to decode the text > encoded data or > binary encoded data based on the local+remote port and IP > address pair. > > > Regards, > R. Ezhirpavai > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 09:50:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10053 for ; Fri, 4 Aug 2000 09:50:02 -0400 (EDT) Received: from standards (47.234.32.16:2708) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84FBC@standards.nortelnetworks.com>; Fri, 4 Aug 2000 9:38:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7748 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 09:38:03 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84FBB@standards.nortelnetworks.com>; Fri, 4 Aug 2000 9:38:03 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA29999; Fri, 4 Aug 2000 09:49:12 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 JAA29989; Fri, 4 Aug 2000 09:49:15 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 4 Aug 2000 09:49:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="KS_C_5601-1987" Message-ID: <4FBEA8857476D311A03300204840E1CF67868F@whq-msgusr-02.fore.com> Date: Fri, 4 Aug 2000 09:49:12 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: About mixing and topology X-To: Junyoung Heo To: MEGACO@STANDARDS.NORTELNETWORKS.COM I cannot completely understand your question. The text describes how you use TOPOLOGY to control a device that uses a "star" topology mixer. So I think the text is clear on how you enable mixing among terminations data when the mixer is a "everyone hears everyone else" type of mix. What the text is not clear on is how you use topology when the mixer is not a "star". That is a known limitation, which was agreed to be deferred to a later edition. Brian -----Original Message----- From: Junyoung Heo [mailto:green@NADATEL.COM] Sent: Friday, August 04, 2000 1:19 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: About mixing and topology I have just read megaco draft documnet. I will use megaco as protocol between MC and MP. I choose megaco because its topology property. But, I can't find how to describe topology to enable mixing among terminations' data. How can I make it? Regards, Junyoung Heo 2000/08/04 KOREA From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 09:52:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10906 for ; Fri, 4 Aug 2000 09:52:32 -0400 (EDT) Received: from standards (47.234.32.16:2708) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84FC7@standards.nortelnetworks.com>; Fri, 4 Aug 2000 9:38:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7762 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 09:38:41 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84FC4@standards.nortelnetworks.com>; Fri, 4 Aug 2000 9:38:36 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA00088; Fri, 4 Aug 2000 09:49:56 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA00215; Fri, 4 Aug 2000 09:49:59 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 4 Aug 2000 09:49:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF678690@whq-msgusr-02.fore.com> Date: Fri, 4 Aug 2000 09:49:57 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Calling Line Identification X-To: "rpatil@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Need a package. Any volunteers? Brian > -----Original Message----- > From: Rajendra Patil [mailto:rpatil@HSS.HNS.COM] > Sent: Friday, August 04, 2000 7:57 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Calling Line Identification > > > Hi, > > How MEGACOsupports CLID display for residential gateway ? > > Thanks/ > Rajendra > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 09:58:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12950 for ; Fri, 4 Aug 2000 09:58:46 -0400 (EDT) Received: from standards (47.234.32.16:2708) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84FF9@standards.nortelnetworks.com>; Fri, 4 Aug 2000 9:46:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7742 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 09:46:31 -0400 Received: from dnsmx2pya.telcordia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84FB8@standards.nortelnetworks.com>; Fri, 4 Aug 2000 9:36:30 -0400 Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id JAA03715; Fri, 4 Aug 2000 09:46:49 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256931.004BADEF ; Fri, 4 Aug 2000 09:46:37 -0400 X-Lotus-FromDomain: TELCORDIA Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=eKhVFIXcaC6pvs0QtY7GdLoyZ1a3TXjmsQGhndIq62qErOziiLi9hco0" Content-Disposition: inline Message-ID: <85256931.004BAD51.00@notes949.cc.telcordia.com> Date: Fri, 4 Aug 2000 09:46:20 -0400 Reply-To: "Petros N. Mouchtaris" Sender: "Media Gateway Control (megaco)" From: "Petros N. Mouchtaris" Subject: Re: MG and DiffServ X-To: "James M. Polk" To: MEGACO@STANDARDS.NORTELNETWORKS.COM --0__=eKhVFIXcaC6pvs0QtY7GdLoyZ1a3TXjmsQGhndIq62qErOziiLi9hco0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline I have a specific case that your approach does not support. I may have misunderstood your comments so please let me know if I'm incorrect. TI think this case is reasonable and should be supported: I'd like all my voice to receive premium quality except for my calls to Greece where I'm willing to accept best effort quality so that those calls to Greece are virtually free. This will help me keep up with all my friends and family there. I expect that the MGC will maintain this policy and not my phone. Let me know what you think. Petros "James M. Polk" on 08/04/2000 09:28:26 AM Please respond to "James M. Polk" To: MEGACO@standards.nortelnetworks.com cc: (bcc: Petros N. Mouchtaris/Telcordia) Subject: Re: MG and DiffServ All Shouldn't this be defined by other mechanisms by default? For example, typically the MG is dumb and requires a config image from some TFTP server. A template config is usually utilized that should set the default DSCP to a value that likely won't change. This isn't a Protocol issue, I don't think, it's a semantics issue. Another example, the port the MG is physically connected to on the Enet Switch sets the traffic to a specific Voice VLAN. Again, this isn't a Protocol issue. Another example, the Enet Switch knows that a MG is what's attached to a specific port and sets all incoming traffic to a defined DSCP value -- again, not a Protocol issue. I think, typically, a Protocol deals with things that are negotiated. I yet don't see why a MG (IP Phone) which is almost always getting its config file(s) from a Server (MGC?) that it will yet need to have anything other than the one default value (even if that is EF marked) which that Domain Administrator assigns to all Voice traffic within that Domain. I believe the same should apply to a MG that's a PSTN to IP Gateway. There actually cannot be a priority change from the PSTN to the IP network in this example by law, if that IP Network is providing a Telecommunications Service (although I'm not sure that 'law' is the right word -- I just know MLPP cannot be run on the PSTN or like network-types). Therefore, all inbound IP Voice related traffic must have the same value as all other Voice traffic to those types of providers. I know Fred Baker is very resistant to the idea of Voice traffic having multiple Forwarding queue behaviors within an internetworking device (i.e. multiple levels of EF for dropping), so this would suggest the DSCP other than EF isn't preferred by him (and others). His belief - and I'm not yet sure it's correct in the long term - is that this is a session issue, not a forwarding issue; therefore this is an RSVP/COPS Prioritization issue, isn't it? At 06:01 PM 8/3/2000 -0700, Bill Foster wrote: >Given that the MGC is often defining policy and QoS use is an important >policy, it would be useful to have the capability. > >At 04:34 PM 8/3/00 -0700, S KA N wrote: >>Hi There, >> >>If you can recall the meaning of DiffServ, its for >>implementing differentiated services in the Internet. >>Which basically means giving QoS to specially marked >>data traffic. Now if you look at the requirements >>specified in Section 5.5 of RFC2805, it says that >>the MGCP protocol should support the ability to >>specify QoS for the connection between MGs, etc. >> >>Any comment. >> >>...SKAN >> >> >> >> > There's a difference between an operator's RFP >> > requiring that their MGs >> > support DiffServ and a protocol dependency on such >> > support. Megaco has no >> > such dependency. >> > >> > > -----Original Message----- >> > > From: S KA N [SMTP:s_ka_n@YAHOO.COM] >> > > Sent: Wednesday, August 02, 2000 3:26 PM >> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM >> > > Subject: MG and DiffServ >> > > >> > > Hi, >> > > >> > > Can you think of any relation between the MG and >> > > DiffServ? >> > > >> > > If a privately managed IP network is DiffServ >> > > compliant and suppose if the same network >> > > is going to be used for VoIP purposes also. Don't >> > > we require the MGs to be DiffServ compliant? >> > > >> > > Any help/comment would be appreciated. >> > > >> > > ...SKAN >> >> >>__________________________________________________ >>Do You Yahoo!? >>Kick off your party with Yahoo! Invites. >>http://invites.yahoo.com/ > >----------------------------- >Bill Foster >Phone: (408) 527-8791 >Page: (800) 365-4578 >Fax: (781) 998-6492 > ************************************* "At the end of the day... the most committed win!" James M. Polk Sr. Product Manager, Multiservice Architecture and Standards Enterprise Voice Business Unit Cisco Systems Dallas, Texas w) 972.813.5208 f) 972.813.5280 www.cisco.com --0__=eKhVFIXcaC6pvs0QtY7GdLoyZ1a3TXjmsQGhndIq62qErOziiLi9hco0 Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PGh0bWw+PGRpdj5BbGw8L2Rpdj4NCjxicj4NCjxkaXY+U2hvdWxkbid0IHRoaXMgYmUgZGVmaW5l ZCBieSBvdGhlciBtZWNoYW5pc21zIGJ5IGRlZmF1bHQ/PC9kaXY+DQo8YnI+DQo8ZGl2PkZvciBl eGFtcGxlLCB0eXBpY2FsbHkgdGhlIE1HIGlzIGR1bWIgYW5kIHJlcXVpcmVzIGEgY29uZmlnIGlt YWdlDQpmcm9tIHNvbWUgVEZUUCBzZXJ2ZXIuIEEgdGVtcGxhdGUgY29uZmlnIGlzIHVzdWFsbHkg dXRpbGl6ZWQgdGhhdCBzaG91bGQNCnNldCB0aGUgZGVmYXVsdCBEU0NQIHRvIGEgdmFsdWUgdGhh dCBsaWtlbHkgd29uJ3QgY2hhbmdlLiBUaGlzIGlzbid0IGENClByb3RvY29sIGlzc3VlLCBJIGRv bid0IHRoaW5rLCBpdCdzIGEgc2VtYW50aWNzIGlzc3VlLjwvZGl2Pg0KPGJyPg0KPGRpdj5Bbm90 aGVyIGV4YW1wbGUsIHRoZSBwb3J0IHRoZSBNRyBpcyBwaHlzaWNhbGx5IGNvbm5lY3RlZCB0byBv biB0aGUNCkVuZXQgU3dpdGNoIHNldHMgdGhlIHRyYWZmaWMgdG8gYSBzcGVjaWZpYyBWb2ljZSBW TEFOLiBBZ2FpbiwgdGhpcyBpc24ndA0KYSBQcm90b2NvbCBpc3N1ZS48L2Rpdj4NCjxicj4NCjxk aXY+QW5vdGhlciBleGFtcGxlLCB0aGUgRW5ldCBTd2l0Y2gga25vd3MgdGhhdCBhIE1HIGlzIHdo YXQncyBhdHRhY2hlZA0KdG8gYSBzcGVjaWZpYyBwb3J0IGFuZCBzZXRzIGFsbCBpbmNvbWluZyB0 cmFmZmljIHRvIGEgZGVmaW5lZCBEU0NQIHZhbHVlDQotLSBhZ2Fpbiwgbm90IGEgUHJvdG9jb2wg aXNzdWUuPC9kaXY+DQo8YnI+DQo8ZGl2PkkgdGhpbmssIHR5cGljYWxseSwgYSBQcm90b2NvbCBk ZWFscyB3aXRoIHRoaW5ncyB0aGF0IGFyZQ0KbmVnb3RpYXRlZC4gSSB5ZXQgZG9uJ3Qgc2VlIHdo eSBhIE1HIChJUCBQaG9uZSkgd2hpY2ggaXMgYWxtb3N0IGFsd2F5cw0KZ2V0dGluZyBpdHMgY29u ZmlnIGZpbGUocykgZnJvbSBhIFNlcnZlciAoTUdDPykgdGhhdCBpdCB3aWxsIHlldCBuZWVkIHRv DQpoYXZlIGFueXRoaW5nIG90aGVyIHRoYW4gdGhlIG9uZSBkZWZhdWx0IHZhbHVlIChldmVuIGlm IHRoYXQgaXMgRUYNCm1hcmtlZCkgd2hpY2ggdGhhdCBEb21haW4gQWRtaW5pc3RyYXRvciBhc3Np Z25zIHRvIGFsbCBWb2ljZSB0cmFmZmljDQp3aXRoaW4gdGhhdCBEb21haW4uIDwvZGl2Pg0KPGJy Pg0KPGRpdj5JIGJlbGlldmUgdGhlIHNhbWUgc2hvdWxkIGFwcGx5IHRvIGEgTUcgdGhhdCdzIGEg UFNUTiB0byBJUCBHYXRld2F5Lg0KVGhlcmUgYWN0dWFsbHkgY2Fubm90IGJlIGEgcHJpb3JpdHkg Y2hhbmdlIGZyb20gdGhlIFBTVE4gdG8gdGhlIElQDQpuZXR3b3JrIGluIHRoaXMgZXhhbXBsZSBi eSBsYXcsIGlmIHRoYXQgSVAgTmV0d29yayBpcyBwcm92aWRpbmcgYQ0KVGVsZWNvbW11bmljYXRp b25zIFNlcnZpY2UgKGFsdGhvdWdoIEknbSBub3Qgc3VyZSB0aGF0ICdsYXcnIGlzIHRoZSByaWdo dA0Kd29yZCAtLSBJIGp1c3Qga25vdyBNTFBQIGNhbm5vdCBiZSBydW4gb24gdGhlIFBTVE4gb3Ig bGlrZQ0KbmV0d29yay10eXBlcykuIFRoZXJlZm9yZSwgYWxsIGluYm91bmQgSVAgVm9pY2UgcmVs YXRlZCB0cmFmZmljIG11c3QgaGF2ZQ0KdGhlIHNhbWUgdmFsdWUgYXMgYWxsIG90aGVyIFZvaWNl IHRyYWZmaWMgdG8gdGhvc2UgdHlwZXMgb2YNCnByb3ZpZGVycy48L2Rpdj4NCjxicj4NCjxkaXY+ SSBrbm93IEZyZWQgQmFrZXIgaXMgdmVyeSByZXNpc3RhbnQgdG8gdGhlIGlkZWEgb2YgVm9pY2Ug dHJhZmZpYw0KaGF2aW5nIG11bHRpcGxlIEZvcndhcmRpbmcgcXVldWUgYmVoYXZpb3JzIHdpdGhp biBhbiBpbnRlcm5ldHdvcmtpbmcNCmRldmljZSAoaS5lLiBtdWx0aXBsZSBsZXZlbHMgb2YgRUYg Zm9yIGRyb3BwaW5nKSwgc28gdGhpcyB3b3VsZCBzdWdnZXN0DQp0aGUgRFNDUCBvdGhlciB0aGFu IEVGIGlzbid0IHByZWZlcnJlZCBieSBoaW0gKGFuZCBvdGhlcnMpLiBIaXMgYmVsaWVmIC0NCmFu ZCBJJ20gbm90IHlldCBzdXJlIGl0J3MgY29ycmVjdCBpbiB0aGUgbG9uZyB0ZXJtIC0gaXMgdGhh dCB0aGlzIGlzIGENCnNlc3Npb24gaXNzdWUsIG5vdCBhIGZvcndhcmRpbmcgaXNzdWU7IHRoZXJl Zm9yZSB0aGlzIGlzIGFuIFJTVlAvQ09QUw0KUHJpb3JpdGl6YXRpb24gaXNzdWUsIGlzbid0IGl0 PzwvZGl2Pg0KPGJyPg0KPGJyPg0KPGRpdj5BdCAwNjowMSBQTSA4LzMvMjAwMCAtMDcwMCwgQmls bCBGb3N0ZXIgd3JvdGU6PC9kaXY+DQo8ZGl2PiZndDtHaXZlbiB0aGF0IHRoZSBNR0MgaXMgb2Z0 ZW4gZGVmaW5pbmcgcG9saWN5IGFuZCBRb1MgdXNlIGlzIGFuDQppbXBvcnRhbnQgPC9kaXY+DQo8 ZGl2PiZndDtwb2xpY3ksIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBoYXZlIHRoZSBjYXBhYmlsaXR5 LjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDtBdCAwNDozNCBQTSA4LzMvMDAgLTA3 MDAsIFMgS0EgTiB3cm90ZTo8L2Rpdj4NCjxkaXY+Jmd0OyZndDtIaSBUaGVyZSw8L2Rpdj4NCjxk aXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDtJZiB5b3UgY2FuIHJlY2FsbCB0aGUgbWVh bmluZyBvZiBEaWZmU2VydiwgaXRzIGZvcjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0O2ltcGxlbWVudGlu ZyBkaWZmZXJlbnRpYXRlZCBzZXJ2aWNlcyBpbiB0aGUNCkludGVybmV0LjwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0O1doaWNoIGJhc2ljYWxseSBtZWFucyBnaXZpbmcgUW9TIHRvIHNwZWNpYWxseSBtYXJr ZWQ8L2Rpdj4NCjxkaXY+Jmd0OyZndDtkYXRhIHRyYWZmaWMuIE5vdyBpZiB5b3UgbG9vayBhdCB0 aGUgcmVxdWlyZW1lbnRzPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7c3BlY2lmaWVkIGluIFNlY3Rpb24g NS41IG9mIFJGQzI4MDUsIGl0IHNheXMgdGhhdDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0O3RoZSBNR0NQ IHByb3RvY29sIHNob3VsZCBzdXBwb3J0IHRoZSBhYmlsaXR5IHRvPC9kaXY+DQo8ZGl2PiZndDsm Z3Q7c3BlY2lmeSBRb1MgZm9yIHRoZSBjb25uZWN0aW9uIGJldHdlZW4gTUdzLCBldGMuPC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7QW55IGNvbW1lbnQuPC9kaXY+DQo8 ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Li4uU0tBTjwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRp dj4mZ3Q7Jmd0OyAmZ3Q7IFRoZXJlJ3MgYSBkaWZmZXJlbmNlIGJldHdlZW4gYW4gb3BlcmF0b3In cyBSRlA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyByZXF1aXJpbmcgdGhhdCB0aGVpciBNR3M8 L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyBzdXBwb3J0IERpZmZTZXJ2IGFuZCBhIHByb3RvY29s IGRlcGVuZGVuY3kgb24NCnN1Y2g8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyBzdXBwb3J0LiZu YnNwOyBNZWdhY28gaGFzIG5vPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDsgc3VjaCBkZXBlbmRl bmN5LjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDsg Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7 ICZndDsgRnJvbTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUyBLQSBODQpb U01UUDpzX2thX25AWUFIT08uQ09NXTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsgU2Vu dDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCldlZG5lc2RheSwgQXVndXN0 IDAyLCAyMDAwIDM6MjYgUE08L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyAmZ3Q7IFRvOiBNRUdB Q09AU1RBTkRBUkRTLk5PUlRFTE5FVFdPUktTLkNPTTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7 ICZndDsgU3ViamVjdDombmJzcDsmbmJzcDsmbmJzcDsgTUcgYW5kDQpEaWZmU2VydjwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0OyAmZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyAmZ3Q7IEhp LDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0 OyAmZ3Q7IENhbiB5b3UgdGhpbmsgb2YgYW55IHJlbGF0aW9uIGJldHdlZW4gdGhlIE1HDQphbmQ8 L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyAmZ3Q7IERpZmZTZXJ2PzwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyAmZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyAmZ3Q7IElmIGEgcHJpdmF0 ZWx5IG1hbmFnZWQgSVAgbmV0d29yayBpcw0KRGlmZlNlcnY8L2Rpdj4NCjxkaXY+Jmd0OyZndDsg Jmd0OyAmZ3Q7IGNvbXBsaWFudCBhbmQgc3VwcG9zZSBpZiB0aGUgc2FtZSBuZXR3b3JrPC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7ICZndDsgJmd0OyBpcyBnb2luZyB0byBiZSB1c2VkIGZvciBWb0lQIHB1 cnBvc2VzIGFsc28uDQpEb24ndDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsgd2UgcmVx dWlyZSB0aGUgTUdzIHRvIGJlIERpZmZTZXJ2DQpjb21wbGlhbnQ/PC9kaXY+DQo8ZGl2PiZndDsm Z3Q7ICZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsgQW55IGhlbHAvY29t bWVudCB3b3VsZCBiZSBhcHByZWNpYXRlZC48L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyAmZ3Q7 PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDsgJmd0OyAuLi5TS0FOPC9kaXY+DQo8ZGl2PiZndDsm Z3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2Rpdj4NCjxkaXY+Jmd0OyZn dDtEbyBZb3UgWWFob28hPzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0O0tpY2sgb2ZmIHlvdXIgcGFydHkg d2l0aCBZYWhvbyEgSW52aXRlcy48L2Rpdj4NCjxkaXY+Jmd0OyZndDs8YSBocmVmPSJodHRwOi8v aW52aXRlcy55YWhvby5jb20vIiBFVURPUkE9QVVUT1VSTD5odHRwOi8vaW52aXRlcy55YWhvby5j b20vPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTwvZGl2Pg0KPGRpdj4mZ3Q7QmlsbCBGb3N0ZXI8L2Rpdj4NCjxkaXY+Jmd0 O1Bob25lOiAoNDA4KSA1MjctODc5MTwvZGl2Pg0KPGRpdj4mZ3Q7UGFnZTombmJzcDsmbmJzcDsg KDgwMCkgMzY1LTQ1Nzg8L2Rpdj4NCjxkaXY+Jmd0O0ZheDombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgKDc4MSkgOTk4LTY0OTI8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGJyPg0KDQo8ZGl2IGFs aWduPSJjZW50ZXIiPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4N CiZxdW90O0F0IHRoZSBlbmQgb2YgdGhlIGRheS4uLiB0aGUgbW9zdCBjb21taXR0ZWQgd2luISZx dW90Ozxicj4NCjxicj4NCjwvZGl2Pg0KSmFtZXMgTS4gUG9sazxicj4NClNyLiBQcm9kdWN0IE1h bmFnZXIsIE11bHRpc2VydmljZSBBcmNoaXRlY3R1cmUgYW5kIFN0YW5kYXJkczxicj4NCkVudGVy cHJpc2UgVm9pY2UgQnVzaW5lc3MgVW5pdDxicj4NCkNpc2NvIFN5c3RlbXM8YnI+DQpEYWxsYXMs IFRleGFzPGJyPg0KdykgOTcyLjgxMy41MjA4PGJyPg0KZikmbmJzcDsgOTcyLjgxMy41MjgwPGJy Pg0KPGEgaHJlZj0iaHR0cDovL3d3dy5jaXNjby5jb20vIiBldWRvcmE9ImF1dG91cmwiPnd3dy5j aXNjby5jb208L2E+PC9odG1sPg0KDQo= --0__=eKhVFIXcaC6pvs0QtY7GdLoyZ1a3TXjmsQGhndIq62qErOziiLi9hco0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 10:13:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18024 for ; Fri, 4 Aug 2000 10:13:46 -0400 (EDT) Received: from standards (47.234.32.16:2708) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8501C@standards.nortelnetworks.com>; Fri, 4 Aug 2000 10:01:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7873 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 10:01:42 -0400 Received: from diablo.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8501B@standards.nortelnetworks.com>; Fri, 4 Aug 2000 10:01:41 -0400 Received: from jmpolk-8k (ssh.cisco.com [171.69.10.34]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id HAA01062; Fri, 4 Aug 2000 07:12:58 -0700 (PDT) X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_5912504==_.ALT" Message-ID: <4.1.20000804090404.00c056a0@diablo.cisco.com> Date: Fri, 4 Aug 2000 09:12:54 -0500 Reply-To: "James M. Polk" Sender: "Media Gateway Control (megaco)" From: "James M. Polk" Subject: Re: MG and DiffServ X-To: "Petros N. Mouchtaris" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <85256931.004BAD51.00@notes949.cc.telcordia.com> --=====================_5912504==_.ALT Content-Type: text/plain; charset="us-ascii" Petros Who is providing the Service for you Voice traffic? If that is a Telecommunications Service Provider (as defined by the US FCC), then you won't have that choice across their network (I don't believe). If that is from an Enterprise-based Call Agent (MGC), then I'd be surprised if that were legally allowed to separate this traffic if that Enterprise has the MGC or Call Agent for Signaling to/from your MG. I think you'll have to somehow get the traffic you want to be EF marked across a Telecom SP and have your Greece-bound traffic across some other network entirely, then this will work. But (I think) the same MGC cannot signal both your Greece destination traffic and the rest of your Voice traffic (as they would be separate networks for signaling). One way around that is a Peer-to-Peer signaling Protocol like H.323 or SIP from a computer (NetMeeting for example) going best effort to the Internet for that best effort traffic, and your phones remain on that Telecom SP's MGC and of EF marked packets and high quality. At 09:46 AM 8/4/2000 -0400, Petros N. Mouchtaris wrote: > > >I have a specific case that your approach does not support. I may have >misunderstood your comments so please let me know if I'm incorrect. TI think >this case is reasonable and should be supported: > >I'd like all my voice to receive premium quality except for my calls to Greece >where I'm willing to accept best effort quality so that those calls to Greece >are virtually free. This will help me keep up with all my friends and family >there. > >I expect that the MGC will maintain this policy and not my phone. Let me know >what you think. > >Petros > > > > > >"James M. Polk" on 08/04/2000 09:28:26 AM > >Please respond to "James M. Polk" > >To: MEGACO@standards.nortelnetworks.com >cc: (bcc: Petros N. Mouchtaris/Telcordia) >Subject: Re: MG and DiffServ > > > > > >All > >Shouldn't this be defined by other mechanisms by default? > >For example, typically the MG is dumb and requires a config image from some >TFTP server. A template config is usually utilized that should set the default >DSCP to a value that likely won't change. This isn't a Protocol issue, I don't >think, it's a semantics issue. > >Another example, the port the MG is physically connected to on the Enet Switch >sets the traffic to a specific Voice VLAN. Again, this isn't a Protocol issue. > >Another example, the Enet Switch knows that a MG is what's attached to a >specific port and sets all incoming traffic to a defined DSCP value -- again, >not a Protocol issue. > >I think, typically, a Protocol deals with things that are negotiated. I yet >don't see why a MG (IP Phone) which is almost always getting its config file(s) >from a Server (MGC?) that it will yet need to have anything other than the one >default value (even if that is EF marked) which that Domain Administrator >assigns to all Voice traffic within that Domain. > >I believe the same should apply to a MG that's a PSTN to IP Gateway. There >actually cannot be a priority change from the PSTN to the IP network in this >example by law, if that IP Network is providing a Telecommunications Service >(although I'm not sure that 'law' is the right word -- I just know MLPP cannot >be run on the PSTN or like network-types). Therefore, all inbound IP Voice >related traffic must have the same value as all other Voice traffic to those >types of providers. > >I know Fred Baker is very resistant to the idea of Voice traffic having >multiple Forwarding queue behaviors within an internetworking device (i.e. >multiple levels of EF for dropping), so this would suggest the DSCP other than >EF isn't preferred by him (and others). His belief - and I'm not yet sure it's >correct in the long term - is that this is a session issue, not a forwarding >issue; therefore this is an RSVP/COPS Prioritization issue, isn't it? > > >At 06:01 PM 8/3/2000 -0700, Bill Foster wrote: >>Given that the MGC is often defining policy and QoS use is an important >>policy, it would be useful to have the capability. >> >>At 04:34 PM 8/3/00 -0700, S KA N wrote: >>>Hi There, >>> >>>If you can recall the meaning of DiffServ, its for >>>implementing differentiated services in the Internet. >>>Which basically means giving QoS to specially marked >>>data traffic. Now if you look at the requirements >>>specified in Section 5.5 of RFC2805, it says that >>>the MGCP protocol should support the ability to >>>specify QoS for the connection between MGs, etc. >>> >>>Any comment. >>> >>>...SKAN >>> >>> >>> >>> > There's a difference between an operator's RFP >>> > requiring that their MGs >>> > support DiffServ and a protocol dependency on such >>> > support. Megaco has no >>> > such dependency. >>> > >>> > > -----Original Message----- >>> > > From: S KA N [SMTP:s_ka_n@YAHOO.COM] >>> > > Sent: Wednesday, August 02, 2000 3:26 PM >>> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM >>> > > Subject: MG and DiffServ >>> > > >>> > > Hi, >>> > > >>> > > Can you think of any relation between the MG and >>> > > DiffServ? >>> > > >>> > > If a privately managed IP network is DiffServ >>> > > compliant and suppose if the same network >>> > > is going to be used for VoIP purposes also. Don't >>> > > we require the MGs to be DiffServ compliant? >>> > > >>> > > Any help/comment would be appreciated. >>> > > >>> > > ...SKAN >>> >>> >>>__________________________________________________ >>>Do You Yahoo!? >>>Kick off your party with Yahoo! Invites. >>>http://invites.yahoo.com/ >> >>----------------------------- >>Bill Foster >>Phone: (408) 527-8791 >>Page: (800) 365-4578 >>Fax: (781) 998-6492 >> > >************************************* >"At the end of the day... the most committed win!" > >James M. Polk >Sr. Product Manager, Multiservice Architecture and Standards >Enterprise Voice Business Unit >Cisco Systems >Dallas, Texas >w) 972.813.5208 >f) 972.813.5280 >www.cisco.com > ************************************* "At the end of the day... the most committed win!" James M. Polk Sr. Product Manager, Multiservice Architecture and Standards Enterprise Voice Business Unit Cisco Systems Dallas, Texas w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_5912504==_.ALT Content-Type: text/html; charset="us-ascii"
Petros

Who is providing the Service for you Voice traffic? If that is a Telecommunications Service Provider (as defined by the US FCC), then you won't have that choice across their network (I don't believe). If that is from an Enterprise-based Call Agent (MGC), then I'd be surprised if that were legally allowed to separate this traffic if that Enterprise has the MGC or Call Agent for Signaling to/from your MG.

I think you'll have to somehow get the traffic you want to be EF marked across a Telecom SP and have your Greece-bound traffic across some other network entirely, then this will work. But (I think) the same MGC cannot signal both your Greece destination traffic and the rest of your Voice traffic (as they would be separate networks for signaling).

One way around that is a Peer-to-Peer signaling Protocol like H.323 or SIP from a computer (NetMeeting for example) going best effort to the Internet for that best effort traffic, and your phones remain on that Telecom SP's MGC and of EF marked packets and high quality.

At 09:46 AM 8/4/2000 -0400, Petros N. Mouchtaris wrote:
>
>
>I have a specific case that your approach does not support. I may have
>misunderstood your comments so please let me know if I'm incorrect. TI think
>this case is reasonable and should be supported:
>
>I'd like all my voice to receive premium quality except for my calls to Greece
>where I'm willing to accept best effort quality so that those calls to Greece
>are virtually free. This will help me keep up with all my friends and family
>there.
>
>I expect that the MGC will maintain this policy and not my phone.  Let me know
>what you think.
>
>Petros
>
>
>
>
>
>"James M. Polk" <jmpolk@cisco.com> on 08/04/2000 09:28:26 AM
>
>Please respond to "James M. Polk" <jmpolk@cisco.com>
>
>To:   MEGACO@standards.nortelnetworks.com
>cc:    (bcc: Petros N. Mouchtaris/Telcordia)
>Subject:  Re: MG and DiffServ
>
>
>
>
>
>All
>
>Shouldn't this be defined by other mechanisms by default?
>
>For example, typically the MG is dumb and requires a config image from some
>TFTP server. A template config is usually utilized that should set the default
>DSCP to a value that likely won't change. This isn't a Protocol issue, I don't
>think, it's a semantics issue.
>
>Another example, the port the MG is physically connected to on the Enet Switch
>sets the traffic to a specific Voice VLAN. Again, this isn't a Protocol issue.
>
>Another example, the Enet Switch knows that a MG is what's attached to a
>specific port and sets all incoming traffic to a defined DSCP value -- again,
>not a Protocol issue.
>
>I think, typically, a Protocol deals with things that are negotiated. I yet
>don't see why a MG (IP Phone) which is almost always getting its config file(s)
>from a Server (MGC?) that it will yet need to have anything other than the one
>default value (even if that is EF marked) which that Domain Administrator
>assigns to all Voice traffic within that Domain.
>
>I believe the same should apply to a MG that's a PSTN to IP Gateway. There
>actually cannot be a priority change from the PSTN to the IP network in this
>example by law, if that IP Network is providing a Telecommunications Service
>(although I'm not sure that 'law' is the right word -- I just know MLPP cannot
>be run on the PSTN or like network-types). Therefore, all inbound IP Voice
>related traffic must have the same value as all other Voice traffic to those
>types of providers.
>
>I know Fred Baker is very resistant to the idea of Voice traffic having
>multiple Forwarding queue behaviors within an internetworking device (i.e.
>multiple levels of EF for dropping), so this would suggest the DSCP other than
>EF isn't preferred by him (and others). His belief - and I'm not yet sure it's
>correct in the long term - is that this is a session issue, not a forwarding
>issue; therefore this is an RSVP/COPS Prioritization issue, isn't it?
>
>
>At 06:01 PM 8/3/2000 -0700, Bill Foster wrote:
>>Given that the MGC is often defining policy and QoS use is an important
>>policy, it would be useful to have the capability.
>>
>>At 04:34 PM 8/3/00 -0700, S KA N wrote:
>>>Hi There,
>>>
>>>If you can recall the meaning of DiffServ, its for
>>>implementing differentiated services in the Internet.
>>>Which basically means giving QoS to specially marked
>>>data traffic. Now if you look at the requirements
>>>specified in Section 5.5 of RFC2805, it says that
>>>the MGCP protocol should support the ability to
>>>specify QoS for the connection between MGs, etc.
>>>
>>>Any comment.
>>>
>>>...SKAN
>>>
>>>
>>>
>>> > There's a difference between an operator's RFP
>>> > requiring that their MGs
>>> > support DiffServ and a protocol dependency on such
>>> > support.  Megaco has no
>>> > such dependency.
>>> >
>>> > > -----Original Message-----
>>> > > From:       S KA N [SMTP:s_ka_n@YAHOO.COM]
>>> > > Sent:       Wednesday, August 02, 2000 3:26 PM
>>> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>>> > > Subject:    MG and DiffServ
>>> > >
>>> > > Hi,
>>> > >
>>> > > Can you think of any relation between the MG and
>>> > > DiffServ?
>>> > >
>>> > > If a privately managed IP network is DiffServ
>>> > > compliant and suppose if the same network
>>> > > is going to be used for VoIP purposes also. Don't
>>> > > we require the MGs to be DiffServ compliant?
>>> > >
>>> > > Any help/comment would be appreciated.
>>> > >
>>> > > ...SKAN
>>>
>>>
>>>__________________________________________________
>>>Do You Yahoo!?
>>>Kick off your party with Yahoo! Invites.
>>
>>-----------------------------
>>Bill Foster
>>Phone: (408) 527-8791
>>Page:   (800) 365-4578
>>Fax:     (781) 998-6492
>>
>
>*************************************
>"At the end of the day... the most committed win!"
>
>James M. Polk
>Sr. Product Manager, Multiservice Architecture and Standards
>Enterprise Voice Business Unit
>Cisco Systems
>Dallas, Texas
>w) 972.813.5208
>f)  972.813.5280
>

*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_5912504==_.ALT-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 10:34:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24916 for ; Fri, 4 Aug 2000 10:34:25 -0400 (EDT) Received: from standards (47.234.32.16:2708) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85074@standards.nortelnetworks.com>; Fri, 4 Aug 2000 10:22:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7988 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 10:22:19 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85073@standards.nortelnetworks.com>; Fri, 4 Aug 2000 10:22:19 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04176; Fri, 4 Aug 2000 10:33:39 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 KAA11787; Fri, 4 Aug 2000 10:33:42 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 4 Aug 2000 10:33:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF678692@whq-msgusr-02.fore.com> Date: Fri, 4 Aug 2000 10:33:40 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Calling Line Identification X-To: CHATRAS Bruno FTRD/DAC/ISS To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA24916 My concern here is that when you implement a package, you implement all of it, and the extended capabilities you propose may be beyond what a reasonable implementation of a simple CLID capability may provide. I could see a set of packages each extending from the previous which could have capabilities you describe. Brian > -----Original Message----- > From: CHATRAS Bruno FTRD/DAC/ISS > [mailto:bruno.chatras@rd.francetelecom.fr] > Sent: Friday, August 04, 2000 10:24 AM > To: Rosen, Brian > Cc: 'MEGACO@STANDARDS.NORTELNETWORKS.COM' > Subject: RE: Calling Line Identification > > > Hi, > > I think that we need a more generic package that can support the > transmission of dipaly information over an analog line. > > I see a need to support: > > a) On-hook transmission associated with ringing (Calling Line > ID, Calling > Name ID, ...) > > b) On-hook transmission not associated with ringing (e.g.; > notification > services for message waiting indication) > > c) Off-hook transmission (calling Line ID presentation during > call waiting, > text-based advice of charge, ...) > > In all cases, there shall be no restrictions on the type of > message (and > parameters) to be sent over the analog line. > > I know that someone from Telcordia has presented a > contribution on that > topic to the ITU SG16 meeting in February'2000. The meeting reports > indicates that the proposal was reasonnable but that more > work was required. > I don't know what happened after that. > > I also attach for your information an alternative package > description I > drafted a few days ago. I'll not be able to work on it during > the cmming > weeks (holiday !). However, if someone wants to... > > > > > -----Message d'origine----- > > De: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > Date: vendredi 4 août 2000 15:50 > > À: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Objet: Re: Calling Line Identification > > > > > > Need a package. > > > > Any volunteers? > > > > Brian > > > > > -----Original Message----- > > > From: Rajendra Patil [mailto:rpatil@HSS.HNS.COM] > > > Sent: Friday, August 04, 2000 7:57 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Calling Line Identification > > > > > > > > > Hi, > > > > > > How MEGACOsupports CLID display for residential gateway ? > > > > > > Thanks/ > > > Rajendra > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 10:37:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25943 for ; Fri, 4 Aug 2000 10:37:26 -0400 (EDT) Received: from standards (47.234.32.16:2708) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85083@standards.nortelnetworks.com>; Fri, 4 Aug 2000 10:23:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7909 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 10:23:19 -0400 Received: from p-mail1.cnet.fr (192.144.74.31:3545) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85036@standards.nortelnetworks.com>; Fri, 4 Aug 2000 10:13:17 -0400 Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Aug 2000 16:24:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFFE1F.B2512C6E" Message-ID: <98388C05D464D111B61800805F150416012AF88C@p-ibis.issy.cnet.fr> Date: Fri, 4 Aug 2000 16:24:28 +0200 Reply-To: CHATRAS Bruno FTRD/DAC/ISS Sender: "Media Gateway Control (megaco)" From: CHATRAS Bruno FTRD/DAC/ISS Subject: Re: Calling Line Identification X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01BFFE1F.B2512C6E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I think that we need a more generic package that can support the transmission of dipaly information over an analog line. I see a need to support: a) On-hook transmission associated with ringing (Calling Line ID, = Calling Name ID, ...) b) On-hook transmission not associated with ringing (e.g.; notification services for message waiting indication) c) Off-hook transmission (calling Line ID presentation during call = waiting, text-based advice of charge, ...) In all cases, there shall be no restrictions on the type of message = (and parameters) to be sent over the analog line. I know that someone from Telcordia has presented a contribution on that topic to the ITU SG16 meeting in February'2000. The meeting reports indicates that the proposal was reasonnable but that more work was = required. I don't know what happened after that. I also attach for your information an alternative package description I drafted a few days ago. I'll not be able to work on it during the = cmming weeks (holiday !). However, if someone wants to... > -----Message d'origine----- > De: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Date: vendredi 4 ao=FBt 2000 15:50 > =C0: MEGACO@STANDARDS.NORTELNETWORKS.COM > Objet: Re: Calling Line Identification >=20 >=20 > Need a package. >=20 > Any volunteers? >=20 > Brian >=20 > > -----Original Message----- > > From: Rajendra Patil [mailto:rpatil@HSS.HNS.COM] > > Sent: Friday, August 04, 2000 7:57 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Calling Line Identification > > > > > > Hi, > > > > How MEGACOsupports CLID display for residential gateway ? > > > > Thanks/ > > Rajendra > > >=20 ------_=_NextPart_000_01BFFE1F.B2512C6E Content-Type: text/plain; name="eal-package.txt" Content-Disposition: attachment; filename="eal-package.txt" Content-Transfer-Encoding: quoted-printable Extended Analog Supervision Package PackageID: eal, 0x60002 Version: 1 Extends: Analog Line Supervision Description: This package extends the list of signals that can be = applied to an analog line. Properties None. Events Display Delivered EventID: dd (0x0010) Description: Indicates the successful delivery of textual information = on an analog line Display Undelivered EventID: du (0x0011) =09 Description: Indicates the failure of the delivery of textual = information on an analog line. Signals Pulse Generation SignalID: pg, 0x0008 =09 Description : Sends pulses on the line Signal Type: Timeout Duration: Provisioned Additional parameters Initial ParameterID: ini (0x0009) Type: integer value representing a number of initial pulses Default is 1 Interval ParameterID: int (0x000A) =09 Type: integer value representing the number of seconds between = pulses Default is infinite. Frequency ParameterID: fre (0x000B) =09 Type: integer in Hz Default is 12KHz Sdss SignalID: sdss (0x000C) =09 Description: Sends text over an analog line Signal Type: Timeout Duration: Provisioned Additional Parameters Display ParameterID: display (0x000D) Type: string containing the text to be sent over the analog line Default is provisioned (e.g. "----------") =09 Statistics None. Procedures When processing the "sdss" signal, the MG is responsible for handling = the following elements : - Selection and application of the Terminal Equipment Alerting Signal = (TAS), depending of the transmission mode and provisioning information = (e.g. ; Dual Tone for off-hook data transmission or Ringing Pulse for = on-hook transmission). - Insertion of the Channel Seizure Signal - Insertion of the Mark Signal - Check Sum calculation=20 - FSK modulation . The information received from the MG shall comprise the following = elements: - Message type tag (1 octet) - Message length (1 octet) - Set of parameters, each of which including a parameter tag (1 octet), = a parameter length (1 octet) and a value When on-hook transmission is not associated with ringing, it is = advisable for the MGC to request the notification of the "dd" and "du" = events so that it can release the call as soon as the transmission is = achieved (or in case of failure). ------_=_NextPart_000_01BFFE1F.B2512C6E-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 11:07:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06358 for ; Fri, 4 Aug 2000 11:07:08 -0400 (EDT) Received: from standards (47.234.32.16:1357) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB850B9@standards.nortelnetworks.com>; Fri, 4 Aug 2000 10:55:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8073 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 10:55:10 -0400 Received: from p-mail1.cnet.fr (192.144.74.31:4686) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB850B3@standards.nortelnetworks.com>; Fri, 4 Aug 2000 10:45:05 -0400 Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Aug 2000 16:56:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <98388C05D464D111B61800805F150416012AF88D@p-ibis.issy.cnet.fr> Date: Fri, 4 Aug 2000 16:56:11 +0200 Reply-To: CHATRAS Bruno FTRD/DAC/ISS Sender: "Media Gateway Control (megaco)" From: CHATRAS Bruno FTRD/DAC/ISS Subject: Re: Calling Line Identification X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA06358 Well, It's not easy to tell what is "reasonable" and what is not... The same issue could be raised for where the Generic Announcement package supports both fixed and variable announcements. Anyway, if we want to define more atomic packages for this new case, we first need to figure out which capabilities have a real impact on MG implementations and derive the number of packages from that. My feeling is that the MG does not need to be aware of the type of information which is actually sent to the terminal. The MGC shall provide a complete "presentation layer" frame, including the message type and lengh indicators. The MG does not need to check that the message type is known and that the parameters are valid for that message. What matters for the MG is the type of transmission (on-hook/off-hook) and possibly the presence/absence of ringing after the data transmission. Therefore I assume that we could go for three service-independent packages only. The first package "on-hook transmission associated with ringing" would be used to support Calling Line ID but also Calling Name ID or anything that needs to be displayed when a call is presented. Bruno, > -----Message d'origine----- > De: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Date: vendredi 4 août 2000 16:34 > À: MEGACO@STANDARDS.NORTELNETWORKS.COM > Objet: Re: Calling Line Identification > > > My concern here is that when you implement a package, you > implement all of > it, > and the extended capabilities you propose may be beyond what > a reasonable > implementation > of a simple CLID capability may provide. I could see a set > of packages each > extending > from the previous which could have capabilities you describe. > > Brian > > > -----Original Message----- > > From: CHATRAS Bruno FTRD/DAC/ISS > > [mailto:bruno.chatras@rd.francetelecom.fr] > > Sent: Friday, August 04, 2000 10:24 AM > > To: Rosen, Brian > > Cc: 'MEGACO@STANDARDS.NORTELNETWORKS.COM' > > Subject: RE: Calling Line Identification > > > > > > Hi, > > > > I think that we need a more generic package that can support the > > transmission of dipaly information over an analog line. > > > > I see a need to support: > > > > a) On-hook transmission associated with ringing (Calling Line > > ID, Calling > > Name ID, ...) > > > > b) On-hook transmission not associated with ringing (e.g.; > > notification > > services for message waiting indication) > > > > c) Off-hook transmission (calling Line ID presentation during > > call waiting, > > text-based advice of charge, ...) > > > > In all cases, there shall be no restrictions on the type of > > message (and > > parameters) to be sent over the analog line. > > > > I know that someone from Telcordia has presented a > > contribution on that > > topic to the ITU SG16 meeting in February'2000. The meeting reports > > indicates that the proposal was reasonnable but that more > > work was required. > > I don't know what happened after that. > > > > I also attach for your information an alternative package > > description I > > drafted a few days ago. I'll not be able to work on it during > > the cmming > > weeks (holiday !). However, if someone wants to... > > > > > > > > > -----Message d'origine----- > > > De: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > > Date: vendredi 4 août 2000 15:50 > > > À: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Objet: Re: Calling Line Identification > > > > > > > > > Need a package. > > > > > > Any volunteers? > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Rajendra Patil [mailto:rpatil@HSS.HNS.COM] > > > > Sent: Friday, August 04, 2000 7:57 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Calling Line Identification > > > > > > > > > > > > Hi, > > > > > > > > How MEGACOsupports CLID display for residential gateway ? > > > > > > > > Thanks/ > > > > Rajendra > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 21:09:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10308 for ; Fri, 4 Aug 2000 21:09:53 -0400 (EDT) Received: from standards (47.234.32.16:1542) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8539F@standards.nortelnetworks.com>; Fri, 4 Aug 2000 20:57:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9111 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 20:57:50 -0400 Received: from empowertel.com (64.220.200.243:58141) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8539B@standards.nortelnetworks.com>; Fri, 4 Aug 2000 20:47:50 -0400 Received: from Rajeev ([192.168.111.39]) by empowertel.com (8.9.3+Sun/8.9.3) with SMTP id RAA11343; Fri, 4 Aug 2000 17:56:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0115_01BFFE3D.DB4A4100" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <011401bffe78$87a91900$276fa8c0@empowertel.com> Date: Fri, 4 Aug 2000 18:00:20 -0700 Reply-To: rajeev@empowertel.com Sender: "Media Gateway Control (megaco)" From: Rajeev Gupta Subject: Re: MG and DiffServ X-To: "James M. Polk" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4.1.20000804090404.00c056a0@diablo.cisco.com> This is a multi-part message in MIME format. ------=_NextPart_000_0115_01BFFE3D.DB4A4100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Presumably different QoS may be applied to each voice call depending on parameters such as codec, VAD, customer's tolerance for quality. This is dynamically determined by the MGC, and can be indicated to the MG, so the MG can select a suitable QoS path. It is not clear who is setting up the QoS path - one model is that the MGC simply indicates to the MG the required QoS, and leaves it to the MG to select the correct mechanism to get the required QoS e.g. if the MGs are connected over an MPLS network, the MG may use RSVP to setup the QoS/label for the voice path. In a trunking application, the MGs may have (MPLS) trunks setup among themselves, perhaps different trunks for different QoS types, and the MG directs the RTP stream to the trunk that matches the QoS for the call. Rajeev Gupta empowerTel Networks 475 Sycamore Drive, Milpitas, CA 95035 Phone: +1 408 519 7136 Fax: +1 408 519 7420 mailto:rajeev@empowertel.com http://www.empowertel.com -----Original Message----- From: Media Gateway Control (megaco) [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of James M. Polk Sent: Friday, August 04, 2000 7:13 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: MG and DiffServ Petros Who is providing the Service for you Voice traffic? If that is a Telecommunications Service Provider (as defined by the US FCC), then you won't have that choice across their network (I don't believe). If that is from an Enterprise-based Call Agent (MGC), then I'd be surprised if that were legally allowed to separate this traffic if that Enterprise has the MGC or Call Agent for Signaling to/from your MG. I think you'll have to somehow get the traffic you want to be EF marked across a Telecom SP and have your Greece-bound traffic across some other network entirely, then this will work. But (I think) the same MGC cannot signal both your Greece destination traffic and the rest of your Voice traffic (as they would be separate networks for signaling). One way around that is a Peer-to-Peer signaling Protocol like H.323 or SIP from a computer (NetMeeting for example) going best effort to the Internet for that best effort traffic, and your phones remain on that Telecom SP's MGC and of EF marked packets and high quality. At 09:46 AM 8/4/2000 -0400, Petros N. Mouchtaris wrote: > > >I have a specific case that your approach does not support. I may have >misunderstood your comments so please let me know if I'm incorrect. TI think >this case is reasonable and should be supported: > >I'd like all my voice to receive premium quality except for my calls to Greece >where I'm willing to accept best effort quality so that those calls to Greece >are virtually free. This will help me keep up with all my friends and family >there. > >I expect that the MGC will maintain this policy and not my phone. Let me know >what you think. > >Petros > > > > > >"James M. Polk" on 08/04/2000 09:28:26 AM > >Please respond to "James M. Polk" > >To: MEGACO@standards.nortelnetworks.com >cc: (bcc: Petros N. Mouchtaris/Telcordia) >Subject: Re: MG and DiffServ > > > > > >All > >Shouldn't this be defined by other mechanisms by default? > >For example, typically the MG is dumb and requires a config image from some >TFTP server. A template config is usually utilized that should set the default >DSCP to a value that likely won't change. This isn't a Protocol issue, I don't >think, it's a semantics issue. > >Another example, the port the MG is physically connected to on the Enet Switch >sets the traffic to a specific Voice VLAN. Again, this isn't a Protocol issue. > >Another example, the Enet Switch knows that a MG is what's attached to a >specific port and sets all incoming traffic to a defined DSCP value -- again, >not a Protocol issue. > >I think, typically, a Protocol deals with things that are negotiated. I yet >don't see why a MG (IP Phone) which is almost always getting its config file(s) >from a Server (MGC?) that it will yet need to have anything other than the one >default value (even if that is EF marked) which that Domain Administrator >assigns to all Voice traffic within that Domain. > >I believe the same should apply to a MG that's a PSTN to IP Gateway. There >actually cannot be a priority change from the PSTN to the IP network in this >example by law, if that IP Network is providing a Telecommunications Service >(although I'm not sure that 'law' is the right word -- I just know MLPP cannot >be run on the PSTN or like network-types). Therefore, all inbound IP Voice >related traffic must have the same value as all other Voice traffic to those >types of providers. > >I know Fred Baker is very resistant to the idea of Voice traffic having >multiple Forwarding queue behaviors within an internetworking device (i.e. >multiple levels of EF for dropping), so this would suggest the DSCP other than >EF isn't preferred by him (and others). His belief - and I'm not yet sure it's >correct in the long term - is that this is a session issue, not a forwarding >issue; therefore this is an RSVP/COPS Prioritization issue, isn't it? > > >At 06:01 PM 8/3/2000 -0700, Bill Foster wrote: >>Given that the MGC is often defining policy and QoS use is an important >>policy, it would be useful to have the capability. >> >>At 04:34 PM 8/3/00 -0700, S KA N wrote: >>>Hi There, >>> >>>If you can recall the meaning of DiffServ, its for >>>implementing differentiated services in the Internet. >>>Which basically means giving QoS to specially marked >>>data traffic. Now if you look at the requirements >>>specified in Section 5.5 of RFC2805, it says that >>>the MGCP protocol should support the ability to >>>specify QoS for the connection between MGs, etc. >>> >>>Any comment. >>> >>>...SKAN >>> >>> >>> >>> > There's a difference between an operator's RFP >>> > requiring that their MGs >>> > support DiffServ and a protocol dependency on such >>> > support. Megaco has no >>> > such dependency. >>> > >>> > > -----Original Message----- >>> > > From: S KA N [SMTP:s_ka_n@YAHOO.COM] >>> > > Sent: Wednesday, August 02, 2000 3:26 PM >>> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM >>> > > Subject: MG and DiffServ >>> > > >>> > > Hi, >>> > > >>> > > Can you think of any relation between the MG and >>> > > DiffServ? >>> > > >>> > > If a privately managed IP network is DiffServ >>> > > compliant and suppose if the same network >>> > > is going to be used for VoIP purposes also. Don't >>> > > we require the MGs to be DiffServ compliant? >>> > > >>> > > Any help/comment would be appreciated. >>> > > >>> > > ...SKAN >>> >>> >>>__________________________________________________ >>>Do You Yahoo!? >>>Kick off your party with Yahoo! Invites. >>>http://invites.yahoo.com/ >> >>----------------------------- >>Bill Foster >>Phone: (408) 527-8791 >>Page: (800) 365-4578 >>Fax: (781) 998-6492 >> > >************************************* >"At the end of the day... the most committed win!" > >James M. Polk >Sr. Product Manager, Multiservice Architecture and Standards >Enterprise Voice Business Unit >Cisco Systems >Dallas, Texas >w) 972.813.5208 >f) 972.813.5280 >www.cisco.com > ************************************* "At the end of the day... the most committed win!" James M. Polk Sr. Product Manager, Multiservice Architecture and Standards Enterprise Voice Business Unit Cisco Systems Dallas, Texas w) 972.813.5208 f) 972.813.5280 www.cisco.com ------=_NextPart_000_0115_01BFFE3D.DB4A4100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Presumably different QoS may be applied to each voice call = depending on=20 parameters such as codec, VAD, customer's tolerance for quality. This is = dynamically determined by the MGC, and can be indicated to the MG, so = the MG can=20 select a suitable QoS path. It is not clear who is setting up the QoS = path - one=20 model is that the MGC simply indicates to the MG the required QoS, and = leaves it=20 to the MG to select the correct mechanism to get the required QoS e.g.=20 if the MGs are=20 connected over an MPLS network, the MG may use RSVP to setup the = QoS/label for=20 the voice path. In a trunking application, the MGs may have (MPLS) = trunks setup=20 among themselves, perhaps different trunks for different QoS types, and = the MG=20 directs the RTP stream to the trunk that matches the QoS for the=20 call.

Rajeev Gupta =
empowerTel Networks
475 Sycamore Drive, Milpitas, CA = 95035=20
Phone: +1 408 519 7136 =
Fax: +1 408 519 7420
mailto:rajeev@empowertel.com=20
http://www.empowertel.com =

-----Original Message-----
From: Media Gateway = Control=20 (megaco) [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of = James=20 M. Polk
Sent: Friday, August 04, 2000 7:13 AM
To:=20 MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: MG and=20 DiffServ

Petros

Who is providing the Service for you Voice traffic? If that is a=20 Telecommunications Service Provider (as defined by the US FCC), then = you won't=20 have that choice across their network (I don't believe). If that is = from an=20 Enterprise-based Call Agent (MGC), then I'd be surprised if that were = legally=20 allowed to separate this traffic if that Enterprise has the MGC or = Call Agent=20 for Signaling to/from your MG.

I think you'll have to somehow get the traffic you want to be EF = marked=20 across a Telecom SP and have your Greece-bound traffic across some = other=20 network entirely, then this will work. But (I think) the same MGC = cannot=20 signal both your Greece destination traffic and the rest of your Voice = traffic=20 (as they would be separate networks for signaling).

One way around that is a Peer-to-Peer signaling Protocol like = H.323 or=20 SIP from a computer (NetMeeting for example) going best effort to the = Internet=20 for that best effort traffic, and your phones remain on that Telecom = SP's MGC=20 and of EF marked packets and high quality.

At 09:46 AM 8/4/2000 -0400, Petros N. Mouchtaris wrote:
>
>
>I have a specific case that your approach does not support. I = may=20 have
>misunderstood your comments so please let me know if I'm = incorrect.=20 TI think
>this case is reasonable and should be supported:
>
>I'd like all my voice to receive premium quality except for = my calls=20 to Greece
>where I'm willing to accept best effort quality so that those = calls=20 to Greece
>are virtually free. This will help me keep up with all my = friends and=20 family
>there.
>
>I expect that the MGC will maintain this policy and not my=20 phone.  Let me know
>what you think.
>
>Petros
>
>
>
>
>
>"James M. Polk" <jmpolk@cisco.com> on 08/04/2000 = 09:28:26=20 AM
>
>Please respond to "James M. Polk" = <jmpolk@cisco.com>
>
>To:   MEGACO@standards.nortelnetworks.com
>cc:    (bcc: Petros N. = Mouchtaris/Telcordia)
>Subject:  Re: MG and DiffServ
>
>
>
>
>
>All
>
>Shouldn't this be defined by other mechanisms by = default?
>
>For example, typically the MG is dumb and requires a config = image=20 from some
>TFTP server. A template config is usually utilized that = should set=20 the default
>DSCP to a value that likely won't change. This isn't a = Protocol=20 issue, I don't
>think, it's a semantics issue.
>
>Another example, the port the MG is physically connected to = on the=20 Enet Switch
>sets the traffic to a specific Voice VLAN. Again, this isn't = a=20 Protocol issue.
>
>Another example, the Enet Switch knows that a MG is what's = attached=20 to a
>specific port and sets all incoming traffic to a defined DSCP = value=20 -- again,
>not a Protocol issue.
>
>I think, typically, a Protocol deals with things that are = negotiated.=20 I yet
>don't see why a MG (IP Phone) which is almost always getting = its=20 config file(s)
>from a Server (MGC?) that it will yet need to have anything = other=20 than the one
>default value (even if that is EF marked) which that Domain=20 Administrator
>assigns to all Voice traffic within that Domain.
>
>I believe the same should apply to a MG that's a PSTN to IP = Gateway.=20 There
>actually cannot be a priority change from the PSTN to the IP = network=20 in this
>example by law, if that IP Network is providing a = Telecommunications=20 Service
>(although I'm not sure that 'law' is the right word -- I just = know=20 MLPP cannot
>be run on the PSTN or like network-types). Therefore, all = inbound IP=20 Voice
>related traffic must have the same value as all other Voice = traffic=20 to those
>types of providers.
>
>I know Fred Baker is very resistant to the idea of Voice = traffic=20 having
>multiple Forwarding queue behaviors within an internetworking = device=20 (i.e.
>multiple levels of EF for dropping), so this would suggest = the DSCP=20 other than
>EF isn't preferred by him (and others). His belief - and I'm = not yet=20 sure it's
>correct in the long term - is that this is a session issue, = not a=20 forwarding
>issue; therefore this is an RSVP/COPS Prioritization issue, = isn't=20 it?
>
>
>At 06:01 PM 8/3/2000 -0700, Bill Foster wrote:
>>Given that the MGC is often defining policy and QoS use = is an=20 important
>>policy, it would be useful to have the capability.
>>
>>At 04:34 PM 8/3/00 -0700, S KA N wrote:
>>>Hi There,
>>>
>>>If you can recall the meaning of DiffServ, its = for
>>>implementing differentiated services in the = Internet.
>>>Which basically means giving QoS to specially = marked
>>>data traffic. Now if you look at the = requirements
>>>specified in Section 5.5 of RFC2805, it says = that
>>>the MGCP protocol should support the ability to
>>>specify QoS for the connection between MGs, = etc.
>>>
>>>Any comment.
>>>
>>>...SKAN
>>>
>>>
>>>
>>> > There's a difference between an operator's = RFP
>>> > requiring that their MGs
>>> > support DiffServ and a protocol dependency on=20 such
>>> > support.  Megaco has no
>>> > such dependency.
>>> >
>>> > > -----Original Message-----
>>> > > From:       = S KA N=20 [SMTP:s_ka_n@YAHOO.COM]
>>> > > Sent:      =20 Wednesday, August 02, 2000 3:26 PM
>>> > > To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
>>> > > Subject:    MG and = DiffServ
>>> > >
>>> > > Hi,
>>> > >
>>> > > Can you think of any relation between the = MG=20 and
>>> > > DiffServ?
>>> > >
>>> > > If a privately managed IP network is=20 DiffServ
>>> > > compliant and suppose if the same = network
>>> > > is going to be used for VoIP purposes = also.=20 Don't
>>> > > we require the MGs to be DiffServ = compliant?
>>> > >
>>> > > Any help/comment would be = appreciated.
>>> > >
>>> > > ...SKAN
>>>
>>>
=
>>>__________________________________________________
=
>>>Do You Yahoo!?
>>>Kick off your party with Yahoo! Invites.
>>
>>-----------------------------
>>Bill Foster
>>Phone: (408) 527-8791
>>Page:   (800) 365-4578
>>Fax:     (781) 998-6492
>>
>
>*************************************
>"At the end of the day... the most committed win!"
>
>James M. Polk
>Sr. Product Manager, Multiservice Architecture and = Standards
>Enterprise Voice Business Unit
>Cisco Systems
>Dallas, Texas
>w) 972.813.5208
>f)  972.813.5280
>

*************************************
"At the = end of the=20 day... the most committed win!"

James M. Polk
Sr. = Product=20 Manager, Multiservice Architecture and Standards
Enterprise Voice = Business=20 Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f) =20 972.813.5280
www.cisco.com
------=_NextPart_000_0115_01BFFE3D.DB4A4100-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 21:34:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16232 for ; Fri, 4 Aug 2000 21:34:21 -0400 (EDT) Received: from standards (47.234.32.16:2947) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB853BD@standards.nortelnetworks.com>; Fri, 4 Aug 2000 21:22:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9152 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 21:22:40 -0400 Received: from firewall.chttl.com.tw (gate.chttl.com.tw) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB853BA@standards.nortelnetworks.com>; Fri, 4 Aug 2000 21:12:39 -0400 Received: from ms.chttl.com.tw (ms.tl.gov.tw. [10.144.2.104]) by firewall.chttl.com.tw (8.9.3/8.9.3) with ESMTP id JAA11474 for ; Sat, 5 Aug 2000 09:23:14 +0800 (CST) Received: from bigman ([10.144.200.130]) by ms.chttl.com.tw (8.9.3/8.9.3) with SMTP id JAA01632 for ; Sat, 5 Aug 2000 09:26:48 +0800 (CST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01BFFEBE.CEA319A0" 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 Message-ID: <001601bffe7b$c0dcedc0$82c8900a@chttl.com.tw> Date: Sat, 5 Aug 2000 09:23:25 +0800 Reply-To: =?big5?B?s3Or26l2?= Sender: "Media Gateway Control (megaco)" From: =?big5?B?s3Or26l2?= Subject: Extended package To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0013_01BFFEBE.CEA319A0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Is there any example of extended packages of MEGACO? Can both packages with different version coexist in the MG? If yes, = which version the package in the command is referred to for. ------=_NextPart_000_0013_01BFFEBE.CEA319A0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Is there any example of extended packages of=20 MEGACO?
Can both packages with different version coexist in = the MG? If=20 yes, which version the package in the command is referred to=20 for.
------=_NextPart_000_0013_01BFFEBE.CEA319A0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 23:04:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08446 for ; Fri, 4 Aug 2000 23:04:41 -0400 (EDT) Received: from standards (47.234.32.16:4833) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB853E8@standards.nortelnetworks.com>; Fri, 4 Aug 2000 22:52:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9207 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 22:52:54 -0400 Received: from marie.nada.co.kr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB853E7@standards.nortelnetworks.com>; Fri, 4 Aug 2000 22:52:53 -0400 Received: from vctest1 ([192.168.1.153]) by marie.nada.co.kr (8.9.3/8.9.3) with SMTP id MAA06893 for ; Sat, 5 Aug 2000 12:08:38 +0900 References: <4FBEA8857476D311A03300204840E1CF67868F@whq-msgusr-02.fore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: <002c01bffe8a$2a2ce330$9901a8c0@nadatel.com> Date: Sat, 5 Aug 2000 12:06:34 +0900 Reply-To: Junyoung Heo Sender: "Media Gateway Control (megaco)" From: Junyoung Heo Subject: Re: About mixing and topology To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id XAA08446 Thanks for answer, but I need more help. draft-ietf-megaco-merged-01.txt page 39 shows when no topology descriptor. T1 / \ T2 ---- T3 Can I think it is a star topology? Finally, I need "everyone SEEs ANYone else". So, I want to control whose video is mixed. How to use [T1, T2, association] form for my purpose? Sorry for my ugly english. I'm poor at writing English. --;; Best regards. ----- Original Message ----- From: "Rosen, Brian" To: "'Junyoung Heo'" ; Sent: Friday, August 04, 2000 10:49 PM Subject: RE: About mixing and topology > I cannot completely understand your question. > > The text describes how you use TOPOLOGY to control a device that uses > a "star" topology mixer. So I think the text is clear on how you enable > mixing among terminations data when the mixer is a "everyone hears everyone > else" > type of mix. > > What the text is not clear on is how you use topology when the mixer is > not a "star". That is a known limitation, which was agreed to be deferred > to > a later edition. > > Brian > > > -----Original Message----- > From: Junyoung Heo [mailto:green@NADATEL.COM] > Sent: Friday, August 04, 2000 1:19 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: About mixing and topology > > > I have just read megaco draft documnet. > I will use megaco as protocol between MC and MP. > > I choose megaco because its topology property. > But, I can't find how to describe topology to enable mixing among > terminations' data. > > How can I make it? > > Regards, > > Junyoung Heo > 2000/08/04 > KOREA From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Aug 5 18:07:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03821 for ; Sat, 5 Aug 2000 18:07:40 -0400 (EDT) Received: from standards (47.234.32.16:2968) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB855CC@standards.nortelnetworks.com>; Sat, 5 Aug 2000 17:55:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9797 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 5 Aug 2000 17:55:30 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB855CB@standards.nortelnetworks.com>; Sat, 5 Aug 2000 17:55:29 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA24945; Sat, 5 Aug 2000 18:06:53 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA06582; Sat, 5 Aug 2000 18:06:56 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Sat, 5 Aug 2000 18:06:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="KS_C_5601-1987" Message-ID: <4FBEA8857476D311A03300204840E1CF6786AA@whq-msgusr-02.fore.com> Date: Sat, 5 Aug 2000 18:06:51 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: About mixing and topology X-To: Junyoung Heo To: MEGACO@STANDARDS.NORTELNETWORKS.COM At "star" connection is "everyone hears everyone else", so the default topology illustrates that connection; T1 hears T2 and T3, T2 hears T1 and T3, T3 hears T1 and T2. If your video mixer has an equivalent function, then the topology descriptor will be perfect for your application. If the mixer has some other behavior (say, quadrants, with four inputs sent to all parties identically), the current text does not define how you would use Topology. Brian -----Original Message----- From: Junyoung Heo To: MEGACO@STANDARDS.NORTELNETWORKS.COM Sent: 8/4/00 11:06 PM Subject: Re: About mixing and topology Thanks for answer, but I need more help. draft-ietf-megaco-merged-01.txt page 39 shows when no topology descriptor. T1 / \ T2 ---- T3 Can I think it is a star topology? Finally, I need "everyone SEEs ANYone else". So, I want to control whose video is mixed. How to use [T1, T2, association] form for my purpose? Sorry for my ugly english. I'm poor at writing English. --;; Best regards. ----- Original Message ----- From: "Rosen, Brian" To: "'Junyoung Heo'" ; Sent: Friday, August 04, 2000 10:49 PM Subject: RE: About mixing and topology > I cannot completely understand your question. > > The text describes how you use TOPOLOGY to control a device that uses > a "star" topology mixer. So I think the text is clear on how you enable > mixing among terminations data when the mixer is a "everyone hears everyone > else" > type of mix. > > What the text is not clear on is how you use topology when the mixer is > not a "star". That is a known limitation, which was agreed to be deferred > to > a later edition. > > Brian > > > -----Original Message----- > From: Junyoung Heo [mailto:green@NADATEL.COM] > Sent: Friday, August 04, 2000 1:19 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: About mixing and topology > > > I have just read megaco draft documnet. > I will use megaco as protocol between MC and MP. > > I choose megaco because its topology property. > But, I can't find how to describe topology to enable mixing among > terminations' data. > > How can I make it? > > Regards, > > Junyoung Heo > 2000/08/04 > KOREA From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Aug 6 04:27:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09365 for ; Sun, 6 Aug 2000 04:27:53 -0400 (EDT) Received: from standards (47.234.32.16:2985) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB856D0@standards.nortelnetworks.com>; 6 Aug 2000 4:15:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10127 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 6 Aug 2000 04:15:46 -0400 Received: from qhars002.nortel.com (47.101.112.102:33910) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB856CF@standards.nortelnetworks.com>; 6 Aug 2000 4:15:46 -0400 Received: from zrtps06s.us.nortel.com (actually 47.140.48.50) by qhars002.nortel.com; Sun, 6 Aug 2000 09:23:07 +0100 Received: from zmers013 (actually zmers013.ca.nortel.com) by zrtps06s.us.nortel.com; Sun, 6 Aug 2000 04:23:05 -0400 Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by zmers013; Sun, 6 Aug 2000 04:22:55 -0400 Received: from cpm.elex.co.il (cpm.elex.co.il [141.226.9.254]) by tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA09820 for ; Sun, 6 Aug 2000 11:21:42 +0300 (IDT) Received: from Dan by cpm.elex.co.il (8.8.8+Sun/SMI-SVR4) id LAA24115; Sun, 6 Aug 2000 11:21:41 +0300 (IDT) MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Orig: Message-ID: <000d01bfff87$400fac20$4609e28d@elex.co.il> Date: Sun, 6 Aug 2000 11:18:13 +0200 Reply-To: "Davidson, Dan" Sender: "Media Gateway Control (megaco)" From: "Davidson, Dan" Subject: Re: Calling Line Identification To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Lets keep in mind that caller ID, caller Name and other similar features can be received also during an active call: the SCWID service - Spontaneous Call Wait ID. Cheers, Dan > Well, It's not easy to tell what is "reasonable" and what is not... The same > issue could be raised for where the Generic > Announcement package supports both fixed and variable announcements. > Anyway, if we want to define more atomic packages for this new case, we > first need to figure out which capabilities have a real impact on MG > implementations and derive the number of packages from that. My feeling is > that the MG does not need to be aware of the type of information which is > actually sent to the terminal. The MGC shall provide a complete > "presentation layer" frame, including the message type and lengh indicators. > The MG does not need to check that the message type is known and that the > parameters are valid for that message. What matters for the MG is the type > of transmission (on-hook/off-hook) and possibly the presence/absence of > ringing after the data transmission. Therefore I assume that we could go for > three service-independent packages only. > The first package "on-hook transmission associated with ringing" would be > used to support Calling Line ID but also Calling Name ID or anything that > needs to be displayed when a call is presented. >Bruno, > -----Message d'origine----- > De: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Date: vendredi 4 ao?t 2000 16:34 > ?: MEGACO@STANDARDS.NORTELNETWORKS.COM > Objet: Re: Calling Line Identification > > > My concern here is that when you implement a package, you > implement all of > it, > and the extended capabilities you propose may be beyond what > a reasonable > implementation > of a simple CLID capability may provide. I could see a set > of packages each > extending > from the previous which could have capabilities you describe. > > Brian > > > -----Original Message----- > > From: CHATRAS Bruno FTRD/DAC/ISS > > [mailto:bruno.chatras@rd.francetelecom.fr] > > Sent: Friday, August 04, 2000 10:24 AM > > To: Rosen, Brian > > Cc: 'MEGACO@STANDARDS.NORTELNETWORKS.COM' > > Subject: RE: Calling Line Identification > > > > > > Hi, > > > > I think that we need a more generic package that can support the > > transmission of dipaly information over an analog line. > > > > I see a need to support: > > > > a) On-hook transmission associated with ringing (Calling Line > > ID, Calling > > Name ID, ...) > > > > b) On-hook transmission not associated with ringing (e.g.; > > notification > > services for message waiting indication) > > > > c) Off-hook transmission (calling Line ID presentation during > > call waiting, > > text-based advice of charge, ...) > > > > In all cases, there shall be no restrictions on the type of > > message (and > > parameters) to be sent over the analog line. > > > > I know that someone from Telcordia has presented a > > contribution on that > > topic to the ITU SG16 meeting in February'2000. The meeting reports > > indicates that the proposal was reasonnable but that more > > work was required. > > I don't know what happened after that. > > > > I also attach for your information an alternative package > > description I > > drafted a few days ago. I'll not be able to work on it during > > the cmming > > weeks (holiday !). However, if someone wants to... > > > > > > > > > -----Message d'origine----- > > > De: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > > Date: vendredi 4 ao?t 2000 15:50 > > > ?: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Objet: Re: Calling Line Identification > > > > > > > > > Need a package. > > > > > > Any volunteers? > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Rajendra Patil [mailto:rpatil@HSS.HNS.COM] > > > > Sent: Friday, August 04, 2000 7:57 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Calling Line Identification > > > > > > > > > > > > Hi, > > > > > > > > How MEGACOsupports CLID display for residential gateway ? > > > > > > > > Thanks/ > > > > Rajendra > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Aug 6 12:15:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14097 for ; Sun, 6 Aug 2000 12:15:17 -0400 (EDT) Received: from standards (47.234.32.16:2551) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85772@standards.nortelnetworks.com>; 6 Aug 2000 12:03:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10336 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 6 Aug 2000 12:03:12 -0400 Received: from mars.hss.co.in (202.54.26.197:40341) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85771@standards.nortelnetworks.com>; 6 Aug 2000 12:03:10 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e768rWq26558 for ; Sun, 6 Aug 2000 14:27:17 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256933.002FE0A2 ; Sun, 6 Aug 2000 14:12:56 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256933.002FDEFD.00@sandesh.hss.hns.com> Date: Sun, 6 Aug 2000 14:17:48 +0530 Reply-To: rezhirpavai@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: rezhirpavai@HSS.HNS.COM Subject: Amm request To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello, Sections 7.2.1 (Add Command), 7.2.2 (Modify Command), 7.2.4 (Move Command), donot talk about event buffer descriptor that could be sent along with these commands !!!!!!!!! But grammer does support Event Buffer Descriptor in these commands. Regards, R. Ezhirpavai From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 7 03:38:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25704 for ; Mon, 7 Aug 2000 03:38:43 -0400 (EDT) Received: from standards (47.234.32.16:2216) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB858D7@standards.nortelnetworks.com>; Mon, 7 Aug 2000 3:22:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10740 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Aug 2000 03:22:52 -0400 Received: from arianne.ishoni.com (164.164.83.132:1310) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB858C9@standards.nortelnetworks.com>; Mon, 7 Aug 2000 3:12:50 -0400 Received: from sarunk (sarunk [192.168.1.96]) by arianne.ishoni.com (8.9.3/8.9.3) with SMTP id MAA05984 for ; Mon, 7 Aug 2000 12:57:45 +0530 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Message-ID: Date: Mon, 7 Aug 2000 13:04:18 +0530 Reply-To: sarunk@ishoni.com Sender: "Media Gateway Control (megaco)" From: Arun Kumar S Subject: Clarification on Endpoint Identifier in RQNT To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, I wanted a clarification on the endpoint identifier naming conventions for the RQNT message. To quote from rfc2705, "EndpointId is the name for the endpoint in the gateway where NotificationRequest executes, as defined in section 2.1.1." The rfc does not specify the whether the endpoint id can be under-specified using the "any of" or "all" wildcard naming convention. - Is it possible for the endpoint id to be under-specified? - If so, can both the wild-cards (any of / all) be used within the endpoint id of RQNT? Regards, ___________________________________________________ Arun Kumar S ishoni Networks (India) Pvt Ltd (http://www.ishoni.com) ...Broadband for everyone email: sarunk@ishoni.com Phone: +91-80-2292125 (Work) Fax: +91-80-2995545 (Work) From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 7 11:36:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25785 for ; Mon, 7 Aug 2000 11:36:55 -0400 (EDT) Received: from standards (47.234.32.16:2795) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85A7C@standards.nortelnetworks.com>; Mon, 7 Aug 2000 11:24:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11259 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Aug 2000 11:24:13 -0400 Received: from eratosthenes.zen.co.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85A66@standards.nortelnetworks.com>; Mon, 7 Aug 2000 11:14:12 -0400 Received: (qmail 17838 invoked from network); 7 Aug 2000 15:25:40 -0000 Received: from 116.locke.zen.co.uk (HELO mike) (212.23.16.116) by eratosthenes.zen.co.uk with SMTP for ; 7 Aug 2000 15:25:40 -0000 X-Envelope-To: rajeev@empowertel.com References: <011401bffe78$87a91900$276fa8c0@empowertel.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01C0008C.09BD5B80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <006a01c00083$acf30f60$b61017d4@mike> Date: Mon, 7 Aug 2000 16:25:02 +0100 Reply-To: Mike Buckley Sender: "Media Gateway Control (megaco)" From: Mike Buckley Subject: Re: MG and DiffServ X-To: rajeev@empowertel.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0067_01C0008C.09BD5B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ETSI TIPHON have been looking at the problem of end to end QoS control = in a mixed IP/circuit switched environment, in particular the general = case where a number of separate transport domains and service providers = are involved in the call; each transport domain possibly supporting a = different QoS mechanism. =20 Within the TIPHON architecture a clear distinction is drawn between = application and transport. The former being IP telephony and the latter = IP (or ATM/frame relay) transport. The required QoS is clearly an issue = for the application, in particular the agreement between user and = service provider. However the speech QoS required has to be translated = to parameters that can be controlled in the transport domain. e.g. = delay, jitter and packet loss. Diff Serv, RSVP/Intserv, MPLS are = generic transport domain mechanism that help deliver the delay, jitter = and packet loss requirements required by the application. The MGC is entirely in the application domain and it is at this level = that required end to end QoS is established and authorised. The MG = however spans both transport and application domains. Media conversion, = and possibly RTP, are part of the application, but IP and UDP = termination and the QoS mechanisms that go with them are definitely = transport. So within the TIPHON architecture there would be no need to = signal issues related to the particular transport QoS mechanism in = Megaco (these would be internal to the MG), however delay, jitter and = packet loss parameters would be required. Further details of the TIPHON = model can be found in. http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/DTS0= 5003/V0.8.1/DTS-5003v0.8.1.zip Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley@44comms.com ----- Original Message -----=20 From: Rajeev Gupta=20 To: MEGACO@STANDARDS.NORTELNETWORKS.COM=20 Sent: Saturday, August 05, 2000 2:00 AM Subject: Re: MG and DiffServ Presumably different QoS may be applied to each voice call depending = on parameters such as codec, VAD, customer's tolerance for quality. This = is dynamically determined by the MGC, and can be indicated to the MG, so = the MG can select a suitable QoS path. It is not clear who is setting up = the QoS path - one model is that the MGC simply indicates to the MG the = required QoS, and leaves it to the MG to select the correct mechanism to = get the required QoS e.g. if the MGs are connected over an MPLS network, = the MG may use RSVP to setup the QoS/label for the voice path. In a = trunking application, the MGs may have (MPLS) trunks setup among = themselves, perhaps different trunks for different QoS types, and the MG = directs the RTP stream to the trunk that matches the QoS for the call. Rajeev Gupta=20 empowerTel Networks=20 475 Sycamore Drive, Milpitas, CA 95035=20 Phone: +1 408 519 7136=20 Fax: +1 408 519 7420=20 mailto:rajeev@empowertel.com=20 http://www.empowertel.com=20 -----Original Message----- From: Media Gateway Control (megaco) = [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of James M. Polk Sent: Friday, August 04, 2000 7:13 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: MG and DiffServ Petros Who is providing the Service for you Voice traffic? If that is a = Telecommunications Service Provider (as defined by the US FCC), then you = won't have that choice across their network (I don't believe). If that = is from an Enterprise-based Call Agent (MGC), then I'd be surprised if = that were legally allowed to separate this traffic if that Enterprise = has the MGC or Call Agent for Signaling to/from your MG. I think you'll have to somehow get the traffic you want to be EF = marked across a Telecom SP and have your Greece-bound traffic across = some other network entirely, then this will work. But (I think) the same = MGC cannot signal both your Greece destination traffic and the rest of = your Voice traffic (as they would be separate networks for signaling). One way around that is a Peer-to-Peer signaling Protocol like H.323 = or SIP from a computer (NetMeeting for example) going best effort to the = Internet for that best effort traffic, and your phones remain on that = Telecom SP's MGC and of EF marked packets and high quality. At 09:46 AM 8/4/2000 -0400, Petros N. Mouchtaris wrote: > > >I have a specific case that your approach does not support. I may = have >misunderstood your comments so please let me know if I'm incorrect. = TI think >this case is reasonable and should be supported: > >I'd like all my voice to receive premium quality except for my = calls to Greece >where I'm willing to accept best effort quality so that those calls = to Greece >are virtually free. This will help me keep up with all my friends = and family >there. > >I expect that the MGC will maintain this policy and not my phone. = Let me know >what you think. > >Petros > > > > > >"James M. Polk" on 08/04/2000 09:28:26 AM > >Please respond to "James M. Polk" > >To: MEGACO@standards.nortelnetworks.com >cc: (bcc: Petros N. Mouchtaris/Telcordia) >Subject: Re: MG and DiffServ > > > > > >All > >Shouldn't this be defined by other mechanisms by default? > >For example, typically the MG is dumb and requires a config image = from some >TFTP server. A template config is usually utilized that should set = the default >DSCP to a value that likely won't change. This isn't a Protocol = issue, I don't >think, it's a semantics issue. > >Another example, the port the MG is physically connected to on the = Enet Switch >sets the traffic to a specific Voice VLAN. Again, this isn't a = Protocol issue. > >Another example, the Enet Switch knows that a MG is what's attached = to a >specific port and sets all incoming traffic to a defined DSCP value = -- again, >not a Protocol issue. > >I think, typically, a Protocol deals with things that are = negotiated. I yet >don't see why a MG (IP Phone) which is almost always getting its = config file(s) >from a Server (MGC?) that it will yet need to have anything other = than the one >default value (even if that is EF marked) which that Domain = Administrator >assigns to all Voice traffic within that Domain. > >I believe the same should apply to a MG that's a PSTN to IP = Gateway. There >actually cannot be a priority change from the PSTN to the IP = network in this >example by law, if that IP Network is providing a = Telecommunications Service >(although I'm not sure that 'law' is the right word -- I just know = MLPP cannot >be run on the PSTN or like network-types). Therefore, all inbound = IP Voice >related traffic must have the same value as all other Voice traffic = to those >types of providers. > >I know Fred Baker is very resistant to the idea of Voice traffic = having >multiple Forwarding queue behaviors within an internetworking = device (i.e. >multiple levels of EF for dropping), so this would suggest the DSCP = other than >EF isn't preferred by him (and others). His belief - and I'm not = yet sure it's >correct in the long term - is that this is a session issue, not a = forwarding >issue; therefore this is an RSVP/COPS Prioritization issue, isn't = it? > > >At 06:01 PM 8/3/2000 -0700, Bill Foster wrote: >>Given that the MGC is often defining policy and QoS use is an = important >>policy, it would be useful to have the capability. >> >>At 04:34 PM 8/3/00 -0700, S KA N wrote: >>>Hi There, >>> >>>If you can recall the meaning of DiffServ, its for >>>implementing differentiated services in the Internet. >>>Which basically means giving QoS to specially marked >>>data traffic. Now if you look at the requirements >>>specified in Section 5.5 of RFC2805, it says that >>>the MGCP protocol should support the ability to >>>specify QoS for the connection between MGs, etc. >>> >>>Any comment. >>> >>>...SKAN >>> >>> >>> >>> > There's a difference between an operator's RFP >>> > requiring that their MGs >>> > support DiffServ and a protocol dependency on such >>> > support. Megaco has no >>> > such dependency. >>> > >>> > > -----Original Message----- >>> > > From: S KA N [SMTP:s_ka_n@YAHOO.COM] >>> > > Sent: Wednesday, August 02, 2000 3:26 PM >>> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM >>> > > Subject: MG and DiffServ >>> > > >>> > > Hi, >>> > > >>> > > Can you think of any relation between the MG and >>> > > DiffServ? >>> > > >>> > > If a privately managed IP network is DiffServ >>> > > compliant and suppose if the same network >>> > > is going to be used for VoIP purposes also. Don't >>> > > we require the MGs to be DiffServ compliant? >>> > > >>> > > Any help/comment would be appreciated. >>> > > >>> > > ...SKAN >>> >>> >>>__________________________________________________ >>>Do You Yahoo!? >>>Kick off your party with Yahoo! Invites. >>>http://invites.yahoo.com/ >> >>----------------------------- >>Bill Foster >>Phone: (408) 527-8791 >>Page: (800) 365-4578 >>Fax: (781) 998-6492 >> > >************************************* >"At the end of the day... the most committed win!" > >James M. Polk >Sr. Product Manager, Multiservice Architecture and Standards >Enterprise Voice Business Unit >Cisco Systems >Dallas, Texas >w) 972.813.5208 >f) 972.813.5280 >www.cisco.com > ************************************* "At the end of the day... the most committed win!" James M. Polk Sr. Product Manager, Multiservice Architecture and Standards Enterprise Voice Business Unit Cisco Systems Dallas, Texas w) 972.813.5208 f) 972.813.5280 www.cisco.com=20 ------=_NextPart_000_0067_01C0008C.09BD5B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
ETSI TIPHON have been looking at the = problem of end=20 to end QoS control in a mixed IP/circuit switched environment, in=20 particular the general case where a number of separate transport domains = and=20 service providers are involved in the call; each transport domain = possibly=20 supporting a different QoS mechanism.
 
Within the TIPHON architecture a clear = distinction=20 is drawn between application and transport.  The former being IP = telephony=20 and the latter IP (or ATM/frame relay) transport.  The required QoS = is=20 clearly an issue for the application, in particular the agreement = between user=20 and service provider.  However the speech QoS required has to be = translated=20 to parameters that can be controlled in the transport domain. e.g. = delay, jitter=20 and packet loss.  Diff Serv, RSVP/Intserv, MPLS are generic = transport=20 domain mechanism that help deliver the delay, jitter and packet loss=20 requirements required by the application.
 
The MGC is entirely in the application = domain and=20 it is at this level that required end to end QoS is established and=20 authorised.  The MG however spans both transport and application=20 domains.  Media conversion, and possibly RTP, are part of the=20 application, but IP and UDP termination and the QoS mechanisms that go = with them=20 are definitely transport.  So within the TIPHON architecture there = would be=20 no need to signal issues related to the particular transport QoS = mechanism in=20 Megaco (these would be internal to the MG), however delay, jitter and = packet=20 loss parameters would be required.  Further details of the TIPHON = model can=20 be found in.
 
http://docbox.etsi.org/tech-org/tiphon/Document/tip= hon/07-drafts/wg5/DTS05003/V0.8.1/DTS-5003v0.8.1.zip
 
 
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley@44comms.com
=
 
 
----- Original Message -----
From:=20 Rajeev=20 Gupta
To: MEGACO@STANDARDS.NORTELNETWOR= KS.COM=20
Sent: Saturday, August 05, 2000 = 2:00=20 AM
Subject: Re: MG and = DiffServ

Presumably different QoS may be applied to each voice call = depending on=20 parameters such as codec, VAD, customer's tolerance for quality. This = is=20 dynamically determined by the MGC, and can be indicated to the MG, so = the MG=20 can select a suitable QoS path. It is not clear who is setting up the = QoS path=20 - one model is that the MGC simply indicates to the MG the required = QoS, and=20 leaves it to the MG to select the correct mechanism to get the = required QoS=20 e.g. if the MGs are=20 connected over an MPLS network, the MG may use RSVP to setup the = QoS/label for=20 the voice path. In a trunking application, the MGs may have (MPLS) = trunks=20 setup among themselves, perhaps different trunks for different QoS = types, and=20 the MG directs the RTP stream to the trunk that matches the QoS for = the=20 call.

Rajeev Gupta =
empowerTel Networks =
475 Sycamore Drive, Milpitas, CA = 95035=20
Phone: +1 408 519 = 7136
Fax: +1 408 519 7420
mailto:rajeev@empowertel.com=20
http://www.empowertel.com

-----Original Message-----
From: Media Gateway = Control=20 (megaco) [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of = James M. Polk
Sent: Friday, August 04, 2000 7:13=20 AM
To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re:=20 MG and DiffServ

Petros

Who is providing the Service for you Voice traffic? If that is = a=20 Telecommunications Service Provider (as defined by the US FCC), then = you=20 won't have that choice across their network (I don't believe). If = that is=20 from an Enterprise-based Call Agent (MGC), then I'd be surprised if = that=20 were legally allowed to separate this traffic if that Enterprise has = the MGC=20 or Call Agent for Signaling to/from your MG.

I think you'll have to somehow get the traffic you want to be = EF marked=20 across a Telecom SP and have your Greece-bound traffic across some = other=20 network entirely, then this will work. But (I think) the same MGC = cannot=20 signal both your Greece destination traffic and the rest of your = Voice=20 traffic (as they would be separate networks for = signaling).

One way around that is a Peer-to-Peer signaling Protocol like = H.323 or=20 SIP from a computer (NetMeeting for example) going best effort to = the=20 Internet for that best effort traffic, and your phones remain on = that=20 Telecom SP's MGC and of EF marked packets and high = quality.

At 09:46 AM 8/4/2000 -0400, Petros N. Mouchtaris wrote:
>
>
>I have a specific case that your approach does not support. = I may=20 have
>misunderstood your comments so please let me know if I'm = incorrect.=20 TI think
>this case is reasonable and should be supported:
>
>I'd like all my voice to receive premium quality except for = my=20 calls to Greece
>where I'm willing to accept best effort quality so that = those calls=20 to Greece
>are virtually free. This will help me keep up with all my = friends=20 and family
>there.
>
>I expect that the MGC will maintain this policy and not my=20 phone.  Let me know
>what you think.
>
>Petros
>
>
>
>
>
>"James M. Polk" <jmpolk@cisco.com> on 08/04/2000 = 09:28:26=20 AM
>
>Please respond to "James M. Polk" = <jmpolk@cisco.com>
>
>To:   MEGACO@standards.nortelnetworks.com
>cc:    (bcc: Petros N. = Mouchtaris/Telcordia)
>Subject:  Re: MG and DiffServ
>
>
>
>
>
>All
>
>Shouldn't this be defined by other mechanisms by = default?
>
>For example, typically the MG is dumb and requires a config = image=20 from some
>TFTP server. A template config is usually utilized that = should set=20 the default
>DSCP to a value that likely won't change. This isn't a = Protocol=20 issue, I don't
>think, it's a semantics issue.
>
>Another example, the port the MG is physically connected to = on the=20 Enet Switch
>sets the traffic to a specific Voice VLAN. Again, this = isn't a=20 Protocol issue.
>
>Another example, the Enet Switch knows that a MG is what's = attached=20 to a
>specific port and sets all incoming traffic to a defined = DSCP value=20 -- again,
>not a Protocol issue.
>
>I think, typically, a Protocol deals with things that are=20 negotiated. I yet
>don't see why a MG (IP Phone) which is almost always = getting its=20 config file(s)
>from a Server (MGC?) that it will yet need to have anything = other=20 than the one
>default value (even if that is EF marked) which that Domain = Administrator
>assigns to all Voice traffic within that Domain.
>
>I believe the same should apply to a MG that's a PSTN to IP = Gateway. There
>actually cannot be a priority change from the PSTN to the = IP=20 network in this
>example by law, if that IP Network is providing a=20 Telecommunications Service
>(although I'm not sure that 'law' is the right word -- I = just know=20 MLPP cannot
>be run on the PSTN or like network-types). Therefore, all = inbound=20 IP Voice
>related traffic must have the same value as all other Voice = traffic=20 to those
>types of providers.
>
>I know Fred Baker is very resistant to the idea of Voice = traffic=20 having
>multiple Forwarding queue behaviors within an = internetworking=20 device (i.e.
>multiple levels of EF for dropping), so this would suggest = the DSCP=20 other than
>EF isn't preferred by him (and others). His belief - and = I'm not=20 yet sure it's
>correct in the long term - is that this is a session issue, = not a=20 forwarding
>issue; therefore this is an RSVP/COPS Prioritization issue, = isn't=20 it?
>
>
>At 06:01 PM 8/3/2000 -0700, Bill Foster wrote:
>>Given that the MGC is often defining policy and QoS use = is an=20 important
>>policy, it would be useful to have the = capability.
>>
>>At 04:34 PM 8/3/00 -0700, S KA N wrote:
>>>Hi There,
>>>
>>>If you can recall the meaning of DiffServ, its = for
>>>implementing differentiated services in the = Internet.
>>>Which basically means giving QoS to specially = marked
>>>data traffic. Now if you look at the = requirements
>>>specified in Section 5.5 of RFC2805, it says = that
>>>the MGCP protocol should support the ability = to
>>>specify QoS for the connection between MGs, = etc.
>>>
>>>Any comment.
>>>
>>>...SKAN
>>>
>>>
>>>
>>> > There's a difference between an operator's = RFP
>>> > requiring that their MGs
>>> > support DiffServ and a protocol dependency on = such
>>> > support.  Megaco has no
>>> > such dependency.
>>> >
>>> > > -----Original Message-----
>>> > > = From:       S KA N=20 [SMTP:s_ka_n@YAHOO.COM]
>>> > > = Sent:      =20 Wednesday, August 02, 2000 3:26 PM
>>> > > To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
>>> > > Subject:    MG and = DiffServ
>>> > >
>>> > > Hi,
>>> > >
>>> > > Can you think of any relation between = the MG=20 and
>>> > > DiffServ?
>>> > >
>>> > > If a privately managed IP network is=20 DiffServ
>>> > > compliant and suppose if the same = network
>>> > > is going to be used for VoIP purposes = also.=20 Don't
>>> > > we require the MGs to be DiffServ=20 compliant?
>>> > >
>>> > > Any help/comment would be = appreciated.
>>> > >
>>> > > ...SKAN
>>>
>>>
=
>>>__________________________________________________
=
>>>Do You Yahoo!?
>>>Kick off your party with Yahoo! Invites.
>>
>>-----------------------------
>>Bill Foster
>>Phone: (408) 527-8791
>>Page:   (800) 365-4578
>>Fax:     (781) 998-6492
>>
>
>*************************************
>"At the end of the day... the most committed win!"
>
>James M. Polk
>Sr. Product Manager, Multiservice Architecture and = Standards
>Enterprise Voice Business Unit
>Cisco Systems
>Dallas, Texas
>w) 972.813.5208
>f)  972.813.5280
>

*************************************
"At the = end of=20 the day... the most committed win!"

James M. = Polk
Sr.=20 Product Manager, Multiservice Architecture and = Standards
Enterprise Voice=20 Business Unit
Cisco Systems
Dallas, Texas
w)=20 972.813.5208
f)  972.813.5280
www.cisco.com =
------=_NextPart_000_0067_01C0008C.09BD5B80-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 7 12:06:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14081 for ; Mon, 7 Aug 2000 12:06:18 -0400 (EDT) Received: from standards (47.234.32.16:2795) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85AD8@standards.nortelnetworks.com>; Mon, 7 Aug 2000 11:54:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11397 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Aug 2000 11:54:06 -0400 Received: from shako.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85AD0@standards.nortelnetworks.com>; Mon, 7 Aug 2000 11:44:00 -0400 Received: from shako.cisco.com (shako.cisco.com [161.44.3.76]) by shako.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id LAA26230; Mon, 7 Aug 2000 11:55:09 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: RWzWmcP43O4ynkq5SvBBZw== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Message-ID: <200008071555.LAA26230@shako.cisco.com> Date: Mon, 7 Aug 2000 11:55:09 -0400 Reply-To: Ravi Subramaniam Sender: "Media Gateway Control (megaco)" From: Ravi Subramaniam Subject: megaco NAS package X-To: taylor@nortelnetworks.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello Tom... I have a prelimnary nas package which I build on top of the existing one, please take a look at it. I am working on making it IETF compliant right now, so alignments etc. may be off. Thanks ... Ravi Subramaniam IOS-Wan Connectivity Products Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 7 13:05:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16159 for ; Mon, 7 Aug 2000 13:05:59 -0400 (EDT) Received: from standards (47.234.32.16:2159) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85B6C@standards.nortelnetworks.com>; Mon, 7 Aug 2000 12:53:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11599 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Aug 2000 12:53:23 -0400 Received: from shako.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85B6B@standards.nortelnetworks.com>; Mon, 7 Aug 2000 12:53:17 -0400 Received: from shako.cisco.com (shako.cisco.com [161.44.3.76]) by shako.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id NAA04332; Mon, 7 Aug 2000 13:04:17 -0400 (EDT) MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Gam_of_Porpoises_204_000 X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Message-ID: <200008071704.NAA04332@shako.cisco.com> Date: Mon, 7 Aug 2000 13:04:17 -0400 Reply-To: Ravi Subramaniam Sender: "Media Gateway Control (megaco)" From: Ravi Subramaniam Subject: Re: megaco NAS package X-cc: taylor@nortelnetworks.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM --Gam_of_Porpoises_204_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: VvOptRvtVxsU/at0TsWg5A== Attachment included !! oops ... > > Hello Tom... > I have a prelimnary nas package which I build on top of the existing one, > please take a look at it. I am working on making it IETF compliant > right now, so alignments etc. may be off. > Thanks ... > Ravi Subramaniam > IOS-Wan Connectivity Products > Cisco Systems Thanks ... Ravi Subramaniam IOS-Wan Connectivity Products Cisco Systems --Gam_of_Porpoises_204_000 Content-Type: TEXT/plain; name="new_naspkg.02.txt"; charset=us-ascii; x-unix-mode=0644 Content-Description: new_naspkg.02.txt Content-MD5: vNDr9WtJBf9PBr8fbWr58A== Media Gateway Control (Megaco) Mike Kallas Internet Draft Nortel Networks Document: draft-ietf-megaco-naspkg-01.txt Zacharias Bilalis Category: Standards Track Siemens Ravi Subramaniam Cisco Systems Megaco/H.248 NAS Package Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document is work in progress and defines a NAS Package for the Megaco/H.248 protocol. It is intended to satisfy the requirements in section 11.2.5 of the Megaco/H.248 requirements document [5]. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 3. ABBREVIATIONS NAS: Network Access Server VPN: Virtual Private Network Kallas, Bilalis, Subramaniam Standards Track - Expires September 2000 1 Megaco/H.248 NAS Package March 2000 4. NAS PACKAGE PackageID: nas, 0x0022 Version: 1 Extends: none This package supports the functionality of a Media Gateway as NAS (Network Access Server), providing support for dial-in access to the NAS. 4.1 Properties VPN id PropertyId: vpnid (0x0001) Description: identifies the VPN to which this termination is to be connected Type: octet string as defined in RFC2685 [4] Possible Values: vpnid Defined in: TerminationState Characteristics: read/write NAS id PropertyId: nasid (0x0002) Description: identifies the NAS to which this termination is to be connected Type: octet string as defined in RFC2685 [4] Possible Values: 0- Defined in: TerminationState Characteristics: read/write 4.2 Events 4.2.1 NAS Failure EventID: nasfail (0x0001) Description: indicates a failure in the processing of the access attempt due to external or internal reasons. EventDescriptor Parameters: none added by this package ObservedEventDescriptor Parameters: Error code ParameterID: ec (0x0001) Description: describes the failure reason Type: integer, 0 to 99 Possible values: 0: NAS internal error 1: AAA server unavailable 2: Operator shutdown 4.2.2 Authorization Result EventID: authres (0x0002) Description: This event reports the outcome of a request for authorization of Kallas, Bilalis, Subramaniam Standards Track - Expires September 2000 2 Megaco/H.248 NAS Package March 2000 the network access request EventDescriptor Parameters: none added by this package ObservedEventDescriptor Parameters: result ParameterID: res (0x0001) Description: outcome of the service request to the AAA server (see for example IETF RFC 2138 (RADIUS) [2]) Type: enumeration Possible values: succ (0x0000) service request was successful den (0x0001) service request was denied 4.2.4 Call Request EventID: cr (0x0003) Description: The call request event is used to notify that a call has been requested by the NAS. The call back type is used to notify that a call-back has been requested by the AAA server during the initial phase of a data connection (see for example IETF RFC 2138 (RADIUS) [2]). The event report includes the telephone number to which the call is to be made. EventDescriptor Parameters: none added by this package ObservedEventDescriptor Parameters: Type ParameterID: type (0x0001) Description: Type of call desired Type: integer Possible values: 0x1: Callback request 0x2: Outbound call Number to be called ParameterID: cdn (0x0002) Description: the called number Type: string of digits Possible values: location-dependent. Calling number ParameterID: cgn (0x0003) Description: the calling number Type: string of digits Possible values: location-dependent. Bearer Capability ParameterID: bcap(0x0004) Description: Bearer capability desired for the call Type: integer Possible values: 0x1: Unrestricted Digital 0x2: Modem 0x3: Voice Bandwidth ParameterID: bw (0x0005) Description: Bandwidth for the connection Type: integer Possible values: 0x1: 64 0x2: 56 4.2.4 Call Release EventID: cr (0x0004) Description: The call is to be released from the destination. ObservedEventDescriptor Parameters: Cause ParameterID: cause (0x0001) Description: cause code Type: integer Possible values: 00-0x80 4.2.4 Cot results EventID: cot_results (0x0005) Description: The results from the continuity test are returned ObservedEventDescriptor Parameters: Cause ParameterID: cause (0x0001) Description: cot result Type: boolean Possible values: PASSED (0x1) FAILED (0x0) 4.3 Signals 4.3.1 RELEASE SignalID: rel (0x0001) Description: release Parameters: Parameter id: Cause Description: cause code Type: integer Possible values: 00-0x80 4.3.2 Cot SignalID: cot (0x0002) Description: continuity test - Put (or remove) TDM circuit in loopback Parameters: Action: Descriptor: Perform cot action Type: Integer Possible values: 1 - Start loopback 2 - Stop loopback Timeout: Descriptor: Timeout for the reception of tones Type: Integer Possible values: 1-300 (seconds) Result: Descriptor: If action is stop cot, then return results Type: Booolean Possible Values: Pass : 0x1 Fail : 0x0 4.3.3 Generate_tones SignalID: tone (0x0003) Description: Generate or stop generating tones (milliwatt) on the circuit Parameters: Action: Descriptor: Perform action Type: Integer Possible values: 1 - Start tone generation 2 - Stop tone generation Type: Descriptor: Tone type Type: Integer Possible values: 0x01 - Multi Frequency tone 0x02 - DTMF 0x03 - Analog 0x04 - Digital Milliwatt Duration Descriptor: Tone duration Type: integer Possible Values: 0-120 Tone String Descriptor: String of tone to send Type: integer Possible Values: ascii string 4.4.4 Circuit_state SignalID: circuit_state (0x0004) Description: Set the circuit state to new state Parameters: New_state: Descriptor: New state for circuit Type: Integer Possible values: 1 - Idle 2 - OOS- Out of service 4.4.5 Get_cot_results SignalID: cot_results (0x0005) Description: Get the cot results Parameters: Results: Descriptor: Results of the loopback test Type: Integer Possible values: 0x1 - Passed 0x0 - Failed 4.4 Statistics None 4.5 Procedures Kallas, Bilalis, Subramaniam Standards Track - Expires September 2000 3 Megaco/H.248 NAS Package March 2000 None 4.6 Descriptor 4.6.1 Call Info Descriptor The call info descriptor contains the parameters required by the NAS for authentication. This descriptor will be delivered to the NAS with the ADD command and will contain the following: . DNIS digits string . CLID digit string . Call type . Authentication Flag . TDM Hairpin flag . TDM Hairpin destination termination id 5. Call Flows 6. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [2] Rigney, C., et al, Remote Authentication Dial In Service (RADIUS), RFC 2138, April 1997 [3] Townsley, W., et al, Layer Two Tunneling Protocol(L2TP), RFC 2661, August 1999 [4] B. Fox and B. Gleeson, Virtual Private Networks Identifier, RFC 2685, September 1999 [5] N. Greene, M. Ramalho, B. Rosen, Media Gateway control protocol architecture and requirements, RFC number TBD, March 2000 (currently draft-ietf-megaco-reqs-10.txt, February 2000) 7. AUTHOR'S ADDRESSES Mike Kallas Nortel Networks P.O. Box 833805 Richardson, Texas 75083-3805 USA Email: mkallas@nortelnetworks.com Zacharias Bilalis Siemens Schertlinstr. 8 81379 Munich Germany Email: zacharias.bilalis@icn.siemens.de Ravi Subramaniam Cisco Systems 7025 Kit Creek Road RTP, NC 27709 USA Email: ravis@cisco.com Kallas, Bilalis, Subramaniam Standards Track - Expires September 2000 4 --Gam_of_Porpoises_204_000-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 7 14:25:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04633 for ; Mon, 7 Aug 2000 14:25:06 -0400 (EDT) Received: from standards (47.234.32.16:4216) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85BF2@standards.nortelnetworks.com>; Mon, 7 Aug 2000 14:12:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11771 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Aug 2000 14:12:41 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85BF1@standards.nortelnetworks.com>; Mon, 7 Aug 2000 14:02:39 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id LAA10868; Mon, 7 Aug 2000 11:14:10 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <398EFD67.6A32686@cisco.com> Date: Mon, 7 Aug 2000 14:18:15 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: Clarification on Endpoint Identifier in RQNT X-To: sarunk@ishoni.com X-cc: mgcp@pulver.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Arun Kumar S wrote: > Hi, > > I wanted a clarification on the endpoint identifier naming conventions for > the RQNT message. > > To quote from rfc2705, > > "EndpointId is the name for the endpoint in the gateway where > NotificationRequest executes, as defined in section 2.1.1." > > The rfc does not specify the whether the endpoint id can be under-specified > using the "any of" or "all" wildcard naming convention. > - Is it possible for the endpoint id to be under-specified? > - If so, can both the wild-cards (any of / all) be used within the endpoint > id > of RQNT? The "all of" wildcard can definitely be used. It makes little sense to use the "any of" wildcard here, however the spec is unfortunately silent on this. If you are developing a gw, I would encourage you to accept requests using "any of" wildcards, but if you are developing a Call Agent I would strongly discourage such use (the 2705 update may in fact disallow it). For future reference, you might want to send MGCP questions to "mgcp@pulver.com" instead. Regards. Flemming > > > Regards, > ___________________________________________________ > Arun Kumar S > ishoni Networks (India) Pvt Ltd (http://www.ishoni.com) > ...Broadband for everyone > email: sarunk@ishoni.com > Phone: +91-80-2292125 (Work) > Fax: +91-80-2995545 (Work) -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 7 16:45:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23776 for ; Mon, 7 Aug 2000 16:45:15 -0400 (EDT) Received: from standards (47.234.32.16:1938) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85CD1@standards.nortelnetworks.com>; Mon, 7 Aug 2000 16:33:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0231 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Aug 2000 16:33:07 -0400 Received: from mail.xybridge.com (209.111.160.85:2628) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85CC1@standards.nortelnetworks.com>; Mon, 7 Aug 2000 16:23:06 -0400 Received: from nitin ([10.10.13.38]) by mail.xybridge.com (8.9.3/8.9.3) with SMTP id OAA14314; Mon, 7 Aug 2000 14:47:43 -0500 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.00.2919.6600 Message-ID: Date: Mon, 7 Aug 2000 15:44:16 -0500 Reply-To: Nitin Kumar Sender: "Media Gateway Control (megaco)" From: Nitin Kumar Subject: Re: [MGCP]: Re: Clarification on Endpoint Identifier in RQNT X-To: Flemming Andreasen , sarunk@ishoni.com X-cc: mgcp@pulver.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <398EFD67.6A32686@cisco.com> Content-Transfer-Encoding: 7bit I think MGCP should strictly disallow "any of" wildcard in RQNT, because on what basis MG can decode "any of" wildcarded RQNT. In that case MG has no other option but to decode "any of" wildcard as "all of" to be on safer side. For NotificationRequest we should have similar clarity as we have for EndPointConfiguration request. See following extract from MGCP rfc2705... "EndpointId is the name for the endpoint in the gateway where EndpointConfiguration executes, as defined in section 2.1.1. The "any of" wildcard convention shall not be used. If the "all of" wildcard convention is used, the command applies to all the endpoint whose name matches the wildcard." Regards nitin -----Original Message----- From: owner-iptelephony-news@enterprise.pulver.com [mailto:owner-iptelephony-news@enterprise.pulver.com] On Behalf Of Flemming Andreasen Sent: Monday, August 07, 2000 1:18 PM To: sarunk@ishoni.com Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM; mgcp@pulver.com Subject: [MGCP]: Re: Clarification on Endpoint Identifier in RQNT Arun Kumar S wrote: > Hi, > > I wanted a clarification on the endpoint identifier naming conventions for > the RQNT message. > > To quote from rfc2705, > > "EndpointId is the name for the endpoint in the gateway where > NotificationRequest executes, as defined in section 2.1.1." > > The rfc does not specify the whether the endpoint id can be under-specified > using the "any of" or "all" wildcard naming convention. > - Is it possible for the endpoint id to be under-specified? > - If so, can both the wild-cards (any of / all) be used within the endpoint > id > of RQNT? The "all of" wildcard can definitely be used. It makes little sense to use the "any of" wildcard here, however the spec is unfortunately silent on this. If you are developing a gw, I would encourage you to accept requests using "any of" wildcards, but if you are developing a Call Agent I would strongly discourage such use (the 2705 update may in fact disallow it). For future reference, you might want to send MGCP questions to "mgcp@pulver.com" instead. Regards. Flemming > > > Regards, > ___________________________________________________ > Arun Kumar S > ishoni Networks (India) Pvt Ltd (http://www.ishoni.com) > ...Broadband for everyone > email: sarunk@ishoni.com > Phone: +91-80-2292125 (Work) > Fax: +91-80-2995545 (Work) -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 7 16:59:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00745 for ; Mon, 7 Aug 2000 16:59:29 -0400 (EDT) Received: from standards (47.234.32.16:1938) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85CF9@standards.nortelnetworks.com>; Mon, 7 Aug 2000 16:47:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0279 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Aug 2000 16:47:19 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85CEA@standards.nortelnetworks.com>; Mon, 7 Aug 2000 16:37:18 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id NAA14920; Mon, 7 Aug 2000 13:48:04 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <398F2174.8E1C5A82@cisco.com> Date: Mon, 7 Aug 2000 16:52:04 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: [MGCP]: Re: Clarification on Endpoint Identifier in RQNT X-To: Nitin Kumar X-cc: sarunk@ishoni.com, mgcp@pulver.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Nitin Kumar wrote: > I think MGCP should strictly disallow "any of" wildcard in RQNT, I agree that would be very reasonable, however it's not spec'ed that way in 2705 currently. > because on > what basis MG can decode "any of" wildcarded RQNT. In that case MG has no > other option but to decode "any of" wildcard as "all of" to be on safer > side. That you certainly should *not* do. > > > For NotificationRequest we should have similar clarity as we have for > EndPointConfiguration request. > > See following extract from MGCP rfc2705... > > "EndpointId is the name for the endpoint in the gateway where > EndpointConfiguration executes, as defined in section 2.1.1. The > "any of" wildcard convention shall not be used. If the "all of" > wildcard convention is used, the command applies to all the endpoint > whose name matches the wildcard." > Right - we should add that to the 2705 update unless somebody thinks otherwise. -- Flemming > > Regards > > nitin > > -----Original Message----- > From: owner-iptelephony-news@enterprise.pulver.com > [mailto:owner-iptelephony-news@enterprise.pulver.com] On Behalf Of Flemming > Andreasen > Sent: Monday, August 07, 2000 1:18 PM > To: sarunk@ishoni.com > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM; mgcp@pulver.com > Subject: [MGCP]: Re: Clarification on Endpoint Identifier in RQNT > > Arun Kumar S wrote: > > > Hi, > > > > I wanted a clarification on the endpoint identifier naming > conventions for > > the RQNT message. > > > > To quote from rfc2705, > > > > "EndpointId is the name for the endpoint in the gateway where > > NotificationRequest executes, as defined in section 2.1.1." > > > > The rfc does not specify the whether the endpoint id can be > under-specified > > using the "any of" or "all" wildcard naming convention. > > - Is it possible for the endpoint id to be under-specified? > > - If so, can both the wild-cards (any of / all) be used within the > endpoint > > id > > of RQNT? > > The "all of" wildcard can definitely be used. It makes little sense to use > the "any of" > wildcard here, however the spec is unfortunately silent on this. If you are > developing > a gw, I would encourage you to accept requests using "any of" wildcards, but > if you are > developing a Call Agent I would strongly discourage such use (the 2705 > update may in > fact disallow it). > > For future reference, you might want to send MGCP questions to > "mgcp@pulver.com" > instead. > > Regards. > > Flemming > > > > > > > Regards, > > ___________________________________________________ > > Arun Kumar S > > ishoni Networks (India) Pvt Ltd (http://www.ishoni.com) > > ...Broadband for everyone > > email: sarunk@ishoni.com > > Phone: +91-80-2292125 (Work) > > Fax: +91-80-2995545 (Work) > > -- > Flemming Andreasen Phone: +1 732 452 1667 > Cisco Systems Fax: +1 240 359 5839 -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 7 18:57:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29413 for ; Mon, 7 Aug 2000 18:57:40 -0400 (EDT) Received: from standards (47.234.32.16:3117) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85D80@standards.nortelnetworks.com>; Mon, 7 Aug 2000 18:45:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0457 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Aug 2000 18:45:40 -0400 Received: from qhars002.nortel.com (47.101.112.102:45037) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85D7C@standards.nortelnetworks.com>; Mon, 7 Aug 2000 18:35:40 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Mon, 7 Aug 2000 23:39:45 +0100 Received: from zcard015.ca.nortel.com (actually zcard015) by smtprch1.nortel.com; Mon, 7 Aug 2000 17:36:20 -0500 Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id PJTQR2L4; Mon, 7 Aug 2000 18:36:14 -0400 Received: from americasm10.nt.com (pnc1m006.us.nortel.com [47.142.208.218]) by zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id PBL4BW9S; Mon, 7 Aug 2000 18:36:14 -0400 X-Sybari-Space: 00000000 00000000 00000000 X-Sender: "Brown, Michael [NC1:3T19:EXCH]" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 References: <000d01bfff87$400fac20$4609e28d@elex.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <398F3B2B.BAFCF5D9@americasm10.nt.com> Date: Mon, 7 Aug 2000 18:41:47 -0400 Reply-To: Michael Brown Sender: "Media Gateway Control (megaco)" From: Michael Brown Organization: Nortel Networks Subject: Re: Calling Line Identification To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Actually, there is a proposed package which will address pretty much the whole gamut of services related to display during alerting (either onhook or offhook). Please see the Enhanced Alerting Package in the document at: http://www.ietf.org/internet-drafts/draft-brown-supplpkgs-00.txt Michael Brown "Davidson, Dan" wrote: > Lets keep in mind that caller ID, caller Name and other similar features can > be received > also during an active call: the SCWID service - Spontaneous Call Wait ID. > > Cheers, > Dan > > > Well, It's not easy to tell what is "reasonable" and what is not... The > same > > issue could be raised for where the > Generic > > Announcement package supports both fixed and variable announcements. > > > Anyway, if we want to define more atomic packages for this new case, we > > first need to figure out which capabilities have a real impact on MG > > implementations and derive the number of packages from that. My feeling is > > that the MG does not need to be aware of the type of information which is > > actually sent to the terminal. The MGC shall provide a complete > > "presentation layer" frame, including the message type and lengh > indicators. > > The MG does not need to check that the message type is known and that the > > parameters are valid for that message. What matters for the MG is the type > > of transmission (on-hook/off-hook) and possibly the presence/absence of > > ringing after the data transmission. Therefore I assume that we could go > for > > three service-independent packages only. > > > The first package "on-hook transmission associated with ringing" would be > > used to support Calling Line ID but also Calling Name ID or anything that > > needs to be displayed when a call is presented. > > >Bruno, > > > -----Message d'origine----- > > De: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > Date: vendredi 4 ao?t 2000 16:34 > > ?: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Objet: Re: Calling Line Identification > > > > > > My concern here is that when you implement a package, you > > implement all of > > it, > > and the extended capabilities you propose may be beyond what > > a reasonable > > implementation > > of a simple CLID capability may provide. I could see a set > > of packages each > > extending > > from the previous which could have capabilities you describe. > > > > Brian > > > > > -----Original Message----- > > > From: CHATRAS Bruno FTRD/DAC/ISS > > > [mailto:bruno.chatras@rd.francetelecom.fr] > > > Sent: Friday, August 04, 2000 10:24 AM > > > To: Rosen, Brian > > > Cc: 'MEGACO@STANDARDS.NORTELNETWORKS.COM' > > > Subject: RE: Calling Line Identification > > > > > > > > > Hi, > > > > > > I think that we need a more generic package that can support the > > > transmission of dipaly information over an analog line. > > > > > > I see a need to support: > > > > > > a) On-hook transmission associated with ringing (Calling Line > > > ID, Calling > > > Name ID, ...) > > > > > > b) On-hook transmission not associated with ringing (e.g.; > > > notification > > > services for message waiting indication) > > > > > > c) Off-hook transmission (calling Line ID presentation during > > > call waiting, > > > text-based advice of charge, ...) > > > > > > In all cases, there shall be no restrictions on the type of > > > message (and > > > parameters) to be sent over the analog line. > > > > > > I know that someone from Telcordia has presented a > > > contribution on that > > > topic to the ITU SG16 meeting in February'2000. The meeting reports > > > indicates that the proposal was reasonnable but that more > > > work was required. > > > I don't know what happened after that. > > > > > > I also attach for your information an alternative package > > > description I > > > drafted a few days ago. I'll not be able to work on it during > > > the cmming > > > weeks (holiday !). However, if someone wants to... > > > > > > > > > > > > > -----Message d'origine----- > > > > De: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > > > Date: vendredi 4 ao?t 2000 15:50 > > > > ?: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Objet: Re: Calling Line Identification > > > > > > > > > > > > Need a package. > > > > > > > > Any volunteers? > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Rajendra Patil [mailto:rpatil@HSS.HNS.COM] > > > > > Sent: Friday, August 04, 2000 7:57 AM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Calling Line Identification > > > > > > > > > > > > > > > Hi, > > > > > > > > > > How MEGACOsupports CLID display for residential gateway ? > > > > > > > > > > Thanks/ > > > > > Rajendra > > > > > > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 9 07:52:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06223 for ; Wed, 9 Aug 2000 07:52:01 -0400 (EDT) Received: from standards (47.234.32.16:2032) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86238@standards.nortelnetworks.com>; Wed, 9 Aug 2000 3:48:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1962 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Aug 2000 03:48:47 -0400 Received: from firewall.chttl.com.tw (gate.chttl.com.tw) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86237@standards.nortelnetworks.com>; Wed, 9 Aug 2000 3:48:46 -0400 Received: from ms.chttl.com.tw (ms.tl.gov.tw. [10.144.2.104]) by firewall.chttl.com.tw (8.9.3/8.9.3) with ESMTP id PAA01741 for ; Wed, 9 Aug 2000 15:59:34 +0800 (CST) Received: from bigman ([10.144.200.130]) by ms.chttl.com.tw (8.9.3/8.9.3) with SMTP id QAA05594 for ; Wed, 9 Aug 2000 16:03:09 +0800 (CST) References: <200008071555.LAA26230@shako.cisco.com> 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 Message-ID: <000d01c001d7$c01d0e60$82c8900a@chttl.com.tw> Date: Wed, 9 Aug 2000 15:59:26 +0800 Reply-To: =?iso-8859-1?B?s3Or26l2?= Sender: "Media Gateway Control (megaco)" From: =?iso-8859-1?B?s3Or26l2?= Subject: Why analog termination has IP termination properties? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit There is an example call flow in Annex A of MEGACO protocol. I traced the call flow. Here I have one issue in step 3 of the section A.1.1. The Step 3 of Section A.1.1 is copied in following: 3. The MGC programs a Termination in the NULL context. The terminationId is A4444, the streamId is 1, the requestId in the Events descriptor is 2222. The mId is the identifier of the sender of this message, in this case, it is the IP address and port [123.123.123.4]:55555. Mode for this stream is set to SendReceive. "al" is the analog line supervision package. MGC to MG1: MEGACO/1 [123.123.123.4]:55555 Transaction = 9999 { Context = - { Modify = A4444 { Media { Stream = 1 LocalControl { Mode = SendReceive, ds0/gain=2, ; in dB, ds0/ec=G165 }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 a=fmtp:PCMU VAD=X-NNVAD ; special voice activity ; detection algorithm } } }, Events = 2222 {al/of} } } } My Issue is: Termination A444 is an analog line termination. Why does it has the Local Descriptor which describe the IP termination properties such "c=IN IP4 $", "m= audio $ RTP/AVP 0"....? From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 9 07:52:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06234 for ; Wed, 9 Aug 2000 07:52:02 -0400 (EDT) Received: from standards (47.234.32.16:4094) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86279@standards.nortelnetworks.com>; Wed, 9 Aug 2000 7:12:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2034 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Aug 2000 07:12:59 -0400 Received: from qhars002.nortel.com (47.101.112.102:60184) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86278@standards.nortelnetworks.com>; Wed, 9 Aug 2000 7:02:54 -0400 Received: from zrtps06s.us.nortel.com (actually 47.140.48.50) by qhars002.nortel.com; Wed, 9 Aug 2000 12:10:11 +0100 Received: from zmers013 (actually zmers013.ca.nortel.com) by zrtps06s.us.nortel.com; Wed, 9 Aug 2000 07:10:00 -0400 Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by zmers013; Wed, 9 Aug 2000 07:09:45 -0400 Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA16026 for ; Wed, 9 Aug 2000 14:08:21 +0300 (IDT) Received: from tsyspc13 by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id OAA00862; Wed, 9 Aug 2000 14:08:20 +0300 (IDT) References: <4FBEA8857476D311A03300204840E1CF67865E@whq-msgusr-02.fore.com> 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 X-Orig: Message-ID: <001801c001fa$90627fc0$6f0de28d@elex.co.il> Date: Wed, 9 Aug 2000 14:08:43 +0200 Reply-To: "Bentov, Kohava" Sender: "Media Gateway Control (megaco)" From: "Bentov, Kohava" Organization: Telrad Subject: API for Text/Binary encoding & Reply IP address To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, Please, help me to understand the following two issues: 1. The Binary and the Text encoding differ in some of the definitions. Thus, the User of the 'Megaco Stack' should know the message format of each message it sends. At first we thought that this information is relevant just to the Stack itself and it is hidden from the user (MGC or MG). But now, if some of the definitions are not the same (for example, TerminationID), the API procedures (between the User and the 'Megaco Stack') in some cases will be doubled: one for the Text format and one for the Binary. The user has to use the right API procedures according to the encoding format. . Am I right ????? 2. In section 9 the following is written: ' ...but responses must always be sent back to the address which was the source of the corresponding request.'. My question is: To which IP address should I send the response: the address mentioned in the mId field in the header of the message, or, to the Source Address of message (from the TCP or UDP layer)? Should I check the correlation between these two addresses? Thanks in advance, Bentov Kohava S/W Development Nortel SBU Telrad Networks Email:kohava.bentov@telrad.co.il From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 9 08:55:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17265 for ; Wed, 9 Aug 2000 08:55:58 -0400 (EDT) Received: from standards (47.234.32.16:1849) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB862CA@standards.nortelnetworks.com>; Wed, 9 Aug 2000 8:43:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2139 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Aug 2000 08:43:35 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB862C9@standards.nortelnetworks.com>; Wed, 9 Aug 2000 8:43:22 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA00945; Wed, 9 Aug 2000 08:54:54 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 IAA11369; Wed, 9 Aug 2000 08:54:54 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 08:54:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6786EB@whq-msgusr-02.fore.com> Date: Wed, 9 Aug 2000 08:54:54 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: API for Text/Binary encoding & Reply IP address X-To: "Bentov, Kohava" To: MEGACO@STANDARDS.NORTELNETWORKS.COM There are some differences that the "user" of the stack would have to deal with that are mostly a consequence of the differences in the way things are named. TerminationIds are the obvious one. I think it's possible for an MGC to deal with the differences, if the stack keeps the symbol table, and the interface uses handles. The stack would have to have "matching" mechanisms. While I think this is possible, I haven't implemented it (not planning on binary implementations around here at the moment). An MG that attempted to do both would be somewhat harder, I think. The text on mIds and the section 9 text needs some improvement. Basically, I think it's the case that the response usually goes to where the mId says it should go. The section 9 text refers to cases where the controlling MGC is changing. The idea is that the response goes back to the "old" MGC. Any new requests (a new Notify perhaps) would go to the mId. Brian > -----Original Message----- > From: Bentov, Kohava [mailto:kohava.bentov@telrad.co.il] > Sent: Wednesday, August 09, 2000 8:09 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: API for Text/Binary encoding & Reply IP address > > > Hi all, > > Please, help me to understand the following two issues: > > 1. The Binary and the Text encoding differ in some of the > definitions. > Thus, the User > of the 'Megaco Stack' should know the message format > of each message > it sends. At first > we thought that this information is relevant just to > the Stack itself > and it is hidden from the user > (MGC or MG). But now, if some of the definitions are > not the same > (for example, TerminationID), > the API procedures (between the User and the 'Megaco > Stack') in some > cases will be doubled: one for > the Text format and one for the Binary. > The user has to use the right API procedures according to the > encoding format. . > Am I right ????? > > 2. In section 9 the following is written: > ' ...but responses must always be sent back to the > address which > was the source of the > corresponding request.'. > My question is: > To which IP address should I send the response: > the address > mentioned in the mId field > in the header of the message, or, to the Source > Address of > message (from the TCP or > UDP layer)? > Should I check the correlation between these > two addresses? > > Thanks in advance, > Bentov Kohava > S/W Development > Nortel SBU > Telrad Networks > Email:kohava.bentov@telrad.co.il > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 9 09:25:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27706 for ; Wed, 9 Aug 2000 09:25:10 -0400 (EDT) Received: from standards (47.234.32.16:3190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB862F3@standards.nortelnetworks.com>; Wed, 9 Aug 2000 9:12:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2191 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Aug 2000 09:12:43 -0400 Received: from qhars002.nortel.com (47.101.112.102:44713) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB862F2@standards.nortelnetworks.com>; Wed, 9 Aug 2000 9:12:38 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Wed, 9 Aug 2000 14:16:47 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Wed, 9 Aug 2000 09:16:11 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 9 Aug 2000 09:16:10 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480C07@zcard00g.ca.nortel.com> Date: Wed, 9 Aug 2000 09:16:01 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Draft Meeting Minutes To: MEGACO@STANDARDS.NORTELNETWORKS.COM Here are the draft minutes for our meeting last week. Please indicate any errors or omissions. Reported by Tom Taylor. The Media Gateway Control Working Group (Megaco) met on Thursday afternoon, Aug. 3, beginning at 3:30, with Tom Taylor as Chair. About 120 people attended. The meeting did not fill its entire two hour slot. 1. Agenda ========= The proposed and actual agenda was as follows: 1. Agenda bashing 5 min 2. Status report -- work in progress 15 min 3. Status report -- interop 5 min Brian Rosen 4. ISDN 10 min Bart van Doorselaer 5. CAS package issues 10 min Michael Brown 6. Auditing of ephemerals 10 min 7. SDPng requirements 5 min 8. IETF/ITU operating agreement 15 min 2. Status Report ================ The Chair presented a report on the status of work on Megaco/H.248, organized under the headings of "Base Protocol Status", ITU-T Work In Hand", "TIPHON Work In Hand", and "IETF Megaco Work In Hand". 2.1 Base Protocol Status ------------------------ Draft-ietf-megaco-protocol-08.txt and -megaco-errata-03.txt were approved as Standards Track RFCs in May. As of the meeting date, they were at top of RFC Editor's queue, and should therefore be assigned RFC numbers shortly. The ITU-T formally decided H.248 in June. IETF Last Call on draft-ietf-megaco-merged-01.txt is complete. It was expected to be approved by the IESG as a standards-track RFC in the week following IETF 48. Since it is simply the merged content of the other two RFCs, it will obsolete them when it is published. Two errors have been identified so far: - conflict between the TDM Circuit package and Annex C - token "EB" used for both EmbedToken and EventBufferToken. The list has also brought up a large number of points of clarification. There was a discussion on how we would document these points. It was agreed (subject to ratification by the list) that we would rely on ITU-T documentation as presented in the H.248 Implementor's Guide. Specifically, we would publish the draft Implementor's Guide as an I-D. When Study Group 16 approves the document, we will publish a short RFC pointing to it. The ITU-T makes Implementor's Guides publicly available on the web at no cost. The Chair noted that list discussion included some proposals for changes to the protocol. Since Megaco/H.248 has now been fully approved, no changes are possible to this version of the protocol. 2.2 ITU-T Work In Hand ---------------------- The Chair listed the following SG 16 Annexes scheduled for November decision. WG Last Call has been issued on them. One general comment was received: make the I-D titles more descriptive. Packages: Annex F: facsimile, text conversation, call discrimination - comments (Mule/Parsons, 7/25-26/00) Annex G: display, key, keypad, label key, function key, indicator, soft key, ancillary input - one error noted (Blatherwick, 7/31/00) Annex J: dynamic tone generation Annex K: generic announcement - a meeting participant noted a comment which the Chair had overlooked. New transports: Annex H: SCTP - correction noted (Xie, 7/13/00) Annex I: ATM - I-D abstract typo noted (Xie, 7/11/00) It was agreed that we would consolidate these annexes into two documents (packages, transport alternatives) for IETF Last Call and publication as Standards Track RFCs. The errors noted in WG Last Call will be reported to the SG 16 Rapporteur's meeting being held in Portland, OR, the week of Aug. 21-25. The Chair listed the following further ITU-T work items: In Study Group 16, for November determination, Feb'01 decision: Annex L: Error Codes Annex M: Advanced Audio Server packages. On this latter, the Chair noted a potential Nortel Networks IPR claim on the original submission to the IETF (draft-cromwell-...), but could not say whether this survived in the current Study Group 16 document. He agreed to follow IETF rules on disclosure if and when Annex M comes back to the IETF. As noted already, Study Group 16 will also maintain an H.248v1 "Implementor's Guide" (i.e. bugs and clarifications) as a living document. The first draft of this document should appear out of the Portland Rapporteur's meeting, and the first approved version out of the November Study Group meeting. Study Group 16 has applied Annex G packages in H.323 Annex L "Stimulus Signalling", where H.248 content is embedded within messages passed between the Gatekeeper and the H.323 stimulus set. (For November decision.) In ITU-T Study Group 11, two different pieces of work are in progress: Question 9, for December determination: New Recommendation Q.5x, package(s) for H.248 control of signal processing network equipment. Contact: Larry Forni (larry.forni@errols.com) SG 11 BICC (Q. ??, for ?? determination) Work on Bearer-Independent Call Control (BICC) related packages. Contact: Christian Groves (christian.groves@ericsson.com) 2.3 TIPHON Work In Hand ----------------------- ETSI TIPHON Working Group 6 is working on a protocol conformance statement (PICS) for a very limited subset of the protocol -- just enough for a basic call through a trunking gateway. For the latest draft document, see http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ Contact: Klaus Sambor(Klaus.Sambor@TELEKOM.AT) 2.4 Megaco Work In Hand ----------------------- The Chair listed the following drafts reflecting work items of the group. draft-ietf-megaco-mib-00.txt (Standards Track) - main remaining charter item - awaiting inputs from Brown et al - awaiting ideas out of interop event. A new draft of this document was promised within the next month. draft-ietf-megaco-naspkg-00.txt (Standards Track) - expert resource located, more complete draft in next month. draft-ietf-megaco-ipphone-02.txt (Informational) - recycled document to be submitted for WG Last Call in the next month. draft-ietf-megaco-r2package-01.txt - WG Last Call issued, issues raised re CAS in general and this document in particular - proposed to constitute CAS design team to settle. It was at about this point that Scott Bradner intervened to point out that Megaco was attempting to move beyond its charter. The Working Group cannot take on new work items unless they fall within that charter. Once the charter has been completed, what happens to the Working Group is a matter for discussion between the WG Chair, our Area Director, the IESG at large, and the IAB. The Megaco E-mail list should continue regardless of the fate of the Working Group itself, and IETF procedure allows the submission of non-WG-initiated drafts for advancement to RFC status. Subject to that reminder, the Chair noted the following individual submissions to Megaco: draft-bouwen-megaco-isdn-00.txt - alternatives for ISDN signalling transport; ISDN D-channel data The Chair was corrected on this -- a more recent draft is available (see below). draft-brown-supplpkgs-00.txt - more call progress tones (two packages) - analog line enhanced alerting package - trunk signalling packages (robbed bit, MF) A comment was raised on this draft, to the effect that the proposed tone identifiers needed clearer documentation so that parties outside of North America could judge their applicability. Michael Brown (michael.brown@nortelnetworks.com) indicated that the document was to be reissued and that it would be split into three parts. (See further discussion of channel-associated signalling below.) draft-hss-megaco-r1package-00.txt - R1 signalling (international counterpart to MF) draft-sharp-megaco-t1rbsapp-00.txt (expired) - applicability statement for robbed bit signalling Also note draft-rajeshkumar-mmusic-sdp-atm-02.txt (SDP for ATM connections). The intent is to complete work on this document within the next month or two. Comments should be made now. Brian Rosen (brosen@marconi.com) committed to follow up and close the loop with a Megaco package for ATM. 3. Interop Event Status Report ============================== Brian Rosen presented one chart giving all the essential details regarding the Megaco/H.248 interoperability event to be held this month. [Brian, could I have it?] Between ten and twenty implementations are expected, representing both MGs and MGCs. As Brian reported, the NDA form was available within a day of the meeting. 4. ISDN (draft-bouwen-megaco-isdn-??.txt) ========================================= Bart Van Doorselaar (XXXXXX) noted that the draft had been recycled to take out the discussion of signalling transport in Megaco. Nevertheless, the issues of signalling channel management and D-channel data remained open. Brian Rosen encouraged Bart and his co-authors to submit detailed package proposals. Scott Bradner asked whether the ITU-T might have related work in hand. Christian Groves suggested that the group in Study Group 11 dealing with ISDN might be the right place to do the work. 5. Channel-Associated Signalling ================================ Michael Brown gave a brief presentation of the the issues associated with channel-associated signalling (CAS) packages. He and others felt that the approach presented in the R1 and R2 package documents was overly repetitious, and that it should be possible to define reusable events and signals common to multiple signalling systems. The authors of those documents had responded on the list to say that they had not seen enough commonality to be worthwhile isolating. In any event, it appears desirable to make CAS package definition a matter of focussed discussion amongst interested parties. The action is upon the Chair to invite these parties to submit their names and then work together to come up with a common view. 6. Auditing Of Ephemerals ========================= In the original draft agenda, this portion of the meeting was to be devoted to issues raised on the list. The Chair observed that list discussion did not lend itself to easy summarization, because there were a lot of small issues rather than a few large ones. He had identified one recent issue which could be followed up: the question of how the MGC could find out what kinds of ephemerals the MG supported in advance of instantiation. His summary of list discussion was as follows: Issue: how to tell what kind of ephemerals the MG supports, in advance of instantiation. Subsidiary issues: - whether auditCapability of ROOT returns packages which apply to individual terminations rather than the MG as a unit - whether there are constraints on the combinations of packages supported on a given (ephemeral) termination - naming patterns associated with specific types of ephemerals - (implicit) whether naming pattern is a meaningful concept with binary encoding Potential solutions: - favourable definition of auditCapability of ROOT - naming pattern property - transport-specific ROOT packages, including naming patterns. It was noted in subsequent discussion that the original proposal for a naming pattern property had been turned down at the ITU-T not because binary naming patterns are implausible, but because the ASN.1 expression of naming patterns had not been formulated and it was considered too risky to attempt the task at the last minute. Now that the pressure is off, the job can be done. Brian Rosen expressed an interest in submitting a proposal. On the general issue, Brian suggested that the Chair had presented a good summary, but that resolution would have to be done on the list. 7. SDPng ======== The Chair noted that MMUSIC is beginning to study requirements for a protocol to support session negotiation as opposed to simple session description. They have dubbed this work "SDPng". A first cut at requirements has been presented in draft-kutscher-mmusic-sdpng-req-00.txt. Related material has been assembled at http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/ Megaco is a potential customer (in Megaco/H.248v2), recalling that we had to add a fair amount to SDP to achieve what we needed. Discussion in a small group following the MMUSIC meeting had brought about general agreement that there was a fairly fine balance between meeting the real requirements and creating something overly complex. The Chair presented a summary of those requirements which originated with Mark Handley (XXXX), a participant in that discussion: - Ability to indicate when a given parameter is required and when it can safely be ignored if not supported or understood. - Ability to indicate whether a given proposal applies to send direction, receive direction, or both. - Ability to provide multiple formats and indicate whether the intent is "support all" or "choose one". - Ability to group: equivalent of multipart/related and multipart/alternative. Note that others would consider this list a good start but not quite complete. Flemming Andreasen (fga@cisco.com) and Michael Brown both expressed their concern over what introduction of a new protocol would do to existing SDP implementations. 8. Cooperation With Other Standards Bodies ========================================== In May the Chair had presented to the list a draft agreement for continued cooperation with Study Group 16 and other Study Groups. In reprise of this topic, he proposed to leave aside the legalese and have the meeting consider just the principles of any agreement. He presented four charts enumerating these proposed principles. 8.1 Considerations ------------------ The first chart presented the considerations which should be behind any agreement. (1) IETF members have a continuing interest in free access to H.248 documentation as H.248 evolves. Almost certainly they wish to participate as equal partners in that evolution. (2) There is a small probability that ITU-T reorganization this fall may place the Question dealing with H.248 (currently Q. 14/16) under new senior management. Thus any agreement for cooperation with this Question should be finalized only after the WTSA finishes its work. (3) The IESG may choose to reorganize/disband Megaco. Hence as much as possible, any agreement should be drafted to be independent of Megaco's existence. (4) Other groups doing H.248 related work may not want to cooperate as closely with Megaco as SG 16. There was no discussion of these points. 8.2 Keeping Each Other Informed ------------------------------- The minimum requirement for any agreement is that the signatories agree to keep each other informed about any Megaco/H.248-related work they plan to undertake. Corollary: the IETF must provide a designated point of contact for notifications. Discussion: Scott Bradner noted that the minimum aim of any agreements between the IETF and other bodies should also include the encouragement of cross-publication of the resulting work. This could be by means of Informational rather than Standards Track RFCs. 8.3 Base Protocol Evolution --------------------------- Chart contents: We want agreement with Q. 14/16 and its successor that: - we work with them as equal partners in developing any new versions of the base protocol; - WG Last Call resolution precedes ITU-T determination; - once any new version has been determined, it is frozen except for bug fixes and clarifications; - IETF Last Call and IESG approval occur in the interval between determination and decision; - in principle, the document approved by the IESG is the same as the document decided by the ITU-T (i.e. we do not have to keep a separate errata document as we did this time around). The ITU-T naturally retains the right to make last-minute modifications based on members' comments or newly-found errors. Discussion: Scott Bradner and Greg Ratta indicated that discussion of this chart was moot. Any continuing agreement with the ITU-T should have broader scope than that of a particular Working Group and a particular Question. Moreover, ITU-T procedures may change significantly in the wake of the meeting of the governing body next month. 8.4 Packages ------------ Chart contents: We want agreement with other standards groups that: - they will coordinate work on packages with us to minimize duplication of effort; - we will be given a chance to review packages that they are working on when we have relevant expertise, and our comments will be taken into account; - our respective processes will be coordinated to allow for that review. Discussion: Michael Kallas noted that the strong relationship between many packages points to a need for continuing coordination. Christian Groves in response recalled that the Megaco E-mail list will continue. As for the matter of consultation, package work actually involves two issues: style, and content. The originator of a package should control the content. An expert adviser could rule on style. Further discussion reiterated the importance of maintaining Megaco as a continuing list. Scott Bradner summed up by recalling that IANA registration rules could include review by a designated expert. This procedure is recommended when some degree of control over the registered material is desired. The alternative is to base registration on publicly-reviewed specifications. 9. Adjournment ============== The Chair adjourned the meeting with a word of thanks to all who had faithfully supported the work of Megaco. He noted that it might be the last time we met. Tom Taylor Lead Standards Developer taylor@nortelnetworks.com Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 9 09:40:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28114 for ; Wed, 9 Aug 2000 09:40:27 -0400 (EDT) Received: from standards (47.234.32.16:3190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8631E@standards.nortelnetworks.com>; Wed, 9 Aug 2000 9:28:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2232 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Aug 2000 09:28:09 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86312@standards.nortelnetworks.com>; Wed, 9 Aug 2000 9:18:09 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id GAA15186; Wed, 9 Aug 2000 06:29:45 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF6786EB@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39915DBF.ED3E3120@cisco.com> Date: Wed, 9 Aug 2000 09:33:51 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: API for Text/Binary encoding & Reply IP address X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "Rosen, Brian" wrote: > There are some differences that the "user" of the stack would > have to deal with that are mostly a consequence of the differences > in the way things are named. TerminationIds are the obvious one. > I think it's possible for an MGC to deal with the differences, > if the stack keeps the symbol table, and the interface uses handles. > The stack would have to have "matching" mechanisms. While I think this > is possible, I haven't implemented it (not planning on binary > implementations around here at the moment). An MG that attempted > to do both would be somewhat harder, I think. > > The text on mIds and the section 9 text needs some improvement. > Basically, I think it's the case that the response usually goes to > where the mId says it should go. No. The response always goes back to the source (address). It's by far the simplest for relibale transmission when you have to deal with clustering and failover. > The section 9 text refers to > cases where the controlling MGC is changing. The idea is that the > response goes back to the "old" MGC. Any new requests (a new Notify > perhaps) would go to the mId. Right, however that should always be the case. -- Flemming > > > Brian > > > -----Original Message----- > > From: Bentov, Kohava [mailto:kohava.bentov@telrad.co.il] > > Sent: Wednesday, August 09, 2000 8:09 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: API for Text/Binary encoding & Reply IP address > > > > > > Hi all, > > > > Please, help me to understand the following two issues: > > > > 1. The Binary and the Text encoding differ in some of the > > definitions. > > Thus, the User > > of the 'Megaco Stack' should know the message format > > of each message > > it sends. At first > > we thought that this information is relevant just to > > the Stack itself > > and it is hidden from the user > > (MGC or MG). But now, if some of the definitions are > > not the same > > (for example, TerminationID), > > the API procedures (between the User and the 'Megaco > > Stack') in some > > cases will be doubled: one for > > the Text format and one for the Binary. > > The user has to use the right API procedures according to the > > encoding format. . > > Am I right ????? > > > > 2. In section 9 the following is written: > > ' ...but responses must always be sent back to the > > address which > > was the source of the > > corresponding request.'. > > My question is: > > To which IP address should I send the response: > > the address > > mentioned in the mId field > > in the header of the message, or, to the Source > > Address of > > message (from the TCP or > > UDP layer)? > > Should I check the correlation between these > > two addresses? > > > > Thanks in advance, > > Bentov Kohava > > S/W Development > > Nortel SBU > > Telrad Networks > > Email:kohava.bentov@telrad.co.il > > -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 9 09:51:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28316 for ; Wed, 9 Aug 2000 09:51:10 -0400 (EDT) Received: from standards (47.234.32.16:3190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8633E@standards.nortelnetworks.com>; Wed, 9 Aug 2000 9:38:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2287 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Aug 2000 09:38:46 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8633D@standards.nortelnetworks.com>; Wed, 9 Aug 2000 9:38:45 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05923; Wed, 9 Aug 2000 09:50:21 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 JAA25865; Wed, 9 Aug 2000 09:50:20 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 09:50:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6786EF@whq-msgusr-02.fore.com> Date: Wed, 9 Aug 2000 09:50:18 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: API for Text/Binary encoding & Reply IP address X-To: Flemming Andreasen , "kohava.bentov@telrad.co.il" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Woops, I must not be awake. Flemming is right. The effect of the text is ALWAYS, that the RESPONSE goes back to whence it came. It's new REQUESTS that might go to where mId says. Sorry for the confusion. Brian > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Wednesday, August 09, 2000 9:34 AM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: API for Text/Binary encoding & Reply IP address > > > > > "Rosen, Brian" wrote: > > > There are some differences that the "user" of the stack would > > have to deal with that are mostly a consequence of the differences > > in the way things are named. TerminationIds are the obvious one. > > I think it's possible for an MGC to deal with the differences, > > if the stack keeps the symbol table, and the interface uses handles. > > The stack would have to have "matching" mechanisms. While > I think this > > is possible, I haven't implemented it (not planning on binary > > implementations around here at the moment). An MG that attempted > > to do both would be somewhat harder, I think. > > > > The text on mIds and the section 9 text needs some improvement. > > Basically, I think it's the case that the response usually goes to > > where the mId says it should go. > > No. The response always goes back to the source (address). > It's by far the > simplest for relibale transmission when you have to deal with > clustering > and failover. > > > > > The section 9 text refers to > > cases where the controlling MGC is changing. The idea is that the > > response goes back to the "old" MGC. Any new requests (a new Notify > > perhaps) would go to the mId. > > Right, however that should always be the case. > > -- Flemming > > > > > > > Brian > > > > > -----Original Message----- > > > From: Bentov, Kohava [mailto:kohava.bentov@telrad.co.il] > > > Sent: Wednesday, August 09, 2000 8:09 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: API for Text/Binary encoding & Reply IP address > > > > > > > > > Hi all, > > > > > > Please, help me to understand the following two issues: > > > > > > 1. The Binary and the Text encoding differ in some of the > > > definitions. > > > Thus, the User > > > of the 'Megaco Stack' should know the message format > > > of each message > > > it sends. At first > > > we thought that this information is relevant just to > > > the Stack itself > > > and it is hidden from the user > > > (MGC or MG). But now, if some of the definitions are > > > not the same > > > (for example, TerminationID), > > > the API procedures (between the User and the 'Megaco > > > Stack') in some > > > cases will be doubled: one for > > > the Text format and one for the Binary. > > > The user has to use the right API procedures > according to the > > > encoding format. . > > > Am I right ????? > > > > > > 2. In section 9 the following is written: > > > ' ...but responses must always be sent back to the > > > address which > > > was the source of the > > > corresponding request.'. > > > My question is: > > > To which IP address should I send the response: > > > the address > > > mentioned in the mId field > > > in the header of the message, or, to the Source > > > Address of > > > message (from the TCP or > > > UDP layer)? > > > Should I check the correlation between these > > > two addresses? > > > > > > Thanks in advance, > > > Bentov Kohava > > > S/W Development > > > Nortel SBU > > > Telrad Networks > > > Email:kohava.bentov@telrad.co.il > > > > > -- > Flemming Andreasen Phone: +1 732 452 1667 > Cisco Systems Fax: +1 240 359 5839 > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 9 14:36:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15801 for ; Wed, 9 Aug 2000 14:36:25 -0400 (EDT) Received: from standards (47.234.32.16:4244) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86553@standards.nortelnetworks.com>; Wed, 9 Aug 2000 14:23:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2993 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Aug 2000 14:23:59 -0400 Received: from turin.trillium.com (38.187.146.197:2275) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86552@standards.nortelnetworks.com>; Wed, 9 Aug 2000 14:23:58 -0400 Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Wed, 9 Aug 2000 11:51:07 -0700 Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id LAA06577 for ; Wed, 9 Aug 2000 11:35:25 -0700 (PDT) Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 11:29:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8BBD33A986C5D311804000902719FF5D9FB3A8@aega.trillium.com> Date: Wed, 9 Aug 2000 11:29:23 -0700 Reply-To: Bharat Kaul Sender: "Media Gateway Control (megaco)" From: Bharat Kaul Subject: Virtual MGs and MID To: MEGACO@STANDARDS.NORTELNETWORKS.COM I need a clarification regarding use of MID in virtual MG case. First consider a case where virtual MGs are controlled by the same MGC (i.e. in commands from MGC the MID is constant to all these MGs) and the transport used is UDP. How do we identify the virtual MG in a PHYSICAL MG to which the command from the MGC is destined to ? Secondly, on MGC side for UDP transport, can all these MGs use the same MID (like www.example.net) ? If yes, then we have the same identification problem on MGC side too ? I am not clear about the MID that a virtual MG should fill in its messages to MGC to identify itself uniquely i.e. how are MID's for a virtual MG and non-virtual MG different while sending messages to the MGC ? Clarifications are appreciated. - Thanks Bharat ---------------------------------------------------------------------------- ------- Bharat Kaul; Trillium Digital Systems Inc. mailto:bharat@trillium.com 12100 Wilshire Blvd, Phone: +1-310-442-9222 Los Angeles, CA - 90025. Fax: +1-310-442-1162 http://www.trillium.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 9 23:02:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27069 for ; Wed, 9 Aug 2000 23:02:54 -0400 (EDT) Received: from standards (47.234.32.16:3306) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8673E@standards.nortelnetworks.com>; Wed, 9 Aug 2000 22:50:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3627 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Aug 2000 22:50:45 -0400 Received: from devonshire.cnchost.com (devonshire.concentric.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8673D@standards.nortelnetworks.com>; Wed, 9 Aug 2000 22:50:45 -0400 Received: from MATT.ascend.com (w066.z208037018.sjc-ca.dsl.cnc.net [208.37.18.66]) by devonshire.cnchost.com id XAA04330; Wed, 9 Aug 2000 23:02:21 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Errors-To: X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000809195823.00c7bac0@pop3.ipverse.com> Date: Wed, 9 Aug 2000 20:00:51 -0700 Reply-To: Matt Holdrege Sender: "Media Gateway Control (megaco)" From: Matt Holdrege Subject: Re: megaco NAS package X-To: Ravi Subramaniam To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200008071704.NAA04332@shako.cisco.com> As I've said many times before, what makes a NAS different than any ordinary MG? If you do maintain that there are some things that a NAS package would need special, then your I-D should only have those differences. Just print the delta. Why would you have a NAS Id different than an MG ID. Why is a call ID different on a NAS, etc., etc., etc. At 01:04 PM 8/7/00 -0400, Ravi Subramaniam wrote: >Content-Type: TEXT/plain; charset=us-ascii >Content-MD5: VvOptRvtVxsU/at0TsWg5A== > >Attachment included !! oops ... > > > > > Hello Tom... > > I have a prelimnary nas package which I build on top of the > existing one, > > please take a look at it. I am working on making it IETF compliant > > right now, so alignments etc. may be off. > > Thanks ... > > Ravi Subramaniam > > IOS-Wan Connectivity Products > > Cisco Systems > >Thanks ... >Ravi Subramaniam >IOS-Wan Connectivity Products >Cisco Systems >Content-Type: TEXT/plain; name="new_naspkg.02.txt"; charset=us-ascii; >x-unix-mode=0644 >Content-Description: new_naspkg.02.txt >Content-MD5: vNDr9WtJBf9PBr8fbWr58A== > > >Media Gateway Control (Megaco) Mike Kallas >Internet Draft Nortel Networks >Document: draft-ietf-megaco-naspkg-01.txt Zacharias Bilalis >Category: Standards Track Siemens > Ravi Subramaniam > Cisco Systems > > > Megaco/H.248 NAS Package From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 10 07:17:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15149 for ; Thu, 10 Aug 2000 07:17:04 -0400 (EDT) Received: from standards (47.234.32.16:1991) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB867E8@standards.nortelnetworks.com>; Thu, 10 Aug 2000 7:04:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3827 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Aug 2000 07:04:09 -0400 Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB867E7@standards.nortelnetworks.com>; Thu, 10 Aug 2000 7:04:09 -0400 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA01961 for ; Thu, 10 Aug 2000 07:15:50 -0400 (EDT) Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA01921 for ; Thu, 10 Aug 2000 07:15:48 -0400 (EDT) Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA02775; Thu, 10 Aug 2000 13:15:27 +0200 (MET DST) X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <8BBD33A986C5D311804000902719FF5D9FB3A8@aega.trillium.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39928EB4.8C401FF3@lucent.com> Date: Thu, 10 Aug 2000 13:15:00 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Virtual MGs and MID To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Bharat, Only the IP address of the virtual MGs would be the same; they can be distinguished by port number. This scheme works by virtue of the fact that (virtual) MGs initiate the registration procedure and can inform the MGC of the port number they want to use in the first message (servicechange). Cheers, John Bharat Kaul wrote: > > I need a clarification regarding use of MID in virtual MG case. > > First consider a case where virtual MGs are controlled by the same MGC (i.e. > in commands from MGC the MID is constant to all these MGs) and the transport > used is UDP. How do we identify the virtual MG in a PHYSICAL MG to which the > command from the MGC is destined to ? > > Secondly, on MGC side for UDP transport, can all these MGs use the same MID > (like www.example.net) ? If yes, then we have the same identification > problem on MGC side too ? I am not clear about the MID that a virtual MG > should fill in its messages to MGC to identify itself uniquely i.e. how are > MID's for a virtual MG and non-virtual MG different while sending messages > to the MGC ? > > Clarifications are appreciated. > > - Thanks > Bharat > > ---------------------------------------------------------------------------- > ------- > Bharat Kaul; Trillium Digital Systems Inc. > mailto:bharat@trillium.com 12100 Wilshire Blvd, > Phone: +1-310-442-9222 Los Angeles, CA - 90025. > Fax: +1-310-442-1162 http://www.trillium.com -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 10 10:32:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25010 for ; Thu, 10 Aug 2000 10:32:23 -0400 (EDT) Received: from standards (47.234.32.16:4359) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8687A@standards.nortelnetworks.com>; Thu, 10 Aug 2000 10:19:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4002 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Aug 2000 10:19:56 -0400 Received: from qhars002.nortel.com (47.101.112.102:40007) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86879@standards.nortelnetworks.com>; Thu, 10 Aug 2000 10:19:51 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Thu, 10 Aug 2000 15:30:35 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Thu, 10 Aug 2000 09:25:36 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 10 Aug 2000 09:29:05 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD11480C14@zcard00g.ca.nortel.com> Date: Thu, 10 Aug 2000 09:29:04 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: IANA Registration Of Packages To: MEGACO@STANDARDS.NORTELNETWORKS.COM I have compiled the following set of instructions to IANA for registration of Megaco/H.248 packages. Before I submit it, I would like your comments. I believe I capture the content of our sections 12 and 13 (though in main part by reference). I have taken two liberties: -- the private numbering range has been extended a bit to round out the hexadecimal representation -- I impose a naming convention for private packages which requires an originator-specific part followed by an underscore as the first part of the package name. So ... comments? INSTRUCTIONS FOR THE REGISTRATION OF MEGACO/H.248 PACKAGES 1. Introduction Packages are the primary mechanism for extension of the Megaco/H.248 Gateway Control Protocol. Packages define additional Properties, Events, Signals and Statistics that may occur on Terminations or on the Media Gateway as a whole. Packages may also define new Megaco/H.248 error codes. This is a matter of documentary convenience: the package documentation is submitted to IANA in support of the error code registration. If a package is updated, it is unnecessary to provide IANA with a new document reference in support of the error code unless the description of the error code itself is modified. 2. Relationships Between Packages A new package may be independent, may extend another package, or may be a new version of a previously registered package. 3. Conditions For Registration Of Packages Megaco/H.248 packages may be registered with IANA as either public or private packages. 3.1 Common Requirements For Registration The following information MUST be supplied for every registered package: a) the proposed text name for the package. Text names MUST be unique, with the exception that a new version of a previously registered package MUST have the same name as the package it updates. b) the version number of the package. Version numbers are consecutive integers beginning with 1 for the initial version of a package. c) if the package extends another package, the text name and, if available, serial number of the other package. d) a contact name and E-mail and postal addresses for that contact. The contact information MUST be updated by the defining organization as necessary. 3.2 Additional Requirements For Registration Of Private Packages Private packages MUST have text names of the form qualifier "_" packageName where qualifier is unique to the organization or individual registering the package. There is no additional requirement beyond this and the requirements stated in the previous section. 3.3 Additional Requirements For Registration Of Public Packages Public packages MUST satisfy the following requirements additional to those stated in section 3.1: a) The defining organization MUST supply a reference to a publicly-available document which describes the package. The document SHOULD be located on a public web server and SHOULD have a stable URL. The documentation MUST remain available even when a new version of the package is registered. The organization SHOULD indicate within the document where comments on that document may be sent. b) The document MUST have achieved an advanced degree of technical stability. c) The defining organization MUST indicate whether the document is still a work in progress or is final. For a work in progress, the organization MUST indicate the planned date of the final document. When such a document does become final, the defining organization MUST advise IANA of the change in status and MUST ensure that the reference held by IANA is that of the final document. d) IANA MUST be satisfied that the cited document satisfies the requirements given in section 12 of RFC XXXX (currently draft- ietf-megaco-merged-01.txt) or Recommendation H.248 (the corresponding ITU-T document). IANA may draw upon the services of an expert adviser in making this assessment. 4. IANA Actions IANA will assign a serial number to each package meeting the conditions of registration (except for an update of an existing package, which retains the serial number of the package it is updating), in consecutive order of registration. The serial number will be used to identify the package in the binary-coded version of the Megaco/H.248 protocol. Serial number 0 is reserved, and the initial tabulation of public packages is given below. Public packages MUST be given serial numbers in the range 0x0001 to 0xfdff. Private packages MUST be given serial numbers in the range 0xfe00 to 0xffff. IANA will maintain the currency and public availability of the tabulation of public and private packages. Packages will be listed in increasing order of serial number. Updates to packages will be listed in increasing order of version number. 5. Initial Tabulation Of Public Packages Serial Text Name Ver Extends Status Reference/ Serial Ver Contact 0x0001 g 1 - - Final Annex E of RFC xxxx or ITU-T Rec. H.248 Glen Freundlich ggf@avaya.com 0x0002 root 1 - - Final ditto 0x0003 tonegen 1 - - Final ditto 0x0004 tonedet 1 - - Final ditto 0x0005 dg 1 0x0003 1 Final ditto 0x0006 dd 1 0x0004 1 Final ditto 0x0007 cg 1 0x0003 1 Final ditto 0x0008 cd 1 0x0004 1 Final ditto 0x0009 al 1 - - Final ditto 0x000a ct 1 - - Final ditto 0x000b nt 1 - - Final ditto 0x000c rtp 1 0x000b 1 Final ditto 0x000d tdmc 1 0x000b 1 Final ditto 0x000e ftmd 1 0x0004 1 IP 11/00 RFC yyyy /H.248 Annex F Glen Freundlich ggf@avaya.com 0x000f txc 1 - - IP 11/00 ditto 0x0010 txp 1 - - IP 11/00 ditto 0x0011 ctyp 1 - - IP 11/00 ditto 0x0012 fax 1 - - IP 11/00 ditto 0x0013 ipfax 1 - - IP 11/00 ditto 0x0014 dis 1 - - IP 11/00 RFC yyyy /H.248 Annex G Glen Freundlich ggf@avaya.com 0x0015 key 1 - - IP 11/00 ditto 0x0016 kp 1 0x0015 1 IP 11/00 ditto 0x0017 labelkey 1 0x0015 1 IP 11/00 ditto 0x0018 kf 1 0x0017 1 IP 11/00 ditto 0x0019 ind 1 - - IP 11/00 ditto 0x001a ks 1 0x0017 1 IP 11/00 ditto 0x001b anci 1 - - IP 11/00 ditto 0x001c dtd 1 - - IP 11/00 RFC yyyy /H.248 Annex J Glen Freundlich ggf@avaya.com 0x001d an 1 - - IP 11/00 RFC yyyy /H.248 Annex K Glen Freundlich ggf@avaya.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 10 17:50:06 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14627 for ; Thu, 10 Aug 2000 17:50:06 -0400 (EDT) Received: from standards (47.234.32.16:2292) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86978@standards.nortelnetworks.com>; Thu, 10 Aug 2000 17:37:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4314 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Aug 2000 17:37:46 -0400 Received: from shako.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86977@standards.nortelnetworks.com>; Thu, 10 Aug 2000 17:37:45 -0400 Received: from shako.cisco.com (shako.cisco.com [161.44.3.76]) by shako.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id RAA19637; Thu, 10 Aug 2000 17:49:04 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: CHERRyn+CLYeRy5xk3GGfw== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Message-ID: <200008102149.RAA19637@shako.cisco.com> Date: Thu, 10 Aug 2000 17:49:04 -0400 Reply-To: Ravi Subramaniam Sender: "Media Gateway Control (megaco)" From: Ravi Subramaniam Subject: Re: megaco NAS package X-To: matt@ipverse.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello Matt ... I thought that was the whole idea of packages, we can inherit the properties of some packages and create packages which efficiently grouped items required for a particular application, even though it may be defined across many other packages ... In my draft I did get rid of call_state signal since MODIFY can accomplish the same thing. I am looking at the nas id now ... > > As I've said many times before, what makes a NAS different than any > ordinary MG? If you do maintain that there are some things that a NAS > package would need special, then your I-D should only have those > differences. Just print the delta. Why would you have a NAS Id different > than an MG ID. Why is a call ID different on a NAS, etc., etc., etc. > > > At 01:04 PM 8/7/00 -0400, Ravi Subramaniam wrote: > >Content-Type: TEXT/plain; charset=us-ascii > >Content-MD5: VvOptRvtVxsU/at0TsWg5A== > > > >Attachment included !! oops ... > > > > > > > > Hello Tom... > > > I have a prelimnary nas package which I build on top of the > > existing one, > > > please take a look at it. I am working on making it IETF compliant > > > right now, so alignments etc. may be off. > > > Thanks ... > > > Ravi Subramaniam > > > IOS-Wan Connectivity Products > > > Cisco Systems > > > >Thanks ... > >Ravi Subramaniam > >IOS-Wan Connectivity Products > >Cisco Systems > >Content-Type: TEXT/plain; name="new_naspkg.02.txt"; charset=us-ascii; > >x-unix-mode=0644 > >Content-Description: new_naspkg.02.txt > >Content-MD5: vNDr9WtJBf9PBr8fbWr58A== > > > > > >Media Gateway Control (Megaco) Mike Kallas > >Internet Draft Nortel Networks > >Document: draft-ietf-megaco-naspkg-01.txt Zacharias Bilalis > >Category: Standards Track Siemens > > Ravi Subramaniam > > Cisco Systems > > > > > > Megaco/H.248 NAS Package Thanks ... Ravi Subramaniam IOS-Wan Connectivity Products Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 10 21:44:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19276 for ; Thu, 10 Aug 2000 21:44:09 -0400 (EDT) Received: from standards (47.234.32.16:2427) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB869E4@standards.nortelnetworks.com>; Thu, 10 Aug 2000 21:31:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4445 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Aug 2000 21:31:58 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB869E2@standards.nortelnetworks.com>; Thu, 10 Aug 2000 21:21:58 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7B1XZw06065; Fri, 11 Aug 2000 03:33:35 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id DAA04224; Fri, 11 Aug 2000 03:33:35 +0200 (MET DST) Received: from ericsson.com (7-179.epa.ericsson.se [146.11.7.179]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id DAA19675; Fri, 11 Aug 2000 03:33:31 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480C14@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3993434A.737CB89A@ericsson.com> Date: Fri, 11 Aug 2000 10:05:30 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: IANA Registration Of Packages X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Tom, Looks good. Just a couple of comments marked CHG below. Cheers, Christian Tom-PT Taylor wrote: > > I have compiled the following set of instructions to IANA for registration > of Megaco/H.248 packages. Before I submit it, I would like your comments. > > I believe I capture the content of our sections 12 and 13 (though in main > part by reference). I have taken two liberties: > -- the private numbering range has been extended a bit to round out the > hexadecimal representation [CHG] OK by me. > -- I impose a naming convention for private packages which requires an > originator-specific part followed by an underscore as the first part of the > package name. > > So ... comments? > > INSTRUCTIONS FOR THE REGISTRATION OF MEGACO/H.248 PACKAGES > > 1. Introduction > > Packages are the primary mechanism for extension of the Megaco/H.248 > Gateway Control Protocol. Packages define additional Properties, > Events, Signals and Statistics that may occur on Terminations or on > the Media Gateway as a whole. > > Packages may also define new Megaco/H.248 error codes. This is a > matter of documentary convenience: the package documentation is > submitted to IANA in support of the error code registration. If a > package is updated, it is unnecessary to provide IANA with a new > document reference in support of the error code unless the > description of the error code itself is modified. [CHG] What do you mean document reference? I thought that the package that was being registered was the document which described the error code? > > 2. Relationships Between Packages > > A new package may be independent, may extend another package, or may > be a new version of a previously registered package. [CHG] Perhaps the statement about a new version needs to be changed? Its not really a 'new' package. Only the new version number would be registered with IANA not a new name. > > 3. Conditions For Registration Of Packages > > Megaco/H.248 packages may be registered with IANA as either public > or private packages. > > 3.1 Common Requirements For Registration > > The following information MUST be supplied for every registered > package: > > a) the proposed text name for the package. Text names MUST be > unique, with the exception that a new version of a previously > registered package MUST have the same name as the package it > updates. > > b) the version number of the package. Version numbers are > consecutive integers beginning with 1 for the initial version > of a package. > > c) if the package extends another package, the text name and, if > available, serial number of the other package. [CHG] The serial number will always be available as its mandatory in the package description. ie. "if the package extends another package, the text name and serial number of the package it extends." > > d) a contact name and E-mail and postal addresses for that > contact. The contact information MUST be updated by the > defining organization as necessary. [CHG] How would this work for different organisations? For example in the ITU would it be the TSB? In the IETF who would it be if it comes through the WG process? Would it be enough to just reference the appropriate document number as this won't change but people do? > > 3.2 Additional Requirements For Registration Of Private Packages > > Private packages MUST have text names of the form > qualifier "_" packageName > where qualifier is unique to the organization or individual > registering the package. There is no additional requirement beyond > this and the requirements stated in the previous section. [CHG] How is this qualifier kept unique? Is it up to IANA to police this? > > 3.3 Additional Requirements For Registration Of Public Packages > > Public packages MUST satisfy the following requirements additional > to those stated in section 3.1: > > a) The defining organization MUST supply a reference to a > publicly-available document which describes the package. The > document SHOULD be located on a public web server and SHOULD > have a stable URL. The documentation MUST remain available > even when a new version of the package is registered. The > organization SHOULD indicate within the document where > comments on that document may be sent. [CHG] Public web server? Does a web server that has password protection count ie. ITU, MSF etc? I know the recommendation states this but should we clarify it here? > > b) The document MUST have achieved an advanced degree of technical > stability. > > c) The defining organization MUST indicate whether the document is > still a work in progress or is final. For a work in progress, > the organization MUST indicate the planned date of the final > document. When such a document does become final, the defining > organization MUST advise IANA of the change in status and MUST > ensure that the reference held by IANA is that of the final > document. > > d) IANA MUST be satisfied that the cited document satisfies the > requirements given in section 12 of RFC XXXX (currently draft- > ietf-megaco-merged-01.txt) or Recommendation H.248 (the > corresponding ITU-T document). IANA may draw upon the services > of an expert adviser in making this assessment. > > 4. IANA Actions > > IANA will assign a serial number to each package meeting the > conditions of registration (except for an update of an existing > package, which retains the serial number of the package it is > updating), in consecutive order of registration. The serial number > will be used to identify the package in the binary-coded version of > the Megaco/H.248 protocol. Serial number 0 is reserved, and the > initial tabulation of public packages is given below. Public > packages MUST be given serial numbers in the range 0x0001 to 0xfdff. > Private packages MUST be given serial numbers in the range 0xfe00 to > 0xffff. > > IANA will maintain the currency and public availability of the > tabulation of public and private packages. Packages will be listed > in increasing order of serial number. Updates to packages will be > listed in increasing order of version number. > > 5. Initial Tabulation Of Public Packages > > Serial Text Name Ver Extends Status Reference/ > Serial Ver Contact > > 0x0001 g 1 - - Final Annex E of RFC xxxx or > ITU-T Rec. H.248 > Glen Freundlich > ggf@avaya.com > 0x0002 root 1 - - Final ditto > 0x0003 tonegen 1 - - Final ditto > 0x0004 tonedet 1 - - Final ditto > 0x0005 dg 1 0x0003 1 Final ditto > 0x0006 dd 1 0x0004 1 Final ditto > 0x0007 cg 1 0x0003 1 Final ditto > 0x0008 cd 1 0x0004 1 Final ditto > 0x0009 al 1 - - Final ditto > 0x000a ct 1 - - Final ditto > 0x000b nt 1 - - Final ditto > 0x000c rtp 1 0x000b 1 Final ditto > 0x000d tdmc 1 0x000b 1 Final ditto > 0x000e ftmd 1 0x0004 1 IP 11/00 RFC yyyy /H.248 Annex F > Glen Freundlich > ggf@avaya.com > 0x000f txc 1 - - IP 11/00 ditto > 0x0010 txp 1 - - IP 11/00 ditto > 0x0011 ctyp 1 - - IP 11/00 ditto > 0x0012 fax 1 - - IP 11/00 ditto > 0x0013 ipfax 1 - - IP 11/00 ditto > 0x0014 dis 1 - - IP 11/00 RFC yyyy /H.248 Annex G > Glen Freundlich > ggf@avaya.com > 0x0015 key 1 - - IP 11/00 ditto > 0x0016 kp 1 0x0015 1 IP 11/00 ditto > 0x0017 labelkey 1 0x0015 1 IP 11/00 ditto > 0x0018 kf 1 0x0017 1 IP 11/00 ditto > 0x0019 ind 1 - - IP 11/00 ditto > 0x001a ks 1 0x0017 1 IP 11/00 ditto > 0x001b anci 1 - - IP 11/00 ditto > 0x001c dtd 1 - - IP 11/00 RFC yyyy /H.248 Annex J > Glen Freundlich > ggf@avaya.com > 0x001d an 1 - - IP 11/00 RFC yyyy /H.248 Annex K > Glen Freundlich > ggf@avaya.com [CHG] Is Glen the appropriate reference or should the TSB be referenced? From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 10 21:46:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19329 for ; Thu, 10 Aug 2000 21:46:52 -0400 (EDT) Received: from standards (47.234.32.16:2427) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB869F9@standards.nortelnetworks.com>; Thu, 10 Aug 2000 21:32:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4446 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Aug 2000 21:32:59 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB869E3@standards.nortelnetworks.com>; Thu, 10 Aug 2000 21:22:58 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7B1Yew06110 for ; Fri, 11 Aug 2000 03:34:40 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id DAA04313 for ; Fri, 11 Aug 2000 03:34:39 +0200 (MET DST) Received: from ericsson.com (7-179.epa.ericsson.se [146.11.7.179]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id DAA19699 for ; Fri, 11 Aug 2000 03:34:22 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------2B383B83E3F44C8B9F523D14" Message-ID: <3993572B.41AD24FC@ericsson.com> Date: Fri, 11 Aug 2000 11:30:20 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: H.248 Annex L To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------2B383B83E3F44C8B9F523D14 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit G'Day all, Attached is a first draft of H.248 Annex L which defines Error Codes and Service Change Reasons. First version is in PDF but once comments are received it will be made into a draft. Comments are welcome. I'll try to incorporate the commments recieved before Monday into a contribution to SG16. One general question I have is does anyone know how we assigned the numbers? It would be good to have a section in the annex L which documents this so that future codes can be added in the same way. Cheers, Christian --------------2B383B83E3F44C8B9F523D14 Content-Type: application/pdf; name="APC-1912_error_code_contribution_v2.PDF" Content-Disposition: inline; filename="APC-1912_error_code_contribution_v2.PDF" Content-Transfer-Encoding: base64 JVBERi0xLjIgDQol4uPP0w0KIA0KOCAwIG9iag0KPDwNCi9MZW5ndGggOSAwIFINCi9GaWx0 ZXIgL0xaV0RlY29kZSANCj4+DQpzdHJlYW0NCoAQioDRyMBANByLhsOBAICoRAbBokIDkZxA DReRoMMRgLhhDIcZgaLY6MBoNhrDSoYxBHRiNpRKjuIBQKiGbzcdDCYzoOhAQTYZhAKYcaga NRuLhmNpbKiIIJJHhmORjKpZJRmMarDpmKCQZTSZDKcjaYTka4babVayLZTSbJ9RCpRq0Mo9 DINDqfE6rFYvUZMOBlVqbXJpQDMLq/YbHZbOQDqYTELrGaTGcznOBcczLcroM7sOaZeYfTYn fpHWBrKYdV48NRlTMMKLSUDQLp8K5OIIYNxkNxAMxwORpngaRYHfIpFgaMhrCRoNIPDBjoBd vpaLhpDDkZRBIoFBINwhdL6dEdNy7/Jd/hPZMppa/layGaDkaTmdDSYTdQ6KBobug6TSKewA cBswbWuyjgZhm+AUCOOQ3jsMo5vm+S2jCt64v+grtLwpz0r65jABoraVsKKiuvq+78v2NwXQ jCcKiAyrLszGAxjeNrjBiGSEtHEKJoM1DABk3cFMAGAauk2a1NsFwQBWGyqwcHIZhgqsqJe4 zkPQjb1Oa54XBywalw+EEfISpbsu2ijvJEOKLhqGCOulAIavKwc8hk6gYhc2E3hAK4QP6Brw zpOwQQCpIbtkh8vqa1DSKvB4Yy6gYoou8KC0XMc2L1SMiOYjKqq1QEEiokTABiG7WRQktW1e rokioKqHDKNgyx0No2jqNzLDC/ScBAKadDcMizDINI9WENNiCnXY6DeOTjR+pMgr0qCShgGb gQVblvQeIg3jGOo2jKnKfigIYWhiqgZOMFtroUqDqhdVMCvY81wI8GV+RUmljDqMg8hBGQ6j hNIbWsHNsRTfV/Bxb9YYliiuissY52e/oeDIOQwjMOgfXleimXcGd8RDVjhvcjwY5a2Yoz0F uZhiGgXvMKQwjgOFqDoMo6jkEF0DK/Q3DPhuHwI7M6o+90HhlpySBpdwcZLh165RlVtSMGlX tcGEj1mmgoZ+Nj+DIEGpXm4r/t9MimTyk0Q1LRbtSbVSItfH+oNmOg0OMGzrsGFu57yp+7VP QKQtTf1XZdsXIScII6jOOr83lAKFIYFqYSEqTib9gIUCmJ4qikIYiuM7d8QHITCJq4080diA QIyjc/8ZvUDbpfqP990gQJ8Itl2nar/8M6Wt3z24jVN3VUpFWMfMJVnqtmKlaiYIsOLmBoaM HpncTT6KVVXfcT7Df8Tq6JHXIYII3DcMo8BAJgQC4GTYhAIo5ISaGTcsQIG0rFLGHYyx3j6n 8DOd4KQZQwo4BAERCoYz7hwWGG5eT4V7Mpea4p8zjVKIpK6FB1AUAnhTe67NpbdSNPlVQ+dx wMFHthUeV0EAUEJM+DmGENi8ikNaPI4h5ypiSkgd4ewG7eSWGATLDcmifyDBCCCEMJYRwpOn CcEQ4xBl5p5TLC53MMXGteiY003zeSuhBDoCBwB3gnw9DWGFYoRzzBpjaHeCIIA4Q7DeZxtT gFhP9f+tQEEAkKggLEGYNL9G1SNjcGg7z70jkMJud2HKElpo6h+f+Ly9zosrPYDRikNmHIPf oGUsUgQ3ggDEd6V4dGgNDkXI2VQIFiB3kkf1aYIHMHejeG2AiyAQS6kHG+AjPYdn3WEd4ncG QQH4mLLuLsHWuGlMAcIHLLgYg1Zi6Q/gICxwABAjqAc0oGv0ZA0BtUhjuhjLAhQMgLpqxfmu 4l56aYjwyRKDeJBriXz+aiR6HMWYUBTCCEyepzkyQfhe4t6UM0ftgaaDVKiDwqSSjc/WNsrw 2BvJnH0N8PJEx0CcGUmb8n6P2fwC0/z313ogW0+Qjhd5+ElSpRQlwOJuoPCKFKLIUpDhPCIE UKZP4trFp+FYJLqpDhICCE4I7q3k0xXsn92rXSS0Wp0eVRzZAUBSCKEF0wToJ1GCGFIJIUHt BPCdQtlLwWIkmW65EhaD1ohygRPCQ4aIGQOggjhCwdyxzODJKuAiFo8TRQsZxdMkZjySM5AQ NhmVChllvLVYEGZ6H/S8QEANCmVuZHN0cmVhbQ0KZW5kb2JqDQo5IDAgb2JqDQoxNTAxDQpl bmRvYmoNCjQgMCBvYmoNCjw8DQovVHlwZSAvUGFnZQ0KL1BhcmVudCA1IDAgUg0KL1Jlc291 cmNlcyA8PA0KL0ZvbnQgPDwNCi9GMCA2IDAgUiANCi9GMSA3IDAgUiANCj4+DQovUHJvY1Nl dCAyIDAgUg0KPj4NCi9Db250ZW50cyA4IDAgUg0KPj4NCmVuZG9iag0KMTEgMCBvYmoNCjw8 DQovTGVuZ3RoIDEyIDAgUg0KL0ZpbHRlciAvTFpXRGVjb2RlIA0KPj4NCnN0cmVhbQ0KgBCK gNHIwEA0HIuGw4EAgKhEBsGiQgORnEANF5GgwxGAuGEMhxmBotjowGg2GsNKhjEEdGI2lEqO 4gFAqIZvNx0MJjOg6EBBNhmEAphxqBo1G4uGY2lsqIggkkeGY5GMqlklGYxqsOmYoJBlNJkM pyNphORrhtptVrItlNJsn1EKlGrQyj0Mg0Op8TqsVi9Rkw4GVWptcmlAMwur9hsdls5AOphM QusZpMZzOc4FxzMtyugzuw5pl5h9Nid+kdYGsph1Xjw1GVMwwotJQNAunwrk4ghg3GQ3EAzH A5GmeBpFgd8ikWBoyGsJGg0g8MGOgF2+louGkMORlEEigUEg3CF0vp0R03Lv8l3+E9kymlr+ VrIZoORpOZ0NJhN1DooGhu6DpNIp7ABwGzBta7KOBmGb4BQI45DeOwyjm+b5LaMK3ri/6Cu0 vCnPSvrmMAGitpWwoqK6+r7vy/Y3BdCMJwqIDKsuzMYDGN42uMGIZIS0cQomgzUMAGTdwUwA YBq6TZrU2wXBAFYbKrBwchmGCqyol7jOQ9CNvU5rnhcHLBqXD4QR8hKluy7aKO8kQ4ouGoYI 66UAhq8rBzyGTqBiFzYTeEArhA/oGvDOk7BBAKkhu2SHy+prUNIq8HhlLqBiii7whyhIcTu2 LrwTSEhzCjKqhkuyPpUkTANhE7XSWGUTq6JAXSOhggicJwiiwEAmBALlUqYIopCkJ4pBAIYn iIIopp+JwiOMhCFIYFsjxCqKOVS9zyhhbjZinYorCSIYi2UJFdCPc4pCKIIpieJzjBvP9HKh bC9KgkoaBlB0FNIrtmimIYpCSKAqCTeNMAaHAcUApiYKSwcTYc0Dsuw7rv0OgaChAlCOhtJt IVPNM/0CkL0QUFAYuNPN7QIECMsGrVAVGkUfIUGYb5Err/LmBoYzzT8UqfkmaZOKlWvY7F/w eJKcwkMg6p4NKcONa8/qZa4Zo9kWio1NKSpBpLUo9KlHtdoKEQeKg0PwED+DcMo8BAsQzDTu ULDoNDvCKOUJDlZQ3rFvQ0DCOm4YyOrODIEG8BBvbvR1jNbVwEA4QkOg3x0NkoiTxA2PwOnC 77v438Cm6xOMgwW6PUcCpLOlR7SGAZtZFSaDcOo2jEse4Mxzb9joMvGjuNO98hvgQb9wHBLF QowjaMvPcRyL+8xCbGQsMO6jLu43ePqr+jeoQ774/vI+X03UcG723804wqBVfSPXoHNuhiHE lwf3oQcW8RuAbnGhpKE+l5jp3nPuQs3ZvEAHHvcDgTsNYYQzvTBA59uAbDMuXQkHZ7UAXHQC Ms4d8QIHyAgfM4dyDc3EFlDyCB3r8X5olBg2g7MNUkO4BQ3gMYbA6ligG+h5UB3AhUhY90OY Yz7hwc04FzUGQ2BvJmGYOocnIuBbw8MOTmAyk6P0TiE0BYhvrgSlEKYZWqRgOMzpRqQV8qUR SV1S5/wWxsOu1p1y2TVHAX+eU1cfIdPYg84R5KFTvFiJ0W8OYLnVr3a4SaPTZlVx9JeDd25X W2tvbi3ODMG4GN5kKCCM4coPBjO8fU/kFQQBSDKGFHDhYVFmO8/+IMoXJnecqm57DmnOPUBA 6E/LpJGutT+n2SKS0qP4Yog+UcpZTuGDdKqVkrowI6efK4zIY3hQAeM8h9MzTLTPlSd6aaOA QTWO8G56MFoMSCg+GGYceV8mAmTJQGwN5AFdk++GMEJ3zBliEd6cEpllTQmlK2cz7w3wwlm4 yXwYYNULndIQ/kIQyQji++N8rhnqwshk/RJbtX8KpX9DqF1DIQw9h/A6gMoixzOoLOMEELKA BzhLE+iEUYpxVivCGLUXIvQlhPN+l84aYzRM6f9+VICltjbSDUhaD5ymapdGk/pxp7q3aI/R fCKGAE0BmtMFyIJ5r7Xo/ie6tD40TQrIUzj3ZEwakZHQ7C1waKiRC0ZkzNmU1eUsy2O9W2ZM lZqqxoBdgbM6Z4fFHrQkB15CMVWeTZElT3W6nWyxs4iQJDm1dWZCioWTa+RtsVhkSnCsuDS1 BswgmYDSGd8E0X1PNdShUHU8V6qPa+g4jhd7TL7U6/gqb9zZh7CLReJqwlUoWDcG94ZPgwhk ca8MPDiIwBoik5Chc2LXn9d07wsYcw+zDR+rdsbX7JV8X2e5Sx5bGp6sEEZmd6jCW9BmdFB7 PjPrVviRuviRgYSAbSDTAKD7N21BACO25/yYXxvTYaOBLlRs9wIQY4yR1b2PXyRm/1vzykcZ EpU2YTp14LZ+Vk7WGjStGvpJTCdjD/tcR9VtIagFvphJK0GGxLiTWLBQEK6MqwyhxDqhUOjC 0jtcKZaohhKLzJtO4nBjYDUsMOYaQd2xSrdNlx7iFBbIcfSiDyTkMLdCxvNce9IzEFKks/R8 DbDOND0qTvg002YLGF41dkmHKtYyGWqNCUzN6aatMZJEqU1ANQY13qhlguybiOnYvKvbQ2U2 Or8a4mwvRGLItht8ygwBS6SksBQER7zeJ+BuxMUZ1jNJjYbbBb2SdlKzWXTK2x5QdA5H8DmT ujKb8iZGC4CgOYXCiOGQs72gDdT8HdDOWaIDdci3abgCAOeYydZmjJsihmy5ERoeG42FT6c1 a9grbiwtZWzHDfxJZR5XQ2BlQo50lTyty5sbqG+ttzXEI6DcGZ04bdqPpew1KqyFoThNQrua trjwghubk3QIMJnA8P4iCAITv6PqudmgtfiDwwhwDg6EMZkt4pRCq4yFD56ZguDOlG5pDtdh u17Vac9FX+wRDlQ7dC9tYWStLqArG7M7Q6ChBLNmqz0TEyfup2oNriIoBRKwMxY6ASm6USe3 zMMOae1m0psxz38A47Ek4Jwb88R060qvpnPsV6d1k2PsC358WXdrPkmlm4jXVhDKHM8CNTRJ iXE3pWrZi3npBVHoqK0dvSJz0qpfXe44eSWzu4UlyaBX5Y+9tyFpaA/guZRzyFoCSh3vKpt/ f25BvcWCC7BMwyULDz6x/1b30hU5nzWjISSn8ADluhpDsCpP5vYbNyZ3Q2QkJwD+8hCfgsx7 heprphAUF2jnm5POM+uXyTTi1FF9r8JOR7kqsnb8O9CI8DLAslMCd4BRgd9uCelYN+3g9lGE c6w6IOlm/Rza7lsPtvztaMPpIPFiaMSHpOlMUL8P6vuvKDYqnOPPFP9AoHMnNg3g2LZnTmrm gk7FrMZufuvO5MuNRPiodNTHvtUvCrQvDrILSNPwBqQuom0ilt3iaG2jvNdNeNfISjutgj8t htitjpXNuj+qLg5tnNoIAGpQcrtgQIPQMPlKNAQOFNnkdIOLnQLwMnsJTGpDukLNkPgHXqmF Zn8FXn+AytvIutwHiK5mfvDLAwQvJv0E6uiK/DZujgxoJoKwVumNXjStQuoPqOqOrA3OsFps 4FVwAwRMPGgw7DXDfw7Geuzmru1wPrcrIOgQYO5jfsBIbu7sDIyO9nEHHn0u/nAvAolA0omH Tw+rRPEwIqvgUCbg2vHCet0Q/rRxGQ6EmRYsPgcvMAUOUjvA2nTjvA5g4I0ICDLKZoyJ0ELA QAtnpuXiDiUAWRqgbRriTjgE6AaxrlXgXAunHChA4A3rXAxOTvmt0u3v7GyL1wDPqilL3vtL IL5sIL6iOr7swvxr+RFwQQYv1RPCXP2xQraP4sFKsI3R2QHP7qRr8sCDBsLv/sVRdR/uwCtQ Cw7odQEAywFE/wGRMyGQYgYQZkFkfr8gqp1A6m9nTg0g9HiQOE6E0HWwxmjOgwYwSx4QUNUK MxXQWtYQXuvsuDVn8H8xgwcJzvGj+IBrmLnKZg8I0SVwltponn0yWgzm8HDoEITnuEdRayln HSmnEAwyVrsEWoAInm5yonhnknDwxJjk3MXGxiuyvCyoBDvoEH0otA2ysqMwgtjG4AzOqieI AAxIXnjw3NWQWQ4yFw5ycRHo4iaQ8w9yOt0SMvhOnySupnvRCxDj/xLL+xdwBxHSSiOxIuox Jg3xKxExLzGL0TRROO6o+k6mdSCoERRu+xTIyRUvBxWxcPEPJSbu5iTuOmxEENcJTylS7veS wqUofNoxSnlRToVu+TojvTpnCRVRWA5TEulmaO3TXzHO5wJsRIdRaRbOlEvCAg0KZW5kc3Ry ZWFtDQplbmRvYmoNCjEyIDAgb2JqDQozMDczDQplbmRvYmoNCjEwIDAgb2JqDQo8PA0KL1R5 cGUgL1BhZ2UNCi9QYXJlbnQgNSAwIFINCi9SZXNvdXJjZXMgPDwNCi9Gb250IDw8DQovRjAg NiAwIFIgDQovRjEgNyAwIFIgDQovRjIgMTMgMCBSIA0KL0YzIDE0IDAgUiANCj4+DQovUHJv Y1NldCAyIDAgUg0KPj4NCi9Db250ZW50cyAxMSAwIFINCj4+DQplbmRvYmoNCjE2IDAgb2Jq DQo8PA0KL0xlbmd0aCAxNyAwIFINCi9GaWx0ZXIgL0xaV0RlY29kZSANCj4+DQpzdHJlYW0N CoAQioDRyMBANByLhsOBAICoRAbBokIDkZxADReRoMMRgLhhDIcZgaLY6MBoNhrDSoYxBHRi NpRKjuIBQKiGbzcdDCYzoOhAQTYZhAKYcagaNRuLhmNpbKiIIJJHhmORjKpZJRmMarDpmKCQ ZTSZDKcjaYTka4babVayLZTSbJ9RCpRq0Mo9DINDqfE6rFYvUZMOBlVqbXJpQDMLq/YbHZbO QDqYTELrGaTGcznOBcczLcroM7sOaZeYfTYnfpHWBrKYdV48NRlTMMKLSUDQLp8K5OIIYNxk NxAMxwORpngaRYHfIpFgaMhrCRoNIPDBjoBdvpaLhpDDkZRBIoFBINwhdL6dEdNy7/Jd/hPZ Mppa/layGaDkaTmdDSYTdQ6KBobug6TSKewAcBswbWuyjgZhm+AUCOOQ3jsMo5vm+S2jCt64 v+grtLwpz0r65jABoraVsKKiuvq+78v2NwXQjCcKiAyrLszGAxjeNrjBiGSEtHEKJoM1DABk 3cFMAGAauk2a1NsFwQBWGyqwcHIZhgqsqJe4zkPQjb1Oa54XBywalw+EEfISpbsu2ijvJEOK LhqGCOulAIavKwc8hk6gYhc2E3hAK4QP6BrwzpOwQQCpIbtkh8vqa1DSKvB4Zy6gYoou8KC0 WGgZo9JtISHMKMqrHyVJEktRUq2a7OK/4YzzVECBAjLB1QkL0QUjilOjB7/LmBrqoVEC9Vsj U0wSKiRSMGDgQUlwaWfB4ijlCQ5BAm6xBAEYQB04wbITWkQ1NZVUtSu73BdZauoOGEHONI8U qejKN2XZqSwRVkUq6JwwjaMtwP+rNi3pZFT3xdMshzdbq4bJwpjynIwjwEFrWwEA0v6Kg5P4 Oadv0nApDKOI6wqOjjBbWVQKZlc/0dcojVOkqQWZhalwdaMHiIMozY2NORDdgdhJPdVa3tNO a3QwE6NZFCXVlE93CoNDvDpjw3ZAng0pxN+TZRjULDI/DujOsyxDIEA542MbvaC78NDYMu1D oN4QLKOgxjQEA4QkMg665rw3qEMOVaMj6oK1QFlwKkoawPhwb8i2eO4/kOujdkmwPzjT+iCN w3DLiwghYn/Q9GEAhR7cTtQHITTUAGDB0nPT3QeF1MTFAVFhlP8yhAuwbQHNDuu/Q6Btiu3E huGKE5ivVIyJEnHzZaM9BrR6ujDCwwjgOA2MsyW5yiKrObUO+rP6MoXDPKO4PxQo3jpvo3sw NIxbmEG7BAsQ6GNY2Z0/6XgagxBooApjzSkq0OurhP6gXjHgIGp0G5H12KiIg00GbTzXJqZs V0OjVgQBlDc2pwgIAwv7ay1toQIA3rZfTCR+RP3BH9DGfwEAYjvBwLM+d3J/yDMvOuo9erM2 lLqV0ko4btzZhQJ2GsMIZ2BHGiC4tPqITAFLYgigFDJAzFjhI25ohRnELGNK0lXriYkqrYc9 o+IUwyw1N4uxdjhwbLqiE9CM8Ro0s2XyR4360GoEeXhIIrrGIXkOdG/Rjb+4RFjYyz0OYYz7 hwbsHKMZ6IhKBWOYAhcTEVE0JuG1gJOZMxBR+uxm0RWErojYgoFBdgao9VmYNpARlcMKUpEc Gav0nI9ZbGaIq92mHsWo9eA0x5QgokQtlbZ3lvSZdauRY65lcs3QMutdp8VplMXk6+aqyZrx /BgvuUC/mARTYIn+T8t5WxrkIUhhxzpDHxCsWNtjXgnPzBAFMOr34Xv/DIyplhCnFMwiIwiI 8apsFYBszpqDPGfNAaFJmMrB40NLngksHFEIOoNog1QND8WNtkhu/97oIA2RPhcUIOc/w4UB O/ImEMO0JN2R0GwECFA5T5P7SV8VAnPSOO8wEzEUTvNWDCWJbLhI7R4cXJw0rTQYRbg6DJH6 D6at4QqyCKULlsyNq2cYHEC5bRYVWDmQUHSXqiK7HAOQdjLBlPqfyKU96euZb6WadL/w5JRC Sf2rcNzOUtqJTufFeg3B1DbDpbMOmNhnZVWV20QorydKwDejx2ZynVQfUCk7dKh1bqNV6pIZ alljWCXSVIOJwVTKxWVda8LZGztJV2pAIEdE5hIHR7rxmyBzbM2hukP1hMrtadKPNCZrUaob ISJbO4mxPqRKeg8qq0FSXEYSLrPowBujEcai8tyN3OnI9mzZLlHUhjfHGFsVqwJpT+pc/4La L3LZkzSJFz3Zg3rXZyQq1VryJCpIu0cj8BrZklJQNMloX3Wk240qC+mbKtmXKOUpPYqFQlTZ ePc72byvi48KWjtpby5lcYRXsva3HxmAwa8i56NgymVB1ac9ZmYJW0G9bk0VwrjrPOHEE5MK nZm2bRExBpv0YnEwqTy87pTLX+wGTLBZ235xlfxh7DkGxbXdYFHS173MaLETkNLPyx0EBqy2 68epWULj8zih85yaM9Z+G5oLmaLR3cTjGPsxVQvWkGs9AKwGqtXhW5hrx3XOB0C4CgOYXCiB oe5DkMsMrg3DDk2l/rJ39t3hSHNiZOmLSQkTo8t7c2z06bmG4M8IawVPcThG7JJoOWcBw08r uqQy6rt1pRjxPCx6SBBpRC0OoZBmDeHWEtQ0eqfuwrVEs5bZg42obOFIbQkhkdM1hy8Ndtum t2/8PAdNwv7gAG4MLQtzhQQkHAsYdA87nCKhQnO4aCbQivrSzBUgb63JLWrXRNAphpDPuoNm 5wpk6P0i4y+2wQROY8wGv3EJE6MZOfkJIRLjFGirQjLGf6Nkfqsv0mkTgxxQilhCK0q8J3a5 Ld2L53bwTqaLnyYSyLy37j+rK6Mgzf8/XdPvWRDN+YfzhoBeE8nr9LxxM2RW5cDne1NgpCuD MHSYtWsM2ALgcc5ozzxhadF+M1Kyg/Q9uicNuDk6JtXG2xOeDGGwOunKxYIYzuSRlgu8QvzU Xbr916pOOI8ifCxXSxSTkrJfjsmnF5uoVyK/kn5YYYt7hDDvLprS6VDdwuwN8SzUj3ihXUu8 Vy+mX1tYmV5wzExnjVBeN8BMZmet1b+P8Tchydc412RyDla62vPP3uyPTmyjOjKhxsrdgj58 RLLlJBnV+hSLRG34Wnd5mhZ/kONmBrDcG8O5/Sb283LtvNWbL8ZC6TRtnOdAUZ2opnq8XOMm c7oZOQk/htcJU0NCLRQ/r7CSCyLT6w7caRbuBvxCYxhtSRqFJyxrT/4EBzbjKRhCz7r778MA imrorwTCSLLgAjzf5B47oOamKEq3qFDZqmr7CF47zTLXq4gMjxrj5xjkK8xhbkj9zlDlTmzj y67DzwheC7aWCLy768I/68ZmT+zOIqLnzkojroLLw+Loi+q+7x65iPkG5Iy/y2bAI2bqDArq Tu7qjHTBbxbB7Dbo8ILyiiI2byyU0NLzL3SVzzqWDwD0LIL0bLJVTFQjrFhYDF71iPb1y/jG i/5aSZSQ7HT2rHw/6acPLN6cZhbIsKBYBEwwbJb4bpT40NrKSdLKqdj5jIZhY5z/RaSApYCf bHb8jcwIh7oOxuR8aAS46gpl0K8GzsSLLOb47OqibPCir+Zo8JT9byZZaj40T/o7wJoI7uLZ kWUAiSi1B/6FDtUViocEkEywr7Y/oEQIIMgMgES+IEQJpGccJHSUg/h9BoINEDkNTl6zpR6D oG0EUNwJAJ4J4KYIoEAM4NLeyFD7SET8bvTc6HSG4OqwqE7UINCgK3KE8EjZYORtxCwO8dcM YEEZcFJur/yOQ/ENKqMDwkoj8eLkwFEF5s7Ta4sjzkD9TySckHKWEHa6slS7DfsITmMIrmkI 7m8YT1sYjnpyEJ5dhycKQ2kKi48K0lbpElsUkLjpsLyZcMDA0izqoEEMzBqS7liB8kD4sShB 8N7DSIDDghMIDyLzgkzzxMkPDJj0jEMPpXzFo2kQL5kQickQxhz2UL8RbHiaD28RzIDJkUab J673wGh3z4K16YcPZhcTjw4mjKcHoBr5cwExQwA6sUw8pBpqY+IKoNz7z8A/sCKRLXjX0c4M RjbdavUhKGoOb86gz9MpULShy9KiTO7PInDPcnkQcnxXb6L3xeQhUxEd4hcy4GLr8zQFCfZ+ kg5uhw4HCBrNsLC/T+8HDn8xoFEmLlcmbwcd5NS7knCMMyAKgFUd6QMLoGbp7HUMLvaw8qkq zrMrMmi2Erj90r6TJLwgIA0KZW5kc3RyZWFtDQplbmRvYmoNCjE3IDAgb2JqDQozMDkzDQpl bmRvYmoNCjE1IDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQgNSAwIFINCi9SZXNv dXJjZXMgPDwNCi9Gb250IDw8DQovRjAgNiAwIFIgDQovRjEgNyAwIFIgDQovRjIgMTMgMCBS IA0KPj4NCi9Qcm9jU2V0IDIgMCBSDQo+Pg0KL0NvbnRlbnRzIDE2IDAgUg0KPj4NCmVuZG9i ag0KMTkgMCBvYmoNCjw8DQovTGVuZ3RoIDIwIDAgUg0KL0ZpbHRlciAvTFpXRGVjb2RlIA0K Pj4NCnN0cmVhbQ0KgBCKgNHIwEA0HIuGw4EAgKhEBsGiQgORnEANF5GgwxGAuGEMhxmBotjo wGg2GsNKhjEEdGI2lEqO4gFAqIZvNx0MJjOg6EBBNhmEAphxqBo1G4uGY2lsqIggkkeGY5GM qlklGYxqsOmYoJBlNJkMpyNphORrhtptVrItlNJsn1EKlGrQyj0Mg0Op8TqsVi9Rkw4GVWpt cmlAMwur9hsdls5AOphMQusZpMZzOc4FxzMtyugzuw5pl5h9Nid+kdYGsph1Xjw1GVMwwotJ QNAunwrk4ghg3GQ3EAzHA5GmeBpFgd8ikWBoyGsJGg0g8MGOgF2+louGkMORlEEigUEg3CF0 vp0R03Lv8l3+E9kymlr+VrIZoORpOZ0NJhN1DooGhu6DpNIp7ABwGzBta7KOBmGb4BQI45De Owyjm+b5LaMK3ri/6Cu0vCnPSvrmMAGitpWwoqK6+r7vy/Y3BdCMJwqIDKsuzMYDGN42uMGI ZIS0cQomgzUMAGTdwUwAYBq6TZrU2wXBAFYbKrBwchmGCqyol7jOQ9CNvU5rnhcHLBqXD4QR 8hKluy7aKO8kQ4ouGoYI66UAhq8rBzyGTqBiFzYTeEArhA/oGvDOk7BBAKkhu2SHy+prUNIq 8HuK/8vCii7woLRcxx888hzCjKq1AkKIqk90HrsjjjBlP9QQIECMsHUwqJFSiDqU6MHv8ucA IVEC9VmjU0wTW7Uo8GQYOBBSXBpZkHiKOUJDkECbrEEARhAHTjBshNYxDUljJUkUDPcF1jq6 g4ZMHV0B3FYtbXMksESbFDSK6JwwjaMtuv+rNgxSp9x3nZM62/dEfYTJwpjynIwjwEFp2qEA 0v6IKeDSnDjBaGIahmhSoK069H4II1SpKkFkMApcHWdB4iDKM2LjS/ScX/X6TrvgdiI3lVy4 PJmVtdNWV3WKg0O9jObv6O4wwsMj8O6M6zLEMgQDIOrvDoN4QDppQQDnh6dYkN6hP4n+NJxr Kw0KN46BBHQ3DMN6ya/rw4QlrW1jdjudo/kc/0DYbABqGIc4VJd1Jps4QbSnemikMo462/OL YwNw3DLiQghBuyf81zgQCFx8LDCOA4DYyzJDYMsoiqzmsDvpT+5ti0LDduAQDgN7MDSMXXbx rIyjoxuLs6/6DY9wdjwLesqYUG3AtnsDvDKN2scdtOmY2NwWBB2nsBB14zyj3Vrx2svs7ltI xO8OCzdlx/2fF224vxiw2973/g643lCQY0KunOMFQFRUCSuIaIilFZOHjB4DoEkIgLjjPLZI o5eLKWeKnSUcMwgKAoE7DWGEM6/oKuCXSyt55UmGIoBQ5MMxY3sQCZyUZwCwjSkZZ/BtZCuS XOMNoDhdK6W/g2Z48xksGU0tAg4ewG6zV8EeBgDOKBXWKOgCo5x/B/XrPkWo6BmQcwxn3Dg1 0OUNT0RIcIaUwBC1VGzJuG1fpOY0PLR/CmJTBisQfVYDFVysDBqyVouRU6uQaK7Xuus4xSY3 SCXksdeiylorOPKtCKpNIrrWWwd5bcaFvp6Z6wWSDB4FkdiAQdLCvijJHlDI9oMbZWMwNmvt fsaGAyNjzKMwBL5SnlKW0c+IVQ3Brd0Hc/sWSyMXDC02CTHWPshKZEiDCw2CxMZYVgGzL18M xZmzVpsaIbyth29Sa5r0TtFKyr1pJ3kdRyP41hi4Yw2B1au49sQcAyhjDSzQljxpkhumW96C TvEJB2MZPA/oYSHByP4HNyL3gQOTcqhV/Ac4ixHZJGuFZJklroI/R02YdZhzFi416Lp3Q5u9 eyWN+jWHrHdbqd1toc2qNWDKGSCjyoUTThyyiJcPJIp1g9LJFRNIQhjhHCWOsKKNQII8mqD8 MIZBuhpCeJCfUQstKRR4GdWzZyZIdFpzDX2wljYrGGMYaYyt2Q4r9j5dgcQ4ZPONldQQaFTo 8DZAKD511hn/QEnFA38zxnnPVi9ZHrxfWtA+LdiIvLVmcbAF1cYUVYWGSVLMb6igoLFGKMkZ qrQXZMsSDU5KgxuQUCiOMcye1WjvU2UTQY92pVYDKP8oJHK1lHIaRCvZFsCkcRuXR7JJxRBj JZaVin0rZk6t5cEgZcyvmsa6U9dyqrvnFIScoMF7WaX0vyEzAE/y4mpT5gyRjVsKBpelJwTm vTIDbMqZhTyyh0DG0prFCg7lvDIGNq1kZoVMedaSn9pmDsuu8TRmTNA3M2e9OCIzgbg4Frq0 I57Cllmss2Q5sM7X10InlPSm7n3NufWsG1ux3r9hsv61YhoXAUBBCYEzEy1wkBPCeFMIoXC5 PHoBfPGAc8eYmou4GNWA3DHCvUDGYAKG9BvnwHI/SFXcUzpqHKeoYg82OCaEd8Ac54tcbDSi lRYlrI6Drixt7ccGX5P65w/B+g3EWn9fHH9EG7WhebVkrC9zXJLK0g+MYZZlneoU5smedb5U Qvrfdi+dGw0pnzPsNOI34h0n8jDPUSby2lwrB1xNRCu1HqTeFX8Fs9uFgSj+qLM6p1VP/Aap wMDfxQz/FOS4KKwRZghWOLtZowIVrTWuM8BYDxtlKg+1b2LW06BbHey1PVS27VTbSX1t1w3l t1bIwkhwZq8Sdb+8lPbhXSklrZBdyKv3Kk2tpblzrcXRibDy6iva7ruP/KzCd516yxm3LO8E trx1ywJvyp4OJtTo4Qr0J4dW4uOvhouwIRELOgvdX7O1gA3TNP+x5I9k2RyHPNqrg+6F8k0D CHZDQbHWvJV/s+IRDKrwq4LNaoOCLU4Lm9g8404d982aEDic6CzhInaQ2EIIZGsYene5jELU s52OCHjfHIRWv4+41YJqLUwytVyxTdKNfcuvhahkXmVGckElSZn5BbiOjE0pFy14YYQ2BsDf f5409tEcY4lxsIj4H33+DqZxizcQ0NQfIHjw/g3jUubDynlfcqUk7O82fTdTZdnt1ETTiOd+ Jhzpzqendo5q1AYOR/UMLtSQk1MUbVCgO01P1ZamqR3aqetAbrJI0T6Pa4uSxXXljdf3KrRZ +tmxtZ2o3/ZvZcdLXEJ2iyfadstqwuVYpdX6r947au0rjbtvdwn/kZwSHX3WDrL5NJW4sVt2 BvuZu8/8n9s7S/MueSl1UGyqOavC8u5d5ruN/FKuAJajjJbvyLzLhqniqGFCpu3jaPOusinn 8u6DugwgyMtrDqFCbicotMAGRJpPSLzOgGWpssEgUOdMGpvuesIwDq6NzHFuhofv1j4nPQIL 5p7tJmaMRwMmMOlG5H1OmwKNCQLvEs4kLL9mwQeHHmNEKQfwONep3uzMBM+IWOEjsgYDRJtC uqXmZsUrHOmH2H8mpKaOuqbKcNNqePpMKQXvUQTPVqlPLvYksvZoXPaoZvcPXvotZquv0opq vLNtdqxLDvhqzthPjIzv9K3rJwWw1v/q7vUs/q9PUiuq+wbKBQJELLCMRKELHNgLFxBIuKyr FLIq4OztUjSrMQYkHrOthrQNnO0I8wRl6oFrVH1NmKltniErYQEPqIpo+DygatsLoPuI9Pvt vpEj4txRGODNaLimit1RAP2v3pPLnpWvpv/perqloP9N9F4v/LtruvNgUJaPcQDRrP6j2E2J KLjx1MNphA5g6nUm7PGsaqRJiA3pjAQQ3uXCjGPGQQPrRRYvTQSQrOTwTpuwUueD/ufRvRGo esMLfN8iFP+I2CSiTwYiPEyogK+x9gQRyKxqFMnsog6A8nwH4qGF+p/HwAykKCcsvg0gzqAA 2HwHQD8qAkXCWDGCctKKWH8ndA6G/ohDsOZwqKOSMLuLMjZx4R5MpMRstLHDuoBA0kKA5Ows OwgH2DuuWR6GurHR7KSGLCxSdwdFrQxOuOvGrvQvXPRyBMDNQQ3IRPWRcRYOSQ5xICaQ7Pby 5k/w9KtQ+w+PfosRQROviRDK1IzK2i6LJLKOfyBu1AcO2CXNvsmyOS4oSyPLwMqxNLDRQrEm KrGHMEoxCM8uOxFLKMjkhIpRVDZxWRDw0QQtPQXvlCWRao5RbkuiBiAgDQplbmRzdHJlYW0N CmVuZG9iag0KMjAgMCBvYmoNCjMwMDANCmVuZG9iag0KMTggMCBvYmoNCjw8DQovVHlwZSAv UGFnZQ0KL1BhcmVudCA1IDAgUg0KL1Jlc291cmNlcyA8PA0KL0ZvbnQgPDwNCi9GMCA2IDAg UiANCi9GMSA3IDAgUiANCi9GMiAxMyAwIFIgDQo+Pg0KL1Byb2NTZXQgMiAwIFINCj4+DQov Q29udGVudHMgMTkgMCBSDQo+Pg0KZW5kb2JqDQoyMiAwIG9iag0KPDwNCi9MZW5ndGggMjMg MCBSDQovRmlsdGVyIC9MWldEZWNvZGUgDQo+Pg0Kc3RyZWFtDQqAEIqA0cjAQDQci4bDgQCA qEQGwaJCA5GcQA0XkaDDEYC4YQyHGYGi2OjAaDYaw0qGMQR0YjaUSo7iAUCohm83HQwmM6Do QEE2GYQCmHGoGjUbi4ZjaWyoiCCSR4ZjkYyqWSUZjGqw6ZigkGU0mQynI2mE5GuG2m1Wsi2U 0myfUQqUatDKPQyDQ6nxOqxWL1GTDgZVam1yaUAzC6v2Gx2WzkA6mExC6xmkxnM5zgXHMy3K 6DO7DmmXmH02J36R1gaymHVePDUZUzDCi0lA0C6fCuTiCGDcZDcQDMcDkaZ4GkWB3yKRYGjI awkaDSDwwY6AXb6Wi4aQw5GUQSKBQSDcIXS+nRHTcu/yXf4T2TKaWv5Wshmg5Gk5nQ0mE3UO igaG7oOk0insAHAbMG1rso4GYZvgFAjjkN47DKOb5vktowreuL/oK7S8Kc9K+uYwAaK2lbCi orr6vu/L9jcF0IwnCogMqy7MxgMY3ja4wYhkhLRxCiaDNQwAZN3BTABgGrpNmtTbBcEAVhsq sHByGYYKrKiXuM5D0I29TmueFwcsGpcPhBHyEqW7Ltoo7yRDii4ahgjrpQCGrysHPIZOoGIX NhN4QCuED+ga8M6TsEEAqSG7ZIfL6mtQ0irweGsuoGKKLvCgtFzHHzzyHMKMqrUCQoiqT3Qe u0uP+GU/1BAgQIywdTCokVKIOpTowe/y5wAhUQL1WaNTTBNbtSjwZBg4EFJcGlmQeIo5QkOQ QJusQQBGEAdOMGyE1jENSWMlSRQM9wXWOrqDxNXyjSPFKnoyjdj3MksESbFDSK6JwwjaMtuv +rNg3jYlS3rZM6zLdE1XU+ImvwOY0jciwpDKNo3jozr/hxPNeVlIdABgwci2ffLXNjfN1jeO Ueho8sg2HIzzWc8sTUfdYmDeMYwjY42BoXgtRZKjyXpBfTyqXo91iJCoxvuOA6ZZTFIo7OmS OY0CEpNTwbOuwYaTypk/5JOGqzCGoY5eGqmBvtl0wHr4QR+66mO679DoHTobhopM2L0jAjVK kuj3sqQbQdZ0H6aM2JjS/ScYDX6Trvgt5zTwlyvRmtbXW4y7BtAcQsA4Qc3QGHSweKg0O87o 4jrCuNDIECd8g/vXDqNLuwsOg0DCOgQd672LYxjQX51ng2BBpo56eNOo5YEGJjGNg6rFCw3D KMcKjmsw8hBqb/ha7e5BarVAWPAqSu3Y7XK0hEHjCsXX9+72JjNliy9t2g3dn4R3X8N3eE7Q ngaScPSewxkEDPFqBpDK7MN4dQ6AuOMQZ8yf1HLicE5hyqp0lHDVUbMKBOw1hhDOwCCpUHzq BZkSVNRhAUMWDMWMMobntuSKMFQFRUD2A3Wa0hOoM4fldWmtUhwZQ8PAYm8F1gICxxGeY856 AcocANh1DwjzQXFGzJuG1f5OYqwWWgC5o68oNq2VwqlBQKFWA3c+rAwaslaLkVOrll4M1eJO OMUloMclixoYSsuH77loRDJpEV6K2DvLbiqt9PTlozsIXOzVhxtDomDc+6JYbl5AGAXxCFFR NF+r/iq0BYRpVxydPYn1hgNJWJOCmHknIYQ8AgkQtaJcXSyv9OM+YGoMyFQqgwo+Mzg4OrId I4iUBXXGOOdtFVyhH5IEbczB4kqdGToLSy0s+IQYFo7l27N3DsQQO+QsGZDQbIHvBDeCB/QY w0RMO8HOWROpahvKFANHUXj+BkYs6+cgcEJBkDrAWA8/ZezRIZBd9Do5rwgc4DeiEoQUP/DL AE7wZD8HdDOWYsQZEohVM47MO7rD+hlBcGdKMNYIFCDDN+fj/YFn8DdAoMVGQysaLIxOB8FD /wWfPBmTcZ5qzIJKR900W6KQjDHCWE8YZhUNha0VH8MIZQ0htCg/8V0jQ+dO6iQwKJbxHiS9 I/sA4nvRii1BqUVDjVcXu0dSsXJwQ1J7Cl8ZHYysGjosgrEMFWA4jfI+PytWER2V2yo+Me2C R+Xo5pIy0XOSFWktSRIb1syMW8uCOMGmD2QqKyhXp0UHSZmnX1wwMJP1KX4v6rSv5TSQs/HV hklV3ANmAuFYbIWrphdIaBhkv5KhVDcHMOocA4Msdk+BazVEjteOwkwjpojeMvTcnY7jZjwo NbICCX4OClPpbO0ROq37a3mNncQNdNQ7n9l1Qg/6Xm0trKZL9jzcTsN0gy3c8DeiDGwa82w8 8qai2pKW4lfTi6LzOgMG6aDXppWOg5NK2jnLbOfIVJo0pgG0qPNcsxK7qom3vplEul+JHZz/ dgfmBChYFHdR0GcNx+J1hie/APGBYEKLWn7PKADLGNq/fHeA7FDJX4bqOgeZZNKNBzo5R6nt eKgzEr4RyY9qakQwqZU615RqgJ/hZkiqlSUUQxovViG+UmyV7dIUh04M83GzrGFSJESqzxNr Statbz62ocV+DE2EZJTxmmpldhJCMPHZWY3+ijqzvYoCSU8/FZnqPWnXEutFllrMarLpjPGm pe6ALsDihcK30xYdQgh05opKvXilW2s08onaaBBq6tj4Vf5fbrZ7CbhWExawTXSL1dqoAtbp keYtqFUOosAeUHNg7dSoCNYZzViI8WKNpYyPsGrHzWWVZJpDatwRE1pIpbS3LN2E15KqY9ok nHROlabCW7LVLwtZKK10pU/7bqHbOoyyrgWT4DRQEFxLjXIuVOt6N6r2H9z3FPUMv5gvm1Pg TQ0ycEVzopM3Gcz81VSzEnWiZLAUZbhNl2K0OzAQvjXVc7tWdivn2RqjOEg9Fc1srEbOmnc7 nezy8tp2t4qW31FoK0+VsKb/JNxnRQNqw6O6A83oWkcWvTerR/WOmYjacztrLPPEdR6lzBqd 0nI9FA5omV3W2fHo6e59rTtcU6fa5qjULaUxuk2p2BxpFddYwV42PXuVNh41ZlLssvaFnah7 UwqiiO8eeCba0GsTbvSpBSt3HIfctmJF7oP/I7aOyd6VyOzbY6JKd5bc2VJ7e2waKSj5RbGP 2/rUnVRO+67iveDXHuSHK5ce5gMfSEaZkTWD1tF0SS7RhXeFhuvWG+9tt0vFZKS1y7iZDB9O O03FN1/G824BxdYhjWl0xlvGiSF3pF9k0CghIOBYw6B5apfNQBTDQNevwYO/TdrtX+OCBiKS zCIg4s7yYSwOhg44cewawecq3mwK1+jwYYJgwQXW/aDe/e98e+9gBAC4BQCCDceylqCCC4KI eiCSY0Da6pA7A/BCBACFBIfApcBAoFAu/ge+hGDktcp0BADuceDQxMoSwg7E5AfUI8BozgdO 1INYoo7i1g0mxgDexkxodmDEgkxceA4O96uWx6n0nAx6O6DYfqf8nagHBpAw/ixapqeAgYPu 4Ugk7my87qypAI18g+zI74/YhI5O5izWoczGqszO5ezSq25UNU5tEM5yei526660rU6C7Y6G R60C1I6PAeKiI4Tc3uBQ0dEkKUZi5CBuBi/U2dFEV7AtDPA0tdA5A9BAiQJ/BhBNBRBVFZBa CER6TKbkZAI8dQmyJcJeZwJpBgW8YLEuRM6YI6NiOqV6Z4P6pul6KWa8uooZAE1QWgfa0UBw ZGQe6s0sdm7c1m62zq6y0+iNCa7a57HAejHMZap/Dk3XEsriyWBQl02I8AIS5m8G2q8K5I8O Bi8Skg8Yr8MI8e2wtuj48mk4kkPY3AkI8yrE82sy88V+9A8U7u9WtC9KtGN29SqG8q709bDw BQ9g30sa3XIU4A+SZs+WPi924Q984UWs4Y+gP7BxB0LG4imAKYoY7s9FHgcPGOwUca47AWOM oVEq0MVyJcwuVcwzGIfXGUZqJNKg0aibJqX/B2xMWvC8pkxUnI0nDUTexixmpGBAxs1kxyDS x2f4f8ian2nCoSyIMHGm7IKxJSSWKyQfDBDEnY1lHXDSgVDYgcghDe4/J4yrJ85FDuRSK65M qe4/Go5Wqq5bEChrEG7oyMzZERKi5wzk1pEXHG7eihEeimz8LpEnIQj/MQOFFGdREoNm6hKs pyLG6o0nG46xG+5+65NBHTHYyE6LEpLnD81TGuJK1YQfL9Nw7hNGrbMLDmqI4vHjE1Ho7/Ha 2NHu8EkjH02YjW8OBlH+sK2U2s8gc8P/IO6PJOZHIYQWspM6iM3Ms08+s4tlIu3bIy3eb6tu Xg3nPQtW9ctalIZ+33NQ9okDKmkJKmaZOWejLAnUo6eU080nLcvhN84lJ0ynHfOhJ/HlAS48 P/KNAdKQtqV6wwdDKcNeYYSzCWK66hL9GZLApuBADrLJQgQtQkxKP6J2R0DkDIP4e3B5B9L6 wXKGgOiXBYiRLgfK1NOEOfAkSWQem8x7SMlqCFLW1lRtG8hs6uYmIsgHOQgTDWLNDbMGgmao ICANCmVuZHN0cmVhbQ0KZW5kb2JqDQoyMyAwIG9iag0KMzI1OA0KZW5kb2JqDQoyMSAwIG9i ag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDUgMCBSDQovUmVzb3VyY2VzIDw8DQovRm9u dCA8PA0KL0YwIDYgMCBSIA0KL0YxIDcgMCBSIA0KL0YyIDEzIDAgUiANCj4+DQovUHJvY1Nl dCAyIDAgUg0KPj4NCi9Db250ZW50cyAyMiAwIFINCj4+DQplbmRvYmoNCjI1IDAgb2JqDQo8 PA0KL0xlbmd0aCAyNiAwIFINCi9GaWx0ZXIgL0xaV0RlY29kZSANCj4+DQpzdHJlYW0NCoAQ ioDRyMBANByLhsOBAICoRAbBokIDkZxADReRoMMRgLhhDIcZgaLY6MBoNhrDSoYxBHRiNpRK juIBQKiGbzcdDCYzoOhAQTYZhAKYcagaNRuLhmNpbKiIIJJHhmORjKpZJRmMarDpmKCQZTSZ DKcjaYTka4babVayLZTSbJ9RCpRq0Mo9DINDqfE6rFYvUZMOBlVqbXJpQDMLq/YbHZbOQDqY TELrGaTGcznOBcczLcroM7sOaZeYfTYnfpHWBrKYdV48NRlTMMKLSUDQLp8K5OIIYNxkNxAM xwORpngaRYHfIpFgaMhrCRoNIPDBjoBdvpaLhpDDkZRBIoFBINwhdL6dEdNy7/Jd/hPZMppa /layGaDkaTmdDSYTdQ6KBobug6TSKewAcBswbWuyjgZhm+AUCOOQ3jsMo5vm+S2jCt64v+gr tLwpz0r65jABoraVsKKiuvq+78v2NwXQjCcKiAyrLszGAxjeNrjBiGSEtHEKJoM1DABk3cFM AGAauk2a1NsFwQBWGyqwcHIZhgqsqJe4zkPQjb1Oa54XBywalw+EEfISpbsu2ijvJEOKLhqG COulAIavKwc8hk6gYhc2E3hAK4QP6BrwzpOwQQCpIbtkh8vqa1DSKvB4bS6gYoou8KC0WGyO pBSEhzCjKqo4u6VJFJThvdB4oJ2NYwjOModOMgwWq1QEEtKwE1MIFApDKMyxjKNwx1pWyoVz PsQsAGakPcqVoNmIo5QkOSHDKPA6BANL+joNDvLHa4QCJCoxvuOA6DeOUOLmBoYtgFwcRAvQ QIyjaS1DVSShpB0FJKGzgNmKlw3Lc903WOQkqe/Fu2MNg6rEMmHhBcFxWtdmLW1blvYtg1x3 Y41cXlellT/QN7WdBFohg0Vdq6sQ53QNN1Y1j2LhBkNsZlmmbDlZNcT/R0Q1LNN9VS1KPIXV rZpuNo22Knugx+F1mXto0faSrFfrsGQZuMGU/61Al7iMwetJC9EFBopTowe/13qTpmy3xNNd 34jwZBhgcUJcGm+QfatyJusQQBGEFav+GyE7JoojVNvGlI/aOYPi6KGbDAfHo3yTAQRJu/Qe Jww6jxV3qyhV6tLrPPPY51ohiGnYSdc2Z4TjQwjgOAyrNCw6DuyzvY8MIQR1qD+DJkd4hmhW TuvR6n6zpG1ZXf/RNncwzW8NL9Jx06jJPVG6o1o9UbVSkF8s2mwoVzeVX6GtHtdvkGwfgrvd tn2FBB3XeO+Ys8FY7FWcvHLKG5ijyWPnegNApbwY2IhkW8RZnLPXcLYPwyM7Z1zBtCV0s1fo MQcuxSpCM2Ybg3rcDGWY+4ZWKBvDqHQFzQVcspdY5B8zlHqklI/CZ7CKiaKvDGrFWb4AGhUB UVAkqvkFLAWEsRYyyD/q3WWqFApqm+v0We30rrg2NBUY5ARkDGVsP6guu4ujJXVvSfKqeHQV G8kmeu/RgT92DRmZqwphi3ULQPgjC6MTGFyB0jCziMa13lxqefDaK5UmWMAI8y9B8Fo8s3W/ IdjUlGfw0aG9FsypnqRwcm0xgCD2ntRJzEZW7VWrw3ci1sqTXWrHFP+2JPSKY2Nock+ltoM2 3pOOM3ONbZnOtJSM4GSDspkRABRF5bDhTvOIiM4yW75JXw7fO35qzcAaJ0biUZI8uJiN3mMw GcMpTZukdMcZ1LdHHzXlEkZ0JrnZOhK6CAJwbwQBzDqGMNAIA4ISd4HIOgeYxMODgrBWRnT/ skeaUyDzRGsQ4jcvtyZS45opK69p7j3g3RGfE5R8i+ZsxxBtL6ElJ24BQoEWOgs+HSneC4Cg IIbg3LaJ+FwojGgkyEDbHumdNabh4BAEKnQIA3lCeLQEN9A6XqvDlTGQi2HgrgeJBoGyqIPS MiU3ohBhFnA1ROzFhElYMIWhQtw7qOgzhuPxIBHqPl5ziRKDeLKC3ZPXK7AqAqO4DsUj8xKC cC6AUtoIHkF73Qyhtj4oWFLxoWBpkBDCGTy65EMojJ56dJXJw9abMyIURIpLvioyhXcjUso/ V+sFYZ3YoyqefK21EW2W20WpGRbK25As6txHhn8aF4SKpHDmiznwcInnovSsZNH8AgpZU2l1 Bp1UMbkDiDldCSmrfm+oGT67G2BYnbtnbG7dSGkEyKhrX0/0QhraeroMGv2frI7esxxnAPjS FLeJsM6G33cpZmd9xJytLVCSwFEp2pWwBbKyK0n5yPoljE1rwNWwtjMG+SXTWzCS9l/Myb6A HVTibs2meJ7Jlz0cBFwmkzgQTQcO4k401HHUTnhHHAp2bvTdKq5rEUbXXNLnPD8rt04jTtmG 63Ad8K7t/xUbSfM+5+z/DKhQnNB0LUJiHQuRND3n0SldgKbAMKMXyJpRyt1HqQVZpE5zMEon 0kuu8+0Gz71eMBzE7FZ9ermMGgbAhh8ELBBugowYIuVFuXTsbWlnQeAyhjhjIAMgdTvLrW6x 2tFj0dBuDmYw7rFAxUGYvBq6x2Kt3uMAUieaCypmsmYE0I7Fp9BiO9Ussy3KksfYchQOWmyc VIKFli0T/c/V9eRn68Fg2c5TalonTFkbJwxv5aTLtmqKShjjZ6dFoKFRFk41bBqvbVRNtZFB Y8RokXvttNrMS05mYsjBeWS954y1lt/h9eJdmTXDorkk58Pp6ZjYJoTQ1MGo3fYgxKQF5gQY skJvCwjO5E74sxe2/KdbkUaJpJphW3cvRslBZy4yv8ESpaoQm2WDsSEia5hJqyl5a4Wx7hl9 GG23T2PjMHEO+sf3wxOgvFLgrcYumljFxuF8A8pcnjcjuOVA4851kl0GZAUZEnZevI9FOdm/ 6UeUGgN1Qz3yfPyf0+w01tDCGzK1ANt3UKNQ552AMaZtjjwDIWZVhUdDS9++2aur0kjfyp2O cZavuuwa8G9GSXGgz0Ci5ufbAcHgloKwgU+yhu7PwR4el1uLa0bo9imkdJz6e7syFRONNli0 6CDT8C9RXX1LCAjwNzzTJKoo8rurtYeq1n2qgmvtcIW11rw/ut9gZaintPo+1rOqs2yV20NC 8FcUfgR6JiKInWtWLuXbvJ6w5LWlk3d0hd428XJb5hVwN7rz773KUaS88OMjsd7ynZu0aIYd eDhP4+Gfi4fGTiL9SRa9yHji40i+Z/a9DaTuDL7fbMKUj6zkZqb47BbkzBrJDCDO7lg37Cqa px7mTNzmiXzmx9g/6YTHqYrMJvb7yZT8DoIN5wzoZxborHrGrpJyqbgGpBzpzNjpBz7IJSqd KmLIrq0GbB7EpvQrJ2Jfy5bJyfTsSf4/IMI/RFwliQyhDtbLbt5XLjrlD5R6zqTMx7rvKj7v a/CibvyizN6/TDzOTOi1A567bxL2aZjxqvyBzyDZBgwKYnUKQ/Qlj+zzTRbzqQjz7ST3L0Zh zRTTL05YjTwPL1rUj6TOojw7cAiSK+I2ZnL3DSjWR/r3jWwoSqz4Asb4T3z4pWbYRijYiv7P 6CMPA70KEPgyz0iyBayyR5UCUSK1AjkOBB6yjaIoy0p6D5LkCHj5j6z57bkXBP77iJbcL6zc a1z7Q/7c77q2rdiLq3Dd5jr8a8b8xdj9C4UHcLpgIGMFTfr+IEEPUKI/EPrzDgzQC8LhT/bh zZL/yhr9Jkz15e0AbqTjUBEYD5DuMBkIwGEBzA0CDBTBjo6XbCL6xrwHEDbGaG8DzwBtjmpu DnCd0M0IqOMFMJKZcbBwkFyaLGEGMDkgTnbrbpg6UHUjcHiczVMAomjqg/7I0Ikl76hK52L9 xJzsLKL3iqQsYEAOzs8QsKrK8K8e8HELKTsYbv6i6lT5rux7bM8MTNMMqG8M7DSZLwRd4uzO bwpJYHEmLrksDgKBkOrY0O7yRnKhKqJqKqcocorzKxzzbRjR0QYED0EQzSx4z0zTiQD1bUK/ rUaDsXK96sUOA8oj8EUTTWL3ct0T738ocUcMUUrtcVCwjx0VjQLQY70t0oKs8usWiFqF7aDj jajj8p5VbfzjAFEZC0cgEfUSS1M1r67ck2I44gYgIA0KZW5kc3RyZWFtDQplbmRvYmoNCjI2 IDAgb2JqDQozMDAzDQplbmRvYmoNCjI0IDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJl bnQgNSAwIFINCi9SZXNvdXJjZXMgPDwNCi9Gb250IDw8DQovRjAgNiAwIFIgDQovRjEgNyAw IFIgDQovRjIgMTMgMCBSIA0KPj4NCi9Qcm9jU2V0IDIgMCBSDQo+Pg0KL0NvbnRlbnRzIDI1 IDAgUg0KPj4NCmVuZG9iag0KMjkgMCBvYmoNCjw8DQovTGVuZ3RoIDMwIDAgUg0KL0ZpbHRl ciAvTFpXRGVjb2RlIA0KPj4NCnN0cmVhbQ0KgBCKgNHIwEA0HIuGw4EAgKhEBsGiQgORnEAN F5GgwxGAuGEMhxmBotjowGg2GsNKhjEEdGI2lEqO4gFAqIZvNx0MJjOg6EBBNhmEAphxqBo1 G4uGY2lsqIggkkeGY5GMqlklGYxqsOmYoJBlNJkMpyNphORrhtptVrItlNJsn1EKlGrQyj0M g0Op8TqsVi9Rkw4GVWptcmlAMwur9hsdls5AOphMQusZpMZzOc4FxzMtyugzuw5pl5h9Nid+ kdYGsph1Xjw1GVMwwotJQNAunwrk4ghg3GQ3EAzHA5GmeBpFgd8ikWBoyGsJGg0g8MGOgF2+ louGkMORlEEigUEg3CF0vp0R03Lv8l3+E9kymlr+VrIZoORpOZ0NJhN1DooGhu6DpNIp7ABw GzBta7KOBmGb4BQI45DeOwyjm+b5LaMK3ri/6Cu0vCnPSvrmMAGitpWwoqK6+r7vy/Y3BdCM JwqIDKsuzMYDGN42uMGIZIS0cQomgzUMAGTdwUwAYBq6TZrU2wXBAFYbKrBwchmGCqyol7jO Q9CNvU5rnhcHLBqXD4QR8hKluy7aKO8kQ4ouGoYI66UAhq8rBzyGTqBiFzYTeEArhA/oGvDO k7BBAKkhu2SHy+prUNIq8HhvLqBiii7woLRcqI9JtISHMKMqqji7pUkTABmpD3KlVrZiKOUJ DkhwyjwOgQDS/o6DQ7yx1oEAiQqMb7jgOg3jlDi5gaGLYBcHEQL0ECMo2kqQCpVSSpOHNXSW G9sK6KlfBAKCzDCNoyjosYQCddDvPxXQ3DGNg6rEMl5BBXrvVlYN11xfN9hBYFkuMFtnLtaK oK1QEEtKkssvdB6xDnYo02Pgr/oNg8/0dENSzTa9UtSjyFsIFCbjbdKch042Nx+F0+4+I1TY ckSsZOu0fuMGU/x9FKnoywefpC9EFBopTowe/1mKTk0CWojU05tkgYBkGDgQUlwaaxB9+2SE CbrEEARhBlr/hshOf6hkGiWzqtsNdhyuoO1emKNI+gaijeqMBBFQ0q2d3XTs9mKyhVpNLtu+ pKGIc27rTyqnyEVPjcw5XfddareNgyjOMI2YCNF42HitjWQOWDWcGaFYXjtH6DmmQ1RotVht B2tQfYYzV2NL9JxwqjJPVG2alU6P5HSkF7m+OeIVAcQ79vPIhiwVQ3FckdZU/l8V3el7V2i2 BDhc9080EA7jDCwyPw7vPjle4QDn7zvYEJojhAMg3wrQo31yjoNz8yxObDowY7Z1zBscYa9E koNWTPUUcuEmiyAQBiO8GEED5A5K5DeUJXq8WKMWYw6ljTrjruwaiqZkTtWIHDYkbNcwYw1h hDOGV4J6IFKBWmYBNTJwpBlDMWMMq84bMuhMSaBir2sooNVEsrrX1ahUVurlXa+lyMEVq6WE TqFll0Wewp4q1naNvRK2lbxSIJAoXGd5y7mV2ODXghZ7y9X4xVYFFBfUU3RK/VmxlZjB4vkM hyw4vZHmIu5NnCF08fijMbYYx5abbYVxkJLA9FDKEdsrJ7EYFrMGZSRdk25m5UmclKBgzxnx g3itDao8ppAM2lJOOM05xLsW+MjSM116jXInE0jw2I7zZYbtpT03pxcuJJtyaWDSBzdzmvQl BLeFjJXpxMQfHCG7h2nszZrMgjyznKGuOqc9pcbXzLsbAFBCQcCxh0DyCAMIcJ2FmQsHQO5l l4K8dGHN1SR1oMLaQeaHbjZLOBcqCiLUi4SR/T7P+Qc3HZvImmDApbuJLu7d678N0N3hvIjD RFbDN1XNubo84G00DSmASY3F5csEHxrBA9osobnurzjo+GKx3oNRuVq2AOE652zvXiG5/zAw 8BlDGHVda+AyB1fqG+nMGXyrqnRQsowLYDnYofQMqRVKRlaROV2n4b52QbnfPGeYcp6z3DHP mK0IFiUKk5I+FEkoxrakNC6RFB4YwzhrDeRyf4dUpcaj+H0QIhREsBCaT9hIlLeVZL0FEeIp MAjtFePsWa4sXi5M5hC0Jat7pBN4k0ZnIrfjTTCc1VFaxwV1HKmy9gy01qjHhf8VJ9R8Vo6q QNjFsSFTqiegxXZFWckZDiulEHj0harQUmjKZNWLk6QmxrsZutFZwgoFBdisyomLKtqbyTCS vljQeZ0tJjPGcYR5q8S5xS8a9ZlsIb2xzCONMRtdypW0jeYbQ4zrL81colExmKDwaA3Kqzwj sYGZzSkpNRwCKSuzYv+n+bcoLrtveUS6/szsASqiS1a02BAYrcQeEkNocA2BptmT8Mi+AzNg CaHUNh+sVK3O+hpep3beA2gRCaSDipQyTrxRR28L6D0YDc74NLwDjUdtCtW0dEwalTpGiZyj dAgx5LIrsMNGgQYrPzi2e8Hz+wYDbjTGznQ8P5s3COmIb8aL4qIrmC08MX4tgowKpKs4hv/J xbeA2PnkVbscSZJGBAYGirCTR7lUQRBBCIEQEWcXt00te/1/5Zj74tzkHQF1c3X3KyI1Uj84 cJE0r7DSIsJYFXVKhE2yCsKD2Uj1Ze3TYKE3GWVZ63tH7l2kIRRY12iwb0Wewd6KWXQ3Zfya G4JJT14q7fYGPL+LdcMDvlbePe2rdn/kAwmQTDLB3AkPNaROb3UaigXhjKeDwYXOJcwo2d0M /xdAam7YGpaVYlpHLB65NAkweXI5oNuXswLxdAd0MIZKhZnfyGkM0QTuk5ngTwNKFM4k5imC wEAdTObebAjpsYNEG6h3Am6rCf9YTHuxKSvZXbuAyu9gHIUrLxNHaTwG/x/70PFwzkU0Cj5x YIvisGYDZGzAgUSu1d5Pgk8cDls10L8oOz2LMnDHQdTu7dfvh6f2+mZoOlE1VH+xNUgoD2EV 9jqAuAy7hPzcBoGkcqOqmSQmsb2aLyv3w2edYbK2YBn3iodA2TvPztcOfUOpdUBAEfa76Z3x QD6wahu4+WW/hTu/oWR+Yk0yVkzJx/8oXpjFgPIpz73ILmZzwn+lqZr4R1nPTUFVf1HqTUt/ NTl9VQgwZkM3WOuhm6313Mro7cggfvoNVECsg3W85qavW6K+E7r9q1ZlgWY+aVXrTYtkejtg srbiqMWFhbqWTviz+DJo/RpVYZ6jjjWUHpgGYOq8+EhuDsG8NiFLaGBFbqkKlNnn0FfPkvgP hOtC3uuDOtwP1vMN2tDkTLhDstTtGgUA3gxvCNsLYNqtrv/rMF/NbvkvzLioRt2NyvNtgqJt 5Dyt6KDt7GWJnOxP2wVt4MDwKMOOjDZgjGwA0CzAyH0vhvikKuPDONclauSDvDYCEoDJBGYQ UuXMNOYPqOZClAZuasQJQOcLsLxudmlpZnEPTLwqJr2u+rJJfr6JgmzL7m1QtMhOgm4FXMOk 6MEj/m8tgL1t4pqrhiaMKD/ptMopQw9Hqt/o0l2qisUMbpNLZreHWCmPnK6shq7mqqKskCuv QqNKONCRBPTrmMNpipZQ7nnm9EStEpxKTlHsJqiuQLZuUI/qsoErkt3QbMitTxLtVPrNWLpN yO8kjAbvVmIAZw0L5PxtuvzNdoRobgqAVO9N4qWDSEVpMt7pOQoO8wpJRqKJSpYQsr0wuMNQ vOAQwOfQxOgQyN4LGr3o0w0mxr7i7KTxSisETKRkmQLphOmGrOnHCREFcuGOHRXqriqDtDpN DPoRaxKvPQqvQIgKMtnxNniMGvoxQKSHmxRx4GoKVAbv5r3m7DZqYKZNHn2DuieM9PfMuODt mswH0kLM6qjQBPdILNrRWgQIOqojOA5A7J8H5CdF1yaOCQGxYAcMfyCxnAZDQRcAUODOENny ALkNRxaN+IWtUAUNVq/wURfLCypofuKIhq2xePMsQvwLTyxNaxiwRvyr5RkrOketfyIyDxTR gmSgcLJKYNlyUNnCcNop4NMSbycq2ydtrtMtqDLQPxjttopreNxITQUvulvSNEHtswSv0A5S mvtQoxJvULmxoEHwYpNj/kvCAg0KZW5kc3RyZWFtDQplbmRvYmoNCjMwIDAgb2JqDQoyOTYy DQplbmRvYmoNCjI3IDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQgMjggMCBSDQov UmVzb3VyY2VzIDw8DQovRm9udCA8PA0KL0YwIDYgMCBSIA0KL0YxIDcgMCBSIA0KL0YyIDEz IDAgUiANCi9GMyAxNCAwIFIgDQo+Pg0KL1Byb2NTZXQgMiAwIFINCj4+DQovQ29udGVudHMg MjkgMCBSDQo+Pg0KZW5kb2JqDQozMiAwIG9iag0KPDwNCi9MZW5ndGggMzMgMCBSDQovRmls dGVyIC9MWldEZWNvZGUgDQo+Pg0Kc3RyZWFtDQqAEIqA0cjAQDQci4bDgQCAqEQGwaJCA5Gc QA0XkaDDEYC4YQyHGYGi2OjAaDYaw0qGMQR0YjaUSo7iAUCohm83HQwmM6DoQEE2GYQCmHGo GjUbi4ZjaWyoiCCSR4ZjkYyqWSUZjGqw6ZigkGU0mQynI2mE5GuG2m1Wsi2U0myfUQqUatDK PQyDQ6nxOqxWL1GTDgZVam1yaUAzC6v2Gx2WzkA6mExC6xmkxnM5zgXHMy3K6DO7DmmXmH02 J36R1gaymHVePDUZUzDCi0lA0C6fCuTiCGDcZDcQDMcDkaZ4GkWB3yKRYGjIawkaDSDwwY6A Xb6Wi4aQw5GUQSKBQSDcIXS+nRHTcu/yXf4T2TKaWv5Wshmg5Gk5nQ0mE3UOigaG7oOk0ins AHAbMG1rso4GYZvgFAjjkN47DKOb5vktowreuL/oK7S8Kc9K+uYwAaK2lbCiorr6vu/L9jcF 0IwnCogMqy7MxgMY3ja4wYhkhLRxCiaDNQwAZN3BTABgGrpNmtTbBcEAVhsqsHByGYYKrKiX uM5D0I29TmueFwcsGpcPhBHyEqW7Ltoo7yRDii4ahgjrpQCGrysHPIZOoGIXNhN4QCuED+ga 8M6TsEEAqSG7ZIfL6mtQ0irweHEuoGKKLvCgtFzHHzzyHMKMqrUCQoiqT3QeuwZhq4wZT/UE CBAjLB1MKiRUog6lOjB7/LnACFRAvVaI1NME1w1KPBkGDgQUlwaWbB4ijlCQ5BAm6xBAEYQB 04wbITWUQ1JY6VJFAz3BdZCuhBOkHVfAdx2NW9zpLBEmxQ0iuicMI2jLbz/qzYUUqfcl6WVL IaWdfLyhnhVfCmsY7Ms7wqjcMI7Q0NjJDYzr/haGIahmhSoK069H4KI1SpKkFksApcHWfB4i DKMw0jcNL9JxgFgJOu+CWKjeWXM9Fnz1X1XoVeNiMAhcTtcGIcBxE99jeOgQDqzgyOMFrtuu weQT/R15ZXn9TyU4dVNmKCdjWMIz3+4yDbDQFkQKks1MIFApZqsYyjcMe4v+KgVKg9gb4W10 6hnhau2payHDKPGr5uEA6DQ7yx8hmg5jG+44DoN45Z4o3CcMjyF7VFSaJuNt/Jz0j0BbH91Z blNS2RXNUwUFFWBtV9YsHWda3LU9dBpXl8XY4yk9T4d59zhFmcTBdo8amnH9FbA321bnY3Bo /n9xol0aNdb4zo6V4aAjKN+jpsj9Vfd+8FYGBedsni5ckoYOJdKanlHxdaWUNwZAQN8cCGlC kBgzISDa1hi4dXLuiDSHoMsBm/n6DoHlrjIWRlMbo2NYjBmhtnKwDZmK+WZs1ZuzkNLOzjM+ I++xecJVkq6Jc+c2jSQbNLNK01qb/2pNUJoE5qzWGtNca8diELKFitlhnCYjxHwcvyJo2wMb bm4OxbmyZQLTG8I/b03wMzfnAP1dK4VIziF0uLeuCh7K1wqOScof1y7mVqvac454NLoHRRcZ Kn9Pq8mhNmf2R4rUVgUQDgzIB2ZCYRGlYM9ErDelWA3eA+FeStpKGEeQw6AMOz/vNWHJJlT+ l6rLNYwwGINJVuOjytdbJ3nvLtSWCBfi/ifBUDkfwOZO2dH9b4HEOqFWrrwSCsRIagAYGDSK VgGkKVKmzgGfxrZ/0vFLeQQwGqBwXTcZG2NOx3E4KHIGiYHCgCmTdeQeYvSkUiIkPYDiaT1Z 6K+gQWCBYIAxM1dEx5YCXgaytnUu1qbdTsnYdo2M7p35zANK1OmbgN5xnnZetJozIaMOrBQG EhrEQ5MTcCfU/jcIDhlDgGwPIIA0BhQtP1v6b4EwLeBJ94SQjTTMmdPKKa+GoPxNm3w/JZmr 1CDgTgzimAGoNZGqApFTTBnDI8gNNFDTwTnBkXY8xSKKzvVEpN/8OiGrfXVD5lKDmDmAK009 BZWYiAoD2EUMjOXRBcqyDJCwbmrRoOOQOgbyAazrBsUkHFVDsHVYHVah9EZvrtsDQWd6Rp3S sRMo9FYdVqwZctHQn01YC0npnBefk/qG1CJ0HKoqFajhuM4H1rifbGt0i/KaKDLZUgwZhIpm jNmcTBdjDKUrKZCxRkODBKlYTRMQs0GKlcdwQBNCOC+6AQwQB3DQZYNFLKXAgM4TkEFHqQUi DLSQN1JjuzEmM5YN93z+3TukEe9k11gNdBsz+2TdnTkmOxRlZsOju2hQtR4OkvbWTAhef288 xT8nfgc5alrV73XQtGGaf4IGc3aQtf+fVornI6syHO1dc7ytykDQiMFUzqxtBvKG8LFLyXmp RSpKIVHMXfJ5gdCzNwxhsDqWKAzlbnYDl9gYnF36G16auGMsx97RBvgkC7EkTX8kckNbeKki osRar5F1P5JkQsvXBGNvp3Yz2/vrDN59w7bMIZE9QlwN3GXKO8ZzG+RWTAyiVmchmUoRynyp cS25v83RTzibOOLkXJ4WjtjVzUekKx8j86PKOd3bX5dTRlqSD5GOwV+UZN2aU0w2tulinyC3 0oPCfHda6r08q9Vm02RNGUTVvX8Zht6FcGI7wcd7CN8D8YWDPXo7sBrma7u438sS1w3lCudi 2kdLbynemHgoOjXM4HaOlI/E1tJUKotxIpVilz/qwk1n2TjRHjvJaRKNgeoK0nso21B6y05Y vbe6t1b64ab59fHFK4hrqxUDIM+vdz717VAhUbOXNfH73Bift2tRWX/oNreCAJNrA6hmZsGM NNmjumZsw4EOcHWRMkz5tzP+a8wT1X0TS3cLbfQxz1DTNW6Kw7rWAXaHrQDAWBUe1Al9liaY 0O8jp101guAoDmFwogd7tndDUGUnlogyTFvUCBjcWQQbLBB0YNuReP5ODlyLRWxroXvCHEqd MTGTSRdvqHKrCMrsybW23W8jovX4rVGJ3kZIzOB7xILSrLykRtVbG/Q8c9E5A0ZvWPbn3Quj 07RA2E3+HPt7hoBhDCuWF3zgg/ogINGrXDpHTstzvRggLE53yD2sdY89XsbsPIaAFGZB5XTN 98vklIR51BjLSu9ZDWzci3jNeXwmtd8EFRzMBpDEx3G0wU33oPzaLYtzroaTbFE6EncYgSK0 2T3KLtJB7827JV3irAcyZXFub88nt1JOeZu2QnEN4aDlbRuWDkJZrb3wP+fA/a5Q4MkM4AV8 oGMG4I/q3edQ4Qmmo44Wdi4aho36uKSy5+OyI+smXYCaguP2BACODC9K6cpWDqDcDKmIj6Dg w4vWLE9KJ48mBiByUamSNKmWTop2PWdqZbAeK6DkOMTyy8Vmq+p4cWb1BQ2oguqVBumaTCOi T+TYYcTyTYm2TSXUUEVyPSNQr+oKlA8soSMGoWKYsUPCsYIYqYZIq8b0CKQoJyteokxKtm7e 5SfIhOnqBQ5et6wOzMZ+3c1EaKlYrEh4rMvym6rYhyPaNm9Cwk1/BMY4O8dC9UDLBeauucwS mMtEDLDaau6rEgvW+E62KE9m7GQq7Ua/Divw+680bQiq7oo4yy7u+022bukQ74RQb2zGb+8A OMdMjW0Gjc3ocg8Ujq2M9S8ej68idjF6XtB4RSRWR2de/EP+bm/I0qkm3Qd3FuLsWi/Y32lM 3OeM/glA5wKMlI5o/sWW3ieq/0ew3q/6e83y3LAHDrAKOy4CxTAUz6fdHouNAdGciKfpAkT+ fw/NAYSyQC4nIQSdA6rmo9BDBGDDBLBPBSDhBWgNEibhBOl69K+nCSvk9sR9CqZAnaicSMKo kUCmDS2CDCDY5GY+tgz27yynD+5Wb1DyhchgP+uBHPDpHCozEE3GaU54XsTY1ksG9AxrEYQt Ec+fE82Os/EtCREwgMDnJUYuDY9U6tEjFA65FG5FFM7Y+3Jm+8f4bTFcK7Fgi3FlDkvyby77 FyzLFk/Kh+cPF+tw8Q3rGG9O8ac20e9a0lGnFQ92dRGa5akXGgka/GITLZGueNGyJYd6O0Bj G6hpHAhvHEV6/k3ZIIlNH238Sy98VghS/2e0/7CAvq0y1eJc3/HtLmK7HgP+R8rLApHRNYI7 HufU3HEI8xIMXukVAiONAmfFNqf7FaYYipONA5A9IdBEDLBI66P4yRKfIuxqxA6kDSZtCUY/ JCtisQTKSEkQ1i4So5OiycjPGiyhJfDg91ILJpDtJshZD1JyZ65nD87ihwaPM05zKFNUNfAx NWqzKQ+OwtKWYvKa6uu7OoO9Eu+qgNPLBMcDGjKzKdK5FEQq7FK+Y+iWbA7a+4z9PcinLNPH LQ7tLVMDPZLpFrONMg78zJF2cGjVLqjbLvGCe1L0+M9E8dL9GQj+qUICDQplbmRzdHJlYW0N CmVuZG9iag0KMzMgMCBvYmoNCjMxOTkNCmVuZG9iag0KMzEgMCBvYmoNCjw8DQovVHlwZSAv UGFnZQ0KL1BhcmVudCAyOCAwIFINCi9SZXNvdXJjZXMgPDwNCi9Gb250IDw8DQovRjAgNiAw IFIgDQovRjEgNyAwIFIgDQovRjIgMTMgMCBSIA0KL0YzIDE0IDAgUiANCj4+DQovUHJvY1Nl dCAyIDAgUg0KPj4NCi9Db250ZW50cyAzMiAwIFINCj4+DQplbmRvYmoNCjM1IDAgb2JqDQo8 PA0KL0xlbmd0aCAzNiAwIFINCi9GaWx0ZXIgL0xaV0RlY29kZSANCj4+DQpzdHJlYW0NCoAQ ioDRyMBANByLhsOBAICoRAbBokIDkZxADReRoMMRgLhhDIcZgaLY6MBoNhrDSoYxBHRiNpRK juIBQKiGbzcdDCYzoOhAQTYZhAKYcagaNRuLhmNpbKiIIJJHhmORjKpZJRmMarDpmKCQZTSZ DKcjaYTka4babVayLZTSbJ9RCpRq0Mo9DINDqfE6rFYvUZMOBlVqbXJpQDMLq/YbHZbOQDqY TELrGaTGcznOBcczLcroM7sOaZeYfTYnfpHWBrKYdV48NRlTMMKLSUDQLp8K5OIIYNxkNxAM xwORpngaRYHfIpFgaMhrCRoNIPDBjoBdvpaLhpDDkZRBIoFBINwhdL6dEdNy7/Jd/hPZMppa /layGaDkaTmdDSYTdQ6KBobug6TSKewAcBswbWuyjgZhm+AUCOOQ3jsMo5vm+S2jCt64v+gr tLwpz0r65jABoraVsKKiuvq+78v2NwXQjCcKiAyrLszGAxjeNrjBiGSEtHEKJoM1DABk3cFM AGAauk2a1NsFwQBWGyqwcHIZhgqsqJe4zkPQjb1Oa54XBywalw+EEfISpbsu2ijvJEOKLhqG COulAIavKwc8hk6gYhc2E3hAK4QP6BrwzpOwQQCpIbtkh8vqa1DSKvB4cy6gYoou8KC0WGyO pBSEhzCjKqo4u6VJEwCFvdB6bjaNoypyHTjIMFsfhdPsQ1LNMEiokSsMIFC7BoGTjBlP8fRS p6MsHZSQvRBQaKU6MHv8ucAIVEC9BAjKN19VT2Bg4EFJcGlxweIo5QkOQQJusQQBGEFaP+Gy E2VAluiNU1wNTVFy1zawahilNjwHXaNV7VN/BhBEmxQ0iuicMNY3pbCs21Zd9X5hbAOrE7XO qrNrCqNw5jqOA4DeOQ6DKMlrqMG4Zu1g9uSHQAYMHSaPBiGlyYg8slwc2Ym5c/aHDyODOv/L ysqSk1FhnabzSpMjBzs7k4UOgYZhuHEyKZmU/0CvWGQO91c4baz8u7ilMAbruvtFRdcWVruM z/nWtVG1GB2mGuwz6hUBuuwdcUdQTwIHTobhihPEbLXlTo/jqsBtoeIQeIgyjMNI3DS/ScYs oyT1RfNvTSktQ2BtFnxU+Nj8HjTAYHzGQ5zn6uioNDvbYMuKBBzwxjYOqxZfzwQDp3gQR1WD +ePCw3DeOgQZPlOV5bl4xDz5PliaI4We6sfOZW73lO95qyjcMjjBa7fCqgrVAV9ArVBz1rV/ u2b8BAMj8HdDOWZ4ytX4p/cgaVyTqnKkeI+/pzJswoE7DWGEM4ZXRnoBa/JshpWPI/WEFJzj 4w3BjgtASDLeVQv1KkUhtAMAZwsNmupdhDgyh4eo8h84ICxwzc2HMMZ9w4B0ZWhxbDBC7A4W 3AhhLk3VsMBoauFrXlfO6eW75igSSnv8eE8R4zwT+w5h2yt5MNYbxfeXGFdpYofRAiEHJ9sR gXRIgKddR6zF9upX+r9hirFyquR2rFWcJlcK6W45JfqwUFLDO0DNY6yWrsIWdIcwi02pMPK6 zBbKrHTxLX6kZdDAGeyfdeCiGUYl3neXlBdeyemNSGgW5RgEUz4sDOAwaVsnJXsOVabNibFT jMYk0whji0EjA3NY0BnsxmSMmZQypljLgQRic8HYMIbCwggDaG8sUbwaszKZCeOkwo8Swj0Y ApbtkUldc251z7oQ3QXdK5STZG4FLQUoguWRtHYg2ZrBwkqTGfshBkaBB7u3eh0baG2bE2jv TUeId5/j0nqPWmc9k78YnlBhonQh34bUo0GO6GZ8r4nmR/eem8NlGpoRCfa+87E4INwqhdC1 zBXaMvUDgWZigZWWrtoi9OHQeAyhjDq9kF0JoNP0Y3OOJqSjhy7lHBEMcE4KwXCoCoqBJU1Q fhCd2EcJT/q2flISf0K6AnZhdDCUcpV2hUjJF6kkaAQQ9h+GmIMQ5MRwjlPOpkrztqhNcR9g lBYq0ciuU+k8VqFTZXhQ4OtEELRbeLNCHEZ110YjJNyI5DKYVKnNOSwIN5yFdsqd6uUaq613 jdWGOcB47KmnrOUksfIHyjVfIAnsgiE1ktewqexUlhLEOKf9ZErJNyRYXPeSi1UnHGKTMGQs uJiLirOuaURXa2LuoYvFeZxpVr4nE65cMeTXT5BAwMhktq+Xij2keqDEqdwXmBEm3t7EjJul AdFUMlwioUJyCAMQdQzBmLGd8OobA2Tcm9a2OtS4mSvnPe8mk63POgDS6I408b6L6npHl1ko LzT7n7TKfij2Qg4SRKMJL6zLUqQtTeuN/nqYBwHgW0oIHvvBQsGbA4bKjn/fc1+l78rXYOtj eNOtT4+wQglBSsC2KxNjs9VqD0iYQYEq9CSq1WJi3VgY11dNl621vxvXKukbIh1IhQiFVdgE FxyNnbdWRPZMJuvXkdhkL83Gqv2TQKec64BhUK9MNIZnuPpefS2ziuKY4OkPcDJco1iA1kbc aSFvo9XKWpJZ2B/7n4bdRfa6jrVzu5JpdmU93JVL3kfdGYdsryHZvMwN+96mELflze7SN8Jf H/vnLfV+SNdTIuZKMEAT6izRKEHOnMJHkhverG07z/gzugmwGEOGCiFYMvDniczl8JAowpO3 C878Mg2dNrevs9nW4huI7JfObWQZvBwidiVQA6mcfZkClxg5wZFgTh5hkDdw1Sqpk8o2UX55 sypA4lgKMrwiy0caq9WSPG/y8nXMEMcxQ0htXCMHHcz12jblvizDc9x+VhnOC6tpBwp0dcnS CKJFEn0reC6NyN2LS02ta5zGb1yd1Hfm6+p+O6plTd7VmwNMZIz2wFJxsCDa2ujri6ZHpda7 JpL3hDcE/3QiVsFaMyN3MX0szY0zOGdIkPYDiY7ITtzHku0V/2ggj0qDuGF7gZA3oV0G9QNA YUKAg0E29I+6DsQvUUS9r+dk0HdO+1sBqJk+HBZ9OFsqRt5rm3sTTam1iy7ZaYQPyjAfFHaO m2BNrWfInhJO1MpjUlGx1UikQ5k9yXdlKMzPnBpWbp07Wevi8/NwhEDTtUOjbyTlJV01JPKb Ej+qby4n2qYW/KA9idGOJeH4OHKZ5BxQDStNfIYg1meKDz+/ZymFJTA4Wko86CgJu2AQB1fW 5xz1lIzHee+2/8aOI4JjBapkRqxNJgL8D6pvpnr7EAL6Yjo7A6pjMBBTg8YGQuyghyKO7B7q 6FzcDrTcT/DcjDA/7DSW7DqcjJBnzjJLZaygx/r470D+gNynZ44/rQTRB9bHTv5/sEL/Skh7 5KKk6HMHB6Dv6lrdByizrhgjxnzzZB6GqoaoplzH7KDbjVzdbWDJLhwmjgzJzlqObRqDsLbi CrpWTiY/7irLqFqFzUyUjjqtzj7MrkRCq1LkrijLi2blLOKP7li3RXLmCVy36maRJYgG7m7V qJTnTTKSbnq5rTzoDdTUTi6UTuDosNyGbpC7perpaTbsRAxtDWZZCTC9zoLXJh5SqXi+KX7r 7UEDToRni0BBZLDPo2itwshzyjTcsHQETP4OQOwyw7w+o/iCpzwM4ETbSb7IjBrgMFDPMDy2 qdUELC0EZbEErO7gT3CVkRxbAuz4jeMPLzY8qJD+IJzfDfTRR+Df8ZcDTbwkrgkD8LqqrNTh ZbkMSrjLEMzrrhS3jk7jENbjatcN7Mj/aHUOaNbkjNK1kJUesPLcLOSQMhTRipUQLTLmbh5Y gHEQ6W8RTD5FC5bTifUR7sCOzq0LIGUShBbUrMMTC7bpMTbs7sLpps0UBgQ2MUbEbDkmRVbY cVCUbri+UVjpi9irUQaZAGAHMNoEDFZk7AYywNLQAMR54O4sJ5UZEMEicdjgTb6dBiLCcaSd yeEJEVsE6pqf5xrUisiS8FzHLvJCz+wyQNh8zaEKCohlrwikp50HIMSoYMLfI7wN4oRz0phz oMcp6/8qJ9cqYMh5Twh6h88I5VEhaspJccIGMs42YNyngO5lYtBzynoMwncv5dqMgscGbBB7 iIUH4I8KjhMK0mMDcLMd8aELjJseUhSpMJZLLKrmjiLLLrsNI9gG7jMNklaMUOCMquMg0Osh JbE4DrEPS20PkiBbBLwgIA0KZW5kc3RyZWFtDQplbmRvYmoNCjM2IDAgb2JqDQozMDQyDQpl bmRvYmoNCjM0IDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQgMjggMCBSDQovUmVz b3VyY2VzIDw8DQovRm9udCA8PA0KL0YwIDYgMCBSIA0KL0YxIDcgMCBSIA0KL0YyIDEzIDAg UiANCj4+DQovUHJvY1NldCAyIDAgUg0KPj4NCi9Db250ZW50cyAzNSAwIFINCj4+DQplbmRv YmoNCjM4IDAgb2JqDQo8PA0KL0xlbmd0aCAzOSAwIFINCi9GaWx0ZXIgL0xaV0RlY29kZSAN Cj4+DQpzdHJlYW0NCoAQioDRyMBANByLhsOBAICoRAbBokIDkZxADReRoMMRgLhhDIcZgaLY 6MBoNhrDSoYxBHRiNpRKjuIBQKiGbzcdDCYzoOhAQTYZhAKYcagaNRuLhmNpbKiIIJJHhmOR jKpZJRmMarDpmKCQZTSZDKcjaYTka4babVayLZTSbJ9RCpRq0Mo9DINDqfE6rFYvUZMOBlVq bXJpQDMLq/YbHZbOQDqYTELrGaTGcznOBcczLcroM7sOaZeYfTYnfpHWBrKYdV48NRlTMMKL SUDQLp8K5OIIYNxkNxAMxwORpngaRYHfIpFgaMhrCRoNIPDBjoBdvpaLhpDDkZRBIoFBINwh dL6dEdNy7/Jd/hPZMppa/layGaDkaTmdDSYTdQ6KBobug6TSKewAcBswbWuyjgZhm+AUCOOQ 3jsMo5vm+S2jCt64v+grtLwpz0r65jABoraVsKKiuvq+78v2NwXQjCcKiAyrLszGAxjeNrjB iGSEtHEKJoM1DABk3cFMAGAauk2a1NsFwQBWGyqwcHIZhgqsqJe4zkPQjb1Oa54XBywalw+E EfISpbsu2ijvJEOKLoQGqlKZAM6x9NKOtBNIYhc2E3hAK4QP6BrwzpOwQQCpIbtkh8vqa1DS KvB6OS6gYoou8KC0XMc9L1SMiOYjKq1AKiRKw90HrshDjBlP89QIECMsHU9UsIGilOjB7/Ln ACFRAvVaI1NME1Q1KPBkGDgQUlwaWZB4ijlCQ5BAm6xBAEYQB04wbITWUQ1LYyVJFAz3BdY6 uhA2Ac18o0jxSp6Mo3Y9zJLBEmxQ0iuicMI2jLbr/qzYN5WJU17WSGFlwdZzy2hhsVPiJKcr GNwwjYEA0LMMg7rNOENDYOrux6GddBxYTSyHQGFzCkrsYcwNejS/omiPTAGhmG4cTQG4ahs6 8zaA0U03TQVcNO5gahjXWf09oF4o67Efuupjuu/Q6B06G4aKTNlQ3Gji73LhSl4jSrZiIMoz ZoNL9JxgVfpPsdZ3pPexpC9GHVPddXoVAcQsA1bWX28oYtXB4qDQ70dDaso3DIEEdDqNnIjc N46BAMTvDKPAyjGOo6DLyIyDq7w6DfjWOY9q4zZDkbvZoEA6cWEGbOMFrt6CqCtarcQjVMkq QWRJTh1W2YoJ2NYwjPgLjIMFve0DYbATUwgUCltaxjKNwx+c/4qBUqD2BvZvChgGGdWlag32 sKnO8z2Xac59lrbUOYxvuOHUDluKjPhfGR4ha6AYsoQeTdxz3CervAam5WZVUwJFJKDRY5rk lplcSGg/AICxrVckG9bMG3UOaO880NxYwwuicij0GidYMKzMADZAMBAcQzNmGkoT8zvuvauH NtxkW3n9g25cOiPQYlJBw4BYalEFrqPi34G0SjSwxem4WAsVSusYO6GEMgeYPoUO65EMUXgw s4OqQxb7PIDAzSY7sjrRHWqiTC0tppTI0t/Oydh6Rg44qcIMQshMVSIQQTSmFwQNGzoLa4xE robX2neDmHBz8ODLQcfqcYHCf0gxLI8DE4kBH0KPK6CwEAczjLgMHDBfEiSXJUicCgOoYw0A gDChYEUdCoO2CO5I/kRJSvccjJGSbbHRy0Dc5cOr3QysAJyCIED7QQB3Y26KMEllqs4U6Qtr xTFoM8aJG9qycI5GojooCO0NTyypd3Hto7WTxAghk8OQZTURnrWUy1va0JXwbDCHAOCEp/n7 dEC6bEf2fAuiTPAu0BpwTtSHHNpk5p4UHNHOtP6gY+taj+7pmCkGwsJVUs5VjLFXqxlS79W1 IFcq7X030/5SYBt1WKrdhSy3zGuaYtE2a04PLYO8tt/wDVvzpYNR9si52HSvXYliBjUXfr1q OvheNIjZr+YBUFglMXfsIqisqT0BETLuSc+8NocH2lmi8E4ModA7vtLQ64t7sHcOHBmQp3if 1HVbbuR+rr6QbSsQe2ptgbm3BpbgcZudfKZEbeE2SJhLqlRQikgUkpsJWEeByDhwhXXFOMR2 49yLk3KqFcxCSDjnnQQqBA6V07qZ/hvDEGyZYIH5O1DmyNCUyQyM0ItCetlbko2ddxRwwb0a LrHspAJojezhyiJpa+2Ns4No6DdD4sUYXZupc3M8oSPQZV1oTKqTty3zyeucCgOYaH2uZdEW S1bI4U2GRhXO79CDpXGd8sNsNjW8vFrEvtB7yQxvLebUF6E7HqElesgp7D2juzKqDABIz5V0 PofVTt+pDn4W0P7DqDs0H7v5DS/t9uEXxQxeG2hiQKIETMJ688qDVAZTyYOuRvNIUUAoLs0u ktRKZUpsdStk1LYn0vYLYvGzxD2U6istB8xXaeTQp8tpbi3pUVFeBkle7eHC1KBqVmptk1iV Qv7VJfWKl+r/e+r+rLKV55Zpo9UHFl4zyMPiFAxp/IFAgrVb8s8O64skP+9HL9dr8V5v1nC/ mSipV/ePiuwTbYg1BsTm7Mde3hq4b3ZE/5doosGcFd/CtmbNk0s7B9xx/LQhvco5a0t23Ouf dDMW1l2QQXQtkG3Djs7bW41Y5C3iha11tLPcFxdw2eHYvxIKAMF8zyKk+bPXF0kLXUus9tyM I7thvKEGwnBFr266dKHK+JmsYbLuRjVsVfMykeI/f/NBNMBYEzW//E+CkfvXeyGZ7eEDjYSf JTc7OFsnk0yi+7DdtX6QexC/p/mJtmwDqpivFsCsDYxITjOvVNMcEsx0oAGWPVw6JyBjfISv EnHGphpZu2ccl8CWfkzKGGcp1Aytj7jbCakZdV6DWTOYcsZk0YDBfOj801XONm3LFXN2vp5g eUpCvQiBvQrny0oRQ8H4iLoOumhne6INLfvLmW6/WAbS2vSV8tKNAsVU/TGQdNq9slqAlx1X CGuu/GxB4TrShVM4GTZDu9DqPze8HsbCt39G3k8p5m9T0bocDvjeBNN979e9xDCfT+CPrg8+ 8PD8cOu1w+/ZCuIsSP93/veAWKUUors/xZnBAQ0KZW5kc3RyZWFtDQplbmRvYmoNCjM5IDAg b2JqDQoyMjI5DQplbmRvYmoNCjM3IDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQg MjggMCBSDQovUmVzb3VyY2VzIDw8DQovRm9udCA8PA0KL0YwIDYgMCBSIA0KL0YxIDcgMCBS IA0KL0YyIDEzIDAgUiANCj4+DQovUHJvY1NldCAyIDAgUg0KPj4NCi9Db250ZW50cyAzOCAw IFINCj4+DQplbmRvYmoNCjQxIDAgb2JqDQo8PA0KL0xlbmd0aCA0MiAwIFINCi9GaWx0ZXIg L0xaV0RlY29kZSANCj4+DQpzdHJlYW0NCoAQioDRyMBANByLhsOBAICoRAbBokIDkZxADReR oMMRgLhhDIcZgaLY6MBoNhrDSoYxBHRiNpRKjuIBQKiGbzcdDCYzoOhAQTYZhAKYcagaNRuL hmNpbKiIIJJHhmORjKpZJRmMarDpmKCQZTSZDKcjaYTka4babVayLZTSbJ9RCpRq0Mo9DIND qfE6rFYvUZMOBlVqbXJpQDMLq/YbHZbOQDqYTELrGaTGcznOBcczLcroM7sOaZeYfTYnfpHW BrKYdV48NRlTMMKLSUDQLp8K5OIIYNxkNxAMxwORpngaRYHfIpFgaMhrCRoNIPDBjoBdvpaL hpDDkZRBIoFBINwhdL6dEdNy7/Jd/hPZMppa/layGaDkaTmdDSYTdQ6KBobug6TSKewAcBsw bWuyjgZhm+AUCOOQ3jsMo5vm+S2jCt64v+grtLwpz0r65jABoraVsKKiuvq+78v2NwXQjCcK iAyrLszGAxjeNrjBiGSEtHEKJoM1DABk3cFMAGAauk2a1NsFwQBWGyqwcHIZhgqsqJe4zkPQ jb1Oa54XBywalw+EEfISpbsu2ijvJEOKLoQGqlKZAM6x9NKOtBNIYhc2E3hAK4QP6BrwzpOw QQCpIbtkh8vqa1DSKvB6tS6gYoou8KC0XMc2L1SMiOYjKqq1QEEiokVKRSroZuNOtHRSp6Ms HU9ApCBsfIUGYbybFT4x7OocQHENSz9VCVJEwAYhy1kUJLZtnq6KaxjsyzvPq/gzu8KQyjDH A5uMFoZT+plyBmj1f1ojU9rvZTUteGEHQUlwb3nB4gswNIzjcNI3Itao5WuMdsjRbdu2/cId OMgwW1PWS9BAjMHI5d9cxKHL3PKqcHj2IoyDSOg3jkLgZZPCw3DeOgyp9lg8DoEA0LG7zJDe OuYjQN6Z5GEFwDnfj+jcOo2jEsY5j7hqoR/ZOJWPPVcpLX9KtndIY2E8rBwJiYjVtVNVsJiw ZujB7/LnXV0oXWeuI3r943neloPKGu4q7b1wJwEARhBhj/hqjobWLpwjVNt1WJdVKuhAgqDO NI4XSPtaM7beCoq0kz3QeJwwjblrjKy7XBNLp/DY3qFgNpz+s8kIzpdPsDZ4FgmEvzkgyjJc bqhxyDpYeuzscHUySpBVW3qXuKWBQIgyjNf+RDSnG+7Ph1b1TAtox+wgUW8M2aDdgvpKMKgV KgkrYRO10fRNB4qDLmAQX+EA6ZmEHZWwEFtYA733ZYN2gPROM+N8pHm1L1QeTcNrnScvhPQu QhIMniLscKvBqT2l0gyawnpratU0ulQU2JsiTketpRA4NyjGCsPIQW3RB7d0cN6b4rBwDooJ Qdgo6ZxJ8SClVccDR3jrITvFcsRxqarSaObc7Ax0DZINuEhs1EqSjzXEfV+4om4bAyAgCEG9 lbuQZp5MG75Y0TmLEfcqVgG0KjSFdeW81fx+oAH/eon9XBpVmPZQU9t5j3nwQBfIYB88OH1m zfa+9+L8zvP2YK/hg7+gQP8DK/56AboGQCMBAVaEB0dwKJ60qBzkIItcgnFBzEeV0qvP+DGM DrGvQ3g+nyELqGzGfIVCV0a7XXvGjU3NupNIXN5b3Axv5CoaSiie8Vw7q0nEFMHD2H8TYgrL JdERzJs4kOeP/EuYrpIKFSBos+KYODVtlCuWYNsWouB0i9KuMTwV3RmhRFGNSD42vOjhJSTz 1UQx3Y1Hl7kfJsNnks+ZcsgkTldkKzGQ79JFMGYRI9mEkX/z4jkVBU8EJ9klkw1R1ECJOQMY c0xiMt5RzIXVBY7UGWtRjla1FsMsIqrBlTCSIEx5pFSl3KqXsem8H9mDDKYjrKSuwbk6dxRB UHTOcjNCmy8XLxFjXEdzlASjTaqFU2ZNRqZNnatStwbroPOoCaEcIYIAiBpO6Tx28jGERed2 5F3x13rTGjK8Sm6840vanrG+SdIKLR0rnPx7U/zuvfqoA2gZr6Cr1azIN1FCX4H9kQ/Vaz93 8rcog/2idfmHp/owxKS7xKOIrk3JGTtFZP0jhrLmCsplAUqlZVil5SpYuKhHLWmsuTAINdNC w2cv6fQxb9DOq9rIcNlIKdKpU25cNuiHKWTM1qpxKT/EyMdQz0WMq06mbLq4m1gldY8xq/ww z3BAWUoIdXvz3X+Get0P64vApJO+uzxq8x5r28+OL06/tNjs9ifqKI9PdsLH0/9iUl2LqKke g5NLIULkTZWRdl390Rklfso0c5QUZgJaKIwKKPWms5SJR9q3DUntcDa2ETaWzItm2OmN3Gzn VtxUy3UKbe07uBDCYVxIm3YqzDk2hBSU3Ltzc6ad0LR1SiS5+6tzMgXHhFd2DUY7wUukJeMN 15ZJvyDCGuSIIGbsxDeUIzjA1sXvrgru+Vq3hxnnlXp5k9q+z5sBhxLMeMBWEkjgagUf6CPo QXgx9j/LIvyoZhKh0jpIYXopn+AYMKN4fxDAuTzTI64mm7komi6Qb4rpZbKV9tMYyzbRjWMc 0ZdY5hawqYFwmzzDcDcWsL6chOL0lqZx9S9U1NufVBzV08nOh1peHWzZXVZVq/qJ1ATA3mYz EUINjOyxggDYGEPO1UdBuDcGUngaVrh0DyCALgKAyguDOC53IMEBUWXTLEp4KAyM7f8HQ7rn AQBzDy98LgKVxwQBcQy+Nc2n5vnjXiFTys518wxA2fVoMAWDj3gWw+CJA3a0JlmQ1ktE5own I2zGjbNx+0jpOqOILS6WtRiS69WMUYCXSDjUDg8W1EJZCDUtt21Y2yRTjVlv9XXBx7UHH+zN jzLBgcDI3PM4VPmq6ia91NidFuNxjZGVKvS3yvi6Qgcj+BzDafiiYIAjIaDYHU7uaneq7TdO 6uucOEZyjdfrR+Gb+6Z0imriWBM+8V0BYrQTiLHUI0NhCynHtF8hwtyPA/f9JYe5PpW07Z0v EBANCmVuZHN0cmVhbQ0KZW5kb2JqDQo0MiAwIG9iag0KMjE5MQ0KZW5kb2JqDQo0MCAwIG9i ag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDI4IDAgUg0KL1Jlc291cmNlcyA8PA0KL0Zv bnQgPDwNCi9GMCA2IDAgUiANCi9GMSA3IDAgUiANCi9GMiAxMyAwIFIgDQovRjMgMTQgMCBS IA0KL0Y0IDQzIDAgUiANCj4+DQovUHJvY1NldCAyIDAgUg0KPj4NCi9Db250ZW50cyA0MSAw IFINCj4+DQplbmRvYmoNCjQ1IDAgb2JqDQo8PA0KL0xlbmd0aCA0NiAwIFINCi9GaWx0ZXIg L0xaV0RlY29kZSANCj4+DQpzdHJlYW0NCoAQioDRyMBANByLhsOBAICoRAbBokIDkZxADReR oMMRgLhhDIcZgaLY6MBoNhrDSoYxBHRiNpRKjuIBQKiGbzcdDCYzoOhAQTYZhAKYcagaNRuL hmNpbKiIIJJHhmORjKpZJRmMarDpmKCQZTSZDKcjaYTka4babVayLZTSbJ9RCpRq0Mo9DIND qfE6rFYvUZMOBlVqbXJpQDMLq/YbHZbOQDqYTELrGaTGcznOBcczLcroM7sOaZeYfTYnfpHW BrKYdV48NRlTMMKLSUDQLp8K5OIIYNxkNxAMxwORpngaRYHfIpFgaMhrCRoNIPDBjoBdvpaL hpDDkZRBIoFBINwhdL6dEdNy7/Jd/hPZMppa/layGaDkaTmdDSYTdQ6KBobug6TSKewAcBsw bWuyjgZhm+AUCOOQ3jsMo5vm+S2jCt64v+grtLwpz0r65jABoraVsKKiuvq+78v2NwXQjCcK iAyrLszGAxjeNrjBiGSEtHEKJoM1DABk3cFMAGAauk2a1NsFwQBWGyqwcHIZhgqsqJe4zkPQ jb1Oa54XBywalw+EEfISpbsu2ijvJEOKLoQGqlKZAM6x9NKOtBNIYhc2E3hAK4QP6BrwzpOw QQCpIbtkh8vqa1DSKvB8fS6gYoou8KC0WGocIVJtISHMKMqrPSQoij1RUq2YZzJHs8sHAgQI ywdUCokVKT2pTowe/y5ga6qFRAvVao1NME1y1KpQdBSXBrZ0VJoKQyjDHAQBGEAdOMGqOhtA cQ1NZKVV09zy2UroQIKhjjSOF0jxSp6Mo3ZSRKirSTPdB4nDCNoy24/6su1cNjXHXFzWfdFf uNV89VojLpYQ9DZiaI4QCSNo4DKNwyDSNyLCNDQ2Dq7rjBa6tQXjlC7OxgwjVOkqQWWwCl2k lgUCIMozY+NL9JxgNgoNlE/0DYzATUwgUWqMyx44MeAONoatXhmcCpK2ETtdH0TQeKgyjwOg QY+EA6DQ7wprGOzLO8+r+DO72wDpjg5jToGpKhqmjNKwCF322abjbf6c6Co2hx+69H3nmFyV SrGlYcGF3T/h9xCNW97YpFAaV7UV1OMpO/YhZGJ5rm8F2jB9q2unFs23btv4K0uD8zXaXXS+ KChzYCjXfePR3rctmXzVkUq7ft/8KBuB190dT9rc9cc/gWF9HiXoYqI4h4xjWOY9kAQZEt+S s6/+UPJlcfOvZXF5iu/hZqG3T5znee5+N3lanov2KgkukoKaWztpwbmoP5byn8GTVn+mvBk1 pBaR0Tlda+2FsZ/WzNobU2wEDbmQNxbC3Ruz+G8NEUA/xvrM1WrTBQ4FwZPYRuIUc5Z57wnH wAYcDFyb1XLOYhoYRzgM1fJOdAsReSx3gqpdM9F1Js3VrYW08pbyoYiu0h6wp6TuSOO8Oa5x 37lojs0JcRx4ppHjr+aiwJP7zYZONWW7ZhcQnqOVZe9eKsKgmhlY8GGDYYQ4GSLez4PL4WRv kZOyleB0mWPrjWRx98SCsPyaUzpngbmfQhgNCRvbVyPP/RRAFpp3YCRnaFAdqqITANZejBBr zcoKtlbOCBtIcm1tQg2Ght8Hm5hubq3c/7+oSymJK35Z6D4WMchdL0qEMHFLHhm44qTkF0Q5 jk7Ny8bGEubc6ww/7oVizUi+vcrDp1oLSK7E11sT3YRSedNZzTW3cG0KoVVd0XHZOLm+8OMT f4VPIlEUZ5k9ZmTsjdFc2jDYdRzoEg8JobyxBtj3H0MUfw6SBfEyRkz5pDPpZa/xg7Mn4SPf nJJ+0loRt6hM/5H7SmmQDgLSWBECpTwNlS102cE2xNkgvLCDMtIONwBA3KEEvJRyYpOR6YSK IyE0mK4SF5CYYsvmbG2Z8NjygzmkrOHdCUFQ/iDCqLU3IpukczEmK0S4VTmP7Og/8UVwVhqj NedyvyqGDnnIesM918T5mGbOfjyp/1uq1UiN9XqDTTcXHRx1Cg6h4ofH4NkgJBPjousF87Kp EPqZdNR9xH6PlSkhACkUlH7yXpNMCTdKYAUrlBS2ZEJIE2mSXTKK0qqayspxK+WMs22y2g7T +D8uqSWttK0eYMKHjVKR3C15SXiAgA0KZW5kc3RyZWFtDQplbmRvYmoNCjQ2IDAgb2JqDQox NTYzDQplbmRvYmoNCjQ0IDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQgMjggMCBS DQovUmVzb3VyY2VzIDw8DQovRm9udCA8PA0KL0YwIDYgMCBSIA0KL0YxIDcgMCBSIA0KL0Yy IDEzIDAgUiANCi9GNCA0MyAwIFIgDQo+Pg0KL1Byb2NTZXQgMiAwIFINCj4+DQovQ29udGVu dHMgNDUgMCBSDQo+Pg0KZW5kb2JqDQo2IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0 eXBlIC9UcnVlVHlwZQ0KL05hbWUgL0YwDQovQmFzZUZvbnQgL1RpbWVzTmV3Um9tYW4NCi9F bmNvZGluZyAvV2luQW5zaUVuY29kaW5nDQo+Pg0KZW5kb2JqDQo3IDAgb2JqDQo8PA0KL1R5 cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UcnVlVHlwZQ0KL05hbWUgL0YxDQovQmFzZUZvbnQgL1Rp bWVzTmV3Um9tYW4sQm9sZA0KL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcNCj4+DQplbmRv YmoNCjEzIDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UcnVlVHlwZQ0KL05h bWUgL0YyDQovQmFzZUZvbnQgL0FyaWFsLEJvbGQNCi9FbmNvZGluZyAvV2luQW5zaUVuY29k aW5nDQo+Pg0KZW5kb2JqDQoxNCAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAv VHJ1ZVR5cGUNCi9OYW1lIC9GMw0KL0Jhc2VGb250IC9UaW1lc05ld1JvbWFuLEJvbGRJdGFs aWMNCi9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nDQo+Pg0KZW5kb2JqDQo0MyAwIG9iag0K PDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHJ1ZVR5cGUNCi9OYW1lIC9GNA0KL0Jhc2VG b250IC9Db3VyaWVyTmV3LEJvbGQNCi9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nDQo+Pg0K ZW5kb2JqDQoyIDAgb2JqDQpbIC9QREYgL1RleHQgIF0NCmVuZG9iag0KNSAwIG9iag0KPDwN Ci9LaWRzIFs0IDAgUiAxMCAwIFIgMTUgMCBSIDE4IDAgUiAyMSAwIFIgMjQgMCBSIF0NCi9D b3VudCA2DQovVHlwZSAvUGFnZXMNCi9QYXJlbnQgNDcgMCBSDQo+Pg0KZW5kb2JqDQoyOCAw IG9iag0KPDwNCi9LaWRzIFsyNyAwIFIgMzEgMCBSIDM0IDAgUiAzNyAwIFIgNDAgMCBSIDQ0 IDAgUiBdDQovQ291bnQgNg0KL1R5cGUgL1BhZ2VzDQovUGFyZW50IDQ3IDAgUg0KPj4NCmVu ZG9iag0KNDcgMCBvYmoNCjw8DQovS2lkcyBbNSAwIFIgMjggMCBSIF0NCi9Db3VudCAxMg0K L1R5cGUgL1BhZ2VzDQovTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdDQo+Pg0KZW5kb2JqDQox IDAgb2JqDQo8PA0KL0NyZWF0b3IgKE1pY3Jvc29mdCBXb3JkICkNCi9DcmVhdGlvbkRhdGUg KEZyaWRheSwgMTEgQXVndXN0IDIwMDAgMTE6MjgpDQovVGl0bGUgKEFQQy0xOTEyX2Vycm9y X2NvZGVfY29udHJpYnV0aW9uX3YyKQ0KL0F1dGhvciAoQ2hyaXN0aWFuIEdyb3ZlcykNCi9Q cm9kdWNlciAoQWNyb2JhdCBQREZXcml0ZXIgMy4wMiBmb3IgV2luZG93cykNCi9LZXl3b3Jk cyAoKQ0KL1N1YmplY3QgKEguMjQ4IEFubmV4IEwpDQo+Pg0KZW5kb2JqDQozIDAgb2JqDQo8 PA0KL1BhZ2VzIDQ3IDAgUg0KL1R5cGUgL0NhdGFsb2cNCi9EZWZhdWx0R3JheSA0OCAwIFIN Ci9EZWZhdWx0UkdCICA0OSAwIFINCj4+DQplbmRvYmoNCjQ4IDAgb2JqDQpbL0NhbEdyYXkN Cjw8DQovV2hpdGVQb2ludCBbMC45NTA1IDEgMS4wODkxIF0NCi9HYW1tYSAwLjI0NjggDQo+ Pg0KXQ0KZW5kb2JqDQo0OSAwIG9iag0KWy9DYWxSR0INCjw8DQovV2hpdGVQb2ludCBbMC45 NTA1IDEgMS4wODkxIF0NCi9HYW1tYSBbMC4yNDY4IDAuMjQ2OCAwLjI0NjggXQ0KL01hdHJp eCBbMC40MzYxIDAuMjIyNSAwLjAxMzkgMC4zODUxIDAuNzE2OSAwLjA5NzEgMC4xNDMxIDAu MDYwNiAwLjcxNDEgXQ0KPj4NCl0NCmVuZG9iag0KeHJlZg0KMCA1MA0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDM2Mzk1IDAwMDAwIG4NCjAwMDAwMzYwMjYgMDAwMDAgbg0KMDAwMDAz NjY1NiAwMDAwMCBuDQowMDAwMDAxNjI3IDAwMDAwIG4NCjAwMDAwMzYwNjAgMDAwMDAgbg0K MDAwMDAzNTM5MyAwMDAwMCBuDQowMDAwMDM1NTE2IDAwMDAwIG4NCjAwMDAwMDAwMjEgMDAw MDAgbg0KMDAwMDAwMTYwNCAwMDAwMCBuDQowMDAwMDA0OTUxIDAwMDAwIG4NCjAwMDAwMDE3 NzAgMDAwMDAgbg0KMDAwMDAwNDkyNyAwMDAwMCBuDQowMDAwMDM1NjQ0IDAwMDAwIG4NCjAw MDAwMzU3NjUgMDAwMDAgbg0KMDAwMDAwODMyMyAwMDAwMCBuDQowMDAwMDA1MTIyIDAwMDAw IG4NCjAwMDAwMDgyOTkgMDAwMDAgbg0KMDAwMDAxMTU4OSAwMDAwMCBuDQowMDAwMDA4NDgx IDAwMDAwIG4NCjAwMDAwMTE1NjUgMDAwMDAgbg0KMDAwMDAxNTExMyAwMDAwMCBuDQowMDAw MDExNzQ3IDAwMDAwIG4NCjAwMDAwMTUwODkgMDAwMDAgbg0KMDAwMDAxODM4MiAwMDAwMCBu DQowMDAwMDE1MjcxIDAwMDAwIG4NCjAwMDAwMTgzNTggMDAwMDAgbg0KMDAwMDAyMTYxMCAw MDAwMCBuDQowMDAwMDM2MTc2IDAwMDAwIG4NCjAwMDAwMTg1NDAgMDAwMDAgbg0KMDAwMDAy MTU4NiAwMDAwMCBuDQowMDAwMDI1MDg5IDAwMDAwIG4NCjAwMDAwMjE3ODIgMDAwMDAgbg0K MDAwMDAyNTA2NSAwMDAwMCBuDQowMDAwMDI4NDExIDAwMDAwIG4NCjAwMDAwMjUyNjEgMDAw MDAgbg0KMDAwMDAyODM4NyAwMDAwMCBuDQowMDAwMDMwOTA3IDAwMDAwIG4NCjAwMDAwMjg1 NzAgMDAwMDAgbg0KMDAwMDAzMDg4MyAwMDAwMCBuDQowMDAwMDMzMzY1IDAwMDAwIG4NCjAw MDAwMzEwNjYgMDAwMDAgbg0KMDAwMDAzMzM0MSAwMDAwMCBuDQowMDAwMDM1OTAwIDAwMDAw IG4NCjAwMDAwMzUyMjEgMDAwMDAgbg0KMDAwMDAzMzU1MCAwMDAwMCBuDQowMDAwMDM1MTk3 IDAwMDAwIG4NCjAwMDAwMzYyOTQgMDAwMDAgbg0KMDAwMDAzNjc1NCAwMDAwMCBuDQowMDAw MDM2ODQyIDAwMDAwIG4NCnRyYWlsZXINCjw8DQovU2l6ZSA1MA0KL1Jvb3QgMyAwIFINCi9J bmZvIDEgMCBSDQovSUQgWzwwMTY5MTI2OTFmNmQ1ZGY5MzUzMWFjYTdmZTc5YmExND48MDE2 OTEyNjkxZjZkNWRmOTM1MzFhY2E3ZmU3OWJhMTQ+XQ0KPj4NCnN0YXJ0eHJlZg0KMzcwMjAN CiUlRU9GDQo= --------------2B383B83E3F44C8B9F523D14-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 11 01:28:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26734 for ; Fri, 11 Aug 2000 01:28:57 -0400 (EDT) Received: from standards (47.234.32.16:2469) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86A85@standards.nortelnetworks.com>; Fri, 11 Aug 2000 1:16:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4634 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Aug 2000 01:16:46 -0400 Received: from mars.hss.co.in (202.54.26.197:65226) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86A84@standards.nortelnetworks.com>; Fri, 11 Aug 2000 1:16:44 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e7B5TZq08471 for ; Fri, 11 Aug 2000 10:59:41 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256938.001D341E ; Fri, 11 Aug 2000 10:48:58 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256938.001D30D2.00@sandesh.hss.hns.com> Date: Fri, 11 Aug 2000 10:53:01 +0530 Reply-To: klaha@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Kushanava Laha Subject: Query on termination state To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi List, I would appreciate your views on the following points. 1. What is the impact of a termination being made "outofservice" in the MG through the ServiceStates property of the termination state descriptor? The protocol says that "the termination cannot be used for traffic". a) For a termination which was carrying traffic, does it mean that in addition to setting aside the termination from further usage, since no further signals and events should be entertained on the termination, is all signal, event and observed events descriptor pertaining to the termination cleared ? b) Since a Subtract may come later for the termination,if it was in an active context, can Subtract be processed for an "outofservice" termination? c) For an ephemeral termination particularly(whose existense is only in an active context), is an "outofservice" equivalent to setting the mode property in the LocalControl Descriptor as "inactive"? (The termination cannot be deleted as the same action is expected to happen subsequently on getting a Subtract) ? 2. What is the impact of a an "outofservice" termination within an active context in the MG being made "inservice" through the ServiceStates property of the termination descriptor ? The protocol just mentions that "it can be used for normal traffic" ? a) Does it mean that the MG can start honouring signal and event descriptor and start reporting events for the termination? b) Does it mean that the ephemeral termination mode property in the LocalControl Descriptor is set to the mode previous to the change done while making it "outofservice" ? 3. What impact does a ServiceChange have on a termination, physical (in active or NULL context) or ephemeral (in active context only), in an MG, when the method is Restart? a) Does it attempt to put all "outofservice" terminations to "inservice" state as described above? thanks, Kushanava Laha, Hughes Software Systems. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 11 10:08:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17446 for ; Fri, 11 Aug 2000 10:08:33 -0400 (EDT) Received: from standards (47.234.32.16:4697) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86BBF@standards.nortelnetworks.com>; Fri, 11 Aug 2000 9:56:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5014 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Aug 2000 09:56:15 -0400 Received: from auemail2.firewall.lucent.com (auemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86BBE@standards.nortelnetworks.com>; Fri, 11 Aug 2000 9:56:14 -0400 Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA14702 for ; Fri, 11 Aug 2000 10:07:59 -0400 (EDT) Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA14677 for ; Fri, 11 Aug 2000 10:07:58 -0400 (EDT) Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA28702; Fri, 11 Aug 2000 16:07:44 +0200 (MET DST) X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480C14@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <399408A8.806E1D85@lucent.com> Date: Fri, 11 Aug 2000 16:07:36 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: IANA Registration Of Packages To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Tom, First a minor nit: your first liberty amounts to proposing a change in the H.248/Megaco standard. I'm not saying that this change cannot be accommodated, but it might be less trouble if we stick to the 60000-64565 range. As an aside, I have no idea how we ever came up with the 64565. Second, as this affects organizations such as ITU-T, were you planning to have it reviewed at the upcoming Portland rapporteurs' meeting? I think that, in particular, the provision that old versions must remain available is something that ITU may have a problem with. Cheers, John Tom-PT Taylor wrote: > > I have compiled the following set of instructions to IANA for registration > of Megaco/H.248 packages. Before I submit it, I would like your comments. > > I believe I capture the content of our sections 12 and 13 (though in main > part by reference). I have taken two liberties: > -- the private numbering range has been extended a bit to round out the > hexadecimal representation > -- I impose a naming convention for private packages which requires an > originator-specific part followed by an underscore as the first part of the > package name. > > So ... comments? > > INSTRUCTIONS FOR THE REGISTRATION OF MEGACO/H.248 PACKAGES > > 1. Introduction > > Packages are the primary mechanism for extension of the Megaco/H.248 > Gateway Control Protocol. Packages define additional Properties, > Events, Signals and Statistics that may occur on Terminations or on > the Media Gateway as a whole. > > Packages may also define new Megaco/H.248 error codes. This is a > matter of documentary convenience: the package documentation is > submitted to IANA in support of the error code registration. If a > package is updated, it is unnecessary to provide IANA with a new > document reference in support of the error code unless the > description of the error code itself is modified. > > 2. Relationships Between Packages > > A new package may be independent, may extend another package, or may > be a new version of a previously registered package. > > 3. Conditions For Registration Of Packages > > Megaco/H.248 packages may be registered with IANA as either public > or private packages. > > 3.1 Common Requirements For Registration > > The following information MUST be supplied for every registered > package: > > a) the proposed text name for the package. Text names MUST be > unique, with the exception that a new version of a previously > registered package MUST have the same name as the package it > updates. > > b) the version number of the package. Version numbers are > consecutive integers beginning with 1 for the initial version > of a package. > > c) if the package extends another package, the text name and, if > available, serial number of the other package. > > d) a contact name and E-mail and postal addresses for that > contact. The contact information MUST be updated by the > defining organization as necessary. > > 3.2 Additional Requirements For Registration Of Private Packages > > Private packages MUST have text names of the form > qualifier "_" packageName > where qualifier is unique to the organization or individual > registering the package. There is no additional requirement beyond > this and the requirements stated in the previous section. > > 3.3 Additional Requirements For Registration Of Public Packages > > Public packages MUST satisfy the following requirements additional > to those stated in section 3.1: > > a) The defining organization MUST supply a reference to a > publicly-available document which describes the package. The > document SHOULD be located on a public web server and SHOULD > have a stable URL. The documentation MUST remain available > even when a new version of the package is registered. The > organization SHOULD indicate within the document where > comments on that document may be sent. > > b) The document MUST have achieved an advanced degree of technical > stability. > > c) The defining organization MUST indicate whether the document is > still a work in progress or is final. For a work in progress, > the organization MUST indicate the planned date of the final > document. When such a document does become final, the defining > organization MUST advise IANA of the change in status and MUST > ensure that the reference held by IANA is that of the final > document. > > d) IANA MUST be satisfied that the cited document satisfies the > requirements given in section 12 of RFC XXXX (currently draft- > ietf-megaco-merged-01.txt) or Recommendation H.248 (the > corresponding ITU-T document). IANA may draw upon the services > of an expert adviser in making this assessment. > > 4. IANA Actions > > IANA will assign a serial number to each package meeting the > conditions of registration (except for an update of an existing > package, which retains the serial number of the package it is > updating), in consecutive order of registration. The serial number > will be used to identify the package in the binary-coded version of > the Megaco/H.248 protocol. Serial number 0 is reserved, and the > initial tabulation of public packages is given below. Public > packages MUST be given serial numbers in the range 0x0001 to 0xfdff. > Private packages MUST be given serial numbers in the range 0xfe00 to > 0xffff. > > IANA will maintain the currency and public availability of the > tabulation of public and private packages. Packages will be listed > in increasing order of serial number. Updates to packages will be > listed in increasing order of version number. > > 5. Initial Tabulation Of Public Packages > > Serial Text Name Ver Extends Status Reference/ > Serial Ver Contact > > 0x0001 g 1 - - Final Annex E of RFC xxxx or > ITU-T Rec. H.248 > Glen Freundlich > ggf@avaya.com > 0x0002 root 1 - - Final ditto > 0x0003 tonegen 1 - - Final ditto > 0x0004 tonedet 1 - - Final ditto > 0x0005 dg 1 0x0003 1 Final ditto > 0x0006 dd 1 0x0004 1 Final ditto > 0x0007 cg 1 0x0003 1 Final ditto > 0x0008 cd 1 0x0004 1 Final ditto > 0x0009 al 1 - - Final ditto > 0x000a ct 1 - - Final ditto > 0x000b nt 1 - - Final ditto > 0x000c rtp 1 0x000b 1 Final ditto > 0x000d tdmc 1 0x000b 1 Final ditto > 0x000e ftmd 1 0x0004 1 IP 11/00 RFC yyyy /H.248 Annex F > Glen Freundlich > ggf@avaya.com > 0x000f txc 1 - - IP 11/00 ditto > 0x0010 txp 1 - - IP 11/00 ditto > 0x0011 ctyp 1 - - IP 11/00 ditto > 0x0012 fax 1 - - IP 11/00 ditto > 0x0013 ipfax 1 - - IP 11/00 ditto > 0x0014 dis 1 - - IP 11/00 RFC yyyy /H.248 Annex G > Glen Freundlich > ggf@avaya.com > 0x0015 key 1 - - IP 11/00 ditto > 0x0016 kp 1 0x0015 1 IP 11/00 ditto > 0x0017 labelkey 1 0x0015 1 IP 11/00 ditto > 0x0018 kf 1 0x0017 1 IP 11/00 ditto > 0x0019 ind 1 - - IP 11/00 ditto > 0x001a ks 1 0x0017 1 IP 11/00 ditto > 0x001b anci 1 - - IP 11/00 ditto > 0x001c dtd 1 - - IP 11/00 RFC yyyy /H.248 Annex J > Glen Freundlich > ggf@avaya.com > 0x001d an 1 - - IP 11/00 RFC yyyy /H.248 Annex K > Glen Freundlich > ggf@avaya.com -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 11 14:16:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28938 for ; Fri, 11 Aug 2000 14:16:12 -0400 (EDT) Received: from standards (47.234.32.16:4119) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86C93@standards.nortelnetworks.com>; Fri, 11 Aug 2000 14:03:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5305 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Aug 2000 14:03:45 -0400 Received: from shako.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86C92@standards.nortelnetworks.com>; Fri, 11 Aug 2000 14:03:44 -0400 Received: from shako.cisco.com (shako.cisco.com [161.44.3.76]) by shako.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id OAA10775 for ; Fri, 11 Aug 2000 14:15:06 -0400 (EDT) MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Fall_of_Woodcocks_465_000 X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Message-ID: <200008111815.OAA10775@shako.cisco.com> Date: Fri, 11 Aug 2000 14:15:06 -0400 Reply-To: Ravi Subramaniam Sender: "Media Gateway Control (megaco)" From: Ravi Subramaniam Subject: Re: megaco NAS package To: MEGACO@STANDARDS.NORTELNETWORKS.COM --Fall_of_Woodcocks_465_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: TK8KDx1sihavUeCY91GSBA== Hello ... nas package with changes ...using continuity test package and test tones package now instead of defining it in nas. > > As I've said many times before, what makes a NAS different than any > ordinary MG? If you do maintain that there are some things that a NAS > package would need special, then your I-D should only have those > differences. Just print the delta. Why would you have a NAS Id different > than an MG ID. Why is a call ID different on a NAS, etc., etc., etc. > > > At 01:04 PM 8/7/00 -0400, Ravi Subramaniam wrote: > >Content-Type: TEXT/plain; charset=us-ascii > >Content-MD5: VvOptRvtVxsU/at0TsWg5A== > > > >Attachment included !! oops ... > > > > > > > > Hello Tom... > > > I have a prelimnary nas package which I build on top of the > > existing one, > > > please take a look at it. I am working on making it IETF compliant > > > right now, so alignments etc. may be off. > > > Thanks ... > > > Ravi Subramaniam > > > IOS-Wan Connectivity Products > > > Cisco Systems > > > >Thanks ... > >Ravi Subramaniam > >IOS-Wan Connectivity Products > >Cisco Systems > >Content-Type: TEXT/plain; name="new_naspkg.02.txt"; charset=us-ascii; > >x-unix-mode=0644 > >Content-Description: new_naspkg.02.txt > >Content-MD5: vNDr9WtJBf9PBr8fbWr58A== > > > > > >Media Gateway Control (Megaco) Mike Kallas > >Internet Draft Nortel Networks > >Document: draft-ietf-megaco-naspkg-01.txt Zacharias Bilalis > >Category: Standards Track Siemens > > Ravi Subramaniam > > Cisco Systems > > > > > > Megaco/H.248 NAS Package Thanks ... Ravi Subramaniam IOS-Wan Connectivity Products Cisco Systems --Fall_of_Woodcocks_465_000 Content-Type: TEXT/plain; name="new_naspkg.02.txt"; charset=us-ascii; x-unix-mode=0644 Content-Description: new_naspkg.02.txt Content-MD5: s9a7B/ERRvYcPCRPy2rTmg== Media Gateway Control (Megaco) Mike Kallas Internet Draft Nortel Networks Document: draft-ietf-megaco-naspkg-01.txt Zacharias Bilalis Category: Standards Track Siemens Ravi Subramaniam Cisco Systems Megaco/H.248 NAS Package Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document is work in progress and defines a NAS Package for the Megaco/H.248 protocol. It is intended to satisfy the requirements in section 11.2.5 of the Megaco/H.248 requirements document [5]. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 3. ABBREVIATIONS NAS: Network Access Server VPN: Virtual Private Network Kallas, Bilalis, Subramaniam Standards Track - Expires September 2000 1 Megaco/H.248 NAS Package March 2000 4. NAS PACKAGE PackageID: nas, 0x0022 Version: 1 Extends: none This package supports the functionality of a Media Gateway as NAS (Network Access Server), providing support for dial-in access to the NAS. 4.1 Properties VPN id PropertyId: vpnid (0x0001) Description: identifies the VPN to which this termination is to be connected Type: octet string as defined in RFC2685 [4] Possible Values: vpnid Defined in: TerminationState Characteristics: read/write NAS id PropertyId: nasid (0x0002) Description: identifies the NAS to which this termination is to be connected Type: octet string as defined in RFC2685 [4] Possible Values: 0- Defined in: TerminationState Characteristics: read/write 4.2 Events 4.2.2 Authorization Result EventID: authres (0x0002) Description: This event reports the outcome of a request for authorization of Kallas, Bilalis, Subramaniam Standards Track - Expires September 2000 2 Megaco/H.248 NAS Package March 2000 the network access request EventDescriptor Parameters: none added by this package ObservedEventDescriptor Parameters: result ParameterID: res (0x0001) Description: outcome of the service request to the AAA server (see for example IETF RFC 2138 (RADIUS) [2]) Type: enumeration Possible values: succ (0x0000) service request was successful den (0x0001) service request was denied 4.2.4 Call Request EventID: cr (0x0003) Description: The call request event is used to notify that a call has been requested by the NAS. The call back type is used to notify that a call-back has been requested by the AAA server during the initial phase of a data connection (see for example IETF RFC 2138 (RADIUS) [2]). The event report includes the telephone number to which the call is to be made. EventDescriptor Parameters: none added by this package ObservedEventDescriptor Parameters: Type ParameterID: type (0x0001) Description: Type of call desired Type: integer Possible values: 0x1: Callback request 0x2: Outbound call Number to be called ParameterID: cdn (0x0002) Description: the called number Type: string of digits Possible values: location-dependent. Calling number ParameterID: cgn (0x0003) Description: the calling number Type: string of digits Possible values: location-dependent. Bearer Capability ParameterID: bcap(0x0004) Description: Bearer capability desired for the call Type: integer Possible values: 0x1: Unrestricted Digital 0x2: Modem 0x3: Voice Bandwidth ParameterID: bw (0x0005) Description: Bandwidth for the connection Type: integer Possible values: 0x1: 64 0x2: 56 4.2.4 Call Release EventID: cr (0x0004) Description: The call is to be released from the destination. ObservedEventDescriptor Parameters: Cause ParameterID: cause (0x0001) Description: cause code Type: integer Possible values: 00-0x80 4.3 Signals 4.3.1 RELEASE SignalID: rel (0x0001) Description: release Parameters: Parameter id: Cause Description: cause code Type: integer Possible values: 00-0x80 4.4 Statistics None 4.5 Procedures Kallas, Bilalis, Subramaniam Standards Track - Expires September 2000 3 Megaco/H.248 NAS Package March 2000 None 4.6 Descriptor 4.6.1 Call Info Descriptor The call info descriptor contains the parameters required by the NAS for authentication. This descriptor will be delivered to the NAS with the ADD command and will contain the following: . DNIS digits string . CLID digit string . Call type . Authentication Flag . TDM Hairpin flag . TDM Hairpin destination termination id 5. Call Flows 6. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [2] Rigney, C., et al, Remote Authentication Dial In Service (RADIUS), RFC 2138, April 1997 [3] Townsley, W., et al, Layer Two Tunneling Protocol(L2TP), RFC 2661, August 1999 [4] B. Fox and B. Gleeson, Virtual Private Networks Identifier, RFC 2685, September 1999 [5] N. Greene, M. Ramalho, B. Rosen, Media Gateway control protocol architecture and requirements, RFC number TBD, March 2000 (currently draft-ietf-megaco-reqs-10.txt, February 2000) 7. AUTHOR'S ADDRESSES Mike Kallas Nortel Networks P.O. Box 833805 Richardson, Texas 75083-3805 USA Email: mkallas@nortelnetworks.com Zacharias Bilalis Siemens Schertlinstr. 8 81379 Munich Germany Email: zacharias.bilalis@icn.siemens.de Ravi Subramaniam Cisco Systems 7025 Kit Creek Road RTP, NC 27709 USA Email: ravis@cisco.com Kallas, Bilalis, Subramaniam Standards Track - Expires September 2000 4 --Fall_of_Woodcocks_465_000-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 11 16:00:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02087 for ; Fri, 11 Aug 2000 16:00:26 -0400 (EDT) Received: from standards (47.234.32.16:1825) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86CF1@standards.nortelnetworks.com>; Fri, 11 Aug 2000 15:47:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5425 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Aug 2000 15:47:21 -0400 Received: from qhars002.nortel.com (47.101.112.102:43265) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86CF0@standards.nortelnetworks.com>; Fri, 11 Aug 2000 15:47:20 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Fri, 11 Aug 2000 20:53:53 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Fri, 11 Aug 2000 14:52:01 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 11 Aug 2000 14:51:51 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480C1E@zcard00g.ca.nortel.com> Date: Fri, 11 Aug 2000 14:51:48 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: IANA Registration Of Packages X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Responses to some of your comments. > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > Sent: Thursday, August 10, 2000 8:06 PM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: IANA Registration Of Packages > > > G'Day Tom, > > Looks good. Just a couple of comments marked CHG below. > > Cheers, Christian > > Tom-PT Taylor wrote: [snip] > > part by reference). I have taken two liberties: > > -- the private numbering range has been extended a bit to > round out the > > hexadecimal representation > [CHG] OK by me. [snip] > > Packages may also define new Megaco/H.248 error codes. This is a > > matter of documentary convenience: the package documentation is > > submitted to IANA in support of the error code registration. If a > > package is updated, it is unnecessary to provide IANA with a new > > document reference in support of the error code unless the > > description of the error code itself is modified. > [CHG] What do you mean document reference? I thought that the package > that was being registered was the document which described the error > code? [PTT] I'll be posting separate procedures for registering error codes. The details will be covered there. > > > > > 2. Relationships Between Packages > > > > A new package may be independent, may extend another > package, or may > > be a new version of a previously registered package. > [CHG] Perhaps the statement about a new version needs to be > changed? Its > not really a 'new' package. Only the new version number would be > registered with IANA not a new name. [PTT] Perhaps instead of "A new package ..." I should say "A package presented for registration ..." > [snip] > > > > c) if the package extends another package, the text > name and, if > > available, serial number of the other package. > [CHG] The serial number will always be available as its > mandatory in the > package description. ie. "if the package extends another package, the > text name and serial number of the package it extends." [PTT] The serial number will not be available if the package being extended is also new (i.e.) part of the same submission. > > > > > d) a contact name and E-mail and postal addresses for that > > contact. The contact information MUST be updated by the > > defining organization as necessary. > [CHG] How would this work for different organisations? For example in > the ITU would it be the TSB? In the IETF who would it be if it comes > through the WG process? Would it be enough to just reference the > appropriate document number as this won't change but people do? [PTT] That's up to those organizations to figure out. > > > > 3.2 Additional Requirements For Registration Of Private Packages > > > > Private packages MUST have text names of the form > > qualifier "_" packageName > > where qualifier is unique to the organization or individual > > registering the package. There is no additional > requirement beyond > > this and the requirements stated in the previous section. > [CHG] How is this qualifier kept unique? Is it up to IANA to police > this? [PTT] That would be my thought. The intent is just to broaden the namespace in an orderly way. Note that I haven't said how the qualifier should be constructed, but if people want to use conventions like those used in JAVA or SIP, that would be great. > > > > > 3.3 Additional Requirements For Registration Of Public Packages > > > > Public packages MUST satisfy the following requirements > additional > > to those stated in section 3.1: > > > > a) The defining organization MUST supply a reference to a > > publicly-available document which describes the > package. The > > document SHOULD be located on a public web server and SHOULD > > have a stable URL. The documentation MUST remain available > > even when a new version of the package is registered. The > > organization SHOULD indicate within the document where > > comments on that document may be sent. > [CHG] Public web server? Does a web server that has password > protection > count ie. ITU, MSF etc? > I know the recommendation states this but should we clarify it here? [PTT] I suppose we should. I'll add some words on the next pass. [snip] Glen Freundlich > > ggf@avaya.com > > 0x001d an 1 - - IP 11/00 RFC yyyy > /H.248 Annex K > > Glen Freundlich > > ggf@avaya.com > [CHG] Is Glen the appropriate reference or should the TSB be > referenced? [PTT] I'll leave that up to the ITU-T to decide. I'm quite willing to be reference, but of course in principle my formal status as WG chair has limited duration. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 11 17:32:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05778 for ; Fri, 11 Aug 2000 17:32:42 -0400 (EDT) Received: from standards (47.234.32.16:1485) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86D36@standards.nortelnetworks.com>; Fri, 11 Aug 2000 17:20:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5510 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Aug 2000 17:20:29 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86D33@standards.nortelnetworks.com>; Fri, 11 Aug 2000 17:10:29 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id OAA13545; Fri, 11 Aug 2000 14:22:12 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <8BBD33A986C5D311804000902719FF5D9FB3A8@aega.trillium.com> <39928EB4.8C401FF3@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39946F7B.A0205470@cisco.com> Date: Fri, 11 Aug 2000 17:26:19 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: Virtual MGs and MID X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I'm not so sure it's that simple. The port number the MG indicates is for receiving messages, not sending. Furthermore, I thought mId would be unique thereby enabling the MGC to detect duplicate transactions by looking at the combination of mId and TransactionId (as specified in D.1.1). If that's not the case, we have another problem. -- Flemming John Segers wrote: > Bharat, > > Only the IP address of the virtual MGs would be the same; they can be > distinguished by port number. > > This scheme works by virtue of the fact that (virtual) MGs initiate the > registration procedure and can inform the MGC of the port number they > want to use in the first message (servicechange). > > Cheers, > > John > > Bharat Kaul wrote: > > > > I need a clarification regarding use of MID in virtual MG case. > > > > First consider a case where virtual MGs are controlled by the same MGC (i.e. > > in commands from MGC the MID is constant to all these MGs) and the transport > > used is UDP. How do we identify the virtual MG in a PHYSICAL MG to which the > > command from the MGC is destined to ? > > > > Secondly, on MGC side for UDP transport, can all these MGs use the same MID > > (like www.example.net) ? If yes, then we have the same identification > > problem on MGC side too ? I am not clear about the MID that a virtual MG > > should fill in its messages to MGC to identify itself uniquely i.e. how are > > MID's for a virtual MG and non-virtual MG different while sending messages > > to the MGC ? > > > > Clarifications are appreciated. > > > > - Thanks > > Bharat > > > > ---------------------------------------------------------------------------- > > ------- > > Bharat Kaul; Trillium Digital Systems Inc. > > mailto:bharat@trillium.com 12100 Wilshire Blvd, > > Phone: +1-310-442-9222 Los Angeles, CA - 90025. > > Fax: +1-310-442-1162 http://www.trillium.com > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Aug 12 16:12:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05660 for ; Sat, 12 Aug 2000 16:12:54 -0400 (EDT) Received: from standards (47.234.32.16:1807) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86FB8@standards.nortelnetworks.com>; Sat, 12 Aug 2000 16:00:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6402 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 12 Aug 2000 16:00:25 -0400 Received: from web6402.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86FAD@standards.nortelnetworks.com>; Sat, 12 Aug 2000 15:50:24 -0400 Received: from [64.220.200.242] by web6402.mail.yahoo.com; Sat, 12 Aug 2000 13:02:12 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <20000812200212.10329.qmail@web6402.mail.yahoo.com> Date: Sat, 12 Aug 2000 13:02:12 -0700 Reply-To: =?iso-8859-1?q?S=20KA=20N?= Sender: "Media Gateway Control (megaco)" From: =?iso-8859-1?q?S=20KA=20N?= Subject: Re: MG and DiffServ X-To: Matt Holdrege To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hi All, > >Can you think of any relation between the MG and > >DiffServ? > > > >If a privately managed IP network is DiffServ > >compliant and suppose if the same network > >is going to be used for VoIP purposes also. Don't > >we require the MGs to be DiffServ compliant? > > Most MG's are already diffserv or TOS compliant. In > any case you can't require a vendor to build > something unless you plan to give them a lot of > money. I am still in the same loop. Let me go one more level down this time. How would I consider an MG to be QoS (e.g. diffserv, mpls, rsvp) compliant? Is it not possible that first make the MG w/o QoS support and then later at the time of selling it to a customer put a QoS compliant layer-3 device such as an MPLS router with diffserv, etc, with it. In this case, would it still be considered QoS compliant? Request you to comment on this. >>>SKAN<<< __________________________________________________ Do You Yahoo!? Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Aug 12 17:16:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06071 for ; Sat, 12 Aug 2000 17:16:40 -0400 (EDT) Received: from standards (47.234.32.16:3616) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86FD6@standards.nortelnetworks.com>; Sat, 12 Aug 2000 17:04:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6454 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 12 Aug 2000 17:04:28 -0400 Received: from mail.pi.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86FD5@standards.nortelnetworks.com>; Sat, 12 Aug 2000 17:04:28 -0400 Received: from pigpen (ap03-074.mp.pi.se [195.7.87.74]) by mail.pi.se (8.8.8/8.8.8) with SMTP id XAA03643; Sat, 12 Aug 2000 23:16:04 +0200 (MET DST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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.00.2919.6600 Message-ID: Date: Sat, 12 Aug 2000 23:18:42 +0200 Reply-To: Gunnar Hellstrom Sender: "Media Gateway Control (megaco)" From: Gunnar Hellstrom Subject: APC-1945 H.248 Annex F fax/text/call discrimination status and white draft submitted X-To: Sg16mailbag list X-cc: 3GPP_TSG_SA_WG1_GLOBALTEXT <3GPP_TSG_SA_WG1_GLOBALTEXT@list.etsi.fr>, "Text Telephone Forum (Text Telephone Forum)" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Dear all, I have placed document APC-1945 for the Portland Q.12-Q.14 meeting in the Incoming directory of the Pictel avc-site. I hope it will appear soon in the 0008_Por directory for the meeting. Title: H.248 Annex F fax/text/call discrimination, status and white draft. Source: Editor ( Gunnar Hellström, Ericsson ) Document for: Information The document is already sent as a white draft to ITU. The reason to enter the document in this meeting is merely to clarify the status since there are other contributions to H.248 Annex F. ----------------------------Copy of first page of APC-1945:--------------------------------- Status: This document contains the white draft H.248 Annex F. facsimile, text conversation and call discrimination packages. 1. After the determination in February 2000, small modifications have been requested by Q14/16, Q4/8, Q9/16 and Q4/1. They are incorporated. 2. The document was handled by Q.4/8 in a meeting in June. The resulting comments can be found in APC-1890 and APC-1892 issued by Q.4/8 representatives. 3. The document was handled by Q.4/16, Q.9/16 and WP1/16 in a meeting in Edinburgh in June. 4. The contents of documents APC-1890 and APC-1892 proposing modifications for the facsimile parts were available at that meeting and all proposed changes were incorporated. 5. To the knowledge of the editor, also the contents of APC-1891 – T.38 Appendix V- is in line with the current edition of H.248 Annex F. 6. Possible extensions to fully cover data modem discrimination, session establishment and transport were briefly discussed in Q.4/16. No action was taken because of lack of contributions. It should be noted that the current document contains full functionality for the modem negotiation and can therefore be extended by other packages to also cover the modulation and transport of data modem traffic. 7. The document has also been converted to pure text format and entered as an Internet Draft to IETF as draft-ietf-megaco-h248f-00.txt Included here is the white draft as sent to the TSB for decision in the Study Group 16 meeting in November. -------------end of excerpt--------------------------------- Regards ------------------------------------------ Gunnar Hellstrom LM Ericsson E-mail gunnar.hellstrom@omnitor.se Tel +46 8 556 002 03 Mob +46 708 204 288 fax +46 8 556 002 06 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Aug 13 03:41:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05517 for ; Sun, 13 Aug 2000 03:41:49 -0400 (EDT) Received: from standards (47.234.32.16:4378) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8711C@standards.nortelnetworks.com>; 13 Aug 2000 3:28:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6868 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 13 Aug 2000 03:28:57 -0400 Received: from mail-in.audiocodes.com (mail-out.audiocodes.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87111@standards.nortelnetworks.com>; 13 Aug 2000 3:18:56 -0400 Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id ; Sun, 13 Aug 2000 10:24:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Message-ID: <81C3E8FE6C0AD4119D49009027C3AAB25DAB67@MAIL-IN> Date: Sun, 13 Aug 2000 10:23:59 +0200 Reply-To: Nurit Shenhar Sender: "Media Gateway Control (megaco)" From: Nurit Shenhar Subject: draft-ietf-megaco-merged-01.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello 1. I think that there is an error in Appendix A, step 15. The mId should be [125.125.125.111]. 2. There seems to be an inconsistency between the ASN.1 and the ABNF definition of LocalDescriptor and RemoteDescriptor. The ASN.1 format is: **************************************************************************** ********************************** StreamParms ::= SEQUENCE { localControlDescriptor LocalControlDescriptor OPTIONAL, localDescriptor LocalRemoteDescriptor OPTIONAL, remoteDescriptor LocalRemoteDescriptor OPTIONAL, ... } LocalRemoteDescriptor ::= SEQUENCE { propGrps SEQUENCE OF PropertyGroup, ... } PropertyParm ::= SEQUENCE { name PkgdName, value SEQUENCE OF OCTET STRING, extraInfo CHOICE { relation Relation, range BOOLEAN, sublist BOOLEAN } OPTIONAL, ... } **************************************************************************** ********************************** And the ABNF format is: **************************************************************************** ********************************** streamParm = ( localDescriptor / remoteDescriptor / localControlDescriptor ) localDescriptor = LocalToken LBRKT octetString RBRKT remoteDescriptor = RemoteToken LBRKT octetString RBRKT **************************************************************************** ********************************** Which is correct? With respect Nurit Shenhar, AudioCodes From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Aug 13 08:57:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08147 for ; Sun, 13 Aug 2000 08:57:46 -0400 (EDT) Received: from standards (47.234.32.16:3378) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87177@standards.nortelnetworks.com>; 13 Aug 2000 8:45:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7013 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 13 Aug 2000 08:45:28 -0400 Received: from eratosthenes.zen.co.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87176@standards.nortelnetworks.com>; 13 Aug 2000 8:35:27 -0400 Received: (qmail 12512 invoked from network); 13 Aug 2000 12:47:16 -0000 Received: from 78.godel.zen.co.uk (HELO mike) (212.23.16.206) by eratosthenes.zen.co.uk with SMTP for ; 13 Aug 2000 12:47:16 -0000 X-Envelope-To: s_ka_n@YAHOO.COM References: <20000812200212.10329.qmail@web6402.mail.yahoo.com> 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.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <002c01c00524$873da6e0$ce1017d4@mike> Date: Sun, 13 Aug 2000 13:43:53 +0100 Reply-To: Mike Buckley Sender: "Media Gateway Control (megaco)" From: Mike Buckley Subject: Re: MG and DiffServ X-To: S KA N To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit You really need to sort out roles and responsibilities before you can answer these questions. In the general case you have to make a distinction between the VoIP service provider and IP network operator. Of course they may be one and the same but this assumption will not provide a general solution. The MG is a service provider function, it is linked to IP telephony or some other application - as such it is likely to be owned by the IP telephony service provider. The IP transport network on the other hand is likely to be general purpose and will be carrying traffic of different types and from different sources. So where do Diff Serv and RSVP/IntServ fit in? I would submit that these are part of the IP transport network, are application independent, and under the control of the IP network operator. So in the general case they are really nothing to do with the MG which is the territory of the IP telephony service provider. Between the MG and the IP network must be some form of border element which is owned by the IP network operator. This is the device that will terminate RSVP or Diff Serv as far as the network operator is concerned. This device will also provide policy enforcement ON BEHALF OF THE NETWORK OPERATOR. In the TIPHON architecture this device is called an interconnect Function (ICF). RSVP or Diff Serv could of course be extended beyond the domain of the IP Network Operator. This must be by service level agreements, however, and these must address issues of security, policy enforcement and network addressing. TIPHON has chosen to regard the situation of end to end homogeneity as a special case. The general case is where the transport domain mechanisms terminate at the ICFs on the boundary of the IP network operators domain of control. This model allows end to end QoS solutions where the media pass through IP domians with different QoS mechanisms, policies and address spaces (NATs may be part of the ICFs). So Diff Serv and other mechanisms could terminate in the MG but this would require agreements between the network operator and service provider. Policy Enforcement, NAT and security would also need to be covered by such agreements if a network operator was to pass these roles on to a third party. Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley@44comms.com ----- Original Message ----- From: "S KA N" To: Sent: Saturday, August 12, 2000 9:02 PM Subject: Re: MG and DiffServ Hi All, > >Can you think of any relation between the MG and > >DiffServ? > > > >If a privately managed IP network is DiffServ > >compliant and suppose if the same network > >is going to be used for VoIP purposes also. Don't > >we require the MGs to be DiffServ compliant? > > Most MG's are already diffserv or TOS compliant. In > any case you can't require a vendor to build > something unless you plan to give them a lot of > money. I am still in the same loop. Let me go one more level down this time. How would I consider an MG to be QoS (e.g. diffserv, mpls, rsvp) compliant? Is it not possible that first make the MG w/o QoS support and then later at the time of selling it to a customer put a QoS compliant layer-3 device such as an MPLS router with diffserv, etc, with it. In this case, would it still be considered QoS compliant? Request you to comment on this. >>>SKAN<<< __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 14 03:46:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01859 for ; Mon, 14 Aug 2000 03:46:37 -0400 (EDT) Received: from standards (47.234.32.16:4221) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87352@standards.nortelnetworks.com>; Mon, 14 Aug 2000 3:34:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7641 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Aug 2000 03:34:05 -0400 Received: from alemail1.lucent.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87351@standards.nortelnetworks.com>; Mon, 14 Aug 2000 3:34:05 -0400 Received: from alemail1.lucent.com (localhost [127.0.0.1]) by alemail1.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA03208 for ; Mon, 14 Aug 2000 03:45:58 -0400 (EDT) Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211]) by alemail1.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA03192 for ; Mon, 14 Aug 2000 03:45:57 -0400 (EDT) Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA15476; Mon, 14 Aug 2000 09:45:32 +0200 (MET DST) X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3997A391.2EBAB667@lucent.com> Date: Mon, 14 Aug 2000 09:45:21 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Editor's contribution on H.248 in SG16 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit All, I submitted a contribution to the the upcoming SG16 rapporteurs' meeting on H.248. The document can be found at . It lists all the errors I know of in the ITU-approved H.248 recommendation, which is the same as draft-ietf-megaco-merged-01. Most of the errors require minor editorial corrections; there's two that I believe should be discussed on the list: - contradicting text on MG registration in sections 7.2.8 and 11.2 (see section 3.1 of APC-1923), - echo cancellation parameters (see section 3.2 of APC-1923). The meeting takes place next week. I hope that we can agree on a solution before the meeting starts. It would be even better if you agree on the solutions I propose in the contribution :) Regards, John Segers -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 14 05:55:06 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02601 for ; Mon, 14 Aug 2000 05:55:06 -0400 (EDT) Received: from standards (47.234.32.16:1849) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87399@standards.nortelnetworks.com>; Mon, 14 Aug 2000 5:42:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7729 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Aug 2000 05:42:46 -0400 Received: from alemail1.lucent.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87398@standards.nortelnetworks.com>; Mon, 14 Aug 2000 5:42:45 -0400 Received: from alemail1.lucent.com (localhost [127.0.0.1]) by alemail1.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA00575 for ; Mon, 14 Aug 2000 05:54:39 -0400 (EDT) Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211]) by alemail1.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA00565 for ; Mon, 14 Aug 2000 05:54:38 -0400 (EDT) Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA19364; Mon, 14 Aug 2000 11:54:25 +0200 (MET DST) X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <8BBD33A986C5D311804000902719FF5D9FB3A8@aega.trillium.com> <39928EB4.8C401FF3@lucent.com> <39946F7B.A0205470@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3997C1C6.CDC32B5D@lucent.com> Date: Mon, 14 Aug 2000 11:54:14 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Virtual MGs and MID To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Flemming, I think that I'm missing the point. Here's how I understood it to work. MGs and MGCs alike include an MId in messages they send, including port number when necessary, thus making MId unique if different ports are used for communication with different (virtual) MGs. Is there a catch? Cheers, John Flemming Andreasen wrote: > > I'm not so sure it's that simple. The port number the MG indicates is for > receiving messages, not sending. Furthermore, I thought mId would be unique > thereby enabling the MGC to detect duplicate transactions by looking at the > combination of mId and TransactionId (as specified in D.1.1). If that's not the > case, we have another problem. > > -- Flemming > > John Segers wrote: > > > Bharat, > > > > Only the IP address of the virtual MGs would be the same; they can be > > distinguished by port number. > > > > This scheme works by virtue of the fact that (virtual) MGs initiate the > > registration procedure and can inform the MGC of the port number they > > want to use in the first message (servicechange). > > > > Cheers, > > > > John > > > > Bharat Kaul wrote: > > > > > > I need a clarification regarding use of MID in virtual MG case. > > > > > > First consider a case where virtual MGs are controlled by the same MGC (i.e. > > > in commands from MGC the MID is constant to all these MGs) and the transport > > > used is UDP. How do we identify the virtual MG in a PHYSICAL MG to which the > > > command from the MGC is destined to ? > > > > > > Secondly, on MGC side for UDP transport, can all these MGs use the same MID > > > (like www.example.net) ? If yes, then we have the same identification > > > problem on MGC side too ? I am not clear about the MID that a virtual MG > > > should fill in its messages to MGC to identify itself uniquely i.e. how are > > > MID's for a virtual MG and non-virtual MG different while sending messages > > > to the MGC ? > > > > > > Clarifications are appreciated. > > > > > > - Thanks > > > Bharat > > > > > > ---------------------------------------------------------------------------- > > > ------- > > > Bharat Kaul; Trillium Digital Systems Inc. > > > mailto:bharat@trillium.com 12100 Wilshire Blvd, > > > Phone: +1-310-442-9222 Los Angeles, CA - 90025. > > > Fax: +1-310-442-1162 http://www.trillium.com > > > > -- > > John Segers email: jsegers@lucent.com > > Lucent Technologies Room HE 303 > > Dept. Forward Looking Work phone: +31 35 687 4724 > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > -- > Flemming Andreasen Phone: +1 732 452 1667 > Cisco Systems Fax: +1 240 359 5839 -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 14 12:50:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14581 for ; Mon, 14 Aug 2000 12:50:01 -0400 (EDT) Received: from standards (47.234.32.16:2939) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB874DF@standards.nortelnetworks.com>; Mon, 14 Aug 2000 12:37:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8147 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Aug 2000 12:37:04 -0400 Received: from web6401.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB874D2@standards.nortelnetworks.com>; Mon, 14 Aug 2000 12:27:03 -0400 Received: from [64.220.200.242] by web6401.mail.yahoo.com; Mon, 14 Aug 2000 09:38:57 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <20000814163857.2114.qmail@web6401.mail.yahoo.com> Date: Mon, 14 Aug 2000 09:38:57 -0700 Reply-To: =?iso-8859-1?q?S=20KA=20N?= Sender: "Media Gateway Control (megaco)" From: =?iso-8859-1?q?S=20KA=20N?= Subject: Re: MG and DiffServ X-To: Mike Buckley To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hi Mike, Thanks for your reply. I have the following point. If a VoIP vendor implements all the functionality required by ICF, then it will be possible to have close integration of the VoIP devices with the IP network. Take an example of MPLS itself. Here if the MG device itself has MPLS functionality builtin, the granualarity in policy enforcement (FEC implementation) will be more. Any comment? >>>SKAN<<< > You really need to sort out roles and > responsibilities before you can answer > these questions. > > In the general case you have to make a distinction > between the VoIP service > provider and IP network operator. Of course they > may be one and the same > but this assumption will not provide a general > solution. > > The MG is a service provider function, it is linked > to IP telephony or some > other application - as such it is likely to be owned > by the IP telephony > service provider. The IP transport network on the > other hand is likely to > be general purpose and will be carrying traffic of > different types and from > different sources. > > So where do Diff Serv and RSVP/IntServ fit in? I > would submit that these > are part of the IP transport network, are > application independent, and under > the control of the IP network operator. > So in the general case they are really nothing to do > with the MG which is > the territory of the IP telephony service provider. > > Between the MG and the IP network must be some form > of border element which > is owned by the IP network operator. This is the > device that will terminate > RSVP or Diff Serv as far as the network operator is > concerned. This device > will also provide policy enforcement ON BEHALF OF > THE NETWORK OPERATOR. In > the TIPHON architecture this device is called an > interconnect Function > (ICF). > > RSVP or Diff Serv could of course be extended beyond > the domain of the IP > Network Operator. This must be by service level > agreements, however, and > these must address issues of security, > policy enforcement and network addressing. TIPHON > has chosen to regard the > situation of end to end homogeneity as a special > case. The general case is > where the transport domain mechanisms terminate at > the ICFs on the boundary > of the IP network operators domain of control. This > model allows end to end > QoS solutions where the media pass through IP > domians with different QoS > mechanisms, policies and address spaces (NATs may be > part of the ICFs). > > So Diff Serv and other mechanisms could terminate in > the MG but this would > require agreements between the network operator and > service provider. > Policy Enforcement, NAT and security would also need > to be covered by such > agreements if a network operator was to pass these > roles on to a third > party. > > > Mike Buckley > +44-1457-877718 (T) > +44-1457-877721 (F) > mikebuckley@44comms.com > > > ----- Original Message ----- > From: "S KA N" > To: > Sent: Saturday, August 12, 2000 9:02 PM > Subject: Re: MG and DiffServ > > > Hi All, > > > >Can you think of any relation between the MG and > > >DiffServ? > > > > > >If a privately managed IP network is DiffServ > > >compliant and suppose if the same network > > >is going to be used for VoIP purposes also. Don't > > >we require the MGs to be DiffServ compliant? > > > > Most MG's are already diffserv or TOS compliant. > In > > any case you can't require a vendor to build > > something unless you plan to give them a lot of > > money. > > I am still in the same loop. Let me go one more > level > down this time. How would I consider an MG to be > QoS (e.g. diffserv, mpls, rsvp) compliant? Is it > not possible that first make the MG w/o QoS support > and then later at the time of selling it to a > customer > put a QoS compliant layer-3 device such as an MPLS > router with diffserv, etc, with it. In this case, > would > it still be considered QoS compliant? > > Request you to comment on this. > > >>>SKAN<<< > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Mail - Free email you can access from > anywhere! > http://mail.yahoo.com/ > > __________________________________________________ Do You Yahoo!? Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 14 13:34:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15486 for ; Mon, 14 Aug 2000 13:34:06 -0400 (EDT) Received: from standards (47.234.32.16:4348) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87503@standards.nortelnetworks.com>; Mon, 14 Aug 2000 13:21:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8209 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Aug 2000 13:21:27 -0400 Received: from eratosthenes.zen.co.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87500@standards.nortelnetworks.com>; Mon, 14 Aug 2000 13:11:26 -0400 Received: (qmail 10248 invoked from network); 14 Aug 2000 17:23:13 -0000 Received: from 27.locke.zen.co.uk (HELO mike) (212.23.16.27) by eratosthenes.zen.co.uk with SMTP for ; 14 Aug 2000 17:23:13 -0000 X-Envelope-To: s_ka_n@yahoo.com References: <20000814163857.2114.qmail@web6401.mail.yahoo.com> 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.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <006301c00614$3c8a8f00$481017d4@mike> Date: Mon, 14 Aug 2000 18:16:10 +0100 Reply-To: Mike Buckley Sender: "Media Gateway Control (megaco)" From: Mike Buckley Subject: Re: MG and DiffServ X-To: S KA N To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Skan, The key issue as I see it is who owns the ICF and who is enforcing the policies. I would think that generally the ICF that implements MPLS and policy enforcement will be owned by the operator of the IP network not the VoIP service provider. In this situation it would be outside the MG which is a service provider function. Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley@44comms.com ----- Original Message ----- From: "S KA N" To: "Mike Buckley" ; "S KA N" ; Sent: Monday, August 14, 2000 5:38 PM Subject: Re: MG and DiffServ > Hi Mike, > > Thanks for your reply. I have the following point. > > If a VoIP vendor implements all the functionality > required by ICF, then it will be possible to have > close integration of the VoIP devices with the IP > network. Take an example of MPLS itself. Here if > the MG device itself has MPLS functionality builtin, > the granualarity in policy enforcement (FEC > implementation) will be more. > > Any comment? > > >>>SKAN<<< > > > > You really need to sort out roles and > > responsibilities before you can answer > > these questions. > > > > In the general case you have to make a distinction > > between the VoIP service > > provider and IP network operator. Of course they > > may be one and the same > > but this assumption will not provide a general > > solution. > > > > The MG is a service provider function, it is linked > > to IP telephony or some > > other application - as such it is likely to be owned > > by the IP telephony > > service provider. The IP transport network on the > > other hand is likely to > > be general purpose and will be carrying traffic of > > different types and from > > different sources. > > > > So where do Diff Serv and RSVP/IntServ fit in? I > > would submit that these > > are part of the IP transport network, are > > application independent, and under > > the control of the IP network operator. > > So in the general case they are really nothing to do > > with the MG which is > > the territory of the IP telephony service provider. > > > > Between the MG and the IP network must be some form > > of border element which > > is owned by the IP network operator. This is the > > device that will terminate > > RSVP or Diff Serv as far as the network operator is > > concerned. This device > > will also provide policy enforcement ON BEHALF OF > > THE NETWORK OPERATOR. In > > the TIPHON architecture this device is called an > > interconnect Function > > (ICF). > > > > RSVP or Diff Serv could of course be extended beyond > > the domain of the IP > > Network Operator. This must be by service level > > agreements, however, and > > these must address issues of security, > > policy enforcement and network addressing. TIPHON > > has chosen to regard the > > situation of end to end homogeneity as a special > > case. The general case is > > where the transport domain mechanisms terminate at > > the ICFs on the boundary > > of the IP network operators domain of control. This > > model allows end to end > > QoS solutions where the media pass through IP > > domians with different QoS > > mechanisms, policies and address spaces (NATs may be > > part of the ICFs). > > > > So Diff Serv and other mechanisms could terminate in > > the MG but this would > > require agreements between the network operator and > > service provider. > > Policy Enforcement, NAT and security would also need > > to be covered by such > > agreements if a network operator was to pass these > > roles on to a third > > party. > > > > > > Mike Buckley > > +44-1457-877718 (T) > > +44-1457-877721 (F) > > mikebuckley@44comms.com > > > > > > ----- Original Message ----- > > From: "S KA N" > > To: > > Sent: Saturday, August 12, 2000 9:02 PM > > Subject: Re: MG and DiffServ > > > > > > Hi All, > > > > > >Can you think of any relation between the MG and > > > >DiffServ? > > > > > > > >If a privately managed IP network is DiffServ > > > >compliant and suppose if the same network > > > >is going to be used for VoIP purposes also. Don't > > > >we require the MGs to be DiffServ compliant? > > > > > > Most MG's are already diffserv or TOS compliant. > > In > > > any case you can't require a vendor to build > > > something unless you plan to give them a lot of > > > money. > > > > I am still in the same loop. Let me go one more > > level > > down this time. How would I consider an MG to be > > QoS (e.g. diffserv, mpls, rsvp) compliant? Is it > > not possible that first make the MG w/o QoS support > > and then later at the time of selling it to a > > customer > > put a QoS compliant layer-3 device such as an MPLS > > router with diffserv, etc, with it. In this case, > > would > > it still be considered QoS compliant? > > > > Request you to comment on this. > > > > >>>SKAN<<< > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Mail - Free email you can access from > > anywhere! > > http://mail.yahoo.com/ > > > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Mail - Free email you can access from anywhere! > http://mail.yahoo.com/ > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 14 16:38:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18464 for ; Mon, 14 Aug 2000 16:38:31 -0400 (EDT) Received: from standards (47.234.32.16:1272) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8767F@standards.nortelnetworks.com>; Mon, 14 Aug 2000 16:25:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8728 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Aug 2000 16:25:48 -0400 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8767E@standards.nortelnetworks.com>; Mon, 14 Aug 2000 16:25:48 -0400 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA29179; Mon, 14 Aug 2000 13:37:55 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA21375; Mon, 14 Aug 2000 13:37:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20000812200212.10329.qmail@web6402.mail.yahoo.com> <002c01c00524$873da6e0$ce1017d4@mike> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Message-ID: <14744.22673.951871.609884@thomasm-u1.cisco.com> Date: Mon, 14 Aug 2000 13:37:37 -0700 Reply-To: Michael Thomas Sender: "Media Gateway Control (megaco)" From: Michael Thomas Subject: Re: MG and DiffServ X-To: Mike Buckley To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <002c01c00524$873da6e0$ce1017d4@mike> Content-Transfer-Encoding: 7bit I don't get what the big problem is here. Edge devices can and do participate in QoS. This may be as simple as just setting the DSCP, or as complicated as having the application signal its desire for enhanced QoS using RSVP, performing its own internal microflow policing, using integrity and policy objects to transmit identity, etc, etc. The common aspect is that they are requests made by the application layer which are initiated by an IP host. For MEGACO, there are some implications because MG's must be able to be made dumb, policywise. Since e-2-e QoS needs to be initiated by device, that means that the on-the-wire protocol that controls the device (MGC) needs a means to instruct the dumb device (MG) of the correct QoS policy to initiate. This is no different in principal than the MGC telling the MG what codec it prefers the MG to use. As far as the transit network goes, this is really a pairwise settlement issue between the MG and the telephony service provider (they may not be owned by the same entity either), the TSP and the ISP, and the ISP's amongst themselves. Part of that business and settlement relationship in each case needs to be how it fulfills the SLA of the upstream customer. If my contract says that I get EF treatment with any subscriber, that just says that any foreign transit networks better abide within the confines of that SLA, or they need to figure something else out. Fortunately, things like MPLS are making those sort of traffic engineering problems more tenable versus strict destination based routing, though I suppose it's even possible with DSCP's accounted for in the FEC's. I really don't see how that differs materially from normal peering point politics though, and I'm not sure that it warrents a big glossy new TLA. Mike Mike Buckley writes: > You really need to sort out roles and responsibilities before you can answer > these questions. > > In the general case you have to make a distinction between the VoIP service > provider and IP network operator. Of course they may be one and the same > but this assumption will not provide a general solution. > > The MG is a service provider function, it is linked to IP telephony or some > other application - as such it is likely to be owned by the IP telephony > service provider. The IP transport network on the other hand is likely to > be general purpose and will be carrying traffic of different types and from > different sources. > > So where do Diff Serv and RSVP/IntServ fit in? I would submit that these > are part of the IP transport network, are application independent, and under > the control of the IP network operator. > So in the general case they are really nothing to do with the MG which is > the territory of the IP telephony service provider. > > Between the MG and the IP network must be some form of border element which > is owned by the IP network operator. This is the device that will terminate > RSVP or Diff Serv as far as the network operator is concerned. This device > will also provide policy enforcement ON BEHALF OF THE NETWORK OPERATOR. In > the TIPHON architecture this device is called an interconnect Function > (ICF). > > RSVP or Diff Serv could of course be extended beyond the domain of the IP > Network Operator. This must be by service level agreements, however, and > these must address issues of security, > policy enforcement and network addressing. TIPHON has chosen to regard the > situation of end to end homogeneity as a special case. The general case is > where the transport domain mechanisms terminate at the ICFs on the boundary > of the IP network operators domain of control. This model allows end to end > QoS solutions where the media pass through IP domians with different QoS > mechanisms, policies and address spaces (NATs may be part of the ICFs). > > So Diff Serv and other mechanisms could terminate in the MG but this would > require agreements between the network operator and service provider. > Policy Enforcement, NAT and security would also need to be covered by such > agreements if a network operator was to pass these roles on to a third > party. > > > Mike Buckley > +44-1457-877718 (T) > +44-1457-877721 (F) > mikebuckley@44comms.com > > > ----- Original Message ----- > From: "S KA N" > To: > Sent: Saturday, August 12, 2000 9:02 PM > Subject: Re: MG and DiffServ > > > Hi All, > > > >Can you think of any relation between the MG and > > >DiffServ? > > > > > >If a privately managed IP network is DiffServ > > >compliant and suppose if the same network > > >is going to be used for VoIP purposes also. Don't > > >we require the MGs to be DiffServ compliant? > > > > Most MG's are already diffserv or TOS compliant. In > > any case you can't require a vendor to build > > something unless you plan to give them a lot of > > money. > > I am still in the same loop. Let me go one more level > down this time. How would I consider an MG to be > QoS (e.g. diffserv, mpls, rsvp) compliant? Is it > not possible that first make the MG w/o QoS support > and then later at the time of selling it to a customer > put a QoS compliant layer-3 device such as an MPLS > router with diffserv, etc, with it. In this case, > would > it still be considered QoS compliant? > > Request you to comment on this. > > >>>SKAN<<< > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Mail - Free email you can access from anywhere! > http://mail.yahoo.com/ > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 14 18:33:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19999 for ; Mon, 14 Aug 2000 18:33:11 -0400 (EDT) Received: from standards (47.234.32.16:4966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87744@standards.nortelnetworks.com>; Mon, 14 Aug 2000 18:20:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8991 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Aug 2000 18:20:40 -0400 Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87743@standards.nortelnetworks.com>; Mon, 14 Aug 2000 18:20:40 -0400 Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 14 Aug 2000 15:48:19 -0700 Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id PAA11581; Mon, 14 Aug 2000 15:32:20 -0700 (PDT) Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id ; Mon, 14 Aug 2000 15:26:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8BBD33A986C5D311804000902719FF5D9FB3B5@aega.trillium.com> Date: Mon, 14 Aug 2000 15:26:00 -0700 Reply-To: Bharat Kaul Sender: "Media Gateway Control (megaco)" From: Bharat Kaul Subject: Re: Virtual MGs and MID X-To: John Segers X-cc: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM there are a few things which need to be addressed. ISSUE 1: ---------- Flemming mentioned that "port" in MID indicates where the commands should be sent. However, my understanding is different and is given below. If MG needs to indicate to MGC where to send the commands, it will include a ServiceChange Address in its ServiceChange message and thereby indicates to MGC where to send the commands. And this is possible only for UDP transport. For TCP transport, MGC uses the same connection as established by the MG. MGC can also instruct MG to send commands to a particular port by Redirection. So at this point, I myself don't understand what "PORT" in MID signifies. Clarifications are appreciated. ISSUE 2: ---------- MID in standards for IPV4 network is IPAddress [optional port]. So possibility is that in some messages from a entity port is present and in some it is not. In examples shown in the standard (Appendix A), the MG1 is not using consistent MID i.e. in one case it doesn't use "port" in MID and other times it does. From MGC point of view, how does one ensure that it is the same MG ? By the same token, what stops any MG from using the UDP port of transmission as port number in MID. This leads to a problem that at MGC side that MID for a single MG can vary (as examples show) and in case of virtual MG using UDP transport, there is no way poor MGC can distinguish between them. ISSUE 3: ---------- In case of TCP transport, how does one distinguish between a single MG establishing multiple connections to the MGC and virtual MGs establishing TCP connections. Note that at the time of establishing TCP Connection, MGC has no way of knowing which case it is handling ? Can anyone shed some light in this area too ? - Thanks Bharat -----Original Message----- From: John Segers [mailto:jsegers@LUCENT.COM] Sent: Monday, August 14, 2000 2:54 AM To: MEGACO@standards.nortelnetworks.com Subject: Re: Virtual MGs and MID Flemming, I think that I'm missing the point. Here's how I understood it to work. MGs and MGCs alike include an MId in messages they send, including port number when necessary, thus making MId unique if different ports are used for communication with different (virtual) MGs. Is there a catch? Cheers, John Flemming Andreasen wrote: > > I'm not so sure it's that simple. The port number the MG indicates is for > receiving messages, not sending. Furthermore, I thought mId would be unique > thereby enabling the MGC to detect duplicate transactions by looking at the > combination of mId and TransactionId (as specified in D.1.1). If that's not the > case, we have another problem. > > -- Flemming > > John Segers wrote: > > > Bharat, > > > > Only the IP address of the virtual MGs would be the same; they can be > > distinguished by port number. > > > > This scheme works by virtue of the fact that (virtual) MGs initiate the > > registration procedure and can inform the MGC of the port number they > > want to use in the first message (servicechange). > > > > Cheers, > > > > John > > > > Bharat Kaul wrote: > > > > > > I need a clarification regarding use of MID in virtual MG case. > > > > > > First consider a case where virtual MGs are controlled by the same MGC (i.e. > > > in commands from MGC the MID is constant to all these MGs) and the transport > > > used is UDP. How do we identify the virtual MG in a PHYSICAL MG to which the > > > command from the MGC is destined to ? > > > > > > Secondly, on MGC side for UDP transport, can all these MGs use the same MID > > > (like www.example.net) ? If yes, then we have the same identification > > > problem on MGC side too ? I am not clear about the MID that a virtual MG > > > should fill in its messages to MGC to identify itself uniquely i.e. how are > > > MID's for a virtual MG and non-virtual MG different while sending messages > > > to the MGC ? > > > > > > Clarifications are appreciated. > > > > > > - Thanks > > > Bharat > > > > > > ---------------------------------------------------------------------------- > > > ------- > > > Bharat Kaul; Trillium Digital Systems Inc. > > > mailto:bharat@trillium.com 12100 Wilshire Blvd, > > > Phone: +1-310-442-9222 Los Angeles, CA - 90025. > > > Fax: +1-310-442-1162 http://www.trillium.com > > > > -- > > John Segers email: jsegers@lucent.com > > Lucent Technologies Room HE 303 > > Dept. Forward Looking Work phone: +31 35 687 4724 > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > -- > Flemming Andreasen Phone: +1 732 452 1667 > Cisco Systems Fax: +1 240 359 5839 -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 08:43:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13044 for ; Tue, 15 Aug 2000 08:43:02 -0400 (EDT) Received: from standards (47.234.32.16:1891) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87A06@standards.nortelnetworks.com>; Tue, 15 Aug 2000 8:30:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9894 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 08:30:24 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87A04@standards.nortelnetworks.com>; Tue, 15 Aug 2000 8:20:19 -0400 Received: from cisco.com (atlantis-dial-1-50.cisco.com [171.68.181.51]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id FAA24682; Tue, 15 Aug 2000 05:32:10 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <8BBD33A986C5D311804000902719FF5D9FB3A8@aega.trillium.com> <39928EB4.8C401FF3@lucent.com> <39946F7B.A0205470@cisco.com> <3997C1C6.CDC32B5D@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3998CE46.7A48E0AE@cisco.com> Date: Tue, 15 Aug 2000 00:59:50 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: Virtual MGs and MID X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit John Segers wrote: > Flemming, > > I think that I'm missing the point. > > Here's how I understood it to work. MGs and MGCs alike include an MId > in messages they send, including port number when necessary, thus making > MId unique if different ports are used for communication with different > (virtual) MGs. Is there a catch? I thought the port number was only used for ServiceChange and indicated the destination port to use subsequently. I assume the port number you refer to would still be the destination port number (which is simply part of the identifier now), not the source port number. If that's the case, I guess you're right (although it strikes me that having divided the name of an MG/MGC into a local and network part independent of transport would seem better) Related question then: Assume we communicate with MG X on port Y. Is a mId with X as the domainname and Y as the portnumber the same as mId X without a portnumber ? -- Flemming > > > Cheers, > > John > > Flemming Andreasen wrote: > > > > I'm not so sure it's that simple. The port number the MG indicates is for > > receiving messages, not sending. Furthermore, I thought mId would be unique > > thereby enabling the MGC to detect duplicate transactions by looking at the > > combination of mId and TransactionId (as specified in D.1.1). If that's not the > > case, we have another problem. > > > > -- Flemming > > > > John Segers wrote: > > > > > Bharat, > > > > > > Only the IP address of the virtual MGs would be the same; they can be > > > distinguished by port number. > > > > > > This scheme works by virtue of the fact that (virtual) MGs initiate the > > > registration procedure and can inform the MGC of the port number they > > > want to use in the first message (servicechange). > > > > > > Cheers, > > > > > > John > > > > > > Bharat Kaul wrote: > > > > > > > > I need a clarification regarding use of MID in virtual MG case. > > > > > > > > First consider a case where virtual MGs are controlled by the same MGC (i.e. > > > > in commands from MGC the MID is constant to all these MGs) and the transport > > > > used is UDP. How do we identify the virtual MG in a PHYSICAL MG to which the > > > > command from the MGC is destined to ? > > > > > > > > Secondly, on MGC side for UDP transport, can all these MGs use the same MID > > > > (like www.example.net) ? If yes, then we have the same identification > > > > problem on MGC side too ? I am not clear about the MID that a virtual MG > > > > should fill in its messages to MGC to identify itself uniquely i.e. how are > > > > MID's for a virtual MG and non-virtual MG different while sending messages > > > > to the MGC ? > > > > > > > > Clarifications are appreciated. > > > > > > > > - Thanks > > > > Bharat > > > > > > > > ---------------------------------------------------------------------------- > > > > ------- > > > > Bharat Kaul; Trillium Digital Systems Inc. > > > > mailto:bharat@trillium.com 12100 Wilshire Blvd, > > > > Phone: +1-310-442-9222 Los Angeles, CA - 90025. > > > > Fax: +1-310-442-1162 http://www.trillium.com > > > > > > -- > > > John Segers email: jsegers@lucent.com > > > Lucent Technologies Room HE 303 > > > Dept. Forward Looking Work phone: +31 35 687 4724 > > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > > > -- > > Flemming Andreasen Phone: +1 732 452 1667 > > Cisco Systems Fax: +1 240 359 5839 > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 08:48:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13249 for ; Tue, 15 Aug 2000 08:48:39 -0400 (EDT) Received: from standards (47.234.32.16:1891) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87A1F@standards.nortelnetworks.com>; Tue, 15 Aug 2000 8:36:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9895 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 08:36:15 -0400 Received: from eratosthenes.zen.co.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87A05@standards.nortelnetworks.com>; Tue, 15 Aug 2000 8:26:14 -0400 Received: (qmail 8950 invoked from network); 15 Aug 2000 12:38:09 -0000 Received: from 72.locke.zen.co.uk (HELO mike) (212.23.16.72) by eratosthenes.zen.co.uk with SMTP for ; 15 Aug 2000 12:38:09 -0000 X-Envelope-To: mat@cisco.com References: <20000812200212.10329.qmail@web6402.mail.yahoo.com><002c01c00524$873da6e0$ce1017d4@mike> <14744.22673.951871.609884@thomasm-u1.cisco.com> 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.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <002a01c006b5$95136f60$481017d4@mike> Date: Tue, 15 Aug 2000 13:37:07 +0100 Reply-To: Mike Buckley Sender: "Media Gateway Control (megaco)" From: Mike Buckley Subject: Re: MG and DiffServ X-To: Michael Thomas To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit > Since e-2-e QoS needs to be initiated by device, > that means that the on-the-wire protocol that > controls the device (MGC) needs a means to > instruct the dumb device (MG) of the correct QoS > policy to initiate. This is no different in > principal than the MGC telling the MG what codec > it prefers the MG to use. Not sure I followed this. Are you saying that Megaco should carry details of the transport QoS mechanisms that may be supported in the MG? Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley@44comms.com ----- Original Message ----- From: "Michael Thomas" To: "Mike Buckley" Cc: Sent: Monday, August 14, 2000 9:37 PM Subject: Re: MG and DiffServ > > I don't get what the big problem is here. Edge > devices can and do participate in QoS. This may be > as simple as just setting the DSCP, or as > complicated as having the application signal its > desire for enhanced QoS using RSVP, performing its > own internal microflow policing, using integrity > and policy objects to transmit identity, etc, > etc. The common aspect is that they are requests > made by the application layer which are initiated > by an IP host. > > For MEGACO, there are some implications because > MG's must be able to be made dumb, policywise. > Since e-2-e QoS needs to be initiated by device, > that means that the on-the-wire protocol that > controls the device (MGC) needs a means to > instruct the dumb device (MG) of the correct QoS > policy to initiate. This is no different in > principal than the MGC telling the MG what codec > it prefers the MG to use. > > As far as the transit network goes, this is really > a pairwise settlement issue between the MG and the > telephony service provider (they may not be owned > by the same entity either), the TSP and the ISP, > and the ISP's amongst themselves. Part of that > business and settlement relationship in each case > needs to be how it fulfills the SLA of the > upstream customer. If my contract says that I get > EF treatment with any subscriber, that just says > that any foreign transit networks better abide > within the confines of that SLA, or they need to > figure something else out. Fortunately, things > like MPLS are making those sort of traffic > engineering problems more tenable versus strict > destination based routing, though I suppose it's > even possible with DSCP's accounted for in the > FEC's. > > I really don't see how that differs materially > from normal peering point politics though, and I'm > not sure that it warrents a big glossy new TLA. > > Mike > > > Mike Buckley writes: > > You really need to sort out roles and responsibilities before you can answer > > these questions. > > > > In the general case you have to make a distinction between the VoIP service > > provider and IP network operator. Of course they may be one and the same > > but this assumption will not provide a general solution. > > > > The MG is a service provider function, it is linked to IP telephony or some > > other application - as such it is likely to be owned by the IP telephony > > service provider. The IP transport network on the other hand is likely to > > be general purpose and will be carrying traffic of different types and from > > different sources. > > > > So where do Diff Serv and RSVP/IntServ fit in? I would submit that these > > are part of the IP transport network, are application independent, and under > > the control of the IP network operator. > > So in the general case they are really nothing to do with the MG which is > > the territory of the IP telephony service provider. > > > > Between the MG and the IP network must be some form of border element which > > is owned by the IP network operator. This is the device that will terminate > > RSVP or Diff Serv as far as the network operator is concerned. This device > > will also provide policy enforcement ON BEHALF OF THE NETWORK OPERATOR. In > > the TIPHON architecture this device is called an interconnect Function > > (ICF). > > > > RSVP or Diff Serv could of course be extended beyond the domain of the IP > > Network Operator. This must be by service level agreements, however, and > > these must address issues of security, > > policy enforcement and network addressing. TIPHON has chosen to regard the > > situation of end to end homogeneity as a special case. The general case is > > where the transport domain mechanisms terminate at the ICFs on the boundary > > of the IP network operators domain of control. This model allows end to end > > QoS solutions where the media pass through IP domians with different QoS > > mechanisms, policies and address spaces (NATs may be part of the ICFs). > > > > So Diff Serv and other mechanisms could terminate in the MG but this would > > require agreements between the network operator and service provider. > > Policy Enforcement, NAT and security would also need to be covered by such > > agreements if a network operator was to pass these roles on to a third > > party. > > > > > > Mike Buckley > > +44-1457-877718 (T) > > +44-1457-877721 (F) > > mikebuckley@44comms.com > > > > > > ----- Original Message ----- > > From: "S KA N" > > To: > > Sent: Saturday, August 12, 2000 9:02 PM > > Subject: Re: MG and DiffServ > > > > > > Hi All, > > > > > >Can you think of any relation between the MG and > > > >DiffServ? > > > > > > > >If a privately managed IP network is DiffServ > > > >compliant and suppose if the same network > > > >is going to be used for VoIP purposes also. Don't > > > >we require the MGs to be DiffServ compliant? > > > > > > Most MG's are already diffserv or TOS compliant. In > > > any case you can't require a vendor to build > > > something unless you plan to give them a lot of > > > money. > > > > I am still in the same loop. Let me go one more level > > down this time. How would I consider an MG to be > > QoS (e.g. diffserv, mpls, rsvp) compliant? Is it > > not possible that first make the MG w/o QoS support > > and then later at the time of selling it to a customer > > put a QoS compliant layer-3 device such as an MPLS > > router with diffserv, etc, with it. In this case, > > would > > it still be considered QoS compliant? > > > > Request you to comment on this. > > > > >>>SKAN<<< > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Mail - Free email you can access from anywhere! > > http://mail.yahoo.com/ > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 15:23:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22550 for ; Tue, 15 Aug 2000 15:23:31 -0400 (EDT) Received: from standards (47.234.32.16:1118) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87CE7@standards.nortelnetworks.com>; Tue, 15 Aug 2000 15:11:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10854 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 15:11:00 -0400 Received: from web6403.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87CE1@standards.nortelnetworks.com>; Tue, 15 Aug 2000 15:00:58 -0400 Received: from [64.220.200.242] by web6403.mail.yahoo.com; Tue, 15 Aug 2000 12:12:54 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <20000815191255.26132.qmail@web6403.mail.yahoo.com> Date: Tue, 15 Aug 2000 12:12:54 -0700 Reply-To: =?iso-8859-1?q?S=20KA=20N?= Sender: "Media Gateway Control (megaco)" From: =?iso-8859-1?q?S=20KA=20N?= Subject: Re: MG and DiffServ X-To: mikebuckley@44COMMS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit > > Since e-2-e QoS needs to be initiated by device, > > that means that the on-the-wire protocol that > > controls the device (MGC) needs a means to > > instruct the dumb device (MG) of the correct QoS > > policy to initiate. This is no different in > > principal than the MGC telling the MG what codec > > it prefers the MG to use. > > Not sure I followed this. Are you saying that > Megaco should carry details > of the transport QoS mechanisms that may be > supported in the MG? If I recall correctly, there is a requirement specified by MSF also to have a Bearer Control Interface (probably on MGC) which will enable multiple bearer control system to coexists (MPLS, PNNI, ISUP). So even this also points towards having MGCP understand different bearer types. <<>> > > Mike > > Mike Buckley > +44-1457-877718 (T) > +44-1457-877721 (F) > mikebuckley@44comms.com > > > ----- Original Message ----- > From: "Michael Thomas" > To: "Mike Buckley" > Cc: > Sent: Monday, August 14, 2000 9:37 PM > Subject: Re: MG and DiffServ > > > > > > I don't get what the big problem is here. Edge > > devices can and do participate in QoS. This may be > > as simple as just setting the DSCP, or as > > complicated as having the application signal its > > desire for enhanced QoS using RSVP, performing its > > own internal microflow policing, using integrity > > and policy objects to transmit identity, etc, > > etc. The common aspect is that they are requests > > made by the application layer which are initiated > > by an IP host. > > > > For MEGACO, there are some implications because > > MG's must be able to be made dumb, policywise. > > Since e-2-e QoS needs to be initiated by device, > > that means that the on-the-wire protocol that > > controls the device (MGC) needs a means to > > instruct the dumb device (MG) of the correct QoS > > policy to initiate. This is no different in > > principal than the MGC telling the MG what codec > > it prefers the MG to use. > > > > As far as the transit network goes, this is really > > a pairwise settlement issue between the MG and the > > telephony service provider (they may not be owned > > by the same entity either), the TSP and the ISP, > > and the ISP's amongst themselves. Part of that > > business and settlement relationship in each case > > needs to be how it fulfills the SLA of the > > upstream customer. If my contract says that I get > > EF treatment with any subscriber, that just says > > that any foreign transit networks better abide > > within the confines of that SLA, or they need to > > figure something else out. Fortunately, things > > like MPLS are making those sort of traffic > > engineering problems more tenable versus strict > > destination based routing, though I suppose it's > > even possible with DSCP's accounted for in the > > FEC's. > > > > I really don't see how that differs materially > > from normal peering point politics though, and I'm > > not sure that it warrents a big glossy new TLA. > > > > Mike > > > > > > Mike Buckley writes: > > > You really need to sort out roles and > responsibilities before you can > answer > > > these questions. > > > > > > In the general case you have to make a > distinction between the VoIP > service > > > provider and IP network operator. Of course > they may be one and the > same > > > but this assumption will not provide a general > solution. > > > > > > The MG is a service provider function, it is > linked to IP telephony or > some > > > other application - as such it is likely to be > owned by the IP > telephony > > > service provider. The IP transport network on > the other hand is likely > to > > > be general purpose and will be carrying traffic > of different types and > from > > > different sources. > > > > > > So where do Diff Serv and RSVP/IntServ fit in? > I would submit that > these > > > are part of the IP transport network, are > application independent, and > under > > > the control of the IP network operator. > > > So in the general case they are really nothing > to do with the MG which > is > > > the territory of the IP telephony service > provider. > > > > > > Between the MG and the IP network must be some > form of border element > which > > > is owned by the IP network operator. This is > the device that will > terminate > > > RSVP or Diff Serv as far as the network > operator is concerned. This > device > > > will also provide policy enforcement ON BEHALF > OF THE NETWORK OPERATOR. > In > > > the TIPHON architecture this device is called > an interconnect Function > > > (ICF). > > > > > > RSVP or Diff Serv could of course be extended > beyond the domain of the > IP > > > Network Operator. This must be by service > level agreements, however, > and > > > these must address issues of security, > > > policy enforcement and network addressing. > TIPHON has chosen to regard > the > > > situation of end to end homogeneity as a > special case. The general > case is > > > where the transport domain mechanisms terminate > at the ICFs on the > boundary > > > of the IP network operators domain of control. > This model allows end > to end > > > QoS solutions where the media pass through IP > domians with different > QoS > > > mechanisms, policies and address spaces (NATs > may be part of the ICFs). > > > > > > So Diff Serv and other mechanisms could > terminate in the MG but this > would > > > require agreements between the network operator > and service provider. > > > Policy Enforcement, NAT and security would also > need to be covered by > such > > > agreements if a network operator was to pass > these roles on to a third > > > party. > > > > > > > > > Mike Buckley > > > +44-1457-877718 (T) > > > +44-1457-877721 (F) > > > mikebuckley@44comms.com > > > > > > > > > ----- Original Message ----- > > > From: "S KA N" > > > To: > > > Sent: Saturday, August 12, 2000 9:02 PM > > > Subject: Re: MG and DiffServ > > > > > > > > > Hi All, > > > > > > > >Can you think of any relation between the MG > and > > > > >DiffServ? > === message truncated === __________________________________________________ Do You Yahoo!? Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 16:12:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23585 for ; Tue, 15 Aug 2000 16:12:38 -0400 (EDT) Received: from standards (47.234.32.16:2534) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87D51@standards.nortelnetworks.com>; Tue, 15 Aug 2000 16:00:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10924 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 16:00:14 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87D16@standards.nortelnetworks.com>; Tue, 15 Aug 2000 15:50:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23329; Tue, 15 Aug 2000 16:02:01 -0400 (EDT) Message-ID: <200008152002.QAA23329@ietf.org> Date: Tue, 15 Aug 2000 16:02:01 -0400 Reply-To: The IESG Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: CC field duplicated. Last occurrence was retained. Comments: RFC822 error: CC field duplicated. Last occurrence was retained. Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: Protocol Action: Megaco Protocol (With erratta folded in) to Proposed Standard To: MEGACO@STANDARDS.NORTELNETWORKS.COM The IESG has approved the Internet-Draft 'Megaco Protocol (With erratta folded in)' as a Proposed Standard. This document is the product of the Media Gateway Control Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary This document is the combination of draft-ietf-megaco-protocol-08.txt and draft-ietf-megaco-errata-03.txt and is the same text as is being published by the ITU as recommendation H.248. The two IDs were previously approved and Proposed Standards and this new document will obsolete the RFCs that result from those IDs. Working Group Summary The working group supported publishing this combined document and there were no comments from the IETF last-call Protocol Quality This document was reviewed for the IESG by Scott Bradner. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 21:05:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02004 for ; Tue, 15 Aug 2000 21:05:09 -0400 (EDT) Received: from standards (47.234.32.16:4118) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87E86@standards.nortelnetworks.com>; Tue, 15 Aug 2000 20:52:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11412 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 20:52:44 -0400 Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87E85@standards.nortelnetworks.com>; Tue, 15 Aug 2000 20:52:44 -0400 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA02936; Tue, 15 Aug 2000 18:00:00 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA21628; Tue, 15 Aug 2000 17:59:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20000812200212.10329.qmail@web6402.mail.yahoo.com> <002c01c00524$873da6e0$ce1017d4@mike> <14744.22673.951871.609884@thomasm-u1.cisco.com> <002a01c006b5$95136f60$481017d4@mike> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Message-ID: <14745.59261.564728.186405@thomasm-u1.cisco.com> Date: Tue, 15 Aug 2000 17:59:41 -0700 Reply-To: Michael Thomas Sender: "Media Gateway Control (megaco)" From: Michael Thomas Subject: Re: MG and DiffServ X-To: Mike Buckley To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <002a01c006b5$95136f60$481017d4@mike> Content-Transfer-Encoding: 7bit Mike Buckley writes: > > Since e-2-e QoS needs to be initiated by device, > > that means that the on-the-wire protocol that > > controls the device (MGC) needs a means to > > instruct the dumb device (MG) of the correct QoS > > policy to initiate. This is no different in > > principal than the MGC telling the MG what codec > > it prefers the MG to use. > > Not sure I followed this. Are you saying that Megaco should carry details > of the transport QoS mechanisms that may be supported in the MG? Absolutely. The MG may have no idea what QoS policy is appropriate, and in fact it may change on a call by call basis which says that it *must* be setable from the MGC. Mike From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 21:23:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02324 for ; Tue, 15 Aug 2000 21:23:04 -0400 (EDT) Received: from standards (47.234.32.16:1450) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87E9F@standards.nortelnetworks.com>; Tue, 15 Aug 2000 21:10:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11444 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 21:10:43 -0400 Received: from pusren01.risti.telkom.co.id by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87E9E@standards.nortelnetworks.com>; Tue, 15 Aug 2000 21:00:41 -0400 Received: from sign74 ([10.14.3.81]) by pusren01.risti.telkom.co.id (8.9.1/8.9.1) with SMTP id IAA00510 for ; Wed, 16 Aug 2000 08:20:32 +0700 (JVT) 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Message-ID: <001501c00720$5c739340$51030e0a@telkom.go.id> Date: Wed, 16 Aug 2000 08:21:52 +0700 Reply-To: ben@risti.telkom.co.id Sender: "Media Gateway Control (megaco)" From: Beny Subject: ISUP routing label to IP addressing To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear All, I have two questions, First, I need an information, how to convert ISUP routing label (OPC,DPC, CIC) to IP addressing case ? Secondly, SS No.7 has dual mode the type of digit transmission endblock and overlap mode, What The SG doing to handling that condition?. regards Beny Triantono Signaling Laboratory Research & Development Division PT Telekomunikasi Indonesia ph : +62 22 4571346 fax : +62 22 2012262 www.ristinet.com www.ristishop.com www.gematel.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 09:44:06 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24762 for ; Wed, 16 Aug 2000 09:44:05 -0400 (EDT) Received: from standards (47.234.32.16:1466) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88123@standards.nortelnetworks.com>; Wed, 16 Aug 2000 9:31:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12300 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 09:31:09 -0400 Received: from qhars002.nortel.com (47.101.112.102:35354) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88122@standards.nortelnetworks.com>; Wed, 16 Aug 2000 9:31:08 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Wed, 16 Aug 2000 14:42:03 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Wed, 16 Aug 2000 08:42:00 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 16 Aug 2000 08:41:20 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480C34@zcard00g.ca.nortel.com> Date: Wed, 16 Aug 2000 08:41:25 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Virtual MGs and MID X-To: Bharat Kaul To: MEGACO@STANDARDS.NORTELNETWORKS.COM My own views below. > -----Original Message----- > From: Bharat Kaul [mailto:bharat@TRILLIUM.COM] > Sent: Monday, August 14, 2000 6:26 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Virtual MGs and MID > > > there are a few things which need to be addressed. > > ISSUE 1: > ---------- > > Flemming mentioned that "port" in MID indicates where the > commands should be > sent. However, my understanding is different and is given below. > [PTT] Responses must be sent back to where requests came from. For IP transport, the source is presumably derived from the IP header. The primary function of the MID is therefore to provide a logical MG identifier which serves as a handle to the control session context. > If MG needs to indicate to MGC where to send the commands, it > will include a > ServiceChange Address in its ServiceChange message and > thereby indicates to > MGC where to send the commands. And this is possible only for > UDP transport. > For TCP transport, MGC uses the same connection as > established by the MG. [PTT] For TCP transport, I would think that a new ServiceChangeAddress would indicate that the MGC should establish a TCP connection to the new address. It's not clear in general why an MG would do this, but perhaps as part of a failover strategy it might do so. > > MGC can also instruct MG to send commands to a particular port by > Redirection. > > So at this point, I myself don't understand what "PORT" in > MID signifies. > Clarifications are appreciated. > > > ISSUE 2: > ---------- > > MID in standards for IPV4 network is IPAddress [optional port]. So > possibility is that in some messages from a entity port is > present and in > some it is not. > > In examples shown in the standard (Appendix A), the MG1 is not using > consistent MID i.e. in one case it doesn't use "port" in MID > and other times > it does. From MGC point of view, how does one ensure that it > is the same MG > ? > > By the same token, what stops any MG from using the UDP port > of transmission > as port number in MID. > > This leads to a problem that at MGC side that MID for a > single MG can vary > (as examples show) and in case of virtual MG using UDP > transport, there is > no way poor MGC can distinguish between them. > [PTT] If I am correct in my view that the MId serves as a logical identifier, it must be consistent throughout the same control session. > > ISSUE 3: > ---------- > > In case of TCP transport, how does one distinguish between a single MG > establishing multiple connections to the MGC and virtual MGs > establishing > TCP connections. Note that at the time of establishing TCP > Connection, MGC > has no way of knowing which case it is handling ? Can anyone > shed some light > in this area too ? > [PTT] Again, if I am correct in my interpretation of MId, it identifies the logical MG, so the MGC can distinguish the two cases by comparing MIds. It could also do so by noting which terminations each control connection supports. > > - Thanks > Bharat > > > > -----Original Message----- > From: John Segers [mailto:jsegers@LUCENT.COM] > Sent: Monday, August 14, 2000 2:54 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Re: Virtual MGs and MID > > > Flemming, > > I think that I'm missing the point. > > Here's how I understood it to work. MGs and MGCs alike include an MId > in messages they send, including port number when necessary, > thus making > MId unique if different ports are used for communication with > different > (virtual) MGs. Is there a catch? > > Cheers, > > John > > Flemming Andreasen wrote: > > > > I'm not so sure it's that simple. The port number the MG > indicates is for > > receiving messages, not sending. Furthermore, I thought mId would be > unique > > thereby enabling the MGC to detect duplicate transactions > by looking at > the > > combination of mId and TransactionId (as specified in > D.1.1). If that's > not the > > case, we have another problem. > > > > -- Flemming > > > > John Segers wrote: > > > > > Bharat, > > > > > > Only the IP address of the virtual MGs would be the same; > they can be > > > distinguished by port number. > > > > > > This scheme works by virtue of the fact that (virtual) > MGs initiate the > > > registration procedure and can inform the MGC of the port > number they > > > want to use in the first message (servicechange). > > > > > > Cheers, > > > > > > John > > > > > > Bharat Kaul wrote: > > > > > > > > I need a clarification regarding use of MID in virtual MG case. > > > > > > > > First consider a case where virtual MGs are controlled > by the same MGC > (i.e. > > > > in commands from MGC the MID is constant to all these > MGs) and the > transport > > > > used is UDP. How do we identify the virtual MG in a > PHYSICAL MG to > which the > > > > command from the MGC is destined to ? > > > > > > > > Secondly, on MGC side for UDP transport, can all these > MGs use the > same MID > > > > (like www.example.net) ? If yes, then we have the same > identification > > > > problem on MGC side too ? I am not clear about the MID > that a virtual > MG > > > > should fill in its messages to MGC to identify itself > uniquely i.e. > how are > > > > MID's for a virtual MG and non-virtual MG different > while sending > messages > > > > to the MGC ? > > > > > > > > Clarifications are appreciated. > > > > > > > > - Thanks > > > > Bharat > > > > > > > > > -------------------------------------------------------------- > -------------- > > > > ------- > > > > Bharat Kaul; Trillium > Digital Systems > Inc. > > > > mailto:bharat@trillium.com 12100 Wilshire Blvd, > > > > Phone: +1-310-442-9222 Los Angeles, CA - 90025. > > > > Fax: +1-310-442-1162 http://www.trillium.com > > > > > > -- > > > John Segers email: > jsegers@lucent.com > > > Lucent Technologies > Room HE 303 > > > Dept. Forward Looking Work phone: > +31 35 687 4724 > > > P.O. Box 18, 1270 AA Huizen fax: > +31 35 687 5954 > > > > -- > > Flemming Andreasen Phone: +1 732 452 1667 > > Cisco Systems Fax: +1 240 359 5839 > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 09:44:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24767 for ; Wed, 16 Aug 2000 09:44:06 -0400 (EDT) Received: from standards (47.234.32.16:1466) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88136@standards.nortelnetworks.com>; Wed, 16 Aug 2000 9:31:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12324 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 09:31:46 -0400 Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88134@standards.nortelnetworks.com>; Wed, 16 Aug 2000 9:31:46 -0400 Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA00580 for ; Wed, 16 Aug 2000 09:43:45 -0400 (EDT) Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA00561 for ; Wed, 16 Aug 2000 09:43:44 -0400 (EDT) Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA00178; Wed, 16 Aug 2000 15:43:32 +0200 (MET DST) X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <8BBD33A986C5D311804000902719FF5D9FB3A8@aega.trillium.com> <39928EB4.8C401FF3@lucent.com> <39946F7B.A0205470@cisco.com> <3997C1C6.CDC32B5D@lucent.com> <3998CE46.7A48E0AE@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <399A9A77.F38965C9@lucent.com> Date: Wed, 16 Aug 2000 15:43:19 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Virtual MGs and MID To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Flemming, If we have communication with MG X on port Y, then I would say that mId X:Y is equivalent to mId X if X by itself uniquely identifies the MG. Thinking about it, I'm not sure that the port number to include in an mId is the destination port. mId is really supposed to identify the source of the message, and we're proposing that it be a combination of source IP address and destination port. This issue definitely requires some clarifying text. Cheers, John Flemming Andreasen wrote: > > John Segers wrote: > > > Flemming, > > > > I think that I'm missing the point. > > > > Here's how I understood it to work. MGs and MGCs alike include an MId > > in messages they send, including port number when necessary, thus making > > MId unique if different ports are used for communication with different > > (virtual) MGs. Is there a catch? > > I thought the port number was only used for ServiceChange and indicated the > destination port to use subsequently. I assume the port number you refer to would > still be the destination port number (which is simply part of the identifier now), not > the source port number. If that's the case, I guess you're right (although it strikes > me that having divided the name of an MG/MGC into a local and network part independent > of transport would seem better) > > Related question then: Assume we communicate with MG X on port Y. Is a mId with X > as the domainname and Y as the portnumber the same as mId X without a portnumber ? > > -- Flemming > > > > > > > Cheers, > > > > John > > > > Flemming Andreasen wrote: > > > > > > I'm not so sure it's that simple. The port number the MG indicates is for > > > receiving messages, not sending. Furthermore, I thought mId would be unique > > > thereby enabling the MGC to detect duplicate transactions by looking at the > > > combination of mId and TransactionId (as specified in D.1.1). If that's not the > > > case, we have another problem. > > > > > > -- Flemming > > > > > > John Segers wrote: > > > > > > > Bharat, > > > > > > > > Only the IP address of the virtual MGs would be the same; they can be > > > > distinguished by port number. > > > > > > > > This scheme works by virtue of the fact that (virtual) MGs initiate the > > > > registration procedure and can inform the MGC of the port number they > > > > want to use in the first message (servicechange). > > > > > > > > Cheers, > > > > > > > > John > > > > > > > > Bharat Kaul wrote: > > > > > > > > > > I need a clarification regarding use of MID in virtual MG case. > > > > > > > > > > First consider a case where virtual MGs are controlled by the same MGC (i.e. > > > > > in commands from MGC the MID is constant to all these MGs) and the transport > > > > > used is UDP. How do we identify the virtual MG in a PHYSICAL MG to which the > > > > > command from the MGC is destined to ? > > > > > > > > > > Secondly, on MGC side for UDP transport, can all these MGs use the same MID > > > > > (like www.example.net) ? If yes, then we have the same identification > > > > > problem on MGC side too ? I am not clear about the MID that a virtual MG > > > > > should fill in its messages to MGC to identify itself uniquely i.e. how are > > > > > MID's for a virtual MG and non-virtual MG different while sending messages > > > > > to the MGC ? > > > > > > > > > > Clarifications are appreciated. > > > > > > > > > > - Thanks > > > > > Bharat > > > > > > > > > > ---------------------------------------------------------------------------- > > > > > ------- > > > > > Bharat Kaul; Trillium Digital Systems Inc. > > > > > mailto:bharat@trillium.com 12100 Wilshire Blvd, > > > > > Phone: +1-310-442-9222 Los Angeles, CA - 90025. > > > > > Fax: +1-310-442-1162 http://www.trillium.com > > > > > > > > -- > > > > John Segers email: jsegers@lucent.com > > > > Lucent Technologies Room HE 303 > > > > Dept. Forward Looking Work phone: +31 35 687 4724 > > > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > > > > > -- > > > Flemming Andreasen Phone: +1 732 452 1667 > > > Cisco Systems Fax: +1 240 359 5839 > > > > -- > > John Segers email: jsegers@lucent.com > > Lucent Technologies Room HE 303 > > Dept. Forward Looking Work phone: +31 35 687 4724 > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > -- > Flemming Andreasen > Cisco Systems -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 09:52:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24920 for ; Wed, 16 Aug 2000 09:52:12 -0400 (EDT) Received: from standards (47.234.32.16:1466) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88163@standards.nortelnetworks.com>; Wed, 16 Aug 2000 9:39:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12386 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 09:39:37 -0400 Received: from qhars002.nortel.com (47.101.112.102:36671) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88162@standards.nortelnetworks.com>; Wed, 16 Aug 2000 9:39:37 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Wed, 16 Aug 2000 14:47:16 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Wed, 16 Aug 2000 08:40:03 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 16 Aug 2000 08:43:30 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD11480C35@zcard00g.ca.nortel.com> Date: Wed, 16 Aug 2000 08:43:36 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Virtual MGs and MID X-To: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'd say that an MID without port is different from an MId with port. The MId is a logical handle to identify the originator of the message. > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@CISCO.COM] > Sent: Tuesday, August 15, 2000 1:00 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Virtual MGs and MID > > > John Segers wrote: > > > Flemming, > > > > I think that I'm missing the point. > > > > Here's how I understood it to work. MGs and MGCs alike > include an MId > > in messages they send, including port number when > necessary, thus making > > MId unique if different ports are used for communication > with different > > (virtual) MGs. Is there a catch? > > I thought the port number was only used for ServiceChange and > indicated the > destination port to use subsequently. I assume the port > number you refer to would > still be the destination port number (which is simply part of > the identifier now), not > the source port number. If that's the case, I guess you're > right (although it strikes > me that having divided the name of an MG/MGC into a local and > network part independent > of transport would seem better) > > Related question then: Assume we communicate with MG X on > port Y. Is a mId with X > as the domainname and Y as the portnumber the same as mId X > without a portnumber ? > > > -- Flemming > > > > > > > Cheers, > > > > John > > > > Flemming Andreasen wrote: > > > > > > I'm not so sure it's that simple. The port number the MG > indicates is for > > > receiving messages, not sending. Furthermore, I thought > mId would be unique > > > thereby enabling the MGC to detect duplicate transactions > by looking at the > > > combination of mId and TransactionId (as specified in > D.1.1). If that's not the > > > case, we have another problem. > > > > > > -- Flemming > > > > > > John Segers wrote: > > > > > > > Bharat, > > > > > > > > Only the IP address of the virtual MGs would be the > same; they can be > > > > distinguished by port number. > > > > > > > > This scheme works by virtue of the fact that (virtual) > MGs initiate the > > > > registration procedure and can inform the MGC of the > port number they > > > > want to use in the first message (servicechange). > > > > > > > > Cheers, > > > > > > > > John > > > > > > > > Bharat Kaul wrote: > > > > > > > > > > I need a clarification regarding use of MID in > virtual MG case. > > > > > > > > > > First consider a case where virtual MGs are > controlled by the same MGC (i.e. > > > > > in commands from MGC the MID is constant to all these > MGs) and the transport > > > > > used is UDP. How do we identify the virtual MG in a > PHYSICAL MG to which the > > > > > command from the MGC is destined to ? > > > > > > > > > > Secondly, on MGC side for UDP transport, can all > these MGs use the same MID > > > > > (like www.example.net) ? If yes, then we have the > same identification > > > > > problem on MGC side too ? I am not clear about the > MID that a virtual MG > > > > > should fill in its messages to MGC to identify itself > uniquely i.e. how are > > > > > MID's for a virtual MG and non-virtual MG different > while sending messages > > > > > to the MGC ? > > > > > > > > > > Clarifications are appreciated. > > > > > > > > > > - Thanks > > > > > Bharat > > > > > > > > > > > -------------------------------------------------------------- > -------------- > > > > > ------- > > > > > Bharat Kaul; Trillium > Digital Systems Inc. > > > > > mailto:bharat@trillium.com 12100 Wilshire Blvd, > > > > > Phone: +1-310-442-9222 Los Angeles, CA - 90025. > > > > > Fax: +1-310-442-1162 http://www.trillium.com > > > > > > > > -- > > > > John Segers email: > jsegers@lucent.com > > > > Lucent Technologies > Room HE 303 > > > > Dept. Forward Looking Work phone: > +31 35 687 4724 > > > > P.O. Box 18, 1270 AA Huizen fax: > +31 35 687 5954 > > > > > > -- > > > Flemming Andreasen Phone: +1 732 452 1667 > > > Cisco Systems Fax: +1 240 359 5839 > > > > -- > > John Segers email: > jsegers@lucent.com > > Lucent Technologies > Room HE 303 > > Dept. Forward Looking Work phone: +31 > 35 687 4724 > > P.O. Box 18, 1270 AA Huizen fax: +31 > 35 687 5954 > > -- > Flemming Andreasen > Cisco Systems > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 09:55:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24981 for ; Wed, 16 Aug 2000 09:55:15 -0400 (EDT) Received: from standards (47.234.32.16:1466) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8818F@standards.nortelnetworks.com>; Wed, 16 Aug 2000 9:42:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12443 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 09:42:39 -0400 Received: from qhars002.nortel.com (47.101.112.102:37270) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8818A@standards.nortelnetworks.com>; Wed, 16 Aug 2000 9:42:39 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Wed, 16 Aug 2000 14:53:45 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Wed, 16 Aug 2000 09:53:22 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 16 Aug 2000 09:53:20 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480C36@zcard00g.ca.nortel.com> Date: Wed, 16 Aug 2000 09:53:11 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: ISUP routing label to IP addressing X-To: "ben@risti.telkom.co.id" To: MEGACO@STANDARDS.NORTELNETWORKS.COM The answer to your first question is that the translation is a matter of implementation within your network. In principle you need translation tables at your SG to select which MGC to route to, and tables at your MGC to select the MG and terminationId. Your second question is also a matter of design choice. It is possible to handle both en bloc and overlap signalling in an IP network. In the SIP case, there are a couple of possible solutions, but think of the MGC forwarding repeated INVITEs with the digit information accumulated to date, and proxies rejecting the invitations until enough digits are available to route call signalling to another gateway or the final endpoint. > -----Original Message----- > From: Beny [mailto:ben@RISTI.TELKOM.CO.ID] > Sent: Tuesday, August 15, 2000 9:22 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: ISUP routing label to IP addressing > > > Dear All, > > I have two questions, > > First, I need an information, how to convert ISUP routing > label (OPC,DPC, > CIC) to IP addressing case ? > Secondly, SS No.7 has dual mode the type of digit > transmission endblock and > overlap mode, What The SG doing to handling that condition?. > regards > > Beny Triantono > Signaling Laboratory > Research & Development Division > PT Telekomunikasi Indonesia > ph : +62 22 4571346 > fax : +62 22 2012262 > www.ristinet.com > www.ristishop.com > www.gematel.com > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 10:06:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25330 for ; Wed, 16 Aug 2000 10:06:44 -0400 (EDT) Received: from standards (47.234.32.16:1466) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB881B2@standards.nortelnetworks.com>; Wed, 16 Aug 2000 9:54:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12491 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 09:54:13 -0400 Received: from mars.hss.co.in (202.54.26.197:33317) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB881B1@standards.nortelnetworks.com>; Wed, 16 Aug 2000 9:54:11 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e7GE7Jc02825 for ; Wed, 16 Aug 2000 19:37:21 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525693D.004C95FE ; Wed, 16 Aug 2000 19:26:31 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525693D.004C9531.00@sandesh.hss.hns.com> Date: Wed, 16 Aug 2000 19:31:02 +0530 Reply-To: klaha@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Kushanava Laha Subject: Stream Descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM G'day Tom, The protocol talks of the deletion of a stream being only possible when the Local/Remote Descriptors for the stream is set to empty and the ReserveGroup and ReserveValue properties for all the terminations within the context supporting the stream are set to "false". I fail to understand the restriction imposed on the reserve properties........... Kushanava Laha, Hughes Software systems. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 10:48:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26534 for ; Wed, 16 Aug 2000 10:48:09 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8825B@standards.nortelnetworks.com>; Wed, 16 Aug 2000 10:35:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12720 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 10:35:26 -0400 Received: from qhars002.nortel.com (47.101.112.102:45083) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8825A@standards.nortelnetworks.com>; Wed, 16 Aug 2000 10:35:26 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Wed, 16 Aug 2000 15:47:17 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Wed, 16 Aug 2000 09:45:24 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 16 Aug 2000 09:44:18 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480C38@zcard00g.ca.nortel.com> Date: Wed, 16 Aug 2000 09:44:11 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Stream Descriptor X-To: "klaha@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I've been on the road every week for the last two months. It's nice to have a few hours to sit down and pay attention to my much-neglected list. Anyway, to your point: the key is to be found in the third-last paragraph of section 7.1.7. Setting the "reserve.." properties to FALSE actually causes resources to be released, where setting them TRUE does not guarantee that release happens. > -----Original Message----- > From: Kushanava Laha [mailto:klaha@HSS.HNS.COM] > Sent: Wednesday, August 16, 2000 10:01 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Stream Descriptor > > > G'day Tom, > The protocol talks of the deletion of a stream being > only possible when the > Local/Remote Descriptors for the stream is set to empty and > the ReserveGroup and > ReserveValue properties for all the terminations within the > context supporting > the stream > are set to "false". > I fail to understand the restriction imposed on the reserve > properties........... > > Kushanava Laha, > Hughes Software systems. > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 10:55:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26734 for ; Wed, 16 Aug 2000 10:55:18 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8827C@standards.nortelnetworks.com>; Wed, 16 Aug 2000 10:42:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12762 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 10:42:36 -0400 Received: from qhars002.nortel.com (47.101.112.102:46094) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8827B@standards.nortelnetworks.com>; Wed, 16 Aug 2000 10:42:35 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Wed, 16 Aug 2000 15:54:12 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Wed, 16 Aug 2000 10:52:45 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 16 Aug 2000 10:51:51 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480C39@zcard00g.ca.nortel.com> Date: Wed, 16 Aug 2000 10:51:51 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: draft-ietf-megaco-merged-01.txt X-To: Nurit Shenhar To: MEGACO@STANDARDS.NORTELNETWORKS.COM Responses below. > -----Original Message----- > From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM] > Sent: Sunday, August 13, 2000 4:24 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: draft-ietf-megaco-merged-01.txt > > > Hello > > 1. I think that there is an error in Appendix A, step 15. The > mId should be > [125.125.125.111]. > [PTT] Certainly that would be consistent with the mId shown in step 17. > 2. There seems to be an inconsistency between the ASN.1 and the ABNF > definition of LocalDescriptor and RemoteDescriptor. > > The ASN.1 format is: > > ************************************************************** > ************** > ********************************** > StreamParms ::= SEQUENCE > { > localControlDescriptor LocalControlDescriptor OPTIONAL, > localDescriptor LocalRemoteDescriptor OPTIONAL, > remoteDescriptor LocalRemoteDescriptor OPTIONAL, ... > } > LocalRemoteDescriptor ::= SEQUENCE > { > propGrps SEQUENCE OF PropertyGroup, ... > } > PropertyParm ::= SEQUENCE > { > name PkgdName, > value SEQUENCE OF OCTET STRING, > extraInfo CHOICE > { > relation Relation, > range BOOLEAN, > sublist BOOLEAN > } OPTIONAL, > ... > } > ************************************************************** > ************** > ********************************** > > And the ABNF format is: > > ************************************************************** > ************** > ********************************** > streamParm = ( localDescriptor / remoteDescriptor / > localControlDescriptor ) > > localDescriptor = LocalToken LBRKT octetString RBRKT > remoteDescriptor = RemoteToken LBRKT octetString RBRKT > ************************************************************** > ************** > ********************************** > > Which is correct? [PTT] The ABNF is more general and includes the ASN.1 as a possibility. Basically the ABNF allows you to use either SDP or Annex C, whereas the ASN.1 assumes Annex C plus whatever packages come along to augment or replace it. > > > > With respect > > Nurit Shenhar, AudioCodes > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 11:24:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27814 for ; Wed, 16 Aug 2000 11:24:08 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB882DA@standards.nortelnetworks.com>; Wed, 16 Aug 2000 11:11:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12887 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 11:11:26 -0400 Received: from mars.hss.co.in (202.54.26.197:33970) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB882D9@standards.nortelnetworks.com>; Wed, 16 Aug 2000 11:11:19 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e7GFNnc03849; Wed, 16 Aug 2000 20:53:53 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525693D.0053992F ; Wed, 16 Aug 2000 20:43:07 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525693D.0053989B.00@sandesh.hss.hns.com> Date: Wed, 16 Aug 2000 20:48:06 +0530 Reply-To: klaha@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Kushanava Laha Subject: Re: Stream Descriptor X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Tom, It's nice to have you back responding to the usual bombardment of queries. If the MG fails to see the Reserve properties set to FALSE, should it refuse to delete the stream ? The next query is regarding the sequential signal list..............The sequential signal list as per 7.1.11 contains a signal list identifier, a sequence of signals and a signal type. A signal type parameter for the entire list is however missing in the grammar (ABNF or ASN.1). Moreover 7.1.11 also speaks of the possible values for this signal type parameter applicable to the entire list depending on the signal types of the component signals of the list. Question is if an MG encounters a signal type for the signal list violating the specifications in 7.1.11, should it dishonour the signals descriptor? Kushanava Laha, Hughes Software systems Tom-PT Taylor on 08/16/2000 08:14:11 PM Please respond to Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Kushanava Laha/HSS) Subject: Re: Stream Descriptor I've been on the road every week for the last two months. It's nice to have a few hours to sit down and pay attention to my much-neglected list. Anyway, to your point: the key is to be found in the third-last paragraph of section 7.1.7. Setting the "reserve.." properties to FALSE actually causes resources to be released, where setting them TRUE does not guarantee that release happens. > -----Original Message----- > From: Kushanava Laha [mailto:klaha@HSS.HNS.COM] > Sent: Wednesday, August 16, 2000 10:01 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Stream Descriptor > > > G'day Tom, > The protocol talks of the deletion of a stream being > only possible when the > Local/Remote Descriptors for the stream is set to empty and > the ReserveGroup and > ReserveValue properties for all the terminations within the > context supporting > the stream > are set to "false". > I fail to understand the restriction imposed on the reserve > properties........... > > Kushanava Laha, > Hughes Software systems. > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 14:06:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01278 for ; Wed, 16 Aug 2000 14:06:39 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88605@standards.nortelnetworks.com>; Wed, 16 Aug 2000 13:53:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13978 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 13:53:49 -0400 Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88604@standards.nortelnetworks.com>; Wed, 16 Aug 2000 13:53:45 -0400 Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 16 Aug 2000 11:21:25 -0700 Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id LAA12034; Wed, 16 Aug 2000 11:05:17 -0700 (PDT) Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 Aug 2000 10:58:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C007AB.A35ACB94" Message-ID: <8BBD33A986C5D311804000902719FF5D9FB3C3@aega.trillium.com> Date: Wed, 16 Aug 2000 10:58:52 -0700 Reply-To: Bharat Kaul Sender: "Media Gateway Control (megaco)" From: Bharat Kaul Subject: Re: Virtual MGs and MID X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01C007AB.A35ACB94 Content-Type: text/plain; charset="iso-8859-1" Hi Tom, I believe in previous discussions on the mailing list and the philosophy of the protocol that MG always initiates conversation, MG providing ServiceChangeAddress for TCP transport had been ruled out. Providing ServiceChangeAddress for TCP transport implies MGC initiates connection or in other words MG has to have TCP Servers. References for above discussions are give at the end of this email. Is this the current understanding of the protocol ? If yes, I think we should add a line or two in errata which clarifies some of the questions asked with respect to TCP transport and ServiceChange. Atleast pooling the references given below, it does seem like a nice thing to do :) On a side note, if MG is so particular about the port where it wants MGC to send commands to it, the MG might as well use the same port for establishing the TCP connection to the MGC and do away with ServiceChange address and still adhere to "MG Initiates" philosophy. Secondly, I agree with you that the MID should be consistent across a control session. However, the example in Appendix A where MG1 is sending commands is not consistent with this idea. So may be in our errata we should fix that and additionally have a line or two in standards or errata which says, " The MID is constant for the duration of a control session". - Bharat REFERENCES Mail on Oct 6, 1999 with subject as "TCP as transport". Mail on May 30, 2000 with subject as "TCP transport /ServiceChange Command" Mail on June 27, 2000 with subject as "MG Service Change w.r.t. TCP as transport" Mail on July 6, 2000 with subject as "MG Service Change w.r.t. TCP as transport" -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Wednesday, August 16, 2000 6:41 AM To: 'Bharat Kaul'; megaco@standards.nortelnetworks.com Subject: RE: Virtual MGs and MID My own views below. > -----Original Message----- > From: Bharat Kaul [ mailto:bharat@TRILLIUM.COM ] > Sent: Monday, August 14, 2000 6:26 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Virtual MGs and MID > > > there are a few things which need to be addressed. > > ISSUE 1: > ---------- > > Flemming mentioned that "port" in MID indicates where the > commands should be > sent. However, my understanding is different and is given below. > [PTT] Responses must be sent back to where requests came from. For IP transport, the source is presumably derived from the IP header. The primary function of the MID is therefore to provide a logical MG identifier which serves as a handle to the control session context. > If MG needs to indicate to MGC where to send the commands, it > will include a > ServiceChange Address in its ServiceChange message and > thereby indicates to > MGC where to send the commands. And this is possible only for > UDP transport. > For TCP transport, MGC uses the same connection as > established by the MG. [PTT] For TCP transport, I would think that a new ServiceChangeAddress would indicate that the MGC should establish a TCP connection to the new address. It's not clear in general why an MG would do this, but perhaps as part of a failover strategy it might do so. > > MGC can also instruct MG to send commands to a particular port by > Redirection. > > So at this point, I myself don't understand what "PORT" in > MID signifies. > Clarifications are appreciated. > > > ISSUE 2: > ---------- > > MID in standards for IPV4 network is IPAddress [optional port]. So > possibility is that in some messages from a entity port is > present and in > some it is not. > > In examples shown in the standard (Appendix A), the MG1 is not using > consistent MID i.e. in one case it doesn't use "port" in MID > and other times > it does. From MGC point of view, how does one ensure that it > is the same MG > ? > > By the same token, what stops any MG from using the UDP port > of transmission > as port number in MID. > > This leads to a problem that at MGC side that MID for a > single MG can vary > (as examples show) and in case of virtual MG using UDP > transport, there is > no way poor MGC can distinguish between them. > [PTT] If I am correct in my view that the MId serves as a logical identifier, it must be consistent throughout the same control session. > > ISSUE 3: > ---------- > > In case of TCP transport, how does one distinguish between a single MG > establishing multiple connections to the MGC and virtual MGs > establishing > TCP connections. Note that at the time of establishing TCP > Connection, MGC > has no way of knowing which case it is handling ? Can anyone > shed some light > in this area too ? > [PTT] Again, if I am correct in my interpretation of MId, it identifies the logical MG, so the MGC can distinguish the two cases by comparing MIds. It could also do so by noting which terminations each control connection supports. > > - Thanks > Bharat > > > > -----Original Message----- > From: John Segers [ mailto:jsegers@LUCENT.COM ] > Sent: Monday, August 14, 2000 2:54 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Re: Virtual MGs and MID > > > Flemming, > > I think that I'm missing the point. > > Here's how I understood it to work. MGs and MGCs alike include an MId > in messages they send, including port number when necessary, > thus making > MId unique if different ports are used for communication with > different > (virtual) MGs. Is there a catch? > > Cheers, > > John > > Flemming Andreasen wrote: > > > > I'm not so sure it's that simple. The port number the MG > indicates is for > > receiving messages, not sending. Furthermore, I thought mId would be > unique > > thereby enabling the MGC to detect duplicate transactions > by looking at > the > > combination of mId and TransactionId (as specified in > D.1.1). If that's > not the > > case, we have another problem. > > > > -- Flemming > > > > John Segers wrote: > > > > > Bharat, > > > > > > Only the IP address of the virtual MGs would be the same; > they can be > > > distinguished by port number. > > > > > > This scheme works by virtue of the fact that (virtual) > MGs initiate the > > > registration procedure and can inform the MGC of the port > number they > > > want to use in the first message (servicechange). > > > > > > Cheers, > > > > > > John > > > > > > Bharat Kaul wrote: > > > > > > > > I need a clarification regarding use of MID in virtual MG case. > > > > > > > > First consider a case where virtual MGs are controlled > by the same MGC > (i.e. > > > > in commands from MGC the MID is constant to all these > MGs) and the > transport > > > > used is UDP. How do we identify the virtual MG in a > PHYSICAL MG to > which the > > > > command from the MGC is destined to ? > > > > > > > > Secondly, on MGC side for UDP transport, can all these > MGs use the > same MID > > > > (like www.example.net) ? If yes, then we have the same > identification > > > > problem on MGC side too ? I am not clear about the MID > that a virtual > MG > > > > should fill in its messages to MGC to identify itself > uniquely i.e. > how are > > > > MID's for a virtual MG and non-virtual MG different > while sending > messages > > > > to the MGC ? > > > > > > > > Clarifications are appreciated. > > > > > > > > - Thanks > > > > Bharat > > > > > > > > > -------------------------------------------------------------- > -------------- > > > > ------- > > > > Bharat Kaul; Trillium > Digital Systems > Inc. > > > > mailto:bharat@trillium.com 12100 Wilshire Blvd, > > > > Phone: +1-310-442-9222 Los Angeles, CA - 90025. > > > > Fax: +1-310-442-1162 http://www.trillium.com > > > > > > -- > > > John Segers email: > jsegers@lucent.com > > > Lucent Technologies > Room HE 303 > > > Dept. Forward Looking Work phone: > +31 35 687 4724 > > > P.O. Box 18, 1270 AA Huizen fax: > +31 35 687 5954 > > > > -- > > Flemming Andreasen Phone: +1 732 452 1667 > > Cisco Systems Fax: +1 240 359 5839 > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > ------_=_NextPart_001_01C007AB.A35ACB94 Content-Type: text/html; charset="iso-8859-1" RE: Virtual MGs and MID
Hi Tom,
 
   I believe in previous discussions on the mailing list and the philosophy of the protocol that MG always initiates conversation, MG providing ServiceChangeAddress for TCP transport had been ruled out. Providing ServiceChangeAddress for TCP transport implies MGC initiates connection or in other words MG has to have TCP Servers. References for above discussions are give at the end of this email.
 
Is this the current understanding of the protocol ? If yes, I think we should add a line or two in errata which clarifies some of the questions asked with respect to TCP transport and ServiceChange. Atleast pooling the references given below, it does seem like a nice thing to do :)
 
On a side note, if MG is so particular about the port where it wants MGC to send commands to it, the MG might as well use the same port for establishing the TCP connection to the MGC and do away with ServiceChange address and still adhere to "MG Initiates" philosophy.
 
Secondly, I agree with you that the MID should be consistent across a control session. However, the example in Appendix A where MG1 is sending commands is not consistent with this idea. So may be in our errata we should fix that and additionally have a line or two in standards or errata which says, " The MID is constant for the duration of a control session".
 
- Bharat
 
 
 
REFERENCES
 
Mail on Oct 6, 1999 with subject as "TCP as transport".
Mail on May 30, 2000 with subject as "TCP transport /ServiceChange Command"
Mail on June 27, 2000 with subject as "MG Service Change w.r.t. TCP as transport"
Mail on July 6, 2000  with subject as "MG Service Change w.r.t. TCP as transport"
 
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Wednesday, August 16, 2000 6:41 AM
To: 'Bharat Kaul'; megaco@standards.nortelnetworks.com
Subject: RE: Virtual MGs and MID

My own views below.

> -----Original Message-----
> From: Bharat Kaul [mailto:bharat@TRILLIUM.COM]
> Sent: Monday, August 14, 2000 6:26 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Virtual MGs and MID
>
>
> there are a few things which need to be addressed.
>
> ISSUE 1:
> ----------
>
> Flemming mentioned that "port" in MID indicates where the
> commands should be
> sent. However, my understanding is different and is given below.
>
[PTT]
Responses must be sent back to where requests came from.  For IP transport, the source is presumably derived from the IP header.  The primary function of the MID is therefore to provide a logical MG identifier which serves as a handle to the control session context.

> If MG needs to indicate to MGC where to send the commands, it
> will include a
> ServiceChange Address in its ServiceChange message and
> thereby indicates to
> MGC where to send the commands. And this is possible only for
> UDP transport.
> For TCP transport, MGC uses the same connection as
> established by the MG.
[PTT]
For TCP transport, I would think that a new ServiceChangeAddress would indicate that the MGC should establish a TCP connection to the new address.  It's not clear in general why an MG would do this, but perhaps as part of a failover strategy it might do so.

>
> MGC can also instruct MG to send commands to a particular port by
> Redirection.
>
> So at this point, I myself don't understand what "PORT" in
> MID signifies.
> Clarifications are appreciated.
>
>
> ISSUE 2:
> ----------
>
> MID in standards for IPV4 network is IPAddress [optional port]. So
> possibility is that in some messages from a entity port is
> present and in
> some it is not.
>
> In examples shown in the standard (Appendix A), the MG1 is not using
> consistent MID i.e. in one case it doesn't use "port" in MID
> and other times
> it does. From MGC point of view, how does one ensure that it
> is the same MG
> ?

>
> By the same token, what stops any MG from using the UDP port
> of transmission
> as port number in MID.
>
> This leads to a problem that at MGC side that MID for a
> single MG can vary
> (as examples show) and in case of virtual MG using UDP
> transport, there is
> no way poor MGC can distinguish between them.
>
[PTT]
If I am correct in my view that the MId serves as a logical identifier, it must be consistent throughout the same control session.

>
> ISSUE 3:
> ----------
>
> In case of TCP transport, how does one distinguish between a single MG
> establishing multiple connections to the MGC and virtual MGs
> establishing
> TCP connections. Note that at the time of establishing TCP
> Connection, MGC
> has no way of knowing which case it is handling ? Can anyone
> shed some light
> in this area too ?
>
[PTT]
Again, if I am correct in my interpretation of MId, it identifies the logical MG, so the MGC can distinguish the two cases by comparing MIds.  It could also do so by noting which terminations each control connection supports.

>
> - Thanks
>   Bharat
>
>
>
> -----Original Message-----
> From: John Segers [mailto:jsegers@LUCENT.COM]
> Sent: Monday, August 14, 2000 2:54 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Virtual MGs and MID
>
>
> Flemming,
>
> I think that I'm missing the point.
>
> Here's how I understood it to work.  MGs and MGCs alike include an MId
> in messages they send, including port number when necessary,
> thus making
> MId unique if different ports are used for communication with
> different
> (virtual) MGs.  Is there a catch?
>
> Cheers,
>
> John
>
> Flemming Andreasen wrote:
> >
> > I'm not so sure it's that simple. The port number the MG
> indicates is for
> > receiving messages, not sending. Furthermore, I thought mId would be
> unique
> > thereby enabling the MGC to detect duplicate transactions
> by looking at
> the
> > combination of mId and TransactionId (as specified in
> D.1.1). If that's
> not the
> > case, we have another problem.
> >
> > -- Flemming
> >
> > John Segers wrote:
> >
> > > Bharat,
> > >
> > > Only the IP address of the virtual MGs would be the same;
> they can be
> > > distinguished by port number.
> > >
> > > This scheme works by virtue of the fact that (virtual)
> MGs initiate the
> > > registration procedure and can inform the MGC of the port
> number they
> > > want to use in the first message (servicechange).
> > >
> > > Cheers,
> > >
> > > John
> > >
> > > Bharat Kaul wrote:
> > > >
> > > > I need a clarification regarding use of MID in virtual MG case.
> > > >
> > > > First consider a case where virtual MGs are controlled
> by the same MGC
> (i.e.
> > > > in commands from MGC the MID is constant to all these
> MGs) and the
> transport
> > > > used is UDP. How do we identify the virtual MG in a
> PHYSICAL MG to
> which the
> > > > command from the MGC is destined to ?
> > > >
> > > > Secondly, on MGC side for UDP transport, can all these
> MGs use the
> same MID
> > > > (like www.example.net) ? If yes, then we have the same
> identification
> > > > problem on MGC side too ?  I am not clear about the MID
> that a virtual
> MG
> > > > should fill in its messages to MGC to identify itself
> uniquely i.e.
> how are
> > > > MID's for a virtual MG and non-virtual MG different
> while sending
> messages
> > > > to the MGC ?
> > > >
> > > > Clarifications are appreciated.
> > > >
> > > > - Thanks
> > > >   Bharat
> > > >
> > > >
> --------------------------------------------------------------
> --------------
> > > > -------
> > > > Bharat Kaul;                                 Trillium
> Digital Systems
> Inc.
> > > > mailto:bharat@trillium.com    12100 Wilshire Blvd,
> > > > Phone: +1-310-442-9222         Los Angeles, CA - 90025.
> > > > Fax:     +1-310-442-1162           http://www.trillium.com
> > >
> > > --
> > > John Segers                                  email:
> jsegers@lucent.com
> > > Lucent Technologies                                      
>  Room HE 303
> > > Dept. Forward Looking Work                      phone:
> +31 35 687 4724
> > > P.O. Box 18, 1270 AA  Huizen                      fax:
> +31 35 687 5954
> >
> > --
> > Flemming Andreasen                Phone: +1 732 452 1667
> > Cisco Systems                     Fax:   +1 240 359 5839
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 303
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
>

------_=_NextPart_001_01C007AB.A35ACB94-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 14:13:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01400 for ; Wed, 16 Aug 2000 14:13:25 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8862B@standards.nortelnetworks.com>; Wed, 16 Aug 2000 14:00:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14027 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 14:00:26 -0400 Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8862A@standards.nortelnetworks.com>; Wed, 16 Aug 2000 14:00:24 -0400 Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 16 Aug 2000 11:28:14 -0700 Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id LAA12205; Wed, 16 Aug 2000 11:12:10 -0700 (PDT) Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 Aug 2000 11:05:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8BBD33A986C5D311804000902719FF5DAFF428@aega.trillium.com> Date: Wed, 16 Aug 2000 11:05:45 -0700 Reply-To: Naren Tulpule Sender: "Media Gateway Control (megaco)" From: Naren Tulpule Subject: Re: draft-ietf-megaco-merged-01.txt X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > > 1. I think that there is an error in Appendix A, step 15. The > mId should be > [125.125.125.111]. > [PTT] Certainly that would be consistent with the mId shown in step 17. [[ NAREN ]] Is it the consensus now that a) MID _MUST_ be unique for an MG or MGC, and treated as a logical handle irrespective of any changes in ports etc; and b) Virtual MGs _MUST_ distinguish themselves by a mandatory port part in the MID; and this "IP-address/name + port" MID _MUST_ not change (as in (a)). I am surprized the protocol designers did not fix even basic things like how an MG or MGC identifies a peer from MID received in a message. (But perhaps that's an "implementation detail", best left out of protocol specs :-) [PTT] The ABNF is more general and includes the ASN.1 as a possibility. Basically the ABNF allows you to use either SDP or Annex C, whereas the ASN.1 assumes Annex C plus whatever packages come along to augment or replace it. [[ NAREN ]] Can you please clarify how ABNF allows us to use annex C? I thought annex C was strictly for binary encoding; and SDP for text encoding; and that ABNF only specified text encoding. Are you allowed to embed binary info in text? (Certainly if annex A is to be believed, we have to embed text strings like digit maps inside the binary but now it's the other way too?) Or do you mean some unspecified equivalent of binary ID-value pairs in text encoding? -- Naren. Narendra C. Tulpule SMTS, Trillium Digital Systems Ph: +1-310-442-9222 Fax: +1-310-442-1162 12100 Wilshire Bl #1800 Los Angeles, CA 90025 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 15:28:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02756 for ; Wed, 16 Aug 2000 15:28:27 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88731@standards.nortelnetworks.com>; Wed, 16 Aug 2000 15:15:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14361 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 15:15:45 -0400 Received: from northex.sevis.com (isdn-64-218-134-130.sevis.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88727@standards.nortelnetworks.com>; Wed, 16 Aug 2000 15:05:45 -0400 Received: by isdn-64-218-134-130.sevis.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 Aug 2000 14:20:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 16 Aug 2000 14:20:09 -0500 Reply-To: Quy Ha Sender: "Media Gateway Control (megaco)" From: Quy Ha Subject: Please add my name to your E-mail distro list. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Quy Ha Sevis Systems, Inc. Systems Engineering 17950 Preston Rd, Suite 700 Dallas, TX 75252 972-267-5107 ext. 285; 972-267-5196 fax quy.ha@sevis.com This email is intended for the named recipient(s) only and may contain information that is privileged and/or confidential. Nothing in this email is intended to constitute a waiver of any privilege or the confidentiality of this message. If you have received this email in error, please notify me immediately by reply and delete this message. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 11:01:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27994 for ; Thu, 17 Aug 2000 11:01:11 -0400 (EDT) Received: from standards (47.234.32.16:1158) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88D10@standards.nortelnetworks.com>; Thu, 17 Aug 2000 10:46:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16252 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 10:46:19 -0400 Received: from cs.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88CD8@standards.nortelnetworks.com>; Thu, 17 Aug 2000 10:36:19 -0400 Received: from bourbon.cs.columbia.edu (bourbon.cs.columbia.edu [128.59.19.24]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA17014 for ; Thu, 17 Aug 2000 10:48:21 -0400 (EDT) Received: from localhost (xiaotaow@localhost) by bourbon.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA12716 for ; Thu, 17 Aug 2000 10:48:21 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 17 Aug 2000 10:48:20 -0400 Reply-To: Xiaotao Wu Sender: "Media Gateway Control (megaco)" From: Xiaotao Wu Subject: Need clarification on topology To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, I have a question for handling the topology. Based on the syntax definition, every contextRequest can only have one topologyDescriptor and every topologyDescriptor can only have one (termA, termB, direction) triples. So, if I want to specify the topology by using more than one triple (e.g., I want to set (termA, termB, Isolate) and at the same time, set (termA, termB, bothway)), I need to use more than one contextRequest to do it, instead of putting all the topologyDescriptors in one contextRequest, though these descriptors are applied to the same context. Is it right? Thanks! -Xiaotao contextRequest = ((contextProperties [COMMA contextAudit]) / contextAudit) contextProperties = contextProperty *(COMMA contextProperty) ; at-most-once contextProperty = (topologyDescriptor / priority / EmergencyToken) .... topologyDescriptor = TopologyToken LBRKT terminationA COMMA terminationB COMMA topologyDirection RBRKT terminationA = TerminationID terminationB = TerminationID topologyDirection = BothwayToken / IsolateToken / OnewayToken -Xiaotao ==================================================== Name : Xiaotao Wu (Always available by email!) Email: xiaotaow@cs.columbia.edu, xw71@columbia.edu URL : http://www.cs.columbia.edu/~xiaotaow Work Phone: (212)939-7087, Home Phone: (212)795-1963 Office: Room 623, Schapiro (CEPSR), West 120th ==================================================== From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 11:35:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28728 for ; Thu, 17 Aug 2000 11:35:01 -0400 (EDT) Received: from standards (47.234.32.16:1158) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88E1E@standards.nortelnetworks.com>; Thu, 17 Aug 2000 11:21:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16678 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 11:21:59 -0400 Received: from qhars002.nortel.com (47.101.112.102:40029) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88E1D@standards.nortelnetworks.com>; Thu, 17 Aug 2000 11:21:58 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Thu, 17 Aug 2000 14:19:05 +0100 Received: from zcard015.ca.nortel.com (actually zcard015) by smtprch1.nortel.com; Thu, 17 Aug 2000 08:16:32 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 17 Aug 2000 09:15:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0084D.42968A80" Message-ID: Date: Thu, 17 Aug 2000 09:15:48 -0400 Reply-To: Sophia Scoggins Sender: "Media Gateway Control (megaco)" From: Sophia Scoggins Subject: Packet Network Package X-To: Tom-PT Taylor X-cc: Michael Brown To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01C0084D.42968A80 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0084D.42968A80" ------_=_NextPart_001_01C0084D.42968A80 Content-Type: text/plain; charset="iso-8859-1" Tom, A few weeks ago, I sent you the packetnetwork package "draft-scoggins-megaco-pktnetpkg-00.txt", as a join-effort from Mike and myself, for posting to IETF Megaco site. I didn't see it on the web. I am sending it to the list now. Would you please post it on the web? We would like to get some comments and then have the final call. Regards, Sophia & Mike <> ------_=_NextPart_001_01C0084D.42968A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Packet Network Package

Tom,


A few weeks ago, I sent you the = packetnetwork package = "draft-scoggins-megaco-pktnetpkg-00.txt", as a join-effort = from Mike and myself, for posting to IETF Megaco site. I didn't see it = on the web. I am sending it to the list now. Would you please post it = on the web? We would like to get some comments and then have the final = call.


Regards, Sophia & Mike

= <<draft-scoggins-megaco-pktnetpkg-00.txt>>

------_=_NextPart_001_01C0084D.42968A80-- ------_=_NextPart_000_01C0084D.42968A80 Content-Type: text/plain; name="draft-scoggins-megaco-pktnetpkg-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-scoggins-megaco-pktnetpkg-00.txt" Content-Transfer-Encoding: quoted-printable Internet Draft Sophia Scoggins C. Michael Brown Nortel Networks Aug. 2, 2000 Document: draft-scoggins-megaco-pktnetpkg-00.txt Category: Informational Packetnetwork Package for Megaco/H.248 Status of this Memo This document is an Internet-Draft and is in full conformance with all=20 provisions of Section 10 of RFC2026 [ ].=20 Internet-Drafts are working documents of the Internet Engineering Task = Force=20 (IETF), its areas, and its working groups. Note that other groups may = also=20 distribute working documents as Internet-Drafts. Internet-Drafts are = draft=20 documents valid for a maximum of six months and may be updated, = replaced, or=20 obsoleted by other documents at any time. It is inappropriate to use = Internet-=20 Drafts as reference material or to cite them other than as "work in = progress."=20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html. 1. Abstract This document provides a proposed package for bearer independent packet networks. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", = "SHOULD",=20 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document = are to=20 be interpreted as described in RFC-2119 [ ]. 3. Packetnetwork package The package hierarchy should be Network | =20 +-----PacketNetwork | +----- ATM IP At the PacketNetwork level, we want to be generic so that it does not = matter=20 what type of bearer service is. This is particular good in terms of = separation=20 of call processing and bearere connection control. It leaves the MGC = only has=20 knowledge of the call processing, but not bearer connection control.=20 If any MGC needs bearer specific knowledge for call control, it can = derive the bearer specific package from the PacketNetwork, as showned above, to be = 'ATM package' or 'IP package' as an extension to the PacketNetwork. 1. PacketNetwork Package PackageID: pkt (0x ????) Version: 1 Extends: Network Package version 1 This package is used to support packet network connection without = knowledge=20 of the underlying bearer type. A connection-oriented network and a connectionless network have = different characteristics. Further refinement of the network characteristics = can be defined as an extension to this pkt package. =20 For example, 'eecid' can be used for connection-oriented network, = while for connectionless network, such as IP, a pair of RTP ports are = chosen. In that case, 'eecid' can still be used to identify this pair of RTP = ports. Note that there are many ways to choose the RTP ports. One way is = to have the originating MG chooses both RTP ports for sending and = receiving, and the terminating MG uses them. Another way is to have the = originating MG chooses just a receiving RTP port and the terminating MG chooses = another RTP port as its receiving port and as the originating MG's sending = port. 1.1. Properties None. 1.2. Events 1.2.1 Connection Established This event can be used to indicate that the bearer connection is = ready. In the case of connection-less, such as IP network, this event means=20 that the RTP ports have been reserved. =20 Event ID: coav, 0x ???? Detects the establishment of packet connection EventDescriptor parameter:=20 ParameterName: eecid (optional) ParameterID: eecid, 0x?? Type: integer Possible values: Random number ObservedEventsDescriptor parameters: None. =20 1.2.2. Disconnection This event indicates that either the connection has been released, or the MG has not been successful to establish a connection. In = the case the MG not successful to establish a connection, it should not = be treated as failure. EventID: disc, 0x ???? Detects the termination of packet connection EventDescriptor parameter: None. ObservedEventsDescriptor parameters:=20 ParameterName: reason ParameterID: reason, 0x?? Type: integer Possible values: disconnection reason=20 1.23. Failure EventID: of, 0x ???? Detects failure of packet connection EventDescriptor parameter: None. ObservedEventsDescriptor parameters: None ParameterName: reason ParameterID: reason, 0x?? Type: integer Possible values: failure reason=20 1.3. Signals: =20 1.3.1 Establish a Connection This signal explicitly requests to establish a connection. In the=20 case of IP network, eecid is not needed. Signal ID: conn, 0x ???? Establish a packet connection SignalDescriptor parameter:=20 ParameterName: eecid (optional) ParameterID: eecid, 0x?? Type: a previous generated random number Possible values: Random number ObservedEventsDescriptor parameters: None. =20 1.3.2. Disconnection Signal ID: cont, 0x ???? Terminate the packet connection SignaltDescriptor parameter:=20 ParameterName: eecid ParameterID: eecid, 0x?? Type: a previous generated random number Possible values: disconnection reason=20 1.4. Statistics Packet sent StatisticID: pkts Type: 64 bit integer Possible Value: any integer in the range. Packet Received StatisticsID: pktr Type: 64 bit integer Possible Value: any integer in the range. Packet Dropped StatisticsID: pktd Type: 64 bit integer Possible Value: any integer in the range. =20 2. Acknowledgments None 3. Author's Addresses Sophia Scoggins Nortel Networks 4008 Chapel Hill Road Research Triangle Park, NC USA 27709 Phone: (919) 991-2182 Email: scoggins@nortelnetworks.com 4. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This = document=20 and translations of it may be copied and furnished to others, and = derivative=20 works that comment on or otherwise explain it or assist in its = implementation=20 may be prepared, copied, published and distributed, in whole or in = part,=20 without restriction of any kind, provided that the above copyright = notice and=20 this paragraph are included on all such copies and derivative works. = However,=20 this document itself may not be modified in any way, such as by = removing the=20 copyright notice or references to the Internet Society or other = Internet=20 organizations, except as needed for the purpose of developing Internet=20 standards in which case the procedures for copyrights defined in the = Internet=20 Standards process must be followed, or as required to translate it into = languages other than English. The limited permissions granted above = are=20 perpetual and will not be revoked by the Internet Society or its = successors or=20 assigns. This document and the information contained herein is = provided on an=20 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING = TASK FORCE=20 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED = TO ANY=20 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY = RIGHTS OR=20 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR = PURPOSE." 5. Expiration Date This memo is filed as , and = expires=20 Feburary 3, 2001. ------_=_NextPart_000_01C0084D.42968A80-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 15:50:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03653 for ; Thu, 17 Aug 2000 15:50:50 -0400 (EDT) Received: from standards (47.234.32.16:2064) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8927A@standards.nortelnetworks.com>; Thu, 17 Aug 2000 15:36:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18060 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 15:36:01 -0400 Received: from mail.yourdomain.com (m319-mp1-cvx1a.man.ntl.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89233@standards.nortelnetworks.com>; Thu, 17 Aug 2000 15:25:59 -0400 Message-ID: Date: Thu, 17 Aug 2000 15:36:01 -0400 Reply-To: announce@LEISUREWEBCAMS.COM Sender: "Media Gateway Control (megaco)" From: announce@LEISUREWEBCAMS.COM Subject: LeisureWebcams.com - See the World To: MEGACO@STANDARDS.NORTELNETWORKS.COM LeisureWebcams.com is a recently launched website specialising in providing free LIVE access to over 1,500 webcams and 2,000 Tourist Offices world wide. Check it out:- http://www.leisurewebcams.com/ This offers you the chance to check out live and frequently updated images of your chosen location through the webcams and get detailed local knowledge through the Tourist Offices. Along with booking holidays direct through our travel partner, there is the opportunity to sell your unwanted clothes and equipment through our free Swap Shop. There is a lot to see, so if you have enjoyed your trip through our site, do tell your friends and let us know through 'Your Views'. If you have any suggestions for the site, or queries, please feel free to contact me at cy@LeisureWebcams.com. I look forward to hearing from you. Kind regards, Charlie Yates MARKETING DIRECTOR LeisureWebcams.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 16:02:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03835 for ; Thu, 17 Aug 2000 16:02:11 -0400 (EDT) Received: from standards (47.234.32.16:2064) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB892E1@standards.nortelnetworks.com>; Thu, 17 Aug 2000 15:49:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18288 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 15:49:26 -0400 Received: from qhars002.nortel.com (47.101.112.102:59594) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB892E0@standards.nortelnetworks.com>; Thu, 17 Aug 2000 15:49:25 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Thu, 17 Aug 2000 21:01:02 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Thu, 17 Aug 2000 14:32:43 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 17 Aug 2000 14:29:35 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480C42@zcard00g.ca.nortel.com> Date: Thu, 17 Aug 2000 14:29:29 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Virtual MGs and MID X-To: Bharat Kaul To: MEGACO@STANDARDS.NORTELNETWORKS.COM There is a distinction between the conversation at the application level and the connection at transport level. If the MG provides an alternate address in ServiceChangeAddress, it is not telling the MGC to initiate a new session at that alternate address, merely that that is where the current conversation should be continued. Remeber, the MG is controlling this -- the MGC is not imposing on it the requirement to be a TCP server. -----Original Message----- From: Bharat Kaul [mailto:bharat@trillium.com] Sent: Wednesday, August 16, 2000 1:59 PM To: Taylor, Tom-PT [NORSE:B901:EXCH]; megaco@standards.nortelnetworks.com Cc: Bharat Kaul Subject: RE: Virtual MGs and MID Hi Tom, I believe in previous discussions on the mailing list and the philosophy of the protocol that MG always initiates conversation, MG providing ServiceChangeAddress for TCP transport had been ruled out. Providing ServiceChangeAddress for TCP transport implies MGC initiates connection or in other words MG has to have TCP Servers. References for above discussions are give at the end of this email. Is this the current understanding of the protocol ? If yes, I think we should add a line or two in errata which clarifies some of the questions asked with respect to TCP transport and ServiceChange. Atleast pooling the references given below, it does seem like a nice thing to do :) On a side note, if MG is so particular about the port where it wants MGC to send commands to it, the MG might as well use the same port for establishing the TCP connection to the MGC and do away with ServiceChange address and still adhere to "MG Initiates" philosophy. [PTT] Yes, that is what I would expect. Secondly, I agree with you that the MID should be consistent across a control session. However, the example in Appendix A where MG1 is sending commands is not consistent with this idea. So may be in our errata we should fix that and additionally have a line or two in standards or errata which says, " The MID is constant for the duration of a control session". - Bharat REFERENCES Mail on Oct 6, 1999 with subject as "TCP as transport". Mail on May 30, 2000 with subject as "TCP transport /ServiceChange Command" Mail on June 27, 2000 with subject as "MG Service Change w.r.t. TCP as transport" Mail on July 6, 2000 with subject as "MG Service Change w.r.t. TCP as transport" -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Wednesday, August 16, 2000 6:41 AM To: 'Bharat Kaul'; megaco@standards.nortelnetworks.com Subject: RE: Virtual MGs and MID My own views below. > -----Original Message----- > From: Bharat Kaul [ mailto:bharat@TRILLIUM.COM ] > Sent: Monday, August 14, 2000 6:26 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Virtual MGs and MID > > > there are a few things which need to be addressed. > > ISSUE 1: > ---------- > > Flemming mentioned that "port" in MID indicates where the > commands should be > sent. However, my understanding is different and is given below. > [PTT] Responses must be sent back to where requests came from. For IP transport, the source is presumably derived from the IP header. The primary function of the MID is therefore to provide a logical MG identifier which serves as a handle to the control session context. > If MG needs to indicate to MGC where to send the commands, it > will include a > ServiceChange Address in its ServiceChange message and > thereby indicates to > MGC where to send the commands. And this is possible only for > UDP transport. > For TCP transport, MGC uses the same connection as > established by the MG. [PTT] For TCP transport, I would think that a new ServiceChangeAddress would indicate that the MGC should establish a TCP connection to the new address. It's not clear in general why an MG would do this, but perhaps as part of a failover strategy it might do so. > > MGC can also instruct MG to send commands to a particular port by > Redirection. > > So at this point, I myself don't understand what "PORT" in > MID signifies. > Clarifications are appreciated. > > > ISSUE 2: > ---------- > > MID in standards for IPV4 network is IPAddress [optional port]. So > possibility is that in some messages from a entity port is > present and in > some it is not. > > In examples shown in the standard (Appendix A), the MG1 is not using > consistent MID i.e. in one case it doesn't use "port" in MID > and other times > it does. From MGC point of view, how does one ensure that it > is the same MG > ? > > By the same token, what stops any MG from using the UDP port > of transmission > as port number in MID. > > This leads to a problem that at MGC side that MID for a > single MG can vary > (as examples show) and in case of virtual MG using UDP > transport, there is > no way poor MGC can distinguish between them. > [PTT] If I am correct in my view that the MId serves as a logical identifier, it must be consistent throughout the same control session. > > ISSUE 3: > ---------- > > In case of TCP transport, how does one distinguish between a single MG > establishing multiple connections to the MGC and virtual MGs > establishing > TCP connections. Note that at the time of establishing TCP > Connection, MGC > has no way of knowing which case it is handling ? Can anyone > shed some light > in this area too ? > [PTT] Again, if I am correct in my interpretation of MId, it identifies the logical MG, so the MGC can distinguish the two cases by comparing MIds. It could also do so by noting which terminations each control connection supports. > > - Thanks > Bharat > > > > -----Original Message----- > From: John Segers [ mailto:jsegers@LUCENT.COM ] > Sent: Monday, August 14, 2000 2:54 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Re: Virtual MGs and MID > > > Flemming, > > I think that I'm missing the point. > > Here's how I understood it to work. MGs and MGCs alike include an MId > in messages they send, including port number when necessary, > thus making > MId unique if different ports are used for communication with > different > (virtual) MGs. Is there a catch? > > Cheers, > > John > > Flemming Andreasen wrote: > > > > I'm not so sure it's that simple. The port number the MG > indicates is for > > receiving messages, not sending. Furthermore, I thought mId would be > unique > > thereby enabling the MGC to detect duplicate transactions > by looking at > the > > combination of mId and TransactionId (as specified in > D.1.1). If that's > not the > > case, we have another problem. > > > > -- Flemming > > > > John Segers wrote: > > > > > Bharat, > > > > > > Only the IP address of the virtual MGs would be the same; > they can be > > > distinguished by port number. > > > > > > This scheme works by virtue of the fact that (virtual) > MGs initiate the > > > registration procedure and can inform the MGC of the port > number they > > > want to use in the first message (servicechange). > > > > > > Cheers, > > > > > > John > > > > > > Bharat Kaul wrote: > > > > > > > > I need a clarification regarding use of MID in virtual MG case. > > > > > > > > First consider a case where virtual MGs are controlled > by the same MGC > (i.e. > > > > in commands from MGC the MID is constant to all these > MGs) and the > transport > > > > used is UDP. How do we identify the virtual MG in a > PHYSICAL MG to > which the > > > > command from the MGC is destined to ? > > > > > > > > Secondly, on MGC side for UDP transport, can all these > MGs use the > same MID > > > > (like www.example.net) ? If yes, then we have the same > identification > > > > problem on MGC side too ? I am not clear about the MID > that a virtual > MG > > > > should fill in its messages to MGC to identify itself > uniquely i.e. > how are > > > > MID's for a virtual MG and non-virtual MG different > while sending > messages > > > > to the MGC ? > > > > > > > > Clarifications are appreciated. > > > > > > > > - Thanks > > > > Bharat > > > > > > > > > -------------------------------------------------------------- > -------------- > > > > ------- > > > > Bharat Kaul; Trillium > Digital Systems > Inc. > > > > mailto:bharat@trillium.com 12100 Wilshire Blvd, > > > > Phone: +1-310-442-9222 Los Angeles, CA - 90025. > > > > Fax: +1-310-442-1162 http://www.trillium.com > > > > > > -- > > > John Segers email: > jsegers@lucent.com > > > Lucent Technologies > Room HE 303 > > > Dept. Forward Looking Work phone: > +31 35 687 4724 > > > P.O. Box 18, 1270 AA Huizen fax: > +31 35 687 5954 > > > > -- > > Flemming Andreasen Phone: +1 732 452 1667 > > Cisco Systems Fax: +1 240 359 5839 > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 16:30:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04132 for ; Thu, 17 Aug 2000 16:30:07 -0400 (EDT) Received: from standards (47.234.32.16:2064) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8930F@standards.nortelnetworks.com>; Thu, 17 Aug 2000 16:17:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18348 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 16:17:13 -0400 Received: from qhars002.nortel.com (47.101.112.102:60137) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8930D@standards.nortelnetworks.com>; Thu, 17 Aug 2000 16:17:12 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Thu, 17 Aug 2000 21:28:33 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Thu, 17 Aug 2000 15:08:25 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 17 Aug 2000 15:07:42 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480C45@zcard00g.ca.nortel.com> Date: Thu, 17 Aug 2000 15:07:34 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Packet Network Package X-To: Sophia Scoggins X-cc: Michael Brown To: MEGACO@STANDARDS.NORTELNETWORKS.COM The proper way to provide new material to the WG is via an Internet Draft. If your earlier submission to internet-drafts@ietf.org failed, please try again. > -----Original Message----- > From: Scoggins, Sophia [NC1:3T18:EXCH] > Sent: Thursday, August 17, 2000 9:16 AM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: Brown, Michael [NC1:3T19:EXCH]; > 'MEGACO@STANDARDS.NORTELNETWORKS.COM' > Subject: Packet Network Package > > Tom, > > > A few weeks ago, I sent you the packetnetwork package > "draft-scoggins-megaco-pktnetpkg-00.txt", as a join-effort from Mike and > myself, for posting to IETF Megaco site. I didn't see it on the web. I am > sending it to the list now. Would you please post it on the web? We would > like to get some comments and then have the final call. > > > Regards, Sophia & Mike > > << File: draft-scoggins-megaco-pktnetpkg-00.txt >> From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 09:58:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28558 for ; Fri, 18 Aug 2000 09:57:54 -0400 (EDT) Received: from standards (47.234.32.16:1875) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8969C@standards.nortelnetworks.com>; Fri, 18 Aug 2000 9:45:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19524 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 09:45:14 -0400 Received: from qhars002.nortel.com (47.101.112.102:53583) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8969B@standards.nortelnetworks.com>; Fri, 18 Aug 2000 9:45:14 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Fri, 18 Aug 2000 14:57:07 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Fri, 18 Aug 2000 08:49:05 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 18 Aug 2000 08:50:58 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD11480C51@zcard00g.ca.nortel.com> Date: Fri, 18 Aug 2000 08:50:56 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: RFC Numbers To: MEGACO@STANDARDS.NORTELNETWORKS.COM draft-ietf-megaco-protocol-08.txt will be published as RFC 2885. draft-ietf-megaco-errata-03.txt will be published as RFC 2886. As noted on this list earlier, the IESG has approved draft-ietf-megaco-merged-01.txt. When published, this will obsoleted the above two RFCs. Tom Taylor From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 10:11:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28771 for ; Fri, 18 Aug 2000 10:11:37 -0400 (EDT) Received: from standards (47.234.32.16:1875) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB896BD@standards.nortelnetworks.com>; Fri, 18 Aug 2000 9:58:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19562 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 09:58:50 -0400 Received: from qhars002.nortel.com (47.101.112.102:55744) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB896BC@standards.nortelnetworks.com>; Fri, 18 Aug 2000 9:58:49 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Fri, 18 Aug 2000 15:10:39 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Fri, 18 Aug 2000 09:05:57 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 18 Aug 2000 09:05:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0091D.4C4648B0" Message-ID: <28560036253BD41191A10000F8BCBD11480C52@zcard00g.ca.nortel.com> Date: Fri, 18 Aug 2000 09:05:00 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: draft-ietf-megaco-merged-01.txt X-To: Naren Tulpule To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01C0091D.4C4648B0 Content-Type: text/plain; charset="iso-8859-1" I left off responding to this until I saw other reactions. Would anyone else care to comment on the proposition that the primary function of mId in the message header is to serve as a logical handle to the control session, rather than as an actual address to which responses must be sent? I see Naren's question (b) as one way to achieve differentiation of virtual MGs but not necessarily the only one, so question (a) is the key one. One other response below. > -----Original Message----- > From: Naren Tulpule [mailto:naren@TRILLIUM.COM] > Sent: Wednesday, August 16, 2000 2:06 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: draft-ietf-megaco-merged-01.txt > > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > > > > 1. I think that there is an error in Appendix A, step 15. The > > mId should be > > [125.125.125.111]. > > > [PTT] > Certainly that would be consistent with the mId shown in step 17. > > [[ NAREN ]] Is it the consensus now that > a) MID _MUST_ be unique for an MG or MGC, and treated as a > logical handle > irrespective of any changes in ports etc; and > b) Virtual MGs _MUST_ distinguish themselves by a mandatory > port part in the > MID; and this "IP-address/name + port" MID _MUST_ not change > (as in (a)). > I am surprized the protocol designers did not fix even basic > things like how > an MG or MGC identifies a peer from MID received in a > message. (But perhaps > that's an "implementation detail", best left out of protocol specs :-) > > [PTT] > The ABNF is more general and includes the ASN.1 as a > possibility. Basically > the ABNF allows you to use either SDP or Annex C, whereas the > ASN.1 assumes > Annex C plus whatever packages come along to augment or replace it. > > [[ NAREN ]] Can you please clarify how ABNF allows us to use > annex C? I > thought annex C was strictly for binary encoding; and SDP for > text encoding; > and that ABNF only specified text encoding. Are you allowed > to embed binary > info in text? (Certainly if annex A is to be believed, we > have to embed text > strings like digit maps inside the binary but now it's the > other way too?) > Or do you mean some unspecified equivalent of binary ID-value > pairs in text > encoding? > [PTT] I plead guilty. I raised a possibly which is not allowed in the main body of the protocol document. Back a year ago, before we made the restriction, there was a suggestion that binary data would be Base-64 encoded. > -- Naren. > Narendra C. Tulpule SMTS, Trillium Digital Systems > Ph: +1-310-442-9222 Fax: +1-310-442-1162 > 12100 Wilshire Bl #1800 Los Angeles, CA 90025 > ------_=_NextPart_001_01C0091D.4C4648B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-ietf-megaco-merged-01.txt

I left off responding to this until I saw other = reactions.  Would anyone else care to comment on the proposition = that the primary function of mId in the message header is to serve as a = logical handle to the control session, rather than as an actual address = to which responses must be sent?  I see Naren's question (b) as = one way to achieve differentiation of virtual MGs but not necessarily = the only one, so question (a) is the key one.

One other response below.

> -----Original Message-----
> From: Naren Tulpule [mailto:naren@TRILLIUM.COM]=
> Sent: Wednesday, August 16, 2000 2:06 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: = draft-ietf-megaco-merged-01.txt
>
>
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.C= OM]
> >
> > 1. I think that there is an error in = Appendix A, step 15. The
> > mId should be
> > [125.125.125.111].
> >
> [PTT]
> Certainly that would be consistent with the mId = shown in step 17.
>
> [[ NAREN ]] Is it the consensus now that
> a) MID _MUST_ be unique for an MG or MGC, and = treated as a
> logical handle
> irrespective of any changes in ports etc; = and
> b) Virtual MGs _MUST_ distinguish themselves by = a mandatory
> port part in the
> MID; and this "IP-address/name + = port" MID _MUST_ not change
> (as in (a)).
> I am surprized the protocol designers did not = fix even basic
> things like how
> an MG or MGC identifies a peer from MID = received in a
> message. (But perhaps
> that's an "implementation detail", = best left out of protocol specs :-)
>
> [PTT]
> The ABNF is more general and includes the ASN.1 = as a
> possibility.  Basically
> the ABNF allows you to use either SDP or Annex = C, whereas the
> ASN.1 assumes
> Annex C plus whatever packages come along to = augment or replace it.
>
> [[ NAREN ]] Can you please clarify how ABNF = allows us to use
> annex C? I
> thought annex C was strictly for binary = encoding; and SDP for
> text encoding;
> and that ABNF only specified text encoding. Are = you allowed
> to embed binary
> info in text? (Certainly if annex A is to be = believed, we
> have to embed text
> strings like digit maps inside the binary but = now it's the
> other way too?)
> Or do you mean some unspecified equivalent of = binary ID-value
> pairs in text
> encoding?
>
[PTT] I plead guilty.  I raised a possibly = which is not allowed in the main body of the protocol document.  = Back a year ago, before we made the restriction, there was a suggestion = that binary data would be Base-64 encoded.

> -- Naren.
> Narendra C. Tulpule    SMTS, = Trillium Digital Systems
> Ph: = +1-310-442-9222         &nb= sp;    Fax: +1-310-442-1162
> 12100 Wilshire Bl = #1800         Los Angeles, CA = 90025
>

------_=_NextPart_001_01C0091D.4C4648B0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 10:25:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29032 for ; Fri, 18 Aug 2000 10:25:00 -0400 (EDT) Received: from standards (47.234.32.16:1875) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89722@standards.nortelnetworks.com>; Fri, 18 Aug 2000 10:12:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19693 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 10:12:12 -0400 Received: from qhars002.nortel.com (47.101.112.102:57630) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89721@standards.nortelnetworks.com>; Fri, 18 Aug 2000 10:12:12 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Fri, 18 Aug 2000 15:21:36 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Fri, 18 Aug 2000 09:15:56 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 18 Aug 2000 09:19:28 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD11480C53@zcard00g.ca.nortel.com> Date: Fri, 18 Aug 2000 09:19:23 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Need clarification on topology X-To: Xiaotao Wu To: MEGACO@STANDARDS.NORTELNETWORKS.COM You're right, and it's a bug. The ASN.1 shows ContextRequest ::= SEQUENCE { priority INTEGER(0..15) OPTIONAL, emergency BOOLEAN OPTIONAL, topologyReq SEQUENCE OF TopologyRequest OPTIONAL, ... } which meets the intent by allowing multiple triples. I'll raise this one in Portland next week when Q. 14/16 are considering the draft Implementor's Guide. > -----Original Message----- > From: Xiaotao Wu [mailto:xiaotaow@CS.COLUMBIA.EDU] > Sent: Thursday, August 17, 2000 10:48 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Need clarification on topology > > > Hi, > > I have a question for handling the topology. Based on the syntax > definition, every contextRequest can only have one > topologyDescriptor and > every topologyDescriptor can only have one > (termA, termB, direction) triples. So, if I want to specify > the topology > by using more than one triple (e.g., I want to set (termA, termB, > Isolate) and at the same time, set (termA, termB, bothway)), > I need to use > more than one contextRequest to do it, instead of putting all the > topologyDescriptors in one contextRequest, though these > descriptors are > applied to the same context. Is it right? > > Thanks! > > -Xiaotao > > contextRequest = ((contextProperties [COMMA contextAudit]) > / contextAudit) > > contextProperties = contextProperty *(COMMA contextProperty) > > ; at-most-once > contextProperty = (topologyDescriptor / priority / EmergencyToken) > .... > > topologyDescriptor = TopologyToken LBRKT terminationA COMMA > terminationB COMMA topologyDirection RBRKT > terminationA = TerminationID > terminationB = TerminationID > topologyDirection = BothwayToken / IsolateToken / OnewayToken > > > > -Xiaotao > > ==================================================== > Name : Xiaotao Wu (Always available by email!) > Email: xiaotaow@cs.columbia.edu, xw71@columbia.edu > URL : http://www.cs.columbia.edu/~xiaotaow > Work Phone: (212)939-7087, Home Phone: (212)795-1963 > Office: Room 623, Schapiro (CEPSR), West 120th > ==================================================== > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 11:09:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29967 for ; Fri, 18 Aug 2000 11:09:24 -0400 (EDT) Received: from standards (47.234.32.16:1875) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8982D@standards.nortelnetworks.com>; Fri, 18 Aug 2000 10:55:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19856 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 10:55:30 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB897A3@standards.nortelnetworks.com>; Fri, 18 Aug 2000 10:45:30 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id HAA23724; Fri, 18 Aug 2000 07:57:26 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480C52@zcard00g.ca.nortel.com> Content-Type: multipart/alternative; boundary="------------11B722FB78DCA51504A05CE9" Message-ID: <399D4FD3.CC9CBE2@cisco.com> Date: Fri, 18 Aug 2000 11:01:40 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: draft-ietf-megaco-merged-01.txt X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------11B722FB78DCA51504A05CE9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tom-PT Taylor wrote: > > > I left off responding to this until I saw other reactions. Would > anyone else care to comment on the proposition that the primary > function of mId in the message header is to serve as a logical handle > to the control session, rather than as an actual address to which > responses must be sent? I would agree with that. Requiring responses to be sent from the same port as commands are received on is a rather undesirable limitation IMO. -- Flemming > I see Naren's question (b) as one way to achieve differentiation of > virtual MGs but not necessarily the only one, so question (a) is the > key one. > > One other response below. > > > -----Original Message----- > > From: Naren Tulpule [mailto:naren@TRILLIUM.COM] > > Sent: Wednesday, August 16, 2000 2:06 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: draft-ietf-megaco-merged-01.txt > > > > > > -----Original Message----- > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > > > > > > 1. I think that there is an error in Appendix A, step 15. The > > > mId should be > > > [125.125.125.111]. > > > > > [PTT] > > Certainly that would be consistent with the mId shown in step 17. > > > > [[ NAREN ]] Is it the consensus now that > > a) MID _MUST_ be unique for an MG or MGC, and treated as a > > logical handle > > irrespective of any changes in ports etc; and > > b) Virtual MGs _MUST_ distinguish themselves by a mandatory > > port part in the > > MID; and this "IP-address/name + port" MID _MUST_ not change > > (as in (a)). > > I am surprized the protocol designers did not fix even basic > > things like how > > an MG or MGC identifies a peer from MID received in a > > message. (But perhaps > > that's an "implementation detail", best left out of protocol specs > :-) > > > > [PTT] > > The ABNF is more general and includes the ASN.1 as a > > possibility. Basically > > the ABNF allows you to use either SDP or Annex C, whereas the > > ASN.1 assumes > > Annex C plus whatever packages come along to augment or replace it. > > > > [[ NAREN ]] Can you please clarify how ABNF allows us to use > > annex C? I > > thought annex C was strictly for binary encoding; and SDP for > > text encoding; > > and that ABNF only specified text encoding. Are you allowed > > to embed binary > > info in text? (Certainly if annex A is to be believed, we > > have to embed text > > strings like digit maps inside the binary but now it's the > > other way too?) > > Or do you mean some unspecified equivalent of binary ID-value > > pairs in text > > encoding? > > > [PTT] I plead guilty. I raised a possibly which is not allowed in the > main body of the protocol document. Back a year ago, before we made > the restriction, there was a suggestion that binary data would be > Base-64 encoded. > > > -- Naren. > > Narendra C. Tulpule SMTS, Trillium Digital Systems > > Ph: +1-310-442-9222 Fax: +1-310-442-1162 > > 12100 Wilshire Bl #1800 Los Angeles, CA 90025 > > -- Flemming Andreasen Cisco Systems --------------11B722FB78DCA51504A05CE9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Tom-PT Taylor wrote:

 

I left off responding to this until I saw other reactions.  Would anyone else care to comment on the proposition that the primary function of mId in the message header is to serve as a logical handle to the control session, rather than as an actual address to which responses must be sent?

I would agree with that. Requiring responses to be sent from the same port as commands are received on is a rather undesirable limitation IMO.

-- Flemming
 

I see Naren's question (b) as one way to achieve differentiation of virtual MGs but not necessarily the only one, so question (a) is the key one.

One other response below.

> -----Original Message-----
> From: Naren Tulpule [mailto:naren@TRILLIUM.COM]
> Sent: Wednesday, August 16, 2000 2:06 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: draft-ietf-megaco-merged-01.txt
>
>
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> >
> > 1. I think that there is an error in Appendix A, step 15. The
> > mId should be
> > [125.125.125.111].
> >
> [PTT]
> Certainly that would be consistent with the mId shown in step 17.
>
> [[ NAREN ]] Is it the consensus now that
> a) MID _MUST_ be unique for an MG or MGC, and treated as a
> logical handle
> irrespective of any changes in ports etc; and
> b) Virtual MGs _MUST_ distinguish themselves by a mandatory
> port part in the
> MID; and this "IP-address/name + port" MID _MUST_ not change
> (as in (a)).
> I am surprized the protocol designers did not fix even basic
> things like how
> an MG or MGC identifies a peer from MID received in a
> message. (But perhaps
> that's an "implementation detail", best left out of protocol specs :-)
>
> [PTT]
> The ABNF is more general and includes the ASN.1 as a
> possibility.  Basically
> the ABNF allows you to use either SDP or Annex C, whereas the
> ASN.1 assumes
> Annex C plus whatever packages come along to augment or replace it.
>
> [[ NAREN ]] Can you please clarify how ABNF allows us to use
> annex C? I
> thought annex C was strictly for binary encoding; and SDP for
> text encoding;
> and that ABNF only specified text encoding. Are you allowed
> to embed binary
> info in text? (Certainly if annex A is to be believed, we
> have to embed text
> strings like digit maps inside the binary but now it's the
> other way too?)
> Or do you mean some unspecified equivalent of binary ID-value
> pairs in text
> encoding?
>
[PTT] I plead guilty.  I raised a possibly which is not allowed in the main body of the protocol document.  Back a year ago, before we made the restriction, there was a suggestion that binary data would be Base-64 encoded.

> -- Naren.
> Narendra C. Tulpule    SMTS, Trillium Digital Systems
> Ph: +1-310-442-9222              Fax: +1-310-442-1162
> 12100 Wilshire Bl #1800         Los Angeles, CA 90025
>

--
Flemming Andreasen
Cisco Systems
  --------------11B722FB78DCA51504A05CE9-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 22 06:35:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00071 for ; Tue, 22 Aug 2000 06:35:17 -0400 (EDT) Received: from standards (47.234.32.16:4415) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B0E7@standards.nortelnetworks.com>; Tue, 22 Aug 2000 6:22:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28465 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Aug 2000 06:22:15 -0400 Received: from qhars002.nortel.com (47.101.112.102:61761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B0E6@standards.nortelnetworks.com>; Tue, 22 Aug 2000 6:22:14 -0400 Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Tue, 22 Aug 2000 11:32:57 +0100 Received: from zmers013 (actually zmers013.ca.nortel.com) by zrtps06s.us.nortel.com; Tue, 22 Aug 2000 06:32:12 -0400 Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by zmers013; Tue, 22 Aug 2000 06:32:06 -0400 Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA15261 for ; Tue, 22 Aug 2000 13:35:15 +0300 (IDT) Received: from tsyspc13 by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id NAA25302; Tue, 22 Aug 2000 13:35:14 +0300 (IDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C00C3D.3DD85520" 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 X-Orig: Message-ID: <000d01c00c2c$7a67ef20$6f0de28d@elex.co.il> Date: Tue, 22 Aug 2000 13:31:13 +0200 Reply-To: "Bentov, Kohava" Sender: "Media Gateway Control (megaco)" From: "Bentov, Kohava" Organization: Telrad Subject: transactionResponseAck ? To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C00C3D.3DD85520 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi all, In Appendix A (the call flow Example), there are no = transactionResponseAck messages between the MGC =20 and its MGs.=20 Is the transactionResponseAck optional ? In section B.2 (ABNF specification) the following is written: --------------------------------------- transactionList =3D 1*( transactionRequest / transactionReply /=20 transactionPending / = transactionResponseAck ) ;Use of response acks is dependent on underlying transport --------------------------------------- Regarding the remark:=20 Does it mean that we'll use transactionResponseAck = when the transport layer=20 is UDP and we'll not send/receive = transactionResponseAck when the transport layer is TCP ? If not, what does it mean ? Thanks in advance, Bentov Kohava S/W Development Telrad Networks E-mail: kohava.bentov@telrad.co.il ------=_NextPart_000_000A_01C00C3D.3DD85520 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi all,
 
    In Appendix A (the = call flow=20 Example), there are no=20 transactionResponseAck  messages between = the=20 MGC 
    and its MGs. 
    Is the=20 transactionResponseAck optional=20 ?
 
    In section B.2 (ABNF = specification) the following is written:
 
---------------------------------------
    transactionList =3D = 1*(=20 transactionRequest / transactionReply /
          &nbs= p;            = ;   =20       transactionPending / = transactionResponseAck=20 )

  ;Use of response acks is dependent on = underlying=20 transport

---------------------------------------
 
    Regarding the = remark:=20
          &nbs= p;         =20 Does it mean that we'll use transactionResponseAck when = the=20 transport layer
          &nbs= p;          is=20 UDP and we'll not send/receive transactionResponseAck = when the=20 transport layer is TCP ?
 
         &n= bsp;          = =20 If not, what does it mean ?
 
 
  Thanks in=20 advance,
       Bentov=20 Kohava
       S/W=20 Development
       Telrad=20 Networks
        E-mail: = kohava.bentov@telrad.co.il
------=_NextPart_000_000A_01C00C3D.3DD85520-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 22 14:14:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12366 for ; Tue, 22 Aug 2000 14:14:11 -0400 (EDT) Received: from standards (47.234.32.16:2437) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B416@standards.nortelnetworks.com>; Tue, 22 Aug 2000 14:01:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29510 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Aug 2000 14:01:07 -0400 Received: from qhars002.nortel.com (47.101.112.102:52008) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B415@standards.nortelnetworks.com>; Tue, 22 Aug 2000 14:01:06 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Tue, 22 Aug 2000 19:13:15 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Tue, 22 Aug 2000 14:12:59 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 22 Aug 2000 14:12:58 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480C6D@zcard00g.ca.nortel.com> Date: Tue, 22 Aug 2000 14:12:35 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: transactionResponseAck ? X-To: "Bentov, Kohava [Partner:LOD:Telrad]" To: MEGACO@STANDARDS.NORTELNETWORKS.COM TransactionResponseAck is used only with UDP/ALF. See Annex D.1. -----Original Message----- From: Bentov, Kohava [Partner:LOD:Telrad] Sent: Tuesday, August 22, 2000 7:31 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: transactionResponseAck ? Hi all, In Appendix A (the call flow Example), there are no transactionResponseAck messages between the MGC and its MGs. Is the transactionResponseAck optional ? In section B.2 (ABNF specification) the following is written: --------------------------------------- transactionList = 1*( transactionRequest / transactionReply / transactionPending / transactionResponseAck ) ;Use of response acks is dependent on underlying transport --------------------------------------- Regarding the remark: Does it mean that we'll use transactionResponseAck when the transport layer is UDP and we'll not send/receive transactionResponseAck when the transport layer is TCP ? If not, what does it mean ? Thanks in advance, Bentov Kohava S/W Development Telrad Networks E-mail: kohava.bentov@telrad.co.il From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 22 20:28:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18012 for ; Tue, 22 Aug 2000 20:28:58 -0400 (EDT) Received: from standards (47.234.32.16:1797) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B530@standards.nortelnetworks.com>; Tue, 22 Aug 2000 20:16:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29862 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Aug 2000 20:16:09 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B52F@standards.nortelnetworks.com>; Tue, 22 Aug 2000 20:16:08 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA17779; Tue, 22 Aug 2000 20:28:24 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA21972; Tue, 22 Aug 2000 20:28:25 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 22 Aug 2000 20:28:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00C99.0C897B00" Message-ID: <4FBEA8857476D311A03300204840E1CF017065B7@whq-msgusr-02.fore.com> Date: Tue, 22 Aug 2000 20:28:24 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: transactionResponseAck ? X-To: "Bentov, Kohava" To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01C00C99.0C897B00 Content-Type: text/plain; charset="windows-1255" transactionResponseAck would be used if the transport required it. For example, UDP would need it. A reliable transport, such as TCP, would not require it. I'd suggest that, as with most IETF protocols, all implementations should accept transactionResponseAck regardless of what transport is used. Thus be conservative in what you send, liberal in what you accept. Brian -----Original Message----- From: Bentov, Kohava [mailto:kohava.bentov@telrad.co.il] Sent: Tuesday, August 22, 2000 7:31 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: transactionResponseAck ? Hi all, In Appendix A (the call flow Example), there are no transactionResponseAck messages between the MGC and its MGs. Is the transactionResponseAck optional ? In section B.2 (ABNF specification) the following is written: --------------------------------------- transactionList = 1*( transactionRequest / transactionReply / transactionPending / transactionResponseAck ) ;Use of response acks is dependent on underlying transport --------------------------------------- Regarding the remark: Does it mean that we'll use transactionResponseAck when the transport layer is UDP and we'll not send/receive transactionResponseAck when the transport layer is TCP ? If not, what does it mean ? Thanks in advance, Bentov Kohava S/W Development Telrad Networks E-mail: kohava.bentov@telrad.co.il ------_=_NextPart_001_01C00C99.0C897B00 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
transactionResponseAck would be used if the = transport=20 required it.  For example, UDP would need it.
A=20 reliable transport, such as TCP, would not require = it.
 
I'd=20 suggest that, as with most IETF protocols, all implementations should = accept=20 transactionResponseAck
regardless of what transport is used.  = Thus be=20 conservative in what you send, liberal in what you = accept.
 
Brian
-----Original Message-----
From: Bentov, Kohava=20 [mailto:kohava.bentov@telrad.co.il]
Sent: Tuesday, August = 22, 2000=20 7:31 AM
To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:=20 transactionResponseAck ?

Hi all,
 
    In Appendix A = (the call flow=20 Example), there are no=20 = transactionResponseAck  messages between= the=20 MGC 
    and = its MGs. 
    Is the=20 transactionResponseAck optional=20 ?
 
    In section B.2 = (ABNF=20 specification) the following is written:
 
---------------------------------------
    transactionList = =3D 1*(=20 transactionRequest / transactionReply /
          &nb= sp;           &nb= sp;   =20       transactionPending / = transactionResponseAck=20 )

  ;Use of response acks is dependent on = underlying=20 transport

---------------------------------------
 
    Regarding the = remark:=20
          &nb= sp;         =20 Does it mean that we'll use transactionResponseAck = when the=20 transport layer
          &= nbsp;          is=20 UDP and we'll not send/receive transactionResponseAck = when=20 the transport layer is TCP ?
 
         &= nbsp;          =20 If not, what does it mean ?
 
 
  Thanks in=20 advance,
       Bentov=20 Kohava
       S/W=20 Development
       Telrad=20 = Networks
        E-mail: = ; kohava.bentov@telrad.co.il
<= /BLOCKQUOTE> ------_=_NextPart_001_01C00C99.0C897B00-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 23 00:25:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22615 for ; Wed, 23 Aug 2000 00:25:07 -0400 (EDT) Received: from standards (47.234.32.16:4180) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B58A@standards.nortelnetworks.com>; Wed, 23 Aug 2000 0:12:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29969 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 23 Aug 2000 00:12:09 -0400 Received: from smtp2.abac.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B589@standards.nortelnetworks.com>; Wed, 23 Aug 2000 0:02:08 -0400 Received: from laptop (ip144.boston5.ma.pub-ip.psi.net [38.26.109.144]) by smtp2.abac.com (8.10.1/8.10.1) with SMTP id e7N4S4Z51465 for megaco@standards.nortelnetworks.com; Tue, 22 Aug 2000 21:28:04 -0700 (PDT) Content-Type: TEXT/PLAIN charset=US-ASCII Message-ID: Date: Tue, 22 Aug 2000 21:28:04 -0700 Reply-To: chris@COLLEGEWAFER.COM Sender: "Media Gateway Control (megaco)" From: chris@COLLEGEWAFER.COM Subject: Si, Ultra-Thin Si (MEMS), GaAs, InP, GaN, PtSi, SOI, Equipment & More... To: MEGACO@STANDARDS.NORTELNETWORKS.COM Visit http://www.collegewafer.com for your free quote, or call (800) 713-9375 or Fax (888)-832-0340!!! E-mail us at sales@collegewafer.com All Ultrathin Si wafers polished two sides with TTV < 3 microns for (MEMS) Applications. 4"N(100) 1-10 ohm-cm 10-100 microns polished two sides in Silicon! New Platinum Silicon (PtSi)price posted! 4" SOI Available! Other Wafers: IN STOCK & READY to SHIP Si, GaAs, Ge, InP, InAs, InSb, GaSb, GaN in 1"-12" diameters. Customer supplied GaAs or Ge can be reclaimed or repolished. Equipment Used Vacuum Deposition Equipment Evaporation Systems CHA/Ion Tech Milling Balzers BAK760 and Spitfire and more. Visit us for details! New! Ask for details at sales@collegewafer.com Contact us for your free quote today! Also visit http://www.thecoveredcall.com learn to pick winning stocks using he CANSLIM method of investing with a covered call twist! To REMOVE yourself from this list please visit http://www.collegewafer.com/contact_us/Remove/remove.html MEMS From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 23 10:06:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11939 for ; Wed, 23 Aug 2000 10:06:39 -0400 (EDT) Received: from standards (47.234.32.16:3471) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B65A@standards.nortelnetworks.com>; Wed, 23 Aug 2000 9:53:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30205 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 23 Aug 2000 09:53:18 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B659@standards.nortelnetworks.com>; Wed, 23 Aug 2000 9:53:17 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20884; Wed, 23 Aug 2000 10:05:17 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA28827; Wed, 23 Aug 2000 10:05:14 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 10:05:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF017065F4@whq-msgusr-02.fore.com> Date: Wed, 23 Aug 2000 10:05:14 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: First Megaco Interop Event -- Registration Closing!! X-To: megaco-interop@fore.com, isc_members@inventures.com, msf-members@msforum.org To: MEGACO@STANDARDS.NORTELNETWORKS.COM I apologize if you get this multiple times. Registration for the first Megaco Interop Event, August 28-31 at the University of New Hampshire's Interoperability Lab will close Wednesday, August 23, 2000 at 6:00 PST. As of today, we have 16(!!!) organizations already signed up, including several test vendors, stack vendors and a wide variety of MG and MGCs. If you were planning to come, but have not completed the signup process, please please visit http://www.tsemantics.com/megaco-interop and fill out the signup form NOW!!!! If there are any problems, please email me ASAP. We will probably not be able to accommodate any unplanned entries due to lack of space, so registration will be required. Brian ------------ Brian Rosen, Office of the CTO Marconi, plc 1000 FORE Drive, Warrendale, PA 15086 (724) 742-6826 mailto:brian.rosen@marconi.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 23 10:23:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12470 for ; Wed, 23 Aug 2000 10:23:50 -0400 (EDT) Received: from standards (47.234.32.16:3471) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B68B@standards.nortelnetworks.com>; Wed, 23 Aug 2000 10:10:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30272 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 23 Aug 2000 10:10:54 -0400 Received: from arianne.ishoni.com (164.164.83.132:2628) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B68A@standards.nortelnetworks.com>; Wed, 23 Aug 2000 10:10:52 -0400 Received: from sarunk (sarunk [192.168.1.96]) by arianne.ishoni.com (8.9.3/8.9.3) with SMTP id TAA18461 for ; Wed, 23 Aug 2000 19:56:47 +0530 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.00.2314.1300 Message-ID: Date: Wed, 23 Aug 2000 20:03:52 +0530 Reply-To: sarunk@ishoni.com Sender: "Media Gateway Control (megaco)" From: Arun Kumar S Subject: Clarification on the MGCP retransmission logic To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, I would like some clarifications on the re-transmission logic that is mentioned in the MGCP RFC2705. I feel that the diagram and the text contradict and hence the need for the clarification. SCENARIO 1 ------------------- When the GW started up it resolved the Call Agent's(CA) address and got a single IP address (interface). Now a command was sent and the CA does not send an ack. What is the expected behaviour of the GW with regard to the re-transmission logic?? The expected behaviour in the GW is, - The GW should retransmit the command Max1 times and query DNS on the retry count reaching Max1 times, or - The GW should retransmit the command Max2 times and then query the DNS to look for any new IP addresses. SCENARIO 2 -------------------- When the GW started up it resolved the CA's domain name into multiple IP addresses (say 3). Now a command is sent to the CA and it does not respond with an ACK. The GW re-transmits the command. The gateway should retransmit the command to the first IP address in the list of IP addresses Max1 times. Once Max1 is reached, - The next IP (2nd) address in the original list is then tried after re-setting the retry-count to zero for Max1 times again. Then the last (3rd) address is again tried for Max2 times before performing a DNS re-lookup. Then retransmissions are carried out in a similar fashion with the new set of addresses. - A DNS query is performed on trying for Max1 times with the first address. Then with the first address in the new set of IP addresses if re-transmission is performed, a re-lookup will again need to be done after re-transmitting for Max1 times and so retry count reaching Max2 times will never occur. Which of the two approaches above is correct?? OR is there any other way in which the retransmission logic should work?? In other words referring to the diagram on page 97 in RFC 2705 how do we interpret "(if N=Max1 or N=Max2 check DNS)"?? What are the conditions under which we should query DNS (Single and multiple IP interface)?? Regards, Arun.S ___________________________________________________ Arun Kumar S ishoni Networks (India) Pvt Ltd (http://www.ishoni.com) ...Broadband for everyone email: sarunk@ishoni.com Phone: +91-80-2292125 (Work) Fax: +91-80-2995545 (Work) From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 23 10:29:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12730 for ; Wed, 23 Aug 2000 10:29:44 -0400 (EDT) Received: from standards (47.234.32.16:3471) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B6B0@standards.nortelnetworks.com>; Wed, 23 Aug 2000 10:16:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30321 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 23 Aug 2000 10:16:52 -0400 Received: from newdev.harvard.edu (newdev.eecs.harvard.edu) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B6AF@standards.nortelnetworks.com>; Wed, 23 Aug 2000 10:16:52 -0400 Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id KAA00230; Wed, 23 Aug 2000 10:29:03 -0400 (EDT) Message-ID: <200008231429.KAA00230@newdev.harvard.edu> Date: Wed, 23 Aug 2000 10:29:03 -0400 Reply-To: Scott Bradner Sender: "Media Gateway Control (megaco)" From: Scott Bradner Subject: Re: Clarification on the MGCP retransmission logic X-To: sarunk@ishoni.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Arun Kumar S wrote: > I would like some clarifications on the re-transmission logic that is ... > mentioned in the MGCP RFC2705 the megaco working group does not deal with MGCP - please contact the authors of the document Scott From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 23 13:52:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19794 for ; Wed, 23 Aug 2000 13:52:46 -0400 (EDT) Received: from standards (47.234.32.16:3767) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B808@standards.nortelnetworks.com>; Wed, 23 Aug 2000 13:39:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30754 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 23 Aug 2000 13:39:47 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B806@standards.nortelnetworks.com>; Wed, 23 Aug 2000 13:29:46 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id KAA28165; Wed, 23 Aug 2000 10:41:34 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <200008231429.KAA00230@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A40DCF.559E5DE1@cisco.com> Date: Wed, 23 Aug 2000 13:45:51 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: Clarification on the MGCP retransmission logic X-To: Scott Bradner To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Scott Bradner wrote: > Arun Kumar S wrote: > > I would like some clarifications on the re-transmission logic that is ... > > mentioned in the MGCP RFC2705 > > the megaco working group does not deal with MGCP - please contact the > authors of the document or "mgcp@pulver.com" -- Flemming > > > Scott -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 23 15:35:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22075 for ; Wed, 23 Aug 2000 15:35:23 -0400 (EDT) Received: from standards (47.234.32.16:1897) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B8AC@standards.nortelnetworks.com>; Wed, 23 Aug 2000 15:22:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30953 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 23 Aug 2000 15:22:18 -0400 Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B8AB@standards.nortelnetworks.com>; Wed, 23 Aug 2000 15:22:18 -0400 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA18590 for ; Wed, 23 Aug 2000 15:34:39 -0400 (EDT) Received: from electric.amc.bell-labs.com (h135-17-7-254.lucent.com [135.17.7.254]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA18580 for ; Wed, 23 Aug 2000 15:34:39 -0400 (EDT) Received: by electric.amc.bell-labs.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 15:34:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 23 Aug 2000 15:34:49 -0400 Reply-To: "Raju, Makaraju" Sender: "Media Gateway Control (megaco)" From: "Raju, Makaraju" Subject: Missing SDP quivalent X-cc: jagadish , John Segers , Sujay Rao To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, Annex C.11 listed out all the SDP equivalents, but there is no equivalent specified for "m" (m= (media name and transport address)). Am I missing something? How do I encode/decode "m"? Thank you Raju & Jagadish From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 23 19:37:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24246 for ; Wed, 23 Aug 2000 19:37:48 -0400 (EDT) Received: from standards (47.234.32.16:3108) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BA93@standards.nortelnetworks.com>; Wed, 23 Aug 2000 19:24:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31590 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 23 Aug 2000 19:24:53 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BA92@standards.nortelnetworks.com>; Wed, 23 Aug 2000 19:24:53 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA06182 for ; Wed, 23 Aug 2000 19:37:11 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA06401 for ; Wed, 23 Aug 2000 19:37:13 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 19:37:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF67876E@whq-msgusr-02.fore.com> Date: Wed, 23 Aug 2000 19:37:12 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: T1/E1/PRI Package To: MEGACO@STANDARDS.NORTELNETWORKS.COM Is anyone working on a T1/E1 package that would deliver such items as alarm levels, etc.? Do we actually need such a thing? Similarly, is there a need for a PRI/PRA package? Is anyone working on it? Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 23 21:04:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25071 for ; Wed, 23 Aug 2000 21:04:46 -0400 (EDT) Received: from standards (47.234.32.16:4938) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BABE@standards.nortelnetworks.com>; Wed, 23 Aug 2000 20:51:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31644 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 23 Aug 2000 20:51:57 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BABD@standards.nortelnetworks.com>; Wed, 23 Aug 2000 20:41:56 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7O0sGw13854; Thu, 24 Aug 2000 02:54:16 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id CAA21375; Thu, 24 Aug 2000 02:54:16 +0200 (MET DST) Received: from ericsson.com (rmt160103.am.ericsson.se [138.85.160.103]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id CAA24777; Thu, 24 Aug 2000 02:54:06 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A47178.86BBA6CC@ericsson.com> Date: Thu, 24 Aug 2000 10:51:04 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Missing SDP quivalent X-To: "Raju, Makaraju" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Raju, As the binary verion is of a Tag length Value format The TAG is the Tag from the C.11 table The Length is the length of the string The Value is the whole SDP M line: so it would be T,L,V(M= Media name and Transport Address)). Cheers, Christian "Raju, Makaraju" wrote: > > Hi, > > Annex C.11 listed out all the SDP equivalents, but there is no > equivalent specified for "m" (m= (media name and transport address)). > > Am I missing something? How do I encode/decode "m"? > > Thank you > Raju & Jagadish From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 24 08:32:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15809 for ; Thu, 24 Aug 2000 08:32:38 -0400 (EDT) Received: from standards (47.234.32.16:2815) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BBBA@standards.nortelnetworks.com>; Thu, 24 Aug 2000 8:19:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31943 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 24 Aug 2000 08:19:41 -0400 Received: from mail-in.audiocodes.com (mail-out.audiocodes.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BBB9@standards.nortelnetworks.com>; Thu, 24 Aug 2000 8:19:39 -0400 Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Aug 2000 15:31:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Message-ID: <81C3E8FE6C0AD4119D49009027C3AAB25DAB8F@MAIL-IN> Date: Thu, 24 Aug 2000 15:31:37 +0200 Reply-To: Nurit Shenhar Sender: "Media Gateway Control (megaco)" From: Nurit Shenhar Subject: Subtract command To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi 1.What is the meaning of the "W-" (Wildcarded response) in the subtract command and in the AuditRequest Command? 2. It says that as default, the statistics shall be returned in the subtract reply. Does it mean that it will be sent even if the Audit descriptor does not exist? Thenks Nurit From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 24 10:17:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17623 for ; Thu, 24 Aug 2000 10:17:29 -0400 (EDT) Received: from standards (47.234.32.16:4406) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BBE0@standards.nortelnetworks.com>; Thu, 24 Aug 2000 10:04:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31986 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 24 Aug 2000 10:04:15 -0400 Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BBDF@standards.nortelnetworks.com>; Thu, 24 Aug 2000 10:04:14 -0400 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA24861 for ; Thu, 24 Aug 2000 10:16:38 -0400 (EDT) Received: from electric.amc.bell-labs.com (h135-17-7-254.lucent.com [135.17.7.254]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA24857 for ; Thu, 24 Aug 2000 10:16:38 -0400 (EDT) Received: by electric.amc.bell-labs.com with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Aug 2000 10:16:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 24 Aug 2000 10:16:48 -0400 Reply-To: "Raju, Makaraju" Sender: "Media Gateway Control (megaco)" From: "Raju, Makaraju" Subject: Re: Missing SDP quivalent X-To: Christian Groves X-cc: jagadish To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi Christian, But my problem is, I didn't find any TAG value in C.11 for "M". The C.11 table lists TAGs for remaining SDPs("C", "Z" etc.) but not for "M". Thanks Raju > G'Day Raju, > > As the binary verion is of a Tag length Value format > The TAG is the Tag from the C.11 table > The Length is the length of the string > The Value is the whole SDP M line: > > so it would be T,L,V(M= Media name and Transport Address)). > > Cheers, Christian > > "Raju, Makaraju" wrote: > > > > Hi, > > > > Annex C.11 listed out all the SDP equivalents, but there is no > > equivalent specified for "m" (m= (media name and transport > address)). > > > > Am I missing something? How do I encode/decode "m"? > > > > Thank you > > Raju & Jagadish > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 24 13:10:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20688 for ; Thu, 24 Aug 2000 13:10:14 -0400 (EDT) Received: from standards (47.234.32.16:2318) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BC65@standards.nortelnetworks.com>; Thu, 24 Aug 2000 12:56:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32135 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 24 Aug 2000 12:56:56 -0400 Received: from beamer.mchh.siemens.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BC62@standards.nortelnetworks.com>; Thu, 24 Aug 2000 12:46:54 -0400 Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA25951 for ; Thu, 24 Aug 2000 18:58:46 +0200 (MET DST) Received: from mchh150e.mch.pn.siemens.de ([139.21.130.150]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA21170 for ; Thu, 24 Aug 2000 18:58:44 +0200 (MET DST) Received: by mchh150e.mch.pn.siemens.de with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Aug 2000 18:58:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <45DE2268C874D21198880001FA7E416C82C44C@mchh155e.mch.pn.siemens.de> Date: Thu, 24 Aug 2000 18:59:08 +0200 Reply-To: Klaghofer Karl ICN EN HC SE 81 Sender: "Media Gateway Control (megaco)" From: Klaghofer Karl ICN EN HC SE 81 Subject: Internet draft Megaco IP Phone To: MEGACO@STANDARDS.NORTELNETWORKS.COM When will there be a new issue available of the internet draft . Version 02 expires end of August. Does anybody have links to further material (e.g. presentations, tutorials,etc.) on H.248/Megaco IP phones (besides base standards H.248 and H.248 Annex G themselves). Thanks, Karl Klaghofer Siemens karl.klaghofer@icn.siemens.de From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 24 15:25:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22726 for ; Thu, 24 Aug 2000 15:25:35 -0400 (EDT) Received: from standards (47.234.32.16:3967) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BCBC@standards.nortelnetworks.com>; Thu, 24 Aug 2000 15:12:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32235 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 24 Aug 2000 15:12:21 -0400 Received: from cs.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BCBB@standards.nortelnetworks.com>; Thu, 24 Aug 2000 15:12:21 -0400 Received: from bourbon.cs.columbia.edu (bourbon.cs.columbia.edu [128.59.19.24]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA12347 for ; Thu, 24 Aug 2000 15:24:46 -0400 (EDT) Received: from localhost (xiaotaow@localhost) by bourbon.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA12491 for ; Thu, 24 Aug 2000 15:24:44 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 24 Aug 2000 15:24:38 -0400 Reply-To: Xiaotao Wu Sender: "Media Gateway Control (megaco)" From: Xiaotao Wu Subject: Topology for non existing terminations To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <81C3E8FE6C0AD4119D49009027C3AAB25DAB8F@MAIL-IN> Is it valid to specify Topology for the terminations not in the context? For Add termination command, we in fact do this if we specify the topology for the terminations we want to add in. We deal with topology first before we add the terminations in. If we can do this, when the wildcard is used to specify the topology, whether this topology will also be applied to the future terminations? e.g., we do (*, *, ISOLATE), later on, we add a termination A, A should be ISOLATE with others, or A is connected to the others by default BOTHWAY? Can we keep the topology if the terminations are not in the context? E.g., we have (A, B, ONEWAY), then we do Subtract B, and B is removed from the context. If later on, we add B back, what will be the topology between A and B? Still be ONEWAY or just the default BOTHWAY? Thanks! -Xiaotao ==================================================== Name : Xiaotao Wu (Always available by email!) Email: xiaotaow@cs.columbia.edu, xw71@columbia.edu URL : http://www.cs.columbia.edu/~xiaotaow Work Phone: (212)939-7087, Home Phone: (212)795-1963 Office: Room 623, Schapiro (CEPSR), West 120th ==================================================== From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 24 17:04:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23973 for ; Thu, 24 Aug 2000 17:04:04 -0400 (EDT) Received: from standards (47.234.32.16:1719) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BCE0@standards.nortelnetworks.com>; Thu, 24 Aug 2000 16:51:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32281 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 24 Aug 2000 16:51:02 -0400 Received: from qhars002.nortel.com (47.101.112.102:39710) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BCDF@standards.nortelnetworks.com>; Thu, 24 Aug 2000 16:50:47 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Thu, 24 Aug 2000 22:03:03 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Thu, 24 Aug 2000 12:19:15 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 24 Aug 2000 12:22:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00DEF.E9E5CBF0" X-Orig: Message-ID: <8E2783FA4E0CD411888D0000F8CD15D33C38F4@zcard00q.ca.nortel.com> Date: Thu, 24 Aug 2000 12:22:43 -0500 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: Internet draft Megaco IP Phone To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01C00DEF.E9E5CBF0 Content-Type: text/plain; charset="iso-8859-1" Karl, all: Working on 03 version it as we type, just doing addition of some boilerplate. Will likely be posted tomorrow. -- Peter Blatherwick ------_=_NextPart_001_01C00DEF.E9E5CBF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Internet draft Megaco IP Phone

Karl, all:

Working on 03 version it as we = type, just doing addition of some boilerplate.  Will likely be = posted tomorrow. 

-- Peter Blatherwick


------_=_NextPart_001_01C00DEF.E9E5CBF0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 24 18:30:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24790 for ; Thu, 24 Aug 2000 18:30:12 -0400 (EDT) Received: from standards (47.234.32.16:3298) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BD12@standards.nortelnetworks.com>; Thu, 24 Aug 2000 18:17:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32337 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 24 Aug 2000 18:17:15 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BD0C@standards.nortelnetworks.com>; Thu, 24 Aug 2000 18:07:15 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7OMJcw20351; Fri, 25 Aug 2000 00:19:38 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id AAA21712; Fri, 25 Aug 2000 00:19:38 +0200 (MET DST) Received: from ericsson.com (rmt160158.am.ericsson.se [138.85.160.158]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id AAA00959; Fri, 25 Aug 2000 00:19:31 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A5959A.34FA015B@ericsson.com> Date: Fri, 25 Aug 2000 07:37:30 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Support of Values in Packages X-To: SG16 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day all, There has been some confusion at the SG16 on what is supported in Packages. The understanding that I had was that: If you support a package you must support all the signals, properties, events and statistics. However you do not have to support all the values associated with the properties and parameters. Tom mentioned that a thread discussed on the list contravened this. The reasoning that I have for not having to support all the values is the following: o Proliferation of packages. Eg: if a package has a list of tones, and I must support all the values, if I only want to support a subset of these values then I need a new package. Therefore you may get the case of a package "Package Call Progress Tones E.7" where an MG doesn't support Payphone Recognition Tone because it doesn't have payphones connected to it. To be compliant with H.248 I can't extend the package because I want to remove the payphone tone. So a new Package needs to be defined containing exactly the same information but without the payphone tone. Now my MG won't support the standard Call Progress Tone package but will support the XXX_companies_Call_Progress_Tone package. This would lead to a proliferation of packages. o Multiple GW support - One MG may not implement all the values of a property. For something like a list of codecs, a group of resources associated with the value may be placed in different MG GWs. ie. GSM codecs in MG1, PCM codecs in MG2. So whilst the MGs support the same package properties, they can't support a subset of values then you'd need to define a different package for each MG configuration. Again leading to a proliferation of packages. o The MGC knows the PackageID, that all Properties, Signals, Events, Statistics are supported. In H.248 we have the AuditCapability and AuditValue commands to find out what actual values of properties are supported. So if people agree that not all values in a package need to be supported I propose to add some text to the implementor's guide: Section 12.1 after 2nd Paragraph "A MG SHALL support all Property, Signals & parameters, Events & parameters and Statistics. A MG MAY support a subset of property and parameter values defined in the package unless specified in a package." Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 24 18:33:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24878 for ; Thu, 24 Aug 2000 18:33:27 -0400 (EDT) Received: from standards (47.234.32.16:3298) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BD25@standards.nortelnetworks.com>; Thu, 24 Aug 2000 18:17:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32338 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 24 Aug 2000 18:17:59 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BD0D@standards.nortelnetworks.com>; Thu, 24 Aug 2000 18:07:57 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7OMKJw20386; Fri, 25 Aug 2000 00:20:19 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id AAA21724; Fri, 25 Aug 2000 00:20:19 +0200 (MET DST) Received: from ericsson.com (rmt160158.am.ericsson.se [138.85.160.158]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id AAA00967; Fri, 25 Aug 2000 00:20:04 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A59C31.27F14AFD@ericsson.com> Date: Fri, 25 Aug 2000 08:05:37 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Missing SDP quivalent X-To: "Raju, Makaraju" X-cc: jagadish To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Raju, You are correct, it looks like it was missed in the table. One for the implementor's guide. I propose adding: SDP_M B00F STRING Media Name and Transport Address Reference: IETF RFC2327 Cheers, Christian "Raju, Makaraju" wrote: > > Hi Christian, > > But my problem is, I didn't find any TAG value in C.11 for "M". > The C.11 table lists TAGs for remaining SDPs("C", "Z" etc.) but not for "M". > > Thanks > Raju > > > G'Day Raju, > > > > As the binary verion is of a Tag length Value format > > The TAG is the Tag from the C.11 table > > The Length is the length of the string > > The Value is the whole SDP M line: > > > > so it would be T,L,V(M= Media name and Transport Address)). > > > > Cheers, Christian > > > > "Raju, Makaraju" wrote: > > > > > > Hi, > > > > > > Annex C.11 listed out all the SDP equivalents, but there is no > > > equivalent specified for "m" (m= (media name and transport > > address)). > > > > > > Am I missing something? How do I encode/decode "m"? > > > > > > Thank you > > > Raju & Jagadish > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 24 18:33:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24882 for ; Thu, 24 Aug 2000 18:33:27 -0400 (EDT) Received: from standards (47.234.32.16:3298) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BD32@standards.nortelnetworks.com>; Thu, 24 Aug 2000 18:18:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32339 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 24 Aug 2000 18:18:57 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BD0E@standards.nortelnetworks.com>; Thu, 24 Aug 2000 18:08:57 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e7OMLLp05556; Fri, 25 Aug 2000 00:21:21 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id AAA21743; Fri, 25 Aug 2000 00:21:21 +0200 (MET DST) Received: from ericsson.com (rmt160158.am.ericsson.se [138.85.160.158]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id AAA00981; Fri, 25 Aug 2000 00:21:00 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A5959A.34FA015B@ericsson.com> Date: Fri, 25 Aug 2000 07:37:30 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Support of Values in Packages X-To: SG16 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day all, There has been some confusion at the SG16 on what is supported in Packages. The understanding that I had was that: If you support a package you must support all the signals, properties, events and statistics. However you do not have to support all the values associated with the properties and parameters. Tom mentioned that a thread discussed on the list contravened this. The reasoning that I have for not having to support all the values is the following: o Proliferation of packages. Eg: if a package has a list of tones, and I must support all the values, if I only want to support a subset of these values then I need a new package. Therefore you may get the case of a package "Package Call Progress Tones E.7" where an MG doesn't support Payphone Recognition Tone because it doesn't have payphones connected to it. To be compliant with H.248 I can't extend the package because I want to remove the payphone tone. So a new Package needs to be defined containing exactly the same information but without the payphone tone. Now my MG won't support the standard Call Progress Tone package but will support the XXX_companies_Call_Progress_Tone package. This would lead to a proliferation of packages. o Multiple GW support - One MG may not implement all the values of a property. For something like a list of codecs, a group of resources associated with the value may be placed in different MG GWs. ie. GSM codecs in MG1, PCM codecs in MG2. So whilst the MGs support the same package properties, they can't support a subset of values then you'd need to define a different package for each MG configuration. Again leading to a proliferation of packages. o The MGC knows the PackageID, that all Properties, Signals, Events, Statistics are supported. In H.248 we have the AuditCapability and AuditValue commands to find out what actual values of properties are supported. So if people agree that not all values in a package need to be supported I propose to add some text to the implementor's guide: Section 12.1 after 2nd Paragraph "A MG SHALL support all Property, Signals & parameters, Events & parameters and Statistics. A MG MAY support a subset of property X-Mozilla-Status: 0009defined in the package unless specified in a package." Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 24 18:33:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24892 for ; Thu, 24 Aug 2000 18:33:28 -0400 (EDT) Received: from standards (47.234.32.16:3298) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BD50@standards.nortelnetworks.com>; Thu, 24 Aug 2000 18:20:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32341 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 24 Aug 2000 18:20:37 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BD10@standards.nortelnetworks.com>; Thu, 24 Aug 2000 18:10:37 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7OMN1w20440; Fri, 25 Aug 2000 00:23:01 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id AAA21772; Fri, 25 Aug 2000 00:23:01 +0200 (MET DST) Received: from ericsson.com (rmt160158.am.ericsson.se [138.85.160.158]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id AAA01007; Fri, 25 Aug 2000 00:22:49 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A5959A.34FA015B@ericsson.com> Date: Fri, 25 Aug 2000 07:37:30 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Support of Values in Packages X-To: SG16 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day all, There has been some confusion at the SG16 on what is supported in Packages. The understanding that I had was that: If you support a package you must support all the signals, properties, events and statistics. However you do not have to support all the values associated with the properties and parameters. Tom mentioned that a thread discussed on the list contravened this. The reasoning that I have for not having to support all the values is the following: o Proliferation of packages. Eg: if a package has a list of tones, and I must support all the values, if I only want to support a subset of these values then I need a new package. Therefore you may get the case of a package "Package Call Progress Tones E.7" where an MG doesn't support Payphone Recognition Tone because it doesn't have payphones connected to it. To be compliant with H.248 I can't extend the package because I want to remove the payphone tone. So a new Package needs to be defined containing exactly the same information but without the payphone tone. Now my MG won't support the standard Call Progress Tone package but will support the XXX_companies_Call_Progress_Tone package. This would lead to a proliferation of packages. o Multiple GW support - One MG may not implement all the values of a property. For something like a list of codecs, a group of resources associated with the value may be placed in different MG GWs. ie. GSM codecs in MG1, PCM codecs in MG2. So whilst the MGs support the same package properties, they can't support a subset of values then you'd need to define a different package for each MG configuration. Again leading to a proliferation of packages. o The MGC knows the PackageID, that all Properties, Signals, Events, Statistics are supported. In H.248 we have the AuditCapability and AuditValue commands to find out what actual values of properties are supported. So if people agree that not all values in a package need to be supported I propose to add some text to the implementor's guide: Section 12.1 after 2nd Paragraph "A MG SHALL support all Property, Signals & parameters, Events & parameters and Statistics. A MG MAY support a subset of property X-MX-Mozilla-Status: 0009ined in the package unless specified in a package." Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 24 18:36:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24912 for ; Thu, 24 Aug 2000 18:36:31 -0400 (EDT) Received: from standards (47.234.32.16:3298) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BD6E@standards.nortelnetworks.com>; Thu, 24 Aug 2000 18:21:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32342 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 24 Aug 2000 18:21:21 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BD11@standards.nortelnetworks.com>; Thu, 24 Aug 2000 18:11:21 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7OMNiw20454; Fri, 25 Aug 2000 00:23:44 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id AAA21782; Fri, 25 Aug 2000 00:23:43 +0200 (MET DST) Received: from ericsson.com (rmt160158.am.ericsson.se [138.85.160.158]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id AAA01015; Fri, 25 Aug 2000 00:23:28 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A59C31.27F14AFD@ericsson.com> Date: Fri, 25 Aug 2000 08:05:37 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Missing SDP quivalent X-To: "Raju, Makaraju" X-cc: jagadish To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Raju, You are correct, it looks like it was missed in the table. One for the implementor's guide. I propose adding: SDP_M B00F STRING Media Name and Transport Address Reference: IETF RFC2327 Cheers, Christian "Raju, Makaraju" wrote: > > Hi Christian, > > But my problem is, I didn't find any TAG value in C.11 for "M". > The C.11 table lists TAGs for remaining SDPs("C", "Z" etc.) but not for "M". > > Thanks > Raju > > > G'Day Raju, > > > > As the binary verion is of a Tag length Value format > > The TAG is the Tag from the C.11 table > > The Length is the length of the string > > The Value is the whole SDP M line: > > > > so it would be T,L,V(M= Media name and Transport Address)). > > > > Cheers, Christian > > > > "Raju, Makaraju" wrote: > > > > > > Hi, > > > > > > Annex C.11 listed out all X-Mozilla-Status: 0009ut there is no > > > equivalent specified for "m" (m= (media name and transport > > address)). > > > > > > Am I missing something? How do I encode/decode "m"? > > > > > > Thank you > > > Raju & Jagadish > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 24 21:40:33 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27350 for ; Thu, 24 Aug 2000 21:40:33 -0400 (EDT) Received: from standards (47.234.32.16:2996) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BDD4@standards.nortelnetworks.com>; Thu, 24 Aug 2000 21:27:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32574 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 24 Aug 2000 21:27:37 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BDCB@standards.nortelnetworks.com>; Thu, 24 Aug 2000 21:17:37 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e7P1T8p14123; Fri, 25 Aug 2000 03:29:08 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id DAA23427; Fri, 25 Aug 2000 03:29:08 +0200 (MET DST) Received: from ericsson.com (rmt160161.am.ericsson.se [138.85.160.161]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id DAA01772; Fri, 25 Aug 2000 03:29:01 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A5B606.5BDDA65F@ericsson.com> Date: Fri, 25 Aug 2000 09:55:50 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Topology for non existing terminations X-To: Xiaotao Wu To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Xiaotao, I belive topology is only valid for the action after it, thus if you subtract a termination A you also lose the topology associated with it. Therefore if you add it back you will need to respecify the topology. Cheers, Christian Xiaotao Wu wrote: > > Is it valid to specify Topology for the terminations not in the context? > > For Add termination command, we in fact do this if we specify the topology > for the terminations we want to add in. We deal with topology first before > we add the terminations in. > > If we can do this, when the wildcard is used to specify the topology, > whether this topology will also be applied to the future terminations? > e.g., we do (*, *, ISOLATE), later on, we add a termination A, A should be > ISOLATE with others, or A is connected to the others by default BOTHWAY? > > Can we keep the topology if the terminations are not in the > context? E.g., we have (A, B, ONEWAY), then we do Subtract B, and B is > removed from the context. If later on, we add B back, what will be the > topology between A and B? Still be ONEWAY or just the default BOTHWAY? > > Thanks! > > -Xiaotao > > ==================================================== > Name : Xiaotao Wu (Always available by email!) > Email: xiaotaow@cs.columbia.edu, xw71@columbia.edu > URL : http://www.cs.columbia.edu/~xiaotaow > Work Phone: (212)939-7087, Home Phone: (212)795-1963 > Office: Room 623, Schapiro (CEPSR), West 120th > ==================================================== From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 25 03:43:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13782 for ; Fri, 25 Aug 2000 03:43:35 -0400 (EDT) Received: from standards (47.234.32.16:2784) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BEB7@standards.nortelnetworks.com>; Fri, 25 Aug 2000 3:30:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32842 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Aug 2000 03:30:31 -0400 Received: from hd2.dot.net.in (hd2.vsnl.net.in) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BEB6@standards.nortelnetworks.com>; Fri, 25 Aug 2000 3:29:52 -0400 Received: from hyd.chiplogic.com ([203.197.21.234]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id NAA29560 for ; Fri, 25 Aug 2000 13:08:27 +0530 (IST) Received: from chiplogic.com ([192.168.2.163]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id NAA21265 for ; Fri, 25 Aug 2000 13:14:02 +0530 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {TLC;RETAIL} (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A623B1.6C297E5B@chiplogic.com> Date: Fri, 25 Aug 2000 13:13:45 +0530 Reply-To: chennu7@yahoo.com Sender: "Media Gateway Control (megaco)" From: chennu Organization: Chiplogic India (P) Ltd. Subject: Package Descriptor in Audit Capability To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, I have a basic doubt . Why is that Package Descriptor not legal in AuditCapability command? According the draft it is valid in AuditValue command which is used to know the current values associated with a Termination. Does this mean that the List of Packages supported by a Termination keep changing ? Please clarify . Thanks in Advance, Chennu. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 25 09:48:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20538 for ; Fri, 25 Aug 2000 09:48:29 -0400 (EDT) Received: from standards (47.234.32.16:2933) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BFCD@standards.nortelnetworks.com>; Fri, 25 Aug 2000 9:35:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33187 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Aug 2000 09:35:25 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BFCA@standards.nortelnetworks.com>; Fri, 25 Aug 2000 9:25:25 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id GAA04923; Fri, 25 Aug 2000 06:37:49 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <39A5959A.34FA015B@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A677AE.6DB5635@cisco.com> Date: Fri, 25 Aug 2000 09:42:06 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: Support of Values in Packages X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Christian Groves wrote: > G'Day all, > > There has been some confusion at the SG16 on what is supported in > Packages. > > The understanding that I had was that: If you support a package you must > support all the signals, properties, events and statistics. Agreed. > However you > do not have to support all the values associated with the properties and > parameters. I guess the term "values" is somewhat prone to interpretation, but I would tend to disagree if we refer to a list of well-defined values, as e.g. a list of tone ids in E.7. > > > Tom mentioned that a thread discussed on the list contravened this. > > The reasoning that I have for not having to support all the values is > the following: > o Proliferation of packages. Eg: if a package has a list of tones, and I > must support all the values, if I only want to support a subset of these > values then I need a new package. Therefore you may get the case of a > package "Package Call Progress Tones E.7" where an MG doesn't support > Payphone Recognition Tone because it doesn't have payphones connected to > it. However, in this parcticular example, the tones are both signals and tone ids, so the effect would be the same. While I'm not particularly fond of the tonegen package, it does nevertheless illustrate an important point, namely that the distinction between signals, and parameters to signals (and similar for other constructs) is somewhat arbitrary. The package really gives you two things: 1. A name space 2. A convenient grouping of some set of "properties" If we don't know exaclty what those "properties" are, then we've lost a very important aspect of packages. > To be compliant with H.248 I can't extend the package because I want > to remove the payphone tone. So a new Package needs to be defined > containing exactly the same information but without the payphone tone. > Now my MG won't support the standard Call Progress Tone package but will > support the XXX_companies_Call_Progress_Tone package. This would lead to > a proliferation of packages. I agree, but we have to ask ourselves what the idea about packages is. Simplicity and flexibility are often at odds with each other and in this case stress the importance of defining packages very carefully. If I no longer know exactly what is supported in a package, how do I go about using that package ? > > > o Multiple GW support - One MG may not implement all the values of a > property. For something like a list of codecs, a group of resources > associated with the value may be placed in different MG GWs. ie. GSM > codecs in MG1, PCM codecs in MG2. So whilst the MGs support the same > package properties, they can't support a subset of values then you'd > need to define a different package for each MG configuration. Again > leading to a proliferation of packages. Back to defining what "values" mean. Obviously, if we define a "codec" property in a package, we can't expect support for every possible codec in the world. Maybe there's a distinction between supporting values for events, signals, statistics, and properties ? > > > o The MGC knows the PackageID, that all Properties, Signals, Events, > Statistics are supported. In H.248 we have the AuditCapability and > AuditValue commands to find out what actual values of properties are > supported. Not sure how you would do that with event and signal parameters though (come to think of it, I'm not sure how you, in practice, do that for a lot of parameters; "The appropriate descriptors, *with the possible values for the Termination* are returned from AuditCapabilities", Section 7.2.6). On the other, we could have a new property that looked similar, so it's not clear it wouldn't apply there either. > > > So if people agree that not all values in a package need to be supported > I propose to add some text to the implementor's guide: > Section 12.1 after 2nd Paragraph > "A MG SHALL support all Property, Signals & parameters, Events & > parameters and Statistics. A MG MAY support a subset of property and > parameter values defined in the package unless specified in a package." I don't want to deflate the package concept to the extent this would seem to allow, but I agree there's an issue here. Further discussion is needed before we make any change. -- Flemming > > > Cheers, Christian -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 25 12:40:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24322 for ; Fri, 25 Aug 2000 12:40:31 -0400 (EDT) Received: from standards (47.234.32.16:2320) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C023@standards.nortelnetworks.com>; Fri, 25 Aug 2000 12:27:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33290 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Aug 2000 12:27:17 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C01F@standards.nortelnetworks.com>; Fri, 25 Aug 2000 12:17:16 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7PGTgw06441 for ; Fri, 25 Aug 2000 18:29:43 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id SAA23564 for ; Fri, 25 Aug 2000 18:29:42 +0200 (MET DST) Received: from ericsson.com (rmt160185.am.ericsson.se [138.85.160.185]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id SAA06289 for ; Fri, 25 Aug 2000 18:29:35 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A69ECA.BEFAD1FB@ericsson.com> Date: Sat, 26 Aug 2000 02:28:58 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: [Fwd: Re: Support of Values in Packages] To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: Re: Support of Values in Packages Date: Fri, 25 Aug 2000 13:34:09 +0530 From: chennu Reply-To: chennu7@yahoo.com Organization: Chiplogic India (P) Ltd. To: Christian Groves References: <39A5959A.34FA015B@ericsson.com> Hi Christian and All, I also have the same understanding . I agree to your proposal of adding the text to the implementors guide. --chennu. Christian Groves wrote: > G'Day all, > > There has been some confusion at the SG16 on what is supported in > Packages. > > The understanding that I had was that: If you support a package you must > support all the signals, properties, events and statistics. However you > do not have to support all the values associated with the properties and > parameters. > > Tom mentioned that a thread discussed on the list contravened this. > > The reasoning that I have for not having to support all the values is > the following: > o Proliferation of packages. Eg: if a package has a list of tones, and I > must support all the values, if I only want to support a subset of these > values then I need a new package. Therefore you may get the case of a > package "Package Call Progress Tones E.7" where an MG doesn't support > Payphone Recognition Tone because it doesn't have payphones connected to > it. To be compliant with H.248 I can't extend the package because I want > to remove the payphone tone. So a new Package needs to be defined > containing exactly the same information but without the payphone tone. > Now my MG won't support the standard Call Progress Tone package but will > support the XXX_companies_Call_Progress_Tone package. This would lead to > a proliferation of packages. > > o Multiple GW support - One MG may not implement all the values of a > property. For something like a list of codecs, a group of resources > associated with the value may be placed in different MG GWs. ie. GSM > codecs in MG1, PCM codecs in MG2. So whilst the MGs support the same > package properties, they can't support a subset of values then you'd > need to define a different package for each MG configuration. Again > leading to a proliferation of packages. > > o The MGC knows the PackageID, that all Properties, Signals, Events, > Statistics are supported. In H.248 we have the AuditCapability and > AuditValue commands to find out what actual values of properties are > supported. > > So if people agree that not all values in a package need to be supported > I propose to add some text to the implementor's guide: > Section 12.1 after 2nd Paragraph > "A MG SHALL support all Property, Signals & parameters, Events & > parameters and Statistics. A MG MAY support a subset of property and > parameter values defined in the package unless specified in a package." > > Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 25 13:45:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25400 for ; Fri, 25 Aug 2000 13:45:44 -0400 (EDT) Received: from standards (47.234.32.16:3878) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C062@standards.nortelnetworks.com>; Fri, 25 Aug 2000 13:32:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33374 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Aug 2000 13:32:14 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C061@standards.nortelnetworks.com>; Fri, 25 Aug 2000 13:32:14 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA17487; Fri, 25 Aug 2000 13:44:38 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA25222; Fri, 25 Aug 2000 13:44:38 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 25 Aug 2000 13:44:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF678781@whq-msgusr-02.fore.com> Date: Fri, 25 Aug 2000 13:44:28 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: draft-ietf-megaco-ipphone-03.txt X-To: "Tom Taylor (E-mail)" To: MEGACO@STANDARDS.NORTELNETWORKS.COM If it still subsets the protocol, I'll oppose any WG action. Nortel, or TIA, or whoever can always ask IESG to do an informational, but I think the WG should stand firm on no subsets. Of course if they have dropped that, then no problem. Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Friday, August 25, 2000 1:14 PM To: ITU-SG16@mailbag.cps.intel.com Subject: draft-ietf-megaco-ipphone-03.txt As indicated in the quotation below, the latest version of the IPPhone profile has been sent to the IETF. If you can't wait for it to be posted, please send an E-mail to Peter Blatherwick asking for a copy. When it appears, I offer it for WG Last Call, with a view to publishing it as an Informational RFC. Tom Taylor -----Original Message----- From: Blatherwick, Peter [CAR:AT14:EXCH] Sent: Friday, August 25, 2000 12:29 To: 'internet-drafts@ietf.org' Cc: 'Bob Bell (Cisco)'; 'Phil Holland (Circa)' Subject: I-D Submission: Megaco IP Phone MG 03 Greetings: Please find I-D submission, "draft-ietf-megaco-ipphone-03.txt", for Megaco WG, attached. This replaces the previous submission of the same name (draft-ietf-megaco-ipphone-02.txt). Please copy announcement to Megaco mailing list (megaco@standards.nortelnetworks.com) when posted. Thanks, and have a great day, Peter Blatherwick 613-763-7539 blather@nortelnetworks.com << File: draft-ietf-megaco-ipphone-03.txt >> From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 25 18:43:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01247 for ; Fri, 25 Aug 2000 18:43:56 -0400 (EDT) Received: from standards (47.234.32.16:2985) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C0A2@standards.nortelnetworks.com>; Fri, 25 Aug 2000 18:30:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33459 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Aug 2000 18:30:49 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C0A0@standards.nortelnetworks.com>; Fri, 25 Aug 2000 18:20:48 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e7PMXAp27190; Sat, 26 Aug 2000 00:33:10 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id AAA26134; Sat, 26 Aug 2000 00:33:09 +0200 (MET DST) Received: from ericsson.com (rmt160181.am.ericsson.se [138.85.160.181]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id AAA07633; Sat, 26 Aug 2000 00:33:02 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <39A623B1.6C297E5B@chiplogic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A6BB16.24564D10@ericsson.com> Date: Sat, 26 Aug 2000 04:29:42 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Package Descriptor in Audit Capability X-To: chennu7@yahoo.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Chennu, The Package Descriptor is not legal in the AuditCap command because a termination supports a certain set of Packages. When you do an auditValue of a termination you receive the PackageIDs that are supported. AuditCap relates to the complete set of values a termination supports. So for Packages this list would be the entire list registered with IANA. As that doesn't make much sense to have in a MG, auditing packages was left out of AuditCap. Cheers, Christian chennu wrote: > > Hi, > > I have a basic doubt . Why is that Package Descriptor not legal in > AuditCapability command? According the draft it is valid in AuditValue > command which is used to know the current values associated with a > Termination. Does this mean that the List of Packages supported by a > Termination keep changing ? > Please clarify . > > Thanks in Advance, > Chennu. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 25 18:46:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01282 for ; Fri, 25 Aug 2000 18:46:24 -0400 (EDT) Received: from standards (47.234.32.16:2985) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C0C2@standards.nortelnetworks.com>; Fri, 25 Aug 2000 18:33:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33460 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Aug 2000 18:33:22 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C0A1@standards.nortelnetworks.com>; Fri, 25 Aug 2000 18:23:22 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7PMZkw22954; Sat, 26 Aug 2000 00:35:46 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id AAA26181; Sat, 26 Aug 2000 00:35:45 +0200 (MET DST) Received: from ericsson.com (rmt160181.am.ericsson.se [138.85.160.181]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id AAA07678; Sat, 26 Aug 2000 00:35:36 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <39A5959A.34FA015B@ericsson.com> <39A677AE.6DB5635@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A6C530.E9D9C467@ericsson.com> Date: Sat, 26 Aug 2000 05:12:48 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Support of Values in Packages X-To: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Flemming, At least we agree there's an ambiguity here. I do agree with you about the Tone Packages where Properties and signals are blurred and the here you would support all the values. That's why in my clarification I mentioned that a package may mandate support of all values. I also agree that there's a need for clarification on what auditing Signals means. Could you elaborate on how we would be deflating the package concept by clarifying the Values are optional? How I saw it handled was that if a Package Defined Prop = val1, val2, val3 and a MG supported P =v1, v3 the if the MGC tried to set prop = val2 then it would receive unsupported property in reply. I didn't see this would cause people major problems. Cheers, Christian Flemming Andreasen wrote: > > Christian Groves wrote: > > > G'Day all, > > > > There has been some confusion at the SG16 on what is supported in > > Packages. > > > > The understanding that I had was that: If you support a package you must > > support all the signals, properties, events and statistics. > > Agreed. > > > However you > > do not have to support all the values associated with the properties and > > parameters. > > I guess the term "values" is somewhat prone to interpretation, but I would > tend to disagree if we refer to a list of well-defined values, as e.g. a > list of tone ids in E.7. > > > > > > > Tom mentioned that a thread discussed on the list contravened this. > > > > The reasoning that I have for not having to support all the values is > > the following: > > o Proliferation of packages. Eg: if a package has a list of tones, and I > > must support all the values, if I only want to support a subset of these > > values then I need a new package. Therefore you may get the case of a > > package "Package Call Progress Tones E.7" where an MG doesn't support > > Payphone Recognition Tone because it doesn't have payphones connected to > > it. > > However, in this parcticular example, the tones are both signals and tone > ids, so the effect would be the same. While I'm not particularly fond of the > tonegen package, it does nevertheless illustrate an important point, namely > that the distinction between signals, and parameters to signals (and similar > for other constructs) is somewhat arbitrary. The package really gives you > two things: > 1. A name space > 2. A convenient grouping of some set of "properties" > > If we don't know exaclty what those "properties" are, then we've lost a very > important aspect of packages. > > > To be compliant with H.248 I can't extend the package because I want > > to remove the payphone tone. So a new Package needs to be defined > > containing exactly the same information but without the payphone tone. > > Now my MG won't support the standard Call Progress Tone package but will > > support the XXX_companies_Call_Progress_Tone package. This would lead to > > a proliferation of packages. > > I agree, but we have to ask ourselves what the idea about packages is. > Simplicity and flexibility are often at odds with each other and in this > case stress the importance of defining packages very carefully. > > If I no longer know exactly what is supported in a package, how do I go > about using that package ? > > > > > > > o Multiple GW support - One MG may not implement all the values of a > > property. For something like a list of codecs, a group of resources > > associated with the value may be placed in different MG GWs. ie. GSM > > codecs in MG1, PCM codecs in MG2. So whilst the MGs support the same > > package properties, they can't support a subset of values then you'd > > need to define a different package for each MG configuration. Again > > leading to a proliferation of packages. > > Back to defining what "values" mean. Obviously, if we define a "codec" > property in a package, we can't expect support for every possible codec in > the world. > > Maybe there's a distinction between supporting values for events, signals, > statistics, and properties ? > > > > > > > o The MGC knows the PackageID, that all Properties, Signals, Events, > > Statistics are supported. In H.248 we have the AuditCapability and > > AuditValue commands to find out what actual values of properties are > > supported. > > Not sure how you would do that with event and signal parameters though (come > to think of it, I'm not sure how you, in practice, do that for a lot of > parameters; "The appropriate descriptors, *with the possible values for the > Termination* are returned from AuditCapabilities", Section 7.2.6). On the > other, we could have a new property that looked similar, so it's not clear > it wouldn't apply there either. > > > > > > > So if people agree that not all values in a package need to be supported > > I propose to add some text to the implementor's guide: > > Section 12.1 after 2nd Paragraph > > "A MG SHALL support all Property, Signals & parameters, Events & > > parameters and Statistics. A MG MAY support a subset of property and > > parameter values defined in the package unless specified in a package." > > I don't want to deflate the package concept to the extent this would seem to > allow, but I agree there's an issue here. Further discussion is needed > before we make any change. > > -- Flemming > > > > > > > Cheers, Christian > > -- > Flemming Andreasen > Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Aug 25 19:00:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01408 for ; Fri, 25 Aug 2000 19:00:46 -0400 (EDT) Received: from standards (47.234.32.16:2985) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C126@standards.nortelnetworks.com>; Fri, 25 Aug 2000 18:47:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33537 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Aug 2000 18:47:53 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C0DF@standards.nortelnetworks.com>; Fri, 25 Aug 2000 18:37:52 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id PAA10657; Fri, 25 Aug 2000 15:50:18 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <39A5959A.34FA015B@ericsson.com> <39A677AE.6DB5635@cisco.com> <39A6C530.E9D9C467@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A6F92B.B154BC0F@cisco.com> Date: Fri, 25 Aug 2000 18:54:35 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: Support of Values in Packages X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Christian Groves wrote: > G'Day Flemming, > > At least we agree there's an ambiguity here. I do agree with you about > the Tone Packages where Properties and signals are blurred and the here > you would support all the values. That's why in my clarification I > mentioned that a package may mandate support of all values. OK, I understood it differently. All you want, is the ability to define a package, and in that package you then specify that which values are optional and which are mandatory ? > I also agree > that there's a need for clarification on what auditing Signals means. > > Could you elaborate on how we would be deflating the package concept by > clarifying the Values are optional? My main concern is having MG A and MG B both support package P and yet my MGC doesn't know what they actually implement. So far, it would simply be defined by whatever is defined in package P and interoperability becomes very simple. We now add an extra dimension to the package concept. As long as the package, not the MG, defines what can be optional that's probably fine. It does leave open the issue of finding out which of the optional values are actually supported. Ideally, you would like to be able to figure that out ahead of time rather than by trial and error. > > > How I saw it handled was that if a Package Defined Prop = val1, val2, > val3 and a MG supported P =v1, v3 the if the MGC tried to set prop = > val2 then it would receive unsupported property in reply. I didn't see > this would cause people major problems. I would much prefer being able to figure that out ahead of time (but realize that may be easier said than done in the general case) -- Flemming > > > Cheers, Christian > > Flemming Andreasen wrote: > > > > Christian Groves wrote: > > > > > G'Day all, > > > > > > There has been some confusion at the SG16 on what is supported in > > > Packages. > > > > > > The understanding that I had was that: If you support a package you must > > > support all the signals, properties, events and statistics. > > > > Agreed. > > > > > However you > > > do not have to support all the values associated with the properties and > > > parameters. > > > > I guess the term "values" is somewhat prone to interpretation, but I would > > tend to disagree if we refer to a list of well-defined values, as e.g. a > > list of tone ids in E.7. > > > > > > > > > > > Tom mentioned that a thread discussed on the list contravened this. > > > > > > The reasoning that I have for not having to support all the values is > > > the following: > > > o Proliferation of packages. Eg: if a package has a list of tones, and I > > > must support all the values, if I only want to support a subset of these > > > values then I need a new package. Therefore you may get the case of a > > > package "Package Call Progress Tones E.7" where an MG doesn't support > > > Payphone Recognition Tone because it doesn't have payphones connected to > > > it. > > > > However, in this parcticular example, the tones are both signals and tone > > ids, so the effect would be the same. While I'm not particularly fond of the > > tonegen package, it does nevertheless illustrate an important point, namely > > that the distinction between signals, and parameters to signals (and similar > > for other constructs) is somewhat arbitrary. The package really gives you > > two things: > > 1. A name space > > 2. A convenient grouping of some set of "properties" > > > > If we don't know exaclty what those "properties" are, then we've lost a very > > important aspect of packages. > > > > > To be compliant with H.248 I can't extend the package because I want > > > to remove the payphone tone. So a new Package needs to be defined > > > containing exactly the same information but without the payphone tone. > > > Now my MG won't support the standard Call Progress Tone package but will > > > support the XXX_companies_Call_Progress_Tone package. This would lead to > > > a proliferation of packages. > > > > I agree, but we have to ask ourselves what the idea about packages is. > > Simplicity and flexibility are often at odds with each other and in this > > case stress the importance of defining packages very carefully. > > > > If I no longer know exactly what is supported in a package, how do I go > > about using that package ? > > > > > > > > > > > o Multiple GW support - One MG may not implement all the values of a > > > property. For something like a list of codecs, a group of resources > > > associated with the value may be placed in different MG GWs. ie. GSM > > > codecs in MG1, PCM codecs in MG2. So whilst the MGs support the same > > > package properties, they can't support a subset of values then you'd > > > need to define a different package for each MG configuration. Again > > > leading to a proliferation of packages. > > > > Back to defining what "values" mean. Obviously, if we define a "codec" > > property in a package, we can't expect support for every possible codec in > > the world. > > > > Maybe there's a distinction between supporting values for events, signals, > > statistics, and properties ? > > > > > > > > > > > o The MGC knows the PackageID, that all Properties, Signals, Events, > > > Statistics are supported. In H.248 we have the AuditCapability and > > > AuditValue commands to find out what actual values of properties are > > > supported. > > > > Not sure how you would do that with event and signal parameters though (come > > to think of it, I'm not sure how you, in practice, do that for a lot of > > parameters; "The appropriate descriptors, *with the possible values for the > > Termination* are returned from AuditCapabilities", Section 7.2.6). On the > > other, we could have a new property that looked similar, so it's not clear > > it wouldn't apply there either. > > > > > > > > > > > So if people agree that not all values in a package need to be supported > > > I propose to add some text to the implementor's guide: > > > Section 12.1 after 2nd Paragraph > > > "A MG SHALL support all Property, Signals & parameters, Events & > > > parameters and Statistics. A MG MAY support a subset of property and > > > parameter values defined in the package unless specified in a package." > > > > I don't want to deflate the package concept to the extent this would seem to > > allow, but I agree there's an issue here. Further discussion is needed > > before we make any change. > > > > -- Flemming > > > > > > > > > > > Cheers, Christian > > > > -- > > Flemming Andreasen > > Cisco Systems -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Aug 26 02:07:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19240 for ; Sat, 26 Aug 2000 02:07:34 -0400 (EDT) Received: from standards (47.234.32.16:1145) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C1F0@standards.nortelnetworks.com>; Sat, 26 Aug 2000 1:54:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33881 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 26 Aug 2000 01:54:41 -0400 Received: from hd2.dot.net.in (hd2.vsnl.net.in) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C1EF@standards.nortelnetworks.com>; Sat, 26 Aug 2000 1:54:37 -0400 Received: from hyd.chiplogic.com ([203.197.21.105]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id LAA16885 for ; Sat, 26 Aug 2000 11:11:56 +0530 (IST) Received: from chiplogic.com ([192.168.2.163]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id LAA10763 for ; Sat, 26 Aug 2000 11:14:59 +0530 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {TLC;RETAIL} (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <81C3E8FE6C0AD4119D49009027C3AAB25DAB8F@MAIL-IN> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A75953.AC0F6634@chiplogic.com> Date: Sat, 26 Aug 2000 11:14:51 +0530 Reply-To: chennu Sender: "Media Gateway Control (megaco)" From: chennu Organization: Chiplogic India (P) Ltd. Subject: Re: Subtract command To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Nurit, I am answering your 2 Question. Yes Statistics Descriptor is returned by default. But if Audit Descriptor is sent in the Subtract command with some descriptors set in that then the only the requested descriptors are sent back. If none of the descripotors is set in the Audit Descriptor then nothing is returned in the reply sent for the Subtract command. Hope I have cleared your doubt . -- Chennu. Nurit Shenhar wrote: > Hi > > 1.What is the meaning of the "W-" (Wildcarded response) in the subtract > command and in the AuditRequest Command? > > 2. It says that as default, the statistics shall be returned in the subtract > reply. Does it mean that it will be sent even if the Audit descriptor does > not exist? > > Thenks > > Nurit From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 28 01:43:20 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22128 for ; Mon, 28 Aug 2000 01:43:20 -0400 (EDT) Received: from standards (47.234.32.16:4028) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C583@standards.nortelnetworks.com>; Mon, 28 Aug 2000 1:29:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35072 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Aug 2000 01:29:58 -0400 Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C582@standards.nortelnetworks.com>; Mon, 28 Aug 2000 1:29:57 -0400 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id BAA07539 for ; Mon, 28 Aug 2000 01:42:32 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id BAA07528 for ; Mon, 28 Aug 2000 01:42:31 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id HAA11341; Mon, 28 Aug 2000 07:42:31 +0200 (MET DST) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id HAA11330; Mon, 28 Aug 2000 07:42:28 +0200 (MET DST) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Original-CC: MEGACO@standards.nortelnetworks.com References: <39A5959A.34FA015B@ericsson.com> <39A677AE.6DB5635@cisco.com> <39A6C530.E9D9C467@ericsson.com> <39A6F92B.B154BC0F@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A9AEE9.D74B2F7E@lucent.com> Date: Mon, 28 Aug 2000 02:14:33 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Support of Values in Packages X-To: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Flemming, Flemming Andreasen wrote: > OK, I understood it differently. All you want, is the ability to define a package, > and in that package you then specify that which values are optional and which are > mandatory ? Allowing this would certainly give a lot more flexibility and I believe that something like this could be allowed in package definitions. If we do allow this, then, we should consider adding some text somewhere (implementor's guide probably). This to prevent people from claiming to support the DTMF detection package, and only detect digits 0-8: the package doesn't say that support for 9 is mandatory. I am not certain whether one statement could cover all existing packages or that we would have to address them separately. > > I also agree > > that there's a need for clarification on what auditing Signals means. > > > > Could you elaborate on how we would be deflating the package concept by > > clarifying the Values are optional? > > My main concern is having MG A and MG B both support package P and yet my MGC > doesn't know what they actually implement. So far, it would simply be defined by > whatever is defined in package P and interoperability becomes very simple. We now > add an extra dimension to the package concept. As long as the package, not the MG, > defines what can be optional that's probably fine. It does leave open the issue of > finding out which of the optional values are actually supported. Ideally, you > would like to be able to figure that out ahead of time rather than by trial and > error. I agree that documenting the status (mandatory/optional) of values in packages is better than leaving it up to the MG and that trial and error is far from ideal. At the risk of upsetting Brian, but at the same time increasing the chances of getting him to think about this issue, might I suggest that provisioning could be used? Cheers, John -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 28 04:45:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01251 for ; Mon, 28 Aug 2000 04:45:22 -0400 (EDT) Received: from standards (47.234.32.16:3658) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C5EF@standards.nortelnetworks.com>; Mon, 28 Aug 2000 4:32:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35208 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Aug 2000 04:32:07 -0400 Received: from marie.nada.co.kr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C5EE@standards.nortelnetworks.com>; Mon, 28 Aug 2000 4:32:06 -0400 Received: from vctest1 ([192.168.1.153]) by marie.nada.co.kr (8.9.3/8.9.3) with SMTP id RAA26512 for ; Mon, 28 Aug 2000 17:52:24 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A2_01C01118.2B099730" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: <00a501c010cc$bba269d0$9901a8c0@nadatel.com> Date: Mon, 28 Aug 2000 17:48:26 +0900 Reply-To: Junyoung Heo Sender: "Media Gateway Control (megaco)" From: Junyoung Heo Subject: About creating contextID and terimnationID To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_00A2_01C01118.2B099730 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkuDQoNCkl0IGNhbiBiZSBhbGxvd2VkIHRoYXQgTUdDIGNyZWF0ZXMgY29udGV4dElEL3Rlcm1p bmF0aW9uSUQgDQphbmQgc2VuZHMgQUREIGNvbW1hbmQgd2l0aCB0aGVtKG5ldyBJRHMpIHRvIE1H Lg0KDQpJJ20gc29ycnksIGlmIHNpbWlsaWFyIHF1ZXN0aW9uIGlzIGFscmVhZHkgYW5zd2VyZWQu DQoNClRoYW5rcyBmb3IgcmVhZGluZy4NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQrH48HYv7UoSnVueW91bmcgSGVvKQ0KUiZEIGNlbnRlciBvZiBOYWRhVGVsIENvLixMdGQuIEtv cmVhDQpUZWwgOiArODItMi01OTYtMzk0MQ0KRmF4IDogKzgyLTItNTk2LTM2MjYNCkVtYWlsIDog Z3JlZW5AbmFkYXRlbC5jb20NCg== ------=_NextPart_000_00A2_01C01118.2B099730 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MjAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpLjwvRk9OVD48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JdCBjYW4gYmUgYWxs b3dlZCB0aGF0IE1HQyZuYnNwO2NyZWF0ZXMgDQpjb250ZXh0SUQvdGVybWluYXRpb25JRCA8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5hbmQgc2VuZHMgQUREIGNvbW1hbmQgd2l0aCB0 aGVtKG5ldyBJRHMpIHRvIE1HLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj5JJ20gc29ycnksIGlmJm5ic3A7c2ltaWxpYXIgcXVlc3Rpb24gaXMgYWxy ZWFkeSANCmFuc3dlcmVkLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIHNpemU9Mj5UaGFua3MgZm9yIHJlYWRpbmcuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxC Uj7H48HYv7UoSnVueW91bmcgSGVvKTxCUj5SJmFtcDtEIA0KY2VudGVyIG9mIE5hZGFUZWwgQ28u LEx0ZC4gS29yZWE8QlI+VGVsIDogKzgyLTItNTk2LTM5NDE8QlI+RmF4IDogDQorODItMi01OTYt MzYyNjxCUj5FbWFpbCA6IDxBIA0KaHJlZj0ibWFpbHRvOmdyZWVuQG5hZGF0ZWwuY29tIj5ncmVl bkBuYWRhdGVsLmNvbTwvQT48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_00A2_01C01118.2B099730-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 28 07:03:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02878 for ; Mon, 28 Aug 2000 07:03:08 -0400 (EDT) Received: from standards (47.234.32.16:1751) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C644@standards.nortelnetworks.com>; Mon, 28 Aug 2000 6:49:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35320 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Aug 2000 06:49:49 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C643@standards.nortelnetworks.com>; Mon, 28 Aug 2000 6:39:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02636; Mon, 28 Aug 2000 06:52:23 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200008281052.GAA02636@ietf.org> Date: Mon, 28 Aug 2000 06:52:23 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-megaco-ipphone-03.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM --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 IP Phone Media Gateway Application Profile Author(s) : R. Bell, P. Blatherwick, P. Holland Filename : draft-ietf-megaco-ipphone-03.txt Pages : 13 Date : 25-Aug-00 This document specifies a particular application of the Megaco/H.248 Protocol [3] for control of Internet telephones and similar appliances: the Megaco IP Phone Media Gateway. The telephone itself is a Media Gateway (MG), controlled by the Megaco/H.248 Protocol, with application control intelligence located in the Media Gateway Controller (MGC). To achieve a high degree of interoperability and design efficiency in such end-user devices, a consistent architectural approach, a particular organization of Terminations and Packages, and a Protocol Profile are described. The approach makes use of existing Protocol features and user interface related Packages [4], and is thus a straight-forward application of the Megaco/H.248 Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-03.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-ipphone-03.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-ipphone-03.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: <20000825141440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-ipphone-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-ipphone-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000825141440.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 28 13:23:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16292 for ; Mon, 28 Aug 2000 13:23:13 -0400 (EDT) Received: from standards (47.234.32.16:3651) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C7BC@standards.nortelnetworks.com>; Mon, 28 Aug 2000 13:09:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35793 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Aug 2000 13:09:52 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C7BB@standards.nortelnetworks.com>; Mon, 28 Aug 2000 13:09:51 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07384; Mon, 28 Aug 2000 13:22:25 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA03381; Mon, 28 Aug 2000 13:22:26 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 28 Aug 2000 13:22:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF678790@whq-msgusr-02.fore.com> Date: Mon, 28 Aug 2000 13:22:19 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Support of Values in Packages X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'll chime in late here with the opinion that in some really unusual cases, it may make sense to have some values that the MG doesn't implement. The codec list is one, and anything that recognized a preexisting IANA list might be another. I think that, by default, if you implement the package, you implement all of it. I think that if there was a need, you could state, in the definition of the package, that implementation of some values can be optional. I'd make the language be pretty limiting, recommending that it's a bad idea,... Of course an AuditCapability of that descriptor should return the values implemented. Brian > -----Original Message----- > From: John Segers [mailto:jsegers@LUCENT.COM] > Sent: Sunday, August 27, 2000 8:15 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Support of Values in Packages > > > Flemming, > > Flemming Andreasen wrote: > > > OK, I understood it differently. All you want, is the > ability to define a package, > > and in that package you then specify that which values are > optional and which are > > mandatory ? > > Allowing this would certainly give a lot more flexibility and > I believe > that something like this could be allowed in package definitions. > > If we do allow this, then, we should consider adding some > text somewhere > (implementor's guide probably). This to prevent people from > claiming to > support the DTMF detection package, and only detect digits 0-8: the > package doesn't say that support for 9 is mandatory. I am not certain > whether one statement could cover all existing packages or > that we would > have to address them separately. > > > > I also agree > > > that there's a need for clarification on what auditing > Signals means. > > > > > > Could you elaborate on how we would be deflating the > package concept by > > > clarifying the Values are optional? > > > > My main concern is having MG A and MG B both support > package P and yet my MGC > > doesn't know what they actually implement. So far, it would > simply be defined by > > whatever is defined in package P and interoperability > becomes very simple. We now > > add an extra dimension to the package concept. As long as > the package, not the MG, > > defines what can be optional that's probably fine. It does > leave open the issue of > > finding out which of the optional values are actually > supported. Ideally, you > > would like to be able to figure that out ahead of time > rather than by trial and > > error. > > I agree that documenting the status (mandatory/optional) of values in > packages is better than leaving it up to the MG and that > trial and error > is far from ideal. At the risk of upsetting Brian, but at > the same time > increasing the chances of getting him to think about this > issue, might I > suggest that provisioning could be used? > > Cheers, > > John > > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 306 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 28 13:26:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16313 for ; Mon, 28 Aug 2000 13:26:00 -0400 (EDT) Received: from standards (47.234.32.16:3651) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C7D9@standards.nortelnetworks.com>; Mon, 28 Aug 2000 13:11:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35828 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Aug 2000 13:11:55 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C7D7@standards.nortelnetworks.com>; Mon, 28 Aug 2000 13:11:55 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07623; Mon, 28 Aug 2000 13:24:20 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 NAA04044; Mon, 28 Aug 2000 13:24:19 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 28 Aug 2000 13:24:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01114.CC79F37A" Message-ID: <4FBEA8857476D311A03300204840E1CF678791@whq-msgusr-02.fore.com> Date: Mon, 28 Aug 2000 13:24:18 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: About creating contextID and terimnationID X-To: Junyoung Heo To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01C01114.CC79F37A Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable No, the MG creates Contexts, and their IDs, as well as all = TerminationIds (both physical and ephemeral). It is not possible for the MGC to create contextIds or terminationIds. =20 Brian -----Original Message----- From: Junyoung Heo [mailto:green@NADATEL.COM] Sent: Monday, August 28, 2000 4:48 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: About creating contextID and terimnationID Hi. =20 It can be allowed that MGC creates contextID/terminationID=20 and sends ADD command with them(new IDs) to MG. =20 I'm sorry, if similiar question is already answered. =20 Thanks for reading. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D =C7=E3=C1=D8=BF=B5(Junyoung Heo) R&D center of NadaTel Co.,Ltd. Korea Tel : +82-2-596-3941 Fax : +82-2-596-3626 Email : green@nadatel.com =20 ------_=_NextPart_001_01C01114.CC79F37A Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable
No,=20 the MG creates Contexts, and their IDs, as well as all TerminationIds=20 (both
physical and ephemeral).  It is not = possible for=20 the MGC to create contextIds or
terminationIds.
 
Brian
-----Original Message-----
From: Junyoung Heo=20 [mailto:green@NADATEL.COM]
Sent: Monday, August 28, 2000 = 4:48=20 AM
To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: About=20 creating contextID and terimnationID

Hi.
 
It can be allowed that MGC creates=20 contextID/terminationID
and sends ADD command with them(new IDs) to = MG.
 
I'm sorry, if similiar question is already=20 answered.
 
Thanks for reading.
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
=C7=E3=C1=D8=BF=B5(Junyoung=20 Heo)
R&D center of NadaTel Co.,Ltd. Korea
Tel :=20 +82-2-596-3941
Fax : +82-2-596-3626
Email : green@nadatel.com
------_=_NextPart_001_01C01114.CC79F37A-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 28 18:10:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21352 for ; Mon, 28 Aug 2000 18:10:57 -0400 (EDT) Received: from standards (47.234.32.16:1604) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C87D@standards.nortelnetworks.com>; Mon, 28 Aug 2000 17:57:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36036 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Aug 2000 17:57:08 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C87C@standards.nortelnetworks.com>; Mon, 28 Aug 2000 17:57:07 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA06859 for ; Mon, 28 Aug 2000 18:09:42 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 SAA26935 for ; Mon, 28 Aug 2000 18:09:42 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 28 Aug 2000 18:09:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01706829@whq-msgusr-02.fore.com> Date: Mon, 28 Aug 2000 18:09:41 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: TPKT Headers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Consensus here is that the TPKT header for TCP is exactly 4 bytes long (3,0, 16 bit length). The TDPU header is NOT implemented. Reading RFC1006, you could infer that the next byte is a TDPU header length, followed by a variable number of bytes, then user data. Apparently H.245 only uses the packet header, and not the TDPU header. Any dissenters? Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 28 18:13:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21370 for ; Mon, 28 Aug 2000 18:13:40 -0400 (EDT) Received: from standards (47.234.32.16:1604) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C897@standards.nortelnetworks.com>; Mon, 28 Aug 2000 17:59:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36065 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Aug 2000 17:59:19 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C896@standards.nortelnetworks.com>; Mon, 28 Aug 2000 17:59:18 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA06895 for ; Mon, 28 Aug 2000 18:10:08 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 SAA26936 for ; Mon, 28 Aug 2000 18:10:08 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 28 Aug 2000 18:09:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01706828@whq-msgusr-02.fore.com> Date: Mon, 28 Aug 2000 18:09:41 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Is ServiceChangeMgcId Optional on Cold Start? To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is the first in what I expect will be a series of issues that we discover at the Interop. Yes, testing has not begun yet, but we already have one. The question is, what does the MGC send in a ServiceChange reply? The text currently states: Upon a cold start of the MG, it will issue a ServiceChange command with a "Restart" method, on the Root Termination to its primary MGC. If the MGC accepts the MG, it will send a Transaction Accept, with the ServiceChangeMgcId set to itself. Note that this implies ServiceChangeMgcId is not optional. I think this is incorrect and the text should state: "...with the ServiceChangeMgcId omitted or set to itself." Following the usual IETF dictum about "be strict in what you send, liberal in what you accept", MGCs SHOULD set ServiceChangeMgcId, MGs should NOT depend on it. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Aug 28 19:40:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22230 for ; Mon, 28 Aug 2000 19:40:46 -0400 (EDT) Received: from standards (47.234.32.16:3995) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C8D8@standards.nortelnetworks.com>; Mon, 28 Aug 2000 19:27:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36151 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Aug 2000 19:27:43 -0400 Received: from world.std.com (world-f.std.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C8D7@standards.nortelnetworks.com>; Mon, 28 Aug 2000 19:27:43 -0400 Received: (from mpd@localhost) by world.std.com (8.9.3/8.9.3) id TAA16496; Mon, 28 Aug 2000 19:38:27 -0400 (EDT) Message-ID: <200008282338.TAA16496@world.std.com> Date: Mon, 28 Aug 2000 19:38:27 -0400 Reply-To: Michael P DiGioia Sender: "Media Gateway Control (megaco)" From: Michael P DiGioia Subject: Re: Is ServiceChangeMgcId Optional on Cold Start? X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM >> Note that this implies ServiceChangeMgcId is not optional. >> I think this is incorrect and the text should state: >> "...with the ServiceChangeMgcId omitted or set to itself." Brian, The first ServiceChange cmd from the MG is akin to a hello message and nothing is required to be returned. Transaction accept from the PriMGC indicates an add to MGC's table was complete. I therefore agree that it should be omitted. /mpd From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 00:50:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27729 for ; Tue, 29 Aug 2000 00:50:43 -0400 (EDT) Received: from standards (47.234.32.16:4409) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C99A@standards.nortelnetworks.com>; Tue, 29 Aug 2000 0:37:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36401 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 00:37:23 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C999@standards.nortelnetworks.com>; Tue, 29 Aug 2000 0:27:23 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e7T4e0p25741 for ; Tue, 29 Aug 2000 06:40:00 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id GAA24597 for ; Tue, 29 Aug 2000 06:39:04 +0200 (MET DST) Received: from ericsson.com (rmt160172.am.ericsson.se [138.85.160.172]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id GAA25900 for ; Tue, 29 Aug 2000 06:38:56 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF678790@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39AB3878.AB683DEE@ericsson.com> Date: Tue, 29 Aug 2000 15:13:44 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Support of Values in Packages To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Brian, all, I could have sworn that we had discussed this back in Red Bank last year when discussing inheritance of packages etc and I've been under the assumption that optional values was the way we went. I also thought that it was in the protocol. It seems that this wasn't documented anywhere and shows that it should have been documented either way somewhere. I think somehow the statement has been lost because there's nothing written anywhere on what you have to implement in a package. It seems that we are all in agreement that you must support properties/signal/event/statistics so I propose that we add text to the implementor's guide to this effect. Values: it still seems that we have some differing opinions. I don't think the case has to be so unsual for you not to implement a value of a property in your media gateway. Anything that describes the use of resources may be different from MG to MG. Even the same vendors/operators MGs are provisioned with different equipment which would represent a different value but the same property. I don't see the need to have a different package in this case and they should still be compliant with the protocol. I think the case of supporting ALL values would be the odd case in all but the simplest of packages. I'd still like that the values are optional unless specified to be mandatory. I'm not convinced mandatory support of all values is workable in the real world. Cheers, Christian "Rosen, Brian" wrote: > > I'll chime in late here with the opinion that in some really unusual > cases, it may make sense to have some values that the MG doesn't implement. > The codec list is one, and anything that recognized a preexisting IANA list > might be another. > > I think that, by default, if you implement the package, you implement all of > it. > I think that if there was a need, you could state, in the definition of the > package, that implementation of some values can be optional. I'd make the > language be pretty limiting, recommending that it's a bad idea,... > Of course an AuditCapability of that descriptor should return the values > implemented. > > Brian > > > -----Original Message----- > > From: John Segers [mailto:jsegers@LUCENT.COM] > > Sent: Sunday, August 27, 2000 8:15 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Support of Values in Packages > > > > > > Flemming, > > > > Flemming Andreasen wrote: > > > > > OK, I understood it differently. All you want, is the > > ability to define a package, > > > and in that package you then specify that which values are > > optional and which are > > > mandatory ? > > > > Allowing this would certainly give a lot more flexibility and > > I believe > > that something like this could be allowed in package definitions. > > > > If we do allow this, then, we should consider adding some > > text somewhere > > (implementor's guide probably). This to prevent people from > > claiming to > > support the DTMF detection package, and only detect digits 0-8: the > > package doesn't say that support for 9 is mandatory. I am not certain > > whether one statement could cover all existing packages or > > that we would > > have to address them separately. > > > > > > I also agree > > > > that there's a need for clarification on what auditing > > Signals means. > > > > > > > > Could you elaborate on how we would be deflating the > > package concept by > > > > clarifying the Values are optional? > > > > > > My main concern is having MG A and MG B both support > > package P and yet my MGC > > > doesn't know what they actually implement. So far, it would > > simply be defined by > > > whatever is defined in package P and interoperability > > becomes very simple. We now > > > add an extra dimension to the package concept. As long as > > the package, not the MG, > > > defines what can be optional that's probably fine. It does > > leave open the issue of > > > finding out which of the optional values are actually > > supported. Ideally, you > > > would like to be able to figure that out ahead of time > > rather than by trial and > > > error. > > > > I agree that documenting the status (mandatory/optional) of values in > > packages is better than leaving it up to the MG and that > > trial and error > > is far from ideal. At the risk of upsetting Brian, but at > > the same time > > increasing the chances of getting him to think about this > > issue, might I > > suggest that provisioning could be used? > > > > Cheers, > > > > John > > > > > > -- > > John Segers email: jsegers@lucent.com > > Lucent Technologies Room HE 306 > > Dept. Forward Looking Work phone: +31 35 687 4724 > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 01:49:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02900 for ; Tue, 29 Aug 2000 01:49:57 -0400 (EDT) Received: from standards (47.234.32.16:1885) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C9CB@standards.nortelnetworks.com>; Tue, 29 Aug 2000 1:36:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36450 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 01:36:43 -0400 Received: from globespan.net (216.6.89.98:1608) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C9BF@standards.nortelnetworks.com>; Tue, 29 Aug 2000 1:26:41 -0400 Received: from globespan.net (sphilip.india.ficon-tech.com [172.25.1.104]) by globespan.net (8.9.3/8.9.3) with ESMTP id LAA60918 for ; Tue, 29 Aug 2000 11:07:39 +0530 (IST) (envelope-from sphilip@globespan.net) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <39A5B606.5BDDA65F@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39AB4C5B.590E3962@globespan.net> Date: Tue, 29 Aug 2000 11:08:36 +0530 Reply-To: Shalini Philip Sender: "Media Gateway Control (megaco)" From: Shalini Philip Organization: Globespan Inc. Subject: Re: Topology for non existing terminations To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Christian and all, I differ with your statement that if you add the termination back you will need to respecify the topology. IMO, whenever terminations are added to a context, the last specified value of the topology descriptor is used, unless a new one is specified by MGC in the same action. So, the MGC need not always respecify the topology whenever terminations are added to a context. If the topology descriptor does not have any information regarding the termination to be added, the default topology of bothway would be applied. Any comments? Thanks & Regards, Shalini Philip. Christian Groves wrote: > G'Day Xiaotao, > > I belive topology is only valid for the action after it, thus if you > subtract a termination A you also lose the topology associated with it. > Therefore if you add it back you will need to respecify the topology. > > Cheers, Christian > > Xiaotao Wu wrote: > > > > Is it valid to specify Topology for the terminations not in the context? > > > > For Add termination command, we in fact do this if we specify the topology > > for the terminations we want to add in. We deal with topology first before > > we add the terminations in. > > > > If we can do this, when the wildcard is used to specify the topology, > > whether this topology will also be applied to the future terminations? > > e.g., we do (*, *, ISOLATE), later on, we add a termination A, A should be > > ISOLATE with others, or A is connected to the others by default BOTHWAY? > > > > Can we keep the topology if the terminations are not in the > > context? E.g., we have (A, B, ONEWAY), then we do Subtract B, and B is > > removed from the context. If later on, we add B back, what will be the > > topology between A and B? Still be ONEWAY or just the default BOTHWAY? > > > > Thanks! > > > > -Xiaotao > > > > ==================================================== > > Name : Xiaotao Wu (Always available by email!) > > Email: xiaotaow@cs.columbia.edu, xw71@columbia.edu > > URL : http://www.cs.columbia.edu/~xiaotaow > > Work Phone: (212)939-7087, Home Phone: (212)795-1963 > > Office: Room 623, Schapiro (CEPSR), West 120th > > ==================================================== -- Regards, Shalini Philip Globespan Inc. E-Mail : mailto:sphilip@globespan.net Web : http://www.globespan.net From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 03:39:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11069 for ; Tue, 29 Aug 2000 03:39:01 -0400 (EDT) Received: from standards (47.234.32.16:4769) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CA54@standards.nortelnetworks.com>; Tue, 29 Aug 2000 3:25:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36626 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 03:25:50 -0400 Received: from hd2.dot.net.in (hd2.vsnl.net.in) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CA53@standards.nortelnetworks.com>; Tue, 29 Aug 2000 3:25:48 -0400 Received: from hyd.chiplogic.com ([203.197.21.159]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id NAA25350 for ; Tue, 29 Aug 2000 13:04:51 +0530 (IST) Received: from chiplogic.com ([192.168.2.163]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id NAA11038 for ; Tue, 29 Aug 2000 13:11:12 +0530 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {TLC;RETAIL} (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <39A5B606.5BDDA65F@ericsson.com> <39AB4C5B.590E3962@globespan.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39AB68F9.D5DA1ABA@chiplogic.com> Date: Tue, 29 Aug 2000 13:10:42 +0530 Reply-To: chennu Sender: "Media Gateway Control (megaco)" From: chennu Organization: Chiplogic India (P) Ltd. Subject: Re: Topology for non existing terminations To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi , I agree with Christain topology for the Termination subtracted from a Context is lost. My reasoning : When you subtract a termination from a context you are not sure whether that termination is added again to the same context or not. I think, the topology descriptor can be retained only when placing a termination on hold. Thanks, Chennu. Shalini Philip wrote: > Hello Christian and all, > I differ with your statement that if you add the termination back you will > need to respecify the topology. IMO, whenever terminations are added to a > context, the last specified value of the topology descriptor is used, unless a > new one is specified by MGC in the same action. So, the MGC need not always > respecify the topology whenever terminations are added to a context. If the > topology descriptor does not have any information regarding the termination to > be added, the default topology of bothway would be applied. > > Any comments? > > Thanks & Regards, > Shalini Philip. > > Christian Groves wrote: > > > G'Day Xiaotao, > > > > I belive topology is only valid for the action after it, thus if you > > subtract a termination A you also lose the topology associated with it. > > Therefore if you add it back you will need to respecify the topology. > > > > Cheers, Christian > > > > Xiaotao Wu wrote: > > > > > > Is it valid to specify Topology for the terminations not in the context? > > > > > > For Add termination command, we in fact do this if we specify the topology > > > for the terminations we want to add in. We deal with topology first before > > > we add the terminations in. > > > > > > If we can do this, when the wildcard is used to specify the topology, > > > whether this topology will also be applied to the future terminations? > > > e.g., we do (*, *, ISOLATE), later on, we add a termination A, A should be > > > ISOLATE with others, or A is connected to the others by default BOTHWAY? > > > > > > Can we keep the topology if the terminations are not in the > > > context? E.g., we have (A, B, ONEWAY), then we do Subtract B, and B is > > > removed from the context. If later on, we add B back, what will be the > > > topology between A and B? Still be ONEWAY or just the default BOTHWAY? > > > > > > Thanks! > > > > > > -Xiaotao > > > > > > ==================================================== > > > Name : Xiaotao Wu (Always available by email!) > > > Email: xiaotaow@cs.columbia.edu, xw71@columbia.edu > > > URL : http://www.cs.columbia.edu/~xiaotaow > > > Work Phone: (212)939-7087, Home Phone: (212)795-1963 > > > Office: Room 623, Schapiro (CEPSR), West 120th > > > ==================================================== > > -- > Regards, > > Shalini Philip > Globespan Inc. > E-Mail : mailto:sphilip@globespan.net > Web : http://www.globespan.net From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 03:47:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11142 for ; Tue, 29 Aug 2000 03:47:39 -0400 (EDT) Received: from standards (47.234.32.16:4769) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CA80@standards.nortelnetworks.com>; Tue, 29 Aug 2000 3:34:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36625 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 03:34:35 -0400 Received: from ace.hss.co.in (202.54.26.201:1235) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CA52@standards.nortelnetworks.com>; Tue, 29 Aug 2000 3:24:30 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by ace.hss.co.in (8.10.0/8.10.0) with SMTP id e7T7c5201061 for ; Tue, 29 Aug 2000 13:08:07 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525694A.0028F2F4 ; Tue, 29 Aug 2000 12:57:15 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525694A.0028EC57.00@sandesh.hss.hns.com> Date: Tue, 29 Aug 2000 13:02:05 +0530 Reply-To: chassija@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Chanchal Hassija Subject: Re: Topology for non existing terminations To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello All.... As mentioned in the protocol document...... "If a required descriptor other than the audit descriptor is unspecified (i.e. entirely absent) from a command, the previous values set in that descriptor for that termination are retained." So this implies that if you subtract Termination A from a context and then add it back without respecifying the topology descriptor, then you should retain the old topology descriptor. But then we should look at the following points before we accept the above statement as the ultimate truth.. a) Topology Descriptor is maintained at context level(unlike other descriptors) because it applies to a context rather than to terminations. So if I take a termination A out of a context, the topology descriptor is no more associated with the termination.... b) All events that took place in the interval between -- when the termination A was taken out of the context and when it was brought back might have made the existing Topology Descriptor entirely invalid. For eg... (assuming B is the other termination in the context) b1) The termination B with whom the association for A was defined, got subtracted out of the context in the interval. b2) The topology descriptor for association of B with A was changed in the interval. So A can't assume that it shall still have the same topology descriptor as it had earlier. IMHO : If a termination is subtracted from a context, the topology descriptor should be updated to remove this termination altogether. Else, all the mess (because of terminations which got subtracted and never returned) that shall get inserted in the descriptor shall stay there throughout the life of the context. And if the termination is added back later, respecify the topology descriptor. But this approach might have the overhead of too much processing w.r.t topology descriptor.... What do others feel about it ? Your Comments are Welcome... Enjoy Chanchal... Shalini Philip on 08/29/2000 11:08:36 AM Please respond to Shalini Philip To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Chanchal Hassija/HSS) Subject: Re: Topology for non existing terminations Hello Christian and all, I differ with your statement that if you add the termination back you will need to respecify the topology. IMO, whenever terminations are added to a context, the last specified value of the topology descriptor is used, unless a new one is specified by MGC in the same action. So, the MGC need not always respecify the topology whenever terminations are added to a context. If the topology descriptor does not have any information regarding the termination to be added, the default topology of bothway would be applied. Any comments? Thanks & Regards, Shalini Philip. Christian Groves wrote: > G'Day Xiaotao, > > I belive topology is only valid for the action after it, thus if you > subtract a termination A you also lose the topology associated with it. > Therefore if you add it back you will need to respecify the topology. > > Cheers, Christian > > Xiaotao Wu wrote: > > > > Is it valid to specify Topology for the terminations not in the context? > > > > For Add termination command, we in fact do this if we specify the topology > > for the terminations we want to add in. We deal with topology first before > > we add the terminations in. > > > > If we can do this, when the wildcard is used to specify the topology, > > whether this topology will also be applied to the future terminations? > > e.g., we do (*, *, ISOLATE), later on, we add a termination A, A should be > > ISOLATE with others, or A is connected to the others by default BOTHWAY? > > > > Can we keep the topology if the terminations are not in the > > context? E.g., we have (A, B, ONEWAY), then we do Subtract B, and B is > > removed from the context. If later on, we add B back, what will be the > > topology between A and B? Still be ONEWAY or just the default BOTHWAY? > > > > Thanks! > > > > -Xiaotao > > > > ==================================================== > > Name : Xiaotao Wu (Always available by email!) > > Email: xiaotaow@cs.columbia.edu, xw71@columbia.edu > > URL : http://www.cs.columbia.edu/~xiaotaow > > Work Phone: (212)939-7087, Home Phone: (212)795-1963 > > Office: Room 623, Schapiro (CEPSR), West 120th > > ==================================================== -- Regards, Shalini Philip Globespan Inc. E-Mail : mailto:sphilip@globespan.net Web : http://www.globespan.net From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 05:06:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11637 for ; Tue, 29 Aug 2000 05:06:42 -0400 (EDT) Received: from standards (47.234.32.16:4585) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CAEB@standards.nortelnetworks.com>; Tue, 29 Aug 2000 4:53:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36785 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 04:53:23 -0400 Received: from globespan.net (216.6.89.98:4445) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CAD0@standards.nortelnetworks.com>; Tue, 29 Aug 2000 4:43:21 -0400 Received: from sumit.globespan.net (hkumar.india.ficon-tech.com [172.25.1.130]) by globespan.net (8.9.3/8.9.3) with ESMTP id OAA74411 for ; Tue, 29 Aug 2000 14:24:20 +0530 (IST) (envelope-from sgarg@globespan.net) X-Sender: sgarg@mail X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.2.7.0.20000829142811.00aa7610@mail> Date: Tue, 29 Aug 2000 14:29:14 +0530 Reply-To: Sumit Garg Sender: "Media Gateway Control (megaco)" From: Sumit Garg Subject: Re: Topology for non existing terminations To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi all, I agree that the topology descriptor is maintained at the context level. As all will recall the format of the topology descriptor itself is a sequence of the form, (T1,T2, association); I believe it is implicit that T1 and T2 are terminations pertaining to the context under consideration. When T1 gets subtracted form the context all the associated topology descriptor triplets should be discarded as they no longer pertain to terminations belonging to the context. Also, implementation of this descriptor is optional and the default behavior (Bothway for all) will occur when T1 is added to the Context again where it is not implemented. Therefore, when T1 is added to the Context again it should be treated like a new termination. This way the behavior of both the cases where it has/has not been implemented will be similar. Regards, Sumit Garg At 01:02 PM 8/29/00, you wrote: Hello All.... As mentioned in the protocol document...... "If a required descriptor other than the audit descriptor is unspecified (i.e. entirely absent) from a command, the previous values set in that descriptor for that termination are retained." So this implies that if you subtract Termination A from a context and then add it back without respecifying the topology descriptor, then you should retain the old topology descriptor. But then we should look at the following points before we accept the above statement as the ultimate truth.. a) Topology Descriptor is maintained at context level(unlike other descriptors) because it applies to a context rather than to terminations. So if I take a termination A out of a context, the topology descriptor is no more associated with the termination.... b) All events that took place in the interval between -- when the termination A was taken out of the context and when it was brought back might have made the existing Topology Descriptor entirely invalid. For eg... (assuming B is the other termination in the context) b1) The termination B with whom the association for A was defined, got subtracted out of the context in the interval. b2) The topology descriptor for association of B with A was changed in the interval. So A can't assume that it shall still have the same topology descriptor as it had earlier. IMHO : If a termination is subtracted from a context, the topology descriptor should be updated to remove this termination altogether. Else, all the mess (because of terminations which got subtracted and never returned) that shall get inserted in the descriptor shall stay there throughout the life of the context. And if the termination is added back later, respecify the topology descriptor. But this approach might have the overhead of too much processing w.r.t topology descriptor.... What do others feel about it ? Your Comments are Welcome... Enjoy Chanchal... Shalini Philip on 08/29/2000 11:08:36 AM Please respond to Shalini Philip To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Chanchal Hassija/HSS) Subject: Re: Topology for non existing terminations Hello Christian and all, I differ with your statement that if you add the termination back you will need to respecify the topology. IMO, whenever terminations are added to a context, the last specified value of the topology descriptor is used, unless a new one is specified by MGC in the same action. So, the MGC need not always respecify the topology whenever terminations are added to a context. If the topology descriptor does not have any information regarding the termination to be added, the default topology of bothway would be applied. Any comments? Thanks & Regards, Shalini Philip. Christian Groves wrote: > G'Day Xiaotao, > > I belive topology is only valid for the action after it, thus if you > subtract a termination A you also lose the topology associated with it. > Therefore if you add it back you will need to respecify the topology. > > Cheers, Christian > > Xiaotao Wu wrote: > > > > Is it valid to specify Topology for the terminations not in the context? > > > > For Add termination command, we in fact do this if we specify the topology > > for the terminations we want to add in. We deal with topology first before > > we add the terminations in. > > > > If we can do this, when the wildcard is used to specify the topology, > > whether this topology will also be applied to the future terminations? > > e.g., we do (*, *, ISOLATE), later on, we add a termination A, A should be > > ISOLATE with others, or A is connected to the others by default BOTHWAY? > > > > Can we keep the topology if the terminations are not in the > > context? E.g., we have (A, B, ONEWAY), then we do Subtract B, and B is > > removed from the context. If later on, we add B back, what will be the > > topology between A and B? Still be ONEWAY or just the default BOTHWAY? > > > > Thanks! > > > > -Xiaotao > > > > ==================================================== > > Name : Xiaotao Wu (Always available by email!) > > Email: xiaotaow@cs.columbia.edu, xw71@columbia.edu > > URL : http://www.cs.columbia.edu/~xiaotaow > > Work Phone: (212)939-7087, Home Phone: (212)795-1963 > > Office: Room 623, Schapiro (CEPSR), West 120th > > ==================================================== -- Regards, Shalini Philip Globespan Inc. E-Mail : mailto:sphilip@globespan.net Web : http://www.globespan.net Regards, Sumit Garg ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sumit Garg GlobeSpan India Pvt. Ltd. E-mail: mailto:sgarg@ficon-tech.com Web: http://www.globespan.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 08:39:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15837 for ; Tue, 29 Aug 2000 08:39:04 -0400 (EDT) Received: from standards (47.234.32.16:4718) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CB8A@standards.nortelnetworks.com>; Tue, 29 Aug 2000 8:25:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37026 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 08:25:53 -0400 Received: from hd2.dot.net.in (hd2.vsnl.net.in) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CB89@standards.nortelnetworks.com>; Tue, 29 Aug 2000 8:24:58 -0400 Received: from hyd.chiplogic.com ([203.197.20.179]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id SAA23756 for ; Tue, 29 Aug 2000 18:01:11 +0530 (IST) Received: from chiplogic.com ([192.168.2.163]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id SAA17381 for ; Tue, 29 Aug 2000 18:02:18 +0530 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {TLC;RETAIL} (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF678790@whq-msgusr-02.fore.com> <39AB3878.AB683DEE@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39ABAD2E.F0CAD7C9@chiplogic.com> Date: Tue, 29 Aug 2000 18:01:42 +0530 Reply-To: chennu Sender: "Media Gateway Control (megaco)" From: chennu Organization: Chiplogic India (P) Ltd. Subject: Re: Support of Values in Packages To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, Extending the same discussion I have a doubt. I will first give my current understanding on how an MGC knows about a MG. * First AuditCapability command is sent to know the list of terminations supported by the MG. * Then AuditValue command is sent to know which packages are supported by each termination. With this we will come to know about all parameters in signals & events , and properties supported by the termination. * Then AuditCapability command is sent to know what are the Media properties(defined in Annex C) and values supported by each property. Also the possible values of parameters in signals & events and properties supported by the termination. As Christian said , I think, AuditCapability is done to know only the supported values in parameters of the signals & events and properties rather than the all the possible values. I am not sure whether this should be allowed with all the parameters in the signals & events and properties. But if possible some text can be added to make some of the values optional. Please correct me if my understanding is wrong. Thanks, Chennu. Christian Groves wrote: > G'Day Brian, all, > > I could have sworn that we had discussed this back in Red Bank last year > when discussing inheritance of packages etc and I've been under the > assumption that optional values was the way we went. I also thought that > it was in the protocol. It seems that this wasn't documented anywhere > and shows that it should have been documented either way somewhere. I > think somehow the statement has been lost because there's nothing > written anywhere on what you have to implement in a package. > > It seems that we are all in agreement that you must support > properties/signal/event/statistics so I propose that we add text to the > implementor's guide to this effect. > > Values: it still seems that we have some differing opinions. > > I don't think the case has to be so unsual for you not to implement a > value of a property in your media gateway. Anything that describes the > use of resources may be different from MG to MG. Even the same > vendors/operators MGs are provisioned with different equipment which > would represent a different value but the same property. I don't see the > need to have a different package in this case and they should still be > compliant with the protocol. I think the case of supporting ALL values > would be the odd case in all but the simplest of packages. I'd still > like that the values are optional unless specified to be mandatory. I'm > not convinced mandatory support of all values is workable in the real > world. > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > I'll chime in late here with the opinion that in some really unusual > > cases, it may make sense to have some values that the MG doesn't implement. > > The codec list is one, and anything that recognized a preexisting IANA list > > might be another. > > > > I think that, by default, if you implement the package, you implement all of > > it. > > I think that if there was a need, you could state, in the definition of the > > package, that implementation of some values can be optional. I'd make the > > language be pretty limiting, recommending that it's a bad idea,... > > Of course an AuditCapability of that descriptor should return the values > > implemented. > > > > Brian > > > > > -----Original Message----- > > > From: John Segers [mailto:jsegers@LUCENT.COM] > > > Sent: Sunday, August 27, 2000 8:15 PM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Support of Values in Packages > > > > > > > > > Flemming, > > > > > > Flemming Andreasen wrote: > > > > > > > OK, I understood it differently. All you want, is the > > > ability to define a package, > > > > and in that package you then specify that which values are > > > optional and which are > > > > mandatory ? > > > > > > Allowing this would certainly give a lot more flexibility and > > > I believe > > > that something like this could be allowed in package definitions. > > > > > > If we do allow this, then, we should consider adding some > > > text somewhere > > > (implementor's guide probably). This to prevent people from > > > claiming to > > > support the DTMF detection package, and only detect digits 0-8: the > > > package doesn't say that support for 9 is mandatory. I am not certain > > > whether one statement could cover all existing packages or > > > that we would > > > have to address them separately. > > > > > > > > I also agree > > > > > that there's a need for clarification on what auditing > > > Signals means. > > > > > > > > > > Could you elaborate on how we would be deflating the > > > package concept by > > > > > clarifying the Values are optional? > > > > > > > > My main concern is having MG A and MG B both support > > > package P and yet my MGC > > > > doesn't know what they actually implement. So far, it would > > > simply be defined by > > > > whatever is defined in package P and interoperability > > > becomes very simple. We now > > > > add an extra dimension to the package concept. As long as > > > the package, not the MG, > > > > defines what can be optional that's probably fine. It does > > > leave open the issue of > > > > finding out which of the optional values are actually > > > supported. Ideally, you > > > > would like to be able to figure that out ahead of time > > > rather than by trial and > > > > error. > > > > > > I agree that documenting the status (mandatory/optional) of values in > > > packages is better than leaving it up to the MG and that > > > trial and error > > > is far from ideal. At the risk of upsetting Brian, but at > > > the same time > > > increasing the chances of getting him to think about this > > > issue, might I > > > suggest that provisioning could be used? > > > > > > Cheers, > > > > > > John > > > > > > > > > -- > > > John Segers email: jsegers@lucent.com > > > Lucent Technologies Room HE 306 > > > Dept. Forward Looking Work phone: +31 35 687 4724 > > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 09:22:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17137 for ; Tue, 29 Aug 2000 09:22:23 -0400 (EDT) Received: from standards (47.234.32.16:2134) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CBCD@standards.nortelnetworks.com>; Tue, 29 Aug 2000 9:09:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37111 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 09:09:08 -0400 Received: from hd2.dot.net.in (hd2.vsnl.net.in) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CBCC@standards.nortelnetworks.com>; Tue, 29 Aug 2000 9:09:04 -0400 Received: from hyd.chiplogic.com ([203.197.20.179]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id SAA16375 for ; Tue, 29 Aug 2000 18:48:12 +0530 (IST) Received: from chiplogic.com ([192.168.2.163]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id SAA18684 for ; Tue, 29 Aug 2000 18:53:18 +0530 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {TLC;RETAIL} (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01706828@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39ABB926.479A345A@chiplogic.com> Date: Tue, 29 Aug 2000 18:52:46 +0530 Reply-To: chennu Sender: "Media Gateway Control (megaco)" From: chennu Organization: Chiplogic India (P) Ltd. Subject: Re: Is ServiceChangeMgcId Optional on Cold Start? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Brian, The text explaining ServiceChangeMgcId is contradictory. I am giving the text in 7.2.8 of Megaco-merged-01 document "ServiceChangeMgcId provides an alternative address where the MG should seek to establish another association." I am giving some more lines under the same section "The return from ServiceChange is empty except when the Root terminationID is used. In that case it includes the following parameters as required: * ServiceChangeMgcId, if the responding MGC does not wish to sustain an association with the MG " I think this text makes more meaning and the ServiceChangeMgcId should be omitted when MGC accepts the ServiceChange command from MG. Thanks, Chennu. "Rosen, Brian" wrote: > This is the first in what I expect will be a series of > issues that we discover at the Interop. Yes, testing has not > begun yet, but we already have one. The question is, what does > the MGC send in a ServiceChange reply? > > The text currently states: > Upon a cold start of the MG, it will issue a > ServiceChange command with a "Restart" method, on the Root > Termination to its primary MGC. If the MGC accepts the MG, > it will send a Transaction Accept, with the ServiceChangeMgcId > set to itself. > > Note that this implies ServiceChangeMgcId is not optional. > I think this is incorrect and the text should state: > "...with the ServiceChangeMgcId omitted or set to itself." > > Following the usual IETF dictum about "be strict in what you > send, liberal in what you accept", MGCs SHOULD set > ServiceChangeMgcId, MGs should NOT depend on it. > > Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 09:57:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18065 for ; Tue, 29 Aug 2000 09:57:57 -0400 (EDT) Received: from standards (47.234.32.16:3665) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CC0C@standards.nortelnetworks.com>; Tue, 29 Aug 2000 9:44:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37196 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 09:44:53 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CC0B@standards.nortelnetworks.com>; Tue, 29 Aug 2000 9:44:52 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA16394 for ; Tue, 29 Aug 2000 09:57:29 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA02648 for ; Tue, 29 Aug 2000 09:57:26 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 09:57:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF67879C@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 09:57:22 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Interop Testing has Started!!! To: MEGACO@STANDARDS.NORTELNETWORKS.COM Just a short note to let you know that we have begun testing in earnest. We have 18 organizations present. There are 6 MGC implementations and 13 MGC implementations, plus several test system developers. Several of the MGC developers have kindly brought more than one system, so we have all MGs that are really ready to test being tested. There is a lot of intense work going on right now! Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 10:12:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18627 for ; Tue, 29 Aug 2000 10:12:31 -0400 (EDT) Received: from standards (47.234.32.16:4966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CC2D@standards.nortelnetworks.com>; Tue, 29 Aug 2000 9:59:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37240 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 09:59:17 -0400 Received: from qhars002.nortel.com (47.101.112.102:33979) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CC2C@standards.nortelnetworks.com>; Tue, 29 Aug 2000 9:59:12 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Tue, 29 Aug 2000 15:05:04 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Tue, 29 Aug 2000 09:06:10 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 29 Aug 2000 09:04:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C011C2.033A1680" Message-ID: <8E2783FA4E0CD411888D0000F8CD15D33C3911@zcard00q.ca.nortel.com> Date: Tue, 29 Aug 2000 09:04:14 -0500 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: resend: I-D posted: Megaco IP Phone MG 03 To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01C011C2.033A1680 Content-Type: text/plain; charset="iso-8859-1" Resend. The below summary of updates in Megaco IP Phone 03 does not appear to have made it to the list. The I-D is now available on-line at: http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-03.txt -----Original Message----- From: Blatherwick, Peter [CAR:AT14:EXCH] Sent: Friday, August 25, 2000 13:01 To: 'Megaco' Cc: 'Bob Bell (Cisco)'; 'Phil Holland (Circa)' Subject: I-D posted: Megaco IP Phone MG 03 Greetings: An updated version of the Megaco IP Phone MG I-D has been submitted as "draft-ietf-megaco-ipphone-03.txt". Updates include: - Removed text regarding subset profile (as proposed and agreed IETF 47), - Added description of termination naming conventions (last remaining technical issue), - Clarified spec covers minimum functionality only, with optional binary encoding, TCP and other transports, extensions (as agreed IETF 47) - Marked as Informational (as agreed IETF 47), - Added sections on Conventions (per RFC 2119) and Security Considerations (null section), - Editorial fix-ups. Above is all as previously agreed. Technical issues and dependencies are now complete. We believe the document is ready for Last Call. Regards, Peter Blatherwick Bob Bell Phil Holland ------_=_NextPart_001_01C011C2.033A1680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable resend: I-D posted: Megaco IP Phone MG 03

Resend.  The below summary = of updates in Megaco IP Phone 03 does not appear to have made it to the = list.  The I-D is now available on-line at: http://www.ietf.org/internet-drafts/draft-ietf-megaco-= ipphone-03.txt


-----Original = Message-----
From: Blatherwick, Peter = [CAR:AT14:EXCH]
Sent: Friday, August 25, 2000 = 13:01
To: 'Megaco'
Cc: 'Bob Bell (Cisco)'; 'Phil = Holland (Circa)'
Subject: I-D posted: Megaco IP = Phone MG 03


Greetings:

An updated version of the Megaco = IP Phone MG I-D has been
submitted as = "draft-ietf-megaco-ipphone-03.txt". 

Updates include:
- Removed text regarding subset = profile (as proposed and
  agreed IETF 47),
- Added description of = termination naming conventions
  (last remaining = technical issue),
- Clarified spec covers minimum = functionality only, with
  optional binary = encoding, TCP and other transports,
  extensions (as agreed = IETF 47)
- Marked as Informational (as = agreed IETF 47),
- Added sections on Conventions = (per RFC 2119) and Security
  Considerations (null = section),
- Editorial fix-ups.

Above is all as previously = agreed.  Technical issues and
dependencies are now = complete.  We believe the document is
ready for Last = Call.   

Regards,
Peter Blatherwick
Bob Bell
Phil Holland

------_=_NextPart_001_01C011C2.033A1680-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 10:23:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18996 for ; Tue, 29 Aug 2000 10:23:21 -0400 (EDT) Received: from standards (47.234.32.16:4966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CC57@standards.nortelnetworks.com>; Tue, 29 Aug 2000 10:10:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37294 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 10:10:06 -0400 Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CC56@standards.nortelnetworks.com>; Tue, 29 Aug 2000 10:10:06 -0400 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA09615 for ; Tue, 29 Aug 2000 10:22:45 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA09547 for ; Tue, 29 Aug 2000 10:22:44 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA07085; Tue, 29 Aug 2000 16:22:37 +0200 (MET DST) Received: from hzsgg01.nl.lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA07077; Tue, 29 Aug 2000 16:22:35 +0200 (MET DST) Received: from lucent.com by hzsgg01.nl.lucent.com (8.8.8+Sun/EMS-1.4.1 client sol2) id QAA25742; Tue, 29 Aug 2000 16:22:34 +0200 (MET DST) X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Original-CC: MEGACO@standards.nortelnetworks.com References: <20000812200212.10329.qmail@web6402.mail.yahoo.com> <002c01c00524$873da6e0$ce1017d4@mike> <14744.22673.951871.609884@thomasm-u1.cisco.com> <002a01c006b5$95136f60$481017d4@mike> <14745.59261.564728.186405@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39ABC789.C69AC4CA@lucent.com> Date: Tue, 29 Aug 2000 16:24:09 +0200 Reply-To: Paul Sijben Sender: "Media Gateway Control (megaco)" From: Paul Sijben Organization: Lucent technologies, The Netherlands Subject: Re: MG and DiffServ X-To: Michael Thomas To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I agree. Flemming, I'd gladly help in drawing up the appropriate packages. Paul Michael Thomas wrote: > > Mike Buckley writes: > > > Since e-2-e QoS needs to be initiated by device, > > > that means that the on-the-wire protocol that > > > controls the device (MGC) needs a means to > > > instruct the dumb device (MG) of the correct QoS > > > policy to initiate. This is no different in > > > principal than the MGC telling the MG what codec > > > it prefers the MG to use. > > > > Not sure I followed this. Are you saying that Megaco should carry details > > of the transport QoS mechanisms that may be supported in the MG? > > Absolutely. The MG may have no idea what QoS > policy is appropriate, and in fact it may > change on a call by call basis which says that > it *must* be setable from the MGC. > > Mike -- Paul Sijben Tel:+31 356874774 Lucent Technologies Message:+31 208702874 Forward Looking Work Fax: +31 208702874 Huizen, The Netherlands http://voip.nl.lucent.com/~sijben (internal) From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 10:50:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20218 for ; Tue, 29 Aug 2000 10:50:52 -0400 (EDT) Received: from standards (47.234.32.16:4966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CD45@standards.nortelnetworks.com>; Tue, 29 Aug 2000 10:37:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37537 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 10:37:34 -0400 Received: from qhars002.nortel.com (47.101.112.102:38923) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CD14@standards.nortelnetworks.com>; Tue, 29 Aug 2000 10:27:33 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Tue, 29 Aug 2000 15:39:24 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Tue, 29 Aug 2000 09:34:03 -0500 Received: from zrtpd00x.us.nortel.com ([47.140.224.108]) by zrchb213.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id R5FC5NY4; Tue, 29 Aug 2000 09:37:41 -0500 Received: from americasm01.nt.com (brtphe34.us.nortel.com [47.202.35.89]) by zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id RJ6RWTCM; Tue, 29 Aug 2000 10:37:35 -0400 X-Mailer: Mozilla 4.72 [en] (X11; U; HP-UX B.10.20 9000/778) X-Accept-Language: en MIME-Version: 1.0 References: <39A5959A.34FA015B@ericsson.com> <39A677AE.6DB5635@cisco.com> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Message-ID: <39ABCDE6.893C0FEA@americasm01.nt.com> Date: Tue, 29 Aug 2000 10:51:19 -0400 Reply-To: Kevin Boyle Sender: "Media Gateway Control (megaco)" From: Kevin Boyle Organization: Nortel Networks Subject: Re: Support of Values in Packages To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I am resending this, since it apparently floated off into the ether, never to be seen again.  I apologize for any duplication that may occur.

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

Hello,

A general question here:

What, exactly, is meant by "support" of a signal?  Does this mean that a gateway will absolutely know what the physical parameters of the signal are, and will play it?  Or does it mean something a little less than that, for instance, that the gateway will gracefully accept the signal in question, not necessarily doing anything about it?

Generally speaking, signals, and tones in particular, have very precise definitions as to when and how they should be used.  So, if there are no phones in need of a particular signal off of a gateway, in theory, that signal would never be requested by the MGC.  However, if it was, by the package definition, the MG would be required to support it.  Is it incorrect, then, for the MG to successfully acknowledge the signal application command, and then throw the signal away?  Maybe the signal could be datafilled to be/do nothing in the MG, in which case ignoring the signal would be a correct application of the signal to the line.

MGCs have a little different issue with the meaning of "support".  Just because a MGC supports the ability to generate a particular signal to a MG, does not necessarily mean that MGC will ever do so.  In this case, "support" becomes a pretty meaningless term.  If a signal is never going to be generated, then what does support really mean?  That the MGC can generate the signal through manual intervention?

The same argument about signal support in MGCs also applies to events as well.  If we will never ask for a particular event, what does support of that event mean?  For MGs, the same is not true.  A MG must be able to report a supported event when it is requested in the Events descriptor.  So support of events from a MG standpoint is fairly straightforward.  Since properties and statistics are acted upon in both directions, support is also a straightforward concept for these as well.

I, too, agree that there is an issue regarding values, as highlighted by the codec example.  In the same vein, there needs to be a better definition of what support means, especially in regards to signals and events.  I propose, as a starting point for discussion, that "support" of signals in the MG means that the MG will accept the signal, and acknowledge it without error, at the very minimum.  Any problem with MGs choosing to ignore important signals will be rectified by the MG's inability to produce quality telephone service without those signals.  "Support" in the MGC is a little tougher issue, since support of a signal or event is invisible until such time as the signal or event is requested.

Any comments/ideas/statements to correct my misconceptions? ;)

Regards,

Kevin Boyle
CS2K Line Services
Nortel Networks

Flemming Andreasen wrote:

Christian Groves wrote:

> G'Day all,
>
> There has been some confusion at the SG16 on what is supported in
> Packages.
>
> The understanding that I had was that: If you support a package you must
> support all the signals, properties, events and statistics.

Agreed.

> However you
> do not have to support all the values associated with the properties and
> parameters.

I guess the term "values" is somewhat prone to interpretation, but I would
tend to disagree if we refer to a list of well-defined values, as e.g. a
list of tone ids in E.7.

>
>
> Tom mentioned that a thread discussed on the list contravened this.
>
> The reasoning that I have for not having to support all the values is
> the following:
> o Proliferation of packages. Eg: if a package has a list of tones, and I
> must support all the values, if I only want to support a subset of these
> values then I need a new package. Therefore you may get the case of a
> package "Package Call Progress Tones E.7" where an MG doesn't support
> Payphone Recognition Tone because it doesn't have payphones connected to
> it.

However, in this parcticular example, the tones are both signals and tone
ids, so the effect would be the same. While I'm not particularly fond of the
tonegen package, it does nevertheless illustrate an important point, namely
that the distinction between signals, and parameters to signals (and similar
for other constructs) is somewhat arbitrary. The package really gives you
two things:
1. A name space
2. A convenient grouping of some set of "properties"

If we don't know exaclty what those "properties" are, then we've lost a very
important aspect of packages.

> To be compliant with H.248 I can't extend the package because I want
> to remove the payphone tone. So a new Package needs to be defined
> containing exactly the same information but without the payphone tone.
> Now my MG won't support the standard Call Progress Tone package but will
> support the XXX_companies_Call_Progress_Tone package. This would lead to
> a proliferation of packages.

I agree, but we have to ask ourselves what the idea about packages is.
Simplicity and flexibility are often at odds with each other and in this
case stress the importance of defining packages very carefully.

If I no longer know exactly what is supported in a package, how do I go
about using that package ?

>
>
> o Multiple GW support - One MG may not implement all the values of a
> property. For something like a list of codecs, a group of resources
> associated with the value may be placed in different MG GWs. ie. GSM
> codecs in MG1, PCM codecs in MG2. So whilst the MGs support the same
> package properties, they can't support a subset of values then you'd
> need to define a different package for each MG configuration. Again
> leading to a proliferation of packages.

Back to defining what "values" mean. Obviously, if we define a "codec"
property in a package, we can't expect support for every possible codec in
the world.

Maybe there's a distinction between supporting values for events, signals,
statistics, and properties ?

>
>
> o The MGC knows the PackageID, that all Properties, Signals, Events,
> Statistics are supported. In H.248 we have the AuditCapability and
> AuditValue commands to find out what actual values of properties are
> supported.

Not sure how you would do that with event and signal parameters though (come
to think of it, I'm not sure how you, in practice, do that for a lot of
parameters; "The appropriate descriptors, *with the possible values for the
Termination* are returned from AuditCapabilities", Section 7.2.6). On the
other, we could have a new property that looked similar, so it's not clear
it wouldn't apply there either.

>
>
> So if people agree that not all values in a package need to be supported
> I propose to add some text to the implementor's guide:
> Section 12.1 after 2nd Paragraph
> "A MG SHALL support all Property, Signals & parameters, Events &
> parameters and Statistics. A MG MAY support a subset of property and
> parameter values defined in the package unless specified in a package."

I don't want to deflate the package concept to the extent this would seem to
allow, but I agree there's an issue here. Further discussion is needed
before we make any change. 

-- Flemming
>
>
> Cheers, Christian

--
Flemming Andreasen
Cisco Systems

From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 11:26:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21949 for ; Tue, 29 Aug 2000 11:26:51 -0400 (EDT) Received: from standards (47.234.32.16:4966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CDDA@standards.nortelnetworks.com>; Tue, 29 Aug 2000 11:12:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37756 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 11:12:33 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CDC1@standards.nortelnetworks.com>; Tue, 29 Aug 2000 11:02:33 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id IAA26130; Tue, 29 Aug 2000 08:15:08 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF678790@whq-msgusr-02.fore.com> <39AB3878.AB683DEE@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39ABD481.59337BEE@cisco.com> Date: Tue, 29 Aug 2000 11:19:29 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: Support of Values in Packages X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Christian Groves wrote: > G'Day Brian, all, > > I could have sworn that we had discussed this back in Red Bank last year > when discussing inheritance of packages etc and I've been under the > assumption that optional values was the way we went. I also thought that > it was in the protocol. It seems that this wasn't documented anywhere > and shows that it should have been documented either way somewhere. I > think somehow the statement has been lost because there's nothing > written anywhere on what you have to implement in a package. > > It seems that we are all in agreement that you must support > properties/signal/event/statistics so I propose that we add text to the > implementor's guide to this effect. > > Values: it still seems that we have some differing opinions. > > I don't think the case has to be so unsual for you not to implement a > value of a property in your media gateway. Anything that describes the > use of resources may be different from MG to MG. Even the same > vendors/operators MGs are provisioned with different equipment which > would represent a different value but the same property. I don't see the > need to have a different package in this case and they should still be > compliant with the protocol. I think the case of supporting ALL values > would be the odd case in all but the simplest of packages. I'd still > like that the values are optional unless specified to be mandatory. I'd prefer it the other way around, not least considering that it would consistent with the current protocol text. -- Flemming BTW: Am I the only one all of a sudden getting a lot of messages with "owner-megaco" as the sender even though it's clearly not ? > I'm > not convinced mandatory support of all values is workable in the real > world. > > Cheers, Christian > -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 11:51:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23222 for ; Tue, 29 Aug 2000 11:51:36 -0400 (EDT) Received: from standards (47.234.32.16:4966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CE2D@standards.nortelnetworks.com>; Tue, 29 Aug 2000 11:38:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37893 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 11:38:08 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CE2C@standards.nortelnetworks.com>; Tue, 29 Aug 2000 11:38:08 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27184 for ; Tue, 29 Aug 2000 11:50:44 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA02397 for ; Tue, 29 Aug 2000 11:50:37 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 11:50:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF67879E@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 11:28:43 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Case Sensitivity To: MEGACO@STANDARDS.NORTELNETWORKS.COM There is confusion on whether text encoding is case sensitive or not. Several of us remember language about this, but there is none now. I believe, and the sentiment of the room (interop test room), is that everything, language tokens, terminationIds, package names/events/signals/parameters... is NOT case sensitive. Any objections? Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 11:56:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23343 for ; Tue, 29 Aug 2000 11:56:15 -0400 (EDT) Received: from standards (47.234.32.16:4966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CE4C@standards.nortelnetworks.com>; Tue, 29 Aug 2000 11:42:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37934 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 11:42:58 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CE4B@standards.nortelnetworks.com>; Tue, 29 Aug 2000 11:42:58 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA28207 for ; Tue, 29 Aug 2000 11:55:35 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 LAA04625 for ; Tue, 29 Aug 2000 11:55:35 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 11:55:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787A0@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 11:55:35 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Case Sensitivity To: MEGACO@STANDARDS.NORTELNETWORKS.COM To be really careful: SDP is defined case sensitive, and we aren't changing that quoted strings are case sensitive So, what we are really saying is that symbols are case insensitive Symbols include protocol tokens, terminationIds, package names, events and signals names, property names, statistics names and enumerated values. Brian > -----Original Message----- > From: Rosen, Brian > Sent: Tuesday, August 29, 2000 11:29 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Case Sensitivity > > > There is confusion on whether text encoding is case sensitive or not. > Several of us remember language about this, but there is none now. > > I believe, and the sentiment of the room (interop test room), > is that everything, language tokens, terminationIds, package > names/events/signals/parameters... is NOT case sensitive. > > Any objections? > > Brian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 12:44:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25521 for ; Tue, 29 Aug 2000 12:44:55 -0400 (EDT) Received: from standards (47.234.32.16:4966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CEA2@standards.nortelnetworks.com>; Tue, 29 Aug 2000 12:31:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38042 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 12:31:44 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CEA1@standards.nortelnetworks.com>; Tue, 29 Aug 2000 12:31:44 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id JAA08136; Tue, 29 Aug 2000 09:44:06 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF67879E@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39ABE95B.2A455D21@cisco.com> Date: Tue, 29 Aug 2000 12:48:27 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: Case Sensitivity X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "Rosen, Brian" wrote: > There is confusion on whether text encoding is case sensitive or not. > Several of us remember language about this, but there is none now. > > I believe, and the sentiment of the room (interop test room), > is that everything, language tokens, terminationIds, package > names/events/signals/parameters... is NOT case sensitive. > > Any objections? There shouldn't be as ABNF is case insensitive. -- Flemming > > > Brian -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 16:06:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00176 for ; Tue, 29 Aug 2000 16:06:03 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CF91@standards.nortelnetworks.com>; Tue, 29 Aug 2000 15:52:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0293 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 15:52:03 -0400 Received: from qhars002.nortel.com (47.101.112.102:37129) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CF8E@standards.nortelnetworks.com>; Tue, 29 Aug 2000 15:51:50 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Tue, 29 Aug 2000 21:03:11 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Tue, 29 Aug 2000 14:59:05 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 29 Aug 2000 15:02:43 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD11480CA9@zcard00g.ca.nortel.com> Date: Tue, 29 Aug 2000 15:02:34 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Is ServiceChangeMgcId Optional on Cold Start? X-To: chennu To: MEGACO@STANDARDS.NORTELNETWORKS.COM Please look at the words you quote again. To me the two passages both say the same thing, although the second one does it in roundabout fashion through the use of negatives. The interpretation is exactly as you say: ServiceChangeMgcId is omitted when the MGC is willing to accept the association. > -----Original Message----- > From: chennu [mailto:chennu@CHIPLOGIC.COM] > Sent: Tuesday, August 29, 2000 9:23 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Is ServiceChangeMgcId Optional on Cold Start? > > > Hi Brian, > > The text explaining ServiceChangeMgcId is contradictory. I am > giving the > text in 7.2.8 of Megaco-merged-01 document > "ServiceChangeMgcId provides an alternative address where the > MG should > seek to establish another association." > I am giving some more lines under the same section > "The return from ServiceChange is empty except when the Root > terminationID is used. In that case it includes the following > parameters as required: > * ServiceChangeMgcId, if the responding MGC does not wish > to sustain > an association with the MG " > I think this text makes more meaning and the ServiceChangeMgcId should > be omitted when MGC accepts the ServiceChange command from MG. > > Thanks, > Chennu. > > > "Rosen, Brian" wrote: > > > This is the first in what I expect will be a series of > > issues that we discover at the Interop. Yes, testing has not > > begun yet, but we already have one. The question is, what does > > the MGC send in a ServiceChange reply? > > > > The text currently states: > > Upon a cold start of the MG, it will issue a > > ServiceChange command with a "Restart" method, on the Root > > Termination to its primary MGC. If the MGC accepts the MG, > > it will send a Transaction Accept, with the ServiceChangeMgcId > > set to itself. > > > > Note that this implies ServiceChangeMgcId is not optional. > > I think this is incorrect and the text should state: > > "...with the ServiceChangeMgcId omitted or set to itself." > > > > Following the usual IETF dictum about "be strict in what you > > send, liberal in what you accept", MGCs SHOULD set > > ServiceChangeMgcId, MGs should NOT depend on it. > > > > Brian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 16:08:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00241 for ; Tue, 29 Aug 2000 16:08:39 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CFBC@standards.nortelnetworks.com>; Tue, 29 Aug 2000 15:55:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0350 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 15:55:21 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CFBB@standards.nortelnetworks.com>; Tue, 29 Aug 2000 15:55:20 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA19274 for ; Tue, 29 Aug 2000 16:07:57 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA04928 for ; Tue, 29 Aug 2000 16:07:58 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 16:07:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787A5@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 16:07:57 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Is Media required on the Physical Termination/Default value for M ODE To: MEGACO@STANDARDS.NORTELNETWORKS.COM Another issue from the event: Is it REQUIRED that the MGC send a media descriptor to a PHYSICAL termination in order to get media to flow? There are two questions actually: 1) Is there a default state of MODE (text is silent) 2) Should the MG demand a media descriptor before allowing media flow? I believe: 1) The default for MODE is SendRecieve 2) MGCs should always send a media descriptor, with at least a MODE setting 3) MGs should not depend on 2) Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 16:10:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00275 for ; Tue, 29 Aug 2000 16:10:49 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CFD7@standards.nortelnetworks.com>; Tue, 29 Aug 2000 15:57:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0386 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 15:57:39 -0400 Received: from qhars002.nortel.com (47.101.112.102:37446) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CFD6@standards.nortelnetworks.com>; Tue, 29 Aug 2000 15:57:39 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Tue, 29 Aug 2000 21:10:15 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Tue, 29 Aug 2000 16:09:47 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 29 Aug 2000 16:09:41 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 29 Aug 2000 16:08:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <28560036253BD41191A10000F8BCBD11480CAB@zcard00g.ca.nortel.com> Date: Tue, 29 Aug 2000 16:09:33 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Case Sensitivity X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Yes, that was the intent. I can't find any language either. I know we took some of it out of Annex B in Red Bank or Geneva, but that was partly in the belief that it was covered elsewhere. > -----Original Message----- > From: Rosen, Brian [ mailto:Brian.Rosen@MARCONI.COM ] > Sent: Tuesday, August 29, 2000 11:56 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Case Sensitivity > > > To be really careful: > SDP is defined case sensitive, and we aren't changing that > quoted strings are case sensitive > So, what we are really saying is that symbols are case insensitive > Symbols include protocol tokens, terminationIds, package names, > events and signals names, property names, statistics names > and enumerated values. > > Brian > > > -----Original Message----- > > From: Rosen, Brian > > Sent: Tuesday, August 29, 2000 11:29 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Case Sensitivity > > > > > > There is confusion on whether text encoding is case > sensitive or not. > > Several of us remember language about this, but there is none now. > > > > I believe, and the sentiment of the room (interop test room), > > is that everything, language tokens, terminationIds, package > > names/events/signals/parameters... is NOT case sensitive. > > > > Any objections? > > > > Brian > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 16:23:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00340 for ; Tue, 29 Aug 2000 16:23:06 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CFFA@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:09:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0432 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 16:09:53 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CFF9@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:09:53 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA20610 for ; Tue, 29 Aug 2000 16:22:30 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 QAA08442 for ; Tue, 29 Aug 2000 16:22:31 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 16:22:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787A7@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 16:22:30 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Error in text on interim AH header To: MEGACO@STANDARDS.NORTELNETWORKS.COM There is an error in the text in section 10.2 Interim AH scheme in the sentence: ...........To retain the same functionality, the ICV calculation should be performed across the entire transaction prepended by a synthesized IP header consisting of a 32 bit source IP address, a 32 bit destination address and a 16 bit UDP destination port encoded as 10 hex digits. The error is "10 hex digits". It should be 20 hex digits, representing 10 bytes (4 source, 4 dest, 2 port). Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 16:25:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00377 for ; Tue, 29 Aug 2000 16:25:50 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D015@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:12:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0467 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 16:12:11 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D014@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:12:10 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA20796 for ; Tue, 29 Aug 2000 16:24:47 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 QAA08949 for ; Tue, 29 Aug 2000 16:24:48 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 16:24:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787A8@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 16:24:47 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Accepting Null bodies To: MEGACO@STANDARDS.NORTELNETWORKS.COM It seems obvious to me that an MG should always accept a command which has no descriptors, assuming that the contextId and the terminationIds are legal. It's a NOP, but it's legal. Now, someone here tried to send Context= - {Subtract=*{}} That's not legal (can't subtract from null context}. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 16:25:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00381 for ; Tue, 29 Aug 2000 16:25:50 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D01A@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:12:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0472 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 16:12:19 -0400 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D019@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:12:18 -0400 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA22147; Tue, 29 Aug 2000 13:25:17 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA25635; Tue, 29 Aug 2000 13:24:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <4FBEA8857476D311A03300204840E1CF6787A5@whq-msgusr-02.fore.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Message-ID: <14764.7194.265745.489366@thomasm-u1.cisco.com> Date: Tue, 29 Aug 2000 13:24:58 -0700 Reply-To: Michael Thomas Sender: "Media Gateway Control (megaco)" From: Michael Thomas Subject: Is Media required on the Physical Termination/Default value for M ODE X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4FBEA8857476D311A03300204840E1CF6787A5@whq-msgusr-02.fore.com> Content-Transfer-Encoding: 7bit My general take has been that the MGC shouldn't assume much about the MG. If it wants the MG to do something, it should tell it. If it doesn't know the MG's state, it should audit it. Therefore, I think I disagree with the spec requiring some set of semantics for underspecified commands. What's the gain? Mike Rosen, Brian writes: > Another issue from the event: > > Is it REQUIRED that the MGC send a media descriptor to a PHYSICAL > termination in order to get media to flow? > > There are two questions actually: > 1) Is there a default state of MODE (text is silent) > 2) Should the MG demand a media descriptor before allowing media flow? > > I believe: > 1) The default for MODE is SendRecieve > 2) MGCs should always send a media descriptor, with at least a MODE > setting > 3) MGs should not depend on 2) > > Brian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 16:31:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00460 for ; Tue, 29 Aug 2000 16:31:02 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D04D@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:17:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0541 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 16:17:54 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D04C@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:17:53 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA21170; Tue, 29 Aug 2000 16:30:27 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 QAA10107; Tue, 29 Aug 2000 16:30:28 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 16:30:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787A9@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 16:30:27 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Is Media required on the Physical Termination/Default value f or M ODE X-To: Michael Thomas To: MEGACO@STANDARDS.NORTELNETWORKS.COM Okay, so what would you expect to happen if you audited media of the physical termination. Even if there was no default, it should be one of the legal states. Now, suppose it's in an acceptable state, should you have to send a media descriptor? What the folks who implemented the MG requiring the media descriptor say is that "there is no mode, you haven't set it". I can't deal with that, because audit has to return a value. So it has to be something, and the MGC should be able to leave it, right? Now, I said I think MGCs should always send media! Brian > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, August 29, 2000 4:25 PM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Is Media required on the Physical > Termination/Default value for > M ODE > > > > My general take has been that the MGC shouldn't > assume much about the MG. If it wants the MG to > do something, it should tell it. If it doesn't > know the MG's state, it should audit it. > Therefore, I think I disagree with the spec > requiring some set of semantics for underspecified > commands. What's the gain? > > Mike > > Rosen, Brian writes: > > Another issue from the event: > > > > Is it REQUIRED that the MGC send a media descriptor to a PHYSICAL > > termination in order to get media to flow? > > > > There are two questions actually: > > 1) Is there a default state of MODE (text is silent) > > 2) Should the MG demand a media descriptor before allowing > media flow? > > > > I believe: > > 1) The default for MODE is SendRecieve > > 2) MGCs should always send a media descriptor, with at least a MODE > > setting > > 3) MGs should not depend on 2) > > > > Brian > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 16:36:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00572 for ; Tue, 29 Aug 2000 16:36:07 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D06A@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:23:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0579 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 16:23:03 -0400 Received: from qhars002.nortel.com (47.101.112.102:38620) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D069@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:23:02 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Tue, 29 Aug 2000 21:35:19 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Tue, 29 Aug 2000 15:36:58 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 29 Aug 2000 15:35:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C011F8.9702D240" Message-ID: <8E2783FA4E0CD411888D0000F8CD15D33C391A@zcard00q.ca.nortel.com> Date: Tue, 29 Aug 2000 15:34:54 -0500 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: Case Sensitivity X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01C011F8.9702D240 Content-Type: text/plain; charset="iso-8859-1" Brian, all: Your description below is as I remember it being decided. To me this does not constitute change, just an editorial mishap. At what stage did the text go missing (just a curio)? -- Peter -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] Sent: Tuesday, August 29, 2000 11:56 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Case Sensitivity To be really careful: SDP is defined case sensitive, and we aren't changing that quoted strings are case sensitive So, what we are really saying is that symbols are case insensitive Symbols include protocol tokens, terminationIds, package names, events and signals names, property names, statistics names and enumerated values. Brian > -----Original Message----- > From: Rosen, Brian > Sent: Tuesday, August 29, 2000 11:29 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Case Sensitivity > > > There is confusion on whether text encoding is case sensitive or not. > Several of us remember language about this, but there is none now. > > I believe, and the sentiment of the room (interop test room), > is that everything, language tokens, terminationIds, package > names/events/signals/parameters... is NOT case sensitive. > > Any objections? > > Brian > ------_=_NextPart_001_01C011F8.9702D240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Case Sensitivity

Brian, all:

Your description below is as I remember it being = decided.  To me this does not constitute change, just an editorial = mishap.  At what stage did the text go missing (just a = curio)? 

-- Peter 

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
Sent: Tuesday, August 29, 2000 11:56
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Case Sensitivity


To be really careful:
        SDP is = defined case sensitive, and we aren't changing that
        quoted = strings are case sensitive
So, what we are really saying is that symbols are = case insensitive
Symbols include protocol tokens, terminationIds, = package names,
events and signals names, property names, statistics = names
and enumerated values.

Brian

> -----Original Message-----
> From: Rosen, Brian
> Sent: Tuesday, August 29, 2000 11:29 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Case Sensitivity
>
>
> There is confusion on whether text encoding is = case sensitive or not.
> Several of us remember language about this, but = there is none now.
>
> I believe, and the sentiment of the room = (interop test room),
> is that everything, language tokens, = terminationIds, package
> names/events/signals/parameters... is NOT case = sensitive.
>
> Any objections?
>
> Brian
>

------_=_NextPart_001_01C011F8.9702D240-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 16:38:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00627 for ; Tue, 29 Aug 2000 16:38:30 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D087@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:25:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0616 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 16:25:05 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D086@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:25:04 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA21791; Tue, 29 Aug 2000 16:37:42 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA12160; Tue, 29 Aug 2000 16:37:41 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 16:37:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787AA@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 16:37:40 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Is ServiceChangeMgcId Optional on Cold Start? X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM The actual confusing wording is: Upon a cold start of the MG, it will issue a ServiceChange command with a "Restart" method, on the Root Termination to its primary MGC. If the MGC accepts the MG, it will send a Transaction Accept, with the ServiceChangeMgcId set to itself. If the MG receives an ServiceChangeMgcId not equal to the MGC it contacted, it sends a ServiceChange to the MGC specified in the ServiceChangeMgcId. This says that you must send it. The ABNF makes it optional ServiceChange Descriptor text says: The optional ServiceChangeAddress parameter specifies the address (e.g., IP port number for IP networks) to be used for subsequent communications. It can be specified in the input parameter descriptor or the returned result descriptor. 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. So it doesn't say whether it's optional or not, but doesn't give any other use other than when the MGC asks the MG to change. Brian > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > Sent: Tuesday, August 29, 2000 4:03 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Is ServiceChangeMgcId Optional on Cold Start? > > > Please look at the words you quote again. To me the two > passages both say > the same thing, although the second one does it in roundabout fashion > through the use of negatives. The interpretation is exactly > as you say: > ServiceChangeMgcId is omitted when the MGC is willing to accept the > association. > > > -----Original Message----- > > From: chennu [mailto:chennu@CHIPLOGIC.COM] > > Sent: Tuesday, August 29, 2000 9:23 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Is ServiceChangeMgcId Optional on Cold Start? > > > > > > Hi Brian, > > > > The text explaining ServiceChangeMgcId is contradictory. I am > > giving the > > text in 7.2.8 of Megaco-merged-01 document > > "ServiceChangeMgcId provides an alternative address where the > > MG should > > seek to establish another association." > > I am giving some more lines under the same section > > "The return from ServiceChange is empty except when the Root > > terminationID is used. In that case it includes the following > > parameters as required: > > * ServiceChangeMgcId, if the responding MGC does not wish > > to sustain > > an association with the MG " > > I think this text makes more meaning and the > ServiceChangeMgcId should > > be omitted when MGC accepts the ServiceChange command from MG. > > > > Thanks, > > Chennu. > > > > > > "Rosen, Brian" wrote: > > > > > This is the first in what I expect will be a series of > > > issues that we discover at the Interop. Yes, testing has not > > > begun yet, but we already have one. The question is, what does > > > the MGC send in a ServiceChange reply? > > > > > > The text currently states: > > > Upon a cold start of the MG, it will issue a > > > ServiceChange command with a "Restart" method, on the Root > > > Termination to its primary MGC. If the MGC accepts the MG, > > > it will send a Transaction Accept, with the ServiceChangeMgcId > > > set to itself. > > > > > > Note that this implies ServiceChangeMgcId is not optional. > > > I think this is incorrect and the text should state: > > > "...with the ServiceChangeMgcId omitted or set to itself." > > > > > > Following the usual IETF dictum about "be strict in what you > > > send, liberal in what you accept", MGCs SHOULD set > > > ServiceChangeMgcId, MGs should NOT depend on it. > > > > > > Brian > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 16:46:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00737 for ; Tue, 29 Aug 2000 16:46:44 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D0B0@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:33:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0669 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 16:33:37 -0400 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D0AF@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:33:36 -0400 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA08766; Tue, 29 Aug 2000 13:46:34 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA25643; Tue, 29 Aug 2000 13:46:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <4FBEA8857476D311A03300204840E1CF6787A7@whq-msgusr-02.fore.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Message-ID: <14764.8472.40780.40867@thomasm-u1.cisco.com> Date: Tue, 29 Aug 2000 13:46:16 -0700 Reply-To: Michael Thomas Sender: "Media Gateway Control (megaco)" From: Michael Thomas Subject: Error in text on interim AH header X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4FBEA8857476D311A03300204840E1CF6787A7@whq-msgusr-02.fore.com> Content-Transfer-Encoding: 7bit Er, this isn't very ipv6 friendly. Mike Rosen, Brian writes: > There is an error in the text in section 10.2 Interim AH scheme > in the sentence: > ...........To retain the same functionality, the ICV calculation > should be performed across the entire transaction prepended by a > synthesized IP header consisting of a 32 bit source IP address, a 32 > bit destination address and a 16 bit UDP destination port encoded as > 10 hex digits. > > The error is "10 hex digits". It should be 20 hex digits, > representing 10 bytes (4 source, 4 dest, 2 port). > > Brian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 16:49:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00774 for ; Tue, 29 Aug 2000 16:49:11 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D0CB@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:35:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0703 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 16:35:59 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D0CA@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:35:58 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA22784 for ; Tue, 29 Aug 2000 16:48:35 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 QAA15454 for ; Tue, 29 Aug 2000 16:48:36 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 16:48:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787AB@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 16:48:33 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: More issues on media of physical terminations To: MEGACO@STANDARDS.NORTELNETWORKS.COM I turn your attention to the example, and step 3 Specifically, look at the lines: Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 a=fmtp:PCMU VAD=X-NNVAD ; special voice activity ; detection algorithm This is too weird to let go 1) There is no IP address. Choose is really wrong, especially because the response doesn't return an address 2) the m line is bogus, it's not RTP I'll give some more info related to this; when we pushed through the atm sdp spec, it used RTP/AVP to pick up the codec spec, as this does. The MMUSIC group objected (it isn't RTP), so we had to define a new name space for ATM that simply defines the codec parameter the same as RTP/AVP 3) the a line has some sense, but it really would make more sense to have this be a parameter defined in the al package. Clearly, if you send SDP, you need a c and an m line, but using IP is just wrong. We can either make them parameters, and then SDP wouldn't be used in most cases, or we can extend SDP to have a more sane c and m line. At the very least, the c line should specify a legal IP address, and not choose. Brian Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 16:50:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00796 for ; Tue, 29 Aug 2000 16:50:42 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D0E8@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:37:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0740 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 16:37:26 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D0E7@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:37:25 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA22925; Tue, 29 Aug 2000 16:49:58 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 QAA15736; Tue, 29 Aug 2000 16:49:58 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 16:49:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787AC@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 16:49:57 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Error in text on interim AH header X-To: Michael Thomas To: MEGACO@STANDARDS.NORTELNETWORKS.COM It got through the IESG. This is because IPSEC is mandatory for IPv6. Brian > -----Original Message----- > From: Michael Thomas [mailto:mat@CISCO.COM] > Sent: Tuesday, August 29, 2000 4:46 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Error in text on interim AH header > > > Er, this isn't very ipv6 friendly. > > Mike > > Rosen, Brian writes: > > There is an error in the text in section 10.2 Interim AH scheme > > in the sentence: > > ...........To retain the same functionality, the ICV calculation > > should be performed across the entire transaction prepended by a > > synthesized IP header consisting of a 32 bit source IP > address, a 32 > > bit destination address and a 16 bit UDP destination > port encoded as > > 10 hex digits. > > > > The error is "10 hex digits". It should be 20 hex digits, > > representing 10 bytes (4 source, 4 dest, 2 port). > > > > Brian > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 17:03:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00939 for ; Tue, 29 Aug 2000 17:03:01 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D127@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:49:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0820 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 16:49:56 -0400 Received: from qhars002.nortel.com (47.101.112.102:39760) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D126@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:49:56 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Tue, 29 Aug 2000 22:00:51 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Tue, 29 Aug 2000 16:57:31 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 29 Aug 2000 16:57:28 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480CAE@zcard00g.ca.nortel.com> Date: Tue, 29 Aug 2000 16:57:18 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Is Media required on the Physical Termination/Default value f or M ODE X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Sorry, Brian, the natural default is "inactive". It does seem that we failed to specify the defaults in 7.1.7, even though section 6.2.4 promises that we would. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Sent: Tuesday, August 29, 2000 4:30 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Is Media required on the Physical > Termination/Default value > f or M ODE > > > Okay, so what would you expect to happen if you audited media of > the physical termination. Even if there was no default, it should > be one of the legal states. > > Now, suppose it's in an acceptable state, should you have to send > a media descriptor? > > What the folks who implemented the MG requiring the media descriptor > say is that "there is no mode, you haven't set it". I can't deal > with that, because audit has to return a value. So it has to be > something, and the MGC should be able to leave it, right? > > Now, I said I think MGCs should always send media! > > Brian > > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Tuesday, August 29, 2000 4:25 PM > > To: Rosen, Brian > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Is Media required on the Physical > > Termination/Default value for > > M ODE > > > > > > > > My general take has been that the MGC shouldn't > > assume much about the MG. If it wants the MG to > > do something, it should tell it. If it doesn't > > know the MG's state, it should audit it. > > Therefore, I think I disagree with the spec > > requiring some set of semantics for underspecified > > commands. What's the gain? > > > > Mike > > > > Rosen, Brian writes: > > > Another issue from the event: > > > > > > Is it REQUIRED that the MGC send a media descriptor to a PHYSICAL > > > termination in order to get media to flow? > > > > > > There are two questions actually: > > > 1) Is there a default state of MODE (text is silent) > > > 2) Should the MG demand a media descriptor before allowing > > media flow? > > > > > > I believe: > > > 1) The default for MODE is SendRecieve > > > 2) MGCs should always send a media descriptor, with at > least a MODE > > > setting > > > 3) MGs should not depend on 2) > > > > > > Brian > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 17:05:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00979 for ; Tue, 29 Aug 2000 17:05:01 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D13C@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:50:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0846 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 16:50:33 -0400 Received: from qhars002.nortel.com (47.101.112.102:39921) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D13B@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:50:33 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Tue, 29 Aug 2000 22:03:01 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Tue, 29 Aug 2000 15:57:10 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 29 Aug 2000 16:00:48 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 29 Aug 2000 16:53:52 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD11480CAF@zcard00g.ca.nortel.com> Date: Tue, 29 Aug 2000 16:00:42 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Is Media required on the Physical Termination/Default value f or M ODE X-To: Michael Thomas To: MEGACO@STANDARDS.NORTELNETWORKS.COM I tend to agree with Mike. Moreover, painful as it may be in the case of digital circuit terminations to see all that duplication of information in both Local and Remote, we should be sticking codec specifications into those descriptors when TDM is involved. I've just been looking at temptation in this regard while designing packages for NAS operation. One of the required packages conveys signalled bearer capability to the TDM circuit termination. I think that has to go into Local and Remote, which means I need a TDM update for SDP. I can use the ATMSDP document as a starting point, but TDM should be a lot simpler. > -----Original Message----- > From: Michael Thomas [mailto:mat@CISCO.COM] > Sent: Tuesday, August 29, 2000 4:25 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Is Media required on the Physical > Termination/Default value for > M ODE > > > My general take has been that the MGC shouldn't > assume much about the MG. If it wants the MG to > do something, it should tell it. If it doesn't > know the MG's state, it should audit it. > Therefore, I think I disagree with the spec > requiring some set of semantics for underspecified > commands. What's the gain? > > Mike > > Rosen, Brian writes: > > Another issue from the event: > > > > Is it REQUIRED that the MGC send a media descriptor to a PHYSICAL > > termination in order to get media to flow? > > > > There are two questions actually: > > 1) Is there a default state of MODE (text is silent) > > 2) Should the MG demand a media descriptor before allowing > media flow? > > > > I believe: > > 1) The default for MODE is SendRecieve > > 2) MGCs should always send a media descriptor, with at least a MODE > > setting > > 3) MGs should not depend on 2) > > > > Brian > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 17:07:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01008 for ; Tue, 29 Aug 2000 17:07:57 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D166@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:54:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0901 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 16:54:44 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D165@standards.nortelnetworks.com>; Tue, 29 Aug 2000 16:54:44 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA24290; Tue, 29 Aug 2000 17:07:21 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 RAA19514; Tue, 29 Aug 2000 17:07:22 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 17:07:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C011FD.1FE94234" Message-ID: <4FBEA8857476D311A03300204840E1CF6787AF@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 17:07:21 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Is Media required on the Physical Termination/Default value f or M ODE X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01C011FD.1FE94234 Content-Type: text/plain; charset="iso-8859-1" That's an acceptable default, which almost forces the MGC to set it to something else in order to get media to flow. Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Tuesday, August 29, 2000 4:57 PM To: Rosen, Brian; megaco@standards.nortelnetworks.com Subject: RE: Is Media required on the Physical Termination/Default value f or M ODE Sorry, Brian, the natural default is "inactive". It does seem that we failed to specify the defaults in 7.1.7, even though section 6.2.4 promises that we would. > -----Original Message----- > From: Rosen, Brian [ mailto:Brian.Rosen@MARCONI.COM ] > Sent: Tuesday, August 29, 2000 4:30 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Is Media required on the Physical > Termination/Default value > f or M ODE > > > Okay, so what would you expect to happen if you audited media of > the physical termination. Even if there was no default, it should > be one of the legal states. > > Now, suppose it's in an acceptable state, should you have to send > a media descriptor? > > What the folks who implemented the MG requiring the media descriptor > say is that "there is no mode, you haven't set it". I can't deal > with that, because audit has to return a value. So it has to be > something, and the MGC should be able to leave it, right? > > Now, I said I think MGCs should always send media! > > Brian > > > > > -----Original Message----- > > From: Michael Thomas [ mailto:mat@cisco.com ] > > Sent: Tuesday, August 29, 2000 4:25 PM > > To: Rosen, Brian > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Is Media required on the Physical > > Termination/Default value for > > M ODE > > > > > > > > My general take has been that the MGC shouldn't > > assume much about the MG. If it wants the MG to > > do something, it should tell it. If it doesn't > > know the MG's state, it should audit it. > > Therefore, I think I disagree with the spec > > requiring some set of semantics for underspecified > > commands. What's the gain? > > > > Mike > > > > Rosen, Brian writes: > > > Another issue from the event: > > > > > > Is it REQUIRED that the MGC send a media descriptor to a PHYSICAL > > > termination in order to get media to flow? > > > > > > There are two questions actually: > > > 1) Is there a default state of MODE (text is silent) > > > 2) Should the MG demand a media descriptor before allowing > > media flow? > > > > > > I believe: > > > 1) The default for MODE is SendRecieve > > > 2) MGCs should always send a media descriptor, with at > least a MODE > > > setting > > > 3) MGs should not depend on 2) > > > > > > Brian > > > > > > ------_=_NextPart_001_01C011FD.1FE94234 Content-Type: text/html; charset="iso-8859-1" RE: Is Media required on the Physical Termination/Default value f or M ODE
That's an acceptable default, which almost forces the MGC to set it to something
else in order to get media to flow.
 
Brian
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, August 29, 2000 4:57 PM
To: Rosen, Brian; megaco@standards.nortelnetworks.com
Subject: RE: Is Media required on the Physical Termination/Default value f or M ODE

Sorry, Brian, the natural default is "inactive".  It does seem that we failed to specify the defaults in 7.1.7, even though section 6.2.4 promises that we would.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Tuesday, August 29, 2000 4:30 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Is Media required on the Physical
> Termination/Default value
> f or M ODE
>
>
> Okay, so what would you expect to happen if you audited media of
> the physical termination.  Even if there was no default, it should
> be one of the legal states.
>
> Now, suppose it's in an acceptable state, should you have to send
> a media descriptor?
>
> What the folks who implemented the MG requiring the media descriptor
> say is that "there is no mode, you haven't set it".  I can't deal
> with that, because audit has to return a value.  So it has to be
> something, and the MGC should be able to leave it, right?
>
> Now, I said I think MGCs should always send media!
>
> Brian
>
>
>
> > -----Original Message-----
> > From: Michael Thomas [mailto:mat@cisco.com]
> > Sent: Tuesday, August 29, 2000 4:25 PM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Is Media required on the Physical
> > Termination/Default value for
> > M ODE
> >
> >
> >
> > My general take has been that the MGC shouldn't
> > assume much about the MG. If it wants the MG to
> > do something, it should tell it. If it doesn't
> > know the MG's state, it should audit it.
> > Therefore, I think I disagree with the spec
> > requiring some set of semantics for underspecified
> > commands. What's the gain?
> >
> >               Mike
> >
> > Rosen, Brian writes:
> >  > Another issue from the event:
> >  >
> >  > Is it REQUIRED that the MGC send a media descriptor to a PHYSICAL
> >  > termination in order to get media to flow?
> >  >
> >  > There are two questions actually:
> >  > 1) Is there a default state of MODE (text is silent)
> >  > 2) Should the MG demand a media descriptor before allowing
> > media flow?
> >  >
> >  > I believe:
> >  > 1) The default for MODE is SendRecieve
> >  > 2) MGCs should always send a media descriptor, with at
> least a MODE
> >  > setting
> >  > 3) MGs should not depend on 2)
> >  >
> >  > Brian
> >  >
> >
>

------_=_NextPart_001_01C011FD.1FE94234-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 17:55:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01604 for ; Tue, 29 Aug 2000 17:55:57 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D1BF@standards.nortelnetworks.com>; Tue, 29 Aug 2000 17:42:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1013 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 17:42:54 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D1BE@standards.nortelnetworks.com>; Tue, 29 Aug 2000 17:42:53 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA27560 for ; Tue, 29 Aug 2000 17:55:31 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 RAA28160 for ; Tue, 29 Aug 2000 17:55:32 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 17:55:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787B1@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 17:55:32 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Repeated Modify To: MEGACO@STANDARDS.NORTELNETWORKS.COM If you repeat a modify, what happens? I'd think that other than subtract or add, it's a NOP. Add/Subtract is an error. The specific command set MODE to the same value it was. Might unnecessarily consume cycles, but should be legal right? Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 18:04:33 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01731 for ; Tue, 29 Aug 2000 18:04:33 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D1E2@standards.nortelnetworks.com>; Tue, 29 Aug 2000 17:51:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1056 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 17:51:32 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D1E1@standards.nortelnetworks.com>; Tue, 29 Aug 2000 17:51:31 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA27976 for ; Tue, 29 Aug 2000 18:04:09 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 SAA29291 for ; Tue, 29 Aug 2000 18:04:10 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 18:04:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787B2@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 18:04:09 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Supplying only a port on a ServiceChangeAddress To: MEGACO@STANDARDS.NORTELNETWORKS.COM Suppose all you want to specify in a ServiceChangeAddress is a port number that is, the IP address doesn't change, but the port does. The ABNF sez: serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE This is because it could be IP, ATM, FR, MPLS.... The example shows just a port number. Should that be legal? Should you have to specify the IP address as x.x.x.x:p? Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 18:12:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01836 for ; Tue, 29 Aug 2000 18:12:58 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D1FD@standards.nortelnetworks.com>; Tue, 29 Aug 2000 17:59:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1091 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 17:59:54 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D1FC@standards.nortelnetworks.com>; Tue, 29 Aug 2000 17:59:54 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA28637 for ; Tue, 29 Aug 2000 18:12:32 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 SAA00484 for ; Tue, 29 Aug 2000 18:12:33 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 18:12:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787B3@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 18:12:33 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Megaco Interop Event - First Day results To: MEGACO@STANDARDS.NORTELNETWORKS.COM We have finished the "official" part of the testing today, although many participants are continuing to do testing tonight. All first pairings of MG/MGC have successfully completed calls. Many of them have done all the level 3 scenarios, and many of those have included failover of the MGC! Media flows work on these tests in almost every case. I think that's fabulous. Our goals tomorrow are to get every MG at least 3-4 MGCs to pair with (there are 6 different implementations in all). Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 18:24:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01903 for ; Tue, 29 Aug 2000 18:24:20 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D21D@standards.nortelnetworks.com>; Tue, 29 Aug 2000 18:11:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1134 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 18:11:23 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D21C@standards.nortelnetworks.com>; Tue, 29 Aug 2000 18:11:22 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id PAA15625; Tue, 29 Aug 2000 15:24:01 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF6787B1@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39AC3905.DC486794@cisco.com> Date: Tue, 29 Aug 2000 18:28:21 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: Repeated Modify X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I'm not sure I understand this question. If you resend a command with the same transaction-id, etc. it's a duplicate that will (hopefully) not get executed again. If you send a command with another transaction-id than previously, it's a new command and it will be carried out as such. That may or may not lead to a change on the MG. "Rosen, Brian" wrote: > If you repeat a modify, what happens? > > I'd think that other than subtract or add, it's a NOP. > Add/Subtract is an error. > > The specific command set MODE to the same value it was. > Might unnecessarily consume cycles, but should be legal > right? Sure, however it's a new command with a NOP result. -- Flemming > > > Brian -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 18:29:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01941 for ; Tue, 29 Aug 2000 18:29:49 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D235@standards.nortelnetworks.com>; Tue, 29 Aug 2000 18:16:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1133 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 18:16:45 -0400 Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D21B@standards.nortelnetworks.com>; Tue, 29 Aug 2000 18:06:45 -0400 Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id RAA29840 for ; Tue, 29 Aug 2000 17:16:18 -0500 (CDT) Received: from (relay2-alt.usa.alcatel.com [143.209.167.22]) by fw7 via smap (V2.1) id xma029702; Tue, 29 Aug 00 17:15:54 -0500 Received: from lcmail01.usa.alcatel.com (localhost [127.0.0.1]) by relay2.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id RAA15838 for ; Tue, 29 Aug 2000 17:19:48 -0500 (CDT) Received: from usa.alcatel.com (acta5u.dt.usa.alcatel.com [143.209.254.56]) by lcmail01.usa.alcatel.com (Netscape Messaging Server 4.15 lcmail01 Aug 8 2000 13:22:32) with ESMTP id G02RCZ00.9I4 for ; Tue, 29 Aug 2000 17:19:47 -0500 X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39AC36AF.6312C45C@usa.alcatel.com> Date: Tue, 29 Aug 2000 17:18:23 -0500 Reply-To: Mario Monteiro Sender: "Media Gateway Control (megaco)" From: Mario Monteiro Subject: line-side answer supervision To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit For analog circuits, answer indication in some cases needs to be returned towards the originating side for billing purposes. Question: Once answer is detected at the terminating side, how is this answer event communicated to the originating side so that the originating AGW may apply line-side answer supervision? That is, what type of Megaco signal is sent by the Softswitch to the originating AGW? Thanks, From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 18:33:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02028 for ; Tue, 29 Aug 2000 18:33:40 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D24F@standards.nortelnetworks.com>; Tue, 29 Aug 2000 18:20:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1199 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 18:20:38 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D24E@standards.nortelnetworks.com>; Tue, 29 Aug 2000 18:20:37 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id PAA19532; Tue, 29 Aug 2000 15:33:09 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF6787B2@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39AC3B2A.4629DBAF@cisco.com> Date: Tue, 29 Aug 2000 18:37:30 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: Supplying only a port on a ServiceChangeAddress X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "Rosen, Brian" wrote: > Suppose all you want to specify in a ServiceChangeAddress is a port number > that is, the IP address doesn't change, but the port does. > > The ABNF sez: > serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE > > This is because it could be IP, ATM, FR, MPLS.... > > The example shows just a port number. Actually, I thought that's all that would be allowed in the case of IP. If not, how can it be within the "context of the association currently being negotiated", and how would it then relate to ServiceChangeMgcId ? -- Flemming > > > Should that be legal? Should you have to specify the IP address > as x.x.x.x:p? > > Brian -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 18:36:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02046 for ; Tue, 29 Aug 2000 18:36:03 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D266@standards.nortelnetworks.com>; Tue, 29 Aug 2000 18:23:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1229 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 18:23:00 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D265@standards.nortelnetworks.com>; Tue, 29 Aug 2000 18:22:59 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA29830; Tue, 29 Aug 2000 18:35:37 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 SAA03286; Tue, 29 Aug 2000 18:35:38 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 18:35:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787B4@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 18:35:37 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Repeated Modify X-To: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM This would be a new transactionId, but the same command. I conclude that we agree on what happens - you execute the command, which may not cause any state change on the MG. Brian > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@CISCO.COM] > Sent: Tuesday, August 29, 2000 6:28 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Repeated Modify > > > I'm not sure I understand this question. If you resend a command with > the same transaction-id, etc. it's a duplicate that will > (hopefully) not > get executed again. If you send a command with another transaction-id > than previously, it's a new command and it will be carried > out as such. > That may or may not lead to a change on the MG. > > > > "Rosen, Brian" wrote: > > > If you repeat a modify, what happens? > > > > I'd think that other than subtract or add, it's a NOP. > > Add/Subtract is an error. > > > > The specific command set MODE to the same value it was. > > Might unnecessarily consume cycles, but should be legal > > right? > > Sure, however it's a new command with a NOP result. > > -- Flemming > > > > > > > Brian > > -- > Flemming Andreasen > Cisco Systems > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 18:37:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02063 for ; Tue, 29 Aug 2000 18:37:56 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D281@standards.nortelnetworks.com>; Tue, 29 Aug 2000 18:24:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1264 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 18:24:54 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D280@standards.nortelnetworks.com>; Tue, 29 Aug 2000 18:24:53 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA29913; Tue, 29 Aug 2000 18:37:31 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 SAA03434; Tue, 29 Aug 2000 18:37:32 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 18:37:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787B5@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 18:37:32 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Supplying only a port on a ServiceChangeAddress X-To: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM I think the issue is that you can have the same MGC have multiple IP addresses. You accept the association, but change the address. Say, a pool of servers appearing to be one MGC. Brian > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Tuesday, August 29, 2000 6:38 PM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Supplying only a port on a ServiceChangeAddress > > > > > "Rosen, Brian" wrote: > > > Suppose all you want to specify in a ServiceChangeAddress > is a port number > > that is, the IP address doesn't change, but the port does. > > > > The ABNF sez: > > serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE > > > > This is because it could be IP, ATM, FR, MPLS.... > > > > The example shows just a port number. > > Actually, I thought that's all that would be allowed in the > case of IP. If > not, how can it be within the "context of the association > currently being > negotiated", and how would it then relate to ServiceChangeMgcId ? > > -- Flemming > > > > > > > Should that be legal? Should you have to specify the IP address > > as x.x.x.x:p? > > > > Brian > > -- > Flemming Andreasen > Cisco Systems > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 18:48:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02212 for ; Tue, 29 Aug 2000 18:48:35 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D2AE@standards.nortelnetworks.com>; Tue, 29 Aug 2000 18:35:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1324 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 18:35:33 -0400 Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D2AD@standards.nortelnetworks.com>; Tue, 29 Aug 2000 18:35:33 -0400 Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Tue, 29 Aug 2000 16:04:45 -0700 Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id PAA28209; Tue, 29 Aug 2000 15:47:56 -0700 (PDT) Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 15:40:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8BBD33A986C5D311804000902719FF5DAFF446@aega.trillium.com> Date: Tue, 29 Aug 2000 15:40:40 -0700 Reply-To: Naren Tulpule Sender: "Media Gateway Control (megaco)" From: Naren Tulpule Subject: Re: Supplying only a port on a ServiceChangeAddress X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi Brian, List, people had posed this question (what the format of ServiceChangeAddress should be) earlier on the list. The answer you gave was "The address has to make sense in the domain of the transport mechanism. I'm not too fond of overspecifying this kind of thing, because it requires changes when you allow additional transports." I agree with this, upto a point. (e.g. in the case you mention below, "port number only" should be allowed because it does make sense). In ABNF ServiceChangeAddress is specified as VALUE (= 1*(Safe character) / quotedString). This is useless unless you have enough contextual information to contact the new address. Flemming's response quotes the text ("in the context of the current association being negotiated") but that can mean several things. Why should the parser assume IP transport, for example, and interprete the number as a port number? Instead, can we make ServiceChangeAddress = MID and allow port number in MID (along with any new transports that may come up). Or it can be "MID or port number" if you don't want to extend MID. I think it's better to extend the ABNF for ServiceChangeAddress later as and when new transports are added; rather than make it so generalized right now that you can't even parse it without having additional information about the transport from somewhere outside the parser. -- Naren. Narendra C. Tulpule SMTS, Trillium Digital Systems Ph: +1-310-442-9222 Fax: +1-310-442-1162 12100 Wilshire Bl #1800 Los Angeles, CA 90025 -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] Sent: Tuesday, August 29, 2000 3:04 PM To: MEGACO@standards.nortelnetworks.com Subject: Supplying only a port on a ServiceChangeAddress Suppose all you want to specify in a ServiceChangeAddress is a port number that is, the IP address doesn't change, but the port does. The ABNF sez: serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE This is because it could be IP, ATM, FR, MPLS.... The example shows just a port number. Should that be legal? Should you have to specify the IP address as x.x.x.x:p? Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 18:52:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02277 for ; Tue, 29 Aug 2000 18:52:06 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D2D1@standards.nortelnetworks.com>; Tue, 29 Aug 2000 18:39:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1368 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 18:39:07 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D2D0@standards.nortelnetworks.com>; Tue, 29 Aug 2000 18:39:06 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA00579; Tue, 29 Aug 2000 18:51:44 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 SAA04828; Tue, 29 Aug 2000 18:51:45 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 18:51:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787B7@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 18:51:45 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Supplying only a port on a ServiceChangeAddress X-To: Naren Tulpule To: MEGACO@STANDARDS.NORTELNETWORKS.COM I have some sympathy with this sentiment. I'm not too happy with VALUE as an address, even if I understand it. Other opinions? Brian > -----Original Message----- > From: Naren Tulpule [mailto:naren@trillium.com] > Sent: Tuesday, August 29, 2000 6:41 PM > To: Rosen, Brian; MEGACO@standards.nortelnetworks.com > Subject: RE: Supplying only a port on a ServiceChangeAddress > > > Hi Brian, List, > people had posed this question (what the format of > ServiceChangeAddress > should be) earlier on the list. The answer you gave was > "The address has to make sense in the domain of the transport > mechanism. I'm > not too fond of overspecifying this kind of thing, because it requires > changes when you allow additional transports." > I agree with this, upto a point. (e.g. in the case you > mention below, "port > number only" should be allowed because it does make sense). > > In ABNF ServiceChangeAddress is specified as VALUE (= > 1*(Safe character) / > quotedString). This is useless unless you have enough > contextual information > to contact the new address. Flemming's response quotes the > text ("in the > context of the current association being negotiated") but > that can mean > several things. Why should the parser assume IP transport, > for example, and > interprete the number as a port number? > > Instead, can we make ServiceChangeAddress = MID and allow > port number in > MID (along with any new transports that may come up). Or it > can be "MID or > port number" if you don't want to extend MID. I think it's > better to extend > the ABNF for ServiceChangeAddress later as and when new > transports are > added; rather than make it so generalized right now that you > can't even > parse it without having additional information about the > transport from > somewhere outside the parser. > > -- Naren. > Narendra C. Tulpule SMTS, Trillium Digital Systems > Ph: +1-310-442-9222 Fax: +1-310-442-1162 > 12100 Wilshire Bl #1800 Los Angeles, CA 90025 > > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Sent: Tuesday, August 29, 2000 3:04 PM > To: MEGACO@standards.nortelnetworks.com > Subject: Supplying only a port on a ServiceChangeAddress > > > Suppose all you want to specify in a ServiceChangeAddress is > a port number > that is, the IP address doesn't change, but the port does. > > The ABNF sez: > serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE > > This is because it could be IP, ATM, FR, MPLS.... > > The example shows just a port number. > > Should that be legal? Should you have to specify the IP address > as x.x.x.x:p? > > Brian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 19:23:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02606 for ; Tue, 29 Aug 2000 19:23:35 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D30E@standards.nortelnetworks.com>; Tue, 29 Aug 2000 19:10:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1444 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 19:10:33 -0400 Received: from hotmail.com (f29.law7.hotmail.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D30D@standards.nortelnetworks.com>; Tue, 29 Aug 2000 19:10:33 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 29 Aug 2000 16:23:13 -0700 Received: from 63.95.216.52 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 29 Aug 2000 23:23:13 GMT X-Originating-IP: [63.95.216.52] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 29 Aug 2000 23:23:13.0153 (UTC) FILETIME=[1A029F10:01C01210] Message-ID: Date: Tue, 29 Aug 2000 16:23:13 PDT Reply-To: khouston@valiantnet.com Sender: "Media Gateway Control (megaco)" From: Kelly Houston Subject: Default UDP Ports for MGCP v1.0 and MEGACO To: MEGACO@STANDARDS.NORTELNETWORKS.COM All, In regards to sending out commands verbs, both MGCP v1.0 and the MEGACO Internet Draft specifically state that the sender of the command (MG or MGC) should use the default UDP port. 2944 for MEGACO (text-based) 2427 for MGCP MGC to MG 2727 for MGCP MG to MGC However, it seems as if the two protocols do not agree on how to send the responses when they are not explicitly defined. The MEGACO document (standard) states that: "Responses must be sent to the address and port from which the corresponding commands were sent." MGCP v1.0 (RFC2705) states that: "When no port is specified for the endpoint, the commands should be sent: * by the Call Agents, to the default MGCP port for gateways, 2427. * by the Gateways, to the default MGCP port for Call Agents, 2727." Does this mean that for all MGCP v1.0 compliant implementations the MG should respond to commands on port 2727 unless otherwise defined, or is this a typo which should read port 2427 which would make the definition consistent to what is being proposed in MEGAGO? If anyone can clarify this please let me know. Thanks. Kelly Houston Senior Staff Engineer Valiant Networks, Inc. ph: (408) 360-9242 _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 19:25:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02623 for ; Tue, 29 Aug 2000 19:25:15 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D32B@standards.nortelnetworks.com>; Tue, 29 Aug 2000 19:12:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1481 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 19:12:09 -0400 Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D32A@standards.nortelnetworks.com>; Tue, 29 Aug 2000 19:12:08 -0400 Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Tue, 29 Aug 2000 16:41:22 -0700 Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id QAA28923; Tue, 29 Aug 2000 16:24:32 -0700 (PDT) Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 16:17:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8BBD33A986C5D311804000902719FF5D9FB405@aega.trillium.com> Date: Tue, 29 Aug 2000 16:17:16 -0700 Reply-To: Bharat Kaul Sender: "Media Gateway Control (megaco)" From: Bharat Kaul Subject: Re: Supplying only a port on a ServiceChangeAddress X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Brian, I have a question here regarding multiple IP addresses. Does MEGACO follow same retransmission algorithm as RFC 2705 with max1 and max2 as thresholds and contacting DNS in between as required ? The Megaco document doesn't seem to say that except a casual mention in D.1.5 section. If the retransmission algorithm doesn't have max1 and max2 thresholds, are multiple IP addresses of any significance for communication between a MG and an MGC with no clear way defined for switching between IP Addresses ? On a similar note, are we required to maintain TTL for IP addresses and contact DNS in MEGACO too ? Thanks - Bharat -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] Sent: Tuesday, August 29, 2000 3:38 PM To: MEGACO@standards.nortelnetworks.com Subject: Re: Supplying only a port on a ServiceChangeAddress I think the issue is that you can have the same MGC have multiple IP addresses. You accept the association, but change the address. Say, a pool of servers appearing to be one MGC. Brian > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Tuesday, August 29, 2000 6:38 PM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Supplying only a port on a ServiceChangeAddress > > > > > "Rosen, Brian" wrote: > > > Suppose all you want to specify in a ServiceChangeAddress > is a port number > > that is, the IP address doesn't change, but the port does. > > > > The ABNF sez: > > serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE > > > > This is because it could be IP, ATM, FR, MPLS.... > > > > The example shows just a port number. > > Actually, I thought that's all that would be allowed in the > case of IP. If > not, how can it be within the "context of the association > currently being > negotiated", and how would it then relate to ServiceChangeMgcId ? > > -- Flemming > > > > > > > Should that be legal? Should you have to specify the IP address > > as x.x.x.x:p? > > > > Brian > > -- > Flemming Andreasen > Cisco Systems > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 19:29:48 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02639 for ; Tue, 29 Aug 2000 19:29:48 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D348@standards.nortelnetworks.com>; Tue, 29 Aug 2000 19:16:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1519 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 19:16:47 -0400 Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D347@standards.nortelnetworks.com>; Tue, 29 Aug 2000 19:16:47 -0400 Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Tue, 29 Aug 2000 16:45:57 -0700 Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id QAA29006; Tue, 29 Aug 2000 16:29:07 -0700 (PDT) Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 16:21:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8BBD33A986C5D311804000902719FF5D9FB406@aega.trillium.com> Date: Tue, 29 Aug 2000 16:21:52 -0700 Reply-To: Bharat Kaul Sender: "Media Gateway Control (megaco)" From: Bharat Kaul Subject: Re: Default UDP Ports for MGCP v1.0 and MEGACO X-To: "khouston@valiantnet.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Kelly, Both protocols say the same thing. The statement you pointed out from RFC2705 says "Commands should be sent to default port". Note that it is talking about commands. Responses to those commands must always be sent to the source transport address which is same as defined in MEGACO. MEGACO, however, has additional procedures defined for switching to different ports through protocol mechanisms for tranmission to commands to ports other than default. But responses in all cases must be sent to source transport address. - Bharat -----Original Message----- From: Kelly Houston [mailto:khouston10@HOTMAIL.COM] Sent: Tuesday, August 29, 2000 4:23 PM To: MEGACO@standards.nortelnetworks.com Subject: Default UDP Ports for MGCP v1.0 and MEGACO All, In regards to sending out commands verbs, both MGCP v1.0 and the MEGACO Internet Draft specifically state that the sender of the command (MG or MGC) should use the default UDP port. 2944 for MEGACO (text-based) 2427 for MGCP MGC to MG 2727 for MGCP MG to MGC However, it seems as if the two protocols do not agree on how to send the responses when they are not explicitly defined. The MEGACO document (standard) states that: "Responses must be sent to the address and port from which the corresponding commands were sent." MGCP v1.0 (RFC2705) states that: "When no port is specified for the endpoint, the commands should be sent: * by the Call Agents, to the default MGCP port for gateways, 2427. * by the Gateways, to the default MGCP port for Call Agents, 2727." Does this mean that for all MGCP v1.0 compliant implementations the MG should respond to commands on port 2727 unless otherwise defined, or is this a typo which should read port 2427 which would make the definition consistent to what is being proposed in MEGAGO? If anyone can clarify this please let me know. Thanks. Kelly Houston Senior Staff Engineer Valiant Networks, Inc. ph: (408) 360-9242 _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 19:32:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02714 for ; Tue, 29 Aug 2000 19:32:47 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D379@standards.nortelnetworks.com>; Tue, 29 Aug 2000 19:19:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1584 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 19:19:48 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D378@standards.nortelnetworks.com>; Tue, 29 Aug 2000 19:19:48 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id QAA13799; Tue, 29 Aug 2000 16:32:26 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF6787B5@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39AC490E.7C85FEB3@cisco.com> Date: Tue, 29 Aug 2000 19:36:46 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: Supplying only a port on a ServiceChangeAddress X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "Rosen, Brian" wrote: > I think the issue is that you can have the same MGC have multiple > IP addresses. You accept the association, but change the address. > Say, a pool of servers appearing to be one MGC. I'm not sure I fully understand what an association is then. What's the difference/relationship between the association address and the ServiceChangeMgcId (which may itself contain an address or indirectly refer to a number of addresses through DNS) ? -- Flemming > > > Brian > > > -----Original Message----- > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > Sent: Tuesday, August 29, 2000 6:38 PM > > To: Rosen, Brian > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Supplying only a port on a ServiceChangeAddress > > > > > > > > > > "Rosen, Brian" wrote: > > > > > Suppose all you want to specify in a ServiceChangeAddress > > is a port number > > > that is, the IP address doesn't change, but the port does. > > > > > > The ABNF sez: > > > serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE > > > > > > This is because it could be IP, ATM, FR, MPLS.... > > > > > > The example shows just a port number. > > > > Actually, I thought that's all that would be allowed in the > > case of IP. If > > not, how can it be within the "context of the association > > currently being > > negotiated", and how would it then relate to ServiceChangeMgcId ? > > > > -- Flemming > > > > > > > > > > > Should that be legal? Should you have to specify the IP address > > > as x.x.x.x:p? > > > > > > Brian > > > > -- > > Flemming Andreasen > > Cisco Systems > > > > -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 19:38:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02752 for ; Tue, 29 Aug 2000 19:38:49 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D392@standards.nortelnetworks.com>; Tue, 29 Aug 2000 19:25:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1616 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 19:25:46 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D391@standards.nortelnetworks.com>; Tue, 29 Aug 2000 19:25:45 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id QAA16399; Tue, 29 Aug 2000 16:38:23 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF6787B7@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39AC4A74.D405A080@cisco.com> Date: Tue, 29 Aug 2000 19:42:44 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: Supplying only a port on a ServiceChangeAddress X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "Rosen, Brian" wrote: > I have some sympathy with this sentiment. > I'm not too happy with VALUE as an address, even if I > understand it. > > Other opinions? I agree. As part of that change, may I suggest we get rid of any duality between ServiceChangeAddress and ServiceChangeMgcId as well. -- Flemming > > > Brian > > > -----Original Message----- > > From: Naren Tulpule [mailto:naren@trillium.com] > > Sent: Tuesday, August 29, 2000 6:41 PM > > To: Rosen, Brian; MEGACO@standards.nortelnetworks.com > > Subject: RE: Supplying only a port on a ServiceChangeAddress > > > > > > Hi Brian, List, > > people had posed this question (what the format of > > ServiceChangeAddress > > should be) earlier on the list. The answer you gave was > > "The address has to make sense in the domain of the transport > > mechanism. I'm > > not too fond of overspecifying this kind of thing, because it requires > > changes when you allow additional transports." > > I agree with this, upto a point. (e.g. in the case you > > mention below, "port > > number only" should be allowed because it does make sense). > > > > In ABNF ServiceChangeAddress is specified as VALUE (= > > 1*(Safe character) / > > quotedString). This is useless unless you have enough > > contextual information > > to contact the new address. Flemming's response quotes the > > text ("in the > > context of the current association being negotiated") but > > that can mean > > several things. Why should the parser assume IP transport, > > for example, and > > interprete the number as a port number? > > > > Instead, can we make ServiceChangeAddress = MID and allow > > port number in > > MID (along with any new transports that may come up). Or it > > can be "MID or > > port number" if you don't want to extend MID. I think it's > > better to extend > > the ABNF for ServiceChangeAddress later as and when new > > transports are > > added; rather than make it so generalized right now that you > > can't even > > parse it without having additional information about the > > transport from > > somewhere outside the parser. > > > > -- Naren. > > Narendra C. Tulpule SMTS, Trillium Digital Systems > > Ph: +1-310-442-9222 Fax: +1-310-442-1162 > > 12100 Wilshire Bl #1800 Los Angeles, CA 90025 > > > > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > Sent: Tuesday, August 29, 2000 3:04 PM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Supplying only a port on a ServiceChangeAddress > > > > > > Suppose all you want to specify in a ServiceChangeAddress is > > a port number > > that is, the IP address doesn't change, but the port does. > > > > The ABNF sez: > > serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE > > > > This is because it could be IP, ATM, FR, MPLS.... > > > > The example shows just a port number. > > > > Should that be legal? Should you have to specify the IP address > > as x.x.x.x:p? > > > > Brian > > -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 19:42:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02817 for ; Tue, 29 Aug 2000 19:42:13 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D3B8@standards.nortelnetworks.com>; Tue, 29 Aug 2000 19:29:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1664 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 19:29:10 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D3B7@standards.nortelnetworks.com>; Tue, 29 Aug 2000 19:29:10 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id QAA17661; Tue, 29 Aug 2000 16:41:48 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <8BBD33A986C5D311804000902719FF5D9FB406@aega.trillium.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39AC4B40.BC62CB61@cisco.com> Date: Tue, 29 Aug 2000 19:46:09 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: Default UDP Ports for MGCP v1.0 and MEGACO X-To: Bharat Kaul To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Bharat Kaul wrote: > Kelly, > > Both protocols say the same thing. The statement you pointed out from > RFC2705 says "Commands should be sent to default port". Note that it is > talking about commands. > Responses to those commands must always be sent to the source transport > address which is same as defined in MEGACO. > > MEGACO, however, has additional procedures Different procedures rather. NotifiedEntity in MGCP serves this purpose. -- Flemming > defined for switching to > different ports through protocol mechanisms for tranmission to commands to > ports other than default. But responses in all cases must be sent to source > transport address. > > - Bharat > > -----Original Message----- > From: Kelly Houston [mailto:khouston10@HOTMAIL.COM] > Sent: Tuesday, August 29, 2000 4:23 PM > To: MEGACO@standards.nortelnetworks.com > Subject: Default UDP Ports for MGCP v1.0 and MEGACO > > All, > > In regards to sending out commands verbs, both MGCP v1.0 and the MEGACO > Internet Draft specifically state that the sender of the command (MG or MGC) > should use the default UDP port. > > 2944 for MEGACO (text-based) > 2427 for MGCP MGC to MG > 2727 for MGCP MG to MGC > > However, it seems as if the two protocols do not agree on how to send the > responses when they are not explicitly defined. > > The MEGACO document (standard) states that: > > "Responses must be sent to the address and port from which the corresponding > commands were sent." > > MGCP v1.0 (RFC2705) states that: > > "When no port is specified for the endpoint, the commands should be > sent: > > * by the Call Agents, to the default MGCP port for gateways, 2427. > > * by the Gateways, to the default MGCP port for Call Agents, 2727." > > Does this mean that for all MGCP v1.0 compliant implementations the MG > should respond to commands on port 2727 unless otherwise defined, or is this > a typo which should read port 2427 which would make the definition > consistent to what is being proposed in MEGAGO? > > If anyone can clarify this please let me know. > > Thanks. > > Kelly Houston > Senior Staff Engineer > Valiant Networks, Inc. > ph: (408) 360-9242 > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > Share information about yourself, create your own public profile at > http://profiles.msn.com. -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 19:44:48 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02867 for ; Tue, 29 Aug 2000 19:44:48 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D3D7@standards.nortelnetworks.com>; Tue, 29 Aug 2000 19:31:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1703 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 19:31:42 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D3D6@standards.nortelnetworks.com>; Tue, 29 Aug 2000 19:31:42 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA02885; Tue, 29 Aug 2000 19:44:19 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 TAA10568; Tue, 29 Aug 2000 19:44:20 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 19:44:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787B9@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 19:44:21 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Supplying only a port on a ServiceChangeAddress X-To: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM I thought you might say that, I've been thinking about it since I sent the message. Posing the question slightly differently, if the ServiceChangeAddress can do what ServiceChangeMid can do, so why have two mechanisms? The only difference would be the MGs actions. If you used ServiceChangeAddress, the MG would not send a new ServiceChange command to the new address. If you used ServiceChangeMid, it would. The end result would be the same. We can: Explicitly disallow ServiceChangeAddress from being used to change anything but IP Port when used with IP Get rid of one of the two of them I favor the former, as that is easiest, is most consistent with history, and makes the most sense to me. I'll note that what we call ServiceChangeAddress used to be "port". It got changed when we realized "port" wouldn't make sense if it was not an IP transport. Brian > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Tuesday, August 29, 2000 7:37 PM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Supplying only a port on a ServiceChangeAddress > > > > > "Rosen, Brian" wrote: > > > I think the issue is that you can have the same MGC have multiple > > IP addresses. You accept the association, but change the address. > > Say, a pool of servers appearing to be one MGC. > > I'm not sure I fully understand what an association is then. > What's the > difference/relationship between the association address and the > ServiceChangeMgcId (which may itself contain an address or indirectly > refer to a number of addresses through DNS) ? > > -- Flemming > > > > > > > > Brian > > > > > -----Original Message----- > > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > > Sent: Tuesday, August 29, 2000 6:38 PM > > > To: Rosen, Brian > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Supplying only a port on a ServiceChangeAddress > > > > > > > > > > > > > > > "Rosen, Brian" wrote: > > > > > > > Suppose all you want to specify in a ServiceChangeAddress > > > is a port number > > > > that is, the IP address doesn't change, but the port does. > > > > > > > > The ABNF sez: > > > > serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE > > > > > > > > This is because it could be IP, ATM, FR, MPLS.... > > > > > > > > The example shows just a port number. > > > > > > Actually, I thought that's all that would be allowed in the > > > case of IP. If > > > not, how can it be within the "context of the association > > > currently being > > > negotiated", and how would it then relate to ServiceChangeMgcId ? > > > > > > -- Flemming > > > > > > > > > > > > > > > Should that be legal? Should you have to specify the IP address > > > > as x.x.x.x:p? > > > > > > > > Brian > > > > > > -- > > > Flemming Andreasen > > > Cisco Systems > > > > > > > > -- > Flemming Andreasen > Cisco Systems > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 19:46:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02917 for ; Tue, 29 Aug 2000 19:46:28 -0400 (EDT) Received: from standards (47.234.32.16:2576) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D3F6@standards.nortelnetworks.com>; Tue, 29 Aug 2000 19:33:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1742 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 19:33:24 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D3F5@standards.nortelnetworks.com>; Tue, 29 Aug 2000 19:33:23 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA02970 for ; Tue, 29 Aug 2000 19:46:01 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 TAA10715 for ; Tue, 29 Aug 2000 19:46:02 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 19:46:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787BA@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 19:46:02 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Media without Stream To: MEGACO@STANDARDS.NORTELNETWORKS.COM It may come as a surprise to some of you, as it did to me, that you can say: Media=termId{Local.... you don't have to say Media=termId{Stream=1{Local... ABNF clearly allows this. We have an MGC implementation that did this, and an MG that got confused. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 20:10:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03288 for ; Tue, 29 Aug 2000 20:10:57 -0400 (EDT) Received: from standards (47.234.32.16:3984) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D41B@standards.nortelnetworks.com>; Tue, 29 Aug 2000 19:57:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1789 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 19:57:58 -0400 Received: from qhars002.nortel.com (47.101.112.102:47475) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D41A@standards.nortelnetworks.com>; Tue, 29 Aug 2000 19:57:57 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Wed, 30 Aug 2000 01:10:37 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Tue, 29 Aug 2000 20:10:24 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 29 Aug 2000 20:10:20 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 29 Aug 2000 20:09:06 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480CB3@zcard00g.ca.nortel.com> Date: Tue, 29 Aug 2000 20:10:18 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Repeated Modify X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Seems reasonable to me. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Sent: Tuesday, August 29, 2000 5:56 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Repeated Modify > > > If you repeat a modify, what happens? > > I'd think that other than subtract or add, it's a NOP. > Add/Subtract is an error. > > The specific command set MODE to the same value it was. > Might unnecessarily consume cycles, but should be legal > right? > > Brian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 20:15:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03351 for ; Tue, 29 Aug 2000 20:15:50 -0400 (EDT) Received: from standards (47.234.32.16:3984) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D450@standards.nortelnetworks.com>; Tue, 29 Aug 2000 20:02:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1863 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 20:02:53 -0400 Received: from qhars002.nortel.com (47.101.112.102:47687) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D44F@standards.nortelnetworks.com>; Tue, 29 Aug 2000 20:02:52 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Wed, 30 Aug 2000 01:15:32 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Tue, 29 Aug 2000 19:17:04 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 29 Aug 2000 19:15:13 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 29 Aug 2000 20:12:41 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480CB5@zcard00g.ca.nortel.com> Date: Tue, 29 Aug 2000 19:15:11 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: line-side answer supervision X-To: Mario Monteiro To: MEGACO@STANDARDS.NORTELNETWORKS.COM Nothing is defined yet, though I remember this being brought up at one point. I think we have lots of package work ahead of us. > -----Original Message----- > From: Mario Monteiro [mailto:Mario.Monteiro@USA.ALCATEL.COM] > Sent: Tuesday, August 29, 2000 6:18 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: line-side answer supervision > > > For analog circuits, answer indication in some cases needs to be > returned towards the originating side for billing purposes. > > Question: Once answer is detected at the terminating side, how is this > answer event communicated to the originating side so that the > originating AGW may apply line-side answer supervision? That is, what > type of Megaco signal is sent by the Softswitch to the > originating AGW? > > Thanks, > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 20:18:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03390 for ; Tue, 29 Aug 2000 20:18:02 -0400 (EDT) Received: from standards (47.234.32.16:3984) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D46E@standards.nortelnetworks.com>; Tue, 29 Aug 2000 20:04:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1901 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 20:04:58 -0400 Received: from world.std.com (world-f.std.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D46D@standards.nortelnetworks.com>; Tue, 29 Aug 2000 20:04:58 -0400 Received: (from mpd@localhost) by world.std.com (8.9.3/8.9.3) id UAA19141; Tue, 29 Aug 2000 20:14:33 -0400 (EDT) Message-ID: <200008300014.UAA19141@world.std.com> Date: Tue, 29 Aug 2000 20:14:33 -0400 Reply-To: Michael P DiGioia Sender: "Media Gateway Control (megaco)" From: Michael P DiGioia Subject: Re: Repeated Modify X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Brian, >>If you repeat a modify, what happens? This is implementation specific! I.e., Should not be specified as one or the other. In addition, if the MG is designed to execute all commands, someone should first check and see if any one command can cause a problem (i.e., do something more than NOP as with ADD). How will any one MG know apriori that it should skip any one command? /mpd From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 20:24:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03430 for ; Tue, 29 Aug 2000 20:24:17 -0400 (EDT) Received: from standards (47.234.32.16:3984) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D49A@standards.nortelnetworks.com>; Tue, 29 Aug 2000 20:11:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1957 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 20:11:18 -0400 Received: from qhars002.nortel.com (47.101.112.102:47900) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D499@standards.nortelnetworks.com>; Tue, 29 Aug 2000 20:11:18 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Wed, 30 Aug 2000 01:23:15 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Tue, 29 Aug 2000 19:17:57 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 29 Aug 2000 19:21:35 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD11480CB6@zcard00g.ca.nortel.com> Date: Tue, 29 Aug 2000 19:21:32 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Media without Stream X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is the optimized syntax for single stream (e.g. voice-only) operation. It has been there ever since we invented streams, since one of the constraints on handling of multimedia was that it not discommode straightforward VoIP operation. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Sent: Tuesday, August 29, 2000 7:46 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Media without Stream > > > It may come as a surprise to some of you, as it did to me, that you > can say: > > Media=termId{Local.... > > you don't have to say > Media=termId{Stream=1{Local... > > ABNF clearly allows this. We have an MGC implementation that > did this, > and an MG that got confused. > > Brian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 20:32:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03539 for ; Tue, 29 Aug 2000 20:32:07 -0400 (EDT) Received: from standards (47.234.32.16:3984) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D4C3@standards.nortelnetworks.com>; Tue, 29 Aug 2000 20:18:51 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2012 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 20:18:51 -0400 Received: from world.std.com (world-f.std.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D4C2@standards.nortelnetworks.com>; Tue, 29 Aug 2000 20:18:51 -0400 Received: (from mpd@localhost) by world.std.com (8.9.3/8.9.3) id UAA29820; Tue, 29 Aug 2000 20:29:22 -0400 (EDT) Message-ID: <200008300029.UAA29820@world.std.com> Date: Tue, 29 Aug 2000 20:29:22 -0400 Reply-To: Michael P DiGioia Sender: "Media Gateway Control (megaco)" From: Michael P DiGioia Subject: Re: Supplying only a port on a ServiceChangeAddress X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Brian, >>Suppose all you want to specify in a ServiceChangeAddress is a port numbe >>that is, the IP address doesn't change, but the port does. Any one port number alone is useless unless its associated with an address. However, I believe its valid syntax to allow only the "portNumber = UINT16" in the ServiceChangeAddress. /mpd From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 20:38:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03568 for ; Tue, 29 Aug 2000 20:38:39 -0400 (EDT) Received: from standards (47.234.32.16:3984) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D4EE@standards.nortelnetworks.com>; Tue, 29 Aug 2000 20:25:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2065 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 20:25:37 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D4ED@standards.nortelnetworks.com>; Tue, 29 Aug 2000 20:25:37 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA04734; Tue, 29 Aug 2000 20:38:14 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 UAA15642; Tue, 29 Aug 2000 20:38:16 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 20:38:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787BE@whq-msgusr-02.fore.com> Date: Tue, 29 Aug 2000 20:38:15 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Supplying only a port on a ServiceChangeAddress X-To: Michael P DiGioia To: MEGACO@STANDARDS.NORTELNETWORKS.COM Changing port only is the normal case. The MG contacts the MGC on the default port, the MGC replies with a ServiceChangeAddress with the port it wants this association to use. It will never be the default port, unless it can only support one MG! Normally, the address does not change. Brian > -----Original Message----- > From: Michael P DiGioia [mailto:mpd@world.std.com] > Sent: Tuesday, August 29, 2000 8:29 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM; Rosen, Brian > Subject: Re: Supplying only a port on a ServiceChangeAddress > > > Brian, > > >>Suppose all you want to specify in a ServiceChangeAddress > is a port numbe > >>that is, the IP address doesn't change, but the port does. > > Any one port number alone is useless unless its associated with an > address. However, I believe its valid syntax to allow only the > "portNumber = UINT16" in the ServiceChangeAddress. > > /mpd > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 23:17:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06848 for ; Tue, 29 Aug 2000 23:17:31 -0400 (EDT) Received: from standards (47.234.32.16:3771) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D60A@standards.nortelnetworks.com>; Tue, 29 Aug 2000 22:59:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2468 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 22:59:50 -0400 Received: from qhars002.nortel.com (47.101.112.102:53758) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D603@standards.nortelnetworks.com>; Tue, 29 Aug 2000 22:59:49 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Sun, 27 Aug 2000 05:32:19 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Sat, 26 Aug 2000 18:47:01 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Sat, 26 Aug 2000 18:45:27 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480C97@zcard00g.ca.nortel.com> Date: Sat, 26 Aug 2000 18:45:25 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Communication From Study Group 15, Question 4 X-cc: "Hansen, Chris" To: MEGACO@STANDARDS.NORTELNETWORKS.COM The following note comes from ITU-T Study Group 15, Question 4. Study Group 15 deals with physical transport standardization. I'll let Question 4's note speak for itself. In truth, this was addressed to the IETF in general rather than Megaco, so if someone can suggest more appropriate WGs to send it to please let me know. Tom Taylor We would like to make you aware the Q4/SG15 has initiated a Voice over DSL (VoDSL) project in order to support various VoDSL end to end services and thus evaluate new features and technologies that may be required in future G series xDSL PHY layer standards and welcome any requirements or input you may have relevant to this effort. At this time, it is not anticipated that this project will develop a new ITU-T Recommendation, but rather act in directing any VoDSL related requirements or features to the relevant PHY layer project. We are currently working on a draft VDSL Recommendation and the next generation (i.e. "bis" versions) of the ADSL and SHDSL G.series Recommendations. The project has identified and are considering the following enhanced features for future Recommendations: - Multi-bearers to enable data and voice (i.e. simultaneous ATM and STM) - ATM dual latency/dual TCs - Q mode - Signaling, management and control support - Seamless rate adaptation - Repartitioning - Line powering (provide voice during remote power failure) - QoS (error rate/latency ...) - Network Timing Reference (NTR) - synchronization - All digital loop (upstream capacity improvement) - Co-operation between PHY, transport and voice layers We welcome your input and any guidance you can provide to make the Q4/SG15 VoDSL project result in improved future G.series xDSL Recommendations. Currently approved G.series Recommendations can be found at www.itu.ch. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 23:17:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06852 for ; Tue, 29 Aug 2000 23:17:32 -0400 (EDT) Received: from standards (47.234.32.16:3771) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D60E@standards.nortelnetworks.com>; Tue, 29 Aug 2000 22:59:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2473 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 22:59:50 -0400 Received: from qhars002.nortel.com (47.101.112.102:53756) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D604@standards.nortelnetworks.com>; Tue, 29 Aug 2000 22:59:49 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Fri, 25 Aug 2000 18:07:30 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Fri, 25 Aug 2000 12:03:03 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 25 Aug 2000 12:01:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00EB6.0F925960" Message-ID: <8E2783FA4E0CD411888D0000F8CD15D33C38FB@zcard00q.ca.nortel.com> Date: Fri, 25 Aug 2000 12:01:07 -0500 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: I-D posted: Megaco IP Phone MG 03 X-cc: "Bob Bell (Cisco)" , "Phil Holland (Circa)" To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01C00EB6.0F925960 Content-Type: text/plain; charset="iso-8859-1" Greetings: An updated version of the Megaco IP Phone MG I-D has been submitted as "draft-ietf-megaco-ipphone-03.txt". Updates include: - Removed text regarding subset profile (as proposed and agreed IETF 47), - Added description of termination naming conventions (last remaining technical issue), - Clarified spec covers minimum functionality only, with optional binary encoding, TCP and other transports, extensions (as agreed IETF 47) - Marked as Informational (as agreed IETF 47), - Added sections on Conventions (per RFC 2119) and Security Considerations (null section), - Editorial fix-ups. Above is all as previously agreed. Technical issues and dependencies are now complete. We believe the document is ready for Last Call. Regards, Peter Blatherwick Bob Bell Phil Holland ------_=_NextPart_001_01C00EB6.0F925960 Content-Type: text/html; charset="iso-8859-1" I-D posted: Megaco IP Phone MG 03

Greetings:

An updated version of the Megaco IP Phone MG I-D has been
submitted as "draft-ietf-megaco-ipphone-03.txt". 

Updates include:
- Removed text regarding subset profile (as proposed and
  agreed IETF 47),
- Added description of termination naming conventions
  (last remaining technical issue),
- Clarified spec covers minimum functionality only, with
  optional binary encoding, TCP and other transports,
  extensions (as agreed IETF 47)
- Marked as Informational (as agreed IETF 47),
- Added sections on Conventions (per RFC 2119) and Security
  Considerations (null section),
- Editorial fix-ups.

Above is all as previously agreed.  Technical issues and
dependencies are now complete.  We believe the document is
ready for Last Call.   

Regards,
Peter Blatherwick
Bob Bell
Phil Holland

------_=_NextPart_001_01C00EB6.0F925960-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 23:17:33 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06862 for ; Tue, 29 Aug 2000 23:17:32 -0400 (EDT) Received: from standards (47.234.32.16:3771) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D614@standards.nortelnetworks.com>; Tue, 29 Aug 2000 22:59:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2478 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 22:59:51 -0400 Received: from qhars002.nortel.com (47.101.112.102:53756) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D609@standards.nortelnetworks.com>; Tue, 29 Aug 2000 22:59:50 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Mon, 28 Aug 2000 19:06:35 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Mon, 28 Aug 2000 14:06:23 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 28 Aug 2000 14:06:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0111A.A59EBF00" Message-ID: <8E2783FA4E0CD411888D0000F8CD15D33C390A@zcard00q.ca.nortel.com> Date: Mon, 28 Aug 2000 14:06:11 -0400 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: resend: I-D posted: Megaco IP Phone MG 03 To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01C0111A.A59EBF00 Content-Type: text/plain; charset="iso-8859-1" Resend. The below summary of updates in Megaco IP Phone 03 does not appear to have made it to the list. The I-D is now available on-line at: http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-03.txt -----Original Message----- From: Blatherwick, Peter [CAR:AT14:EXCH] Sent: Friday, August 25, 2000 13:01 To: 'Megaco' Cc: 'Bob Bell (Cisco)'; 'Phil Holland (Circa)' Subject: I-D posted: Megaco IP Phone MG 03 Greetings: An updated version of the Megaco IP Phone MG I-D has been submitted as "draft-ietf-megaco-ipphone-03.txt". Updates include: - Removed text regarding subset profile (as proposed and agreed IETF 47), - Added description of termination naming conventions (last remaining technical issue), - Clarified spec covers minimum functionality only, with optional binary encoding, TCP and other transports, extensions (as agreed IETF 47) - Marked as Informational (as agreed IETF 47), - Added sections on Conventions (per RFC 2119) and Security Considerations (null section), - Editorial fix-ups. Above is all as previously agreed. Technical issues and dependencies are now complete. We believe the document is ready for Last Call. Regards, Peter Blatherwick Bob Bell Phil Holland ------_=_NextPart_001_01C0111A.A59EBF00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable resend: I-D posted: Megaco IP Phone MG 03

Resend.  The below summary of updates in Megaco = IP Phone 03 does not appear to have made it to the list.  The I-D = is now available on-line at: http://www.ietf.org/internet-drafts/draft-ietf-megaco-= ipphone-03.txt


-----Original Message-----
From: Blatherwick, Peter [CAR:AT14:EXCH]
Sent: Friday, August 25, 2000 13:01
To: 'Megaco'
Cc: 'Bob Bell (Cisco)'; 'Phil Holland = (Circa)'
Subject: I-D posted: Megaco IP Phone MG 03


Greetings:

An updated version of the Megaco IP Phone MG I-D has = been
submitted as = "draft-ietf-megaco-ipphone-03.txt". 

Updates include:
- Removed text regarding subset profile (as proposed = and
  agreed IETF 47),
- Added description of termination naming = conventions
  (last remaining technical issue),
- Clarified spec covers minimum functionality only, = with
  optional binary encoding, TCP and other = transports,
  extensions (as agreed IETF 47)
- Marked as Informational (as agreed IETF 47), =
- Added sections on Conventions (per RFC 2119) and = Security
  Considerations (null section),
- Editorial fix-ups.

Above is all as previously agreed.  Technical = issues and
dependencies are now complete.  We believe the = document is
ready for Last Call.   

Regards,
Peter Blatherwick
Bob Bell
Phil Holland

------_=_NextPart_001_01C0111A.A59EBF00-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 23:17:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06871 for ; Tue, 29 Aug 2000 23:17:33 -0400 (EDT) Received: from standards (47.234.32.16:3771) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D618@standards.nortelnetworks.com>; Tue, 29 Aug 2000 22:59:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2483 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 22:59:53 -0400 Received: from qhars002.nortel.com (47.101.112.102:53756) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D612@standards.nortelnetworks.com>; Tue, 29 Aug 2000 22:59:51 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Fri, 25 Aug 2000 18:48:37 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Fri, 25 Aug 2000 13:47:49 -0400 Received: from zrtpd00x.us.nortel.com ([47.140.224.108]) by zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id RPW663Q7; Fri, 25 Aug 2000 13:47:43 -0400 Received: from americasm01.nt.com (brtphe34.us.nortel.com [47.202.35.89]) by zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id RJ6RW363; Fri, 25 Aug 2000 13:47:41 -0400 X-Mailer: Mozilla 4.72 [en] (X11; U; HP-UX B.10.20 9000/778) X-Accept-Language: en MIME-Version: 1.0 References: <39A5959A.34FA015B@ericsson.com> <39A677AE.6DB5635@cisco.com> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A6B45D.F0F66E82@americasm01.nt.com> Date: Fri, 25 Aug 2000 14:01:01 -0400 Reply-To: Kevin Boyle Sender: "Media Gateway Control (megaco)" From: Kevin Boyle Organization: Nortel Networks Subject: Re: Support of Values in Packages To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello,

A general question here:

What, exactly, is meant by "support" of a signal?  Does this mean that a gateway will absolutely know what the physical parameters of the signal are, and will play it?  Or does it mean something a little less than that, for instance, that the gateway will gracefully accept the signal in question, not necessarily doing anything about it?

Generally speaking, signals, and tones in particular, have very precise definitions as to when and how they should be used.  So, if there are no phones in need of a particular signal off of a gateway, in theory, that signal would never be requested by the MGC.  However, if it was, by the package definition, the MG would be required to support it.  Is it incorrect, then, for the MG to successfully acknowledge the signal application command, and then throw the signal away?  Maybe the signal could be datafilled to be/do nothing in the MG, in which case ignoring the signal would be a correct application of the signal to the line.

MGCs have a little different issue with the meaning of "support".  Just because a MGC supports the ability to generate a particular signal to a MG, does not necessarily mean that MGC will ever do so.  In this case, "support" becomes a pretty meaningless term.  If a signal is never going to be generated, then what does support really mean?  That the MGC can generate the signal through manual intervention?

The same argument about signal support in MGCs also applies to events as well.  If we will never ask for a particular event, what does support of that event mean?  For MGs, the same is not true.  A MG must be able to report a supported event when it is requested in the Events descriptor.  So support of events from a MG standpoint is fairly straightforward.  Since properties and statistics are acted upon in both directions, support is also a straightforward concept for these as well.

I, too, agree that there is an issue regarding values, as highlighted by the codec example.  In the same vein, there needs to be a better definition of what support means, especially in regards to signals and events.  I propose, as a starting point for discussion, that "support" of signals in the MG means that the MG will accept the signal, and acknowledge it without error, at the very minimum.  Any problem with MGs choosing to ignore important signals will be rectified by the MG's inability to produce quality telephone service without those signals.  "Support" in the MGC is a little tougher issue, since support of a signal or event is invisible until such time as the signal or event is requested.

Any comments/ideas/statements to correct my misconceptions? ;)

Regards,

Kevin Boyle
CS2K Line Services
Nortel Networks

Flemming Andreasen wrote:

Christian Groves wrote:

> G'Day all,
>
> There has been some confusion at the SG16 on what is supported in
> Packages.
>
> The understanding that I had was that: If you support a package you must
> support all the signals, properties, events and statistics.

Agreed.

> However you
> do not have to support all the values associated with the properties and
> parameters.

I guess the term "values" is somewhat prone to interpretation, but I would
tend to disagree if we refer to a list of well-defined values, as e.g. a
list of tone ids in E.7.

>
>
> Tom mentioned that a thread discussed on the list contravened this.
>
> The reasoning that I have for not having to support all the values is
> the following:
> o Proliferation of packages. Eg: if a package has a list of tones, and I
> must support all the values, if I only want to support a subset of these
> values then I need a new package. Therefore you may get the case of a
> package "Package Call Progress Tones E.7" where an MG doesn't support
> Payphone Recognition Tone because it doesn't have payphones connected to
> it.

However, in this parcticular example, the tones are both signals and tone
ids, so the effect would be the same. While I'm not particularly fond of the
tonegen package, it does nevertheless illustrate an important point, namely
that the distinction between signals, and parameters to signals (and similar
for other constructs) is somewhat arbitrary. The package really gives you
two things:
1. A name space
2. A convenient grouping of some set of "properties"

If we don't know exaclty what those "properties" are, then we've lost a very
important aspect of packages.

> To be compliant with H.248 I can't extend the package because I want
> to remove the payphone tone. So a new Package needs to be defined
> containing exactly the same information but without the payphone tone.
> Now my MG won't support the standard Call Progress Tone package but will
> support the XXX_companies_Call_Progress_Tone package. This would lead to
> a proliferation of packages.

I agree, but we have to ask ourselves what the idea about packages is.
Simplicity and flexibility are often at odds with each other and in this
case stress the importance of defining packages very carefully.

If I no longer know exactly what is supported in a package, how do I go
about using that package ?

>
>
> o Multiple GW support - One MG may not implement all the values of a
> property. For something like a list of codecs, a group of resources
> associated with the value may be placed in different MG GWs. ie. GSM
> codecs in MG1, PCM codecs in MG2. So whilst the MGs support the same
> package properties, they can't support a subset of values then you'd
> need to define a different package for each MG configuration. Again
> leading to a proliferation of packages.

Back to defining what "values" mean. Obviously, if we define a "codec"
property in a package, we can't expect support for every possible codec in
the world.

Maybe there's a distinction between supporting values for events, signals,
statistics, and properties ?

>
>
> o The MGC knows the PackageID, that all Properties, Signals, Events,
> Statistics are supported. In H.248 we have the AuditCapability and
> AuditValue commands to find out what actual values of properties are
> supported.

Not sure how you would do that with event and signal parameters though (come
to think of it, I'm not sure how you, in practice, do that for a lot of
parameters; "The appropriate descriptors, *with the possible values for the
Termination* are returned from AuditCapabilities", Section 7.2.6). On the
other, we could have a new property that looked similar, so it's not clear
it wouldn't apply there either.

>
>
> So if people agree that not all values in a package need to be supported
> I propose to add some text to the implementor's guide:
> Section 12.1 after 2nd Paragraph
> "A MG SHALL support all Property, Signals & parameters, Events &
> parameters and Statistics. A MG MAY support a subset of property and
> parameter values defined in the package unless specified in a package."

I don't want to deflate the package concept to the extent this would seem to
allow, but I agree there's an issue here. Further discussion is needed
before we make any change.

-- Flemming

>
>
> Cheers, Christian

--
Flemming Andreasen
Cisco Systems

From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 23:17:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06882 for ; Tue, 29 Aug 2000 23:17:34 -0400 (EDT) Received: from standards (47.234.32.16:3771) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D61C@standards.nortelnetworks.com>; Tue, 29 Aug 2000 22:59:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2488 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 22:59:54 -0400 Received: from qhars002.nortel.com (47.101.112.102:53758) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D607@standards.nortelnetworks.com>; Tue, 29 Aug 2000 22:59:50 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Mon, 28 Aug 2000 12:43:27 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Sat, 26 Aug 2000 10:03:24 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Sat, 26 Aug 2000 10:06:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00F6F.46928D90" X-Orig: Message-ID: <8E2783FA4E0CD411888D0000F8CD15D33C3904@zcard00q.ca.nortel.com> Date: Sat, 26 Aug 2000 10:06:56 -0500 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: I-D posted: Megaco IP Phone MG 03 X-cc: "Bob Bell (Cisco)" , "Phil Holland (Circa)" To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01C00F6F.46928D90 Content-Type: text/plain; charset="iso-8859-1" Greetings: An updated version of the Megaco IP Phone MG I-D has been submitted as "draft-ietf-megaco-ipphone-03.txt". Updates include: - Removed text regarding subset profile (as proposed and agreed IETF 47), - Added description of termination naming conventions (last remaining technical issue), - Clarified spec covers minimum functionality only, with optional binary encoding, TCP and other transports, extensions (as agreed IETF 47) - Marked as Informational (as agreed IETF 47), - Added sections on Conventions (per RFC 2119) and Security Considerations (null section), - Editorial fix-ups. Above is all as previously agreed. Technical issues and dependencies are now complete. We believe the document is ready for Last Call. Regards, Peter Blatherwick Bob Bell Phil Holland ------_=_NextPart_001_01C00F6F.46928D90 Content-Type: text/html; charset="iso-8859-1" I-D posted: Megaco IP Phone MG 03

Greetings:

An updated version of the Megaco IP Phone MG I-D has been
submitted as "draft-ietf-megaco-ipphone-03.txt". 

Updates include:
- Removed text regarding subset profile (as proposed and
  agreed IETF 47),
- Added description of termination naming conventions
  (last remaining technical issue),
- Clarified spec covers minimum functionality only, with
  optional binary encoding, TCP and other transports,
  extensions (as agreed IETF 47)
- Marked as Informational (as agreed IETF 47),
- Added sections on Conventions (per RFC 2119) and Security
  Considerations (null section),
- Editorial fix-ups.

Above is all as previously agreed.  Technical issues and
dependencies are now complete.  We believe the document is
ready for Last Call.   

Regards,
Peter Blatherwick
Bob Bell
Phil Holland



------_=_NextPart_001_01C00F6F.46928D90-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 23:17:35 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06892 for ; Tue, 29 Aug 2000 23:17:34 -0400 (EDT) Received: from standards (47.234.32.16:3771) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D620@standards.nortelnetworks.com>; Tue, 29 Aug 2000 22:59:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2493 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 22:59:56 -0400 Received: from qhars002.nortel.com (47.101.112.102:53760) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D613@standards.nortelnetworks.com>; Tue, 29 Aug 2000 22:59:52 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Fri, 25 Aug 2000 19:17:39 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Fri, 25 Aug 2000 14:17:08 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 25 Aug 2000 14:17:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00EC0.A62F95E0" Message-ID: <8E2783FA4E0CD411888D0000F8CD15D33C3900@zcard00q.ca.nortel.com> Date: Fri, 25 Aug 2000 14:16:55 -0400 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: draft-ietf-megaco-ipphone-03.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01C00EC0.A62F95E0 Content-Type: text/plain; charset="iso-8859-1" There seems to be considerable phase lag in the list at the moment... Don't Panic! It does not subset the protocol. In fact this was in place in the previous 02 version only "for discussion" (per Editors' Note at top of section). It was proposed (by me) to remove the subset aspect and agreed at IETF 47. Please see announcement to list I posted a short while ago with summary of changes. -- Peter -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] Sent: Friday, August 25, 2000 13:44 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: draft-ietf-megaco-ipphone-03.txt If it still subsets the protocol, I'll oppose any WG action. Nortel, or TIA, or whoever can always ask IESG to do an informational, but I think the WG should stand firm on no subsets. Of course if they have dropped that, then no problem. Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Friday, August 25, 2000 1:14 PM To: ITU-SG16@mailbag.cps.intel.com Subject: draft-ietf-megaco-ipphone-03.txt As indicated in the quotation below, the latest version of the IPPhone profile has been sent to the IETF. If you can't wait for it to be posted, please send an E-mail to Peter Blatherwick asking for a copy. When it appears, I offer it for WG Last Call, with a view to publishing it as an Informational RFC. Tom Taylor -----Original Message----- From: Blatherwick, Peter [CAR:AT14:EXCH] Sent: Friday, August 25, 2000 12:29 To: 'internet-drafts@ietf.org' Cc: 'Bob Bell (Cisco)'; 'Phil Holland (Circa)' Subject: I-D Submission: Megaco IP Phone MG 03 Greetings: Please find I-D submission, "draft-ietf-megaco-ipphone-03.txt", for Megaco WG, attached. This replaces the previous submission of the same name (draft-ietf-megaco-ipphone-02.txt). Please copy announcement to Megaco mailing list (megaco@standards.nortelnetworks.com) when posted. Thanks, and have a great day, Peter Blatherwick 613-763-7539 blather@nortelnetworks.com << File: draft-ietf-megaco-ipphone-03.txt >> ------_=_NextPart_001_01C00EC0.A62F95E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-ietf-megaco-ipphone-03.txt

There seems to be considerable = phase lag in the list at the moment... 

Don't Panic!  It does not = subset the protocol.  In fact this was in place in the previous 02 = version only "for discussion" (per Editors' Note at top of = section).  It was proposed (by me) to remove the subset aspect and = agreed at IETF 47.  Please see announcement to list I posted a = short while ago with summary of changes. 

-- Peter


-----Original = Message-----
From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
Sent: Friday, August 25, 2000 = 13:44
To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: = draft-ietf-megaco-ipphone-03.txt


If it still subsets the = protocol, I'll oppose any WG action.
Nortel, or TIA, or whoever can = always ask IESG to do an informational,
but I think the WG should stand = firm on no subsets.

Of course if they have dropped = that, then no problem.


Brian
-----Original = Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c= om]
Sent: Friday, August 25, 2000 = 1:14 PM
To: = ITU-SG16@mailbag.cps.intel.com
Subject: = draft-ietf-megaco-ipphone-03.txt


As indicated in the quotation = below, the latest version of the IPPhone
profile has been sent to the = IETF.  If you can't wait for it to be posted,
please send an E-mail to Peter = Blatherwick asking for a copy.
When it appears, I offer it for = WG Last Call, with a view to publishing it
as an Informational RFC.
Tom Taylor


-----Original = Message-----
From: Blatherwick, Peter = [CAR:AT14:EXCH]
Sent: Friday, August 25, 2000 = 12:29
To: = 'internet-drafts@ietf.org'
Cc: 'Bob Bell (Cisco)'; 'Phil = Holland (Circa)'
Subject: I-D Submission: Megaco = IP Phone MG 03


Greetings:
Please find I-D submission, = "draft-ietf-megaco-ipphone-03.txt", for Megaco
WG, attached.  This = replaces the previous submission of the same name
(draft-ietf-megaco-ipphone-02.txt).
Please copy announcement to = Megaco mailing list
(megaco@standards.nortelnetworks.com) when posted.
Thanks, and have a great = day,
Peter Blatherwick
613-763-7539
blather@nortelnetworks.com


  << File: = draft-ietf-megaco-ipphone-03.txt >>


------_=_NextPart_001_01C00EC0.A62F95E0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 07:58:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25197 for ; Wed, 30 Aug 2000 07:58:42 -0400 (EDT) Received: from standards (47.234.32.16:3331) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D9C1@standards.nortelnetworks.com>; Wed, 30 Aug 2000 7:45:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3732 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 07:45:08 -0400 Received: from qhars002.nortel.com (47.101.112.102:34812) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D9C0@standards.nortelnetworks.com>; Wed, 30 Aug 2000 7:45:08 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Wed, 30 Aug 2000 12:56:01 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Wed, 30 Aug 2000 07:55:19 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 30 Aug 2000 07:55:19 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480CBA@zcard00g.ca.nortel.com> Date: Wed, 30 Aug 2000 07:55:15 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Support of Values in Packages X-To: Kevin Boyle To: MEGACO@STANDARDS.NORTELNETWORKS.COM You make a valid point about "support" making fewer demands on the MGC than on the MG in many cases. Just to frame the terms of discussion, I would suggest that we use support in the strict sense that the recipient is capable of carrying out the semantic intent, not just process the syntax. The key issues are predictability of MG behaviour vs. package fragmentation. The codec example is (so far) a red herring, since I don't recall a codec property in any of our packages. Our solution to open-ended lists to this point has been package extensions (cf toneids). The hope is that each such extension can cluster a reasonable number of items which one might expect to be supported in the same device. Something like codecs would certainly dash that hope, since there is in general no linkage between the support of one codec and the support of another. We may just have to live with this, in the sense that we end up registering lots of packages. The numbering space for package registration is pretty broad. -----Original Message----- From: Boyle, Kevin [NCRTP:3Z70:EXCH] Sent: Friday, August 25, 2000 2:01 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Support of Values in Packages Hello, A general question here: What, exactly, is meant by "support" of a signal? Does this mean that a gateway will absolutely know what the physical parameters of the signal are, and will play it? Or does it mean something a little less than that, for instance, that the gateway will gracefully accept the signal in question, not necessarily doing anything about it? Generally speaking, signals, and tones in particular, have very precise definitions as to when and how they should be used. So, if there are no phones in need of a particular signal off of a gateway, in theory, that signal would never be requested by the MGC. However, if it was, by the package definition, the MG would be required to support it. Is it incorrect, then, for the MG to successfully acknowledge the signal application command, and then throw the signal away? Maybe the signal could be datafilled to be/do nothing in the MG, in which case ignoring the signal would be a correct application of the signal to the line. MGCs have a little different issue with the meaning of "support". Just because a MGC supports the ability to generate a particular signal to a MG, does not necessarily mean that MGC will ever do so. In this case, "support" becomes a pretty meaningless term. If a signal is never going to be generated, then what does support really mean? That the MGC can generate the signal through manual intervention? The same argument about signal support in MGCs also applies to events as well. If we will never ask for a particular event, what does support of that event mean? For MGs, the same is not true. A MG must be able to report a supported event when it is requested in the Events descriptor. So support of events from a MG standpoint is fairly straightforward. Since properties and statistics are acted upon in both directions, support is also a straightforward concept for these as well. I, too, agree that there is an issue regarding values, as highlighted by the codec example. In the same vein, there needs to be a better definition of what support means, especially in regards to signals and events. I propose, as a starting point for discussion, that "support" of signals in the MG means that the MG will accept the signal, and acknowledge it without error, at the very minimum. Any problem with MGs choosing to ignore important signals will be rectified by the MG's inability to produce quality telephone service without those signals. "Support" in the MGC is a little tougher issue, since support of a signal or event is invisible until such time as the signal or event is requested. Any comments/ideas/statements to correct my misconceptions? ;) Regards, Kevin Boyle CS2K Line Services Nortel Networks Flemming Andreasen wrote: Christian Groves wrote: > G'Day all, > > There has been some confusion at the SG16 on what is supported in > Packages. > > The understanding that I had was that: If you support a package you must > support all the signals, properties, events and statistics. Agreed. > However you > do not have to support all the values associated with the properties and > parameters. I guess the term "values" is somewhat prone to interpretation, but I would tend to disagree if we refer to a list of well-defined values, as e.g. a list of tone ids in E.7. > > > Tom mentioned that a thread discussed on the list contravened this. > > The reasoning that I have for not having to support all the values is > the following: > o Proliferation of packages. Eg: if a package has a list of tones, and I > must support all the values, if I only want to support a subset of these > values then I need a new package. Therefore you may get the case of a > package "Package Call Progress Tones E.7" where an MG doesn't support > Payphone Recognition Tone because it doesn't have payphones connected to > it. However, in this parcticular example, the tones are both signals and tone ids, so the effect would be the same. While I'm not particularly fond of the tonegen package, it does nevertheless illustrate an important point, namely that the distinction between signals, and parameters to signals (and similar for other constructs) is somewhat arbitrary. The package really gives you two things: 1. A name space 2. A convenient grouping of some set of "properties" If we don't know exaclty what those "properties" are, then we've lost a very important aspect of packages. > To be compliant with H.248 I can't extend the package because I want > to remove the payphone tone. So a new Package needs to be defined > containing exactly the same information but without the payphone tone. > Now my MG won't support the standard Call Progress Tone package but will > support the XXX_companies_Call_Progress_Tone package. This would lead to > a proliferation of packages. I agree, but we have to ask ourselves what the idea about packages is. Simplicity and flexibility are often at odds with each other and in this case stress the importance of defining packages very carefully. If I no longer know exactly what is supported in a package, how do I go about using that package ? > > > o Multiple GW support - One MG may not implement all the values of a > property. For something like a list of codecs, a group of resources > associated with the value may be placed in different MG GWs. ie. GSM > codecs in MG1, PCM codecs in MG2. So whilst the MGs support the same > package properties, they can't support a subset of values then you'd > need to define a different package for each MG configuration. Again > leading to a proliferation of packages. Back to defining what "values" mean. Obviously, if we define a "codec" property in a package, we can't expect support for every possible codec in the world. Maybe there's a distinction between supporting values for events, signals, statistics, and properties ? > > > o The MGC knows the PackageID, that all Properties, Signals, Events, > Statistics are supported. In H.248 we have the AuditCapability and > AuditValue commands to find out what actual values of properties are > supported. Not sure how you would do that with event and signal parameters though (come to think of it, I'm not sure how you, in practice, do that for a lot of parameters; "The appropriate descriptors, *with the possible values for the Termination* are returned from AuditCapabilities", Section 7.2.6). On the other, we could have a new property that looked similar, so it's not clear it wouldn't apply there either. > > > So if people agree that not all values in a package need to be supported > I propose to add some text to the implementor's guide: > Section 12.1 after 2nd Paragraph > "A MG SHALL support all Property, Signals & parameters, Events & > parameters and Statistics. A MG MAY support a subset of property and > parameter values defined in the package unless specified in a package." I don't want to deflate the package concept to the extent this would seem to allow, but I agree there's an issue here. Further discussion is needed before we make any change. -- Flemming > > > Cheers, Christian -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 08:27:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26206 for ; Wed, 30 Aug 2000 08:27:34 -0400 (EDT) Received: from standards (47.234.32.16:4661) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DA1E@standards.nortelnetworks.com>; Wed, 30 Aug 2000 8:14:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3853 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 08:14:03 -0400 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DA1D@standards.nortelnetworks.com>; Wed, 30 Aug 2000 8:14:02 -0400 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA06424 for ; Wed, 30 Aug 2000 08:26:44 -0400 (EDT) Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA06413 for ; Wed, 30 Aug 2000 08:26:44 -0400 (EDT) Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA00494; Wed, 30 Aug 2000 14:26:31 +0200 (MET DST) X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF678791@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39ACFD5F.B49DDD11@lucent.com> Date: Wed, 30 Aug 2000 14:26:07 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: About creating contextID and terimnationID To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Brian, It just so happens that I looked at section 7.2.1 (Add) and found the following text: > The TerminationID specifies the termination to be added to the Context. > The Termination is either created, or taken from the null Context. > For an existing Termination, the TerminationID would be specific. > For a Termination that does not yet exist, the TerminationID is > specified as CHOOSE in the command. The new TerminationID will be > returned. This text is not particularly clear, but seems to say that specific physical Terminations are designated in Add commands, while CHOOSE must be used for ephemerals. In my opinion we shouldn't have this restriction in the protocol: in some situations you may want to have the MG select a termination (outgoing circuit within a trunk), in some you have to specify the termination (access GW with subscriber lines). It may make sense to have profiles impose such restrictions. Cheers, John Brian Rosen wrote: > No, the MG creates Contexts, and their IDs, as well as all TerminationIds (both > physical and ephemeral). It is not possible for the MGC to create contextIds or > terminationIds. > > Brian -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 08:47:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27283 for ; Wed, 30 Aug 2000 08:47:37 -0400 (EDT) Received: from standards (47.234.32.16:4661) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DA58@standards.nortelnetworks.com>; Wed, 30 Aug 2000 8:34:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3925 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 08:34:24 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DA57@standards.nortelnetworks.com>; Wed, 30 Aug 2000 8:34:23 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA29861; Wed, 30 Aug 2000 08:47:03 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 IAA01589; Wed, 30 Aug 2000 08:47:05 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 08:47:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787C0@whq-msgusr-02.fore.com> Date: Wed, 30 Aug 2000 08:47:03 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: About creating contextID and terimnationID X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hmmm The original question was "who creates Ids". I believe it's always the MG that creates Ids. For example, the MGC can never specify the TerminationId in an Add for an ephemeral. Clearly, the MGC never specifies the ContextId for a previously non-existing Context. Your issue seems to be who specifies Ids. For physical terminations, I agree that the MGC can specify one, or it can specify CHOOSE, in which case the MG will pick one For ephemeral terminations, I believe the MG always specifies one, so that the MGC must always specify CHOOSE. We could clear up the language you cite to make this clearer. Brian > -----Original Message----- > From: John Segers [mailto:jsegers@LUCENT.COM] > Sent: Wednesday, August 30, 2000 8:26 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: About creating contextID and terimnationID > > > Brian, > > It just so happens that I looked at section 7.2.1 (Add) and found the > following text: > > > The TerminationID specifies the termination to be added to > the Context. > > The Termination is either created, or taken from the null Context. > > For an existing Termination, the TerminationID would be specific. > > For a Termination that does not yet exist, the TerminationID is > > specified as CHOOSE in the command. The new TerminationID will be > > returned. > > This text is not particularly clear, but seems to say that specific > physical Terminations are designated in Add commands, while > CHOOSE must > be used for ephemerals. > > In my opinion we shouldn't have this restriction in the protocol: in > some situations you may want to have the MG select a termination > (outgoing circuit within a trunk), in some you have to specify the > termination (access GW with subscriber lines). > > It may make sense to have profiles impose such restrictions. > > Cheers, > > John > > Brian Rosen wrote: > > No, the MG creates Contexts, and their IDs, as well as all > TerminationIds (both > > physical and ephemeral). It is not possible for the MGC to > create contextIds or > > terminationIds. > > > > Brian > > > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 08:49:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27376 for ; Wed, 30 Aug 2000 08:49:46 -0400 (EDT) Received: from standards (47.234.32.16:4661) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DA78@standards.nortelnetworks.com>; Wed, 30 Aug 2000 8:35:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3965 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 08:35:56 -0400 Received: from qhars002.nortel.com (47.101.112.102:42961) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DA77@standards.nortelnetworks.com>; Wed, 30 Aug 2000 8:35:56 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Wed, 30 Aug 2000 13:48:23 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Wed, 30 Aug 2000 08:47:45 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 30 Aug 2000 08:47:41 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480CBC@zcard00g.ca.nortel.com> Date: Wed, 30 Aug 2000 08:47:37 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: About creating contextID and terimnationID X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Yes, I've certainly considered it a requirement of the protocol that it be possible to ask the MG to choose the outgoing trunk. All these little gotchas! How many more are we going to find? > -----Original Message----- > From: John Segers [mailto:jsegers@LUCENT.COM] > Sent: Wednesday, August 30, 2000 8:26 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: About creating contextID and terimnationID > > > Brian, > > It just so happens that I looked at section 7.2.1 (Add) and found the > following text: > > > The TerminationID specifies the termination to be added to > the Context. > > The Termination is either created, or taken from the null Context. > > For an existing Termination, the TerminationID would be specific. > > For a Termination that does not yet exist, the TerminationID is > > specified as CHOOSE in the command. The new TerminationID will be > > returned. > > This text is not particularly clear, but seems to say that specific > physical Terminations are designated in Add commands, while > CHOOSE must > be used for ephemerals. > > In my opinion we shouldn't have this restriction in the protocol: in > some situations you may want to have the MG select a termination > (outgoing circuit within a trunk), in some you have to specify the > termination (access GW with subscriber lines). > > It may make sense to have profiles impose such restrictions. > > Cheers, > > John > > Brian Rosen wrote: > > No, the MG creates Contexts, and their IDs, as well as all > TerminationIds (both > > physical and ephemeral). It is not possible for the MGC to > create contextIds or > > terminationIds. > > > > Brian > > > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 08:51:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27444 for ; Wed, 30 Aug 2000 08:51:12 -0400 (EDT) Received: from standards (47.234.32.16:4661) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DA91@standards.nortelnetworks.com>; Wed, 30 Aug 2000 8:37:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3996 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 08:37:30 -0400 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DA90@standards.nortelnetworks.com>; Wed, 30 Aug 2000 8:37:29 -0400 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA27592 for ; Wed, 30 Aug 2000 08:50:11 -0400 (EDT) Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA27579 for ; Wed, 30 Aug 2000 08:50:10 -0400 (EDT) Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA01136; Wed, 30 Aug 2000 14:49:57 +0200 (MET DST) X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <8E2783FA4E0CD411888D0000F8CD15D33C391A@zcard00q.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39AD02DD.3956CE26@lucent.com> Date: Wed, 30 Aug 2000 14:49:33 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Case Sensitivity To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit All, The text disappeared, because at the very beginning of Annex B there is a reference to RFC 2234, and RFC 2234 says: > The TerminationID specifies the termination to be added to the Context. The Termination is either created, or taken from the null Context. For an existing Termination, the TerminationID would be specific. For a Termination that does not yet exist, the TerminationID is specified as CHOOSE in the command. The new TerminationID will be returned. > ABNF permits specifying literal text string directly, enclosed in > quotation-marks. Hence: > > command = "command string" > > Literal text strings are interpreted as a concatenated set of > printable characters. > > NOTE: ABNF strings are case-insensitive and > the character set for these strings is us-ascii. > > Hence: > > rulename = "abc" > > and: > > rulename = "aBc" > > will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC" and "ABC". > > To specify a rule which IS case SENSITIVE, > specify the characters individually. > > For example: > > rulename = %d97 %d98 %d99 > > or > > rulename = %d97.98.99 > > > > > > Crocker & Overell Standards Track [Page 4] > > RFC 2234 ABNF for Syntax Specifications November 1997 > > > will match only the string which comprises only lowercased > characters, abc. So the syntax of megaco is really case-insensitive, even quoted strings! Cheers, John > Peter Blatherwick wrote: > > Brian, all: > > Your description below is as I remember it being decided. To me this > does not constitute change, just an editorial mishap. At what stage > did the text go missing (just a curio)? > > -- Peter > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Sent: Tuesday, August 29, 2000 11:56 > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Case Sensitivity > > To be really careful: > SDP is defined case sensitive, and we aren't changing that > quoted strings are case sensitive > So, what we are really saying is that symbols are case insensitive > Symbols include protocol tokens, terminationIds, package names, > events and signals names, property names, statistics names > and enumerated values. > > Brian > > > -----Original Message----- > > From: Rosen, Brian > > Sent: Tuesday, August 29, 2000 11:29 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Case Sensitivity > > > > > > There is confusion on whether text encoding is case sensitive or > not. > > Several of us remember language about this, but there is none now. > > > > I believe, and the sentiment of the room (interop test room), > > is that everything, language tokens, terminationIds, package > > names/events/signals/parameters... is NOT case sensitive. > > > > Any objections? > > > > Brian > > -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 09:01:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27801 for ; Wed, 30 Aug 2000 09:01:02 -0400 (EDT) Received: from standards (47.234.32.16:4661) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DAD8@standards.nortelnetworks.com>; Wed, 30 Aug 2000 8:47:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4089 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 08:47:36 -0400 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DAD7@standards.nortelnetworks.com>; Wed, 30 Aug 2000 8:47:36 -0400 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA08540 for ; Wed, 30 Aug 2000 09:00:18 -0400 (EDT) Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA08500 for ; Wed, 30 Aug 2000 09:00:17 -0400 (EDT) Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA01449; Wed, 30 Aug 2000 15:00:11 +0200 (MET DST) X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF6787C0@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39AD0542.CC0ED560@lucent.com> Date: Wed, 30 Aug 2000 14:59:46 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: About creating contextID and terimnationID To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Brian, You seem to distinguish between creating and specifying Ids, but I don't understand the distinction. Can you elaborate? I agree with your text for physical terminations, but I'm not sure it isn't valid to have the MGC use a specific Id to create an ephemeral termination. John "Rosen, Brian" wrote: > > Hmmm > > The original question was "who creates Ids". I believe it's always the > MG that creates Ids. For example, the MGC can never specify the > TerminationId in an Add for an ephemeral. Clearly, the MGC never > specifies the ContextId for a previously non-existing Context. > > Your issue seems to be who specifies Ids. > For physical terminations, I agree that the MGC can specify one, > or it can specify CHOOSE, in which case the MG will > pick one > For ephemeral terminations, I believe the MG always specifies one, > so that the MGC must always specify CHOOSE. > > We could clear up the language you cite to make this clearer. > > Brian > > > -----Original Message----- > > From: John Segers [mailto:jsegers@LUCENT.COM] > > Sent: Wednesday, August 30, 2000 8:26 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: About creating contextID and terimnationID > > > > > > Brian, > > > > It just so happens that I looked at section 7.2.1 (Add) and found the > > following text: > > > > > The TerminationID specifies the termination to be added to > > the Context. > > > The Termination is either created, or taken from the null Context. > > > For an existing Termination, the TerminationID would be specific. > > > For a Termination that does not yet exist, the TerminationID is > > > specified as CHOOSE in the command. The new TerminationID will be > > > returned. > > > > This text is not particularly clear, but seems to say that specific > > physical Terminations are designated in Add commands, while > > CHOOSE must > > be used for ephemerals. > > > > In my opinion we shouldn't have this restriction in the protocol: in > > some situations you may want to have the MG select a termination > > (outgoing circuit within a trunk), in some you have to specify the > > termination (access GW with subscriber lines). > > > > It may make sense to have profiles impose such restrictions. > > > > Cheers, > > > > John > > > > Brian Rosen wrote: > > > No, the MG creates Contexts, and their IDs, as well as all > > TerminationIds (both > > > physical and ephemeral). It is not possible for the MGC to > > create contextIds or > > > terminationIds. > > > > > > Brian > > > > > > > > -- > > John Segers email: jsegers@lucent.com > > Lucent Technologies Room HE 303 > > Dept. Forward Looking Work phone: +31 35 687 4724 > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 09:43:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29117 for ; Wed, 30 Aug 2000 09:43:45 -0400 (EDT) Received: from standards (47.234.32.16:4315) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DB67@standards.nortelnetworks.com>; Wed, 30 Aug 2000 9:30:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4275 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 09:30:27 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DB66@standards.nortelnetworks.com>; Wed, 30 Aug 2000 9:30:26 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id GAA23510; Wed, 30 Aug 2000 06:43:07 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF6787C0@whq-msgusr-02.fore.com> <39AD0542.CC0ED560@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39AD106F.B18E224D@cisco.com> Date: Wed, 30 Aug 2000 09:47:28 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: About creating contextID and terimnationID X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit John Segers wrote: > Brian, > > You seem to distinguish between creating and specifying Ids, but I don't > understand the distinction. Can you elaborate? Let's say I have an MG with 4 analog access lines and an IP interface supporting RTP terminations. As part of provisioning, I define a name-space for both. In the case of the analog access lines, I define my naming scheme to be aaln/1, aaln/2, aaln/3 and aaln/4. In the case of the IP interface, I define a naming scheme to be RTP/. Now, when adding an analog access line to my context, I *specify* which analog access line I want added, e.g. aaln/1. When adding an RTP termination to the context, I simply need an RTP termination, hence I instruct the MG to create one for me. As part of that creation, a name is assigned to the RTP termination, e.g. RTP/1 > > > I agree with your text for physical terminations, but I'm not sure it > isn't valid to have the MGC use a specific Id to create an ephemeral > termination. The question to ask is why ? In the case of physical terminations, you refer to a specific physical entity and hence you MUST be able to precisely identify that entity. In the case of ephemeral terminations however, the termination does not exist until added to a context, and once subtracted it disappears. In other words, it's not anything permanently referenceable, and hence using a specific Id doesn't mean anything. -- Flemming > > > John > > "Rosen, Brian" wrote: > > > > Hmmm > > > > The original question was "who creates Ids". I believe it's always the > > MG that creates Ids. For example, the MGC can never specify the > > TerminationId in an Add for an ephemeral. Clearly, the MGC never > > specifies the ContextId for a previously non-existing Context. > > > > Your issue seems to be who specifies Ids. > > For physical terminations, I agree that the MGC can specify one, > > or it can specify CHOOSE, in which case the MG will > > pick one > > For ephemeral terminations, I believe the MG always specifies one, > > so that the MGC must always specify CHOOSE. > > > > We could clear up the language you cite to make this clearer. > > > > Brian > > > > > -----Original Message----- > > > From: John Segers [mailto:jsegers@LUCENT.COM] > > > Sent: Wednesday, August 30, 2000 8:26 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: About creating contextID and terimnationID > > > > > > > > > Brian, > > > > > > It just so happens that I looked at section 7.2.1 (Add) and found the > > > following text: > > > > > > > The TerminationID specifies the termination to be added to > > > the Context. > > > > The Termination is either created, or taken from the null Context. > > > > For an existing Termination, the TerminationID would be specific. > > > > For a Termination that does not yet exist, the TerminationID is > > > > specified as CHOOSE in the command. The new TerminationID will be > > > > returned. > > > > > > This text is not particularly clear, but seems to say that specific > > > physical Terminations are designated in Add commands, while > > > CHOOSE must > > > be used for ephemerals. > > > > > > In my opinion we shouldn't have this restriction in the protocol: in > > > some situations you may want to have the MG select a termination > > > (outgoing circuit within a trunk), in some you have to specify the > > > termination (access GW with subscriber lines). > > > > > > It may make sense to have profiles impose such restrictions. > > > > > > Cheers, > > > > > > John > > > > > > Brian Rosen wrote: > > > > No, the MG creates Contexts, and their IDs, as well as all > > > TerminationIds (both > > > > physical and ephemeral). It is not possible for the MGC to > > > create contextIds or > > > > terminationIds. > > > > > > > > Brian > > > > > > > > > > > > -- > > > John Segers email: jsegers@lucent.com > > > Lucent Technologies Room HE 303 > > > Dept. Forward Looking Work phone: +31 35 687 4724 > > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > > > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 09:46:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29193 for ; Wed, 30 Aug 2000 09:46:17 -0400 (EDT) Received: from standards (47.234.32.16:4315) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DB80@standards.nortelnetworks.com>; Wed, 30 Aug 2000 9:32:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4306 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 09:32:55 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DB7F@standards.nortelnetworks.com>; Wed, 30 Aug 2000 9:32:54 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05564; Wed, 30 Aug 2000 09:45:30 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA16507; Wed, 30 Aug 2000 09:45:32 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 09:45:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787C3@whq-msgusr-02.fore.com> Date: Wed, 30 Aug 2000 09:45:29 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: About creating contextID and terimnationID X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Okay, I believe that the MG instantiates all terminations, and when it instantiates them, it names them. For physical terminations, this is done at boot time. For ephemeral terminations, it is done when it is requested, via an Add. I think that in all cases, the MGC specifies CHOOSE for an ephemeral, and the MG obliges by creating the termination, and creating an ID. I think this is best because then the MG uniformly creates names, and the MGC uniformly uses the names the MG defines. I think that there is no advantage in allowing the MGC to create a terminationId for ephemerals, and there is substantial simplicity to the MG to always be the creator of terminationIds and ContextIds. Brian > -----Original Message----- > From: John Segers [mailto:jsegers@LUCENT.COM] > Sent: Wednesday, August 30, 2000 9:00 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: About creating contextID and terimnationID > > > Brian, > > You seem to distinguish between creating and specifying Ids, > but I don't > understand the distinction. Can you elaborate? > > I agree with your text for physical terminations, but I'm not sure it > isn't valid to have the MGC use a specific Id to create an ephemeral > termination. > > John > > "Rosen, Brian" wrote: > > > > Hmmm > > > > The original question was "who creates Ids". I believe > it's always the > > MG that creates Ids. For example, the MGC can never specify the > > TerminationId in an Add for an ephemeral. Clearly, the MGC never > > specifies the ContextId for a previously non-existing Context. > > > > Your issue seems to be who specifies Ids. > > For physical terminations, I agree that the MGC can > specify one, > > or it can specify CHOOSE, in which case the MG will > > pick one > > For ephemeral terminations, I believe the MG always > specifies one, > > so that the MGC must always specify CHOOSE. > > > > We could clear up the language you cite to make this clearer. > > > > Brian > > > > > -----Original Message----- > > > From: John Segers [mailto:jsegers@LUCENT.COM] > > > Sent: Wednesday, August 30, 2000 8:26 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: About creating contextID and terimnationID > > > > > > > > > Brian, > > > > > > It just so happens that I looked at section 7.2.1 (Add) > and found the > > > following text: > > > > > > > The TerminationID specifies the termination to be added to > > > the Context. > > > > The Termination is either created, or taken from the > null Context. > > > > For an existing Termination, the TerminationID would be > specific. > > > > For a Termination that does not yet exist, the TerminationID is > > > > specified as CHOOSE in the command. The new > TerminationID will be > > > > returned. > > > > > > This text is not particularly clear, but seems to say > that specific > > > physical Terminations are designated in Add commands, while > > > CHOOSE must > > > be used for ephemerals. > > > > > > In my opinion we shouldn't have this restriction in the > protocol: in > > > some situations you may want to have the MG select a termination > > > (outgoing circuit within a trunk), in some you have to specify the > > > termination (access GW with subscriber lines). > > > > > > It may make sense to have profiles impose such restrictions. > > > > > > Cheers, > > > > > > John > > > > > > Brian Rosen wrote: > > > > No, the MG creates Contexts, and their IDs, as well as all > > > TerminationIds (both > > > > physical and ephemeral). It is not possible for the MGC to > > > create contextIds or > > > > terminationIds. > > > > > > > > Brian > > > > > > > > > > > > -- > > > John Segers email: > jsegers@lucent.com > > > Lucent Technologies > Room HE 303 > > > Dept. Forward Looking Work phone: > +31 35 687 4724 > > > P.O. Box 18, 1270 AA Huizen fax: > +31 35 687 5954 > > > > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 09:50:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29376 for ; Wed, 30 Aug 2000 09:50:58 -0400 (EDT) Received: from standards (47.234.32.16:4315) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DBBC@standards.nortelnetworks.com>; Wed, 30 Aug 2000 9:37:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4378 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 09:37:45 -0400 Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DBBB@standards.nortelnetworks.com>; Wed, 30 Aug 2000 9:37:45 -0400 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA16018 for ; Wed, 30 Aug 2000 09:50:27 -0400 (EDT) Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA15999 for ; Wed, 30 Aug 2000 09:50:25 -0400 (EDT) Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA02863; Wed, 30 Aug 2000 15:50:12 +0200 (MET DST) X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF6787C0@whq-msgusr-02.fore.com> <39AD0542.CC0ED560@lucent.com> <39AD106F.B18E224D@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39AD10FC.D652261D@lucent.com> Date: Wed, 30 Aug 2000 15:49:48 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: About creating contextID and terimnationID To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Flemming, This makes a lot of sense. So you agree that the name of an ephemeral to be created is partially specified rather than CHOOSE only. Cheers, John Flemming Andreasen wrote: > > John Segers wrote: > > > Brian, > > > > You seem to distinguish between creating and specifying Ids, but I don't > > understand the distinction. Can you elaborate? > > Let's say I have an MG with 4 analog access lines and an IP interface supporting > RTP terminations. As part of provisioning, I define a name-space for both. In > the case of the analog access lines, I define my naming scheme to be aaln/1, > aaln/2, aaln/3 and aaln/4. In the case of the IP interface, I define a naming > scheme to be RTP/. Now, when adding an analog access line to my context, > I *specify* which analog access line I want added, e.g. aaln/1. When adding an > RTP termination to the context, I simply need an RTP termination, hence I > instruct the MG to create one for me. As part of that creation, a name is > assigned to the RTP termination, e.g. RTP/1 > > > > > > > I agree with your text for physical terminations, but I'm not sure it > > isn't valid to have the MGC use a specific Id to create an ephemeral > > termination. > > The question to ask is why ? In the case of physical terminations, you refer to > a specific physical entity and hence you MUST be able to precisely identify that > entity. In the case of ephemeral terminations however, the termination does not > exist until added to a context, and once subtracted it disappears. In other > words, it's not anything permanently referenceable, and hence using a specific > Id doesn't mean anything. > > -- Flemming > > > > > > > John > > > > "Rosen, Brian" wrote: > > > > > > Hmmm > > > > > > The original question was "who creates Ids". I believe it's always the > > > MG that creates Ids. For example, the MGC can never specify the > > > TerminationId in an Add for an ephemeral. Clearly, the MGC never > > > specifies the ContextId for a previously non-existing Context. > > > > > > Your issue seems to be who specifies Ids. > > > For physical terminations, I agree that the MGC can specify one, > > > or it can specify CHOOSE, in which case the MG will > > > pick one > > > For ephemeral terminations, I believe the MG always specifies one, > > > so that the MGC must always specify CHOOSE. > > > > > > We could clear up the language you cite to make this clearer. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: John Segers [mailto:jsegers@LUCENT.COM] > > > > Sent: Wednesday, August 30, 2000 8:26 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: About creating contextID and terimnationID > > > > > > > > > > > > Brian, > > > > > > > > It just so happens that I looked at section 7.2.1 (Add) and found the > > > > following text: > > > > > > > > > The TerminationID specifies the termination to be added to > > > > the Context. > > > > > The Termination is either created, or taken from the null Context. > > > > > For an existing Termination, the TerminationID would be specific. > > > > > For a Termination that does not yet exist, the TerminationID is > > > > > specified as CHOOSE in the command. The new TerminationID will be > > > > > returned. > > > > > > > > This text is not particularly clear, but seems to say that specific > > > > physical Terminations are designated in Add commands, while > > > > CHOOSE must > > > > be used for ephemerals. > > > > > > > > In my opinion we shouldn't have this restriction in the protocol: in > > > > some situations you may want to have the MG select a termination > > > > (outgoing circuit within a trunk), in some you have to specify the > > > > termination (access GW with subscriber lines). > > > > > > > > It may make sense to have profiles impose such restrictions. > > > > > > > > Cheers, > > > > > > > > John > > > > > > > > Brian Rosen wrote: > > > > > No, the MG creates Contexts, and their IDs, as well as all > > > > TerminationIds (both > > > > > physical and ephemeral). It is not possible for the MGC to > > > > create contextIds or > > > > > terminationIds. > > > > > > > > > > Brian > > > > > > > > > > > > > > > > -- > > > > John Segers email: jsegers@lucent.com > > > > Lucent Technologies Room HE 303 > > > > Dept. Forward Looking Work phone: +31 35 687 4724 > > > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > > > > > > > -- > > John Segers email: jsegers@lucent.com > > Lucent Technologies Room HE 303 > > Dept. Forward Looking Work phone: +31 35 687 4724 > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > -- > Flemming Andreasen > Cisco Systems -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 09:57:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29661 for ; Wed, 30 Aug 2000 09:57:43 -0400 (EDT) Received: from standards (47.234.32.16:4315) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DBDD@standards.nortelnetworks.com>; Wed, 30 Aug 2000 9:44:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4421 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 09:44:31 -0400 Received: from qhars002.nortel.com (47.101.112.102:54164) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DBDC@standards.nortelnetworks.com>; Wed, 30 Aug 2000 9:44:26 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Wed, 30 Aug 2000 14:56:51 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Wed, 30 Aug 2000 09:56:08 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 30 Aug 2000 09:56:07 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 30 Aug 2000 09:55:30 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480CC0@zcard00g.ca.nortel.com> Date: Wed, 30 Aug 2000 09:56:04 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: About creating contextID and terimnationID X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM The MGC should be allowed to use either method. > -----Original Message----- > From: John Segers [mailto:jsegers@LUCENT.COM] > Sent: Wednesday, August 30, 2000 9:50 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: About creating contextID and terimnationID > > > Flemming, > > This makes a lot of sense. So you agree that the name of an ephemeral > to be created is partially specified rather than CHOOSE only. > > Cheers, > > John > > Flemming Andreasen wrote: > > > > John Segers wrote: > > > > > Brian, > > > > > > You seem to distinguish between creating and specifying > Ids, but I don't > > > understand the distinction. Can you elaborate? > > > > Let's say I have an MG with 4 analog access lines and an IP > interface supporting > > RTP terminations. As part of provisioning, I define a > name-space for both. In > > the case of the analog access lines, I define my naming > scheme to be aaln/1, > > aaln/2, aaln/3 and aaln/4. In the case of the IP interface, > I define a naming > > scheme to be RTP/. Now, when adding an analog > access line to my context, > > I *specify* which analog access line I want added, e.g. > aaln/1. When adding an > > RTP termination to the context, I simply need an RTP > termination, hence I > > instruct the MG to create one for me. As part of that > creation, a name is > > assigned to the RTP termination, e.g. RTP/1 > > > > > > > > > > > I agree with your text for physical terminations, but I'm > not sure it > > > isn't valid to have the MGC use a specific Id to create > an ephemeral > > > termination. > > > > The question to ask is why ? In the case of physical > terminations, you refer to > > a specific physical entity and hence you MUST be able to > precisely identify that > > entity. In the case of ephemeral terminations however, the > termination does not > > exist until added to a context, and once subtracted it > disappears. In other > > words, it's not anything permanently referenceable, and > hence using a specific > > Id doesn't mean anything. > > > > -- Flemming > > > > > > > > > > > John > > > > > > "Rosen, Brian" wrote: > > > > > > > > Hmmm > > > > > > > > The original question was "who creates Ids". I believe > it's always the > > > > MG that creates Ids. For example, the MGC can never specify the > > > > TerminationId in an Add for an ephemeral. Clearly, the > MGC never > > > > specifies the ContextId for a previously non-existing Context. > > > > > > > > Your issue seems to be who specifies Ids. > > > > For physical terminations, I agree that the MGC > can specify one, > > > > or it can specify CHOOSE, in which case > the MG will > > > > pick one > > > > For ephemeral terminations, I believe the MG > always specifies one, > > > > so that the MGC must always specify CHOOSE. > > > > > > > > We could clear up the language you cite to make this clearer. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: John Segers [mailto:jsegers@LUCENT.COM] > > > > > Sent: Wednesday, August 30, 2000 8:26 AM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: About creating contextID and terimnationID > > > > > > > > > > > > > > > Brian, > > > > > > > > > > It just so happens that I looked at section 7.2.1 > (Add) and found the > > > > > following text: > > > > > > > > > > > The TerminationID specifies the termination to be added to > > > > > the Context. > > > > > > The Termination is either created, or taken from > the null Context. > > > > > > For an existing Termination, the TerminationID > would be specific. > > > > > > For a Termination that does not yet exist, the > TerminationID is > > > > > > specified as CHOOSE in the command. The new > TerminationID will be > > > > > > returned. > > > > > > > > > > This text is not particularly clear, but seems to say > that specific > > > > > physical Terminations are designated in Add commands, while > > > > > CHOOSE must > > > > > be used for ephemerals. > > > > > > > > > > In my opinion we shouldn't have this restriction in > the protocol: in > > > > > some situations you may want to have the MG select a > termination > > > > > (outgoing circuit within a trunk), in some you have > to specify the > > > > > termination (access GW with subscriber lines). > > > > > > > > > > It may make sense to have profiles impose such restrictions. > > > > > > > > > > Cheers, > > > > > > > > > > John > > > > > > > > > > Brian Rosen wrote: > > > > > > No, the MG creates Contexts, and their IDs, as well as all > > > > > TerminationIds (both > > > > > > physical and ephemeral). It is not possible for the MGC to > > > > > create contextIds or > > > > > > terminationIds. > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > -- > > > > > John Segers email: > jsegers@lucent.com > > > > > Lucent Technologies > Room HE 303 > > > > > Dept. Forward Looking Work > phone: +31 35 687 4724 > > > > > P.O. Box 18, 1270 AA Huizen > fax: +31 35 687 5954 > > > > > > > > > > > -- > > > John Segers email: > jsegers@lucent.com > > > Lucent Technologies > Room HE 303 > > > Dept. Forward Looking Work phone: > +31 35 687 4724 > > > P.O. Box 18, 1270 AA Huizen fax: > +31 35 687 5954 > > > > -- > > Flemming Andreasen > > Cisco Systems > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 10:42:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00811 for ; Wed, 30 Aug 2000 10:42:51 -0400 (EDT) Received: from standards (47.234.32.16:1371) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DC13@standards.nortelnetworks.com>; Wed, 30 Aug 2000 10:29:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4492 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 10:29:29 -0400 Received: from mel.alcatel.fr (mail2.alcatel.fr) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DC12@standards.nortelnetworks.com>; Wed, 30 Aug 2000 10:29:29 -0400 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id QAA31520; Wed, 30 Aug 2000 16:41:48 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id QAA08851; Wed, 30 Aug 2000 16:40:07 +0200 (MET DST) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id QAA12078; Wed, 30 Aug 2000 16:41:48 +0200 (MET DST) Received: from ms.alcatel.fr ([188.9.247.87]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id QAA12512; Wed, 30 Aug 2000 16:41:44 +0200 (MET DST) X-Mailer: Mozilla 4.5 [fr] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480C07@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39AD1D76.A8413324@ms.alcatel.fr> Date: Wed, 30 Aug 2000 16:43:02 +0200 Reply-To: Thomas LEVY Sender: "Media Gateway Control (megaco)" From: Thomas LEVY Organization: Alcatel Subject: Re: Draft Meeting Minutes => Changes to the protocol, X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Tom-PT Taylor wrote : > Here are the draft minutes for our meeting last week. Please indicate any > errors or omissions. > > .... > > The Chair noted that list discussion included some proposals for changes to > the protocol. Since Megaco/H.248 has now been fully approved, no changes > are possible to this version of the protocol. > Tom, I have the meaning that after Megaco/H.248 has been fully approved, the Megaco IETF WG will be closed (refer Goals and Milestones). So, how changes to the protocol could be discussed inside IETF after this step? Sincerely, Thomas LEVY, From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 12:56:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04638 for ; Wed, 30 Aug 2000 12:56:00 -0400 (EDT) Received: from standards (47.234.32.16:4864) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DFA7@standards.nortelnetworks.com>; Wed, 30 Aug 2000 12:42:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5804 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 12:42:41 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DFA6@standards.nortelnetworks.com>; Wed, 30 Aug 2000 12:42:40 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA24903 for ; Wed, 30 Aug 2000 12:55:20 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 MAA08160 for ; Wed, 30 Aug 2000 12:55:23 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 12:55:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787C8@whq-msgusr-02.fore.com> Date: Wed, 30 Aug 2000 12:55:21 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: DTMF Events To: MEGACO@STANDARDS.NORTELNETWORKS.COM The wording in Section E.6.2, DTMF detect is ambiguous and has led to an incompatibility. The intention of the section on DTMF digits was that a set of events was defined, d0-d9, da-df,... Each of these events can be used in an event descriptor. The events have no parameters. When detected, these events trigger a notify. So if d0 is mentioned in an event descriptor, and no digitMap is mentioned, and DTMF0 is detected, the event d0 is notified, with no parameters. One implementer assumed that when you set the d0... event, you still got the digitmap completion event notify, with a one digit string. This is not the intention. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 13:06:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04929 for ; Wed, 30 Aug 2000 13:06:38 -0400 (EDT) Received: from standards (47.234.32.16:4864) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DFCC@standards.nortelnetworks.com>; Wed, 30 Aug 2000 12:53:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5853 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 12:53:26 -0400 Received: from qhars002.nortel.com (47.101.112.102:47885) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DFCB@standards.nortelnetworks.com>; Wed, 30 Aug 2000 12:53:26 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Wed, 30 Aug 2000 18:05:35 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Wed, 30 Aug 2000 13:05:08 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 30 Aug 2000 13:05:07 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 30 Aug 2000 13:03:37 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480CC9@zcard00g.ca.nortel.com> Date: Wed, 30 Aug 2000 13:05:00 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: DTMF Events X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM To be clear on this, EITHER you get a digit map completion event (if a digit map was active and it completed) OR you get the individual digit event (otherwise). > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Sent: Wednesday, August 30, 2000 12:55 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: DTMF Events > > > The wording in Section E.6.2, DTMF detect is ambiguous and has > led to an incompatibility. The intention of the section on DTMF > digits was that a set of events was defined, d0-d9, da-df,... > Each of these events can be used in an event descriptor. The > events have no parameters. When detected, these events trigger > a notify. So if d0 is mentioned in an event descriptor, > and no digitMap is mentioned, and DTMF0 is detected, the event > d0 is notified, with no parameters. > > One implementer assumed that when you set the d0... event, > you still got the digitmap completion event notify, with a one digit > string. This is not the intention. > > > Brian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 13:21:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05156 for ; Wed, 30 Aug 2000 13:21:11 -0400 (EDT) Received: from standards (47.234.32.16:4864) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DFFA@standards.nortelnetworks.com>; Wed, 30 Aug 2000 13:07:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5914 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 13:07:58 -0400 Received: from qhars002.nortel.com (47.101.112.102:49023) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DFF9@standards.nortelnetworks.com>; Wed, 30 Aug 2000 13:07:57 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Wed, 30 Aug 2000 18:20:15 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Wed, 30 Aug 2000 12:14:25 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 30 Aug 2000 12:18:02 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD11480CCA@zcard00g.ca.nortel.com> Date: Wed, 30 Aug 2000 12:17:55 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: DTMF Events To: MEGACO@STANDARDS.NORTELNETWORKS.COM That wasn't really clear. I meant to add that if the digit map is active but it hasn't completed, individual digits are absorbed and not reported. > -----Original Message----- > From: Taylor, Tom-PT [NORSE:B901:EXCH] > Sent: Wednesday, August 30, 2000 1:05 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: DTMF Events > > > To be clear on this, EITHER you get a digit map completion > event (if a digit > map was active and it completed) OR you get the individual digit event > (otherwise). > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > Sent: Wednesday, August 30, 2000 12:55 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: DTMF Events > > > > > > The wording in Section E.6.2, DTMF detect is ambiguous and has > > led to an incompatibility. The intention of the section on DTMF > > digits was that a set of events was defined, d0-d9, da-df,... > > Each of these events can be used in an event descriptor. The > > events have no parameters. When detected, these events trigger > > a notify. So if d0 is mentioned in an event descriptor, > > and no digitMap is mentioned, and DTMF0 is detected, the event > > d0 is notified, with no parameters. > > > > One implementer assumed that when you set the d0... event, > > you still got the digitmap completion event notify, with a one digit > > string. This is not the intention. > > > > > > Brian > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 16:50:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08966 for ; Wed, 30 Aug 2000 16:50:59 -0400 (EDT) Received: from standards (47.234.32.16:4638) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E1A0@standards.nortelnetworks.com>; Wed, 30 Aug 2000 16:37:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6454 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 16:37:44 -0400 Received: from qhars002.nortel.com (47.101.112.102:58009) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E19F@standards.nortelnetworks.com>; Wed, 30 Aug 2000 16:27:44 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Wed, 30 Aug 2000 21:40:26 +0100 Received: from zcard015.ca.nortel.com (actually zcard015) by ertpg14e1.nortelnetworks.com; Wed, 30 Aug 2000 16:39:58 -0400 Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id RFR31D8C; Wed, 30 Aug 2000 16:39:57 -0400 Received: from americasm10.nt.com (PMERY0H8 [192.32.71.209]) by zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QY5CTKV9; Wed, 30 Aug 2000 16:39:56 -0400 X-Sybari-Space: 00000000 00000000 00000000 X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480CC0@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39AD725E.295857A5@americasm10.nt.com> Date: Wed, 30 Aug 2000 16:45:18 -0400 Reply-To: Michael Brown Sender: "Media Gateway Control (megaco)" From: Michael Brown Organization: Nortel Networks Subject: Re: About creating contextID and terimnationID To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I also agree that partial specification should be allowed in addition to choose. One other quick point was on an earlier post, the statement was made that physical terminations are created at boot time... physical terminations could also be created/added subsequent to the boot of the MG. "Taylor, Tom-PT" wrote: > The MGC should be allowed to use either method. > > > -----Original Message----- > > From: John Segers [mailto:jsegers@LUCENT.COM] > > Sent: Wednesday, August 30, 2000 9:50 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: About creating contextID and terimnationID > > > > > > Flemming, > > > > This makes a lot of sense. So you agree that the name of an ephemeral > > to be created is partially specified rather than CHOOSE only. > > > > Cheers, > > > > John > > > > Flemming Andreasen wrote: > > > > > > John Segers wrote: > > > > > > > Brian, > > > > > > > > You seem to distinguish between creating and specifying > > Ids, but I don't > > > > understand the distinction. Can you elaborate? > > > > > > Let's say I have an MG with 4 analog access lines and an IP > > interface supporting > > > RTP terminations. As part of provisioning, I define a > > name-space for both. In > > > the case of the analog access lines, I define my naming > > scheme to be aaln/1, > > > aaln/2, aaln/3 and aaln/4. In the case of the IP interface, > > I define a naming > > > scheme to be RTP/. Now, when adding an analog > > access line to my context, > > > I *specify* which analog access line I want added, e.g. > > aaln/1. When adding an > > > RTP termination to the context, I simply need an RTP > > termination, hence I > > > instruct the MG to create one for me. As part of that > > creation, a name is > > > assigned to the RTP termination, e.g. RTP/1 > > > > > > > > > > > > > > > I agree with your text for physical terminations, but I'm > > not sure it > > > > isn't valid to have the MGC use a specific Id to create > > an ephemeral > > > > termination. > > > > > > The question to ask is why ? In the case of physical > > terminations, you refer to > > > a specific physical entity and hence you MUST be able to > > precisely identify that > > > entity. In the case of ephemeral terminations however, the > > termination does not > > > exist until added to a context, and once subtracted it > > disappears. In other > > > words, it's not anything permanently referenceable, and > > hence using a specific > > > Id doesn't mean anything. > > > > > > -- Flemming > > > > > > > > > > > > > > > John > > > > > > > > "Rosen, Brian" wrote: > > > > > > > > > > Hmmm > > > > > > > > > > The original question was "who creates Ids". I believe > > it's always the > > > > > MG that creates Ids. For example, the MGC can never specify the > > > > > TerminationId in an Add for an ephemeral. Clearly, the > > MGC never > > > > > specifies the ContextId for a previously non-existing Context. > > > > > > > > > > Your issue seems to be who specifies Ids. > > > > > For physical terminations, I agree that the MGC > > can specify one, > > > > > or it can specify CHOOSE, in which case > > the MG will > > > > > pick one > > > > > For ephemeral terminations, I believe the MG > > always specifies one, > > > > > so that the MGC must always specify CHOOSE. > > > > > > > > > > We could clear up the language you cite to make this clearer. > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: John Segers [mailto:jsegers@LUCENT.COM] > > > > > > Sent: Wednesday, August 30, 2000 8:26 AM > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > Subject: Re: About creating contextID and terimnationID > > > > > > > > > > > > > > > > > > Brian, > > > > > > > > > > > > It just so happens that I looked at section 7.2.1 > > (Add) and found the > > > > > > following text: > > > > > > > > > > > > > The TerminationID specifies the termination to be added to > > > > > > the Context. > > > > > > > The Termination is either created, or taken from > > the null Context. > > > > > > > For an existing Termination, the TerminationID > > would be specific. > > > > > > > For a Termination that does not yet exist, the > > TerminationID is > > > > > > > specified as CHOOSE in the command. The new > > TerminationID will be > > > > > > > returned. > > > > > > > > > > > > This text is not particularly clear, but seems to say > > that specific > > > > > > physical Terminations are designated in Add commands, while > > > > > > CHOOSE must > > > > > > be used for ephemerals. > > > > > > > > > > > > In my opinion we shouldn't have this restriction in > > the protocol: in > > > > > > some situations you may want to have the MG select a > > termination > > > > > > (outgoing circuit within a trunk), in some you have > > to specify the > > > > > > termination (access GW with subscriber lines). > > > > > > > > > > > > It may make sense to have profiles impose such restrictions. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > John > > > > > > > > > > > > Brian Rosen wrote: > > > > > > > No, the MG creates Contexts, and their IDs, as well as all > > > > > > TerminationIds (both > > > > > > > physical and ephemeral). It is not possible for the MGC to > > > > > > create contextIds or > > > > > > > terminationIds. > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > John Segers email: > > jsegers@lucent.com > > > > > > Lucent Technologies > > Room HE 303 > > > > > > Dept. Forward Looking Work > > phone: +31 35 687 4724 > > > > > > P.O. Box 18, 1270 AA Huizen > > fax: +31 35 687 5954 > > > > > > > > > > > > > > -- > > > > John Segers email: > > jsegers@lucent.com > > > > Lucent Technologies > > Room HE 303 > > > > Dept. Forward Looking Work phone: > > +31 35 687 4724 > > > > P.O. Box 18, 1270 AA Huizen fax: > > +31 35 687 5954 > > > > > > -- > > > Flemming Andreasen > > > Cisco Systems > > > > -- > > John Segers email: jsegers@lucent.com > > Lucent Technologies Room HE 303 > > Dept. Forward Looking Work phone: +31 35 687 4724 > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 17:12:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09277 for ; Wed, 30 Aug 2000 17:12:43 -0400 (EDT) Received: from standards (47.234.32.16:1912) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E1BE@standards.nortelnetworks.com>; Wed, 30 Aug 2000 16:59:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6492 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 16:59:36 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E1BD@standards.nortelnetworks.com>; Wed, 30 Aug 2000 16:59:35 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id OAA09807; Wed, 30 Aug 2000 14:12:16 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF6787C0@whq-msgusr-02.fore.com> <39AD0542.CC0ED560@lucent.com> <39AD106F.B18E224D@cisco.com> <39AD10FC.D652261D@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39AD79B5.1241E68B@cisco.com> Date: Wed, 30 Aug 2000 17:16:37 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: About creating contextID and terimnationID X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit John Segers wrote: > Flemming, > > This makes a lot of sense. So you agree that the name of an ephemeral > to be created is partially specified rather than CHOOSE only. In most cases yes. If you only have a single type of termination, then CHOOSE alone might be fine. If you have multiple, it's not disallowed, but you wouldn't know which one you would get (which most likely is not what you wanted). -- Flemming > > > Cheers, > > John > > Flemming Andreasen wrote: > > > > John Segers wrote: > > > > > Brian, > > > > > > You seem to distinguish between creating and specifying Ids, but I don't > > > understand the distinction. Can you elaborate? > > > > Let's say I have an MG with 4 analog access lines and an IP interface supporting > > RTP terminations. As part of provisioning, I define a name-space for both. In > > the case of the analog access lines, I define my naming scheme to be aaln/1, > > aaln/2, aaln/3 and aaln/4. In the case of the IP interface, I define a naming > > scheme to be RTP/. Now, when adding an analog access line to my context, > > I *specify* which analog access line I want added, e.g. aaln/1. When adding an > > RTP termination to the context, I simply need an RTP termination, hence I > > instruct the MG to create one for me. As part of that creation, a name is > > assigned to the RTP termination, e.g. RTP/1 > > > > > > > > > > > I agree with your text for physical terminations, but I'm not sure it > > > isn't valid to have the MGC use a specific Id to create an ephemeral > > > termination. > > > > The question to ask is why ? In the case of physical terminations, you refer to > > a specific physical entity and hence you MUST be able to precisely identify that > > entity. In the case of ephemeral terminations however, the termination does not > > exist until added to a context, and once subtracted it disappears. In other > > words, it's not anything permanently referenceable, and hence using a specific > > Id doesn't mean anything. > > > > -- Flemming > > > > > > > > > > > John > > > > > > "Rosen, Brian" wrote: > > > > > > > > Hmmm > > > > > > > > The original question was "who creates Ids". I believe it's always the > > > > MG that creates Ids. For example, the MGC can never specify the > > > > TerminationId in an Add for an ephemeral. Clearly, the MGC never > > > > specifies the ContextId for a previously non-existing Context. > > > > > > > > Your issue seems to be who specifies Ids. > > > > For physical terminations, I agree that the MGC can specify one, > > > > or it can specify CHOOSE, in which case the MG will > > > > pick one > > > > For ephemeral terminations, I believe the MG always specifies one, > > > > so that the MGC must always specify CHOOSE. > > > > > > > > We could clear up the language you cite to make this clearer. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: John Segers [mailto:jsegers@LUCENT.COM] > > > > > Sent: Wednesday, August 30, 2000 8:26 AM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: About creating contextID and terimnationID > > > > > > > > > > > > > > > Brian, > > > > > > > > > > It just so happens that I looked at section 7.2.1 (Add) and found the > > > > > following text: > > > > > > > > > > > The TerminationID specifies the termination to be added to > > > > > the Context. > > > > > > The Termination is either created, or taken from the null Context. > > > > > > For an existing Termination, the TerminationID would be specific. > > > > > > For a Termination that does not yet exist, the TerminationID is > > > > > > specified as CHOOSE in the command. The new TerminationID will be > > > > > > returned. > > > > > > > > > > This text is not particularly clear, but seems to say that specific > > > > > physical Terminations are designated in Add commands, while > > > > > CHOOSE must > > > > > be used for ephemerals. > > > > > > > > > > In my opinion we shouldn't have this restriction in the protocol: in > > > > > some situations you may want to have the MG select a termination > > > > > (outgoing circuit within a trunk), in some you have to specify the > > > > > termination (access GW with subscriber lines). > > > > > > > > > > It may make sense to have profiles impose such restrictions. > > > > > > > > > > Cheers, > > > > > > > > > > John > > > > > > > > > > Brian Rosen wrote: > > > > > > No, the MG creates Contexts, and their IDs, as well as all > > > > > TerminationIds (both > > > > > > physical and ephemeral). It is not possible for the MGC to > > > > > create contextIds or > > > > > > terminationIds. > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > -- > > > > > John Segers email: jsegers@lucent.com > > > > > Lucent Technologies Room HE 303 > > > > > Dept. Forward Looking Work phone: +31 35 687 4724 > > > > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > > > > > > > > > > -- > > > John Segers email: jsegers@lucent.com > > > Lucent Technologies Room HE 303 > > > Dept. Forward Looking Work phone: +31 35 687 4724 > > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > > > -- > > Flemming Andreasen > > Cisco Systems > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 17:22:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09405 for ; Wed, 30 Aug 2000 17:22:12 -0400 (EDT) Received: from standards (47.234.32.16:1912) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E1DF@standards.nortelnetworks.com>; Wed, 30 Aug 2000 17:09:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6535 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 17:08:59 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E1DE@standards.nortelnetworks.com>; Wed, 30 Aug 2000 17:08:59 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA17875; Wed, 30 Aug 2000 17:21:39 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA13271; Wed, 30 Aug 2000 17:21:42 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 17:21:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787CF@whq-msgusr-02.fore.com> Date: Wed, 30 Aug 2000 17:21:39 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: About creating contextID and terimnationID X-To: Michael Brown To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'll agree, CHOOSE or Wildcard should be acceptable. I also agree that you could create new physical terminations after boot. At the moment, you would need to use some external mechanism to let the MGC know that they were there. Someday, I could see a package with an event that let the MGC know about new terminations. Brian > -----Original Message----- > From: Michael Brown [mailto:C.Michael.Brown@NORTELNETWORKS.COM] > Sent: Wednesday, August 30, 2000 4:45 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: About creating contextID and terimnationID > > > I also agree that partial specification should be allowed in > addition to > choose. > > One other quick point was on an earlier post, the statement > was made that > physical terminations are created at boot time... physical > terminations > could also be created/added subsequent to the boot of the MG. > > "Taylor, Tom-PT" wrote: > > > The MGC should be allowed to use either method. > > > > > -----Original Message----- > > > From: John Segers [mailto:jsegers@LUCENT.COM] > > > Sent: Wednesday, August 30, 2000 9:50 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: About creating contextID and terimnationID > > > > > > > > > Flemming, > > > > > > This makes a lot of sense. So you agree that the name of > an ephemeral > > > to be created is partially specified rather than CHOOSE only. > > > > > > Cheers, > > > > > > John > > > > > > Flemming Andreasen wrote: > > > > > > > > John Segers wrote: > > > > > > > > > Brian, > > > > > > > > > > You seem to distinguish between creating and specifying > > > Ids, but I don't > > > > > understand the distinction. Can you elaborate? > > > > > > > > Let's say I have an MG with 4 analog access lines and an IP > > > interface supporting > > > > RTP terminations. As part of provisioning, I define a > > > name-space for both. In > > > > the case of the analog access lines, I define my naming > > > scheme to be aaln/1, > > > > aaln/2, aaln/3 and aaln/4. In the case of the IP interface, > > > I define a naming > > > > scheme to be RTP/. Now, when adding an analog > > > access line to my context, > > > > I *specify* which analog access line I want added, e.g. > > > aaln/1. When adding an > > > > RTP termination to the context, I simply need an RTP > > > termination, hence I > > > > instruct the MG to create one for me. As part of that > > > creation, a name is > > > > assigned to the RTP termination, e.g. RTP/1 > > > > > > > > > > > > > > > > > > > I agree with your text for physical terminations, but I'm > > > not sure it > > > > > isn't valid to have the MGC use a specific Id to create > > > an ephemeral > > > > > termination. > > > > > > > > The question to ask is why ? In the case of physical > > > terminations, you refer to > > > > a specific physical entity and hence you MUST be able to > > > precisely identify that > > > > entity. In the case of ephemeral terminations however, the > > > termination does not > > > > exist until added to a context, and once subtracted it > > > disappears. In other > > > > words, it's not anything permanently referenceable, and > > > hence using a specific > > > > Id doesn't mean anything. > > > > > > > > -- Flemming > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > "Rosen, Brian" wrote: > > > > > > > > > > > > Hmmm > > > > > > > > > > > > The original question was "who creates Ids". I believe > > > it's always the > > > > > > MG that creates Ids. For example, the MGC can > never specify the > > > > > > TerminationId in an Add for an ephemeral. Clearly, the > > > MGC never > > > > > > specifies the ContextId for a previously > non-existing Context. > > > > > > > > > > > > Your issue seems to be who specifies Ids. > > > > > > For physical terminations, I agree that the MGC > > > can specify one, > > > > > > or it can specify CHOOSE, in which case > > > the MG will > > > > > > pick one > > > > > > For ephemeral terminations, I believe the MG > > > always specifies one, > > > > > > so that the MGC must always specify CHOOSE. > > > > > > > > > > > > We could clear up the language you cite to make > this clearer. > > > > > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: John Segers [mailto:jsegers@LUCENT.COM] > > > > > > > Sent: Wednesday, August 30, 2000 8:26 AM > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > > Subject: Re: About creating contextID and terimnationID > > > > > > > > > > > > > > > > > > > > > Brian, > > > > > > > > > > > > > > It just so happens that I looked at section 7.2.1 > > > (Add) and found the > > > > > > > following text: > > > > > > > > > > > > > > > The TerminationID specifies the termination to > be added to > > > > > > > the Context. > > > > > > > > The Termination is either created, or taken from > > > the null Context. > > > > > > > > For an existing Termination, the TerminationID > > > would be specific. > > > > > > > > For a Termination that does not yet exist, the > > > TerminationID is > > > > > > > > specified as CHOOSE in the command. The new > > > TerminationID will be > > > > > > > > returned. > > > > > > > > > > > > > > This text is not particularly clear, but seems to say > > > that specific > > > > > > > physical Terminations are designated in Add > commands, while > > > > > > > CHOOSE must > > > > > > > be used for ephemerals. > > > > > > > > > > > > > > In my opinion we shouldn't have this restriction in > > > the protocol: in > > > > > > > some situations you may want to have the MG select a > > > termination > > > > > > > (outgoing circuit within a trunk), in some you have > > > to specify the > > > > > > > termination (access GW with subscriber lines). > > > > > > > > > > > > > > It may make sense to have profiles impose such > restrictions. > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > John > > > > > > > > > > > > > > Brian Rosen wrote: > > > > > > > > No, the MG creates Contexts, and their IDs, as > well as all > > > > > > > TerminationIds (both > > > > > > > > physical and ephemeral). It is not possible > for the MGC to > > > > > > > create contextIds or > > > > > > > > terminationIds. > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > John Segers email: > > > jsegers@lucent.com > > > > > > > Lucent Technologies > > > Room HE 303 > > > > > > > Dept. Forward Looking Work > > > phone: +31 35 687 4724 > > > > > > > P.O. Box 18, 1270 AA Huizen > > > fax: +31 35 687 5954 > > > > > > > > > > > > > > > > > -- > > > > > John Segers email: > > > jsegers@lucent.com > > > > > Lucent Technologies > > > Room HE 303 > > > > > Dept. Forward Looking Work phone: > > > +31 35 687 4724 > > > > > P.O. Box 18, 1270 AA Huizen fax: > > > +31 35 687 5954 > > > > > > > > -- > > > > Flemming Andreasen > > > > Cisco Systems > > > > > > -- > > > John Segers email: > jsegers@lucent.com > > > Lucent Technologies > Room HE 303 > > > Dept. Forward Looking Work phone: > +31 35 687 4724 > > > P.O. Box 18, 1270 AA Huizen fax: > +31 35 687 5954 > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 17:35:06 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09585 for ; Wed, 30 Aug 2000 17:35:05 -0400 (EDT) Received: from standards (47.234.32.16:1912) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E1FE@standards.nortelnetworks.com>; Wed, 30 Aug 2000 17:21:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6575 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 17:21:59 -0400 Received: from qhars002.nortel.com (47.101.112.102:60044) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E1FD@standards.nortelnetworks.com>; Wed, 30 Aug 2000 17:21:59 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Wed, 30 Aug 2000 22:33:31 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Wed, 30 Aug 2000 16:29:18 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 30 Aug 2000 16:32:55 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD11480CCD@zcard00g.ca.nortel.com> Date: Wed, 30 Aug 2000 16:32:10 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: About creating contextID and terimnationID X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM How about ServiceChange to signal their coming into service? > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Sent: Wednesday, August 30, 2000 5:22 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: About creating contextID and terimnationID > > > I'll agree, CHOOSE or Wildcard should be acceptable. > > I also agree that you could create new physical terminations > after boot. At the moment, you would need to use some external > mechanism to let the MGC know that they were there. > Someday, I could see a package with an event that let the > MGC know about new terminations. > > Brian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 17:49:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09762 for ; Wed, 30 Aug 2000 17:49:49 -0400 (EDT) Received: from standards (47.234.32.16:1912) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E222@standards.nortelnetworks.com>; Wed, 30 Aug 2000 17:36:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6621 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 17:36:40 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E221@standards.nortelnetworks.com>; Wed, 30 Aug 2000 17:36:40 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA19844; Wed, 30 Aug 2000 17:49:15 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 RAA18537; Wed, 30 Aug 2000 17:49:14 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 17:49:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C012CC.21BA79D2" Message-ID: <4FBEA8857476D311A03300204840E1CF6787D0@whq-msgusr-02.fore.com> Date: Wed, 30 Aug 2000 17:49:10 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: About creating contextID and terimnationID X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01C012CC.21BA79D2 Content-Type: text/plain; charset="iso-8859-1" Doh!!! Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Wednesday, August 30, 2000 5:32 PM To: Rosen, Brian; megaco@standards.nortelnetworks.com Subject: RE: About creating contextID and terimnationID How about ServiceChange to signal their coming into service? > -----Original Message----- > From: Rosen, Brian [ mailto:Brian.Rosen@MARCONI.COM ] > Sent: Wednesday, August 30, 2000 5:22 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: About creating contextID and terimnationID > > > I'll agree, CHOOSE or Wildcard should be acceptable. > > I also agree that you could create new physical terminations > after boot. At the moment, you would need to use some external > mechanism to let the MGC know that they were there. > Someday, I could see a package with an event that let the > MGC know about new terminations. > > Brian > ------_=_NextPart_001_01C012CC.21BA79D2 Content-Type: text/html; charset="iso-8859-1" RE: About creating contextID and terimnationID
Doh!!!
 
Brian
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Wednesday, August 30, 2000 5:32 PM
To: Rosen, Brian; megaco@standards.nortelnetworks.com
Subject: RE: About creating contextID and terimnationID

How about ServiceChange to signal their coming into service?

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Wednesday, August 30, 2000 5:22 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: About creating contextID and terimnationID
>
>
> I'll agree, CHOOSE or Wildcard should be acceptable.
>
> I also agree that you could create new physical terminations
> after boot.  At the moment, you would need to use some external
> mechanism to let the MGC know that they were there.
> Someday, I could see a package with an event that let the
> MGC know about new terminations.
>
> Brian
>

------_=_NextPart_001_01C012CC.21BA79D2-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 19:20:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10872 for ; Wed, 30 Aug 2000 19:20:18 -0400 (EDT) Received: from standards (47.234.32.16:1270) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E2C5@standards.nortelnetworks.com>; Wed, 30 Aug 2000 19:07:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6831 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 19:07:13 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E2C4@standards.nortelnetworks.com>; Wed, 30 Aug 2000 19:07:13 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA25152 for ; Wed, 30 Aug 2000 19:19:53 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 TAA00372 for ; Wed, 30 Aug 2000 19:19:56 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 19:19:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787D3@whq-msgusr-02.fore.com> Date: Wed, 30 Aug 2000 19:19:53 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Statistics when you delete a stream To: MEGACO@STANDARDS.NORTELNETWORKS.COM The way the protocol is defined now, if you were to create a stream on a termination, run some media, delete the stream, and then re-establish the stream (maybe to another IP address), you would not get statistics automatically on the delete of the stream. As defined now, statistics are only generated automatically when a Subtract is done on the termination. Do list members think that this behavior is correct? Or should statistics be generated if a stream is deleted? I personally think the current spec is correct, because the statistics are kept on the TERMINATION and not the STREAM. You can always get the statistics by specifying Audit of Statistics on the deletion of the stream. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 19:54:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11142 for ; Wed, 30 Aug 2000 19:54:55 -0400 (EDT) Received: from standards (47.234.32.16:3707) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E320@standards.nortelnetworks.com>; Wed, 30 Aug 2000 19:41:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6949 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 19:41:48 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E31F@standards.nortelnetworks.com>; Wed, 30 Aug 2000 19:41:47 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA00713 for ; Wed, 30 Aug 2000 19:54:28 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA11086 for ; Wed, 30 Aug 2000 19:54:31 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 19:54:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787D4@whq-msgusr-02.fore.com> Date: Wed, 30 Aug 2000 19:54:29 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: First Megaco Interop Test a big success! To: MEGACO@STANDARDS.NORTELNETWORKS.COM Testing has just completed at the first interop event. We had some dropouts (implementations that could not complete any significant testing due to bugs). My actual participation count is 16 organizations, 48 people, 10 MG implementations and 6 MGC implementations, all independently developed. There were three test equipment vendors who brought network analyzers. Of the 10 x 6 pair matrix, there were 6 instances of a single implementer bring both MG and MGCs, which we did not test. One of the MGs could only send binary encoded commands, and only one of the MGCs could handle binary (it could also do text encoding). Of the remaining 48 possible pairs, we tried all but 13. As you might expect, nothing worked on first try! Plenty of furious code debugging, patching, editing and recompiling commenced. Of the trials, we judged 6 as failing - which primarily were due to incompatible simplifying assumptions made in the clearly early stage of implementing. 7 of the tests passed up to Level 1, which was a very simple connection between two ports of a gateway. The rest were judged to have passed up to Level 3, which is a real basic call, with dial tone, hook switch, dialplan, ring and answer! Almost all of these included media flow! We counted some of these as passing even if there were some small problems. We had several successful calls between two MGs, including a test of two MGs from different implementers with a MGC from a third! I have now issued emails to the list with all of the issues we discovered (other than clearly wrong assumptions made by almost everyone at some point). I'd say the document is pretty darn good. There will be a formal report of the event issued as an I-D within the next couple of weeks. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 20:09:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11412 for ; Wed, 30 Aug 2000 20:09:52 -0400 (EDT) Received: from standards (47.234.32.16:3707) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E34A@standards.nortelnetworks.com>; Wed, 30 Aug 2000 19:56:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6993 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 19:56:40 -0400 Received: from boreas.isi.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E342@standards.nortelnetworks.com>; Wed, 30 Aug 2000 19:46:38 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA26933; Wed, 30 Aug 2000 16:59:06 -0700 (PDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Message-ID: <200008302359.QAA26933@boreas.isi.edu> Date: Wed, 30 Aug 2000 16:59:06 -0700 Reply-To: RFC Editor Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: RFC Editor Subject: RFC 2885 on Megaco Protocol To: MEGACO@STANDARDS.NORTELNETWORKS.COM --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2885 Title: Megaco Protocol 0.8 Author(s): F. Cuervo, N. Greene, C. Huitema, A. Rayhan, B. Rosen, J. Segers Status: Standards Track Date: August 2000 Mailbox: fcuervo@nortelnetworks.com, ngreene@nortelnetworks.com, huitema@microsoft.com, arayhan@nortelnetworks.com, brian.rosen@marconi.com, jsegers@lucent.com Pages: 169 Characters: 344871 Obsoletes/Updates/SeeAlso: None I-D Tag: draft-ietf-megaco-protocol-08.txt URL: ftp://ftp.isi.edu/in-notes/rfc2885.txt This document is common text with Recommendation H.248 as redetermined in Geneva, February 2000. It must be read in conjunction with the Megaco Errata, RFC 2886. A merged document presenting the Megaco protocol with the Errata incorporated will be available shortly. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. This document is a product of the Media Gateway Control Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000830165634.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2885 --OtherAccess Content-Type: Message/External-body; name="rfc2885.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000830165634.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 20:11:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11453 for ; Wed, 30 Aug 2000 20:11:53 -0400 (EDT) Received: from standards (47.234.32.16:3707) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E361@standards.nortelnetworks.com>; Wed, 30 Aug 2000 19:58:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6994 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 19:58:35 -0400 Received: from boreas.isi.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E343@standards.nortelnetworks.com>; Wed, 30 Aug 2000 19:48:34 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA27557; Wed, 30 Aug 2000 17:01:00 -0700 (PDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Message-ID: <200008310001.RAA27557@boreas.isi.edu> Date: Wed, 30 Aug 2000 17:01:00 -0700 Reply-To: RFC Editor Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: RFC Editor Subject: RFC 2886 on Megaco Errata To: MEGACO@STANDARDS.NORTELNETWORKS.COM --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2886 Title: Megaco Errata Author(s): T. Taylor Status: Standards Track Date: August 2000 Mailbox: taylor@nortelnetworks.com Pages: 22 Characters: 41311 Obsoletes/Updates/SeeAlso: None I-D Tag: draft-ietf-megaco-errata-03.txt URL: ftp://ftp.isi.edu/in-notes/rfc2886.txt This document records the errors found in the Megaco/H.248 protocol document [2], along with the changes proposed in the text of that document to resolve them. This document is a product of the Media Gateway Control Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000830165929.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2886 --OtherAccess Content-Type: Message/External-body; name="rfc2886.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000830165929.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 20:45:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12176 for ; Wed, 30 Aug 2000 20:45:26 -0400 (EDT) Received: from standards (47.234.32.16:3707) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E399@standards.nortelnetworks.com>; Wed, 30 Aug 2000 20:32:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7097 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 20:32:21 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E394@standards.nortelnetworks.com>; Wed, 30 Aug 2000 20:22:21 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e7V0Z3p27037 for ; Thu, 31 Aug 2000 02:35:03 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id CAA22895 for ; Thu, 31 Aug 2000 02:35:02 +0200 (MET DST) Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id CAA07862 for ; Thu, 31 Aug 2000 02:34:59 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39ADA82E.6A8F46E0@ericsson.com> Date: Thu, 31 Aug 2000 11:34:54 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: H.248v1 Implementor's Guide Editor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day All, At the Portland SG16 meeting I was appointed editor of the H.248v1 Implementor's Guide. I will shortly make available a first draft containing agree changes from the SG16 meeting. I will also start collating that are raised on this list for input to the next SG16 meeting. So please be kind when you see me keep asking for proposed text when we are discussing a problem. I believe it makes it clear to people what is being discussed and its helps me write a guide that people accept. Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 21:02:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12598 for ; Wed, 30 Aug 2000 21:02:00 -0400 (EDT) Received: from standards (47.234.32.16:3707) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E3C6@standards.nortelnetworks.com>; Wed, 30 Aug 2000 20:48:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7146 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 20:48:20 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E3BA@standards.nortelnetworks.com>; Wed, 30 Aug 2000 20:38:19 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e7V0p2p27853 for ; Thu, 31 Aug 2000 02:51:02 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id CAA23015 for ; Thu, 31 Aug 2000 02:51:02 +0200 (MET DST) Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id CAA07935 for ; Thu, 31 Aug 2000 02:50:59 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF6787A8@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39ADA3C9.3E93F4D8@ericsson.com> Date: Thu, 31 Aug 2000 11:16:09 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Accepting Null bodies To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Brian, Agreed it certainly is a bit weird. I propose to add the following text to the implementor's guide in 7.2.3 Subtract "...and returning all physical terminations to Null context. Subtract of termination from the NULL context is not allowed." Does anyone disagree? CHeers, Christian "Rosen, Brian" wrote: > > It seems obvious to me that an MG should always accept a > command which has no descriptors, assuming that the contextId > and the terminationIds are legal. It's a NOP, but it's legal. > > Now, someone here tried to send Context= - {Subtract=*{}} > That's not legal (can't subtract from null context}. > > Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 21:02:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12602 for ; Wed, 30 Aug 2000 21:02:02 -0400 (EDT) Received: from standards (47.234.32.16:3707) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E3CD@standards.nortelnetworks.com>; Wed, 30 Aug 2000 20:48:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7147 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 20:48:25 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E3BB@standards.nortelnetworks.com>; Wed, 30 Aug 2000 20:38:24 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7V0p7w12330 for ; Thu, 31 Aug 2000 02:51:07 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id CAA23019 for ; Thu, 31 Aug 2000 02:51:07 +0200 (MET DST) Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id CAA07939 for ; Thu, 31 Aug 2000 02:51:04 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480CAE@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39ADA48D.CCB79B35@ericsson.com> Date: Thu, 31 Aug 2000 11:19:25 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Is Media required on the Physical Termination/Default value for M ODE To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day all, I would have thought that the default was inactive for a termination and that the stream mode would be off unless otherwise provisioned in the MG. If a MGC wanted media to flows then it could set the mode to send/receive when it did the ADD. I think its important to let the MGC decide when it wants the cut through to occur on terminations ie. s/r on both terminations. Cheers, Christian Tom-PT Taylor wrote: > > Sorry, Brian, the natural default is "inactive". It does seem that we > failed to specify the defaults in 7.1.7, even though section 6.2.4 promises > that we would. > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > Sent: Tuesday, August 29, 2000 4:30 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Is Media required on the Physical > > Termination/Default value > > f or M ODE > > > > > > Okay, so what would you expect to happen if you audited media of > > the physical termination. Even if there was no default, it should > > be one of the legal states. > > > > Now, suppose it's in an acceptable state, should you have to send > > a media descriptor? > > > > What the folks who implemented the MG requiring the media descriptor > > say is that "there is no mode, you haven't set it". I can't deal > > with that, because audit has to return a value. So it has to be > > something, and the MGC should be able to leave it, right? > > > > Now, I said I think MGCs should always send media! > > > > Brian > > > > > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: Tuesday, August 29, 2000 4:25 PM > > > To: Rosen, Brian > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Is Media required on the Physical > > > Termination/Default value for > > > M ODE > > > > > > > > > > > > My general take has been that the MGC shouldn't > > > assume much about the MG. If it wants the MG to > > > do something, it should tell it. If it doesn't > > > know the MG's state, it should audit it. > > > Therefore, I think I disagree with the spec > > > requiring some set of semantics for underspecified > > > commands. What's the gain? > > > > > > Mike > > > > > > Rosen, Brian writes: > > > > Another issue from the event: > > > > > > > > Is it REQUIRED that the MGC send a media descriptor to a PHYSICAL > > > > termination in order to get media to flow? > > > > > > > > There are two questions actually: > > > > 1) Is there a default state of MODE (text is silent) > > > > 2) Should the MG demand a media descriptor before allowing > > > media flow? > > > > > > > > I believe: > > > > 1) The default for MODE is SendRecieve > > > > 2) MGCs should always send a media descriptor, with at > > least a MODE > > > > setting > > > > 3) MGs should not depend on 2) > > > > > > > > Brian > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 21:02:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12615 for ; Wed, 30 Aug 2000 21:02:02 -0400 (EDT) Received: from standards (47.234.32.16:3707) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E3D6@standards.nortelnetworks.com>; Wed, 30 Aug 2000 20:48:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7148 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 20:48:34 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E3BC@standards.nortelnetworks.com>; Wed, 30 Aug 2000 20:38:34 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e7V0pHp27881; Thu, 31 Aug 2000 02:51:17 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id CAA23023; Thu, 31 Aug 2000 02:51:16 +0200 (MET DST) Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id CAA07943; Thu, 31 Aug 2000 02:51:09 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF6787C3@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39ADA548.908175E4@ericsson.com> Date: Thu, 31 Aug 2000 11:22:32 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: About creating contextID and terimnationID X-cc: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Brian, I think this seems like a resolution to the issue. Do you think this is something for the implementor's guide? If so can you suggest some text? Cheers, Christian "Rosen, Brian" wrote: > > Okay, I believe that the MG instantiates all terminations, > and when it instantiates them, it names them. For physical > terminations, this is done at boot time. For ephemeral > terminations, it is done when it is requested, via an Add. > > I think that in all cases, the MGC specifies CHOOSE for > an ephemeral, and the MG obliges by creating the termination, > and creating an ID. I think this is best because then > the MG uniformly creates names, and the MGC uniformly > uses the names the MG defines. > > I think that there is no advantage in allowing the MGC to > create a terminationId for ephemerals, and there is > substantial simplicity to the MG to always be the > creator of terminationIds and ContextIds. > > Brian > > > -----Original Message----- > > From: John Segers [mailto:jsegers@LUCENT.COM] > > Sent: Wednesday, August 30, 2000 9:00 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: About creating contextID and terimnationID > > > > > > Brian, > > > > You seem to distinguish between creating and specifying Ids, > > but I don't > > understand the distinction. Can you elaborate? > > > > I agree with your text for physical terminations, but I'm not sure it > > isn't valid to have the MGC use a specific Id to create an ephemeral > > termination. > > > > John > > > > "Rosen, Brian" wrote: > > > > > > Hmmm > > > > > > The original question was "who creates Ids". I believe > > it's always the > > > MG that creates Ids. For example, the MGC can never specify the > > > TerminationId in an Add for an ephemeral. Clearly, the MGC never > > > specifies the ContextId for a previously non-existing Context. > > > > > > Your issue seems to be who specifies Ids. > > > For physical terminations, I agree that the MGC can > > specify one, > > > or it can specify CHOOSE, in which case the MG will > > > pick one > > > For ephemeral terminations, I believe the MG always > > specifies one, > > > so that the MGC must always specify CHOOSE. > > > > > > We could clear up the language you cite to make this clearer. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: John Segers [mailto:jsegers@LUCENT.COM] > > > > Sent: Wednesday, August 30, 2000 8:26 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: About creating contextID and terimnationID > > > > > > > > > > > > Brian, > > > > > > > > It just so happens that I looked at section 7.2.1 (Add) > > and found the > > > > following text: > > > > > > > > > The TerminationID specifies the termination to be added to > > > > the Context. > > > > > The Termination is either created, or taken from the > > null Context. > > > > > For an existing Termination, the TerminationID would be > > specific. > > > > > For a Termination that does not yet exist, the TerminationID is > > > > > specified as CHOOSE in the command. The new > > TerminationID will be > > > > > returned. > > > > > > > > This text is not particularly clear, but seems to say > > that specific > > > > physical Terminations are designated in Add commands, while > > > > CHOOSE must > > > > be used for ephemerals. > > > > > > > > In my opinion we shouldn't have this restriction in the > > protocol: in > > > > some situations you may want to have the MG select a termination > > > > (outgoing circuit within a trunk), in some you have to specify the > > > > termination (access GW with subscriber lines). > > > > > > > > It may make sense to have profiles impose such restrictions. > > > > > > > > Cheers, > > > > > > > > John > > > > > > > > Brian Rosen wrote: > > > > > No, the MG creates Contexts, and their IDs, as well as all > > > > TerminationIds (both > > > > > physical and ephemeral). It is not possible for the MGC to > > > > create contextIds or > > > > > terminationIds. > > > > > > > > > > Brian > > > > > > > > > > > > > > > > -- > > > > John Segers email: > > jsegers@lucent.com > > > > Lucent Technologies > > Room HE 303 > > > > Dept. Forward Looking Work phone: > > +31 35 687 4724 > > > > P.O. Box 18, 1270 AA Huizen fax: > > +31 35 687 5954 > > > > > > > > -- > > John Segers email: jsegers@lucent.com > > Lucent Technologies Room HE 303 > > Dept. Forward Looking Work phone: +31 35 687 4724 > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 21:02:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12622 for ; Wed, 30 Aug 2000 21:02:03 -0400 (EDT) Received: from standards (47.234.32.16:3707) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E3DE@standards.nortelnetworks.com>; Wed, 30 Aug 2000 20:48:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7149 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 20:48:42 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E3BD@standards.nortelnetworks.com>; Wed, 30 Aug 2000 20:38:42 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e7V0pPp27889 for ; Thu, 31 Aug 2000 02:51:25 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id CAA23038 for ; Thu, 31 Aug 2000 02:51:24 +0200 (MET DST) Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id CAA07955 for ; Thu, 31 Aug 2000 02:51:22 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480CB6@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39ADA710.8AECB288@ericsson.com> Date: Thu, 31 Aug 2000 11:30:09 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Media without Stream To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Yes, I agree Tom I thought it was covered in 7.1.4: As a convenience a LocalControl, Local, or Remote descriptor may be included in the Media Descriptor without an enclosing Stream descriptor. In this case, the StreamID is assumed to be 1. Cheers, Christian Tom-PT Taylor wrote: > > This is the optimized syntax for single stream (e.g. voice-only) operation. > It has been there ever since we invented streams, since one of the > constraints on handling of multimedia was that it not discommode > straightforward VoIP operation. > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > Sent: Tuesday, August 29, 2000 7:46 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Media without Stream > > > > > > It may come as a surprise to some of you, as it did to me, that you > > can say: > > > > Media=termId{Local.... > > > > you don't have to say > > Media=termId{Stream=1{Local... > > > > ABNF clearly allows this. We have an MGC implementation that > > did this, > > and an MG that got confused. > > > > Brian > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 21:02:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12632 for ; Wed, 30 Aug 2000 21:02:04 -0400 (EDT) Received: from standards (47.234.32.16:3707) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E3E4@standards.nortelnetworks.com>; Wed, 30 Aug 2000 20:48:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7150 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 20:48:50 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E3BE@standards.nortelnetworks.com>; Wed, 30 Aug 2000 20:38:50 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7V0pUw12340; Thu, 31 Aug 2000 02:51:30 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id CAA23044; Thu, 31 Aug 2000 02:51:29 +0200 (MET DST) Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id CAA07959; Thu, 31 Aug 2000 02:51:26 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480CCA@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39ADA763.3E5C1A0@ericsson.com> Date: Thu, 31 Aug 2000 11:31:31 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: DTMF Events X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Tom and Brian, Do you have some proposed text for the Implementor's Guide? Cheers, Christian Tom-PT Taylor wrote: > > That wasn't really clear. I meant to add that if the digit map is active > but it hasn't completed, individual digits are absorbed and not reported. > > > -----Original Message----- > > From: Taylor, Tom-PT [NORSE:B901:EXCH] > > Sent: Wednesday, August 30, 2000 1:05 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: DTMF Events > > > > > > To be clear on this, EITHER you get a digit map completion > > event (if a digit > > map was active and it completed) OR you get the individual digit event > > (otherwise). > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > > Sent: Wednesday, August 30, 2000 12:55 PM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: DTMF Events > > > > > > > > > The wording in Section E.6.2, DTMF detect is ambiguous and has > > > led to an incompatibility. The intention of the section on DTMF > > > digits was that a set of events was defined, d0-d9, da-df,... > > > Each of these events can be used in an event descriptor. The > > > events have no parameters. When detected, these events trigger > > > a notify. So if d0 is mentioned in an event descriptor, > > > and no digitMap is mentioned, and DTMF0 is detected, the event > > > d0 is notified, with no parameters. > > > > > > One implementer assumed that when you set the d0... event, > > > you still got the digitmap completion event notify, with a one digit > > > string. This is not the intention. > > > > > > > > > Brian > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 21:02:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12643 for ; Wed, 30 Aug 2000 21:02:05 -0400 (EDT) Received: from standards (47.234.32.16:3707) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E3E9@standards.nortelnetworks.com>; Wed, 30 Aug 2000 20:48:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7151 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 20:48:55 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E3BF@standards.nortelnetworks.com>; Wed, 30 Aug 2000 20:38:53 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7V0pZw12344; Thu, 31 Aug 2000 02:51:35 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id CAA23048; Thu, 31 Aug 2000 02:51:34 +0200 (MET DST) Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id CAA07963; Thu, 31 Aug 2000 02:51:31 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF6787D3@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39ADA8B1.E09FF1B4@ericsson.com> Date: Thu, 31 Aug 2000 11:37:05 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Statistics when you delete a stream X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Brian, Your interpretation seems correct to me and consistent with what's in the protocol today. Cheers, Christian "Rosen, Brian" wrote: > > The way the protocol is defined now, if you were to create a stream > on a termination, run some media, delete the stream, and then > re-establish the stream (maybe to another IP address), you would > not get statistics automatically on the delete of the stream. > As defined now, statistics are only generated automatically when > a Subtract is done on the termination. > > Do list members think that this behavior is correct? Or should > statistics be generated if a stream is deleted? > > I personally think the current spec is correct, because the > statistics are kept on the TERMINATION and not the STREAM. > You can always get the statistics by specifying Audit of > Statistics on the deletion of the stream. > > Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 31 08:22:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04744 for ; Thu, 31 Aug 2000 08:22:00 -0400 (EDT) Received: from standards (47.234.32.16:4488) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E626@standards.nortelnetworks.com>; Thu, 31 Aug 2000 8:08:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7950 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 31 Aug 2000 08:08:42 -0400 Received: from mars.hss.co.in (202.54.26.197:58449) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E625@standards.nortelnetworks.com>; Thu, 31 Aug 2000 8:08:35 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e7VCLmh12867 for ; Thu, 31 Aug 2000 17:52:00 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525694C.0042EBD3 ; Thu, 31 Aug 2000 17:40:57 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525694C.0042E8DA.00@sandesh.hss.hns.com> Date: Thu, 31 Aug 2000 17:43:33 +0530 Reply-To: klaha@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Kushanava Laha Subject: Re: Statistics when you delete a stream To: MEGACO@STANDARDS.NORTELNETWORKS.COM G'day Brian, Christian I second Christian's opinion. However Brian's last sentence deserves some more clarification. >>"You can always get the statistics by specifying Audit of >> Statistics on the deletion of the stream." I assume the intention was that "by specifying Audit of statistics you shall get the cumulative statistics for all streams on the termination, irrespective of whether they had been deleted recently or in the past along with those that are still alive". regards, Kushanava Laha ---------------------- Forwarded by Kushanava Laha/HSS on 08/31/2000 05:39 PM --------------------------- Christian Groves on 08/31/2000 06:07:05 AM Please respond to Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Kushanava Laha/HSS) Subject: Re: Statistics when you delete a stream G'Day Brian, Your interpretation seems correct to me and consistent with what's in the protocol today. Cheers, Christian "Rosen, Brian" wrote: > > The way the protocol is defined now, if you were to create a stream > on a termination, run some media, delete the stream, and then > re-establish the stream (maybe to another IP address), you would > not get statistics automatically on the delete of the stream. > As defined now, statistics are only generated automatically when > a Subtract is done on the termination. > > Do list members think that this behavior is correct? Or should > statistics be generated if a stream is deleted? > > I personally think the current spec is correct, because the > statistics are kept on the TERMINATION and not the STREAM. > You can always get the statistics by specifying Audit of > Statistics on the deletion of the stream. > > Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 31 08:54:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05237 for ; Thu, 31 Aug 2000 08:54:18 -0400 (EDT) Received: from standards (47.234.32.16:3027) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E657@standards.nortelnetworks.com>; Thu, 31 Aug 2000 8:41:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8011 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 31 Aug 2000 08:41:06 -0400 Received: from smtp2.cluster.oleane.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E655@standards.nortelnetworks.com>; Thu, 31 Aug 2000 8:41:04 -0400 Received: from oleane (dyn-1-1-093.Vin.dialup.oleane.fr [195.25.4.93]) by smtp2.cluster.oleane.net with SMTP id OAA41950; Thu, 31 Aug 2000 14:56:18 +0200 (CEST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C0135B.31862340" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <000e01c0134a$6f8ea1a0$0401a8c0@oleane.com> Date: Thu, 31 Aug 2000 14:53:15 +0200 Reply-To: Peter Lewis Sender: "Media Gateway Control (megaco)" From: Peter Lewis Subject: VoDSL Europe 2001 X-To: info To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C0135B.31862340 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable VoDSL Europe 2001 The Call for Papers dead line has been extended to September 15th Please get more details at: http://www.upperside.fr/bavodsl2001.htm ------=_NextPart_000_000B_01C0135B.31862340 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
VoDSL Europe 2001
The Call for Papers dead line has = been extended=20 to September 15th
Please get more details = at:
http://www.upperside.fr/= bavodsl2001.htm
 
------=_NextPart_000_000B_01C0135B.31862340-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 31 15:22:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12017 for ; Thu, 31 Aug 2000 15:22:46 -0400 (EDT) Received: from standards (47.234.32.16:2636) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E9D4@standards.nortelnetworks.com>; Thu, 31 Aug 2000 15:09:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9173 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 31 Aug 2000 15:09:24 -0400 Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E9D3@standards.nortelnetworks.com>; Thu, 31 Aug 2000 15:09:23 -0400 Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 31 Aug 2000 12:38:41 -0700 Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id MAA02169 for ; Thu, 31 Aug 2000 12:21:47 -0700 (PDT) Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 12:14:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8BBD33A986C5D311804000902719FF5D9FB420@aega.trillium.com> Date: Thu, 31 Aug 2000 12:14:18 -0700 Reply-To: Bharat Kaul Sender: "Media Gateway Control (megaco)" From: Bharat Kaul Subject: Retransmission Algorithm To: MEGACO@STANDARDS.NORTELNETWORKS.COM I didn't see any comments on following posting. So am resending the posting. Comments please :) - Bharat -----Original Message----- From: Bharat Kaul [mailto:bharat@trillium.com] Sent: Tuesday, August 29, 2000 4:17 PM I have a question regarding usage of multiple IP addresses. Does MEGACO follow same retransmission algorithm as RFC 2705 with max1 and max2 as thresholds and contacting DNS in between as required ? The Megaco document doesn't seem to say that except a casual mention in D.1.5 section. If the retransmission algorithm doesn't have max1 and max2 thresholds, are multiple IP addresses of any significance for communication between a MG and an MGC with no clear way defined for switching between IP Addresses ? On a similar note, are we required to maintain TTL for IP addresses and contact DNS in MEGACO too ? Thanks - Bharat From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 31 15:48:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12309 for ; Thu, 31 Aug 2000 15:48:29 -0400 (EDT) Received: from standards (47.234.32.16:2636) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EA01@standards.nortelnetworks.com>; Thu, 31 Aug 2000 15:35:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9231 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 31 Aug 2000 15:35:07 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EA00@standards.nortelnetworks.com>; Thu, 31 Aug 2000 15:35:06 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA02295; Thu, 31 Aug 2000 15:47:49 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 PAA24331; Thu, 31 Aug 2000 15:47:51 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 15:47:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6787D8@whq-msgusr-02.fore.com> Date: Thu, 31 Aug 2000 15:47:48 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Statistics when you delete a stream X-To: Kushanava Laha To: MEGACO@STANDARDS.NORTELNETWORKS.COM Yep, that's what I meant. Brian -----Original Message----- From: Kushanava Laha To: MEGACO@STANDARDS.NORTELNETWORKS.COM Sent: 8/31/00 8:13 AM Subject: Re: Statistics when you delete a stream G'day Brian, Christian I second Christian's opinion. However Brian's last sentence deserves some more clarification. >>"You can always get the statistics by specifying Audit of >> Statistics on the deletion of the stream." I assume the intention was that "by specifying Audit of statistics you shall get the cumulative statistics for all streams on the termination, irrespective of whether they had been deleted recently or in the past along with those that are still alive". regards, Kushanava Laha ---------------------- Forwarded by Kushanava Laha/HSS on 08/31/2000 05:39 PM --------------------------- Christian Groves on 08/31/2000 06:07:05 AM Please respond to Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Kushanava Laha/HSS) Subject: Re: Statistics when you delete a stream G'Day Brian, Your interpretation seems correct to me and consistent with what's in the protocol today. Cheers, Christian "Rosen, Brian" wrote: > > The way the protocol is defined now, if you were to create a stream > on a termination, run some media, delete the stream, and then > re-establish the stream (maybe to another IP address), you would > not get statistics automatically on the delete of the stream. > As defined now, statistics are only generated automatically when > a Subtract is done on the termination. > > Do list members think that this behavior is correct? Or should > statistics be generated if a stream is deleted? > > I personally think the current spec is correct, because the > statistics are kept on the TERMINATION and not the STREAM. > You can always get the statistics by specifying Audit of > Statistics on the deletion of the stream. > > Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 31 16:51:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12887 for ; Thu, 31 Aug 2000 16:51:41 -0400 (EDT) Received: from standards (47.234.32.16:1648) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EAB3@standards.nortelnetworks.com>; Thu, 31 Aug 2000 16:38:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9434 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 31 Aug 2000 16:38:13 -0400 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EAB2@standards.nortelnetworks.com>; Thu, 31 Aug 2000 16:38:13 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA05481; Thu, 31 Aug 2000 13:50:57 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA24724; Thu, 31 Aug 2000 13:50:56 -0700 (MST)] Received: from agevole.cig.mot.com (agevole [136.182.3.251]) by relay1.cig.mot.com (8.8.8+Sun/SCERG-RELAY-1.11b) with ESMTP id PAA28284; Thu, 31 Aug 2000 15:50:40 -0500 (CDT) Received: from cig.mot.com (d42-5077.cig.mot.com [160.15.80.119]) by agevole.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with ESMTP id PAA06375; Thu, 31 Aug 2000 15:50:39 -0500 (CDT) X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <8BBD33A986C5D311804000902719FF5D9FB420@aega.trillium.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200008312050.PAA06375@agevole.cig.mot.com> Date: Thu, 31 Aug 2000 15:51:03 -0500 Reply-To: Qiaobing Xie Sender: "Media Gateway Control (megaco)" From: Qiaobing Xie Subject: Re: Retransmission Algorithm X-To: Bharat Kaul To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit If you use SCTP as the transport (Megaco/Annex H), all the issues you described here will be covered by SCTP... -Qiaobing Bharat Kaul wrote: > > I didn't see any comments on following posting. So am resending the posting. > > Comments please :) > > - Bharat > > -----Original Message----- > From: Bharat Kaul [mailto:bharat@trillium.com] > Sent: Tuesday, August 29, 2000 4:17 PM > > I have a question regarding usage of multiple IP addresses. Does MEGACO > follow > same retransmission algorithm as RFC 2705 with max1 and max2 as thresholds > and contacting DNS in between as required ? The Megaco document doesn't seem > to say that except a casual mention in D.1.5 section. > > If the retransmission algorithm doesn't have max1 and max2 thresholds, are > multiple IP addresses of any significance for communication between a MG and > an MGC with no clear way defined for switching between IP Addresses ? > > On a similar note, are we required to maintain TTL for IP addresses and > contact DNS in MEGACO too ? > > Thanks > - Bharat From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 31 17:20:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13153 for ; Thu, 31 Aug 2000 17:20:16 -0400 (EDT) Received: from standards (47.234.32.16:1648) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EB21@standards.nortelnetworks.com>; Thu, 31 Aug 2000 17:07:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9565 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 31 Aug 2000 17:07:04 -0400 Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EB20@standards.nortelnetworks.com>; Thu, 31 Aug 2000 17:07:04 -0400 Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 31 Aug 2000 14:36:29 -0700 Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id OAA04543; Thu, 31 Aug 2000 14:19:35 -0700 (PDT) Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 14:12:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8BBD33A986C5D311804000902719FF5D9FB423@aega.trillium.com> Date: Thu, 31 Aug 2000 14:12:02 -0700 Reply-To: Bharat Kaul Sender: "Media Gateway Control (megaco)" From: Bharat Kaul Subject: Re: Retransmission Algorithm X-To: Qiaobing Xie To: MEGACO@STANDARDS.NORTELNETWORKS.COM I was wondering from the point of view of UDP. TCP has lot of complicatios with this algorithm (like establishing new connections etc.).To me it seems that the retransmission algorithm is not same as what used to be RFC2705 and we have to stick to one IP Address. - Bharat -----Original Message----- From: Qiaobing Xie [mailto:xieqb@CIG.MOT.COM] Sent: Thursday, August 31, 2000 1:51 PM To: MEGACO@standards.nortelnetworks.com Subject: Re: Retransmission Algorithm If you use SCTP as the transport (Megaco/Annex H), all the issues you described here will be covered by SCTP... -Qiaobing Bharat Kaul wrote: > > I didn't see any comments on following posting. So am resending the posting. > > Comments please :) > > - Bharat > > -----Original Message----- > From: Bharat Kaul [mailto:bharat@trillium.com] > Sent: Tuesday, August 29, 2000 4:17 PM > > I have a question regarding usage of multiple IP addresses. Does MEGACO > follow > same retransmission algorithm as RFC 2705 with max1 and max2 as thresholds > and contacting DNS in between as required ? The Megaco document doesn't seem > to say that except a casual mention in D.1.5 section. > > If the retransmission algorithm doesn't have max1 and max2 thresholds, are > multiple IP addresses of any significance for communication between a MG and > an MGC with no clear way defined for switching between IP Addresses ? > > On a similar note, are we required to maintain TTL for IP addresses and > contact DNS in MEGACO too ? > > Thanks > - Bharat From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 31 17:46:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13366 for ; Thu, 31 Aug 2000 17:46:35 -0400 (EDT) Received: from standards (47.234.32.16:3638) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EB47@standards.nortelnetworks.com>; Thu, 31 Aug 2000 17:33:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9611 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 31 Aug 2000 17:33:26 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EB46@standards.nortelnetworks.com>; Thu, 31 Aug 2000 17:33:25 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id OAA06121; Thu, 31 Aug 2000 14:46:10 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <8BBD33A986C5D311804000902719FF5D9FB420@aega.trillium.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39AED327.87B26F68@cisco.com> Date: Thu, 31 Aug 2000 17:50:31 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: Retransmission Algorithm X-To: Bharat Kaul To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Although domain names are allowed, use of multiple IP addresses for clustered systems is unspecified in Megaco. That doesn't mean you can't go ahead and use the 2705 mechanism, however you can't depend on it being supported either. -- Flemming Bharat Kaul wrote: > I didn't see any comments on following posting. So am resending the posting. > > Comments please :) > > - Bharat > > -----Original Message----- > From: Bharat Kaul [mailto:bharat@trillium.com] > Sent: Tuesday, August 29, 2000 4:17 PM > > I have a question regarding usage of multiple IP addresses. Does MEGACO > follow > same retransmission algorithm as RFC 2705 with max1 and max2 as thresholds > and contacting DNS in between as required ? The Megaco document doesn't seem > to say that except a casual mention in D.1.5 section. > > If the retransmission algorithm doesn't have max1 and max2 thresholds, are > multiple IP addresses of any significance for communication between a MG and > an MGC with no clear way defined for switching between IP Addresses ? > > On a similar note, are we required to maintain TTL for IP addresses and > contact DNS in MEGACO too ? > > Thanks > - Bharat -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Aug 31 23:32:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20111 for ; Thu, 31 Aug 2000 23:32:38 -0400 (EDT) Received: from standards (47.234.32.16:2390) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8ED42@standards.nortelnetworks.com>; Thu, 31 Aug 2000 23:19:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10290 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 31 Aug 2000 23:19:27 -0400 Received: from qhars002.nortel.com (47.101.112.102:56904) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8ED3E@standards.nortelnetworks.com>; Thu, 31 Aug 2000 23:19:26 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Wed, 30 Aug 2000 15:58:14 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Wed, 30 Aug 2000 09:59:53 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 30 Aug 2000 09:57:55 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480CC1@zcard00g.ca.nortel.com> Date: Wed, 30 Aug 2000 09:57:45 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Draft Meeting Minutes => Changes to the protocol, X-To: Thomas LEVY To: MEGACO@STANDARDS.NORTELNETWORKS.COM The charter may or may not be extended -- I have no indication on that score. The Megaco MIB is our last deliverable under the old charter, plus one or two items in progress (the NAS packages, the IPPhone profile). In any event, the Megaco list will continue to be available for discussion, and it will be possible to submit non-WG-initiated drafts for IESG approval. > -----Original Message----- > From: Thomas LEVY [mailto:thomas.levy@MS.ALCATEL.FR] > Sent: Wednesday, August 30, 2000 10:43 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Draft Meeting Minutes => Changes to the protocol, > > > Tom-PT Taylor wrote : > > > Here are the draft minutes for our meeting last week. > Please indicate any > > errors or omissions. > > > > .... > > > > The Chair noted that list discussion included some > proposals for changes to > > the protocol. Since Megaco/H.248 has now been fully > approved, no changes > > are possible to this version of the protocol. > > > > Tom, > > I have the meaning that after Megaco/H.248 has been fully > approved, the Megaco > IETF WG will be closed (refer Goals and Milestones). > So, how changes to the protocol could be discussed inside > IETF after this step? > > Sincerely, > > Thomas LEVY, >