From mailman-admin@ietf.org Sun Feb 1 09:14:52 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13836 for ; Sun, 1 Feb 2004 09:14:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnIMj-0007KC-Tb for megaco-archive@lists.ietf.org; Sun, 01 Feb 2004 09:14:25 -0500 Date: Sun, 01 Feb 2004 09:14:25 -0500 Message-ID: <20040201141425.1364.80891.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 Mon Feb 2 08:24:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10440 for ; Mon, 2 Feb 2004 08:24:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ane3V-0005c8-GY; Mon, 02 Feb 2004 08:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AncwN-0001jA-AT for megaco@optimus.ietf.org; Mon, 02 Feb 2004 07:12:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06229 for ; Mon, 2 Feb 2004 07:12:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AncwM-000574-00 for megaco@ietf.org; Mon, 02 Feb 2004 07:12:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AncvR-00051e-00 for megaco@ietf.org; Mon, 02 Feb 2004 07:11:37 -0500 Received: from ext-proxy-2.ftel.co.uk ([192.65.220.98]) by ietf-mx with esmtp (Exim 4.12) id 1Ancv9-0004uG-00 for megaco@ietf.org; Mon, 02 Feb 2004 07:11:19 -0500 Received: from utility-1.ftel.co.uk (utility-1.ftel.co.uk [193.112.172.10]) by ext-proxy-2.ftel.co.uk (8.12.10/8.12.9/Revision:1.91/relay-in/ssl/db) with ESMTP id i12CAgMu027706 for ; Mon, 2 Feb 2004 12:10:42 GMT Received: from DALLAPTOP (dhcp-172-16-48-64.ftel.co.uk [172.16.48.64]) by utility-1.ftel.co.uk (8.12.9+Sun/8.12.9/Revision:1.90/db) with SMTP id i12CAaNk008396 for ; Mon, 2 Feb 2004 12:10:36 GMT Message-ID: <008001c3e985$9114d690$403010ac@DALLAPTOP> From: "Dal Chohan" To: Date: Mon, 2 Feb 2004 12:10:34 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007D_01C3E985.8F986FC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Subject: [Megaco] Events Descriptor with KeepActive set and an Emebdded Signals Descriptor Sender: megaco-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_007D_01C3E985.8F986FC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable H.248v2 clause 7.1.9 states that ; "A media gateway controller shall not = send EventsDescriptors with an event both marked KeepActive and = containing an embedded SignalsDescriptor" I think that this is unnecessarily too restrictive and unduly reduces = the flexibility of H.248. The judicious use of the KA flag within the = Embedded Signal descriptor itself can keep the Signal currently being = applied active. The following scenario describes a practical situation where the above = rule is violate. Take the case where "Automatic Metering" is applied to = an analogue line and automatic meter pulses are being generated by the = MG. Now the MG is monitoring for "On-Hook" and the KA (KeepActive) flag = is sent against the "On-Hook" event. Upon detection of "On-Hook" the = event is reported to the MGC by the MG and the automatic metering still = continues.=20 Now the MGC sends a command requesting that the MG monitor for = "Off-Hook" with the KA flag set, plus an Embedded signals/event = descriptor indicating that "dial tone" should be played. In addition the = KA flag is set for the "enable metering" signal to ensure that the = automatic metering continues when the dial tone signal is applied , and = the digit map descriptor is also enabled. Now this sequence clearly = violates the rule stated above. I would therefore recommend that the sentence above is deleted from the = specification unless someone can think off a good reason for keeping it, = because it is unnecessarily too restrictive and reduces the flexibility = of the H.248 protocol. Regards. Dal Chohan ------=_NextPart_000_007D_01C3E985.8F986FC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
H.248v2 clause=20 7.1.9 states that ; "A media gateway controller shall not send EventsDescriptors = with an=20 event both marked KeepActive and containing an embedded=20 SignalsDescriptor"

I think that this is unnecessarily too = restrictive=20 and unduly reduces the flexibility of H.248. The judicious use of the KA = flag=20 within the Embedded Signal descriptor itself can keep the Signal = currently being=20 applied active.

The following scenario describes a = practical=20 situation where the above rule is violate. Take the case where = "Automatic=20 Metering" is applied to an analogue line and automatic meter pulses are = being=20 generated  by the MG. Now the MG is monitoring for "On-Hook" and = the KA=20 (KeepActive) flag is sent against the "On-Hook" event. Upon detection = of =20 "On-Hook" the event is reported to the MGC by the MG and the automatic = metering=20 still continues.

Now the MGC sends a command requesting = that the MG=20 monitor for "Off-Hook" with the KA flag set, plus an Embedded=20 signals/event descriptor indicating that "dial tone" should be = played. In=20 addition the KA flag is set for the "enable metering" signal to ensure = that the=20 automatic metering continues when the dial tone signal is applied , = and the=20 digit map descriptor is also enabled. Now this sequence clearly violates = the=20 rule stated above.

I would therefore recommend = that the=20 sentence above is deleted from the specification unless someone can = think off a=20 good reason for keeping it, because it is unnecessarily too restrictive = and=20 reduces the flexibility of the H.248 = protocol.

 

 
Regards.
 
 
Dal = Chohan
------=_NextPart_000_007D_01C3E985.8F986FC0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 2 13:38:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29741 for ; Mon, 2 Feb 2004 13:38:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnixP-0001m6-M6; Mon, 02 Feb 2004 13:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aniwe-0001XQ-Ok for megaco@optimus.ietf.org; Mon, 02 Feb 2004 13:37:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29655 for ; Mon, 2 Feb 2004 13:37:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aniwc-0007G8-00 for megaco@ietf.org; Mon, 02 Feb 2004 13:37:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnivT-000726-00 for megaco@ietf.org; Mon, 02 Feb 2004 13:36:03 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Anitz-0006fK-00 for megaco@ietf.org; Mon, 02 Feb 2004 13:34:31 -0500 Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i12IXTZ22379 for ; Mon, 2 Feb 2004 12:33:34 -0600 (CST) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id NAA12164; Mon, 2 Feb 2004 13:33:26 -0500 (EST) Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id NAA12160; Mon, 2 Feb 2004 13:33:25 -0500 (EST) Message-ID: <401E97D5.5070806@bell-labs.com> Date: Mon, 02 Feb 2004 13:32:53 -0500 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MEGACO list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Megaco] pulse dialing ? Sender: megaco-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 Are there packages for pulse dialing? Generally, you could just use the DTMF detection packages. A '2' is a '2', right? But consider this US-centric example: The *XX services, such as *69, are supported via pulse dialing 1169. Supporting this would require not only differentiating between pulse dialed digits and touch-tone, but also different digit maps for each. Thoughts? -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Feb 2 13:43:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00284 for ; Mon, 2 Feb 2004 13:43:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anj2U-0002Rk-0r for megaco-archive@odin.ietf.org; Mon, 02 Feb 2004 13:43:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12IhHDc009400 for megaco-archive@odin.ietf.org; Mon, 2 Feb 2004 13:43:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anj2T-0002RX-RE for megaco-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 13:43:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00259 for ; Mon, 2 Feb 2004 13:43:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anj2R-0000hH-00 for megaco-web-archive@ietf.org; Mon, 02 Feb 2004 13:43:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnizW-00007g-00 for megaco-web-archive@ietf.org; Mon, 02 Feb 2004 13:40:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Anixj-0007Tz-00 for megaco-web-archive@ietf.org; Mon, 02 Feb 2004 13:38:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnixP-0001m6-M6; Mon, 02 Feb 2004 13:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aniwe-0001XQ-Ok for megaco@optimus.ietf.org; Mon, 02 Feb 2004 13:37:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29655 for ; Mon, 2 Feb 2004 13:37:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aniwc-0007G8-00 for megaco@ietf.org; Mon, 02 Feb 2004 13:37:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnivT-000726-00 for megaco@ietf.org; Mon, 02 Feb 2004 13:36:03 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Anitz-0006fK-00 for megaco@ietf.org; Mon, 02 Feb 2004 13:34:31 -0500 Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i12IXTZ22379 for ; Mon, 2 Feb 2004 12:33:34 -0600 (CST) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id NAA12164; Mon, 2 Feb 2004 13:33:26 -0500 (EST) Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id NAA12160; Mon, 2 Feb 2004 13:33:25 -0500 (EST) Message-ID: <401E97D5.5070806@bell-labs.com> Date: Mon, 02 Feb 2004 13:32:53 -0500 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MEGACO list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] pulse dialing ? Sender: megaco-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Are there packages for pulse dialing? Generally, you could just use the DTMF detection packages. A '2' is a '2', right? But consider this US-centric example: The *XX services, such as *69, are supported via pulse dialing 1169. Supporting this would require not only differentiating between pulse dialed digits and touch-tone, but also different digit maps for each. Thoughts? -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 2 13:55:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01388 for ; Mon, 2 Feb 2004 13:55:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjDs-0003qP-7y; Mon, 02 Feb 2004 13:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjDG-0003mh-Qg for megaco@optimus.ietf.org; Mon, 02 Feb 2004 13:54:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01239 for ; Mon, 2 Feb 2004 13:54:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjDE-00039p-00 for megaco@ietf.org; Mon, 02 Feb 2004 13:54:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anj9q-0002Mw-00 for megaco@ietf.org; Mon, 02 Feb 2004 13:50:55 -0500 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1Anj71-0001Za-00 for megaco@ietf.org; Mon, 02 Feb 2004 13:47:59 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i12IlJ319719 for ; Mon, 2 Feb 2004 13:47:20 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3DCZWK>; Mon, 2 Feb 2004 13:47:20 -0500 Message-ID: From: "Kevin Boyle" To: Troy Cauble , MEGACO list Subject: RE: [Megaco] pulse dialing ? Date: Mon, 2 Feb 2004 13:47:16 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I don't see where it matters if you collect *XX or 11XX. Let's take the example below: In North America, starting with 1 means a call out of your LATA. However, there are no NPAs or NXXs in NA that begin with 1. Therefore, the switch will know that this is a feature code since it starts with 11. (Of course, this is why there are no NPAs or NXXs that begin with 1). Kevin -----Original Message----- From: Troy Cauble [mailto:troy@bell-labs.com] Sent: Monday, February 02, 2004 1:33 PM To: MEGACO list Subject: [Megaco] pulse dialing ? Are there packages for pulse dialing? Generally, you could just use the DTMF detection packages. A '2' is a '2', right? But consider this US-centric example: The *XX services, such as *69, are supported via pulse dialing 1169. Supporting this would require not only differentiating between pulse dialed digits and touch-tone, but also different digit maps for each. Thoughts? -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Feb 2 14:00:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02315 for ; Mon, 2 Feb 2004 14:00:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjIZ-0004sn-VV for megaco-archive@odin.ietf.org; Mon, 02 Feb 2004 13:59:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12Ixt7F018763 for megaco-archive@odin.ietf.org; Mon, 2 Feb 2004 13:59:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjIZ-0004sX-SA for megaco-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 13:59:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02201 for ; Mon, 2 Feb 2004 13:59:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjIX-0004bQ-00 for megaco-web-archive@ietf.org; Mon, 02 Feb 2004 13:59:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnjGc-00044I-00 for megaco-web-archive@ietf.org; Mon, 02 Feb 2004 13:57:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnjDr-0003Jb-00 for megaco-web-archive@ietf.org; Mon, 02 Feb 2004 13:55:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjDs-0003qP-7y; Mon, 02 Feb 2004 13:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjDG-0003mh-Qg for megaco@optimus.ietf.org; Mon, 02 Feb 2004 13:54:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01239 for ; Mon, 2 Feb 2004 13:54:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjDE-00039p-00 for megaco@ietf.org; Mon, 02 Feb 2004 13:54:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anj9q-0002Mw-00 for megaco@ietf.org; Mon, 02 Feb 2004 13:50:55 -0500 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1Anj71-0001Za-00 for megaco@ietf.org; Mon, 02 Feb 2004 13:47:59 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i12IlJ319719 for ; Mon, 2 Feb 2004 13:47:20 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3DCZWK>; Mon, 2 Feb 2004 13:47:20 -0500 Message-ID: From: "Kevin Boyle" To: Troy Cauble , MEGACO list Subject: RE: [Megaco] pulse dialing ? Date: Mon, 2 Feb 2004 13:47:16 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 I don't see where it matters if you collect *XX or 11XX. Let's take the example below: In North America, starting with 1 means a call out of your LATA. However, there are no NPAs or NXXs in NA that begin with 1. Therefore, the switch will know that this is a feature code since it starts with 11. (Of course, this is why there are no NPAs or NXXs that begin with 1). Kevin -----Original Message----- From: Troy Cauble [mailto:troy@bell-labs.com] Sent: Monday, February 02, 2004 1:33 PM To: MEGACO list Subject: [Megaco] pulse dialing ? Are there packages for pulse dialing? Generally, you could just use the DTMF detection packages. A '2' is a '2', right? But consider this US-centric example: The *XX services, such as *69, are supported via pulse dialing 1169. Supporting this would require not only differentiating between pulse dialed digits and touch-tone, but also different digit maps for each. Thoughts? -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 3 04:59:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00138 for ; Tue, 3 Feb 2004 04:59:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnxKg-00014M-Jh; Tue, 03 Feb 2004 04:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnxJv-00012u-6u for megaco@optimus.ietf.org; Tue, 03 Feb 2004 04:58:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00101 for ; Tue, 3 Feb 2004 04:58:12 -0500 (EST) From: Jean-Luc.Lecuyer@alcatel.fr Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnxJs-0001Mc-00 for megaco@ietf.org; Tue, 03 Feb 2004 04:58:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnxIy-0001Ho-00 for megaco@ietf.org; Tue, 03 Feb 2004 04:57:17 -0500 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail3.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1AnxIA-00017d-00 for megaco@ietf.org; Tue, 03 Feb 2004 04:56:26 -0500 Received: from frmail26.netfr.alcatel.fr (frmail26.netfr.alcatel.fr [155.132.182.156]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i139tlQM030939 for ; Tue, 3 Feb 2004 10:55:47 +0100 To: megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 3 Feb 2004 10:55:58 +0100 X-MIMETrack: Serialize by Router on FRMAIL26/FR/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/03/2004 10:55:46 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Subject: [Megaco] Analog line state Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , High all Initial state : the MG is programmed to send a notify if a transition on-hook / off-hook or vice versa happens. Nevertheless the MGC can miss a transition state from on-hook / off-hook or vice versa (lost of H248 dialog with the MG) I am looking for a way to know the state of a analog line (on-hook / off-hook). I expected to use the AuditValue on the termination to know it but unfortunately the AuditValue does not give this information. In my understanding the only way to retrieve this information is to send a modify command on the termination to reprogam the detection of event al/on and al/of. What do you think about that ? Thank-you for your help. Regards Jean-Luc Lecuyer _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 3 07:37:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06680 for ; Tue, 3 Feb 2004 07:37:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnznZ-0008EN-5s; Tue, 03 Feb 2004 07:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anzmw-0008D0-Qd for megaco@optimus.ietf.org; Tue, 03 Feb 2004 07:36:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06620 for ; Tue, 3 Feb 2004 07:36:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anzmw-0003Pz-00 for megaco@ietf.org; Tue, 03 Feb 2004 07:36:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anzm5-0003Kz-00 for megaco@ietf.org; Tue, 03 Feb 2004 07:35:30 -0500 Received: from [192.144.74.33] (helo=p-mail1.rd.francetelecom.com) by ietf-mx with esmtp (Exim 4.12) id 1AnzlP-0003BG-00 for megaco@ietf.org; Tue, 03 Feb 2004 07:34:47 -0500 Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 13:32:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : [Megaco] pulse dialing ? Date: Tue, 3 Feb 2004 13:32:24 +0100 Message-ID: <869954804BD53B41AF69F225F15FC331DB1F3E@ftrdmel1.rd.francetelecom.fr> Thread-Topic: [Megaco] pulse dialing ? Thread-Index: AcPpvj+cEf8s3+qpQ0aCpM0N3SyYuwAkNq3w From: "CHATRAS Bruno FTRD/DAC/ISS" To: "Kevin Boyle" , "Troy Cauble" , "MEGACO list" X-OriginalArrivalTime: 03 Feb 2004 12:32:26.0045 (UTC) FILETIME=[C7B786D0:01C3EA51] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I believe that using different set of packages would be more appropriate = for DTMF detection and Pulse Dialing detection, as these two dialing = procedures involve completly different types of resources in the MG.=20 Moreover, the current wording of the DTMF package (which extends the = Tone Detection package) explicitly refers to the detection of audio = tones (as opposed to pulses). Use of the DTMF package for supporting = pulse dialing would, as a minimum, require changes to the package = description. Use of the same package for both DTMF and pulse dialing would also have = a side effect on audit procedures: Auditing the list of supported = packages would not enable the MGC to know whether the MG supports DTMF = detection, pulse detection, or both. Bruno -----Message d'origine----- De : megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] De la part de = Kevin Boyle Envoy=E9 : lundi 2 f=E9vrier 2004 19:47 =C0 : Troy Cauble; MEGACO list Objet : RE: [Megaco] pulse dialing ? I don't see where it matters if you collect *XX or 11XX. Let's take the = example below: In North America, starting with 1 means a call out of = your LATA. However, there are no NPAs or NXXs in NA that begin with 1. = Therefore, the switch will know that this is a feature code since it = starts with 11. (Of course, this is why there are no NPAs or NXXs that = begin with 1). Kevin=20 -----Original Message----- From: Troy Cauble [mailto:troy@bell-labs.com]=20 Sent: Monday, February 02, 2004 1:33 PM To: MEGACO list Subject: [Megaco] pulse dialing ? Are there packages for pulse dialing? Generally, you could just use the DTMF detection packages. A '2' is a '2', right? But consider this US-centric example: The *XX services, such as *69, = are supported via pulse dialing 1169. Supporting this would require not only differentiating between pulse = dialed digits and touch-tone, but also different digit maps for each. Thoughts? -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue Feb 3 07:38:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06731 for ; Tue, 3 Feb 2004 07:38:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anzou-0000C2-6t for megaco-archive@odin.ietf.org; Tue, 03 Feb 2004 07:38:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13CcOn7000738 for megaco-archive@odin.ietf.org; Tue, 3 Feb 2004 07:38:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anzot-0000Bp-VQ for megaco-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 07:38:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06719 for ; Tue, 3 Feb 2004 07:38:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anzot-0003cb-00 for megaco-web-archive@ietf.org; Tue, 03 Feb 2004 07:38:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anznz-0003X0-00 for megaco-web-archive@ietf.org; Tue, 03 Feb 2004 07:37:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnznZ-0003RW-00 for megaco-web-archive@ietf.org; Tue, 03 Feb 2004 07:37:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnznZ-0008EN-5s; Tue, 03 Feb 2004 07:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anzmw-0008D0-Qd for megaco@optimus.ietf.org; Tue, 03 Feb 2004 07:36:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06620 for ; Tue, 3 Feb 2004 07:36:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anzmw-0003Pz-00 for megaco@ietf.org; Tue, 03 Feb 2004 07:36:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anzm5-0003Kz-00 for megaco@ietf.org; Tue, 03 Feb 2004 07:35:30 -0500 Received: from [192.144.74.33] (helo=p-mail1.rd.francetelecom.com) by ietf-mx with esmtp (Exim 4.12) id 1AnzlP-0003BG-00 for megaco@ietf.org; Tue, 03 Feb 2004 07:34:47 -0500 Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 13:32:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : [Megaco] pulse dialing ? Date: Tue, 3 Feb 2004 13:32:24 +0100 Message-ID: <869954804BD53B41AF69F225F15FC331DB1F3E@ftrdmel1.rd.francetelecom.fr> Thread-Topic: [Megaco] pulse dialing ? Thread-Index: AcPpvj+cEf8s3+qpQ0aCpM0N3SyYuwAkNq3w From: "CHATRAS Bruno FTRD/DAC/ISS" To: "Kevin Boyle" , "Troy Cauble" , "MEGACO list" X-OriginalArrivalTime: 03 Feb 2004 12:32:26.0045 (UTC) FILETIME=[C7B786D0:01C3EA51] Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I believe that using different set of packages would be more appropriate = for DTMF detection and Pulse Dialing detection, as these two dialing = procedures involve completly different types of resources in the MG.=20 Moreover, the current wording of the DTMF package (which extends the = Tone Detection package) explicitly refers to the detection of audio = tones (as opposed to pulses). Use of the DTMF package for supporting = pulse dialing would, as a minimum, require changes to the package = description. Use of the same package for both DTMF and pulse dialing would also have = a side effect on audit procedures: Auditing the list of supported = packages would not enable the MGC to know whether the MG supports DTMF = detection, pulse detection, or both. Bruno -----Message d'origine----- De : megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] De la part de = Kevin Boyle Envoy=E9 : lundi 2 f=E9vrier 2004 19:47 =C0 : Troy Cauble; MEGACO list Objet : RE: [Megaco] pulse dialing ? I don't see where it matters if you collect *XX or 11XX. Let's take the = example below: In North America, starting with 1 means a call out of = your LATA. However, there are no NPAs or NXXs in NA that begin with 1. = Therefore, the switch will know that this is a feature code since it = starts with 11. (Of course, this is why there are no NPAs or NXXs that = begin with 1). Kevin=20 -----Original Message----- From: Troy Cauble [mailto:troy@bell-labs.com]=20 Sent: Monday, February 02, 2004 1:33 PM To: MEGACO list Subject: [Megaco] pulse dialing ? Are there packages for pulse dialing? Generally, you could just use the DTMF detection packages. A '2' is a '2', right? But consider this US-centric example: The *XX services, such as *69, = are supported via pulse dialing 1169. Supporting this would require not only differentiating between pulse = dialed digits and touch-tone, but also different digit maps for each. Thoughts? -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 3 10:07:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11724 for ; Tue, 3 Feb 2004 10:07:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao28j-0003yT-AF; Tue, 03 Feb 2004 10:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao1vc-0000bD-IZ for megaco@optimus.ietf.org; Tue, 03 Feb 2004 09:53:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10752 for ; Tue, 3 Feb 2004 09:53:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao1va-00015z-00 for megaco@ietf.org; Tue, 03 Feb 2004 09:53:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao1ui-00010l-00 for megaco@ietf.org; Tue, 03 Feb 2004 09:52:32 -0500 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 1Ao1u8-0000t3-00 for megaco@ietf.org; Tue, 03 Feb 2004 09:51:56 -0500 Received: from vies1k7x.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i13EpPTm028219 for ; Tue, 3 Feb 2004 15:51:25 +0100 Received: from vies141a.sie.siemens.at (vies1kbx.sie.siemens.at [158.226.135.174]) by vies1k7x.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i13EpOcx027919 for ; Tue, 3 Feb 2004 15:51:24 +0100 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Feb 2004 15:51:36 +0100 Message-ID: From: Reitter Johann To: "'megaco@ietf.org'" Date: Tue, 3 Feb 2004 15:51:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Megaco] Megaco/H.248 versus snmp for midcom Sender: megaco-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: , Dear all, may someone please explain to me why megaco/H.248 is "real-time capable" whereas snmp is not? Thanks in advance Regards, Hans _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue Feb 3 10:09:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11949 for ; Tue, 3 Feb 2004 10:09:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao2AL-0004g7-OQ for megaco-archive@odin.ietf.org; Tue, 03 Feb 2004 10:08:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13F8faJ017977 for megaco-archive@odin.ietf.org; Tue, 3 Feb 2004 10:08:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao2AL-0004fs-JA for megaco-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 10:08:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11878 for ; Tue, 3 Feb 2004 10:08:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao2AJ-0002tb-00 for megaco-web-archive@ietf.org; Tue, 03 Feb 2004 10:08:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao29R-0002lP-00 for megaco-web-archive@ietf.org; Tue, 03 Feb 2004 10:07:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao28n-0002dm-00 for megaco-web-archive@ietf.org; Tue, 03 Feb 2004 10:07:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao28j-0003yT-AF; Tue, 03 Feb 2004 10:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao1vc-0000bD-IZ for megaco@optimus.ietf.org; Tue, 03 Feb 2004 09:53:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10752 for ; Tue, 3 Feb 2004 09:53:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao1va-00015z-00 for megaco@ietf.org; Tue, 03 Feb 2004 09:53:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao1ui-00010l-00 for megaco@ietf.org; Tue, 03 Feb 2004 09:52:32 -0500 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 1Ao1u8-0000t3-00 for megaco@ietf.org; Tue, 03 Feb 2004 09:51:56 -0500 Received: from vies1k7x.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i13EpPTm028219 for ; Tue, 3 Feb 2004 15:51:25 +0100 Received: from vies141a.sie.siemens.at (vies1kbx.sie.siemens.at [158.226.135.174]) by vies1k7x.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i13EpOcx027919 for ; Tue, 3 Feb 2004 15:51:24 +0100 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Feb 2004 15:51:36 +0100 Message-ID: From: Reitter Johann To: "'megaco@ietf.org'" Date: Tue, 3 Feb 2004 15:51:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] Megaco/H.248 versus snmp for midcom Sender: megaco-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Dear all, may someone please explain to me why megaco/H.248 is "real-time capable" whereas snmp is not? Thanks in advance Regards, Hans _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 3 12:16:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19398 for ; Tue, 3 Feb 2004 12:16:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao49a-0001q3-RR; Tue, 03 Feb 2004 12:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao499-0001oP-0V for megaco@optimus.ietf.org; Tue, 03 Feb 2004 12:15:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19328 for ; Tue, 3 Feb 2004 12:15:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao497-0002Bw-00 for megaco@ietf.org; Tue, 03 Feb 2004 12:15:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao484-00023Q-00 for megaco@ietf.org; Tue, 03 Feb 2004 12:14:29 -0500 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1Ao479-0001pp-00 for megaco@ietf.org; Tue, 03 Feb 2004 12:13:31 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i13HD0417672 for ; Tue, 3 Feb 2004 12:13:00 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3DDN4P>; Tue, 3 Feb 2004 12:13:00 -0500 Message-ID: From: "Kevin Boyle" To: Reitter Johann , "'megaco@ietf.org'" Subject: RE: [Megaco] Megaco/H.248 versus snmp for midcom Date: Tue, 3 Feb 2004 12:12:51 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , SNMP and H.248 address two different problem spaces. H.248 is designed for real-time communications control. SNMP is designed for remote management of network equipment. Generally speaking, management is not a real-time function, so the things that must be taken into consideration for real-time control were not built into SNMP. Kevin -----Original Message----- From: Reitter Johann [mailto:johann.reitter@siemens.com] Sent: Tuesday, February 03, 2004 9:52 AM To: 'megaco@ietf.org' Subject: [Megaco] Megaco/H.248 versus snmp for midcom Dear all, may someone please explain to me why megaco/H.248 is "real-time capable" whereas snmp is not? Thanks in advance Regards, Hans _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue Feb 3 12:18:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19527 for ; Tue, 3 Feb 2004 12:18:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4BA-0001zF-Sq for megaco-archive@odin.ietf.org; Tue, 03 Feb 2004 12:17:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13HHeHD007631 for megaco-archive@odin.ietf.org; Tue, 3 Feb 2004 12:17:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4BA-0001z0-MT for megaco-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 12:17:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19513 for ; Tue, 3 Feb 2004 12:17:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4B9-0002UC-00 for megaco-web-archive@ietf.org; Tue, 03 Feb 2004 12:17:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao4AC-0002Mm-00 for megaco-web-archive@ietf.org; Tue, 03 Feb 2004 12:16:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao49a-0002Ev-00 for megaco-web-archive@ietf.org; Tue, 03 Feb 2004 12:16:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao49a-0001q3-RR; Tue, 03 Feb 2004 12:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao499-0001oP-0V for megaco@optimus.ietf.org; Tue, 03 Feb 2004 12:15:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19328 for ; Tue, 3 Feb 2004 12:15:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao497-0002Bw-00 for megaco@ietf.org; Tue, 03 Feb 2004 12:15:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao484-00023Q-00 for megaco@ietf.org; Tue, 03 Feb 2004 12:14:29 -0500 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1Ao479-0001pp-00 for megaco@ietf.org; Tue, 03 Feb 2004 12:13:31 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i13HD0417672 for ; Tue, 3 Feb 2004 12:13:00 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3DDN4P>; Tue, 3 Feb 2004 12:13:00 -0500 Message-ID: From: "Kevin Boyle" To: Reitter Johann , "'megaco@ietf.org'" Subject: RE: [Megaco] Megaco/H.248 versus snmp for midcom Date: Tue, 3 Feb 2004 12:12:51 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 SNMP and H.248 address two different problem spaces. H.248 is designed for real-time communications control. SNMP is designed for remote management of network equipment. Generally speaking, management is not a real-time function, so the things that must be taken into consideration for real-time control were not built into SNMP. Kevin -----Original Message----- From: Reitter Johann [mailto:johann.reitter@siemens.com] Sent: Tuesday, February 03, 2004 9:52 AM To: 'megaco@ietf.org' Subject: [Megaco] Megaco/H.248 versus snmp for midcom Dear all, may someone please explain to me why megaco/H.248 is "real-time capable" whereas snmp is not? Thanks in advance Regards, Hans _______________________________________________ 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 Feb 4 11:15:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12669 for ; Wed, 4 Feb 2004 11:15:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPg8-0006cX-Pw; Wed, 04 Feb 2004 11:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPfK-0006al-UU for megaco@optimus.ietf.org; Wed, 04 Feb 2004 11:14:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12640 for ; Wed, 4 Feb 2004 11:14:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoPfK-00054d-00 for megaco@ietf.org; Wed, 04 Feb 2004 11:14:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoPeO-000505-00 for megaco@ietf.org; Wed, 04 Feb 2004 11:13:16 -0500 Received: from ext-proxy-2.ftel.co.uk ([192.65.220.98]) by ietf-mx with esmtp (Exim 4.12) id 1AoPdx-0004vF-00 for megaco@ietf.org; Wed, 04 Feb 2004 11:12:49 -0500 Received: from utility-1.ftel.co.uk (utility-1.ftel.co.uk [193.112.172.10]) by ext-proxy-2.ftel.co.uk (8.12.10/8.12.9/Revision:1.91/relay-in/ssl/db) with ESMTP id i14GCGMu016540 for ; Wed, 4 Feb 2004 16:12:16 GMT Received: from DALLAPTOP (dhcp-172-16-48-64.ftel.co.uk [172.16.48.64]) by utility-1.ftel.co.uk (8.12.9+Sun/8.12.9/Revision:1.90/db) with SMTP id i14GCANk025674 for ; Wed, 4 Feb 2004 16:12:10 GMT Message-ID: <008a01c3eb39$a5fb5100$403010ac@DALLAPTOP> From: "Dal Chohan" To: Date: Wed, 4 Feb 2004 16:12:10 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01C3EB39.A4665920" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Subject: [Megaco] H.248.23 Enhanced Alerting 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_0087_01C3EB39.A4665920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The description of the "Call Waiting" signal defined in H.248.23 = specifies that call waiting patterns do not repeat - Is this correct? I would have thought that for a Call Waiting service that it would would = make perfect sense for the "call waiting" pattern to be repeatedly = applied by the MG until it was told to stop the call waiting signal by = the MGC (c.f. ringing) . It is the MGC that determines the interval = within which the waiting call should be accepted and thus determines the = overall duration of the call waiting pattern. Dal Chohan ------=_NextPart_000_0087_01C3EB39.A4665920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
The description of the "Call Waiting" = signal=20 defined in H.248.23 specifies that call waiting patterns do not repeat - = Is this=20 correct?
 
I would have thought that for a Call = Waiting=20 service that it would would make perfect sense for the "call waiting" = pattern to=20 be repeatedly applied by the MG until it was told to stop the call = waiting=20 signal by the MGC (c.f. ringing) . It is the MGC = that determines the=20 interval within which the waiting call should be accepted and thus = determines=20 the overall duration of the call waiting pattern.
 
 
 
Dal = Chohan
------=_NextPart_000_0087_01C3EB39.A4665920-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Feb 4 11:17:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12738 for ; Wed, 4 Feb 2004 11:17:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPiE-0006vC-4M for megaco-archive@odin.ietf.org; Wed, 04 Feb 2004 11:17:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14GHEEB026605 for megaco-archive@odin.ietf.org; Wed, 4 Feb 2004 11:17:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPiD-0006v2-Pd for megaco-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 11:17:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12713 for ; Wed, 4 Feb 2004 11:17:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoPiC-0005Lw-00 for megaco-web-archive@ietf.org; Wed, 04 Feb 2004 11:17:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoPhE-0005F6-00 for megaco-web-archive@ietf.org; Wed, 04 Feb 2004 11:16:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoPgM-00055c-00 for megaco-web-archive@ietf.org; Wed, 04 Feb 2004 11:15:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPg8-0006cX-Pw; Wed, 04 Feb 2004 11:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPfK-0006al-UU for megaco@optimus.ietf.org; Wed, 04 Feb 2004 11:14:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12640 for ; Wed, 4 Feb 2004 11:14:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoPfK-00054d-00 for megaco@ietf.org; Wed, 04 Feb 2004 11:14:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoPeO-000505-00 for megaco@ietf.org; Wed, 04 Feb 2004 11:13:16 -0500 Received: from ext-proxy-2.ftel.co.uk ([192.65.220.98]) by ietf-mx with esmtp (Exim 4.12) id 1AoPdx-0004vF-00 for megaco@ietf.org; Wed, 04 Feb 2004 11:12:49 -0500 Received: from utility-1.ftel.co.uk (utility-1.ftel.co.uk [193.112.172.10]) by ext-proxy-2.ftel.co.uk (8.12.10/8.12.9/Revision:1.91/relay-in/ssl/db) with ESMTP id i14GCGMu016540 for ; Wed, 4 Feb 2004 16:12:16 GMT Received: from DALLAPTOP (dhcp-172-16-48-64.ftel.co.uk [172.16.48.64]) by utility-1.ftel.co.uk (8.12.9+Sun/8.12.9/Revision:1.90/db) with SMTP id i14GCANk025674 for ; Wed, 4 Feb 2004 16:12:10 GMT Message-ID: <008a01c3eb39$a5fb5100$403010ac@DALLAPTOP> From: "Dal Chohan" To: Date: Wed, 4 Feb 2004 16:12:10 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01C3EB39.A4665920" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Subject: [Megaco] H.248.23 Enhanced Alerting 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0087_01C3EB39.A4665920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The description of the "Call Waiting" signal defined in H.248.23 = specifies that call waiting patterns do not repeat - Is this correct? I would have thought that for a Call Waiting service that it would would = make perfect sense for the "call waiting" pattern to be repeatedly = applied by the MG until it was told to stop the call waiting signal by = the MGC (c.f. ringing) . It is the MGC that determines the interval = within which the waiting call should be accepted and thus determines the = overall duration of the call waiting pattern. Dal Chohan ------=_NextPart_000_0087_01C3EB39.A4665920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
The description of the "Call Waiting" = signal=20 defined in H.248.23 specifies that call waiting patterns do not repeat - = Is this=20 correct?
 
I would have thought that for a Call = Waiting=20 service that it would would make perfect sense for the "call waiting" = pattern to=20 be repeatedly applied by the MG until it was told to stop the call = waiting=20 signal by the MGC (c.f. ringing) . It is the MGC = that determines the=20 interval within which the waiting call should be accepted and thus = determines=20 the overall duration of the call waiting pattern.
 
 
 
Dal = Chohan
------=_NextPart_000_0087_01C3EB39.A4665920-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Feb 4 11:30:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13292 for ; Wed, 4 Feb 2004 11:30:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPud-0007o7-CO; Wed, 04 Feb 2004 11:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPtw-0007fK-Dl for megaco@optimus.ietf.org; Wed, 04 Feb 2004 11:29:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13170 for ; Wed, 4 Feb 2004 11:29:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoPtv-0006pE-00 for megaco@ietf.org; Wed, 04 Feb 2004 11:29:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoPt4-0006i9-00 for megaco@ietf.org; Wed, 04 Feb 2004 11:28:27 -0500 Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx with smtp (Exim 4.12) id 1AoPs3-0006aq-00 for megaco@ietf.org; Wed, 04 Feb 2004 11:27:23 -0500 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1075903412; Wed Feb 4 18:28:07 2004 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id <12SLZWN4>; Wed, 4 Feb 2004 18:26:54 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F3810165F9@MAILSERVER> From: Raphael Tryster To: "'Dal Chohan'" , megaco@ietf.org Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. Date: Wed, 4 Feb 2004 18:26:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EB3B.B335C830" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , 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_01C3EB3B.B335C830 Content-Type: text/plain Kevin Boyle answered this question recently: Call wait patterns are generally replayed after a short amount of time (10 seconds in North America). Note that this is not a repetition -- this is actually a second distinct application of the signal. There are several feature scenarios where the second signal will not be applied -- if the waiting party hangs up, or if the callee flashes, to name a couple. As for the dt package, I believe the characterization of call wait tone as timeout is erroneous, although previous attempts to fix it have been rejected. I wrote the alerting package to be local-variant unaware, leaving it to the MG to be responsible for how the signals should be applied to its terminations. Note that most localities have more than one wait tone pattern, to allow for assignable distinctive tones (similar to assigning distinctive ringing patterns to different incoming callers). I see no reason to use dt/cw if using alert/cw. The alerting package provides far more functionality than the dt package for both ringing and call waiting. Kevin _____ From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, January 08, 2004 5:39 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: call waiting signal type In draft_boyle_megaco_alerting_03.txt, the alert/cw signal has type brief, whereas the standard signal dt/cw apparently has type timeout. Is this a matter of national protocol? The description of alert/cw says "Call wait patterns do not repeat". In Israel, a call waiting signal consists of 3 short tones, repeated once a few seconds later. If it is a matter of national protocol, does this mean that a particular installation will use either alert/cw or dt/cw, but not both? Raphael Tryster -----Original Message----- From: Dal Chohan [SMTP:D.Chohan@ftel.co.uk] Sent: Wednesday, 4 February 2004 18:12 To: megaco@ietf.org Subject: [Megaco] H.248.23 Enhanced Alerting Package. The description of the "Call Waiting" signal defined in H.248.23 specifies that call waiting patterns do not repeat - Is this correct? I would have thought that for a Call Waiting service that it would would make perfect sense for the "call waiting" pattern to be repeatedly applied by the MG until it was told to stop the call waiting signal by the MGC (c.f. ringing) . It is the MGC that determines the interval within which the waiting call should be accepted and thus determines the overall duration of the call waiting pattern. Dal Chohan ------_=_NextPart_001_01C3EB3B.B335C830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] H.248.23 Enhanced Alerting Package.

Kevin Boyle answered this question recen= tly:


Call wait patterns are generally replaye= d after a short amount of time (10 seconds in North America).=A0 Note tha= t this is not a repetition -- this is actually a second distinct applicat= ion of the signal.=A0 There are several feature scenarios where the secon= d signal will not be applied -- if the waiting party hangs up, or if the = callee flashes, to name a couple.

=A0
As for the dt package, I believe the ch= aracterization of call wait tone as timeout is erroneous, although previo= us attempts to fix it have been rejected.=A0 I wrote the alerting package= to be local-variant unaware, leaving it to the MG to be responsible for = how the signals should be applied to its terminations.=A0 Note that most = localities have more than one wait tone pattern, to allow for assignable = distinctive tones (similar to assigning distinctive ringing patterns to d= ifferent incoming callers).

=A0
I see no reason to use dt/cw if using a= lert/cw.=A0 The alerting package provides far more functionality than the= dt package for both ringing and call waiting.

=A0
Kevin


=A0 _____ =A0

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

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

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

    Raphael Tryster


    -----Original Mess= age-----
    From:   Dal Chohan [SMTP:D= =2EChohan@ftel.co.uk]
    Sent:   Wednesday, 4 February 2004 18:12
    To:     megaco@ietf.org
    Subject:    &nbs= p;   [Megaco] H.248.23= Enhanced Alerting Package.

    =A0
    The description of the "Call Waiti= ng" signal defined in H.248.23 specifies that call waiting patterns = do not repeat - Is this correct?

    =A0
    I would have thought that for a Call Wa= iting service that it would would make perfect sense for the "call w= aiting" pattern to be repeatedly applied by the MG until it was told= to stop the call waiting signal by the MGC (c.f. ringing) .=A0It is the = MGC that=A0determines the interval within which the waiting call should b= e accepted and thus determines the overall duration of the=A0call waiting= pattern.

    =A0
    =A0
    =A0
    Dal Chohan

------_=_NextPart_001_01C3EB3B.B335C830-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Feb 4 11:32:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13394 for ; Wed, 4 Feb 2004 11:32:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPw5-0008B1-FI for megaco-archive@odin.ietf.org; Wed, 04 Feb 2004 11:31:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14GVXYW031432 for megaco-archive@odin.ietf.org; Wed, 4 Feb 2004 11:31:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPw5-0008At-4m for megaco-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 11:31:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13388 for ; Wed, 4 Feb 2004 11:31:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoPw4-000782-00 for megaco-web-archive@ietf.org; Wed, 04 Feb 2004 11:31:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoPvD-000719-00 for megaco-web-archive@ietf.org; Wed, 04 Feb 2004 11:30:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoPug-0006sg-00 for megaco-web-archive@ietf.org; Wed, 04 Feb 2004 11:30:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPud-0007o7-CO; Wed, 04 Feb 2004 11:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPtw-0007fK-Dl for megaco@optimus.ietf.org; Wed, 04 Feb 2004 11:29:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13170 for ; Wed, 4 Feb 2004 11:29:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoPtv-0006pE-00 for megaco@ietf.org; Wed, 04 Feb 2004 11:29:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoPt4-0006i9-00 for megaco@ietf.org; Wed, 04 Feb 2004 11:28:27 -0500 Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx with smtp (Exim 4.12) id 1AoPs3-0006aq-00 for megaco@ietf.org; Wed, 04 Feb 2004 11:27:23 -0500 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1075903412; Wed Feb 4 18:28:07 2004 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id <12SLZWN4>; Wed, 4 Feb 2004 18:26:54 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F3810165F9@MAILSERVER> From: Raphael Tryster To: "'Dal Chohan'" , megaco@ietf.org Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. Date: Wed, 4 Feb 2004 18:26:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EB3B.B335C830" Sender: megaco-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.8 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,OPT_HEADER autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3EB3B.B335C830 Content-Type: text/plain Kevin Boyle answered this question recently: Call wait patterns are generally replayed after a short amount of time (10 seconds in North America). Note that this is not a repetition -- this is actually a second distinct application of the signal. There are several feature scenarios where the second signal will not be applied -- if the waiting party hangs up, or if the callee flashes, to name a couple. As for the dt package, I believe the characterization of call wait tone as timeout is erroneous, although previous attempts to fix it have been rejected. I wrote the alerting package to be local-variant unaware, leaving it to the MG to be responsible for how the signals should be applied to its terminations. Note that most localities have more than one wait tone pattern, to allow for assignable distinctive tones (similar to assigning distinctive ringing patterns to different incoming callers). I see no reason to use dt/cw if using alert/cw. The alerting package provides far more functionality than the dt package for both ringing and call waiting. Kevin _____ From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, January 08, 2004 5:39 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: call waiting signal type In draft_boyle_megaco_alerting_03.txt, the alert/cw signal has type brief, whereas the standard signal dt/cw apparently has type timeout. Is this a matter of national protocol? The description of alert/cw says "Call wait patterns do not repeat". In Israel, a call waiting signal consists of 3 short tones, repeated once a few seconds later. If it is a matter of national protocol, does this mean that a particular installation will use either alert/cw or dt/cw, but not both? Raphael Tryster -----Original Message----- From: Dal Chohan [SMTP:D.Chohan@ftel.co.uk] Sent: Wednesday, 4 February 2004 18:12 To: megaco@ietf.org Subject: [Megaco] H.248.23 Enhanced Alerting Package. The description of the "Call Waiting" signal defined in H.248.23 specifies that call waiting patterns do not repeat - Is this correct? I would have thought that for a Call Waiting service that it would would make perfect sense for the "call waiting" pattern to be repeatedly applied by the MG until it was told to stop the call waiting signal by the MGC (c.f. ringing) . It is the MGC that determines the interval within which the waiting call should be accepted and thus determines the overall duration of the call waiting pattern. Dal Chohan ------_=_NextPart_001_01C3EB3B.B335C830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] H.248.23 Enhanced Alerting Package.

Kevin Boyle answered this question recen= tly:


Call wait patterns are generally replaye= d after a short amount of time (10 seconds in North America).=A0 Note tha= t this is not a repetition -- this is actually a second distinct applicat= ion of the signal.=A0 There are several feature scenarios where the secon= d signal will not be applied -- if the waiting party hangs up, or if the = callee flashes, to name a couple.

=A0
As for the dt package, I believe the ch= aracterization of call wait tone as timeout is erroneous, although previo= us attempts to fix it have been rejected.=A0 I wrote the alerting package= to be local-variant unaware, leaving it to the MG to be responsible for = how the signals should be applied to its terminations.=A0 Note that most = localities have more than one wait tone pattern, to allow for assignable = distinctive tones (similar to assigning distinctive ringing patterns to d= ifferent incoming callers).

=A0
I see no reason to use dt/cw if using a= lert/cw.=A0 The alerting package provides far more functionality than the= dt package for both ringing and call waiting.

=A0
Kevin


=A0 _____ =A0

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

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

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

    Raphael Tryster


    -----Original Mess= age-----
    From:   Dal Chohan [SMTP:D= =2EChohan@ftel.co.uk]
    Sent:   Wednesday, 4 February 2004 18:12
    To:     megaco@ietf.org
    Subject:    &nbs= p;   [Megaco] H.248.23= Enhanced Alerting Package.

    =A0
    The description of the "Call Waiti= ng" signal defined in H.248.23 specifies that call waiting patterns = do not repeat - Is this correct?

    =A0
    I would have thought that for a Call Wa= iting service that it would would make perfect sense for the "call w= aiting" pattern to be repeatedly applied by the MG until it was told= to stop the call waiting signal by the MGC (c.f. ringing) .=A0It is the = MGC that=A0determines the interval within which the waiting call should b= e accepted and thus determines the overall duration of the=A0call waiting= pattern.

    =A0
    =A0
    =A0
    Dal Chohan

------_=_NextPart_001_01C3EB3B.B335C830-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Feb 5 04:20:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08122 for ; Thu, 5 Feb 2004 04:20:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aofg1-00052z-A2; Thu, 05 Feb 2004 04:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoffw-00051c-0S for megaco@optimus.ietf.org; Thu, 05 Feb 2004 04:19:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08117 for ; Thu, 5 Feb 2004 04:19:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoffs-00074G-00 for megaco@ietf.org; Thu, 05 Feb 2004 04:19:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aofez-0006z3-00 for megaco@ietf.org; Thu, 05 Feb 2004 04:18:58 -0500 Received: from ext-proxy-1.ftel.co.uk ([192.65.220.99]) by ietf-mx with esmtp (Exim 4.12) id 1Aofei-0006tA-00 for megaco@ietf.org; Thu, 05 Feb 2004 04:18:40 -0500 Received: from utility-1.ftel.co.uk (utility-1.ftel.co.uk [193.112.172.10]) by ext-proxy-1.ftel.co.uk (8.12.10/8.12.9/Revision:1.91/relay-in/ssl/db) with ESMTP id i159I7Xi008042; Thu, 5 Feb 2004 09:18:07 GMT Received: from DALLAPTOP (dhcp-172-16-48-64.ftel.co.uk [172.16.48.64]) by utility-1.ftel.co.uk (8.12.9+Sun/8.12.9/Revision:1.90/db) with SMTP id i159I1Nk012851; Thu, 5 Feb 2004 09:18:01 GMT Message-ID: <002a01c3ebc8$f4422cf0$403010ac@DALLAPTOP> From: "Dal Chohan" To: "Raphael Tryster" , References: <9A64A99CD3F2BD4582BE4FB63FC1F3810165F9@MAILSERVER> Subject: Re: [Megaco] H.248.23 Enhanced Alerting Package. Date: Thu, 5 Feb 2004 09:17:59 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C3EBC8.F29F7970" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C3EBC8.F29F7970 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] H.248.23 Enhanced Alerting Package.Raphael=20 Thanks for the response - but I don't see why the Call Waiting can't be = repeatedly applied just like ringing. If the Callee flashes, then the = detection of the event will stop the signal as per standard H.248 = behaviour and if the waiting party hangs up, then the MGC will instruct = the MG to stop applying the signal via a new signal descriptor. Dal Chohan. ----- Original Message -----=20 From: Raphael Tryster=20 To: 'Dal Chohan' ; megaco@ietf.org=20 Sent: Wednesday, February 04, 2004 4:26 PM Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. Kevin Boyle answered this question recently:=20 Call wait patterns are generally replayed after a short amount of time = (10 seconds in North America). Note that this is not a repetition -- = this is actually a second distinct application of the signal. There are = several feature scenarios where the second signal will not be applied -- = if the waiting party hangs up, or if the callee flashes, to name a = couple. =20 As for the dt package, I believe the characterization of call wait = tone as timeout is erroneous, although previous attempts to fix it have = been rejected. I wrote the alerting package to be local-variant = unaware, leaving it to the MG to be responsible for how the signals = should be applied to its terminations. Note that most localities have = more than one wait tone pattern, to allow for assignable distinctive = tones (similar to assigning distinctive ringing patterns to different = incoming callers). =20 I see no reason to use dt/cw if using alert/cw. The alerting package = provides far more functionality than the dt package for both ringing and = call waiting. =20 Kevin=20 _____ =20 From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, January 08, 2004 5:39 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: call waiting signal type In draft_boyle_megaco_alerting_03.txt, the alert/cw signal has type = brief, whereas the standard signal dt/cw apparently has type timeout. = Is this a matter of national protocol? The description of alert/cw says = "Call wait patterns do not repeat". In Israel, a call waiting signal = consists of 3 short tones, repeated once a few seconds later. If it is a matter of national protocol, does this mean that a = particular installation will use either alert/cw or dt/cw, but not both? Raphael Tryster=20 -----Original Message-----=20 From: Dal Chohan [SMTP:D.Chohan@ftel.co.uk]=20 Sent: Wednesday, 4 February 2004 18:12=20 To: megaco@ietf.org=20 Subject: [Megaco] H.248.23 Enhanced Alerting Package.=20 =20 The description of the "Call Waiting" signal defined in H.248.23 = specifies that call waiting patterns do not repeat - Is this correct? =20 I would have thought that for a Call Waiting service that it would = would make perfect sense for the "call waiting" pattern to be repeatedly = applied by the MG until it was told to stop the call waiting signal by = the MGC (c.f. ringing) . It is the MGC that determines the interval = within which the waiting call should be accepted and thus determines the = overall duration of the call waiting pattern. =20 =20 =20 Dal Chohan ------=_NextPart_000_0027_01C3EBC8.F29F7970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] H.248.23 Enhanced Alerting = Package.
Raphael =
 
Thanks for the response = -  but I don't see why the Call Waiting can't = be repeatedly=20 applied just like ringing. If the Callee = flashes, then=20 the detection of the event will stop the signal as per standard H.248 = behaviour=20 and if the waiting party hangs up, then the MGC will instruct the MG to = stop=20 applying the signal via a new signal descriptor.
 
Dal Chohan.
----- Original Message -----
From:=20 Raphael=20 Tryster
Sent: Wednesday, February 04, = 2004 4:26=20 PM
Subject: RE: [Megaco] H.248.23 = Enhanced=20 Alerting Package.

Kevin Boyle answered this question = recently:=20


Call wait patterns are generally = replayed after a=20 short amount of time (10 seconds in North America).  Note that = this is=20 not a repetition -- this is actually a second distinct application of = the=20 signal.  There are several feature scenarios where the second = signal will=20 not be applied -- if the waiting party hangs up, or if the callee = flashes, to=20 name a couple.


As for = the dt package,=20 I believe the characterization of call wait tone as timeout is = erroneous,=20 although previous attempts to fix it have been rejected.  I wrote = the=20 alerting package to be local-variant unaware, leaving it to the MG to = be=20 responsible for how the signals should be applied to its = terminations. =20 Note that most localities have more than one wait tone pattern, to = allow for=20 assignable distinctive tones (similar to assigning distinctive ringing = patterns to different incoming callers).


I see no = reason to use=20 dt/cw if using alert/cw.  The alerting package provides far more=20 functionality than the dt package for both ringing and call=20 waiting.


Kevin


  _____  

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

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

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

    Raphael Tryster=20


    -----Original=20 Message-----
    From:   Dal=20 Chohan [SMTP:D.Chohan@ftel.co.uk]
    Sent:   Wednesday, 4=20 February 2004 18:12
    To:     megaco@ietf.org
    Subject:        = [Megaco] H.248.23 Enhanced Alerting = Package.


    The = description of=20 the "Call Waiting" signal defined in H.248.23 specifies that call = waiting=20 patterns do not repeat - Is this correct?


    I = would have thought=20 that for a Call Waiting service that it would would make perfect = sense for=20 the "call waiting" pattern to be repeatedly applied by the MG until = it was=20 told to stop the call waiting signal by the MGC (c.f. ringing) = . It is=20 the MGC that determines the interval within which the waiting = call=20 should be accepted and thus determines the overall duration of = the call=20 waiting pattern.


      =
     
    Dal=20 Chohan

------=_NextPart_000_0027_01C3EBC8.F29F7970-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Feb 5 04:22:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08219 for ; Thu, 5 Feb 2004 04:22:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aofhs-0005DS-BG for megaco-archive@odin.ietf.org; Thu, 05 Feb 2004 04:21:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i159Lu3X020049 for megaco-archive@odin.ietf.org; Thu, 5 Feb 2004 04:21:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aofhr-0005DI-JI for megaco-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 04:21:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08189 for ; Thu, 5 Feb 2004 04:21:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aofho-0007HK-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 04:21:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aofgr-0007AN-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 04:20:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aofg0-00074f-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 04:20:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aofg1-00052z-A2; Thu, 05 Feb 2004 04:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoffw-00051c-0S for megaco@optimus.ietf.org; Thu, 05 Feb 2004 04:19:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08117 for ; Thu, 5 Feb 2004 04:19:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoffs-00074G-00 for megaco@ietf.org; Thu, 05 Feb 2004 04:19:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aofez-0006z3-00 for megaco@ietf.org; Thu, 05 Feb 2004 04:18:58 -0500 Received: from ext-proxy-1.ftel.co.uk ([192.65.220.99]) by ietf-mx with esmtp (Exim 4.12) id 1Aofei-0006tA-00 for megaco@ietf.org; Thu, 05 Feb 2004 04:18:40 -0500 Received: from utility-1.ftel.co.uk (utility-1.ftel.co.uk [193.112.172.10]) by ext-proxy-1.ftel.co.uk (8.12.10/8.12.9/Revision:1.91/relay-in/ssl/db) with ESMTP id i159I7Xi008042; Thu, 5 Feb 2004 09:18:07 GMT Received: from DALLAPTOP (dhcp-172-16-48-64.ftel.co.uk [172.16.48.64]) by utility-1.ftel.co.uk (8.12.9+Sun/8.12.9/Revision:1.90/db) with SMTP id i159I1Nk012851; Thu, 5 Feb 2004 09:18:01 GMT Message-ID: <002a01c3ebc8$f4422cf0$403010ac@DALLAPTOP> From: "Dal Chohan" To: "Raphael Tryster" , References: <9A64A99CD3F2BD4582BE4FB63FC1F3810165F9@MAILSERVER> Subject: Re: [Megaco] H.248.23 Enhanced Alerting Package. Date: Thu, 5 Feb 2004 09:17:59 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C3EBC8.F29F7970" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C3EBC8.F29F7970 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] H.248.23 Enhanced Alerting Package.Raphael=20 Thanks for the response - but I don't see why the Call Waiting can't be = repeatedly applied just like ringing. If the Callee flashes, then the = detection of the event will stop the signal as per standard H.248 = behaviour and if the waiting party hangs up, then the MGC will instruct = the MG to stop applying the signal via a new signal descriptor. Dal Chohan. ----- Original Message -----=20 From: Raphael Tryster=20 To: 'Dal Chohan' ; megaco@ietf.org=20 Sent: Wednesday, February 04, 2004 4:26 PM Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. Kevin Boyle answered this question recently:=20 Call wait patterns are generally replayed after a short amount of time = (10 seconds in North America). Note that this is not a repetition -- = this is actually a second distinct application of the signal. There are = several feature scenarios where the second signal will not be applied -- = if the waiting party hangs up, or if the callee flashes, to name a = couple. =20 As for the dt package, I believe the characterization of call wait = tone as timeout is erroneous, although previous attempts to fix it have = been rejected. I wrote the alerting package to be local-variant = unaware, leaving it to the MG to be responsible for how the signals = should be applied to its terminations. Note that most localities have = more than one wait tone pattern, to allow for assignable distinctive = tones (similar to assigning distinctive ringing patterns to different = incoming callers). =20 I see no reason to use dt/cw if using alert/cw. The alerting package = provides far more functionality than the dt package for both ringing and = call waiting. =20 Kevin=20 _____ =20 From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, January 08, 2004 5:39 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: call waiting signal type In draft_boyle_megaco_alerting_03.txt, the alert/cw signal has type = brief, whereas the standard signal dt/cw apparently has type timeout. = Is this a matter of national protocol? The description of alert/cw says = "Call wait patterns do not repeat". In Israel, a call waiting signal = consists of 3 short tones, repeated once a few seconds later. If it is a matter of national protocol, does this mean that a = particular installation will use either alert/cw or dt/cw, but not both? Raphael Tryster=20 -----Original Message-----=20 From: Dal Chohan [SMTP:D.Chohan@ftel.co.uk]=20 Sent: Wednesday, 4 February 2004 18:12=20 To: megaco@ietf.org=20 Subject: [Megaco] H.248.23 Enhanced Alerting Package.=20 =20 The description of the "Call Waiting" signal defined in H.248.23 = specifies that call waiting patterns do not repeat - Is this correct? =20 I would have thought that for a Call Waiting service that it would = would make perfect sense for the "call waiting" pattern to be repeatedly = applied by the MG until it was told to stop the call waiting signal by = the MGC (c.f. ringing) . It is the MGC that determines the interval = within which the waiting call should be accepted and thus determines the = overall duration of the call waiting pattern. =20 =20 =20 Dal Chohan ------=_NextPart_000_0027_01C3EBC8.F29F7970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] H.248.23 Enhanced Alerting = Package.
Raphael =
 
Thanks for the response = -  but I don't see why the Call Waiting can't = be repeatedly=20 applied just like ringing. If the Callee = flashes, then=20 the detection of the event will stop the signal as per standard H.248 = behaviour=20 and if the waiting party hangs up, then the MGC will instruct the MG to = stop=20 applying the signal via a new signal descriptor.
 
Dal Chohan.
----- Original Message -----
From:=20 Raphael=20 Tryster
Sent: Wednesday, February 04, = 2004 4:26=20 PM
Subject: RE: [Megaco] H.248.23 = Enhanced=20 Alerting Package.

Kevin Boyle answered this question = recently:=20


Call wait patterns are generally = replayed after a=20 short amount of time (10 seconds in North America).  Note that = this is=20 not a repetition -- this is actually a second distinct application of = the=20 signal.  There are several feature scenarios where the second = signal will=20 not be applied -- if the waiting party hangs up, or if the callee = flashes, to=20 name a couple.


As for = the dt package,=20 I believe the characterization of call wait tone as timeout is = erroneous,=20 although previous attempts to fix it have been rejected.  I wrote = the=20 alerting package to be local-variant unaware, leaving it to the MG to = be=20 responsible for how the signals should be applied to its = terminations. =20 Note that most localities have more than one wait tone pattern, to = allow for=20 assignable distinctive tones (similar to assigning distinctive ringing = patterns to different incoming callers).


I see no = reason to use=20 dt/cw if using alert/cw.  The alerting package provides far more=20 functionality than the dt package for both ringing and call=20 waiting.


Kevin


  _____  

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

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

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

    Raphael Tryster=20


    -----Original=20 Message-----
    From:   Dal=20 Chohan [SMTP:D.Chohan@ftel.co.uk]
    Sent:   Wednesday, 4=20 February 2004 18:12
    To:     megaco@ietf.org
    Subject:        = [Megaco] H.248.23 Enhanced Alerting = Package.


    The = description of=20 the "Call Waiting" signal defined in H.248.23 specifies that call = waiting=20 patterns do not repeat - Is this correct?


    I = would have thought=20 that for a Call Waiting service that it would would make perfect = sense for=20 the "call waiting" pattern to be repeatedly applied by the MG until = it was=20 told to stop the call waiting signal by the MGC (c.f. ringing) = . It is=20 the MGC that determines the interval within which the waiting = call=20 should be accepted and thus determines the overall duration of = the call=20 waiting pattern.


      =
     
    Dal=20 Chohan

------=_NextPart_000_0027_01C3EBC8.F29F7970-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Feb 5 07:30:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13239 for ; Thu, 5 Feb 2004 07:30:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoidv-0006ts-GE; Thu, 05 Feb 2004 07:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoidm-0006sN-QK for megaco@optimus.ietf.org; Thu, 05 Feb 2004 07:29:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13230 for ; Thu, 5 Feb 2004 07:29:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoidm-0001D6-00 for megaco@ietf.org; Thu, 05 Feb 2004 07:29:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoicq-00017p-00 for megaco@ietf.org; Thu, 05 Feb 2004 07:28:57 -0500 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1Aoic4-0000yA-00 for megaco@ietf.org; Thu, 05 Feb 2004 07:28:09 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i15CRbD12134 for ; Thu, 5 Feb 2004 07:27:37 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3D1SZL>; Thu, 5 Feb 2004 07:27:38 -0500 Message-ID: From: "Kevin Boyle" To: Dal Chohan , Raphael Tryster , megaco@ietf.org Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. Date: Thu, 5 Feb 2004 07:27:37 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , So, you would rather need two messages to play the tone once and one message to play the tone twice? That is incredibly non-intuitive. Call wait generally has a very long interval between occurrences, and is generally limited to two occurrences. Ringing, on the other hand, does not have a long interval (as compared to the length of the audible signal) and is always applied indefinitely. Further, the two examples I gave are just that -- examples. If you read the call waiting specifications, certain feature interactions require only a single application of the call wait tone as well. These all lead to the conclusion that I stated earlier: Call wait is a discrete signal applied multiple times. Kevin _____ From: Dal Chohan [mailto:D.Chohan@ftel.co.uk] Sent: Thursday, February 05, 2004 4:18 AM To: Raphael Tryster; megaco@ietf.org Subject: Re: [Megaco] H.248.23 Enhanced Alerting Package. Raphael Thanks for the response - but I don't see why the Call Waiting can't be repeatedly applied just like ringing. If the Callee flashes, then the detection of the event will stop the signal as per standard H.248 behaviour and if the waiting party hangs up, then the MGC will instruct the MG to stop applying the signal via a new signal descriptor. Dal Chohan. ----- Original Message ----- From: Raphael Tryster To: 'Dal Chohan' ; megaco@ietf.org Sent: Wednesday, February 04, 2004 4:26 PM Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. Kevin Boyle answered this question recently: Call wait patterns are generally replayed after a short amount of time (10 seconds in North America). Note that this is not a repetition -- this is actually a second distinct application of the signal. There are several feature scenarios where the second signal will not be applied -- if the waiting party hangs up, or if the callee flashes, to name a couple. As for the dt package, I believe the characterization of call wait tone as timeout is erroneous, although previous attempts to fix it have been rejected. I wrote the alerting package to be local-variant unaware, leaving it to the MG to be responsible for how the signals should be applied to its terminations. Note that most localities have more than one wait tone pattern, to allow for assignable distinctive tones (similar to assigning distinctive ringing patterns to different incoming callers). I see no reason to use dt/cw if using alert/cw. The alerting package provides far more functionality than the dt package for both ringing and call waiting. Kevin _____ From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, January 08, 2004 5:39 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: call waiting signal type In draft_boyle_megaco_alerting_03.txt, the alert/cw signal has type brief, whereas the standard signal dt/cw apparently has type timeout. Is this a matter of national protocol? The description of alert/cw says "Call wait patterns do not repeat". In Israel, a call waiting signal consists of 3 short tones, repeated once a few seconds later. If it is a matter of national protocol, does this mean that a particular installation will use either alert/cw or dt/cw, but not both? Raphael Tryster BM__MailData-----Original Message----- From: Dal Chohan [SMTP:D.Chohan@ftel.co.uk] Sent: Wednesday, 4 February 2004 18:12 To: megaco@ietf.org Subject: [Megaco] H.248.23 Enhanced Alerting Package. The description of the "Call Waiting" signal defined in H.248.23 specifies that call waiting patterns do not repeat - Is this correct? I would have thought that for a Call Waiting service that it would would make perfect sense for the "call waiting" pattern to be repeatedly applied by the MG until it was told to stop the call waiting signal by the MGC (c.f. ringing) . It is the MGC that determines the interval within which the waiting call should be accepted and thus determines the overall duration of the call waiting pattern. Dal Chohan _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Feb 5 07:32:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13298 for ; Thu, 5 Feb 2004 07:32:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoifi-00074S-MB for megaco-archive@odin.ietf.org; Thu, 05 Feb 2004 07:31:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15CVs03027174 for megaco-archive@odin.ietf.org; Thu, 5 Feb 2004 07:31:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoifi-00074B-HV for megaco-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 07:31:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13273 for ; Thu, 5 Feb 2004 07:31:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoifh-0001PX-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 07:31:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoiel-0001JE-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 07:30:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aoidy-0001EH-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 07:30:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoidv-0006ts-GE; Thu, 05 Feb 2004 07:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoidm-0006sN-QK for megaco@optimus.ietf.org; Thu, 05 Feb 2004 07:29:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13230 for ; Thu, 5 Feb 2004 07:29:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoidm-0001D6-00 for megaco@ietf.org; Thu, 05 Feb 2004 07:29:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoicq-00017p-00 for megaco@ietf.org; Thu, 05 Feb 2004 07:28:57 -0500 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1Aoic4-0000yA-00 for megaco@ietf.org; Thu, 05 Feb 2004 07:28:09 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i15CRbD12134 for ; Thu, 5 Feb 2004 07:27:37 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3D1SZL>; Thu, 5 Feb 2004 07:27:38 -0500 Message-ID: From: "Kevin Boyle" To: Dal Chohan , Raphael Tryster , megaco@ietf.org Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. Date: Thu, 5 Feb 2004 07:27:37 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 So, you would rather need two messages to play the tone once and one message to play the tone twice? That is incredibly non-intuitive. Call wait generally has a very long interval between occurrences, and is generally limited to two occurrences. Ringing, on the other hand, does not have a long interval (as compared to the length of the audible signal) and is always applied indefinitely. Further, the two examples I gave are just that -- examples. If you read the call waiting specifications, certain feature interactions require only a single application of the call wait tone as well. These all lead to the conclusion that I stated earlier: Call wait is a discrete signal applied multiple times. Kevin _____ From: Dal Chohan [mailto:D.Chohan@ftel.co.uk] Sent: Thursday, February 05, 2004 4:18 AM To: Raphael Tryster; megaco@ietf.org Subject: Re: [Megaco] H.248.23 Enhanced Alerting Package. Raphael Thanks for the response - but I don't see why the Call Waiting can't be repeatedly applied just like ringing. If the Callee flashes, then the detection of the event will stop the signal as per standard H.248 behaviour and if the waiting party hangs up, then the MGC will instruct the MG to stop applying the signal via a new signal descriptor. Dal Chohan. ----- Original Message ----- From: Raphael Tryster To: 'Dal Chohan' ; megaco@ietf.org Sent: Wednesday, February 04, 2004 4:26 PM Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. Kevin Boyle answered this question recently: Call wait patterns are generally replayed after a short amount of time (10 seconds in North America). Note that this is not a repetition -- this is actually a second distinct application of the signal. There are several feature scenarios where the second signal will not be applied -- if the waiting party hangs up, or if the callee flashes, to name a couple. As for the dt package, I believe the characterization of call wait tone as timeout is erroneous, although previous attempts to fix it have been rejected. I wrote the alerting package to be local-variant unaware, leaving it to the MG to be responsible for how the signals should be applied to its terminations. Note that most localities have more than one wait tone pattern, to allow for assignable distinctive tones (similar to assigning distinctive ringing patterns to different incoming callers). I see no reason to use dt/cw if using alert/cw. The alerting package provides far more functionality than the dt package for both ringing and call waiting. Kevin _____ From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, January 08, 2004 5:39 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: call waiting signal type In draft_boyle_megaco_alerting_03.txt, the alert/cw signal has type brief, whereas the standard signal dt/cw apparently has type timeout. Is this a matter of national protocol? The description of alert/cw says "Call wait patterns do not repeat". In Israel, a call waiting signal consists of 3 short tones, repeated once a few seconds later. If it is a matter of national protocol, does this mean that a particular installation will use either alert/cw or dt/cw, but not both? Raphael Tryster BM__MailData-----Original Message----- From: Dal Chohan [SMTP:D.Chohan@ftel.co.uk] Sent: Wednesday, 4 February 2004 18:12 To: megaco@ietf.org Subject: [Megaco] H.248.23 Enhanced Alerting Package. The description of the "Call Waiting" signal defined in H.248.23 specifies that call waiting patterns do not repeat - Is this correct? I would have thought that for a Call Waiting service that it would would make perfect sense for the "call waiting" pattern to be repeatedly applied by the MG until it was told to stop the call waiting signal by the MGC (c.f. ringing) . It is the MGC that determines the interval within which the waiting call should be accepted and thus determines the overall duration of the call waiting pattern. Dal Chohan _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Feb 5 09:02:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15446 for ; Thu, 5 Feb 2004 09:02:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aok4v-0004TG-PI; Thu, 05 Feb 2004 09:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aok3y-0004PB-2G for megaco@optimus.ietf.org; Thu, 05 Feb 2004 09:01:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15432 for ; Thu, 5 Feb 2004 09:01:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aok3w-0001Qc-00 for megaco@ietf.org; Thu, 05 Feb 2004 09:01:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aok32-0001Lq-00 for megaco@ietf.org; Thu, 05 Feb 2004 09:00:06 -0500 Received: from ext-proxy-2.ftel.co.uk ([192.65.220.98]) by ietf-mx with esmtp (Exim 4.12) id 1Aok2U-0001FK-00 for megaco@ietf.org; Thu, 05 Feb 2004 08:59:30 -0500 Received: from utility-2.ftel.co.uk (utility-2.ftel.co.uk [193.112.172.11]) by ext-proxy-2.ftel.co.uk (8.12.10/8.12.9/Revision:1.91/relay-in/ssl/db) with ESMTP id i15DwtMu002172; Thu, 5 Feb 2004 13:58:55 GMT Received: from DALLAPTOP (dhcp-172-16-48-64.ftel.co.uk [172.16.48.64]) by utility-2.ftel.co.uk (8.12.9+Sun/8.12.9/Revision:1.90/db) with SMTP id i15DwjEp001354; Thu, 5 Feb 2004 13:58:45 GMT Message-ID: <00de01c3ebf0$2e1c7080$403010ac@DALLAPTOP> From: "Dal Chohan" To: "Kevin Boyle" , "Raphael Tryster" , References: Subject: Re: [Megaco] H.248.23 Enhanced Alerting Package. Date: Thu, 5 Feb 2004 13:58:43 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DB_01C3EBF0.2A65F830" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_00DB_01C3EBF0.2A65F830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] H.248.23 Enhanced Alerting Package.Sorry, but I think you = have missed the point that I am making - H.248.23 states that Call Wait = patterns do not repeat and to me this means that you cannot apply the = Call Waiting tone repeatedly and I see no reason for such a restriction. I can think of an implementation of Call Waiting for example in the UK = where it would be advantageous for the Call Waiting tone to be = repeatedly applied by the MG, rather than defining the distinct number = of cycles of Call Waiting that should be applied at the MG as determined = by the pattern parameter. This approach minimises the configuration in = the MG and lets the MGC determine the number of cycles of Call Waiting = that should be applied, which it does know anyway since it is running an = overall timer within which the waiting call should be accepted. Some additional comments in-line. Dal Chohan. ----- Original Message -----=20 From: Kevin Boyle=20 To: Dal Chohan ; Raphael Tryster ; megaco@ietf.org=20 Sent: Thursday, February 05, 2004 12:27 PM Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. So, you would rather need two messages to play the tone once and one = message to play the tone twice? That is incredibly non-intuitive. [DC] I didn't say that - Isn't that the purpose of the pattern = parameter to define the duration of the Call Waiting tone, so for = example pattern 1 could mean apply the Call Waiting tone indefinitely = and pattern 2 could mean apply one pulse of Call Waiting tone. Call wait generally has a very long interval between occurrences, and = is generally limited to two occurrences. =20 [DC] The two ocurrences may true for the US market, but this isn't the = case for the UK. Ringing, on the other hand, does not have a long interval (as compared = to the length of the audible signal) and is always applied indefinitely. = Further, the two examples I gave are just that -- examples. If you = read the call waiting specifications, certain feature interactions = require only a single application of the call wait tone as well. These = all lead to the conclusion that I stated earlier: Call wait is a = discrete signal applied multiple times. [DC] I have no problem with treating the signal as a pulsed signal = that is applied multiple times, but the current text states that = "multiple" cannnot be of an infinite value and I think the UK Call = Waiting service operation could benefit from this latter mode of = working. Kevin -------------------------------------------------------------------------= --- From: Dal Chohan [mailto:D.Chohan@ftel.co.uk]=20 Sent: Thursday, February 05, 2004 4:18 AM To: Raphael Tryster; megaco@ietf.org Subject: Re: [Megaco] H.248.23 Enhanced Alerting Package. Raphael=20 Thanks for the response - but I don't see why the Call Waiting = can't be repeatedly applied just like ringing. If the Callee flashes, = then the detection of the event will stop the signal as per standard = H.248 behaviour and if the waiting party hangs up, then the MGC will = instruct the MG to stop applying the signal via a new signal descriptor. Dal Chohan. ----- Original Message -----=20 From: Raphael Tryster=20 To: 'Dal Chohan' ; megaco@ietf.org=20 Sent: Wednesday, February 04, 2004 4:26 PM Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. Kevin Boyle answered this question recently:=20 Call wait patterns are generally replayed after a short amount of = time (10 seconds in North America). Note that this is not a repetition = -- this is actually a second distinct application of the signal. There = are several feature scenarios where the second signal will not be = applied -- if the waiting party hangs up, or if the callee flashes, to = name a couple. As for the dt package, I believe the characterization of call wait = tone as timeout is erroneous, although previous attempts to fix it have = been rejected. I wrote the alerting package to be local-variant = unaware, leaving it to the MG to be responsible for how the signals = should be applied to its terminations. Note that most localities have = more than one wait tone pattern, to allow for assignable distinctive = tones (similar to assigning distinctive ringing patterns to different = incoming callers). I see no reason to use dt/cw if using alert/cw. The alerting = package provides far more functionality than the dt package for both = ringing and call waiting. Kevin=20 _____ =20 From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, January 08, 2004 5:39 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: call waiting signal type In draft_boyle_megaco_alerting_03.txt, the alert/cw signal has = type brief, whereas the standard signal dt/cw apparently has type = timeout. Is this a matter of national protocol? The description of = alert/cw says "Call wait patterns do not repeat". In Israel, a call = waiting signal consists of 3 short tones, repeated once a few seconds = later. If it is a matter of national protocol, does this mean that a = particular installation will use either alert/cw or dt/cw, but not both? Raphael Tryster=20 -----Original Message-----=20 From: Dal Chohan [SMTP:D.Chohan@ftel.co.uk]=20 Sent: Wednesday, 4 February 2004 18:12=20 To: megaco@ietf.org=20 Subject: [Megaco] H.248.23 Enhanced Alerting Package.=20 The description of the "Call Waiting" signal defined in H.248.23 = specifies that call waiting patterns do not repeat - Is this correct? I would have thought that for a Call Waiting service that it = would would make perfect sense for the "call waiting" pattern to be = repeatedly applied by the MG until it was told to stop the call waiting = signal by the MGC (c.f. ringing) . It is the MGC that determines the = interval within which the waiting call should be accepted and thus = determines the overall duration of the call waiting pattern. =20 =20 Dal Chohan ------=_NextPart_000_00DB_01C3EBF0.2A65F830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] H.248.23 Enhanced Alerting = Package.
Sorry, but I think you have missed the = point that I=20 am making - H.248.23 states that Call Wait patterns do not repeat and to = me this=20 means that you cannot apply the Call Waiting tone repeatedly and I = see no=20 reason for such a restriction.
 
I can think of an implementation of = Call Waiting=20 for example in the UK where it would be advantageous for the Call = Waiting tone=20 to be repeatedly applied by the MG, rather than defining the distinct = number of=20 cycles of Call Waiting that should be applied at the MG as determined by = the=20 pattern parameter. This approach minimises the configuration in the MG = and lets=20 the MGC determine the number of cycles of Call Waiting that should be = applied,=20 which it does know anyway since it is running an overall timer within = which the=20 waiting call should be accepted.
 
Some additional comments = in-line.
 
 
Dal Chohan.
 
 
 
----- Original Message -----
From:=20 Kevin Boyle
To: Dal Chohan ; Raphael Tryster ; megaco@ietf.org
Sent: Thursday, February 05, = 2004 12:27=20 PM
Subject: RE: [Megaco] H.248.23 = Enhanced=20 Alerting Package.

So, you would rather need two messages to play the tone once = and one=20 message to play the tone twice?  That is incredibly=20 non-intuitive.
 
[DC] I didn't say that - Isn't that the purpose of the = pattern=20 parameter to define the duration of the Call Waiting tone, so for = example=20 pattern 1 could mean apply the Call Waiting tone indefinitely and = pattern 2=20 could mean apply one pulse of Call Waiting tone.
 
 
Call wait generally has a very long interval between = occurrences, and=20 is generally limited to two occurrences. 
 
[DC] The two ocurrences may true for the US market, but = this isn't=20 the case for the UK.
 
Ringing, on the other hand, does not have a long interval (as = compared=20 to the length of the audible signal) and is always applied = indefinitely. =20 Further, the two examples I gave are just that -- examples.  If = you read=20 the call waiting specifications, certain feature interactions require = only a=20 single application of the call wait tone as well.  These all lead = to the=20 conclusion that I stated earlier: Call wait is a discrete signal = applied=20 multiple times.
 
[DC] I have no problem with treating the signal as a pulsed = signal that=20 is applied multiple times, but the current text states that "multiple" = cannnot=20 be of an infinite value and I think the UK Call Waiting service = operation=20 could benefit from this latter mode of working.
 
Kevin

From: Dal Chohan=20 [mailto:D.Chohan@ftel.co.uk]
Sent: Thursday, February 05, = 2004=20 4:18 AM
To: Raphael Tryster; = megaco@ietf.org
Subject:=20 Re: [Megaco] H.248.23 Enhanced Alerting = Package.

Raphael =
 
Thanks for the response = -  but I don't see why the Call Waiting = can't be=20 repeatedly applied just like ringing. If = the Callee=20 flashes, then the detection of the event will stop the signal as per = standard H.248 behaviour and if the waiting party hangs up, then the = MGC=20 will instruct the MG to stop applying the signal via a new signal=20 descriptor.
 
Dal Chohan.
----- Original Message ----- =
From:=20 Raphael=20 Tryster
To: 'Dal Chohan' ; megaco@ietf.org=20
Sent: Wednesday, February = 04, 2004=20 4:26 PM
Subject: RE: [Megaco] = H.248.23=20 Enhanced Alerting Package.

Kevin Boyle answered this question=20 recently:


Call wait patterns are generally = replayed after=20 a short amount of time (10 seconds in North America).  Note = that this=20 is not a repetition -- this is actually a second distinct = application of=20 the signal.  There are several feature scenarios where the = second=20 signal will not be applied -- if the waiting party hangs up, or if = the=20 callee flashes, to name a couple.


As = for the dt=20 package, I believe the characterization of call wait tone as = timeout is=20 erroneous, although previous attempts to fix it have been = rejected. =20 I wrote the alerting package to be local-variant unaware, leaving = it to=20 the MG to be responsible for how the signals should be applied to = its=20 terminations.  Note that most localities have more than one = wait tone=20 pattern, to allow for assignable distinctive tones (similar to = assigning=20 distinctive ringing patterns to different incoming = callers).


I see = no reason to=20 use dt/cw if using alert/cw.  The alerting package provides = far more=20 functionality than the dt package for both ringing and call=20 waiting.


Kevin=20


  _____ =  

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

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

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

    Raphael Tryster=20


    -----Original = Message-----
    From:  =20 Dal Chohan [SMTP:D.Chohan@ftel.co.uk]
    Sent:   Wednesday, 4=20 February 2004 18:12
    To:     megaco@ietf.org
    Subject:       =20 [Megaco] H.248.23 Enhanced Alerting=20 Package.


    The = description=20 of the "Call Waiting" signal defined in H.248.23 specifies that = call=20 waiting patterns do not repeat - Is this correct?


    I would have thought that for a Call Waiting service = that it=20 would would make perfect sense for the "call waiting" pattern to = be=20 repeatedly applied by the MG until it was told to stop the call = waiting=20 signal by the MGC (c.f. ringing) . It is the MGC=20 that determines the interval within which the waiting call = should=20 be accepted and thus determines the overall duration of = the call=20 waiting pattern.


     
     
    Dal=20 = Chohan

<= /HTML> ------=_NextPart_000_00DB_01C3EBF0.2A65F830-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Feb 5 09:04:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15513 for ; Thu, 5 Feb 2004 09:04:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aok6r-0004dM-SY for megaco-archive@odin.ietf.org; Thu, 05 Feb 2004 09:04:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15E41bp017808 for megaco-archive@odin.ietf.org; Thu, 5 Feb 2004 09:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aok6r-0004d9-OJ for megaco-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 09:04:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15491 for ; Thu, 5 Feb 2004 09:03:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aok6q-0001hu-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 09:04:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aok5r-0001bg-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 09:03:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aok4v-0001WE-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 09:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aok4v-0004TG-PI; Thu, 05 Feb 2004 09:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aok3y-0004PB-2G for megaco@optimus.ietf.org; Thu, 05 Feb 2004 09:01:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15432 for ; Thu, 5 Feb 2004 09:01:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aok3w-0001Qc-00 for megaco@ietf.org; Thu, 05 Feb 2004 09:01:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aok32-0001Lq-00 for megaco@ietf.org; Thu, 05 Feb 2004 09:00:06 -0500 Received: from ext-proxy-2.ftel.co.uk ([192.65.220.98]) by ietf-mx with esmtp (Exim 4.12) id 1Aok2U-0001FK-00 for megaco@ietf.org; Thu, 05 Feb 2004 08:59:30 -0500 Received: from utility-2.ftel.co.uk (utility-2.ftel.co.uk [193.112.172.11]) by ext-proxy-2.ftel.co.uk (8.12.10/8.12.9/Revision:1.91/relay-in/ssl/db) with ESMTP id i15DwtMu002172; Thu, 5 Feb 2004 13:58:55 GMT Received: from DALLAPTOP (dhcp-172-16-48-64.ftel.co.uk [172.16.48.64]) by utility-2.ftel.co.uk (8.12.9+Sun/8.12.9/Revision:1.90/db) with SMTP id i15DwjEp001354; Thu, 5 Feb 2004 13:58:45 GMT Message-ID: <00de01c3ebf0$2e1c7080$403010ac@DALLAPTOP> From: "Dal Chohan" To: "Kevin Boyle" , "Raphael Tryster" , References: Subject: Re: [Megaco] H.248.23 Enhanced Alerting Package. Date: Thu, 5 Feb 2004 13:58:43 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DB_01C3EBF0.2A65F830" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_00DB_01C3EBF0.2A65F830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] H.248.23 Enhanced Alerting Package.Sorry, but I think you = have missed the point that I am making - H.248.23 states that Call Wait = patterns do not repeat and to me this means that you cannot apply the = Call Waiting tone repeatedly and I see no reason for such a restriction. I can think of an implementation of Call Waiting for example in the UK = where it would be advantageous for the Call Waiting tone to be = repeatedly applied by the MG, rather than defining the distinct number = of cycles of Call Waiting that should be applied at the MG as determined = by the pattern parameter. This approach minimises the configuration in = the MG and lets the MGC determine the number of cycles of Call Waiting = that should be applied, which it does know anyway since it is running an = overall timer within which the waiting call should be accepted. Some additional comments in-line. Dal Chohan. ----- Original Message -----=20 From: Kevin Boyle=20 To: Dal Chohan ; Raphael Tryster ; megaco@ietf.org=20 Sent: Thursday, February 05, 2004 12:27 PM Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. So, you would rather need two messages to play the tone once and one = message to play the tone twice? That is incredibly non-intuitive. [DC] I didn't say that - Isn't that the purpose of the pattern = parameter to define the duration of the Call Waiting tone, so for = example pattern 1 could mean apply the Call Waiting tone indefinitely = and pattern 2 could mean apply one pulse of Call Waiting tone. Call wait generally has a very long interval between occurrences, and = is generally limited to two occurrences. =20 [DC] The two ocurrences may true for the US market, but this isn't the = case for the UK. Ringing, on the other hand, does not have a long interval (as compared = to the length of the audible signal) and is always applied indefinitely. = Further, the two examples I gave are just that -- examples. If you = read the call waiting specifications, certain feature interactions = require only a single application of the call wait tone as well. These = all lead to the conclusion that I stated earlier: Call wait is a = discrete signal applied multiple times. [DC] I have no problem with treating the signal as a pulsed signal = that is applied multiple times, but the current text states that = "multiple" cannnot be of an infinite value and I think the UK Call = Waiting service operation could benefit from this latter mode of = working. Kevin -------------------------------------------------------------------------= --- From: Dal Chohan [mailto:D.Chohan@ftel.co.uk]=20 Sent: Thursday, February 05, 2004 4:18 AM To: Raphael Tryster; megaco@ietf.org Subject: Re: [Megaco] H.248.23 Enhanced Alerting Package. Raphael=20 Thanks for the response - but I don't see why the Call Waiting = can't be repeatedly applied just like ringing. If the Callee flashes, = then the detection of the event will stop the signal as per standard = H.248 behaviour and if the waiting party hangs up, then the MGC will = instruct the MG to stop applying the signal via a new signal descriptor. Dal Chohan. ----- Original Message -----=20 From: Raphael Tryster=20 To: 'Dal Chohan' ; megaco@ietf.org=20 Sent: Wednesday, February 04, 2004 4:26 PM Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. Kevin Boyle answered this question recently:=20 Call wait patterns are generally replayed after a short amount of = time (10 seconds in North America). Note that this is not a repetition = -- this is actually a second distinct application of the signal. There = are several feature scenarios where the second signal will not be = applied -- if the waiting party hangs up, or if the callee flashes, to = name a couple. As for the dt package, I believe the characterization of call wait = tone as timeout is erroneous, although previous attempts to fix it have = been rejected. I wrote the alerting package to be local-variant = unaware, leaving it to the MG to be responsible for how the signals = should be applied to its terminations. Note that most localities have = more than one wait tone pattern, to allow for assignable distinctive = tones (similar to assigning distinctive ringing patterns to different = incoming callers). I see no reason to use dt/cw if using alert/cw. The alerting = package provides far more functionality than the dt package for both = ringing and call waiting. Kevin=20 _____ =20 From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, January 08, 2004 5:39 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: call waiting signal type In draft_boyle_megaco_alerting_03.txt, the alert/cw signal has = type brief, whereas the standard signal dt/cw apparently has type = timeout. Is this a matter of national protocol? The description of = alert/cw says "Call wait patterns do not repeat". In Israel, a call = waiting signal consists of 3 short tones, repeated once a few seconds = later. If it is a matter of national protocol, does this mean that a = particular installation will use either alert/cw or dt/cw, but not both? Raphael Tryster=20 -----Original Message-----=20 From: Dal Chohan [SMTP:D.Chohan@ftel.co.uk]=20 Sent: Wednesday, 4 February 2004 18:12=20 To: megaco@ietf.org=20 Subject: [Megaco] H.248.23 Enhanced Alerting Package.=20 The description of the "Call Waiting" signal defined in H.248.23 = specifies that call waiting patterns do not repeat - Is this correct? I would have thought that for a Call Waiting service that it = would would make perfect sense for the "call waiting" pattern to be = repeatedly applied by the MG until it was told to stop the call waiting = signal by the MGC (c.f. ringing) . It is the MGC that determines the = interval within which the waiting call should be accepted and thus = determines the overall duration of the call waiting pattern. =20 =20 Dal Chohan ------=_NextPart_000_00DB_01C3EBF0.2A65F830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] H.248.23 Enhanced Alerting = Package.
Sorry, but I think you have missed the = point that I=20 am making - H.248.23 states that Call Wait patterns do not repeat and to = me this=20 means that you cannot apply the Call Waiting tone repeatedly and I = see no=20 reason for such a restriction.
 
I can think of an implementation of = Call Waiting=20 for example in the UK where it would be advantageous for the Call = Waiting tone=20 to be repeatedly applied by the MG, rather than defining the distinct = number of=20 cycles of Call Waiting that should be applied at the MG as determined by = the=20 pattern parameter. This approach minimises the configuration in the MG = and lets=20 the MGC determine the number of cycles of Call Waiting that should be = applied,=20 which it does know anyway since it is running an overall timer within = which the=20 waiting call should be accepted.
 
Some additional comments = in-line.
 
 
Dal Chohan.
 
 
 
----- Original Message -----
From:=20 Kevin Boyle
To: Dal Chohan ; Raphael Tryster ; megaco@ietf.org
Sent: Thursday, February 05, = 2004 12:27=20 PM
Subject: RE: [Megaco] H.248.23 = Enhanced=20 Alerting Package.

So, you would rather need two messages to play the tone once = and one=20 message to play the tone twice?  That is incredibly=20 non-intuitive.
 
[DC] I didn't say that - Isn't that the purpose of the = pattern=20 parameter to define the duration of the Call Waiting tone, so for = example=20 pattern 1 could mean apply the Call Waiting tone indefinitely and = pattern 2=20 could mean apply one pulse of Call Waiting tone.
 
 
Call wait generally has a very long interval between = occurrences, and=20 is generally limited to two occurrences. 
 
[DC] The two ocurrences may true for the US market, but = this isn't=20 the case for the UK.
 
Ringing, on the other hand, does not have a long interval (as = compared=20 to the length of the audible signal) and is always applied = indefinitely. =20 Further, the two examples I gave are just that -- examples.  If = you read=20 the call waiting specifications, certain feature interactions require = only a=20 single application of the call wait tone as well.  These all lead = to the=20 conclusion that I stated earlier: Call wait is a discrete signal = applied=20 multiple times.
 
[DC] I have no problem with treating the signal as a pulsed = signal that=20 is applied multiple times, but the current text states that "multiple" = cannnot=20 be of an infinite value and I think the UK Call Waiting service = operation=20 could benefit from this latter mode of working.
 
Kevin

From: Dal Chohan=20 [mailto:D.Chohan@ftel.co.uk]
Sent: Thursday, February 05, = 2004=20 4:18 AM
To: Raphael Tryster; = megaco@ietf.org
Subject:=20 Re: [Megaco] H.248.23 Enhanced Alerting = Package.

Raphael =
 
Thanks for the response = -  but I don't see why the Call Waiting = can't be=20 repeatedly applied just like ringing. If = the Callee=20 flashes, then the detection of the event will stop the signal as per = standard H.248 behaviour and if the waiting party hangs up, then the = MGC=20 will instruct the MG to stop applying the signal via a new signal=20 descriptor.
 
Dal Chohan.
----- Original Message ----- =
From:=20 Raphael=20 Tryster
To: 'Dal Chohan' ; megaco@ietf.org=20
Sent: Wednesday, February = 04, 2004=20 4:26 PM
Subject: RE: [Megaco] = H.248.23=20 Enhanced Alerting Package.

Kevin Boyle answered this question=20 recently:


Call wait patterns are generally = replayed after=20 a short amount of time (10 seconds in North America).  Note = that this=20 is not a repetition -- this is actually a second distinct = application of=20 the signal.  There are several feature scenarios where the = second=20 signal will not be applied -- if the waiting party hangs up, or if = the=20 callee flashes, to name a couple.


As = for the dt=20 package, I believe the characterization of call wait tone as = timeout is=20 erroneous, although previous attempts to fix it have been = rejected. =20 I wrote the alerting package to be local-variant unaware, leaving = it to=20 the MG to be responsible for how the signals should be applied to = its=20 terminations.  Note that most localities have more than one = wait tone=20 pattern, to allow for assignable distinctive tones (similar to = assigning=20 distinctive ringing patterns to different incoming = callers).


I see = no reason to=20 use dt/cw if using alert/cw.  The alerting package provides = far more=20 functionality than the dt package for both ringing and call=20 waiting.


Kevin=20


  _____ =  

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

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

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

    Raphael Tryster=20


    -----Original = Message-----
    From:  =20 Dal Chohan [SMTP:D.Chohan@ftel.co.uk]
    Sent:   Wednesday, 4=20 February 2004 18:12
    To:     megaco@ietf.org
    Subject:       =20 [Megaco] H.248.23 Enhanced Alerting=20 Package.


    The = description=20 of the "Call Waiting" signal defined in H.248.23 specifies that = call=20 waiting patterns do not repeat - Is this correct?


    I would have thought that for a Call Waiting service = that it=20 would would make perfect sense for the "call waiting" pattern to = be=20 repeatedly applied by the MG until it was told to stop the call = waiting=20 signal by the MGC (c.f. ringing) . It is the MGC=20 that determines the interval within which the waiting call = should=20 be accepted and thus determines the overall duration of = the call=20 waiting pattern.


     
     
    Dal=20 = Chohan

<= /HTML> ------=_NextPart_000_00DB_01C3EBF0.2A65F830-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Feb 5 09:49:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17057 for ; Thu, 5 Feb 2004 09:49:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokoP-0001yQ-8z; Thu, 05 Feb 2004 09:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoknY-0001uq-Fg for megaco@optimus.ietf.org; Thu, 05 Feb 2004 09:48:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16957 for ; Thu, 5 Feb 2004 09:48:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoknW-0006MB-00 for megaco@ietf.org; Thu, 05 Feb 2004 09:48:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AokmZ-0006G0-00 for megaco@ietf.org; Thu, 05 Feb 2004 09:47:08 -0500 Received: from bay1-f141.bay1.hotmail.com ([65.54.245.141] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1Aokln-000647-00 for megaco@ietf.org; Thu, 05 Feb 2004 09:46:19 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 5 Feb 2004 06:45:48 -0800 Received: from 202.54.11.72 by by1fd.bay1.hotmail.msn.com with HTTP; Thu, 05 Feb 2004 14:45:48 GMT X-Originating-IP: [202.54.11.72] X-Originating-Email: [sharma_u@hotmail.com] X-Sender: sharma_u@hotmail.com From: "Umesh Sharma" To: kboyle@nortelnetworks.com, D.Chohan@ftel.co.uk, raphael@tdsoft.com, megaco@ietf.org Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. Date: Thu, 05 Feb 2004 14:45:48 +0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 05 Feb 2004 14:45:48.0434 (UTC) FILETIME=[BE56AF20:01C3EBF6] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=HTML_FONTCOLOR_RED, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: ,

Hi,

Just to add specs says Call Waiting tone should be a 440 Hz tone applied for 300 +- 50 ms, talking path should be interrupted for a maximum of 400ms for the application of CW tone. If the controlling party does not flash or disconnect after FIRST burst of CW tone, a second burst should be applied 10 +- 1 seconds later (can go upto 30 ms in overload situation).  The behaviour could be different due to interactions with other services that a subscriber has subscribed to. Applying ringing continously will disturb the conversation going on.

Regards,

Umesh



 




 
>From: "Kevin Boyle" >To: Dal Chohan , Raphael Tryster , megaco@ietf.org >Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. >Date: Thu, 5 Feb 2004 07:27:37 -0500 > >So, you would rather need two messages to play the tone once and one message >to play the tone twice? That is incredibly non-intuitive. > >Call wait generally has a very long interval between occurrences, and is >generally limited to two occurrences. Ringing, on the other hand, does not >have a long interval (as compared to the length of the audible signal) and >is always applied indefinitely. Further, the two examples I gave are just >that -- examples. If you read the call waiting specifications, certain >feature interactions require only a single application of the call wait tone >a! s well. These all lead to the conclusion that I stated earlier: Call wait >is a discrete signal applied multiple times. > >Kevin > > > _____ > >From: Dal Chohan [mailto:D.Chohan@ftel.co.uk] >Sent: Thursday, February 05, 2004 4:18 AM >To: Raphael Tryster; megaco@ietf.org >Subject: Re: [Megaco] H.248.23 Enhanced Alerting Package. > > >Raphael > >Thanks for the response - but I don't see why the Call Waiting can't be >repeatedly applied just like ringing. If the Callee flashes, then the >detection of the event will stop the signal as per standard H.248 behaviour >and if the waiting party hangs up, then the MGC will instruct the MG to stop >applying the signal via a new signal descriptor. > >Dal Chohan. > >----- Original Message ----- >From: Raphael Tryster >To: 'Dal Chohan' ; megaco@ietf.org > >Sent: Wednesday, Febru! ary 04, 2004 4:26 PM >Subject: RE: [Megaco] H.248.23 Enhanced Alert ing Package. > > >Kevin Boyle answered this question recently: > > >Call wait patterns are generally replayed after a short amount of time (10 >seconds in North America). Note that this is not a repetition -- this is >actually a second distinct application of the signal. There are several >feature scenarios where the second signal will not be applied -- if the >waiting party hangs up, or if the callee flashes, to name a couple. > > >As for the dt package, I believe the characterization of call wait tone as >timeout is erroneous, although previous attempts to fix it have been >rejected. I wrote the alerting package to be local-variant unaware, leaving >it to the MG to be responsible for how the signals should be applied to its >terminations. Note that most localities have more than one wait tone >pattern, to allow for assignable distinctive tones (similar to assigning >distinctive ringing patterns to different incoming ! callers). > > >I see no reason to use dt/cw if using alert/cw. The alerting package >provides far more functionality than the dt package for both ringing and >call waiting. > > >Kevin > > > _____ > > > > From: Raphael Tryster >[mailto:raphael@tdsoft.com] >Sent: Thursday, January 08, 2004 5:39 AM >To: Boyle, Kevin [NCRTP:3Z40:EXCH]; >megaco@ietf.org >Subject: call waiting signal type > > > > In draft_boyle_megaco_alerting_03.txt, the alert/cw signal has type >brief, whereas the standard signal dt/cw apparently has type timeout. Is >this a matter of national protocol? The description of alert/cw says "Call >wait patterns do not repeat". In Israel, a call waiting signal consists of >3 short tones, repeated once a few seconds later. > > If it is a matter of national protocol, does this mean that a >particular installation will ! use either alert/cw or dt/cw, but not both? > > Raphael Tryster > > > BM__MailData-----Original Message----- >From: Dal Chohan [SMTP:D.Chohan@ftel.co.uk] >Sent: Wednesday, 4 February 2004 18:12 >To: megaco@ietf.org >Subject: [Megaco] H.248.23 Enhanced Alerting Package. > > >The description of the "Call Waiting" signal defined in H.248.23 specifies >that call waiting patterns do not repeat - Is this correct? > > >I would have thought that for a Call Waiting service that it would would >make perfect sense for the "call waiting" pattern to be repeatedly applied >by the MG until it was told to stop the call waiting signal by the MGC (c.f. >ringing) . It is the MGC that determines the interval within which the >waiting call should be accepted and thus determines the overall duration of >the call waiting pattern. > > > > >Dal Chohan > > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailm! an/listinfo/megaco

Easiest Money Transfer to India. Send Money To 6000 Indian Towns. Easiest Way To Send Money Home! _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Feb 5 09:51:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17133 for ; Thu, 5 Feb 2004 09:51:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokqL-0002C6-2T for megaco-archive@odin.ietf.org; Thu, 05 Feb 2004 09:51:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15Ep1h9008430 for megaco-archive@odin.ietf.org; Thu, 5 Feb 2004 09:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokqK-0002Bq-Ti for megaco-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 09:51:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17107 for ; Thu, 5 Feb 2004 09:50:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AokqI-0006gQ-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 09:50:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AokpK-0006Zp-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 09:49:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AokoO-0006T1-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 09:49:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokoP-0001yQ-8z; Thu, 05 Feb 2004 09:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoknY-0001uq-Fg for megaco@optimus.ietf.org; Thu, 05 Feb 2004 09:48:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16957 for ; Thu, 5 Feb 2004 09:48:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoknW-0006MB-00 for megaco@ietf.org; Thu, 05 Feb 2004 09:48:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AokmZ-0006G0-00 for megaco@ietf.org; Thu, 05 Feb 2004 09:47:08 -0500 Received: from bay1-f141.bay1.hotmail.com ([65.54.245.141] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1Aokln-000647-00 for megaco@ietf.org; Thu, 05 Feb 2004 09:46:19 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 5 Feb 2004 06:45:48 -0800 Received: from 202.54.11.72 by by1fd.bay1.hotmail.msn.com with HTTP; Thu, 05 Feb 2004 14:45:48 GMT X-Originating-IP: [202.54.11.72] X-Originating-Email: [sharma_u@hotmail.com] X-Sender: sharma_u@hotmail.com From: "Umesh Sharma" To: kboyle@nortelnetworks.com, D.Chohan@ftel.co.uk, raphael@tdsoft.com, megaco@ietf.org Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. Date: Thu, 05 Feb 2004 14:45:48 +0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 05 Feb 2004 14:45:48.0434 (UTC) FILETIME=[BE56AF20:01C3EBF6] Sender: megaco-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=HTML_FONTCOLOR_RED, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY autolearn=no version=2.60

Hi,

Just to add specs says Call Waiting tone should be a 440 Hz tone applied for 300 +- 50 ms, talking path should be interrupted for a maximum of 400ms for the application of CW tone. If the controlling party does not flash or disconnect after FIRST burst of CW tone, a second burst should be applied 10 +- 1 seconds later (can go upto 30 ms in overload situation).  The behaviour could be different due to interactions with other services that a subscriber has subscribed to. Applying ringing continously will disturb the conversation going on.

Regards,

Umesh



 




 
>From: "Kevin Boyle" >To: Dal Chohan , Raphael Tryster , megaco@ietf.org >Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. >Date: Thu, 5 Feb 2004 07:27:37 -0500 > >So, you would rather need two messages to play the tone once and one message >to play the tone twice? That is incredibly non-intuitive. > >Call wait generally has a very long interval between occurrences, and is >generally limited to two occurrences. Ringing, on the other hand, does not >have a long interval (as compared to the length of the audible signal) and >is always applied indefinitely. Further, the two examples I gave are just >that -- examples. If you read the call waiting specifications, certain >feature interactions require only a single application of the call wait tone >a! s well. These all lead to the conclusion that I stated earlier: Call wait >is a discrete signal applied multiple times. > >Kevin > > > _____ > >From: Dal Chohan [mailto:D.Chohan@ftel.co.uk] >Sent: Thursday, February 05, 2004 4:18 AM >To: Raphael Tryster; megaco@ietf.org >Subject: Re: [Megaco] H.248.23 Enhanced Alerting Package. > > >Raphael > >Thanks for the response - but I don't see why the Call Waiting can't be >repeatedly applied just like ringing. If the Callee flashes, then the >detection of the event will stop the signal as per standard H.248 behaviour >and if the waiting party hangs up, then the MGC will instruct the MG to stop >applying the signal via a new signal descriptor. > >Dal Chohan. > >----- Original Message ----- >From: Raphael Tryster >To: 'Dal Chohan' ; megaco@ietf.org > >Sent: Wednesday, Febru! ary 04, 2004 4:26 PM >Subject: RE: [Megaco] H.248.23 Enhanced Alert ing Package. > > >Kevin Boyle answered this question recently: > > >Call wait patterns are generally replayed after a short amount of time (10 >seconds in North America). Note that this is not a repetition -- this is >actually a second distinct application of the signal. There are several >feature scenarios where the second signal will not be applied -- if the >waiting party hangs up, or if the callee flashes, to name a couple. > > >As for the dt package, I believe the characterization of call wait tone as >timeout is erroneous, although previous attempts to fix it have been >rejected. I wrote the alerting package to be local-variant unaware, leaving >it to the MG to be responsible for how the signals should be applied to its >terminations. Note that most localities have more than one wait tone >pattern, to allow for assignable distinctive tones (similar to assigning >distinctive ringing patterns to different incoming ! callers). > > >I see no reason to use dt/cw if using alert/cw. The alerting package >provides far more functionality than the dt package for both ringing and >call waiting. > > >Kevin > > > _____ > > > > From: Raphael Tryster >[mailto:raphael@tdsoft.com] >Sent: Thursday, January 08, 2004 5:39 AM >To: Boyle, Kevin [NCRTP:3Z40:EXCH]; >megaco@ietf.org >Subject: call waiting signal type > > > > In draft_boyle_megaco_alerting_03.txt, the alert/cw signal has type >brief, whereas the standard signal dt/cw apparently has type timeout. Is >this a matter of national protocol? The description of alert/cw says "Call >wait patterns do not repeat". In Israel, a call waiting signal consists of >3 short tones, repeated once a few seconds later. > > If it is a matter of national protocol, does this mean that a >particular installation will ! use either alert/cw or dt/cw, but not both? > > Raphael Tryster > > > BM__MailData-----Original Message----- >From: Dal Chohan [SMTP:D.Chohan@ftel.co.uk] >Sent: Wednesday, 4 February 2004 18:12 >To: megaco@ietf.org >Subject: [Megaco] H.248.23 Enhanced Alerting Package. > > >The description of the "Call Waiting" signal defined in H.248.23 specifies >that call waiting patterns do not repeat - Is this correct? > > >I would have thought that for a Call Waiting service that it would would >make perfect sense for the "call waiting" pattern to be repeatedly applied >by the MG until it was told to stop the call waiting signal by the MGC (c.f. >ringing) . It is the MGC that determines the interval within which the >waiting call should be accepted and thus determines the overall duration of >the call waiting pattern. > > > > >Dal Chohan > > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailm! an/listinfo/megaco

Easiest Money Transfer to India. Send Money To 6000 Indian Towns. Easiest Way To Send Money Home! _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Feb 5 12:27:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24967 for ; Thu, 5 Feb 2004 12:27:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AonHJ-0008Hu-6v; Thu, 05 Feb 2004 12:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AonGP-0008Cm-Qx for megaco@optimus.ietf.org; Thu, 05 Feb 2004 12:26:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24939 for ; Thu, 5 Feb 2004 12:26:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AonGO-00079B-00 for megaco@ietf.org; Thu, 05 Feb 2004 12:26:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AonFQ-00074l-00 for megaco@ietf.org; Thu, 05 Feb 2004 12:25:05 -0500 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1AonEt-0006zi-00 for megaco@ietf.org; Thu, 05 Feb 2004 12:24:31 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i15HO0q02981 for ; Thu, 5 Feb 2004 12:24:00 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3D18DF>; Thu, 5 Feb 2004 12:24:01 -0500 Message-ID: From: "Kevin Boyle" To: Dal Chohan , Raphael Tryster , megaco@ietf.org Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. Date: Thu, 5 Feb 2004 12:23:59 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , If the MGC wants to apply the tone repeatedly, it is certainly within the prerogative of the MGC to override the signal type and duration. I am interested to know which specification defines the feature you talk about, since I went out of my way to consider the function of these features in many localities when I designed the packages. It seems to me that things are a little more complicated than just playing the sound repeatedly. Applying a signal on an active speech path requires the MG to cut the speech path to ensure that only the party to whom the tone applies hears it. This would imply that the speech path would be cut for the entire duration of the signal. This would be somewhat detrimental to the ongoing speech on the call if the duration of the tone is "infinite". I stand by what the package says. Kevin _____ From: Dal Chohan [mailto:D.Chohan@ftel.co.uk] Sent: Thursday, February 05, 2004 8:59 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Raphael Tryster; megaco@ietf.org Subject: Re: [Megaco] H.248.23 Enhanced Alerting Package. Sorry, but I think you have missed the point that I am making - H.248.23 states that Call Wait patterns do not repeat and to me this means that you cannot apply the Call Waiting tone repeatedly and I see no reason for such a restriction. I can think of an implementation of Call Waiting for example in the UK where it would be advantageous for the Call Waiting tone to be repeatedly applied by the MG, rather than defining the distinct number of cycles of Call Waiting that should be applied at the MG as determined by the pattern parameter. This approach minimises the configuration in the MG and lets the MGC determine the number of cycles of Call Waiting that should be applied, which it does know anyway since it is running an overall timer within which the waiting call should be accepted. Some additional comments in-line. Dal Chohan. ----- Original Message ----- From: Kevin Boyle To: Dal Chohan ; Raphael Tryster ; megaco@ietf.org Sent: Thursday, February 05, 2004 12:27 PM Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. So, you would rather need two messages to play the tone once and one message to play the tone twice? That is incredibly non-intuitive. [DC] I didn't say that - Isn't that the purpose of the pattern parameter to define the duration of the Call Waiting tone, so for example pattern 1 could mean apply the Call Waiting tone indefinitely and pattern 2 could mean apply one pulse of Call Waiting tone. Call wait generally has a very long interval between occurrences, and is generally limited to two occurrences. [DC] The two ocurrences may true for the US market, but this isn't the case for the UK. Ringing, on the other hand, does not have a long interval (as compared to the length of the audible signal) and is always applied indefinitely. Further, the two examples I gave are just that -- examples. If you read the call waiting specifications, certain feature interactions require only a single application of the call wait tone as well. These all lead to the conclusion that I stated earlier: Call wait is a discrete signal applied multiple times. [DC] I have no problem with treating the signal as a pulsed signal that is applied multiple times, but the current text states that "multiple" cannnot be of an infinite value and I think the UK Call Waiting service operation could benefit from this latter mode of working. Kevin _____ From: Dal Chohan [mailto:D.Chohan@ftel.co.uk] Sent: Thursday, February 05, 2004 4:18 AM To: Raphael Tryster; megaco@ietf.org Subject: Re: [Megaco] H.248.23 Enhanced Alerting Package. Raphael Thanks for the response - but I don't see why the Call Waiting can't be repeatedly applied just like ringing. If the Callee flashes, then the detection of the event will stop the signal as per standard H.248 behaviour and if the waiting party hangs up, then the MGC will instruct the MG to stop applying the signal via a new signal descriptor. Dal Chohan. ----- Original Message ----- From: Raphael Tryster To: 'Dal Chohan' ; megaco@ietf.org Sent: Wednesday, February 04, 2004 4:26 PM Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. Kevin Boyle answered this question recently: Call wait patterns are generally replayed after a short amount of time (10 seconds in North America). Note that this is not a repetition -- this is actually a second distinct application of the signal. There are several feature scenarios where the second signal will not be applied -- if the waiting party hangs up, or if the callee flashes, to name a couple. As for the dt package, I believe the characterization of call wait tone as timeout is erroneous, although previous attempts to fix it have been rejected. I wrote the alerting package to be local-variant unaware, leaving it to the MG to be responsible for how the signals should be applied to its terminations. Note that most localities have more than one wait tone pattern, to allow for assignable distinctive tones (similar to assigning distinctive ringing patterns to different incoming callers). I see no reason to use dt/cw if using alert/cw. The alerting package provides far more functionality than the dt package for both ringing and call waiting. Kevin _____ From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, January 08, 2004 5:39 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: call waiting signal type In draft_boyle_megaco_alerting_03.txt, the alert/cw signal has type brief, whereas the standard signal dt/cw apparently has type timeout. Is this a matter of national protocol? The description of alert/cw says "Call wait patterns do not repeat". In Israel, a call waiting signal consists of 3 short tones, repeated once a few seconds later. If it is a matter of national protocol, does this mean that a particular installation will use either alert/cw or dt/cw, but not both? Raphael Tryster BM__MailData-----Original Message----- From: Dal Chohan [SMTP:D.Chohan@ftel.co.uk] Sent: Wednesday, 4 February 2004 18:12 To: megaco@ietf.org Subject: [Megaco] H.248.23 Enhanced Alerting Package. The description of the "Call Waiting" signal defined in H.248.23 specifies that call waiting patterns do not repeat - Is this correct? I would have thought that for a Call Waiting service that it would would make perfect sense for the "call waiting" pattern to be repeatedly applied by the MG until it was told to stop the call waiting signal by the MGC (c.f. ringing) . It is the MGC that determines the interval within which the waiting call should be accepted and thus determines the overall duration of the call waiting pattern. Dal Chohan _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Feb 5 12:29:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25047 for ; Thu, 5 Feb 2004 12:29:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AonJG-00006l-Ud for megaco-archive@odin.ietf.org; Thu, 05 Feb 2004 12:29:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15HT2TD000411 for megaco-archive@odin.ietf.org; Thu, 5 Feb 2004 12:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AonJG-00006Y-R2 for megaco-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 12:29:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25029 for ; Thu, 5 Feb 2004 12:28:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AonJF-0007OD-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 12:29:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AonIK-0007J7-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 12:28:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AonHO-0007EN-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 12:27:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AonHJ-0008Hu-6v; Thu, 05 Feb 2004 12:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AonGP-0008Cm-Qx for megaco@optimus.ietf.org; Thu, 05 Feb 2004 12:26:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24939 for ; Thu, 5 Feb 2004 12:26:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AonGO-00079B-00 for megaco@ietf.org; Thu, 05 Feb 2004 12:26:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AonFQ-00074l-00 for megaco@ietf.org; Thu, 05 Feb 2004 12:25:05 -0500 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1AonEt-0006zi-00 for megaco@ietf.org; Thu, 05 Feb 2004 12:24:31 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i15HO0q02981 for ; Thu, 5 Feb 2004 12:24:00 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3D18DF>; Thu, 5 Feb 2004 12:24:01 -0500 Message-ID: From: "Kevin Boyle" To: Dal Chohan , Raphael Tryster , megaco@ietf.org Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. Date: Thu, 5 Feb 2004 12:23:59 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 If the MGC wants to apply the tone repeatedly, it is certainly within the prerogative of the MGC to override the signal type and duration. I am interested to know which specification defines the feature you talk about, since I went out of my way to consider the function of these features in many localities when I designed the packages. It seems to me that things are a little more complicated than just playing the sound repeatedly. Applying a signal on an active speech path requires the MG to cut the speech path to ensure that only the party to whom the tone applies hears it. This would imply that the speech path would be cut for the entire duration of the signal. This would be somewhat detrimental to the ongoing speech on the call if the duration of the tone is "infinite". I stand by what the package says. Kevin _____ From: Dal Chohan [mailto:D.Chohan@ftel.co.uk] Sent: Thursday, February 05, 2004 8:59 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Raphael Tryster; megaco@ietf.org Subject: Re: [Megaco] H.248.23 Enhanced Alerting Package. Sorry, but I think you have missed the point that I am making - H.248.23 states that Call Wait patterns do not repeat and to me this means that you cannot apply the Call Waiting tone repeatedly and I see no reason for such a restriction. I can think of an implementation of Call Waiting for example in the UK where it would be advantageous for the Call Waiting tone to be repeatedly applied by the MG, rather than defining the distinct number of cycles of Call Waiting that should be applied at the MG as determined by the pattern parameter. This approach minimises the configuration in the MG and lets the MGC determine the number of cycles of Call Waiting that should be applied, which it does know anyway since it is running an overall timer within which the waiting call should be accepted. Some additional comments in-line. Dal Chohan. ----- Original Message ----- From: Kevin Boyle To: Dal Chohan ; Raphael Tryster ; megaco@ietf.org Sent: Thursday, February 05, 2004 12:27 PM Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. So, you would rather need two messages to play the tone once and one message to play the tone twice? That is incredibly non-intuitive. [DC] I didn't say that - Isn't that the purpose of the pattern parameter to define the duration of the Call Waiting tone, so for example pattern 1 could mean apply the Call Waiting tone indefinitely and pattern 2 could mean apply one pulse of Call Waiting tone. Call wait generally has a very long interval between occurrences, and is generally limited to two occurrences. [DC] The two ocurrences may true for the US market, but this isn't the case for the UK. Ringing, on the other hand, does not have a long interval (as compared to the length of the audible signal) and is always applied indefinitely. Further, the two examples I gave are just that -- examples. If you read the call waiting specifications, certain feature interactions require only a single application of the call wait tone as well. These all lead to the conclusion that I stated earlier: Call wait is a discrete signal applied multiple times. [DC] I have no problem with treating the signal as a pulsed signal that is applied multiple times, but the current text states that "multiple" cannnot be of an infinite value and I think the UK Call Waiting service operation could benefit from this latter mode of working. Kevin _____ From: Dal Chohan [mailto:D.Chohan@ftel.co.uk] Sent: Thursday, February 05, 2004 4:18 AM To: Raphael Tryster; megaco@ietf.org Subject: Re: [Megaco] H.248.23 Enhanced Alerting Package. Raphael Thanks for the response - but I don't see why the Call Waiting can't be repeatedly applied just like ringing. If the Callee flashes, then the detection of the event will stop the signal as per standard H.248 behaviour and if the waiting party hangs up, then the MGC will instruct the MG to stop applying the signal via a new signal descriptor. Dal Chohan. ----- Original Message ----- From: Raphael Tryster To: 'Dal Chohan' ; megaco@ietf.org Sent: Wednesday, February 04, 2004 4:26 PM Subject: RE: [Megaco] H.248.23 Enhanced Alerting Package. Kevin Boyle answered this question recently: Call wait patterns are generally replayed after a short amount of time (10 seconds in North America). Note that this is not a repetition -- this is actually a second distinct application of the signal. There are several feature scenarios where the second signal will not be applied -- if the waiting party hangs up, or if the callee flashes, to name a couple. As for the dt package, I believe the characterization of call wait tone as timeout is erroneous, although previous attempts to fix it have been rejected. I wrote the alerting package to be local-variant unaware, leaving it to the MG to be responsible for how the signals should be applied to its terminations. Note that most localities have more than one wait tone pattern, to allow for assignable distinctive tones (similar to assigning distinctive ringing patterns to different incoming callers). I see no reason to use dt/cw if using alert/cw. The alerting package provides far more functionality than the dt package for both ringing and call waiting. Kevin _____ From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, January 08, 2004 5:39 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: call waiting signal type In draft_boyle_megaco_alerting_03.txt, the alert/cw signal has type brief, whereas the standard signal dt/cw apparently has type timeout. Is this a matter of national protocol? The description of alert/cw says "Call wait patterns do not repeat". In Israel, a call waiting signal consists of 3 short tones, repeated once a few seconds later. If it is a matter of national protocol, does this mean that a particular installation will use either alert/cw or dt/cw, but not both? Raphael Tryster BM__MailData-----Original Message----- From: Dal Chohan [SMTP:D.Chohan@ftel.co.uk] Sent: Wednesday, 4 February 2004 18:12 To: megaco@ietf.org Subject: [Megaco] H.248.23 Enhanced Alerting Package. The description of the "Call Waiting" signal defined in H.248.23 specifies that call waiting patterns do not repeat - Is this correct? I would have thought that for a Call Waiting service that it would would make perfect sense for the "call waiting" pattern to be repeatedly applied by the MG until it was told to stop the call waiting signal by the MGC (c.f. ringing) . It is the MGC that determines the interval within which the waiting call should be accepted and thus determines the overall duration of the call waiting pattern. Dal Chohan _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Feb 5 16:24:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09842 for ; Thu, 5 Feb 2004 16:24:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoqyf-0001WF-0X; Thu, 05 Feb 2004 16:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqyM-0001UL-Co for megaco@optimus.ietf.org; Thu, 05 Feb 2004 16:23:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09793 for ; Thu, 5 Feb 2004 16:23:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoqyK-0002ks-00 for megaco@ietf.org; Thu, 05 Feb 2004 16:23:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoqx9-0002Zy-00 for megaco@ietf.org; Thu, 05 Feb 2004 16:22:28 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AoqwY-0002ST-00 for megaco@ietf.org; Thu, 05 Feb 2004 16:21:51 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i15LLnqY020803 for ; Thu, 5 Feb 2004 22:21:49 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 22:21:49 +0100 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJ15S9T; Thu, 5 Feb 2004 22:22:23 +0100 Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.140]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1HJMJSFJ; Fri, 6 Feb 2004 08:21:41 +1100 Message-ID: <4022B371.2030706@ericsson.com> Date: Fri, 06 Feb 2004 08:19:45 +1100 X-Sybari-Trust: a0556279 6b512624 6c3547e6 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nurit Shenhar CC: megaco@ietf.org References: <14B7C5B03853404495D29CFA4A54B21C70DAEE@lodmsg01.corp.audiocodes.com> In-Reply-To: <14B7C5B03853404495D29CFA4A54B21C70DAEE@lodmsg01.corp.audiocodes.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 05 Feb 2004 21:21:49.0400 (UTC) FILETIME=[10FA5D80:01C3EC2E] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by albatross-ext.wise.edt.ericsson.se id i15LLnqY020803 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Megaco] Re: Contradiction in signal ID between H.248.24 and Q.1950 Sender: megaco-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: quoted-printable Hello Nurit, These do not need to be unique because when you reference a signal the=20 formulation is PackageID/ToneID. The packageID means that the toneid is u= nique.=20 You cannot use the Original (extended packageID) to reference the tones i= n the=20 new package. Or have I missed something in your question? Regards, Christian Nurit Shenhar wrote: > Hi Christian >=20 > =20 >=20 > Can you forward this mail for me to the list? (Or answer it yourself)?=20 > Somehow my mails don=92t get to the list. I sent a mail to Tom Taylor, = but=20 > got no response. >=20 > =20 >=20 > =20 >=20 > The tone IDs in the MF generation package H.248.24 are defined as 0x005= 0=20 > and up. In the Q.1950 package Basic Service Tones Generation (=91srvtn=92= )=20 > and the following packages, the signals start from 0x004f. That results= =20 > in non-unique numbers. As both packages inherit from the basic tones=20 > generation package =91tonegen=92, I think they should be unique. >=20 > =20 >=20 > Thanks, >=20 > =20 >=20 > =20 >=20 > Nurit Shenhar >=20 > H.248/MEGACO Architect >=20 > =20 >=20 > E-Mail: nurit.shenhar@audiocodes.com >=20 > Fax. +972-3-5394223 >=20 > www.audiocodes.com >=20 > =20 >=20 This communication is confidential and intended solely for the addressee(= s). Any unauthorized review, use, disclosure or distribution is prohibite= d. If you believe this message has been sent to you in error, please noti= fy the sender by replying to this transmission and delete the message wit= hout disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interrupt= ion, unauthorized amendment, tampering and viruses, and we only send and = receive e-mails on the basis that we are not liable for any such corrupti= on, interception, amendment, tampering or viruses or any consequences the= reof. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Feb 5 16:28:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10407 for ; Thu, 5 Feb 2004 16:28:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aor2S-0001oB-Rk for megaco-archive@odin.ietf.org; Thu, 05 Feb 2004 16:27:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15LRu6D006950 for megaco-archive@odin.ietf.org; Thu, 5 Feb 2004 16:27:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aor2S-0001o1-OB for megaco-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 16:27:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10312 for ; Thu, 5 Feb 2004 16:27:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aor2Q-0003gf-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 16:27:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aor0F-0003Cf-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 16:25:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aoqyg-0002oU-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 16:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoqyf-0001WF-0X; Thu, 05 Feb 2004 16:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqyM-0001UL-Co for megaco@optimus.ietf.org; Thu, 05 Feb 2004 16:23:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09793 for ; Thu, 5 Feb 2004 16:23:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoqyK-0002ks-00 for megaco@ietf.org; Thu, 05 Feb 2004 16:23:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoqx9-0002Zy-00 for megaco@ietf.org; Thu, 05 Feb 2004 16:22:28 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AoqwY-0002ST-00 for megaco@ietf.org; Thu, 05 Feb 2004 16:21:51 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i15LLnqY020803 for ; Thu, 5 Feb 2004 22:21:49 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 22:21:49 +0100 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJ15S9T; Thu, 5 Feb 2004 22:22:23 +0100 Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.140]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1HJMJSFJ; Fri, 6 Feb 2004 08:21:41 +1100 Message-ID: <4022B371.2030706@ericsson.com> Date: Fri, 06 Feb 2004 08:19:45 +1100 X-Sybari-Trust: a0556279 6b512624 6c3547e6 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nurit Shenhar CC: megaco@ietf.org References: <14B7C5B03853404495D29CFA4A54B21C70DAEE@lodmsg01.corp.audiocodes.com> In-Reply-To: <14B7C5B03853404495D29CFA4A54B21C70DAEE@lodmsg01.corp.audiocodes.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 05 Feb 2004 21:21:49.0400 (UTC) FILETIME=[10FA5D80:01C3EC2E] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by albatross-ext.wise.edt.ericsson.se id i15LLnqY020803 Content-Transfer-Encoding: quoted-printable Subject: [Megaco] Re: Contradiction in signal ID between H.248.24 and Q.1950 Sender: megaco-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Nurit, These do not need to be unique because when you reference a signal the=20 formulation is PackageID/ToneID. The packageID means that the toneid is u= nique.=20 You cannot use the Original (extended packageID) to reference the tones i= n the=20 new package. Or have I missed something in your question? Regards, Christian Nurit Shenhar wrote: > Hi Christian >=20 > =20 >=20 > Can you forward this mail for me to the list? (Or answer it yourself)?=20 > Somehow my mails don=92t get to the list. I sent a mail to Tom Taylor, = but=20 > got no response. >=20 > =20 >=20 > =20 >=20 > The tone IDs in the MF generation package H.248.24 are defined as 0x005= 0=20 > and up. In the Q.1950 package Basic Service Tones Generation (=91srvtn=92= )=20 > and the following packages, the signals start from 0x004f. That results= =20 > in non-unique numbers. As both packages inherit from the basic tones=20 > generation package =91tonegen=92, I think they should be unique. >=20 > =20 >=20 > Thanks, >=20 > =20 >=20 > =20 >=20 > Nurit Shenhar >=20 > H.248/MEGACO Architect >=20 > =20 >=20 > E-Mail: nurit.shenhar@audiocodes.com >=20 > Fax. +972-3-5394223 >=20 > www.audiocodes.com >=20 > =20 >=20 This communication is confidential and intended solely for the addressee(= s). Any unauthorized review, use, disclosure or distribution is prohibite= d. If you believe this message has been sent to you in error, please noti= fy the sender by replying to this transmission and delete the message wit= hout disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interrupt= ion, unauthorized amendment, tampering and viruses, and we only send and = receive e-mails on the basis that we are not liable for any such corrupti= on, interception, amendment, tampering or viruses or any consequences the= reof. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Feb 5 16:50:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14033 for ; Thu, 5 Feb 2004 16:50:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorNs-0004MG-O9; Thu, 05 Feb 2004 16:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorNH-0004Gz-OA for megaco@optimus.ietf.org; Thu, 05 Feb 2004 16:49:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13770 for ; Thu, 5 Feb 2004 16:49:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AorNE-0007ba-00 for megaco@ietf.org; Thu, 05 Feb 2004 16:49:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AorLX-0007FG-00 for megaco@ietf.org; Thu, 05 Feb 2004 16:47:40 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AorJB-0006m0-00 for megaco@ietf.org; Thu, 05 Feb 2004 16:45:13 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i15LjDYG025246 for ; Thu, 5 Feb 2004 22:45:13 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 22:45:12 +0100 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJS23R8; Thu, 5 Feb 2004 22:45:12 +0100 Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.140]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1HJMJSVC; Fri, 6 Feb 2004 08:45:05 +1100 Message-ID: <4022B8EC.5040105@ericsson.com> Date: Fri, 06 Feb 2004 08:43:08 +1100 X-Sybari-Trust: 9198306c 6b512624 6c3547e6 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dal Chohan CC: megaco@ietf.org Subject: Re: [Megaco] Events Descriptor with KeepActive set and an Emebdded Signals Descriptor References: <008001c3e985$9114d690$403010ac@DALLAPTOP> In-Reply-To: <008001c3e985$9114d690$403010ac@DALLAPTOP> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2004 21:45:12.0958 (UTC) FILETIME=[559051E0:01C3EC31] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Dal, I believe there may be some confusion over which KeepActive is being referred to by the text. Both the EventDescriptor and the signal descriptor can have the keep active flag. This text talks about the EventDescriptor keepactive flag. The reason the text was added was that in the case of an embedded signals descriptor it doesn't make sense to have a keep active flag in the EventDescriptor because the embedded signals descriptor will become active at the detection of event and any existing signals would be subject to the keep active flags in this embedded descriptor. So I believe your scenarios are handled. Regards, Christian Dal Chohan wrote: > H.248v2 clause 7.1.9 states that ; "A media gateway controller shall not > send EventsDescriptors with an event both marked KeepActive and > containing an embedded SignalsDescriptor" > > I think that this is unnecessarily too restrictive and unduly reduces > the flexibility of H.248. The judicious use of the KA flag within the > Embedded Signal descriptor itself can keep the Signal currently being > applied active. > > The following scenario describes a practical situation where the above > rule is violate. Take the case where "Automatic Metering" is applied to > an analogue line and automatic meter pulses are being generated by the > MG. Now the MG is monitoring for "On-Hook" and the KA (KeepActive) flag > is sent against the "On-Hook" event. Upon detection of "On-Hook" the > event is reported to the MGC by the MG and the automatic metering still > continues. > > Now the MGC sends a command requesting that the MG monitor for > "Off-Hook" with the KA flag set, plus an Embedded > signals/event descriptor indicating that "dial tone" should be played. > In addition the KA flag is set for the "enable metering" signal to > ensure that the automatic metering continues when the dial tone signal > is applied , and the digit map descriptor is also enabled. Now this > sequence clearly violates the rule stated above. > > I would therefore recommend that the sentence above is deleted from the > specification unless someone can think off a good reason for keeping it, > because it is unnecessarily too restrictive and reduces the flexibility > of the H.248 protocol. > > > > > Regards. > > > Dal Chohan This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Feb 5 16:55:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14483 for ; Thu, 5 Feb 2004 16:55:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorSh-0004Y5-3H; Thu, 05 Feb 2004 16:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorRu-0004Up-Nu for megaco@optimus.ietf.org; Thu, 05 Feb 2004 16:54:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14448 for ; Thu, 5 Feb 2004 16:54:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AorRs-0000Ni-00 for megaco@ietf.org; Thu, 05 Feb 2004 16:54:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AorRB-0000Mk-00 for megaco@ietf.org; Thu, 05 Feb 2004 16:53:30 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AorQW-0000JY-00 for megaco@ietf.org; Thu, 05 Feb 2004 16:52:48 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i15LqmYG025715 for ; Thu, 5 Feb 2004 22:52:48 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 22:52:48 +0100 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJ30S5V; Thu, 5 Feb 2004 22:52:47 +0100 Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.140]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1HJMJSZ7; Fri, 6 Feb 2004 08:52:40 +1100 Message-ID: <4022BAB4.2060604@ericsson.com> Date: Fri, 06 Feb 2004 08:50:44 +1100 X-Sybari-Trust: 09a437b0 6b512624 6c3547e6 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jean-Luc.Lecuyer@alcatel.fr CC: megaco@ietf.org Subject: Re: [Megaco] Analog line state References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2004 21:52:48.0163 (UTC) FILETIME=[64E31730:01C3EC32] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Jean-Luc, If you use and Audit the Event Buffer Descriptor you will get the current events active. Otherwise you will have to reset the event using the "strict" parameter. However I would first address an implementation that loses messages... Regards, Christian Jean-Luc.Lecuyer@alcatel.fr wrote: > High all > > Initial state : the MG is programmed to send a notify if a transition > on-hook / off-hook or vice versa happens. > Nevertheless the MGC can miss a transition state from on-hook / off-hook > or vice versa (lost of H248 dialog with the MG) > > I am looking for a way to know the state of a analog line (on-hook / > off-hook). I expected to use the AuditValue on the termination to know it > but unfortunately the AuditValue does not give this information. > > In my understanding the only way to retrieve this information is to send a > modify command on the termination to reprogam the detection of event al/on > and al/of. > > What do you think about that ? > Thank-you for your help. > > Regards > Jean-Luc Lecuyer > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Feb 5 17:03:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14879 for ; Thu, 5 Feb 2004 17:03:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoraB-0005Vc-Nw for megaco-archive@odin.ietf.org; Thu, 05 Feb 2004 17:02:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15M2ln5021175 for megaco-archive@odin.ietf.org; Thu, 5 Feb 2004 17:02:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoraB-0005VS-KX for megaco-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 17:02:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14831 for ; Thu, 5 Feb 2004 17:02:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aora9-0000zM-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 17:02:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AorY6-0000gv-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 17:00:38 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AorXD-0000ap-02 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 16:59:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AorSh-0008Dv-Nl for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 16:55:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorSh-0004Y5-3H; Thu, 05 Feb 2004 16:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorRu-0004Up-Nu for megaco@optimus.ietf.org; Thu, 05 Feb 2004 16:54:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14448 for ; Thu, 5 Feb 2004 16:54:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AorRs-0000Ni-00 for megaco@ietf.org; Thu, 05 Feb 2004 16:54:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AorRB-0000Mk-00 for megaco@ietf.org; Thu, 05 Feb 2004 16:53:30 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AorQW-0000JY-00 for megaco@ietf.org; Thu, 05 Feb 2004 16:52:48 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i15LqmYG025715 for ; Thu, 5 Feb 2004 22:52:48 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 22:52:48 +0100 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJ30S5V; Thu, 5 Feb 2004 22:52:47 +0100 Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.140]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1HJMJSZ7; Fri, 6 Feb 2004 08:52:40 +1100 Message-ID: <4022BAB4.2060604@ericsson.com> Date: Fri, 06 Feb 2004 08:50:44 +1100 X-Sybari-Trust: 09a437b0 6b512624 6c3547e6 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jean-Luc.Lecuyer@alcatel.fr CC: megaco@ietf.org Subject: Re: [Megaco] Analog line state References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2004 21:52:48.0163 (UTC) FILETIME=[64E31730:01C3EC32] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Jean-Luc, If you use and Audit the Event Buffer Descriptor you will get the current events active. Otherwise you will have to reset the event using the "strict" parameter. However I would first address an implementation that loses messages... Regards, Christian Jean-Luc.Lecuyer@alcatel.fr wrote: > High all > > Initial state : the MG is programmed to send a notify if a transition > on-hook / off-hook or vice versa happens. > Nevertheless the MGC can miss a transition state from on-hook / off-hook > or vice versa (lost of H248 dialog with the MG) > > I am looking for a way to know the state of a analog line (on-hook / > off-hook). I expected to use the AuditValue on the termination to know it > but unfortunately the AuditValue does not give this information. > > In my understanding the only way to retrieve this information is to send a > modify command on the termination to reprogam the detection of event al/on > and al/of. > > What do you think about that ? > Thank-you for your help. > > Regards > Jean-Luc Lecuyer > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Feb 5 17:03:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15021 for ; Thu, 5 Feb 2004 17:03:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoras-0005ZO-84 for megaco-archive@odin.ietf.org; Thu, 05 Feb 2004 17:03:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15M3U6A021404 for megaco-archive@odin.ietf.org; Thu, 5 Feb 2004 17:03:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoras-0005Z9-4Q for megaco-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 17:03:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14920 for ; Thu, 5 Feb 2004 17:03:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aorap-00016j-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 17:03:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AorYT-0000lk-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 17:01:02 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AorXM-0000ap-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 16:59:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AorNt-00089W-D6 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 16:50:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorNs-0004MG-O9; Thu, 05 Feb 2004 16:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorNH-0004Gz-OA for megaco@optimus.ietf.org; Thu, 05 Feb 2004 16:49:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13770 for ; Thu, 5 Feb 2004 16:49:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AorNE-0007ba-00 for megaco@ietf.org; Thu, 05 Feb 2004 16:49:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AorLX-0007FG-00 for megaco@ietf.org; Thu, 05 Feb 2004 16:47:40 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AorJB-0006m0-00 for megaco@ietf.org; Thu, 05 Feb 2004 16:45:13 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i15LjDYG025246 for ; Thu, 5 Feb 2004 22:45:13 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 22:45:12 +0100 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJS23R8; Thu, 5 Feb 2004 22:45:12 +0100 Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.140]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1HJMJSVC; Fri, 6 Feb 2004 08:45:05 +1100 Message-ID: <4022B8EC.5040105@ericsson.com> Date: Fri, 06 Feb 2004 08:43:08 +1100 X-Sybari-Trust: 9198306c 6b512624 6c3547e6 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dal Chohan CC: megaco@ietf.org Subject: Re: [Megaco] Events Descriptor with KeepActive set and an Emebdded Signals Descriptor References: <008001c3e985$9114d690$403010ac@DALLAPTOP> In-Reply-To: <008001c3e985$9114d690$403010ac@DALLAPTOP> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2004 21:45:12.0958 (UTC) FILETIME=[559051E0:01C3EC31] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Dal, I believe there may be some confusion over which KeepActive is being referred to by the text. Both the EventDescriptor and the signal descriptor can have the keep active flag. This text talks about the EventDescriptor keepactive flag. The reason the text was added was that in the case of an embedded signals descriptor it doesn't make sense to have a keep active flag in the EventDescriptor because the embedded signals descriptor will become active at the detection of event and any existing signals would be subject to the keep active flags in this embedded descriptor. So I believe your scenarios are handled. Regards, Christian Dal Chohan wrote: > H.248v2 clause 7.1.9 states that ; "A media gateway controller shall not > send EventsDescriptors with an event both marked KeepActive and > containing an embedded SignalsDescriptor" > > I think that this is unnecessarily too restrictive and unduly reduces > the flexibility of H.248. The judicious use of the KA flag within the > Embedded Signal descriptor itself can keep the Signal currently being > applied active. > > The following scenario describes a practical situation where the above > rule is violate. Take the case where "Automatic Metering" is applied to > an analogue line and automatic meter pulses are being generated by the > MG. Now the MG is monitoring for "On-Hook" and the KA (KeepActive) flag > is sent against the "On-Hook" event. Upon detection of "On-Hook" the > event is reported to the MGC by the MG and the automatic metering still > continues. > > Now the MGC sends a command requesting that the MG monitor for > "Off-Hook" with the KA flag set, plus an Embedded > signals/event descriptor indicating that "dial tone" should be played. > In addition the KA flag is set for the "enable metering" signal to > ensure that the automatic metering continues when the dial tone signal > is applied , and the digit map descriptor is also enabled. Now this > sequence clearly violates the rule stated above. > > I would therefore recommend that the sentence above is deleted from the > specification unless someone can think off a good reason for keeping it, > because it is unnecessarily too restrictive and reduces the flexibility > of the H.248 protocol. > > > > > Regards. > > > Dal Chohan This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Feb 5 17:27:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16467 for ; Thu, 5 Feb 2004 17:27:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aorxd-0008EZ-6l; Thu, 05 Feb 2004 17:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aorwr-0008Dw-Ec for megaco@optimus.ietf.org; Thu, 05 Feb 2004 17:26:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16404 for ; Thu, 5 Feb 2004 17:26:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aorwp-0002SJ-00 for megaco@ietf.org; Thu, 05 Feb 2004 17:26:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aorvt-0002RE-00 for megaco@ietf.org; Thu, 05 Feb 2004 17:25:14 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1Aoruw-0002QA-00 for megaco@ietf.org; Thu, 05 Feb 2004 17:24:14 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i15MOEAh000998 for ; Thu, 5 Feb 2004 23:24:14 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 23:24:13 +0100 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJS2VM2; Thu, 5 Feb 2004 23:24:13 +0100 Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.140]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1HJMJTN6; Fri, 6 Feb 2004 09:24:05 +1100 Message-ID: <4022C205.3060803@ericsson.com> Date: Fri, 06 Feb 2004 09:21:57 +1100 X-Sybari-Trust: 4b7bdd7a 6b512624 6c3547e6 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco ietf Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2004 22:24:13.0987 (UTC) FILETIME=[C8ECFF30:01C3EC36] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,USERPASS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Megaco] Results of ITU-T SG16 Sender: megaco-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 All, In my capacity as ITU-T Q.3 Rapporteur i'd like to inform you of the output of the January SG16 meeting. The Q.3 meeting report can be found contained in the Working Party 2 report at: http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/Output_docs/WP2_report_040130.zip The various editor's output drafts for: H.248 Subseries Implementors' Guide H.248.1 Version 1 Implementors' Guide H.248.1 Version 2 Corrigendum 1 H.248.3 Corrigendum 1 H.248.4 Corrigendum 1 H.248.7 Corrigendum 1 H.248.8 Amendment 1 H.248.16 Corrigendum 1 H.248.17 Corrigendum 1 New H.248.19: MCU Composition Package New H.248.21: Semi-permanent Connection Package H.248.23 Corrigendum 1 H.248.25 Corrigendum 1 H.248.26 Corrigendum 1 New H.248.28: ICAS New H.248.30: RTCPXR New H.248.31: Adaptive Jitter Buffer (AJB) H Series Supplement 2: Packages Guide Release 5 can be found at: http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/Output_docs/ The documents are currently being uploaded so please check again if the document is not on the site. The Password for the sites is: Avguest ***Please note: Many of these documents are subject to a Last Call process which may result in changes. They are also subject to a publishing process so they may also be editorially changed. Use with this in mind. I was also decided by the meeting that the H.248.1 Version 1 Implementors Guide will only be maintained until the time H.248.1v3 is approved (Late 2004->Mid-2005). No work will occur documenting errors in v1. v2 errors/clarifications will be document. This was to encourage people to move to v2 and v3. Regards, Christian This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Feb 5 17:28:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16524 for ; Thu, 5 Feb 2004 17:28:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoryt-0008IA-3g for megaco-archive@odin.ietf.org; Thu, 05 Feb 2004 17:28:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15MSJFW031873 for megaco-archive@odin.ietf.org; Thu, 5 Feb 2004 17:28:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aorys-0008I0-Vp for megaco-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 17:28:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16503 for ; Thu, 5 Feb 2004 17:28:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoryq-0002XR-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 17:28:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aorxt-0002VD-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 17:27:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aorxc-0002TN-00 for megaco-web-archive@ietf.org; Thu, 05 Feb 2004 17:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aorxd-0008EZ-6l; Thu, 05 Feb 2004 17:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aorwr-0008Dw-Ec for megaco@optimus.ietf.org; Thu, 05 Feb 2004 17:26:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16404 for ; Thu, 5 Feb 2004 17:26:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aorwp-0002SJ-00 for megaco@ietf.org; Thu, 05 Feb 2004 17:26:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aorvt-0002RE-00 for megaco@ietf.org; Thu, 05 Feb 2004 17:25:14 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1Aoruw-0002QA-00 for megaco@ietf.org; Thu, 05 Feb 2004 17:24:14 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i15MOEAh000998 for ; Thu, 5 Feb 2004 23:24:14 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 23:24:13 +0100 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJS2VM2; Thu, 5 Feb 2004 23:24:13 +0100 Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.140]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1HJMJTN6; Fri, 6 Feb 2004 09:24:05 +1100 Message-ID: <4022C205.3060803@ericsson.com> Date: Fri, 06 Feb 2004 09:21:57 +1100 X-Sybari-Trust: 4b7bdd7a 6b512624 6c3547e6 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco ietf Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2004 22:24:13.0987 (UTC) FILETIME=[C8ECFF30:01C3EC36] Content-Transfer-Encoding: 7bit Subject: [Megaco] Results of ITU-T SG16 Sender: megaco-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,USERPASS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello All, In my capacity as ITU-T Q.3 Rapporteur i'd like to inform you of the output of the January SG16 meeting. The Q.3 meeting report can be found contained in the Working Party 2 report at: http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/Output_docs/WP2_report_040130.zip The various editor's output drafts for: H.248 Subseries Implementors' Guide H.248.1 Version 1 Implementors' Guide H.248.1 Version 2 Corrigendum 1 H.248.3 Corrigendum 1 H.248.4 Corrigendum 1 H.248.7 Corrigendum 1 H.248.8 Amendment 1 H.248.16 Corrigendum 1 H.248.17 Corrigendum 1 New H.248.19: MCU Composition Package New H.248.21: Semi-permanent Connection Package H.248.23 Corrigendum 1 H.248.25 Corrigendum 1 H.248.26 Corrigendum 1 New H.248.28: ICAS New H.248.30: RTCPXR New H.248.31: Adaptive Jitter Buffer (AJB) H Series Supplement 2: Packages Guide Release 5 can be found at: http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/Output_docs/ The documents are currently being uploaded so please check again if the document is not on the site. The Password for the sites is: Avguest ***Please note: Many of these documents are subject to a Last Call process which may result in changes. They are also subject to a publishing process so they may also be editorially changed. Use with this in mind. I was also decided by the meeting that the H.248.1 Version 1 Implementors Guide will only be maintained until the time H.248.1v3 is approved (Late 2004->Mid-2005). No work will occur documenting errors in v1. v2 errors/clarifications will be document. This was to encourage people to move to v2 and v3. Regards, Christian This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Feb 6 11:54:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04007 for ; Fri, 6 Feb 2004 11:54:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9Ev-0001Hx-IK; Fri, 06 Feb 2004 11:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9Ei-0001HP-4z for megaco@optimus.ietf.org; Fri, 06 Feb 2004 11:53:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03991 for ; Fri, 6 Feb 2004 11:53:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap9Eg-00023C-00 for megaco@ietf.org; Fri, 06 Feb 2004 11:53:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap9Dj-000204-00 for megaco@ietf.org; Fri, 06 Feb 2004 11:52:48 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1Ap9Cp-0001wT-00 for megaco@ietf.org; Fri, 06 Feb 2004 11:51:52 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i16GoHcw006006; Fri, 6 Feb 2004 09:50:17 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i16GlnWK013950; Fri, 6 Feb 2004 10:48:02 -0600 Message-Id: <5.2.1.1.0.20040206113839.01e04830@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 06 Feb 2004 11:47:32 -0500 To: , megaco@ietf.org From: Aleksandr Ryabin Subject: RE: [Megaco] Query Related to Automatic Metering Cc: "'Tom Taylor'", "'Kevin Boyle'" In-Reply-To: <000801c3ec91$941f5400$210110ac@SAMPATHKW2K03> References: <3FE72151.8050301@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Sender: megaco-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: , Sampath, metd already adheres to that way as described in its "KeepActive and EventbufferControl Procedures." Regards, Aleks >From: "Sampath Komanduri" >To: "'Tom Taylor'", > "'Kevin Boyle'", > "'Aleksandr Ryabin'" >Subject: RE: [Megaco] Query Related to Automatic Metering >Date: Fri, 6 Feb 2004 01:14:07 -0800 > >Hi Kevin/Aleks, >Is my understanding correct that we are going to change the AMET and METD >package procedures to reflect the issue raised by gsachin and agreed by Tom? >Pls. let me know. >Thanks, >Sampath > >-----Original Message----- >From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of Tom >Taylor >Sent: Monday, December 22, 2003 8:53 AM >Cc: megaco@ietf.org >Subject: Re: [Megaco] Query Related to Automatic Metering > > >I think you make a good point. It's desirable to keep the protocol >intact, rather than define exceptions within individual packages. > >gsachin wrote: > > > > > > > > > Hi List, > > > > > > this is a query regarding Periodic report event 'pr' defined in AMET > > package .the package procedure says that > > > > "the detection of event pr shall not cause the termination of the > > signal em or signal mbp, even if the KeppActive(KA) flag is not set > > for the pr event" > > > > what i feel is that the detection of the 'pr' event shall not cause > > the termination of any of the signals. > > > > pls tell me if this is a correct assumption? > > > > if yes, then i think here the package procedures should have mandated > > the use of KA flag with this event. Doing this will keep the protocol > > rules intact. > > > > > > > > Regards > > Sachin Gupta _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Feb 6 11:56:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04123 for ; Fri, 6 Feb 2004 11:56:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9Gh-0001aJ-0S for megaco-archive@odin.ietf.org; Fri, 06 Feb 2004 11:55:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16Gtox8006090 for megaco-archive@odin.ietf.org; Fri, 6 Feb 2004 11:55:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9Gg-0001a9-T4 for megaco-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 11:55:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04109 for ; Fri, 6 Feb 2004 11:55:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap9Gf-0002AI-00 for megaco-web-archive@ietf.org; Fri, 06 Feb 2004 11:55:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap9Fl-00027g-00 for megaco-web-archive@ietf.org; Fri, 06 Feb 2004 11:54:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap9Ev-00024l-00 for megaco-web-archive@ietf.org; Fri, 06 Feb 2004 11:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9Ev-0001Hx-IK; Fri, 06 Feb 2004 11:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9Ei-0001HP-4z for megaco@optimus.ietf.org; Fri, 06 Feb 2004 11:53:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03991 for ; Fri, 6 Feb 2004 11:53:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap9Eg-00023C-00 for megaco@ietf.org; Fri, 06 Feb 2004 11:53:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap9Dj-000204-00 for megaco@ietf.org; Fri, 06 Feb 2004 11:52:48 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1Ap9Cp-0001wT-00 for megaco@ietf.org; Fri, 06 Feb 2004 11:51:52 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i16GoHcw006006; Fri, 6 Feb 2004 09:50:17 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i16GlnWK013950; Fri, 6 Feb 2004 10:48:02 -0600 Message-Id: <5.2.1.1.0.20040206113839.01e04830@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 06 Feb 2004 11:47:32 -0500 To: , megaco@ietf.org From: Aleksandr Ryabin Subject: RE: [Megaco] Query Related to Automatic Metering Cc: "'Tom Taylor'", "'Kevin Boyle'" In-Reply-To: <000801c3ec91$941f5400$210110ac@SAMPATHKW2K03> References: <3FE72151.8050301@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: megaco-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Sampath, metd already adheres to that way as described in its "KeepActive and EventbufferControl Procedures." Regards, Aleks >From: "Sampath Komanduri" >To: "'Tom Taylor'", > "'Kevin Boyle'", > "'Aleksandr Ryabin'" >Subject: RE: [Megaco] Query Related to Automatic Metering >Date: Fri, 6 Feb 2004 01:14:07 -0800 > >Hi Kevin/Aleks, >Is my understanding correct that we are going to change the AMET and METD >package procedures to reflect the issue raised by gsachin and agreed by Tom? >Pls. let me know. >Thanks, >Sampath > >-----Original Message----- >From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of Tom >Taylor >Sent: Monday, December 22, 2003 8:53 AM >Cc: megaco@ietf.org >Subject: Re: [Megaco] Query Related to Automatic Metering > > >I think you make a good point. It's desirable to keep the protocol >intact, rather than define exceptions within individual packages. > >gsachin wrote: > > > > > > > > > Hi List, > > > > > > this is a query regarding Periodic report event 'pr' defined in AMET > > package .the package procedure says that > > > > "the detection of event pr shall not cause the termination of the > > signal em or signal mbp, even if the KeppActive(KA) flag is not set > > for the pr event" > > > > what i feel is that the detection of the 'pr' event shall not cause > > the termination of any of the signals. > > > > pls tell me if this is a correct assumption? > > > > if yes, then i think here the package procedures should have mandated > > the use of KA flag with this event. Doing this will keep the protocol > > rules intact. > > > > > > > > Regards > > Sachin Gupta _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Sat Feb 7 19:55:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19865 for ; Sat, 7 Feb 2004 19:55:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApdDy-0000Dd-Lw; Sat, 07 Feb 2004 19:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHu7-0000i3-VK for megaco@optimus.ietf.org; Fri, 06 Feb 2004 21:09:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04496 for ; Fri, 6 Feb 2004 21:09:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApHu5-00060F-00 for megaco@ietf.org; Fri, 06 Feb 2004 21:09:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApHtB-0005xF-00 for megaco@ietf.org; Fri, 06 Feb 2004 21:08:10 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ApHsI-0005qo-00 for megaco@ietf.org; Fri, 06 Feb 2004 21:07:14 -0500 Received: from MUSHARMAW2K1 (shiau-nt2.cisco.com [171.71.9.42]) by sj-core-4.cisco.com (8.12.6/8.12.6) with SMTP id i1726fpp011411; Fri, 6 Feb 2004 18:06:41 -0800 (PST) From: "Sachin Gupta" To: "Aleksandr Ryabin" , , Cc: "'Tom Taylor'" , "'Kevin Boyle'" Subject: RE: [Megaco] Query Related to Automatic Metering Date: Fri, 6 Feb 2004 18:06:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <5.2.1.1.0.20040206113839.01e04830@IL06EXM13.corp.mot.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Aleks, The "KeepActive and EventbufferControl Procedures." in the metd package does not mandate the use of KeepActive(KA) flag. In case MGC comes with "metering pulse detection" event without KA Flag then what should be MGs behaviour? A) Should it do the normal processing (i.e stop all signals), as mentioned in the base protocol, when this event is detected? B) Should it report an error for the command request? C) Should it do the processing as if KA flag is there, even though call agent has not specified it? Do we have any scenarios where detection of this event may require stopping of currently applied signals? If not, then shouldn't the use of KA be mandated? Pls clarify. Thanks Sachin gupta -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Aleksandr Ryabin Sent: Friday, February 06, 2004 8:48 AM To: sampathk@cisco.com; megaco@ietf.org Cc: 'Tom Taylor'; 'Kevin Boyle' Subject: RE: [Megaco] Query Related to Automatic Metering Sampath, metd already adheres to that way as described in its "KeepActive and EventbufferControl Procedures." Regards, Aleks >From: "Sampath Komanduri" >To: "'Tom Taylor'", > "'Kevin Boyle'", > "'Aleksandr Ryabin'" >Subject: RE: [Megaco] Query Related to Automatic Metering >Date: Fri, 6 Feb 2004 01:14:07 -0800 > >Hi Kevin/Aleks, >Is my understanding correct that we are going to change the AMET and METD >package procedures to reflect the issue raised by gsachin and agreed by Tom? >Pls. let me know. >Thanks, >Sampath > >-----Original Message----- >From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of Tom >Taylor >Sent: Monday, December 22, 2003 8:53 AM >Cc: megaco@ietf.org >Subject: Re: [Megaco] Query Related to Automatic Metering > > >I think you make a good point. It's desirable to keep the protocol >intact, rather than define exceptions within individual packages. > >gsachin wrote: > > > > > > > > > Hi List, > > > > > > this is a query regarding Periodic report event 'pr' defined in AMET > > package .the package procedure says that > > > > "the detection of event pr shall not cause the termination of the > > signal em or signal mbp, even if the KeppActive(KA) flag is not set > > for the pr event" > > > > what i feel is that the detection of the 'pr' event shall not cause > > the termination of any of the signals. > > > > pls tell me if this is a correct assumption? > > > > if yes, then i think here the package procedures should have mandated > > the use of KA flag with this event. Doing this will keep the protocol > > rules intact. > > > > > > > > Regards > > Sachin Gupta _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Sat Feb 7 19:57:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19904 for ; Sat, 7 Feb 2004 19:57:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApdFj-0000L6-1g for megaco-archive@odin.ietf.org; Sat, 07 Feb 2004 19:56:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i180up2D001298 for megaco-archive@odin.ietf.org; Sat, 7 Feb 2004 19:56:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApdFi-0000Kr-Tf for megaco-web-archive@optimus.ietf.org; Sat, 07 Feb 2004 19:56:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19895 for ; Sat, 7 Feb 2004 19:56:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApdFh-0006fy-00 for megaco-web-archive@ietf.org; Sat, 07 Feb 2004 19:56:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApdEi-0006cC-00 for megaco-web-archive@ietf.org; Sat, 07 Feb 2004 19:55:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApdDz-0006Z2-00 for megaco-web-archive@ietf.org; Sat, 07 Feb 2004 19:55:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApdDy-0000Dd-Lw; Sat, 07 Feb 2004 19:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHu7-0000i3-VK for megaco@optimus.ietf.org; Fri, 06 Feb 2004 21:09:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04496 for ; Fri, 6 Feb 2004 21:09:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApHu5-00060F-00 for megaco@ietf.org; Fri, 06 Feb 2004 21:09:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApHtB-0005xF-00 for megaco@ietf.org; Fri, 06 Feb 2004 21:08:10 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ApHsI-0005qo-00 for megaco@ietf.org; Fri, 06 Feb 2004 21:07:14 -0500 Received: from MUSHARMAW2K1 (shiau-nt2.cisco.com [171.71.9.42]) by sj-core-4.cisco.com (8.12.6/8.12.6) with SMTP id i1726fpp011411; Fri, 6 Feb 2004 18:06:41 -0800 (PST) From: "Sachin Gupta" To: "Aleksandr Ryabin" , , Cc: "'Tom Taylor'" , "'Kevin Boyle'" Subject: RE: [Megaco] Query Related to Automatic Metering Date: Fri, 6 Feb 2004 18:06:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <5.2.1.1.0.20040206113839.01e04830@IL06EXM13.corp.mot.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Aleks, The "KeepActive and EventbufferControl Procedures." in the metd package does not mandate the use of KeepActive(KA) flag. In case MGC comes with "metering pulse detection" event without KA Flag then what should be MGs behaviour? A) Should it do the normal processing (i.e stop all signals), as mentioned in the base protocol, when this event is detected? B) Should it report an error for the command request? C) Should it do the processing as if KA flag is there, even though call agent has not specified it? Do we have any scenarios where detection of this event may require stopping of currently applied signals? If not, then shouldn't the use of KA be mandated? Pls clarify. Thanks Sachin gupta -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Aleksandr Ryabin Sent: Friday, February 06, 2004 8:48 AM To: sampathk@cisco.com; megaco@ietf.org Cc: 'Tom Taylor'; 'Kevin Boyle' Subject: RE: [Megaco] Query Related to Automatic Metering Sampath, metd already adheres to that way as described in its "KeepActive and EventbufferControl Procedures." Regards, Aleks >From: "Sampath Komanduri" >To: "'Tom Taylor'", > "'Kevin Boyle'", > "'Aleksandr Ryabin'" >Subject: RE: [Megaco] Query Related to Automatic Metering >Date: Fri, 6 Feb 2004 01:14:07 -0800 > >Hi Kevin/Aleks, >Is my understanding correct that we are going to change the AMET and METD >package procedures to reflect the issue raised by gsachin and agreed by Tom? >Pls. let me know. >Thanks, >Sampath > >-----Original Message----- >From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of Tom >Taylor >Sent: Monday, December 22, 2003 8:53 AM >Cc: megaco@ietf.org >Subject: Re: [Megaco] Query Related to Automatic Metering > > >I think you make a good point. It's desirable to keep the protocol >intact, rather than define exceptions within individual packages. > >gsachin wrote: > > > > > > > > > Hi List, > > > > > > this is a query regarding Periodic report event 'pr' defined in AMET > > package .the package procedure says that > > > > "the detection of event pr shall not cause the termination of the > > signal em or signal mbp, even if the KeppActive(KA) flag is not set > > for the pr event" > > > > what i feel is that the detection of the 'pr' event shall not cause > > the termination of any of the signals. > > > > pls tell me if this is a correct assumption? > > > > if yes, then i think here the package procedures should have mandated > > the use of KA flag with this event. Doing this will keep the protocol > > rules intact. > > > > > > > > Regards > > Sachin Gupta _______________________________________________ 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 Sun Feb 8 05:37:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14960 for ; Sun, 8 Feb 2004 05:37:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApmJB-0000x8-Ut; Sun, 08 Feb 2004 05:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApmIN-0000qr-Ki for megaco@optimus.ietf.org; Sun, 08 Feb 2004 05:36:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14932 for ; Sun, 8 Feb 2004 05:36:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApmIK-0001qk-00 for megaco@ietf.org; Sun, 08 Feb 2004 05:36:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApmHO-0001nT-00 for megaco@ietf.org; Sun, 08 Feb 2004 05:35:11 -0500 Received: from bzq-179-22-133.cust.bezeqint.net ([212.179.22.133] helo=lodmsg01.corp.audiocodes.com) by ietf-mx with esmtp (Exim 4.12) id 1ApmGy-0001hz-00 for megaco@ietf.org; Sun, 08 Feb 2004 05:34:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Feb 2004 12:32:05 +0200 Message-ID: <14B7C5B03853404495D29CFA4A54B21C5117B4@lodmsg01.corp.audiocodes.com> Thread-Topic: Contradiction in signal ID between H.248.24 and Q.1950 Thread-Index: AcPsLc3ltkZ1Lq//SICYUry1ikS6DAB/+yfQ From: "Nurit Shenhar" To: "Christian Groves" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Megaco] RE: Contradiction in signal ID between H.248.24 and Q.1950 Sender: megaco-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: quoted-printable Hi Christian What about the tonegen/pt signal? I thought up to now that you may specify a list of tones in the format: Tonegen/pt{tl=3D{cg, d0, d1, roh}} And so mix some tones in a single signal. Is it not the case? If this format is allowed, than I have a problem with the overlapping when using the ASN.1 format. Nurit -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com]=20 Sent: Thursday, February 05, 2004 11:20 PM To: Nurit Shenhar Cc: megaco@ietf.org Subject: Re: Contradiction in signal ID between H.248.24 and Q.1950 Hello Nurit, These do not need to be unique because when you reference a signal the=20 formulation is PackageID/ToneID. The packageID means that the toneid is unique.=20 You cannot use the Original (extended packageID) to reference the tones in the=20 new package. Or have I missed something in your question? Regards, Christian Nurit Shenhar wrote: > Hi Christian >=20 > =20 >=20 > Can you forward this mail for me to the list? (Or answer it yourself)? > Somehow my mails don't get to the list. I sent a mail to Tom Taylor, but=20 > got no response. >=20 > =20 >=20 > =20 >=20 > The tone IDs in the MF generation package H.248.24 are defined as 0x0050=20 > and up. In the Q.1950 package Basic Service Tones Generation ('srvtn') > and the following packages, the signals start from 0x004f. That results=20 > in non-unique numbers. As both packages inherit from the basic tones=20 > generation package 'tonegen', I think they should be unique. >=20 > =20 >=20 > Thanks, >=20 > =20 >=20 > =20 >=20 > Nurit Shenhar >=20 > H.248/MEGACO Architect >=20 > =20 >=20 > E-Mail: nurit.shenhar@audiocodes.com >=20 > Fax. +972-3-5394223 >=20 > www.audiocodes.com >=20 > =20 >=20 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Sun Feb 8 05:54:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15507 for ; Sun, 8 Feb 2004 05:54:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApmZf-0001fw-Cl for megaco-archive@odin.ietf.org; Sun, 08 Feb 2004 05:54:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18As3RX006434 for megaco-archive@odin.ietf.org; Sun, 8 Feb 2004 05:54:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApmZf-0001fh-4i for megaco-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 05:54:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15338 for ; Sun, 8 Feb 2004 05:53:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApmZb-0003Ka-00 for megaco-web-archive@ietf.org; Sun, 08 Feb 2004 05:53:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApmXj-0002w7-00 for megaco-web-archive@ietf.org; Sun, 08 Feb 2004 05:52:04 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ApmWa-0002km-03 for megaco-web-archive@ietf.org; Sun, 08 Feb 2004 05:50:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1ApmJE-0001wO-Ky for megaco-web-archive@ietf.org; Sun, 08 Feb 2004 05:37:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApmJB-0000x8-Ut; Sun, 08 Feb 2004 05:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApmIN-0000qr-Ki for megaco@optimus.ietf.org; Sun, 08 Feb 2004 05:36:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14932 for ; Sun, 8 Feb 2004 05:36:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApmIK-0001qk-00 for megaco@ietf.org; Sun, 08 Feb 2004 05:36:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApmHO-0001nT-00 for megaco@ietf.org; Sun, 08 Feb 2004 05:35:11 -0500 Received: from bzq-179-22-133.cust.bezeqint.net ([212.179.22.133] helo=lodmsg01.corp.audiocodes.com) by ietf-mx with esmtp (Exim 4.12) id 1ApmGy-0001hz-00 for megaco@ietf.org; Sun, 08 Feb 2004 05:34:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Feb 2004 12:32:05 +0200 Message-ID: <14B7C5B03853404495D29CFA4A54B21C5117B4@lodmsg01.corp.audiocodes.com> Thread-Topic: Contradiction in signal ID between H.248.24 and Q.1950 Thread-Index: AcPsLc3ltkZ1Lq//SICYUry1ikS6DAB/+yfQ From: "Nurit Shenhar" To: "Christian Groves" Cc: Content-Transfer-Encoding: quoted-printable Subject: [Megaco] RE: Contradiction in signal ID between H.248.24 and Q.1950 Sender: megaco-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Christian What about the tonegen/pt signal? I thought up to now that you may specify a list of tones in the format: Tonegen/pt{tl=3D{cg, d0, d1, roh}} And so mix some tones in a single signal. Is it not the case? If this format is allowed, than I have a problem with the overlapping when using the ASN.1 format. Nurit -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com]=20 Sent: Thursday, February 05, 2004 11:20 PM To: Nurit Shenhar Cc: megaco@ietf.org Subject: Re: Contradiction in signal ID between H.248.24 and Q.1950 Hello Nurit, These do not need to be unique because when you reference a signal the=20 formulation is PackageID/ToneID. The packageID means that the toneid is unique.=20 You cannot use the Original (extended packageID) to reference the tones in the=20 new package. Or have I missed something in your question? Regards, Christian Nurit Shenhar wrote: > Hi Christian >=20 > =20 >=20 > Can you forward this mail for me to the list? (Or answer it yourself)? > Somehow my mails don't get to the list. I sent a mail to Tom Taylor, but=20 > got no response. >=20 > =20 >=20 > =20 >=20 > The tone IDs in the MF generation package H.248.24 are defined as 0x0050=20 > and up. In the Q.1950 package Basic Service Tones Generation ('srvtn') > and the following packages, the signals start from 0x004f. That results=20 > in non-unique numbers. As both packages inherit from the basic tones=20 > generation package 'tonegen', I think they should be unique. >=20 > =20 >=20 > Thanks, >=20 > =20 >=20 > =20 >=20 > Nurit Shenhar >=20 > H.248/MEGACO Architect >=20 > =20 >=20 > E-Mail: nurit.shenhar@audiocodes.com >=20 > Fax. +972-3-5394223 >=20 > www.audiocodes.com >=20 > =20 >=20 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Sun Feb 8 17:36:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05090 for ; Sun, 8 Feb 2004 17:36:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApxWz-0008Ee-Iz; Sun, 08 Feb 2004 17:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApxWW-0008E5-JG for megaco@optimus.ietf.org; Sun, 08 Feb 2004 17:35:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05082 for ; Sun, 8 Feb 2004 17:35:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApxWU-0000Be-00 for megaco@ietf.org; Sun, 08 Feb 2004 17:35:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApxVY-00007s-00 for megaco@ietf.org; Sun, 08 Feb 2004 17:34:32 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ApxUg-00004F-00 for megaco@ietf.org; Sun, 08 Feb 2004 17:33:38 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i18MXbqY022120 for ; Sun, 8 Feb 2004 23:33:37 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sun, 8 Feb 2004 23:33:37 +0100 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJSTX74; Sun, 8 Feb 2004 23:34:00 +0100 Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.193]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1MYMBZ0T; Mon, 9 Feb 2004 09:33:21 +1100 Message-ID: <4026B8A6.60808@ericsson.com> Date: Mon, 09 Feb 2004 09:31:02 +1100 X-Sybari-Trust: 17b2a8b8 6b512624 7e80e808 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nurit Shenhar CC: megaco@ietf.org References: <14B7C5B03853404495D29CFA4A54B21C5117B4@lodmsg01.corp.audiocodes.com> In-Reply-To: <14B7C5B03853404495D29CFA4A54B21C5117B4@lodmsg01.corp.audiocodes.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Feb 2004 22:33:37.0788 (UTC) FILETIME=[983773C0:01C3EE93] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Megaco] Re: Contradiction in signal ID between H.248.24 and Q.1950 Sender: megaco-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 Nurit, You can't use the old package name to reference the signals in a new package. However you can use the new package name to refer to the new and old signals. Regards, Christian Nurit Shenhar wrote: > Hi Christian > > What about the tonegen/pt signal? I thought up to now that you may > specify a list of tones in the format: > > Tonegen/pt{tl={cg, d0, d1, roh}} > > And so mix some tones in a single signal. Is it not the case? If this > format is allowed, than I have a problem with the overlapping when using > the ASN.1 format. > > Nurit > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > Sent: Thursday, February 05, 2004 11:20 PM > To: Nurit Shenhar > Cc: megaco@ietf.org > Subject: Re: Contradiction in signal ID between H.248.24 and Q.1950 > > Hello Nurit, > > These do not need to be unique because when you reference a signal the > formulation is PackageID/ToneID. The packageID means that the toneid is > unique. > You cannot use the Original (extended packageID) to reference the tones > in the > new package. Or have I missed something in your question? > > Regards, Christian > > Nurit Shenhar wrote: > > >>Hi Christian >> >> >> >>Can you forward this mail for me to the list? (Or answer it yourself)? > > >>Somehow my mails don't get to the list. I sent a mail to Tom Taylor, > > but > >>got no response. >> >> >> >> >> >>The tone IDs in the MF generation package H.248.24 are defined as > > 0x0050 > >>and up. In the Q.1950 package Basic Service Tones Generation ('srvtn') > > >>and the following packages, the signals start from 0x004f. That > > results > >>in non-unique numbers. As both packages inherit from the basic tones >>generation package 'tonegen', I think they should be unique. >> >> >> >>Thanks, >> >> >> >> >> >>Nurit Shenhar >> >>H.248/MEGACO Architect >> >> >> >>E-Mail: nurit.shenhar@audiocodes.com >> >>Fax. +972-3-5394223 >> >>www.audiocodes.com >> >> >> > > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in > error, please notify the sender by replying to this transmission and > delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and we only > send and receive e-mails on the basis that we are not liable for any > such corruption, interception, amendment, tampering or viruses or any > consequences thereof. > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Sun Feb 8 17:38:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05135 for ; Sun, 8 Feb 2004 17:38:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApxYW-0008WS-CX for megaco-archive@odin.ietf.org; Sun, 08 Feb 2004 17:37:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18Mba5x032759 for megaco-archive@odin.ietf.org; Sun, 8 Feb 2004 17:37:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApxYV-0008WI-Tb for megaco-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 17:37:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05125 for ; Sun, 8 Feb 2004 17:37:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApxYT-0000KX-00 for megaco-web-archive@ietf.org; Sun, 08 Feb 2004 17:37:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApxXb-0000GQ-00 for megaco-web-archive@ietf.org; Sun, 08 Feb 2004 17:36:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApxWz-0000Cc-00 for megaco-web-archive@ietf.org; Sun, 08 Feb 2004 17:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApxWz-0008Ee-Iz; Sun, 08 Feb 2004 17:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApxWW-0008E5-JG for megaco@optimus.ietf.org; Sun, 08 Feb 2004 17:35:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05082 for ; Sun, 8 Feb 2004 17:35:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApxWU-0000Be-00 for megaco@ietf.org; Sun, 08 Feb 2004 17:35:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApxVY-00007s-00 for megaco@ietf.org; Sun, 08 Feb 2004 17:34:32 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ApxUg-00004F-00 for megaco@ietf.org; Sun, 08 Feb 2004 17:33:38 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i18MXbqY022120 for ; Sun, 8 Feb 2004 23:33:37 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sun, 8 Feb 2004 23:33:37 +0100 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJSTX74; Sun, 8 Feb 2004 23:34:00 +0100 Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.193]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1MYMBZ0T; Mon, 9 Feb 2004 09:33:21 +1100 Message-ID: <4026B8A6.60808@ericsson.com> Date: Mon, 09 Feb 2004 09:31:02 +1100 X-Sybari-Trust: 17b2a8b8 6b512624 7e80e808 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nurit Shenhar CC: megaco@ietf.org References: <14B7C5B03853404495D29CFA4A54B21C5117B4@lodmsg01.corp.audiocodes.com> In-Reply-To: <14B7C5B03853404495D29CFA4A54B21C5117B4@lodmsg01.corp.audiocodes.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Feb 2004 22:33:37.0788 (UTC) FILETIME=[983773C0:01C3EE93] Content-Transfer-Encoding: 7bit Subject: [Megaco] Re: Contradiction in signal ID between H.248.24 and Q.1950 Sender: megaco-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Nurit, You can't use the old package name to reference the signals in a new package. However you can use the new package name to refer to the new and old signals. Regards, Christian Nurit Shenhar wrote: > Hi Christian > > What about the tonegen/pt signal? I thought up to now that you may > specify a list of tones in the format: > > Tonegen/pt{tl={cg, d0, d1, roh}} > > And so mix some tones in a single signal. Is it not the case? If this > format is allowed, than I have a problem with the overlapping when using > the ASN.1 format. > > Nurit > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > Sent: Thursday, February 05, 2004 11:20 PM > To: Nurit Shenhar > Cc: megaco@ietf.org > Subject: Re: Contradiction in signal ID between H.248.24 and Q.1950 > > Hello Nurit, > > These do not need to be unique because when you reference a signal the > formulation is PackageID/ToneID. The packageID means that the toneid is > unique. > You cannot use the Original (extended packageID) to reference the tones > in the > new package. Or have I missed something in your question? > > Regards, Christian > > Nurit Shenhar wrote: > > >>Hi Christian >> >> >> >>Can you forward this mail for me to the list? (Or answer it yourself)? > > >>Somehow my mails don't get to the list. I sent a mail to Tom Taylor, > > but > >>got no response. >> >> >> >> >> >>The tone IDs in the MF generation package H.248.24 are defined as > > 0x0050 > >>and up. In the Q.1950 package Basic Service Tones Generation ('srvtn') > > >>and the following packages, the signals start from 0x004f. That > > results > >>in non-unique numbers. As both packages inherit from the basic tones >>generation package 'tonegen', I think they should be unique. >> >> >> >>Thanks, >> >> >> >> >> >>Nurit Shenhar >> >>H.248/MEGACO Architect >> >> >> >>E-Mail: nurit.shenhar@audiocodes.com >> >>Fax. +972-3-5394223 >> >>www.audiocodes.com >> >> >> > > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in > error, please notify the sender by replying to this transmission and > delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and we only > send and receive e-mails on the basis that we are not liable for any > such corruption, interception, amendment, tampering or viruses or any > consequences thereof. > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 9 09:45:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21644 for ; Mon, 9 Feb 2004 09:45:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCel-0006eu-A7; Mon, 09 Feb 2004 09:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCdw-0006XX-6h for megaco@optimus.ietf.org; Mon, 09 Feb 2004 09:44:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21589 for ; Mon, 9 Feb 2004 09:44:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqCdu-0004jW-00 for megaco@ietf.org; Mon, 09 Feb 2004 09:44:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqCcw-0004dt-00 for megaco@ietf.org; Mon, 09 Feb 2004 09:43:11 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AqCbz-0004Yw-00 for megaco@ietf.org; Mon, 09 Feb 2004 09:42:11 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i19EfWAH016841; Mon, 9 Feb 2004 07:41:42 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i19EeC4n004617; Mon, 9 Feb 2004 08:40:13 -0600 Message-Id: <5.2.1.1.0.20040209092402.05202c98@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 09 Feb 2004 09:39:43 -0500 To: "Sachin Gupta", From: Aleksandr Ryabin Subject: RE: [Megaco] Query Related to Automatic Metering In-Reply-To: References: <5.2.1.1.0.20040206113839.01e04830@IL06EXM13.corp.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Sachin Gupta, A) The package definition should not really care ether there are such cases, or not. It is up to MGC to control and direct MG on how exactly MGC wants MG to behave. That is if it wants it for whatever reason terminate all signals on detection of the event then it will not provide KA. Regards, Aleks At 09:06 PM 2/6/2004, Sachin Gupta wrote: >Aleks, >The "KeepActive and EventbufferControl Procedures." in the metd package does >not mandate the use of KeepActive(KA) flag. > >In case MGC comes with "metering pulse detection" event without KA Flag then >what should be MGs behaviour? > >A) Should it do the normal processing (i.e stop all signals), as mentioned >in the base protocol, when this event is detected? >B) Should it report an error for the command request? >C) Should it do the processing as if KA flag is there, even though call >agent has not specified it? > >Do we have any scenarios where detection of this event may require stopping >of currently applied signals? If not, then shouldn't the use of KA be >mandated? > > >Pls clarify. > >Thanks >Sachin gupta > >-----Original Message----- >From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of >Aleksandr Ryabin >Sent: Friday, February 06, 2004 8:48 AM >To: sampathk@cisco.com; megaco@ietf.org >Cc: 'Tom Taylor'; 'Kevin Boyle' >Subject: RE: [Megaco] Query Related to Automatic Metering > > >Sampath, > >metd already adheres to that way as described in its >"KeepActive and EventbufferControl Procedures." > >Regards, > Aleks > > >From: "Sampath Komanduri" > >To: "'Tom Taylor'", > > "'Kevin Boyle'", > > "'Aleksandr Ryabin'" > >Subject: RE: [Megaco] Query Related to Automatic Metering > >Date: Fri, 6 Feb 2004 01:14:07 -0800 > > > >Hi Kevin/Aleks, > >Is my understanding correct that we are going to change the AMET and METD > >package procedures to reflect the issue raised by gsachin and agreed by >Tom? > >Pls. let me know. > >Thanks, > >Sampath > > > >-----Original Message----- > >From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of Tom > >Taylor > >Sent: Monday, December 22, 2003 8:53 AM > >Cc: megaco@ietf.org > >Subject: Re: [Megaco] Query Related to Automatic Metering > > > > > >I think you make a good point. It's desirable to keep the protocol > >intact, rather than define exceptions within individual packages. > > > >gsachin wrote: > > > > > > > > > > > > > > Hi List, > > > > > > > > > this is a query regarding Periodic report event 'pr' defined in AMET > > > package .the package procedure says that > > > > > > "the detection of event pr shall not cause the termination of the > > > signal em or signal mbp, even if the KeppActive(KA) flag is not set > > > for the pr event" > > > > > > what i feel is that the detection of the 'pr' event shall not cause > > > the termination of any of the signals. > > > > > > pls tell me if this is a correct assumption? > > > > > > if yes, then i think here the package procedures should have mandated > > > the use of KA flag with this event. Doing this will keep the protocol > > > rules intact. > > > > > > > > > > > > Regards > > > Sachin Gupta > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Feb 9 09:47:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21721 for ; Mon, 9 Feb 2004 09:47:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCgm-0006sM-N9 for megaco-archive@odin.ietf.org; Mon, 09 Feb 2004 09:47:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19El8Hq026424 for megaco-archive@odin.ietf.org; Mon, 9 Feb 2004 09:47:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCgm-0006s7-JL for megaco-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 09:47:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21702 for ; Mon, 9 Feb 2004 09:47:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqCgk-00050h-00 for megaco-web-archive@ietf.org; Mon, 09 Feb 2004 09:47:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqCfj-0004uV-00 for megaco-web-archive@ietf.org; Mon, 09 Feb 2004 09:46:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqCem-0004oW-00 for megaco-web-archive@ietf.org; Mon, 09 Feb 2004 09:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCel-0006eu-A7; Mon, 09 Feb 2004 09:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCdw-0006XX-6h for megaco@optimus.ietf.org; Mon, 09 Feb 2004 09:44:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21589 for ; Mon, 9 Feb 2004 09:44:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqCdu-0004jW-00 for megaco@ietf.org; Mon, 09 Feb 2004 09:44:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqCcw-0004dt-00 for megaco@ietf.org; Mon, 09 Feb 2004 09:43:11 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AqCbz-0004Yw-00 for megaco@ietf.org; Mon, 09 Feb 2004 09:42:11 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i19EfWAH016841; Mon, 9 Feb 2004 07:41:42 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i19EeC4n004617; Mon, 9 Feb 2004 08:40:13 -0600 Message-Id: <5.2.1.1.0.20040209092402.05202c98@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 09 Feb 2004 09:39:43 -0500 To: "Sachin Gupta", From: Aleksandr Ryabin Subject: RE: [Megaco] Query Related to Automatic Metering In-Reply-To: References: <5.2.1.1.0.20040206113839.01e04830@IL06EXM13.corp.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: megaco-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL autolearn=no version=2.60 Sachin Gupta, A) The package definition should not really care ether there are such cases, or not. It is up to MGC to control and direct MG on how exactly MGC wants MG to behave. That is if it wants it for whatever reason terminate all signals on detection of the event then it will not provide KA. Regards, Aleks At 09:06 PM 2/6/2004, Sachin Gupta wrote: >Aleks, >The "KeepActive and EventbufferControl Procedures." in the metd package does >not mandate the use of KeepActive(KA) flag. > >In case MGC comes with "metering pulse detection" event without KA Flag then >what should be MGs behaviour? > >A) Should it do the normal processing (i.e stop all signals), as mentioned >in the base protocol, when this event is detected? >B) Should it report an error for the command request? >C) Should it do the processing as if KA flag is there, even though call >agent has not specified it? > >Do we have any scenarios where detection of this event may require stopping >of currently applied signals? If not, then shouldn't the use of KA be >mandated? > > >Pls clarify. > >Thanks >Sachin gupta > >-----Original Message----- >From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of >Aleksandr Ryabin >Sent: Friday, February 06, 2004 8:48 AM >To: sampathk@cisco.com; megaco@ietf.org >Cc: 'Tom Taylor'; 'Kevin Boyle' >Subject: RE: [Megaco] Query Related to Automatic Metering > > >Sampath, > >metd already adheres to that way as described in its >"KeepActive and EventbufferControl Procedures." > >Regards, > Aleks > > >From: "Sampath Komanduri" > >To: "'Tom Taylor'", > > "'Kevin Boyle'", > > "'Aleksandr Ryabin'" > >Subject: RE: [Megaco] Query Related to Automatic Metering > >Date: Fri, 6 Feb 2004 01:14:07 -0800 > > > >Hi Kevin/Aleks, > >Is my understanding correct that we are going to change the AMET and METD > >package procedures to reflect the issue raised by gsachin and agreed by >Tom? > >Pls. let me know. > >Thanks, > >Sampath > > > >-----Original Message----- > >From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of Tom > >Taylor > >Sent: Monday, December 22, 2003 8:53 AM > >Cc: megaco@ietf.org > >Subject: Re: [Megaco] Query Related to Automatic Metering > > > > > >I think you make a good point. It's desirable to keep the protocol > >intact, rather than define exceptions within individual packages. > > > >gsachin wrote: > > > > > > > > > > > > > > Hi List, > > > > > > > > > this is a query regarding Periodic report event 'pr' defined in AMET > > > package .the package procedure says that > > > > > > "the detection of event pr shall not cause the termination of the > > > signal em or signal mbp, even if the KeppActive(KA) flag is not set > > > for the pr event" > > > > > > what i feel is that the detection of the 'pr' event shall not cause > > > the termination of any of the signals. > > > > > > pls tell me if this is a correct assumption? > > > > > > if yes, then i think here the package procedures should have mandated > > > the use of KA flag with this event. Doing this will keep the protocol > > > rules intact. > > > > > > > > > > > > Regards > > > Sachin Gupta > > >_______________________________________________ >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 Feb 9 10:41:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24394 for ; Mon, 9 Feb 2004 10:41:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDWx-0007R3-7T; Mon, 09 Feb 2004 10:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqBCs-0005my-5G for megaco@optimus.ietf.org; Mon, 09 Feb 2004 08:12:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17317 for ; Mon, 9 Feb 2004 08:12:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqBCr-0003mP-00 for megaco@ietf.org; Mon, 09 Feb 2004 08:12:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqBBs-0003eb-00 for megaco@ietf.org; Mon, 09 Feb 2004 08:11:09 -0500 Received: from [203.199.83.147] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1AqBB0-0003UG-00 for megaco@ietf.org; Mon, 09 Feb 2004 08:10:14 -0500 Received: (qmail 5511 invoked by uid 510); 9 Feb 2004 13:10:04 -0000 Date: 9 Feb 2004 13:10:04 -0000 Message-ID: <20040209131004.5509.qmail@webmail25.rediffmail.com> Received: from unknown (137.71.23.54) by rediffmail.com via HTTP; 09 feb 2004 13:10:04 -0000 MIME-Version: 1.0 From: "kumaraswamy Uppu" Reply-To: "kumaraswamy Uppu" To: megaco@ietf.org Content-type: multipart/alternative; boundary="Next_1076332204---0-203.199.83.147-5394" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.4 required=5.0 tests=FROM_ENDS_IN_NUMS,HTML_30_40, HTML_MESSAGE,MSGID_FROM_MTA_HEADER,REPLY_TO_ULINE_NUMS autolearn=no version=2.60 Subject: [Megaco] (no subject) Sender: megaco-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 multipart mime message --Next_1076332204---0-203.199.83.147-5394 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi All,
=0A  I have a query about BER encoding of serviceChan= geReason Parameter. As per rfc 3525 , this string is first BER-encoded as a= n IA5String.
=0AThe result of this BER-encoding is then encoded as an AS= N.1 OCTET STRING type.
=0A  This is the encoded buffer for this Par= ameter.
=0A  04 0F 16 0D 39 30 31 20  43 6F 6C 64 20 42 6F 6F = 74
=0A  First I encoded it as IA5 string (16 0D 39 30 31 20  = 43 6F 6C 64 20 42 6F 6F 74) and then the result I encoded it as OctetString= .
=0A  When I tried to decode with Hammer Call Anaylzer its not dec= oding  serviceChangeReason properly.
=0A
=0AHere Is the capture = this packet.
=0A
=0A---- UDP ----
=0A  ---- UDP header ----<= BR>=0A      0B-81 =3D B81h [2945d] source port
=0A  =     0B-81 =3D B81h [2945d] destination port
=0A    &= nbsp; 00-7D =3D 7Dh [125d] length: octets include header (not less than 8)<= BR>=0A      E4-9B =3D E49Bh [58523d] checksum: checksum is c= orrect
=0A  ---- UDP datagram ----
=0A---- H.248 ----
=0A&nb= sp; {1010 0000}=3D A0h [160d]  tag: 0x00 [000]
=0A  ---- Mes= sage ----
=0A      ---- version ----
=0A    =     {0000 0001}=3D 01h [001d] version
=0A     = ---- MId ----
=0A        ---- IP4Address ----
= =0A            ---- address ----
=0A =             address: 192.168.5.8
=0A&nbs= p;     ---- Transactions ----
=0A        = ---- TransactionRequest ----
=0A           = ; ---- TransactionID ----
=0A            &= nbsp; {0110 0101}=3D 65h [101d] transactionID
=0A      &= nbsp;     ---- actions ----
=0A        &nb= sp;     ---- ActionRequest ----
=0A       = ;           ---- ContextID ----
=0A   = ;                 {0000 0000}=3D 0= 0h [000d] contextID
=0A              =     ---- commandsRequest ----
=0A        &= nbsp;           ---- CommandRequest ----
=0A&n= bsp;                     =   ---- Command ----
=0A            &n= bsp;             ---- serviceChangeRequest -= ---
=0A                  &n= bsp;           ---- TerminationIDList ----
=0A&= nbsp;                    =           ---- TerminationID ----
=0A  &= nbsp;                    =             ---- wildcard ----
=0A  =                      = ;               ---- WildcardField ----=
=0A                   = ;                   ---- Wild= cardField ----
=0A               = ;                     &nb= sp;     wildcardField: FF-FF-FF-FF-FF-FF-FF-FF- 00
=0A  &= nbsp;                    =       ---- ServiceChangeParm ----
=0A     = ;                     &nb= sp;     ---- ServiceChangeMethod ----
=0A     =                     &nbs= p;         {0000 0011}=3D 03h [003d] ServiceChangeMetho= drestart
=0A                &nbs= p;               ---- ServiceChangeVers= ion ----
=0A                &nbs= p;                   {0000 000= 1}=3D 01h [001d] ServiceChangeVersion
=0A        &nb= sp;                     &= nbsp; ---- Value ----
=0A            &nbs= p;                     &n= bsp; value: 16-0D-39-30-31-20-43-6F- 6C-64-20-42-6F-6F-74
=0A
=0A&nbs= p; Is it correct ?
=0A  Can any one help me in this.
=0A
=0A= Thanks,
=0AKumar
=0A
=0A
=0A=0A

=0A

=0A= =0A --Next_1076332204---0-203.199.83.147-5394 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All,=0A I have a query about BER encoding of serviceChangeReason Parame= ter. As per rfc 3525 , this string is first BER-encoded as an IA5String.=0A= The result of this BER-encoding is then encoded as an ASN.1 OCTET STRING ty= pe.=0A This is the encoded buffer for this Parameter.=0A 04 0F 16 0D 39 3= 0 31 20 43 6F 6C 64 20 42 6F 6F 74 =0A First I encoded it as IA5 string (= 16 0D 39 30 31 20 43 6F 6C 64 20 42 6F 6F 74) and then the result I encode= d it as OctetString.=0A When I tried to decode with Hammer Call Anaylzer i= ts not decoding serviceChangeReason properly.=0A=0AHere Is the capture thi= s packet.=0A=0A---- UDP ----=0A ---- UDP header ----=0A 0B-81 =3D B8= 1h [2945d] source port=0A 0B-81 =3D B81h [2945d] destination port=0A = 00-7D =3D 7Dh [125d] length: octets include header (not less than 8)=0A= E4-9B =3D E49Bh [58523d] checksum: checksum is correct=0A ---- UDP = datagram ----=0A---- H.248 ----=0A {1010 0000}=3D A0h [160d] tag: 0x00 [= 000]=0A ---- Message ----=0A ---- version ----=0A {0000 0001= }=3D 01h [001d] version=0A ---- MId ----=0A ---- IP4Address --= --=0A ---- address ----=0A address: 192.168.5.8=0A= ---- Transactions ----=0A ---- TransactionRequest ----=0A = ---- TransactionID ----=0A {0110 0101}=3D 65h [101d] = transactionID=0A ---- actions ----=0A ---- ActionR= equest ----=0A ---- ContextID ----=0A = {0000 0000}=3D 00h [000d] contextID=0A ---- commandsReques= t ----=0A ---- CommandRequest ----=0A = ---- Command ----=0A ---- serviceChangeRequ= est ----=0A ---- TerminationIDList ----=0A = ---- TerminationID ----=0A = ---- wildcard ----=0A = ---- WildcardField ----=0A ---- Wild= cardField ----=0A wildcardField: F= F-FF-FF-FF-FF-FF-FF-FF- 00=0A ---- ServiceChan= geParm ----=0A ---- ServiceChangeMethod ---= -=0A {0000 0011}=3D 03h [003d] ServiceCh= angeMethodrestart=0A ---- ServiceChangeVers= ion ----=0A {0000 0001}=3D 01h [001d] Se= rviceChangeVersion=0A ---- Value ----=0A = value: 16-0D-39-30-31-20-43-6F- 6C-64-20-4= 2-6F-6F-74=0A=0A Is it correct ? =0A Can any one help me in this.=0A=0ATh= anks,=0AKumar=0A =0A=0A --Next_1076332204---0-203.199.83.147-5394-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Feb 9 10:43:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24516 for ; Mon, 9 Feb 2004 10:43:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDYw-0007f9-ES for megaco-archive@odin.ietf.org; Mon, 09 Feb 2004 10:43:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19Fh6Xe029449 for megaco-archive@odin.ietf.org; Mon, 9 Feb 2004 10:43:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDYw-0007eu-9Q for megaco-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 10:43:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24471 for ; Mon, 9 Feb 2004 10:43:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqDYt-0001KT-00 for megaco-web-archive@ietf.org; Mon, 09 Feb 2004 10:43:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqDXv-0001Dw-00 for megaco-web-archive@ietf.org; Mon, 09 Feb 2004 10:42:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqDWw-00015p-00 for megaco-web-archive@ietf.org; Mon, 09 Feb 2004 10:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDWx-0007R3-7T; Mon, 09 Feb 2004 10:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqBCs-0005my-5G for megaco@optimus.ietf.org; Mon, 09 Feb 2004 08:12:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17317 for ; Mon, 9 Feb 2004 08:12:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqBCr-0003mP-00 for megaco@ietf.org; Mon, 09 Feb 2004 08:12:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqBBs-0003eb-00 for megaco@ietf.org; Mon, 09 Feb 2004 08:11:09 -0500 Received: from [203.199.83.147] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1AqBB0-0003UG-00 for megaco@ietf.org; Mon, 09 Feb 2004 08:10:14 -0500 Received: (qmail 5511 invoked by uid 510); 9 Feb 2004 13:10:04 -0000 Date: 9 Feb 2004 13:10:04 -0000 Message-ID: <20040209131004.5509.qmail@webmail25.rediffmail.com> Received: from unknown (137.71.23.54) by rediffmail.com via HTTP; 09 feb 2004 13:10:04 -0000 MIME-Version: 1.0 From: "kumaraswamy Uppu" Reply-To: "kumaraswamy Uppu" To: megaco@ietf.org Content-type: multipart/alternative; boundary="Next_1076332204---0-203.199.83.147-5394" Subject: [Megaco] (no subject) Sender: megaco-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.4 required=5.0 tests=FROM_ENDS_IN_NUMS,HTML_30_40, HTML_MESSAGE,MSGID_FROM_MTA_HEADER,REPLY_TO_ULINE_NUMS autolearn=no version=2.60 This is a multipart mime message --Next_1076332204---0-203.199.83.147-5394 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi All,
=0A  I have a query about BER encoding of serviceChan= geReason Parameter. As per rfc 3525 , this string is first BER-encoded as a= n IA5String.
=0AThe result of this BER-encoding is then encoded as an AS= N.1 OCTET STRING type.
=0A  This is the encoded buffer for this Par= ameter.
=0A  04 0F 16 0D 39 30 31 20  43 6F 6C 64 20 42 6F 6F = 74
=0A  First I encoded it as IA5 string (16 0D 39 30 31 20  = 43 6F 6C 64 20 42 6F 6F 74) and then the result I encoded it as OctetString= .
=0A  When I tried to decode with Hammer Call Anaylzer its not dec= oding  serviceChangeReason properly.
=0A
=0AHere Is the capture = this packet.
=0A
=0A---- UDP ----
=0A  ---- UDP header ----<= BR>=0A      0B-81 =3D B81h [2945d] source port
=0A  =     0B-81 =3D B81h [2945d] destination port
=0A    &= nbsp; 00-7D =3D 7Dh [125d] length: octets include header (not less than 8)<= BR>=0A      E4-9B =3D E49Bh [58523d] checksum: checksum is c= orrect
=0A  ---- UDP datagram ----
=0A---- H.248 ----
=0A&nb= sp; {1010 0000}=3D A0h [160d]  tag: 0x00 [000]
=0A  ---- Mes= sage ----
=0A      ---- version ----
=0A    =     {0000 0001}=3D 01h [001d] version
=0A     = ---- MId ----
=0A        ---- IP4Address ----
= =0A            ---- address ----
=0A =             address: 192.168.5.8
=0A&nbs= p;     ---- Transactions ----
=0A        = ---- TransactionRequest ----
=0A           = ; ---- TransactionID ----
=0A            &= nbsp; {0110 0101}=3D 65h [101d] transactionID
=0A      &= nbsp;     ---- actions ----
=0A        &nb= sp;     ---- ActionRequest ----
=0A       = ;           ---- ContextID ----
=0A   = ;                 {0000 0000}=3D 0= 0h [000d] contextID
=0A              =     ---- commandsRequest ----
=0A        &= nbsp;           ---- CommandRequest ----
=0A&n= bsp;                     =   ---- Command ----
=0A            &n= bsp;             ---- serviceChangeRequest -= ---
=0A                  &n= bsp;           ---- TerminationIDList ----
=0A&= nbsp;                    =           ---- TerminationID ----
=0A  &= nbsp;                    =             ---- wildcard ----
=0A  =                      = ;               ---- WildcardField ----=
=0A                   = ;                   ---- Wild= cardField ----
=0A               = ;                     &nb= sp;     wildcardField: FF-FF-FF-FF-FF-FF-FF-FF- 00
=0A  &= nbsp;                    =       ---- ServiceChangeParm ----
=0A     = ;                     &nb= sp;     ---- ServiceChangeMethod ----
=0A     =                     &nbs= p;         {0000 0011}=3D 03h [003d] ServiceChangeMetho= drestart
=0A                &nbs= p;               ---- ServiceChangeVers= ion ----
=0A                &nbs= p;                   {0000 000= 1}=3D 01h [001d] ServiceChangeVersion
=0A        &nb= sp;                     &= nbsp; ---- Value ----
=0A            &nbs= p;                     &n= bsp; value: 16-0D-39-30-31-20-43-6F- 6C-64-20-42-6F-6F-74
=0A
=0A&nbs= p; Is it correct ?
=0A  Can any one help me in this.
=0A
=0A= Thanks,
=0AKumar
=0A
=0A
=0A=0A

=0A

=0A= =0A --Next_1076332204---0-203.199.83.147-5394 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All,=0A I have a query about BER encoding of serviceChangeReason Parame= ter. As per rfc 3525 , this string is first BER-encoded as an IA5String.=0A= The result of this BER-encoding is then encoded as an ASN.1 OCTET STRING ty= pe.=0A This is the encoded buffer for this Parameter.=0A 04 0F 16 0D 39 3= 0 31 20 43 6F 6C 64 20 42 6F 6F 74 =0A First I encoded it as IA5 string (= 16 0D 39 30 31 20 43 6F 6C 64 20 42 6F 6F 74) and then the result I encode= d it as OctetString.=0A When I tried to decode with Hammer Call Anaylzer i= ts not decoding serviceChangeReason properly.=0A=0AHere Is the capture thi= s packet.=0A=0A---- UDP ----=0A ---- UDP header ----=0A 0B-81 =3D B8= 1h [2945d] source port=0A 0B-81 =3D B81h [2945d] destination port=0A = 00-7D =3D 7Dh [125d] length: octets include header (not less than 8)=0A= E4-9B =3D E49Bh [58523d] checksum: checksum is correct=0A ---- UDP = datagram ----=0A---- H.248 ----=0A {1010 0000}=3D A0h [160d] tag: 0x00 [= 000]=0A ---- Message ----=0A ---- version ----=0A {0000 0001= }=3D 01h [001d] version=0A ---- MId ----=0A ---- IP4Address --= --=0A ---- address ----=0A address: 192.168.5.8=0A= ---- Transactions ----=0A ---- TransactionRequest ----=0A = ---- TransactionID ----=0A {0110 0101}=3D 65h [101d] = transactionID=0A ---- actions ----=0A ---- ActionR= equest ----=0A ---- ContextID ----=0A = {0000 0000}=3D 00h [000d] contextID=0A ---- commandsReques= t ----=0A ---- CommandRequest ----=0A = ---- Command ----=0A ---- serviceChangeRequ= est ----=0A ---- TerminationIDList ----=0A = ---- TerminationID ----=0A = ---- wildcard ----=0A = ---- WildcardField ----=0A ---- Wild= cardField ----=0A wildcardField: F= F-FF-FF-FF-FF-FF-FF-FF- 00=0A ---- ServiceChan= geParm ----=0A ---- ServiceChangeMethod ---= -=0A {0000 0011}=3D 03h [003d] ServiceCh= angeMethodrestart=0A ---- ServiceChangeVers= ion ----=0A {0000 0001}=3D 01h [001d] Se= rviceChangeVersion=0A ---- Value ----=0A = value: 16-0D-39-30-31-20-43-6F- 6C-64-20-4= 2-6F-6F-74=0A=0A Is it correct ? =0A Can any one help me in this.=0A=0ATh= anks,=0AKumar=0A =0A=0A --Next_1076332204---0-203.199.83.147-5394-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 9 11:42:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27464 for ; Mon, 9 Feb 2004 11:42:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqETx-0004W7-2m; Mon, 09 Feb 2004 11:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqETA-0004Lu-BU for megaco@optimus.ietf.org; Mon, 09 Feb 2004 11:41:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27404 for ; Mon, 9 Feb 2004 11:41:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqET9-0007c8-00 for megaco@ietf.org; Mon, 09 Feb 2004 11:41:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqESY-0007Y1-00 for megaco@ietf.org; Mon, 09 Feb 2004 11:40:36 -0500 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1AqES3-0007NV-00 for megaco@ietf.org; Mon, 09 Feb 2004 11:40:03 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i19GX8o14902; Mon, 9 Feb 2004 11:33:08 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3DGM88>; Mon, 9 Feb 2004 11:33:08 -0500 Message-ID: From: "Kevin Boyle" To: Sachin Gupta , Aleksandr Ryabin , sampathk@cisco.com, megaco@ietf.org Cc: "Tom-PT Taylor" Subject: RE: [Megaco] Query Related to Automatic Metering Date: Mon, 9 Feb 2004 11:33:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EF2A.644B1836" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , 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_01C3EF2A.644B1836 Content-Type: text/plain The package cannot, and should not, mandate use of KA. The text has been updated via corrigendum to correct the alteration of the base protocol function. I will vigorously oppose any mandate of use of KA. The package should function the same way as any other when KA is not specified. Kevin -----Original Message----- From: Sachin Gupta [mailto:sachgupt@cisco.com] Sent: Friday, February 06, 2004 9:07 PM To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; Boyle, Kevin [NCRTP:3Z40:EXCH] Subject: RE: [Megaco] Query Related to Automatic Metering Aleks, The "KeepActive and EventbufferControl Procedures." in the metd package does not mandate the use of KeepActive(KA) flag. In case MGC comes with "metering pulse detection" event without KA Flag then what should be MGs behaviour? A) Should it do the normal processing (i.e stop all signals), as mentioned in the base protocol, when this event is detected? B) Should it report an error for the command request? C) Should it do the processing as if KA flag is there, even though call agent has not specified it? Do we have any scenarios where detection of this event may require stopping of currently applied signals? If not, then shouldn't the use of KA be mandated? Pls clarify. Thanks Sachin gupta -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Aleksandr Ryabin Sent: Friday, February 06, 2004 8:48 AM To: sampathk@cisco.com; megaco@ietf.org Cc: 'Tom Taylor'; 'Kevin Boyle' Subject: RE: [Megaco] Query Related to Automatic Metering Sampath, metd already adheres to that way as described in its "KeepActive and EventbufferControl Procedures." Regards, Aleks >From: "Sampath Komanduri" >To: "'Tom Taylor'", > "'Kevin Boyle'", > "'Aleksandr Ryabin'" >Subject: RE: [Megaco] Query Related to Automatic Metering >Date: Fri, 6 Feb 2004 01:14:07 -0800 > >Hi Kevin/Aleks, >Is my understanding correct that we are going to change the AMET and >METD package procedures to reflect the issue raised by gsachin and >agreed by Tom? >Pls. let me know. >Thanks, >Sampath > >-----Original Message----- >From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of >Tom Taylor >Sent: Monday, December 22, 2003 8:53 AM >Cc: megaco@ietf.org >Subject: Re: [Megaco] Query Related to Automatic Metering > > >I think you make a good point. It's desirable to keep the protocol >intact, rather than define exceptions within individual packages. > >gsachin wrote: > > > > > > > > > Hi List, > > > > > > this is a query regarding Periodic report event 'pr' defined in AMET > > package .the package procedure says that > > > > "the detection of event pr shall not cause the termination of the > > signal em or signal mbp, even if the KeppActive(KA) flag is not set > > for the pr event" > > > > what i feel is that the detection of the 'pr' event shall not cause > > the termination of any of the signals. > > > > pls tell me if this is a correct assumption? > > > > if yes, then i think here the package procedures should have > > mandated the use of KA flag with this event. Doing this will keep > > the protocol rules intact. > > > > > > > > Regards > > Sachin Gupta _______________________________________________ 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 ------_=_NextPart_001_01C3EF2A.644B1836 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] Query Related to Automatic Metering

The package cannot, and should not, mandate use of = KA.  The text has been updated via corrigendum to correct the = alteration of the base protocol function.  I will vigorously = oppose any mandate of use of KA.

The package should function the same way as any other = when KA is not specified.

Kevin

-----Original Message-----
From: Sachin Gupta [mailto:sachgupt@cisco.com] =
Sent: Friday, February 06, 2004 9:07 PM
To: Aleksandr Ryabin; sampathk@cisco.com; = megaco@ietf.org
Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; Boyle, Kevin = [NCRTP:3Z40:EXCH]
Subject: RE: [Megaco] Query Related to Automatic = Metering


Aleks,
The "KeepActive and EventbufferControl = Procedures." in the metd package does not mandate the use of = KeepActive(KA) flag.

In case MGC comes with "metering pulse = detection" event without KA Flag then what should be MGs = behaviour?

A) Should it do the normal processing (i.e stop all = signals), as mentioned in the base protocol, when this event is = detected?

B) Should it report an error for the command = request?
C) Should it do the processing as if KA flag is = there, even though call agent has not specified it?

Do we have any scenarios where detection of this = event may require stopping of currently applied signals? If not, then = shouldn't the use of KA be mandated?


Pls clarify.

Thanks
Sachin gupta

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]O= n Behalf Of Aleksandr Ryabin
Sent: Friday, February 06, 2004 8:48 AM
To: sampathk@cisco.com; megaco@ietf.org
Cc: 'Tom Taylor'; 'Kevin Boyle'
Subject: RE: [Megaco] Query Related to Automatic = Metering


Sampath,

metd already adheres to that way as described in its = "KeepActive and EventbufferControl Procedures."

Regards,
         = Aleks

>From: "Sampath = Komanduri"<sampathk@cisco.com>
>To: "'Tom = Taylor'"<taylor@nortelnetworks.com>,
>    "'Kevin = Boyle'"<kboyle@nortelnetworks.com>,
>    "'Aleksandr = Ryabin'"<kengr@motorola.com>
>Subject: RE: [Megaco] Query Related to Automatic = Metering
>Date: Fri, 6 Feb 2004 01:14:07 -0800
>
>Hi Kevin/Aleks,
>Is my understanding correct that we are going to = change the AMET and
>METD package procedures to reflect the issue = raised by gsachin and
>agreed by
Tom?
>Pls. let me know.
>Thanks,
>Sampath
>
>-----Original Message-----
>From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] = On Behalf Of
>Tom Taylor
>Sent: Monday, December 22, 2003 8:53 AM
>Cc: megaco@ietf.org
>Subject: Re: [Megaco] Query Related to Automatic = Metering
>
>
>I think you make a good point.  It's = desirable to keep the protocol
>intact, rather than define exceptions within = individual packages.
>
>gsachin wrote:
>
> >
> >
> >
> > Hi List,
> >
> >
> > this is a query regarding Periodic report = event 'pr' defined in AMET
> > package .the package procedure says = that
> >
> > "the detection of event pr shall not = cause the termination of the
> > signal em or signal mbp, even if the = KeppActive(KA) flag is not set
> > for the pr event"
> >
> > what i feel is that the detection of the = 'pr' event shall not cause
> > the termination of any of the = signals.
> >
> > pls tell me if this is a correct = assumption?
> >
> > if yes, then i think here the package = procedures should have
> > mandated the use of KA flag with this = event. Doing this will keep
> > the protocol rules intact.
> >
> >
> >
> > Regards
> > Sachin Gupta


_______________________________________________
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

------_=_NextPart_001_01C3EF2A.644B1836-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Feb 9 11:43:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27566 for ; Mon, 9 Feb 2004 11:43:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEVO-0004gw-0P for megaco-archive@odin.ietf.org; Mon, 09 Feb 2004 11:43:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19GhTHX018028 for megaco-archive@odin.ietf.org; Mon, 9 Feb 2004 11:43:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEVN-0004gh-SL for megaco-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 11:43:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27543 for ; Mon, 9 Feb 2004 11:43:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqEVM-00003L-00 for megaco-web-archive@ietf.org; Mon, 09 Feb 2004 11:43:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqEUK-0007jw-00 for megaco-web-archive@ietf.org; Mon, 09 Feb 2004 11:42:25 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqETy-0007dX-00 for megaco-web-archive@ietf.org; Mon, 09 Feb 2004 11:42:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqETz-0005nD-IV for megaco-web-archive@ietf.org; Mon, 09 Feb 2004 11:42:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqETx-0004W7-2m; Mon, 09 Feb 2004 11:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqETA-0004Lu-BU for megaco@optimus.ietf.org; Mon, 09 Feb 2004 11:41:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27404 for ; Mon, 9 Feb 2004 11:41:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqET9-0007c8-00 for megaco@ietf.org; Mon, 09 Feb 2004 11:41:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqESY-0007Y1-00 for megaco@ietf.org; Mon, 09 Feb 2004 11:40:36 -0500 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1AqES3-0007NV-00 for megaco@ietf.org; Mon, 09 Feb 2004 11:40:03 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i19GX8o14902; Mon, 9 Feb 2004 11:33:08 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3DGM88>; Mon, 9 Feb 2004 11:33:08 -0500 Message-ID: From: "Kevin Boyle" To: Sachin Gupta , Aleksandr Ryabin , sampathk@cisco.com, megaco@ietf.org Cc: "Tom-PT Taylor" Subject: RE: [Megaco] Query Related to Automatic Metering Date: Mon, 9 Feb 2004 11:33:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EF2A.644B1836" Sender: megaco-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3EF2A.644B1836 Content-Type: text/plain The package cannot, and should not, mandate use of KA. The text has been updated via corrigendum to correct the alteration of the base protocol function. I will vigorously oppose any mandate of use of KA. The package should function the same way as any other when KA is not specified. Kevin -----Original Message----- From: Sachin Gupta [mailto:sachgupt@cisco.com] Sent: Friday, February 06, 2004 9:07 PM To: Aleksandr Ryabin; sampathk@cisco.com; megaco@ietf.org Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; Boyle, Kevin [NCRTP:3Z40:EXCH] Subject: RE: [Megaco] Query Related to Automatic Metering Aleks, The "KeepActive and EventbufferControl Procedures." in the metd package does not mandate the use of KeepActive(KA) flag. In case MGC comes with "metering pulse detection" event without KA Flag then what should be MGs behaviour? A) Should it do the normal processing (i.e stop all signals), as mentioned in the base protocol, when this event is detected? B) Should it report an error for the command request? C) Should it do the processing as if KA flag is there, even though call agent has not specified it? Do we have any scenarios where detection of this event may require stopping of currently applied signals? If not, then shouldn't the use of KA be mandated? Pls clarify. Thanks Sachin gupta -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Aleksandr Ryabin Sent: Friday, February 06, 2004 8:48 AM To: sampathk@cisco.com; megaco@ietf.org Cc: 'Tom Taylor'; 'Kevin Boyle' Subject: RE: [Megaco] Query Related to Automatic Metering Sampath, metd already adheres to that way as described in its "KeepActive and EventbufferControl Procedures." Regards, Aleks >From: "Sampath Komanduri" >To: "'Tom Taylor'", > "'Kevin Boyle'", > "'Aleksandr Ryabin'" >Subject: RE: [Megaco] Query Related to Automatic Metering >Date: Fri, 6 Feb 2004 01:14:07 -0800 > >Hi Kevin/Aleks, >Is my understanding correct that we are going to change the AMET and >METD package procedures to reflect the issue raised by gsachin and >agreed by Tom? >Pls. let me know. >Thanks, >Sampath > >-----Original Message----- >From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of >Tom Taylor >Sent: Monday, December 22, 2003 8:53 AM >Cc: megaco@ietf.org >Subject: Re: [Megaco] Query Related to Automatic Metering > > >I think you make a good point. It's desirable to keep the protocol >intact, rather than define exceptions within individual packages. > >gsachin wrote: > > > > > > > > > Hi List, > > > > > > this is a query regarding Periodic report event 'pr' defined in AMET > > package .the package procedure says that > > > > "the detection of event pr shall not cause the termination of the > > signal em or signal mbp, even if the KeppActive(KA) flag is not set > > for the pr event" > > > > what i feel is that the detection of the 'pr' event shall not cause > > the termination of any of the signals. > > > > pls tell me if this is a correct assumption? > > > > if yes, then i think here the package procedures should have > > mandated the use of KA flag with this event. Doing this will keep > > the protocol rules intact. > > > > > > > > Regards > > Sachin Gupta _______________________________________________ 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 ------_=_NextPart_001_01C3EF2A.644B1836 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] Query Related to Automatic Metering

The package cannot, and should not, mandate use of = KA.  The text has been updated via corrigendum to correct the = alteration of the base protocol function.  I will vigorously = oppose any mandate of use of KA.

The package should function the same way as any other = when KA is not specified.

Kevin

-----Original Message-----
From: Sachin Gupta [mailto:sachgupt@cisco.com] =
Sent: Friday, February 06, 2004 9:07 PM
To: Aleksandr Ryabin; sampathk@cisco.com; = megaco@ietf.org
Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; Boyle, Kevin = [NCRTP:3Z40:EXCH]
Subject: RE: [Megaco] Query Related to Automatic = Metering


Aleks,
The "KeepActive and EventbufferControl = Procedures." in the metd package does not mandate the use of = KeepActive(KA) flag.

In case MGC comes with "metering pulse = detection" event without KA Flag then what should be MGs = behaviour?

A) Should it do the normal processing (i.e stop all = signals), as mentioned in the base protocol, when this event is = detected?

B) Should it report an error for the command = request?
C) Should it do the processing as if KA flag is = there, even though call agent has not specified it?

Do we have any scenarios where detection of this = event may require stopping of currently applied signals? If not, then = shouldn't the use of KA be mandated?


Pls clarify.

Thanks
Sachin gupta

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]O= n Behalf Of Aleksandr Ryabin
Sent: Friday, February 06, 2004 8:48 AM
To: sampathk@cisco.com; megaco@ietf.org
Cc: 'Tom Taylor'; 'Kevin Boyle'
Subject: RE: [Megaco] Query Related to Automatic = Metering


Sampath,

metd already adheres to that way as described in its = "KeepActive and EventbufferControl Procedures."

Regards,
         = Aleks

>From: "Sampath = Komanduri"<sampathk@cisco.com>
>To: "'Tom = Taylor'"<taylor@nortelnetworks.com>,
>    "'Kevin = Boyle'"<kboyle@nortelnetworks.com>,
>    "'Aleksandr = Ryabin'"<kengr@motorola.com>
>Subject: RE: [Megaco] Query Related to Automatic = Metering
>Date: Fri, 6 Feb 2004 01:14:07 -0800
>
>Hi Kevin/Aleks,
>Is my understanding correct that we are going to = change the AMET and
>METD package procedures to reflect the issue = raised by gsachin and
>agreed by
Tom?
>Pls. let me know.
>Thanks,
>Sampath
>
>-----Original Message-----
>From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] = On Behalf Of
>Tom Taylor
>Sent: Monday, December 22, 2003 8:53 AM
>Cc: megaco@ietf.org
>Subject: Re: [Megaco] Query Related to Automatic = Metering
>
>
>I think you make a good point.  It's = desirable to keep the protocol
>intact, rather than define exceptions within = individual packages.
>
>gsachin wrote:
>
> >
> >
> >
> > Hi List,
> >
> >
> > this is a query regarding Periodic report = event 'pr' defined in AMET
> > package .the package procedure says = that
> >
> > "the detection of event pr shall not = cause the termination of the
> > signal em or signal mbp, even if the = KeppActive(KA) flag is not set
> > for the pr event"
> >
> > what i feel is that the detection of the = 'pr' event shall not cause
> > the termination of any of the = signals.
> >
> > pls tell me if this is a correct = assumption?
> >
> > if yes, then i think here the package = procedures should have
> > mandated the use of KA flag with this = event. Doing this will keep
> > the protocol rules intact.
> >
> >
> >
> > Regards
> > Sachin Gupta


_______________________________________________
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

------_=_NextPart_001_01C3EF2A.644B1836-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 9 14:08:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04803 for ; Mon, 9 Feb 2004 14:08:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGlF-0008Gf-N5; Mon, 09 Feb 2004 14:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGkf-00085T-Nf for megaco@optimus.ietf.org; Mon, 09 Feb 2004 14:07:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04743 for ; Mon, 9 Feb 2004 14:07:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGkd-0006hn-00 for megaco@ietf.org; Mon, 09 Feb 2004 14:07:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGjk-0006cE-00 for megaco@ietf.org; Mon, 09 Feb 2004 14:06:28 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AqGiz-0006TH-00 for megaco@ietf.org; Mon, 09 Feb 2004 14:05:41 -0500 Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i19J57D08026 for ; Mon, 9 Feb 2004 13:05:07 -0600 (CST) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA21478; Mon, 9 Feb 2004 14:05:04 -0500 (EST) Cc: megaco@ietf.org Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA21469; Mon, 9 Feb 2004 14:05:03 -0500 (EST) Message-ID: <4027DA06.3080704@bell-labs.com> Date: Mon, 09 Feb 2004 14:05:42 -0500 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kumaraswamy Uppu Original-CC: megaco@ietf.org Subject: Re: [Megaco] (no subject) References: <20040209131004.5509.qmail@webmail25.rediffmail.com> In-Reply-To: <20040209131004.5509.qmail@webmail25.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit kumaraswamy Uppu wrote: > Hi All, > I have a query about BER encoding of serviceChangeReason Parameter. As per rfc 3525 , this string is first BER-encoded as an IA5String. > The result of this BER-encoding is then encoded as an ASN.1 OCTET STRING type. > This is the encoded buffer for this Parameter. > 04 0F 16 0D 39 30 31 20 43 6F 6C 64 20 42 6F 6F 74 > First I encoded it as IA5 string (16 0D 39 30 31 20 43 6F 6C 64 20 42 6F 6F 74) and then the result I encoded it as OctetString. > When I tried to decode with Hammer Call Anaylzer its not decoding serviceChangeReason properly. > > Here Is the capture this packet. > > ---- UDP ---- > ---- UDP header ---- > 0B-81 = B81h [2945d] source port > 0B-81 = B81h [2945d] destination port > 00-7D = 7Dh [125d] length: octets include header (not less than 8) > E4-9B = E49Bh [58523d] checksum: checksum is correct > ---- UDP datagram ---- > ---- H.248 ---- > {1010 0000}= A0h [160d] tag: 0x00 [000] > ---- Message ---- > ---- version ---- > {0000 0001}= 01h [001d] version > ---- MId ---- > ---- IP4Address ---- > ---- address ---- > address: 192.168.5.8 > ---- Transactions ---- > ---- TransactionRequest ---- > ---- TransactionID ---- > {0110 0101}= 65h [101d] transactionID > ---- actions ---- > ---- ActionRequest ---- > ---- ContextID ---- > {0000 0000}= 00h [000d] contextID > ---- commandsRequest ---- > ---- CommandRequest ---- > ---- Command ---- > ---- serviceChangeRequest ---- > ---- TerminationIDList ---- > ---- TerminationID ---- > ---- wildcard ---- > ---- WildcardField ---- > ---- WildcardField ---- > wildcardField: FF-FF-FF-FF-FF-FF-FF-FF- 00 > ---- ServiceChangeParm ---- > ---- ServiceChangeMethod ---- > {0000 0011}= 03h [003d] ServiceChangeMethodrestart > ---- ServiceChangeVersion ---- > {0000 0001}= 01h [001d] ServiceChangeVersion > ---- Value ---- > value: 16-0D-39-30-31-20-43-6F- 6C-64-20-42-6F-6F-74 > > Is it correct ? > Can any one help me in this. > I have two guesses. It's been too long since I looked at BER internals, but looking at the last part of your output. > ---- Value ---- > value: 16-0D-39-30-31-20-43-6F-6C-64-20-42-6F-6F-74 > 9 0 1 sp C o l d sp B o o t 16-0D is the tag-len for an IA5String. Also, judging from the structured output of your call analyzer, it appears that it found the positional OCTET-STRING tag-len that proceeds the one for the IA5String. So one GUESS is that your call analyzer is broken/obsolete. H.248 was out for some time before the serviceChangeReason was clarified via an IG to be double wrapped. Actually, it's not decoding anything wrong, it's just not decoding it fully. Guess 2: > This is the encoded buffer for this Parameter. > 04 0F 16 0D 39 30 31 20 43 6F 6C 64 20 42 6F 6F 74 04-0F should be the tag-len for the OCTET STRING. 0F is the correct len. 04 appears to be an incorrect or paritial tag. The tag should be 0x8004 before encoding. 0x8000 comes from it being a context specific class (not universal). The 0x8004 gets encoded into a multibyte form and comes out 11 04 0f 16 0d 39 ... -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Feb 9 14:09:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04851 for ; Mon, 9 Feb 2004 14:09:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGmW-0008Tr-Np for megaco-archive@odin.ietf.org; Mon, 09 Feb 2004 14:09:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19J9KeI032593 for megaco-archive@odin.ietf.org; Mon, 9 Feb 2004 14:09:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGmW-0008Tc-I8 for megaco-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 14:09:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04837 for ; Mon, 9 Feb 2004 14:09:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGmU-0006sT-00 for megaco-web-archive@ietf.org; Mon, 09 Feb 2004 14:09:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGlX-0006nO-00 for megaco-web-archive@ietf.org; Mon, 09 Feb 2004 14:08:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqGlE-0006ig-00 for megaco-web-archive@ietf.org; Mon, 09 Feb 2004 14:08:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGlF-0008Gf-N5; Mon, 09 Feb 2004 14:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGkf-00085T-Nf for megaco@optimus.ietf.org; Mon, 09 Feb 2004 14:07:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04743 for ; Mon, 9 Feb 2004 14:07:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGkd-0006hn-00 for megaco@ietf.org; Mon, 09 Feb 2004 14:07:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGjk-0006cE-00 for megaco@ietf.org; Mon, 09 Feb 2004 14:06:28 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AqGiz-0006TH-00 for megaco@ietf.org; Mon, 09 Feb 2004 14:05:41 -0500 Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i19J57D08026 for ; Mon, 9 Feb 2004 13:05:07 -0600 (CST) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA21478; Mon, 9 Feb 2004 14:05:04 -0500 (EST) Cc: megaco@ietf.org Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA21469; Mon, 9 Feb 2004 14:05:03 -0500 (EST) Message-ID: <4027DA06.3080704@bell-labs.com> Date: Mon, 09 Feb 2004 14:05:42 -0500 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kumaraswamy Uppu Original-CC: megaco@ietf.org Subject: Re: [Megaco] (no subject) References: <20040209131004.5509.qmail@webmail25.rediffmail.com> In-Reply-To: <20040209131004.5509.qmail@webmail25.rediffmail.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit kumaraswamy Uppu wrote: > Hi All, > I have a query about BER encoding of serviceChangeReason Parameter. As per rfc 3525 , this string is first BER-encoded as an IA5String. > The result of this BER-encoding is then encoded as an ASN.1 OCTET STRING type. > This is the encoded buffer for this Parameter. > 04 0F 16 0D 39 30 31 20 43 6F 6C 64 20 42 6F 6F 74 > First I encoded it as IA5 string (16 0D 39 30 31 20 43 6F 6C 64 20 42 6F 6F 74) and then the result I encoded it as OctetString. > When I tried to decode with Hammer Call Anaylzer its not decoding serviceChangeReason properly. > > Here Is the capture this packet. > > ---- UDP ---- > ---- UDP header ---- > 0B-81 = B81h [2945d] source port > 0B-81 = B81h [2945d] destination port > 00-7D = 7Dh [125d] length: octets include header (not less than 8) > E4-9B = E49Bh [58523d] checksum: checksum is correct > ---- UDP datagram ---- > ---- H.248 ---- > {1010 0000}= A0h [160d] tag: 0x00 [000] > ---- Message ---- > ---- version ---- > {0000 0001}= 01h [001d] version > ---- MId ---- > ---- IP4Address ---- > ---- address ---- > address: 192.168.5.8 > ---- Transactions ---- > ---- TransactionRequest ---- > ---- TransactionID ---- > {0110 0101}= 65h [101d] transactionID > ---- actions ---- > ---- ActionRequest ---- > ---- ContextID ---- > {0000 0000}= 00h [000d] contextID > ---- commandsRequest ---- > ---- CommandRequest ---- > ---- Command ---- > ---- serviceChangeRequest ---- > ---- TerminationIDList ---- > ---- TerminationID ---- > ---- wildcard ---- > ---- WildcardField ---- > ---- WildcardField ---- > wildcardField: FF-FF-FF-FF-FF-FF-FF-FF- 00 > ---- ServiceChangeParm ---- > ---- ServiceChangeMethod ---- > {0000 0011}= 03h [003d] ServiceChangeMethodrestart > ---- ServiceChangeVersion ---- > {0000 0001}= 01h [001d] ServiceChangeVersion > ---- Value ---- > value: 16-0D-39-30-31-20-43-6F- 6C-64-20-42-6F-6F-74 > > Is it correct ? > Can any one help me in this. > I have two guesses. It's been too long since I looked at BER internals, but looking at the last part of your output. > ---- Value ---- > value: 16-0D-39-30-31-20-43-6F-6C-64-20-42-6F-6F-74 > 9 0 1 sp C o l d sp B o o t 16-0D is the tag-len for an IA5String. Also, judging from the structured output of your call analyzer, it appears that it found the positional OCTET-STRING tag-len that proceeds the one for the IA5String. So one GUESS is that your call analyzer is broken/obsolete. H.248 was out for some time before the serviceChangeReason was clarified via an IG to be double wrapped. Actually, it's not decoding anything wrong, it's just not decoding it fully. Guess 2: > This is the encoded buffer for this Parameter. > 04 0F 16 0D 39 30 31 20 43 6F 6C 64 20 42 6F 6F 74 04-0F should be the tag-len for the OCTET STRING. 0F is the correct len. 04 appears to be an incorrect or paritial tag. The tag should be 0x8004 before encoding. 0x8000 comes from it being a context specific class (not universal). The 0x8004 gets encoded into a multibyte form and comes out 11 04 0f 16 0d 39 ... -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Feb 11 03:29:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21815 for ; Wed, 11 Feb 2004 03:29:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqpjx-0007em-Lr; Wed, 11 Feb 2004 03:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqpjV-0007cc-Mm for megaco@optimus.ietf.org; Wed, 11 Feb 2004 03:28:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21779 for ; Wed, 11 Feb 2004 03:28:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqpjT-0006Gt-00 for megaco@ietf.org; Wed, 11 Feb 2004 03:28:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqpiV-0006Ba-00 for megaco@ietf.org; Wed, 11 Feb 2004 03:27:31 -0500 Received: from [211.160.15.6] (helo=mail.putian.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqphp-00061K-00 for megaco@ietf.org; Wed, 11 Feb 2004 03:26:50 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F078.E87CE2CA" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 11 Feb 2004 16:27:38 +0800 Message-ID: <006A9E7E02D21C45AC3CB741AEBF844EA88B7E@mail.putian.com> Thread-Topic: question about disconnection message from MGW Thread-Index: AcPweOejV4oP0nFwREW0synUBtEUbA== From: =?gb2312?B?0e7PyLKo?= To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 Subject: [Megaco] question about disconnection message from MGW Sender: megaco-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_001_01C3F078.E87CE2CA Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi,all if MGC receives a message svc.req(ROOT,Method=3DDisconnection) , I am not sure if MGC should sends audit command after svc.reply, and if MGC sends audit to MGW, how MGC should use audit.reply, that is what should MGC deal with the reply message. Thanks a lot! Simba =20 ------_=_NextPart_001_01C3F078.E87CE2CA Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable =B1=F9=B4=A8
Hi,all
if MGC receives a message=20 svc.req(ROOT,Method=3DDisconnection) ,
I am not sure if MGC should sends = audit=20 command after svc.reply,
and if MGC sends audit to MGW, how = MGC=20 should use audit.reply,
that is what should MGC deal with = the reply=20 message. Thanks a lot!
       &nbs= p;            = ;            =   =20 Simba

 

------_=_NextPart_001_01C3F078.E87CE2CA-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Feb 11 03:31:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21952 for ; Wed, 11 Feb 2004 03:31:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqplW-0007oP-Ap for megaco-archive@odin.ietf.org; Wed, 11 Feb 2004 03:30:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B8UcaB030027 for megaco-archive@odin.ietf.org; Wed, 11 Feb 2004 03:30:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqplV-0007oE-SH for megaco-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 03:30:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21874 for ; Wed, 11 Feb 2004 03:30:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqplT-0006UY-00 for megaco-web-archive@ietf.org; Wed, 11 Feb 2004 03:30:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqpkZ-0006OU-00 for megaco-web-archive@ietf.org; Wed, 11 Feb 2004 03:29:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqpjx-0006Hy-00 for megaco-web-archive@ietf.org; Wed, 11 Feb 2004 03:29:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqpjx-0007em-Lr; Wed, 11 Feb 2004 03:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqpjV-0007cc-Mm for megaco@optimus.ietf.org; Wed, 11 Feb 2004 03:28:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21779 for ; Wed, 11 Feb 2004 03:28:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqpjT-0006Gt-00 for megaco@ietf.org; Wed, 11 Feb 2004 03:28:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqpiV-0006Ba-00 for megaco@ietf.org; Wed, 11 Feb 2004 03:27:31 -0500 Received: from [211.160.15.6] (helo=mail.putian.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqphp-00061K-00 for megaco@ietf.org; Wed, 11 Feb 2004 03:26:50 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F078.E87CE2CA" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 11 Feb 2004 16:27:38 +0800 Message-ID: <006A9E7E02D21C45AC3CB741AEBF844EA88B7E@mail.putian.com> Thread-Topic: question about disconnection message from MGW Thread-Index: AcPweOejV4oP0nFwREW0synUBtEUbA== From: =?gb2312?B?0e7PyLKo?= To: Subject: [Megaco] question about disconnection message from MGW Sender: megaco-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F078.E87CE2CA Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi,all if MGC receives a message svc.req(ROOT,Method=3DDisconnection) , I am not sure if MGC should sends audit command after svc.reply, and if MGC sends audit to MGW, how MGC should use audit.reply, that is what should MGC deal with the reply message. Thanks a lot! Simba =20 ------_=_NextPart_001_01C3F078.E87CE2CA Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable =B1=F9=B4=A8
Hi,all
if MGC receives a message=20 svc.req(ROOT,Method=3DDisconnection) ,
I am not sure if MGC should sends = audit=20 command after svc.reply,
and if MGC sends audit to MGW, how = MGC=20 should use audit.reply,
that is what should MGC deal with = the reply=20 message. Thanks a lot!
       &nbs= p;            = ;            =   =20 Simba

 

------_=_NextPart_001_01C3F078.E87CE2CA-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Feb 11 09:12:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01548 for ; Wed, 11 Feb 2004 09:12:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqv5t-00053R-Ip; Wed, 11 Feb 2004 09:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqv5f-00052V-8s for megaco@optimus.ietf.org; Wed, 11 Feb 2004 09:11:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01539 for ; Wed, 11 Feb 2004 09:11:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqv5d-0007g2-00 for megaco@ietf.org; Wed, 11 Feb 2004 09:11:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqv4f-0007Za-00 for megaco@ietf.org; Wed, 11 Feb 2004 09:10:46 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqv3m-0007NU-00 for megaco@ietf.org; Wed, 11 Feb 2004 09:09:50 -0500 Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1BE9FD00558 for ; Wed, 11 Feb 2004 08:09:16 -0600 (CST) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id JAA01776; Wed, 11 Feb 2004 09:09:12 -0500 (EST) Cc: megaco@ietf.org Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id JAA01757; Wed, 11 Feb 2004 09:09:11 -0500 (EST) Message-ID: <402A3801.80307@bell-labs.com> Date: Wed, 11 Feb 2004 09:11:13 -0500 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Troy Cauble Original-CC: megaco@ietf.org Subject: Re: [Megaco] (no subject) References: <20040209131004.5509.qmail@webmail25.rediffmail.com> <4027DA06.3080704@bell-labs.com> In-Reply-To: <4027DA06.3080704@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Troy Cauble wrote: > kumaraswamy Uppu wrote: > >> Hi All, >> I have a query about BER encoding of serviceChangeReason Parameter. >> As per rfc 3525 , this string is first BER-encoded as an IA5String. >> The result of this BER-encoding is then encoded as an ASN.1 OCTET >> STRING type. >> This is the encoded buffer for this Parameter. >> 04 0F 16 0D 39 30 31 20 43 6F 6C 64 20 42 6F 6F 74 First I >> encoded it as IA5 string (16 0D 39 30 31 20 43 6F 6C 64 20 42 6F 6F >> 74) and then the result I encoded it as OctetString. >> When I tried to decode with Hammer Call Anaylzer its not decoding >> serviceChangeReason properly. >> >> Here Is the capture this packet. >> >> ---- UDP ---- >> ---- UDP header ---- >> 0B-81 = B81h [2945d] source port >> 0B-81 = B81h [2945d] destination port >> 00-7D = 7Dh [125d] length: octets include header (not less than 8) >> E4-9B = E49Bh [58523d] checksum: checksum is correct >> ---- UDP datagram ---- >> ---- H.248 ---- >> {1010 0000}= A0h [160d] tag: 0x00 [000] >> ---- Message ---- >> ---- version ---- >> {0000 0001}= 01h [001d] version >> ---- MId ---- >> ---- IP4Address ---- >> ---- address ---- >> address: 192.168.5.8 >> ---- Transactions ---- >> ---- TransactionRequest ---- >> ---- TransactionID ---- >> {0110 0101}= 65h [101d] transactionID >> ---- actions ---- >> ---- ActionRequest ---- >> ---- ContextID ---- >> {0000 0000}= 00h [000d] contextID >> ---- commandsRequest ---- >> ---- CommandRequest ---- >> ---- Command ---- >> ---- serviceChangeRequest ---- >> ---- TerminationIDList ---- >> ---- TerminationID ---- >> ---- wildcard ---- >> ---- WildcardField ---- >> ---- WildcardField ---- >> wildcardField: >> FF-FF-FF-FF-FF-FF-FF-FF- 00 >> ---- ServiceChangeParm ---- >> ---- ServiceChangeMethod ---- >> {0000 0011}= 03h [003d] >> ServiceChangeMethodrestart >> ---- ServiceChangeVersion ---- >> {0000 0001}= 01h [001d] >> ServiceChangeVersion >> ---- Value ---- >> value: 16-0D-39-30-31-20-43-6F- >> 6C-64-20-42-6F-6F-74 >> >> Is it correct ? Can any one help me in this. >> > > I have two guesses. > > It's been too long since I looked at BER internals, > but looking at the last part of your output. > > > ---- Value ---- > > value: 16-0D-39-30-31-20-43-6F-6C-64-20-42-6F-6F-74 > > > 9 0 1 sp C o l d sp B o o t > > 16-0D is the tag-len for an IA5String. > > Also, judging from the structured output of your call analyzer, > it appears that it found the positional OCTET-STRING tag-len > that proceeds the one for the IA5String. > > So one GUESS is that your call analyzer is broken/obsolete. > H.248 was out for some time before the serviceChangeReason was > clarified via an IG to be double wrapped. Actually, it's not > decoding anything wrong, it's just not decoding it fully. > > > > Guess 2: > > > This is the encoded buffer for this Parameter. > > 04 0F 16 0D 39 30 31 20 43 6F 6C 64 20 42 6F 6F 74 > > 04-0F should be the tag-len for the OCTET STRING. 0F is > the correct len. 04 appears to be an incorrect or paritial > tag. The tag should be 0x8004 before encoding. 0x8000 > comes from it being a context specific class (not universal). > The 0x8004 gets encoded into a multibyte form and comes out > > 11 04 0f 16 0d 39 ... > > -troy On review, my second guess is wrong. 04-0F is the correct tag-len for the octet string. It is not a context specific class. The context specific class is the Value level which requires another tag-len encoding. So the whole scReason would be a4 11 04 0f 16 0d 39 ... -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Feb 11 09:14:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01631 for ; Wed, 11 Feb 2004 09:14:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqv7a-0005Fc-2y for megaco-archive@odin.ietf.org; Wed, 11 Feb 2004 09:13:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BEDkAI020180 for megaco-archive@odin.ietf.org; Wed, 11 Feb 2004 09:13:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqv7Z-0005FP-VP for megaco-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 09:13:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01625 for ; Wed, 11 Feb 2004 09:13:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqv7Y-00005I-00 for megaco-web-archive@ietf.org; Wed, 11 Feb 2004 09:13:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqv6b-0007mi-00 for megaco-web-archive@ietf.org; Wed, 11 Feb 2004 09:12:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqv5t-0007gv-00 for megaco-web-archive@ietf.org; Wed, 11 Feb 2004 09:12:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqv5t-00053R-Ip; Wed, 11 Feb 2004 09:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqv5f-00052V-8s for megaco@optimus.ietf.org; Wed, 11 Feb 2004 09:11:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01539 for ; Wed, 11 Feb 2004 09:11:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqv5d-0007g2-00 for megaco@ietf.org; Wed, 11 Feb 2004 09:11:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqv4f-0007Za-00 for megaco@ietf.org; Wed, 11 Feb 2004 09:10:46 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqv3m-0007NU-00 for megaco@ietf.org; Wed, 11 Feb 2004 09:09:50 -0500 Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1BE9FD00558 for ; Wed, 11 Feb 2004 08:09:16 -0600 (CST) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id JAA01776; Wed, 11 Feb 2004 09:09:12 -0500 (EST) Cc: megaco@ietf.org Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id JAA01757; Wed, 11 Feb 2004 09:09:11 -0500 (EST) Message-ID: <402A3801.80307@bell-labs.com> Date: Wed, 11 Feb 2004 09:11:13 -0500 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Troy Cauble Original-CC: megaco@ietf.org Subject: Re: [Megaco] (no subject) References: <20040209131004.5509.qmail@webmail25.rediffmail.com> <4027DA06.3080704@bell-labs.com> In-Reply-To: <4027DA06.3080704@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Troy Cauble wrote: > kumaraswamy Uppu wrote: > >> Hi All, >> I have a query about BER encoding of serviceChangeReason Parameter. >> As per rfc 3525 , this string is first BER-encoded as an IA5String. >> The result of this BER-encoding is then encoded as an ASN.1 OCTET >> STRING type. >> This is the encoded buffer for this Parameter. >> 04 0F 16 0D 39 30 31 20 43 6F 6C 64 20 42 6F 6F 74 First I >> encoded it as IA5 string (16 0D 39 30 31 20 43 6F 6C 64 20 42 6F 6F >> 74) and then the result I encoded it as OctetString. >> When I tried to decode with Hammer Call Anaylzer its not decoding >> serviceChangeReason properly. >> >> Here Is the capture this packet. >> >> ---- UDP ---- >> ---- UDP header ---- >> 0B-81 = B81h [2945d] source port >> 0B-81 = B81h [2945d] destination port >> 00-7D = 7Dh [125d] length: octets include header (not less than 8) >> E4-9B = E49Bh [58523d] checksum: checksum is correct >> ---- UDP datagram ---- >> ---- H.248 ---- >> {1010 0000}= A0h [160d] tag: 0x00 [000] >> ---- Message ---- >> ---- version ---- >> {0000 0001}= 01h [001d] version >> ---- MId ---- >> ---- IP4Address ---- >> ---- address ---- >> address: 192.168.5.8 >> ---- Transactions ---- >> ---- TransactionRequest ---- >> ---- TransactionID ---- >> {0110 0101}= 65h [101d] transactionID >> ---- actions ---- >> ---- ActionRequest ---- >> ---- ContextID ---- >> {0000 0000}= 00h [000d] contextID >> ---- commandsRequest ---- >> ---- CommandRequest ---- >> ---- Command ---- >> ---- serviceChangeRequest ---- >> ---- TerminationIDList ---- >> ---- TerminationID ---- >> ---- wildcard ---- >> ---- WildcardField ---- >> ---- WildcardField ---- >> wildcardField: >> FF-FF-FF-FF-FF-FF-FF-FF- 00 >> ---- ServiceChangeParm ---- >> ---- ServiceChangeMethod ---- >> {0000 0011}= 03h [003d] >> ServiceChangeMethodrestart >> ---- ServiceChangeVersion ---- >> {0000 0001}= 01h [001d] >> ServiceChangeVersion >> ---- Value ---- >> value: 16-0D-39-30-31-20-43-6F- >> 6C-64-20-42-6F-6F-74 >> >> Is it correct ? Can any one help me in this. >> > > I have two guesses. > > It's been too long since I looked at BER internals, > but looking at the last part of your output. > > > ---- Value ---- > > value: 16-0D-39-30-31-20-43-6F-6C-64-20-42-6F-6F-74 > > > 9 0 1 sp C o l d sp B o o t > > 16-0D is the tag-len for an IA5String. > > Also, judging from the structured output of your call analyzer, > it appears that it found the positional OCTET-STRING tag-len > that proceeds the one for the IA5String. > > So one GUESS is that your call analyzer is broken/obsolete. > H.248 was out for some time before the serviceChangeReason was > clarified via an IG to be double wrapped. Actually, it's not > decoding anything wrong, it's just not decoding it fully. > > > > Guess 2: > > > This is the encoded buffer for this Parameter. > > 04 0F 16 0D 39 30 31 20 43 6F 6C 64 20 42 6F 6F 74 > > 04-0F should be the tag-len for the OCTET STRING. 0F is > the correct len. 04 appears to be an incorrect or paritial > tag. The tag should be 0x8004 before encoding. 0x8000 > comes from it being a context specific class (not universal). > The 0x8004 gets encoded into a multibyte form and comes out > > 11 04 0f 16 0d 39 ... > > -troy On review, my second guess is wrong. 04-0F is the correct tag-len for the octet string. It is not a context specific class. The context specific class is the Value level which requires another tag-len encoding. So the whole scReason would be a4 11 04 0f 16 0d 39 ... -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Feb 11 13:34:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12741 for ; Wed, 11 Feb 2004 13:34:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzBR-0006pp-1T; Wed, 11 Feb 2004 13:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzAf-0006nG-NM for megaco@optimus.ietf.org; Wed, 11 Feb 2004 13:33:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12712 for ; Wed, 11 Feb 2004 13:33:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzAd-0003rI-00 for megaco@ietf.org; Wed, 11 Feb 2004 13:33:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqz9f-0003k6-00 for megaco@ietf.org; Wed, 11 Feb 2004 13:32:12 -0500 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1Aqz99-0003b2-00 for megaco@ietf.org; Wed, 11 Feb 2004 13:31:39 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1BIV5D25996; Wed, 11 Feb 2004 13:31:05 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3D2A69>; Wed, 11 Feb 2004 13:31:05 -0500 Message-ID: From: "Kevin Boyle" To: ??? , megaco@ietf.org Subject: RE: [Megaco] question about disconnection message from MGW Date: Wed, 11 Feb 2004 13:31:00 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This would all depend upon what the MGC is trying to accomplish. How the MGC would use an audit depends heavily upon what function it performs. Note that there are no requirements as to when or how audits are performed. Audits are a tool to be used as appropriate by an implementation. Kevin ________________________________ From: yxb@cpit.com.cn [mailto:yxb@cpit.com.cn] Sent: Wednesday, February 11, 2004 3:28 AM To: megaco@ietf.org Subject: [Megaco] question about disconnection message from MGW Hi,all if MGC receives a message svc.req(ROOT,Method=Disconnection) , I am not sure if MGC should sends audit command after svc.reply, and if MGC sends audit to MGW, how MGC should use audit.reply, that is what should MGC deal with the reply message. Thanks a lot! Simba _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Feb 11 13:36:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12826 for ; Wed, 11 Feb 2004 13:36:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzDE-00073v-5R for megaco-archive@odin.ietf.org; Wed, 11 Feb 2004 13:36:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BIZqIg027143 for megaco-archive@odin.ietf.org; Wed, 11 Feb 2004 13:35:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzDE-00073i-0a for megaco-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 13:35:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12789 for ; Wed, 11 Feb 2004 13:35:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzDB-0004B2-00 for megaco-web-archive@ietf.org; Wed, 11 Feb 2004 13:35:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzCD-00043f-00 for megaco-web-archive@ietf.org; Wed, 11 Feb 2004 13:34:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqzBR-0003xs-00 for megaco-web-archive@ietf.org; Wed, 11 Feb 2004 13:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzBR-0006pp-1T; Wed, 11 Feb 2004 13:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzAf-0006nG-NM for megaco@optimus.ietf.org; Wed, 11 Feb 2004 13:33:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12712 for ; Wed, 11 Feb 2004 13:33:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzAd-0003rI-00 for megaco@ietf.org; Wed, 11 Feb 2004 13:33:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqz9f-0003k6-00 for megaco@ietf.org; Wed, 11 Feb 2004 13:32:12 -0500 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1Aqz99-0003b2-00 for megaco@ietf.org; Wed, 11 Feb 2004 13:31:39 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1BIV5D25996; Wed, 11 Feb 2004 13:31:05 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3D2A69>; Wed, 11 Feb 2004 13:31:05 -0500 Message-ID: From: "Kevin Boyle" To: ??? , megaco@ietf.org Subject: RE: [Megaco] question about disconnection message from MGW Date: Wed, 11 Feb 2004 13:31:00 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 This would all depend upon what the MGC is trying to accomplish. How the MGC would use an audit depends heavily upon what function it performs. Note that there are no requirements as to when or how audits are performed. Audits are a tool to be used as appropriate by an implementation. Kevin ________________________________ From: yxb@cpit.com.cn [mailto:yxb@cpit.com.cn] Sent: Wednesday, February 11, 2004 3:28 AM To: megaco@ietf.org Subject: [Megaco] question about disconnection message from MGW Hi,all if MGC receives a message svc.req(ROOT,Method=Disconnection) , I am not sure if MGC should sends audit command after svc.reply, and if MGC sends audit to MGW, how MGC should use audit.reply, that is what should MGC deal with the reply message. Thanks a lot! Simba _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Feb 11 20:06:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16190 for ; Wed, 11 Feb 2004 20:06:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5Ip-000253-01; Wed, 11 Feb 2004 20:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5I1-000245-I6 for megaco@optimus.ietf.org; Wed, 11 Feb 2004 20:05:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16104 for ; Wed, 11 Feb 2004 20:05:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5Hz-0001T2-00 for megaco@ietf.org; Wed, 11 Feb 2004 20:05:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar5Gu-0001K3-00 for megaco@ietf.org; Wed, 11 Feb 2004 20:04:05 -0500 Received: from [211.160.15.6] (helo=mail.putian.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar5G3-00012f-00 for megaco@ietf.org; Wed, 11 Feb 2004 20:03:11 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: Re: [Megaco] question about disconnection message from MGW X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 12 Feb 2004 09:02:18 +0800 Message-ID: <006A9E7E02D21C45AC3CB741AEBF844EA88D2C@mail.putian.com> Thread-Topic: [Megaco] question about disconnection message from MGW Thread-Index: AcPwzWk6naBLu8nzT2qdrSo7nGGXDQANKWHg From: =?utf-8?B?5p2o5YWI5rOi?= To: "Kevin Boyle" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Sender: megaco-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: base64 DQpUaGFuayBmb3IgeW91ciByZXBseSwgYnV0IGlmIE1HVyBzZW5kIERpc2Nvbm5lY3Rpb24gaW5k aWNhdGlvbiB0byBNR0MsIHdoaWNoIG1lYW5zDQpNR1cgZGlzY29ubmVjdGVkIGZyb20gTUdDIGp1 c3Qgbm93LCBub3cgTUdXIHJlc3RvcmVzIGNvbm5lY3Rpb24gd2l0aCBNR0MsIHRoZW4NCm1heWJl IHN0YXRlIG9mIHRoZSBNR1cgIGlzIGRpZmZlcmVudCBmcm9tIHdoYXQgTUdDIHJlZ2FyZGVkICwg c28gTUdDIG5lZWQgYXVkaXQgTUdXDQp0byBzeWNob3JuaXplIHdpdGggaXQuICBBbGwgYWJvdmUg Y2FuIGJlIGZvdW5kIGluIHRoZSBkb2N1bWVudDogZHJhZnQtaWV0Zi1tZWdhY28tY2FsbGZsb3dz LTAyLnR4dCwNCndoaWNoIHJlYWRzIGFzIGJlbG93Og0KDQpUaGUgTUcgaXNzdWVzIHRoZSBkaXNj b25uZWN0aW9uIG1ldGhvZCBvZiBTZXJ2aWNlIENoYW5nZSB3aGVuIGl0IGxvc3QNCnRoZSBjb21t dW5pY2F0aW9uIHdpdGggTUdDIGFuZCBsYXRlciByZWdhaW5zIGl0LiBUaGUgTUdDIG5vcm1hbGx5 DQpnZW5lcmF0ZXMgYW4gQXVkaXQgbWVzc2FnZSB0byBhc3Nlc3MgdGhlIHN0YXRlIG9mIHRoZSB0 ZXJtaW5hdGlvbnMNCmJlZm9yZSBhbmQgYWZ0ZXIgdGhlIGRpc2Nvbm5lY3Rpb24uIFRoZSBBdWRp dCBjb21tYW5kIGVuYWJsZXMgTUdDIHRvDQpzeW5jaHJvbml6ZSBpdHMgc3RhdGUgd2l0aCB0aGUg TUcncyBzdGF0ZS4NCg0KDQpUaG91Z2ggaXQgaXMgYSBkcmFmdCwgYnV0IEkgdGhpbmsgaXQgaXMg cmVhc29uYWJsZS4gV2hhdCBhYm91dCB5b3VyIG9waW5pb24/DQpUaGFua3MgZm9yIHlvdXIgcmVw bHkgYWdhaW4hDQoNCi0tLS0t5Y6f5aeL6YKu5Lu2LS0tLS0NCuWPkeS7tuS6ujogS2V2aW4gQm95 bGUgW21haWx0bzprYm95bGVAbm9ydGVsbmV0d29ya3MuY29tXQ0K5Y+R6YCB5pe26Ze0OiAyMDA0 5bm0MuaciDEy5pelIDI6MzENCuaUtuS7tuS6ujogw5HDrsOPw6jCssKoOyBtZWdhY29AaWV0Zi5v cmcNClRpdGxlOiBSRTogW01lZ2Fjb10gcXVlc3Rpb24gYWJvdXQgZGlzY29ubmVjdGlvbiBtZXNz YWdlIGZyb20gTUdXDQoNCg0KVGhpcyB3b3VsZCBhbGwgZGVwZW5kIHVwb24gd2hhdCB0aGUgTUdD IGlzIHRyeWluZyB0byBhY2NvbXBsaXNoLiAgSG93IHRoZQ0KTUdDIHdvdWxkIHVzZSBhbiBhdWRp dCBkZXBlbmRzIGhlYXZpbHkgdXBvbiB3aGF0IGZ1bmN0aW9uIGl0IHBlcmZvcm1zLg0KDQpOb3Rl IHRoYXQgdGhlcmUgYXJlIG5vIHJlcXVpcmVtZW50cyBhcyB0byB3aGVuIG9yIGhvdyBhdWRpdHMg YXJlIHBlcmZvcm1lZC4NCkF1ZGl0cyBhcmUgYSB0b29sIHRvIGJlIHVzZWQgYXMgYXBwcm9wcmlh dGUgYnkgYW4gaW1wbGVtZW50YXRpb24uDQoNCktldmluIA0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KCUZyb206IHl4YkBjcGl0LmNvbS5jbiBbbWFpbHRvOnl4YkBjcGl0LmNv bS5jbl0gDQoJU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMSwgMjAwNCAzOjI4IEFNDQoJVG86 IG1lZ2Fjb0BpZXRmLm9yZw0KCVN1YmplY3Q6IFtNZWdhY29dIHF1ZXN0aW9uIGFib3V0IGRpc2Nv bm5lY3Rpb24gbWVzc2FnZSBmcm9tIE1HVw0KCQ0KCQ0KCUhpLGFsbA0KCWlmIE1HQyByZWNlaXZl cyBhIG1lc3NhZ2Ugc3ZjLnJlcShST09ULE1ldGhvZD1EaXNjb25uZWN0aW9uKSAsDQoJSSBhbSBu b3Qgc3VyZSBpZiBNR0Mgc2hvdWxkIHNlbmRzIGF1ZGl0IGNvbW1hbmQgYWZ0ZXIgc3ZjLnJlcGx5 LA0KCWFuZCBpZiBNR0Mgc2VuZHMgYXVkaXQgdG8gTUdXLCBob3cgTUdDIHNob3VsZCB1c2UgYXVk aXQucmVwbHksDQoJdGhhdCBpcyB3aGF0IHNob3VsZCBNR0MgZGVhbCB3aXRoIHRoZSByZXBseSBt ZXNzYWdlLiBUaGFua3MgYSBsb3QhDQoJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBTaW1iYQ0KDQo= _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Feb 11 20:08:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16265 for ; Wed, 11 Feb 2004 20:08:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5Ka-0002Zl-Uh for megaco-archive@odin.ietf.org; Wed, 11 Feb 2004 20:07:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C17q1N009878 for megaco-archive@odin.ietf.org; Wed, 11 Feb 2004 20:07:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5KZ-0002Yj-Qb for megaco-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 20:07:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16248 for ; Wed, 11 Feb 2004 20:07:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5KX-0001lx-00 for megaco-web-archive@ietf.org; Wed, 11 Feb 2004 20:07:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar5Ja-0001fu-00 for megaco-web-archive@ietf.org; Wed, 11 Feb 2004 20:06:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5Io-0001a7-00 for megaco-web-archive@ietf.org; Wed, 11 Feb 2004 20:06:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5Ip-000253-01; Wed, 11 Feb 2004 20:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5I1-000245-I6 for megaco@optimus.ietf.org; Wed, 11 Feb 2004 20:05:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16104 for ; Wed, 11 Feb 2004 20:05:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5Hz-0001T2-00 for megaco@ietf.org; Wed, 11 Feb 2004 20:05:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar5Gu-0001K3-00 for megaco@ietf.org; Wed, 11 Feb 2004 20:04:05 -0500 Received: from [211.160.15.6] (helo=mail.putian.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar5G3-00012f-00 for megaco@ietf.org; Wed, 11 Feb 2004 20:03:11 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: Re: [Megaco] question about disconnection message from MGW X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 12 Feb 2004 09:02:18 +0800 Message-ID: <006A9E7E02D21C45AC3CB741AEBF844EA88D2C@mail.putian.com> Thread-Topic: [Megaco] question about disconnection message from MGW Thread-Index: AcPwzWk6naBLu8nzT2qdrSo7nGGXDQANKWHg From: =?utf-8?B?5p2o5YWI5rOi?= To: "Kevin Boyle" , Content-Transfer-Encoding: base64 Sender: megaco-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQpUaGFuayBmb3IgeW91ciByZXBseSwgYnV0IGlmIE1HVyBzZW5kIERpc2Nvbm5lY3Rpb24gaW5k aWNhdGlvbiB0byBNR0MsIHdoaWNoIG1lYW5zDQpNR1cgZGlzY29ubmVjdGVkIGZyb20gTUdDIGp1 c3Qgbm93LCBub3cgTUdXIHJlc3RvcmVzIGNvbm5lY3Rpb24gd2l0aCBNR0MsIHRoZW4NCm1heWJl IHN0YXRlIG9mIHRoZSBNR1cgIGlzIGRpZmZlcmVudCBmcm9tIHdoYXQgTUdDIHJlZ2FyZGVkICwg c28gTUdDIG5lZWQgYXVkaXQgTUdXDQp0byBzeWNob3JuaXplIHdpdGggaXQuICBBbGwgYWJvdmUg Y2FuIGJlIGZvdW5kIGluIHRoZSBkb2N1bWVudDogZHJhZnQtaWV0Zi1tZWdhY28tY2FsbGZsb3dz LTAyLnR4dCwNCndoaWNoIHJlYWRzIGFzIGJlbG93Og0KDQpUaGUgTUcgaXNzdWVzIHRoZSBkaXNj b25uZWN0aW9uIG1ldGhvZCBvZiBTZXJ2aWNlIENoYW5nZSB3aGVuIGl0IGxvc3QNCnRoZSBjb21t dW5pY2F0aW9uIHdpdGggTUdDIGFuZCBsYXRlciByZWdhaW5zIGl0LiBUaGUgTUdDIG5vcm1hbGx5 DQpnZW5lcmF0ZXMgYW4gQXVkaXQgbWVzc2FnZSB0byBhc3Nlc3MgdGhlIHN0YXRlIG9mIHRoZSB0 ZXJtaW5hdGlvbnMNCmJlZm9yZSBhbmQgYWZ0ZXIgdGhlIGRpc2Nvbm5lY3Rpb24uIFRoZSBBdWRp dCBjb21tYW5kIGVuYWJsZXMgTUdDIHRvDQpzeW5jaHJvbml6ZSBpdHMgc3RhdGUgd2l0aCB0aGUg TUcncyBzdGF0ZS4NCg0KDQpUaG91Z2ggaXQgaXMgYSBkcmFmdCwgYnV0IEkgdGhpbmsgaXQgaXMg cmVhc29uYWJsZS4gV2hhdCBhYm91dCB5b3VyIG9waW5pb24/DQpUaGFua3MgZm9yIHlvdXIgcmVw bHkgYWdhaW4hDQoNCi0tLS0t5Y6f5aeL6YKu5Lu2LS0tLS0NCuWPkeS7tuS6ujogS2V2aW4gQm95 bGUgW21haWx0bzprYm95bGVAbm9ydGVsbmV0d29ya3MuY29tXQ0K5Y+R6YCB5pe26Ze0OiAyMDA0 5bm0MuaciDEy5pelIDI6MzENCuaUtuS7tuS6ujogw5HDrsOPw6jCssKoOyBtZWdhY29AaWV0Zi5v cmcNClRpdGxlOiBSRTogW01lZ2Fjb10gcXVlc3Rpb24gYWJvdXQgZGlzY29ubmVjdGlvbiBtZXNz YWdlIGZyb20gTUdXDQoNCg0KVGhpcyB3b3VsZCBhbGwgZGVwZW5kIHVwb24gd2hhdCB0aGUgTUdD IGlzIHRyeWluZyB0byBhY2NvbXBsaXNoLiAgSG93IHRoZQ0KTUdDIHdvdWxkIHVzZSBhbiBhdWRp dCBkZXBlbmRzIGhlYXZpbHkgdXBvbiB3aGF0IGZ1bmN0aW9uIGl0IHBlcmZvcm1zLg0KDQpOb3Rl IHRoYXQgdGhlcmUgYXJlIG5vIHJlcXVpcmVtZW50cyBhcyB0byB3aGVuIG9yIGhvdyBhdWRpdHMg YXJlIHBlcmZvcm1lZC4NCkF1ZGl0cyBhcmUgYSB0b29sIHRvIGJlIHVzZWQgYXMgYXBwcm9wcmlh dGUgYnkgYW4gaW1wbGVtZW50YXRpb24uDQoNCktldmluIA0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KCUZyb206IHl4YkBjcGl0LmNvbS5jbiBbbWFpbHRvOnl4YkBjcGl0LmNv bS5jbl0gDQoJU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMSwgMjAwNCAzOjI4IEFNDQoJVG86 IG1lZ2Fjb0BpZXRmLm9yZw0KCVN1YmplY3Q6IFtNZWdhY29dIHF1ZXN0aW9uIGFib3V0IGRpc2Nv bm5lY3Rpb24gbWVzc2FnZSBmcm9tIE1HVw0KCQ0KCQ0KCUhpLGFsbA0KCWlmIE1HQyByZWNlaXZl cyBhIG1lc3NhZ2Ugc3ZjLnJlcShST09ULE1ldGhvZD1EaXNjb25uZWN0aW9uKSAsDQoJSSBhbSBu b3Qgc3VyZSBpZiBNR0Mgc2hvdWxkIHNlbmRzIGF1ZGl0IGNvbW1hbmQgYWZ0ZXIgc3ZjLnJlcGx5 LA0KCWFuZCBpZiBNR0Mgc2VuZHMgYXVkaXQgdG8gTUdXLCBob3cgTUdDIHNob3VsZCB1c2UgYXVk aXQucmVwbHksDQoJdGhhdCBpcyB3aGF0IHNob3VsZCBNR0MgZGVhbCB3aXRoIHRoZSByZXBseSBt ZXNzYWdlLiBUaGFua3MgYSBsb3QhDQoJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBTaW1iYQ0KDQo= _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Feb 11 21:08:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18151 for ; Wed, 11 Feb 2004 21:08:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar6Gn-0006su-8P; Wed, 11 Feb 2004 21:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar6GZ-0006pt-UT for megaco@optimus.ietf.org; Wed, 11 Feb 2004 21:07:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18134 for ; Wed, 11 Feb 2004 21:07:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar6GX-0007R6-00 for megaco@ietf.org; Wed, 11 Feb 2004 21:07:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar6FY-0007LI-00 for megaco@ietf.org; Wed, 11 Feb 2004 21:06:45 -0500 Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar6EZ-0007Bt-00 for megaco@ietf.org; Wed, 11 Feb 2004 21:05:44 -0500 Received: from z14593 (huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HSY00KWE81G85@mta1.huawei.com> for megaco@ietf.org; Thu, 12 Feb 2004 09:56:06 +0800 (CST) Date: Thu, 12 Feb 2004 10:06:05 +0800 From: Zhao Bo Subject: Re: [Megaco] question about disconnection message from MGW To: =?utf-8?B?5p2o5YWI5rOi?= Cc: megaco@ietf.org Message-id: <001c01c3f10c$cb38ba60$f8486e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 X-Mailer: Microsoft Outlook Express 5.50.4922.1500 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <006A9E7E02D21C45AC3CB741AEBF844EA88D2C@mail.putian.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: base64 Sender: megaco-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: base64 SGksIHBsZWFzZSByZWZlciB0byBzZWN0aW9uIDcuMjggb2YgSC4yNDguMSwgZGVzY3JpcHRpb24g b2YgU2VydmljZUNoYW5nZU1ldGhvZCAiRGlzY29ubmVjdGVkIjoNCg0KRGlzY29ubmVjdGVkOiBh bHdheXMgYXBwbGllZCB3aXRoIHRoZSBSb290IFRlcm1pbmF0aW9uSUQsIGluZGljYXRlcyB0aGF0 IHRoZSBNRyBsb3N0DQpjb21tdW5pY2F0aW9uIHdpdGggdGhlIE1HQywgYnV0IGl0IHdhcyBzdWJz ZXF1ZW50bHkgcmVzdG9yZWQgdG8gdGhlIHNhbWUgTUdDIChwb3NzaWJseQ0KYWZ0ZXIgdHJ5aW5n IG90aGVyIE1HQ3Mgb24gYSBwcmUtcHJvdmlzaW9uZWQgbGlzdCkuIFNpbmNlIE1HIHN0YXRlIG1h eSBoYXZlIGNoYW5nZWQsIHRoZQ0KTUdDIG1heSB3aXNoIHRvIHVzZSB0aGUgQXVkaXQgY29tbWFu ZCB0byByZXN5bmNocm9uaXplIGl0cyBzdGF0ZSB3aXRoIHRoZSBNRydzLg0KDQotLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIuadqOWFiOazoiIgPHl4YkBjcGl0LmNvbS5jbj4N ClRvOiAiS2V2aW4gQm95bGUiIDxrYm95bGVAbm9ydGVsbmV0d29ya3MuY29tPjsgPG1lZ2Fjb0Bp ZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxMiwgMjAwNCA5OjAyIEFNDQpTdWJq ZWN0OiBSZTogW01lZ2Fjb10gcXVlc3Rpb24gYWJvdXQgZGlzY29ubmVjdGlvbiBtZXNzYWdlIGZy b20gTUdXDQoNCg0KPiANCj4gVGhhbmsgZm9yIHlvdXIgcmVwbHksIGJ1dCBpZiBNR1cgc2VuZCBE aXNjb25uZWN0aW9uIGluZGljYXRpb24gdG8gTUdDLCB3aGljaCBtZWFucw0KPiBNR1cgZGlzY29u bmVjdGVkIGZyb20gTUdDIGp1c3Qgbm93LCBub3cgTUdXIHJlc3RvcmVzIGNvbm5lY3Rpb24gd2l0 aCBNR0MsIHRoZW4NCj4gbWF5YmUgc3RhdGUgb2YgdGhlIE1HVyAgaXMgZGlmZmVyZW50IGZyb20g d2hhdCBNR0MgcmVnYXJkZWQgLCBzbyBNR0MgbmVlZCBhdWRpdCBNR1cNCj4gdG8gc3ljaG9ybml6 ZSB3aXRoIGl0LiAgQWxsIGFib3ZlIGNhbiBiZSBmb3VuZCBpbiB0aGUgZG9jdW1lbnQ6IGRyYWZ0 LWlldGYtbWVnYWNvLWNhbGxmbG93cy0wMi50eHQsDQo+IHdoaWNoIHJlYWRzIGFzIGJlbG93Og0K PiANCj4gVGhlIE1HIGlzc3VlcyB0aGUgZGlzY29ubmVjdGlvbiBtZXRob2Qgb2YgU2VydmljZSBD aGFuZ2Ugd2hlbiBpdCBsb3N0DQo+IHRoZSBjb21tdW5pY2F0aW9uIHdpdGggTUdDIGFuZCBsYXRl ciByZWdhaW5zIGl0LiBUaGUgTUdDIG5vcm1hbGx5DQo+IGdlbmVyYXRlcyBhbiBBdWRpdCBtZXNz YWdlIHRvIGFzc2VzcyB0aGUgc3RhdGUgb2YgdGhlIHRlcm1pbmF0aW9ucw0KPiBiZWZvcmUgYW5k IGFmdGVyIHRoZSBkaXNjb25uZWN0aW9uLiBUaGUgQXVkaXQgY29tbWFuZCBlbmFibGVzIE1HQyB0 bw0KPiBzeW5jaHJvbml6ZSBpdHMgc3RhdGUgd2l0aCB0aGUgTUcncyBzdGF0ZS4NCj4gDQo+IA0K PiBUaG91Z2ggaXQgaXMgYSBkcmFmdCwgYnV0IEkgdGhpbmsgaXQgaXMgcmVhc29uYWJsZS4gV2hh dCBhYm91dCB5b3VyIG9waW5pb24/DQo+IFRoYW5rcyBmb3IgeW91ciByZXBseSBhZ2FpbiENCj4g DQo+IC0tLS0t5Y6f5aeL6YKu5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBLZXZpbiBCb3lsZSBbbWFp bHRvOmtib3lsZUBub3J0ZWxuZXR3b3Jrcy5jb21dDQo+IOWPkemAgeaXtumXtDogMjAwNOW5tDLm nIgxMuaXpSAyOjMxDQo+IOaUtuS7tuS6ujogw5HDrsOPw6jCssKoOyBtZWdhY29AaWV0Zi5vcmcN Cj4gVGl0bGU6IFJFOiBbTWVnYWNvXSBxdWVzdGlvbiBhYm91dCBkaXNjb25uZWN0aW9uIG1lc3Nh Z2UgZnJvbSBNR1cNCj4gDQo+IA0KPiBUaGlzIHdvdWxkIGFsbCBkZXBlbmQgdXBvbiB3aGF0IHRo ZSBNR0MgaXMgdHJ5aW5nIHRvIGFjY29tcGxpc2guICBIb3cgdGhlDQo+IE1HQyB3b3VsZCB1c2Ug YW4gYXVkaXQgZGVwZW5kcyBoZWF2aWx5IHVwb24gd2hhdCBmdW5jdGlvbiBpdCBwZXJmb3Jtcy4N Cj4gDQo+IE5vdGUgdGhhdCB0aGVyZSBhcmUgbm8gcmVxdWlyZW1lbnRzIGFzIHRvIHdoZW4gb3Ig aG93IGF1ZGl0cyBhcmUgcGVyZm9ybWVkLg0KPiBBdWRpdHMgYXJlIGEgdG9vbCB0byBiZSB1c2Vk IGFzIGFwcHJvcHJpYXRlIGJ5IGFuIGltcGxlbWVudGF0aW9uLg0KPiANCj4gS2V2aW4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiBGcm9tOiB5eGJAY3BpdC5jb20u Y24gW21haWx0bzp5eGJAY3BpdC5jb20uY25dIA0KPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5 IDExLCAyMDA0IDM6MjggQU0NCj4gVG86IG1lZ2Fjb0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbTWVn YWNvXSBxdWVzdGlvbiBhYm91dCBkaXNjb25uZWN0aW9uIG1lc3NhZ2UgZnJvbSBNR1cNCj4gDQo+ IA0KPiBIaSxhbGwNCj4gaWYgTUdDIHJlY2VpdmVzIGEgbWVzc2FnZSBzdmMucmVxKFJPT1QsTWV0 aG9kPURpc2Nvbm5lY3Rpb24pICwNCj4gSSBhbSBub3Qgc3VyZSBpZiBNR0Mgc2hvdWxkIHNlbmRz IGF1ZGl0IGNvbW1hbmQgYWZ0ZXIgc3ZjLnJlcGx5LA0KPiBhbmQgaWYgTUdDIHNlbmRzIGF1ZGl0 IHRvIE1HVywgaG93IE1HQyBzaG91bGQgdXNlIGF1ZGl0LnJlcGx5LA0KPiB0aGF0IGlzIHdoYXQg c2hvdWxkIE1HQyBkZWFsIHdpdGggdGhlIHJlcGx5IG1lc3NhZ2UuIFRoYW5rcyBhIGxvdCENCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTaW1iYQ0KPiANCj4gMXLoiYpYWGkg eteuCG0/IDAgJ34gZmZYKSAo _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Feb 11 21:10:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18324 for ; Wed, 11 Feb 2004 21:10:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar6IX-0007GN-Su for megaco-archive@odin.ietf.org; Wed, 11 Feb 2004 21:09:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C29nKd027913 for megaco-archive@odin.ietf.org; Wed, 11 Feb 2004 21:09:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar6IX-0007G8-Ow for megaco-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 21:09:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18202 for ; Wed, 11 Feb 2004 21:09:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar6IV-0007cQ-00 for megaco-web-archive@ietf.org; Wed, 11 Feb 2004 21:09:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar6HY-0007X2-00 for megaco-web-archive@ietf.org; Wed, 11 Feb 2004 21:08:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar6Gn-0007S7-00 for megaco-web-archive@ietf.org; Wed, 11 Feb 2004 21:08:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar6Gn-0006su-8P; Wed, 11 Feb 2004 21:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar6GZ-0006pt-UT for megaco@optimus.ietf.org; Wed, 11 Feb 2004 21:07:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18134 for ; Wed, 11 Feb 2004 21:07:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar6GX-0007R6-00 for megaco@ietf.org; Wed, 11 Feb 2004 21:07:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar6FY-0007LI-00 for megaco@ietf.org; Wed, 11 Feb 2004 21:06:45 -0500 Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar6EZ-0007Bt-00 for megaco@ietf.org; Wed, 11 Feb 2004 21:05:44 -0500 Received: from z14593 (huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HSY00KWE81G85@mta1.huawei.com> for megaco@ietf.org; Thu, 12 Feb 2004 09:56:06 +0800 (CST) Date: Thu, 12 Feb 2004 10:06:05 +0800 From: Zhao Bo Subject: Re: [Megaco] question about disconnection message from MGW To: =?utf-8?B?5p2o5YWI5rOi?= Cc: megaco@ietf.org Message-id: <001c01c3f10c$cb38ba60$f8486e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 X-Mailer: Microsoft Outlook Express 5.50.4922.1500 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <006A9E7E02D21C45AC3CB741AEBF844EA88D2C@mail.putian.com> Content-Transfer-Encoding: base64 Sender: megaco-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGksIHBsZWFzZSByZWZlciB0byBzZWN0aW9uIDcuMjggb2YgSC4yNDguMSwgZGVzY3JpcHRpb24g b2YgU2VydmljZUNoYW5nZU1ldGhvZCAiRGlzY29ubmVjdGVkIjoNCg0KRGlzY29ubmVjdGVkOiBh bHdheXMgYXBwbGllZCB3aXRoIHRoZSBSb290IFRlcm1pbmF0aW9uSUQsIGluZGljYXRlcyB0aGF0 IHRoZSBNRyBsb3N0DQpjb21tdW5pY2F0aW9uIHdpdGggdGhlIE1HQywgYnV0IGl0IHdhcyBzdWJz ZXF1ZW50bHkgcmVzdG9yZWQgdG8gdGhlIHNhbWUgTUdDIChwb3NzaWJseQ0KYWZ0ZXIgdHJ5aW5n IG90aGVyIE1HQ3Mgb24gYSBwcmUtcHJvdmlzaW9uZWQgbGlzdCkuIFNpbmNlIE1HIHN0YXRlIG1h eSBoYXZlIGNoYW5nZWQsIHRoZQ0KTUdDIG1heSB3aXNoIHRvIHVzZSB0aGUgQXVkaXQgY29tbWFu ZCB0byByZXN5bmNocm9uaXplIGl0cyBzdGF0ZSB3aXRoIHRoZSBNRydzLg0KDQotLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIuadqOWFiOazoiIgPHl4YkBjcGl0LmNvbS5jbj4N ClRvOiAiS2V2aW4gQm95bGUiIDxrYm95bGVAbm9ydGVsbmV0d29ya3MuY29tPjsgPG1lZ2Fjb0Bp ZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxMiwgMjAwNCA5OjAyIEFNDQpTdWJq ZWN0OiBSZTogW01lZ2Fjb10gcXVlc3Rpb24gYWJvdXQgZGlzY29ubmVjdGlvbiBtZXNzYWdlIGZy b20gTUdXDQoNCg0KPiANCj4gVGhhbmsgZm9yIHlvdXIgcmVwbHksIGJ1dCBpZiBNR1cgc2VuZCBE aXNjb25uZWN0aW9uIGluZGljYXRpb24gdG8gTUdDLCB3aGljaCBtZWFucw0KPiBNR1cgZGlzY29u bmVjdGVkIGZyb20gTUdDIGp1c3Qgbm93LCBub3cgTUdXIHJlc3RvcmVzIGNvbm5lY3Rpb24gd2l0 aCBNR0MsIHRoZW4NCj4gbWF5YmUgc3RhdGUgb2YgdGhlIE1HVyAgaXMgZGlmZmVyZW50IGZyb20g d2hhdCBNR0MgcmVnYXJkZWQgLCBzbyBNR0MgbmVlZCBhdWRpdCBNR1cNCj4gdG8gc3ljaG9ybml6 ZSB3aXRoIGl0LiAgQWxsIGFib3ZlIGNhbiBiZSBmb3VuZCBpbiB0aGUgZG9jdW1lbnQ6IGRyYWZ0 LWlldGYtbWVnYWNvLWNhbGxmbG93cy0wMi50eHQsDQo+IHdoaWNoIHJlYWRzIGFzIGJlbG93Og0K PiANCj4gVGhlIE1HIGlzc3VlcyB0aGUgZGlzY29ubmVjdGlvbiBtZXRob2Qgb2YgU2VydmljZSBD aGFuZ2Ugd2hlbiBpdCBsb3N0DQo+IHRoZSBjb21tdW5pY2F0aW9uIHdpdGggTUdDIGFuZCBsYXRl ciByZWdhaW5zIGl0LiBUaGUgTUdDIG5vcm1hbGx5DQo+IGdlbmVyYXRlcyBhbiBBdWRpdCBtZXNz YWdlIHRvIGFzc2VzcyB0aGUgc3RhdGUgb2YgdGhlIHRlcm1pbmF0aW9ucw0KPiBiZWZvcmUgYW5k IGFmdGVyIHRoZSBkaXNjb25uZWN0aW9uLiBUaGUgQXVkaXQgY29tbWFuZCBlbmFibGVzIE1HQyB0 bw0KPiBzeW5jaHJvbml6ZSBpdHMgc3RhdGUgd2l0aCB0aGUgTUcncyBzdGF0ZS4NCj4gDQo+IA0K PiBUaG91Z2ggaXQgaXMgYSBkcmFmdCwgYnV0IEkgdGhpbmsgaXQgaXMgcmVhc29uYWJsZS4gV2hh dCBhYm91dCB5b3VyIG9waW5pb24/DQo+IFRoYW5rcyBmb3IgeW91ciByZXBseSBhZ2FpbiENCj4g DQo+IC0tLS0t5Y6f5aeL6YKu5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBLZXZpbiBCb3lsZSBbbWFp bHRvOmtib3lsZUBub3J0ZWxuZXR3b3Jrcy5jb21dDQo+IOWPkemAgeaXtumXtDogMjAwNOW5tDLm nIgxMuaXpSAyOjMxDQo+IOaUtuS7tuS6ujogw5HDrsOPw6jCssKoOyBtZWdhY29AaWV0Zi5vcmcN Cj4gVGl0bGU6IFJFOiBbTWVnYWNvXSBxdWVzdGlvbiBhYm91dCBkaXNjb25uZWN0aW9uIG1lc3Nh Z2UgZnJvbSBNR1cNCj4gDQo+IA0KPiBUaGlzIHdvdWxkIGFsbCBkZXBlbmQgdXBvbiB3aGF0IHRo ZSBNR0MgaXMgdHJ5aW5nIHRvIGFjY29tcGxpc2guICBIb3cgdGhlDQo+IE1HQyB3b3VsZCB1c2Ug YW4gYXVkaXQgZGVwZW5kcyBoZWF2aWx5IHVwb24gd2hhdCBmdW5jdGlvbiBpdCBwZXJmb3Jtcy4N Cj4gDQo+IE5vdGUgdGhhdCB0aGVyZSBhcmUgbm8gcmVxdWlyZW1lbnRzIGFzIHRvIHdoZW4gb3Ig aG93IGF1ZGl0cyBhcmUgcGVyZm9ybWVkLg0KPiBBdWRpdHMgYXJlIGEgdG9vbCB0byBiZSB1c2Vk IGFzIGFwcHJvcHJpYXRlIGJ5IGFuIGltcGxlbWVudGF0aW9uLg0KPiANCj4gS2V2aW4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiBGcm9tOiB5eGJAY3BpdC5jb20u Y24gW21haWx0bzp5eGJAY3BpdC5jb20uY25dIA0KPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5 IDExLCAyMDA0IDM6MjggQU0NCj4gVG86IG1lZ2Fjb0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbTWVn YWNvXSBxdWVzdGlvbiBhYm91dCBkaXNjb25uZWN0aW9uIG1lc3NhZ2UgZnJvbSBNR1cNCj4gDQo+ IA0KPiBIaSxhbGwNCj4gaWYgTUdDIHJlY2VpdmVzIGEgbWVzc2FnZSBzdmMucmVxKFJPT1QsTWV0 aG9kPURpc2Nvbm5lY3Rpb24pICwNCj4gSSBhbSBub3Qgc3VyZSBpZiBNR0Mgc2hvdWxkIHNlbmRz IGF1ZGl0IGNvbW1hbmQgYWZ0ZXIgc3ZjLnJlcGx5LA0KPiBhbmQgaWYgTUdDIHNlbmRzIGF1ZGl0 IHRvIE1HVywgaG93IE1HQyBzaG91bGQgdXNlIGF1ZGl0LnJlcGx5LA0KPiB0aGF0IGlzIHdoYXQg c2hvdWxkIE1HQyBkZWFsIHdpdGggdGhlIHJlcGx5IG1lc3NhZ2UuIFRoYW5rcyBhIGxvdCENCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTaW1iYQ0KPiANCj4gMXLoiYpYWGkg eteuCG0/IDAgJ34gZmZYKSAo _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Feb 11 21:33:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19741 for ; Wed, 11 Feb 2004 21:33:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar6f1-0000AA-7X; Wed, 11 Feb 2004 21:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar6en-00008N-9p for megaco@optimus.ietf.org; Wed, 11 Feb 2004 21:32:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19716 for ; Wed, 11 Feb 2004 21:32:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar6ek-0002c6-00 for megaco@ietf.org; Wed, 11 Feb 2004 21:32:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar6dx-0002Sy-00 for megaco@ietf.org; Wed, 11 Feb 2004 21:31:58 -0500 Received: from [211.160.15.6] (helo=mail.putian.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar6cz-0002BS-00 for megaco@ietf.org; Wed, 11 Feb 2004 21:30:58 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 12 Feb 2004 10:31:43 +0800 Message-ID: <006A9E7E02D21C45AC3CB741AEBF844EA88F1D@mail.putian.com> Thread-Topic: [Megaco] question about disconnection message from MGW Thread-Index: AcPxDNaD+mjLqrOZQdeVV6B+wRSfLQAAvamw From: =?utf-8?B?5p2o5YWI5rOi?= To: "Zhao Bo" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Subject: [Megaco] =?utf-8?Q?=E7=AD=94=E5=A4=8D=3A_=5BMegaco=5D_question_about_disc?= =?utf-8?Q?onnection_message_from_MGW?= Sender: megaco-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: base64 DQpUaGVuIHdoYXQgZG8geW91IHRoaW5rIG9mICJyZXN5bmNocm9uaXplIGl0cyBzdGF0ZSB3aXRo IHRoZSBNRydzIj8NCndoYXQgZG9lcyByZXN5bmNocm9uaXplIG1lYW4/DQp3aGF0IE1HQyBzaG91 bGQgZGVhbCB3aXRoIGF1ZGl0LnJlcGx5IG1lc3NhZ2UsIHN1Y2ggYXMgbWVkaWFkZXNjLCBzaWdu YWxzZGVzYywNCmV2ZW50c2Rlc2MsIHN0YXRpc3RpY3NkZXNjIGFuZCBvdGhlcj8NCg0KLS0tLS3l jp/lp4vpgq7ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBaaGFvIEJvIFttYWlsdG86emJvQGh1YXdlaS5j b21dDQrlj5HpgIHml7bpl7Q6IDIwMDTlubQy5pyIMTLml6UgMTA6MDYNCuaUtuS7tuS6ujog5p2o 5YWI5rOiDQrmioTpgIE6IG1lZ2Fjb0BpZXRmLm9yZw0K5Li76aKYOiBSZTogW01lZ2Fjb10gcXVl c3Rpb24gYWJvdXQgZGlzY29ubmVjdGlvbiBtZXNzYWdlIGZyb20gTUdXDQoNCg0KSGksIHBsZWFz ZSByZWZlciB0byBzZWN0aW9uIDcuMjggb2YgSC4yNDguMSwgZGVzY3JpcHRpb24gb2YgU2Vydmlj ZUNoYW5nZU1ldGhvZCAiRGlzY29ubmVjdGVkIjoNCg0KRGlzY29ubmVjdGVkOiBhbHdheXMgYXBw bGllZCB3aXRoIHRoZSBSb290IFRlcm1pbmF0aW9uSUQsIGluZGljYXRlcyB0aGF0IHRoZSBNRyBs b3N0DQpjb21tdW5pY2F0aW9uIHdpdGggdGhlIE1HQywgYnV0IGl0IHdhcyBzdWJzZXF1ZW50bHkg cmVzdG9yZWQgdG8gdGhlIHNhbWUgTUdDIChwb3NzaWJseQ0KYWZ0ZXIgdHJ5aW5nIG90aGVyIE1H Q3Mgb24gYSBwcmUtcHJvdmlzaW9uZWQgbGlzdCkuIFNpbmNlIE1HIHN0YXRlIG1heSBoYXZlIGNo YW5nZWQsIHRoZQ0KTUdDIG1heSB3aXNoIHRvIHVzZSB0aGUgQXVkaXQgY29tbWFuZCB0byByZXN5 bmNocm9uaXplIGl0cyBzdGF0ZSB3aXRoIHRoZSBNRydzLg0KDQotLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tIA0KRnJvbTogIuadqOWFiOazoiIgPHl4YkBjcGl0LmNvbS5jbj4NClRvOiAiS2V2 aW4gQm95bGUiIDxrYm95bGVAbm9ydGVsbmV0d29ya3MuY29tPjsgPG1lZ2Fjb0BpZXRmLm9yZz4N ClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxMiwgMjAwNCA5OjAyIEFNDQpTdWJqZWN0OiBSZTog W01lZ2Fjb10gcXVlc3Rpb24gYWJvdXQgZGlzY29ubmVjdGlvbiBtZXNzYWdlIGZyb20gTUdXDQoN Cg0KPiANCj4gVGhhbmsgZm9yIHlvdXIgcmVwbHksIGJ1dCBpZiBNR1cgc2VuZCBEaXNjb25uZWN0 aW9uIGluZGljYXRpb24gdG8gTUdDLCB3aGljaCBtZWFucw0KPiBNR1cgZGlzY29ubmVjdGVkIGZy b20gTUdDIGp1c3Qgbm93LCBub3cgTUdXIHJlc3RvcmVzIGNvbm5lY3Rpb24gd2l0aCBNR0MsIHRo ZW4NCj4gbWF5YmUgc3RhdGUgb2YgdGhlIE1HVyAgaXMgZGlmZmVyZW50IGZyb20gd2hhdCBNR0Mg cmVnYXJkZWQgLCBzbyBNR0MgbmVlZCBhdWRpdCBNR1cNCj4gdG8gc3ljaG9ybml6ZSB3aXRoIGl0 LiAgQWxsIGFib3ZlIGNhbiBiZSBmb3VuZCBpbiB0aGUgZG9jdW1lbnQ6IGRyYWZ0LWlldGYtbWVn YWNvLWNhbGxmbG93cy0wMi50eHQsDQo+IHdoaWNoIHJlYWRzIGFzIGJlbG93Og0KPiANCj4gVGhl IE1HIGlzc3VlcyB0aGUgZGlzY29ubmVjdGlvbiBtZXRob2Qgb2YgU2VydmljZSBDaGFuZ2Ugd2hl biBpdCBsb3N0DQo+IHRoZSBjb21tdW5pY2F0aW9uIHdpdGggTUdDIGFuZCBsYXRlciByZWdhaW5z IGl0LiBUaGUgTUdDIG5vcm1hbGx5DQo+IGdlbmVyYXRlcyBhbiBBdWRpdCBtZXNzYWdlIHRvIGFz c2VzcyB0aGUgc3RhdGUgb2YgdGhlIHRlcm1pbmF0aW9ucw0KPiBiZWZvcmUgYW5kIGFmdGVyIHRo ZSBkaXNjb25uZWN0aW9uLiBUaGUgQXVkaXQgY29tbWFuZCBlbmFibGVzIE1HQyB0bw0KPiBzeW5j aHJvbml6ZSBpdHMgc3RhdGUgd2l0aCB0aGUgTUcncyBzdGF0ZS4NCj4gDQo+IA0KPiBUaG91Z2gg aXQgaXMgYSBkcmFmdCwgYnV0IEkgdGhpbmsgaXQgaXMgcmVhc29uYWJsZS4gV2hhdCBhYm91dCB5 b3VyIG9waW5pb24/DQo+IFRoYW5rcyBmb3IgeW91ciByZXBseSBhZ2FpbiENCj4gDQo+IC0tLS0t 5Y6f5aeL6YKu5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBLZXZpbiBCb3lsZSBbbWFpbHRvOmtib3ls ZUBub3J0ZWxuZXR3b3Jrcy5jb21dDQo+IOWPkemAgeaXtumXtDogMjAwNOW5tDLmnIgxMuaXpSAy OjMxDQo+IOaUtuS7tuS6ujogw5HDrsOPw6jCssKoOyBtZWdhY29AaWV0Zi5vcmcNCj4gVGl0bGU6 IFJFOiBbTWVnYWNvXSBxdWVzdGlvbiBhYm91dCBkaXNjb25uZWN0aW9uIG1lc3NhZ2UgZnJvbSBN R1cNCj4gDQo+IA0KPiBUaGlzIHdvdWxkIGFsbCBkZXBlbmQgdXBvbiB3aGF0IHRoZSBNR0MgaXMg dHJ5aW5nIHRvIGFjY29tcGxpc2guICBIb3cgdGhlDQo+IE1HQyB3b3VsZCB1c2UgYW4gYXVkaXQg ZGVwZW5kcyBoZWF2aWx5IHVwb24gd2hhdCBmdW5jdGlvbiBpdCBwZXJmb3Jtcy4NCj4gDQo+IE5v dGUgdGhhdCB0aGVyZSBhcmUgbm8gcmVxdWlyZW1lbnRzIGFzIHRvIHdoZW4gb3IgaG93IGF1ZGl0 cyBhcmUgcGVyZm9ybWVkLg0KPiBBdWRpdHMgYXJlIGEgdG9vbCB0byBiZSB1c2VkIGFzIGFwcHJv cHJpYXRlIGJ5IGFuIGltcGxlbWVudGF0aW9uLg0KPiANCj4gS2V2aW4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiBGcm9tOiB5eGJAY3BpdC5jb20uY24gW21haWx0 bzp5eGJAY3BpdC5jb20uY25dIA0KPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDA0 IDM6MjggQU0NCj4gVG86IG1lZ2Fjb0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbTWVnYWNvXSBxdWVz dGlvbiBhYm91dCBkaXNjb25uZWN0aW9uIG1lc3NhZ2UgZnJvbSBNR1cNCj4gDQo+IA0KPiBIaSxh bGwNCj4gaWYgTUdDIHJlY2VpdmVzIGEgbWVzc2FnZSBzdmMucmVxKFJPT1QsTWV0aG9kPURpc2Nv bm5lY3Rpb24pICwNCj4gSSBhbSBub3Qgc3VyZSBpZiBNR0Mgc2hvdWxkIHNlbmRzIGF1ZGl0IGNv bW1hbmQgYWZ0ZXIgc3ZjLnJlcGx5LA0KPiBhbmQgaWYgTUdDIHNlbmRzIGF1ZGl0IHRvIE1HVywg aG93IE1HQyBzaG91bGQgdXNlIGF1ZGl0LnJlcGx5LA0KPiB0aGF0IGlzIHdoYXQgc2hvdWxkIE1H QyBkZWFsIHdpdGggdGhlIHJlcGx5IG1lc3NhZ2UuIFRoYW5rcyBhIGxvdCENCj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBTaW1iYQ0KPiANCj4gMXLoiYpYWGkgeteuCG0/IDAg J34gZmZYKSAoDQo= _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Feb 11 21:35:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19817 for ; Wed, 11 Feb 2004 21:35:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar6gr-0000IV-Rb for megaco-archive@odin.ietf.org; Wed, 11 Feb 2004 21:34:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C2YvhY001137 for megaco-archive@odin.ietf.org; Wed, 11 Feb 2004 21:34:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar6gr-0000IG-Nb for megaco-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 21:34:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19795 for ; Wed, 11 Feb 2004 21:34:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar6go-0002rc-00 for megaco-web-archive@ietf.org; Wed, 11 Feb 2004 21:34:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar6fv-0002lA-00 for megaco-web-archive@ietf.org; Wed, 11 Feb 2004 21:33:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar6f0-0002eV-00 for megaco-web-archive@ietf.org; Wed, 11 Feb 2004 21:33:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar6f1-0000AA-7X; Wed, 11 Feb 2004 21:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar6en-00008N-9p for megaco@optimus.ietf.org; Wed, 11 Feb 2004 21:32:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19716 for ; Wed, 11 Feb 2004 21:32:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar6ek-0002c6-00 for megaco@ietf.org; Wed, 11 Feb 2004 21:32:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar6dx-0002Sy-00 for megaco@ietf.org; Wed, 11 Feb 2004 21:31:58 -0500 Received: from [211.160.15.6] (helo=mail.putian.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar6cz-0002BS-00 for megaco@ietf.org; Wed, 11 Feb 2004 21:30:58 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 12 Feb 2004 10:31:43 +0800 Message-ID: <006A9E7E02D21C45AC3CB741AEBF844EA88F1D@mail.putian.com> Thread-Topic: [Megaco] question about disconnection message from MGW Thread-Index: AcPxDNaD+mjLqrOZQdeVV6B+wRSfLQAAvamw From: =?utf-8?B?5p2o5YWI5rOi?= To: "Zhao Bo" Cc: Content-Transfer-Encoding: base64 Subject: [Megaco] =?utf-8?Q?=E7=AD=94=E5=A4=8D=3A_=5BMegaco=5D_question_about_disc?= =?utf-8?Q?onnection_message_from_MGW?= Sender: megaco-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQpUaGVuIHdoYXQgZG8geW91IHRoaW5rIG9mICJyZXN5bmNocm9uaXplIGl0cyBzdGF0ZSB3aXRo IHRoZSBNRydzIj8NCndoYXQgZG9lcyByZXN5bmNocm9uaXplIG1lYW4/DQp3aGF0IE1HQyBzaG91 bGQgZGVhbCB3aXRoIGF1ZGl0LnJlcGx5IG1lc3NhZ2UsIHN1Y2ggYXMgbWVkaWFkZXNjLCBzaWdu YWxzZGVzYywNCmV2ZW50c2Rlc2MsIHN0YXRpc3RpY3NkZXNjIGFuZCBvdGhlcj8NCg0KLS0tLS3l jp/lp4vpgq7ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBaaGFvIEJvIFttYWlsdG86emJvQGh1YXdlaS5j b21dDQrlj5HpgIHml7bpl7Q6IDIwMDTlubQy5pyIMTLml6UgMTA6MDYNCuaUtuS7tuS6ujog5p2o 5YWI5rOiDQrmioTpgIE6IG1lZ2Fjb0BpZXRmLm9yZw0K5Li76aKYOiBSZTogW01lZ2Fjb10gcXVl c3Rpb24gYWJvdXQgZGlzY29ubmVjdGlvbiBtZXNzYWdlIGZyb20gTUdXDQoNCg0KSGksIHBsZWFz ZSByZWZlciB0byBzZWN0aW9uIDcuMjggb2YgSC4yNDguMSwgZGVzY3JpcHRpb24gb2YgU2Vydmlj ZUNoYW5nZU1ldGhvZCAiRGlzY29ubmVjdGVkIjoNCg0KRGlzY29ubmVjdGVkOiBhbHdheXMgYXBw bGllZCB3aXRoIHRoZSBSb290IFRlcm1pbmF0aW9uSUQsIGluZGljYXRlcyB0aGF0IHRoZSBNRyBs b3N0DQpjb21tdW5pY2F0aW9uIHdpdGggdGhlIE1HQywgYnV0IGl0IHdhcyBzdWJzZXF1ZW50bHkg cmVzdG9yZWQgdG8gdGhlIHNhbWUgTUdDIChwb3NzaWJseQ0KYWZ0ZXIgdHJ5aW5nIG90aGVyIE1H Q3Mgb24gYSBwcmUtcHJvdmlzaW9uZWQgbGlzdCkuIFNpbmNlIE1HIHN0YXRlIG1heSBoYXZlIGNo YW5nZWQsIHRoZQ0KTUdDIG1heSB3aXNoIHRvIHVzZSB0aGUgQXVkaXQgY29tbWFuZCB0byByZXN5 bmNocm9uaXplIGl0cyBzdGF0ZSB3aXRoIHRoZSBNRydzLg0KDQotLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tIA0KRnJvbTogIuadqOWFiOazoiIgPHl4YkBjcGl0LmNvbS5jbj4NClRvOiAiS2V2 aW4gQm95bGUiIDxrYm95bGVAbm9ydGVsbmV0d29ya3MuY29tPjsgPG1lZ2Fjb0BpZXRmLm9yZz4N ClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxMiwgMjAwNCA5OjAyIEFNDQpTdWJqZWN0OiBSZTog W01lZ2Fjb10gcXVlc3Rpb24gYWJvdXQgZGlzY29ubmVjdGlvbiBtZXNzYWdlIGZyb20gTUdXDQoN Cg0KPiANCj4gVGhhbmsgZm9yIHlvdXIgcmVwbHksIGJ1dCBpZiBNR1cgc2VuZCBEaXNjb25uZWN0 aW9uIGluZGljYXRpb24gdG8gTUdDLCB3aGljaCBtZWFucw0KPiBNR1cgZGlzY29ubmVjdGVkIGZy b20gTUdDIGp1c3Qgbm93LCBub3cgTUdXIHJlc3RvcmVzIGNvbm5lY3Rpb24gd2l0aCBNR0MsIHRo ZW4NCj4gbWF5YmUgc3RhdGUgb2YgdGhlIE1HVyAgaXMgZGlmZmVyZW50IGZyb20gd2hhdCBNR0Mg cmVnYXJkZWQgLCBzbyBNR0MgbmVlZCBhdWRpdCBNR1cNCj4gdG8gc3ljaG9ybml6ZSB3aXRoIGl0 LiAgQWxsIGFib3ZlIGNhbiBiZSBmb3VuZCBpbiB0aGUgZG9jdW1lbnQ6IGRyYWZ0LWlldGYtbWVn YWNvLWNhbGxmbG93cy0wMi50eHQsDQo+IHdoaWNoIHJlYWRzIGFzIGJlbG93Og0KPiANCj4gVGhl IE1HIGlzc3VlcyB0aGUgZGlzY29ubmVjdGlvbiBtZXRob2Qgb2YgU2VydmljZSBDaGFuZ2Ugd2hl biBpdCBsb3N0DQo+IHRoZSBjb21tdW5pY2F0aW9uIHdpdGggTUdDIGFuZCBsYXRlciByZWdhaW5z IGl0LiBUaGUgTUdDIG5vcm1hbGx5DQo+IGdlbmVyYXRlcyBhbiBBdWRpdCBtZXNzYWdlIHRvIGFz c2VzcyB0aGUgc3RhdGUgb2YgdGhlIHRlcm1pbmF0aW9ucw0KPiBiZWZvcmUgYW5kIGFmdGVyIHRo ZSBkaXNjb25uZWN0aW9uLiBUaGUgQXVkaXQgY29tbWFuZCBlbmFibGVzIE1HQyB0bw0KPiBzeW5j aHJvbml6ZSBpdHMgc3RhdGUgd2l0aCB0aGUgTUcncyBzdGF0ZS4NCj4gDQo+IA0KPiBUaG91Z2gg aXQgaXMgYSBkcmFmdCwgYnV0IEkgdGhpbmsgaXQgaXMgcmVhc29uYWJsZS4gV2hhdCBhYm91dCB5 b3VyIG9waW5pb24/DQo+IFRoYW5rcyBmb3IgeW91ciByZXBseSBhZ2FpbiENCj4gDQo+IC0tLS0t 5Y6f5aeL6YKu5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBLZXZpbiBCb3lsZSBbbWFpbHRvOmtib3ls ZUBub3J0ZWxuZXR3b3Jrcy5jb21dDQo+IOWPkemAgeaXtumXtDogMjAwNOW5tDLmnIgxMuaXpSAy OjMxDQo+IOaUtuS7tuS6ujogw5HDrsOPw6jCssKoOyBtZWdhY29AaWV0Zi5vcmcNCj4gVGl0bGU6 IFJFOiBbTWVnYWNvXSBxdWVzdGlvbiBhYm91dCBkaXNjb25uZWN0aW9uIG1lc3NhZ2UgZnJvbSBN R1cNCj4gDQo+IA0KPiBUaGlzIHdvdWxkIGFsbCBkZXBlbmQgdXBvbiB3aGF0IHRoZSBNR0MgaXMg dHJ5aW5nIHRvIGFjY29tcGxpc2guICBIb3cgdGhlDQo+IE1HQyB3b3VsZCB1c2UgYW4gYXVkaXQg ZGVwZW5kcyBoZWF2aWx5IHVwb24gd2hhdCBmdW5jdGlvbiBpdCBwZXJmb3Jtcy4NCj4gDQo+IE5v dGUgdGhhdCB0aGVyZSBhcmUgbm8gcmVxdWlyZW1lbnRzIGFzIHRvIHdoZW4gb3IgaG93IGF1ZGl0 cyBhcmUgcGVyZm9ybWVkLg0KPiBBdWRpdHMgYXJlIGEgdG9vbCB0byBiZSB1c2VkIGFzIGFwcHJv cHJpYXRlIGJ5IGFuIGltcGxlbWVudGF0aW9uLg0KPiANCj4gS2V2aW4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiBGcm9tOiB5eGJAY3BpdC5jb20uY24gW21haWx0 bzp5eGJAY3BpdC5jb20uY25dIA0KPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDA0 IDM6MjggQU0NCj4gVG86IG1lZ2Fjb0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbTWVnYWNvXSBxdWVz dGlvbiBhYm91dCBkaXNjb25uZWN0aW9uIG1lc3NhZ2UgZnJvbSBNR1cNCj4gDQo+IA0KPiBIaSxh bGwNCj4gaWYgTUdDIHJlY2VpdmVzIGEgbWVzc2FnZSBzdmMucmVxKFJPT1QsTWV0aG9kPURpc2Nv bm5lY3Rpb24pICwNCj4gSSBhbSBub3Qgc3VyZSBpZiBNR0Mgc2hvdWxkIHNlbmRzIGF1ZGl0IGNv bW1hbmQgYWZ0ZXIgc3ZjLnJlcGx5LA0KPiBhbmQgaWYgTUdDIHNlbmRzIGF1ZGl0IHRvIE1HVywg aG93IE1HQyBzaG91bGQgdXNlIGF1ZGl0LnJlcGx5LA0KPiB0aGF0IGlzIHdoYXQgc2hvdWxkIE1H QyBkZWFsIHdpdGggdGhlIHJlcGx5IG1lc3NhZ2UuIFRoYW5rcyBhIGxvdCENCj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBTaW1iYQ0KPiANCj4gMXLoiYpYWGkgeteuCG0/IDAg J34gZmZYKSAoDQo= _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Feb 12 13:45:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06504 for ; Thu, 12 Feb 2004 13:45:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLpf-0007g5-DF; Thu, 12 Feb 2004 13:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLp1-0007dy-Pl for megaco@optimus.ietf.org; Thu, 12 Feb 2004 13:44:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06481 for ; Thu, 12 Feb 2004 13:44:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArLox-0004ps-00 for megaco@ietf.org; Thu, 12 Feb 2004 13:44:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArLnz-0004lP-00 for megaco@ietf.org; Thu, 12 Feb 2004 13:43:19 -0500 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1ArLnd-0004h6-00 for megaco@ietf.org; Thu, 12 Feb 2004 13:42:57 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1CIgSN06981 for ; Thu, 12 Feb 2004 13:42:28 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3D2X03>; Thu, 12 Feb 2004 13:42:29 -0500 Message-ID: From: "Kevin Boyle" To: ??? , megaco@ietf.org Subject: RE: [Megaco] question about disconnection message from MGW Date: Thu, 12 Feb 2004 13:42:22 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I would like to point out that the callflows document is not a standard, and only provides examples of one possible way to achieve certain functionality. Your implementation may differ based upon the functionality it is trying to achieve. In fact, I believe the callflows document is expired. The spec does not mandates audits or any particular handling of audit responses. That would be a detail to be resolved by your implementation. If your implementation needs to perform audits, then that should be taken into account during its design. Kevin -----Original Message----- From: yxb@cpit.com.cn [mailto:yxb@cpit.com.cn] Sent: Wednesday, February 11, 2004 8:02 PM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: Re: [Megaco] question about disconnection message from MGW Thank for your reply, but if MGW send Disconnection indication to MGC, which means MGW disconnected from MGC just now, now MGW restores connection with MGC, then maybe state of the MGW is different from what MGC regarded , so MGC need audit MGW to sychornize with it. All above can be found in the document: draft-ietf-megaco-callflows-02.txt, which reads as below: The MG issues the disconnection method of Service Change when it lost the communication with MGC and later regains it. The MGC normally generates an Audit message to assess the state of the terminations before and after the disconnection. The Audit command enables MGC to synchronize its state with the MG's state. Though it is a draft, but I think it is reasonable. What about your opinion? Thanks for your reply again! -----原始邮件----- å‘件人: Kevin Boyle [mailto:kboyle@nortelnetworks.com] å‘é€æ—¶é—´: 2004å¹´2月12æ—¥ 2:31 收件人: ÑîÃ貨; megaco@ietf.org Title: RE: [Megaco] question about disconnection message from MGW This would all depend upon what the MGC is trying to accomplish. How the MGC would use an audit depends heavily upon what function it performs. Note that there are no requirements as to when or how audits are performed. Audits are a tool to be used as appropriate by an implementation. Kevin ________________________________ From: yxb@cpit.com.cn [mailto:yxb@cpit.com.cn] Sent: Wednesday, February 11, 2004 3:28 AM To: megaco@ietf.org Subject: [Megaco] question about disconnection message from MGW Hi,all if MGC receives a message svc.req(ROOT,Method=Disconnection) , I am not sure if MGC should sends audit command after svc.reply, and if MGC sends audit to MGW, how MGC should use audit.reply, that is what should MGC deal with the reply message. Thanks a lot! Simba _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Feb 12 13:46:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06538 for ; Thu, 12 Feb 2004 13:46:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLqb-0007k0-Ji; Thu, 12 Feb 2004 13:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLq1-0007hf-Ku for megaco@optimus.ietf.org; Thu, 12 Feb 2004 13:45:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06493 for ; Thu, 12 Feb 2004 13:45:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArLpx-0004vA-00 for megaco@ietf.org; Thu, 12 Feb 2004 13:45:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArLp0-0004qS-00 for megaco@ietf.org; Thu, 12 Feb 2004 13:44:23 -0500 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1ArLoU-0004le-00 for megaco@ietf.org; Thu, 12 Feb 2004 13:43:50 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1CIhLN07043 for ; Thu, 12 Feb 2004 13:43:21 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3D2YAQ>; Thu, 12 Feb 2004 13:43:22 -0500 Message-ID: From: "Kevin Boyle" To: Zhao Bo , ??? Cc: megaco@ietf.org Subject: RE: [Megaco] question about disconnection message from MGW Date: Thu, 12 Feb 2004 13:43:16 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Again, the MGC MAY wish to audit. There is no requirement. Whether the MGC audits or not is determined by the implementation of the MGC. Kevin -----Original Message----- From: Zhao Bo [mailto:zbo@huawei.com] Sent: Wednesday, February 11, 2004 9:06 PM To: ??? Cc: megaco@ietf.org Subject: Re: [Megaco] question about disconnection message from MGW Hi, please refer to section 7.28 of H.248.1, description of ServiceChangeMethod "Disconnected": Disconnected: always applied with the Root TerminationID, indicates that the MG lost communication with the MGC, but it was subsequently restored to the same MGC (possibly after trying other MGCs on a pre-provisioned list). Since MG state may have changed, the MGC may wish to use the Audit command to resynchronize its state with the MG's. ----- Original Message ----- From: "æ¨å…ˆæ³¢" To: "Kevin Boyle" ; Sent: Thursday, February 12, 2004 9:02 AM Subject: Re: [Megaco] question about disconnection message from MGW > > Thank for your reply, but if MGW send Disconnection indication to MGC, which means > MGW disconnected from MGC just now, now MGW restores connection with MGC, then > maybe state of the MGW is different from what MGC regarded , so MGC need audit MGW > to sychornize with it. All above can be found in the document: draft-ietf-megaco-callflows-02.txt, > which reads as below: > > The MG issues the disconnection method of Service Change when it lost > the communication with MGC and later regains it. The MGC normally > generates an Audit message to assess the state of the terminations > before and after the disconnection. The Audit command enables MGC to > synchronize its state with the MG's state. > > > Though it is a draft, but I think it is reasonable. What about your opinion? > Thanks for your reply again! > > -----原始邮件----- > å‘件人: Kevin Boyle [mailto:kboyle@nortelnetworks.com] > å‘é€æ—¶é—´: 2004å¹´2月12æ—¥ 2:31 > 收件人: ÑîÃ貨; megaco@ietf.org > Title: RE: [Megaco] question about disconnection message from MGW > > > This would all depend upon what the MGC is trying to accomplish. How the > MGC would use an audit depends heavily upon what function it performs. > > Note that there are no requirements as to when or how audits are performed. > Audits are a tool to be used as appropriate by an implementation. > > Kevin > ________________________________ > > From: yxb@cpit.com.cn [mailto:yxb@cpit.com.cn] > Sent: Wednesday, February 11, 2004 3:28 AM > To: megaco@ietf.org > Subject: [Megaco] question about disconnection message from MGW > > > Hi,all > if MGC receives a message svc.req(ROOT,Method=Disconnection) , > I am not sure if MGC should sends audit command after svc.reply, > and if MGC sends audit to MGW, how MGC should use audit.reply, > that is what should MGC deal with the reply message. Thanks a lot! > Simba > > 1r艊XXi z×®m? 0 '~ ffX) (1r剚XXÇ i"z敃mì ¶? 0Ä€'~ffX)í¬€( _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Feb 12 13:47:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06575 for ; Thu, 12 Feb 2004 13:47:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLr9-0007uG-6w for megaco-archive@odin.ietf.org; Thu, 12 Feb 2004 13:46:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CIkZTf030388 for megaco-archive@odin.ietf.org; Thu, 12 Feb 2004 13:46:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLr9-0007u2-1a for megaco-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 13:46:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06568 for ; Thu, 12 Feb 2004 13:46:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArLr4-00051M-00 for megaco-web-archive@ietf.org; Thu, 12 Feb 2004 13:46:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArLq2-0004vz-00 for megaco-web-archive@ietf.org; Thu, 12 Feb 2004 13:45:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArLpj-0004qq-00 for megaco-web-archive@ietf.org; Thu, 12 Feb 2004 13:45:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLpf-0007g5-DF; Thu, 12 Feb 2004 13:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLp1-0007dy-Pl for megaco@optimus.ietf.org; Thu, 12 Feb 2004 13:44:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06481 for ; Thu, 12 Feb 2004 13:44:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArLox-0004ps-00 for megaco@ietf.org; Thu, 12 Feb 2004 13:44:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArLnz-0004lP-00 for megaco@ietf.org; Thu, 12 Feb 2004 13:43:19 -0500 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1ArLnd-0004h6-00 for megaco@ietf.org; Thu, 12 Feb 2004 13:42:57 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1CIgSN06981 for ; Thu, 12 Feb 2004 13:42:28 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3D2X03>; Thu, 12 Feb 2004 13:42:29 -0500 Message-ID: From: "Kevin Boyle" To: ??? , megaco@ietf.org Subject: RE: [Megaco] question about disconnection message from MGW Date: Thu, 12 Feb 2004 13:42:22 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 I would like to point out that the callflows document is not a standard, and only provides examples of one possible way to achieve certain functionality. Your implementation may differ based upon the functionality it is trying to achieve. In fact, I believe the callflows document is expired. The spec does not mandates audits or any particular handling of audit responses. That would be a detail to be resolved by your implementation. If your implementation needs to perform audits, then that should be taken into account during its design. Kevin -----Original Message----- From: yxb@cpit.com.cn [mailto:yxb@cpit.com.cn] Sent: Wednesday, February 11, 2004 8:02 PM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: Re: [Megaco] question about disconnection message from MGW Thank for your reply, but if MGW send Disconnection indication to MGC, which means MGW disconnected from MGC just now, now MGW restores connection with MGC, then maybe state of the MGW is different from what MGC regarded , so MGC need audit MGW to sychornize with it. All above can be found in the document: draft-ietf-megaco-callflows-02.txt, which reads as below: The MG issues the disconnection method of Service Change when it lost the communication with MGC and later regains it. The MGC normally generates an Audit message to assess the state of the terminations before and after the disconnection. The Audit command enables MGC to synchronize its state with the MG's state. Though it is a draft, but I think it is reasonable. What about your opinion? Thanks for your reply again! -----原始邮件----- å‘件人: Kevin Boyle [mailto:kboyle@nortelnetworks.com] å‘é€æ—¶é—´: 2004å¹´2月12æ—¥ 2:31 收件人: ÑîÃ貨; megaco@ietf.org Title: RE: [Megaco] question about disconnection message from MGW This would all depend upon what the MGC is trying to accomplish. How the MGC would use an audit depends heavily upon what function it performs. Note that there are no requirements as to when or how audits are performed. Audits are a tool to be used as appropriate by an implementation. Kevin ________________________________ From: yxb@cpit.com.cn [mailto:yxb@cpit.com.cn] Sent: Wednesday, February 11, 2004 3:28 AM To: megaco@ietf.org Subject: [Megaco] question about disconnection message from MGW Hi,all if MGC receives a message svc.req(ROOT,Method=Disconnection) , I am not sure if MGC should sends audit command after svc.reply, and if MGC sends audit to MGW, how MGC should use audit.reply, that is what should MGC deal with the reply message. Thanks a lot! Simba _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Feb 12 13:48:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06640 for ; Thu, 12 Feb 2004 13:48:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLs3-00081W-Ss for megaco-archive@odin.ietf.org; Thu, 12 Feb 2004 13:47:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CIlV2Y030836 for megaco-archive@odin.ietf.org; Thu, 12 Feb 2004 13:47:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLs3-00081H-M5 for megaco-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 13:47:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06612 for ; Thu, 12 Feb 2004 13:47:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArLrz-00057q-00 for megaco-web-archive@ietf.org; Thu, 12 Feb 2004 13:47:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArLr7-00051r-00 for megaco-web-archive@ietf.org; Thu, 12 Feb 2004 13:46:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArLqY-0004wE-00 for megaco-web-archive@ietf.org; Thu, 12 Feb 2004 13:45:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLqb-0007k0-Ji; Thu, 12 Feb 2004 13:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLq1-0007hf-Ku for megaco@optimus.ietf.org; Thu, 12 Feb 2004 13:45:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06493 for ; Thu, 12 Feb 2004 13:45:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArLpx-0004vA-00 for megaco@ietf.org; Thu, 12 Feb 2004 13:45:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArLp0-0004qS-00 for megaco@ietf.org; Thu, 12 Feb 2004 13:44:23 -0500 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1ArLoU-0004le-00 for megaco@ietf.org; Thu, 12 Feb 2004 13:43:50 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1CIhLN07043 for ; Thu, 12 Feb 2004 13:43:21 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3D2YAQ>; Thu, 12 Feb 2004 13:43:22 -0500 Message-ID: From: "Kevin Boyle" To: Zhao Bo , ??? Cc: megaco@ietf.org Subject: RE: [Megaco] question about disconnection message from MGW Date: Thu, 12 Feb 2004 13:43:16 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Again, the MGC MAY wish to audit. There is no requirement. Whether the MGC audits or not is determined by the implementation of the MGC. Kevin -----Original Message----- From: Zhao Bo [mailto:zbo@huawei.com] Sent: Wednesday, February 11, 2004 9:06 PM To: ??? Cc: megaco@ietf.org Subject: Re: [Megaco] question about disconnection message from MGW Hi, please refer to section 7.28 of H.248.1, description of ServiceChangeMethod "Disconnected": Disconnected: always applied with the Root TerminationID, indicates that the MG lost communication with the MGC, but it was subsequently restored to the same MGC (possibly after trying other MGCs on a pre-provisioned list). Since MG state may have changed, the MGC may wish to use the Audit command to resynchronize its state with the MG's. ----- Original Message ----- From: "æ¨å…ˆæ³¢" To: "Kevin Boyle" ; Sent: Thursday, February 12, 2004 9:02 AM Subject: Re: [Megaco] question about disconnection message from MGW > > Thank for your reply, but if MGW send Disconnection indication to MGC, which means > MGW disconnected from MGC just now, now MGW restores connection with MGC, then > maybe state of the MGW is different from what MGC regarded , so MGC need audit MGW > to sychornize with it. All above can be found in the document: draft-ietf-megaco-callflows-02.txt, > which reads as below: > > The MG issues the disconnection method of Service Change when it lost > the communication with MGC and later regains it. The MGC normally > generates an Audit message to assess the state of the terminations > before and after the disconnection. The Audit command enables MGC to > synchronize its state with the MG's state. > > > Though it is a draft, but I think it is reasonable. What about your opinion? > Thanks for your reply again! > > -----原始邮件----- > å‘件人: Kevin Boyle [mailto:kboyle@nortelnetworks.com] > å‘é€æ—¶é—´: 2004å¹´2月12æ—¥ 2:31 > 收件人: ÑîÃ貨; megaco@ietf.org > Title: RE: [Megaco] question about disconnection message from MGW > > > This would all depend upon what the MGC is trying to accomplish. How the > MGC would use an audit depends heavily upon what function it performs. > > Note that there are no requirements as to when or how audits are performed. > Audits are a tool to be used as appropriate by an implementation. > > Kevin > ________________________________ > > From: yxb@cpit.com.cn [mailto:yxb@cpit.com.cn] > Sent: Wednesday, February 11, 2004 3:28 AM > To: megaco@ietf.org > Subject: [Megaco] question about disconnection message from MGW > > > Hi,all > if MGC receives a message svc.req(ROOT,Method=Disconnection) , > I am not sure if MGC should sends audit command after svc.reply, > and if MGC sends audit to MGW, how MGC should use audit.reply, > that is what should MGC deal with the reply message. Thanks a lot! > Simba > > 1r艊XXi z×®m? 0 '~ ffX) (1r剚XXÇ i"z敃mì ¶? 0Ä€'~ffX)í¬€( _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 16 08:45:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17095 for ; Mon, 16 Feb 2004 08:45:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asj3W-0006cw-E8; Mon, 16 Feb 2004 08:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asj2l-0006bh-2j for megaco@optimus.ietf.org; Mon, 16 Feb 2004 08:44:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16929 for ; Mon, 16 Feb 2004 08:44:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asj2j-0004Fo-00 for megaco@ietf.org; Mon, 16 Feb 2004 08:44:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asj1m-0004CC-00 for megaco@ietf.org; Mon, 16 Feb 2004 08:43:15 -0500 Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com) by ietf-mx with esmtp (Exim 4.12) id 1Asj0u-00048i-00 for megaco@ietf.org; Mon, 16 Feb 2004 08:42:21 -0500 Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Feb 2004 08:42:02 -0500 Message-ID: From: Carl Rutter To: megaco@ietf.org Date: Mon, 16 Feb 2004 08:42:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Megaco] Compelled Signaling - ICASGEN vs ICASC Sender: megaco-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: , Question, Will both of these packages co-exist? If not what is the timeframe in which this issue will be resolved? Thx, Carl Carl Rutter Telica, Inc. Building G, Suite 100 734 Forest Street Marlboro, MA 01752 Email crutter@telica.com Voice 508-480-0909 x8178 Fax 508-480-0922 www.telica.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Feb 16 08:46:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17203 for ; Mon, 16 Feb 2004 08:46:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asj4o-0006rz-KY for megaco-archive@odin.ietf.org; Mon, 16 Feb 2004 08:46:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GDkMN2026401 for megaco-archive@odin.ietf.org; Mon, 16 Feb 2004 08:46:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asj4o-0006rk-Ef for megaco-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 08:46:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17169 for ; Mon, 16 Feb 2004 08:46:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asj4m-0004P2-00 for megaco-web-archive@ietf.org; Mon, 16 Feb 2004 08:46:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asj3t-0004LW-00 for megaco-web-archive@ietf.org; Mon, 16 Feb 2004 08:45:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asj3a-0004I7-00 for megaco-web-archive@ietf.org; Mon, 16 Feb 2004 08:45:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asj3W-0006cw-E8; Mon, 16 Feb 2004 08:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asj2l-0006bh-2j for megaco@optimus.ietf.org; Mon, 16 Feb 2004 08:44:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16929 for ; Mon, 16 Feb 2004 08:44:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asj2j-0004Fo-00 for megaco@ietf.org; Mon, 16 Feb 2004 08:44:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asj1m-0004CC-00 for megaco@ietf.org; Mon, 16 Feb 2004 08:43:15 -0500 Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com) by ietf-mx with esmtp (Exim 4.12) id 1Asj0u-00048i-00 for megaco@ietf.org; Mon, 16 Feb 2004 08:42:21 -0500 Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Feb 2004 08:42:02 -0500 Message-ID: From: Carl Rutter To: megaco@ietf.org Date: Mon, 16 Feb 2004 08:42:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] Compelled Signaling - ICASGEN vs ICASC Sender: megaco-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Question, Will both of these packages co-exist? If not what is the timeframe in which this issue will be resolved? Thx, Carl Carl Rutter Telica, Inc. Building G, Suite 100 734 Forest Street Marlboro, MA 01752 Email crutter@telica.com Voice 508-480-0909 x8178 Fax 508-480-0922 www.telica.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 16 10:43:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26277 for ; Mon, 16 Feb 2004 10:43:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Askti-0007OO-GM; Mon, 16 Feb 2004 10:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsktM-0007Gg-B4 for megaco@optimus.ietf.org; Mon, 16 Feb 2004 10:42:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26199 for ; Mon, 16 Feb 2004 10:42:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsktI-0005T8-00 for megaco@ietf.org; Mon, 16 Feb 2004 10:42:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsksY-0005Oo-00 for megaco@ietf.org; Mon, 16 Feb 2004 10:41:51 -0500 Received: from main.gmane.org ([80.91.224.249]) by ietf-mx with esmtp (Exim 4.12) id 1Askrk-0005IC-00 for megaco@ietf.org; Mon, 16 Feb 2004 10:41:00 -0500 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Askrg-0002Mw-00 for ; Mon, 16 Feb 2004 16:40:56 +0100 Received: from willow.rfc1149.net ([81.56.47.149]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon Feb 16 15:40:56 2004 Received: from sam by willow.rfc1149.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon Feb 16 15:40:56 2004 X-Injected-Via-Gmane: http://gmane.org/ To: megaco@ietf.org From: Samuel Tardieu Date: Mon, 16 Feb 2004 16:38:12 +0100 Organization: Avian Carrier & Friends Lines: 15 Message-ID: <87isi7rq57.fsf@beeblebrox.enst.fr> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: willow.rfc1149.net User-Agent: T-gnus/6.16.2 (based on Gnus v5.10.2) (revision 02) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) Cancel-Lock: sha1:n2w+qHaXbjihLDBhPi24xuZCJUc= X-Leafnode-NNTP-Posting-Host: 3ffe:304:103:111:200:39ff:fe25:3aa2 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Megaco] Conference call Sender: megaco-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: , I am wondering how I should implement three-people conference calls when the people are located on different MGs. If the communication between the MGs and the end-users don't cost anything (a handset connected directly to the MG), it looks like it makes sense to establish three bidirectional RTP streams to minimize latency. However, if those communications cost money (outgoing POTS communications), one of the MGs should be the one implementing the conferencing service. How do you typically do? Sam -- Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Feb 16 10:45:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26441 for ; Mon, 16 Feb 2004 10:45:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AskvN-0007df-Uk for megaco-archive@odin.ietf.org; Mon, 16 Feb 2004 10:44:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GFijwi029356 for megaco-archive@odin.ietf.org; Mon, 16 Feb 2004 10:44:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AskvN-0007dP-Qg for megaco-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 10:44:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26401 for ; Mon, 16 Feb 2004 10:44:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AskvL-0005gg-00 for megaco-web-archive@ietf.org; Mon, 16 Feb 2004 10:44:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AskuI-0005a9-00 for megaco-web-archive@ietf.org; Mon, 16 Feb 2004 10:43:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Askth-0005UP-00 for megaco-web-archive@ietf.org; Mon, 16 Feb 2004 10:43:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Askti-0007OO-GM; Mon, 16 Feb 2004 10:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsktM-0007Gg-B4 for megaco@optimus.ietf.org; Mon, 16 Feb 2004 10:42:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26199 for ; Mon, 16 Feb 2004 10:42:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsktI-0005T8-00 for megaco@ietf.org; Mon, 16 Feb 2004 10:42:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsksY-0005Oo-00 for megaco@ietf.org; Mon, 16 Feb 2004 10:41:51 -0500 Received: from main.gmane.org ([80.91.224.249]) by ietf-mx with esmtp (Exim 4.12) id 1Askrk-0005IC-00 for megaco@ietf.org; Mon, 16 Feb 2004 10:41:00 -0500 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Askrg-0002Mw-00 for ; Mon, 16 Feb 2004 16:40:56 +0100 Received: from willow.rfc1149.net ([81.56.47.149]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon Feb 16 15:40:56 2004 Received: from sam by willow.rfc1149.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon Feb 16 15:40:56 2004 X-Injected-Via-Gmane: http://gmane.org/ To: megaco@ietf.org From: Samuel Tardieu Date: Mon, 16 Feb 2004 16:38:12 +0100 Organization: Avian Carrier & Friends Lines: 15 Message-ID: <87isi7rq57.fsf@beeblebrox.enst.fr> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: willow.rfc1149.net User-Agent: T-gnus/6.16.2 (based on Gnus v5.10.2) (revision 02) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) Cancel-Lock: sha1:n2w+qHaXbjihLDBhPi24xuZCJUc= X-Leafnode-NNTP-Posting-Host: 3ffe:304:103:111:200:39ff:fe25:3aa2 Subject: [Megaco] Conference call Sender: megaco-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I am wondering how I should implement three-people conference calls when the people are located on different MGs. If the communication between the MGs and the end-users don't cost anything (a handset connected directly to the MG), it looks like it makes sense to establish three bidirectional RTP streams to minimize latency. However, if those communications cost money (outgoing POTS communications), one of the MGs should be the one implementing the conferencing service. How do you typically do? Sam -- Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 16 23:09:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25058 for ; Mon, 16 Feb 2004 23:09:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AswXc-00026S-Vg; Mon, 16 Feb 2004 23:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AswXP-00025u-Fa for megaco@optimus.ietf.org; Mon, 16 Feb 2004 23:08:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25043 for ; Mon, 16 Feb 2004 23:08:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AswXK-0001Q5-00 for megaco@ietf.org; Mon, 16 Feb 2004 23:08:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AswWI-0001LJ-00 for megaco@ietf.org; Mon, 16 Feb 2004 23:07:40 -0500 Received: from [203.199.83.248] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1AswVJ-0001Ho-00 for megaco@ietf.org; Mon, 16 Feb 2004 23:06:37 -0500 Received: (qmail 27580 invoked by uid 510); 17 Feb 2004 04:06:32 -0000 Date: 17 Feb 2004 04:06:32 -0000 Message-ID: <20040217040632.27579.qmail@webmail36.rediffmail.com> Received: from unknown (137.71.23.54) by rediffmail.com via HTTP; 17 feb 2004 04:06:32 -0000 MIME-Version: 1.0 From: "kumar" Reply-To: "kumar" To: megaco@ietf.org Content-type: multipart/alternative; boundary="Next_1076990792---0-203.199.83.248-27572" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,MSGID_FROM_MTA_HEADER,REPLY_TO_ULINE_NUMS autolearn=no version=2.60 Subject: [Megaco] tone direction iin alerting 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 multipart mime message --Next_1076990792---0-203.199.83.248-27572 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi All,
=0A  I have few questions. While I was going through= Enhanced Alerting Package, I came accross the signal parameter Tone Direct= ion. As per the document it indicates the direction the signal shall procee= d w.r.t. to the center of the context. What does this context refer to ? Is= it the context created during the add command ? Can anyone explain me clea= rly?
=0A
=0A  My other question is regarding BER encoding. In r= fc3525 does not mention which Type class we need to use.I am using Context = specific class. But some other implementors are using Universal type. Is my= decoder should able to decode  both classes?
=0A 
=0A&nbs= p; I saw the differences between rfc3015 and rfc3525. Some mandatory param= eters in rfc3015 are made optional in 3525. Both are defined with version 1= . How do they communicate each other as MG with 3015 expects some mandatory= parameter?
=0A
=0AThanks,
=0AKumar=0A

=0A

=0A=0A --Next_1076990792---0-203.199.83.248-27572 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All,=0A I have few questions. While I was going through Enhanced Alert= ing Package, I came accross the signal parameter Tone Direction. As per the= document it indicates the direction the signal shall proceed w.r.t. to the= center of the context. What does this context refer to ? Is it the context= created during the add command ? Can anyone explain me clearly?=0A=0A My= other question is regarding BER encoding. In rfc3525 does not mention whic= h Type class we need to use.I am using Context specific class. But some oth= er implementors are using Universal type. Is my decoder should able to deco= de both classes?=0A =0A I saw the differences between rfc3015 and rfc35= 25. Some mandatory parameters in rfc3015 are made optional in 3525. Both ar= e defined with version 1. How do they communicate each other as MG with 301= 5 expects some mandatory parameter?=0A=0AThanks,=0AKumar --Next_1076990792---0-203.199.83.248-27572-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Feb 16 23:11:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25194 for ; Mon, 16 Feb 2004 23:11:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AswZa-0002EY-N7 for megaco-archive@odin.ietf.org; Mon, 16 Feb 2004 23:11:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H4B16E008562 for megaco-archive@odin.ietf.org; Mon, 16 Feb 2004 23:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AswZX-0002Dg-45 for megaco-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 23:10:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25160 for ; Mon, 16 Feb 2004 23:10:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AswZS-0001ZI-00 for megaco-web-archive@ietf.org; Mon, 16 Feb 2004 23:10:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AswYY-0001VJ-00 for megaco-web-archive@ietf.org; Mon, 16 Feb 2004 23:10:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AswXf-0001R8-00 for megaco-web-archive@ietf.org; Mon, 16 Feb 2004 23:09:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AswXc-00026S-Vg; Mon, 16 Feb 2004 23:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AswXP-00025u-Fa for megaco@optimus.ietf.org; Mon, 16 Feb 2004 23:08:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25043 for ; Mon, 16 Feb 2004 23:08:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AswXK-0001Q5-00 for megaco@ietf.org; Mon, 16 Feb 2004 23:08:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AswWI-0001LJ-00 for megaco@ietf.org; Mon, 16 Feb 2004 23:07:40 -0500 Received: from [203.199.83.248] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1AswVJ-0001Ho-00 for megaco@ietf.org; Mon, 16 Feb 2004 23:06:37 -0500 Received: (qmail 27580 invoked by uid 510); 17 Feb 2004 04:06:32 -0000 Date: 17 Feb 2004 04:06:32 -0000 Message-ID: <20040217040632.27579.qmail@webmail36.rediffmail.com> Received: from unknown (137.71.23.54) by rediffmail.com via HTTP; 17 feb 2004 04:06:32 -0000 MIME-Version: 1.0 From: "kumar" Reply-To: "kumar" To: megaco@ietf.org Content-type: multipart/alternative; boundary="Next_1076990792---0-203.199.83.248-27572" Subject: [Megaco] tone direction iin alerting 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,MSGID_FROM_MTA_HEADER,REPLY_TO_ULINE_NUMS autolearn=no version=2.60 This is a multipart mime message --Next_1076990792---0-203.199.83.248-27572 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi All,
=0A  I have few questions. While I was going through= Enhanced Alerting Package, I came accross the signal parameter Tone Direct= ion. As per the document it indicates the direction the signal shall procee= d w.r.t. to the center of the context. What does this context refer to ? Is= it the context created during the add command ? Can anyone explain me clea= rly?
=0A
=0A  My other question is regarding BER encoding. In r= fc3525 does not mention which Type class we need to use.I am using Context = specific class. But some other implementors are using Universal type. Is my= decoder should able to decode  both classes?
=0A 
=0A&nbs= p; I saw the differences between rfc3015 and rfc3525. Some mandatory param= eters in rfc3015 are made optional in 3525. Both are defined with version 1= . How do they communicate each other as MG with 3015 expects some mandatory= parameter?
=0A
=0AThanks,
=0AKumar=0A

=0A

=0A=0A --Next_1076990792---0-203.199.83.248-27572 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All,=0A I have few questions. While I was going through Enhanced Alert= ing Package, I came accross the signal parameter Tone Direction. As per the= document it indicates the direction the signal shall proceed w.r.t. to the= center of the context. What does this context refer to ? Is it the context= created during the add command ? Can anyone explain me clearly?=0A=0A My= other question is regarding BER encoding. In rfc3525 does not mention whic= h Type class we need to use.I am using Context specific class. But some oth= er implementors are using Universal type. Is my decoder should able to deco= de both classes?=0A =0A I saw the differences between rfc3015 and rfc35= 25. Some mandatory parameters in rfc3015 are made optional in 3525. Both ar= e defined with version 1. How do they communicate each other as MG with 301= 5 expects some mandatory parameter?=0A=0AThanks,=0AKumar --Next_1076990792---0-203.199.83.248-27572-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 17 00:12:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26874 for ; Tue, 17 Feb 2004 00:12:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsxWb-0005eZ-KV; Tue, 17 Feb 2004 00:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsxWN-0005dS-53 for megaco@optimus.ietf.org; Tue, 17 Feb 2004 00:11:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26866 for ; Tue, 17 Feb 2004 00:11:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsxWK-00050t-00 for megaco@ietf.org; Tue, 17 Feb 2004 00:11:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsxVK-0004vt-00 for megaco@ietf.org; Tue, 17 Feb 2004 00:10:43 -0500 Received: from [202.41.97.50] (helo=u1.doe.ernet.in) by ietf-mx with esmtp (Exim 4.12) id 1AsxUL-0004nZ-00 for megaco@ietf.org; Tue, 17 Feb 2004 00:09:41 -0500 Received: from uucp-relay-delhi.ernet.in (uucp-relay-delhi.ernet.in [202.41.97.134]) by u1.doe.ernet.in (8.12.8/8.12.8) with ESMTP id i1H4w71q016692; Tue, 17 Feb 2004 10:29:12 +0530 Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0) id KAA05680; Tue, 17 Feb 2004 10:49:01 -0500 (GMT) >Received: from relay.cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4) id KAA03846; Tue, 17 Feb 2004 10:34:29 -0500 X-Authentication-Warning: relay.cdotd.ernet.in: iscan owned process doing -bs Message-ID: <40319EE4.6C3BEA89@cdotd.ernet.in> Date: Tue, 17 Feb 2004 10:26:04 +0530 From: manish rathi Organization: C-DOT X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: kboyle@nortelnetworks.com, megaco@ietf.org Received: from cdotd by vikram.eis.ernet.in; Tue, 17 Feb 2004 10:49 GMT Content-Type: multipart/alternative; boundary="------------E6EB7A775EF6179453036518" X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_MESSAGE, MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Subject: [Megaco] megaco Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --------------E6EB7A775EF6179453036518 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi, I want to start implementing megaco for 3g MSC. I've read basic megaco rfc 3525 & packages. What other i need to study for implementing it? What can be the implementation strategy? Can u tell me the state machine (Identified states of mgc & mgw)? Is here any implementation document on internet for it? We want to develop it inhouse. Thanks Regards Manish -- Things work out best for those who make the best use of it. --------------E6EB7A775EF6179453036518 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit hi,
I want to start implementing megaco for 3g MSC.
I've read basic megaco rfc 3525 & packages.
What other i need to study for implementing it?
What can be the implementation strategy?
Can u tell me the state machine (Identified states of mgc & mgw)?
Is here any implementation document on internet for it?
We want to develop it inhouse.

Thanks
Regards
Manish
  




-- 
Things work out best for those who make the best use of it.

 

--------------E6EB7A775EF6179453036518--



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


From exim@www1.ietf.org  Tue Feb 17 00:14:17 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26933
	for ; Tue, 17 Feb 2004 00:14:17 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AsxYK-0005nl-GH
	for megaco-archive@odin.ietf.org; Tue, 17 Feb 2004 00:13:50 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H5DmQd022295
	for megaco-archive@odin.ietf.org; Tue, 17 Feb 2004 00:13:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AsxYK-0005nW-CU
	for megaco-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 00:13:48 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26912
	for ; Tue, 17 Feb 2004 00:13:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AsxYH-00057q-00
	for megaco-web-archive@ietf.org; Tue, 17 Feb 2004 00:13:46 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AsxXL-00054L-00
	for megaco-web-archive@ietf.org; Tue, 17 Feb 2004 00:12:48 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AsxWb-00051j-00
	for megaco-web-archive@ietf.org; Tue, 17 Feb 2004 00:12:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AsxWb-0005eZ-KV; Tue, 17 Feb 2004 00:12:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AsxWN-0005dS-53
	for megaco@optimus.ietf.org; Tue, 17 Feb 2004 00:11:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26866
	for ; Tue, 17 Feb 2004 00:11:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AsxWK-00050t-00
	for megaco@ietf.org; Tue, 17 Feb 2004 00:11:44 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AsxVK-0004vt-00
	for megaco@ietf.org; Tue, 17 Feb 2004 00:10:43 -0500
Received: from [202.41.97.50] (helo=u1.doe.ernet.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AsxUL-0004nZ-00
	for megaco@ietf.org; Tue, 17 Feb 2004 00:09:41 -0500
Received: from uucp-relay-delhi.ernet.in (uucp-relay-delhi.ernet.in [202.41.97.134])
	by u1.doe.ernet.in (8.12.8/8.12.8) with ESMTP id i1H4w71q016692;
	Tue, 17 Feb 2004 10:29:12 +0530
Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0)
	id KAA05680; Tue, 17 Feb 2004 10:49:01 -0500 (GMT)
>Received: from relay.cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4)
	id KAA03846; Tue, 17 Feb 2004 10:34:29 -0500
X-Authentication-Warning: relay.cdotd.ernet.in: iscan owned process doing -bs
Message-ID: <40319EE4.6C3BEA89@cdotd.ernet.in>
Date: Tue, 17 Feb 2004 10:26:04 +0530
From: manish rathi 
Organization: C-DOT
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.11.00 9000/785)
X-Accept-Language: en
MIME-Version: 1.0
To: kboyle@nortelnetworks.com, megaco@ietf.org
Received: from cdotd by vikram.eis.ernet.in; Tue, 17 Feb 2004 10:49 GMT
Content-Type: multipart/alternative;
 boundary="------------E6EB7A775EF6179453036518"
X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p'
Subject: [Megaco] megaco
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_MESSAGE,
	MSGID_FROM_MTA_HEADER autolearn=no version=2.60


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

hi,
I want to start implementing megaco for 3g MSC.
I've read basic megaco rfc 3525 & packages.
What other i need to study for implementing it?
What can be the implementation strategy?
Can u tell me the state machine (Identified states of mgc & mgw)?
Is here any implementation document on internet for it?
We want to develop it inhouse.

Thanks
Regards
Manish


--
Things work out best for those who make the best use of it.



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



hi,

I want to start implementing megaco for 3g MSC.

I've read basic megaco rfc 3525 & packages.

What other i need to study for implementing it?

What can be the implementation strategy?

Can u tell me the state machine (Identified states of mgc & mgw)?

Is here any implementation document on internet for it?

We want to develop it inhouse.

Thanks

Regards

Manish

 




-- 
Things work out best for those who make the best use of it.

 

--------------E6EB7A775EF6179453036518--



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



From megaco-admin@ietf.org  Tue Feb 17 09:11:34 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28906
	for ; Tue, 17 Feb 2004 09:11:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1At5wE-0002VW-Ik; Tue, 17 Feb 2004 09:11:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1At5vM-0002Tt-A3
	for megaco@optimus.ietf.org; Tue, 17 Feb 2004 09:10:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28842
	for ; Tue, 17 Feb 2004 09:10:05 -0500 (EST)
From: Albrecht.Schwarz@alcatel.de
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1At5vK-0001km-00
	for megaco@ietf.org; Tue, 17 Feb 2004 09:10:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1At5uV-0001hF-00
	for megaco@ietf.org; Tue, 17 Feb 2004 09:09:15 -0500
Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de)
	by ietf-mx with esmtp (Exim 4.12)
	id 1At5tg-0001Yk-00
	for megaco@ietf.org; Tue, 17 Feb 2004 09:08:24 -0500
Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205])
	by mailrelay2.alcatel.de (8.12.10/8.12.10) with ESMTP id i1HE7ppC000118;
	Tue, 17 Feb 2004 14:07:51 GMT
Subject: Re: [Megaco] Compelled Signaling - ICASGEN vs ICASC
To: Carl Rutter 
Cc: megaco@ietf.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
Date: Tue, 17 Feb 2004 15:07:50 +0100
X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 02/17/2004 15:07:51
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
X-Alcanet-virus-scanned: i1HE7ppC000118 at mailrelay2.alcatel.de
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.8 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no 
	version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	


Carl,

work is still in progress on that rather complex subject.
Next Q.3/16 meeting is scheduled in May 2004.

Regards,
Albrecht

ALCATEL



                                                                                                                                                    
                      Carl Rutter                                                                                                                   
                                           cc:                                                                                                  
                      Sent by:                 Subject: [Megaco] Compelled Signaling - ICASGEN vs ICASC                                             
                      megaco-admin@iet                                                                                                              
                      f.org                                                                                                                         
                                                                                                                                                    
                                                                                                                                                    
                      16.02.2004 14:42                                                                                                              
                                                                                                                                                    
                                                                                                                                                    




Question,

Will both of these packages co-exist?
If not what is the timeframe in which this issue will be resolved?

Thx,
Carl

Carl Rutter
Telica, Inc.
Building G, Suite 100
734 Forest Street
Marlboro, MA 01752
Email crutter@telica.com
Voice 508-480-0909 x8178
Fax 508-480-0922
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


From exim@www1.ietf.org  Tue Feb 17 09:13:36 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29000
	for ; Tue, 17 Feb 2004 09:13:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1At5yF-0002iR-TI
	for megaco-archive@odin.ietf.org; Tue, 17 Feb 2004 09:13:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HED7ZP010435
	for megaco-archive@odin.ietf.org; Tue, 17 Feb 2004 09:13:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1At5yF-0002iE-OI
	for megaco-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 09:13:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28953
	for ; Tue, 17 Feb 2004 09:13:05 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1At5yE-00020p-00
	for megaco-web-archive@ietf.org; Tue, 17 Feb 2004 09:13:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1At5xH-0001tG-00
	for megaco-web-archive@ietf.org; Tue, 17 Feb 2004 09:12:07 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1At5wH-0001oU-00
	for megaco-web-archive@ietf.org; Tue, 17 Feb 2004 09:11:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1At5wE-0002VW-Ik; Tue, 17 Feb 2004 09:11:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1At5vM-0002Tt-A3
	for megaco@optimus.ietf.org; Tue, 17 Feb 2004 09:10:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28842
	for ; Tue, 17 Feb 2004 09:10:05 -0500 (EST)
From: Albrecht.Schwarz@alcatel.de
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1At5vK-0001km-00
	for megaco@ietf.org; Tue, 17 Feb 2004 09:10:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1At5uV-0001hF-00
	for megaco@ietf.org; Tue, 17 Feb 2004 09:09:15 -0500
Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de)
	by ietf-mx with esmtp (Exim 4.12)
	id 1At5tg-0001Yk-00
	for megaco@ietf.org; Tue, 17 Feb 2004 09:08:24 -0500
Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205])
	by mailrelay2.alcatel.de (8.12.10/8.12.10) with ESMTP id i1HE7ppC000118;
	Tue, 17 Feb 2004 14:07:51 GMT
Subject: Re: [Megaco] Compelled Signaling - ICASGEN vs ICASC
To: Carl Rutter 
Cc: megaco@ietf.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
Date: Tue, 17 Feb 2004 15:07:50 +0100
X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 02/17/2004 15:07:51
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
X-Alcanet-virus-scanned: i1HE7ppC000118 at mailrelay2.alcatel.de
Sender: megaco-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: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no 
	version=2.60


Carl,

work is still in progress on that rather complex subject.
Next Q.3/16 meeting is scheduled in May 2004.

Regards,
Albrecht

ALCATEL



                                                                                                                                                    
                      Carl Rutter                                                                                                                   
                                           cc:                                                                                                  
                      Sent by:                 Subject: [Megaco] Compelled Signaling - ICASGEN vs ICASC                                             
                      megaco-admin@iet                                                                                                              
                      f.org                                                                                                                         
                                                                                                                                                    
                                                                                                                                                    
                      16.02.2004 14:42                                                                                                              
                                                                                                                                                    
                                                                                                                                                    




Question,

Will both of these packages co-exist?
If not what is the timeframe in which this issue will be resolved?

Thx,
Carl

Carl Rutter
Telica, Inc.
Building G, Suite 100
734 Forest Street
Marlboro, MA 01752
Email crutter@telica.com
Voice 508-480-0909 x8178
Fax 508-480-0922
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



From megaco-admin@ietf.org  Tue Feb 17 10:45:33 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07346
	for ; Tue, 17 Feb 2004 10:45:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1At7PF-0003KO-Pw; Tue, 17 Feb 2004 10:45:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1At7Ox-0003Hu-Gj
	for megaco@optimus.ietf.org; Tue, 17 Feb 2004 10:44:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07024
	for ; Tue, 17 Feb 2004 10:44:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1At7Ov-0002HG-00
	for megaco@ietf.org; Tue, 17 Feb 2004 10:44:45 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1At7Mv-0001re-00
	for megaco@ietf.org; Tue, 17 Feb 2004 10:42:42 -0500
Received: from [212.243.184.140] (helo=srvchber1200.dt.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 1At7L5-0001QG-00
	for megaco@ietf.org; Tue, 17 Feb 2004 10:40:47 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3F56C.53B4CE38"
Date: Tue, 17 Feb 2004 16:40:10 +0100
Message-ID: <5355A618310B404680473CB13366DB3F15FFA3@srvchber1200.dt.net>
Thread-Topic: MG reconfiguration
Thread-Index: AcP1bFOtcDRTyLkAQYKuY8SH7VUKoA==
From: "Spielmann, Beat" 
To: 
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_70_80,HTML_MESSAGE 
	autolearn=no version=2.60
Subject: [Megaco] MG reconfiguration
Sender: megaco-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_001_01C3F56C.53B4CE38
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I am wondering whether there is common practice to notify the MGC about
MG configuration changes,

e.g. if several physical terminations are added/deleted on a MG by
Element Management is there a common way to notify the MGC about the
availability/removal of these terminations?

=20

Regards

B. Spielmann

=20

=20


------_=_NextPart_001_01C3F56C.53B4CE38
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

















I am wondering whether =
there is common
practice to notify the MGC about MG configuration =
changes,



e.g. if several physical =
terminations
are added/deleted on a MG by Element Management is there a common way to =
notify
the MGC about the availability/removal of these =
terminations?



 
=



Regards


B. =
Spielmann



 
=



 








=00
------_=_NextPart_001_01C3F56C.53B4CE38--

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


From exim@www1.ietf.org  Tue Feb 17 11:02:50 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09723
	for ; Tue, 17 Feb 2004 11:02:49 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1At7fy-0005it-Tg
	for megaco-archive@odin.ietf.org; Tue, 17 Feb 2004 11:02:23 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HG2Mbe021993
	for megaco-archive@odin.ietf.org; Tue, 17 Feb 2004 11:02:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1At7fy-0005ie-OG
	for megaco-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 11:02:22 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09616
	for ; Tue, 17 Feb 2004 11:02:18 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1At7fw-00052v-00
	for megaco-web-archive@ietf.org; Tue, 17 Feb 2004 11:02:20 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1At7dK-0004Uf-00
	for megaco-web-archive@ietf.org; Tue, 17 Feb 2004 10:59:39 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1At7bL-00047a-00
	for megaco-web-archive@ietf.org; Tue, 17 Feb 2004 10:57:35 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1At7PO-0003eK-NI
	for megaco-web-archive@ietf.org; Tue, 17 Feb 2004 10:45:15 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1At7PF-0003KO-Pw; Tue, 17 Feb 2004 10:45:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1At7Ox-0003Hu-Gj
	for megaco@optimus.ietf.org; Tue, 17 Feb 2004 10:44:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07024
	for ; Tue, 17 Feb 2004 10:44:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1At7Ov-0002HG-00
	for megaco@ietf.org; Tue, 17 Feb 2004 10:44:45 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1At7Mv-0001re-00
	for megaco@ietf.org; Tue, 17 Feb 2004 10:42:42 -0500
Received: from [212.243.184.140] (helo=srvchber1200.dt.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 1At7L5-0001QG-00
	for megaco@ietf.org; Tue, 17 Feb 2004 10:40:47 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3F56C.53B4CE38"
Date: Tue, 17 Feb 2004 16:40:10 +0100
Message-ID: <5355A618310B404680473CB13366DB3F15FFA3@srvchber1200.dt.net>
Thread-Topic: MG reconfiguration
Thread-Index: AcP1bFOtcDRTyLkAQYKuY8SH7VUKoA==
From: "Spielmann, Beat" 
To: 
Subject: [Megaco] MG reconfiguration
Sender: megaco-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: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_60_70,HTML_MESSAGE 
	autolearn=no version=2.60

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3F56C.53B4CE38
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I am wondering whether there is common practice to notify the MGC about
MG configuration changes,

e.g. if several physical terminations are added/deleted on a MG by
Element Management is there a common way to notify the MGC about the
availability/removal of these terminations?

=20

Regards

B. Spielmann

=20

=20


------_=_NextPart_001_01C3F56C.53B4CE38
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

















I am wondering whether =
there is common
practice to notify the MGC about MG configuration =
changes,



e.g. if several physical =
terminations
are added/deleted on a MG by Element Management is there a common way to =
notify
the MGC about the availability/removal of these =
terminations?



 
=



Regards


B. =
Spielmann



 
=



 








=00
------_=_NextPart_001_01C3F56C.53B4CE38--

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



From megaco-admin@ietf.org  Tue Feb 17 19:57:32 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20543
	for ; Tue, 17 Feb 2004 19:57:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AtG1N-0002NW-O4; Tue, 17 Feb 2004 19:57:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AtG18-0002Mq-6t
	for megaco@optimus.ietf.org; Tue, 17 Feb 2004 19:56:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20519
	for ; Tue, 17 Feb 2004 19:56:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AtG16-0001Vc-00
	for megaco@ietf.org; Tue, 17 Feb 2004 19:56:44 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AtG0I-0001RN-00
	for megaco@ietf.org; Tue, 17 Feb 2004 19:55:54 -0500
Received: from [211.160.15.6] (helo=mail.putian.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AtFzi-0001It-00
	for megaco@ietf.org; Tue, 17 Feb 2004 19:55:19 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Megaco] MG reconfiguration
Date: Wed, 18 Feb 2004 08:56:18 +0800
Message-ID: <006A9E7E02D21C45AC3CB741AEBF844EAE5B1F@mail.putian.com>
Thread-Topic: Megaco digest, Vol 1 #1089 - 4 msgs
Thread-Index: AcP1d/Y7zMkxdOxUTrqtfOmd+RsdZgAQOTjw
From: "???" 
To: 
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: quoted-printable

 MG will send SvcChg.req command to MGC indicating Service restore when =
terminations are added
and send SvcChg.req command to MGC indicating service cancel when =
terminations are removed.




Message: 4
Date: Tue, 17 Feb 2004 16:40:10 +0100
From: "Spielmann, Beat" 
To: 
Subject: [Megaco] MG reconfiguration

This is a multi-part message in MIME format.

------_=3D_NextPart_001_01C3F56C.53B4CE38
Content-Type: text/plain;
	charset=3D"us-ascii"
Content-Transfer-Encoding: quoted-printable

I am wondering whether there is common practice to notify the MGC about
MG configuration changes,

e.g. if several physical terminations are added/deleted on a MG by
Element Management is there a common way to notify the MGC about the
availability/removal of these terminations?

=3D20

Regards

B. Spielmann



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


From exim@www1.ietf.org  Tue Feb 17 19:59:04 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20640
	for ; Tue, 17 Feb 2004 19:59:04 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AtG2t-0002hr-IR
	for megaco-archive@odin.ietf.org; Tue, 17 Feb 2004 19:58:36 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1I0wZGB010397
	for megaco-archive@odin.ietf.org; Tue, 17 Feb 2004 19:58:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AtG2t-0002hc-DJ
	for megaco-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 19:58:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20600
	for ; Tue, 17 Feb 2004 19:58:32 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AtG2q-0001e0-00
	for megaco-web-archive@ietf.org; Tue, 17 Feb 2004 19:58:32 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AtG1y-0001aB-00
	for megaco-web-archive@ietf.org; Tue, 17 Feb 2004 19:57:39 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AtG1O-0001W2-00
	for megaco-web-archive@ietf.org; Tue, 17 Feb 2004 19:57:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AtG1N-0002NW-O4; Tue, 17 Feb 2004 19:57:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AtG18-0002Mq-6t
	for megaco@optimus.ietf.org; Tue, 17 Feb 2004 19:56:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20519
	for ; Tue, 17 Feb 2004 19:56:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AtG16-0001Vc-00
	for megaco@ietf.org; Tue, 17 Feb 2004 19:56:44 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AtG0I-0001RN-00
	for megaco@ietf.org; Tue, 17 Feb 2004 19:55:54 -0500
Received: from [211.160.15.6] (helo=mail.putian.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AtFzi-0001It-00
	for megaco@ietf.org; Tue, 17 Feb 2004 19:55:19 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Megaco] MG reconfiguration
Date: Wed, 18 Feb 2004 08:56:18 +0800
Message-ID: <006A9E7E02D21C45AC3CB741AEBF844EAE5B1F@mail.putian.com>
Thread-Topic: Megaco digest, Vol 1 #1089 - 4 msgs
Thread-Index: AcP1d/Y7zMkxdOxUTrqtfOmd+RsdZgAQOTjw
From: "???" 
To: 
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

 MG will send SvcChg.req command to MGC indicating Service restore when =
terminations are added
and send SvcChg.req command to MGC indicating service cancel when =
terminations are removed.




Message: 4
Date: Tue, 17 Feb 2004 16:40:10 +0100
From: "Spielmann, Beat" 
To: 
Subject: [Megaco] MG reconfiguration

This is a multi-part message in MIME format.

------_=3D_NextPart_001_01C3F56C.53B4CE38
Content-Type: text/plain;
	charset=3D"us-ascii"
Content-Transfer-Encoding: quoted-printable

I am wondering whether there is common practice to notify the MGC about
MG configuration changes,

e.g. if several physical terminations are added/deleted on a MG by
Element Management is there a common way to notify the MGC about the
availability/removal of these terminations?

=3D20

Regards

B. Spielmann



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



From megaco-admin@ietf.org  Wed Feb 18 23:06:38 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11568
	for ; Wed, 18 Feb 2004 23:06:38 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AtfRr-00079j-J9; Wed, 18 Feb 2004 23:06:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AtfRW-0006vW-H1
	for megaco@optimus.ietf.org; Wed, 18 Feb 2004 23:05:42 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11547
	for ; Wed, 18 Feb 2004 23:05:37 -0500 (EST)
From: shivanand.meti@wipro.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AtfRR-0007VR-00
	for megaco@ietf.org; Wed, 18 Feb 2004 23:05:37 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AtfQ1-0007RM-00
	for megaco@ietf.org; Wed, 18 Feb 2004 23:04:10 -0500
Received: from wiproecmx2.wipro.com ([164.164.31.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AtfOC-0007JB-00
	for megaco@ietf.org; Wed, 18 Feb 2004 23:02:17 -0500
Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125])
	by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i1J41eKA002214
	for ; Thu, 19 Feb 2004 09:31:40 +0530 (IST)
Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Thu, 19 Feb 2004 09:33:31 +0530
Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 19 Feb 2004 09:31:40 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3F69D.13D008AA"
Date: Thu, 19 Feb 2004 09:31:39 +0530
Message-ID: <72001BBBF6CB124BA1C40E415914E21302BEB2@blr-ec-msg04.wipro.com>
Thread-Topic: network failure
Thread-Index: AcP2nUehhDWxbggURe2PmbIzRWpoLA==
To: 
X-OriginalArrivalTime: 19 Feb 2004 04:01:40.0533 (UTC) FILETIME=[142D7E50:01C3F69D]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_60_70,HTML_MESSAGE,
	NO_REAL_NAME autolearn=no version=2.60
Subject: [Megaco] network failure
Sender: megaco-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_001_01C3F69D.13D008AA
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi ,
=20
 Can anybody tell me how to use network failure Events (with Notify
command) ?

------_=_NextPart_001_01C3F69D.13D008AA
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable


Message




Hi=20
,


 


 Can anybody=20
tell me how to use network failure Events (with Notify command)=20
?

=00
------_=_NextPart_001_01C3F69D.13D008AA--

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


From exim@www1.ietf.org  Wed Feb 18 23:09:13 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11722
	for ; Wed, 18 Feb 2004 23:09:13 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AtfUU-0007dO-PS
	for megaco-archive@odin.ietf.org; Wed, 18 Feb 2004 23:08:46 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J48khi029340
	for megaco-archive@odin.ietf.org; Wed, 18 Feb 2004 23:08:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AtfUT-0007d9-VA
	for megaco-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 23:08:45 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11671
	for ; Wed, 18 Feb 2004 23:08:41 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AtfUP-0007h7-00
	for megaco-web-archive@ietf.org; Wed, 18 Feb 2004 23:08:42 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AtfTR-0007cH-00
	for megaco-web-archive@ietf.org; Wed, 18 Feb 2004 23:07:43 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AtfRx-0007Xa-00
	for megaco-web-archive@ietf.org; Wed, 18 Feb 2004 23:06:09 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AtfRr-00079j-J9; Wed, 18 Feb 2004 23:06:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AtfRW-0006vW-H1
	for megaco@optimus.ietf.org; Wed, 18 Feb 2004 23:05:42 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11547
	for ; Wed, 18 Feb 2004 23:05:37 -0500 (EST)
From: shivanand.meti@wipro.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AtfRR-0007VR-00
	for megaco@ietf.org; Wed, 18 Feb 2004 23:05:37 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AtfQ1-0007RM-00
	for megaco@ietf.org; Wed, 18 Feb 2004 23:04:10 -0500
Received: from wiproecmx2.wipro.com ([164.164.31.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AtfOC-0007JB-00
	for megaco@ietf.org; Wed, 18 Feb 2004 23:02:17 -0500
Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125])
	by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i1J41eKA002214
	for ; Thu, 19 Feb 2004 09:31:40 +0530 (IST)
Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Thu, 19 Feb 2004 09:33:31 +0530
Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 19 Feb 2004 09:31:40 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3F69D.13D008AA"
Date: Thu, 19 Feb 2004 09:31:39 +0530
Message-ID: <72001BBBF6CB124BA1C40E415914E21302BEB2@blr-ec-msg04.wipro.com>
Thread-Topic: network failure
Thread-Index: AcP2nUehhDWxbggURe2PmbIzRWpoLA==
To: 
X-OriginalArrivalTime: 19 Feb 2004 04:01:40.0533 (UTC) FILETIME=[142D7E50:01C3F69D]
Subject: [Megaco] network failure
Sender: megaco-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: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE,
	NO_REAL_NAME autolearn=no version=2.60

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3F69D.13D008AA
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi ,
=20
 Can anybody tell me how to use network failure Events (with Notify
command) ?

------_=_NextPart_001_01C3F69D.13D008AA
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable


Message




Hi=20
,


 


 Can anybody=20
tell me how to use network failure Events (with Notify command)=20
?

=00
------_=_NextPart_001_01C3F69D.13D008AA--

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



From megaco-admin@ietf.org  Mon Feb 23 04:09:45 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14372
	for ; Mon, 23 Feb 2004 04:09:44 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvC5H-0004DC-9A; Mon, 23 Feb 2004 04:09:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvC4K-00046W-OZ
	for megaco@optimus.ietf.org; Mon, 23 Feb 2004 04:08:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14332
	for ; Mon, 23 Feb 2004 04:08:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvC4I-000735-00
	for megaco@ietf.org; Mon, 23 Feb 2004 04:08:02 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvC3K-0006zy-00
	for megaco@ietf.org; Mon, 23 Feb 2004 04:07:02 -0500
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvC2S-0006uT-00
	for megaco@ietf.org; Mon, 23 Feb 2004 04:06:08 -0500
Received: from z14593 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HTJ008ZF5649C@mta0.huawei.com> for megaco@ietf.org;
 Mon, 23 Feb 2004 17:03:41 +0800 (CST)
Date: Mon, 23 Feb 2004 17:05:01 +0800
From: Zhao Bo 
To: megaco@ietf.org
Message-id: <000801c3f9ec$1f1258c0$f8486e0a@HUAWEI.COM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
Content-type: text/plain; charset=Windows-1252
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7BIT
Subject: [Megaco] Questions about H.248.17 "line test 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

Could anyone kindly answer the following questions (I can't find the author's email address in H.248.17 text).

1. Section 1 "Scope" says:
"The detailing of results that are reported (e.g. events and statistics), as well as the timing and mechanisms used for
transmitting such records from the MG to the MGC"
Why? If a test is initiated by MGC, why not define a protocol to send the measuring result back to MGC?

2.If we have two switch connected with temination T1 and T2
    SW1--T1-------T2--SW2
Shall the H.248 signal be apllied to T1 and T2, or some extra termination, for example T3 or T4 in the following scenerio:
T3--SW1--T1-------T2--SW2--T4

3. Section 7.1.1 says:
"ITU-T Rec. O.11 describes test responder behaviour. For a description of this behaviour see
clause 9."
But either O.11 or H.247.17 text has a clause 9?

Best regards

Zhao Bo

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

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


From exim@www1.ietf.org  Mon Feb 23 04:11:43 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14502
	for ; Mon, 23 Feb 2004 04:11:43 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvC7P-0004UZ-47
	for megaco-archive@odin.ietf.org; Mon, 23 Feb 2004 04:11:15 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N9BEB7017261
	for megaco-archive@odin.ietf.org; Mon, 23 Feb 2004 04:11:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvC7O-0004UK-Ky
	for megaco-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 04:11:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14482
	for ; Mon, 23 Feb 2004 04:11:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvC7L-0007IS-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 04:11:11 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvC6V-0007DT-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 04:10:20 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvC5T-00078R-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 04:09:15 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvC5H-0004DC-9A; Mon, 23 Feb 2004 04:09:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvC4K-00046W-OZ
	for megaco@optimus.ietf.org; Mon, 23 Feb 2004 04:08:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14332
	for ; Mon, 23 Feb 2004 04:08:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvC4I-000735-00
	for megaco@ietf.org; Mon, 23 Feb 2004 04:08:02 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvC3K-0006zy-00
	for megaco@ietf.org; Mon, 23 Feb 2004 04:07:02 -0500
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvC2S-0006uT-00
	for megaco@ietf.org; Mon, 23 Feb 2004 04:06:08 -0500
Received: from z14593 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HTJ008ZF5649C@mta0.huawei.com> for megaco@ietf.org;
 Mon, 23 Feb 2004 17:03:41 +0800 (CST)
Date: Mon, 23 Feb 2004 17:05:01 +0800
From: Zhao Bo 
To: megaco@ietf.org
Message-id: <000801c3f9ec$1f1258c0$f8486e0a@HUAWEI.COM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
Content-type: text/plain; charset=Windows-1252
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7BIT
Subject: [Megaco] Questions about H.248.17 "line test 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: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Could anyone kindly answer the following questions (I can't find the author's email address in H.248.17 text).

1. Section 1 "Scope" says:
"The detailing of results that are reported (e.g. events and statistics), as well as the timing and mechanisms used for
transmitting such records from the MG to the MGC"
Why? If a test is initiated by MGC, why not define a protocol to send the measuring result back to MGC?

2.If we have two switch connected with temination T1 and T2
    SW1--T1-------T2--SW2
Shall the H.248 signal be apllied to T1 and T2, or some extra termination, for example T3 or T4 in the following scenerio:
T3--SW1--T1-------T2--SW2--T4

3. Section 7.1.1 says:
"ITU-T Rec. O.11 describes test responder behaviour. For a description of this behaviour see
clause 9."
But either O.11 or H.247.17 text has a clause 9?

Best regards

Zhao Bo

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

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



From megaco-admin@ietf.org  Mon Feb 23 04:30:32 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15337
	for ; Mon, 23 Feb 2004 04:30:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvCPb-0005dp-V7; Mon, 23 Feb 2004 04:30:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvCOf-0005UD-4y
	for megaco@optimus.ietf.org; Mon, 23 Feb 2004 04:29:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15232
	for ; Mon, 23 Feb 2004 04:29:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvCOc-0000q3-00
	for megaco@ietf.org; Mon, 23 Feb 2004 04:29:02 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvCNh-0000kU-00
	for megaco@ietf.org; Mon, 23 Feb 2004 04:28:05 -0500
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvCMi-0000Tv-00
	for megaco@ietf.org; Mon, 23 Feb 2004 04:27:06 -0500
Received: from z14593 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HTJ008E763G9C@mta0.huawei.com> for megaco@ietf.org;
 Mon, 23 Feb 2004 17:23:41 +0800 (CST)
Date: Mon, 23 Feb 2004 17:25:02 +0800
From: Zhao Bo 
To: megaco@ietf.org
Message-id: <000b01c3f9ee$ea987ae0$f8486e0a@HUAWEI.COM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
Content-type: text/plain; charset=Windows-1252
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7BIT
Subject: [Megaco] Questions about H.248.17 "line test packages"(upgrade,sorry,
 my poor English)
Sender: megaco-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

Could anyone kindly answer the following questions (I can't find the author's email address in H.248.17 text).

1. Section 1 "Scope" says:
"The detailing of results that are reported (e.g. events and statistics), as well as the timing and mechanisms used for
transmitting such records from the MG to the MGC"
Why? If a test is initiated by MGC, why not define a protocol to send the measuring result back to MGC?

2.If we have two switch connected with temination T1 and T2
    SW1--T1-------T2--SW2
Shall the H.248 signal be apllied to T1 and T2, or some extra termination, for example T3 or T4 in the following scenerio:
T3--SW1--T1-------T2--SW2--T4

3. Section 7.1.1 says:
"ITU-T Rec. O.11 describes test responder behaviour. For a description of this behaviour see
clause 9."
But neither O.11 nor H.247.17 text has a clause 9?

Best regards

Zhao Bo


Zhao Bo

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

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


From exim@www1.ietf.org  Mon Feb 23 04:32:39 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15551
	for ; Mon, 23 Feb 2004 04:32:39 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvCRg-0005sW-53
	for megaco-archive@odin.ietf.org; Mon, 23 Feb 2004 04:32:12 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N9WC36022592
	for megaco-archive@odin.ietf.org; Mon, 23 Feb 2004 04:32:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvCRf-0005sJ-Dq
	for megaco-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 04:32:11 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15498
	for ; Mon, 23 Feb 2004 04:32:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvCRc-0001D7-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 04:32:08 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvCQb-000154-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 04:31:06 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvCPb-0000wF-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 04:30:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvCPb-0005dp-V7; Mon, 23 Feb 2004 04:30:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvCOf-0005UD-4y
	for megaco@optimus.ietf.org; Mon, 23 Feb 2004 04:29:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15232
	for ; Mon, 23 Feb 2004 04:29:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvCOc-0000q3-00
	for megaco@ietf.org; Mon, 23 Feb 2004 04:29:02 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvCNh-0000kU-00
	for megaco@ietf.org; Mon, 23 Feb 2004 04:28:05 -0500
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvCMi-0000Tv-00
	for megaco@ietf.org; Mon, 23 Feb 2004 04:27:06 -0500
Received: from z14593 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HTJ008E763G9C@mta0.huawei.com> for megaco@ietf.org;
 Mon, 23 Feb 2004 17:23:41 +0800 (CST)
Date: Mon, 23 Feb 2004 17:25:02 +0800
From: Zhao Bo 
To: megaco@ietf.org
Message-id: <000b01c3f9ee$ea987ae0$f8486e0a@HUAWEI.COM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
Content-type: text/plain; charset=Windows-1252
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7BIT
Subject: [Megaco] Questions about H.248.17 "line test packages"(upgrade,sorry,
 my poor English)
Sender: megaco-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: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Could anyone kindly answer the following questions (I can't find the author's email address in H.248.17 text).

1. Section 1 "Scope" says:
"The detailing of results that are reported (e.g. events and statistics), as well as the timing and mechanisms used for
transmitting such records from the MG to the MGC"
Why? If a test is initiated by MGC, why not define a protocol to send the measuring result back to MGC?

2.If we have two switch connected with temination T1 and T2
    SW1--T1-------T2--SW2
Shall the H.248 signal be apllied to T1 and T2, or some extra termination, for example T3 or T4 in the following scenerio:
T3--SW1--T1-------T2--SW2--T4

3. Section 7.1.1 says:
"ITU-T Rec. O.11 describes test responder behaviour. For a description of this behaviour see
clause 9."
But neither O.11 nor H.247.17 text has a clause 9?

Best regards

Zhao Bo


Zhao Bo

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

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



From megaco-admin@ietf.org  Mon Feb 23 13:34:30 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09871
	for ; Mon, 23 Feb 2004 13:34:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvKu1-00052s-6I; Mon, 23 Feb 2004 13:34:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvKtU-0004sq-GF
	for megaco@optimus.ietf.org; Mon, 23 Feb 2004 13:33:28 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09813
	for ; Mon, 23 Feb 2004 13:33:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvKtS-0004ed-00
	for megaco@ietf.org; Mon, 23 Feb 2004 13:33:26 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvKsW-0004a3-00
	for megaco@ietf.org; Mon, 23 Feb 2004 13:32:28 -0500
Received: from [198.87.49.137] (helo=mx2.veraznet.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvKrx-0004V1-00
	for megaco@ietf.org; Mon, 23 Feb 2004 13:31:53 -0500
Received: from sapphire.veraznet.com ([198.87.49.5]) by mx2.veraznet.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 23 Feb 2004 10:31:22 -0800
Received: by mail.veraznet.com with Internet Mail Service (5.5.2656.59)
	id <192SRK27>; Mon, 23 Feb 2004 10:33:38 -0800
Message-ID: <9E388C880C1ED411AFE1009027E787250526F145@mail.veraznet.com>
From: Madhubabu Brahmanapally 
To: megaco@ietf.org
Date: Mon, 23 Feb 2004 10:33:38 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3FA3B.8D8B7FD0"
X-OriginalArrivalTime: 23 Feb 2004 18:31:22.0665 (UTC) FILETIME=[3CCDF190:01C3FA3B]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_40_50,HTML_MESSAGE 
	autolearn=no version=2.60
Subject: [Megaco] Are Megaco subscribers immobile??
Sender: megaco-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_01C3FA3B.8D8B7FD0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi All,
The present Protocol spec doesn't address the issue of mobility of users
connected to the residential gateways. Are there any proposals for
registration of endpoints when they change their physical location (Yet
retaining their domain name,etc).  Similar to the REGISTER message in SIP. 
 
Regards
Madhubabu

------_=_NextPart_001_01C3FA3B.8D8B7FD0
Content-Type: text/html;
	charset="iso-8859-1"









Hi 
All,


The present Protocol 
spec doesn't address the issue of mobility of users connected to the residential 
gateways. Are there any proposals for registration of endpoints when they change 
their physical location (Yet retaining their domain name,etc).  Similar to 
the REGISTER message in SIP. 


 


Regards


Madhubabu


------_=_NextPart_001_01C3FA3B.8D8B7FD0--

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


From exim@www1.ietf.org  Mon Feb 23 13:36:02 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09934
	for ; Mon, 23 Feb 2004 13:36:02 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvKvW-0005Kz-MZ
	for megaco-archive@odin.ietf.org; Mon, 23 Feb 2004 13:35:34 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NIZYAV020516
	for megaco-archive@odin.ietf.org; Mon, 23 Feb 2004 13:35:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvKvW-0005Kp-J6
	for megaco-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 13:35:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09915
	for ; Mon, 23 Feb 2004 13:35:31 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvKvU-0004qn-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 13:35:32 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvKue-0004lt-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 13:34:41 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvKu1-0004gN-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 13:34:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvKu1-00052s-6I; Mon, 23 Feb 2004 13:34:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvKtU-0004sq-GF
	for megaco@optimus.ietf.org; Mon, 23 Feb 2004 13:33:28 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09813
	for ; Mon, 23 Feb 2004 13:33:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvKtS-0004ed-00
	for megaco@ietf.org; Mon, 23 Feb 2004 13:33:26 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvKsW-0004a3-00
	for megaco@ietf.org; Mon, 23 Feb 2004 13:32:28 -0500
Received: from [198.87.49.137] (helo=mx2.veraznet.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvKrx-0004V1-00
	for megaco@ietf.org; Mon, 23 Feb 2004 13:31:53 -0500
Received: from sapphire.veraznet.com ([198.87.49.5]) by mx2.veraznet.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 23 Feb 2004 10:31:22 -0800
Received: by mail.veraznet.com with Internet Mail Service (5.5.2656.59)
	id <192SRK27>; Mon, 23 Feb 2004 10:33:38 -0800
Message-ID: <9E388C880C1ED411AFE1009027E787250526F145@mail.veraznet.com>
From: Madhubabu Brahmanapally 
To: megaco@ietf.org
Date: Mon, 23 Feb 2004 10:33:38 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3FA3B.8D8B7FD0"
X-OriginalArrivalTime: 23 Feb 2004 18:31:22.0665 (UTC) FILETIME=[3CCDF190:01C3FA3B]
Subject: [Megaco] Are Megaco subscribers immobile??
Sender: megaco-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: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE 
	autolearn=no version=2.60

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

------_=_NextPart_001_01C3FA3B.8D8B7FD0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi All,
The present Protocol spec doesn't address the issue of mobility of users
connected to the residential gateways. Are there any proposals for
registration of endpoints when they change their physical location (Yet
retaining their domain name,etc).  Similar to the REGISTER message in SIP. 
 
Regards
Madhubabu

------_=_NextPart_001_01C3FA3B.8D8B7FD0
Content-Type: text/html;
	charset="iso-8859-1"









Hi 
All,


The present Protocol 
spec doesn't address the issue of mobility of users connected to the residential 
gateways. Are there any proposals for registration of endpoints when they change 
their physical location (Yet retaining their domain name,etc).  Similar to 
the REGISTER message in SIP. 


 


Regards


Madhubabu


------_=_NextPart_001_01C3FA3B.8D8B7FD0--

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



From megaco-admin@ietf.org  Mon Feb 23 13:53:29 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11265
	for ; Mon, 23 Feb 2004 13:53:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvLCO-0007FY-Tc; Mon, 23 Feb 2004 13:53:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvLBo-0007Ef-P1
	for megaco@optimus.ietf.org; Mon, 23 Feb 2004 13:52:24 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11199
	for ; Mon, 23 Feb 2004 13:52:21 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvLBm-0006mx-00
	for megaco@ietf.org; Mon, 23 Feb 2004 13:52:22 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvLAq-0006jU-00
	for megaco@ietf.org; Mon, 23 Feb 2004 13:51:24 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvLAD-0006dN-00
	for megaco@ietf.org; Mon, 23 Feb 2004 13:50:45 -0500
Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1NIoCZ11498;
	Mon, 23 Feb 2004 13:50:12 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id FKLHBRQ3; Mon, 23 Feb 2004 13:50:12 -0500
Received: from nortelnetworks.com (acart1hf.ca.nortel.com [47.129.129.223]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DBDZJKHB; Mon, 23 Feb 2004 13:50:13 -0500
Message-ID: <403A4B63.2030800@nortelnetworks.com>
Date: Mon, 23 Feb 2004 13:50:11 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Madhubabu Brahmanapally 
CC: megaco@ietf.org
Subject: Re: [Megaco] Are Megaco subscribers immobile??
References: <9E388C880C1ED411AFE1009027E787250526F145@mail.veraznet.com>
In-Reply-To: <9E388C880C1ED411AFE1009027E787250526F145@mail.veraznet.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit

I would think this contrary to the spirit of Megaco, in that the awareness of 
services resides in the MGC alone and is not reflected in the protocol.

Madhubabu Brahmanapally wrote:

> Hi All,
> The present Protocol spec doesn't address the issue of mobility of users 
> connected to the residential gateways. Are there any proposals for 
> registration of endpoints when they change their physical location (Yet 
> retaining their domain name,etc).  Similar to the REGISTER message in SIP.
>  
> Regards
> Madhubabu

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


From exim@www1.ietf.org  Mon Feb 23 14:05:36 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12393
	for ; Mon, 23 Feb 2004 14:05:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvLO7-0007fI-Sb
	for megaco-archive@odin.ietf.org; Mon, 23 Feb 2004 14:05:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NJ57Gt029461
	for megaco-archive@odin.ietf.org; Mon, 23 Feb 2004 14:05:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvLO7-0007f6-Nh
	for megaco-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 14:05:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12288
	for ; Mon, 23 Feb 2004 14:05:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvLO4-0000kN-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 14:05:05 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvLLw-0000Jy-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 14:02:53 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvLKb-00005G-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 14:01:29 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1AvLCQ-0001vZ-T3
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 13:53:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvLCO-0007FY-Tc; Mon, 23 Feb 2004 13:53:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvLBo-0007Ef-P1
	for megaco@optimus.ietf.org; Mon, 23 Feb 2004 13:52:24 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11199
	for ; Mon, 23 Feb 2004 13:52:21 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvLBm-0006mx-00
	for megaco@ietf.org; Mon, 23 Feb 2004 13:52:22 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvLAq-0006jU-00
	for megaco@ietf.org; Mon, 23 Feb 2004 13:51:24 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvLAD-0006dN-00
	for megaco@ietf.org; Mon, 23 Feb 2004 13:50:45 -0500
Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1NIoCZ11498;
	Mon, 23 Feb 2004 13:50:12 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id FKLHBRQ3; Mon, 23 Feb 2004 13:50:12 -0500
Received: from nortelnetworks.com (acart1hf.ca.nortel.com [47.129.129.223]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DBDZJKHB; Mon, 23 Feb 2004 13:50:13 -0500
Message-ID: <403A4B63.2030800@nortelnetworks.com>
Date: Mon, 23 Feb 2004 13:50:11 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Madhubabu Brahmanapally 
CC: megaco@ietf.org
Subject: Re: [Megaco] Are Megaco subscribers immobile??
References: <9E388C880C1ED411AFE1009027E787250526F145@mail.veraznet.com>
In-Reply-To: <9E388C880C1ED411AFE1009027E787250526F145@mail.veraznet.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: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I would think this contrary to the spirit of Megaco, in that the awareness of 
services resides in the MGC alone and is not reflected in the protocol.

Madhubabu Brahmanapally wrote:

> Hi All,
> The present Protocol spec doesn't address the issue of mobility of users 
> connected to the residential gateways. Are there any proposals for 
> registration of endpoints when they change their physical location (Yet 
> retaining their domain name,etc).  Similar to the REGISTER message in SIP.
>  
> Regards
> Madhubabu

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



From megaco-admin@ietf.org  Mon Feb 23 15:16:31 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17249
	for ; Mon, 23 Feb 2004 15:16:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvMUk-0005I7-Rx; Mon, 23 Feb 2004 15:16:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvMUB-00057a-85
	for megaco@optimus.ietf.org; Mon, 23 Feb 2004 15:15:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17124
	for ; Mon, 23 Feb 2004 15:15:24 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvMUA-0007JU-00
	for megaco@ietf.org; Mon, 23 Feb 2004 15:15:26 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvMTG-0007FU-00
	for megaco@ietf.org; Mon, 23 Feb 2004 15:14:31 -0500
Received: from [198.87.49.137] (helo=mx2.veraznet.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvMSQ-00076t-00
	for megaco@ietf.org; Mon, 23 Feb 2004 15:13:38 -0500
Received: from sapphire.veraznet.com ([198.87.49.5]) by mx2.veraznet.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 23 Feb 2004 12:13:07 -0800
Received: by mail.veraznet.com with Internet Mail Service (5.5.2656.59)
	id <192SRKTF>; Mon, 23 Feb 2004 12:15:24 -0800
Message-ID: <9E388C880C1ED411AFE1009027E787250526F146@mail.veraznet.com>
From: Madhubabu Brahmanapally 
To: "'Tom Taylor'" 
Cc: megaco@ietf.org
Subject: RE: [Megaco] Are Megaco subscribers immobile??
Date: Mon, 23 Feb 2004 12:15:22 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3FA49.C4497190"
X-OriginalArrivalTime: 23 Feb 2004 20:13:07.0869 (UTC) FILETIME=[73CA24D0:01C3FA49]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE 
	autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
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_01C3FA49.C4497190
Content-Type: text/plain

Hi Tom,
Thanks for the reply.

If the protocol doesn't provide any mechanism...everything boils down to
provisioning which defeats the purpose of mobility...Of course the protocol
is not addressing the mobility issue..

But, If new terminations/cards are added...apart from pre-provisioning
shouldn't there be a way so that the GW can scale using the protocol
interface. rather than through proprietary means...


Even now when the serviceChange when generated with "restart", it is assumed
that the terminations are pre-provisioned at the MGC. Then, How does the MGs
scale dynamically. Of course scaling down is not a problem...as the group of
terminations are already known to both entities.


Regards
Madhubabu

-----Original Message-----
From: Tom Taylor [mailto:taylor@nortelnetworks.com]
Sent: Monday, February 23, 2004 10:50 AM
To: Madhubabu Brahmanapally
Cc: megaco@ietf.org
Subject: Re: [Megaco] Are Megaco subscribers immobile??


I would think this contrary to the spirit of Megaco, in that the awareness
of 
services resides in the MGC alone and is not reflected in the protocol.

Madhubabu Brahmanapally wrote:

> Hi All,
> The present Protocol spec doesn't address the issue of mobility of users 
> connected to the residential gateways. Are there any proposals for 
> registration of endpoints when they change their physical location (Yet 
> retaining their domain name,etc).  Similar to the REGISTER message in SIP.
>  
> Regards
> Madhubabu

------_=_NextPart_001_01C3FA49.C4497190
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [Megaco] Are Megaco subscribers immobile??




Hi Tom,

Thanks for the reply.




If the protocol doesn't provide any =
mechanism...everything boils down to provisioning which defeats the =
purpose of mobility...Of course the protocol is not addressing the =
mobility issue..



But, If new terminations/cards are added...apart from =
pre-provisioning shouldn't there be a way so that the GW can scale =
using the protocol interface. rather than through proprietary =
means...





Even now when the serviceChange when generated with =
"restart", it is assumed that the terminations are =
pre-provisioned at the MGC. Then, How does the MGs scale dynamically. =
Of course scaling down is not a problem...as the group of terminations =
are already known to both entities.





Regards

Madhubabu




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

From: Tom Taylor [mailto:taylor@nortelnetworks.c=
om]

Sent: Monday, February 23, 2004 10:50 AM

To: Madhubabu Brahmanapally

Cc: megaco@ietf.org

Subject: Re: [Megaco] Are Megaco subscribers =
immobile??






I would think this contrary to the spirit of Megaco, =
in that the awareness of 

services resides in the MGC alone and is not =
reflected in the protocol.




Madhubabu Brahmanapally wrote:




> Hi All,

> The present Protocol spec doesn't address the =
issue of mobility of users 

> connected to the residential gateways. Are =
there any proposals for 

> registration of endpoints when they change =
their physical location (Yet 

> retaining their domain name,etc).  Similar =
to the REGISTER message in SIP.

>  

> Regards

> Madhubabu





------_=_NextPart_001_01C3FA49.C4497190--

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


From exim@www1.ietf.org  Mon Feb 23 15:18:04 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17425
	for ; Mon, 23 Feb 2004 15:18:03 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvMWF-0005jh-LD
	for megaco-archive@odin.ietf.org; Mon, 23 Feb 2004 15:17:35 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NKHZS6022042
	for megaco-archive@odin.ietf.org; Mon, 23 Feb 2004 15:17:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvMWF-0005jP-H6
	for megaco-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 15:17:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17383
	for ; Mon, 23 Feb 2004 15:17:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvMWE-0007Tq-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 15:17:34 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvMVK-0007PX-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 15:16:39 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvMUk-0007Kq-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 15:16:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvMUk-0005I7-Rx; Mon, 23 Feb 2004 15:16:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvMUB-00057a-85
	for megaco@optimus.ietf.org; Mon, 23 Feb 2004 15:15:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17124
	for ; Mon, 23 Feb 2004 15:15:24 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvMUA-0007JU-00
	for megaco@ietf.org; Mon, 23 Feb 2004 15:15:26 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvMTG-0007FU-00
	for megaco@ietf.org; Mon, 23 Feb 2004 15:14:31 -0500
Received: from [198.87.49.137] (helo=mx2.veraznet.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvMSQ-00076t-00
	for megaco@ietf.org; Mon, 23 Feb 2004 15:13:38 -0500
Received: from sapphire.veraznet.com ([198.87.49.5]) by mx2.veraznet.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 23 Feb 2004 12:13:07 -0800
Received: by mail.veraznet.com with Internet Mail Service (5.5.2656.59)
	id <192SRKTF>; Mon, 23 Feb 2004 12:15:24 -0800
Message-ID: <9E388C880C1ED411AFE1009027E787250526F146@mail.veraznet.com>
From: Madhubabu Brahmanapally 
To: "'Tom Taylor'" 
Cc: megaco@ietf.org
Subject: RE: [Megaco] Are Megaco subscribers immobile??
Date: Mon, 23 Feb 2004 12:15:22 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3FA49.C4497190"
X-OriginalArrivalTime: 23 Feb 2004 20:13:07.0869 (UTC) FILETIME=[73CA24D0:01C3FA49]
Sender: megaco-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: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE 
	autolearn=no version=2.60

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

------_=_NextPart_001_01C3FA49.C4497190
Content-Type: text/plain

Hi Tom,
Thanks for the reply.

If the protocol doesn't provide any mechanism...everything boils down to
provisioning which defeats the purpose of mobility...Of course the protocol
is not addressing the mobility issue..

But, If new terminations/cards are added...apart from pre-provisioning
shouldn't there be a way so that the GW can scale using the protocol
interface. rather than through proprietary means...


Even now when the serviceChange when generated with "restart", it is assumed
that the terminations are pre-provisioned at the MGC. Then, How does the MGs
scale dynamically. Of course scaling down is not a problem...as the group of
terminations are already known to both entities.


Regards
Madhubabu

-----Original Message-----
From: Tom Taylor [mailto:taylor@nortelnetworks.com]
Sent: Monday, February 23, 2004 10:50 AM
To: Madhubabu Brahmanapally
Cc: megaco@ietf.org
Subject: Re: [Megaco] Are Megaco subscribers immobile??


I would think this contrary to the spirit of Megaco, in that the awareness
of 
services resides in the MGC alone and is not reflected in the protocol.

Madhubabu Brahmanapally wrote:

> Hi All,
> The present Protocol spec doesn't address the issue of mobility of users 
> connected to the residential gateways. Are there any proposals for 
> registration of endpoints when they change their physical location (Yet 
> retaining their domain name,etc).  Similar to the REGISTER message in SIP.
>  
> Regards
> Madhubabu

------_=_NextPart_001_01C3FA49.C4497190
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [Megaco] Are Megaco subscribers immobile??




Hi Tom,

Thanks for the reply.




If the protocol doesn't provide any =
mechanism...everything boils down to provisioning which defeats the =
purpose of mobility...Of course the protocol is not addressing the =
mobility issue..



But, If new terminations/cards are added...apart from =
pre-provisioning shouldn't there be a way so that the GW can scale =
using the protocol interface. rather than through proprietary =
means...





Even now when the serviceChange when generated with =
"restart", it is assumed that the terminations are =
pre-provisioned at the MGC. Then, How does the MGs scale dynamically. =
Of course scaling down is not a problem...as the group of terminations =
are already known to both entities.





Regards

Madhubabu




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

From: Tom Taylor [mailto:taylor@nortelnetworks.c=
om]

Sent: Monday, February 23, 2004 10:50 AM

To: Madhubabu Brahmanapally

Cc: megaco@ietf.org

Subject: Re: [Megaco] Are Megaco subscribers =
immobile??






I would think this contrary to the spirit of Megaco, =
in that the awareness of 

services resides in the MGC alone and is not =
reflected in the protocol.




Madhubabu Brahmanapally wrote:




> Hi All,

> The present Protocol spec doesn't address the =
issue of mobility of users 

> connected to the residential gateways. Are =
there any proposals for 

> registration of endpoints when they change =
their physical location (Yet 

> retaining their domain name,etc).  Similar =
to the REGISTER message in SIP.

>  

> Regards

> Madhubabu





------_=_NextPart_001_01C3FA49.C4497190--

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



From megaco-admin@ietf.org  Mon Feb 23 15:35:31 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18559
	for ; Mon, 23 Feb 2004 15:35:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvMn9-0007my-5J; Mon, 23 Feb 2004 15:35:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvMmY-0007jh-Lj
	for megaco@optimus.ietf.org; Mon, 23 Feb 2004 15:34:26 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18541
	for ; Mon, 23 Feb 2004 15:34:24 -0500 (EST)
From: shashi.kumar@wipro.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvMmX-0001BC-00
	for megaco@ietf.org; Mon, 23 Feb 2004 15:34:25 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvMlp-000187-00
	for megaco@ietf.org; Mon, 23 Feb 2004 15:33:42 -0500
Received: from wiproecmx2.wipro.com ([164.164.31.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvMl3-0000yI-00
	for megaco@ietf.org; Mon, 23 Feb 2004 15:32:54 -0500
Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125])
	by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i1NKWIqA019590
	for ; Tue, 24 Feb 2004 02:02:20 +0530 (IST)
Received: from blr-ec-bh3.wipro.com ([10.200.50.93]) by ec-vwall-wd with InterScan Messaging Security Suite; Tue, 24 Feb 2004 02:03:18 +0530
Received: from blr-ec-msg02.wipro.com ([10.200.51.99]) by blr-ec-bh3.wipro.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 24 Feb 2004 02:02:18 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3FA4C.21349DDE"
Subject: RE: [Megaco] Are Megaco subscribers immobile??
Date: Tue, 24 Feb 2004 02:02:17 +0530
Message-ID: 
Thread-Topic: [Megaco] Are Megaco subscribers immobile??
Thread-Index: AcP6SfiRy7m5gqNaSfeA7O8W4eja5QAAVa+g
To: , 
Cc: 
X-OriginalArrivalTime: 23 Feb 2004 20:32:18.0032 (UTC) FILETIME=[21571700:01C3FA4C]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no 
	version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3FA4C.21349DDE
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Madhubabu,
=20
  Protocol might not directly address the dynamic scaling of MG's, but =
it is always possible that, service change with restart could be =
initiated, when MGC is made aware of the fact that, we are adding the =
new terminations and then trigger a service change with restart. This =
would indirectly amount to dynamic scaling of MG's with out any =
proprietary means.
=20
Thanks,
Shashi

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of =
Madhubabu Brahmanapally
Sent: Tuesday, February 24, 2004 1:45 AM
To: 'Tom Taylor'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Are Megaco subscribers immobile??



Hi Tom,=20
Thanks for the reply.=20

If the protocol doesn't provide any mechanism...everything boils down to =
provisioning which defeats the purpose of mobility...Of course the =
protocol is not addressing the mobility issue..

But, If new terminations/cards are added...apart from pre-provisioning =
shouldn't there be a way so that the GW can scale using the protocol =
interface. rather than through proprietary means...


Even now when the serviceChange when generated with "restart", it is =
assumed that the terminations are pre-provisioned at the MGC. Then, How =
does the MGs scale dynamically. Of course scaling down is not a =
problem...as the group of terminations are already known to both =
entities.


Regards=20
Madhubabu=20

-----Original Message-----=20
From: Tom Taylor [ mailto:taylor@nortelnetworks.com]=20
Sent: Monday, February 23, 2004 10:50 AM=20
To: Madhubabu Brahmanapally=20
Cc: megaco@ietf.org=20
Subject: Re: [Megaco] Are Megaco subscribers immobile??=20


I would think this contrary to the spirit of Megaco, in that the =
awareness of=20
services resides in the MGC alone and is not reflected in the protocol.=20

Madhubabu Brahmanapally wrote:=20

> Hi All,=20
> The present Protocol spec doesn't address the issue of mobility of =
users=20
> connected to the residential gateways. Are there any proposals for=20
> registration of endpoints when they change their physical location =
(Yet=20
> retaining their domain name,etc).  Similar to the REGISTER message in =
SIP.=20
> =20
> Regards=20
> Madhubabu=20


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




RE: [Megaco] Are Megaco subscribers immobile??






Madhubabu,


 


 =20
Protocol might not directly address the dynamic scaling of MG's, =
but it is=20
always possible that, service change with restart could be initiated, =
when MGC=20
is made aware of the fact that, we are adding the new terminations and=20
then trigger a service change with restart. This would indirectly =
amount to=20
dynamic scaling of MG's with out any proprietary =
means.


 


Thanks,


Shashi



  
-----Original Message-----
From: =
megaco-admin@ietf.org=20
  [mailto:megaco-admin@ietf.org]On Behalf Of Madhubabu=20
  Brahmanapally
Sent: Tuesday, February 24, 2004 1:45 =
AM
To:=20
  'Tom Taylor'
Cc: megaco@ietf.org
Subject: RE: =
[Megaco] Are=20
  Megaco subscribers immobile??


  
Hi Tom, 
Thanks for the =
reply.=20
  

  
If the protocol doesn't provide any =
mechanism...everything=20
  boils down to provisioning which defeats the purpose of mobility...Of =
course=20
  the protocol is not addressing the mobility issue..

  
But, If new terminations/cards are added...apart =
from=20
  pre-provisioning shouldn't there be a way so that the GW can scale =
using the=20
  protocol interface. rather than through proprietary =
means...


  
Even now when the serviceChange when generated with =
"restart",=20
  it is assumed that the terminations are pre-provisioned at the MGC. =
Then, How=20
  does the MGs scale dynamically. Of course scaling down is not a =
problem...as=20
  the group of terminations are already known to both =
entities.


  
Regards 
Madhubabu =


  
-----Original Message----- 
From: Tom=20
  Taylor [mailto:taylor@nortelnetworks.co=
m]=20
  
Sent: Monday, February 23, 2004 10:50 AM =

To: Madhubabu Brahmanapally 
Cc:=20
  megaco@ietf.org 
Subject: Re: [Megaco] Are =
Megaco=20
  subscribers immobile?? 


  
I would think this contrary to the spirit of Megaco, =
in that=20
  the awareness of 
services resides in the MGC =
alone and=20
  is not reflected in the protocol. 

  
Madhubabu Brahmanapally wrote: 

  
> Hi All, 
> The =
present Protocol=20
  spec doesn't address the issue of mobility of users 
> connected to the residential gateways. Are there any =
proposals for=20
  
> registration of endpoints when they =
change their=20
  physical location (Yet 
> retaining their =
domain=20
  name,etc).  Similar to the REGISTER message in SIP. =

>  
> Regards =

> Madhubabu 


------_=_NextPart_001_01C3FA4C.21349DDE--

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


From exim@www1.ietf.org  Mon Feb 23 15:37:01 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18602
	for ; Mon, 23 Feb 2004 15:37:01 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvMob-0007x2-Jh
	for megaco-archive@odin.ietf.org; Mon, 23 Feb 2004 15:36:33 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NKaXjE030558
	for megaco-archive@odin.ietf.org; Mon, 23 Feb 2004 15:36:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvMob-0007wn-FT
	for megaco-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 15:36:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18590
	for ; Mon, 23 Feb 2004 15:36:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvMoa-0001KY-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 15:36:32 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvMnZ-0001Fo-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 15:35:30 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvMn8-0001CB-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 15:35:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvMn9-0007my-5J; Mon, 23 Feb 2004 15:35:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvMmY-0007jh-Lj
	for megaco@optimus.ietf.org; Mon, 23 Feb 2004 15:34:26 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18541
	for ; Mon, 23 Feb 2004 15:34:24 -0500 (EST)
From: shashi.kumar@wipro.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvMmX-0001BC-00
	for megaco@ietf.org; Mon, 23 Feb 2004 15:34:25 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvMlp-000187-00
	for megaco@ietf.org; Mon, 23 Feb 2004 15:33:42 -0500
Received: from wiproecmx2.wipro.com ([164.164.31.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvMl3-0000yI-00
	for megaco@ietf.org; Mon, 23 Feb 2004 15:32:54 -0500
Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125])
	by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i1NKWIqA019590
	for ; Tue, 24 Feb 2004 02:02:20 +0530 (IST)
Received: from blr-ec-bh3.wipro.com ([10.200.50.93]) by ec-vwall-wd with InterScan Messaging Security Suite; Tue, 24 Feb 2004 02:03:18 +0530
Received: from blr-ec-msg02.wipro.com ([10.200.51.99]) by blr-ec-bh3.wipro.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 24 Feb 2004 02:02:18 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3FA4C.21349DDE"
Subject: RE: [Megaco] Are Megaco subscribers immobile??
Date: Tue, 24 Feb 2004 02:02:17 +0530
Message-ID: 
Thread-Topic: [Megaco] Are Megaco subscribers immobile??
Thread-Index: AcP6SfiRy7m5gqNaSfeA7O8W4eja5QAAVa+g
To: , 
Cc: 
X-OriginalArrivalTime: 23 Feb 2004 20:32:18.0032 (UTC) FILETIME=[21571700:01C3FA4C]
Sender: megaco-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: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_20_30,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no 
	version=2.60

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3FA4C.21349DDE
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Madhubabu,
=20
  Protocol might not directly address the dynamic scaling of MG's, but =
it is always possible that, service change with restart could be =
initiated, when MGC is made aware of the fact that, we are adding the =
new terminations and then trigger a service change with restart. This =
would indirectly amount to dynamic scaling of MG's with out any =
proprietary means.
=20
Thanks,
Shashi

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of =
Madhubabu Brahmanapally
Sent: Tuesday, February 24, 2004 1:45 AM
To: 'Tom Taylor'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Are Megaco subscribers immobile??



Hi Tom,=20
Thanks for the reply.=20

If the protocol doesn't provide any mechanism...everything boils down to =
provisioning which defeats the purpose of mobility...Of course the =
protocol is not addressing the mobility issue..

But, If new terminations/cards are added...apart from pre-provisioning =
shouldn't there be a way so that the GW can scale using the protocol =
interface. rather than through proprietary means...


Even now when the serviceChange when generated with "restart", it is =
assumed that the terminations are pre-provisioned at the MGC. Then, How =
does the MGs scale dynamically. Of course scaling down is not a =
problem...as the group of terminations are already known to both =
entities.


Regards=20
Madhubabu=20

-----Original Message-----=20
From: Tom Taylor [ mailto:taylor@nortelnetworks.com]=20
Sent: Monday, February 23, 2004 10:50 AM=20
To: Madhubabu Brahmanapally=20
Cc: megaco@ietf.org=20
Subject: Re: [Megaco] Are Megaco subscribers immobile??=20


I would think this contrary to the spirit of Megaco, in that the =
awareness of=20
services resides in the MGC alone and is not reflected in the protocol.=20

Madhubabu Brahmanapally wrote:=20

> Hi All,=20
> The present Protocol spec doesn't address the issue of mobility of =
users=20
> connected to the residential gateways. Are there any proposals for=20
> registration of endpoints when they change their physical location =
(Yet=20
> retaining their domain name,etc).  Similar to the REGISTER message in =
SIP.=20
> =20
> Regards=20
> Madhubabu=20


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




RE: [Megaco] Are Megaco subscribers immobile??






Madhubabu,


 


 =20
Protocol might not directly address the dynamic scaling of MG's, =
but it is=20
always possible that, service change with restart could be initiated, =
when MGC=20
is made aware of the fact that, we are adding the new terminations and=20
then trigger a service change with restart. This would indirectly =
amount to=20
dynamic scaling of MG's with out any proprietary =
means.


 


Thanks,


Shashi



  
-----Original Message-----
From: =
megaco-admin@ietf.org=20
  [mailto:megaco-admin@ietf.org]On Behalf Of Madhubabu=20
  Brahmanapally
Sent: Tuesday, February 24, 2004 1:45 =
AM
To:=20
  'Tom Taylor'
Cc: megaco@ietf.org
Subject: RE: =
[Megaco] Are=20
  Megaco subscribers immobile??


  
Hi Tom, 
Thanks for the =
reply.=20
  

  
If the protocol doesn't provide any =
mechanism...everything=20
  boils down to provisioning which defeats the purpose of mobility...Of =
course=20
  the protocol is not addressing the mobility issue..

  
But, If new terminations/cards are added...apart =
from=20
  pre-provisioning shouldn't there be a way so that the GW can scale =
using the=20
  protocol interface. rather than through proprietary =
means...


  
Even now when the serviceChange when generated with =
"restart",=20
  it is assumed that the terminations are pre-provisioned at the MGC. =
Then, How=20
  does the MGs scale dynamically. Of course scaling down is not a =
problem...as=20
  the group of terminations are already known to both =
entities.


  
Regards 
Madhubabu =


  
-----Original Message----- 
From: Tom=20
  Taylor [mailto:taylor@nortelnetworks.co=
m]=20
  
Sent: Monday, February 23, 2004 10:50 AM =

To: Madhubabu Brahmanapally 
Cc:=20
  megaco@ietf.org 
Subject: Re: [Megaco] Are =
Megaco=20
  subscribers immobile?? 


  
I would think this contrary to the spirit of Megaco, =
in that=20
  the awareness of 
services resides in the MGC =
alone and=20
  is not reflected in the protocol. 

  
Madhubabu Brahmanapally wrote: 

  
> Hi All, 
> The =
present Protocol=20
  spec doesn't address the issue of mobility of users 
> connected to the residential gateways. Are there any =
proposals for=20
  
> registration of endpoints when they =
change their=20
  physical location (Yet 
> retaining their =
domain=20
  name,etc).  Similar to the REGISTER message in SIP. =

>  
> Regards =

> Madhubabu 


------_=_NextPart_001_01C3FA4C.21349DDE--

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



From megaco-admin@ietf.org  Mon Feb 23 15:38:30 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18718
	for ; Mon, 23 Feb 2004 15:38:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvMq2-0008Ng-Jf; Mon, 23 Feb 2004 15:38:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvMpa-0008HJ-4S
	for megaco@optimus.ietf.org; Mon, 23 Feb 2004 15:37:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18637
	for ; Mon, 23 Feb 2004 15:37:31 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvMpY-0001Qt-00
	for megaco@ietf.org; Mon, 23 Feb 2004 15:37:32 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvMoa-0001Kk-00
	for megaco@ietf.org; Mon, 23 Feb 2004 15:36:33 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvMnb-0001C8-00
	for megaco@ietf.org; Mon, 23 Feb 2004 15:35:31 -0500
Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1NKYwZ01890;
	Mon, 23 Feb 2004 15:34:58 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id FKLHB996; Mon, 23 Feb 2004 15:34:58 -0500
Received: from nortelnetworks.com (acart1hf.ca.nortel.com [47.129.129.223]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DBDZJKJ2; Mon, 23 Feb 2004 15:34:58 -0500
Message-ID: <403A63F1.90201@nortelnetworks.com>
Date: Mon, 23 Feb 2004 15:34:57 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Madhubabu Brahmanapally 
CC: megaco@ietf.org
Subject: Re: [Megaco] Are Megaco subscribers immobile??
References: <9E388C880C1ED411AFE1009027E787250526F146@mail.veraznet.com>
In-Reply-To: <9E388C880C1ED411AFE1009027E787250526F146@mail.veraznet.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit

The key point is that only the MGC is aware of the telephone number associated 
with a particular termination.  The telephone number and what it implies in terms 
of services are outside the scope of Megaco, which deals only with media 
processing, events, and signals.  You can indicate through ServiceChange that 
physical terminations have been added to the MG, but you need some other protocol 
(e.g. SNMP) to indicate (either directly from the telephone set or on behalf of 
the set) information not related to media.

Madhubabu Brahmanapally wrote:

> Hi Tom,
> Thanks for the reply.
> 
> If the protocol doesn't provide any mechanism...everything boils down to 
> provisioning which defeats the purpose of mobility...Of course the 
> protocol is not addressing the mobility issue..
> 
> But, If new terminations/cards are added...apart from pre-provisioning 
> shouldn't there be a way so that the GW can scale using the protocol 
> interface. rather than through proprietary means...
> 
> 
> Even now when the serviceChange when generated with "restart", it is 
> assumed that the terminations are pre-provisioned at the MGC. Then, How 
> does the MGs scale dynamically. Of course scaling down is not a 
> problem...as the group of terminations are already known to both entities.
> 
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: Tom Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Monday, February 23, 2004 10:50 AM
> To: Madhubabu Brahmanapally
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Are Megaco subscribers immobile??
> 
> 
> I would think this contrary to the spirit of Megaco, in that the 
> awareness of
> services resides in the MGC alone and is not reflected in the protocol.
> 
> Madhubabu Brahmanapally wrote:
> 
>  > Hi All,
>  > The present Protocol spec doesn't address the issue of mobility of users
>  > connected to the residential gateways. Are there any proposals for
>  > registration of endpoints when they change their physical location (Yet
>  > retaining their domain name,etc).  Similar to the REGISTER message in 
> SIP.
>  > 
>  > Regards
>  > Madhubabu
> 

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


From exim@www1.ietf.org  Mon Feb 23 15:39:56 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18853
	for ; Mon, 23 Feb 2004 15:39:56 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvMrQ-00008T-A6
	for megaco-archive@odin.ietf.org; Mon, 23 Feb 2004 15:39:28 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NKdSfG000515
	for megaco-archive@odin.ietf.org; Mon, 23 Feb 2004 15:39:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvMrQ-00008E-6A
	for megaco-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 15:39:28 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18788
	for ; Mon, 23 Feb 2004 15:39:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvMrO-0001d6-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 15:39:26 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvMqb-0001Xo-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 15:38:38 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvMq2-0001TL-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 15:38:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvMq2-0008Ng-Jf; Mon, 23 Feb 2004 15:38:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvMpa-0008HJ-4S
	for megaco@optimus.ietf.org; Mon, 23 Feb 2004 15:37:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18637
	for ; Mon, 23 Feb 2004 15:37:31 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvMpY-0001Qt-00
	for megaco@ietf.org; Mon, 23 Feb 2004 15:37:32 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvMoa-0001Kk-00
	for megaco@ietf.org; Mon, 23 Feb 2004 15:36:33 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvMnb-0001C8-00
	for megaco@ietf.org; Mon, 23 Feb 2004 15:35:31 -0500
Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1NKYwZ01890;
	Mon, 23 Feb 2004 15:34:58 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id FKLHB996; Mon, 23 Feb 2004 15:34:58 -0500
Received: from nortelnetworks.com (acart1hf.ca.nortel.com [47.129.129.223]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DBDZJKJ2; Mon, 23 Feb 2004 15:34:58 -0500
Message-ID: <403A63F1.90201@nortelnetworks.com>
Date: Mon, 23 Feb 2004 15:34:57 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Madhubabu Brahmanapally 
CC: megaco@ietf.org
Subject: Re: [Megaco] Are Megaco subscribers immobile??
References: <9E388C880C1ED411AFE1009027E787250526F146@mail.veraznet.com>
In-Reply-To: <9E388C880C1ED411AFE1009027E787250526F146@mail.veraznet.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: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

The key point is that only the MGC is aware of the telephone number associated 
with a particular termination.  The telephone number and what it implies in terms 
of services are outside the scope of Megaco, which deals only with media 
processing, events, and signals.  You can indicate through ServiceChange that 
physical terminations have been added to the MG, but you need some other protocol 
(e.g. SNMP) to indicate (either directly from the telephone set or on behalf of 
the set) information not related to media.

Madhubabu Brahmanapally wrote:

> Hi Tom,
> Thanks for the reply.
> 
> If the protocol doesn't provide any mechanism...everything boils down to 
> provisioning which defeats the purpose of mobility...Of course the 
> protocol is not addressing the mobility issue..
> 
> But, If new terminations/cards are added...apart from pre-provisioning 
> shouldn't there be a way so that the GW can scale using the protocol 
> interface. rather than through proprietary means...
> 
> 
> Even now when the serviceChange when generated with "restart", it is 
> assumed that the terminations are pre-provisioned at the MGC. Then, How 
> does the MGs scale dynamically. Of course scaling down is not a 
> problem...as the group of terminations are already known to both entities.
> 
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: Tom Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Monday, February 23, 2004 10:50 AM
> To: Madhubabu Brahmanapally
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Are Megaco subscribers immobile??
> 
> 
> I would think this contrary to the spirit of Megaco, in that the 
> awareness of
> services resides in the MGC alone and is not reflected in the protocol.
> 
> Madhubabu Brahmanapally wrote:
> 
>  > Hi All,
>  > The present Protocol spec doesn't address the issue of mobility of users
>  > connected to the residential gateways. Are there any proposals for
>  > registration of endpoints when they change their physical location (Yet
>  > retaining their domain name,etc).  Similar to the REGISTER message in 
> SIP.
>  > 
>  > Regards
>  > Madhubabu
> 

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



From megaco-admin@ietf.org  Mon Feb 23 17:18:33 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27017
	for ; Mon, 23 Feb 2004 17:18:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvOOp-000770-9i; Mon, 23 Feb 2004 17:18:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvOOF-00072c-8C
	for megaco@optimus.ietf.org; Mon, 23 Feb 2004 17:17:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26880
	for ; Mon, 23 Feb 2004 17:17:23 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvOOD-0003YT-00
	for megaco@ietf.org; Mon, 23 Feb 2004 17:17:25 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvOMY-0003BS-00
	for megaco@ietf.org; Mon, 23 Feb 2004 17:15:45 -0500
Received: from [198.87.49.137] (helo=mx2.veraznet.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvOJw-0002cM-00
	for megaco@ietf.org; Mon, 23 Feb 2004 17:13:00 -0500
Received: from sapphire.veraznet.com ([198.87.49.5]) by mx2.veraznet.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 23 Feb 2004 14:12:26 -0800
Received: by mail.veraznet.com with Internet Mail Service (5.5.2656.59)
	id <192SRLAC>; Mon, 23 Feb 2004 14:14:42 -0800
Message-ID: <9E388C880C1ED411AFE1009027E787250526F147@mail.veraznet.com>
From: Madhubabu Brahmanapally 
To: "'shashi.kumar@wipro.com'" ,
        taylor@nortelnetworks.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Are Megaco subscribers immobile??
Date: Mon, 23 Feb 2004 14:14:41 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3FA5A.6F3C0170"
X-OriginalArrivalTime: 23 Feb 2004 22:12:26.0663 (UTC) FILETIME=[1EC36B70:01C3FA5A]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY autolearn=no 
	version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
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_01C3FA5A.6F3C0170
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Shashi,
ServiceChange can be sent from MG to those terminations that MGC is already
in aware of (and not for those which were never provisioned at the MGC).
Tom's reply seems more logical as the protocol only deals with the
Mediaprocessing, events and signals. Its not within the scope of the
protocol.
 
Regards
Madhubabu

-----Original Message-----
From: shashi.kumar@wipro.com [mailto:shashi.kumar@wipro.com]
Sent: Monday, February 23, 2004 12:32 PM
To: Madhubabu Brahmanapally; taylor@nortelnetworks.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Are Megaco subscribers immobile??


Madhubabu,
 
  Protocol might not directly address the dynamic scaling of MG's, but it is
always possible that, service change with restart could be initiated, when
MGC is made aware of the fact that, we are adding the new terminations and
then trigger a service change with restart. This would indirectly amount to
dynamic scaling of MG's with out any proprietary means.
 
Thanks,
Shashi

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
Madhubabu Brahmanapally
Sent: Tuesday, February 24, 2004 1:45 AM
To: 'Tom Taylor'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Are Megaco subscribers immobile??



Hi Tom, 
Thanks for the reply. 

If the protocol doesn't provide any mechanism...everything boils down to
provisioning which defeats the purpose of mobility...Of course the protocol
is not addressing the mobility issue..

But, If new terminations/cards are added...apart from pre-provisioning
shouldn't there be a way so that the GW can scale using the protocol
interface. rather than through proprietary means...


Even now when the serviceChange when generated with "restart", it is assumed
that the terminations are pre-provisioned at the MGC. Then, How does the MGs
scale dynamically. Of course scaling down is not a problem...as the group of
terminations are already known to both entities.


Regards 
Madhubabu 

-----Original Message----- 
From: Tom Taylor [ mailto:taylor@nortelnetworks.com
 ] 
Sent: Monday, February 23, 2004 10:50 AM 
To: Madhubabu Brahmanapally 
Cc: megaco@ietf.org 
Subject: Re: [Megaco] Are Megaco subscribers immobile?? 


I would think this contrary to the spirit of Megaco, in that the awareness
of 
services resides in the MGC alone and is not reflected in the protocol. 

Madhubabu Brahmanapally wrote: 

> Hi All, 
> The present Protocol spec doesn't address the issue of mobility of users 
> connected to the residential gateways. Are there any proposals for 
> registration of endpoints when they change their physical location (Yet 
> retaining their domain name,etc).  Similar to the REGISTER message in SIP.

>  
> Regards 
> Madhubabu 


Confidentiality Notice





The information contained in this electronic message and any attachments to
this message are intended

for the exclusive use of the addressee(s) and may contain confidential or
privileged information. If

you are not the intended recipient, please notify the sender at Wipro or
Mailadmin@wipro.com immediately

and destroy all copies of this message and any attachments.




------_=_NextPart_001_01C3FA5A.6F3C0170
Content-Type: text/html;
	charset="iso-8859-1"




RE: [Megaco] Are Megaco subscribers immobile??




Hi 
Shashi,


ServiceChange can be sent from MG to those terminations that MGC is 
already in aware of (and not for those which were never provisioned at the MGC). 
Tom's reply seems more logical as the protocol only deals with the 
Mediaprocessing, events and signals. Its not within the scope of the 
protocol.


 


Regards


Madhubabu



  
-----Original Message-----
From: shashi.kumar@wipro.com 
  [mailto:shashi.kumar@wipro.com]
Sent: Monday, February 23, 2004 
  12:32 PM
To: Madhubabu Brahmanapally; 
  taylor@nortelnetworks.com
Cc: megaco@ietf.org
Subject: RE: 
  [Megaco] Are Megaco subscribers immobile??


  

  
Madhubabu,

  
 

  
  Protocol might not directly address the dynamic scaling of MG's, 
  but it is always possible that, service change with restart could be 
  initiated, when MGC is made aware of the fact that, we are adding the new 
  terminations and then trigger a service change with restart. This would 
  indirectly amount to dynamic scaling of MG's with out any proprietary 
  means.

  
 

  
Thanks,

  
Shashi

  

    
-----Original Message-----
From: megaco-admin@ietf.org 
    [mailto:megaco-admin@ietf.org]On Behalf Of Madhubabu 
    Brahmanapally
Sent: Tuesday, February 24, 2004 1:45 
    AM
To: 'Tom Taylor'
Cc: 
    megaco@ietf.org
Subject: RE: [Megaco] Are Megaco subscribers 
    immobile??


    
Hi Tom, 
Thanks for the reply. 
    

    
If the protocol doesn't provide any mechanism...everything 
    boils down to provisioning which defeats the purpose of mobility...Of course 
    the protocol is not addressing the mobility issue..

    
But, If new terminations/cards are added...apart from 
    pre-provisioning shouldn't there be a way so that the GW can scale using the 
    protocol interface. rather than through proprietary means...


    
Even now when the serviceChange when generated with 
    "restart", it is assumed that the terminations are pre-provisioned at the 
    MGC. Then, How does the MGs scale dynamically. Of course scaling down is not 
    a problem...as the group of terminations are already known to both 
    entities.


    
Regards 
Madhubabu 

    
-----Original Message----- 
From: Tom 
    Taylor [mailto:taylor@nortelnetworks.com] 
    
Sent: Monday, February 23, 2004 10:50 AM 
To: Madhubabu Brahmanapally 
Cc: 
    megaco@ietf.org 
Subject: Re: [Megaco] Are Megaco 
    subscribers immobile?? 


    
I would think this contrary to the spirit of Megaco, in that 
    the awareness of 
services resides in the MGC alone 
    and is not reflected in the protocol. 

    
Madhubabu Brahmanapally wrote: 

    
> Hi All, 
> The present 
    Protocol spec doesn't address the issue of mobility of users 
    
> connected to the residential gateways. Are 
    there any proposals for 
> registration of 
    endpoints when they change their physical location (Yet 
> retaining their domain name,etc).  Similar to the REGISTER 
    message in SIP. 
>  
> Regards 
> Madhubabu 
  

  

    
    

      
Confidentiality Notice


The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.



------_=_NextPart_001_01C3FA5A.6F3C0170--

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


From exim@www1.ietf.org  Mon Feb 23 17:21:00 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27168
	for ; Mon, 23 Feb 2004 17:21:00 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvORB-0007We-AG
	for megaco-archive@odin.ietf.org; Mon, 23 Feb 2004 17:20:34 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NMKTK6028928
	for megaco-archive@odin.ietf.org; Mon, 23 Feb 2004 17:20:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvORB-0007WV-3F
	for megaco-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 17:20:29 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27134
	for ; Mon, 23 Feb 2004 17:20:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvOR8-0003xU-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 17:20:26 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvOPW-0003nd-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 17:18:48 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvOOr-0003ej-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 17:18:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvOOp-000770-9i; Mon, 23 Feb 2004 17:18:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvOOF-00072c-8C
	for megaco@optimus.ietf.org; Mon, 23 Feb 2004 17:17:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26880
	for ; Mon, 23 Feb 2004 17:17:23 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvOOD-0003YT-00
	for megaco@ietf.org; Mon, 23 Feb 2004 17:17:25 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvOMY-0003BS-00
	for megaco@ietf.org; Mon, 23 Feb 2004 17:15:45 -0500
Received: from [198.87.49.137] (helo=mx2.veraznet.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvOJw-0002cM-00
	for megaco@ietf.org; Mon, 23 Feb 2004 17:13:00 -0500
Received: from sapphire.veraznet.com ([198.87.49.5]) by mx2.veraznet.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 23 Feb 2004 14:12:26 -0800
Received: by mail.veraznet.com with Internet Mail Service (5.5.2656.59)
	id <192SRLAC>; Mon, 23 Feb 2004 14:14:42 -0800
Message-ID: <9E388C880C1ED411AFE1009027E787250526F147@mail.veraznet.com>
From: Madhubabu Brahmanapally 
To: "'shashi.kumar@wipro.com'" ,
        taylor@nortelnetworks.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Are Megaco subscribers immobile??
Date: Mon, 23 Feb 2004 14:14:41 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3FA5A.6F3C0170"
X-OriginalArrivalTime: 23 Feb 2004 22:12:26.0663 (UTC) FILETIME=[1EC36B70:01C3FA5A]
Sender: megaco-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: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY autolearn=no 
	version=2.60

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

------_=_NextPart_001_01C3FA5A.6F3C0170
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Shashi,
ServiceChange can be sent from MG to those terminations that MGC is already
in aware of (and not for those which were never provisioned at the MGC).
Tom's reply seems more logical as the protocol only deals with the
Mediaprocessing, events and signals. Its not within the scope of the
protocol.
 
Regards
Madhubabu

-----Original Message-----
From: shashi.kumar@wipro.com [mailto:shashi.kumar@wipro.com]
Sent: Monday, February 23, 2004 12:32 PM
To: Madhubabu Brahmanapally; taylor@nortelnetworks.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Are Megaco subscribers immobile??


Madhubabu,
 
  Protocol might not directly address the dynamic scaling of MG's, but it is
always possible that, service change with restart could be initiated, when
MGC is made aware of the fact that, we are adding the new terminations and
then trigger a service change with restart. This would indirectly amount to
dynamic scaling of MG's with out any proprietary means.
 
Thanks,
Shashi

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
Madhubabu Brahmanapally
Sent: Tuesday, February 24, 2004 1:45 AM
To: 'Tom Taylor'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Are Megaco subscribers immobile??



Hi Tom, 
Thanks for the reply. 

If the protocol doesn't provide any mechanism...everything boils down to
provisioning which defeats the purpose of mobility...Of course the protocol
is not addressing the mobility issue..

But, If new terminations/cards are added...apart from pre-provisioning
shouldn't there be a way so that the GW can scale using the protocol
interface. rather than through proprietary means...


Even now when the serviceChange when generated with "restart", it is assumed
that the terminations are pre-provisioned at the MGC. Then, How does the MGs
scale dynamically. Of course scaling down is not a problem...as the group of
terminations are already known to both entities.


Regards 
Madhubabu 

-----Original Message----- 
From: Tom Taylor [ mailto:taylor@nortelnetworks.com
 ] 
Sent: Monday, February 23, 2004 10:50 AM 
To: Madhubabu Brahmanapally 
Cc: megaco@ietf.org 
Subject: Re: [Megaco] Are Megaco subscribers immobile?? 


I would think this contrary to the spirit of Megaco, in that the awareness
of 
services resides in the MGC alone and is not reflected in the protocol. 

Madhubabu Brahmanapally wrote: 

> Hi All, 
> The present Protocol spec doesn't address the issue of mobility of users 
> connected to the residential gateways. Are there any proposals for 
> registration of endpoints when they change their physical location (Yet 
> retaining their domain name,etc).  Similar to the REGISTER message in SIP.

>  
> Regards 
> Madhubabu 


Confidentiality Notice





The information contained in this electronic message and any attachments to
this message are intended

for the exclusive use of the addressee(s) and may contain confidential or
privileged information. If

you are not the intended recipient, please notify the sender at Wipro or
Mailadmin@wipro.com immediately

and destroy all copies of this message and any attachments.




------_=_NextPart_001_01C3FA5A.6F3C0170
Content-Type: text/html;
	charset="iso-8859-1"




RE: [Megaco] Are Megaco subscribers immobile??




Hi 
Shashi,


ServiceChange can be sent from MG to those terminations that MGC is 
already in aware of (and not for those which were never provisioned at the MGC). 
Tom's reply seems more logical as the protocol only deals with the 
Mediaprocessing, events and signals. Its not within the scope of the 
protocol.


 


Regards


Madhubabu



  
-----Original Message-----
From: shashi.kumar@wipro.com 
  [mailto:shashi.kumar@wipro.com]
Sent: Monday, February 23, 2004 
  12:32 PM
To: Madhubabu Brahmanapally; 
  taylor@nortelnetworks.com
Cc: megaco@ietf.org
Subject: RE: 
  [Megaco] Are Megaco subscribers immobile??


  

  
Madhubabu,

  
 

  
  Protocol might not directly address the dynamic scaling of MG's, 
  but it is always possible that, service change with restart could be 
  initiated, when MGC is made aware of the fact that, we are adding the new 
  terminations and then trigger a service change with restart. This would 
  indirectly amount to dynamic scaling of MG's with out any proprietary 
  means.

  
 

  
Thanks,

  
Shashi

  

    
-----Original Message-----
From: megaco-admin@ietf.org 
    [mailto:megaco-admin@ietf.org]On Behalf Of Madhubabu 
    Brahmanapally
Sent: Tuesday, February 24, 2004 1:45 
    AM
To: 'Tom Taylor'
Cc: 
    megaco@ietf.org
Subject: RE: [Megaco] Are Megaco subscribers 
    immobile??


    
Hi Tom, 
Thanks for the reply. 
    

    
If the protocol doesn't provide any mechanism...everything 
    boils down to provisioning which defeats the purpose of mobility...Of course 
    the protocol is not addressing the mobility issue..

    
But, If new terminations/cards are added...apart from 
    pre-provisioning shouldn't there be a way so that the GW can scale using the 
    protocol interface. rather than through proprietary means...


    
Even now when the serviceChange when generated with 
    "restart", it is assumed that the terminations are pre-provisioned at the 
    MGC. Then, How does the MGs scale dynamically. Of course scaling down is not 
    a problem...as the group of terminations are already known to both 
    entities.


    
Regards 
Madhubabu 

    
-----Original Message----- 
From: Tom 
    Taylor [mailto:taylor@nortelnetworks.com] 
    
Sent: Monday, February 23, 2004 10:50 AM 
To: Madhubabu Brahmanapally 
Cc: 
    megaco@ietf.org 
Subject: Re: [Megaco] Are Megaco 
    subscribers immobile?? 


    
I would think this contrary to the spirit of Megaco, in that 
    the awareness of 
services resides in the MGC alone 
    and is not reflected in the protocol. 

    
Madhubabu Brahmanapally wrote: 

    
> Hi All, 
> The present 
    Protocol spec doesn't address the issue of mobility of users 
    
> connected to the residential gateways. Are 
    there any proposals for 
> registration of 
    endpoints when they change their physical location (Yet 
> retaining their domain name,etc).  Similar to the REGISTER 
    message in SIP. 
>  
> Regards 
> Madhubabu 
  

  

    
    

      
Confidentiality Notice


The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.



------_=_NextPart_001_01C3FA5A.6F3C0170--

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



From megaco-admin@ietf.org  Mon Feb 23 18:12:28 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00366
	for ; Mon, 23 Feb 2004 18:12:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvPF3-0007Pe-JD; Mon, 23 Feb 2004 18:12:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvPEc-0007JL-J1
	for megaco@optimus.ietf.org; Mon, 23 Feb 2004 18:11:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00205
	for ; Mon, 23 Feb 2004 18:11:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvPEZ-0000cu-00
	for megaco@ietf.org; Mon, 23 Feb 2004 18:11:31 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvPDZ-0000WN-00
	for megaco@ietf.org; Mon, 23 Feb 2004 18:10:30 -0500
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvPCi-0000Sa-00
	for megaco@ietf.org; Mon, 23 Feb 2004 18:09:36 -0500
Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1NN9ZqY004695
	for ; Tue, 24 Feb 2004 00:09:35 +0100 (MET)
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Tue, 24 Feb 2004 00:09:35 +0100
Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id FMFLTM47; Tue, 24 Feb 2004 00:09:44 +0100
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.156]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id FHQ5G645; Tue, 24 Feb 2004 10:08:56 +1100
Message-ID: <403A8743.6000402@ericsson.com>
Date: Tue, 24 Feb 2004 10:05:39 +1100
X-Sybari-Trust: adb8de05 c77f3eb6 53bd8675 00000138
From: Christian Groves 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Zhao Bo 
CC: megaco@ietf.org
Subject: Re: [Megaco] Questions about H.248.17 "line test packages"(upgrade,sorry,
 my poor English)
References: <000b01c3f9ee$ea987ae0$f8486e0a@HUAWEI.COM>
In-Reply-To: <000b01c3f9ee$ea987ae0$f8486e0a@HUAWEI.COM>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Feb 2004 23:09:35.0803 (UTC) FILETIME=[1AB0A8B0:01C3FA62]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit

Hello Zhao,

I'm the editor of H.248.17. Please see my replies below marked [CHG].

Regards, Christian

Zhao Bo wrote:

> Could anyone kindly answer the following questions (I can't find the author's email address in H.248.17 text).
> 
> 1. Section 1 "Scope" says:
> "The detailing of results that are reported (e.g. events and statistics), as well as the timing and mechanisms used for
> transmitting such records from the MG to the MGC"
> Why? If a test is initiated by MGC, why not define a protocol to send the measuring result back to MGC?

[CHG] As the results are related to the physical characteristics of the bearer 
and not usually interesting to a MGC it was seen that a protocol other than 
H.248 (or even internal O&M of the MG) was more suitable for this information.

> 
> 2.If we have two switch connected with temination T1 and T2
>     SW1--T1-------T2--SW2
> Shall the H.248 signal be apllied to T1 and T2, or some extra termination, for example T3 or T4 in the following scenerio:
> T3--SW1--T1-------T2--SW2--T4

[CHG] Depends on what you want to test. If all you want to test is the link 
between T1 and T2 then you only apply signals between T1 & T2.

> 
> 3. Section 7.1.1 says:
> "ITU-T Rec. O.11 describes test responder behaviour. For a description of this behaviour see
> clause 9."
> But neither O.11 nor H.247.17 text has a clause 9?

[CHG] Please see the latest implementors guide for the correction.

> 
> Best regards
> 
> Zhao Bo
> 
> 
> Zhao Bo
> 
> *****************************************************************
> This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
> *****************************************************************
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 


This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.


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


From exim@www1.ietf.org  Mon Feb 23 18:14:07 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00700
	for ; Mon, 23 Feb 2004 18:14:07 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvPGf-0007sj-Cx
	for megaco-archive@odin.ietf.org; Mon, 23 Feb 2004 18:13:41 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NNDf2q030289
	for megaco-archive@odin.ietf.org; Mon, 23 Feb 2004 18:13:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvPGf-0007sS-8z
	for megaco-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 18:13:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00622
	for ; Mon, 23 Feb 2004 18:13:36 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvPGc-0000uL-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 18:13:38 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvPFl-0000no-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 18:12:46 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvPF2-0000gZ-00
	for megaco-web-archive@ietf.org; Mon, 23 Feb 2004 18:12:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvPF3-0007Pe-JD; Mon, 23 Feb 2004 18:12:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvPEc-0007JL-J1
	for megaco@optimus.ietf.org; Mon, 23 Feb 2004 18:11:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00205
	for ; Mon, 23 Feb 2004 18:11:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvPEZ-0000cu-00
	for megaco@ietf.org; Mon, 23 Feb 2004 18:11:31 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvPDZ-0000WN-00
	for megaco@ietf.org; Mon, 23 Feb 2004 18:10:30 -0500
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvPCi-0000Sa-00
	for megaco@ietf.org; Mon, 23 Feb 2004 18:09:36 -0500
Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1NN9ZqY004695
	for ; Tue, 24 Feb 2004 00:09:35 +0100 (MET)
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Tue, 24 Feb 2004 00:09:35 +0100
Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id FMFLTM47; Tue, 24 Feb 2004 00:09:44 +0100
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.156]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id FHQ5G645; Tue, 24 Feb 2004 10:08:56 +1100
Message-ID: <403A8743.6000402@ericsson.com>
Date: Tue, 24 Feb 2004 10:05:39 +1100
X-Sybari-Trust: adb8de05 c77f3eb6 53bd8675 00000138
From: Christian Groves 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Zhao Bo 
CC: megaco@ietf.org
Subject: Re: [Megaco] Questions about H.248.17 "line test packages"(upgrade,sorry,
 my poor English)
References: <000b01c3f9ee$ea987ae0$f8486e0a@HUAWEI.COM>
In-Reply-To: <000b01c3f9ee$ea987ae0$f8486e0a@HUAWEI.COM>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Feb 2004 23:09:35.0803 (UTC) FILETIME=[1AB0A8B0:01C3FA62]
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: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello Zhao,

I'm the editor of H.248.17. Please see my replies below marked [CHG].

Regards, Christian

Zhao Bo wrote:

> Could anyone kindly answer the following questions (I can't find the author's email address in H.248.17 text).
> 
> 1. Section 1 "Scope" says:
> "The detailing of results that are reported (e.g. events and statistics), as well as the timing and mechanisms used for
> transmitting such records from the MG to the MGC"
> Why? If a test is initiated by MGC, why not define a protocol to send the measuring result back to MGC?

[CHG] As the results are related to the physical characteristics of the bearer 
and not usually interesting to a MGC it was seen that a protocol other than 
H.248 (or even internal O&M of the MG) was more suitable for this information.

> 
> 2.If we have two switch connected with temination T1 and T2
>     SW1--T1-------T2--SW2
> Shall the H.248 signal be apllied to T1 and T2, or some extra termination, for example T3 or T4 in the following scenerio:
> T3--SW1--T1-------T2--SW2--T4

[CHG] Depends on what you want to test. If all you want to test is the link 
between T1 and T2 then you only apply signals between T1 & T2.

> 
> 3. Section 7.1.1 says:
> "ITU-T Rec. O.11 describes test responder behaviour. For a description of this behaviour see
> clause 9."
> But neither O.11 nor H.247.17 text has a clause 9?

[CHG] Please see the latest implementors guide for the correction.

> 
> Best regards
> 
> Zhao Bo
> 
> 
> Zhao Bo
> 
> *****************************************************************
> This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
> *****************************************************************
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 


This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.


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



From megaco-admin@ietf.org  Wed Feb 25 02:14:32 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14892
	for ; Wed, 25 Feb 2004 02:14:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvtF3-0007vg-Pn; Wed, 25 Feb 2004 02:14:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvtEz-0007uG-94
	for megaco@optimus.ietf.org; Wed, 25 Feb 2004 02:13:57 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14818
	for ; Wed, 25 Feb 2004 02:13:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvtEv-0007RP-00
	for megaco@ietf.org; Wed, 25 Feb 2004 02:13:53 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvtE3-0007JD-00
	for megaco@ietf.org; Wed, 25 Feb 2004 02:13:00 -0500
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvtDI-00076i-00
	for megaco@ietf.org; Wed, 25 Feb 2004 02:12:13 -0500
Received: from z14593 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HTM001NAP7LT4@mta0.huawei.com> for megaco@ietf.org;
 Wed, 25 Feb 2004 15:09:22 +0800 (CST)
Date: Wed, 25 Feb 2004 15:11:00 +0800
From: Zhao Bo 
To: megaco@ietf.org
Message-id: <000701c3fb6e$8665d1e0$f8486e0a@HUAWEI.COM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
Content-type: text/plain; charset=Windows-1252
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7BIT
Subject: [Megaco] Hairpin case A/u Law conversion
Sender: megaco-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

In this case, the A/u law format of a TDM ciruit can be provisioned,  but the MG doesn't know the service type of a call, thus 
has no way to know if a conversion is needed. For speech service conversion may be needed; for data service like isdn UDI, conversion is not permitted.
Is there any method to solve this problem?

Zhao Bo

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

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


From exim@www1.ietf.org  Wed Feb 25 02:33:43 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00679
	for ; Wed, 25 Feb 2004 02:33:43 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvtXY-0004Fd-Qg
	for megaco-archive@odin.ietf.org; Wed, 25 Feb 2004 02:33:16 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P7X8Nx016325
	for megaco-archive@odin.ietf.org; Wed, 25 Feb 2004 02:33:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvtXY-0004F7-16
	for megaco-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 02:33:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00503
	for ; Wed, 25 Feb 2004 02:33:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvtXT-0001mr-00
	for megaco-web-archive@ietf.org; Wed, 25 Feb 2004 02:33:03 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvtW8-0001Ua-00
	for megaco-web-archive@ietf.org; Wed, 25 Feb 2004 02:31:41 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvtUM-00014z-00
	for megaco-web-archive@ietf.org; Wed, 25 Feb 2004 02:29:50 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1AvtF7-0003zi-HD
	for megaco-web-archive@ietf.org; Wed, 25 Feb 2004 02:14:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvtF3-0007vg-Pn; Wed, 25 Feb 2004 02:14:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AvtEz-0007uG-94
	for megaco@optimus.ietf.org; Wed, 25 Feb 2004 02:13:57 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14818
	for ; Wed, 25 Feb 2004 02:13:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvtEv-0007RP-00
	for megaco@ietf.org; Wed, 25 Feb 2004 02:13:53 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AvtE3-0007JD-00
	for megaco@ietf.org; Wed, 25 Feb 2004 02:13:00 -0500
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvtDI-00076i-00
	for megaco@ietf.org; Wed, 25 Feb 2004 02:12:13 -0500
Received: from z14593 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HTM001NAP7LT4@mta0.huawei.com> for megaco@ietf.org;
 Wed, 25 Feb 2004 15:09:22 +0800 (CST)
Date: Wed, 25 Feb 2004 15:11:00 +0800
From: Zhao Bo 
To: megaco@ietf.org
Message-id: <000701c3fb6e$8665d1e0$f8486e0a@HUAWEI.COM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
Content-type: text/plain; charset=Windows-1252
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7BIT
Subject: [Megaco] Hairpin case A/u Law conversion
Sender: megaco-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: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

In this case, the A/u law format of a TDM ciruit can be provisioned,  but the MG doesn't know the service type of a call, thus 
has no way to know if a conversion is needed. For speech service conversion may be needed; for data service like isdn UDI, conversion is not permitted.
Is there any method to solve this problem?

Zhao Bo

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

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



From megaco-admin@ietf.org  Wed Feb 25 09:27:30 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17721
	for ; Wed, 25 Feb 2004 09:27:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aw005-0004eV-EE; Wed, 25 Feb 2004 09:27:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Avzzz-0004e6-OT
	for megaco@optimus.ietf.org; Wed, 25 Feb 2004 09:26:55 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17715
	for ; Wed, 25 Feb 2004 09:26:52 -0500 (EST)
From: Albrecht.Schwarz@alcatel.de
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Avzzx-000503-00
	for megaco@ietf.org; Wed, 25 Feb 2004 09:26:53 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Avzz0-0004vK-00
	for megaco@ietf.org; Wed, 25 Feb 2004 09:25:55 -0500
Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvzyV-0004pd-00; Wed, 25 Feb 2004 09:25:23 -0500
Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205])
	by mailrelay2.alcatel.de (8.12.10/8.12.10) with ESMTP id i1PEOeol021276;
	Wed, 25 Feb 2004 14:24:40 GMT
Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion
To: Zhao Bo 
Cc: megaco@ietf.org, megaco-admin@ietf.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
Date: Wed, 25 Feb 2004 15:24:39 +0100
X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 02/25/2004 15:24:39
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
X-Alcanet-virus-scanned: i1PEOeol021276 at mailrelay2.alcatel.de
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no 
	version=2.60
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: quoted-printable


Dear Zhao Bo,

because there isn't any "hairpinning" definition in MEGACOP/H.248 stand=
ards
("please correct if I'm wrong"), I'd like to use the following one for
responding your questions:

***********************************************************************=
************
Definition:
TDM Hairpinning
? is a scenario whereby a call is being made between two TDM endpoints =
on a
    single media gateway. The media comes in on one TDM channel and goe=
s
    out on another TDM channel through the use of an internal loop in t=
he
    media gateway.

Note 1: due to the fact that there are local call types at local exchan=
ges
(CLASS5), and transit exchanges (CLASS4) in legacy TDM networks (PSTN,
NISDN, etc), there is a variety of TDM-to-TDM connection types behind t=
he
general "TDM hairpinning" capability (dependent on required type of IWF=
,
etc.) in corresponding H.248 MG types

Note 2: H.248/MEGCOP perspective
TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM Terminations
***********************************************************************=
*************

Based on this hairpinning understanding, my answers are:

(1) Speech telephony service: G.711 companding formats are a property o=
f
the corresponding H.248 TDM termination

[Note: dependent on MG architecture and implementation, property might =
be
signalled or preprovisioned. Of course, G.711 companding law is an inhe=
rent
property of your DS0 channel at your PDH/SDH/SONET framer; the way, how=

this DS0 property is associated with the corresponding H.248 TDM
Termination property may only realized MG-internally for very specific =
MG
architectures. Generally it is up to the MGC, particularly if some (or =
all)
DS0's are ISDN B channels.]

(2) Voiceband Data services: same as in (1)

[Note: VBD according new ITU-T V.152 -> "... For purposes of
interoperability, a V.152 compliant implementation shall support at lea=
st
both G.711 A-law and G.711 =EC-law codecs as VBD codecs. "]

(3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer service
requirement
=3D> H.248 TDM Termination property must be signalled by MGC, if not, M=
G may
not guarantee UDI capability (i.e., fully transparent 64-kbit/s bearer
channel) in TDM hairpinning scenarios ...


Conclusion:
IF your MG is supporting
PSTN lines (=3D H.248 ALN Termination),
PSTN trunks (=3D H.248 TDM Termination), and
ISDN B channels (=3D H.248 TDM Termination)

AND IF you've such services and interworking requirements

THEN you should generally signal the corresponding properties ...

... in case of
TDM hairpinning,
ALN hairpinning, or
ALN-to-TDM connection types.

Regards,
Albrecht

ALCATEL




                                                                       =
                                                                       =
     =20
                      Zhao Bo                                          =
                                                                       =
     =20
                               To:      megaco@ietf.org=
                                                                       =
     =20
                      Sent by:                 cc:                     =
                                                                       =
     =20
                      megaco-admin@iet         Subject: [Megaco] Hairpi=
n case A/u Law conversion                                              =
     =20
                      f.org                                            =
                                                                       =
     =20
                                                                       =
                                                                       =
     =20
                                                                       =
                                                                       =
     =20
                      25.02.2004 08:11                                 =
                                                                       =
     =20
                                                                       =
                                                                       =
     =20
                                                                       =
                                                                       =
     =20




In this case, the A/u law format of a TDM ciruit can be provisioned,  b=
ut
the MG doesn't know the service type of a call, thus
has no way to know if a conversion is needed. For speech service conver=
sion
may be needed; for data service like isdn UDI, conversion is not permit=
ted.
Is there any method to solve this problem?

Zhao Bo

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

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



=



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


From exim@www1.ietf.org  Wed Feb 25 09:29:19 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17782
	for ; Wed, 25 Feb 2004 09:29:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aw01r-00050J-6L
	for megaco-archive@odin.ietf.org; Wed, 25 Feb 2004 09:28:52 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PESp44019235
	for megaco-archive@odin.ietf.org; Wed, 25 Feb 2004 09:28:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aw01r-00050A-0N
	for megaco-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 09:28:51 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17771
	for ; Wed, 25 Feb 2004 09:28:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aw01p-00059n-00
	for megaco-web-archive@ietf.org; Wed, 25 Feb 2004 09:28:49 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aw00q-00054v-00
	for megaco-web-archive@ietf.org; Wed, 25 Feb 2004 09:27:49 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aw005-00050l-00
	for megaco-web-archive@ietf.org; Wed, 25 Feb 2004 09:27:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aw005-0004eV-EE; Wed, 25 Feb 2004 09:27:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Avzzz-0004e6-OT
	for megaco@optimus.ietf.org; Wed, 25 Feb 2004 09:26:55 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17715
	for ; Wed, 25 Feb 2004 09:26:52 -0500 (EST)
From: Albrecht.Schwarz@alcatel.de
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Avzzx-000503-00
	for megaco@ietf.org; Wed, 25 Feb 2004 09:26:53 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Avzz0-0004vK-00
	for megaco@ietf.org; Wed, 25 Feb 2004 09:25:55 -0500
Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AvzyV-0004pd-00; Wed, 25 Feb 2004 09:25:23 -0500
Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205])
	by mailrelay2.alcatel.de (8.12.10/8.12.10) with ESMTP id i1PEOeol021276;
	Wed, 25 Feb 2004 14:24:40 GMT
Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion
To: Zhao Bo 
Cc: megaco@ietf.org, megaco-admin@ietf.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
Date: Wed, 25 Feb 2004 15:24:39 +0100
X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 02/25/2004 15:24:39
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
X-Alcanet-virus-scanned: i1PEOeol021276 at mailrelay2.alcatel.de
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no 
	version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable


Dear Zhao Bo,

because there isn't any "hairpinning" definition in MEGACOP/H.248 stand=
ards
("please correct if I'm wrong"), I'd like to use the following one for
responding your questions:

***********************************************************************=
************
Definition:
TDM Hairpinning
? is a scenario whereby a call is being made between two TDM endpoints =
on a
    single media gateway. The media comes in on one TDM channel and goe=
s
    out on another TDM channel through the use of an internal loop in t=
he
    media gateway.

Note 1: due to the fact that there are local call types at local exchan=
ges
(CLASS5), and transit exchanges (CLASS4) in legacy TDM networks (PSTN,
NISDN, etc), there is a variety of TDM-to-TDM connection types behind t=
he
general "TDM hairpinning" capability (dependent on required type of IWF=
,
etc.) in corresponding H.248 MG types

Note 2: H.248/MEGCOP perspective
TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM Terminations
***********************************************************************=
*************

Based on this hairpinning understanding, my answers are:

(1) Speech telephony service: G.711 companding formats are a property o=
f
the corresponding H.248 TDM termination

[Note: dependent on MG architecture and implementation, property might =
be
signalled or preprovisioned. Of course, G.711 companding law is an inhe=
rent
property of your DS0 channel at your PDH/SDH/SONET framer; the way, how=

this DS0 property is associated with the corresponding H.248 TDM
Termination property may only realized MG-internally for very specific =
MG
architectures. Generally it is up to the MGC, particularly if some (or =
all)
DS0's are ISDN B channels.]

(2) Voiceband Data services: same as in (1)

[Note: VBD according new ITU-T V.152 -> "... For purposes of
interoperability, a V.152 compliant implementation shall support at lea=
st
both G.711 A-law and G.711 =EC-law codecs as VBD codecs. "]

(3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer service
requirement
=3D> H.248 TDM Termination property must be signalled by MGC, if not, M=
G may
not guarantee UDI capability (i.e., fully transparent 64-kbit/s bearer
channel) in TDM hairpinning scenarios ...


Conclusion:
IF your MG is supporting
PSTN lines (=3D H.248 ALN Termination),
PSTN trunks (=3D H.248 TDM Termination), and
ISDN B channels (=3D H.248 TDM Termination)

AND IF you've such services and interworking requirements

THEN you should generally signal the corresponding properties ...

... in case of
TDM hairpinning,
ALN hairpinning, or
ALN-to-TDM connection types.

Regards,
Albrecht

ALCATEL




                                                                       =
                                                                       =
     =20
                      Zhao Bo                                          =
                                                                       =
     =20
                               To:      megaco@ietf.org=
                                                                       =
     =20
                      Sent by:                 cc:                     =
                                                                       =
     =20
                      megaco-admin@iet         Subject: [Megaco] Hairpi=
n case A/u Law conversion                                              =
     =20
                      f.org                                            =
                                                                       =
     =20
                                                                       =
                                                                       =
     =20
                                                                       =
                                                                       =
     =20
                      25.02.2004 08:11                                 =
                                                                       =
     =20
                                                                       =
                                                                       =
     =20
                                                                       =
                                                                       =
     =20




In this case, the A/u law format of a TDM ciruit can be provisioned,  b=
ut
the MG doesn't know the service type of a call, thus
has no way to know if a conversion is needed. For speech service conver=
sion
may be needed; for data service like isdn UDI, conversion is not permit=
ted.
Is there any method to solve this problem?

Zhao Bo

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

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



=



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



From megaco-admin@ietf.org  Thu Feb 26 03:42:37 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27836
	for ; Thu, 26 Feb 2004 03:42:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwH5p-0008M3-KE; Thu, 26 Feb 2004 03:42:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwH5I-0008Cm-Lz
	for megaco@optimus.ietf.org; Thu, 26 Feb 2004 03:41:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27745
	for ; Thu, 26 Feb 2004 03:41:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwH5F-0001HE-00
	for megaco@ietf.org; Thu, 26 Feb 2004 03:41:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwH4B-0001Bd-00
	for megaco@ietf.org; Thu, 26 Feb 2004 03:40:24 -0500
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwH3b-00012g-00
	for megaco@ietf.org; Thu, 26 Feb 2004 03:39:48 -0500
Received: from z14593 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HTO00GMXNRSE7@mta0.huawei.com> for megaco@ietf.org;
 Thu, 26 Feb 2004 16:33:29 +0800 (CST)
Date: Thu, 26 Feb 2004 16:34:53 +0800
From: Zhao Bo 
Subject: Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion
To: Albrecht.Schwarz@alcatel.de
Cc: megaco@ietf.org
Message-id: <000401c3fc43$68abbe00$f8486e0a@HUAWEI.COM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: base64
X-Priority: 3
X-MSMail-priority: Normal
References: 
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,MIME_BASE64_LATIN,
	MIME_BASE64_TEXT autolearn=no version=2.60
Content-Transfer-Encoding: base64
Sender: megaco-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: base64

RGVhciBBbGJyZWNodDoNCiAgICBJcyB0aGVyZSBhbnkgSC4yNDggcGFja2FnZSBkZWZpbmVkIHRv
IHNpZ25hbCB0aGUgVURJIHRyYW5zcGFyZW5jeSBwcm9wZXJ0aWVzIGluIFRETSBoYWlycGluZyBj
YXNlPyAgDQogICAgQmVzdCByZWdhcmRzDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g
DQpGcm9tOiA8QWxicmVjaHQuU2Nod2FyekBhbGNhdGVsLmRlPg0KVG86ICJaaGFvIEJvIiA8emJv
QGh1YXdlaS5jb20+DQpDYzogPG1lZ2Fjb0BpZXRmLm9yZz47IDxtZWdhY28tYWRtaW5AaWV0Zi5v
cmc+DQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI1LCAyMDA0IDEwOjI0IFBNDQpTdWJqZWN0
OiBURE0gSGFpcnBpbm5pbmc7IFJlOiBbTWVnYWNvXSBIYWlycGluIGNhc2UgQS91IExhdyBjb252
ZXJzaW9uDQoNCg0KDQpEZWFyIFpoYW8gQm8sDQoNCmJlY2F1c2UgdGhlcmUgaXNuJ3QgYW55ICJo
YWlycGlubmluZyIgZGVmaW5pdGlvbiBpbiBNRUdBQ09QL0guMjQ4IHN0YW5kYXJkcw0KKCJwbGVh
c2UgY29ycmVjdCBpZiBJJ20gd3JvbmciKSwgSSdkIGxpa2UgdG8gdXNlIHRoZSBmb2xsb3dpbmcg
b25lIGZvcg0KcmVzcG9uZGluZyB5b3VyIHF1ZXN0aW9uczoNCg0KKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioNCkRlZmluaXRpb246DQpURE0gSGFpcnBpbm5pbmcNCj8gaXMgYSBzY2VuYXJpbyB3
aGVyZWJ5IGEgY2FsbCBpcyBiZWluZyBtYWRlIGJldHdlZW4gdHdvIFRETSBlbmRwb2ludHMgb24g
YQ0KICAgIHNpbmdsZSBtZWRpYSBnYXRld2F5LiBUaGUgbWVkaWEgY29tZXMgaW4gb24gb25lIFRE
TSBjaGFubmVsIGFuZCBnb2VzDQogICAgb3V0IG9uIGFub3RoZXIgVERNIGNoYW5uZWwgdGhyb3Vn
aCB0aGUgdXNlIG9mIGFuIGludGVybmFsIGxvb3AgaW4gdGhlDQogICAgbWVkaWEgZ2F0ZXdheS4N
Cg0KTm90ZSAxOiBkdWUgdG8gdGhlIGZhY3QgdGhhdCB0aGVyZSBhcmUgbG9jYWwgY2FsbCB0eXBl
cyBhdCBsb2NhbCBleGNoYW5nZXMNCihDTEFTUzUpLCBhbmQgdHJhbnNpdCBleGNoYW5nZXMgKENM
QVNTNCkgaW4gbGVnYWN5IFRETSBuZXR3b3JrcyAoUFNUTiwNCk5JU0ROLCBldGMpLCB0aGVyZSBp
cyBhIHZhcmlldHkgb2YgVERNLXRvLVRETSBjb25uZWN0aW9uIHR5cGVzIGJlaGluZCB0aGUNCmdl
bmVyYWwgIlRETSBoYWlycGlubmluZyIgY2FwYWJpbGl0eSAoZGVwZW5kZW50IG9uIHJlcXVpcmVk
IHR5cGUgb2YgSVdGLA0KZXRjLikgaW4gY29ycmVzcG9uZGluZyBILjI0OCBNRyB0eXBlcw0KDQpO
b3RlIDI6IEguMjQ4L01FR0NPUCBwZXJzcGVjdGl2ZQ0KVERNIEhhaXJwaW5uaW5nID0gU2luZ2xl
IEguMjQ4IENvbnRleHQgd2l0aCAyIEguMjQ4IFRETSBUZXJtaW5hdGlvbnMNCioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKg0KDQpCYXNlZCBvbiB0aGlzIGhhaXJwaW5uaW5nIHVuZGVyc3RhbmRp
bmcsIG15IGFuc3dlcnMgYXJlOg0KDQooMSkgU3BlZWNoIHRlbGVwaG9ueSBzZXJ2aWNlOiBHLjcx
MSBjb21wYW5kaW5nIGZvcm1hdHMgYXJlIGEgcHJvcGVydHkgb2YNCnRoZSBjb3JyZXNwb25kaW5n
IEguMjQ4IFRETSB0ZXJtaW5hdGlvbg0KDQpbTm90ZTogZGVwZW5kZW50IG9uIE1HIGFyY2hpdGVj
dHVyZSBhbmQgaW1wbGVtZW50YXRpb24sIHByb3BlcnR5IG1pZ2h0IGJlDQpzaWduYWxsZWQgb3Ig
cHJlcHJvdmlzaW9uZWQuIE9mIGNvdXJzZSwgRy43MTEgY29tcGFuZGluZyBsYXcgaXMgYW4gaW5o
ZXJlbnQNCnByb3BlcnR5IG9mIHlvdXIgRFMwIGNoYW5uZWwgYXQgeW91ciBQREgvU0RIL1NPTkVU
IGZyYW1lcjsgdGhlIHdheSwgaG93DQp0aGlzIERTMCBwcm9wZXJ0eSBpcyBhc3NvY2lhdGVkIHdp
dGggdGhlIGNvcnJlc3BvbmRpbmcgSC4yNDggVERNDQpUZXJtaW5hdGlvbiBwcm9wZXJ0eSBtYXkg
b25seSByZWFsaXplZCBNRy1pbnRlcm5hbGx5IGZvciB2ZXJ5IHNwZWNpZmljIE1HDQphcmNoaXRl
Y3R1cmVzLiBHZW5lcmFsbHkgaXQgaXMgdXAgdG8gdGhlIE1HQywgcGFydGljdWxhcmx5IGlmIHNv
bWUgKG9yIGFsbCkNCkRTMCdzIGFyZSBJU0ROIEIgY2hhbm5lbHMuXQ0KDQooMikgVm9pY2ViYW5k
IERhdGEgc2VydmljZXM6IHNhbWUgYXMgaW4gKDEpDQoNCltOb3RlOiBWQkQgYWNjb3JkaW5nIG5l
dyBJVFUtVCBWLjE1MiAtPiAiLi4uIEZvciBwdXJwb3NlcyBvZg0KaW50ZXJvcGVyYWJpbGl0eSwg
YSBWLjE1MiBjb21wbGlhbnQgaW1wbGVtZW50YXRpb24gc2hhbGwgc3VwcG9ydCBhdCBsZWFzdA0K
Ym90aCBHLjcxMSBBLWxhdyBhbmQgRy43MTEg7C1sYXcgY29kZWNzIGFzIFZCRCBjb2RlY3MuICJd
DQoNCigzKSBJU0ROIFVESSA9IGFsbCBJU0ROIFRlbGVzZXJ2aWNlcyB3aXRoIElTRE4gSS4yMzEu
IGJlYXJlciBzZXJ2aWNlDQpyZXF1aXJlbWVudA0KPT4gSC4yNDggVERNIFRlcm1pbmF0aW9uIHBy
b3BlcnR5IG11c3QgYmUgc2lnbmFsbGVkIGJ5IE1HQywgaWYgbm90LCBNRyBtYXkNCm5vdCBndWFy
YW50ZWUgVURJIGNhcGFiaWxpdHkgKGkuZS4sIGZ1bGx5IHRyYW5zcGFyZW50IDY0LWtiaXQvcyBi
ZWFyZXINCmNoYW5uZWwpIGluIFRETSBoYWlycGlubmluZyBzY2VuYXJpb3MgLi4uDQoNCg0KQ29u
Y2x1c2lvbjoNCklGIHlvdXIgTUcgaXMgc3VwcG9ydGluZw0KUFNUTiBsaW5lcyAoPSBILjI0OCBB
TE4gVGVybWluYXRpb24pLA0KUFNUTiB0cnVua3MgKD0gSC4yNDggVERNIFRlcm1pbmF0aW9uKSwg
YW5kDQpJU0ROIEIgY2hhbm5lbHMgKD0gSC4yNDggVERNIFRlcm1pbmF0aW9uKQ0KDQpBTkQgSUYg
eW91J3ZlIHN1Y2ggc2VydmljZXMgYW5kIGludGVyd29ya2luZyByZXF1aXJlbWVudHMNCg0KVEhF
TiB5b3Ugc2hvdWxkIGdlbmVyYWxseSBzaWduYWwgdGhlIGNvcnJlc3BvbmRpbmcgcHJvcGVydGll
cyAuLi4NCg0KLi4uIGluIGNhc2Ugb2YNClRETSBoYWlycGlubmluZywNCkFMTiBoYWlycGlubmlu
Zywgb3INCkFMTi10by1URE0gY29ubmVjdGlvbiB0eXBlcy4NCg0KUmVnYXJkcywNCkFsYnJlY2h0
DQoNCkFMQ0FURUwNCg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K
ICAgICAgICAgICAgICAgICAgICAgIFpoYW8gQm8gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAg
IDx6Ym9AaHVhd2VpLmNvbT4gICAgICAgICBUbzogICAgICBtZWdhY29AaWV0Zi5vcmcgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIFNlbnQgYnk6ICAgICAgICAgICAg
ICAgICBjYzogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAg
ICAgICAgICAgICAgICAgIG1lZ2Fjby1hZG1pbkBpZXQgICAgICAgICBTdWJqZWN0OiBbTWVnYWNv
XSBIYWlycGluIGNhc2UgQS91IExhdyBjb252ZXJzaW9uICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIGYub3Jn
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIDI1LjAyLjIwMDQg
MDg6MTEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIA0KDQoNCg0KDQpJbiB0aGlzIGNhc2UsIHRoZSBBL3UgbGF3IGZvcm1h
dCBvZiBhIFRETSBjaXJ1aXQgY2FuIGJlIHByb3Zpc2lvbmVkLCAgYnV0DQp0aGUgTUcgZG9lc24n
dCBrbm93IHRoZSBzZXJ2aWNlIHR5cGUgb2YgYSBjYWxsLCB0aHVzDQpoYXMgbm8gd2F5IHRvIGtu
b3cgaWYgYSBjb252ZXJzaW9uIGlzIG5lZWRlZC4gRm9yIHNwZWVjaCBzZXJ2aWNlIGNvbnZlcnNp
b24NCm1heSBiZSBuZWVkZWQ7IGZvciBkYXRhIHNlcnZpY2UgbGlrZSBpc2RuIFVESSwgY29udmVy
c2lvbiBpcyBub3QgcGVybWl0dGVkLg0KSXMgdGhlcmUgYW55IG1ldGhvZCB0byBzb2x2ZSB0aGlz
IHByb2JsZW0/DQoNClpoYW8gQm8NCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0
YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbQ0KSFVBV0VJLCB3
aGljaCBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRy
ZXNzIGlzDQpsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l
ZCBoZXJlaW4gaW4gYW55IHdheQ0KKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3Rh
bCBvciBwYXJ0aWFsIGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwNCm9yIGRpc3NlbWluYXRpb24p
IGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpIGlzDQpwcm9o
aWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm
eSB0aGUgc2VuZGVyDQpieSBwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0
IQ0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCk1lZ2FjbyBtYWlsaW5nIGxpc3QNCk1lZ2Fjb0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cx
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWVnYWNvDQoNCg0KDQoNCg0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTWVnYWNvIG1haWxpbmcgbGlz
dA0KTWVnYWNvQGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9tZWdhY28NCg==


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


From exim@www1.ietf.org  Thu Feb 26 03:43:59 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27907
	for ; Thu, 26 Feb 2004 03:43:59 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwH7B-0000F5-VJ
	for megaco-archive@odin.ietf.org; Thu, 26 Feb 2004 03:43:31 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q8hT3c000926
	for megaco-archive@odin.ietf.org; Thu, 26 Feb 2004 03:43:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwH7B-0000Er-Nj
	for megaco-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 03:43:29 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27881
	for ; Thu, 26 Feb 2004 03:43:27 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwH79-0001TM-00
	for megaco-web-archive@ietf.org; Thu, 26 Feb 2004 03:43:27 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwH6H-0001Nu-00
	for megaco-web-archive@ietf.org; Thu, 26 Feb 2004 03:42:33 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwH5r-0001IT-00
	for megaco-web-archive@ietf.org; Thu, 26 Feb 2004 03:42:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwH5p-0008M3-KE; Thu, 26 Feb 2004 03:42:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwH5I-0008Cm-Lz
	for megaco@optimus.ietf.org; Thu, 26 Feb 2004 03:41:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27745
	for ; Thu, 26 Feb 2004 03:41:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwH5F-0001HE-00
	for megaco@ietf.org; Thu, 26 Feb 2004 03:41:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwH4B-0001Bd-00
	for megaco@ietf.org; Thu, 26 Feb 2004 03:40:24 -0500
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwH3b-00012g-00
	for megaco@ietf.org; Thu, 26 Feb 2004 03:39:48 -0500
Received: from z14593 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HTO00GMXNRSE7@mta0.huawei.com> for megaco@ietf.org;
 Thu, 26 Feb 2004 16:33:29 +0800 (CST)
Date: Thu, 26 Feb 2004 16:34:53 +0800
From: Zhao Bo 
Subject: Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion
To: Albrecht.Schwarz@alcatel.de
Cc: megaco@ietf.org
Message-id: <000401c3fc43$68abbe00$f8486e0a@HUAWEI.COM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: base64
X-Priority: 3
X-MSMail-priority: Normal
References: 
Content-Transfer-Encoding: base64
Sender: megaco-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: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,MIME_BASE64_LATIN,
	MIME_BASE64_TEXT autolearn=no version=2.60
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

RGVhciBBbGJyZWNodDoNCiAgICBJcyB0aGVyZSBhbnkgSC4yNDggcGFja2FnZSBkZWZpbmVkIHRv
IHNpZ25hbCB0aGUgVURJIHRyYW5zcGFyZW5jeSBwcm9wZXJ0aWVzIGluIFRETSBoYWlycGluZyBj
YXNlPyAgDQogICAgQmVzdCByZWdhcmRzDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g
DQpGcm9tOiA8QWxicmVjaHQuU2Nod2FyekBhbGNhdGVsLmRlPg0KVG86ICJaaGFvIEJvIiA8emJv
QGh1YXdlaS5jb20+DQpDYzogPG1lZ2Fjb0BpZXRmLm9yZz47IDxtZWdhY28tYWRtaW5AaWV0Zi5v
cmc+DQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI1LCAyMDA0IDEwOjI0IFBNDQpTdWJqZWN0
OiBURE0gSGFpcnBpbm5pbmc7IFJlOiBbTWVnYWNvXSBIYWlycGluIGNhc2UgQS91IExhdyBjb252
ZXJzaW9uDQoNCg0KDQpEZWFyIFpoYW8gQm8sDQoNCmJlY2F1c2UgdGhlcmUgaXNuJ3QgYW55ICJo
YWlycGlubmluZyIgZGVmaW5pdGlvbiBpbiBNRUdBQ09QL0guMjQ4IHN0YW5kYXJkcw0KKCJwbGVh
c2UgY29ycmVjdCBpZiBJJ20gd3JvbmciKSwgSSdkIGxpa2UgdG8gdXNlIHRoZSBmb2xsb3dpbmcg
b25lIGZvcg0KcmVzcG9uZGluZyB5b3VyIHF1ZXN0aW9uczoNCg0KKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioNCkRlZmluaXRpb246DQpURE0gSGFpcnBpbm5pbmcNCj8gaXMgYSBzY2VuYXJpbyB3
aGVyZWJ5IGEgY2FsbCBpcyBiZWluZyBtYWRlIGJldHdlZW4gdHdvIFRETSBlbmRwb2ludHMgb24g
YQ0KICAgIHNpbmdsZSBtZWRpYSBnYXRld2F5LiBUaGUgbWVkaWEgY29tZXMgaW4gb24gb25lIFRE
TSBjaGFubmVsIGFuZCBnb2VzDQogICAgb3V0IG9uIGFub3RoZXIgVERNIGNoYW5uZWwgdGhyb3Vn
aCB0aGUgdXNlIG9mIGFuIGludGVybmFsIGxvb3AgaW4gdGhlDQogICAgbWVkaWEgZ2F0ZXdheS4N
Cg0KTm90ZSAxOiBkdWUgdG8gdGhlIGZhY3QgdGhhdCB0aGVyZSBhcmUgbG9jYWwgY2FsbCB0eXBl
cyBhdCBsb2NhbCBleGNoYW5nZXMNCihDTEFTUzUpLCBhbmQgdHJhbnNpdCBleGNoYW5nZXMgKENM
QVNTNCkgaW4gbGVnYWN5IFRETSBuZXR3b3JrcyAoUFNUTiwNCk5JU0ROLCBldGMpLCB0aGVyZSBp
cyBhIHZhcmlldHkgb2YgVERNLXRvLVRETSBjb25uZWN0aW9uIHR5cGVzIGJlaGluZCB0aGUNCmdl
bmVyYWwgIlRETSBoYWlycGlubmluZyIgY2FwYWJpbGl0eSAoZGVwZW5kZW50IG9uIHJlcXVpcmVk
IHR5cGUgb2YgSVdGLA0KZXRjLikgaW4gY29ycmVzcG9uZGluZyBILjI0OCBNRyB0eXBlcw0KDQpO
b3RlIDI6IEguMjQ4L01FR0NPUCBwZXJzcGVjdGl2ZQ0KVERNIEhhaXJwaW5uaW5nID0gU2luZ2xl
IEguMjQ4IENvbnRleHQgd2l0aCAyIEguMjQ4IFRETSBUZXJtaW5hdGlvbnMNCioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKg0KDQpCYXNlZCBvbiB0aGlzIGhhaXJwaW5uaW5nIHVuZGVyc3RhbmRp
bmcsIG15IGFuc3dlcnMgYXJlOg0KDQooMSkgU3BlZWNoIHRlbGVwaG9ueSBzZXJ2aWNlOiBHLjcx
MSBjb21wYW5kaW5nIGZvcm1hdHMgYXJlIGEgcHJvcGVydHkgb2YNCnRoZSBjb3JyZXNwb25kaW5n
IEguMjQ4IFRETSB0ZXJtaW5hdGlvbg0KDQpbTm90ZTogZGVwZW5kZW50IG9uIE1HIGFyY2hpdGVj
dHVyZSBhbmQgaW1wbGVtZW50YXRpb24sIHByb3BlcnR5IG1pZ2h0IGJlDQpzaWduYWxsZWQgb3Ig
cHJlcHJvdmlzaW9uZWQuIE9mIGNvdXJzZSwgRy43MTEgY29tcGFuZGluZyBsYXcgaXMgYW4gaW5o
ZXJlbnQNCnByb3BlcnR5IG9mIHlvdXIgRFMwIGNoYW5uZWwgYXQgeW91ciBQREgvU0RIL1NPTkVU
IGZyYW1lcjsgdGhlIHdheSwgaG93DQp0aGlzIERTMCBwcm9wZXJ0eSBpcyBhc3NvY2lhdGVkIHdp
dGggdGhlIGNvcnJlc3BvbmRpbmcgSC4yNDggVERNDQpUZXJtaW5hdGlvbiBwcm9wZXJ0eSBtYXkg
b25seSByZWFsaXplZCBNRy1pbnRlcm5hbGx5IGZvciB2ZXJ5IHNwZWNpZmljIE1HDQphcmNoaXRl
Y3R1cmVzLiBHZW5lcmFsbHkgaXQgaXMgdXAgdG8gdGhlIE1HQywgcGFydGljdWxhcmx5IGlmIHNv
bWUgKG9yIGFsbCkNCkRTMCdzIGFyZSBJU0ROIEIgY2hhbm5lbHMuXQ0KDQooMikgVm9pY2ViYW5k
IERhdGEgc2VydmljZXM6IHNhbWUgYXMgaW4gKDEpDQoNCltOb3RlOiBWQkQgYWNjb3JkaW5nIG5l
dyBJVFUtVCBWLjE1MiAtPiAiLi4uIEZvciBwdXJwb3NlcyBvZg0KaW50ZXJvcGVyYWJpbGl0eSwg
YSBWLjE1MiBjb21wbGlhbnQgaW1wbGVtZW50YXRpb24gc2hhbGwgc3VwcG9ydCBhdCBsZWFzdA0K
Ym90aCBHLjcxMSBBLWxhdyBhbmQgRy43MTEg7C1sYXcgY29kZWNzIGFzIFZCRCBjb2RlY3MuICJd
DQoNCigzKSBJU0ROIFVESSA9IGFsbCBJU0ROIFRlbGVzZXJ2aWNlcyB3aXRoIElTRE4gSS4yMzEu
IGJlYXJlciBzZXJ2aWNlDQpyZXF1aXJlbWVudA0KPT4gSC4yNDggVERNIFRlcm1pbmF0aW9uIHBy
b3BlcnR5IG11c3QgYmUgc2lnbmFsbGVkIGJ5IE1HQywgaWYgbm90LCBNRyBtYXkNCm5vdCBndWFy
YW50ZWUgVURJIGNhcGFiaWxpdHkgKGkuZS4sIGZ1bGx5IHRyYW5zcGFyZW50IDY0LWtiaXQvcyBi
ZWFyZXINCmNoYW5uZWwpIGluIFRETSBoYWlycGlubmluZyBzY2VuYXJpb3MgLi4uDQoNCg0KQ29u
Y2x1c2lvbjoNCklGIHlvdXIgTUcgaXMgc3VwcG9ydGluZw0KUFNUTiBsaW5lcyAoPSBILjI0OCBB
TE4gVGVybWluYXRpb24pLA0KUFNUTiB0cnVua3MgKD0gSC4yNDggVERNIFRlcm1pbmF0aW9uKSwg
YW5kDQpJU0ROIEIgY2hhbm5lbHMgKD0gSC4yNDggVERNIFRlcm1pbmF0aW9uKQ0KDQpBTkQgSUYg
eW91J3ZlIHN1Y2ggc2VydmljZXMgYW5kIGludGVyd29ya2luZyByZXF1aXJlbWVudHMNCg0KVEhF
TiB5b3Ugc2hvdWxkIGdlbmVyYWxseSBzaWduYWwgdGhlIGNvcnJlc3BvbmRpbmcgcHJvcGVydGll
cyAuLi4NCg0KLi4uIGluIGNhc2Ugb2YNClRETSBoYWlycGlubmluZywNCkFMTiBoYWlycGlubmlu
Zywgb3INCkFMTi10by1URE0gY29ubmVjdGlvbiB0eXBlcy4NCg0KUmVnYXJkcywNCkFsYnJlY2h0
DQoNCkFMQ0FURUwNCg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K
ICAgICAgICAgICAgICAgICAgICAgIFpoYW8gQm8gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAg
IDx6Ym9AaHVhd2VpLmNvbT4gICAgICAgICBUbzogICAgICBtZWdhY29AaWV0Zi5vcmcgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIFNlbnQgYnk6ICAgICAgICAgICAg
ICAgICBjYzogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAg
ICAgICAgICAgICAgICAgIG1lZ2Fjby1hZG1pbkBpZXQgICAgICAgICBTdWJqZWN0OiBbTWVnYWNv
XSBIYWlycGluIGNhc2UgQS91IExhdyBjb252ZXJzaW9uICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIGYub3Jn
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIDI1LjAyLjIwMDQg
MDg6MTEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIA0KDQoNCg0KDQpJbiB0aGlzIGNhc2UsIHRoZSBBL3UgbGF3IGZvcm1h
dCBvZiBhIFRETSBjaXJ1aXQgY2FuIGJlIHByb3Zpc2lvbmVkLCAgYnV0DQp0aGUgTUcgZG9lc24n
dCBrbm93IHRoZSBzZXJ2aWNlIHR5cGUgb2YgYSBjYWxsLCB0aHVzDQpoYXMgbm8gd2F5IHRvIGtu
b3cgaWYgYSBjb252ZXJzaW9uIGlzIG5lZWRlZC4gRm9yIHNwZWVjaCBzZXJ2aWNlIGNvbnZlcnNp
b24NCm1heSBiZSBuZWVkZWQ7IGZvciBkYXRhIHNlcnZpY2UgbGlrZSBpc2RuIFVESSwgY29udmVy
c2lvbiBpcyBub3QgcGVybWl0dGVkLg0KSXMgdGhlcmUgYW55IG1ldGhvZCB0byBzb2x2ZSB0aGlz
IHByb2JsZW0/DQoNClpoYW8gQm8NCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0
YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbQ0KSFVBV0VJLCB3
aGljaCBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRy
ZXNzIGlzDQpsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l
ZCBoZXJlaW4gaW4gYW55IHdheQ0KKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3Rh
bCBvciBwYXJ0aWFsIGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwNCm9yIGRpc3NlbWluYXRpb24p
IGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpIGlzDQpwcm9o
aWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm
eSB0aGUgc2VuZGVyDQpieSBwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0
IQ0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCk1lZ2FjbyBtYWlsaW5nIGxpc3QNCk1lZ2Fjb0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cx
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWVnYWNvDQoNCg0KDQoNCg0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTWVnYWNvIG1haWxpbmcgbGlz
dA0KTWVnYWNvQGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9tZWdhY28NCg==


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



From megaco-admin@ietf.org  Thu Feb 26 08:08:32 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09898
	for ; Thu, 26 Feb 2004 08:08:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwLFD-0000Rb-0I; Thu, 26 Feb 2004 08:08:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwLEm-0000Jd-Cc
	for megaco@optimus.ietf.org; Thu, 26 Feb 2004 08:07:36 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09787
	for ; Thu, 26 Feb 2004 08:07:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwLEl-0004q5-00
	for megaco@ietf.org; Thu, 26 Feb 2004 08:07:35 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwLDs-0004gV-00
	for megaco@ietf.org; Thu, 26 Feb 2004 08:06:41 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwLCu-0004Mq-00
	for megaco@ietf.org; Thu, 26 Feb 2004 08:05:40 -0500
Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1QD52w01891;
	Thu, 26 Feb 2004 08:05:02 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id FS3QX8FL; Thu, 26 Feb 2004 08:05:02 -0500
Received: from nortelnetworks.com (acart1ec.ca.nortel.com [47.129.129.121]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DBDZJLJT; Thu, 26 Feb 2004 08:05:02 -0500
Message-ID: <403DEEFD.70408@nortelnetworks.com>
Date: Thu, 26 Feb 2004 08:05:01 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Zhao Bo 
CC: Albrecht.Schwarz@alcatel.de, megaco@ietf.org
Subject: Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion
References:  <000401c3fc43$68abbe00$f8486e0a@HUAWEI.COM>
In-Reply-To: <000401c3fc43$68abbe00$f8486e0a@HUAWEI.COM>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04f.nortelnetworks.com id i1QD52w01891
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: quoted-printable

I think you would do it by specifying the CLEARMODE codec in the Local an=
d Remote=20
descriptors.  Unfortunately, CLEARMODE is still under consideration by th=
e IESG=20
and hasn't reached RFC status.

Zhao Bo wrote:
> Dear Albrecht:
>     Is there any H.248 package defined to signal the UDI transparency p=
roperties in TDM hairping case? =20
>     Best regards
>=20
> ----- Original Message -----=20
> From: 
> To: "Zhao Bo" 
> Cc: ; 
> Sent: Wednesday, February 25, 2004 10:24 PM
> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion
>=20
>=20
>=20
> Dear Zhao Bo,
>=20
> because there isn't any "hairpinning" definition in MEGACOP/H.248 stand=
ards
> ("please correct if I'm wrong"), I'd like to use the following one for
> responding your questions:
>=20
> ***********************************************************************=
************
> Definition:
> TDM Hairpinning
> ? is a scenario whereby a call is being made between two TDM endpoints =
on a
>     single media gateway. The media comes in on one TDM channel and goe=
s
>     out on another TDM channel through the use of an internal loop in t=
he
>     media gateway.
>=20
> Note 1: due to the fact that there are local call types at local exchan=
ges
> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks (PSTN,
> NISDN, etc), there is a variety of TDM-to-TDM connection types behind t=
he
> general "TDM hairpinning" capability (dependent on required type of IWF=
,
> etc.) in corresponding H.248 MG types
>=20
> Note 2: H.248/MEGCOP perspective
> TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM Terminations
> ***********************************************************************=
*************
>=20
> Based on this hairpinning understanding, my answers are:
>=20
> (1) Speech telephony service: G.711 companding formats are a property o=
f
> the corresponding H.248 TDM termination
>=20
> [Note: dependent on MG architecture and implementation, property might =
be
> signalled or preprovisioned. Of course, G.711 companding law is an inhe=
rent
> property of your DS0 channel at your PDH/SDH/SONET framer; the way, how
> this DS0 property is associated with the corresponding H.248 TDM
> Termination property may only realized MG-internally for very specific =
MG
> architectures. Generally it is up to the MGC, particularly if some (or =
all)
> DS0's are ISDN B channels.]
>=20
> (2) Voiceband Data services: same as in (1)
>=20
> [Note: VBD according new ITU-T V.152 -> "... For purposes of
> interoperability, a V.152 compliant implementation shall support at lea=
st
> both G.711 A-law and G.711 =EC-law codecs as VBD codecs. "]
>=20
> (3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer service
> requirement
> =3D> H.248 TDM Termination property must be signalled by MGC, if not, M=
G may
> not guarantee UDI capability (i.e., fully transparent 64-kbit/s bearer
> channel) in TDM hairpinning scenarios ...
>=20
>=20
> Conclusion:
> IF your MG is supporting
> PSTN lines (=3D H.248 ALN Termination),
> PSTN trunks (=3D H.248 TDM Termination), and
> ISDN B channels (=3D H.248 TDM Termination)
>=20
> AND IF you've such services and interworking requirements
>=20
> THEN you should generally signal the corresponding properties ...
>=20
> ... in case of
> TDM hairpinning,
> ALN hairpinning, or
> ALN-to-TDM connection types.
>=20
> Regards,
> Albrecht
>=20
> ALCATEL
>=20
>=20
>=20
>=20
>                                                                        =
                                                                         =
   =20
>                       Zhao Bo                                          =
                                                                         =
   =20
>                                To:      megaco@ietf.org=
                                                                         =
   =20
>                       Sent by:                 cc:                     =
                                                                         =
   =20
>                       megaco-admin@iet         Subject: [Megaco] Hairpi=
n case A/u Law conversion                                                =
   =20
>                       f.org                                            =
                                                                         =
   =20
>                                                                        =
                                                                         =
   =20
>                                                                        =
                                                                         =
   =20
>                       25.02.2004 08:11                                 =
                                                                         =
   =20
>                                                                        =
                                                                         =
   =20
>                                                                        =
                                                                         =
   =20
>=20
>=20
>=20
>=20
> In this case, the A/u law format of a TDM ciruit can be provisioned,  b=
ut
> the MG doesn't know the service type of a call, thus
> has no way to know if a conversion is needed. For speech service conver=
sion
> may be needed; for data service like isdn UDI, conversion is not permit=
ted.
> Is there any method to solve this problem?
>=20
> Zhao Bo
>=20
> *****************************************************************
> This e-mail and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address i=
s
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproducti=
on,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the send=
er
> by phone or email immediately and delete it!
> *****************************************************************
>=20
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 1=E8=1Ar=89=9A=8AX=A7=82X=AC=B4=C7 i=CA"z=D7=E8=AE=08m=B6=9B?=FF=0C0=D6=
'=AD~=8A=E0=FEf=A2=96f=A7=FEX=AC=B6)=DF=A3=F9=9E=81=A7(

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


From exim@www1.ietf.org  Thu Feb 26 08:10:16 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10040
	for ; Thu, 26 Feb 2004 08:10:16 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwLGt-0000iL-Be
	for megaco-archive@odin.ietf.org; Thu, 26 Feb 2004 08:09:48 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QD9luf002741
	for megaco-archive@odin.ietf.org; Thu, 26 Feb 2004 08:09:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwLGt-0000i8-63
	for megaco-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 08:09:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10004
	for ; Thu, 26 Feb 2004 08:09:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwLGs-00058J-00
	for megaco-web-archive@ietf.org; Thu, 26 Feb 2004 08:09:46 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwLG1-00051Z-00
	for megaco-web-archive@ietf.org; Thu, 26 Feb 2004 08:08:54 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwLFD-0004u4-00
	for megaco-web-archive@ietf.org; Thu, 26 Feb 2004 08:08:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwLFD-0000Rb-0I; Thu, 26 Feb 2004 08:08:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwLEm-0000Jd-Cc
	for megaco@optimus.ietf.org; Thu, 26 Feb 2004 08:07:36 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09787
	for ; Thu, 26 Feb 2004 08:07:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwLEl-0004q5-00
	for megaco@ietf.org; Thu, 26 Feb 2004 08:07:35 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwLDs-0004gV-00
	for megaco@ietf.org; Thu, 26 Feb 2004 08:06:41 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwLCu-0004Mq-00
	for megaco@ietf.org; Thu, 26 Feb 2004 08:05:40 -0500
Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1QD52w01891;
	Thu, 26 Feb 2004 08:05:02 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id FS3QX8FL; Thu, 26 Feb 2004 08:05:02 -0500
Received: from nortelnetworks.com (acart1ec.ca.nortel.com [47.129.129.121]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DBDZJLJT; Thu, 26 Feb 2004 08:05:02 -0500
Message-ID: <403DEEFD.70408@nortelnetworks.com>
Date: Thu, 26 Feb 2004 08:05:01 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Zhao Bo 
CC: Albrecht.Schwarz@alcatel.de, megaco@ietf.org
Subject: Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion
References:  <000401c3fc43$68abbe00$f8486e0a@HUAWEI.COM>
In-Reply-To: <000401c3fc43$68abbe00$f8486e0a@HUAWEI.COM>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04f.nortelnetworks.com id i1QD52w01891
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

I think you would do it by specifying the CLEARMODE codec in the Local an=
d Remote=20
descriptors.  Unfortunately, CLEARMODE is still under consideration by th=
e IESG=20
and hasn't reached RFC status.

Zhao Bo wrote:
> Dear Albrecht:
>     Is there any H.248 package defined to signal the UDI transparency p=
roperties in TDM hairping case? =20
>     Best regards
>=20
> ----- Original Message -----=20
> From: 
> To: "Zhao Bo" 
> Cc: ; 
> Sent: Wednesday, February 25, 2004 10:24 PM
> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion
>=20
>=20
>=20
> Dear Zhao Bo,
>=20
> because there isn't any "hairpinning" definition in MEGACOP/H.248 stand=
ards
> ("please correct if I'm wrong"), I'd like to use the following one for
> responding your questions:
>=20
> ***********************************************************************=
************
> Definition:
> TDM Hairpinning
> ? is a scenario whereby a call is being made between two TDM endpoints =
on a
>     single media gateway. The media comes in on one TDM channel and goe=
s
>     out on another TDM channel through the use of an internal loop in t=
he
>     media gateway.
>=20
> Note 1: due to the fact that there are local call types at local exchan=
ges
> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks (PSTN,
> NISDN, etc), there is a variety of TDM-to-TDM connection types behind t=
he
> general "TDM hairpinning" capability (dependent on required type of IWF=
,
> etc.) in corresponding H.248 MG types
>=20
> Note 2: H.248/MEGCOP perspective
> TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM Terminations
> ***********************************************************************=
*************
>=20
> Based on this hairpinning understanding, my answers are:
>=20
> (1) Speech telephony service: G.711 companding formats are a property o=
f
> the corresponding H.248 TDM termination
>=20
> [Note: dependent on MG architecture and implementation, property might =
be
> signalled or preprovisioned. Of course, G.711 companding law is an inhe=
rent
> property of your DS0 channel at your PDH/SDH/SONET framer; the way, how
> this DS0 property is associated with the corresponding H.248 TDM
> Termination property may only realized MG-internally for very specific =
MG
> architectures. Generally it is up to the MGC, particularly if some (or =
all)
> DS0's are ISDN B channels.]
>=20
> (2) Voiceband Data services: same as in (1)
>=20
> [Note: VBD according new ITU-T V.152 -> "... For purposes of
> interoperability, a V.152 compliant implementation shall support at lea=
st
> both G.711 A-law and G.711 =EC-law codecs as VBD codecs. "]
>=20
> (3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer service
> requirement
> =3D> H.248 TDM Termination property must be signalled by MGC, if not, M=
G may
> not guarantee UDI capability (i.e., fully transparent 64-kbit/s bearer
> channel) in TDM hairpinning scenarios ...
>=20
>=20
> Conclusion:
> IF your MG is supporting
> PSTN lines (=3D H.248 ALN Termination),
> PSTN trunks (=3D H.248 TDM Termination), and
> ISDN B channels (=3D H.248 TDM Termination)
>=20
> AND IF you've such services and interworking requirements
>=20
> THEN you should generally signal the corresponding properties ...
>=20
> ... in case of
> TDM hairpinning,
> ALN hairpinning, or
> ALN-to-TDM connection types.
>=20
> Regards,
> Albrecht
>=20
> ALCATEL
>=20
>=20
>=20
>=20
>                                                                        =
                                                                         =
   =20
>                       Zhao Bo                                          =
                                                                         =
   =20
>                                To:      megaco@ietf.org=
                                                                         =
   =20
>                       Sent by:                 cc:                     =
                                                                         =
   =20
>                       megaco-admin@iet         Subject: [Megaco] Hairpi=
n case A/u Law conversion                                                =
   =20
>                       f.org                                            =
                                                                         =
   =20
>                                                                        =
                                                                         =
   =20
>                                                                        =
                                                                         =
   =20
>                       25.02.2004 08:11                                 =
                                                                         =
   =20
>                                                                        =
                                                                         =
   =20
>                                                                        =
                                                                         =
   =20
>=20
>=20
>=20
>=20
> In this case, the A/u law format of a TDM ciruit can be provisioned,  b=
ut
> the MG doesn't know the service type of a call, thus
> has no way to know if a conversion is needed. For speech service conver=
sion
> may be needed; for data service like isdn UDI, conversion is not permit=
ted.
> Is there any method to solve this problem?
>=20
> Zhao Bo
>=20
> *****************************************************************
> This e-mail and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address i=
s
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproducti=
on,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the send=
er
> by phone or email immediately and delete it!
> *****************************************************************
>=20
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 1=E8=1Ar=89=9A=8AX=A7=82X=AC=B4=C7 i=CA"z=D7=E8=AE=08m=B6=9B?=FF=0C0=D6=
'=AD~=8A=E0=FEf=A2=96f=A7=FEX=AC=B6)=DF=A3=F9=9E=81=A7(

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



From megaco-admin@ietf.org  Thu Feb 26 10:08:32 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17962
	for ; Thu, 26 Feb 2004 10:08:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwN7K-0008ES-UI; Thu, 26 Feb 2004 10:08:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwN6z-00087b-Nf
	for megaco@optimus.ietf.org; Thu, 26 Feb 2004 10:07:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17900
	for ; Thu, 26 Feb 2004 10:07:37 -0500 (EST)
From: Albrecht.Schwarz@alcatel.de
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwN6x-0003t8-00
	for megaco@ietf.org; Thu, 26 Feb 2004 10:07:39 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwN6B-0003o8-00
	for megaco@ietf.org; Thu, 26 Feb 2004 10:06:52 -0500
Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwN5N-0003bZ-00
	for megaco@ietf.org; Thu, 26 Feb 2004 10:06:01 -0500
Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205])
	by mailrelay2.alcatel.de (8.12.10/8.12.10) with ESMTP id i1QF5Eol019175;
	Thu, 26 Feb 2004 15:05:14 GMT
Subject: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin
 case A/u Law conversion
To: Zhao Bo , Tom Taylor 
Cc: megaco@ietf.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
Date: Thu, 26 Feb 2004 16:05:12 +0100
X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 02/26/2004 16:05:13
MIME-Version: 1.0
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: base64
X-Alcanet-virus-scanned: i1QF5Eol019175 at mailrelay2.alcatel.de
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no 
	version=2.60
Content-Transfer-Encoding: base64
Sender: megaco-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: base64

DQpJIHRoaW5rIHRoYXQgdGhlIHF1ZXN0aW9uIGlzLCB3aGV0aGVyIHRoaXMgc3BlY2lmaWMgVERN
IGJlYXJlciBjYXBhYmlsaXR5DQpzaG91bGQgYmUgKDEpIGV4cGxpY2l0bHkgc2lnbmFsbGVkLCBv
ciB3aGV0aGVyICgyKSBpbXBsaWNpdCBhc3N1bXB0aW9uIGlzDQphbHJlYWR5IHN1ZmZpY2llbnQu
DQoNCldpdGggcmVnYXJkIHRvICgxKSwgVG9tLCBJIGd1ZXNzIHRoYXQgeW91ciByZWZlciB0bw0K
DQoqIFJUUC9DTEVBUk1PREUNCiAgUlRQIHBheWxvYWQgZm9ybWF0IGZvciBhIDY0IGtiaXQvcyB0
cmFuc3BhcmVudCBjYWxsDQogIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry
YWZ0LWlldGYtYXZ0LXJ0cC1jbGVhcm1vZGUtMDQudHh0DQoNCkJ1dCwgdGhpcyBjb21pbmcgUkZD
IG1heSBub3QgYmUgZGlyZWN0bHkgYXBwbGllZCwgZS5nLiwgcGFja2V0aXphdGlvbiB0aW1lDQpw
YXJhbWV0ZXIgaXNuJ3QgYXBwbGljYWJsZSBJTUhPLiBQbHMgY29ycmVjdCBtZSBpZiB3cm9uZy4N
Cg0KT3IgZG8geW91IHJlZmVyIHRvIHlvdXIgcHJvcG9zYWxzIGluIHlvdXIgZXhwaXJlZCBkcmFm
dCB3cnQNCiogVERNL0NMRUFSTU9ERQ0KICBDb252ZW50aW9ucyBmb3IgdGhlIHVzZSBvZiB0aGUg
U2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQKQ0KICBmb3IgRGlnaXRhbCBDaXJjdWl0
IENvbm5lY3Rpb25zDQogIGh0dHA6Ly93d3cud2F0ZXJzcHJpbmdzLm9yZy9wdWIvaWQvZHJhZnQt
dGF5bG9yLW1tdXNpYy1zZHAtdGRtLTAxLnR4dA0KDQpNeSBjb25jbHVzaW9uIGlzLCB0aGF0IGFu
IGV4cGxpY2l0IHNpZ25hbGxpbmcgbWV0aG9kIGRvZXNuJ3QgZXhpc3QgdG9kYXkNCigiZXhjZXB0
aW9uIG1pZ2h0IGJlIFEuMTk1MCIpLg0KRXZlbiB0aG91Z2gsIGFuIGV4cGxpY2l0IFRETSBNZWRp
YSBEZXNjcmlwdG9yIGZvciBJLjIzMS4xICBtaWdodCBiZSBoZWxwZnVsDQpmb3IgdW5hbWJpZ291
c2x5IHNwZWNpZmljYXRpb24gaW4gY2VydGFpbiBNRyBpbXBsZW1lbnRhdGlvbnMuDQoNCg0KV2l0
aCByZWdhcmQgdG8gKDIpOg0KSW1wbGljaXQgc2lnbmFsaW5nIGlzIGluIG15IHVuZGVyc3RhbmRp
bmcgdGhlIHNpdHVhdGlvbiBvZiB0b2RheS4gSW4gY2FzZQ0Kb2YsIChhKSBtaXNzaW5nIFRETSBN
ZWRpYSBEZXNjcmlwdG9ycywgb3IgKGIpICJpZGVudGljYWwgVERNIE1lZGlhDQpEZXNjcmlwdG9y
cyB3aXRoIHRyYW5zcGFyZW50IGNoYW5uZWwgaW5kaWNhdGlvbnMiLCB3aGVuIGEgdHJhbnNwYXJl
bnQNCjY0LWtiaXQvcyBiZWFyZXIgY29ubmVjdGlvbiBtYXkgYmUgZXN0YWJsaXNoZWQuDQpTb21l
dGltZXMgdGhpcyBpcyBhbHNvIGNhbGxlZCAibmF0aXZlIFRETSBzd2l0Y2hpbmciLCBvciAibmF0
aXZlIFRETQ0KaGFpcnBpbm5pbmciLCBidXQgdGVjaG5pY2FsbHkgaXQgaXMgZXhhY3RseSByZXBy
ZXNlbnRpbmcgYW4gSVNETiBCIGNoYW5uZWwNCndpdGggSS4yMzEuMSBiZWFyZXIgc2VydmljZS4g
Wz0+IHRoZSBjaGFubmVsIG1heSBieXBhc3MgdGhlIERTUCwgYnV0IGluDQpjYXNlIHRoYXQgYSBE
U1AgaXMgbG9vcGVkLWluLCB0aGVuIG11c3QgYmUgdGhlIERTUCBjaGFubmVsIG9wZXJhdGlvbiBt
b2RlDQpjb25maWd1cmVkIGZvciAnQ2xlYXJtb2RlJ10NCg0KTGFzdCBjb21tZW50Og0KU3VjaCBr
aW5kIG9mIGltcGxpY2l0IHNpZ25hbGxpbmcgbWVjaGFuaXNtIGlzIG9mdGVuIGFzc3VtZWQgaW4g
dGVsY28NCmluZHVzdHJ5LCBiZWNhdXNlIHRoaXMgaXMgdGhlIGxlZ2FjeSBzaWduYWxpbmcgbWVj
aGFuaXNtIHdpdGhpbiBhIFRETQ0Kc3dpdGNoICgiaWYgdGhlcmUgYXJlbid0IGFueSBzaWduYWxl
ZCBiZWFyZXIgY2FwYWJpbGl0aWVzIHRoZW4gdHJhbnNwYXJlbnQNCmNoYW5uZWw7IGFueSBuZWVk
ZWQgYmVhcmVyIGNhcGFiaWxpdHkgaW4gYWRkaXRpb24gbXVzdCBiZSBleHBsaWNpdGx5DQpzaWdu
YWxsZWQsIGxpa2Ugc2lnbmFsIHByb2Nlc3NpbmcgbmV0d29yayBlcXVpcG1lbnQgZnVuY3Rpb25z
LCBlLmcuLCBFQyIpLg0KDQpURE0gaGFpcnBpbm5pbmcgbWVhbnMsIGFuICJILjI0OC1jb250cm9s
bGVkIFRETSBzd2l0Y2hpbmcgZnVuY3Rpb24iIGZyb20NCkguMjQ4IE1lZGlhIEdhdGV3YXkgcGVy
c3BlY3RpdmUuIEhlbmNlLCB0aGlzIGltcGxpY2l0IHNpZ25hbGxpbmcgYXNzdW1wdGlvbg0KbWF5
IGJlIHN0aWxsIHZhbGlkLCBvciBkbyB5b3Ugc2VlIGFueSBuZWVkcyBmb3IgZXhwbGljaXQgc2ln
bmFsaW5nDQpjb2RlcG9pbnRzIGluIGNhc2Ugb2YgVERNLXRvLVRETSBJU0ROIEkuMjMxLjEgY2Fs
bHM/DQoNClJlZ2FyZHMNCg0KQWxicmVjaHQNCg0KDQoNCg0KDQoNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICBUb20gVGF5bG9yICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg
ICAgICAgICAgICAgICAgICAgICA8dGF5bG9yQG5vcnRlbG5lICAgICAgICAgVG86ICAgICAgWmhh
byBCbyA8emJvQGh1YXdlaS5jb20+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICB0
d29ya3MuY29tPiAgICAgICAgICAgICAgY2M6ICAgICAgQWxicmVjaHQgU0NIV0FSWi9ERS9BTENB
VEVMQEFMQ0FURUwsIG1lZ2Fjb0BpZXRmLm9yZyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgU3ViamVjdDogUmU6IFRETSBIYWlycGlubmluZzsgUmU6IFtNZWdhY29dIEhhaXJwaW4gY2Fz
ZSBBL3UgTGF3IGNvbnZlcnNpb24gICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAg
ICAgICAgICAgICAgICAyNi4wMi4yMDA0IDE0OjA1ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQoNCg0KSSB0aGlu
ayB5b3Ugd291bGQgZG8gaXQgYnkgc3BlY2lmeWluZyB0aGUgQ0xFQVJNT0RFIGNvZGVjIGluIHRo
ZSBMb2NhbCBhbmQNClJlbW90ZQ0KZGVzY3JpcHRvcnMuICBVbmZvcnR1bmF0ZWx5LCBDTEVBUk1P
REUgaXMgc3RpbGwgdW5kZXIgY29uc2lkZXJhdGlvbiBieSB0aGUNCklFU0cNCmFuZCBoYXNuJ3Qg
cmVhY2hlZCBSRkMgc3RhdHVzLg0KDQpaaGFvIEJvIHdyb3RlOg0KPiBEZWFyIEFsYnJlY2h0Og0K
PiAgICAgSXMgdGhlcmUgYW55IEguMjQ4IHBhY2thZ2UgZGVmaW5lZCB0byBzaWduYWwgdGhlIFVE
SSB0cmFuc3BhcmVuY3kNCnByb3BlcnRpZXMgaW4gVERNIGhhaXJwaW5nIGNhc2U/DQo+ICAgICBC
ZXN0IHJlZ2FyZHMNCj4NCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiA8
QWxicmVjaHQuU2Nod2FyekBhbGNhdGVsLmRlPg0KPiBUbzogIlpoYW8gQm8iIDx6Ym9AaHVhd2Vp
LmNvbT4NCj4gQ2M6IDxtZWdhY29AaWV0Zi5vcmc+OyA8bWVnYWNvLWFkbWluQGlldGYub3JnPg0K
PiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI1LCAyMDA0IDEwOjI0IFBNDQo+IFN1YmplY3Q6
IFRETSBIYWlycGlubmluZzsgUmU6IFtNZWdhY29dIEhhaXJwaW4gY2FzZSBBL3UgTGF3IGNvbnZl
cnNpb24NCj4NCj4NCj4NCj4gRGVhciBaaGFvIEJvLA0KPg0KPiBiZWNhdXNlIHRoZXJlIGlzbid0
IGFueSAiaGFpcnBpbm5pbmciIGRlZmluaXRpb24gaW4gTUVHQUNPUC9ILjI0OA0Kc3RhbmRhcmRz
DQo+ICgicGxlYXNlIGNvcnJlY3QgaWYgSSdtIHdyb25nIiksIEknZCBsaWtlIHRvIHVzZSB0aGUg
Zm9sbG93aW5nIG9uZSBmb3INCj4gcmVzcG9uZGluZyB5b3VyIHF1ZXN0aW9uczoNCj4NCj4NCioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqDQoNCj4gRGVmaW5pdGlvbjoNCj4gVERNIEhhaXJwaW5u
aW5nDQo+ID8gaXMgYSBzY2VuYXJpbyB3aGVyZWJ5IGEgY2FsbCBpcyBiZWluZyBtYWRlIGJldHdl
ZW4gdHdvIFRETSBlbmRwb2ludHMgb24NCmENCj4gICAgIHNpbmdsZSBtZWRpYSBnYXRld2F5LiBU
aGUgbWVkaWEgY29tZXMgaW4gb24gb25lIFRETSBjaGFubmVsIGFuZCBnb2VzDQo+ICAgICBvdXQg
b24gYW5vdGhlciBURE0gY2hhbm5lbCB0aHJvdWdoIHRoZSB1c2Ugb2YgYW4gaW50ZXJuYWwgbG9v
cCBpbiB0aGUNCj4gICAgIG1lZGlhIGdhdGV3YXkuDQo+DQo+IE5vdGUgMTogZHVlIHRvIHRoZSBm
YWN0IHRoYXQgdGhlcmUgYXJlIGxvY2FsIGNhbGwgdHlwZXMgYXQgbG9jYWwNCmV4Y2hhbmdlcw0K
PiAoQ0xBU1M1KSwgYW5kIHRyYW5zaXQgZXhjaGFuZ2VzIChDTEFTUzQpIGluIGxlZ2FjeSBURE0g
bmV0d29ya3MgKFBTVE4sDQo+IE5JU0ROLCBldGMpLCB0aGVyZSBpcyBhIHZhcmlldHkgb2YgVERN
LXRvLVRETSBjb25uZWN0aW9uIHR5cGVzIGJlaGluZCB0aGUNCj4gZ2VuZXJhbCAiVERNIGhhaXJw
aW5uaW5nIiBjYXBhYmlsaXR5IChkZXBlbmRlbnQgb24gcmVxdWlyZWQgdHlwZSBvZiBJV0YsDQo+
IGV0Yy4pIGluIGNvcnJlc3BvbmRpbmcgSC4yNDggTUcgdHlwZXMNCj4NCj4gTm90ZSAyOiBILjI0
OC9NRUdDT1AgcGVyc3BlY3RpdmUNCj4gVERNIEhhaXJwaW5uaW5nID0gU2luZ2xlIEguMjQ4IENv
bnRleHQgd2l0aCAyIEguMjQ4IFRETSBUZXJtaW5hdGlvbnMNCj4NCioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKg0KDQo+DQo+IEJhc2VkIG9uIHRoaXMgaGFpcnBpbm5pbmcgdW5kZXJzdGFuZGlu
ZywgbXkgYW5zd2VycyBhcmU6DQo+DQo+ICgxKSBTcGVlY2ggdGVsZXBob255IHNlcnZpY2U6IEcu
NzExIGNvbXBhbmRpbmcgZm9ybWF0cyBhcmUgYSBwcm9wZXJ0eSBvZg0KPiB0aGUgY29ycmVzcG9u
ZGluZyBILjI0OCBURE0gdGVybWluYXRpb24NCj4NCj4gW05vdGU6IGRlcGVuZGVudCBvbiBNRyBh
cmNoaXRlY3R1cmUgYW5kIGltcGxlbWVudGF0aW9uLCBwcm9wZXJ0eSBtaWdodCBiZQ0KPiBzaWdu
YWxsZWQgb3IgcHJlcHJvdmlzaW9uZWQuIE9mIGNvdXJzZSwgRy43MTEgY29tcGFuZGluZyBsYXcg
aXMgYW4NCmluaGVyZW50DQo+IHByb3BlcnR5IG9mIHlvdXIgRFMwIGNoYW5uZWwgYXQgeW91ciBQ
REgvU0RIL1NPTkVUIGZyYW1lcjsgdGhlIHdheSwgaG93DQo+IHRoaXMgRFMwIHByb3BlcnR5IGlz
IGFzc29jaWF0ZWQgd2l0aCB0aGUgY29ycmVzcG9uZGluZyBILjI0OCBURE0NCj4gVGVybWluYXRp
b24gcHJvcGVydHkgbWF5IG9ubHkgcmVhbGl6ZWQgTUctaW50ZXJuYWxseSBmb3IgdmVyeSBzcGVj
aWZpYyBNRw0KPiBhcmNoaXRlY3R1cmVzLiBHZW5lcmFsbHkgaXQgaXMgdXAgdG8gdGhlIE1HQywg
cGFydGljdWxhcmx5IGlmIHNvbWUgKG9yDQphbGwpDQo+IERTMCdzIGFyZSBJU0ROIEIgY2hhbm5l
bHMuXQ0KPg0KPiAoMikgVm9pY2ViYW5kIERhdGEgc2VydmljZXM6IHNhbWUgYXMgaW4gKDEpDQo+
DQo+IFtOb3RlOiBWQkQgYWNjb3JkaW5nIG5ldyBJVFUtVCBWLjE1MiAtPiAiLi4uIEZvciBwdXJw
b3NlcyBvZg0KPiBpbnRlcm9wZXJhYmlsaXR5LCBhIFYuMTUyIGNvbXBsaWFudCBpbXBsZW1lbnRh
dGlvbiBzaGFsbCBzdXBwb3J0IGF0IGxlYXN0DQo+IGJvdGggRy43MTEgQS1sYXcgYW5kIEcuNzEx
IMOsLWxhdyBjb2RlY3MgYXMgVkJEIGNvZGVjcy4gIl0NCj4NCj4gKDMpIElTRE4gVURJID0gYWxs
IElTRE4gVGVsZXNlcnZpY2VzIHdpdGggSVNETiBJLjIzMS4gYmVhcmVyIHNlcnZpY2UNCj4gcmVx
dWlyZW1lbnQNCj4gPT4gSC4yNDggVERNIFRlcm1pbmF0aW9uIHByb3BlcnR5IG11c3QgYmUgc2ln
bmFsbGVkIGJ5IE1HQywgaWYgbm90LCBNRw0KbWF5DQo+IG5vdCBndWFyYW50ZWUgVURJIGNhcGFi
aWxpdHkgKGkuZS4sIGZ1bGx5IHRyYW5zcGFyZW50IDY0LWtiaXQvcyBiZWFyZXINCj4gY2hhbm5l
bCkgaW4gVERNIGhhaXJwaW5uaW5nIHNjZW5hcmlvcyAuLi4NCj4NCj4NCj4gQ29uY2x1c2lvbjoN
Cj4gSUYgeW91ciBNRyBpcyBzdXBwb3J0aW5nDQo+IFBTVE4gbGluZXMgKD0gSC4yNDggQUxOIFRl
cm1pbmF0aW9uKSwNCj4gUFNUTiB0cnVua3MgKD0gSC4yNDggVERNIFRlcm1pbmF0aW9uKSwgYW5k
DQo+IElTRE4gQiBjaGFubmVscyAoPSBILjI0OCBURE0gVGVybWluYXRpb24pDQo+DQo+IEFORCBJ
RiB5b3UndmUgc3VjaCBzZXJ2aWNlcyBhbmQgaW50ZXJ3b3JraW5nIHJlcXVpcmVtZW50cw0KPg0K
PiBUSEVOIHlvdSBzaG91bGQgZ2VuZXJhbGx5IHNpZ25hbCB0aGUgY29ycmVzcG9uZGluZyBwcm9w
ZXJ0aWVzIC4uLg0KPg0KPiAuLi4gaW4gY2FzZSBvZg0KPiBURE0gaGFpcnBpbm5pbmcsDQo+IEFM
TiBoYWlycGlubmluZywgb3INCj4gQUxOLXRvLVRETSBjb25uZWN0aW9uIHR5cGVzLg0KPg0KPiBS
ZWdhcmRzLA0KPiBBbGJyZWNodA0KPg0KPiBBTENBVEVMDQo+DQo+DQo+DQo+DQo+DQoNCj4gICAg
ICAgICAgICAgICAgICAgICAgIFpoYW8gQm8NCg0KPiAgICAgICAgICAgICAgICAgICAgICAgPHpi
b0BodWF3ZWkuY29tPiAgICAgICAgIFRvOiAgICAgIG1lZ2Fjb0BpZXRmLm9yZw0KDQo+ICAgICAg
ICAgICAgICAgICAgICAgICBTZW50IGJ5OiAgICAgICAgICAgICAgICAgY2M6DQoNCj4gICAgICAg
ICAgICAgICAgICAgICAgIG1lZ2Fjby1hZG1pbkBpZXQgICAgICAgICBTdWJqZWN0OiBbTWVnYWNv
XSBIYWlycGluDQpjYXNlIEEvdSBMYXcgY29udmVyc2lvbg0KPiAgICAgICAgICAgICAgICAgICAg
ICAgZi5vcmcNCg0KPg0KDQo+DQoNCj4gICAgICAgICAgICAgICAgICAgICAgIDI1LjAyLjIwMDQg
MDg6MTENCg0KPg0KDQo+DQoNCj4NCj4NCj4NCj4NCj4gSW4gdGhpcyBjYXNlLCB0aGUgQS91IGxh
dyBmb3JtYXQgb2YgYSBURE0gY2lydWl0IGNhbiBiZSBwcm92aXNpb25lZCwgIGJ1dA0KPiB0aGUg
TUcgZG9lc24ndCBrbm93IHRoZSBzZXJ2aWNlIHR5cGUgb2YgYSBjYWxsLCB0aHVzDQo+IGhhcyBu
byB3YXkgdG8ga25vdyBpZiBhIGNvbnZlcnNpb24gaXMgbmVlZGVkLiBGb3Igc3BlZWNoIHNlcnZp
Y2UNCmNvbnZlcnNpb24NCj4gbWF5IGJlIG5lZWRlZDsgZm9yIGRhdGEgc2VydmljZSBsaWtlIGlz
ZG4gVURJLCBjb252ZXJzaW9uIGlzIG5vdA0KcGVybWl0dGVkLg0KPiBJcyB0aGVyZSBhbnkgbWV0
aG9kIHRvIHNvbHZlIHRoaXMgcHJvYmxlbT8NCj4NCj4gWmhhbyBCbw0KPg0KPiAqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K
PiBUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGlu
Zm9ybWF0aW9uIGZyb20NCj4gSFVBV0VJLCB3aGljaCBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUg
cGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzDQo+IGxpc3RlZCBhYm92ZS4gQW55IHVz
ZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5DQo+IChpbmNs
dWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbCBkaXNjbG9zdXJlLA0K
cmVwcm9kdWN0aW9uLA0KPiBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4g
dGhlIGludGVuZGVkIHJlY2lwaWVudChzKSBpcw0KPiBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2
ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+IGJ5IHBo
b25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQo+ICoqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+DQo+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE1lZ2Fj
byBtYWlsaW5nIGxpc3QNCj4gTWVnYWNvQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL21lZ2Fjbw0KPg0KPg0KPg0KPg0KPg0KPg0KPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBNZWdhY28gbWFpbGluZyBs
aXN0DQo+IE1lZ2Fjb0BpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9tZWdhY28NCj4gMcOoGnLigLDFocWgWMKn4oCaWMKswrTDhyBpw4oiesOXw6jCrght
wrbigLo/w78MMMOWJ8KtfsWgw6DDvmbCouKAk2bCp8O+WMKswrYpw5/Co8O5xb7vop3CpygNCg0K
DQoNCg==



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


From exim@www1.ietf.org  Thu Feb 26 10:10:17 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18159
	for ; Thu, 26 Feb 2004 10:10:17 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwN94-0000Mz-Kp
	for megaco-archive@odin.ietf.org; Thu, 26 Feb 2004 10:09:50 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QF9oor001415
	for megaco-archive@odin.ietf.org; Thu, 26 Feb 2004 10:09:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwN94-0000Mk-EV
	for megaco-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 10:09:50 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18108
	for ; Thu, 26 Feb 2004 10:09:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwN92-00048q-00
	for megaco-web-archive@ietf.org; Thu, 26 Feb 2004 10:09:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwN86-00040e-00
	for megaco-web-archive@ietf.org; Thu, 26 Feb 2004 10:08:51 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwN7L-0003ud-00
	for megaco-web-archive@ietf.org; Thu, 26 Feb 2004 10:08:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwN7K-0008ES-UI; Thu, 26 Feb 2004 10:08:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwN6z-00087b-Nf
	for megaco@optimus.ietf.org; Thu, 26 Feb 2004 10:07:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17900
	for ; Thu, 26 Feb 2004 10:07:37 -0500 (EST)
From: Albrecht.Schwarz@alcatel.de
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwN6x-0003t8-00
	for megaco@ietf.org; Thu, 26 Feb 2004 10:07:39 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwN6B-0003o8-00
	for megaco@ietf.org; Thu, 26 Feb 2004 10:06:52 -0500
Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwN5N-0003bZ-00
	for megaco@ietf.org; Thu, 26 Feb 2004 10:06:01 -0500
Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205])
	by mailrelay2.alcatel.de (8.12.10/8.12.10) with ESMTP id i1QF5Eol019175;
	Thu, 26 Feb 2004 15:05:14 GMT
Subject: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin
 case A/u Law conversion
To: Zhao Bo , Tom Taylor 
Cc: megaco@ietf.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
Date: Thu, 26 Feb 2004 16:05:12 +0100
X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 02/26/2004 16:05:13
MIME-Version: 1.0
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: base64
X-Alcanet-virus-scanned: i1QF5Eol019175 at mailrelay2.alcatel.de
Content-Transfer-Encoding: base64
Sender: megaco-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: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no 
	version=2.60
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

DQpJIHRoaW5rIHRoYXQgdGhlIHF1ZXN0aW9uIGlzLCB3aGV0aGVyIHRoaXMgc3BlY2lmaWMgVERN
IGJlYXJlciBjYXBhYmlsaXR5DQpzaG91bGQgYmUgKDEpIGV4cGxpY2l0bHkgc2lnbmFsbGVkLCBv
ciB3aGV0aGVyICgyKSBpbXBsaWNpdCBhc3N1bXB0aW9uIGlzDQphbHJlYWR5IHN1ZmZpY2llbnQu
DQoNCldpdGggcmVnYXJkIHRvICgxKSwgVG9tLCBJIGd1ZXNzIHRoYXQgeW91ciByZWZlciB0bw0K
DQoqIFJUUC9DTEVBUk1PREUNCiAgUlRQIHBheWxvYWQgZm9ybWF0IGZvciBhIDY0IGtiaXQvcyB0
cmFuc3BhcmVudCBjYWxsDQogIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry
YWZ0LWlldGYtYXZ0LXJ0cC1jbGVhcm1vZGUtMDQudHh0DQoNCkJ1dCwgdGhpcyBjb21pbmcgUkZD
IG1heSBub3QgYmUgZGlyZWN0bHkgYXBwbGllZCwgZS5nLiwgcGFja2V0aXphdGlvbiB0aW1lDQpw
YXJhbWV0ZXIgaXNuJ3QgYXBwbGljYWJsZSBJTUhPLiBQbHMgY29ycmVjdCBtZSBpZiB3cm9uZy4N
Cg0KT3IgZG8geW91IHJlZmVyIHRvIHlvdXIgcHJvcG9zYWxzIGluIHlvdXIgZXhwaXJlZCBkcmFm
dCB3cnQNCiogVERNL0NMRUFSTU9ERQ0KICBDb252ZW50aW9ucyBmb3IgdGhlIHVzZSBvZiB0aGUg
U2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQKQ0KICBmb3IgRGlnaXRhbCBDaXJjdWl0
IENvbm5lY3Rpb25zDQogIGh0dHA6Ly93d3cud2F0ZXJzcHJpbmdzLm9yZy9wdWIvaWQvZHJhZnQt
dGF5bG9yLW1tdXNpYy1zZHAtdGRtLTAxLnR4dA0KDQpNeSBjb25jbHVzaW9uIGlzLCB0aGF0IGFu
IGV4cGxpY2l0IHNpZ25hbGxpbmcgbWV0aG9kIGRvZXNuJ3QgZXhpc3QgdG9kYXkNCigiZXhjZXB0
aW9uIG1pZ2h0IGJlIFEuMTk1MCIpLg0KRXZlbiB0aG91Z2gsIGFuIGV4cGxpY2l0IFRETSBNZWRp
YSBEZXNjcmlwdG9yIGZvciBJLjIzMS4xICBtaWdodCBiZSBoZWxwZnVsDQpmb3IgdW5hbWJpZ291
c2x5IHNwZWNpZmljYXRpb24gaW4gY2VydGFpbiBNRyBpbXBsZW1lbnRhdGlvbnMuDQoNCg0KV2l0
aCByZWdhcmQgdG8gKDIpOg0KSW1wbGljaXQgc2lnbmFsaW5nIGlzIGluIG15IHVuZGVyc3RhbmRp
bmcgdGhlIHNpdHVhdGlvbiBvZiB0b2RheS4gSW4gY2FzZQ0Kb2YsIChhKSBtaXNzaW5nIFRETSBN
ZWRpYSBEZXNjcmlwdG9ycywgb3IgKGIpICJpZGVudGljYWwgVERNIE1lZGlhDQpEZXNjcmlwdG9y
cyB3aXRoIHRyYW5zcGFyZW50IGNoYW5uZWwgaW5kaWNhdGlvbnMiLCB3aGVuIGEgdHJhbnNwYXJl
bnQNCjY0LWtiaXQvcyBiZWFyZXIgY29ubmVjdGlvbiBtYXkgYmUgZXN0YWJsaXNoZWQuDQpTb21l
dGltZXMgdGhpcyBpcyBhbHNvIGNhbGxlZCAibmF0aXZlIFRETSBzd2l0Y2hpbmciLCBvciAibmF0
aXZlIFRETQ0KaGFpcnBpbm5pbmciLCBidXQgdGVjaG5pY2FsbHkgaXQgaXMgZXhhY3RseSByZXBy
ZXNlbnRpbmcgYW4gSVNETiBCIGNoYW5uZWwNCndpdGggSS4yMzEuMSBiZWFyZXIgc2VydmljZS4g
Wz0+IHRoZSBjaGFubmVsIG1heSBieXBhc3MgdGhlIERTUCwgYnV0IGluDQpjYXNlIHRoYXQgYSBE
U1AgaXMgbG9vcGVkLWluLCB0aGVuIG11c3QgYmUgdGhlIERTUCBjaGFubmVsIG9wZXJhdGlvbiBt
b2RlDQpjb25maWd1cmVkIGZvciAnQ2xlYXJtb2RlJ10NCg0KTGFzdCBjb21tZW50Og0KU3VjaCBr
aW5kIG9mIGltcGxpY2l0IHNpZ25hbGxpbmcgbWVjaGFuaXNtIGlzIG9mdGVuIGFzc3VtZWQgaW4g
dGVsY28NCmluZHVzdHJ5LCBiZWNhdXNlIHRoaXMgaXMgdGhlIGxlZ2FjeSBzaWduYWxpbmcgbWVj
aGFuaXNtIHdpdGhpbiBhIFRETQ0Kc3dpdGNoICgiaWYgdGhlcmUgYXJlbid0IGFueSBzaWduYWxl
ZCBiZWFyZXIgY2FwYWJpbGl0aWVzIHRoZW4gdHJhbnNwYXJlbnQNCmNoYW5uZWw7IGFueSBuZWVk
ZWQgYmVhcmVyIGNhcGFiaWxpdHkgaW4gYWRkaXRpb24gbXVzdCBiZSBleHBsaWNpdGx5DQpzaWdu
YWxsZWQsIGxpa2Ugc2lnbmFsIHByb2Nlc3NpbmcgbmV0d29yayBlcXVpcG1lbnQgZnVuY3Rpb25z
LCBlLmcuLCBFQyIpLg0KDQpURE0gaGFpcnBpbm5pbmcgbWVhbnMsIGFuICJILjI0OC1jb250cm9s
bGVkIFRETSBzd2l0Y2hpbmcgZnVuY3Rpb24iIGZyb20NCkguMjQ4IE1lZGlhIEdhdGV3YXkgcGVy
c3BlY3RpdmUuIEhlbmNlLCB0aGlzIGltcGxpY2l0IHNpZ25hbGxpbmcgYXNzdW1wdGlvbg0KbWF5
IGJlIHN0aWxsIHZhbGlkLCBvciBkbyB5b3Ugc2VlIGFueSBuZWVkcyBmb3IgZXhwbGljaXQgc2ln
bmFsaW5nDQpjb2RlcG9pbnRzIGluIGNhc2Ugb2YgVERNLXRvLVRETSBJU0ROIEkuMjMxLjEgY2Fs
bHM/DQoNClJlZ2FyZHMNCg0KQWxicmVjaHQNCg0KDQoNCg0KDQoNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICBUb20gVGF5bG9yICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg
ICAgICAgICAgICAgICAgICAgICA8dGF5bG9yQG5vcnRlbG5lICAgICAgICAgVG86ICAgICAgWmhh
byBCbyA8emJvQGh1YXdlaS5jb20+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICB0
d29ya3MuY29tPiAgICAgICAgICAgICAgY2M6ICAgICAgQWxicmVjaHQgU0NIV0FSWi9ERS9BTENB
VEVMQEFMQ0FURUwsIG1lZ2Fjb0BpZXRmLm9yZyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgU3ViamVjdDogUmU6IFRETSBIYWlycGlubmluZzsgUmU6IFtNZWdhY29dIEhhaXJwaW4gY2Fz
ZSBBL3UgTGF3IGNvbnZlcnNpb24gICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAg
ICAgICAgICAgICAgICAyNi4wMi4yMDA0IDE0OjA1ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQoNCg0KSSB0aGlu
ayB5b3Ugd291bGQgZG8gaXQgYnkgc3BlY2lmeWluZyB0aGUgQ0xFQVJNT0RFIGNvZGVjIGluIHRo
ZSBMb2NhbCBhbmQNClJlbW90ZQ0KZGVzY3JpcHRvcnMuICBVbmZvcnR1bmF0ZWx5LCBDTEVBUk1P
REUgaXMgc3RpbGwgdW5kZXIgY29uc2lkZXJhdGlvbiBieSB0aGUNCklFU0cNCmFuZCBoYXNuJ3Qg
cmVhY2hlZCBSRkMgc3RhdHVzLg0KDQpaaGFvIEJvIHdyb3RlOg0KPiBEZWFyIEFsYnJlY2h0Og0K
PiAgICAgSXMgdGhlcmUgYW55IEguMjQ4IHBhY2thZ2UgZGVmaW5lZCB0byBzaWduYWwgdGhlIFVE
SSB0cmFuc3BhcmVuY3kNCnByb3BlcnRpZXMgaW4gVERNIGhhaXJwaW5nIGNhc2U/DQo+ICAgICBC
ZXN0IHJlZ2FyZHMNCj4NCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiA8
QWxicmVjaHQuU2Nod2FyekBhbGNhdGVsLmRlPg0KPiBUbzogIlpoYW8gQm8iIDx6Ym9AaHVhd2Vp
LmNvbT4NCj4gQ2M6IDxtZWdhY29AaWV0Zi5vcmc+OyA8bWVnYWNvLWFkbWluQGlldGYub3JnPg0K
PiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI1LCAyMDA0IDEwOjI0IFBNDQo+IFN1YmplY3Q6
IFRETSBIYWlycGlubmluZzsgUmU6IFtNZWdhY29dIEhhaXJwaW4gY2FzZSBBL3UgTGF3IGNvbnZl
cnNpb24NCj4NCj4NCj4NCj4gRGVhciBaaGFvIEJvLA0KPg0KPiBiZWNhdXNlIHRoZXJlIGlzbid0
IGFueSAiaGFpcnBpbm5pbmciIGRlZmluaXRpb24gaW4gTUVHQUNPUC9ILjI0OA0Kc3RhbmRhcmRz
DQo+ICgicGxlYXNlIGNvcnJlY3QgaWYgSSdtIHdyb25nIiksIEknZCBsaWtlIHRvIHVzZSB0aGUg
Zm9sbG93aW5nIG9uZSBmb3INCj4gcmVzcG9uZGluZyB5b3VyIHF1ZXN0aW9uczoNCj4NCj4NCioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqDQoNCj4gRGVmaW5pdGlvbjoNCj4gVERNIEhhaXJwaW5u
aW5nDQo+ID8gaXMgYSBzY2VuYXJpbyB3aGVyZWJ5IGEgY2FsbCBpcyBiZWluZyBtYWRlIGJldHdl
ZW4gdHdvIFRETSBlbmRwb2ludHMgb24NCmENCj4gICAgIHNpbmdsZSBtZWRpYSBnYXRld2F5LiBU
aGUgbWVkaWEgY29tZXMgaW4gb24gb25lIFRETSBjaGFubmVsIGFuZCBnb2VzDQo+ICAgICBvdXQg
b24gYW5vdGhlciBURE0gY2hhbm5lbCB0aHJvdWdoIHRoZSB1c2Ugb2YgYW4gaW50ZXJuYWwgbG9v
cCBpbiB0aGUNCj4gICAgIG1lZGlhIGdhdGV3YXkuDQo+DQo+IE5vdGUgMTogZHVlIHRvIHRoZSBm
YWN0IHRoYXQgdGhlcmUgYXJlIGxvY2FsIGNhbGwgdHlwZXMgYXQgbG9jYWwNCmV4Y2hhbmdlcw0K
PiAoQ0xBU1M1KSwgYW5kIHRyYW5zaXQgZXhjaGFuZ2VzIChDTEFTUzQpIGluIGxlZ2FjeSBURE0g
bmV0d29ya3MgKFBTVE4sDQo+IE5JU0ROLCBldGMpLCB0aGVyZSBpcyBhIHZhcmlldHkgb2YgVERN
LXRvLVRETSBjb25uZWN0aW9uIHR5cGVzIGJlaGluZCB0aGUNCj4gZ2VuZXJhbCAiVERNIGhhaXJw
aW5uaW5nIiBjYXBhYmlsaXR5IChkZXBlbmRlbnQgb24gcmVxdWlyZWQgdHlwZSBvZiBJV0YsDQo+
IGV0Yy4pIGluIGNvcnJlc3BvbmRpbmcgSC4yNDggTUcgdHlwZXMNCj4NCj4gTm90ZSAyOiBILjI0
OC9NRUdDT1AgcGVyc3BlY3RpdmUNCj4gVERNIEhhaXJwaW5uaW5nID0gU2luZ2xlIEguMjQ4IENv
bnRleHQgd2l0aCAyIEguMjQ4IFRETSBUZXJtaW5hdGlvbnMNCj4NCioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKg0KDQo+DQo+IEJhc2VkIG9uIHRoaXMgaGFpcnBpbm5pbmcgdW5kZXJzdGFuZGlu
ZywgbXkgYW5zd2VycyBhcmU6DQo+DQo+ICgxKSBTcGVlY2ggdGVsZXBob255IHNlcnZpY2U6IEcu
NzExIGNvbXBhbmRpbmcgZm9ybWF0cyBhcmUgYSBwcm9wZXJ0eSBvZg0KPiB0aGUgY29ycmVzcG9u
ZGluZyBILjI0OCBURE0gdGVybWluYXRpb24NCj4NCj4gW05vdGU6IGRlcGVuZGVudCBvbiBNRyBh
cmNoaXRlY3R1cmUgYW5kIGltcGxlbWVudGF0aW9uLCBwcm9wZXJ0eSBtaWdodCBiZQ0KPiBzaWdu
YWxsZWQgb3IgcHJlcHJvdmlzaW9uZWQuIE9mIGNvdXJzZSwgRy43MTEgY29tcGFuZGluZyBsYXcg
aXMgYW4NCmluaGVyZW50DQo+IHByb3BlcnR5IG9mIHlvdXIgRFMwIGNoYW5uZWwgYXQgeW91ciBQ
REgvU0RIL1NPTkVUIGZyYW1lcjsgdGhlIHdheSwgaG93DQo+IHRoaXMgRFMwIHByb3BlcnR5IGlz
IGFzc29jaWF0ZWQgd2l0aCB0aGUgY29ycmVzcG9uZGluZyBILjI0OCBURE0NCj4gVGVybWluYXRp
b24gcHJvcGVydHkgbWF5IG9ubHkgcmVhbGl6ZWQgTUctaW50ZXJuYWxseSBmb3IgdmVyeSBzcGVj
aWZpYyBNRw0KPiBhcmNoaXRlY3R1cmVzLiBHZW5lcmFsbHkgaXQgaXMgdXAgdG8gdGhlIE1HQywg
cGFydGljdWxhcmx5IGlmIHNvbWUgKG9yDQphbGwpDQo+IERTMCdzIGFyZSBJU0ROIEIgY2hhbm5l
bHMuXQ0KPg0KPiAoMikgVm9pY2ViYW5kIERhdGEgc2VydmljZXM6IHNhbWUgYXMgaW4gKDEpDQo+
DQo+IFtOb3RlOiBWQkQgYWNjb3JkaW5nIG5ldyBJVFUtVCBWLjE1MiAtPiAiLi4uIEZvciBwdXJw
b3NlcyBvZg0KPiBpbnRlcm9wZXJhYmlsaXR5LCBhIFYuMTUyIGNvbXBsaWFudCBpbXBsZW1lbnRh
dGlvbiBzaGFsbCBzdXBwb3J0IGF0IGxlYXN0DQo+IGJvdGggRy43MTEgQS1sYXcgYW5kIEcuNzEx
IMOsLWxhdyBjb2RlY3MgYXMgVkJEIGNvZGVjcy4gIl0NCj4NCj4gKDMpIElTRE4gVURJID0gYWxs
IElTRE4gVGVsZXNlcnZpY2VzIHdpdGggSVNETiBJLjIzMS4gYmVhcmVyIHNlcnZpY2UNCj4gcmVx
dWlyZW1lbnQNCj4gPT4gSC4yNDggVERNIFRlcm1pbmF0aW9uIHByb3BlcnR5IG11c3QgYmUgc2ln
bmFsbGVkIGJ5IE1HQywgaWYgbm90LCBNRw0KbWF5DQo+IG5vdCBndWFyYW50ZWUgVURJIGNhcGFi
aWxpdHkgKGkuZS4sIGZ1bGx5IHRyYW5zcGFyZW50IDY0LWtiaXQvcyBiZWFyZXINCj4gY2hhbm5l
bCkgaW4gVERNIGhhaXJwaW5uaW5nIHNjZW5hcmlvcyAuLi4NCj4NCj4NCj4gQ29uY2x1c2lvbjoN
Cj4gSUYgeW91ciBNRyBpcyBzdXBwb3J0aW5nDQo+IFBTVE4gbGluZXMgKD0gSC4yNDggQUxOIFRl
cm1pbmF0aW9uKSwNCj4gUFNUTiB0cnVua3MgKD0gSC4yNDggVERNIFRlcm1pbmF0aW9uKSwgYW5k
DQo+IElTRE4gQiBjaGFubmVscyAoPSBILjI0OCBURE0gVGVybWluYXRpb24pDQo+DQo+IEFORCBJ
RiB5b3UndmUgc3VjaCBzZXJ2aWNlcyBhbmQgaW50ZXJ3b3JraW5nIHJlcXVpcmVtZW50cw0KPg0K
PiBUSEVOIHlvdSBzaG91bGQgZ2VuZXJhbGx5IHNpZ25hbCB0aGUgY29ycmVzcG9uZGluZyBwcm9w
ZXJ0aWVzIC4uLg0KPg0KPiAuLi4gaW4gY2FzZSBvZg0KPiBURE0gaGFpcnBpbm5pbmcsDQo+IEFM
TiBoYWlycGlubmluZywgb3INCj4gQUxOLXRvLVRETSBjb25uZWN0aW9uIHR5cGVzLg0KPg0KPiBS
ZWdhcmRzLA0KPiBBbGJyZWNodA0KPg0KPiBBTENBVEVMDQo+DQo+DQo+DQo+DQo+DQoNCj4gICAg
ICAgICAgICAgICAgICAgICAgIFpoYW8gQm8NCg0KPiAgICAgICAgICAgICAgICAgICAgICAgPHpi
b0BodWF3ZWkuY29tPiAgICAgICAgIFRvOiAgICAgIG1lZ2Fjb0BpZXRmLm9yZw0KDQo+ICAgICAg
ICAgICAgICAgICAgICAgICBTZW50IGJ5OiAgICAgICAgICAgICAgICAgY2M6DQoNCj4gICAgICAg
ICAgICAgICAgICAgICAgIG1lZ2Fjby1hZG1pbkBpZXQgICAgICAgICBTdWJqZWN0OiBbTWVnYWNv
XSBIYWlycGluDQpjYXNlIEEvdSBMYXcgY29udmVyc2lvbg0KPiAgICAgICAgICAgICAgICAgICAg
ICAgZi5vcmcNCg0KPg0KDQo+DQoNCj4gICAgICAgICAgICAgICAgICAgICAgIDI1LjAyLjIwMDQg
MDg6MTENCg0KPg0KDQo+DQoNCj4NCj4NCj4NCj4NCj4gSW4gdGhpcyBjYXNlLCB0aGUgQS91IGxh
dyBmb3JtYXQgb2YgYSBURE0gY2lydWl0IGNhbiBiZSBwcm92aXNpb25lZCwgIGJ1dA0KPiB0aGUg
TUcgZG9lc24ndCBrbm93IHRoZSBzZXJ2aWNlIHR5cGUgb2YgYSBjYWxsLCB0aHVzDQo+IGhhcyBu
byB3YXkgdG8ga25vdyBpZiBhIGNvbnZlcnNpb24gaXMgbmVlZGVkLiBGb3Igc3BlZWNoIHNlcnZp
Y2UNCmNvbnZlcnNpb24NCj4gbWF5IGJlIG5lZWRlZDsgZm9yIGRhdGEgc2VydmljZSBsaWtlIGlz
ZG4gVURJLCBjb252ZXJzaW9uIGlzIG5vdA0KcGVybWl0dGVkLg0KPiBJcyB0aGVyZSBhbnkgbWV0
aG9kIHRvIHNvbHZlIHRoaXMgcHJvYmxlbT8NCj4NCj4gWmhhbyBCbw0KPg0KPiAqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K
PiBUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGlu
Zm9ybWF0aW9uIGZyb20NCj4gSFVBV0VJLCB3aGljaCBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUg
cGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzDQo+IGxpc3RlZCBhYm92ZS4gQW55IHVz
ZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5DQo+IChpbmNs
dWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbCBkaXNjbG9zdXJlLA0K
cmVwcm9kdWN0aW9uLA0KPiBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4g
dGhlIGludGVuZGVkIHJlY2lwaWVudChzKSBpcw0KPiBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2
ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+IGJ5IHBo
b25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQo+ICoqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+DQo+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE1lZ2Fj
byBtYWlsaW5nIGxpc3QNCj4gTWVnYWNvQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL21lZ2Fjbw0KPg0KPg0KPg0KPg0KPg0KPg0KPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBNZWdhY28gbWFpbGluZyBs
aXN0DQo+IE1lZ2Fjb0BpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9tZWdhY28NCj4gMcOoGnLigLDFocWgWMKn4oCaWMKswrTDhyBpw4oiesOXw6jCrght
wrbigLo/w78MMMOWJ8KtfsWgw6DDvmbCouKAk2bCp8O+WMKswrYpw5/Co8O5xb7vop3CpygNCg0K
DQoNCg==



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



From megaco-admin@ietf.org  Thu Feb 26 10:33:28 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19994
	for ; Thu, 26 Feb 2004 10:33:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwNVV-0005Yy-7Q; Thu, 26 Feb 2004 10:33:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwNVN-0005YC-UQ
	for megaco@optimus.ietf.org; Thu, 26 Feb 2004 10:32:53 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19917
	for ; Thu, 26 Feb 2004 10:32:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwNVL-0006t0-00
	for megaco@ietf.org; Thu, 26 Feb 2004 10:32:51 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwNUR-0006km-00
	for megaco@ietf.org; Thu, 26 Feb 2004 10:31:56 -0500
Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwNTk-0006dD-00
	for megaco@ietf.org; Thu, 26 Feb 2004 10:31:12 -0500
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 26 Feb 2004 10:30:36 -0500
Message-ID: 
From: Carl Rutter 
To: megaco@ietf.org
Date: Thu, 26 Feb 2004 10:30:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Megaco] SIP MEGACO interworking
Sender: megaco-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: ,
	

I have a question about dealing with differences between SIP and MEGACO
SDP formats.  I noticed there was a similar thread about this not too long
ago.
http://www.ietf.org/mail-archive/working-groups/megaco/current/msg04724.html
I believe it ended with the point that the MGC needed to do some massaging.

My specific issue is with T.38.   The "SIP Support for real-time Fax"
document
has 1 session with multiple media session-levels.  The T.38 document p34
indicates the 
media lines MUST be separated by a version descriptor.  Given the
incompatible
formats I believe the MGC must do some massaging.  
Is this correct?
Should the MG just handle both cases?
Is there a SIP/MEGACO interworking document?

Thanks,
Carl

Carl Rutter
Telica, Inc.
Building G, Suite 100
734 Forest Street
Marlboro, MA 01752
Email crutter@telica.com
Voice 508-480-0909 x8178
Fax 508-480-0922 
www.telica.com




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


From exim@www1.ietf.org  Thu Feb 26 10:35:18 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20201
	for ; Thu, 26 Feb 2004 10:35:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwNXH-0005i3-Kh
	for megaco-archive@odin.ietf.org; Thu, 26 Feb 2004 10:34:51 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QFYpb8021943
	for megaco-archive@odin.ietf.org; Thu, 26 Feb 2004 10:34:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwNXH-0005hq-FS
	for megaco-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 10:34:51 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20148
	for ; Thu, 26 Feb 2004 10:34:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwNXF-0007D3-00
	for megaco-web-archive@ietf.org; Thu, 26 Feb 2004 10:34:49 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwNWN-00073q-00
	for megaco-web-archive@ietf.org; Thu, 26 Feb 2004 10:33:56 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwNVU-0006uX-00
	for megaco-web-archive@ietf.org; Thu, 26 Feb 2004 10:33:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwNVV-0005Yy-7Q; Thu, 26 Feb 2004 10:33:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwNVN-0005YC-UQ
	for megaco@optimus.ietf.org; Thu, 26 Feb 2004 10:32:53 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19917
	for ; Thu, 26 Feb 2004 10:32:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwNVL-0006t0-00
	for megaco@ietf.org; Thu, 26 Feb 2004 10:32:51 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwNUR-0006km-00
	for megaco@ietf.org; Thu, 26 Feb 2004 10:31:56 -0500
Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwNTk-0006dD-00
	for megaco@ietf.org; Thu, 26 Feb 2004 10:31:12 -0500
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 26 Feb 2004 10:30:36 -0500
Message-ID: 
From: Carl Rutter 
To: megaco@ietf.org
Date: Thu, 26 Feb 2004 10:30:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Megaco] SIP MEGACO interworking
Sender: megaco-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: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60

I have a question about dealing with differences between SIP and MEGACO
SDP formats.  I noticed there was a similar thread about this not too long
ago.
http://www.ietf.org/mail-archive/working-groups/megaco/current/msg04724.html
I believe it ended with the point that the MGC needed to do some massaging.

My specific issue is with T.38.   The "SIP Support for real-time Fax"
document
has 1 session with multiple media session-levels.  The T.38 document p34
indicates the 
media lines MUST be separated by a version descriptor.  Given the
incompatible
formats I believe the MGC must do some massaging.  
Is this correct?
Should the MG just handle both cases?
Is there a SIP/MEGACO interworking document?

Thanks,
Carl

Carl Rutter
Telica, Inc.
Building G, Suite 100
734 Forest Street
Marlboro, MA 01752
Email crutter@telica.com
Voice 508-480-0909 x8178
Fax 508-480-0922 
www.telica.com




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



From megaco-admin@ietf.org  Thu Feb 26 11:00:37 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21734
	for ; Thu, 26 Feb 2004 11:00:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwNvk-0008Jv-9x; Thu, 26 Feb 2004 11:00:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwNvM-0008EK-Uc
	for megaco@optimus.ietf.org; Thu, 26 Feb 2004 10:59:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21686
	for ; Thu, 26 Feb 2004 10:59:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwNvK-0002fj-00
	for megaco@ietf.org; Thu, 26 Feb 2004 10:59:42 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwNuS-0002a6-00
	for megaco@ietf.org; Thu, 26 Feb 2004 10:58:49 -0500
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwNtg-0002Of-00
	for megaco@ietf.org; Thu, 26 Feb 2004 10:58:00 -0500
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 i1QFvLY01433;
	Thu, 26 Feb 2004 10:57:22 -0500 (EST)
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 FS3C9KQZ; Thu, 26 Feb 2004 10:57:21 -0500
Received: from nortelnetworks.com (acart1ec.ca.nortel.com [47.129.129.121]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DBDZJLMX; Thu, 26 Feb 2004 10:57:22 -0500
Message-ID: <403E1760.2010903@nortelnetworks.com>
Date: Thu, 26 Feb 2004 10:57:20 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Albrecht.Schwarz@alcatel.de
CC: Zhao Bo , megaco@ietf.org
Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning;
 Re: [Megaco] Hairpin case A/u Law conversion
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by zcars0m9.nortelnetworks.com id i1QFvLY01433
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: quoted-printable

I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in my inter=
vention.=20
  My old draft has been allowed to expire because it did not seem to be o=
f much=20
interest to the community.

You are right: the draft just referred to doesn't apply to TDM, only to t=
he packet=20
side.  I wasn't thinking.  I agree that in the absence of the attributes =
provided=20
in my old draft, TDM bearer characteristics are assumed rather than signa=
lled=20
explicitly.

Albrecht.Schwarz@alcatel.de wrote:

> I think that the question is, whether this specific TDM bearer capabili=
ty
> should be (1) explicitly signalled, or whether (2) implicit assumption =
is
> already sufficient.
>=20
> With regard to (1), Tom, I guess that your refer to
>=20
> * RTP/CLEARMODE
>   RTP payload format for a 64 kbit/s transparent call
>   http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-04.t=
xt
>=20
> But, this coming RFC may not be directly applied, e.g., packetization t=
ime
> parameter isn't applicable IMHO. Pls correct me if wrong.
>=20
> Or do you refer to your proposals in your expired draft wrt
> * TDM/CLEARMODE
>   Conventions for the use of the Session Description Protocol (SDP)
>   for Digital Circuit Connections
>   http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01.txt
>=20
> My conclusion is, that an explicit signalling method doesn't exist toda=
y
> ("exception might be Q.1950").
> Even though, an explicit TDM Media Descriptor for I.231.1  might be hel=
pful
> for unambigously specification in certain MG implementations.
>=20
>=20
> With regard to (2):
> Implicit signaling is in my understanding the situation of today. In ca=
se
> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Media
> Descriptors with transparent channel indications", when a transparent
> 64-kbit/s bearer connection may be established.
> Sometimes this is also called "native TDM switching", or "native TDM
> hairpinning", but technically it is exactly representing an ISDN B chan=
nel
> with I.231.1 bearer service. [=3D> the channel may bypass the DSP, but =
in
> case that a DSP is looped-in, then must be the DSP channel operation mo=
de
> configured for 'Clearmode']
>=20
> Last comment:
> Such kind of implicit signalling mechanism is often assumed in telco
> industry, because this is the legacy signaling mechanism within a TDM
> switch ("if there aren't any signaled bearer capabilities then transpar=
ent
> channel; any needed bearer capability in addition must be explicitly
> signalled, like signal processing network equipment functions, e.g., EC=
").
>=20
> TDM hairpinning means, an "H.248-controlled TDM switching function" fro=
m
> H.248 Media Gateway perspective. Hence, this implicit signalling assump=
tion
> may be still valid, or do you see any needs for explicit signaling
> codepoints in case of TDM-to-TDM ISDN I.231.1 calls?
>=20
> Regards
>=20
> Albrecht
>=20
>=20
>=20
>=20
>=20
>=20
>                                                                        =
                                                                         =
   =20
>                       Tom Taylor                                       =
                                                                         =
   =20
>                                                                                       =
   =20
>                       tworks.com>              cc:      Albrecht SCHWAR=
Z/DE/ALCATEL@ALCATEL, megaco@ietf.org                                    =
   =20
>                                                Subject: Re: TDM Hairpin=
ning; Re: [Megaco] Hairpin case A/u Law conversion                       =
   =20
>                       26.02.2004 14:05                                 =
                                                                         =
   =20
>                                                                        =
                                                                         =
   =20
>                                                                        =
                                                                         =
   =20
>=20
>=20
>=20
>=20
> I think you would do it by specifying the CLEARMODE codec in the Local =
and
> Remote
> descriptors.  Unfortunately, CLEARMODE is still under consideration by =
the
> IESG
> and hasn't reached RFC status.
>=20
> Zhao Bo wrote:
>=20
>>Dear Albrecht:
>>    Is there any H.248 package defined to signal the UDI transparency
>=20
> properties in TDM hairping case?
>=20
>>    Best regards
>>
>>----- Original Message -----
>>From: 
>>To: "Zhao Bo" 
>>Cc: ; 
>>Sent: Wednesday, February 25, 2004 10:24 PM
>>Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion
>>
>>
>>
>>Dear Zhao Bo,
>>
>>because there isn't any "hairpinning" definition in MEGACOP/H.248
>=20
> standards
>=20
>>("please correct if I'm wrong"), I'd like to use the following one for
>>responding your questions:
>>
>>
>=20
> ***********************************************************************=
************
>=20
>=20
>>Definition:
>>TDM Hairpinning
>>? is a scenario whereby a call is being made between two TDM endpoints =
on
>=20
> a
>=20
>>    single media gateway. The media comes in on one TDM channel and goe=
s
>>    out on another TDM channel through the use of an internal loop in t=
he
>>    media gateway.
>>
>>Note 1: due to the fact that there are local call types at local
>=20
> exchanges
>=20
>>(CLASS5), and transit exchanges (CLASS4) in legacy TDM networks (PSTN,
>>NISDN, etc), there is a variety of TDM-to-TDM connection types behind t=
he
>>general "TDM hairpinning" capability (dependent on required type of IWF=
,
>>etc.) in corresponding H.248 MG types
>>
>>Note 2: H.248/MEGCOP perspective
>>TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM Terminations
>>
>=20
> ***********************************************************************=
*************
>=20
>=20
>>Based on this hairpinning understanding, my answers are:
>>
>>(1) Speech telephony service: G.711 companding formats are a property o=
f
>>the corresponding H.248 TDM termination
>>
>>[Note: dependent on MG architecture and implementation, property might =
be
>>signalled or preprovisioned. Of course, G.711 companding law is an
>=20
> inherent
>=20
>>property of your DS0 channel at your PDH/SDH/SONET framer; the way, how
>>this DS0 property is associated with the corresponding H.248 TDM
>>Termination property may only realized MG-internally for very specific =
MG
>>architectures. Generally it is up to the MGC, particularly if some (or
>=20
> all)
>=20
>>DS0's are ISDN B channels.]
>>
>>(2) Voiceband Data services: same as in (1)
>>
>>[Note: VBD according new ITU-T V.152 -> "... For purposes of
>>interoperability, a V.152 compliant implementation shall support at lea=
st
>>both G.711 A-law and G.711 =C3=AC-law codecs as VBD codecs. "]
>>
>>(3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer service
>>requirement
>>=3D> H.248 TDM Termination property must be signalled by MGC, if not, M=
G
>=20
> may
>=20
>>not guarantee UDI capability (i.e., fully transparent 64-kbit/s bearer
>>channel) in TDM hairpinning scenarios ...
>>
>>
>>Conclusion:
>>IF your MG is supporting
>>PSTN lines (=3D H.248 ALN Termination),
>>PSTN trunks (=3D H.248 TDM Termination), and
>>ISDN B channels (=3D H.248 TDM Termination)
>>
>>AND IF you've such services and interworking requirements
>>
>>THEN you should generally signal the corresponding properties ...
>>
>>... in case of
>>TDM hairpinning,
>>ALN hairpinning, or
>>ALN-to-TDM connection types.
>>
>>Regards,
>>Albrecht
>>
>>ALCATEL
>>
>>
>>
>>
>>
>=20
>=20
>>                      Zhao Bo
>=20
>=20
>>                               To:      megaco@ietf.org
>=20
>=20
>>                      Sent by:                 cc:
>=20
>=20
>>                      megaco-admin@iet         Subject: [Megaco] Hairpi=
n
>=20
> case A/u Law conversion
>=20
>>                      f.org
>=20
>=20
>=20
>=20
>>                      25.02.2004 08:11
>=20
>=20
>=20
>=20
>>
>>
>>
>>In this case, the A/u law format of a TDM ciruit can be provisioned,  b=
ut
>>the MG doesn't know the service type of a call, thus
>>has no way to know if a conversion is needed. For speech service
>=20
> conversion
>=20
>>may be needed; for data service like isdn UDI, conversion is not
>=20
> permitted.
>=20
>>Is there any method to solve this problem?
>>
>>Zhao Bo
>>
>>*****************************************************************
>>This e-mail and its attachments contain confidential information from
>>HUAWEI, which is intended only for the person or entity whose address i=
s
>>listed above. Any use of the information contained herein in any way
>>(including, but not limited to, total or partial disclosure,
>=20
> reproduction,
>=20
>>or dissemination) by persons other than the intended recipient(s) is
>>prohibited. If you receive this e-mail in error, please notify the send=
er
>>by phone or email immediately and delete it!
>>*****************************************************************
>>
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>
>>
>>
>>
>>
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
>>1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3=87 i=C3=
=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2=AD~=C5=A0=
=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2=A3=C3=B9=
=C5=BE=EF=A2=9D=C2=A7(
>=20
>=20
>=20
>=20

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


From exim@www1.ietf.org  Thu Feb 26 11:02:19 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21842
	for ; Thu, 26 Feb 2004 11:02:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwNxK-0000EY-Vb
	for megaco-archive@odin.ietf.org; Thu, 26 Feb 2004 11:01:53 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QG1kvQ000895
	for megaco-archive@odin.ietf.org; Thu, 26 Feb 2004 11:01:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwNxK-0000EM-Mv
	for megaco-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 11:01:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21825
	for ; Thu, 26 Feb 2004 11:01:42 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwNxI-0002su-00
	for megaco-web-archive@ietf.org; Thu, 26 Feb 2004 11:01:44 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwNwN-0002nC-00
	for megaco-web-archive@ietf.org; Thu, 26 Feb 2004 11:00:48 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwNvk-0002ha-00
	for megaco-web-archive@ietf.org; Thu, 26 Feb 2004 11:00:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwNvk-0008Jv-9x; Thu, 26 Feb 2004 11:00:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwNvM-0008EK-Uc
	for megaco@optimus.ietf.org; Thu, 26 Feb 2004 10:59:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21686
	for ; Thu, 26 Feb 2004 10:59:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwNvK-0002fj-00
	for megaco@ietf.org; Thu, 26 Feb 2004 10:59:42 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwNuS-0002a6-00
	for megaco@ietf.org; Thu, 26 Feb 2004 10:58:49 -0500
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwNtg-0002Of-00
	for megaco@ietf.org; Thu, 26 Feb 2004 10:58:00 -0500
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 i1QFvLY01433;
	Thu, 26 Feb 2004 10:57:22 -0500 (EST)
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 FS3C9KQZ; Thu, 26 Feb 2004 10:57:21 -0500
Received: from nortelnetworks.com (acart1ec.ca.nortel.com [47.129.129.121]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DBDZJLMX; Thu, 26 Feb 2004 10:57:22 -0500
Message-ID: <403E1760.2010903@nortelnetworks.com>
Date: Thu, 26 Feb 2004 10:57:20 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Albrecht.Schwarz@alcatel.de
CC: Zhao Bo , megaco@ietf.org
Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning;
 Re: [Megaco] Hairpin case A/u Law conversion
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by zcars0m9.nortelnetworks.com id i1QFvLY01433
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in my inter=
vention.=20
  My old draft has been allowed to expire because it did not seem to be o=
f much=20
interest to the community.

You are right: the draft just referred to doesn't apply to TDM, only to t=
he packet=20
side.  I wasn't thinking.  I agree that in the absence of the attributes =
provided=20
in my old draft, TDM bearer characteristics are assumed rather than signa=
lled=20
explicitly.

Albrecht.Schwarz@alcatel.de wrote:

> I think that the question is, whether this specific TDM bearer capabili=
ty
> should be (1) explicitly signalled, or whether (2) implicit assumption =
is
> already sufficient.
>=20
> With regard to (1), Tom, I guess that your refer to
>=20
> * RTP/CLEARMODE
>   RTP payload format for a 64 kbit/s transparent call
>   http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-04.t=
xt
>=20
> But, this coming RFC may not be directly applied, e.g., packetization t=
ime
> parameter isn't applicable IMHO. Pls correct me if wrong.
>=20
> Or do you refer to your proposals in your expired draft wrt
> * TDM/CLEARMODE
>   Conventions for the use of the Session Description Protocol (SDP)
>   for Digital Circuit Connections
>   http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01.txt
>=20
> My conclusion is, that an explicit signalling method doesn't exist toda=
y
> ("exception might be Q.1950").
> Even though, an explicit TDM Media Descriptor for I.231.1  might be hel=
pful
> for unambigously specification in certain MG implementations.
>=20
>=20
> With regard to (2):
> Implicit signaling is in my understanding the situation of today. In ca=
se
> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Media
> Descriptors with transparent channel indications", when a transparent
> 64-kbit/s bearer connection may be established.
> Sometimes this is also called "native TDM switching", or "native TDM
> hairpinning", but technically it is exactly representing an ISDN B chan=
nel
> with I.231.1 bearer service. [=3D> the channel may bypass the DSP, but =
in
> case that a DSP is looped-in, then must be the DSP channel operation mo=
de
> configured for 'Clearmode']
>=20
> Last comment:
> Such kind of implicit signalling mechanism is often assumed in telco
> industry, because this is the legacy signaling mechanism within a TDM
> switch ("if there aren't any signaled bearer capabilities then transpar=
ent
> channel; any needed bearer capability in addition must be explicitly
> signalled, like signal processing network equipment functions, e.g., EC=
").
>=20
> TDM hairpinning means, an "H.248-controlled TDM switching function" fro=
m
> H.248 Media Gateway perspective. Hence, this implicit signalling assump=
tion
> may be still valid, or do you see any needs for explicit signaling
> codepoints in case of TDM-to-TDM ISDN I.231.1 calls?
>=20
> Regards
>=20
> Albrecht
>=20
>=20
>=20
>=20
>=20
>=20
>                                                                        =
                                                                         =
   =20
>                       Tom Taylor                                       =
                                                                         =
   =20
>                                                                                       =
   =20
>                       tworks.com>              cc:      Albrecht SCHWAR=
Z/DE/ALCATEL@ALCATEL, megaco@ietf.org                                    =
   =20
>                                                Subject: Re: TDM Hairpin=
ning; Re: [Megaco] Hairpin case A/u Law conversion                       =
   =20
>                       26.02.2004 14:05                                 =
                                                                         =
   =20
>                                                                        =
                                                                         =
   =20
>                                                                        =
                                                                         =
   =20
>=20
>=20
>=20
>=20
> I think you would do it by specifying the CLEARMODE codec in the Local =
and
> Remote
> descriptors.  Unfortunately, CLEARMODE is still under consideration by =
the
> IESG
> and hasn't reached RFC status.
>=20
> Zhao Bo wrote:
>=20
>>Dear Albrecht:
>>    Is there any H.248 package defined to signal the UDI transparency
>=20
> properties in TDM hairping case?
>=20
>>    Best regards
>>
>>----- Original Message -----
>>From: 
>>To: "Zhao Bo" 
>>Cc: ; 
>>Sent: Wednesday, February 25, 2004 10:24 PM
>>Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion
>>
>>
>>
>>Dear Zhao Bo,
>>
>>because there isn't any "hairpinning" definition in MEGACOP/H.248
>=20
> standards
>=20
>>("please correct if I'm wrong"), I'd like to use the following one for
>>responding your questions:
>>
>>
>=20
> ***********************************************************************=
************
>=20
>=20
>>Definition:
>>TDM Hairpinning
>>? is a scenario whereby a call is being made between two TDM endpoints =
on
>=20
> a
>=20
>>    single media gateway. The media comes in on one TDM channel and goe=
s
>>    out on another TDM channel through the use of an internal loop in t=
he
>>    media gateway.
>>
>>Note 1: due to the fact that there are local call types at local
>=20
> exchanges
>=20
>>(CLASS5), and transit exchanges (CLASS4) in legacy TDM networks (PSTN,
>>NISDN, etc), there is a variety of TDM-to-TDM connection types behind t=
he
>>general "TDM hairpinning" capability (dependent on required type of IWF=
,
>>etc.) in corresponding H.248 MG types
>>
>>Note 2: H.248/MEGCOP perspective
>>TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM Terminations
>>
>=20
> ***********************************************************************=
*************
>=20
>=20
>>Based on this hairpinning understanding, my answers are:
>>
>>(1) Speech telephony service: G.711 companding formats are a property o=
f
>>the corresponding H.248 TDM termination
>>
>>[Note: dependent on MG architecture and implementation, property might =
be
>>signalled or preprovisioned. Of course, G.711 companding law is an
>=20
> inherent
>=20
>>property of your DS0 channel at your PDH/SDH/SONET framer; the way, how
>>this DS0 property is associated with the corresponding H.248 TDM
>>Termination property may only realized MG-internally for very specific =
MG
>>architectures. Generally it is up to the MGC, particularly if some (or
>=20
> all)
>=20
>>DS0's are ISDN B channels.]
>>
>>(2) Voiceband Data services: same as in (1)
>>
>>[Note: VBD according new ITU-T V.152 -> "... For purposes of
>>interoperability, a V.152 compliant implementation shall support at lea=
st
>>both G.711 A-law and G.711 =C3=AC-law codecs as VBD codecs. "]
>>
>>(3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer service
>>requirement
>>=3D> H.248 TDM Termination property must be signalled by MGC, if not, M=
G
>=20
> may
>=20
>>not guarantee UDI capability (i.e., fully transparent 64-kbit/s bearer
>>channel) in TDM hairpinning scenarios ...
>>
>>
>>Conclusion:
>>IF your MG is supporting
>>PSTN lines (=3D H.248 ALN Termination),
>>PSTN trunks (=3D H.248 TDM Termination), and
>>ISDN B channels (=3D H.248 TDM Termination)
>>
>>AND IF you've such services and interworking requirements
>>
>>THEN you should generally signal the corresponding properties ...
>>
>>... in case of
>>TDM hairpinning,
>>ALN hairpinning, or
>>ALN-to-TDM connection types.
>>
>>Regards,
>>Albrecht
>>
>>ALCATEL
>>
>>
>>
>>
>>
>=20
>=20
>>                      Zhao Bo
>=20
>=20
>>                               To:      megaco@ietf.org
>=20
>=20
>>                      Sent by:                 cc:
>=20
>=20
>>                      megaco-admin@iet         Subject: [Megaco] Hairpi=
n
>=20
> case A/u Law conversion
>=20
>>                      f.org
>=20
>=20
>=20
>=20
>>                      25.02.2004 08:11
>=20
>=20
>=20
>=20
>>
>>
>>
>>In this case, the A/u law format of a TDM ciruit can be provisioned,  b=
ut
>>the MG doesn't know the service type of a call, thus
>>has no way to know if a conversion is needed. For speech service
>=20
> conversion
>=20
>>may be needed; for data service like isdn UDI, conversion is not
>=20
> permitted.
>=20
>>Is there any method to solve this problem?
>>
>>Zhao Bo
>>
>>*****************************************************************
>>This e-mail and its attachments contain confidential information from
>>HUAWEI, which is intended only for the person or entity whose address i=
s
>>listed above. Any use of the information contained herein in any way
>>(including, but not limited to, total or partial disclosure,
>=20
> reproduction,
>=20
>>or dissemination) by persons other than the intended recipient(s) is
>>prohibited. If you receive this e-mail in error, please notify the send=
er
>>by phone or email immediately and delete it!
>>*****************************************************************
>>
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>
>>
>>
>>
>>
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
>>1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3=87 i=C3=
=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2=AD~=C5=A0=
=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2=A3=C3=B9=
=C5=BE=EF=A2=9D=C2=A7(
>=20
>=20
>=20
>=20

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



From megaco-admin@ietf.org  Thu Feb 26 11:37:29 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23324
	for ; Thu, 26 Feb 2004 11:37:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwOVR-0003Bc-Ex; Thu, 26 Feb 2004 11:37:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwOVA-0003At-Pa
	for megaco@optimus.ietf.org; Thu, 26 Feb 2004 11:36:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23321
	for ; Thu, 26 Feb 2004 11:36:41 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwOV9-0006Q1-00
	for megaco@ietf.org; Thu, 26 Feb 2004 11:36:43 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwOUE-0006LI-00
	for megaco@ietf.org; Thu, 26 Feb 2004 11:35:46 -0500
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwOTy-0006Fr-00
	for megaco@ietf.org; Thu, 26 Feb 2004 11:35:30 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1QGYnr08325
	for ; Thu, 26 Feb 2004 10:34:51 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA22093; Thu, 26 Feb 2004 11:34:31 -0500 (EST)
Cc: megaco@ietf.org
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA22084; Thu, 26 Feb 2004 11:34:30 -0500 (EST)
Message-ID: <403E2013.5000408@bell-labs.com>
Date: Thu, 26 Feb 2004 11:34:27 -0500
From: Troy Cauble 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Carl Rutter 
Original-CC: megaco@ietf.org
Subject: Re: [Megaco] SIP MEGACO interworking
References: 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit

Carl Rutter wrote:
> I have a question about dealing with differences between SIP and MEGACO
> SDP formats.  I noticed there was a similar thread about this not too long
> ago.
> http://www.ietf.org/mail-archive/working-groups/megaco/current/msg04724.html
> I believe it ended with the point that the MGC needed to do some massaging.
> 
> My specific issue is with T.38.   The "SIP Support for real-time Fax"
> document
> has 1 session with multiple media session-levels.  The T.38 document p34
> indicates the 
> media lines MUST be separated by a version descriptor.  Given the
> incompatible
> formats I believe the MGC must do some massaging.  
> Is this correct?
> Should the MG just handle both cases?
> Is there a SIP/MEGACO interworking document?
> 
> Thanks,
> Carl

I don't know about the T.38 question.  But I suspect that if you look 
very closely at the semantics of SDP usage in MEGACO and SIP, you'll 
find more basic reasons for an interworking MGC to massage the SDP. 
Sure, they both borrowed the SDP *syntax*... (Actually, MEGACO twists 
*that* pretty hard...)

I may be wrong.  I may be mixing in some MGCP interworking issues.  But 
I would look closely at.

Does the sending port have to be the receiving port?
Is the m=line a preference ordered list?
Am I expressing the list of codecs I'm willing to receive, or
willing to send and receive?
Must the payload types be the same in both directions?
Are the return SDP ("answer") codecs a subset of the initial SDP ("offer")?
How do you express putting a stream "on hold"?
How are multiple media streams an multiple sessions handled?
Do you have a=rtpmap lines for static payload types?

Doesn't MEGACO allow you to leave out whole lines that are required
in the SDP RFC and in SIP?



-troy

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


From exim@www1.ietf.org  Thu Feb 26 11:39:07 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23391
	for ; Thu, 26 Feb 2004 11:39:07 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwOX1-0003hX-1s
	for megaco-archive@odin.ietf.org; Thu, 26 Feb 2004 11:38:39 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QGcd73014226
	for megaco-archive@odin.ietf.org; Thu, 26 Feb 2004 11:38:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwOX0-0003hN-Lt
	for megaco-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 11:38:38 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23367
	for ; Thu, 26 Feb 2004 11:38:35 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwOWz-0006by-00
	for megaco-web-archive@ietf.org; Thu, 26 Feb 2004 11:38:37 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwOW9-0006V2-00
	for megaco-web-archive@ietf.org; Thu, 26 Feb 2004 11:37:46 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwOVR-0006Qh-00
	for megaco-web-archive@ietf.org; Thu, 26 Feb 2004 11:37:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwOVR-0003Bc-Ex; Thu, 26 Feb 2004 11:37:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwOVA-0003At-Pa
	for megaco@optimus.ietf.org; Thu, 26 Feb 2004 11:36:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23321
	for ; Thu, 26 Feb 2004 11:36:41 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwOV9-0006Q1-00
	for megaco@ietf.org; Thu, 26 Feb 2004 11:36:43 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwOUE-0006LI-00
	for megaco@ietf.org; Thu, 26 Feb 2004 11:35:46 -0500
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwOTy-0006Fr-00
	for megaco@ietf.org; Thu, 26 Feb 2004 11:35:30 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1QGYnr08325
	for ; Thu, 26 Feb 2004 10:34:51 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA22093; Thu, 26 Feb 2004 11:34:31 -0500 (EST)
Cc: megaco@ietf.org
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA22084; Thu, 26 Feb 2004 11:34:30 -0500 (EST)
Message-ID: <403E2013.5000408@bell-labs.com>
Date: Thu, 26 Feb 2004 11:34:27 -0500
From: Troy Cauble 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Carl Rutter 
Original-CC: megaco@ietf.org
Subject: Re: [Megaco] SIP MEGACO interworking
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: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Carl Rutter wrote:
> I have a question about dealing with differences between SIP and MEGACO
> SDP formats.  I noticed there was a similar thread about this not too long
> ago.
> http://www.ietf.org/mail-archive/working-groups/megaco/current/msg04724.html
> I believe it ended with the point that the MGC needed to do some massaging.
> 
> My specific issue is with T.38.   The "SIP Support for real-time Fax"
> document
> has 1 session with multiple media session-levels.  The T.38 document p34
> indicates the 
> media lines MUST be separated by a version descriptor.  Given the
> incompatible
> formats I believe the MGC must do some massaging.  
> Is this correct?
> Should the MG just handle both cases?
> Is there a SIP/MEGACO interworking document?
> 
> Thanks,
> Carl

I don't know about the T.38 question.  But I suspect that if you look 
very closely at the semantics of SDP usage in MEGACO and SIP, you'll 
find more basic reasons for an interworking MGC to massage the SDP. 
Sure, they both borrowed the SDP *syntax*... (Actually, MEGACO twists 
*that* pretty hard...)

I may be wrong.  I may be mixing in some MGCP interworking issues.  But 
I would look closely at.

Does the sending port have to be the receiving port?
Is the m=line a preference ordered list?
Am I expressing the list of codecs I'm willing to receive, or
willing to send and receive?
Must the payload types be the same in both directions?
Are the return SDP ("answer") codecs a subset of the initial SDP ("offer")?
How do you express putting a stream "on hold"?
How are multiple media streams an multiple sessions handled?
Do you have a=rtpmap lines for static payload types?

Doesn't MEGACO allow you to leave out whole lines that are required
in the SDP RFC and in SIP?



-troy

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



From megaco-admin@ietf.org  Fri Feb 27 01:44:31 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02679
	for ; Fri, 27 Feb 2004 01:44:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Awbj7-0006dd-FH; Fri, 27 Feb 2004 01:44:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwbiN-0006bP-Mt
	for megaco@optimus.ietf.org; Fri, 27 Feb 2004 01:43:15 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02614
	for ; Fri, 27 Feb 2004 01:43:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwbiK-00013R-00
	for megaco@ietf.org; Fri, 27 Feb 2004 01:43:12 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwbhP-0000xU-00
	for megaco@ietf.org; Fri, 27 Feb 2004 01:42:16 -0500
Received: from eagle.ericsson.se ([193.180.251.53])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwbgV-0000rd-00
	for megaco@ietf.org; Fri, 27 Feb 2004 01:41:20 -0500
Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1R6fKAh000701
	for ; Fri, 27 Feb 2004 07:41:20 +0100
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Fri, 27 Feb 2004 07:41:20 +0100
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id ; Fri, 27 Feb 2004 07:41:42 +0100
Message-ID: 
From: "Christer Holmberg (JO/LMF)" 
To: "'Troy Cauble'" , Carl Rutter 
Cc: megaco@ietf.org
Subject: RE: [Megaco] SIP MEGACO interworking
Date: Fri, 27 Feb 2004 07:41:08 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 27 Feb 2004 06:41:20.0610 (UTC) FILETIME=[B5A73C20:01C3FCFC]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	


Hi,

Comments inline ([CHH])

>Carl Rutter wrote:
>>I have a question about dealing with differences between 
>>SIP and MEGACO SDP formats.  I noticed there was a similar thread about 
>>this not too long ago.
>> 
>>http://www.ietf.org/mail-archive/working-groups/megaco/currentmsg04724.html
>>I believe it ended with the point that the MGC needed to do 
>>some massaging.
>> 
>>My specific issue is with T.38.   The "SIP Support for 
>>real-time Fax" document has 1 session with multiple media session-levels.  The T.38 
>>document p34 indicates the media lines MUST be separated by a version descriptor.  Given the
>>incompatible formats I believe the MGC must do some massaging.  
>>Is this correct?
>>Should the MG just handle both cases?
>>Is there a SIP/MEGACO interworking document?
>I don't know about the T.38 question.  But I suspect that if you look 
>very closely at the semantics of SDP usage in MEGACO and SIP, you'll 
>find more basic reasons for an interworking MGC to massage the SDP. 
>Sure, they both borrowed the SDP *syntax*... (Actually, MEGACO twists 
>*that* pretty hard...)

[CHH] In H.248 you must, as you said, separate the m= lines (one for audio, one for t38 fax) with v= lines. In SIP you don't have to do that (you can have multiple m= lines under a single v= line) so your controller will have to do some SDP "restructuring".

[CHH] Having said that, the H.248 spec actually at one point does say that a node shall be able to handle a RFC2327 compliant SDP (which could mean multiple m= lines), which I think is a little confusing. However, we shall remember that this is not the only way where H.248 diverts from the SDP standard, and the H.248 does specify those things. There has been discussions if/how things related to the H.248 SDP handling could be clarified, though.
 
>Does the sending port have to be the receiving port?

[CHH] I don't think that the H.248 spec (nor the SDP spec) specifies that. I know that many nodes do, and eg the G.799.1 media gateway spec requires it.

>Is the m=line a preference ordered list?
>Am I expressing the list of codecs I'm willing to receive, or
>willing to send and receive?

[CHH] In H.248 I believe you are specifying the codecs you want to "reserve resources" for, and the mode property then indicates the media direction. In SDP you indicate which codecs you are able to receive (which, in practic, mostly also means the codecs you are able to send). Please note that H.248 uses SDP for "controlling" another node, and not only for offer/answer two-party negotiation.

>Must the payload types be the same in both directions?

[CHH] This issue came up at a SIPit interop event once, and the answer was no.

>Are the return SDP ("answer") codecs a subset of the initial 
>SDP ("offer")?

[CHH] Yes, and you use the ReserveValue property to indicate if you want to use one or as-many-as-possible of the given codecs.

>How do you express putting a stream "on hold"?

[CHH] That depends on where you are situated in the network, I think. "On hold" is pretty much a signalling thing, and if a node receives a "hold" indicator, and is required to eg do something specific with the media, it may use H.248 to do whatever it has to do. I see no reason to define specific H.248 "hold behaviour".

>How are multiple media streams an multiple sessions handled?

[CHH] Could you please clarify? :)

>Do you have a=rtpmap lines for static payload types?

[CHH] You can have, but you're not required to. That is basic SDP, and H.248 doesn't change that behaviour.

>Doesn't MEGACO allow you to leave out whole lines that are required in the SDP RFC and in SIP?

[CHH] Yes, and that is defined in the spec.

[CHH] The SDP issue has been discussed on the list, and at meetings, and as I said earlier, people are looking into if/how things could be clarified, including the SDP "interworking" between protocols like H.248 and SIP.

Regards,

Christer Holmberg
Ericsson Finland



This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.


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


From exim@www1.ietf.org  Fri Feb 27 01:46:36 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02814
	for ; Fri, 27 Feb 2004 01:46:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwblA-0006nE-3t
	for megaco-archive@odin.ietf.org; Fri, 27 Feb 2004 01:46:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R6k8MY026106
	for megaco-archive@odin.ietf.org; Fri, 27 Feb 2004 01:46:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Awbl9-0006mz-Vy
	for megaco-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 01:46:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02738
	for ; Fri, 27 Feb 2004 01:46:05 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Awbl6-0001OD-00
	for megaco-web-archive@ietf.org; Fri, 27 Feb 2004 01:46:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Awbk6-0001FQ-00
	for megaco-web-archive@ietf.org; Fri, 27 Feb 2004 01:45:03 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Awbj7-00018k-00
	for megaco-web-archive@ietf.org; Fri, 27 Feb 2004 01:44:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Awbj7-0006dd-FH; Fri, 27 Feb 2004 01:44:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwbiN-0006bP-Mt
	for megaco@optimus.ietf.org; Fri, 27 Feb 2004 01:43:15 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02614
	for ; Fri, 27 Feb 2004 01:43:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwbiK-00013R-00
	for megaco@ietf.org; Fri, 27 Feb 2004 01:43:12 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwbhP-0000xU-00
	for megaco@ietf.org; Fri, 27 Feb 2004 01:42:16 -0500
Received: from eagle.ericsson.se ([193.180.251.53])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwbgV-0000rd-00
	for megaco@ietf.org; Fri, 27 Feb 2004 01:41:20 -0500
Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1R6fKAh000701
	for ; Fri, 27 Feb 2004 07:41:20 +0100
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Fri, 27 Feb 2004 07:41:20 +0100
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id ; Fri, 27 Feb 2004 07:41:42 +0100
Message-ID: 
From: "Christer Holmberg (JO/LMF)" 
To: "'Troy Cauble'" , Carl Rutter 
Cc: megaco@ietf.org
Subject: RE: [Megaco] SIP MEGACO interworking
Date: Fri, 27 Feb 2004 07:41:08 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 27 Feb 2004 06:41:20.0610 (UTC) FILETIME=[B5A73C20:01C3FCFC]
Sender: megaco-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: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60


Hi,

Comments inline ([CHH])

>Carl Rutter wrote:
>>I have a question about dealing with differences between 
>>SIP and MEGACO SDP formats.  I noticed there was a similar thread about 
>>this not too long ago.
>> 
>>http://www.ietf.org/mail-archive/working-groups/megaco/currentmsg04724.html
>>I believe it ended with the point that the MGC needed to do 
>>some massaging.
>> 
>>My specific issue is with T.38.   The "SIP Support for 
>>real-time Fax" document has 1 session with multiple media session-levels.  The T.38 
>>document p34 indicates the media lines MUST be separated by a version descriptor.  Given the
>>incompatible formats I believe the MGC must do some massaging.  
>>Is this correct?
>>Should the MG just handle both cases?
>>Is there a SIP/MEGACO interworking document?
>I don't know about the T.38 question.  But I suspect that if you look 
>very closely at the semantics of SDP usage in MEGACO and SIP, you'll 
>find more basic reasons for an interworking MGC to massage the SDP. 
>Sure, they both borrowed the SDP *syntax*... (Actually, MEGACO twists 
>*that* pretty hard...)

[CHH] In H.248 you must, as you said, separate the m= lines (one for audio, one for t38 fax) with v= lines. In SIP you don't have to do that (you can have multiple m= lines under a single v= line) so your controller will have to do some SDP "restructuring".

[CHH] Having said that, the H.248 spec actually at one point does say that a node shall be able to handle a RFC2327 compliant SDP (which could mean multiple m= lines), which I think is a little confusing. However, we shall remember that this is not the only way where H.248 diverts from the SDP standard, and the H.248 does specify those things. There has been discussions if/how things related to the H.248 SDP handling could be clarified, though.
 
>Does the sending port have to be the receiving port?

[CHH] I don't think that the H.248 spec (nor the SDP spec) specifies that. I know that many nodes do, and eg the G.799.1 media gateway spec requires it.

>Is the m=line a preference ordered list?
>Am I expressing the list of codecs I'm willing to receive, or
>willing to send and receive?

[CHH] In H.248 I believe you are specifying the codecs you want to "reserve resources" for, and the mode property then indicates the media direction. In SDP you indicate which codecs you are able to receive (which, in practic, mostly also means the codecs you are able to send). Please note that H.248 uses SDP for "controlling" another node, and not only for offer/answer two-party negotiation.

>Must the payload types be the same in both directions?

[CHH] This issue came up at a SIPit interop event once, and the answer was no.

>Are the return SDP ("answer") codecs a subset of the initial 
>SDP ("offer")?

[CHH] Yes, and you use the ReserveValue property to indicate if you want to use one or as-many-as-possible of the given codecs.

>How do you express putting a stream "on hold"?

[CHH] That depends on where you are situated in the network, I think. "On hold" is pretty much a signalling thing, and if a node receives a "hold" indicator, and is required to eg do something specific with the media, it may use H.248 to do whatever it has to do. I see no reason to define specific H.248 "hold behaviour".

>How are multiple media streams an multiple sessions handled?

[CHH] Could you please clarify? :)

>Do you have a=rtpmap lines for static payload types?

[CHH] You can have, but you're not required to. That is basic SDP, and H.248 doesn't change that behaviour.

>Doesn't MEGACO allow you to leave out whole lines that are required in the SDP RFC and in SIP?

[CHH] Yes, and that is defined in the spec.

[CHH] The SDP issue has been discussed on the list, and at meetings, and as I said earlier, people are looking into if/how things could be clarified, including the SDP "interworking" between protocols like H.248 and SIP.

Regards,

Christer Holmberg
Ericsson Finland



This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.


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



From megaco-admin@ietf.org  Fri Feb 27 07:48:33 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28626
	for ; Fri, 27 Feb 2004 07:48:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwhPN-0007ff-OO; Fri, 27 Feb 2004 07:48:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwhOe-0007eT-5f
	for megaco@optimus.ietf.org; Fri, 27 Feb 2004 07:47:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28579
	for ; Fri, 27 Feb 2004 07:47:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwhOc-0007Nq-00
	for megaco@ietf.org; Fri, 27 Feb 2004 07:47:14 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwhNe-0007H7-00
	for megaco@ietf.org; Fri, 27 Feb 2004 07:46:15 -0500
Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwhMl-00076K-00
	for megaco@ietf.org; Fri, 27 Feb 2004 07:45:20 -0500
Received: from z14593 (huawei.com [172.17.1.60])
 by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14
 2003)) with ESMTPA id <0HTQ007V3TMXKV@mta1.huawei.com> for megaco@ietf.org;
 Fri, 27 Feb 2004 20:35:22 +0800 (CST)
Date: Fri, 27 Feb 2004 20:44:45 +0800
From: Zhao Bo 
Subject: Re: [Megaco] Questions about H.248.17
 "line test packages"(upgrade,sorry, my poor English)
To: Christian Groves 
Cc: megaco@ietf.org
Message-id: <000401c3fd2f$7b2023e0$f8486e0a@HUAWEI.COM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <000b01c3f9ee$ea987ae0$f8486e0a@HUAWEI.COM>
 <403A8743.6000402@ericsson.com>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7BIT
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7BIT

Hi Chrisitan:
    I studied a simple procedure as follow:

    (1)Testee MG is set to  loopback;
    (2)Tester sends a 1020Hz tone to  testee;
    (3)Tester receive the loopbacked tone, analyze the quality of tone and output a report.

    Suppose the Tester is embeded in MGW. In H.248.17 structure,  the procedure will be.
    (1)Testee MGC set the Testee MGW to loopback.
    (2)Tester MGC signals the Tester to send  1020Hz tone;
    (3)Someone ask Tester MGW to receive loopback tone and make analysis.
    (4)MGW output a report to this "someone".

    Maybe you think O&M should be that "Someone"?  If my understanding is right--in same procedure O&M and  MGC will operate same termination, I think that's quite strange:-)
    
    Best regards
    

----- Original Message ----- 
From: "Christian Groves" 
To: "Zhao Bo" 
Cc: 
Sent: Tuesday, February 24, 2004 7:05 AM
Subject: Re: [Megaco] Questions about H.248.17 "line test packages"(upgrade,sorry, my poor English)


> Hello Zhao,
> 
> I'm the editor of H.248.17. Please see my replies below marked [CHG].
> 
> Regards, Christian
> 
> Zhao Bo wrote:
> 
> > Could anyone kindly answer the following questions (I can't find the author's email address in H.248.17 text).
> > 
> > 1. Section 1 "Scope" says:
> > "The detailing of results that are reported (e.g. events and statistics), as well as the timing and mechanisms used for
> > transmitting such records from the MG to the MGC"
> > Why? If a test is initiated by MGC, why not define a protocol to send the measuring result back to MGC?
> 
> [CHG] As the results are related to the physical characteristics of the bearer 
> and not usually interesting to a MGC it was seen that a protocol other than 
> H.248 (or even internal O&M of the MG) was more suitable for this information.
> 
> > 
> > 2.If we have two switch connected with temination T1 and T2
> >     SW1--T1-------T2--SW2
> > Shall the H.248 signal be apllied to T1 and T2, or some extra termination, for example T3 or T4 in the following scenerio:
> > T3--SW1--T1-------T2--SW2--T4
> 
> [CHG] Depends on what you want to test. If all you want to test is the link 
> between T1 and T2 then you only apply signals between T1 & T2.
> 
> > 
> > 3. Section 7.1.1 says:
> > "ITU-T Rec. O.11 describes test responder behaviour. For a description of this behaviour see
> > clause 9."
> > But neither O.11 nor H.247.17 text has a clause 9?
> 
> [CHG] Please see the latest implementors guide for the correction.
> 
> > 
> > Best regards
> > 
> > Zhao Bo
> > 
> > 
> > Zhao Bo
> > 
> > *****************************************************************
> > This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
> > *****************************************************************
> > 
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> > 
> 
> 
> This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco

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


From exim@www1.ietf.org  Fri Feb 27 07:49:59 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28666
	for ; Fri, 27 Feb 2004 07:49:59 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwhQm-0007o1-NC
	for megaco-archive@odin.ietf.org; Fri, 27 Feb 2004 07:49:30 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RCnSp3030001
	for megaco-archive@odin.ietf.org; Fri, 27 Feb 2004 07:49:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwhQm-0007nl-HE
	for megaco-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 07:49:28 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28663
	for ; Fri, 27 Feb 2004 07:49:26 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwhQl-0007br-00
	for megaco-web-archive@ietf.org; Fri, 27 Feb 2004 07:49:27 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwhPm-0007WF-00
	for megaco-web-archive@ietf.org; Fri, 27 Feb 2004 07:48:27 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwhPQ-0007QW-00
	for megaco-web-archive@ietf.org; Fri, 27 Feb 2004 07:48:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwhPN-0007ff-OO; Fri, 27 Feb 2004 07:48:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AwhOe-0007eT-5f
	for megaco@optimus.ietf.org; Fri, 27 Feb 2004 07:47:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28579
	for ; Fri, 27 Feb 2004 07:47:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwhOc-0007Nq-00
	for megaco@ietf.org; Fri, 27 Feb 2004 07:47:14 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AwhNe-0007H7-00
	for megaco@ietf.org; Fri, 27 Feb 2004 07:46:15 -0500
Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AwhMl-00076K-00
	for megaco@ietf.org; Fri, 27 Feb 2004 07:45:20 -0500
Received: from z14593 (huawei.com [172.17.1.60])
 by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14
 2003)) with ESMTPA id <0HTQ007V3TMXKV@mta1.huawei.com> for megaco@ietf.org;
 Fri, 27 Feb 2004 20:35:22 +0800 (CST)
Date: Fri, 27 Feb 2004 20:44:45 +0800
From: Zhao Bo 
Subject: Re: [Megaco] Questions about H.248.17
 "line test packages"(upgrade,sorry, my poor English)
To: Christian Groves 
Cc: megaco@ietf.org
Message-id: <000401c3fd2f$7b2023e0$f8486e0a@HUAWEI.COM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <000b01c3f9ee$ea987ae0$f8486e0a@HUAWEI.COM>
 <403A8743.6000402@ericsson.com>
Content-Transfer-Encoding: 7BIT
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Hi Chrisitan:
    I studied a simple procedure as follow:

    (1)Testee MG is set to  loopback;
    (2)Tester sends a 1020Hz tone to  testee;
    (3)Tester receive the loopbacked tone, analyze the quality of tone and output a report.

    Suppose the Tester is embeded in MGW. In H.248.17 structure,  the procedure will be.
    (1)Testee MGC set the Testee MGW to loopback.
    (2)Tester MGC signals the Tester to send  1020Hz tone;
    (3)Someone ask Tester MGW to receive loopback tone and make analysis.
    (4)MGW output a report to this "someone".

    Maybe you think O&M should be that "Someone"?  If my understanding is right--in same procedure O&M and  MGC will operate same termination, I think that's quite strange:-)
    
    Best regards
    

----- Original Message ----- 
From: "Christian Groves" 
To: "Zhao Bo" 
Cc: 
Sent: Tuesday, February 24, 2004 7:05 AM
Subject: Re: [Megaco] Questions about H.248.17 "line test packages"(upgrade,sorry, my poor English)


> Hello Zhao,
> 
> I'm the editor of H.248.17. Please see my replies below marked [CHG].
> 
> Regards, Christian
> 
> Zhao Bo wrote:
> 
> > Could anyone kindly answer the following questions (I can't find the author's email address in H.248.17 text).
> > 
> > 1. Section 1 "Scope" says:
> > "The detailing of results that are reported (e.g. events and statistics), as well as the timing and mechanisms used for
> > transmitting such records from the MG to the MGC"
> > Why? If a test is initiated by MGC, why not define a protocol to send the measuring result back to MGC?
> 
> [CHG] As the results are related to the physical characteristics of the bearer 
> and not usually interesting to a MGC it was seen that a protocol other than 
> H.248 (or even internal O&M of the MG) was more suitable for this information.
> 
> > 
> > 2.If we have two switch connected with temination T1 and T2
> >     SW1--T1-------T2--SW2
> > Shall the H.248 signal be apllied to T1 and T2, or some extra termination, for example T3 or T4 in the following scenerio:
> > T3--SW1--T1-------T2--SW2--T4
> 
> [CHG] Depends on what you want to test. If all you want to test is the link 
> between T1 and T2 then you only apply signals between T1 & T2.
> 
> > 
> > 3. Section 7.1.1 says:
> > "ITU-T Rec. O.11 describes test responder behaviour. For a description of this behaviour see
> > clause 9."
> > But neither O.11 nor H.247.17 text has a clause 9?
> 
> [CHG] Please see the latest implementors guide for the correction.
> 
> > 
> > Best regards
> > 
> > Zhao Bo
> > 
> > 
> > Zhao Bo
> > 
> > *****************************************************************
> > This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
> > *****************************************************************
> > 
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> > 
> 
> 
> This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
> 
> 
> _______________________________________________
> 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  Sun Feb 29 18:57:28 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16829
	for ; Sun, 29 Feb 2004 18:57:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Axans-0007N8-Sc; Sun, 29 Feb 2004 18:57:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Axan9-0007MG-Iq
	for megaco@optimus.ietf.org; Sun, 29 Feb 2004 18:56:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16801
	for ; Sun, 29 Feb 2004 18:56:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Axan6-0007NW-00
	for megaco@ietf.org; Sun, 29 Feb 2004 18:56:12 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AxamB-0007Jf-00
	for megaco@ietf.org; Sun, 29 Feb 2004 18:55:17 -0500
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AxalW-0007Fd-00
	for megaco@ietf.org; Sun, 29 Feb 2004 18:54:34 -0500
Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118])
	by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1TNsSYG005720
	for ; Mon, 1 Mar 2004 00:54:28 +0100 (MET)
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Mon, 1 Mar 2004 00:54:28 +0100
Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id FYF7DGJ3; Mon, 1 Mar 2004 00:54:28 +0100
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.252]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id FHQ5K2VW; Mon, 1 Mar 2004 10:53:35 +1100
Message-ID: <40427B92.3000707@ericsson.com>
Date: Mon, 01 Mar 2004 10:53:54 +1100
X-Sybari-Trust: 9bb19359 c77f3eb6 614305f2 00000138
From: Christian Groves 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tom Taylor 
CC: Albrecht.Schwarz@alcatel.de, Zhao Bo , megaco@ietf.org
Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning;
 Re: [Megaco] Hairpin case A/u Law conversion
References:  <403E1760.2010903@nortelnetworks.com>
In-Reply-To: <403E1760.2010903@nortelnetworks.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
X-OriginalArrivalTime: 29 Feb 2004 23:54:28.0573 (UTC) FILETIME=[5E2F40D0:01C3FF1F]
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by penguin-ext.wise.edt.ericsson.se id i1TNsSYG005720
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: quoted-printable

Hello Tom and Albrecht,

What peice of information do you want to signal explicitely? Doesn't TMR =
allow=20
you to specify 64Kbit UDI? If so then its supported by H.248.1 Annex C.9.=
 For=20
H.248 text users this (or any element in Annex C) can be tranferred via=20
H.248.15. Alternatively Q.1950 sect 5.7.1.2 specifies an equivalent encod=
ing.

Regards, Christian

Tom Taylor wrote:

> I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in my=20
> intervention.  My old draft has been allowed to expire because it did=20
> not seem to be of much interest to the community.
>=20
> You are right: the draft just referred to doesn't apply to TDM, only to=
=20
> the packet side.  I wasn't thinking.  I agree that in the absence of th=
e=20
> attributes provided in my old draft, TDM bearer characteristics are=20
> assumed rather than signalled explicitly.
>=20
> Albrecht.Schwarz@alcatel.de wrote:
>=20
>> I think that the question is, whether this specific TDM bearer capabil=
ity
>> should be (1) explicitly signalled, or whether (2) implicit assumption=
 is
>> already sufficient.
>>
>> With regard to (1), Tom, I guess that your refer to
>>
>> * RTP/CLEARMODE
>>   RTP payload format for a 64 kbit/s transparent call
>>   http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-04.=
txt
>>
>> But, this coming RFC may not be directly applied, e.g., packetization=20
>> time
>> parameter isn't applicable IMHO. Pls correct me if wrong.
>>
>> Or do you refer to your proposals in your expired draft wrt
>> * TDM/CLEARMODE
>>   Conventions for the use of the Session Description Protocol (SDP)
>>   for Digital Circuit Connections
>>   http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01.tx=
t
>>
>> My conclusion is, that an explicit signalling method doesn't exist tod=
ay
>> ("exception might be Q.1950").
>> Even though, an explicit TDM Media Descriptor for I.231.1  might be=20
>> helpful
>> for unambigously specification in certain MG implementations.
>>
>>
>> With regard to (2):
>> Implicit signaling is in my understanding the situation of today. In c=
ase
>> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Media
>> Descriptors with transparent channel indications", when a transparent
>> 64-kbit/s bearer connection may be established.
>> Sometimes this is also called "native TDM switching", or "native TDM
>> hairpinning", but technically it is exactly representing an ISDN B=20
>> channel
>> with I.231.1 bearer service. [=3D> the channel may bypass the DSP, but=
 in
>> case that a DSP is looped-in, then must be the DSP channel operation m=
ode
>> configured for 'Clearmode']
>>
>> Last comment:
>> Such kind of implicit signalling mechanism is often assumed in telco
>> industry, because this is the legacy signaling mechanism within a TDM
>> switch ("if there aren't any signaled bearer capabilities then=20
>> transparent
>> channel; any needed bearer capability in addition must be explicitly
>> signalled, like signal processing network equipment functions, e.g.,=20
>> EC").
>>
>> TDM hairpinning means, an "H.248-controlled TDM switching function" fr=
om
>> H.248 Media Gateway perspective. Hence, this implicit signalling=20
>> assumption
>> may be still valid, or do you see any needs for explicit signaling
>> codepoints in case of TDM-to-TDM ISDN I.231.1 calls?
>>
>> Regards
>>
>> Albrecht
>>
>>
>>
>>
>>
>>
>>                                                                       =
                                                                         =
    =20
>>                       Tom=20
>> Taylor                                                                =
                                                   =20
>>                       >                                                       =
             =20
>>                       tworks.com>              cc:      Albrecht=20
>> SCHWARZ/DE/ALCATEL@ALCATEL,=20
>> megaco@ietf.org                                       =20
>>                                                Subject: Re: TDM=20
>> Hairpinning; Re: [Megaco] Hairpin case A/u Law=20
>> conversion                                                 26.02.2004=20
>> 14:05                                                                 =
                                            =20
>>                                                                       =
                                                                         =
    =20
>>                                                                       =
                                                                         =
    =20
>>
>>
>>
>>
>> I think you would do it by specifying the CLEARMODE codec in the Local=
=20
>> and
>> Remote
>> descriptors.  Unfortunately, CLEARMODE is still under consideration by=
=20
>> the
>> IESG
>> and hasn't reached RFC status.
>>
>> Zhao Bo wrote:
>>
>>> Dear Albrecht:
>>>    Is there any H.248 package defined to signal the UDI transparency
>>
>>
>> properties in TDM hairping case?
>>
>>>    Best regards
>>>
>>> ----- Original Message -----
>>> From: 
>>> To: "Zhao Bo" 
>>> Cc: ; 
>>> Sent: Wednesday, February 25, 2004 10:24 PM
>>> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversio=
n
>>>
>>>
>>>
>>> Dear Zhao Bo,
>>>
>>> because there isn't any "hairpinning" definition in MEGACOP/H.248
>>
>>
>> standards
>>
>>> ("please correct if I'm wrong"), I'd like to use the following one fo=
r
>>> responding your questions:
>>>
>>>
>>
>> **********************************************************************=
*************=20
>>
>>
>>
>>> Definition:
>>> TDM Hairpinning
>>> ? is a scenario whereby a call is being made between two TDM=20
>>> endpoints on
>>
>>
>> a
>>
>>>    single media gateway. The media comes in on one TDM channel and go=
es
>>>    out on another TDM channel through the use of an internal loop in =
the
>>>    media gateway.
>>>
>>> Note 1: due to the fact that there are local call types at local
>>
>>
>> exchanges
>>
>>> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks (PSTN=
,
>>> NISDN, etc), there is a variety of TDM-to-TDM connection types behind=
=20
>>> the
>>> general "TDM hairpinning" capability (dependent on required type of I=
WF,
>>> etc.) in corresponding H.248 MG types
>>>
>>> Note 2: H.248/MEGCOP perspective
>>> TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM Termination=
s
>>>
>>
>> **********************************************************************=
**************=20
>>
>>
>>
>>> Based on this hairpinning understanding, my answers are:
>>>
>>> (1) Speech telephony service: G.711 companding formats are a property=
 of
>>> the corresponding H.248 TDM termination
>>>
>>> [Note: dependent on MG architecture and implementation, property=20
>>> might be
>>> signalled or preprovisioned. Of course, G.711 companding law is an
>>
>>
>> inherent
>>
>>> property of your DS0 channel at your PDH/SDH/SONET framer; the way, h=
ow
>>> this DS0 property is associated with the corresponding H.248 TDM
>>> Termination property may only realized MG-internally for very=20
>>> specific MG
>>> architectures. Generally it is up to the MGC, particularly if some (o=
r
>>
>>
>> all)
>>
>>> DS0's are ISDN B channels.]
>>>
>>> (2) Voiceband Data services: same as in (1)
>>>
>>> [Note: VBD according new ITU-T V.152 -> "... For purposes of
>>> interoperability, a V.152 compliant implementation shall support at=20
>>> least
>>> both G.711 A-law and G.711 =C3=AC-law codecs as VBD codecs. "]
>>>
>>> (3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer servic=
e
>>> requirement
>>> =3D> H.248 TDM Termination property must be signalled by MGC, if not,=
 MG
>>
>>
>> may
>>
>>> not guarantee UDI capability (i.e., fully transparent 64-kbit/s beare=
r
>>> channel) in TDM hairpinning scenarios ...
>>>
>>>
>>> Conclusion:
>>> IF your MG is supporting
>>> PSTN lines (=3D H.248 ALN Termination),
>>> PSTN trunks (=3D H.248 TDM Termination), and
>>> ISDN B channels (=3D H.248 TDM Termination)
>>>
>>> AND IF you've such services and interworking requirements
>>>
>>> THEN you should generally signal the corresponding properties ...
>>>
>>> ... in case of
>>> TDM hairpinning,
>>> ALN hairpinning, or
>>> ALN-to-TDM connection types.
>>>
>>> Regards,
>>> Albrecht
>>>
>>> ALCATEL
>>>
>>>
>>>
>>>
>>>
>>
>>
>>>                      Zhao Bo
>>
>>
>>
>>>                               To:      megaco@ietf.or=
g
>>
>>
>>
>>>                      Sent by:                 cc:
>>
>>
>>
>>>                      megaco-admin@iet         Subject: [Megaco] Hairp=
in
>>
>>
>> case A/u Law conversion
>>
>>>                      f.org
>>
>>
>>
>>
>>
>>>                      25.02.2004 08:11
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>> In this case, the A/u law format of a TDM ciruit can be provisioned, =
=20
>>> but
>>> the MG doesn't know the service type of a call, thus
>>> has no way to know if a conversion is needed. For speech service
>>
>>
>> conversion
>>
>>> may be needed; for data service like isdn UDI, conversion is not
>>
>>
>> permitted.
>>
>>> Is there any method to solve this problem?
>>>
>>> Zhao Bo
>>>
>>> *****************************************************************
>>> This e-mail and its attachments contain confidential information from
>>> HUAWEI, which is intended only for the person or entity whose address=
 is
>>> listed above. Any use of the information contained herein in any way
>>> (including, but not limited to, total or partial disclosure,
>>
>>
>> reproduction,
>>
>>> or dissemination) by persons other than the intended recipient(s) is
>>> prohibited. If you receive this e-mail in error, please notify the=20
>>> sender
>>> by phone or email immediately and delete it!
>>> *****************************************************************
>>>
>>> _______________________________________________
>>> Megaco mailing list
>>> Megaco@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Megaco mailing list
>>> Megaco@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/megaco
>>> 1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3=87 i=
=C3=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2=AD~=C5=
=A0=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2=A3=C3=
=B9=C5=BE=EF=A2=9D=C2=A7(
>>
>>
>>
>>
>>
>=20
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>=20


This communication is confidential and intended solely for the addressee(=
s). Any unauthorized review, use, disclosure or distribution is prohibite=
d. If you believe this message has been sent to you in error, please noti=
fy the sender by replying to this transmission and delete the message wit=
hout disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interrupt=
ion, unauthorized amendment, tampering and viruses, and we only send and =
receive e-mails on the basis that we are not liable for any such corrupti=
on, interception, amendment, tampering or viruses or any consequences the=
reof.


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


From exim@www1.ietf.org  Sun Feb 29 18:58:43 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16918
	for ; Sun, 29 Feb 2004 18:58:43 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Axap4-0007Rc-Sy
	for megaco-archive@odin.ietf.org; Sun, 29 Feb 2004 18:58:17 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TNwECF028615
	for megaco-archive@odin.ietf.org; Sun, 29 Feb 2004 18:58:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Axap4-0007RS-P9
	for megaco-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 18:58:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16879
	for ; Sun, 29 Feb 2004 18:58:10 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Axap1-0007XE-00
	for megaco-web-archive@ietf.org; Sun, 29 Feb 2004 18:58:11 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Axao9-0007So-00
	for megaco-web-archive@ietf.org; Sun, 29 Feb 2004 18:57:18 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Axans-0007Om-00
	for megaco-web-archive@ietf.org; Sun, 29 Feb 2004 18:57:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Axans-0007N8-Sc; Sun, 29 Feb 2004 18:57:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Axan9-0007MG-Iq
	for megaco@optimus.ietf.org; Sun, 29 Feb 2004 18:56:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16801
	for ; Sun, 29 Feb 2004 18:56:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Axan6-0007NW-00
	for megaco@ietf.org; Sun, 29 Feb 2004 18:56:12 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AxamB-0007Jf-00
	for megaco@ietf.org; Sun, 29 Feb 2004 18:55:17 -0500
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AxalW-0007Fd-00
	for megaco@ietf.org; Sun, 29 Feb 2004 18:54:34 -0500
Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118])
	by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1TNsSYG005720
	for ; Mon, 1 Mar 2004 00:54:28 +0100 (MET)
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Mon, 1 Mar 2004 00:54:28 +0100
Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id FYF7DGJ3; Mon, 1 Mar 2004 00:54:28 +0100
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.252]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id FHQ5K2VW; Mon, 1 Mar 2004 10:53:35 +1100
Message-ID: <40427B92.3000707@ericsson.com>
Date: Mon, 01 Mar 2004 10:53:54 +1100
X-Sybari-Trust: 9bb19359 c77f3eb6 614305f2 00000138
From: Christian Groves 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tom Taylor 
CC: Albrecht.Schwarz@alcatel.de, Zhao Bo , megaco@ietf.org
Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning;
 Re: [Megaco] Hairpin case A/u Law conversion
References:  <403E1760.2010903@nortelnetworks.com>
In-Reply-To: <403E1760.2010903@nortelnetworks.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
X-OriginalArrivalTime: 29 Feb 2004 23:54:28.0573 (UTC) FILETIME=[5E2F40D0:01C3FF1F]
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by penguin-ext.wise.edt.ericsson.se id i1TNsSYG005720
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hello Tom and Albrecht,

What peice of information do you want to signal explicitely? Doesn't TMR =
allow=20
you to specify 64Kbit UDI? If so then its supported by H.248.1 Annex C.9.=
 For=20
H.248 text users this (or any element in Annex C) can be tranferred via=20
H.248.15. Alternatively Q.1950 sect 5.7.1.2 specifies an equivalent encod=
ing.

Regards, Christian

Tom Taylor wrote:

> I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in my=20
> intervention.  My old draft has been allowed to expire because it did=20
> not seem to be of much interest to the community.
>=20
> You are right: the draft just referred to doesn't apply to TDM, only to=
=20
> the packet side.  I wasn't thinking.  I agree that in the absence of th=
e=20
> attributes provided in my old draft, TDM bearer characteristics are=20
> assumed rather than signalled explicitly.
>=20
> Albrecht.Schwarz@alcatel.de wrote:
>=20
>> I think that the question is, whether this specific TDM bearer capabil=
ity
>> should be (1) explicitly signalled, or whether (2) implicit assumption=
 is
>> already sufficient.
>>
>> With regard to (1), Tom, I guess that your refer to
>>
>> * RTP/CLEARMODE
>>   RTP payload format for a 64 kbit/s transparent call
>>   http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-04.=
txt
>>
>> But, this coming RFC may not be directly applied, e.g., packetization=20
>> time
>> parameter isn't applicable IMHO. Pls correct me if wrong.
>>
>> Or do you refer to your proposals in your expired draft wrt
>> * TDM/CLEARMODE
>>   Conventions for the use of the Session Description Protocol (SDP)
>>   for Digital Circuit Connections
>>   http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01.tx=
t
>>
>> My conclusion is, that an explicit signalling method doesn't exist tod=
ay
>> ("exception might be Q.1950").
>> Even though, an explicit TDM Media Descriptor for I.231.1  might be=20
>> helpful
>> for unambigously specification in certain MG implementations.
>>
>>
>> With regard to (2):
>> Implicit signaling is in my understanding the situation of today. In c=
ase
>> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Media
>> Descriptors with transparent channel indications", when a transparent
>> 64-kbit/s bearer connection may be established.
>> Sometimes this is also called "native TDM switching", or "native TDM
>> hairpinning", but technically it is exactly representing an ISDN B=20
>> channel
>> with I.231.1 bearer service. [=3D> the channel may bypass the DSP, but=
 in
>> case that a DSP is looped-in, then must be the DSP channel operation m=
ode
>> configured for 'Clearmode']
>>
>> Last comment:
>> Such kind of implicit signalling mechanism is often assumed in telco
>> industry, because this is the legacy signaling mechanism within a TDM
>> switch ("if there aren't any signaled bearer capabilities then=20
>> transparent
>> channel; any needed bearer capability in addition must be explicitly
>> signalled, like signal processing network equipment functions, e.g.,=20
>> EC").
>>
>> TDM hairpinning means, an "H.248-controlled TDM switching function" fr=
om
>> H.248 Media Gateway perspective. Hence, this implicit signalling=20
>> assumption
>> may be still valid, or do you see any needs for explicit signaling
>> codepoints in case of TDM-to-TDM ISDN I.231.1 calls?
>>
>> Regards
>>
>> Albrecht
>>
>>
>>
>>
>>
>>
>>                                                                       =
                                                                         =
    =20
>>                       Tom=20
>> Taylor                                                                =
                                                   =20
>>                       >                                                       =
             =20
>>                       tworks.com>              cc:      Albrecht=20
>> SCHWARZ/DE/ALCATEL@ALCATEL,=20
>> megaco@ietf.org                                       =20
>>                                                Subject: Re: TDM=20
>> Hairpinning; Re: [Megaco] Hairpin case A/u Law=20
>> conversion                                                 26.02.2004=20
>> 14:05                                                                 =
                                            =20
>>                                                                       =
                                                                         =
    =20
>>                                                                       =
                                                                         =
    =20
>>
>>
>>
>>
>> I think you would do it by specifying the CLEARMODE codec in the Local=
=20
>> and
>> Remote
>> descriptors.  Unfortunately, CLEARMODE is still under consideration by=
=20
>> the
>> IESG
>> and hasn't reached RFC status.
>>
>> Zhao Bo wrote:
>>
>>> Dear Albrecht:
>>>    Is there any H.248 package defined to signal the UDI transparency
>>
>>
>> properties in TDM hairping case?
>>
>>>    Best regards
>>>
>>> ----- Original Message -----
>>> From: 
>>> To: "Zhao Bo" 
>>> Cc: ; 
>>> Sent: Wednesday, February 25, 2004 10:24 PM
>>> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversio=
n
>>>
>>>
>>>
>>> Dear Zhao Bo,
>>>
>>> because there isn't any "hairpinning" definition in MEGACOP/H.248
>>
>>
>> standards
>>
>>> ("please correct if I'm wrong"), I'd like to use the following one fo=
r
>>> responding your questions:
>>>
>>>
>>
>> **********************************************************************=
*************=20
>>
>>
>>
>>> Definition:
>>> TDM Hairpinning
>>> ? is a scenario whereby a call is being made between two TDM=20
>>> endpoints on
>>
>>
>> a
>>
>>>    single media gateway. The media comes in on one TDM channel and go=
es
>>>    out on another TDM channel through the use of an internal loop in =
the
>>>    media gateway.
>>>
>>> Note 1: due to the fact that there are local call types at local
>>
>>
>> exchanges
>>
>>> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks (PSTN=
,
>>> NISDN, etc), there is a variety of TDM-to-TDM connection types behind=
=20
>>> the
>>> general "TDM hairpinning" capability (dependent on required type of I=
WF,
>>> etc.) in corresponding H.248 MG types
>>>
>>> Note 2: H.248/MEGCOP perspective
>>> TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM Termination=
s
>>>
>>
>> **********************************************************************=
**************=20
>>
>>
>>
>>> Based on this hairpinning understanding, my answers are:
>>>
>>> (1) Speech telephony service: G.711 companding formats are a property=
 of
>>> the corresponding H.248 TDM termination
>>>
>>> [Note: dependent on MG architecture and implementation, property=20
>>> might be
>>> signalled or preprovisioned. Of course, G.711 companding law is an
>>
>>
>> inherent
>>
>>> property of your DS0 channel at your PDH/SDH/SONET framer; the way, h=
ow
>>> this DS0 property is associated with the corresponding H.248 TDM
>>> Termination property may only realized MG-internally for very=20
>>> specific MG
>>> architectures. Generally it is up to the MGC, particularly if some (o=
r
>>
>>
>> all)
>>
>>> DS0's are ISDN B channels.]
>>>
>>> (2) Voiceband Data services: same as in (1)
>>>
>>> [Note: VBD according new ITU-T V.152 -> "... For purposes of
>>> interoperability, a V.152 compliant implementation shall support at=20
>>> least
>>> both G.711 A-law and G.711 =C3=AC-law codecs as VBD codecs. "]
>>>
>>> (3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer servic=
e
>>> requirement
>>> =3D> H.248 TDM Termination property must be signalled by MGC, if not,=
 MG
>>
>>
>> may
>>
>>> not guarantee UDI capability (i.e., fully transparent 64-kbit/s beare=
r
>>> channel) in TDM hairpinning scenarios ...
>>>
>>>
>>> Conclusion:
>>> IF your MG is supporting
>>> PSTN lines (=3D H.248 ALN Termination),
>>> PSTN trunks (=3D H.248 TDM Termination), and
>>> ISDN B channels (=3D H.248 TDM Termination)
>>>
>>> AND IF you've such services and interworking requirements
>>>
>>> THEN you should generally signal the corresponding properties ...
>>>
>>> ... in case of
>>> TDM hairpinning,
>>> ALN hairpinning, or
>>> ALN-to-TDM connection types.
>>>
>>> Regards,
>>> Albrecht
>>>
>>> ALCATEL
>>>
>>>
>>>
>>>
>>>
>>
>>
>>>                      Zhao Bo
>>
>>
>>
>>>                               To:      megaco@ietf.or=
g
>>
>>
>>
>>>                      Sent by:                 cc:
>>
>>
>>
>>>                      megaco-admin@iet         Subject: [Megaco] Hairp=
in
>>
>>
>> case A/u Law conversion
>>
>>>                      f.org
>>
>>
>>
>>
>>
>>>                      25.02.2004 08:11
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>> In this case, the A/u law format of a TDM ciruit can be provisioned, =
=20
>>> but
>>> the MG doesn't know the service type of a call, thus
>>> has no way to know if a conversion is needed. For speech service
>>
>>
>> conversion
>>
>>> may be needed; for data service like isdn UDI, conversion is not
>>
>>
>> permitted.
>>
>>> Is there any method to solve this problem?
>>>
>>> Zhao Bo
>>>
>>> *****************************************************************
>>> This e-mail and its attachments contain confidential information from
>>> HUAWEI, which is intended only for the person or entity whose address=
 is
>>> listed above. Any use of the information contained herein in any way
>>> (including, but not limited to, total or partial disclosure,
>>
>>
>> reproduction,
>>
>>> or dissemination) by persons other than the intended recipient(s) is
>>> prohibited. If you receive this e-mail in error, please notify the=20
>>> sender
>>> by phone or email immediately and delete it!
>>> *****************************************************************
>>>
>>> _______________________________________________
>>> Megaco mailing list
>>> Megaco@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Megaco mailing list
>>> Megaco@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/megaco
>>> 1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3=87 i=
=C3=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2=AD~=C5=
=A0=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2=A3=C3=
=B9=C5=BE=EF=A2=9D=C2=A7(
>>
>>
>>
>>
>>
>=20
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>=20


This communication is confidential and intended solely for the addressee(=
s). Any unauthorized review, use, disclosure or distribution is prohibite=
d. If you believe this message has been sent to you in error, please noti=
fy the sender by replying to this transmission and delete the message wit=
hout disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interrupt=
ion, unauthorized amendment, tampering and viruses, and we only send and =
receive e-mails on the basis that we are not liable for any such corrupti=
on, interception, amendment, tampering or viruses or any consequences the=
reof.


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



From megaco-admin@ietf.org  Sun Feb 29 19:31:32 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18758
	for ; Sun, 29 Feb 2004 19:31:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AxbKo-0001qX-Ai; Sun, 29 Feb 2004 19:31:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AxbK3-0001pv-9W
	for megaco@optimus.ietf.org; Sun, 29 Feb 2004 19:30:15 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18722
	for ; Sun, 29 Feb 2004 19:30:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AxbK1-00034k-00
	for megaco@ietf.org; Sun, 29 Feb 2004 19:30:13 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AxbJ6-00030o-00
	for megaco@ietf.org; Sun, 29 Feb 2004 19:29:17 -0500
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AxbIu-0002wl-00
	for megaco@ietf.org; Sun, 29 Feb 2004 19:29:04 -0500
Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120])
	by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i210T4YG007972
	for ; Mon, 1 Mar 2004 01:29:04 +0100 (MET)
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Mon, 1 Mar 2004 01:29:04 +0100
Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id FYFNT3YW; Mon, 1 Mar 2004 01:29:35 +0100
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.252]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id FHQ5KJJ7; Mon, 1 Mar 2004 11:28:13 +1100
Message-ID: <404283B0.8060907@ericsson.com>
Date: Mon, 01 Mar 2004 11:28:32 +1100
X-Sybari-Trust: 42449a94 c77f3eb6 73f6aa1c 00000138
From: Christian Groves 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Zhao Bo 
CC: megaco@ietf.org
Subject: Re: [Megaco] Questions about H.248.17 "line test packages"(upgrade,sorry,
 my poor English)
References: <000b01c3f9ee$ea987ae0$f8486e0a@HUAWEI.COM> <403A8743.6000402@ericsson.com> <000401c3fd2f$7b2023e0$f8486e0a@HUAWEI.COM>
In-Reply-To: <000401c3fd2f$7b2023e0$f8486e0a@HUAWEI.COM>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Mar 2004 00:29:04.0491 (UTC) FILETIME=[338733B0:01C3FF24]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit

Hello Zhao Bo,

I don't know why you think it is quite strange? MGC/MGs are full of O&M systems 
which supervise the performance of their internals. If there's a problem or a 
performance metric this is output to somebody, which may be another off-line system.

Christian

Zhao Bo wrote:

> Hi Chrisitan:
>     I studied a simple procedure as follow:
> 
>     (1)Testee MG is set to  loopback;
>     (2)Tester sends a 1020Hz tone to  testee;
>     (3)Tester receive the loopbacked tone, analyze the quality of tone and output a report.
> 
>     Suppose the Tester is embeded in MGW. In H.248.17 structure,  the procedure will be.
>     (1)Testee MGC set the Testee MGW to loopback.
>     (2)Tester MGC signals the Tester to send  1020Hz tone;
>     (3)Someone ask Tester MGW to receive loopback tone and make analysis.
>     (4)MGW output a report to this "someone".
> 
>     Maybe you think O&M should be that "Someone"?  If my understanding is right--in same procedure O&M and  MGC will operate same termination, I think that's quite strange:-)
>     
>     Best regards
>     
> 
> ----- Original Message ----- 
> From: "Christian Groves" 
> To: "Zhao Bo" 
> Cc: 
> Sent: Tuesday, February 24, 2004 7:05 AM
> Subject: Re: [Megaco] Questions about H.248.17 "line test packages"(upgrade,sorry, my poor English)
> 
> 
> 
>>Hello Zhao,
>>
>>I'm the editor of H.248.17. Please see my replies below marked [CHG].
>>
>>Regards, Christian
>>
>>Zhao Bo wrote:
>>
>>
>>>Could anyone kindly answer the following questions (I can't find the author's email address in H.248.17 text).
>>>
>>>1. Section 1 "Scope" says:
>>>"The detailing of results that are reported (e.g. events and statistics), as well as the timing and mechanisms used for
>>>transmitting such records from the MG to the MGC"
>>>Why? If a test is initiated by MGC, why not define a protocol to send the measuring result back to MGC?
>>
>>[CHG] As the results are related to the physical characteristics of the bearer 
>>and not usually interesting to a MGC it was seen that a protocol other than 
>>H.248 (or even internal O&M of the MG) was more suitable for this information.
>>
>>
>>>2.If we have two switch connected with temination T1 and T2
>>>    SW1--T1-------T2--SW2
>>>Shall the H.248 signal be apllied to T1 and T2, or some extra termination, for example T3 or T4 in the following scenerio:
>>>T3--SW1--T1-------T2--SW2--T4
>>
>>[CHG] Depends on what you want to test. If all you want to test is the link 
>>between T1 and T2 then you only apply signals between T1 & T2.
>>
>>
>>>3. Section 7.1.1 says:
>>>"ITU-T Rec. O.11 describes test responder behaviour. For a description of this behaviour see
>>>clause 9."
>>>But neither O.11 nor H.247.17 text has a clause 9?
>>
>>[CHG] Please see the latest implementors guide for the correction.
>>
>>
>>>Best regards
>>>
>>>Zhao Bo
>>>
>>>
>>>Zhao Bo
>>>
>>>*****************************************************************
>>>This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
>>>*****************************************************************
>>>
>>>_______________________________________________
>>>Megaco mailing list
>>>Megaco@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/megaco
>>>
>>
>>
>>This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.
>>
>>E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
>>
>>
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
> 
> 


This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.


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


From exim@www1.ietf.org  Sun Feb 29 19:32:49 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18794
	for ; Sun, 29 Feb 2004 19:32:49 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AxbM3-00023C-Vj
	for megaco-archive@odin.ietf.org; Sun, 29 Feb 2004 19:32:20 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i210WJuP007876
	for megaco-archive@odin.ietf.org; Sun, 29 Feb 2004 19:32:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AxbM3-00022v-Re
	for megaco-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 19:32:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18788
	for ; Sun, 29 Feb 2004 19:32:18 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AxbM2-0003GN-00
	for megaco-web-archive@ietf.org; Sun, 29 Feb 2004 19:32:18 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AxbL8-0003Bc-00
	for megaco-web-archive@ietf.org; Sun, 29 Feb 2004 19:31:23 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AxbKo-00036a-00
	for megaco-web-archive@ietf.org; Sun, 29 Feb 2004 19:31:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AxbKo-0001qX-Ai; Sun, 29 Feb 2004 19:31:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AxbK3-0001pv-9W
	for megaco@optimus.ietf.org; Sun, 29 Feb 2004 19:30:15 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18722
	for ; Sun, 29 Feb 2004 19:30:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AxbK1-00034k-00
	for megaco@ietf.org; Sun, 29 Feb 2004 19:30:13 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AxbJ6-00030o-00
	for megaco@ietf.org; Sun, 29 Feb 2004 19:29:17 -0500
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AxbIu-0002wl-00
	for megaco@ietf.org; Sun, 29 Feb 2004 19:29:04 -0500
Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120])
	by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i210T4YG007972
	for ; Mon, 1 Mar 2004 01:29:04 +0100 (MET)
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Mon, 1 Mar 2004 01:29:04 +0100
Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id FYFNT3YW; Mon, 1 Mar 2004 01:29:35 +0100
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.252]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id FHQ5KJJ7; Mon, 1 Mar 2004 11:28:13 +1100
Message-ID: <404283B0.8060907@ericsson.com>
Date: Mon, 01 Mar 2004 11:28:32 +1100
X-Sybari-Trust: 42449a94 c77f3eb6 73f6aa1c 00000138
From: Christian Groves 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Zhao Bo 
CC: megaco@ietf.org
Subject: Re: [Megaco] Questions about H.248.17 "line test packages"(upgrade,sorry,
 my poor English)
References: <000b01c3f9ee$ea987ae0$f8486e0a@HUAWEI.COM> <403A8743.6000402@ericsson.com> <000401c3fd2f$7b2023e0$f8486e0a@HUAWEI.COM>
In-Reply-To: <000401c3fd2f$7b2023e0$f8486e0a@HUAWEI.COM>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Mar 2004 00:29:04.0491 (UTC) FILETIME=[338733B0:01C3FF24]
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: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello Zhao Bo,

I don't know why you think it is quite strange? MGC/MGs are full of O&M systems 
which supervise the performance of their internals. If there's a problem or a 
performance metric this is output to somebody, which may be another off-line system.

Christian

Zhao Bo wrote:

> Hi Chrisitan:
>     I studied a simple procedure as follow:
> 
>     (1)Testee MG is set to  loopback;
>     (2)Tester sends a 1020Hz tone to  testee;
>     (3)Tester receive the loopbacked tone, analyze the quality of tone and output a report.
> 
>     Suppose the Tester is embeded in MGW. In H.248.17 structure,  the procedure will be.
>     (1)Testee MGC set the Testee MGW to loopback.
>     (2)Tester MGC signals the Tester to send  1020Hz tone;
>     (3)Someone ask Tester MGW to receive loopback tone and make analysis.
>     (4)MGW output a report to this "someone".
> 
>     Maybe you think O&M should be that "Someone"?  If my understanding is right--in same procedure O&M and  MGC will operate same termination, I think that's quite strange:-)
>     
>     Best regards
>     
> 
> ----- Original Message ----- 
> From: "Christian Groves" 
> To: "Zhao Bo" 
> Cc: 
> Sent: Tuesday, February 24, 2004 7:05 AM
> Subject: Re: [Megaco] Questions about H.248.17 "line test packages"(upgrade,sorry, my poor English)
> 
> 
> 
>>Hello Zhao,
>>
>>I'm the editor of H.248.17. Please see my replies below marked [CHG].
>>
>>Regards, Christian
>>
>>Zhao Bo wrote:
>>
>>
>>>Could anyone kindly answer the following questions (I can't find the author's email address in H.248.17 text).
>>>
>>>1. Section 1 "Scope" says:
>>>"The detailing of results that are reported (e.g. events and statistics), as well as the timing and mechanisms used for
>>>transmitting such records from the MG to the MGC"
>>>Why? If a test is initiated by MGC, why not define a protocol to send the measuring result back to MGC?
>>
>>[CHG] As the results are related to the physical characteristics of the bearer 
>>and not usually interesting to a MGC it was seen that a protocol other than 
>>H.248 (or even internal O&M of the MG) was more suitable for this information.
>>
>>
>>>2.If we have two switch connected with temination T1 and T2
>>>    SW1--T1-------T2--SW2
>>>Shall the H.248 signal be apllied to T1 and T2, or some extra termination, for example T3 or T4 in the following scenerio:
>>>T3--SW1--T1-------T2--SW2--T4
>>
>>[CHG] Depends on what you want to test. If all you want to test is the link 
>>between T1 and T2 then you only apply signals between T1 & T2.
>>
>>
>>>3. Section 7.1.1 says:
>>>"ITU-T Rec. O.11 describes test responder behaviour. For a description of this behaviour see
>>>clause 9."
>>>But neither O.11 nor H.247.17 text has a clause 9?
>>
>>[CHG] Please see the latest implementors guide for the correction.
>>
>>
>>>Best regards
>>>
>>>Zhao Bo
>>>
>>>
>>>Zhao Bo
>>>
>>>*****************************************************************
>>>This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
>>>*****************************************************************
>>>
>>>_______________________________________________
>>>Megaco mailing list
>>>Megaco@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/megaco
>>>
>>
>>
>>This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.
>>
>>E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
>>
>>
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
> 
> 


This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.


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



From megaco-admin@ietf.org  Sun Feb 29 21:01:30 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23302
	for ; Sun, 29 Feb 2004 21:01:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Axcjs-0002cr-QU; Sun, 29 Feb 2004 21:01:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AxcjC-0002Yn-PB
	for megaco@optimus.ietf.org; Sun, 29 Feb 2004 21:00:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23253
	for ; Sun, 29 Feb 2004 21:00:16 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AxcjA-0004ck-00
	for megaco@ietf.org; Sun, 29 Feb 2004 21:00:16 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AxciF-0004XD-00
	for megaco@ietf.org; Sun, 29 Feb 2004 20:59:20 -0500
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AxchM-0004OL-00
	for megaco@ietf.org; Sun, 29 Feb 2004 20:58:26 -0500
Received: from z14593 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HTV00EOLK1A2K@mta0.huawei.com> for megaco@ietf.org;
 Mon, 01 Mar 2004 09:56:00 +0800 (CST)
Date: Mon, 01 Mar 2004 09:57:26 +0800
From: Zhao Bo 
Subject: Re: [Megaco] Questions about H.248.17
 "line test packages"(upgrade,sorry, my poor English)
To: Christian Groves 
Cc: megaco@ietf.org
Message-id: <000401c3ff30$8c45bec0$f8486e0a@HUAWEI.COM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <000b01c3f9ee$ea987ae0$f8486e0a@HUAWEI.COM>
 <403A8743.6000402@ericsson.com> <000401c3fd2f$7b2023e0$f8486e0a@HUAWEI.COM>
 <404283B0.8060907@ericsson.com>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7BIT
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7BIT

Hi Christian:
    I think as a common rule, if a termination is in a call (being operated by MGC), O&M should not operate it, because the O&M operation may affect the call quality. 
    Best regards.

----- Original Message ----- 
From: "Christian Groves" 
To: "Zhao Bo" 
Cc: 
Sent: Monday, March 01, 2004 8:28 AM
Subject: Re: [Megaco] Questions about H.248.17 "line test packages"(upgrade,sorry, my poor English)


> Hello Zhao Bo,
> 
> I don't know why you think it is quite strange? MGC/MGs are full of O&M systems 
> which supervise the performance of their internals. If there's a problem or a 
> performance metric this is output to somebody, which may be another off-line system.
> 
> Christian
> 
> Zhao Bo wrote:
> 
> > Hi Chrisitan:
> >     I studied a simple procedure as follow:
> > 
> >     (1)Testee MG is set to  loopback;
> >     (2)Tester sends a 1020Hz tone to  testee;
> >     (3)Tester receive the loopbacked tone, analyze the quality of tone and output a report.
> > 
> >     Suppose the Tester is embeded in MGW. In H.248.17 structure,  the procedure will be.
> >     (1)Testee MGC set the Testee MGW to loopback.
> >     (2)Tester MGC signals the Tester to send  1020Hz tone;
> >     (3)Someone ask Tester MGW to receive loopback tone and make analysis.
> >     (4)MGW output a report to this "someone".
> > 
> >     Maybe you think O&M should be that "Someone"?  If my understanding is right--in same procedure O&M and  MGC will operate same termination, I think that's quite strange:-)
> >     
> >     Best regards
> >     
> > 
> > ----- Original Message ----- 
> > From: "Christian Groves" 
> > To: "Zhao Bo" 
> > Cc: 
> > Sent: Tuesday, February 24, 2004 7:05 AM
> > Subject: Re: [Megaco] Questions about H.248.17 "line test packages"(upgrade,sorry, my poor English)
> > 
> > 
> > 
> >>Hello Zhao,
> >>
> >>I'm the editor of H.248.17. Please see my replies below marked [CHG].
> >>
> >>Regards, Christian
> >>
> >>Zhao Bo wrote:
> >>
> >>
> >>>Could anyone kindly answer the following questions (I can't find the author's email address in H.248.17 text).
> >>>
> >>>1. Section 1 "Scope" says:
> >>>"The detailing of results that are reported (e.g. events and statistics), as well as the timing and mechanisms used for
> >>>transmitting such records from the MG to the MGC"
> >>>Why? If a test is initiated by MGC, why not define a protocol to send the measuring result back to MGC?
> >>
> >>[CHG] As the results are related to the physical characteristics of the bearer 
> >>and not usually interesting to a MGC it was seen that a protocol other than 
> >>H.248 (or even internal O&M of the MG) was more suitable for this information.
> >>
> >>
> >>>2.If we have two switch connected with temination T1 and T2
> >>>    SW1--T1-------T2--SW2
> >>>Shall the H.248 signal be apllied to T1 and T2, or some extra termination, for example T3 or T4 in the following scenerio:
> >>>T3--SW1--T1-------T2--SW2--T4
> >>
> >>[CHG] Depends on what you want to test. If all you want to test is the link 
> >>between T1 and T2 then you only apply signals between T1 & T2.
> >>
> >>
> >>>3. Section 7.1.1 says:
> >>>"ITU-T Rec. O.11 describes test responder behaviour. For a description of this behaviour see
> >>>clause 9."
> >>>But neither O.11 nor H.247.17 text has a clause 9?
> >>
> >>[CHG] Please see the latest implementors guide for the correction.
> >>
> >>
> >>>Best regards
> >>>
> >>>Zhao Bo
> >>>
> >>>
> >>>Zhao Bo
> >>>
> >>>*****************************************************************
> >>>This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
> >>>*****************************************************************
> >>>
> >>>_______________________________________________
> >>>Megaco mailing list
> >>>Megaco@ietf.org
> >>>https://www1.ietf.org/mailman/listinfo/megaco
> >>>
> >>
> >>
> >>This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.
> >>
> >>E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
> >>
> >>
> >>_______________________________________________
> >>Megaco mailing list
> >>Megaco@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/megaco
> > 
> > 
> 
> 
> This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
> 

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


From exim@www1.ietf.org  Sun Feb 29 21:06:04 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23587
	for ; Sun, 29 Feb 2004 21:06:04 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AxcoK-0002pe-3V
	for megaco-archive@odin.ietf.org; Sun, 29 Feb 2004 21:05:36 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i2125aOI010882
	for megaco-archive@odin.ietf.org; Sun, 29 Feb 2004 21:05:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AxcoJ-0002pR-VS
	for megaco-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 21:05:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23427
	for ; Sun, 29 Feb 2004 21:05:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AxcoH-0005Bn-00
	for megaco-web-archive@ietf.org; Sun, 29 Feb 2004 21:05:33 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AxcnS-000513-00
	for megaco-web-archive@ietf.org; Sun, 29 Feb 2004 21:04:43 -0500
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Axcml-0004tO-04
	for megaco-web-archive@ietf.org; Sun, 29 Feb 2004 21:03:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Axcjs-0002cr-QU; Sun, 29 Feb 2004 21:01:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AxcjC-0002Yn-PB
	for megaco@optimus.ietf.org; Sun, 29 Feb 2004 21:00:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23253
	for ; Sun, 29 Feb 2004 21:00:16 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AxcjA-0004ck-00
	for megaco@ietf.org; Sun, 29 Feb 2004 21:00:16 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AxciF-0004XD-00
	for megaco@ietf.org; Sun, 29 Feb 2004 20:59:20 -0500
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AxchM-0004OL-00
	for megaco@ietf.org; Sun, 29 Feb 2004 20:58:26 -0500
Received: from z14593 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HTV00EOLK1A2K@mta0.huawei.com> for megaco@ietf.org;
 Mon, 01 Mar 2004 09:56:00 +0800 (CST)
Date: Mon, 01 Mar 2004 09:57:26 +0800
From: Zhao Bo 
Subject: Re: [Megaco] Questions about H.248.17
 "line test packages"(upgrade,sorry, my poor English)
To: Christian Groves 
Cc: megaco@ietf.org
Message-id: <000401c3ff30$8c45bec0$f8486e0a@HUAWEI.COM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <000b01c3f9ee$ea987ae0$f8486e0a@HUAWEI.COM>
 <403A8743.6000402@ericsson.com> <000401c3fd2f$7b2023e0$f8486e0a@HUAWEI.COM>
 <404283B0.8060907@ericsson.com>
Content-Transfer-Encoding: 7BIT
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Media Gateway Control 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Hi Christian:
    I think as a common rule, if a termination is in a call (being operated by MGC), O&M should not operate it, because the O&M operation may affect the call quality. 
    Best regards.

----- Original Message ----- 
From: "Christian Groves" 
To: "Zhao Bo" 
Cc: 
Sent: Monday, March 01, 2004 8:28 AM
Subject: Re: [Megaco] Questions about H.248.17 "line test packages"(upgrade,sorry, my poor English)


> Hello Zhao Bo,
> 
> I don't know why you think it is quite strange? MGC/MGs are full of O&M systems 
> which supervise the performance of their internals. If there's a problem or a 
> performance metric this is output to somebody, which may be another off-line system.
> 
> Christian
> 
> Zhao Bo wrote:
> 
> > Hi Chrisitan:
> >     I studied a simple procedure as follow:
> > 
> >     (1)Testee MG is set to  loopback;
> >     (2)Tester sends a 1020Hz tone to  testee;
> >     (3)Tester receive the loopbacked tone, analyze the quality of tone and output a report.
> > 
> >     Suppose the Tester is embeded in MGW. In H.248.17 structure,  the procedure will be.
> >     (1)Testee MGC set the Testee MGW to loopback.
> >     (2)Tester MGC signals the Tester to send  1020Hz tone;
> >     (3)Someone ask Tester MGW to receive loopback tone and make analysis.
> >     (4)MGW output a report to this "someone".
> > 
> >     Maybe you think O&M should be that "Someone"?  If my understanding is right--in same procedure O&M and  MGC will operate same termination, I think that's quite strange:-)
> >     
> >     Best regards
> >     
> > 
> > ----- Original Message ----- 
> > From: "Christian Groves" 
> > To: "Zhao Bo" 
> > Cc: 
> > Sent: Tuesday, February 24, 2004 7:05 AM
> > Subject: Re: [Megaco] Questions about H.248.17 "line test packages"(upgrade,sorry, my poor English)
> > 
> > 
> > 
> >>Hello Zhao,
> >>
> >>I'm the editor of H.248.17. Please see my replies below marked [CHG].
> >>
> >>Regards, Christian
> >>
> >>Zhao Bo wrote:
> >>
> >>
> >>>Could anyone kindly answer the following questions (I can't find the author's email address in H.248.17 text).
> >>>
> >>>1. Section 1 "Scope" says:
> >>>"The detailing of results that are reported (e.g. events and statistics), as well as the timing and mechanisms used for
> >>>transmitting such records from the MG to the MGC"
> >>>Why? If a test is initiated by MGC, why not define a protocol to send the measuring result back to MGC?
> >>
> >>[CHG] As the results are related to the physical characteristics of the bearer 
> >>and not usually interesting to a MGC it was seen that a protocol other than 
> >>H.248 (or even internal O&M of the MG) was more suitable for this information.
> >>
> >>
> >>>2.If we have two switch connected with temination T1 and T2
> >>>    SW1--T1-------T2--SW2
> >>>Shall the H.248 signal be apllied to T1 and T2, or some extra termination, for example T3 or T4 in the following scenerio:
> >>>T3--SW1--T1-------T2--SW2--T4
> >>
> >>[CHG] Depends on what you want to test. If all you want to test is the link 
> >>between T1 and T2 then you only apply signals between T1 & T2.
> >>
> >>
> >>>3. Section 7.1.1 says:
> >>>"ITU-T Rec. O.11 describes test responder behaviour. For a description of this behaviour see
> >>>clause 9."
> >>>But neither O.11 nor H.247.17 text has a clause 9?
> >>
> >>[CHG] Please see the latest implementors guide for the correction.
> >>
> >>
> >>>Best regards
> >>>
> >>>Zhao Bo
> >>>
> >>>
> >>>Zhao Bo
> >>>
> >>>*****************************************************************
> >>>This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
> >>>*****************************************************************
> >>>
> >>>_______________________________________________
> >>>Megaco mailing list
> >>>Megaco@ietf.org
> >>>https://www1.ietf.org/mailman/listinfo/megaco
> >>>
> >>
> >>
> >>This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.
> >>
> >>E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
> >>
> >>
> >>_______________________________________________
> >>Megaco mailing list
> >>Megaco@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/megaco
> > 
> > 
> 
> 
> This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
> 

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