From mailman-admin@ietf.org Sun Jun 1 10:51:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14312 for ; Sun, 1 Jun 2003 10:51:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51EpXB16607 for ; Sun, 1 Jun 2003 10:51:33 -0400 Date: Sun, 01 Jun 2003 10:51:33 -0400 Message-ID: <20030601145133.11734.91495.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 Jun 2 09:21:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06093 for ; Mon, 2 Jun 2003 09:21:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52DKeB12838; Mon, 2 Jun 2003 09:20:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52DI2B12692 for ; Mon, 2 Jun 2003 09:18:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05929 for ; Mon, 2 Jun 2003 09:17:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MpAb-0002rD-00 for megaco@ietf.org; Mon, 02 Jun 2003 09:16:13 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19MpAa-0002qy-00 for megaco@ietf.org; Mon, 02 Jun 2003 09:16:12 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52DHQ703980; Mon, 2 Jun 2003 09:17:27 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLF82S0; Mon, 2 Jun 2003 09:17:27 -0400 Received: from nortelnetworks.com (acart40q.ca.nortel.com [47.129.49.127]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA030S; Mon, 2 Jun 2003 09:17:26 -0400 Message-ID: <3EDB4E65.8050204@nortelnetworks.com> Date: Mon, 02 Jun 2003 09:17:25 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Megaco List CC: bs@utstar.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] WG Last Call For Megaco MIB Sender: megaco-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 like to announce Working Group Last Call for the Megaco MIB. This can be found at http://www.ietf.org/internet-drafts/draft-ietf-megaco-mib-05.txt I have also requested review by a MIB expert. Barring major issues, Last Call will end on 16 June. Tom Taylor, Chair, Megaco WG. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jun 2 09:22:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06154 for ; Mon, 2 Jun 2003 09:22:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52DMLA12943 for megaco-archive@odin.ietf.org; Mon, 2 Jun 2003 09:22:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52DMKB12940 for ; Mon, 2 Jun 2003 09:22:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06138 for ; Mon, 2 Jun 2003 09:22:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MpEl-0002te-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 09:20:31 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MpEk-0002tb-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 09:20:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52DKeB12838; Mon, 2 Jun 2003 09:20:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52DI2B12692 for ; Mon, 2 Jun 2003 09:18:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05929 for ; Mon, 2 Jun 2003 09:17:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MpAb-0002rD-00 for megaco@ietf.org; Mon, 02 Jun 2003 09:16:13 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19MpAa-0002qy-00 for megaco@ietf.org; Mon, 02 Jun 2003 09:16:12 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52DHQ703980; Mon, 2 Jun 2003 09:17:27 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLF82S0; Mon, 2 Jun 2003 09:17:27 -0400 Received: from nortelnetworks.com (acart40q.ca.nortel.com [47.129.49.127]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA030S; Mon, 2 Jun 2003 09:17:26 -0400 Message-ID: <3EDB4E65.8050204@nortelnetworks.com> Date: Mon, 02 Jun 2003 09:17:25 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Megaco List CC: bs@utstar.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] WG Last Call For Megaco MIB Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I would like to announce Working Group Last Call for the Megaco MIB. This can be found at http://www.ietf.org/internet-drafts/draft-ietf-megaco-mib-05.txt I have also requested review by a MIB expert. Barring major issues, Last Call will end on 16 June. Tom Taylor, Chair, Megaco WG. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jun 2 09:58:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07527 for ; Mon, 2 Jun 2003 09:58:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52DvOB15839; Mon, 2 Jun 2003 09:57:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52DuRB15751 for ; Mon, 2 Jun 2003 09:56:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07444 for ; Mon, 2 Jun 2003 09:56:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mpll-0003Cx-00 for megaco@ietf.org; Mon, 02 Jun 2003 09:54:37 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19Mplk-0003CC-00 for megaco@ietf.org; Mon, 02 Jun 2003 09:54:36 -0400 Received: from zcard307.ca.nortel.com (americasm01.nt.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52Dton20233 for ; Mon, 2 Jun 2003 09:55:50 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L9VCGPD9; Mon, 2 Jun 2003 09:55:51 -0400 Received: from nortelnetworks.com (acart40q.ca.nortel.com [47.129.49.127]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0PAX; Mon, 2 Jun 2003 09:55:49 -0400 Message-ID: <3EDB5764.4070205@nortelnetworks.com> Date: Mon, 02 Jun 2003 09:55:48 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Megaco List Content-Type: text/plain; charset=windows-1252; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04e.nortelnetworks.com id h52Dton20233 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h52DuRB15752 Subject: [Megaco] Summary Of SG 16 Meeting Just Concluded Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit For your information, I have extracted the Megaco-relevant portion of the SG 16 meeting report. The meeting was held 20-30 May in Geneva. 3.7.3 Recommendations for Consent New H.248.22 Shared Risk Group Package TD-PLEN-57 New H.248.23 Enhanced Alerting Packages TD-PLEN-32 New H.248.24 MF Tone Generation and Detection Packages TD-PLEN-33 New H.248.25 Basic CAS Packages TD-PLEN-58R1 New H.248.26 Enhanced Analogue Line Packages TD-PLEN-34 New H.248.27 Supplemental Tones Packages TD-PLEN-35 3.7.4 Documents for Approval H.248 Supp H.248 Sub-Series: Packages Guide Release 4 TD-PLEN-56 H.248 IG H.248 Sub Series Implementor's Guide TD-PLEN-36R1 3.7.6 Documents planned for Decision/Consent 3.7.6.5 H.248 Implementers Guide TD-GEN-0035 Reply to LS on Rec. H.248 Annex E, Gain and Automatic Level Control SG15 Addressed at the San Jose February 2003 meeting in AVD-2338. No further action needed. D-0347 Proposed additions to H.248 Implementors' Guide LM Ericsson This contribution was presented and it was agreed to incorporate the two proposed additions into the H.248 Sub-series implementors' guide. It was also agreed that text should be on clarifying what should be sent in a reponse to a request that has only actions and no commands. This has been added as section 6.18. TD-WP2-0028 H.248 Sub-series Implementors' Guide Editor The editor's draft was presented and accepted. It was agreed to put the H.248 Sub-Series Implementors' Guide forward for consent. The agreed text can be found in TD-PLEN-0036R1. 3.7.6.6 H.248.1 Annex F ServiceChange TD-WP2-0021 Draft H.248.1 Annex F Editor The editor's draft was presented and it was noted that there were no changes from San Jose output. It was agreed that this document was not ready to be put forward for consent. People are encouraged to contribute on this in the interim meeting. TD-WP2-0027 Considerations for discussion of update of ServiceChange procedures for H.248 Editor The temporary document was presented as a record of the requirements for ServiceChange annex work. 3.7.6.7 H.248.19 Decomposed MCU Audio, Video and Data Conferencing Packages D-0348 Additional requirements for H.248.19 for Chat conferencing LM Ericsson This delayed contribution was presented and discussion on the difference between messaging and chat conferencing. It was agreed to add these requirements to H.248.19. Ms.Levin will provide a reference to work undertaken in the IETF on this work. This reference should be included in the requirements when it becomes available. D-0349 Addition to H.248.19 for Tiled Windows LM Ericsson This delayed contribution was presented. It was noted that even in simple video window configuration individual windows may have different sizes. It was also noted that in the IETF work is ongoing on defining profiles for different configurations. It was agreed to accept this work for inclusion to H.248.19 but further changes maybe needed to define the use of profiles and the use of non-proportional window configurations. D-0350 Addition to H.248.19 for viewer indication LM Ericsson This contribution was presented and there was some discussion on the signal type and whether it should be two signals of type brief or one signal of type on/off. It was agreed that this should be type brief however a better explantion of how this is used should be be included. TD-WP2-0017 Draft H.248.19, "Decomposed Multipoint Control Unit, Audio, Video and Data Conferencing Packages" Editor The editor's input was presented and was accepted. D-0353 Video Coding description in H.245, H.248 and SDP LM Ericsson This contribution was presented. Discussion highlighted that for many video codecs (H.261, H.264) there was not a problem of mapping H.245 to SDP however a complete mapping between SDP and H.245 did not exist for H.263. Work is ongoing in the IETF to solve this problem through the use of profiles or feature description. It was agreed that this work should be monitored but this issue is of no consequence to the H.248.19 work. The output of H.248.19 for this meeting can be found in TD-WP2-60. 3.7.6.8 H.248.22 Shared Risk Group Handling Package D-0351 H.248.shrisk additions LM Ericsson The contribution was presented and it was agreed to put forward this delayed contribution (with editorial corrections) for consent. The recommendation for consent can be found in TD-PLEN-57. 3.7.6.9 H.248.23 Enhanced Alerting Packages D-0343 Comments to AVD-2313, "Enhanced Alerting Packages" Ericsson This delayed contribution was presented. Each of the bullet points in the discussion section were addressed, the results of which are detailed below: Item 1,2: Agreed to be incorporated in H.248.23 Item 3: Rejected Item 4: Text should be included to clarify what the variable duration is dependent on. Item 5: The text should be clarified to make clear that an error is NOT generated only when the data component of the signal is not delivered. All other errors will generate an error. Item 6: Text should be included to clarify the use of the TAS signal Item 7, 8: Included in editor's draft. TD-WP2-0022 Draft H.248.23 Enhanced Alerting Packages Editor This temporary document was presented. The editor stated that this work had existed for 2 years in the IETF and authors decided to move it to the ITU. Mr. Okubo questioned whether the IETF had been consulted over this move. The IETF had received a liaison from Question 3/16 notifying them of the proposal for taking over the work. It asked that they respond if there was a problem with this approach. No response was received. It was also noted that package development was not specifically part of the IETF Megaco WG charter. There was a question from Mr.Chatras (France Telecom) as to where the checksum should be generated, MGC or MG. The editor replied that as the checksum was associated with the data plane the MGC should be responsible for generating the checksum. This will be clarified in updated text. Mr. Chatras also questioned the need of having an example for ETSI based encodings. It was agreed that the editor and Mr.Chatras co-ordinate on such an example. It was agreed that H.248.23 be put forward for consent. The recommendation for consent is contained in TD-PLEN-0032. 3.7.6.10 H.248.24 MF Tone Generation and Detection Packages D-0342 Comments to AVD-2312, "MF Tone Generation and Detection Packages" Ericsson This delayed contribution was presented. Each of the bullet points in the discussion section were addressed, the results of which are detailed below: Item 1: Agreed to be incorporated in H.248.24 Item 2: Resolved. It was agreed to remove the text "was chosen arbitrarily". Item 3: Agreed to be incorporated in H.248.24 Item 4: Agreed to be incorporated in H.248.24 TD-WP2-0023 Draft H.248.24 MF Tone Generation and Detection Packages Editor This temporary document was presented and accepted. It was agreed to put forward H.248.24 for consent at this meeting. The recommendation for consent is contained in TD-PLEN-0033. 3.7.6.11 H.248.25 Basic CAS Packages D-0327 Comments to AVD-2315, "Basic CAS Packages" Ericsson This delayed contribution was presented. Each of the bullet points in the discussion section were addressed, the results of which are detailed below: Item 1: Package ID needs to be registered with IANA before final approval. Item 2: Editor to check if any values have been dropped. Item 3,4: Accepted to be resolved. Item 5: These values need to be reviewed in line with the comments made in D328. Item 6: Resolved. The address signal was split in a separate package. D-0328 H.248 Basic CAS Package – CAS Failure Code Extensions Alcatel This delayed contribution was presented and listed a number of concerns with the CAS package on Glare, Start Dailing Timeout, LTO and Polarity. The editor replied that: • Glare need not be added as it was already covered by the procedure section of the package. • Start Dialling Timeout can be handled by the Register Timeout Signal in the CAS Address package. • LTO there are other events that can be used to indicate this situation. • Unexpected Line signal could be used to indicate Polarity error. It was agreed that this explanation of error conditions should be included in H.248.24. TD-WP2-0016 Draft H.248.25 Basic CAS Packages Editor This temporary document was presented by the editor. The editor tabled a number of comments from the IETF mailing list: 1. Remove RTO as a possible value in bcas/casf event --> ec parameter (bcas addresses line signals/events, Register signaling is covered in the derived packages, so register failure reporting is outside scope of this package) 2. Added meth parameter in bcasaddr/addr event (digit map is associated with the reporting of this event) 3. casblk package has been referred in the icas package there the CAS Blocking Package should be included. The comments were agreed. The CAS blocking package will be specified in the ICAS package. It was agreed to put forward H.248.25 for consent at this meeting. A Package ID for the "bcasaddr" package has been requested. The recommendation for consent is contained in TD-PLEN-58R1. 3.7.6.12 H.248.26 Enhanced Analog Line Packages D-0346 Comments to AVD-2317, "Enhanced Analogue Line Packages" Ericsson This delayed contribution was presented. Each of the bullet points in the discussion section were addressed, the results of which are detailed below: Item 1: Agreed to be included. Item 2: Rejected. Signal type to remain on/off Item 3: Agreed to be included. TD-WP2-0024 Draft H.248.26 Enhanced Analog Line Packages Editor This temporary document was presented by the editor and agreed as baseline text. It was agreed to put forward H.248.26 for consent at this meeting. The recommendation for consent is contained in TD-PLEN-0034. 3.7.6.13 H.248.27 Supplemental Tones Packages D-0344 Comments to AVD-2314, "Supplementary Tones Packages" Ericsson This delayed contribution was presented. Each of the bullet points in the discussion section were addressed, the results of which are detailed below: Item 1,2: Agreed to be included Item 3: Heading should read "Diagnostic Tones" Item 4: A summary should be added detailing the use of this package. Item 5: Agreed to be included. TD-WP2-0025 Draft H.248.27 Supplemental Tones Packages Editor This temporary document was presented by the editor and agreed as baseline text. It was agreed to put forward H.248.27 for consent at this meeting. The recommendation for consent is contained in TD-PLEN-0035. 3.7.6.14 H.248 Sub-Series Packages Guide TD-WP2-0018 Proposed additions to H.248 Sub-Series: Packages Guide Release 4" Editor This temporary document was presented and the text agreed as baseline. A comment was made that packages in H.248.23,24,25,26,27,icas, icasc should be added. The respective drafts in the IETF should point to the ITU work. The supplement for approval is contained in TD-PLEN-56. D-0352 Proposed Liaison to Tiphon on H.248 Packages Ericsson This delayed contribution was presented and it was agreed to send enclosed liaison to Tiphon. The outgoing liaison can be found in TD-WP2-56. 3.7.7 Other Work to Progress 3.7.7.1 H.248.icas International CAS Packages D=0345 Comments to AVD-2316, "International CAS Packages" Ericsson This delayed contribution was presented. Each of the bullet points in the discussion section were addressed, the results of which is detailed below: Item 1: Agreed to be included. Item 2: Resolved. Signalling is different for R1 and R2. Item 3: Agreed to be included. D=0341 International CAS Compelled Register Signaling Packages Nortel This delayed contribution was presented and it was agreed to start a work item on this. This new work item shall be named H.248.icasc. D341 is considered baseline text. TD-WP2=0026 H.248.icas International CAS Packages Editor This temporary document was presented by the editor and agreed as baseline text. 3.7.8 New Work 3.7.8.1 New Packages for H.248 D-0361 Request for an extension package to the H.248 Network Package for the jitter buffer. (H.248.1 Annex E.11.1) Lucent This delayed contribution was presented. There was a comment from Mr. Boyle that if the work was accepted as a package extension the contribution would need significant editing. Mr. Boyle also questioned the need for a minimum and nominal jitter value. Mr. Teising replied that should know the network topology and can provide these values. It was discussed that the MG would better know the routing of the bearer so it would be more appropriate for it to provide the values. It was agreed to persue this work however extensive editing work is needed as well a scope and summary addressing the above questions. An editing session meet to draft text for a baseline document. The baseline shall be referred to as H.248.ajb and is contained in TD-WP2-0052. D-0362 Request that an extension package be defined to the H.248 Congestion Control Package (H.248.10) Lucent This delayed contribution was presented. Mr.Boyle questioned whether any consideration had been made to use H.248.11. Mr. Tegeler questioned if congestion on different routes and directions could be indicated. Mr.Groves expressed concern that the proposed extensions addressed MG wide congestion events as well as network congestion events where as the base H.248.10 only addressed MG events. Mr.Schwarz questioned how congestion of an IP connection carried over an ATM (AAL5 interface) would be handled? Mr. Schwarz noted that the resources specified fell in two types: those dealing with H.248 processing and Media Processing. Due to the number of questions D362 was not accepted. Mr. Teising undertook to study these questions and provide an updated contribution at a subsequent question. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jun 2 09:59:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07586 for ; Mon, 2 Jun 2003 09:59:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52DwxO15972 for megaco-archive@odin.ietf.org; Mon, 2 Jun 2003 09:58:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52DwxB15969 for ; Mon, 2 Jun 2003 09:58:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07556 for ; Mon, 2 Jun 2003 09:58:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MpoD-0003Ec-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 09:57:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MpoC-0003EY-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 09:57:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52DvOB15839; Mon, 2 Jun 2003 09:57:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52DuRB15751 for ; Mon, 2 Jun 2003 09:56:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07444 for ; Mon, 2 Jun 2003 09:56:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mpll-0003Cx-00 for megaco@ietf.org; Mon, 02 Jun 2003 09:54:37 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19Mplk-0003CC-00 for megaco@ietf.org; Mon, 02 Jun 2003 09:54:36 -0400 Received: from zcard307.ca.nortel.com (americasm01.nt.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52Dton20233 for ; Mon, 2 Jun 2003 09:55:50 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L9VCGPD9; Mon, 2 Jun 2003 09:55:51 -0400 Received: from nortelnetworks.com (acart40q.ca.nortel.com [47.129.49.127]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0PAX; Mon, 2 Jun 2003 09:55:49 -0400 Message-ID: <3EDB5764.4070205@nortelnetworks.com> Date: Mon, 02 Jun 2003 09:55:48 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Megaco List Content-Type: text/plain; charset=windows-1252; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04e.nortelnetworks.com id h52Dton20233 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h52DuRB15752 Subject: [Megaco] Summary Of SG 16 Meeting Just Concluded Sender: megaco-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-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h52DvOB15839 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h52DwxB15969 Content-Transfer-Encoding: 8bit For your information, I have extracted the Megaco-relevant portion of the SG 16 meeting report. The meeting was held 20-30 May in Geneva. 3.7.3 Recommendations for Consent New H.248.22 Shared Risk Group Package TD-PLEN-57 New H.248.23 Enhanced Alerting Packages TD-PLEN-32 New H.248.24 MF Tone Generation and Detection Packages TD-PLEN-33 New H.248.25 Basic CAS Packages TD-PLEN-58R1 New H.248.26 Enhanced Analogue Line Packages TD-PLEN-34 New H.248.27 Supplemental Tones Packages TD-PLEN-35 3.7.4 Documents for Approval H.248 Supp H.248 Sub-Series: Packages Guide Release 4 TD-PLEN-56 H.248 IG H.248 Sub Series Implementor's Guide TD-PLEN-36R1 3.7.6 Documents planned for Decision/Consent 3.7.6.5 H.248 Implementers Guide TD-GEN-0035 Reply to LS on Rec. H.248 Annex E, Gain and Automatic Level Control SG15 Addressed at the San Jose February 2003 meeting in AVD-2338. No further action needed. D-0347 Proposed additions to H.248 Implementors' Guide LM Ericsson This contribution was presented and it was agreed to incorporate the two proposed additions into the H.248 Sub-series implementors' guide. It was also agreed that text should be on clarifying what should be sent in a reponse to a request that has only actions and no commands. This has been added as section 6.18. TD-WP2-0028 H.248 Sub-series Implementors' Guide Editor The editor's draft was presented and accepted. It was agreed to put the H.248 Sub-Series Implementors' Guide forward for consent. The agreed text can be found in TD-PLEN-0036R1. 3.7.6.6 H.248.1 Annex F ServiceChange TD-WP2-0021 Draft H.248.1 Annex F Editor The editor's draft was presented and it was noted that there were no changes from San Jose output. It was agreed that this document was not ready to be put forward for consent. People are encouraged to contribute on this in the interim meeting. TD-WP2-0027 Considerations for discussion of update of ServiceChange procedures for H.248 Editor The temporary document was presented as a record of the requirements for ServiceChange annex work. 3.7.6.7 H.248.19 Decomposed MCU Audio, Video and Data Conferencing Packages D-0348 Additional requirements for H.248.19 for Chat conferencing LM Ericsson This delayed contribution was presented and discussion on the difference between messaging and chat conferencing. It was agreed to add these requirements to H.248.19. Ms.Levin will provide a reference to work undertaken in the IETF on this work. This reference should be included in the requirements when it becomes available. D-0349 Addition to H.248.19 for Tiled Windows LM Ericsson This delayed contribution was presented. It was noted that even in simple video window configuration individual windows may have different sizes. It was also noted that in the IETF work is ongoing on defining profiles for different configurations. It was agreed to accept this work for inclusion to H.248.19 but further changes maybe needed to define the use of profiles and the use of non-proportional window configurations. D-0350 Addition to H.248.19 for viewer indication LM Ericsson This contribution was presented and there was some discussion on the signal type and whether it should be two signals of type brief or one signal of type on/off. It was agreed that this should be type brief however a better explantion of how this is used should be be included. TD-WP2-0017 Draft H.248.19, "Decomposed Multipoint Control Unit, Audio, Video and Data Conferencing Packages" Editor The editor's input was presented and was accepted. D-0353 Video Coding description in H.245, H.248 and SDP LM Ericsson This contribution was presented. Discussion highlighted that for many video codecs (H.261, H.264) there was not a problem of mapping H.245 to SDP however a complete mapping between SDP and H.245 did not exist for H.263. Work is ongoing in the IETF to solve this problem through the use of profiles or feature description. It was agreed that this work should be monitored but this issue is of no consequence to the H.248.19 work. The output of H.248.19 for this meeting can be found in TD-WP2-60. 3.7.6.8 H.248.22 Shared Risk Group Handling Package D-0351 H.248.shrisk additions LM Ericsson The contribution was presented and it was agreed to put forward this delayed contribution (with editorial corrections) for consent. The recommendation for consent can be found in TD-PLEN-57. 3.7.6.9 H.248.23 Enhanced Alerting Packages D-0343 Comments to AVD-2313, "Enhanced Alerting Packages" Ericsson This delayed contribution was presented. Each of the bullet points in the discussion section were addressed, the results of which are detailed below: Item 1,2: Agreed to be incorporated in H.248.23 Item 3: Rejected Item 4: Text should be included to clarify what the variable duration is dependent on. Item 5: The text should be clarified to make clear that an error is NOT generated only when the data component of the signal is not delivered. All other errors will generate an error. Item 6: Text should be included to clarify the use of the TAS signal Item 7, 8: Included in editor's draft. TD-WP2-0022 Draft H.248.23 Enhanced Alerting Packages Editor This temporary document was presented. The editor stated that this work had existed for 2 years in the IETF and authors decided to move it to the ITU. Mr. Okubo questioned whether the IETF had been consulted over this move. The IETF had received a liaison from Question 3/16 notifying them of the proposal for taking over the work. It asked that they respond if there was a problem with this approach. No response was received. It was also noted that package development was not specifically part of the IETF Megaco WG charter. There was a question from Mr.Chatras (France Telecom) as to where the checksum should be generated, MGC or MG. The editor replied that as the checksum was associated with the data plane the MGC should be responsible for generating the checksum. This will be clarified in updated text. Mr. Chatras also questioned the need of having an example for ETSI based encodings. It was agreed that the editor and Mr.Chatras co-ordinate on such an example. It was agreed that H.248.23 be put forward for consent. The recommendation for consent is contained in TD-PLEN-0032. 3.7.6.10 H.248.24 MF Tone Generation and Detection Packages D-0342 Comments to AVD-2312, "MF Tone Generation and Detection Packages" Ericsson This delayed contribution was presented. Each of the bullet points in the discussion section were addressed, the results of which are detailed below: Item 1: Agreed to be incorporated in H.248.24 Item 2: Resolved. It was agreed to remove the text "was chosen arbitrarily". Item 3: Agreed to be incorporated in H.248.24 Item 4: Agreed to be incorporated in H.248.24 TD-WP2-0023 Draft H.248.24 MF Tone Generation and Detection Packages Editor This temporary document was presented and accepted. It was agreed to put forward H.248.24 for consent at this meeting. The recommendation for consent is contained in TD-PLEN-0033. 3.7.6.11 H.248.25 Basic CAS Packages D-0327 Comments to AVD-2315, "Basic CAS Packages" Ericsson This delayed contribution was presented. Each of the bullet points in the discussion section were addressed, the results of which are detailed below: Item 1: Package ID needs to be registered with IANA before final approval. Item 2: Editor to check if any values have been dropped. Item 3,4: Accepted to be resolved. Item 5: These values need to be reviewed in line with the comments made in D328. Item 6: Resolved. The address signal was split in a separate package. D-0328 H.248 Basic CAS Package – CAS Failure Code Extensions Alcatel This delayed contribution was presented and listed a number of concerns with the CAS package on Glare, Start Dailing Timeout, LTO and Polarity. The editor replied that: • Glare need not be added as it was already covered by the procedure section of the package. • Start Dialling Timeout can be handled by the Register Timeout Signal in the CAS Address package. • LTO there are other events that can be used to indicate this situation. • Unexpected Line signal could be used to indicate Polarity error. It was agreed that this explanation of error conditions should be included in H.248.24. TD-WP2-0016 Draft H.248.25 Basic CAS Packages Editor This temporary document was presented by the editor. The editor tabled a number of comments from the IETF mailing list: 1. Remove RTO as a possible value in bcas/casf event --> ec parameter (bcas addresses line signals/events, Register signaling is covered in the derived packages, so register failure reporting is outside scope of this package) 2. Added meth parameter in bcasaddr/addr event (digit map is associated with the reporting of this event) 3. casblk package has been referred in the icas package there the CAS Blocking Package should be included. The comments were agreed. The CAS blocking package will be specified in the ICAS package. It was agreed to put forward H.248.25 for consent at this meeting. A Package ID for the "bcasaddr" package has been requested. The recommendation for consent is contained in TD-PLEN-58R1. 3.7.6.12 H.248.26 Enhanced Analog Line Packages D-0346 Comments to AVD-2317, "Enhanced Analogue Line Packages" Ericsson This delayed contribution was presented. Each of the bullet points in the discussion section were addressed, the results of which are detailed below: Item 1: Agreed to be included. Item 2: Rejected. Signal type to remain on/off Item 3: Agreed to be included. TD-WP2-0024 Draft H.248.26 Enhanced Analog Line Packages Editor This temporary document was presented by the editor and agreed as baseline text. It was agreed to put forward H.248.26 for consent at this meeting. The recommendation for consent is contained in TD-PLEN-0034. 3.7.6.13 H.248.27 Supplemental Tones Packages D-0344 Comments to AVD-2314, "Supplementary Tones Packages" Ericsson This delayed contribution was presented. Each of the bullet points in the discussion section were addressed, the results of which are detailed below: Item 1,2: Agreed to be included Item 3: Heading should read "Diagnostic Tones" Item 4: A summary should be added detailing the use of this package. Item 5: Agreed to be included. TD-WP2-0025 Draft H.248.27 Supplemental Tones Packages Editor This temporary document was presented by the editor and agreed as baseline text. It was agreed to put forward H.248.27 for consent at this meeting. The recommendation for consent is contained in TD-PLEN-0035. 3.7.6.14 H.248 Sub-Series Packages Guide TD-WP2-0018 Proposed additions to H.248 Sub-Series: Packages Guide Release 4" Editor This temporary document was presented and the text agreed as baseline. A comment was made that packages in H.248.23,24,25,26,27,icas, icasc should be added. The respective drafts in the IETF should point to the ITU work. The supplement for approval is contained in TD-PLEN-56. D-0352 Proposed Liaison to Tiphon on H.248 Packages Ericsson This delayed contribution was presented and it was agreed to send enclosed liaison to Tiphon. The outgoing liaison can be found in TD-WP2-56. 3.7.7 Other Work to Progress 3.7.7.1 H.248.icas International CAS Packages D=0345 Comments to AVD-2316, "International CAS Packages" Ericsson This delayed contribution was presented. Each of the bullet points in the discussion section were addressed, the results of which is detailed below: Item 1: Agreed to be included. Item 2: Resolved. Signalling is different for R1 and R2. Item 3: Agreed to be included. D=0341 International CAS Compelled Register Signaling Packages Nortel This delayed contribution was presented and it was agreed to start a work item on this. This new work item shall be named H.248.icasc. D341 is considered baseline text. TD-WP2=0026 H.248.icas International CAS Packages Editor This temporary document was presented by the editor and agreed as baseline text. 3.7.8 New Work 3.7.8.1 New Packages for H.248 D-0361 Request for an extension package to the H.248 Network Package for the jitter buffer. (H.248.1 Annex E.11.1) Lucent This delayed contribution was presented. There was a comment from Mr. Boyle that if the work was accepted as a package extension the contribution would need significant editing. Mr. Boyle also questioned the need for a minimum and nominal jitter value. Mr. Teising replied that should know the network topology and can provide these values. It was discussed that the MG would better know the routing of the bearer so it would be more appropriate for it to provide the values. It was agreed to persue this work however extensive editing work is needed as well a scope and summary addressing the above questions. An editing session meet to draft text for a baseline document. The baseline shall be referred to as H.248.ajb and is contained in TD-WP2-0052. D-0362 Request that an extension package be defined to the H.248 Congestion Control Package (H.248.10) Lucent This delayed contribution was presented. Mr.Boyle questioned whether any consideration had been made to use H.248.11. Mr. Tegeler questioned if congestion on different routes and directions could be indicated. Mr.Groves expressed concern that the proposed extensions addressed MG wide congestion events as well as network congestion events where as the base H.248.10 only addressed MG events. Mr.Schwarz questioned how congestion of an IP connection carried over an ATM (AAL5 interface) would be handled? Mr. Schwarz noted that the resources specified fell in two types: those dealing with H.248 processing and Media Processing. Due to the number of questions D362 was not accepted. Mr. Teising undertook to study these questions and provide an updated contribution at a subsequent question. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jun 2 13:26:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15734 for ; Mon, 2 Jun 2003 13:26:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52HNvB02310; Mon, 2 Jun 2003 13:23:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52HK5B02134 for ; Mon, 2 Jun 2003 13:20:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15600 for ; Mon, 2 Jun 2003 13:20:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mswp-0004oQ-00 for megaco@ietf.org; Mon, 02 Jun 2003 13:18:15 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19Mswo-0004oC-00 for megaco@ietf.org; Mon, 02 Jun 2003 13:18:14 -0400 Received: from smilevm.winphoria.com ([10.14.25.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 2 Jun 2003 13:19:24 -0400 Message-Id: <5.2.1.1.0.20030602120818.01d1da10@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 02 Jun 2003 12:13:04 -0400 To: Tom Taylor , Megaco List From: Aleksandr Ryabin Subject: Re: [Megaco] Summary Of SG 16 Meeting Just Concluded In-Reply-To: <3EDB5764.4070205@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 02 Jun 2003 17:19:24.0516 (UTC) FILETIME=[1D1B3240:01C3292B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h52HK6B02135 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Tom, Thanks for the info. Are the output documents referred below publicly available? If yes, where from? Thanks Aleks At 09:55 AM 6/2/2003, Tom Taylor wrote: >For your information, I have extracted the Megaco-relevant portion of the >SG 16 meeting report. The meeting was held 20-30 May in Geneva. > >3.7.3 Recommendations for Consent > >New H.248.22 Shared Risk Group Package TD-PLEN-57 >New H.248.23 Enhanced Alerting Packages TD-PLEN-32 >New H.248.24 MF Tone Generation and Detection Packages TD-PLEN-33 >New H.248.25 Basic CAS Packages TD-PLEN-58R1 >New H.248.26 Enhanced Analogue Line Packages TD-PLEN-34 >New H.248.27 Supplemental Tones Packages TD-PLEN-35 > >3.7.4 Documents for Approval > >H.248 Supp H.248 Sub-Series: Packages Guide Release 4 TD-PLEN-56 >H.248 IG H.248 Sub Series Implementor's Guide TD-PLEN-36R1 > > >3.7.6 Documents planned for Decision/Consent > >3.7.6.5 H.248 Implementers Guide > >TD-GEN-0035 Reply to LS on Rec. H.248 Annex E, Gain and Automatic >Level Control SG15 >Addressed at the San Jose February 2003 meeting in AVD-2338. No further >action needed. > >D-0347 Proposed additions to H.248 Implementors' Guide LM Ericsson >This contribution was presented and it was agreed to incorporate the two >proposed additions into the H.248 Sub-series implementors' guide. It was >also agreed that text should be on clarifying what should be sent in a >reponse to a request that has only actions and no commands. This has been >added as section 6.18. > >TD-WP2-0028 H.248 Sub-series Implementors' Guide Editor >The editor's draft was presented and accepted. >It was agreed to put the H.248 Sub-Series Implementors' Guide forward for >consent. The agreed text can be found in TD-PLEN-0036R1. > >3.7.6.6 H.248.1 Annex F ServiceChange > >TD-WP2-0021 Draft H.248.1 Annex F Editor >The editor's draft was presented and it was noted that there were no >changes from San Jose output. It was agreed that this document was not >ready to be put forward for consent. People are encouraged to contribute >on this in the interim meeting. > >TD-WP2-0027 Considerations for discussion of update of ServiceChange >procedures for H.248 Editor >The temporary document was presented as a record of the requirements for >ServiceChange annex work. > >3.7.6.7 H.248.19 Decomposed MCU Audio, Video and Data Conferencing Packages > >D-0348 Additional requirements for H.248.19 for Chat conferencing LM >Ericsson >This delayed contribution was presented and discussion on the difference >between messaging and chat conferencing. It was agreed to add these >requirements to H.248.19. Ms.Levin will provide a reference to work >undertaken in the IETF on this work. This reference should be included in >the requirements when it becomes available. > >D-0349 Addition to H.248.19 for Tiled Windows LM Ericsson >This delayed contribution was presented. It was noted that even in simple >video window configuration individual windows may have different sizes. It >was also noted that in the IETF work is ongoing on defining profiles for >different configurations. It was agreed to accept this work for inclusion >to H.248.19 but further changes maybe needed to define the use of profiles >and the use of non-proportional window configurations. > >D-0350 Addition to H.248.19 for viewer indication LM Ericsson >This contribution was presented and there was some discussion on the >signal type and whether it should be two signals of type brief or one >signal of type on/off. It was agreed that this should be type brief >however a better explantion of how this is used should be be included. > >TD-WP2-0017 Draft H.248.19, "Decomposed Multipoint Control Unit, >Audio, Video and Data Conferencing Packages" Editor >The editor's input was presented and was accepted. > >D-0353 Video Coding description in H.245, H.248 and SDP LM Ericsson >This contribution was presented. Discussion highlighted that for many >video codecs (H.261, H.264) there was not a problem of mapping H.245 to >SDP however a complete mapping between SDP and H.245 did not exist for >H.263. Work is ongoing in the IETF to solve this problem through the use >of profiles or feature description. It was agreed that this work should be >monitored but this issue is of no consequence to the H.248.19 work. >The output of H.248.19 for this meeting can be found in TD-WP2-60. > >3.7.6.8 H.248.22 Shared Risk Group Handling Package > >D-0351 H.248.shrisk additions LM Ericsson >The contribution was presented and it was agreed to put forward this >delayed contribution (with editorial corrections) for consent. The >recommendation for consent can be found in TD-PLEN-57. > >3.7.6.9 H.248.23 Enhanced Alerting Packages > >D-0343 Comments to AVD-2313, "Enhanced Alerting Packages" Ericsson >This delayed contribution was presented. Each of the bullet points in the >discussion section were addressed, the results of which are detailed below: >Item 1,2: Agreed to be incorporated in H.248.23 >Item 3: Rejected >Item 4: Text should be included to clarify what the variable duration is >dependent on. >Item 5: The text should be clarified to make clear that an error is NOT >generated only when the data component of the signal is not delivered. All >other errors will generate an error. >Item 6: Text should be included to clarify the use of the TAS signal >Item 7, 8: Included in editor's draft. > >TD-WP2-0022 Draft H.248.23 Enhanced Alerting Packages Editor >This temporary document was presented. The editor stated that this work >had existed for 2 years in the IETF and authors decided to move it to the >ITU. Mr. Okubo questioned whether the IETF had been consulted over this >move. The IETF had received a liaison from Question 3/16 notifying them of >the proposal for taking over the work. It asked that they respond if there >was a problem with this approach. No response was received. It was also >noted that package development was not specifically part of the IETF >Megaco WG charter. >There was a question from Mr.Chatras (France Telecom) as to where the >checksum should be generated, MGC or MG. The editor replied that as the >checksum was associated with the data plane the MGC should be responsible >for generating the checksum. This will be clarified in updated text. >Mr. Chatras also questioned the need of having an example for ETSI based >encodings. It was agreed that the editor and Mr.Chatras co-ordinate on >such an example. >It was agreed that H.248.23 be put forward for consent. The recommendation >for consent is contained in TD-PLEN-0032. > >3.7.6.10 H.248.24 MF Tone Generation and Detection Packages > >D-0342 Comments to AVD-2312, "MF Tone Generation and Detection >Packages" Ericsson >This delayed contribution was presented. Each of the bullet points in the >discussion section were addressed, the results of which are detailed below: >Item 1: Agreed to be incorporated in H.248.24 >Item 2: Resolved. It was agreed to remove the text "was chosen arbitrarily". >Item 3: Agreed to be incorporated in H.248.24 >Item 4: Agreed to be incorporated in H.248.24 > >TD-WP2-0023 Draft H.248.24 MF Tone Generation and Detection >Packages Editor >This temporary document was presented and accepted. >It was agreed to put forward H.248.24 for consent at this meeting. The >recommendation for consent is contained in TD-PLEN-0033. > >3.7.6.11 H.248.25 Basic CAS Packages > >D-0327 Comments to AVD-2315, "Basic CAS Packages" Ericsson >This delayed contribution was presented. Each of the bullet points in the >discussion section were addressed, the results of which are detailed below: >Item 1: Package ID needs to be registered with IANA before final approval. >Item 2: Editor to check if any values have been dropped. >Item 3,4: Accepted to be resolved. >Item 5: These values need to be reviewed in line with the comments made in >D328. >Item 6: Resolved. The address signal was split in a separate package. > >D-0328 H.248 Basic CAS Package ­ CAS Failure Code Extensions Alcatel >This delayed contribution was presented and listed a number of concerns >with the CAS package on Glare, Start Dailing Timeout, LTO and Polarity. >The editor replied that: >• Glare need not be added as it was already covered by the procedure >section of the package. >• Start Dialling Timeout can be handled by the Register Timeout >Signal in the CAS Address package. >• LTO there are other events that can be used to indicate this >situation. >• Unexpected Line signal could be used to indicate Polarity error. >It was agreed that this explanation of error conditions should be included >in H.248.24. > >TD-WP2-0016 Draft H.248.25 Basic CAS Packages Editor >This temporary document was presented by the editor. The editor tabled a >number of comments from the IETF mailing list: >1. Remove RTO as a possible value in bcas/casf event --> ec parameter >(bcas addresses line signals/events, Register signaling is covered in the >derived packages, so register failure reporting is outside scope of this >package) >2. Added meth parameter in bcasaddr/addr event (digit map is associated >with the reporting of this event) >3. casblk package has been referred in the icas package there the CAS >Blocking Package should be included. >The comments were agreed. The CAS blocking package will be specified in >the ICAS package. >It was agreed to put forward H.248.25 for consent at this meeting. A >Package ID for the "bcasaddr" package has been requested. The >recommendation for consent is contained in TD-PLEN-58R1. > >3.7.6.12 H.248.26 Enhanced Analog Line Packages > >D-0346 Comments to AVD-2317, "Enhanced Analogue Line Packages" Ericsson >This delayed contribution was presented. Each of the bullet points in the >discussion section were addressed, the results of which are detailed below: >Item 1: Agreed to be included. >Item 2: Rejected. Signal type to remain on/off >Item 3: Agreed to be included. > >TD-WP2-0024 Draft H.248.26 Enhanced Analog Line Packages Editor >This temporary document was presented by the editor and agreed as baseline >text. >It was agreed to put forward H.248.26 for consent at this meeting. The >recommendation for consent is contained in TD-PLEN-0034. > >3.7.6.13 H.248.27 Supplemental Tones Packages > >D-0344 Comments to AVD-2314, "Supplementary Tones Packages" Ericsson >This delayed contribution was presented. Each of the bullet points in the >discussion section were addressed, the results of which are detailed below: >Item 1,2: Agreed to be included >Item 3: Heading should read "Diagnostic Tones" >Item 4: A summary should be added detailing the use of this package. >Item 5: Agreed to be included. > >TD-WP2-0025 Draft H.248.27 Supplemental Tones Packages Editor >This temporary document was presented by the editor and agreed as baseline >text. >It was agreed to put forward H.248.27 for consent at this meeting. The >recommendation for consent is contained in TD-PLEN-0035. > >3.7.6.14 H.248 Sub-Series Packages Guide > >TD-WP2-0018 Proposed additions to H.248 Sub-Series: Packages Guide >Release 4" Editor >This temporary document was presented and the text agreed as baseline. A >comment was made that packages in H.248.23,24,25,26,27,icas, icasc should >be added. The respective drafts in the IETF should point to the ITU work. >The supplement for approval is contained in TD-PLEN-56. > >D-0352 Proposed Liaison to Tiphon on H.248 Packages Ericsson >This delayed contribution was presented and it was agreed to send enclosed >liaison to Tiphon. The outgoing liaison can be found in TD-WP2-56. > >3.7.7 Other Work to Progress > >3.7.7.1 H.248.icas International CAS Packages > >D=0345 Comments to AVD-2316, "International CAS Packages" Ericsson >This delayed contribution was presented. Each of the bullet points in the >discussion section were addressed, the results of which is detailed below: >Item 1: Agreed to be included. >Item 2: Resolved. Signalling is different for R1 and R2. >Item 3: Agreed to be included. > >D=0341 International CAS Compelled Register Signaling Packages Nortel >This delayed contribution was presented and it was agreed to start a work >item on this. This new work item shall be named H.248.icasc. D341 is >considered baseline text. > >TD-WP2=0026 H.248.icas International CAS Packages Editor >This temporary document was presented by the editor and agreed as baseline >text. > >3.7.8 New Work > >3.7.8.1 New Packages for H.248 > >D-0361 Request for an extension package to the H.248 Network Package for >the jitter buffer. (H.248.1 Annex E.11.1) Lucent >This delayed contribution was presented. There was a comment from Mr. >Boyle that if the work was accepted as a package extension the >contribution would need significant editing. Mr. Boyle also questioned the >need for a minimum and nominal jitter value. Mr. Teising replied that >should know the network topology and can provide these values. It was >discussed that the MG would better know the routing of the bearer so it >would be more appropriate for it to provide the values. >It was agreed to persue this work however extensive editing work is needed >as well a scope and summary addressing the above questions. >An editing session meet to draft text for a baseline document. The >baseline shall be referred to as H.248.ajb and is contained in TD-WP2-0052. > >D-0362 Request that an extension package be defined to the H.248 >Congestion Control Package (H.248.10) Lucent >This delayed contribution was presented. Mr.Boyle questioned whether any >consideration had been made to use H.248.11. Mr. Tegeler questioned if >congestion on different routes and directions could be indicated. >Mr.Groves expressed concern that the proposed extensions addressed MG wide >congestion events as well as network congestion events where as the base >H.248.10 only addressed MG events. Mr.Schwarz questioned how congestion of >an IP connection carried over an ATM (AAL5 interface) would be handled? >Mr. Schwarz noted that the resources specified fell in two types: those >dealing with H.248 processing and Media Processing. Due to the number of >questions D362 was not accepted. Mr. Teising undertook to study these >questions and provide an updated contribution at a subsequent question. > > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jun 2 13:27:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15811 for ; Mon, 2 Jun 2003 13:27:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52HR3o02442 for megaco-archive@odin.ietf.org; Mon, 2 Jun 2003 13:27:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52HR3B02439 for ; Mon, 2 Jun 2003 13:27:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15790 for ; Mon, 2 Jun 2003 13:26:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mt3Z-0004r1-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 13:25:13 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Mt3Y-0004qx-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 13:25:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52HNvB02310; Mon, 2 Jun 2003 13:23:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52HK5B02134 for ; Mon, 2 Jun 2003 13:20:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15600 for ; Mon, 2 Jun 2003 13:20:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mswp-0004oQ-00 for megaco@ietf.org; Mon, 02 Jun 2003 13:18:15 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19Mswo-0004oC-00 for megaco@ietf.org; Mon, 02 Jun 2003 13:18:14 -0400 Received: from smilevm.winphoria.com ([10.14.25.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 2 Jun 2003 13:19:24 -0400 Message-Id: <5.2.1.1.0.20030602120818.01d1da10@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 02 Jun 2003 12:13:04 -0400 To: Tom Taylor , Megaco List From: Aleksandr Ryabin Subject: Re: [Megaco] Summary Of SG 16 Meeting Just Concluded In-Reply-To: <3EDB5764.4070205@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 02 Jun 2003 17:19:24.0516 (UTC) FILETIME=[1D1B3240:01C3292B] X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h52HK6B02135 Sender: megaco-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-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h52HNvB02310 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h52HR3B02439 Content-Transfer-Encoding: 8bit Hi Tom, Thanks for the info. Are the output documents referred below publicly available? If yes, where from? Thanks Aleks At 09:55 AM 6/2/2003, Tom Taylor wrote: >For your information, I have extracted the Megaco-relevant portion of the >SG 16 meeting report. The meeting was held 20-30 May in Geneva. > >3.7.3 Recommendations for Consent > >New H.248.22 Shared Risk Group Package TD-PLEN-57 >New H.248.23 Enhanced Alerting Packages TD-PLEN-32 >New H.248.24 MF Tone Generation and Detection Packages TD-PLEN-33 >New H.248.25 Basic CAS Packages TD-PLEN-58R1 >New H.248.26 Enhanced Analogue Line Packages TD-PLEN-34 >New H.248.27 Supplemental Tones Packages TD-PLEN-35 > >3.7.4 Documents for Approval > >H.248 Supp H.248 Sub-Series: Packages Guide Release 4 TD-PLEN-56 >H.248 IG H.248 Sub Series Implementor's Guide TD-PLEN-36R1 > > >3.7.6 Documents planned for Decision/Consent > >3.7.6.5 H.248 Implementers Guide > >TD-GEN-0035 Reply to LS on Rec. H.248 Annex E, Gain and Automatic >Level Control SG15 >Addressed at the San Jose February 2003 meeting in AVD-2338. No further >action needed. > >D-0347 Proposed additions to H.248 Implementors' Guide LM Ericsson >This contribution was presented and it was agreed to incorporate the two >proposed additions into the H.248 Sub-series implementors' guide. It was >also agreed that text should be on clarifying what should be sent in a >reponse to a request that has only actions and no commands. This has been >added as section 6.18. > >TD-WP2-0028 H.248 Sub-series Implementors' Guide Editor >The editor's draft was presented and accepted. >It was agreed to put the H.248 Sub-Series Implementors' Guide forward for >consent. The agreed text can be found in TD-PLEN-0036R1. > >3.7.6.6 H.248.1 Annex F ServiceChange > >TD-WP2-0021 Draft H.248.1 Annex F Editor >The editor's draft was presented and it was noted that there were no >changes from San Jose output. It was agreed that this document was not >ready to be put forward for consent. People are encouraged to contribute >on this in the interim meeting. > >TD-WP2-0027 Considerations for discussion of update of ServiceChange >procedures for H.248 Editor >The temporary document was presented as a record of the requirements for >ServiceChange annex work. > >3.7.6.7 H.248.19 Decomposed MCU Audio, Video and Data Conferencing Packages > >D-0348 Additional requirements for H.248.19 for Chat conferencing LM >Ericsson >This delayed contribution was presented and discussion on the difference >between messaging and chat conferencing. It was agreed to add these >requirements to H.248.19. Ms.Levin will provide a reference to work >undertaken in the IETF on this work. This reference should be included in >the requirements when it becomes available. > >D-0349 Addition to H.248.19 for Tiled Windows LM Ericsson >This delayed contribution was presented. It was noted that even in simple >video window configuration individual windows may have different sizes. It >was also noted that in the IETF work is ongoing on defining profiles for >different configurations. It was agreed to accept this work for inclusion >to H.248.19 but further changes maybe needed to define the use of profiles >and the use of non-proportional window configurations. > >D-0350 Addition to H.248.19 for viewer indication LM Ericsson >This contribution was presented and there was some discussion on the >signal type and whether it should be two signals of type brief or one >signal of type on/off. It was agreed that this should be type brief >however a better explantion of how this is used should be be included. > >TD-WP2-0017 Draft H.248.19, "Decomposed Multipoint Control Unit, >Audio, Video and Data Conferencing Packages" Editor >The editor's input was presented and was accepted. > >D-0353 Video Coding description in H.245, H.248 and SDP LM Ericsson >This contribution was presented. Discussion highlighted that for many >video codecs (H.261, H.264) there was not a problem of mapping H.245 to >SDP however a complete mapping between SDP and H.245 did not exist for >H.263. Work is ongoing in the IETF to solve this problem through the use >of profiles or feature description. It was agreed that this work should be >monitored but this issue is of no consequence to the H.248.19 work. >The output of H.248.19 for this meeting can be found in TD-WP2-60. > >3.7.6.8 H.248.22 Shared Risk Group Handling Package > >D-0351 H.248.shrisk additions LM Ericsson >The contribution was presented and it was agreed to put forward this >delayed contribution (with editorial corrections) for consent. The >recommendation for consent can be found in TD-PLEN-57. > >3.7.6.9 H.248.23 Enhanced Alerting Packages > >D-0343 Comments to AVD-2313, "Enhanced Alerting Packages" Ericsson >This delayed contribution was presented. Each of the bullet points in the >discussion section were addressed, the results of which are detailed below: >Item 1,2: Agreed to be incorporated in H.248.23 >Item 3: Rejected >Item 4: Text should be included to clarify what the variable duration is >dependent on. >Item 5: The text should be clarified to make clear that an error is NOT >generated only when the data component of the signal is not delivered. All >other errors will generate an error. >Item 6: Text should be included to clarify the use of the TAS signal >Item 7, 8: Included in editor's draft. > >TD-WP2-0022 Draft H.248.23 Enhanced Alerting Packages Editor >This temporary document was presented. The editor stated that this work >had existed for 2 years in the IETF and authors decided to move it to the >ITU. Mr. Okubo questioned whether the IETF had been consulted over this >move. The IETF had received a liaison from Question 3/16 notifying them of >the proposal for taking over the work. It asked that they respond if there >was a problem with this approach. No response was received. It was also >noted that package development was not specifically part of the IETF >Megaco WG charter. >There was a question from Mr.Chatras (France Telecom) as to where the >checksum should be generated, MGC or MG. The editor replied that as the >checksum was associated with the data plane the MGC should be responsible >for generating the checksum. This will be clarified in updated text. >Mr. Chatras also questioned the need of having an example for ETSI based >encodings. It was agreed that the editor and Mr.Chatras co-ordinate on >such an example. >It was agreed that H.248.23 be put forward for consent. The recommendation >for consent is contained in TD-PLEN-0032. > >3.7.6.10 H.248.24 MF Tone Generation and Detection Packages > >D-0342 Comments to AVD-2312, "MF Tone Generation and Detection >Packages" Ericsson >This delayed contribution was presented. Each of the bullet points in the >discussion section were addressed, the results of which are detailed below: >Item 1: Agreed to be incorporated in H.248.24 >Item 2: Resolved. It was agreed to remove the text "was chosen arbitrarily". >Item 3: Agreed to be incorporated in H.248.24 >Item 4: Agreed to be incorporated in H.248.24 > >TD-WP2-0023 Draft H.248.24 MF Tone Generation and Detection >Packages Editor >This temporary document was presented and accepted. >It was agreed to put forward H.248.24 for consent at this meeting. The >recommendation for consent is contained in TD-PLEN-0033. > >3.7.6.11 H.248.25 Basic CAS Packages > >D-0327 Comments to AVD-2315, "Basic CAS Packages" Ericsson >This delayed contribution was presented. Each of the bullet points in the >discussion section were addressed, the results of which are detailed below: >Item 1: Package ID needs to be registered with IANA before final approval. >Item 2: Editor to check if any values have been dropped. >Item 3,4: Accepted to be resolved. >Item 5: These values need to be reviewed in line with the comments made in >D328. >Item 6: Resolved. The address signal was split in a separate package. > >D-0328 H.248 Basic CAS Package ­ CAS Failure Code Extensions Alcatel >This delayed contribution was presented and listed a number of concerns >with the CAS package on Glare, Start Dailing Timeout, LTO and Polarity. >The editor replied that: >• Glare need not be added as it was already covered by the procedure >section of the package. >• Start Dialling Timeout can be handled by the Register Timeout >Signal in the CAS Address package. >• LTO there are other events that can be used to indicate this >situation. >• Unexpected Line signal could be used to indicate Polarity error. >It was agreed that this explanation of error conditions should be included >in H.248.24. > >TD-WP2-0016 Draft H.248.25 Basic CAS Packages Editor >This temporary document was presented by the editor. The editor tabled a >number of comments from the IETF mailing list: >1. Remove RTO as a possible value in bcas/casf event --> ec parameter >(bcas addresses line signals/events, Register signaling is covered in the >derived packages, so register failure reporting is outside scope of this >package) >2. Added meth parameter in bcasaddr/addr event (digit map is associated >with the reporting of this event) >3. casblk package has been referred in the icas package there the CAS >Blocking Package should be included. >The comments were agreed. The CAS blocking package will be specified in >the ICAS package. >It was agreed to put forward H.248.25 for consent at this meeting. A >Package ID for the "bcasaddr" package has been requested. The >recommendation for consent is contained in TD-PLEN-58R1. > >3.7.6.12 H.248.26 Enhanced Analog Line Packages > >D-0346 Comments to AVD-2317, "Enhanced Analogue Line Packages" Ericsson >This delayed contribution was presented. Each of the bullet points in the >discussion section were addressed, the results of which are detailed below: >Item 1: Agreed to be included. >Item 2: Rejected. Signal type to remain on/off >Item 3: Agreed to be included. > >TD-WP2-0024 Draft H.248.26 Enhanced Analog Line Packages Editor >This temporary document was presented by the editor and agreed as baseline >text. >It was agreed to put forward H.248.26 for consent at this meeting. The >recommendation for consent is contained in TD-PLEN-0034. > >3.7.6.13 H.248.27 Supplemental Tones Packages > >D-0344 Comments to AVD-2314, "Supplementary Tones Packages" Ericsson >This delayed contribution was presented. Each of the bullet points in the >discussion section were addressed, the results of which are detailed below: >Item 1,2: Agreed to be included >Item 3: Heading should read "Diagnostic Tones" >Item 4: A summary should be added detailing the use of this package. >Item 5: Agreed to be included. > >TD-WP2-0025 Draft H.248.27 Supplemental Tones Packages Editor >This temporary document was presented by the editor and agreed as baseline >text. >It was agreed to put forward H.248.27 for consent at this meeting. The >recommendation for consent is contained in TD-PLEN-0035. > >3.7.6.14 H.248 Sub-Series Packages Guide > >TD-WP2-0018 Proposed additions to H.248 Sub-Series: Packages Guide >Release 4" Editor >This temporary document was presented and the text agreed as baseline. A >comment was made that packages in H.248.23,24,25,26,27,icas, icasc should >be added. The respective drafts in the IETF should point to the ITU work. >The supplement for approval is contained in TD-PLEN-56. > >D-0352 Proposed Liaison to Tiphon on H.248 Packages Ericsson >This delayed contribution was presented and it was agreed to send enclosed >liaison to Tiphon. The outgoing liaison can be found in TD-WP2-56. > >3.7.7 Other Work to Progress > >3.7.7.1 H.248.icas International CAS Packages > >D=0345 Comments to AVD-2316, "International CAS Packages" Ericsson >This delayed contribution was presented. Each of the bullet points in the >discussion section were addressed, the results of which is detailed below: >Item 1: Agreed to be included. >Item 2: Resolved. Signalling is different for R1 and R2. >Item 3: Agreed to be included. > >D=0341 International CAS Compelled Register Signaling Packages Nortel >This delayed contribution was presented and it was agreed to start a work >item on this. This new work item shall be named H.248.icasc. D341 is >considered baseline text. > >TD-WP2=0026 H.248.icas International CAS Packages Editor >This temporary document was presented by the editor and agreed as baseline >text. > >3.7.8 New Work > >3.7.8.1 New Packages for H.248 > >D-0361 Request for an extension package to the H.248 Network Package for >the jitter buffer. (H.248.1 Annex E.11.1) Lucent >This delayed contribution was presented. There was a comment from Mr. >Boyle that if the work was accepted as a package extension the >contribution would need significant editing. Mr. Boyle also questioned the >need for a minimum and nominal jitter value. Mr. Teising replied that >should know the network topology and can provide these values. It was >discussed that the MG would better know the routing of the bearer so it >would be more appropriate for it to provide the values. >It was agreed to persue this work however extensive editing work is needed >as well a scope and summary addressing the above questions. >An editing session meet to draft text for a baseline document. The >baseline shall be referred to as H.248.ajb and is contained in TD-WP2-0052. > >D-0362 Request that an extension package be defined to the H.248 >Congestion Control Package (H.248.10) Lucent >This delayed contribution was presented. Mr.Boyle questioned whether any >consideration had been made to use H.248.11. Mr. Tegeler questioned if >congestion on different routes and directions could be indicated. >Mr.Groves expressed concern that the proposed extensions addressed MG wide >congestion events as well as network congestion events where as the base >H.248.10 only addressed MG events. Mr.Schwarz questioned how congestion of >an IP connection carried over an ATM (AAL5 interface) would be handled? >Mr. Schwarz noted that the resources specified fell in two types: those >dealing with H.248 processing and Media Processing. Due to the number of >questions D362 was not accepted. Mr. Teising undertook to study these >questions and provide an updated contribution at a subsequent question. > > > >_______________________________________________ >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 Jun 2 13:59:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17125 for ; Mon, 2 Jun 2003 13:59:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52HwPB05451; Mon, 2 Jun 2003 13:58:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52Hv9B05401 for ; Mon, 2 Jun 2003 13:57:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17062 for ; Mon, 2 Jun 2003 13:57:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MtWg-00057p-00 for megaco@ietf.org; Mon, 02 Jun 2003 13:55:18 -0400 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 19MtWf-00057m-00 for megaco@ietf.org; Mon, 02 Jun 2003 13:55:17 -0400 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h52Hv2F23892; Mon, 2 Jun 2003 10:57:02 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Mon, 2 Jun 2003 10:57:01 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: megaco@ietf.org cc: "Wijnen, Bert (Bert)" Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2133786286-1221920650-1054569136=:18018" Content-ID: Subject: [Megaco] Re: FW: Request For MIB Review (fwd) Sender: megaco-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. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2133786286-1221920650-1054569136=:18018 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Megaco WG, Bert Wijnen asked me to forward this message to the megaco mailing list. Mike ---------- Forwarded message ---------- Date: Mon, 2 Jun 2003 09:13:15 -0700 (PDT) From: C. M. Heard To: "Wijnen, Bert (Bert)" Cc: "Mreview (E-mail)" Subject: Re: FW: Request For MIB Review Bert, I think that the WG should clean this document up before asking a MIB reviewer to spend time on it. Even after correcting a bunch of routine syntax errors (see 2nd attachment) the MIB module does not even come close to compiling cleanly (see 1st attachment). It is clear from inspection that the document has not been checked for compliance either with http://www.ietf.org/ID-nits.html (e.g., many lines over 80 characters on the front page ... limit is 72) or with draft-ietf-ops-mib-review-guidelines-01.txt (e.g., REVISION clauses don't follow the rules in section 4.5 of that document). I also see that requirements information is in the DESCRIPTION clauses of the OBJECT-GROUP definitions. As discussed here last week, it does not belong there (we should probably add something to section 4.8 of the guidelines doc telling people to put implementation requirements specs in compliance statements ONLY). Mike On Mon, 2 Jun 2003, Wijnen, Bert (Bert) wrote: > Any volunteers? > > Thanks, > Bert > > -----Original Message----- > From: Tom Taylor [mailto:taylor@nortelnetworks.com] > Sent: maandag 2 juni 2003 15:13 > To: bwijnen@lucent.com > Cc: bs@utstar.com; jon.peterson@neustar.biz > Subject: Request For MIB Review > > > The Megaco MIB is about to enter WG Last Call. Could you supply > a MIB doctor to review it? It is available at > http://www.ietf.org/internet-drafts/draft-ietf-megaco-mib-05.txt > > Thanks, > Tom Taylor > taylor@nortelnetworks.com > Megaco WG Chair ---2133786286-1221920650-1054569136=:18018 Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII Content-ID: Content-Description: Re: smilint -l 6 -i namelength-32 MEGACO-MIB (fwd) Return-Path: Received: from postman.bayarea.net (postman.bayarea.net [205.219.84.13]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h52FnZO06627 for ; Mon, 2 Jun 2003 08:49:35 -0700 Received: from psmtp.com (exprod6mx2.postini.com [12.158.35.142]) by postman.bayarea.net (8.12.8p1/8.12.8) with SMTP id h52FnXDH036612 for ; Mon, 2 Jun 2003 08:49:33 -0700 (PDT) Received: from source ([207.106.49.20]) by exprod6mx2.postini.com ([12.158.35.251]) with SMTP; Mon, 02 Jun 2003 11:49:28 EDT Received: from agitator.ibr.cs.tu-bs.de (agitator.ibr.cs.tu-bs.de [134.169.34.18]) by puzzle.pobox.com (Postfix) with ESMTP id 464C526C5CC for ; Mon, 2 Jun 2003 11:49:10 -0400 (EDT) Received: from agitator.ibr.cs.tu-bs.de (localhost [127.0.0.1]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h52Fn5oS020577 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 2 Jun 2003 17:49:05 +0200 Received: (from mail@localhost) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) id h52Fn57j020576; Mon, 2 Jun 2003 17:49:05 +0200 Date: Mon, 2 Jun 2003 17:49:05 +0200 Message-Id: <200306021549.h52Fn57j020576@agitator.ibr.cs.tu-bs.de> X-Authentication-Warning: agitator.ibr.cs.tu-bs.de: mail set sender to '<>' using -f From: smilint@ibr.cs.tu-bs.de Reply-To: smilint-owner@ibr.cs.tu-bs.de Errors-To: smilint-owner@ibr.cs.tu-bs.de To: "C. M. Heard" In-Reply-To: Subject: Re: smilint -l 6 -i namelength-32 MEGACO-MIB X-IBRFilter-SpamReport: -3.4 () IN_REP_TO,NO_REAL_NAME,X_AUTH_WARNING X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) MIME-Version: 1.0 This is an automatically generated mail message in response to a mail message you (or someone else who used your address) sent to . If you want to learn more about this mail service, send a mail message with the "Subject: help" to . This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) has been processed to get the following results: smilint -m -s -l 6 -i namelength-32 MEGACO-MIB MEGACO-MIB:62: [5] {date-year-2digits} warning: date specification `0003201200Z' contains a two-digit year representing `1900' MEGACO-MIB:62: [2] {date-value} date specification `0003201200Z' contains an illegal value MEGACO-MIB:147: [5] {integer-misuse} warning: use Integer32 instead of INTEGER in SMIv2 MEGACO-MIB:353: [4] {hyphen-in-label} warning: named number `dss1-ip' must not include a hyphen in SMIv2 MEGACO-MIB:891: [4] {hyphen-in-label} warning: named number `in-Service' must not include a hyphen in SMIv2 MEGACO-MIB:892: [4] {hyphen-in-label} warning: named number `out-Of-Service' must not include a hyphen in SMIv2 MEGACO-MIB:1144: [3] {notification-object-access} object `medGwyTerminationId' of notification `medGwyInvalidTerminationId' must not be `not-accessible' MEGACO-MIB:1171: [1] {} unknown object identifier label `medGwyTerminationStatus' MEGACO-MIB:1173: [1] {} unknown object identifier label `medGwyTerminationTestStatus' MEGACO-MIB:1169: [3] {notification-object-type} object `medGwyTerminationStatus' of notification `medGwyTerminationStatusChange' must be a scalar or column MEGACO-MIB:1169: [3] {notification-object-type} object `medGwyTerminationTestStatus' of notification `medGwyTerminationStatusChange' must be a scalar or column MEGACO-MIB:1179: [3] {notification-object-access} object `medGwyGatewayId' of notification `medGwyGatewayHandoff' must not be `not-accessible' MEGACO-MIB:1179: [3] {notification-object-access} object `medGwyGatewayControllerId' of notification `medGwyGatewayHandoff' must not be `not-accessible' MEGACO-MIB:1190: [3] {notification-object-access} object `medGwyTerminationId' of notification `medGwyProtocolError' must not be `not-accessible' MEGACO-MIB:449: [4] {group-membership} warning: node `medGwyGatewayRowStatus' must be contained in at least one conformance group MEGACO-MIB:878: [4] {group-membership} warning: node `medGwyTerminationName' must be contained in at least one conformance group MEGACO-MIB:888: [4] {group-membership} warning: node `medGwyTerminationAdminStatus' must be contained in at least one conformance group MEGACO-MIB:909: [4] {group-membership} warning: node `medGwyTerminationOperStatus' must be contained in at least one conformance group MEGACO-MIB:930: [4] {group-membership} warning: node `medGwyTerminationInterfaceIdentifier' must be contained in at least one conformance group MEGACO-MIB:940: [4] {group-membership} warning: node `medGwyTerminationPropertyProfileId' must be contained in at least one conformance group MEGACO-MIB:950: [4] {group-membership} warning: node `medGwyTerminationRowStatus' must be contained in at least one conformance group MEGACO-MIB:1042: [4] {group-membership} warning: node `medGwyPropertyProfileProperty' must be contained in at least one conformance group MEGACO-MIB:1052: [4] {group-membership} warning: node `medGwyTermPropertyProfileStatus' must be contained in at least one conformance group MEGACO-MIB:1113: [4] {group-membership} warning: node `medGwyReceivedElement' must be contained in at least one conformance group ---2133786286-1221920650-1054569136=:18018 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=megaco-mib-syntax-errors Content-ID: Content-Description: Content-Disposition: INLINE *** MEGACO-MIB~ Mon Jun 2 08:14:08 2003 --- MEGACO-MIB Mon Jun 2 08:48:16 2003 *************** *** 8,14 **** IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, ! Integer32, IpAddress, Unsigned32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, --- 8,14 ---- IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, ! Integer32, IpAddress, Unsigned32, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, *************** *** 352,359 **** other (2), -- Other (none from the list below) dss1-ip (3), -- Q931+ ipdc (4), -- IPDC ! megacov1 (5) -- MEGACO/H.248 Version 1 ! megacov2 (6) -- MEGACO/H.248 Version 2 mgcp (7) -- MGCP } MAX-ACCESS read-create --- 352,359 ---- other (2), -- Other (none from the list below) dss1-ip (3), -- Q931+ ipdc (4), -- IPDC ! megacov1 (5), -- MEGACO/H.248 Version 1 ! megacov2 (6), -- MEGACO/H.248 Version 2 mgcp (7) -- MGCP } MAX-ACCESS read-create *************** *** 364,372 **** medGwyGatewaySignalingTptProtocol OBJECT-TYPE SYNTAX INTEGER { ! TCP (1), ! UDP (2), ! SCTP (3), other (4) } MAX-ACCESS read-create --- 364,372 ---- medGwyGatewaySignalingTptProtocol OBJECT-TYPE SYNTAX INTEGER { ! tcp (1), ! udp (2), ! sctp (3), other (4) } MAX-ACCESS read-create *************** *** 401,407 **** up (1), -- ready to communicate with MGC down (2), testing(3), -- in some test mode ! unknown(4), -- status can not be determined -- for some reason. } MAX-ACCESS read-only --- 401,407 ---- up (1), -- ready to communicate with MGC down (2), testing(3), -- in some test mode ! unknown(4) -- status can not be determined -- for some reason. } MAX-ACCESS read-only *************** *** 485,500 **** -- The relationship can be, for example, as follows: -- -- MediaGatewayId medGwyGatewayControllerId ! -- +----------+ medGwyGatewayLinkId +----------+ ! -- | mg1 |----------->------------>| mgc1 | ! -- | +----------+ | | +----------+ ! -- | | mg2 | +------------->| mgc2 | ! -- | | +----------+ | | +----------+ ! -- +-| | mg3 |----------->---------->| | mgc3 | -- | | | | | | | ! -- +-| | +----------->| | -- | | | | ! -- +----------+ +----------+ -- -- ***************************************************************** --- 485,500 ---- -- The relationship can be, for example, as follows: -- -- MediaGatewayId medGwyGatewayControllerId ! -- +-~-~-~-~-~+ medGwyGatewayLinkId +~-~-~-~-~-+ ! -- | mg1 |~-~-~-~-~-~>~-~-~-~-~-~->| mgc1 | ! -- | +-~-~-~-~-~+ | | +~-~-~-~-~-+ ! -- | | mg2 | +~-~-~-~-~-~-~>| mgc2 | ! -- | | +~-~-~-~-~-+ | | +~-~-~-~-~-+ ! -- +-| | mg3 |~-~-~-~-~-~>~-~-~-~-~->| | mgc3 | -- | | | | | | | ! -- +-| | +~-~-~-~-~-~>| | -- | | | | ! -- +~-~-~-~-~-+ +~-~-~-~-~-+ -- -- ***************************************************************** *************** *** 521,528 **** medGwyGatewayControllerId Unsigned32, -- ro medGwyGatewayControllerIPAddress IpAddress, -- rw medGwyGatewayControllerPort Integer32, -- rw ! medGwyGatewayControllerAdminStatus INTEGER -- rw ! medGwyGatewayControllerOperStatus INTEGER, -- ro } medGwyGatewayControllerId OBJECT-TYPE --- 521,528 ---- medGwyGatewayControllerId Unsigned32, -- ro medGwyGatewayControllerIPAddress IpAddress, -- rw medGwyGatewayControllerPort Integer32, -- rw ! medGwyGatewayControllerAdminStatus INTEGER, -- rw ! medGwyGatewayControllerOperStatus INTEGER -- ro } medGwyGatewayControllerId OBJECT-TYPE *************** *** 1245,1251 **** MANDATORY-GROUPS { medGwyConfigGroup, ! medGwyStatsGroup, } GROUP medGwyGWControllerGroup --- 1245,1251 ---- MANDATORY-GROUPS { medGwyConfigGroup, ! medGwyStatsGroup } GROUP medGwyGWControllerGroup ---2133786286-1221920650-1054569136=:18018-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jun 2 14:00:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17191 for ; Mon, 2 Jun 2003 14:00:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52I0Rv05609 for megaco-archive@odin.ietf.org; Mon, 2 Jun 2003 14:00:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52I0RB05606 for ; Mon, 2 Jun 2003 14:00:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17171 for ; Mon, 2 Jun 2003 14:00:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MtZs-00059G-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 13:58:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MtZr-00059D-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 13:58:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52HwPB05451; Mon, 2 Jun 2003 13:58:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52Hv9B05401 for ; Mon, 2 Jun 2003 13:57:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17062 for ; Mon, 2 Jun 2003 13:57:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MtWg-00057p-00 for megaco@ietf.org; Mon, 02 Jun 2003 13:55:18 -0400 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 19MtWf-00057m-00 for megaco@ietf.org; Mon, 02 Jun 2003 13:55:17 -0400 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h52Hv2F23892; Mon, 2 Jun 2003 10:57:02 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Mon, 2 Jun 2003 10:57:01 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: megaco@ietf.org cc: "Wijnen, Bert (Bert)" Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2133786286-1221920650-1054569136=:18018" Content-ID: Subject: [Megaco] Re: FW: Request For MIB Review (fwd) Sender: megaco-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. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2133786286-1221920650-1054569136=:18018 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Megaco WG, Bert Wijnen asked me to forward this message to the megaco mailing list. Mike ---------- Forwarded message ---------- Date: Mon, 2 Jun 2003 09:13:15 -0700 (PDT) From: C. M. Heard To: "Wijnen, Bert (Bert)" Cc: "Mreview (E-mail)" Subject: Re: FW: Request For MIB Review Bert, I think that the WG should clean this document up before asking a MIB reviewer to spend time on it. Even after correcting a bunch of routine syntax errors (see 2nd attachment) the MIB module does not even come close to compiling cleanly (see 1st attachment). It is clear from inspection that the document has not been checked for compliance either with http://www.ietf.org/ID-nits.html (e.g., many lines over 80 characters on the front page ... limit is 72) or with draft-ietf-ops-mib-review-guidelines-01.txt (e.g., REVISION clauses don't follow the rules in section 4.5 of that document). I also see that requirements information is in the DESCRIPTION clauses of the OBJECT-GROUP definitions. As discussed here last week, it does not belong there (we should probably add something to section 4.8 of the guidelines doc telling people to put implementation requirements specs in compliance statements ONLY). Mike On Mon, 2 Jun 2003, Wijnen, Bert (Bert) wrote: > Any volunteers? > > Thanks, > Bert > > -----Original Message----- > From: Tom Taylor [mailto:taylor@nortelnetworks.com] > Sent: maandag 2 juni 2003 15:13 > To: bwijnen@lucent.com > Cc: bs@utstar.com; jon.peterson@neustar.biz > Subject: Request For MIB Review > > > The Megaco MIB is about to enter WG Last Call. Could you supply > a MIB doctor to review it? It is available at > http://www.ietf.org/internet-drafts/draft-ietf-megaco-mib-05.txt > > Thanks, > Tom Taylor > taylor@nortelnetworks.com > Megaco WG Chair ---2133786286-1221920650-1054569136=:18018 Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII Content-ID: Content-Description: Re: smilint -l 6 -i namelength-32 MEGACO-MIB (fwd) Return-Path: Received: from postman.bayarea.net (postman.bayarea.net [205.219.84.13]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h52FnZO06627 for ; Mon, 2 Jun 2003 08:49:35 -0700 Received: from psmtp.com (exprod6mx2.postini.com [12.158.35.142]) by postman.bayarea.net (8.12.8p1/8.12.8) with SMTP id h52FnXDH036612 for ; Mon, 2 Jun 2003 08:49:33 -0700 (PDT) Received: from source ([207.106.49.20]) by exprod6mx2.postini.com ([12.158.35.251]) with SMTP; Mon, 02 Jun 2003 11:49:28 EDT Received: from agitator.ibr.cs.tu-bs.de (agitator.ibr.cs.tu-bs.de [134.169.34.18]) by puzzle.pobox.com (Postfix) with ESMTP id 464C526C5CC for ; Mon, 2 Jun 2003 11:49:10 -0400 (EDT) Received: from agitator.ibr.cs.tu-bs.de (localhost [127.0.0.1]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h52Fn5oS020577 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 2 Jun 2003 17:49:05 +0200 Received: (from mail@localhost) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) id h52Fn57j020576; Mon, 2 Jun 2003 17:49:05 +0200 Date: Mon, 2 Jun 2003 17:49:05 +0200 Message-Id: <200306021549.h52Fn57j020576@agitator.ibr.cs.tu-bs.de> X-Authentication-Warning: agitator.ibr.cs.tu-bs.de: mail set sender to '<>' using -f From: smilint@ibr.cs.tu-bs.de Reply-To: smilint-owner@ibr.cs.tu-bs.de Errors-To: smilint-owner@ibr.cs.tu-bs.de To: "C. M. Heard" In-Reply-To: Subject: Re: smilint -l 6 -i namelength-32 MEGACO-MIB X-IBRFilter-SpamReport: -3.4 () IN_REP_TO,NO_REAL_NAME,X_AUTH_WARNING X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) MIME-Version: 1.0 This is an automatically generated mail message in response to a mail message you (or someone else who used your address) sent to . If you want to learn more about this mail service, send a mail message with the "Subject: help" to . This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) has been processed to get the following results: smilint -m -s -l 6 -i namelength-32 MEGACO-MIB MEGACO-MIB:62: [5] {date-year-2digits} warning: date specification `0003201200Z' contains a two-digit year representing `1900' MEGACO-MIB:62: [2] {date-value} date specification `0003201200Z' contains an illegal value MEGACO-MIB:147: [5] {integer-misuse} warning: use Integer32 instead of INTEGER in SMIv2 MEGACO-MIB:353: [4] {hyphen-in-label} warning: named number `dss1-ip' must not include a hyphen in SMIv2 MEGACO-MIB:891: [4] {hyphen-in-label} warning: named number `in-Service' must not include a hyphen in SMIv2 MEGACO-MIB:892: [4] {hyphen-in-label} warning: named number `out-Of-Service' must not include a hyphen in SMIv2 MEGACO-MIB:1144: [3] {notification-object-access} object `medGwyTerminationId' of notification `medGwyInvalidTerminationId' must not be `not-accessible' MEGACO-MIB:1171: [1] {} unknown object identifier label `medGwyTerminationStatus' MEGACO-MIB:1173: [1] {} unknown object identifier label `medGwyTerminationTestStatus' MEGACO-MIB:1169: [3] {notification-object-type} object `medGwyTerminationStatus' of notification `medGwyTerminationStatusChange' must be a scalar or column MEGACO-MIB:1169: [3] {notification-object-type} object `medGwyTerminationTestStatus' of notification `medGwyTerminationStatusChange' must be a scalar or column MEGACO-MIB:1179: [3] {notification-object-access} object `medGwyGatewayId' of notification `medGwyGatewayHandoff' must not be `not-accessible' MEGACO-MIB:1179: [3] {notification-object-access} object `medGwyGatewayControllerId' of notification `medGwyGatewayHandoff' must not be `not-accessible' MEGACO-MIB:1190: [3] {notification-object-access} object `medGwyTerminationId' of notification `medGwyProtocolError' must not be `not-accessible' MEGACO-MIB:449: [4] {group-membership} warning: node `medGwyGatewayRowStatus' must be contained in at least one conformance group MEGACO-MIB:878: [4] {group-membership} warning: node `medGwyTerminationName' must be contained in at least one conformance group MEGACO-MIB:888: [4] {group-membership} warning: node `medGwyTerminationAdminStatus' must be contained in at least one conformance group MEGACO-MIB:909: [4] {group-membership} warning: node `medGwyTerminationOperStatus' must be contained in at least one conformance group MEGACO-MIB:930: [4] {group-membership} warning: node `medGwyTerminationInterfaceIdentifier' must be contained in at least one conformance group MEGACO-MIB:940: [4] {group-membership} warning: node `medGwyTerminationPropertyProfileId' must be contained in at least one conformance group MEGACO-MIB:950: [4] {group-membership} warning: node `medGwyTerminationRowStatus' must be contained in at least one conformance group MEGACO-MIB:1042: [4] {group-membership} warning: node `medGwyPropertyProfileProperty' must be contained in at least one conformance group MEGACO-MIB:1052: [4] {group-membership} warning: node `medGwyTermPropertyProfileStatus' must be contained in at least one conformance group MEGACO-MIB:1113: [4] {group-membership} warning: node `medGwyReceivedElement' must be contained in at least one conformance group ---2133786286-1221920650-1054569136=:18018 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=megaco-mib-syntax-errors Content-ID: Content-Description: Content-Disposition: INLINE *** MEGACO-MIB~ Mon Jun 2 08:14:08 2003 --- MEGACO-MIB Mon Jun 2 08:48:16 2003 *************** *** 8,14 **** IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, ! Integer32, IpAddress, Unsigned32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, --- 8,14 ---- IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, ! Integer32, IpAddress, Unsigned32, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, *************** *** 352,359 **** other (2), -- Other (none from the list below) dss1-ip (3), -- Q931+ ipdc (4), -- IPDC ! megacov1 (5) -- MEGACO/H.248 Version 1 ! megacov2 (6) -- MEGACO/H.248 Version 2 mgcp (7) -- MGCP } MAX-ACCESS read-create --- 352,359 ---- other (2), -- Other (none from the list below) dss1-ip (3), -- Q931+ ipdc (4), -- IPDC ! megacov1 (5), -- MEGACO/H.248 Version 1 ! megacov2 (6), -- MEGACO/H.248 Version 2 mgcp (7) -- MGCP } MAX-ACCESS read-create *************** *** 364,372 **** medGwyGatewaySignalingTptProtocol OBJECT-TYPE SYNTAX INTEGER { ! TCP (1), ! UDP (2), ! SCTP (3), other (4) } MAX-ACCESS read-create --- 364,372 ---- medGwyGatewaySignalingTptProtocol OBJECT-TYPE SYNTAX INTEGER { ! tcp (1), ! udp (2), ! sctp (3), other (4) } MAX-ACCESS read-create *************** *** 401,407 **** up (1), -- ready to communicate with MGC down (2), testing(3), -- in some test mode ! unknown(4), -- status can not be determined -- for some reason. } MAX-ACCESS read-only --- 401,407 ---- up (1), -- ready to communicate with MGC down (2), testing(3), -- in some test mode ! unknown(4) -- status can not be determined -- for some reason. } MAX-ACCESS read-only *************** *** 485,500 **** -- The relationship can be, for example, as follows: -- -- MediaGatewayId medGwyGatewayControllerId ! -- +----------+ medGwyGatewayLinkId +----------+ ! -- | mg1 |----------->------------>| mgc1 | ! -- | +----------+ | | +----------+ ! -- | | mg2 | +------------->| mgc2 | ! -- | | +----------+ | | +----------+ ! -- +-| | mg3 |----------->---------->| | mgc3 | -- | | | | | | | ! -- +-| | +----------->| | -- | | | | ! -- +----------+ +----------+ -- -- ***************************************************************** --- 485,500 ---- -- The relationship can be, for example, as follows: -- -- MediaGatewayId medGwyGatewayControllerId ! -- +-~-~-~-~-~+ medGwyGatewayLinkId +~-~-~-~-~-+ ! -- | mg1 |~-~-~-~-~-~>~-~-~-~-~-~->| mgc1 | ! -- | +-~-~-~-~-~+ | | +~-~-~-~-~-+ ! -- | | mg2 | +~-~-~-~-~-~-~>| mgc2 | ! -- | | +~-~-~-~-~-+ | | +~-~-~-~-~-+ ! -- +-| | mg3 |~-~-~-~-~-~>~-~-~-~-~->| | mgc3 | -- | | | | | | | ! -- +-| | +~-~-~-~-~-~>| | -- | | | | ! -- +~-~-~-~-~-+ +~-~-~-~-~-+ -- -- ***************************************************************** *************** *** 521,528 **** medGwyGatewayControllerId Unsigned32, -- ro medGwyGatewayControllerIPAddress IpAddress, -- rw medGwyGatewayControllerPort Integer32, -- rw ! medGwyGatewayControllerAdminStatus INTEGER -- rw ! medGwyGatewayControllerOperStatus INTEGER, -- ro } medGwyGatewayControllerId OBJECT-TYPE --- 521,528 ---- medGwyGatewayControllerId Unsigned32, -- ro medGwyGatewayControllerIPAddress IpAddress, -- rw medGwyGatewayControllerPort Integer32, -- rw ! medGwyGatewayControllerAdminStatus INTEGER, -- rw ! medGwyGatewayControllerOperStatus INTEGER -- ro } medGwyGatewayControllerId OBJECT-TYPE *************** *** 1245,1251 **** MANDATORY-GROUPS { medGwyConfigGroup, ! medGwyStatsGroup, } GROUP medGwyGWControllerGroup --- 1245,1251 ---- MANDATORY-GROUPS { medGwyConfigGroup, ! medGwyStatsGroup } GROUP medGwyGWControllerGroup ---2133786286-1221920650-1054569136=:18018-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jun 2 15:19:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20635 for ; Mon, 2 Jun 2003 15:19:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52JHqB12395; Mon, 2 Jun 2003 15:17:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52JG8B12297 for ; Mon, 2 Jun 2003 15:16:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20530 for ; Mon, 2 Jun 2003 15:16:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MulA-0005d2-00 for megaco@ietf.org; Mon, 02 Jun 2003 15:14:20 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19Mul9-0005cx-00 for megaco@ietf.org; Mon, 02 Jun 2003 15:14:19 -0400 Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52JFSY24147; Mon, 2 Jun 2003 15:15:28 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L9VCHYWG; Mon, 2 Jun 2003 15:15:28 -0400 Received: from nortelnetworks.com (acart418.ca.nortel.com [47.129.49.145]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0PHA; Mon, 2 Jun 2003 15:15:26 -0400 Message-ID: <3EDBA24D.6070702@nortelnetworks.com> Date: Mon, 02 Jun 2003 15:15:25 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Aleksandr Ryabin CC: Megaco List Subject: Re: [Megaco] Summary Of SG 16 Meeting Just Concluded References: <5.2.1.1.0.20030602120818.01d1da10@imap.winphoria.com> In-Reply-To: <5.2.1.1.0.20030602120818.01d1da10@imap.winphoria.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04f.nortelnetworks.com id h52JFSY24147 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h52JG8B12298 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Have a look at http://standard.pictel.com/ftp/avc-site/0305_Gen/. Aleksandr Ryabin wrote: > Hi Tom, > > Thanks for the info. > Are the output documents referred below publicly available? > If yes, where from? > > Thanks > Aleks > > At 09:55 AM 6/2/2003, Tom Taylor wrote: > >> For your information, I have extracted the Megaco-relevant portion of >> the SG 16 meeting report. The meeting was held 20-30 May in Geneva. >> >> 3.7.3 Recommendations for Consent >> >> New H.248.22 Shared Risk Group Package TD-PLEN-57 >> New H.248.23 Enhanced Alerting Packages TD-PLEN-32 >> New H.248.24 MF Tone Generation and Detection Packages >> TD-PLEN-33 >> New H.248.25 Basic CAS Packages TD-PLEN-58R1 >> New H.248.26 Enhanced Analogue Line Packages TD-PLEN-34 >> New H.248.27 Supplemental Tones Packages TD-PLEN-35 >> >> 3.7.4 Documents for Approval >> >> H.248 Supp H.248 Sub-Series: Packages Guide Release 4 >> TD-PLEN-56 >> H.248 IG H.248 Sub Series Implementor's Guide TD-PLEN-36R1 >> >> >> 3.7.6 Documents planned for Decision/Consent >> >> 3.7.6.5 H.248 Implementers Guide >> >> TD-GEN-0035 Reply to LS on Rec. H.248 Annex E, Gain and Automatic >> Level Control SG15 >> Addressed at the San Jose February 2003 meeting in AVD-2338. No >> further action needed. >> >> D-0347 Proposed additions to H.248 Implementors' Guide LM Ericsson >> This contribution was presented and it was agreed to incorporate the >> two proposed additions into the H.248 Sub-series implementors' guide. >> It was also agreed that text should be on clarifying what should be >> sent in a reponse to a request that has only actions and no commands. >> This has been added as section 6.18. >> >> TD-WP2-0028 H.248 Sub-series Implementors' Guide Editor >> The editor's draft was presented and accepted. >> It was agreed to put the H.248 Sub-Series Implementors' Guide forward >> for consent. The agreed text can be found in TD-PLEN-0036R1. >> >> 3.7.6.6 H.248.1 Annex F ServiceChange >> >> TD-WP2-0021 Draft H.248.1 Annex F Editor >> The editor's draft was presented and it was noted that there were no >> changes from San Jose output. It was agreed that this document was not >> ready to be put forward for consent. People are encouraged to >> contribute on this in the interim meeting. >> >> TD-WP2-0027 Considerations for discussion of update of >> ServiceChange procedures for H.248 Editor >> The temporary document was presented as a record of the requirements >> for ServiceChange annex work. >> >> 3.7.6.7 H.248.19 Decomposed MCU Audio, Video and Data Conferencing >> Packages >> >> D-0348 Additional requirements for H.248.19 for Chat >> conferencing LM Ericsson >> This delayed contribution was presented and discussion on the >> difference between messaging and chat conferencing. It was agreed to >> add these requirements to H.248.19. Ms.Levin will provide a reference >> to work undertaken in the IETF on this work. This reference should be >> included in the requirements when it becomes available. >> >> D-0349 Addition to H.248.19 for Tiled Windows LM Ericsson >> This delayed contribution was presented. It was noted that even in >> simple video window configuration individual windows may have >> different sizes. It was also noted that in the IETF work is ongoing on >> defining profiles for different configurations. It was agreed to >> accept this work for inclusion to H.248.19 but further changes maybe >> needed to define the use of profiles and the use of non-proportional >> window configurations. >> >> D-0350 Addition to H.248.19 for viewer indication LM Ericsson >> This contribution was presented and there was some discussion on the >> signal type and whether it should be two signals of type brief or one >> signal of type on/off. It was agreed that this should be type brief >> however a better explantion of how this is used should be be included. >> >> TD-WP2-0017 Draft H.248.19, "Decomposed Multipoint Control Unit, >> Audio, Video and Data Conferencing Packages" Editor >> The editor's input was presented and was accepted. >> >> D-0353 Video Coding description in H.245, H.248 and SDP LM >> Ericsson >> This contribution was presented. Discussion highlighted that for many >> video codecs (H.261, H.264) there was not a problem of mapping H.245 >> to SDP however a complete mapping between SDP and H.245 did not exist >> for H.263. Work is ongoing in the IETF to solve this problem through >> the use of profiles or feature description. It was agreed that this >> work should be monitored but this issue is of no consequence to the >> H.248.19 work. >> The output of H.248.19 for this meeting can be found in TD-WP2-60. >> >> 3.7.6.8 H.248.22 Shared Risk Group Handling Package >> >> D-0351 H.248.shrisk additions LM Ericsson >> The contribution was presented and it was agreed to put forward this >> delayed contribution (with editorial corrections) for consent. The >> recommendation for consent can be found in TD-PLEN-57. >> >> 3.7.6.9 H.248.23 Enhanced Alerting Packages >> >> D-0343 Comments to AVD-2313, "Enhanced Alerting Packages" Ericsson >> This delayed contribution was presented. Each of the bullet points in >> the discussion section were addressed, the results of which are >> detailed below: >> Item 1,2: Agreed to be incorporated in H.248.23 >> Item 3: Rejected >> Item 4: Text should be included to clarify what the variable duration >> is dependent on. >> Item 5: The text should be clarified to make clear that an error is >> NOT generated only when the data component of the signal is not >> delivered. All other errors will generate an error. >> Item 6: Text should be included to clarify the use of the TAS signal >> Item 7, 8: Included in editor's draft. >> >> TD-WP2-0022 Draft H.248.23 Enhanced Alerting Packages Editor >> This temporary document was presented. The editor stated that this >> work had existed for 2 years in the IETF and authors decided to move >> it to the ITU. Mr. Okubo questioned whether the IETF had been >> consulted over this move. The IETF had received a liaison from >> Question 3/16 notifying them of the proposal for taking over the work. >> It asked that they respond if there was a problem with this approach. >> No response was received. It was also noted that package development >> was not specifically part of the IETF Megaco WG charter. >> There was a question from Mr.Chatras (France Telecom) as to where the >> checksum should be generated, MGC or MG. The editor replied that as >> the checksum was associated with the data plane the MGC should be >> responsible for generating the checksum. This will be clarified in >> updated text. >> Mr. Chatras also questioned the need of having an example for ETSI >> based encodings. It was agreed that the editor and Mr.Chatras >> co-ordinate on such an example. >> It was agreed that H.248.23 be put forward for consent. The >> recommendation for consent is contained in TD-PLEN-0032. >> >> 3.7.6.10 H.248.24 MF Tone Generation and Detection Packages >> >> D-0342 Comments to AVD-2312, "MF Tone Generation and Detection >> Packages" Ericsson >> This delayed contribution was presented. Each of the bullet points in >> the discussion section were addressed, the results of which are >> detailed below: >> Item 1: Agreed to be incorporated in H.248.24 >> Item 2: Resolved. It was agreed to remove the text "was chosen >> arbitrarily". >> Item 3: Agreed to be incorporated in H.248.24 >> Item 4: Agreed to be incorporated in H.248.24 >> >> TD-WP2-0023 Draft H.248.24 MF Tone Generation and Detection >> Packages Editor >> This temporary document was presented and accepted. >> It was agreed to put forward H.248.24 for consent at this meeting. The >> recommendation for consent is contained in TD-PLEN-0033. >> >> 3.7.6.11 H.248.25 Basic CAS Packages >> >> D-0327 Comments to AVD-2315, "Basic CAS Packages" Ericsson >> This delayed contribution was presented. Each of the bullet points in >> the discussion section were addressed, the results of which are >> detailed below: >> Item 1: Package ID needs to be registered with IANA before final >> approval. >> Item 2: Editor to check if any values have been dropped. >> Item 3,4: Accepted to be resolved. >> Item 5: These values need to be reviewed in line with the comments >> made in D328. >> Item 6: Resolved. The address signal was split in a separate package. >> >> D-0328 H.248 Basic CAS Package ­ CAS Failure Code Extensions Alcatel >> This delayed contribution was presented and listed a number of >> concerns with the CAS package on Glare, Start Dailing Timeout, LTO and >> Polarity. The editor replied that: >> • Glare need not be added as it was already covered by the >> procedure section of the package. >> • Start Dialling Timeout can be handled by the Register Timeout >> Signal in the CAS Address package. >> • LTO there are other events that can be used to indicate this >> situation. >> • Unexpected Line signal could be used to indicate Polarity error. >> It was agreed that this explanation of error conditions should be >> included in H.248.24. >> >> TD-WP2-0016 Draft H.248.25 Basic CAS Packages Editor >> This temporary document was presented by the editor. The editor tabled >> a number of comments from the IETF mailing list: >> 1. Remove RTO as a possible value in bcas/casf event --> ec parameter >> (bcas addresses line signals/events, Register signaling is covered in >> the derived packages, so register failure reporting is outside scope >> of this package) >> 2. Added meth parameter in bcasaddr/addr event (digit map is >> associated with the reporting of this event) >> 3. casblk package has been referred in the icas package there the CAS >> Blocking Package should be included. >> The comments were agreed. The CAS blocking package will be specified >> in the ICAS package. >> It was agreed to put forward H.248.25 for consent at this meeting. A >> Package ID for the "bcasaddr" package has been requested. The >> recommendation for consent is contained in TD-PLEN-58R1. >> >> 3.7.6.12 H.248.26 Enhanced Analog Line Packages >> >> D-0346 Comments to AVD-2317, "Enhanced Analogue Line Packages" Ericsson >> This delayed contribution was presented. Each of the bullet points in >> the discussion section were addressed, the results of which are >> detailed below: >> Item 1: Agreed to be included. >> Item 2: Rejected. Signal type to remain on/off >> Item 3: Agreed to be included. >> >> TD-WP2-0024 Draft H.248.26 Enhanced Analog Line Packages Editor >> This temporary document was presented by the editor and agreed as >> baseline text. >> It was agreed to put forward H.248.26 for consent at this meeting. The >> recommendation for consent is contained in TD-PLEN-0034. >> >> 3.7.6.13 H.248.27 Supplemental Tones Packages >> >> D-0344 Comments to AVD-2314, "Supplementary Tones Packages" Ericsson >> This delayed contribution was presented. Each of the bullet points in >> the discussion section were addressed, the results of which are >> detailed below: >> Item 1,2: Agreed to be included >> Item 3: Heading should read "Diagnostic Tones" >> Item 4: A summary should be added detailing the use of this package. >> Item 5: Agreed to be included. >> >> TD-WP2-0025 Draft H.248.27 Supplemental Tones Packages Editor >> This temporary document was presented by the editor and agreed as >> baseline text. >> It was agreed to put forward H.248.27 for consent at this meeting. The >> recommendation for consent is contained in TD-PLEN-0035. >> >> 3.7.6.14 H.248 Sub-Series Packages Guide >> >> TD-WP2-0018 Proposed additions to H.248 Sub-Series: Packages Guide >> Release 4" Editor >> This temporary document was presented and the text agreed as baseline. >> A comment was made that packages in H.248.23,24,25,26,27,icas, icasc >> should be added. The respective drafts in the IETF should point to the >> ITU work. The supplement for approval is contained in TD-PLEN-56. >> >> D-0352 Proposed Liaison to Tiphon on H.248 Packages Ericsson >> This delayed contribution was presented and it was agreed to send >> enclosed liaison to Tiphon. The outgoing liaison can be found in >> TD-WP2-56. >> >> 3.7.7 Other Work to Progress >> >> 3.7.7.1 H.248.icas International CAS Packages >> >> D=0345 Comments to AVD-2316, "International CAS Packages" Ericsson >> This delayed contribution was presented. Each of the bullet points in >> the discussion section were addressed, the results of which is >> detailed below: >> Item 1: Agreed to be included. >> Item 2: Resolved. Signalling is different for R1 and R2. >> Item 3: Agreed to be included. >> >> D=0341 International CAS Compelled Register Signaling Packages Nortel >> This delayed contribution was presented and it was agreed to start a >> work item on this. This new work item shall be named H.248.icasc. D341 >> is considered baseline text. >> >> TD-WP2=0026 H.248.icas International CAS Packages Editor >> This temporary document was presented by the editor and agreed as >> baseline text. >> >> 3.7.8 New Work >> >> 3.7.8.1 New Packages for H.248 >> >> D-0361 Request for an extension package to the H.248 Network Package >> for the jitter buffer. (H.248.1 Annex E.11.1) Lucent >> This delayed contribution was presented. There was a comment from Mr. >> Boyle that if the work was accepted as a package extension the >> contribution would need significant editing. Mr. Boyle also questioned >> the need for a minimum and nominal jitter value. Mr. Teising replied >> that should know the network topology and can provide these values. It >> was discussed that the MG would better know the routing of the bearer >> so it would be more appropriate for it to provide the values. >> It was agreed to persue this work however extensive editing work is >> needed as well a scope and summary addressing the above questions. >> An editing session meet to draft text for a baseline document. The >> baseline shall be referred to as H.248.ajb and is contained in >> TD-WP2-0052. >> >> D-0362 Request that an extension package be defined to the H.248 >> Congestion Control Package (H.248.10) Lucent >> This delayed contribution was presented. Mr.Boyle questioned whether >> any consideration had been made to use H.248.11. Mr. Tegeler >> questioned if congestion on different routes and directions could be >> indicated. Mr.Groves expressed concern that the proposed extensions >> addressed MG wide congestion events as well as network congestion >> events where as the base H.248.10 only addressed MG events. Mr.Schwarz >> questioned how congestion of an IP connection carried over an ATM >> (AAL5 interface) would be handled? Mr. Schwarz noted that the >> resources specified fell in two types: those dealing with H.248 >> processing and Media Processing. Due to the number of questions D362 >> was not accepted. Mr. Teising undertook to study these questions and >> provide an updated contribution at a subsequent question. >> >> >> >> _______________________________________________ >> 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 Jun 2 15:20:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20655 for ; Mon, 2 Jun 2003 15:20:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52JJ8B12526; Mon, 2 Jun 2003 15:19:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52I7lB06779 for ; Mon, 2 Jun 2003 14:07:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17593 for ; Mon, 2 Jun 2003 14:07:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mtgy-0005Ej-00 for megaco@ietf.org; Mon, 02 Jun 2003 14:05:56 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19Mtgx-0005EY-00 for megaco@ietf.org; Mon, 02 Jun 2003 14:05:56 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h52I7A2J029401; Mon, 2 Jun 2003 11:07:10 -0700 (PDT) Received: from cisco.com (dhcp-171-71-9-206.cisco.com [171.71.9.206]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AER43999; Mon, 2 Jun 2003 11:07:09 -0700 (PDT) Message-ID: <3EDB924D.9D5BAB1E@cisco.com> Date: Mon, 02 Jun 2003 11:07:09 -0700 From: Malathi Anand X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: megaco@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] CAS pkg definition Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, I could not find the email addresses of the authors of doc AVD-2315. Hence email to this alias to get some answers. 1. Under the bcasaddr pkg also defined in the above doc., the description for section 8.1.1 (New Property) is missing? What is this parameter for? How will it be used? 2. Under the osext pkg defined in above doc.,in section 11.2.4/11.2.5, what does "operator attached" and "operator released" mean? The description is not too clear. When will these events be notified/signaled? Thanks. -Malathi _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jun 2 15:21:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20702 for ; Mon, 2 Jun 2003 15:21:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52JKW512653 for megaco-archive@odin.ietf.org; Mon, 2 Jun 2003 15:20:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52JKVB12650 for ; Mon, 2 Jun 2003 15:20:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20674 for ; Mon, 2 Jun 2003 15:20:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MupQ-0005eU-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 15:18:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MupP-0005eQ-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 15:18:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52JHqB12395; Mon, 2 Jun 2003 15:17:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52JG8B12297 for ; Mon, 2 Jun 2003 15:16:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20530 for ; Mon, 2 Jun 2003 15:16:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MulA-0005d2-00 for megaco@ietf.org; Mon, 02 Jun 2003 15:14:20 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19Mul9-0005cx-00 for megaco@ietf.org; Mon, 02 Jun 2003 15:14:19 -0400 Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52JFSY24147; Mon, 2 Jun 2003 15:15:28 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L9VCHYWG; Mon, 2 Jun 2003 15:15:28 -0400 Received: from nortelnetworks.com (acart418.ca.nortel.com [47.129.49.145]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0PHA; Mon, 2 Jun 2003 15:15:26 -0400 Message-ID: <3EDBA24D.6070702@nortelnetworks.com> Date: Mon, 02 Jun 2003 15:15:25 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Aleksandr Ryabin CC: Megaco List Subject: Re: [Megaco] Summary Of SG 16 Meeting Just Concluded References: <5.2.1.1.0.20030602120818.01d1da10@imap.winphoria.com> In-Reply-To: <5.2.1.1.0.20030602120818.01d1da10@imap.winphoria.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04f.nortelnetworks.com id h52JFSY24147 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h52JG8B12298 Sender: megaco-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-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h52JHqB12395 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h52JKVB12650 Content-Transfer-Encoding: 8bit Have a look at http://standard.pictel.com/ftp/avc-site/0305_Gen/. Aleksandr Ryabin wrote: > Hi Tom, > > Thanks for the info. > Are the output documents referred below publicly available? > If yes, where from? > > Thanks > Aleks > > At 09:55 AM 6/2/2003, Tom Taylor wrote: > >> For your information, I have extracted the Megaco-relevant portion of >> the SG 16 meeting report. The meeting was held 20-30 May in Geneva. >> >> 3.7.3 Recommendations for Consent >> >> New H.248.22 Shared Risk Group Package TD-PLEN-57 >> New H.248.23 Enhanced Alerting Packages TD-PLEN-32 >> New H.248.24 MF Tone Generation and Detection Packages >> TD-PLEN-33 >> New H.248.25 Basic CAS Packages TD-PLEN-58R1 >> New H.248.26 Enhanced Analogue Line Packages TD-PLEN-34 >> New H.248.27 Supplemental Tones Packages TD-PLEN-35 >> >> 3.7.4 Documents for Approval >> >> H.248 Supp H.248 Sub-Series: Packages Guide Release 4 >> TD-PLEN-56 >> H.248 IG H.248 Sub Series Implementor's Guide TD-PLEN-36R1 >> >> >> 3.7.6 Documents planned for Decision/Consent >> >> 3.7.6.5 H.248 Implementers Guide >> >> TD-GEN-0035 Reply to LS on Rec. H.248 Annex E, Gain and Automatic >> Level Control SG15 >> Addressed at the San Jose February 2003 meeting in AVD-2338. No >> further action needed. >> >> D-0347 Proposed additions to H.248 Implementors' Guide LM Ericsson >> This contribution was presented and it was agreed to incorporate the >> two proposed additions into the H.248 Sub-series implementors' guide. >> It was also agreed that text should be on clarifying what should be >> sent in a reponse to a request that has only actions and no commands. >> This has been added as section 6.18. >> >> TD-WP2-0028 H.248 Sub-series Implementors' Guide Editor >> The editor's draft was presented and accepted. >> It was agreed to put the H.248 Sub-Series Implementors' Guide forward >> for consent. The agreed text can be found in TD-PLEN-0036R1. >> >> 3.7.6.6 H.248.1 Annex F ServiceChange >> >> TD-WP2-0021 Draft H.248.1 Annex F Editor >> The editor's draft was presented and it was noted that there were no >> changes from San Jose output. It was agreed that this document was not >> ready to be put forward for consent. People are encouraged to >> contribute on this in the interim meeting. >> >> TD-WP2-0027 Considerations for discussion of update of >> ServiceChange procedures for H.248 Editor >> The temporary document was presented as a record of the requirements >> for ServiceChange annex work. >> >> 3.7.6.7 H.248.19 Decomposed MCU Audio, Video and Data Conferencing >> Packages >> >> D-0348 Additional requirements for H.248.19 for Chat >> conferencing LM Ericsson >> This delayed contribution was presented and discussion on the >> difference between messaging and chat conferencing. It was agreed to >> add these requirements to H.248.19. Ms.Levin will provide a reference >> to work undertaken in the IETF on this work. This reference should be >> included in the requirements when it becomes available. >> >> D-0349 Addition to H.248.19 for Tiled Windows LM Ericsson >> This delayed contribution was presented. It was noted that even in >> simple video window configuration individual windows may have >> different sizes. It was also noted that in the IETF work is ongoing on >> defining profiles for different configurations. It was agreed to >> accept this work for inclusion to H.248.19 but further changes maybe >> needed to define the use of profiles and the use of non-proportional >> window configurations. >> >> D-0350 Addition to H.248.19 for viewer indication LM Ericsson >> This contribution was presented and there was some discussion on the >> signal type and whether it should be two signals of type brief or one >> signal of type on/off. It was agreed that this should be type brief >> however a better explantion of how this is used should be be included. >> >> TD-WP2-0017 Draft H.248.19, "Decomposed Multipoint Control Unit, >> Audio, Video and Data Conferencing Packages" Editor >> The editor's input was presented and was accepted. >> >> D-0353 Video Coding description in H.245, H.248 and SDP LM >> Ericsson >> This contribution was presented. Discussion highlighted that for many >> video codecs (H.261, H.264) there was not a problem of mapping H.245 >> to SDP however a complete mapping between SDP and H.245 did not exist >> for H.263. Work is ongoing in the IETF to solve this problem through >> the use of profiles or feature description. It was agreed that this >> work should be monitored but this issue is of no consequence to the >> H.248.19 work. >> The output of H.248.19 for this meeting can be found in TD-WP2-60. >> >> 3.7.6.8 H.248.22 Shared Risk Group Handling Package >> >> D-0351 H.248.shrisk additions LM Ericsson >> The contribution was presented and it was agreed to put forward this >> delayed contribution (with editorial corrections) for consent. The >> recommendation for consent can be found in TD-PLEN-57. >> >> 3.7.6.9 H.248.23 Enhanced Alerting Packages >> >> D-0343 Comments to AVD-2313, "Enhanced Alerting Packages" Ericsson >> This delayed contribution was presented. Each of the bullet points in >> the discussion section were addressed, the results of which are >> detailed below: >> Item 1,2: Agreed to be incorporated in H.248.23 >> Item 3: Rejected >> Item 4: Text should be included to clarify what the variable duration >> is dependent on. >> Item 5: The text should be clarified to make clear that an error is >> NOT generated only when the data component of the signal is not >> delivered. All other errors will generate an error. >> Item 6: Text should be included to clarify the use of the TAS signal >> Item 7, 8: Included in editor's draft. >> >> TD-WP2-0022 Draft H.248.23 Enhanced Alerting Packages Editor >> This temporary document was presented. The editor stated that this >> work had existed for 2 years in the IETF and authors decided to move >> it to the ITU. Mr. Okubo questioned whether the IETF had been >> consulted over this move. The IETF had received a liaison from >> Question 3/16 notifying them of the proposal for taking over the work. >> It asked that they respond if there was a problem with this approach. >> No response was received. It was also noted that package development >> was not specifically part of the IETF Megaco WG charter. >> There was a question from Mr.Chatras (France Telecom) as to where the >> checksum should be generated, MGC or MG. The editor replied that as >> the checksum was associated with the data plane the MGC should be >> responsible for generating the checksum. This will be clarified in >> updated text. >> Mr. Chatras also questioned the need of having an example for ETSI >> based encodings. It was agreed that the editor and Mr.Chatras >> co-ordinate on such an example. >> It was agreed that H.248.23 be put forward for consent. The >> recommendation for consent is contained in TD-PLEN-0032. >> >> 3.7.6.10 H.248.24 MF Tone Generation and Detection Packages >> >> D-0342 Comments to AVD-2312, "MF Tone Generation and Detection >> Packages" Ericsson >> This delayed contribution was presented. Each of the bullet points in >> the discussion section were addressed, the results of which are >> detailed below: >> Item 1: Agreed to be incorporated in H.248.24 >> Item 2: Resolved. It was agreed to remove the text "was chosen >> arbitrarily". >> Item 3: Agreed to be incorporated in H.248.24 >> Item 4: Agreed to be incorporated in H.248.24 >> >> TD-WP2-0023 Draft H.248.24 MF Tone Generation and Detection >> Packages Editor >> This temporary document was presented and accepted. >> It was agreed to put forward H.248.24 for consent at this meeting. The >> recommendation for consent is contained in TD-PLEN-0033. >> >> 3.7.6.11 H.248.25 Basic CAS Packages >> >> D-0327 Comments to AVD-2315, "Basic CAS Packages" Ericsson >> This delayed contribution was presented. Each of the bullet points in >> the discussion section were addressed, the results of which are >> detailed below: >> Item 1: Package ID needs to be registered with IANA before final >> approval. >> Item 2: Editor to check if any values have been dropped. >> Item 3,4: Accepted to be resolved. >> Item 5: These values need to be reviewed in line with the comments >> made in D328. >> Item 6: Resolved. The address signal was split in a separate package. >> >> D-0328 H.248 Basic CAS Package ­ CAS Failure Code Extensions Alcatel >> This delayed contribution was presented and listed a number of >> concerns with the CAS package on Glare, Start Dailing Timeout, LTO and >> Polarity. The editor replied that: >> • Glare need not be added as it was already covered by the >> procedure section of the package. >> • Start Dialling Timeout can be handled by the Register Timeout >> Signal in the CAS Address package. >> • LTO there are other events that can be used to indicate this >> situation. >> • Unexpected Line signal could be used to indicate Polarity error. >> It was agreed that this explanation of error conditions should be >> included in H.248.24. >> >> TD-WP2-0016 Draft H.248.25 Basic CAS Packages Editor >> This temporary document was presented by the editor. The editor tabled >> a number of comments from the IETF mailing list: >> 1. Remove RTO as a possible value in bcas/casf event --> ec parameter >> (bcas addresses line signals/events, Register signaling is covered in >> the derived packages, so register failure reporting is outside scope >> of this package) >> 2. Added meth parameter in bcasaddr/addr event (digit map is >> associated with the reporting of this event) >> 3. casblk package has been referred in the icas package there the CAS >> Blocking Package should be included. >> The comments were agreed. The CAS blocking package will be specified >> in the ICAS package. >> It was agreed to put forward H.248.25 for consent at this meeting. A >> Package ID for the "bcasaddr" package has been requested. The >> recommendation for consent is contained in TD-PLEN-58R1. >> >> 3.7.6.12 H.248.26 Enhanced Analog Line Packages >> >> D-0346 Comments to AVD-2317, "Enhanced Analogue Line Packages" Ericsson >> This delayed contribution was presented. Each of the bullet points in >> the discussion section were addressed, the results of which are >> detailed below: >> Item 1: Agreed to be included. >> Item 2: Rejected. Signal type to remain on/off >> Item 3: Agreed to be included. >> >> TD-WP2-0024 Draft H.248.26 Enhanced Analog Line Packages Editor >> This temporary document was presented by the editor and agreed as >> baseline text. >> It was agreed to put forward H.248.26 for consent at this meeting. The >> recommendation for consent is contained in TD-PLEN-0034. >> >> 3.7.6.13 H.248.27 Supplemental Tones Packages >> >> D-0344 Comments to AVD-2314, "Supplementary Tones Packages" Ericsson >> This delayed contribution was presented. Each of the bullet points in >> the discussion section were addressed, the results of which are >> detailed below: >> Item 1,2: Agreed to be included >> Item 3: Heading should read "Diagnostic Tones" >> Item 4: A summary should be added detailing the use of this package. >> Item 5: Agreed to be included. >> >> TD-WP2-0025 Draft H.248.27 Supplemental Tones Packages Editor >> This temporary document was presented by the editor and agreed as >> baseline text. >> It was agreed to put forward H.248.27 for consent at this meeting. The >> recommendation for consent is contained in TD-PLEN-0035. >> >> 3.7.6.14 H.248 Sub-Series Packages Guide >> >> TD-WP2-0018 Proposed additions to H.248 Sub-Series: Packages Guide >> Release 4" Editor >> This temporary document was presented and the text agreed as baseline. >> A comment was made that packages in H.248.23,24,25,26,27,icas, icasc >> should be added. The respective drafts in the IETF should point to the >> ITU work. The supplement for approval is contained in TD-PLEN-56. >> >> D-0352 Proposed Liaison to Tiphon on H.248 Packages Ericsson >> This delayed contribution was presented and it was agreed to send >> enclosed liaison to Tiphon. The outgoing liaison can be found in >> TD-WP2-56. >> >> 3.7.7 Other Work to Progress >> >> 3.7.7.1 H.248.icas International CAS Packages >> >> D=0345 Comments to AVD-2316, "International CAS Packages" Ericsson >> This delayed contribution was presented. Each of the bullet points in >> the discussion section were addressed, the results of which is >> detailed below: >> Item 1: Agreed to be included. >> Item 2: Resolved. Signalling is different for R1 and R2. >> Item 3: Agreed to be included. >> >> D=0341 International CAS Compelled Register Signaling Packages Nortel >> This delayed contribution was presented and it was agreed to start a >> work item on this. This new work item shall be named H.248.icasc. D341 >> is considered baseline text. >> >> TD-WP2=0026 H.248.icas International CAS Packages Editor >> This temporary document was presented by the editor and agreed as >> baseline text. >> >> 3.7.8 New Work >> >> 3.7.8.1 New Packages for H.248 >> >> D-0361 Request for an extension package to the H.248 Network Package >> for the jitter buffer. (H.248.1 Annex E.11.1) Lucent >> This delayed contribution was presented. There was a comment from Mr. >> Boyle that if the work was accepted as a package extension the >> contribution would need significant editing. Mr. Boyle also questioned >> the need for a minimum and nominal jitter value. Mr. Teising replied >> that should know the network topology and can provide these values. It >> was discussed that the MG would better know the routing of the bearer >> so it would be more appropriate for it to provide the values. >> It was agreed to persue this work however extensive editing work is >> needed as well a scope and summary addressing the above questions. >> An editing session meet to draft text for a baseline document. The >> baseline shall be referred to as H.248.ajb and is contained in >> TD-WP2-0052. >> >> D-0362 Request that an extension package be defined to the H.248 >> Congestion Control Package (H.248.10) Lucent >> This delayed contribution was presented. Mr.Boyle questioned whether >> any consideration had been made to use H.248.11. Mr. Tegeler >> questioned if congestion on different routes and directions could be >> indicated. Mr.Groves expressed concern that the proposed extensions >> addressed MG wide congestion events as well as network congestion >> events where as the base H.248.10 only addressed MG events. Mr.Schwarz >> questioned how congestion of an IP connection carried over an ATM >> (AAL5 interface) would be handled? Mr. Schwarz noted that the >> resources specified fell in two types: those dealing with H.248 >> processing and Media Processing. Due to the number of questions D362 >> was not accepted. Mr. Teising undertook to study these questions and >> provide an updated contribution at a subsequent question. >> >> >> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jun 2 15:21:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20755 for ; Mon, 2 Jun 2003 15:21:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52JKsp12701 for megaco-archive@odin.ietf.org; Mon, 2 Jun 2003 15:20:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52JKrB12696 for ; Mon, 2 Jun 2003 15:20:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20690 for ; Mon, 2 Jun 2003 15:20:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mupl-0005ez-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 15:19:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Mupl-0005ew-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 15:19:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52JJ8B12526; Mon, 2 Jun 2003 15:19:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52I7lB06779 for ; Mon, 2 Jun 2003 14:07:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17593 for ; Mon, 2 Jun 2003 14:07:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mtgy-0005Ej-00 for megaco@ietf.org; Mon, 02 Jun 2003 14:05:56 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19Mtgx-0005EY-00 for megaco@ietf.org; Mon, 02 Jun 2003 14:05:56 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h52I7A2J029401; Mon, 2 Jun 2003 11:07:10 -0700 (PDT) Received: from cisco.com (dhcp-171-71-9-206.cisco.com [171.71.9.206]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AER43999; Mon, 2 Jun 2003 11:07:09 -0700 (PDT) Message-ID: <3EDB924D.9D5BAB1E@cisco.com> Date: Mon, 02 Jun 2003 11:07:09 -0700 From: Malathi Anand X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: megaco@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] CAS pkg definition Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I could not find the email addresses of the authors of doc AVD-2315. Hence email to this alias to get some answers. 1. Under the bcasaddr pkg also defined in the above doc., the description for section 8.1.1 (New Property) is missing? What is this parameter for? How will it be used? 2. Under the osext pkg defined in above doc.,in section 11.2.4/11.2.5, what does "operator attached" and "operator released" mean? The description is not too clear. When will these events be notified/signaled? Thanks. -Malathi _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jun 2 16:22:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22591 for ; Mon, 2 Jun 2003 16:22:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52KL4B17698; Mon, 2 Jun 2003 16:21:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52KJHB17571 for ; Mon, 2 Jun 2003 16:19:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22533 for ; Mon, 2 Jun 2003 16:19:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MvkG-00065p-00 for megaco@ietf.org; Mon, 02 Jun 2003 16:17:28 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19MvkF-00065S-00 for megaco@ietf.org; Mon, 02 Jun 2003 16:17:27 -0400 Received: from smilevm.winphoria.com ([10.14.25.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 2 Jun 2003 16:18:42 -0400 Message-Id: <5.2.1.1.0.20030602180527.02b1b518@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 02 Jun 2003 18:09:51 -0400 To: Tom Taylor , Megaco List From: Aleksandr Ryabin Subject: Re: [Megaco] Summary Of SG 16 Meeting Just Concluded In-Reply-To: <3EDBA24D.6070702@nortelnetworks.com> References: <5.2.1.1.0.20030602120818.01d1da10@imap.winphoria.com> <5.2.1.1.0.20030602120818.01d1da10@imap.winphoria.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 02 Jun 2003 20:18:42.0979 (UTC) FILETIME=[29A65F30:01C32944] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h52KJHB17572 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I did, it only contains input documents. Where are the output docs? e.g TD-PLEN-57, etc.? At 03:15 PM 6/2/2003, Tom Taylor wrote: >Have a look at http://standard.pictel.com/ftp/avc-site/0305_Gen/. > >Aleksandr Ryabin wrote: > >>Hi Tom, >>Thanks for the info. >>Are the output documents referred below publicly available? >>If yes, where from? >>Thanks >> Aleks >>At 09:55 AM 6/2/2003, Tom Taylor wrote: >> >>>For your information, I have extracted the Megaco-relevant portion of >>>the SG 16 meeting report. The meeting was held 20-30 May in Geneva. >>> >>>3.7.3 Recommendations for Consent >>> >>>New H.248.22 Shared Risk Group Package TD-PLEN-57 >>>New H.248.23 Enhanced Alerting Packages TD-PLEN-32 >>>New H.248.24 MF Tone Generation and Detection Packages >>>TD-PLEN-33 >>>New H.248.25 Basic CAS Packages TD-PLEN-58R1 >>>New H.248.26 Enhanced Analogue Line Packages TD-PLEN-34 >>>New H.248.27 Supplemental Tones Packages TD-PLEN-35 >>> >>>3.7.4 Documents for Approval >>> >>>H.248 Supp H.248 Sub-Series: Packages Guide Release 4 >>>TD-PLEN-56 >>>H.248 IG H.248 Sub Series Implementor's Guide TD-PLEN-36R1 >>> >>> >>>3.7.6 Documents planned for Decision/Consent >>> >>>3.7.6.5 H.248 Implementers Guide >>> >>>TD-GEN-0035 Reply to LS on Rec. H.248 Annex E, Gain and Automatic >>>Level Control SG15 >>>Addressed at the San Jose February 2003 meeting in AVD-2338. No further >>>action needed. >>> >>>D-0347 Proposed additions to H.248 Implementors' Guide LM Ericsson >>>This contribution was presented and it was agreed to incorporate the two >>>proposed additions into the H.248 Sub-series implementors' guide. It was >>>also agreed that text should be on clarifying what should be sent in a >>>reponse to a request that has only actions and no commands. This has >>>been added as section 6.18. >>> >>>TD-WP2-0028 H.248 Sub-series Implementors' Guide Editor >>>The editor's draft was presented and accepted. >>>It was agreed to put the H.248 Sub-Series Implementors' Guide forward >>>for consent. The agreed text can be found in TD-PLEN-0036R1. >>> >>>3.7.6.6 H.248.1 Annex F ServiceChange >>> >>>TD-WP2-0021 Draft H.248.1 Annex F Editor >>>The editor's draft was presented and it was noted that there were no >>>changes from San Jose output. It was agreed that this document was not >>>ready to be put forward for consent. People are encouraged to contribute >>>on this in the interim meeting. >>> >>>TD-WP2-0027 Considerations for discussion of update of ServiceChange >>>procedures for H.248 Editor >>>The temporary document was presented as a record of the requirements for >>>ServiceChange annex work. >>> >>>3.7.6.7 H.248.19 Decomposed MCU Audio, Video and Data Conferencing Packages >>> >>>D-0348 Additional requirements for H.248.19 for Chat >>>conferencing LM Ericsson >>>This delayed contribution was presented and discussion on the difference >>>between messaging and chat conferencing. It was agreed to add these >>>requirements to H.248.19. Ms.Levin will provide a reference to work >>>undertaken in the IETF on this work. This reference should be included >>>in the requirements when it becomes available. >>> >>>D-0349 Addition to H.248.19 for Tiled Windows LM Ericsson >>>This delayed contribution was presented. It was noted that even in >>>simple video window configuration individual windows may have different >>>sizes. It was also noted that in the IETF work is ongoing on defining >>>profiles for different configurations. It was agreed to accept this work >>>for inclusion to H.248.19 but further changes maybe needed to define the >>>use of profiles and the use of non-proportional window configurations. >>> >>>D-0350 Addition to H.248.19 for viewer indication LM Ericsson >>>This contribution was presented and there was some discussion on the >>>signal type and whether it should be two signals of type brief or one >>>signal of type on/off. It was agreed that this should be type brief >>>however a better explantion of how this is used should be be included. >>> >>>TD-WP2-0017 Draft H.248.19, "Decomposed Multipoint Control Unit, >>>Audio, Video and Data Conferencing Packages" Editor >>>The editor's input was presented and was accepted. >>> >>>D-0353 Video Coding description in H.245, H.248 and SDP LM Ericsson >>>This contribution was presented. Discussion highlighted that for many >>>video codecs (H.261, H.264) there was not a problem of mapping H.245 to >>>SDP however a complete mapping between SDP and H.245 did not exist for >>>H.263. Work is ongoing in the IETF to solve this problem through the use >>>of profiles or feature description. It was agreed that this work should >>>be monitored but this issue is of no consequence to the H.248.19 work. >>>The output of H.248.19 for this meeting can be found in TD-WP2-60. >>> >>>3.7.6.8 H.248.22 Shared Risk Group Handling Package >>> >>>D-0351 H.248.shrisk additions LM Ericsson >>>The contribution was presented and it was agreed to put forward this >>>delayed contribution (with editorial corrections) for consent. The >>>recommendation for consent can be found in TD-PLEN-57. >>> >>>3.7.6.9 H.248.23 Enhanced Alerting Packages >>> >>>D-0343 Comments to AVD-2313, "Enhanced Alerting Packages" Ericsson >>>This delayed contribution was presented. Each of the bullet points in >>>the discussion section were addressed, the results of which are detailed below: >>>Item 1,2: Agreed to be incorporated in H.248.23 >>>Item 3: Rejected >>>Item 4: Text should be included to clarify what the variable duration is >>>dependent on. >>>Item 5: The text should be clarified to make clear that an error is NOT >>>generated only when the data component of the signal is not delivered. >>>All other errors will generate an error. >>>Item 6: Text should be included to clarify the use of the TAS signal >>>Item 7, 8: Included in editor's draft. >>> >>>TD-WP2-0022 Draft H.248.23 Enhanced Alerting Packages Editor >>>This temporary document was presented. The editor stated that this work >>>had existed for 2 years in the IETF and authors decided to move it to >>>the ITU. Mr. Okubo questioned whether the IETF had been consulted over >>>this move. The IETF had received a liaison from Question 3/16 notifying >>>them of the proposal for taking over the work. It asked that they >>>respond if there was a problem with this approach. No response was >>>received. It was also noted that package development was not >>>specifically part of the IETF Megaco WG charter. >>>There was a question from Mr.Chatras (France Telecom) as to where the >>>checksum should be generated, MGC or MG. The editor replied that as the >>>checksum was associated with the data plane the MGC should be >>>responsible for generating the checksum. This will be clarified in >>>updated text. >>>Mr. Chatras also questioned the need of having an example for ETSI based >>>encodings. It was agreed that the editor and Mr.Chatras co-ordinate on >>>such an example. >>>It was agreed that H.248.23 be put forward for consent. The >>>recommendation for consent is contained in TD-PLEN-0032. >>> >>>3.7.6.10 H.248.24 MF Tone Generation and Detection Packages >>> >>>D-0342 Comments to AVD-2312, "MF Tone Generation and Detection >>>Packages" Ericsson >>>This delayed contribution was presented. Each of the bullet points in >>>the discussion section were addressed, the results of which are detailed below: >>>Item 1: Agreed to be incorporated in H.248.24 >>>Item 2: Resolved. It was agreed to remove the text "was chosen arbitrarily". >>>Item 3: Agreed to be incorporated in H.248.24 >>>Item 4: Agreed to be incorporated in H.248.24 >>> >>>TD-WP2-0023 Draft H.248.24 MF Tone Generation and Detection >>>Packages Editor >>>This temporary document was presented and accepted. >>>It was agreed to put forward H.248.24 for consent at this meeting. The >>>recommendation for consent is contained in TD-PLEN-0033. >>> >>>3.7.6.11 H.248.25 Basic CAS Packages >>> >>>D-0327 Comments to AVD-2315, "Basic CAS Packages" Ericsson >>>This delayed contribution was presented. Each of the bullet points in >>>the discussion section were addressed, the results of which are detailed below: >>>Item 1: Package ID needs to be registered with IANA before final approval. >>>Item 2: Editor to check if any values have been dropped. >>>Item 3,4: Accepted to be resolved. >>>Item 5: These values need to be reviewed in line with the comments made >>>in D328. >>>Item 6: Resolved. The address signal was split in a separate package. >>> >>>D-0328 H.248 Basic CAS Package ­ CAS Failure Code Extensions Alcatel >>>This delayed contribution was presented and listed a number of concerns >>>with the CAS package on Glare, Start Dailing Timeout, LTO and Polarity. >>>The editor replied that: >>>• Glare need not be added as it was already covered by the >>>procedure section of the package. >>>• Start Dialling Timeout can be handled by the Register Timeout >>>Signal in the CAS Address package. >>>• LTO there are other events that can be used to indicate this >>>situation. >>>• Unexpected Line signal could be used to indicate Polarity error. >>>It was agreed that this explanation of error conditions should be >>>included in H.248.24. >>> >>>TD-WP2-0016 Draft H.248.25 Basic CAS Packages Editor >>>This temporary document was presented by the editor. The editor tabled a >>>number of comments from the IETF mailing list: >>>1. Remove RTO as a possible value in bcas/casf event --> ec parameter >>>(bcas addresses line signals/events, Register signaling is covered in >>>the derived packages, so register failure reporting is outside scope of >>>this package) >>>2. Added meth parameter in bcasaddr/addr event (digit map is associated >>>with the reporting of this event) >>>3. casblk package has been referred in the icas package there the CAS >>>Blocking Package should be included. >>>The comments were agreed. The CAS blocking package will be specified in >>>the ICAS package. >>>It was agreed to put forward H.248.25 for consent at this meeting. A >>>Package ID for the "bcasaddr" package has been requested. The >>>recommendation for consent is contained in TD-PLEN-58R1. >>> >>>3.7.6.12 H.248.26 Enhanced Analog Line Packages >>> >>>D-0346 Comments to AVD-2317, "Enhanced Analogue Line Packages" Ericsson >>>This delayed contribution was presented. Each of the bullet points in >>>the discussion section were addressed, the results of which are detailed below: >>>Item 1: Agreed to be included. >>>Item 2: Rejected. Signal type to remain on/off >>>Item 3: Agreed to be included. >>> >>>TD-WP2-0024 Draft H.248.26 Enhanced Analog Line Packages Editor >>>This temporary document was presented by the editor and agreed as >>>baseline text. >>>It was agreed to put forward H.248.26 for consent at this meeting. The >>>recommendation for consent is contained in TD-PLEN-0034. >>> >>>3.7.6.13 H.248.27 Supplemental Tones Packages >>> >>>D-0344 Comments to AVD-2314, "Supplementary Tones Packages" Ericsson >>>This delayed contribution was presented. Each of the bullet points in >>>the discussion section were addressed, the results of which are detailed below: >>>Item 1,2: Agreed to be included >>>Item 3: Heading should read "Diagnostic Tones" >>>Item 4: A summary should be added detailing the use of this package. >>>Item 5: Agreed to be included. >>> >>>TD-WP2-0025 Draft H.248.27 Supplemental Tones Packages Editor >>>This temporary document was presented by the editor and agreed as >>>baseline text. >>>It was agreed to put forward H.248.27 for consent at this meeting. The >>>recommendation for consent is contained in TD-PLEN-0035. >>> >>>3.7.6.14 H.248 Sub-Series Packages Guide >>> >>>TD-WP2-0018 Proposed additions to H.248 Sub-Series: Packages Guide >>>Release 4" Editor >>>This temporary document was presented and the text agreed as baseline. A >>>comment was made that packages in H.248.23,24,25,26,27,icas, icasc >>>should be added. The respective drafts in the IETF should point to the >>>ITU work. The supplement for approval is contained in TD-PLEN-56. >>> >>>D-0352 Proposed Liaison to Tiphon on H.248 Packages Ericsson >>>This delayed contribution was presented and it was agreed to send >>>enclosed liaison to Tiphon. The outgoing liaison can be found in TD-WP2-56. >>> >>>3.7.7 Other Work to Progress >>> >>>3.7.7.1 H.248.icas International CAS Packages >>> >>>D=0345 Comments to AVD-2316, "International CAS Packages" Ericsson >>>This delayed contribution was presented. Each of the bullet points in >>>the discussion section were addressed, the results of which is detailed below: >>>Item 1: Agreed to be included. >>>Item 2: Resolved. Signalling is different for R1 and R2. >>>Item 3: Agreed to be included. >>> >>>D=0341 International CAS Compelled Register Signaling Packages Nortel >>>This delayed contribution was presented and it was agreed to start a >>>work item on this. This new work item shall be named H.248.icasc. D341 >>>is considered baseline text. >>> >>>TD-WP2=0026 H.248.icas International CAS Packages Editor >>>This temporary document was presented by the editor and agreed as >>>baseline text. >>> >>>3.7.8 New Work >>> >>>3.7.8.1 New Packages for H.248 >>> >>>D-0361 Request for an extension package to the H.248 Network Package >>>for the jitter buffer. (H.248.1 Annex E.11.1) Lucent >>>This delayed contribution was presented. There was a comment from Mr. >>>Boyle that if the work was accepted as a package extension the >>>contribution would need significant editing. Mr. Boyle also questioned >>>the need for a minimum and nominal jitter value. Mr. Teising replied >>>that should know the network topology and can provide these values. It >>>was discussed that the MG would better know the routing of the bearer so >>>it would be more appropriate for it to provide the values. >>>It was agreed to persue this work however extensive editing work is >>>needed as well a scope and summary addressing the above questions. >>>An editing session meet to draft text for a baseline document. The >>>baseline shall be referred to as H.248.ajb and is contained in TD-WP2-0052. >>> >>>D-0362 Request that an extension package be defined to the H.248 >>>Congestion Control Package (H.248.10) Lucent >>>This delayed contribution was presented. Mr.Boyle questioned whether any >>>consideration had been made to use H.248.11. Mr. Tegeler questioned if >>>congestion on different routes and directions could be indicated. >>>Mr.Groves expressed concern that the proposed extensions addressed MG >>>wide congestion events as well as network congestion events where as the >>>base H.248.10 only addressed MG events. Mr.Schwarz questioned how >>>congestion of an IP connection carried over an ATM (AAL5 interface) >>>would be handled? Mr. Schwarz noted that the resources specified fell in >>>two types: those dealing with H.248 processing and Media Processing. Due >>>to the number of questions D362 was not accepted. Mr. Teising undertook >>>to study these questions and provide an updated contribution at a >>>subsequent question. >>> >>> >>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >> > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jun 2 16:24:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22627 for ; Mon, 2 Jun 2003 16:24:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52KNYO17816 for megaco-archive@odin.ietf.org; Mon, 2 Jun 2003 16:23:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52KNXB17813 for ; Mon, 2 Jun 2003 16:23:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22616 for ; Mon, 2 Jun 2003 16:23:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MvoO-00066x-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 16:21:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MvoO-00066u-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 16:21:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52KL4B17698; Mon, 2 Jun 2003 16:21:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52KJHB17571 for ; Mon, 2 Jun 2003 16:19:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22533 for ; Mon, 2 Jun 2003 16:19:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MvkG-00065p-00 for megaco@ietf.org; Mon, 02 Jun 2003 16:17:28 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19MvkF-00065S-00 for megaco@ietf.org; Mon, 02 Jun 2003 16:17:27 -0400 Received: from smilevm.winphoria.com ([10.14.25.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 2 Jun 2003 16:18:42 -0400 Message-Id: <5.2.1.1.0.20030602180527.02b1b518@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 02 Jun 2003 18:09:51 -0400 To: Tom Taylor , Megaco List From: Aleksandr Ryabin Subject: Re: [Megaco] Summary Of SG 16 Meeting Just Concluded In-Reply-To: <3EDBA24D.6070702@nortelnetworks.com> References: <5.2.1.1.0.20030602120818.01d1da10@imap.winphoria.com> <5.2.1.1.0.20030602120818.01d1da10@imap.winphoria.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 02 Jun 2003 20:18:42.0979 (UTC) FILETIME=[29A65F30:01C32944] X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h52KJHB17572 Sender: megaco-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-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h52KL4B17698 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h52KNXB17813 Content-Transfer-Encoding: 8bit I did, it only contains input documents. Where are the output docs? e.g TD-PLEN-57, etc.? At 03:15 PM 6/2/2003, Tom Taylor wrote: >Have a look at http://standard.pictel.com/ftp/avc-site/0305_Gen/. > >Aleksandr Ryabin wrote: > >>Hi Tom, >>Thanks for the info. >>Are the output documents referred below publicly available? >>If yes, where from? >>Thanks >> Aleks >>At 09:55 AM 6/2/2003, Tom Taylor wrote: >> >>>For your information, I have extracted the Megaco-relevant portion of >>>the SG 16 meeting report. The meeting was held 20-30 May in Geneva. >>> >>>3.7.3 Recommendations for Consent >>> >>>New H.248.22 Shared Risk Group Package TD-PLEN-57 >>>New H.248.23 Enhanced Alerting Packages TD-PLEN-32 >>>New H.248.24 MF Tone Generation and Detection Packages >>>TD-PLEN-33 >>>New H.248.25 Basic CAS Packages TD-PLEN-58R1 >>>New H.248.26 Enhanced Analogue Line Packages TD-PLEN-34 >>>New H.248.27 Supplemental Tones Packages TD-PLEN-35 >>> >>>3.7.4 Documents for Approval >>> >>>H.248 Supp H.248 Sub-Series: Packages Guide Release 4 >>>TD-PLEN-56 >>>H.248 IG H.248 Sub Series Implementor's Guide TD-PLEN-36R1 >>> >>> >>>3.7.6 Documents planned for Decision/Consent >>> >>>3.7.6.5 H.248 Implementers Guide >>> >>>TD-GEN-0035 Reply to LS on Rec. H.248 Annex E, Gain and Automatic >>>Level Control SG15 >>>Addressed at the San Jose February 2003 meeting in AVD-2338. No further >>>action needed. >>> >>>D-0347 Proposed additions to H.248 Implementors' Guide LM Ericsson >>>This contribution was presented and it was agreed to incorporate the two >>>proposed additions into the H.248 Sub-series implementors' guide. It was >>>also agreed that text should be on clarifying what should be sent in a >>>reponse to a request that has only actions and no commands. This has >>>been added as section 6.18. >>> >>>TD-WP2-0028 H.248 Sub-series Implementors' Guide Editor >>>The editor's draft was presented and accepted. >>>It was agreed to put the H.248 Sub-Series Implementors' Guide forward >>>for consent. The agreed text can be found in TD-PLEN-0036R1. >>> >>>3.7.6.6 H.248.1 Annex F ServiceChange >>> >>>TD-WP2-0021 Draft H.248.1 Annex F Editor >>>The editor's draft was presented and it was noted that there were no >>>changes from San Jose output. It was agreed that this document was not >>>ready to be put forward for consent. People are encouraged to contribute >>>on this in the interim meeting. >>> >>>TD-WP2-0027 Considerations for discussion of update of ServiceChange >>>procedures for H.248 Editor >>>The temporary document was presented as a record of the requirements for >>>ServiceChange annex work. >>> >>>3.7.6.7 H.248.19 Decomposed MCU Audio, Video and Data Conferencing Packages >>> >>>D-0348 Additional requirements for H.248.19 for Chat >>>conferencing LM Ericsson >>>This delayed contribution was presented and discussion on the difference >>>between messaging and chat conferencing. It was agreed to add these >>>requirements to H.248.19. Ms.Levin will provide a reference to work >>>undertaken in the IETF on this work. This reference should be included >>>in the requirements when it becomes available. >>> >>>D-0349 Addition to H.248.19 for Tiled Windows LM Ericsson >>>This delayed contribution was presented. It was noted that even in >>>simple video window configuration individual windows may have different >>>sizes. It was also noted that in the IETF work is ongoing on defining >>>profiles for different configurations. It was agreed to accept this work >>>for inclusion to H.248.19 but further changes maybe needed to define the >>>use of profiles and the use of non-proportional window configurations. >>> >>>D-0350 Addition to H.248.19 for viewer indication LM Ericsson >>>This contribution was presented and there was some discussion on the >>>signal type and whether it should be two signals of type brief or one >>>signal of type on/off. It was agreed that this should be type brief >>>however a better explantion of how this is used should be be included. >>> >>>TD-WP2-0017 Draft H.248.19, "Decomposed Multipoint Control Unit, >>>Audio, Video and Data Conferencing Packages" Editor >>>The editor's input was presented and was accepted. >>> >>>D-0353 Video Coding description in H.245, H.248 and SDP LM Ericsson >>>This contribution was presented. Discussion highlighted that for many >>>video codecs (H.261, H.264) there was not a problem of mapping H.245 to >>>SDP however a complete mapping between SDP and H.245 did not exist for >>>H.263. Work is ongoing in the IETF to solve this problem through the use >>>of profiles or feature description. It was agreed that this work should >>>be monitored but this issue is of no consequence to the H.248.19 work. >>>The output of H.248.19 for this meeting can be found in TD-WP2-60. >>> >>>3.7.6.8 H.248.22 Shared Risk Group Handling Package >>> >>>D-0351 H.248.shrisk additions LM Ericsson >>>The contribution was presented and it was agreed to put forward this >>>delayed contribution (with editorial corrections) for consent. The >>>recommendation for consent can be found in TD-PLEN-57. >>> >>>3.7.6.9 H.248.23 Enhanced Alerting Packages >>> >>>D-0343 Comments to AVD-2313, "Enhanced Alerting Packages" Ericsson >>>This delayed contribution was presented. Each of the bullet points in >>>the discussion section were addressed, the results of which are detailed below: >>>Item 1,2: Agreed to be incorporated in H.248.23 >>>Item 3: Rejected >>>Item 4: Text should be included to clarify what the variable duration is >>>dependent on. >>>Item 5: The text should be clarified to make clear that an error is NOT >>>generated only when the data component of the signal is not delivered. >>>All other errors will generate an error. >>>Item 6: Text should be included to clarify the use of the TAS signal >>>Item 7, 8: Included in editor's draft. >>> >>>TD-WP2-0022 Draft H.248.23 Enhanced Alerting Packages Editor >>>This temporary document was presented. The editor stated that this work >>>had existed for 2 years in the IETF and authors decided to move it to >>>the ITU. Mr. Okubo questioned whether the IETF had been consulted over >>>this move. The IETF had received a liaison from Question 3/16 notifying >>>them of the proposal for taking over the work. It asked that they >>>respond if there was a problem with this approach. No response was >>>received. It was also noted that package development was not >>>specifically part of the IETF Megaco WG charter. >>>There was a question from Mr.Chatras (France Telecom) as to where the >>>checksum should be generated, MGC or MG. The editor replied that as the >>>checksum was associated with the data plane the MGC should be >>>responsible for generating the checksum. This will be clarified in >>>updated text. >>>Mr. Chatras also questioned the need of having an example for ETSI based >>>encodings. It was agreed that the editor and Mr.Chatras co-ordinate on >>>such an example. >>>It was agreed that H.248.23 be put forward for consent. The >>>recommendation for consent is contained in TD-PLEN-0032. >>> >>>3.7.6.10 H.248.24 MF Tone Generation and Detection Packages >>> >>>D-0342 Comments to AVD-2312, "MF Tone Generation and Detection >>>Packages" Ericsson >>>This delayed contribution was presented. Each of the bullet points in >>>the discussion section were addressed, the results of which are detailed below: >>>Item 1: Agreed to be incorporated in H.248.24 >>>Item 2: Resolved. It was agreed to remove the text "was chosen arbitrarily". >>>Item 3: Agreed to be incorporated in H.248.24 >>>Item 4: Agreed to be incorporated in H.248.24 >>> >>>TD-WP2-0023 Draft H.248.24 MF Tone Generation and Detection >>>Packages Editor >>>This temporary document was presented and accepted. >>>It was agreed to put forward H.248.24 for consent at this meeting. The >>>recommendation for consent is contained in TD-PLEN-0033. >>> >>>3.7.6.11 H.248.25 Basic CAS Packages >>> >>>D-0327 Comments to AVD-2315, "Basic CAS Packages" Ericsson >>>This delayed contribution was presented. Each of the bullet points in >>>the discussion section were addressed, the results of which are detailed below: >>>Item 1: Package ID needs to be registered with IANA before final approval. >>>Item 2: Editor to check if any values have been dropped. >>>Item 3,4: Accepted to be resolved. >>>Item 5: These values need to be reviewed in line with the comments made >>>in D328. >>>Item 6: Resolved. The address signal was split in a separate package. >>> >>>D-0328 H.248 Basic CAS Package ­ CAS Failure Code Extensions Alcatel >>>This delayed contribution was presented and listed a number of concerns >>>with the CAS package on Glare, Start Dailing Timeout, LTO and Polarity. >>>The editor replied that: >>>• Glare need not be added as it was already covered by the >>>procedure section of the package. >>>• Start Dialling Timeout can be handled by the Register Timeout >>>Signal in the CAS Address package. >>>• LTO there are other events that can be used to indicate this >>>situation. >>>• Unexpected Line signal could be used to indicate Polarity error. >>>It was agreed that this explanation of error conditions should be >>>included in H.248.24. >>> >>>TD-WP2-0016 Draft H.248.25 Basic CAS Packages Editor >>>This temporary document was presented by the editor. The editor tabled a >>>number of comments from the IETF mailing list: >>>1. Remove RTO as a possible value in bcas/casf event --> ec parameter >>>(bcas addresses line signals/events, Register signaling is covered in >>>the derived packages, so register failure reporting is outside scope of >>>this package) >>>2. Added meth parameter in bcasaddr/addr event (digit map is associated >>>with the reporting of this event) >>>3. casblk package has been referred in the icas package there the CAS >>>Blocking Package should be included. >>>The comments were agreed. The CAS blocking package will be specified in >>>the ICAS package. >>>It was agreed to put forward H.248.25 for consent at this meeting. A >>>Package ID for the "bcasaddr" package has been requested. The >>>recommendation for consent is contained in TD-PLEN-58R1. >>> >>>3.7.6.12 H.248.26 Enhanced Analog Line Packages >>> >>>D-0346 Comments to AVD-2317, "Enhanced Analogue Line Packages" Ericsson >>>This delayed contribution was presented. Each of the bullet points in >>>the discussion section were addressed, the results of which are detailed below: >>>Item 1: Agreed to be included. >>>Item 2: Rejected. Signal type to remain on/off >>>Item 3: Agreed to be included. >>> >>>TD-WP2-0024 Draft H.248.26 Enhanced Analog Line Packages Editor >>>This temporary document was presented by the editor and agreed as >>>baseline text. >>>It was agreed to put forward H.248.26 for consent at this meeting. The >>>recommendation for consent is contained in TD-PLEN-0034. >>> >>>3.7.6.13 H.248.27 Supplemental Tones Packages >>> >>>D-0344 Comments to AVD-2314, "Supplementary Tones Packages" Ericsson >>>This delayed contribution was presented. Each of the bullet points in >>>the discussion section were addressed, the results of which are detailed below: >>>Item 1,2: Agreed to be included >>>Item 3: Heading should read "Diagnostic Tones" >>>Item 4: A summary should be added detailing the use of this package. >>>Item 5: Agreed to be included. >>> >>>TD-WP2-0025 Draft H.248.27 Supplemental Tones Packages Editor >>>This temporary document was presented by the editor and agreed as >>>baseline text. >>>It was agreed to put forward H.248.27 for consent at this meeting. The >>>recommendation for consent is contained in TD-PLEN-0035. >>> >>>3.7.6.14 H.248 Sub-Series Packages Guide >>> >>>TD-WP2-0018 Proposed additions to H.248 Sub-Series: Packages Guide >>>Release 4" Editor >>>This temporary document was presented and the text agreed as baseline. A >>>comment was made that packages in H.248.23,24,25,26,27,icas, icasc >>>should be added. The respective drafts in the IETF should point to the >>>ITU work. The supplement for approval is contained in TD-PLEN-56. >>> >>>D-0352 Proposed Liaison to Tiphon on H.248 Packages Ericsson >>>This delayed contribution was presented and it was agreed to send >>>enclosed liaison to Tiphon. The outgoing liaison can be found in TD-WP2-56. >>> >>>3.7.7 Other Work to Progress >>> >>>3.7.7.1 H.248.icas International CAS Packages >>> >>>D=0345 Comments to AVD-2316, "International CAS Packages" Ericsson >>>This delayed contribution was presented. Each of the bullet points in >>>the discussion section were addressed, the results of which is detailed below: >>>Item 1: Agreed to be included. >>>Item 2: Resolved. Signalling is different for R1 and R2. >>>Item 3: Agreed to be included. >>> >>>D=0341 International CAS Compelled Register Signaling Packages Nortel >>>This delayed contribution was presented and it was agreed to start a >>>work item on this. This new work item shall be named H.248.icasc. D341 >>>is considered baseline text. >>> >>>TD-WP2=0026 H.248.icas International CAS Packages Editor >>>This temporary document was presented by the editor and agreed as >>>baseline text. >>> >>>3.7.8 New Work >>> >>>3.7.8.1 New Packages for H.248 >>> >>>D-0361 Request for an extension package to the H.248 Network Package >>>for the jitter buffer. (H.248.1 Annex E.11.1) Lucent >>>This delayed contribution was presented. There was a comment from Mr. >>>Boyle that if the work was accepted as a package extension the >>>contribution would need significant editing. Mr. Boyle also questioned >>>the need for a minimum and nominal jitter value. Mr. Teising replied >>>that should know the network topology and can provide these values. It >>>was discussed that the MG would better know the routing of the bearer so >>>it would be more appropriate for it to provide the values. >>>It was agreed to persue this work however extensive editing work is >>>needed as well a scope and summary addressing the above questions. >>>An editing session meet to draft text for a baseline document. The >>>baseline shall be referred to as H.248.ajb and is contained in TD-WP2-0052. >>> >>>D-0362 Request that an extension package be defined to the H.248 >>>Congestion Control Package (H.248.10) Lucent >>>This delayed contribution was presented. Mr.Boyle questioned whether any >>>consideration had been made to use H.248.11. Mr. Tegeler questioned if >>>congestion on different routes and directions could be indicated. >>>Mr.Groves expressed concern that the proposed extensions addressed MG >>>wide congestion events as well as network congestion events where as the >>>base H.248.10 only addressed MG events. Mr.Schwarz questioned how >>>congestion of an IP connection carried over an ATM (AAL5 interface) >>>would be handled? Mr. Schwarz noted that the resources specified fell in >>>two types: those dealing with H.248 processing and Media Processing. Due >>>to the number of questions D362 was not accepted. Mr. Teising undertook >>>to study these questions and provide an updated contribution at a >>>subsequent question. >>> >>> >>> >>>_______________________________________________ >>>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 Jun 2 16:35:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23070 for ; Mon, 2 Jun 2003 16:35:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52KYPB18429; Mon, 2 Jun 2003 16:34:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52KXEB18352 for ; Mon, 2 Jun 2003 16:33:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22907 for ; Mon, 2 Jun 2003 16:33:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mvxl-0006A2-00 for megaco@ietf.org; Mon, 02 Jun 2003 16:31:25 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19Mvxk-00069y-00 for megaco@ietf.org; Mon, 02 Jun 2003 16:31:24 -0400 Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52KWcn26455; Mon, 2 Jun 2003 16:32:38 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L9VC2CM4; Mon, 2 Jun 2003 16:32:38 -0400 Received: from nortelnetworks.com (acart418.ca.nortel.com [47.129.49.145]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0P22; Mon, 2 Jun 2003 16:32:38 -0400 Message-ID: <3EDBB462.5050502@nortelnetworks.com> Date: Mon, 02 Jun 2003 16:32:34 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Aleksandr Ryabin CC: Megaco List Subject: Re: [Megaco] Summary Of SG 16 Meeting Just Concluded References: <5.2.1.1.0.20030602120818.01d1da10@imap.winphoria.com> <5.2.1.1.0.20030602120818.01d1da10@imap.winphoria.com> <5.2.1.1.0.20030602180527.02b1b518@imap.winphoria.com> In-Reply-To: <5.2.1.1.0.20030602180527.02b1b518@imap.winphoria.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04e.nortelnetworks.com id h52KWcn26455 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h52KXEB18353 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit They will probably make it there, labelled by their Recommendation number. One thing you are NOT guaranteed: that this site will contain the documents as the ITU-T will publish them. The best you can hope for is a very late draft. ITU-T members, of course, have full access to all meeting documents at the ITU-T site. You do have to register individually for TIES access. If there is general interest in a document which is a work in progress, I can see about translating it into an I-D for comment. Aleksandr Ryabin wrote: > I did, it only contains input documents. > Where are the output docs? e.g TD-PLEN-57, etc.? > > At 03:15 PM 6/2/2003, Tom Taylor wrote: > >> Have a look at http://standard.pictel.com/ftp/avc-site/0305_Gen/. >> >> Aleksandr Ryabin wrote: >> >>> Hi Tom, >>> Thanks for the info. >>> Are the output documents referred below publicly available? >>> If yes, where from? >>> Thanks >>> Aleks >>> At 09:55 AM 6/2/2003, Tom Taylor wrote: >>> >>>> For your information, I have extracted the Megaco-relevant portion >>>> of the SG 16 meeting report. The meeting was held 20-30 May in Geneva. >>>> >>>> 3.7.3 Recommendations for Consent >>>> >>>> New H.248.22 Shared Risk Group Package TD-PLEN-57 >>>> New H.248.23 Enhanced Alerting Packages TD-PLEN-32 >>>> New H.248.24 MF Tone Generation and Detection Packages >>>> TD-PLEN-33 >>>> New H.248.25 Basic CAS Packages TD-PLEN-58R1 >>>> New H.248.26 Enhanced Analogue Line Packages TD-PLEN-34 >>>> New H.248.27 Supplemental Tones Packages TD-PLEN-35 >>>> >>>> 3.7.4 Documents for Approval >>>> >>>> H.248 Supp H.248 Sub-Series: Packages Guide Release 4 >>>> TD-PLEN-56 >>>> H.248 IG H.248 Sub Series Implementor's Guide TD-PLEN-36R1 >>>> >>>> >>>> 3.7.6 Documents planned for Decision/Consent >>>> >>>> 3.7.6.5 H.248 Implementers Guide >>>> >>>> TD-GEN-0035 Reply to LS on Rec. H.248 Annex E, Gain and >>>> Automatic Level Control SG15 >>>> Addressed at the San Jose February 2003 meeting in AVD-2338. No >>>> further action needed. >>>> >>>> D-0347 Proposed additions to H.248 Implementors' Guide LM Ericsson >>>> This contribution was presented and it was agreed to incorporate the >>>> two proposed additions into the H.248 Sub-series implementors' >>>> guide. It was also agreed that text should be on clarifying what >>>> should be sent in a reponse to a request that has only actions and >>>> no commands. This has been added as section 6.18. >>>> >>>> TD-WP2-0028 H.248 Sub-series Implementors' Guide Editor >>>> The editor's draft was presented and accepted. >>>> It was agreed to put the H.248 Sub-Series Implementors' Guide >>>> forward for consent. The agreed text can be found in TD-PLEN-0036R1. >>>> >>>> 3.7.6.6 H.248.1 Annex F ServiceChange >>>> >>>> TD-WP2-0021 Draft H.248.1 Annex F Editor >>>> The editor's draft was presented and it was noted that there were no >>>> changes from San Jose output. It was agreed that this document was >>>> not ready to be put forward for consent. People are encouraged to >>>> contribute on this in the interim meeting. >>>> >>>> TD-WP2-0027 Considerations for discussion of update of >>>> ServiceChange procedures for H.248 Editor >>>> The temporary document was presented as a record of the requirements >>>> for ServiceChange annex work. >>>> >>>> 3.7.6.7 H.248.19 Decomposed MCU Audio, Video and Data Conferencing >>>> Packages >>>> >>>> D-0348 Additional requirements for H.248.19 for Chat >>>> conferencing LM Ericsson >>>> This delayed contribution was presented and discussion on the >>>> difference between messaging and chat conferencing. It was agreed to >>>> add these requirements to H.248.19. Ms.Levin will provide a >>>> reference to work undertaken in the IETF on this work. This >>>> reference should be included in the requirements when it becomes >>>> available. >>>> >>>> D-0349 Addition to H.248.19 for Tiled Windows LM Ericsson >>>> This delayed contribution was presented. It was noted that even in >>>> simple video window configuration individual windows may have >>>> different sizes. It was also noted that in the IETF work is ongoing >>>> on defining profiles for different configurations. It was agreed to >>>> accept this work for inclusion to H.248.19 but further changes maybe >>>> needed to define the use of profiles and the use of non-proportional >>>> window configurations. >>>> >>>> D-0350 Addition to H.248.19 for viewer indication LM Ericsson >>>> This contribution was presented and there was some discussion on the >>>> signal type and whether it should be two signals of type brief or >>>> one signal of type on/off. It was agreed that this should be type >>>> brief however a better explantion of how this is used should be be >>>> included. >>>> >>>> TD-WP2-0017 Draft H.248.19, "Decomposed Multipoint Control Unit, >>>> Audio, Video and Data Conferencing Packages" Editor >>>> The editor's input was presented and was accepted. >>>> >>>> D-0353 Video Coding description in H.245, H.248 and SDP LM >>>> Ericsson >>>> This contribution was presented. Discussion highlighted that for >>>> many video codecs (H.261, H.264) there was not a problem of mapping >>>> H.245 to SDP however a complete mapping between SDP and H.245 did >>>> not exist for H.263. Work is ongoing in the IETF to solve this >>>> problem through the use of profiles or feature description. It was >>>> agreed that this work should be monitored but this issue is of no >>>> consequence to the H.248.19 work. >>>> The output of H.248.19 for this meeting can be found in TD-WP2-60. >>>> >>>> 3.7.6.8 H.248.22 Shared Risk Group Handling Package >>>> >>>> D-0351 H.248.shrisk additions LM Ericsson >>>> The contribution was presented and it was agreed to put forward this >>>> delayed contribution (with editorial corrections) for consent. The >>>> recommendation for consent can be found in TD-PLEN-57. >>>> >>>> 3.7.6.9 H.248.23 Enhanced Alerting Packages >>>> >>>> D-0343 Comments to AVD-2313, "Enhanced Alerting Packages" >>>> Ericsson >>>> This delayed contribution was presented. Each of the bullet points >>>> in the discussion section were addressed, the results of which are >>>> detailed below: >>>> Item 1,2: Agreed to be incorporated in H.248.23 >>>> Item 3: Rejected >>>> Item 4: Text should be included to clarify what the variable >>>> duration is dependent on. >>>> Item 5: The text should be clarified to make clear that an error is >>>> NOT generated only when the data component of the signal is not >>>> delivered. All other errors will generate an error. >>>> Item 6: Text should be included to clarify the use of the TAS signal >>>> Item 7, 8: Included in editor's draft. >>>> >>>> TD-WP2-0022 Draft H.248.23 Enhanced Alerting Packages Editor >>>> This temporary document was presented. The editor stated that this >>>> work had existed for 2 years in the IETF and authors decided to move >>>> it to the ITU. Mr. Okubo questioned whether the IETF had been >>>> consulted over this move. The IETF had received a liaison from >>>> Question 3/16 notifying them of the proposal for taking over the >>>> work. It asked that they respond if there was a problem with this >>>> approach. No response was received. It was also noted that package >>>> development was not specifically part of the IETF Megaco WG charter. >>>> There was a question from Mr.Chatras (France Telecom) as to where >>>> the checksum should be generated, MGC or MG. The editor replied that >>>> as the checksum was associated with the data plane the MGC should be >>>> responsible for generating the checksum. This will be clarified in >>>> updated text. >>>> Mr. Chatras also questioned the need of having an example for ETSI >>>> based encodings. It was agreed that the editor and Mr.Chatras >>>> co-ordinate on such an example. >>>> It was agreed that H.248.23 be put forward for consent. The >>>> recommendation for consent is contained in TD-PLEN-0032. >>>> >>>> 3.7.6.10 H.248.24 MF Tone Generation and Detection Packages >>>> >>>> D-0342 Comments to AVD-2312, "MF Tone Generation and Detection >>>> Packages" Ericsson >>>> This delayed contribution was presented. Each of the bullet points >>>> in the discussion section were addressed, the results of which are >>>> detailed below: >>>> Item 1: Agreed to be incorporated in H.248.24 >>>> Item 2: Resolved. It was agreed to remove the text "was chosen >>>> arbitrarily". >>>> Item 3: Agreed to be incorporated in H.248.24 >>>> Item 4: Agreed to be incorporated in H.248.24 >>>> >>>> TD-WP2-0023 Draft H.248.24 MF Tone Generation and Detection >>>> Packages Editor >>>> This temporary document was presented and accepted. >>>> It was agreed to put forward H.248.24 for consent at this meeting. >>>> The recommendation for consent is contained in TD-PLEN-0033. >>>> >>>> 3.7.6.11 H.248.25 Basic CAS Packages >>>> >>>> D-0327 Comments to AVD-2315, "Basic CAS Packages" Ericsson >>>> This delayed contribution was presented. Each of the bullet points >>>> in the discussion section were addressed, the results of which are >>>> detailed below: >>>> Item 1: Package ID needs to be registered with IANA before final >>>> approval. >>>> Item 2: Editor to check if any values have been dropped. >>>> Item 3,4: Accepted to be resolved. >>>> Item 5: These values need to be reviewed in line with the comments >>>> made in D328. >>>> Item 6: Resolved. The address signal was split in a separate package. >>>> >>>> D-0328 H.248 Basic CAS Package ­ CAS Failure Code Extensions Alcatel >>>> This delayed contribution was presented and listed a number of >>>> concerns with the CAS package on Glare, Start Dailing Timeout, LTO >>>> and Polarity. The editor replied that: >>>> • Glare need not be added as it was already covered by the >>>> procedure section of the package. >>>> • Start Dialling Timeout can be handled by the Register >>>> Timeout Signal in the CAS Address package. >>>> • LTO there are other events that can be used to indicate this >>>> situation. >>>> • Unexpected Line signal could be used to indicate Polarity >>>> error. >>>> It was agreed that this explanation of error conditions should be >>>> included in H.248.24. >>>> >>>> TD-WP2-0016 Draft H.248.25 Basic CAS Packages Editor >>>> This temporary document was presented by the editor. The editor >>>> tabled a number of comments from the IETF mailing list: >>>> 1. Remove RTO as a possible value in bcas/casf event --> ec >>>> parameter (bcas addresses line signals/events, Register signaling is >>>> covered in the derived packages, so register failure reporting is >>>> outside scope of this package) >>>> 2. Added meth parameter in bcasaddr/addr event (digit map is >>>> associated with the reporting of this event) >>>> 3. casblk package has been referred in the icas package there the >>>> CAS Blocking Package should be included. >>>> The comments were agreed. The CAS blocking package will be specified >>>> in the ICAS package. >>>> It was agreed to put forward H.248.25 for consent at this meeting. A >>>> Package ID for the "bcasaddr" package has been requested. The >>>> recommendation for consent is contained in TD-PLEN-58R1. >>>> >>>> 3.7.6.12 H.248.26 Enhanced Analog Line Packages >>>> >>>> D-0346 Comments to AVD-2317, "Enhanced Analogue Line Packages" >>>> Ericsson >>>> This delayed contribution was presented. Each of the bullet points >>>> in the discussion section were addressed, the results of which are >>>> detailed below: >>>> Item 1: Agreed to be included. >>>> Item 2: Rejected. Signal type to remain on/off >>>> Item 3: Agreed to be included. >>>> >>>> TD-WP2-0024 Draft H.248.26 Enhanced Analog Line Packages Editor >>>> This temporary document was presented by the editor and agreed as >>>> baseline text. >>>> It was agreed to put forward H.248.26 for consent at this meeting. >>>> The recommendation for consent is contained in TD-PLEN-0034. >>>> >>>> 3.7.6.13 H.248.27 Supplemental Tones Packages >>>> >>>> D-0344 Comments to AVD-2314, "Supplementary Tones Packages" >>>> Ericsson >>>> This delayed contribution was presented. Each of the bullet points >>>> in the discussion section were addressed, the results of which are >>>> detailed below: >>>> Item 1,2: Agreed to be included >>>> Item 3: Heading should read "Diagnostic Tones" >>>> Item 4: A summary should be added detailing the use of this package. >>>> Item 5: Agreed to be included. >>>> >>>> TD-WP2-0025 Draft H.248.27 Supplemental Tones Packages Editor >>>> This temporary document was presented by the editor and agreed as >>>> baseline text. >>>> It was agreed to put forward H.248.27 for consent at this meeting. >>>> The recommendation for consent is contained in TD-PLEN-0035. >>>> >>>> 3.7.6.14 H.248 Sub-Series Packages Guide >>>> >>>> TD-WP2-0018 Proposed additions to H.248 Sub-Series: Packages >>>> Guide Release 4" Editor >>>> This temporary document was presented and the text agreed as >>>> baseline. A comment was made that packages in >>>> H.248.23,24,25,26,27,icas, icasc should be added. The respective >>>> drafts in the IETF should point to the ITU work. The supplement for >>>> approval is contained in TD-PLEN-56. >>>> >>>> D-0352 Proposed Liaison to Tiphon on H.248 Packages Ericsson >>>> This delayed contribution was presented and it was agreed to send >>>> enclosed liaison to Tiphon. The outgoing liaison can be found in >>>> TD-WP2-56. >>>> >>>> 3.7.7 Other Work to Progress >>>> >>>> 3.7.7.1 H.248.icas International CAS Packages >>>> >>>> D=0345 Comments to AVD-2316, "International CAS Packages" >>>> Ericsson >>>> This delayed contribution was presented. Each of the bullet points >>>> in the discussion section were addressed, the results of which is >>>> detailed below: >>>> Item 1: Agreed to be included. >>>> Item 2: Resolved. Signalling is different for R1 and R2. >>>> Item 3: Agreed to be included. >>>> >>>> D=0341 International CAS Compelled Register Signaling Packages Nortel >>>> This delayed contribution was presented and it was agreed to start >>>> a work item on this. This new work item shall be named H.248.icasc. >>>> D341 is considered baseline text. >>>> >>>> TD-WP2=0026 H.248.icas International CAS Packages Editor >>>> This temporary document was presented by the editor and agreed as >>>> baseline text. >>>> >>>> 3.7.8 New Work >>>> >>>> 3.7.8.1 New Packages for H.248 >>>> >>>> D-0361 Request for an extension package to the H.248 Network >>>> Package for the jitter buffer. (H.248.1 Annex E.11.1) Lucent >>>> This delayed contribution was presented. There was a comment from >>>> Mr. Boyle that if the work was accepted as a package extension the >>>> contribution would need significant editing. Mr. Boyle also >>>> questioned the need for a minimum and nominal jitter value. Mr. >>>> Teising replied that should know the network topology and can >>>> provide these values. It was discussed that the MG would better know >>>> the routing of the bearer so it would be more appropriate for it to >>>> provide the values. >>>> It was agreed to persue this work however extensive editing work is >>>> needed as well a scope and summary addressing the above questions. >>>> An editing session meet to draft text for a baseline document. The >>>> baseline shall be referred to as H.248.ajb and is contained in >>>> TD-WP2-0052. >>>> >>>> D-0362 Request that an extension package be defined to the H.248 >>>> Congestion Control Package (H.248.10) Lucent >>>> This delayed contribution was presented. Mr.Boyle questioned whether >>>> any consideration had been made to use H.248.11. Mr. Tegeler >>>> questioned if congestion on different routes and directions could be >>>> indicated. Mr.Groves expressed concern that the proposed extensions >>>> addressed MG wide congestion events as well as network congestion >>>> events where as the base H.248.10 only addressed MG events. >>>> Mr.Schwarz questioned how congestion of an IP connection carried >>>> over an ATM (AAL5 interface) would be handled? Mr. Schwarz noted >>>> that the resources specified fell in two types: those dealing with >>>> H.248 processing and Media Processing. Due to the number of >>>> questions D362 was not accepted. Mr. Teising undertook to study >>>> these questions and provide an updated contribution at a subsequent >>>> question. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Megaco mailing list >>>> Megaco@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >> > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jun 2 16:36:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23125 for ; Mon, 2 Jun 2003 16:36:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52KaQT18574 for megaco-archive@odin.ietf.org; Mon, 2 Jun 2003 16:36:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52KaQB18571 for ; Mon, 2 Jun 2003 16:36:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23100 for ; Mon, 2 Jun 2003 16:36:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mw0r-0006DP-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 16:34:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Mw0q-0006DM-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 16:34:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52KYPB18429; Mon, 2 Jun 2003 16:34:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52KXEB18352 for ; Mon, 2 Jun 2003 16:33:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22907 for ; Mon, 2 Jun 2003 16:33:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mvxl-0006A2-00 for megaco@ietf.org; Mon, 02 Jun 2003 16:31:25 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19Mvxk-00069y-00 for megaco@ietf.org; Mon, 02 Jun 2003 16:31:24 -0400 Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52KWcn26455; Mon, 2 Jun 2003 16:32:38 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L9VC2CM4; Mon, 2 Jun 2003 16:32:38 -0400 Received: from nortelnetworks.com (acart418.ca.nortel.com [47.129.49.145]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0P22; Mon, 2 Jun 2003 16:32:38 -0400 Message-ID: <3EDBB462.5050502@nortelnetworks.com> Date: Mon, 02 Jun 2003 16:32:34 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Aleksandr Ryabin CC: Megaco List Subject: Re: [Megaco] Summary Of SG 16 Meeting Just Concluded References: <5.2.1.1.0.20030602120818.01d1da10@imap.winphoria.com> <5.2.1.1.0.20030602120818.01d1da10@imap.winphoria.com> <5.2.1.1.0.20030602180527.02b1b518@imap.winphoria.com> In-Reply-To: <5.2.1.1.0.20030602180527.02b1b518@imap.winphoria.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04e.nortelnetworks.com id h52KWcn26455 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h52KXEB18353 Sender: megaco-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-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h52KYPB18429 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h52KaQB18571 Content-Transfer-Encoding: 8bit They will probably make it there, labelled by their Recommendation number. One thing you are NOT guaranteed: that this site will contain the documents as the ITU-T will publish them. The best you can hope for is a very late draft. ITU-T members, of course, have full access to all meeting documents at the ITU-T site. You do have to register individually for TIES access. If there is general interest in a document which is a work in progress, I can see about translating it into an I-D for comment. Aleksandr Ryabin wrote: > I did, it only contains input documents. > Where are the output docs? e.g TD-PLEN-57, etc.? > > At 03:15 PM 6/2/2003, Tom Taylor wrote: > >> Have a look at http://standard.pictel.com/ftp/avc-site/0305_Gen/. >> >> Aleksandr Ryabin wrote: >> >>> Hi Tom, >>> Thanks for the info. >>> Are the output documents referred below publicly available? >>> If yes, where from? >>> Thanks >>> Aleks >>> At 09:55 AM 6/2/2003, Tom Taylor wrote: >>> >>>> For your information, I have extracted the Megaco-relevant portion >>>> of the SG 16 meeting report. The meeting was held 20-30 May in Geneva. >>>> >>>> 3.7.3 Recommendations for Consent >>>> >>>> New H.248.22 Shared Risk Group Package TD-PLEN-57 >>>> New H.248.23 Enhanced Alerting Packages TD-PLEN-32 >>>> New H.248.24 MF Tone Generation and Detection Packages >>>> TD-PLEN-33 >>>> New H.248.25 Basic CAS Packages TD-PLEN-58R1 >>>> New H.248.26 Enhanced Analogue Line Packages TD-PLEN-34 >>>> New H.248.27 Supplemental Tones Packages TD-PLEN-35 >>>> >>>> 3.7.4 Documents for Approval >>>> >>>> H.248 Supp H.248 Sub-Series: Packages Guide Release 4 >>>> TD-PLEN-56 >>>> H.248 IG H.248 Sub Series Implementor's Guide TD-PLEN-36R1 >>>> >>>> >>>> 3.7.6 Documents planned for Decision/Consent >>>> >>>> 3.7.6.5 H.248 Implementers Guide >>>> >>>> TD-GEN-0035 Reply to LS on Rec. H.248 Annex E, Gain and >>>> Automatic Level Control SG15 >>>> Addressed at the San Jose February 2003 meeting in AVD-2338. No >>>> further action needed. >>>> >>>> D-0347 Proposed additions to H.248 Implementors' Guide LM Ericsson >>>> This contribution was presented and it was agreed to incorporate the >>>> two proposed additions into the H.248 Sub-series implementors' >>>> guide. It was also agreed that text should be on clarifying what >>>> should be sent in a reponse to a request that has only actions and >>>> no commands. This has been added as section 6.18. >>>> >>>> TD-WP2-0028 H.248 Sub-series Implementors' Guide Editor >>>> The editor's draft was presented and accepted. >>>> It was agreed to put the H.248 Sub-Series Implementors' Guide >>>> forward for consent. The agreed text can be found in TD-PLEN-0036R1. >>>> >>>> 3.7.6.6 H.248.1 Annex F ServiceChange >>>> >>>> TD-WP2-0021 Draft H.248.1 Annex F Editor >>>> The editor's draft was presented and it was noted that there were no >>>> changes from San Jose output. It was agreed that this document was >>>> not ready to be put forward for consent. People are encouraged to >>>> contribute on this in the interim meeting. >>>> >>>> TD-WP2-0027 Considerations for discussion of update of >>>> ServiceChange procedures for H.248 Editor >>>> The temporary document was presented as a record of the requirements >>>> for ServiceChange annex work. >>>> >>>> 3.7.6.7 H.248.19 Decomposed MCU Audio, Video and Data Conferencing >>>> Packages >>>> >>>> D-0348 Additional requirements for H.248.19 for Chat >>>> conferencing LM Ericsson >>>> This delayed contribution was presented and discussion on the >>>> difference between messaging and chat conferencing. It was agreed to >>>> add these requirements to H.248.19. Ms.Levin will provide a >>>> reference to work undertaken in the IETF on this work. This >>>> reference should be included in the requirements when it becomes >>>> available. >>>> >>>> D-0349 Addition to H.248.19 for Tiled Windows LM Ericsson >>>> This delayed contribution was presented. It was noted that even in >>>> simple video window configuration individual windows may have >>>> different sizes. It was also noted that in the IETF work is ongoing >>>> on defining profiles for different configurations. It was agreed to >>>> accept this work for inclusion to H.248.19 but further changes maybe >>>> needed to define the use of profiles and the use of non-proportional >>>> window configurations. >>>> >>>> D-0350 Addition to H.248.19 for viewer indication LM Ericsson >>>> This contribution was presented and there was some discussion on the >>>> signal type and whether it should be two signals of type brief or >>>> one signal of type on/off. It was agreed that this should be type >>>> brief however a better explantion of how this is used should be be >>>> included. >>>> >>>> TD-WP2-0017 Draft H.248.19, "Decomposed Multipoint Control Unit, >>>> Audio, Video and Data Conferencing Packages" Editor >>>> The editor's input was presented and was accepted. >>>> >>>> D-0353 Video Coding description in H.245, H.248 and SDP LM >>>> Ericsson >>>> This contribution was presented. Discussion highlighted that for >>>> many video codecs (H.261, H.264) there was not a problem of mapping >>>> H.245 to SDP however a complete mapping between SDP and H.245 did >>>> not exist for H.263. Work is ongoing in the IETF to solve this >>>> problem through the use of profiles or feature description. It was >>>> agreed that this work should be monitored but this issue is of no >>>> consequence to the H.248.19 work. >>>> The output of H.248.19 for this meeting can be found in TD-WP2-60. >>>> >>>> 3.7.6.8 H.248.22 Shared Risk Group Handling Package >>>> >>>> D-0351 H.248.shrisk additions LM Ericsson >>>> The contribution was presented and it was agreed to put forward this >>>> delayed contribution (with editorial corrections) for consent. The >>>> recommendation for consent can be found in TD-PLEN-57. >>>> >>>> 3.7.6.9 H.248.23 Enhanced Alerting Packages >>>> >>>> D-0343 Comments to AVD-2313, "Enhanced Alerting Packages" >>>> Ericsson >>>> This delayed contribution was presented. Each of the bullet points >>>> in the discussion section were addressed, the results of which are >>>> detailed below: >>>> Item 1,2: Agreed to be incorporated in H.248.23 >>>> Item 3: Rejected >>>> Item 4: Text should be included to clarify what the variable >>>> duration is dependent on. >>>> Item 5: The text should be clarified to make clear that an error is >>>> NOT generated only when the data component of the signal is not >>>> delivered. All other errors will generate an error. >>>> Item 6: Text should be included to clarify the use of the TAS signal >>>> Item 7, 8: Included in editor's draft. >>>> >>>> TD-WP2-0022 Draft H.248.23 Enhanced Alerting Packages Editor >>>> This temporary document was presented. The editor stated that this >>>> work had existed for 2 years in the IETF and authors decided to move >>>> it to the ITU. Mr. Okubo questioned whether the IETF had been >>>> consulted over this move. The IETF had received a liaison from >>>> Question 3/16 notifying them of the proposal for taking over the >>>> work. It asked that they respond if there was a problem with this >>>> approach. No response was received. It was also noted that package >>>> development was not specifically part of the IETF Megaco WG charter. >>>> There was a question from Mr.Chatras (France Telecom) as to where >>>> the checksum should be generated, MGC or MG. The editor replied that >>>> as the checksum was associated with the data plane the MGC should be >>>> responsible for generating the checksum. This will be clarified in >>>> updated text. >>>> Mr. Chatras also questioned the need of having an example for ETSI >>>> based encodings. It was agreed that the editor and Mr.Chatras >>>> co-ordinate on such an example. >>>> It was agreed that H.248.23 be put forward for consent. The >>>> recommendation for consent is contained in TD-PLEN-0032. >>>> >>>> 3.7.6.10 H.248.24 MF Tone Generation and Detection Packages >>>> >>>> D-0342 Comments to AVD-2312, "MF Tone Generation and Detection >>>> Packages" Ericsson >>>> This delayed contribution was presented. Each of the bullet points >>>> in the discussion section were addressed, the results of which are >>>> detailed below: >>>> Item 1: Agreed to be incorporated in H.248.24 >>>> Item 2: Resolved. It was agreed to remove the text "was chosen >>>> arbitrarily". >>>> Item 3: Agreed to be incorporated in H.248.24 >>>> Item 4: Agreed to be incorporated in H.248.24 >>>> >>>> TD-WP2-0023 Draft H.248.24 MF Tone Generation and Detection >>>> Packages Editor >>>> This temporary document was presented and accepted. >>>> It was agreed to put forward H.248.24 for consent at this meeting. >>>> The recommendation for consent is contained in TD-PLEN-0033. >>>> >>>> 3.7.6.11 H.248.25 Basic CAS Packages >>>> >>>> D-0327 Comments to AVD-2315, "Basic CAS Packages" Ericsson >>>> This delayed contribution was presented. Each of the bullet points >>>> in the discussion section were addressed, the results of which are >>>> detailed below: >>>> Item 1: Package ID needs to be registered with IANA before final >>>> approval. >>>> Item 2: Editor to check if any values have been dropped. >>>> Item 3,4: Accepted to be resolved. >>>> Item 5: These values need to be reviewed in line with the comments >>>> made in D328. >>>> Item 6: Resolved. The address signal was split in a separate package. >>>> >>>> D-0328 H.248 Basic CAS Package ­ CAS Failure Code Extensions Alcatel >>>> This delayed contribution was presented and listed a number of >>>> concerns with the CAS package on Glare, Start Dailing Timeout, LTO >>>> and Polarity. The editor replied that: >>>> • Glare need not be added as it was already covered by the >>>> procedure section of the package. >>>> • Start Dialling Timeout can be handled by the Register >>>> Timeout Signal in the CAS Address package. >>>> • LTO there are other events that can be used to indicate this >>>> situation. >>>> • Unexpected Line signal could be used to indicate Polarity >>>> error. >>>> It was agreed that this explanation of error conditions should be >>>> included in H.248.24. >>>> >>>> TD-WP2-0016 Draft H.248.25 Basic CAS Packages Editor >>>> This temporary document was presented by the editor. The editor >>>> tabled a number of comments from the IETF mailing list: >>>> 1. Remove RTO as a possible value in bcas/casf event --> ec >>>> parameter (bcas addresses line signals/events, Register signaling is >>>> covered in the derived packages, so register failure reporting is >>>> outside scope of this package) >>>> 2. Added meth parameter in bcasaddr/addr event (digit map is >>>> associated with the reporting of this event) >>>> 3. casblk package has been referred in the icas package there the >>>> CAS Blocking Package should be included. >>>> The comments were agreed. The CAS blocking package will be specified >>>> in the ICAS package. >>>> It was agreed to put forward H.248.25 for consent at this meeting. A >>>> Package ID for the "bcasaddr" package has been requested. The >>>> recommendation for consent is contained in TD-PLEN-58R1. >>>> >>>> 3.7.6.12 H.248.26 Enhanced Analog Line Packages >>>> >>>> D-0346 Comments to AVD-2317, "Enhanced Analogue Line Packages" >>>> Ericsson >>>> This delayed contribution was presented. Each of the bullet points >>>> in the discussion section were addressed, the results of which are >>>> detailed below: >>>> Item 1: Agreed to be included. >>>> Item 2: Rejected. Signal type to remain on/off >>>> Item 3: Agreed to be included. >>>> >>>> TD-WP2-0024 Draft H.248.26 Enhanced Analog Line Packages Editor >>>> This temporary document was presented by the editor and agreed as >>>> baseline text. >>>> It was agreed to put forward H.248.26 for consent at this meeting. >>>> The recommendation for consent is contained in TD-PLEN-0034. >>>> >>>> 3.7.6.13 H.248.27 Supplemental Tones Packages >>>> >>>> D-0344 Comments to AVD-2314, "Supplementary Tones Packages" >>>> Ericsson >>>> This delayed contribution was presented. Each of the bullet points >>>> in the discussion section were addressed, the results of which are >>>> detailed below: >>>> Item 1,2: Agreed to be included >>>> Item 3: Heading should read "Diagnostic Tones" >>>> Item 4: A summary should be added detailing the use of this package. >>>> Item 5: Agreed to be included. >>>> >>>> TD-WP2-0025 Draft H.248.27 Supplemental Tones Packages Editor >>>> This temporary document was presented by the editor and agreed as >>>> baseline text. >>>> It was agreed to put forward H.248.27 for consent at this meeting. >>>> The recommendation for consent is contained in TD-PLEN-0035. >>>> >>>> 3.7.6.14 H.248 Sub-Series Packages Guide >>>> >>>> TD-WP2-0018 Proposed additions to H.248 Sub-Series: Packages >>>> Guide Release 4" Editor >>>> This temporary document was presented and the text agreed as >>>> baseline. A comment was made that packages in >>>> H.248.23,24,25,26,27,icas, icasc should be added. The respective >>>> drafts in the IETF should point to the ITU work. The supplement for >>>> approval is contained in TD-PLEN-56. >>>> >>>> D-0352 Proposed Liaison to Tiphon on H.248 Packages Ericsson >>>> This delayed contribution was presented and it was agreed to send >>>> enclosed liaison to Tiphon. The outgoing liaison can be found in >>>> TD-WP2-56. >>>> >>>> 3.7.7 Other Work to Progress >>>> >>>> 3.7.7.1 H.248.icas International CAS Packages >>>> >>>> D=0345 Comments to AVD-2316, "International CAS Packages" >>>> Ericsson >>>> This delayed contribution was presented. Each of the bullet points >>>> in the discussion section were addressed, the results of which is >>>> detailed below: >>>> Item 1: Agreed to be included. >>>> Item 2: Resolved. Signalling is different for R1 and R2. >>>> Item 3: Agreed to be included. >>>> >>>> D=0341 International CAS Compelled Register Signaling Packages Nortel >>>> This delayed contribution was presented and it was agreed to start >>>> a work item on this. This new work item shall be named H.248.icasc. >>>> D341 is considered baseline text. >>>> >>>> TD-WP2=0026 H.248.icas International CAS Packages Editor >>>> This temporary document was presented by the editor and agreed as >>>> baseline text. >>>> >>>> 3.7.8 New Work >>>> >>>> 3.7.8.1 New Packages for H.248 >>>> >>>> D-0361 Request for an extension package to the H.248 Network >>>> Package for the jitter buffer. (H.248.1 Annex E.11.1) Lucent >>>> This delayed contribution was presented. There was a comment from >>>> Mr. Boyle that if the work was accepted as a package extension the >>>> contribution would need significant editing. Mr. Boyle also >>>> questioned the need for a minimum and nominal jitter value. Mr. >>>> Teising replied that should know the network topology and can >>>> provide these values. It was discussed that the MG would better know >>>> the routing of the bearer so it would be more appropriate for it to >>>> provide the values. >>>> It was agreed to persue this work however extensive editing work is >>>> needed as well a scope and summary addressing the above questions. >>>> An editing session meet to draft text for a baseline document. The >>>> baseline shall be referred to as H.248.ajb and is contained in >>>> TD-WP2-0052. >>>> >>>> D-0362 Request that an extension package be defined to the H.248 >>>> Congestion Control Package (H.248.10) Lucent >>>> This delayed contribution was presented. Mr.Boyle questioned whether >>>> any consideration had been made to use H.248.11. Mr. Tegeler >>>> questioned if congestion on different routes and directions could be >>>> indicated. Mr.Groves expressed concern that the proposed extensions >>>> addressed MG wide congestion events as well as network congestion >>>> events where as the base H.248.10 only addressed MG events. >>>> Mr.Schwarz questioned how congestion of an IP connection carried >>>> over an ATM (AAL5 interface) would be handled? Mr. Schwarz noted >>>> that the resources specified fell in two types: those dealing with >>>> H.248 processing and Media Processing. Due to the number of >>>> questions D362 was not accepted. Mr. Teising undertook to study >>>> these questions and provide an updated contribution at a subsequent >>>> question. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Jun 2 17:15:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24331 for ; Mon, 2 Jun 2003 17:15:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52LEIB23562; Mon, 2 Jun 2003 17:14:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52LDwB23517 for ; Mon, 2 Jun 2003 17:13:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24261 for ; Mon, 2 Jun 2003 17:13:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MwbA-0006W9-00 for megaco@ietf.org; Mon, 02 Jun 2003 17:12:08 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 19Mwb9-0006W1-00 for megaco@ietf.org; Mon, 02 Jun 2003 17:12:07 -0400 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 h52LDM203806; Mon, 2 Jun 2003 17:13:22 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jun 2003 17:13:22 -0400 Message-ID: From: "Kevin Boyle" To: "Tom-PT Taylor" , Aleksandr Ryabin Cc: Megaco List Subject: RE: [Megaco] Summary Of SG 16 Meeting Just Concluded Date: Mon, 2 Jun 2003 17:13:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3294B.C91B02E4" Sender: megaco-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_01C3294B.C91B02E4 Content-Type: text/plain I uploaded the newly approved IG, and the consented text for H.248.23-27. They are currently in the Incoming folder, and will be moved over to the 0305_Gen folder in the near future. Note that these documents are completed, other than editorial changes during the publication process. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Monday, June 02, 2003 4:33 PM To: Aleksandr Ryabin Cc: Megaco List Subject: Re: [Megaco] Summary Of SG 16 Meeting Just Concluded They will probably make it there, labelled by their Recommendation number. One thing you are NOT guaranteed: that this site will contain the documents as the ITU-T will publish them. The best you can hope for is a very late draft. ITU-T members, of course, have full access to all meeting documents at the ITU-T site. You do have to register individually for TIES access. If there is general interest in a document which is a work in progress, I can see about translating it into an I-D for comment. Aleksandr Ryabin wrote: > I did, it only contains input documents. > Where are the output docs? e.g TD-PLEN-57, etc.? > > At 03:15 PM 6/2/2003, Tom Taylor wrote: > >> Have a look at http://standard.pictel.com/ftp/avc-site/0305_Gen/. >> >> Aleksandr Ryabin wrote: >> >>> Hi Tom, >>> Thanks for the info. >>> Are the output documents referred below publicly available? If yes, >>> where from? Thanks >>> Aleks ------_=_NextPart_001_01C3294B.C91B02E4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] Summary Of SG 16 Meeting Just Concluded

I uploaded the newly approved IG, and the consented = text for H.248.23-27.  They are currently in the Incoming folder, = and will be moved over to the 0305_Gen folder in the near = future.

Note that these documents are completed, other than = editorial changes during the publication process.

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH]
Sent: Monday, June 02, 2003 4:33 PM
To: Aleksandr Ryabin
Cc: Megaco List
Subject: Re: [Megaco] Summary Of SG 16 Meeting Just = Concluded


They will probably make it there, labelled by their = Recommendation number.  One
thing you are NOT guaranteed: that this site will = contain the documents as the ITU-T
will publish them.  The best you can hope for = is a very late draft.

ITU-T members, of course, have full access to all = meeting documents at the ITU-T
site.  You do have to register individually for = TIES access.

If there is general interest in a document which is a = work in progress, I can see
about translating it into an I-D for comment.

Aleksandr Ryabin wrote:

> I did, it only contains input documents.
> Where are the output docs? e.g TD-PLEN-57, = etc.?
>
> At 03:15 PM 6/2/2003, Tom Taylor wrote:
>
>> Have a look at http://standard.pictel.com/ftp/avc-site/0305_Gen/.=
>>
>> Aleksandr Ryabin wrote:
>>
>>> Hi Tom,
>>> Thanks for the info.
>>> Are the output documents referred below = publicly available? If yes,
>>> where from? Thanks
>>>         = Aleks

------_=_NextPart_001_01C3294B.C91B02E4-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jun 2 17:16:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24418 for ; Mon, 2 Jun 2003 17:16:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52LGOD23655 for megaco-archive@odin.ietf.org; Mon, 2 Jun 2003 17:16:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52LGOB23652 for ; Mon, 2 Jun 2003 17:16:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24389 for ; Mon, 2 Jun 2003 17:16:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MwdW-0006XT-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 17:14:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MwdV-0006XQ-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 17:14:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52LEIB23562; Mon, 2 Jun 2003 17:14:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52LDwB23517 for ; Mon, 2 Jun 2003 17:13:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24261 for ; Mon, 2 Jun 2003 17:13:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MwbA-0006W9-00 for megaco@ietf.org; Mon, 02 Jun 2003 17:12:08 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 19Mwb9-0006W1-00 for megaco@ietf.org; Mon, 02 Jun 2003 17:12:07 -0400 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 h52LDM203806; Mon, 2 Jun 2003 17:13:22 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jun 2003 17:13:22 -0400 Message-ID: From: "Kevin Boyle" To: "Tom-PT Taylor" , Aleksandr Ryabin Cc: Megaco List Subject: RE: [Megaco] Summary Of SG 16 Meeting Just Concluded Date: Mon, 2 Jun 2003 17:13:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3294B.C91B02E4" Sender: megaco-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_01C3294B.C91B02E4 Content-Type: text/plain I uploaded the newly approved IG, and the consented text for H.248.23-27. They are currently in the Incoming folder, and will be moved over to the 0305_Gen folder in the near future. Note that these documents are completed, other than editorial changes during the publication process. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Monday, June 02, 2003 4:33 PM To: Aleksandr Ryabin Cc: Megaco List Subject: Re: [Megaco] Summary Of SG 16 Meeting Just Concluded They will probably make it there, labelled by their Recommendation number. One thing you are NOT guaranteed: that this site will contain the documents as the ITU-T will publish them. The best you can hope for is a very late draft. ITU-T members, of course, have full access to all meeting documents at the ITU-T site. You do have to register individually for TIES access. If there is general interest in a document which is a work in progress, I can see about translating it into an I-D for comment. Aleksandr Ryabin wrote: > I did, it only contains input documents. > Where are the output docs? e.g TD-PLEN-57, etc.? > > At 03:15 PM 6/2/2003, Tom Taylor wrote: > >> Have a look at http://standard.pictel.com/ftp/avc-site/0305_Gen/. >> >> Aleksandr Ryabin wrote: >> >>> Hi Tom, >>> Thanks for the info. >>> Are the output documents referred below publicly available? If yes, >>> where from? Thanks >>> Aleks ------_=_NextPart_001_01C3294B.C91B02E4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] Summary Of SG 16 Meeting Just Concluded

I uploaded the newly approved IG, and the consented = text for H.248.23-27.  They are currently in the Incoming folder, = and will be moved over to the 0305_Gen folder in the near = future.

Note that these documents are completed, other than = editorial changes during the publication process.

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH]
Sent: Monday, June 02, 2003 4:33 PM
To: Aleksandr Ryabin
Cc: Megaco List
Subject: Re: [Megaco] Summary Of SG 16 Meeting Just = Concluded


They will probably make it there, labelled by their = Recommendation number.  One
thing you are NOT guaranteed: that this site will = contain the documents as the ITU-T
will publish them.  The best you can hope for = is a very late draft.

ITU-T members, of course, have full access to all = meeting documents at the ITU-T
site.  You do have to register individually for = TIES access.

If there is general interest in a document which is a = work in progress, I can see
about translating it into an I-D for comment.

Aleksandr Ryabin wrote:

> I did, it only contains input documents.
> Where are the output docs? e.g TD-PLEN-57, = etc.?
>
> At 03:15 PM 6/2/2003, Tom Taylor wrote:
>
>> Have a look at http://standard.pictel.com/ftp/avc-site/0305_Gen/.=
>>
>> Aleksandr Ryabin wrote:
>>
>>> Hi Tom,
>>> Thanks for the info.
>>> Are the output documents referred below = publicly available? If yes,
>>> where from? Thanks
>>>         = Aleks

------_=_NextPart_001_01C3294B.C91B02E4-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jun 2 22:54:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04794 for ; Mon, 2 Jun 2003 22:54:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h532rEB16494; Mon, 2 Jun 2003 22:53:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h532nYB16363 for ; Mon, 2 Jun 2003 22:49:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04742 for ; Mon, 2 Jun 2003 22:49:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N1pu-00014l-00 for megaco@ietf.org; Mon, 02 Jun 2003 22:47:42 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19N1pt-00014i-00 for megaco@ietf.org; Mon, 02 Jun 2003 22:47:41 -0400 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h532muu00061 for ; Mon, 2 Jun 2003 22:48:57 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L9VC25Y7; Mon, 2 Jun 2003 22:48:56 -0400 Received: from nortelnetworks.com (acart418.ca.nortel.com [47.129.49.145]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0PL1; Mon, 2 Jun 2003 22:48:57 -0400 Message-ID: <3EDC0C97.8000200@nortelnetworks.com> Date: Mon, 02 Jun 2003 22:48:55 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Megaco List Subject: [Fwd: RE: [Megaco] Summary Of SG 16 Meeting Just Concluded] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Earlier attempt didn't get to the list. -------- Original Message -------- Subject: RE: [Megaco] Summary Of SG 16 Meeting Just Concluded Date: Mon, 2 Jun 2003 17:13:16 -0400 From: Boyle, Kevin [NCRTP:3Z40:EXCH] To: Taylor, Tom-PT [CAR:5N00:EXCH] , Aleksandr Ryabin CC: Megaco List I uploaded the newly approved IG, and the consented text for H.248.23-27. They are currently in the Incoming folder, and will be moved over to the 0305_Gen folder in the near future. Note that these documents are completed, other than editorial changes during the publication process. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Monday, June 02, 2003 4:33 PM To: Aleksandr Ryabin Cc: Megaco List Subject: Re: [Megaco] Summary Of SG 16 Meeting Just Concluded They will probably make it there, labelled by their Recommendation number. One thing you are NOT guaranteed: that this site will contain the documents as the ITU-T will publish them. The best you can hope for is a very late draft. ITU-T members, of course, have full access to all meeting documents at the ITU-T site. You do have to register individually for TIES access. If there is general interest in a document which is a work in progress, I can see about translating it into an I-D for comment. Aleksandr Ryabin wrote: > I did, it only contains input documents. > Where are the output docs? e.g TD-PLEN-57, etc.? > > At 03:15 PM 6/2/2003, Tom Taylor wrote: > >> Have a look at http://standard.pictel.com/ftp/avc-site/0305_Gen/. >> >> Aleksandr Ryabin wrote: >> >>> Hi Tom, >>> Thanks for the info. >>> Are the output documents referred below publicly available? If yes, >>> where from? Thanks >>> Aleks _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jun 2 22:56:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04926 for ; Mon, 2 Jun 2003 22:56:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h532te916633 for megaco-archive@odin.ietf.org; Mon, 2 Jun 2003 22:55:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h532teB16630 for ; Mon, 2 Jun 2003 22:55:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04871 for ; Mon, 2 Jun 2003 22:55:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N1vn-00017B-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 22:53:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19N1vn-000177-00 for megaco-web-archive@ietf.org; Mon, 02 Jun 2003 22:53:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h532rEB16494; Mon, 2 Jun 2003 22:53:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h532nYB16363 for ; Mon, 2 Jun 2003 22:49:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04742 for ; Mon, 2 Jun 2003 22:49:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N1pu-00014l-00 for megaco@ietf.org; Mon, 02 Jun 2003 22:47:42 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19N1pt-00014i-00 for megaco@ietf.org; Mon, 02 Jun 2003 22:47:41 -0400 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h532muu00061 for ; Mon, 2 Jun 2003 22:48:57 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L9VC25Y7; Mon, 2 Jun 2003 22:48:56 -0400 Received: from nortelnetworks.com (acart418.ca.nortel.com [47.129.49.145]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0PL1; Mon, 2 Jun 2003 22:48:57 -0400 Message-ID: <3EDC0C97.8000200@nortelnetworks.com> Date: Mon, 02 Jun 2003 22:48:55 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Megaco List Subject: [Fwd: RE: [Megaco] Summary Of SG 16 Meeting Just Concluded] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Earlier attempt didn't get to the list. -------- Original Message -------- Subject: RE: [Megaco] Summary Of SG 16 Meeting Just Concluded Date: Mon, 2 Jun 2003 17:13:16 -0400 From: Boyle, Kevin [NCRTP:3Z40:EXCH] To: Taylor, Tom-PT [CAR:5N00:EXCH] , Aleksandr Ryabin CC: Megaco List I uploaded the newly approved IG, and the consented text for H.248.23-27. They are currently in the Incoming folder, and will be moved over to the 0305_Gen folder in the near future. Note that these documents are completed, other than editorial changes during the publication process. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Monday, June 02, 2003 4:33 PM To: Aleksandr Ryabin Cc: Megaco List Subject: Re: [Megaco] Summary Of SG 16 Meeting Just Concluded They will probably make it there, labelled by their Recommendation number. One thing you are NOT guaranteed: that this site will contain the documents as the ITU-T will publish them. The best you can hope for is a very late draft. ITU-T members, of course, have full access to all meeting documents at the ITU-T site. You do have to register individually for TIES access. If there is general interest in a document which is a work in progress, I can see about translating it into an I-D for comment. Aleksandr Ryabin wrote: > I did, it only contains input documents. > Where are the output docs? e.g TD-PLEN-57, etc.? > > At 03:15 PM 6/2/2003, Tom Taylor wrote: > >> Have a look at http://standard.pictel.com/ftp/avc-site/0305_Gen/. >> >> Aleksandr Ryabin wrote: >> >>> Hi Tom, >>> Thanks for the info. >>> Are the output documents referred below publicly available? If yes, >>> where from? Thanks >>> Aleks _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jun 3 07:52:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27949 for ; Tue, 3 Jun 2003 07:52:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53BpIB04708; Tue, 3 Jun 2003 07:51:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53BlcB04481 for ; Tue, 3 Jun 2003 07:47:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27484; Tue, 3 Jun 2003 07:47:36 -0400 (EDT) Message-Id: <200306031147.HAA27484@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: megaco@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 03 Jun 2003 07:47:36 -0400 Subject: [Megaco] I-D ACTION:draft-ietf-megaco-callflows-02.txt Sender: megaco-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Media Gateway Control Working Group of the IETF. Title : Megaco/H.248 Call flow examples Author(s) : M. Brahmanapally, P. Viswanadham, K. Gundamaraju Filename : draft-ietf-megaco-callflows-02.txt Pages : 295 Date : 2003-6-2 The Megaco/H.248 call flow examples draft illustrates the usage of Megaco - Version 1 protocol [Ref:3] defined between the Media Gateway Controller and Media Gateway. In light of the vast features presently incorporated and continuously evolving features of the protocol, it serves the purpose of representing typical use case scenarios. There are a lot of possible scenarios for usage of MEGACO protocol. It is not the intent of the draft to represent the inter-working functionality among various protocols, however, an attempt is made to depict its usage in such a case for the purpose of completeness in the larger perspective. An attempt has been made to illustrate the supplementary call services using MEGACO. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-callflows-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-megaco-callflows-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-megaco-callflows-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-2145705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-callflows-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-callflows-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-2145705.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jun 3 07:53:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28017 for ; Tue, 3 Jun 2003 07:53:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53Bqwp04899 for megaco-archive@odin.ietf.org; Tue, 3 Jun 2003 07:52:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53BqvB04896 for ; Tue, 3 Jun 2003 07:52:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27992 for ; Tue, 3 Jun 2003 07:52:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NAJo-0004Gf-00 for megaco-web-archive@ietf.org; Tue, 03 Jun 2003 07:51:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NAJn-0004Gc-00 for megaco-web-archive@ietf.org; Tue, 03 Jun 2003 07:51:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53BpIB04708; Tue, 3 Jun 2003 07:51:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53BlcB04481 for ; Tue, 3 Jun 2003 07:47:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27484; Tue, 3 Jun 2003 07:47:36 -0400 (EDT) Message-Id: <200306031147.HAA27484@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: megaco@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 03 Jun 2003 07:47:36 -0400 Subject: [Megaco] I-D ACTION:draft-ietf-megaco-callflows-02.txt Sender: megaco-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Media Gateway Control Working Group of the IETF. Title : Megaco/H.248 Call flow examples Author(s) : M. Brahmanapally, P. Viswanadham, K. Gundamaraju Filename : draft-ietf-megaco-callflows-02.txt Pages : 295 Date : 2003-6-2 The Megaco/H.248 call flow examples draft illustrates the usage of Megaco - Version 1 protocol [Ref:3] defined between the Media Gateway Controller and Media Gateway. In light of the vast features presently incorporated and continuously evolving features of the protocol, it serves the purpose of representing typical use case scenarios. There are a lot of possible scenarios for usage of MEGACO protocol. It is not the intent of the draft to represent the inter-working functionality among various protocols, however, an attempt is made to depict its usage in such a case for the purpose of completeness in the larger perspective. An attempt has been made to illustrate the supplementary call services using MEGACO. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-callflows-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-megaco-callflows-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-megaco-callflows-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-2145705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-callflows-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-callflows-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-2145705.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jun 3 10:21:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06795 for ; Tue, 3 Jun 2003 10:21:22 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53EJkB18517; Tue, 3 Jun 2003 10:19:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53EHfB18395 for ; Tue, 3 Jun 2003 10:17:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06659; Tue, 3 Jun 2003 10:17:34 -0400 (EDT) From: Albrecht.Schwarz@alcatel.de Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NCZn-0006Qq-00; Tue, 03 Jun 2003 10:15:47 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.71] helo=mailrelay1.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 19NCZm-0006QT-00; Tue, 03 Jun 2003 10:15:46 -0400 Received: from slsas5.stgl.netd.alcatel.de (destgs0000c.ad1.ad.alcatel.com [149.204.45.57]) by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id QAA26218; Tue, 3 Jun 2003 16:14:51 +0200 (MET DST) Subject: H.248.19 & H.248.22; RE: [Megaco] Summary Of SG 16 Meeting Just Concluded To: "Kevin Boyle" Cc: Aleksandr Ryabin , Megaco List , megaco-admin@ietf.org, "Tom-PT Taylor" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 3 Jun 2003 16:15:00 +0200 X-MIMETrack: Serialize by Router on DEMTA001/DE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/03/2003 04:15:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes Sender: megaco-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: , Kevin, what about H.248.22 Shared Risk Group Package and H.248.19 Decomposed MCU Package? Packages status wasn't mentioned in Tom's TD 84 (PLEN) excerpt, and draft docs aren't uploaded on pictel avt site. Are there any specific reasons behind? Thanks Albrecht "Kevin Boyle" , Aleksandr Ryabin tworks.com> cc: Megaco List Sent by: Subject: RE: [Megaco] Summary Of SG 16 Meeting Just Concluded megaco-admin@iet f.org 02.06.2003 23:13 I uploaded the newly approved IG, and the consented text for H.248.23-27. They are currently in the Incoming folder, and will be moved over to the 0305_Gen folder in the near future. Note that these documents are completed, other than editorial changes during the publication process. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Monday, June 02, 2003 4:33 PM To: Aleksandr Ryabin Cc: Megaco List Subject: Re: [Megaco] Summary Of SG 16 Meeting Just Concluded They will probably make it there, labelled by their Recommendation number. One thing you are NOT guaranteed: that this site will contain the documents as the ITU-T will publish them. The best you can hope for is a very late draft. ITU-T members, of course, have full access to all meeting documents at the ITU-T site. You do have to register individually for TIES access. If there is general interest in a document which is a work in progress, I can see about translating it into an I-D for comment. Aleksandr Ryabin wrote: > I did, it only contains input documents. > Where are the output docs? e.g TD-PLEN-57, etc.? > > At 03:15 PM 6/2/2003, Tom Taylor wrote: > >> Have a look at http://standard.pictel.com/ftp/avc-site/0305_Gen/. >> >> Aleksandr Ryabin wrote: >> >>> Hi Tom, >>> Thanks for the info. >>> Are the output documents referred below publicly available? If yes, >>> where from? Thanks >>> Aleks _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jun 3 10:22:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06850 for ; Tue, 3 Jun 2003 10:22:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53EM5S18716 for megaco-archive@odin.ietf.org; Tue, 3 Jun 2003 10:22:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53EM5B18713 for ; Tue, 3 Jun 2003 10:22:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06834 for ; Tue, 3 Jun 2003 10:21:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NCe4-0006Tj-00 for megaco-web-archive@ietf.org; Tue, 03 Jun 2003 10:20:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NCe4-0006Tg-00 for megaco-web-archive@ietf.org; Tue, 03 Jun 2003 10:20:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53EJkB18517; Tue, 3 Jun 2003 10:19:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53EHfB18395 for ; Tue, 3 Jun 2003 10:17:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06659; Tue, 3 Jun 2003 10:17:34 -0400 (EDT) From: Albrecht.Schwarz@alcatel.de Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NCZn-0006Qq-00; Tue, 03 Jun 2003 10:15:47 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.71] helo=mailrelay1.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 19NCZm-0006QT-00; Tue, 03 Jun 2003 10:15:46 -0400 Received: from slsas5.stgl.netd.alcatel.de (destgs0000c.ad1.ad.alcatel.com [149.204.45.57]) by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id QAA26218; Tue, 3 Jun 2003 16:14:51 +0200 (MET DST) Subject: H.248.19 & H.248.22; RE: [Megaco] Summary Of SG 16 Meeting Just Concluded To: "Kevin Boyle" Cc: Aleksandr Ryabin , Megaco List , megaco-admin@ietf.org, "Tom-PT Taylor" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 3 Jun 2003 16:15:00 +0200 X-MIMETrack: Serialize by Router on DEMTA001/DE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/03/2003 04:15:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes Sender: megaco-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: , Kevin, what about H.248.22 Shared Risk Group Package and H.248.19 Decomposed MCU Package? Packages status wasn't mentioned in Tom's TD 84 (PLEN) excerpt, and draft docs aren't uploaded on pictel avt site. Are there any specific reasons behind? Thanks Albrecht "Kevin Boyle" , Aleksandr Ryabin tworks.com> cc: Megaco List Sent by: Subject: RE: [Megaco] Summary Of SG 16 Meeting Just Concluded megaco-admin@iet f.org 02.06.2003 23:13 I uploaded the newly approved IG, and the consented text for H.248.23-27. They are currently in the Incoming folder, and will be moved over to the 0305_Gen folder in the near future. Note that these documents are completed, other than editorial changes during the publication process. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Monday, June 02, 2003 4:33 PM To: Aleksandr Ryabin Cc: Megaco List Subject: Re: [Megaco] Summary Of SG 16 Meeting Just Concluded They will probably make it there, labelled by their Recommendation number. One thing you are NOT guaranteed: that this site will contain the documents as the ITU-T will publish them. The best you can hope for is a very late draft. ITU-T members, of course, have full access to all meeting documents at the ITU-T site. You do have to register individually for TIES access. If there is general interest in a document which is a work in progress, I can see about translating it into an I-D for comment. Aleksandr Ryabin wrote: > I did, it only contains input documents. > Where are the output docs? e.g TD-PLEN-57, etc.? > > At 03:15 PM 6/2/2003, Tom Taylor wrote: > >> Have a look at http://standard.pictel.com/ftp/avc-site/0305_Gen/. >> >> Aleksandr Ryabin wrote: >> >>> Hi Tom, >>> Thanks for the info. >>> Are the output documents referred below publicly available? If yes, >>> where from? Thanks >>> Aleks _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jun 4 01:37:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07650 for ; Wed, 4 Jun 2003 01:37:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h545ZxB32088; Wed, 4 Jun 2003 01:35:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h545XHB32003 for ; Wed, 4 Jun 2003 01:33:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07611; Wed, 4 Jun 2003 01:33:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NQrr-00066C-00; Wed, 04 Jun 2003 01:31:23 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19NQrq-000669-00; Wed, 04 Jun 2003 01:31:22 -0400 Received: from brsf10.epa.ericsson.se ([61.88.9.226]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h545UWT21251; Wed, 4 Jun 2003 15:30:33 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h545Wvb10538; Wed, 4 Jun 2003 15:32:57 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.236.88]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LZBXMZ2A; Wed, 4 Jun 2003 15:32:55 +1000 Message-ID: <3EDD7E1E.763E3B88@ericsson.com.au> Date: Wed, 04 Jun 2003 15:05:34 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Albrecht.Schwarz@alcatel.de CC: Kevin Boyle , Aleksandr Ryabin , Megaco List , megaco-admin@ietf.org, Tom-PT Taylor Subject: Re: H.248.19 & H.248.22; RE: [Megaco] Summary Of SG 16 Meeting Just Concluded References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Albrecht, I suspect Kevin did not upload those files because he is not the editor of them. I was editor of H.248.22 and H.248.19. The input contributions for H.248.22 and H.248.19 can be found on the site below. I have also recently uploaded the output H.248.19, H.248.22, H.248 Packages Supplement documents to this site. Regards, Christian Albrecht.Schwarz@alcatel.de wrote: > > Kevin, > > what about H.248.22 Shared Risk Group Package > and H.248.19 Decomposed MCU Package? > Packages status wasn't mentioned in Tom's TD 84 (PLEN) excerpt, and draft > docs aren't uploaded on pictel avt site. > Are there any specific reasons behind? > > Thanks > Albrecht > > > "Kevin Boyle" > , Aleksandr Ryabin > tworks.com> cc: Megaco List > Sent by: Subject: RE: [Megaco] Summary Of SG 16 Meeting Just Concluded > megaco-admin@iet > f.org > > > 02.06.2003 23:13 > > > > I uploaded the newly approved IG, and the consented text for H.248.23-27. > They are currently in the Incoming folder, and will be moved over to the > 0305_Gen folder in the near future. > > Note that these documents are completed, other than editorial changes > during the publication process. > > Kevin > > -----Original Message----- > From: Taylor, Tom-PT [CAR:5N00:EXCH] > Sent: Monday, June 02, 2003 4:33 PM > To: Aleksandr Ryabin > Cc: Megaco List > Subject: Re: [Megaco] Summary Of SG 16 Meeting Just Concluded > > They will probably make it there, labelled by their Recommendation number. > One > thing you are NOT guaranteed: that this site will contain the documents as > the ITU-T > will publish them. The best you can hope for is a very late draft. > > ITU-T members, of course, have full access to all meeting documents at the > ITU-T > site. You do have to register individually for TIES access. > > If there is general interest in a document which is a work in progress, I > can see > about translating it into an I-D for comment. > > Aleksandr Ryabin wrote: > > > I did, it only contains input documents. > > Where are the output docs? e.g TD-PLEN-57, etc.? > > > > At 03:15 PM 6/2/2003, Tom Taylor wrote: > > > >> Have a look at http://standard.pictel.com/ftp/avc-site/0305_Gen/. > >> > >> Aleksandr Ryabin wrote: > >> > >>> Hi Tom, > >>> Thanks for the info. > >>> Are the output documents referred below publicly available? If yes, > >>> where from? Thanks > >>> Aleks > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jun 4 01:39:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07691 for ; Wed, 4 Jun 2003 01:39:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h545ccj00581 for megaco-archive@odin.ietf.org; Wed, 4 Jun 2003 01:38:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h545ccB00578 for ; Wed, 4 Jun 2003 01:38:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07686 for ; Wed, 4 Jun 2003 01:38:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NQx3-00067D-00 for megaco-web-archive@ietf.org; Wed, 04 Jun 2003 01:36:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NQx2-000679-00 for megaco-web-archive@ietf.org; Wed, 04 Jun 2003 01:36:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h545ZxB32088; Wed, 4 Jun 2003 01:35:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h545XHB32003 for ; Wed, 4 Jun 2003 01:33:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07611; Wed, 4 Jun 2003 01:33:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NQrr-00066C-00; Wed, 04 Jun 2003 01:31:23 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19NQrq-000669-00; Wed, 04 Jun 2003 01:31:22 -0400 Received: from brsf10.epa.ericsson.se ([61.88.9.226]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h545UWT21251; Wed, 4 Jun 2003 15:30:33 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h545Wvb10538; Wed, 4 Jun 2003 15:32:57 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.236.88]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LZBXMZ2A; Wed, 4 Jun 2003 15:32:55 +1000 Message-ID: <3EDD7E1E.763E3B88@ericsson.com.au> Date: Wed, 04 Jun 2003 15:05:34 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Albrecht.Schwarz@alcatel.de CC: Kevin Boyle , Aleksandr Ryabin , Megaco List , megaco-admin@ietf.org, Tom-PT Taylor Subject: Re: H.248.19 & H.248.22; RE: [Megaco] Summary Of SG 16 Meeting Just Concluded References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Albrecht, I suspect Kevin did not upload those files because he is not the editor of them. I was editor of H.248.22 and H.248.19. The input contributions for H.248.22 and H.248.19 can be found on the site below. I have also recently uploaded the output H.248.19, H.248.22, H.248 Packages Supplement documents to this site. Regards, Christian Albrecht.Schwarz@alcatel.de wrote: > > Kevin, > > what about H.248.22 Shared Risk Group Package > and H.248.19 Decomposed MCU Package? > Packages status wasn't mentioned in Tom's TD 84 (PLEN) excerpt, and draft > docs aren't uploaded on pictel avt site. > Are there any specific reasons behind? > > Thanks > Albrecht > > > "Kevin Boyle" > , Aleksandr Ryabin > tworks.com> cc: Megaco List > Sent by: Subject: RE: [Megaco] Summary Of SG 16 Meeting Just Concluded > megaco-admin@iet > f.org > > > 02.06.2003 23:13 > > > > I uploaded the newly approved IG, and the consented text for H.248.23-27. > They are currently in the Incoming folder, and will be moved over to the > 0305_Gen folder in the near future. > > Note that these documents are completed, other than editorial changes > during the publication process. > > Kevin > > -----Original Message----- > From: Taylor, Tom-PT [CAR:5N00:EXCH] > Sent: Monday, June 02, 2003 4:33 PM > To: Aleksandr Ryabin > Cc: Megaco List > Subject: Re: [Megaco] Summary Of SG 16 Meeting Just Concluded > > They will probably make it there, labelled by their Recommendation number. > One > thing you are NOT guaranteed: that this site will contain the documents as > the ITU-T > will publish them. The best you can hope for is a very late draft. > > ITU-T members, of course, have full access to all meeting documents at the > ITU-T > site. You do have to register individually for TIES access. > > If there is general interest in a document which is a work in progress, I > can see > about translating it into an I-D for comment. > > Aleksandr Ryabin wrote: > > > I did, it only contains input documents. > > Where are the output docs? e.g TD-PLEN-57, etc.? > > > > At 03:15 PM 6/2/2003, Tom Taylor wrote: > > > >> Have a look at http://standard.pictel.com/ftp/avc-site/0305_Gen/. > >> > >> Aleksandr Ryabin wrote: > >> > >>> Hi Tom, > >>> Thanks for the info. > >>> Are the output documents referred below publicly available? If yes, > >>> where from? Thanks > >>> Aleks > > _______________________________________________ > 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 Jun 4 05:08:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08876 for ; Wed, 4 Jun 2003 05:08:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54978B27676; Wed, 4 Jun 2003 05:07:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5495MB27382 for ; Wed, 4 Jun 2003 05:05:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08788 for ; Wed, 4 Jun 2003 05:05:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NUB7-00001D-00 for megaco@ietf.org; Wed, 04 Jun 2003 05:03:29 -0400 Received: from [211.206.122.240] (helo=mail.mailwave.co.kr) by ietf-mx with smtp (Exim 4.12) id 19NUB7-00001A-00 for megaco@ietf.org; Wed, 04 Jun 2003 05:03:29 -0400 Received: from unknown[203.233.7.254] (envelope sender: ) by 211.206.122.240 (TERRACE MAILCENTER) with ESMTP for ; Wed, 04 Jun 2003 18:08:45 KST +0900 From: "Jay H Kim" To: Date: Wed, 4 Jun 2003 18:08:27 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h5495MB27383 Subject: [Megaco] AuditValue Reply in draft-ietf-megaco-callflows-02 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dear All, There are three questions for draft-ietf-megaco-callflows-02. At the end of section 3.1 (page 148 and 149), the auditValue reply message is shown. Q1] Does the auditReply have the auditDescriptor also? Q2] If the auditReply has the auditDescriptor, is the "audit" just typo or not? Q3] While the AuditToken is defined as "Audit" or "AT", but the given token in the text is "audit". Is there any clarification for upper and lower case letter? G'Day The following text is from the draft-ietf-megaco-callflows-02 =================================================== MEGACO/1 [209.110.59.34]:25000 Reply = 1235 { Context = 2 { AuditValue = EphA { Media { TerminationState { ServiceState = InService, Buffer = OFF }, Stream = 1 { LocalControl { Mode = SendReceive, nt/jit=40 }, Local { v=0 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 0 a=ptime:30 }, Remote { v=0 o=- 2890844525 2890842816 IN IP4 209.110.44.44 s=- t= 00 c=IN IP4 209.110.44.45 m=audio 40000 RTP/AVP 0 a=ptime:30 } } }, audit { Events, Signals, DigitMap}, Packages {nt-1, rtp-1}, Statistics { rtp/ps=1200, ; packets sent nt/os=62300, ; octets sent rtp/pr=700, ; packets received nt/or=45100, ; octets received rtp/pl=0.2, ; % packet loss rtp/jit=20, rtp/delay=40 } ; avg latency } } } ================================================================ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jun 4 05:09:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08924 for ; Wed, 4 Jun 2003 05:09:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54990C28393 for megaco-archive@odin.ietf.org; Wed, 4 Jun 2003 05:09:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54990B28390 for ; Wed, 4 Jun 2003 05:09:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08901 for ; Wed, 4 Jun 2003 05:08:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NUEd-00002y-00 for megaco-web-archive@ietf.org; Wed, 04 Jun 2003 05:07:07 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NUEd-00002v-00 for megaco-web-archive@ietf.org; Wed, 04 Jun 2003 05:07:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54978B27676; Wed, 4 Jun 2003 05:07:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5495MB27382 for ; Wed, 4 Jun 2003 05:05:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08788 for ; Wed, 4 Jun 2003 05:05:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NUB7-00001D-00 for megaco@ietf.org; Wed, 04 Jun 2003 05:03:29 -0400 Received: from [211.206.122.240] (helo=mail.mailwave.co.kr) by ietf-mx with smtp (Exim 4.12) id 19NUB7-00001A-00 for megaco@ietf.org; Wed, 04 Jun 2003 05:03:29 -0400 Received: from unknown[203.233.7.254] (envelope sender: ) by 211.206.122.240 (TERRACE MAILCENTER) with ESMTP for ; Wed, 04 Jun 2003 18:08:45 KST +0900 From: "Jay H Kim" To: Date: Wed, 4 Jun 2003 18:08:27 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h5495MB27383 Subject: [Megaco] AuditValue Reply in draft-ietf-megaco-callflows-02 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Dear All, There are three questions for draft-ietf-megaco-callflows-02. At the end of section 3.1 (page 148 and 149), the auditValue reply message is shown. Q1] Does the auditReply have the auditDescriptor also? Q2] If the auditReply has the auditDescriptor, is the "audit" just typo or not? Q3] While the AuditToken is defined as "Audit" or "AT", but the given token in the text is "audit". Is there any clarification for upper and lower case letter? G'Day The following text is from the draft-ietf-megaco-callflows-02 =================================================== MEGACO/1 [209.110.59.34]:25000 Reply = 1235 { Context = 2 { AuditValue = EphA { Media { TerminationState { ServiceState = InService, Buffer = OFF }, Stream = 1 { LocalControl { Mode = SendReceive, nt/jit=40 }, Local { v=0 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 0 a=ptime:30 }, Remote { v=0 o=- 2890844525 2890842816 IN IP4 209.110.44.44 s=- t= 00 c=IN IP4 209.110.44.45 m=audio 40000 RTP/AVP 0 a=ptime:30 } } }, audit { Events, Signals, DigitMap}, Packages {nt-1, rtp-1}, Statistics { rtp/ps=1200, ; packets sent nt/os=62300, ; octets sent rtp/pr=700, ; packets received nt/or=45100, ; octets received rtp/pl=0.2, ; % packet loss rtp/jit=20, rtp/delay=40 } ; avg latency } } } ================================================================ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jun 4 12:53:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01166 for ; Wed, 4 Jun 2003 12:53:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54GpuB01293; Wed, 4 Jun 2003 12:51:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54GoZB01249 for ; Wed, 4 Jun 2003 12:50:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01100 for ; Wed, 4 Jun 2003 12:50:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NbRK-0005Zk-00 for megaco@ietf.org; Wed, 04 Jun 2003 12:48:42 -0400 Received: from amethyst.syndeocorp.com ([4.21.34.131] helo=syndeocorp.com) by ietf-mx with esmtp (Exim 4.12) id 19NbRJ-0005ZS-00 for megaco@ietf.org; Wed, 04 Jun 2003 12:48:41 -0400 Received: from madhupc (madhu-pc.syndeocorp.com [4.21.35.182]) by syndeocorp.com (Switch-2.0.1/Switch-2.0.1) with SMTP id h54Gnle09899; Wed, 4 Jun 2003 09:49:47 -0700 (PDT) Reply-To: From: "Madhu Babu Brahmanapally" To: "'Jay H Kim'" , Subject: RE: [Megaco] AuditValue Reply in draft-ietf-megaco-callflows-02 Date: Wed, 4 Jun 2003 09:56:42 -0700 Message-ID: <022201c32aba$47763a40$b6231504@madhupc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 In-Reply-To: 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 Jay, Thanks for your review. According to Annex B, "Everything in the ABNF and text encoding is case insensitive.". As speicified in 7.2.5 the auditValue response shouldnot include a Audit descriptor. I will make necessary changes to the draft. Thanks for your input. Regards Madhubabu -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Jay H Kim Sent: Wednesday, June 04, 2003 2:08 AM To: megaco@ietf.org Subject: [Megaco] AuditValue Reply in draft-ietf-megaco-callflows-02 Dear All, There are three questions for draft-ietf-megaco-callflows-02. At the end of section 3.1 (page 148 and 149), the auditValue reply message is shown. Q1] Does the auditReply have the auditDescriptor also? Q2] If the auditReply has the auditDescriptor, is the "audit" just typo or not? Q3] While the AuditToken is defined as "Audit" or "AT", but the given token in the text is "audit". Is there any clarification for upper and lower case letter? G'Day The following text is from the draft-ietf-megaco-callflows-02 =================================================== MEGACO/1 [209.110.59.34]:25000 Reply = 1235 { Context = 2 { AuditValue = EphA { Media { TerminationState { ServiceState = InService, Buffer = OFF }, Stream = 1 { LocalControl { Mode = SendReceive, nt/jit=40 }, Local { v=0 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 0 a=ptime:30 }, Remote { v=0 o=- 2890844525 2890842816 IN IP4 209.110.44.44 s=- t= 00 c=IN IP4 209.110.44.45 m=audio 40000 RTP/AVP 0 a=ptime:30 } } }, audit { Events, Signals, DigitMap}, Packages {nt-1, rtp-1}, Statistics { rtp/ps=1200, ; packets sent nt/os=62300, ; octets sent rtp/pr=700, ; packets received nt/or=45100, ; octets received rtp/pl=0.2, ; % packet loss rtp/jit=20, rtp/delay=40 } ; avg latency } } } ================================================================ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jun 4 12:54:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01216 for ; Wed, 4 Jun 2003 12:54:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54Gs9b01410 for megaco-archive@odin.ietf.org; Wed, 4 Jun 2003 12:54:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54Gs9B01407 for ; Wed, 4 Jun 2003 12:54:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01196 for ; Wed, 4 Jun 2003 12:54:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NbUm-0005bT-00 for megaco-web-archive@ietf.org; Wed, 04 Jun 2003 12:52:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NbUl-0005bQ-00 for megaco-web-archive@ietf.org; Wed, 04 Jun 2003 12:52:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54GpuB01293; Wed, 4 Jun 2003 12:51:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54GoZB01249 for ; Wed, 4 Jun 2003 12:50:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01100 for ; Wed, 4 Jun 2003 12:50:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NbRK-0005Zk-00 for megaco@ietf.org; Wed, 04 Jun 2003 12:48:42 -0400 Received: from amethyst.syndeocorp.com ([4.21.34.131] helo=syndeocorp.com) by ietf-mx with esmtp (Exim 4.12) id 19NbRJ-0005ZS-00 for megaco@ietf.org; Wed, 04 Jun 2003 12:48:41 -0400 Received: from madhupc (madhu-pc.syndeocorp.com [4.21.35.182]) by syndeocorp.com (Switch-2.0.1/Switch-2.0.1) with SMTP id h54Gnle09899; Wed, 4 Jun 2003 09:49:47 -0700 (PDT) Reply-To: From: "Madhu Babu Brahmanapally" To: "'Jay H Kim'" , Subject: RE: [Megaco] AuditValue Reply in draft-ietf-megaco-callflows-02 Date: Wed, 4 Jun 2003 09:56:42 -0700 Message-ID: <022201c32aba$47763a40$b6231504@madhupc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jay, Thanks for your review. According to Annex B, "Everything in the ABNF and text encoding is case insensitive.". As speicified in 7.2.5 the auditValue response shouldnot include a Audit descriptor. I will make necessary changes to the draft. Thanks for your input. Regards Madhubabu -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Jay H Kim Sent: Wednesday, June 04, 2003 2:08 AM To: megaco@ietf.org Subject: [Megaco] AuditValue Reply in draft-ietf-megaco-callflows-02 Dear All, There are three questions for draft-ietf-megaco-callflows-02. At the end of section 3.1 (page 148 and 149), the auditValue reply message is shown. Q1] Does the auditReply have the auditDescriptor also? Q2] If the auditReply has the auditDescriptor, is the "audit" just typo or not? Q3] While the AuditToken is defined as "Audit" or "AT", but the given token in the text is "audit". Is there any clarification for upper and lower case letter? G'Day The following text is from the draft-ietf-megaco-callflows-02 =================================================== MEGACO/1 [209.110.59.34]:25000 Reply = 1235 { Context = 2 { AuditValue = EphA { Media { TerminationState { ServiceState = InService, Buffer = OFF }, Stream = 1 { LocalControl { Mode = SendReceive, nt/jit=40 }, Local { v=0 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 0 a=ptime:30 }, Remote { v=0 o=- 2890844525 2890842816 IN IP4 209.110.44.44 s=- t= 00 c=IN IP4 209.110.44.45 m=audio 40000 RTP/AVP 0 a=ptime:30 } } }, audit { Events, Signals, DigitMap}, Packages {nt-1, rtp-1}, Statistics { rtp/ps=1200, ; packets sent nt/os=62300, ; octets sent rtp/pr=700, ; packets received nt/or=45100, ; octets received rtp/pl=0.2, ; % packet loss rtp/jit=20, rtp/delay=40 } ; avg latency } } } ================================================================ _______________________________________________ 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 Jun 5 04:58:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12052 for ; Thu, 5 Jun 2003 04:58:39 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h558vbB14867; Thu, 5 Jun 2003 04:57:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h558tJB14784 for ; Thu, 5 Jun 2003 04:55:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11971 for ; Thu, 5 Jun 2003 04:55:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NqUu-0004Lk-00 for megaco@ietf.org; Thu, 05 Jun 2003 04:53:24 -0400 Received: from [211.206.122.239] (helo=mail.mailwave.co.kr) by ietf-mx with smtp (Exim 4.12) id 19NqUp-0004Lf-00 for megaco@ietf.org; Thu, 05 Jun 2003 04:53:19 -0400 Received: from unknown[203.233.7.254] (envelope sender: ) by 211.206.122.239 (TERRACE MAILCENTER) with ESMTP for ; Thu, 05 Jun 2003 17:58:30 KST +0900 From: "Jay H Kim" To: Date: Thu, 5 Jun 2003 17:58:12 +0900 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01C32B8C.07C4F530" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: [Megaco] EventsToken in auditItem of teminationAudit or empty eventsDescriptor Sender: megaco-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_003B_01C32B8C.07C4F530 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 V2hlbiBJIHBhcnNlIHRoZSBtZWdhY28gQXVkaXQgUmVzcG9uc2UgbWVzc2FnZSwgSSBzdGFuZCBh IGNvbmZ1c2luZyB0ZXh0Lg0KIA0KRm9yIGZvbGxvd2luZyBBdWRpdFZhbHVlIFJlc3BvbnNlIG1l c3NhZ2UsDQpEb2VzIHRoZSAiRXZlbnRzIiBpbmRpY2F0ZSBFdmVudHNUb2tlbiBpbiBhdWRpdEl0 ZW0gb3IgZW1wdHkgZXZlbnRzRGVzY3JpcHRvcj8NCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KTUVHQUNPLzEgWzIwOS4xMTAuNTkuMzRdOjI1MDAwDQogICBSZXBseSA9IDEyMzUg ew0KICAgICAgQ29udGV4dCA9IDIgew0KICAgQXVkaXRWYWx1ZSA9IEVwaEEgew0KICAgICAgICAg ICAgIEV2ZW50cywNCiAgICAgICAgICAgICB9DQogICAgICAgfQ0KICAgfQ0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCiANCkFjY29yZGluZyB0IG8gdGhlIEFubmV4IEIuMiwg dGVybWluYXRpb25BdWRpdCBjYW4gaGF2ZSBldmVudHNEZXNjcmlwdG9yIG9yIGF1ZGl0SXRlbS4N ClRoZSBldmVudHNEZXNjcmlwdG9yIGNhbiBiZSBlbXB0eShpZS4gRXZlbnRzVG9rZW4gb25seSkg YW5kIHRoZSBhdWRpdEl0ZW0gY2FuIGhhdmUgRXZlbnRzVG9rZW4gYWxzby4NCg0KQ291bGQgYW55 b25lIGdpdmUgbWUgdGhlIGNsYXJpZmljYXRpb24gZm9yIHRoaXM/DQpUaGFua3MgZm9yd2FyZC4N CiANCkcnRGF5DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpKYXkgSCBLaW0NClImRCBDZW50ZXIgIFhFTkVSIFN5c3RlbXMgSW5j Lg0KT2ZmaWNlOiArODItMi0zNDgyLTQ5MDAuIGV4dC40MTENCkZheDogKzgyLTItMzQ4My00OTAy DQorbWFpbHRvOmpheWhraW1AeGVuZXIuY29tDQpIb21lcGFnZTogd3d3LnhlbmVyLmNvbQ0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQoN Cg== ------=_NextPart_000_003B_01C32B8C.07C4F530 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXVz LWFzY2lpIiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA1 LjAwLjMzMTUuMjg3MCIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWPjxGT05U IGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+DQo8RElWPjxGT05UIHNpemU9Mj48U1BBTiBj bGFzcz0yNDE1MDQyMDgtMDUwNjIwMDM+V2hlbiBJIHBhcnNlIHRoZSBtZWdhY28gQXVkaXQgDQpS ZXNwb25zZSBtZXNzYWdlLCBJIHN0YW5kIGEgY29uZnVzaW5nIHRleHQuPC9TUEFOPjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTI0MTUwNDIwOC0wNTA2MjAwMz48 L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9 MjQxNTA0MjA4LTA1MDYyMDAzPkZvciBmb2xsb3dpbmcgQXVkaXRWYWx1ZSANClJlc3BvbnNlIG1l c3NhZ2UsPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNz PTI0MTUwNDIwOC0wNTA2MjAwMz5Eb2VzJm5ic3A7dGhlICJFdmVudHMiIGluZGljYXRlIA0KRXZl bnRzVG9rZW4gaW4gYXVkaXRJdGVtIG9yIGVtcHR5IGV2ZW50c0Rlc2NyaXB0b3I/PC9TUEFOPjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9MjQxNTA0MjA4LTA1 MDYyMDAzPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvU1BBTj48L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5NRUdBQ08vMSBbMjA5LjExMC41OS4zNF06MjUwMDA8QlI+ Jm5ic3A7Jm5ic3A7IFJlcGx5ID0gMTIzNSANCns8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IENvbnRleHQgPSAyIHs8QlI+Jm5ic3A7Jm5ic3A7IEF1ZGl0VmFsdWUgPSANCkVwaEEg DQp7PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0V2ZW50cyw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7fTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp9PEJSPiZuYnNw OyZuYnNwOyB9PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PFNQQU4gDQpjbGFzcz0y NDE1MDQyMDgtMDUwNjIwMDM+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L1NQ QU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9MjQxNTA0MjA4 LTA1MDYyMDAzPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48 U1BBTiBjbGFzcz0yNDE1MDQyMDgtMDUwNjIwMDM+QWNjb3JkaW5nIHQgbyB0aGUgQW5uZXggQi4y LCANCnRlcm1pbmF0aW9uQXVkaXQgY2FuIGhhdmUgZXZlbnRzRGVzY3JpcHRvciBvciBhdWRpdEl0 ZW0uPC9TUEFOPjwvRk9OVD48Rk9OVCANCnNpemU9Mj48U1BBTiBjbGFzcz0yNDE1MDQyMDgtMDUw NjIwMDM+PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNz PTI0MTUwNDIwOC0wNTA2MjAwMz5UaGUgZXZlbnRzRGVzY3JpcHRvciBjYW4gYmUgDQplbXB0eShp ZS4gRXZlbnRzVG9rZW4gb25seSkgYW5kIHRoZSBhdWRpdEl0ZW0gY2FuIGhhdmUgRXZlbnRzVG9r ZW4gDQphbHNvLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9MjQxNTA0MjA4LTA1MDYyMDAzPkNvdWxkIGFueW9uZSBn aXZlIG1lJm5ic3A7dGhlIA0KY2xhcmlmaWNhdGlvbiBmb3IgdGhpcz88L1NQQU4+PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9MjQxNTA0MjA4LTA1MDYyMDAzPlRo YW5rcyANCmZvcndhcmQuPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxT UEFOIGNsYXNzPTI0MTUwNDIwOC0wNTA2MjAwMz48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9MjQxNTA0MjA4LTA1MDYyMDAzPkcnRGF5PC9T UEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTI0MTUwNDIw OC0wNTA2MjAwMz48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ PFNQQU4gY2xhc3M9MjQxNTA0MjA4LTA1MDYyMDAzPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz0yNDE1MDQyMDgtMDUwNjIwMDM+PC9TUEFO PjwvRk9OVD48L0ZPTlQ+PEZPTlQgDQpzaXplPTI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPjxGT05UIA0KZmFjZT0iTW9ub3R5cGUg Q29yc2l2YSI+SmF5IEggS2ltPEJSPjwvRk9OVD5SJmFtcDtEIENlbnRlciZuYnNwOyBYRU5FUiBT eXN0ZW1zIA0KSW5jLjxCUj5PZmZpY2U6ICs4Mi0yLTM0ODItNDkwMC4gZXh0LjQxMTxCUj5GYXg6 ICs4Mi0yLTM0ODMtNDkwMjxCUj4rPC9GT05UPjxBIA0KaHJlZj0ibWFpbHRvOmpheWhraW1AeGVu ZXIuY29tIj48Rk9OVCANCnNpemU9Mj5tYWlsdG86amF5aGtpbUB4ZW5lci5jb208L0ZPTlQ+PC9B PjxCUj48Rk9OVCBzaXplPTI+SG9tZXBhZ2U6IA0Kd3d3LnhlbmVyLmNvbTxCUj4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCjwvRk9OVD48 L0RJVj48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_003B_01C32B8C.07C4F530-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jun 5 04:59:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12087 for ; Thu, 5 Jun 2003 04:59:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h558xJo14943 for megaco-archive@odin.ietf.org; Thu, 5 Jun 2003 04:59:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h558xJB14940 for ; Thu, 5 Jun 2003 04:59:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12071 for ; Thu, 5 Jun 2003 04:59:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NqYn-0004MV-00 for megaco-web-archive@ietf.org; Thu, 05 Jun 2003 04:57:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NqYm-0004MR-00 for megaco-web-archive@ietf.org; Thu, 05 Jun 2003 04:57:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h558vbB14867; Thu, 5 Jun 2003 04:57:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h558tJB14784 for ; Thu, 5 Jun 2003 04:55:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11971 for ; Thu, 5 Jun 2003 04:55:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NqUu-0004Lk-00 for megaco@ietf.org; Thu, 05 Jun 2003 04:53:24 -0400 Received: from [211.206.122.239] (helo=mail.mailwave.co.kr) by ietf-mx with smtp (Exim 4.12) id 19NqUp-0004Lf-00 for megaco@ietf.org; Thu, 05 Jun 2003 04:53:19 -0400 Received: from unknown[203.233.7.254] (envelope sender: ) by 211.206.122.239 (TERRACE MAILCENTER) with ESMTP for ; Thu, 05 Jun 2003 17:58:30 KST +0900 From: "Jay H Kim" To: Date: Thu, 5 Jun 2003 17:58:12 +0900 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01C32B8C.07C4F530" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: [Megaco] EventsToken in auditItem of teminationAudit or empty eventsDescriptor Sender: megaco-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_003B_01C32B8C.07C4F530 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 V2hlbiBJIHBhcnNlIHRoZSBtZWdhY28gQXVkaXQgUmVzcG9uc2UgbWVzc2FnZSwgSSBzdGFuZCBh IGNvbmZ1c2luZyB0ZXh0Lg0KIA0KRm9yIGZvbGxvd2luZyBBdWRpdFZhbHVlIFJlc3BvbnNlIG1l c3NhZ2UsDQpEb2VzIHRoZSAiRXZlbnRzIiBpbmRpY2F0ZSBFdmVudHNUb2tlbiBpbiBhdWRpdEl0 ZW0gb3IgZW1wdHkgZXZlbnRzRGVzY3JpcHRvcj8NCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KTUVHQUNPLzEgWzIwOS4xMTAuNTkuMzRdOjI1MDAwDQogICBSZXBseSA9IDEyMzUg ew0KICAgICAgQ29udGV4dCA9IDIgew0KICAgQXVkaXRWYWx1ZSA9IEVwaEEgew0KICAgICAgICAg ICAgIEV2ZW50cywNCiAgICAgICAgICAgICB9DQogICAgICAgfQ0KICAgfQ0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCiANCkFjY29yZGluZyB0IG8gdGhlIEFubmV4IEIuMiwg dGVybWluYXRpb25BdWRpdCBjYW4gaGF2ZSBldmVudHNEZXNjcmlwdG9yIG9yIGF1ZGl0SXRlbS4N ClRoZSBldmVudHNEZXNjcmlwdG9yIGNhbiBiZSBlbXB0eShpZS4gRXZlbnRzVG9rZW4gb25seSkg YW5kIHRoZSBhdWRpdEl0ZW0gY2FuIGhhdmUgRXZlbnRzVG9rZW4gYWxzby4NCg0KQ291bGQgYW55 b25lIGdpdmUgbWUgdGhlIGNsYXJpZmljYXRpb24gZm9yIHRoaXM/DQpUaGFua3MgZm9yd2FyZC4N CiANCkcnRGF5DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpKYXkgSCBLaW0NClImRCBDZW50ZXIgIFhFTkVSIFN5c3RlbXMgSW5j Lg0KT2ZmaWNlOiArODItMi0zNDgyLTQ5MDAuIGV4dC40MTENCkZheDogKzgyLTItMzQ4My00OTAy DQorbWFpbHRvOmpheWhraW1AeGVuZXIuY29tDQpIb21lcGFnZTogd3d3LnhlbmVyLmNvbQ0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQoN Cg== ------=_NextPart_000_003B_01C32B8C.07C4F530 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXVz LWFzY2lpIiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA1 LjAwLjMzMTUuMjg3MCIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWPjxGT05U IGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+DQo8RElWPjxGT05UIHNpemU9Mj48U1BBTiBj bGFzcz0yNDE1MDQyMDgtMDUwNjIwMDM+V2hlbiBJIHBhcnNlIHRoZSBtZWdhY28gQXVkaXQgDQpS ZXNwb25zZSBtZXNzYWdlLCBJIHN0YW5kIGEgY29uZnVzaW5nIHRleHQuPC9TUEFOPjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTI0MTUwNDIwOC0wNTA2MjAwMz48 L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9 MjQxNTA0MjA4LTA1MDYyMDAzPkZvciBmb2xsb3dpbmcgQXVkaXRWYWx1ZSANClJlc3BvbnNlIG1l c3NhZ2UsPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNz PTI0MTUwNDIwOC0wNTA2MjAwMz5Eb2VzJm5ic3A7dGhlICJFdmVudHMiIGluZGljYXRlIA0KRXZl bnRzVG9rZW4gaW4gYXVkaXRJdGVtIG9yIGVtcHR5IGV2ZW50c0Rlc2NyaXB0b3I/PC9TUEFOPjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9MjQxNTA0MjA4LTA1 MDYyMDAzPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvU1BBTj48L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5NRUdBQ08vMSBbMjA5LjExMC41OS4zNF06MjUwMDA8QlI+ Jm5ic3A7Jm5ic3A7IFJlcGx5ID0gMTIzNSANCns8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IENvbnRleHQgPSAyIHs8QlI+Jm5ic3A7Jm5ic3A7IEF1ZGl0VmFsdWUgPSANCkVwaEEg DQp7PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0V2ZW50cyw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7fTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp9PEJSPiZuYnNw OyZuYnNwOyB9PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PFNQQU4gDQpjbGFzcz0y NDE1MDQyMDgtMDUwNjIwMDM+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L1NQ QU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9MjQxNTA0MjA4 LTA1MDYyMDAzPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48 U1BBTiBjbGFzcz0yNDE1MDQyMDgtMDUwNjIwMDM+QWNjb3JkaW5nIHQgbyB0aGUgQW5uZXggQi4y LCANCnRlcm1pbmF0aW9uQXVkaXQgY2FuIGhhdmUgZXZlbnRzRGVzY3JpcHRvciBvciBhdWRpdEl0 ZW0uPC9TUEFOPjwvRk9OVD48Rk9OVCANCnNpemU9Mj48U1BBTiBjbGFzcz0yNDE1MDQyMDgtMDUw NjIwMDM+PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNz PTI0MTUwNDIwOC0wNTA2MjAwMz5UaGUgZXZlbnRzRGVzY3JpcHRvciBjYW4gYmUgDQplbXB0eShp ZS4gRXZlbnRzVG9rZW4gb25seSkgYW5kIHRoZSBhdWRpdEl0ZW0gY2FuIGhhdmUgRXZlbnRzVG9r ZW4gDQphbHNvLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9MjQxNTA0MjA4LTA1MDYyMDAzPkNvdWxkIGFueW9uZSBn aXZlIG1lJm5ic3A7dGhlIA0KY2xhcmlmaWNhdGlvbiBmb3IgdGhpcz88L1NQQU4+PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9MjQxNTA0MjA4LTA1MDYyMDAzPlRo YW5rcyANCmZvcndhcmQuPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxT UEFOIGNsYXNzPTI0MTUwNDIwOC0wNTA2MjAwMz48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9MjQxNTA0MjA4LTA1MDYyMDAzPkcnRGF5PC9T UEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTI0MTUwNDIw OC0wNTA2MjAwMz48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ PFNQQU4gY2xhc3M9MjQxNTA0MjA4LTA1MDYyMDAzPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz0yNDE1MDQyMDgtMDUwNjIwMDM+PC9TUEFO PjwvRk9OVD48L0ZPTlQ+PEZPTlQgDQpzaXplPTI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPjxGT05UIA0KZmFjZT0iTW9ub3R5cGUg Q29yc2l2YSI+SmF5IEggS2ltPEJSPjwvRk9OVD5SJmFtcDtEIENlbnRlciZuYnNwOyBYRU5FUiBT eXN0ZW1zIA0KSW5jLjxCUj5PZmZpY2U6ICs4Mi0yLTM0ODItNDkwMC4gZXh0LjQxMTxCUj5GYXg6 ICs4Mi0yLTM0ODMtNDkwMjxCUj4rPC9GT05UPjxBIA0KaHJlZj0ibWFpbHRvOmpheWhraW1AeGVu ZXIuY29tIj48Rk9OVCANCnNpemU9Mj5tYWlsdG86amF5aGtpbUB4ZW5lci5jb208L0ZPTlQ+PC9B PjxCUj48Rk9OVCBzaXplPTI+SG9tZXBhZ2U6IA0Kd3d3LnhlbmVyLmNvbTxCUj4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCjwvRk9OVD48 L0RJVj48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_003B_01C32B8C.07C4F530-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jun 5 06:44:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14346 for ; Thu, 5 Jun 2003 06:44:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55AgmB22648; Thu, 5 Jun 2003 06:42:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55AfZB22617 for ; Thu, 5 Jun 2003 06:41:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14333 for ; Thu, 5 Jun 2003 06:41:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ns9i-0004pY-00 for megaco@ietf.org; Thu, 05 Jun 2003 06:39:38 -0400 Received: from [203.124.156.98] (helo=chandgate.mahindrabt.com) by ietf-mx with esmtp (Exim 4.12) id 19Ns9e-0004pV-00 for megaco@ietf.org; Thu, 05 Jun 2003 06:39:35 -0400 Received: from thisdomain (mailscan.chand.mahindrabt.com [10.3.0.15]) by chandgate.mahindrabt.com (8.12.9/8.12.9) with ESMTP id h55AfG6d012223 for ; Thu, 5 Jun 2003 16:11:21 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Thu, 05 Jun 2003 16:14:53 +0530 Date: Thu, 05 Jun 2003 16:14:53 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: anilj@mahindrabt.com Received: from dscp00986 ([10.5.13.76]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id QAA01922; Thu, 5 Jun 2003 16:11:12 +0530 Message-ID: <00b101c32b4f$cf2735d0$4c0d050a@mahindrabt.com> From: "Anil Jangam" To: "Jay H Kim" Cc: References: <4D79C746863DD51197690002A52CDA000400E1C3@zcard0kc.ca.nortel.com> Subject: Re: [Megaco] EventsToken in auditItem of teminationAudit or empty eventsDescriptor Date: Thu, 5 Jun 2003 16:17:06 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AE_01C32B7D.E89A5280" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: megaco-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_00AE_01C32B7D.E89A5280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MessageHi Kim, See the answer from Tom in this regard. see below your mail. regds, /anil. ----- Original Message -----=20 From: Jay H Kim=20 To: megaco@ietf.org=20 Sent: Thursday, June 05, 2003 2:38 PM Subject: [Megaco] EventsToken in auditItem of teminationAudit or empty = eventsDescriptor When I parse the megaco Audit Response message, I stand a confusing text. For following AuditValue Response message, Does the "Events" indicate EventsToken in auditItem or empty = eventsDescriptor? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D MEGACO/1 [209.110.59.34]:25000 Reply =3D 1235 { Context =3D 2 { AuditValue =3D EphA { Events, } } } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D According t o the Annex B.2, terminationAudit can have eventsDescriptor = or auditItem. The eventsDescriptor can be empty(ie. EventsToken only) and the = auditItem can have EventsToken also. Could anyone give me the clarification for this? Thanks forward. G'Day ----- Original Message -----=20 From: Tom-PT Taylor=20 To: 'Anil Jangam' ; Kevin Boyle=20 Sent: Wednesday, January 22, 2003 10:40 PM Subject: RE: [Megaco] auditReturnParameter in AmmsReply I suppose as the guy who concocted this syntax I should answer the = question. You return the auditItem. That was my shortcut for returning = descriptor name only. Apparently there is a parsing problem with this syntax, but we never = seem to have taken the step of resolving it. -----Original Message----- From: Anil Jangam [mailto:anilj@mahindrabt.com]=20 Sent: Wednesday, January 22, 2003 12:26 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH] Subject: Fw: [Megaco] auditReturnParameter in AmmsReply Importance: High Hi, What should be the treatment for the case below?? /anil. ----- Original Message -----=20 From: Anil Jangam=20 To: megaco@ietf.org=20 Sent: Monday, January 20, 2003 7:19 PM Subject: [Megaco] auditReturnParameter in AmmsReply hi, as per the AuditReturnParameter (inside ammsReply) definition, it is = mentioned that it may contain the AuditItem. Also it may contain = EventsDescriptor as well. auditReturnParameter =3D (mediaDescriptor / modemDescriptor / muxDescriptor / eventsDescriptor / signalsDescriptor / digitMapDescriptor = / observedEventsDescriptor / = eventBufferDescriptor / statisticsDescriptor / = packagesDescriptor / errorDescriptor / auditItem)=20 ;at-most-once, and DigitMapToken and PackagesToken are not allowed = ;in AuditCapabilities command auditItem =3D ( MuxToken / ModemToken / MediaToken / SignalsToken / EventBufferToken / DigitMapToken / StatsToken / = EventsToken / ObservedEventsToken / PackagesToken ) In above case, if the EventDescriptor is received empty, then how = the corresponding Token should be treated?? Should it be treated as = empty EventDescriptor OR be as AuditItem?? What is the difference = between these two?? P.S.: The EventDescriptor is defined, where except token everything = is optional: eventsDescriptor =3D EventsToken [ EQUAL RequestID LBRKT requestedEvent *( COMMA requestedEvent ) = RBRKT ] ********************************************************* Disclaimer This message (including any attachments) contains=20 confidential information intended for a specific=20 individual and purpose, and is protected by law.=20 If you are not the intended recipient, you should=20 delete this message and are hereby notified that=20 any disclosure, copying, or distribution of this message, or the taking of any action based on it,=20 is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ********************************************************* Disclaimer This message (including any attachments) contains=20 confidential information intended for a specific=20 individual and purpose, and is protected by law.=20 If you are not the intended recipient, you should=20 delete this message and are hereby notified that=20 any disclosure, copying, or distribution of this message, or the taking of any action based on it,=20 is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ------=_NextPart_000_00AE_01C32B7D.E89A5280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi Kim,
 
See the answer from Tom in this regard. = see below=20 your mail.
 
regds,
/anil.
 
 
----- Original Message -----
From: Jay H = Kim
Sent: Thursday, June 05, 2003 = 2:38 PM
Subject: [Megaco] EventsToken in = auditItem=20 of teminationAudit or empty eventsDescriptor

When I parse the = megaco Audit=20 Response message, I stand a confusing text.
 
For following = AuditValue=20 Response message,
Does the = "Events" indicate=20 EventsToken in auditItem or empty eventsDescriptor?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
MEGACO/1 [209.110.59.34]:25000
   Reply = =3D 1235=20 {
      Context =3D 2 {
   = AuditValue =3D=20 EphA=20 {
           &n= bsp; Events,
        &nbs= p;    }
      =20 }
   }
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
According t o the = Annex B.2,=20 terminationAudit can have eventsDescriptor or = auditItem.
The = eventsDescriptor can be=20 empty(ie. EventsToken only) and the auditItem can have EventsToken=20 also.
 
Could anyone give = me the=20 clarification for this?
Thanks=20 forward.
 
G'Day
 
----- Original Message -----
From:=20 Tom-PT Taylor
To: 'Anil Jangam' ; Kevin=20 Boyle
Sent: Wednesday, January 22, = 2003 10:40=20 PM
Subject: RE: [Megaco]=20 auditReturnParameter in AmmsReply

I = suppose as=20 the guy who concocted this syntax I should answer the question.  = You=20 return the auditItem.  That was my shortcut for returning = descriptor name=20 only.
 
Apparently=20 there is a parsing problem with this syntax, but we never seem to have = taken=20 the step of resolving it.
-----Original Message-----
From: = Anil Jangam=20 [mailto:anilj@mahindrabt.com]
Sent: Wednesday, January = 22, 2003=20 12:26 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, = Tom-PT=20 [CAR:5N00:EXCH]
Subject: Fw: [Megaco] auditReturnParameter = in=20 AmmsReply
Importance: High

Hi,
 
What should be the treatment for = the case=20 below??
/anil.
 
----- Original Message -----=20
From: = Anil=20 Jangam
Sent: Monday, January 20, 2003 7:19 PM
Subject: [Megaco] auditReturnParameter in = AmmsReply

hi,
 
as per the = AuditReturnParameter (inside=20 ammsReply) definition, it is mentioned that it may contain = the=20 AuditItem. Also it may contain EventsDescriptor as well.
 
auditReturnParameter =3D = (mediaDescriptor /=20 modemDescriptor=20 = /
           &n= bsp;           &nb= sp;     =20 muxDescriptor / eventsDescriptor=20 = /
           &n= bsp;           &nb= sp;     =20 signalsDescriptor / digitMapDescriptor=20 = /
           &n= bsp;           &nb= sp;     =20 observedEventsDescriptor / eventBufferDescriptor=20 = /
           &n= bsp;           &nb= sp;     =20 statisticsDescriptor / packagesDescriptor=20 = /
           &n= bsp;           &nb= sp;      errorDescriptor=20 / auditItem)
 
 ;at-most-once, and = DigitMapToken and=20 PackagesToken are not allowed ;in AuditCapabilities=20 = command
auditItem         = ;  =20 =3D ( MuxToken / ModemToken / MediaToken=20 = /
           &n= bsp;           &nb= sp;     =20 SignalsToken / EventBufferToken=20 = /
           &n= bsp;           &nb= sp;     =20 DigitMapToken / StatsToken / EventsToken=20 = /
           &n= bsp;           &nb= sp;     =20 ObservedEventsToken / PackagesToken )
 
In above case, if the = EventDescriptor=20 is received empty, then how the corresponding Token should be = treated??=20 Should it be treated as empty EventDescriptor OR be as AuditItem?? = What is=20 the difference between these two??
 
P.S.: The EventDescriptor is = defined, where=20 except token everything is optional:
eventsDescriptor     =3D=20 EventsToken [ EQUAL RequestID=20 = LBRKT
          &nbs= p;            = ;   =20 requestedEvent *( COMMA requestedEvent ) RBRKT=20 = ]

*******************************************************= **
Disclaimer

This=20 message (including any attachments) contains
confidential = information=20 intended for a specific
individual and purpose, and is protected = by law.=20
If you are not the intended recipient, you should
delete = this=20 message and are hereby notified that
any disclosure, copying, = or=20 distribution of this
message, or the taking of any action based = on it,=20
is strictly=20 = prohibited.

******************************************************= ***
Visit=20 us at = http://www.mahindrabt.com

*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

------=_NextPart_000_00AE_01C32B7D.E89A5280-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jun 5 06:45:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14383 for ; Thu, 5 Jun 2003 06:45:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55AiiP22725 for megaco-archive@odin.ietf.org; Thu, 5 Jun 2003 06:44:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55AiiB22722 for ; Thu, 5 Jun 2003 06:44:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14373 for ; Thu, 5 Jun 2003 06:44:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NsCl-0004q7-00 for megaco-web-archive@ietf.org; Thu, 05 Jun 2003 06:42:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NsCk-0004q4-00 for megaco-web-archive@ietf.org; Thu, 05 Jun 2003 06:42:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55AgmB22648; Thu, 5 Jun 2003 06:42:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55AfZB22617 for ; Thu, 5 Jun 2003 06:41:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14333 for ; Thu, 5 Jun 2003 06:41:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ns9i-0004pY-00 for megaco@ietf.org; Thu, 05 Jun 2003 06:39:38 -0400 Received: from [203.124.156.98] (helo=chandgate.mahindrabt.com) by ietf-mx with esmtp (Exim 4.12) id 19Ns9e-0004pV-00 for megaco@ietf.org; Thu, 05 Jun 2003 06:39:35 -0400 Received: from thisdomain (mailscan.chand.mahindrabt.com [10.3.0.15]) by chandgate.mahindrabt.com (8.12.9/8.12.9) with ESMTP id h55AfG6d012223 for ; Thu, 5 Jun 2003 16:11:21 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Thu, 05 Jun 2003 16:14:53 +0530 Date: Thu, 05 Jun 2003 16:14:53 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: anilj@mahindrabt.com Received: from dscp00986 ([10.5.13.76]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id QAA01922; Thu, 5 Jun 2003 16:11:12 +0530 Message-ID: <00b101c32b4f$cf2735d0$4c0d050a@mahindrabt.com> From: "Anil Jangam" To: "Jay H Kim" Cc: References: <4D79C746863DD51197690002A52CDA000400E1C3@zcard0kc.ca.nortel.com> Subject: Re: [Megaco] EventsToken in auditItem of teminationAudit or empty eventsDescriptor Date: Thu, 5 Jun 2003 16:17:06 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AE_01C32B7D.E89A5280" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: megaco-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_00AE_01C32B7D.E89A5280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MessageHi Kim, See the answer from Tom in this regard. see below your mail. regds, /anil. ----- Original Message -----=20 From: Jay H Kim=20 To: megaco@ietf.org=20 Sent: Thursday, June 05, 2003 2:38 PM Subject: [Megaco] EventsToken in auditItem of teminationAudit or empty = eventsDescriptor When I parse the megaco Audit Response message, I stand a confusing text. For following AuditValue Response message, Does the "Events" indicate EventsToken in auditItem or empty = eventsDescriptor? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D MEGACO/1 [209.110.59.34]:25000 Reply =3D 1235 { Context =3D 2 { AuditValue =3D EphA { Events, } } } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D According t o the Annex B.2, terminationAudit can have eventsDescriptor = or auditItem. The eventsDescriptor can be empty(ie. EventsToken only) and the = auditItem can have EventsToken also. Could anyone give me the clarification for this? Thanks forward. G'Day ----- Original Message -----=20 From: Tom-PT Taylor=20 To: 'Anil Jangam' ; Kevin Boyle=20 Sent: Wednesday, January 22, 2003 10:40 PM Subject: RE: [Megaco] auditReturnParameter in AmmsReply I suppose as the guy who concocted this syntax I should answer the = question. You return the auditItem. That was my shortcut for returning = descriptor name only. Apparently there is a parsing problem with this syntax, but we never = seem to have taken the step of resolving it. -----Original Message----- From: Anil Jangam [mailto:anilj@mahindrabt.com]=20 Sent: Wednesday, January 22, 2003 12:26 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH] Subject: Fw: [Megaco] auditReturnParameter in AmmsReply Importance: High Hi, What should be the treatment for the case below?? /anil. ----- Original Message -----=20 From: Anil Jangam=20 To: megaco@ietf.org=20 Sent: Monday, January 20, 2003 7:19 PM Subject: [Megaco] auditReturnParameter in AmmsReply hi, as per the AuditReturnParameter (inside ammsReply) definition, it is = mentioned that it may contain the AuditItem. Also it may contain = EventsDescriptor as well. auditReturnParameter =3D (mediaDescriptor / modemDescriptor / muxDescriptor / eventsDescriptor / signalsDescriptor / digitMapDescriptor = / observedEventsDescriptor / = eventBufferDescriptor / statisticsDescriptor / = packagesDescriptor / errorDescriptor / auditItem)=20 ;at-most-once, and DigitMapToken and PackagesToken are not allowed = ;in AuditCapabilities command auditItem =3D ( MuxToken / ModemToken / MediaToken / SignalsToken / EventBufferToken / DigitMapToken / StatsToken / = EventsToken / ObservedEventsToken / PackagesToken ) In above case, if the EventDescriptor is received empty, then how = the corresponding Token should be treated?? Should it be treated as = empty EventDescriptor OR be as AuditItem?? What is the difference = between these two?? P.S.: The EventDescriptor is defined, where except token everything = is optional: eventsDescriptor =3D EventsToken [ EQUAL RequestID LBRKT requestedEvent *( COMMA requestedEvent ) = RBRKT ] ********************************************************* Disclaimer This message (including any attachments) contains=20 confidential information intended for a specific=20 individual and purpose, and is protected by law.=20 If you are not the intended recipient, you should=20 delete this message and are hereby notified that=20 any disclosure, copying, or distribution of this message, or the taking of any action based on it,=20 is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ********************************************************* Disclaimer This message (including any attachments) contains=20 confidential information intended for a specific=20 individual and purpose, and is protected by law.=20 If you are not the intended recipient, you should=20 delete this message and are hereby notified that=20 any disclosure, copying, or distribution of this message, or the taking of any action based on it,=20 is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ------=_NextPart_000_00AE_01C32B7D.E89A5280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi Kim,
 
See the answer from Tom in this regard. = see below=20 your mail.
 
regds,
/anil.
 
 
----- Original Message -----
From: Jay H = Kim
Sent: Thursday, June 05, 2003 = 2:38 PM
Subject: [Megaco] EventsToken in = auditItem=20 of teminationAudit or empty eventsDescriptor

When I parse the = megaco Audit=20 Response message, I stand a confusing text.
 
For following = AuditValue=20 Response message,
Does the = "Events" indicate=20 EventsToken in auditItem or empty eventsDescriptor?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
MEGACO/1 [209.110.59.34]:25000
   Reply = =3D 1235=20 {
      Context =3D 2 {
   = AuditValue =3D=20 EphA=20 {
           &n= bsp; Events,
        &nbs= p;    }
      =20 }
   }
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
According t o the = Annex B.2,=20 terminationAudit can have eventsDescriptor or = auditItem.
The = eventsDescriptor can be=20 empty(ie. EventsToken only) and the auditItem can have EventsToken=20 also.
 
Could anyone give = me the=20 clarification for this?
Thanks=20 forward.
 
G'Day
 
----- Original Message -----
From:=20 Tom-PT Taylor
To: 'Anil Jangam' ; Kevin=20 Boyle
Sent: Wednesday, January 22, = 2003 10:40=20 PM
Subject: RE: [Megaco]=20 auditReturnParameter in AmmsReply

I = suppose as=20 the guy who concocted this syntax I should answer the question.  = You=20 return the auditItem.  That was my shortcut for returning = descriptor name=20 only.
 
Apparently=20 there is a parsing problem with this syntax, but we never seem to have = taken=20 the step of resolving it.
-----Original Message-----
From: = Anil Jangam=20 [mailto:anilj@mahindrabt.com]
Sent: Wednesday, January = 22, 2003=20 12:26 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, = Tom-PT=20 [CAR:5N00:EXCH]
Subject: Fw: [Megaco] auditReturnParameter = in=20 AmmsReply
Importance: High

Hi,
 
What should be the treatment for = the case=20 below??
/anil.
 
----- Original Message -----=20
From: = Anil=20 Jangam
Sent: Monday, January 20, 2003 7:19 PM
Subject: [Megaco] auditReturnParameter in = AmmsReply

hi,
 
as per the = AuditReturnParameter (inside=20 ammsReply) definition, it is mentioned that it may contain = the=20 AuditItem. Also it may contain EventsDescriptor as well.
 
auditReturnParameter =3D = (mediaDescriptor /=20 modemDescriptor=20 = /
           &n= bsp;           &nb= sp;     =20 muxDescriptor / eventsDescriptor=20 = /
           &n= bsp;           &nb= sp;     =20 signalsDescriptor / digitMapDescriptor=20 = /
           &n= bsp;           &nb= sp;     =20 observedEventsDescriptor / eventBufferDescriptor=20 = /
           &n= bsp;           &nb= sp;     =20 statisticsDescriptor / packagesDescriptor=20 = /
           &n= bsp;           &nb= sp;      errorDescriptor=20 / auditItem)
 
 ;at-most-once, and = DigitMapToken and=20 PackagesToken are not allowed ;in AuditCapabilities=20 = command
auditItem         = ;  =20 =3D ( MuxToken / ModemToken / MediaToken=20 = /
           &n= bsp;           &nb= sp;     =20 SignalsToken / EventBufferToken=20 = /
           &n= bsp;           &nb= sp;     =20 DigitMapToken / StatsToken / EventsToken=20 = /
           &n= bsp;           &nb= sp;     =20 ObservedEventsToken / PackagesToken )
 
In above case, if the = EventDescriptor=20 is received empty, then how the corresponding Token should be = treated??=20 Should it be treated as empty EventDescriptor OR be as AuditItem?? = What is=20 the difference between these two??
 
P.S.: The EventDescriptor is = defined, where=20 except token everything is optional:
eventsDescriptor     =3D=20 EventsToken [ EQUAL RequestID=20 = LBRKT
          &nbs= p;            = ;   =20 requestedEvent *( COMMA requestedEvent ) RBRKT=20 = ]

*******************************************************= **
Disclaimer

This=20 message (including any attachments) contains
confidential = information=20 intended for a specific
individual and purpose, and is protected = by law.=20
If you are not the intended recipient, you should
delete = this=20 message and are hereby notified that
any disclosure, copying, = or=20 distribution of this
message, or the taking of any action based = on it,=20
is strictly=20 = prohibited.

******************************************************= ***
Visit=20 us at = http://www.mahindrabt.com

*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

------=_NextPart_000_00AE_01C32B7D.E89A5280-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jun 5 11:10:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00721 for ; Thu, 5 Jun 2003 11:10:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55F8nB12663; Thu, 5 Jun 2003 11:08:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55F5iB11632 for ; Thu, 5 Jun 2003 11:05:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29931 for ; Thu, 5 Jun 2003 11:05:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NwHK-0007jI-00 for megaco@ietf.org; Thu, 05 Jun 2003 11:03:46 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19NwHJ-0007hJ-00 for megaco@ietf.org; Thu, 05 Jun 2003 11:03:45 -0400 Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h55F53t16753 for ; Thu, 5 Jun 2003 10:05:04 -0500 (CDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA21435; Thu, 5 Jun 2003 11:05:02 -0400 (EDT) Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA21430; Thu, 5 Jun 2003 11:05:02 -0400 (EDT) Message-ID: <3EDF5C17.4080205@bell-labs.com> Date: Thu, 05 Jun 2003 11:04:55 -0400 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco@ietf.org Subject: Re: [Megaco] EventsToken in auditItem of teminationAudit or empty eventsDescriptor References: <4D79C746863DD51197690002A52CDA000400E1C3@zcard0kc.ca.nortel.com> <00b101c32b4f$cf2735d0$4c0d050a@mahindrabt.com> In-Reply-To: <00b101c32b4f$cf2735d0$4c0d050a@mahindrabt.com> Content-Type: multipart/mixed; boundary="------------000606000500050804070707" Sender: megaco-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. --------------000606000500050804070707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jay H Kim wrote: > According t o the Annex B.2, terminationAudit can have eventsDescriptor or auditItem. > The eventsDescriptor can be empty(ie. EventsToken only) and the auditItem can have EventsToken also. > The same is/was true of EventBufferToken, as well. Tom-PT Taylor wrote: > > Apparently there is a parsing problem with this syntax, but we never seem to have taken the step of resolving it. This was discussed in June of 2001 in the thread 'IG 6.79 "Cancelling Event Detection" breaks ABNF'. This parsing problem was the start of the thread, but other parsing problems were discussed as well. Apparently folks thought the needed changes were to radical to fix at the time. I am attaching the last post to the thread, my proposed fixes. It got no responses at the time. I am not current enough with H.248 to know if the other 3 problems are still problems. -troy --------------000606000500050804070707 Content-Type: message/rfc822; name="Attached Message" Content-Disposition: inline; filename="Attached Message" Message-ID: <3BC3287B.D2E6E4E4@lucent.com> Date: Tue, 09 Oct 2001 12:40:27 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" , Tom-PT Taylor , "'tla@lucent.com'" , MEGACO list Subject: Re: IG 6.79 "Cancelling Event Detection" breaks ABNF References: <4FBEA8857476D311A03300204840E1CF0446551E@whq-msgusr-02.pit.comms.marconi.com> <3B20ECFC.A8C1F9BC@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greetings, This old thread had some fairly serious problems that were never resolved. I am proposing changes for the problems in the text encoding. There is a larger issue to the ASN.1 problems -- I will start another thread for that. BACKGROUND I'm told that auditItem's use in auditReturnParameter is to represent empty descriptors. auditReturnParameter = (mediaDescriptor / modemDescriptor / muxDescriptor / eventsDescriptor / signalsDescriptor / digitMapDescriptor / observedEventsDescriptor / eventBufferDescriptor / statisticsDescriptor / packagesDescriptor / errorDescriptor / auditItem ) auditItem = ( MuxToken / ModemToken / MediaToken / SignalsToken / EventBufferToken / DigitMapToken / StatsToken / EventsToken / ObservedEventsToken / PackagesToken ) But some of the descriptors in auditReturnParameter already have empty forms. This is the crux of problems #1, #2 (text) and #4 below. PROPOSED CHANGES that fix #1, #2 (text) and #4 below signalsDescriptor = SignalsToken [ LBRKT signalParm *(COMMA signalParm) RBRKT ] auditReturnParameter = (mediaDescriptor / modemDescriptor / muxDescriptor / eventsDescriptor / signalsDescriptor / digitMapDescriptor / observedEventsDescriptor / eventBufferDescriptor / statisticsDescriptor / packagesDescriptor / errorDescriptor / auditReturnItem ) auditReturnItem = ( MuxToken / ModemToken / MediaToken / DigitMapToken / StatsToken / ObservedEventsToken / PackagesToken ) auditItem = ( auditReturnItem / SignalsToken / EventBufferToken / EventsToken ) An alternative approach would be to create empty forms for the other 7 descriptors represented by auditItem and remove the auditItem from auditReturnParameter. But then those empty forms could be used elsewhere (ammParameter, notifyRequest) where they're apparantly not needed. -troy Troy Cauble wrote: > > A summary of the problems discussed in this thread. > > 1) In the text encoding, some empty descriptors have the form > "Signals {}" while others have "Events". > > In a Termination Audit: > > 2) There are two line encodings for an empty Signals descriptor > (text and ASN.1). > > 3) There are two line encodings each for an empty Events descriptor > or Event Buffer descriptor (ASN.1 only). > > 4) In the text encoding, EventsToken and EventBufferToken each > have reduce/reduce conflicts because they can represent either > an auditItem token or an empty descriptor in the auditReturnParameter. > > -troy > > > > "Rosen, Brian" wrote: > > > > I agree with Tom; we did a pass over the ABNF to try to make > > all of the empty forms not have braces. The choice was > > completely arbitrary, and as I recall, we decided since it > > didn't make any real difference, shorter was better. > > If we missed one, we goofed. > > > > Tom, the problem here seems to be real. As Troy says, you will get > > a reduce conflict in a rules-based parser with this ambiguity. > > I'm pretty sure you can ignore the problem, but it's poor design > > practice. You will recall all of the effort Abdallah and Nancy > > went through to test out these kinds of things as we developed > > the ABNF. The IG change wasn't verified in the same way, thus > > we have this problem. We need to decide what to do. > > > > Brian > > > > > > Tom-PT Taylor wrote: > > > > > > > > I'm the one responsible for all this. I suppose I should > > > dig up the thread. > > > > Anyway, the intention was definitiely to provide a way of > > > signalling empty > > > > descriptors. I think we chose rather arbitrarily between > > > the desc{} and desc > > > > form, opting for the latter. > > > --------------000606000500050804070707-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jun 5 11:11:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00788 for ; Thu, 5 Jun 2003 11:11:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55FArZ12915 for megaco-archive@odin.ietf.org; Thu, 5 Jun 2003 11:10:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FArB12912 for ; Thu, 5 Jun 2003 11:10:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00762 for ; Thu, 5 Jun 2003 11:10:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NwMJ-000044-00 for megaco-web-archive@ietf.org; Thu, 05 Jun 2003 11:08:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NwMJ-000041-00 for megaco-web-archive@ietf.org; Thu, 05 Jun 2003 11:08:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55F8nB12663; Thu, 5 Jun 2003 11:08:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55F5iB11632 for ; Thu, 5 Jun 2003 11:05:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29931 for ; Thu, 5 Jun 2003 11:05:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NwHK-0007jI-00 for megaco@ietf.org; Thu, 05 Jun 2003 11:03:46 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19NwHJ-0007hJ-00 for megaco@ietf.org; Thu, 05 Jun 2003 11:03:45 -0400 Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h55F53t16753 for ; Thu, 5 Jun 2003 10:05:04 -0500 (CDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA21435; Thu, 5 Jun 2003 11:05:02 -0400 (EDT) Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA21430; Thu, 5 Jun 2003 11:05:02 -0400 (EDT) Message-ID: <3EDF5C17.4080205@bell-labs.com> Date: Thu, 05 Jun 2003 11:04:55 -0400 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco@ietf.org Subject: Re: [Megaco] EventsToken in auditItem of teminationAudit or empty eventsDescriptor References: <4D79C746863DD51197690002A52CDA000400E1C3@zcard0kc.ca.nortel.com> <00b101c32b4f$cf2735d0$4c0d050a@mahindrabt.com> In-Reply-To: <00b101c32b4f$cf2735d0$4c0d050a@mahindrabt.com> Content-Type: multipart/mixed; boundary="------------000606000500050804070707" Sender: megaco-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. --------------000606000500050804070707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jay H Kim wrote: > According t o the Annex B.2, terminationAudit can have eventsDescriptor or auditItem. > The eventsDescriptor can be empty(ie. EventsToken only) and the auditItem can have EventsToken also. > The same is/was true of EventBufferToken, as well. Tom-PT Taylor wrote: > > Apparently there is a parsing problem with this syntax, but we never seem to have taken the step of resolving it. This was discussed in June of 2001 in the thread 'IG 6.79 "Cancelling Event Detection" breaks ABNF'. This parsing problem was the start of the thread, but other parsing problems were discussed as well. Apparently folks thought the needed changes were to radical to fix at the time. I am attaching the last post to the thread, my proposed fixes. It got no responses at the time. I am not current enough with H.248 to know if the other 3 problems are still problems. -troy --------------000606000500050804070707 Content-Type: message/rfc822; name="Attached Message" Content-Disposition: inline; filename="Attached Message" Message-ID: <3BC3287B.D2E6E4E4@lucent.com> Date: Tue, 09 Oct 2001 12:40:27 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" , Tom-PT Taylor , "'tla@lucent.com'" , MEGACO list Subject: Re: IG 6.79 "Cancelling Event Detection" breaks ABNF References: <4FBEA8857476D311A03300204840E1CF0446551E@whq-msgusr-02.pit.comms.marconi.com> <3B20ECFC.A8C1F9BC@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greetings, This old thread had some fairly serious problems that were never resolved. I am proposing changes for the problems in the text encoding. There is a larger issue to the ASN.1 problems -- I will start another thread for that. BACKGROUND I'm told that auditItem's use in auditReturnParameter is to represent empty descriptors. auditReturnParameter = (mediaDescriptor / modemDescriptor / muxDescriptor / eventsDescriptor / signalsDescriptor / digitMapDescriptor / observedEventsDescriptor / eventBufferDescriptor / statisticsDescriptor / packagesDescriptor / errorDescriptor / auditItem ) auditItem = ( MuxToken / ModemToken / MediaToken / SignalsToken / EventBufferToken / DigitMapToken / StatsToken / EventsToken / ObservedEventsToken / PackagesToken ) But some of the descriptors in auditReturnParameter already have empty forms. This is the crux of problems #1, #2 (text) and #4 below. PROPOSED CHANGES that fix #1, #2 (text) and #4 below signalsDescriptor = SignalsToken [ LBRKT signalParm *(COMMA signalParm) RBRKT ] auditReturnParameter = (mediaDescriptor / modemDescriptor / muxDescriptor / eventsDescriptor / signalsDescriptor / digitMapDescriptor / observedEventsDescriptor / eventBufferDescriptor / statisticsDescriptor / packagesDescriptor / errorDescriptor / auditReturnItem ) auditReturnItem = ( MuxToken / ModemToken / MediaToken / DigitMapToken / StatsToken / ObservedEventsToken / PackagesToken ) auditItem = ( auditReturnItem / SignalsToken / EventBufferToken / EventsToken ) An alternative approach would be to create empty forms for the other 7 descriptors represented by auditItem and remove the auditItem from auditReturnParameter. But then those empty forms could be used elsewhere (ammParameter, notifyRequest) where they're apparantly not needed. -troy Troy Cauble wrote: > > A summary of the problems discussed in this thread. > > 1) In the text encoding, some empty descriptors have the form > "Signals {}" while others have "Events". > > In a Termination Audit: > > 2) There are two line encodings for an empty Signals descriptor > (text and ASN.1). > > 3) There are two line encodings each for an empty Events descriptor > or Event Buffer descriptor (ASN.1 only). > > 4) In the text encoding, EventsToken and EventBufferToken each > have reduce/reduce conflicts because they can represent either > an auditItem token or an empty descriptor in the auditReturnParameter. > > -troy > > > > "Rosen, Brian" wrote: > > > > I agree with Tom; we did a pass over the ABNF to try to make > > all of the empty forms not have braces. The choice was > > completely arbitrary, and as I recall, we decided since it > > didn't make any real difference, shorter was better. > > If we missed one, we goofed. > > > > Tom, the problem here seems to be real. As Troy says, you will get > > a reduce conflict in a rules-based parser with this ambiguity. > > I'm pretty sure you can ignore the problem, but it's poor design > > practice. You will recall all of the effort Abdallah and Nancy > > went through to test out these kinds of things as we developed > > the ABNF. The IG change wasn't verified in the same way, thus > > we have this problem. We need to decide what to do. > > > > Brian > > > > > > Tom-PT Taylor wrote: > > > > > > > > I'm the one responsible for all this. I suppose I should > > > dig up the thread. > > > > Anyway, the intention was definitiely to provide a way of > > > signalling empty > > > > descriptors. I think we chose rather arbitrarily between > > > the desc{} and desc > > > > form, opting for the latter. > > > --------------000606000500050804070707-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jun 5 12:43:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05838 for ; Thu, 5 Jun 2003 12:43:30 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GdxB20580; Thu, 5 Jun 2003 12:39:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GcTB20510 for ; Thu, 5 Jun 2003 12:38:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05688 for ; Thu, 5 Jun 2003 12:38:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nxj8-0000vl-00 for megaco@ietf.org; Thu, 05 Jun 2003 12:36:34 -0400 Received: from gw-4.winphoria.com ([12.105.64.137] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19Nxj7-0000vb-00 for megaco@ietf.org; Thu, 05 Jun 2003 12:36:33 -0400 Received: from smilevm.winphoria.com ([10.14.25.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 5 Jun 2003 12:37:54 -0400 Message-Id: <5.2.1.1.0.20030605123319.029ede30@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 05 Jun 2003 12:36:31 -0400 To: Troy Cauble , "Jay H Kim" , "Anil Jangam" , megaco@ietf.org From: Aleksandr Ryabin Subject: Re: [Megaco] EventsToken in auditItem of teminationAudit or empty eventsDescriptor In-Reply-To: <3EDF5C17.4080205@bell-labs.com> References: <00b101c32b4f$cf2735d0$4c0d050a@mahindrabt.com> <4D79C746863DD51197690002A52CDA000400E1C3@zcard0kc.ca.nortel.com> <00b101c32b4f$cf2735d0$4c0d050a@mahindrabt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 05 Jun 2003 16:37:55.0068 (UTC) FILETIME=[D084D3C0:01C32B80] Sender: megaco-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: , See "6.3 Empty Descriptor Syntax" in IG. http://standard.pictel.com/ftp/avc-site/0305_Gen/H.248_IG.zip Aleks At 11:04 AM 6/5/2003, Troy Cauble wrote: >Jay H Kim wrote: > > > According t o the Annex B.2, terminationAudit can have eventsDescriptor > or auditItem. > > The eventsDescriptor can be empty(ie. EventsToken only) and the > auditItem can have EventsToken also. > > > >The same is/was true of EventBufferToken, as well. > > >Tom-PT Taylor wrote: > >> Apparently there is a parsing problem with this syntax, but we never >> seem to have taken the step of resolving it. > > >This was discussed in June of 2001 in the thread >'IG 6.79 "Cancelling Event Detection" breaks ABNF'. > >This parsing problem was the start of the thread, but other >parsing problems were discussed as well. > >Apparently folks thought the needed changes were to radical >to fix at the time. > >I am attaching the last post to the thread, my proposed fixes. >It got no responses at the time. > >I am not current enough with H.248 to know if the other 3 >problems are still problems. > >-troy > > > > > > >Message-ID: <3BC3287B.D2E6E4E4@lucent.com> >Date: Tue, 09 Oct 2001 12:40:27 -0400 >From: Troy Cauble >Reply-To: Troy Cauble >X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) >X-Accept-Language: en >MIME-Version: 1.0 >To: "Rosen, Brian" , > Tom-PT Taylor , > "'tla@lucent.com'" , MEGACO list >Subject: Re: IG 6.79 "Cancelling Event Detection" breaks ABNF >References: ><4FBEA8857476D311A03300204840E1CF0446551E@whq-msgusr-02.pit.comms.marconi.com> ><3B20ECFC.A8C1F9BC@lucent.com> >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > > >Greetings, > >This old thread had some fairly serious problems that were never >resolved. I am proposing changes for the problems in the text >encoding. There is a larger issue to the ASN.1 problems -- I >will start another thread for that. > > >BACKGROUND > >I'm told that auditItem's use in auditReturnParameter is to >represent empty descriptors. > > auditReturnParameter = (mediaDescriptor / modemDescriptor / > muxDescriptor / eventsDescriptor / > signalsDescriptor / digitMapDescriptor / > observedEventsDescriptor / eventBufferDescriptor / > statisticsDescriptor / packagesDescriptor / > errorDescriptor / auditItem ) > > auditItem = ( MuxToken / ModemToken / MediaToken / > SignalsToken / EventBufferToken / > DigitMapToken / StatsToken / EventsToken / > ObservedEventsToken / PackagesToken ) > >But some of the descriptors in auditReturnParameter already have >empty forms. This is the crux of problems #1, #2 (text) and #4 below. > > >PROPOSED CHANGES that fix #1, #2 (text) and #4 below > > signalsDescriptor = SignalsToken [ LBRKT signalParm > *(COMMA signalParm) RBRKT ] > > auditReturnParameter = (mediaDescriptor / modemDescriptor / > muxDescriptor / eventsDescriptor / > signalsDescriptor / digitMapDescriptor / > observedEventsDescriptor / eventBufferDescriptor / > statisticsDescriptor / packagesDescriptor / > errorDescriptor / auditReturnItem ) > > auditReturnItem = ( MuxToken / ModemToken / MediaToken / > DigitMapToken / StatsToken / > ObservedEventsToken / PackagesToken ) > > auditItem = ( auditReturnItem / SignalsToken / > EventBufferToken / EventsToken ) > > >An alternative approach would be to create empty forms for >the other 7 descriptors represented by auditItem and remove >the auditItem from auditReturnParameter. But then those >empty forms could be used elsewhere (ammParameter, notifyRequest) >where they're apparantly not needed. > >-troy > > > >Troy Cauble wrote: > > > > A summary of the problems discussed in this thread. > > > > 1) In the text encoding, some empty descriptors have the form > > "Signals {}" while others have "Events". > > > > In a Termination Audit: > > > > 2) There are two line encodings for an empty Signals descriptor > > (text and ASN.1). > > > > 3) There are two line encodings each for an empty Events descriptor > > or Event Buffer descriptor (ASN.1 only). > > > > 4) In the text encoding, EventsToken and EventBufferToken each > > have reduce/reduce conflicts because they can represent either > > an auditItem token or an empty descriptor in the auditReturnParameter. > > > > -troy > > > > > > > > "Rosen, Brian" wrote: > > > > > > I agree with Tom; we did a pass over the ABNF to try to make > > > all of the empty forms not have braces. The choice was > > > completely arbitrary, and as I recall, we decided since it > > > didn't make any real difference, shorter was better. > > > If we missed one, we goofed. > > > > > > Tom, the problem here seems to be real. As Troy says, you will get > > > a reduce conflict in a rules-based parser with this ambiguity. > > > I'm pretty sure you can ignore the problem, but it's poor design > > > practice. You will recall all of the effort Abdallah and Nancy > > > went through to test out these kinds of things as we developed > > > the ABNF. The IG change wasn't verified in the same way, thus > > > we have this problem. We need to decide what to do. > > > > > > Brian > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > I'm the one responsible for all this. I suppose I should > > > > dig up the thread. > > > > > Anyway, the intention was definitiely to provide a way of > > > > signalling empty > > > > > descriptors. I think we chose rather arbitrarily between > > > > the desc{} and desc > > > > > form, opting for the latter. > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jun 5 12:44:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05863 for ; Thu, 5 Jun 2003 12:44:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55GiFM20786 for megaco-archive@odin.ietf.org; Thu, 5 Jun 2003 12:44:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GiFB20783 for ; Thu, 5 Jun 2003 12:44:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05855 for ; Thu, 5 Jun 2003 12:44:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nxoi-0000yw-00 for megaco-web-archive@ietf.org; Thu, 05 Jun 2003 12:42:20 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Nxoh-0000yt-00 for megaco-web-archive@ietf.org; Thu, 05 Jun 2003 12:42:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GdxB20580; Thu, 5 Jun 2003 12:39:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GcTB20510 for ; Thu, 5 Jun 2003 12:38:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05688 for ; Thu, 5 Jun 2003 12:38:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nxj8-0000vl-00 for megaco@ietf.org; Thu, 05 Jun 2003 12:36:34 -0400 Received: from gw-4.winphoria.com ([12.105.64.137] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19Nxj7-0000vb-00 for megaco@ietf.org; Thu, 05 Jun 2003 12:36:33 -0400 Received: from smilevm.winphoria.com ([10.14.25.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 5 Jun 2003 12:37:54 -0400 Message-Id: <5.2.1.1.0.20030605123319.029ede30@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 05 Jun 2003 12:36:31 -0400 To: Troy Cauble , "Jay H Kim" , "Anil Jangam" , megaco@ietf.org From: Aleksandr Ryabin Subject: Re: [Megaco] EventsToken in auditItem of teminationAudit or empty eventsDescriptor In-Reply-To: <3EDF5C17.4080205@bell-labs.com> References: <00b101c32b4f$cf2735d0$4c0d050a@mahindrabt.com> <4D79C746863DD51197690002A52CDA000400E1C3@zcard0kc.ca.nortel.com> <00b101c32b4f$cf2735d0$4c0d050a@mahindrabt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 05 Jun 2003 16:37:55.0068 (UTC) FILETIME=[D084D3C0:01C32B80] Sender: megaco-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: , See "6.3 Empty Descriptor Syntax" in IG. http://standard.pictel.com/ftp/avc-site/0305_Gen/H.248_IG.zip Aleks At 11:04 AM 6/5/2003, Troy Cauble wrote: >Jay H Kim wrote: > > > According t o the Annex B.2, terminationAudit can have eventsDescriptor > or auditItem. > > The eventsDescriptor can be empty(ie. EventsToken only) and the > auditItem can have EventsToken also. > > > >The same is/was true of EventBufferToken, as well. > > >Tom-PT Taylor wrote: > >> Apparently there is a parsing problem with this syntax, but we never >> seem to have taken the step of resolving it. > > >This was discussed in June of 2001 in the thread >'IG 6.79 "Cancelling Event Detection" breaks ABNF'. > >This parsing problem was the start of the thread, but other >parsing problems were discussed as well. > >Apparently folks thought the needed changes were to radical >to fix at the time. > >I am attaching the last post to the thread, my proposed fixes. >It got no responses at the time. > >I am not current enough with H.248 to know if the other 3 >problems are still problems. > >-troy > > > > > > >Message-ID: <3BC3287B.D2E6E4E4@lucent.com> >Date: Tue, 09 Oct 2001 12:40:27 -0400 >From: Troy Cauble >Reply-To: Troy Cauble >X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) >X-Accept-Language: en >MIME-Version: 1.0 >To: "Rosen, Brian" , > Tom-PT Taylor , > "'tla@lucent.com'" , MEGACO list >Subject: Re: IG 6.79 "Cancelling Event Detection" breaks ABNF >References: ><4FBEA8857476D311A03300204840E1CF0446551E@whq-msgusr-02.pit.comms.marconi.com> ><3B20ECFC.A8C1F9BC@lucent.com> >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > > >Greetings, > >This old thread had some fairly serious problems that were never >resolved. I am proposing changes for the problems in the text >encoding. There is a larger issue to the ASN.1 problems -- I >will start another thread for that. > > >BACKGROUND > >I'm told that auditItem's use in auditReturnParameter is to >represent empty descriptors. > > auditReturnParameter = (mediaDescriptor / modemDescriptor / > muxDescriptor / eventsDescriptor / > signalsDescriptor / digitMapDescriptor / > observedEventsDescriptor / eventBufferDescriptor / > statisticsDescriptor / packagesDescriptor / > errorDescriptor / auditItem ) > > auditItem = ( MuxToken / ModemToken / MediaToken / > SignalsToken / EventBufferToken / > DigitMapToken / StatsToken / EventsToken / > ObservedEventsToken / PackagesToken ) > >But some of the descriptors in auditReturnParameter already have >empty forms. This is the crux of problems #1, #2 (text) and #4 below. > > >PROPOSED CHANGES that fix #1, #2 (text) and #4 below > > signalsDescriptor = SignalsToken [ LBRKT signalParm > *(COMMA signalParm) RBRKT ] > > auditReturnParameter = (mediaDescriptor / modemDescriptor / > muxDescriptor / eventsDescriptor / > signalsDescriptor / digitMapDescriptor / > observedEventsDescriptor / eventBufferDescriptor / > statisticsDescriptor / packagesDescriptor / > errorDescriptor / auditReturnItem ) > > auditReturnItem = ( MuxToken / ModemToken / MediaToken / > DigitMapToken / StatsToken / > ObservedEventsToken / PackagesToken ) > > auditItem = ( auditReturnItem / SignalsToken / > EventBufferToken / EventsToken ) > > >An alternative approach would be to create empty forms for >the other 7 descriptors represented by auditItem and remove >the auditItem from auditReturnParameter. But then those >empty forms could be used elsewhere (ammParameter, notifyRequest) >where they're apparantly not needed. > >-troy > > > >Troy Cauble wrote: > > > > A summary of the problems discussed in this thread. > > > > 1) In the text encoding, some empty descriptors have the form > > "Signals {}" while others have "Events". > > > > In a Termination Audit: > > > > 2) There are two line encodings for an empty Signals descriptor > > (text and ASN.1). > > > > 3) There are two line encodings each for an empty Events descriptor > > or Event Buffer descriptor (ASN.1 only). > > > > 4) In the text encoding, EventsToken and EventBufferToken each > > have reduce/reduce conflicts because they can represent either > > an auditItem token or an empty descriptor in the auditReturnParameter. > > > > -troy > > > > > > > > "Rosen, Brian" wrote: > > > > > > I agree with Tom; we did a pass over the ABNF to try to make > > > all of the empty forms not have braces. The choice was > > > completely arbitrary, and as I recall, we decided since it > > > didn't make any real difference, shorter was better. > > > If we missed one, we goofed. > > > > > > Tom, the problem here seems to be real. As Troy says, you will get > > > a reduce conflict in a rules-based parser with this ambiguity. > > > I'm pretty sure you can ignore the problem, but it's poor design > > > practice. You will recall all of the effort Abdallah and Nancy > > > went through to test out these kinds of things as we developed > > > the ABNF. The IG change wasn't verified in the same way, thus > > > we have this problem. We need to decide what to do. > > > > > > Brian > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > I'm the one responsible for all this. I suppose I should > > > > dig up the thread. > > > > > Anyway, the intention was definitiely to provide a way of > > > > signalling empty > > > > > descriptors. I think we chose rather arbitrarily between > > > > the desc{} and desc > > > > > form, opting for the latter. > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jun 5 14:27:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09819 for ; Thu, 5 Jun 2003 14:27:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55IQgB28862; Thu, 5 Jun 2003 14:26:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55IOcB28715 for ; Thu, 5 Jun 2003 14:24:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09607 for ; Thu, 5 Jun 2003 14:24:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NzNo-0001un-00 for megaco@ietf.org; Thu, 05 Jun 2003 14:22:40 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19NzNo-0001uf-00 for megaco@ietf.org; Thu, 05 Jun 2003 14:22:40 -0400 Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h55INwk16109 for ; Thu, 5 Jun 2003 13:23:58 -0500 (CDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA23193; Thu, 5 Jun 2003 14:23:57 -0400 (EDT) Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA23189; Thu, 5 Jun 2003 14:23:57 -0400 (EDT) Message-ID: <3EDF8ABD.9010409@bell-labs.com> Date: Thu, 05 Jun 2003 14:23:57 -0400 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco@ietf.org Subject: Re: [Megaco] EventsToken in auditItem of teminationAudit or empty eventsDescriptor References: <00b101c32b4f$cf2735d0$4c0d050a@mahindrabt.com> <4D79C746863DD51197690002A52CDA000400E1C3@zcard0kc.ca.nortel.com> <00b101c32b4f$cf2735d0$4c0d050a@mahindrabt.com> <5.2.1.1.0.20030605123319.029ede30@imap.winphoria.com> In-Reply-To: <5.2.1.1.0.20030605123319.029ede30@imap.winphoria.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Aleksandr Ryabin wrote: > See "6.3 Empty Descriptor Syntax" in IG. > http://standard.pictel.com/ftp/avc-site/0305_Gen/H.248_IG.zip > Aleks > Hah! I had forgotten! I haven't been focused on H.248 lately. Nitpick: The title for that section of the IG says it's for "v1". This might mislead people. Thanks, -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jun 5 14:29:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09932 for ; Thu, 5 Jun 2003 14:29:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55ISgZ29025 for megaco-archive@odin.ietf.org; Thu, 5 Jun 2003 14:28:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55ISgB29020 for ; Thu, 5 Jun 2003 14:28:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09887 for ; Thu, 5 Jun 2003 14:28:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NzRl-00020G-00 for megaco-web-archive@ietf.org; Thu, 05 Jun 2003 14:26:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NzRk-00020D-00 for megaco-web-archive@ietf.org; Thu, 05 Jun 2003 14:26:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55IQgB28862; Thu, 5 Jun 2003 14:26:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55IOcB28715 for ; Thu, 5 Jun 2003 14:24:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09607 for ; Thu, 5 Jun 2003 14:24:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NzNo-0001un-00 for megaco@ietf.org; Thu, 05 Jun 2003 14:22:40 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19NzNo-0001uf-00 for megaco@ietf.org; Thu, 05 Jun 2003 14:22:40 -0400 Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h55INwk16109 for ; Thu, 5 Jun 2003 13:23:58 -0500 (CDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA23193; Thu, 5 Jun 2003 14:23:57 -0400 (EDT) Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA23189; Thu, 5 Jun 2003 14:23:57 -0400 (EDT) Message-ID: <3EDF8ABD.9010409@bell-labs.com> Date: Thu, 05 Jun 2003 14:23:57 -0400 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco@ietf.org Subject: Re: [Megaco] EventsToken in auditItem of teminationAudit or empty eventsDescriptor References: <00b101c32b4f$cf2735d0$4c0d050a@mahindrabt.com> <4D79C746863DD51197690002A52CDA000400E1C3@zcard0kc.ca.nortel.com> <00b101c32b4f$cf2735d0$4c0d050a@mahindrabt.com> <5.2.1.1.0.20030605123319.029ede30@imap.winphoria.com> In-Reply-To: <5.2.1.1.0.20030605123319.029ede30@imap.winphoria.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Aleksandr Ryabin wrote: > See "6.3 Empty Descriptor Syntax" in IG. > http://standard.pictel.com/ftp/avc-site/0305_Gen/H.248_IG.zip > Aleks > Hah! I had forgotten! I haven't been focused on H.248 lately. Nitpick: The title for that section of the IG says it's for "v1". This might mislead people. Thanks, -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jun 5 22:10:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25340 for ; Thu, 5 Jun 2003 22:10:39 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5629IB31833; Thu, 5 Jun 2003 22:09:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5627CB31070 for ; Thu, 5 Jun 2003 22:07:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25261 for ; Thu, 5 Jun 2003 22:07:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O6bT-0005N9-00 for megaco@ietf.org; Thu, 05 Jun 2003 22:05:15 -0400 Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx with esmtp (Exim 4.12) id 19O6bR-0005N4-00 for megaco@ietf.org; Thu, 05 Jun 2003 22:05:14 -0400 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.2+Sun/8.12.3) with SMTP id h561tSRK009131 for ; Fri, 6 Jun 2003 09:55:29 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Fri Jun 06 10:07:36 2003 +0800 Received: from bellnet-mail1.sbell.com.cn ([172.24.208.21]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.5329); Fri, 6 Jun 2003 10:07:35 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Jun 2003 10:07:35 +0800 Message-ID: Thread-Topic: [Megaco] EventsToken in auditItem of teminationAudit or empty eventsDescriptor Thread-Index: AcMrQL2UCfaEO2XhT+WBjUnitJu7dQAi64pgAAD2sKA= From: "FND-AD Wang JuLin" To: X-OriginalArrivalTime: 06 Jun 2003 02:07:35.0777 (UTC) FILETIME=[65CF1D10:01C32BD0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5627CB31071 Subject: [Megaco] consulting for the standard about MultiMedia Gateway Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dear all, Is there any standard about MM gateway besides H.248 Anex M4. I was searching for the call flow between H.320/H.324 terminals through Trunking MMG under the control of Softswitch. Another issue is when we handle the rtp media stream by IP tunneling,is there any related standard about the SDP description of RTP? Any suggestion is highly appreciated. best regards > :-)Jerry Wang tel:(8621)58541240 ext 9531 mailto:Julin.Wang@alcatel-sbell.com.cn Alcatel Shanghai Bell Co.LTD _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jun 5 22:12:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25393 for ; Thu, 5 Jun 2003 22:12:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h562Bmb31906 for megaco-archive@odin.ietf.org; Thu, 5 Jun 2003 22:11:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h562BmB31902 for ; Thu, 5 Jun 2003 22:11:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25385 for ; Thu, 5 Jun 2003 22:11:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O6fv-0005Oj-00 for megaco-web-archive@ietf.org; Thu, 05 Jun 2003 22:09:51 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19O6fu-0005Og-00 for megaco-web-archive@ietf.org; Thu, 05 Jun 2003 22:09:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5629IB31833; Thu, 5 Jun 2003 22:09:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5627CB31070 for ; Thu, 5 Jun 2003 22:07:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25261 for ; Thu, 5 Jun 2003 22:07:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O6bT-0005N9-00 for megaco@ietf.org; Thu, 05 Jun 2003 22:05:15 -0400 Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx with esmtp (Exim 4.12) id 19O6bR-0005N4-00 for megaco@ietf.org; Thu, 05 Jun 2003 22:05:14 -0400 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.2+Sun/8.12.3) with SMTP id h561tSRK009131 for ; Fri, 6 Jun 2003 09:55:29 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Fri Jun 06 10:07:36 2003 +0800 Received: from bellnet-mail1.sbell.com.cn ([172.24.208.21]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.5329); Fri, 6 Jun 2003 10:07:35 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Jun 2003 10:07:35 +0800 Message-ID: Thread-Topic: [Megaco] EventsToken in auditItem of teminationAudit or empty eventsDescriptor Thread-Index: AcMrQL2UCfaEO2XhT+WBjUnitJu7dQAi64pgAAD2sKA= From: "FND-AD Wang JuLin" To: X-OriginalArrivalTime: 06 Jun 2003 02:07:35.0777 (UTC) FILETIME=[65CF1D10:01C32BD0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5627CB31071 Subject: [Megaco] consulting for the standard about MultiMedia Gateway Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Dear all, Is there any standard about MM gateway besides H.248 Anex M4. I was searching for the call flow between H.320/H.324 terminals through Trunking MMG under the control of Softswitch. Another issue is when we handle the rtp media stream by IP tunneling,is there any related standard about the SDP description of RTP? Any suggestion is highly appreciated. best regards > :-)Jerry Wang tel:(8621)58541240 ext 9531 mailto:Julin.Wang@alcatel-sbell.com.cn Alcatel Shanghai Bell Co.LTD _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jun 5 23:53:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27296 for ; Thu, 5 Jun 2003 23:53:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h563qlB06008; Thu, 5 Jun 2003 23:52:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h563piB05953 for ; Thu, 5 Jun 2003 23:51:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27241 for ; Thu, 5 Jun 2003 23:51:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O8Ef-0005uL-00 for megaco@ietf.org; Thu, 05 Jun 2003 23:49:49 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19O8Ee-0005uI-00 for megaco@ietf.org; Thu, 05 Jun 2003 23:49:48 -0400 Received: from brsf10.epa.ericsson.se ([61.88.9.226]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h563nBT02444; Fri, 6 Jun 2003 13:49:11 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h563pbb22410; Fri, 6 Jun 2003 13:51:37 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.236.88]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LZBX3AQ1; Fri, 6 Jun 2003 13:51:36 +1000 Message-ID: <3EE00FBE.589424E4@ericsson.com.au> Date: Fri, 06 Jun 2003 13:51:26 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: FND-AD Wang JuLin CC: megaco@ietf.org Subject: Re: [Megaco] consulting for the standard about MultiMedia Gateway References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Jerry, H.248.12 Annex A also provides some information. Regards, Christian FND-AD Wang JuLin wrote: > > Dear all, > Is there any standard about MM gateway besides H.248 Anex M4. I was > searching for the call flow between H.320/H.324 terminals through > Trunking MMG under the control of Softswitch. > Another issue is when we handle the rtp media stream by IP tunneling,is > there any related standard about the SDP description of RTP? > > Any suggestion is highly appreciated. > > best regards > > :-)Jerry Wang > tel:(8621)58541240 ext 9531 > mailto:Julin.Wang@alcatel-sbell.com.cn > Alcatel Shanghai Bell Co.LTD > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jun 5 23:55:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27330 for ; Thu, 5 Jun 2003 23:55:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h563sct06060 for megaco-archive@odin.ietf.org; Thu, 5 Jun 2003 23:54:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h563scB06057 for ; Thu, 5 Jun 2003 23:54:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27325 for ; Thu, 5 Jun 2003 23:54:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O8HT-0005v7-00 for megaco-web-archive@ietf.org; Thu, 05 Jun 2003 23:52:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19O8HS-0005v4-00 for megaco-web-archive@ietf.org; Thu, 05 Jun 2003 23:52:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h563qlB06008; Thu, 5 Jun 2003 23:52:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h563piB05953 for ; Thu, 5 Jun 2003 23:51:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27241 for ; Thu, 5 Jun 2003 23:51:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O8Ef-0005uL-00 for megaco@ietf.org; Thu, 05 Jun 2003 23:49:49 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19O8Ee-0005uI-00 for megaco@ietf.org; Thu, 05 Jun 2003 23:49:48 -0400 Received: from brsf10.epa.ericsson.se ([61.88.9.226]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h563nBT02444; Fri, 6 Jun 2003 13:49:11 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h563pbb22410; Fri, 6 Jun 2003 13:51:37 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.236.88]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LZBX3AQ1; Fri, 6 Jun 2003 13:51:36 +1000 Message-ID: <3EE00FBE.589424E4@ericsson.com.au> Date: Fri, 06 Jun 2003 13:51:26 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: FND-AD Wang JuLin CC: megaco@ietf.org Subject: Re: [Megaco] consulting for the standard about MultiMedia Gateway References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Jerry, H.248.12 Annex A also provides some information. Regards, Christian FND-AD Wang JuLin wrote: > > Dear all, > Is there any standard about MM gateway besides H.248 Anex M4. I was > searching for the call flow between H.320/H.324 terminals through > Trunking MMG under the control of Softswitch. > Another issue is when we handle the rtp media stream by IP tunneling,is > there any related standard about the SDP description of RTP? > > Any suggestion is highly appreciated. > > best regards > > :-)Jerry Wang > tel:(8621)58541240 ext 9531 > mailto:Julin.Wang@alcatel-sbell.com.cn > Alcatel Shanghai Bell Co.LTD > > > _______________________________________________ > 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 Jun 9 13:02:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12516 for ; Mon, 9 Jun 2003 13:02:08 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59H0bB17429; Mon, 9 Jun 2003 13:00:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59GwrB17314 for ; Mon, 9 Jun 2003 12:58:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12395; Mon, 9 Jun 2003 12:58:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PPwv-0005EV-00; Mon, 09 Jun 2003 12:56:49 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19PPwu-0005ES-00; Mon, 09 Jun 2003 12:56:48 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h59GwnD08477; Mon, 9 Jun 2003 09:58:49 -0700 (PDT) Message-Id: <200306091658.h59GwnD08477@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, megaco@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 09 Jun 2003 09:58:49 -0700 Subject: [Megaco] RFC 3525 on Gateway Control Protocol Version 1 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3525 Title: Gateway Control Protocol Version 1 Author(s): C. Groves, M. Pantaleo, T. Anderson, T. Taylor, Editors Status: Standards Track Date: June 2003 Mailbox: Christian.Groves@ericsson.com.au, Marcello.Pantaleo@eed.ericsson.se, tlatla@verizon.net, taylor@nortelnetworks.com Pages: 213 Characters: 439674 Obsoletes: 3015 I-D Tag: draft-ietf-megaco-3015corr-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3525.txt This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e., a Media Gateway and a Media Gateway Controller. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. This document replaces RFC 3015. It is the result of continued cooperation between the IETF Megaco Working Group and ITU-T Study Group 16. It incorporates the original text of RFC 3015, modified by corrections and clarifications discussed on the Megaco E-mail list and incorporated into the Study Group 16 Implementor's Guide for Recommendation H.248. The present version of this document underwent ITU-T Last Call as Recommendation H.248 Amendment 1. Because of ITU-T renumbering, it was published by the ITU-T as Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. Users of this specification are advised to consult the H.248 Sub-series Implementors' Guide at http://www.itu.int/itudoc/itu-t/com16/implgd for additional corrections and clarifications. This document is a product of the Media Gateway Control Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030609095640.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3525 --OtherAccess Content-Type: Message/External-body; name="rfc3525.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030609095640.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jun 9 13:03:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12569 for ; Mon, 9 Jun 2003 13:03:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59H2p217641 for megaco-archive@odin.ietf.org; Mon, 9 Jun 2003 13:02:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59H2pB17638 for ; Mon, 9 Jun 2003 13:02:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12560 for ; Mon, 9 Jun 2003 13:02:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PQ0l-0005Gp-00 for megaco-web-archive@ietf.org; Mon, 09 Jun 2003 13:00:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PQ0k-0005Gl-00 for megaco-web-archive@ietf.org; Mon, 09 Jun 2003 13:00:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59H0bB17429; Mon, 9 Jun 2003 13:00:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59GwrB17314 for ; Mon, 9 Jun 2003 12:58:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12395; Mon, 9 Jun 2003 12:58:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PPwv-0005EV-00; Mon, 09 Jun 2003 12:56:49 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19PPwu-0005ES-00; Mon, 09 Jun 2003 12:56:48 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h59GwnD08477; Mon, 9 Jun 2003 09:58:49 -0700 (PDT) Message-Id: <200306091658.h59GwnD08477@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, megaco@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 09 Jun 2003 09:58:49 -0700 Subject: [Megaco] RFC 3525 on Gateway Control Protocol Version 1 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3525 Title: Gateway Control Protocol Version 1 Author(s): C. Groves, M. Pantaleo, T. Anderson, T. Taylor, Editors Status: Standards Track Date: June 2003 Mailbox: Christian.Groves@ericsson.com.au, Marcello.Pantaleo@eed.ericsson.se, tlatla@verizon.net, taylor@nortelnetworks.com Pages: 213 Characters: 439674 Obsoletes: 3015 I-D Tag: draft-ietf-megaco-3015corr-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3525.txt This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e., a Media Gateway and a Media Gateway Controller. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. This document replaces RFC 3015. It is the result of continued cooperation between the IETF Megaco Working Group and ITU-T Study Group 16. It incorporates the original text of RFC 3015, modified by corrections and clarifications discussed on the Megaco E-mail list and incorporated into the Study Group 16 Implementor's Guide for Recommendation H.248. The present version of this document underwent ITU-T Last Call as Recommendation H.248 Amendment 1. Because of ITU-T renumbering, it was published by the ITU-T as Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. Users of this specification are advised to consult the H.248 Sub-series Implementors' Guide at http://www.itu.int/itudoc/itu-t/com16/implgd for additional corrections and clarifications. This document is a product of the Media Gateway Control Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030609095640.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3525 --OtherAccess Content-Type: Message/External-body; name="rfc3525.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030609095640.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jun 9 14:24:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15390 for ; Mon, 9 Jun 2003 14:24:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59INjB24800; Mon, 9 Jun 2003 14:23:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59ILZB24656 for ; Mon, 9 Jun 2003 14:21:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15291 for ; Mon, 9 Jun 2003 14:21:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PREv-0005yk-00 for megaco@ietf.org; Mon, 09 Jun 2003 14:19:29 -0400 Received: from [168.226.49.107] (helo=mail3.telefonica.com.ar) by ietf-mx with esmtp (Exim 4.12) id 19PREu-0005yf-00 for megaco@ietf.org; Mon, 09 Jun 2003 14:19:28 -0400 Received: from mailhub.telefonica.com.ar ([168.226.28.51]) by mail3 with InterScan Messaging Security Suite; Mon, 09 Jun 2003 15:20:45 -0300 Received: by mailhub.sote.tasa.com.ar with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Jun 2003 15:20:50 -0300 Message-ID: <6BB2DEB822D3D111817B00805FBE5F0215181EDF@mstelefonica6.sote.tasa.com.ar> From: Pellegrino Jose Luis To: "'rfc-editor@rfc-editor.org'" Cc: megaco@ietf.org Subject: RE: [Megaco] RFC 3525 on Gateway Control Protocol Version 1 Date: Mon, 9 Jun 2003 15:20:47 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , What about draft-MEGACO version 2 published during last april? A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Media Gateway Control Working Group of the IETF. Title : The Megaco/H.248v2 Gateway Control Protocol, version 2 Author(s) : C. Groves, M. Pantaleo et al. Filename : draft-ietf-megaco-h248v2-04.txt Pages : 219 Date : 2003-4-3 Does the new RFC 3525 reeplaces this draft. Notice that this draft expires on next october. If this draft is still alive, does it mean that it will became on a new RFCXXXX in the future? If so, that RFCXXXX will obsolete the RFC3525, will not it? Jose Luis, > -----Mensaje original----- > De: rfc-editor@rfc-editor.org [SMTP:rfc-editor@rfc-editor.org] > Enviado el: Lunes 9 de Junio de 2003 13:59 > CC: rfc-editor@rfc-editor.org; megaco@ietf.org > Asunto: [Megaco] RFC 3525 on Gateway Control Protocol Version 1 > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 3525 > > Title: Gateway Control Protocol Version 1 > Author(s): C. Groves, M. Pantaleo, T. Anderson, T. Taylor, > Editors > Status: Standards Track > Date: June 2003 > Mailbox: Christian.Groves@ericsson.com.au, > Marcello.Pantaleo@eed.ericsson.se, > tlatla@verizon.net, > taylor@nortelnetworks.com > Pages: 213 > Characters: 439674 > Obsoletes: 3015 > > I-D Tag: draft-ietf-megaco-3015corr-03.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3525.txt > > > This document defines the protocol used between elements of a > physically decomposed multimedia gateway, i.e., a Media Gateway and a > Media Gateway Controller. The protocol presented in this document > meets the requirements for a media gateway control protocol as > presented in RFC 2805. > > This document replaces RFC 3015. It is the result of > continued cooperation between the IETF Megaco Working Group and ITU-T > Study Group 16. It incorporates the original text of RFC 3015, > modified by corrections and clarifications discussed on the Megaco > > E-mail list and incorporated into the Study Group 16 Implementor's > Guide for Recommendation H.248. The present version of this document > underwent ITU-T Last Call as Recommendation H.248 Amendment 1. > Because of ITU-T renumbering, it was published by the ITU-T as > Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. > > Users of this specification are advised to consult the H.248 > Sub-series Implementors' Guide at > http://www.itu.int/itudoc/itu-t/com16/implgd for additional > corrections and clarifications. > > This document is a product of the Media Gateway Control Working Group > of the IETF. > > This is now a Proposed Standard Protocol. > > This document specifies an Internet standards track protocol for > the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the > "Internet Official Protocol Standards" (STD 1) for the > standardization state and status of this protocol. Distribution > of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution.echo > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. <> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jun 9 14:25:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15440 for ; Mon, 9 Jun 2003 14:25:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59IPRw24921 for megaco-archive@odin.ietf.org; Mon, 9 Jun 2003 14:25:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59IPRB24918 for ; Mon, 9 Jun 2003 14:25:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15425 for ; Mon, 9 Jun 2003 14:25:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PRIf-00061K-00 for megaco-web-archive@ietf.org; Mon, 09 Jun 2003 14:23:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PRIe-00061H-00 for megaco-web-archive@ietf.org; Mon, 09 Jun 2003 14:23:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59INjB24800; Mon, 9 Jun 2003 14:23:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59ILZB24656 for ; Mon, 9 Jun 2003 14:21:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15291 for ; Mon, 9 Jun 2003 14:21:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PREv-0005yk-00 for megaco@ietf.org; Mon, 09 Jun 2003 14:19:29 -0400 Received: from [168.226.49.107] (helo=mail3.telefonica.com.ar) by ietf-mx with esmtp (Exim 4.12) id 19PREu-0005yf-00 for megaco@ietf.org; Mon, 09 Jun 2003 14:19:28 -0400 Received: from mailhub.telefonica.com.ar ([168.226.28.51]) by mail3 with InterScan Messaging Security Suite; Mon, 09 Jun 2003 15:20:45 -0300 Received: by mailhub.sote.tasa.com.ar with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Jun 2003 15:20:50 -0300 Message-ID: <6BB2DEB822D3D111817B00805FBE5F0215181EDF@mstelefonica6.sote.tasa.com.ar> From: Pellegrino Jose Luis To: "'rfc-editor@rfc-editor.org'" Cc: megaco@ietf.org Subject: RE: [Megaco] RFC 3525 on Gateway Control Protocol Version 1 Date: Mon, 9 Jun 2003 15:20:47 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h59INjB24800 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h59IPRB24918 Content-Transfer-Encoding: 8bit What about draft-MEGACO version 2 published during last april? A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Media Gateway Control Working Group of the IETF. Title : The Megaco/H.248v2 Gateway Control Protocol, version 2 Author(s) : C. Groves, M. Pantaleo et al. Filename : draft-ietf-megaco-h248v2-04.txt Pages : 219 Date : 2003-4-3 Does the new RFC 3525 reeplaces this draft. Notice that this draft expires on next october. If this draft is still alive, does it mean that it will became on a new RFCXXXX in the future? If so, that RFCXXXX will obsolete the RFC3525, will not it? Jose Luis, > -----Mensaje original----- > De: rfc-editor@rfc-editor.org [SMTP:rfc-editor@rfc-editor.org] > Enviado el: Lunes 9 de Junio de 2003 13:59 > CC: rfc-editor@rfc-editor.org; megaco@ietf.org > Asunto: [Megaco] RFC 3525 on Gateway Control Protocol Version 1 > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 3525 > > Title: Gateway Control Protocol Version 1 > Author(s): C. Groves, M. Pantaleo, T. Anderson, T. Taylor, > Editors > Status: Standards Track > Date: June 2003 > Mailbox: Christian.Groves@ericsson.com.au, > Marcello.Pantaleo@eed.ericsson.se, > tlatla@verizon.net, > taylor@nortelnetworks.com > Pages: 213 > Characters: 439674 > Obsoletes: 3015 > > I-D Tag: draft-ietf-megaco-3015corr-03.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3525.txt > > > This document defines the protocol used between elements of a > physically decomposed multimedia gateway, i.e., a Media Gateway and a > Media Gateway Controller. The protocol presented in this document > meets the requirements for a media gateway control protocol as > presented in RFC 2805. > > This document replaces RFC 3015. It is the result of > continued cooperation between the IETF Megaco Working Group and ITU-T > Study Group 16. It incorporates the original text of RFC 3015, > modified by corrections and clarifications discussed on the Megaco > > E-mail list and incorporated into the Study Group 16 Implementor's > Guide for Recommendation H.248. The present version of this document > underwent ITU-T Last Call as Recommendation H.248 Amendment 1. > Because of ITU-T renumbering, it was published by the ITU-T as > Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. > > Users of this specification are advised to consult the H.248 > Sub-series Implementors' Guide at > http://www.itu.int/itudoc/itu-t/com16/implgd for additional > corrections and clarifications. > > This document is a product of the Media Gateway Control Working Group > of the IETF. > > This is now a Proposed Standard Protocol. > > This document specifies an Internet standards track protocol for > the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the > "Internet Official Protocol Standards" (STD 1) for the > standardization state and status of this protocol. Distribution > of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution.echo > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. <> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jun 9 15:03:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16930 for ; Mon, 9 Jun 2003 15:03:39 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59J2JB27639; Mon, 9 Jun 2003 15:02:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59J13B27565 for ; Mon, 9 Jun 2003 15:01:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16774 for ; Mon, 9 Jun 2003 15:00:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PRr6-0006J6-00 for megaco@ietf.org; Mon, 09 Jun 2003 14:58:56 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19PRr5-0006It-00 for megaco@ietf.org; Mon, 09 Jun 2003 14:58:55 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h59J0Mj11340; Mon, 9 Jun 2003 15:00:22 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLGBLBQ; Mon, 9 Jun 2003 15:00:22 -0400 Received: from nortelnetworks.com (acart1dn.ca.nortel.com [47.129.129.97]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0R6W; Mon, 9 Jun 2003 15:00:22 -0400 Message-ID: <3EE4D943.9060504@nortelnetworks.com> Date: Mon, 09 Jun 2003 15:00:19 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Pellegrino Jose Luis CC: megaco@ietf.org Subject: Re: [Megaco] RFC 3525 on Gateway Control Protocol Version 1 References: <6BB2DEB822D3D111817B00805FBE5F0215181EDF@mstelefonica6.sote.tasa.com.ar> In-Reply-To: <6BB2DEB822D3D111817B00805FBE5F0215181EDF@mstelefonica6.sote.tasa.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by zcars0m9.nortelnetworks.com id h59J0Mj11340 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h59J13B27566 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit As it says in the abstract to the version 2 draft, this draft when approved will UPDATE, not OBSOLETE, RFC 3525. At least, that is how I have always seen the matter. If this list feels otherwise, say so now: the draft has been submitted for consideration as an RFC, but is still in the preliminary stages of evaluation. BTW does anyone who wasn't close to its production want to do a review of the draft for the Area Director (Jon Peterson)? Pellegrino Jose Luis wrote: > What about draft-MEGACO version 2 published during last april? > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Media Gateway Control Working Group of the > IETF. > > Title : The Megaco/H.248v2 Gateway Control Protocol, > version 2 > Author(s) : C. Groves, M. Pantaleo et al. > Filename : draft-ietf-megaco-h248v2-04.txt > Pages : 219 > Date : 2003-4-3 > > Does the new RFC 3525 reeplaces this draft. Notice that this draft expires > on next october. > If this draft is still alive, does it mean that it will became on a new > RFCXXXX in the future? If so, that RFCXXXX will obsolete the RFC3525, will > not it? > Jose Luis, > > > >>-----Mensaje original----- >>De: rfc-editor@rfc-editor.org [SMTP:rfc-editor@rfc-editor.org] >>Enviado el: Lunes 9 de Junio de 2003 13:59 >>CC: rfc-editor@rfc-editor.org; megaco@ietf.org >>Asunto: [Megaco] RFC 3525 on Gateway Control Protocol Version 1 >> >> >>A new Request for Comments is now available in online RFC libraries. >> >> >> RFC 3525 >> >> Title: Gateway Control Protocol Version 1 >> Author(s): C. Groves, M. Pantaleo, T. Anderson, T. Taylor, >> Editors >> Status: Standards Track >> Date: June 2003 >> Mailbox: Christian.Groves@ericsson.com.au, >> Marcello.Pantaleo@eed.ericsson.se, >> tlatla@verizon.net, >> taylor@nortelnetworks.com >> Pages: 213 >> Characters: 439674 >> Obsoletes: 3015 >> >> I-D Tag: draft-ietf-megaco-3015corr-03.txt >> >> URL: ftp://ftp.rfc-editor.org/in-notes/rfc3525.txt >> >> >>This document defines the protocol used between elements of a >>physically decomposed multimedia gateway, i.e., a Media Gateway and a >>Media Gateway Controller. The protocol presented in this document >>meets the requirements for a media gateway control protocol as >>presented in RFC 2805. >> >>This document replaces RFC 3015. It is the result of >>continued cooperation between the IETF Megaco Working Group and ITU-T >>Study Group 16. It incorporates the original text of RFC 3015, >>modified by corrections and clarifications discussed on the Megaco >> >>E-mail list and incorporated into the Study Group 16 Implementor's >>Guide for Recommendation H.248. The present version of this document >>underwent ITU-T Last Call as Recommendation H.248 Amendment 1. >>Because of ITU-T renumbering, it was published by the ITU-T as >>Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. >> >>Users of this specification are advised to consult the H.248 >>Sub-series Implementors' Guide at >>http://www.itu.int/itudoc/itu-t/com16/implgd for additional >>corrections and clarifications. >> >>This document is a product of the Media Gateway Control Working Group >>of the IETF. >> >>This is now a Proposed Standard Protocol. >> >>This document specifies an Internet standards track protocol for >>the Internet community, and requests discussion and suggestions >>for improvements. Please refer to the current edition of the >>"Internet Official Protocol Standards" (STD 1) for the >>standardization state and status of this protocol. Distribution >>of this memo is unlimited. >> >>This announcement is sent to the IETF list and the RFC-DIST list. >>Requests to be added to or deleted from the IETF distribution list >>should be sent to IETF-REQUEST@IETF.ORG. Requests to be >>added to or deleted from the RFC-DIST distribution list should >>be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. >> >>Details on obtaining RFCs via FTP or EMAIL may be obtained by sending >>an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body >>help: ways_to_get_rfcs. For example: >> >> To: rfc-info@RFC-EDITOR.ORG >> Subject: getting rfcs >> >> help: ways_to_get_rfcs >> >>Requests for special distribution should be addressed to either the >>author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless >>specifically noted otherwise on the RFC itself, all RFCs are for >>unlimited distribution.echo >>Submissions for Requests for Comments should be sent to >>RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC >>Authors, for further information. >> >> >>Joyce K. Reynolds and Sandy Ginoza >>USC/Information Sciences Institute >> >>... >> >>Below is the data which will enable a MIME compliant Mail Reader >>implementation to automatically retrieve the ASCII version >>of the RFCs. <> > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jun 9 15:04:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17108 for ; Mon, 9 Jun 2003 15:04:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59J4Vg27732 for megaco-archive@odin.ietf.org; Mon, 9 Jun 2003 15:04:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59J4VB27729 for ; Mon, 9 Jun 2003 15:04:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17054 for ; Mon, 9 Jun 2003 15:04:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PRuS-0006LV-00 for megaco-web-archive@ietf.org; Mon, 09 Jun 2003 15:02:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PRuS-0006LS-00 for megaco-web-archive@ietf.org; Mon, 09 Jun 2003 15:02:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59J2JB27639; Mon, 9 Jun 2003 15:02:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59J13B27565 for ; Mon, 9 Jun 2003 15:01:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16774 for ; Mon, 9 Jun 2003 15:00:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PRr6-0006J6-00 for megaco@ietf.org; Mon, 09 Jun 2003 14:58:56 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19PRr5-0006It-00 for megaco@ietf.org; Mon, 09 Jun 2003 14:58:55 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h59J0Mj11340; Mon, 9 Jun 2003 15:00:22 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLGBLBQ; Mon, 9 Jun 2003 15:00:22 -0400 Received: from nortelnetworks.com (acart1dn.ca.nortel.com [47.129.129.97]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0R6W; Mon, 9 Jun 2003 15:00:22 -0400 Message-ID: <3EE4D943.9060504@nortelnetworks.com> Date: Mon, 09 Jun 2003 15:00:19 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Pellegrino Jose Luis CC: megaco@ietf.org Subject: Re: [Megaco] RFC 3525 on Gateway Control Protocol Version 1 References: <6BB2DEB822D3D111817B00805FBE5F0215181EDF@mstelefonica6.sote.tasa.com.ar> In-Reply-To: <6BB2DEB822D3D111817B00805FBE5F0215181EDF@mstelefonica6.sote.tasa.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by zcars0m9.nortelnetworks.com id h59J0Mj11340 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h59J13B27566 Sender: megaco-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-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h59J2JB27639 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h59J4VB27729 Content-Transfer-Encoding: 8bit As it says in the abstract to the version 2 draft, this draft when approved will UPDATE, not OBSOLETE, RFC 3525. At least, that is how I have always seen the matter. If this list feels otherwise, say so now: the draft has been submitted for consideration as an RFC, but is still in the preliminary stages of evaluation. BTW does anyone who wasn't close to its production want to do a review of the draft for the Area Director (Jon Peterson)? Pellegrino Jose Luis wrote: > What about draft-MEGACO version 2 published during last april? > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Media Gateway Control Working Group of the > IETF. > > Title : The Megaco/H.248v2 Gateway Control Protocol, > version 2 > Author(s) : C. Groves, M. Pantaleo et al. > Filename : draft-ietf-megaco-h248v2-04.txt > Pages : 219 > Date : 2003-4-3 > > Does the new RFC 3525 reeplaces this draft. Notice that this draft expires > on next october. > If this draft is still alive, does it mean that it will became on a new > RFCXXXX in the future? If so, that RFCXXXX will obsolete the RFC3525, will > not it? > Jose Luis, > > > >>-----Mensaje original----- >>De: rfc-editor@rfc-editor.org [SMTP:rfc-editor@rfc-editor.org] >>Enviado el: Lunes 9 de Junio de 2003 13:59 >>CC: rfc-editor@rfc-editor.org; megaco@ietf.org >>Asunto: [Megaco] RFC 3525 on Gateway Control Protocol Version 1 >> >> >>A new Request for Comments is now available in online RFC libraries. >> >> >> RFC 3525 >> >> Title: Gateway Control Protocol Version 1 >> Author(s): C. Groves, M. Pantaleo, T. Anderson, T. Taylor, >> Editors >> Status: Standards Track >> Date: June 2003 >> Mailbox: Christian.Groves@ericsson.com.au, >> Marcello.Pantaleo@eed.ericsson.se, >> tlatla@verizon.net, >> taylor@nortelnetworks.com >> Pages: 213 >> Characters: 439674 >> Obsoletes: 3015 >> >> I-D Tag: draft-ietf-megaco-3015corr-03.txt >> >> URL: ftp://ftp.rfc-editor.org/in-notes/rfc3525.txt >> >> >>This document defines the protocol used between elements of a >>physically decomposed multimedia gateway, i.e., a Media Gateway and a >>Media Gateway Controller. The protocol presented in this document >>meets the requirements for a media gateway control protocol as >>presented in RFC 2805. >> >>This document replaces RFC 3015. It is the result of >>continued cooperation between the IETF Megaco Working Group and ITU-T >>Study Group 16. It incorporates the original text of RFC 3015, >>modified by corrections and clarifications discussed on the Megaco >> >>E-mail list and incorporated into the Study Group 16 Implementor's >>Guide for Recommendation H.248. The present version of this document >>underwent ITU-T Last Call as Recommendation H.248 Amendment 1. >>Because of ITU-T renumbering, it was published by the ITU-T as >>Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. >> >>Users of this specification are advised to consult the H.248 >>Sub-series Implementors' Guide at >>http://www.itu.int/itudoc/itu-t/com16/implgd for additional >>corrections and clarifications. >> >>This document is a product of the Media Gateway Control Working Group >>of the IETF. >> >>This is now a Proposed Standard Protocol. >> >>This document specifies an Internet standards track protocol for >>the Internet community, and requests discussion and suggestions >>for improvements. Please refer to the current edition of the >>"Internet Official Protocol Standards" (STD 1) for the >>standardization state and status of this protocol. Distribution >>of this memo is unlimited. >> >>This announcement is sent to the IETF list and the RFC-DIST list. >>Requests to be added to or deleted from the IETF distribution list >>should be sent to IETF-REQUEST@IETF.ORG. Requests to be >>added to or deleted from the RFC-DIST distribution list should >>be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. >> >>Details on obtaining RFCs via FTP or EMAIL may be obtained by sending >>an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body >>help: ways_to_get_rfcs. For example: >> >> To: rfc-info@RFC-EDITOR.ORG >> Subject: getting rfcs >> >> help: ways_to_get_rfcs >> >>Requests for special distribution should be addressed to either the >>author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless >>specifically noted otherwise on the RFC itself, all RFCs are for >>unlimited distribution.echo >>Submissions for Requests for Comments should be sent to >>RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC >>Authors, for further information. >> >> >>Joyce K. Reynolds and Sandy Ginoza >>USC/Information Sciences Institute >> >>... >> >>Below is the data which will enable a MIME compliant Mail Reader >>implementation to automatically retrieve the ASCII version >>of the RFCs. <> > > _______________________________________________ > 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 Jun 10 01:41:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02299 for ; Tue, 10 Jun 2003 01:41:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A5dIB06033; Tue, 10 Jun 2003 01:39:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A5bMB05504 for ; Tue, 10 Jun 2003 01:37:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02159 for ; Tue, 10 Jun 2003 01:37:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pbmt-0001oI-00 for megaco@ietf.org; Tue, 10 Jun 2003 01:35:15 -0400 Received: from [202.144.91.188] (helo=ipgen-india.com) by ietf-mx with esmtp (Exim 4.12) id 19Pbmf-0001nF-00 for megaco@ietf.org; Tue, 10 Jun 2003 01:35:02 -0400 Received: from sureshchandra [192.168.1.230] by ipgen-india.com [192.168.1.15] with SMTP (MDaemon.PRO.v5.0.7.T) for ; Tue, 10 Jun 2003 11:06:53 +0530 Message-ID: <02b001c32f12$b2f9d4a0$e601a8c0@sureshchandra> From: "H.S.Sureshchandra" To: "Tom Taylor" , "Simran Chadha" Cc: "Megaco List" References: <20030204052156.14303.qmail@webmail28.rediffmail.com> <3E400D7B.8080102@nortelnetworks.com> Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote Descriptors! Date: Tue, 10 Jun 2003 11:09:42 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MDRemoteIP: 192.168.1.230 X-Return-Path: suresh@ipgen.com X-MDaemon-Deliver-To: megaco@ietf.org Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Tom, I do not see incorporation of any of the observations made by my colleague Simran Chadha in the new RFC 3525, as "promised" by you in your earlier mail. Please clarify. Thanks ! Suresh ----- Original Message ----- From: "Tom Taylor" To: "Simran Chadha" Cc: "Megaco List" Sent: Wednesday, February 05, 2003 12:29 AM Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote Descriptors! > That "cannot not" is a typo -- I'll remove the "not" during the "authors' 48 hours" > interval prior to formal publication as a new RFC. > > On your second point: the two paragraphs apply independently to ReserveGroup and > ReserveValue. That is, it is possible to have ReserveGroup TRUE and ReserveValue > FALSE -- in which case the MG reserves for multiple session descriptions but is > restricted to one codec in each -- or vice versa. Or both could be TRUE, or both FALSE. > > On the third point, the intended meaning would be conveyed by replacing "if it > cannot support any of the alternatives" with "if it can support none of the > alternatives". Perhaps I can also do that during the "authors' 48 hours" period, > though we would usually do it through the ITU-T Implementor's Guide. > > The task of developing an unambiguous protocol specification is not simple. Your > points have eluded others in the three years since first approval. Thank you for > your contribution. > > Simran Chadha wrote: > > > > Hi List, > > > > Can someone please help me at the earliest on the issues raised earlier > > by me - particularly, usage of LocalControl,Local and Remote Descriptors ? > > > > Thanks in advance. > > > > Simran Chadha > > On Thu, 30 Jan 2003 Simran Chadha wrote : > > > >> Hi List, > >> > >> Can you please help me with clarifications in my understanding of > >> sections 7.1.7 and 7.1.8 on the use of LocalControl,Local and Remote > >> Descriptors. > >> > >> As per draft-ietf-megaco-3015corr-03, in section 7.1.7, > >> If the value of a Reserve property is True, the MG SHALL reserve > >> resources for all alternatives specified in the Local and/or Remote > >> descriptors for which it currently has resources available. It SHALL > >> respond with the alternatives for which it reserves resources. If it > >> cannot not support any of the alternatives, it SHALL respond with a > >> reply to the MGC that contains empty Local and/or Remote descriptors. > >> The use of two negations - "cannot not" in the last statement will > >> imply that - If it can support any of the alternatives, it SHALL > >> respond with a reply to the MGC that contains empty Local and/or > >> Remote descriptors. > >> I don't think this is what is meant to be conveyed here. > >> > >> Also in section 7.1.7 the first para starts - If the value of a > >> Reserve property is True, ..... > >> while the second para starts - If the value of a Reserve property is > >> False, .... > >> Now as there are two Reserve properties - one Reserve Group and the > >> other Reserve Value, One could be False and the other could be True. > >> Then in this case what will be the inference - Should para 1 apply or > >> para 2 ? Both the paras would seem to be mutually exclusive in what is > >> needed to be done. > >> > >> Also statements like "if it cannot support any of the alternatives ... > >> " - will have two meanings. > >> 1. Any - Not even one - NONE of the alternatives is supported. > >> 2. Any - Atleast one - While a few alternatives can be supported, a > >> few might not be. > >> > >> The protocol needs to be more clear on such aspects in the documents > >> henceforth. The English language is understood in different parts of > >> the world. Variations to agreed usage of the language terms will make > >> it difficult for new users of Megaco protocol, like me. > >> > >> Can someone please educate me on the exact usage and meaning of > >> LocalControl,Local and Remote Descriptors ? > >> > >> Thanks and awaiting comments and clarifications > >> > >> Simran Chadha > > > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jun 10 01:42:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02319 for ; Tue, 10 Jun 2003 01:42:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5A5g6706310 for megaco-archive@odin.ietf.org; Tue, 10 Jun 2003 01:42:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A5g6B06307 for ; Tue, 10 Jun 2003 01:42:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02315 for ; Tue, 10 Jun 2003 01:42:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PbrT-0001rb-00 for megaco-web-archive@ietf.org; Tue, 10 Jun 2003 01:39:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PbrT-0001rY-00 for megaco-web-archive@ietf.org; Tue, 10 Jun 2003 01:39:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A5dIB06033; Tue, 10 Jun 2003 01:39:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A5bMB05504 for ; Tue, 10 Jun 2003 01:37:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02159 for ; Tue, 10 Jun 2003 01:37:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pbmt-0001oI-00 for megaco@ietf.org; Tue, 10 Jun 2003 01:35:15 -0400 Received: from [202.144.91.188] (helo=ipgen-india.com) by ietf-mx with esmtp (Exim 4.12) id 19Pbmf-0001nF-00 for megaco@ietf.org; Tue, 10 Jun 2003 01:35:02 -0400 Received: from sureshchandra [192.168.1.230] by ipgen-india.com [192.168.1.15] with SMTP (MDaemon.PRO.v5.0.7.T) for ; Tue, 10 Jun 2003 11:06:53 +0530 Message-ID: <02b001c32f12$b2f9d4a0$e601a8c0@sureshchandra> From: "H.S.Sureshchandra" To: "Tom Taylor" , "Simran Chadha" Cc: "Megaco List" References: <20030204052156.14303.qmail@webmail28.rediffmail.com> <3E400D7B.8080102@nortelnetworks.com> Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote Descriptors! Date: Tue, 10 Jun 2003 11:09:42 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MDRemoteIP: 192.168.1.230 X-Return-Path: suresh@ipgen.com X-MDaemon-Deliver-To: megaco@ietf.org Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Tom, I do not see incorporation of any of the observations made by my colleague Simran Chadha in the new RFC 3525, as "promised" by you in your earlier mail. Please clarify. Thanks ! Suresh ----- Original Message ----- From: "Tom Taylor" To: "Simran Chadha" Cc: "Megaco List" Sent: Wednesday, February 05, 2003 12:29 AM Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote Descriptors! > That "cannot not" is a typo -- I'll remove the "not" during the "authors' 48 hours" > interval prior to formal publication as a new RFC. > > On your second point: the two paragraphs apply independently to ReserveGroup and > ReserveValue. That is, it is possible to have ReserveGroup TRUE and ReserveValue > FALSE -- in which case the MG reserves for multiple session descriptions but is > restricted to one codec in each -- or vice versa. Or both could be TRUE, or both FALSE. > > On the third point, the intended meaning would be conveyed by replacing "if it > cannot support any of the alternatives" with "if it can support none of the > alternatives". Perhaps I can also do that during the "authors' 48 hours" period, > though we would usually do it through the ITU-T Implementor's Guide. > > The task of developing an unambiguous protocol specification is not simple. Your > points have eluded others in the three years since first approval. Thank you for > your contribution. > > Simran Chadha wrote: > > > > Hi List, > > > > Can someone please help me at the earliest on the issues raised earlier > > by me - particularly, usage of LocalControl,Local and Remote Descriptors ? > > > > Thanks in advance. > > > > Simran Chadha > > On Thu, 30 Jan 2003 Simran Chadha wrote : > > > >> Hi List, > >> > >> Can you please help me with clarifications in my understanding of > >> sections 7.1.7 and 7.1.8 on the use of LocalControl,Local and Remote > >> Descriptors. > >> > >> As per draft-ietf-megaco-3015corr-03, in section 7.1.7, > >> If the value of a Reserve property is True, the MG SHALL reserve > >> resources for all alternatives specified in the Local and/or Remote > >> descriptors for which it currently has resources available. It SHALL > >> respond with the alternatives for which it reserves resources. If it > >> cannot not support any of the alternatives, it SHALL respond with a > >> reply to the MGC that contains empty Local and/or Remote descriptors. > >> The use of two negations - "cannot not" in the last statement will > >> imply that - If it can support any of the alternatives, it SHALL > >> respond with a reply to the MGC that contains empty Local and/or > >> Remote descriptors. > >> I don't think this is what is meant to be conveyed here. > >> > >> Also in section 7.1.7 the first para starts - If the value of a > >> Reserve property is True, ..... > >> while the second para starts - If the value of a Reserve property is > >> False, .... > >> Now as there are two Reserve properties - one Reserve Group and the > >> other Reserve Value, One could be False and the other could be True. > >> Then in this case what will be the inference - Should para 1 apply or > >> para 2 ? Both the paras would seem to be mutually exclusive in what is > >> needed to be done. > >> > >> Also statements like "if it cannot support any of the alternatives ... > >> " - will have two meanings. > >> 1. Any - Not even one - NONE of the alternatives is supported. > >> 2. Any - Atleast one - While a few alternatives can be supported, a > >> few might not be. > >> > >> The protocol needs to be more clear on such aspects in the documents > >> henceforth. The English language is understood in different parts of > >> the world. Variations to agreed usage of the language terms will make > >> it difficult for new users of Megaco protocol, like me. > >> > >> Can someone please educate me on the exact usage and meaning of > >> LocalControl,Local and Remote Descriptors ? > >> > >> Thanks and awaiting comments and clarifications > >> > >> Simran Chadha > > > > > > > > _______________________________________________ > > 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 Jun 10 08:20:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23142 for ; Tue, 10 Jun 2003 08:20:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACJFB15385; Tue, 10 Jun 2003 08:19:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACHBB15307 for ; Tue, 10 Jun 2003 08:17:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22998 for ; Tue, 10 Jun 2003 08:17:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pi1q-0004J0-00 for megaco@ietf.org; Tue, 10 Jun 2003 08:15:06 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 19Pi1p-0004IJ-00 for megaco@ietf.org; Tue, 10 Jun 2003 08:15:05 -0400 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h5ACG3dp030186 for ; Tue, 10 Jun 2003 14:16:04 +0200 Received: from vies194a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h5ACG1oE011661 for ; Tue, 10 Jun 2003 14:16:02 +0200 (MET DST) Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jun 2003 14:16:01 +0200 Message-ID: From: Kalleitner Franz To: Megaco List Date: Tue, 10 Jun 2003 14:15:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32F49.FD4B6280" Subject: [Megaco] correct connection model for conferencing according darft H.248.1 9 Sender: megaco-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_01C32F49.FD4B6280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello megaco-list-members In the past, many threats were discussing about conferencing. However = SG16 started to summarized this topic in the draft H.248.19 (BTW: Thanks a = lot for that work), but the connection model is still not clear to me. As documented in H.248.19 =A75 (conferencing architectures) it is = mentioned that according H.248 =A76 two different types of conferencing could = apply by placing the relevant terminations in the same or different contexts. In case of implementing conferences using different contexts, which connection model should apply ? 1.) for each conferee an own context as shown at example =A79 draft-ietf-megaco-callflows-02.txt? 2.) separation into a central conference context and for each conferee = an own, lets say, call leg context? 3.) or are both listed connection models meaningful ? The second approach was discussed many times in the list, but there was never a final and clear statement, may be there could be one before finalizing H248.19. Thanks in advance Franz ------_=_NextPart_001_01C32F49.FD4B6280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+Y29ycmVj dCBjb25uZWN0aW9uIG1vZGVsIGZvciBjb25mZXJlbmNpbmcgYWNjb3JkaW5nIGRhcmZ0IEguMjQ4 LjE5PC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp YWwiPkhlbGxvIG1lZ2Fjby1saXN0LW1lbWJlcnM8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJ WkU9MiBGQUNFPSJBcmlhbCI+SW4gdGhlIHBhc3QsIG1hbnkgdGhyZWF0cyB3ZXJlIGRpc2N1c3Np bmcgYWJvdXQgY29uZmVyZW5jaW5nLiBIb3dldmVyIFNHMTYgc3RhcnRlZCB0byBzdW1tYXJpemVk IHRoaXMgdG9waWMgaW4gdGhlIGRyYWZ0IEguMjQ4LjE5IChCVFc6IFRoYW5rcyBhIGxvdCBmb3Ig dGhhdCB3b3JrKSwgYnV0IHRoZSBjb25uZWN0aW9uIG1vZGVsIGlzIHN0aWxsIG5vdCBjbGVhciB0 byBtZS48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkFzIGRvY3Vt ZW50ZWQgaW4gSC4yNDguMTkgpzUgKGNvbmZlcmVuY2luZyBhcmNoaXRlY3R1cmVzKSBpdCBpcyBt ZW50aW9uZWQgdGhhdCBhY2NvcmRpbmcgSC4yNDggpzYgdHdvIGRpZmZlcmVudCB0eXBlcyBvZiBj b25mZXJlbmNpbmcgY291bGQgYXBwbHkgYnkgcGxhY2luZyB0aGUgcmVsZXZhbnQgdGVybWluYXRp b25zIGluIHRoZSBzYW1lIG9yIGRpZmZlcmVudCBjb250ZXh0cy48L0ZPTlQ+PC9QPg0KDQo8UD48 Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkluIGNhc2Ugb2YgaW1wbGVtZW50aW5nIGNvbmZlcmVu Y2VzIHVzaW5nIGRpZmZlcmVudCBjb250ZXh0cywgd2hpY2ggY29ubmVjdGlvbiBtb2RlbCBzaG91 bGQgYXBwbHkgPzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPjEuKSBmb3Ig ZWFjaCBjb25mZXJlZSBhbiBvd24gY29udGV4dCBhcyBzaG93biBhdCBleGFtcGxlIKc5IGRyYWZ0 LWlldGYtbWVnYWNvLWNhbGxmbG93cy0wMi50eHQ/PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBG QUNFPSJBcmlhbCI+Mi4pIHNlcGFyYXRpb24gaW50byBhIGNlbnRyYWwgY29uZmVyZW5jZSBjb250 ZXh0IGFuZCBmb3IgZWFjaCBjb25mZXJlZSBhbiBvd24sIGxldHMgc2F5LCBjYWxsIGxlZyBjb250 ZXh0PzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPjMuKSBvciBhcmUgYm90 aCBsaXN0ZWQgY29ubmVjdGlvbiBtb2RlbHMgbWVhbmluZ2Z1bCA/PC9GT05UPg0KPC9QPg0KDQo8 UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlRoZSBzZWNvbmQgYXBwcm9hY2ggd2FzIGRpc2N1 c3NlZCBtYW55IHRpbWVzIGluIHRoZSBsaXN0LCBidXQgdGhlcmUgd2FzIG5ldmVyIGEgZmluYWwg YW5kIGNsZWFyIHN0YXRlbWVudCwgbWF5IGJlIHRoZXJlIGNvdWxkIGJlIG9uZSBiZWZvcmUgZmlu YWxpemluZyBIMjQ4LjE5LjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlh bCI+VGhhbmtzIGluIGFkdmFuY2U8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFs Ij5GcmFuejwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg== ------_=_NextPart_001_01C32F49.FD4B6280-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jun 10 08:21:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23189 for ; Tue, 10 Jun 2003 08:21:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5ACLSg15514 for megaco-archive@odin.ietf.org; Tue, 10 Jun 2003 08:21:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACLSB15511 for ; Tue, 10 Jun 2003 08:21:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23177 for ; Tue, 10 Jun 2003 08:21:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pi5z-0004Lg-00 for megaco-web-archive@ietf.org; Tue, 10 Jun 2003 08:19:23 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Pi5z-0004Ld-00 for megaco-web-archive@ietf.org; Tue, 10 Jun 2003 08:19:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACJFB15385; Tue, 10 Jun 2003 08:19:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACHBB15307 for ; Tue, 10 Jun 2003 08:17:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22998 for ; Tue, 10 Jun 2003 08:17:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pi1q-0004J0-00 for megaco@ietf.org; Tue, 10 Jun 2003 08:15:06 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 19Pi1p-0004IJ-00 for megaco@ietf.org; Tue, 10 Jun 2003 08:15:05 -0400 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h5ACG3dp030186 for ; Tue, 10 Jun 2003 14:16:04 +0200 Received: from vies194a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h5ACG1oE011661 for ; Tue, 10 Jun 2003 14:16:02 +0200 (MET DST) Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jun 2003 14:16:01 +0200 Message-ID: From: Kalleitner Franz To: Megaco List Date: Tue, 10 Jun 2003 14:15:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32F49.FD4B6280" Subject: [Megaco] correct connection model for conferencing according darft H.248.1 9 Sender: megaco-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_01C32F49.FD4B6280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello megaco-list-members In the past, many threats were discussing about conferencing. However = SG16 started to summarized this topic in the draft H.248.19 (BTW: Thanks a = lot for that work), but the connection model is still not clear to me. As documented in H.248.19 =A75 (conferencing architectures) it is = mentioned that according H.248 =A76 two different types of conferencing could = apply by placing the relevant terminations in the same or different contexts. In case of implementing conferences using different contexts, which connection model should apply ? 1.) for each conferee an own context as shown at example =A79 draft-ietf-megaco-callflows-02.txt? 2.) separation into a central conference context and for each conferee = an own, lets say, call leg context? 3.) or are both listed connection models meaningful ? The second approach was discussed many times in the list, but there was never a final and clear statement, may be there could be one before finalizing H248.19. Thanks in advance Franz ------_=_NextPart_001_01C32F49.FD4B6280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+Y29ycmVj dCBjb25uZWN0aW9uIG1vZGVsIGZvciBjb25mZXJlbmNpbmcgYWNjb3JkaW5nIGRhcmZ0IEguMjQ4 LjE5PC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp YWwiPkhlbGxvIG1lZ2Fjby1saXN0LW1lbWJlcnM8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJ WkU9MiBGQUNFPSJBcmlhbCI+SW4gdGhlIHBhc3QsIG1hbnkgdGhyZWF0cyB3ZXJlIGRpc2N1c3Np bmcgYWJvdXQgY29uZmVyZW5jaW5nLiBIb3dldmVyIFNHMTYgc3RhcnRlZCB0byBzdW1tYXJpemVk IHRoaXMgdG9waWMgaW4gdGhlIGRyYWZ0IEguMjQ4LjE5IChCVFc6IFRoYW5rcyBhIGxvdCBmb3Ig dGhhdCB3b3JrKSwgYnV0IHRoZSBjb25uZWN0aW9uIG1vZGVsIGlzIHN0aWxsIG5vdCBjbGVhciB0 byBtZS48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkFzIGRvY3Vt ZW50ZWQgaW4gSC4yNDguMTkgpzUgKGNvbmZlcmVuY2luZyBhcmNoaXRlY3R1cmVzKSBpdCBpcyBt ZW50aW9uZWQgdGhhdCBhY2NvcmRpbmcgSC4yNDggpzYgdHdvIGRpZmZlcmVudCB0eXBlcyBvZiBj b25mZXJlbmNpbmcgY291bGQgYXBwbHkgYnkgcGxhY2luZyB0aGUgcmVsZXZhbnQgdGVybWluYXRp b25zIGluIHRoZSBzYW1lIG9yIGRpZmZlcmVudCBjb250ZXh0cy48L0ZPTlQ+PC9QPg0KDQo8UD48 Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkluIGNhc2Ugb2YgaW1wbGVtZW50aW5nIGNvbmZlcmVu Y2VzIHVzaW5nIGRpZmZlcmVudCBjb250ZXh0cywgd2hpY2ggY29ubmVjdGlvbiBtb2RlbCBzaG91 bGQgYXBwbHkgPzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPjEuKSBmb3Ig ZWFjaCBjb25mZXJlZSBhbiBvd24gY29udGV4dCBhcyBzaG93biBhdCBleGFtcGxlIKc5IGRyYWZ0 LWlldGYtbWVnYWNvLWNhbGxmbG93cy0wMi50eHQ/PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBG QUNFPSJBcmlhbCI+Mi4pIHNlcGFyYXRpb24gaW50byBhIGNlbnRyYWwgY29uZmVyZW5jZSBjb250 ZXh0IGFuZCBmb3IgZWFjaCBjb25mZXJlZSBhbiBvd24sIGxldHMgc2F5LCBjYWxsIGxlZyBjb250 ZXh0PzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPjMuKSBvciBhcmUgYm90 aCBsaXN0ZWQgY29ubmVjdGlvbiBtb2RlbHMgbWVhbmluZ2Z1bCA/PC9GT05UPg0KPC9QPg0KDQo8 UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlRoZSBzZWNvbmQgYXBwcm9hY2ggd2FzIGRpc2N1 c3NlZCBtYW55IHRpbWVzIGluIHRoZSBsaXN0LCBidXQgdGhlcmUgd2FzIG5ldmVyIGEgZmluYWwg YW5kIGNsZWFyIHN0YXRlbWVudCwgbWF5IGJlIHRoZXJlIGNvdWxkIGJlIG9uZSBiZWZvcmUgZmlu YWxpemluZyBIMjQ4LjE5LjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlh bCI+VGhhbmtzIGluIGFkdmFuY2U8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFs Ij5GcmFuejwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg== ------_=_NextPart_001_01C32F49.FD4B6280-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jun 10 08:40:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24696 for ; Tue, 10 Jun 2003 08:40:24 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACcQB17561; Tue, 10 Jun 2003 08:38:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACbkB17503 for ; Tue, 10 Jun 2003 08:37:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24457 for ; Tue, 10 Jun 2003 08:37:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PiLk-0004hX-00 for megaco@ietf.org; Tue, 10 Jun 2003 08:35:40 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19PiLj-0004gZ-00 for megaco@ietf.org; Tue, 10 Jun 2003 08:35:39 -0400 Received: from zcard307.ca.nortel.com (americasm07.nt.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5ACXGA24143; Tue, 10 Jun 2003 08:33:16 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MLYHWCLX; Tue, 10 Jun 2003 08:33:16 -0400 Received: from nortelnetworks.com (acart1dn.ca.nortel.com [47.129.129.97]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0SBZ; Tue, 10 Jun 2003 08:33:17 -0400 Message-ID: <3EE5D009.2060508@nortelnetworks.com> Date: Tue, 10 Jun 2003 08:33:13 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: "H.S.Sureshchandra" CC: Simran Chadha , Megaco List Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote Descriptors! References: <20030204052156.14303.qmail@webmail28.rediffmail.com> <3E400D7B.8080102@nortelnetworks.com> <02b001c32f12$b2f9d4a0$e601a8c0@sureshchandra> In-Reply-To: <02b001c32f12$b2f9d4a0$e601a8c0@sureshchandra> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit My apologies -- I failed to keep this somewhwere where I would remember it when the time came. The ridiculous part is that the "authors' 48 hours" actually lasted a full month due to other delays. We can do two things now: record the corrections in the Implementor's Guide, and register them as errata against the RFC with the RFC Editor. I'll work on that today. H.S.Sureshchandra wrote: > Hello Tom, > > I do not see incorporation of any of the observations made by my colleague > Simran Chadha in the new RFC 3525, as "promised" by you in your earlier > mail. > > Please clarify. Thanks ! > > Suresh > > > ----- Original Message ----- > From: "Tom Taylor" > To: "Simran Chadha" > Cc: "Megaco List" > Sent: Wednesday, February 05, 2003 12:29 AM > Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote > Descriptors! > > > >>That "cannot not" is a typo -- I'll remove the "not" during the "authors' > > 48 hours" > >>interval prior to formal publication as a new RFC. >> >>On your second point: the two paragraphs apply independently to > > ReserveGroup and > >>ReserveValue. That is, it is possible to have ReserveGroup TRUE and > > ReserveValue > >>FALSE -- in which case the MG reserves for multiple session descriptions > > but is > >>restricted to one codec in each -- or vice versa. Or both could be TRUE, > > or both FALSE. > >>On the third point, the intended meaning would be conveyed by replacing > > "if it > >>cannot support any of the alternatives" with "if it can support none of > > the > >>alternatives". Perhaps I can also do that during the "authors' 48 hours" > > period, > >>though we would usually do it through the ITU-T Implementor's Guide. >> >>The task of developing an unambiguous protocol specification is not > > simple. Your > >>points have eluded others in the three years since first approval. Thank > > you for > >>your contribution. >> >>Simran Chadha wrote: >> >>>Hi List, >>> >>>Can someone please help me at the earliest on the issues raised earlier >>>by me - particularly, usage of LocalControl,Local and Remote Descriptors > > ? > >>>Thanks in advance. >>> >>>Simran Chadha >>>On Thu, 30 Jan 2003 Simran Chadha wrote : >>> >>> >>>>Hi List, >>>> >>>>Can you please help me with clarifications in my understanding of >>>>sections 7.1.7 and 7.1.8 on the use of LocalControl,Local and Remote >>>>Descriptors. >>>> >>>>As per draft-ietf-megaco-3015corr-03, in section 7.1.7, >>>>If the value of a Reserve property is True, the MG SHALL reserve >>>>resources for all alternatives specified in the Local and/or Remote >>>>descriptors for which it currently has resources available. It SHALL >>>>respond with the alternatives for which it reserves resources. If it >>>>cannot not support any of the alternatives, it SHALL respond with a >>>>reply to the MGC that contains empty Local and/or Remote descriptors. >>>>The use of two negations - "cannot not" in the last statement will >>>>imply that - If it can support any of the alternatives, it SHALL >>>>respond with a reply to the MGC that contains empty Local and/or >>>>Remote descriptors. >>>>I don't think this is what is meant to be conveyed here. >>>> >>>>Also in section 7.1.7 the first para starts - If the value of a >>>>Reserve property is True, ..... >>>>while the second para starts - If the value of a Reserve property is >>>>False, .... >>>>Now as there are two Reserve properties - one Reserve Group and the >>>>other Reserve Value, One could be False and the other could be True. >>>>Then in this case what will be the inference - Should para 1 apply or >>>>para 2 ? Both the paras would seem to be mutually exclusive in what is >>>>needed to be done. >>>> >>>>Also statements like "if it cannot support any of the alternatives ... >>>>" - will have two meanings. >>>>1. Any - Not even one - NONE of the alternatives is supported. >>>>2. Any - Atleast one - While a few alternatives can be supported, a >>>>few might not be. >>>> >>>>The protocol needs to be more clear on such aspects in the documents >>>>henceforth. The English language is understood in different parts of >>>>the world. Variations to agreed usage of the language terms will make >>>>it difficult for new users of Megaco protocol, like me. >>>> >>>>Can someone please educate me on the exact usage and meaning of >>>>LocalControl,Local and Remote Descriptors ? >>>> >>>>Thanks and awaiting comments and clarifications >>>> >>>>Simran Chadha >>> >>> >>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jun 10 08:42:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25004 for ; Tue, 10 Jun 2003 08:42:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5ACg6B17842 for megaco-archive@odin.ietf.org; Tue, 10 Jun 2003 08:42:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACg3B17839 for ; Tue, 10 Jun 2003 08:42:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24934 for ; Tue, 10 Jun 2003 08:42:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PiPu-0004qe-00 for megaco-web-archive@ietf.org; Tue, 10 Jun 2003 08:39:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PiPt-0004qH-00 for megaco-web-archive@ietf.org; Tue, 10 Jun 2003 08:39:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACcQB17561; Tue, 10 Jun 2003 08:38:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACbkB17503 for ; Tue, 10 Jun 2003 08:37:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24457 for ; Tue, 10 Jun 2003 08:37:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PiLk-0004hX-00 for megaco@ietf.org; Tue, 10 Jun 2003 08:35:40 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19PiLj-0004gZ-00 for megaco@ietf.org; Tue, 10 Jun 2003 08:35:39 -0400 Received: from zcard307.ca.nortel.com (americasm07.nt.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5ACXGA24143; Tue, 10 Jun 2003 08:33:16 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MLYHWCLX; Tue, 10 Jun 2003 08:33:16 -0400 Received: from nortelnetworks.com (acart1dn.ca.nortel.com [47.129.129.97]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0SBZ; Tue, 10 Jun 2003 08:33:17 -0400 Message-ID: <3EE5D009.2060508@nortelnetworks.com> Date: Tue, 10 Jun 2003 08:33:13 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: "H.S.Sureshchandra" CC: Simran Chadha , Megaco List Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote Descriptors! References: <20030204052156.14303.qmail@webmail28.rediffmail.com> <3E400D7B.8080102@nortelnetworks.com> <02b001c32f12$b2f9d4a0$e601a8c0@sureshchandra> In-Reply-To: <02b001c32f12$b2f9d4a0$e601a8c0@sureshchandra> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit My apologies -- I failed to keep this somewhwere where I would remember it when the time came. The ridiculous part is that the "authors' 48 hours" actually lasted a full month due to other delays. We can do two things now: record the corrections in the Implementor's Guide, and register them as errata against the RFC with the RFC Editor. I'll work on that today. H.S.Sureshchandra wrote: > Hello Tom, > > I do not see incorporation of any of the observations made by my colleague > Simran Chadha in the new RFC 3525, as "promised" by you in your earlier > mail. > > Please clarify. Thanks ! > > Suresh > > > ----- Original Message ----- > From: "Tom Taylor" > To: "Simran Chadha" > Cc: "Megaco List" > Sent: Wednesday, February 05, 2003 12:29 AM > Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote > Descriptors! > > > >>That "cannot not" is a typo -- I'll remove the "not" during the "authors' > > 48 hours" > >>interval prior to formal publication as a new RFC. >> >>On your second point: the two paragraphs apply independently to > > ReserveGroup and > >>ReserveValue. That is, it is possible to have ReserveGroup TRUE and > > ReserveValue > >>FALSE -- in which case the MG reserves for multiple session descriptions > > but is > >>restricted to one codec in each -- or vice versa. Or both could be TRUE, > > or both FALSE. > >>On the third point, the intended meaning would be conveyed by replacing > > "if it > >>cannot support any of the alternatives" with "if it can support none of > > the > >>alternatives". Perhaps I can also do that during the "authors' 48 hours" > > period, > >>though we would usually do it through the ITU-T Implementor's Guide. >> >>The task of developing an unambiguous protocol specification is not > > simple. Your > >>points have eluded others in the three years since first approval. Thank > > you for > >>your contribution. >> >>Simran Chadha wrote: >> >>>Hi List, >>> >>>Can someone please help me at the earliest on the issues raised earlier >>>by me - particularly, usage of LocalControl,Local and Remote Descriptors > > ? > >>>Thanks in advance. >>> >>>Simran Chadha >>>On Thu, 30 Jan 2003 Simran Chadha wrote : >>> >>> >>>>Hi List, >>>> >>>>Can you please help me with clarifications in my understanding of >>>>sections 7.1.7 and 7.1.8 on the use of LocalControl,Local and Remote >>>>Descriptors. >>>> >>>>As per draft-ietf-megaco-3015corr-03, in section 7.1.7, >>>>If the value of a Reserve property is True, the MG SHALL reserve >>>>resources for all alternatives specified in the Local and/or Remote >>>>descriptors for which it currently has resources available. It SHALL >>>>respond with the alternatives for which it reserves resources. If it >>>>cannot not support any of the alternatives, it SHALL respond with a >>>>reply to the MGC that contains empty Local and/or Remote descriptors. >>>>The use of two negations - "cannot not" in the last statement will >>>>imply that - If it can support any of the alternatives, it SHALL >>>>respond with a reply to the MGC that contains empty Local and/or >>>>Remote descriptors. >>>>I don't think this is what is meant to be conveyed here. >>>> >>>>Also in section 7.1.7 the first para starts - If the value of a >>>>Reserve property is True, ..... >>>>while the second para starts - If the value of a Reserve property is >>>>False, .... >>>>Now as there are two Reserve properties - one Reserve Group and the >>>>other Reserve Value, One could be False and the other could be True. >>>>Then in this case what will be the inference - Should para 1 apply or >>>>para 2 ? Both the paras would seem to be mutually exclusive in what is >>>>needed to be done. >>>> >>>>Also statements like "if it cannot support any of the alternatives ... >>>>" - will have two meanings. >>>>1. Any - Not even one - NONE of the alternatives is supported. >>>>2. Any - Atleast one - While a few alternatives can be supported, a >>>>few might not be. >>>> >>>>The protocol needs to be more clear on such aspects in the documents >>>>henceforth. The English language is understood in different parts of >>>>the world. Variations to agreed usage of the language terms will make >>>>it difficult for new users of Megaco protocol, like me. >>>> >>>>Can someone please educate me on the exact usage and meaning of >>>>LocalControl,Local and Remote Descriptors ? >>>> >>>>Thanks and awaiting comments and clarifications >>>> >>>>Simran Chadha >>> >>> >>> >>>_______________________________________________ >>>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 Jun 10 08:59:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26563 for ; Tue, 10 Jun 2003 08:58:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACudB18543; Tue, 10 Jun 2003 08:56:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACtqB18491 for ; Tue, 10 Jun 2003 08:55:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26400 for ; Tue, 10 Jun 2003 08:55:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PidG-0005JE-00 for megaco@ietf.org; Tue, 10 Jun 2003 08:53:46 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 19PidF-0005IW-00 for megaco@ietf.org; Tue, 10 Jun 2003 08:53:45 -0400 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 h5ACtB724726 for ; Tue, 10 Jun 2003 08:55:11 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jun 2003 08:55:11 -0400 Message-ID: From: "Kevin Boyle" To: "Tom-PT Taylor" , "H.S.Sureshchandra" Cc: Simran Chadha , Megaco List Subject: RE: [Megaco] Re: Usage of LocalControl,Local and Remote Descripto rs! Date: Tue, 10 Jun 2003 08:55:11 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , If the concerns pointed out exist in H.248.1 v1 (03/2002), then any corrections belong in the IG. The intent of the RFC is to produce identical text to the ITU-T Recommendation as much as possible, correct? Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Tuesday, June 10, 2003 8:33 AM To: H.S.Sureshchandra Cc: Simran Chadha; Megaco List Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote Descriptors! My apologies -- I failed to keep this somewhwere where I would remember it when the time came. The ridiculous part is that the "authors' 48 hours" actually lasted a full month due to other delays. We can do two things now: record the corrections in the Implementor's Guide, and register them as errata against the RFC with the RFC Editor. I'll work on that today. H.S.Sureshchandra wrote: > Hello Tom, > > I do not see incorporation of any of the observations made by my > colleague Simran Chadha in the new RFC 3525, as "promised" by you in > your earlier mail. > > Please clarify. Thanks ! > > Suresh > > > ----- Original Message ----- > From: "Tom Taylor" > To: "Simran Chadha" > Cc: "Megaco List" > Sent: Wednesday, February 05, 2003 12:29 AM > Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote > Descriptors! > > > >>That "cannot not" is a typo -- I'll remove the "not" during the >>"authors' > > 48 hours" > >>interval prior to formal publication as a new RFC. >> >>On your second point: the two paragraphs apply independently to > > ReserveGroup and > >>ReserveValue. That is, it is possible to have ReserveGroup TRUE and > > ReserveValue > >>FALSE -- in which case the MG reserves for multiple session >>descriptions > > but is > >>restricted to one codec in each -- or vice versa. Or both could be >>TRUE, > > or both FALSE. > >>On the third point, the intended meaning would be conveyed by >>replacing > > "if it > >>cannot support any of the alternatives" with "if it can support none >>of > > the > >>alternatives". Perhaps I can also do that during the "authors' 48 >>hours" > > period, > >>though we would usually do it through the ITU-T Implementor's Guide. >> >>The task of developing an unambiguous protocol specification is not > > simple. Your > >>points have eluded others in the three years since first approval. >>Thank > > you for > >>your contribution. >> >>Simran Chadha wrote: >> >>>Hi List, >>> >>>Can someone please help me at the earliest on the issues raised >>>earlier by me - particularly, usage of LocalControl,Local and Remote >>>Descriptors > > ? > >>>Thanks in advance. >>> >>>Simran Chadha >>>On Thu, 30 Jan 2003 Simran Chadha wrote : >>> >>> >>>>Hi List, >>>> >>>>Can you please help me with clarifications in my understanding of >>>>sections 7.1.7 and 7.1.8 on the use of LocalControl,Local and Remote >>>>Descriptors. >>>> >>>>As per draft-ietf-megaco-3015corr-03, in section 7.1.7, >>>>If the value of a Reserve property is True, the MG SHALL reserve >>>>resources for all alternatives specified in the Local and/or Remote >>>>descriptors for which it currently has resources available. It SHALL >>>>respond with the alternatives for which it reserves resources. If it >>>>cannot not support any of the alternatives, it SHALL respond with a >>>>reply to the MGC that contains empty Local and/or Remote >>>>descriptors. The use of two negations - "cannot not" in the last >>>>statement will imply that - If it can support any of the >>>>alternatives, it SHALL respond with a reply to the MGC that contains >>>>empty Local and/or Remote descriptors. I don't think this is what is >>>>meant to be conveyed here. >>>> >>>>Also in section 7.1.7 the first para starts - If the value of a >>>>Reserve property is True, ..... while the second para starts - If >>>>the value of a Reserve property is False, .... >>>>Now as there are two Reserve properties - one Reserve Group and the >>>>other Reserve Value, One could be False and the other could be True. >>>>Then in this case what will be the inference - Should para 1 apply or >>>>para 2 ? Both the paras would seem to be mutually exclusive in what is >>>>needed to be done. >>>> >>>>Also statements like "if it cannot support any of the alternatives >>>>... " - will have two meanings. 1. Any - Not even one - NONE of the >>>>alternatives is supported. >>>>2. Any - Atleast one - While a few alternatives can be supported, a >>>>few might not be. >>>> >>>>The protocol needs to be more clear on such aspects in the documents >>>>henceforth. The English language is understood in different parts of >>>>the world. Variations to agreed usage of the language terms will >>>>make it difficult for new users of Megaco protocol, like me. >>>> >>>>Can someone please educate me on the exact usage and meaning of >>>>LocalControl,Local and Remote Descriptors ? >>>> >>>>Thanks and awaiting comments and clarifications >>>> >>>>Simran Chadha >>> >>> >>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco >>> >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jun 10 09:00:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26737 for ; Tue, 10 Jun 2003 09:00:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5ACxrU18708 for megaco-archive@odin.ietf.org; Tue, 10 Jun 2003 08:59:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACxrB18705 for ; Tue, 10 Jun 2003 08:59:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26664 for ; Tue, 10 Jun 2003 08:59:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pih9-0005Ob-00 for megaco-web-archive@ietf.org; Tue, 10 Jun 2003 08:57:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Pih9-0005OY-00 for megaco-web-archive@ietf.org; Tue, 10 Jun 2003 08:57:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACudB18543; Tue, 10 Jun 2003 08:56:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACtqB18491 for ; Tue, 10 Jun 2003 08:55:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26400 for ; Tue, 10 Jun 2003 08:55:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PidG-0005JE-00 for megaco@ietf.org; Tue, 10 Jun 2003 08:53:46 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 19PidF-0005IW-00 for megaco@ietf.org; Tue, 10 Jun 2003 08:53:45 -0400 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 h5ACtB724726 for ; Tue, 10 Jun 2003 08:55:11 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jun 2003 08:55:11 -0400 Message-ID: From: "Kevin Boyle" To: "Tom-PT Taylor" , "H.S.Sureshchandra" Cc: Simran Chadha , Megaco List Subject: RE: [Megaco] Re: Usage of LocalControl,Local and Remote Descripto rs! Date: Tue, 10 Jun 2003 08:55:11 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , If the concerns pointed out exist in H.248.1 v1 (03/2002), then any corrections belong in the IG. The intent of the RFC is to produce identical text to the ITU-T Recommendation as much as possible, correct? Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Tuesday, June 10, 2003 8:33 AM To: H.S.Sureshchandra Cc: Simran Chadha; Megaco List Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote Descriptors! My apologies -- I failed to keep this somewhwere where I would remember it when the time came. The ridiculous part is that the "authors' 48 hours" actually lasted a full month due to other delays. We can do two things now: record the corrections in the Implementor's Guide, and register them as errata against the RFC with the RFC Editor. I'll work on that today. H.S.Sureshchandra wrote: > Hello Tom, > > I do not see incorporation of any of the observations made by my > colleague Simran Chadha in the new RFC 3525, as "promised" by you in > your earlier mail. > > Please clarify. Thanks ! > > Suresh > > > ----- Original Message ----- > From: "Tom Taylor" > To: "Simran Chadha" > Cc: "Megaco List" > Sent: Wednesday, February 05, 2003 12:29 AM > Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote > Descriptors! > > > >>That "cannot not" is a typo -- I'll remove the "not" during the >>"authors' > > 48 hours" > >>interval prior to formal publication as a new RFC. >> >>On your second point: the two paragraphs apply independently to > > ReserveGroup and > >>ReserveValue. That is, it is possible to have ReserveGroup TRUE and > > ReserveValue > >>FALSE -- in which case the MG reserves for multiple session >>descriptions > > but is > >>restricted to one codec in each -- or vice versa. Or both could be >>TRUE, > > or both FALSE. > >>On the third point, the intended meaning would be conveyed by >>replacing > > "if it > >>cannot support any of the alternatives" with "if it can support none >>of > > the > >>alternatives". Perhaps I can also do that during the "authors' 48 >>hours" > > period, > >>though we would usually do it through the ITU-T Implementor's Guide. >> >>The task of developing an unambiguous protocol specification is not > > simple. Your > >>points have eluded others in the three years since first approval. >>Thank > > you for > >>your contribution. >> >>Simran Chadha wrote: >> >>>Hi List, >>> >>>Can someone please help me at the earliest on the issues raised >>>earlier by me - particularly, usage of LocalControl,Local and Remote >>>Descriptors > > ? > >>>Thanks in advance. >>> >>>Simran Chadha >>>On Thu, 30 Jan 2003 Simran Chadha wrote : >>> >>> >>>>Hi List, >>>> >>>>Can you please help me with clarifications in my understanding of >>>>sections 7.1.7 and 7.1.8 on the use of LocalControl,Local and Remote >>>>Descriptors. >>>> >>>>As per draft-ietf-megaco-3015corr-03, in section 7.1.7, >>>>If the value of a Reserve property is True, the MG SHALL reserve >>>>resources for all alternatives specified in the Local and/or Remote >>>>descriptors for which it currently has resources available. It SHALL >>>>respond with the alternatives for which it reserves resources. If it >>>>cannot not support any of the alternatives, it SHALL respond with a >>>>reply to the MGC that contains empty Local and/or Remote >>>>descriptors. The use of two negations - "cannot not" in the last >>>>statement will imply that - If it can support any of the >>>>alternatives, it SHALL respond with a reply to the MGC that contains >>>>empty Local and/or Remote descriptors. I don't think this is what is >>>>meant to be conveyed here. >>>> >>>>Also in section 7.1.7 the first para starts - If the value of a >>>>Reserve property is True, ..... while the second para starts - If >>>>the value of a Reserve property is False, .... >>>>Now as there are two Reserve properties - one Reserve Group and the >>>>other Reserve Value, One could be False and the other could be True. >>>>Then in this case what will be the inference - Should para 1 apply or >>>>para 2 ? Both the paras would seem to be mutually exclusive in what is >>>>needed to be done. >>>> >>>>Also statements like "if it cannot support any of the alternatives >>>>... " - will have two meanings. 1. Any - Not even one - NONE of the >>>>alternatives is supported. >>>>2. Any - Atleast one - While a few alternatives can be supported, a >>>>few might not be. >>>> >>>>The protocol needs to be more clear on such aspects in the documents >>>>henceforth. The English language is understood in different parts of >>>>the world. Variations to agreed usage of the language terms will >>>>make it difficult for new users of Megaco protocol, like me. >>>> >>>>Can someone please educate me on the exact usage and meaning of >>>>LocalControl,Local and Remote Descriptors ? >>>> >>>>Thanks and awaiting comments and clarifications >>>> >>>>Simran Chadha >>> >>> >>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco >>> >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jun 10 14:50:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12357 for ; Tue, 10 Jun 2003 14:50:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AInXB16740; Tue, 10 Jun 2003 14:49:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AIljB16661 for ; Tue, 10 Jun 2003 14:47:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12236 for ; Tue, 10 Jun 2003 14:47:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Po7k-0001HN-00 for megaco@ietf.org; Tue, 10 Jun 2003 14:45:36 -0400 Received: from tnt.isi.edu ([128.9.128.128]) by ietf-mx with esmtp (Exim 4.12) id 19Po7j-0001HK-00 for megaco@ietf.org; Tue, 10 Jun 2003 14:45:36 -0400 Received: from jet.isi.edu (jet.isi.edu [128.9.160.87]) by tnt.isi.edu (8.11.6p2/8.11.2) with ESMTP id h5AIlVi14137; Tue, 10 Jun 2003 11:47:31 -0700 (PDT) Received: (from rfc-ed@localhost) by jet.isi.edu (8.9.3/8.8.6) id LAA01141; Tue, 10 Jun 2003 11:47:31 -0700 (PDT) Date: Tue, 10 Jun 2003 11:47:31 -0700 From: RFC Editor To: Pellegrino Jose Luis , megaco@ietf.org Cc: Allison Mankin , Jon Peterson Subject: Re: [Megaco] RFC 3525 on Gateway Control Protocol Version 1 Message-ID: <20030610184731.GD785@isi.edu> References: <6BB2DEB822D3D111817B00805FBE5F0215181EDF@mstelefonica6.sote.tasa.com.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline In-Reply-To: <6BB2DEB822D3D111817B00805FBE5F0215181EDF@mstelefonica6.sote.tasa.com.ar> User-Agent: Mutt/1.4i X-MIME-Autoconverted: from 8bit to quoted-printable by tnt.isi.edu id h5AIlVi14137 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5AIljB16662 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Jose Luis, We are going to have to request that the Working Group and/or Area Directors answer this question for you. We are not in a position to provide this information. Thank you. RFC Editor On Mon, Jun 09, 2003 at 03:20:47PM -0300, Pellegrino Jose Luis wrote: > What about draft-MEGACO version 2 published during last april? > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Media Gateway Control Working Group of the > IETF. > > Title : The Megaco/H.248v2 Gateway Control Protocol, > version 2 > Author(s) : C. Groves, M. Pantaleo et al. > Filename : draft-ietf-megaco-h248v2-04.txt > Pages : 219 > Date : 2003-4-3 > > Does the new RFC 3525 reeplaces this draft. Notice that this draft expires > on next october. > If this draft is still alive, does it mean that it will became on a new > RFCXXXX in the future? If so, that RFCXXXX will obsolete the RFC3525, will > not it? > Jose Luis, > > > > -----Mensaje original----- > > De: rfc-editor@rfc-editor.org [SMTP:rfc-editor@rfc-editor.org] > > Enviado el: Lunes 9 de Junio de 2003 13:59 > > CC: rfc-editor@rfc-editor.org; megaco@ietf.org > > Asunto: [Megaco] RFC 3525 on Gateway Control Protocol Version 1 > > > > > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 3525 > > > > Title: Gateway Control Protocol Version 1 > > Author(s): C. Groves, M. Pantaleo, T. Anderson, T. Taylor, > > Editors > > Status: Standards Track > > Date: June 2003 > > Mailbox: Christian.Groves@ericsson.com.au, > > Marcello.Pantaleo@eed.ericsson.se, > > tlatla@verizon.net, > > taylor@nortelnetworks.com > > Pages: 213 > > Characters: 439674 > > Obsoletes: 3015 > > > > I-D Tag: draft-ietf-megaco-3015corr-03.txt > > > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3525.txt > > > > > > This document defines the protocol used between elements of a > > physically decomposed multimedia gateway, i.e., a Media Gateway and a > > Media Gateway Controller. The protocol presented in this document > > meets the requirements for a media gateway control protocol as > > presented in RFC 2805. > > > > This document replaces RFC 3015. It is the result of > > continued cooperation between the IETF Megaco Working Group and ITU-T > > Study Group 16. It incorporates the original text of RFC 3015, > > modified by corrections and clarifications discussed on the Megaco > > > > E-mail list and incorporated into the Study Group 16 Implementor's > > Guide for Recommendation H.248. The present version of this document > > underwent ITU-T Last Call as Recommendation H.248 Amendment 1. > > Because of ITU-T renumbering, it was published by the ITU-T as > > Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. > > > > Users of this specification are advised to consult the H.248 > > Sub-series Implementors' Guide at > > http://www.itu.int/itudoc/itu-t/com16/implgd for additional > > corrections and clarifications. > > > > This document is a product of the Media Gateway Control Working Group > > of the IETF. > > > > This is now a Proposed Standard Protocol. > > > > This document specifies an Internet standards track protocol for > > the Internet community, and requests discussion and suggestions > > for improvements. Please refer to the current edition of the > > "Internet Official Protocol Standards" (STD 1) for the > > standardization state and status of this protocol. Distribution > > of this memo is unlimited. > > > > This announcement is sent to the IETF list and the RFC-DIST list. > > Requests to be added to or deleted from the IETF distribution list > > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > > added to or deleted from the RFC-DIST distribution list should > > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > > help: ways_to_get_rfcs. For example: > > > > To: rfc-info@RFC-EDITOR.ORG > > Subject: getting rfcs > > > > help: ways_to_get_rfcs > > > > Requests for special distribution should be addressed to either the > > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > > specifically noted otherwise on the RFC itself, all RFCs are for > > unlimited distribution.echo > > Submissions for Requests for Comments should be sent to > > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > > Authors, for further information. > > > > > > Joyce K. Reynolds and Sandy Ginoza > > USC/Information Sciences Institute > > > > ... > > > > Below is the data which will enable a MIME compliant Mail Reader > > implementation to automatically retrieve the ASCII version > > of the RFCs. <> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jun 10 14:52:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12426 for ; Tue, 10 Jun 2003 14:52:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AIpc916836 for megaco-archive@odin.ietf.org; Tue, 10 Jun 2003 14:51:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AIpbB16833 for ; Tue, 10 Jun 2003 14:51:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12406 for ; Tue, 10 Jun 2003 14:51:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PoBV-0001Jr-00 for megaco-web-archive@ietf.org; Tue, 10 Jun 2003 14:49:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PoBU-0001Jn-00 for megaco-web-archive@ietf.org; Tue, 10 Jun 2003 14:49:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AInXB16740; Tue, 10 Jun 2003 14:49:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AIljB16661 for ; Tue, 10 Jun 2003 14:47:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12236 for ; Tue, 10 Jun 2003 14:47:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Po7k-0001HN-00 for megaco@ietf.org; Tue, 10 Jun 2003 14:45:36 -0400 Received: from tnt.isi.edu ([128.9.128.128]) by ietf-mx with esmtp (Exim 4.12) id 19Po7j-0001HK-00 for megaco@ietf.org; Tue, 10 Jun 2003 14:45:36 -0400 Received: from jet.isi.edu (jet.isi.edu [128.9.160.87]) by tnt.isi.edu (8.11.6p2/8.11.2) with ESMTP id h5AIlVi14137; Tue, 10 Jun 2003 11:47:31 -0700 (PDT) Received: (from rfc-ed@localhost) by jet.isi.edu (8.9.3/8.8.6) id LAA01141; Tue, 10 Jun 2003 11:47:31 -0700 (PDT) Date: Tue, 10 Jun 2003 11:47:31 -0700 From: RFC Editor To: Pellegrino Jose Luis , megaco@ietf.org Cc: Allison Mankin , Jon Peterson Subject: Re: [Megaco] RFC 3525 on Gateway Control Protocol Version 1 Message-ID: <20030610184731.GD785@isi.edu> References: <6BB2DEB822D3D111817B00805FBE5F0215181EDF@mstelefonica6.sote.tasa.com.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline In-Reply-To: <6BB2DEB822D3D111817B00805FBE5F0215181EDF@mstelefonica6.sote.tasa.com.ar> User-Agent: Mutt/1.4i X-MIME-Autoconverted: from 8bit to quoted-printable by tnt.isi.edu id h5AIlVi14137 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5AIljB16662 Sender: megaco-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-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5AInXB16740 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5AIpbB16833 Content-Transfer-Encoding: 8bit Jose Luis, We are going to have to request that the Working Group and/or Area Directors answer this question for you. We are not in a position to provide this information. Thank you. RFC Editor On Mon, Jun 09, 2003 at 03:20:47PM -0300, Pellegrino Jose Luis wrote: > What about draft-MEGACO version 2 published during last april? > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Media Gateway Control Working Group of the > IETF. > > Title : The Megaco/H.248v2 Gateway Control Protocol, > version 2 > Author(s) : C. Groves, M. Pantaleo et al. > Filename : draft-ietf-megaco-h248v2-04.txt > Pages : 219 > Date : 2003-4-3 > > Does the new RFC 3525 reeplaces this draft. Notice that this draft expires > on next october. > If this draft is still alive, does it mean that it will became on a new > RFCXXXX in the future? If so, that RFCXXXX will obsolete the RFC3525, will > not it? > Jose Luis, > > > > -----Mensaje original----- > > De: rfc-editor@rfc-editor.org [SMTP:rfc-editor@rfc-editor.org] > > Enviado el: Lunes 9 de Junio de 2003 13:59 > > CC: rfc-editor@rfc-editor.org; megaco@ietf.org > > Asunto: [Megaco] RFC 3525 on Gateway Control Protocol Version 1 > > > > > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 3525 > > > > Title: Gateway Control Protocol Version 1 > > Author(s): C. Groves, M. Pantaleo, T. Anderson, T. Taylor, > > Editors > > Status: Standards Track > > Date: June 2003 > > Mailbox: Christian.Groves@ericsson.com.au, > > Marcello.Pantaleo@eed.ericsson.se, > > tlatla@verizon.net, > > taylor@nortelnetworks.com > > Pages: 213 > > Characters: 439674 > > Obsoletes: 3015 > > > > I-D Tag: draft-ietf-megaco-3015corr-03.txt > > > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3525.txt > > > > > > This document defines the protocol used between elements of a > > physically decomposed multimedia gateway, i.e., a Media Gateway and a > > Media Gateway Controller. The protocol presented in this document > > meets the requirements for a media gateway control protocol as > > presented in RFC 2805. > > > > This document replaces RFC 3015. It is the result of > > continued cooperation between the IETF Megaco Working Group and ITU-T > > Study Group 16. It incorporates the original text of RFC 3015, > > modified by corrections and clarifications discussed on the Megaco > > > > E-mail list and incorporated into the Study Group 16 Implementor's > > Guide for Recommendation H.248. The present version of this document > > underwent ITU-T Last Call as Recommendation H.248 Amendment 1. > > Because of ITU-T renumbering, it was published by the ITU-T as > > Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. > > > > Users of this specification are advised to consult the H.248 > > Sub-series Implementors' Guide at > > http://www.itu.int/itudoc/itu-t/com16/implgd for additional > > corrections and clarifications. > > > > This document is a product of the Media Gateway Control Working Group > > of the IETF. > > > > This is now a Proposed Standard Protocol. > > > > This document specifies an Internet standards track protocol for > > the Internet community, and requests discussion and suggestions > > for improvements. Please refer to the current edition of the > > "Internet Official Protocol Standards" (STD 1) for the > > standardization state and status of this protocol. Distribution > > of this memo is unlimited. > > > > This announcement is sent to the IETF list and the RFC-DIST list. > > Requests to be added to or deleted from the IETF distribution list > > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > > added to or deleted from the RFC-DIST distribution list should > > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > > help: ways_to_get_rfcs. For example: > > > > To: rfc-info@RFC-EDITOR.ORG > > Subject: getting rfcs > > > > help: ways_to_get_rfcs > > > > Requests for special distribution should be addressed to either the > > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > > specifically noted otherwise on the RFC itself, all RFCs are for > > unlimited distribution.echo > > Submissions for Requests for Comments should be sent to > > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > > Authors, for further information. > > > > > > Joyce K. Reynolds and Sandy Ginoza > > USC/Information Sciences Institute > > > > ... > > > > Below is the data which will enable a MIME compliant Mail Reader > > implementation to automatically retrieve the ASCII version > > of the RFCs. <> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jun 10 22:34:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27081 for ; Tue, 10 Jun 2003 22:34:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B2XOB16440; Tue, 10 Jun 2003 22:33:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B2VmB16395 for ; Tue, 10 Jun 2003 22:31:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27017 for ; Tue, 10 Jun 2003 22:31:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PvMq-00046X-00 for megaco@ietf.org; Tue, 10 Jun 2003 22:29:40 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19PvMo-00046U-00 for megaco@ietf.org; Tue, 10 Jun 2003 22:29:38 -0400 Received: from brsf10.epa.ericsson.se ([61.88.9.226]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h5B2TCT00394; Wed, 11 Jun 2003 12:29:12 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h5B2Vcb27365; Wed, 11 Jun 2003 12:31:38 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.148]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LZBXQC20; Wed, 11 Jun 2003 12:31:36 +1000 Message-ID: <3EE68930.A9073F54@ericsson.com.au> Date: Wed, 11 Jun 2003 11:43:12 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kalleitner Franz CC: Megaco List Subject: Re: [Megaco] correct connection model for conferencing according darft H.248.19 References: Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ish7.ericsson.com.au id h5B2TCT00394 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5B2VmB16396 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello Franz, I believe the correct approach is the model where all terminations for a centralised conference belong to '1' context. However in some conferencing scenarios a hybrid approach with more than one context would be needed. Take for example when you have a centralised conference and someone is put on hold. According to the H.248 connection model a seperate context is needed. So therefore you have a hybrid with 2 contexts. Another example is when you have a main conference in one context and side context in another context. Rather than moving all the participants a seperate call leg termination in both contexts could be used to join the conferences. This is why H.248.19 makes the statement "By placing the relevant terminations in the same or different contexts it allows the MCU to perform the different types of "multi-point". If you also wanted to model the conference bridge as a central context with a side context for each call leg then I believe that due to the fact that hybrid approach should be supported then this model is also supported. The packages in H.248.19 support the above configurations. I believe the configuration/model for conferencing in is incorrect and I do not believe that the H.248.19 package support this model. Whilst the draft is quite voluminous I would caution people using the call flows as gospel and I would certainly not base an implementation on them. Regards, Christian Kalleitner Franz wrote: > > Hello megaco-list-members > > In the past, many threats were discussing about conferencing. However SG16 > started to summarized this topic in the draft H.248.19 (BTW: Thanks a lot for > that work), but the connection model is still not clear to me. > > As documented in H.248.19 §5 (conferencing architectures) it is mentioned that > according H.248 §6 two different types of conferencing could apply by placing > the relevant terminations in the same or different contexts. > > In case of implementing conferences using different contexts, which connection > model should apply ? > 1.) for each conferee an own context as shown at example §9 > draft-ietf-megaco-callflows-02.txt? > 2.) separation into a central conference context and for each conferee an own, > lets say, call leg context? > 3.) or are both listed connection models meaningful ? > > The second approach was discussed many times in the list, but there was never > a final and clear statement, may be there could be one before finalizing > H248.19. > > Thanks in advance > Franz _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jun 10 22:35:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27103 for ; Tue, 10 Jun 2003 22:35:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5B2ZYG16555 for megaco-archive@odin.ietf.org; Tue, 10 Jun 2003 22:35:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B2ZYB16552 for ; Tue, 10 Jun 2003 22:35:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27098 for ; Tue, 10 Jun 2003 22:35:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PvQT-00047f-00 for megaco-web-archive@ietf.org; Tue, 10 Jun 2003 22:33:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PvQS-00047c-00 for megaco-web-archive@ietf.org; Tue, 10 Jun 2003 22:33:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B2XOB16440; Tue, 10 Jun 2003 22:33:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B2VmB16395 for ; Tue, 10 Jun 2003 22:31:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27017 for ; Tue, 10 Jun 2003 22:31:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PvMq-00046X-00 for megaco@ietf.org; Tue, 10 Jun 2003 22:29:40 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19PvMo-00046U-00 for megaco@ietf.org; Tue, 10 Jun 2003 22:29:38 -0400 Received: from brsf10.epa.ericsson.se ([61.88.9.226]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h5B2TCT00394; Wed, 11 Jun 2003 12:29:12 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h5B2Vcb27365; Wed, 11 Jun 2003 12:31:38 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.148]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LZBXQC20; Wed, 11 Jun 2003 12:31:36 +1000 Message-ID: <3EE68930.A9073F54@ericsson.com.au> Date: Wed, 11 Jun 2003 11:43:12 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kalleitner Franz CC: Megaco List Subject: Re: [Megaco] correct connection model for conferencing according darft H.248.19 References: Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ish7.ericsson.com.au id h5B2TCT00394 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5B2VmB16396 Sender: megaco-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-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5B2XOB16440 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5B2ZYB16552 Content-Transfer-Encoding: 8bit Hello Franz, I believe the correct approach is the model where all terminations for a centralised conference belong to '1' context. However in some conferencing scenarios a hybrid approach with more than one context would be needed. Take for example when you have a centralised conference and someone is put on hold. According to the H.248 connection model a seperate context is needed. So therefore you have a hybrid with 2 contexts. Another example is when you have a main conference in one context and side context in another context. Rather than moving all the participants a seperate call leg termination in both contexts could be used to join the conferences. This is why H.248.19 makes the statement "By placing the relevant terminations in the same or different contexts it allows the MCU to perform the different types of "multi-point". If you also wanted to model the conference bridge as a central context with a side context for each call leg then I believe that due to the fact that hybrid approach should be supported then this model is also supported. The packages in H.248.19 support the above configurations. I believe the configuration/model for conferencing in is incorrect and I do not believe that the H.248.19 package support this model. Whilst the draft is quite voluminous I would caution people using the call flows as gospel and I would certainly not base an implementation on them. Regards, Christian Kalleitner Franz wrote: > > Hello megaco-list-members > > In the past, many threats were discussing about conferencing. However SG16 > started to summarized this topic in the draft H.248.19 (BTW: Thanks a lot for > that work), but the connection model is still not clear to me. > > As documented in H.248.19 §5 (conferencing architectures) it is mentioned that > according H.248 §6 two different types of conferencing could apply by placing > the relevant terminations in the same or different contexts. > > In case of implementing conferences using different contexts, which connection > model should apply ? > 1.) for each conferee an own context as shown at example §9 > draft-ietf-megaco-callflows-02.txt? > 2.) separation into a central conference context and for each conferee an own, > lets say, call leg context? > 3.) or are both listed connection models meaningful ? > > The second approach was discussed many times in the list, but there was never > a final and clear statement, may be there could be one before finalizing > H248.19. > > Thanks in advance > Franz _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jun 10 22:37:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27120 for ; Tue, 10 Jun 2003 22:37:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B2XfB16471; Tue, 10 Jun 2003 22:33:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B2VsB16402 for ; Tue, 10 Jun 2003 22:31:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27020 for ; Tue, 10 Jun 2003 22:31:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PvMv-00046d-00 for megaco@ietf.org; Tue, 10 Jun 2003 22:29:45 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19PvMu-00046a-00 for megaco@ietf.org; Tue, 10 Jun 2003 22:29:44 -0400 Received: from brsf10.epa.ericsson.se ([61.88.9.226]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h5B2TIT00411; Wed, 11 Jun 2003 12:29:18 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h5B2Vhb27390; Wed, 11 Jun 2003 12:31:43 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.148]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LZBXQCJG; Wed, 11 Jun 2003 12:31:41 +1000 Message-ID: <3EE68F6B.C86E35C8@ericsson.com.au> Date: Wed, 11 Jun 2003 12:09:47 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Boyle CC: Tom-PT Taylor , "H.S.Sureshchandra" , Simran Chadha , Megaco List Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote Descriptors! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit G'Day, I agree with Kevin we should include these in the implementors' guide. Regards, Christian Kevin Boyle wrote: > > If the concerns pointed out exist in H.248.1 v1 (03/2002), then any > corrections belong in the IG. The intent of the RFC is to produce identical > text to the ITU-T Recommendation as much as possible, correct? > > Kevin > > -----Original Message----- > From: Taylor, Tom-PT [CAR:5N00:EXCH] > Sent: Tuesday, June 10, 2003 8:33 AM > To: H.S.Sureshchandra > Cc: Simran Chadha; Megaco List > Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote > Descriptors! > > My apologies -- I failed to keep this somewhwere where I would remember it > when the > time came. The ridiculous part is that the "authors' 48 hours" actually > lasted a > full month due to other delays. > > We can do two things now: record the corrections in the Implementor's Guide, > and > register them as errata against the RFC with the RFC Editor. I'll work on > that today. > > H.S.Sureshchandra wrote: > > > Hello Tom, > > > > I do not see incorporation of any of the observations made by my > > colleague Simran Chadha in the new RFC 3525, as "promised" by you in > > your earlier mail. > > > > Please clarify. Thanks ! > > > > Suresh > > > > > > ----- Original Message ----- > > From: "Tom Taylor" > > To: "Simran Chadha" > > Cc: "Megaco List" > > Sent: Wednesday, February 05, 2003 12:29 AM > > Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote > > Descriptors! > > > > > > > >>That "cannot not" is a typo -- I'll remove the "not" during the > >>"authors' > > > > 48 hours" > > > >>interval prior to formal publication as a new RFC. > >> > >>On your second point: the two paragraphs apply independently to > > > > ReserveGroup and > > > >>ReserveValue. That is, it is possible to have ReserveGroup TRUE and > > > > ReserveValue > > > >>FALSE -- in which case the MG reserves for multiple session > >>descriptions > > > > but is > > > >>restricted to one codec in each -- or vice versa. Or both could be > >>TRUE, > > > > or both FALSE. > > > >>On the third point, the intended meaning would be conveyed by > >>replacing > > > > "if it > > > >>cannot support any of the alternatives" with "if it can support none > >>of > > > > the > > > >>alternatives". Perhaps I can also do that during the "authors' 48 > >>hours" > > > > period, > > > >>though we would usually do it through the ITU-T Implementor's Guide. > >> > >>The task of developing an unambiguous protocol specification is not > > > > simple. Your > > > >>points have eluded others in the three years since first approval. > >>Thank > > > > you for > > > >>your contribution. > >> > >>Simran Chadha wrote: > >> > >>>Hi List, > >>> > >>>Can someone please help me at the earliest on the issues raised > >>>earlier by me - particularly, usage of LocalControl,Local and Remote > >>>Descriptors > > > > ? > > > >>>Thanks in advance. > >>> > >>>Simran Chadha > >>>On Thu, 30 Jan 2003 Simran Chadha wrote : > >>> > >>> > >>>>Hi List, > >>>> > >>>>Can you please help me with clarifications in my understanding of > >>>>sections 7.1.7 and 7.1.8 on the use of LocalControl,Local and Remote > >>>>Descriptors. > >>>> > >>>>As per draft-ietf-megaco-3015corr-03, in section 7.1.7, > >>>>If the value of a Reserve property is True, the MG SHALL reserve > >>>>resources for all alternatives specified in the Local and/or Remote > >>>>descriptors for which it currently has resources available. It SHALL > >>>>respond with the alternatives for which it reserves resources. If it > >>>>cannot not support any of the alternatives, it SHALL respond with a > >>>>reply to the MGC that contains empty Local and/or Remote > >>>>descriptors. The use of two negations - "cannot not" in the last > >>>>statement will imply that - If it can support any of the > >>>>alternatives, it SHALL respond with a reply to the MGC that contains > >>>>empty Local and/or Remote descriptors. I don't think this is what is > >>>>meant to be conveyed here. > >>>> > >>>>Also in section 7.1.7 the first para starts - If the value of a > >>>>Reserve property is True, ..... while the second para starts - If > >>>>the value of a Reserve property is False, .... > >>>>Now as there are two Reserve properties - one Reserve Group and the > >>>>other Reserve Value, One could be False and the other could be True. > >>>>Then in this case what will be the inference - Should para 1 apply or > >>>>para 2 ? Both the paras would seem to be mutually exclusive in what is > >>>>needed to be done. > >>>> > >>>>Also statements like "if it cannot support any of the alternatives > >>>>... " - will have two meanings. 1. Any - Not even one - NONE of the > >>>>alternatives is supported. > >>>>2. Any - Atleast one - While a few alternatives can be supported, a > >>>>few might not be. > >>>> > >>>>The protocol needs to be more clear on such aspects in the documents > >>>>henceforth. The English language is understood in different parts of > >>>>the world. Variations to agreed usage of the language terms will > >>>>make it difficult for new users of Megaco protocol, like me. > >>>> > >>>>Can someone please educate me on the exact usage and meaning of > >>>>LocalControl,Local and Remote Descriptors ? > >>>> > >>>>Thanks and awaiting comments and clarifications > >>>> > >>>>Simran Chadha > >>> > >>> > >>> > >>>_______________________________________________ > >>>Megaco mailing list > >>>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > >>> > >> > >>_______________________________________________ > >>Megaco mailing list > >>Megaco@ietf.org > >>https://www1.ietf.org/mailman/listinfo/megaco > >> > > > > > > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jun 10 22:38:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27145 for ; Tue, 10 Jun 2003 22:38:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5B2bgd17264 for megaco-archive@odin.ietf.org; Tue, 10 Jun 2003 22:37:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B2bfB17245 for ; Tue, 10 Jun 2003 22:37:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27137 for ; Tue, 10 Jun 2003 22:37:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PvSW-00047l-00 for megaco-web-archive@ietf.org; Tue, 10 Jun 2003 22:35:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PvSV-00047i-00 for megaco-web-archive@ietf.org; Tue, 10 Jun 2003 22:35:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B2XfB16471; Tue, 10 Jun 2003 22:33:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B2VsB16402 for ; Tue, 10 Jun 2003 22:31:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27020 for ; Tue, 10 Jun 2003 22:31:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PvMv-00046d-00 for megaco@ietf.org; Tue, 10 Jun 2003 22:29:45 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19PvMu-00046a-00 for megaco@ietf.org; Tue, 10 Jun 2003 22:29:44 -0400 Received: from brsf10.epa.ericsson.se ([61.88.9.226]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h5B2TIT00411; Wed, 11 Jun 2003 12:29:18 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h5B2Vhb27390; Wed, 11 Jun 2003 12:31:43 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.148]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LZBXQCJG; Wed, 11 Jun 2003 12:31:41 +1000 Message-ID: <3EE68F6B.C86E35C8@ericsson.com.au> Date: Wed, 11 Jun 2003 12:09:47 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Boyle CC: Tom-PT Taylor , "H.S.Sureshchandra" , Simran Chadha , Megaco List Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote Descriptors! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit G'Day, I agree with Kevin we should include these in the implementors' guide. Regards, Christian Kevin Boyle wrote: > > If the concerns pointed out exist in H.248.1 v1 (03/2002), then any > corrections belong in the IG. The intent of the RFC is to produce identical > text to the ITU-T Recommendation as much as possible, correct? > > Kevin > > -----Original Message----- > From: Taylor, Tom-PT [CAR:5N00:EXCH] > Sent: Tuesday, June 10, 2003 8:33 AM > To: H.S.Sureshchandra > Cc: Simran Chadha; Megaco List > Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote > Descriptors! > > My apologies -- I failed to keep this somewhwere where I would remember it > when the > time came. The ridiculous part is that the "authors' 48 hours" actually > lasted a > full month due to other delays. > > We can do two things now: record the corrections in the Implementor's Guide, > and > register them as errata against the RFC with the RFC Editor. I'll work on > that today. > > H.S.Sureshchandra wrote: > > > Hello Tom, > > > > I do not see incorporation of any of the observations made by my > > colleague Simran Chadha in the new RFC 3525, as "promised" by you in > > your earlier mail. > > > > Please clarify. Thanks ! > > > > Suresh > > > > > > ----- Original Message ----- > > From: "Tom Taylor" > > To: "Simran Chadha" > > Cc: "Megaco List" > > Sent: Wednesday, February 05, 2003 12:29 AM > > Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote > > Descriptors! > > > > > > > >>That "cannot not" is a typo -- I'll remove the "not" during the > >>"authors' > > > > 48 hours" > > > >>interval prior to formal publication as a new RFC. > >> > >>On your second point: the two paragraphs apply independently to > > > > ReserveGroup and > > > >>ReserveValue. That is, it is possible to have ReserveGroup TRUE and > > > > ReserveValue > > > >>FALSE -- in which case the MG reserves for multiple session > >>descriptions > > > > but is > > > >>restricted to one codec in each -- or vice versa. Or both could be > >>TRUE, > > > > or both FALSE. > > > >>On the third point, the intended meaning would be conveyed by > >>replacing > > > > "if it > > > >>cannot support any of the alternatives" with "if it can support none > >>of > > > > the > > > >>alternatives". Perhaps I can also do that during the "authors' 48 > >>hours" > > > > period, > > > >>though we would usually do it through the ITU-T Implementor's Guide. > >> > >>The task of developing an unambiguous protocol specification is not > > > > simple. Your > > > >>points have eluded others in the three years since first approval. > >>Thank > > > > you for > > > >>your contribution. > >> > >>Simran Chadha wrote: > >> > >>>Hi List, > >>> > >>>Can someone please help me at the earliest on the issues raised > >>>earlier by me - particularly, usage of LocalControl,Local and Remote > >>>Descriptors > > > > ? > > > >>>Thanks in advance. > >>> > >>>Simran Chadha > >>>On Thu, 30 Jan 2003 Simran Chadha wrote : > >>> > >>> > >>>>Hi List, > >>>> > >>>>Can you please help me with clarifications in my understanding of > >>>>sections 7.1.7 and 7.1.8 on the use of LocalControl,Local and Remote > >>>>Descriptors. > >>>> > >>>>As per draft-ietf-megaco-3015corr-03, in section 7.1.7, > >>>>If the value of a Reserve property is True, the MG SHALL reserve > >>>>resources for all alternatives specified in the Local and/or Remote > >>>>descriptors for which it currently has resources available. It SHALL > >>>>respond with the alternatives for which it reserves resources. If it > >>>>cannot not support any of the alternatives, it SHALL respond with a > >>>>reply to the MGC that contains empty Local and/or Remote > >>>>descriptors. The use of two negations - "cannot not" in the last > >>>>statement will imply that - If it can support any of the > >>>>alternatives, it SHALL respond with a reply to the MGC that contains > >>>>empty Local and/or Remote descriptors. I don't think this is what is > >>>>meant to be conveyed here. > >>>> > >>>>Also in section 7.1.7 the first para starts - If the value of a > >>>>Reserve property is True, ..... while the second para starts - If > >>>>the value of a Reserve property is False, .... > >>>>Now as there are two Reserve properties - one Reserve Group and the > >>>>other Reserve Value, One could be False and the other could be True. > >>>>Then in this case what will be the inference - Should para 1 apply or > >>>>para 2 ? Both the paras would seem to be mutually exclusive in what is > >>>>needed to be done. > >>>> > >>>>Also statements like "if it cannot support any of the alternatives > >>>>... " - will have two meanings. 1. Any - Not even one - NONE of the > >>>>alternatives is supported. > >>>>2. Any - Atleast one - While a few alternatives can be supported, a > >>>>few might not be. > >>>> > >>>>The protocol needs to be more clear on such aspects in the documents > >>>>henceforth. The English language is understood in different parts of > >>>>the world. Variations to agreed usage of the language terms will > >>>>make it difficult for new users of Megaco protocol, like me. > >>>> > >>>>Can someone please educate me on the exact usage and meaning of > >>>>LocalControl,Local and Remote Descriptors ? > >>>> > >>>>Thanks and awaiting comments and clarifications > >>>> > >>>>Simran Chadha > >>> > >>> > >>> > >>>_______________________________________________ > >>>Megaco mailing list > >>>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > >>> > >> > >>_______________________________________________ > >>Megaco mailing list > >>Megaco@ietf.org > >>https://www1.ietf.org/mailman/listinfo/megaco > >> > > > > > > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jun 12 08:18:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06486 for ; Thu, 12 Jun 2003 08:18:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CCHdm14855; Thu, 12 Jun 2003 08:17:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CCF8m14725 for ; Thu, 12 Jun 2003 08:15:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06275 for ; Thu, 12 Jun 2003 08:15:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QQwu-0001QL-00 for megaco@ietf.org; Thu, 12 Jun 2003 08:13:00 -0400 Received: from wiprom2mx1.wipro.com ([203.197.164.41]) by ietf-mx with esmtp (Exim 4.12) id 19QQwc-0001No-00 for megaco@ietf.org; Thu, 12 Jun 2003 08:12:42 -0400 Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h5CCE0C20102 for ; Thu, 12 Jun 2003 17:44:00 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-m1-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Jun 2003 17:43:55 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-04f6d1c6-9b53-11d7-ba7f-006067005148" Date: Thu, 12 Jun 2003 17:43:55 +0530 Message-ID: <5A521CAA914BAF47A48A726DE83E7D240F5D8A@blr-k1-msg.wipro.com> Thread-Topic: GW Response for package info Thread-Index: AcMw3XCqwsB/UMi3Q/ua5t61kI+5/A== From: "Nagalakshmi H.G" To: X-OriginalArrivalTime: 12 Jun 2003 12:13:55.0224 (UTC) FILETIME=[1820B180:01C330DC] Subject: [Megaco] GW Response for package info Sender: megaco-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. ------=_NextPartTM-000-04f6d1c6-9b53-11d7-ba7f-006067005148 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C330DC.18588AD4" ------_=_NextPart_001_01C330DC.18588AD4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 A GW's response to the package is different when it is sent on the ephemeral compared to when sent on the physical termination. =20 !/1 [10.104.1.24]:2944 T=3D65662{C=3D${A=3D${M{O{MO=3DSR,xconn/phys=3DE1/04/06/3,tdmc/gain=3D2},= L{v=3D0 c=3DIN IP4 $ m=3Daudio $ RTP/AVP 8 0 a=3Dptime:10 }}}}} !/1 [10.104.21.2]:2944 P =3D 65662 { C =3D $ { A =3D $ { ER =3D 442 {}; The package tdmc cannot be used = for a IP termination } } } But when tdmc/gain is sent on the physical , the GW does not send out a 442.=20 =20 Is this a desired behaviour out of a GW ? Does Megaco speak anything about this varied response from the GW for the same package information sent (ie., based on which termination it is sent on ) ? =20 =20 Appreciate your response on the same. =20 Thanks, Nagalakshmi. =20 ------_=_NextPart_001_01C330DC.18588AD4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi All,
 
 A GW's response to the package is different when it is = sent on the=20 ephemeral compared to when sent on the physical termination.
 
 !/1 [10.104.1.24]:2944=20 T=3D65662{C=3D${A=3D${M{O{MO=3DSR,xconn/phys=3DE1/04/06/3,tdmc/ga= in=3D2},L{v=3D0
c=3DIN=20 IP4 $
m=3Daudio $ RTP/AVP 8=20 0
a=3Dptime:10
}}}}}
!/1 [10.104.21.2]:2944
P =3D 65662=20 {
        C =3D $=20 {
           &n= bsp;   =20 A =3D $=20 {
           &n= bsp;           =20 ER =3D 442 {}; The package tdmc cannot be used for a IP = termination
         &nbs= p;     =20 }
       =20 }
}
 But when tdmc/gain is = sent on=20 the physical , the GW does not send out a 442. =
 
 Is this a desired behaviour out of a GW = ? Does Megaco speak anything about this varied = response=20 from the GW for the same package information sent (ie., based on which=20 termination it is sent on ) ? 
 
 Appreciate=20 your response on the same.
 
Thanks,
Nagalakshmi.  =20
------_=_NextPart_001_01C330DC.18588AD4-- ------=_NextPartTM-000-04f6d1c6-9b53-11d7-ba7f-006067005148-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jun 12 08:19:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06537 for ; Thu, 12 Jun 2003 08:19:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CCJJP14992 for megaco-archive@odin.ietf.org; Thu, 12 Jun 2003 08:19:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CCJJm14989 for ; Thu, 12 Jun 2003 08:19:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06509 for ; Thu, 12 Jun 2003 08:19:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QR0x-0001Tx-00 for megaco-web-archive@ietf.org; Thu, 12 Jun 2003 08:17:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QR0w-0001Tt-00 for megaco-web-archive@ietf.org; Thu, 12 Jun 2003 08:17:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CCHdm14855; Thu, 12 Jun 2003 08:17:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CCF8m14725 for ; Thu, 12 Jun 2003 08:15:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06275 for ; Thu, 12 Jun 2003 08:15:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QQwu-0001QL-00 for megaco@ietf.org; Thu, 12 Jun 2003 08:13:00 -0400 Received: from wiprom2mx1.wipro.com ([203.197.164.41]) by ietf-mx with esmtp (Exim 4.12) id 19QQwc-0001No-00 for megaco@ietf.org; Thu, 12 Jun 2003 08:12:42 -0400 Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h5CCE0C20102 for ; Thu, 12 Jun 2003 17:44:00 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-m1-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Jun 2003 17:43:55 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-04f6d1c6-9b53-11d7-ba7f-006067005148" Date: Thu, 12 Jun 2003 17:43:55 +0530 Message-ID: <5A521CAA914BAF47A48A726DE83E7D240F5D8A@blr-k1-msg.wipro.com> Thread-Topic: GW Response for package info Thread-Index: AcMw3XCqwsB/UMi3Q/ua5t61kI+5/A== From: "Nagalakshmi H.G" To: X-OriginalArrivalTime: 12 Jun 2003 12:13:55.0224 (UTC) FILETIME=[1820B180:01C330DC] Subject: [Megaco] GW Response for package info Sender: megaco-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. ------=_NextPartTM-000-04f6d1c6-9b53-11d7-ba7f-006067005148 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C330DC.18588AD4" ------_=_NextPart_001_01C330DC.18588AD4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 A GW's response to the package is different when it is sent on the ephemeral compared to when sent on the physical termination. =20 !/1 [10.104.1.24]:2944 T=3D65662{C=3D${A=3D${M{O{MO=3DSR,xconn/phys=3DE1/04/06/3,tdmc/gain=3D2},= L{v=3D0 c=3DIN IP4 $ m=3Daudio $ RTP/AVP 8 0 a=3Dptime:10 }}}}} !/1 [10.104.21.2]:2944 P =3D 65662 { C =3D $ { A =3D $ { ER =3D 442 {}; The package tdmc cannot be used = for a IP termination } } } But when tdmc/gain is sent on the physical , the GW does not send out a 442.=20 =20 Is this a desired behaviour out of a GW ? Does Megaco speak anything about this varied response from the GW for the same package information sent (ie., based on which termination it is sent on ) ? =20 =20 Appreciate your response on the same. =20 Thanks, Nagalakshmi. =20 ------_=_NextPart_001_01C330DC.18588AD4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi All,
 
 A GW's response to the package is different when it is = sent on the=20 ephemeral compared to when sent on the physical termination.
 
 !/1 [10.104.1.24]:2944=20 T=3D65662{C=3D${A=3D${M{O{MO=3DSR,xconn/phys=3DE1/04/06/3,tdmc/ga= in=3D2},L{v=3D0
c=3DIN=20 IP4 $
m=3Daudio $ RTP/AVP 8=20 0
a=3Dptime:10
}}}}}
!/1 [10.104.21.2]:2944
P =3D 65662=20 {
        C =3D $=20 {
           &n= bsp;   =20 A =3D $=20 {
           &n= bsp;           =20 ER =3D 442 {}; The package tdmc cannot be used for a IP = termination
         &nbs= p;     =20 }
       =20 }
}
 But when tdmc/gain is = sent on=20 the physical , the GW does not send out a 442. =
 
 Is this a desired behaviour out of a GW = ? Does Megaco speak anything about this varied = response=20 from the GW for the same package information sent (ie., based on which=20 termination it is sent on ) ? 
 
 Appreciate=20 your response on the same.
 
Thanks,
Nagalakshmi.  =20
------_=_NextPart_001_01C330DC.18588AD4-- ------=_NextPartTM-000-04f6d1c6-9b53-11d7-ba7f-006067005148-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Jun 13 11:14:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09323 for ; Fri, 13 Jun 2003 11:14:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D1A3a08439; Thu, 12 Jun 2003 21:10:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D19tm08418 for ; Thu, 12 Jun 2003 21:09:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03519 for ; Thu, 12 Jun 2003 21:09:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qd2f-0007br-00 for megaco@ietf.org; Thu, 12 Jun 2003 21:07:45 -0400 Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx with esmtp (Exim 4.12) id 19Qd2e-0007bT-00 for megaco@ietf.org; Thu, 12 Jun 2003 21:07:44 -0400 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.2+Sun/8.12.3) with SMTP id h5D0w1QA014728 for ; Fri, 13 Jun 2003 08:58:01 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Fri Jun 13 09:10:14 2003 +0800 Received: from bellnet-mail1.sbell.com.cn ([172.24.208.21]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Jun 2003 09:10:13 +0800 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_01C33148.8AA628EA" Date: Fri, 13 Jun 2003 09:10:13 +0800 Message-ID: Thread-Topic: GW Response for package info Thread-Index: =?utf-7?Q?AcMw3XCqwsB/UMi3Q/ua5t61kI+5/A-i+BkEAAAH8cAA-?= =?utf-7?Q?+AD0-?= From: "FND-AD Wang JuLin" To: Cc: X-OriginalArrivalTime: 13 Jun 2003 01:10:13.0342 (UTC) FILETIME=[8AD977E0:01C33148] Subject: [Megaco] FW: +AFs-Megaco+AF0- GW Response for package info Sender: megaco-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_01C33148.8AA628EA Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit TDM Circuit Package is used to support TDM circuit terminations.So when it was used for rtp termination,error will be triggered. Our stack report 501 +ACI-Not implement+ACI- error in such case. -----Original Message----- From: Nagalakshmi H.G +AFs-mailto:nagalakshmi.gireesh+AEA-wipro.com+AF0- Sent: Thursday, June 12, 2003 8:14 PM To: megaco+AEA-ietf.org Subject: +AFs-Megaco+AF0- GW Response for package info Hi All, A GW's response to the package is different when it is sent on the ephemeral compared to when sent on the physical termination. +ACE-/1 +AFs-10.104.1.24+AF0-:2944 T+AD0-65662+AHs-C+AD0AJAB7-A+AD0AJAB7-M+AHs-O+AHs-MO+AD0-SR,xconn/phys+AD0-E1/04/06/3,tdmc/gain+AD0-2+AH0-,L+AHs-v+AD0-0 c+AD0-IN IP4 +ACQ- m+AD0-audio +ACQ- RTP/AVP 8 0 a+AD0-ptime:10 +AH0AfQB9AH0AfQ- +ACE-/1 +AFs-10.104.21.2+AF0-:2944 P +AD0- 65662 +AHs- C +AD0- +ACQ- +AHs- A +AD0- +ACQ- +AHs- ER +AD0- 442 +AHsAfQA7- The package tdmc cannot be used for a IP termination +AH0- +AH0- +AH0- But when tdmc/gain is sent on the physical , the GW does not send out a 442. Is this a desired behaviour out of a GW ? Does Megaco speak anything about this varied response from the GW for the same package information sent (ie., based on which termination it is sent on ) ? Appreciate your response on the same. Thanks, Nagalakshmi. ------_=_NextPart_001_01C33148.8AA628EA Content-Type: text/html; charset="utf-7" Content-Transfer-Encoding: 7bit +ADwAIQ-DOCTYPE HTML PUBLIC +ACI--//W3C//DTD HTML 4.0 Transitional//EN+ACIAPg- +ADw-HTML+AD4APA-HEAD+AD4- +ADw-META HTTP-EQUIV+AD0AIg-Content-Type+ACI- CONTENT+AD0AIg-text/html+ADs- charset+AD0-utf-7+ACIAPg- +ADw-TITLE+AD4-Message+ADw-/TITLE+AD4- +ADw-META content+AD0AIg-MSHTML 6.00.2712.300+ACI- name+AD0-GENERATOR+AD4APA-/HEAD+AD4- +ADw-BODY+AD4- +ADw-DIV+AD4APA-SPAN class+AD0-010215500-13062003+AD4APA-FONT color+AD0AIw-0000ff size+AD0-2+AD4-TDM Circuit Package is used to support TDM circuit terminations.So when it was used for rtp termination,error will be triggered. Our stack report 501 +ACI-Not implement+ACI- error in such case.+ADw-/FONT+AD4APA-/SPAN+AD4APA-/DIV+AD4- +ADw-BLOCKQUOTE dir+AD0-ltr style+AD0AIg-PADDING-LEFT: 5px+ADs- MARGIN-LEFT: 5px+ADs- BORDER-LEFT: +ACM-0000ff 2px solid+ADs- MARGIN-RIGHT: 0px+ACIAPg- +ADw-DIV class+AD0-OutlookMessageHeader dir+AD0-ltr align+AD0-left+AD4APA-FONT face+AD0-Tahoma size+AD0-2+AD4------Original Message-----+ADw-BR+AD4APA-B+AD4-From:+ADw-/B+AD4- Nagalakshmi H.G +AFs-mailto:nagalakshmi.gireesh+AEA-wipro.com+AF0APA-BR+AD4APA-B+AD4-Sent:+ADw-/B+AD4- Thursday, June 12, 2003 8:14 PM+ADw-BR+AD4APA-B+AD4-To:+ADw-/B+AD4- megaco+AEA-ietf.org+ADw-BR+AD4APA-B+AD4-Subject:+ADw-/B+AD4- +AFs-Megaco+AF0- GW Response for package info+ADw-BR+AD4APA-BR+AD4APA-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-SPAN class+AD0-321021412-12062003+AD4-Hi All,+ADw-/SPAN+AD4APA-/SPAN+AD4APA-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT size+AD0-2+AD4APA-FONT color+AD0AIw-0000ff+AD4APA-FONT face+AD0-Arial+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-/SPAN+AD4APA-/FONT+AD4APA-/FONT+AD4APA-/FONT+AD4AJg-nbsp+ADsAPA-/DIV+AD4- +ADw-DIV+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-FONT face+AD0-Arial+AD4APA-FONT color+AD0AIw-0000ff+AD4APA-FONT size+AD0-2+AD4AJg-nbsp+ADs-A GW's response to the package is different when it is sent on the ephemeral compared to when sent on the physical terminatio+ADw-SPAN class+AD0-321021412-12062003+AD4-n.+ADw-/SPAN+AD4APA-/FONT+AD4APA-/FONT+AD4APA-/FONT+AD4APA-/SPAN+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-FONT face+AD0-Arial+AD4APA-FONT color+AD0AIw-0000ff+AD4APA-FONT size+AD0-2+AD4APA-SPAN class+AD0-321021412-12062003+AD4APA-/SPAN+AD4APA-/FONT+AD4APA-/FONT+AD4APA-/FONT+AD4APA-/SPAN+AD4AJg-nbsp+ADsAPA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-SPAN class+AD0-321021412-12062003+AD4AJg-nbsp+ADsAIQ-/1 +AFs-10.104.1.24+AF0-:2944 T+AD0-65662+AHs-C+AD0AJAB7-A+AD0AJAB7-M+AHs-O+AHs-MO+AD0-SR,xconn/phys+AD0-E1/04/06/3,+ADw-STRONG+AD4-tdmc/gain+AD0-2+ADw-/STRONG+AD4AfQ-,L+AHs-v+AD0-0+ADw-BR+AD4-c+AD0-IN IP4 +ACQAPA-BR+AD4-m+AD0-audio +ACQ- RTP/AVP 8 0+ADw-BR+AD4-a+AD0-ptime:10+ADw-BR+AD4AfQB9AH0AfQB9ADw-BR+AD4APA-/SPAN+AD4APA-/SPAN+AD4APA-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-SPAN class+AD0-321021412-12062003+AD4AIQ-/1 +AFs-10.104.21.2+AF0-:2944+ADw-BR+AD4-P +AD0- 65662 +AHsAPA-BR+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- C +AD0- +ACQ- +AHsAPA-BR+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- A +AD0- +ACQ- +AHsAPA-BR+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- ER +AD0- +ADw-STRONG+AD4-442+ADw-/STRONG+AD4- +AHsAfQA7- The package tdmc cannot be used for a IP termination+ADw-BR+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- +AH0APA-BR+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- +AH0APA-BR+AD4AfQA8-BR+AD4APA-/SPAN+AD4APA-/SPAN+AD4APA-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-SPAN class+AD0-321021412-12062003+AD4AJg-nbsp+ADs-But when +ADw-STRONG+AD4-tdmc/gain+ADw-/STRONG+AD4- is sent on the physical , the GW does not send out a 442. +ADw-/SPAN+AD4APA-/SPAN+AD4APA-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-SPAN class+AD0-321021412-12062003+AD4APA-/SPAN+AD4APA-/SPAN+AD4APA-/FONT+AD4AJg-nbsp+ADsAPA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-SPAN class+AD0-321021412-12062003+AD4AJg-nbsp+ADs-Is this a desired behaviour out of a GW ? +ADw-SPAN class+AD0-124102811-12062003+AD4-Does Megaco speak anything about this varied response from the GW for the same package information sent (ie., based on which termination it is sent on ) ?+ACY-nbsp+ADs- +ADw-/SPAN+AD4APA-/DIV+AD4APA-/SPAN+AD4APA-/SPAN+AD4APA-/FONT+AD4- +ADw-DIV+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-SPAN class+AD0-877053106-11062003+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4APA-/FONT+AD4APA-/SPAN+AD4APA-/SPAN+AD4AJg-nbsp+ADsAPA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4APA-SPAN class+AD0-124102811-12062003+AD4-+ADw-SPAN class+AD0-877053106-11062003+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4AJg-nbsp+ADs-Appreciate your response on the same.+ADw-/FONT+AD4APA-/SPAN+AD4APA-/DIV+AD4- +ADw-DIV+AD4- +ADw-DIV+AD4APA-SPAN class+AD0-877053106-11062003+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4APA-/FONT+AD4APA-/SPAN+AD4AJg-nbsp+ADsAPA-/DIV+AD4- +ADw-DIV+AD4APA-SPAN class+AD0-877053106-11062003+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4-Thanks,+ADw-/FONT+AD4APA-/SPAN+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-SPAN class+AD0-877053106-11062003+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4-Nagalakshmi.+ACY-nbsp+ADsAJg-nbsp+ADs- +ADw-/FONT+AD4APA-/SPAN+AD4APA-/DIV+AD4APA-/SPAN+AD4APA-/FONT+AD4APA-/DIV+AD4APA-/BLOCKQUOTE+AD4APA-/BODY+AD4APA-/HTML+AD4- ------_=_NextPart_001_01C33148.8AA628EA-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Jun 13 11:16:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09376 for ; Fri, 13 Jun 2003 11:16:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DFFiJ19979 for megaco-archive@odin.ietf.org; Fri, 13 Jun 2003 11:15:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFFhm19976 for ; Fri, 13 Jun 2003 11:15:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09364 for ; Fri, 13 Jun 2003 11:15:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QqFC-00067q-00 for megaco-web-archive@ietf.org; Fri, 13 Jun 2003 11:13:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QqFA-00067f-00 for megaco-web-archive@ietf.org; Fri, 13 Jun 2003 11:13:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D1A3a08439; Thu, 12 Jun 2003 21:10:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D19tm08418 for ; Thu, 12 Jun 2003 21:09:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03519 for ; Thu, 12 Jun 2003 21:09:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qd2f-0007br-00 for megaco@ietf.org; Thu, 12 Jun 2003 21:07:45 -0400 Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx with esmtp (Exim 4.12) id 19Qd2e-0007bT-00 for megaco@ietf.org; Thu, 12 Jun 2003 21:07:44 -0400 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.2+Sun/8.12.3) with SMTP id h5D0w1QA014728 for ; Fri, 13 Jun 2003 08:58:01 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Fri Jun 13 09:10:14 2003 +0800 Received: from bellnet-mail1.sbell.com.cn ([172.24.208.21]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Jun 2003 09:10:13 +0800 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_01C33148.8AA628EA" Date: Fri, 13 Jun 2003 09:10:13 +0800 Message-ID: Thread-Topic: GW Response for package info Thread-Index: =?utf-7?Q?AcMw3XCqwsB/UMi3Q/ua5t61kI+5/A-i+BkEAAAH8cAA-?= =?utf-7?Q?+AD0-?= From: "FND-AD Wang JuLin" To: Cc: X-OriginalArrivalTime: 13 Jun 2003 01:10:13.0342 (UTC) FILETIME=[8AD977E0:01C33148] Subject: [Megaco] FW: +AFs-Megaco+AF0- GW Response for package info Sender: megaco-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_01C33148.8AA628EA Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit TDM Circuit Package is used to support TDM circuit terminations.So when it was used for rtp termination,error will be triggered. Our stack report 501 +ACI-Not implement+ACI- error in such case. -----Original Message----- From: Nagalakshmi H.G +AFs-mailto:nagalakshmi.gireesh+AEA-wipro.com+AF0- Sent: Thursday, June 12, 2003 8:14 PM To: megaco+AEA-ietf.org Subject: +AFs-Megaco+AF0- GW Response for package info Hi All, A GW's response to the package is different when it is sent on the ephemeral compared to when sent on the physical termination. +ACE-/1 +AFs-10.104.1.24+AF0-:2944 T+AD0-65662+AHs-C+AD0AJAB7-A+AD0AJAB7-M+AHs-O+AHs-MO+AD0-SR,xconn/phys+AD0-E1/04/06/3,tdmc/gain+AD0-2+AH0-,L+AHs-v+AD0-0 c+AD0-IN IP4 +ACQ- m+AD0-audio +ACQ- RTP/AVP 8 0 a+AD0-ptime:10 +AH0AfQB9AH0AfQ- +ACE-/1 +AFs-10.104.21.2+AF0-:2944 P +AD0- 65662 +AHs- C +AD0- +ACQ- +AHs- A +AD0- +ACQ- +AHs- ER +AD0- 442 +AHsAfQA7- The package tdmc cannot be used for a IP termination +AH0- +AH0- +AH0- But when tdmc/gain is sent on the physical , the GW does not send out a 442. Is this a desired behaviour out of a GW ? Does Megaco speak anything about this varied response from the GW for the same package information sent (ie., based on which termination it is sent on ) ? Appreciate your response on the same. Thanks, Nagalakshmi. ------_=_NextPart_001_01C33148.8AA628EA Content-Type: text/html; charset="utf-7" Content-Transfer-Encoding: 7bit +ADwAIQ-DOCTYPE HTML PUBLIC +ACI--//W3C//DTD HTML 4.0 Transitional//EN+ACIAPg- +ADw-HTML+AD4APA-HEAD+AD4- +ADw-META HTTP-EQUIV+AD0AIg-Content-Type+ACI- CONTENT+AD0AIg-text/html+ADs- charset+AD0-utf-7+ACIAPg- +ADw-TITLE+AD4-Message+ADw-/TITLE+AD4- +ADw-META content+AD0AIg-MSHTML 6.00.2712.300+ACI- name+AD0-GENERATOR+AD4APA-/HEAD+AD4- +ADw-BODY+AD4- +ADw-DIV+AD4APA-SPAN class+AD0-010215500-13062003+AD4APA-FONT color+AD0AIw-0000ff size+AD0-2+AD4-TDM Circuit Package is used to support TDM circuit terminations.So when it was used for rtp termination,error will be triggered. Our stack report 501 +ACI-Not implement+ACI- error in such case.+ADw-/FONT+AD4APA-/SPAN+AD4APA-/DIV+AD4- +ADw-BLOCKQUOTE dir+AD0-ltr style+AD0AIg-PADDING-LEFT: 5px+ADs- MARGIN-LEFT: 5px+ADs- BORDER-LEFT: +ACM-0000ff 2px solid+ADs- MARGIN-RIGHT: 0px+ACIAPg- +ADw-DIV class+AD0-OutlookMessageHeader dir+AD0-ltr align+AD0-left+AD4APA-FONT face+AD0-Tahoma size+AD0-2+AD4------Original Message-----+ADw-BR+AD4APA-B+AD4-From:+ADw-/B+AD4- Nagalakshmi H.G +AFs-mailto:nagalakshmi.gireesh+AEA-wipro.com+AF0APA-BR+AD4APA-B+AD4-Sent:+ADw-/B+AD4- Thursday, June 12, 2003 8:14 PM+ADw-BR+AD4APA-B+AD4-To:+ADw-/B+AD4- megaco+AEA-ietf.org+ADw-BR+AD4APA-B+AD4-Subject:+ADw-/B+AD4- +AFs-Megaco+AF0- GW Response for package info+ADw-BR+AD4APA-BR+AD4APA-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-SPAN class+AD0-321021412-12062003+AD4-Hi All,+ADw-/SPAN+AD4APA-/SPAN+AD4APA-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT size+AD0-2+AD4APA-FONT color+AD0AIw-0000ff+AD4APA-FONT face+AD0-Arial+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-/SPAN+AD4APA-/FONT+AD4APA-/FONT+AD4APA-/FONT+AD4AJg-nbsp+ADsAPA-/DIV+AD4- +ADw-DIV+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-FONT face+AD0-Arial+AD4APA-FONT color+AD0AIw-0000ff+AD4APA-FONT size+AD0-2+AD4AJg-nbsp+ADs-A GW's response to the package is different when it is sent on the ephemeral compared to when sent on the physical terminatio+ADw-SPAN class+AD0-321021412-12062003+AD4-n.+ADw-/SPAN+AD4APA-/FONT+AD4APA-/FONT+AD4APA-/FONT+AD4APA-/SPAN+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-FONT face+AD0-Arial+AD4APA-FONT color+AD0AIw-0000ff+AD4APA-FONT size+AD0-2+AD4APA-SPAN class+AD0-321021412-12062003+AD4APA-/SPAN+AD4APA-/FONT+AD4APA-/FONT+AD4APA-/FONT+AD4APA-/SPAN+AD4AJg-nbsp+ADsAPA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-SPAN class+AD0-321021412-12062003+AD4AJg-nbsp+ADsAIQ-/1 +AFs-10.104.1.24+AF0-:2944 T+AD0-65662+AHs-C+AD0AJAB7-A+AD0AJAB7-M+AHs-O+AHs-MO+AD0-SR,xconn/phys+AD0-E1/04/06/3,+ADw-STRONG+AD4-tdmc/gain+AD0-2+ADw-/STRONG+AD4AfQ-,L+AHs-v+AD0-0+ADw-BR+AD4-c+AD0-IN IP4 +ACQAPA-BR+AD4-m+AD0-audio +ACQ- RTP/AVP 8 0+ADw-BR+AD4-a+AD0-ptime:10+ADw-BR+AD4AfQB9AH0AfQB9ADw-BR+AD4APA-/SPAN+AD4APA-/SPAN+AD4APA-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-SPAN class+AD0-321021412-12062003+AD4AIQ-/1 +AFs-10.104.21.2+AF0-:2944+ADw-BR+AD4-P +AD0- 65662 +AHsAPA-BR+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- C +AD0- +ACQ- +AHsAPA-BR+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- A +AD0- +ACQ- +AHsAPA-BR+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- ER +AD0- +ADw-STRONG+AD4-442+ADw-/STRONG+AD4- +AHsAfQA7- The package tdmc cannot be used for a IP termination+ADw-BR+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- +AH0APA-BR+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- +AH0APA-BR+AD4AfQA8-BR+AD4APA-/SPAN+AD4APA-/SPAN+AD4APA-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-SPAN class+AD0-321021412-12062003+AD4AJg-nbsp+ADs-But when +ADw-STRONG+AD4-tdmc/gain+ADw-/STRONG+AD4- is sent on the physical , the GW does not send out a 442. +ADw-/SPAN+AD4APA-/SPAN+AD4APA-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-SPAN class+AD0-321021412-12062003+AD4APA-/SPAN+AD4APA-/SPAN+AD4APA-/FONT+AD4AJg-nbsp+ADsAPA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-SPAN class+AD0-321021412-12062003+AD4AJg-nbsp+ADs-Is this a desired behaviour out of a GW ? +ADw-SPAN class+AD0-124102811-12062003+AD4-Does Megaco speak anything about this varied response from the GW for the same package information sent (ie., based on which termination it is sent on ) ?+ACY-nbsp+ADs- +ADw-/SPAN+AD4APA-/DIV+AD4APA-/SPAN+AD4APA-/SPAN+AD4APA-/FONT+AD4- +ADw-DIV+AD4APA-SPAN class+AD0-124102811-12062003+AD4APA-SPAN class+AD0-877053106-11062003+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4APA-/FONT+AD4APA-/SPAN+AD4APA-/SPAN+AD4AJg-nbsp+ADsAPA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4APA-SPAN class+AD0-124102811-12062003+AD4-+ADw-SPAN class+AD0-877053106-11062003+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4AJg-nbsp+ADs-Appreciate your response on the same.+ADw-/FONT+AD4APA-/SPAN+AD4APA-/DIV+AD4- +ADw-DIV+AD4- +ADw-DIV+AD4APA-SPAN class+AD0-877053106-11062003+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4APA-/FONT+AD4APA-/SPAN+AD4AJg-nbsp+ADsAPA-/DIV+AD4- +ADw-DIV+AD4APA-SPAN class+AD0-877053106-11062003+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4-Thanks,+ADw-/FONT+AD4APA-/SPAN+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-SPAN class+AD0-877053106-11062003+AD4APA-FONT face+AD0-Arial color+AD0AIw-0000ff size+AD0-2+AD4-Nagalakshmi.+ACY-nbsp+ADsAJg-nbsp+ADs- +ADw-/FONT+AD4APA-/SPAN+AD4APA-/DIV+AD4APA-/SPAN+AD4APA-/FONT+AD4APA-/DIV+AD4APA-/BLOCKQUOTE+AD4APA-/BODY+AD4APA-/HTML+AD4- ------_=_NextPart_001_01C33148.8AA628EA-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Jun 13 12:55:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11998 for ; Fri, 13 Jun 2003 12:55:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFu2a23087; Fri, 13 Jun 2003 11:56:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFtYm23069 for ; Fri, 13 Jun 2003 11:55:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10414 for ; Fri, 13 Jun 2003 11:55:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qqrk-0006Kh-00 for megaco@ietf.org; Fri, 13 Jun 2003 11:53:24 -0400 Received: from web21405.mail.yahoo.com ([216.136.232.75]) by ietf-mx with smtp (Exim 4.12) id 19Qqrj-0006Kd-00 for megaco@ietf.org; Fri, 13 Jun 2003 11:53:23 -0400 Message-ID: <20030613155529.1162.qmail@web21405.mail.yahoo.com> Received: from [199.171.212.105] by web21405.mail.yahoo.com via HTTP; Fri, 13 Jun 2003 08:55:29 PDT Date: Fri, 13 Jun 2003 08:55:29 -0700 (PDT) From: Devendra Parkar To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Megaco] Specifying hierarchy for Term Id in Megaco Binary Encoding Sender: megaco-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: , In ABNF syntax for Megaco, the termination Id separates each level of hierachy by "/". How does it work for Megaco Binary? There is no identifier supported for Binary, which will differntiate levels. If I'm correct, the wildcard field is used only for specifying wildcards and not for specifying level within the hierarchy. This might be very basic question for most of you, but still your clarification will benifit a lot. Thanks, Devendra __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Jun 13 12:56:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12114 for ; Fri, 13 Jun 2003 12:56:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DGuWw31316 for megaco-archive@odin.ietf.org; Fri, 13 Jun 2003 12:56:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DGuWm31313 for ; Fri, 13 Jun 2003 12:56:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12075 for ; Fri, 13 Jun 2003 12:56:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qroj-0006ib-00 for megaco-web-archive@ietf.org; Fri, 13 Jun 2003 12:54:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qroj-0006iY-00 for megaco-web-archive@ietf.org; Fri, 13 Jun 2003 12:54:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFu2a23087; Fri, 13 Jun 2003 11:56:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFtYm23069 for ; Fri, 13 Jun 2003 11:55:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10414 for ; Fri, 13 Jun 2003 11:55:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qqrk-0006Kh-00 for megaco@ietf.org; Fri, 13 Jun 2003 11:53:24 -0400 Received: from web21405.mail.yahoo.com ([216.136.232.75]) by ietf-mx with smtp (Exim 4.12) id 19Qqrj-0006Kd-00 for megaco@ietf.org; Fri, 13 Jun 2003 11:53:23 -0400 Message-ID: <20030613155529.1162.qmail@web21405.mail.yahoo.com> Received: from [199.171.212.105] by web21405.mail.yahoo.com via HTTP; Fri, 13 Jun 2003 08:55:29 PDT Date: Fri, 13 Jun 2003 08:55:29 -0700 (PDT) From: Devendra Parkar To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Megaco] Specifying hierarchy for Term Id in Megaco Binary Encoding Sender: megaco-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: , In ABNF syntax for Megaco, the termination Id separates each level of hierachy by "/". How does it work for Megaco Binary? There is no identifier supported for Binary, which will differntiate levels. If I'm correct, the wildcard field is used only for specifying wildcards and not for specifying level within the hierarchy. This might be very basic question for most of you, but still your clarification will benifit a lot. Thanks, Devendra __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Jun 13 12:58:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12515 for ; Fri, 13 Jun 2003 12:58:47 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFU3a20791; Fri, 13 Jun 2003 11:30:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFTGm20709 for ; Fri, 13 Jun 2003 11:29:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09750 for ; Fri, 13 Jun 2003 11:29:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QqSI-0006CB-00 for megaco@ietf.org; Fri, 13 Jun 2003 11:27:06 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 19QqSH-0006Bs-00 for megaco@ietf.org; Fri, 13 Jun 2003 11:27:05 -0400 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 h5DFSar17140 for ; Fri, 13 Jun 2003 11:28:36 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jun 2003 11:28:37 -0400 Message-ID: From: "Kevin Boyle" To: FND-AD Wang JuLin , "Gireesh, Nagalakshmi [Business:WBNG:WT43]" Cc: megaco@ietf.org Subject: RE: [Megaco] FW: +AFs-Megaco+AF0- GW Response for package info Date: Fri, 13 Jun 2003 11:28:35 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Actually, TDMC can apply to any termination that could support ecan and gain. It would depend on the implementation. Quoting from H.248.1, Annex E.13: "This package may be used by any termination that supports gain and echo control. It was originally intended for use on TDM circuits but may be more widely used. New versions or extensions of this package should take non-TDM use into account." Further, I don't believe 501 would be the appropriate error code. If a termination doesn't support a package, wouldn't 440 ("Unsupported or Unknown Package") be more appropriate? Kevin -----Original Message----- From: FND-AD Wang JuLin [mailto:JuLin.Wang@alcatel-sbell.com.cn] Sent: Thursday, June 12, 2003 9:10 PM To: Gireesh, Nagalakshmi [Business:WBNG:WT43] Cc: megaco@ietf.org Subject: [Megaco] FW: +AFs-Megaco+AF0- GW Response for package info TDM Circuit Package is used to support TDM circuit terminations.So when it was used for rtp termination,error will be triggered. Our stack report 501 "Not implement" error in such case. -----Original Message----- From: Nagalakshmi H.G [mailto:nagalakshmi.gireesh@wipro.com] Sent: Thursday, June 12, 2003 8:14 PM To: megaco@ietf.org Subject: [Megaco] GW Response for package info Hi All, A GW's response to the package is different when it is sent on the ephemeral compared to when sent on the physical termination. !/1 [10.104.1.24]:2944 T=65662{C=${A=${M{O{MO=SR,xconn/phys=E1/04/06/3,tdmc/gain=2},L{v=0 c=IN IP4 $ m=audio $ RTP/AVP 8 0 a=ptime:10 }}}}} !/1 [10.104.21.2]:2944 P = 65662 { C = $ { A = $ { ER = 442 {}; The package tdmc cannot be used for a IP termination } } } But when tdmc/gain is sent on the physical , the GW does not send out a 442. Is this a desired behaviour out of a GW ? Does Megaco speak anything about this varied response from the GW for the same package information sent (ie., based on which termination it is sent on ) ? Appreciate your response on the same. Thanks, Nagalakshmi. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Jun 13 12:59:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12661 for ; Fri, 13 Jun 2003 12:59:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DGxWq03927 for megaco-archive@odin.ietf.org; Fri, 13 Jun 2003 12:59:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DGxWm03924 for ; Fri, 13 Jun 2003 12:59:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12614 for ; Fri, 13 Jun 2003 12:59:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qrrd-0006nw-00 for megaco-web-archive@ietf.org; Fri, 13 Jun 2003 12:57:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qrrc-0006nr-00 for megaco-web-archive@ietf.org; Fri, 13 Jun 2003 12:57:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFU3a20791; Fri, 13 Jun 2003 11:30:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFTGm20709 for ; Fri, 13 Jun 2003 11:29:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09750 for ; Fri, 13 Jun 2003 11:29:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QqSI-0006CB-00 for megaco@ietf.org; Fri, 13 Jun 2003 11:27:06 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 19QqSH-0006Bs-00 for megaco@ietf.org; Fri, 13 Jun 2003 11:27:05 -0400 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 h5DFSar17140 for ; Fri, 13 Jun 2003 11:28:36 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jun 2003 11:28:37 -0400 Message-ID: From: "Kevin Boyle" To: FND-AD Wang JuLin , "Gireesh, Nagalakshmi [Business:WBNG:WT43]" Cc: megaco@ietf.org Subject: RE: [Megaco] FW: +AFs-Megaco+AF0- GW Response for package info Date: Fri, 13 Jun 2003 11:28:35 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Actually, TDMC can apply to any termination that could support ecan and gain. It would depend on the implementation. Quoting from H.248.1, Annex E.13: "This package may be used by any termination that supports gain and echo control. It was originally intended for use on TDM circuits but may be more widely used. New versions or extensions of this package should take non-TDM use into account." Further, I don't believe 501 would be the appropriate error code. If a termination doesn't support a package, wouldn't 440 ("Unsupported or Unknown Package") be more appropriate? Kevin -----Original Message----- From: FND-AD Wang JuLin [mailto:JuLin.Wang@alcatel-sbell.com.cn] Sent: Thursday, June 12, 2003 9:10 PM To: Gireesh, Nagalakshmi [Business:WBNG:WT43] Cc: megaco@ietf.org Subject: [Megaco] FW: +AFs-Megaco+AF0- GW Response for package info TDM Circuit Package is used to support TDM circuit terminations.So when it was used for rtp termination,error will be triggered. Our stack report 501 "Not implement" error in such case. -----Original Message----- From: Nagalakshmi H.G [mailto:nagalakshmi.gireesh@wipro.com] Sent: Thursday, June 12, 2003 8:14 PM To: megaco@ietf.org Subject: [Megaco] GW Response for package info Hi All, A GW's response to the package is different when it is sent on the ephemeral compared to when sent on the physical termination. !/1 [10.104.1.24]:2944 T=65662{C=${A=${M{O{MO=SR,xconn/phys=E1/04/06/3,tdmc/gain=2},L{v=0 c=IN IP4 $ m=audio $ RTP/AVP 8 0 a=ptime:10 }}}}} !/1 [10.104.21.2]:2944 P = 65662 { C = $ { A = $ { ER = 442 {}; The package tdmc cannot be used for a IP termination } } } But when tdmc/gain is sent on the physical , the GW does not send out a 442. Is this a desired behaviour out of a GW ? Does Megaco speak anything about this varied response from the GW for the same package information sent (ie., based on which termination it is sent on ) ? Appreciate your response on the same. Thanks, Nagalakshmi. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Jun 13 13:24:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14323 for ; Fri, 13 Jun 2003 13:24:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D5l2a27491; Fri, 13 Jun 2003 01:47:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D5kBm27460 for ; Fri, 13 Jun 2003 01:46:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09728 for ; Fri, 13 Jun 2003 01:46:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QhM0-0001Pc-00 for megaco@ietf.org; Fri, 13 Jun 2003 01:44:00 -0400 Received: from [203.197.15.67] (helo=gatekeeper2.mahindrabt.com) by ietf-mx with esmtp (Exim 4.12) id 19QhLz-0001PZ-00 for megaco@ietf.org; Fri, 13 Jun 2003 01:43:59 -0400 Received: from thisdomain (mailscan.mahindrabt.com [10.2.0.50]) by gatekeeper2.mahindrabt.com (8.12.9/8.12.9) with ESMTP id h5D5jv53012281 for ; Fri, 13 Jun 2003 11:16:00 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Fri, 13 Jun 2003 10:50:15 +0530 Date: Fri, 13 Jun 2003 10:50:15 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: anilj@mahindrabt.com Received: from dscp00986 ([10.5.13.76]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id LAA26248; Fri, 13 Jun 2003 11:15:55 +0530 Message-ID: <003601c3316f$e9a1ece0$4c0d050a@mahindrabt.com> From: "Anil Jangam" To: "Nagalakshmi H.G" , References: <5A521CAA914BAF47A48A726DE83E7D240F5D8A@blr-k1-msg.wipro.com> Subject: Re: [Megaco] GW Response for package info Date: Fri, 13 Jun 2003 11:22:02 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C3319E.02F60FE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: megaco-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_0033_01C3319E.02F60FE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MessageHi Lakshmi, If you see the description of the 'tdmc' package, its mentioned that = 'tdmc' package was originally intended to use for the TDM circuits, but = my be more widely used. It also mentions that derivatives of this = package should be applicable for the non-TDM circuits as well. With this sight, reporting the some error code when applied the above = property (tdmc/gain) to the 'Ephemeral' termination is normal. But the = error code which you have returned (442) is not correct. The meaning of = 442 is different (442 talks about syntax error). More appropriate error = code you should return is 445 (see the details of 445). hope it helps. /anil. ----- Original Message -----=20 From: Nagalakshmi H.G=20 To: megaco@ietf.org=20 Sent: Thursday, June 12, 2003 5:59 PM Subject: [Megaco] GW Response for package info Hi All, A GW's response to the package is different when it is sent on the = ephemeral compared to when sent on the physical termination. !/1 [10.104.1.24]:2944 = T=3D65662{C=3D${A=3D${M{O{MO=3DSR,xconn/phys=3DE1/04/06/3,tdmc/gain=3D2},= L{v=3D0 c=3DIN IP4 $ m=3Daudio $ RTP/AVP 8 0 a=3Dptime:10 }}}}} !/1 [10.104.21.2]:2944 P =3D 65662 { C =3D $ { A =3D $ { ER =3D 442 {}; The package tdmc cannot be used = for a IP termination } } } But when tdmc/gain is sent on the physical , the GW does not send out = a 442.=20 Is this a desired behaviour out of a GW ? Does Megaco speak anything = about this varied response from the GW for the same package information = sent (ie., based on which termination it is sent on ) ? =20 Appreciate your response on the same. Thanks, Nagalakshmi. =20 ********************************************************* Disclaimer This message (including any attachments) contains=20 confidential information intended for a specific=20 individual and purpose, and is protected by law.=20 If you are not the intended recipient, you should=20 delete this message and are hereby notified that=20 any disclosure, copying, or distribution of this message, or the taking of any action based on it,=20 is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ------=_NextPart_000_0033_01C3319E.02F60FE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi Lakshmi,
 
If you see the description of the = 'tdmc' package,=20 its mentioned that 'tdmc' package was originally intended to use for the = TDM=20 circuits, but my be more widely used. It also mentions that derivatives = of this=20 package should be applicable for the non-TDM circuits as = well.
 
With this sight, reporting the = some error code=20 when applied the above property (tdmc/gain) to the 'Ephemeral' = termination=20 is normal. But the error code which you have returned (442) is not = correct. The=20 meaning of 442 is different (442 talks about syntax error). More = appropriate=20 error code you should return is 445 (see the details of = 445).
 
hope it helps.
/anil.
 
----- Original Message -----
From:=20 Nagalakshmi H.G =
Sent: Thursday, June 12, 2003 = 5:59=20 PM
Subject: [Megaco] GW Response = for package=20 info

Hi=20 All,
 
 A GW's response to the package is different when it is = sent on=20 the ephemeral compared to when sent on the physical termination.
 
 !/1=20 [10.104.1.24]:2944=20 = T=3D65662{C=3D${A=3D${M{O{MO=3DSR,xconn/phys=3DE1/04/06/3,tdmc/ga= in=3D2},L{v=3D0
c=3DIN=20 IP4 $
m=3Daudio $ RTP/AVP 8=20 0
a=3Dptime:10
}}}}}
!/1=20 [10.104.21.2]:2944
P =3D 65662=20 {
        C =3D $=20 = {
           &n= bsp;   =20 A =3D $=20 = {
           &n= bsp;           =20 ER =3D 442 {}; The package tdmc cannot be used for a = IP=20 = termination
         &nbs= p;     =20 }
       =20 }
}
 But = when=20 tdmc/gain is sent on the physical , the GW does not = send out=20 a 442.
 
 Is = this a=20 desired behaviour out of a GW ? Does = Megaco=20 speak anything about this varied response from the GW for the same = package=20 information sent (ie., based on which termination it is sent on ) = ? =20
 
 Appreciate your response on the=20 same.
 
Thanks,
Nagalakshmi.  =20

*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

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

Visit us at http://www.mahindrabt.com

------=_NextPart_000_0033_01C3319E.02F60FE0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Jun 13 13:25:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14479 for ; Fri, 13 Jun 2003 13:25:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DHPTB11357 for megaco-archive@odin.ietf.org; Fri, 13 Jun 2003 13:25:29 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHPSm11354 for ; Fri, 13 Jun 2003 13:25:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14381 for ; Fri, 13 Jun 2003 13:25:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsGj-0007HY-00 for megaco-web-archive@ietf.org; Fri, 13 Jun 2003 13:23:17 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QsGi-0007HN-00 for megaco-web-archive@ietf.org; Fri, 13 Jun 2003 13:23:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D5l2a27491; Fri, 13 Jun 2003 01:47:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D5kBm27460 for ; Fri, 13 Jun 2003 01:46:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09728 for ; Fri, 13 Jun 2003 01:46:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QhM0-0001Pc-00 for megaco@ietf.org; Fri, 13 Jun 2003 01:44:00 -0400 Received: from [203.197.15.67] (helo=gatekeeper2.mahindrabt.com) by ietf-mx with esmtp (Exim 4.12) id 19QhLz-0001PZ-00 for megaco@ietf.org; Fri, 13 Jun 2003 01:43:59 -0400 Received: from thisdomain (mailscan.mahindrabt.com [10.2.0.50]) by gatekeeper2.mahindrabt.com (8.12.9/8.12.9) with ESMTP id h5D5jv53012281 for ; Fri, 13 Jun 2003 11:16:00 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Fri, 13 Jun 2003 10:50:15 +0530 Date: Fri, 13 Jun 2003 10:50:15 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: anilj@mahindrabt.com Received: from dscp00986 ([10.5.13.76]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id LAA26248; Fri, 13 Jun 2003 11:15:55 +0530 Message-ID: <003601c3316f$e9a1ece0$4c0d050a@mahindrabt.com> From: "Anil Jangam" To: "Nagalakshmi H.G" , References: <5A521CAA914BAF47A48A726DE83E7D240F5D8A@blr-k1-msg.wipro.com> Subject: Re: [Megaco] GW Response for package info Date: Fri, 13 Jun 2003 11:22:02 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C3319E.02F60FE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: megaco-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_0033_01C3319E.02F60FE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MessageHi Lakshmi, If you see the description of the 'tdmc' package, its mentioned that = 'tdmc' package was originally intended to use for the TDM circuits, but = my be more widely used. It also mentions that derivatives of this = package should be applicable for the non-TDM circuits as well. With this sight, reporting the some error code when applied the above = property (tdmc/gain) to the 'Ephemeral' termination is normal. But the = error code which you have returned (442) is not correct. The meaning of = 442 is different (442 talks about syntax error). More appropriate error = code you should return is 445 (see the details of 445). hope it helps. /anil. ----- Original Message -----=20 From: Nagalakshmi H.G=20 To: megaco@ietf.org=20 Sent: Thursday, June 12, 2003 5:59 PM Subject: [Megaco] GW Response for package info Hi All, A GW's response to the package is different when it is sent on the = ephemeral compared to when sent on the physical termination. !/1 [10.104.1.24]:2944 = T=3D65662{C=3D${A=3D${M{O{MO=3DSR,xconn/phys=3DE1/04/06/3,tdmc/gain=3D2},= L{v=3D0 c=3DIN IP4 $ m=3Daudio $ RTP/AVP 8 0 a=3Dptime:10 }}}}} !/1 [10.104.21.2]:2944 P =3D 65662 { C =3D $ { A =3D $ { ER =3D 442 {}; The package tdmc cannot be used = for a IP termination } } } But when tdmc/gain is sent on the physical , the GW does not send out = a 442.=20 Is this a desired behaviour out of a GW ? Does Megaco speak anything = about this varied response from the GW for the same package information = sent (ie., based on which termination it is sent on ) ? =20 Appreciate your response on the same. Thanks, Nagalakshmi. =20 ********************************************************* Disclaimer This message (including any attachments) contains=20 confidential information intended for a specific=20 individual and purpose, and is protected by law.=20 If you are not the intended recipient, you should=20 delete this message and are hereby notified that=20 any disclosure, copying, or distribution of this message, or the taking of any action based on it,=20 is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ------=_NextPart_000_0033_01C3319E.02F60FE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi Lakshmi,
 
If you see the description of the = 'tdmc' package,=20 its mentioned that 'tdmc' package was originally intended to use for the = TDM=20 circuits, but my be more widely used. It also mentions that derivatives = of this=20 package should be applicable for the non-TDM circuits as = well.
 
With this sight, reporting the = some error code=20 when applied the above property (tdmc/gain) to the 'Ephemeral' = termination=20 is normal. But the error code which you have returned (442) is not = correct. The=20 meaning of 442 is different (442 talks about syntax error). More = appropriate=20 error code you should return is 445 (see the details of = 445).
 
hope it helps.
/anil.
 
----- Original Message -----
From:=20 Nagalakshmi H.G =
Sent: Thursday, June 12, 2003 = 5:59=20 PM
Subject: [Megaco] GW Response = for package=20 info

Hi=20 All,
 
 A GW's response to the package is different when it is = sent on=20 the ephemeral compared to when sent on the physical termination.
 
 !/1=20 [10.104.1.24]:2944=20 = T=3D65662{C=3D${A=3D${M{O{MO=3DSR,xconn/phys=3DE1/04/06/3,tdmc/ga= in=3D2},L{v=3D0
c=3DIN=20 IP4 $
m=3Daudio $ RTP/AVP 8=20 0
a=3Dptime:10
}}}}}
!/1=20 [10.104.21.2]:2944
P =3D 65662=20 {
        C =3D $=20 = {
           &n= bsp;   =20 A =3D $=20 = {
           &n= bsp;           =20 ER =3D 442 {}; The package tdmc cannot be used for a = IP=20 = termination
         &nbs= p;     =20 }
       =20 }
}
 But = when=20 tdmc/gain is sent on the physical , the GW does not = send out=20 a 442.
 
 Is = this a=20 desired behaviour out of a GW ? Does = Megaco=20 speak anything about this varied response from the GW for the same = package=20 information sent (ie., based on which termination it is sent on ) = ? =20
 
 Appreciate your response on the=20 same.
 
Thanks,
Nagalakshmi.  =20

*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

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

Visit us at http://www.mahindrabt.com

------=_NextPart_000_0033_01C3319E.02F60FE0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Sat Jun 14 03:21:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20905 for ; Sat, 14 Jun 2003 03:21:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E5n2a25971; Sat, 14 Jun 2003 01:49:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E5m9m25934 for ; Sat, 14 Jun 2003 01:48:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07337 for ; Sat, 14 Jun 2003 01:48:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R3rR-0004T5-00 for megaco@ietf.org; Sat, 14 Jun 2003 01:45:57 -0400 Received: from 205-158-62-158.outblaze.com ([205.158.62.158] helo=spf1.us.outblaze.com) by ietf-mx with smtp (Exim 4.12) id 19R3rQ-0004Sz-00 for megaco@ietf.org; Sat, 14 Jun 2003 01:45:56 -0400 Received: (qmail 7571 invoked from network); 14 Jun 2003 05:46:49 -0000 Received: from unknown (205.158.62.68) by spf1.us.outblaze.com with QMQP; 14 Jun 2003 05:46:49 -0000 Received: (qmail 37225 invoked from network); 14 Jun 2003 05:47:35 -0000 Received: from unknown (HELO ws1-5.us4.outblaze.com) (205.158.62.51) by 205-158-62-153.outblaze.com with SMTP; 14 Jun 2003 05:47:35 -0000 Received: (qmail 31245 invoked by uid 1001); 14 Jun 2003 05:47:35 -0000 Message-ID: <20030614054735.31244.qmail@mail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [202.54.26.125] by ws1-5.us4.outblaze.com with http for umsharma@techie.com; Sat, 14 Jun 2003 00:47:35 -0500 From: "Umesh Sharma" To: devendra_parkar@yahoo.com, megaco@ietf.org Date: Sat, 14 Jun 2003 00:47:35 -0500 Subject: Re: [Megaco] Specifying hierarchy for Term Id in Megaco Binary Encoding X-Originating-Ip: 202.54.26.125 X-Originating-Server: ws1-5.us4.outblaze.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: , Content-Transfer-Encoding: 7bit Hi, It seems that hierarchy can be 'provisioned'. Assume that Term Ids are 4 bytes each and each one representing a level in the hierarchy. A valid term id could then be 00000010 00000001 01111101 01111110. Regards, Umesh ----- Original Message ----- From: Devendra Parkar Date: Fri, 13 Jun 2003 08:55:29 -0700 (PDT) To: megaco@ietf.org Subject: [Megaco] Specifying hierarchy for Term Id in Megaco Binary Encoding > In ABNF syntax for Megaco, the termination Id > separates each level of hierachy by "/". How does it > work for Megaco Binary? There is no identifier > supported for Binary, which will differntiate levels. > If I'm correct, the wildcard field is used only for > specifying wildcards and not for specifying level > within the hierarchy. > > This might be very basic question for most of you, but > still your clarification will benifit a lot. > > Thanks, > > Devendra > > __________________________________ > Do you Yahoo!? > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > http://calendar.yahoo.com > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Sat Jun 14 03:22:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20933 for ; Sat, 14 Jun 2003 03:22:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5E7MBh11836 for megaco-archive@odin.ietf.org; Sat, 14 Jun 2003 03:22:11 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E7MBm11833 for ; Sat, 14 Jun 2003 03:22:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20927 for ; Sat, 14 Jun 2003 03:22:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R5KS-0005Dx-00 for megaco-web-archive@ietf.org; Sat, 14 Jun 2003 03:20:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19R5KR-0005Du-00 for megaco-web-archive@ietf.org; Sat, 14 Jun 2003 03:19:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E5n2a25971; Sat, 14 Jun 2003 01:49:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E5m9m25934 for ; Sat, 14 Jun 2003 01:48:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07337 for ; Sat, 14 Jun 2003 01:48:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R3rR-0004T5-00 for megaco@ietf.org; Sat, 14 Jun 2003 01:45:57 -0400 Received: from 205-158-62-158.outblaze.com ([205.158.62.158] helo=spf1.us.outblaze.com) by ietf-mx with smtp (Exim 4.12) id 19R3rQ-0004Sz-00 for megaco@ietf.org; Sat, 14 Jun 2003 01:45:56 -0400 Received: (qmail 7571 invoked from network); 14 Jun 2003 05:46:49 -0000 Received: from unknown (205.158.62.68) by spf1.us.outblaze.com with QMQP; 14 Jun 2003 05:46:49 -0000 Received: (qmail 37225 invoked from network); 14 Jun 2003 05:47:35 -0000 Received: from unknown (HELO ws1-5.us4.outblaze.com) (205.158.62.51) by 205-158-62-153.outblaze.com with SMTP; 14 Jun 2003 05:47:35 -0000 Received: (qmail 31245 invoked by uid 1001); 14 Jun 2003 05:47:35 -0000 Message-ID: <20030614054735.31244.qmail@mail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [202.54.26.125] by ws1-5.us4.outblaze.com with http for umsharma@techie.com; Sat, 14 Jun 2003 00:47:35 -0500 From: "Umesh Sharma" To: devendra_parkar@yahoo.com, megaco@ietf.org Date: Sat, 14 Jun 2003 00:47:35 -0500 Subject: Re: [Megaco] Specifying hierarchy for Term Id in Megaco Binary Encoding X-Originating-Ip: 202.54.26.125 X-Originating-Server: ws1-5.us4.outblaze.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, It seems that hierarchy can be 'provisioned'. Assume that Term Ids are 4 bytes each and each one representing a level in the hierarchy. A valid term id could then be 00000010 00000001 01111101 01111110. Regards, Umesh ----- Original Message ----- From: Devendra Parkar Date: Fri, 13 Jun 2003 08:55:29 -0700 (PDT) To: megaco@ietf.org Subject: [Megaco] Specifying hierarchy for Term Id in Megaco Binary Encoding > In ABNF syntax for Megaco, the termination Id > separates each level of hierachy by "/". How does it > work for Megaco Binary? There is no identifier > supported for Binary, which will differntiate levels. > If I'm correct, the wildcard field is used only for > specifying wildcards and not for specifying level > within the hierarchy. > > This might be very basic question for most of you, but > still your clarification will benifit a lot. > > Thanks, > > Devendra > > __________________________________ > Do you Yahoo!? > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > http://calendar.yahoo.com > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jun 16 14:24:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24212 for ; Mon, 16 Jun 2003 14:24:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GDt3a04345; Mon, 16 Jun 2003 09:55:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GDsQm04308 for ; Mon, 16 Jun 2003 09:54:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13996 for ; Mon, 16 Jun 2003 09:54:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RuP3-0002mP-00 for megaco@ietf.org; Mon, 16 Jun 2003 09:52:09 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19RuP2-0002mM-00 for megaco@ietf.org; Mon, 16 Jun 2003 09:52:08 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5GDtBcv030965 for ; Mon, 16 Jun 2003 15:55:11 +0200 Received: from super.du.uab.ericsson.se ([134.138.176.16]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGH0XWJ; Mon, 16 Jun 2003 15:56:06 +0200 Received: from bifur.du.uab.ericsson.se (daemon@bifur [134.138.177.75]) by super.du.uab.ericsson.se (8.10.1/8.10.1/erix-1.8) with ESMTP id h5GDsL509910 for ; Mon, 16 Jun 2003 15:54:21 +0200 (MET DST) Received: (from bmk@localhost) by bifur.du.uab.ericsson.se (8.11.6+Sun/8.9.1/client-1.0) id h5GDsKI16066; Mon, 16 Jun 2003 15:54:20 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16109.52236.206512.265782@gargle.gargle.HOWL> Date: Mon, 16 Jun 2003 15:54:20 +0200 From: Micael Karlberg Reply-To: micael.karlberg@ericsson.com Organization: Ericsson AB (EAB/UKH/KD) To: megaco@ietf.org X-Mailer: VM 7.07 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Subject: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Sender: megaco-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, In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch between the ABNF and the ASN.1 regarding indAudmediaDescriptor. My question is: Should the definition of ABNF indAudmediaDescriptor really be: indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm *(COMMA indAudmediaParm) RBRKT The comment for indAudmediaParm and the ASN.1 IndAudMediaDescriptor indicates that it should be a list. Or am I missing something? Also, see definition of mediaDescriptor! ABNF: ---- indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT ; at-most-once per item ; and either streamParm or streamDescriptor but not both indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / indAudterminationStateDescriptor) ASN.1: ----- IndAudMediaDescriptor ::= SEQUENCE { termStateDescr IndAudTerminationStateDescriptor OPTIONAL, streams CHOICE { oneStream IndAudStreamParms, multiStream SEQUENCE OF IndAudStreamDescriptor } OPTIONAL, ... } Regards, /BMK _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jun 16 14:25:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24257 for ; Mon, 16 Jun 2003 14:25:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GIPFr24263 for megaco-archive@odin.ietf.org; Mon, 16 Jun 2003 14:25:15 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GIPFm24260 for ; Mon, 16 Jun 2003 14:25:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24248 for ; Mon, 16 Jun 2003 14:25:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ryd7-0004su-00 for megaco-web-archive@ietf.org; Mon, 16 Jun 2003 14:22:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ryd7-0004sq-00 for megaco-web-archive@ietf.org; Mon, 16 Jun 2003 14:22:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GDt3a04345; Mon, 16 Jun 2003 09:55:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GDsQm04308 for ; Mon, 16 Jun 2003 09:54:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13996 for ; Mon, 16 Jun 2003 09:54:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RuP3-0002mP-00 for megaco@ietf.org; Mon, 16 Jun 2003 09:52:09 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19RuP2-0002mM-00 for megaco@ietf.org; Mon, 16 Jun 2003 09:52:08 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5GDtBcv030965 for ; Mon, 16 Jun 2003 15:55:11 +0200 Received: from super.du.uab.ericsson.se ([134.138.176.16]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGH0XWJ; Mon, 16 Jun 2003 15:56:06 +0200 Received: from bifur.du.uab.ericsson.se (daemon@bifur [134.138.177.75]) by super.du.uab.ericsson.se (8.10.1/8.10.1/erix-1.8) with ESMTP id h5GDsL509910 for ; Mon, 16 Jun 2003 15:54:21 +0200 (MET DST) Received: (from bmk@localhost) by bifur.du.uab.ericsson.se (8.11.6+Sun/8.9.1/client-1.0) id h5GDsKI16066; Mon, 16 Jun 2003 15:54:20 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16109.52236.206512.265782@gargle.gargle.HOWL> Date: Mon, 16 Jun 2003 15:54:20 +0200 From: Micael Karlberg Reply-To: micael.karlberg@ericsson.com Organization: Ericsson AB (EAB/UKH/KD) To: megaco@ietf.org X-Mailer: VM 7.07 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Subject: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch between the ABNF and the ASN.1 regarding indAudmediaDescriptor. My question is: Should the definition of ABNF indAudmediaDescriptor really be: indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm *(COMMA indAudmediaParm) RBRKT The comment for indAudmediaParm and the ASN.1 IndAudMediaDescriptor indicates that it should be a list. Or am I missing something? Also, see definition of mediaDescriptor! ABNF: ---- indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT ; at-most-once per item ; and either streamParm or streamDescriptor but not both indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / indAudterminationStateDescriptor) ASN.1: ----- IndAudMediaDescriptor ::= SEQUENCE { termStateDescr IndAudTerminationStateDescriptor OPTIONAL, streams CHOICE { oneStream IndAudStreamParms, multiStream SEQUENCE OF IndAudStreamDescriptor } OPTIONAL, ... } Regards, /BMK _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jun 16 23:56:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15461 for ; Mon, 16 Jun 2003 23:56:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H1Q1a22995; Mon, 16 Jun 2003 21:26:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H1PPm22966 for ; Mon, 16 Jun 2003 21:25:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12014 for ; Mon, 16 Jun 2003 21:25:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S5Bj-0001MW-00 for megaco@ietf.org; Mon, 16 Jun 2003 21:23:07 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19S5Bi-0001M5-00 for megaco@ietf.org; Mon, 16 Jun 2003 21:23:06 -0400 Received: from brsf10.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h5H0ufk17618; Tue, 17 Jun 2003 10:56:41 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h5H0x8X11311; Tue, 17 Jun 2003 10:59:08 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.176]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LZBXS0VG; Tue, 17 Jun 2003 10:58:57 +1000 Message-ID: <3EEE67CA.EB8B5993@ericsson.com.au> Date: Tue, 17 Jun 2003 10:58:51 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: micael.karlberg@ericsson.com CC: megaco@ietf.org Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? References: <16109.52236.206512.265782@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Micael, I don't understand what the problem is nor the comments in the ASN.1 you are referring to? If you are referring to the ::= SEQUENCE this is actually an ASN.1 construct that says that a sequence of information elements may be encoded, in this case "termStateDescr" & a choice of streams. This same information is represented by the ABNF. Regards, Christian Micael Karlberg wrote: > > Hi, > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch > between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > My question is: Should the definition of ABNF indAudmediaDescriptor > really be: > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > *(COMMA indAudmediaParm) RBRKT > > The comment for indAudmediaParm and the ASN.1 IndAudMediaDescriptor > indicates that it should be a list. Or am I missing something? > > Also, see definition of mediaDescriptor! > > ABNF: > ---- > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > > ; at-most-once per item > ; and either streamParm or streamDescriptor but not both > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > indAudterminationStateDescriptor) > > ASN.1: > ----- > IndAudMediaDescriptor ::= SEQUENCE > { > > termStateDescr IndAudTerminationStateDescriptor OPTIONAL, > streams CHOICE > { > oneStream IndAudStreamParms, > multiStream SEQUENCE OF IndAudStreamDescriptor > } OPTIONAL, > ... > } > > Regards, > /BMK > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jun 16 23:58:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15524 for ; Mon, 16 Jun 2003 23:58:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H3vrP01117 for megaco-archive@odin.ietf.org; Mon, 16 Jun 2003 23:57:53 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H3vem01114 for ; Mon, 16 Jun 2003 23:57:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15496 for ; Mon, 16 Jun 2003 23:57:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S7Z2-0002FN-00 for megaco-web-archive@ietf.org; Mon, 16 Jun 2003 23:55:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S7Z2-0002FK-00 for megaco-web-archive@ietf.org; Mon, 16 Jun 2003 23:55:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H1Q1a22995; Mon, 16 Jun 2003 21:26:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H1PPm22966 for ; Mon, 16 Jun 2003 21:25:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12014 for ; Mon, 16 Jun 2003 21:25:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S5Bj-0001MW-00 for megaco@ietf.org; Mon, 16 Jun 2003 21:23:07 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19S5Bi-0001M5-00 for megaco@ietf.org; Mon, 16 Jun 2003 21:23:06 -0400 Received: from brsf10.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h5H0ufk17618; Tue, 17 Jun 2003 10:56:41 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h5H0x8X11311; Tue, 17 Jun 2003 10:59:08 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.176]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LZBXS0VG; Tue, 17 Jun 2003 10:58:57 +1000 Message-ID: <3EEE67CA.EB8B5993@ericsson.com.au> Date: Tue, 17 Jun 2003 10:58:51 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: micael.karlberg@ericsson.com CC: megaco@ietf.org Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? References: <16109.52236.206512.265782@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Micael, I don't understand what the problem is nor the comments in the ASN.1 you are referring to? If you are referring to the ::= SEQUENCE this is actually an ASN.1 construct that says that a sequence of information elements may be encoded, in this case "termStateDescr" & a choice of streams. This same information is represented by the ABNF. Regards, Christian Micael Karlberg wrote: > > Hi, > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch > between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > My question is: Should the definition of ABNF indAudmediaDescriptor > really be: > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > *(COMMA indAudmediaParm) RBRKT > > The comment for indAudmediaParm and the ASN.1 IndAudMediaDescriptor > indicates that it should be a list. Or am I missing something? > > Also, see definition of mediaDescriptor! > > ABNF: > ---- > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > > ; at-most-once per item > ; and either streamParm or streamDescriptor but not both > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > indAudterminationStateDescriptor) > > ASN.1: > ----- > IndAudMediaDescriptor ::= SEQUENCE > { > > termStateDescr IndAudTerminationStateDescriptor OPTIONAL, > streams CHOICE > { > oneStream IndAudStreamParms, > multiStream SEQUENCE OF IndAudStreamDescriptor > } OPTIONAL, > ... > } > > Regards, > /BMK > > _______________________________________________ > 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 Jun 17 10:36:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19821 for ; Tue, 17 Jun 2003 10:36:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H7Y3a32055; Tue, 17 Jun 2003 03:34:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H7XLm32011 for ; Tue, 17 Jun 2003 03:33:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01922 for ; Tue, 17 Jun 2003 03:33:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SAvo-0003jV-00 for megaco@ietf.org; Tue, 17 Jun 2003 03:31:04 -0400 Received: from [203.124.156.99] (helo=chandgate2.mahindrabt.com) by ietf-mx with esmtp (Exim 4.12) id 19SAvm-0003jS-00 for megaco@ietf.org; Tue, 17 Jun 2003 03:31:03 -0400 Received: from thisdomain (mailscan.chand.mahindrabt.com [10.3.0.15]) by chandgate2.mahindrabt.com (8.12.9/8.12.9) with ESMTP id h5H7FmIu018247 for ; Tue, 17 Jun 2003 12:45:54 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Tue, 17 Jun 2003 13:06:40 +0530 Date: Tue, 17 Jun 2003 13:06:40 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: sunilv@mahindrabt.com Received: from dscp00980 ([10.5.11.125]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id NAA00509; Tue, 17 Jun 2003 13:02:55 +0530 Message-ID: <005001c334a2$94cb3ec0$7d0b050a@mahindrabt.com> From: "sunil vatnal" To: Cc: "krishnappa" Date: Tue, 17 Jun 2003 13:02:17 +0530 Organization: mbt MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C334D0.AE512020" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [Megaco] what is ALF ( Application Level Framing ) Sender: megaco-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_004D_01C334D0.AE512020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The megaco RFC 3015 suggests to implement ALF ( Application Level = Framing ) for the UDP transport. The meaning of the ALF is like this in = the RFC. " ALF is a set of techniques that allows an application, as opposed to a = stack, to affect how messages are sent to the other side. A typical ALF = technique is to allow an application to change the order of messages = sent when there is a queue after it has queued them. There is no formal = specification for ALF.=20 Implementors using IP/UDP with ALF SHOULD be aware of the = restrictions of the MTU on the maximum message size. " Most of the Megaco Protocol Stack developers say that they have achieved = the ALF by implementing reliable transactions by having retransmissions, = provisional transmissions, rejection of duplicate transactions...etc. My Question is .... =3D=3D=3D> Can we achieve ALF by ..=20 1) implementing reliable transactions with retransmission techniques = with long timer mechanism ( This is already implemented ) -- OR --=20 2) Fragment and reassemble the message or the media data depending = upon the MTU size. =20 -- OR -- 3) Divide the message or the media data into ADUs ( Application Data = Units ) and keep track=20 of the order of these. Please clarify.. Thanks and Regards, Sunil M Vatnal Mahindra British Telecom. ********************************************************* Disclaimer This message (including any attachments) contains=20 confidential information intended for a specific=20 individual and purpose, and is protected by law.=20 If you are not the intended recipient, you should=20 delete this message and are hereby notified that=20 any disclosure, copying, or distribution of this message, or the taking of any action based on it,=20 is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ------=_NextPart_000_004D_01C334D0.AE512020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
The megaco RFC 3015 suggests to = implement ALF (=20 Application Level Framing ) for the UDP transport. The meaning of the = ALF is=20 like this in the RFC.
 
" ALF is a set of = techniques that=20 allows an application, as opposed to a stack, to affect how messages are = sent to=20 the other side. A typical ALF technique is to allow an application to = change the=20 order of messages sent when there is a queue after it has queued = them. =20 There is no formal specification for ALF.
   Implementors = using=20 IP/UDP with ALF SHOULD be aware of the restrictions of the MTU on the = maximum=20 message size. "
 
Most of the Megaco Protocol Stack = developers say=20 that they have achieved the ALF by implementing reliable = transactions by=20 having retransmissions, provisional transmissions, rejection of = duplicate=20 transactions...etc.
 
My Question is .... =3D=3D=3D> Can = we achieve ALF by=20 ..
 
   1) implementing reliable = transactions=20 with retransmission techniques with long timer
       = mechanism ( This is=20 already implemented )
 
          &nbs= p;            = ;            =          --=20 OR --
 
   2) Fragment and reassemble = the message=20 or the media data depending upon the MTU size.
  
       =20             =    =20             =    =20     -- OR --
   3) Divide the message = or the=20 media data into ADUs ( Application Data Units ) and keep track =
       of = the order=20 of these.
 
   Please = clarify..
 
  Thanks and Regards,
  Sunil M Vatnal
  Mahindra British=20 Telecom.

*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

------=_NextPart_000_004D_01C334D0.AE512020-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jun 17 10:38:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19868 for ; Tue, 17 Jun 2003 10:38:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HEbep01641 for megaco-archive@odin.ietf.org; Tue, 17 Jun 2003 10:37:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEbdm01637 for ; Tue, 17 Jun 2003 10:37:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19844 for ; Tue, 17 Jun 2003 10:37:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SHYK-00004t-00 for megaco-web-archive@ietf.org; Tue, 17 Jun 2003 10:35:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SHYK-00004q-00 for megaco-web-archive@ietf.org; Tue, 17 Jun 2003 10:35:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H7Y3a32055; Tue, 17 Jun 2003 03:34:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H7XLm32011 for ; Tue, 17 Jun 2003 03:33:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01922 for ; Tue, 17 Jun 2003 03:33:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SAvo-0003jV-00 for megaco@ietf.org; Tue, 17 Jun 2003 03:31:04 -0400 Received: from [203.124.156.99] (helo=chandgate2.mahindrabt.com) by ietf-mx with esmtp (Exim 4.12) id 19SAvm-0003jS-00 for megaco@ietf.org; Tue, 17 Jun 2003 03:31:03 -0400 Received: from thisdomain (mailscan.chand.mahindrabt.com [10.3.0.15]) by chandgate2.mahindrabt.com (8.12.9/8.12.9) with ESMTP id h5H7FmIu018247 for ; Tue, 17 Jun 2003 12:45:54 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Tue, 17 Jun 2003 13:06:40 +0530 Date: Tue, 17 Jun 2003 13:06:40 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: sunilv@mahindrabt.com Received: from dscp00980 ([10.5.11.125]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id NAA00509; Tue, 17 Jun 2003 13:02:55 +0530 Message-ID: <005001c334a2$94cb3ec0$7d0b050a@mahindrabt.com> From: "sunil vatnal" To: Cc: "krishnappa" Date: Tue, 17 Jun 2003 13:02:17 +0530 Organization: mbt MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C334D0.AE512020" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [Megaco] what is ALF ( Application Level Framing ) Sender: megaco-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_004D_01C334D0.AE512020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The megaco RFC 3015 suggests to implement ALF ( Application Level = Framing ) for the UDP transport. The meaning of the ALF is like this in = the RFC. " ALF is a set of techniques that allows an application, as opposed to a = stack, to affect how messages are sent to the other side. A typical ALF = technique is to allow an application to change the order of messages = sent when there is a queue after it has queued them. There is no formal = specification for ALF.=20 Implementors using IP/UDP with ALF SHOULD be aware of the = restrictions of the MTU on the maximum message size. " Most of the Megaco Protocol Stack developers say that they have achieved = the ALF by implementing reliable transactions by having retransmissions, = provisional transmissions, rejection of duplicate transactions...etc. My Question is .... =3D=3D=3D> Can we achieve ALF by ..=20 1) implementing reliable transactions with retransmission techniques = with long timer mechanism ( This is already implemented ) -- OR --=20 2) Fragment and reassemble the message or the media data depending = upon the MTU size. =20 -- OR -- 3) Divide the message or the media data into ADUs ( Application Data = Units ) and keep track=20 of the order of these. Please clarify.. Thanks and Regards, Sunil M Vatnal Mahindra British Telecom. ********************************************************* Disclaimer This message (including any attachments) contains=20 confidential information intended for a specific=20 individual and purpose, and is protected by law.=20 If you are not the intended recipient, you should=20 delete this message and are hereby notified that=20 any disclosure, copying, or distribution of this message, or the taking of any action based on it,=20 is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ------=_NextPart_000_004D_01C334D0.AE512020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
The megaco RFC 3015 suggests to = implement ALF (=20 Application Level Framing ) for the UDP transport. The meaning of the = ALF is=20 like this in the RFC.
 
" ALF is a set of = techniques that=20 allows an application, as opposed to a stack, to affect how messages are = sent to=20 the other side. A typical ALF technique is to allow an application to = change the=20 order of messages sent when there is a queue after it has queued = them. =20 There is no formal specification for ALF.
   Implementors = using=20 IP/UDP with ALF SHOULD be aware of the restrictions of the MTU on the = maximum=20 message size. "
 
Most of the Megaco Protocol Stack = developers say=20 that they have achieved the ALF by implementing reliable = transactions by=20 having retransmissions, provisional transmissions, rejection of = duplicate=20 transactions...etc.
 
My Question is .... =3D=3D=3D> Can = we achieve ALF by=20 ..
 
   1) implementing reliable = transactions=20 with retransmission techniques with long timer
       = mechanism ( This is=20 already implemented )
 
          &nbs= p;            = ;            =          --=20 OR --
 
   2) Fragment and reassemble = the message=20 or the media data depending upon the MTU size.
  
       =20             =    =20             =    =20     -- OR --
   3) Divide the message = or the=20 media data into ADUs ( Application Data Units ) and keep track =
       of = the order=20 of these.
 
   Please = clarify..
 
  Thanks and Regards,
  Sunil M Vatnal
  Mahindra British=20 Telecom.

*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

------=_NextPart_000_004D_01C334D0.AE512020-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jun 17 14:02:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28807 for ; Tue, 17 Jun 2003 14:02:56 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBs2a20725; Tue, 17 Jun 2003 07:54:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBrvm20713 for ; Tue, 17 Jun 2003 07:53:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08054 for ; Tue, 17 Jun 2003 07:53:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SF00-00059C-00 for megaco@ietf.org; Tue, 17 Jun 2003 07:51:40 -0400 Received: from [203.124.156.99] (helo=chandgate2.mahindrabt.com) by ietf-mx with esmtp (Exim 4.12) id 19SEzy-000599-00 for megaco@ietf.org; Tue, 17 Jun 2003 07:51:38 -0400 Received: from thisdomain (mailscan.chand.mahindrabt.com [10.3.0.15]) by chandgate2.mahindrabt.com (8.12.9/8.12.9) with ESMTP id h5HBaNIu003451 for ; Tue, 17 Jun 2003 17:06:29 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Tue, 17 Jun 2003 17:27:25 +0530 Date: Tue, 17 Jun 2003 17:27:25 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: shail@mahindrabt.com Received: from dscp00947 ([10.5.12.184]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with ESMTP id RAA30531 for ; Tue, 17 Jun 2003 17:23:42 +0530 Message-ID: <012701c334c7$707f40f0$b80c050a@mahindrabt.com> Reply-To: "Shailendra" From: "Shailendra" To: Date: Tue, 17 Jun 2003 17:26:08 +0530 Organization: Mahibdra - British Telecom MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Megaco] Query regarding ALF in 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: , Content-Transfer-Encoding: 7bit Hi, The megaco RFC 3015 suggests to implement ALF ( Application Level Framing ) for the UDP transport. The meaning of the ALF is like this in the RFC. " ALF is a set of techniques that allows an application, as opposed to a stack, to affect how messages are sent to the other side. A typical ALF technique is to allow an application to change the order of messages sent when there is a queue after it has queued them. There is no formal specification for ALF. Implementors using IP/UDP with ALF SHOULD be aware of the restrictions of the MTU on the maximum message size. " Most of the Megaco Protocol Stack developers say that they have achieved the ALF by implementing reliable transactions by having retransmissions, provisional transmissions, rejection of duplicate transactions...etc. My Questions is .... Can we achieve ALF by .. 1) implementing reliable transactions with retransmission techniques with long timer mechanism ( This is already implemented ) -- OR -- 2) Fragment and reassemble the message or the media data depending upon the MTU size. -- OR -- 3) Divide the message or the media data into ADUs ( Application Data Units ) and keep track of the order of these. Please clarify.. Thanks and Regards, Shailendra ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue Jun 17 14:15:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29866 for ; Tue, 17 Jun 2003 14:15:54 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HIFPE12783 for megaco-archive@odin.ietf.org; Tue, 17 Jun 2003 14:15:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SKnz-000242-8T for megaco-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 14:03:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28850 for ; Tue, 17 Jun 2003 14:03:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SKlj-0002NS-00 for megaco-web-archive@ietf.org; Tue, 17 Jun 2003 14:01:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SKlj-0002NP-00 for megaco-web-archive@ietf.org; Tue, 17 Jun 2003 14:01:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBs2a20725; Tue, 17 Jun 2003 07:54:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBrvm20713 for ; Tue, 17 Jun 2003 07:53:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08054 for ; Tue, 17 Jun 2003 07:53:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SF00-00059C-00 for megaco@ietf.org; Tue, 17 Jun 2003 07:51:40 -0400 Received: from [203.124.156.99] (helo=chandgate2.mahindrabt.com) by ietf-mx with esmtp (Exim 4.12) id 19SEzy-000599-00 for megaco@ietf.org; Tue, 17 Jun 2003 07:51:38 -0400 Received: from thisdomain (mailscan.chand.mahindrabt.com [10.3.0.15]) by chandgate2.mahindrabt.com (8.12.9/8.12.9) with ESMTP id h5HBaNIu003451 for ; Tue, 17 Jun 2003 17:06:29 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Tue, 17 Jun 2003 17:27:25 +0530 Date: Tue, 17 Jun 2003 17:27:25 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: shail@mahindrabt.com Received: from dscp00947 ([10.5.12.184]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with ESMTP id RAA30531 for ; Tue, 17 Jun 2003 17:23:42 +0530 Message-ID: <012701c334c7$707f40f0$b80c050a@mahindrabt.com> Reply-To: "Shailendra" From: "Shailendra" To: Date: Tue, 17 Jun 2003 17:26:08 +0530 Organization: Mahibdra - British Telecom MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Megaco] Query regarding ALF in 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, The megaco RFC 3015 suggests to implement ALF ( Application Level Framing ) for the UDP transport. The meaning of the ALF is like this in the RFC. " ALF is a set of techniques that allows an application, as opposed to a stack, to affect how messages are sent to the other side. A typical ALF technique is to allow an application to change the order of messages sent when there is a queue after it has queued them. There is no formal specification for ALF. Implementors using IP/UDP with ALF SHOULD be aware of the restrictions of the MTU on the maximum message size. " Most of the Megaco Protocol Stack developers say that they have achieved the ALF by implementing reliable transactions by having retransmissions, provisional transmissions, rejection of duplicate transactions...etc. My Questions is .... Can we achieve ALF by .. 1) implementing reliable transactions with retransmission techniques with long timer mechanism ( This is already implemented ) -- OR -- 2) Fragment and reassemble the message or the media data depending upon the MTU size. -- OR -- 3) Divide the message or the media data into ADUs ( Application Data Units ) and keep track of the order of these. Please clarify.. Thanks and Regards, Shailendra ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jun 17 15:13:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04974 for ; Tue, 17 Jun 2003 15:13:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SL04-0003Sx-Jn; Tue, 17 Jun 2003 14:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SKDR-0000Pg-NI for megaco@optimus.ietf.org; Tue, 17 Jun 2003 13:25:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27382 for ; Tue, 17 Jun 2003 13:25:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SKBC-000218-00 for megaco@ietf.org; Tue, 17 Jun 2003 13:23:34 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19SKBB-000215-00 for megaco@ietf.org; Tue, 17 Jun 2003 13:23:33 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HHPjw2023457; Tue, 17 Jun 2003 19:25:46 +0200 (MEST) Received: from super.du.uab.ericsson.se ([134.138.176.16]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLLXQP; Tue, 17 Jun 2003 19:25:40 +0200 Received: from bifur.du.uab.ericsson.se (daemon@bifur [134.138.177.75]) by super.du.uab.ericsson.se (8.10.1/8.10.1/erix-1.8) with ESMTP id h5HHPi527486; Tue, 17 Jun 2003 19:25:44 +0200 (MET DST) Received: (from bmk@localhost) by bifur.du.uab.ericsson.se (8.11.6+Sun/8.9.1/client-1.0) id h5HHPi717185; Tue, 17 Jun 2003 19:25:44 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <16111.20238.893943.119367@gargle.gargle.HOWL> Date: Tue, 17 Jun 2003 19:25:34 +0200 From: Micael Karlberg Reply-To: micael.karlberg@ericsson.com Organization: Ericsson AB (EAB/UKH/KD) To: Christian Groves CC: megaco@ietf.org Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? In-Reply-To: <3EEE67CA.EB8B5993@ericsson.com.au> References: <16109.52236.206512.265782@gargle.gargle.HOWL> <3EEE67CA.EB8B5993@ericsson.com.au> X-Mailer: VM 7.07 under Emacs 21.1.1 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA04974 Hello Christian, Christian Groves writes: > Hello Micael, > > I don't understand what the problem is nor the comments in the ASN.1 you are > referring to? The comment ("at-most-once per item...") is in the ABNF. > If you are referring to the ::= SEQUENCE this is actually an ASN.1 > construct that says that a sequence of information elements may be encoded, in > this case "termStateDescr" & a choice of streams. This is how see it also. > This same information is represented by the ABNF. This I _cannot_ find! The comment in the ABNF seems to indicate that it should be as in the ASN.1 but the ABNF definition of the indAudmediaDescriptor allow for only one value of indAudmediaParm. Therefor my _question_ if the definition should'nt really be: indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm *(COMMA indAudmediaParm) RBRKT Also, the defintion of the mediaDescriptor strikes me as _very_ similar to my "proposal": mediaDescriptor = MediaToken LBRKT mediaParm *(COMMA mediaParm) RBRKT ; at-most one terminationStateDescriptor ; and either streamParm(s) or streamDescriptor(s) but not both mediaParm = (streamParm / streamDescriptor / terminationStateDescriptor) Regards, /BMK > > Regards, Christian > > Micael Karlberg wrote: > > > > Hi, > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch > > between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > > My question is: Should the definition of ABNF indAudmediaDescriptor > > really be: > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > *(COMMA indAudmediaParm) RBRKT > > > > The comment for indAudmediaParm and the ASN.1 IndAudMediaDescriptor > > indicates that it should be a list. Or am I missing something? > > > > Also, see definition of mediaDescriptor! > > > > ABNF: > > ---- > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > > > > ; at-most-once per item > > ; and either streamParm or streamDescriptor but not both > > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > > indAudterminationStateDescriptor) > > > > ASN.1: > > ----- > > IndAudMediaDescriptor ::= SEQUENCE > > { > > > > termStateDescr IndAudTerminationStateDescriptor OPTIONAL, > > streams CHOICE > > { > > oneStream IndAudStreamParms, > > multiStream SEQUENCE OF IndAudStreamDescriptor > > } OPTIONAL, > > ... > > } > > > > Regards, > > /BMK > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco -- Micael Karlberg Ericsson AB, Älvsjö Sweden Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development ECN: 851 5668 Mail: micael.karlberg@ericsson.com Fax: +46 8 727 5775 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue Jun 17 15:41:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06893 for ; Tue, 17 Jun 2003 15:41:08 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HJedq16459 for megaco-archive@odin.ietf.org; Tue, 17 Jun 2003 15:40:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SLtS-00019B-M6 for megaco-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 15:13:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04895 for ; Tue, 17 Jun 2003 15:13:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SLrE-0003el-00 for megaco-web-archive@ietf.org; Tue, 17 Jun 2003 15:11:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SLrD-0003eh-00 for megaco-web-archive@ietf.org; Tue, 17 Jun 2003 15:11:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SL04-0003Sx-Jn; Tue, 17 Jun 2003 14:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SKDR-0000Pg-NI for megaco@optimus.ietf.org; Tue, 17 Jun 2003 13:25:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27382 for ; Tue, 17 Jun 2003 13:25:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SKBC-000218-00 for megaco@ietf.org; Tue, 17 Jun 2003 13:23:34 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19SKBB-000215-00 for megaco@ietf.org; Tue, 17 Jun 2003 13:23:33 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HHPjw2023457; Tue, 17 Jun 2003 19:25:46 +0200 (MEST) Received: from super.du.uab.ericsson.se ([134.138.176.16]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLLXQP; Tue, 17 Jun 2003 19:25:40 +0200 Received: from bifur.du.uab.ericsson.se (daemon@bifur [134.138.177.75]) by super.du.uab.ericsson.se (8.10.1/8.10.1/erix-1.8) with ESMTP id h5HHPi527486; Tue, 17 Jun 2003 19:25:44 +0200 (MET DST) Received: (from bmk@localhost) by bifur.du.uab.ericsson.se (8.11.6+Sun/8.9.1/client-1.0) id h5HHPi717185; Tue, 17 Jun 2003 19:25:44 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <16111.20238.893943.119367@gargle.gargle.HOWL> Date: Tue, 17 Jun 2003 19:25:34 +0200 From: Micael Karlberg Reply-To: micael.karlberg@ericsson.com Organization: Ericsson AB (EAB/UKH/KD) To: Christian Groves CC: megaco@ietf.org Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? In-Reply-To: <3EEE67CA.EB8B5993@ericsson.com.au> References: <16109.52236.206512.265782@gargle.gargle.HOWL> <3EEE67CA.EB8B5993@ericsson.com.au> X-Mailer: VM 7.07 under Emacs 21.1.1 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA06893 Hello Christian, Christian Groves writes: > Hello Micael, > > I don't understand what the problem is nor the comments in the ASN.1 you are > referring to? The comment ("at-most-once per item...") is in the ABNF. > If you are referring to the ::= SEQUENCE this is actually an ASN.1 > construct that says that a sequence of information elements may be encoded, in > this case "termStateDescr" & a choice of streams. This is how see it also. > This same information is represented by the ABNF. This I _cannot_ find! The comment in the ABNF seems to indicate that it should be as in the ASN.1 but the ABNF definition of the indAudmediaDescriptor allow for only one value of indAudmediaParm. Therefor my _question_ if the definition should'nt really be: indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm *(COMMA indAudmediaParm) RBRKT Also, the defintion of the mediaDescriptor strikes me as _very_ similar to my "proposal": mediaDescriptor = MediaToken LBRKT mediaParm *(COMMA mediaParm) RBRKT ; at-most one terminationStateDescriptor ; and either streamParm(s) or streamDescriptor(s) but not both mediaParm = (streamParm / streamDescriptor / terminationStateDescriptor) Regards, /BMK > > Regards, Christian > > Micael Karlberg wrote: > > > > Hi, > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch > > between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > > My question is: Should the definition of ABNF indAudmediaDescriptor > > really be: > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > *(COMMA indAudmediaParm) RBRKT > > > > The comment for indAudmediaParm and the ASN.1 IndAudMediaDescriptor > > indicates that it should be a list. Or am I missing something? > > > > Also, see definition of mediaDescriptor! > > > > ABNF: > > ---- > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > > > > ; at-most-once per item > > ; and either streamParm or streamDescriptor but not both > > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > > indAudterminationStateDescriptor) > > > > ASN.1: > > ----- > > IndAudMediaDescriptor ::= SEQUENCE > > { > > > > termStateDescr IndAudTerminationStateDescriptor OPTIONAL, > > streams CHOICE > > { > > oneStream IndAudStreamParms, > > multiStream SEQUENCE OF IndAudStreamDescriptor > > } OPTIONAL, > > ... > > } > > > > Regards, > > /BMK > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco -- Micael Karlberg Ericsson AB, Älvsjö Sweden Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development ECN: 851 5668 Mail: micael.karlberg@ericsson.com Fax: +46 8 727 5775 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jun 17 15:41:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07110 for ; Tue, 17 Jun 2003 15:41:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SM3l-000356-FM; Tue, 17 Jun 2003 15:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SL1o-0003fW-MS for megaco@optimus.ietf.org; Tue, 17 Jun 2003 14:18:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00381 for ; Tue, 17 Jun 2003 14:17:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SKzZ-0002hP-00 for megaco@ietf.org; Tue, 17 Jun 2003 14:15:37 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 19SKzY-0002gc-00 for megaco@ietf.org; Tue, 17 Jun 2003 14:15:36 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5HIHLX19706 for ; Tue, 17 Jun 2003 14:17:21 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 14:17:19 -0400 Message-ID: From: "Kevin Boyle" To: sunil vatnal , megaco@ietf.org Cc: krishnappa Subject: RE: [Megaco] what is ALF ( Application Level Framing ) Date: Tue, 17 Jun 2003 14:17:13 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Comments inline. [KJBII] Kevin -----Original Message----- From: sunil vatnal [mailto:sunilv@mahindrabt.com] Sent: Tuesday, June 17, 2003 3:32 AM To: megaco@ietf.org Cc: krishnappa Subject: [Megaco] what is ALF ( Application Level Framing ) Hi, The megaco RFC 3015 suggests to implement ALF ( Application Level Framing ) for the UDP transport. The meaning of the ALF is like this in the RFC. " ALF is a set of techniques that allows an application, as opposed to a stack, to affect how messages are sent to the other side. A typical ALF technique is to allow an application to change the order of messages sent when there is a queue after it has queued them. There is no formal specification for ALF. Implementors using IP/UDP with ALF SHOULD be aware of the restrictions of the MTU on the maximum message size. " Most of the Megaco Protocol Stack developers say that they have achieved the ALF by implementing reliable transactions by having retransmissions, provisional transmissions, rejection of duplicate transactions...etc. My Question is .... ===> Can we achieve ALF by .. 1) implementing reliable transactions with retransmission techniques with long timer mechanism ( This is already implemented ) [KJBII] This is generally what is referred to as ALF. -- OR -- 2) Fragment and reassemble the message or the media data depending upon the MTU size. [KJBII] Message fragmentation and reassembly is generally part of the transport, and is not currently specified in the H.248 protocol. There is a published method for message fragmentation for UDP, but that is an add-on, and is (from my understanding) not widely supported, so your efforts may be in vain here. Some efforts have been made at doing message segmentation within the protocol, but that effort is currently stalled. -- OR -- 3) Divide the message or the media data into ADUs ( Application Data Units ) and keep track of the order of these. [KJBII] See the above about message segmentation. Please clarify.. Thanks and Regards, Sunil M Vatnal Mahindra British Telecom. ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jun 17 15:41:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07139 for ; Tue, 17 Jun 2003 15:41:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SM3m-00035K-4X; Tue, 17 Jun 2003 15:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SL2x-0003ig-VH for megaco@optimus.ietf.org; Tue, 17 Jun 2003 14:19:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00427 for ; Tue, 17 Jun 2003 14:19:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SL0i-0002iT-00 for megaco@ietf.org; Tue, 17 Jun 2003 14:16:48 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 19SL0h-0002ht-00 for megaco@ietf.org; Tue, 17 Jun 2003 14:16:47 -0400 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 h5HIIWa15457 for ; Tue, 17 Jun 2003 14:18:32 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 14:18:32 -0400 Message-ID: From: "Kevin Boyle" To: Christian Groves , micael.karlberg@ericsson.com Cc: megaco@ietf.org Subject: RE: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Date: Tue, 17 Jun 2003 14:18:28 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I have to concur with Christian... I don't see the problem. Is there something in particular that you don't see represented in one encoding that is in the other? Kevin -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] Sent: Monday, June 16, 2003 8:59 PM To: micael.karlberg@ericsson.com Cc: megaco@ietf.org Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Hello Micael, I don't understand what the problem is nor the comments in the ASN.1 you are referring to? If you are referring to the ::= SEQUENCE this is actually an ASN.1 construct that says that a sequence of information elements may be encoded, in this case "termStateDescr" & a choice of streams. This same information is represented by the ABNF. Regards, Christian Micael Karlberg wrote: > > Hi, > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch > between the ABNF and the ASN.1 regarding indAudmediaDescriptor. My > question is: Should the definition of ABNF indAudmediaDescriptor > really be: > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > *(COMMA indAudmediaParm) RBRKT > > The comment for indAudmediaParm and the ASN.1 IndAudMediaDescriptor > indicates that it should be a list. Or am I missing something? > > Also, see definition of mediaDescriptor! > > ABNF: > ---- > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > > ; at-most-once per item > ; and either streamParm or streamDescriptor but not both > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > indAudterminationStateDescriptor) > > ASN.1: > ----- > IndAudMediaDescriptor ::= SEQUENCE > { > > termStateDescr IndAudTerminationStateDescriptor OPTIONAL, > streams CHOICE > { > oneStream IndAudStreamParms, > multiStream SEQUENCE OF IndAudStreamDescriptor > } OPTIONAL, > ... > } > > Regards, > /BMK > > _______________________________________________ > 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 Jun 17 15:49:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07725 for ; Tue, 17 Jun 2003 15:49:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HJnCZ24084 for megaco-archive@odin.ietf.org; Tue, 17 Jun 2003 15:49:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SMKF-0004rp-4U for megaco-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 15:41:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06850 for ; Tue, 17 Jun 2003 15:40:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SMHy-00043M-00 for megaco-web-archive@ietf.org; Tue, 17 Jun 2003 15:38:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SMHx-00043E-00 for megaco-web-archive@ietf.org; Tue, 17 Jun 2003 15:38:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SM3l-000356-FM; Tue, 17 Jun 2003 15:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SL1o-0003fW-MS for megaco@optimus.ietf.org; Tue, 17 Jun 2003 14:18:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00381 for ; Tue, 17 Jun 2003 14:17:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SKzZ-0002hP-00 for megaco@ietf.org; Tue, 17 Jun 2003 14:15:37 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 19SKzY-0002gc-00 for megaco@ietf.org; Tue, 17 Jun 2003 14:15:36 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5HIHLX19706 for ; Tue, 17 Jun 2003 14:17:21 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 14:17:19 -0400 Message-ID: From: "Kevin Boyle" To: sunil vatnal , megaco@ietf.org Cc: krishnappa Subject: RE: [Megaco] what is ALF ( Application Level Framing ) Date: Tue, 17 Jun 2003 14:17:13 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Comments inline. [KJBII] Kevin -----Original Message----- From: sunil vatnal [mailto:sunilv@mahindrabt.com] Sent: Tuesday, June 17, 2003 3:32 AM To: megaco@ietf.org Cc: krishnappa Subject: [Megaco] what is ALF ( Application Level Framing ) Hi, The megaco RFC 3015 suggests to implement ALF ( Application Level Framing ) for the UDP transport. The meaning of the ALF is like this in the RFC. " ALF is a set of techniques that allows an application, as opposed to a stack, to affect how messages are sent to the other side. A typical ALF technique is to allow an application to change the order of messages sent when there is a queue after it has queued them. There is no formal specification for ALF. Implementors using IP/UDP with ALF SHOULD be aware of the restrictions of the MTU on the maximum message size. " Most of the Megaco Protocol Stack developers say that they have achieved the ALF by implementing reliable transactions by having retransmissions, provisional transmissions, rejection of duplicate transactions...etc. My Question is .... ===> Can we achieve ALF by .. 1) implementing reliable transactions with retransmission techniques with long timer mechanism ( This is already implemented ) [KJBII] This is generally what is referred to as ALF. -- OR -- 2) Fragment and reassemble the message or the media data depending upon the MTU size. [KJBII] Message fragmentation and reassembly is generally part of the transport, and is not currently specified in the H.248 protocol. There is a published method for message fragmentation for UDP, but that is an add-on, and is (from my understanding) not widely supported, so your efforts may be in vain here. Some efforts have been made at doing message segmentation within the protocol, but that effort is currently stalled. -- OR -- 3) Divide the message or the media data into ADUs ( Application Data Units ) and keep track of the order of these. [KJBII] See the above about message segmentation. Please clarify.. Thanks and Regards, Sunil M Vatnal Mahindra British Telecom. ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue Jun 17 15:51:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07813 for ; Tue, 17 Jun 2003 15:51:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HJpCD24436 for megaco-archive@odin.ietf.org; Tue, 17 Jun 2003 15:51:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SMKG-0004sa-QL for megaco-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 15:41:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06872 for ; Tue, 17 Jun 2003 15:41:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SMI2-00043g-00 for megaco-web-archive@ietf.org; Tue, 17 Jun 2003 15:38:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SMI0-00043c-00 for megaco-web-archive@ietf.org; Tue, 17 Jun 2003 15:38:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SM3m-00035K-4X; Tue, 17 Jun 2003 15:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SL2x-0003ig-VH for megaco@optimus.ietf.org; Tue, 17 Jun 2003 14:19:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00427 for ; Tue, 17 Jun 2003 14:19:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SL0i-0002iT-00 for megaco@ietf.org; Tue, 17 Jun 2003 14:16:48 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 19SL0h-0002ht-00 for megaco@ietf.org; Tue, 17 Jun 2003 14:16:47 -0400 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 h5HIIWa15457 for ; Tue, 17 Jun 2003 14:18:32 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 14:18:32 -0400 Message-ID: From: "Kevin Boyle" To: Christian Groves , micael.karlberg@ericsson.com Cc: megaco@ietf.org Subject: RE: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Date: Tue, 17 Jun 2003 14:18:28 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I have to concur with Christian... I don't see the problem. Is there something in particular that you don't see represented in one encoding that is in the other? Kevin -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] Sent: Monday, June 16, 2003 8:59 PM To: micael.karlberg@ericsson.com Cc: megaco@ietf.org Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Hello Micael, I don't understand what the problem is nor the comments in the ASN.1 you are referring to? If you are referring to the ::= SEQUENCE this is actually an ASN.1 construct that says that a sequence of information elements may be encoded, in this case "termStateDescr" & a choice of streams. This same information is represented by the ABNF. Regards, Christian Micael Karlberg wrote: > > Hi, > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch > between the ABNF and the ASN.1 regarding indAudmediaDescriptor. My > question is: Should the definition of ABNF indAudmediaDescriptor > really be: > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > *(COMMA indAudmediaParm) RBRKT > > The comment for indAudmediaParm and the ASN.1 IndAudMediaDescriptor > indicates that it should be a list. Or am I missing something? > > Also, see definition of mediaDescriptor! > > ABNF: > ---- > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > > ; at-most-once per item > ; and either streamParm or streamDescriptor but not both > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > indAudterminationStateDescriptor) > > ASN.1: > ----- > IndAudMediaDescriptor ::= SEQUENCE > { > > termStateDescr IndAudTerminationStateDescriptor OPTIONAL, > streams CHOICE > { > oneStream IndAudStreamParms, > multiStream SEQUENCE OF IndAudStreamDescriptor > } OPTIONAL, > ... > } > > Regards, > /BMK > > _______________________________________________ > 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 Jun 17 15:51:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07927 for ; Tue, 17 Jun 2003 15:51:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SMQ2-00063p-Ay; Tue, 17 Jun 2003 15:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SMAJ-0003ZC-Rt for megaco@optimus.ietf.org; Tue, 17 Jun 2003 15:30:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06344 for ; Tue, 17 Jun 2003 15:30:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SM85-0003ux-00 for megaco@ietf.org; Tue, 17 Jun 2003 15:28:29 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 19SM84-0003ui-00 for megaco@ietf.org; Tue, 17 Jun 2003 15:28:29 -0400 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 h5HJUEa24587 for ; Tue, 17 Jun 2003 15:30:14 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 15:30:14 -0400 Message-ID: From: "Kevin Boyle" To: micael.karlberg@ericsson.com, Christian Groves Cc: megaco@ietf.org Subject: RE: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Date: Tue, 17 Jun 2003 15:30:14 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Aha... I see the problem now. In binary, you can request info about several streams at once, but you may only request info about one stream in text. Is this an accurate summary? Seeing as this would be a syntax change, we need to know if anyone would have major heartburn over changing the syntax to fix this. If not, I will draft up an IG item to fix this... Speaking personally, I think this is a beneficial change, because it makes the syntax align between the expression of items within the media descriptor, and the audit of items within the media descriptor, as well as making both binary and text align in capability. Any other comments? Kevin -----Original Message----- From: Micael Karlberg [mailto:micael.karlberg@ericsson.com] Sent: Tuesday, June 17, 2003 1:26 PM To: Christian Groves Cc: megaco@ietf.org Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Hello Christian, Christian Groves writes: > Hello Micael, > > I don't understand what the problem is nor the comments in the ASN.1 you are > referring to? The comment ("at-most-once per item...") is in the ABNF. > If you are referring to the ::= SEQUENCE this is actually an ASN.1 > construct that says that a sequence of information elements may be encoded, in > this case "termStateDescr" & a choice of streams. This is how see it also. > This same information is represented by the ABNF. This I _cannot_ find! The comment in the ABNF seems to indicate that it should be as in the ASN.1 but the ABNF definition of the indAudmediaDescriptor allow for only one value of indAudmediaParm. Therefor my _question_ if the definition should'nt really be: indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm *(COMMA indAudmediaParm) RBRKT Also, the defintion of the mediaDescriptor strikes me as _very_ similar to my "proposal": mediaDescriptor = MediaToken LBRKT mediaParm *(COMMA mediaParm) RBRKT ; at-most one terminationStateDescriptor ; and either streamParm(s) or streamDescriptor(s) but not both mediaParm = (streamParm / streamDescriptor / terminationStateDescriptor) Regards, /BMK > > Regards, Christian > > Micael Karlberg wrote: > > > > Hi, > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch > > between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > > My question is: Should the definition of ABNF indAudmediaDescriptor > > really be: > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > *(COMMA indAudmediaParm) RBRKT > > > > The comment for indAudmediaParm and the ASN.1 IndAudMediaDescriptor > > indicates that it should be a list. Or am I missing something? > > > > Also, see definition of mediaDescriptor! > > > > ABNF: > > ---- > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > > > > ; at-most-once per item > > ; and either streamParm or streamDescriptor but not both > > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > > indAudterminationStateDescriptor) > > > > ASN.1: > > ----- > > IndAudMediaDescriptor ::= SEQUENCE > > { > > > > termStateDescr IndAudTerminationStateDescriptor OPTIONAL, > > streams CHOICE > > { > > oneStream IndAudStreamParms, > > multiStream SEQUENCE OF IndAudStreamDescriptor > > } OPTIONAL, > > ... > > } > > > > Regards, > > /BMK > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco -- Micael Karlberg Ericsson AB, Älvsjö Sweden Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development ECN: 851 5668 Mail: micael.karlberg@ericsson.com Fax: +46 8 727 5775 _______________________________________________ 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 Jun 17 16:06:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08428 for ; Tue, 17 Jun 2003 16:06:16 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HK5mB26340 for megaco-archive@odin.ietf.org; Tue, 17 Jun 2003 16:05:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SMUD-0006OV-Vm for megaco-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 15:51:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07795 for ; Tue, 17 Jun 2003 15:51:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SMRz-0004GS-00 for megaco-web-archive@ietf.org; Tue, 17 Jun 2003 15:49:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SMRz-0004GP-00 for megaco-web-archive@ietf.org; Tue, 17 Jun 2003 15:49:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SMQ2-00063p-Ay; Tue, 17 Jun 2003 15:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SMAJ-0003ZC-Rt for megaco@optimus.ietf.org; Tue, 17 Jun 2003 15:30:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06344 for ; Tue, 17 Jun 2003 15:30:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SM85-0003ux-00 for megaco@ietf.org; Tue, 17 Jun 2003 15:28:29 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 19SM84-0003ui-00 for megaco@ietf.org; Tue, 17 Jun 2003 15:28:29 -0400 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 h5HJUEa24587 for ; Tue, 17 Jun 2003 15:30:14 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 15:30:14 -0400 Message-ID: From: "Kevin Boyle" To: micael.karlberg@ericsson.com, Christian Groves Cc: megaco@ietf.org Subject: RE: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Date: Tue, 17 Jun 2003 15:30:14 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Aha... I see the problem now. In binary, you can request info about several streams at once, but you may only request info about one stream in text. Is this an accurate summary? Seeing as this would be a syntax change, we need to know if anyone would have major heartburn over changing the syntax to fix this. If not, I will draft up an IG item to fix this... Speaking personally, I think this is a beneficial change, because it makes the syntax align between the expression of items within the media descriptor, and the audit of items within the media descriptor, as well as making both binary and text align in capability. Any other comments? Kevin -----Original Message----- From: Micael Karlberg [mailto:micael.karlberg@ericsson.com] Sent: Tuesday, June 17, 2003 1:26 PM To: Christian Groves Cc: megaco@ietf.org Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Hello Christian, Christian Groves writes: > Hello Micael, > > I don't understand what the problem is nor the comments in the ASN.1 you are > referring to? The comment ("at-most-once per item...") is in the ABNF. > If you are referring to the ::= SEQUENCE this is actually an ASN.1 > construct that says that a sequence of information elements may be encoded, in > this case "termStateDescr" & a choice of streams. This is how see it also. > This same information is represented by the ABNF. This I _cannot_ find! The comment in the ABNF seems to indicate that it should be as in the ASN.1 but the ABNF definition of the indAudmediaDescriptor allow for only one value of indAudmediaParm. Therefor my _question_ if the definition should'nt really be: indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm *(COMMA indAudmediaParm) RBRKT Also, the defintion of the mediaDescriptor strikes me as _very_ similar to my "proposal": mediaDescriptor = MediaToken LBRKT mediaParm *(COMMA mediaParm) RBRKT ; at-most one terminationStateDescriptor ; and either streamParm(s) or streamDescriptor(s) but not both mediaParm = (streamParm / streamDescriptor / terminationStateDescriptor) Regards, /BMK > > Regards, Christian > > Micael Karlberg wrote: > > > > Hi, > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch > > between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > > My question is: Should the definition of ABNF indAudmediaDescriptor > > really be: > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > *(COMMA indAudmediaParm) RBRKT > > > > The comment for indAudmediaParm and the ASN.1 IndAudMediaDescriptor > > indicates that it should be a list. Or am I missing something? > > > > Also, see definition of mediaDescriptor! > > > > ABNF: > > ---- > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > > > > ; at-most-once per item > > ; and either streamParm or streamDescriptor but not both > > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > > indAudterminationStateDescriptor) > > > > ASN.1: > > ----- > > IndAudMediaDescriptor ::= SEQUENCE > > { > > > > termStateDescr IndAudTerminationStateDescriptor OPTIONAL, > > streams CHOICE > > { > > oneStream IndAudStreamParms, > > multiStream SEQUENCE OF IndAudStreamDescriptor > > } OPTIONAL, > > ... > > } > > > > Regards, > > /BMK > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco -- Micael Karlberg Ericsson AB, Älvsjö Sweden Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development ECN: 851 5668 Mail: micael.karlberg@ericsson.com Fax: +46 8 727 5775 _______________________________________________ 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 Jun 17 21:22:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17989 for ; Tue, 17 Jun 2003 21:22:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SReD-0000c8-AQ; Tue, 17 Jun 2003 21:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SRdd-0000bk-4M for megaco@optimus.ietf.org; Tue, 17 Jun 2003 21:21:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17931 for ; Tue, 17 Jun 2003 21:21:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SRbN-0006M9-00 for megaco@ietf.org; Tue, 17 Jun 2003 21:19:05 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19SRbM-0006M5-00 for megaco@ietf.org; Tue, 17 Jun 2003 21:19:05 -0400 Received: from smilevm.winphoria.com ([10.14.25.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 17 Jun 2003 21:20:51 -0400 Message-Id: <5.2.1.1.0.20030617201948.02d0c8a0@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 17 Jun 2003 21:19:09 -0400 To: "Kevin Boyle" , megaco@ietf.org From: Aleksandr Ryabin Subject: RE: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Cc: micael.karlberg@ericsson.com, Christian Groves In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 18 Jun 2003 01:20:51.0678 (UTC) FILETIME=[DB648FE0:01C33537] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA17989 Hi, While we are on topic. The following does not allow auditing for the whole local or remote SDP in ABNF: ; at-most-once indAudstreamParm = ( indAudlocalControlDescriptor ) ; SDP too complex to pull out individual pieces for audit, ; hence no individual audit for Local and Remote The question is why? I mean why does not it allow to audit *whole* local or remote SDP? E.g.: indAudstreamParm = ( indAudlocalControlDescriptor / LocalToken / RemoteToken) BTW ASN.1 does allow that, as well as individual pieces of SDPs. Thanks Aleks PS. Small nit in indAudauditReturnParameter (two slashes at the end): indAudauditReturnParameter = (indAudmediaDescriptor / / At 03:30 PM 6/17/2003, Kevin Boyle wrote: >Aha... I see the problem now. In binary, you can request info about several >streams at once, but you may only request info about one stream in text. Is >this an accurate summary? > >Seeing as this would be a syntax change, we need to know if anyone would >have major heartburn over changing the syntax to fix this. If not, I will >draft up an IG item to fix this... > >Speaking personally, I think this is a beneficial change, because it makes >the syntax align between the expression of items within the media >descriptor, and the audit of items within the media descriptor, as well as >making both binary and text align in capability. > >Any other comments? > >Kevin > >-----Original Message----- >From: Micael Karlberg [mailto:micael.karlberg@ericsson.com] >Sent: Tuesday, June 17, 2003 1:26 PM >To: Christian Groves >Cc: megaco@ietf.org >Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? > > >Hello Christian, > >Christian Groves writes: > > Hello Micael, > > > > I don't understand what the problem is nor the comments in the ASN.1 you >are > referring to? > >The comment ("at-most-once per item...") is in the ABNF. > > > If you are referring to the ::= SEQUENCE this is actually an ASN.1 > >construct that says that a sequence of information elements may be encoded, >in > this case "termStateDescr" & a choice of streams. > >This is how see it also. > > > This same information is represented by the ABNF. > >This I _cannot_ find! > >The comment in the ABNF seems to indicate that it should be as in >the ASN.1 but the ABNF definition of the indAudmediaDescriptor >allow for only one value of indAudmediaParm. > >Therefor my _question_ if the definition should'nt really be: > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > *(COMMA indAudmediaParm) RBRKT > >Also, the defintion of the mediaDescriptor strikes me as _very_ similar to >my "proposal": > > mediaDescriptor = MediaToken LBRKT mediaParm > *(COMMA mediaParm) RBRKT > > ; at-most one terminationStateDescriptor > ; and either streamParm(s) or streamDescriptor(s) but not both > mediaParm = (streamParm / streamDescriptor / > terminationStateDescriptor) > >Regards, > /BMK > > > > > Regards, Christian > > > > Micael Karlberg wrote: > > > > > > Hi, > > > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch > > >between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > > My >question is: Should the definition of ABNF indAudmediaDescriptor > > really >be: > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > > *(COMMA indAudmediaParm) RBRKT > > > > > > The comment for indAudmediaParm and the ASN.1 IndAudMediaDescriptor > > > indicates that it should be a list. Or am I missing something? > > > > > Also, see definition of mediaDescriptor! > > > > > > ABNF: > > > ---- > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > > > > > > ; at-most-once per item > > > ; and either streamParm or streamDescriptor but not both > > > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > > > indAudterminationStateDescriptor) > > > > > > ASN.1: > > > ----- > > > IndAudMediaDescriptor ::= SEQUENCE > > > { > > > > > > termStateDescr IndAudTerminationStateDescriptor OPTIONAL, > > > streams CHOICE > > > { > > > oneStream IndAudStreamParms, > > > multiStream SEQUENCE OF IndAudStreamDescriptor > > > } OPTIONAL, > > > ... > > > } > > > > > > Regards, > > > /BMK > > > > > > _______________________________________________ > > > Megaco mailing list > > > Megaco@ietf.org > > > https://www1.ietf.org/mailman/listinfo/megaco > >-- >Micael Karlberg Ericsson AB, Älvsjö Sweden >Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development >ECN: 851 5668 Mail: micael.karlberg@ericsson.com >Fax: +46 8 727 5775 > >_______________________________________________ >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 Jun 17 21:22:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18004 for ; Tue, 17 Jun 2003 21:22:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5I1M4Y02456 for megaco-archive@odin.ietf.org; Tue, 17 Jun 2003 21:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SReG-0000dX-Jk for megaco-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 21:22:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17963 for ; Tue, 17 Jun 2003 21:22:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SRc1-0006Mj-00 for megaco-web-archive@ietf.org; Tue, 17 Jun 2003 21:19:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SRbz-0006Mf-00 for megaco-web-archive@ietf.org; Tue, 17 Jun 2003 21:19:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SReD-0000c8-AQ; Tue, 17 Jun 2003 21:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SRdd-0000bk-4M for megaco@optimus.ietf.org; Tue, 17 Jun 2003 21:21:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17931 for ; Tue, 17 Jun 2003 21:21:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SRbN-0006M9-00 for megaco@ietf.org; Tue, 17 Jun 2003 21:19:05 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19SRbM-0006M5-00 for megaco@ietf.org; Tue, 17 Jun 2003 21:19:05 -0400 Received: from smilevm.winphoria.com ([10.14.25.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 17 Jun 2003 21:20:51 -0400 Message-Id: <5.2.1.1.0.20030617201948.02d0c8a0@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 17 Jun 2003 21:19:09 -0400 To: "Kevin Boyle" , megaco@ietf.org From: Aleksandr Ryabin Subject: RE: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Cc: micael.karlberg@ericsson.com, Christian Groves In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 18 Jun 2003 01:20:51.0678 (UTC) FILETIME=[DB648FE0:01C33537] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA18004 Hi, While we are on topic. The following does not allow auditing for the whole local or remote SDP in ABNF: ; at-most-once indAudstreamParm = ( indAudlocalControlDescriptor ) ; SDP too complex to pull out individual pieces for audit, ; hence no individual audit for Local and Remote The question is why? I mean why does not it allow to audit *whole* local or remote SDP? E.g.: indAudstreamParm = ( indAudlocalControlDescriptor / LocalToken / RemoteToken) BTW ASN.1 does allow that, as well as individual pieces of SDPs. Thanks Aleks PS. Small nit in indAudauditReturnParameter (two slashes at the end): indAudauditReturnParameter = (indAudmediaDescriptor / / At 03:30 PM 6/17/2003, Kevin Boyle wrote: >Aha... I see the problem now. In binary, you can request info about several >streams at once, but you may only request info about one stream in text. Is >this an accurate summary? > >Seeing as this would be a syntax change, we need to know if anyone would >have major heartburn over changing the syntax to fix this. If not, I will >draft up an IG item to fix this... > >Speaking personally, I think this is a beneficial change, because it makes >the syntax align between the expression of items within the media >descriptor, and the audit of items within the media descriptor, as well as >making both binary and text align in capability. > >Any other comments? > >Kevin > >-----Original Message----- >From: Micael Karlberg [mailto:micael.karlberg@ericsson.com] >Sent: Tuesday, June 17, 2003 1:26 PM >To: Christian Groves >Cc: megaco@ietf.org >Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? > > >Hello Christian, > >Christian Groves writes: > > Hello Micael, > > > > I don't understand what the problem is nor the comments in the ASN.1 you >are > referring to? > >The comment ("at-most-once per item...") is in the ABNF. > > > If you are referring to the ::= SEQUENCE this is actually an ASN.1 > >construct that says that a sequence of information elements may be encoded, >in > this case "termStateDescr" & a choice of streams. > >This is how see it also. > > > This same information is represented by the ABNF. > >This I _cannot_ find! > >The comment in the ABNF seems to indicate that it should be as in >the ASN.1 but the ABNF definition of the indAudmediaDescriptor >allow for only one value of indAudmediaParm. > >Therefor my _question_ if the definition should'nt really be: > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > *(COMMA indAudmediaParm) RBRKT > >Also, the defintion of the mediaDescriptor strikes me as _very_ similar to >my "proposal": > > mediaDescriptor = MediaToken LBRKT mediaParm > *(COMMA mediaParm) RBRKT > > ; at-most one terminationStateDescriptor > ; and either streamParm(s) or streamDescriptor(s) but not both > mediaParm = (streamParm / streamDescriptor / > terminationStateDescriptor) > >Regards, > /BMK > > > > > Regards, Christian > > > > Micael Karlberg wrote: > > > > > > Hi, > > > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch > > >between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > > My >question is: Should the definition of ABNF indAudmediaDescriptor > > really >be: > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > > *(COMMA indAudmediaParm) RBRKT > > > > > > The comment for indAudmediaParm and the ASN.1 IndAudMediaDescriptor > > > indicates that it should be a list. Or am I missing something? > > > > > Also, see definition of mediaDescriptor! > > > > > > ABNF: > > > ---- > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > > > > > > ; at-most-once per item > > > ; and either streamParm or streamDescriptor but not both > > > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > > > indAudterminationStateDescriptor) > > > > > > ASN.1: > > > ----- > > > IndAudMediaDescriptor ::= SEQUENCE > > > { > > > > > > termStateDescr IndAudTerminationStateDescriptor OPTIONAL, > > > streams CHOICE > > > { > > > oneStream IndAudStreamParms, > > > multiStream SEQUENCE OF IndAudStreamDescriptor > > > } OPTIONAL, > > > ... > > > } > > > > > > Regards, > > > /BMK > > > > > > _______________________________________________ > > > Megaco mailing list > > > Megaco@ietf.org > > > https://www1.ietf.org/mailman/listinfo/megaco > >-- >Micael Karlberg Ericsson AB, Älvsjö Sweden >Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development >ECN: 851 5668 Mail: micael.karlberg@ericsson.com >Fax: +46 8 727 5775 > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jun 18 00:09:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22005 for ; Wed, 18 Jun 2003 00:09:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SUFq-0004Ry-Eu; Wed, 18 Jun 2003 00:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SUEy-0004R2-1W for megaco@optimus.ietf.org; Wed, 18 Jun 2003 00:08:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21920 for ; Wed, 18 Jun 2003 00:08:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SUCi-0007K8-00 for megaco@ietf.org; Wed, 18 Jun 2003 00:05:48 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19SUCh-0007Jd-00 for megaco@ietf.org; Wed, 18 Jun 2003 00:05:47 -0400 Received: from brsf10.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h5I3urk11255; Wed, 18 Jun 2003 13:56:53 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h5I3xJP18734; Wed, 18 Jun 2003 13:59:20 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.236.90]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LZBXTYYQ; Wed, 18 Jun 2003 13:59:18 +1000 Message-ID: <3EEFE391.DEF3314@ericsson.com.au> Date: Wed, 18 Jun 2003 13:59:13 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Aleksandr Ryabin CC: Kevin Boyle , megaco@ietf.org, micael.karlberg@ericsson.com Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? References: <5.2.1.1.0.20030617201948.02d0c8a0@imap.winphoria.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ish7.ericsson.com.au id h5I3urk11255 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA22005 Hello Aleksandr, Megaco does allow you to audit a whole local or remote descriptor. This is the audit capability v1. Individual auditing was added in v2. We didn't add individual audit of a whole descriptor as this would duplicate functionality. It was decided not to allow auditing of individual segments of local and remote SDP (text encoding) because no body could come up with an appropriate method to do this and didn't know what the reply looked like. For the binary encoding it was very easy because all parameters follow a tag length value structure. You request the tag and you get back the value. Christian Aleksandr Ryabin wrote: > > Hi, > > While we are on topic. The following does not allow auditing for the whole > local or remote SDP in ABNF: > ; at-most-once > indAudstreamParm = ( indAudlocalControlDescriptor ) > ; SDP too complex to pull out individual pieces for audit, > ; hence no individual audit for Local and Remote > > The question is why? I mean why does not it allow to audit *whole* > local or remote SDP? E.g.: > indAudstreamParm = ( indAudlocalControlDescriptor / LocalToken / > RemoteToken) > > BTW ASN.1 does allow that, as well as individual pieces of SDPs. > > Thanks > Aleks > > PS. Small nit in indAudauditReturnParameter (two slashes at the end): > indAudauditReturnParameter = (indAudmediaDescriptor / / > > At 03:30 PM 6/17/2003, Kevin Boyle wrote: > >Aha... I see the problem now. In binary, you can request info about several > >streams at once, but you may only request info about one stream in text. Is > >this an accurate summary? > > > >Seeing as this would be a syntax change, we need to know if anyone would > >have major heartburn over changing the syntax to fix this. If not, I will > >draft up an IG item to fix this... > > > >Speaking personally, I think this is a beneficial change, because it makes > >the syntax align between the expression of items within the media > >descriptor, and the audit of items within the media descriptor, as well as > >making both binary and text align in capability. > > > >Any other comments? > > > >Kevin > > > >-----Original Message----- > >From: Micael Karlberg [mailto:micael.karlberg@ericsson.com] > >Sent: Tuesday, June 17, 2003 1:26 PM > >To: Christian Groves > >Cc: megaco@ietf.org > >Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? > > > > > >Hello Christian, > > > >Christian Groves writes: > > > Hello Micael, > > > > > > I don't understand what the problem is nor the comments in the ASN.1 you > >are > referring to? > > > >The comment ("at-most-once per item...") is in the ABNF. > > > > > If you are referring to the ::= SEQUENCE this is actually an ASN.1 > > >construct that says that a sequence of information elements may be encoded, > >in > this case "termStateDescr" & a choice of streams. > > > >This is how see it also. > > > > > This same information is represented by the ABNF. > > > >This I _cannot_ find! > > > >The comment in the ABNF seems to indicate that it should be as in > >the ASN.1 but the ABNF definition of the indAudmediaDescriptor > >allow for only one value of indAudmediaParm. > > > >Therefor my _question_ if the definition should'nt really be: > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > *(COMMA indAudmediaParm) RBRKT > > > >Also, the defintion of the mediaDescriptor strikes me as _very_ similar to > >my "proposal": > > > > mediaDescriptor = MediaToken LBRKT mediaParm > > *(COMMA mediaParm) RBRKT > > > > ; at-most one terminationStateDescriptor > > ; and either streamParm(s) or streamDescriptor(s) but not both > > mediaParm = (streamParm / streamDescriptor / > > terminationStateDescriptor) > > > >Regards, > > /BMK > > > > > > > > Regards, Christian > > > > > > Micael Karlberg wrote: > > > > > > > > Hi, > > > > > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch > > > >between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > > My > >question is: Should the definition of ABNF indAudmediaDescriptor > > really > >be: > > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > > > *(COMMA indAudmediaParm) RBRKT > > > > > > > > The comment for indAudmediaParm and the ASN.1 IndAudMediaDescriptor > > > > indicates that it should be a list. Or am I missing something? > > > > > > Also, see definition of mediaDescriptor! > > > > > > > > ABNF: > > > > ---- > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > > > > > > > > ; at-most-once per item > > > > ; and either streamParm or streamDescriptor but not both > > > > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > > > > indAudterminationStateDescriptor) > > > > > > > > ASN.1: > > > > ----- > > > > IndAudMediaDescriptor ::= SEQUENCE > > > > { > > > > > > > > termStateDescr IndAudTerminationStateDescriptor OPTIONAL, > > > > streams CHOICE > > > > { > > > > oneStream IndAudStreamParms, > > > > multiStream SEQUENCE OF IndAudStreamDescriptor > > > > } OPTIONAL, > > > > ... > > > > } > > > > > > > > Regards, > > > > /BMK > > > > > > > > _______________________________________________ > > > > Megaco mailing list > > > > Megaco@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/megaco > > > >-- > >Micael Karlberg Ericsson AB, Älvsjö Sweden > >Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development > >ECN: 851 5668 Mail: micael.karlberg@ericsson.com > >Fax: +46 8 727 5775 > > > >_______________________________________________ > >Megaco mailing list > >Megaco@ietf.org > >https://www1.ietf.org/mailman/listinfo/megaco > > > >_______________________________________________ > >Megaco mailing list > >Megaco@ietf.org > >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Jun 18 00:09:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22031 for ; Wed, 18 Jun 2003 00:09:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5I496l17243 for megaco-archive@odin.ietf.org; Wed, 18 Jun 2003 00:09:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SUFu-0004U2-1Z for megaco-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 00:09:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21976 for ; Wed, 18 Jun 2003 00:09:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SUDe-0007Kz-00 for megaco-web-archive@ietf.org; Wed, 18 Jun 2003 00:06:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SUDd-0007Kv-00 for megaco-web-archive@ietf.org; Wed, 18 Jun 2003 00:06:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SUFp-0004Ro-RG; Wed, 18 Jun 2003 00:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SUEw-0004Qx-3I for megaco@optimus.ietf.org; Wed, 18 Jun 2003 00:08:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21917 for ; Wed, 18 Jun 2003 00:08:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SUCg-0007Jz-00 for megaco@ietf.org; Wed, 18 Jun 2003 00:05:46 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19SUCe-0007Jd-00 for megaco@ietf.org; Wed, 18 Jun 2003 00:05:45 -0400 Received: from brsf10.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h5I3qpk11003; Wed, 18 Jun 2003 13:52:51 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h5I3tHP17982; Wed, 18 Jun 2003 13:55:17 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.236.90]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LZBXTYW1; Wed, 18 Jun 2003 13:55:16 +1000 Message-ID: <3EEFE29F.FA336106@ericsson.com.au> Date: Wed, 18 Jun 2003 13:55:11 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Boyle CC: micael.karlberg@ericsson.com, megaco@ietf.org Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? References: Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ish7.ericsson.com.au id h5I3qpk11003 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA22031 G'Day Kevin and Micael, I still don't see a problem. indAudterminationAudit allows you to request multiple values: indAudterminationAudit = indAudauditReturnParameter *(COMMA indAudauditReturnParameter) indAudauditReturnParameter = (indAudmediaDescriptor / / indAudeventsDescriptor / indAudsignalsDescriptor / indAuddigitMapDescriptor / indAudeventBufferDescriptor / indAudstatisticsDescriptor / indAudpackagesDescriptor) indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT This allows you to request several streams. So the capabilities are aligned. The reason we have the indAudstreamParm / indAudstreamDescriptor is to allow for the case where no streamid is given. Regards, Christian Kevin Boyle wrote: > > Aha... I see the problem now. In binary, you can request info about several > streams at once, but you may only request info about one stream in text. Is > this an accurate summary? > > Seeing as this would be a syntax change, we need to know if anyone would have > major heartburn over changing the syntax to fix this. If not, I will draft up > an IG item to fix this... > > Speaking personally, I think this is a beneficial change, because it makes the > syntax align between the expression of items within the media descriptor, and > the audit of items within the media descriptor, as well as making both binary > and text align in capability. > > Any other comments? > > Kevin > > -----Original Message----- > From: Micael Karlberg [mailto:micael.karlberg@ericsson.com] > Sent: Tuesday, June 17, 2003 1:26 PM > To: Christian Groves > Cc: megaco@ietf.org > Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? > > Hello Christian, > > Christian Groves writes: > > Hello Micael, > > > > I don't understand what the problem is nor the comments in the ASN.1 you > are > referring to? > > The comment ("at-most-once per item...") is in the ABNF. > > > If you are referring to the ::= SEQUENCE this is actually an ASN.1 > > construct that says that a sequence of information elements may be encoded, > in > this case "termStateDescr" & a choice of streams. > > This is how see it also. > > > This same information is represented by the ABNF. > > This I _cannot_ find! > > The comment in the ABNF seems to indicate that it should be as in > the ASN.1 but the ABNF definition of the indAudmediaDescriptor > allow for only one value of indAudmediaParm. > > Therefor my _question_ if the definition should'nt really be: > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > *(COMMA indAudmediaParm) RBRKT > > Also, the defintion of the mediaDescriptor strikes me as _very_ similar to my > "proposal": > > mediaDescriptor = MediaToken LBRKT mediaParm > *(COMMA mediaParm) RBRKT > > ; at-most one terminationStateDescriptor > ; and either streamParm(s) or streamDescriptor(s) but not both > mediaParm = (streamParm / streamDescriptor / > terminationStateDescriptor) > > Regards, > /BMK > > > > > Regards, Christian > > > > Micael Karlberg wrote: > > > > > > Hi, > > > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch > > > between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > > My > question is: Should the definition of ABNF indAudmediaDescriptor > > really > be: > > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > > *(COMMA indAudmediaParm) RBRKT > > > > > > The comment for indAudmediaParm and the ASN.1 IndAudMediaDescriptor > > > indicates that it should be a list. Or am I missing something? > > > > > > Also, see definition of mediaDescriptor! > > > > > > ABNF: > > > ---- > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > > > > > > ; at-most-once per item > > > ; and either streamParm or streamDescriptor but not both > > > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > > > indAudterminationStateDescriptor) > > > > > > ASN.1: > > > ----- > > > IndAudMediaDescriptor ::= SEQUENCE > > > { > > > > > > termStateDescr IndAudTerminationStateDescriptor OPTIONAL, > > > streams CHOICE > > > { > > > oneStream IndAudStreamParms, > > > multiStream SEQUENCE OF IndAudStreamDescriptor > > > } OPTIONAL, > > > ... > > > } > > > > > > Regards, > > > /BMK > > > > > > _______________________________________________ > > > Megaco mailing list > > > Megaco@ietf.org > > > https://www1.ietf.org/mailman/listinfo/megaco > > -- > Micael Karlberg Ericsson AB, Älvsjö Sweden > Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development > ECN: 851 5668 Mail: micael.karlberg@ericsson.com > Fax: +46 8 727 5775 > > _______________________________________________ > 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 Jun 18 00:09:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22046 for ; Wed, 18 Jun 2003 00:09:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5I496417260 for megaco-archive@odin.ietf.org; Wed, 18 Jun 2003 00:09:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SUFu-0004UJ-Q7 for megaco-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 00:09:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21982 for ; Wed, 18 Jun 2003 00:09:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SUDf-0007L2-00 for megaco-web-archive@ietf.org; Wed, 18 Jun 2003 00:06:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SUDd-0007Kw-00 for megaco-web-archive@ietf.org; Wed, 18 Jun 2003 00:06:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SUFq-0004Ry-Eu; Wed, 18 Jun 2003 00:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SUEy-0004R2-1W for megaco@optimus.ietf.org; Wed, 18 Jun 2003 00:08:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21920 for ; Wed, 18 Jun 2003 00:08:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SUCi-0007K8-00 for megaco@ietf.org; Wed, 18 Jun 2003 00:05:48 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19SUCh-0007Jd-00 for megaco@ietf.org; Wed, 18 Jun 2003 00:05:47 -0400 Received: from brsf10.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h5I3urk11255; Wed, 18 Jun 2003 13:56:53 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h5I3xJP18734; Wed, 18 Jun 2003 13:59:20 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.236.90]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LZBXTYYQ; Wed, 18 Jun 2003 13:59:18 +1000 Message-ID: <3EEFE391.DEF3314@ericsson.com.au> Date: Wed, 18 Jun 2003 13:59:13 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Aleksandr Ryabin CC: Kevin Boyle , megaco@ietf.org, micael.karlberg@ericsson.com Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? References: <5.2.1.1.0.20030617201948.02d0c8a0@imap.winphoria.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ish7.ericsson.com.au id h5I3urk11255 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA22046 Hello Aleksandr, Megaco does allow you to audit a whole local or remote descriptor. This is the audit capability v1. Individual auditing was added in v2. We didn't add individual audit of a whole descriptor as this would duplicate functionality. It was decided not to allow auditing of individual segments of local and remote SDP (text encoding) because no body could come up with an appropriate method to do this and didn't know what the reply looked like. For the binary encoding it was very easy because all parameters follow a tag length value structure. You request the tag and you get back the value. Christian Aleksandr Ryabin wrote: > > Hi, > > While we are on topic. The following does not allow auditing for the whole > local or remote SDP in ABNF: > ; at-most-once > indAudstreamParm = ( indAudlocalControlDescriptor ) > ; SDP too complex to pull out individual pieces for audit, > ; hence no individual audit for Local and Remote > > The question is why? I mean why does not it allow to audit *whole* > local or remote SDP? E.g.: > indAudstreamParm = ( indAudlocalControlDescriptor / LocalToken / > RemoteToken) > > BTW ASN.1 does allow that, as well as individual pieces of SDPs. > > Thanks > Aleks > > PS. Small nit in indAudauditReturnParameter (two slashes at the end): > indAudauditReturnParameter = (indAudmediaDescriptor / / > > At 03:30 PM 6/17/2003, Kevin Boyle wrote: > >Aha... I see the problem now. In binary, you can request info about several > >streams at once, but you may only request info about one stream in text. Is > >this an accurate summary? > > > >Seeing as this would be a syntax change, we need to know if anyone would > >have major heartburn over changing the syntax to fix this. If not, I will > >draft up an IG item to fix this... > > > >Speaking personally, I think this is a beneficial change, because it makes > >the syntax align between the expression of items within the media > >descriptor, and the audit of items within the media descriptor, as well as > >making both binary and text align in capability. > > > >Any other comments? > > > >Kevin > > > >-----Original Message----- > >From: Micael Karlberg [mailto:micael.karlberg@ericsson.com] > >Sent: Tuesday, June 17, 2003 1:26 PM > >To: Christian Groves > >Cc: megaco@ietf.org > >Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? > > > > > >Hello Christian, > > > >Christian Groves writes: > > > Hello Micael, > > > > > > I don't understand what the problem is nor the comments in the ASN.1 you > >are > referring to? > > > >The comment ("at-most-once per item...") is in the ABNF. > > > > > If you are referring to the ::= SEQUENCE this is actually an ASN.1 > > >construct that says that a sequence of information elements may be encoded, > >in > this case "termStateDescr" & a choice of streams. > > > >This is how see it also. > > > > > This same information is represented by the ABNF. > > > >This I _cannot_ find! > > > >The comment in the ABNF seems to indicate that it should be as in > >the ASN.1 but the ABNF definition of the indAudmediaDescriptor > >allow for only one value of indAudmediaParm. > > > >Therefor my _question_ if the definition should'nt really be: > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > *(COMMA indAudmediaParm) RBRKT > > > >Also, the defintion of the mediaDescriptor strikes me as _very_ similar to > >my "proposal": > > > > mediaDescriptor = MediaToken LBRKT mediaParm > > *(COMMA mediaParm) RBRKT > > > > ; at-most one terminationStateDescriptor > > ; and either streamParm(s) or streamDescriptor(s) but not both > > mediaParm = (streamParm / streamDescriptor / > > terminationStateDescriptor) > > > >Regards, > > /BMK > > > > > > > > Regards, Christian > > > > > > Micael Karlberg wrote: > > > > > > > > Hi, > > > > > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch > > > >between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > > My > >question is: Should the definition of ABNF indAudmediaDescriptor > > really > >be: > > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > > > *(COMMA indAudmediaParm) RBRKT > > > > > > > > The comment for indAudmediaParm and the ASN.1 IndAudMediaDescriptor > > > > indicates that it should be a list. Or am I missing something? > > > > > > Also, see definition of mediaDescriptor! > > > > > > > > ABNF: > > > > ---- > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > > > > > > > > ; at-most-once per item > > > > ; and either streamParm or streamDescriptor but not both > > > > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > > > > indAudterminationStateDescriptor) > > > > > > > > ASN.1: > > > > ----- > > > > IndAudMediaDescriptor ::= SEQUENCE > > > > { > > > > > > > > termStateDescr IndAudTerminationStateDescriptor OPTIONAL, > > > > streams CHOICE > > > > { > > > > oneStream IndAudStreamParms, > > > > multiStream SEQUENCE OF IndAudStreamDescriptor > > > > } OPTIONAL, > > > > ... > > > > } > > > > > > > > Regards, > > > > /BMK > > > > > > > > _______________________________________________ > > > > Megaco mailing list > > > > Megaco@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/megaco > > > >-- > >Micael Karlberg Ericsson AB, Älvsjö Sweden > >Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development > >ECN: 851 5668 Mail: micael.karlberg@ericsson.com > >Fax: +46 8 727 5775 > > > >_______________________________________________ > >Megaco mailing list > >Megaco@ietf.org > >https://www1.ietf.org/mailman/listinfo/megaco > > > >_______________________________________________ > >Megaco mailing list > >Megaco@ietf.org > >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jun 18 00:34:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22856 for ; Wed, 18 Jun 2003 00:34:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SUe1-000538-MM; Wed, 18 Jun 2003 00:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SUdv-00052v-9s for megaco@optimus.ietf.org; Wed, 18 Jun 2003 00:33:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22832 for ; Wed, 18 Jun 2003 00:33:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SUbf-0007Yi-00 for megaco@ietf.org; Wed, 18 Jun 2003 00:31:35 -0400 Received: from [218.154.52.161] (helo=dinnovan.com) by ietf-mx with esmtp (Exim 4.12) id 19SUbe-0007Ye-00 for megaco@ietf.org; Wed, 18 Jun 2003 00:31:35 -0400 Received: from Spooler by dinnovan.com (Mercury/32 v3.21c) ID MO000C0C; 18 Jun 03 13:45:49 +0900 Received: from spooler by dinnovan.com (Mercury/32 v3.21c); 18 Jun 03 13:45:07 +0900 Received: from lysen (10.1.1.123) by dinnovan.com (Mercury/32 v3.21c) ID MG000C0B; 18 Jun 03 13:45:01 +0900 Message-ID: <002d01c33553$3e8a8910$7b01010a@lysen> From: =?x-user-defined?B?wNO/tbvz?= To: Subject: [MEGACO] How can I get megaco soft phone.... Date: Wed, 18 Jun 2003 13:36:54 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01C3359E.AE53AC90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Sender: megaco-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_002A_01C3359E.AE53AC90 Content-Type: text/plain; charset="x-user-defined" Content-Transfer-Encoding: base64 DQpIZWxsbyBBbGwhIQ0KDQpJIGZvdW5kIEFWQVogbWVnYWNvIHBob25lLi4uDQpCdXQgSXQncyBu b3Qgd29ya2luZyBpbiBvcmRlcmx5Lg0KSG93IGNhbiBJIGdldCBhbm90aGVyIG1lZ2FjbyBzb2Z0 IHBob25lLi4uLg0KDQpyZWdhcmQuLg0KDQpseXNlbkBrb3JlYS5jb20NCg0KDQoNCg0KDQo= ------=_NextPart_000_002A_01C3359E.AE53AC90 Content-Type: text/html; charset="x-user-defined" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXgtdXNlci1kZWZpbmVkIj4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ3MzEuMjIwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYj NDc1NDg7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5IZWxs byBBbGwhITwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgZm91bmQgQVZBWiBtZWdhY28gcGhvbmUuLi48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5CdXQgSXQncyBub3Qgd29ya2luZyBpbiBvcmRlcmx5 LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhvdyBjYW4gSSBnZXQgYW5vdGhlciBt ZWdhY28gc29mdCBwaG9uZS4uLi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5yZWdhcmQuLjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+PEEgDQpocmVmPSJt YWlsdG86bHlzZW5Aa29yZWEuY29tIj5seXNlbkBrb3JlYS5jb208L0E+PC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IHNp emU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_002A_01C3359E.AE53AC90-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Jun 18 00:34:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22871 for ; Wed, 18 Jun 2003 00:34:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5I4Y4g19494 for megaco-archive@odin.ietf.org; Wed, 18 Jun 2003 00:34:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SUe4-00054L-5C for megaco-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 00:34:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22838 for ; Wed, 18 Jun 2003 00:34:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SUbo-0007Yo-00 for megaco-web-archive@ietf.org; Wed, 18 Jun 2003 00:31:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SUbo-0007Yl-00 for megaco-web-archive@ietf.org; Wed, 18 Jun 2003 00:31:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SUe1-000538-MM; Wed, 18 Jun 2003 00:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SUdv-00052v-9s for megaco@optimus.ietf.org; Wed, 18 Jun 2003 00:33:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22832 for ; Wed, 18 Jun 2003 00:33:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SUbf-0007Yi-00 for megaco@ietf.org; Wed, 18 Jun 2003 00:31:35 -0400 Received: from [218.154.52.161] (helo=dinnovan.com) by ietf-mx with esmtp (Exim 4.12) id 19SUbe-0007Ye-00 for megaco@ietf.org; Wed, 18 Jun 2003 00:31:35 -0400 Received: from Spooler by dinnovan.com (Mercury/32 v3.21c) ID MO000C0C; 18 Jun 03 13:45:49 +0900 Received: from spooler by dinnovan.com (Mercury/32 v3.21c); 18 Jun 03 13:45:07 +0900 Received: from lysen (10.1.1.123) by dinnovan.com (Mercury/32 v3.21c) ID MG000C0B; 18 Jun 03 13:45:01 +0900 Message-ID: <002d01c33553$3e8a8910$7b01010a@lysen> From: =?x-user-defined?B?wNO/tbvz?= To: Subject: [MEGACO] How can I get megaco soft phone.... Date: Wed, 18 Jun 2003 13:36:54 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01C3359E.AE53AC90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Sender: megaco-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_002A_01C3359E.AE53AC90 Content-Type: text/plain; charset="x-user-defined" Content-Transfer-Encoding: base64 DQpIZWxsbyBBbGwhIQ0KDQpJIGZvdW5kIEFWQVogbWVnYWNvIHBob25lLi4uDQpCdXQgSXQncyBu b3Qgd29ya2luZyBpbiBvcmRlcmx5Lg0KSG93IGNhbiBJIGdldCBhbm90aGVyIG1lZ2FjbyBzb2Z0 IHBob25lLi4uLg0KDQpyZWdhcmQuLg0KDQpseXNlbkBrb3JlYS5jb20NCg0KDQoNCg0KDQo= ------=_NextPart_000_002A_01C3359E.AE53AC90 Content-Type: text/html; charset="x-user-defined" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXgtdXNlci1kZWZpbmVkIj4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ3MzEuMjIwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYj NDc1NDg7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5IZWxs byBBbGwhITwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgZm91bmQgQVZBWiBtZWdhY28gcGhvbmUuLi48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5CdXQgSXQncyBub3Qgd29ya2luZyBpbiBvcmRlcmx5 LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhvdyBjYW4gSSBnZXQgYW5vdGhlciBt ZWdhY28gc29mdCBwaG9uZS4uLi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5yZWdhcmQuLjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+PEEgDQpocmVmPSJt YWlsdG86bHlzZW5Aa29yZWEuY29tIj5seXNlbkBrb3JlYS5jb208L0E+PC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IHNp emU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_002A_01C3359E.AE53AC90-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jun 18 01:02:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22004 for ; Wed, 18 Jun 2003 00:09:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SUFp-0004Ro-RG; Wed, 18 Jun 2003 00:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SUEw-0004Qx-3I for megaco@optimus.ietf.org; Wed, 18 Jun 2003 00:08:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21917 for ; Wed, 18 Jun 2003 00:08:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SUCg-0007Jz-00 for megaco@ietf.org; Wed, 18 Jun 2003 00:05:46 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19SUCe-0007Jd-00 for megaco@ietf.org; Wed, 18 Jun 2003 00:05:45 -0400 Received: from brsf10.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h5I3qpk11003; Wed, 18 Jun 2003 13:52:51 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h5I3tHP17982; Wed, 18 Jun 2003 13:55:17 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.236.90]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LZBXTYW1; Wed, 18 Jun 2003 13:55:16 +1000 Message-ID: <3EEFE29F.FA336106@ericsson.com.au> Date: Wed, 18 Jun 2003 13:55:11 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Boyle CC: micael.karlberg@ericsson.com, megaco@ietf.org Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? References: Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ish7.ericsson.com.au id h5I3qpk11003 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA22004 G'Day Kevin and Micael, I still don't see a problem. indAudterminationAudit allows you to request multiple values: indAudterminationAudit = indAudauditReturnParameter *(COMMA indAudauditReturnParameter) indAudauditReturnParameter = (indAudmediaDescriptor / / indAudeventsDescriptor / indAudsignalsDescriptor / indAuddigitMapDescriptor / indAudeventBufferDescriptor / indAudstatisticsDescriptor / indAudpackagesDescriptor) indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT This allows you to request several streams. So the capabilities are aligned. The reason we have the indAudstreamParm / indAudstreamDescriptor is to allow for the case where no streamid is given. Regards, Christian Kevin Boyle wrote: > > Aha... I see the problem now. In binary, you can request info about several > streams at once, but you may only request info about one stream in text. Is > this an accurate summary? > > Seeing as this would be a syntax change, we need to know if anyone would have > major heartburn over changing the syntax to fix this. If not, I will draft up > an IG item to fix this... > > Speaking personally, I think this is a beneficial change, because it makes the > syntax align between the expression of items within the media descriptor, and > the audit of items within the media descriptor, as well as making both binary > and text align in capability. > > Any other comments? > > Kevin > > -----Original Message----- > From: Micael Karlberg [mailto:micael.karlberg@ericsson.com] > Sent: Tuesday, June 17, 2003 1:26 PM > To: Christian Groves > Cc: megaco@ietf.org > Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? > > Hello Christian, > > Christian Groves writes: > > Hello Micael, > > > > I don't understand what the problem is nor the comments in the ASN.1 you > are > referring to? > > The comment ("at-most-once per item...") is in the ABNF. > > > If you are referring to the ::= SEQUENCE this is actually an ASN.1 > > construct that says that a sequence of information elements may be encoded, > in > this case "termStateDescr" & a choice of streams. > > This is how see it also. > > > This same information is represented by the ABNF. > > This I _cannot_ find! > > The comment in the ABNF seems to indicate that it should be as in > the ASN.1 but the ABNF definition of the indAudmediaDescriptor > allow for only one value of indAudmediaParm. > > Therefor my _question_ if the definition should'nt really be: > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > *(COMMA indAudmediaParm) RBRKT > > Also, the defintion of the mediaDescriptor strikes me as _very_ similar to my > "proposal": > > mediaDescriptor = MediaToken LBRKT mediaParm > *(COMMA mediaParm) RBRKT > > ; at-most one terminationStateDescriptor > ; and either streamParm(s) or streamDescriptor(s) but not both > mediaParm = (streamParm / streamDescriptor / > terminationStateDescriptor) > > Regards, > /BMK > > > > > Regards, Christian > > > > Micael Karlberg wrote: > > > > > > Hi, > > > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch > > > between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > > My > question is: Should the definition of ABNF indAudmediaDescriptor > > really > be: > > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > > *(COMMA indAudmediaParm) RBRKT > > > > > > The comment for indAudmediaParm and the ASN.1 IndAudMediaDescriptor > > > indicates that it should be a list. Or am I missing something? > > > > > > Also, see definition of mediaDescriptor! > > > > > > ABNF: > > > ---- > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > > > > > > ; at-most-once per item > > > ; and either streamParm or streamDescriptor but not both > > > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > > > indAudterminationStateDescriptor) > > > > > > ASN.1: > > > ----- > > > IndAudMediaDescriptor ::= SEQUENCE > > > { > > > > > > termStateDescr IndAudTerminationStateDescriptor OPTIONAL, > > > streams CHOICE > > > { > > > oneStream IndAudStreamParms, > > > multiStream SEQUENCE OF IndAudStreamDescriptor > > > } OPTIONAL, > > > ... > > > } > > > > > > Regards, > > > /BMK > > > > > > _______________________________________________ > > > Megaco mailing list > > > Megaco@ietf.org > > > https://www1.ietf.org/mailman/listinfo/megaco > > -- > Micael Karlberg Ericsson AB, Älvsjö Sweden > Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development > ECN: 851 5668 Mail: micael.karlberg@ericsson.com > Fax: +46 8 727 5775 > > _______________________________________________ > 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 Jun 18 09:57:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07227 for ; Wed, 18 Jun 2003 09:57:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sd9S-0001GG-It; Wed, 18 Jun 2003 09:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Scrn-0000Ik-Kf for megaco@optimus.ietf.org; Wed, 18 Jun 2003 09:20:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05474 for ; Wed, 18 Jun 2003 09:20:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ScpX-0004Ox-00 for megaco@ietf.org; Wed, 18 Jun 2003 09:18:27 -0400 Received: from [203.124.156.99] (helo=chandgate2.mahindrabt.com) by ietf-mx with esmtp (Exim 4.12) id 19ScpV-0004Ou-00 for megaco@ietf.org; Wed, 18 Jun 2003 09:18:25 -0400 Received: from thisdomain (mailscan.chand.mahindrabt.com [10.3.0.15]) by chandgate2.mahindrabt.com (8.12.9/8.12.9) with ESMTP id h5ID38Iu003334 for ; Wed, 18 Jun 2003 18:33:14 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Wed, 18 Jun 2003 18:54:13 +0530 Date: Wed, 18 Jun 2003 18:54:13 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: sunilv@mahindrabt.com Received: from dscp00980 ([10.5.11.125]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id SAA01294 for ; Wed, 18 Jun 2003 18:49:00 +0530 Message-ID: <009701c3359c$1f9785a0$7d0b050a@mahindrabt.com> From: "sunil vatnal" To: References: <20030617160002.7738.18125.Mailman@www1.ietf.org> Date: Wed, 18 Jun 2003 18:48:07 +0530 Organization: mbt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Megaco] Help Sender: megaco-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, 1. When vendors claim ALF support for MEGACO, do they consider 1 MEGACO transaction as 1 ADU ? 2. Do these vendor send multiple transactions in one MEGACO Message ? Atul Mahindra British Telecom Ltd ----- Original Message ----- From: To: Sent: Wednesday, June 18, 2003 12:27 AM Subject: Megaco digest, Vol 1 #917 - 3 msgs > Send Megaco mailing list submissions to > megaco@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/megaco > or, via email, send a message with subject or body 'help' to > megaco-request@ietf.org > > You can reach the person managing the list at > megaco-admin@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Megaco digest..." > > > Today's Topics: > > 1. Re: v2 mismatch ABNF & ASN.1 IndAudmediaParm? (Christian Groves) > 2. what is ALF ( Application Level Framing ) (sunil vatnal) > 3. Query regarding ALF in MEGACO (Shailendra) > > --__--__-- > > Message: 1 > Date: Tue, 17 Jun 2003 10:58:51 +1000 > From: Christian Groves > To: micael.karlberg@ericsson.com > CC: megaco@ietf.org > Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? > > Hello Micael, > > I don't understand what the problem is nor the comments in the ASN.1 you are > referring to? If you are referring to the ::= SEQUENCE this is actually an ASN.1 > construct that says that a sequence of information elements may be encoded, in > this case "termStateDescr" & a choice of streams. This same information is > represented by the ABNF. > > Regards, Christian > > Micael Karlberg wrote: > > > > Hi, > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch > > between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > > My question is: Should the definition of ABNF indAudmediaDescriptor > > really be: > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > *(COMMA indAudmediaParm) RBRKT > > > > The comment for indAudmediaParm and the ASN.1 IndAudMediaDescriptor > > indicates that it should be a list. Or am I missing something? > > > > Also, see definition of mediaDescriptor! > > > > ABNF: > > ---- > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > > > > ; at-most-once per item > > ; and either streamParm or streamDescriptor but not both > > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > > indAudterminationStateDescriptor) > > > > ASN.1: > > ----- > > IndAudMediaDescriptor ::= SEQUENCE > > { > > > > termStateDescr IndAudTerminationStateDescriptor OPTIONAL, > > streams CHOICE > > { > > oneStream IndAudStreamParms, > > multiStream SEQUENCE OF IndAudStreamDescriptor > > } OPTIONAL, > > ... > > } > > > > Regards, > > /BMK > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > --__--__-- > > Message: 2 > Date: Tue, 17 Jun 2003 13:06:40 +0530 > From: "sunil vatnal" > To: > Cc: "krishnappa" > Date: Tue, 17 Jun 2003 13:02:17 +0530 > Organization: mbt > Subject: [Megaco] what is ALF ( Application Level Framing ) > > This is a multi-part message in MIME format. > > ------=_NextPart_000_004D_01C334D0.AE512020 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Hi, > > The megaco RFC 3015 suggests to implement ALF ( Application Level = > Framing ) for the UDP transport. The meaning of the ALF is like this in = > the RFC. > > " ALF is a set of techniques that allows an application, as opposed to a = > stack, to affect how messages are sent to the other side. A typical ALF = > technique is to allow an application to change the order of messages = > sent when there is a queue after it has queued them. There is no formal = > specification for ALF.=20 > Implementors using IP/UDP with ALF SHOULD be aware of the = > restrictions of the MTU on the maximum message size. " > > Most of the Megaco Protocol Stack developers say that they have achieved = > the ALF by implementing reliable transactions by having retransmissions, = > provisional transmissions, rejection of duplicate transactions...etc. > > My Question is .... =3D=3D=3D> Can we achieve ALF by ..=20 > > 1) implementing reliable transactions with retransmission techniques = > with long timer > mechanism ( This is already implemented ) > > -- OR --=20 > > 2) Fragment and reassemble the message or the media data depending = > upon the MTU size. > =20 > -- OR -- > 3) Divide the message or the media data into ADUs ( Application Data = > Units ) and keep track=20 > of the order of these. > > Please clarify.. > > Thanks and Regards, > Sunil M Vatnal > Mahindra British Telecom. > > ********************************************************* > Disclaimer > > This message (including any attachments) contains=20 > confidential information intended for a specific=20 > individual and purpose, and is protected by law.=20 > If you are not the intended recipient, you should=20 > delete this message and are hereby notified that=20 > any disclosure, copying, or distribution of this > message, or the taking of any action based on it,=20 > is strictly prohibited. > > ********************************************************* > Visit us at http://www.mahindrabt.com > > > ------=_NextPart_000_004D_01C334D0.AE512020 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > > charset=3Diso-8859-1"> > > > > >
>
Hi,
>
 
>
The megaco RFC 3015 suggests to = > implement ALF (=20 > Application Level Framing ) for the UDP transport. The meaning of the = > ALF is=20 > like this in the RFC.
>
 
>
" ALF is a set of = > techniques that=20 > allows an application, as opposed to a stack, to affect how messages are = > sent to=20 > the other side. A typical ALF technique is to allow an application to = > change the=20 > order of messages sent when there is a queue after it has queued = > them. =20 > There is no formal specification for ALF.
   Implementors = > using=20 > IP/UDP with ALF SHOULD be aware of the restrictions of the MTU on the = > maximum=20 > message size. "
>
 
>
Most of the Megaco Protocol Stack = > developers say=20 > that they have achieved the ALF by implementing reliable = > transactions by=20 > having retransmissions, provisional transmissions, rejection of = > duplicate=20 > transactions...etc.
>
 
>
My Question is .... =3D=3D=3D> Can = > we achieve ALF by=20 > ..
>
 
>
   1) implementing reliable = > transactions=20 > with retransmission techniques with long timer
>
       = > mechanism ( This is=20 > already implemented )
>
 
>
size=3D2>          &nbs= > p;            = > ;            = >          --=20 > OR --
>
 
>
   2) Fragment and reassemble = > the message=20 > or the media data depending upon the MTU size.
>
  
>
       =20 >             = >    =20 >             = >    =20 >     -- OR --
>
   3) Divide the message = > or the=20 > media data into ADUs ( Application Data Units ) and keep track = >
>
       of = > the order=20 > of these.
>
 
>
   Please = > clarify..
>
 
>
  Thanks and Regards,
>
  Sunil M Vatnal
>
  Mahindra British=20 > Telecom.
> > >
> *********************************************************
> Disclaimer
>
> This message (including any attachments) contains
> confidential information intended for a specific
> individual and purpose, and is protected by law.
> If you are not the intended recipient, you should
> delete this message and are hereby notified that
> any disclosure, copying, or distribution of this
> message, or the taking of any action based on it,
> is strictly prohibited.
>
> *********************************************************
> Visit us at http://www.mahindrabt.com
>
> > > ------=_NextPart_000_004D_01C334D0.AE512020-- > > > > --__--__-- > > Message: 3 > Date: Tue, 17 Jun 2003 17:27:25 +0530 > Reply-To: "Shailendra" > From: "Shailendra" > To: > Date: Tue, 17 Jun 2003 17:26:08 +0530 > Organization: Mahibdra - British Telecom > Subject: [Megaco] Query regarding ALF in MEGACO > > Hi, > > The megaco RFC 3015 suggests to implement ALF ( Application Level Framing ) > for the UDP transport. The meaning of the ALF is like this in the RFC. > > " ALF is a set of techniques that allows an application, as opposed to a > stack, to affect how messages are sent to the other side. A typical ALF > technique is to allow an application to change the order of messages sent > when there is a queue after it has queued them. There is no formal > specification for ALF. > Implementors using IP/UDP with ALF SHOULD be aware of the restrictions of > the MTU on the maximum message size. " > > Most of the Megaco Protocol Stack developers say that they have achieved the > ALF by implementing reliable transactions by having retransmissions, > provisional transmissions, rejection of duplicate transactions...etc. > > My Questions is .... Can we achieve ALF by .. > > 1) implementing reliable transactions with retransmission techniques with > long timer > mechanism ( This is already implemented ) > > -- OR -- > > 2) Fragment and reassemble the message or the media data depending upon > the MTU size. > > -- OR -- > 3) Divide the message or the media data into ADUs ( Application Data > Units ) and keep track > of the order of these. > > Please clarify.. > > Thanks and Regards, > Shailendra > > ********************************************************* > Disclaimer > > This message (including any attachments) contains > confidential information intended for a specific > individual and purpose, and is protected by law. > If you are not the intended recipient, you should > delete this message and are hereby notified that > any disclosure, copying, or distribution of this > message, or the taking of any action based on it, > is strictly prohibited. > > ********************************************************* > Visit us at http://www.mahindrabt.com > > > > > > --__--__-- > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > > End of Megaco Digest > ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jun 18 10:01:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07509 for ; Wed, 18 Jun 2003 10:01:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sd9T-0001Gi-HM; Wed, 18 Jun 2003 09:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Scth-0000S2-Eq for megaco@optimus.ietf.org; Wed, 18 Jun 2003 09:22:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05657 for ; Wed, 18 Jun 2003 09:22:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ScrQ-0004Sy-00 for megaco@ietf.org; Wed, 18 Jun 2003 09:20:24 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19ScrQ-0004SF-00 for megaco@ietf.org; Wed, 18 Jun 2003 09:20:24 -0400 Received: from smilevm.winphoria.com ([10.14.25.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 18 Jun 2003 09:22:12 -0400 Message-Id: <5.2.1.1.0.20030618091318.02d8bb08@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 18 Jun 2003 09:20:05 -0400 To: Christian Groves , megaco@ietf.org From: Aleksandr Ryabin Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Cc: Kevin Boyle , micael.karlberg@ericsson.com In-Reply-To: <3EEFE391.DEF3314@ericsson.com.au> References: <5.2.1.1.0.20030617201948.02d0c8a0@imap.winphoria.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 18 Jun 2003 13:22:12.0829 (UTC) FILETIME=[A0F818D0:01C3359C] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA07509 Hi Christian, Could you please clarify on how would MGC audit individual local, or remote SDP with v1? I mean, local and remote SDPs are part of larger MediaDescriptor and the ABNF construction of auditItem only allows auditing the whole MediaDescriptor, not parts of it: ;at-most-once, and DigitMapToken and PackagesToken are not allowed ;in AuditCapabilities command auditItem = ( MuxToken / ModemToken / MediaToken / SignalsToken / EventBufferToken / DigitMapToken / StatsToken / EventsToken / ObservedEventsToken / PackagesToken ) So, if I understand it correctly, MGC can only audit the whole MediaDescriptor, not individual local, or remote SDP. Regards, Aleks At 11:59 PM 6/17/2003, Christian Groves wrote: >Hello Aleksandr, > >Megaco does allow you to audit a whole local or remote descriptor. This is the >audit capability v1. Individual auditing was added in v2. We didn't add >individual audit of a whole descriptor as this would duplicate functionality. > >It was decided not to allow auditing of individual segments of local and >remote >SDP (text encoding) because no body could come up with an appropriate >method to >do this and didn't know what the reply looked like. For the binary encoding it >was very easy because all parameters follow a tag length value structure. You >request the tag and you get back the value. > >Christian > >Aleksandr Ryabin wrote: > > > > Hi, > > > > While we are on topic. The following does not allow auditing for the whole > > local or remote SDP in ABNF: > > ; at-most-once > > indAudstreamParm = ( indAudlocalControlDescriptor ) > > ; SDP too complex to pull out individual pieces for audit, > > ; hence no individual audit for Local and Remote > > > > The question is why? I mean why does not it allow to audit *whole* > > local or remote SDP? E.g.: > > indAudstreamParm = ( indAudlocalControlDescriptor / LocalToken / > > RemoteToken) > > > > BTW ASN.1 does allow that, as well as individual pieces of SDPs. > > > > Thanks > > Aleks > > > > PS. Small nit in indAudauditReturnParameter (two slashes at the end): > > indAudauditReturnParameter = (indAudmediaDescriptor / / > > > > At 03:30 PM 6/17/2003, Kevin Boyle wrote: > > >Aha... I see the problem now. In binary, you can request info about > several > > >streams at once, but you may only request info about one stream in > text. Is > > >this an accurate summary? > > > > > >Seeing as this would be a syntax change, we need to know if anyone would > > >have major heartburn over changing the syntax to fix this. If not, I will > > >draft up an IG item to fix this... > > > > > >Speaking personally, I think this is a beneficial change, because it makes > > >the syntax align between the expression of items within the media > > >descriptor, and the audit of items within the media descriptor, as well as > > >making both binary and text align in capability. > > > > > >Any other comments? > > > > > >Kevin > > > > > >-----Original Message----- > > >From: Micael Karlberg [mailto:micael.karlberg@ericsson.com] > > >Sent: Tuesday, June 17, 2003 1:26 PM > > >To: Christian Groves > > >Cc: megaco@ietf.org > > >Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? > > > > > > > > >Hello Christian, > > > > > >Christian Groves writes: > > > > Hello Micael, > > > > > > > > I don't understand what the problem is nor the comments in the > ASN.1 you > > >are > referring to? > > > > > >The comment ("at-most-once per item...") is in the ABNF. > > > > > > > If you are referring to the ::= SEQUENCE this is actually an ASN.1 > > > >construct that says that a sequence of information elements may be > encoded, > > >in > this case "termStateDescr" & a choice of streams. > > > > > >This is how see it also. > > > > > > > This same information is represented by the ABNF. > > > > > >This I _cannot_ find! > > > > > >The comment in the ABNF seems to indicate that it should be as in > > >the ASN.1 but the ABNF definition of the indAudmediaDescriptor > > >allow for only one value of indAudmediaParm. > > > > > >Therefor my _question_ if the definition should'nt really be: > > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > > *(COMMA indAudmediaParm) RBRKT > > > > > >Also, the defintion of the mediaDescriptor strikes me as _very_ similar to > > >my "proposal": > > > > > > mediaDescriptor = MediaToken LBRKT mediaParm > > > *(COMMA mediaParm) RBRKT > > > > > > ; at-most one terminationStateDescriptor > > > ; and either streamParm(s) or streamDescriptor(s) but not both > > > mediaParm = (streamParm / streamDescriptor / > > > terminationStateDescriptor) > > > > > >Regards, > > > /BMK > > > > > > > > > > > Regards, Christian > > > > > > > > Micael Karlberg wrote: > > > > > > > > > > Hi, > > > > > > > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a > mismatch > > > > >between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > > My > > >question is: Should the definition of ABNF indAudmediaDescriptor > > > really > > >be: > > > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > > > > *(COMMA indAudmediaParm) RBRKT > > > > > > > > > > The comment for indAudmediaParm and the ASN.1 > IndAudMediaDescriptor > > > > > indicates that it should be a list. Or am I missing something? > > > > > > > Also, see definition of mediaDescriptor! > > > > > > > > > > ABNF: > > > > > ---- > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > RBRKT > > > > > > > > > > ; at-most-once per item > > > > > ; and either streamParm or streamDescriptor but not both > > > > > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > > > > > indAudterminationStateDescriptor) > > > > > > > > > > ASN.1: > > > > > ----- > > > > > IndAudMediaDescriptor ::= SEQUENCE > > > > > { > > > > > > > > > > termStateDescr IndAudTerminationStateDescriptor > OPTIONAL, > > > > > streams CHOICE > > > > > { > > > > > oneStream IndAudStreamParms, > > > > > multiStream SEQUENCE OF IndAudStreamDescriptor > > > > > } OPTIONAL, > > > > > ... > > > > > } > > > > > > > > > > Regards, > > > > > /BMK > > > > > > > > > > _______________________________________________ > > > > > Megaco mailing list > > > > > Megaco@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > >-- > > >Micael Karlberg Ericsson AB, Älvsjö Sweden > > >Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development > > >ECN: 851 5668 Mail: micael.karlberg@ericsson.com > > >Fax: +46 8 727 5775 > > > > > >_______________________________________________ > > >Megaco mailing list > > >Megaco@ietf.org > > >https://www1.ietf.org/mailman/listinfo/megaco > > > > > >_______________________________________________ > > >Megaco mailing list > > >Megaco@ietf.org > > >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Jun 18 10:10:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08739 for ; Wed, 18 Jun 2003 10:10:56 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IEASv11718 for megaco-archive@odin.ietf.org; Wed, 18 Jun 2003 10:10:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdR1-00020F-Ca for megaco-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 09:57:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07222 for ; Wed, 18 Jun 2003 09:57:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SdOk-0004sf-00 for megaco-web-archive@ietf.org; Wed, 18 Jun 2003 09:54:50 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SdOj-0004sc-00 for megaco-web-archive@ietf.org; Wed, 18 Jun 2003 09:54:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sd9S-0001GG-It; Wed, 18 Jun 2003 09:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Scrn-0000Ik-Kf for megaco@optimus.ietf.org; Wed, 18 Jun 2003 09:20:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05474 for ; Wed, 18 Jun 2003 09:20:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ScpX-0004Ox-00 for megaco@ietf.org; Wed, 18 Jun 2003 09:18:27 -0400 Received: from [203.124.156.99] (helo=chandgate2.mahindrabt.com) by ietf-mx with esmtp (Exim 4.12) id 19ScpV-0004Ou-00 for megaco@ietf.org; Wed, 18 Jun 2003 09:18:25 -0400 Received: from thisdomain (mailscan.chand.mahindrabt.com [10.3.0.15]) by chandgate2.mahindrabt.com (8.12.9/8.12.9) with ESMTP id h5ID38Iu003334 for ; Wed, 18 Jun 2003 18:33:14 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Wed, 18 Jun 2003 18:54:13 +0530 Date: Wed, 18 Jun 2003 18:54:13 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: sunilv@mahindrabt.com Received: from dscp00980 ([10.5.11.125]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id SAA01294 for ; Wed, 18 Jun 2003 18:49:00 +0530 Message-ID: <009701c3359c$1f9785a0$7d0b050a@mahindrabt.com> From: "sunil vatnal" To: References: <20030617160002.7738.18125.Mailman@www1.ietf.org> Date: Wed, 18 Jun 2003 18:48:07 +0530 Organization: mbt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Megaco] Help Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, 1. When vendors claim ALF support for MEGACO, do they consider 1 MEGACO transaction as 1 ADU ? 2. Do these vendor send multiple transactions in one MEGACO Message ? Atul Mahindra British Telecom Ltd ----- Original Message ----- From: To: Sent: Wednesday, June 18, 2003 12:27 AM Subject: Megaco digest, Vol 1 #917 - 3 msgs > Send Megaco mailing list submissions to > megaco@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/megaco > or, via email, send a message with subject or body 'help' to > megaco-request@ietf.org > > You can reach the person managing the list at > megaco-admin@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Megaco digest..." > > > Today's Topics: > > 1. Re: v2 mismatch ABNF & ASN.1 IndAudmediaParm? (Christian Groves) > 2. what is ALF ( Application Level Framing ) (sunil vatnal) > 3. Query regarding ALF in MEGACO (Shailendra) > > --__--__-- > > Message: 1 > Date: Tue, 17 Jun 2003 10:58:51 +1000 > From: Christian Groves > To: micael.karlberg@ericsson.com > CC: megaco@ietf.org > Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? > > Hello Micael, > > I don't understand what the problem is nor the comments in the ASN.1 you are > referring to? If you are referring to the ::= SEQUENCE this is actually an ASN.1 > construct that says that a sequence of information elements may be encoded, in > this case "termStateDescr" & a choice of streams. This same information is > represented by the ABNF. > > Regards, Christian > > Micael Karlberg wrote: > > > > Hi, > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch > > between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > > My question is: Should the definition of ABNF indAudmediaDescriptor > > really be: > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > *(COMMA indAudmediaParm) RBRKT > > > > The comment for indAudmediaParm and the ASN.1 IndAudMediaDescriptor > > indicates that it should be a list. Or am I missing something? > > > > Also, see definition of mediaDescriptor! > > > > ABNF: > > ---- > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > > > > ; at-most-once per item > > ; and either streamParm or streamDescriptor but not both > > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > > indAudterminationStateDescriptor) > > > > ASN.1: > > ----- > > IndAudMediaDescriptor ::= SEQUENCE > > { > > > > termStateDescr IndAudTerminationStateDescriptor OPTIONAL, > > streams CHOICE > > { > > oneStream IndAudStreamParms, > > multiStream SEQUENCE OF IndAudStreamDescriptor > > } OPTIONAL, > > ... > > } > > > > Regards, > > /BMK > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > --__--__-- > > Message: 2 > Date: Tue, 17 Jun 2003 13:06:40 +0530 > From: "sunil vatnal" > To: > Cc: "krishnappa" > Date: Tue, 17 Jun 2003 13:02:17 +0530 > Organization: mbt > Subject: [Megaco] what is ALF ( Application Level Framing ) > > This is a multi-part message in MIME format. > > ------=_NextPart_000_004D_01C334D0.AE512020 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Hi, > > The megaco RFC 3015 suggests to implement ALF ( Application Level = > Framing ) for the UDP transport. The meaning of the ALF is like this in = > the RFC. > > " ALF is a set of techniques that allows an application, as opposed to a = > stack, to affect how messages are sent to the other side. A typical ALF = > technique is to allow an application to change the order of messages = > sent when there is a queue after it has queued them. There is no formal = > specification for ALF.=20 > Implementors using IP/UDP with ALF SHOULD be aware of the = > restrictions of the MTU on the maximum message size. " > > Most of the Megaco Protocol Stack developers say that they have achieved = > the ALF by implementing reliable transactions by having retransmissions, = > provisional transmissions, rejection of duplicate transactions...etc. > > My Question is .... =3D=3D=3D> Can we achieve ALF by ..=20 > > 1) implementing reliable transactions with retransmission techniques = > with long timer > mechanism ( This is already implemented ) > > -- OR --=20 > > 2) Fragment and reassemble the message or the media data depending = > upon the MTU size. > =20 > -- OR -- > 3) Divide the message or the media data into ADUs ( Application Data = > Units ) and keep track=20 > of the order of these. > > Please clarify.. > > Thanks and Regards, > Sunil M Vatnal > Mahindra British Telecom. > > ********************************************************* > Disclaimer > > This message (including any attachments) contains=20 > confidential information intended for a specific=20 > individual and purpose, and is protected by law.=20 > If you are not the intended recipient, you should=20 > delete this message and are hereby notified that=20 > any disclosure, copying, or distribution of this > message, or the taking of any action based on it,=20 > is strictly prohibited. > > ********************************************************* > Visit us at http://www.mahindrabt.com > > > ------=_NextPart_000_004D_01C334D0.AE512020 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > > charset=3Diso-8859-1"> > > > > >
>
Hi,
>
 
>
The megaco RFC 3015 suggests to = > implement ALF (=20 > Application Level Framing ) for the UDP transport. The meaning of the = > ALF is=20 > like this in the RFC.
>
 
>
" ALF is a set of = > techniques that=20 > allows an application, as opposed to a stack, to affect how messages are = > sent to=20 > the other side. A typical ALF technique is to allow an application to = > change the=20 > order of messages sent when there is a queue after it has queued = > them. =20 > There is no formal specification for ALF.
   Implementors = > using=20 > IP/UDP with ALF SHOULD be aware of the restrictions of the MTU on the = > maximum=20 > message size. "
>
 
>
Most of the Megaco Protocol Stack = > developers say=20 > that they have achieved the ALF by implementing reliable = > transactions by=20 > having retransmissions, provisional transmissions, rejection of = > duplicate=20 > transactions...etc.
>
 
>
My Question is .... =3D=3D=3D> Can = > we achieve ALF by=20 > ..
>
 
>
   1) implementing reliable = > transactions=20 > with retransmission techniques with long timer
>
       = > mechanism ( This is=20 > already implemented )
>
 
>
size=3D2>          &nbs= > p;            = > ;            = >          --=20 > OR --
>
 
>
   2) Fragment and reassemble = > the message=20 > or the media data depending upon the MTU size.
>
  
>
       =20 >             = >    =20 >             = >    =20 >     -- OR --
>
   3) Divide the message = > or the=20 > media data into ADUs ( Application Data Units ) and keep track = >
>
       of = > the order=20 > of these.
>
 
>
   Please = > clarify..
>
 
>
  Thanks and Regards,
>
  Sunil M Vatnal
>
  Mahindra British=20 > Telecom.
> > >
> *********************************************************
> Disclaimer
>
> This message (including any attachments) contains
> confidential information intended for a specific
> individual and purpose, and is protected by law.
> If you are not the intended recipient, you should
> delete this message and are hereby notified that
> any disclosure, copying, or distribution of this
> message, or the taking of any action based on it,
> is strictly prohibited.
>
> *********************************************************
> Visit us at http://www.mahindrabt.com
>
> > > ------=_NextPart_000_004D_01C334D0.AE512020-- > > > > --__--__-- > > Message: 3 > Date: Tue, 17 Jun 2003 17:27:25 +0530 > Reply-To: "Shailendra" > From: "Shailendra" > To: > Date: Tue, 17 Jun 2003 17:26:08 +0530 > Organization: Mahibdra - British Telecom > Subject: [Megaco] Query regarding ALF in MEGACO > > Hi, > > The megaco RFC 3015 suggests to implement ALF ( Application Level Framing ) > for the UDP transport. The meaning of the ALF is like this in the RFC. > > " ALF is a set of techniques that allows an application, as opposed to a > stack, to affect how messages are sent to the other side. A typical ALF > technique is to allow an application to change the order of messages sent > when there is a queue after it has queued them. There is no formal > specification for ALF. > Implementors using IP/UDP with ALF SHOULD be aware of the restrictions of > the MTU on the maximum message size. " > > Most of the Megaco Protocol Stack developers say that they have achieved the > ALF by implementing reliable transactions by having retransmissions, > provisional transmissions, rejection of duplicate transactions...etc. > > My Questions is .... Can we achieve ALF by .. > > 1) implementing reliable transactions with retransmission techniques with > long timer > mechanism ( This is already implemented ) > > -- OR -- > > 2) Fragment and reassemble the message or the media data depending upon > the MTU size. > > -- OR -- > 3) Divide the message or the media data into ADUs ( Application Data > Units ) and keep track > of the order of these. > > Please clarify.. > > Thanks and Regards, > Shailendra > > ********************************************************* > Disclaimer > > This message (including any attachments) contains > confidential information intended for a specific > individual and purpose, and is protected by law. > If you are not the intended recipient, you should > delete this message and are hereby notified that > any disclosure, copying, or distribution of this > message, or the taking of any action based on it, > is strictly prohibited. > > ********************************************************* > Visit us at http://www.mahindrabt.com > > > > > > --__--__-- > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > > End of Megaco Digest > ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Jun 18 10:10:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08769 for ; Wed, 18 Jun 2003 10:10:58 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IEAUZ11796 for megaco-archive@odin.ietf.org; Wed, 18 Jun 2003 10:10:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdUo-0002BE-33 for megaco-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 10:01:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07495 for ; Wed, 18 Jun 2003 10:01:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SdSX-0004uu-00 for megaco-web-archive@ietf.org; Wed, 18 Jun 2003 09:58:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SdSW-0004ur-00 for megaco-web-archive@ietf.org; Wed, 18 Jun 2003 09:58:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sd9T-0001Gi-HM; Wed, 18 Jun 2003 09:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Scth-0000S2-Eq for megaco@optimus.ietf.org; Wed, 18 Jun 2003 09:22:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05657 for ; Wed, 18 Jun 2003 09:22:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ScrQ-0004Sy-00 for megaco@ietf.org; Wed, 18 Jun 2003 09:20:24 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19ScrQ-0004SF-00 for megaco@ietf.org; Wed, 18 Jun 2003 09:20:24 -0400 Received: from smilevm.winphoria.com ([10.14.25.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 18 Jun 2003 09:22:12 -0400 Message-Id: <5.2.1.1.0.20030618091318.02d8bb08@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 18 Jun 2003 09:20:05 -0400 To: Christian Groves , megaco@ietf.org From: Aleksandr Ryabin Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Cc: Kevin Boyle , micael.karlberg@ericsson.com In-Reply-To: <3EEFE391.DEF3314@ericsson.com.au> References: <5.2.1.1.0.20030617201948.02d0c8a0@imap.winphoria.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 18 Jun 2003 13:22:12.0829 (UTC) FILETIME=[A0F818D0:01C3359C] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA08769 Hi Christian, Could you please clarify on how would MGC audit individual local, or remote SDP with v1? I mean, local and remote SDPs are part of larger MediaDescriptor and the ABNF construction of auditItem only allows auditing the whole MediaDescriptor, not parts of it: ;at-most-once, and DigitMapToken and PackagesToken are not allowed ;in AuditCapabilities command auditItem = ( MuxToken / ModemToken / MediaToken / SignalsToken / EventBufferToken / DigitMapToken / StatsToken / EventsToken / ObservedEventsToken / PackagesToken ) So, if I understand it correctly, MGC can only audit the whole MediaDescriptor, not individual local, or remote SDP. Regards, Aleks At 11:59 PM 6/17/2003, Christian Groves wrote: >Hello Aleksandr, > >Megaco does allow you to audit a whole local or remote descriptor. This is the >audit capability v1. Individual auditing was added in v2. We didn't add >individual audit of a whole descriptor as this would duplicate functionality. > >It was decided not to allow auditing of individual segments of local and >remote >SDP (text encoding) because no body could come up with an appropriate >method to >do this and didn't know what the reply looked like. For the binary encoding it >was very easy because all parameters follow a tag length value structure. You >request the tag and you get back the value. > >Christian > >Aleksandr Ryabin wrote: > > > > Hi, > > > > While we are on topic. The following does not allow auditing for the whole > > local or remote SDP in ABNF: > > ; at-most-once > > indAudstreamParm = ( indAudlocalControlDescriptor ) > > ; SDP too complex to pull out individual pieces for audit, > > ; hence no individual audit for Local and Remote > > > > The question is why? I mean why does not it allow to audit *whole* > > local or remote SDP? E.g.: > > indAudstreamParm = ( indAudlocalControlDescriptor / LocalToken / > > RemoteToken) > > > > BTW ASN.1 does allow that, as well as individual pieces of SDPs. > > > > Thanks > > Aleks > > > > PS. Small nit in indAudauditReturnParameter (two slashes at the end): > > indAudauditReturnParameter = (indAudmediaDescriptor / / > > > > At 03:30 PM 6/17/2003, Kevin Boyle wrote: > > >Aha... I see the problem now. In binary, you can request info about > several > > >streams at once, but you may only request info about one stream in > text. Is > > >this an accurate summary? > > > > > >Seeing as this would be a syntax change, we need to know if anyone would > > >have major heartburn over changing the syntax to fix this. If not, I will > > >draft up an IG item to fix this... > > > > > >Speaking personally, I think this is a beneficial change, because it makes > > >the syntax align between the expression of items within the media > > >descriptor, and the audit of items within the media descriptor, as well as > > >making both binary and text align in capability. > > > > > >Any other comments? > > > > > >Kevin > > > > > >-----Original Message----- > > >From: Micael Karlberg [mailto:micael.karlberg@ericsson.com] > > >Sent: Tuesday, June 17, 2003 1:26 PM > > >To: Christian Groves > > >Cc: megaco@ietf.org > > >Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? > > > > > > > > >Hello Christian, > > > > > >Christian Groves writes: > > > > Hello Micael, > > > > > > > > I don't understand what the problem is nor the comments in the > ASN.1 you > > >are > referring to? > > > > > >The comment ("at-most-once per item...") is in the ABNF. > > > > > > > If you are referring to the ::= SEQUENCE this is actually an ASN.1 > > > >construct that says that a sequence of information elements may be > encoded, > > >in > this case "termStateDescr" & a choice of streams. > > > > > >This is how see it also. > > > > > > > This same information is represented by the ABNF. > > > > > >This I _cannot_ find! > > > > > >The comment in the ABNF seems to indicate that it should be as in > > >the ASN.1 but the ABNF definition of the indAudmediaDescriptor > > >allow for only one value of indAudmediaParm. > > > > > >Therefor my _question_ if the definition should'nt really be: > > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > > *(COMMA indAudmediaParm) RBRKT > > > > > >Also, the defintion of the mediaDescriptor strikes me as _very_ similar to > > >my "proposal": > > > > > > mediaDescriptor = MediaToken LBRKT mediaParm > > > *(COMMA mediaParm) RBRKT > > > > > > ; at-most one terminationStateDescriptor > > > ; and either streamParm(s) or streamDescriptor(s) but not both > > > mediaParm = (streamParm / streamDescriptor / > > > terminationStateDescriptor) > > > > > >Regards, > > > /BMK > > > > > > > > > > > Regards, Christian > > > > > > > > Micael Karlberg wrote: > > > > > > > > > > Hi, > > > > > > > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a > mismatch > > > > >between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > > My > > >question is: Should the definition of ABNF indAudmediaDescriptor > > > really > > >be: > > > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > > > > *(COMMA indAudmediaParm) RBRKT > > > > > > > > > > The comment for indAudmediaParm and the ASN.1 > IndAudMediaDescriptor > > > > > indicates that it should be a list. Or am I missing something? > > > > > > > Also, see definition of mediaDescriptor! > > > > > > > > > > ABNF: > > > > > ---- > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > RBRKT > > > > > > > > > > ; at-most-once per item > > > > > ; and either streamParm or streamDescriptor but not both > > > > > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > > > > > indAudterminationStateDescriptor) > > > > > > > > > > ASN.1: > > > > > ----- > > > > > IndAudMediaDescriptor ::= SEQUENCE > > > > > { > > > > > > > > > > termStateDescr IndAudTerminationStateDescriptor > OPTIONAL, > > > > > streams CHOICE > > > > > { > > > > > oneStream IndAudStreamParms, > > > > > multiStream SEQUENCE OF IndAudStreamDescriptor > > > > > } OPTIONAL, > > > > > ... > > > > > } > > > > > > > > > > Regards, > > > > > /BMK > > > > > > > > > > _______________________________________________ > > > > > Megaco mailing list > > > > > Megaco@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > >-- > > >Micael Karlberg Ericsson AB, Älvsjö Sweden > > >Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development > > >ECN: 851 5668 Mail: micael.karlberg@ericsson.com > > >Fax: +46 8 727 5775 > > > > > >_______________________________________________ > > >Megaco mailing list > > >Megaco@ietf.org > > >https://www1.ietf.org/mailman/listinfo/megaco > > > > > >_______________________________________________ > > >Megaco mailing list > > >Megaco@ietf.org > > >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jun 18 11:28:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12562 for ; Wed, 18 Jun 2003 11:28:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SeMw-0005iH-3Z; Wed, 18 Jun 2003 10:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdiG-0003DY-Cr for megaco@optimus.ietf.org; Wed, 18 Jun 2003 10:15:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09351 for ; Wed, 18 Jun 2003 10:14:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sdfz-00057j-00 for megaco@ietf.org; Wed, 18 Jun 2003 10:12:39 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19Sdfy-00057Y-00 for megaco@ietf.org; Wed, 18 Jun 2003 10:12:38 -0400 Received: from smilevm.winphoria.com ([10.14.25.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 18 Jun 2003 10:14:25 -0400 Message-Id: <5.2.1.1.0.20030618092037.02dc0310@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 18 Jun 2003 10:11:56 -0400 To: Christian Groves , Kevin Boyle , megaco@ietf.org From: Aleksandr Ryabin Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Cc: micael.karlberg@ericsson.com In-Reply-To: <3EEFE29F.FA336106@ericsson.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 18 Jun 2003 14:14:26.0070 (UTC) FILETIME=[EC86BB60:01C335A3] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA12562 Hi Christian, I think that Michael originally pointed out on discrepancy between ASN.1 and ABNF. Specifically, IndAudMediaDescriptor contains multiStream which is defined as a SEQUENCE: multiStream SEQUENCE OF IndAudStreamDescriptor Thus inside of one IndAudMediaDescriptor construction MGC can place multiple audit instructions for different streams, while ABNF does not allow that. You are right, there is a way to do it, but ABNF does not match ASN.1 in this case on how to do it. In this case ASN.1 allows two ways to do the same thing, while ABNF only one way. Generally speaking my personal opinion that we should minimize cases when MGC can do same things different ways and instead fix ASN.1 spec to not allow SEQUENCE (but see more below), e.g.: multiStream IndAudStreamDescriptor Same problem for propertyParms in IndAudLocalControlDescriptor and in IndAudTerminationStateDescriptor (SEQUENCE OF should be removed). But if we are to fix this then we should fix the rest if ASN.1 indAudXXX constructions to not allow multiple audits inside of one construction and that means turning SEQENCE into CHOICE for most of IndAudXXX constructions. So the way I see it, ASN.1 went the "flexible" way which can be complex, but and minimizes the final size of audit when several items needs to be audited inside of one descriptor, while ABNF went "simple" way which makes it strait forward, but it can get big if MGC need to audit more then one item inside of one descriptor. I think we should let it be since it is too much of the changes and add flexibility of ASN.1 into ABNF in the next version which includes adding (COMMA...) in most of indAudXXX constructions in ABNF. At that point we should qualify with "at-most-once per item" indAudauditReturnParameter in ABNF and IndAuditParameter in ASN.1 do disallow "old simple" way. Regards, Aleks At 11:55 PM 6/17/2003, Christian Groves wrote: >G'Day Kevin and Micael, > >I still don't see a problem. indAudterminationAudit allows you to request >multiple values: >indAudterminationAudit = indAudauditReturnParameter > *(COMMA indAudauditReturnParameter) > >indAudauditReturnParameter = (indAudmediaDescriptor / / > >indAudeventsDescriptor / > >indAudsignalsDescriptor / > >indAuddigitMapDescriptor / > >indAudeventBufferDescriptor / > >indAudstatisticsDescriptor / > >indAudpackagesDescriptor) > > >indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > >This allows you to request several streams. So the capabilities are >aligned. The >reason we have the indAudstreamParm / indAudstreamDescriptor is to allow >for the >case where no streamid is given. > >Regards, Christian > >Kevin Boyle wrote: > > > > Aha... I see the problem now. In binary, you can request info about > several > > streams at once, but you may only request info about one stream in > text. Is > > this an accurate summary? > > > > Seeing as this would be a syntax change, we need to know if anyone > would have > > major heartburn over changing the syntax to fix this. If not, I will > draft up > > an IG item to fix this... > > > > Speaking personally, I think this is a beneficial change, because it > makes the > > syntax align between the expression of items within the media > descriptor, and > > the audit of items within the media descriptor, as well as making both > binary > > and text align in capability. > > > > Any other comments? > > > > Kevin > > > > -----Original Message----- > > From: Micael Karlberg [mailto:micael.karlberg@ericsson.com] > > Sent: Tuesday, June 17, 2003 1:26 PM > > To: Christian Groves > > Cc: megaco@ietf.org > > Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? > > > > Hello Christian, > > > > Christian Groves writes: > > > Hello Micael, > > > > > > I don't understand what the problem is nor the comments in the ASN.1 you > > are > referring to? > > > > The comment ("at-most-once per item...") is in the ABNF. > > > > > If you are referring to the ::= SEQUENCE this is actually an ASN.1 > > > construct that says that a sequence of information elements may be encoded, > > in > this case "termStateDescr" & a choice of streams. > > > > This is how see it also. > > > > > This same information is represented by the ABNF. > > > > This I _cannot_ find! > > > > The comment in the ABNF seems to indicate that it should be as in > > the ASN.1 but the ABNF definition of the indAudmediaDescriptor > > allow for only one value of indAudmediaParm. > > > > Therefor my _question_ if the definition should'nt really be: > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > *(COMMA indAudmediaParm) RBRKT > > > > Also, the defintion of the mediaDescriptor strikes me as _very_ similar > to my > > "proposal": > > > > mediaDescriptor = MediaToken LBRKT mediaParm > > *(COMMA mediaParm) RBRKT > > > > ; at-most one terminationStateDescriptor > > ; and either streamParm(s) or streamDescriptor(s) but not both > > mediaParm = (streamParm / streamDescriptor / > > terminationStateDescriptor) > > > > Regards, > > /BMK > > > > > > > > Regards, Christian > > > > > > Micael Karlberg wrote: > > > > > > > > Hi, > > > > > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch > > > > between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > > My > > question is: Should the definition of ABNF indAudmediaDescriptor > > > really > > be: > > > > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > > > *(COMMA indAudmediaParm) RBRKT > > > > > > > > The comment for indAudmediaParm and the ASN.1 > IndAudMediaDescriptor > > > > indicates that it should be a list. Or am I missing something? > > > > > > > > Also, see definition of mediaDescriptor! > > > > > > > > ABNF: > > > > ---- > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > > > > > > > > ; at-most-once per item > > > > ; and either streamParm or streamDescriptor but not both > > > > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > > > > indAudterminationStateDescriptor) > > > > > > > > ASN.1: > > > > ----- > > > > IndAudMediaDescriptor ::= SEQUENCE > > > > { > > > > > > > > termStateDescr IndAudTerminationStateDescriptor OPTIONAL, > > > > streams CHOICE > > > > { > > > > oneStream IndAudStreamParms, > > > > multiStream SEQUENCE OF IndAudStreamDescriptor > > > > } OPTIONAL, > > > > ... > > > > } > > > > > > > > Regards, > > > > /BMK > > > > > > > > _______________________________________________ > > > > Megaco mailing list > > > > Megaco@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/megaco > > > > -- > > Micael Karlberg Ericsson AB, Älvsjö Sweden > > Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development > > ECN: 851 5668 Mail: micael.karlberg@ericsson.com > > Fax: +46 8 727 5775 > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Jun 18 12:00:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14410 for ; Wed, 18 Jun 2003 12:00:54 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IG0QW01374 for megaco-archive@odin.ietf.org; Wed, 18 Jun 2003 12:00:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SerJ-0007FZ-Ap for megaco-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 11:28:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12528 for ; Wed, 18 Jun 2003 11:28:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sep3-0005mX-00 for megaco-web-archive@ietf.org; Wed, 18 Jun 2003 11:26:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Sep2-0005mU-00 for megaco-web-archive@ietf.org; Wed, 18 Jun 2003 11:26:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SeMw-0005iH-3Z; Wed, 18 Jun 2003 10:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdiG-0003DY-Cr for megaco@optimus.ietf.org; Wed, 18 Jun 2003 10:15:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09351 for ; Wed, 18 Jun 2003 10:14:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sdfz-00057j-00 for megaco@ietf.org; Wed, 18 Jun 2003 10:12:39 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19Sdfy-00057Y-00 for megaco@ietf.org; Wed, 18 Jun 2003 10:12:38 -0400 Received: from smilevm.winphoria.com ([10.14.25.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 18 Jun 2003 10:14:25 -0400 Message-Id: <5.2.1.1.0.20030618092037.02dc0310@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 18 Jun 2003 10:11:56 -0400 To: Christian Groves , Kevin Boyle , megaco@ietf.org From: Aleksandr Ryabin Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Cc: micael.karlberg@ericsson.com In-Reply-To: <3EEFE29F.FA336106@ericsson.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 18 Jun 2003 14:14:26.0070 (UTC) FILETIME=[EC86BB60:01C335A3] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA14410 Hi Christian, I think that Michael originally pointed out on discrepancy between ASN.1 and ABNF. Specifically, IndAudMediaDescriptor contains multiStream which is defined as a SEQUENCE: multiStream SEQUENCE OF IndAudStreamDescriptor Thus inside of one IndAudMediaDescriptor construction MGC can place multiple audit instructions for different streams, while ABNF does not allow that. You are right, there is a way to do it, but ABNF does not match ASN.1 in this case on how to do it. In this case ASN.1 allows two ways to do the same thing, while ABNF only one way. Generally speaking my personal opinion that we should minimize cases when MGC can do same things different ways and instead fix ASN.1 spec to not allow SEQUENCE (but see more below), e.g.: multiStream IndAudStreamDescriptor Same problem for propertyParms in IndAudLocalControlDescriptor and in IndAudTerminationStateDescriptor (SEQUENCE OF should be removed). But if we are to fix this then we should fix the rest if ASN.1 indAudXXX constructions to not allow multiple audits inside of one construction and that means turning SEQENCE into CHOICE for most of IndAudXXX constructions. So the way I see it, ASN.1 went the "flexible" way which can be complex, but and minimizes the final size of audit when several items needs to be audited inside of one descriptor, while ABNF went "simple" way which makes it strait forward, but it can get big if MGC need to audit more then one item inside of one descriptor. I think we should let it be since it is too much of the changes and add flexibility of ASN.1 into ABNF in the next version which includes adding (COMMA...) in most of indAudXXX constructions in ABNF. At that point we should qualify with "at-most-once per item" indAudauditReturnParameter in ABNF and IndAuditParameter in ASN.1 do disallow "old simple" way. Regards, Aleks At 11:55 PM 6/17/2003, Christian Groves wrote: >G'Day Kevin and Micael, > >I still don't see a problem. indAudterminationAudit allows you to request >multiple values: >indAudterminationAudit = indAudauditReturnParameter > *(COMMA indAudauditReturnParameter) > >indAudauditReturnParameter = (indAudmediaDescriptor / / > >indAudeventsDescriptor / > >indAudsignalsDescriptor / > >indAuddigitMapDescriptor / > >indAudeventBufferDescriptor / > >indAudstatisticsDescriptor / > >indAudpackagesDescriptor) > > >indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > >This allows you to request several streams. So the capabilities are >aligned. The >reason we have the indAudstreamParm / indAudstreamDescriptor is to allow >for the >case where no streamid is given. > >Regards, Christian > >Kevin Boyle wrote: > > > > Aha... I see the problem now. In binary, you can request info about > several > > streams at once, but you may only request info about one stream in > text. Is > > this an accurate summary? > > > > Seeing as this would be a syntax change, we need to know if anyone > would have > > major heartburn over changing the syntax to fix this. If not, I will > draft up > > an IG item to fix this... > > > > Speaking personally, I think this is a beneficial change, because it > makes the > > syntax align between the expression of items within the media > descriptor, and > > the audit of items within the media descriptor, as well as making both > binary > > and text align in capability. > > > > Any other comments? > > > > Kevin > > > > -----Original Message----- > > From: Micael Karlberg [mailto:micael.karlberg@ericsson.com] > > Sent: Tuesday, June 17, 2003 1:26 PM > > To: Christian Groves > > Cc: megaco@ietf.org > > Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? > > > > Hello Christian, > > > > Christian Groves writes: > > > Hello Micael, > > > > > > I don't understand what the problem is nor the comments in the ASN.1 you > > are > referring to? > > > > The comment ("at-most-once per item...") is in the ABNF. > > > > > If you are referring to the ::= SEQUENCE this is actually an ASN.1 > > > construct that says that a sequence of information elements may be encoded, > > in > this case "termStateDescr" & a choice of streams. > > > > This is how see it also. > > > > > This same information is represented by the ABNF. > > > > This I _cannot_ find! > > > > The comment in the ABNF seems to indicate that it should be as in > > the ASN.1 but the ABNF definition of the indAudmediaDescriptor > > allow for only one value of indAudmediaParm. > > > > Therefor my _question_ if the definition should'nt really be: > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > *(COMMA indAudmediaParm) RBRKT > > > > Also, the defintion of the mediaDescriptor strikes me as _very_ similar > to my > > "proposal": > > > > mediaDescriptor = MediaToken LBRKT mediaParm > > *(COMMA mediaParm) RBRKT > > > > ; at-most one terminationStateDescriptor > > ; and either streamParm(s) or streamDescriptor(s) but not both > > mediaParm = (streamParm / streamDescriptor / > > terminationStateDescriptor) > > > > Regards, > > /BMK > > > > > > > > Regards, Christian > > > > > > Micael Karlberg wrote: > > > > > > > > Hi, > > > > > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch > > > > between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > > My > > question is: Should the definition of ABNF indAudmediaDescriptor > > > really > > be: > > > > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > > > *(COMMA indAudmediaParm) RBRKT > > > > > > > > The comment for indAudmediaParm and the ASN.1 > IndAudMediaDescriptor > > > > indicates that it should be a list. Or am I missing something? > > > > > > > > Also, see definition of mediaDescriptor! > > > > > > > > ABNF: > > > > ---- > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > > > > > > > > ; at-most-once per item > > > > ; and either streamParm or streamDescriptor but not both > > > > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > > > > indAudterminationStateDescriptor) > > > > > > > > ASN.1: > > > > ----- > > > > IndAudMediaDescriptor ::= SEQUENCE > > > > { > > > > > > > > termStateDescr IndAudTerminationStateDescriptor OPTIONAL, > > > > streams CHOICE > > > > { > > > > oneStream IndAudStreamParms, > > > > multiStream SEQUENCE OF IndAudStreamDescriptor > > > > } OPTIONAL, > > > > ... > > > > } > > > > > > > > Regards, > > > > /BMK > > > > > > > > _______________________________________________ > > > > Megaco mailing list > > > > Megaco@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/megaco > > > > -- > > Micael Karlberg Ericsson AB, Älvsjö Sweden > > Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development > > ECN: 851 5668 Mail: micael.karlberg@ericsson.com > > Fax: +46 8 727 5775 > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jun 18 15:58:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26206 for ; Wed, 18 Jun 2003 15:58:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SiuX-0002lF-16; Wed, 18 Jun 2003 15:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SQqZ-0007qq-Pw for megaco@optimus.ietf.org; Tue, 17 Jun 2003 20:30:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17095 for ; Tue, 17 Jun 2003 20:30:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SQoK-00069o-00 for megaco@ietf.org; Tue, 17 Jun 2003 20:28:24 -0400 Received: from venus.uos.ac.kr ([210.125.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19SQoJ-00069O-00 for megaco@ietf.org; Tue, 17 Jun 2003 20:28:23 -0400 Received: from yim (hektor.etri.re.kr [129.254.193.202]) (authenticated bits=0) by venus.uos.ac.kr (8.12.3/8.12.3/Debian -4) with ESMTP id h5I0TrM7014766 for ; Wed, 18 Jun 2003 09:29:57 +0900 From: "???" To: Date: Wed, 18 Jun 2003 09:29:41 +0900 Message-ID: <000001c33530$bb10f960$cac1fe81@yim> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Megaco] Controlling a Media Server using 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: , Content-Transfer-Encoding: 7bit Hi, List. If the network configuration described below. 1) MGC controlls Media Server Using Megaco. 2) Media server is conntected to IP network if we want to make media server to connect to the MG to send some annoncement, then How can we describe context model in Media Server? Are there a physical termination representing a kind of media source and ephemeral termination representing RTP stream in the context? Is a media source can be modeled as a termination? Or just one ephemeral termination is included in the context? In this case, Can we play signals, which is defined in Annex K, on the ephemeral termination? please give me your opinion. regards. yim. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Jun 18 16:18:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27493 for ; Wed, 18 Jun 2003 16:18:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IKI6X14923 for megaco-archive@odin.ietf.org; Wed, 18 Jun 2003 16:18:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sj44-00037q-VH for megaco-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 15:57:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26187 for ; Wed, 18 Jun 2003 15:57:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sj1n-0001Ds-00 for megaco-web-archive@ietf.org; Wed, 18 Jun 2003 15:55:31 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Sj1m-0001Do-00 for megaco-web-archive@ietf.org; Wed, 18 Jun 2003 15:55:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SiuX-0002lF-16; Wed, 18 Jun 2003 15:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SQqZ-0007qq-Pw for megaco@optimus.ietf.org; Tue, 17 Jun 2003 20:30:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17095 for ; Tue, 17 Jun 2003 20:30:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SQoK-00069o-00 for megaco@ietf.org; Tue, 17 Jun 2003 20:28:24 -0400 Received: from venus.uos.ac.kr ([210.125.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19SQoJ-00069O-00 for megaco@ietf.org; Tue, 17 Jun 2003 20:28:23 -0400 Received: from yim (hektor.etri.re.kr [129.254.193.202]) (authenticated bits=0) by venus.uos.ac.kr (8.12.3/8.12.3/Debian -4) with ESMTP id h5I0TrM7014766 for ; Wed, 18 Jun 2003 09:29:57 +0900 From: "???" To: Date: Wed, 18 Jun 2003 09:29:41 +0900 Message-ID: <000001c33530$bb10f960$cac1fe81@yim> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Megaco] Controlling a Media Server using 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, List. If the network configuration described below. 1) MGC controlls Media Server Using Megaco. 2) Media server is conntected to IP network if we want to make media server to connect to the MG to send some annoncement, then How can we describe context model in Media Server? Are there a physical termination representing a kind of media source and ephemeral termination representing RTP stream in the context? Is a media source can be modeled as a termination? Or just one ephemeral termination is included in the context? In this case, Can we play signals, which is defined in Annex K, on the ephemeral termination? please give me your opinion. regards. yim. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jun 18 22:17:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11726 for ; Wed, 18 Jun 2003 22:17:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sogc-0008N8-15; Wed, 18 Jun 2003 21:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SofN-0008H9-G6 for megaco@optimus.ietf.org; Wed, 18 Jun 2003 21:56:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11050 for ; Wed, 18 Jun 2003 21:56:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sod5-00056U-00 for megaco@ietf.org; Wed, 18 Jun 2003 21:54:23 -0400 Received: from [218.154.52.161] (helo=dinnovan.com) by ietf-mx with esmtp (Exim 4.12) id 19Sod4-00056R-00 for megaco@ietf.org; Wed, 18 Jun 2003 21:54:23 -0400 Received: from Spooler by dinnovan.com (Mercury/32 v3.21c) ID MO000D61; 19 Jun 03 11:08:40 +0900 Received: from spooler by dinnovan.com (Mercury/32 v3.21c); 19 Jun 03 11:07:52 +0900 Received: from dongpyo (10.1.1.22) by dinnovan.com (Mercury/32 v3.21c) ID MG000D60; 19 Jun 03 11:07:51 +0900 Message-ID: <002801c33606$bf4e76c0$1601010a@dongpyo> From: =?x-user-defined?B?wMy1v8el?= To: Date: Thu, 19 Jun 2003 11:01:50 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C33652.2F26DC80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Megaco] About a service control over a media server Sender: megaco-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_0025_01C33652.2F26DC80 Content-Type: text/plain; charset="x-user-defined" Content-Transfer-Encoding: base64 SGksIGFsbC4uIQ0KSSdtIExlZSBmcm9tIEtvcmVhLg0KSSBnb3QgdG8gaGF2ZSBzb21lIHF1ZXN0 aW9ucyB3aGlsZSBkZXZlbG9waW5nIGEgbWVkaWEgc2VydmVyLg0KDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU0lQICAoMSkNCkFTKEFwcGljYXRpb24gU2Vy dmVyKSAtLS0tLS0tLS0tLS0tLS0tIA0KICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgfCBTSVAgKDIpICAgICAgICAgICAgICAg ICAgICAgICB8DQogICAgICAgICAgICAgIHwgICAgICAgICAgIE1lZ2FjbyAgKDMpICAgICAgfA0K ICAgICAgIFNvZnRzd2l0Y2ggLS0tLS0tLS0tLS0tLS0tLS0tLS0+IE1lZGlhIFNlcnZlcg0KDQoN Cg0KTGV0J3MgYXNzdW1lIHRoYXQgYSBuZXcgY2FsbCBpcyBzZXQgdXAgdGhyb3VnaCBtZWdhY28g cHJvdG9jb2wgYmV0d2VlbiB0aGUgc29mdHN3aXRjaCBhbmQgdGhlIG1lZGlhIHNlcnZlciBhcyBw aWN0dXJlIGFib3ZlLg0KVGhlcmUgYXJlIHNldmVyYWwgd2F5cyB0aGF0IHdlIGNhbiAgcHJvY2Vl ZCB0aGUgc2VydmljZSBmbG93cyBhZnRlciBhIGNhbGwgc2V0dXAuDQoNCiAgICAgICAgICBTSVAN CjEuIEFTLS0tLS0tLT5NZWRpYSBTZXJ2ZXINCg0KICAgICAgICAgIFNJUCAgICAgICAgICAgICAg ICAgIE1lZ2Fjbw0KMi4gQVMtLS0tLS0tPlNvZnRzd2l0Y2gtLS0tLS0tPk1lZGlhIFNlcnZlcg0K DQpBY2NvcmRpbmcgdG8gMSwgQVMgZGlyZWN0bHkgY29udHJvbHMgb3ZlciB0aGUgbWVkaWEgc2Vy dmVyIGZvciB0aGUgc2VydmljZSBwcm9jZWR1cmUgYnkgdXNpbmcgU0lQLg0KSW4gdGhlIGNhc2Ug b2YgMiwgdGhlIG1lZGlhIHNlcnZlciBpcyBjb250cm9sbGVkIGJ5IHRoZSBzb2Z0c3dpdGNoIHRo cm91Z2ggTWVnYWNvIGZvciB0aGUgc2VydmljZSBwcm9jZWR1cmUuDQoNCklmIHdlIHVzZSAxLCBJ IHRoaW5rIHRoZSBtZWRpYSBzZXJ2ZXIgbXVzdCBoYXZlIHNvbWUgZnVuY3Rpb24gZm9yIGFzc29j aWF0aW5nICgzKSBjYWxsIHdpdGggKDEpIHNlcnZpY2UgY29udHJvbC4NCg0KLS0tWzFdLiBEbyB5 b3Uga25vdyBhbnkgYWxnb3JpdGhtIG9yIGdvb2Qgd2F5IHRvIHNvbHZlIHRoaXMgcHJvYmxlbT8N Ci0tLVsyXS4gSW4gYWRkaXRpb24sIEkgaGF2ZSBubyBpZGVhIGhvdyBBUyBjYW4gY29udHJvbCB0 aGUgc2VydmljZS4gKGNhbGwgZmxvdykNCi0tLVszXS4gSSBoYXZlIHRyaWVkIHRvIGZpbmQgc29t ZSBkb2N1bWVudHMgb3IgZHJhZnRzIGFib3V0IHRoZSB3YXlzIG9mIHNlcnZpY2UgY29udHJvbCAo SSBtZWFuIGluIGRldGFpbCksIGJ1dCBJIGNvdWxkbid0Lg0KDQpEbyB5b3UgZ3V5cyBoYXZlIGFu eSBpZGVhIG9uIHRoaXM/ ------=_NextPart_000_0025_01C33652.2F26DC80 Content-Type: text/html; charset="x-user-defined" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXgtdXNlci1kZWZpbmVkIj4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTEyNiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPERJVj48 Rk9OVCBzaXplPTI+SGksIGFsbC4uITwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkn bSBMZWUgZnJvbSBLb3JlYS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JIGdvdCB0 byBoYXZlIHNvbWUgcXVlc3Rpb25zIHdoaWxlIGRldmVsb3BpbmcgYSBtZWRpYSANCnNlcnZlci48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+PEZPTlQgc2l6ZT0yPjwvRk9O VD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgDQpzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KU0lQJm5i c3A7ICgxKTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkFTKEFwcGljYXRpb24gU2Vy dmVyKSAtLS0tLS0tLS0tLS0tLS0tJm5ic3A7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCANCnNp emU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7fDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgDQpzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7fCZuYnNwO1NJUCANCigyKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIA0Kc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtNZWdhY28mbmJzcDsmbmJzcDsoMykmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJz cDsmbmJzcDt8PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNvZnRzd2l0Y2ggDQotLS0tLS0tLS0tLS0tLS0tLS0tLSZn dDsgTWVkaWEgU2VydmVyPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+DQo8RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4Oz48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPkxldCdzIGFzc3VtZSB0aGF0IGEgbmV3IGNhbGwgaXMgc2V0IHVwIHRo cm91Z2ggbWVnYWNvIHByb3RvY29sIGJldHdlZW4gdGhlIA0Kc29mdHN3aXRjaCBhbmQmbmJzcDt0 aGUgbWVkaWEgc2VydmVyIGFzIHBpY3R1cmUgYWJvdmUuPC9ESVY+DQo8RElWPlRoZXJlIGFyZSBz ZXZlcmFsIHdheXMgdGhhdCB3ZSBjYW4mbmJzcDsgcHJvY2VlZCB0aGUgc2VydmljZSBmbG93cyBh ZnRlciBhIA0KY2FsbCBzZXR1cC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTSVA8L0RJ Vj4NCjxESVY+MS4mbmJzcDtBUy0tLS0tLS0mZ3Q7TWVkaWEgU2VydmVyPC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQpTSVAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQpNZWdhY288L0RJVj4NCjxESVY+Mi4mbmJzcDtBUy0tLS0tLS0mZ3Q7U29mdHN3 aXRjaC0tLS0tLS0mZ3Q7TWVkaWEgU2VydmVyPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj5BY2NvcmRpbmcgdG8gMSwgQVMgZGlyZWN0bHkgY29udHJvbHMgb3ZlciB0aGUgbWVkaWEgc2Vy dmVyIGZvciB0aGUgc2VydmljZSANCnByb2NlZHVyZSBieSB1c2luZyBTSVAuPC9ESVY+DQo8RElW PkluIHRoZSBjYXNlIG9mIDIsIHRoZSBtZWRpYSBzZXJ2ZXIgaXMgY29udHJvbGxlZCBieSB0aGUg c29mdHN3aXRjaCB0aHJvdWdoIA0KTWVnYWNvIGZvciB0aGUgc2VydmljZSBwcm9jZWR1cmUuPC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5JZiB3ZSB1c2UgMSwgSSB0aGluayB0aGUgbWVk aWEgc2VydmVyIG11c3QgaGF2ZSBzb21lIGZ1bmN0aW9uIA0KZm9yJm5ic3A7YXNzb2NpYXRpbmcg KDMpIGNhbGwmbmJzcDt3aXRoICgxKSBzZXJ2aWNlIGNvbnRyb2wuPC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj4tLS1bMV0uIERvIHlvdSBrbm93Jm5ic3A7YW55IGFsZ29yaXRobSBvciBn b29kIHdheSB0byBzb2x2ZSB0aGlzIA0KcHJvYmxlbT88L0RJVj4NCjxESVY+LS0tWzJdLiBJbiBh ZGRpdGlvbiwgSSBoYXZlIG5vIGlkZWEgaG93IEFTIGNhbiBjb250cm9sIHRoZSBzZXJ2aWNlLiAo Y2FsbCANCmZsb3cpPC9ESVY+DQo8RElWPi0tLVszXS4gSSBoYXZlIHRyaWVkIHRvIGZpbmQgc29t ZSBkb2N1bWVudHMgb3IgZHJhZnRzIGFib3V0IHRoZSB3YXlzIG9mIA0Kc2VydmljZSBjb250cm9s IChJIG1lYW4gaW4gZGV0YWlsKSwgYnV0IEkgY291bGRuJ3QuPC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj5EbyB5b3UgZ3V5cyBoYXZlIGFueSBpZGVhIG9uIA0KdGhpcz88L0RJVj48L0ZP TlQ+PC9ESVY+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0025_01C33652.2F26DC80-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Jun 18 22:22:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11817 for ; Wed, 18 Jun 2003 22:22:22 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5J2Lt903807 for megaco-archive@odin.ietf.org; Wed, 18 Jun 2003 22:21:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SozG-0000pN-96 for megaco-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 22:17:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11700 for ; Wed, 18 Jun 2003 22:17:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sowy-0005Ix-00 for megaco-web-archive@ietf.org; Wed, 18 Jun 2003 22:14:56 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Sowx-0005Iu-00 for megaco-web-archive@ietf.org; Wed, 18 Jun 2003 22:14:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sogc-0008N8-15; Wed, 18 Jun 2003 21:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SofN-0008H9-G6 for megaco@optimus.ietf.org; Wed, 18 Jun 2003 21:56:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11050 for ; Wed, 18 Jun 2003 21:56:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sod5-00056U-00 for megaco@ietf.org; Wed, 18 Jun 2003 21:54:23 -0400 Received: from [218.154.52.161] (helo=dinnovan.com) by ietf-mx with esmtp (Exim 4.12) id 19Sod4-00056R-00 for megaco@ietf.org; Wed, 18 Jun 2003 21:54:23 -0400 Received: from Spooler by dinnovan.com (Mercury/32 v3.21c) ID MO000D61; 19 Jun 03 11:08:40 +0900 Received: from spooler by dinnovan.com (Mercury/32 v3.21c); 19 Jun 03 11:07:52 +0900 Received: from dongpyo (10.1.1.22) by dinnovan.com (Mercury/32 v3.21c) ID MG000D60; 19 Jun 03 11:07:51 +0900 Message-ID: <002801c33606$bf4e76c0$1601010a@dongpyo> From: =?x-user-defined?B?wMy1v8el?= To: Date: Thu, 19 Jun 2003 11:01:50 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C33652.2F26DC80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Megaco] About a service control over a media server Sender: megaco-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_0025_01C33652.2F26DC80 Content-Type: text/plain; charset="x-user-defined" Content-Transfer-Encoding: base64 SGksIGFsbC4uIQ0KSSdtIExlZSBmcm9tIEtvcmVhLg0KSSBnb3QgdG8gaGF2ZSBzb21lIHF1ZXN0 aW9ucyB3aGlsZSBkZXZlbG9waW5nIGEgbWVkaWEgc2VydmVyLg0KDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU0lQICAoMSkNCkFTKEFwcGljYXRpb24gU2Vy dmVyKSAtLS0tLS0tLS0tLS0tLS0tIA0KICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgfCBTSVAgKDIpICAgICAgICAgICAgICAg ICAgICAgICB8DQogICAgICAgICAgICAgIHwgICAgICAgICAgIE1lZ2FjbyAgKDMpICAgICAgfA0K ICAgICAgIFNvZnRzd2l0Y2ggLS0tLS0tLS0tLS0tLS0tLS0tLS0+IE1lZGlhIFNlcnZlcg0KDQoN Cg0KTGV0J3MgYXNzdW1lIHRoYXQgYSBuZXcgY2FsbCBpcyBzZXQgdXAgdGhyb3VnaCBtZWdhY28g cHJvdG9jb2wgYmV0d2VlbiB0aGUgc29mdHN3aXRjaCBhbmQgdGhlIG1lZGlhIHNlcnZlciBhcyBw aWN0dXJlIGFib3ZlLg0KVGhlcmUgYXJlIHNldmVyYWwgd2F5cyB0aGF0IHdlIGNhbiAgcHJvY2Vl ZCB0aGUgc2VydmljZSBmbG93cyBhZnRlciBhIGNhbGwgc2V0dXAuDQoNCiAgICAgICAgICBTSVAN CjEuIEFTLS0tLS0tLT5NZWRpYSBTZXJ2ZXINCg0KICAgICAgICAgIFNJUCAgICAgICAgICAgICAg ICAgIE1lZ2Fjbw0KMi4gQVMtLS0tLS0tPlNvZnRzd2l0Y2gtLS0tLS0tPk1lZGlhIFNlcnZlcg0K DQpBY2NvcmRpbmcgdG8gMSwgQVMgZGlyZWN0bHkgY29udHJvbHMgb3ZlciB0aGUgbWVkaWEgc2Vy dmVyIGZvciB0aGUgc2VydmljZSBwcm9jZWR1cmUgYnkgdXNpbmcgU0lQLg0KSW4gdGhlIGNhc2Ug b2YgMiwgdGhlIG1lZGlhIHNlcnZlciBpcyBjb250cm9sbGVkIGJ5IHRoZSBzb2Z0c3dpdGNoIHRo cm91Z2ggTWVnYWNvIGZvciB0aGUgc2VydmljZSBwcm9jZWR1cmUuDQoNCklmIHdlIHVzZSAxLCBJ IHRoaW5rIHRoZSBtZWRpYSBzZXJ2ZXIgbXVzdCBoYXZlIHNvbWUgZnVuY3Rpb24gZm9yIGFzc29j aWF0aW5nICgzKSBjYWxsIHdpdGggKDEpIHNlcnZpY2UgY29udHJvbC4NCg0KLS0tWzFdLiBEbyB5 b3Uga25vdyBhbnkgYWxnb3JpdGhtIG9yIGdvb2Qgd2F5IHRvIHNvbHZlIHRoaXMgcHJvYmxlbT8N Ci0tLVsyXS4gSW4gYWRkaXRpb24sIEkgaGF2ZSBubyBpZGVhIGhvdyBBUyBjYW4gY29udHJvbCB0 aGUgc2VydmljZS4gKGNhbGwgZmxvdykNCi0tLVszXS4gSSBoYXZlIHRyaWVkIHRvIGZpbmQgc29t ZSBkb2N1bWVudHMgb3IgZHJhZnRzIGFib3V0IHRoZSB3YXlzIG9mIHNlcnZpY2UgY29udHJvbCAo SSBtZWFuIGluIGRldGFpbCksIGJ1dCBJIGNvdWxkbid0Lg0KDQpEbyB5b3UgZ3V5cyBoYXZlIGFu eSBpZGVhIG9uIHRoaXM/ ------=_NextPart_000_0025_01C33652.2F26DC80 Content-Type: text/html; charset="x-user-defined" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXgtdXNlci1kZWZpbmVkIj4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTEyNiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPERJVj48 Rk9OVCBzaXplPTI+SGksIGFsbC4uITwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkn bSBMZWUgZnJvbSBLb3JlYS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JIGdvdCB0 byBoYXZlIHNvbWUgcXVlc3Rpb25zIHdoaWxlIGRldmVsb3BpbmcgYSBtZWRpYSANCnNlcnZlci48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+PEZPTlQgc2l6ZT0yPjwvRk9O VD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgDQpzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KU0lQJm5i c3A7ICgxKTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkFTKEFwcGljYXRpb24gU2Vy dmVyKSAtLS0tLS0tLS0tLS0tLS0tJm5ic3A7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCANCnNp emU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7fDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgDQpzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7fCZuYnNwO1NJUCANCigyKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIA0Kc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtNZWdhY28mbmJzcDsmbmJzcDsoMykmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJz cDsmbmJzcDt8PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNvZnRzd2l0Y2ggDQotLS0tLS0tLS0tLS0tLS0tLS0tLSZn dDsgTWVkaWEgU2VydmVyPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+DQo8RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4Oz48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPkxldCdzIGFzc3VtZSB0aGF0IGEgbmV3IGNhbGwgaXMgc2V0IHVwIHRo cm91Z2ggbWVnYWNvIHByb3RvY29sIGJldHdlZW4gdGhlIA0Kc29mdHN3aXRjaCBhbmQmbmJzcDt0 aGUgbWVkaWEgc2VydmVyIGFzIHBpY3R1cmUgYWJvdmUuPC9ESVY+DQo8RElWPlRoZXJlIGFyZSBz ZXZlcmFsIHdheXMgdGhhdCB3ZSBjYW4mbmJzcDsgcHJvY2VlZCB0aGUgc2VydmljZSBmbG93cyBh ZnRlciBhIA0KY2FsbCBzZXR1cC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTSVA8L0RJ Vj4NCjxESVY+MS4mbmJzcDtBUy0tLS0tLS0mZ3Q7TWVkaWEgU2VydmVyPC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQpTSVAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQpNZWdhY288L0RJVj4NCjxESVY+Mi4mbmJzcDtBUy0tLS0tLS0mZ3Q7U29mdHN3 aXRjaC0tLS0tLS0mZ3Q7TWVkaWEgU2VydmVyPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj5BY2NvcmRpbmcgdG8gMSwgQVMgZGlyZWN0bHkgY29udHJvbHMgb3ZlciB0aGUgbWVkaWEgc2Vy dmVyIGZvciB0aGUgc2VydmljZSANCnByb2NlZHVyZSBieSB1c2luZyBTSVAuPC9ESVY+DQo8RElW PkluIHRoZSBjYXNlIG9mIDIsIHRoZSBtZWRpYSBzZXJ2ZXIgaXMgY29udHJvbGxlZCBieSB0aGUg c29mdHN3aXRjaCB0aHJvdWdoIA0KTWVnYWNvIGZvciB0aGUgc2VydmljZSBwcm9jZWR1cmUuPC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5JZiB3ZSB1c2UgMSwgSSB0aGluayB0aGUgbWVk aWEgc2VydmVyIG11c3QgaGF2ZSBzb21lIGZ1bmN0aW9uIA0KZm9yJm5ic3A7YXNzb2NpYXRpbmcg KDMpIGNhbGwmbmJzcDt3aXRoICgxKSBzZXJ2aWNlIGNvbnRyb2wuPC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj4tLS1bMV0uIERvIHlvdSBrbm93Jm5ic3A7YW55IGFsZ29yaXRobSBvciBn b29kIHdheSB0byBzb2x2ZSB0aGlzIA0KcHJvYmxlbT88L0RJVj4NCjxESVY+LS0tWzJdLiBJbiBh ZGRpdGlvbiwgSSBoYXZlIG5vIGlkZWEgaG93IEFTIGNhbiBjb250cm9sIHRoZSBzZXJ2aWNlLiAo Y2FsbCANCmZsb3cpPC9ESVY+DQo8RElWPi0tLVszXS4gSSBoYXZlIHRyaWVkIHRvIGZpbmQgc29t ZSBkb2N1bWVudHMgb3IgZHJhZnRzIGFib3V0IHRoZSB3YXlzIG9mIA0Kc2VydmljZSBjb250cm9s IChJIG1lYW4gaW4gZGV0YWlsKSwgYnV0IEkgY291bGRuJ3QuPC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj5EbyB5b3UgZ3V5cyBoYXZlIGFueSBpZGVhIG9uIA0KdGhpcz88L0RJVj48L0ZP TlQ+PC9ESVY+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0025_01C33652.2F26DC80-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jun 19 13:57:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05103 for ; Thu, 19 Jun 2003 13:57:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3ef-0001xw-Fz; Thu, 19 Jun 2003 13:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3eN-0001uw-Tn for megaco@optimus.ietf.org; Thu, 19 Jun 2003 13:56:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05048 for ; Thu, 19 Jun 2003 13:56:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3c4-0000Nw-00 for megaco@ietf.org; Thu, 19 Jun 2003 13:54:20 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 19T3c4-0000Nf-00 for megaco@ietf.org; Thu, 19 Jun 2003 13:54:20 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5JHu4b13296 for ; Thu, 19 Jun 2003 13:56:05 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jun 2003 13:56:04 -0400 Message-ID: From: "Kevin Boyle" To: ??? , megaco@ietf.org Subject: RE: [Megaco] Controlling a Media Server using MEGACO Date: Thu, 19 Jun 2003 13:55:58 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Comments inline. [KJBII] Kevin -----Original Message----- From: ??? [mailto:siba@venus.uos.ac.kr] Sent: Tuesday, June 17, 2003 8:30 PM To: megaco@ietf.org Subject: [Megaco] Controlling a Media Server using MEGACO Hi, List. If the network configuration described below. 1) MGC controlls Media Server Using Megaco. 2) Media server is conntected to IP network if we want to make media server to connect to the MG to send some annoncement, then How can we describe context model in Media Server? [KJBII] This would depend upon your implementation. Are there a physical termination representing a kind of media source and ephemeral termination representing RTP stream in the context? Is a media source can be modeled as a termination? [KJBII] A termination is defined as the source or sink of a media flow. So, yes, a media source can be modeled as a termination. The model you describe with a physical as the media source, and an ephemeral as the packet bearer stream is certainly one way that you can build this half call. Or just one ephemeral termination is included in the context? In this case, Can we play signals, which is defined in Annex K, on the ephemeral termination? [KJBII] There is nothing that restricts asserting signals on ephemerals. If your implementation allows this kind of modeling, then certainly this could be another way to build this scenario. [KJBII] As an aside, there are more advanced media server packages in H.248.9. H.248.7 (formerly Annex K) only describes a simple announcement package. If you wish to do more complicated media serving, then I suggest having a good look at H.248.9. please give me your opinion. regards. yim. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Jun 19 13:57:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05118 for ; Thu, 19 Jun 2003 13:57:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JHv6V07648 for megaco-archive@odin.ietf.org; Thu, 19 Jun 2003 13:57:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3ek-0001zG-04 for megaco-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 13:57:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05065 for ; Thu, 19 Jun 2003 13:57:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3cQ-0000OF-00 for megaco-web-archive@ietf.org; Thu, 19 Jun 2003 13:54:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T3cQ-0000OC-00 for megaco-web-archive@ietf.org; Thu, 19 Jun 2003 13:54:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3ef-0001xw-Fz; Thu, 19 Jun 2003 13:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3eN-0001uw-Tn for megaco@optimus.ietf.org; Thu, 19 Jun 2003 13:56:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05048 for ; Thu, 19 Jun 2003 13:56:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3c4-0000Nw-00 for megaco@ietf.org; Thu, 19 Jun 2003 13:54:20 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 19T3c4-0000Nf-00 for megaco@ietf.org; Thu, 19 Jun 2003 13:54:20 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5JHu4b13296 for ; Thu, 19 Jun 2003 13:56:05 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jun 2003 13:56:04 -0400 Message-ID: From: "Kevin Boyle" To: ??? , megaco@ietf.org Subject: RE: [Megaco] Controlling a Media Server using MEGACO Date: Thu, 19 Jun 2003 13:55:58 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Comments inline. [KJBII] Kevin -----Original Message----- From: ??? [mailto:siba@venus.uos.ac.kr] Sent: Tuesday, June 17, 2003 8:30 PM To: megaco@ietf.org Subject: [Megaco] Controlling a Media Server using MEGACO Hi, List. If the network configuration described below. 1) MGC controlls Media Server Using Megaco. 2) Media server is conntected to IP network if we want to make media server to connect to the MG to send some annoncement, then How can we describe context model in Media Server? [KJBII] This would depend upon your implementation. Are there a physical termination representing a kind of media source and ephemeral termination representing RTP stream in the context? Is a media source can be modeled as a termination? [KJBII] A termination is defined as the source or sink of a media flow. So, yes, a media source can be modeled as a termination. The model you describe with a physical as the media source, and an ephemeral as the packet bearer stream is certainly one way that you can build this half call. Or just one ephemeral termination is included in the context? In this case, Can we play signals, which is defined in Annex K, on the ephemeral termination? [KJBII] There is nothing that restricts asserting signals on ephemerals. If your implementation allows this kind of modeling, then certainly this could be another way to build this scenario. [KJBII] As an aside, there are more advanced media server packages in H.248.9. H.248.7 (formerly Annex K) only describes a simple announcement package. If you wish to do more complicated media serving, then I suggest having a good look at H.248.9. please give me your opinion. regards. yim. _______________________________________________ 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 Jun 19 20:01:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26057 for ; Thu, 19 Jun 2003 20:01:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T9Kw-0003jK-Kd; Thu, 19 Jun 2003 20:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T9Kn-0003is-Du for megaco@optimus.ietf.org; Thu, 19 Jun 2003 20:00:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26010 for ; Thu, 19 Jun 2003 20:00:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T9IU-0004rc-00 for megaco@ietf.org; Thu, 19 Jun 2003 19:58:30 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19T9IU-0004rZ-00 for megaco@ietf.org; Thu, 19 Jun 2003 19:58:30 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 19 Jun 2003 17:03:04 -0800 Received: from VNANDURI-W2K.cisco.com (dhcp-171-71-9-175.cisco.com [171.71.9.175]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5K00JIY018666 for ; Thu, 19 Jun 2003 17:00:19 -0700 (PDT) Message-Id: <4.3.2.7.2.20030619164650.01ab4450@mira-sjc5-6.cisco.com> X-Sender: vnanduri@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jun 2003 17:00:18 -0700 To: megaco@ietf.org From: Venkata Narasimha Murthy Nanduri Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Megaco] Max # signals in a Sequential signal list Sender: megaco-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, What can be the maximum number of signals in a Sequential signal list? If RFC does not mention about the maximum number of signals in a list, Can MG restrict the Maximum number of signals that it can handle in a list? In practical scenarios, what will be the number of signals in a Sequential signal list? Thanks Venkata Venkata Nanduri [] Software Engineer Voice Gateway and Dial BU 3850 Zanker Road, Building 1 San jose - 95134 USA Tel: 408 853 8235 Fax: 408 525 0640 e-mail: vnanduri@cisco.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Jun 19 20:01:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26072 for ; Thu, 19 Jun 2003 20:01:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5K016814384 for megaco-archive@odin.ietf.org; Thu, 19 Jun 2003 20:01:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T9L0-0003jv-Aw for megaco-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 20:01:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26026 for ; Thu, 19 Jun 2003 20:01:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T9Ih-0004rk-00 for megaco-web-archive@ietf.org; Thu, 19 Jun 2003 19:58:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T9Ih-0004rg-00 for megaco-web-archive@ietf.org; Thu, 19 Jun 2003 19:58:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T9Kw-0003jK-Kd; Thu, 19 Jun 2003 20:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T9Kn-0003is-Du for megaco@optimus.ietf.org; Thu, 19 Jun 2003 20:00:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26010 for ; Thu, 19 Jun 2003 20:00:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T9IU-0004rc-00 for megaco@ietf.org; Thu, 19 Jun 2003 19:58:30 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19T9IU-0004rZ-00 for megaco@ietf.org; Thu, 19 Jun 2003 19:58:30 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 19 Jun 2003 17:03:04 -0800 Received: from VNANDURI-W2K.cisco.com (dhcp-171-71-9-175.cisco.com [171.71.9.175]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5K00JIY018666 for ; Thu, 19 Jun 2003 17:00:19 -0700 (PDT) Message-Id: <4.3.2.7.2.20030619164650.01ab4450@mira-sjc5-6.cisco.com> X-Sender: vnanduri@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jun 2003 17:00:18 -0700 To: megaco@ietf.org From: Venkata Narasimha Murthy Nanduri Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Megaco] Max # signals in a Sequential signal list Sender: megaco-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, What can be the maximum number of signals in a Sequential signal list? If RFC does not mention about the maximum number of signals in a list, Can MG restrict the Maximum number of signals that it can handle in a list? In practical scenarios, what will be the number of signals in a Sequential signal list? Thanks Venkata Venkata Nanduri [] Software Engineer Voice Gateway and Dial BU 3850 Zanker Road, Building 1 San jose - 95134 USA Tel: 408 853 8235 Fax: 408 525 0640 e-mail: vnanduri@cisco.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jun 19 21:24:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28052 for ; Thu, 19 Jun 2003 21:24:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TAdF-0000D9-5H; Thu, 19 Jun 2003 21:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TAcu-0000Cp-5P for megaco@optimus.ietf.org; Thu, 19 Jun 2003 21:23:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28024 for ; Thu, 19 Jun 2003 21:23:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TAaa-0005Jh-00 for megaco@ietf.org; Thu, 19 Jun 2003 21:21:16 -0400 Received: from web20712.mail.yahoo.com ([66.163.169.153]) by ietf-mx with smtp (Exim 4.12) id 19TAaa-0005Je-00 for megaco@ietf.org; Thu, 19 Jun 2003 21:21:16 -0400 Message-ID: <20030620012337.49509.qmail@web20712.mail.yahoo.com> Received: from [218.154.52.161] by web20712.mail.yahoo.com via HTTP; Thu, 19 Jun 2003 18:23:37 PDT Date: Thu, 19 Jun 2003 18:23:37 -0700 (PDT) From: Dongpyo Lee To: megaco@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1380671858-1056072217=:48811" Subject: [Megaco] Service control of a media server Sender: megaco-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: , --0-1380671858-1056072217=:48811 Content-Type: text/plain; charset=us-ascii Hi, all..! I got to have some questions while developing a media server. SIP (1) AS(Appication Server) ---------------- | | | SIP (2) | | Megaco (3) | Softswitch --------------------> Media Server Let's assume that a new call is set up through megaco protocol between the softswitch and the media server as picture above. There are several ways that we can proceed the service flows after a call setup. SIP 1. AS------->Media Server SIP Megaco 2. AS------->Softswitch------->Media Server According to 1, AS directly controls over the media server for the service procedure by using SIP. In the case of 2, the media server is controlled by the softswitch through Megaco for the service procedure. If we use 1, I think the media server must have some function for associating (3) call with (1) service control. [1]. Do you know any algorithm or good way to solve this problem? [2]. In addition, I have no idea how AS can control the service. (call flow) [3]. I have tried to find some documents or drafts about the ways of service control (I mean in detail), but I couldn't. Do you guys have any idea on these? Thanks and Regards. --------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! --0-1380671858-1056072217=:48811 Content-Type: text/html; charset=us-ascii
Hi, all..!
I got to have some questions while developing a media server.
 
 
                                            SIP  (1)
AS(Appication Server) ---------------- 
              |                                  |
              | SIP (2)                       |
              |           Megaco  (3)      |
       Softswitch --------------------> Media Server
 
 
 
Let's assume that a new call is set up through megaco protocol between the softswitch and the media server as picture above.
There are several ways that we can  proceed the service flows after a call setup.
 
          SIP
1. AS------->Media Server
 
          SIP                  Megaco
2. AS------->Softswitch------->Media Server
 
According to 1, AS directly controls over the media server for the service procedure by using SIP.
In the case of 2, the media server is controlled by the softswitch through Megaco for the service procedure.
 
If we use 1, I think the media server must have some function for associating (3) call with (1) service control.
 
[1]. Do you know any algorithm or good way to solve this problem?
[2]. In addition, I have no idea how AS can control the service. (call flow)
[3]. I have tried to find some documents or drafts about the ways of service control (I mean in detail), but I couldn't.
 
Do you guys have any idea on these?
 
Thanks and Regards.

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month! --0-1380671858-1056072217=:48811-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Jun 19 21:24:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28067 for ; Thu, 19 Jun 2003 21:24:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5K1O2t00869 for megaco-archive@odin.ietf.org; Thu, 19 Jun 2003 21:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TAdG-0000Dw-UM for megaco-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 21:24:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28040 for ; Thu, 19 Jun 2003 21:24:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TAax-0005K1-00 for megaco-web-archive@ietf.org; Thu, 19 Jun 2003 21:21:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TAaw-0005Jx-00 for megaco-web-archive@ietf.org; Thu, 19 Jun 2003 21:21:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TAdF-0000D9-5H; Thu, 19 Jun 2003 21:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TAcu-0000Cp-5P for megaco@optimus.ietf.org; Thu, 19 Jun 2003 21:23:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28024 for ; Thu, 19 Jun 2003 21:23:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TAaa-0005Jh-00 for megaco@ietf.org; Thu, 19 Jun 2003 21:21:16 -0400 Received: from web20712.mail.yahoo.com ([66.163.169.153]) by ietf-mx with smtp (Exim 4.12) id 19TAaa-0005Je-00 for megaco@ietf.org; Thu, 19 Jun 2003 21:21:16 -0400 Message-ID: <20030620012337.49509.qmail@web20712.mail.yahoo.com> Received: from [218.154.52.161] by web20712.mail.yahoo.com via HTTP; Thu, 19 Jun 2003 18:23:37 PDT Date: Thu, 19 Jun 2003 18:23:37 -0700 (PDT) From: Dongpyo Lee To: megaco@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1380671858-1056072217=:48811" Subject: [Megaco] Service control of a media server Sender: megaco-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: , --0-1380671858-1056072217=:48811 Content-Type: text/plain; charset=us-ascii Hi, all..! I got to have some questions while developing a media server. SIP (1) AS(Appication Server) ---------------- | | | SIP (2) | | Megaco (3) | Softswitch --------------------> Media Server Let's assume that a new call is set up through megaco protocol between the softswitch and the media server as picture above. There are several ways that we can proceed the service flows after a call setup. SIP 1. AS------->Media Server SIP Megaco 2. AS------->Softswitch------->Media Server According to 1, AS directly controls over the media server for the service procedure by using SIP. In the case of 2, the media server is controlled by the softswitch through Megaco for the service procedure. If we use 1, I think the media server must have some function for associating (3) call with (1) service control. [1]. Do you know any algorithm or good way to solve this problem? [2]. In addition, I have no idea how AS can control the service. (call flow) [3]. I have tried to find some documents or drafts about the ways of service control (I mean in detail), but I couldn't. Do you guys have any idea on these? Thanks and Regards. --------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! --0-1380671858-1056072217=:48811 Content-Type: text/html; charset=us-ascii
Hi, all..!
I got to have some questions while developing a media server.
 
 
                                            SIP  (1)
AS(Appication Server) ---------------- 
              |                                  |
              | SIP (2)                       |
              |           Megaco  (3)      |
       Softswitch --------------------> Media Server
 
 
 
Let's assume that a new call is set up through megaco protocol between the softswitch and the media server as picture above.
There are several ways that we can  proceed the service flows after a call setup.
 
          SIP
1. AS------->Media Server
 
          SIP                  Megaco
2. AS------->Softswitch------->Media Server
 
According to 1, AS directly controls over the media server for the service procedure by using SIP.
In the case of 2, the media server is controlled by the softswitch through Megaco for the service procedure.
 
If we use 1, I think the media server must have some function for associating (3) call with (1) service control.
 
[1]. Do you know any algorithm or good way to solve this problem?
[2]. In addition, I have no idea how AS can control the service. (call flow)
[3]. I have tried to find some documents or drafts about the ways of service control (I mean in detail), but I couldn't.
 
Do you guys have any idea on these?
 
Thanks and Regards.

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month! --0-1380671858-1056072217=:48811-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Jun 20 10:46:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09043 for ; Fri, 20 Jun 2003 10:46:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TN9O-0001pK-Ao; Fri, 20 Jun 2003 10:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TN97-0001ot-Df for megaco@optimus.ietf.org; Fri, 20 Jun 2003 10:45:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09003 for ; Fri, 20 Jun 2003 10:45:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TN94-0004SV-00 for megaco@ietf.org; Fri, 20 Jun 2003 10:45:42 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19TN93-0004SB-00 for megaco@ietf.org; Fri, 20 Jun 2003 10:45:41 -0400 Received: from smilevm.winphoria.com ([10.14.25.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 20 Jun 2003 10:45:09 -0400 Message-Id: <5.2.1.1.0.20030620102508.02de9e50@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 20 Jun 2003 10:43:36 -0400 To: Christian Groves , megaco@ietf.org From: Aleksandr Ryabin Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Cc: Kevin Boyle , micael.karlberg@ericsson.com In-Reply-To: <3EF11E66.5BB454EB@ericsson.com.au> References: <5.2.1.1.0.20030617201948.02d0c8a0@imap.winphoria.com> <5.2.1.1.0.20030618091318.02d8bb08@imap.winphoria.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 20 Jun 2003 14:45:10.0057 (UTC) FILETIME=[8C745190:01C3373A] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA09043 Hi Christian, I'm not sure on your usage of "whole" and "individual". They are complimentary: each SDP is "individual" and it is a "whole". I said "whole" SDP, not "whole" MediaDescriptor. What I'm trying to understand is: How can MGC do an audit to get *only* whole local (or remote) SDP and nothing else? My understanding current ABNF syntax does not allow it. Do we agree on this? If yes, is it useful to have such a functionality? I think yes. Do we agree on this? If yes, does my proposal below solves the request? I think yes. Do we agree on this? If yes, how do we go about adding it into IG/or next version? Opinions? Thanks Aleks At 10:22 PM 6/18/2003, Christian Groves wrote: >Hello Aleksandr, > >You said "whole" local or remote descriptor MediaToken allows that. It >does not >allow "individual" local and remote descriptors. > >Regards, Christian > >Aleksandr Ryabin wrote: > > > > Hi Christian, > > > > Could you please clarify on how would MGC audit individual local, or > > remote SDP with v1? I mean, local and remote SDPs are part of > > larger MediaDescriptor and the ABNF construction of auditItem > > only allows auditing the whole MediaDescriptor, not parts of it: > > > > ;at-most-once, and DigitMapToken and PackagesToken are not allowed > > ;in AuditCapabilities command > > auditItem = ( MuxToken / ModemToken / MediaToken / > > SignalsToken / EventBufferToken / > > DigitMapToken / StatsToken / EventsToken / > > ObservedEventsToken / PackagesToken ) > > > > So, if I understand it correctly, MGC can only audit the whole > > MediaDescriptor, not individual local, or remote SDP. > > > > Regards, > > Aleks > > > > At 11:59 PM 6/17/2003, Christian Groves wrote: > > >Hello Aleksandr, > > > > > >Megaco does allow you to audit a whole local or remote descriptor. > This is the > > >audit capability v1. Individual auditing was added in v2. We didn't add > > >individual audit of a whole descriptor as this would duplicate > functionality. > > > > > >It was decided not to allow auditing of individual segments of local and > > >remote > > >SDP (text encoding) because no body could come up with an appropriate > > >method to > > >do this and didn't know what the reply looked like. For the binary > encoding it > > >was very easy because all parameters follow a tag length value > structure. You > > >request the tag and you get back the value. > > > > > >Christian > > > > > >Aleksandr Ryabin wrote: > > > > > > > > Hi, > > > > > > > > While we are on topic. The following does not allow auditing for > the whole > > > > local or remote SDP in ABNF: > > > > ; at-most-once > > > > indAudstreamParm = ( indAudlocalControlDescriptor ) > > > > ; SDP too complex to pull out individual pieces for audit, > > > > ; hence no individual audit for Local and Remote > > > > > > > > The question is why? I mean why does not it allow to audit *whole* > > > > local or remote SDP? E.g.: > > > > indAudstreamParm = ( indAudlocalControlDescriptor / > LocalToken / > > > > RemoteToken) > > > > > > > > BTW ASN.1 does allow that, as well as individual pieces of SDPs. > > > > > > > > Thanks > > > > Aleks > > > > > > > > PS. Small nit in indAudauditReturnParameter (two slashes at the end): > > > > indAudauditReturnParameter = (indAudmediaDescriptor / / > > > > > > > > At 03:30 PM 6/17/2003, Kevin Boyle wrote: > > > > >Aha... I see the problem now. In binary, you can request info about > > > several > > > > >streams at once, but you may only request info about one stream in > > > text. Is > > > > >this an accurate summary? > > > > > > > > > >Seeing as this would be a syntax change, we need to know if anyone > would > > > > >have major heartburn over changing the syntax to fix this. If > not, I will > > > > >draft up an IG item to fix this... > > > > > > > > > >Speaking personally, I think this is a beneficial change, because > it makes > > > > >the syntax align between the expression of items within the media > > > > >descriptor, and the audit of items within the media descriptor, as > well as > > > > >making both binary and text align in capability. > > > > > > > > > >Any other comments? > > > > > > > > > >Kevin > > > > > > > > > >-----Original Message----- > > > > >From: Micael Karlberg [mailto:micael.karlberg@ericsson.com] > > > > >Sent: Tuesday, June 17, 2003 1:26 PM > > > > >To: Christian Groves > > > > >Cc: megaco@ietf.org > > > > >Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? > > > > > > > > > > > > > > >Hello Christian, > > > > > > > > > >Christian Groves writes: > > > > > > Hello Micael, > > > > > > > > > > > > I don't understand what the problem is nor the comments in the > > > ASN.1 you > > > > >are > referring to? > > > > > > > > > >The comment ("at-most-once per item...") is in the ABNF. > > > > > > > > > > > If you are referring to the ::= SEQUENCE this is actually an > ASN.1 > > > > > >construct that says that a sequence of information elements may be > > > encoded, > > > > >in > this case "termStateDescr" & a choice of streams. > > > > > > > > > >This is how see it also. > > > > > > > > > > > This same information is represented by the ABNF. > > > > > > > > > >This I _cannot_ find! > > > > > > > > > >The comment in the ABNF seems to indicate that it should be as in > > > > >the ASN.1 but the ABNF definition of the indAudmediaDescriptor > > > > >allow for only one value of indAudmediaParm. > > > > > > > > > >Therefor my _question_ if the definition should'nt really be: > > > > > > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > > > > *(COMMA indAudmediaParm) RBRKT > > > > > > > > > >Also, the defintion of the mediaDescriptor strikes me as _very_ > similar to > > > > >my "proposal": > > > > > > > > > > mediaDescriptor = MediaToken LBRKT mediaParm > > > > > *(COMMA mediaParm) RBRKT > > > > > > > > > > ; at-most one terminationStateDescriptor > > > > > ; and either streamParm(s) or streamDescriptor(s) but not both > > > > > mediaParm = (streamParm / streamDescriptor / > > > > > terminationStateDescriptor) > > > > > > > > > >Regards, > > > > > /BMK > > > > > > > > > > > > > > > > > Regards, Christian > > > > > > > > > > > > Micael Karlberg wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a > > > mismatch > > > > > > >between the ABNF and the ASN.1 regarding > indAudmediaDescriptor. > > My > > > > >question is: Should the definition of ABNF indAudmediaDescriptor > > > > > really > > > > >be: > > > > > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > > > > > > *(COMMA indAudmediaParm) RBRKT > > > > > > > > > > > > > > The comment for indAudmediaParm and the ASN.1 > > > IndAudMediaDescriptor > > > > > > > indicates that it should be a list. Or am I missing something? > > > > > > > > > Also, see definition of mediaDescriptor! > > > > > > > > > > > > > > ABNF: > > > > > > > ---- > > > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > > RBRKT > > > > > > > > > > > > > > ; at-most-once per item > > > > > > > ; and either streamParm or streamDescriptor but not both > > > > > > > indAudmediaParm = (indAudstreamParm / > indAudstreamDescriptor / > > > > > > > indAudterminationStateDescriptor) > > > > > > > > > > > > > > ASN.1: > > > > > > > ----- > > > > > > > IndAudMediaDescriptor ::= SEQUENCE > > > > > > > { > > > > > > > > > > > > > > termStateDescr IndAudTerminationStateDescriptor > > > OPTIONAL, > > > > > > > streams CHOICE > > > > > > > { > > > > > > > oneStream IndAudStreamParms, > > > > > > > multiStream SEQUENCE OF > IndAudStreamDescriptor > > > > > > > } OPTIONAL, > > > > > > > ... > > > > > > > } > > > > > > > > > > > > > > Regards, > > > > > > > /BMK > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Megaco mailing list > > > > > > > Megaco@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > > > > > >-- > > > > >Micael Karlberg Ericsson AB, Älvsjö Sweden > > > > >Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development > > > > >ECN: 851 5668 Mail: micael.karlberg@ericsson.com > > > > >Fax: +46 8 727 5775 > > > > > > > > > >_______________________________________________ > > > > >Megaco mailing list > > > > >Megaco@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/megaco > > > > > > > > > >_______________________________________________ > > > > >Megaco mailing list > > > > >Megaco@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Jun 20 10:46:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09058 for ; Fri, 20 Jun 2003 10:46:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KEk4f07106 for megaco-archive@odin.ietf.org; Fri, 20 Jun 2003 10:46:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TN9Q-0001qX-No for megaco-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 10:46:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09014 for ; Fri, 20 Jun 2003 10:46:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TN9O-0004Sh-00 for megaco-web-archive@ietf.org; Fri, 20 Jun 2003 10:46:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TN9N-0004Se-00 for megaco-web-archive@ietf.org; Fri, 20 Jun 2003 10:46:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TN9O-0001pK-Ao; Fri, 20 Jun 2003 10:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TN97-0001ot-Df for megaco@optimus.ietf.org; Fri, 20 Jun 2003 10:45:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09003 for ; Fri, 20 Jun 2003 10:45:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TN94-0004SV-00 for megaco@ietf.org; Fri, 20 Jun 2003 10:45:42 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19TN93-0004SB-00 for megaco@ietf.org; Fri, 20 Jun 2003 10:45:41 -0400 Received: from smilevm.winphoria.com ([10.14.25.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 20 Jun 2003 10:45:09 -0400 Message-Id: <5.2.1.1.0.20030620102508.02de9e50@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 20 Jun 2003 10:43:36 -0400 To: Christian Groves , megaco@ietf.org From: Aleksandr Ryabin Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Cc: Kevin Boyle , micael.karlberg@ericsson.com In-Reply-To: <3EF11E66.5BB454EB@ericsson.com.au> References: <5.2.1.1.0.20030617201948.02d0c8a0@imap.winphoria.com> <5.2.1.1.0.20030618091318.02d8bb08@imap.winphoria.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 20 Jun 2003 14:45:10.0057 (UTC) FILETIME=[8C745190:01C3373A] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA09058 Hi Christian, I'm not sure on your usage of "whole" and "individual". They are complimentary: each SDP is "individual" and it is a "whole". I said "whole" SDP, not "whole" MediaDescriptor. What I'm trying to understand is: How can MGC do an audit to get *only* whole local (or remote) SDP and nothing else? My understanding current ABNF syntax does not allow it. Do we agree on this? If yes, is it useful to have such a functionality? I think yes. Do we agree on this? If yes, does my proposal below solves the request? I think yes. Do we agree on this? If yes, how do we go about adding it into IG/or next version? Opinions? Thanks Aleks At 10:22 PM 6/18/2003, Christian Groves wrote: >Hello Aleksandr, > >You said "whole" local or remote descriptor MediaToken allows that. It >does not >allow "individual" local and remote descriptors. > >Regards, Christian > >Aleksandr Ryabin wrote: > > > > Hi Christian, > > > > Could you please clarify on how would MGC audit individual local, or > > remote SDP with v1? I mean, local and remote SDPs are part of > > larger MediaDescriptor and the ABNF construction of auditItem > > only allows auditing the whole MediaDescriptor, not parts of it: > > > > ;at-most-once, and DigitMapToken and PackagesToken are not allowed > > ;in AuditCapabilities command > > auditItem = ( MuxToken / ModemToken / MediaToken / > > SignalsToken / EventBufferToken / > > DigitMapToken / StatsToken / EventsToken / > > ObservedEventsToken / PackagesToken ) > > > > So, if I understand it correctly, MGC can only audit the whole > > MediaDescriptor, not individual local, or remote SDP. > > > > Regards, > > Aleks > > > > At 11:59 PM 6/17/2003, Christian Groves wrote: > > >Hello Aleksandr, > > > > > >Megaco does allow you to audit a whole local or remote descriptor. > This is the > > >audit capability v1. Individual auditing was added in v2. We didn't add > > >individual audit of a whole descriptor as this would duplicate > functionality. > > > > > >It was decided not to allow auditing of individual segments of local and > > >remote > > >SDP (text encoding) because no body could come up with an appropriate > > >method to > > >do this and didn't know what the reply looked like. For the binary > encoding it > > >was very easy because all parameters follow a tag length value > structure. You > > >request the tag and you get back the value. > > > > > >Christian > > > > > >Aleksandr Ryabin wrote: > > > > > > > > Hi, > > > > > > > > While we are on topic. The following does not allow auditing for > the whole > > > > local or remote SDP in ABNF: > > > > ; at-most-once > > > > indAudstreamParm = ( indAudlocalControlDescriptor ) > > > > ; SDP too complex to pull out individual pieces for audit, > > > > ; hence no individual audit for Local and Remote > > > > > > > > The question is why? I mean why does not it allow to audit *whole* > > > > local or remote SDP? E.g.: > > > > indAudstreamParm = ( indAudlocalControlDescriptor / > LocalToken / > > > > RemoteToken) > > > > > > > > BTW ASN.1 does allow that, as well as individual pieces of SDPs. > > > > > > > > Thanks > > > > Aleks > > > > > > > > PS. Small nit in indAudauditReturnParameter (two slashes at the end): > > > > indAudauditReturnParameter = (indAudmediaDescriptor / / > > > > > > > > At 03:30 PM 6/17/2003, Kevin Boyle wrote: > > > > >Aha... I see the problem now. In binary, you can request info about > > > several > > > > >streams at once, but you may only request info about one stream in > > > text. Is > > > > >this an accurate summary? > > > > > > > > > >Seeing as this would be a syntax change, we need to know if anyone > would > > > > >have major heartburn over changing the syntax to fix this. If > not, I will > > > > >draft up an IG item to fix this... > > > > > > > > > >Speaking personally, I think this is a beneficial change, because > it makes > > > > >the syntax align between the expression of items within the media > > > > >descriptor, and the audit of items within the media descriptor, as > well as > > > > >making both binary and text align in capability. > > > > > > > > > >Any other comments? > > > > > > > > > >Kevin > > > > > > > > > >-----Original Message----- > > > > >From: Micael Karlberg [mailto:micael.karlberg@ericsson.com] > > > > >Sent: Tuesday, June 17, 2003 1:26 PM > > > > >To: Christian Groves > > > > >Cc: megaco@ietf.org > > > > >Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? > > > > > > > > > > > > > > >Hello Christian, > > > > > > > > > >Christian Groves writes: > > > > > > Hello Micael, > > > > > > > > > > > > I don't understand what the problem is nor the comments in the > > > ASN.1 you > > > > >are > referring to? > > > > > > > > > >The comment ("at-most-once per item...") is in the ABNF. > > > > > > > > > > > If you are referring to the ::= SEQUENCE this is actually an > ASN.1 > > > > > >construct that says that a sequence of information elements may be > > > encoded, > > > > >in > this case "termStateDescr" & a choice of streams. > > > > > > > > > >This is how see it also. > > > > > > > > > > > This same information is represented by the ABNF. > > > > > > > > > >This I _cannot_ find! > > > > > > > > > >The comment in the ABNF seems to indicate that it should be as in > > > > >the ASN.1 but the ABNF definition of the indAudmediaDescriptor > > > > >allow for only one value of indAudmediaParm. > > > > > > > > > >Therefor my _question_ if the definition should'nt really be: > > > > > > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > > > > *(COMMA indAudmediaParm) RBRKT > > > > > > > > > >Also, the defintion of the mediaDescriptor strikes me as _very_ > similar to > > > > >my "proposal": > > > > > > > > > > mediaDescriptor = MediaToken LBRKT mediaParm > > > > > *(COMMA mediaParm) RBRKT > > > > > > > > > > ; at-most one terminationStateDescriptor > > > > > ; and either streamParm(s) or streamDescriptor(s) but not both > > > > > mediaParm = (streamParm / streamDescriptor / > > > > > terminationStateDescriptor) > > > > > > > > > >Regards, > > > > > /BMK > > > > > > > > > > > > > > > > > Regards, Christian > > > > > > > > > > > > Micael Karlberg wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a > > > mismatch > > > > > > >between the ABNF and the ASN.1 regarding > indAudmediaDescriptor. > > My > > > > >question is: Should the definition of ABNF indAudmediaDescriptor > > > > > really > > > > >be: > > > > > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > > > > > > *(COMMA indAudmediaParm) RBRKT > > > > > > > > > > > > > > The comment for indAudmediaParm and the ASN.1 > > > IndAudMediaDescriptor > > > > > > > indicates that it should be a list. Or am I missing something? > > > > > > > > > Also, see definition of mediaDescriptor! > > > > > > > > > > > > > > ABNF: > > > > > > > ---- > > > > > > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm > > > RBRKT > > > > > > > > > > > > > > ; at-most-once per item > > > > > > > ; and either streamParm or streamDescriptor but not both > > > > > > > indAudmediaParm = (indAudstreamParm / > indAudstreamDescriptor / > > > > > > > indAudterminationStateDescriptor) > > > > > > > > > > > > > > ASN.1: > > > > > > > ----- > > > > > > > IndAudMediaDescriptor ::= SEQUENCE > > > > > > > { > > > > > > > > > > > > > > termStateDescr IndAudTerminationStateDescriptor > > > OPTIONAL, > > > > > > > streams CHOICE > > > > > > > { > > > > > > > oneStream IndAudStreamParms, > > > > > > > multiStream SEQUENCE OF > IndAudStreamDescriptor > > > > > > > } OPTIONAL, > > > > > > > ... > > > > > > > } > > > > > > > > > > > > > > Regards, > > > > > > > /BMK > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Megaco mailing list > > > > > > > Megaco@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > > > > > >-- > > > > >Micael Karlberg Ericsson AB, Älvsjö Sweden > > > > >Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development > > > > >ECN: 851 5668 Mail: micael.karlberg@ericsson.com > > > > >Fax: +46 8 727 5775 > > > > > > > > > >_______________________________________________ > > > > >Megaco mailing list > > > > >Megaco@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/megaco > > > > > > > > > >_______________________________________________ > > > > >Megaco mailing list > > > > >Megaco@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Jun 20 10:57:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10633 for ; Fri, 20 Jun 2003 10:57:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TNK2-0003Dt-Bv; Fri, 20 Jun 2003 10:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TNJq-0003BO-Cf for megaco@optimus.ietf.org; Fri, 20 Jun 2003 10:56:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10432 for ; Fri, 20 Jun 2003 10:56:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TNJn-0004yt-00 for megaco@ietf.org; Fri, 20 Jun 2003 10:56:47 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19TNJm-0004vl-00 for megaco@ietf.org; Fri, 20 Jun 2003 10:56:47 -0400 Received: from smilevm.winphoria.com ([10.14.25.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 20 Jun 2003 10:56:14 -0400 Message-Id: <5.2.1.1.0.20030620104441.02cefea8@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 20 Jun 2003 10:53:51 -0400 To: Christian Groves , megaco@ietf.org From: Aleksandr Ryabin Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Cc: Kevin Boyle , micael.karlberg@ericsson.com In-Reply-To: <3EF12560.9D077C6D@ericsson.com.au> References: <5.2.1.1.0.20030618092037.02dc0310@imap.winphoria.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Jun 2003 14:56:15.0078 (UTC) FILETIME=[18D67860:01C3373C] Sender: megaco-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 Christian, Please see my comments below inline [AR]. Regards, Aleks At 10:52 PM 6/18/2003, Christian Groves wrote: >G'Day Aleksandr, > >Functionality wise the text and binary version I see as equivalent as you can >ask for a list of parameters to be audited. How syntically this is acheived is >has a difference. I don't think its necessary to change the ASN.1 as its not >broken and would break v2 implementations. If people want to change the ABNF >with *(COMMA mediaParm) then OK. We should also clarify that if you want >multiple items from the same descriptor use *(COMMA ...), if you want multiple >items in different descriptors use indAudauditReturnParameter or >IndAuditParameter. You still need the simple way for multiple descriptors. [AR] That is exactly what "at-most-once per item" qualifier will do. >The question which you alluded to below is this an acceptable "Fix" (not break >implementations) or should it wait for a version change to align? > >Depending on the answer to the above perhaps this could be captured in the >implementors' guide as a new section detailing the issue and saying solution >will be in v3. I believe we identified another issue at the May SG16 that we >agreed would be something to look at in v3. [AR] Generally speaking it is too big of a change, thus it should wait until next version, but depending on number of current implementations of v2 out there it might as well be added to current v2 in IG. [AR] I'm not currently aware of any v2 implementations, thus it should be easy to go with v2/IG approach. Opinions? >As for go "flexible" or "simple" on either of the encodings there was no >conscious decision. I simply tried to mirror existing data structures when I >proposed the syntax in both the ASN1 and ABNF. That's why the ASN.1 has >sequences because it mirrors previous related v1 structures. I tried to do the >same for the ABNF but we had some last minute editing (re: local/remote >comment) >and some things were changed. That's why things are as they are. > >Regards, Christian > >Aleksandr Ryabin wrote: > > > > Hi Christian, > > > > I think that Michael originally pointed out on discrepancy between > > ASN.1 and ABNF. Specifically, IndAudMediaDescriptor contains > > multiStream which is defined as a SEQUENCE: > > multiStream SEQUENCE OF IndAudStreamDescriptor > > > > Thus inside of one IndAudMediaDescriptor construction MGC can > > place multiple audit instructions for different streams, while > > ABNF does not allow that. > > > > You are right, there is a way to do it, but ABNF does not match > > ASN.1 in this case on how to do it. In this case ASN.1 allows two > > ways to do the same thing, while ABNF only one way. > > > > Generally speaking my personal opinion that we should minimize cases > > when MGC can do same things different ways and instead fix ASN.1 > > spec to not allow SEQUENCE (but see more below), e.g.: > > multiStream IndAudStreamDescriptor > > > > Same problem for propertyParms in IndAudLocalControlDescriptor and > > in IndAudTerminationStateDescriptor (SEQUENCE OF should be removed). > > But if we are to fix this then we should fix the rest if ASN.1 indAudXXX > > constructions to not allow multiple audits inside of one construction > and that > > means turning SEQENCE into CHOICE for most of IndAudXXX constructions. > > > > So the way I see it, ASN.1 went the "flexible" way which can be complex, > > but and minimizes the final size of audit when several items needs to > > be audited inside of one descriptor, while ABNF went "simple" way > > which makes it strait forward, but it can get big if MGC need to audit > > more then one item inside of one descriptor. > > > > I think we should let it be since it is too much of the changes and add > > flexibility of ASN.1 into ABNF in the next version which includes > > adding (COMMA...) in most of indAudXXX constructions in ABNF. > > At that point we should qualify with "at-most-once per item" > > indAudauditReturnParameter in ABNF and IndAuditParameter in > > ASN.1 do disallow "old simple" way. > > > > Regards, > > Aleks [snip] _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Jun 20 10:57:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10647 for ; Fri, 20 Jun 2003 10:57:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KEv6112472 for megaco-archive@odin.ietf.org; Fri, 20 Jun 2003 10:57:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TNK6-0003F4-6b for megaco-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 10:57:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10485 for ; Fri, 20 Jun 2003 10:57:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TNK3-00050Q-00 for megaco-web-archive@ietf.org; Fri, 20 Jun 2003 10:57:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TNK3-00050N-00 for megaco-web-archive@ietf.org; Fri, 20 Jun 2003 10:57:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TNK2-0003Dt-Bv; Fri, 20 Jun 2003 10:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TNJq-0003BO-Cf for megaco@optimus.ietf.org; Fri, 20 Jun 2003 10:56:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10432 for ; Fri, 20 Jun 2003 10:56:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TNJn-0004yt-00 for megaco@ietf.org; Fri, 20 Jun 2003 10:56:47 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19TNJm-0004vl-00 for megaco@ietf.org; Fri, 20 Jun 2003 10:56:47 -0400 Received: from smilevm.winphoria.com ([10.14.25.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 20 Jun 2003 10:56:14 -0400 Message-Id: <5.2.1.1.0.20030620104441.02cefea8@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 20 Jun 2003 10:53:51 -0400 To: Christian Groves , megaco@ietf.org From: Aleksandr Ryabin Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? Cc: Kevin Boyle , micael.karlberg@ericsson.com In-Reply-To: <3EF12560.9D077C6D@ericsson.com.au> References: <5.2.1.1.0.20030618092037.02dc0310@imap.winphoria.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Jun 2003 14:56:15.0078 (UTC) FILETIME=[18D67860:01C3373C] Sender: megaco-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 Christian, Please see my comments below inline [AR]. Regards, Aleks At 10:52 PM 6/18/2003, Christian Groves wrote: >G'Day Aleksandr, > >Functionality wise the text and binary version I see as equivalent as you can >ask for a list of parameters to be audited. How syntically this is acheived is >has a difference. I don't think its necessary to change the ASN.1 as its not >broken and would break v2 implementations. If people want to change the ABNF >with *(COMMA mediaParm) then OK. We should also clarify that if you want >multiple items from the same descriptor use *(COMMA ...), if you want multiple >items in different descriptors use indAudauditReturnParameter or >IndAuditParameter. You still need the simple way for multiple descriptors. [AR] That is exactly what "at-most-once per item" qualifier will do. >The question which you alluded to below is this an acceptable "Fix" (not break >implementations) or should it wait for a version change to align? > >Depending on the answer to the above perhaps this could be captured in the >implementors' guide as a new section detailing the issue and saying solution >will be in v3. I believe we identified another issue at the May SG16 that we >agreed would be something to look at in v3. [AR] Generally speaking it is too big of a change, thus it should wait until next version, but depending on number of current implementations of v2 out there it might as well be added to current v2 in IG. [AR] I'm not currently aware of any v2 implementations, thus it should be easy to go with v2/IG approach. Opinions? >As for go "flexible" or "simple" on either of the encodings there was no >conscious decision. I simply tried to mirror existing data structures when I >proposed the syntax in both the ASN1 and ABNF. That's why the ASN.1 has >sequences because it mirrors previous related v1 structures. I tried to do the >same for the ABNF but we had some last minute editing (re: local/remote >comment) >and some things were changed. That's why things are as they are. > >Regards, Christian > >Aleksandr Ryabin wrote: > > > > Hi Christian, > > > > I think that Michael originally pointed out on discrepancy between > > ASN.1 and ABNF. Specifically, IndAudMediaDescriptor contains > > multiStream which is defined as a SEQUENCE: > > multiStream SEQUENCE OF IndAudStreamDescriptor > > > > Thus inside of one IndAudMediaDescriptor construction MGC can > > place multiple audit instructions for different streams, while > > ABNF does not allow that. > > > > You are right, there is a way to do it, but ABNF does not match > > ASN.1 in this case on how to do it. In this case ASN.1 allows two > > ways to do the same thing, while ABNF only one way. > > > > Generally speaking my personal opinion that we should minimize cases > > when MGC can do same things different ways and instead fix ASN.1 > > spec to not allow SEQUENCE (but see more below), e.g.: > > multiStream IndAudStreamDescriptor > > > > Same problem for propertyParms in IndAudLocalControlDescriptor and > > in IndAudTerminationStateDescriptor (SEQUENCE OF should be removed). > > But if we are to fix this then we should fix the rest if ASN.1 indAudXXX > > constructions to not allow multiple audits inside of one construction > and that > > means turning SEQENCE into CHOICE for most of IndAudXXX constructions. > > > > So the way I see it, ASN.1 went the "flexible" way which can be complex, > > but and minimizes the final size of audit when several items needs to > > be audited inside of one descriptor, while ABNF went "simple" way > > which makes it strait forward, but it can get big if MGC need to audit > > more then one item inside of one descriptor. > > > > I think we should let it be since it is too much of the changes and add > > flexibility of ASN.1 into ABNF in the next version which includes > > adding (COMMA...) in most of indAudXXX constructions in ABNF. > > At that point we should qualify with "at-most-once per item" > > indAudauditReturnParameter in ABNF and IndAuditParameter in > > ASN.1 do disallow "old simple" way. > > > > Regards, > > Aleks [snip] _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Jun 20 13:18:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17976 for ; Fri, 20 Jun 2003 13:18:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TPWT-0004oX-QA; Fri, 20 Jun 2003 13:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TPVl-0004oE-7p for megaco@optimus.ietf.org; Fri, 20 Jun 2003 13:17:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17956 for ; Fri, 20 Jun 2003 13:17:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TPVj-0006ms-00 for megaco@ietf.org; Fri, 20 Jun 2003 13:17:15 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 19TPVh-0006mW-00 for megaco@ietf.org; Fri, 20 Jun 2003 13:17:14 -0400 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 h5KHGaw18069 for ; Fri, 20 Jun 2003 13:16:37 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jun 2003 13:16:38 -0400 Message-ID: From: "Kevin Boyle" To: Venkata Narasimha Murthy Nanduri , megaco@ietf.org Subject: RE: [Megaco] Max # signals in a Sequential signal list Date: Fri, 20 Jun 2003 13:16:36 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Comments inline. [KJBII] Kevin -----Original Message----- From: Venkata Narasimha Murthy Nanduri [mailto:vnanduri@cisco.com] Sent: Thursday, June 19, 2003 8:00 PM To: megaco@ietf.org Subject: [Megaco] Max # signals in a Sequential signal list Hi, What can be the maximum number of signals in a Sequential signal list? [KJBII] The protocol does not put any limit on the number of signals in a SignalList. If RFC does not mention about the maximum number of signals in a list, Can MG restrict the Maximum number of signals that it can handle in a list? [KJBII] If an MG cannot execute a given command for any reason, it should return an Error Descriptor. This would include receiving a SignalList that is too large for the MG to handle. In practical scenarios, what will be the number of signals in a Sequential signal list? [KJBII] That would depend entirely upon what applications are supported by the MGC and MG. Thanks Venkata Venkata Nanduri [] Software Engineer Voice Gateway and Dial BU 3850 Zanker Road, Building 1 San jose - 95134 USA Tel: 408 853 8235 Fax: 408 525 0640 e-mail: vnanduri@cisco.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 Fri Jun 20 13:18:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17994 for ; Fri, 20 Jun 2003 13:18:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KHI4o18553 for megaco-archive@odin.ietf.org; Fri, 20 Jun 2003 13:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TPWW-0004pA-Q1 for megaco-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 13:18:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17964 for ; Fri, 20 Jun 2003 13:18:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TPWU-0006n2-00 for megaco-web-archive@ietf.org; Fri, 20 Jun 2003 13:18:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TPWU-0006my-00 for megaco-web-archive@ietf.org; Fri, 20 Jun 2003 13:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TPWT-0004oX-QA; Fri, 20 Jun 2003 13:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TPVl-0004oE-7p for megaco@optimus.ietf.org; Fri, 20 Jun 2003 13:17:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17956 for ; Fri, 20 Jun 2003 13:17:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TPVj-0006ms-00 for megaco@ietf.org; Fri, 20 Jun 2003 13:17:15 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 19TPVh-0006mW-00 for megaco@ietf.org; Fri, 20 Jun 2003 13:17:14 -0400 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 h5KHGaw18069 for ; Fri, 20 Jun 2003 13:16:37 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jun 2003 13:16:38 -0400 Message-ID: From: "Kevin Boyle" To: Venkata Narasimha Murthy Nanduri , megaco@ietf.org Subject: RE: [Megaco] Max # signals in a Sequential signal list Date: Fri, 20 Jun 2003 13:16:36 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Comments inline. [KJBII] Kevin -----Original Message----- From: Venkata Narasimha Murthy Nanduri [mailto:vnanduri@cisco.com] Sent: Thursday, June 19, 2003 8:00 PM To: megaco@ietf.org Subject: [Megaco] Max # signals in a Sequential signal list Hi, What can be the maximum number of signals in a Sequential signal list? [KJBII] The protocol does not put any limit on the number of signals in a SignalList. If RFC does not mention about the maximum number of signals in a list, Can MG restrict the Maximum number of signals that it can handle in a list? [KJBII] If an MG cannot execute a given command for any reason, it should return an Error Descriptor. This would include receiving a SignalList that is too large for the MG to handle. In practical scenarios, what will be the number of signals in a Sequential signal list? [KJBII] That would depend entirely upon what applications are supported by the MGC and MG. Thanks Venkata Venkata Nanduri [] Software Engineer Voice Gateway and Dial BU 3850 Zanker Road, Building 1 San jose - 95134 USA Tel: 408 853 8235 Fax: 408 525 0640 e-mail: vnanduri@cisco.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 Fri Jun 20 14:33:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24740 for ; Fri, 20 Jun 2003 14:33:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQh2-0002iv-Rw; Fri, 20 Jun 2003 14:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQgT-0002ea-He for megaco@optimus.ietf.org; Fri, 20 Jun 2003 14:32:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24558 for ; Fri, 20 Jun 2003 14:32:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TQgQ-00008B-00 for megaco@ietf.org; Fri, 20 Jun 2003 14:32:22 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19TQgQ-00007S-00 for megaco@ietf.org; Fri, 20 Jun 2003 14:32:22 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 20 Jun 2003 11:33:41 -0800 Received: from VNANDURI-W2K.cisco.com (dhcp-171-71-9-175.cisco.com [171.71.9.175]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5KIVlRN000244; Fri, 20 Jun 2003 11:31:47 -0700 (PDT) Message-Id: <4.3.2.7.2.20030620112752.00b8e200@mira-sjc5-6.cisco.com> X-Sender: vnanduri@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Jun 2003 11:31:46 -0700 To: "Kevin Boyle" From: Venkata Narasimha Murthy Nanduri Subject: RE: [Megaco] Max # signals in a Sequential signal list Cc: Venkata Narasimha Murthy Nanduri , megaco@ietf.org In-Reply-To: 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: , Hi Kevin, Thanks for your response. Please see inline..[VN] At 01:16 PM 6/20/2003 -0400, Kevin Boyle wrote: >Comments inline. [KJBII] > >Kevin > >-----Original Message----- >From: Venkata Narasimha Murthy Nanduri [mailto:vnanduri@cisco.com] >Sent: Thursday, June 19, 2003 8:00 PM >To: megaco@ietf.org >Subject: [Megaco] Max # signals in a Sequential signal list > > >Hi, > >What can be the maximum number of signals in a Sequential signal list? >[KJBII] The protocol does not put any limit on the number of signals in a >SignalList. > >If RFC does not mention about the maximum number of signals in a list, Can >MG restrict the Maximum number of signals that it can handle in a list? >[KJBII] If an MG cannot execute a given command for any reason, it should >return an Error Descriptor. This would include receiving a SignalList that >is too large for the MG to handle. [VN] Does the standard has a error code defined for this purpose? If so, can you please point me to that? >In practical scenarios, what will be the number of signals in a Sequential >signal list? >[KJBII] That would depend entirely upon what applications are supported by >the MGC and MG. [VN] Can you please give some examples of applications and how the Sequential signal will be used in each case. That will really help me understand the way Sequential signal lists will be used in different applications. Thank you very much Venkata >Thanks >Venkata > >Venkata Nanduri >[] > >Software Engineer >Voice Gateway and Dial BU >3850 Zanker Road, >Building 1 >San jose - 95134 >USA > >Tel: 408 853 8235 >Fax: 408 525 0640 >e-mail: vnanduri@cisco.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 Venkata Nanduri [] Software Engineer Voice Gateway and Dial BU 3850 Zanker Road, Building 1 San jose - 95134 USA Tel: 408 853 8235 Fax: 408 525 0640 e-mail: vnanduri@cisco.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Jun 20 14:33:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24757 for ; Fri, 20 Jun 2003 14:33:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KIX3R10574 for megaco-archive@odin.ietf.org; Fri, 20 Jun 2003 14:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQh5-0002kT-3N for megaco-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 14:33:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24668 for ; Fri, 20 Jun 2003 14:33:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TQh2-000093-00 for megaco-web-archive@ietf.org; Fri, 20 Jun 2003 14:33:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TQh1-00008y-00 for megaco-web-archive@ietf.org; Fri, 20 Jun 2003 14:32:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQh2-0002iv-Rw; Fri, 20 Jun 2003 14:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQgT-0002ea-He for megaco@optimus.ietf.org; Fri, 20 Jun 2003 14:32:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24558 for ; Fri, 20 Jun 2003 14:32:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TQgQ-00008B-00 for megaco@ietf.org; Fri, 20 Jun 2003 14:32:22 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19TQgQ-00007S-00 for megaco@ietf.org; Fri, 20 Jun 2003 14:32:22 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 20 Jun 2003 11:33:41 -0800 Received: from VNANDURI-W2K.cisco.com (dhcp-171-71-9-175.cisco.com [171.71.9.175]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5KIVlRN000244; Fri, 20 Jun 2003 11:31:47 -0700 (PDT) Message-Id: <4.3.2.7.2.20030620112752.00b8e200@mira-sjc5-6.cisco.com> X-Sender: vnanduri@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Jun 2003 11:31:46 -0700 To: "Kevin Boyle" From: Venkata Narasimha Murthy Nanduri Subject: RE: [Megaco] Max # signals in a Sequential signal list Cc: Venkata Narasimha Murthy Nanduri , megaco@ietf.org In-Reply-To: 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: , Hi Kevin, Thanks for your response. Please see inline..[VN] At 01:16 PM 6/20/2003 -0400, Kevin Boyle wrote: >Comments inline. [KJBII] > >Kevin > >-----Original Message----- >From: Venkata Narasimha Murthy Nanduri [mailto:vnanduri@cisco.com] >Sent: Thursday, June 19, 2003 8:00 PM >To: megaco@ietf.org >Subject: [Megaco] Max # signals in a Sequential signal list > > >Hi, > >What can be the maximum number of signals in a Sequential signal list? >[KJBII] The protocol does not put any limit on the number of signals in a >SignalList. > >If RFC does not mention about the maximum number of signals in a list, Can >MG restrict the Maximum number of signals that it can handle in a list? >[KJBII] If an MG cannot execute a given command for any reason, it should >return an Error Descriptor. This would include receiving a SignalList that >is too large for the MG to handle. [VN] Does the standard has a error code defined for this purpose? If so, can you please point me to that? >In practical scenarios, what will be the number of signals in a Sequential >signal list? >[KJBII] That would depend entirely upon what applications are supported by >the MGC and MG. [VN] Can you please give some examples of applications and how the Sequential signal will be used in each case. That will really help me understand the way Sequential signal lists will be used in different applications. Thank you very much Venkata >Thanks >Venkata > >Venkata Nanduri >[] > >Software Engineer >Voice Gateway and Dial BU >3850 Zanker Road, >Building 1 >San jose - 95134 >USA > >Tel: 408 853 8235 >Fax: 408 525 0640 >e-mail: vnanduri@cisco.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 Venkata Nanduri [] Software Engineer Voice Gateway and Dial BU 3850 Zanker Road, Building 1 San jose - 95134 USA Tel: 408 853 8235 Fax: 408 525 0640 e-mail: vnanduri@cisco.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jun 23 11:55:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26021 for ; Mon, 23 Jun 2003 11:55:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UTeo-0006S5-MG; Mon, 23 Jun 2003 11:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UTdx-0006RC-Be for megaco@optimus.ietf.org; Mon, 23 Jun 2003 11:54:39 -0400 Received: from ish7.ericsson.com.au (ish7.ericsson.com.au [61.88.9.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25928 for ; Mon, 23 Jun 2003 11:52:59 -0400 (EDT) Received: from brsf10.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h5K19Bk26854; Fri, 20 Jun 2003 11:09:11 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h5K1BbP27365; Fri, 20 Jun 2003 11:11:37 +1000 (EST) Received: from ericsson.com.au (146.11.245.130 [146.11.245.130]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LZBXVAAY; Fri, 20 Jun 2003 11:11:25 +1000 Message-ID: <3EF11E66.5BB454EB@ericsson.com.au> Date: Thu, 19 Jun 2003 12:22:30 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Aleksandr Ryabin CC: megaco@ietf.org, Kevin Boyle , micael.karlberg@ericsson.com Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? References: <5.2.1.1.0.20030617201948.02d0c8a0@imap.winphoria.com> <5.2.1.1.0.20030618091318.02d8bb08@imap.winphoria.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA25960 Sender: megaco-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 Aleksandr, You said "whole" local or remote descriptor MediaToken allows that. It do= es not allow "individual" local and remote descriptors. Regards, Christian Aleksandr Ryabin wrote: >=20 > Hi Christian, >=20 > Could you please clarify on how would MGC audit individual local, or > remote SDP with v1? I mean, local and remote SDPs are part of > larger MediaDescriptor and the ABNF construction of auditItem > only allows auditing the whole MediaDescriptor, not parts of it: >=20 > ;at-most-once, and DigitMapToken and PackagesToken are not allow= ed > ;in AuditCapabilities command > auditItem =3D ( MuxToken / ModemToken / MediaToken / > SignalsToken / EventBufferToken / > DigitMapToken / StatsToken / EventsToken= / > ObservedEventsToken / PackagesToken ) >=20 > So, if I understand it correctly, MGC can only audit the whole > MediaDescriptor, not individual local, or remote SDP. >=20 > Regards, > Aleks >=20 > At 11:59 PM 6/17/2003, Christian Groves wrote: > >Hello Aleksandr, > > > >Megaco does allow you to audit a whole local or remote descriptor. Thi= s is the > >audit capability v1. Individual auditing was added in v2. We didn't ad= d > >individual audit of a whole descriptor as this would duplicate functio= nality. > > > >It was decided not to allow auditing of individual segments of local a= nd > >remote > >SDP (text encoding) because no body could come up with an appropriate > >method to > >do this and didn't know what the reply looked like. For the binary enc= oding it > >was very easy because all parameters follow a tag length value structu= re. You > >request the tag and you get back the value. > > > >Christian > > > >Aleksandr Ryabin wrote: > > > > > > Hi, > > > > > > While we are on topic. The following does not allow auditing for th= e whole > > > local or remote SDP in ABNF: > > > ; at-most-once > > > indAudstreamParm =3D ( indAudlocalControlDescriptor ) > > > ; SDP too complex to pull out individual pieces for audit, > > > ; hence no individual audit for Local and Remote > > > > > > The question is why? I mean why does not it allow to audit *whole* > > > local or remote SDP? E.g.: > > > indAudstreamParm =3D ( indAudlocalControlDescriptor / Loca= lToken / > > > RemoteToken) > > > > > > BTW ASN.1 does allow that, as well as individual pieces of SDPs. > > > > > > Thanks > > > Aleks > > > > > > PS. Small nit in indAudauditReturnParameter (two slashes at the end= ): > > > indAudauditReturnParameter =3D (indAudmediaDescriptor / / > > > > > > At 03:30 PM 6/17/2003, Kevin Boyle wrote: > > > >Aha... I see the problem now. In binary, you can request info abo= ut > > several > > > >streams at once, but you may only request info about one stream in > > text. Is > > > >this an accurate summary? > > > > > > > >Seeing as this would be a syntax change, we need to know if anyone= would > > > >have major heartburn over changing the syntax to fix this. If not= , I will > > > >draft up an IG item to fix this... > > > > > > > >Speaking personally, I think this is a beneficial change, because = it makes > > > >the syntax align between the expression of items within the media > > > >descriptor, and the audit of items within the media descriptor, as= well as > > > >making both binary and text align in capability. > > > > > > > >Any other comments? > > > > > > > >Kevin > > > > > > > >-----Original Message----- > > > >From: Micael Karlberg [mailto:micael.karlberg@ericsson.com] > > > >Sent: Tuesday, June 17, 2003 1:26 PM > > > >To: Christian Groves > > > >Cc: megaco@ietf.org > > > >Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? > > > > > > > > > > > >Hello Christian, > > > > > > > >Christian Groves writes: > > > > > Hello Micael, > > > > > > > > > > I don't understand what the problem is nor the comments in the > > ASN.1 you > > > >are > referring to? > > > > > > > >The comment ("at-most-once per item...") is in the ABNF. > > > > > > > > > If you are referring to the ::=3D SEQUENCE this is actually an= ASN.1 > > > > >construct that says that a sequence of information elements may be > > encoded, > > > >in > this case "termStateDescr" & a choice of streams. > > > > > > > >This is how see it also. > > > > > > > > > This same information is represented by the ABNF. > > > > > > > >This I _cannot_ find! > > > > > > > >The comment in the ABNF seems to indicate that it should be as in > > > >the ASN.1 but the ABNF definition of the indAudmediaDescriptor > > > >allow for only one value of indAudmediaParm. > > > > > > > >Therefor my _question_ if the definition should'nt really be: > > > > > > > > indAudmediaDescriptor =3D MediaToken LBRKT indAudmediaPar= m > > > > *(COMMA indAudmediaParm) RBRKT > > > > > > > >Also, the defintion of the mediaDescriptor strikes me as _very_ si= milar to > > > >my "proposal": > > > > > > > > mediaDescriptor =3D MediaToken LBRKT mediaParm > > > > *(COMMA mediaParm) RBRKT > > > > > > > > ; at-most one terminationStateDescriptor > > > > ; and either streamParm(s) or streamDescriptor(s) but not b= oth > > > > mediaParm =3D (streamParm / streamDescriptor / > > > > terminationStateDescriptor) > > > > > > > >Regards, > > > > /BMK > > > > > > > > > > > > > > Regards, Christian > > > > > > > > > > Micael Karlberg wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a > > mismatch > > > > > >between the ABNF and the ASN.1 regarding indAudmediaDescriptor. >= > My > > > >question is: Should the definition of ABNF indAudmediaDescriptor = > > > > really > > > >be: > > > > > > > > indAudmediaDescriptor =3D MediaToken LBRKT indAudmed= iaParm > > > > > > *(COMMA indAudmediaParm) RBR= KT > > > > > > > > > > > > The comment for indAudmediaParm and the ASN.1 > > IndAudMediaDescriptor > > > > > > indicates that it should be a list. Or am I missing something? = > > > > > > > > Also, see definition of mediaDescriptor! > > > > > > > > > > > > ABNF: > > > > > > ---- > > > > > > indAudmediaDescriptor =3D MediaToken LBRKT indAudmed= iaParm > > RBRKT > > > > > > > > > > > > ; at-most-once per item > > > > > > ; and either streamParm or streamDescriptor but not bo= th > > > > > > indAudmediaParm =3D (indAudstreamParm / indAudstreamDe= scriptor / > > > > > > indAudterminationStateDescriptor) > > > > > > > > > > > > ASN.1: > > > > > > ----- > > > > > > IndAudMediaDescriptor ::=3D SEQUENCE > > > > > > { > > > > > > > > > > > > termStateDescr IndAudTerminationStateDescriptor > > OPTIONAL, > > > > > > streams CHOICE > > > > > > { > > > > > > oneStream IndAudStreamParms, > > > > > > multiStream SEQUENCE OF IndAudStreamDes= criptor > > > > > > } OPTIONAL, > > > > > > ... > > > > > > } > > > > > > > > > > > > Regards, > > > > > > /BMK > > > > > > > > > > > > _______________________________________________ > > > > > > Megaco mailing list > > > > > > Megaco@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > > > >-- > > > >Micael Karlberg Ericsson AB, =C4lvsj=F6 Sweden > > > >Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development > > > >ECN: 851 5668 Mail: micael.karlberg@ericsson.com > > > >Fax: +46 8 727 5775 > > > > > > > >_______________________________________________ > > > >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 Jun 23 11:55:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26054 for ; Mon, 23 Jun 2003 11:55:44 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NFtGm24981 for megaco-archive@odin.ietf.org; Mon, 23 Jun 2003 11:55:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UTf2-0006Uq-L2 for megaco-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 11:55:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26006 for ; Mon, 23 Jun 2003 11:55:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UTf1-0003GK-00 for megaco-web-archive@ietf.org; Mon, 23 Jun 2003 11:55:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UTev-0003GA-00 for megaco-web-archive@ietf.org; Mon, 23 Jun 2003 11:55:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UTeo-0006S5-MG; Mon, 23 Jun 2003 11:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UTdx-0006RC-Be for megaco@optimus.ietf.org; Mon, 23 Jun 2003 11:54:39 -0400 Received: from ish7.ericsson.com.au (ish7.ericsson.com.au [61.88.9.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25928 for ; Mon, 23 Jun 2003 11:52:59 -0400 (EDT) Received: from brsf10.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h5K19Bk26854; Fri, 20 Jun 2003 11:09:11 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h5K1BbP27365; Fri, 20 Jun 2003 11:11:37 +1000 (EST) Received: from ericsson.com.au (146.11.245.130 [146.11.245.130]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LZBXVAAY; Fri, 20 Jun 2003 11:11:25 +1000 Message-ID: <3EF11E66.5BB454EB@ericsson.com.au> Date: Thu, 19 Jun 2003 12:22:30 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Aleksandr Ryabin CC: megaco@ietf.org, Kevin Boyle , micael.karlberg@ericsson.com Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? References: <5.2.1.1.0.20030617201948.02d0c8a0@imap.winphoria.com> <5.2.1.1.0.20030618091318.02d8bb08@imap.winphoria.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA25960 Sender: megaco-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 Content-Transfer-Encoding: quoted-printable Hello Aleksandr, You said "whole" local or remote descriptor MediaToken allows that. It do= es not allow "individual" local and remote descriptors. Regards, Christian Aleksandr Ryabin wrote: >=20 > Hi Christian, >=20 > Could you please clarify on how would MGC audit individual local, or > remote SDP with v1? I mean, local and remote SDPs are part of > larger MediaDescriptor and the ABNF construction of auditItem > only allows auditing the whole MediaDescriptor, not parts of it: >=20 > ;at-most-once, and DigitMapToken and PackagesToken are not allow= ed > ;in AuditCapabilities command > auditItem =3D ( MuxToken / ModemToken / MediaToken / > SignalsToken / EventBufferToken / > DigitMapToken / StatsToken / EventsToken= / > ObservedEventsToken / PackagesToken ) >=20 > So, if I understand it correctly, MGC can only audit the whole > MediaDescriptor, not individual local, or remote SDP. >=20 > Regards, > Aleks >=20 > At 11:59 PM 6/17/2003, Christian Groves wrote: > >Hello Aleksandr, > > > >Megaco does allow you to audit a whole local or remote descriptor. Thi= s is the > >audit capability v1. Individual auditing was added in v2. We didn't ad= d > >individual audit of a whole descriptor as this would duplicate functio= nality. > > > >It was decided not to allow auditing of individual segments of local a= nd > >remote > >SDP (text encoding) because no body could come up with an appropriate > >method to > >do this and didn't know what the reply looked like. For the binary enc= oding it > >was very easy because all parameters follow a tag length value structu= re. You > >request the tag and you get back the value. > > > >Christian > > > >Aleksandr Ryabin wrote: > > > > > > Hi, > > > > > > While we are on topic. The following does not allow auditing for th= e whole > > > local or remote SDP in ABNF: > > > ; at-most-once > > > indAudstreamParm =3D ( indAudlocalControlDescriptor ) > > > ; SDP too complex to pull out individual pieces for audit, > > > ; hence no individual audit for Local and Remote > > > > > > The question is why? I mean why does not it allow to audit *whole* > > > local or remote SDP? E.g.: > > > indAudstreamParm =3D ( indAudlocalControlDescriptor / Loca= lToken / > > > RemoteToken) > > > > > > BTW ASN.1 does allow that, as well as individual pieces of SDPs. > > > > > > Thanks > > > Aleks > > > > > > PS. Small nit in indAudauditReturnParameter (two slashes at the end= ): > > > indAudauditReturnParameter =3D (indAudmediaDescriptor / / > > > > > > At 03:30 PM 6/17/2003, Kevin Boyle wrote: > > > >Aha... I see the problem now. In binary, you can request info abo= ut > > several > > > >streams at once, but you may only request info about one stream in > > text. Is > > > >this an accurate summary? > > > > > > > >Seeing as this would be a syntax change, we need to know if anyone= would > > > >have major heartburn over changing the syntax to fix this. If not= , I will > > > >draft up an IG item to fix this... > > > > > > > >Speaking personally, I think this is a beneficial change, because = it makes > > > >the syntax align between the expression of items within the media > > > >descriptor, and the audit of items within the media descriptor, as= well as > > > >making both binary and text align in capability. > > > > > > > >Any other comments? > > > > > > > >Kevin > > > > > > > >-----Original Message----- > > > >From: Micael Karlberg [mailto:micael.karlberg@ericsson.com] > > > >Sent: Tuesday, June 17, 2003 1:26 PM > > > >To: Christian Groves > > > >Cc: megaco@ietf.org > > > >Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? > > > > > > > > > > > >Hello Christian, > > > > > > > >Christian Groves writes: > > > > > Hello Micael, > > > > > > > > > > I don't understand what the problem is nor the comments in the > > ASN.1 you > > > >are > referring to? > > > > > > > >The comment ("at-most-once per item...") is in the ABNF. > > > > > > > > > If you are referring to the ::=3D SEQUENCE this is actually an= ASN.1 > > > > >construct that says that a sequence of information elements may be > > encoded, > > > >in > this case "termStateDescr" & a choice of streams. > > > > > > > >This is how see it also. > > > > > > > > > This same information is represented by the ABNF. > > > > > > > >This I _cannot_ find! > > > > > > > >The comment in the ABNF seems to indicate that it should be as in > > > >the ASN.1 but the ABNF definition of the indAudmediaDescriptor > > > >allow for only one value of indAudmediaParm. > > > > > > > >Therefor my _question_ if the definition should'nt really be: > > > > > > > > indAudmediaDescriptor =3D MediaToken LBRKT indAudmediaPar= m > > > > *(COMMA indAudmediaParm) RBRKT > > > > > > > >Also, the defintion of the mediaDescriptor strikes me as _very_ si= milar to > > > >my "proposal": > > > > > > > > mediaDescriptor =3D MediaToken LBRKT mediaParm > > > > *(COMMA mediaParm) RBRKT > > > > > > > > ; at-most one terminationStateDescriptor > > > > ; and either streamParm(s) or streamDescriptor(s) but not b= oth > > > > mediaParm =3D (streamParm / streamDescriptor / > > > > terminationStateDescriptor) > > > > > > > >Regards, > > > > /BMK > > > > > > > > > > > > > > Regards, Christian > > > > > > > > > > Micael Karlberg wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a > > mismatch > > > > > >between the ABNF and the ASN.1 regarding indAudmediaDescriptor. >= > My > > > >question is: Should the definition of ABNF indAudmediaDescriptor = > > > > really > > > >be: > > > > > > > > indAudmediaDescriptor =3D MediaToken LBRKT indAudmed= iaParm > > > > > > *(COMMA indAudmediaParm) RBR= KT > > > > > > > > > > > > The comment for indAudmediaParm and the ASN.1 > > IndAudMediaDescriptor > > > > > > indicates that it should be a list. Or am I missing something? = > > > > > > > > Also, see definition of mediaDescriptor! > > > > > > > > > > > > ABNF: > > > > > > ---- > > > > > > indAudmediaDescriptor =3D MediaToken LBRKT indAudmed= iaParm > > RBRKT > > > > > > > > > > > > ; at-most-once per item > > > > > > ; and either streamParm or streamDescriptor but not bo= th > > > > > > indAudmediaParm =3D (indAudstreamParm / indAudstreamDe= scriptor / > > > > > > indAudterminationStateDescriptor) > > > > > > > > > > > > ASN.1: > > > > > > ----- > > > > > > IndAudMediaDescriptor ::=3D SEQUENCE > > > > > > { > > > > > > > > > > > > termStateDescr IndAudTerminationStateDescriptor > > OPTIONAL, > > > > > > streams CHOICE > > > > > > { > > > > > > oneStream IndAudStreamParms, > > > > > > multiStream SEQUENCE OF IndAudStreamDes= criptor > > > > > > } OPTIONAL, > > > > > > ... > > > > > > } > > > > > > > > > > > > Regards, > > > > > > /BMK > > > > > > > > > > > > _______________________________________________ > > > > > > Megaco mailing list > > > > > > Megaco@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > > > >-- > > > >Micael Karlberg Ericsson AB, =C4lvsj=F6 Sweden > > > >Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development > > > >ECN: 851 5668 Mail: micael.karlberg@ericsson.com > > > >Fax: +46 8 727 5775 > > > > > > > >_______________________________________________ > > > >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 Jun 23 11:55:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26056 for ; Mon, 23 Jun 2003 11:55:44 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NFtGH24998 for megaco-archive@odin.ietf.org; Mon, 23 Jun 2003 11:55:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UTf2-0006V7-TM for megaco-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 11:55:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26009 for ; Mon, 23 Jun 2003 11:55:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UTf1-0003GM-00 for megaco-web-archive@ietf.org; Mon, 23 Jun 2003 11:55:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UTev-0003GB-00 for megaco-web-archive@ietf.org; Mon, 23 Jun 2003 11:55:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UTep-0006SF-6y; Mon, 23 Jun 2003 11:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UTdz-0006RD-F3 for megaco@optimus.ietf.org; Mon, 23 Jun 2003 11:54:41 -0400 Received: from ish7.ericsson.com.au (ish7.ericsson.com.au [61.88.9.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25961 for ; Mon, 23 Jun 2003 11:54:07 -0400 (EDT) Received: from brsf10.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h5K19Ek26866; Fri, 20 Jun 2003 11:09:14 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h5K1BfP27387; Fri, 20 Jun 2003 11:11:41 +1000 (EST) Received: from ericsson.com.au (146.11.245.130 [146.11.245.130]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LZBXVAA9; Fri, 20 Jun 2003 11:11:28 +1000 Message-ID: <3EF12560.9D077C6D@ericsson.com.au> Date: Thu, 19 Jun 2003 12:52:16 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Aleksandr Ryabin CC: Kevin Boyle , megaco@ietf.org, micael.karlberg@ericsson.com Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? References: <5.2.1.1.0.20030618092037.02dc0310@imap.winphoria.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA25962 Sender: megaco-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 Content-Transfer-Encoding: quoted-printable G'Day Aleksandr, Functionality wise the text and binary version I see as equivalent as you= can ask for a list of parameters to be audited. How syntically this is acheiv= ed is has a difference. I don't think its necessary to change the ASN.1 as its = not broken and would break v2 implementations. If people want to change the A= BNF with *(COMMA mediaParm) then OK. We should also clarify that if you want multiple items from the same descriptor use *(COMMA ...), if you want mul= tiple items in different descriptors use indAudauditReturnParameter or IndAuditParameter. You still need the simple way for multiple descriptors. The question which you alluded to below is this an acceptable "Fix" (not = break implementations) or should it wait for a version change to align? Depending on the answer to the above perhaps this could be captured in th= e implementors' guide as a new section detailing the issue and saying solut= ion will be in v3. I believe we identified another issue at the May SG16 that= we agreed would be something to look at in v3. As for go "flexible" or "simple" on either of the encodings there was no conscious decision. I simply tried to mirror existing data structures whe= n I proposed the syntax in both the ASN1 and ABNF. That's why the ASN.1 has sequences because it mirrors previous related v1 structures. I tried to d= o the same for the ABNF but we had some last minute editing (re: local/remote c= omment) and some things were changed. That's why things are as they are. Regards, Christian Aleksandr Ryabin wrote: >=20 > Hi Christian, >=20 > I think that Michael originally pointed out on discrepancy between > ASN.1 and ABNF. Specifically, IndAudMediaDescriptor contains > multiStream which is defined as a SEQUENCE: > multiStream SEQUENCE OF IndAudStreamDescriptor >=20 > Thus inside of one IndAudMediaDescriptor construction MGC can > place multiple audit instructions for different streams, while > ABNF does not allow that. >=20 > You are right, there is a way to do it, but ABNF does not match > ASN.1 in this case on how to do it. In this case ASN.1 allows two > ways to do the same thing, while ABNF only one way. >=20 > Generally speaking my personal opinion that we should minimize cases > when MGC can do same things different ways and instead fix ASN.1 > spec to not allow SEQUENCE (but see more below), e.g.: > multiStream IndAudStreamDescriptor >=20 > Same problem for propertyParms in IndAudLocalControlDescriptor and > in IndAudTerminationStateDescriptor (SEQUENCE OF should be removed). > But if we are to fix this then we should fix the rest if ASN.1 indAudXX= X > constructions to not allow multiple audits inside of one construction a= nd that > means turning SEQENCE into CHOICE for most of IndAudXXX constructions. >=20 > So the way I see it, ASN.1 went the "flexible" way which can be complex= , > but and minimizes the final size of audit when several items needs to > be audited inside of one descriptor, while ABNF went "simple" way > which makes it strait forward, but it can get big if MGC need to audit > more then one item inside of one descriptor. >=20 > I think we should let it be since it is too much of the changes and add > flexibility of ASN.1 into ABNF in the next version which includes > adding (COMMA...) in most of indAudXXX constructions in ABNF. > At that point we should qualify with "at-most-once per item" > indAudauditReturnParameter in ABNF and IndAuditParameter in > ASN.1 do disallow "old simple" way. >=20 > Regards, > Aleks >=20 > At 11:55 PM 6/17/2003, Christian Groves wrote: > >G'Day Kevin and Micael, > > > >I still don't see a problem. indAudterminationAudit allows you to requ= est > >multiple values: > >indAudterminationAudit =3D indAudauditReturnParameter > > *(COMMA indAudauditReturnParameter) > > > >indAudauditReturnParameter =3D (indAudmediaDescriptor / / > > > >indAudeventsDescriptor / > > > >indAudsignalsDescriptor / > > > >indAuddigitMapDescriptor / > > > >indAudeventBufferDescriptor / > > > >indAudstatisticsDescriptor / > > > >indAudpackagesDescriptor) > > > > > >indAudmediaDescriptor =3D MediaToken LBRKT indAudmediaParm RBRKT > > > >This allows you to request several streams. So the capabilities are > >aligned. The > >reason we have the indAudstreamParm / indAudstreamDescriptor is to all= ow > >for the > >case where no streamid is given. > > > >Regards, Christian > > > >Kevin Boyle wrote: > > > > > > Aha... I see the problem now. In binary, you can request info abou= t > > several > > > streams at once, but you may only request info about one stream in > > text. Is > > > this an accurate summary? > > > > > > Seeing as this would be a syntax change, we need to know if anyone > > would have > > > major heartburn over changing the syntax to fix this. If not, I wi= ll > > draft up > > > an IG item to fix this... > > > > > > Speaking personally, I think this is a beneficial change, because i= t > > makes the > > > syntax align between the expression of items within the media > > descriptor, and > > > the audit of items within the media descriptor, as well as making b= oth > > binary > > > and text align in capability. > > > > > > Any other comments? > > > > > > Kevin > > > > > > -----Original Message----- > > > From: Micael Karlberg [mailto:micael.karlberg@ericsson.com] > > > Sent: Tuesday, June 17, 2003 1:26 PM > > > To: Christian Groves > > > Cc: megaco@ietf.org > > > Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? > > > > > > Hello Christian, > > > > > > Christian Groves writes: > > > > Hello Micael, > > > > > > > > I don't understand what the problem is nor the comments in the A= SN.1 you > > > are > referring to? > > > > > > The comment ("at-most-once per item...") is in the ABNF. > > > > > > > If you are referring to the ::=3D SEQUENCE this is actually an A= SN.1 > > > > construct that says that a sequence of information elements may be = encoded, > > > in > this case "termStateDescr" & a choice of streams. > > > > > > This is how see it also. > > > > > > > This same information is represented by the ABNF. > > > > > > This I _cannot_ find! > > > > > > The comment in the ABNF seems to indicate that it should be as in > > > the ASN.1 but the ABNF definition of the indAudmediaDescriptor > > > allow for only one value of indAudmediaParm. > > > > > > Therefor my _question_ if the definition should'nt really be: > > > > > > indAudmediaDescriptor =3D MediaToken LBRKT indAudmediaParm > > > *(COMMA indAudmediaParm) RBRKT > > > > > > Also, the defintion of the mediaDescriptor strikes me as _very_ sim= ilar > > to my > > > "proposal": > > > > > > mediaDescriptor =3D MediaToken LBRKT mediaParm > > > *(COMMA mediaParm) RBRKT > > > > > > ; at-most one terminationStateDescriptor > > > ; and either streamParm(s) or streamDescriptor(s) but not bot= h > > > mediaParm =3D (streamParm / streamDescriptor / > > > terminationStateDescriptor) > > > > > > Regards, > > > /BMK > > > > > > > > > > > Regards, Christian > > > > > > > > Micael Karlberg wrote: > > > > > > > > > > Hi, > > > > > > > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismat= ch > > > > > between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > = > My > > > question is: Should the definition of ABNF indAudmediaDescriptor >= > > > really > > > be: > > > > > > > > > > indAudmediaDescriptor =3D MediaToken LBRKT indAudmedia= Parm > > > > > *(COMMA indAudmediaParm) RBRKT > > > > > > > > > > The comment for indAudmediaParm and the ASN.1 > > IndAudMediaDescriptor > > > > > indicates that it should be a list. Or am I missing something? > > > > > > > > > > Also, see definition of mediaDescriptor! > > > > > > > > > > ABNF: > > > > > ---- > > > > > indAudmediaDescriptor =3D MediaToken LBRKT indAudmedia= Parm RBRKT > > > > > > > > > > ; at-most-once per item > > > > > ; and either streamParm or streamDescriptor but not both > > > > > indAudmediaParm =3D (indAudstreamParm / indAudstreamDesc= riptor / > > > > > indAudterminationStateDescriptor) > > > > > > > > > > ASN.1: > > > > > ----- > > > > > IndAudMediaDescriptor ::=3D SEQUENCE > > > > > { > > > > > > > > > > termStateDescr IndAudTerminationStateDescriptor OP= TIONAL, > > > > > streams CHOICE > > > > > { > > > > > oneStream IndAudStreamParms, > > > > > multiStream SEQUENCE OF IndAudStreamDescr= iptor > > > > > } OPTIONAL, > > > > > ... > > > > > } > > > > > > > > > > Regards, > > > > > /BMK > > > > > > > > > > _______________________________________________ > > > > > Megaco mailing list > > > > > Megaco@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > > -- > > > Micael Karlberg Ericsson AB, =C4lvsj=F6 Sweden > > > Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development > > > ECN: 851 5668 Mail: micael.karlberg@ericsson.com > > > Fax: +46 8 727 5775 > > > > > > _______________________________________________ > > > 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 >=20 > _______________________________________________ > 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 Jun 23 12:53:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26022 for ; Mon, 23 Jun 2003 11:55:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UTep-0006SF-6y; Mon, 23 Jun 2003 11:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UTdz-0006RD-F3 for megaco@optimus.ietf.org; Mon, 23 Jun 2003 11:54:41 -0400 Received: from ish7.ericsson.com.au (ish7.ericsson.com.au [61.88.9.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25961 for ; Mon, 23 Jun 2003 11:54:07 -0400 (EDT) Received: from brsf10.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h5K19Ek26866; Fri, 20 Jun 2003 11:09:14 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h5K1BfP27387; Fri, 20 Jun 2003 11:11:41 +1000 (EST) Received: from ericsson.com.au (146.11.245.130 [146.11.245.130]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LZBXVAA9; Fri, 20 Jun 2003 11:11:28 +1000 Message-ID: <3EF12560.9D077C6D@ericsson.com.au> Date: Thu, 19 Jun 2003 12:52:16 +1000 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Aleksandr Ryabin CC: Kevin Boyle , megaco@ietf.org, micael.karlberg@ericsson.com Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? References: <5.2.1.1.0.20030618092037.02dc0310@imap.winphoria.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA25962 Sender: megaco-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 G'Day Aleksandr, Functionality wise the text and binary version I see as equivalent as you= can ask for a list of parameters to be audited. How syntically this is acheiv= ed is has a difference. I don't think its necessary to change the ASN.1 as its = not broken and would break v2 implementations. If people want to change the A= BNF with *(COMMA mediaParm) then OK. We should also clarify that if you want multiple items from the same descriptor use *(COMMA ...), if you want mul= tiple items in different descriptors use indAudauditReturnParameter or IndAuditParameter. You still need the simple way for multiple descriptors. The question which you alluded to below is this an acceptable "Fix" (not = break implementations) or should it wait for a version change to align? Depending on the answer to the above perhaps this could be captured in th= e implementors' guide as a new section detailing the issue and saying solut= ion will be in v3. I believe we identified another issue at the May SG16 that= we agreed would be something to look at in v3. As for go "flexible" or "simple" on either of the encodings there was no conscious decision. I simply tried to mirror existing data structures whe= n I proposed the syntax in both the ASN1 and ABNF. That's why the ASN.1 has sequences because it mirrors previous related v1 structures. I tried to d= o the same for the ABNF but we had some last minute editing (re: local/remote c= omment) and some things were changed. That's why things are as they are. Regards, Christian Aleksandr Ryabin wrote: >=20 > Hi Christian, >=20 > I think that Michael originally pointed out on discrepancy between > ASN.1 and ABNF. Specifically, IndAudMediaDescriptor contains > multiStream which is defined as a SEQUENCE: > multiStream SEQUENCE OF IndAudStreamDescriptor >=20 > Thus inside of one IndAudMediaDescriptor construction MGC can > place multiple audit instructions for different streams, while > ABNF does not allow that. >=20 > You are right, there is a way to do it, but ABNF does not match > ASN.1 in this case on how to do it. In this case ASN.1 allows two > ways to do the same thing, while ABNF only one way. >=20 > Generally speaking my personal opinion that we should minimize cases > when MGC can do same things different ways and instead fix ASN.1 > spec to not allow SEQUENCE (but see more below), e.g.: > multiStream IndAudStreamDescriptor >=20 > Same problem for propertyParms in IndAudLocalControlDescriptor and > in IndAudTerminationStateDescriptor (SEQUENCE OF should be removed). > But if we are to fix this then we should fix the rest if ASN.1 indAudXX= X > constructions to not allow multiple audits inside of one construction a= nd that > means turning SEQENCE into CHOICE for most of IndAudXXX constructions. >=20 > So the way I see it, ASN.1 went the "flexible" way which can be complex= , > but and minimizes the final size of audit when several items needs to > be audited inside of one descriptor, while ABNF went "simple" way > which makes it strait forward, but it can get big if MGC need to audit > more then one item inside of one descriptor. >=20 > I think we should let it be since it is too much of the changes and add > flexibility of ASN.1 into ABNF in the next version which includes > adding (COMMA...) in most of indAudXXX constructions in ABNF. > At that point we should qualify with "at-most-once per item" > indAudauditReturnParameter in ABNF and IndAuditParameter in > ASN.1 do disallow "old simple" way. >=20 > Regards, > Aleks >=20 > At 11:55 PM 6/17/2003, Christian Groves wrote: > >G'Day Kevin and Micael, > > > >I still don't see a problem. indAudterminationAudit allows you to requ= est > >multiple values: > >indAudterminationAudit =3D indAudauditReturnParameter > > *(COMMA indAudauditReturnParameter) > > > >indAudauditReturnParameter =3D (indAudmediaDescriptor / / > > > >indAudeventsDescriptor / > > > >indAudsignalsDescriptor / > > > >indAuddigitMapDescriptor / > > > >indAudeventBufferDescriptor / > > > >indAudstatisticsDescriptor / > > > >indAudpackagesDescriptor) > > > > > >indAudmediaDescriptor =3D MediaToken LBRKT indAudmediaParm RBRKT > > > >This allows you to request several streams. So the capabilities are > >aligned. The > >reason we have the indAudstreamParm / indAudstreamDescriptor is to all= ow > >for the > >case where no streamid is given. > > > >Regards, Christian > > > >Kevin Boyle wrote: > > > > > > Aha... I see the problem now. In binary, you can request info abou= t > > several > > > streams at once, but you may only request info about one stream in > > text. Is > > > this an accurate summary? > > > > > > Seeing as this would be a syntax change, we need to know if anyone > > would have > > > major heartburn over changing the syntax to fix this. If not, I wi= ll > > draft up > > > an IG item to fix this... > > > > > > Speaking personally, I think this is a beneficial change, because i= t > > makes the > > > syntax align between the expression of items within the media > > descriptor, and > > > the audit of items within the media descriptor, as well as making b= oth > > binary > > > and text align in capability. > > > > > > Any other comments? > > > > > > Kevin > > > > > > -----Original Message----- > > > From: Micael Karlberg [mailto:micael.karlberg@ericsson.com] > > > Sent: Tuesday, June 17, 2003 1:26 PM > > > To: Christian Groves > > > Cc: megaco@ietf.org > > > Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? > > > > > > Hello Christian, > > > > > > Christian Groves writes: > > > > Hello Micael, > > > > > > > > I don't understand what the problem is nor the comments in the A= SN.1 you > > > are > referring to? > > > > > > The comment ("at-most-once per item...") is in the ABNF. > > > > > > > If you are referring to the ::=3D SEQUENCE this is actually an A= SN.1 > > > > construct that says that a sequence of information elements may be = encoded, > > > in > this case "termStateDescr" & a choice of streams. > > > > > > This is how see it also. > > > > > > > This same information is represented by the ABNF. > > > > > > This I _cannot_ find! > > > > > > The comment in the ABNF seems to indicate that it should be as in > > > the ASN.1 but the ABNF definition of the indAudmediaDescriptor > > > allow for only one value of indAudmediaParm. > > > > > > Therefor my _question_ if the definition should'nt really be: > > > > > > indAudmediaDescriptor =3D MediaToken LBRKT indAudmediaParm > > > *(COMMA indAudmediaParm) RBRKT > > > > > > Also, the defintion of the mediaDescriptor strikes me as _very_ sim= ilar > > to my > > > "proposal": > > > > > > mediaDescriptor =3D MediaToken LBRKT mediaParm > > > *(COMMA mediaParm) RBRKT > > > > > > ; at-most one terminationStateDescriptor > > > ; and either streamParm(s) or streamDescriptor(s) but not bot= h > > > mediaParm =3D (streamParm / streamDescriptor / > > > terminationStateDescriptor) > > > > > > Regards, > > > /BMK > > > > > > > > > > > Regards, Christian > > > > > > > > Micael Karlberg wrote: > > > > > > > > > > Hi, > > > > > > > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismat= ch > > > > > between the ABNF and the ASN.1 regarding indAudmediaDescriptor. > = > My > > > question is: Should the definition of ABNF indAudmediaDescriptor >= > > > really > > > be: > > > > > > > > > > indAudmediaDescriptor =3D MediaToken LBRKT indAudmedia= Parm > > > > > *(COMMA indAudmediaParm) RBRKT > > > > > > > > > > The comment for indAudmediaParm and the ASN.1 > > IndAudMediaDescriptor > > > > > indicates that it should be a list. Or am I missing something? > > > > > > > > > > Also, see definition of mediaDescriptor! > > > > > > > > > > ABNF: > > > > > ---- > > > > > indAudmediaDescriptor =3D MediaToken LBRKT indAudmedia= Parm RBRKT > > > > > > > > > > ; at-most-once per item > > > > > ; and either streamParm or streamDescriptor but not both > > > > > indAudmediaParm =3D (indAudstreamParm / indAudstreamDesc= riptor / > > > > > indAudterminationStateDescriptor) > > > > > > > > > > ASN.1: > > > > > ----- > > > > > IndAudMediaDescriptor ::=3D SEQUENCE > > > > > { > > > > > > > > > > termStateDescr IndAudTerminationStateDescriptor OP= TIONAL, > > > > > streams CHOICE > > > > > { > > > > > oneStream IndAudStreamParms, > > > > > multiStream SEQUENCE OF IndAudStreamDescr= iptor > > > > > } OPTIONAL, > > > > > ... > > > > > } > > > > > > > > > > Regards, > > > > > /BMK > > > > > > > > > > _______________________________________________ > > > > > Megaco mailing list > > > > > Megaco@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > > -- > > > Micael Karlberg Ericsson AB, =C4lvsj=F6 Sweden > > > Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development > > > ECN: 851 5668 Mail: micael.karlberg@ericsson.com > > > Fax: +46 8 727 5775 > > > > > > _______________________________________________ > > > 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 >=20 > _______________________________________________ > 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 Jun 25 11:35:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15837 for ; Wed, 25 Jun 2003 11:35:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIg-00013u-DA; Wed, 25 Jun 2003 11:35:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBqm-0006YL-44 for megaco@optimus.ietf.org; Wed, 25 Jun 2003 11:07:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08619 for ; Wed, 25 Jun 2003 09:18:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VAAk-0003je-00 for megaco@ietf.org; Wed, 25 Jun 2003 09:18:50 -0400 Received: from shardagate.mahindrabt.com ([203.124.158.2]) by ietf-mx with esmtp (Exim 4.12) id 19VAAY-0003jP-00 for megaco@ietf.org; Wed, 25 Jun 2003 09:18:38 -0400 Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97]) by shardagate.mahindrabt.com (8.12.9/8.12.9) with ESMTP id h5PDHxIY002183 for ; Wed, 25 Jun 2003 18:48:05 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Wed, 25 Jun 2003 18:31:53 +0530 Date: Wed, 25 Jun 2003 18:31:53 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: anilj@mahindrabt.com Received: from dscp00986 ([10.5.13.76]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id SAA32577; Wed, 25 Jun 2003 18:47:54 +0530 Message-ID: <012701c33b1c$fd6fc6f0$4c0d050a@mahindrabt.com> From: "Anil Jangam" To: "Christian Groves" Cc: References: <009801c33a5c$3208b6e0$4c0d050a@mahindrabt.com> <3EF938EB.5090807@ericsson.com.au> Date: Wed, 25 Jun 2003 18:53:39 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Megaco] Re: ISDN Package for 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: , Content-Transfer-Encoding: 7bit Hi Christian, yes, you are correct. The events related to signaling (q.931) messages that an isdn terminal would generate, would eventually be transmitted to MGC by IUA backhualing. As far as the bearer events on the same isdn termination is concern, I am not sure how the "draft-bouwen-megaco-isdn-pack-00.txt" (though expired) is applicable. I was looking into the q.931, but could not find much except that the beraer events (e.g. offhook + called party number) would be communicated to the MGC in a single Q.931 SETUP message. In this case then what are the other bearer events that MEGACO is going to detect and/or report the to the MGC? What role does megaco is going to play (if at all it plays!)? I hope my query now makes some sense. /anil. ----- Original Message ----- From: "Christian Groves" To: "Anil Jangam" Cc: ; "Tom-PT Taylor" Sent: Wednesday, June 25, 2003 11:25 AM Subject: Re: ISDN Package for Megaco. > Hello Anil, > > The status of the draft is that its expired so theoretically it doesn't exist!? > > I don't think the aspects so mention below are of much interest to the Megaco > protocol. The backhaul interface (using IUA etc) would be something different to > the Megaco interface. Could you be more specific on your question 1.? Is it > events related to the ISDN signalling data (ie. the backhauled channel) or > bearer events? > > Regards, Christian > > Anil Jangam wrote: > > Hi, > > > > What is the status of the document "draft-bouwen-megaco-isdn-pack-00.txt"? > > As it stands in the Packages supplement (rel-3) of the ITU-T, no 'Identity' > > is defined and the 'Status' is expired. > > > > I would like to know following regarding an 'ISDN-Access gateway' controlled > > by MEGACO : > > 1. How does the events and signaling generated out of the ISDN interface be > > handled? > > 2. Do we have to define an IUA interface in MGW to transport the signaling > > to MGC? In this case, how the MGW would look like? > > > > regards, > > /anil. > > > > ********************************************************* > > Disclaimer > > > > This message (including any attachments) contains > > confidential information intended for a specific > > individual and purpose, and is protected by law. > > If you are not the intended recipient, you should > > delete this message and are hereby notified that > > any disclosure, copying, or distribution of this > > message, or the taking of any action based on it, > > is strictly prohibited. > > > > ********************************************************* > > Visit us at http://www.mahindrabt.com > > > > > > > > > ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Jun 25 11:35:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16044 for ; Wed, 25 Jun 2003 11:35:56 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFZSA05985 for megaco-archive@odin.ietf.org; Wed, 25 Jun 2003 11:35:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIy-0001YL-QC for megaco-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:35:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15675 for ; Wed, 25 Jun 2003 11:35:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCIw-0004ey-00 for megaco-web-archive@ietf.org; Wed, 25 Jun 2003 11:35:26 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VCIp-0004di-00 for megaco-web-archive@ietf.org; Wed, 25 Jun 2003 11:35:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIg-00013u-DA; Wed, 25 Jun 2003 11:35:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBqm-0006YL-44 for megaco@optimus.ietf.org; Wed, 25 Jun 2003 11:07:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08619 for ; Wed, 25 Jun 2003 09:18:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VAAk-0003je-00 for megaco@ietf.org; Wed, 25 Jun 2003 09:18:50 -0400 Received: from shardagate.mahindrabt.com ([203.124.158.2]) by ietf-mx with esmtp (Exim 4.12) id 19VAAY-0003jP-00 for megaco@ietf.org; Wed, 25 Jun 2003 09:18:38 -0400 Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97]) by shardagate.mahindrabt.com (8.12.9/8.12.9) with ESMTP id h5PDHxIY002183 for ; Wed, 25 Jun 2003 18:48:05 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Wed, 25 Jun 2003 18:31:53 +0530 Date: Wed, 25 Jun 2003 18:31:53 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: anilj@mahindrabt.com Received: from dscp00986 ([10.5.13.76]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id SAA32577; Wed, 25 Jun 2003 18:47:54 +0530 Message-ID: <012701c33b1c$fd6fc6f0$4c0d050a@mahindrabt.com> From: "Anil Jangam" To: "Christian Groves" Cc: References: <009801c33a5c$3208b6e0$4c0d050a@mahindrabt.com> <3EF938EB.5090807@ericsson.com.au> Date: Wed, 25 Jun 2003 18:53:39 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Megaco] Re: ISDN Package for 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Christian, yes, you are correct. The events related to signaling (q.931) messages that an isdn terminal would generate, would eventually be transmitted to MGC by IUA backhualing. As far as the bearer events on the same isdn termination is concern, I am not sure how the "draft-bouwen-megaco-isdn-pack-00.txt" (though expired) is applicable. I was looking into the q.931, but could not find much except that the beraer events (e.g. offhook + called party number) would be communicated to the MGC in a single Q.931 SETUP message. In this case then what are the other bearer events that MEGACO is going to detect and/or report the to the MGC? What role does megaco is going to play (if at all it plays!)? I hope my query now makes some sense. /anil. ----- Original Message ----- From: "Christian Groves" To: "Anil Jangam" Cc: ; "Tom-PT Taylor" Sent: Wednesday, June 25, 2003 11:25 AM Subject: Re: ISDN Package for Megaco. > Hello Anil, > > The status of the draft is that its expired so theoretically it doesn't exist!? > > I don't think the aspects so mention below are of much interest to the Megaco > protocol. The backhaul interface (using IUA etc) would be something different to > the Megaco interface. Could you be more specific on your question 1.? Is it > events related to the ISDN signalling data (ie. the backhauled channel) or > bearer events? > > Regards, Christian > > Anil Jangam wrote: > > Hi, > > > > What is the status of the document "draft-bouwen-megaco-isdn-pack-00.txt"? > > As it stands in the Packages supplement (rel-3) of the ITU-T, no 'Identity' > > is defined and the 'Status' is expired. > > > > I would like to know following regarding an 'ISDN-Access gateway' controlled > > by MEGACO : > > 1. How does the events and signaling generated out of the ISDN interface be > > handled? > > 2. Do we have to define an IUA interface in MGW to transport the signaling > > to MGC? In this case, how the MGW would look like? > > > > regards, > > /anil. > > > > ********************************************************* > > Disclaimer > > > > This message (including any attachments) contains > > confidential information intended for a specific > > individual and purpose, and is protected by law. > > If you are not the intended recipient, you should > > delete this message and are hereby notified that > > any disclosure, copying, or distribution of this > > message, or the taking of any action based on it, > > is strictly prohibited. > > > > ********************************************************* > > Visit us at http://www.mahindrabt.com > > > > > > > > > ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jun 25 12:39:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20602 for ; Wed, 25 Jun 2003 12:39:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VDIT-00036f-6B; Wed, 25 Jun 2003 12:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBy2-0008Bp-DY for megaco@optimus.ietf.org; Wed, 25 Jun 2003 11:13:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03805 for ; Wed, 25 Jun 2003 03:14:20 -0400 (EDT) From: zhou.zichun@zte.com.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V4Tz-0002X1-00 for megaco@ietf.org; Wed, 25 Jun 2003 03:14:19 -0400 Received: from [211.96.102.115] (helo=zte.com.cn) by ietf-mx with esmtp (Exim 4.12) id 19V4To-0002Wq-00 for megaco@ietf.org; Wed, 25 Jun 2003 03:14:09 -0400 To: megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Wed, 25 Jun 2003 15:11:24 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.8 |June 18, 2001) at 2003-06-25 15:14:54 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] A question about H.248 on SCTP Sender: megaco-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, H.248.4 (Annex H) gives SCTP to transport H.248 transactions. The paper says: It is recommended that transactions related to one context are transported over the same stream. SCTP transmits messages and processes received messages in one stream. When MGC and MG exchange informations. The MG/MGC maybe get context_A messages from inbound stream_1, but send out context_A messages from inboud stream_2, the paper didn't tell us the streams MUST be used as pairs: inboud stream_1 so outbound stream_1. And there maybe coexist more than one SCTP associations between MGC/MGW. The MG/MGC maybe get contex_A messages from one association and respond the reply in another association. The paper din't tell us MUST use one association to process one context. The upper mechanism is different from TUP/ISUP call process. The MGC/MG couldn't anticipate the H.248 communication partner reply the call context message in which association or stream. If the MGC initiate a context in one association ,but received reply in another association, MGC have to forward the message to the initiated place. Doesn't it looks strange? Maybe u have further suggestion about this question. Thanks. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Jun 25 12:39:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20618 for ; Wed, 25 Jun 2003 12:39:39 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PGdBW12004 for megaco-archive@odin.ietf.org; Wed, 25 Jun 2003 12:39:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VDId-00037X-Ah for megaco-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 12:39:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20590 for ; Wed, 25 Jun 2003 12:39:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VDIc-0005GM-00 for megaco-web-archive@ietf.org; Wed, 25 Jun 2003 12:39:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VDIX-0005GJ-00 for megaco-web-archive@ietf.org; Wed, 25 Jun 2003 12:39:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VDIT-00036f-6B; Wed, 25 Jun 2003 12:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBy2-0008Bp-DY for megaco@optimus.ietf.org; Wed, 25 Jun 2003 11:13:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03805 for ; Wed, 25 Jun 2003 03:14:20 -0400 (EDT) From: zhou.zichun@zte.com.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V4Tz-0002X1-00 for megaco@ietf.org; Wed, 25 Jun 2003 03:14:19 -0400 Received: from [211.96.102.115] (helo=zte.com.cn) by ietf-mx with esmtp (Exim 4.12) id 19V4To-0002Wq-00 for megaco@ietf.org; Wed, 25 Jun 2003 03:14:09 -0400 To: megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Wed, 25 Jun 2003 15:11:24 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.8 |June 18, 2001) at 2003-06-25 15:14:54 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] A question about H.248 on SCTP Sender: megaco-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, H.248.4 (Annex H) gives SCTP to transport H.248 transactions. The paper says: It is recommended that transactions related to one context are transported over the same stream. SCTP transmits messages and processes received messages in one stream. When MGC and MG exchange informations. The MG/MGC maybe get context_A messages from inbound stream_1, but send out context_A messages from inboud stream_2, the paper didn't tell us the streams MUST be used as pairs: inboud stream_1 so outbound stream_1. And there maybe coexist more than one SCTP associations between MGC/MGW. The MG/MGC maybe get contex_A messages from one association and respond the reply in another association. The paper din't tell us MUST use one association to process one context. The upper mechanism is different from TUP/ISUP call process. The MGC/MG couldn't anticipate the H.248 communication partner reply the call context message in which association or stream. If the MGC initiate a context in one association ,but received reply in another association, MGC have to forward the message to the initiated place. Doesn't it looks strange? Maybe u have further suggestion about this question. Thanks. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Jun 25 13:25:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21942 for ; Wed, 25 Jun 2003 13:25:46 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PHLCk19630 for megaco-archive@odin.ietf.org; Wed, 25 Jun 2003 13:21:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VDxI-00056X-F4 for megaco-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 13:21:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21800 for ; Wed, 25 Jun 2003 13:21:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VDxH-0005Wm-00 for megaco-web-archive@ietf.org; Wed, 25 Jun 2003 13:21:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VDxC-0005Wj-00 for megaco-web-archive@ietf.org; Wed, 25 Jun 2003 13:21:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VDx7-00055p-5z; Wed, 25 Jun 2003 13:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VDwY-00055G-OG for megaco@optimus.ietf.org; Wed, 25 Jun 2003 13:20:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21777 for ; Wed, 25 Jun 2003 13:20:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VDwX-0005WC-00 for megaco@ietf.org; Wed, 25 Jun 2003 13:20:25 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19VDwM-0005Vy-00 for megaco@ietf.org; Wed, 25 Jun 2003 13:20:15 -0400 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 h5PHJGc06610; Wed, 25 Jun 2003 13:19:16 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NLV6ASLQ; Wed, 25 Jun 2003 13:19:16 -0400 Received: from nortelnetworks.com (acart1en.ca.nortel.com [47.129.129.130]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NLV9J6F2; Wed, 25 Jun 2003 13:19:16 -0400 Message-ID: <3EF9D98E.2000409@nortelnetworks.com> Date: Wed, 25 Jun 2003 13:19:10 -0400 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.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: zhou.zichun@zte.com.cn CC: megaco@ietf.org Subject: Re: [Megaco] A question about H.248 on SCTP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It really doesn't matter which stream each end uses, so long as one end uses the same stream for all messages relating to a given context. The reason for this rule is to ensure that messages arrive in order at the peer. zhou.zichun@zte.com.cn wrote: > Hi, > H.248.4 (Annex H) gives SCTP to transport H.248 transactions. The paper > says: It is recommended that transactions related to one context are > transported over the same stream. SCTP transmits messages and processes > received messages in one stream. > > When MGC and MG exchange informations. The MG/MGC maybe get context_A > messages from inbound stream_1, but send out context_A messages from inboud > stream_2, the paper didn't tell us the streams MUST be used as pairs: > inboud stream_1 so outbound stream_1. > > And there maybe coexist more than one SCTP associations between MGC/MGW. > The MG/MGC maybe get contex_A messages from one association and respond the > reply in another association. The paper din't tell us MUST use one > association to process one context. > > The upper mechanism is different from TUP/ISUP call process. The MGC/MG > couldn't anticipate the H.248 communication partner reply the call context > message in which association or stream. If the MGC initiate a context in > one association ,but received reply in another association, MGC have to > forward the message to the initiated place. Doesn't it looks strange? Maybe > u have further suggestion about this question. > > Thanks. > > > > > > _______________________________________________ > 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 Jun 25 14:12:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21941 for ; Wed, 25 Jun 2003 13:25:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VDx7-00055p-5z; Wed, 25 Jun 2003 13:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VDwY-00055G-OG for megaco@optimus.ietf.org; Wed, 25 Jun 2003 13:20:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21777 for ; Wed, 25 Jun 2003 13:20:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VDwX-0005WC-00 for megaco@ietf.org; Wed, 25 Jun 2003 13:20:25 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19VDwM-0005Vy-00 for megaco@ietf.org; Wed, 25 Jun 2003 13:20:15 -0400 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 h5PHJGc06610; Wed, 25 Jun 2003 13:19:16 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NLV6ASLQ; Wed, 25 Jun 2003 13:19:16 -0400 Received: from nortelnetworks.com (acart1en.ca.nortel.com [47.129.129.130]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NLV9J6F2; Wed, 25 Jun 2003 13:19:16 -0400 Message-ID: <3EF9D98E.2000409@nortelnetworks.com> Date: Wed, 25 Jun 2003 13:19:10 -0400 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.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: zhou.zichun@zte.com.cn CC: megaco@ietf.org Subject: Re: [Megaco] A question about H.248 on SCTP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit It really doesn't matter which stream each end uses, so long as one end uses the same stream for all messages relating to a given context. The reason for this rule is to ensure that messages arrive in order at the peer. zhou.zichun@zte.com.cn wrote: > Hi, > H.248.4 (Annex H) gives SCTP to transport H.248 transactions. The paper > says: It is recommended that transactions related to one context are > transported over the same stream. SCTP transmits messages and processes > received messages in one stream. > > When MGC and MG exchange informations. The MG/MGC maybe get context_A > messages from inbound stream_1, but send out context_A messages from inboud > stream_2, the paper didn't tell us the streams MUST be used as pairs: > inboud stream_1 so outbound stream_1. > > And there maybe coexist more than one SCTP associations between MGC/MGW. > The MG/MGC maybe get contex_A messages from one association and respond the > reply in another association. The paper din't tell us MUST use one > association to process one context. > > The upper mechanism is different from TUP/ISUP call process. The MGC/MG > couldn't anticipate the H.248 communication partner reply the call context > message in which association or stream. If the MGC initiate a context in > one association ,but received reply in another association, MGC have to > forward the message to the initiated place. Doesn't it looks strange? Maybe > u have further suggestion about this question. > > Thanks. > > > > > > _______________________________________________ > 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 Jun 26 02:32:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10027 for ; Thu, 26 Jun 2003 02:32:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQIc-00063J-Th; Thu, 26 Jun 2003 02:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQHr-00062d-SX for megaco@optimus.ietf.org; Thu, 26 Jun 2003 02:31:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10007; Thu, 26 Jun 2003 02:31:12 -0400 (EDT) From: P.Kotar@alcatel.de Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VQHo-00066C-00; Thu, 26 Jun 2003 02:31:12 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.71] helo=mailrelay1.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 19VQHd-000666-00; Thu, 26 Jun 2003 02:31:01 -0400 Received: from slsas5.stgl.netd.alcatel.de (destgs0000c.ad1.ad.alcatel.com [149.204.45.57]) by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id IAA29827; Thu, 26 Jun 2003 08:29:18 +0200 (MET DST) Subject: Re: [Megaco] Re: ISDN Package for Megaco. To: "Anil Jangam" Cc: "Christian Groves" , megaco@ietf.org, megaco-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 26 Jun 2003 08:29:34 +0200 X-MIMETrack: Serialize by Router on DEMTA001/DE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/26/2003 08:29:37 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes Sender: megaco-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: , Hello In deed there is a kind of interworking profile missing for DSS1 <-> H.248. Depending on the DSS1 messages and its content (e.g. SETUP message with or without cd party nbr. digits; with a certain bearer capability; if there is a Progress Indicator to be sent, etc). the related H.248 messages and their content have to be defined. This "co-operation between DSS1 and H.248" should be specified in order to allow that MG and MGCs of different manufacturers work together. Peter "Anil Jangam" t.com> cc: Sent by: Subject: [Megaco] Re: ISDN Package for Megaco. megaco-admin@iet f.org 06/25/2003 03:01 PM Hi Christian, yes, you are correct. The events related to signaling (q.931) messages that an isdn terminal would generate, would eventually be transmitted to MGC by IUA backhualing. As far as the bearer events on the same isdn termination is concern, I am not sure how the "draft-bouwen-megaco-isdn-pack-00.txt" (though expired) is applicable. I was looking into the q.931, but could not find much except that the beraer events (e.g. offhook + called party number) would be communicated to the MGC in a single Q.931 SETUP message. In this case then what are the other bearer events that MEGACO is going to detect and/or report the to the MGC? What role does megaco is going to play (if at all it plays!)? I hope my query now makes some sense. /anil. ----- Original Message ----- From: "Christian Groves" To: "Anil Jangam" Cc: ; "Tom-PT Taylor" Sent: Wednesday, June 25, 2003 11:25 AM Subject: Re: ISDN Package for Megaco. > Hello Anil, > > The status of the draft is that its expired so theoretically it doesn't exist!? > > I don't think the aspects so mention below are of much interest to the Megaco > protocol. The backhaul interface (using IUA etc) would be something different to > the Megaco interface. Could you be more specific on your question 1.? Is it > events related to the ISDN signalling data (ie. the backhauled channel) or > bearer events? > > Regards, Christian > > Anil Jangam wrote: > > Hi, > > > > What is the status of the document "draft-bouwen-megaco-isdn-pack-00.txt"? > > As it stands in the Packages supplement (rel-3) of the ITU-T, no 'Identity' > > is defined and the 'Status' is expired. > > > > I would like to know following regarding an 'ISDN-Access gateway' controlled > > by MEGACO : > > 1. How does the events and signaling generated out of the ISDN interface be > > handled? > > 2. Do we have to define an IUA interface in MGW to transport the signaling > > to MGC? In this case, how the MGW would look like? > > > > regards, > > /anil. > > > > ********************************************************* > > Disclaimer > > > > This message (including any attachments) contains > > confidential information intended for a specific > > individual and purpose, and is protected by law. > > If you are not the intended recipient, you should > > delete this message and are hereby notified that > > any disclosure, copying, or distribution of this > > message, or the taking of any action based on it, > > is strictly prohibited. > > > > ********************************************************* > > Visit us at http://www.mahindrabt.com > > > > > > > > > ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.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 Thu Jun 26 02:32:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10047 for ; Thu, 26 Jun 2003 02:32:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q6WAk23352 for megaco-archive@odin.ietf.org; Thu, 26 Jun 2003 02:32:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQIk-00064Z-GP for megaco-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 02:32:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10020 for ; Thu, 26 Jun 2003 02:32:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VQIg-00066d-00 for megaco-web-archive@ietf.org; Thu, 26 Jun 2003 02:32:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VQIb-00066a-00 for megaco-web-archive@ietf.org; Thu, 26 Jun 2003 02:32:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQIc-00063J-Th; Thu, 26 Jun 2003 02:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQHr-00062d-SX for megaco@optimus.ietf.org; Thu, 26 Jun 2003 02:31:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10007; Thu, 26 Jun 2003 02:31:12 -0400 (EDT) From: P.Kotar@alcatel.de Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VQHo-00066C-00; Thu, 26 Jun 2003 02:31:12 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.71] helo=mailrelay1.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 19VQHd-000666-00; Thu, 26 Jun 2003 02:31:01 -0400 Received: from slsas5.stgl.netd.alcatel.de (destgs0000c.ad1.ad.alcatel.com [149.204.45.57]) by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id IAA29827; Thu, 26 Jun 2003 08:29:18 +0200 (MET DST) Subject: Re: [Megaco] Re: ISDN Package for Megaco. To: "Anil Jangam" Cc: "Christian Groves" , megaco@ietf.org, megaco-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 26 Jun 2003 08:29:34 +0200 X-MIMETrack: Serialize by Router on DEMTA001/DE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/26/2003 08:29:37 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes Sender: megaco-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: , Hello In deed there is a kind of interworking profile missing for DSS1 <-> H.248. Depending on the DSS1 messages and its content (e.g. SETUP message with or without cd party nbr. digits; with a certain bearer capability; if there is a Progress Indicator to be sent, etc). the related H.248 messages and their content have to be defined. This "co-operation between DSS1 and H.248" should be specified in order to allow that MG and MGCs of different manufacturers work together. Peter "Anil Jangam" t.com> cc: Sent by: Subject: [Megaco] Re: ISDN Package for Megaco. megaco-admin@iet f.org 06/25/2003 03:01 PM Hi Christian, yes, you are correct. The events related to signaling (q.931) messages that an isdn terminal would generate, would eventually be transmitted to MGC by IUA backhualing. As far as the bearer events on the same isdn termination is concern, I am not sure how the "draft-bouwen-megaco-isdn-pack-00.txt" (though expired) is applicable. I was looking into the q.931, but could not find much except that the beraer events (e.g. offhook + called party number) would be communicated to the MGC in a single Q.931 SETUP message. In this case then what are the other bearer events that MEGACO is going to detect and/or report the to the MGC? What role does megaco is going to play (if at all it plays!)? I hope my query now makes some sense. /anil. ----- Original Message ----- From: "Christian Groves" To: "Anil Jangam" Cc: ; "Tom-PT Taylor" Sent: Wednesday, June 25, 2003 11:25 AM Subject: Re: ISDN Package for Megaco. > Hello Anil, > > The status of the draft is that its expired so theoretically it doesn't exist!? > > I don't think the aspects so mention below are of much interest to the Megaco > protocol. The backhaul interface (using IUA etc) would be something different to > the Megaco interface. Could you be more specific on your question 1.? Is it > events related to the ISDN signalling data (ie. the backhauled channel) or > bearer events? > > Regards, Christian > > Anil Jangam wrote: > > Hi, > > > > What is the status of the document "draft-bouwen-megaco-isdn-pack-00.txt"? > > As it stands in the Packages supplement (rel-3) of the ITU-T, no 'Identity' > > is defined and the 'Status' is expired. > > > > I would like to know following regarding an 'ISDN-Access gateway' controlled > > by MEGACO : > > 1. How does the events and signaling generated out of the ISDN interface be > > handled? > > 2. Do we have to define an IUA interface in MGW to transport the signaling > > to MGC? In this case, how the MGW would look like? > > > > regards, > > /anil. > > > > ********************************************************* > > Disclaimer > > > > This message (including any attachments) contains > > confidential information intended for a specific > > individual and purpose, and is protected by law. > > If you are not the intended recipient, you should > > delete this message and are hereby notified that > > any disclosure, copying, or distribution of this > > message, or the taking of any action based on it, > > is strictly prohibited. > > > > ********************************************************* > > Visit us at http://www.mahindrabt.com > > > > > > > > > ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.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 Thu Jun 26 04:24:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11946 for ; Thu, 26 Jun 2003 04:24:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VS34-0005dC-Jg; Thu, 26 Jun 2003 04:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VR5B-0001jm-72 for megaco@optimus.ietf.org; Thu, 26 Jun 2003 03:22:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10933 for ; Thu, 26 Jun 2003 03:21:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VR28-0006KJ-00 for megaco@ietf.org; Thu, 26 Jun 2003 03:19:04 -0400 Received: from einsteinium.btinternet.com ([194.73.73.147]) by ietf-mx with esmtp (Exim 4.12) id 19VR1x-0006KE-00 for megaco@ietf.org; Thu, 26 Jun 2003 03:18:53 -0400 Received: from dial81-135-8-20.in-addr.btopenworld.com ([81.135.8.20] helo=HERCULES) by einsteinium.btinternet.com with smtp (Exim 3.22 #23) id 19VR1T-0005j0-00 for megaco@ietf.org; Thu, 26 Jun 2003 08:18:24 +0100 Message-ID: <001601c33bb3$22547150$14088751@mpirical.com> From: "marcus gates" To: Date: Thu, 26 Jun 2003 08:18:06 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C33BBB.78597E80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Megaco] megaco traces Sender: megaco-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_0013_01C33BBB.78597E80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can anybody provide me with a typicla MEGACO call setup trace in = ethereal format? ------=_NextPart_000_0013_01C33BBB.78597E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Can anybody provide me with a typicla = MEGACO call=20 setup trace in ethereal format?
------=_NextPart_000_0013_01C33BBB.78597E80-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Jun 26 04:24:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11982 for ; Thu, 26 Jun 2003 04:24:42 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q8OEM22319 for megaco-archive@odin.ietf.org; Thu, 26 Jun 2003 04:24:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VS3C-0005ns-8S for megaco-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 04:24:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11881 for ; Thu, 26 Jun 2003 04:24:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VS39-0006ZZ-00 for megaco-web-archive@ietf.org; Thu, 26 Jun 2003 04:24:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VS33-0006ZW-00 for megaco-web-archive@ietf.org; Thu, 26 Jun 2003 04:24:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VS34-0005dC-Jg; Thu, 26 Jun 2003 04:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VR5B-0001jm-72 for megaco@optimus.ietf.org; Thu, 26 Jun 2003 03:22:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10933 for ; Thu, 26 Jun 2003 03:21:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VR28-0006KJ-00 for megaco@ietf.org; Thu, 26 Jun 2003 03:19:04 -0400 Received: from einsteinium.btinternet.com ([194.73.73.147]) by ietf-mx with esmtp (Exim 4.12) id 19VR1x-0006KE-00 for megaco@ietf.org; Thu, 26 Jun 2003 03:18:53 -0400 Received: from dial81-135-8-20.in-addr.btopenworld.com ([81.135.8.20] helo=HERCULES) by einsteinium.btinternet.com with smtp (Exim 3.22 #23) id 19VR1T-0005j0-00 for megaco@ietf.org; Thu, 26 Jun 2003 08:18:24 +0100 Message-ID: <001601c33bb3$22547150$14088751@mpirical.com> From: "marcus gates" To: Date: Thu, 26 Jun 2003 08:18:06 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C33BBB.78597E80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Megaco] megaco traces Sender: megaco-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_0013_01C33BBB.78597E80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can anybody provide me with a typicla MEGACO call setup trace in = ethereal format? ------=_NextPart_000_0013_01C33BBB.78597E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Can anybody provide me with a typicla = MEGACO call=20 setup trace in ethereal format?
------=_NextPart_000_0013_01C33BBB.78597E80-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jun 26 10:36:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28272 for ; Thu, 26 Jun 2003 10:36:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VXr0-0004cJ-Lr; Thu, 26 Jun 2003 10:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VS7N-0007Oz-9x for megaco@optimus.ietf.org; Thu, 26 Jun 2003 04:28:48 -0400 Received: from zte.com.cn ([211.96.102.115]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12352 for ; Thu, 26 Jun 2003 04:28:14 -0400 (EDT) From: zhou.zichun@zte.com.cn To: Tom Taylor Cc: megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Thu, 26 Jun 2003 16:26:24 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.8 |June 18, 2001) at 2003-06-26 16:29:05 MIME-Version: 1.0 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Subject: [Megaco] =?gb2312?B?tPC4tDogUmU6IFtNZWdhY29dIEEgcXVlc3Rpb24gYWJvdXQgSC4yNDggb24=?= SCTP Sender: megaco-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 DQpUb20sDQogIFRoaXMgcnVsZSBjYW4gZW5zdXJlIG9uZSBzaWRlIG1lc3NhZ2Ugc2VxdWVuY2Vs eSBhcnJpdmVkIGF0IHRoZSBwZWVyLiBCdXQNCm9ubHkgdGhlIG1lc3NhZ2Ugc2VxdWVuY2UgYXNz dXJhbmNlIGlzIG5vdCBlZmZpY2llbnQgaW4gYmlnIHN5c3RlbXMuIE1heWJlDQpiaWcgc3lzdGVt IGlzIG5lZ2xlY3RlZCBieSBNRUdBQ08uIFRoZSBwcm9ibGVtIGlzIHRoZSBiYWxhbmNlIGJldHdl ZW4NCm11bHRpLW1hY2hpbmUuIExldCdzIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgZXhhbXBsZToN Cg0KICBNR0MgaGFzIDIgbWFjaGluZXMoQSxCKSB0byAgcHJvY2VzcyB0aGUgY29udGV4dCB0cmFu c2FjdGlvbnMgZm9yIG9uZSBNR1cuDQpTaW5jZSBTQ1RQIGNhbm4ndCBwcm92aWRlIG9uZSBhc3Nv Y2lhdGlvbiBvbiBkaWZmZXJlbnQgbWFjaGluZXMuIFNvIHRoZXJlDQphcmUgYXQgbGVhc3QgdHdv IGFzc29jaWF0aW9uIG9uIG1hY2hpbmUgQSBhbmQgQi4gV2hlbiBhIGNvbnRleHQgbmVlZCB0byBi ZQ0KZXN0YWJsaXNoZWQsIHRoZSBNR0Mgc2VuZCB0cmFuc2FjdGlvbnMgdG8gTUdXIHRocm91Z2gg YXNzb2NpYXRpb24gYXQNCm1hY2hpbmUgQS4gQnV0IHRoZSBNR1cgbWF5IHNlbmQgTk9USUZZIHRy YW5zYWN0aW9ucyB0byBNU0MgdGhyb3VnaA0KYXNzb2NpYXRpb24gYXQgbWFjaGluZSBCLiBTbyBt YWNoaW5lIEIgaGF2ZSB0byBzZW5kIHRoaXMgbWVzc2FnZSB0byBtYWNoaW5lDQpBLiBXaGVuIE1H QyBoYXZlIG1vcmUgbWFjaGluZXMsIHRoZSBtZXNzYWdlIGRpc3RyaWJ1dGlvbiBpcyBhIG1lc3Mu DQoNCiAgSW4gdGhlIFRETSBjYWxsIHByb2Nlc3MsIElUVSBkZWZpbmVzIENJQyBudW1iZXIgZm9y IFRVUC9JU1VQIHByb2Nlc3NpbmcNCnBhaXIuIFNpbmNlIGV2ZXJ5IGNhbGwgaXMgY29tYmluZWQg d2l0aCBhIENJQyBudW1iZXIsIGV2ZXJ5IFRVUC9JU1VQIGNhbGwNCm1lc3NhZ2UgYmluZyBhIENJ QywgaXQncyBlYXN5IHRvIGxldCBwcm9jZXNzIHBlZXJzIHRvIGZpbmQgdGhlIGNhbGwgcHJvY2Vz cw0KbWFjaGluZS4gQWxzbyB0aGUgQklDQyBwcm90b2NvbCBhZG9wdCB0aGUgQ0lDIHRvIGlkZW50 aWZ5IGNhbGwgZW50aXkNCmJldHdlZW4gQklDQyBwYWlyLg0KDQogIEl0J3MgYSBwaXR0eSB0aGVy ZSBpcyBubyBzaW1pbGFyIHdheSBpbiBNRUdBQ08uIFRob3VnaCBNRUdBQ08gcHJvdmlkZQ0KQ09O VEVYVElEIGJldHdlZW4gTUdXL01TQywgYnV0IHVuZm9ydHVuYXRlbHksIHRoZSBDT05URVhUSUQg aXMgZHluYW1pY2xseQ0KYWxsb2NhdGVkIGJ5IE1HVyBkdXJpbmcgdGhlIGNhbGwuIElmIHRoZSBN R1cgaXMgc21hbGwsIHRoZXJlIGlzIG5vIHByb2JsZW0sDQpiZWNhdXNlIGFsbCB0aGUgQ09OVEVY VCBpcyBwcm9jZXNzZWQgYnkgb25lIG1hY2hpbmUuIFdoZW4gdGhlIE1HVyBpcyBodWdlLA0KdGhl IGluY29taW5nIE1FR0FDTyBtZXNzYWdlIGRpc3RyaWJ1dGlvbiBpcyBhIHByb2JsZW0sIHRoZSBN RUdBQ08gYmVhcmVyDQpsYXllciBjb3VsZG4ndCBkZWNpZGUgd2hpY2ggcHJvY2VzcyBtYWNoaW5l IHNob3VsZCBnZXQgdGhpcyBtZXNzYWdlLCB1bmxpa2UNClRVUC9JU1VQLCB0aGUgTVRQMyBjYW4g ZmluZCB0aGUgcHJvY2VzcyBtYWNoaW5lIGJ5IENJQy4gT25seSBhZnRlciBILjI0OA0KZGVjb2Rl IHRoZSBtZXNzYWdlLCBpdCBjb3VsZCBmaW5kIHRoZSBwcm9jZXNzIG1hY2hpbmUgaW4gYSBtZXNz Lg0KDQogIElmIHdlIGFkZCBzaW1pbGFyIHJ1bGVzIGxpa2UgVFVQL0lTVVAsIHdlIHdpbGwgc29s dmUgdGhlc2UgcHJvYmxlbS4gSQ0Kc3VwcG9zZSB0aGUgcnVsZSBpczoNCg0KICAxLiAiSC4yNDgg Y2FsbCBDT05URVhUSUQgaXMgcHJlZGVmaW5lZCBiZXR3ZWVuIE1HQyBhbmQgTUdXLiBNR0MgZ2V0 IGENCkNPTlRFWFRJRCB3aGVuIGEgY2FsbCBzaG91bGQgYmUgaW5pdGlhdGVkLiBNR1cgZGVjaWRl IHdoZXRoZXIgdGhlIENPTlRFWFQNCmV4aXN0IG9yIG5vdCwgaWYgZG9zbid0IGV4aXN0IGl0IGNy ZWF0ZSBhIGNvbnRleHQgd2l0aCB0aGlzIENPTlRFWFRJRC4iDQpUaGlzIHJ1bGUgaXMgZm9yIG11 bHRpLW1hY2hpbmUgY2FsbCBsb2FkIGJhbGFuY2UsIGFuZCBmb3IgdHJhbnNwb3J0IGxheWVyDQpl YXN5IGZpbmRpbmcgcHJvY2VzcyBtYWNoaW5lLCBqdXN0IGxpa2Ugb3RoZXIgY2FsbCByZWxhdGVk IHByb3RvY29sDQpUVVAvSVNVUC9CSUNDLg0KDQogIDIuIk1HQy9NR1cgU0hPVUxEIHNlbGVjdCB0 cmFuc3BvcnQgbGF5ZXIgbGlua3Moc3VjaCBhcyBNVFAzQiBsaW5rcywgTTNVQQ0KQVNQcyBhbmQg c3RyZWFtcywgU0NUUCBhc3NvY2lhdGlvbnMgYW5kIHN0cmVhbXMsIFRDUCBsaW5rcywgVURQIHBv cnRzLCBldGMpDQpieSBDT05URVhUSUQgbG93ZXN0IDQgYml0cy4iIFRoaXMgcnVsZSBpcyBmb3Ig dHJhbnNhY3Rpb24gc2VxdWVuY2VzIGJlbG9uZw0Kb25lIGNvbnRleHQsIGFsc28gdGhlIGxvYWQg YmFsYW5jZSBvZiB0cmFuc3BvcnQgbGF5ZXIgbGlua3MuDQoNCiAgQmVzdCByZWdhcmRzLg0KDQog IFppY2h1bg0KDQoNCg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCiAgICAgICAgICAgICAgICAgICAgVG9tIFRheWxvciAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAg ICAgICAgIDx0YXlsb3JAbm9ydGVsbmV0ICAgICAgIMrVvP7Iy6O6ICAgICB6aG91LnppY2h1bkB6 dGUuY29tLmNuICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICB3b3Jrcy5jb20+ ICAgICAgICAgICAgICCzrcvNo7ogIG1lZ2Fjb0BpZXRmLm9yZyAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg1vfM 4qO6ICBSZTogW01lZ2Fjb10gQSBxdWVzdGlvbiBhYm91dCBILjI0OCBvbiAgICAgDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTQ1RQICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgMjAwMy0wNi0yNiAwMToxOSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQoNCg0KDQpJdCByZWFsbHkgZG9lc24ndCBtYXR0ZXIg d2hpY2ggc3RyZWFtIGVhY2ggZW5kIHVzZXMsIHNvIGxvbmcgYXMgb25lIGVuZA0KdXNlcyB0aGUN CnNhbWUgc3RyZWFtIGZvciBhbGwgbWVzc2FnZXMgcmVsYXRpbmcgdG8gYSBnaXZlbiBjb250ZXh0 LiAgVGhlIHJlYXNvbiBmb3INCnRoaXMgcnVsZQ0KaXMgdG8gZW5zdXJlIHRoYXQgbWVzc2FnZXMg YXJyaXZlIGluIG9yZGVyIGF0IHRoZSBwZWVyLg0KDQp6aG91LnppY2h1bkB6dGUuY29tLmNuIHdy b3RlOg0KDQo+IEhpLA0KPiAgIEguMjQ4LjQgKEFubmV4IEgpIGdpdmVzIFNDVFAgdG8gdHJhbnNw b3J0IEguMjQ4IHRyYW5zYWN0aW9ucy4gVGhlIHBhcGVyDQo+IHNheXM6IEl0IGlzIHJlY29tbWVu ZGVkIHRoYXQgdHJhbnNhY3Rpb25zIHJlbGF0ZWQgdG8gb25lIGNvbnRleHQgYXJlDQo+IHRyYW5z cG9ydGVkIG92ZXIgdGhlIHNhbWUgc3RyZWFtLiBTQ1RQIHRyYW5zbWl0cyBtZXNzYWdlcyBhbmQg cHJvY2Vzc2VzDQo+IHJlY2VpdmVkIG1lc3NhZ2VzIGluIG9uZSBzdHJlYW0uDQo+DQo+ICAgV2hl biBNR0MgYW5kIE1HIGV4Y2hhbmdlIGluZm9ybWF0aW9ucy4gVGhlIE1HL01HQyBtYXliZSBnZXQg Y29udGV4dF9BDQo+IG1lc3NhZ2VzIGZyb20gaW5ib3VuZCBzdHJlYW1fMSwgYnV0IHNlbmQgb3V0 IGNvbnRleHRfQSBtZXNzYWdlcyBmcm9tDQppbmJvdWQNCj4gc3RyZWFtXzIsIHRoZSBwYXBlciBk aWRuJ3QgdGVsbCB1cyB0aGUgc3RyZWFtcyBNVVNUIGJlIHVzZWQgYXMgcGFpcnM6DQo+IGluYm91 ZCBzdHJlYW1fMSBzbyBvdXRib3VuZCBzdHJlYW1fMS4NCj4NCj4gICBBbmQgdGhlcmUgbWF5YmUg Y29leGlzdCBtb3JlIHRoYW4gb25lIFNDVFAgYXNzb2NpYXRpb25zIGJldHdlZW4NCk1HQy9NR1cu DQo+IFRoZSBNRy9NR0MgbWF5YmUgZ2V0IGNvbnRleF9BIG1lc3NhZ2VzIGZyb20gb25lIGFzc29j aWF0aW9uIGFuZCByZXNwb25kDQp0aGUNCj4gcmVwbHkgaW4gYW5vdGhlciBhc3NvY2lhdGlvbi4g VGhlIHBhcGVyIGRpbid0IHRlbGwgdXMgTVVTVCB1c2Ugb25lDQo+IGFzc29jaWF0aW9uIHRvIHBy b2Nlc3Mgb25lIGNvbnRleHQuDQo+DQo+ICAgVGhlIHVwcGVyIG1lY2hhbmlzbSBpcyBkaWZmZXJl bnQgZnJvbSBUVVAvSVNVUCBjYWxsIHByb2Nlc3MuIFRoZSBNR0MvTUcNCj4gY291bGRuJ3QgYW50 aWNpcGF0ZSB0aGUgSC4yNDggY29tbXVuaWNhdGlvbiBwYXJ0bmVyIHJlcGx5IHRoZSBjYWxsDQpj b250ZXh0DQo+IG1lc3NhZ2UgaW4gd2hpY2ggYXNzb2NpYXRpb24gb3Igc3RyZWFtLiBJZiB0aGUg TUdDIGluaXRpYXRlIGEgY29udGV4dCBpbg0KPiBvbmUgYXNzb2NpYXRpb24gLGJ1dCByZWNlaXZl ZCByZXBseSBpbiBhbm90aGVyIGFzc29jaWF0aW9uLCBNR0MgaGF2ZSB0bw0KPiBmb3J3YXJkIHRo ZSBtZXNzYWdlIHRvIHRoZSBpbml0aWF0ZWQgcGxhY2UuIERvZXNuJ3QgaXQgbG9va3Mgc3RyYW5n ZT8NCk1heWJlDQo+IHUgaGF2ZSBmdXJ0aGVyIHN1Z2dlc3Rpb24gYWJvdXQgdGhpcyBxdWVzdGlv bi4NCj4NCj4gICBUaGFua3MuDQo+DQo+DQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE1lZ2FjbyBtYWlsaW5nIGxpc3QNCj4gTWVn YWNvQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21l Z2Fjbw0KPg0KDQoNCg0K _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jun 26 11:22:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02025 for ; Thu, 26 Jun 2003 11:22:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYZV-0001P3-V5; Thu, 26 Jun 2003 11:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYYj-0001OU-7b for megaco@optimus.ietf.org; Thu, 26 Jun 2003 11:21:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01823 for ; Thu, 26 Jun 2003 11:20:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VYYT-0002ap-00 for megaco@ietf.org; Thu, 26 Jun 2003 11:20:57 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19VYYI-0002W0-00 for megaco@ietf.org; Thu, 26 Jun 2003 11:20:46 -0400 Received: from smilevm.winphoria.com ([10.14.25.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 26 Jun 2003 11:15:21 -0400 Message-Id: <5.2.1.1.0.20030626110256.027fc0c0@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 26 Jun 2003 11:14:20 -0400 To: zhou.zichun@zte.com.cn, megaco@ietf.org From: Aleksandr Ryabin Subject: Re: [Megaco] A question about H.248 on SCTP Cc: Tom Taylor In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 26 Jun 2003 15:15:22.0148 (UTC) FILETIME=[C305F640:01C33BF5] 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 Hi, I'm not exactly following how SCTP differ from UDP, or TCP for message distribution problem you are trying to solve, but in Notify there is RequestIdentifier which is provided by MGC (A or B), thus you can route (on A) based on it, that is of course provided you parse whole message on A, which you have to do anyway since a message can contain several transactions with terminationIds "serviced" by different MGCs Regards, Aleks At 04:26 AM 6/26/2003, zhou.zichun@zte.com.cn wrote: >Tom, > This rule can ensure one side message sequencely arrived at the peer.= But >only the message sequence assurance is not efficient in big systems. Maybe >big system is neglected by MEGACO. The problem is the balance between >multi-machine. Let's consider the following example: > > MGC has 2 machines(A,B) to process the context transactions for one= MGW. >Since SCTP cann't provide one association on different machines. So there >are at least two association on machine A and B. When a context need to be >established, the MGC send transactions to MGW through association at >machine A. But the MGW may send NOTIFY transactions to MSC through >association at machine B. So machine B have to send this message to machine >A. When MGC have more machines, the message distribution is a mess. > > In the TDM call process, ITU defines CIC number for TUP/ISUP processing >pair. Since every call is combined with a CIC number, every TUP/ISUP call >message bing a CIC, it's easy to let process peers to find the call process >machine. Also the BICC protocol adopt the CIC to identify call entiy >between BICC pair. > > It's a pitty there is no similar way in MEGACO. Though MEGACO provide >CONTEXTID between MGW/MSC, but unfortunately, the CONTEXTID is dynamiclly >allocated by MGW during the call. If the MGW is small, there is no problem, >because all the CONTEXT is processed by one machine. When the MGW is huge, >the incoming MEGACO message distribution is a problem, the MEGACO bearer >layer couldn't decide which process machine should get this message, unlike >TUP/ISUP, the MTP3 can find the process machine by CIC. Only after H.248 >decode the message, it could find the process machine in a mess. > > If we add similar rules like TUP/ISUP, we will solve these problem. I >suppose the rule is: > > 1. "H.248 call CONTEXTID is predefined between MGC and MGW. MGC get a >CONTEXTID when a call should be initiated. MGW decide whether the CONTEXT >exist or not, if dosn't exist it create a context with this CONTEXTID." >This rule is for multi-machine call load balance, and for transport layer >easy finding process machine, just like other call related protocol >TUP/ISUP/BICC. > > 2."MGC/MGW SHOULD select transport layer links(such as MTP3B links, M3UA >ASPs and streams, SCTP associations and streams, TCP links, UDP ports, etc) >by CONTEXTID lowest 4 bits." This rule is for transaction sequences belong >one context, also the load balance of transport layer links. > > Best regards. > > Zichun > > > > > > >=20 > > Tom=20 > Taylor > zhou.zichun@zte.com.cn > works.com> =B3=AD=CB=CD=A3=BA = megaco@ietf.org=20 > > =D6=F7=CC=E2=A3=BA Re:= [Megaco] A=20 > question about H.248 on > SCTP=20 > >=20 > > 2003-06-26=20 > 01:19 >=20 > >=20 > > > > > > >It really doesn't matter which stream each end uses, so long as one end >uses the >same stream for all messages relating to a given context. The reason for >this rule >is to ensure that messages arrive in order at the peer. > >zhou.zichun@zte.com.cn wrote: > > > Hi, > > H.248.4 (Annex H) gives SCTP to transport H.248 transactions. The= paper > > says: It is recommended that transactions related to one context are > > transported over the same stream. SCTP transmits messages and processes > > received messages in one stream. > > > > When MGC and MG exchange informations. The MG/MGC maybe get context_A > > messages from inbound stream_1, but send out context_A messages from >inboud > > stream_2, the paper didn't tell us the streams MUST be used as pairs: > > inboud stream_1 so outbound stream_1. > > > > And there maybe coexist more than one SCTP associations between >MGC/MGW. > > The MG/MGC maybe get contex_A messages from one association and respond >the > > reply in another association. The paper din't tell us MUST use one > > association to process one context. > > > > The upper mechanism is different from TUP/ISUP call process. The= MGC/MG > > couldn't anticipate the H.248 communication partner reply the call >context > > message in which association or stream. If the MGC initiate a context in > > one association ,but received reply in another association, MGC have to > > forward the message to the initiated place. Doesn't it looks strange? >Maybe > > u have further suggestion about this question. > > > > Thanks. > > > > > > > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > >gagagagaco > > > > > > https://www1.ietf.org/mailman/lis1=E8r=89=9A=8AX=A7=82X=AC=B4=C7=20 > i=CA"z=D7=E8=AEm=B6=9B?=FF0=D6'=AD~=8A=E0=FEf=A2=ADf=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 Jun 26 11:23:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02131 for ; Thu, 26 Jun 2003 11:23:04 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QFMa105499 for megaco-archive@odin.ietf.org; Thu, 26 Jun 2003 11:22:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYa4-0001Qc-4y for megaco-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 11:22:36 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02026 for ; Thu, 26 Jun 2003 11:22:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYZV-0001P3-V5; Thu, 26 Jun 2003 11:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYYj-0001OU-7b for megaco@optimus.ietf.org; Thu, 26 Jun 2003 11:21:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01823 for ; Thu, 26 Jun 2003 11:20:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VYYT-0002ap-00 for megaco@ietf.org; Thu, 26 Jun 2003 11:20:57 -0400 Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com) by ietf-mx with esmtp (Exim 4.12) id 19VYYI-0002W0-00 for megaco@ietf.org; Thu, 26 Jun 2003 11:20:46 -0400 Received: from smilevm.winphoria.com ([10.14.25.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 26 Jun 2003 11:15:21 -0400 Message-Id: <5.2.1.1.0.20030626110256.027fc0c0@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 26 Jun 2003 11:14:20 -0400 To: zhou.zichun@zte.com.cn, megaco@ietf.org From: Aleksandr Ryabin Subject: Re: [Megaco] A question about H.248 on SCTP Cc: Tom Taylor In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 26 Jun 2003 15:15:22.0148 (UTC) FILETIME=[C305F640:01C33BF5] 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 Content-Transfer-Encoding: quoted-printable Hi, I'm not exactly following how SCTP differ from UDP, or TCP for message distribution problem you are trying to solve, but in Notify there is RequestIdentifier which is provided by MGC (A or B), thus you can route (on A) based on it, that is of course provided you parse whole message on A, which you have to do anyway since a message can contain several transactions with terminationIds "serviced" by different MGCs Regards, Aleks At 04:26 AM 6/26/2003, zhou.zichun@zte.com.cn wrote: >Tom, > This rule can ensure one side message sequencely arrived at the peer.= But >only the message sequence assurance is not efficient in big systems. Maybe >big system is neglected by MEGACO. The problem is the balance between >multi-machine. Let's consider the following example: > > MGC has 2 machines(A,B) to process the context transactions for one= MGW. >Since SCTP cann't provide one association on different machines. So there >are at least two association on machine A and B. When a context need to be >established, the MGC send transactions to MGW through association at >machine A. But the MGW may send NOTIFY transactions to MSC through >association at machine B. So machine B have to send this message to machine >A. When MGC have more machines, the message distribution is a mess. > > In the TDM call process, ITU defines CIC number for TUP/ISUP processing >pair. Since every call is combined with a CIC number, every TUP/ISUP call >message bing a CIC, it's easy to let process peers to find the call process >machine. Also the BICC protocol adopt the CIC to identify call entiy >between BICC pair. > > It's a pitty there is no similar way in MEGACO. Though MEGACO provide >CONTEXTID between MGW/MSC, but unfortunately, the CONTEXTID is dynamiclly >allocated by MGW during the call. If the MGW is small, there is no problem, >because all the CONTEXT is processed by one machine. When the MGW is huge, >the incoming MEGACO message distribution is a problem, the MEGACO bearer >layer couldn't decide which process machine should get this message, unlike >TUP/ISUP, the MTP3 can find the process machine by CIC. Only after H.248 >decode the message, it could find the process machine in a mess. > > If we add similar rules like TUP/ISUP, we will solve these problem. I >suppose the rule is: > > 1. "H.248 call CONTEXTID is predefined between MGC and MGW. MGC get a >CONTEXTID when a call should be initiated. MGW decide whether the CONTEXT >exist or not, if dosn't exist it create a context with this CONTEXTID." >This rule is for multi-machine call load balance, and for transport layer >easy finding process machine, just like other call related protocol >TUP/ISUP/BICC. > > 2."MGC/MGW SHOULD select transport layer links(such as MTP3B links, M3UA >ASPs and streams, SCTP associations and streams, TCP links, UDP ports, etc) >by CONTEXTID lowest 4 bits." This rule is for transaction sequences belong >one context, also the load balance of transport layer links. > > Best regards. > > Zichun > > > > > > >=20 > > Tom=20 > Taylor > zhou.zichun@zte.com.cn > works.com> =B3=AD=CB=CD=A3=BA = megaco@ietf.org=20 > > =D6=F7=CC=E2=A3=BA Re:= [Megaco] A=20 > question about H.248 on > SCTP=20 > >=20 > > 2003-06-26=20 > 01:19 >=20 > >=20 > > > > > > >It really doesn't matter which stream each end uses, so long as one end >uses the >same stream for all messages relating to a given context. The reason for >this rule >is to ensure that messages arrive in order at the peer. > >zhou.zichun@zte.com.cn wrote: > > > Hi, > > H.248.4 (Annex H) gives SCTP to transport H.248 transactions. The= paper > > says: It is recommended that transactions related to one context are > > transported over the same stream. SCTP transmits messages and processes > > received messages in one stream. > > > > When MGC and MG exchange informations. The MG/MGC maybe get context_A > > messages from inbound stream_1, but send out context_A messages from >inboud > > stream_2, the paper didn't tell us the streams MUST be used as pairs: > > inboud stream_1 so outbound stream_1. > > > > And there maybe coexist more than one SCTP associations between >MGC/MGW. > > The MG/MGC maybe get contex_A messages from one association and respond >the > > reply in another association. The paper din't tell us MUST use one > > association to process one context. > > > > The upper mechanism is different from TUP/ISUP call process. The= MGC/MG > > couldn't anticipate the H.248 communication partner reply the call >context > > message in which association or stream. If the MGC initiate a context in > > one association ,but received reply in another association, MGC have to > > forward the message to the initiated place. Doesn't it looks strange? >Maybe > > u have further suggestion about this question. > > > > Thanks. > > > > > > > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > >gagagagaco > > > > > > https://www1.ietf.org/mailman/lis1=E8r=89=9A=8AX=A7=82X=AC=B4=C7=20 > i=CA"z=D7=E8=AEm=B6=9B?=FF0=D6'=AD~=8A=E0=FEf=A2=ADf=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 Fri Jun 27 14:28:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10265 for ; Fri, 27 Jun 2003 14:28:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VxxA-0007qQ-AI; Fri, 27 Jun 2003 14:28:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vubq-0002P9-H5 for megaco@optimus.ietf.org; Fri, 27 Jun 2003 10:54:39 -0400 Received: from ish7.ericsson.com.au (ish7.ericsson.com.au [61.88.9.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20340 for ; Fri, 27 Jun 2003 04:11:31 -0400 (EDT) Received: from brsf10.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h5N62Rk06597; Mon, 23 Jun 2003 16:02:27 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h5N64sP18186; Mon, 23 Jun 2003 16:04:54 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.236.91]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LZBXWHBF; Mon, 23 Jun 2003 16:04:10 +1000 Message-ID: <3EF679AA.8070702@ericsson.com.au> Date: Mon, 23 Jun 2003 13:53:14 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aleksandr Ryabin CC: megaco@ietf.org, Kevin Boyle , micael.karlberg@ericsson.com Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? References: <5.2.1.1.0.20030617201948.02d0c8a0@imap.winphoria.com> <5.2.1.1.0.20030618091318.02d8bb08@imap.winphoria.com> <5.2.1.1.0.20030620102508.02de9e50@imap.winphoria.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA20341 Sender: megaco-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 Aleksandr, See below. Christian Aleksandr Ryabin wrote: > Hi Christian, >=20 > I'm not sure on your usage of "whole" and "individual". > They are complimentary: each SDP is "individual" and it is a "whole". > I said "whole" SDP, not "whole" MediaDescriptor. [CHG] Well no use arguing about personal interpretations maybe its the=20 difference between US english, International english and Australian engli= sh :). >=20 > What I'm trying to understand is: > How can MGC do an audit to get *only* whole local (or remote) SDP and=20 > nothing else? [CHG] No > My understanding current ABNF syntax does not allow it. > Do we agree on this? [CHG] Yes >=20 > If yes, is it useful to have such a functionality? I think yes. > Do we agree on this? [CHG] I don't oppose adding this if its wanted. >=20 > If yes, does my proposal below solves the request? I think yes. > Do we agree on this? [CHG] Yes >=20 > If yes, how do we go about adding it into IG/or next version? > Opinions? [CHG] Next version would enable the syntax change to be identified. Witho= ut=20 breaking things. >=20 > Thanks > Aleks >=20 > At 10:22 PM 6/18/2003, Christian Groves wrote: >=20 >> Hello Aleksandr, >> >> You said "whole" local or remote descriptor MediaToken allows that. It= =20 >> does not >> allow "individual" local and remote descriptors. >> >> Regards, Christian >> >> Aleksandr Ryabin wrote: >> > >> > Hi Christian, >> > >> > Could you please clarify on how would MGC audit individual local, or >> > remote SDP with v1? I mean, local and remote SDPs are part of >> > larger MediaDescriptor and the ABNF construction of auditItem >> > only allows auditing the whole MediaDescriptor, not parts of it: >> > >> > ;at-most-once, and DigitMapToken and PackagesToken are not=20 >> allowed >> > ;in AuditCapabilities command >> > auditItem =3D ( MuxToken / ModemToken / MediaToken= / >> > SignalsToken / EventBufferToken / >> > DigitMapToken / StatsToken /=20 >> EventsToken / >> > ObservedEventsToken / PackagesToken ) >> > >> > So, if I understand it correctly, MGC can only audit the whole >> > MediaDescriptor, not individual local, or remote SDP. >> > >> > Regards, >> > Aleks >> > >> > At 11:59 PM 6/17/2003, Christian Groves wrote: >> > >Hello Aleksandr, >> > > >> > >Megaco does allow you to audit a whole local or remote descriptor.=20 >> This is the >> > >audit capability v1. Individual auditing was added in v2. We didn't= =20 >> add >> > >individual audit of a whole descriptor as this would duplicate=20 >> functionality. >> > > >> > >It was decided not to allow auditing of individual segments of=20 >> local and >> > >remote >> > >SDP (text encoding) because no body could come up with an appropria= te >> > >method to >> > >do this and didn't know what the reply looked like. For the binary=20 >> encoding it >> > >was very easy because all parameters follow a tag length value=20 >> structure. You >> > >request the tag and you get back the value. >> > > >> > >Christian >> > > >> > >Aleksandr Ryabin wrote: >> > > > >> > > > Hi, >> > > > >> > > > While we are on topic. The following does not allow auditing for= =20 >> the whole >> > > > local or remote SDP in ABNF: >> > > > ; at-most-once >> > > > indAudstreamParm =3D ( indAudlocalControlDescriptor ) >> > > > ; SDP too complex to pull out individual pieces for aud= it, >> > > > ; hence no individual audit for Local and Remote >> > > > >> > > > The question is why? I mean why does not it allow to audit *whol= e* >> > > > local or remote SDP? E.g.: >> > > > indAudstreamParm =3D ( indAudlocalControlDescriptor /=20 >> LocalToken / >> > > > RemoteToken) >> > > > >> > > > BTW ASN.1 does allow that, as well as individual pieces of SDPs. >> > > > >> > > > Thanks >> > > > Aleks >> > > > >> > > > PS. Small nit in indAudauditReturnParameter (two slashes at the=20 >> end): >> > > > indAudauditReturnParameter =3D (indAudmediaDescriptor / / >> > > > >> > > > At 03:30 PM 6/17/2003, Kevin Boyle wrote: >> > > > >Aha... I see the problem now. In binary, you can request info=20 >> about >> > > several >> > > > >streams at once, but you may only request info about one stream= in >> > > text. Is >> > > > >this an accurate summary? >> > > > > >> > > > >Seeing as this would be a syntax change, we need to know if=20 >> anyone would >> > > > >have major heartburn over changing the syntax to fix this. If=20 >> not, I will >> > > > >draft up an IG item to fix this... >> > > > > >> > > > >Speaking personally, I think this is a beneficial change,=20 >> because it makes >> > > > >the syntax align between the expression of items within the med= ia >> > > > >descriptor, and the audit of items within the media descriptor,= =20 >> as well as >> > > > >making both binary and text align in capability. >> > > > > >> > > > >Any other comments? >> > > > > >> > > > >Kevin >> > > > > >> > > > >-----Original Message----- >> > > > >From: Micael Karlberg [mailto:micael.karlberg@ericsson.com] >> > > > >Sent: Tuesday, June 17, 2003 1:26 PM >> > > > >To: Christian Groves >> > > > >Cc: megaco@ietf.org >> > > > >Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm? >> > > > > >> > > > > >> > > > >Hello Christian, >> > > > > >> > > > >Christian Groves writes: >> > > > > > Hello Micael, >> > > > > > >> > > > > > I don't understand what the problem is nor the comments in = the >> > > ASN.1 you >> > > > >are > referring to? >> > > > > >> > > > >The comment ("at-most-once per item...") is in the ABNF. >> > > > > >> > > > > > If you are referring to the ::=3D SEQUENCE this is actually= =20 >> an ASN.1 > >> > > > >construct that says that a sequence of information elements may= be >> > > encoded, >> > > > >in > this case "termStateDescr" & a choice of streams. >> > > > > >> > > > >This is how see it also. >> > > > > >> > > > > > This same information is represented by the ABNF. >> > > > > >> > > > >This I _cannot_ find! >> > > > > >> > > > >The comment in the ABNF seems to indicate that it should be as = in >> > > > >the ASN.1 but the ABNF definition of the indAudmediaDescriptor >> > > > >allow for only one value of indAudmediaParm. >> > > > > >> > > > >Therefor my _question_ if the definition should'nt really be: >> > > > > >> > > > > indAudmediaDescriptor =3D MediaToken LBRKT indAudmedia= Parm >> > > > > *(COMMA indAudmediaParm) RBRK= T >> > > > > >> > > > >Also, the defintion of the mediaDescriptor strikes me as _very_= =20 >> similar to >> > > > >my "proposal": >> > > > > >> > > > > mediaDescriptor =3D MediaToken LBRKT mediaParm >> > > > > *(COMMA mediaParm) RBRKT >> > > > > >> > > > > ; at-most one terminationStateDescriptor >> > > > > ; and either streamParm(s) or streamDescriptor(s) but=20 >> not both >> > > > > mediaParm =3D (streamParm / streamDescriptor / >> > > > > terminationStateDescriptor) >> > > > > >> > > > >Regards, >> > > > > /BMK >> > > > > >> > > > > > >> > > > > > Regards, Christian >> > > > > > >> > > > > > Micael Karlberg wrote: >> > > > > > > >> > > > > > > Hi, >> > > > > > > >> > > > > > > In draft-ietf-megaco-h248v2-04.txt there appear to be a >> > > mismatch > > >> > > > >between the ABNF and the ASN.1 regarding=20 >> indAudmediaDescriptor. > > My >> > > > >question is: Should the definition of ABNF=20 >> indAudmediaDescriptor > > >> > > really >> > > > >be: > > >> > > > > > > indAudmediaDescriptor =3D MediaToken LBRKT=20 >> indAudmediaParm >> > > > > > > *(COMMA indAudmediaParm)=20 >> RBRKT >> > > > > > > >> > > > > > > The comment for indAudmediaParm and the ASN.1 >> > > IndAudMediaDescriptor > >> > > > > > indicates that it should be a list. Or am I missing=20 >> something? > > >> > > > > > > Also, see definition of mediaDescriptor! >> > > > > > > >> > > > > > > ABNF: >> > > > > > > ---- >> > > > > > > indAudmediaDescriptor =3D MediaToken LBRKT=20 >> indAudmediaParm >> > > RBRKT >> > > > > > > >> > > > > > > ; at-most-once per item >> > > > > > > ; and either streamParm or streamDescriptor but not= =20 >> both >> > > > > > > indAudmediaParm =3D (indAudstreamParm /=20 >> indAudstreamDescriptor / >> > > > > > > indAudterminationStateDescriptor= ) >> > > > > > > >> > > > > > > ASN.1: >> > > > > > > ----- >> > > > > > > IndAudMediaDescriptor ::=3D SEQUENCE >> > > > > > > { >> > > > > > > >> > > > > > > termStateDescr IndAudTerminationStateDescript= or >> > > OPTIONAL, >> > > > > > > streams CHOICE >> > > > > > > { >> > > > > > > oneStream IndAudStreamParms, >> > > > > > > multiStream SEQUENCE OF=20 >> IndAudStreamDescriptor >> > > > > > > } OPTIONAL, >> > > > > > > ... >> > > > > > > } >> > > > > > > >> > > > > > > Regards, >> > > > > > > /BMK >> > > > > > > >> > > > > > > _______________________________________________ >> > > > > > > Megaco mailing list >> > > > > > > Megaco@ietf.org >> > > > > > > https://www1.ietf.org/mailman/listinfo/megaco >> > > > > >> > > > >-- >> > > > >Micael Karlberg Ericsson AB, =C4lvsj=F6 Sweden >> > > > >Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development >> > > > >ECN: 851 5668 Mail: micael.karlberg@ericsson.com >> > > > >Fax: +46 8 727 5775 >> > > > > >> > > > >_______________________________________________ >> > > > >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 >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Jun 27 14:33:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10892 for ; Fri, 27 Jun 2003 14:33:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vy21-00015P-A7; Fri, 27 Jun 2003 14:33:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VvVM-0006FZ-Hk for megaco@optimus.ietf.org; Fri, 27 Jun 2003 11:51:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05101 for ; Fri, 27 Jun 2003 11:50:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VvV6-000448-00 for megaco@ietf.org; Fri, 27 Jun 2003 11:51:00 -0400 Received: from [4.19.224.196] (helo=wench.telica.com) by ietf-mx with esmtp (Exim 4.12) id 19VvUq-00043V-00 for megaco@ietf.org; Fri, 27 Jun 2003 11:50:44 -0400 Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jun 2003 11:49:40 -0400 Message-ID: From: Bob Braisted To: "'megaco@ietf.org'" Date: Fri, 27 Jun 2003 11:49:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] Z duration modifier and Timer overrides Sender: megaco-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 2 questions. 1. i see that in previous versions of h248v2 that the Z duration modifier was called out in Annex B of the protocol (see below) http://www1.ietf.org/internet-drafts/draft-ietf-megaco-h248v2-04.txt digitMapName = NAME digitMapValue = ["T" COLON Timer COMMA] ["S" COLON Timer COMMA] ["L" COLON Timer COMMA] ["Z" COLON Timer COMMA] digitMap Timer = 1*2DIGIT ; Units are seconds for T, S, and L timers, and hundreds of ; milliseconds for Z timer. Thus T, S, and L range from 1 to 99 ; seconds and Z from 100 ms to 9.9 s was this unintentionally omitted from the RFC 3525? and if not, how would one override the provisioned value of the Z duration modifier on a per call basis? 2. with respect to timer overrides, again referencing h248v2, i notice that previously, the letter "T" was a valid digitMapLetter, (used to specify start timer override), and the latest version does not include "T" in the digitMapLetter expression. Was this also intentionally removed? and if so, can we assume that overriding the start digit timer would consist of specifying ["T" COLON Timer COMMA] in the digit map descriptor and not within the digit map string itself.? the older version has ... digitMapLetter = DIGIT ;Basic event symbols / %x41-4B / %x61-6B ; a-k, A-K / "L" / "S" / "T" ;Inter-event timers (long, short, start) / "Z" ;Long duration modifier the latest version removes the "T" . Robert M. Braisted Tel: 508-804-8182 Telica, Inc Fax: 508-460-0698 734 Forest Street email:bbraisted@telica.com Building G, Suite 500 Marlboro, MA 01752 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Sun Jun 29 22:25:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14094 for ; Sun, 29 Jun 2003 22:25:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5U2P6303263 for megaco-archive@odin.ietf.org; Sun, 29 Jun 2003 22:25:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WoLq-0000qY-7F for megaco-web-archive@optimus.ietf.org; Sun, 29 Jun 2003 22:25:06 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14049 for ; Sun, 29 Jun 2003 22:24:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WoKn-0000ht-2w; Sun, 29 Jun 2003 22:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VucZ-0002P9-Nx for megaco@optimus.ietf.org; Fri, 27 Jun 2003 10:55:44 -0400 Received: from zte.com.cn ([211.96.102.115]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20062 for ; Fri, 27 Jun 2003 03:59:07 -0400 (EDT) From: zhou.zichun@zte.com.cn Subject: Re: Re: [Megaco] A question about H.248 on SCTP To: Aleksandr Ryabin Cc: megaco@ietf.org, Tom Taylor , zhou.zichun@zte.com.cn X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Fri, 27 Jun 2003 10:50:17 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.8 |June 18, 2001) at 2003-06-27 15:59:57 MIME-Version: 1.0 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 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 Content-Transfer-Encoding: base64 DQpIaSxhbGwNCiAgIEFzIFRvbSBzYWlkLEkgYWdyZWUgd2UgY2FuIHNwbGl0IGEgTUdXIGludG8g c2V2ZXJhbCB2aXJ0dWFsIE1HV3MgdG8NCnNvbHZlIGh1Z2UgTUdXIHByb2JsZW0uDQogICBBcyBB bGVrcyBzYWlkLCBJIGFncmVlIHRoZSB0cmFuc3BvcnQgY29ubmVjdGlvbiB0eXBlIG9mDQpUQ1Av VURQL1NDVFAvTVRQM0IvTTNVQSBhcmUgb2Ygbm8gZGlmZmVyZW5jZS4NCiAgIE1heWJlIG1heSBx dWVzdGlvbiBzaG91bGQgYmUgcmVuYW1lZCB0byBIb3cgSC4yNDggYmUgdXNlZCBpbiBiaWcgc3lz dGVtLA0Kbm90IG9ubHkgYWJvdXQgU0NUUCB0cmFuc3BvcnQgY29ubmVjdGlvbnMuDQogICBUaGUg cHJvYmxlbSBpczogaG93IG1hbnkgdHJhbnNwb3J0IGNvbm5lY3Rpb24gc2hvdWxkIGV4aXN0IGJl d3RlZW4gYQ0KcGFpciBNR0MtTUdXPyBUaGUgTUdDJ3Mgc2VydmljZWNoYW5nZSB0cmFuc2FjdGlv biBjYW4gcHJvdmlkZSBvbmx5IG9uZQ0KSVArUE9SVChldGMuKSBpbmRpY2F0aW9uLiBJZiB0aGUg YW5zd2VyIGlzIG9ubHkgb25lIGNvbm5lY3Rpb24gc3VjaCBhcw0KVENQL1NDVFAgY291bGQgZXhp c3QgYmV0d2VlbiBNR0MtTUdXIHBhaXIsIHNpbmNlIGhhcmR3YXJlIGNhcGFjaXR5IGlzDQpsaW1p dGVkIG9uZSBjb25uZWN0aW9uIGNhbiBwcm92aWRlIGxpbWl0ZWQgSC4yNDggdHJhbnNhY3Rpb24g ZGVsaXZlcnkNCmFiaWxpdHkuIEluIDNHUFAgd2hlbiB3ZSBkZXNpZ24gYmlnIE1HVyBzeXN0ZW0s IG9uZSBjb25uZWN0aW9uIGNhcGFjaXR5IGlzDQpub3QgZWZmaWNpZW50LiBPbmUgd29yZCwgbXVz dCB3ZSBzcGxpdCB0aGUgTUdXIGludG8gc2V2ZXJhbCBsaXR0bGUgc3lzdGVtcw0KdG8gcHJvdmlk ZSBzZXZlcmFsIGxvZ2ljYWwgaW50ZXJmYWNlIHRvIE1HQz8gSSB0aGluayBJdCdzIGluY29udmVu aWVudCBmb3INCnN5c3RlbSBtYWludGVuYW5jZSBhbmQgZXZvbHZlbWVudC4NCiAgIEkgdGhpbmsg QWxla3MgYW5kIFRvbSBkaWRuJ3QgcmVjb2duaXplIG15IHRydWUgaWRlYS4gSW4gbXkgYmVmb3Jl DQpzY2VuYXJpbyAsdGhlIE1HQyBoYXMgMiBtYWNoaW5lcyhwcm9jZXNzb3IpIHRvIHByb2Nlc3Mg b25lIE1HVywgdGhlc2UgMg0KbWFjaGluZXMgYmVsb25nIHRvIE9ORSBNR0MsIG1heWJlIHRoZXJl IGFyZSBtb3JlIHRoYW4gb25lIG1hY2hpbmUgb24gTUdXDQp0b28sIG5vdCBpbiBvdXIgc2lnaHQu IFdoZW4gMiBvciBtb3JlIHBvcmNlc3NvciBleGlzdGVkIHRoZSBwcm9jZXNzb3INCmlkZW50aWZ5 IGlzIGEgcHJvYmxlbS4gQXMgQWxla3Mgc2FpZCB3ZSBjYW4gcGFyc2UgdGhlIFJlcXVlc3RJZGVu dGlmaWVyIHRvDQppZGVudGlmeSB0aGUgcHJvY2Vzc29yLCBidXQgZG9uJ3QgdSB0aGluayBpdCB3 YXN0ZSBhIGxvdCB0aW1lLCBhbmQgdGhpcw0KbWV0aG9kIGNhbm4ndCBsZXQgTUdDIHByb2Nlc3Mg dGhlIGNhbGxpbmcgc3RhdGUgdGVybWluYXRpb24gb3V0IG9mIHNlcnZpY2UNClNlcnZpY2VDaGFu Z2UgdHJhbnNhY3Rpb25zLiBJIGluc2lzdCBwcmVkZWZpbmVkIENPTlRFWFRJRCBiZXR3ZWVuIE1H Qy1NR1cNCmlzIGEgYmV0dGVyIHdheSB0byBzb2x2ZSB0aGlzIHByb2JsZW0uIE9yIE1FR0FDTyBk ZWZpbmUgdGhpczoiIENPTlRFWFRJRCBpcw0KcHJlZGVmaW5lZCBvbiBNR1csIE1HQyBjYW4gYXVk aXQgQ09OVEVYVElEIGZyb20gTUdXIGFmdGVyIE1HVyByZWdpc3RlcmluZyIuDQpXZSBjYW4gZ2V0 IENPTlRFWFRJRCB3aXRoIGZldyBwYXJzaW5nIHN0ZXBzLiBPZiBjb3Vyc2Ugd2UgbXVzdCBkZWFs IHdpdGgNCm11bHRpLXRyYW5zYWN0aW9ucyBpbiBvbmUgbWVzc2FnZSwgdGhpcyBpcyBhIGVhc2ll ciBzY2FubmluZyB3b3JrIGNvbXBhcmUNCndpdGggd29yZCB0byB3b3JkIHBhcnNpbmcuDQoNCiAg IEkgZGlkbid0IHRoaW5rIHR3byBNR0NzIGNhbiBvcGVyYXRlIG9uZSBNR1csIGEgbG9naWMgTUdX IHNob3VsZCBiZWxvbmcNCnRvIG9uZSBNR0MuIEFzIE1FR0FDTyBkZWZpbml0aW9uIHRoZSBDT05U RVhUSUQgaXMgdmFsaWQgYmV0d2VlbiBhIE1HQy1NR1cNCnBhaXIsIHNvIHRoZSBDT05URVhUSUQg c2VsZWN0ZWQgYnkgTUdDIGlzIHBvc3NpYmxlLiBUaGUgYmlnIGFkdmFudGFnZSBvZg0KdGhpcyBy dWxlIGlzIGxldCBILjI0OCAgYWN0IGxpa2UgYSBjYWxsIHJlbGF0ZWQgcHJvdG9jb2wgbW9yZS4N CiAgIEknbSBjb25mdXNlZCBieSBBbGVrcydzIHdvcmRzOiAiYSBtZXNzYWdlIGNhbiBjb250YWlu IHNldmVyYWwNCnRyYW5zYWN0aW9ucyB3aXRoIHRlcm1pbmF0aW9uSWRzICdzZXJ2aWNlZCcgYnkg ZGlmZmVyZW50IE1HQ3MiLiBJIHRoaW5rDQp0aGlzIGNvdWxkbid0IGhhcHBlbiBiZWNhdXNlIHRo ZXJlIHNob3VsZCBiZSBkaWZmZW50IHRyYW5zcG9ydCBjb25uZWN0aW9ucw0KZnJvbSBkaWZmZXJl bnQgTUdDcyB0byBhIHBoeXNpY2FsIE1HVyh0aGlzIE1HVyB3YXMgc3BsaXR0ZWQgdG8gZGlmZmVy ZW50DQpNR1dzKS4NCg0KICAgQmVzdCByZWdhcmRzLA0KICAgWmljaHVuDQoNCg0KVG9tIFRheWxv ciA8dGF5bG9yQG5vcnRlbG5ldHdvcmtzLmNvbT4gc2F5czoNCg0KPlRoZSBNR0MgY29udHJvbHMg d2hpY2ggYWRkcmVzcyBhbmQgcG9ydCB0aGUgTUdXIHNlbmRzIGl0cyBOb3RpZnkgdG8sIGluDQp0 aGUNCj5TZXJ2aWNlQ2hhbmdlIHJlcGx5LiAgT2YgY291cnNlLCB0aGlzIGlzIGEgc3RhdGljIGFy cmFuZ2VtZW50LiAgWW91IGNhbg0KZGl2aWRlDQo+dGhpbmdzIHVwIGJ5IHNwbGl0dGluZyB0aGUg TUdXIHVwIGludG8gdmlydHVhbCBtYWNoaW5lcywgYnV0IHllcywgSSBhZ3JlZQ0KdGhhdCB5b3UN Cj5jYW5ub3QgZHluYW1pY2FsbHkgbG9hZHNoYXJlIHRoZSBjb250cm9sIG9mIG9uZSBNR1cgYmV0 d2VlbiB0d28gTUdDcy4NClRoYXQgaXMgYQ0KPmRlbGliZXJhdGUgY29uc3RyYWludCBpbiBNZWdh Y28gYmVjYXVzZSBkeW5hbWljIHNoYXJpbmcgd291bGQgbWVhbiB5b3UNCm5lZWQgc29tZSB3YXkN Cj50byByZXNvbHZlIGNvbnRlbnRpb24gaWYgdHdvIE1HQ3MgdHJ5IHRvIHVzZSB0aGUgc2FtZSBy ZXNvdXJjZXMuDQoNCg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN CiAgICAgICAgICAgICAgICAgICAgQWxla3NhbmRyICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAg IFJ5YWJpbiAgICAgICAgICAgICAgIMrVvP7Iy6O6ICAgICB6aG91LnppY2h1bkB6dGUuY29tLmNu LCAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICA8a2VuZ3JAd2lucGhvciAgICAg ICAgbWVnYWNvQGlldGYub3JnICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg ICAgICAgICAgICAgICAgICAgaWEuY29tPiAgICAgICAgICAgICAgs63LzaO6ICBUb20gVGF5bG9y IDx0YXlsb3JAbm9ydGVsbmV0d29ya3MuY29tPiAgICAgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgINb3zOKjuiAgUmU6IFtNZWdhY29dIEEgcXVlc3Rpb24gYWJvdXQg SC4yNDggb24gICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg U0NUUCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgIDIwMDMt MDYtMjYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAyMzoxNCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KDQoNCg0KDQoNCkhpLA0KDQpJJ20gbm90IGV4YWN0bHkgZm9sbG93aW5nIGhvdyBT Q1RQIGRpZmZlciBmcm9tIFVEUCwgb3IgVENQDQpmb3IgbWVzc2FnZSBkaXN0cmlidXRpb24gcHJv YmxlbSB5b3UgYXJlIHRyeWluZyB0byBzb2x2ZSwNCmJ1dCBpbiBOb3RpZnkgdGhlcmUgaXMgUmVx dWVzdElkZW50aWZpZXIgd2hpY2ggaXMgcHJvdmlkZWQgYnkNCk1HQyAoQSBvciBCKSwgdGh1cyB5 b3UgY2FuIHJvdXRlIChvbiBBKSBiYXNlZCBvbiBpdCwNCnRoYXQgaXMgb2YgY291cnNlIHByb3Zp ZGVkIHlvdSBwYXJzZSB3aG9sZSBtZXNzYWdlIG9uIEEsDQp3aGljaCB5b3UgaGF2ZSB0byBkbyBh bnl3YXkgc2luY2UgYSBtZXNzYWdlIGNhbiBjb250YWluIHNldmVyYWwNCnRyYW5zYWN0aW9ucyB3 aXRoIHRlcm1pbmF0aW9uSWRzICJzZXJ2aWNlZCIgYnkgZGlmZmVyZW50IE1HQ3MNCg0KUmVnYXJk cywNCiAgICAgICAgIEFsZWtzDQoNCkF0IDA0OjI2IEFNIDYvMjYvMjAwMywgemhvdS56aWNodW5A enRlLmNvbS5jbiB3cm90ZToNCg0KPlRvbSwNCj4gICBUaGlzIHJ1bGUgY2FuIGVuc3VyZSBvbmUg c2lkZSBtZXNzYWdlIHNlcXVlbmNlbHkgYXJyaXZlZCBhdCB0aGUgcGVlci4NCkJ1dA0KPm9ubHkg dGhlIG1lc3NhZ2Ugc2VxdWVuY2UgYXNzdXJhbmNlIGlzIG5vdCBlZmZpY2llbnQgaW4gYmlnIHN5 c3RlbXMuIE1heWJlDQo+YmlnIHN5c3RlbSBpcyBuZWdsZWN0ZWQgYnkgTUVHQUNPLiBUaGUgcHJv YmxlbSBpcyB0aGUgYmFsYW5jZSBiZXR3ZWVuDQo+bXVsdGktbWFjaGluZS4gTGV0J3MgY29uc2lk ZXIgdGhlIGZvbGxvd2luZyBleGFtcGxlOg0KPg0KPiAgIE1HQyBoYXMgMiBtYWNoaW5lcyhBLEIp IHRvICBwcm9jZXNzIHRoZSBjb250ZXh0IHRyYW5zYWN0aW9ucyBmb3Igb25lDQpNR1cuDQo+U2lu Y2UgU0NUUCBjYW5uJ3QgcHJvdmlkZSBvbmUgYXNzb2NpYXRpb24gb24gZGlmZmVyZW50IG1hY2hp bmVzLiBTbyB0aGVyZQ0KPmFyZSBhdCBsZWFzdCB0d28gYXNzb2NpYXRpb24gb24gbWFjaGluZSBB IGFuZCBCLiBXaGVuIGEgY29udGV4dCBuZWVkIHRvIGJlDQo+ZXN0YWJsaXNoZWQsIHRoZSBNR0Mg c2VuZCB0cmFuc2FjdGlvbnMgdG8gTUdXIHRocm91Z2ggYXNzb2NpYXRpb24gYXQNCj5tYWNoaW5l IEEuIEJ1dCB0aGUgTUdXIG1heSBzZW5kIE5PVElGWSB0cmFuc2FjdGlvbnMgdG8gTVNDIHRocm91 Z2gNCj5hc3NvY2lhdGlvbiBhdCBtYWNoaW5lIEIuIFNvIG1hY2hpbmUgQiBoYXZlIHRvIHNlbmQg dGhpcyBtZXNzYWdlIHRvDQptYWNoaW5lDQo+QS4gV2hlbiBNR0MgaGF2ZSBtb3JlIG1hY2hpbmVz LCB0aGUgbWVzc2FnZSBkaXN0cmlidXRpb24gaXMgYSBtZXNzLg0KPg0KPiAgIEluIHRoZSBURE0g Y2FsbCBwcm9jZXNzLCBJVFUgZGVmaW5lcyBDSUMgbnVtYmVyIGZvciBUVVAvSVNVUCBwcm9jZXNz aW5nDQo+cGFpci4gU2luY2UgZXZlcnkgY2FsbCBpcyBjb21iaW5lZCB3aXRoIGEgQ0lDIG51bWJl ciwgZXZlcnkgVFVQL0lTVVAgY2FsbA0KPm1lc3NhZ2UgYmluZyBhIENJQywgaXQncyBlYXN5IHRv IGxldCBwcm9jZXNzIHBlZXJzIHRvIGZpbmQgdGhlIGNhbGwNCnByb2Nlc3MNCj5tYWNoaW5lLiBB bHNvIHRoZSBCSUNDIHByb3RvY29sIGFkb3B0IHRoZSBDSUMgdG8gaWRlbnRpZnkgY2FsbCBlbnRp eQ0KPmJldHdlZW4gQklDQyBwYWlyLg0KPg0KPiAgIEl0J3MgYSBwaXR0eSB0aGVyZSBpcyBubyBz aW1pbGFyIHdheSBpbiBNRUdBQ08uIFRob3VnaCBNRUdBQ08gcHJvdmlkZQ0KPkNPTlRFWFRJRCBi ZXR3ZWVuIE1HVy9NU0MsIGJ1dCB1bmZvcnR1bmF0ZWx5LCB0aGUgQ09OVEVYVElEIGlzIGR5bmFt aWNsbHkNCj5hbGxvY2F0ZWQgYnkgTUdXIGR1cmluZyB0aGUgY2FsbC4gSWYgdGhlIE1HVyBpcyBz bWFsbCwgdGhlcmUgaXMgbm8NCnByb2JsZW0sDQo+YmVjYXVzZSBhbGwgdGhlIENPTlRFWFQgaXMg cHJvY2Vzc2VkIGJ5IG9uZSBtYWNoaW5lLiBXaGVuIHRoZSBNR1cgaXMgaHVnZSwNCj50aGUgaW5j b21pbmcgTUVHQUNPIG1lc3NhZ2UgZGlzdHJpYnV0aW9uIGlzIGEgcHJvYmxlbSwgdGhlIE1FR0FD TyBiZWFyZXINCj5sYXllciBjb3VsZG4ndCBkZWNpZGUgd2hpY2ggcHJvY2VzcyBtYWNoaW5lIHNo b3VsZCBnZXQgdGhpcyBtZXNzYWdlLA0KdW5saWtlDQo+VFVQL0lTVVAsIHRoZSBNVFAzIGNhbiBm aW5kIHRoZSBwcm9jZXNzIG1hY2hpbmUgYnkgQ0lDLiBPbmx5IGFmdGVyIEguMjQ4DQo+ZGVjb2Rl IHRoZSBtZXNzYWdlLCBpdCBjb3VsZCBmaW5kIHRoZSBwcm9jZXNzIG1hY2hpbmUgaW4gYSBtZXNz Lg0KPg0KPiAgIElmIHdlIGFkZCBzaW1pbGFyIHJ1bGVzIGxpa2UgVFVQL0lTVVAsIHdlIHdpbGwg c29sdmUgdGhlc2UgcHJvYmxlbS4gSQ0KPnN1cHBvc2UgdGhlIHJ1bGUgaXM6DQo+DQo+ICAgMS4g IkguMjQ4IGNhbGwgQ09OVEVYVElEIGlzIHByZWRlZmluZWQgYmV0d2VlbiBNR0MgYW5kIE1HVy4g TUdDIGdldCBhDQo+Q09OVEVYVElEIHdoZW4gYSBjYWxsIHNob3VsZCBiZSBpbml0aWF0ZWQuIE1H VyBkZWNpZGUgd2hldGhlciB0aGUgQ09OVEVYVA0KPmV4aXN0IG9yIG5vdCwgaWYgZG9zbid0IGV4 aXN0IGl0IGNyZWF0ZSBhIGNvbnRleHQgd2l0aCB0aGlzIENPTlRFWFRJRC4iDQo+VGhpcyBydWxl IGlzIGZvciBtdWx0aS1tYWNoaW5lIGNhbGwgbG9hZCBiYWxhbmNlLCBhbmQgZm9yIHRyYW5zcG9y dCBsYXllcg0KPmVhc3kgZmluZGluZyBwcm9jZXNzIG1hY2hpbmUsIGp1c3QgbGlrZSBvdGhlciBj YWxsIHJlbGF0ZWQgcHJvdG9jb2wNCj5UVVAvSVNVUC9CSUNDLg0KPg0KPiAgIDIuIk1HQy9NR1cg U0hPVUxEIHNlbGVjdCB0cmFuc3BvcnQgbGF5ZXIgbGlua3Moc3VjaCBhcyBNVFAzQiBsaW5rcywN Ck0zVUENCj5BU1BzIGFuZCBzdHJlYW1zLCBTQ1RQIGFzc29jaWF0aW9ucyBhbmQgc3RyZWFtcywg VENQIGxpbmtzLCBVRFAgcG9ydHMsDQpldGMpDQo+YnkgQ09OVEVYVElEIGxvd2VzdCA0IGJpdHMu IiBUaGlzIHJ1bGUgaXMgZm9yIHRyYW5zYWN0aW9uIHNlcXVlbmNlcyBiZWxvbmcNCj5vbmUgY29u dGV4dCwgYWxzbyB0aGUgbG9hZCBiYWxhbmNlIG9mIHRyYW5zcG9ydCBsYXllciBsaW5rcy4NCj4N Cj4gICBCZXN0IHJlZ2FyZHMuDQo+DQo+ICAgWmljaHVuDQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+ DQo+ICAgICAgICAgICAgICAgICAgICAgVG9tDQo+IFRheWxvcg0KPiAgICAgICAgICAgICAgICAg ICAgIDx0YXlsb3JAbm9ydGVsbmV0ICAgICAgIMrVvP7Iy6O6DQo+IHpob3UuemljaHVuQHp0ZS5j b20uY24NCj4gICAgICAgICAgICAgICAgICAgICB3b3Jrcy5jb20+ICAgICAgICAgICAgICCzrcvN o7ogIG1lZ2Fjb0BpZXRmLm9yZw0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgINb3zOKjuiAgUmU6IFtNZWdhY29dIEENCj4gcXVlc3Rpb24gYWJvdXQgSC4y NDggb24NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU0NU UA0KPg0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgIDIwMDMtMDYtMjYNCj4gMDE6MTkNCj4N Cj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj5JdCByZWFsbHkgZG9lc24ndCBtYXR0ZXIgd2hpY2gg c3RyZWFtIGVhY2ggZW5kIHVzZXMsIHNvIGxvbmcgYXMgb25lIGVuZA0KPnVzZXMgdGhlDQo+c2Ft ZSBzdHJlYW0gZm9yIGFsbCBtZXNzYWdlcyByZWxhdGluZyB0byBhIGdpdmVuIGNvbnRleHQuICBU aGUgcmVhc29uIGZvcg0KPnRoaXMgcnVsZQ0KPmlzIHRvIGVuc3VyZSB0aGF0IG1lc3NhZ2VzIGFy cml2ZSBpbiBvcmRlciBhdCB0aGUgcGVlci4NCj4NCj56aG91LnppY2h1bkB6dGUuY29tLmNuIHdy b3RlOg0KPg0KPiA+IEhpLA0KPiA+ICAgSC4yNDguNCAoQW5uZXggSCkgZ2l2ZXMgU0NUUCB0byB0 cmFuc3BvcnQgSC4yNDggdHJhbnNhY3Rpb25zLiBUaGUNCnBhcGVyDQo+ID4gc2F5czogSXQgaXMg cmVjb21tZW5kZWQgdGhhdCB0cmFuc2FjdGlvbnMgcmVsYXRlZCB0byBvbmUgY29udGV4dCBhcmUN Cj4gPiB0cmFuc3BvcnRlZCBvdmVyIHRoZSBzYW1lIHN0cmVhbS4gU0NUUCB0cmFuc21pdHMgbWVz c2FnZXMgYW5kIHByb2Nlc3Nlcw0KPiA+IHJlY2VpdmVkIG1lc3NhZ2VzIGluIG9uZSBzdHJlYW0u DQo+ID4NCj4gPiAgIFdoZW4gTUdDIGFuZCBNRyBleGNoYW5nZSBpbmZvcm1hdGlvbnMuIFRoZSBN Ry9NR0MgbWF5YmUgZ2V0IGNvbnRleHRfQQ0KPiA+IG1lc3NhZ2VzIGZyb20gaW5ib3VuZCBzdHJl YW1fMSwgYnV0IHNlbmQgb3V0IGNvbnRleHRfQSBtZXNzYWdlcyBmcm9tDQo+aW5ib3VkDQo+ID4g c3RyZWFtXzIsIHRoZSBwYXBlciBkaWRuJ3QgdGVsbCB1cyB0aGUgc3RyZWFtcyBNVVNUIGJlIHVz ZWQgYXMgcGFpcnM6DQo+ID4gaW5ib3VkIHN0cmVhbV8xIHNvIG91dGJvdW5kIHN0cmVhbV8xLg0K PiA+DQo+ID4gICBBbmQgdGhlcmUgbWF5YmUgY29leGlzdCBtb3JlIHRoYW4gb25lIFNDVFAgYXNz b2NpYXRpb25zIGJldHdlZW4NCj5NR0MvTUdXLg0KPiA+IFRoZSBNRy9NR0MgbWF5YmUgZ2V0IGNv bnRleF9BIG1lc3NhZ2VzIGZyb20gb25lIGFzc29jaWF0aW9uIGFuZCByZXNwb25kDQo+dGhlDQo+ ID4gcmVwbHkgaW4gYW5vdGhlciBhc3NvY2lhdGlvbi4gVGhlIHBhcGVyIGRpbid0IHRlbGwgdXMg TVVTVCB1c2Ugb25lDQo+ID4gYXNzb2NpYXRpb24gdG8gcHJvY2VzcyBvbmUgY29udGV4dC4NCj4g Pg0KPiA+ICAgVGhlIHVwcGVyIG1lY2hhbmlzbSBpcyBkaWZmZXJlbnQgZnJvbSBUVVAvSVNVUCBj YWxsIHByb2Nlc3MuIFRoZQ0KTUdDL01HDQo+ID4gY291bGRuJ3QgYW50aWNpcGF0ZSB0aGUgSC4y NDggY29tbXVuaWNhdGlvbiBwYXJ0bmVyIHJlcGx5IHRoZSBjYWxsDQo+Y29udGV4dA0KPiA+IG1l c3NhZ2UgaW4gd2hpY2ggYXNzb2NpYXRpb24gb3Igc3RyZWFtLiBJZiB0aGUgTUdDIGluaXRpYXRl IGEgY29udGV4dA0KaW4NCj4gPiBvbmUgYXNzb2NpYXRpb24gLGJ1dCByZWNlaXZlZCByZXBseSBp biBhbm90aGVyIGFzc29jaWF0aW9uLCBNR0MgaGF2ZSB0bw0KPiA+IGZvcndhcmQgdGhlIG1lc3Nh Z2UgdG8gdGhlIGluaXRpYXRlZCBwbGFjZS4gRG9lc24ndCBpdCBsb29rcyBzdHJhbmdlPw0KPk1h eWJlDQo+ID4gdSBoYXZlIGZ1cnRoZXIgc3VnZ2VzdGlvbiBhYm91dCB0aGlzIHF1ZXN0aW9uLg0K PiA+DQo+ID4gICBUaGFua3MuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gTWVnYWNvIG1haWxp bmcgbGlzdA0KPiA+IE1lZ2Fjb0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21lZ2Fjbw0KPiA+DQo+DQo+DQo+DQo+Z2FnYWdhZ2Fjbw0KPiA+DQo+ DQo+DQo+DQo+ICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXMx6HKJmopYp4JYrLQ/ DQo+IGk/etform22mz8/MD+tforg/mairWan/listinfo/megacoDQoNCg0KDQo= _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Sun Jun 29 22:24:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14046 for ; Sun, 29 Jun 2003 22:24:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WoKn-0000i3-Jw; Sun, 29 Jun 2003 22:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WnCV-0006dP-4g for megaco@optimus.ietf.org; Sun, 29 Jun 2003 21:11:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12325 for ; Sun, 29 Jun 2003 21:11:06 -0400 (EDT) From: zhou.zichun@zte.com.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WnCD-0001Hb-00 for megaco@ietf.org; Sun, 29 Jun 2003 21:11:05 -0400 Received: from [211.96.102.115] (helo=zte.com.cn) by ietf-mx with esmtp (Exim 4.12) id 19WnC2-0001H0-00 for megaco@ietf.org; Sun, 29 Jun 2003 21:10:55 -0400 To: megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Mon, 30 Jun 2003 09:07:09 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.8 |June 18, 2001) at 2003-06-30 09:11:33 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] MG capacity must be small? Sender: megaco-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 all, H.248 entity indicate it's transport address in ServiceChange command. Give an TCP transport example, the transport is an IP+PORT pair. So there only exist one TCP transport connection for a MG+MGC pair. Here now the CPU processor is limited, so we can conclude the MG+MGC transaction capacity cann't exeed the TCP transport capacity, so the MG capacity couldn't be very high. I want to see whether H.248 could support huge MG. Could there exist more than one transport connection between one MG+MGC pair? Maybe the transport on TCP/SCTP/MTP3B/etc. is not different. Regards, Zichun _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Sun Jun 29 22:24:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14047 for ; Sun, 29 Jun 2003 22:24:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WoKn-0000ht-2w; Sun, 29 Jun 2003 22:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VucZ-0002P9-Nx for megaco@optimus.ietf.org; Fri, 27 Jun 2003 10:55:44 -0400 Received: from zte.com.cn ([211.96.102.115]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20062 for ; Fri, 27 Jun 2003 03:59:07 -0400 (EDT) From: zhou.zichun@zte.com.cn Subject: Re: Re: [Megaco] A question about H.248 on SCTP To: Aleksandr Ryabin Cc: megaco@ietf.org, Tom Taylor , zhou.zichun@zte.com.cn X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Fri, 27 Jun 2003 10:50:17 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.8 |June 18, 2001) at 2003-06-27 15:59:57 MIME-Version: 1.0 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 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 DQpIaSxhbGwNCiAgIEFzIFRvbSBzYWlkLEkgYWdyZWUgd2UgY2FuIHNwbGl0IGEgTUdXIGludG8g c2V2ZXJhbCB2aXJ0dWFsIE1HV3MgdG8NCnNvbHZlIGh1Z2UgTUdXIHByb2JsZW0uDQogICBBcyBB bGVrcyBzYWlkLCBJIGFncmVlIHRoZSB0cmFuc3BvcnQgY29ubmVjdGlvbiB0eXBlIG9mDQpUQ1Av VURQL1NDVFAvTVRQM0IvTTNVQSBhcmUgb2Ygbm8gZGlmZmVyZW5jZS4NCiAgIE1heWJlIG1heSBx dWVzdGlvbiBzaG91bGQgYmUgcmVuYW1lZCB0byBIb3cgSC4yNDggYmUgdXNlZCBpbiBiaWcgc3lz dGVtLA0Kbm90IG9ubHkgYWJvdXQgU0NUUCB0cmFuc3BvcnQgY29ubmVjdGlvbnMuDQogICBUaGUg cHJvYmxlbSBpczogaG93IG1hbnkgdHJhbnNwb3J0IGNvbm5lY3Rpb24gc2hvdWxkIGV4aXN0IGJl d3RlZW4gYQ0KcGFpciBNR0MtTUdXPyBUaGUgTUdDJ3Mgc2VydmljZWNoYW5nZSB0cmFuc2FjdGlv biBjYW4gcHJvdmlkZSBvbmx5IG9uZQ0KSVArUE9SVChldGMuKSBpbmRpY2F0aW9uLiBJZiB0aGUg YW5zd2VyIGlzIG9ubHkgb25lIGNvbm5lY3Rpb24gc3VjaCBhcw0KVENQL1NDVFAgY291bGQgZXhp c3QgYmV0d2VlbiBNR0MtTUdXIHBhaXIsIHNpbmNlIGhhcmR3YXJlIGNhcGFjaXR5IGlzDQpsaW1p dGVkIG9uZSBjb25uZWN0aW9uIGNhbiBwcm92aWRlIGxpbWl0ZWQgSC4yNDggdHJhbnNhY3Rpb24g ZGVsaXZlcnkNCmFiaWxpdHkuIEluIDNHUFAgd2hlbiB3ZSBkZXNpZ24gYmlnIE1HVyBzeXN0ZW0s IG9uZSBjb25uZWN0aW9uIGNhcGFjaXR5IGlzDQpub3QgZWZmaWNpZW50LiBPbmUgd29yZCwgbXVz dCB3ZSBzcGxpdCB0aGUgTUdXIGludG8gc2V2ZXJhbCBsaXR0bGUgc3lzdGVtcw0KdG8gcHJvdmlk ZSBzZXZlcmFsIGxvZ2ljYWwgaW50ZXJmYWNlIHRvIE1HQz8gSSB0aGluayBJdCdzIGluY29udmVu aWVudCBmb3INCnN5c3RlbSBtYWludGVuYW5jZSBhbmQgZXZvbHZlbWVudC4NCiAgIEkgdGhpbmsg QWxla3MgYW5kIFRvbSBkaWRuJ3QgcmVjb2duaXplIG15IHRydWUgaWRlYS4gSW4gbXkgYmVmb3Jl DQpzY2VuYXJpbyAsdGhlIE1HQyBoYXMgMiBtYWNoaW5lcyhwcm9jZXNzb3IpIHRvIHByb2Nlc3Mg b25lIE1HVywgdGhlc2UgMg0KbWFjaGluZXMgYmVsb25nIHRvIE9ORSBNR0MsIG1heWJlIHRoZXJl IGFyZSBtb3JlIHRoYW4gb25lIG1hY2hpbmUgb24gTUdXDQp0b28sIG5vdCBpbiBvdXIgc2lnaHQu IFdoZW4gMiBvciBtb3JlIHBvcmNlc3NvciBleGlzdGVkIHRoZSBwcm9jZXNzb3INCmlkZW50aWZ5 IGlzIGEgcHJvYmxlbS4gQXMgQWxla3Mgc2FpZCB3ZSBjYW4gcGFyc2UgdGhlIFJlcXVlc3RJZGVu dGlmaWVyIHRvDQppZGVudGlmeSB0aGUgcHJvY2Vzc29yLCBidXQgZG9uJ3QgdSB0aGluayBpdCB3 YXN0ZSBhIGxvdCB0aW1lLCBhbmQgdGhpcw0KbWV0aG9kIGNhbm4ndCBsZXQgTUdDIHByb2Nlc3Mg dGhlIGNhbGxpbmcgc3RhdGUgdGVybWluYXRpb24gb3V0IG9mIHNlcnZpY2UNClNlcnZpY2VDaGFu Z2UgdHJhbnNhY3Rpb25zLiBJIGluc2lzdCBwcmVkZWZpbmVkIENPTlRFWFRJRCBiZXR3ZWVuIE1H Qy1NR1cNCmlzIGEgYmV0dGVyIHdheSB0byBzb2x2ZSB0aGlzIHByb2JsZW0uIE9yIE1FR0FDTyBk ZWZpbmUgdGhpczoiIENPTlRFWFRJRCBpcw0KcHJlZGVmaW5lZCBvbiBNR1csIE1HQyBjYW4gYXVk aXQgQ09OVEVYVElEIGZyb20gTUdXIGFmdGVyIE1HVyByZWdpc3RlcmluZyIuDQpXZSBjYW4gZ2V0 IENPTlRFWFRJRCB3aXRoIGZldyBwYXJzaW5nIHN0ZXBzLiBPZiBjb3Vyc2Ugd2UgbXVzdCBkZWFs IHdpdGgNCm11bHRpLXRyYW5zYWN0aW9ucyBpbiBvbmUgbWVzc2FnZSwgdGhpcyBpcyBhIGVhc2ll ciBzY2FubmluZyB3b3JrIGNvbXBhcmUNCndpdGggd29yZCB0byB3b3JkIHBhcnNpbmcuDQoNCiAg IEkgZGlkbid0IHRoaW5rIHR3byBNR0NzIGNhbiBvcGVyYXRlIG9uZSBNR1csIGEgbG9naWMgTUdX IHNob3VsZCBiZWxvbmcNCnRvIG9uZSBNR0MuIEFzIE1FR0FDTyBkZWZpbml0aW9uIHRoZSBDT05U RVhUSUQgaXMgdmFsaWQgYmV0d2VlbiBhIE1HQy1NR1cNCnBhaXIsIHNvIHRoZSBDT05URVhUSUQg c2VsZWN0ZWQgYnkgTUdDIGlzIHBvc3NpYmxlLiBUaGUgYmlnIGFkdmFudGFnZSBvZg0KdGhpcyBy dWxlIGlzIGxldCBILjI0OCAgYWN0IGxpa2UgYSBjYWxsIHJlbGF0ZWQgcHJvdG9jb2wgbW9yZS4N CiAgIEknbSBjb25mdXNlZCBieSBBbGVrcydzIHdvcmRzOiAiYSBtZXNzYWdlIGNhbiBjb250YWlu IHNldmVyYWwNCnRyYW5zYWN0aW9ucyB3aXRoIHRlcm1pbmF0aW9uSWRzICdzZXJ2aWNlZCcgYnkg ZGlmZmVyZW50IE1HQ3MiLiBJIHRoaW5rDQp0aGlzIGNvdWxkbid0IGhhcHBlbiBiZWNhdXNlIHRo ZXJlIHNob3VsZCBiZSBkaWZmZW50IHRyYW5zcG9ydCBjb25uZWN0aW9ucw0KZnJvbSBkaWZmZXJl bnQgTUdDcyB0byBhIHBoeXNpY2FsIE1HVyh0aGlzIE1HVyB3YXMgc3BsaXR0ZWQgdG8gZGlmZmVy ZW50DQpNR1dzKS4NCg0KICAgQmVzdCByZWdhcmRzLA0KICAgWmljaHVuDQoNCg0KVG9tIFRheWxv ciA8dGF5bG9yQG5vcnRlbG5ldHdvcmtzLmNvbT4gc2F5czoNCg0KPlRoZSBNR0MgY29udHJvbHMg d2hpY2ggYWRkcmVzcyBhbmQgcG9ydCB0aGUgTUdXIHNlbmRzIGl0cyBOb3RpZnkgdG8sIGluDQp0 aGUNCj5TZXJ2aWNlQ2hhbmdlIHJlcGx5LiAgT2YgY291cnNlLCB0aGlzIGlzIGEgc3RhdGljIGFy cmFuZ2VtZW50LiAgWW91IGNhbg0KZGl2aWRlDQo+dGhpbmdzIHVwIGJ5IHNwbGl0dGluZyB0aGUg TUdXIHVwIGludG8gdmlydHVhbCBtYWNoaW5lcywgYnV0IHllcywgSSBhZ3JlZQ0KdGhhdCB5b3UN Cj5jYW5ub3QgZHluYW1pY2FsbHkgbG9hZHNoYXJlIHRoZSBjb250cm9sIG9mIG9uZSBNR1cgYmV0 d2VlbiB0d28gTUdDcy4NClRoYXQgaXMgYQ0KPmRlbGliZXJhdGUgY29uc3RyYWludCBpbiBNZWdh Y28gYmVjYXVzZSBkeW5hbWljIHNoYXJpbmcgd291bGQgbWVhbiB5b3UNCm5lZWQgc29tZSB3YXkN Cj50byByZXNvbHZlIGNvbnRlbnRpb24gaWYgdHdvIE1HQ3MgdHJ5IHRvIHVzZSB0aGUgc2FtZSBy ZXNvdXJjZXMuDQoNCg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN CiAgICAgICAgICAgICAgICAgICAgQWxla3NhbmRyICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAg IFJ5YWJpbiAgICAgICAgICAgICAgIMrVvP7Iy6O6ICAgICB6aG91LnppY2h1bkB6dGUuY29tLmNu LCAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICA8a2VuZ3JAd2lucGhvciAgICAg ICAgbWVnYWNvQGlldGYub3JnICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg ICAgICAgICAgICAgICAgICAgaWEuY29tPiAgICAgICAgICAgICAgs63LzaO6ICBUb20gVGF5bG9y IDx0YXlsb3JAbm9ydGVsbmV0d29ya3MuY29tPiAgICAgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgINb3zOKjuiAgUmU6IFtNZWdhY29dIEEgcXVlc3Rpb24gYWJvdXQg SC4yNDggb24gICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg U0NUUCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgIDIwMDMt MDYtMjYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAyMzoxNCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KDQoNCg0KDQoNCkhpLA0KDQpJJ20gbm90IGV4YWN0bHkgZm9sbG93aW5nIGhvdyBT Q1RQIGRpZmZlciBmcm9tIFVEUCwgb3IgVENQDQpmb3IgbWVzc2FnZSBkaXN0cmlidXRpb24gcHJv YmxlbSB5b3UgYXJlIHRyeWluZyB0byBzb2x2ZSwNCmJ1dCBpbiBOb3RpZnkgdGhlcmUgaXMgUmVx dWVzdElkZW50aWZpZXIgd2hpY2ggaXMgcHJvdmlkZWQgYnkNCk1HQyAoQSBvciBCKSwgdGh1cyB5 b3UgY2FuIHJvdXRlIChvbiBBKSBiYXNlZCBvbiBpdCwNCnRoYXQgaXMgb2YgY291cnNlIHByb3Zp ZGVkIHlvdSBwYXJzZSB3aG9sZSBtZXNzYWdlIG9uIEEsDQp3aGljaCB5b3UgaGF2ZSB0byBkbyBh bnl3YXkgc2luY2UgYSBtZXNzYWdlIGNhbiBjb250YWluIHNldmVyYWwNCnRyYW5zYWN0aW9ucyB3 aXRoIHRlcm1pbmF0aW9uSWRzICJzZXJ2aWNlZCIgYnkgZGlmZmVyZW50IE1HQ3MNCg0KUmVnYXJk cywNCiAgICAgICAgIEFsZWtzDQoNCkF0IDA0OjI2IEFNIDYvMjYvMjAwMywgemhvdS56aWNodW5A enRlLmNvbS5jbiB3cm90ZToNCg0KPlRvbSwNCj4gICBUaGlzIHJ1bGUgY2FuIGVuc3VyZSBvbmUg c2lkZSBtZXNzYWdlIHNlcXVlbmNlbHkgYXJyaXZlZCBhdCB0aGUgcGVlci4NCkJ1dA0KPm9ubHkg dGhlIG1lc3NhZ2Ugc2VxdWVuY2UgYXNzdXJhbmNlIGlzIG5vdCBlZmZpY2llbnQgaW4gYmlnIHN5 c3RlbXMuIE1heWJlDQo+YmlnIHN5c3RlbSBpcyBuZWdsZWN0ZWQgYnkgTUVHQUNPLiBUaGUgcHJv YmxlbSBpcyB0aGUgYmFsYW5jZSBiZXR3ZWVuDQo+bXVsdGktbWFjaGluZS4gTGV0J3MgY29uc2lk ZXIgdGhlIGZvbGxvd2luZyBleGFtcGxlOg0KPg0KPiAgIE1HQyBoYXMgMiBtYWNoaW5lcyhBLEIp IHRvICBwcm9jZXNzIHRoZSBjb250ZXh0IHRyYW5zYWN0aW9ucyBmb3Igb25lDQpNR1cuDQo+U2lu Y2UgU0NUUCBjYW5uJ3QgcHJvdmlkZSBvbmUgYXNzb2NpYXRpb24gb24gZGlmZmVyZW50IG1hY2hp bmVzLiBTbyB0aGVyZQ0KPmFyZSBhdCBsZWFzdCB0d28gYXNzb2NpYXRpb24gb24gbWFjaGluZSBB IGFuZCBCLiBXaGVuIGEgY29udGV4dCBuZWVkIHRvIGJlDQo+ZXN0YWJsaXNoZWQsIHRoZSBNR0Mg c2VuZCB0cmFuc2FjdGlvbnMgdG8gTUdXIHRocm91Z2ggYXNzb2NpYXRpb24gYXQNCj5tYWNoaW5l IEEuIEJ1dCB0aGUgTUdXIG1heSBzZW5kIE5PVElGWSB0cmFuc2FjdGlvbnMgdG8gTVNDIHRocm91 Z2gNCj5hc3NvY2lhdGlvbiBhdCBtYWNoaW5lIEIuIFNvIG1hY2hpbmUgQiBoYXZlIHRvIHNlbmQg dGhpcyBtZXNzYWdlIHRvDQptYWNoaW5lDQo+QS4gV2hlbiBNR0MgaGF2ZSBtb3JlIG1hY2hpbmVz LCB0aGUgbWVzc2FnZSBkaXN0cmlidXRpb24gaXMgYSBtZXNzLg0KPg0KPiAgIEluIHRoZSBURE0g Y2FsbCBwcm9jZXNzLCBJVFUgZGVmaW5lcyBDSUMgbnVtYmVyIGZvciBUVVAvSVNVUCBwcm9jZXNz aW5nDQo+cGFpci4gU2luY2UgZXZlcnkgY2FsbCBpcyBjb21iaW5lZCB3aXRoIGEgQ0lDIG51bWJl ciwgZXZlcnkgVFVQL0lTVVAgY2FsbA0KPm1lc3NhZ2UgYmluZyBhIENJQywgaXQncyBlYXN5IHRv IGxldCBwcm9jZXNzIHBlZXJzIHRvIGZpbmQgdGhlIGNhbGwNCnByb2Nlc3MNCj5tYWNoaW5lLiBB bHNvIHRoZSBCSUNDIHByb3RvY29sIGFkb3B0IHRoZSBDSUMgdG8gaWRlbnRpZnkgY2FsbCBlbnRp eQ0KPmJldHdlZW4gQklDQyBwYWlyLg0KPg0KPiAgIEl0J3MgYSBwaXR0eSB0aGVyZSBpcyBubyBz aW1pbGFyIHdheSBpbiBNRUdBQ08uIFRob3VnaCBNRUdBQ08gcHJvdmlkZQ0KPkNPTlRFWFRJRCBi ZXR3ZWVuIE1HVy9NU0MsIGJ1dCB1bmZvcnR1bmF0ZWx5LCB0aGUgQ09OVEVYVElEIGlzIGR5bmFt aWNsbHkNCj5hbGxvY2F0ZWQgYnkgTUdXIGR1cmluZyB0aGUgY2FsbC4gSWYgdGhlIE1HVyBpcyBz bWFsbCwgdGhlcmUgaXMgbm8NCnByb2JsZW0sDQo+YmVjYXVzZSBhbGwgdGhlIENPTlRFWFQgaXMg cHJvY2Vzc2VkIGJ5IG9uZSBtYWNoaW5lLiBXaGVuIHRoZSBNR1cgaXMgaHVnZSwNCj50aGUgaW5j b21pbmcgTUVHQUNPIG1lc3NhZ2UgZGlzdHJpYnV0aW9uIGlzIGEgcHJvYmxlbSwgdGhlIE1FR0FD TyBiZWFyZXINCj5sYXllciBjb3VsZG4ndCBkZWNpZGUgd2hpY2ggcHJvY2VzcyBtYWNoaW5lIHNo b3VsZCBnZXQgdGhpcyBtZXNzYWdlLA0KdW5saWtlDQo+VFVQL0lTVVAsIHRoZSBNVFAzIGNhbiBm aW5kIHRoZSBwcm9jZXNzIG1hY2hpbmUgYnkgQ0lDLiBPbmx5IGFmdGVyIEguMjQ4DQo+ZGVjb2Rl IHRoZSBtZXNzYWdlLCBpdCBjb3VsZCBmaW5kIHRoZSBwcm9jZXNzIG1hY2hpbmUgaW4gYSBtZXNz Lg0KPg0KPiAgIElmIHdlIGFkZCBzaW1pbGFyIHJ1bGVzIGxpa2UgVFVQL0lTVVAsIHdlIHdpbGwg c29sdmUgdGhlc2UgcHJvYmxlbS4gSQ0KPnN1cHBvc2UgdGhlIHJ1bGUgaXM6DQo+DQo+ICAgMS4g IkguMjQ4IGNhbGwgQ09OVEVYVElEIGlzIHByZWRlZmluZWQgYmV0d2VlbiBNR0MgYW5kIE1HVy4g TUdDIGdldCBhDQo+Q09OVEVYVElEIHdoZW4gYSBjYWxsIHNob3VsZCBiZSBpbml0aWF0ZWQuIE1H VyBkZWNpZGUgd2hldGhlciB0aGUgQ09OVEVYVA0KPmV4aXN0IG9yIG5vdCwgaWYgZG9zbid0IGV4 aXN0IGl0IGNyZWF0ZSBhIGNvbnRleHQgd2l0aCB0aGlzIENPTlRFWFRJRC4iDQo+VGhpcyBydWxl IGlzIGZvciBtdWx0aS1tYWNoaW5lIGNhbGwgbG9hZCBiYWxhbmNlLCBhbmQgZm9yIHRyYW5zcG9y dCBsYXllcg0KPmVhc3kgZmluZGluZyBwcm9jZXNzIG1hY2hpbmUsIGp1c3QgbGlrZSBvdGhlciBj YWxsIHJlbGF0ZWQgcHJvdG9jb2wNCj5UVVAvSVNVUC9CSUNDLg0KPg0KPiAgIDIuIk1HQy9NR1cg U0hPVUxEIHNlbGVjdCB0cmFuc3BvcnQgbGF5ZXIgbGlua3Moc3VjaCBhcyBNVFAzQiBsaW5rcywN Ck0zVUENCj5BU1BzIGFuZCBzdHJlYW1zLCBTQ1RQIGFzc29jaWF0aW9ucyBhbmQgc3RyZWFtcywg VENQIGxpbmtzLCBVRFAgcG9ydHMsDQpldGMpDQo+YnkgQ09OVEVYVElEIGxvd2VzdCA0IGJpdHMu IiBUaGlzIHJ1bGUgaXMgZm9yIHRyYW5zYWN0aW9uIHNlcXVlbmNlcyBiZWxvbmcNCj5vbmUgY29u dGV4dCwgYWxzbyB0aGUgbG9hZCBiYWxhbmNlIG9mIHRyYW5zcG9ydCBsYXllciBsaW5rcy4NCj4N Cj4gICBCZXN0IHJlZ2FyZHMuDQo+DQo+ICAgWmljaHVuDQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+ DQo+ICAgICAgICAgICAgICAgICAgICAgVG9tDQo+IFRheWxvcg0KPiAgICAgICAgICAgICAgICAg ICAgIDx0YXlsb3JAbm9ydGVsbmV0ICAgICAgIMrVvP7Iy6O6DQo+IHpob3UuemljaHVuQHp0ZS5j b20uY24NCj4gICAgICAgICAgICAgICAgICAgICB3b3Jrcy5jb20+ICAgICAgICAgICAgICCzrcvN o7ogIG1lZ2Fjb0BpZXRmLm9yZw0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgINb3zOKjuiAgUmU6IFtNZWdhY29dIEENCj4gcXVlc3Rpb24gYWJvdXQgSC4y NDggb24NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU0NU UA0KPg0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgIDIwMDMtMDYtMjYNCj4gMDE6MTkNCj4N Cj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj5JdCByZWFsbHkgZG9lc24ndCBtYXR0ZXIgd2hpY2gg c3RyZWFtIGVhY2ggZW5kIHVzZXMsIHNvIGxvbmcgYXMgb25lIGVuZA0KPnVzZXMgdGhlDQo+c2Ft ZSBzdHJlYW0gZm9yIGFsbCBtZXNzYWdlcyByZWxhdGluZyB0byBhIGdpdmVuIGNvbnRleHQuICBU aGUgcmVhc29uIGZvcg0KPnRoaXMgcnVsZQ0KPmlzIHRvIGVuc3VyZSB0aGF0IG1lc3NhZ2VzIGFy cml2ZSBpbiBvcmRlciBhdCB0aGUgcGVlci4NCj4NCj56aG91LnppY2h1bkB6dGUuY29tLmNuIHdy b3RlOg0KPg0KPiA+IEhpLA0KPiA+ICAgSC4yNDguNCAoQW5uZXggSCkgZ2l2ZXMgU0NUUCB0byB0 cmFuc3BvcnQgSC4yNDggdHJhbnNhY3Rpb25zLiBUaGUNCnBhcGVyDQo+ID4gc2F5czogSXQgaXMg cmVjb21tZW5kZWQgdGhhdCB0cmFuc2FjdGlvbnMgcmVsYXRlZCB0byBvbmUgY29udGV4dCBhcmUN Cj4gPiB0cmFuc3BvcnRlZCBvdmVyIHRoZSBzYW1lIHN0cmVhbS4gU0NUUCB0cmFuc21pdHMgbWVz c2FnZXMgYW5kIHByb2Nlc3Nlcw0KPiA+IHJlY2VpdmVkIG1lc3NhZ2VzIGluIG9uZSBzdHJlYW0u DQo+ID4NCj4gPiAgIFdoZW4gTUdDIGFuZCBNRyBleGNoYW5nZSBpbmZvcm1hdGlvbnMuIFRoZSBN Ry9NR0MgbWF5YmUgZ2V0IGNvbnRleHRfQQ0KPiA+IG1lc3NhZ2VzIGZyb20gaW5ib3VuZCBzdHJl YW1fMSwgYnV0IHNlbmQgb3V0IGNvbnRleHRfQSBtZXNzYWdlcyBmcm9tDQo+aW5ib3VkDQo+ID4g c3RyZWFtXzIsIHRoZSBwYXBlciBkaWRuJ3QgdGVsbCB1cyB0aGUgc3RyZWFtcyBNVVNUIGJlIHVz ZWQgYXMgcGFpcnM6DQo+ID4gaW5ib3VkIHN0cmVhbV8xIHNvIG91dGJvdW5kIHN0cmVhbV8xLg0K PiA+DQo+ID4gICBBbmQgdGhlcmUgbWF5YmUgY29leGlzdCBtb3JlIHRoYW4gb25lIFNDVFAgYXNz b2NpYXRpb25zIGJldHdlZW4NCj5NR0MvTUdXLg0KPiA+IFRoZSBNRy9NR0MgbWF5YmUgZ2V0IGNv bnRleF9BIG1lc3NhZ2VzIGZyb20gb25lIGFzc29jaWF0aW9uIGFuZCByZXNwb25kDQo+dGhlDQo+ ID4gcmVwbHkgaW4gYW5vdGhlciBhc3NvY2lhdGlvbi4gVGhlIHBhcGVyIGRpbid0IHRlbGwgdXMg TVVTVCB1c2Ugb25lDQo+ID4gYXNzb2NpYXRpb24gdG8gcHJvY2VzcyBvbmUgY29udGV4dC4NCj4g Pg0KPiA+ICAgVGhlIHVwcGVyIG1lY2hhbmlzbSBpcyBkaWZmZXJlbnQgZnJvbSBUVVAvSVNVUCBj YWxsIHByb2Nlc3MuIFRoZQ0KTUdDL01HDQo+ID4gY291bGRuJ3QgYW50aWNpcGF0ZSB0aGUgSC4y NDggY29tbXVuaWNhdGlvbiBwYXJ0bmVyIHJlcGx5IHRoZSBjYWxsDQo+Y29udGV4dA0KPiA+IG1l c3NhZ2UgaW4gd2hpY2ggYXNzb2NpYXRpb24gb3Igc3RyZWFtLiBJZiB0aGUgTUdDIGluaXRpYXRl IGEgY29udGV4dA0KaW4NCj4gPiBvbmUgYXNzb2NpYXRpb24gLGJ1dCByZWNlaXZlZCByZXBseSBp biBhbm90aGVyIGFzc29jaWF0aW9uLCBNR0MgaGF2ZSB0bw0KPiA+IGZvcndhcmQgdGhlIG1lc3Nh Z2UgdG8gdGhlIGluaXRpYXRlZCBwbGFjZS4gRG9lc24ndCBpdCBsb29rcyBzdHJhbmdlPw0KPk1h eWJlDQo+ID4gdSBoYXZlIGZ1cnRoZXIgc3VnZ2VzdGlvbiBhYm91dCB0aGlzIHF1ZXN0aW9uLg0K PiA+DQo+ID4gICBUaGFua3MuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gTWVnYWNvIG1haWxp bmcgbGlzdA0KPiA+IE1lZ2Fjb0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21lZ2Fjbw0KPiA+DQo+DQo+DQo+DQo+Z2FnYWdhZ2Fjbw0KPiA+DQo+ DQo+DQo+DQo+ICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXMx6HKJmopYp4JYrLQ/ DQo+IGk/etform22mz8/MD+tforg/mairWan/listinfo/megacoDQoNCg0KDQo= _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Sun Jun 29 22:26:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14182 for ; Sun, 29 Jun 2003 22:26:47 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5U2QK503739 for megaco-archive@odin.ietf.org; Sun, 29 Jun 2003 22:26:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WoN2-0000yE-4A for megaco-web-archive@optimus.ietf.org; Sun, 29 Jun 2003 22:26:20 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14048 for ; Sun, 29 Jun 2003 22:24:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WoKn-0000i3-Jw; Sun, 29 Jun 2003 22:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WnCV-0006dP-4g for megaco@optimus.ietf.org; Sun, 29 Jun 2003 21:11:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12325 for ; Sun, 29 Jun 2003 21:11:06 -0400 (EDT) From: zhou.zichun@zte.com.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WnCD-0001Hb-00 for megaco@ietf.org; Sun, 29 Jun 2003 21:11:05 -0400 Received: from [211.96.102.115] (helo=zte.com.cn) by ietf-mx with esmtp (Exim 4.12) id 19WnC2-0001H0-00 for megaco@ietf.org; Sun, 29 Jun 2003 21:10:55 -0400 To: megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Mon, 30 Jun 2003 09:07:09 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.8 |June 18, 2001) at 2003-06-30 09:11:33 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] MG capacity must be small? Sender: megaco-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 all, H.248 entity indicate it's transport address in ServiceChange command. Give an TCP transport example, the transport is an IP+PORT pair. So there only exist one TCP transport connection for a MG+MGC pair. Here now the CPU processor is limited, so we can conclude the MG+MGC transaction capacity cann't exeed the TCP transport capacity, so the MG capacity couldn't be very high. I want to see whether H.248 could support huge MG. Could there exist more than one transport connection between one MG+MGC pair? Maybe the transport on TCP/SCTP/MTP3B/etc. is not different. Regards, Zichun _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jun 30 00:46:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17518 for ; Mon, 30 Jun 2003 00:46:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WqYC-00066D-Qz; Mon, 30 Jun 2003 00:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WqXb-00065q-Qx for megaco@optimus.ietf.org; Mon, 30 Jun 2003 00:45:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17472 for ; Mon, 30 Jun 2003 00:43:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WqWD-0003K0-00 for megaco@ietf.org; Mon, 30 Jun 2003 00:43:57 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19WqW2-0003JT-00 for megaco@ietf.org; Mon, 30 Jun 2003 00:43:46 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5U4gXJ29460; Mon, 30 Jun 2003 00:42:33 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NLVY3C3W; Mon, 30 Jun 2003 00:42:33 -0400 Received: from nortelnetworks.com (acart1bz.ca.nortel.com [47.129.129.42]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NLV9J7S6; Mon, 30 Jun 2003 00:42:34 -0400 Message-ID: <3EFFBFB6.7030508@nortelnetworks.com> Date: Mon, 30 Jun 2003 00:42:30 -0400 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.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Bob Braisted CC: "'megaco@ietf.org'" Subject: Re: [Megaco] Z duration modifier and Timer overrides References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The problem is that RFC 3525 is actually H.248v1. The corresponding ID for H.248v2 has been submitted for IESG approval, but is stalled at the AD review stage. Bob Braisted wrote: > > i have 2 questions. > > 1. i see that in previous versions of h248v2 that the Z duration modifier > was called out in Annex B of the protocol (see below) > > http://www1.ietf.org/internet-drafts/draft-ietf-megaco-h248v2-04.txt > > digitMapName = NAME > digitMapValue = ["T" COLON Timer COMMA] ["S" COLON Timer COMMA] > ["L" COLON Timer COMMA] ["Z" COLON > Timer COMMA] > digitMap > Timer = 1*2DIGIT > ; Units are seconds for T, S, and L timers, and hundreds of > ; milliseconds for Z timer. Thus T, S, and L range from 1 to 99 > ; seconds and Z from 100 ms to 9.9 s > > was this unintentionally omitted from the RFC 3525? > and if not, how would one override the provisioned value of the Z duration > modifier on a per call basis? > > 2. with respect to timer overrides, again referencing h248v2, i notice that > previously, the letter "T" was a valid digitMapLetter, (used to specify > start timer override), and the latest version does not include "T" in the > digitMapLetter expression. Was this also intentionally removed? and if so, > can we assume that overriding the start digit timer would consist of > specifying ["T" COLON Timer COMMA] in the digit map descriptor and not > within the digit map string itself.? > > the older version has ... > > digitMapLetter = DIGIT ;Basic event > symbols > / %x41-4B / %x61-6B ; a-k, A-K > / "L" / "S" / "T" > ;Inter-event timers (long, short, start) > / "Z" ;Long > duration modifier > > the latest version removes the "T" . > > > Robert M. Braisted Tel: 508-804-8182 > Telica, Inc Fax: 508-460-0698 > 734 Forest Street email:bbraisted@telica.com > Building G, Suite 500 > Marlboro, MA 01752 > > > > > _______________________________________________ > 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 Jun 30 00:46:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17543 for ; Mon, 30 Jun 2003 00:46:42 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5U4kDj23526 for megaco-archive@odin.ietf.org; Mon, 30 Jun 2003 00:46:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WqYP-00067N-9w for megaco-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 00:46:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17501 for ; Mon, 30 Jun 2003 00:46:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WqYM-0003Ka-00 for megaco-web-archive@ietf.org; Mon, 30 Jun 2003 00:46:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19WqYH-0003KP-00 for megaco-web-archive@ietf.org; Mon, 30 Jun 2003 00:46:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WqYC-00066D-Qz; Mon, 30 Jun 2003 00:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WqXb-00065q-Qx for megaco@optimus.ietf.org; Mon, 30 Jun 2003 00:45:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17472 for ; Mon, 30 Jun 2003 00:43:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WqWD-0003K0-00 for megaco@ietf.org; Mon, 30 Jun 2003 00:43:57 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19WqW2-0003JT-00 for megaco@ietf.org; Mon, 30 Jun 2003 00:43:46 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5U4gXJ29460; Mon, 30 Jun 2003 00:42:33 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NLVY3C3W; Mon, 30 Jun 2003 00:42:33 -0400 Received: from nortelnetworks.com (acart1bz.ca.nortel.com [47.129.129.42]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NLV9J7S6; Mon, 30 Jun 2003 00:42:34 -0400 Message-ID: <3EFFBFB6.7030508@nortelnetworks.com> Date: Mon, 30 Jun 2003 00:42:30 -0400 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.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Bob Braisted CC: "'megaco@ietf.org'" Subject: Re: [Megaco] Z duration modifier and Timer overrides References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The problem is that RFC 3525 is actually H.248v1. The corresponding ID for H.248v2 has been submitted for IESG approval, but is stalled at the AD review stage. Bob Braisted wrote: > > i have 2 questions. > > 1. i see that in previous versions of h248v2 that the Z duration modifier > was called out in Annex B of the protocol (see below) > > http://www1.ietf.org/internet-drafts/draft-ietf-megaco-h248v2-04.txt > > digitMapName = NAME > digitMapValue = ["T" COLON Timer COMMA] ["S" COLON Timer COMMA] > ["L" COLON Timer COMMA] ["Z" COLON > Timer COMMA] > digitMap > Timer = 1*2DIGIT > ; Units are seconds for T, S, and L timers, and hundreds of > ; milliseconds for Z timer. Thus T, S, and L range from 1 to 99 > ; seconds and Z from 100 ms to 9.9 s > > was this unintentionally omitted from the RFC 3525? > and if not, how would one override the provisioned value of the Z duration > modifier on a per call basis? > > 2. with respect to timer overrides, again referencing h248v2, i notice that > previously, the letter "T" was a valid digitMapLetter, (used to specify > start timer override), and the latest version does not include "T" in the > digitMapLetter expression. Was this also intentionally removed? and if so, > can we assume that overriding the start digit timer would consist of > specifying ["T" COLON Timer COMMA] in the digit map descriptor and not > within the digit map string itself.? > > the older version has ... > > digitMapLetter = DIGIT ;Basic event > symbols > / %x41-4B / %x61-6B ; a-k, A-K > / "L" / "S" / "T" > ;Inter-event timers (long, short, start) > / "Z" ;Long > duration modifier > > the latest version removes the "T" . > > > Robert M. Braisted Tel: 508-804-8182 > Telica, Inc Fax: 508-460-0698 > 734 Forest Street email:bbraisted@telica.com > Building G, Suite 500 > Marlboro, MA 01752 > > > > > _______________________________________________ > 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 Jun 30 05:43:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07165 for ; Mon, 30 Jun 2003 05:43:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WvBd-0004m7-0P; Mon, 30 Jun 2003 05:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WvAA-0004ki-5Q for megaco@optimus.ietf.org; Mon, 30 Jun 2003 05:42:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07096 for ; Mon, 30 Jun 2003 05:41:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wv9r-0005Bq-00 for megaco@ietf.org; Mon, 30 Jun 2003 05:41:11 -0400 Received: from mail.tdsoft.com ([212.143.64.34] helo=exchange.td-soft.co.il) by ietf-mx with smtp (Exim 4.12) id 19Wv9f-0005Bn-00 for megaco@ietf.org; Mon, 30 Jun 2003 05:41:00 -0400 Received: through eSafe SMTP Relay 1056860629; Mon Jun 30 12:41:17 2003 Received: by exchange.td-soft.co.il with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jun 2003 12:36:35 +0200 Message-ID: From: Raphael Tryster To: "'Madhu Babu Brahmanapally'" , "'David Barr'" , "'megaco'" Subject: RE: [Megaco] H.248 equivalent of MGCP Delete from MG Date: Mon, 30 Jun 2003 12:36:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33EF3.76970690" Sender: megaco-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_01C33EF3.76970690 Content-Type: text/plain; charset="iso-8859-1" It won't help to put qualert in the event buffer descriptor unless it is also requested in the events descriptor, so the MGC can receive it. It seems to me David has a valid point about nt/qualert only becoming known if it is actually asked for, and the sample call flows don't. If the MGC constantly asks for a set of maintenance type parameters, it could make messages rather large. Can anyone tell me if this feature is used in practice? Raphael Tryster -----Original Message----- From: Madhu Babu Brahmanapally [SMTP:madhubabu@kenetec.com] Sent: Tuesday, 14 August 2001 20:10 To: 'David Barr'; 'megaco' Subject: RE: [Megaco] H.248 equivalent of MGCP Delete from MG HI David/All, MGC, if interested to receive such events, has to sent those events in the events descriptor or event buffer descriptor (Not shown in Example call flows). Both "netfail" and "quality alert" can be used for this purpose.(as applicable). The method of calculating the threshold for percent of quality loss is based on some provisional method. (I initially thought that the protocol will suggest few methods for this calculation, I'm not sure how this calculation is done.) Regards Madhubabu -----Original Message----- From: David Barr [mailto:David.Barr@nortelnetworks.com] Sent: Tuesday, August 14, 2001 12:12 PM To: 'Madhu Babu Brahmanapally'; megaco Subject: RE: [Megaco] H.248 equivalent of MGCP Delete from MG So in my cases below, I assume you mean using nt/qualert with threshold=100% ... is this correct? For case (1), I would think nt/netfail would also be a suitable event ... correct? However there is a problem with using events to do this. If the MGC doesn't request the event, it obviously won't get informed of the problem and therefore the call won't be cleared (... well, not until the users hang-up in frustration.) The advantage of the MGCP approach was that the MGC got to know about the problem without explicitly having to ask for it everytime it set up a connection. Ok, back to nt/qualert ... is it standard practice for the MGC to request this? None of the example call flows I have seen show the MGC requesting nt/qualert. Regards, Dave. -----Original Message----- From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] Sent: Tuesday, August 14, 2001 4:45 PM To: Barr, David [HAL02:HF22:EXCH]; megaco Subject: RE: [Megaco] H.248 equivalent of MGCP Delete from MG Hi David, In H.248, its only the MGC that can subtract the terminations from the context. In case of packet-side failure/comfort noise or any other case MG has to only indicate using the quality alert event and MGC will take the necessary action. Regards Madhubabu -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of David Barr Sent: Tuesday, August 14, 2001 11:20 AM To: 'megaco@ietf.org' Subject: [Megaco] H.248 equivalent of MGCP Delete from MG Hello list, MGCP has the concept of a Delete from the MG to the MGC. So what do we do for H.248 ? The Subtract command is intended for MGC to MG only. The MG may need to use this under certain circumstances. Examples are: (1) If there is detection of a packet-side bearer failure which affects a ephemeral termination within a current context. (2) If the MG fails to detect voice (or comfort noise) on a bearer connection after a certain amount of time -- this may be due to a problem with the peer MG, rather than anything wrong with the network. (3) A temporary MG resource issue which caused it to drop the call, but shouldn't affect future calls. Is there a standardised way for the MG to convey this infomation to the MGC -- i.e. one which all MGCs will understand? Thanks. ------_=_NextPart_001_01C33EF3.76970690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] H.248 equivalent of MGCP Delete from MG

It won't help to put qualert in the even= t buffer descriptor unless it is also requested in the events descriptor,= so the MGC can receive it.  It seems to me David has a valid point = about nt/qualert only becoming known if it is actually asked for, and the= sample call flows don't.  If the MGC constantly asks for a set of m= aintenance type parameters, it could make messages rather large.  Ca= n anyone tell me if this feature is used in practice?

Raphael Tryster

    -----Original Mess= age-----
    From:   Madhu Babu Brahman= apally [SMTP:madhubabu@kenetec.com]
    Sent:   Tuesday, 14 August 2001 20:10
    To:     'David Barr'; 'megaco'
    Subject:    &nbs= p;   RE: [Megaco] H.24= 8 equivalent of MGCP Delete from MG

    HI David/All,
    =A0
    MGC, if interested to= receive such events, has to sent those events in the events descriptor o= r event buffer descriptor (Not shown in Example call flows). Both "n= etfail" and "quality alert" can be used for this purpose.(= as applicable).=A0 The method of calculating the threshold for percent of= quality loss is based on some provisional method. (I initially thought t= hat the protocol will suggest few methods for this calculation,=A0I'm not= sure how this calculation is done.)

    =A0
    Regards
    Madhubabu

      -----Original Message-----
      From: David Barr [mailto:David.Barr@nortelnetworks.com]
      Sent: Tuesday, August 14, 2001 12:12 PM
      To: 'Madhu Babu Brahmanapally'; megaco
      Subject: RE: [Megaco] H.248 equivalent of MGCP Delete fr= om MG
      So in my cases below,= I assume you mean using nt/qualert with threshold=3D100% ... is this cor= rect?
      =A0
      For case (1), I would= think nt/netfail would also be a suitable event ... correct?
      =A0
      However there is a pr= oblem with using events to do this.=A0 If the MGC doesn't request the eve= nt, it obviously won't get informed of the problem and therefore the call= won't be cleared (... well, not until the users hang-up in frustration.)=

      =A0
      The advantage of the = MGCP approach was that the MGC got to know about the problem without expl= icitly having to ask for it everytime it set up a connection.

      =A0
      Ok, back to nt/qualer= t ... is it standard practice for the MGC to request this?=A0 None of the= example call flows I have seen show the MGC requesting nt/qualert.

      =A0
      Regards,
      Dave.
      =A0
      -----Original Message-----
      From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
      Sent: Tuesday, August 14, 2001 4:45 PM
      To: Barr, David [HAL02:HF22:EXCH]; megaco
      Subject: RE: [Megaco] H.248 equivalent of MGCP Delete fr= om MG
      Hi David,
      In H.248, its only th= e MGC that can subtract the terminations from the context. In case of pac= ket-side failure/comfort noise or any other case MG has to only indicate = using the quality alert event and MGC will take the necessary action.

      Regards
      Madhubabu

        -----Original Message-----
        From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of David Barr
        Sent: Tuesday, August 14, 2001 11:20 AM
        To: 'megaco@ietf.org'
        Subject: [Megaco] H.248 equivalent of MGCP Delete from M= G

        Hello list,

        MGCP has the concept o= f a Delete from the MG to the MGC.

        So what do we do for H= =2E248 ?=A0 The Subtract command is intended for MGC to MG only.

        The MG may need to use= this under certain circumstances.=A0 Examples are:
        (1) If there is de= tection of a packet-side bearer failure which affects a ephemeral termina= tion within a current context.

        (2) If the MG fails to= detect voice (or comfort noise) on a bearer connection after a certain a= mount of time -- this may be due to a problem with the peer MG, rather th= an anything wrong with the network.

        (3) A temporary MG res= ource issue which caused it to drop the call, but shouldn't affect future= calls.

        Is there a standardise= d way for the MG to convey this infomation to the MGC -- i.e. one which a= ll MGCs will understand?

        Thanks.

------_=_NextPart_001_01C33EF3.76970690-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Jun 30 05:43:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07180 for ; Mon, 30 Jun 2003 05:43:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5U9h8H18503 for megaco-archive@odin.ietf.org; Mon, 30 Jun 2003 05:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WvBk-0004oM-R2 for megaco-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 05:43:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07160 for ; Mon, 30 Jun 2003 05:43:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WvBh-0005Cm-00 for megaco-web-archive@ietf.org; Mon, 30 Jun 2003 05:43:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19WvBb-0005Cj-00 for megaco-web-archive@ietf.org; Mon, 30 Jun 2003 05:42:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WvBd-0004m7-0P; Mon, 30 Jun 2003 05:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WvAA-0004ki-5Q for megaco@optimus.ietf.org; Mon, 30 Jun 2003 05:42:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07096 for ; Mon, 30 Jun 2003 05:41:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wv9r-0005Bq-00 for megaco@ietf.org; Mon, 30 Jun 2003 05:41:11 -0400 Received: from mail.tdsoft.com ([212.143.64.34] helo=exchange.td-soft.co.il) by ietf-mx with smtp (Exim 4.12) id 19Wv9f-0005Bn-00 for megaco@ietf.org; Mon, 30 Jun 2003 05:41:00 -0400 Received: through eSafe SMTP Relay 1056860629; Mon Jun 30 12:41:17 2003 Received: by exchange.td-soft.co.il with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jun 2003 12:36:35 +0200 Message-ID: From: Raphael Tryster To: "'Madhu Babu Brahmanapally'" , "'David Barr'" , "'megaco'" Subject: RE: [Megaco] H.248 equivalent of MGCP Delete from MG Date: Mon, 30 Jun 2003 12:36:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33EF3.76970690" Sender: megaco-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_01C33EF3.76970690 Content-Type: text/plain; charset="iso-8859-1" It won't help to put qualert in the event buffer descriptor unless it is also requested in the events descriptor, so the MGC can receive it. It seems to me David has a valid point about nt/qualert only becoming known if it is actually asked for, and the sample call flows don't. If the MGC constantly asks for a set of maintenance type parameters, it could make messages rather large. Can anyone tell me if this feature is used in practice? Raphael Tryster -----Original Message----- From: Madhu Babu Brahmanapally [SMTP:madhubabu@kenetec.com] Sent: Tuesday, 14 August 2001 20:10 To: 'David Barr'; 'megaco' Subject: RE: [Megaco] H.248 equivalent of MGCP Delete from MG HI David/All, MGC, if interested to receive such events, has to sent those events in the events descriptor or event buffer descriptor (Not shown in Example call flows). Both "netfail" and "quality alert" can be used for this purpose.(as applicable). The method of calculating the threshold for percent of quality loss is based on some provisional method. (I initially thought that the protocol will suggest few methods for this calculation, I'm not sure how this calculation is done.) Regards Madhubabu -----Original Message----- From: David Barr [mailto:David.Barr@nortelnetworks.com] Sent: Tuesday, August 14, 2001 12:12 PM To: 'Madhu Babu Brahmanapally'; megaco Subject: RE: [Megaco] H.248 equivalent of MGCP Delete from MG So in my cases below, I assume you mean using nt/qualert with threshold=100% ... is this correct? For case (1), I would think nt/netfail would also be a suitable event ... correct? However there is a problem with using events to do this. If the MGC doesn't request the event, it obviously won't get informed of the problem and therefore the call won't be cleared (... well, not until the users hang-up in frustration.) The advantage of the MGCP approach was that the MGC got to know about the problem without explicitly having to ask for it everytime it set up a connection. Ok, back to nt/qualert ... is it standard practice for the MGC to request this? None of the example call flows I have seen show the MGC requesting nt/qualert. Regards, Dave. -----Original Message----- From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] Sent: Tuesday, August 14, 2001 4:45 PM To: Barr, David [HAL02:HF22:EXCH]; megaco Subject: RE: [Megaco] H.248 equivalent of MGCP Delete from MG Hi David, In H.248, its only the MGC that can subtract the terminations from the context. In case of packet-side failure/comfort noise or any other case MG has to only indicate using the quality alert event and MGC will take the necessary action. Regards Madhubabu -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of David Barr Sent: Tuesday, August 14, 2001 11:20 AM To: 'megaco@ietf.org' Subject: [Megaco] H.248 equivalent of MGCP Delete from MG Hello list, MGCP has the concept of a Delete from the MG to the MGC. So what do we do for H.248 ? The Subtract command is intended for MGC to MG only. The MG may need to use this under certain circumstances. Examples are: (1) If there is detection of a packet-side bearer failure which affects a ephemeral termination within a current context. (2) If the MG fails to detect voice (or comfort noise) on a bearer connection after a certain amount of time -- this may be due to a problem with the peer MG, rather than anything wrong with the network. (3) A temporary MG resource issue which caused it to drop the call, but shouldn't affect future calls. Is there a standardised way for the MG to convey this infomation to the MGC -- i.e. one which all MGCs will understand? Thanks. ------_=_NextPart_001_01C33EF3.76970690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] H.248 equivalent of MGCP Delete from MG

It won't help to put qualert in the even= t buffer descriptor unless it is also requested in the events descriptor,= so the MGC can receive it.  It seems to me David has a valid point = about nt/qualert only becoming known if it is actually asked for, and the= sample call flows don't.  If the MGC constantly asks for a set of m= aintenance type parameters, it could make messages rather large.  Ca= n anyone tell me if this feature is used in practice?

Raphael Tryster

    -----Original Mess= age-----
    From:   Madhu Babu Brahman= apally [SMTP:madhubabu@kenetec.com]
    Sent:   Tuesday, 14 August 2001 20:10
    To:     'David Barr'; 'megaco'
    Subject:    &nbs= p;   RE: [Megaco] H.24= 8 equivalent of MGCP Delete from MG

    HI David/All,
    =A0
    MGC, if interested to= receive such events, has to sent those events in the events descriptor o= r event buffer descriptor (Not shown in Example call flows). Both "n= etfail" and "quality alert" can be used for this purpose.(= as applicable).=A0 The method of calculating the threshold for percent of= quality loss is based on some provisional method. (I initially thought t= hat the protocol will suggest few methods for this calculation,=A0I'm not= sure how this calculation is done.)

    =A0
    Regards
    Madhubabu

      -----Original Message-----
      From: David Barr [mailto:David.Barr@nortelnetworks.com]
      Sent: Tuesday, August 14, 2001 12:12 PM
      To: 'Madhu Babu Brahmanapally'; megaco
      Subject: RE: [Megaco] H.248 equivalent of MGCP Delete fr= om MG
      So in my cases below,= I assume you mean using nt/qualert with threshold=3D100% ... is this cor= rect?
      =A0
      For case (1), I would= think nt/netfail would also be a suitable event ... correct?
      =A0
      However there is a pr= oblem with using events to do this.=A0 If the MGC doesn't request the eve= nt, it obviously won't get informed of the problem and therefore the call= won't be cleared (... well, not until the users hang-up in frustration.)=

      =A0
      The advantage of the = MGCP approach was that the MGC got to know about the problem without expl= icitly having to ask for it everytime it set up a connection.

      =A0
      Ok, back to nt/qualer= t ... is it standard practice for the MGC to request this?=A0 None of the= example call flows I have seen show the MGC requesting nt/qualert.

      =A0
      Regards,
      Dave.
      =A0
      -----Original Message-----
      From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
      Sent: Tuesday, August 14, 2001 4:45 PM
      To: Barr, David [HAL02:HF22:EXCH]; megaco
      Subject: RE: [Megaco] H.248 equivalent of MGCP Delete fr= om MG
      Hi David,
      In H.248, its only th= e MGC that can subtract the terminations from the context. In case of pac= ket-side failure/comfort noise or any other case MG has to only indicate = using the quality alert event and MGC will take the necessary action.

      Regards
      Madhubabu

        -----Original Message-----
        From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of David Barr
        Sent: Tuesday, August 14, 2001 11:20 AM
        To: 'megaco@ietf.org'
        Subject: [Megaco] H.248 equivalent of MGCP Delete from M= G

        Hello list,

        MGCP has the concept o= f a Delete from the MG to the MGC.

        So what do we do for H= =2E248 ?=A0 The Subtract command is intended for MGC to MG only.

        The MG may need to use= this under certain circumstances.=A0 Examples are:
        (1) If there is de= tection of a packet-side bearer failure which affects a ephemeral termina= tion within a current context.

        (2) If the MG fails to= detect voice (or comfort noise) on a bearer connection after a certain a= mount of time -- this may be due to a problem with the peer MG, rather th= an anything wrong with the network.

        (3) A temporary MG res= ource issue which caused it to drop the call, but shouldn't affect future= calls.

        Is there a standardise= d way for the MG to convey this infomation to the MGC -- i.e. one which a= ll MGCs will understand?

        Thanks.

------_=_NextPart_001_01C33EF3.76970690-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jun 30 07:29:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10281 for ; Mon, 30 Jun 2003 07:29:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WwqD-0000Vc-3T; Mon, 30 Jun 2003 07:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wwpx-0000U3-W2 for megaco@optimus.ietf.org; Mon, 30 Jun 2003 07:28:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10221 for ; Mon, 30 Jun 2003 07:28:45 -0400 (EDT) From: bvswamy@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wwpx-0005u8-00 for megaco@ietf.org; Mon, 30 Jun 2003 07:28:45 -0400 Received: from hindon.hss.co.in ([202.54.26.202]) by ietf-mx with esmtp (Exim 4.12) id 19Wwpl-0005tg-00 for megaco@ietf.org; Mon, 30 Jun 2003 07:28:34 -0400 Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h5UBPAD28190 for ; Mon, 30 Jun 2003 16:55:10 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h5UBP9O28183 for ; Mon, 30 Jun 2003 16:55:09 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h5UBSlp29258 for ; Mon, 30 Jun 2003 16:58:47 +0530 (IST) To: megaco@ietf.org Date: Mon, 30 Jun 2003 16:53:42 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 30/06/2003 04:52:29 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Megaco] EBCP Flag ON-OFF transition Sender: megaco-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 All Needed a clarification on the behaviour of MG wrt to the EBCP flag transition from ON to OFF. The scenario is as follows: 1) Modify TermId = T10 CtxId = null Media { TerminationState { Buffer = LockStep} }, Events = 1 { dd/d0,dd/d1,dd/d2,al/hf}, EventBuffer { dd/d4, dd/d5, dd/d6, dd/d7 } 2) After the notification of any event in the event descriptor, eventbuffer descriptor is activated and buffering is done by MG. 3) MGC modifies the EBCP flag to OFF. Modify TermId = T10 CtxId = null Media { TerminationState { Buffer = OFF} } Now according to the protocol, the events that are buffered shall be discarded, (draft-ietf-megaco-3015corr-01>> " If the MG receives a command instructing it to set the value of EventBufferControl to Off, all events in the EventBuffer SHALL be discarded" ) however there is no mention whether the old event descriptor shall get activated or not. That is if any event in the old event descriptor is detected then whether it should be reported to MGC or whether it should be discarded. Regards Venkat www.hssworld.com Hughes Software Systems "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Jun 30 07:29:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10301 for ; Mon, 30 Jun 2003 07:29:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UBT8j02065 for megaco-archive@odin.ietf.org; Mon, 30 Jun 2003 07:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WwqK-0000XE-Hj for megaco-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 07:29:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10242 for ; Mon, 30 Jun 2003 07:29:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WwqJ-0005uP-00 for megaco-web-archive@ietf.org; Mon, 30 Jun 2003 07:29:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19WwqE-0005uM-00 for megaco-web-archive@ietf.org; Mon, 30 Jun 2003 07:29:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WwqD-0000Vc-3T; Mon, 30 Jun 2003 07:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wwpx-0000U3-W2 for megaco@optimus.ietf.org; Mon, 30 Jun 2003 07:28:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10221 for ; Mon, 30 Jun 2003 07:28:45 -0400 (EDT) From: bvswamy@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wwpx-0005u8-00 for megaco@ietf.org; Mon, 30 Jun 2003 07:28:45 -0400 Received: from hindon.hss.co.in ([202.54.26.202]) by ietf-mx with esmtp (Exim 4.12) id 19Wwpl-0005tg-00 for megaco@ietf.org; Mon, 30 Jun 2003 07:28:34 -0400 Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h5UBPAD28190 for ; Mon, 30 Jun 2003 16:55:10 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h5UBP9O28183 for ; Mon, 30 Jun 2003 16:55:09 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h5UBSlp29258 for ; Mon, 30 Jun 2003 16:58:47 +0530 (IST) To: megaco@ietf.org Date: Mon, 30 Jun 2003 16:53:42 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 30/06/2003 04:52:29 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Megaco] EBCP Flag ON-OFF transition Sender: megaco-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 All Needed a clarification on the behaviour of MG wrt to the EBCP flag transition from ON to OFF. The scenario is as follows: 1) Modify TermId = T10 CtxId = null Media { TerminationState { Buffer = LockStep} }, Events = 1 { dd/d0,dd/d1,dd/d2,al/hf}, EventBuffer { dd/d4, dd/d5, dd/d6, dd/d7 } 2) After the notification of any event in the event descriptor, eventbuffer descriptor is activated and buffering is done by MG. 3) MGC modifies the EBCP flag to OFF. Modify TermId = T10 CtxId = null Media { TerminationState { Buffer = OFF} } Now according to the protocol, the events that are buffered shall be discarded, (draft-ietf-megaco-3015corr-01>> " If the MG receives a command instructing it to set the value of EventBufferControl to Off, all events in the EventBuffer SHALL be discarded" ) however there is no mention whether the old event descriptor shall get activated or not. That is if any event in the old event descriptor is detected then whether it should be reported to MGC or whether it should be discarded. Regards Venkat www.hssworld.com Hughes Software Systems "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jun 30 08:34:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18109 for ; Mon, 30 Jun 2003 08:34:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wxr8-0004Vr-L0; Mon, 30 Jun 2003 08:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WrrU-0002RQ-Ka for megaco@optimus.ietf.org; Mon, 30 Jun 2003 02:10:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00860 for ; Mon, 30 Jun 2003 02:09:59 -0400 (EDT) From: zhou.zichun@zte.com.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WrrR-0003oZ-00 for megaco@ietf.org; Mon, 30 Jun 2003 02:09:57 -0400 Received: from [211.96.102.115] (helo=zte.com.cn) by ietf-mx with esmtp (Exim 4.12) id 19WrrG-0003oN-00 for megaco@ietf.org; Mon, 30 Jun 2003 02:09:46 -0400 Subject: RE:RE: [Megaco] MG capacity must be small? To: "Christer Holmberg (JO/LMF)" Cc: megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Mon, 30 Jun 2003 14:08:44 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.8 |June 18, 2001) at 2003-06-30 14:10:32 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Christer, I agree split MG is possible. I want to know whether we could solve the problem without split the MGW. Could we let a MG-MGC pair's H.248 transported on several TCP connections? The MEGACO didn't mention it. In fact, splited logical MGW are small. When the MGWs need connect each other, wasting occurs. Give an example, In 3GPP WCDMA systems big MGW connect several RNCs, split MGW maybe RTP transport resources when inter-RNCs change-over begins. Spliting make the equipment difficult to config data, also difficult to maintain. Regards, Zichun spamcontrol _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Jun 30 08:34:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18158 for ; Mon, 30 Jun 2003 08:34:54 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UCYO117514 for megaco-archive@odin.ietf.org; Mon, 30 Jun 2003 08:34:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WxrU-0004YP-Py for megaco-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 08:34:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18054 for ; Mon, 30 Jun 2003 08:34:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WxrE-00076X-00 for megaco-web-archive@ietf.org; Mon, 30 Jun 2003 08:34:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Wxr8-00076R-00 for megaco-web-archive@ietf.org; Mon, 30 Jun 2003 08:34:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wxr8-0004Ve-3K; Mon, 30 Jun 2003 08:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WrI3-0007pI-5w for megaco@optimus.ietf.org; Mon, 30 Jun 2003 01:33:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18992 for ; Mon, 30 Jun 2003 01:33:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WrHl-0003cU-00 for megaco@ietf.org; Mon, 30 Jun 2003 01:33:05 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19WrHa-0003cP-00 for megaco@ietf.org; Mon, 30 Jun 2003 01:32:54 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5U5WKw2026981; Mon, 30 Jun 2003 07:32:21 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 30 Jun 2003 07:32:36 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'zhou.zichun@zte.com.cn'" , megaco@ietf.org Subject: RE: [Megaco] MG capacity must be small? Date: Mon, 30 Jun 2003 07:32:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, >H.248 entity indicate it's transport address in >ServiceChange command. >Give an TCP transport example, the transport is an IP+PORT >pair. So there only exist one TCP transport connection for a MG+MGC pair. >Here now the CPU processor is limited, so we can conclude the MG+MGC >transaction capacity cann't exeed the TCP transport capacity, so the MG capacity >couldn't be very high. > >I want to see whether H.248 could support huge MG. Could >there exist more than one transport connection between one MG+MGC pair? Maybe the >transport on TCP/SCTP/MTP3B/etc. is not different. [CHH] One option is to split your physical MG into multiple virtual MGs. Then you can establish separate TCP connections for each of those. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jun 30 08:42:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19175 for ; Mon, 30 Jun 2003 08:42:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wxvy-00053X-3X; Mon, 30 Jun 2003 08:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wxvw-00053G-Ol for megaco@optimus.ietf.org; Mon, 30 Jun 2003 08:39:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17304 for ; Mon, 30 Jun 2003 08:29:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WxmN-0006tx-00 for megaco@ietf.org; Mon, 30 Jun 2003 08:29:07 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19WxmC-0006tI-00 for megaco@ietf.org; Mon, 30 Jun 2003 08:28:56 -0400 Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5UCSJ425821 for ; Mon, 30 Jun 2003 08:28:19 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NLV6JQ54; Mon, 30 Jun 2003 08:28:19 -0400 Received: from nortelnetworks.com (acart1bz.ca.nortel.com [47.129.129.42]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NLV9J744; Mon, 30 Jun 2003 08:28:20 -0400 Message-ID: <3F002CB4.1060101@nortelnetworks.com> Date: Mon, 30 Jun 2003 08:27:32 -0400 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.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: megaco@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] [Fwd: EBCP Flag ON-OFF transition] Sender: megaco-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 -------- Original Message -------- Subject: EBCP Flag ON-OFF transition Date: Mon, 30 Jun 2003 15:57:10 +0530 From: bvswamy@hss.hns.com To: megaco-admin@ietf.org Hi All Needed a clarification on the behaviour of MG wrt to the EBCP flag transition from ON to OFF. The scenario is as follows: 1) Modify TermId = T10 CtxId = null Media { TerminationState { Buffer = LockStep} }, Events = 1 { dd/d0,dd/d1,dd/d2,al/hf}, EventBuffer { dd/d4, dd/d5, dd/d6, dd/d7 } 2) After the notification of any event in the event descriptor, eventbuffer descriptor is activated and buffering is done by MG. 3) MGC modifies the EBCP flag to OFF. Modify TermId = T10 CtxId = null Media { TerminationState { Buffer = OFF} } Now according to the protocol, the events that are buffered shall be discarded, (draft-ietf-megaco-3015corr-01>> " If the MG receives a command instructing it to set the value of EventBufferControl to Off, all events in the EventBuffer SHALL be discarded" ) however there is no mention whether the old event descriptor shall get activated or not. That is if any event in the old event descriptor is detected then whether it should be reported to MGC or whether it should be discarded. Regards Venkat www.hssworld.com Hughes Software Systems "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Jun 30 08:49:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19787 for ; Mon, 30 Jun 2003 08:49:51 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UCnMQ21666 for megaco-archive@odin.ietf.org; Mon, 30 Jun 2003 08:49:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wy5y-0005dI-Ee for megaco-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 08:49:22 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19739 for ; Mon, 30 Jun 2003 08:49:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wxvy-00053X-3X; Mon, 30 Jun 2003 08:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wxvw-00053G-Ol for megaco@optimus.ietf.org; Mon, 30 Jun 2003 08:39:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17304 for ; Mon, 30 Jun 2003 08:29:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WxmN-0006tx-00 for megaco@ietf.org; Mon, 30 Jun 2003 08:29:07 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19WxmC-0006tI-00 for megaco@ietf.org; Mon, 30 Jun 2003 08:28:56 -0400 Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5UCSJ425821 for ; Mon, 30 Jun 2003 08:28:19 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NLV6JQ54; Mon, 30 Jun 2003 08:28:19 -0400 Received: from nortelnetworks.com (acart1bz.ca.nortel.com [47.129.129.42]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NLV9J744; Mon, 30 Jun 2003 08:28:20 -0400 Message-ID: <3F002CB4.1060101@nortelnetworks.com> Date: Mon, 30 Jun 2003 08:27:32 -0400 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.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: megaco@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] [Fwd: EBCP Flag ON-OFF transition] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: EBCP Flag ON-OFF transition Date: Mon, 30 Jun 2003 15:57:10 +0530 From: bvswamy@hss.hns.com To: megaco-admin@ietf.org Hi All Needed a clarification on the behaviour of MG wrt to the EBCP flag transition from ON to OFF. The scenario is as follows: 1) Modify TermId = T10 CtxId = null Media { TerminationState { Buffer = LockStep} }, Events = 1 { dd/d0,dd/d1,dd/d2,al/hf}, EventBuffer { dd/d4, dd/d5, dd/d6, dd/d7 } 2) After the notification of any event in the event descriptor, eventbuffer descriptor is activated and buffering is done by MG. 3) MGC modifies the EBCP flag to OFF. Modify TermId = T10 CtxId = null Media { TerminationState { Buffer = OFF} } Now according to the protocol, the events that are buffered shall be discarded, (draft-ietf-megaco-3015corr-01>> " If the MG receives a command instructing it to set the value of EventBufferControl to Off, all events in the EventBuffer SHALL be discarded" ) however there is no mention whether the old event descriptor shall get activated or not. That is if any event in the old event descriptor is detected then whether it should be reported to MGC or whether it should be discarded. Regards Venkat www.hssworld.com Hughes Software Systems "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Jun 30 10:02:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18159 for ; Mon, 30 Jun 2003 08:34:54 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UCYOU17531 for megaco-archive@odin.ietf.org; Mon, 30 Jun 2003 08:34:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WxrU-0004YV-SW for megaco-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 08:34:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18055 for ; Mon, 30 Jun 2003 08:34:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WxrE-00076U-00 for megaco-web-archive@ietf.org; Mon, 30 Jun 2003 08:34:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Wxr8-00076Q-00 for megaco-web-archive@ietf.org; Mon, 30 Jun 2003 08:34:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wxr8-0004Vr-L0; Mon, 30 Jun 2003 08:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WrrU-0002RQ-Ka for megaco@optimus.ietf.org; Mon, 30 Jun 2003 02:10:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00860 for ; Mon, 30 Jun 2003 02:09:59 -0400 (EDT) From: zhou.zichun@zte.com.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WrrR-0003oZ-00 for megaco@ietf.org; Mon, 30 Jun 2003 02:09:57 -0400 Received: from [211.96.102.115] (helo=zte.com.cn) by ietf-mx with esmtp (Exim 4.12) id 19WrrG-0003oN-00 for megaco@ietf.org; Mon, 30 Jun 2003 02:09:46 -0400 Subject: RE:RE: [Megaco] MG capacity must be small? To: "Christer Holmberg (JO/LMF)" Cc: megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Mon, 30 Jun 2003 14:08:44 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.8 |June 18, 2001) at 2003-06-30 14:10:32 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Christer, I agree split MG is possible. I want to know whether we could solve the problem without split the MGW. Could we let a MG-MGC pair's H.248 transported on several TCP connections? The MEGACO didn't mention it. In fact, splited logical MGW are small. When the MGWs need connect each other, wasting occurs. Give an example, In 3GPP WCDMA systems big MGW connect several RNCs, split MGW maybe RTP transport resources when inter-RNCs change-over begins. Spliting make the equipment difficult to config data, also difficult to maintain. Regards, Zichun spamcontrol _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jun 30 10:37:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27959 for ; Mon, 30 Jun 2003 10:37:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wzm9-00029J-OJ; Mon, 30 Jun 2003 10:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wzl0-0001yy-UF for megaco@optimus.ietf.org; Mon, 30 Jun 2003 10:36:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27736 for ; Mon, 30 Jun 2003 10:35:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wzki-0001KW-00 for megaco@ietf.org; Mon, 30 Jun 2003 10:35:32 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 19WzkW-0001Gz-00 for megaco@ietf.org; Mon, 30 Jun 2003 10:35:20 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5UEYS823404 for ; Mon, 30 Jun 2003 10:34:28 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jun 2003 10:34:28 -0400 Message-ID: From: "Kevin Boyle" To: zhou.zichun@zte.com.cn, "Christer Holmberg (JO/LMF)" Cc: megaco@ietf.org Subject: RE: RE: [Megaco] MG capacity must be small? Date: Mon, 30 Jun 2003 10:34:17 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I disagree. Partitioning MGs into several VMGs makes them easier to configure and maintain, as long as the partitioning is made to apportion the available resources. Remember that VMGs may share the same resources and provisioning -- it is only to the MGC that the VMGs appear to be different entities. So, the various VMGs don't have to be wasteful when interconnecting, because they are, behind the scenes, the same MG. A MG could, for example, figure out that a particular bearer is running from one of its VMGs to another, and keep the bearer local instead of looping it over the network. Kevin -----Original Message----- From: zhou.zichun@zte.com.cn [mailto:zhou.zichun@zte.com.cn] Sent: Monday, June 30, 2003 2:09 AM To: Christer Holmberg (JO/LMF) Cc: megaco@ietf.org Subject: RE:RE: [Megaco] MG capacity must be small? Hi Christer, I agree split MG is possible. I want to know whether we could solve the problem without split the MGW. Could we let a MG-MGC pair's H.248 transported on several TCP connections? The MEGACO didn't mention it. In fact, splited logical MGW are small. When the MGWs need connect each other, wasting occurs. Give an example, In 3GPP WCDMA systems big MGW connect several RNCs, split MGW maybe RTP transport resources when inter-RNCs change-over begins. Spliting make the equipment difficult to config data, also difficult to maintain. Regards, Zichun spamcontrol _______________________________________________ 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 Jun 30 10:37:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28002 for ; Mon, 30 Jun 2003 10:37:42 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UEbFE08739 for megaco-archive@odin.ietf.org; Mon, 30 Jun 2003 10:37:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WzmN-0002Gs-08 for megaco-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 10:37:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27949 for ; Mon, 30 Jun 2003 10:37:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WzmJ-0001MR-00 for megaco-web-archive@ietf.org; Mon, 30 Jun 2003 10:37:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Wzm9-0001MK-00 for megaco-web-archive@ietf.org; Mon, 30 Jun 2003 10:37:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wzm9-00029J-OJ; Mon, 30 Jun 2003 10:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wzl0-0001yy-UF for megaco@optimus.ietf.org; Mon, 30 Jun 2003 10:36:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27736 for ; Mon, 30 Jun 2003 10:35:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wzki-0001KW-00 for megaco@ietf.org; Mon, 30 Jun 2003 10:35:32 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 19WzkW-0001Gz-00 for megaco@ietf.org; Mon, 30 Jun 2003 10:35:20 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5UEYS823404 for ; Mon, 30 Jun 2003 10:34:28 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jun 2003 10:34:28 -0400 Message-ID: From: "Kevin Boyle" To: zhou.zichun@zte.com.cn, "Christer Holmberg (JO/LMF)" Cc: megaco@ietf.org Subject: RE: RE: [Megaco] MG capacity must be small? Date: Mon, 30 Jun 2003 10:34:17 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I disagree. Partitioning MGs into several VMGs makes them easier to configure and maintain, as long as the partitioning is made to apportion the available resources. Remember that VMGs may share the same resources and provisioning -- it is only to the MGC that the VMGs appear to be different entities. So, the various VMGs don't have to be wasteful when interconnecting, because they are, behind the scenes, the same MG. A MG could, for example, figure out that a particular bearer is running from one of its VMGs to another, and keep the bearer local instead of looping it over the network. Kevin -----Original Message----- From: zhou.zichun@zte.com.cn [mailto:zhou.zichun@zte.com.cn] Sent: Monday, June 30, 2003 2:09 AM To: Christer Holmberg (JO/LMF) Cc: megaco@ietf.org Subject: RE:RE: [Megaco] MG capacity must be small? Hi Christer, I agree split MG is possible. I want to know whether we could solve the problem without split the MGW. Could we let a MG-MGC pair's H.248 transported on several TCP connections? The MEGACO didn't mention it. In fact, splited logical MGW are small. When the MGWs need connect each other, wasting occurs. Give an example, In 3GPP WCDMA systems big MGW connect several RNCs, split MGW maybe RTP transport resources when inter-RNCs change-over begins. Spliting make the equipment difficult to config data, also difficult to maintain. Regards, Zichun spamcontrol _______________________________________________ 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 Jun 30 11:39:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18108 for ; Mon, 30 Jun 2003 08:34:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wxr8-0004Ve-3K; Mon, 30 Jun 2003 08:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WrI3-0007pI-5w for megaco@optimus.ietf.org; Mon, 30 Jun 2003 01:33:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18992 for ; Mon, 30 Jun 2003 01:33:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WrHl-0003cU-00 for megaco@ietf.org; Mon, 30 Jun 2003 01:33:05 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19WrHa-0003cP-00 for megaco@ietf.org; Mon, 30 Jun 2003 01:32:54 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5U5WKw2026981; Mon, 30 Jun 2003 07:32:21 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 30 Jun 2003 07:32:36 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'zhou.zichun@zte.com.cn'" , megaco@ietf.org Subject: RE: [Megaco] MG capacity must be small? Date: Mon, 30 Jun 2003 07:32:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, >H.248 entity indicate it's transport address in >ServiceChange command. >Give an TCP transport example, the transport is an IP+PORT >pair. So there only exist one TCP transport connection for a MG+MGC pair. >Here now the CPU processor is limited, so we can conclude the MG+MGC >transaction capacity cann't exeed the TCP transport capacity, so the MG capacity >couldn't be very high. > >I want to see whether H.248 could support huge MG. Could >there exist more than one transport connection between one MG+MGC pair? Maybe the >transport on TCP/SCTP/MTP3B/etc. is not different. [CHH] One option is to split your physical MG into multiple virtual MGs. Then you can establish separate TCP connections for each of those. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco