From mailman-admin@ietf.org Thu May 1 11:36:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17528 for ; Thu, 1 May 2003 11:36:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FgK827942 for ; Thu, 1 May 2003 11:42:20 -0400 Date: Thu, 01 May 2003 11:42:20 -0400 Message-ID: <20030501154220.17986.86203.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: megaco-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, megaco-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for megaco-archive@lists.ietf.org: List Password // URL ---- -------- megaco@ietf.org rFKd https://www1.ietf.org/mailman/options/megaco/megaco-archive%40lists.ietf.org From megaco-admin@ietf.org Thu May 1 17:22:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11725 for ; Thu, 1 May 2003 17:22:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41LRo811090; Thu, 1 May 2003 17:27:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41LMd810866 for ; Thu, 1 May 2003 17:22:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11392 for ; Thu, 1 May 2003 17:15:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BLRA-0006wB-00 for megaco@ietf.org; Thu, 01 May 2003 17:17:52 -0400 Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.RADVISION.com) by ietf-mx with esmtp (Exim 4.12) id 19BLR4-0006vi-00 for megaco@ietf.org; Thu, 01 May 2003 17:17:46 -0400 Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19) id <2JB423GF>; Thu, 1 May 2003 17:14:56 -0400 Message-ID: From: Steve Cipolli To: "'Flemming Andreasen'" , Adrian Soncodi Cc: Megaco Subject: RE: [Megaco] Support for redundant MG failover Date: Thu, 1 May 2003 17:14:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , My understanding of both MGCP and MEGACO is that neither has a mechanism to distinguish multihomed interfaces from redundant MGCs/MGs. In MGCP the list of IP addresses returned for a given domain name may be a set of (multihomed) interfaces, a set of redundant MGCs/MGs, or some combination of both. In MEGACO the provisioned list of MGCs in an MG has this exact same property. I do see the fact that MEGACO MGCs have no mechanism to contact MGs on multihomed interfaces as a significant deficiency. I agree that mapping a list IP addresses returned from a domain name to the set of interfaces supported by a MEGACO association would be benefical, but the problem of how to distinguish multihomed interfaces from redundant MGs/MGCs still remains unclear to me (for both MEGACO and MGCP). --Stephen > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Thursday, April 24, 2003 11:04 AM > To: Adrian Soncodi > Cc: Megaco > Subject: Re: [Megaco] Support for redundant MG failover > > > > > Adrian Soncodi wrote: > > > Hello, all, > > > > I was wondering what is your oppinion on the following: > > > > Another topic that is not addressed in the MEGACO spec is > the case of > > a multi-homed MG, i.e. an MG where: > > - the primary controller has 2 physical interfaces A1 and A2, > > potentially on 2 different subnets, working in load-sharing mode > > (rather than active-standby) > > - the secondary MG controller can then be either transparrent (it > > takes over A1 and A2 on switchover) or non-transparent (has 2 more > > physical addresses, B1 and B2). > > > > One may argue that multi-homing is not necessary, for > example because > > you can always assign a single "logical" IP address A that is > > reachable over both interfaces A1 and A2. Yes, but this schema > > requires some dynamic IP routing capability in the backbone (e.g. to > > figure out when A1 is down and packets for A should be > routed to A2), > > which has a number of disadvantages: > > - Depending on the routing protocol, the latency for dynamic updates > > of the addresses can be very large (180 seconds in case of RIP), > > unacceptable for telephony. > > - Depending on the network topology, interface failures may > not become > > visible in the backbone. For example, if there is a LAN > switch between > > the MG and the first router, then the router does not see when the > > interface A1 fails (unless the dynamic routing domain is extended to > > include the MG, which is not always the case). > > - Some service providers (especially the smaller ones) do not run a > > dynamic IP routing protocol in their (whole) backbone, or > they may not > > even have a real backbone, for example they may use leased lines, IP > > over ATM/FR PVCs with no sophisticated routing capabilities. > > > > On the other hand, making the physical addresses A1 and A2 visible > > allows for redundant signaling paths to the MG using only static IP > > routing in the network, which in certain situations is desirable. > > > > The MGC-MG redundancy schema gets even more complicated if you > > consider that the MGC can be multi-homed too. Effectively, > it can have > > the same A1, A2, B1, B2 schema as the MG. In this case, > what is really > > useful is an SCTP association (MGC-A1, MGC-A2, MG-A1, > MG-A2), because > > this takes care of all the combinations. But if the MG supports only > > UDP, it is not clear from the standard how to emulate this SCTP > > behavior. For example: > > - Some MGs do a DNS query for the MGC name, get 2 IP addresses in > > response, but they just ignore the second IP address, thus ignoring > > that the MGC is multi-homed. > > - Other MGs consider the IP addresses as being 2 different MGCs, > > rather than one multi-homed MG. The problem is that they > only talk to > > one MGC at a time, and then they need a "handover" to > switch. So while > > talking on A1-A1, the MGC cannot for example audit on A2-A2, because > > this is immediately considered a failover (causing for example the > > pending notifications to be lost). The MGCP spec, for example, > > explicitly states that an MG should not change its > controlling entity > > when being audited from another IP address (and it doesn't > say whether > > this is a different MGC or the same multi-homed MGC). > > > > I think what needs to be clarified here is: > > - Whether an MG/MGC can be multi-homed and how to handle > its multiple > > IP addresses. > > - Whether an MG/MGC with active-standby controllers, transparent or > > non-transparent switchover, are considered one MG/MGC or 2 MG/MGCs > > - Whether a domain name for an MG/MGC which yields more than one IP > > address through DNS, is associated with one controller, or with an > > active-standby pair, or possibly even with more > active-standby pairs. > > > > I agree - these are rather big holes in the current specs IMO. > > > > > > The case with non-transparent MG controller switchover, as Flemming > > mentioned, poses additional problems. For example, if the active MG > > controller loses connectivity over A1 and A2, it may not > even notice, > > because not all MGs do heartbeats. So if the MGC determines it can > > actually talk to B1 and B2, it cannot force an MG controller > > switchover, or at least the standard does not define the > procedure for > > this. I would note that, in practice, however, most of the MGs and > > MGCs have transparent switchover (there is no B1, B2, they reuse A1, > > A2 ...). > > > > The MGCP spec is a little more explicit on how the IP addresses are > > handled. So I don't understand why this topic is outside > the scope of > > MEGACO. > > > > Right. I have always thought it was unfortunate, that Megaco did not > specify anything about use of multiple IP addresses and/or interfaces > (apart from the static provisioning of backup MGCs) as this limits the > robustness of the protocol when using UDP/TCP. I was hoping > that Annex F > would rectifiy some of that, but it doesn't seem like it. > > > > > I raised these issues because, from my experience, every > single vendor > > interprets them differently, and MGC-MG redundancy is a delicate > > subject. Any suggestions? > > 1. Continued discussion on the mailing list (preferably with > more input > from some of the traditional Megaco gurus). > 2. Write a contribution for SG16 addressing this. > 3. Forget about TCP and UDP and just use SCTP. > > -- Flemming > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu May 1 17:23:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11820 for ; Thu, 1 May 2003 17:23:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41LTdb11228 for megaco-archive@odin.ietf.org; Thu, 1 May 2003 17:29:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41LTd811225 for ; Thu, 1 May 2003 17:29:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11803 for ; Thu, 1 May 2003 17:22:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BLYA-0006zf-00 for megaco-web-archive@ietf.org; Thu, 01 May 2003 17:25:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BLYA-0006zb-00 for megaco-web-archive@ietf.org; Thu, 01 May 2003 17:25:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41LRo811090; Thu, 1 May 2003 17:27:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41LMd810866 for ; Thu, 1 May 2003 17:22:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11392 for ; Thu, 1 May 2003 17:15:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BLRA-0006wB-00 for megaco@ietf.org; Thu, 01 May 2003 17:17:52 -0400 Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.RADVISION.com) by ietf-mx with esmtp (Exim 4.12) id 19BLR4-0006vi-00 for megaco@ietf.org; Thu, 01 May 2003 17:17:46 -0400 Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19) id <2JB423GF>; Thu, 1 May 2003 17:14:56 -0400 Message-ID: From: Steve Cipolli To: "'Flemming Andreasen'" , Adrian Soncodi Cc: Megaco Subject: RE: [Megaco] Support for redundant MG failover Date: Thu, 1 May 2003 17:14:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , My understanding of both MGCP and MEGACO is that neither has a mechanism to distinguish multihomed interfaces from redundant MGCs/MGs. In MGCP the list of IP addresses returned for a given domain name may be a set of (multihomed) interfaces, a set of redundant MGCs/MGs, or some combination of both. In MEGACO the provisioned list of MGCs in an MG has this exact same property. I do see the fact that MEGACO MGCs have no mechanism to contact MGs on multihomed interfaces as a significant deficiency. I agree that mapping a list IP addresses returned from a domain name to the set of interfaces supported by a MEGACO association would be benefical, but the problem of how to distinguish multihomed interfaces from redundant MGs/MGCs still remains unclear to me (for both MEGACO and MGCP). --Stephen > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Thursday, April 24, 2003 11:04 AM > To: Adrian Soncodi > Cc: Megaco > Subject: Re: [Megaco] Support for redundant MG failover > > > > > Adrian Soncodi wrote: > > > Hello, all, > > > > I was wondering what is your oppinion on the following: > > > > Another topic that is not addressed in the MEGACO spec is > the case of > > a multi-homed MG, i.e. an MG where: > > - the primary controller has 2 physical interfaces A1 and A2, > > potentially on 2 different subnets, working in load-sharing mode > > (rather than active-standby) > > - the secondary MG controller can then be either transparrent (it > > takes over A1 and A2 on switchover) or non-transparent (has 2 more > > physical addresses, B1 and B2). > > > > One may argue that multi-homing is not necessary, for > example because > > you can always assign a single "logical" IP address A that is > > reachable over both interfaces A1 and A2. Yes, but this schema > > requires some dynamic IP routing capability in the backbone (e.g. to > > figure out when A1 is down and packets for A should be > routed to A2), > > which has a number of disadvantages: > > - Depending on the routing protocol, the latency for dynamic updates > > of the addresses can be very large (180 seconds in case of RIP), > > unacceptable for telephony. > > - Depending on the network topology, interface failures may > not become > > visible in the backbone. For example, if there is a LAN > switch between > > the MG and the first router, then the router does not see when the > > interface A1 fails (unless the dynamic routing domain is extended to > > include the MG, which is not always the case). > > - Some service providers (especially the smaller ones) do not run a > > dynamic IP routing protocol in their (whole) backbone, or > they may not > > even have a real backbone, for example they may use leased lines, IP > > over ATM/FR PVCs with no sophisticated routing capabilities. > > > > On the other hand, making the physical addresses A1 and A2 visible > > allows for redundant signaling paths to the MG using only static IP > > routing in the network, which in certain situations is desirable. > > > > The MGC-MG redundancy schema gets even more complicated if you > > consider that the MGC can be multi-homed too. Effectively, > it can have > > the same A1, A2, B1, B2 schema as the MG. In this case, > what is really > > useful is an SCTP association (MGC-A1, MGC-A2, MG-A1, > MG-A2), because > > this takes care of all the combinations. But if the MG supports only > > UDP, it is not clear from the standard how to emulate this SCTP > > behavior. For example: > > - Some MGs do a DNS query for the MGC name, get 2 IP addresses in > > response, but they just ignore the second IP address, thus ignoring > > that the MGC is multi-homed. > > - Other MGs consider the IP addresses as being 2 different MGCs, > > rather than one multi-homed MG. The problem is that they > only talk to > > one MGC at a time, and then they need a "handover" to > switch. So while > > talking on A1-A1, the MGC cannot for example audit on A2-A2, because > > this is immediately considered a failover (causing for example the > > pending notifications to be lost). The MGCP spec, for example, > > explicitly states that an MG should not change its > controlling entity > > when being audited from another IP address (and it doesn't > say whether > > this is a different MGC or the same multi-homed MGC). > > > > I think what needs to be clarified here is: > > - Whether an MG/MGC can be multi-homed and how to handle > its multiple > > IP addresses. > > - Whether an MG/MGC with active-standby controllers, transparent or > > non-transparent switchover, are considered one MG/MGC or 2 MG/MGCs > > - Whether a domain name for an MG/MGC which yields more than one IP > > address through DNS, is associated with one controller, or with an > > active-standby pair, or possibly even with more > active-standby pairs. > > > > I agree - these are rather big holes in the current specs IMO. > > > > > > The case with non-transparent MG controller switchover, as Flemming > > mentioned, poses additional problems. For example, if the active MG > > controller loses connectivity over A1 and A2, it may not > even notice, > > because not all MGs do heartbeats. So if the MGC determines it can > > actually talk to B1 and B2, it cannot force an MG controller > > switchover, or at least the standard does not define the > procedure for > > this. I would note that, in practice, however, most of the MGs and > > MGCs have transparent switchover (there is no B1, B2, they reuse A1, > > A2 ...). > > > > The MGCP spec is a little more explicit on how the IP addresses are > > handled. So I don't understand why this topic is outside > the scope of > > MEGACO. > > > > Right. I have always thought it was unfortunate, that Megaco did not > specify anything about use of multiple IP addresses and/or interfaces > (apart from the static provisioning of backup MGCs) as this limits the > robustness of the protocol when using UDP/TCP. I was hoping > that Annex F > would rectifiy some of that, but it doesn't seem like it. > > > > > I raised these issues because, from my experience, every > single vendor > > interprets them differently, and MGC-MG redundancy is a delicate > > subject. Any suggestions? > > 1. Continued discussion on the mailing list (preferably with > more input > from some of the traditional Megaco gurus). > 2. Write a contribution for SG16 addressing this. > 3. Forget about TCP and UDP and just use SCTP. > > -- Flemming > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu May 1 18:08:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14900 for ; Thu, 1 May 2003 18:08:30 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41MEM814819; Thu, 1 May 2003 18:14:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41MDH814785 for ; Thu, 1 May 2003 18:13:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14648 for ; Thu, 1 May 2003 18:06:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BMEN-0007WM-00 for megaco@ietf.org; Thu, 01 May 2003 18:08:43 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19BMEI-0007Vn-00 for megaco@ietf.org; Thu, 01 May 2003 18:08:38 -0400 Received: from cisco.com (sjc-vpn1-277.cisco.com [10.21.97.21]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h41M8axI000421; Thu, 1 May 2003 15:08:37 -0700 (PDT) Message-ID: <3EB19AE3.72822AAC@cisco.com> Date: Thu, 01 May 2003 18:08:35 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Cipolli CC: Adrian Soncodi , Megaco Subject: Re: [Megaco] Support for redundant MG failover References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Steve Cipolli wrote: > My understanding of both MGCP and MEGACO is that neither has a mechanism to > distinguish multihomed interfaces from redundant MGCs/MGs. In MGCP the list > of IP addresses returned for a given domain name may be a set of > (multihomed) interfaces, a set of redundant MGCs/MGs, or some combination of > both. In MEGACO the provisioned list of MGCs in an MG has this exact same > property. I'm not sure the capabilities of MGCP are relevant to this discussion, but since you asked: - The set of IP addresses associated with a domain name, and for which retransmission and failover procedures are defined in MGCP, are assumed to belong to the same logical MGC. The MGC may be one or more machines each with one or more interfaces. - In order to failover to a backup MGC, "vanilla" MGCP would have the backup MGC contact the MG. - Alternatively, the NotifiedEntityList parameter defined in the MGCP Redirect and Reset package (draft-foster-mgcp-redirect-02.txt) allows you to provide a set of domain names the MG can contact (as opposed to just one in the NotifiedEntity parameter). The multiple domain names can either represent the same and/or multiple different MGCs. The key with this extension is that the domain names are contacted in an ordered fashion. > I do see the fact that MEGACO MGCs have no mechanism to contact MGs on > multihomed interfaces as a significant deficiency. I agree that mapping a > list IP addresses returned from a domain name to the set of interfaces > supported by a MEGACO association would be benefical, but the problem of how > to distinguish multihomed interfaces from redundant MGs/MGCs still remains > unclear to me (for both MEGACO and MGCP). See above for MGCP. For Megaco, I agree and would propose that something along the lines of what has been defined for MGCP could be used. -- Flemming _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu May 1 18:09:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15022 for ; Thu, 1 May 2003 18:09:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41MFss14894 for megaco-archive@odin.ietf.org; Thu, 1 May 2003 18:15:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41MFs814891 for ; Thu, 1 May 2003 18:15:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14967 for ; Thu, 1 May 2003 18:09:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BMGv-0007Y6-00 for megaco-web-archive@ietf.org; Thu, 01 May 2003 18:11:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BMGu-0007Y3-00 for megaco-web-archive@ietf.org; Thu, 01 May 2003 18:11:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41MEM814819; Thu, 1 May 2003 18:14:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41MDH814785 for ; Thu, 1 May 2003 18:13:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14648 for ; Thu, 1 May 2003 18:06:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BMEN-0007WM-00 for megaco@ietf.org; Thu, 01 May 2003 18:08:43 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19BMEI-0007Vn-00 for megaco@ietf.org; Thu, 01 May 2003 18:08:38 -0400 Received: from cisco.com (sjc-vpn1-277.cisco.com [10.21.97.21]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h41M8axI000421; Thu, 1 May 2003 15:08:37 -0700 (PDT) Message-ID: <3EB19AE3.72822AAC@cisco.com> Date: Thu, 01 May 2003 18:08:35 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Cipolli CC: Adrian Soncodi , Megaco Subject: Re: [Megaco] Support for redundant MG failover References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Steve Cipolli wrote: > My understanding of both MGCP and MEGACO is that neither has a mechanism to > distinguish multihomed interfaces from redundant MGCs/MGs. In MGCP the list > of IP addresses returned for a given domain name may be a set of > (multihomed) interfaces, a set of redundant MGCs/MGs, or some combination of > both. In MEGACO the provisioned list of MGCs in an MG has this exact same > property. I'm not sure the capabilities of MGCP are relevant to this discussion, but since you asked: - The set of IP addresses associated with a domain name, and for which retransmission and failover procedures are defined in MGCP, are assumed to belong to the same logical MGC. The MGC may be one or more machines each with one or more interfaces. - In order to failover to a backup MGC, "vanilla" MGCP would have the backup MGC contact the MG. - Alternatively, the NotifiedEntityList parameter defined in the MGCP Redirect and Reset package (draft-foster-mgcp-redirect-02.txt) allows you to provide a set of domain names the MG can contact (as opposed to just one in the NotifiedEntity parameter). The multiple domain names can either represent the same and/or multiple different MGCs. The key with this extension is that the domain names are contacted in an ordered fashion. > I do see the fact that MEGACO MGCs have no mechanism to contact MGs on > multihomed interfaces as a significant deficiency. I agree that mapping a > list IP addresses returned from a domain name to the set of interfaces > supported by a MEGACO association would be benefical, but the problem of how > to distinguish multihomed interfaces from redundant MGs/MGCs still remains > unclear to me (for both MEGACO and MGCP). See above for MGCP. For Megaco, I agree and would propose that something along the lines of what has been defined for MGCP could be used. -- Flemming _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri May 2 13:32:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22031 for ; Fri, 2 May 2003 13:32:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Hc1810021; Fri, 2 May 2003 13:38:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42HZ4809036 for ; Fri, 2 May 2003 13:35:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21776 for ; Fri, 2 May 2003 13:27:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BeLy-0005ut-00 for megaco@ietf.org; Fri, 02 May 2003 13:29:46 -0400 Received: from mail.utstar.com ([65.200.123.6]) by ietf-mx with esmtp (Exim 4.12) id 19BeLd-0005uf-00 for megaco@ietf.org; Fri, 02 May 2003 13:29:25 -0400 Received: from balanew ([172.16.40.43]) by mail.utstar.com (8.11.3/8.11.3) with ESMTP id h42HTfm01497 for ; Fri, 2 May 2003 13:29:41 -0400 (EDT) Reply-To: From: "Balasubramanian Pitchandi" To: Subject: RE: [Megaco] I-D ACTION:draft-ietf-megaco-mib-05.txt Date: Fri, 2 May 2003 13:29:35 -0400 Organization: UTStarcom Inc Message-ID: <002c01c310d0$6679b4c0$2b2810ac@balanew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200304301029.GAA27574@ietf.org> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h42HZ4809037 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Folks, Thanks to all those who provided extensive comments on the Megaco MIB. The next revision of the draft is now available. The major differences to the older draft include: 1. Added medGwyGatewayControllerId as an additional index to the medGwyGatewayControllerTable. 2. Modified the usage of TimeTicks to TimeStamp which is now being widely used and is more useful. 3. Converted the Integer32's to Unsigned32 wherever appropriate. 4. Added few more Textual Conventions that could be imported to vendor specific MIBs. 5. Corrected few MIB syntax errors. 6. Reformatted the entire document to be compliant with the new IETF MIB guidelines from draft-ietf-ops-mib-review-guidelines-01.txt I have made sure that the MIB is backward compatible at most of the places so that the existing implementations are not affected that much. Please review the MIB and let me know if there are any comments/questions. Thanks, Bala -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, April 30, 2003 6:29 AM To: IETF-Announce: Cc: megaco@ietf.org Subject: [Megaco] I-D ACTION:draft-ietf-megaco-mib-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Media Gateway Control Working Group of the IETF. Title : Megaco MIB Author(s) : B. Pitchandi, I. Akramovich, C. Brown, M. Holdrege Filename : draft-ietf-megaco-mib-05.txt Pages : 35 Date : 2003-4-29 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for use by the MEGACO/H.248 protocol operating on Media Gateways and Media Gateway Controllers. These objects can be used to manage the network containing Media Gateways and Media Gateway Controllers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-mib-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-megaco-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-megaco-mib-05.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. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri May 2 13:34:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22125 for ; Fri, 2 May 2003 13:34:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h42HevN10243 for megaco-archive@odin.ietf.org; Fri, 2 May 2003 13:40:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Heu810240 for ; Fri, 2 May 2003 13:40:56 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22096 for ; Fri, 2 May 2003 13:33:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Hc1810021; Fri, 2 May 2003 13:38:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42HZ4809036 for ; Fri, 2 May 2003 13:35:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21776 for ; Fri, 2 May 2003 13:27:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BeLy-0005ut-00 for megaco@ietf.org; Fri, 02 May 2003 13:29:46 -0400 Received: from mail.utstar.com ([65.200.123.6]) by ietf-mx with esmtp (Exim 4.12) id 19BeLd-0005uf-00 for megaco@ietf.org; Fri, 02 May 2003 13:29:25 -0400 Received: from balanew ([172.16.40.43]) by mail.utstar.com (8.11.3/8.11.3) with ESMTP id h42HTfm01497 for ; Fri, 2 May 2003 13:29:41 -0400 (EDT) Reply-To: From: "Balasubramanian Pitchandi" To: Subject: RE: [Megaco] I-D ACTION:draft-ietf-megaco-mib-05.txt Date: Fri, 2 May 2003 13:29:35 -0400 Organization: UTStarcom Inc Message-ID: <002c01c310d0$6679b4c0$2b2810ac@balanew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200304301029.GAA27574@ietf.org> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h42HZ4809037 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Folks, Thanks to all those who provided extensive comments on the Megaco MIB. The next revision of the draft is now available. The major differences to the older draft include: 1. Added medGwyGatewayControllerId as an additional index to the medGwyGatewayControllerTable. 2. Modified the usage of TimeTicks to TimeStamp which is now being widely used and is more useful. 3. Converted the Integer32's to Unsigned32 wherever appropriate. 4. Added few more Textual Conventions that could be imported to vendor specific MIBs. 5. Corrected few MIB syntax errors. 6. Reformatted the entire document to be compliant with the new IETF MIB guidelines from draft-ietf-ops-mib-review-guidelines-01.txt I have made sure that the MIB is backward compatible at most of the places so that the existing implementations are not affected that much. Please review the MIB and let me know if there are any comments/questions. Thanks, Bala -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, April 30, 2003 6:29 AM To: IETF-Announce: Cc: megaco@ietf.org Subject: [Megaco] I-D ACTION:draft-ietf-megaco-mib-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Media Gateway Control Working Group of the IETF. Title : Megaco MIB Author(s) : B. Pitchandi, I. Akramovich, C. Brown, M. Holdrege Filename : draft-ietf-megaco-mib-05.txt Pages : 35 Date : 2003-4-29 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for use by the MEGACO/H.248 protocol operating on Media Gateways and Media Gateway Controllers. These objects can be used to manage the network containing Media Gateways and Media Gateway Controllers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-mib-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-megaco-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-megaco-mib-05.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. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon May 5 12:08:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06521 for ; Mon, 5 May 2003 12:08:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45GFQ813734; Mon, 5 May 2003 12:15:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45G9E813376 for ; Mon, 5 May 2003 12:09:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06331 for ; Mon, 5 May 2003 12:00:25 -0400 (EDT) From: svkumar@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CiQB-0006iY-00 for megaco@ietf.org; Mon, 05 May 2003 12:02:31 -0400 Received: from hindon.hss.co.in ([202.54.26.202]) by ietf-mx with esmtp (Exim 4.12) id 19CiQ5-0006g9-00 for megaco@ietf.org; Mon, 05 May 2003 12:02:25 -0400 Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h45Fu8b26887 for ; Mon, 5 May 2003 21:26:08 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h45Fu7926882 for ; Mon, 5 May 2003 21:26:07 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h45FxFQ28052 for ; Mon, 5 May 2003 21:29:15 +0530 (IST) To: megaco@ietf.org Date: Mon, 5 May 2003 21:24:17 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 05/05/2003 09:23:56 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Megaco] Conveying both Handoff and Disconnected Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi List I had a question regarding a Handoff scenario. Consider the following scenario : 1.An active association exists between MGC1 (primary MGC) and MG1 (primary MG) 2.Now there is some problem in MGC1 and so it sends a handoff request to the MG1 with MgcIDToTry set to that of the secondary MGC- MGC2 3. On receiving this request, MG1 sends a response and then generates a Service Change request to MGC2 with method as handoff. Now heres the problem... 4. Before MG1 receives the response from MGC2, it goes down abruptly, and MG2 (standby) comes up. My concern is that from MG2's perspective, there are two pieces of information which it needs to convey to MGC2: 1) MGC1 directed Handoff 2) The MG itself went down briefly (method : disconnected) Should it send both, or just one of them. I feel that just sending a Service Change with method 'Handoff' would suffice. MGC2 can audit and find the MG's termination status. Please confirm Regards Shiv Kumar Hughes Software Systems "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon May 5 12:09:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06613 for ; Mon, 5 May 2003 12:09:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45GHqD13967 for megaco-archive@odin.ietf.org; Mon, 5 May 2003 12:17:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45GHq813964 for ; Mon, 5 May 2003 12:17:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06562 for ; Mon, 5 May 2003 12:09:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CiYm-0006mT-00 for megaco-web-archive@ietf.org; Mon, 05 May 2003 12:11:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19CiYm-0006mJ-00 for megaco-web-archive@ietf.org; Mon, 05 May 2003 12:11:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45GFQ813734; Mon, 5 May 2003 12:15:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45G9E813376 for ; Mon, 5 May 2003 12:09:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06331 for ; Mon, 5 May 2003 12:00:25 -0400 (EDT) From: svkumar@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CiQB-0006iY-00 for megaco@ietf.org; Mon, 05 May 2003 12:02:31 -0400 Received: from hindon.hss.co.in ([202.54.26.202]) by ietf-mx with esmtp (Exim 4.12) id 19CiQ5-0006g9-00 for megaco@ietf.org; Mon, 05 May 2003 12:02:25 -0400 Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h45Fu8b26887 for ; Mon, 5 May 2003 21:26:08 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h45Fu7926882 for ; Mon, 5 May 2003 21:26:07 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h45FxFQ28052 for ; Mon, 5 May 2003 21:29:15 +0530 (IST) To: megaco@ietf.org Date: Mon, 5 May 2003 21:24:17 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 05/05/2003 09:23:56 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Megaco] Conveying both Handoff and Disconnected Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi List I had a question regarding a Handoff scenario. Consider the following scenario : 1.An active association exists between MGC1 (primary MGC) and MG1 (primary MG) 2.Now there is some problem in MGC1 and so it sends a handoff request to the MG1 with MgcIDToTry set to that of the secondary MGC- MGC2 3. On receiving this request, MG1 sends a response and then generates a Service Change request to MGC2 with method as handoff. Now heres the problem... 4. Before MG1 receives the response from MGC2, it goes down abruptly, and MG2 (standby) comes up. My concern is that from MG2's perspective, there are two pieces of information which it needs to convey to MGC2: 1) MGC1 directed Handoff 2) The MG itself went down briefly (method : disconnected) Should it send both, or just one of them. I feel that just sending a Service Change with method 'Handoff' would suffice. MGC2 can audit and find the MG's termination status. Please confirm Regards Shiv Kumar Hughes Software Systems "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon May 5 13:45:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09341 for ; Mon, 5 May 2003 13:45:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45Hqm821134; Mon, 5 May 2003 13:52:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45Hi0820386 for ; Mon, 5 May 2003 13:44:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08932 for ; Mon, 5 May 2003 13:35:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cjts-0007HE-00 for megaco@ietf.org; Mon, 05 May 2003 13:37:16 -0400 Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com) by ietf-mx with esmtp (Exim 4.12) id 19Cjtm-0007H5-00 for megaco@ietf.org; Mon, 05 May 2003 13:37:10 -0400 Received: from [172.16.1.210] (helo=CCPU00204) by smtp.ccpu.com with smtp (Exim 3.34 #1 (Debian)) id 19CjuF-0006w2-00 for ; Mon, 05 May 2003 10:37:39 -0700 From: "Rashim Anand" To: Date: Mon, 5 May 2003 10:36:41 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Megaco] Query on Status of packages Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Can someone update me on the status of the following packages - CAS packages (draft-manyfolks-megaco-caspackage-02) This draft was set to expire in Sep 2002. Has it been replaced by a newer version or a RFC? Line Test packages (H.248.17) Are the packages defined in this package still in a state of flux or has it been finally approved? 3GPP packages (3GPP TS 29.232 V4.4.0 (2002-03)) When is this document expected to be approved? Thanks, Rashim _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon May 5 13:46:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09369 for ; Mon, 5 May 2003 13:46:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45HsbI21261 for megaco-archive@odin.ietf.org; Mon, 5 May 2003 13:54:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45Hsb821258 for ; Mon, 5 May 2003 13:54:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09366 for ; Mon, 5 May 2003 13:46:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ck4N-0007LN-00 for megaco-web-archive@ietf.org; Mon, 05 May 2003 13:48:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ck4N-0007LK-00 for megaco-web-archive@ietf.org; Mon, 05 May 2003 13:48:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45Hqm821134; Mon, 5 May 2003 13:52:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45Hi0820386 for ; Mon, 5 May 2003 13:44:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08932 for ; Mon, 5 May 2003 13:35:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cjts-0007HE-00 for megaco@ietf.org; Mon, 05 May 2003 13:37:16 -0400 Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com) by ietf-mx with esmtp (Exim 4.12) id 19Cjtm-0007H5-00 for megaco@ietf.org; Mon, 05 May 2003 13:37:10 -0400 Received: from [172.16.1.210] (helo=CCPU00204) by smtp.ccpu.com with smtp (Exim 3.34 #1 (Debian)) id 19CjuF-0006w2-00 for ; Mon, 05 May 2003 10:37:39 -0700 From: "Rashim Anand" To: Date: Mon, 5 May 2003 10:36:41 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Megaco] Query on Status of packages Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Can someone update me on the status of the following packages - CAS packages (draft-manyfolks-megaco-caspackage-02) This draft was set to expire in Sep 2002. Has it been replaced by a newer version or a RFC? Line Test packages (H.248.17) Are the packages defined in this package still in a state of flux or has it been finally approved? 3GPP packages (3GPP TS 29.232 V4.4.0 (2002-03)) When is this document expected to be approved? Thanks, Rashim _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon May 5 20:45:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22862 for ; Mon, 5 May 2003 20:45:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h460rL818771; Mon, 5 May 2003 20:53:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h460nX818640 for ; Mon, 5 May 2003 20:49:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22784 for ; Mon, 5 May 2003 20:40:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CqXX-0002Dz-00 for megaco@ietf.org; Mon, 05 May 2003 20:42:40 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19CqXR-0002Dn-00 for megaco@ietf.org; Mon, 05 May 2003 20:42:33 -0400 Received: from brsf10.epa.ericsson.se ([61.88.9.226]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h460eP416029; Tue, 6 May 2003 10:40:25 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h460gl019291; Tue, 6 May 2003 10:42:47 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.180]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JB8N6WQV; Tue, 6 May 2003 10:42:46 +1000 Message-ID: <3EB70500.CEB5C2D8@ericsson.com.au> Date: Tue, 06 May 2003 10:42:40 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rashim Anand CC: megaco@ietf.org Subject: Re: [Megaco] Query on Status of packages References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Rashim, H.248.17 has been approved and can be found at the ITU website. The lastest version of 3GPP TS29.232 is now V5.2.0. Regards, Christian Rashim Anand wrote: > > Hi, > > Can someone update me on the status of the following packages - > > CAS packages (draft-manyfolks-megaco-caspackage-02) > This draft was set to expire in Sep 2002. Has it been replaced > by a newer version or a RFC? > > Line Test packages (H.248.17) > Are the packages defined in this package still in a state of flux > or has it been finally approved? > > 3GPP packages (3GPP TS 29.232 V4.4.0 (2002-03)) > When is this document expected to be approved? > > Thanks, > Rashim > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon May 5 20:46:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22901 for ; Mon, 5 May 2003 20:46:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h460t8l18855 for megaco-archive@odin.ietf.org; Mon, 5 May 2003 20:55:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h460t7818852 for ; Mon, 5 May 2003 20:55:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22880 for ; Mon, 5 May 2003 20:46:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CqdB-0002Fr-00 for megaco-web-archive@ietf.org; Mon, 05 May 2003 20:48:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19CqdA-0002Fn-00 for megaco-web-archive@ietf.org; Mon, 05 May 2003 20:48:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h460rL818771; Mon, 5 May 2003 20:53:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h460nX818640 for ; Mon, 5 May 2003 20:49:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22784 for ; Mon, 5 May 2003 20:40:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CqXX-0002Dz-00 for megaco@ietf.org; Mon, 05 May 2003 20:42:40 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19CqXR-0002Dn-00 for megaco@ietf.org; Mon, 05 May 2003 20:42:33 -0400 Received: from brsf10.epa.ericsson.se ([61.88.9.226]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h460eP416029; Tue, 6 May 2003 10:40:25 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h460gl019291; Tue, 6 May 2003 10:42:47 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.180]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JB8N6WQV; Tue, 6 May 2003 10:42:46 +1000 Message-ID: <3EB70500.CEB5C2D8@ericsson.com.au> Date: Tue, 06 May 2003 10:42:40 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rashim Anand CC: megaco@ietf.org Subject: Re: [Megaco] Query on Status of packages References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Rashim, H.248.17 has been approved and can be found at the ITU website. The lastest version of 3GPP TS29.232 is now V5.2.0. Regards, Christian Rashim Anand wrote: > > Hi, > > Can someone update me on the status of the following packages - > > CAS packages (draft-manyfolks-megaco-caspackage-02) > This draft was set to expire in Sep 2002. Has it been replaced > by a newer version or a RFC? > > Line Test packages (H.248.17) > Are the packages defined in this package still in a state of flux > or has it been finally approved? > > 3GPP packages (3GPP TS 29.232 V4.4.0 (2002-03)) > When is this document expected to be approved? > > Thanks, > Rashim > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue May 6 03:02:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10141 for ; Tue, 6 May 2003 03:02:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4679x821633; Tue, 6 May 2003 03:09:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4678q821541 for ; Tue, 6 May 2003 03:08:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10068 for ; Tue, 6 May 2003 02:59:44 -0400 (EDT) From: svkumar@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CwSU-0003pP-00 for megaco@ietf.org; Tue, 06 May 2003 03:01:50 -0400 Received: from hindon.hss.co.in ([202.54.26.202]) by ietf-mx with esmtp (Exim 4.12) id 19CwSO-0003ok-00 for megaco@ietf.org; Tue, 06 May 2003 03:01:44 -0400 Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h466whe22191 for ; Tue, 6 May 2003 12:28:43 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h466wg922179 for ; Tue, 6 May 2003 12:28:42 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h4671oG26196 for ; Tue, 6 May 2003 12:31:50 +0530 (IST) Subject: Re: [Megaco] Query on Status of packages To: megaco@ietf.org Date: Tue, 6 May 2003 12:26:52 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 06/05/2003 12:26:30 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi The latest 3GPP TS 29.232 version is 5.5.0. These is a Release 5 spec. You can get it from http://www.3gpp.org/ftp/specs/latest/Rel-5/29_series/ Christian, you have mentioned v5.2.0. Is this a typo or does the MEGACO WG separately approve the 3G Specs related to MEGACO ? Regards Shiv Christian Groves @ietf.org on 05/06/2003 06:12:40 AM Sent by: megaco-admin@ietf.org To: Rashim Anand cc: megaco@ietf.org Subject: Re: [Megaco] Query on Status of packages Hello Rashim, H.248.17 has been approved and can be found at the ITU website. The lastest version of 3GPP TS29.232 is now V5.2.0. Regards, Christian Rashim Anand wrote: > > Hi, > > Can someone update me on the status of the following packages - > > CAS packages (draft-manyfolks-megaco-caspackage-02) > This draft was set to expire in Sep 2002. Has it been replaced > by a newer version or a RFC? > > Line Test packages (H.248.17) > Are the packages defined in this package still in a state of flux > or has it been finally approved? > > 3GPP packages (3GPP TS 29.232 V4.4.0 (2002-03)) > When is this document expected to be approved? > > Thanks, > Rashim > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue May 6 03:03:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10182 for ; Tue, 6 May 2003 03:03:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h467CBi21769 for megaco-archive@odin.ietf.org; Tue, 6 May 2003 03:12:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h467CB821766 for ; Tue, 6 May 2003 03:12:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10169 for ; Tue, 6 May 2003 03:03:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CwVw-0003qe-00 for megaco-web-archive@ietf.org; Tue, 06 May 2003 03:05:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19CwVw-0003qb-00 for megaco-web-archive@ietf.org; Tue, 06 May 2003 03:05:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4679x821633; Tue, 6 May 2003 03:09:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4678q821541 for ; Tue, 6 May 2003 03:08:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10068 for ; Tue, 6 May 2003 02:59:44 -0400 (EDT) From: svkumar@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CwSU-0003pP-00 for megaco@ietf.org; Tue, 06 May 2003 03:01:50 -0400 Received: from hindon.hss.co.in ([202.54.26.202]) by ietf-mx with esmtp (Exim 4.12) id 19CwSO-0003ok-00 for megaco@ietf.org; Tue, 06 May 2003 03:01:44 -0400 Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h466whe22191 for ; Tue, 6 May 2003 12:28:43 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h466wg922179 for ; Tue, 6 May 2003 12:28:42 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h4671oG26196 for ; Tue, 6 May 2003 12:31:50 +0530 (IST) Subject: Re: [Megaco] Query on Status of packages To: megaco@ietf.org Date: Tue, 6 May 2003 12:26:52 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 06/05/2003 12:26:30 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi The latest 3GPP TS 29.232 version is 5.5.0. These is a Release 5 spec. You can get it from http://www.3gpp.org/ftp/specs/latest/Rel-5/29_series/ Christian, you have mentioned v5.2.0. Is this a typo or does the MEGACO WG separately approve the 3G Specs related to MEGACO ? Regards Shiv Christian Groves @ietf.org on 05/06/2003 06:12:40 AM Sent by: megaco-admin@ietf.org To: Rashim Anand cc: megaco@ietf.org Subject: Re: [Megaco] Query on Status of packages Hello Rashim, H.248.17 has been approved and can be found at the ITU website. The lastest version of 3GPP TS29.232 is now V5.2.0. Regards, Christian Rashim Anand wrote: > > Hi, > > Can someone update me on the status of the following packages - > > CAS packages (draft-manyfolks-megaco-caspackage-02) > This draft was set to expire in Sep 2002. Has it been replaced > by a newer version or a RFC? > > Line Test packages (H.248.17) > Are the packages defined in this package still in a state of flux > or has it been finally approved? > > 3GPP packages (3GPP TS 29.232 V4.4.0 (2002-03)) > When is this document expected to be approved? > > Thanks, > Rashim > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed May 7 02:41:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18201 for ; Wed, 7 May 2003 02:41:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h476mS816906; Wed, 7 May 2003 02:48:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h476jx816837 for ; Wed, 7 May 2003 02:45:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18161 for ; Wed, 7 May 2003 02:36:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DIZf-0005ps-00 for megaco@ietf.org; Wed, 07 May 2003 02:38:43 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19DIZd-0005po-00 for megaco@ietf.org; Wed, 07 May 2003 02:38:41 -0400 Received: from brsf10.epa.ericsson.se ([61.88.9.226]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h476b7402852; Wed, 7 May 2003 16:37:07 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h476dS000272; Wed, 7 May 2003 16:39:29 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.201]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JB8N7VSR; Wed, 7 May 2003 16:39:27 +1000 Message-ID: <3EB856D4.9A9E61DF@ericsson.com.au> Date: Wed, 07 May 2003 10:44:04 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: svkumar@hss.hns.com CC: megaco@ietf.org Subject: Re: [Megaco] Query on Status of packages References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit G'Day Shiv, 5.2.0 was a typo, 5.5.0 is the latest. The Megaco WG does not approve 3G Specs related to Megaco. ITU SG16 produces a Packages Guide Supplement which usually contains a description and reference to 3GPP packages. Regards, Christian svkumar@hss.hns.com wrote: > > Hi > > The latest 3GPP TS 29.232 version is 5.5.0. > These is a Release 5 spec. > You can get it from > http://www.3gpp.org/ftp/specs/latest/Rel-5/29_series/ > > Christian, you have mentioned v5.2.0. Is this a typo or does the MEGACO WG > separately approve the 3G Specs related to MEGACO ? > > Regards > Shiv > > Christian Groves @ietf.org on 05/06/2003 > 06:12:40 AM > > Sent by: megaco-admin@ietf.org > > To: Rashim Anand > cc: megaco@ietf.org > > Subject: Re: [Megaco] Query on Status of packages > > Hello Rashim, > > H.248.17 has been approved and can be found at the ITU website. > The lastest version of 3GPP TS29.232 is now V5.2.0. > > Regards, Christian > > Rashim Anand wrote: > > > > Hi, > > > > Can someone update me on the status of the following packages - > > > > CAS packages (draft-manyfolks-megaco-caspackage-02) > > This draft was set to expire in Sep 2002. Has it been replaced > > by a newer version or a RFC? > > > > Line Test packages (H.248.17) > > Are the packages defined in this package still in a state of flux > > or has it been finally approved? > > > > 3GPP packages (3GPP TS 29.232 V4.4.0 (2002-03)) > > When is this document expected to be approved? > > > > Thanks, > > Rashim > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed May 7 02:42:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18264 for ; Wed, 7 May 2003 02:42:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h476owJ17004 for megaco-archive@odin.ietf.org; Wed, 7 May 2003 02:50:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h476ow817001 for ; Wed, 7 May 2003 02:50:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18224 for ; Wed, 7 May 2003 02:41:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DIeT-0005r5-00 for megaco-web-archive@ietf.org; Wed, 07 May 2003 02:43:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DIeT-0005r1-00 for megaco-web-archive@ietf.org; Wed, 07 May 2003 02:43:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h476mS816906; Wed, 7 May 2003 02:48:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h476jx816837 for ; Wed, 7 May 2003 02:45:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18161 for ; Wed, 7 May 2003 02:36:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DIZf-0005ps-00 for megaco@ietf.org; Wed, 07 May 2003 02:38:43 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19DIZd-0005po-00 for megaco@ietf.org; Wed, 07 May 2003 02:38:41 -0400 Received: from brsf10.epa.ericsson.se ([61.88.9.226]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h476b7402852; Wed, 7 May 2003 16:37:07 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h476dS000272; Wed, 7 May 2003 16:39:29 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.201]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JB8N7VSR; Wed, 7 May 2003 16:39:27 +1000 Message-ID: <3EB856D4.9A9E61DF@ericsson.com.au> Date: Wed, 07 May 2003 10:44:04 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: svkumar@hss.hns.com CC: megaco@ietf.org Subject: Re: [Megaco] Query on Status of packages References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit G'Day Shiv, 5.2.0 was a typo, 5.5.0 is the latest. The Megaco WG does not approve 3G Specs related to Megaco. ITU SG16 produces a Packages Guide Supplement which usually contains a description and reference to 3GPP packages. Regards, Christian svkumar@hss.hns.com wrote: > > Hi > > The latest 3GPP TS 29.232 version is 5.5.0. > These is a Release 5 spec. > You can get it from > http://www.3gpp.org/ftp/specs/latest/Rel-5/29_series/ > > Christian, you have mentioned v5.2.0. Is this a typo or does the MEGACO WG > separately approve the 3G Specs related to MEGACO ? > > Regards > Shiv > > Christian Groves @ietf.org on 05/06/2003 > 06:12:40 AM > > Sent by: megaco-admin@ietf.org > > To: Rashim Anand > cc: megaco@ietf.org > > Subject: Re: [Megaco] Query on Status of packages > > Hello Rashim, > > H.248.17 has been approved and can be found at the ITU website. > The lastest version of 3GPP TS29.232 is now V5.2.0. > > Regards, Christian > > Rashim Anand wrote: > > > > Hi, > > > > Can someone update me on the status of the following packages - > > > > CAS packages (draft-manyfolks-megaco-caspackage-02) > > This draft was set to expire in Sep 2002. Has it been replaced > > by a newer version or a RFC? > > > > Line Test packages (H.248.17) > > Are the packages defined in this package still in a state of flux > > or has it been finally approved? > > > > 3GPP packages (3GPP TS 29.232 V4.4.0 (2002-03)) > > When is this document expected to be approved? > > > > Thanks, > > Rashim > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon May 12 10:19:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14888 for ; Mon, 12 May 2003 10:19:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CDhfB31082; Mon, 12 May 2003 09:43:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CDeEB30678 for ; Mon, 12 May 2003 09:40:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13970 for ; Mon, 12 May 2003 10:14:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FE64-0000HG-00 for megaco@ietf.org; Mon, 12 May 2003 10:16:08 -0400 Received: from [203.196.156.177] (helo=netserv.rnd.hfcl.com) by ietf-mx with esmtp (Exim 4.12) id 19FE63-0000H5-00 for megaco@ietf.org; Mon, 12 May 2003 10:16:07 -0400 Received: (from root@localhost) by netserv.rnd.hfcl.com (8.11.6/8.11.2) id h4CEKnt13216 for megaco@ietf.org; Mon, 12 May 2003 19:50:49 +0530 Received: from mukta ([132.147.166.55]) by netserv.rnd.hfcl.com (8.11.6/8.11.2) with SMTP id h4CEKjg13209 for ; Mon, 12 May 2003 19:50:46 +0530 From: "milton" To: "Megaco" Date: Mon, 12 May 2003 19:47:49 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Xmilter: rnd.hfcl.com X-Virus-Scanned: by AMaViS perl-11 Content-Transfer-Encoding: 7bit Subject: [Megaco] Trunking Gateway Profile Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear All, We are working on a Trunking Gatway product-line. Not surprisingly we have chosen Megaco as the only stable controlling protocol. In the process we had some issues with respect to the provisioning in this network architecture. I can share a few observations with you > Presently in this network Network Mangement mechanism is largely undefined. We need to have a fixed line of demarkation between provisioning and control. > More dependent you are on provisioning less robust you become. > Local gateway hardware need not be reflected on the softswitch. -Please comment on these observations. In a multi-vendor network architecture The last point seemed important and one way to achieve this with megaco is by standardizing the naming convention for a particular line of products. As we know, to do that we have to come out with a proper profile for the same. Although defining profiles is not a work-item under the base protocol definition process - I think we have to start this parallel effort of defining profiles. In this regard we have to understand that we need profiles To Make It Happen. We have come out with such a profile for trunking gateway which is quite different from the MSF defined profile. Can we push our trunking gateway profile with IETF? If yes can anybody suggest how to move with that effort? - Milton _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon May 12 10:20:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15004 for ; Mon, 12 May 2003 10:20:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4CDk9c31318 for megaco-archive@odin.ietf.org; Mon, 12 May 2003 09:46:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CDk9B31315 for ; Mon, 12 May 2003 09:46:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14981 for ; Mon, 12 May 2003 10:20:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FEBm-0000T9-00 for megaco-web-archive@ietf.org; Mon, 12 May 2003 10:22:02 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FEBm-0000T5-00 for megaco-web-archive@ietf.org; Mon, 12 May 2003 10:22:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CDhfB31082; Mon, 12 May 2003 09:43:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CDeEB30678 for ; Mon, 12 May 2003 09:40:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13970 for ; Mon, 12 May 2003 10:14:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FE64-0000HG-00 for megaco@ietf.org; Mon, 12 May 2003 10:16:08 -0400 Received: from [203.196.156.177] (helo=netserv.rnd.hfcl.com) by ietf-mx with esmtp (Exim 4.12) id 19FE63-0000H5-00 for megaco@ietf.org; Mon, 12 May 2003 10:16:07 -0400 Received: (from root@localhost) by netserv.rnd.hfcl.com (8.11.6/8.11.2) id h4CEKnt13216 for megaco@ietf.org; Mon, 12 May 2003 19:50:49 +0530 Received: from mukta ([132.147.166.55]) by netserv.rnd.hfcl.com (8.11.6/8.11.2) with SMTP id h4CEKjg13209 for ; Mon, 12 May 2003 19:50:46 +0530 From: "milton" To: "Megaco" Date: Mon, 12 May 2003 19:47:49 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Xmilter: rnd.hfcl.com X-Virus-Scanned: by AMaViS perl-11 Content-Transfer-Encoding: 7bit Subject: [Megaco] Trunking Gateway Profile Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear All, We are working on a Trunking Gatway product-line. Not surprisingly we have chosen Megaco as the only stable controlling protocol. In the process we had some issues with respect to the provisioning in this network architecture. I can share a few observations with you > Presently in this network Network Mangement mechanism is largely undefined. We need to have a fixed line of demarkation between provisioning and control. > More dependent you are on provisioning less robust you become. > Local gateway hardware need not be reflected on the softswitch. -Please comment on these observations. In a multi-vendor network architecture The last point seemed important and one way to achieve this with megaco is by standardizing the naming convention for a particular line of products. As we know, to do that we have to come out with a proper profile for the same. Although defining profiles is not a work-item under the base protocol definition process - I think we have to start this parallel effort of defining profiles. In this regard we have to understand that we need profiles To Make It Happen. We have come out with such a profile for trunking gateway which is quite different from the MSF defined profile. Can we push our trunking gateway profile with IETF? If yes can anybody suggest how to move with that effort? - Milton _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon May 12 11:53:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21819 for ; Mon, 12 May 2003 11:53:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CFE1B07177; Mon, 12 May 2003 11:14:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CF86B06923 for ; Mon, 12 May 2003 11:08:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21423 for ; Mon, 12 May 2003 11:42:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FFT4-0002DU-00 for megaco@ietf.org; Mon, 12 May 2003 11:43:58 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 19FFT3-0002DD-00 for megaco@ietf.org; Mon, 12 May 2003 11:43:57 -0400 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h4CFiTdp026640 for ; Mon, 12 May 2003 17:44:29 +0200 Received: from vies194a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h4CFiRZv014595 for ; Mon, 12 May 2003 17:44:28 +0200 (MET DST) Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Mon, 12 May 2003 17:44:26 +0200 Message-ID: From: Kalleitner Franz To: "'megaco@ietf.org'" Date: Mon, 12 May 2003 17:44:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3189D.554911D0" Subject: [Megaco] MG registration procedure Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3189D.554911D0 Content-Type: text/plain; charset="iso-8859-1" Hi Megaco-List-members, a MG may register (not speaking from cold start) according to the shown examples below using the ServicChangeMethod=Restart on its Root termination. I didn't found any statement in the specification which contextID shall be used either NULL or ALL wildcard. Therefore it seems to be possible to start a correct registration procedure using the ALL wildcard too, as shown in example2 Concerns about exampel1: However an MG may be assembled as pure packet oriented node and offers only ephemeral resources, without any circuted switched resources. I think this kind of MG will not be aware to process resources in NULL Context? Concerns about example2: An alternative would be the use of ALL wildcard , but as far as I understood the ALL wildcard does not include resources which are in the NULL context. However, which registration may be more appropriate. The example flows shows the H248 uses as ContextID = NULL and in comparison e.g with the ITU-T Q1950, which defined ALL wildcard for that procedure. I think most implementations uses the NULL for MGW registration, but a statement in the IG would help to close this ambiguity, at least that both methods would have the same outcome. Comments ? Franz example 1: MEGACO/1 [124.124.124.222] Transaction = 9998 { Context = - { ServiceChange = ROOT {Services { Method=Restart, ServiceChangeAddress=55555, Profile=ResGW/1} } } } example 2: MEGACO/1 [124.124.124.222] Transaction = 9998 { Context = * { ServiceChange = ROOT {Services { Method=Restart, ServiceChangeAddress=55555, Profile=ResGW/1} } } } ------_=_NextPart_001_01C3189D.554911D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+TUcgcmVn aXN0cmF0aW9uIHByb2NlZHVyZTwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQg U0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij5IaSBNZWdhY28tTGlzdC1tZW1iZXJzLDwvRk9OVD4N CjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij5hIE1HIG1heSByZWdp c3RlciAobm90IHNwZWFraW5nIGZyb20gY29sZCBzdGFydCkgYWNjb3JkaW5nIHRvIHRoZSBzaG93 biBleGFtcGxlcyBiZWxvdyB1c2luZyB0aGUgU2VydmljQ2hhbmdlTWV0aG9kPVJlc3RhcnQgb24g aXRzIFJvb3QgdGVybWluYXRpb24uPEJSPg0KSSBkaWRuJ3QgZm91bmQgYW55IHN0YXRlbWVudCBp biB0aGUgc3BlY2lmaWNhdGlvbiB3aGljaCBjb250ZXh0SUQgc2hhbGwgYmUgdXNlZCBlaXRoZXIg TlVMTCBvciBBTEwgd2lsZGNhcmQuPEJSPg0KVGhlcmVmb3JlIGl0IHNlZW1zIHRvIGJlIHBvc3Np YmxlIHRvIHN0YXJ0IGEgY29ycmVjdCByZWdpc3RyYXRpb24gcHJvY2VkdXJlIHVzaW5nIHRoZSBB TEwgd2lsZGNhcmQgdG9vLCBhcyBzaG93biBpbiBleGFtcGxlMiA8L0ZPTlQ+PC9QPg0KDQo8UD48 Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPkNvbmNlcm5zIGFib3V0IGV4YW1wZWwxOjxC Uj4NCkhvd2V2ZXIgYW4gTUcgbWF5IGJlIGFzc2VtYmxlZCBhcyBwdXJlIHBhY2tldCBvcmllbnRl ZCBub2RlIGFuZCBvZmZlcnMgb25seSBlcGhlbWVyYWwgcmVzb3VyY2VzLCB3aXRob3V0IGFueSBj aXJjdXRlZCBzd2l0Y2hlZCByZXNvdXJjZXMuPEJSPg0KSSB0aGluayB0aGlzIGtpbmQgb2YgTUcg d2lsbCBub3QgYmUgYXdhcmUgdG8gcHJvY2VzcyByZXNvdXJjZXMgaW4gTlVMTCBDb250ZXh0Pzwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPkNvbmNlcm5zIGFib3V0 IGV4YW1wbGUyOjxCUj4NCkFuIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRoZSB1c2Ugb2YgQUxMIHdp bGRjYXJkICwgYnV0IGFzIGZhciBhcyBJIHVuZGVyc3Rvb2QgdGhlIEFMTCB3aWxkY2FyZCBkb2Vz IG5vdCBpbmNsdWRlIHJlc291cmNlcyB3aGljaDxCUj4NCmFyZSBpbiB0aGUgTlVMTCBjb250ZXh0 LjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPkhvd2V2ZXIsIHdo aWNoIHJlZ2lzdHJhdGlvbiBtYXkgYmUgbW9yZSBhcHByb3ByaWF0ZS4gVGhlIGV4YW1wbGUgZmxv d3Mgc2hvd3MgdGhlIEgyNDggdXNlcyBhcyBDb250ZXh0SUQgPSBOVUxMIGFuZCBpbiBjb21wYXJp c29uIGUuZyB3aXRoPEJSPg0KdGhlIElUVS1UIFExOTUwLCB3aGljaCBkZWZpbmVkIEFMTCB3aWxk Y2FyZCBmb3IgdGhhdCBwcm9jZWR1cmUuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJD b3VyaWVyIE5ldyI+SSB0aGluayBtb3N0IGltcGxlbWVudGF0aW9ucyB1c2VzIHRoZSBOVUxMIGZv ciBNR1cgcmVnaXN0cmF0aW9uLCBidXQgYSBzdGF0ZW1lbnQgaW4gdGhlIElHIHdvdWxkIGhlbHAg dG8gY2xvc2UgdGhpcyBhbWJpZ3VpdHksIGF0IGxlYXN0IHRoYXQgYm90aCBtZXRob2RzPEJSPg0K d291bGQgaGF2ZSB0aGUgc2FtZSBvdXRjb21lLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD RT0iQ291cmllciBOZXciPkNvbW1lbnRzID88L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9 IkNvdXJpZXIgTmV3Ij5GcmFuejwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmll ciBOZXciPmV4YW1wbGUgMTo8L0ZPTlQ+DQo8QlI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiIFNJWkU9 MiBGQUNFPSJDb3VyaWVyIE5ldyI+TUVHQUNPLzEgWzEyNC4xMjQuMTI0LjIyMl08L0ZPTlQ+DQo8 QlI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+VHJhbnNh Y3Rpb24gPSA5OTk4IHs8L0ZPTlQ+DQo8QlI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiIFNJWkU9MiBG QUNFPSJDb3VyaWVyIE5ldyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IENvbnRleHQgPSAtIHs8L0ZPTlQ+ DQo8QlI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlcnZpY2VDaGFuZ2UgPSBS T09UIHtTZXJ2aWNlcyB7PC9GT05UPg0KPEJSPjxGT05UIENPTE9SPSIjMDAwMDAwIiBTSVpFPTIg RkFDRT0iQ291cmllciBOZXciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNZXRob2Q9UmVzdGFydCwgPC9GT05UPg0KPEJS PjxGT05UIENPTE9SPSIjMDAwMDAwIiBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBTZXJ2aWNlQ2hhbmdlQWRkcmVzcz01NTU1NSwgUHJvZmlsZT1SZXNHVy8xfTwvRk9OVD4NCjxC Uj48Rk9OVCBDT0xPUj0iIzAwMDAwMCIgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvRk9OVD4NCjxCUj48Rk9OVCBD T0xPUj0iIzAwMDAwMCIgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsmbmJzcDsmbmJz cDsgfTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPn08L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij5leGFtcGxlIDI6IDwvRk9OVD4N CjxCUj48Rk9OVCBDT0xPUj0iIzAwMDAwMCIgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij5NRUdB Q08vMSBbMTI0LjEyNC4xMjQuMjIyXTwvRk9OVD4NCjxCUj48Rk9OVCBDT0xPUj0iIzAwMDAwMCIg U0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij5UcmFuc2FjdGlvbiA9IDk5OTggezwvRk9OVD4NCjxC Uj48Rk9OVCBDT0xPUj0iIzAwMDAwMCIgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsm bmJzcDsmbmJzcDsgQ29udGV4dCA9ICogezwvRk9OVD4NCjxCUj48Rk9OVCBDT0xPUj0iIzAwMDAw MCIgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgU2VydmljZUNoYW5nZSA9IFJPT1Qge1NlcnZpY2VzIHs8L0ZPTlQ+DQo8 QlI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IE1ldGhvZD1SZXN0YXJ0LCA8L0ZPTlQ+DQo8QlI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiIFNJ WkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlcnZpY2VDaGFuZ2VBZGRyZXNzPTU1 NTU1LCBQcm9maWxlPVJlc0dXLzF9PC9GT05UPg0KPEJSPjxGT05UIENPTE9SPSIjMDAwMDAwIiBT SVpFPTIgRkFDRT0iQ291cmllciBOZXciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB9PC9GT05UPg0KPEJSPjxGT05UIENPTE9SPSIjMDAwMDAwIiBTSVpFPTIgRkFD RT0iQ291cmllciBOZXciPiZuYnNwOyZuYnNwOyZuYnNwOyB9PC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+fTwvRk9OVD4NCjwvUD4NCjxCUj4NCg0KPC9CT0RZPg0K PC9IVE1MPg== ------_=_NextPart_001_01C3189D.554911D0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon May 12 11:54:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21854 for ; Mon, 12 May 2003 11:54:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4CFKN107537 for megaco-archive@odin.ietf.org; Mon, 12 May 2003 11:20:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CFKNB07534 for ; Mon, 12 May 2003 11:20:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21843 for ; Mon, 12 May 2003 11:54:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FFex-0002LC-00 for megaco-web-archive@ietf.org; Mon, 12 May 2003 11:56:15 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FFex-0002L9-00 for megaco-web-archive@ietf.org; Mon, 12 May 2003 11:56:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CFE1B07177; Mon, 12 May 2003 11:14:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CF86B06923 for ; Mon, 12 May 2003 11:08:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21423 for ; Mon, 12 May 2003 11:42:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FFT4-0002DU-00 for megaco@ietf.org; Mon, 12 May 2003 11:43:58 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 19FFT3-0002DD-00 for megaco@ietf.org; Mon, 12 May 2003 11:43:57 -0400 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h4CFiTdp026640 for ; Mon, 12 May 2003 17:44:29 +0200 Received: from vies194a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h4CFiRZv014595 for ; Mon, 12 May 2003 17:44:28 +0200 (MET DST) Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Mon, 12 May 2003 17:44:26 +0200 Message-ID: From: Kalleitner Franz To: "'megaco@ietf.org'" Date: Mon, 12 May 2003 17:44:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3189D.554911D0" Subject: [Megaco] MG registration procedure Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3189D.554911D0 Content-Type: text/plain; charset="iso-8859-1" Hi Megaco-List-members, a MG may register (not speaking from cold start) according to the shown examples below using the ServicChangeMethod=Restart on its Root termination. I didn't found any statement in the specification which contextID shall be used either NULL or ALL wildcard. Therefore it seems to be possible to start a correct registration procedure using the ALL wildcard too, as shown in example2 Concerns about exampel1: However an MG may be assembled as pure packet oriented node and offers only ephemeral resources, without any circuted switched resources. I think this kind of MG will not be aware to process resources in NULL Context? Concerns about example2: An alternative would be the use of ALL wildcard , but as far as I understood the ALL wildcard does not include resources which are in the NULL context. However, which registration may be more appropriate. The example flows shows the H248 uses as ContextID = NULL and in comparison e.g with the ITU-T Q1950, which defined ALL wildcard for that procedure. I think most implementations uses the NULL for MGW registration, but a statement in the IG would help to close this ambiguity, at least that both methods would have the same outcome. Comments ? Franz example 1: MEGACO/1 [124.124.124.222] Transaction = 9998 { Context = - { ServiceChange = ROOT {Services { Method=Restart, ServiceChangeAddress=55555, Profile=ResGW/1} } } } example 2: MEGACO/1 [124.124.124.222] Transaction = 9998 { Context = * { ServiceChange = ROOT {Services { Method=Restart, ServiceChangeAddress=55555, Profile=ResGW/1} } } } ------_=_NextPart_001_01C3189D.554911D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+TUcgcmVn aXN0cmF0aW9uIHByb2NlZHVyZTwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQg U0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij5IaSBNZWdhY28tTGlzdC1tZW1iZXJzLDwvRk9OVD4N CjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij5hIE1HIG1heSByZWdp c3RlciAobm90IHNwZWFraW5nIGZyb20gY29sZCBzdGFydCkgYWNjb3JkaW5nIHRvIHRoZSBzaG93 biBleGFtcGxlcyBiZWxvdyB1c2luZyB0aGUgU2VydmljQ2hhbmdlTWV0aG9kPVJlc3RhcnQgb24g aXRzIFJvb3QgdGVybWluYXRpb24uPEJSPg0KSSBkaWRuJ3QgZm91bmQgYW55IHN0YXRlbWVudCBp biB0aGUgc3BlY2lmaWNhdGlvbiB3aGljaCBjb250ZXh0SUQgc2hhbGwgYmUgdXNlZCBlaXRoZXIg TlVMTCBvciBBTEwgd2lsZGNhcmQuPEJSPg0KVGhlcmVmb3JlIGl0IHNlZW1zIHRvIGJlIHBvc3Np YmxlIHRvIHN0YXJ0IGEgY29ycmVjdCByZWdpc3RyYXRpb24gcHJvY2VkdXJlIHVzaW5nIHRoZSBB TEwgd2lsZGNhcmQgdG9vLCBhcyBzaG93biBpbiBleGFtcGxlMiA8L0ZPTlQ+PC9QPg0KDQo8UD48 Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPkNvbmNlcm5zIGFib3V0IGV4YW1wZWwxOjxC Uj4NCkhvd2V2ZXIgYW4gTUcgbWF5IGJlIGFzc2VtYmxlZCBhcyBwdXJlIHBhY2tldCBvcmllbnRl ZCBub2RlIGFuZCBvZmZlcnMgb25seSBlcGhlbWVyYWwgcmVzb3VyY2VzLCB3aXRob3V0IGFueSBj aXJjdXRlZCBzd2l0Y2hlZCByZXNvdXJjZXMuPEJSPg0KSSB0aGluayB0aGlzIGtpbmQgb2YgTUcg d2lsbCBub3QgYmUgYXdhcmUgdG8gcHJvY2VzcyByZXNvdXJjZXMgaW4gTlVMTCBDb250ZXh0Pzwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPkNvbmNlcm5zIGFib3V0 IGV4YW1wbGUyOjxCUj4NCkFuIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRoZSB1c2Ugb2YgQUxMIHdp bGRjYXJkICwgYnV0IGFzIGZhciBhcyBJIHVuZGVyc3Rvb2QgdGhlIEFMTCB3aWxkY2FyZCBkb2Vz IG5vdCBpbmNsdWRlIHJlc291cmNlcyB3aGljaDxCUj4NCmFyZSBpbiB0aGUgTlVMTCBjb250ZXh0 LjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPkhvd2V2ZXIsIHdo aWNoIHJlZ2lzdHJhdGlvbiBtYXkgYmUgbW9yZSBhcHByb3ByaWF0ZS4gVGhlIGV4YW1wbGUgZmxv d3Mgc2hvd3MgdGhlIEgyNDggdXNlcyBhcyBDb250ZXh0SUQgPSBOVUxMIGFuZCBpbiBjb21wYXJp c29uIGUuZyB3aXRoPEJSPg0KdGhlIElUVS1UIFExOTUwLCB3aGljaCBkZWZpbmVkIEFMTCB3aWxk Y2FyZCBmb3IgdGhhdCBwcm9jZWR1cmUuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJD b3VyaWVyIE5ldyI+SSB0aGluayBtb3N0IGltcGxlbWVudGF0aW9ucyB1c2VzIHRoZSBOVUxMIGZv ciBNR1cgcmVnaXN0cmF0aW9uLCBidXQgYSBzdGF0ZW1lbnQgaW4gdGhlIElHIHdvdWxkIGhlbHAg dG8gY2xvc2UgdGhpcyBhbWJpZ3VpdHksIGF0IGxlYXN0IHRoYXQgYm90aCBtZXRob2RzPEJSPg0K d291bGQgaGF2ZSB0aGUgc2FtZSBvdXRjb21lLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD RT0iQ291cmllciBOZXciPkNvbW1lbnRzID88L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9 IkNvdXJpZXIgTmV3Ij5GcmFuejwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmll ciBOZXciPmV4YW1wbGUgMTo8L0ZPTlQ+DQo8QlI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiIFNJWkU9 MiBGQUNFPSJDb3VyaWVyIE5ldyI+TUVHQUNPLzEgWzEyNC4xMjQuMTI0LjIyMl08L0ZPTlQ+DQo8 QlI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+VHJhbnNh Y3Rpb24gPSA5OTk4IHs8L0ZPTlQ+DQo8QlI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiIFNJWkU9MiBG QUNFPSJDb3VyaWVyIE5ldyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IENvbnRleHQgPSAtIHs8L0ZPTlQ+ DQo8QlI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlcnZpY2VDaGFuZ2UgPSBS T09UIHtTZXJ2aWNlcyB7PC9GT05UPg0KPEJSPjxGT05UIENPTE9SPSIjMDAwMDAwIiBTSVpFPTIg RkFDRT0iQ291cmllciBOZXciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNZXRob2Q9UmVzdGFydCwgPC9GT05UPg0KPEJS PjxGT05UIENPTE9SPSIjMDAwMDAwIiBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBTZXJ2aWNlQ2hhbmdlQWRkcmVzcz01NTU1NSwgUHJvZmlsZT1SZXNHVy8xfTwvRk9OVD4NCjxC Uj48Rk9OVCBDT0xPUj0iIzAwMDAwMCIgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvRk9OVD4NCjxCUj48Rk9OVCBD T0xPUj0iIzAwMDAwMCIgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsmbmJzcDsmbmJz cDsgfTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPn08L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij5leGFtcGxlIDI6IDwvRk9OVD4N CjxCUj48Rk9OVCBDT0xPUj0iIzAwMDAwMCIgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij5NRUdB Q08vMSBbMTI0LjEyNC4xMjQuMjIyXTwvRk9OVD4NCjxCUj48Rk9OVCBDT0xPUj0iIzAwMDAwMCIg U0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij5UcmFuc2FjdGlvbiA9IDk5OTggezwvRk9OVD4NCjxC Uj48Rk9OVCBDT0xPUj0iIzAwMDAwMCIgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsm bmJzcDsmbmJzcDsgQ29udGV4dCA9ICogezwvRk9OVD4NCjxCUj48Rk9OVCBDT0xPUj0iIzAwMDAw MCIgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgU2VydmljZUNoYW5nZSA9IFJPT1Qge1NlcnZpY2VzIHs8L0ZPTlQ+DQo8 QlI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IE1ldGhvZD1SZXN0YXJ0LCA8L0ZPTlQ+DQo8QlI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiIFNJ WkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlcnZpY2VDaGFuZ2VBZGRyZXNzPTU1 NTU1LCBQcm9maWxlPVJlc0dXLzF9PC9GT05UPg0KPEJSPjxGT05UIENPTE9SPSIjMDAwMDAwIiBT SVpFPTIgRkFDRT0iQ291cmllciBOZXciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB9PC9GT05UPg0KPEJSPjxGT05UIENPTE9SPSIjMDAwMDAwIiBTSVpFPTIgRkFD RT0iQ291cmllciBOZXciPiZuYnNwOyZuYnNwOyZuYnNwOyB9PC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+fTwvRk9OVD4NCjwvUD4NCjxCUj4NCg0KPC9CT0RZPg0K PC9IVE1MPg== ------_=_NextPart_001_01C3189D.554911D0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon May 12 22:40:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11926 for ; Mon, 12 May 2003 22:40:39 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D25VB22326; Mon, 12 May 2003 22:05:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D239B22250 for ; Mon, 12 May 2003 22:03:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11890 for ; Mon, 12 May 2003 22:36:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FPgm-0006Tc-00 for megaco@ietf.org; Mon, 12 May 2003 22:38:48 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19FPgk-0006TU-00 for megaco@ietf.org; Mon, 12 May 2003 22:38:46 -0400 Received: from brsf10.epa.ericsson.se ([61.88.9.226]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h4D2bH423820; Tue, 13 May 2003 12:37:17 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h4D2de008871; Tue, 13 May 2003 12:39:40 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.231]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JB8N0S6B; Tue, 13 May 2003 12:39:39 +1000 Message-ID: <3EC05AE3.31CDA6E1@ericsson.com.au> Date: Tue, 13 May 2003 12:39:31 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kalleitner Franz CC: "'megaco@ietf.org'" Subject: Re: [Megaco] MG registration procedure References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Franz, The revised Q.1950 now lists the context ID as "value not significant". When termination id "root" is used the value of context id is insignificant as you are talking about the gateway as a whole. Regards, Christian Kalleitner Franz wrote: > > Hi Megaco-List-members, > > a MG may register (not speaking from cold start) according to the shown > examples below using the ServicChangeMethod=Restart on its Root termination. > I didn't found any statement in the specification which contextID shall be > used either NULL or ALL wildcard. > Therefore it seems to be possible to start a correct registration procedure > using the ALL wildcard too, as shown in example2 > > Concerns about exampel1: > However an MG may be assembled as pure packet oriented node and offers only > ephemeral resources, without any circuted switched resources. > I think this kind of MG will not be aware to process resources in NULL > Context? > Concerns about example2: > An alternative would be the use of ALL wildcard , but as far as I understood > the ALL wildcard does not include resources which > are in the NULL context. > However, which registration may be more appropriate. The example flows shows > the H248 uses as ContextID = NULL and in comparison e.g with > the ITU-T Q1950, which defined ALL wildcard for that procedure. > I think most implementations uses the NULL for MGW registration, but a > statement in the IG would help to close this ambiguity, at least that both > methods > would have the same outcome. > Comments ? > Franz > example 1: > MEGACO/1 [124.124.124.222] > Transaction = 9998 { > Context = - { > ServiceChange = ROOT {Services { > Method=Restart, > ServiceChangeAddress=55555, Profile=ResGW/1} > } > } > } > example 2: > MEGACO/1 [124.124.124.222] > Transaction = 9998 { > Context = * { > ServiceChange = ROOT {Services { > Method=Restart, > ServiceChangeAddress=55555, Profile=ResGW/1} > } > } > } _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon May 12 22:41:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11949 for ; Mon, 12 May 2003 22:41:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4D27W622947 for megaco-archive@odin.ietf.org; Mon, 12 May 2003 22:07:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D27WB22944 for ; Mon, 12 May 2003 22:07:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11945 for ; Mon, 12 May 2003 22:41:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FPl0-0006UH-00 for megaco-web-archive@ietf.org; Mon, 12 May 2003 22:43:10 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FPl0-0006UE-00 for megaco-web-archive@ietf.org; Mon, 12 May 2003 22:43:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D25VB22326; Mon, 12 May 2003 22:05:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D239B22250 for ; Mon, 12 May 2003 22:03:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11890 for ; Mon, 12 May 2003 22:36:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FPgm-0006Tc-00 for megaco@ietf.org; Mon, 12 May 2003 22:38:48 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19FPgk-0006TU-00 for megaco@ietf.org; Mon, 12 May 2003 22:38:46 -0400 Received: from brsf10.epa.ericsson.se ([61.88.9.226]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h4D2bH423820; Tue, 13 May 2003 12:37:17 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h4D2de008871; Tue, 13 May 2003 12:39:40 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.231]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JB8N0S6B; Tue, 13 May 2003 12:39:39 +1000 Message-ID: <3EC05AE3.31CDA6E1@ericsson.com.au> Date: Tue, 13 May 2003 12:39:31 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kalleitner Franz CC: "'megaco@ietf.org'" Subject: Re: [Megaco] MG registration procedure References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Franz, The revised Q.1950 now lists the context ID as "value not significant". When termination id "root" is used the value of context id is insignificant as you are talking about the gateway as a whole. Regards, Christian Kalleitner Franz wrote: > > Hi Megaco-List-members, > > a MG may register (not speaking from cold start) according to the shown > examples below using the ServicChangeMethod=Restart on its Root termination. > I didn't found any statement in the specification which contextID shall be > used either NULL or ALL wildcard. > Therefore it seems to be possible to start a correct registration procedure > using the ALL wildcard too, as shown in example2 > > Concerns about exampel1: > However an MG may be assembled as pure packet oriented node and offers only > ephemeral resources, without any circuted switched resources. > I think this kind of MG will not be aware to process resources in NULL > Context? > Concerns about example2: > An alternative would be the use of ALL wildcard , but as far as I understood > the ALL wildcard does not include resources which > are in the NULL context. > However, which registration may be more appropriate. The example flows shows > the H248 uses as ContextID = NULL and in comparison e.g with > the ITU-T Q1950, which defined ALL wildcard for that procedure. > I think most implementations uses the NULL for MGW registration, but a > statement in the IG would help to close this ambiguity, at least that both > methods > would have the same outcome. > Comments ? > Franz > example 1: > MEGACO/1 [124.124.124.222] > Transaction = 9998 { > Context = - { > ServiceChange = ROOT {Services { > Method=Restart, > ServiceChangeAddress=55555, Profile=ResGW/1} > } > } > } > example 2: > MEGACO/1 [124.124.124.222] > Transaction = 9998 { > Context = * { > ServiceChange = ROOT {Services { > Method=Restart, > ServiceChangeAddress=55555, Profile=ResGW/1} > } > } > } _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue May 13 09:52:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12141 for ; Tue, 13 May 2003 09:52:05 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DDH7B23635; Tue, 13 May 2003 09:17:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DCngB21128 for ; Tue, 13 May 2003 08:49:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11061 for ; Tue, 13 May 2003 09:23:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FZmE-0003pX-00 for megaco@ietf.org; Tue, 13 May 2003 09:25:06 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19FZmE-0003pN-00 for megaco@ietf.org; Tue, 13 May 2003 09:25:06 -0400 Received: from zcard307.ca.nortel.com (americasm07.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DDPWs05221; Tue, 13 May 2003 09:25:33 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRL14LFK; Tue, 13 May 2003 09:25:33 -0400 Received: from nortelnetworks.com (acart1cc.ca.nortel.com [47.129.129.55]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA02BN; Tue, 13 May 2003 09:25:32 -0400 Message-ID: <3EC0E732.8010706@nortelnetworks.com> Date: Tue, 13 May 2003 08:38:10 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Michael DiGioia CC: "Kevin Boyle" , kengr@winphoria.com, Christian.Groves@ericsson.com.au, megaco@ietf.org, bsteinka@telica.com Subject: Re: [Megaco] Megaco CAS support References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The day this was written, I was on the operating table. Today is the first day I have been in a position to respond. Kevin's frustration with the IETF process is my fault for not providing adequate leadership. For that I apologize. It stems to some extent from a confusion of objectives in my own working life. That said: -- the IESG has been unwilling to expand the Megaco charter to include packages -- at this point, the IESG is ready to terminate the Working Group (BUT KEEP THE LIST). It is up to us to determine a working relationship with the ITU-T that will keep the work moving in everybody's best interest. I should point out that SG 16 itself is not having an easy time of it -- attendance has dropped drastically in the last couple of years. The ITU-T is approaching one of those intervals when it considers reorganization, and we could find ourselves dealing with a different Study Group next year. I'll ask a couple of questions to shape discussion of how we should proceed from here: -- It seems self-evident to me that the Megaco list should continue to be the primary source of material for the Implementor's Guide. Any disagreement? -- Should we ask the ITU-T to allow us to derive I-Ds from new ITU-T Annexes so they can be reviewed by IETF process? I did that sort of transcription early on, but didn't continue because I wasn't sure our agreement with the ITU-T allowed it. -- Package documents in general have been individual drafts, since we couldn't add them to the WG charter. This means the authors were free to submit them to the IESG without my intervention. With that in mind, does anyone believe that there is an IETF role for creation of package documents independently of the ITU-T? Michael DiGioia wrote: > Kevin, > >>> IETF does not seem interested in standardizing any packages. > > > I don't believe I understand your comment. For many years the IETF has > had a well know process of making protocols into drafts and then into > approved standard RFC specifications. Do you imply by this that we > should trash IETF? I would think not since we produced the Internet as > it exists today. > >> From a telephony standpoint, I think I can see your point since the >> ITU is > > the standards body for the telephony world. However, its a closed > organization that tends to be run by the large telephone companies - > i.e., not open to world participation without the necessary fees. > > This whole idea was accepted by this group back in 99/00 to have > concurrent standards. Are we all now in agreement that this was a > mistake? I was with the minority then against this idea and for a quick > standard, produced by only the IETF, since this is how we (IETF) have > been so successful in the past. > > I produced for my company the first IpTelephone which was at the first > Bakeoff in NH. However, by that time, the idea of an IpTelephone using > the media gateway protocols was not accepted by the larger community. > > Where is Vince, Tom, and Brian now? > > /mpd > > > > > > >> From: "Kevin Boyle" >> To: Michael DiGioia , >> kengr@winphoria.com, Christian.Groves@ericsson.com.au, megaco@ietf.org >> CC: bsteinka@telica.com >> Subject: RE: [Megaco] Megaco CAS support >> Date: Tue, 22 Apr 2003 17:26:15 -0400 >> >> With all due respect, the IETF had its chance to progress these (and many >> other) packages. In the interests of the larger community, I have >> taken the >> packages to the ITU for standardization, since the IETF does not seem >> interested in standardizing any packages. >> >> The work in the IETF is not "up and running". The drafts published by >> Hughes were published after the CAS packages were submitted to the ITU. >> >> Given that the working group is in the process of winding down, I do >> not see >> any benefit to anyone in continuing to allow the IETF to hold up >> standardization when the ITU is prepared to consider and advance the >> work. >> >> Kevin >> >> -----Original Message----- >> From: Michael DiGioia [mailto:michaeldigioia@hotmail.com] >> Sent: Tuesday, April 22, 2003 5:01 PM >> To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; >> megaco@ietf.org >> Cc: bsteinka@telica.com >> Subject: Re: [Megaco] Megaco CAS support >> >> >> >> Christian, >> >> I agree, CAS should be part of the IETF similar to the original MEGACO >> draft >> >> work that held both organizations in sync. >> >> /mpd >> >> >> >> >> >From: Aleksandr Ryabin >> >To: Christian Groves , >> >megaco@ietf.org >> >CC: Brad Steinka >> >Subject: Re: [Megaco] Megaco CAS support >> >Date: Tue, 22 Apr 2003 10:30:01 -0400 >> > >> >Hi Christian, >> > >> >Then why are these brand new revisions of drafts were just recently >> >submitted? >> > >> >http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt >> >http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt >> > >> >More over a quick look through reveals that some of the package items >> >in >> >icas >> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same >> >wording. >> > >> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which >> >does not seem to be defined in the document and also "conflicts" with >> >above IETF "CAS Maintenance Package". >> > >> >There is also reference to r2 package in AVD-2316 nowhere found in ITU. >> > >> >Also basic CAS packages draft still available at: >> >http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0 >> >2.txt >> >but it is slightly different (outdated?) from AVD-2315 ITU version >> you have >> >> >specified. >> > >> >The recent submission of the above drafts had lead me to believe that >> >CAS work is still quite "up and running" in IETF. This is all very >> >confusing. When was it decided to move the work to ITU? Could someone >> >point me out to some references (in IETF) of that please? >> > >> >My two cents on this topic: CAS is not an isolated package and in my >> >opinion >> >it would be much more productive to keep it on both channels (ITU and >> IETF) >> >and in sync, similar to some other items done so far in H.248/MEGACO. >> >What other folks think about it? >> > >> >Also in any case can the authors of ITU and IETF CAS related packages >> >work together to come up with some kind of game plan and post it to the >> >list to avoid any further confusion and inconsistencies? >> > >> >Thanks! >> > Aleks >> > >> >At 07:54 PM 4/21/2003, Christian Groves wrote: >> >>G'Day Brad and Karl, >> >> >> >>I believe the intention is to move the CAS work into the ITU. The >> >>contributions >> >>containing the latest drafts can be found at: >> >>ftp://standard.pictel.com/avc-site/0302_San/ >> >> >> >>AVD-2312 MF Tone Generation and Detection Packages >> >>AVD-2315 Basic CAS Packages >> >>AVD-2316 International CAS Packages >> >>AVD-2317 Enhanced Analog Line Packages >> >> >> >>Regards, Christian >> >> >> >>Brad Steinka wrote: >> >> > >> >> > There were several RFC draft document that described various >> >> > packages >> >>to >> >> > support CAS, R1, R2, BCAS, etc. >> >> > Most of these drafts have expired. >> >> > >> >> > Can anyone tell me what the latest RFCs are that support CAS calls >> >> > and >> >>where >> >> > they are in the standards process? >> >> > >> >> > Thanks >> >> > >> >> > Brad Steinka >> >> > Director - Software Engineering >> >> > 734 Forest Street, Building G, Suite 100 >> >> > Marlboro, Ma. 01752 >> >> > Tel: 508-480-0909 x154 >> >> > Email: bsteinka@telica.com >> >> > Web: www.telica.com >> >> > >> >> > _______________________________________________ >> >> > Megaco mailing list >> >> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco >> >>_______________________________________________ >> >>Megaco mailing list >> >>Megaco@ietf.org >> >>https://www1.ietf.org/mailman/listinfo/megaco >> > >> >_______________________________________________ >> >Megaco mailing list >> >Megaco@ietf.org >> >https://www1.ietf.org/mailman/listinfo/megaco >> >> >> _________________________________________________________________ >> MSN 8 with e-mail virus protection service: 2 months FREE* >> http://join.msn.com/?page=features/virus >> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco > > > > _________________________________________________________________ > The new MSN 8: smart spam protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue May 13 09:53:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12212 for ; Tue, 13 May 2003 09:53:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DDJED23832 for megaco-archive@odin.ietf.org; Tue, 13 May 2003 09:19:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DDJEB23829 for ; Tue, 13 May 2003 09:19:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12176 for ; Tue, 13 May 2003 09:52:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FaEn-00047x-00 for megaco-web-archive@ietf.org; Tue, 13 May 2003 09:54:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FaEn-00047u-00 for megaco-web-archive@ietf.org; Tue, 13 May 2003 09:54:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DDH7B23635; Tue, 13 May 2003 09:17:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DCngB21128 for ; Tue, 13 May 2003 08:49:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11061 for ; Tue, 13 May 2003 09:23:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FZmE-0003pX-00 for megaco@ietf.org; Tue, 13 May 2003 09:25:06 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19FZmE-0003pN-00 for megaco@ietf.org; Tue, 13 May 2003 09:25:06 -0400 Received: from zcard307.ca.nortel.com (americasm07.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DDPWs05221; Tue, 13 May 2003 09:25:33 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRL14LFK; Tue, 13 May 2003 09:25:33 -0400 Received: from nortelnetworks.com (acart1cc.ca.nortel.com [47.129.129.55]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA02BN; Tue, 13 May 2003 09:25:32 -0400 Message-ID: <3EC0E732.8010706@nortelnetworks.com> Date: Tue, 13 May 2003 08:38:10 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Michael DiGioia CC: "Kevin Boyle" , kengr@winphoria.com, Christian.Groves@ericsson.com.au, megaco@ietf.org, bsteinka@telica.com Subject: Re: [Megaco] Megaco CAS support References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The day this was written, I was on the operating table. Today is the first day I have been in a position to respond. Kevin's frustration with the IETF process is my fault for not providing adequate leadership. For that I apologize. It stems to some extent from a confusion of objectives in my own working life. That said: -- the IESG has been unwilling to expand the Megaco charter to include packages -- at this point, the IESG is ready to terminate the Working Group (BUT KEEP THE LIST). It is up to us to determine a working relationship with the ITU-T that will keep the work moving in everybody's best interest. I should point out that SG 16 itself is not having an easy time of it -- attendance has dropped drastically in the last couple of years. The ITU-T is approaching one of those intervals when it considers reorganization, and we could find ourselves dealing with a different Study Group next year. I'll ask a couple of questions to shape discussion of how we should proceed from here: -- It seems self-evident to me that the Megaco list should continue to be the primary source of material for the Implementor's Guide. Any disagreement? -- Should we ask the ITU-T to allow us to derive I-Ds from new ITU-T Annexes so they can be reviewed by IETF process? I did that sort of transcription early on, but didn't continue because I wasn't sure our agreement with the ITU-T allowed it. -- Package documents in general have been individual drafts, since we couldn't add them to the WG charter. This means the authors were free to submit them to the IESG without my intervention. With that in mind, does anyone believe that there is an IETF role for creation of package documents independently of the ITU-T? Michael DiGioia wrote: > Kevin, > >>> IETF does not seem interested in standardizing any packages. > > > I don't believe I understand your comment. For many years the IETF has > had a well know process of making protocols into drafts and then into > approved standard RFC specifications. Do you imply by this that we > should trash IETF? I would think not since we produced the Internet as > it exists today. > >> From a telephony standpoint, I think I can see your point since the >> ITU is > > the standards body for the telephony world. However, its a closed > organization that tends to be run by the large telephone companies - > i.e., not open to world participation without the necessary fees. > > This whole idea was accepted by this group back in 99/00 to have > concurrent standards. Are we all now in agreement that this was a > mistake? I was with the minority then against this idea and for a quick > standard, produced by only the IETF, since this is how we (IETF) have > been so successful in the past. > > I produced for my company the first IpTelephone which was at the first > Bakeoff in NH. However, by that time, the idea of an IpTelephone using > the media gateway protocols was not accepted by the larger community. > > Where is Vince, Tom, and Brian now? > > /mpd > > > > > > >> From: "Kevin Boyle" >> To: Michael DiGioia , >> kengr@winphoria.com, Christian.Groves@ericsson.com.au, megaco@ietf.org >> CC: bsteinka@telica.com >> Subject: RE: [Megaco] Megaco CAS support >> Date: Tue, 22 Apr 2003 17:26:15 -0400 >> >> With all due respect, the IETF had its chance to progress these (and many >> other) packages. In the interests of the larger community, I have >> taken the >> packages to the ITU for standardization, since the IETF does not seem >> interested in standardizing any packages. >> >> The work in the IETF is not "up and running". The drafts published by >> Hughes were published after the CAS packages were submitted to the ITU. >> >> Given that the working group is in the process of winding down, I do >> not see >> any benefit to anyone in continuing to allow the IETF to hold up >> standardization when the ITU is prepared to consider and advance the >> work. >> >> Kevin >> >> -----Original Message----- >> From: Michael DiGioia [mailto:michaeldigioia@hotmail.com] >> Sent: Tuesday, April 22, 2003 5:01 PM >> To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; >> megaco@ietf.org >> Cc: bsteinka@telica.com >> Subject: Re: [Megaco] Megaco CAS support >> >> >> >> Christian, >> >> I agree, CAS should be part of the IETF similar to the original MEGACO >> draft >> >> work that held both organizations in sync. >> >> /mpd >> >> >> >> >> >From: Aleksandr Ryabin >> >To: Christian Groves , >> >megaco@ietf.org >> >CC: Brad Steinka >> >Subject: Re: [Megaco] Megaco CAS support >> >Date: Tue, 22 Apr 2003 10:30:01 -0400 >> > >> >Hi Christian, >> > >> >Then why are these brand new revisions of drafts were just recently >> >submitted? >> > >> >http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt >> >http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt >> > >> >More over a quick look through reveals that some of the package items >> >in >> >icas >> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same >> >wording. >> > >> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which >> >does not seem to be defined in the document and also "conflicts" with >> >above IETF "CAS Maintenance Package". >> > >> >There is also reference to r2 package in AVD-2316 nowhere found in ITU. >> > >> >Also basic CAS packages draft still available at: >> >http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0 >> >2.txt >> >but it is slightly different (outdated?) from AVD-2315 ITU version >> you have >> >> >specified. >> > >> >The recent submission of the above drafts had lead me to believe that >> >CAS work is still quite "up and running" in IETF. This is all very >> >confusing. When was it decided to move the work to ITU? Could someone >> >point me out to some references (in IETF) of that please? >> > >> >My two cents on this topic: CAS is not an isolated package and in my >> >opinion >> >it would be much more productive to keep it on both channels (ITU and >> IETF) >> >and in sync, similar to some other items done so far in H.248/MEGACO. >> >What other folks think about it? >> > >> >Also in any case can the authors of ITU and IETF CAS related packages >> >work together to come up with some kind of game plan and post it to the >> >list to avoid any further confusion and inconsistencies? >> > >> >Thanks! >> > Aleks >> > >> >At 07:54 PM 4/21/2003, Christian Groves wrote: >> >>G'Day Brad and Karl, >> >> >> >>I believe the intention is to move the CAS work into the ITU. The >> >>contributions >> >>containing the latest drafts can be found at: >> >>ftp://standard.pictel.com/avc-site/0302_San/ >> >> >> >>AVD-2312 MF Tone Generation and Detection Packages >> >>AVD-2315 Basic CAS Packages >> >>AVD-2316 International CAS Packages >> >>AVD-2317 Enhanced Analog Line Packages >> >> >> >>Regards, Christian >> >> >> >>Brad Steinka wrote: >> >> > >> >> > There were several RFC draft document that described various >> >> > packages >> >>to >> >> > support CAS, R1, R2, BCAS, etc. >> >> > Most of these drafts have expired. >> >> > >> >> > Can anyone tell me what the latest RFCs are that support CAS calls >> >> > and >> >>where >> >> > they are in the standards process? >> >> > >> >> > Thanks >> >> > >> >> > Brad Steinka >> >> > Director - Software Engineering >> >> > 734 Forest Street, Building G, Suite 100 >> >> > Marlboro, Ma. 01752 >> >> > Tel: 508-480-0909 x154 >> >> > Email: bsteinka@telica.com >> >> > Web: www.telica.com >> >> > >> >> > _______________________________________________ >> >> > Megaco mailing list >> >> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco >> >>_______________________________________________ >> >>Megaco mailing list >> >>Megaco@ietf.org >> >>https://www1.ietf.org/mailman/listinfo/megaco >> > >> >_______________________________________________ >> >Megaco mailing list >> >Megaco@ietf.org >> >https://www1.ietf.org/mailman/listinfo/megaco >> >> >> _________________________________________________________________ >> MSN 8 with e-mail virus protection service: 2 months FREE* >> http://join.msn.com/?page=features/virus >> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco > > > > _________________________________________________________________ > The new MSN 8: smart spam protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue May 13 13:32:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21329 for ; Tue, 13 May 2003 13:32:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DGv0B11640; Tue, 13 May 2003 12:57:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DGtjB11579 for ; Tue, 13 May 2003 12:55:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21197 for ; Tue, 13 May 2003 13:29:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FdcF-0006B2-00 for megaco@ietf.org; Tue, 13 May 2003 13:31:03 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 19FdcF-0006Az-00 for megaco@ietf.org; Tue, 13 May 2003 13:31:03 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DHVbh03777 for ; Tue, 13 May 2003 13:31:37 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 May 2003 13:31:38 -0400 Message-ID: From: "Kevin Boyle" To: Tom Taylor , Michael DiGioia Cc: kengr@winphoria.com, Christian.Groves@ericsson.com.au, megaco@ietf.org, bsteinka@telica.com Subject: RE: [Megaco] Megaco CAS support Date: Tue, 13 May 2003 13:31:34 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Comments inline. [KJBII] Kevin -----Original Message----- From: Tom Taylor [mailto:taylor@nortelnetworks.com] Sent: Tuesday, May 13, 2003 8:38 AM To: Michael DiGioia Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; kengr@winphoria.com; Christian.Groves@ericsson.com.au; megaco@ietf.org; bsteinka@telica.com Subject: Re: [Megaco] Megaco CAS support The day this was written, I was on the operating table. Today is the first day I have been in a position to respond. [KJBII] Welcome back! Kevin's frustration with the IETF process is my fault for not providing adequate leadership. For that I apologize. It stems to some extent from a confusion of objectives in my own working life. That said: -- the IESG has been unwilling to expand the Megaco charter to include packages -- at this point, the IESG is ready to terminate the Working Group (BUT KEEP THE LIST). It is up to us to determine a working relationship with the ITU-T that will keep the work moving in everybody's best interest. I should point out that SG 16 itself is not having an easy time of it -- attendance has dropped drastically in the last couple of years. The ITU-T is approaching one of those intervals when it considers reorganization, and we could find ourselves dealing with a different Study Group next year. I'll ask a couple of questions to shape discussion of how we should proceed from here: -- It seems self-evident to me that the Megaco list should continue to be the primary source of material for the Implementor's Guide. Any disagreement? [KJBII] The list has always been the definitive source, so I see no reason to change this. -- Should we ask the ITU-T to allow us to derive I-Ds from new ITU-T Annexes so they can be reviewed by IETF process? I did that sort of transcription early on, but didn't continue because I wasn't sure our agreement with the ITU-T allowed it. [KJBII] I believe we should. Would the IETF allow the annexes to become standards track docs? -- Package documents in general have been individual drafts, since we couldn't add them to the WG charter. This means the authors were free to submit them to the IESG without my intervention. With that in mind, does anyone believe that there is an IETF role for creation of package documents independently of the ITU-T? [KJBII] Since nothing stops anyone from creating a package, I do not see where this would be a problem. However(!), it seems to me that the mandate for standardizing packages has fallen to the ITU. So, I would think that if someone wants to create a package and publish it informationally, then the IETF is fine. If they would like to take it forward as a standard way of performing whatever the package does, then it goes through the ITU. Michael DiGioia wrote: > Kevin, > >>> IETF does not seem interested in standardizing any packages. > > > I don't believe I understand your comment. For many years the IETF has > had a well know process of making protocols into drafts and then into > approved standard RFC specifications. Do you imply by this that we > should trash IETF? I would think not since we produced the Internet as > it exists today. > >> From a telephony standpoint, I think I can see your point since the >> ITU is > > the standards body for the telephony world. However, its a closed > organization that tends to be run by the large telephone companies - > i.e., not open to world participation without the necessary fees. > > This whole idea was accepted by this group back in 99/00 to have > concurrent standards. Are we all now in agreement that this was a > mistake? I was with the minority then against this idea and for a quick > standard, produced by only the IETF, since this is how we (IETF) have > been so successful in the past. > > I produced for my company the first IpTelephone which was at the first > Bakeoff in NH. However, by that time, the idea of an IpTelephone using > the media gateway protocols was not accepted by the larger community. > > Where is Vince, Tom, and Brian now? > > /mpd > > > > > > >> From: "Kevin Boyle" >> To: Michael DiGioia , >> kengr@winphoria.com, Christian.Groves@ericsson.com.au, megaco@ietf.org >> CC: bsteinka@telica.com >> Subject: RE: [Megaco] Megaco CAS support >> Date: Tue, 22 Apr 2003 17:26:15 -0400 >> >> With all due respect, the IETF had its chance to progress these (and >> many >> other) packages. In the interests of the larger community, I have >> taken the >> packages to the ITU for standardization, since the IETF does not seem >> interested in standardizing any packages. >> >> The work in the IETF is not "up and running". The drafts published >> by Hughes were published after the CAS packages were submitted to the >> ITU. >> >> Given that the working group is in the process of winding down, I do >> not see >> any benefit to anyone in continuing to allow the IETF to hold up >> standardization when the ITU is prepared to consider and advance the >> work. >> >> Kevin >> >> -----Original Message----- >> From: Michael DiGioia [mailto:michaeldigioia@hotmail.com] >> Sent: Tuesday, April 22, 2003 5:01 PM >> To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; >> megaco@ietf.org >> Cc: bsteinka@telica.com >> Subject: Re: [Megaco] Megaco CAS support >> >> >> >> Christian, >> >> I agree, CAS should be part of the IETF similar to the original >> MEGACO >> draft >> >> work that held both organizations in sync. >> >> /mpd >> >> >> >> >> >From: Aleksandr Ryabin >> >To: Christian Groves , >> >megaco@ietf.org >> >CC: Brad Steinka >> >Subject: Re: [Megaco] Megaco CAS support >> >Date: Tue, 22 Apr 2003 10:30:01 -0400 >> > >> >Hi Christian, >> > >> >Then why are these brand new revisions of drafts were just recently >> >submitted? >> > >> >http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.t >> >xt >> >http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt >> > >> >More over a quick look through reveals that some of the package >> >items in icas >> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same >> >wording. >> > >> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary >> >which does not seem to be defined in the document and also >> >"conflicts" with above IETF "CAS Maintenance Package". >> > >> >There is also reference to r2 package in AVD-2316 nowhere found in >> >ITU. >> > >> >Also basic CAS packages draft still available at: >> >http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackag >> >e-0 >> >2.txt >> >but it is slightly different (outdated?) from AVD-2315 ITU version >> you have >> >> >specified. >> > >> >The recent submission of the above drafts had lead me to believe >> >that CAS work is still quite "up and running" in IETF. This is all >> >very confusing. When was it decided to move the work to ITU? Could >> >someone point me out to some references (in IETF) of that please? >> > >> >My two cents on this topic: CAS is not an isolated package and in my >> >opinion it would be much more productive to keep it on both channels >> >(ITU and >> IETF) >> >and in sync, similar to some other items done so far in >> >H.248/MEGACO. What other folks think about it? >> > >> >Also in any case can the authors of ITU and IETF CAS related >> >packages work together to come up with some kind of game plan and >> >post it to the list to avoid any further confusion and >> >inconsistencies? >> > >> >Thanks! >> > Aleks >> > >> >At 07:54 PM 4/21/2003, Christian Groves wrote: >> >>G'Day Brad and Karl, >> >> >> >>I believe the intention is to move the CAS work into the ITU. The >> >>contributions containing the latest drafts can be found at: >> >>ftp://standard.pictel.com/avc-site/0302_San/ >> >> >> >>AVD-2312 MF Tone Generation and Detection Packages >> >>AVD-2315 Basic CAS Packages >> >>AVD-2316 International CAS Packages >> >>AVD-2317 Enhanced Analog Line Packages >> >> >> >>Regards, Christian >> >> >> >>Brad Steinka wrote: >> >> > >> >> > There were several RFC draft document that described various >> >> > packages >> >>to >> >> > support CAS, R1, R2, BCAS, etc. >> >> > Most of these drafts have expired. >> >> > >> >> > Can anyone tell me what the latest RFCs are that support CAS >> >> > calls and >> >>where >> >> > they are in the standards process? >> >> > >> >> > Thanks >> >> > >> >> > Brad Steinka >> >> > Director - Software Engineering >> >> > 734 Forest Street, Building G, Suite 100 >> >> > Marlboro, Ma. 01752 >> >> > Tel: 508-480-0909 x154 >> >> > Email: bsteinka@telica.com >> >> > Web: www.telica.com >> >> > >> >> > _______________________________________________ >> >> > Megaco mailing list >> >> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco >> >>_______________________________________________ >> >>Megaco mailing list >> >>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco >> > >> >_______________________________________________ >> >Megaco mailing list >> >Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco >> >> >> _________________________________________________________________ >> MSN 8 with e-mail virus protection service: 2 months FREE* >> http://join.msn.com/?page=features/virus >> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco > > > > _________________________________________________________________ > The new MSN 8: smart spam protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue May 13 13:33:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21373 for ; Tue, 13 May 2003 13:33:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DGxX211759 for megaco-archive@odin.ietf.org; Tue, 13 May 2003 12:59:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DGxWB11756 for ; Tue, 13 May 2003 12:59:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21365 for ; Tue, 13 May 2003 13:32:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fdfv-0006Cd-00 for megaco-web-archive@ietf.org; Tue, 13 May 2003 13:34:51 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Fdfv-0006CZ-00 for megaco-web-archive@ietf.org; Tue, 13 May 2003 13:34:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DGv0B11640; Tue, 13 May 2003 12:57:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DGtjB11579 for ; Tue, 13 May 2003 12:55:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21197 for ; Tue, 13 May 2003 13:29:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FdcF-0006B2-00 for megaco@ietf.org; Tue, 13 May 2003 13:31:03 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 19FdcF-0006Az-00 for megaco@ietf.org; Tue, 13 May 2003 13:31:03 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DHVbh03777 for ; Tue, 13 May 2003 13:31:37 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 May 2003 13:31:38 -0400 Message-ID: From: "Kevin Boyle" To: Tom Taylor , Michael DiGioia Cc: kengr@winphoria.com, Christian.Groves@ericsson.com.au, megaco@ietf.org, bsteinka@telica.com Subject: RE: [Megaco] Megaco CAS support Date: Tue, 13 May 2003 13:31:34 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Comments inline. [KJBII] Kevin -----Original Message----- From: Tom Taylor [mailto:taylor@nortelnetworks.com] Sent: Tuesday, May 13, 2003 8:38 AM To: Michael DiGioia Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; kengr@winphoria.com; Christian.Groves@ericsson.com.au; megaco@ietf.org; bsteinka@telica.com Subject: Re: [Megaco] Megaco CAS support The day this was written, I was on the operating table. Today is the first day I have been in a position to respond. [KJBII] Welcome back! Kevin's frustration with the IETF process is my fault for not providing adequate leadership. For that I apologize. It stems to some extent from a confusion of objectives in my own working life. That said: -- the IESG has been unwilling to expand the Megaco charter to include packages -- at this point, the IESG is ready to terminate the Working Group (BUT KEEP THE LIST). It is up to us to determine a working relationship with the ITU-T that will keep the work moving in everybody's best interest. I should point out that SG 16 itself is not having an easy time of it -- attendance has dropped drastically in the last couple of years. The ITU-T is approaching one of those intervals when it considers reorganization, and we could find ourselves dealing with a different Study Group next year. I'll ask a couple of questions to shape discussion of how we should proceed from here: -- It seems self-evident to me that the Megaco list should continue to be the primary source of material for the Implementor's Guide. Any disagreement? [KJBII] The list has always been the definitive source, so I see no reason to change this. -- Should we ask the ITU-T to allow us to derive I-Ds from new ITU-T Annexes so they can be reviewed by IETF process? I did that sort of transcription early on, but didn't continue because I wasn't sure our agreement with the ITU-T allowed it. [KJBII] I believe we should. Would the IETF allow the annexes to become standards track docs? -- Package documents in general have been individual drafts, since we couldn't add them to the WG charter. This means the authors were free to submit them to the IESG without my intervention. With that in mind, does anyone believe that there is an IETF role for creation of package documents independently of the ITU-T? [KJBII] Since nothing stops anyone from creating a package, I do not see where this would be a problem. However(!), it seems to me that the mandate for standardizing packages has fallen to the ITU. So, I would think that if someone wants to create a package and publish it informationally, then the IETF is fine. If they would like to take it forward as a standard way of performing whatever the package does, then it goes through the ITU. Michael DiGioia wrote: > Kevin, > >>> IETF does not seem interested in standardizing any packages. > > > I don't believe I understand your comment. For many years the IETF has > had a well know process of making protocols into drafts and then into > approved standard RFC specifications. Do you imply by this that we > should trash IETF? I would think not since we produced the Internet as > it exists today. > >> From a telephony standpoint, I think I can see your point since the >> ITU is > > the standards body for the telephony world. However, its a closed > organization that tends to be run by the large telephone companies - > i.e., not open to world participation without the necessary fees. > > This whole idea was accepted by this group back in 99/00 to have > concurrent standards. Are we all now in agreement that this was a > mistake? I was with the minority then against this idea and for a quick > standard, produced by only the IETF, since this is how we (IETF) have > been so successful in the past. > > I produced for my company the first IpTelephone which was at the first > Bakeoff in NH. However, by that time, the idea of an IpTelephone using > the media gateway protocols was not accepted by the larger community. > > Where is Vince, Tom, and Brian now? > > /mpd > > > > > > >> From: "Kevin Boyle" >> To: Michael DiGioia , >> kengr@winphoria.com, Christian.Groves@ericsson.com.au, megaco@ietf.org >> CC: bsteinka@telica.com >> Subject: RE: [Megaco] Megaco CAS support >> Date: Tue, 22 Apr 2003 17:26:15 -0400 >> >> With all due respect, the IETF had its chance to progress these (and >> many >> other) packages. In the interests of the larger community, I have >> taken the >> packages to the ITU for standardization, since the IETF does not seem >> interested in standardizing any packages. >> >> The work in the IETF is not "up and running". The drafts published >> by Hughes were published after the CAS packages were submitted to the >> ITU. >> >> Given that the working group is in the process of winding down, I do >> not see >> any benefit to anyone in continuing to allow the IETF to hold up >> standardization when the ITU is prepared to consider and advance the >> work. >> >> Kevin >> >> -----Original Message----- >> From: Michael DiGioia [mailto:michaeldigioia@hotmail.com] >> Sent: Tuesday, April 22, 2003 5:01 PM >> To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; >> megaco@ietf.org >> Cc: bsteinka@telica.com >> Subject: Re: [Megaco] Megaco CAS support >> >> >> >> Christian, >> >> I agree, CAS should be part of the IETF similar to the original >> MEGACO >> draft >> >> work that held both organizations in sync. >> >> /mpd >> >> >> >> >> >From: Aleksandr Ryabin >> >To: Christian Groves , >> >megaco@ietf.org >> >CC: Brad Steinka >> >Subject: Re: [Megaco] Megaco CAS support >> >Date: Tue, 22 Apr 2003 10:30:01 -0400 >> > >> >Hi Christian, >> > >> >Then why are these brand new revisions of drafts were just recently >> >submitted? >> > >> >http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.t >> >xt >> >http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt >> > >> >More over a quick look through reveals that some of the package >> >items in icas >> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same >> >wording. >> > >> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary >> >which does not seem to be defined in the document and also >> >"conflicts" with above IETF "CAS Maintenance Package". >> > >> >There is also reference to r2 package in AVD-2316 nowhere found in >> >ITU. >> > >> >Also basic CAS packages draft still available at: >> >http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackag >> >e-0 >> >2.txt >> >but it is slightly different (outdated?) from AVD-2315 ITU version >> you have >> >> >specified. >> > >> >The recent submission of the above drafts had lead me to believe >> >that CAS work is still quite "up and running" in IETF. This is all >> >very confusing. When was it decided to move the work to ITU? Could >> >someone point me out to some references (in IETF) of that please? >> > >> >My two cents on this topic: CAS is not an isolated package and in my >> >opinion it would be much more productive to keep it on both channels >> >(ITU and >> IETF) >> >and in sync, similar to some other items done so far in >> >H.248/MEGACO. What other folks think about it? >> > >> >Also in any case can the authors of ITU and IETF CAS related >> >packages work together to come up with some kind of game plan and >> >post it to the list to avoid any further confusion and >> >inconsistencies? >> > >> >Thanks! >> > Aleks >> > >> >At 07:54 PM 4/21/2003, Christian Groves wrote: >> >>G'Day Brad and Karl, >> >> >> >>I believe the intention is to move the CAS work into the ITU. The >> >>contributions containing the latest drafts can be found at: >> >>ftp://standard.pictel.com/avc-site/0302_San/ >> >> >> >>AVD-2312 MF Tone Generation and Detection Packages >> >>AVD-2315 Basic CAS Packages >> >>AVD-2316 International CAS Packages >> >>AVD-2317 Enhanced Analog Line Packages >> >> >> >>Regards, Christian >> >> >> >>Brad Steinka wrote: >> >> > >> >> > There were several RFC draft document that described various >> >> > packages >> >>to >> >> > support CAS, R1, R2, BCAS, etc. >> >> > Most of these drafts have expired. >> >> > >> >> > Can anyone tell me what the latest RFCs are that support CAS >> >> > calls and >> >>where >> >> > they are in the standards process? >> >> > >> >> > Thanks >> >> > >> >> > Brad Steinka >> >> > Director - Software Engineering >> >> > 734 Forest Street, Building G, Suite 100 >> >> > Marlboro, Ma. 01752 >> >> > Tel: 508-480-0909 x154 >> >> > Email: bsteinka@telica.com >> >> > Web: www.telica.com >> >> > >> >> > _______________________________________________ >> >> > Megaco mailing list >> >> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco >> >>_______________________________________________ >> >>Megaco mailing list >> >>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco >> > >> >_______________________________________________ >> >Megaco mailing list >> >Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco >> >> >> _________________________________________________________________ >> MSN 8 with e-mail virus protection service: 2 months FREE* >> http://join.msn.com/?page=features/virus >> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco > > > > _________________________________________________________________ > The new MSN 8: smart spam protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue May 13 14:40:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23913 for ; Tue, 13 May 2003 14:40:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DI5iB16877; Tue, 13 May 2003 14:05:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DHxtB16522 for ; Tue, 13 May 2003 13:59:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23663 for ; Tue, 13 May 2003 14:33:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FecK-0006dN-00 for megaco@ietf.org; Tue, 13 May 2003 14:35:12 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19FecJ-0006dA-00 for megaco@ietf.org; Tue, 13 May 2003 14:35:11 -0400 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DIZID01200; Tue, 13 May 2003 14:35:18 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRL1VTMY; Tue, 13 May 2003 14:35:18 -0400 Received: from nortelnetworks.com (acart1cc.ca.nortel.com [47.129.129.55]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA02HT; Tue, 13 May 2003 14:35:18 -0400 Message-ID: <3EC13AE1.8080106@nortelnetworks.com> Date: Tue, 13 May 2003 14:35:13 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Adrian Soncodi CC: Fernando Vallejo Lazaro , megaco@ietf.org Subject: Re: [Megaco] Support for redundant MG failover References: <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com> <3EA98F66.C6890B54@motorola.com> <3EA99A2E.4DC6BD7D@cisco.com> <3EA9DC82.136119A3@motorola.com> <3EA9F2B5.FEBAA43@cisco.com> <3EACEC44.96FF416A@alcatel.es> <3EADAE09.1010600@tekelec.com> In-Reply-To: <3EADAE09.1010600@tekelec.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit It seems to me that the outlines of a solution have been sketched in Fernando's note. Al the information to support multi-homing and the associated behaviour can be introduced through a set of ROOT properties that can be either provisioned on the MG or set there after the initial control association has been established. Adrian Soncodi wrote: > > > Fernando Vallejo Lazaro wrote: > >> Hi, >> >> I agree with Flemming that Megaco should be based on UDP and TCP. >> SCTP is not widely deployed and can lead to problems of interoperability. >> I would leave it as optional. >> >> For me the control association is clearly defined and it is 1 >> association = 1 IP address. >> Why? Because the assocation is done through a ServiceChange Restart >> message which involves >> an IP address (in the MGC ID) and not a domain name. If the DNS >> returns more than >> one IP address for a given name the MG must choose one of them. >> > This is how one would be tempted to interpret the spec today, although > it is not explicitly stated. But as I have mentioned in a previous > e-mail, this is not adequate for SCTP, where one would like to know that > the 2 IP addresses are on the same machine, to be able to use them > within a single SCTP association. > > Also, the following quote from section 7.2.8 seems to indicate more than > 1 IP address is possible: > > "The ServiceChangeAddress provides an address to be used within the > Context of the association currently being negotiated ..." > > Since this is in the reply to ServiceChange, it looks like it can > actually be a different IP address (which then must be interpreted in > the context of the current association ...). Otherwise, why would the > MGC return the same IP address as the destination IP address of the > ServiceChange message? The MG already knows that one! > >> What I feel is that the gap is in the definition of the secondary MGCs >> and its provisionning. >> I think there should be a way in which the MGC could inform the MGs >> about existing secondaries >> MGCs. Now this can only be done using a HandOff method but sometimes >> this message cannot >> be sent by the primary MGC (e.g. network failure, crash of the MGC ...). >> So it would be useful to add a new method in the ServiceChange to send >> this information and add >> a new parameter indicating what type of relationship there is between >> primary and secondary >> (e.g. mirror, backup, independent, third party.....) >> So in case a MGC is multihomed it could inform the MG at startup that >> a MGC exists which is a >> secondary mirror MGC (which corresponds to the same MGC but with >> another IP address). >> This process can be independent on the actual procedures done by the >> operators to declare >> secondary MGCs. >> > I'm not sure a "mirror MGC" is the same MGC with another IP address. > Some people would interpret "mirrored" as different machines, with some > state synchronization between them... > > Anyway, considering 2 or more multi-homed MGCs, i.e. 4 or more IP > addresses, and if each IP address is a different MGC, then it becomes > quite cumbersome to signal which one is paired with which one. I think > it would be simpler and more clear to allow an MG to be provisioned with > more than one IP address per MGC. Then you would immediately know the > MGC is multi-homed. This works more elegantly with SCTP, and also with > DNS, which can return several IP addresses for an FQDN. > > Adrian > >> When a problem arises the MG can act in two ways: >> 1) If the new MGC is a mirror (maybe other types can be included here) >> it can resend the transactions >> which have failed in the old one. >> 2) If the new MGC is not a mirror it should try to establish a >> connection with a ServiceChange as defined >> in the megaco protocol. Then the MGC is in charge of recovering the >> state of the MG ASAP and the service. >> >> In this way not too much work has to be added and we can accomplish a >> solution. >> >> Regards >> Fernando >> >> >> Flemming Andreasen wrote: >> >>> Qiaobing >>> >>> Nobody is denying that SCTP is an existing spec that solves the >>> multihoming problem and it >>> is quite understandable that you in particular advocate it. However, >>> you seem to have lost >>> sight of the original question in this thread, which was about native >>> Megaco protocol >>> support for redundancy and failover, and as part of that, support for >>> multihoming. Initial >>> claims was that Megaco fully supports this, but we seem to have >>> converged on the opinion >>> that it does not, unless you use SCTP, which is not part of the base >>> Megaco protocol. >>> Furthermore, despite everything, the fact of the matter is that for >>> various reasons, not >>> everybody will be implementing SCTP at least for now (NATs, firewalls >>> and security do not >>> help SCTP here) and since UDP and TCP are the basic requirements, it >>> would have been nice to >>> have better mechanisms for these; it can be done very easily (see >>> MGCP for example). >>> Sometimes, it's good to be a bit pragmatic. >>> >>> -- Flemming >>> >>> Qiaobing Xie wrote: >>> >>> > (Try to respond to similar remarks from two mails) >>> > >>> > Flemming Andreasen wrote: >>> > ... >>> > > In any case, SCTP is there as an option today for those >>> > > that wish to use it. For those that don't, we've already >>> concluded that >>> > > multihoming/redundancy/failover is not very well supported, and >>> that there doesn't >>> > > seem to be much desire to change that. I personally think that's >>> a bit of a shame, but >>> > > so be it. >>> > ... >>> > >>> > Adrian Soncodi wrote: >>> > ... >>> > > You seem to say "if you want multi-homing, it must be only over >>> SCTP". >>> > > Why? Someone could similarly say "if you want MEGACO, it must be >>> over >>> > > UDP". But we don't, we allow all 3 protocols, for flexibility. >>> > > >>> > >>> > I didn't mean to say "you must". I was under the impression that >>> some of >>> > us were saying that we had a technical issue to support >>> multi-homing in >>> > MEGACO, and my response was essentially "this is not an issue, >>> there are >>> > protocol specs existing in IETF to do just that, which is >>> > MEGACO/H.248-Annex-H plus SCTP." Now, I think what I am hearing is, it >>> > is not really about the lack of a solution, it's more about that >>> some of >>> > us just don't want to use the existing IETF solution (for whatever >>> > non-tech reasons, or simply just don't wish to use it) and prefer to >>> > define another solution in IETF. Well, if that is the case, I don't >>> have >>> > much else to say... >>> > >>> > Of cause, if there are tech issues/shortcomings/drawbacks/advantages >>> > related to using SCTP for MEGACO multi-homing support, I'd be more >>> than >>> > glad to help answer. >>> > >>> > -Qiaobing >>> >> -- >> Fernando Vallejo Lazaro >> Phone: +34 91 330 5614 >> SW Wireline ASD-Madrid >> ALCATEL >> >> > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue May 13 14:41:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23974 for ; Tue, 13 May 2003 14:41:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DI85O17872 for megaco-archive@odin.ietf.org; Tue, 13 May 2003 14:08:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DI85B17869 for ; Tue, 13 May 2003 14:08:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23962 for ; Tue, 13 May 2003 14:41:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FekE-0006hj-00 for megaco-web-archive@ietf.org; Tue, 13 May 2003 14:43:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FekE-0006hg-00 for megaco-web-archive@ietf.org; Tue, 13 May 2003 14:43:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DI5iB16877; Tue, 13 May 2003 14:05:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DHxtB16522 for ; Tue, 13 May 2003 13:59:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23663 for ; Tue, 13 May 2003 14:33:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FecK-0006dN-00 for megaco@ietf.org; Tue, 13 May 2003 14:35:12 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19FecJ-0006dA-00 for megaco@ietf.org; Tue, 13 May 2003 14:35:11 -0400 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DIZID01200; Tue, 13 May 2003 14:35:18 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRL1VTMY; Tue, 13 May 2003 14:35:18 -0400 Received: from nortelnetworks.com (acart1cc.ca.nortel.com [47.129.129.55]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA02HT; Tue, 13 May 2003 14:35:18 -0400 Message-ID: <3EC13AE1.8080106@nortelnetworks.com> Date: Tue, 13 May 2003 14:35:13 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Adrian Soncodi CC: Fernando Vallejo Lazaro , megaco@ietf.org Subject: Re: [Megaco] Support for redundant MG failover References: <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com> <3EA98F66.C6890B54@motorola.com> <3EA99A2E.4DC6BD7D@cisco.com> <3EA9DC82.136119A3@motorola.com> <3EA9F2B5.FEBAA43@cisco.com> <3EACEC44.96FF416A@alcatel.es> <3EADAE09.1010600@tekelec.com> In-Reply-To: <3EADAE09.1010600@tekelec.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It seems to me that the outlines of a solution have been sketched in Fernando's note. Al the information to support multi-homing and the associated behaviour can be introduced through a set of ROOT properties that can be either provisioned on the MG or set there after the initial control association has been established. Adrian Soncodi wrote: > > > Fernando Vallejo Lazaro wrote: > >> Hi, >> >> I agree with Flemming that Megaco should be based on UDP and TCP. >> SCTP is not widely deployed and can lead to problems of interoperability. >> I would leave it as optional. >> >> For me the control association is clearly defined and it is 1 >> association = 1 IP address. >> Why? Because the assocation is done through a ServiceChange Restart >> message which involves >> an IP address (in the MGC ID) and not a domain name. If the DNS >> returns more than >> one IP address for a given name the MG must choose one of them. >> > This is how one would be tempted to interpret the spec today, although > it is not explicitly stated. But as I have mentioned in a previous > e-mail, this is not adequate for SCTP, where one would like to know that > the 2 IP addresses are on the same machine, to be able to use them > within a single SCTP association. > > Also, the following quote from section 7.2.8 seems to indicate more than > 1 IP address is possible: > > "The ServiceChangeAddress provides an address to be used within the > Context of the association currently being negotiated ..." > > Since this is in the reply to ServiceChange, it looks like it can > actually be a different IP address (which then must be interpreted in > the context of the current association ...). Otherwise, why would the > MGC return the same IP address as the destination IP address of the > ServiceChange message? The MG already knows that one! > >> What I feel is that the gap is in the definition of the secondary MGCs >> and its provisionning. >> I think there should be a way in which the MGC could inform the MGs >> about existing secondaries >> MGCs. Now this can only be done using a HandOff method but sometimes >> this message cannot >> be sent by the primary MGC (e.g. network failure, crash of the MGC ...). >> So it would be useful to add a new method in the ServiceChange to send >> this information and add >> a new parameter indicating what type of relationship there is between >> primary and secondary >> (e.g. mirror, backup, independent, third party.....) >> So in case a MGC is multihomed it could inform the MG at startup that >> a MGC exists which is a >> secondary mirror MGC (which corresponds to the same MGC but with >> another IP address). >> This process can be independent on the actual procedures done by the >> operators to declare >> secondary MGCs. >> > I'm not sure a "mirror MGC" is the same MGC with another IP address. > Some people would interpret "mirrored" as different machines, with some > state synchronization between them... > > Anyway, considering 2 or more multi-homed MGCs, i.e. 4 or more IP > addresses, and if each IP address is a different MGC, then it becomes > quite cumbersome to signal which one is paired with which one. I think > it would be simpler and more clear to allow an MG to be provisioned with > more than one IP address per MGC. Then you would immediately know the > MGC is multi-homed. This works more elegantly with SCTP, and also with > DNS, which can return several IP addresses for an FQDN. > > Adrian > >> When a problem arises the MG can act in two ways: >> 1) If the new MGC is a mirror (maybe other types can be included here) >> it can resend the transactions >> which have failed in the old one. >> 2) If the new MGC is not a mirror it should try to establish a >> connection with a ServiceChange as defined >> in the megaco protocol. Then the MGC is in charge of recovering the >> state of the MG ASAP and the service. >> >> In this way not too much work has to be added and we can accomplish a >> solution. >> >> Regards >> Fernando >> >> >> Flemming Andreasen wrote: >> >>> Qiaobing >>> >>> Nobody is denying that SCTP is an existing spec that solves the >>> multihoming problem and it >>> is quite understandable that you in particular advocate it. However, >>> you seem to have lost >>> sight of the original question in this thread, which was about native >>> Megaco protocol >>> support for redundancy and failover, and as part of that, support for >>> multihoming. Initial >>> claims was that Megaco fully supports this, but we seem to have >>> converged on the opinion >>> that it does not, unless you use SCTP, which is not part of the base >>> Megaco protocol. >>> Furthermore, despite everything, the fact of the matter is that for >>> various reasons, not >>> everybody will be implementing SCTP at least for now (NATs, firewalls >>> and security do not >>> help SCTP here) and since UDP and TCP are the basic requirements, it >>> would have been nice to >>> have better mechanisms for these; it can be done very easily (see >>> MGCP for example). >>> Sometimes, it's good to be a bit pragmatic. >>> >>> -- Flemming >>> >>> Qiaobing Xie wrote: >>> >>> > (Try to respond to similar remarks from two mails) >>> > >>> > Flemming Andreasen wrote: >>> > ... >>> > > In any case, SCTP is there as an option today for those >>> > > that wish to use it. For those that don't, we've already >>> concluded that >>> > > multihoming/redundancy/failover is not very well supported, and >>> that there doesn't >>> > > seem to be much desire to change that. I personally think that's >>> a bit of a shame, but >>> > > so be it. >>> > ... >>> > >>> > Adrian Soncodi wrote: >>> > ... >>> > > You seem to say "if you want multi-homing, it must be only over >>> SCTP". >>> > > Why? Someone could similarly say "if you want MEGACO, it must be >>> over >>> > > UDP". But we don't, we allow all 3 protocols, for flexibility. >>> > > >>> > >>> > I didn't mean to say "you must". I was under the impression that >>> some of >>> > us were saying that we had a technical issue to support >>> multi-homing in >>> > MEGACO, and my response was essentially "this is not an issue, >>> there are >>> > protocol specs existing in IETF to do just that, which is >>> > MEGACO/H.248-Annex-H plus SCTP." Now, I think what I am hearing is, it >>> > is not really about the lack of a solution, it's more about that >>> some of >>> > us just don't want to use the existing IETF solution (for whatever >>> > non-tech reasons, or simply just don't wish to use it) and prefer to >>> > define another solution in IETF. Well, if that is the case, I don't >>> have >>> > much else to say... >>> > >>> > Of cause, if there are tech issues/shortcomings/drawbacks/advantages >>> > related to using SCTP for MEGACO multi-homing support, I'd be more >>> than >>> > glad to help answer. >>> > >>> > -Qiaobing >>> >> -- >> Fernando Vallejo Lazaro >> Phone: +34 91 330 5614 >> SW Wireline ASD-Madrid >> ALCATEL >> >> > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue May 13 14:56:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24465 for ; Tue, 13 May 2003 14:56:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DILFB18632; Tue, 13 May 2003 14:21:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DI7wB17860 for ; Tue, 13 May 2003 14:07:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23956 for ; Tue, 13 May 2003 14:41:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fek7-0006hb-00 for megaco@ietf.org; Tue, 13 May 2003 14:43:15 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19Fek7-0006hT-00 for megaco@ietf.org; Tue, 13 May 2003 14:43:15 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DIhgs03646; Tue, 13 May 2003 14:43:42 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLFSKF4; Tue, 13 May 2003 14:43:42 -0400 Received: from nortelnetworks.com (acart1cc.ca.nortel.com [47.129.129.55]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA02H7; Tue, 13 May 2003 14:43:42 -0400 Message-ID: <3EC13CD9.30707@nortelnetworks.com> Date: Tue, 13 May 2003 14:43:37 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: bs@utstar.com CC: megaco@ietf.org Subject: Re: [Megaco] I-D ACTION:draft-ietf-megaco-mib-05.txt References: <002c01c310d0$6679b4c0$2b2810ac@balanew> In-Reply-To: <002c01c310d0$6679b4c0$2b2810ac@balanew> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks for your hard work, Bala and all. It would be good if we could take this to Last Call shortly. I'll look forward to doing that at the beginning of June unless reasons appear to prevent it. Balasubramanian Pitchandi wrote: > Folks, > > Thanks to all those who provided extensive comments on the Megaco MIB. The > next revision of the draft is now available. > > The major differences to the older draft include: > > 1. Added medGwyGatewayControllerId as an additional index to the > medGwyGatewayControllerTable. > 2. Modified the usage of TimeTicks to TimeStamp which is now being > widely used and is more useful. > 3. Converted the Integer32's to Unsigned32 wherever appropriate. > 4. Added few more Textual Conventions that could be imported to vendor > specific MIBs. > 5. Corrected few MIB syntax errors. > 6. Reformatted the entire document to be compliant with the new IETF > MIB guidelines from draft-ietf-ops-mib-review-guidelines-01.txt > > I have made sure that the MIB is backward compatible at most of the places > so that the existing implementations are not affected that much. > > Please review the MIB and let me know if there are any comments/questions. > > Thanks, > Bala > > -----Original Message----- > From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Wednesday, April 30, 2003 6:29 AM > To: IETF-Announce: > Cc: megaco@ietf.org > Subject: [Megaco] I-D ACTION:draft-ietf-megaco-mib-05.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Media Gateway Control Working Group of the > IETF. > > Title : Megaco MIB > Author(s) : B. Pitchandi, I. Akramovich, C. Brown, M. Holdrege > Filename : draft-ietf-megaco-mib-05.txt > Pages : 35 > Date : 2003-4-29 > > This memo defines a portion of the Management Information Base (MIB) for use > with network management protocols in the Internet community. In particular, > it defines objects for use by the MEGACO/H.248 protocol operating on Media > Gateways and Media Gateway Controllers. These objects can be used to manage > the network containing Media Gateways and Media Gateway Controllers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-megaco-mib-05.txt > ... _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue May 13 14:57:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24519 for ; Tue, 13 May 2003 14:57:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DINPV18951 for megaco-archive@odin.ietf.org; Tue, 13 May 2003 14:23:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DINPB18948 for ; Tue, 13 May 2003 14:23:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24499 for ; Tue, 13 May 2003 14:56:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fez4-0006qa-00 for megaco-web-archive@ietf.org; Tue, 13 May 2003 14:58:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Fez3-0006qX-00 for megaco-web-archive@ietf.org; Tue, 13 May 2003 14:58:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DILFB18632; Tue, 13 May 2003 14:21:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DI7wB17860 for ; Tue, 13 May 2003 14:07:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23956 for ; Tue, 13 May 2003 14:41:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fek7-0006hb-00 for megaco@ietf.org; Tue, 13 May 2003 14:43:15 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19Fek7-0006hT-00 for megaco@ietf.org; Tue, 13 May 2003 14:43:15 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DIhgs03646; Tue, 13 May 2003 14:43:42 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLFSKF4; Tue, 13 May 2003 14:43:42 -0400 Received: from nortelnetworks.com (acart1cc.ca.nortel.com [47.129.129.55]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA02H7; Tue, 13 May 2003 14:43:42 -0400 Message-ID: <3EC13CD9.30707@nortelnetworks.com> Date: Tue, 13 May 2003 14:43:37 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: bs@utstar.com CC: megaco@ietf.org Subject: Re: [Megaco] I-D ACTION:draft-ietf-megaco-mib-05.txt References: <002c01c310d0$6679b4c0$2b2810ac@balanew> In-Reply-To: <002c01c310d0$6679b4c0$2b2810ac@balanew> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for your hard work, Bala and all. It would be good if we could take this to Last Call shortly. I'll look forward to doing that at the beginning of June unless reasons appear to prevent it. Balasubramanian Pitchandi wrote: > Folks, > > Thanks to all those who provided extensive comments on the Megaco MIB. The > next revision of the draft is now available. > > The major differences to the older draft include: > > 1. Added medGwyGatewayControllerId as an additional index to the > medGwyGatewayControllerTable. > 2. Modified the usage of TimeTicks to TimeStamp which is now being > widely used and is more useful. > 3. Converted the Integer32's to Unsigned32 wherever appropriate. > 4. Added few more Textual Conventions that could be imported to vendor > specific MIBs. > 5. Corrected few MIB syntax errors. > 6. Reformatted the entire document to be compliant with the new IETF > MIB guidelines from draft-ietf-ops-mib-review-guidelines-01.txt > > I have made sure that the MIB is backward compatible at most of the places > so that the existing implementations are not affected that much. > > Please review the MIB and let me know if there are any comments/questions. > > Thanks, > Bala > > -----Original Message----- > From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Wednesday, April 30, 2003 6:29 AM > To: IETF-Announce: > Cc: megaco@ietf.org > Subject: [Megaco] I-D ACTION:draft-ietf-megaco-mib-05.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Media Gateway Control Working Group of the > IETF. > > Title : Megaco MIB > Author(s) : B. Pitchandi, I. Akramovich, C. Brown, M. Holdrege > Filename : draft-ietf-megaco-mib-05.txt > Pages : 35 > Date : 2003-4-29 > > This memo defines a portion of the Management Information Base (MIB) for use > with network management protocols in the Internet community. In particular, > it defines objects for use by the MEGACO/H.248 protocol operating on Media > Gateways and Media Gateway Controllers. These objects can be used to manage > the network containing Media Gateways and Media Gateway Controllers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-megaco-mib-05.txt > ... _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue May 13 16:28:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28129 for ; Tue, 13 May 2003 16:28:30 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DJrIB25765; Tue, 13 May 2003 15:53:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DJp9B25682 for ; Tue, 13 May 2003 15:51:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28069 for ; Tue, 13 May 2003 16:24:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FgLw-0007Ng-00 for megaco@ietf.org; Tue, 13 May 2003 16:26:24 -0400 Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com) by ietf-mx with esmtp (Exim 4.12) id 19FgLv-0007ND-00 for megaco@ietf.org; Tue, 13 May 2003 16:26:24 -0400 Received: from tekelec.com ([172.25.11.41]) by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12) with ESMTP id 2003051315265885:1013 ; Tue, 13 May 2003 15:26:58 -0500 Message-ID: <3EC156C0.4040300@tekelec.com> Date: Tue, 13 May 2003 15:34:08 -0500 From: Adrian Soncodi User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Tom Taylor CC: Fernando Vallejo Lazaro , megaco@ietf.org Subject: Re: [Megaco] Support for redundant MG failover References: <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com> <3EA98F66.C6890B54@motorola.com> <3EA99A2E.4DC6BD7D@cisco.com> <3EA9DC82.136119A3@motorola.com> <3EA9F2B5.FEBAA43@cisco.com> <3EACEC44.96FF416A@alcatel.es> <3EADAE09.1010600@tekelec.com> <3EC13AE1.8080106@nortelnetworks.com> X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12 |February 13, 2003) at 05/13/2003 03:26:58 PM, Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12 |February 13, 2003) at 05/13/2003 03:27:30 PM, Serialize complete at 05/13/2003 03:27:30 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tom Taylor wrote: > It seems to me that the outlines of a solution have been sketched in > Fernando's note. Tom, I don't quite understand, can you elaborate on this statement? I was trying to make the point that, for multi-homing, we could allow 2 or more IP addresses per MG and/or MGC, which would make it simpler to establish for example one SCTP association using all of them. Initially, Fernando said that 1 MEGACO control association = 1 IP address, and implied that 2 IP addresses would be viewed as 2 distinct MGCs. But in this case: - explaining which MGC pairs with which other MGC as multi-homed entities is more difficult, - plus, if an SCTP association uses more than 1 IP address (which it should, in order to take advantage of multi-homing), then it would mean that 1 control association spans 2 MGCs, which seems to contradict the model. Handoff and failover wouldn't work in this case, because MEGACO does not control the selection of the IP addresses withing the SCTP layer. Therefore, what do you think about the number of IP addresses per MG/MGC? If SCTP is allowed to use only one IP address per entity, then why would one ever use SCTP instead of TCP? My understanding is SCTP was supposed to be a solution for multi-homing. Additionally (I don't know if you followed the whole discussion in this thread), a number of people have expressed interest in supporting multi-homing over UDP too. This would also benefit from allowing multiple IP addresses per MG/MGC, but a few clarification in the procedures would be required. Would you be willing to consider adding this additional functionality? Regards, Adrian > Al the information to support multi-homing and the associated > behaviour can be introduced through a set of ROOT properties that can > be either provisioned on the MG or set there after the initial control > association has been established. > > > Adrian Soncodi wrote: > >> >> >> Fernando Vallejo Lazaro wrote: >> >>> Hi, >>> >>> I agree with Flemming that Megaco should be based on UDP and TCP. >>> SCTP is not widely deployed and can lead to problems of >>> interoperability. >>> I would leave it as optional. >>> >>> For me the control association is clearly defined and it is 1 >>> association = 1 IP address. >>> Why? Because the assocation is done through a ServiceChange Restart >>> message which involves >>> an IP address (in the MGC ID) and not a domain name. If the DNS >>> returns more than >>> one IP address for a given name the MG must choose one of them. >>> >> This is how one would be tempted to interpret the spec today, >> although it is not explicitly stated. But as I have mentioned in a >> previous e-mail, this is not adequate for SCTP, where one would like >> to know that the 2 IP addresses are on the same machine, to be able >> to use them within a single SCTP association. >> >> Also, the following quote from section 7.2.8 seems to indicate more >> than 1 IP address is possible: >> >> "The ServiceChangeAddress provides an address to be used within the >> Context of the association currently being negotiated ..." >> >> Since this is in the reply to ServiceChange, it looks like it can >> actually be a different IP address (which then must be interpreted in >> the context of the current association ...). Otherwise, why would the >> MGC return the same IP address as the destination IP address of the >> ServiceChange message? The MG already knows that one! >> >>> What I feel is that the gap is in the definition of the secondary >>> MGCs and its provisionning. >>> I think there should be a way in which the MGC could inform the MGs >>> about existing secondaries >>> MGCs. Now this can only be done using a HandOff method but >>> sometimes this message cannot >>> be sent by the primary MGC (e.g. network failure, crash of the MGC >>> ...). >>> So it would be useful to add a new method in the ServiceChange to >>> send this information and add >>> a new parameter indicating what type of relationship there is >>> between primary and secondary >>> (e.g. mirror, backup, independent, third party.....) >>> So in case a MGC is multihomed it could inform the MG at startup >>> that a MGC exists which is a >>> secondary mirror MGC (which corresponds to the same MGC but with >>> another IP address). >>> This process can be independent on the actual procedures done by the >>> operators to declare >>> secondary MGCs. >>> >> I'm not sure a "mirror MGC" is the same MGC with another IP address. >> Some people would interpret "mirrored" as different machines, with >> some state synchronization between them... >> >> Anyway, considering 2 or more multi-homed MGCs, i.e. 4 or more IP >> addresses, and if each IP address is a different MGC, then it becomes >> quite cumbersome to signal which one is paired with which one. I >> think it would be simpler and more clear to allow an MG to be >> provisioned with more than one IP address per MGC. Then you would >> immediately know the MGC is multi-homed. This works more elegantly >> with SCTP, and also with DNS, which can return several IP addresses >> for an FQDN. >> >> Adrian >> >>> When a problem arises the MG can act in two ways: >>> 1) If the new MGC is a mirror (maybe other types can be included >>> here) it can resend the transactions >>> which have failed in the old one. >>> 2) If the new MGC is not a mirror it should try to establish a >>> connection with a ServiceChange as defined >>> in the megaco protocol. Then the MGC is in charge of recovering the >>> state of the MG ASAP and the service. >>> >>> In this way not too much work has to be added and we can accomplish >>> a solution. >>> >>> Regards >>> Fernando >>> >>> >>> Flemming Andreasen wrote: >>> >>>> Qiaobing >>>> >>>> Nobody is denying that SCTP is an existing spec that solves the >>>> multihoming problem and it >>>> is quite understandable that you in particular advocate it. >>>> However, you seem to have lost >>>> sight of the original question in this thread, which was about >>>> native Megaco protocol >>>> support for redundancy and failover, and as part of that, support >>>> for multihoming. Initial >>>> claims was that Megaco fully supports this, but we seem to have >>>> converged on the opinion >>>> that it does not, unless you use SCTP, which is not part of the >>>> base Megaco protocol. >>>> Furthermore, despite everything, the fact of the matter is that for >>>> various reasons, not >>>> everybody will be implementing SCTP at least for now (NATs, >>>> firewalls and security do not >>>> help SCTP here) and since UDP and TCP are the basic requirements, >>>> it would have been nice to >>>> have better mechanisms for these; it can be done very easily (see >>>> MGCP for example). >>>> Sometimes, it's good to be a bit pragmatic. >>>> >>>> -- Flemming >>>> >>>> Qiaobing Xie wrote: >>>> >>>> > (Try to respond to similar remarks from two mails) >>>> > >>>> > Flemming Andreasen wrote: >>>> > ... >>>> > > In any case, SCTP is there as an option today for those >>>> > > that wish to use it. For those that don't, we've already >>>> concluded that >>>> > > multihoming/redundancy/failover is not very well supported, and >>>> that there doesn't >>>> > > seem to be much desire to change that. I personally think >>>> that's a bit of a shame, but >>>> > > so be it. >>>> > ... >>>> > >>>> > Adrian Soncodi wrote: >>>> > ... >>>> > > You seem to say "if you want multi-homing, it must be only over >>>> SCTP". >>>> > > Why? Someone could similarly say "if you want MEGACO, it must >>>> be over >>>> > > UDP". But we don't, we allow all 3 protocols, for flexibility. >>>> > > >>>> > >>>> > I didn't mean to say "you must". I was under the impression that >>>> some of >>>> > us were saying that we had a technical issue to support >>>> multi-homing in >>>> > MEGACO, and my response was essentially "this is not an issue, >>>> there are >>>> > protocol specs existing in IETF to do just that, which is >>>> > MEGACO/H.248-Annex-H plus SCTP." Now, I think what I am hearing >>>> is, it >>>> > is not really about the lack of a solution, it's more about that >>>> some of >>>> > us just don't want to use the existing IETF solution (for whatever >>>> > non-tech reasons, or simply just don't wish to use it) and prefer to >>>> > define another solution in IETF. Well, if that is the case, I >>>> don't have >>>> > much else to say... >>>> > >>>> > Of cause, if there are tech issues/shortcomings/drawbacks/advantages >>>> > related to using SCTP for MEGACO multi-homing support, I'd be >>>> more than >>>> > glad to help answer. >>>> > >>>> > -Qiaobing >>>> >>> -- >>> Fernando Vallejo Lazaro >>> Phone: +34 91 330 5614 >>> SW Wireline ASD-Madrid >>> ALCATEL >>> >>> >> >> >> >> >> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue May 13 16:29:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28155 for ; Tue, 13 May 2003 16:29:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DJtuY25918 for megaco-archive@odin.ietf.org; Tue, 13 May 2003 15:55:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DJttB25915 for ; Tue, 13 May 2003 15:55:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28150 for ; Tue, 13 May 2003 16:29:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FgQY-0007P7-00 for megaco-web-archive@ietf.org; Tue, 13 May 2003 16:31:10 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FgQY-0007P4-00 for megaco-web-archive@ietf.org; Tue, 13 May 2003 16:31:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DJrIB25765; Tue, 13 May 2003 15:53:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DJp9B25682 for ; Tue, 13 May 2003 15:51:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28069 for ; Tue, 13 May 2003 16:24:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FgLw-0007Ng-00 for megaco@ietf.org; Tue, 13 May 2003 16:26:24 -0400 Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com) by ietf-mx with esmtp (Exim 4.12) id 19FgLv-0007ND-00 for megaco@ietf.org; Tue, 13 May 2003 16:26:24 -0400 Received: from tekelec.com ([172.25.11.41]) by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12) with ESMTP id 2003051315265885:1013 ; Tue, 13 May 2003 15:26:58 -0500 Message-ID: <3EC156C0.4040300@tekelec.com> Date: Tue, 13 May 2003 15:34:08 -0500 From: Adrian Soncodi User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Tom Taylor CC: Fernando Vallejo Lazaro , megaco@ietf.org Subject: Re: [Megaco] Support for redundant MG failover References: <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com> <3EA98F66.C6890B54@motorola.com> <3EA99A2E.4DC6BD7D@cisco.com> <3EA9DC82.136119A3@motorola.com> <3EA9F2B5.FEBAA43@cisco.com> <3EACEC44.96FF416A@alcatel.es> <3EADAE09.1010600@tekelec.com> <3EC13AE1.8080106@nortelnetworks.com> X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12 |February 13, 2003) at 05/13/2003 03:26:58 PM, Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12 |February 13, 2003) at 05/13/2003 03:27:30 PM, Serialize complete at 05/13/2003 03:27:30 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tom Taylor wrote: > It seems to me that the outlines of a solution have been sketched in > Fernando's note. Tom, I don't quite understand, can you elaborate on this statement? I was trying to make the point that, for multi-homing, we could allow 2 or more IP addresses per MG and/or MGC, which would make it simpler to establish for example one SCTP association using all of them. Initially, Fernando said that 1 MEGACO control association = 1 IP address, and implied that 2 IP addresses would be viewed as 2 distinct MGCs. But in this case: - explaining which MGC pairs with which other MGC as multi-homed entities is more difficult, - plus, if an SCTP association uses more than 1 IP address (which it should, in order to take advantage of multi-homing), then it would mean that 1 control association spans 2 MGCs, which seems to contradict the model. Handoff and failover wouldn't work in this case, because MEGACO does not control the selection of the IP addresses withing the SCTP layer. Therefore, what do you think about the number of IP addresses per MG/MGC? If SCTP is allowed to use only one IP address per entity, then why would one ever use SCTP instead of TCP? My understanding is SCTP was supposed to be a solution for multi-homing. Additionally (I don't know if you followed the whole discussion in this thread), a number of people have expressed interest in supporting multi-homing over UDP too. This would also benefit from allowing multiple IP addresses per MG/MGC, but a few clarification in the procedures would be required. Would you be willing to consider adding this additional functionality? Regards, Adrian > Al the information to support multi-homing and the associated > behaviour can be introduced through a set of ROOT properties that can > be either provisioned on the MG or set there after the initial control > association has been established. > > > Adrian Soncodi wrote: > >> >> >> Fernando Vallejo Lazaro wrote: >> >>> Hi, >>> >>> I agree with Flemming that Megaco should be based on UDP and TCP. >>> SCTP is not widely deployed and can lead to problems of >>> interoperability. >>> I would leave it as optional. >>> >>> For me the control association is clearly defined and it is 1 >>> association = 1 IP address. >>> Why? Because the assocation is done through a ServiceChange Restart >>> message which involves >>> an IP address (in the MGC ID) and not a domain name. If the DNS >>> returns more than >>> one IP address for a given name the MG must choose one of them. >>> >> This is how one would be tempted to interpret the spec today, >> although it is not explicitly stated. But as I have mentioned in a >> previous e-mail, this is not adequate for SCTP, where one would like >> to know that the 2 IP addresses are on the same machine, to be able >> to use them within a single SCTP association. >> >> Also, the following quote from section 7.2.8 seems to indicate more >> than 1 IP address is possible: >> >> "The ServiceChangeAddress provides an address to be used within the >> Context of the association currently being negotiated ..." >> >> Since this is in the reply to ServiceChange, it looks like it can >> actually be a different IP address (which then must be interpreted in >> the context of the current association ...). Otherwise, why would the >> MGC return the same IP address as the destination IP address of the >> ServiceChange message? The MG already knows that one! >> >>> What I feel is that the gap is in the definition of the secondary >>> MGCs and its provisionning. >>> I think there should be a way in which the MGC could inform the MGs >>> about existing secondaries >>> MGCs. Now this can only be done using a HandOff method but >>> sometimes this message cannot >>> be sent by the primary MGC (e.g. network failure, crash of the MGC >>> ...). >>> So it would be useful to add a new method in the ServiceChange to >>> send this information and add >>> a new parameter indicating what type of relationship there is >>> between primary and secondary >>> (e.g. mirror, backup, independent, third party.....) >>> So in case a MGC is multihomed it could inform the MG at startup >>> that a MGC exists which is a >>> secondary mirror MGC (which corresponds to the same MGC but with >>> another IP address). >>> This process can be independent on the actual procedures done by the >>> operators to declare >>> secondary MGCs. >>> >> I'm not sure a "mirror MGC" is the same MGC with another IP address. >> Some people would interpret "mirrored" as different machines, with >> some state synchronization between them... >> >> Anyway, considering 2 or more multi-homed MGCs, i.e. 4 or more IP >> addresses, and if each IP address is a different MGC, then it becomes >> quite cumbersome to signal which one is paired with which one. I >> think it would be simpler and more clear to allow an MG to be >> provisioned with more than one IP address per MGC. Then you would >> immediately know the MGC is multi-homed. This works more elegantly >> with SCTP, and also with DNS, which can return several IP addresses >> for an FQDN. >> >> Adrian >> >>> When a problem arises the MG can act in two ways: >>> 1) If the new MGC is a mirror (maybe other types can be included >>> here) it can resend the transactions >>> which have failed in the old one. >>> 2) If the new MGC is not a mirror it should try to establish a >>> connection with a ServiceChange as defined >>> in the megaco protocol. Then the MGC is in charge of recovering the >>> state of the MG ASAP and the service. >>> >>> In this way not too much work has to be added and we can accomplish >>> a solution. >>> >>> Regards >>> Fernando >>> >>> >>> Flemming Andreasen wrote: >>> >>>> Qiaobing >>>> >>>> Nobody is denying that SCTP is an existing spec that solves the >>>> multihoming problem and it >>>> is quite understandable that you in particular advocate it. >>>> However, you seem to have lost >>>> sight of the original question in this thread, which was about >>>> native Megaco protocol >>>> support for redundancy and failover, and as part of that, support >>>> for multihoming. Initial >>>> claims was that Megaco fully supports this, but we seem to have >>>> converged on the opinion >>>> that it does not, unless you use SCTP, which is not part of the >>>> base Megaco protocol. >>>> Furthermore, despite everything, the fact of the matter is that for >>>> various reasons, not >>>> everybody will be implementing SCTP at least for now (NATs, >>>> firewalls and security do not >>>> help SCTP here) and since UDP and TCP are the basic requirements, >>>> it would have been nice to >>>> have better mechanisms for these; it can be done very easily (see >>>> MGCP for example). >>>> Sometimes, it's good to be a bit pragmatic. >>>> >>>> -- Flemming >>>> >>>> Qiaobing Xie wrote: >>>> >>>> > (Try to respond to similar remarks from two mails) >>>> > >>>> > Flemming Andreasen wrote: >>>> > ... >>>> > > In any case, SCTP is there as an option today for those >>>> > > that wish to use it. For those that don't, we've already >>>> concluded that >>>> > > multihoming/redundancy/failover is not very well supported, and >>>> that there doesn't >>>> > > seem to be much desire to change that. I personally think >>>> that's a bit of a shame, but >>>> > > so be it. >>>> > ... >>>> > >>>> > Adrian Soncodi wrote: >>>> > ... >>>> > > You seem to say "if you want multi-homing, it must be only over >>>> SCTP". >>>> > > Why? Someone could similarly say "if you want MEGACO, it must >>>> be over >>>> > > UDP". But we don't, we allow all 3 protocols, for flexibility. >>>> > > >>>> > >>>> > I didn't mean to say "you must". I was under the impression that >>>> some of >>>> > us were saying that we had a technical issue to support >>>> multi-homing in >>>> > MEGACO, and my response was essentially "this is not an issue, >>>> there are >>>> > protocol specs existing in IETF to do just that, which is >>>> > MEGACO/H.248-Annex-H plus SCTP." Now, I think what I am hearing >>>> is, it >>>> > is not really about the lack of a solution, it's more about that >>>> some of >>>> > us just don't want to use the existing IETF solution (for whatever >>>> > non-tech reasons, or simply just don't wish to use it) and prefer to >>>> > define another solution in IETF. Well, if that is the case, I >>>> don't have >>>> > much else to say... >>>> > >>>> > Of cause, if there are tech issues/shortcomings/drawbacks/advantages >>>> > related to using SCTP for MEGACO multi-homing support, I'd be >>>> more than >>>> > glad to help answer. >>>> > >>>> > -Qiaobing >>>> >>> -- >>> Fernando Vallejo Lazaro >>> Phone: +34 91 330 5614 >>> SW Wireline ASD-Madrid >>> ALCATEL >>> >>> >> >> >> >> >> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue May 13 18:40:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02765 for ; Tue, 13 May 2003 18:40:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DM5xB03574; Tue, 13 May 2003 18:05:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DM43B03501 for ; Tue, 13 May 2003 18:04:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02688 for ; Tue, 13 May 2003 18:37:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FiQV-0000TJ-00 for megaco@ietf.org; Tue, 13 May 2003 18:39:15 -0400 Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.RADVISION.com) by ietf-mx with esmtp (Exim 4.12) id 19FiQU-0000TG-00 for megaco@ietf.org; Tue, 13 May 2003 18:39:14 -0400 Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19) id <2JB429XF>; Tue, 13 May 2003 18:37:53 -0400 Message-ID: From: Steve Cipolli To: "'Adrian Soncodi'" , Tom Taylor Cc: Fernando Vallejo Lazaro , megaco@ietf.org Subject: RE: [Megaco] Support for redundant MG failover Date: Tue, 13 May 2003 18:37:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , The topics I've been able to gleen from the email exchanges are: 1. How to distinguish redundant entities from multiple interfaces (multihoming) on a single entity. 2. Issues regarding item #1 with respect to SCTP, which one would expect to use with multiple IP addresses (to a single entity) for link redundancy. 3. Issues regarding item #1 with respect to UDP, which would allow similar advantages to that of SCTP at the expense of some Megaco transport complexity. 4. MGC-to-MG communication via a DNS domain name that yields multiple IP addresses is not specified in Megaco. I'm sure there were more topics... It's interesting to note regarding items #1 & #4 that SIP, MGCP, and soon H.323 (Annex O) have dealt with this problem. SIP and soon H.323 use DNS SRV records to specify redundant entities, and multiple IP addresses in an A or AAAA record to define multiple interfaces on the same entity. MGCP uses multiple IP addresses in an A or AAAA record to indicate multiple interfaces on the same "logical" entity. Redundancy/fail-over is handled by two different schemes that are linked to the specifics of MGCP. It seems to me that this problem should be solved consistently across these (and many other) protocols and Megaco. The SIP/H.323 direction seems to make sense, providing for both redundant and multihome support in a consistent and general way. --Stephen > -----Original Message----- > From: Adrian Soncodi [mailto:adrian.soncodi@tekelec.com] > Sent: Tuesday, May 13, 2003 4:34 PM > To: Tom Taylor > Cc: Fernando Vallejo Lazaro; megaco@ietf.org > Subject: Re: [Megaco] Support for redundant MG failover > > > > Tom Taylor wrote: > > > It seems to me that the outlines of a solution have been > sketched in > > Fernando's note. > > > Tom, > > I don't quite understand, can you elaborate on this statement? I was > trying to make the point that, for multi-homing, we could allow 2 or > more IP addresses per MG and/or MGC, which would make it simpler to > establish for example one SCTP association using all of them. > > Initially, Fernando said that 1 MEGACO control association = 1 IP > address, and implied that 2 IP addresses would be viewed as 2 > distinct > MGCs. But in this case: > - explaining which MGC pairs with which other MGC as multi-homed > entities is more difficult, > - plus, if an SCTP association uses more than 1 IP address (which it > should, in order to take advantage of multi-homing), then it > would mean > that 1 control association spans 2 MGCs, which seems to > contradict the > model. Handoff and failover wouldn't work in this case, > because MEGACO > does not control the selection of the IP addresses withing > the SCTP layer. > > Therefore, what do you think about the number of IP addresses per > MG/MGC? If SCTP is allowed to use only one IP address per > entity, then > why would one ever use SCTP instead of TCP? My understanding > is SCTP was > supposed to be a solution for multi-homing. > > Additionally (I don't know if you followed the whole > discussion in this > thread), a number of people have expressed interest in supporting > multi-homing over UDP too. This would also benefit from allowing > multiple IP addresses per MG/MGC, but a few clarification in the > procedures would be required. Would you be willing to consider adding > this additional functionality? > > Regards, > > Adrian > > > > Al the information to support multi-homing and the associated > > behaviour can be introduced through a set of ROOT > properties that can > > be either provisioned on the MG or set there after the > initial control > > association has been established. > > > > > > Adrian Soncodi wrote: > > > >> > >> > >> Fernando Vallejo Lazaro wrote: > >> > >>> Hi, > >>> > >>> I agree with Flemming that Megaco should be based on UDP and TCP. > >>> SCTP is not widely deployed and can lead to problems of > >>> interoperability. > >>> I would leave it as optional. > >>> > >>> For me the control association is clearly defined and it is 1 > >>> association = 1 IP address. > >>> Why? Because the assocation is done through a > ServiceChange Restart > >>> message which involves > >>> an IP address (in the MGC ID) and not a domain name. If the DNS > >>> returns more than > >>> one IP address for a given name the MG must choose one of them. > >>> > >> This is how one would be tempted to interpret the spec today, > >> although it is not explicitly stated. But as I have mentioned in a > >> previous e-mail, this is not adequate for SCTP, where one > would like > >> to know that the 2 IP addresses are on the same machine, > to be able > >> to use them within a single SCTP association. > >> > >> Also, the following quote from section 7.2.8 seems to > indicate more > >> than 1 IP address is possible: > >> > >> "The ServiceChangeAddress provides an address to be used > within the > >> Context of the association currently being negotiated ..." > >> > >> Since this is in the reply to ServiceChange, it looks like it can > >> actually be a different IP address (which then must be > interpreted in > >> the context of the current association ...). Otherwise, > why would the > >> MGC return the same IP address as the destination IP > address of the > >> ServiceChange message? The MG already knows that one! > >> > >>> What I feel is that the gap is in the definition of the secondary > >>> MGCs and its provisionning. > >>> I think there should be a way in which the MGC could > inform the MGs > >>> about existing secondaries > >>> MGCs. Now this can only be done using a HandOff method but > >>> sometimes this message cannot > >>> be sent by the primary MGC (e.g. network failure, crash > of the MGC > >>> ...). > >>> So it would be useful to add a new method in the ServiceChange to > >>> send this information and add > >>> a new parameter indicating what type of relationship there is > >>> between primary and secondary > >>> (e.g. mirror, backup, independent, third party.....) > >>> So in case a MGC is multihomed it could inform the MG at startup > >>> that a MGC exists which is a > >>> secondary mirror MGC (which corresponds to the same MGC but with > >>> another IP address). > >>> This process can be independent on the actual procedures > done by the > >>> operators to declare > >>> secondary MGCs. > >>> > >> I'm not sure a "mirror MGC" is the same MGC with another > IP address. > >> Some people would interpret "mirrored" as different machines, with > >> some state synchronization between them... > >> > >> Anyway, considering 2 or more multi-homed MGCs, i.e. 4 or more IP > >> addresses, and if each IP address is a different MGC, then > it becomes > >> quite cumbersome to signal which one is paired with which one. I > >> think it would be simpler and more clear to allow an MG to be > >> provisioned with more than one IP address per MGC. Then you would > >> immediately know the MGC is multi-homed. This works more elegantly > >> with SCTP, and also with DNS, which can return several IP > addresses > >> for an FQDN. > >> > >> Adrian > >> > >>> When a problem arises the MG can act in two ways: > >>> 1) If the new MGC is a mirror (maybe other types can be included > >>> here) it can resend the transactions > >>> which have failed in the old one. > >>> 2) If the new MGC is not a mirror it should try to establish a > >>> connection with a ServiceChange as defined > >>> in the megaco protocol. Then the MGC is in charge of > recovering the > >>> state of the MG ASAP and the service. > >>> > >>> In this way not too much work has to be added and we can > accomplish > >>> a solution. > >>> > >>> Regards > >>> Fernando > >>> > >>> > >>> Flemming Andreasen wrote: > >>> > >>>> Qiaobing > >>>> > >>>> Nobody is denying that SCTP is an existing spec that solves the > >>>> multihoming problem and it > >>>> is quite understandable that you in particular advocate it. > >>>> However, you seem to have lost > >>>> sight of the original question in this thread, which was about > >>>> native Megaco protocol > >>>> support for redundancy and failover, and as part of > that, support > >>>> for multihoming. Initial > >>>> claims was that Megaco fully supports this, but we seem to have > >>>> converged on the opinion > >>>> that it does not, unless you use SCTP, which is not part of the > >>>> base Megaco protocol. > >>>> Furthermore, despite everything, the fact of the matter > is that for > >>>> various reasons, not > >>>> everybody will be implementing SCTP at least for now (NATs, > >>>> firewalls and security do not > >>>> help SCTP here) and since UDP and TCP are the basic > requirements, > >>>> it would have been nice to > >>>> have better mechanisms for these; it can be done very > easily (see > >>>> MGCP for example). > >>>> Sometimes, it's good to be a bit pragmatic. > >>>> > >>>> -- Flemming > >>>> > >>>> Qiaobing Xie wrote: > >>>> > >>>> > (Try to respond to similar remarks from two mails) > >>>> > > >>>> > Flemming Andreasen wrote: > >>>> > ... > >>>> > > In any case, SCTP is there as an option today for those > >>>> > > that wish to use it. For those that don't, we've already > >>>> concluded that > >>>> > > multihoming/redundancy/failover is not very well > supported, and > >>>> that there doesn't > >>>> > > seem to be much desire to change that. I personally think > >>>> that's a bit of a shame, but > >>>> > > so be it. > >>>> > ... > >>>> > > >>>> > Adrian Soncodi wrote: > >>>> > ... > >>>> > > You seem to say "if you want multi-homing, it must > be only over > >>>> SCTP". > >>>> > > Why? Someone could similarly say "if you want > MEGACO, it must > >>>> be over > >>>> > > UDP". But we don't, we allow all 3 protocols, for > flexibility. > >>>> > > > >>>> > > >>>> > I didn't mean to say "you must". I was under the > impression that > >>>> some of > >>>> > us were saying that we had a technical issue to support > >>>> multi-homing in > >>>> > MEGACO, and my response was essentially "this is not an issue, > >>>> there are > >>>> > protocol specs existing in IETF to do just that, which is > >>>> > MEGACO/H.248-Annex-H plus SCTP." Now, I think what I > am hearing > >>>> is, it > >>>> > is not really about the lack of a solution, it's more > about that > >>>> some of > >>>> > us just don't want to use the existing IETF solution > (for whatever > >>>> > non-tech reasons, or simply just don't wish to use it) > and prefer to > >>>> > define another solution in IETF. Well, if that is the case, I > >>>> don't have > >>>> > much else to say... > >>>> > > >>>> > Of cause, if there are tech > issues/shortcomings/drawbacks/advantages > >>>> > related to using SCTP for MEGACO multi-homing support, I'd be > >>>> more than > >>>> > glad to help answer. > >>>> > > >>>> > -Qiaobing > >>>> > >>> -- > >>> Fernando Vallejo Lazaro > >>> Phone: +34 91 330 5614 > >>> SW Wireline ASD-Madrid > >>> ALCATEL > >>> > >>> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Megaco mailing list > >> Megaco@ietf.org > >> https://www1.ietf.org/mailman/listinfo/megaco > >> > > > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue May 13 18:41:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02799 for ; Tue, 13 May 2003 18:41:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DM7td04413 for megaco-archive@odin.ietf.org; Tue, 13 May 2003 18:07:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DM7sB04410 for ; Tue, 13 May 2003 18:07:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02791 for ; Tue, 13 May 2003 18:41:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FiUE-0000Ur-00 for megaco-web-archive@ietf.org; Tue, 13 May 2003 18:43:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FiUE-0000Uo-00 for megaco-web-archive@ietf.org; Tue, 13 May 2003 18:43:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DM5xB03574; Tue, 13 May 2003 18:05:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DM43B03501 for ; Tue, 13 May 2003 18:04:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02688 for ; Tue, 13 May 2003 18:37:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FiQV-0000TJ-00 for megaco@ietf.org; Tue, 13 May 2003 18:39:15 -0400 Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.RADVISION.com) by ietf-mx with esmtp (Exim 4.12) id 19FiQU-0000TG-00 for megaco@ietf.org; Tue, 13 May 2003 18:39:14 -0400 Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19) id <2JB429XF>; Tue, 13 May 2003 18:37:53 -0400 Message-ID: From: Steve Cipolli To: "'Adrian Soncodi'" , Tom Taylor Cc: Fernando Vallejo Lazaro , megaco@ietf.org Subject: RE: [Megaco] Support for redundant MG failover Date: Tue, 13 May 2003 18:37:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , The topics I've been able to gleen from the email exchanges are: 1. How to distinguish redundant entities from multiple interfaces (multihoming) on a single entity. 2. Issues regarding item #1 with respect to SCTP, which one would expect to use with multiple IP addresses (to a single entity) for link redundancy. 3. Issues regarding item #1 with respect to UDP, which would allow similar advantages to that of SCTP at the expense of some Megaco transport complexity. 4. MGC-to-MG communication via a DNS domain name that yields multiple IP addresses is not specified in Megaco. I'm sure there were more topics... It's interesting to note regarding items #1 & #4 that SIP, MGCP, and soon H.323 (Annex O) have dealt with this problem. SIP and soon H.323 use DNS SRV records to specify redundant entities, and multiple IP addresses in an A or AAAA record to define multiple interfaces on the same entity. MGCP uses multiple IP addresses in an A or AAAA record to indicate multiple interfaces on the same "logical" entity. Redundancy/fail-over is handled by two different schemes that are linked to the specifics of MGCP. It seems to me that this problem should be solved consistently across these (and many other) protocols and Megaco. The SIP/H.323 direction seems to make sense, providing for both redundant and multihome support in a consistent and general way. --Stephen > -----Original Message----- > From: Adrian Soncodi [mailto:adrian.soncodi@tekelec.com] > Sent: Tuesday, May 13, 2003 4:34 PM > To: Tom Taylor > Cc: Fernando Vallejo Lazaro; megaco@ietf.org > Subject: Re: [Megaco] Support for redundant MG failover > > > > Tom Taylor wrote: > > > It seems to me that the outlines of a solution have been > sketched in > > Fernando's note. > > > Tom, > > I don't quite understand, can you elaborate on this statement? I was > trying to make the point that, for multi-homing, we could allow 2 or > more IP addresses per MG and/or MGC, which would make it simpler to > establish for example one SCTP association using all of them. > > Initially, Fernando said that 1 MEGACO control association = 1 IP > address, and implied that 2 IP addresses would be viewed as 2 > distinct > MGCs. But in this case: > - explaining which MGC pairs with which other MGC as multi-homed > entities is more difficult, > - plus, if an SCTP association uses more than 1 IP address (which it > should, in order to take advantage of multi-homing), then it > would mean > that 1 control association spans 2 MGCs, which seems to > contradict the > model. Handoff and failover wouldn't work in this case, > because MEGACO > does not control the selection of the IP addresses withing > the SCTP layer. > > Therefore, what do you think about the number of IP addresses per > MG/MGC? If SCTP is allowed to use only one IP address per > entity, then > why would one ever use SCTP instead of TCP? My understanding > is SCTP was > supposed to be a solution for multi-homing. > > Additionally (I don't know if you followed the whole > discussion in this > thread), a number of people have expressed interest in supporting > multi-homing over UDP too. This would also benefit from allowing > multiple IP addresses per MG/MGC, but a few clarification in the > procedures would be required. Would you be willing to consider adding > this additional functionality? > > Regards, > > Adrian > > > > Al the information to support multi-homing and the associated > > behaviour can be introduced through a set of ROOT > properties that can > > be either provisioned on the MG or set there after the > initial control > > association has been established. > > > > > > Adrian Soncodi wrote: > > > >> > >> > >> Fernando Vallejo Lazaro wrote: > >> > >>> Hi, > >>> > >>> I agree with Flemming that Megaco should be based on UDP and TCP. > >>> SCTP is not widely deployed and can lead to problems of > >>> interoperability. > >>> I would leave it as optional. > >>> > >>> For me the control association is clearly defined and it is 1 > >>> association = 1 IP address. > >>> Why? Because the assocation is done through a > ServiceChange Restart > >>> message which involves > >>> an IP address (in the MGC ID) and not a domain name. If the DNS > >>> returns more than > >>> one IP address for a given name the MG must choose one of them. > >>> > >> This is how one would be tempted to interpret the spec today, > >> although it is not explicitly stated. But as I have mentioned in a > >> previous e-mail, this is not adequate for SCTP, where one > would like > >> to know that the 2 IP addresses are on the same machine, > to be able > >> to use them within a single SCTP association. > >> > >> Also, the following quote from section 7.2.8 seems to > indicate more > >> than 1 IP address is possible: > >> > >> "The ServiceChangeAddress provides an address to be used > within the > >> Context of the association currently being negotiated ..." > >> > >> Since this is in the reply to ServiceChange, it looks like it can > >> actually be a different IP address (which then must be > interpreted in > >> the context of the current association ...). Otherwise, > why would the > >> MGC return the same IP address as the destination IP > address of the > >> ServiceChange message? The MG already knows that one! > >> > >>> What I feel is that the gap is in the definition of the secondary > >>> MGCs and its provisionning. > >>> I think there should be a way in which the MGC could > inform the MGs > >>> about existing secondaries > >>> MGCs. Now this can only be done using a HandOff method but > >>> sometimes this message cannot > >>> be sent by the primary MGC (e.g. network failure, crash > of the MGC > >>> ...). > >>> So it would be useful to add a new method in the ServiceChange to > >>> send this information and add > >>> a new parameter indicating what type of relationship there is > >>> between primary and secondary > >>> (e.g. mirror, backup, independent, third party.....) > >>> So in case a MGC is multihomed it could inform the MG at startup > >>> that a MGC exists which is a > >>> secondary mirror MGC (which corresponds to the same MGC but with > >>> another IP address). > >>> This process can be independent on the actual procedures > done by the > >>> operators to declare > >>> secondary MGCs. > >>> > >> I'm not sure a "mirror MGC" is the same MGC with another > IP address. > >> Some people would interpret "mirrored" as different machines, with > >> some state synchronization between them... > >> > >> Anyway, considering 2 or more multi-homed MGCs, i.e. 4 or more IP > >> addresses, and if each IP address is a different MGC, then > it becomes > >> quite cumbersome to signal which one is paired with which one. I > >> think it would be simpler and more clear to allow an MG to be > >> provisioned with more than one IP address per MGC. Then you would > >> immediately know the MGC is multi-homed. This works more elegantly > >> with SCTP, and also with DNS, which can return several IP > addresses > >> for an FQDN. > >> > >> Adrian > >> > >>> When a problem arises the MG can act in two ways: > >>> 1) If the new MGC is a mirror (maybe other types can be included > >>> here) it can resend the transactions > >>> which have failed in the old one. > >>> 2) If the new MGC is not a mirror it should try to establish a > >>> connection with a ServiceChange as defined > >>> in the megaco protocol. Then the MGC is in charge of > recovering the > >>> state of the MG ASAP and the service. > >>> > >>> In this way not too much work has to be added and we can > accomplish > >>> a solution. > >>> > >>> Regards > >>> Fernando > >>> > >>> > >>> Flemming Andreasen wrote: > >>> > >>>> Qiaobing > >>>> > >>>> Nobody is denying that SCTP is an existing spec that solves the > >>>> multihoming problem and it > >>>> is quite understandable that you in particular advocate it. > >>>> However, you seem to have lost > >>>> sight of the original question in this thread, which was about > >>>> native Megaco protocol > >>>> support for redundancy and failover, and as part of > that, support > >>>> for multihoming. Initial > >>>> claims was that Megaco fully supports this, but we seem to have > >>>> converged on the opinion > >>>> that it does not, unless you use SCTP, which is not part of the > >>>> base Megaco protocol. > >>>> Furthermore, despite everything, the fact of the matter > is that for > >>>> various reasons, not > >>>> everybody will be implementing SCTP at least for now (NATs, > >>>> firewalls and security do not > >>>> help SCTP here) and since UDP and TCP are the basic > requirements, > >>>> it would have been nice to > >>>> have better mechanisms for these; it can be done very > easily (see > >>>> MGCP for example). > >>>> Sometimes, it's good to be a bit pragmatic. > >>>> > >>>> -- Flemming > >>>> > >>>> Qiaobing Xie wrote: > >>>> > >>>> > (Try to respond to similar remarks from two mails) > >>>> > > >>>> > Flemming Andreasen wrote: > >>>> > ... > >>>> > > In any case, SCTP is there as an option today for those > >>>> > > that wish to use it. For those that don't, we've already > >>>> concluded that > >>>> > > multihoming/redundancy/failover is not very well > supported, and > >>>> that there doesn't > >>>> > > seem to be much desire to change that. I personally think > >>>> that's a bit of a shame, but > >>>> > > so be it. > >>>> > ... > >>>> > > >>>> > Adrian Soncodi wrote: > >>>> > ... > >>>> > > You seem to say "if you want multi-homing, it must > be only over > >>>> SCTP". > >>>> > > Why? Someone could similarly say "if you want > MEGACO, it must > >>>> be over > >>>> > > UDP". But we don't, we allow all 3 protocols, for > flexibility. > >>>> > > > >>>> > > >>>> > I didn't mean to say "you must". I was under the > impression that > >>>> some of > >>>> > us were saying that we had a technical issue to support > >>>> multi-homing in > >>>> > MEGACO, and my response was essentially "this is not an issue, > >>>> there are > >>>> > protocol specs existing in IETF to do just that, which is > >>>> > MEGACO/H.248-Annex-H plus SCTP." Now, I think what I > am hearing > >>>> is, it > >>>> > is not really about the lack of a solution, it's more > about that > >>>> some of > >>>> > us just don't want to use the existing IETF solution > (for whatever > >>>> > non-tech reasons, or simply just don't wish to use it) > and prefer to > >>>> > define another solution in IETF. Well, if that is the case, I > >>>> don't have > >>>> > much else to say... > >>>> > > >>>> > Of cause, if there are tech > issues/shortcomings/drawbacks/advantages > >>>> > related to using SCTP for MEGACO multi-homing support, I'd be > >>>> more than > >>>> > glad to help answer. > >>>> > > >>>> > -Qiaobing > >>>> > >>> -- > >>> Fernando Vallejo Lazaro > >>> Phone: +34 91 330 5614 > >>> SW Wireline ASD-Madrid > >>> ALCATEL > >>> > >>> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Megaco mailing list > >> Megaco@ietf.org > >> https://www1.ietf.org/mailman/listinfo/megaco > >> > > > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue May 13 20:37:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05264 for ; Tue, 13 May 2003 20:37:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E02eB11340; Tue, 13 May 2003 20:02:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DNxYB11154 for ; Tue, 13 May 2003 19:59:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05168 for ; Tue, 13 May 2003 20:32:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FkEG-000157-00 for megaco@ietf.org; Tue, 13 May 2003 20:34:44 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19FkEF-000153-00 for megaco@ietf.org; Tue, 13 May 2003 20:34:43 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4E0Z0Y03197; Tue, 13 May 2003 20:35:00 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLFSSWL; Tue, 13 May 2003 20:35:01 -0400 Received: from nortelnetworks.com (acart1cc.ca.nortel.com [47.129.129.55]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA02MX; Tue, 13 May 2003 20:35:00 -0400 Message-ID: <3EC18F30.3010804@nortelnetworks.com> Date: Tue, 13 May 2003 20:34:56 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Adrian Soncodi CC: SCipolli@radvision.com, megaco@ietf.org Subject: Re: [Megaco] Support for redundant MG failover References: <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com> <3EA98F66.C6890B54@motorola.com> <3EA99A2E.4DC6BD7D@cisco.com> <3EA9DC82.136119A3@motorola.com> <3EA9F2B5.FEBAA43@cisco.com> <3EACEC44.96FF416A@alcatel.es> <3EADAE09.1010600@tekelec.com> <3EC13AE1.8080106@nortelnetworks.com> <3EC156C0.4040300@tekelec.com> In-Reply-To: <3EC156C0.4040300@tekelec.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ok, I'll work a bit harder. First point: I'd say the control association is uniquely identified by the mId of each peer, but is associated with transport (and much other) state. I've always thought of the mId part of the message as an identifier, not necessarily tied to an address, even if that is what the syntax suggests. The syntax also allows an mId which is simply a NAME. Hence I do not believe the protocol as it stands identifies a control association with a network address. This means it is quite feasible to associate a control association with multiple addresses at either end. The protocol has a way to allow you to express additional information of this sort if you need to pass it at the application level: you provide it as properties defined in a package. Second point: pre-start-up is by definition outside the scope of the protocol, since the protocol has yet to operate. The SRV record approach used by SIP is only one alternative of a number that SIP offers. All we can standardize (as we have already done) is that an initial condition for the operation of the protocol is that the MG knows what TRANSPORT (not NETWORK) address it should use to reach the MGC. How it determines that transport address is up to the implementation. For SCTP the initial transport address used is that of the initial primary path. That doesn't prevent the use of multihoming; the peers supply the alternative addresses as part of the SCTP protocol exchange, and there is no need for Megaco to account for them explicitly. If you want to use UDP instead of SCTP, you have to agree on a similar exchange of information. I've already pointed out above how this could be done, by setting and reading of ROOT properties on the MG. Adrian Soncodi wrote: > > Tom Taylor wrote: > >> It seems to me that the outlines of a solution have been sketched in >> Fernando's note. > > > > Tom, > > I don't quite understand, can you elaborate on this statement? I was > trying to make the point that, for multi-homing, we could allow 2 or > more IP addresses per MG and/or MGC, which would make it simpler to > establish for example one SCTP association using all of them. > > Initially, Fernando said that 1 MEGACO control association = 1 IP > address, and implied that 2 IP addresses would be viewed as 2 distinct > MGCs. But in this case: > - explaining which MGC pairs with which other MGC as multi-homed > entities is more difficult, > - plus, if an SCTP association uses more than 1 IP address (which it > should, in order to take advantage of multi-homing), then it would mean > that 1 control association spans 2 MGCs, which seems to contradict the > model. Handoff and failover wouldn't work in this case, because MEGACO > does not control the selection of the IP addresses withing the SCTP layer. > > Therefore, what do you think about the number of IP addresses per > MG/MGC? If SCTP is allowed to use only one IP address per entity, then > why would one ever use SCTP instead of TCP? My understanding is SCTP was > supposed to be a solution for multi-homing. > > Additionally (I don't know if you followed the whole discussion in this > thread), a number of people have expressed interest in supporting > multi-homing over UDP too. This would also benefit from allowing > multiple IP addresses per MG/MGC, but a few clarification in the > procedures would be required. Would you be willing to consider adding > this additional functionality? > > Regards, > > Adrian > > >> Al the information to support multi-homing and the associated >> behaviour can be introduced through a set of ROOT properties that can >> be either provisioned on the MG or set there after the initial control >> association has been established. >> >> >> Adrian Soncodi wrote: >> >>> >>> >>> Fernando Vallejo Lazaro wrote: >>> >>>> Hi, >>>> >>>> I agree with Flemming that Megaco should be based on UDP and TCP. >>>> SCTP is not widely deployed and can lead to problems of >>>> interoperability. >>>> I would leave it as optional. >>>> >>>> For me the control association is clearly defined and it is 1 >>>> association = 1 IP address. >>>> Why? Because the assocation is done through a ServiceChange Restart >>>> message which involves >>>> an IP address (in the MGC ID) and not a domain name. If the DNS >>>> returns more than >>>> one IP address for a given name the MG must choose one of them. >>>> >>> This is how one would be tempted to interpret the spec today, >>> although it is not explicitly stated. But as I have mentioned in a >>> previous e-mail, this is not adequate for SCTP, where one would like >>> to know that the 2 IP addresses are on the same machine, to be able >>> to use them within a single SCTP association. >>> >>> Also, the following quote from section 7.2.8 seems to indicate more >>> than 1 IP address is possible: >>> >>> "The ServiceChangeAddress provides an address to be used within the >>> Context of the association currently being negotiated ..." >>> >>> Since this is in the reply to ServiceChange, it looks like it can >>> actually be a different IP address (which then must be interpreted in >>> the context of the current association ...). Otherwise, why would the >>> MGC return the same IP address as the destination IP address of the >>> ServiceChange message? The MG already knows that one! >>> >>>> What I feel is that the gap is in the definition of the secondary >>>> MGCs and its provisionning. >>>> I think there should be a way in which the MGC could inform the MGs >>>> about existing secondaries >>>> MGCs. Now this can only be done using a HandOff method but >>>> sometimes this message cannot >>>> be sent by the primary MGC (e.g. network failure, crash of the MGC >>>> ...). >>>> So it would be useful to add a new method in the ServiceChange to >>>> send this information and add >>>> a new parameter indicating what type of relationship there is >>>> between primary and secondary >>>> (e.g. mirror, backup, independent, third party.....) >>>> So in case a MGC is multihomed it could inform the MG at startup >>>> that a MGC exists which is a >>>> secondary mirror MGC (which corresponds to the same MGC but with >>>> another IP address). >>>> This process can be independent on the actual procedures done by the >>>> operators to declare >>>> secondary MGCs. >>>> >>> I'm not sure a "mirror MGC" is the same MGC with another IP address. >>> Some people would interpret "mirrored" as different machines, with >>> some state synchronization between them... >>> >>> Anyway, considering 2 or more multi-homed MGCs, i.e. 4 or more IP >>> addresses, and if each IP address is a different MGC, then it becomes >>> quite cumbersome to signal which one is paired with which one. I >>> think it would be simpler and more clear to allow an MG to be >>> provisioned with more than one IP address per MGC. Then you would >>> immediately know the MGC is multi-homed. This works more elegantly >>> with SCTP, and also with DNS, which can return several IP addresses >>> for an FQDN. >>> >>> Adrian >>> >>>> When a problem arises the MG can act in two ways: >>>> 1) If the new MGC is a mirror (maybe other types can be included >>>> here) it can resend the transactions >>>> which have failed in the old one. >>>> 2) If the new MGC is not a mirror it should try to establish a >>>> connection with a ServiceChange as defined >>>> in the megaco protocol. Then the MGC is in charge of recovering the >>>> state of the MG ASAP and the service. >>>> >>>> In this way not too much work has to be added and we can accomplish >>>> a solution. >>>> >>>> Regards >>>> Fernando >>>> >>>> >>>> Flemming Andreasen wrote: >>>> >>>>> Qiaobing >>>>> >>>>> Nobody is denying that SCTP is an existing spec that solves the >>>>> multihoming problem and it >>>>> is quite understandable that you in particular advocate it. >>>>> However, you seem to have lost >>>>> sight of the original question in this thread, which was about >>>>> native Megaco protocol >>>>> support for redundancy and failover, and as part of that, support >>>>> for multihoming. Initial >>>>> claims was that Megaco fully supports this, but we seem to have >>>>> converged on the opinion >>>>> that it does not, unless you use SCTP, which is not part of the >>>>> base Megaco protocol. >>>>> Furthermore, despite everything, the fact of the matter is that for >>>>> various reasons, not >>>>> everybody will be implementing SCTP at least for now (NATs, >>>>> firewalls and security do not >>>>> help SCTP here) and since UDP and TCP are the basic requirements, >>>>> it would have been nice to >>>>> have better mechanisms for these; it can be done very easily (see >>>>> MGCP for example). >>>>> Sometimes, it's good to be a bit pragmatic. >>>>> >>>>> -- Flemming >>>>> >>>>> Qiaobing Xie wrote: >>>>> >>>>> > (Try to respond to similar remarks from two mails) >>>>> > >>>>> > Flemming Andreasen wrote: >>>>> > ... >>>>> > > In any case, SCTP is there as an option today for those >>>>> > > that wish to use it. For those that don't, we've already >>>>> concluded that >>>>> > > multihoming/redundancy/failover is not very well supported, and >>>>> that there doesn't >>>>> > > seem to be much desire to change that. I personally think >>>>> that's a bit of a shame, but >>>>> > > so be it. >>>>> > ... >>>>> > >>>>> > Adrian Soncodi wrote: >>>>> > ... >>>>> > > You seem to say "if you want multi-homing, it must be only over >>>>> SCTP". >>>>> > > Why? Someone could similarly say "if you want MEGACO, it must >>>>> be over >>>>> > > UDP". But we don't, we allow all 3 protocols, for flexibility. >>>>> > > >>>>> > >>>>> > I didn't mean to say "you must". I was under the impression that >>>>> some of >>>>> > us were saying that we had a technical issue to support >>>>> multi-homing in >>>>> > MEGACO, and my response was essentially "this is not an issue, >>>>> there are >>>>> > protocol specs existing in IETF to do just that, which is >>>>> > MEGACO/H.248-Annex-H plus SCTP." Now, I think what I am hearing >>>>> is, it >>>>> > is not really about the lack of a solution, it's more about that >>>>> some of >>>>> > us just don't want to use the existing IETF solution (for whatever >>>>> > non-tech reasons, or simply just don't wish to use it) and prefer to >>>>> > define another solution in IETF. Well, if that is the case, I >>>>> don't have >>>>> > much else to say... >>>>> > >>>>> > Of cause, if there are tech issues/shortcomings/drawbacks/advantages >>>>> > related to using SCTP for MEGACO multi-homing support, I'd be >>>>> more than >>>>> > glad to help answer. >>>>> > >>>>> > -Qiaobing >>>>> >>>> -- >>>> Fernando Vallejo Lazaro >>>> Phone: +34 91 330 5614 >>>> SW Wireline ASD-Madrid >>>> ALCATEL >>>> >>>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Megaco mailing list >>> Megaco@ietf.org >>> https://www1.ietf.org/mailman/listinfo/megaco >>> >> >> > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue May 13 20:38:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05294 for ; Tue, 13 May 2003 20:38:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4E04hv11418 for megaco-archive@odin.ietf.org; Tue, 13 May 2003 20:04:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E04hB11415 for ; Tue, 13 May 2003 20:04:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05283 for ; Tue, 13 May 2003 20:37:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FkJF-00016L-00 for megaco-web-archive@ietf.org; Tue, 13 May 2003 20:39:53 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FkJE-00016I-00 for megaco-web-archive@ietf.org; Tue, 13 May 2003 20:39:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E02eB11340; Tue, 13 May 2003 20:02:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DNxYB11154 for ; Tue, 13 May 2003 19:59:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05168 for ; Tue, 13 May 2003 20:32:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FkEG-000157-00 for megaco@ietf.org; Tue, 13 May 2003 20:34:44 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19FkEF-000153-00 for megaco@ietf.org; Tue, 13 May 2003 20:34:43 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4E0Z0Y03197; Tue, 13 May 2003 20:35:00 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLFSSWL; Tue, 13 May 2003 20:35:01 -0400 Received: from nortelnetworks.com (acart1cc.ca.nortel.com [47.129.129.55]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA02MX; Tue, 13 May 2003 20:35:00 -0400 Message-ID: <3EC18F30.3010804@nortelnetworks.com> Date: Tue, 13 May 2003 20:34:56 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Adrian Soncodi CC: SCipolli@radvision.com, megaco@ietf.org Subject: Re: [Megaco] Support for redundant MG failover References: <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com> <3EA98F66.C6890B54@motorola.com> <3EA99A2E.4DC6BD7D@cisco.com> <3EA9DC82.136119A3@motorola.com> <3EA9F2B5.FEBAA43@cisco.com> <3EACEC44.96FF416A@alcatel.es> <3EADAE09.1010600@tekelec.com> <3EC13AE1.8080106@nortelnetworks.com> <3EC156C0.4040300@tekelec.com> In-Reply-To: <3EC156C0.4040300@tekelec.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ok, I'll work a bit harder. First point: I'd say the control association is uniquely identified by the mId of each peer, but is associated with transport (and much other) state. I've always thought of the mId part of the message as an identifier, not necessarily tied to an address, even if that is what the syntax suggests. The syntax also allows an mId which is simply a NAME. Hence I do not believe the protocol as it stands identifies a control association with a network address. This means it is quite feasible to associate a control association with multiple addresses at either end. The protocol has a way to allow you to express additional information of this sort if you need to pass it at the application level: you provide it as properties defined in a package. Second point: pre-start-up is by definition outside the scope of the protocol, since the protocol has yet to operate. The SRV record approach used by SIP is only one alternative of a number that SIP offers. All we can standardize (as we have already done) is that an initial condition for the operation of the protocol is that the MG knows what TRANSPORT (not NETWORK) address it should use to reach the MGC. How it determines that transport address is up to the implementation. For SCTP the initial transport address used is that of the initial primary path. That doesn't prevent the use of multihoming; the peers supply the alternative addresses as part of the SCTP protocol exchange, and there is no need for Megaco to account for them explicitly. If you want to use UDP instead of SCTP, you have to agree on a similar exchange of information. I've already pointed out above how this could be done, by setting and reading of ROOT properties on the MG. Adrian Soncodi wrote: > > Tom Taylor wrote: > >> It seems to me that the outlines of a solution have been sketched in >> Fernando's note. > > > > Tom, > > I don't quite understand, can you elaborate on this statement? I was > trying to make the point that, for multi-homing, we could allow 2 or > more IP addresses per MG and/or MGC, which would make it simpler to > establish for example one SCTP association using all of them. > > Initially, Fernando said that 1 MEGACO control association = 1 IP > address, and implied that 2 IP addresses would be viewed as 2 distinct > MGCs. But in this case: > - explaining which MGC pairs with which other MGC as multi-homed > entities is more difficult, > - plus, if an SCTP association uses more than 1 IP address (which it > should, in order to take advantage of multi-homing), then it would mean > that 1 control association spans 2 MGCs, which seems to contradict the > model. Handoff and failover wouldn't work in this case, because MEGACO > does not control the selection of the IP addresses withing the SCTP layer. > > Therefore, what do you think about the number of IP addresses per > MG/MGC? If SCTP is allowed to use only one IP address per entity, then > why would one ever use SCTP instead of TCP? My understanding is SCTP was > supposed to be a solution for multi-homing. > > Additionally (I don't know if you followed the whole discussion in this > thread), a number of people have expressed interest in supporting > multi-homing over UDP too. This would also benefit from allowing > multiple IP addresses per MG/MGC, but a few clarification in the > procedures would be required. Would you be willing to consider adding > this additional functionality? > > Regards, > > Adrian > > >> Al the information to support multi-homing and the associated >> behaviour can be introduced through a set of ROOT properties that can >> be either provisioned on the MG or set there after the initial control >> association has been established. >> >> >> Adrian Soncodi wrote: >> >>> >>> >>> Fernando Vallejo Lazaro wrote: >>> >>>> Hi, >>>> >>>> I agree with Flemming that Megaco should be based on UDP and TCP. >>>> SCTP is not widely deployed and can lead to problems of >>>> interoperability. >>>> I would leave it as optional. >>>> >>>> For me the control association is clearly defined and it is 1 >>>> association = 1 IP address. >>>> Why? Because the assocation is done through a ServiceChange Restart >>>> message which involves >>>> an IP address (in the MGC ID) and not a domain name. If the DNS >>>> returns more than >>>> one IP address for a given name the MG must choose one of them. >>>> >>> This is how one would be tempted to interpret the spec today, >>> although it is not explicitly stated. But as I have mentioned in a >>> previous e-mail, this is not adequate for SCTP, where one would like >>> to know that the 2 IP addresses are on the same machine, to be able >>> to use them within a single SCTP association. >>> >>> Also, the following quote from section 7.2.8 seems to indicate more >>> than 1 IP address is possible: >>> >>> "The ServiceChangeAddress provides an address to be used within the >>> Context of the association currently being negotiated ..." >>> >>> Since this is in the reply to ServiceChange, it looks like it can >>> actually be a different IP address (which then must be interpreted in >>> the context of the current association ...). Otherwise, why would the >>> MGC return the same IP address as the destination IP address of the >>> ServiceChange message? The MG already knows that one! >>> >>>> What I feel is that the gap is in the definition of the secondary >>>> MGCs and its provisionning. >>>> I think there should be a way in which the MGC could inform the MGs >>>> about existing secondaries >>>> MGCs. Now this can only be done using a HandOff method but >>>> sometimes this message cannot >>>> be sent by the primary MGC (e.g. network failure, crash of the MGC >>>> ...). >>>> So it would be useful to add a new method in the ServiceChange to >>>> send this information and add >>>> a new parameter indicating what type of relationship there is >>>> between primary and secondary >>>> (e.g. mirror, backup, independent, third party.....) >>>> So in case a MGC is multihomed it could inform the MG at startup >>>> that a MGC exists which is a >>>> secondary mirror MGC (which corresponds to the same MGC but with >>>> another IP address). >>>> This process can be independent on the actual procedures done by the >>>> operators to declare >>>> secondary MGCs. >>>> >>> I'm not sure a "mirror MGC" is the same MGC with another IP address. >>> Some people would interpret "mirrored" as different machines, with >>> some state synchronization between them... >>> >>> Anyway, considering 2 or more multi-homed MGCs, i.e. 4 or more IP >>> addresses, and if each IP address is a different MGC, then it becomes >>> quite cumbersome to signal which one is paired with which one. I >>> think it would be simpler and more clear to allow an MG to be >>> provisioned with more than one IP address per MGC. Then you would >>> immediately know the MGC is multi-homed. This works more elegantly >>> with SCTP, and also with DNS, which can return several IP addresses >>> for an FQDN. >>> >>> Adrian >>> >>>> When a problem arises the MG can act in two ways: >>>> 1) If the new MGC is a mirror (maybe other types can be included >>>> here) it can resend the transactions >>>> which have failed in the old one. >>>> 2) If the new MGC is not a mirror it should try to establish a >>>> connection with a ServiceChange as defined >>>> in the megaco protocol. Then the MGC is in charge of recovering the >>>> state of the MG ASAP and the service. >>>> >>>> In this way not too much work has to be added and we can accomplish >>>> a solution. >>>> >>>> Regards >>>> Fernando >>>> >>>> >>>> Flemming Andreasen wrote: >>>> >>>>> Qiaobing >>>>> >>>>> Nobody is denying that SCTP is an existing spec that solves the >>>>> multihoming problem and it >>>>> is quite understandable that you in particular advocate it. >>>>> However, you seem to have lost >>>>> sight of the original question in this thread, which was about >>>>> native Megaco protocol >>>>> support for redundancy and failover, and as part of that, support >>>>> for multihoming. Initial >>>>> claims was that Megaco fully supports this, but we seem to have >>>>> converged on the opinion >>>>> that it does not, unless you use SCTP, which is not part of the >>>>> base Megaco protocol. >>>>> Furthermore, despite everything, the fact of the matter is that for >>>>> various reasons, not >>>>> everybody will be implementing SCTP at least for now (NATs, >>>>> firewalls and security do not >>>>> help SCTP here) and since UDP and TCP are the basic requirements, >>>>> it would have been nice to >>>>> have better mechanisms for these; it can be done very easily (see >>>>> MGCP for example). >>>>> Sometimes, it's good to be a bit pragmatic. >>>>> >>>>> -- Flemming >>>>> >>>>> Qiaobing Xie wrote: >>>>> >>>>> > (Try to respond to similar remarks from two mails) >>>>> > >>>>> > Flemming Andreasen wrote: >>>>> > ... >>>>> > > In any case, SCTP is there as an option today for those >>>>> > > that wish to use it. For those that don't, we've already >>>>> concluded that >>>>> > > multihoming/redundancy/failover is not very well supported, and >>>>> that there doesn't >>>>> > > seem to be much desire to change that. I personally think >>>>> that's a bit of a shame, but >>>>> > > so be it. >>>>> > ... >>>>> > >>>>> > Adrian Soncodi wrote: >>>>> > ... >>>>> > > You seem to say "if you want multi-homing, it must be only over >>>>> SCTP". >>>>> > > Why? Someone could similarly say "if you want MEGACO, it must >>>>> be over >>>>> > > UDP". But we don't, we allow all 3 protocols, for flexibility. >>>>> > > >>>>> > >>>>> > I didn't mean to say "you must". I was under the impression that >>>>> some of >>>>> > us were saying that we had a technical issue to support >>>>> multi-homing in >>>>> > MEGACO, and my response was essentially "this is not an issue, >>>>> there are >>>>> > protocol specs existing in IETF to do just that, which is >>>>> > MEGACO/H.248-Annex-H plus SCTP." Now, I think what I am hearing >>>>> is, it >>>>> > is not really about the lack of a solution, it's more about that >>>>> some of >>>>> > us just don't want to use the existing IETF solution (for whatever >>>>> > non-tech reasons, or simply just don't wish to use it) and prefer to >>>>> > define another solution in IETF. Well, if that is the case, I >>>>> don't have >>>>> > much else to say... >>>>> > >>>>> > Of cause, if there are tech issues/shortcomings/drawbacks/advantages >>>>> > related to using SCTP for MEGACO multi-homing support, I'd be >>>>> more than >>>>> > glad to help answer. >>>>> > >>>>> > -Qiaobing >>>>> >>>> -- >>>> Fernando Vallejo Lazaro >>>> Phone: +34 91 330 5614 >>>> SW Wireline ASD-Madrid >>>> ALCATEL >>>> >>>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Megaco mailing list >>> Megaco@ietf.org >>> https://www1.ietf.org/mailman/listinfo/megaco >>> >> >> > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed May 14 01:59:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10693 for ; Wed, 14 May 2003 01:59:33 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E5OmB00534; Wed, 14 May 2003 01:24:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E5MoB00441 for ; Wed, 14 May 2003 01:22:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10644 for ; Wed, 14 May 2003 01:55:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FpGz-0002bK-00 for megaco@ietf.org; Wed, 14 May 2003 01:57:53 -0400 Received: from [203.196.156.177] (helo=netserv.rnd.hfcl.com) by ietf-mx with esmtp (Exim 4.12) id 19FpGx-0002bC-00 for megaco@ietf.org; Wed, 14 May 2003 01:57:52 -0400 Received: (from root@localhost) by netserv.rnd.hfcl.com (8.11.6/8.11.2) id h4E62oX32377 for megaco@ietf.org; Wed, 14 May 2003 11:32:50 +0530 Received: from abhishek ([132.147.166.22]) by netserv.rnd.hfcl.com (8.11.6/8.11.2) with SMTP id h4E62ng32366 for ; Wed, 14 May 2003 11:32:49 +0530 Message-ID: <002101c319dd$d3399920$16a69384@abhishek> Reply-To: "Abhishek Bansal" From: "Abhishek Bansal" To: Date: Wed, 14 May 2003 11:28:21 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C31A0B.ECD54C70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xmilter: rnd.hfcl.com X-Virus-Scanned: by AMaViS perl-11 Subject: [Megaco] query regarding qos package Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C31A0B.ECD54C70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi What is the current status of draft-madhubabu-megaco-qospackage-00.txt ? Is there any package adopted by IANA for qos ? With regards Abhishek ------=_NextPart_000_001E_01C31A0B.ECD54C70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi
What is the current status of=20 draft-madhubabu-megaco-qospackage-00.txt ?
Is there any package adopted by IANA = for qos=20 ?
With regards
Abhishek
 
------=_NextPart_000_001E_01C31A0B.ECD54C70-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed May 14 02:00:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11435 for ; Wed, 14 May 2003 02:00:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4E5R3f00639 for megaco-archive@odin.ietf.org; Wed, 14 May 2003 01:27:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E5R3B00636 for ; Wed, 14 May 2003 01:27:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10873 for ; Wed, 14 May 2003 02:00:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FpL3-0002cG-00 for megaco-web-archive@ietf.org; Wed, 14 May 2003 02:02:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FpL3-0002cD-00 for megaco-web-archive@ietf.org; Wed, 14 May 2003 02:02:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E5OmB00534; Wed, 14 May 2003 01:24:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E5MoB00441 for ; Wed, 14 May 2003 01:22:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10644 for ; Wed, 14 May 2003 01:55:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FpGz-0002bK-00 for megaco@ietf.org; Wed, 14 May 2003 01:57:53 -0400 Received: from [203.196.156.177] (helo=netserv.rnd.hfcl.com) by ietf-mx with esmtp (Exim 4.12) id 19FpGx-0002bC-00 for megaco@ietf.org; Wed, 14 May 2003 01:57:52 -0400 Received: (from root@localhost) by netserv.rnd.hfcl.com (8.11.6/8.11.2) id h4E62oX32377 for megaco@ietf.org; Wed, 14 May 2003 11:32:50 +0530 Received: from abhishek ([132.147.166.22]) by netserv.rnd.hfcl.com (8.11.6/8.11.2) with SMTP id h4E62ng32366 for ; Wed, 14 May 2003 11:32:49 +0530 Message-ID: <002101c319dd$d3399920$16a69384@abhishek> Reply-To: "Abhishek Bansal" From: "Abhishek Bansal" To: Date: Wed, 14 May 2003 11:28:21 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C31A0B.ECD54C70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xmilter: rnd.hfcl.com X-Virus-Scanned: by AMaViS perl-11 Subject: [Megaco] query regarding qos package Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C31A0B.ECD54C70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi What is the current status of draft-madhubabu-megaco-qospackage-00.txt ? Is there any package adopted by IANA for qos ? With regards Abhishek ------=_NextPart_000_001E_01C31A0B.ECD54C70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi
What is the current status of=20 draft-madhubabu-megaco-qospackage-00.txt ?
Is there any package adopted by IANA = for qos=20 ?
With regards
Abhishek
 
------=_NextPart_000_001E_01C31A0B.ECD54C70-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed May 14 02:29:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05155 for ; Wed, 14 May 2003 02:29:12 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E5sZB02519; Wed, 14 May 2003 01:54:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E5rZB02486 for ; Wed, 14 May 2003 01:53:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03363 for ; Wed, 14 May 2003 02:26:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fpkj-0002jM-00 for megaco@ietf.org; Wed, 14 May 2003 02:28:37 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19Fpkh-0002jJ-00 for megaco@ietf.org; Wed, 14 May 2003 02:28:35 -0400 Received: from brsf10.epa.ericsson.se ([61.88.9.226]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h4E6R1425429; Wed, 14 May 2003 16:27:01 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h4E6TN006792; Wed, 14 May 2003 16:29:23 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.236.75]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JB83ANX0; Wed, 14 May 2003 16:29:22 +1000 Message-ID: <3EC1A070.CB7B901E@ericsson.com.au> Date: Wed, 14 May 2003 11:48:32 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Boyle , Tom Taylor CC: Michael DiGioia , kengr@winphoria.com, megaco@ietf.org, bsteinka@telica.com Subject: Re: [Megaco] Megaco CAS support References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit G'Day Tom and Kevin, Please see my comments [CHG]. Regards, Christian Kevin Boyle wrote: > > Comments inline. [KJBII] > > Kevin > > -----Original Message----- > From: Tom Taylor [mailto:taylor@nortelnetworks.com] > Sent: Tuesday, May 13, 2003 8:38 AM > To: Michael DiGioia > Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; kengr@winphoria.com; > Christian.Groves@ericsson.com.au; megaco@ietf.org; bsteinka@telica.com > > Subject: Re: [Megaco] Megaco CAS support > > The day this was written, I was on the operating table. Today is the first > day I > have been in a position to respond. > > [KJBII] Welcome back! > > Kevin's frustration with the IETF process is my fault for not providing > adequate > leadership. For that I apologize. It stems to some extent from a confusion > of > objectives in my own working life. That said: > -- the IESG has been unwilling to expand the Megaco charter to include > packages > -- at this point, the IESG is ready to terminate the Working Group (BUT KEEP > THE LIST). > > It is up to us to determine a working relationship with the ITU-T that will > keep the > work moving in everybody's best interest. I should point out that SG 16 > itself is > not having an easy time of it -- attendance has dropped drastically in the > last > couple of years. The ITU-T is approaching one of those intervals when it > considers > reorganization, and we could find ourselves dealing with a different Study > Group > next year. [CHG] Regardless of the number of the Study Group we could be dealing with I think that we can safely assume that the ITUs work on H.248 will continue. > > I'll ask a couple of questions to shape discussion of how we should proceed > from here: > > -- It seems self-evident to me that the Megaco list should continue to be the > primary source of material for the Implementor's Guide. Any disagreement? > > [KJBII] The list has always been the definitive source, so I see no reason to > change this. [CHG] No disagreement. The list is a valuable for discussion. > > -- Should we ask the ITU-T to allow us to derive I-Ds from new ITU-T Annexes > so they > can be reviewed by IETF process? I did that sort of transcription early on, > but > didn't continue because I wasn't sure our agreement with the ITU-T allowed it. > > [KJBII] I believe we should. Would the IETF allow the annexes to become > standards track docs? [CHG] I think the issue is that H.248 material the ITU is working on is available to the members of the list. I do not think it matters whether its in a IETF-draft format. This conversion can sometimes be an onerous editing exercise that does little to technically advance the work. Most of the work is available at the pictel website. At rapportuers meetings all the documents are publically available. There was some discussion about making approved H.248 recommendation available as RFCs, I can't remember whether this was formally agreed by the ITU TSB (something to check). A side issue is the review process. I firmly support that a document should undergo one organisations formal approval procedures (let me explain before you flame!). A document should be viewed and commented on by people from both the ITU and IETF. I believe today we have this arrangement as people can comment on the list and this in considered in the ITU. So if people decide to submit a work item in a particular organisation then it should be approved according that organisation rules taken into account comments from the other organisation. Having said that I think we have to recognise that quite a number of people follow both the ITU and IETF, we should get away from the mentality of throwing things over the fence. > > -- Package documents in general have been individual drafts, since we couldn't > add > them to the WG charter. This means the authors were free to submit them to > the IESG > without my intervention. With that in mind, does anyone believe that there is > an > IETF role for creation of package documents independently of the ITU-T? > > [KJBII] Since nothing stops anyone from creating a package, I do not see where > this would be a problem. However(!), it seems to me that the mandate for > standardizing packages has fallen to the ITU. So, I would think that if > someone wants to create a package and publish it informationally, then the > IETF is fine. If they would like to take it forward as a standard way of > performing whatever the package does, then it goes through the ITU. [CHG] If someone brings the work to the IETF then the opinion of the list should be taken into account. There should be some mechanism to prevent weird and wacky (couldn't think over other words) packages or packages that duplicate existing functionality from gaining psydo approval. We have the private package ID range for those sorts of things. > > Michael DiGioia wrote: > > Kevin, > > > >>> IETF does not seem interested in standardizing any packages. > > > > > > I don't believe I understand your comment. For many years the IETF has > > had a well know process of making protocols into drafts and then into > > approved standard RFC specifications. Do you imply by this that we > > should trash IETF? I would think not since we produced the Internet as > > it exists today. > > > >> From a telephony standpoint, I think I can see your point since the > >> ITU is > > > > the standards body for the telephony world. However, its a closed > > organization that tends to be run by the large telephone companies - > > i.e., not open to world participation without the necessary fees. > > > > This whole idea was accepted by this group back in 99/00 to have > > concurrent standards. Are we all now in agreement that this was a > > mistake? I was with the minority then against this idea and for a quick > > standard, produced by only the IETF, since this is how we (IETF) have > > been so successful in the past. > > > > I produced for my company the first IpTelephone which was at the first > > Bakeoff in NH. However, by that time, the idea of an IpTelephone using > > the media gateway protocols was not accepted by the larger community. > > > > Where is Vince, Tom, and Brian now? > > > > /mpd > > > > > > > > > > > > > >> From: "Kevin Boyle" > >> To: Michael DiGioia , > >> kengr@winphoria.com, Christian.Groves@ericsson.com.au, megaco@ietf.org > >> CC: bsteinka@telica.com > >> Subject: RE: [Megaco] Megaco CAS support > >> Date: Tue, 22 Apr 2003 17:26:15 -0400 > >> > >> With all due respect, the IETF had its chance to progress these (and > >> many > >> other) packages. In the interests of the larger community, I have > >> taken the > >> packages to the ITU for standardization, since the IETF does not seem > >> interested in standardizing any packages. > >> > >> The work in the IETF is not "up and running". The drafts published > >> by Hughes were published after the CAS packages were submitted to the > >> ITU. > >> > >> Given that the working group is in the process of winding down, I do > >> not see > >> any benefit to anyone in continuing to allow the IETF to hold up > >> standardization when the ITU is prepared to consider and advance the > >> work. > >> > >> Kevin > >> > >> -----Original Message----- > >> From: Michael DiGioia [mailto:michaeldigioia@hotmail.com] > >> Sent: Tuesday, April 22, 2003 5:01 PM > >> To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; > >> megaco@ietf.org > >> Cc: bsteinka@telica.com > >> Subject: Re: [Megaco] Megaco CAS support > >> > >> > >> > >> Christian, > >> > >> I agree, CAS should be part of the IETF similar to the original > >> MEGACO > >> draft > >> > >> work that held both organizations in sync. > >> > >> /mpd > >> > >> > >> > >> > >> >From: Aleksandr Ryabin > >> >To: Christian Groves , > >> >megaco@ietf.org > >> >CC: Brad Steinka > >> >Subject: Re: [Megaco] Megaco CAS support > >> >Date: Tue, 22 Apr 2003 10:30:01 -0400 > >> > > >> >Hi Christian, > >> > > >> >Then why are these brand new revisions of drafts were just recently > >> >submitted? > >> > > >> >http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.t > >> >xt > >> >http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt > >> > > >> >More over a quick look through reveals that some of the package > >> >items in icas > >> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same > >> >wording. > >> > > >> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary > >> >which does not seem to be defined in the document and also > >> >"conflicts" with above IETF "CAS Maintenance Package". > >> > > >> >There is also reference to r2 package in AVD-2316 nowhere found in > >> >ITU. > >> > > >> >Also basic CAS packages draft still available at: > >> >http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackag > >> >e-0 > >> >2.txt > >> >but it is slightly different (outdated?) from AVD-2315 ITU version > >> you have > >> > >> >specified. > >> > > >> >The recent submission of the above drafts had lead me to believe > >> >that CAS work is still quite "up and running" in IETF. This is all > >> >very confusing. When was it decided to move the work to ITU? Could > >> >someone point me out to some references (in IETF) of that please? > >> > > >> >My two cents on this topic: CAS is not an isolated package and in my > >> >opinion it would be much more productive to keep it on both channels > >> >(ITU and > >> IETF) > >> >and in sync, similar to some other items done so far in > >> >H.248/MEGACO. What other folks think about it? > >> > > >> >Also in any case can the authors of ITU and IETF CAS related > >> >packages work together to come up with some kind of game plan and > >> >post it to the list to avoid any further confusion and > >> >inconsistencies? > >> > > >> >Thanks! > >> > Aleks > >> > > >> >At 07:54 PM 4/21/2003, Christian Groves wrote: > >> >>G'Day Brad and Karl, > >> >> > >> >>I believe the intention is to move the CAS work into the ITU. The > >> >>contributions containing the latest drafts can be found at: > >> >>ftp://standard.pictel.com/avc-site/0302_San/ > >> >> > >> >>AVD-2312 MF Tone Generation and Detection Packages > >> >>AVD-2315 Basic CAS Packages > >> >>AVD-2316 International CAS Packages > >> >>AVD-2317 Enhanced Analog Line Packages > >> >> > >> >>Regards, Christian > >> >> > >> >>Brad Steinka wrote: > >> >> > > >> >> > There were several RFC draft document that described various > >> >> > packages > >> >>to > >> >> > support CAS, R1, R2, BCAS, etc. > >> >> > Most of these drafts have expired. > >> >> > > >> >> > Can anyone tell me what the latest RFCs are that support CAS > >> >> > calls and > >> >>where > >> >> > they are in the standards process? > >> >> > > >> >> > Thanks > >> >> > > >> >> > Brad Steinka > >> >> > Director - Software Engineering > >> >> > 734 Forest Street, Building G, Suite 100 > >> >> > Marlboro, Ma. 01752 > >> >> > Tel: 508-480-0909 x154 > >> >> > Email: bsteinka@telica.com > >> >> > Web: www.telica.com > >> >> > > >> >> > _______________________________________________ > >> >> > Megaco mailing list > >> >> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > >> >>_______________________________________________ > >> >>Megaco mailing list > >> >>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > >> > > >> >_______________________________________________ > >> >Megaco mailing list > >> >Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > >> > >> > >> _________________________________________________________________ > >> MSN 8 with e-mail virus protection service: 2 months FREE* > >> http://join.msn.com/?page=features/virus > >> > >> _______________________________________________ > >> Megaco mailing list > >> Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > >> _______________________________________________ > >> Megaco mailing list > >> Megaco@ietf.org > >> https://www1.ietf.org/mailman/listinfo/megaco > > > > > > > > _________________________________________________________________ > > The new MSN 8: smart spam protection and 2 months FREE* > > http://join.msn.com/?page=features/junkmail > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed May 14 02:30:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05907 for ; Wed, 14 May 2003 02:30:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4E5ufH02661 for megaco-archive@odin.ietf.org; Wed, 14 May 2003 01:56:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E5ueB02658 for ; Wed, 14 May 2003 01:56:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05617 for ; Wed, 14 May 2003 02:29:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fpnj-00032E-00 for megaco-web-archive@ietf.org; Wed, 14 May 2003 02:31:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Fpni-00032B-00 for megaco-web-archive@ietf.org; Wed, 14 May 2003 02:31:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E5sZB02519; Wed, 14 May 2003 01:54:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E5rZB02486 for ; Wed, 14 May 2003 01:53:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03363 for ; Wed, 14 May 2003 02:26:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fpkj-0002jM-00 for megaco@ietf.org; Wed, 14 May 2003 02:28:37 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19Fpkh-0002jJ-00 for megaco@ietf.org; Wed, 14 May 2003 02:28:35 -0400 Received: from brsf10.epa.ericsson.se ([61.88.9.226]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h4E6R1425429; Wed, 14 May 2003 16:27:01 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h4E6TN006792; Wed, 14 May 2003 16:29:23 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.236.75]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JB83ANX0; Wed, 14 May 2003 16:29:22 +1000 Message-ID: <3EC1A070.CB7B901E@ericsson.com.au> Date: Wed, 14 May 2003 11:48:32 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Boyle , Tom Taylor CC: Michael DiGioia , kengr@winphoria.com, megaco@ietf.org, bsteinka@telica.com Subject: Re: [Megaco] Megaco CAS support References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit G'Day Tom and Kevin, Please see my comments [CHG]. Regards, Christian Kevin Boyle wrote: > > Comments inline. [KJBII] > > Kevin > > -----Original Message----- > From: Tom Taylor [mailto:taylor@nortelnetworks.com] > Sent: Tuesday, May 13, 2003 8:38 AM > To: Michael DiGioia > Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; kengr@winphoria.com; > Christian.Groves@ericsson.com.au; megaco@ietf.org; bsteinka@telica.com > > Subject: Re: [Megaco] Megaco CAS support > > The day this was written, I was on the operating table. Today is the first > day I > have been in a position to respond. > > [KJBII] Welcome back! > > Kevin's frustration with the IETF process is my fault for not providing > adequate > leadership. For that I apologize. It stems to some extent from a confusion > of > objectives in my own working life. That said: > -- the IESG has been unwilling to expand the Megaco charter to include > packages > -- at this point, the IESG is ready to terminate the Working Group (BUT KEEP > THE LIST). > > It is up to us to determine a working relationship with the ITU-T that will > keep the > work moving in everybody's best interest. I should point out that SG 16 > itself is > not having an easy time of it -- attendance has dropped drastically in the > last > couple of years. The ITU-T is approaching one of those intervals when it > considers > reorganization, and we could find ourselves dealing with a different Study > Group > next year. [CHG] Regardless of the number of the Study Group we could be dealing with I think that we can safely assume that the ITUs work on H.248 will continue. > > I'll ask a couple of questions to shape discussion of how we should proceed > from here: > > -- It seems self-evident to me that the Megaco list should continue to be the > primary source of material for the Implementor's Guide. Any disagreement? > > [KJBII] The list has always been the definitive source, so I see no reason to > change this. [CHG] No disagreement. The list is a valuable for discussion. > > -- Should we ask the ITU-T to allow us to derive I-Ds from new ITU-T Annexes > so they > can be reviewed by IETF process? I did that sort of transcription early on, > but > didn't continue because I wasn't sure our agreement with the ITU-T allowed it. > > [KJBII] I believe we should. Would the IETF allow the annexes to become > standards track docs? [CHG] I think the issue is that H.248 material the ITU is working on is available to the members of the list. I do not think it matters whether its in a IETF-draft format. This conversion can sometimes be an onerous editing exercise that does little to technically advance the work. Most of the work is available at the pictel website. At rapportuers meetings all the documents are publically available. There was some discussion about making approved H.248 recommendation available as RFCs, I can't remember whether this was formally agreed by the ITU TSB (something to check). A side issue is the review process. I firmly support that a document should undergo one organisations formal approval procedures (let me explain before you flame!). A document should be viewed and commented on by people from both the ITU and IETF. I believe today we have this arrangement as people can comment on the list and this in considered in the ITU. So if people decide to submit a work item in a particular organisation then it should be approved according that organisation rules taken into account comments from the other organisation. Having said that I think we have to recognise that quite a number of people follow both the ITU and IETF, we should get away from the mentality of throwing things over the fence. > > -- Package documents in general have been individual drafts, since we couldn't > add > them to the WG charter. This means the authors were free to submit them to > the IESG > without my intervention. With that in mind, does anyone believe that there is > an > IETF role for creation of package documents independently of the ITU-T? > > [KJBII] Since nothing stops anyone from creating a package, I do not see where > this would be a problem. However(!), it seems to me that the mandate for > standardizing packages has fallen to the ITU. So, I would think that if > someone wants to create a package and publish it informationally, then the > IETF is fine. If they would like to take it forward as a standard way of > performing whatever the package does, then it goes through the ITU. [CHG] If someone brings the work to the IETF then the opinion of the list should be taken into account. There should be some mechanism to prevent weird and wacky (couldn't think over other words) packages or packages that duplicate existing functionality from gaining psydo approval. We have the private package ID range for those sorts of things. > > Michael DiGioia wrote: > > Kevin, > > > >>> IETF does not seem interested in standardizing any packages. > > > > > > I don't believe I understand your comment. For many years the IETF has > > had a well know process of making protocols into drafts and then into > > approved standard RFC specifications. Do you imply by this that we > > should trash IETF? I would think not since we produced the Internet as > > it exists today. > > > >> From a telephony standpoint, I think I can see your point since the > >> ITU is > > > > the standards body for the telephony world. However, its a closed > > organization that tends to be run by the large telephone companies - > > i.e., not open to world participation without the necessary fees. > > > > This whole idea was accepted by this group back in 99/00 to have > > concurrent standards. Are we all now in agreement that this was a > > mistake? I was with the minority then against this idea and for a quick > > standard, produced by only the IETF, since this is how we (IETF) have > > been so successful in the past. > > > > I produced for my company the first IpTelephone which was at the first > > Bakeoff in NH. However, by that time, the idea of an IpTelephone using > > the media gateway protocols was not accepted by the larger community. > > > > Where is Vince, Tom, and Brian now? > > > > /mpd > > > > > > > > > > > > > >> From: "Kevin Boyle" > >> To: Michael DiGioia , > >> kengr@winphoria.com, Christian.Groves@ericsson.com.au, megaco@ietf.org > >> CC: bsteinka@telica.com > >> Subject: RE: [Megaco] Megaco CAS support > >> Date: Tue, 22 Apr 2003 17:26:15 -0400 > >> > >> With all due respect, the IETF had its chance to progress these (and > >> many > >> other) packages. In the interests of the larger community, I have > >> taken the > >> packages to the ITU for standardization, since the IETF does not seem > >> interested in standardizing any packages. > >> > >> The work in the IETF is not "up and running". The drafts published > >> by Hughes were published after the CAS packages were submitted to the > >> ITU. > >> > >> Given that the working group is in the process of winding down, I do > >> not see > >> any benefit to anyone in continuing to allow the IETF to hold up > >> standardization when the ITU is prepared to consider and advance the > >> work. > >> > >> Kevin > >> > >> -----Original Message----- > >> From: Michael DiGioia [mailto:michaeldigioia@hotmail.com] > >> Sent: Tuesday, April 22, 2003 5:01 PM > >> To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; > >> megaco@ietf.org > >> Cc: bsteinka@telica.com > >> Subject: Re: [Megaco] Megaco CAS support > >> > >> > >> > >> Christian, > >> > >> I agree, CAS should be part of the IETF similar to the original > >> MEGACO > >> draft > >> > >> work that held both organizations in sync. > >> > >> /mpd > >> > >> > >> > >> > >> >From: Aleksandr Ryabin > >> >To: Christian Groves , > >> >megaco@ietf.org > >> >CC: Brad Steinka > >> >Subject: Re: [Megaco] Megaco CAS support > >> >Date: Tue, 22 Apr 2003 10:30:01 -0400 > >> > > >> >Hi Christian, > >> > > >> >Then why are these brand new revisions of drafts were just recently > >> >submitted? > >> > > >> >http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.t > >> >xt > >> >http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt > >> > > >> >More over a quick look through reveals that some of the package > >> >items in icas > >> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same > >> >wording. > >> > > >> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary > >> >which does not seem to be defined in the document and also > >> >"conflicts" with above IETF "CAS Maintenance Package". > >> > > >> >There is also reference to r2 package in AVD-2316 nowhere found in > >> >ITU. > >> > > >> >Also basic CAS packages draft still available at: > >> >http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackag > >> >e-0 > >> >2.txt > >> >but it is slightly different (outdated?) from AVD-2315 ITU version > >> you have > >> > >> >specified. > >> > > >> >The recent submission of the above drafts had lead me to believe > >> >that CAS work is still quite "up and running" in IETF. This is all > >> >very confusing. When was it decided to move the work to ITU? Could > >> >someone point me out to some references (in IETF) of that please? > >> > > >> >My two cents on this topic: CAS is not an isolated package and in my > >> >opinion it would be much more productive to keep it on both channels > >> >(ITU and > >> IETF) > >> >and in sync, similar to some other items done so far in > >> >H.248/MEGACO. What other folks think about it? > >> > > >> >Also in any case can the authors of ITU and IETF CAS related > >> >packages work together to come up with some kind of game plan and > >> >post it to the list to avoid any further confusion and > >> >inconsistencies? > >> > > >> >Thanks! > >> > Aleks > >> > > >> >At 07:54 PM 4/21/2003, Christian Groves wrote: > >> >>G'Day Brad and Karl, > >> >> > >> >>I believe the intention is to move the CAS work into the ITU. The > >> >>contributions containing the latest drafts can be found at: > >> >>ftp://standard.pictel.com/avc-site/0302_San/ > >> >> > >> >>AVD-2312 MF Tone Generation and Detection Packages > >> >>AVD-2315 Basic CAS Packages > >> >>AVD-2316 International CAS Packages > >> >>AVD-2317 Enhanced Analog Line Packages > >> >> > >> >>Regards, Christian > >> >> > >> >>Brad Steinka wrote: > >> >> > > >> >> > There were several RFC draft document that described various > >> >> > packages > >> >>to > >> >> > support CAS, R1, R2, BCAS, etc. > >> >> > Most of these drafts have expired. > >> >> > > >> >> > Can anyone tell me what the latest RFCs are that support CAS > >> >> > calls and > >> >>where > >> >> > they are in the standards process? > >> >> > > >> >> > Thanks > >> >> > > >> >> > Brad Steinka > >> >> > Director - Software Engineering > >> >> > 734 Forest Street, Building G, Suite 100 > >> >> > Marlboro, Ma. 01752 > >> >> > Tel: 508-480-0909 x154 > >> >> > Email: bsteinka@telica.com > >> >> > Web: www.telica.com > >> >> > > >> >> > _______________________________________________ > >> >> > Megaco mailing list > >> >> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > >> >>_______________________________________________ > >> >>Megaco mailing list > >> >>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > >> > > >> >_______________________________________________ > >> >Megaco mailing list > >> >Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > >> > >> > >> _________________________________________________________________ > >> MSN 8 with e-mail virus protection service: 2 months FREE* > >> http://join.msn.com/?page=features/virus > >> > >> _______________________________________________ > >> Megaco mailing list > >> Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > >> _______________________________________________ > >> Megaco mailing list > >> Megaco@ietf.org > >> https://www1.ietf.org/mailman/listinfo/megaco > > > > > > > > _________________________________________________________________ > > The new MSN 8: smart spam protection and 2 months FREE* > > http://join.msn.com/?page=features/junkmail > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed May 14 19:20:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09925 for ; Wed, 14 May 2003 19:20:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EMjdB26374; Wed, 14 May 2003 18:45:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EMh7B26306 for ; Wed, 14 May 2003 18:43:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09863 for ; Wed, 14 May 2003 19:15:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G5VM-0002Ce-00 for megaco@ietf.org; Wed, 14 May 2003 19:17:48 -0400 Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com) by ietf-mx with esmtp (Exim 4.12) id 19G5VL-0002CY-00 for megaco@ietf.org; Wed, 14 May 2003 19:17:47 -0400 Received: from tekelec.com ([172.25.11.41]) by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12) with ESMTP id 2003051418181818:3962 ; Wed, 14 May 2003 18:18:18 -0500 Message-ID: <3EC2D06A.70004@tekelec.com> Date: Wed, 14 May 2003 18:25:30 -0500 From: Adrian Soncodi User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Tom Taylor CC: megaco@ietf.org Subject: Re: [Megaco] Support for redundant MG failover References: <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com> <3EA98F66.C6890B54@motorola.com> <3EA99A2E.4DC6BD7D@cisco.com> <3EA9DC82.136119A3@motorola.com> <3EA9F2B5.FEBAA43@cisco.com> <3EACEC44.96FF416A@alcatel.es> <3EADAE09.1010600@tekelec.com> <3EC13AE1.8080106@nortelnetworks.com> <3EC156C0.4040300@tekelec.com> <3EC18F30.3010804@nortelnetworks.com> X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12 |February 13, 2003) at 05/14/2003 06:18:18 PM, Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12 |February 13, 2003) at 05/14/2003 06:18:56 PM, Serialize complete at 05/14/2003 06:18:56 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tom Taylor wrote: > Ok, I'll work a bit harder. > > First point: I'd say the control association is uniquely identified > by the mId of each peer, but is associated with transport (and much > other) state. I've always thought of the mId part of the message as > an identifier, not necessarily tied to an address, even if that is > what the syntax suggests. The syntax also allows an mId which is > simply a NAME. Hence I do not believe the protocol as it stands > identifies a control association with a network address. > > This means it is quite feasible to associate a control association > with multiple addresses at either end. The protocol has a way to > allow you to express additional information of this sort if you need > to pass it at the application level: you provide it as properties > defined in a package. > > Second point: pre-start-up is by definition outside the scope of the > protocol, since the protocol has yet to operate. The SRV record > approach used by SIP is only one alternative of a number that SIP > offers. All we can standardize (as we have already done) is that an > initial condition for the operation of the protocol is that the MG > knows what TRANSPORT (not NETWORK) address it should use to reach the > MGC. How it determines that transport address is up to the > implementation. Indeed, I need to qualify: When I say "IP address", it's just a shorthand for "IP address + TCP/UDP/SCTP port", which is a transport address. So we are not really talking about network addresses. > > For SCTP the initial transport address used is that of the initial > primary path. That doesn't prevent the use of multihoming; the peers > supply the alternative addresses as part of the SCTP protocol > exchange, and there is no need for Megaco to account for them explicitly. But this approach has one big disadvantage: If the interface corresponding to the initial transport address is down, you don't get to find out about additional alternative addresses in subsequent protocol exchanges. This substantially diminishes the usefulness of multi-homing for redundancy. This problem could be avoided by allowing an MG/MGC to be provisioned with 2 or more transport addresses for the remote peer (and having the MG use them from the beginning, e.g. for the SCTP INIT). But people tend to think that the main spec does not allow more than one transport address (for example, the MEGACO MIB only specifies one per MG/MGC). So how should it be? Adrian > If you want to use UDP instead of SCTP, you have to agree on a similar > exchange of information. I've already pointed out above how this > could be done, by setting and reading of ROOT properties on the MG. > > Adrian Soncodi wrote: > >> >> Tom Taylor wrote: >> >>> It seems to me that the outlines of a solution have been sketched in >>> Fernando's note. >> >> >> >> >> Tom, >> >> I don't quite understand, can you elaborate on this statement? I was >> trying to make the point that, for multi-homing, we could allow 2 or >> more IP addresses per MG and/or MGC, which would make it simpler to >> establish for example one SCTP association using all of them. >> >> Initially, Fernando said that 1 MEGACO control association = 1 IP >> address, and implied that 2 IP addresses would be viewed as 2 >> distinct MGCs. But in this case: >> - explaining which MGC pairs with which other MGC as multi-homed >> entities is more difficult, >> - plus, if an SCTP association uses more than 1 IP address (which it >> should, in order to take advantage of multi-homing), then it would >> mean that 1 control association spans 2 MGCs, which seems to >> contradict the model. Handoff and failover wouldn't work in this >> case, because MEGACO does not control the selection of the IP >> addresses withing the SCTP layer. >> >> Therefore, what do you think about the number of IP addresses per >> MG/MGC? If SCTP is allowed to use only one IP address per entity, >> then why would one ever use SCTP instead of TCP? My understanding is >> SCTP was supposed to be a solution for multi-homing. >> >> Additionally (I don't know if you followed the whole discussion in >> this thread), a number of people have expressed interest in >> supporting multi-homing over UDP too. This would also benefit from >> allowing multiple IP addresses per MG/MGC, but a few clarification in >> the procedures would be required. Would you be willing to consider >> adding this additional functionality? >> >> Regards, >> >> Adrian >> >> >>> Al the information to support multi-homing and the associated >>> behaviour can be introduced through a set of ROOT properties that >>> can be either provisioned on the MG or set there after the initial >>> control association has been established. >>> >>> >>> Adrian Soncodi wrote: >>> >>>> >>>> >>>> Fernando Vallejo Lazaro wrote: >>>> >>>>> Hi, >>>>> >>>>> I agree with Flemming that Megaco should be based on UDP and TCP. >>>>> SCTP is not widely deployed and can lead to problems of >>>>> interoperability. >>>>> I would leave it as optional. >>>>> >>>>> For me the control association is clearly defined and it is 1 >>>>> association = 1 IP address. >>>>> Why? Because the assocation is done through a ServiceChange >>>>> Restart message which involves >>>>> an IP address (in the MGC ID) and not a domain name. If the DNS >>>>> returns more than >>>>> one IP address for a given name the MG must choose one of them. >>>>> >>>> This is how one would be tempted to interpret the spec today, >>>> although it is not explicitly stated. But as I have mentioned in a >>>> previous e-mail, this is not adequate for SCTP, where one would >>>> like to know that the 2 IP addresses are on the same machine, to be >>>> able to use them within a single SCTP association. >>>> >>>> Also, the following quote from section 7.2.8 seems to indicate more >>>> than 1 IP address is possible: >>>> >>>> "The ServiceChangeAddress provides an address to be used within >>>> the Context of the association currently being negotiated ..." >>>> >>>> Since this is in the reply to ServiceChange, it looks like it can >>>> actually be a different IP address (which then must be interpreted >>>> in the context of the current association ...). Otherwise, why >>>> would the MGC return the same IP address as the destination IP >>>> address of the ServiceChange message? The MG already knows that one! >>>> >>>>> What I feel is that the gap is in the definition of the secondary >>>>> MGCs and its provisionning. >>>>> I think there should be a way in which the MGC could inform the >>>>> MGs about existing secondaries >>>>> MGCs. Now this can only be done using a HandOff method but >>>>> sometimes this message cannot >>>>> be sent by the primary MGC (e.g. network failure, crash of the MGC >>>>> ...). >>>>> So it would be useful to add a new method in the ServiceChange to >>>>> send this information and add >>>>> a new parameter indicating what type of relationship there is >>>>> between primary and secondary >>>>> (e.g. mirror, backup, independent, third party.....) >>>>> So in case a MGC is multihomed it could inform the MG at startup >>>>> that a MGC exists which is a >>>>> secondary mirror MGC (which corresponds to the same MGC but with >>>>> another IP address). >>>>> This process can be independent on the actual procedures done by >>>>> the operators to declare >>>>> secondary MGCs. >>>>> >>>> I'm not sure a "mirror MGC" is the same MGC with another IP >>>> address. Some people would interpret "mirrored" as different >>>> machines, with some state synchronization between them... >>>> >>>> Anyway, considering 2 or more multi-homed MGCs, i.e. 4 or more IP >>>> addresses, and if each IP address is a different MGC, then it >>>> becomes quite cumbersome to signal which one is paired with which >>>> one. I think it would be simpler and more clear to allow an MG to >>>> be provisioned with more than one IP address per MGC. Then you >>>> would immediately know the MGC is multi-homed. This works more >>>> elegantly with SCTP, and also with DNS, which can return several IP >>>> addresses for an FQDN. >>>> >>>> Adrian >>>> >>>>> When a problem arises the MG can act in two ways: >>>>> 1) If the new MGC is a mirror (maybe other types can be included >>>>> here) it can resend the transactions >>>>> which have failed in the old one. >>>>> 2) If the new MGC is not a mirror it should try to establish a >>>>> connection with a ServiceChange as defined >>>>> in the megaco protocol. Then the MGC is in charge of recovering >>>>> the state of the MG ASAP and the service. >>>>> >>>>> In this way not too much work has to be added and we can >>>>> accomplish a solution. >>>>> >>>>> Regards >>>>> Fernando >>>>> >>>>> >>>>> Flemming Andreasen wrote: >>>>> >>>>>> Qiaobing >>>>>> >>>>>> Nobody is denying that SCTP is an existing spec that solves the >>>>>> multihoming problem and it >>>>>> is quite understandable that you in particular advocate it. >>>>>> However, you seem to have lost >>>>>> sight of the original question in this thread, which was about >>>>>> native Megaco protocol >>>>>> support for redundancy and failover, and as part of that, support >>>>>> for multihoming. Initial >>>>>> claims was that Megaco fully supports this, but we seem to have >>>>>> converged on the opinion >>>>>> that it does not, unless you use SCTP, which is not part of the >>>>>> base Megaco protocol. >>>>>> Furthermore, despite everything, the fact of the matter is that >>>>>> for various reasons, not >>>>>> everybody will be implementing SCTP at least for now (NATs, >>>>>> firewalls and security do not >>>>>> help SCTP here) and since UDP and TCP are the basic requirements, >>>>>> it would have been nice to >>>>>> have better mechanisms for these; it can be done very easily (see >>>>>> MGCP for example). >>>>>> Sometimes, it's good to be a bit pragmatic. >>>>>> >>>>>> -- Flemming >>>>>> >>>>>> Qiaobing Xie wrote: >>>>>> >>>>>> > (Try to respond to similar remarks from two mails) >>>>>> > >>>>>> > Flemming Andreasen wrote: >>>>>> > ... >>>>>> > > In any case, SCTP is there as an option today for those >>>>>> > > that wish to use it. For those that don't, we've already >>>>>> concluded that >>>>>> > > multihoming/redundancy/failover is not very well supported, >>>>>> and that there doesn't >>>>>> > > seem to be much desire to change that. I personally think >>>>>> that's a bit of a shame, but >>>>>> > > so be it. >>>>>> > ... >>>>>> > >>>>>> > Adrian Soncodi wrote: >>>>>> > ... >>>>>> > > You seem to say "if you want multi-homing, it must be only >>>>>> over SCTP". >>>>>> > > Why? Someone could similarly say "if you want MEGACO, it must >>>>>> be over >>>>>> > > UDP". But we don't, we allow all 3 protocols, for flexibility. >>>>>> > > >>>>>> > >>>>>> > I didn't mean to say "you must". I was under the impression >>>>>> that some of >>>>>> > us were saying that we had a technical issue to support >>>>>> multi-homing in >>>>>> > MEGACO, and my response was essentially "this is not an issue, >>>>>> there are >>>>>> > protocol specs existing in IETF to do just that, which is >>>>>> > MEGACO/H.248-Annex-H plus SCTP." Now, I think what I am hearing >>>>>> is, it >>>>>> > is not really about the lack of a solution, it's more about >>>>>> that some of >>>>>> > us just don't want to use the existing IETF solution (for whatever >>>>>> > non-tech reasons, or simply just don't wish to use it) and >>>>>> prefer to >>>>>> > define another solution in IETF. Well, if that is the case, I >>>>>> don't have >>>>>> > much else to say... >>>>>> > >>>>>> > Of cause, if there are tech >>>>>> issues/shortcomings/drawbacks/advantages >>>>>> > related to using SCTP for MEGACO multi-homing support, I'd be >>>>>> more than >>>>>> > glad to help answer. >>>>>> > >>>>>> > -Qiaobing >>>>>> >>>>> -- >>>>> Fernando Vallejo Lazaro >>>>> Phone: +34 91 330 5614 >>>>> SW Wireline ASD-Madrid >>>>> ALCATEL >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Megaco mailing list >>>> Megaco@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/megaco >>>> >>> >>> >> >> >> > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed May 14 19:21:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09994 for ; Wed, 14 May 2003 19:21:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4EMm0I26490 for megaco-archive@odin.ietf.org; Wed, 14 May 2003 18:48:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EMm0B26487 for ; Wed, 14 May 2003 18:48:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09979 for ; Wed, 14 May 2003 19:20:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G5a5-0002Fh-00 for megaco-web-archive@ietf.org; Wed, 14 May 2003 19:22:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19G5a4-0002Fd-00 for megaco-web-archive@ietf.org; Wed, 14 May 2003 19:22:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EMjdB26374; Wed, 14 May 2003 18:45:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EMh7B26306 for ; Wed, 14 May 2003 18:43:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09863 for ; Wed, 14 May 2003 19:15:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G5VM-0002Ce-00 for megaco@ietf.org; Wed, 14 May 2003 19:17:48 -0400 Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com) by ietf-mx with esmtp (Exim 4.12) id 19G5VL-0002CY-00 for megaco@ietf.org; Wed, 14 May 2003 19:17:47 -0400 Received: from tekelec.com ([172.25.11.41]) by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12) with ESMTP id 2003051418181818:3962 ; Wed, 14 May 2003 18:18:18 -0500 Message-ID: <3EC2D06A.70004@tekelec.com> Date: Wed, 14 May 2003 18:25:30 -0500 From: Adrian Soncodi User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Tom Taylor CC: megaco@ietf.org Subject: Re: [Megaco] Support for redundant MG failover References: <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com> <3EA98F66.C6890B54@motorola.com> <3EA99A2E.4DC6BD7D@cisco.com> <3EA9DC82.136119A3@motorola.com> <3EA9F2B5.FEBAA43@cisco.com> <3EACEC44.96FF416A@alcatel.es> <3EADAE09.1010600@tekelec.com> <3EC13AE1.8080106@nortelnetworks.com> <3EC156C0.4040300@tekelec.com> <3EC18F30.3010804@nortelnetworks.com> X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12 |February 13, 2003) at 05/14/2003 06:18:18 PM, Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12 |February 13, 2003) at 05/14/2003 06:18:56 PM, Serialize complete at 05/14/2003 06:18:56 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tom Taylor wrote: > Ok, I'll work a bit harder. > > First point: I'd say the control association is uniquely identified > by the mId of each peer, but is associated with transport (and much > other) state. I've always thought of the mId part of the message as > an identifier, not necessarily tied to an address, even if that is > what the syntax suggests. The syntax also allows an mId which is > simply a NAME. Hence I do not believe the protocol as it stands > identifies a control association with a network address. > > This means it is quite feasible to associate a control association > with multiple addresses at either end. The protocol has a way to > allow you to express additional information of this sort if you need > to pass it at the application level: you provide it as properties > defined in a package. > > Second point: pre-start-up is by definition outside the scope of the > protocol, since the protocol has yet to operate. The SRV record > approach used by SIP is only one alternative of a number that SIP > offers. All we can standardize (as we have already done) is that an > initial condition for the operation of the protocol is that the MG > knows what TRANSPORT (not NETWORK) address it should use to reach the > MGC. How it determines that transport address is up to the > implementation. Indeed, I need to qualify: When I say "IP address", it's just a shorthand for "IP address + TCP/UDP/SCTP port", which is a transport address. So we are not really talking about network addresses. > > For SCTP the initial transport address used is that of the initial > primary path. That doesn't prevent the use of multihoming; the peers > supply the alternative addresses as part of the SCTP protocol > exchange, and there is no need for Megaco to account for them explicitly. But this approach has one big disadvantage: If the interface corresponding to the initial transport address is down, you don't get to find out about additional alternative addresses in subsequent protocol exchanges. This substantially diminishes the usefulness of multi-homing for redundancy. This problem could be avoided by allowing an MG/MGC to be provisioned with 2 or more transport addresses for the remote peer (and having the MG use them from the beginning, e.g. for the SCTP INIT). But people tend to think that the main spec does not allow more than one transport address (for example, the MEGACO MIB only specifies one per MG/MGC). So how should it be? Adrian > If you want to use UDP instead of SCTP, you have to agree on a similar > exchange of information. I've already pointed out above how this > could be done, by setting and reading of ROOT properties on the MG. > > Adrian Soncodi wrote: > >> >> Tom Taylor wrote: >> >>> It seems to me that the outlines of a solution have been sketched in >>> Fernando's note. >> >> >> >> >> Tom, >> >> I don't quite understand, can you elaborate on this statement? I was >> trying to make the point that, for multi-homing, we could allow 2 or >> more IP addresses per MG and/or MGC, which would make it simpler to >> establish for example one SCTP association using all of them. >> >> Initially, Fernando said that 1 MEGACO control association = 1 IP >> address, and implied that 2 IP addresses would be viewed as 2 >> distinct MGCs. But in this case: >> - explaining which MGC pairs with which other MGC as multi-homed >> entities is more difficult, >> - plus, if an SCTP association uses more than 1 IP address (which it >> should, in order to take advantage of multi-homing), then it would >> mean that 1 control association spans 2 MGCs, which seems to >> contradict the model. Handoff and failover wouldn't work in this >> case, because MEGACO does not control the selection of the IP >> addresses withing the SCTP layer. >> >> Therefore, what do you think about the number of IP addresses per >> MG/MGC? If SCTP is allowed to use only one IP address per entity, >> then why would one ever use SCTP instead of TCP? My understanding is >> SCTP was supposed to be a solution for multi-homing. >> >> Additionally (I don't know if you followed the whole discussion in >> this thread), a number of people have expressed interest in >> supporting multi-homing over UDP too. This would also benefit from >> allowing multiple IP addresses per MG/MGC, but a few clarification in >> the procedures would be required. Would you be willing to consider >> adding this additional functionality? >> >> Regards, >> >> Adrian >> >> >>> Al the information to support multi-homing and the associated >>> behaviour can be introduced through a set of ROOT properties that >>> can be either provisioned on the MG or set there after the initial >>> control association has been established. >>> >>> >>> Adrian Soncodi wrote: >>> >>>> >>>> >>>> Fernando Vallejo Lazaro wrote: >>>> >>>>> Hi, >>>>> >>>>> I agree with Flemming that Megaco should be based on UDP and TCP. >>>>> SCTP is not widely deployed and can lead to problems of >>>>> interoperability. >>>>> I would leave it as optional. >>>>> >>>>> For me the control association is clearly defined and it is 1 >>>>> association = 1 IP address. >>>>> Why? Because the assocation is done through a ServiceChange >>>>> Restart message which involves >>>>> an IP address (in the MGC ID) and not a domain name. If the DNS >>>>> returns more than >>>>> one IP address for a given name the MG must choose one of them. >>>>> >>>> This is how one would be tempted to interpret the spec today, >>>> although it is not explicitly stated. But as I have mentioned in a >>>> previous e-mail, this is not adequate for SCTP, where one would >>>> like to know that the 2 IP addresses are on the same machine, to be >>>> able to use them within a single SCTP association. >>>> >>>> Also, the following quote from section 7.2.8 seems to indicate more >>>> than 1 IP address is possible: >>>> >>>> "The ServiceChangeAddress provides an address to be used within >>>> the Context of the association currently being negotiated ..." >>>> >>>> Since this is in the reply to ServiceChange, it looks like it can >>>> actually be a different IP address (which then must be interpreted >>>> in the context of the current association ...). Otherwise, why >>>> would the MGC return the same IP address as the destination IP >>>> address of the ServiceChange message? The MG already knows that one! >>>> >>>>> What I feel is that the gap is in the definition of the secondary >>>>> MGCs and its provisionning. >>>>> I think there should be a way in which the MGC could inform the >>>>> MGs about existing secondaries >>>>> MGCs. Now this can only be done using a HandOff method but >>>>> sometimes this message cannot >>>>> be sent by the primary MGC (e.g. network failure, crash of the MGC >>>>> ...). >>>>> So it would be useful to add a new method in the ServiceChange to >>>>> send this information and add >>>>> a new parameter indicating what type of relationship there is >>>>> between primary and secondary >>>>> (e.g. mirror, backup, independent, third party.....) >>>>> So in case a MGC is multihomed it could inform the MG at startup >>>>> that a MGC exists which is a >>>>> secondary mirror MGC (which corresponds to the same MGC but with >>>>> another IP address). >>>>> This process can be independent on the actual procedures done by >>>>> the operators to declare >>>>> secondary MGCs. >>>>> >>>> I'm not sure a "mirror MGC" is the same MGC with another IP >>>> address. Some people would interpret "mirrored" as different >>>> machines, with some state synchronization between them... >>>> >>>> Anyway, considering 2 or more multi-homed MGCs, i.e. 4 or more IP >>>> addresses, and if each IP address is a different MGC, then it >>>> becomes quite cumbersome to signal which one is paired with which >>>> one. I think it would be simpler and more clear to allow an MG to >>>> be provisioned with more than one IP address per MGC. Then you >>>> would immediately know the MGC is multi-homed. This works more >>>> elegantly with SCTP, and also with DNS, which can return several IP >>>> addresses for an FQDN. >>>> >>>> Adrian >>>> >>>>> When a problem arises the MG can act in two ways: >>>>> 1) If the new MGC is a mirror (maybe other types can be included >>>>> here) it can resend the transactions >>>>> which have failed in the old one. >>>>> 2) If the new MGC is not a mirror it should try to establish a >>>>> connection with a ServiceChange as defined >>>>> in the megaco protocol. Then the MGC is in charge of recovering >>>>> the state of the MG ASAP and the service. >>>>> >>>>> In this way not too much work has to be added and we can >>>>> accomplish a solution. >>>>> >>>>> Regards >>>>> Fernando >>>>> >>>>> >>>>> Flemming Andreasen wrote: >>>>> >>>>>> Qiaobing >>>>>> >>>>>> Nobody is denying that SCTP is an existing spec that solves the >>>>>> multihoming problem and it >>>>>> is quite understandable that you in particular advocate it. >>>>>> However, you seem to have lost >>>>>> sight of the original question in this thread, which was about >>>>>> native Megaco protocol >>>>>> support for redundancy and failover, and as part of that, support >>>>>> for multihoming. Initial >>>>>> claims was that Megaco fully supports this, but we seem to have >>>>>> converged on the opinion >>>>>> that it does not, unless you use SCTP, which is not part of the >>>>>> base Megaco protocol. >>>>>> Furthermore, despite everything, the fact of the matter is that >>>>>> for various reasons, not >>>>>> everybody will be implementing SCTP at least for now (NATs, >>>>>> firewalls and security do not >>>>>> help SCTP here) and since UDP and TCP are the basic requirements, >>>>>> it would have been nice to >>>>>> have better mechanisms for these; it can be done very easily (see >>>>>> MGCP for example). >>>>>> Sometimes, it's good to be a bit pragmatic. >>>>>> >>>>>> -- Flemming >>>>>> >>>>>> Qiaobing Xie wrote: >>>>>> >>>>>> > (Try to respond to similar remarks from two mails) >>>>>> > >>>>>> > Flemming Andreasen wrote: >>>>>> > ... >>>>>> > > In any case, SCTP is there as an option today for those >>>>>> > > that wish to use it. For those that don't, we've already >>>>>> concluded that >>>>>> > > multihoming/redundancy/failover is not very well supported, >>>>>> and that there doesn't >>>>>> > > seem to be much desire to change that. I personally think >>>>>> that's a bit of a shame, but >>>>>> > > so be it. >>>>>> > ... >>>>>> > >>>>>> > Adrian Soncodi wrote: >>>>>> > ... >>>>>> > > You seem to say "if you want multi-homing, it must be only >>>>>> over SCTP". >>>>>> > > Why? Someone could similarly say "if you want MEGACO, it must >>>>>> be over >>>>>> > > UDP". But we don't, we allow all 3 protocols, for flexibility. >>>>>> > > >>>>>> > >>>>>> > I didn't mean to say "you must". I was under the impression >>>>>> that some of >>>>>> > us were saying that we had a technical issue to support >>>>>> multi-homing in >>>>>> > MEGACO, and my response was essentially "this is not an issue, >>>>>> there are >>>>>> > protocol specs existing in IETF to do just that, which is >>>>>> > MEGACO/H.248-Annex-H plus SCTP." Now, I think what I am hearing >>>>>> is, it >>>>>> > is not really about the lack of a solution, it's more about >>>>>> that some of >>>>>> > us just don't want to use the existing IETF solution (for whatever >>>>>> > non-tech reasons, or simply just don't wish to use it) and >>>>>> prefer to >>>>>> > define another solution in IETF. Well, if that is the case, I >>>>>> don't have >>>>>> > much else to say... >>>>>> > >>>>>> > Of cause, if there are tech >>>>>> issues/shortcomings/drawbacks/advantages >>>>>> > related to using SCTP for MEGACO multi-homing support, I'd be >>>>>> more than >>>>>> > glad to help answer. >>>>>> > >>>>>> > -Qiaobing >>>>>> >>>>> -- >>>>> Fernando Vallejo Lazaro >>>>> Phone: +34 91 330 5614 >>>>> SW Wireline ASD-Madrid >>>>> ALCATEL >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Megaco mailing list >>>> Megaco@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/megaco >>>> >>> >>> >> >> >> > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed May 14 21:07:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11712 for ; Wed, 14 May 2003 21:07:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4F0XFB32558; Wed, 14 May 2003 20:33:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4F0VwB32488 for ; Wed, 14 May 2003 20:31:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11668 for ; Wed, 14 May 2003 21:04:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G7Cf-0002mT-00 for megaco@ietf.org; Wed, 14 May 2003 21:06:37 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19G7Ce-0002mL-00 for megaco@ietf.org; Wed, 14 May 2003 21:06:36 -0400 Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 14 May 2003 21:07:14 -0400 Message-Id: <5.2.0.9.0.20030514195911.027a8320@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 14 May 2003 20:06:39 -0400 To: megaco@ietf.org From: Aleksandr Ryabin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 15 May 2003 01:07:14.0864 (UTC) FILETIME=[527D2300:01C31A7E] Subject: [Megaco] CAS suspend/resume processing Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, Current CAS packages draft found at ftp://standard.pictel.com/avc-site/0302_San/AVD-2315.zip does not seem to have any suspend/resume related events/signals. As a reference such processing is defined in MGCP in RFC 3064 CAS packages. Could the CAS draft authors add appropriate events, signals and procedures to current draft? Thanks Aleks _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed May 14 21:08:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11807 for ; Wed, 14 May 2003 21:08:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4F0ZIb32666 for megaco-archive@odin.ietf.org; Wed, 14 May 2003 20:35:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4F0ZHB32663 for ; Wed, 14 May 2003 20:35:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11761 for ; Wed, 14 May 2003 21:08:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G7Fs-0002nO-00 for megaco-web-archive@ietf.org; Wed, 14 May 2003 21:09:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19G7Fr-0002nL-00 for megaco-web-archive@ietf.org; Wed, 14 May 2003 21:09:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4F0XFB32558; Wed, 14 May 2003 20:33:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4F0VwB32488 for ; Wed, 14 May 2003 20:31:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11668 for ; Wed, 14 May 2003 21:04:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G7Cf-0002mT-00 for megaco@ietf.org; Wed, 14 May 2003 21:06:37 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19G7Ce-0002mL-00 for megaco@ietf.org; Wed, 14 May 2003 21:06:36 -0400 Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 14 May 2003 21:07:14 -0400 Message-Id: <5.2.0.9.0.20030514195911.027a8320@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 14 May 2003 20:06:39 -0400 To: megaco@ietf.org From: Aleksandr Ryabin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 15 May 2003 01:07:14.0864 (UTC) FILETIME=[527D2300:01C31A7E] Subject: [Megaco] CAS suspend/resume processing Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, Current CAS packages draft found at ftp://standard.pictel.com/avc-site/0302_San/AVD-2315.zip does not seem to have any suspend/resume related events/signals. As a reference such processing is defined in MGCP in RFC 3064 CAS packages. Could the CAS draft authors add appropriate events, signals and procedures to current draft? Thanks Aleks _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu May 15 09:07:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07891 for ; Thu, 15 May 2003 09:07:39 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FCXmB28796; Thu, 15 May 2003 08:33:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4F7HaB06497 for ; Thu, 15 May 2003 03:17:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00098 for ; Thu, 15 May 2003 03:50:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GDX4-0004y1-00 for megaco@ietf.org; Thu, 15 May 2003 03:52:06 -0400 Received: from [210.21.224.29] (helo=szsmtp.utstar.com.cn) by ietf-mx with esmtp (Exim 4.12) id 19GDX3-0004xy-00 for megaco@ietf.org; Thu, 15 May 2003 03:52:05 -0400 Received: from sz-nss-leonteng ([172.19.18.33]) by szsmtp.utstar.com.cn (8.11.1/8.11.1) with SMTP id h4F7qjf01694 for ; Thu, 15 May 2003 15:52:45 +0800 Message-Id: <200305150752.h4F7qjf01694@szsmtp.utstar.com.cn> From: "leon.teng" Reply-To: leon.teng@utstar.com To: "megaco@ietf.org" Organization: utstar X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====000_Dragon844788010462_=====" Date: Thu, 15 May 2003 15:52:41 +0800 X-Warning: 210.21.224.29 is a known spammer listed at sbl.spamhaus.org Subject: [Megaco] Question: Is there any package for FSK signal in H248 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --=====000_Dragon844788010462_===== Content-Type: multipart/alternative; boundary="=====002_Dragon844788010462_=====" --=====002_Dragon844788010462_===== Content-Type: text/plain; charset="GB2312" X-MIME-Autoconverted: from 8bit to base64 by szsmtp.utstar.com.cn id h4F7qjf01694 Content-Transfer-Encoding: base64 RGVhciBtZWdhY286DQogICAgSSBjYW4ndCBmaW5kIHN1Y2ggcGFja2FnZS4gQ2FuIGFueW9u ZSBoZWxwIHRlbGwgbWUgaWYgIHNvbWUgb3RoZXIgcGFja2FnZSBhY3QgYXMgdGhlIHNhbWUg ZnVjbnRpb24uDQqhoaGhDQoNClJlZ2FyZHMNCiAgICBsZW9uLnRlbmcNClVUU3RhcmNvbShD aGluYSkgTHRkLCBTaGVuemhlbiBPZmZpY2UgICAgICAgDQpUZWw6ICg4NikgNzU1LTI2OTUy ODk5LTM1MzkNCkZheDogKDg2KSA3NTUtMjY5ODM3ODYgDQpFbWFpbDogbGVvbi50ZW5nQHV0 c3Rhci5jb20NCkRhdGU6ICAyMDAzLTA1LTE1DQogoaGhoaGhoaGhoaGhICAgICAgICAgIA0K ICAgICAgICAgICAgICAgICAgICAgICANCg0KoaGhoaGhoaGhoaGhoaGhoaGhoaEgIKGhICAg DQqhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhDQo= --=====002_Dragon844788010462_===== Content-Type: text/html; charset="GB2312" X-MIME-Autoconverted: from 8bit to quoted-printable by szsmtp.utstar.com.cn id h4F7qjf01694 Content-Transfer-Encoding: quoted-printable
=
<= /TBODY>
Dear megaco:
    I can't find=20 such package. Can anyone help tell me if = ; some=20 other package act as the same fucntion.
=A1=A1=A1=A1
 
Regards<= /DIV>
    leon.teng
UTStarcom(China) Ltd, Shenzhen=20 Office      
Tel: (86= )=20 755-26952899-3539
Fax: (86) 755-26983786
Email: = leon.teng@utstar.c= om
Date:  2003-05-15
 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1          
      = ;            =      

=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1 =20 =A1=A1   
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1


--=====002_Dragon844788010462_=====-- --=====000_Dragon844788010462_===== Content-Type: image/gif; name="fox.gif" Content-Disposition: FoxmailIcon; filename="fox.gif" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhIwAfALMLAP///+Dg4OCgAOCAAOAAAMDA4KCgwKBgQIAAAGBggCAgIAAAAAAAAAAAAAAA AAAAACH/C05FVFNDQVBFMi4wAwHoAwAh+QQJDwALACwAAAAAIwAfAAAE+3DJSem5Na+jux3CxWWi Zx5DIgiD6Lrgan6FoYZDzuborKGDQKEAXBl1Al/lEgwUjcaeTClhBpDQ6ECypYqwzauAuOhSN8BY s6AoDBSjczW9atrcibicmQPZ229yS0AGNUEGCkIKghYiBgGQkZIKi4wHBoWSmgEGjHOXBZucnUov aJeYhUM1pD58fRifCbMJe2Atcy2qBbWlWEdfApmQvD5uMVktFyGhkr0mbllQtCjNxM8dhdJ9CZi8 l5I12BlDyTndw92rNeIUBe6RddyqCQEJfSn1Nu4Tw8TKB9TdQSFAAa19/CRYE0JkRL5aChCAoISg A6cFC4e0qqBgNlhEBLM0bNI4ToJBbwEofURQkcKjSKs2TlhJoGZNhrMQStjVTkNEmzbD8bLxLFXI DiqTKl0aAQAh+QQJDwALACwCAAAAIQAfAAAE+3DJSeW5Na+jux3CxWWi1x1DIgiD6Lrgan6FoYZD zuboXKGDQKEAXBl1At/kEgwUjcaeTMkMIKHRgUTrE12bVgFxwaUCY82CojBQjJSW86ppYyfecGYO RF+3lQY1BoN6gQZBBgpCCjOBQ48GLgYBlJWWCowZBZaUQ5GDm5yWBhqhokIigaeDpaeVqYOOnqQd pqJMcQcJuwkmm4+2UC0oB7K9HUKxjwFYTAKqnccVnryyUCIhtgHSFAE2EwmHMSu8KLYF3BMFGeJG 4YF3k5U16TUaewLvoeHAhty0GfDxQ7dtT4oE3tJ1MMivDgoBCqop9CBw1wIFCEBgQgCHL4LBYQqg YURgseMGFxFBBcA0EgHHjiJaEpg5Uwi6cBNNYKRJ09IQnDk1sBxKtGgEACH5BAkPAAsALAgAAAAb AB8AAAT7cMl56rz44H2GqBpnbVeXCMIArquHckNhnN9gp3ZHUnZQFB0XCvfaVQaBQHDI1BVFyBuz OZBURUsUMukBLq4Lg48SdG0LisJAEcKIfUfpdqZOtN0FZdkzT693EgZ5cYIGSAYKPgqAYYMgb0mR kQqLG4JwBpeSmwYkmnoHn5KZO5qPmYI/Mp2lP3oFEiAJswmMqZKwR6GqtZ6uuEcCnwW9GTcBAkkg H3mSxTxCWrQdzUnEGzbRAgmZxKG4MxhSQ9ya3KoyMs/ZTOfEAQnZA7MB4RPs5IUJQB4KtPb35JGb tUABgn4GAcmTV0GBJoMICJJYCMJftwCUICJAYGQahUYCIEH6IMbtGQmDIUPiIjbD5IWMMGPKjAAA IfkECQ8ACwAsBQAAAB4AHwAABPtwyTmPpbjmvc4Q1rGFXOYlgjCELPulpVcYKDjc6u2VlDcEhYIv RcQJeBLLLzAkEncwnjJgdD4HEmxM+VIFvh/hQiv1vZYFRWGgECGT5tSStk6431zcXM1+LwwGHT4G Mz8GCkAKfhIGLAZfkJEBCopvjYAFkpKBSJghhJoBgDyAoJ+lQUGjJZiZTHchCbIJpISuX5yCK7YF tBu8kblKAqBfvRm2mxUWILdfvhTFwROzMpHHGKA/RSIJmHaPkDPQEzddOd7F3qkz4xjmTjfrvQEJ 5gOyouRj8E7rdB4EKJhFY8O9eLMWKEDwgRICHvcirjigoNhCBLIgRgwxECPTJIcIQpZhcREBgZMn gfTytq/EQpQor/Wi0TIDpZs4c+KMAAAh+QQJDwALACwCAAAAIQAfAAAE+3DJSeW5Na+jux3CxWWi 1x1DIgiD6Lrgan6FoYZDzuboXKGDQKEAXBl1At/kEgwUjcaeTMkMIKHRgUTrE12bVgFxwaUCY82C ojBQjJSW86ppYyfecGYORF+34T9ABjVBBgpCCoAULgYBjo+QCokdBhoHBoOQmgGVGpgnF5mbn54F oJeYg0M1naWgSxcJsgkmql0ol6u0lKYzTAKiQrsVtiYiIQWawxSNvR6zKMmPBcsSos4ZCZjUl5A1 1cHYE9qi2qs138yaQ3s55tQBCe2ynMvBAVgr5nUoAgqzNohJK5BvzqwFChCAkISAl6MYWPZcUCAq IQJZGVRZ2bNDLuKBf9sCSLKIoCEzNu1STiyJgIBLl0KoaVvmpZ0LhC1fwpxGzQbNF3hGCh1KNAIA IfkECQ8ACwAsAAAAACMAHwAABPtwyUnpuTWvo7sdwsVlomceQyIIg+i64Gp+haGGQ87m6Kyhg0Ch AFwZdQJf5RIMFI3GnkwpYQaQ0OhAsqWKsM2rgLjoUjfAWLOgKAwUo3M1vWra3Im4nJkD2dtvcktA BjVBBgpCCoIWIgYBkJGSCouMBwaFkpoBBoxzlwWbnJ1KL2iXmIVDNaQ+fH0YnwmzCXtgLXMtqgW1 pVhHXwKZkLw+bjFZLRchoZK9Jm5ZULQozcTPHYXSfQmYvJeSNdgZQ8k53cPdqzXiFAXukXXcqgkB CX0p9TbuE8PEygfU3UEhQAGtffwkWBNCZES+WgoQgKCEoAOnBQuHtKqgYDZYRASzNGzSOE6CQW8B KH1EUJHCo0irNk5YSaBmTYazEErY1U5DRJs2w/Gy8SxVyA4qkypdGgEAIfkECQ8ACwAsAgAAACEA HwAABPtwyUnluTWvo7sdwsVlotcdQyIIg+i64Gp+haGGQ87m6Fyhg0ChAFwZdQLf5BIMFI3GnkzJ DCCh0YFE6xNdQTkwh0sFxs7hlpLCRKbTo/XGDA4EDIrCQKE01AyAbX4GQXhCfCZ+Q4sGLgZ2kJEB CogVBZJCNQeAl5iQBhqdnkQXfp6AoZ6QIoCcjKAdophMFhcJtwkml4uyUC0om4u5HUKtiwFYTAKm dgXDljW4igVQIiGyAc8Ud88JhDEruCiyzqEZ30befgmbkdGWsBVhAuqd3ryD2vHyOvfO2WlucVMS MB8REAqkaZsxD9cCBQgQQpQz4c0FBcwgIrhFcSWOiIScJlFCQBIBxY8lCahUmemWjY4QV65058zG QhOUcurcqTMCACH5BAkPAAsALAgAAAAbAB8AAAT7cMl56rz44H2GqBpnbVeXCMIArquHckNhnN9g p3ZHUnZQFB0XCvfaVQaBQHDI1BVFyBuzOZBURUuU66ZaXBcGHyW4HdpypLDvKBWeu+mCkuwZ0N47 iUHO3hvsCYEFCXlgfCBqSYqKCgpxawZ7i5MBBo9JiHKUkTuScweRkT8/nJ0/cwUSIIGBhXuaSalH oKOEcbCxRwKePrYZNwECmBUfuAG+PEJarB24gxtnUwmiCaCLMsheygLTntOjMtgX0UPfg8dvgZXI 5CjfM0AeCqwzGG9CrAsKCPL7efdnKijwtA9BKxL3QMwTFaBRQQQIjKx4SKBiRR+DpmXbsM8OosVr g2ZsnOCwpMmTEQAAIfkECQ8ACwAsBQAAAB4AHwAABPtwyTmPpbjmvc4Q1rGFXOYlgjCELPulpVcY KDjc6u2VlDcEhYIvRcQJeBLLLzAkEncwnjJgdD4HEmxM+VLlPquFVup7mW86ZKWcQrvD6k4ZHAgY FIWBIm4wyG8GMz93QHtxCwYsBnWMjQEKhkiJfQWOjn6SgSGBlnaYHH2cm6FBQX08lJVMIkkWCa8J qIGqdZ9KB7MFsRu5jbYeApx1uhmzl2sHILR1uxTCvhOwMo3EGJw/RSIJlAm41DQZaE4328LbpTMz zVlVOee6AQlur3brYuJO5zRCHwqw4OHwtYG1QAGCfgZ5vHljQYEwgwheKWTYsFwlSBARICBDIhkj gY8fgejaZq+EQZAgqemiUTIDxpcwY0YAACH5BAkPAAsALAIAAAAhAB8AAAT7cMlJ5bk1r6O7HcLF ZaLXHUMiCIPouuBqfoWhhkPO5uhcoYNAoQBcGXUC3+QSDBSNxp5MyQwgodGBROsTXZtWAXHBpQJj zYKiMFCMlJbzqmljJ95wZg5EX7fhP0AGNUEGCkIKgBQuBgGOj5AKiR0GGgcGg5CaAZUamCcXmZuf ngWgl5iDQzWdpaBLFwmyCSaqXSiXq7SUpjNMAqJCuxW2JiIhBZrDFI29HrMoyY8FyxKizhkJmNSX kDXVwdgT2qLaqzXfzJpDeznm1AEJ7bKcy8EBWCvmdSgCCrM2iEkrkG/OrAUKEICQhICXoxhY9lxQ ICohAlkZVFnZs0Mu4oF/2wJIsoigITM27VJOLImAgEuXQqhpW+alnQuELV/CnEbNBs0XeEYKHUo0 AgAh+QQJDwALACwAAAAAIwAfAAAE+3DJSee5NVOs9RkD1y1XcYzZZxjh5b6HYaLpUBTrBe7gJ/y0 yqcQMA1+yF8okVgIgpZBIABKWltQ4c56PZ2yEt1xGvhNlV5w+CMtKn4KIlYdbd9AN6qIzp4WFCBx enQbH36AA4IzhBZ5ZAoKfgWMEmSWl2SThAaYAZxkK1kwCwELK52hUGI7XxIrMjcGamxIPWsmTAmL QbRdOitERXsdBVVcLQcCjkW7I8VcP7kJB8GZ0ygyxyAJK9PVfgZNzgVX26cB07A3uuEUmhLVSjvc BQnobNv27RPvMpbFLujZm3ZEQa59/Pj9M/FlgDQFCApC7OBpwbdYHRT4CwARNAETDZhiiatgEBhH SAg8jnS1EEfGlARi+mFScqU6HCspQIwpkxmRBDVHvvqYEZLRo0iNRgAAIfkECQ8ACwAsAgAAACEA HwAABPtwyUnXuTVTrOsZA9dZR3GM22AY4eW+h2GiaVGsF6iDn+DTk08hYBr4jr5QIrEQAC2DQACE rLaeQV3Vejphc0ZpwCdNdrEkkLSg8CmGV7TkEyUWQLapCE1fK0Bvek8yKzgffoBDMygyNo44eWIK CmsFKENilZmbnJYZmJwBBqGjYisaoKGiK6QGI6mhAxKFj5d2kWVHLSZLCYsaRLR5VTkrmCZeFTYG vY0FSC4CuDbJFKJMEgksRj69CSWbBd+fGdtH2szgmTfYEzcaWuhS387i7BSu8FTa4gHfO0uuPQEo I4G/HgqatQMSr5cCBEYmIZAjYUcLBTKkPESwhCMijITGAkza2FEOho0EUq5ZAnLhk4cpVd7y19Il ipE4c+qMAAAh+QQJDwALACwIAAAAGwAfAAAE+3BJeeq8eNp8xtiZdhRH2BnGV63sYZDh0hUFWnm4 1wl8PAekAW/I+yQSC4FpEAh4iFBVjIKDRkslX0fYDPCaRezEABR5mgUFT1Fwgi7k8hZd8NDc2cwL OAcqPGxuUwt7N2h/A4EwU3skd10KCnSDe12Wl10FIZVxl50BKDGVQCiYoAaMj2WEKDQ1lKpyIwdH CYt6sXwnlSR5F1sCXk0rAqo0vlRCRLUJI5cFzRhVyyjNbZY1SBdP1HHNL662BtoS0zwJLwkBzTlH oOQL5gLo0Os7CrXj0jlDzAoIQiIhmJIjRwkFlf4hOBKj4Ap8rQJEUsjQxAoJCgloRHMEEyK8EP80 bgRyJ4HHjxcmqlzJMgIAIfkECQ8ACwAsBQAAAB4AHwAABPtwySmPpTjfPM8YG1cdxSFWg2GAVuse RnmiRaFaX/55Qj8vnkKgNOgZe6BEYiGYeQKBz3HK+qGk0yMIaMUVoYEeFGky/bzQgqKnEFat13Th U4uGup+04tO2w1VAT0N7A30ycAsGCSRCYAoKcogSYJSVYAVWKgaWAZtggCeajZqcoCIqdVAGE6I1 q6ExjaodJAdKCYcZsbKdtCkxaXcSsZWvgQcCqUO5rLyzC7eLzgWLGMADYWTQKtKVNksYOVoDCSpQ i7vU3+FYSOQxCQGLOkqd4BM6U+XU8jwKt4o45DNC7pYCBEUeIZihoyELBcACHESghGHDFv9QSVRI 8R4ehxcSJhIYmUZJRo8zDo4kuUxIgpMoOTyaSbMmzQgAIfkECQ8ACwAsAgAAACEAHwAABPtwyUnX uTVTrOsZA9dZR3GM22AY4eW+h2GiaVGsF6iDn+DTk08hYBr4jr5QIrEQAC2DQACErLaeQV3Vejph c0ZpwCdNdrEkkLSg8CmGV7TkEyUWQLapCE1fK0BvenJBH36AQzODc3liCgprBUAGGWKVlmKRGiua lwEGlZuamZQLK52hok8rMjaTI6xAFyZLCYmpNDkrQ0R7E7AoLgKMdl4Vn6MatAkllgXLxrvIFQkr y7uYBkwUMpjJpgHLrDa12dvNdzvUzuB0IEue2hLcYlsC6gnsRgq05dvR9QIGKFOAQB/BDvOMbNFx QcE8ggiWZGA1RcuOFvt0BXAEUSSiv4sXMUAkQHLNkozxSLTj4WIBQZIl7QxJgDIljD0cc+rcGQEA IfkECQ8ACwAsAAAAACMAHwAABPtwyUnnuadqebdfxyB23lVkn3YNxoi9l4Gm1VoYeCjuQyj8tNqh EAgUBr/kr5dILARBiy6AvCgPgt4sytkJsN8fuAfiSkdJMDaU2UZXPeWVbD7Hfwlk4kuvg3QCTQlF Cgp5bnU2RYuLJ34UQ0SLCJSNjxOMRQSbCI0BlwsGmZsEnUYGZjALATiSAZWsogWDKXA7W61FNwuz AYNOJSJJIxxDB4InCb2+wUhyWiG5RseSsxtHzs8YAgWu3cdGwBpHckmCCUOZJ8fiFQYF5TsJOOiu uhgf3c8i86K+B++6WRtHwdUSee9+6eDnocCEd4yOYJjXCx0SQ+0KTrD3DUfFgHMKEFwM6YEVr4i7 NiiAGCAkgiYbMhm5kVGCoVyFXMKk4E9XN1QqKZHS1eRmu4A/a9pEQIqATyIJjIrDYWCnypxYs2aN AAAh+QQJDwALACwCAAAAIQAfAAAE+3DJSde5p2p59z5D2HlXkXnVNRgi5l7GiVJqYdxgqA+g4M+0 QyEQKAx8SB8vkVgIgJxc4HhJHgQ8GdSiE1y9vi/Pso2KkN8rKKMFqnhJ67hshvsSx4R3Tn8LmAlE Cgp4bR4GNjcxIENEjkQmQIgFlJQxlI8Imo4FM42PmI8BBKQInAEen6IBBqKkpJAGqauiN5+brAaB qBWqtAMStrELgcUUQ5WqSVkmgAUJz0RNE0WKlQFxKsJF0I3TC5aAkwVWVaFFz97UuhMJLEd3gEKi zUzHGu9I7rrzoBjHsjR02SftwLhnGwIKDPEHUbEcIb6V2eEuWoIehCROZAgoNIECBEcGIaAzYUcW BYgEabJH8gUhYYM+ImDZJ4PMV5CYvNQI5eMrApAweXRHs2fMo0iRRgAAIfkECQ8ACwAsCAAAABsA HwAABPtwSXnqmTivqun4XLcdxdVVgwFabGWY5zEURi1/+CALvFgVgUBhwCvydInEQhD7BIgV40Gg g51wgmmWp9VtRCNQUTuVXWAG4QSlM0q9mrSQrRUkiIksPA5k25NBCgp3VnwBKEBBikElYAsGfQWJ QQiVigWOkIuKBJ0IlwEimgFynJ0EjAZgo6Sslq0JQXyTmI+jNAuxuhiQk2o/B0kJBcOxAUoSvZsl MjWJxJJByBsfAgHWh1HRjNDSHkRGwgkky8FJE1jhNeO+cyES1epy472S0xjpPAmQujcf9/ji6eN3 bMcggOhyFBGnAAERQQjA5MhxQcGohgjOdZhoYSKQswCCMGrUwEICxlOMknhEmKHhKVRCoiVYydJk yJs4cUYAACH5BAkPAAsALAUAAAAeAB8AAAT7cMkpjz00U6vzGSDXLVaBjdVnhFdrGSdKfoVhf2A+ fEIvz4VAoDDoGXu7RGIhkFlAgaLleBDsYs6coLrtcXek3yxk5FY/GOzouTtSweJxu5coJrZwMVug TAgVCnVqIzZjQUKIQiZxEjAFh0IIkogFjBKJQgSaCJQBcTYGmJqaigY/oIc2kJMBNn6eGqqQpo0G hzULfroUsom0QAd9BQnDQkuNj5CtE0+qisSHx7bKyylVj5TD0ciY1X0JB9QmfRO2UQFGYAmu4Zgm IhNa6QProQHg04/HGvJI9La6cIDYx68fHYD3eAQiWBDEEXp9FCAoAgiBDB0YrygwF0AnIgIlFzFe COQMkEeQKFxI8DjqWQKSDFFIHEVAEbaX61DKMMmzp88IACH5BAkPAAsALAIAAAAhAB8AAAT7cMlJ 17mnann3PkPYeVeRedU1GCLmXsaJUmph3GCoD6Dgz7RDIRAoDHxIHy+RWAiAnFzgeEkeBDwZ1KIT XL2+L8+yjYqQ3ysoowWqeEnruGyG+xLHhHdOfwuYCUQKCnhtZTVEiYkmdDQFQ4kIkotQBhqKRASa CIsBKDcbBpiaBJxFlh4GBR4BN5ABk62iBYEVqluuRDYLtAGBTRKqq25CB4AmCb2+E7fEK6q6xpC0 wY/EV4+LyEXAC7MzgAlCmCbG3dBFKAk34q/RI9WUGuuivgfCj90U9do7A+u9xO3Qt89dnDuqfvUg RJDZtINKwilAcGQQglSQjhzUcUE0AbqJCJhoEDali7+O9IYMAimyoL+TGUCS0sWEkAF9GGB2mEiK gK5sCWy2jPKCwsqjSJNGAAAh+QQJDwALACwAAAAAIwAfAAAE+3DJSee5NVOs9RkD1y1XcYzZZxjh 5b6HYaLpUBTrBe7gJ/y0yqcQMA1+yF8okVgIgpZBIABKWltQ4c56PZ2yEt1xGvhNlV5w+CMtKn4K IlYdbd9AN6qIzp4WFCBxenQbH36AA4IzhBZ5ZAoKfgWMEmSWl2SThAaYAZxkK1kwCwELK52hUGI7 XxIrMjcGamxIPWsmTAmLQbRdOitERXsdBVVcLQcCjkW7I8VcP7kJB8GZ0ygyxyAJK9PVfgZNzgVX 26cB07A3uuEUmhLVSjvcBQnobNv27RPvMpbFLujZm3ZEQa59/Pj9M/FlgDQFCApC7OBpwbdYHRT4 CwARNAETDZhiiatgEBhHSAg8jnS1EEfGlARi+mFScqU6HCspQIwpkxmRBDVHvvqYEZLRo0iNRgAA IfkECQ8ACwAsAgAAACEAHwAABPtwyUnXuTVTrOsZA9dZR3GM22AY4eW+h2GiaVGsF6iDn+DTk08h YBr4jr5QIrEQAC2DQACErLaeQV3Vejphc0ZpwCdNdrEkkLSg8CmGV7TkEyUWQLapCE1fK0Bvek8y KzgffoBDMygyNo44eWIKCmsFKENilZmbnJYZmJwBBqGjYisaoKGiK6QGI6mhAxKFj5d2kWVHLSZL CYsaRLR5VTkrmCZeFTYGvY0FSC4CuDbJFKJMEgksRj69CSWbBd+fGdtH2szgmTfYEzcaWuhS387i 7BSu8FTa4gHfO0uuPQEoI4G/HgqatQMSr5cCBEYmIZAjYUcLBTKkPESwhCMijITGAkza2FEOho0E Uq5ZAnLhk4cpVd7y19IlipE4c+qMAAAh+QQJDwALACwIAAAAGwAfAAAE+3BJeeq8eNp8xtiZdhRH 2BnGV63sYZDh0hUFWnm41wl8PAekAW/I+yQSC4FpEAh4iFBVjIKDRkslX0fYDPCaRezEABR5mgUF T1Fwgi7k8hZd8NDc2cwLOAcqPGxuUwt7N2h/A4EwU3skd10KCnSDe12Wl10FIZVxl50BKDGVQCiY oAaMj2WEKDQ1lKpyIwdHCYt6sXwnlSR5F1sCXk0rAqo0vlRCRLUJI5cFzRhVyyjNbZY1SBdP1HHN L662BtoS0zwJLwkBzTlHoOQL5gLo0Os7CrXj0jlDzAoIQiIhmJIjRwkFlf4hOBKj4Ap8rQJEUsjQ xAoJCgloRHMEEyK8EP80bgRyJ4HHjxcmqlzJMgIAIfkECQ8ACwAsBQAAAB4AHwAABPtwySmPpTjf PM8YG1cdxSFWg2GAVuseRnmiRaFaX/55Qj8vnkKgNOgZe6BEYiGYeQKBz3HK+qGk0yMIaMUVoYEe FGky/bzQgqKnEFat13ThU4uGup+04tO2w1VAT0N7A30ycAsGCSRCYAoKcogSYJSVYAVWKgaWAZtg gCeajZqcoCIqdVAGE6I1q6ExjaodJAdKCYcZsbKdtCkxaXcSsZWvgQcCqUO5rLyzC7eLzgWLGMAD YWTQKtKVNksYOVoDCSpQi7vU3+FYSOQxCQGLOkqd4BM6U+XU8jwKt4o45DNC7pYCBEUeIZihoyEL BcACHESghGHDFv9QSVRI8R4ehxcSJhIYmUZJRo8zDo4kuUxIgpMoOTyaSbMmzQgAIfkECQ8ACwAs AgAAACEAHwAABPtwyUnXuTVTrOsZA9dZR3GM22AY4eW+h2GiaVGsF6iDn+DTk08hYBr4jr5QIrEQ AC2DQACErLaeQV3Vejphc0ZpwCdNdrEkkLSg8CmGV7TkEyUWQLapCE1fK0BvenJBH36AQzODc3li CgprBUAGGWKVlmKRGiualwEGlZuamZQLK52hok8rMjaTI6xAFyZLCYmpNDkrQ0R7E7AoLgKMdl4V n6MatAkllgXLxrvIFQkry7uYBkwUMpjJpgHLrDa12dvNdzvUzuB0IEue2hLcYlsC6gnsRgq05dvR 9QIGKFOAQB/BDvOMbNFxQcE8ggiWZGA1RcuOFvt0BXAEUSSiv4sXMUAkQHLNkozxSLTj4WIBQZIl 7QxJgDIljD0cc+rcGQEAIfkECQ8ACwAsAAAAACMAHwAABPtwyUnpuTWvo7sdwsVlomceQyIIg+i6 4Gp+haGGQ87m6Kyhg0ChAFwZdQJf5RIMFI3GnkwpYQaQ0OhAsqWKsM2rgLjoUjfAWLOgKAwUo3M1 vWra3Im4nJkD2dtvcktABjVBBgpCCoIWIgYBkJGSCouMBwaFkpoBBoxzlwWbnJ1KL2iXmIVDNaQ+ fH0YnwmzCXtgLXMtqgW1pVhHXwKZkLw+bjFZLRchoZK9Jm5ZULQozcTPHYXSfQmYvJeSNdgZQ8k5 3cPdqzXiFAXukXXcqgkBCX0p9TbuE8PEygfU3UEhQAGtffwkWBNCZES+WgoQgKCEoAOnBQuHtKqg YDZYRASzNGzSOE6CQW8BKH1EUJHCo0irNk5YSaBmTYazEErY1U5DRJs2w/Gy8SxVyA4qkypdGgEA IfkECQ8ACwAsAgAAACEAHwAABPtwyUnluTWvo7sdwsVlotcdQyIIg+i64Gp+haGGQ87m6Fyhg0Ch AFwZdQLf5BIMFI3GnkzJDCCh0YFE6xNdm1YBccGlAmPNgqIwUIyUlvOqaWMn3nBmDkRft5UGNQaD eoEGQQYKQgozgUOPBi4GAZSVlgqMGQWWlEORg5uclgYaoaJCIoGng6WnlamDjp6kHaaiTHEHCbsJ JpuPtlAtKAeyvR1CsY8BWEwCqp3HFZ68slAiIbYB0hQBNhMJhzErvCi2BdwTBRniRuGBd5OVNek1 GnsC76HhwIbctBnw8UO3bU+KBN7SdTDIrw4KAQqqKfQgcNcCBQhAYEIAhy+CwWEKoGFEYLHjBhcR QQXANBIBx44iWhKYOVMIunATTWCkSdPSEJw5NbAcSrRoBAAh+QQJDwALACwIAAAAGwAfAAAE+3DJ eeq8+OB9hqgaZ21XlwjCAK6rh3JDYZzfYKd2R1J2UBQdFwr32lUGgUBwyNQVRcgbszmQVEVLFDLp AS6uC4OPEnRtC4rCQBHCiH1H6XamTrTdBWXZM0+vdxIGeXGCBkgGCj4KgGGDIG9JkZEKixuCcAaX kpsGJJp6B5+SmTuaj5mCPzKdpT96BRIgCbMJjKmSsEehqrWerrhHAp8FvRk3AQJJIB95ksU8Qlq0 Hc1JxBs20QIJmcShuDMYUkPcmtyqMjLP2UznxAEJ2QOzAeET7OSFCUAeCrT29+SRm7VAAYJ+BgHJ k1dBgSaDCAiSWAjCX7cAlCAiQGBkGoVGAiBB+iDG7RkJgyFD4iI2w+SFjDBjyowAACH5BAkPAAsA LAUAAAAeAB8AAAT7cMk5j6W45r3OENaxhVzmJYIwhCz7paVXGCg43OrtlZQ3BIWCL0XECXgSyy8w JBJ3MJ4yYHQ+BxJsTPlSBb4f4UIr9b2WBUVhoBAhk+bUkrZOuN9c3FzNfi8MBh0+BjM/BgpACn4S BiwGX5CRAQqKb42ABZKSgUiYIYSaAYA8gKCfpUFBoyWYmUx3IQmyCaSErl+cgiu2BbQbvJG5SgKg X70ZtpsVFiC3X74UxcETszKRxxigP0UiCZh2j5Az0BM3XTnexd6pM+MY5k43670BCeYDsqLkY/BO 63QeBCiYRWPDvXizFihA8IESAh73Iq44oKDYQgSyIEYMMRAj0ySHCEKWYXERAYGTJ4H08ravxEKU KK/1otEyA6WbOHPijAAAIfkECQ8ACwAsAgAAACEAHwAABPtwyUnluTWvo7sdwsVlotcdQyIIg+i6 4Gp+haGGQ87m6Fyhg0ChAFwZdQLf5BIMFI3GnkzJDCCh0YFE6xNdm1YBccGlAmPNgqIwUIyUlvOq aWMn3nBmDkRft+E/QAY1QQYKQgqAFC4GAY6PkAqJHQYaBwaDkJoBlRqYJxeZm5+eBaCXmINDNZ2l oEsXCbIJJqpdKJertJSmM0wCokK7FbYmIiEFmsMUjb0esyjJjwXLEqLOGQmY1JeQNdXB2BPaotqr Nd/MmkN7OebUAQntspzLwQFYK+Z1KAIKszaISSuQb86sBQoQgJCEgJejGFj2XFAgKiECWRlUWdmz Qy7igX/bAkiyiKAhMzbtUk4siYCAS5dCqGlb5qWdC4QtX8KcRs0GzRd4RgodSjQCACH+PEZJTEUg SURFTlRJVFkNCkNyZWF0ZWQgb3IgbW9kaWZpZWQgYnkNCkVEIVNPTiAnOTYgW1hmL1VDZl0NCgA7 --=====000_Dragon844788010462_=====-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu May 15 09:08:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07935 for ; Thu, 15 May 2003 09:08:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4FCZlV28931 for megaco-archive@odin.ietf.org; Thu, 15 May 2003 08:35:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FCZlB28928 for ; Thu, 15 May 2003 08:35:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07915 for ; Thu, 15 May 2003 09:08:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GIUs-00079I-00 for megaco-web-archive@ietf.org; Thu, 15 May 2003 09:10:10 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19GIUs-00079F-00 for megaco-web-archive@ietf.org; Thu, 15 May 2003 09:10:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FCXmB28796; Thu, 15 May 2003 08:33:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4F7HaB06497 for ; Thu, 15 May 2003 03:17:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00098 for ; Thu, 15 May 2003 03:50:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GDX4-0004y1-00 for megaco@ietf.org; Thu, 15 May 2003 03:52:06 -0400 Received: from [210.21.224.29] (helo=szsmtp.utstar.com.cn) by ietf-mx with esmtp (Exim 4.12) id 19GDX3-0004xy-00 for megaco@ietf.org; Thu, 15 May 2003 03:52:05 -0400 Received: from sz-nss-leonteng ([172.19.18.33]) by szsmtp.utstar.com.cn (8.11.1/8.11.1) with SMTP id h4F7qjf01694 for ; Thu, 15 May 2003 15:52:45 +0800 Message-Id: <200305150752.h4F7qjf01694@szsmtp.utstar.com.cn> From: "leon.teng" Reply-To: leon.teng@utstar.com To: "megaco@ietf.org" Organization: utstar X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====000_Dragon844788010462_=====" Date: Thu, 15 May 2003 15:52:41 +0800 X-Warning: 210.21.224.29 is a known spammer listed at sbl.spamhaus.org Subject: [Megaco] Question: Is there any package for FSK signal in H248 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --=====000_Dragon844788010462_===== Content-Type: multipart/alternative; boundary="=====002_Dragon844788010462_=====" --=====002_Dragon844788010462_===== Content-Type: text/plain; charset="GB2312" X-MIME-Autoconverted: from 8bit to base64 by szsmtp.utstar.com.cn id h4F7qjf01694 Content-Transfer-Encoding: base64 RGVhciBtZWdhY286DQogICAgSSBjYW4ndCBmaW5kIHN1Y2ggcGFja2FnZS4gQ2FuIGFueW9u ZSBoZWxwIHRlbGwgbWUgaWYgIHNvbWUgb3RoZXIgcGFja2FnZSBhY3QgYXMgdGhlIHNhbWUg ZnVjbnRpb24uDQqhoaGhDQoNClJlZ2FyZHMNCiAgICBsZW9uLnRlbmcNClVUU3RhcmNvbShD aGluYSkgTHRkLCBTaGVuemhlbiBPZmZpY2UgICAgICAgDQpUZWw6ICg4NikgNzU1LTI2OTUy ODk5LTM1MzkNCkZheDogKDg2KSA3NTUtMjY5ODM3ODYgDQpFbWFpbDogbGVvbi50ZW5nQHV0 c3Rhci5jb20NCkRhdGU6ICAyMDAzLTA1LTE1DQogoaGhoaGhoaGhoaGhICAgICAgICAgIA0K ICAgICAgICAgICAgICAgICAgICAgICANCg0KoaGhoaGhoaGhoaGhoaGhoaGhoaEgIKGhICAg DQqhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhDQo= --=====002_Dragon844788010462_===== Content-Type: text/html; charset="GB2312" X-MIME-Autoconverted: from 8bit to quoted-printable by szsmtp.utstar.com.cn id h4F7qjf01694 Content-Transfer-Encoding: quoted-printable
=
<= /TBODY>
Dear megaco:
    I can't find=20 such package. Can anyone help tell me if = ; some=20 other package act as the same fucntion.
=A1=A1=A1=A1
 
Regards<= /DIV>
    leon.teng
UTStarcom(China) Ltd, Shenzhen=20 Office      
Tel: (86= )=20 755-26952899-3539
Fax: (86) 755-26983786
Email: = leon.teng@utstar.c= om
Date:  2003-05-15
 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1          
      = ;            =      

=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1 =20 =A1=A1   
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1


--=====002_Dragon844788010462_=====-- --=====000_Dragon844788010462_===== Content-Type: image/gif; name="fox.gif" Content-Disposition: FoxmailIcon; filename="fox.gif" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhIwAfALMLAP///+Dg4OCgAOCAAOAAAMDA4KCgwKBgQIAAAGBggCAgIAAAAAAAAAAAAAAA AAAAACH/C05FVFNDQVBFMi4wAwHoAwAh+QQJDwALACwAAAAAIwAfAAAE+3DJSem5Na+jux3CxWWi Zx5DIgiD6Lrgan6FoYZDzuborKGDQKEAXBl1Al/lEgwUjcaeTClhBpDQ6ECypYqwzauAuOhSN8BY s6AoDBSjczW9atrcibicmQPZ229yS0AGNUEGCkIKghYiBgGQkZIKi4wHBoWSmgEGjHOXBZucnUov aJeYhUM1pD58fRifCbMJe2Atcy2qBbWlWEdfApmQvD5uMVktFyGhkr0mbllQtCjNxM8dhdJ9CZi8 l5I12BlDyTndw92rNeIUBe6RddyqCQEJfSn1Nu4Tw8TKB9TdQSFAAa19/CRYE0JkRL5aChCAoISg A6cFC4e0qqBgNlhEBLM0bNI4ToJBbwEofURQkcKjSKs2TlhJoGZNhrMQStjVTkNEmzbD8bLxLFXI DiqTKl0aAQAh+QQJDwALACwCAAAAIQAfAAAE+3DJSeW5Na+jux3CxWWi1x1DIgiD6Lrgan6FoYZD zuboXKGDQKEAXBl1At/kEgwUjcaeTMkMIKHRgUTrE12bVgFxwaUCY82CojBQjJSW86ppYyfecGYO RF+3lQY1BoN6gQZBBgpCCjOBQ48GLgYBlJWWCowZBZaUQ5GDm5yWBhqhokIigaeDpaeVqYOOnqQd pqJMcQcJuwkmm4+2UC0oB7K9HUKxjwFYTAKqnccVnryyUCIhtgHSFAE2EwmHMSu8KLYF3BMFGeJG 4YF3k5U16TUaewLvoeHAhty0GfDxQ7dtT4oE3tJ1MMivDgoBCqop9CBw1wIFCEBgQgCHL4LBYQqg YURgseMGFxFBBcA0EgHHjiJaEpg5Uwi6cBNNYKRJ09IQnDk1sBxKtGgEACH5BAkPAAsALAgAAAAb AB8AAAT7cMl56rz44H2GqBpnbVeXCMIArquHckNhnN9gp3ZHUnZQFB0XCvfaVQaBQHDI1BVFyBuz OZBURUsUMukBLq4Lg48SdG0LisJAEcKIfUfpdqZOtN0FZdkzT693EgZ5cYIGSAYKPgqAYYMgb0mR kQqLG4JwBpeSmwYkmnoHn5KZO5qPmYI/Mp2lP3oFEiAJswmMqZKwR6GqtZ6uuEcCnwW9GTcBAkkg H3mSxTxCWrQdzUnEGzbRAgmZxKG4MxhSQ9ya3KoyMs/ZTOfEAQnZA7MB4RPs5IUJQB4KtPb35JGb tUABgn4GAcmTV0GBJoMICJJYCMJftwCUICJAYGQahUYCIEH6IMbtGQmDIUPiIjbD5IWMMGPKjAAA IfkECQ8ACwAsBQAAAB4AHwAABPtwyTmPpbjmvc4Q1rGFXOYlgjCELPulpVcYKDjc6u2VlDcEhYIv RcQJeBLLLzAkEncwnjJgdD4HEmxM+VIFvh/hQiv1vZYFRWGgECGT5tSStk6431zcXM1+LwwGHT4G Mz8GCkAKfhIGLAZfkJEBCopvjYAFkpKBSJghhJoBgDyAoJ+lQUGjJZiZTHchCbIJpISuX5yCK7YF tBu8kblKAqBfvRm2mxUWILdfvhTFwROzMpHHGKA/RSIJmHaPkDPQEzddOd7F3qkz4xjmTjfrvQEJ 5gOyouRj8E7rdB4EKJhFY8O9eLMWKEDwgRICHvcirjigoNhCBLIgRgwxECPTJIcIQpZhcREBgZMn gfTytq/EQpQor/Wi0TIDpZs4c+KMAAAh+QQJDwALACwCAAAAIQAfAAAE+3DJSeW5Na+jux3CxWWi 1x1DIgiD6Lrgan6FoYZDzuboXKGDQKEAXBl1At/kEgwUjcaeTMkMIKHRgUTrE12bVgFxwaUCY82C ojBQjJSW86ppYyfecGYORF+34T9ABjVBBgpCCoAULgYBjo+QCokdBhoHBoOQmgGVGpgnF5mbn54F oJeYg0M1naWgSxcJsgkmql0ol6u0lKYzTAKiQrsVtiYiIQWawxSNvR6zKMmPBcsSos4ZCZjUl5A1 1cHYE9qi2qs138yaQ3s55tQBCe2ynMvBAVgr5nUoAgqzNohJK5BvzqwFChCAkISAl6MYWPZcUCAq IQJZGVRZ2bNDLuKBf9sCSLKIoCEzNu1STiyJgIBLl0KoaVvmpZ0LhC1fwpxGzQbNF3hGCh1KNAIA IfkECQ8ACwAsAAAAACMAHwAABPtwyUnpuTWvo7sdwsVlomceQyIIg+i64Gp+haGGQ87m6Kyhg0Ch AFwZdQJf5RIMFI3GnkwpYQaQ0OhAsqWKsM2rgLjoUjfAWLOgKAwUo3M1vWra3Im4nJkD2dtvcktA BjVBBgpCCoIWIgYBkJGSCouMBwaFkpoBBoxzlwWbnJ1KL2iXmIVDNaQ+fH0YnwmzCXtgLXMtqgW1 pVhHXwKZkLw+bjFZLRchoZK9Jm5ZULQozcTPHYXSfQmYvJeSNdgZQ8k53cPdqzXiFAXukXXcqgkB CX0p9TbuE8PEygfU3UEhQAGtffwkWBNCZES+WgoQgKCEoAOnBQuHtKqgYDZYRASzNGzSOE6CQW8B KH1EUJHCo0irNk5YSaBmTYazEErY1U5DRJs2w/Gy8SxVyA4qkypdGgEAIfkECQ8ACwAsAgAAACEA HwAABPtwyUnluTWvo7sdwsVlotcdQyIIg+i64Gp+haGGQ87m6Fyhg0ChAFwZdQLf5BIMFI3GnkzJ DCCh0YFE6xNdQTkwh0sFxs7hlpLCRKbTo/XGDA4EDIrCQKE01AyAbX4GQXhCfCZ+Q4sGLgZ2kJEB CogVBZJCNQeAl5iQBhqdnkQXfp6AoZ6QIoCcjKAdophMFhcJtwkml4uyUC0om4u5HUKtiwFYTAKm dgXDljW4igVQIiGyAc8Ud88JhDEruCiyzqEZ30befgmbkdGWsBVhAuqd3ryD2vHyOvfO2WlucVMS MB8REAqkaZsxD9cCBQgQQpQz4c0FBcwgIrhFcSWOiIScJlFCQBIBxY8lCahUmemWjY4QV65058zG QhOUcurcqTMCACH5BAkPAAsALAgAAAAbAB8AAAT7cMl56rz44H2GqBpnbVeXCMIArquHckNhnN9g p3ZHUnZQFB0XCvfaVQaBQHDI1BVFyBuzOZBURUuU66ZaXBcGHyW4HdpypLDvKBWeu+mCkuwZ0N47 iUHO3hvsCYEFCXlgfCBqSYqKCgpxawZ7i5MBBo9JiHKUkTuScweRkT8/nJ0/cwUSIIGBhXuaSalH oKOEcbCxRwKePrYZNwECmBUfuAG+PEJarB24gxtnUwmiCaCLMsheygLTntOjMtgX0UPfg8dvgZXI 5CjfM0AeCqwzGG9CrAsKCPL7efdnKijwtA9BKxL3QMwTFaBRQQQIjKx4SKBiRR+DpmXbsM8OosVr g2ZsnOCwpMmTEQAAIfkECQ8ACwAsBQAAAB4AHwAABPtwyTmPpbjmvc4Q1rGFXOYlgjCELPulpVcY KDjc6u2VlDcEhYIvRcQJeBLLLzAkEncwnjJgdD4HEmxM+VLlPquFVup7mW86ZKWcQrvD6k4ZHAgY FIWBIm4wyG8GMz93QHtxCwYsBnWMjQEKhkiJfQWOjn6SgSGBlnaYHH2cm6FBQX08lJVMIkkWCa8J qIGqdZ9KB7MFsRu5jbYeApx1uhmzl2sHILR1uxTCvhOwMo3EGJw/RSIJlAm41DQZaE4328LbpTMz zVlVOee6AQlur3brYuJO5zRCHwqw4OHwtYG1QAGCfgZ5vHljQYEwgwheKWTYsFwlSBARICBDIhkj gY8fgejaZq+EQZAgqemiUTIDxpcwY0YAACH5BAkPAAsALAIAAAAhAB8AAAT7cMlJ5bk1r6O7HcLF ZaLXHUMiCIPouuBqfoWhhkPO5uhcoYNAoQBcGXUC3+QSDBSNxp5MyQwgodGBROsTXZtWAXHBpQJj zYKiMFCMlJbzqmljJ95wZg5EX7fhP0AGNUEGCkIKgBQuBgGOj5AKiR0GGgcGg5CaAZUamCcXmZuf ngWgl5iDQzWdpaBLFwmyCSaqXSiXq7SUpjNMAqJCuxW2JiIhBZrDFI29HrMoyY8FyxKizhkJmNSX kDXVwdgT2qLaqzXfzJpDeznm1AEJ7bKcy8EBWCvmdSgCCrM2iEkrkG/OrAUKEICQhICXoxhY9lxQ ICohAlkZVFnZs0Mu4oF/2wJIsoigITM27VJOLImAgEuXQqhpW+alnQuELV/CnEbNBs0XeEYKHUo0 AgAh+QQJDwALACwAAAAAIwAfAAAE+3DJSee5NVOs9RkD1y1XcYzZZxjh5b6HYaLpUBTrBe7gJ/y0 yqcQMA1+yF8okVgIgpZBIABKWltQ4c56PZ2yEt1xGvhNlV5w+CMtKn4KIlYdbd9AN6qIzp4WFCBx enQbH36AA4IzhBZ5ZAoKfgWMEmSWl2SThAaYAZxkK1kwCwELK52hUGI7XxIrMjcGamxIPWsmTAmL QbRdOitERXsdBVVcLQcCjkW7I8VcP7kJB8GZ0ygyxyAJK9PVfgZNzgVX26cB07A3uuEUmhLVSjvc BQnobNv27RPvMpbFLujZm3ZEQa59/Pj9M/FlgDQFCApC7OBpwbdYHRT4CwARNAETDZhiiatgEBhH SAg8jnS1EEfGlARi+mFScqU6HCspQIwpkxmRBDVHvvqYEZLRo0iNRgAAIfkECQ8ACwAsAgAAACEA HwAABPtwyUnXuTVTrOsZA9dZR3GM22AY4eW+h2GiaVGsF6iDn+DTk08hYBr4jr5QIrEQAC2DQACE rLaeQV3Vejphc0ZpwCdNdrEkkLSg8CmGV7TkEyUWQLapCE1fK0Bvek8yKzgffoBDMygyNo44eWIK CmsFKENilZmbnJYZmJwBBqGjYisaoKGiK6QGI6mhAxKFj5d2kWVHLSZLCYsaRLR5VTkrmCZeFTYG vY0FSC4CuDbJFKJMEgksRj69CSWbBd+fGdtH2szgmTfYEzcaWuhS387i7BSu8FTa4gHfO0uuPQEo I4G/HgqatQMSr5cCBEYmIZAjYUcLBTKkPESwhCMijITGAkza2FEOho0EUq5ZAnLhk4cpVd7y19Il ipE4c+qMAAAh+QQJDwALACwIAAAAGwAfAAAE+3BJeeq8eNp8xtiZdhRH2BnGV63sYZDh0hUFWnm4 1wl8PAekAW/I+yQSC4FpEAh4iFBVjIKDRkslX0fYDPCaRezEABR5mgUFT1Fwgi7k8hZd8NDc2cwL OAcqPGxuUwt7N2h/A4EwU3skd10KCnSDe12Wl10FIZVxl50BKDGVQCiYoAaMj2WEKDQ1lKpyIwdH CYt6sXwnlSR5F1sCXk0rAqo0vlRCRLUJI5cFzRhVyyjNbZY1SBdP1HHNL662BtoS0zwJLwkBzTlH oOQL5gLo0Os7CrXj0jlDzAoIQiIhmJIjRwkFlf4hOBKj4Ap8rQJEUsjQxAoJCgloRHMEEyK8EP80 bgRyJ4HHjxcmqlzJMgIAIfkECQ8ACwAsBQAAAB4AHwAABPtwySmPpTjfPM8YG1cdxSFWg2GAVuse RnmiRaFaX/55Qj8vnkKgNOgZe6BEYiGYeQKBz3HK+qGk0yMIaMUVoYEeFGky/bzQgqKnEFat13Th U4uGup+04tO2w1VAT0N7A30ycAsGCSRCYAoKcogSYJSVYAVWKgaWAZtggCeajZqcoCIqdVAGE6I1 q6ExjaodJAdKCYcZsbKdtCkxaXcSsZWvgQcCqUO5rLyzC7eLzgWLGMADYWTQKtKVNksYOVoDCSpQ i7vU3+FYSOQxCQGLOkqd4BM6U+XU8jwKt4o45DNC7pYCBEUeIZihoyELBcACHESghGHDFv9QSVRI 8R4ehxcSJhIYmUZJRo8zDo4kuUxIgpMoOTyaSbMmzQgAIfkECQ8ACwAsAgAAACEAHwAABPtwyUnX uTVTrOsZA9dZR3GM22AY4eW+h2GiaVGsF6iDn+DTk08hYBr4jr5QIrEQAC2DQACErLaeQV3Vejph c0ZpwCdNdrEkkLSg8CmGV7TkEyUWQLapCE1fK0BvenJBH36AQzODc3liCgprBUAGGWKVlmKRGiua lwEGlZuamZQLK52hok8rMjaTI6xAFyZLCYmpNDkrQ0R7E7AoLgKMdl4Vn6MatAkllgXLxrvIFQkr y7uYBkwUMpjJpgHLrDa12dvNdzvUzuB0IEue2hLcYlsC6gnsRgq05dvR9QIGKFOAQB/BDvOMbNFx QcE8ggiWZGA1RcuOFvt0BXAEUSSiv4sXMUAkQHLNkozxSLTj4WIBQZIl7QxJgDIljD0cc+rcGQEA IfkECQ8ACwAsAAAAACMAHwAABPtwyUnnuadqebdfxyB23lVkn3YNxoi9l4Gm1VoYeCjuQyj8tNqh EAgUBr/kr5dILARBiy6AvCgPgt4sytkJsN8fuAfiSkdJMDaU2UZXPeWVbD7Hfwlk4kuvg3QCTQlF Cgp5bnU2RYuLJ34UQ0SLCJSNjxOMRQSbCI0BlwsGmZsEnUYGZjALATiSAZWsogWDKXA7W61FNwuz AYNOJSJJIxxDB4InCb2+wUhyWiG5RseSsxtHzs8YAgWu3cdGwBpHckmCCUOZJ8fiFQYF5TsJOOiu uhgf3c8i86K+B++6WRtHwdUSee9+6eDnocCEd4yOYJjXCx0SQ+0KTrD3DUfFgHMKEFwM6YEVr4i7 NiiAGCAkgiYbMhm5kVGCoVyFXMKk4E9XN1QqKZHS1eRmu4A/a9pEQIqATyIJjIrDYWCnypxYs2aN AAAh+QQJDwALACwCAAAAIQAfAAAE+3DJSde5p2p59z5D2HlXkXnVNRgi5l7GiVJqYdxgqA+g4M+0 QyEQKAx8SB8vkVgIgJxc4HhJHgQ8GdSiE1y9vi/Pso2KkN8rKKMFqnhJ67hshvsSx4R3Tn8LmAlE Cgp4bR4GNjcxIENEjkQmQIgFlJQxlI8Imo4FM42PmI8BBKQInAEen6IBBqKkpJAGqauiN5+brAaB qBWqtAMStrELgcUUQ5WqSVkmgAUJz0RNE0WKlQFxKsJF0I3TC5aAkwVWVaFFz97UuhMJLEd3gEKi zUzHGu9I7rrzoBjHsjR02SftwLhnGwIKDPEHUbEcIb6V2eEuWoIehCROZAgoNIECBEcGIaAzYUcW BYgEabJH8gUhYYM+ImDZJ4PMV5CYvNQI5eMrApAweXRHs2fMo0iRRgAAIfkECQ8ACwAsCAAAABsA HwAABPtwSXnqmTivqun4XLcdxdVVgwFabGWY5zEURi1/+CALvFgVgUBhwCvydInEQhD7BIgV40Gg g51wgmmWp9VtRCNQUTuVXWAG4QSlM0q9mrSQrRUkiIksPA5k25NBCgp3VnwBKEBBikElYAsGfQWJ QQiVigWOkIuKBJ0IlwEimgFynJ0EjAZgo6Sslq0JQXyTmI+jNAuxuhiQk2o/B0kJBcOxAUoSvZsl MjWJxJJByBsfAgHWh1HRjNDSHkRGwgkky8FJE1jhNeO+cyES1epy472S0xjpPAmQujcf9/ji6eN3 bMcggOhyFBGnAAERQQjA5MhxQcGohgjOdZhoYSKQswCCMGrUwEICxlOMknhEmKHhKVRCoiVYydJk yJs4cUYAACH5BAkPAAsALAUAAAAeAB8AAAT7cMkpjz00U6vzGSDXLVaBjdVnhFdrGSdKfoVhf2A+ fEIvz4VAoDDoGXu7RGIhkFlAgaLleBDsYs6coLrtcXek3yxk5FY/GOzouTtSweJxu5coJrZwMVug TAgVCnVqIzZjQUKIQiZxEjAFh0IIkogFjBKJQgSaCJQBcTYGmJqaigY/oIc2kJMBNn6eGqqQpo0G hzULfroUsom0QAd9BQnDQkuNj5CtE0+qisSHx7bKyylVj5TD0ciY1X0JB9QmfRO2UQFGYAmu4Zgm IhNa6QProQHg04/HGvJI9La6cIDYx68fHYD3eAQiWBDEEXp9FCAoAgiBDB0YrygwF0AnIgIlFzFe COQMkEeQKFxI8DjqWQKSDFFIHEVAEbaX61DKMMmzp88IACH5BAkPAAsALAIAAAAhAB8AAAT7cMlJ 17mnann3PkPYeVeRedU1GCLmXsaJUmph3GCoD6Dgz7RDIRAoDHxIHy+RWAiAnFzgeEkeBDwZ1KIT XL2+L8+yjYqQ3ysoowWqeEnruGyG+xLHhHdOfwuYCUQKCnhtZTVEiYkmdDQFQ4kIkotQBhqKRASa CIsBKDcbBpiaBJxFlh4GBR4BN5ABk62iBYEVqluuRDYLtAGBTRKqq25CB4AmCb2+E7fEK6q6xpC0 wY/EV4+LyEXAC7MzgAlCmCbG3dBFKAk34q/RI9WUGuuivgfCj90U9do7A+u9xO3Qt89dnDuqfvUg RJDZtINKwilAcGQQglSQjhzUcUE0AbqJCJhoEDali7+O9IYMAimyoL+TGUCS0sWEkAF9GGB2mEiK gK5sCWy2jPKCwsqjSJNGAAAh+QQJDwALACwAAAAAIwAfAAAE+3DJSee5NVOs9RkD1y1XcYzZZxjh 5b6HYaLpUBTrBe7gJ/y0yqcQMA1+yF8okVgIgpZBIABKWltQ4c56PZ2yEt1xGvhNlV5w+CMtKn4K IlYdbd9AN6qIzp4WFCBxenQbH36AA4IzhBZ5ZAoKfgWMEmSWl2SThAaYAZxkK1kwCwELK52hUGI7 XxIrMjcGamxIPWsmTAmLQbRdOitERXsdBVVcLQcCjkW7I8VcP7kJB8GZ0ygyxyAJK9PVfgZNzgVX 26cB07A3uuEUmhLVSjvcBQnobNv27RPvMpbFLujZm3ZEQa59/Pj9M/FlgDQFCApC7OBpwbdYHRT4 CwARNAETDZhiiatgEBhHSAg8jnS1EEfGlARi+mFScqU6HCspQIwpkxmRBDVHvvqYEZLRo0iNRgAA IfkECQ8ACwAsAgAAACEAHwAABPtwyUnXuTVTrOsZA9dZR3GM22AY4eW+h2GiaVGsF6iDn+DTk08h YBr4jr5QIrEQAC2DQACErLaeQV3Vejphc0ZpwCdNdrEkkLSg8CmGV7TkEyUWQLapCE1fK0Bvek8y KzgffoBDMygyNo44eWIKCmsFKENilZmbnJYZmJwBBqGjYisaoKGiK6QGI6mhAxKFj5d2kWVHLSZL CYsaRLR5VTkrmCZeFTYGvY0FSC4CuDbJFKJMEgksRj69CSWbBd+fGdtH2szgmTfYEzcaWuhS387i 7BSu8FTa4gHfO0uuPQEoI4G/HgqatQMSr5cCBEYmIZAjYUcLBTKkPESwhCMijITGAkza2FEOho0E Uq5ZAnLhk4cpVd7y19IlipE4c+qMAAAh+QQJDwALACwIAAAAGwAfAAAE+3BJeeq8eNp8xtiZdhRH 2BnGV63sYZDh0hUFWnm41wl8PAekAW/I+yQSC4FpEAh4iFBVjIKDRkslX0fYDPCaRezEABR5mgUF T1Fwgi7k8hZd8NDc2cwLOAcqPGxuUwt7N2h/A4EwU3skd10KCnSDe12Wl10FIZVxl50BKDGVQCiY oAaMj2WEKDQ1lKpyIwdHCYt6sXwnlSR5F1sCXk0rAqo0vlRCRLUJI5cFzRhVyyjNbZY1SBdP1HHN L662BtoS0zwJLwkBzTlHoOQL5gLo0Os7CrXj0jlDzAoIQiIhmJIjRwkFlf4hOBKj4Ap8rQJEUsjQ xAoJCgloRHMEEyK8EP80bgRyJ4HHjxcmqlzJMgIAIfkECQ8ACwAsBQAAAB4AHwAABPtwySmPpTjf PM8YG1cdxSFWg2GAVuseRnmiRaFaX/55Qj8vnkKgNOgZe6BEYiGYeQKBz3HK+qGk0yMIaMUVoYEe FGky/bzQgqKnEFat13ThU4uGup+04tO2w1VAT0N7A30ycAsGCSRCYAoKcogSYJSVYAVWKgaWAZtg gCeajZqcoCIqdVAGE6I1q6ExjaodJAdKCYcZsbKdtCkxaXcSsZWvgQcCqUO5rLyzC7eLzgWLGMAD YWTQKtKVNksYOVoDCSpQi7vU3+FYSOQxCQGLOkqd4BM6U+XU8jwKt4o45DNC7pYCBEUeIZihoyEL BcACHESghGHDFv9QSVRI8R4ehxcSJhIYmUZJRo8zDo4kuUxIgpMoOTyaSbMmzQgAIfkECQ8ACwAs AgAAACEAHwAABPtwyUnXuTVTrOsZA9dZR3GM22AY4eW+h2GiaVGsF6iDn+DTk08hYBr4jr5QIrEQ AC2DQACErLaeQV3Vejphc0ZpwCdNdrEkkLSg8CmGV7TkEyUWQLapCE1fK0BvenJBH36AQzODc3li CgprBUAGGWKVlmKRGiualwEGlZuamZQLK52hok8rMjaTI6xAFyZLCYmpNDkrQ0R7E7AoLgKMdl4V n6MatAkllgXLxrvIFQkry7uYBkwUMpjJpgHLrDa12dvNdzvUzuB0IEue2hLcYlsC6gnsRgq05dvR 9QIGKFOAQB/BDvOMbNFxQcE8ggiWZGA1RcuOFvt0BXAEUSSiv4sXMUAkQHLNkozxSLTj4WIBQZIl 7QxJgDIljD0cc+rcGQEAIfkECQ8ACwAsAAAAACMAHwAABPtwyUnpuTWvo7sdwsVlomceQyIIg+i6 4Gp+haGGQ87m6Kyhg0ChAFwZdQJf5RIMFI3GnkwpYQaQ0OhAsqWKsM2rgLjoUjfAWLOgKAwUo3M1 vWra3Im4nJkD2dtvcktABjVBBgpCCoIWIgYBkJGSCouMBwaFkpoBBoxzlwWbnJ1KL2iXmIVDNaQ+ fH0YnwmzCXtgLXMtqgW1pVhHXwKZkLw+bjFZLRchoZK9Jm5ZULQozcTPHYXSfQmYvJeSNdgZQ8k5 3cPdqzXiFAXukXXcqgkBCX0p9TbuE8PEygfU3UEhQAGtffwkWBNCZES+WgoQgKCEoAOnBQuHtKqg YDZYRASzNGzSOE6CQW8BKH1EUJHCo0irNk5YSaBmTYazEErY1U5DRJs2w/Gy8SxVyA4qkypdGgEA IfkECQ8ACwAsAgAAACEAHwAABPtwyUnluTWvo7sdwsVlotcdQyIIg+i64Gp+haGGQ87m6Fyhg0Ch AFwZdQLf5BIMFI3GnkzJDCCh0YFE6xNdm1YBccGlAmPNgqIwUIyUlvOqaWMn3nBmDkRft5UGNQaD eoEGQQYKQgozgUOPBi4GAZSVlgqMGQWWlEORg5uclgYaoaJCIoGng6WnlamDjp6kHaaiTHEHCbsJ JpuPtlAtKAeyvR1CsY8BWEwCqp3HFZ68slAiIbYB0hQBNhMJhzErvCi2BdwTBRniRuGBd5OVNek1 GnsC76HhwIbctBnw8UO3bU+KBN7SdTDIrw4KAQqqKfQgcNcCBQhAYEIAhy+CwWEKoGFEYLHjBhcR QQXANBIBx44iWhKYOVMIunATTWCkSdPSEJw5NbAcSrRoBAAh+QQJDwALACwIAAAAGwAfAAAE+3DJ eeq8+OB9hqgaZ21XlwjCAK6rh3JDYZzfYKd2R1J2UBQdFwr32lUGgUBwyNQVRcgbszmQVEVLFDLp AS6uC4OPEnRtC4rCQBHCiH1H6XamTrTdBWXZM0+vdxIGeXGCBkgGCj4KgGGDIG9JkZEKixuCcAaX kpsGJJp6B5+SmTuaj5mCPzKdpT96BRIgCbMJjKmSsEehqrWerrhHAp8FvRk3AQJJIB95ksU8Qlq0 Hc1JxBs20QIJmcShuDMYUkPcmtyqMjLP2UznxAEJ2QOzAeET7OSFCUAeCrT29+SRm7VAAYJ+BgHJ k1dBgSaDCAiSWAjCX7cAlCAiQGBkGoVGAiBB+iDG7RkJgyFD4iI2w+SFjDBjyowAACH5BAkPAAsA LAUAAAAeAB8AAAT7cMk5j6W45r3OENaxhVzmJYIwhCz7paVXGCg43OrtlZQ3BIWCL0XECXgSyy8w JBJ3MJ4yYHQ+BxJsTPlSBb4f4UIr9b2WBUVhoBAhk+bUkrZOuN9c3FzNfi8MBh0+BjM/BgpACn4S BiwGX5CRAQqKb42ABZKSgUiYIYSaAYA8gKCfpUFBoyWYmUx3IQmyCaSErl+cgiu2BbQbvJG5SgKg X70ZtpsVFiC3X74UxcETszKRxxigP0UiCZh2j5Az0BM3XTnexd6pM+MY5k43670BCeYDsqLkY/BO 63QeBCiYRWPDvXizFihA8IESAh73Iq44oKDYQgSyIEYMMRAj0ySHCEKWYXERAYGTJ4H08ravxEKU KK/1otEyA6WbOHPijAAAIfkECQ8ACwAsAgAAACEAHwAABPtwyUnluTWvo7sdwsVlotcdQyIIg+i6 4Gp+haGGQ87m6Fyhg0ChAFwZdQLf5BIMFI3GnkzJDCCh0YFE6xNdm1YBccGlAmPNgqIwUIyUlvOq aWMn3nBmDkRft+E/QAY1QQYKQgqAFC4GAY6PkAqJHQYaBwaDkJoBlRqYJxeZm5+eBaCXmINDNZ2l oEsXCbIJJqpdKJertJSmM0wCokK7FbYmIiEFmsMUjb0esyjJjwXLEqLOGQmY1JeQNdXB2BPaotqr Nd/MmkN7OebUAQntspzLwQFYK+Z1KAIKszaISSuQb86sBQoQgJCEgJejGFj2XFAgKiECWRlUWdmz Qy7igX/bAkiyiKAhMzbtUk4siYCAS5dCqGlb5qWdC4QtX8KcRs0GzRd4RgodSjQCACH+PEZJTEUg SURFTlRJVFkNCkNyZWF0ZWQgb3IgbW9kaWZpZWQgYnkNCkVEIVNPTiAnOTYgW1hmL1VDZl0NCgA7 --=====000_Dragon844788010462_=====-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon May 19 04:12:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11564 for ; Mon, 19 May 2003 04:12:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J7e2B26053; Mon, 19 May 2003 03:40:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J7XqB24947 for ; Mon, 19 May 2003 03:33:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11404 for ; Mon, 19 May 2003 04:04:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hff2-0000vG-00 for megaco@ietf.org; Mon, 19 May 2003 04:06:20 -0400 Received: from [210.21.224.29] (helo=szsmtp.utstar.com.cn) by ietf-mx with esmtp (Exim 4.12) id 19Hff1-0000ut-00 for megaco@ietf.org; Mon, 19 May 2003 04:06:19 -0400 Received: from minliu ([172.19.18.20]) by szsmtp.utstar.com.cn (8.11.1/8.11.1) with SMTP id h4J86af13047; Mon, 19 May 2003 16:06:39 +0800 From: "Jackson.liu" To: "Tom Taylor" Cc: Date: Mon, 19 May 2003 16:06:47 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3EC2D06A.70004@tekelec.com> X-Warning: 210.21.224.29 is a known spammer listed at sbl.spamhaus.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h4J7XqB24948 Subject: [Megaco] Package definition Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dear Taylor: Would please tell me the QoS, RSVP, Diffserv packages defined in MEGACO? How can I find it? Thanks. Jackson UTStarcom Ltd. SZ R&D Office. 3/F, Legend Research & Developemnt Building, High-tect Industrial Park Tel: (86-755)26983555-3599 Fax: (86-755)26983786 E-Mail: Jackson.liu@utstar.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon May 19 04:13:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11639 for ; Mon, 19 May 2003 04:13:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4J7gGI26196 for megaco-archive@odin.ietf.org; Mon, 19 May 2003 03:42:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J7gFB26190 for ; Mon, 19 May 2003 03:42:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11609 for ; Mon, 19 May 2003 04:12:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hfn9-0000y8-00 for megaco-web-archive@ietf.org; Mon, 19 May 2003 04:14:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Hfn8-0000y4-00 for megaco-web-archive@ietf.org; Mon, 19 May 2003 04:14:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J7e2B26053; Mon, 19 May 2003 03:40:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J7XqB24947 for ; Mon, 19 May 2003 03:33:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11404 for ; Mon, 19 May 2003 04:04:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hff2-0000vG-00 for megaco@ietf.org; Mon, 19 May 2003 04:06:20 -0400 Received: from [210.21.224.29] (helo=szsmtp.utstar.com.cn) by ietf-mx with esmtp (Exim 4.12) id 19Hff1-0000ut-00 for megaco@ietf.org; Mon, 19 May 2003 04:06:19 -0400 Received: from minliu ([172.19.18.20]) by szsmtp.utstar.com.cn (8.11.1/8.11.1) with SMTP id h4J86af13047; Mon, 19 May 2003 16:06:39 +0800 From: "Jackson.liu" To: "Tom Taylor" Cc: Date: Mon, 19 May 2003 16:06:47 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3EC2D06A.70004@tekelec.com> X-Warning: 210.21.224.29 is a known spammer listed at sbl.spamhaus.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h4J7XqB24948 Subject: [Megaco] Package definition Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Dear Taylor: Would please tell me the QoS, RSVP, Diffserv packages defined in MEGACO? How can I find it? Thanks. Jackson UTStarcom Ltd. SZ R&D Office. 3/F, Legend Research & Developemnt Building, High-tect Industrial Park Tel: (86-755)26983555-3599 Fax: (86-755)26983786 E-Mail: Jackson.liu@utstar.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed May 28 16:13:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21672 for ; Wed, 28 May 2003 16:13:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKC8B06579; Wed, 28 May 2003 16:12:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SK8RB06371 for ; Wed, 28 May 2003 16:08:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21188 for ; Wed, 28 May 2003 16:08:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L7CC-0007AL-00 for megaco@ietf.org; Wed, 28 May 2003 16:06:48 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19L7CB-00079q-00 for megaco@ietf.org; Wed, 28 May 2003 16:06:47 -0400 Received: from zcard307.ca.nortel.com (americasm01.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4SK7kl12698; Wed, 28 May 2003 16:07:46 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLF08GQ; Wed, 28 May 2003 16:07:46 -0400 Received: from nortelnetworks.com (acart1d1.ca.nortel.com [47.129.129.77]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0NRX; Wed, 28 May 2003 16:07:47 -0400 Message-ID: <3ED5170C.7080705@nortelnetworks.com> Date: Wed, 28 May 2003 16:07:40 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Aleksandr Ryabin CC: "Kevin Boyle" , klaha@hss.hns.com, megaco@ietf.org Subject: Re: [Megaco] CAS suspend/resume processing References: <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528154550.02ac6608@imap.winphoria.com> In-Reply-To: <5.2.0.9.0.20030528154550.02ac6608@imap.winphoria.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit OK, that's consistent with the Q.699 diagram. What it says is that in the CAS-to-ISUP direction, suspend is initiated by receipt of a Clearback signal, resume by a new Answer signal. I see nothing that needs to be standardized at the Megaco level for this one. It's not so clear what happens in the opposite direction, and maybe that's the source of your difficulty. Aleksandr Ryabin wrote: > ITU-T Q.764 par 2.4 "Suspend, resume", page 30. > Aleks > > At 03:04 PM 5/28/2003, Tom Taylor wrote: > >> I was looking for a standard describing the interworking you are >> trying to gain support for. So far I've found one relevant figure in >> Q.699 and the logic diagrams in e.g. Q.655. Do you have any more >> precise references? >> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed May 28 16:15:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21722 for ; Wed, 28 May 2003 16:15:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4SKEdY06750 for megaco-archive@odin.ietf.org; Wed, 28 May 2003 16:14:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKEdB06747 for ; Wed, 28 May 2003 16:14:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21711 for ; Wed, 28 May 2003 16:14:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L7IC-0007Jo-00 for megaco-web-archive@ietf.org; Wed, 28 May 2003 16:13:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L7IB-0007Jk-00 for megaco-web-archive@ietf.org; Wed, 28 May 2003 16:12:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKC8B06579; Wed, 28 May 2003 16:12:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SK8RB06371 for ; Wed, 28 May 2003 16:08:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21188 for ; Wed, 28 May 2003 16:08:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L7CC-0007AL-00 for megaco@ietf.org; Wed, 28 May 2003 16:06:48 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19L7CB-00079q-00 for megaco@ietf.org; Wed, 28 May 2003 16:06:47 -0400 Received: from zcard307.ca.nortel.com (americasm01.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4SK7kl12698; Wed, 28 May 2003 16:07:46 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLF08GQ; Wed, 28 May 2003 16:07:46 -0400 Received: from nortelnetworks.com (acart1d1.ca.nortel.com [47.129.129.77]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0NRX; Wed, 28 May 2003 16:07:47 -0400 Message-ID: <3ED5170C.7080705@nortelnetworks.com> Date: Wed, 28 May 2003 16:07:40 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Aleksandr Ryabin CC: "Kevin Boyle" , klaha@hss.hns.com, megaco@ietf.org Subject: Re: [Megaco] CAS suspend/resume processing References: <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528154550.02ac6608@imap.winphoria.com> In-Reply-To: <5.2.0.9.0.20030528154550.02ac6608@imap.winphoria.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit OK, that's consistent with the Q.699 diagram. What it says is that in the CAS-to-ISUP direction, suspend is initiated by receipt of a Clearback signal, resume by a new Answer signal. I see nothing that needs to be standardized at the Megaco level for this one. It's not so clear what happens in the opposite direction, and maybe that's the source of your difficulty. Aleksandr Ryabin wrote: > ITU-T Q.764 par 2.4 "Suspend, resume", page 30. > Aleks > > At 03:04 PM 5/28/2003, Tom Taylor wrote: > >> I was looking for a standard describing the interworking you are >> trying to gain support for. So far I've found one relevant figure in >> Q.699 and the logic diagrams in e.g. Q.655. Do you have any more >> precise references? >> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed May 28 16:25:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22138 for ; Wed, 28 May 2003 16:25:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKMBB08336; Wed, 28 May 2003 16:22:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKJQB07715 for ; Wed, 28 May 2003 16:19:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21859 for ; Wed, 28 May 2003 16:19:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L7Mp-0007MT-00 for megaco@ietf.org; Wed, 28 May 2003 16:17:47 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19L7Mo-0007LX-00 for megaco@ietf.org; Wed, 28 May 2003 16:17:46 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4SKId809693; Wed, 28 May 2003 16:18:39 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLF624T; Wed, 28 May 2003 16:18:39 -0400 Received: from nortelnetworks.com (acart1d1.ca.nortel.com [47.129.129.77]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0NSA; Wed, 28 May 2003 16:18:40 -0400 Message-ID: <3ED51998.1040904@nortelnetworks.com> Date: Wed, 28 May 2003 16:18:32 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Aleksandr Ryabin CC: "Kevin Boyle" , klaha@hss.hns.com, megaco@ietf.org Subject: Re: [Megaco] CAS suspend/resume processing References: <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528154550.02ac6608@imap.winphoria.com> In-Reply-To: <5.2.0.9.0.20030528154550.02ac6608@imap.winphoria.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Found the complete answer in Q.695. Suspend <-> Clearback and Resume <-> (re)Answer. This doesn't seem to require anything new in the package documentation so long as Clearback and Answer signals and events have been defined. Aleksandr Ryabin wrote: > ITU-T Q.764 par 2.4 "Suspend, resume", page 30. > Aleks > > At 03:04 PM 5/28/2003, Tom Taylor wrote: > >> I was looking for a standard describing the interworking you are >> trying to gain support for. So far I've found one relevant figure in >> Q.699 and the logic diagrams in e.g. Q.655. Do you have any more >> precise references? >> >> Aleksandr Ryabin wrote: >> >>> Please see comments inline [AR]. >>> Aleks >>> At 12:50 PM 5/28/2003, Kevin Boyle wrote: >>> >>>> Comments inline. [KJBII] >>>> >>>> Kevin >>>> >>>> -----Original Message----- >>>> From: Aleksandr Ryabin [mailto:kengr@winphoria.com] >>>> Sent: Wednesday, May 28, 2003 12:25 PM >>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; klaha@hss.hns.com; >>>> megaco@ietf.org >>>> Subject: RE: [Megaco] CAS suspend/resume processing >>>> >>>> At 11:28 AM 5/28/2003, Kevin Boyle wrote: >>>> >>>>> A few comments: >>>>> >>>>> 1. H.248 is not MGCP. We do not have any reason to make >>>>> H.248 behave or look like MGCP. So, the "MGCP does X" >>>>> argument is irrelevant. >>>> >>>> >>>> >>>> The intention of the quote was to describe call suspend/resume >>>> processing and has nothing to do with "MGCP does X" >>>> In my very first email in the thread I explicitly stated that, but >>>> apparently the need to quote was still necessary >>>> as after all these emails it seem that there was still confusion >>>> on what I'm taking about. >>>> >>>>> 2. The bcas packages are meant to address the functionality >>>>> of CAS. Remember that a CAS trunk has two wires with which >>>>> to do line signaling. This means there are four states -- >>>>> addressed in bcas by Seize, Seize Ack, Answer and Idle. It >>>>> seems to me that any line signaling can therefore be done >>>>> using the package. This "resume" line signal MUST align to >>>>> one of the four line signals by definition. >>>> >>>> >>>> >>>> CAS trunks *can* have upto 4 supervisory bits and in no way 4 >>>> events can cover all 16 bit sets, >>>> for example, Inidia registered CAS signalling uses 3 forward bits >>>> and 2 backward. >>>> Also "events" do not strictly correspond to a specific bit set, >>>> something else can be a mean contribution to event, >>>> for example, time constraints (e.g. rbs/pson, rbs/psoff, or >>>> metering pulse, which by the way is not defined >>>> as event/signal, but should be). >>>> [KJBII] *Basic* CAS has only 2 bits. R2 has 4 -- in which case >>>> you need the icas packages. Are we addressing a *basic* CAS >>>> function, or an R2 function? If it is something needed in R2, we >>>> can talk about including it in icas. >>> >>> >>> [AR] We are addressing *basic* CAS to ISUP suspend/resume mapping >>> function. >>> >>>>> I would prefer we address the requirements set forth by CAS >>>>> signaling directly, and avoid depending upon the implementation >>>>> of a particular requirement under a different protocol. >>>> >>>> >>>> >>>> That was exactly the intention for starting this email thread. >>>> I understand that suspend/resume is not defined in CAS protocol >>>> itself, >>>> but I'd think that pretty much any softswitch which does CAS also >>>> would have >>>> to bridge ISUP (where resume/suspend is defined) with CAS and that >>>> is why, >>>> I think, the authors of MGCP CAS package decided it is quite >>>> appropriate >>>> to define such procedures in scope of package. Yes, I know, "MGCP >>>> does X" >>>> argument is irrelevant, but they (the authors of MGCP CAS package) >>>> did put >>>> some thought in it and we should not need to reinvent a bike. >>>> [KJBII] Except their solution is tailored specifically to MGCP, >>>> and so does not apply here. I would say that an MGC that has to >>>> handle bridging ISUP to CAS should know how to do that function >>>> within the context of the defined protocol. This may not require >>>> a package-based solution -- e.g., don't tear down the CAS side of >>>> the call in the first place, so you are reattached the instant the >>>> ISUP resumes. >>> >>> >>> [AR] We are taking about resume from CAS side, after it suspended >>> (placed on-hook) call. >>> MG still needs support of the protocol to communicate resume/seize >>> from CAS side to MGC, >>> and MG must be aware such state possibility, (e.g. sending seize when >>> trunk is not idle both ways), >>> otherwise MG will send bcas/casf {ec=SME }. This clearly calls at >>> least for "procedure" definition. >>> This procedure can ether be addressed as a separate draft, or folded >>> into base draft. >>> I see no harm in folding this procedure into base draft. >>> >>>> I have a problem on hand and I brought it to the list to insure >>>> compatibility. >>>> Is it just me, or are there other folks who also think this is >>>> relevant? >>>> otherwise I'll just shut up and deal with it as a "specific >>>> implementation" need :) >>>> >>>> Aleks >>>> >>>>> >>>>> Kevin >>>>> >>>>> [KJBII] snip! >> >> > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed May 28 16:27:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22193 for ; Wed, 28 May 2003 16:27:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4SKQpx08624 for megaco-archive@odin.ietf.org; Wed, 28 May 2003 16:26:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKQpB08621 for ; Wed, 28 May 2003 16:26:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22178 for ; Wed, 28 May 2003 16:26:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L7U0-0007SK-00 for megaco-web-archive@ietf.org; Wed, 28 May 2003 16:25:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L7Tz-0007SH-00 for megaco-web-archive@ietf.org; Wed, 28 May 2003 16:25:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKMBB08336; Wed, 28 May 2003 16:22:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKJQB07715 for ; Wed, 28 May 2003 16:19:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21859 for ; Wed, 28 May 2003 16:19:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L7Mp-0007MT-00 for megaco@ietf.org; Wed, 28 May 2003 16:17:47 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19L7Mo-0007LX-00 for megaco@ietf.org; Wed, 28 May 2003 16:17:46 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4SKId809693; Wed, 28 May 2003 16:18:39 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLF624T; Wed, 28 May 2003 16:18:39 -0400 Received: from nortelnetworks.com (acart1d1.ca.nortel.com [47.129.129.77]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0NSA; Wed, 28 May 2003 16:18:40 -0400 Message-ID: <3ED51998.1040904@nortelnetworks.com> Date: Wed, 28 May 2003 16:18:32 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Aleksandr Ryabin CC: "Kevin Boyle" , klaha@hss.hns.com, megaco@ietf.org Subject: Re: [Megaco] CAS suspend/resume processing References: <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528154550.02ac6608@imap.winphoria.com> In-Reply-To: <5.2.0.9.0.20030528154550.02ac6608@imap.winphoria.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Found the complete answer in Q.695. Suspend <-> Clearback and Resume <-> (re)Answer. This doesn't seem to require anything new in the package documentation so long as Clearback and Answer signals and events have been defined. Aleksandr Ryabin wrote: > ITU-T Q.764 par 2.4 "Suspend, resume", page 30. > Aleks > > At 03:04 PM 5/28/2003, Tom Taylor wrote: > >> I was looking for a standard describing the interworking you are >> trying to gain support for. So far I've found one relevant figure in >> Q.699 and the logic diagrams in e.g. Q.655. Do you have any more >> precise references? >> >> Aleksandr Ryabin wrote: >> >>> Please see comments inline [AR]. >>> Aleks >>> At 12:50 PM 5/28/2003, Kevin Boyle wrote: >>> >>>> Comments inline. [KJBII] >>>> >>>> Kevin >>>> >>>> -----Original Message----- >>>> From: Aleksandr Ryabin [mailto:kengr@winphoria.com] >>>> Sent: Wednesday, May 28, 2003 12:25 PM >>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; klaha@hss.hns.com; >>>> megaco@ietf.org >>>> Subject: RE: [Megaco] CAS suspend/resume processing >>>> >>>> At 11:28 AM 5/28/2003, Kevin Boyle wrote: >>>> >>>>> A few comments: >>>>> >>>>> 1. H.248 is not MGCP. We do not have any reason to make >>>>> H.248 behave or look like MGCP. So, the "MGCP does X" >>>>> argument is irrelevant. >>>> >>>> >>>> >>>> The intention of the quote was to describe call suspend/resume >>>> processing and has nothing to do with "MGCP does X" >>>> In my very first email in the thread I explicitly stated that, but >>>> apparently the need to quote was still necessary >>>> as after all these emails it seem that there was still confusion >>>> on what I'm taking about. >>>> >>>>> 2. The bcas packages are meant to address the functionality >>>>> of CAS. Remember that a CAS trunk has two wires with which >>>>> to do line signaling. This means there are four states -- >>>>> addressed in bcas by Seize, Seize Ack, Answer and Idle. It >>>>> seems to me that any line signaling can therefore be done >>>>> using the package. This "resume" line signal MUST align to >>>>> one of the four line signals by definition. >>>> >>>> >>>> >>>> CAS trunks *can* have upto 4 supervisory bits and in no way 4 >>>> events can cover all 16 bit sets, >>>> for example, Inidia registered CAS signalling uses 3 forward bits >>>> and 2 backward. >>>> Also "events" do not strictly correspond to a specific bit set, >>>> something else can be a mean contribution to event, >>>> for example, time constraints (e.g. rbs/pson, rbs/psoff, or >>>> metering pulse, which by the way is not defined >>>> as event/signal, but should be). >>>> [KJBII] *Basic* CAS has only 2 bits. R2 has 4 -- in which case >>>> you need the icas packages. Are we addressing a *basic* CAS >>>> function, or an R2 function? If it is something needed in R2, we >>>> can talk about including it in icas. >>> >>> >>> [AR] We are addressing *basic* CAS to ISUP suspend/resume mapping >>> function. >>> >>>>> I would prefer we address the requirements set forth by CAS >>>>> signaling directly, and avoid depending upon the implementation >>>>> of a particular requirement under a different protocol. >>>> >>>> >>>> >>>> That was exactly the intention for starting this email thread. >>>> I understand that suspend/resume is not defined in CAS protocol >>>> itself, >>>> but I'd think that pretty much any softswitch which does CAS also >>>> would have >>>> to bridge ISUP (where resume/suspend is defined) with CAS and that >>>> is why, >>>> I think, the authors of MGCP CAS package decided it is quite >>>> appropriate >>>> to define such procedures in scope of package. Yes, I know, "MGCP >>>> does X" >>>> argument is irrelevant, but they (the authors of MGCP CAS package) >>>> did put >>>> some thought in it and we should not need to reinvent a bike. >>>> [KJBII] Except their solution is tailored specifically to MGCP, >>>> and so does not apply here. I would say that an MGC that has to >>>> handle bridging ISUP to CAS should know how to do that function >>>> within the context of the defined protocol. This may not require >>>> a package-based solution -- e.g., don't tear down the CAS side of >>>> the call in the first place, so you are reattached the instant the >>>> ISUP resumes. >>> >>> >>> [AR] We are taking about resume from CAS side, after it suspended >>> (placed on-hook) call. >>> MG still needs support of the protocol to communicate resume/seize >>> from CAS side to MGC, >>> and MG must be aware such state possibility, (e.g. sending seize when >>> trunk is not idle both ways), >>> otherwise MG will send bcas/casf {ec=SME }. This clearly calls at >>> least for "procedure" definition. >>> This procedure can ether be addressed as a separate draft, or folded >>> into base draft. >>> I see no harm in folding this procedure into base draft. >>> >>>> I have a problem on hand and I brought it to the list to insure >>>> compatibility. >>>> Is it just me, or are there other folks who also think this is >>>> relevant? >>>> otherwise I'll just shut up and deal with it as a "specific >>>> implementation" need :) >>>> >>>> Aleks >>>> >>>>> >>>>> Kevin >>>>> >>>>> [KJBII] snip! >> >> > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed May 28 16:30:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22344 for ; Wed, 28 May 2003 16:30:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKTEB08756; Wed, 28 May 2003 16:29:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKStB08726 for ; Wed, 28 May 2003 16:28:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22285 for ; Wed, 28 May 2003 16:28:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L7W0-0007TF-00 for megaco@ietf.org; Wed, 28 May 2003 16:27:16 -0400 Received: from frogman.motivity.ca ([64.235.96.70]) by ietf-mx with esmtp (Exim 4.12) id 19L7Vz-0007TC-00 for megaco@ietf.org; Wed, 28 May 2003 16:27:15 -0400 Received: from frogman.motivity.ca (localhost.motivity.ca [127.0.0.1]) by frogman.motivity.ca (8.12.9/8.12.3) with ESMTP id h4SKSeCv088448; Wed, 28 May 2003 16:28:40 -0400 (EDT) (envelope-from vances@frogman.motivity.ca) Received: (from vances@localhost) by frogman.motivity.ca (8.12.9/8.12.3/Submit) id h4SKSe1X088447; Wed, 28 May 2003 16:28:40 -0400 (EDT) (envelope-from vances) Date: Wed, 28 May 2003 16:28:39 -0400 From: Vance Shipley To: Tom Taylor Cc: Aleksandr Ryabin , Kevin Boyle , klaha@hss.hns.com, megaco@ietf.org Subject: Re: [Megaco] CAS suspend/resume processing Message-ID: <20030528202839.GJ87245@frogman.motivity.ca> References: <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528154550.02ac6608@imap.winphoria.com> <3ED5170C.7080705@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ED5170C.7080705@nortelnetworks.com> Organization: Motivity Telecom Inc. User-Agent: Mutt/1.5.1i Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , As there is no CAS "suspend" or "resume" the issue becomes whether or not the MG must understand a call state of "suspended" to make it possible to provide the intended functionality. Since the timing required in processing the suspend/resume is in the order of tens of seconds I'd say not. -Vance On Wed, May 28, 2003 at 04:07:40PM -0400, Tom Taylor wrote: } OK, that's consistent with the Q.699 diagram. What it says is that in the } CAS-to-ISUP direction, suspend is initiated by receipt of a Clearback } signal, resume by a new Answer signal. I see nothing that needs to be } standardized at the Megaco level for this one. It's not so clear what } happens in the opposite direction, and maybe that's the source of your } difficulty. } } Aleksandr Ryabin wrote: } >ITU-T Q.764 par 2.4 "Suspend, resume", page 30. } > Aleks } > } >At 03:04 PM 5/28/2003, Tom Taylor wrote: } > } >>I was looking for a standard describing the interworking you are } >>trying to gain support for. So far I've found one relevant figure in } >>Q.699 and the logic diagrams in e.g. Q.655. Do you have any more } >>precise references? } >> } } _______________________________________________ } Megaco mailing list } Megaco@ietf.org } https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed May 28 16:31:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22404 for ; Wed, 28 May 2003 16:31:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4SKVFl08926 for megaco-archive@odin.ietf.org; Wed, 28 May 2003 16:31:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKVFB08923 for ; Wed, 28 May 2003 16:31:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22378 for ; Wed, 28 May 2003 16:31:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L7YF-0007UP-00 for megaco-web-archive@ietf.org; Wed, 28 May 2003 16:29:35 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L7YF-0007UM-00 for megaco-web-archive@ietf.org; Wed, 28 May 2003 16:29:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKTEB08756; Wed, 28 May 2003 16:29:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKStB08726 for ; Wed, 28 May 2003 16:28:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22285 for ; Wed, 28 May 2003 16:28:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L7W0-0007TF-00 for megaco@ietf.org; Wed, 28 May 2003 16:27:16 -0400 Received: from frogman.motivity.ca ([64.235.96.70]) by ietf-mx with esmtp (Exim 4.12) id 19L7Vz-0007TC-00 for megaco@ietf.org; Wed, 28 May 2003 16:27:15 -0400 Received: from frogman.motivity.ca (localhost.motivity.ca [127.0.0.1]) by frogman.motivity.ca (8.12.9/8.12.3) with ESMTP id h4SKSeCv088448; Wed, 28 May 2003 16:28:40 -0400 (EDT) (envelope-from vances@frogman.motivity.ca) Received: (from vances@localhost) by frogman.motivity.ca (8.12.9/8.12.3/Submit) id h4SKSe1X088447; Wed, 28 May 2003 16:28:40 -0400 (EDT) (envelope-from vances) Date: Wed, 28 May 2003 16:28:39 -0400 From: Vance Shipley To: Tom Taylor Cc: Aleksandr Ryabin , Kevin Boyle , klaha@hss.hns.com, megaco@ietf.org Subject: Re: [Megaco] CAS suspend/resume processing Message-ID: <20030528202839.GJ87245@frogman.motivity.ca> References: <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528154550.02ac6608@imap.winphoria.com> <3ED5170C.7080705@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ED5170C.7080705@nortelnetworks.com> Organization: Motivity Telecom Inc. User-Agent: Mutt/1.5.1i Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , As there is no CAS "suspend" or "resume" the issue becomes whether or not the MG must understand a call state of "suspended" to make it possible to provide the intended functionality. Since the timing required in processing the suspend/resume is in the order of tens of seconds I'd say not. -Vance On Wed, May 28, 2003 at 04:07:40PM -0400, Tom Taylor wrote: } OK, that's consistent with the Q.699 diagram. What it says is that in the } CAS-to-ISUP direction, suspend is initiated by receipt of a Clearback } signal, resume by a new Answer signal. I see nothing that needs to be } standardized at the Megaco level for this one. It's not so clear what } happens in the opposite direction, and maybe that's the source of your } difficulty. } } Aleksandr Ryabin wrote: } >ITU-T Q.764 par 2.4 "Suspend, resume", page 30. } > Aleks } > } >At 03:04 PM 5/28/2003, Tom Taylor wrote: } > } >>I was looking for a standard describing the interworking you are } >>trying to gain support for. So far I've found one relevant figure in } >>Q.699 and the logic diagrams in e.g. Q.655. Do you have any more } >>precise references? } >> } } _______________________________________________ } Megaco mailing list } Megaco@ietf.org } https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed May 28 16:51:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22874 for ; Wed, 28 May 2003 16:51:38 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKoEB10553; Wed, 28 May 2003 16:50:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKneB10507 for ; Wed, 28 May 2003 16:49:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22852 for ; Wed, 28 May 2003 16:49:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L7q5-0007dI-00 for megaco@ietf.org; Wed, 28 May 2003 16:48:01 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19L7q4-0007dF-00 for megaco@ietf.org; Wed, 28 May 2003 16:48:00 -0400 Received: from zcard307.ca.nortel.com (americasm01.nt.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4SKmki13793; Wed, 28 May 2003 16:48:46 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLGADJF; Wed, 28 May 2003 16:48:46 -0400 Received: from nortelnetworks.com (acart1d1.ca.nortel.com [47.129.129.77]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0NS9; Wed, 28 May 2003 16:48:46 -0400 Message-ID: <3ED520AA.5050303@nortelnetworks.com> Date: Wed, 28 May 2003 16:48:42 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Vance Shipley CC: Aleksandr Ryabin , "Kevin Boyle" , klaha@hss.hns.com, megaco@ietf.org Subject: Re: [Megaco] CAS suspend/resume processing References: <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528154550.02ac6608@imap.winphoria.com> <3ED5170C.7080705@nortelnetworks.com> <20030528202839.GJ87245@frogman.motivity.ca> In-Reply-To: <20030528202839.GJ87245@frogman.motivity.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit That seems right: the MGC should be responsible for managing ISUP Timer T6. And BTW, the reference I found was Q.696, not Q.695. Just to summarize in terms of Aleksandr's original point: if you're talking an analogue line working into ISUP, you're talking on-hook/off-hook events as in Annex E. If you're talking CAS signalling, you use the CAS packages to detect or signal Clearback and Answer. In either case the MGC is responsible for the interworking and the applicable standard is Q.696 rather than the CAS package documentation. Vance Shipley wrote: > As there is no CAS "suspend" or "resume" the issue becomes whether > or not the MG must understand a call state of "suspended" to make > it possible to provide the intended functionality. Since the > timing required in processing the suspend/resume is in the order > of tens of seconds I'd say not. > > -Vance > > On Wed, May 28, 2003 at 04:07:40PM -0400, Tom Taylor wrote: > } OK, that's consistent with the Q.699 diagram. What it says is that in the > } CAS-to-ISUP direction, suspend is initiated by receipt of a Clearback > } signal, resume by a new Answer signal. I see nothing that needs to be > } standardized at the Megaco level for this one. It's not so clear what > } happens in the opposite direction, and maybe that's the source of your > } difficulty. > } > } Aleksandr Ryabin wrote: > } >ITU-T Q.764 par 2.4 "Suspend, resume", page 30. > } > Aleks > } > > } >At 03:04 PM 5/28/2003, Tom Taylor wrote: > } > > } >>I was looking for a standard describing the interworking you are > } >>trying to gain support for. So far I've found one relevant figure in > } >>Q.699 and the logic diagrams in e.g. Q.655. Do you have any more > } >>precise references? > } >> > } > } _______________________________________________ > } Megaco mailing list > } Megaco@ietf.org > } https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed May 28 16:52:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22938 for ; Wed, 28 May 2003 16:52:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4SKqMr10661 for megaco-archive@odin.ietf.org; Wed, 28 May 2003 16:52:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKqMB10658 for ; Wed, 28 May 2003 16:52:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22908 for ; Wed, 28 May 2003 16:52:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L7sg-0007eM-00 for megaco-web-archive@ietf.org; Wed, 28 May 2003 16:50:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L7sf-0007eJ-00 for megaco-web-archive@ietf.org; Wed, 28 May 2003 16:50:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKoEB10553; Wed, 28 May 2003 16:50:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKneB10507 for ; Wed, 28 May 2003 16:49:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22852 for ; Wed, 28 May 2003 16:49:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L7q5-0007dI-00 for megaco@ietf.org; Wed, 28 May 2003 16:48:01 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19L7q4-0007dF-00 for megaco@ietf.org; Wed, 28 May 2003 16:48:00 -0400 Received: from zcard307.ca.nortel.com (americasm01.nt.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4SKmki13793; Wed, 28 May 2003 16:48:46 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLGADJF; Wed, 28 May 2003 16:48:46 -0400 Received: from nortelnetworks.com (acart1d1.ca.nortel.com [47.129.129.77]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0NS9; Wed, 28 May 2003 16:48:46 -0400 Message-ID: <3ED520AA.5050303@nortelnetworks.com> Date: Wed, 28 May 2003 16:48:42 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Vance Shipley CC: Aleksandr Ryabin , "Kevin Boyle" , klaha@hss.hns.com, megaco@ietf.org Subject: Re: [Megaco] CAS suspend/resume processing References: <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528154550.02ac6608@imap.winphoria.com> <3ED5170C.7080705@nortelnetworks.com> <20030528202839.GJ87245@frogman.motivity.ca> In-Reply-To: <20030528202839.GJ87245@frogman.motivity.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit That seems right: the MGC should be responsible for managing ISUP Timer T6. And BTW, the reference I found was Q.696, not Q.695. Just to summarize in terms of Aleksandr's original point: if you're talking an analogue line working into ISUP, you're talking on-hook/off-hook events as in Annex E. If you're talking CAS signalling, you use the CAS packages to detect or signal Clearback and Answer. In either case the MGC is responsible for the interworking and the applicable standard is Q.696 rather than the CAS package documentation. Vance Shipley wrote: > As there is no CAS "suspend" or "resume" the issue becomes whether > or not the MG must understand a call state of "suspended" to make > it possible to provide the intended functionality. Since the > timing required in processing the suspend/resume is in the order > of tens of seconds I'd say not. > > -Vance > > On Wed, May 28, 2003 at 04:07:40PM -0400, Tom Taylor wrote: > } OK, that's consistent with the Q.699 diagram. What it says is that in the > } CAS-to-ISUP direction, suspend is initiated by receipt of a Clearback > } signal, resume by a new Answer signal. I see nothing that needs to be > } standardized at the Megaco level for this one. It's not so clear what > } happens in the opposite direction, and maybe that's the source of your > } difficulty. > } > } Aleksandr Ryabin wrote: > } >ITU-T Q.764 par 2.4 "Suspend, resume", page 30. > } > Aleks > } > > } >At 03:04 PM 5/28/2003, Tom Taylor wrote: > } > > } >>I was looking for a standard describing the interworking you are > } >>trying to gain support for. So far I've found one relevant figure in > } >>Q.699 and the logic diagrams in e.g. Q.655. Do you have any more > } >>precise references? > } >> > } > } _______________________________________________ > } Megaco mailing list > } Megaco@ietf.org > } https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed May 28 17:01:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23796 for ; Wed, 28 May 2003 17:01:43 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SL0NB11489; Wed, 28 May 2003 17:00:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKxIB11103 for ; Wed, 28 May 2003 16:59:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23549 for ; Wed, 28 May 2003 16:59:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L7zO-00001X-00 for megaco@ietf.org; Wed, 28 May 2003 16:57:38 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19L7zO-00000Y-00 for megaco@ietf.org; Wed, 28 May 2003 16:57:38 -0400 Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 28 May 2003 16:58:42 -0400 Message-Id: <5.2.0.9.0.20030528164749.0297e3f8@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 28 May 2003 16:56:07 -0400 To: Tom Taylor , megaco@ietf.org From: Aleksandr Ryabin Subject: Re: [Megaco] CAS suspend/resume processing In-Reply-To: <3ED520AA.5050303@nortelnetworks.com> References: <20030528202839.GJ87245@frogman.motivity.ca> <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528154550.02ac6608@imap.winphoria.com> <3ED5170C.7080705@nortelnetworks.com> <20030528202839.GJ87245@frogman.motivity.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 28 May 2003 20:58:43.0193 (UTC) FILETIME=[EC393690:01C3255B] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Yes, now it makes sense. Although a call flow example would be nice, that is to be added to the package spec which show that it will be Answer event. As a side note, all call flow examples in the draft stop after call is answered, IMO it would be cleaner is they continue with termination. Thanks. Aleks At 04:48 PM 5/28/2003, Tom Taylor wrote: >That seems right: the MGC should be responsible for managing ISUP Timer >T6. And BTW, the reference I found was Q.696, not Q.695. > >Just to summarize in terms of Aleksandr's original point: if you're >talking an analogue line working into ISUP, you're talking >on-hook/off-hook events as in Annex E. If you're talking CAS signalling, >you use the CAS packages to detect or signal Clearback and Answer. In >either case the MGC is responsible for the interworking and the applicable >standard is Q.696 rather than the CAS package documentation. > >Vance Shipley wrote: >>As there is no CAS "suspend" or "resume" the issue becomes whether >>or not the MG must understand a call state of "suspended" to make >>it possible to provide the intended functionality. Since the >>timing required in processing the suspend/resume is in the order of tens >>of seconds I'd say not. >> -Vance >>On Wed, May 28, 2003 at 04:07:40PM -0400, Tom Taylor wrote: >>} OK, that's consistent with the Q.699 diagram. What it says is that in >>the } CAS-to-ISUP direction, suspend is initiated by receipt of a >>Clearback } signal, resume by a new Answer signal. I see nothing that >>needs to be } standardized at the Megaco level for this one. It's not >>so clear what } happens in the opposite direction, and maybe that's the >>source of your } difficulty. >>} >>} Aleksandr Ryabin wrote: >>} >ITU-T Q.764 par 2.4 "Suspend, resume", page 30. >>} > Aleks >>} > >>} >At 03:04 PM 5/28/2003, Tom Taylor wrote: >>} > >>} >>I was looking for a standard describing the interworking you are >>} >>trying to gain support for. So far I've found one relevant figure >>in } >>Q.699 and the logic diagrams in e.g. Q.655. Do you have any more >>} >>precise references? >>} >> >>} >>} _______________________________________________ >>} Megaco mailing list >>} Megaco@ietf.org >>} https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed May 28 17:02:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23845 for ; Wed, 28 May 2003 17:02:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4SL2RD12053 for megaco-archive@odin.ietf.org; Wed, 28 May 2003 17:02:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SL2RB12050 for ; Wed, 28 May 2003 17:02:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23828 for ; Wed, 28 May 2003 17:02:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L82S-00006G-00 for megaco-web-archive@ietf.org; Wed, 28 May 2003 17:00:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L82R-00006D-00 for megaco-web-archive@ietf.org; Wed, 28 May 2003 17:00:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SL0NB11489; Wed, 28 May 2003 17:00:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKxIB11103 for ; Wed, 28 May 2003 16:59:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23549 for ; Wed, 28 May 2003 16:59:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L7zO-00001X-00 for megaco@ietf.org; Wed, 28 May 2003 16:57:38 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19L7zO-00000Y-00 for megaco@ietf.org; Wed, 28 May 2003 16:57:38 -0400 Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 28 May 2003 16:58:42 -0400 Message-Id: <5.2.0.9.0.20030528164749.0297e3f8@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 28 May 2003 16:56:07 -0400 To: Tom Taylor , megaco@ietf.org From: Aleksandr Ryabin Subject: Re: [Megaco] CAS suspend/resume processing In-Reply-To: <3ED520AA.5050303@nortelnetworks.com> References: <20030528202839.GJ87245@frogman.motivity.ca> <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528133150.06487c30@imap.winphoria.com> <5.2.0.9.0.20030528154550.02ac6608@imap.winphoria.com> <3ED5170C.7080705@nortelnetworks.com> <20030528202839.GJ87245@frogman.motivity.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 28 May 2003 20:58:43.0193 (UTC) FILETIME=[EC393690:01C3255B] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Yes, now it makes sense. Although a call flow example would be nice, that is to be added to the package spec which show that it will be Answer event. As a side note, all call flow examples in the draft stop after call is answered, IMO it would be cleaner is they continue with termination. Thanks. Aleks At 04:48 PM 5/28/2003, Tom Taylor wrote: >That seems right: the MGC should be responsible for managing ISUP Timer >T6. And BTW, the reference I found was Q.696, not Q.695. > >Just to summarize in terms of Aleksandr's original point: if you're >talking an analogue line working into ISUP, you're talking >on-hook/off-hook events as in Annex E. If you're talking CAS signalling, >you use the CAS packages to detect or signal Clearback and Answer. In >either case the MGC is responsible for the interworking and the applicable >standard is Q.696 rather than the CAS package documentation. > >Vance Shipley wrote: >>As there is no CAS "suspend" or "resume" the issue becomes whether >>or not the MG must understand a call state of "suspended" to make >>it possible to provide the intended functionality. Since the >>timing required in processing the suspend/resume is in the order of tens >>of seconds I'd say not. >> -Vance >>On Wed, May 28, 2003 at 04:07:40PM -0400, Tom Taylor wrote: >>} OK, that's consistent with the Q.699 diagram. What it says is that in >>the } CAS-to-ISUP direction, suspend is initiated by receipt of a >>Clearback } signal, resume by a new Answer signal. I see nothing that >>needs to be } standardized at the Megaco level for this one. It's not >>so clear what } happens in the opposite direction, and maybe that's the >>source of your } difficulty. >>} >>} Aleksandr Ryabin wrote: >>} >ITU-T Q.764 par 2.4 "Suspend, resume", page 30. >>} > Aleks >>} > >>} >At 03:04 PM 5/28/2003, Tom Taylor wrote: >>} > >>} >>I was looking for a standard describing the interworking you are >>} >>trying to gain support for. So far I've found one relevant figure >>in } >>Q.699 and the logic diagrams in e.g. Q.655. Do you have any more >>} >>precise references? >>} >> >>} >>} _______________________________________________ >>} Megaco mailing list >>} Megaco@ietf.org >>} https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed May 28 23:31:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04903 for ; Wed, 28 May 2003 23:31:18 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T3QKB04267; Wed, 28 May 2003 23:26:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T3LpB04144 for ; Wed, 28 May 2003 23:21:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04734 for ; Wed, 28 May 2003 23:21:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LDxd-0002Wc-00 for megaco@ietf.org; Wed, 28 May 2003 23:20:13 -0400 Received: from ms-smtp-03.southeast.rr.com ([24.93.67.84]) by ietf-mx with esmtp (Exim 4.12) id 19LDxc-0002WZ-00 for megaco@ietf.org; Wed, 28 May 2003 23:20:12 -0400 Received: from CPR1 (rdu74-176-143.nc.rr.com [24.74.176.143]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with SMTP id h4T3KGZo019223 for ; Wed, 28 May 2003 23:20:16 -0400 (EDT) From: "Chris" To: Date: Wed, 28 May 2003 23:21:50 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0115_01C3256F.EA990400" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [Megaco] Information Request Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0115_01C3256F.EA990400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Greetings, I am trying to find information on MEGACO and CAS related signaling. I would very much appreciate applicable references. Thanks and regards, Christopher ------=_NextPart_000_0115_01C3256F.EA990400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Greetings,

 

I am trying to find information on MEGACO and CAS related = signaling. I would very much appreciate applicable = references.

 

Thanks and regards,

 

Christopher

------=_NextPart_000_0115_01C3256F.EA990400-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed May 28 23:32:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04937 for ; Wed, 28 May 2003 23:32:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4T3WAh04579 for megaco-archive@odin.ietf.org; Wed, 28 May 2003 23:32:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T3WAB04576 for ; Wed, 28 May 2003 23:32:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04934 for ; Wed, 28 May 2003 23:32:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LE7c-0002af-00 for megaco-web-archive@ietf.org; Wed, 28 May 2003 23:30:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LE7b-0002ac-00 for megaco-web-archive@ietf.org; Wed, 28 May 2003 23:30:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T3QKB04267; Wed, 28 May 2003 23:26:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T3LpB04144 for ; Wed, 28 May 2003 23:21:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04734 for ; Wed, 28 May 2003 23:21:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LDxd-0002Wc-00 for megaco@ietf.org; Wed, 28 May 2003 23:20:13 -0400 Received: from ms-smtp-03.southeast.rr.com ([24.93.67.84]) by ietf-mx with esmtp (Exim 4.12) id 19LDxc-0002WZ-00 for megaco@ietf.org; Wed, 28 May 2003 23:20:12 -0400 Received: from CPR1 (rdu74-176-143.nc.rr.com [24.74.176.143]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with SMTP id h4T3KGZo019223 for ; Wed, 28 May 2003 23:20:16 -0400 (EDT) From: "Chris" To: Date: Wed, 28 May 2003 23:21:50 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0115_01C3256F.EA990400" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [Megaco] Information Request Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0115_01C3256F.EA990400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Greetings, I am trying to find information on MEGACO and CAS related signaling. I would very much appreciate applicable references. Thanks and regards, Christopher ------=_NextPart_000_0115_01C3256F.EA990400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Greetings,

 

I am trying to find information on MEGACO and CAS related = signaling. I would very much appreciate applicable = references.

 

Thanks and regards,

 

Christopher

------=_NextPart_000_0115_01C3256F.EA990400-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco