From mailman-admin@ietf.org Fri Aug 1 09:32:06 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 JAA14353 for ; Fri, 1 Aug 2003 09:18:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iZZr-0005SL-BS for megaco-archive@lists.ietf.org; Fri, 01 Aug 2003 09:04:11 -0400 Date: Fri, 01 Aug 2003 09:04:11 -0400 Message-ID: <20030801130411.29120.33326.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 Wed Aug 6 02:27: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 CAA04077 for ; Wed, 6 Aug 2003 02:27: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 19kHlF-0000Qq-Lw; Wed, 06 Aug 2003 02:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kHkL-0000O8-Bf for megaco@optimus.ietf.org; Wed, 06 Aug 2003 02:26: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 CAA02750 for ; Wed, 6 Aug 2003 02:26:01 -0400 (EDT) From: shchoi@etri.re.kr Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kHkH-0000je-00 for megaco@ietf.org; Wed, 06 Aug 2003 02:26:01 -0400 Received: from cms1.etri.re.kr ([129.254.16.11] helo=cms1.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 19kHkG-0000jb-00 for megaco@ietf.org; Wed, 06 Aug 2003 02:26:00 -0400 Received: by cms1 with Internet Mail Service (5.5.2655.55) id ; Wed, 6 Aug 2003 15:25:18 +0900 Message-ID: <4A0AE1E5A1AAD711AC1B00D0B7C2D4A279387C@cms1> To: megaco@ietf.org Date: Wed, 6 Aug 2003 15:25:17 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35BE3.80DFF2D0" Subject: [Megaco] [Megaco]Question about R2 signaling Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C35BE3.80DFF2D0 Content-Type: text/plain Hi, All. It is natural that MGC is responsible for signaling control and MG is responsible for media control in MGC-MG model. So, I think that ,for R2 signaling service, MGC should perform protocol state machine for R2 and MG should just report R2 related signals and trigger R2 related signals by MGC. Bu, according to H.248.26 "Basic CAS Packages", CAS Failure event means that MG is acting like operating protocol state machine for R2 signaling. Is it necesary that both MGC and MG have protocol state machine for R2 signaling? If it is OK, Is the reason that the protocol state machine of MG corrects that of MGC? Thanks. ------------------------------------------------------------ Seunghan Choi VoIP Technology Team, Network Service Dept. Electronics & Telecommunications Research Institute 161 Kajong-Dong, Yusong-Gu, Taejon, Korea Tel + 82 42 860 6343 Fax + 82 42 860 6342 Mobile 011 455 9524 Email shchoi@etri.re.kr spamcontrol ------_=_NextPart_001_01C35BE3.80DFF2D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable [Megaco]Question about R2 signaling

Hi, All.

It is natural that MGC is responsible for signaling = control and MG is responsible for media control in MGC-MG model. So, I = think that ,for R2 signaling service,

MGC should perform protocol state machine for R2 and = MG should just report R2 related signals and trigger R2 related signals = by MGC. Bu, according to H.248.26 "Basic CAS Packages", CAS = Failure event means that MG is acting like operating protocol state = machine for R2 signaling.

Is it necesary that both MGC and MG have protocol = state machine for R2 signaling? If it is OK, Is the reason that the = protocol state machine of MG corrects that of MGC?

Thanks.

------------------------------------------------------------ =
Seunghan Choi
VoIP Technology Team, Network Service Dept.
Electronics & Telecommunications Research = Institute
161 Kajong-Dong, Yusong-Gu, Taejon, Korea
Tel  + 82 42 860 6343    = Fax  + 82 42 860 6342
Mobile  011 455 9524    = Email  shchoi@etri.re.kr

spamcontrol

------_=_NextPart_001_01C35BE3.80DFF2D0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Aug 6 02:27:36 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 CAA04116 for ; Wed, 6 Aug 2003 02:27: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 19kHlM-0000Rl-SH for megaco-archive@odin.ietf.org; Wed, 06 Aug 2003 02:27:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h766R8pg001718 for megaco-archive@odin.ietf.org; Wed, 6 Aug 2003 02:27:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kHlM-0000RZ-Cy for megaco-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 02:27: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 CAA03704 for ; Wed, 6 Aug 2003 02:27:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kHlI-0000k4-00 for megaco-web-archive@ietf.org; Wed, 06 Aug 2003 02:27:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kHlI-0000k0-00 for megaco-web-archive@ietf.org; Wed, 06 Aug 2003 02:27:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kHlF-0000Qq-Lw; Wed, 06 Aug 2003 02:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kHkL-0000O8-Bf for megaco@optimus.ietf.org; Wed, 06 Aug 2003 02:26: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 CAA02750 for ; Wed, 6 Aug 2003 02:26:01 -0400 (EDT) From: shchoi@etri.re.kr Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kHkH-0000je-00 for megaco@ietf.org; Wed, 06 Aug 2003 02:26:01 -0400 Received: from cms1.etri.re.kr ([129.254.16.11] helo=cms1.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 19kHkG-0000jb-00 for megaco@ietf.org; Wed, 06 Aug 2003 02:26:00 -0400 Received: by cms1 with Internet Mail Service (5.5.2655.55) id ; Wed, 6 Aug 2003 15:25:18 +0900 Message-ID: <4A0AE1E5A1AAD711AC1B00D0B7C2D4A279387C@cms1> To: megaco@ietf.org Date: Wed, 6 Aug 2003 15:25:17 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35BE3.80DFF2D0" Subject: [Megaco] [Megaco]Question about R2 signaling Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C35BE3.80DFF2D0 Content-Type: text/plain Hi, All. It is natural that MGC is responsible for signaling control and MG is responsible for media control in MGC-MG model. So, I think that ,for R2 signaling service, MGC should perform protocol state machine for R2 and MG should just report R2 related signals and trigger R2 related signals by MGC. Bu, according to H.248.26 "Basic CAS Packages", CAS Failure event means that MG is acting like operating protocol state machine for R2 signaling. Is it necesary that both MGC and MG have protocol state machine for R2 signaling? If it is OK, Is the reason that the protocol state machine of MG corrects that of MGC? Thanks. ------------------------------------------------------------ Seunghan Choi VoIP Technology Team, Network Service Dept. Electronics & Telecommunications Research Institute 161 Kajong-Dong, Yusong-Gu, Taejon, Korea Tel + 82 42 860 6343 Fax + 82 42 860 6342 Mobile 011 455 9524 Email shchoi@etri.re.kr spamcontrol ------_=_NextPart_001_01C35BE3.80DFF2D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable [Megaco]Question about R2 signaling

Hi, All.

It is natural that MGC is responsible for signaling = control and MG is responsible for media control in MGC-MG model. So, I = think that ,for R2 signaling service,

MGC should perform protocol state machine for R2 and = MG should just report R2 related signals and trigger R2 related signals = by MGC. Bu, according to H.248.26 "Basic CAS Packages", CAS = Failure event means that MG is acting like operating protocol state = machine for R2 signaling.

Is it necesary that both MGC and MG have protocol = state machine for R2 signaling? If it is OK, Is the reason that the = protocol state machine of MG corrects that of MGC?

Thanks.

------------------------------------------------------------ =
Seunghan Choi
VoIP Technology Team, Network Service Dept.
Electronics & Telecommunications Research = Institute
161 Kajong-Dong, Yusong-Gu, Taejon, Korea
Tel  + 82 42 860 6343    = Fax  + 82 42 860 6342
Mobile  011 455 9524    = Email  shchoi@etri.re.kr

spamcontrol

------_=_NextPart_001_01C35BE3.80DFF2D0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Aug 6 11:14: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 LAA20711 for ; Wed, 6 Aug 2003 11:14: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 19kPzF-0001Ry-Ex; Wed, 06 Aug 2003 11:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPyq-0001Rb-P2 for megaco@optimus.ietf.org; Wed, 06 Aug 2003 11:13:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20568 for ; Wed, 6 Aug 2003 11:13:33 -0400 (EDT) From: klaha@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kPyp-0003iR-00 for megaco@ietf.org; Wed, 06 Aug 2003 11:13:35 -0400 Received: from [202.54.26.202] (helo=hindon.hss.co.in) by ietf-mx with esmtp (Exim 4.12) id 19kPyo-0003g1-00 for megaco@ietf.org; Wed, 06 Aug 2003 11:13:34 -0400 Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h76FALw06381; Wed, 6 Aug 2003 20:40:21 +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 h76FCuv13399; Wed, 6 Aug 2003 20:42:56 +0530 (IST) Subject: Re: [Megaco] [Megaco]Question about R2 signaling To: shchoi@etri.re.kr Cc: megaco@ietf.org Date: Wed, 6 Aug 2003 20:35:59 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 06/08/2003 08:35:59 PM MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable 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 MGC runs the call state machine and MG runs the protocol signalling sta= te machine. Irrespective of the CAS protocol running at MG, the MGC call state mach= ine does not change. The objective is to hide the MGC from the CAS protocol differences and variants as far as possible. Further, having all CAS protocol states recognised/triggered by MGC a) increases MGC-MG traffic b) results into CAS protocol timeouts at MG. regards, Kushanava shchoi@etri.re.kr@ietf.org on 08/06/2003 11:55:17 AM Sent by: megaco-admin@ietf.org To: megaco@ietf.org cc: Subject: [Megaco] [Megaco]Question about R2 signaling Hi, All. It is natural that MGC is responsible for signaling control and MG is responsible for media control in MGC-MG model. So, I think that ,for R2= signaling service, MGC should perform protocol state machine for R2 and MG should just rep= ort R2 related signals and trigger R2 related signals by MGC. Bu, according= to H.248.26 "Basic CAS Packages", CAS Failure event means that MG is actin= g like operating protocol state machine for R2 signaling. Is it necesary that both MGC and MG have protocol state machine for R2 signaling? If it is OK, Is the reason that the protocol state machine o= f MG corrects that of MGC? Thanks. ------------------------------------------------------------ Seunghan Choi VoIP Technology Team, Network Service Dept. Electronics & Telecommunications Research Institute 161 Kajong-Dong, Yusong-Gu, Taejon, Korea Tel=A0 + 82 42 860 6343=A0=A0=A0 Fax=A0 + 82 42 860 6342 Mobile=A0 011 455 9524=A0=A0=A0 Email=A0 shchoi@etri.re.kr spamcontrol = _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Aug 6 11:14: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 LAA20726 for ; Wed, 6 Aug 2003 11:14: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 19kPzK-0001Sn-HP for megaco-archive@odin.ietf.org; Wed, 06 Aug 2003 11:14:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76FE6L4005619 for megaco-archive@odin.ietf.org; Wed, 6 Aug 2003 11:14:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPzK-0001SY-Dx for megaco-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 11:14: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 LAA20681 for ; Wed, 6 Aug 2003 11:14:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kPzJ-0003km-00 for megaco-web-archive@ietf.org; Wed, 06 Aug 2003 11:14:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kPzI-0003kj-00 for megaco-web-archive@ietf.org; Wed, 06 Aug 2003 11:14:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPzF-0001Ry-Ex; Wed, 06 Aug 2003 11:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPyq-0001Rb-P2 for megaco@optimus.ietf.org; Wed, 06 Aug 2003 11:13:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20568 for ; Wed, 6 Aug 2003 11:13:33 -0400 (EDT) From: klaha@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kPyp-0003iR-00 for megaco@ietf.org; Wed, 06 Aug 2003 11:13:35 -0400 Received: from [202.54.26.202] (helo=hindon.hss.co.in) by ietf-mx with esmtp (Exim 4.12) id 19kPyo-0003g1-00 for megaco@ietf.org; Wed, 06 Aug 2003 11:13:34 -0400 Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h76FALw06381; Wed, 6 Aug 2003 20:40:21 +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 h76FCuv13399; Wed, 6 Aug 2003 20:42:56 +0530 (IST) Subject: Re: [Megaco] [Megaco]Question about R2 signaling To: shchoi@etri.re.kr Cc: megaco@ietf.org Date: Wed, 6 Aug 2003 20:35:59 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 06/08/2003 08:35:59 PM MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable 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 MGC runs the call state machine and MG runs the protocol signalling sta= te machine. Irrespective of the CAS protocol running at MG, the MGC call state mach= ine does not change. The objective is to hide the MGC from the CAS protocol differences and variants as far as possible. Further, having all CAS protocol states recognised/triggered by MGC a) increases MGC-MG traffic b) results into CAS protocol timeouts at MG. regards, Kushanava shchoi@etri.re.kr@ietf.org on 08/06/2003 11:55:17 AM Sent by: megaco-admin@ietf.org To: megaco@ietf.org cc: Subject: [Megaco] [Megaco]Question about R2 signaling Hi, All. It is natural that MGC is responsible for signaling control and MG is responsible for media control in MGC-MG model. So, I think that ,for R2= signaling service, MGC should perform protocol state machine for R2 and MG should just rep= ort R2 related signals and trigger R2 related signals by MGC. Bu, according= to H.248.26 "Basic CAS Packages", CAS Failure event means that MG is actin= g like operating protocol state machine for R2 signaling. Is it necesary that both MGC and MG have protocol state machine for R2 signaling? If it is OK, Is the reason that the protocol state machine o= f MG corrects that of MGC? Thanks. ------------------------------------------------------------ Seunghan Choi VoIP Technology Team, Network Service Dept. Electronics & Telecommunications Research Institute 161 Kajong-Dong, Yusong-Gu, Taejon, Korea Tel=A0 + 82 42 860 6343=A0=A0=A0 Fax=A0 + 82 42 860 6342 Mobile=A0 011 455 9524=A0=A0=A0 Email=A0 shchoi@etri.re.kr spamcontrol = _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Aug 7 01:27:28 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 BAA18596 for ; Thu, 7 Aug 2003 01:27:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kdIj-0002ds-6d; Thu, 07 Aug 2003 01:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kdHu-0002dF-Ut for megaco@optimus.ietf.org; Thu, 07 Aug 2003 01:26: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 BAA18579 for ; Thu, 7 Aug 2003 01:26:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kdHr-0002ko-00 for megaco@ietf.org; Thu, 07 Aug 2003 01:26:07 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19kdHq-0002ke-00 for megaco@ietf.org; Thu, 07 Aug 2003 01:26:06 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h775MaF16091; Thu, 7 Aug 2003 15:22:40 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.217]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QBTF7WQ9; Thu, 7 Aug 2003 15:25:50 +1000 Message-ID: <3F31E2EF.5030800@ericsson.com.au> Date: Thu, 07 Aug 2003 15:26:07 +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: micael.karlberg@ericsson.com CC: Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> 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 G'Day Micael, all, Back from holiday and I'm the guy who concocted this syntax. I certainly didn't mean to introduce this ambiguity into the ABNF (its why I dislike ABNF) but it did slip past everyone else until now. So as has been mentioned by Tom we need to fix this. So how about we delete audititem from? It removes the ambiguity. auditReturnParameter = (mediaDescriptor / modemDescriptor / muxDescriptor / eventsDescriptor / signalsDescriptor / digitMapDescriptor / observedEventsDescriptor / eventBufferDescriptor / statisticsDescriptor / packagesDescriptor / errorDescriptor / auditItem) and restore this to v1. The individual auditing mechanism was only meant to change the request mechanisn not what was returned as the "usual" audit reply should have been enough to send the data back that you need. Does this solve the problem. If not, Micael as you need unambiguous syntax can you propose a simple ABNF fix that would solve your problem/s? Regards, Christian Micael Karlberg wrote: > So, now we have yet another parse conflict regarding 'EventBufferToken'? > > We three rules: > > 1) auditItem -> 'EventBufferToken' > 2) eventBufferDescriptor -> 'EventBufferToken' > [ LBRKT eventSpec *(COMMA eventSpec) RBRKT ] > 3) indAudeventBufferDescriptor -> 'EventBufferToken' > LBRKT indAudeventSpec RBRKT > > One conflict between rule 1) and 2) and now another conflict > between rule 2) and 3) > > So, depending on the number of tokens after the 'EventBufferToken', we get: > - Zero -> auditItem > - One -> indAudeventBufferDescriptor > - Two or more -> eventBufferDescriptor > > Is this correct? > > Regards, > /BMK > > Anil Jangam writes: > > This particular question has been repeated for a number of times so far. > > Even I had the same doubt for which Tom has replied as follows: (Marked with > > ####>). > > I think we need to fix this now. > > > > ####> STARTS > > ----- Original Message ----- > > From: Tom-PT Taylor > > To: 'Anil Jangam' ; Kevin Boyle > > 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. > > ####> ENDS > > > > ----- Original Message ----- > > From: "Micael Karlberg" > > To: > > Sent: Thursday, July 17, 2003 3:16 PM > > Subject: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF > > > > > > > Hi, > > > > > > The 'auditReturnParameter' appears to be ambiguously defined in version 2 > > > of the ABNF. > > > > > > An example. If the 'auditReturnParameter' contains the following > > > sequence of tokens: > > > > > > "EB { hobbes }" > > > > > > i.e. > > > > > > EventBufferToken LBRKT pkgdName RBRKT > > > > > > then it may be an 'auditItem' (see 'indAudeventBufferDescriptor') or an > > > 'eventBufferDescriptor' > > > > > > What is the intention here? Should this sequence of tokens be > > > interpreted as an 'auditItem' or an 'eventBufferDescriptor? > > > > > > As a parser implementor I need a well defined, unambiguous grammar to > > > rely on. > > > > > > The grammar looks like this (a little bit simplified): > > > > > > auditReturnParameter = eventBufferDescriptor / auditItem > > > > > > eventBufferDescriptor = EventBufferToken > > > [ LBRKT eventSpec *(COMMA eventSpec) > > RBRKT] > > > > > > eventSpec = pkgdName > > > [ LBRKT eventSpecParameter > > > *(COMMA eventSpecParameter) RBRKT] > > > > > > auditItem = indAudterminationAudit > > > > > > indAudterminationAudit = indAudauditReturnParameter > > > *(COMMA insAudauditReturnParameter) > > > > > > indAudauditReturnParameter = indAudeventBufferDescriptor > > > > > > indAudeventBufferDescriptor = EventBufferToken LBRKT indAudeventSpec > > RBRKT > > > > > > indAudeventSpec = pkgdName > > > [ LBRKT indAudeventSpecParameter RBRKT ] > > > > > > > > > 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 exim@www1.ietf.org Thu Aug 7 01:27: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 BAA18611 for ; Thu, 7 Aug 2003 01:27: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 19kdIm-0002ef-3A for megaco-archive@odin.ietf.org; Thu, 07 Aug 2003 01:27:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h775R49m010201 for megaco-archive@odin.ietf.org; Thu, 7 Aug 2003 01:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kdIm-0002eS-05 for megaco-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 01:27: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 BAA18586 for ; Thu, 7 Aug 2003 01:26:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kdIi-0002l6-00 for megaco-web-archive@ietf.org; Thu, 07 Aug 2003 01:27:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kdIi-0002l3-00 for megaco-web-archive@ietf.org; Thu, 07 Aug 2003 01:27:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kdIj-0002ds-6d; Thu, 07 Aug 2003 01:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kdHu-0002dF-Ut for megaco@optimus.ietf.org; Thu, 07 Aug 2003 01:26: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 BAA18579 for ; Thu, 7 Aug 2003 01:26:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kdHr-0002ko-00 for megaco@ietf.org; Thu, 07 Aug 2003 01:26:07 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19kdHq-0002ke-00 for megaco@ietf.org; Thu, 07 Aug 2003 01:26:06 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h775MaF16091; Thu, 7 Aug 2003 15:22:40 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.217]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QBTF7WQ9; Thu, 7 Aug 2003 15:25:50 +1000 Message-ID: <3F31E2EF.5030800@ericsson.com.au> Date: Thu, 07 Aug 2003 15:26:07 +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: micael.karlberg@ericsson.com CC: Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> 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 G'Day Micael, all, Back from holiday and I'm the guy who concocted this syntax. I certainly didn't mean to introduce this ambiguity into the ABNF (its why I dislike ABNF) but it did slip past everyone else until now. So as has been mentioned by Tom we need to fix this. So how about we delete audititem from? It removes the ambiguity. auditReturnParameter = (mediaDescriptor / modemDescriptor / muxDescriptor / eventsDescriptor / signalsDescriptor / digitMapDescriptor / observedEventsDescriptor / eventBufferDescriptor / statisticsDescriptor / packagesDescriptor / errorDescriptor / auditItem) and restore this to v1. The individual auditing mechanism was only meant to change the request mechanisn not what was returned as the "usual" audit reply should have been enough to send the data back that you need. Does this solve the problem. If not, Micael as you need unambiguous syntax can you propose a simple ABNF fix that would solve your problem/s? Regards, Christian Micael Karlberg wrote: > So, now we have yet another parse conflict regarding 'EventBufferToken'? > > We three rules: > > 1) auditItem -> 'EventBufferToken' > 2) eventBufferDescriptor -> 'EventBufferToken' > [ LBRKT eventSpec *(COMMA eventSpec) RBRKT ] > 3) indAudeventBufferDescriptor -> 'EventBufferToken' > LBRKT indAudeventSpec RBRKT > > One conflict between rule 1) and 2) and now another conflict > between rule 2) and 3) > > So, depending on the number of tokens after the 'EventBufferToken', we get: > - Zero -> auditItem > - One -> indAudeventBufferDescriptor > - Two or more -> eventBufferDescriptor > > Is this correct? > > Regards, > /BMK > > Anil Jangam writes: > > This particular question has been repeated for a number of times so far. > > Even I had the same doubt for which Tom has replied as follows: (Marked with > > ####>). > > I think we need to fix this now. > > > > ####> STARTS > > ----- Original Message ----- > > From: Tom-PT Taylor > > To: 'Anil Jangam' ; Kevin Boyle > > 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. > > ####> ENDS > > > > ----- Original Message ----- > > From: "Micael Karlberg" > > To: > > Sent: Thursday, July 17, 2003 3:16 PM > > Subject: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF > > > > > > > Hi, > > > > > > The 'auditReturnParameter' appears to be ambiguously defined in version 2 > > > of the ABNF. > > > > > > An example. If the 'auditReturnParameter' contains the following > > > sequence of tokens: > > > > > > "EB { hobbes }" > > > > > > i.e. > > > > > > EventBufferToken LBRKT pkgdName RBRKT > > > > > > then it may be an 'auditItem' (see 'indAudeventBufferDescriptor') or an > > > 'eventBufferDescriptor' > > > > > > What is the intention here? Should this sequence of tokens be > > > interpreted as an 'auditItem' or an 'eventBufferDescriptor? > > > > > > As a parser implementor I need a well defined, unambiguous grammar to > > > rely on. > > > > > > The grammar looks like this (a little bit simplified): > > > > > > auditReturnParameter = eventBufferDescriptor / auditItem > > > > > > eventBufferDescriptor = EventBufferToken > > > [ LBRKT eventSpec *(COMMA eventSpec) > > RBRKT] > > > > > > eventSpec = pkgdName > > > [ LBRKT eventSpecParameter > > > *(COMMA eventSpecParameter) RBRKT] > > > > > > auditItem = indAudterminationAudit > > > > > > indAudterminationAudit = indAudauditReturnParameter > > > *(COMMA insAudauditReturnParameter) > > > > > > indAudauditReturnParameter = indAudeventBufferDescriptor > > > > > > indAudeventBufferDescriptor = EventBufferToken LBRKT indAudeventSpec > > RBRKT > > > > > > indAudeventSpec = pkgdName > > > [ LBRKT indAudeventSpecParameter RBRKT ] > > > > > > > > > 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 Thu Aug 7 05:33:27 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 FAA05550 for ; Thu, 7 Aug 2003 05:33:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kh8n-0004la-6R; Thu, 07 Aug 2003 05:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kh7w-0004l2-S8 for megaco@optimus.ietf.org; Thu, 07 Aug 2003 05:32: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 FAA05525 for ; Thu, 7 Aug 2003 05:32:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kh7t-0004Hn-00 for megaco@ietf.org; Thu, 07 Aug 2003 05:32:05 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19kh7s-0004Hk-00 for megaco@ietf.org; Thu, 07 Aug 2003 05:32:04 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h779W17W016473; Thu, 7 Aug 2003 11:32:01 +0200 (MEST) Received: from super.du.uab.ericsson.se ([134.138.176.16]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id QL80D35Q; Thu, 7 Aug 2003 11:32:01 +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 h779VxH18613; Thu, 7 Aug 2003 11:31:59 +0200 (MET DST) Received: (from bmk@localhost) by bifur.du.uab.ericsson.se (8.11.6+Sun/8.9.1/client-1.0) id h779VxF14380; Thu, 7 Aug 2003 11:31:59 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16178.7310.437463.16305@gargle.gargle.HOWL> Date: Thu, 7 Aug 2003 11:31:58 +0200 From: Micael Karlberg Reply-To: micael.karlberg@ericsson.com Organization: Ericsson AB (EAB/UKH/KD) To: Christian Groves Cc: micael.karlberg@ericsson.com, Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF In-Reply-To: <3F31E2EF.5030800@ericsson.com.au> References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> X-Mailer: VM 7.07 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Christian Groves writes: > G'Day Micael, all, > > Back from holiday and I'm the guy who concocted this syntax. I certainly > didn't mean to introduce this ambiguity into the ABNF (its why I dislike > ABNF) but it did slip past everyone else until now. I really which there was some tool to check ABNF easilly, then these kind of problems would occure with much less frequency. For ASN.1 you just feed it to your ASN.1 compiler and your done. Same goes for MIBs. > > So as has been mentioned by Tom we need to fix this. So how about we delete > audititem from? It removes the ambiguity. > auditReturnParameter = (mediaDescriptor / modemDescriptor / > muxDescriptor / eventsDescriptor / > signalsDescriptor / digitMapDescriptor / > observedEventsDescriptor / eventBufferDescriptor / > statisticsDescriptor / packagesDescriptor / > errorDescriptor / auditItem) > > and restore this to v1. Delete auditItem from auditReturnParameter? But auditItem was part of auditReturnParameter even in v1. > The individual auditing mechanism was only meant to change the request > mechanisn not what was returned as the "usual" audit reply > should have been enough to send the data back that you need. Does this > solve the problem. If not, Micael as you need unambiguous syntax can you > propose a simple ABNF fix that would solve your problem/s? I really hope that I am not the only one who is writing a version 2 parser, or else I am wasting my time (or are about to strike gold :) As for a solution, how about adding a token and changing the definition of indAudterminationAudit to: indAudterminationAudit = IndAudTerminationAuditToken indAudauditReturnParameter *(COMMA indAudauditReturnParameter) Not pretty, but it should do the trick. I have not tested it with real messages, but atleast my parser generator did not complain anymore. > > Regards, Christian Regards, /BMK > > > Micael Karlberg wrote: > > So, now we have yet another parse conflict regarding 'EventBufferToken'? > > > > We have three rules: > > > > 1) auditItem -> 'EventBufferToken' > > 2) eventBufferDescriptor -> 'EventBufferToken' > > [ LBRKT eventSpec *(COMMA eventSpec) RBRKT ] > > 3) indAudeventBufferDescriptor -> 'EventBufferToken' > > LBRKT indAudeventSpec RBRKT > > > > One conflict between rule 1) and 2) and now another conflict > > between rule 2) and 3) > > > > So, depending on the number of tokens after the 'EventBufferToken', we get: > > - Zero -> auditItem > > - One -> indAudeventBufferDescriptor > > - Two or more -> eventBufferDescriptor > > > > Is this correct? > > > > Regards, > > /BMK > > > > Anil Jangam writes: > > > This particular question has been repeated for a number of times so far. > > > Even I had the same doubt for which Tom has replied as follows: (Marked with > > > ####>). > > > I think we need to fix this now. > > > > > > ####> STARTS > > > ----- Original Message ----- > > > From: Tom-PT Taylor > > > To: 'Anil Jangam' ; Kevin Boyle > > > 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. > > > ####> ENDS > > > > > > ----- Original Message ----- > > > From: "Micael Karlberg" > > > To: > > > Sent: Thursday, July 17, 2003 3:16 PM > > > Subject: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF > > > > > > > > > > Hi, > > > > > > > > The 'auditReturnParameter' appears to be ambiguously defined in version 2 > > > > of the ABNF. > > > > > > > > An example. If the 'auditReturnParameter' contains the following > > > > sequence of tokens: > > > > > > > > "EB { hobbes }" > > > > > > > > i.e. > > > > > > > > EventBufferToken LBRKT pkgdName RBRKT > > > > > > > > then it may be an 'auditItem' (see 'indAudeventBufferDescriptor') or an > > > > 'eventBufferDescriptor' > > > > > > > > What is the intention here? Should this sequence of tokens be > > > > interpreted as an 'auditItem' or an 'eventBufferDescriptor? > > > > > > > > As a parser implementor I need a well defined, unambiguous grammar to > > > > rely on. > > > > > > > > The grammar looks like this (a little bit simplified): > > > > > > > > auditReturnParameter = eventBufferDescriptor / auditItem > > > > > > > > eventBufferDescriptor = EventBufferToken > > > > [ LBRKT eventSpec *(COMMA eventSpec) > > > RBRKT] > > > > > > > > eventSpec = pkgdName > > > > [ LBRKT eventSpecParameter > > > > *(COMMA eventSpecParameter) RBRKT] > > > > > > > > auditItem = indAudterminationAudit > > > > > > > > indAudterminationAudit = indAudauditReturnParameter > > > > *(COMMA insAudauditReturnParameter) > > > > > > > > indAudauditReturnParameter = indAudeventBufferDescriptor > > > > > > > > indAudeventBufferDescriptor = EventBufferToken LBRKT indAudeventSpec > > > RBRKT > > > > > > > > indAudeventSpec = pkgdName > > > > [ LBRKT indAudeventSpecParameter RBRKT ] > > > > > > > > > > > > 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 exim@www1.ietf.org Thu Aug 7 05: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 FAA05565 for ; Thu, 7 Aug 2003 05: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 19kh8r-0004mR-9H for megaco-archive@odin.ietf.org; Thu, 07 Aug 2003 05:33:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h779X55h018373 for megaco-archive@odin.ietf.org; Thu, 7 Aug 2003 05:33:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kh8r-0004mG-61 for megaco-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 05:33: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 FAA05539 for ; Thu, 7 Aug 2003 05:32:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kh8n-0004I8-00 for megaco-web-archive@ietf.org; Thu, 07 Aug 2003 05:33:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kh8n-0004I4-00 for megaco-web-archive@ietf.org; Thu, 07 Aug 2003 05:33:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kh8n-0004la-6R; Thu, 07 Aug 2003 05:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kh7w-0004l2-S8 for megaco@optimus.ietf.org; Thu, 07 Aug 2003 05:32: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 FAA05525 for ; Thu, 7 Aug 2003 05:32:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kh7t-0004Hn-00 for megaco@ietf.org; Thu, 07 Aug 2003 05:32:05 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19kh7s-0004Hk-00 for megaco@ietf.org; Thu, 07 Aug 2003 05:32:04 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h779W17W016473; Thu, 7 Aug 2003 11:32:01 +0200 (MEST) Received: from super.du.uab.ericsson.se ([134.138.176.16]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id QL80D35Q; Thu, 7 Aug 2003 11:32:01 +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 h779VxH18613; Thu, 7 Aug 2003 11:31:59 +0200 (MET DST) Received: (from bmk@localhost) by bifur.du.uab.ericsson.se (8.11.6+Sun/8.9.1/client-1.0) id h779VxF14380; Thu, 7 Aug 2003 11:31:59 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16178.7310.437463.16305@gargle.gargle.HOWL> Date: Thu, 7 Aug 2003 11:31:58 +0200 From: Micael Karlberg Reply-To: micael.karlberg@ericsson.com Organization: Ericsson AB (EAB/UKH/KD) To: Christian Groves Cc: micael.karlberg@ericsson.com, Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF In-Reply-To: <3F31E2EF.5030800@ericsson.com.au> References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> X-Mailer: VM 7.07 under Emacs 21.1.1 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, Christian Groves writes: > G'Day Micael, all, > > Back from holiday and I'm the guy who concocted this syntax. I certainly > didn't mean to introduce this ambiguity into the ABNF (its why I dislike > ABNF) but it did slip past everyone else until now. I really which there was some tool to check ABNF easilly, then these kind of problems would occure with much less frequency. For ASN.1 you just feed it to your ASN.1 compiler and your done. Same goes for MIBs. > > So as has been mentioned by Tom we need to fix this. So how about we delete > audititem from? It removes the ambiguity. > auditReturnParameter = (mediaDescriptor / modemDescriptor / > muxDescriptor / eventsDescriptor / > signalsDescriptor / digitMapDescriptor / > observedEventsDescriptor / eventBufferDescriptor / > statisticsDescriptor / packagesDescriptor / > errorDescriptor / auditItem) > > and restore this to v1. Delete auditItem from auditReturnParameter? But auditItem was part of auditReturnParameter even in v1. > The individual auditing mechanism was only meant to change the request > mechanisn not what was returned as the "usual" audit reply > should have been enough to send the data back that you need. Does this > solve the problem. If not, Micael as you need unambiguous syntax can you > propose a simple ABNF fix that would solve your problem/s? I really hope that I am not the only one who is writing a version 2 parser, or else I am wasting my time (or are about to strike gold :) As for a solution, how about adding a token and changing the definition of indAudterminationAudit to: indAudterminationAudit = IndAudTerminationAuditToken indAudauditReturnParameter *(COMMA indAudauditReturnParameter) Not pretty, but it should do the trick. I have not tested it with real messages, but atleast my parser generator did not complain anymore. > > Regards, Christian Regards, /BMK > > > Micael Karlberg wrote: > > So, now we have yet another parse conflict regarding 'EventBufferToken'? > > > > We have three rules: > > > > 1) auditItem -> 'EventBufferToken' > > 2) eventBufferDescriptor -> 'EventBufferToken' > > [ LBRKT eventSpec *(COMMA eventSpec) RBRKT ] > > 3) indAudeventBufferDescriptor -> 'EventBufferToken' > > LBRKT indAudeventSpec RBRKT > > > > One conflict between rule 1) and 2) and now another conflict > > between rule 2) and 3) > > > > So, depending on the number of tokens after the 'EventBufferToken', we get: > > - Zero -> auditItem > > - One -> indAudeventBufferDescriptor > > - Two or more -> eventBufferDescriptor > > > > Is this correct? > > > > Regards, > > /BMK > > > > Anil Jangam writes: > > > This particular question has been repeated for a number of times so far. > > > Even I had the same doubt for which Tom has replied as follows: (Marked with > > > ####>). > > > I think we need to fix this now. > > > > > > ####> STARTS > > > ----- Original Message ----- > > > From: Tom-PT Taylor > > > To: 'Anil Jangam' ; Kevin Boyle > > > 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. > > > ####> ENDS > > > > > > ----- Original Message ----- > > > From: "Micael Karlberg" > > > To: > > > Sent: Thursday, July 17, 2003 3:16 PM > > > Subject: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF > > > > > > > > > > Hi, > > > > > > > > The 'auditReturnParameter' appears to be ambiguously defined in version 2 > > > > of the ABNF. > > > > > > > > An example. If the 'auditReturnParameter' contains the following > > > > sequence of tokens: > > > > > > > > "EB { hobbes }" > > > > > > > > i.e. > > > > > > > > EventBufferToken LBRKT pkgdName RBRKT > > > > > > > > then it may be an 'auditItem' (see 'indAudeventBufferDescriptor') or an > > > > 'eventBufferDescriptor' > > > > > > > > What is the intention here? Should this sequence of tokens be > > > > interpreted as an 'auditItem' or an 'eventBufferDescriptor? > > > > > > > > As a parser implementor I need a well defined, unambiguous grammar to > > > > rely on. > > > > > > > > The grammar looks like this (a little bit simplified): > > > > > > > > auditReturnParameter = eventBufferDescriptor / auditItem > > > > > > > > eventBufferDescriptor = EventBufferToken > > > > [ LBRKT eventSpec *(COMMA eventSpec) > > > RBRKT] > > > > > > > > eventSpec = pkgdName > > > > [ LBRKT eventSpecParameter > > > > *(COMMA eventSpecParameter) RBRKT] > > > > > > > > auditItem = indAudterminationAudit > > > > > > > > indAudterminationAudit = indAudauditReturnParameter > > > > *(COMMA insAudauditReturnParameter) > > > > > > > > indAudauditReturnParameter = indAudeventBufferDescriptor > > > > > > > > indAudeventBufferDescriptor = EventBufferToken LBRKT indAudeventSpec > > > RBRKT > > > > > > > > indAudeventSpec = pkgdName > > > > [ LBRKT indAudeventSpecParameter RBRKT ] > > > > > > > > > > > > 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 Thu Aug 7 10:28:11 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 KAA16605 for ; Thu, 7 Aug 2003 10:28:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kljJ-0007a7-JY; Thu, 07 Aug 2003 10:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kliS-0007ZC-Tr for megaco@optimus.ietf.org; Thu, 07 Aug 2003 10:26: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 KAA16509 for ; Thu, 7 Aug 2003 10:26:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kliQ-0006zL-00 for megaco@ietf.org; Thu, 07 Aug 2003 10:26:06 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19kliP-0006yj-00 for megaco@ietf.org; Thu, 07 Aug 2003 10:26:05 -0400 Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h77EPJ727777 for ; Thu, 7 Aug 2003 09:25:20 -0500 (CDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA19797; Thu, 7 Aug 2003 10:25:27 -0400 (EDT) Cc: micael.karlberg@ericsson.com, Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA19778; Thu, 7 Aug 2003 10:25:25 -0400 (EDT) Message-ID: <3F32614D.6070505@bell-labs.com> Date: Thu, 07 Aug 2003 10:25:17 -0400 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Groves Original-CC: micael.karlberg@ericsson.com, Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> In-Reply-To: <3F31E2EF.5030800@ericsson.com.au> 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 Is there something here that isn't already handled by 6.3 in the IG? http://www.itu.int/itudoc/itu-t/com16/implgd/h248s-ig.pdf -troy Christian Groves wrote: > G'Day Micael, all, > > Back from holiday and I'm the guy who concocted this syntax. I certainly > didn't mean to introduce this ambiguity into the ABNF (its why I dislike > ABNF) but it did slip past everyone else until now. > > So as has been mentioned by Tom we need to fix this. So how about we > delete audititem from? It removes the ambiguity. > auditReturnParameter = (mediaDescriptor / modemDescriptor / > muxDescriptor / eventsDescriptor / > signalsDescriptor / digitMapDescriptor / > observedEventsDescriptor / eventBufferDescriptor / > statisticsDescriptor / packagesDescriptor / > errorDescriptor / auditItem) > > and restore this to v1. The individual auditing mechanism was only meant > to change the request mechanisn not what was returned as the "usual" > audit reply should have been enough to send the data back that you need. > Does this solve the problem. If not, Micael as you need unambiguous > syntax can you propose a simple ABNF fix that would solve your problem/s? > > Regards, Christian > > > Micael Karlberg wrote: > >> So, now we have yet another parse conflict regarding 'EventBufferToken'? >> >> We three rules: >> >> 1) auditItem -> 'EventBufferToken' >> 2) eventBufferDescriptor -> 'EventBufferToken' >> [ LBRKT eventSpec *(COMMA eventSpec) >> RBRKT ] >> 3) indAudeventBufferDescriptor -> 'EventBufferToken' >> LBRKT indAudeventSpec RBRKT >> >> One conflict between rule 1) and 2) and now another conflict >> between rule 2) and 3) >> >> So, depending on the number of tokens after the 'EventBufferToken', we >> get: >> - Zero -> auditItem >> - One -> indAudeventBufferDescriptor >> - Two or more -> eventBufferDescriptor >> >> Is this correct? >> >> Regards, >> /BMK >> >> Anil Jangam writes: >> > This particular question has been repeated for a number of times so >> far. >> > Even I had the same doubt for which Tom has replied as follows: >> (Marked with >> > ####>). >> > I think we need to fix this now. >> > > ####> STARTS >> > ----- Original Message ----- >> > From: Tom-PT Taylor >> > To: 'Anil Jangam' ; Kevin Boyle >> > 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. >> > ####> ENDS >> > > ----- Original Message ----- >> > From: "Micael Karlberg" >> > To: >> > Sent: Thursday, July 17, 2003 3:16 PM >> > Subject: [Megaco] Ambiguous definition of auditReturnParameter in >> v2 ABNF >> > > > > Hi, >> > > >> > > The 'auditReturnParameter' appears to be ambiguously defined in >> version 2 >> > > of the ABNF. >> > > >> > > An example. If the 'auditReturnParameter' contains the following >> > > sequence of tokens: >> > > >> > > "EB { hobbes }" >> > > >> > > i.e. >> > > >> > > EventBufferToken LBRKT pkgdName RBRKT >> > > >> > > then it may be an 'auditItem' (see 'indAudeventBufferDescriptor') >> or an >> > > 'eventBufferDescriptor' >> > > >> > > What is the intention here? Should this sequence of tokens be >> > > interpreted as an 'auditItem' or an 'eventBufferDescriptor? >> > > >> > > As a parser implementor I need a well defined, unambiguous >> grammar to >> > > rely on. >> > > >> > > The grammar looks like this (a little bit simplified): >> > > >> > > auditReturnParameter = eventBufferDescriptor / auditItem >> > > >> > > eventBufferDescriptor = EventBufferToken >> > > [ LBRKT eventSpec *(COMMA eventSpec) >> > RBRKT] >> > > >> > > eventSpec = pkgdName >> > > [ LBRKT eventSpecParameter >> > > *(COMMA >> eventSpecParameter) RBRKT] >> > > >> > > auditItem = indAudterminationAudit >> > > >> > > indAudterminationAudit = indAudauditReturnParameter >> > > *(COMMA insAudauditReturnParameter) >> > > >> > > indAudauditReturnParameter = indAudeventBufferDescriptor >> > > >> > > indAudeventBufferDescriptor = EventBufferToken LBRKT >> indAudeventSpec >> > RBRKT >> > > >> > > indAudeventSpec = pkgdName >> > > [ LBRKT indAudeventSpecParameter >> RBRKT ] >> > > >> > > >> > > Regards, >> > > /BMK _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Aug 7 10:28:16 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 KAA16620 for ; Thu, 7 Aug 2003 10:28:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19klk5-0007fl-0P for megaco-archive@odin.ietf.org; Thu, 07 Aug 2003 10:27:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77ERm2J029491 for megaco-archive@odin.ietf.org; Thu, 7 Aug 2003 10:27:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19klk4-0007fa-Sf for megaco-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 10:27: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 KAA16585 for ; Thu, 7 Aug 2003 10:27:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19klk2-00070I-00 for megaco-web-archive@ietf.org; Thu, 07 Aug 2003 10:27:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19klk1-00070F-00 for megaco-web-archive@ietf.org; Thu, 07 Aug 2003 10:27:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kljJ-0007a7-JY; Thu, 07 Aug 2003 10:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kliS-0007ZC-Tr for megaco@optimus.ietf.org; Thu, 07 Aug 2003 10:26: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 KAA16509 for ; Thu, 7 Aug 2003 10:26:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kliQ-0006zL-00 for megaco@ietf.org; Thu, 07 Aug 2003 10:26:06 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19kliP-0006yj-00 for megaco@ietf.org; Thu, 07 Aug 2003 10:26:05 -0400 Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h77EPJ727777 for ; Thu, 7 Aug 2003 09:25:20 -0500 (CDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA19797; Thu, 7 Aug 2003 10:25:27 -0400 (EDT) Cc: micael.karlberg@ericsson.com, Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA19778; Thu, 7 Aug 2003 10:25:25 -0400 (EDT) Message-ID: <3F32614D.6070505@bell-labs.com> Date: Thu, 07 Aug 2003 10:25:17 -0400 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Groves Original-CC: micael.karlberg@ericsson.com, Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> In-Reply-To: <3F31E2EF.5030800@ericsson.com.au> 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 Is there something here that isn't already handled by 6.3 in the IG? http://www.itu.int/itudoc/itu-t/com16/implgd/h248s-ig.pdf -troy Christian Groves wrote: > G'Day Micael, all, > > Back from holiday and I'm the guy who concocted this syntax. I certainly > didn't mean to introduce this ambiguity into the ABNF (its why I dislike > ABNF) but it did slip past everyone else until now. > > So as has been mentioned by Tom we need to fix this. So how about we > delete audititem from? It removes the ambiguity. > auditReturnParameter = (mediaDescriptor / modemDescriptor / > muxDescriptor / eventsDescriptor / > signalsDescriptor / digitMapDescriptor / > observedEventsDescriptor / eventBufferDescriptor / > statisticsDescriptor / packagesDescriptor / > errorDescriptor / auditItem) > > and restore this to v1. The individual auditing mechanism was only meant > to change the request mechanisn not what was returned as the "usual" > audit reply should have been enough to send the data back that you need. > Does this solve the problem. If not, Micael as you need unambiguous > syntax can you propose a simple ABNF fix that would solve your problem/s? > > Regards, Christian > > > Micael Karlberg wrote: > >> So, now we have yet another parse conflict regarding 'EventBufferToken'? >> >> We three rules: >> >> 1) auditItem -> 'EventBufferToken' >> 2) eventBufferDescriptor -> 'EventBufferToken' >> [ LBRKT eventSpec *(COMMA eventSpec) >> RBRKT ] >> 3) indAudeventBufferDescriptor -> 'EventBufferToken' >> LBRKT indAudeventSpec RBRKT >> >> One conflict between rule 1) and 2) and now another conflict >> between rule 2) and 3) >> >> So, depending on the number of tokens after the 'EventBufferToken', we >> get: >> - Zero -> auditItem >> - One -> indAudeventBufferDescriptor >> - Two or more -> eventBufferDescriptor >> >> Is this correct? >> >> Regards, >> /BMK >> >> Anil Jangam writes: >> > This particular question has been repeated for a number of times so >> far. >> > Even I had the same doubt for which Tom has replied as follows: >> (Marked with >> > ####>). >> > I think we need to fix this now. >> > > ####> STARTS >> > ----- Original Message ----- >> > From: Tom-PT Taylor >> > To: 'Anil Jangam' ; Kevin Boyle >> > 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. >> > ####> ENDS >> > > ----- Original Message ----- >> > From: "Micael Karlberg" >> > To: >> > Sent: Thursday, July 17, 2003 3:16 PM >> > Subject: [Megaco] Ambiguous definition of auditReturnParameter in >> v2 ABNF >> > > > > Hi, >> > > >> > > The 'auditReturnParameter' appears to be ambiguously defined in >> version 2 >> > > of the ABNF. >> > > >> > > An example. If the 'auditReturnParameter' contains the following >> > > sequence of tokens: >> > > >> > > "EB { hobbes }" >> > > >> > > i.e. >> > > >> > > EventBufferToken LBRKT pkgdName RBRKT >> > > >> > > then it may be an 'auditItem' (see 'indAudeventBufferDescriptor') >> or an >> > > 'eventBufferDescriptor' >> > > >> > > What is the intention here? Should this sequence of tokens be >> > > interpreted as an 'auditItem' or an 'eventBufferDescriptor? >> > > >> > > As a parser implementor I need a well defined, unambiguous >> grammar to >> > > rely on. >> > > >> > > The grammar looks like this (a little bit simplified): >> > > >> > > auditReturnParameter = eventBufferDescriptor / auditItem >> > > >> > > eventBufferDescriptor = EventBufferToken >> > > [ LBRKT eventSpec *(COMMA eventSpec) >> > RBRKT] >> > > >> > > eventSpec = pkgdName >> > > [ LBRKT eventSpecParameter >> > > *(COMMA >> eventSpecParameter) RBRKT] >> > > >> > > auditItem = indAudterminationAudit >> > > >> > > indAudterminationAudit = indAudauditReturnParameter >> > > *(COMMA insAudauditReturnParameter) >> > > >> > > indAudauditReturnParameter = indAudeventBufferDescriptor >> > > >> > > indAudeventBufferDescriptor = EventBufferToken LBRKT >> indAudeventSpec >> > RBRKT >> > > >> > > indAudeventSpec = pkgdName >> > > [ LBRKT indAudeventSpecParameter >> RBRKT ] >> > > >> > > >> > > Regards, >> > > /BMK _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Aug 8 02:17:34 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 CAA29917 for ; Fri, 8 Aug 2003 02:17:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l0Yg-000144-V1; Fri, 08 Aug 2003 02:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l0Yb-00013J-ER for megaco@optimus.ietf.org; Fri, 08 Aug 2003 02:16: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 CAA29812 for ; Fri, 8 Aug 2003 02:16:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l0YX-0005rl-00 for megaco@ietf.org; Fri, 08 Aug 2003 02:16:53 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19l0YW-0005rM-00 for megaco@ietf.org; Fri, 08 Aug 2003 02:16:52 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h786DEF23448; Fri, 8 Aug 2003 16:13:17 +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 QBTF8LVA; Fri, 8 Aug 2003 16:16:29 +1000 Message-ID: <3F332FD0.90309@ericsson.com.au> Date: Fri, 08 Aug 2003 15:06:24 +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: micael.karlberg@ericsson.com CC: Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> <16178.7310.437463.16305@gargle.gargle.HOWL> 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 G'Day Micael, Please see comments below. Regards, Christian Micael Karlberg wrote: > Hi, > > > Christian Groves writes: > > G'Day Micael, all, > > > > Back from holiday and I'm the guy who concocted this syntax. I certainly > > didn't mean to introduce this ambiguity into the ABNF (its why I dislike > > ABNF) but it did slip past everyone else until now. > > > I really which there was some tool to check ABNF easilly, then > these kind of problems would occure with much less frequency. > For ASN.1 you just feed it to your ASN.1 compiler and your done. > Same goes for MIBs. [CHG] Won't hear any complaints from me :). > > > > > > So as has been mentioned by Tom we need to fix this. So how about we delete > > audititem from? It removes the ambiguity. > > auditReturnParameter = (mediaDescriptor / modemDescriptor / > > muxDescriptor / eventsDescriptor / > > signalsDescriptor / digitMapDescriptor / > > observedEventsDescriptor / eventBufferDescriptor / > > statisticsDescriptor / packagesDescriptor / > > errorDescriptor / auditItem) > > > > and restore this to v1. > > > Delete auditItem from auditReturnParameter? But auditItem was part of > auditReturnParameter even in v1. [CHG] Yes, must have been looking at an old version of v1. > > > > The individual auditing mechanism was only meant to change the request > > mechanisn not what was returned as the "usual" audit reply > > should have been enough to send the data back that you need. Does this > > solve the problem. If not, Micael as you need unambiguous syntax can you > > propose a simple ABNF fix that would solve your problem/s? > > > I really hope that I am not the only one who is writing a version 2 > parser, or else I am wasting my time (or are about to strike gold :) > > As for a solution, how about adding a token and changing the > definition of indAudterminationAudit to: > > indAudterminationAudit = IndAudTerminationAuditToken > indAudauditReturnParameter > *(COMMA indAudauditReturnParameter) > > Not pretty, but it should do the trick. I have not tested it > with real messages, but atleast my parser generator did not > complain anymore. [CHG] I think the point is that the MGC shouldn't be concerned whether the audited parameter is from a descriptor audit or an individual audit. The syntax provided for a descriptor audit is enough to return an individual audit. The problem lies that AuditItem is used both in the command request and reply ABNF. I was thinking about a token yesterday myself but when I had a look at the ASN1 and saw that it used existing AuditDescriptor reply syntax I thought we shouldn't allow using the IndAudRep. Would a rule that, ; For audit replys the indAudterminationAudit SHALL not be used. auditItem = ( MuxToken / ModemToken / MediaToken / SignalsToken / EventBufferToken / DigitMapToken / StatsToken / EventsToken / ObservedEventsToken / PackagesToken ) / indAudterminationAudit) Be a solution? Regards, Christian > > > > > > Regards, Christian > > > Regards, > /BMK > > > > > > > Micael Karlberg wrote: > > > So, now we have yet another parse conflict regarding 'EventBufferToken'? > > > > > > We have three rules: > > > > > > 1) auditItem -> 'EventBufferToken' > > > 2) eventBufferDescriptor -> 'EventBufferToken' > > > [ LBRKT eventSpec *(COMMA eventSpec) RBRKT ] > > > 3) indAudeventBufferDescriptor -> 'EventBufferToken' > > > LBRKT indAudeventSpec RBRKT > > > > > > One conflict between rule 1) and 2) and now another conflict > > > between rule 2) and 3) > > > > > > So, depending on the number of tokens after the 'EventBufferToken', we get: > > > - Zero -> auditItem > > > - One -> indAudeventBufferDescriptor > > > - Two or more -> eventBufferDescriptor > > > > > > Is this correct? > > > > > > Regards, > > > /BMK > > > > > > Anil Jangam writes: > > > > This particular question has been repeated for a number of times so far. > > > > Even I had the same doubt for which Tom has replied as follows: (Marked with > > > > ####>). > > > > I think we need to fix this now. > > > > > > > > ####> STARTS > > > > ----- Original Message ----- > > > > From: Tom-PT Taylor > > > > To: 'Anil Jangam' ; Kevin Boyle > > > > 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. > > > > ####> ENDS > > > > > > > > ----- Original Message ----- > > > > From: "Micael Karlberg" > > > > To: > > > > Sent: Thursday, July 17, 2003 3:16 PM > > > > Subject: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF > > > > > > > > > > > > > Hi, > > > > > > > > > > The 'auditReturnParameter' appears to be ambiguously defined in version 2 > > > > > of the ABNF. > > > > > > > > > > An example. If the 'auditReturnParameter' contains the following > > > > > sequence of tokens: > > > > > > > > > > "EB { hobbes }" > > > > > > > > > > i.e. > > > > > > > > > > EventBufferToken LBRKT pkgdName RBRKT > > > > > > > > > > then it may be an 'auditItem' (see 'indAudeventBufferDescriptor') or an > > > > > 'eventBufferDescriptor' > > > > > > > > > > What is the intention here? Should this sequence of tokens be > > > > > interpreted as an 'auditItem' or an 'eventBufferDescriptor? > > > > > > > > > > As a parser implementor I need a well defined, unambiguous grammar to > > > > > rely on. > > > > > > > > > > The grammar looks like this (a little bit simplified): > > > > > > > > > > auditReturnParameter = eventBufferDescriptor / auditItem > > > > > > > > > > eventBufferDescriptor = EventBufferToken > > > > > [ LBRKT eventSpec *(COMMA eventSpec) > > > > RBRKT] > > > > > > > > > > eventSpec = pkgdName > > > > > [ LBRKT eventSpecParameter > > > > > *(COMMA eventSpecParameter) RBRKT] > > > > > > > > > > auditItem = indAudterminationAudit > > > > > > > > > > indAudterminationAudit = indAudauditReturnParameter > > > > > *(COMMA insAudauditReturnParameter) > > > > > > > > > > indAudauditReturnParameter = indAudeventBufferDescriptor > > > > > > > > > > indAudeventBufferDescriptor = EventBufferToken LBRKT indAudeventSpec > > > > RBRKT > > > > > > > > > > indAudeventSpec = pkgdName > > > > > [ LBRKT indAudeventSpecParameter RBRKT ] > > > > > > > > > > > > > > > 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 exim@www1.ietf.org Fri Aug 8 02:17: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 CAA29952 for ; Fri, 8 Aug 2003 02:17:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l0Yp-00017Q-S8 for megaco-archive@odin.ietf.org; Fri, 08 Aug 2003 02:17:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h786HBEg004299 for megaco-archive@odin.ietf.org; Fri, 8 Aug 2003 02:17:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l0Yp-00017A-El for megaco-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 02: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 CAA29865 for ; Fri, 8 Aug 2003 02:17:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l0Yl-0005sp-00 for megaco-web-archive@ietf.org; Fri, 08 Aug 2003 02:17:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l0Yk-0005sl-00 for megaco-web-archive@ietf.org; Fri, 08 Aug 2003 02:17:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l0Yg-000144-V1; Fri, 08 Aug 2003 02:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l0Yb-00013J-ER for megaco@optimus.ietf.org; Fri, 08 Aug 2003 02:16: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 CAA29812 for ; Fri, 8 Aug 2003 02:16:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l0YX-0005rl-00 for megaco@ietf.org; Fri, 08 Aug 2003 02:16:53 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19l0YW-0005rM-00 for megaco@ietf.org; Fri, 08 Aug 2003 02:16:52 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h786DEF23448; Fri, 8 Aug 2003 16:13:17 +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 QBTF8LVA; Fri, 8 Aug 2003 16:16:29 +1000 Message-ID: <3F332FD0.90309@ericsson.com.au> Date: Fri, 08 Aug 2003 15:06:24 +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: micael.karlberg@ericsson.com CC: Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> <16178.7310.437463.16305@gargle.gargle.HOWL> 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 G'Day Micael, Please see comments below. Regards, Christian Micael Karlberg wrote: > Hi, > > > Christian Groves writes: > > G'Day Micael, all, > > > > Back from holiday and I'm the guy who concocted this syntax. I certainly > > didn't mean to introduce this ambiguity into the ABNF (its why I dislike > > ABNF) but it did slip past everyone else until now. > > > I really which there was some tool to check ABNF easilly, then > these kind of problems would occure with much less frequency. > For ASN.1 you just feed it to your ASN.1 compiler and your done. > Same goes for MIBs. [CHG] Won't hear any complaints from me :). > > > > > > So as has been mentioned by Tom we need to fix this. So how about we delete > > audititem from? It removes the ambiguity. > > auditReturnParameter = (mediaDescriptor / modemDescriptor / > > muxDescriptor / eventsDescriptor / > > signalsDescriptor / digitMapDescriptor / > > observedEventsDescriptor / eventBufferDescriptor / > > statisticsDescriptor / packagesDescriptor / > > errorDescriptor / auditItem) > > > > and restore this to v1. > > > Delete auditItem from auditReturnParameter? But auditItem was part of > auditReturnParameter even in v1. [CHG] Yes, must have been looking at an old version of v1. > > > > The individual auditing mechanism was only meant to change the request > > mechanisn not what was returned as the "usual" audit reply > > should have been enough to send the data back that you need. Does this > > solve the problem. If not, Micael as you need unambiguous syntax can you > > propose a simple ABNF fix that would solve your problem/s? > > > I really hope that I am not the only one who is writing a version 2 > parser, or else I am wasting my time (or are about to strike gold :) > > As for a solution, how about adding a token and changing the > definition of indAudterminationAudit to: > > indAudterminationAudit = IndAudTerminationAuditToken > indAudauditReturnParameter > *(COMMA indAudauditReturnParameter) > > Not pretty, but it should do the trick. I have not tested it > with real messages, but atleast my parser generator did not > complain anymore. [CHG] I think the point is that the MGC shouldn't be concerned whether the audited parameter is from a descriptor audit or an individual audit. The syntax provided for a descriptor audit is enough to return an individual audit. The problem lies that AuditItem is used both in the command request and reply ABNF. I was thinking about a token yesterday myself but when I had a look at the ASN1 and saw that it used existing AuditDescriptor reply syntax I thought we shouldn't allow using the IndAudRep. Would a rule that, ; For audit replys the indAudterminationAudit SHALL not be used. auditItem = ( MuxToken / ModemToken / MediaToken / SignalsToken / EventBufferToken / DigitMapToken / StatsToken / EventsToken / ObservedEventsToken / PackagesToken ) / indAudterminationAudit) Be a solution? Regards, Christian > > > > > > Regards, Christian > > > Regards, > /BMK > > > > > > > Micael Karlberg wrote: > > > So, now we have yet another parse conflict regarding 'EventBufferToken'? > > > > > > We have three rules: > > > > > > 1) auditItem -> 'EventBufferToken' > > > 2) eventBufferDescriptor -> 'EventBufferToken' > > > [ LBRKT eventSpec *(COMMA eventSpec) RBRKT ] > > > 3) indAudeventBufferDescriptor -> 'EventBufferToken' > > > LBRKT indAudeventSpec RBRKT > > > > > > One conflict between rule 1) and 2) and now another conflict > > > between rule 2) and 3) > > > > > > So, depending on the number of tokens after the 'EventBufferToken', we get: > > > - Zero -> auditItem > > > - One -> indAudeventBufferDescriptor > > > - Two or more -> eventBufferDescriptor > > > > > > Is this correct? > > > > > > Regards, > > > /BMK > > > > > > Anil Jangam writes: > > > > This particular question has been repeated for a number of times so far. > > > > Even I had the same doubt for which Tom has replied as follows: (Marked with > > > > ####>). > > > > I think we need to fix this now. > > > > > > > > ####> STARTS > > > > ----- Original Message ----- > > > > From: Tom-PT Taylor > > > > To: 'Anil Jangam' ; Kevin Boyle > > > > 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. > > > > ####> ENDS > > > > > > > > ----- Original Message ----- > > > > From: "Micael Karlberg" > > > > To: > > > > Sent: Thursday, July 17, 2003 3:16 PM > > > > Subject: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF > > > > > > > > > > > > > Hi, > > > > > > > > > > The 'auditReturnParameter' appears to be ambiguously defined in version 2 > > > > > of the ABNF. > > > > > > > > > > An example. If the 'auditReturnParameter' contains the following > > > > > sequence of tokens: > > > > > > > > > > "EB { hobbes }" > > > > > > > > > > i.e. > > > > > > > > > > EventBufferToken LBRKT pkgdName RBRKT > > > > > > > > > > then it may be an 'auditItem' (see 'indAudeventBufferDescriptor') or an > > > > > 'eventBufferDescriptor' > > > > > > > > > > What is the intention here? Should this sequence of tokens be > > > > > interpreted as an 'auditItem' or an 'eventBufferDescriptor? > > > > > > > > > > As a parser implementor I need a well defined, unambiguous grammar to > > > > > rely on. > > > > > > > > > > The grammar looks like this (a little bit simplified): > > > > > > > > > > auditReturnParameter = eventBufferDescriptor / auditItem > > > > > > > > > > eventBufferDescriptor = EventBufferToken > > > > > [ LBRKT eventSpec *(COMMA eventSpec) > > > > RBRKT] > > > > > > > > > > eventSpec = pkgdName > > > > > [ LBRKT eventSpecParameter > > > > > *(COMMA eventSpecParameter) RBRKT] > > > > > > > > > > auditItem = indAudterminationAudit > > > > > > > > > > indAudterminationAudit = indAudauditReturnParameter > > > > > *(COMMA insAudauditReturnParameter) > > > > > > > > > > indAudauditReturnParameter = indAudeventBufferDescriptor > > > > > > > > > > indAudeventBufferDescriptor = EventBufferToken LBRKT indAudeventSpec > > > > RBRKT > > > > > > > > > > indAudeventSpec = pkgdName > > > > > [ LBRKT indAudeventSpecParameter RBRKT ] > > > > > > > > > > > > > > > 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 Fri Aug 8 03:07:00 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 CAA29918 for ; Fri, 8 Aug 2003 02:17:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l0Yi-00014d-1Q; Fri, 08 Aug 2003 02:17:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l0Yb-00013K-Fv for megaco@optimus.ietf.org; Fri, 08 Aug 2003 02:16: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 CAA29814 for ; Fri, 8 Aug 2003 02:16:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l0YX-0005ro-00 for megaco@ietf.org; Fri, 08 Aug 2003 02:16:53 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19l0YW-0005rN-00 for megaco@ietf.org; Fri, 08 Aug 2003 02:16:52 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h786DEF23446; Fri, 8 Aug 2003 16:13:14 +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 QBTF8L49; Fri, 8 Aug 2003 16:16:29 +1000 Message-ID: <3F3325DE.3050608@ericsson.com.au> Date: Fri, 08 Aug 2003 14:23:58 +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: Troy Cauble CC: micael.karlberg@ericsson.com, Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> <3F32614D.6070505@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Troy, I don't think so. As this problem occurs when the returned properties are not empty. If I understand the problem correctly the issues is how does a decoder know that the returned audited parameters belong to a descriptor audit or to an individual audit. Regards, Christian Troy Cauble wrote: > Is there something here that isn't already handled by > 6.3 in the IG? > > http://www.itu.int/itudoc/itu-t/com16/implgd/h248s-ig.pdf > > -troy > > > > > Christian Groves wrote: > >> G'Day Micael, all, >> >> Back from holiday and I'm the guy who concocted this syntax. I >> certainly didn't mean to introduce this ambiguity into the ABNF (its >> why I dislike ABNF) but it did slip past everyone else until now. >> >> So as has been mentioned by Tom we need to fix this. So how about we >> delete audititem from? It removes the ambiguity. >> auditReturnParameter = (mediaDescriptor / modemDescriptor / >> muxDescriptor / eventsDescriptor / >> signalsDescriptor / digitMapDescriptor / >> observedEventsDescriptor / eventBufferDescriptor / >> statisticsDescriptor / packagesDescriptor / >> errorDescriptor / auditItem) >> >> and restore this to v1. The individual auditing mechanism was only >> meant to change the request mechanisn not what was returned as the >> "usual" audit reply should have been enough to send the data back that >> you need. Does this solve the problem. If not, Micael as you need >> unambiguous syntax can you propose a simple ABNF fix that would solve >> your problem/s? >> >> Regards, Christian >> >> >> Micael Karlberg wrote: >> >>> So, now we have yet another parse conflict regarding 'EventBufferToken'? >>> >>> We three rules: >>> >>> 1) auditItem -> 'EventBufferToken' >>> 2) eventBufferDescriptor -> 'EventBufferToken' >>> [ LBRKT eventSpec *(COMMA >>> eventSpec) RBRKT ] >>> 3) indAudeventBufferDescriptor -> 'EventBufferToken' >>> LBRKT indAudeventSpec RBRKT >>> >>> One conflict between rule 1) and 2) and now another conflict >>> between rule 2) and 3) >>> >>> So, depending on the number of tokens after the 'EventBufferToken', >>> we get: >>> - Zero -> auditItem >>> - One -> indAudeventBufferDescriptor >>> - Two or more -> eventBufferDescriptor >>> >>> Is this correct? >>> >>> Regards, >>> /BMK >>> >>> Anil Jangam writes: >>> > This particular question has been repeated for a number of times >>> so far. >>> > Even I had the same doubt for which Tom has replied as follows: >>> (Marked with >>> > ####>). >>> > I think we need to fix this now. >>> > > ####> STARTS >>> > ----- Original Message ----- >>> > From: Tom-PT Taylor >>> > To: 'Anil Jangam' ; Kevin Boyle >>> > 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. >>> > ####> ENDS >>> > > ----- Original Message ----- >>> > From: "Micael Karlberg" >>> > To: >>> > Sent: Thursday, July 17, 2003 3:16 PM >>> > Subject: [Megaco] Ambiguous definition of auditReturnParameter in >>> v2 ABNF >>> > > > > Hi, >>> > > >>> > > The 'auditReturnParameter' appears to be ambiguously defined in >>> version 2 >>> > > of the ABNF. >>> > > >>> > > An example. If the 'auditReturnParameter' contains the following >>> > > sequence of tokens: >>> > > >>> > > "EB { hobbes }" >>> > > >>> > > i.e. >>> > > >>> > > EventBufferToken LBRKT pkgdName RBRKT >>> > > >>> > > then it may be an 'auditItem' (see >>> 'indAudeventBufferDescriptor') or an >>> > > 'eventBufferDescriptor' >>> > > >>> > > What is the intention here? Should this sequence of tokens be >>> > > interpreted as an 'auditItem' or an 'eventBufferDescriptor? >>> > > >>> > > As a parser implementor I need a well defined, unambiguous >>> grammar to >>> > > rely on. >>> > > >>> > > The grammar looks like this (a little bit simplified): >>> > > >>> > > auditReturnParameter = eventBufferDescriptor / auditItem >>> > > >>> > > eventBufferDescriptor = EventBufferToken >>> > > [ LBRKT eventSpec *(COMMA >>> eventSpec) >>> > RBRKT] >>> > > >>> > > eventSpec = pkgdName >>> > > [ LBRKT eventSpecParameter >>> > > *(COMMA >>> eventSpecParameter) RBRKT] >>> > > >>> > > auditItem = indAudterminationAudit >>> > > >>> > > indAudterminationAudit = indAudauditReturnParameter >>> > > *(COMMA insAudauditReturnParameter) >>> > > >>> > > indAudauditReturnParameter = indAudeventBufferDescriptor >>> > > >>> > > indAudeventBufferDescriptor = EventBufferToken LBRKT >>> indAudeventSpec >>> > RBRKT >>> > > >>> > > indAudeventSpec = pkgdName >>> > > [ LBRKT indAudeventSpecParameter >>> RBRKT ] >>> > > >>> > > >>> > > Regards, >>> > > /BMK >> > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Aug 8 03:07:01 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 CAA29951 for ; Fri, 8 Aug 2003 02:17:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l0Yp-00017R-SC for megaco-archive@odin.ietf.org; Fri, 08 Aug 2003 02:17:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h786HBA0004298 for megaco-archive@odin.ietf.org; Fri, 8 Aug 2003 02:17:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l0Yp-00017B-G4 for megaco-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 02: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 CAA29863 for ; Fri, 8 Aug 2003 02:17:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l0Yl-0005su-00 for megaco-web-archive@ietf.org; Fri, 08 Aug 2003 02:17:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l0Yk-0005sm-00 for megaco-web-archive@ietf.org; Fri, 08 Aug 2003 02:17:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l0Yi-00014d-1Q; Fri, 08 Aug 2003 02:17:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l0Yb-00013K-Fv for megaco@optimus.ietf.org; Fri, 08 Aug 2003 02:16: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 CAA29814 for ; Fri, 8 Aug 2003 02:16:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l0YX-0005ro-00 for megaco@ietf.org; Fri, 08 Aug 2003 02:16:53 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19l0YW-0005rN-00 for megaco@ietf.org; Fri, 08 Aug 2003 02:16:52 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h786DEF23446; Fri, 8 Aug 2003 16:13:14 +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 QBTF8L49; Fri, 8 Aug 2003 16:16:29 +1000 Message-ID: <3F3325DE.3050608@ericsson.com.au> Date: Fri, 08 Aug 2003 14:23:58 +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: Troy Cauble CC: micael.karlberg@ericsson.com, Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> <3F32614D.6070505@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Troy, I don't think so. As this problem occurs when the returned properties are not empty. If I understand the problem correctly the issues is how does a decoder know that the returned audited parameters belong to a descriptor audit or to an individual audit. Regards, Christian Troy Cauble wrote: > Is there something here that isn't already handled by > 6.3 in the IG? > > http://www.itu.int/itudoc/itu-t/com16/implgd/h248s-ig.pdf > > -troy > > > > > Christian Groves wrote: > >> G'Day Micael, all, >> >> Back from holiday and I'm the guy who concocted this syntax. I >> certainly didn't mean to introduce this ambiguity into the ABNF (its >> why I dislike ABNF) but it did slip past everyone else until now. >> >> So as has been mentioned by Tom we need to fix this. So how about we >> delete audititem from? It removes the ambiguity. >> auditReturnParameter = (mediaDescriptor / modemDescriptor / >> muxDescriptor / eventsDescriptor / >> signalsDescriptor / digitMapDescriptor / >> observedEventsDescriptor / eventBufferDescriptor / >> statisticsDescriptor / packagesDescriptor / >> errorDescriptor / auditItem) >> >> and restore this to v1. The individual auditing mechanism was only >> meant to change the request mechanisn not what was returned as the >> "usual" audit reply should have been enough to send the data back that >> you need. Does this solve the problem. If not, Micael as you need >> unambiguous syntax can you propose a simple ABNF fix that would solve >> your problem/s? >> >> Regards, Christian >> >> >> Micael Karlberg wrote: >> >>> So, now we have yet another parse conflict regarding 'EventBufferToken'? >>> >>> We three rules: >>> >>> 1) auditItem -> 'EventBufferToken' >>> 2) eventBufferDescriptor -> 'EventBufferToken' >>> [ LBRKT eventSpec *(COMMA >>> eventSpec) RBRKT ] >>> 3) indAudeventBufferDescriptor -> 'EventBufferToken' >>> LBRKT indAudeventSpec RBRKT >>> >>> One conflict between rule 1) and 2) and now another conflict >>> between rule 2) and 3) >>> >>> So, depending on the number of tokens after the 'EventBufferToken', >>> we get: >>> - Zero -> auditItem >>> - One -> indAudeventBufferDescriptor >>> - Two or more -> eventBufferDescriptor >>> >>> Is this correct? >>> >>> Regards, >>> /BMK >>> >>> Anil Jangam writes: >>> > This particular question has been repeated for a number of times >>> so far. >>> > Even I had the same doubt for which Tom has replied as follows: >>> (Marked with >>> > ####>). >>> > I think we need to fix this now. >>> > > ####> STARTS >>> > ----- Original Message ----- >>> > From: Tom-PT Taylor >>> > To: 'Anil Jangam' ; Kevin Boyle >>> > 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. >>> > ####> ENDS >>> > > ----- Original Message ----- >>> > From: "Micael Karlberg" >>> > To: >>> > Sent: Thursday, July 17, 2003 3:16 PM >>> > Subject: [Megaco] Ambiguous definition of auditReturnParameter in >>> v2 ABNF >>> > > > > Hi, >>> > > >>> > > The 'auditReturnParameter' appears to be ambiguously defined in >>> version 2 >>> > > of the ABNF. >>> > > >>> > > An example. If the 'auditReturnParameter' contains the following >>> > > sequence of tokens: >>> > > >>> > > "EB { hobbes }" >>> > > >>> > > i.e. >>> > > >>> > > EventBufferToken LBRKT pkgdName RBRKT >>> > > >>> > > then it may be an 'auditItem' (see >>> 'indAudeventBufferDescriptor') or an >>> > > 'eventBufferDescriptor' >>> > > >>> > > What is the intention here? Should this sequence of tokens be >>> > > interpreted as an 'auditItem' or an 'eventBufferDescriptor? >>> > > >>> > > As a parser implementor I need a well defined, unambiguous >>> grammar to >>> > > rely on. >>> > > >>> > > The grammar looks like this (a little bit simplified): >>> > > >>> > > auditReturnParameter = eventBufferDescriptor / auditItem >>> > > >>> > > eventBufferDescriptor = EventBufferToken >>> > > [ LBRKT eventSpec *(COMMA >>> eventSpec) >>> > RBRKT] >>> > > >>> > > eventSpec = pkgdName >>> > > [ LBRKT eventSpecParameter >>> > > *(COMMA >>> eventSpecParameter) RBRKT] >>> > > >>> > > auditItem = indAudterminationAudit >>> > > >>> > > indAudterminationAudit = indAudauditReturnParameter >>> > > *(COMMA insAudauditReturnParameter) >>> > > >>> > > indAudauditReturnParameter = indAudeventBufferDescriptor >>> > > >>> > > indAudeventBufferDescriptor = EventBufferToken LBRKT >>> indAudeventSpec >>> > RBRKT >>> > > >>> > > indAudeventSpec = pkgdName >>> > > [ LBRKT indAudeventSpecParameter >>> RBRKT ] >>> > > >>> > > >>> > > Regards, >>> > > /BMK >> > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Aug 8 10:52:28 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 KAA14035 for ; Fri, 8 Aug 2003 10:52:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8b3-00007c-Uc; Fri, 08 Aug 2003 10:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8ay-00007I-TJ for megaco@optimus.ietf.org; Fri, 08 Aug 2003 10:51: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 KAA14015 for ; Fri, 8 Aug 2003 10:51:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l8aw-0001II-00 for megaco@ietf.org; Fri, 08 Aug 2003 10:51:54 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19l8av-0001I8-00 for megaco@ietf.org; Fri, 08 Aug 2003 10:51:53 -0400 Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h78EpJA03203 for ; Fri, 8 Aug 2003 09:51:19 -0500 (CDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA29894; Fri, 8 Aug 2003 10:51:27 -0400 (EDT) Cc: micael.karlberg@ericsson.com, Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA29875; Fri, 8 Aug 2003 10:51:26 -0400 (EDT) Message-ID: <3F33B8E3.9030409@bell-labs.com> Date: Fri, 08 Aug 2003 10:51:15 -0400 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Groves Original-CC: micael.karlberg@ericsson.com, Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> <16178.7310.437463.16305@gargle.gargle.HOWL> <3F332FD0.90309@ericsson.com.au> In-Reply-To: <3F332FD0.90309@ericsson.com.au> 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 Christian Groves wrote: >> >> > > So as has been mentioned by Tom we need to fix this. So how >> about we delete > audititem from? It removes the ambiguity. >> > auditReturnParameter = (mediaDescriptor / modemDescriptor / >> > muxDescriptor / eventsDescriptor / >> > signalsDescriptor / digitMapDescriptor / >> > observedEventsDescriptor / >> eventBufferDescriptor / >> > statisticsDescriptor / packagesDescriptor / >> > errorDescriptor / auditItem) >> > > and restore this to v1. >> >> Delete auditItem from auditReturnParameter? But auditItem was part of >> auditReturnParameter even in v1. > > > [CHG] Yes, must have been looking at an old version of v1. > >> >> >> > The individual auditing mechanism was only meant to change the >> request > mechanisn not what was returned as the "usual" audit reply >> > should have been enough to send the data back that you need. Does >> this > solve the problem. If not, Micael as you need unambiguous >> syntax can you > propose a simple ABNF fix that would solve your >> problem/s? >> >> >> I really hope that I am not the only one who is writing a version 2 >> parser, or else I am wasting my time (or are about to strike gold :) >> >> As for a solution, how about adding a token and changing the >> definition of indAudterminationAudit to: >> >> indAudterminationAudit = IndAudTerminationAuditToken >> indAudauditReturnParameter >> *(COMMA indAudauditReturnParameter) >> Not pretty, but it should do the trick. I have not tested it >> with real messages, but atleast my parser generator did not complain >> anymore. > > > [CHG] I think the point is that the MGC shouldn't be concerned whether > the audited parameter is from a descriptor audit or an individual audit. > The syntax provided for a descriptor audit is enough to return an > individual audit. The problem lies that AuditItem is used both in the > command request and reply ABNF. I was thinking about a token yesterday > myself but when I had a look at the ASN1 and saw that it used existing > AuditDescriptor reply syntax I thought we shouldn't allow using the > IndAudRep. > Would a rule that, > > ; For audit replys the indAudterminationAudit SHALL not be used. > auditItem = ( MuxToken / ModemToken / MediaToken / > SignalsToken / EventBufferToken / > DigitMapToken / StatsToken / EventsToken / > ObservedEventsToken / PackagesToken ) / > indAudterminationAudit) > > Be a solution? > > Regards, Christian IG item 6.3 fixed the related conflicts for V1. It's not clear if being in the IG means it applies to V2 as well. I think 6.3 should be explicitly applied to V2 because 1) it makes the two versions more alike, and 2) it fixes the conflicts. IG item #6.3 (http://www.itu.int/itudoc/itu-t/com16/implgd/h248s-ig.pdf) auditReturnParameter = (mediaDescriptor / modemDescriptor / muxDescriptor / eventsDescriptor / signalsDescriptor / digitMapDescriptor / observedEventsDescriptor / eventBufferDescriptor / statisticsDescriptor / packagesDescriptor / errorDescriptor / auditReturnItem) auditReturnItem = (MuxToken / ModemToken / MediaToken / DigitMapToken / StatsToken / ObservedEventsToken / PackagesToken ) ;at-most-once, and DigitMapToken and PackagesToken are not allowed ;in AuditCapabilities command auditItem = ( auditReturnItem / SignalsToken / EventBufferToken / EventsToken ) Note that indAudterminationAudit was not in V1. It must be added to auditItem. I think Christian is arguing that those resulting token conflicts are not critical, because the indAud variations are always followed by "{" or "=", which can distinguish them from the individual tokens of an auditItem. So no other changes are necessary. -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Aug 8 10:52: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 KAA14050 for ; Fri, 8 Aug 2003 10:52: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 19l8b7-00008P-Ne for megaco-archive@odin.ietf.org; Fri, 08 Aug 2003 10:52:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78Eq5Le000513 for megaco-archive@odin.ietf.org; Fri, 8 Aug 2003 10:52:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8b7-00008C-KS for megaco-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 10:52: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 KAA14029 for ; Fri, 8 Aug 2003 10:51:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l8b5-0001IU-00 for megaco-web-archive@ietf.org; Fri, 08 Aug 2003 10:52:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l8b4-0001IQ-00 for megaco-web-archive@ietf.org; Fri, 08 Aug 2003 10:52:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8b3-00007c-Uc; Fri, 08 Aug 2003 10:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8ay-00007I-TJ for megaco@optimus.ietf.org; Fri, 08 Aug 2003 10:51: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 KAA14015 for ; Fri, 8 Aug 2003 10:51:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l8aw-0001II-00 for megaco@ietf.org; Fri, 08 Aug 2003 10:51:54 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19l8av-0001I8-00 for megaco@ietf.org; Fri, 08 Aug 2003 10:51:53 -0400 Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h78EpJA03203 for ; Fri, 8 Aug 2003 09:51:19 -0500 (CDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA29894; Fri, 8 Aug 2003 10:51:27 -0400 (EDT) Cc: micael.karlberg@ericsson.com, Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA29875; Fri, 8 Aug 2003 10:51:26 -0400 (EDT) Message-ID: <3F33B8E3.9030409@bell-labs.com> Date: Fri, 08 Aug 2003 10:51:15 -0400 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Groves Original-CC: micael.karlberg@ericsson.com, Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> <16178.7310.437463.16305@gargle.gargle.HOWL> <3F332FD0.90309@ericsson.com.au> In-Reply-To: <3F332FD0.90309@ericsson.com.au> 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 Christian Groves wrote: >> >> > > So as has been mentioned by Tom we need to fix this. So how >> about we delete > audititem from? It removes the ambiguity. >> > auditReturnParameter = (mediaDescriptor / modemDescriptor / >> > muxDescriptor / eventsDescriptor / >> > signalsDescriptor / digitMapDescriptor / >> > observedEventsDescriptor / >> eventBufferDescriptor / >> > statisticsDescriptor / packagesDescriptor / >> > errorDescriptor / auditItem) >> > > and restore this to v1. >> >> Delete auditItem from auditReturnParameter? But auditItem was part of >> auditReturnParameter even in v1. > > > [CHG] Yes, must have been looking at an old version of v1. > >> >> >> > The individual auditing mechanism was only meant to change the >> request > mechanisn not what was returned as the "usual" audit reply >> > should have been enough to send the data back that you need. Does >> this > solve the problem. If not, Micael as you need unambiguous >> syntax can you > propose a simple ABNF fix that would solve your >> problem/s? >> >> >> I really hope that I am not the only one who is writing a version 2 >> parser, or else I am wasting my time (or are about to strike gold :) >> >> As for a solution, how about adding a token and changing the >> definition of indAudterminationAudit to: >> >> indAudterminationAudit = IndAudTerminationAuditToken >> indAudauditReturnParameter >> *(COMMA indAudauditReturnParameter) >> Not pretty, but it should do the trick. I have not tested it >> with real messages, but atleast my parser generator did not complain >> anymore. > > > [CHG] I think the point is that the MGC shouldn't be concerned whether > the audited parameter is from a descriptor audit or an individual audit. > The syntax provided for a descriptor audit is enough to return an > individual audit. The problem lies that AuditItem is used both in the > command request and reply ABNF. I was thinking about a token yesterday > myself but when I had a look at the ASN1 and saw that it used existing > AuditDescriptor reply syntax I thought we shouldn't allow using the > IndAudRep. > Would a rule that, > > ; For audit replys the indAudterminationAudit SHALL not be used. > auditItem = ( MuxToken / ModemToken / MediaToken / > SignalsToken / EventBufferToken / > DigitMapToken / StatsToken / EventsToken / > ObservedEventsToken / PackagesToken ) / > indAudterminationAudit) > > Be a solution? > > Regards, Christian IG item 6.3 fixed the related conflicts for V1. It's not clear if being in the IG means it applies to V2 as well. I think 6.3 should be explicitly applied to V2 because 1) it makes the two versions more alike, and 2) it fixes the conflicts. IG item #6.3 (http://www.itu.int/itudoc/itu-t/com16/implgd/h248s-ig.pdf) auditReturnParameter = (mediaDescriptor / modemDescriptor / muxDescriptor / eventsDescriptor / signalsDescriptor / digitMapDescriptor / observedEventsDescriptor / eventBufferDescriptor / statisticsDescriptor / packagesDescriptor / errorDescriptor / auditReturnItem) auditReturnItem = (MuxToken / ModemToken / MediaToken / DigitMapToken / StatsToken / ObservedEventsToken / PackagesToken ) ;at-most-once, and DigitMapToken and PackagesToken are not allowed ;in AuditCapabilities command auditItem = ( auditReturnItem / SignalsToken / EventBufferToken / EventsToken ) Note that indAudterminationAudit was not in V1. It must be added to auditItem. I think Christian is arguing that those resulting token conflicts are not critical, because the indAud variations are always followed by "{" or "=", which can distinguish them from the individual tokens of an auditItem. So no other changes are necessary. -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Aug 8 11:43:27 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 LAA15521 for ; Fri, 8 Aug 2003 11:43:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l9OP-0002cm-Om; Fri, 08 Aug 2003 11: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 19l9O3-0002cF-Sb for megaco@optimus.ietf.org; Fri, 08 Aug 2003 11:42: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 LAA15472 for ; Fri, 8 Aug 2003 11:42:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l9O2-0001aW-00 for megaco@ietf.org; Fri, 08 Aug 2003 11:42:38 -0400 Received: from apate.telenet-ops.be ([195.130.132.57]) by ietf-mx with esmtp (Exim 4.12) id 19l9O1-0001aT-00 for megaco@ietf.org; Fri, 08 Aug 2003 11:42:37 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by apate.telenet-ops.be (Postfix) with SMTP id 12C7A37F60 for ; Fri, 8 Aug 2003 17:42:37 +0200 (MEST) Received: from pas (D5778A6D.kabel.telenet.be [213.119.138.109]) by apate.telenet-ops.be (Postfix) with SMTP id D478437F4B for ; Fri, 8 Aug 2003 17:42:36 +0200 (MEST) Message-ID: <003201c35dc3$c9bb3140$6d8a77d5@pandora.be> Reply-To: "Pascal Lambers" From: "Pascal Lambers" To: Date: Fri, 8 Aug 2003 17:43:17 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01C35DD4.8D226F80" 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] Questing regarding digit notification... Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_002F_01C35DD4.8D226F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, May I present you the following question... Suppose that digitmap "[0-9]. " is implemented on an Media Gateway's ROOT and the subscriber dials "1234" (case 1) or "1234#" (case 2). Consequently, the Media Gateway's controller which receives the Notify containing the dialled digits and the Termination Method, is unable to determine whether case 1 or case 2 was dialled. Because in both cases, applying RFC 3015, the notify will carry ds=3D"1234" and the Termination Method will be "FM": Case 1 =3D=3D=3D=3D=3D The user dials 1234. A timeout occurs. As 1234 matches with "[0-9]. ", the digits 1234 are notified and the Termination Method will be "FM" as the condition "Full match, completion by timer expiry" is fulfilled. Case 2 =3D=3D=3D=3D The user dials 1234#. The "#" is an unmatched event, the digits 1234 are notified and the Termination Method will be "FM" as the condition "Full match, completion by unmatched event" is fulfilled. So how does the controller know whether the digits were correct if the gwy does not tell it that a timer expired? Kind regards, Pascal ------=_NextPart_000_002F_01C35DD4.8D226F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
May I present you the following=20 question...

Suppose that digitmap "[0-9]. " is = implemented on=20 an Media Gateway's
ROOT and the subscriber dials "1234" (case 1) or = "1234#"=20 (case 2).

Consequently, the Media Gateway's controller which = receives the=20 Notify
containing the dialled digits and the Termination Method, is = unable=20 to
determine whether case 1 or case 2 was dialled. Because in both=20 cases,
applying RFC 3015, the notify will carry ds=3D"1234" and the=20 Termination
Method will be "FM":

Case = 1
=3D=3D=3D=3D=3D
The user dials=20 1234. A timeout occurs. As 1234 matches with "[0-9]. ",
the digits = 1234 are=20 notified and the Termination Method will be "FM" as
the condition = "Full=20 match, completion by timer expiry" is fulfilled.

Case = 2
=3D=3D=3D=3D
The=20 user dials 1234#. The "#" is an unmatched event, the digits 1234 = are
notified=20 and the Termination Method will be "FM" as the condition "Full
match, = completion by unmatched event" is fulfilled.

So how does the = controller=20 know whether the digits were correct if the
gwy does not tell it that = a timer=20 expired?

Kind = regards,
Pascal
------=_NextPart_000_002F_01C35DD4.8D226F80-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Aug 8 11:43:28 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 LAA15536 for ; Fri, 8 Aug 2003 11:43:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l9OR-0002de-IK for megaco-archive@odin.ietf.org; Fri, 08 Aug 2003 11:43:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78Fh35h010141 for megaco-archive@odin.ietf.org; Fri, 8 Aug 2003 11:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l9OR-0002dU-Ep for megaco-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 11:43: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 LAA15481 for ; Fri, 8 Aug 2003 11:42:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l9OQ-0001ai-00 for megaco-web-archive@ietf.org; Fri, 08 Aug 2003 11:43:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l9OP-0001af-00 for megaco-web-archive@ietf.org; Fri, 08 Aug 2003 11:43:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l9OP-0002cm-Om; Fri, 08 Aug 2003 11: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 19l9O3-0002cF-Sb for megaco@optimus.ietf.org; Fri, 08 Aug 2003 11:42: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 LAA15472 for ; Fri, 8 Aug 2003 11:42:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l9O2-0001aW-00 for megaco@ietf.org; Fri, 08 Aug 2003 11:42:38 -0400 Received: from apate.telenet-ops.be ([195.130.132.57]) by ietf-mx with esmtp (Exim 4.12) id 19l9O1-0001aT-00 for megaco@ietf.org; Fri, 08 Aug 2003 11:42:37 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by apate.telenet-ops.be (Postfix) with SMTP id 12C7A37F60 for ; Fri, 8 Aug 2003 17:42:37 +0200 (MEST) Received: from pas (D5778A6D.kabel.telenet.be [213.119.138.109]) by apate.telenet-ops.be (Postfix) with SMTP id D478437F4B for ; Fri, 8 Aug 2003 17:42:36 +0200 (MEST) Message-ID: <003201c35dc3$c9bb3140$6d8a77d5@pandora.be> Reply-To: "Pascal Lambers" From: "Pascal Lambers" To: Date: Fri, 8 Aug 2003 17:43:17 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01C35DD4.8D226F80" 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] Questing regarding digit notification... Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_002F_01C35DD4.8D226F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, May I present you the following question... Suppose that digitmap "[0-9]. " is implemented on an Media Gateway's ROOT and the subscriber dials "1234" (case 1) or "1234#" (case 2). Consequently, the Media Gateway's controller which receives the Notify containing the dialled digits and the Termination Method, is unable to determine whether case 1 or case 2 was dialled. Because in both cases, applying RFC 3015, the notify will carry ds=3D"1234" and the Termination Method will be "FM": Case 1 =3D=3D=3D=3D=3D The user dials 1234. A timeout occurs. As 1234 matches with "[0-9]. ", the digits 1234 are notified and the Termination Method will be "FM" as the condition "Full match, completion by timer expiry" is fulfilled. Case 2 =3D=3D=3D=3D The user dials 1234#. The "#" is an unmatched event, the digits 1234 are notified and the Termination Method will be "FM" as the condition "Full match, completion by unmatched event" is fulfilled. So how does the controller know whether the digits were correct if the gwy does not tell it that a timer expired? Kind regards, Pascal ------=_NextPart_000_002F_01C35DD4.8D226F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
May I present you the following=20 question...

Suppose that digitmap "[0-9]. " is = implemented on=20 an Media Gateway's
ROOT and the subscriber dials "1234" (case 1) or = "1234#"=20 (case 2).

Consequently, the Media Gateway's controller which = receives the=20 Notify
containing the dialled digits and the Termination Method, is = unable=20 to
determine whether case 1 or case 2 was dialled. Because in both=20 cases,
applying RFC 3015, the notify will carry ds=3D"1234" and the=20 Termination
Method will be "FM":

Case = 1
=3D=3D=3D=3D=3D
The user dials=20 1234. A timeout occurs. As 1234 matches with "[0-9]. ",
the digits = 1234 are=20 notified and the Termination Method will be "FM" as
the condition = "Full=20 match, completion by timer expiry" is fulfilled.

Case = 2
=3D=3D=3D=3D
The=20 user dials 1234#. The "#" is an unmatched event, the digits 1234 = are
notified=20 and the Termination Method will be "FM" as the condition "Full
match, = completion by unmatched event" is fulfilled.

So how does the = controller=20 know whether the digits were correct if the
gwy does not tell it that = a timer=20 expired?

Kind = regards,
Pascal
------=_NextPart_000_002F_01C35DD4.8D226F80-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Aug 8 12:56: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 MAA17404 for ; Fri, 8 Aug 2003 12:56: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 19lAX3-0005UE-S9; Fri, 08 Aug 2003 12:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lAWD-0005Ss-L7 for megaco@optimus.ietf.org; Fri, 08 Aug 2003 12:55: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 MAA17392 for ; Fri, 8 Aug 2003 12:55:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lAWB-00023h-00 for megaco@ietf.org; Fri, 08 Aug 2003 12:55:07 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19lAWB-00023d-00 for megaco@ietf.org; Fri, 08 Aug 2003 12:55:07 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h78Gt1gM023044; Fri, 8 Aug 2003 18:55:01 +0200 (MEST) Received: from super.du.uab.ericsson.se ([134.138.176.16]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id QL803RFB; Fri, 8 Aug 2003 18:55:01 +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 h78Gsxj00727; Fri, 8 Aug 2003 18:54:59 +0200 (MET DST) Received: (from bmk@localhost) by bifur.du.uab.ericsson.se (8.11.6+Sun/8.9.1/client-1.0) id h78GswI20715; Fri, 8 Aug 2003 18:54:58 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16179.54743.520996.419483@gargle.gargle.HOWL> Date: Fri, 8 Aug 2003 18:54:47 +0200 From: Micael Karlberg Reply-To: micael.karlberg@ericsson.com Organization: Ericsson AB (EAB/UKH/KD) To: Christian Groves Cc: micael.karlberg@ericsson.com, Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF In-Reply-To: <3F332FD0.90309@ericsson.com.au> References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> <16178.7310.437463.16305@gargle.gargle.HOWL> <3F332FD0.90309@ericsson.com.au> X-Mailer: VM 7.07 under Emacs 21.1.1 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, Please see comments below. Regards, =09/BMK Christian Groves writes: > G'Day Micael, >=20 > Please see comments below. >=20 > Regards, Christian >=20 <--- snip ---> > > As for a solution, how about adding a token and changing the=20 > > definition of indAudterminationAudit to: > >=20 > > indAudterminationAudit =3D IndAudTerminationAuditToken=20 > > indAudauditReturnParameter =20 > > *(COMMA indAudauditReturnParameter) =20 > > =20 > > Not pretty, but it should do the trick. I have not tested it > > with real messages, but atleast my parser generator did not=20 > > complain anymore. >=20 > [CHG] I think the point is that the MGC shouldn't be concerned wheth= er the=20 > audited parameter is from a descriptor audit or an individual audit.= =20 > The syntax provided for a descriptor audit is enough to return an in= dividual > audit. The problem lies that AuditItem is used both in the command r= equest=20 > and reply ABNF.=20 > I was thinking about a token yesterday myself but when I had a look = at the=20 > ASN1 and saw that it used existing AuditDescriptor reply syntax I th= ought=20 > we shouldn't allow using the IndAudRep. > Would a rule that, >=20 > ; For audit replys the indAudterminationAudit SHALL not be used. > auditItem =3D ( MuxToken / ModemToken / MediaToken / > SignalsToken / EventBufferToken / > DigitMapToken / StatsToken / EventsToken / > ObservedEventsToken / PackagesToken ) / > indAudterminationAudit) >=20 > Be a solution? [BMK] That clears up the intention but I don't think it will make the ABNF less ambiguous for a parser generator (e.g. bison).=20 >=20 > Regards, Christian Regards, =09/BMK >=20 > >=20 > >=20 > > >=20 > > > Regards, Christian > >=20 > >=20 > > Regards, > > =09/BMK > >=20 > > >=20 > > >=20 > > > Micael Karlberg wrote: > > > > So, now we have yet another parse conflict regarding 'EventBu= fferToken'? > > > >=20 > > > > We have three rules: > > > >=20 > > > > 1) auditItem -> 'EventBufferToken' > > > > 2) eventBufferDescriptor -> 'EventBufferToken'=20 > > > > [ LBRKT eventSpec *(COMMA e= ventSpec) RBRKT ] > > > > 3) indAudeventBufferDescriptor -> 'EventBufferToken'=20 > > > > LBRKT indAudeventSpec RBRKT= > > > >=20 > > > > One conflict between rule 1) and 2) and now another conflict > > > > between rule 2) and 3) > > > >=20 > > > > So, depending on the number of tokens after the 'EventBufferT= oken', we get: > > > > - Zero -> auditItem > > > > - One -> indAudeventBufferDescriptor > > > > - Two or more -> eventBufferDescriptor > > > >=20 > > > > Is this correct? > > > >=20 > > > > Regards, > > > > =09/BMK > > > >=20 > > > > Anil Jangam writes: > > > > > This particular question has been repeated for a number of= times so far. > > > > > Even I had the same doubt for which Tom has replied as fol= lows: (Marked with > > > > > ####>). > > > > > I think we need to fix this now. > > > > >=20 > > > > > ####> STARTS > > > > > ----- Original Message ----- > > > > > From: Tom-PT Taylor > > > > > To: 'Anil Jangam' ; Kevin Boyle > > > > > Sent: Wednesday, January 22, 2003 10:40 PM > > > > > Subject: RE: [Megaco] auditReturnParameter in AmmsReply > > > > >=20 > > > > >=20 > > > > > I suppose as the guy who concocted this syntax I should an= swer the question. > > > > > You return the auditItem. That was my shortcut for return= ing descriptor > > > > > name only. > > > > >=20 > > > > > Apparently there is a parsing problem with this syntax, bu= t we never seem to > > > > > have taken the step of resolving it. > > > > > ####> ENDS > > > > >=20 > > > > > ----- Original Message ----- > > > > > From: "Micael Karlberg" > > > > > To: > > > > > Sent: Thursday, July 17, 2003 3:16 PM > > > > > Subject: [Megaco] Ambiguous definition of auditReturnParam= eter in v2 ABNF > > > > >=20 > > > > >=20 > > > > > > Hi, > > > > > > > > > > > > The 'auditReturnParameter' appears to be ambiguously def= ined in version 2 > > > > > > of the ABNF. > > > > > > > > > > > > An example. If the 'auditReturnParameter' contains the f= ollowing > > > > > > sequence of tokens: > > > > > > > > > > > > "EB { hobbes }" > > > > > > > > > > > > i.e. > > > > > > > > > > > > EventBufferToken LBRKT pkgdName RBRKT > > > > > > > > > > > > then it may be an 'auditItem' (see 'indAudeventBufferDes= criptor') or an > > > > > > 'eventBufferDescriptor' > > > > > > > > > > > > What is the intention here? Should this sequence of toke= ns be > > > > > > interpreted as an 'auditItem' or an 'eventBufferDescript= or? > > > > > > > > > > > > As a parser implementor I need a well defined, unambiguo= us grammar to > > > > > > rely on. > > > > > > > > > > > > The grammar looks like this (a little bit simplified): > > > > > > > > > > > > auditReturnParameter =3D eventBufferDescriptor = / auditItem > > > > > > > > > > > > eventBufferDescriptor =3D EventBufferToken > > > > > > [ LBRKT eventSpec *(COMM= A eventSpec) > > > > > RBRKT] > > > > > > > > > > > > eventSpec =3D pkgdName > > > > > > [ LBRKT eventSpecParamet= er > > > > > > *(COMMA eventSpe= cParameter) RBRKT] > > > > > > > > > > > > auditItem =3D indAudterminationAudit= > > > > > > > > > > > > indAudterminationAudit =3D indAudauditReturnParam= eter > > > > > > *(COMMA insAudauditRetur= nParameter) > > > > > > > > > > > > indAudauditReturnParameter =3D indAudeventBufferDescr= iptor > > > > > > > > > > > > indAudeventBufferDescriptor =3D EventBufferToken LBRKT= indAudeventSpec > > > > > RBRKT > > > > > > > > > > > > indAudeventSpec =3D pkgdName > > > > > > [ LBRKT indAudeventSpecP= arameter RBRKT ] > > > > > > > > > > > > > > > > > > Regards, > > > > > > /BMK > > > > > > > > > > > > _______________________________________________ > > > > > > Megaco mailing list > > > > > > Megaco@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > > > > > >=20 > >=20 >=20 --=20 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 =20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Aug 8 12:56: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 MAA17419 for ; Fri, 8 Aug 2003 12:56: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 19lAX8-0005V2-Mt for megaco-archive@odin.ietf.org; Fri, 08 Aug 2003 12:56:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78Gu6A1021135 for megaco-archive@odin.ietf.org; Fri, 8 Aug 2003 12:56:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lAX8-0005Uo-IF for megaco-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 12:56: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 MAA17397 for ; Fri, 8 Aug 2003 12:56:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lAX6-00023n-00 for megaco-web-archive@ietf.org; Fri, 08 Aug 2003 12:56:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lAX6-00023k-00 for megaco-web-archive@ietf.org; Fri, 08 Aug 2003 12:56:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lAX3-0005UE-S9; Fri, 08 Aug 2003 12:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lAWD-0005Ss-L7 for megaco@optimus.ietf.org; Fri, 08 Aug 2003 12:55: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 MAA17392 for ; Fri, 8 Aug 2003 12:55:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lAWB-00023h-00 for megaco@ietf.org; Fri, 08 Aug 2003 12:55:07 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19lAWB-00023d-00 for megaco@ietf.org; Fri, 08 Aug 2003 12:55:07 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h78Gt1gM023044; Fri, 8 Aug 2003 18:55:01 +0200 (MEST) Received: from super.du.uab.ericsson.se ([134.138.176.16]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id QL803RFB; Fri, 8 Aug 2003 18:55:01 +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 h78Gsxj00727; Fri, 8 Aug 2003 18:54:59 +0200 (MET DST) Received: (from bmk@localhost) by bifur.du.uab.ericsson.se (8.11.6+Sun/8.9.1/client-1.0) id h78GswI20715; Fri, 8 Aug 2003 18:54:58 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16179.54743.520996.419483@gargle.gargle.HOWL> Date: Fri, 8 Aug 2003 18:54:47 +0200 From: Micael Karlberg Reply-To: micael.karlberg@ericsson.com Organization: Ericsson AB (EAB/UKH/KD) To: Christian Groves Cc: micael.karlberg@ericsson.com, Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF In-Reply-To: <3F332FD0.90309@ericsson.com.au> References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> <16178.7310.437463.16305@gargle.gargle.HOWL> <3F332FD0.90309@ericsson.com.au> X-Mailer: VM 7.07 under Emacs 21.1.1 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, Please see comments below. Regards, =09/BMK Christian Groves writes: > G'Day Micael, >=20 > Please see comments below. >=20 > Regards, Christian >=20 <--- snip ---> > > As for a solution, how about adding a token and changing the=20 > > definition of indAudterminationAudit to: > >=20 > > indAudterminationAudit =3D IndAudTerminationAuditToken=20 > > indAudauditReturnParameter =20 > > *(COMMA indAudauditReturnParameter) =20 > > =20 > > Not pretty, but it should do the trick. I have not tested it > > with real messages, but atleast my parser generator did not=20 > > complain anymore. >=20 > [CHG] I think the point is that the MGC shouldn't be concerned wheth= er the=20 > audited parameter is from a descriptor audit or an individual audit.= =20 > The syntax provided for a descriptor audit is enough to return an in= dividual > audit. The problem lies that AuditItem is used both in the command r= equest=20 > and reply ABNF.=20 > I was thinking about a token yesterday myself but when I had a look = at the=20 > ASN1 and saw that it used existing AuditDescriptor reply syntax I th= ought=20 > we shouldn't allow using the IndAudRep. > Would a rule that, >=20 > ; For audit replys the indAudterminationAudit SHALL not be used. > auditItem =3D ( MuxToken / ModemToken / MediaToken / > SignalsToken / EventBufferToken / > DigitMapToken / StatsToken / EventsToken / > ObservedEventsToken / PackagesToken ) / > indAudterminationAudit) >=20 > Be a solution? [BMK] That clears up the intention but I don't think it will make the ABNF less ambiguous for a parser generator (e.g. bison).=20 >=20 > Regards, Christian Regards, =09/BMK >=20 > >=20 > >=20 > > >=20 > > > Regards, Christian > >=20 > >=20 > > Regards, > > =09/BMK > >=20 > > >=20 > > >=20 > > > Micael Karlberg wrote: > > > > So, now we have yet another parse conflict regarding 'EventBu= fferToken'? > > > >=20 > > > > We have three rules: > > > >=20 > > > > 1) auditItem -> 'EventBufferToken' > > > > 2) eventBufferDescriptor -> 'EventBufferToken'=20 > > > > [ LBRKT eventSpec *(COMMA e= ventSpec) RBRKT ] > > > > 3) indAudeventBufferDescriptor -> 'EventBufferToken'=20 > > > > LBRKT indAudeventSpec RBRKT= > > > >=20 > > > > One conflict between rule 1) and 2) and now another conflict > > > > between rule 2) and 3) > > > >=20 > > > > So, depending on the number of tokens after the 'EventBufferT= oken', we get: > > > > - Zero -> auditItem > > > > - One -> indAudeventBufferDescriptor > > > > - Two or more -> eventBufferDescriptor > > > >=20 > > > > Is this correct? > > > >=20 > > > > Regards, > > > > =09/BMK > > > >=20 > > > > Anil Jangam writes: > > > > > This particular question has been repeated for a number of= times so far. > > > > > Even I had the same doubt for which Tom has replied as fol= lows: (Marked with > > > > > ####>). > > > > > I think we need to fix this now. > > > > >=20 > > > > > ####> STARTS > > > > > ----- Original Message ----- > > > > > From: Tom-PT Taylor > > > > > To: 'Anil Jangam' ; Kevin Boyle > > > > > Sent: Wednesday, January 22, 2003 10:40 PM > > > > > Subject: RE: [Megaco] auditReturnParameter in AmmsReply > > > > >=20 > > > > >=20 > > > > > I suppose as the guy who concocted this syntax I should an= swer the question. > > > > > You return the auditItem. That was my shortcut for return= ing descriptor > > > > > name only. > > > > >=20 > > > > > Apparently there is a parsing problem with this syntax, bu= t we never seem to > > > > > have taken the step of resolving it. > > > > > ####> ENDS > > > > >=20 > > > > > ----- Original Message ----- > > > > > From: "Micael Karlberg" > > > > > To: > > > > > Sent: Thursday, July 17, 2003 3:16 PM > > > > > Subject: [Megaco] Ambiguous definition of auditReturnParam= eter in v2 ABNF > > > > >=20 > > > > >=20 > > > > > > Hi, > > > > > > > > > > > > The 'auditReturnParameter' appears to be ambiguously def= ined in version 2 > > > > > > of the ABNF. > > > > > > > > > > > > An example. If the 'auditReturnParameter' contains the f= ollowing > > > > > > sequence of tokens: > > > > > > > > > > > > "EB { hobbes }" > > > > > > > > > > > > i.e. > > > > > > > > > > > > EventBufferToken LBRKT pkgdName RBRKT > > > > > > > > > > > > then it may be an 'auditItem' (see 'indAudeventBufferDes= criptor') or an > > > > > > 'eventBufferDescriptor' > > > > > > > > > > > > What is the intention here? Should this sequence of toke= ns be > > > > > > interpreted as an 'auditItem' or an 'eventBufferDescript= or? > > > > > > > > > > > > As a parser implementor I need a well defined, unambiguo= us grammar to > > > > > > rely on. > > > > > > > > > > > > The grammar looks like this (a little bit simplified): > > > > > > > > > > > > auditReturnParameter =3D eventBufferDescriptor = / auditItem > > > > > > > > > > > > eventBufferDescriptor =3D EventBufferToken > > > > > > [ LBRKT eventSpec *(COMM= A eventSpec) > > > > > RBRKT] > > > > > > > > > > > > eventSpec =3D pkgdName > > > > > > [ LBRKT eventSpecParamet= er > > > > > > *(COMMA eventSpe= cParameter) RBRKT] > > > > > > > > > > > > auditItem =3D indAudterminationAudit= > > > > > > > > > > > > indAudterminationAudit =3D indAudauditReturnParam= eter > > > > > > *(COMMA insAudauditRetur= nParameter) > > > > > > > > > > > > indAudauditReturnParameter =3D indAudeventBufferDescr= iptor > > > > > > > > > > > > indAudeventBufferDescriptor =3D EventBufferToken LBRKT= indAudeventSpec > > > > > RBRKT > > > > > > > > > > > > indAudeventSpec =3D pkgdName > > > > > > [ LBRKT indAudeventSpecP= arameter RBRKT ] > > > > > > > > > > > > > > > > > > Regards, > > > > > > /BMK > > > > > > > > > > > > _______________________________________________ > > > > > > Megaco mailing list > > > > > > Megaco@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > > > > > >=20 > >=20 >=20 --=20 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 =20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Aug 8 16:24:34 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 QAA24497 for ; Fri, 8 Aug 2003 16: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 19lDmM-0005UE-Mf; Fri, 08 Aug 2003 16: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 19lCjR-0003Nd-8y for megaco@optimus.ietf.org; Fri, 08 Aug 2003 15:16: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 PAA22979 for ; Fri, 8 Aug 2003 15:16:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lCjM-0003AY-00 for megaco@ietf.org; Fri, 08 Aug 2003 15:16:52 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19lCjL-0003AV-00 for megaco@ietf.org; Fri, 08 Aug 2003 15:16:52 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h78JGg7W027367; Fri, 8 Aug 2003 21:16:42 +0200 (MEST) Received: from super.du.uab.ericsson.se ([134.138.176.16]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id QL80PGRV; Fri, 8 Aug 2003 21:16:42 +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 h78JGcj01434; Fri, 8 Aug 2003 21:16:39 +0200 (MET DST) Received: (from bmk@localhost) by bifur.du.uab.ericsson.se (8.11.6+Sun/8.9.1/client-1.0) id h78JGcR20832; Fri, 8 Aug 2003 21:16:38 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16179.63254.17278.479615@gargle.gargle.HOWL> Date: Fri, 8 Aug 2003 21:16:38 +0200 From: Micael Karlberg Reply-To: micael.karlberg@ericsson.com Organization: Ericsson AB (EAB/UKH/KD) To: Troy Cauble Cc: Christian Groves , micael.karlberg@ericsson.com, Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF In-Reply-To: <3F33B8E3.9030409@bell-labs.com> References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> <16178.7310.437463.16305@gargle.gargle.HOWL> <3F332FD0.90309@ericsson.com.au> <3F33B8E3.9030409@bell-labs.com> X-Mailer: VM 7.07 under Emacs 21.1.1 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, I made the changes described by Troy: 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 / indAudterminationAudit ) This seems to work just fine, and since it is the way it's done in the IG (h248s-ig) why not use this construction in version 2? By the way. I have been using the draft-ietf-megaco-3015corr-03.txt document assuming it to be up-to-date with the latest IG. It was only when Troy pointed out the auditReturnItem that I realized that something was not right. h248s-ig.pdf is dated 25 October 2002 and draft-ietf-megaco-3015corr-03.txt is dated December 2002 (i.e. later). Is there a later version of the draft-ietf-megaco-3015corr document or is it dead (it did expire June 2003)? Regards, /BMK Troy Cauble writes: > Christian Groves wrote: > > > >> > >> > > So as has been mentioned by Tom we need to fix this. So how > >> about we delete > audititem from? It removes the ambiguity. > >> > auditReturnParameter = (mediaDescriptor / modemDescriptor / > >> > muxDescriptor / eventsDescriptor / > >> > signalsDescriptor / digitMapDescriptor / > >> > observedEventsDescriptor / > >> eventBufferDescriptor / > >> > statisticsDescriptor / packagesDescriptor / > >> > errorDescriptor / auditItem) > >> > > and restore this to v1. > >> > >> Delete auditItem from auditReturnParameter? But auditItem was part of > >> auditReturnParameter even in v1. > > > > > > [CHG] Yes, must have been looking at an old version of v1. > > > >> > >> > >> > The individual auditing mechanism was only meant to change the > >> request > mechanisn not what was returned as the "usual" audit reply > >> > should have been enough to send the data back that you need. Does > >> this > solve the problem. If not, Micael as you need unambiguous > >> syntax can you > propose a simple ABNF fix that would solve your > >> problem/s? > >> > >> > >> I really hope that I am not the only one who is writing a version 2 > >> parser, or else I am wasting my time (or are about to strike gold :) > >> > >> As for a solution, how about adding a token and changing the > >> definition of indAudterminationAudit to: > >> > >> indAudterminationAudit = IndAudTerminationAuditToken > >> indAudauditReturnParameter > >> *(COMMA indAudauditReturnParameter) > >> Not pretty, but it should do the trick. I have not tested it > >> with real messages, but atleast my parser generator did not complain > >> anymore. > > > > > > [CHG] I think the point is that the MGC shouldn't be concerned whether > > the audited parameter is from a descriptor audit or an individual audit. > > The syntax provided for a descriptor audit is enough to return an > > individual audit. The problem lies that AuditItem is used both in the > > command request and reply ABNF. I was thinking about a token yesterday > > myself but when I had a look at the ASN1 and saw that it used existing > > AuditDescriptor reply syntax I thought we shouldn't allow using the > > IndAudRep. > > Would a rule that, > > > > ; For audit replys the indAudterminationAudit SHALL not be used. > > auditItem = ( MuxToken / ModemToken / MediaToken / > > SignalsToken / EventBufferToken / > > DigitMapToken / StatsToken / EventsToken / > > ObservedEventsToken / PackagesToken ) / > > indAudterminationAudit) > > > > Be a solution? > > > > Regards, Christian > > IG item 6.3 fixed the related conflicts for V1. It's not clear if being > in the IG means it applies to V2 as well. > > I think 6.3 should be explicitly applied to V2 because > 1) it makes the two versions more alike, and > 2) it fixes the conflicts. > > > IG item #6.3 (http://www.itu.int/itudoc/itu-t/com16/implgd/h248s-ig.pdf) > > auditReturnParameter = (mediaDescriptor / modemDescriptor / > muxDescriptor / eventsDescriptor / > signalsDescriptor / digitMapDescriptor / > observedEventsDescriptor / > eventBufferDescriptor / > statisticsDescriptor / packagesDescriptor / > errorDescriptor / auditReturnItem) > > auditReturnItem = (MuxToken / ModemToken / MediaToken / > DigitMapToken / StatsToken / > ObservedEventsToken / PackagesToken ) > > ;at-most-once, and DigitMapToken and PackagesToken are not allowed > ;in AuditCapabilities command > auditItem = ( auditReturnItem / SignalsToken / > EventBufferToken / EventsToken ) > > > Note that indAudterminationAudit was not in V1. It must be added to > auditItem. I think Christian is arguing that those resulting token > conflicts are not critical, because the indAud variations are always > followed by "{" or "=", which can distinguish them from the individual > tokens of an auditItem. So no other changes are necessary. > > -troy > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Aug 8 16: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 QAA24498 for ; Fri, 8 Aug 2003 16:24:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDmQ-0005Xq-10; Fri, 08 Aug 2003 16: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 19lD0o-0003mt-1w for megaco@optimus.ietf.org; Fri, 08 Aug 2003 15:34: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 PAA23421 for ; Fri, 8 Aug 2003 15:34:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lD0l-0003HO-00 for megaco@ietf.org; Fri, 08 Aug 2003 15:34:51 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19lD0k-0003Gz-00 for megaco@ietf.org; Fri, 08 Aug 2003 15:34:50 -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 h78JXYa23674; Fri, 8 Aug 2003 15:33:34 -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 QBRD4MAV; Fri, 8 Aug 2003 15:33:34 -0400 Received: from nortelnetworks.com (acart1fq.ca.nortel.com [47.129.129.165]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QHD6K33B; Fri, 8 Aug 2003 15:33:34 -0400 Message-ID: <3F33FB08.50903@nortelnetworks.com> Date: Fri, 08 Aug 2003 15:33:28 -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.4) Gecko/20030624 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: micael.karlberg@ericsson.com CC: Troy Cauble , Christian Groves , Anil Jangam , megaco@ietf.org, "Tom-PT Taylor" , "Kevin Boyle" Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> <16178.7310.437463.16305@gargle.gargle.HOWL> <3F332FD0.90309@ericsson.com.au> <3F33B8E3.9030409@bell-labs.com> <16179.63254.17278.479615@gargle.gargle.HOWL> In-Reply-To: <16179.63254.17278.479615@gargle.gargle.HOWL> 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 You should now be using RFC 3525 as the equivalent to H.248.1 version 1. Micael Karlberg wrote: > Hi, > > I made the changes described by Troy: > > 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 / > indAudterminationAudit ) > > This seems to work just fine, and since it is the way it's done > in the IG (h248s-ig) why not use this construction in version 2? > > By the way. I have been using the draft-ietf-megaco-3015corr-03.txt > document assuming it to be up-to-date with the latest IG. It was only > when Troy pointed out the auditReturnItem that I realized that something > was not right. h248s-ig.pdf is dated 25 October 2002 and > draft-ietf-megaco-3015corr-03.txt is dated December 2002 (i.e. later). > Is there a later version of the draft-ietf-megaco-3015corr document > or is it dead (it did expire June 2003)? > > Regards, > /BMK > > Troy Cauble writes: > > Christian Groves wrote: > > > > > > >> > > >> > > So as has been mentioned by Tom we need to fix this. So how > > >> about we delete > audititem from? It removes the ambiguity. > > >> > auditReturnParameter = (mediaDescriptor / modemDescriptor / > > >> > muxDescriptor / eventsDescriptor / > > >> > signalsDescriptor / digitMapDescriptor / > > >> > observedEventsDescriptor / > > >> eventBufferDescriptor / > > >> > statisticsDescriptor / packagesDescriptor / > > >> > errorDescriptor / auditItem) > > >> > > and restore this to v1. > > >> > > >> Delete auditItem from auditReturnParameter? But auditItem was part of > > >> auditReturnParameter even in v1. > > > > > > > > > [CHG] Yes, must have been looking at an old version of v1. > > > > > >> > > >> > > >> > The individual auditing mechanism was only meant to change the > > >> request > mechanisn not what was returned as the "usual" audit reply > > >> > should have been enough to send the data back that you need. Does > > >> this > solve the problem. If not, Micael as you need unambiguous > > >> syntax can you > propose a simple ABNF fix that would solve your > > >> problem/s? > > >> > > >> > > >> I really hope that I am not the only one who is writing a version 2 > > >> parser, or else I am wasting my time (or are about to strike gold :) > > >> > > >> As for a solution, how about adding a token and changing the > > >> definition of indAudterminationAudit to: > > >> > > >> indAudterminationAudit = IndAudTerminationAuditToken > > >> indAudauditReturnParameter > > >> *(COMMA indAudauditReturnParameter) > > >> Not pretty, but it should do the trick. I have not tested it > > >> with real messages, but atleast my parser generator did not complain > > >> anymore. > > > > > > > > > [CHG] I think the point is that the MGC shouldn't be concerned whether > > > the audited parameter is from a descriptor audit or an individual audit. > > > The syntax provided for a descriptor audit is enough to return an > > > individual audit. The problem lies that AuditItem is used both in the > > > command request and reply ABNF. I was thinking about a token yesterday > > > myself but when I had a look at the ASN1 and saw that it used existing > > > AuditDescriptor reply syntax I thought we shouldn't allow using the > > > IndAudRep. > > > Would a rule that, > > > > > > ; For audit replys the indAudterminationAudit SHALL not be used. > > > auditItem = ( MuxToken / ModemToken / MediaToken / > > > SignalsToken / EventBufferToken / > > > DigitMapToken / StatsToken / EventsToken / > > > ObservedEventsToken / PackagesToken ) / > > > indAudterminationAudit) > > > > > > Be a solution? > > > > > > Regards, Christian > > > > IG item 6.3 fixed the related conflicts for V1. It's not clear if being > > in the IG means it applies to V2 as well. > > > > I think 6.3 should be explicitly applied to V2 because > > 1) it makes the two versions more alike, and > > 2) it fixes the conflicts. > > > > > > IG item #6.3 (http://www.itu.int/itudoc/itu-t/com16/implgd/h248s-ig.pdf) > > > > auditReturnParameter = (mediaDescriptor / modemDescriptor / > > muxDescriptor / eventsDescriptor / > > signalsDescriptor / digitMapDescriptor / > > observedEventsDescriptor / > > eventBufferDescriptor / > > statisticsDescriptor / packagesDescriptor / > > errorDescriptor / auditReturnItem) > > > > auditReturnItem = (MuxToken / ModemToken / MediaToken / > > DigitMapToken / StatsToken / > > ObservedEventsToken / PackagesToken ) > > > > ;at-most-once, and DigitMapToken and PackagesToken are not allowed > > ;in AuditCapabilities command > > auditItem = ( auditReturnItem / SignalsToken / > > EventBufferToken / EventsToken ) > > > > > > Note that indAudterminationAudit was not in V1. It must be added to > > auditItem. I think Christian is arguing that those resulting token > > conflicts are not critical, because the indAud variations are always > > followed by "{" or "=", which can distinguish them from the individual > > tokens of an auditItem. So no other changes are necessary. > > > > -troy > > > > > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Aug 8 16:25:02 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 QAA24636 for ; Fri, 8 Aug 2003 16:25:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDmt-0005s3-O3 for megaco-archive@odin.ietf.org; Fri, 08 Aug 2003 16:24:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78KOZs7022566 for megaco-archive@odin.ietf.org; Fri, 8 Aug 2003 16:24:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDmt-0005rs-Kg for megaco-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 16:24: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 QAA24491 for ; Fri, 8 Aug 2003 16:24:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lDmr-0003lz-00 for megaco-web-archive@ietf.org; Fri, 08 Aug 2003 16:24:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lDmp-0003jG-00 for megaco-web-archive@ietf.org; Fri, 08 Aug 2003 16:24:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDmM-0005UE-Mf; Fri, 08 Aug 2003 16: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 19lCjR-0003Nd-8y for megaco@optimus.ietf.org; Fri, 08 Aug 2003 15:16: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 PAA22979 for ; Fri, 8 Aug 2003 15:16:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lCjM-0003AY-00 for megaco@ietf.org; Fri, 08 Aug 2003 15:16:52 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19lCjL-0003AV-00 for megaco@ietf.org; Fri, 08 Aug 2003 15:16:52 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h78JGg7W027367; Fri, 8 Aug 2003 21:16:42 +0200 (MEST) Received: from super.du.uab.ericsson.se ([134.138.176.16]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id QL80PGRV; Fri, 8 Aug 2003 21:16:42 +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 h78JGcj01434; Fri, 8 Aug 2003 21:16:39 +0200 (MET DST) Received: (from bmk@localhost) by bifur.du.uab.ericsson.se (8.11.6+Sun/8.9.1/client-1.0) id h78JGcR20832; Fri, 8 Aug 2003 21:16:38 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16179.63254.17278.479615@gargle.gargle.HOWL> Date: Fri, 8 Aug 2003 21:16:38 +0200 From: Micael Karlberg Reply-To: micael.karlberg@ericsson.com Organization: Ericsson AB (EAB/UKH/KD) To: Troy Cauble Cc: Christian Groves , micael.karlberg@ericsson.com, Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF In-Reply-To: <3F33B8E3.9030409@bell-labs.com> References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> <16178.7310.437463.16305@gargle.gargle.HOWL> <3F332FD0.90309@ericsson.com.au> <3F33B8E3.9030409@bell-labs.com> X-Mailer: VM 7.07 under Emacs 21.1.1 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, I made the changes described by Troy: 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 / indAudterminationAudit ) This seems to work just fine, and since it is the way it's done in the IG (h248s-ig) why not use this construction in version 2? By the way. I have been using the draft-ietf-megaco-3015corr-03.txt document assuming it to be up-to-date with the latest IG. It was only when Troy pointed out the auditReturnItem that I realized that something was not right. h248s-ig.pdf is dated 25 October 2002 and draft-ietf-megaco-3015corr-03.txt is dated December 2002 (i.e. later). Is there a later version of the draft-ietf-megaco-3015corr document or is it dead (it did expire June 2003)? Regards, /BMK Troy Cauble writes: > Christian Groves wrote: > > > >> > >> > > So as has been mentioned by Tom we need to fix this. So how > >> about we delete > audititem from? It removes the ambiguity. > >> > auditReturnParameter = (mediaDescriptor / modemDescriptor / > >> > muxDescriptor / eventsDescriptor / > >> > signalsDescriptor / digitMapDescriptor / > >> > observedEventsDescriptor / > >> eventBufferDescriptor / > >> > statisticsDescriptor / packagesDescriptor / > >> > errorDescriptor / auditItem) > >> > > and restore this to v1. > >> > >> Delete auditItem from auditReturnParameter? But auditItem was part of > >> auditReturnParameter even in v1. > > > > > > [CHG] Yes, must have been looking at an old version of v1. > > > >> > >> > >> > The individual auditing mechanism was only meant to change the > >> request > mechanisn not what was returned as the "usual" audit reply > >> > should have been enough to send the data back that you need. Does > >> this > solve the problem. If not, Micael as you need unambiguous > >> syntax can you > propose a simple ABNF fix that would solve your > >> problem/s? > >> > >> > >> I really hope that I am not the only one who is writing a version 2 > >> parser, or else I am wasting my time (or are about to strike gold :) > >> > >> As for a solution, how about adding a token and changing the > >> definition of indAudterminationAudit to: > >> > >> indAudterminationAudit = IndAudTerminationAuditToken > >> indAudauditReturnParameter > >> *(COMMA indAudauditReturnParameter) > >> Not pretty, but it should do the trick. I have not tested it > >> with real messages, but atleast my parser generator did not complain > >> anymore. > > > > > > [CHG] I think the point is that the MGC shouldn't be concerned whether > > the audited parameter is from a descriptor audit or an individual audit. > > The syntax provided for a descriptor audit is enough to return an > > individual audit. The problem lies that AuditItem is used both in the > > command request and reply ABNF. I was thinking about a token yesterday > > myself but when I had a look at the ASN1 and saw that it used existing > > AuditDescriptor reply syntax I thought we shouldn't allow using the > > IndAudRep. > > Would a rule that, > > > > ; For audit replys the indAudterminationAudit SHALL not be used. > > auditItem = ( MuxToken / ModemToken / MediaToken / > > SignalsToken / EventBufferToken / > > DigitMapToken / StatsToken / EventsToken / > > ObservedEventsToken / PackagesToken ) / > > indAudterminationAudit) > > > > Be a solution? > > > > Regards, Christian > > IG item 6.3 fixed the related conflicts for V1. It's not clear if being > in the IG means it applies to V2 as well. > > I think 6.3 should be explicitly applied to V2 because > 1) it makes the two versions more alike, and > 2) it fixes the conflicts. > > > IG item #6.3 (http://www.itu.int/itudoc/itu-t/com16/implgd/h248s-ig.pdf) > > auditReturnParameter = (mediaDescriptor / modemDescriptor / > muxDescriptor / eventsDescriptor / > signalsDescriptor / digitMapDescriptor / > observedEventsDescriptor / > eventBufferDescriptor / > statisticsDescriptor / packagesDescriptor / > errorDescriptor / auditReturnItem) > > auditReturnItem = (MuxToken / ModemToken / MediaToken / > DigitMapToken / StatsToken / > ObservedEventsToken / PackagesToken ) > > ;at-most-once, and DigitMapToken and PackagesToken are not allowed > ;in AuditCapabilities command > auditItem = ( auditReturnItem / SignalsToken / > EventBufferToken / EventsToken ) > > > Note that indAudterminationAudit was not in V1. It must be added to > auditItem. I think Christian is arguing that those resulting token > conflicts are not critical, because the indAud variations are always > followed by "{" or "=", which can distinguish them from the individual > tokens of an auditItem. So no other changes are necessary. > > -troy > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Aug 8 16:25:06 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 QAA24663 for ; Fri, 8 Aug 2003 16:25:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDmz-0005u7-Mo for megaco-archive@odin.ietf.org; Fri, 08 Aug 2003 16:24:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78KOfiR022689 for megaco-archive@odin.ietf.org; Fri, 8 Aug 2003 16:24:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDmz-0005sS-Im for megaco-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 16:24: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 QAA24485 for ; Fri, 8 Aug 2003 16:24:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lDmr-0003lx-00 for megaco-web-archive@ietf.org; Fri, 08 Aug 2003 16:24:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lDmp-0003jH-00 for megaco-web-archive@ietf.org; Fri, 08 Aug 2003 16:24:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDmQ-0005Xq-10; Fri, 08 Aug 2003 16: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 19lD0o-0003mt-1w for megaco@optimus.ietf.org; Fri, 08 Aug 2003 15:34: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 PAA23421 for ; Fri, 8 Aug 2003 15:34:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lD0l-0003HO-00 for megaco@ietf.org; Fri, 08 Aug 2003 15:34:51 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19lD0k-0003Gz-00 for megaco@ietf.org; Fri, 08 Aug 2003 15:34:50 -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 h78JXYa23674; Fri, 8 Aug 2003 15:33:34 -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 QBRD4MAV; Fri, 8 Aug 2003 15:33:34 -0400 Received: from nortelnetworks.com (acart1fq.ca.nortel.com [47.129.129.165]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QHD6K33B; Fri, 8 Aug 2003 15:33:34 -0400 Message-ID: <3F33FB08.50903@nortelnetworks.com> Date: Fri, 08 Aug 2003 15:33:28 -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.4) Gecko/20030624 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: micael.karlberg@ericsson.com CC: Troy Cauble , Christian Groves , Anil Jangam , megaco@ietf.org, "Tom-PT Taylor" , "Kevin Boyle" Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> <16178.7310.437463.16305@gargle.gargle.HOWL> <3F332FD0.90309@ericsson.com.au> <3F33B8E3.9030409@bell-labs.com> <16179.63254.17278.479615@gargle.gargle.HOWL> In-Reply-To: <16179.63254.17278.479615@gargle.gargle.HOWL> 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 You should now be using RFC 3525 as the equivalent to H.248.1 version 1. Micael Karlberg wrote: > Hi, > > I made the changes described by Troy: > > 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 / > indAudterminationAudit ) > > This seems to work just fine, and since it is the way it's done > in the IG (h248s-ig) why not use this construction in version 2? > > By the way. I have been using the draft-ietf-megaco-3015corr-03.txt > document assuming it to be up-to-date with the latest IG. It was only > when Troy pointed out the auditReturnItem that I realized that something > was not right. h248s-ig.pdf is dated 25 October 2002 and > draft-ietf-megaco-3015corr-03.txt is dated December 2002 (i.e. later). > Is there a later version of the draft-ietf-megaco-3015corr document > or is it dead (it did expire June 2003)? > > Regards, > /BMK > > Troy Cauble writes: > > Christian Groves wrote: > > > > > > >> > > >> > > So as has been mentioned by Tom we need to fix this. So how > > >> about we delete > audititem from? It removes the ambiguity. > > >> > auditReturnParameter = (mediaDescriptor / modemDescriptor / > > >> > muxDescriptor / eventsDescriptor / > > >> > signalsDescriptor / digitMapDescriptor / > > >> > observedEventsDescriptor / > > >> eventBufferDescriptor / > > >> > statisticsDescriptor / packagesDescriptor / > > >> > errorDescriptor / auditItem) > > >> > > and restore this to v1. > > >> > > >> Delete auditItem from auditReturnParameter? But auditItem was part of > > >> auditReturnParameter even in v1. > > > > > > > > > [CHG] Yes, must have been looking at an old version of v1. > > > > > >> > > >> > > >> > The individual auditing mechanism was only meant to change the > > >> request > mechanisn not what was returned as the "usual" audit reply > > >> > should have been enough to send the data back that you need. Does > > >> this > solve the problem. If not, Micael as you need unambiguous > > >> syntax can you > propose a simple ABNF fix that would solve your > > >> problem/s? > > >> > > >> > > >> I really hope that I am not the only one who is writing a version 2 > > >> parser, or else I am wasting my time (or are about to strike gold :) > > >> > > >> As for a solution, how about adding a token and changing the > > >> definition of indAudterminationAudit to: > > >> > > >> indAudterminationAudit = IndAudTerminationAuditToken > > >> indAudauditReturnParameter > > >> *(COMMA indAudauditReturnParameter) > > >> Not pretty, but it should do the trick. I have not tested it > > >> with real messages, but atleast my parser generator did not complain > > >> anymore. > > > > > > > > > [CHG] I think the point is that the MGC shouldn't be concerned whether > > > the audited parameter is from a descriptor audit or an individual audit. > > > The syntax provided for a descriptor audit is enough to return an > > > individual audit. The problem lies that AuditItem is used both in the > > > command request and reply ABNF. I was thinking about a token yesterday > > > myself but when I had a look at the ASN1 and saw that it used existing > > > AuditDescriptor reply syntax I thought we shouldn't allow using the > > > IndAudRep. > > > Would a rule that, > > > > > > ; For audit replys the indAudterminationAudit SHALL not be used. > > > auditItem = ( MuxToken / ModemToken / MediaToken / > > > SignalsToken / EventBufferToken / > > > DigitMapToken / StatsToken / EventsToken / > > > ObservedEventsToken / PackagesToken ) / > > > indAudterminationAudit) > > > > > > Be a solution? > > > > > > Regards, Christian > > > > IG item 6.3 fixed the related conflicts for V1. It's not clear if being > > in the IG means it applies to V2 as well. > > > > I think 6.3 should be explicitly applied to V2 because > > 1) it makes the two versions more alike, and > > 2) it fixes the conflicts. > > > > > > IG item #6.3 (http://www.itu.int/itudoc/itu-t/com16/implgd/h248s-ig.pdf) > > > > auditReturnParameter = (mediaDescriptor / modemDescriptor / > > muxDescriptor / eventsDescriptor / > > signalsDescriptor / digitMapDescriptor / > > observedEventsDescriptor / > > eventBufferDescriptor / > > statisticsDescriptor / packagesDescriptor / > > errorDescriptor / auditReturnItem) > > > > auditReturnItem = (MuxToken / ModemToken / MediaToken / > > DigitMapToken / StatsToken / > > ObservedEventsToken / PackagesToken ) > > > > ;at-most-once, and DigitMapToken and PackagesToken are not allowed > > ;in AuditCapabilities command > > auditItem = ( auditReturnItem / SignalsToken / > > EventBufferToken / EventsToken ) > > > > > > Note that indAudterminationAudit was not in V1. It must be added to > > auditItem. I think Christian is arguing that those resulting token > > conflicts are not critical, because the indAud variations are always > > followed by "{" or "=", which can distinguish them from the individual > > tokens of an auditItem. So no other changes are necessary. > > > > -troy > > > > > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Aug 8 17:12:05 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 QAA24499 for ; Fri, 8 Aug 2003 16:24:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDmR-0005Yw-Go; Fri, 08 Aug 2003 16:24:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lD3V-00040h-Kl for megaco@optimus.ietf.org; Fri, 08 Aug 2003 15: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 PAA23479 for ; Fri, 8 Aug 2003 15:37:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lD3U-0003JD-00 for megaco@ietf.org; Fri, 08 Aug 2003 15:37:40 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19lD3T-0003Iz-00 for megaco@ietf.org; Fri, 08 Aug 2003 15:37:39 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h78JaTa23890; Fri, 8 Aug 2003 15:36:29 -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 NLVZAKJ0; Fri, 8 Aug 2003 15:36:29 -0400 Received: from nortelnetworks.com (acart1fq.ca.nortel.com [47.129.129.165]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QHD6K331; Fri, 8 Aug 2003 15:36:29 -0400 Message-ID: <3F33FBB6.1060909@nortelnetworks.com> Date: Fri, 08 Aug 2003 15:36:22 -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.4) Gecko/20030624 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: micael.karlberg@ericsson.com CC: Troy Cauble , Christian Groves , Anil Jangam , megaco@ietf.org, "Kevin Boyle" Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> <16178.7310.437463.16305@gargle.gargle.HOWL> <3F332FD0.90309@ericsson.com.au> <3F33B8E3.9030409@bell-labs.com> <16179.63254.17278.479615@gargle.gargle.HOWL> <3F33FB08.50903@nortelnetworks.com> In-Reply-To: <3F33FB08.50903@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit It just occurred to me: you won't see any improvement. RFC 3525 only provides the state as of February 2002. Tom Taylor wrote: > You should now be using RFC 3525 as the equivalent to H.248.1 version 1. > > Micael Karlberg wrote: > > [snip] _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Aug 8 17:12:05 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 QAA24637 for ; Fri, 8 Aug 2003 16:25:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDmt-0005sN-RN for megaco-archive@odin.ietf.org; Fri, 08 Aug 2003 16:24:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78KOZO2022581 for megaco-archive@odin.ietf.org; Fri, 8 Aug 2003 16:24:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDmt-0005rt-NU for megaco-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 16:24: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 QAA24489 for ; Fri, 8 Aug 2003 16:24:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lDmr-0003lw-00 for megaco-web-archive@ietf.org; Fri, 08 Aug 2003 16:24:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lDmp-0003jF-00 for megaco-web-archive@ietf.org; Fri, 08 Aug 2003 16:24:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDmR-0005Yw-Go; Fri, 08 Aug 2003 16:24:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lD3V-00040h-Kl for megaco@optimus.ietf.org; Fri, 08 Aug 2003 15: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 PAA23479 for ; Fri, 8 Aug 2003 15:37:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lD3U-0003JD-00 for megaco@ietf.org; Fri, 08 Aug 2003 15:37:40 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19lD3T-0003Iz-00 for megaco@ietf.org; Fri, 08 Aug 2003 15:37:39 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h78JaTa23890; Fri, 8 Aug 2003 15:36:29 -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 NLVZAKJ0; Fri, 8 Aug 2003 15:36:29 -0400 Received: from nortelnetworks.com (acart1fq.ca.nortel.com [47.129.129.165]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QHD6K331; Fri, 8 Aug 2003 15:36:29 -0400 Message-ID: <3F33FBB6.1060909@nortelnetworks.com> Date: Fri, 08 Aug 2003 15:36:22 -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.4) Gecko/20030624 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: micael.karlberg@ericsson.com CC: Troy Cauble , Christian Groves , Anil Jangam , megaco@ietf.org, "Kevin Boyle" Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> <16178.7310.437463.16305@gargle.gargle.HOWL> <3F332FD0.90309@ericsson.com.au> <3F33B8E3.9030409@bell-labs.com> <16179.63254.17278.479615@gargle.gargle.HOWL> <3F33FB08.50903@nortelnetworks.com> In-Reply-To: <3F33FB08.50903@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It just occurred to me: you won't see any improvement. RFC 3525 only provides the state as of February 2002. Tom Taylor wrote: > You should now be using RFC 3525 as the equivalent to H.248.1 version 1. > > Micael Karlberg wrote: > > [snip] _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Aug 11 01:27:28 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 BAA24775 for ; Mon, 11 Aug 2003 01:27:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m5Cv-0002Jt-Gz; Mon, 11 Aug 2003 01:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m5By-0002Ip-BW for megaco@optimus.ietf.org; Mon, 11 Aug 2003 01:26: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 BAA24738 for ; Mon, 11 Aug 2003 01:25:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m5Bv-0003Bt-00 for megaco@ietf.org; Mon, 11 Aug 2003 01:25:59 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19m5Bt-0003Bq-00 for megaco@ietf.org; Mon, 11 Aug 2003 01:25:58 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h7B5LuF00175; Mon, 11 Aug 2003 15:21:58 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.191]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QBTF9QXC; Mon, 11 Aug 2003 15:25:13 +1000 Message-ID: <3F36F738.4020307@ericsson.com.au> Date: Mon, 11 Aug 2003 11:54:00 +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: micael.karlberg@ericsson.com CC: Troy Cauble , Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> <16178.7310.437463.16305@gargle.gargle.HOWL> <3F332FD0.90309@ericsson.com.au> <3F33B8E3.9030409@bell-labs.com> <16179.63254.17278.479615@gargle.gargle.HOWL> 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 Hello Troy and Micael, I agree with Troy 6.3 the syntax does fix the problem in both empty and non-empty cases. We want to change the heading to make this clear. The other problem which has be highlighted now by several people to me is the fact the IG seems to be for H.248.1v1 only. This is NOT the case. It is for both V1 and V2. If a change is for V1 or V2 only then this is mentioned (see 6.9 & 6.10). I've already prepared a contribution for the September SG16 meeting to clear this confusion up. The IETF draft/RFC do not contain any IG additions nor do the published ITU documents. Regards, Christian Micael Karlberg wrote: > Hi, > > I made the changes described by Troy: > > 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 / > indAudterminationAudit ) > > This seems to work just fine, and since it is the way it's done > in the IG (h248s-ig) why not use this construction in version 2? > > By the way. I have been using the draft-ietf-megaco-3015corr-03.txt > document assuming it to be up-to-date with the latest IG. It was only > when Troy pointed out the auditReturnItem that I realized that something > was not right. h248s-ig.pdf is dated 25 October 2002 and > draft-ietf-megaco-3015corr-03.txt is dated December 2002 (i.e. later). > Is there a later version of the draft-ietf-megaco-3015corr document > or is it dead (it did expire June 2003)? > > Regards, > /BMK > > Troy Cauble writes: > > Christian Groves wrote: > > > > > > >> > > >> > > So as has been mentioned by Tom we need to fix this. So how > > >> about we delete > audititem from? It removes the ambiguity. > > >> > auditReturnParameter = (mediaDescriptor / modemDescriptor / > > >> > muxDescriptor / eventsDescriptor / > > >> > signalsDescriptor / digitMapDescriptor / > > >> > observedEventsDescriptor / > > >> eventBufferDescriptor / > > >> > statisticsDescriptor / packagesDescriptor / > > >> > errorDescriptor / auditItem) > > >> > > and restore this to v1. > > >> > > >> Delete auditItem from auditReturnParameter? But auditItem was part of > > >> auditReturnParameter even in v1. > > > > > > > > > [CHG] Yes, must have been looking at an old version of v1. > > > > > >> > > >> > > >> > The individual auditing mechanism was only meant to change the > > >> request > mechanisn not what was returned as the "usual" audit reply > > >> > should have been enough to send the data back that you need. Does > > >> this > solve the problem. If not, Micael as you need unambiguous > > >> syntax can you > propose a simple ABNF fix that would solve your > > >> problem/s? > > >> > > >> > > >> I really hope that I am not the only one who is writing a version 2 > > >> parser, or else I am wasting my time (or are about to strike gold :) > > >> > > >> As for a solution, how about adding a token and changing the > > >> definition of indAudterminationAudit to: > > >> > > >> indAudterminationAudit = IndAudTerminationAuditToken > > >> indAudauditReturnParameter > > >> *(COMMA indAudauditReturnParameter) > > >> Not pretty, but it should do the trick. I have not tested it > > >> with real messages, but atleast my parser generator did not complain > > >> anymore. > > > > > > > > > [CHG] I think the point is that the MGC shouldn't be concerned whether > > > the audited parameter is from a descriptor audit or an individual audit. > > > The syntax provided for a descriptor audit is enough to return an > > > individual audit. The problem lies that AuditItem is used both in the > > > command request and reply ABNF. I was thinking about a token yesterday > > > myself but when I had a look at the ASN1 and saw that it used existing > > > AuditDescriptor reply syntax I thought we shouldn't allow using the > > > IndAudRep. > > > Would a rule that, > > > > > > ; For audit replys the indAudterminationAudit SHALL not be used. > > > auditItem = ( MuxToken / ModemToken / MediaToken / > > > SignalsToken / EventBufferToken / > > > DigitMapToken / StatsToken / EventsToken / > > > ObservedEventsToken / PackagesToken ) / > > > indAudterminationAudit) > > > > > > Be a solution? > > > > > > Regards, Christian > > > > IG item 6.3 fixed the related conflicts for V1. It's not clear if being > > in the IG means it applies to V2 as well. > > > > I think 6.3 should be explicitly applied to V2 because > > 1) it makes the two versions more alike, and > > 2) it fixes the conflicts. > > > > > > IG item #6.3 (http://www.itu.int/itudoc/itu-t/com16/implgd/h248s-ig.pdf) > > > > auditReturnParameter = (mediaDescriptor / modemDescriptor / > > muxDescriptor / eventsDescriptor / > > signalsDescriptor / digitMapDescriptor / > > observedEventsDescriptor / > > eventBufferDescriptor / > > statisticsDescriptor / packagesDescriptor / > > errorDescriptor / auditReturnItem) > > > > auditReturnItem = (MuxToken / ModemToken / MediaToken / > > DigitMapToken / StatsToken / > > ObservedEventsToken / PackagesToken ) > > > > ;at-most-once, and DigitMapToken and PackagesToken are not allowed > > ;in AuditCapabilities command > > auditItem = ( auditReturnItem / SignalsToken / > > EventBufferToken / EventsToken ) > > > > > > Note that indAudterminationAudit was not in V1. It must be added to > > auditItem. I think Christian is arguing that those resulting token > > conflicts are not critical, because the indAud variations are always > > followed by "{" or "=", which can distinguish them from the individual > > tokens of an auditItem. So no other changes are necessary. > > > > -troy > > > > > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Aug 11 01:27: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 BAA24791 for ; Mon, 11 Aug 2003 01:27: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 19m5Cz-0002Kz-Vf for megaco-archive@odin.ietf.org; Mon, 11 Aug 2003 01:27:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7B5R5e1008983 for megaco-archive@odin.ietf.org; Mon, 11 Aug 2003 01:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m5Cz-0002Ko-QQ for megaco-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 01:27: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 BAA24764 for ; Mon, 11 Aug 2003 01:27:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m5Cw-0003CG-00 for megaco-web-archive@ietf.org; Mon, 11 Aug 2003 01:27:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19m5Cv-0003CA-00 for megaco-web-archive@ietf.org; Mon, 11 Aug 2003 01:27:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m5Cv-0002Jt-Gz; Mon, 11 Aug 2003 01:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m5By-0002Ip-BW for megaco@optimus.ietf.org; Mon, 11 Aug 2003 01:26: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 BAA24738 for ; Mon, 11 Aug 2003 01:25:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m5Bv-0003Bt-00 for megaco@ietf.org; Mon, 11 Aug 2003 01:25:59 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19m5Bt-0003Bq-00 for megaco@ietf.org; Mon, 11 Aug 2003 01:25:58 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h7B5LuF00175; Mon, 11 Aug 2003 15:21:58 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.191]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QBTF9QXC; Mon, 11 Aug 2003 15:25:13 +1000 Message-ID: <3F36F738.4020307@ericsson.com.au> Date: Mon, 11 Aug 2003 11:54:00 +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: micael.karlberg@ericsson.com CC: Troy Cauble , Anil Jangam , megaco@ietf.org, Tom-PT Taylor , Kevin Boyle Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF References: <16150.27894.389089.986520@gargle.gargle.HOWL> <00e301c34c58$c21b2de0$4c0d050a@mahindrabt.com> <16151.48138.771516.776631@gargle.gargle.HOWL> <3F31E2EF.5030800@ericsson.com.au> <16178.7310.437463.16305@gargle.gargle.HOWL> <3F332FD0.90309@ericsson.com.au> <3F33B8E3.9030409@bell-labs.com> <16179.63254.17278.479615@gargle.gargle.HOWL> 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 Hello Troy and Micael, I agree with Troy 6.3 the syntax does fix the problem in both empty and non-empty cases. We want to change the heading to make this clear. The other problem which has be highlighted now by several people to me is the fact the IG seems to be for H.248.1v1 only. This is NOT the case. It is for both V1 and V2. If a change is for V1 or V2 only then this is mentioned (see 6.9 & 6.10). I've already prepared a contribution for the September SG16 meeting to clear this confusion up. The IETF draft/RFC do not contain any IG additions nor do the published ITU documents. Regards, Christian Micael Karlberg wrote: > Hi, > > I made the changes described by Troy: > > 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 / > indAudterminationAudit ) > > This seems to work just fine, and since it is the way it's done > in the IG (h248s-ig) why not use this construction in version 2? > > By the way. I have been using the draft-ietf-megaco-3015corr-03.txt > document assuming it to be up-to-date with the latest IG. It was only > when Troy pointed out the auditReturnItem that I realized that something > was not right. h248s-ig.pdf is dated 25 October 2002 and > draft-ietf-megaco-3015corr-03.txt is dated December 2002 (i.e. later). > Is there a later version of the draft-ietf-megaco-3015corr document > or is it dead (it did expire June 2003)? > > Regards, > /BMK > > Troy Cauble writes: > > Christian Groves wrote: > > > > > > >> > > >> > > So as has been mentioned by Tom we need to fix this. So how > > >> about we delete > audititem from? It removes the ambiguity. > > >> > auditReturnParameter = (mediaDescriptor / modemDescriptor / > > >> > muxDescriptor / eventsDescriptor / > > >> > signalsDescriptor / digitMapDescriptor / > > >> > observedEventsDescriptor / > > >> eventBufferDescriptor / > > >> > statisticsDescriptor / packagesDescriptor / > > >> > errorDescriptor / auditItem) > > >> > > and restore this to v1. > > >> > > >> Delete auditItem from auditReturnParameter? But auditItem was part of > > >> auditReturnParameter even in v1. > > > > > > > > > [CHG] Yes, must have been looking at an old version of v1. > > > > > >> > > >> > > >> > The individual auditing mechanism was only meant to change the > > >> request > mechanisn not what was returned as the "usual" audit reply > > >> > should have been enough to send the data back that you need. Does > > >> this > solve the problem. If not, Micael as you need unambiguous > > >> syntax can you > propose a simple ABNF fix that would solve your > > >> problem/s? > > >> > > >> > > >> I really hope that I am not the only one who is writing a version 2 > > >> parser, or else I am wasting my time (or are about to strike gold :) > > >> > > >> As for a solution, how about adding a token and changing the > > >> definition of indAudterminationAudit to: > > >> > > >> indAudterminationAudit = IndAudTerminationAuditToken > > >> indAudauditReturnParameter > > >> *(COMMA indAudauditReturnParameter) > > >> Not pretty, but it should do the trick. I have not tested it > > >> with real messages, but atleast my parser generator did not complain > > >> anymore. > > > > > > > > > [CHG] I think the point is that the MGC shouldn't be concerned whether > > > the audited parameter is from a descriptor audit or an individual audit. > > > The syntax provided for a descriptor audit is enough to return an > > > individual audit. The problem lies that AuditItem is used both in the > > > command request and reply ABNF. I was thinking about a token yesterday > > > myself but when I had a look at the ASN1 and saw that it used existing > > > AuditDescriptor reply syntax I thought we shouldn't allow using the > > > IndAudRep. > > > Would a rule that, > > > > > > ; For audit replys the indAudterminationAudit SHALL not be used. > > > auditItem = ( MuxToken / ModemToken / MediaToken / > > > SignalsToken / EventBufferToken / > > > DigitMapToken / StatsToken / EventsToken / > > > ObservedEventsToken / PackagesToken ) / > > > indAudterminationAudit) > > > > > > Be a solution? > > > > > > Regards, Christian > > > > IG item 6.3 fixed the related conflicts for V1. It's not clear if being > > in the IG means it applies to V2 as well. > > > > I think 6.3 should be explicitly applied to V2 because > > 1) it makes the two versions more alike, and > > 2) it fixes the conflicts. > > > > > > IG item #6.3 (http://www.itu.int/itudoc/itu-t/com16/implgd/h248s-ig.pdf) > > > > auditReturnParameter = (mediaDescriptor / modemDescriptor / > > muxDescriptor / eventsDescriptor / > > signalsDescriptor / digitMapDescriptor / > > observedEventsDescriptor / > > eventBufferDescriptor / > > statisticsDescriptor / packagesDescriptor / > > errorDescriptor / auditReturnItem) > > > > auditReturnItem = (MuxToken / ModemToken / MediaToken / > > DigitMapToken / StatsToken / > > ObservedEventsToken / PackagesToken ) > > > > ;at-most-once, and DigitMapToken and PackagesToken are not allowed > > ;in AuditCapabilities command > > auditItem = ( auditReturnItem / SignalsToken / > > EventBufferToken / EventsToken ) > > > > > > Note that indAudterminationAudit was not in V1. It must be added to > > auditItem. I think Christian is arguing that those resulting token > > conflicts are not critical, because the indAud variations are always > > followed by "{" or "=", which can distinguish them from the individual > > tokens of an auditItem. So no other changes are necessary. > > > > -troy > > > > > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Aug 11 17:36:28 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 RAA07384 for ; Mon, 11 Aug 2003 17:36:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mKKg-0005w6-Nq; Mon, 11 Aug 2003 17: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 19mKJs-0005vb-Pv for megaco@optimus.ietf.org; Mon, 11 Aug 2003 17:35: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 RAA07366 for ; Mon, 11 Aug 2003 17:35:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mKJq-0002cl-00 for megaco@ietf.org; Mon, 11 Aug 2003 17:35:10 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19mKJp-0002ch-00 for megaco@ietf.org; Mon, 11 Aug 2003 17:35:09 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h7BLZ71e000290; Mon, 11 Aug 2003 14:35:07 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h7BKXqBh028832; Mon, 11 Aug 2003 15:33:53 -0500 Message-ID: <3F380C1A.AF46D23B@motorola.com> Date: Mon, 11 Aug 2003 16:35:22 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: zhou.zichun@zte.com.cn CC: Aleksandr Ryabin , megaco@ietf.org, Tom Taylor Subject: Re: [Megaco] A question about H.248 on SCTP References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate5.mot.com id h7BLZ71e000290 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 A late response to an old email... My comments in-line. zhou.zichun@zte.com.cn wrote: >=20 > Hi,all > As Tom said,I agree we can split a MGW into several virtual MGWs to > solve huge MGW problem. > As Aleks said, I agree the transport connection type of > TCP/UDP/SCTP/MTP3B/M3UA are of no difference. > Maybe may question should be renamed to How H.248 be used in big sys= tem, > not only about SCTP transport connections. > The problem is: how many transport connection should exist bewteen a > pair MGC-MGW? The MGC's servicechange transaction can provide only one > IP+PORT(etc.) indication. If the answer is only one connection such as > TCP/SCTP could exist between MGC-MGW pair, since hardware capacity is > limited one connection can provide limited H.248 transaction delivery > ability. In 3GPP when we design big MGW system, one connection capacity= is > not efficient. One word, must we split the MGW into several little syst= ems > to provide several logical interface to MGC? I think It's inconvenient = for > system maintenance and evolvement. I think you are asking a system design question. This is a decision system designer needs to make. If you choose to use multiple connections (TCP, SCTP, or UDP), you will pay the cost for more complexity in your application design and system operation and configuration because your app will need now to manage multiple connections. Using a single connection simplifies design and I do not see any inherited problem for doing so.=20 For large system, the bigger concern is often the reliability of the connection since if it fails you will have a large impact. In this respect, SCTP can potentially give you some advantages over UDP or TCP due to its multi-homing capability to support redundant NICs and cabling. Making use of SCTP streams will help avoid head-of-line blocking problem, but you don't have to do it if head-of-line blocking is not one of your concerns. -Qiaobing > I think Aleks and Tom didn't recognize my true idea. In my before > scenario ,the MGC has 2 machines(processor) to process one MGW, these 2 > machines belong to ONE MGC, maybe there are more than one machine on MG= W > too, not in our sight. When 2 or more porcessor existed the processor > identify is a problem. As Aleks said we can parse the RequestIdentifier= to > identify the processor, but don't u think it waste a lot time, and this > method cann't let MGC process the calling state termination out of serv= ice > ServiceChange transactions. I insist predefined CONTEXTID between MGC-M= GW > is a better way to solve this problem. Or MEGACO define this:" CONTEXTI= D is > predefined on MGW, MGC can audit CONTEXTID from MGW after MGW registeri= ng". > We can get CONTEXTID with few parsing steps. Of course we must deal wit= h > multi-transactions in one message, this is a easier scanning work compa= re > with word to word parsing. >=20 > I didn't think two MGCs can operate one MGW, a logic MGW should belo= ng > to one MGC. As MEGACO definition the CONTEXTID is valid between a MGC-M= GW > pair, so the CONTEXTID selected by MGC is possible. The big advantage o= f > this rule is let H.248 act like a call related protocol more. > I'm confused by Aleks's words: "a message can contain several > transactions with terminationIds 'serviced' by different MGCs". I think > this couldn't happen because there should be diffent transport connecti= ons > from different MGCs to a physical MGW(this MGW was splitted to differen= t > MGWs). >=20 > Best regards, > Zichun >=20 > Tom Taylor says: >=20 > >The MGC controls which address and port the MGW sends its Notify to, i= n > the > >ServiceChange reply. Of course, this is a static arrangement. You ca= n > divide > >things up by splitting the MGW up into virtual machines, but yes, I ag= ree > that you > >cannot dynamically loadshare the control of one MGW between two MGCs. > That is a > >deliberate constraint in Megaco because dynamic sharing would mean you > need some way > >to resolve contention if two MGCs try to use the same resources. >=20 >=20 > Aleksandr > Ryabin =CA=D5=BC=FE=C8=CB=A3=BA z= hou.zichun@zte.com.cn, > ia.com> =B3=AD=CB=CD=A3=BA Tom Taylor= > =D6=F7=CC=E2=A3=BA Re: [Megac= o] A question about H.248 on > SCTP >=20 > 2003-06-26 > 23:14 >=20 >=20 >=20 > Hi, >=20 > 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 >=20 > Regards, > Aleks >=20 > At 04:26 AM 6/26/2003, zhou.zichun@zte.com.cn wrote: >=20 > >Tom, > > This rule can ensure one side message sequencely arrived at the pee= r. > But > >only the message sequence assurance is not efficient in big systems. M= aybe > >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 on= e > MGW. > >Since SCTP cann't provide one association on different machines. So th= ere > >are at least two association on machine A and B. When a context need t= o 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 proces= sing > >pair. Since every call is combined with a CIC number, every TUP/ISUP c= all > >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 provi= de > >CONTEXTID between MGW/MSC, but unfortunately, the CONTEXTID is dynamic= lly > >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 h= uge, > >the incoming MEGACO message distribution is a problem, the MEGACO bear= er > >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.2= 48 > >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 CONT= EXT > >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 la= yer > >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 be= long > >one context, also the load balance of transport layer links. > > > > Best regards. > > > > Zichun > > > > > > > > > > > > > > > > > > Tom > > Taylor > > > zhou.zichun@zte.com.cn > > works.com> =B3=AD=CB=CD=A3=BA megac= o@ietf.org > > > > =D6=F7=CC=E2=A3=BA Re: [= Megaco] A > > question about H.248 on > > SCTP > > > > > > > > 2003-06-26 > > 01:19 > > > > > > > > > > > > > > > > > > > >It really doesn't matter which stream each end uses, so long as one en= d > >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 ar= e > > > transported over the same stream. SCTP transmits messages and proce= sses > > > received messages in one stream. > > > > > > When MGC and MG exchange informations. The MG/MGC maybe get conte= xt_A > > > messages from inbound stream_1, but send out context_A messages fro= m > >inboud > > > stream_2, the paper didn't tell us the streams MUST be used as pair= s: > > > 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 res= pond > >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 conte= xt > in > > > one association ,but received reply in another association, MGC hav= e to > > > forward the message to the initiated place. Doesn't it looks strang= e? > >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? > > i?z=D7=E8=AEm=B6=9B??0?=AD~=8A=E0=FEf=A2=ADf=A7=FEX=AC=B6)=DF=A3=F9=9E= =81=A7( >=20 > 1=E8 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Aug 11 17: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 RAA07399 for ; Mon, 11 Aug 2003 17:36: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 19mKKk-0005wu-3x for megaco-archive@odin.ietf.org; Mon, 11 Aug 2003 17:36:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BLa6Ji022865 for megaco-archive@odin.ietf.org; Mon, 11 Aug 2003 17:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mKKj-0005wg-Vr for megaco-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 17:36: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 RAA07381 for ; Mon, 11 Aug 2003 17:35:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mKKh-0002d4-00 for megaco-web-archive@ietf.org; Mon, 11 Aug 2003 17:36:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mKKg-0002d1-00 for megaco-web-archive@ietf.org; Mon, 11 Aug 2003 17:36:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mKKg-0005w6-Nq; Mon, 11 Aug 2003 17: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 19mKJs-0005vb-Pv for megaco@optimus.ietf.org; Mon, 11 Aug 2003 17:35: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 RAA07366 for ; Mon, 11 Aug 2003 17:35:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mKJq-0002cl-00 for megaco@ietf.org; Mon, 11 Aug 2003 17:35:10 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19mKJp-0002ch-00 for megaco@ietf.org; Mon, 11 Aug 2003 17:35:09 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h7BLZ71e000290; Mon, 11 Aug 2003 14:35:07 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h7BKXqBh028832; Mon, 11 Aug 2003 15:33:53 -0500 Message-ID: <3F380C1A.AF46D23B@motorola.com> Date: Mon, 11 Aug 2003 16:35:22 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: zhou.zichun@zte.com.cn CC: Aleksandr Ryabin , megaco@ietf.org, Tom Taylor Subject: Re: [Megaco] A question about H.248 on SCTP References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate5.mot.com id h7BLZ71e000290 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 A late response to an old email... My comments in-line. zhou.zichun@zte.com.cn wrote: >=20 > Hi,all > As Tom said,I agree we can split a MGW into several virtual MGWs to > solve huge MGW problem. > As Aleks said, I agree the transport connection type of > TCP/UDP/SCTP/MTP3B/M3UA are of no difference. > Maybe may question should be renamed to How H.248 be used in big sys= tem, > not only about SCTP transport connections. > The problem is: how many transport connection should exist bewteen a > pair MGC-MGW? The MGC's servicechange transaction can provide only one > IP+PORT(etc.) indication. If the answer is only one connection such as > TCP/SCTP could exist between MGC-MGW pair, since hardware capacity is > limited one connection can provide limited H.248 transaction delivery > ability. In 3GPP when we design big MGW system, one connection capacity= is > not efficient. One word, must we split the MGW into several little syst= ems > to provide several logical interface to MGC? I think It's inconvenient = for > system maintenance and evolvement. I think you are asking a system design question. This is a decision system designer needs to make. If you choose to use multiple connections (TCP, SCTP, or UDP), you will pay the cost for more complexity in your application design and system operation and configuration because your app will need now to manage multiple connections. Using a single connection simplifies design and I do not see any inherited problem for doing so.=20 For large system, the bigger concern is often the reliability of the connection since if it fails you will have a large impact. In this respect, SCTP can potentially give you some advantages over UDP or TCP due to its multi-homing capability to support redundant NICs and cabling. Making use of SCTP streams will help avoid head-of-line blocking problem, but you don't have to do it if head-of-line blocking is not one of your concerns. -Qiaobing > I think Aleks and Tom didn't recognize my true idea. In my before > scenario ,the MGC has 2 machines(processor) to process one MGW, these 2 > machines belong to ONE MGC, maybe there are more than one machine on MG= W > too, not in our sight. When 2 or more porcessor existed the processor > identify is a problem. As Aleks said we can parse the RequestIdentifier= to > identify the processor, but don't u think it waste a lot time, and this > method cann't let MGC process the calling state termination out of serv= ice > ServiceChange transactions. I insist predefined CONTEXTID between MGC-M= GW > is a better way to solve this problem. Or MEGACO define this:" CONTEXTI= D is > predefined on MGW, MGC can audit CONTEXTID from MGW after MGW registeri= ng". > We can get CONTEXTID with few parsing steps. Of course we must deal wit= h > multi-transactions in one message, this is a easier scanning work compa= re > with word to word parsing. >=20 > I didn't think two MGCs can operate one MGW, a logic MGW should belo= ng > to one MGC. As MEGACO definition the CONTEXTID is valid between a MGC-M= GW > pair, so the CONTEXTID selected by MGC is possible. The big advantage o= f > this rule is let H.248 act like a call related protocol more. > I'm confused by Aleks's words: "a message can contain several > transactions with terminationIds 'serviced' by different MGCs". I think > this couldn't happen because there should be diffent transport connecti= ons > from different MGCs to a physical MGW(this MGW was splitted to differen= t > MGWs). >=20 > Best regards, > Zichun >=20 > Tom Taylor says: >=20 > >The MGC controls which address and port the MGW sends its Notify to, i= n > the > >ServiceChange reply. Of course, this is a static arrangement. You ca= n > divide > >things up by splitting the MGW up into virtual machines, but yes, I ag= ree > that you > >cannot dynamically loadshare the control of one MGW between two MGCs. > That is a > >deliberate constraint in Megaco because dynamic sharing would mean you > need some way > >to resolve contention if two MGCs try to use the same resources. >=20 >=20 > Aleksandr > Ryabin =CA=D5=BC=FE=C8=CB=A3=BA z= hou.zichun@zte.com.cn, > ia.com> =B3=AD=CB=CD=A3=BA Tom Taylor= > =D6=F7=CC=E2=A3=BA Re: [Megac= o] A question about H.248 on > SCTP >=20 > 2003-06-26 > 23:14 >=20 >=20 >=20 > Hi, >=20 > 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 >=20 > Regards, > Aleks >=20 > At 04:26 AM 6/26/2003, zhou.zichun@zte.com.cn wrote: >=20 > >Tom, > > This rule can ensure one side message sequencely arrived at the pee= r. > But > >only the message sequence assurance is not efficient in big systems. M= aybe > >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 on= e > MGW. > >Since SCTP cann't provide one association on different machines. So th= ere > >are at least two association on machine A and B. When a context need t= o 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 proces= sing > >pair. Since every call is combined with a CIC number, every TUP/ISUP c= all > >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 provi= de > >CONTEXTID between MGW/MSC, but unfortunately, the CONTEXTID is dynamic= lly > >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 h= uge, > >the incoming MEGACO message distribution is a problem, the MEGACO bear= er > >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.2= 48 > >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 CONT= EXT > >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 la= yer > >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 be= long > >one context, also the load balance of transport layer links. > > > > Best regards. > > > > Zichun > > > > > > > > > > > > > > > > > > Tom > > Taylor > > > zhou.zichun@zte.com.cn > > works.com> =B3=AD=CB=CD=A3=BA megac= o@ietf.org > > > > =D6=F7=CC=E2=A3=BA Re: [= Megaco] A > > question about H.248 on > > SCTP > > > > > > > > 2003-06-26 > > 01:19 > > > > > > > > > > > > > > > > > > > >It really doesn't matter which stream each end uses, so long as one en= d > >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 ar= e > > > transported over the same stream. SCTP transmits messages and proce= sses > > > received messages in one stream. > > > > > > When MGC and MG exchange informations. The MG/MGC maybe get conte= xt_A > > > messages from inbound stream_1, but send out context_A messages fro= m > >inboud > > > stream_2, the paper didn't tell us the streams MUST be used as pair= s: > > > 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 res= pond > >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 conte= xt > in > > > one association ,but received reply in another association, MGC hav= e to > > > forward the message to the initiated place. Doesn't it looks strang= e? > >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? > > i?z=D7=E8=AEm=B6=9B??0?=AD~=8A=E0=FEf=A2=ADf=A7=FEX=AC=B6)=DF=A3=F9=9E= =81=A7( >=20 > 1=E8 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Aug 12 09:12: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 JAA11659 for ; Tue, 12 Aug 2003 09:12: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 19mYwT-00026h-N3; Tue, 12 Aug 2003 09:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mY4v-0000ho-5O for megaco@optimus.ietf.org; Tue, 12 Aug 2003 08:16: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 IAA10423 for ; Tue, 12 Aug 2003 08:16:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mY4u-0007iH-00 for megaco@ietf.org; Tue, 12 Aug 2003 08:16:40 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 19mY4t-0007iE-00 for megaco@ietf.org; Tue, 12 Aug 2003 08:16:39 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h7CCGcJ11498 for ; Tue, 12 Aug 2003 14:16:38 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h7CCGbG13270 for ; Tue, 12 Aug 2003 14:16:37 +0200 (MEST) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id OAA08378 for ; Tue, 12 Aug 2003 14:16:37 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Tue, 12 Aug 2003 14:15:57 +0200 Message-ID: <2F0349FB836CD411AB1D00508B95270306DE7412@mchh268e.mchh.siemens.de> From: Tegeler Juergen To: megaco@ietf.org Date: Tue, 12 Aug 2003 14:15:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Megaco] new parameter "auditItem" of ServiceChange Descriptor in H.248.1 v2 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 all, I noticed that in annex B of H.248.1 v2 (text encoding)=20 the ServiceChange descriptor has the new parameter "auditItem": serviceChangeParm =3D (serviceChangeMethod / serviceChangeReason / serviceChangeDelay / serviceChangeAddress / =20 serviceChangeProfile / extension / TimeStamp / serviceChangeMgcId / serviceChangeVersion /=20 auditItem) =20 This is not the case in H.248.1 v1. However, neither in chapter 7.1.13 (ServiceChange descriptor) nor in=20 chapter 7.2.8 (ServiceChange command) I found a description of this=20 parameter.=20 Can you explain its purpose and how it should be used? Best regards, =20 J=FCrgen Tegeler ____________________________________________ SIEMENS ICN CP D NA A 12 Machtlfinger Str. 1 Tel.: +49 89 722 23340 D-81359 Muenchen Fax.: +49 89 722 28770 Germany eMail: Juergen.Tegeler@siemens.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue Aug 12 09:12: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 JAA11674 for ; Tue, 12 Aug 2003 09:12: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 19mYwZ-000283-2o for megaco-archive@odin.ietf.org; Tue, 12 Aug 2003 09:12:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CDC7gL008179 for megaco-archive@odin.ietf.org; Tue, 12 Aug 2003 09:12:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mYwY-00027q-VK for megaco-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 09:12: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 JAA11636 for ; Tue, 12 Aug 2003 09:12:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mYwX-0000Ap-00 for megaco-web-archive@ietf.org; Tue, 12 Aug 2003 09:12:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mYwW-0000Ak-00 for megaco-web-archive@ietf.org; Tue, 12 Aug 2003 09:12:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mYwT-00026h-N3; Tue, 12 Aug 2003 09:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mY4v-0000ho-5O for megaco@optimus.ietf.org; Tue, 12 Aug 2003 08:16: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 IAA10423 for ; Tue, 12 Aug 2003 08:16:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mY4u-0007iH-00 for megaco@ietf.org; Tue, 12 Aug 2003 08:16:40 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 19mY4t-0007iE-00 for megaco@ietf.org; Tue, 12 Aug 2003 08:16:39 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h7CCGcJ11498 for ; Tue, 12 Aug 2003 14:16:38 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h7CCGbG13270 for ; Tue, 12 Aug 2003 14:16:37 +0200 (MEST) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id OAA08378 for ; Tue, 12 Aug 2003 14:16:37 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Tue, 12 Aug 2003 14:15:57 +0200 Message-ID: <2F0349FB836CD411AB1D00508B95270306DE7412@mchh268e.mchh.siemens.de> From: Tegeler Juergen To: megaco@ietf.org Date: Tue, 12 Aug 2003 14:15:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Megaco] new parameter "auditItem" of ServiceChange Descriptor in H.248.1 v2 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 all, I noticed that in annex B of H.248.1 v2 (text encoding)=20 the ServiceChange descriptor has the new parameter "auditItem": serviceChangeParm =3D (serviceChangeMethod / serviceChangeReason / serviceChangeDelay / serviceChangeAddress / =20 serviceChangeProfile / extension / TimeStamp / serviceChangeMgcId / serviceChangeVersion /=20 auditItem) =20 This is not the case in H.248.1 v1. However, neither in chapter 7.1.13 (ServiceChange descriptor) nor in=20 chapter 7.2.8 (ServiceChange command) I found a description of this=20 parameter.=20 Can you explain its purpose and how it should be used? Best regards, =20 J=FCrgen Tegeler ____________________________________________ SIEMENS ICN CP D NA A 12 Machtlfinger Str. 1 Tel.: +49 89 722 23340 D-81359 Muenchen Fax.: +49 89 722 28770 Germany eMail: Juergen.Tegeler@siemens.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Aug 12 20:17:28 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 UAA04633 for ; Tue, 12 Aug 2003 20:17:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mjK0-000122-M6; Tue, 12 Aug 2003 20:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mjJh-00011e-Am for megaco@optimus.ietf.org; Tue, 12 Aug 2003 20:16: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 UAA04453 for ; Tue, 12 Aug 2003 20:16:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mjJf-0004mi-00 for megaco@ietf.org; Tue, 12 Aug 2003 20:16:39 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19mjJe-0004me-00 for megaco@ietf.org; Tue, 12 Aug 2003 20:16:38 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h7D0DRF15083; Wed, 13 Aug 2003 10:13:28 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.188]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYCP5CDG; Wed, 13 Aug 2003 10:15:58 +1000 Message-ID: <3F3982D0.7000406@ericsson.com.au> Date: Wed, 13 Aug 2003 10:14:08 +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: Tegeler Juergen CC: megaco@ietf.org Subject: Re: [Megaco] new parameter "auditItem" of ServiceChange Descriptor in H.248.1 v2 References: <2F0349FB836CD411AB1D00508B95270306DE7412@mchh268e.mchh.siemens.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ish7.ericsson.com.au id h7D0DRF15083 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Juergen, 7.2.8 describes the parameter "ServiceChangeInfo". ie. ServiceChangeInfo=20 parameter may contain the package/property/signal/event/statistic of the = reason=20 that caused the service change. auditItem is the text way of returning this information. Regards, Christian Tegeler Juergen wrote: > Hi all, >=20 > I noticed that in annex B of H.248.1 v2 (text encoding)=20 > the ServiceChange descriptor has the new parameter "auditItem": >=20 > serviceChangeParm =3D (serviceChangeMethod / serviceChangeReason / > serviceChangeDelay / serviceChangeAddress / =20 > serviceChangeProfile / extension / TimeStamp / > serviceChangeMgcId / serviceChangeVersion /=20 > auditItem) > =20 > This is not the case in H.248.1 v1. > However, neither in chapter 7.1.13 (ServiceChange descriptor) nor in=20 > chapter 7.2.8 (ServiceChange command) I found a description of this=20 > parameter.=20 > Can you explain its purpose and how it should be used? >=20 > Best regards, =20 >=20 > J=FCrgen Tegeler > ____________________________________________ >=20 > SIEMENS > ICN CP D NA A 12 > Machtlfinger Str. 1 Tel.: +49 89 722 23340 > D-81359 Muenchen Fax.: +49 89 722 28770 > Germany eMail: Juergen.Tegeler@siemens.com >=20 >=20 >=20 > _______________________________________________ > 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 From exim@www1.ietf.org Tue Aug 12 20:17: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 UAA04648 for ; Tue, 12 Aug 2003 20:17:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mjKC-00013M-2T for megaco-archive@odin.ietf.org; Tue, 12 Aug 2003 20:17:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7D0HCBY004044 for megaco-archive@odin.ietf.org; Tue, 12 Aug 2003 20:17:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mjKB-000139-Tc for megaco-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 20: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 UAA04530 for ; Tue, 12 Aug 2003 20:17:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mjK9-0004p0-00 for megaco-web-archive@ietf.org; Tue, 12 Aug 2003 20:17:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mjK0-0004oX-00 for megaco-web-archive@ietf.org; Tue, 12 Aug 2003 20:17:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mjK0-000122-M6; Tue, 12 Aug 2003 20:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mjJh-00011e-Am for megaco@optimus.ietf.org; Tue, 12 Aug 2003 20:16: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 UAA04453 for ; Tue, 12 Aug 2003 20:16:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mjJf-0004mi-00 for megaco@ietf.org; Tue, 12 Aug 2003 20:16:39 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19mjJe-0004me-00 for megaco@ietf.org; Tue, 12 Aug 2003 20:16:38 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h7D0DRF15083; Wed, 13 Aug 2003 10:13:28 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.188]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYCP5CDG; Wed, 13 Aug 2003 10:15:58 +1000 Message-ID: <3F3982D0.7000406@ericsson.com.au> Date: Wed, 13 Aug 2003 10:14:08 +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: Tegeler Juergen CC: megaco@ietf.org Subject: Re: [Megaco] new parameter "auditItem" of ServiceChange Descriptor in H.248.1 v2 References: <2F0349FB836CD411AB1D00508B95270306DE7412@mchh268e.mchh.siemens.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ish7.ericsson.com.au id h7D0DRF15083 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 Hello Juergen, 7.2.8 describes the parameter "ServiceChangeInfo". ie. ServiceChangeInfo=20 parameter may contain the package/property/signal/event/statistic of the = reason=20 that caused the service change. auditItem is the text way of returning this information. Regards, Christian Tegeler Juergen wrote: > Hi all, >=20 > I noticed that in annex B of H.248.1 v2 (text encoding)=20 > the ServiceChange descriptor has the new parameter "auditItem": >=20 > serviceChangeParm =3D (serviceChangeMethod / serviceChangeReason / > serviceChangeDelay / serviceChangeAddress / =20 > serviceChangeProfile / extension / TimeStamp / > serviceChangeMgcId / serviceChangeVersion /=20 > auditItem) > =20 > This is not the case in H.248.1 v1. > However, neither in chapter 7.1.13 (ServiceChange descriptor) nor in=20 > chapter 7.2.8 (ServiceChange command) I found a description of this=20 > parameter.=20 > Can you explain its purpose and how it should be used? >=20 > Best regards, =20 >=20 > J=FCrgen Tegeler > ____________________________________________ >=20 > SIEMENS > ICN CP D NA A 12 > Machtlfinger Str. 1 Tel.: +49 89 722 23340 > D-81359 Muenchen Fax.: +49 89 722 28770 > Germany eMail: Juergen.Tegeler@siemens.com >=20 >=20 >=20 > _______________________________________________ > 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 From megaco-admin@ietf.org Wed Aug 13 00:41:26 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 AAA11690 for ; Wed, 13 Aug 2003 00:41:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mnRV-0003by-Jx; Wed, 13 Aug 2003 00:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mnR6-0003as-9Y for megaco@optimus.ietf.org; Wed, 13 Aug 2003 00:40:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11674 for ; Wed, 13 Aug 2003 00:40:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mnR3-0006QZ-00 for megaco@ietf.org; Wed, 13 Aug 2003 00:40:33 -0400 Received: from web10701.mail.yahoo.com ([216.136.130.209]) by ietf-mx with smtp (Exim 4.12) id 19mnR2-0006QW-00 for megaco@ietf.org; Wed, 13 Aug 2003 00:40:32 -0400 Message-ID: <20030813044032.81688.qmail@web10701.mail.yahoo.com> Received: from [203.124.158.2] by web10701.mail.yahoo.com via HTTP; Wed, 13 Aug 2003 14:40:32 EST Date: Wed, 13 Aug 2003 14:40:32 +1000 (EST) From: =?iso-8859-1?q?petric=20john?= Subject: Re: [Megaco] new parameter "auditItem" of ServiceChange Descriptor in H.248.1 v2 To: Christian Groves , Tegeler Juergen Cc: megaco@ietf.org In-Reply-To: <3F3982D0.7000406@ericsson.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, Whats the relation between the various version of megaco protocol floating around?? There is IETF's RFC-3525, then there is IETF's draft-ietf-megaco-h248v2-04.txt and last there is ITU-T-H248.1 Its really becoming confusing to keep track of all of them. The following 'ServiceChangeInfo' parameter is not defined in RFC3525. When it will be updated? /Pjohn. --- Christian Groves wrote: > Hello Juergen, > > 7.2.8 describes the parameter "ServiceChangeInfo". > ie. ServiceChangeInfo > parameter may contain the > package/property/signal/event/statistic of the > reason > that caused the service change. > > auditItem is the text way of returning this > information. > > Regards, Christian > http://search.yahoo.com.au - Yahoo! Search - Looking for more? Try the new Yahoo! Search _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Aug 13 00:41:28 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 AAA11705 for ; Wed, 13 Aug 2003 00:41:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mnRX-0003dH-AE for megaco-archive@odin.ietf.org; Wed, 13 Aug 2003 00:41:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7D4f3n2013957 for megaco-archive@odin.ietf.org; Wed, 13 Aug 2003 00:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mnRX-0003d2-5c for megaco-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 00: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 AAA11681 for ; Wed, 13 Aug 2003 00:40:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mnRU-0006Qm-00 for megaco-web-archive@ietf.org; Wed, 13 Aug 2003 00:41:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mnRT-0006Qj-00 for megaco-web-archive@ietf.org; Wed, 13 Aug 2003 00:40:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mnRV-0003by-Jx; Wed, 13 Aug 2003 00:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mnR6-0003as-9Y for megaco@optimus.ietf.org; Wed, 13 Aug 2003 00:40:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11674 for ; Wed, 13 Aug 2003 00:40:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mnR3-0006QZ-00 for megaco@ietf.org; Wed, 13 Aug 2003 00:40:33 -0400 Received: from web10701.mail.yahoo.com ([216.136.130.209]) by ietf-mx with smtp (Exim 4.12) id 19mnR2-0006QW-00 for megaco@ietf.org; Wed, 13 Aug 2003 00:40:32 -0400 Message-ID: <20030813044032.81688.qmail@web10701.mail.yahoo.com> Received: from [203.124.158.2] by web10701.mail.yahoo.com via HTTP; Wed, 13 Aug 2003 14:40:32 EST Date: Wed, 13 Aug 2003 14:40:32 +1000 (EST) From: =?iso-8859-1?q?petric=20john?= Subject: Re: [Megaco] new parameter "auditItem" of ServiceChange Descriptor in H.248.1 v2 To: Christian Groves , Tegeler Juergen Cc: megaco@ietf.org In-Reply-To: <3F3982D0.7000406@ericsson.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 Hi, Whats the relation between the various version of megaco protocol floating around?? There is IETF's RFC-3525, then there is IETF's draft-ietf-megaco-h248v2-04.txt and last there is ITU-T-H248.1 Its really becoming confusing to keep track of all of them. The following 'ServiceChangeInfo' parameter is not defined in RFC3525. When it will be updated? /Pjohn. --- Christian Groves wrote: > Hello Juergen, > > 7.2.8 describes the parameter "ServiceChangeInfo". > ie. ServiceChangeInfo > parameter may contain the > package/property/signal/event/statistic of the > reason > that caused the service change. > > auditItem is the text way of returning this > information. > > Regards, Christian > http://search.yahoo.com.au - Yahoo! Search - Looking for more? Try the new Yahoo! Search _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Aug 13 02:19:28 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 CAA29202 for ; Wed, 13 Aug 2003 02:19:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19moyM-00087p-3j; Wed, 13 Aug 2003 02:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19moxx-000876-Jm for megaco@optimus.ietf.org; Wed, 13 Aug 2003 02:18: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 CAA28228 for ; Wed, 13 Aug 2003 02:18:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19moxt-0006yx-00 for megaco@ietf.org; Wed, 13 Aug 2003 02:18:33 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19moxs-0006yu-00 for megaco@ietf.org; Wed, 13 Aug 2003 02:18:32 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h7D6FFF29919; Wed, 13 Aug 2003 16:15:15 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.135]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYCP526L; Wed, 13 Aug 2003 16:17:47 +1000 Message-ID: <3F39D797.9000703@ericsson.com.au> Date: Wed, 13 Aug 2003 16:15:51 +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: petric john CC: Tegeler Juergen , megaco@ietf.org Subject: Re: [Megaco] new parameter "auditItem" of ServiceChange Descriptor in H.248.1 v2 References: <20030813044032.81688.qmail@web10701.mail.yahoo.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 Hello John, RFC3525 is H.248.1 Version 1. ServiceChangeInfo was introduced in H.248.1 Version 2. RFC3525 will not be updated. draft-ietf-megaco-h248v2-04.txt is a copy of H.248.1 Version 2. Hopefully this will become another RFC. Regards, Christian petric john wrote: > Hi, > Whats the relation between the various version of > megaco protocol floating around?? > > There is IETF's RFC-3525, then there is IETF's > draft-ietf-megaco-h248v2-04.txt and last there is > ITU-T-H248.1 Its really becoming confusing to keep > track of all of them. > > The following 'ServiceChangeInfo' parameter is not > defined in RFC3525. When it will be updated? > > /Pjohn. > > --- Christian Groves > wrote: > Hello > Juergen, > >>7.2.8 describes the parameter "ServiceChangeInfo". >>ie. ServiceChangeInfo >>parameter may contain the >>package/property/signal/event/statistic of the >>reason >>that caused the service change. >> >>auditItem is the text way of returning this >>information. >> >>Regards, Christian >> > > > > http://search.yahoo.com.au - Yahoo! Search > - Looking for more? Try the new Yahoo! Search > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Aug 13 02:19: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 CAA29265 for ; Wed, 13 Aug 2003 02:19: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 19moyQ-000890-1f for megaco-archive@odin.ietf.org; Wed, 13 Aug 2003 02:19:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7D6J5a6031276 for megaco-archive@odin.ietf.org; Wed, 13 Aug 2003 02:19:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19moyO-00088N-OE for megaco-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 02:19: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 CAA28704 for ; Wed, 13 Aug 2003 02:18:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19moyK-0006z3-00 for megaco-web-archive@ietf.org; Wed, 13 Aug 2003 02:19:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19moyK-0006z0-00 for megaco-web-archive@ietf.org; Wed, 13 Aug 2003 02:19:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19moyM-00087p-3j; Wed, 13 Aug 2003 02:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19moxx-000876-Jm for megaco@optimus.ietf.org; Wed, 13 Aug 2003 02:18: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 CAA28228 for ; Wed, 13 Aug 2003 02:18:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19moxt-0006yx-00 for megaco@ietf.org; Wed, 13 Aug 2003 02:18:33 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19moxs-0006yu-00 for megaco@ietf.org; Wed, 13 Aug 2003 02:18:32 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h7D6FFF29919; Wed, 13 Aug 2003 16:15:15 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.135]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYCP526L; Wed, 13 Aug 2003 16:17:47 +1000 Message-ID: <3F39D797.9000703@ericsson.com.au> Date: Wed, 13 Aug 2003 16:15:51 +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: petric john CC: Tegeler Juergen , megaco@ietf.org Subject: Re: [Megaco] new parameter "auditItem" of ServiceChange Descriptor in H.248.1 v2 References: <20030813044032.81688.qmail@web10701.mail.yahoo.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 Hello John, RFC3525 is H.248.1 Version 1. ServiceChangeInfo was introduced in H.248.1 Version 2. RFC3525 will not be updated. draft-ietf-megaco-h248v2-04.txt is a copy of H.248.1 Version 2. Hopefully this will become another RFC. Regards, Christian petric john wrote: > Hi, > Whats the relation between the various version of > megaco protocol floating around?? > > There is IETF's RFC-3525, then there is IETF's > draft-ietf-megaco-h248v2-04.txt and last there is > ITU-T-H248.1 Its really becoming confusing to keep > track of all of them. > > The following 'ServiceChangeInfo' parameter is not > defined in RFC3525. When it will be updated? > > /Pjohn. > > --- Christian Groves > wrote: > Hello > Juergen, > >>7.2.8 describes the parameter "ServiceChangeInfo". >>ie. ServiceChangeInfo >>parameter may contain the >>package/property/signal/event/statistic of the >>reason >>that caused the service change. >> >>auditItem is the text way of returning this >>information. >> >>Regards, Christian >> > > > > http://search.yahoo.com.au - Yahoo! Search > - Looking for more? Try the new Yahoo! Search > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Aug 13 14:31: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 OAA29575 for ; Wed, 13 Aug 2003 14:31:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n0Ok-0006HF-3z; Wed, 13 Aug 2003 14:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n0Oe-0006GR-UK for megaco@optimus.ietf.org; Wed, 13 Aug 2003 14:30:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29549 for ; Wed, 13 Aug 2003 14:30:51 -0400 (EDT) From: Dana.Herskowitz@veraznetworks.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n0Oc-0003v4-00 for megaco@ietf.org; Wed, 13 Aug 2003 14:30:54 -0400 Received: from mink.ecitele.com ([147.234.1.100]) by ietf-mx with esmtp (Exim 4.12) id 19n0Ob-0003uq-00 for megaco@ietf.org; Wed, 13 Aug 2003 14:30:53 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.12.8+Sun/8.12.8) with ESMTP id h7DIPW8j002491 for ; Wed, 13 Aug 2003 21:25:32 +0300 (IDT) To: megaco@ietf.org Cc: Eli.Liluz@veraznetworks.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Wed, 13 Aug 2003 21:31:16 +0300 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 08/13/2003 09:31:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] loopback mode and incoming continuity test Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, I have two questions: A) Are the following 2 commands cause the same operations eventually? (Is Loopback mode request is the same as Incoming COT request) (1) MEGACO/1 [1.1.1.1]:2427 Transaction = 777 {Context=$ {Add=Physical1 {Signals{ct/rsp}}}} (2) MEGACO/1 [1.1.1.1]:2427 Transaction=888 {Context=$ {Add=Physical1 {Media{LocalControl{Mode = Loopback}}}}} B) Is the following command valid in order to perform COT or should it include also a "ct" signal? If this command is enough for performing COT - what kind of COT is it - Incoming or Outgoing? MEGACO/1 [1.1.1.1]:2427 Transaction=999 {Context=$ {Modify =Physical1 {Media{TerminationState{State = Test}}}}} Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Aug 13 14:32:00 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 OAA29614 for ; Wed, 13 Aug 2003 14:31:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n0PG-0006Re-LQ for megaco-archive@odin.ietf.org; Wed, 13 Aug 2003 14:31:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DIVYNC024768 for megaco-archive@odin.ietf.org; Wed, 13 Aug 2003 14:31:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n0PG-0006RP-GQ for megaco-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 14:31:34 -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 OAA29576 for ; Wed, 13 Aug 2003 14:31: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 19n0Ok-0006HF-3z; Wed, 13 Aug 2003 14:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n0Oe-0006GR-UK for megaco@optimus.ietf.org; Wed, 13 Aug 2003 14:30:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29549 for ; Wed, 13 Aug 2003 14:30:51 -0400 (EDT) From: Dana.Herskowitz@veraznetworks.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n0Oc-0003v4-00 for megaco@ietf.org; Wed, 13 Aug 2003 14:30:54 -0400 Received: from mink.ecitele.com ([147.234.1.100]) by ietf-mx with esmtp (Exim 4.12) id 19n0Ob-0003uq-00 for megaco@ietf.org; Wed, 13 Aug 2003 14:30:53 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.12.8+Sun/8.12.8) with ESMTP id h7DIPW8j002491 for ; Wed, 13 Aug 2003 21:25:32 +0300 (IDT) To: megaco@ietf.org Cc: Eli.Liluz@veraznetworks.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Wed, 13 Aug 2003 21:31:16 +0300 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 08/13/2003 09:31:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] loopback mode and incoming continuity test Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, I have two questions: A) Are the following 2 commands cause the same operations eventually? (Is Loopback mode request is the same as Incoming COT request) (1) MEGACO/1 [1.1.1.1]:2427 Transaction = 777 {Context=$ {Add=Physical1 {Signals{ct/rsp}}}} (2) MEGACO/1 [1.1.1.1]:2427 Transaction=888 {Context=$ {Add=Physical1 {Media{LocalControl{Mode = Loopback}}}}} B) Is the following command valid in order to perform COT or should it include also a "ct" signal? If this command is enough for performing COT - what kind of COT is it - Incoming or Outgoing? MEGACO/1 [1.1.1.1]:2427 Transaction=999 {Context=$ {Modify =Physical1 {Media{TerminationState{State = Test}}}}} Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Aug 14 02:06: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 CAA24921 for ; Thu, 14 Aug 2003 02:06: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 19nBFL-0007nP-8f; Thu, 14 Aug 2003 02:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nBEM-0007hW-9b for megaco@optimus.ietf.org; Thu, 14 Aug 2003 02:05: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 CAA23364 for ; Thu, 14 Aug 2003 02:04:53 -0400 (EDT) From: Dana.Herskowitz@veraznetworks.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nBEE-0007iq-00 for megaco@ietf.org; Thu, 14 Aug 2003 02:04:54 -0400 Received: from mink.ecitele.com ([147.234.1.100]) by ietf-mx with esmtp (Exim 4.12) id 19nBED-0007in-00 for megaco@ietf.org; Thu, 14 Aug 2003 02:04:53 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.12.8+Sun/8.12.8) with ESMTP id h7E5xX8j019721 for ; Thu, 14 Aug 2003 08:59:33 +0300 (IDT) To: megaco@ietf.org Cc: Eli.Liluz@veraznetworks.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Thu, 14 Aug 2003 09:05:15 +0300 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 08/14/2003 09:05:09 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] continuity test Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, Does the following command, due to the absence of Loopback mode request, necessarily dictates generating a different frequency signal in the continuity test procedure? MEGACO/1 [1.2.3.4]:2427 Transaction=111 {Context=- {Modify =PhysTerm {Signals{ct/rsp}}}} Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Aug 14 02:06: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 CAA24964 for ; Thu, 14 Aug 2003 02:06: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 19nBFO-0007oQ-31 for megaco-archive@odin.ietf.org; Thu, 14 Aug 2003 02:06:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7E6668V030025 for megaco-archive@odin.ietf.org; Thu, 14 Aug 2003 02:06:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nBFN-0007oC-Kn for megaco-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 02:06: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 CAA24441 for ; Thu, 14 Aug 2003 02:06:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nBFK-0007jR-00 for megaco-web-archive@ietf.org; Thu, 14 Aug 2003 02:06:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nBFJ-0007jN-00 for megaco-web-archive@ietf.org; Thu, 14 Aug 2003 02:06:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nBFL-0007nP-8f; Thu, 14 Aug 2003 02:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nBEM-0007hW-9b for megaco@optimus.ietf.org; Thu, 14 Aug 2003 02:05: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 CAA23364 for ; Thu, 14 Aug 2003 02:04:53 -0400 (EDT) From: Dana.Herskowitz@veraznetworks.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nBEE-0007iq-00 for megaco@ietf.org; Thu, 14 Aug 2003 02:04:54 -0400 Received: from mink.ecitele.com ([147.234.1.100]) by ietf-mx with esmtp (Exim 4.12) id 19nBED-0007in-00 for megaco@ietf.org; Thu, 14 Aug 2003 02:04:53 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.12.8+Sun/8.12.8) with ESMTP id h7E5xX8j019721 for ; Thu, 14 Aug 2003 08:59:33 +0300 (IDT) To: megaco@ietf.org Cc: Eli.Liluz@veraznetworks.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Thu, 14 Aug 2003 09:05:15 +0300 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 08/14/2003 09:05:09 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] continuity test Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, Does the following command, due to the absence of Loopback mode request, necessarily dictates generating a different frequency signal in the continuity test procedure? MEGACO/1 [1.2.3.4]:2427 Transaction=111 {Context=- {Modify =PhysTerm {Signals{ct/rsp}}}} Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Aug 14 11:45:28 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 LAA15729 for ; Thu, 14 Aug 2003 11:45:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKHd-0000zY-V6; Thu, 14 Aug 2003 11:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKHK-0000z6-O1 for megaco@optimus.ietf.org; Thu, 14 Aug 2003 11:44: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 LAA15691 for ; Thu, 14 Aug 2003 11:44:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nKHJ-0003bv-00 for megaco@ietf.org; Thu, 14 Aug 2003 11:44:41 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19nKHI-0003bs-00 for megaco@ietf.org; Thu, 14 Aug 2003 11:44:40 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h7EFicUR010973; Thu, 14 Aug 2003 08:44:39 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h7EFiZBi000430; Thu, 14 Aug 2003 10:44:35 -0500 Message-Id: <5.2.1.1.0.20030814111122.0357d0e0@IL06EXM04.corp.mot.com> X-Sender: A19776@IL06EXM04.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 14 Aug 2003 11:39:17 -0400 To: , , From: Aleksandr Ryabin Subject: Re: [Megaco] loopback mode and incoming continuity test 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, Please see my comments below inline [AR]. Regards, Aleks At 02:31 PM 8/13/2003, Dana.Herskowitz@veraznetworks.com wrote: >Hello, >I have two questions: > >A) Are the following 2 commands cause the same operations eventually? >(Is Loopback mode request is the same as Incoming COT request) [AR] Physically might be in some cases, logically not. Please see RFC 3525 p 177 "E.10.5 Procedures" for more details. >(1) >MEGACO/1 [1.1.1.1]:2427 >Transaction = 777 {Context=$ {Add=Physical1 {Signals{ct/rsp}}}} > >(2) >MEGACO/1 [1.1.1.1]:2427 >Transaction=888 {Context=$ {Add=Physical1 {Media{LocalControl{Mode = >Loopback}}}}} > > > >B) Is the following command valid in order to perform COT or should it >include also a "ct" signal? If this command is enough for performing COT - >what kind of COT is it - Incoming or Outgoing? [AR] No, COT procedures are described in RFC section referenced above. MGC needs to apply ct/ct signal and request ct/cmp event for outgoing COT, and apply ct/rsp signal for incoming COT. [AR] Termination state "test" has nothing to do with COT tests. My understanding that termination state "test" means that some maintenance work is being performed on the termination itself and not on connection between termination and its peer entity (which COT does). >MEGACO/1 [1.1.1.1]:2427 >Transaction=999 {Context=$ {Modify =Physical1 {Media{TerminationState{State >= Test}}}}} > >Regards, >Dana H. > > > >_______________________________________________ >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 Aug 14 11:45: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 LAA15744 for ; Thu, 14 Aug 2003 11:45:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKHk-00010r-TY for megaco-archive@odin.ietf.org; Thu, 14 Aug 2003 11:45:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EFj8UO003889 for megaco-archive@odin.ietf.org; Thu, 14 Aug 2003 11:45:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKHk-00010e-QO for megaco-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 11:45: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 LAA15709 for ; Thu, 14 Aug 2003 11:44:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nKHe-0003c9-00 for megaco-web-archive@ietf.org; Thu, 14 Aug 2003 11:45:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nKHe-0003c6-00 for megaco-web-archive@ietf.org; Thu, 14 Aug 2003 11:45:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKHd-0000zY-V6; Thu, 14 Aug 2003 11:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKHK-0000z6-O1 for megaco@optimus.ietf.org; Thu, 14 Aug 2003 11:44: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 LAA15691 for ; Thu, 14 Aug 2003 11:44:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nKHJ-0003bv-00 for megaco@ietf.org; Thu, 14 Aug 2003 11:44:41 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19nKHI-0003bs-00 for megaco@ietf.org; Thu, 14 Aug 2003 11:44:40 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h7EFicUR010973; Thu, 14 Aug 2003 08:44:39 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h7EFiZBi000430; Thu, 14 Aug 2003 10:44:35 -0500 Message-Id: <5.2.1.1.0.20030814111122.0357d0e0@IL06EXM04.corp.mot.com> X-Sender: A19776@IL06EXM04.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 14 Aug 2003 11:39:17 -0400 To: , , From: Aleksandr Ryabin Subject: Re: [Megaco] loopback mode and incoming continuity test 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, Please see my comments below inline [AR]. Regards, Aleks At 02:31 PM 8/13/2003, Dana.Herskowitz@veraznetworks.com wrote: >Hello, >I have two questions: > >A) Are the following 2 commands cause the same operations eventually? >(Is Loopback mode request is the same as Incoming COT request) [AR] Physically might be in some cases, logically not. Please see RFC 3525 p 177 "E.10.5 Procedures" for more details. >(1) >MEGACO/1 [1.1.1.1]:2427 >Transaction = 777 {Context=$ {Add=Physical1 {Signals{ct/rsp}}}} > >(2) >MEGACO/1 [1.1.1.1]:2427 >Transaction=888 {Context=$ {Add=Physical1 {Media{LocalControl{Mode = >Loopback}}}}} > > > >B) Is the following command valid in order to perform COT or should it >include also a "ct" signal? If this command is enough for performing COT - >what kind of COT is it - Incoming or Outgoing? [AR] No, COT procedures are described in RFC section referenced above. MGC needs to apply ct/ct signal and request ct/cmp event for outgoing COT, and apply ct/rsp signal for incoming COT. [AR] Termination state "test" has nothing to do with COT tests. My understanding that termination state "test" means that some maintenance work is being performed on the termination itself and not on connection between termination and its peer entity (which COT does). >MEGACO/1 [1.1.1.1]:2427 >Transaction=999 {Context=$ {Modify =Physical1 {Media{TerminationState{State >= Test}}}}} > >Regards, >Dana H. > > > >_______________________________________________ >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 Aug 14 11:55:28 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 LAA16055 for ; Thu, 14 Aug 2003 11:55:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKRJ-0001Oe-Nf; Thu, 14 Aug 2003 11:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKQx-0001Nu-BY for megaco@optimus.ietf.org; Thu, 14 Aug 2003 11:54: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 LAA16037 for ; Thu, 14 Aug 2003 11:54:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nKQw-0003gW-00 for megaco@ietf.org; Thu, 14 Aug 2003 11:54:38 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19nKQv-0003gT-00 for megaco@ietf.org; Thu, 14 Aug 2003 11:54:37 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h7EFsXq5005648; Thu, 14 Aug 2003 08:54:37 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h7EFsUBi007540; Thu, 14 Aug 2003 10:54:30 -0500 Message-Id: <5.2.1.1.0.20030814113945.03606518@IL06EXM04.corp.mot.com> X-Sender: A19776@IL06EXM04.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 14 Aug 2003 11:48:52 -0400 To: , , From: Aleksandr Ryabin Subject: Re: [Megaco] continuity test 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, No. Specific COT type is provisioned in MG on termination. MGC should make no assumptions on type of COT is provisioned on MG. MGC should always send ct/rsp when it wants MG to respond to COT. Regards, Aleks At 02:05 AM 8/14/2003, Dana.Herskowitz@veraznetworks.com wrote: >Hello, >Does the following command, due to the absence of Loopback mode request, >necessarily dictates generating a different frequency signal in the >continuity test procedure? > > >MEGACO/1 [1.2.3.4]:2427 >Transaction=111 {Context=- {Modify =PhysTerm {Signals{ct/rsp}}}} > > >Regards, >Dana H. > > > >_______________________________________________ >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 Aug 14 11:55: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 LAA16070 for ; Thu, 14 Aug 2003 11:55: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 19nKRL-0001Pa-JW for megaco-archive@odin.ietf.org; Thu, 14 Aug 2003 11:55:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EFt3MW005420 for megaco-archive@odin.ietf.org; Thu, 14 Aug 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 19nKRL-0001PL-Cx for megaco-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 11:55: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 LAA16045 for ; Thu, 14 Aug 2003 11:54:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nKRK-0003gj-00 for megaco-web-archive@ietf.org; Thu, 14 Aug 2003 11:55:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nKRJ-0003gg-00 for megaco-web-archive@ietf.org; Thu, 14 Aug 2003 11:55:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKRJ-0001Oe-Nf; Thu, 14 Aug 2003 11:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKQx-0001Nu-BY for megaco@optimus.ietf.org; Thu, 14 Aug 2003 11:54: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 LAA16037 for ; Thu, 14 Aug 2003 11:54:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nKQw-0003gW-00 for megaco@ietf.org; Thu, 14 Aug 2003 11:54:38 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19nKQv-0003gT-00 for megaco@ietf.org; Thu, 14 Aug 2003 11:54:37 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h7EFsXq5005648; Thu, 14 Aug 2003 08:54:37 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h7EFsUBi007540; Thu, 14 Aug 2003 10:54:30 -0500 Message-Id: <5.2.1.1.0.20030814113945.03606518@IL06EXM04.corp.mot.com> X-Sender: A19776@IL06EXM04.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 14 Aug 2003 11:48:52 -0400 To: , , From: Aleksandr Ryabin Subject: Re: [Megaco] continuity test 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, No. Specific COT type is provisioned in MG on termination. MGC should make no assumptions on type of COT is provisioned on MG. MGC should always send ct/rsp when it wants MG to respond to COT. Regards, Aleks At 02:05 AM 8/14/2003, Dana.Herskowitz@veraznetworks.com wrote: >Hello, >Does the following command, due to the absence of Loopback mode request, >necessarily dictates generating a different frequency signal in the >continuity test procedure? > > >MEGACO/1 [1.2.3.4]:2427 >Transaction=111 {Context=- {Modify =PhysTerm {Signals{ct/rsp}}}} > > >Regards, >Dana H. > > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Sun Aug 17 06:29:27 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 GAA10730 for ; Sun, 17 Aug 2003 06:29:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oKmS-0005Z8-UE; Sun, 17 Aug 2003 06:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oKmQ-0005Yv-TW for megaco@optimus.ietf.org; Sun, 17 Aug 2003 06:28: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 GAA10719 for ; Sun, 17 Aug 2003 06:28:52 -0400 (EDT) From: Dana.Herskowitz@veraznetworks.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oKmN-0007aT-00 for megaco@ietf.org; Sun, 17 Aug 2003 06:28:55 -0400 Received: from mink.ecitele.com ([147.234.1.100]) by ietf-mx with esmtp (Exim 4.12) id 19oKmL-0007aJ-00 for megaco@ietf.org; Sun, 17 Aug 2003 06:28:54 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.12.8+Sun/8.12.8) with ESMTP id h7HANX8l029363; Sun, 17 Aug 2003 13:23:33 +0300 (IDT) Subject: Re: [Megaco] continuity test To: Aleksandr Ryabin Cc: Eli.Liluz@veraznetworks.com, megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Sun, 17 Aug 2003 13:29:03 +0300 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 08/17/2003 01:28:57 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Thank you for replying. I'll refer in this e-mail to the H.248 call flow examples document by Madhubabu Brahmanapally from March 2002. From example 2.12, case (b) : Step 1 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1234 { Context = '-' { Modify = Trunk1/line1 {Media { TerminationState {ServiceState = test} LocalControl { mode = loopback} } Signals = { ct/rsp } } } } There can be two possible cases for responding to the continuity test originated from the PSTN network. In the first case the Trunking Gateway generates a signal whose frequency is different from the frequency of the received signal and in the second case it loops back the received signal to the switch that originated it. In this example we assume the case of Loopback. The mode of the termination is also set to loopback to facilitate this. From these sentences I understand that the MGC may request for responding with signal looped back, and from your response to my former question, I understand that the MG does not have to respect the MGC Loopback mode request as the COT signal is provisioned by the MG itself. Am I right? Dana H. Aleksandr Ryabin , , com> cc: 14/08/03 18:48 Subject: Re: [Megaco] continuity test Hi, No. Specific COT type is provisioned in MG on termination. MGC should make no assumptions on type of COT is provisioned on MG. MGC should always send ct/rsp when it wants MG to respond to COT. Regards, Aleks At 02:05 AM 8/14/2003, Dana.Herskowitz@veraznetworks.com wrote: >Hello, >Does the following command, due to the absence of Loopback mode request, >necessarily dictates generating a different frequency signal in the >continuity test procedure? > > >MEGACO/1 [1.2.3.4]:2427 >Transaction=111 {Context=- {Modify =PhysTerm {Signals{ct/rsp}}}} > > >Regards, >Dana H. > > > >_______________________________________________ >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 Sun Aug 17 06:29: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 GAA10745 for ; Sun, 17 Aug 2003 06:29: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 19oKmX-0005Zq-Dc for megaco-archive@odin.ietf.org; Sun, 17 Aug 2003 06:29:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7HAT5Sl021439 for megaco-archive@odin.ietf.org; Sun, 17 Aug 2003 06:29:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oKmX-0005Zi-8D for megaco-web-archive@optimus.ietf.org; Sun, 17 Aug 2003 06:29: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 GAA10725 for ; Sun, 17 Aug 2003 06:28:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oKmT-0007aa-00 for megaco-web-archive@ietf.org; Sun, 17 Aug 2003 06:29:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oKmS-0007aW-00 for megaco-web-archive@ietf.org; Sun, 17 Aug 2003 06:29:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oKmS-0005Z8-UE; Sun, 17 Aug 2003 06:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oKmQ-0005Yv-TW for megaco@optimus.ietf.org; Sun, 17 Aug 2003 06:28: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 GAA10719 for ; Sun, 17 Aug 2003 06:28:52 -0400 (EDT) From: Dana.Herskowitz@veraznetworks.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oKmN-0007aT-00 for megaco@ietf.org; Sun, 17 Aug 2003 06:28:55 -0400 Received: from mink.ecitele.com ([147.234.1.100]) by ietf-mx with esmtp (Exim 4.12) id 19oKmL-0007aJ-00 for megaco@ietf.org; Sun, 17 Aug 2003 06:28:54 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.12.8+Sun/8.12.8) with ESMTP id h7HANX8l029363; Sun, 17 Aug 2003 13:23:33 +0300 (IDT) Subject: Re: [Megaco] continuity test To: Aleksandr Ryabin Cc: Eli.Liluz@veraznetworks.com, megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Sun, 17 Aug 2003 13:29:03 +0300 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 08/17/2003 01:28:57 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Thank you for replying. I'll refer in this e-mail to the H.248 call flow examples document by Madhubabu Brahmanapally from March 2002. From example 2.12, case (b) : Step 1 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1234 { Context = '-' { Modify = Trunk1/line1 {Media { TerminationState {ServiceState = test} LocalControl { mode = loopback} } Signals = { ct/rsp } } } } There can be two possible cases for responding to the continuity test originated from the PSTN network. In the first case the Trunking Gateway generates a signal whose frequency is different from the frequency of the received signal and in the second case it loops back the received signal to the switch that originated it. In this example we assume the case of Loopback. The mode of the termination is also set to loopback to facilitate this. From these sentences I understand that the MGC may request for responding with signal looped back, and from your response to my former question, I understand that the MG does not have to respect the MGC Loopback mode request as the COT signal is provisioned by the MG itself. Am I right? Dana H. Aleksandr Ryabin , , com> cc: 14/08/03 18:48 Subject: Re: [Megaco] continuity test Hi, No. Specific COT type is provisioned in MG on termination. MGC should make no assumptions on type of COT is provisioned on MG. MGC should always send ct/rsp when it wants MG to respond to COT. Regards, Aleks At 02:05 AM 8/14/2003, Dana.Herskowitz@veraznetworks.com wrote: >Hello, >Does the following command, due to the absence of Loopback mode request, >necessarily dictates generating a different frequency signal in the >continuity test procedure? > > >MEGACO/1 [1.2.3.4]:2427 >Transaction=111 {Context=- {Modify =PhysTerm {Signals{ct/rsp}}}} > > >Regards, >Dana H. > > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Sun Aug 17 10:52:27 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 KAA15057 for ; Sun, 17 Aug 2003 10:52:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oOt0-0003bt-5f; Sun, 17 Aug 2003 10:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oOsD-0003bX-Qz for megaco@optimus.ietf.org; Sun, 17 Aug 2003 10:51: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 KAA15048 for ; Sun, 17 Aug 2003 10:51:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oOsB-0000up-00 for megaco@ietf.org; Sun, 17 Aug 2003 10:51:11 -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 19oOsA-0000um-00 for megaco@ietf.org; Sun, 17 Aug 2003 10:51:10 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 17 Aug 2003 07:50:40 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7HEocLH010369; Sun, 17 Aug 2003 07:50:38 -0700 (PDT) Received: from dea-w2k.cisco.com (sjc-vpn4-382.cisco.com [10.21.81.126]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKL67332; Sun, 17 Aug 2003 07:43:02 -0700 (PDT) Message-Id: <4.3.2.7.2.20030817072720.0484f7a0@mira-sjc5-b.cisco.com> X-Sender: dea@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 17 Aug 2003 07:50:37 -0700 To: Dana.Herskowitz@veraznetworks.com From: David Auerbach Subject: Re: [Megaco] continuity test Cc: 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: , Dana, I believe that the call flow examples in this case are not a good example. I had an email discussion with one of the authors and asked that this be changed. I was under the impression that it would be modified in a future draft of the document. It contradicts (or confuses) RFC 3525 (H.248.1) and I believe the RFC should have priority over a draft document. The comments by Aleksandr in a previous response seem correct. E.10 provides a simple way to provide COT regardless of whether the test is a loopback or dual tone test. Technically, using the mode loopback for that mode of test would give the same result but using loopback for dual tone is contradictory and inconsistent. You certainly do not want a loopback in that case. Why use the mode? Just use E.10. I also agree with Aleksandr that the termination state, servicestate should not be "test" but E.10 is silent on the service state value to use. I would hope that media gateways do not enforce a specific servicestate by returning an error. Best regards, David At 13:29 17/08/2003 +0300, Dana.Herskowitz@veraznetworks.com wrote: >Thank you for replying. >I'll refer in this e-mail to the H.248 call flow examples document by >Madhubabu Brahmanapally from March 2002. > From example 2.12, case (b) : > >Step 1 >MGC to TGW: >MEGACO/1 [216.33.33.61]: 27000 > Transaction = 1234 { > Context = '-' { > Modify = Trunk1/line1 {Media { > TerminationState {ServiceState = test} > LocalControl { mode = loopback} } > Signals = { ct/rsp } > } > } > } > >There can be two possible cases for responding to the continuity test >originated from the PSTN network. In the first case the Trunking Gateway >generates a signal whose frequency is different from the frequency of the >received signal and in the second case it loops back the received signal >to the switch that originated it. In this example we assume the case of >Loopback. The mode of the termination is also set to loopback to facilitate >this. > > > From these sentences I understand that the MGC may request for responding >with signal looped back, and from your response to my former question, I >understand that the MG does not have to respect the MGC Loopback mode >request as the COT signal is provisioned by the MG itself. Am I right? > > >Dana H. > > > > > > Aleksandr > Ryabin > > , , > com> > > > cc: > > 14/08/03 18:48 Subject: Re: [Megaco] > continuity test > > > > > > > >Hi, > >No. Specific COT type is provisioned in MG on termination. >MGC should make no assumptions on type of COT is provisioned on MG. >MGC should always send ct/rsp when it wants MG to respond to COT. > >Regards, > Aleks > >At 02:05 AM 8/14/2003, Dana.Herskowitz@veraznetworks.com wrote: > >Hello, > >Does the following command, due to the absence of Loopback mode request, > >necessarily dictates generating a different frequency signal in the > >continuity test procedure? > > > > > >MEGACO/1 [1.2.3.4]:2427 > >Transaction=111 {Context=- {Modify =PhysTerm {Signals{ct/rsp}}}} > > > > > >Regards, > >Dana H. > > > > > > > >_______________________________________________ > >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 Sun Aug 17 10:52: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 KAA15072 for ; Sun, 17 Aug 2003 10:52: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 19oOt2-0003cc-S0 for megaco-archive@odin.ietf.org; Sun, 17 Aug 2003 10:52:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7HEq4ZE013922 for megaco-archive@odin.ietf.org; Sun, 17 Aug 2003 10:52:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oOt2-0003cT-Mm for megaco-web-archive@optimus.ietf.org; Sun, 17 Aug 2003 10:52: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 KAA15052 for ; Sun, 17 Aug 2003 10:51:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oOt0-0000uv-00 for megaco-web-archive@ietf.org; Sun, 17 Aug 2003 10:52:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oOsz-0000us-00 for megaco-web-archive@ietf.org; Sun, 17 Aug 2003 10:52:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oOt0-0003bt-5f; Sun, 17 Aug 2003 10:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oOsD-0003bX-Qz for megaco@optimus.ietf.org; Sun, 17 Aug 2003 10:51: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 KAA15048 for ; Sun, 17 Aug 2003 10:51:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oOsB-0000up-00 for megaco@ietf.org; Sun, 17 Aug 2003 10:51:11 -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 19oOsA-0000um-00 for megaco@ietf.org; Sun, 17 Aug 2003 10:51:10 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 17 Aug 2003 07:50:40 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7HEocLH010369; Sun, 17 Aug 2003 07:50:38 -0700 (PDT) Received: from dea-w2k.cisco.com (sjc-vpn4-382.cisco.com [10.21.81.126]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKL67332; Sun, 17 Aug 2003 07:43:02 -0700 (PDT) Message-Id: <4.3.2.7.2.20030817072720.0484f7a0@mira-sjc5-b.cisco.com> X-Sender: dea@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 17 Aug 2003 07:50:37 -0700 To: Dana.Herskowitz@veraznetworks.com From: David Auerbach Subject: Re: [Megaco] continuity test Cc: 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: , Dana, I believe that the call flow examples in this case are not a good example. I had an email discussion with one of the authors and asked that this be changed. I was under the impression that it would be modified in a future draft of the document. It contradicts (or confuses) RFC 3525 (H.248.1) and I believe the RFC should have priority over a draft document. The comments by Aleksandr in a previous response seem correct. E.10 provides a simple way to provide COT regardless of whether the test is a loopback or dual tone test. Technically, using the mode loopback for that mode of test would give the same result but using loopback for dual tone is contradictory and inconsistent. You certainly do not want a loopback in that case. Why use the mode? Just use E.10. I also agree with Aleksandr that the termination state, servicestate should not be "test" but E.10 is silent on the service state value to use. I would hope that media gateways do not enforce a specific servicestate by returning an error. Best regards, David At 13:29 17/08/2003 +0300, Dana.Herskowitz@veraznetworks.com wrote: >Thank you for replying. >I'll refer in this e-mail to the H.248 call flow examples document by >Madhubabu Brahmanapally from March 2002. > From example 2.12, case (b) : > >Step 1 >MGC to TGW: >MEGACO/1 [216.33.33.61]: 27000 > Transaction = 1234 { > Context = '-' { > Modify = Trunk1/line1 {Media { > TerminationState {ServiceState = test} > LocalControl { mode = loopback} } > Signals = { ct/rsp } > } > } > } > >There can be two possible cases for responding to the continuity test >originated from the PSTN network. In the first case the Trunking Gateway >generates a signal whose frequency is different from the frequency of the >received signal and in the second case it loops back the received signal >to the switch that originated it. In this example we assume the case of >Loopback. The mode of the termination is also set to loopback to facilitate >this. > > > From these sentences I understand that the MGC may request for responding >with signal looped back, and from your response to my former question, I >understand that the MG does not have to respect the MGC Loopback mode >request as the COT signal is provisioned by the MG itself. Am I right? > > >Dana H. > > > > > > Aleksandr > Ryabin > > , , > com> > > > cc: > > 14/08/03 18:48 Subject: Re: [Megaco] > continuity test > > > > > > > >Hi, > >No. Specific COT type is provisioned in MG on termination. >MGC should make no assumptions on type of COT is provisioned on MG. >MGC should always send ct/rsp when it wants MG to respond to COT. > >Regards, > Aleks > >At 02:05 AM 8/14/2003, Dana.Herskowitz@veraznetworks.com wrote: > >Hello, > >Does the following command, due to the absence of Loopback mode request, > >necessarily dictates generating a different frequency signal in the > >continuity test procedure? > > > > > >MEGACO/1 [1.2.3.4]:2427 > >Transaction=111 {Context=- {Modify =PhysTerm {Signals{ct/rsp}}}} > > > > > >Regards, > >Dana H. > > > > > > > >_______________________________________________ > >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 Aug 26 16:04:17 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 QAA03423 for ; Tue, 26 Aug 2003 16:04:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rk2f-0004l3-HZ; Tue, 26 Aug 2003 16:03:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rTYp-0000Y8-BX for megaco@optimus.ietf.org; Mon, 25 Aug 2003 22:27: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 WAA28075 for ; Mon, 25 Aug 2003 22:27:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rTYm-0002UZ-00 for megaco@ietf.org; Mon, 25 Aug 2003 22:27:52 -0400 Received: from [208.165.63.45] (helo=spemen02.ice.go.cr) by ietf-mx with esmtp (Exim 4.12) id 19rTYl-0002UC-00 for megaco@ietf.org; Mon, 25 Aug 2003 22:27:51 -0400 Received: by spemen02 with Internet Mail Service (5.5.2655.55) id ; Mon, 25 Aug 2003 20:26:42 -0600 Message-ID: <7F5A8CBE73BCDA48A9CCF5BBB972797B116B46@sabmen04.red.ice> From: Solano Arias Randall To: "'megaco@ietf.org'" Date: Mon, 25 Aug 2003 20:26:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36B79.0AD264E2" Subject: [Megaco] Request_MEGACO/H248 variants Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C36B79.0AD264E2 Content-Type: text/plain Hi There; First, I have one request for you, because I am working in one project about NGN and I want to implement new protocol like MEGACO/H.248 for control and signalling. My specify request is about if i must to do one version of H.248 for my country, this questions is because our PSTN have signalling protocol SS7 with one variants called country version. And if MEGACO too need one version of each country. I hope soon to hear of you. Cheers, ------_=_NextPart_001_01C36B79.0AD264E2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hi There;

 

 

Fir= st, I have one request for you, because I am working in one project about = NGN and I want to implement new protocol like MEGACO/H.248 for control and = signalling.

 

My specify request is about if i must to do one version of H.248 for my country, this = questions is because our PSTN have signalling protocol SS7 with one variants called = country = version.

 

And if MEGACO too need one version of each = country.

 

I hope soon to hear of you.

 

Che= ers,

 

 

 

------_=_NextPart_001_01C36B79.0AD264E2-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Aug 26 23:32: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 XAA13010 for ; Tue, 26 Aug 2003 23:32: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 19rmpo-0005Nx-1x; Tue, 26 Aug 2003 19:02:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19reSu-00047c-BC for megaco@optimus.ietf.org; Tue, 26 Aug 2003 10:06: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 KAA05025 for ; Tue, 26 Aug 2003 10:06:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19reSr-0000z0-00 for megaco@ietf.org; Tue, 26 Aug 2003 10:06:30 -0400 Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 19reSq-0000yA-00 for megaco@ietf.org; Tue, 26 Aug 2003 10:06:28 -0400 Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay2.alcatel.de (8.12.9/8.12.9) with ESMTP id h7QE35J5024113 for ; Tue, 26 Aug 2003 16:03:05 +0200 (MET DST) Received: from slssiw ([149.204.245.113] helo=slsdtk.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 19reSK-0000Bp-00; Tue, 26 Aug 2003 16:05:56 +0200 Received: from slsufnt ([149.204.245.33] helo=alcatel.de) by slsdtk.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 19reSK-0000Qs-00; Tue, 26 Aug 2003 16:05:56 +0200 Message-ID: <3F4B6AF9.BAE5D182@alcatel.de> Date: Tue, 26 Aug 2003 16:13:13 +0200 From: Gunter Weiss Organization: Alcatel SEL AG X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh-CN,zh MIME-Version: 1.0 To: "'megaco@ietf.org'" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Alcanet-virus-scanned: h7QE35J5024113 at mailrelay2.alcatel.de Content-Transfer-Encoding: 7bit Subject: [Megaco] Question concerning Dynamic Payload Type negotiation/configuration Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 have some basic questions on Dynamic PT negotiation within H.248/SDP: ----------------------------------------------------------------------- How is it considered in a H.248 controlled network to negotiate the Dynamic Payload type (used for DTMF relay a'la RFC2833) between the two ends (Media Gateways) via the MGC. In detail I'm interested to know, how will the first ADD request from the MGC to the originating Gateway look like? 1.1 Will the MGC already send a dynamic payload in the session description of the first Add request from MGC towards the Gateway? e.g.: MGC >> MG: m=audio $ RTP/AVP 8 96 a=rtpmap:96 telephone-event/8000 MG >> MGC: m=audio 10036 RTP/AVP 8 96 a=rtpmap:96 telephone-event/8000 1.1.1: What will be if the Gateway has another default PT for let's say DTMF relay? Can it responsen than in the following way: MG >> MGC: m=audio 10036 RTP/AVP 8 97 a=rtpmap:97 telephone-event/8000 Or is it considered that the GW can always adapt the PT?? 1.2 If the MGC will send already two PTs in the m line , will there be the ReserveValue set to true or is in this case the ReserveValue not considered at all as the Dynamic PT is a further specification, what the resource should be able to handle? MGC >> MG: MEGACO/1.0 [123.123.123.4]:55555 Transaction = 11 { Context = $ { Add = DS0/1/1 Add = $ { Media { LocalControl{ Mode = ReceiveOnly, ReserveValue = true}; Local{ v=0 c=IN IP4 $ m=audio $ RTP/AVP 8 96 a=rtpmap:96 telephone-event/8000 } }}}} 1.3 Or is it not sent in the request from the MGC, but sent in the response from the MG to the MGC? e.g. MGC >> MG: m=audio $ RTP/AVP 8 MG >> MGC: m=audio 10036 RTP/AVP 8 96 a=rtpmap:96 telephone-event/8000 or another possible way to report the capabilities: e.g.: MGC >> MG: m=audio $ RTP/AVP 8 MG >> MGC: m=audio 3456 RTP/AVP 8 a=sqn: 0 a=cdsc: 1 audio RTP/AVP 8 96 a=cpar: a=rtpmap:96 telephone-event/8000 If there are already scenarios on this topic please point me to it! Thanks in advance, Gunter! -- Gunter Weiss, VS/NGE, VND +--------V--------+ Competance Area Leader - Gateway Protocols | A L C A T E L | callto: +49-711-821-41613 faxto : .-40247 +-----------------+ mailto:G.Weiss@alcatel.de _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Aug 27 02:56: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 CAA28586 for ; Wed, 27 Aug 2003 02:56:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rtdI-0002H7-Lq for megaco-archive@odin.ietf.org; Wed, 27 Aug 2003 02:18:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R6IEOl008706 for megaco-archive@odin.ietf.org; Wed, 27 Aug 2003 02:18:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rr2U-0000sh-QT for megaco-web-archive@optimus.ietf.org; Tue, 26 Aug 2003 23:32: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 XAA12947 for ; Tue, 26 Aug 2003 23:32:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rr2S-0002bz-00 for megaco-web-archive@ietf.org; Tue, 26 Aug 2003 23:32:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rr2R-0002bw-00 for megaco-web-archive@ietf.org; Tue, 26 Aug 2003 23:32:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmpo-0005Nx-1x; Tue, 26 Aug 2003 19:02:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19reSu-00047c-BC for megaco@optimus.ietf.org; Tue, 26 Aug 2003 10:06: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 KAA05025 for ; Tue, 26 Aug 2003 10:06:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19reSr-0000z0-00 for megaco@ietf.org; Tue, 26 Aug 2003 10:06:30 -0400 Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 19reSq-0000yA-00 for megaco@ietf.org; Tue, 26 Aug 2003 10:06:28 -0400 Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay2.alcatel.de (8.12.9/8.12.9) with ESMTP id h7QE35J5024113 for ; Tue, 26 Aug 2003 16:03:05 +0200 (MET DST) Received: from slssiw ([149.204.245.113] helo=slsdtk.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 19reSK-0000Bp-00; Tue, 26 Aug 2003 16:05:56 +0200 Received: from slsufnt ([149.204.245.33] helo=alcatel.de) by slsdtk.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 19reSK-0000Qs-00; Tue, 26 Aug 2003 16:05:56 +0200 Message-ID: <3F4B6AF9.BAE5D182@alcatel.de> Date: Tue, 26 Aug 2003 16:13:13 +0200 From: Gunter Weiss Organization: Alcatel SEL AG X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh-CN,zh MIME-Version: 1.0 To: "'megaco@ietf.org'" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Alcanet-virus-scanned: h7QE35J5024113 at mailrelay2.alcatel.de Content-Transfer-Encoding: 7bit Subject: [Megaco] Question concerning Dynamic Payload Type negotiation/configuration Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 have some basic questions on Dynamic PT negotiation within H.248/SDP: ----------------------------------------------------------------------- How is it considered in a H.248 controlled network to negotiate the Dynamic Payload type (used for DTMF relay a'la RFC2833) between the two ends (Media Gateways) via the MGC. In detail I'm interested to know, how will the first ADD request from the MGC to the originating Gateway look like? 1.1 Will the MGC already send a dynamic payload in the session description of the first Add request from MGC towards the Gateway? e.g.: MGC >> MG: m=audio $ RTP/AVP 8 96 a=rtpmap:96 telephone-event/8000 MG >> MGC: m=audio 10036 RTP/AVP 8 96 a=rtpmap:96 telephone-event/8000 1.1.1: What will be if the Gateway has another default PT for let's say DTMF relay? Can it responsen than in the following way: MG >> MGC: m=audio 10036 RTP/AVP 8 97 a=rtpmap:97 telephone-event/8000 Or is it considered that the GW can always adapt the PT?? 1.2 If the MGC will send already two PTs in the m line , will there be the ReserveValue set to true or is in this case the ReserveValue not considered at all as the Dynamic PT is a further specification, what the resource should be able to handle? MGC >> MG: MEGACO/1.0 [123.123.123.4]:55555 Transaction = 11 { Context = $ { Add = DS0/1/1 Add = $ { Media { LocalControl{ Mode = ReceiveOnly, ReserveValue = true}; Local{ v=0 c=IN IP4 $ m=audio $ RTP/AVP 8 96 a=rtpmap:96 telephone-event/8000 } }}}} 1.3 Or is it not sent in the request from the MGC, but sent in the response from the MG to the MGC? e.g. MGC >> MG: m=audio $ RTP/AVP 8 MG >> MGC: m=audio 10036 RTP/AVP 8 96 a=rtpmap:96 telephone-event/8000 or another possible way to report the capabilities: e.g.: MGC >> MG: m=audio $ RTP/AVP 8 MG >> MGC: m=audio 3456 RTP/AVP 8 a=sqn: 0 a=cdsc: 1 audio RTP/AVP 8 96 a=cpar: a=rtpmap:96 telephone-event/8000 If there are already scenarios on this topic please point me to it! Thanks in advance, Gunter! -- Gunter Weiss, VS/NGE, VND +--------V--------+ Competance Area Leader - Gateway Protocols | A L C A T E L | callto: +49-711-821-41613 faxto : .-40247 +-----------------+ mailto:G.Weiss@alcatel.de _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Aug 27 20:31:59 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 UAA22653 for ; Wed, 27 Aug 2003 20:31:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5Qv-0002cF-Bo; Wed, 27 Aug 2003 14:54:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2EM-0007SP-Jr for megaco@optimus.ietf.org; Wed, 27 Aug 2003 11:29: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 LAA08986 for ; Wed, 27 Aug 2003 11:29:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s2EL-00012r-00 for megaco@ietf.org; Wed, 27 Aug 2003 11:29:05 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19s2EK-00012m-00 for megaco@ietf.org; Wed, 27 Aug 2003 11:29:04 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h7RFT3fs004860 for ; Wed, 27 Aug 2003 08:29:03 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h7RFT0LS013955 for ; Wed, 27 Aug 2003 10:29:01 -0500 Message-Id: <5.2.1.1.0.20030827111250.00a9c130@IL06EXM04.corp.mot.com> X-Sender: A19776@IL06EXM04.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 27 Aug 2003 11:28:00 -0400 To: megaco@ietf.org From: Aleksandr Ryabin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Megaco] ICAS and ICASC packages state Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, Can someone please update the list if there were any changes to ICAS/ICASC docs since SG-16 Geneva meeting in May 2003? Also the meeting docs public site seem to be unaccessible: http://standard.pictel.com/ftp/avc-site/0305_Gen/ Does anyone have any idea what's wrong? Is there an alternative public web site? Thanks Aleks _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Aug 28 00:33:22 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 AAA14955 for ; Thu, 28 Aug 2003 00:33:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCFu-0008UJ-Ft; Wed, 27 Aug 2003 22:11:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sAvI-0002iQ-6y for megaco@optimus.ietf.org; Wed, 27 Aug 2003 20:46: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 UAA23727 for ; Wed, 27 Aug 2003 20:45:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sAvF-0004ML-00 for megaco@ietf.org; Wed, 27 Aug 2003 20:45:57 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19sAvE-0004Lw-00 for megaco@ietf.org; Wed, 27 Aug 2003 20:45:56 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h7S0gkF12450; Thu, 28 Aug 2003 10:42:46 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.222]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYCQC9WK; Thu, 28 Aug 2003 10:44:53 +1000 Message-ID: <3F4D5035.2070004@ericsson.com.au> Date: Thu, 28 Aug 2003 10:43:33 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryabin Aleksandr-A19776 CC: megaco@ietf.org Subject: Re: [Megaco] ICAS and ICASC packages state 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's up to the editor Kevin Boyle. Usually documents are uploaded 5 working days before the meeting. Editors however are allowed to be more flexible. Christian Ryabin Aleksandr-A19776 wrote: > Hi Christian, > > I see Updated Draft H.248.icas (AVD-2353), but > Updated Draft H.248.icasc (AVD-2354) seem to be missing. > Any idea when is it going to be uploaded? > > Thanks > Aleks > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] > Sent: Wednesday, August 27, 2003 8:16 PM > To: Aleksandr Ryabin > Cc: megaco@ietf.org > Subject: Re: [Megaco] ICAS and ICASC packages state > > > Hello Aleksandr, > > The AVC site has moved to: > http://ftp3.itu.int/av-arch/avc-site/ > > As q.3 rapporteur i'll send out the list of H.248 contributions shortly. > > Regards, Christian > > Aleksandr Ryabin wrote: > > >>Hi, >> >>Can someone please update the list if there were any changes to >>ICAS/ICASC docs since SG-16 Geneva meeting in May 2003? >> >>Also the meeting docs public site seem to be unaccessible: >>http://standard.pictel.com/ftp/avc-site/0305_Gen/ >>Does anyone have any idea what's wrong? >>Is there an alternative public web site? >> >>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 Thu Aug 28 00:38:09 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 AAA15339 for ; Thu, 28 Aug 2003 00:38:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDGU-0005Wp-Ju; Wed, 27 Aug 2003 23:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sArY-0002WN-7B for megaco@optimus.ietf.org; Wed, 27 Aug 2003 20:42: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 UAA23504 for ; Wed, 27 Aug 2003 20:42:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sArV-0004IJ-00 for megaco@ietf.org; Wed, 27 Aug 2003 20:42:05 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19sArU-0004IG-00 for megaco@ietf.org; Wed, 27 Aug 2003 20:42:04 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h7S0g20T004724 for ; Wed, 27 Aug 2003 17:42:03 -0700 (MST) Received: from il06exm05.corp.mot.com (il06exm05.corp.mot.com [10.0.111.5]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h7S0g0LR007771 for ; Wed, 27 Aug 2003 19:42:00 -0500 Received: by il06exm05.corp.mot.com with Internet Mail Service (5.5.2657.2) id ; Wed, 27 Aug 2003 19:42:02 -0500 Message-ID: From: Ryabin Aleksandr-A19776 To: "'Christian Groves'" Cc: megaco@ietf.org Subject: RE: [Megaco] ICAS and ICASC packages state Date: Wed, 27 Aug 2003 19:42:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, I see Updated Draft H.248.icas (AVD-2353), but Updated Draft H.248.icasc (AVD-2354) seem to be missing. Any idea when is it going to be uploaded? Thanks Aleks -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] Sent: Wednesday, August 27, 2003 8:16 PM To: Aleksandr Ryabin Cc: megaco@ietf.org Subject: Re: [Megaco] ICAS and ICASC packages state Hello Aleksandr, The AVC site has moved to: http://ftp3.itu.int/av-arch/avc-site/ As q.3 rapporteur i'll send out the list of H.248 contributions shortly. Regards, Christian Aleksandr Ryabin wrote: > Hi, > > Can someone please update the list if there were any changes to > ICAS/ICASC docs since SG-16 Geneva meeting in May 2003? > > Also the meeting docs public site seem to be unaccessible: > http://standard.pictel.com/ftp/avc-site/0305_Gen/ > Does anyone have any idea what's wrong? > Is there an alternative public web site? > > 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 Thu Aug 28 00:44: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 AAA15916 for ; Thu, 28 Aug 2003 00:44:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCSR-00012y-Gl; Wed, 27 Aug 2003 22:24:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sAUb-0000x7-Ne for megaco@optimus.ietf.org; Wed, 27 Aug 2003 20:18: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 UAA21801 for ; Wed, 27 Aug 2003 20:18:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sAUZ-0003pp-00 for megaco@ietf.org; Wed, 27 Aug 2003 20:18:23 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19sAUY-0003pX-00 for megaco@ietf.org; Wed, 27 Aug 2003 20:18:22 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h7S0FAF08792; Thu, 28 Aug 2003 10:15:10 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.222]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYCQC85T; Thu, 28 Aug 2003 10:17:18 +1000 Message-ID: <3F4D49BD.30102@ericsson.com.au> Date: Thu, 28 Aug 2003 10:15:57 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aleksandr Ryabin CC: megaco@ietf.org Subject: Re: [Megaco] ICAS and ICASC packages state References: <5.2.1.1.0.20030827111250.00a9c130@IL06EXM04.corp.mot.com> In-Reply-To: <5.2.1.1.0.20030827111250.00a9c130@IL06EXM04.corp.mot.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 Hello Aleksandr, The AVC site has moved to: http://ftp3.itu.int/av-arch/avc-site/ As q.3 rapporteur i'll send out the list of H.248 contributions shortly. Regards, Christian Aleksandr Ryabin wrote: > Hi, > > Can someone please update the list if there were any changes to > ICAS/ICASC docs since SG-16 Geneva meeting in May 2003? > > Also the meeting docs public site seem to be unaccessible: > http://standard.pictel.com/ftp/avc-site/0305_Gen/ > Does anyone have any idea what's wrong? > Is there an alternative public web site? > > 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 exim@www1.ietf.org Thu Aug 28 02:12:17 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 CAA04534 for ; Thu, 28 Aug 2003 02:12:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCP4-0000jY-Ek for megaco-archive@odin.ietf.org; Wed, 27 Aug 2003 22:20:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S2KoJC002816 for megaco-archive@odin.ietf.org; Wed, 27 Aug 2003 22:20:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sAhK-0001VA-Lg for megaco-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 20:31: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 UAA22629 for ; Wed, 27 Aug 2003 20:31:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sAhI-00042w-00 for megaco-web-archive@ietf.org; Wed, 27 Aug 2003 20:31:32 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sAhH-00042s-00 for megaco-web-archive@ietf.org; Wed, 27 Aug 2003 20:31:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5Qv-0002cF-Bo; Wed, 27 Aug 2003 14:54:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2EM-0007SP-Jr for megaco@optimus.ietf.org; Wed, 27 Aug 2003 11:29: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 LAA08986 for ; Wed, 27 Aug 2003 11:29:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s2EL-00012r-00 for megaco@ietf.org; Wed, 27 Aug 2003 11:29:05 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19s2EK-00012m-00 for megaco@ietf.org; Wed, 27 Aug 2003 11:29:04 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h7RFT3fs004860 for ; Wed, 27 Aug 2003 08:29:03 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h7RFT0LS013955 for ; Wed, 27 Aug 2003 10:29:01 -0500 Message-Id: <5.2.1.1.0.20030827111250.00a9c130@IL06EXM04.corp.mot.com> X-Sender: A19776@IL06EXM04.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 27 Aug 2003 11:28:00 -0400 To: megaco@ietf.org From: Aleksandr Ryabin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Megaco] ICAS and ICASC packages state Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, Can someone please update the list if there were any changes to ICAS/ICASC docs since SG-16 Geneva meeting in May 2003? Also the meeting docs public site seem to be unaccessible: http://standard.pictel.com/ftp/avc-site/0305_Gen/ Does anyone have any idea what's wrong? Is there an alternative public web site? Thanks Aleks _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Aug 28 02:18:42 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 CAA05861 for ; Thu, 28 Aug 2003 02:18:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCQH-0000ux-Rs; Wed, 27 Aug 2003 22:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sAdw-0001Lw-MJ for megaco@optimus.ietf.org; Wed, 27 Aug 2003 20:28: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 UAA22430 for ; Wed, 27 Aug 2003 20:28:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sAdu-0003zj-00 for megaco@ietf.org; Wed, 27 Aug 2003 20:28:02 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19sAdt-0003zN-00 for megaco@ietf.org; Wed, 27 Aug 2003 20:28:01 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h7S0OrF09766 for ; Thu, 28 Aug 2003 10:24:53 +1000 (EST) Received: from ericsson.com.au (146.11.245.222 [146.11.245.222]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYCQC809; Thu, 28 Aug 2003 10:27:01 +1000 Message-ID: <3F4D4BFF.1070600@ericsson.com.au> Date: Thu, 28 Aug 2003 10:25:35 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco ietf Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] H.248 Documents for the SG16 Rapporteurs' Paris Meeting Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello all, The following documents have been submitted to the SG16 Q.3 meeting on H.248: AVD 2350 Updated Draft Implementors' Guide Editor AVD 2351 Updated Draft H.248.1 Annex F Editor AVD 2352 Considerations for discussion of update of ServiceChange procedures for H.248 Editor AVD 2353 Updated Draft H.248.icas Nortel Networks, USA AVD 2354 Updated Draft H.248.icasc Nortel Networks, USA AVD 2356 Proposed H.248 RTCPXR Packages Nortel Networks, USA N.B.: The amendments below are a copy of those already contained in the Implementors' guide. AVD 2357 Proposed H.248.1 Version 1 Amendment Nortel Networks, USA AVD 2358 Proposed H.248.1 Version 2 Amendment Nortel Networks, USA AVD 2359 Proposed H.248.2 Amendment Nortel Networks, USA AVD 2360 Proposed H.248.3 Amendment Nortel Networks, USA AVD 2361 Proposed H.248.4 Amendment Nortel Networks, USA AVD 2362 Proposed H.248.7 Amendment Nortel Networks, USA AVD 2363 Proposed H.248.8 Amendment Nortel Networks, USA AVD 2372 A question regarding possibilities to transport call quality parameters via H.248 SG15 AVD 2382 Enhancements to the ServiceChange in H.248.1 Cisco Systems AVD 2383 Updated Draft H.248.AJB Lucent AVD 2384 Proposed H.248 DCC Package Lucent AVD 2386 Draft H.248.19, "Gateway Control Protocol: Decomposed Multipoint Control Unit, Audio, Video and Data Conferencing Packages" Editor AVD 2387 Proposed additions to the H.248.19 for Text Conferencing LM Ericsson AVD 2388 Proposed Ammendment to H.248.2, "Facsimile, Text Conversation and Call Discrimination packages" LM Ericsson AVD 2389 Proposed additions to the H.248 Series Implementors' Guide LM Ericsson AVD 2390 Draft H.248.spch Semi-Permanent Connection Handling Package LM Ericsson AVD 2395 Further Aspects of H.248.ICASC Package Alcatel SEL Germany Note: These documents have not been agreed upon and may be subject to change. These documents can be found at: http://ftp3.itu.int/av-arch/avc-site/0309_Par/ Regards, Christian Groves SG16 Q.3 Rapporteur _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Aug 28 06:06:10 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 GAA24485 for ; Thu, 28 Aug 2003 06:06:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sJIu-0002Qn-8C for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 05:42:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S9guhv009335 for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 05:42:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sEdN-0002QA-Jk for megaco-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 00:43: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 AAA15897 for ; Thu, 28 Aug 2003 00:43:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sEdK-0002Xf-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 00:43:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sEdK-0002Xc-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 00:43:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCSR-00012y-Gl; Wed, 27 Aug 2003 22:24:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sAUb-0000x7-Ne for megaco@optimus.ietf.org; Wed, 27 Aug 2003 20:18: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 UAA21801 for ; Wed, 27 Aug 2003 20:18:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sAUZ-0003pp-00 for megaco@ietf.org; Wed, 27 Aug 2003 20:18:23 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19sAUY-0003pX-00 for megaco@ietf.org; Wed, 27 Aug 2003 20:18:22 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h7S0FAF08792; Thu, 28 Aug 2003 10:15:10 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.222]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYCQC85T; Thu, 28 Aug 2003 10:17:18 +1000 Message-ID: <3F4D49BD.30102@ericsson.com.au> Date: Thu, 28 Aug 2003 10:15:57 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aleksandr Ryabin CC: megaco@ietf.org Subject: Re: [Megaco] ICAS and ICASC packages state References: <5.2.1.1.0.20030827111250.00a9c130@IL06EXM04.corp.mot.com> In-Reply-To: <5.2.1.1.0.20030827111250.00a9c130@IL06EXM04.corp.mot.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 Hello Aleksandr, The AVC site has moved to: http://ftp3.itu.int/av-arch/avc-site/ As q.3 rapporteur i'll send out the list of H.248 contributions shortly. Regards, Christian Aleksandr Ryabin wrote: > Hi, > > Can someone please update the list if there were any changes to > ICAS/ICASC docs since SG-16 Geneva meeting in May 2003? > > Also the meeting docs public site seem to be unaccessible: > http://standard.pictel.com/ftp/avc-site/0305_Gen/ > Does anyone have any idea what's wrong? > Is there an alternative public web site? > > 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 exim@www1.ietf.org Thu Aug 28 06:45:42 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 GAA28520 for ; Thu, 28 Aug 2003 06:45: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 19sJbN-0003d2-9e for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 06:02:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SA21c7013939 for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 06:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sEXa-0002AS-Gn for megaco-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 00: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 AAA15319 for ; Thu, 28 Aug 2003 00:37:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sEXX-0002Om-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 00:37:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sEXX-0002Oj-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 00:37:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDGU-0005Wp-Ju; Wed, 27 Aug 2003 23:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sArY-0002WN-7B for megaco@optimus.ietf.org; Wed, 27 Aug 2003 20:42: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 UAA23504 for ; Wed, 27 Aug 2003 20:42:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sArV-0004IJ-00 for megaco@ietf.org; Wed, 27 Aug 2003 20:42:05 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19sArU-0004IG-00 for megaco@ietf.org; Wed, 27 Aug 2003 20:42:04 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h7S0g20T004724 for ; Wed, 27 Aug 2003 17:42:03 -0700 (MST) Received: from il06exm05.corp.mot.com (il06exm05.corp.mot.com [10.0.111.5]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h7S0g0LR007771 for ; Wed, 27 Aug 2003 19:42:00 -0500 Received: by il06exm05.corp.mot.com with Internet Mail Service (5.5.2657.2) id ; Wed, 27 Aug 2003 19:42:02 -0500 Message-ID: From: Ryabin Aleksandr-A19776 To: "'Christian Groves'" Cc: megaco@ietf.org Subject: RE: [Megaco] ICAS and ICASC packages state Date: Wed, 27 Aug 2003 19:42:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, I see Updated Draft H.248.icas (AVD-2353), but Updated Draft H.248.icasc (AVD-2354) seem to be missing. Any idea when is it going to be uploaded? Thanks Aleks -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] Sent: Wednesday, August 27, 2003 8:16 PM To: Aleksandr Ryabin Cc: megaco@ietf.org Subject: Re: [Megaco] ICAS and ICASC packages state Hello Aleksandr, The AVC site has moved to: http://ftp3.itu.int/av-arch/avc-site/ As q.3 rapporteur i'll send out the list of H.248 contributions shortly. Regards, Christian Aleksandr Ryabin wrote: > Hi, > > Can someone please update the list if there were any changes to > ICAS/ICASC docs since SG-16 Geneva meeting in May 2003? > > Also the meeting docs public site seem to be unaccessible: > http://standard.pictel.com/ftp/avc-site/0305_Gen/ > Does anyone have any idea what's wrong? > Is there an alternative public web site? > > 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 exim@www1.ietf.org Thu Aug 28 07:29: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 HAA03068 for ; Thu, 28 Aug 2003 07:29: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 19sGuM-00037o-9f for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 03:09:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S79QZ5012004 for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 03:09:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sESx-0001mo-Kn for megaco-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 00:32: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 AAA14896 for ; Thu, 28 Aug 2003 00:32:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sESu-0002Ie-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 00:32:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sESu-0002Ib-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 00:32:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCFu-0008UJ-Ft; Wed, 27 Aug 2003 22:11:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sAvI-0002iQ-6y for megaco@optimus.ietf.org; Wed, 27 Aug 2003 20:46: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 UAA23727 for ; Wed, 27 Aug 2003 20:45:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sAvF-0004ML-00 for megaco@ietf.org; Wed, 27 Aug 2003 20:45:57 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19sAvE-0004Lw-00 for megaco@ietf.org; Wed, 27 Aug 2003 20:45:56 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h7S0gkF12450; Thu, 28 Aug 2003 10:42:46 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.222]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYCQC9WK; Thu, 28 Aug 2003 10:44:53 +1000 Message-ID: <3F4D5035.2070004@ericsson.com.au> Date: Thu, 28 Aug 2003 10:43:33 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryabin Aleksandr-A19776 CC: megaco@ietf.org Subject: Re: [Megaco] ICAS and ICASC packages state 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's up to the editor Kevin Boyle. Usually documents are uploaded 5 working days before the meeting. Editors however are allowed to be more flexible. Christian Ryabin Aleksandr-A19776 wrote: > Hi Christian, > > I see Updated Draft H.248.icas (AVD-2353), but > Updated Draft H.248.icasc (AVD-2354) seem to be missing. > Any idea when is it going to be uploaded? > > Thanks > Aleks > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] > Sent: Wednesday, August 27, 2003 8:16 PM > To: Aleksandr Ryabin > Cc: megaco@ietf.org > Subject: Re: [Megaco] ICAS and ICASC packages state > > > Hello Aleksandr, > > The AVC site has moved to: > http://ftp3.itu.int/av-arch/avc-site/ > > As q.3 rapporteur i'll send out the list of H.248 contributions shortly. > > Regards, Christian > > Aleksandr Ryabin wrote: > > >>Hi, >> >>Can someone please update the list if there were any changes to >>ICAS/ICASC docs since SG-16 Geneva meeting in May 2003? >> >>Also the meeting docs public site seem to be unaccessible: >>http://standard.pictel.com/ftp/avc-site/0305_Gen/ >>Does anyone have any idea what's wrong? >>Is there an alternative public web site? >> >>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 exim@www1.ietf.org Thu Aug 28 08:46:54 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 IAA09388 for ; Thu, 28 Aug 2003 08:46:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sK8G-0006Fo-7B for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 06:36:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SAa075024039 for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 06:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sG6s-0008FS-6f for megaco-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 02:18: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 CAA05805 for ; Thu, 28 Aug 2003 02:18:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sG6o-0004fe-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 02:18:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sG6n-0004fb-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 02:18:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCQH-0000ux-Rs; Wed, 27 Aug 2003 22:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sAdw-0001Lw-MJ for megaco@optimus.ietf.org; Wed, 27 Aug 2003 20:28: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 UAA22430 for ; Wed, 27 Aug 2003 20:28:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sAdu-0003zj-00 for megaco@ietf.org; Wed, 27 Aug 2003 20:28:02 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19sAdt-0003zN-00 for megaco@ietf.org; Wed, 27 Aug 2003 20:28:01 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h7S0OrF09766 for ; Thu, 28 Aug 2003 10:24:53 +1000 (EST) Received: from ericsson.com.au (146.11.245.222 [146.11.245.222]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYCQC809; Thu, 28 Aug 2003 10:27:01 +1000 Message-ID: <3F4D4BFF.1070600@ericsson.com.au> Date: Thu, 28 Aug 2003 10:25:35 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco ietf Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] H.248 Documents for the SG16 Rapporteurs' Paris Meeting Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 all, The following documents have been submitted to the SG16 Q.3 meeting on H.248: AVD 2350 Updated Draft Implementors' Guide Editor AVD 2351 Updated Draft H.248.1 Annex F Editor AVD 2352 Considerations for discussion of update of ServiceChange procedures for H.248 Editor AVD 2353 Updated Draft H.248.icas Nortel Networks, USA AVD 2354 Updated Draft H.248.icasc Nortel Networks, USA AVD 2356 Proposed H.248 RTCPXR Packages Nortel Networks, USA N.B.: The amendments below are a copy of those already contained in the Implementors' guide. AVD 2357 Proposed H.248.1 Version 1 Amendment Nortel Networks, USA AVD 2358 Proposed H.248.1 Version 2 Amendment Nortel Networks, USA AVD 2359 Proposed H.248.2 Amendment Nortel Networks, USA AVD 2360 Proposed H.248.3 Amendment Nortel Networks, USA AVD 2361 Proposed H.248.4 Amendment Nortel Networks, USA AVD 2362 Proposed H.248.7 Amendment Nortel Networks, USA AVD 2363 Proposed H.248.8 Amendment Nortel Networks, USA AVD 2372 A question regarding possibilities to transport call quality parameters via H.248 SG15 AVD 2382 Enhancements to the ServiceChange in H.248.1 Cisco Systems AVD 2383 Updated Draft H.248.AJB Lucent AVD 2384 Proposed H.248 DCC Package Lucent AVD 2386 Draft H.248.19, "Gateway Control Protocol: Decomposed Multipoint Control Unit, Audio, Video and Data Conferencing Packages" Editor AVD 2387 Proposed additions to the H.248.19 for Text Conferencing LM Ericsson AVD 2388 Proposed Ammendment to H.248.2, "Facsimile, Text Conversation and Call Discrimination packages" LM Ericsson AVD 2389 Proposed additions to the H.248 Series Implementors' Guide LM Ericsson AVD 2390 Draft H.248.spch Semi-Permanent Connection Handling Package LM Ericsson AVD 2395 Further Aspects of H.248.ICASC Package Alcatel SEL Germany Note: These documents have not been agreed upon and may be subject to change. These documents can be found at: http://ftp3.itu.int/av-arch/avc-site/0309_Par/ Regards, Christian Groves SG16 Q.3 Rapporteur _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Aug 28 09:56:37 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 JAA15743 for ; Thu, 28 Aug 2003 09:56: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 19sKl2-0001m2-1Q; Thu, 28 Aug 2003 07:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sIRF-0000CM-8z for megaco@optimus.ietf.org; Thu, 28 Aug 2003 04:47: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 EAA18088 for ; Thu, 28 Aug 2003 04:47:23 -0400 (EDT) From: klaha@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sIRB-0007nB-00 for megaco@ietf.org; Thu, 28 Aug 2003 04:47:25 -0400 Received: from [202.54.26.202] (helo=hindon.hss.co.in) by ietf-mx with esmtp (Exim 4.12) id 19sIQZ-0007jw-00 for megaco@ietf.org; Thu, 28 Aug 2003 04:46:48 -0400 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 h7S8gCv01439; Thu, 28 Aug 2003 14:12:12 +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 h7S8jUG20395; Thu, 28 Aug 2003 14:15:30 +0530 (IST) Subject: Re: [Megaco] H.248 Documents for the SG16 Rapporteurs' Paris Meeting To: Christian Groves Cc: megaco ietf Date: Thu, 28 Aug 2003 14:08:25 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 28/08/2003 02:08:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Christian, Sorry, but I do not see AVD 2353 at ftp3.itu.int/av-arch/avc-site/0309_Par/ regards, Kushanava Christian Groves @ietf.org on 08/28/2003 05:55:35 AM Sent by: megaco-admin@ietf.org To: megaco ietf cc: Subject: [Megaco] H.248 Documents for the SG16 Rapporteurs' Paris Meeting Hello all, The following documents have been submitted to the SG16 Q.3 meeting on H.248: AVD 2350 Updated Draft Implementors' Guide Editor AVD 2351 Updated Draft H.248.1 Annex F Editor AVD 2352 Considerations for discussion of update of ServiceChange procedures for H.248 Editor AVD 2353 Updated Draft H.248.icas Nortel Networks, USA AVD 2354 Updated Draft H.248.icasc Nortel Networks, USA AVD 2356 Proposed H.248 RTCPXR Packages Nortel Networks, USA N.B.: The amendments below are a copy of those already contained in the Implementors' guide. AVD 2357 Proposed H.248.1 Version 1 Amendment Nortel Networks, USA AVD 2358 Proposed H.248.1 Version 2 Amendment Nortel Networks, USA AVD 2359 Proposed H.248.2 Amendment Nortel Networks, USA AVD 2360 Proposed H.248.3 Amendment Nortel Networks, USA AVD 2361 Proposed H.248.4 Amendment Nortel Networks, USA AVD 2362 Proposed H.248.7 Amendment Nortel Networks, USA AVD 2363 Proposed H.248.8 Amendment Nortel Networks, USA AVD 2372 A question regarding possibilities to transport call quality parameters via H.248 SG15 AVD 2382 Enhancements to the ServiceChange in H.248.1 Cisco Systems AVD 2383 Updated Draft H.248.AJB Lucent AVD 2384 Proposed H.248 DCC Package Lucent AVD 2386 Draft H.248.19, "Gateway Control Protocol: Decomposed Multipoint Control Unit, Audio, Video and Data Conferencing Packages" Editor AVD 2387 Proposed additions to the H.248.19 for Text Conferencing LM Ericsson AVD 2388 Proposed Ammendment to H.248.2, "Facsimile, Text Conversation and Call Discrimination packages" LM Ericsson AVD 2389 Proposed additions to the H.248 Series Implementors' Guide LM Ericsson AVD 2390 Draft H.248.spch Semi-Permanent Connection Handling Package LM Ericsson AVD 2395 Further Aspects of H.248.ICASC Package Alcatel SEL Germany Note: These documents have not been agreed upon and may be subject to change. These documents can be found at: http://ftp3.itu.int/av-arch/avc-site/0309_Par/ Regards, Christian Groves SG16 Q.3 Rapporteur _______________________________________________ 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 Aug 28 10:03:47 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 KAA16523 for ; Thu, 28 Aug 2003 10:03:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKtp-0002Yj-2E; Thu, 28 Aug 2003 07:25:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sIdk-0000yN-85 for megaco@optimus.ietf.org; Thu, 28 Aug 2003 05:00: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 FAA19313 for ; Thu, 28 Aug 2003 05:00:18 -0400 (EDT) From: Internet-Drafts@ietf.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sIdh-0000Ko-00 for megaco@ietf.org; Thu, 28 Aug 2003 05:00:21 -0400 Received: from [219.140.167.39] (helo=NET2) by ietf-mx with esmtp (Exim 4.12) id 19sIdU-0000Jq-00 for megaco@ietf.org; Thu, 28 Aug 2003 05:00:09 -0400 To: Date: Thu, 28 Aug 2003 16:59:28 +0800 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_01ED3C4F" Message-Id: Subject: [Megaco] Thank you! Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_01ED3C4F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_01ED3C4F Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: document_9446.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_01ED3C4F-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Aug 28 10:23:47 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 KAA19177 for ; Thu, 28 Aug 2003 10:23: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 19sK9P-0006VQ-Lr; Thu, 28 Aug 2003 06:37:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sGEk-0000Ec-Jd for megaco@optimus.ietf.org; Thu, 28 Aug 2003 02:26: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 CAA06626 for ; Thu, 28 Aug 2003 02:26:21 -0400 (EDT) From: anilj@mahindrabt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sGEh-0004mw-00 for Megaco@ietf.org; Thu, 28 Aug 2003 02:26:23 -0400 Received: from [219.140.167.39] (helo=NET2) by ietf-mx with esmtp (Exim 4.12) id 19sGEQ-0004mG-00 for Megaco@ietf.org; Thu, 28 Aug 2003 02:26:08 -0400 To: Date: Thu, 28 Aug 2003 14:25:27 +0800 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0160376B" Message-Id: Subject: [Megaco] Re: Thank you! Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0160376B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_0160376B Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: your_details.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0160376B-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Aug 28 14:10:01 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 OAA05859 for ; Thu, 28 Aug 2003 14:10:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sO74-0004Ql-FM; Thu, 28 Aug 2003 10:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKST-0008Ps-70 for megaco@optimus.ietf.org; Thu, 28 Aug 2003 06:56: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 GAA29684 for ; Thu, 28 Aug 2003 06:56:45 -0400 (EDT) From: abhishek@hfcl.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sKSP-0003CG-00 for Megaco@ietf.org; Thu, 28 Aug 2003 06:56:49 -0400 Received: from [219.140.167.39] (helo=NET2) by ietf-mx with esmtp (Exim 4.12) id 19sKSD-00039y-00 for Megaco@ietf.org; Thu, 28 Aug 2003 06:56:38 -0400 To: Date: Thu, 28 Aug 2003 18:55:58 +0800 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0257E34A" Message-Id: Subject: [Megaco] Re: That movie Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0257E34A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_0257E34A Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: movie0045.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0257E34A-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Aug 28 15:11:23 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 PAA10339 for ; Thu, 28 Aug 2003 15:11:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sPhk-0008Vi-Vl; Thu, 28 Aug 2003 12: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 19roMi-0001cs-Cm for megaco@optimus.ietf.org; Tue, 26 Aug 2003 20:40: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 UAA27366 for ; Tue, 26 Aug 2003 20:40:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19roMg-0006K6-00 for megaco@ietf.org; Tue, 26 Aug 2003 20:40:46 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19roMe-0006Jb-00 for megaco@ietf.org; Tue, 26 Aug 2003 20:40:45 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h7R0bQF29029; Wed, 27 Aug 2003 10:37:26 +1000 (EST) Received: from ericsson.com (146.11.245.131 [146.11.245.131]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYCQC2PH; Wed, 27 Aug 2003 10:39:35 +1000 Message-ID: <3F4BFD73.90109@ericsson.com> Date: Wed, 27 Aug 2003 10:38:11 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Solano Arias Randall CC: "'megaco@ietf.org'" Subject: Re: [Megaco] Request_MEGACO/H248 variants References: <7F5A8CBE73BCDA48A9CCF5BBB972797B116B46@sabmen04.red.ice> In-Reply-To: <7F5A8CBE73BCDA48A9CCF5BBB972797B116B46@sabmen04.red.ice> 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 Hello Solano, I am not aware of any national variants of H.248. Regards, Christian Solano Arias Randall wrote: > Hi There; > > > > > > First, I have one request for you, because I am working in one project > about NGN and I want to implement new protocol like MEGACO/H.248 for > control and signalling. > > > > My specify request is about if i must to do one version of H.248 for my > country, this questions is because our PSTN have signalling protocol SS7 > with one variants called country version. > > > > And if MEGACO too need one version of each country. > > > > I hope soon to hear of you. > > > > Cheers, > > > > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Aug 28 15:36:09 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 PAA11681 for ; Thu, 28 Aug 2003 15:36:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sPsP-0000he-Ll; Thu, 28 Aug 2003 12:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s3xB-0004mG-61 for megaco@optimus.ietf.org; Wed, 27 Aug 2003 13:19: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 NAA19263 for ; Wed, 27 Aug 2003 13:19:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s3x9-0003lu-00 for megaco@ietf.org; Wed, 27 Aug 2003 13:19:27 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 19s3x8-0003lK-00 for megaco@ietf.org; Wed, 27 Aug 2003 13:19:26 -0400 Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Aug 2003 19:18:54 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36CBF.4A126E48" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Wed, 27 Aug 2003 19:18:53 +0200 Message-ID: <869954804BD53B41AF69F225F15FC331331DFB@ftrdmel1.rd.francetelecom.fr> Thread-Topic: DTMF detection and buffering thread-index: AcNsv0eCGSPjBQewQZ2750b4qPBb6w== From: "CHATRAS Bruno FTRD/DAC/ISS" To: X-OriginalArrivalTime: 27 Aug 2003 17:18:54.0234 (UTC) FILETIME=[4A9507A0:01C36CBF] Subject: [Megaco] DTMF detection and buffering Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C36CBF.4A126E48 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 A question about digit collection using the Extended DTMF detection package (H.248.16). =20 Let's assume the following scenario: =20 a) The MGC is notified of the off-hook event and reply with a Modify command asking for digit collection according to the Extended DTMF Detection package procedures. The event descriptor includes the xdd/xce event. The digit map parameter is a pointer to DigitMap1 and the buffer control parameter indicates that digit buffering shall occur for let's say 1 minute after the event has been reported.=20 =20 b) Full match according to DigitMap1 occurs in the MG and the xdd/xce event is reported to the MGC. =20 c) The MGC replies with another Modify command asking for the detection of the xdd/xce event, according to another digit map, DigitMap2. =20 Assuming that the buffer is still empty when the second Modify command is received (because the user dials very very slowly), which DigitMap2 timer is used to wait for the first digit to enter the buffer : T or S ? =20 The ambiguous point is that this first digit will be the first digit to be processed by DigitMap2 but will not be the first dialled digit of the overall dialling procedure.=20 =20 I guess the answer is T because digit map processing should not depend on whether a particular DigitMap is processed immediatly after detection of the off-hook event or after another digit map has been processed. However H.248.16, section 5.5.1.2 "The start timer (T) is used prior to any digits having been dialled" is confusing. A more appropriate wording might be "The start timer (T) is used prior to any digits being available for processing against the digit map". =20 Any views ? =20 Regards, =20 Bruno Chatras ------_=_NextPart_001_01C36CBF.4A126E48 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
A = question about=20 digit collection using the Extended DTMF detection package=20 (H.248.16).
 
Let's = assume the=20 following scenario:
 
a) The = MGC is=20 notified of the off-hook event and reply with a Modify command asking = for digit=20 collection according to the Extended DTMF Detection package procedures. = The=20 event descriptor includes the xdd/xce event. The digit map = parameter is a=20 pointer to DigitMap1 and the buffer control parameter indicates that = digit=20 buffering shall occur for let's say 1 minute after the event has been = reported.=20
 
b) = Full match=20 according to DigitMap1 occurs in the MG and the xdd/xce event is = reported to the=20 MGC.
 
c) The = MGC replies=20 with another Modify command asking for the detection of the xdd/xce = event,=20 according to another digit map, DigitMap2.
 
Assuming that the=20 buffer is still empty when the second Modify command is received = (because the=20 user dials very very slowly), which DigitMap2 timer is used to wait = for=20 the first digit to enter the buffer : T or S ?
 
The = ambiguous point=20 is that this first digit will be the first digit to be processed by = DigitMap2=20 but will not be the first dialled digit of the overall dialling = procedure.=20
 
I = guess the answer=20 is T because digit map processing should not depend on whether a = particular=20 DigitMap is processed immediatly after detection of the off-hook event = or after=20 another digit map has been processed. However H.248.16, section 5.5.1.2 = "The=20 start timer (T) is used prior to any digits having been dialled" is = confusing. A=20 more appropriate wording might be "The start timer (T) is used prior to = any=20 digits being available for processing against the digit=20 map".
 
Any = views=20 ?
 
Regards,
 
Bruno=20 Chatras
------_=_NextPart_001_01C36CBF.4A126E48-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Aug 28 15:38:01 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 PAA11789 for ; Thu, 28 Aug 2003 15:38:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sPsO-0000hU-Sf; Thu, 28 Aug 2003 12:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rx83-0004kE-Ft for megaco@optimus.ietf.org; Wed, 27 Aug 2003 06:02:15 -0400 Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12115 for ; Wed, 27 Aug 2003 06:02:08 -0400 (EDT) Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Aug 2003 11:51:35 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE : [Megaco] QoS package Date: Wed, 27 Aug 2003 11:51:34 +0200 Message-ID: <869954804BD53B41AF69F225F15FC331331D75@ftrdmel1.rd.francetelecom.fr> Thread-Topic: [Megaco] QoS package thread-index: AcNGLKyn6gwAT3fvQ1OSan3WuTpfmAmPuDMQ From: "CHATRAS Bruno FTRD/DAC/ISS" To: "Tom Taylor" Cc: X-OriginalArrivalTime: 27 Aug 2003 09:51:35.0390 (UTC) FILETIME=[CD626FE0:01C36C80] 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 FYI, An updated proposal is available at :=20 http://www.itu.int/md/meetingdoc.asp?type=3Dmitems&lang=3De&parent=3DT01-= SG11-030901-D-0507 -----Message d'origine----- De : Tom Taylor [mailto:taylor@nortelnetworks.com]=20 Envoy=E9 : mercredi 9 juillet 2003 13:59 =C0 : YAMAMOTO, Susumu Cc : megaco@ietf.org; tsuboi.shunnichi@lab.ntt.co.jp Objet : Re: [Megaco] QoS package France Telecom has such a proposal into SG 11. If you have an ITU-T = TIES account, have a look at = http://ties.itu.int/u/tsg11/sg11/bicc/common/france-0304/fra105r1.zip YAMAMOTO, Susumu wrote: > Hi all, >=20 > I am looking for a MEGACO package which could configure TOS value of > RTP packets session by session with Add or Modify command. I found=20 > draft-madhubabu-megaco-qospackage-00 at some web sites, but the draft=20 > seems already expired. >=20 > Please let me know the current situation of standardization of the > draft, or another latest solution for TOS operation if we have. I hope = > the standardization process for the draft might contiue in ITU or=20 > somewhere. >=20 > Thanks, > -Susumu >=20 >=20 >=20 > _______________________________________________ > 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 exim@www1.ietf.org Thu Aug 28 17:49:54 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 RAA22073 for ; Thu, 28 Aug 2003 17:49:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sR6x-0004rW-MO for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 14:03:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SI373n018683 for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 14:03:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sNMy-0002X5-90 for megaco-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 10:03: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 KAA16455 for ; Thu, 28 Aug 2003 10:03:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sNMw-0007d5-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 10:03:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sNMv-0007d2-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 10:03:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKtp-0002Yj-2E; Thu, 28 Aug 2003 07:25:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sIdk-0000yN-85 for megaco@optimus.ietf.org; Thu, 28 Aug 2003 05:00: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 FAA19313 for ; Thu, 28 Aug 2003 05:00:18 -0400 (EDT) From: Internet-Drafts@ietf.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sIdh-0000Ko-00 for megaco@ietf.org; Thu, 28 Aug 2003 05:00:21 -0400 Received: from [219.140.167.39] (helo=NET2) by ietf-mx with esmtp (Exim 4.12) id 19sIdU-0000Jq-00 for megaco@ietf.org; Thu, 28 Aug 2003 05:00:09 -0400 To: Date: Thu, 28 Aug 2003 16:59:28 +0800 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_01ED3C4F" Message-Id: Subject: [Megaco] Thank you! Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_01ED3C4F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_01ED3C4F Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: document_9446.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_01ED3C4F-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Aug 28 18:02:02 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 SAA22709 for ; Thu, 28 Aug 2003 18:02:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sR7V-0004xo-Um for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 14:03:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SI3frZ019070 for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 14:03:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sNgJ-0003Lt-N2 for megaco-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 10:23: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 KAA19143 for ; Thu, 28 Aug 2003 10:23:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sNgH-0000E0-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 10:23:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sNgG-0000Dx-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 10:23:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sK9P-0006VQ-Lr; Thu, 28 Aug 2003 06:37:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sGEk-0000Ec-Jd for megaco@optimus.ietf.org; Thu, 28 Aug 2003 02:26: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 CAA06626 for ; Thu, 28 Aug 2003 02:26:21 -0400 (EDT) From: anilj@mahindrabt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sGEh-0004mw-00 for Megaco@ietf.org; Thu, 28 Aug 2003 02:26:23 -0400 Received: from [219.140.167.39] (helo=NET2) by ietf-mx with esmtp (Exim 4.12) id 19sGEQ-0004mG-00 for Megaco@ietf.org; Thu, 28 Aug 2003 02:26:08 -0400 To: Date: Thu, 28 Aug 2003 14:25:27 +0800 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0160376B" Message-Id: Subject: [Megaco] Re: Thank you! Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0160376B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_0160376B Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: your_details.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0160376B-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Aug 28 18:09: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 SAA23785 for ; Thu, 28 Aug 2003 18:09: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 19sQq3-00046z-1x for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 13:45:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SHjdL7015799 for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 13:45:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sNG2-0002Fm-Ha for megaco-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 09:56: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 JAA15712 for ; Thu, 28 Aug 2003 09:56:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sNG0-0007T7-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 09:56:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sNFz-0007T4-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 09:56:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKl2-0001m2-1Q; Thu, 28 Aug 2003 07:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sIRF-0000CM-8z for megaco@optimus.ietf.org; Thu, 28 Aug 2003 04:47: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 EAA18088 for ; Thu, 28 Aug 2003 04:47:23 -0400 (EDT) From: klaha@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sIRB-0007nB-00 for megaco@ietf.org; Thu, 28 Aug 2003 04:47:25 -0400 Received: from [202.54.26.202] (helo=hindon.hss.co.in) by ietf-mx with esmtp (Exim 4.12) id 19sIQZ-0007jw-00 for megaco@ietf.org; Thu, 28 Aug 2003 04:46:48 -0400 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 h7S8gCv01439; Thu, 28 Aug 2003 14:12:12 +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 h7S8jUG20395; Thu, 28 Aug 2003 14:15:30 +0530 (IST) Subject: Re: [Megaco] H.248 Documents for the SG16 Rapporteurs' Paris Meeting To: Christian Groves Cc: megaco ietf Date: Thu, 28 Aug 2003 14:08:25 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 28/08/2003 02:08:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Christian, Sorry, but I do not see AVD 2353 at ftp3.itu.int/av-arch/avc-site/0309_Par/ regards, Kushanava Christian Groves @ietf.org on 08/28/2003 05:55:35 AM Sent by: megaco-admin@ietf.org To: megaco ietf cc: Subject: [Megaco] H.248 Documents for the SG16 Rapporteurs' Paris Meeting Hello all, The following documents have been submitted to the SG16 Q.3 meeting on H.248: AVD 2350 Updated Draft Implementors' Guide Editor AVD 2351 Updated Draft H.248.1 Annex F Editor AVD 2352 Considerations for discussion of update of ServiceChange procedures for H.248 Editor AVD 2353 Updated Draft H.248.icas Nortel Networks, USA AVD 2354 Updated Draft H.248.icasc Nortel Networks, USA AVD 2356 Proposed H.248 RTCPXR Packages Nortel Networks, USA N.B.: The amendments below are a copy of those already contained in the Implementors' guide. AVD 2357 Proposed H.248.1 Version 1 Amendment Nortel Networks, USA AVD 2358 Proposed H.248.1 Version 2 Amendment Nortel Networks, USA AVD 2359 Proposed H.248.2 Amendment Nortel Networks, USA AVD 2360 Proposed H.248.3 Amendment Nortel Networks, USA AVD 2361 Proposed H.248.4 Amendment Nortel Networks, USA AVD 2362 Proposed H.248.7 Amendment Nortel Networks, USA AVD 2363 Proposed H.248.8 Amendment Nortel Networks, USA AVD 2372 A question regarding possibilities to transport call quality parameters via H.248 SG15 AVD 2382 Enhancements to the ServiceChange in H.248.1 Cisco Systems AVD 2383 Updated Draft H.248.AJB Lucent AVD 2384 Proposed H.248 DCC Package Lucent AVD 2386 Draft H.248.19, "Gateway Control Protocol: Decomposed Multipoint Control Unit, Audio, Video and Data Conferencing Packages" Editor AVD 2387 Proposed additions to the H.248.19 for Text Conferencing LM Ericsson AVD 2388 Proposed Ammendment to H.248.2, "Facsimile, Text Conversation and Call Discrimination packages" LM Ericsson AVD 2389 Proposed additions to the H.248 Series Implementors' Guide LM Ericsson AVD 2390 Draft H.248.spch Semi-Permanent Connection Handling Package LM Ericsson AVD 2395 Further Aspects of H.248.ICASC Package Alcatel SEL Germany Note: These documents have not been agreed upon and may be subject to change. These documents can be found at: http://ftp3.itu.int/av-arch/avc-site/0309_Par/ Regards, Christian Groves SG16 Q.3 Rapporteur _______________________________________________ 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 Aug 28 19:25:05 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 TAA29414 for ; Thu, 28 Aug 2003 19:25:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sTGg-00038m-MY for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 16:21:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SKLI44012068 for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 16:21:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sSAg-0008HP-GD for megaco-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 15:11: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 PAA10287 for ; Thu, 28 Aug 2003 15:10:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sSAb-00055h-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 15:10:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sSAa-00055e-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 15:10:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sPhk-0008Vi-Vl; Thu, 28 Aug 2003 12: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 19roMi-0001cs-Cm for megaco@optimus.ietf.org; Tue, 26 Aug 2003 20:40: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 UAA27366 for ; Tue, 26 Aug 2003 20:40:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19roMg-0006K6-00 for megaco@ietf.org; Tue, 26 Aug 2003 20:40:46 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19roMe-0006Jb-00 for megaco@ietf.org; Tue, 26 Aug 2003 20:40:45 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h7R0bQF29029; Wed, 27 Aug 2003 10:37:26 +1000 (EST) Received: from ericsson.com (146.11.245.131 [146.11.245.131]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYCQC2PH; Wed, 27 Aug 2003 10:39:35 +1000 Message-ID: <3F4BFD73.90109@ericsson.com> Date: Wed, 27 Aug 2003 10:38:11 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Solano Arias Randall CC: "'megaco@ietf.org'" Subject: Re: [Megaco] Request_MEGACO/H248 variants References: <7F5A8CBE73BCDA48A9CCF5BBB972797B116B46@sabmen04.red.ice> In-Reply-To: <7F5A8CBE73BCDA48A9CCF5BBB972797B116B46@sabmen04.red.ice> 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 Hello Solano, I am not aware of any national variants of H.248. Regards, Christian Solano Arias Randall wrote: > Hi There; > > > > > > First, I have one request for you, because I am working in one project > about NGN and I want to implement new protocol like MEGACO/H.248 for > control and signalling. > > > > My specify request is about if i must to do one version of H.248 for my > country, this questions is because our PSTN have signalling protocol SS7 > with one variants called country version. > > > > And if MEGACO too need one version of each country. > > > > I hope soon to hear of you. > > > > Cheers, > > > > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Aug 28 19:54: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 TAA01487 for ; Thu, 28 Aug 2003 19:54: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 19sTnL-0004wm-5e; Thu, 28 Aug 2003 16: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 19sQUs-0002Os-T2 for megaco@optimus.ietf.org; Thu, 28 Aug 2003 13:23: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 NAA02323 for ; Thu, 28 Aug 2003 13:23:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sQUq-0003K2-00 for megaco@ietf.org; Thu, 28 Aug 2003 13:23:44 -0400 Received: from web80707.mail.yahoo.com ([66.163.170.64]) by ietf-mx with smtp (Exim 4.12) id 19sQUp-0003Jt-00 for megaco@ietf.org; Thu, 28 Aug 2003 13:23:44 -0400 Message-ID: <20030828172340.26597.qmail@web80707.mail.yahoo.com> Received: from [195.167.202.147] by web80707.mail.yahoo.com via HTTP; Thu, 28 Aug 2003 10:23:40 PDT Date: Thu, 28 Aug 2003 10:23:40 -0700 (PDT) From: "Ar c'hasour" To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Megaco] 2 terminations on different MGs Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 I would like to a question regarding to a cluster of MGs. Suppose I have a MGC which has created 2 "isolated" terminations for 2 users: For user1, termination t1 is in context c1 on MG1 (ip-adr1, port1) For user2, termination t2 is in context c2 on MG2 (ip-adr2, port2) In a sense, user1 has established a "channel" towards MG1, and user 2 has done the same towards MG2. Now if end-user 1 wants to speak with end-user2, I would like the MGC to order to send data received on t1 towards t2. To do it, the first idea would be to "move" the termination t2 on mg1, but then it would also be needed to inform user 2 that t2's ip address has changed and I need to avoid this. Is there another way to do with MEGACO ? Greetings, P. Kasour __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Aug 28 19:58:18 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 TAA01709 for ; Thu, 28 Aug 2003 19:58:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sTnL-0004ww-PJ; Thu, 28 Aug 2003 16: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 19sSgR-00015I-JU for megaco@optimus.ietf.org; Thu, 28 Aug 2003 15:43: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 PAA12163 for ; Thu, 28 Aug 2003 15:43:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sSgQ-0005K2-00 for megaco@ietf.org; Thu, 28 Aug 2003 15:43:50 -0400 Received: from web20610.mail.yahoo.com ([216.136.226.168]) by ietf-mx with smtp (Exim 4.12) id 19sSgP-0005Jy-00 for megaco@ietf.org; Thu, 28 Aug 2003 15:43:49 -0400 Message-ID: <20030828194348.31487.qmail@web20610.mail.yahoo.com> Received: from [203.199.118.12] by web20610.mail.yahoo.com via HTTP; Thu, 28 Aug 2003 12:43:48 PDT Date: Thu, 28 Aug 2003 12:43:48 -0700 (PDT) From: narasingarao srinath To: megaco@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1188035683-1062099828=:31321" Subject: [Megaco] abbreviation of Megaco Packages Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --0-1188035683-1062099828=:31321 Content-Type: text/plain; charset=us-ascii Hi, Where can i find the abbreviation for all the megaco packages. Is there any document where all the packages are listed. Please suggest. regards, srinath. --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software --0-1188035683-1062099828=:31321 Content-Type: text/html; charset=us-ascii
Hi,
     Where can i find the abbreviation for all the megaco packages.
Is there any document where all the packages are listed.
Please suggest.
 
regards,
srinath.

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software --0-1188035683-1062099828=:31321-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Aug 28 20:13: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 UAA02837 for ; Thu, 28 Aug 2003 20:13: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 19sTlz-0004v8-Ve for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 16:53:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SKrdQn018906 for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 16:53:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sSat-0000p2-3B for megaco-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 15:38:07 -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 PAA11791 for ; Thu, 28 Aug 2003 15:38:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sPsO-0000hU-Sf; Thu, 28 Aug 2003 12:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rx83-0004kE-Ft for megaco@optimus.ietf.org; Wed, 27 Aug 2003 06:02:15 -0400 Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12115 for ; Wed, 27 Aug 2003 06:02:08 -0400 (EDT) Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Aug 2003 11:51:35 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE : [Megaco] QoS package Date: Wed, 27 Aug 2003 11:51:34 +0200 Message-ID: <869954804BD53B41AF69F225F15FC331331D75@ftrdmel1.rd.francetelecom.fr> Thread-Topic: [Megaco] QoS package thread-index: AcNGLKyn6gwAT3fvQ1OSan3WuTpfmAmPuDMQ From: "CHATRAS Bruno FTRD/DAC/ISS" To: "Tom Taylor" Cc: X-OriginalArrivalTime: 27 Aug 2003 09:51:35.0390 (UTC) FILETIME=[CD626FE0:01C36C80] 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 FYI, An updated proposal is available at :=20 http://www.itu.int/md/meetingdoc.asp?type=3Dmitems&lang=3De&parent=3DT01-= SG11-030901-D-0507 -----Message d'origine----- De : Tom Taylor [mailto:taylor@nortelnetworks.com]=20 Envoy=E9 : mercredi 9 juillet 2003 13:59 =C0 : YAMAMOTO, Susumu Cc : megaco@ietf.org; tsuboi.shunnichi@lab.ntt.co.jp Objet : Re: [Megaco] QoS package France Telecom has such a proposal into SG 11. If you have an ITU-T = TIES account, have a look at = http://ties.itu.int/u/tsg11/sg11/bicc/common/france-0304/fra105r1.zip YAMAMOTO, Susumu wrote: > Hi all, >=20 > I am looking for a MEGACO package which could configure TOS value of > RTP packets session by session with Add or Modify command. I found=20 > draft-madhubabu-megaco-qospackage-00 at some web sites, but the draft=20 > seems already expired. >=20 > Please let me know the current situation of standardization of the > draft, or another latest solution for TOS operation if we have. I hope = > the standardization process for the draft might contiue in ITU or=20 > somewhere. >=20 > Thanks, > -Susumu >=20 >=20 >=20 > _______________________________________________ > 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 exim@www1.ietf.org Thu Aug 28 20:52:14 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 UAA06495 for ; Thu, 28 Aug 2003 20:52:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sVQC-0000rh-IM for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 18:39:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SMdGsZ003319 for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 18:39:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sSZ4-0000Uc-7X for megaco-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 15:36:14 -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 PAA11683 for ; Thu, 28 Aug 2003 15:36:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sPsP-0000he-Ll; Thu, 28 Aug 2003 12:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s3xB-0004mG-61 for megaco@optimus.ietf.org; Wed, 27 Aug 2003 13:19: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 NAA19263 for ; Wed, 27 Aug 2003 13:19:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s3x9-0003lu-00 for megaco@ietf.org; Wed, 27 Aug 2003 13:19:27 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 19s3x8-0003lK-00 for megaco@ietf.org; Wed, 27 Aug 2003 13:19:26 -0400 Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Aug 2003 19:18:54 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36CBF.4A126E48" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Wed, 27 Aug 2003 19:18:53 +0200 Message-ID: <869954804BD53B41AF69F225F15FC331331DFB@ftrdmel1.rd.francetelecom.fr> Thread-Topic: DTMF detection and buffering thread-index: AcNsv0eCGSPjBQewQZ2750b4qPBb6w== From: "CHATRAS Bruno FTRD/DAC/ISS" To: X-OriginalArrivalTime: 27 Aug 2003 17:18:54.0234 (UTC) FILETIME=[4A9507A0:01C36CBF] Subject: [Megaco] DTMF detection and buffering Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C36CBF.4A126E48 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 A question about digit collection using the Extended DTMF detection package (H.248.16). =20 Let's assume the following scenario: =20 a) The MGC is notified of the off-hook event and reply with a Modify command asking for digit collection according to the Extended DTMF Detection package procedures. The event descriptor includes the xdd/xce event. The digit map parameter is a pointer to DigitMap1 and the buffer control parameter indicates that digit buffering shall occur for let's say 1 minute after the event has been reported.=20 =20 b) Full match according to DigitMap1 occurs in the MG and the xdd/xce event is reported to the MGC. =20 c) The MGC replies with another Modify command asking for the detection of the xdd/xce event, according to another digit map, DigitMap2. =20 Assuming that the buffer is still empty when the second Modify command is received (because the user dials very very slowly), which DigitMap2 timer is used to wait for the first digit to enter the buffer : T or S ? =20 The ambiguous point is that this first digit will be the first digit to be processed by DigitMap2 but will not be the first dialled digit of the overall dialling procedure.=20 =20 I guess the answer is T because digit map processing should not depend on whether a particular DigitMap is processed immediatly after detection of the off-hook event or after another digit map has been processed. However H.248.16, section 5.5.1.2 "The start timer (T) is used prior to any digits having been dialled" is confusing. A more appropriate wording might be "The start timer (T) is used prior to any digits being available for processing against the digit map". =20 Any views ? =20 Regards, =20 Bruno Chatras ------_=_NextPart_001_01C36CBF.4A126E48 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
A = question about=20 digit collection using the Extended DTMF detection package=20 (H.248.16).
 
Let's = assume the=20 following scenario:
 
a) The = MGC is=20 notified of the off-hook event and reply with a Modify command asking = for digit=20 collection according to the Extended DTMF Detection package procedures. = The=20 event descriptor includes the xdd/xce event. The digit map = parameter is a=20 pointer to DigitMap1 and the buffer control parameter indicates that = digit=20 buffering shall occur for let's say 1 minute after the event has been = reported.=20
 
b) = Full match=20 according to DigitMap1 occurs in the MG and the xdd/xce event is = reported to the=20 MGC.
 
c) The = MGC replies=20 with another Modify command asking for the detection of the xdd/xce = event,=20 according to another digit map, DigitMap2.
 
Assuming that the=20 buffer is still empty when the second Modify command is received = (because the=20 user dials very very slowly), which DigitMap2 timer is used to wait = for=20 the first digit to enter the buffer : T or S ?
 
The = ambiguous point=20 is that this first digit will be the first digit to be processed by = DigitMap2=20 but will not be the first dialled digit of the overall dialling = procedure.=20
 
I = guess the answer=20 is T because digit map processing should not depend on whether a = particular=20 DigitMap is processed immediatly after detection of the off-hook event = or after=20 another digit map has been processed. However H.248.16, section 5.5.1.2 = "The=20 start timer (T) is used prior to any digits having been dialled" is = confusing. A=20 more appropriate wording might be "The start timer (T) is used prior to = any=20 digits being available for processing against the digit=20 map".
 
Any = views=20 ?
 
Regards,
 
Bruno=20 Chatras
------_=_NextPart_001_01C36CBF.4A126E48-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Aug 28 21:05:17 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 VAA07458 for ; Thu, 28 Aug 2003 21:05:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sTjI-0004hQ-Hk for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 16:50:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SKoqS6018056 for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 16:50:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sRDF-0005aT-Df for megaco-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 14:09: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 OAA05801 for ; Thu, 28 Aug 2003 14:09:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sRDC-0004Fv-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 14:09:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sRDC-0004Fs-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 14:09:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sO74-0004Ql-FM; Thu, 28 Aug 2003 10:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKST-0008Ps-70 for megaco@optimus.ietf.org; Thu, 28 Aug 2003 06:56: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 GAA29684 for ; Thu, 28 Aug 2003 06:56:45 -0400 (EDT) From: abhishek@hfcl.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sKSP-0003CG-00 for Megaco@ietf.org; Thu, 28 Aug 2003 06:56:49 -0400 Received: from [219.140.167.39] (helo=NET2) by ietf-mx with esmtp (Exim 4.12) id 19sKSD-00039y-00 for Megaco@ietf.org; Thu, 28 Aug 2003 06:56:38 -0400 To: Date: Thu, 28 Aug 2003 18:55:58 +0800 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0257E34A" Message-Id: Subject: [Megaco] Re: That movie Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0257E34A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_0257E34A Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: movie0045.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0257E34A-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Aug 28 22:44:47 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 WAA14624 for ; Thu, 28 Aug 2003 22:44:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sYiA-0002nP-Sv; Thu, 28 Aug 2003 22:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sWNg-00033a-G9 for megaco@optimus.ietf.org; Thu, 28 Aug 2003 19:40: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 TAA00548 for ; Thu, 28 Aug 2003 19:40:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sWNe-0001ap-00 for megaco@ietf.org; Thu, 28 Aug 2003 19:40:42 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 19sWNe-0001aP-00 for megaco@ietf.org; Thu, 28 Aug 2003 19:40:42 -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 h7SNe6C11977 for ; Thu, 28 Aug 2003 19:40:06 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Aug 2003 19:40:05 -0400 Message-ID: From: "Kevin Boyle" To: CHATRAS Bruno FTRD/DAC/ISS Cc: megaco@ietf.org Subject: RE: [Megaco] DTMF detection and buffering Date: Thu, 28 Aug 2003 19:40:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , You are correct; the T timer should be used. If the MGC wishes to suppress the T timer, it should set it to 0 in the second DigitMap. Note that this wording exists in H.248.1, Section 7.1.14.2 as well. I am amenable to a wording change if this will help clear up any confusion. It would have to included in the IG (for both H.248.1 and H.248.16) -- I will bring it up next week in Paris. Anyone object to the wording suggested by Bruno below? Kevin -----Original Message----- From: CHATRAS Bruno FTRD/DAC/ISS [mailto:bruno.chatras@francetelecom.com] Sent: Wednesday, August 27, 2003 1:19 PM To: megaco@ietf.org Subject: [Megaco] DTMF detection and buffering Hi, A question about digit collection using the Extended DTMF detection package (H.248.16). Let's assume the following scenario: a) The MGC is notified of the off-hook event and reply with a Modify command asking for digit collection according to the Extended DTMF Detection package procedures. The event descriptor includes the xdd/xce event. The digit map parameter is a pointer to DigitMap1 and the buffer control parameter indicates that digit buffering shall occur for let's say 1 minute after the event has been reported. b) Full match according to DigitMap1 occurs in the MG and the xdd/xce event is reported to the MGC. c) The MGC replies with another Modify command asking for the detection of the xdd/xce event, according to another digit map, DigitMap2. Assuming that the buffer is still empty when the second Modify command is received (because the user dials very very slowly), which DigitMap2 timer is used to wait for the first digit to enter the buffer : T or S ? The ambiguous point is that this first digit will be the first digit to be processed by DigitMap2 but will not be the first dialled digit of the overall dialling procedure. I guess the answer is T because digit map processing should not depend on whether a particular DigitMap is processed immediatly after detection of the off-hook event or after another digit map has been processed. However H.248.16, section 5.5.1.2 "The start timer (T) is used prior to any digits having been dialled" is confusing. A more appropriate wording might be "The start timer (T) is used prior to any digits being available for processing against the digit map". Any views ? Regards, Bruno Chatras _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Aug 29 01:35:36 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 BAA29270 for ; Fri, 29 Aug 2003 01:35:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sZbR-0004uU-Be; Thu, 28 Aug 2003 23:07:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sX5t-0005RR-0O for megaco@optimus.ietf.org; Thu, 28 Aug 2003 20:26: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 UAA03859 for ; Thu, 28 Aug 2003 20:26:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sX5q-0002NJ-00 for megaco@ietf.org; Thu, 28 Aug 2003 20:26:22 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19sX5p-0002Me-00 for megaco@ietf.org; Thu, 28 Aug 2003 20:26:21 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h7T0NDF19300; Fri, 29 Aug 2003 10:23:13 +1000 (EST) Received: from ericsson.com.au (146.11.245.139 [146.11.245.139]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYCQD40D; Fri, 29 Aug 2003 10:25:18 +1000 Message-ID: <3F4E9D16.7010807@ericsson.com.au> Date: Fri, 29 Aug 2003 10:23:50 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ar c'hasour" CC: megaco@ietf.org Subject: Re: [Megaco] 2 terminations on different MGs References: <20030828172340.26597.qmail@web80707.mail.yahoo.com> In-Reply-To: <20030828172340.26597.qmail@web80707.mail.yahoo.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 Hello, You would use a MOD command to place the peer users IP addr/port in the remote descriptor. Please look at the H.248.1 appendix for an example. Chirstian Ar c'hasour wrote: > Hello > > I would like to a question regarding to a cluster of > MGs. > > Suppose I have a MGC which has created 2 "isolated" > terminations for 2 users: > For user1, termination t1 is in context c1 on MG1 > (ip-adr1, port1) > For user2, termination t2 is in context c2 on MG2 > (ip-adr2, port2) > In a sense, user1 has established a "channel" towards > MG1, and user 2 has done the same towards MG2. > > Now if end-user 1 wants to speak with end-user2, I > would like the MGC to order to send data received on > t1 towards t2. > > To do it, the first idea would be to "move" the > termination t2 on mg1, but then it would also be > needed to inform user 2 that t2's ip address has > changed and I need to avoid this. > > Is there another way to do with MEGACO ? > > Greetings, > P. Kasour > > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.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 Aug 29 01:47:15 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 BAA00680 for ; Fri, 29 Aug 2003 01:47:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sZS4-0004Og-3x for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 22:57:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T2vRVq016892 for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 22:57:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sZFR-0003nt-E1 for megaco-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 22:44: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 WAA14574 for ; Thu, 28 Aug 2003 22:44:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sZFN-0004zE-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 22:44:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sZFN-0004zB-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 22:44:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sYiA-0002nP-Sv; Thu, 28 Aug 2003 22:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sWNg-00033a-G9 for megaco@optimus.ietf.org; Thu, 28 Aug 2003 19:40: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 TAA00548 for ; Thu, 28 Aug 2003 19:40:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sWNe-0001ap-00 for megaco@ietf.org; Thu, 28 Aug 2003 19:40:42 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 19sWNe-0001aP-00 for megaco@ietf.org; Thu, 28 Aug 2003 19:40:42 -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 h7SNe6C11977 for ; Thu, 28 Aug 2003 19:40:06 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Aug 2003 19:40:05 -0400 Message-ID: From: "Kevin Boyle" To: CHATRAS Bruno FTRD/DAC/ISS Cc: megaco@ietf.org Subject: RE: [Megaco] DTMF detection and buffering Date: Thu, 28 Aug 2003 19:40:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , You are correct; the T timer should be used. If the MGC wishes to suppress the T timer, it should set it to 0 in the second DigitMap. Note that this wording exists in H.248.1, Section 7.1.14.2 as well. I am amenable to a wording change if this will help clear up any confusion. It would have to included in the IG (for both H.248.1 and H.248.16) -- I will bring it up next week in Paris. Anyone object to the wording suggested by Bruno below? Kevin -----Original Message----- From: CHATRAS Bruno FTRD/DAC/ISS [mailto:bruno.chatras@francetelecom.com] Sent: Wednesday, August 27, 2003 1:19 PM To: megaco@ietf.org Subject: [Megaco] DTMF detection and buffering Hi, A question about digit collection using the Extended DTMF detection package (H.248.16). Let's assume the following scenario: a) The MGC is notified of the off-hook event and reply with a Modify command asking for digit collection according to the Extended DTMF Detection package procedures. The event descriptor includes the xdd/xce event. The digit map parameter is a pointer to DigitMap1 and the buffer control parameter indicates that digit buffering shall occur for let's say 1 minute after the event has been reported. b) Full match according to DigitMap1 occurs in the MG and the xdd/xce event is reported to the MGC. c) The MGC replies with another Modify command asking for the detection of the xdd/xce event, according to another digit map, DigitMap2. Assuming that the buffer is still empty when the second Modify command is received (because the user dials very very slowly), which DigitMap2 timer is used to wait for the first digit to enter the buffer : T or S ? The ambiguous point is that this first digit will be the first digit to be processed by DigitMap2 but will not be the first dialled digit of the overall dialling procedure. I guess the answer is T because digit map processing should not depend on whether a particular DigitMap is processed immediatly after detection of the off-hook event or after another digit map has been processed. However H.248.16, section 5.5.1.2 "The start timer (T) is used prior to any digits having been dialled" is confusing. A more appropriate wording might be "The start timer (T) is used prior to any digits being available for processing against the digit map". Any views ? Regards, Bruno Chatras _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Aug 29 02:09: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 CAA11440 for ; Fri, 29 Aug 2003 02:09: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 19sZRZ-0004N6-U5 for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 22:56:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T2uvde016796 for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 22:56:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sWau-0003bT-FI for megaco-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 19:54: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 TAA01453 for ; Thu, 28 Aug 2003 19:54:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sWar-0001lj-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 19:54:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sWaq-0001lf-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 19:54:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sTnL-0004wm-5e; Thu, 28 Aug 2003 16: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 19sQUs-0002Os-T2 for megaco@optimus.ietf.org; Thu, 28 Aug 2003 13:23: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 NAA02323 for ; Thu, 28 Aug 2003 13:23:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sQUq-0003K2-00 for megaco@ietf.org; Thu, 28 Aug 2003 13:23:44 -0400 Received: from web80707.mail.yahoo.com ([66.163.170.64]) by ietf-mx with smtp (Exim 4.12) id 19sQUp-0003Jt-00 for megaco@ietf.org; Thu, 28 Aug 2003 13:23:44 -0400 Message-ID: <20030828172340.26597.qmail@web80707.mail.yahoo.com> Received: from [195.167.202.147] by web80707.mail.yahoo.com via HTTP; Thu, 28 Aug 2003 10:23:40 PDT Date: Thu, 28 Aug 2003 10:23:40 -0700 (PDT) From: "Ar c'hasour" To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Megaco] 2 terminations on different MGs Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 I would like to a question regarding to a cluster of MGs. Suppose I have a MGC which has created 2 "isolated" terminations for 2 users: For user1, termination t1 is in context c1 on MG1 (ip-adr1, port1) For user2, termination t2 is in context c2 on MG2 (ip-adr2, port2) In a sense, user1 has established a "channel" towards MG1, and user 2 has done the same towards MG2. Now if end-user 1 wants to speak with end-user2, I would like the MGC to order to send data received on t1 towards t2. To do it, the first idea would be to "move" the termination t2 on mg1, but then it would also be needed to inform user 2 that t2's ip address has changed and I need to avoid this. Is there another way to do with MEGACO ? Greetings, P. Kasour __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Aug 29 02:34:54 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 CAA17200 for ; Fri, 29 Aug 2003 02:34:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sb2L-0001j7-Dc; Fri, 29 Aug 2003 00: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 19sX4A-0005KB-ID for megaco@optimus.ietf.org; Thu, 28 Aug 2003 20: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 UAA03731 for ; Thu, 28 Aug 2003 20:24:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sX48-0002L5-00 for megaco@ietf.org; Thu, 28 Aug 2003 20:24:36 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19sX47-0002KE-00 for megaco@ietf.org; Thu, 28 Aug 2003 20:24:35 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h7T0LQF19128; Fri, 29 Aug 2003 10:21:26 +1000 (EST) Received: from ericsson.com.au (146.11.245.139 [146.11.245.139]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYCQD48V; Fri, 29 Aug 2003 10:23:31 +1000 Message-ID: <3F4E9CAB.7020901@ericsson.com.au> Date: Fri, 29 Aug 2003 10:22:03 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: narasingarao srinath CC: megaco@ietf.org Subject: Re: [Megaco] abbreviation of Megaco Packages References: <20030828194348.31487.qmail@web20610.mail.yahoo.com> In-Reply-To: <20030828194348.31487.qmail@web20610.mail.yahoo.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 http://www.iana.org/assignments/megaco-h248 or the packages supplement: http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-H.Sup2 Christian narasingarao srinath wrote: > Hi, > Where can i find the abbreviation for all the megaco packages. > Is there any document where all the packages are listed. > Please suggest. > > regards, > srinath. > > ------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! SiteBuilder > - Free, > easy-to-use web site design software _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Aug 29 02:45: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 CAA18014 for ; Fri, 29 Aug 2003 02:45: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 19sZUg-0004Zg-1v for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 23:00:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T309Dk017570 for megaco-archive@odin.ietf.org; Thu, 28 Aug 2003 23:00:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sWeJ-0003jo-JK for megaco-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 19:57: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 TAA01664 for ; Thu, 28 Aug 2003 19:57:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sWeH-0001oz-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 19:57:53 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sWeH-0001ow-00 for megaco-web-archive@ietf.org; Thu, 28 Aug 2003 19:57:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sTnL-0004ww-PJ; Thu, 28 Aug 2003 16: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 19sSgR-00015I-JU for megaco@optimus.ietf.org; Thu, 28 Aug 2003 15:43: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 PAA12163 for ; Thu, 28 Aug 2003 15:43:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sSgQ-0005K2-00 for megaco@ietf.org; Thu, 28 Aug 2003 15:43:50 -0400 Received: from web20610.mail.yahoo.com ([216.136.226.168]) by ietf-mx with smtp (Exim 4.12) id 19sSgP-0005Jy-00 for megaco@ietf.org; Thu, 28 Aug 2003 15:43:49 -0400 Message-ID: <20030828194348.31487.qmail@web20610.mail.yahoo.com> Received: from [203.199.118.12] by web20610.mail.yahoo.com via HTTP; Thu, 28 Aug 2003 12:43:48 PDT Date: Thu, 28 Aug 2003 12:43:48 -0700 (PDT) From: narasingarao srinath To: megaco@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1188035683-1062099828=:31321" Subject: [Megaco] abbreviation of Megaco Packages Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --0-1188035683-1062099828=:31321 Content-Type: text/plain; charset=us-ascii Hi, Where can i find the abbreviation for all the megaco packages. Is there any document where all the packages are listed. Please suggest. regards, srinath. --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software --0-1188035683-1062099828=:31321 Content-Type: text/html; charset=us-ascii
Hi,
     Where can i find the abbreviation for all the megaco packages.
Is there any document where all the packages are listed.
Please suggest.
 
regards,
srinath.

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software --0-1188035683-1062099828=:31321-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Aug 29 03:12:37 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 DAA20255 for ; Fri, 29 Aug 2003 03:12: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 19sbuZ-0003yD-2U; Fri, 29 Aug 2003 01:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sbY2-00039q-Q0 for megaco@optimus.ietf.org; Fri, 29 Aug 2003 01:11: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 BAA27428 for ; Fri, 29 Aug 2003 01:11:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sbXz-0000Ez-00 for megaco@ietf.org; Fri, 29 Aug 2003 01:11:43 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19sbXy-0000Et-00 for megaco@ietf.org; Fri, 29 Aug 2003 01:11:42 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7T5BU31019499; Fri, 29 Aug 2003 07:11:30 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id Q9L3VYN3; Fri, 29 Aug 2003 07:11:29 +0200 Received: from lmf.ericsson.se (vir.lmf.ericsson.se [131.160.61.15]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h7T5BfSZ015401; Fri, 29 Aug 2003 08:11:41 +0300 (EET DST) Message-ID: <3F4EE084.8050209@lmf.ericsson.se> Date: Fri, 29 Aug 2003 08:11:32 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Henrik Taubert Organization: Oy L M Ericsson Ab User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en, sv, fi MIME-Version: 1.0 To: narasingarao srinath CC: megaco@ietf.org Subject: Re: [Megaco] abbreviation of Megaco Packages References: <20030828194348.31487.qmail@web20610.mail.yahoo.com> In-Reply-To: <20030828194348.31487.qmail@web20610.mail.yahoo.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 narasingarao srinath wrote: > Hi, > Where can i find the abbreviation for all the megaco packages. > Is there any document where all the packages are listed. > Please suggest. > > regards, > srinath. > Hi, at least at iana.org there is a list of all packages, with references to their specifications. The direct link is: http://www.iana.org/assignments/megaco-h248 regards, Henrik Taubert _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Aug 29 03:26:36 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 DAA21438 for ; Fri, 29 Aug 2003 03:26: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 19sdVv-00040K-6s for megaco-archive@odin.ietf.org; Fri, 29 Aug 2003 03:17:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T7HhMJ015387 for megaco-archive@odin.ietf.org; Fri, 29 Aug 2003 03:17:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sbuj-00040o-1Y for megaco-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 01:35: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 BAA29168 for ; Fri, 29 Aug 2003 01:35:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sbuf-0000eN-00 for megaco-web-archive@ietf.org; Fri, 29 Aug 2003 01:35:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sbuf-0000eK-00 for megaco-web-archive@ietf.org; Fri, 29 Aug 2003 01:35:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sZbR-0004uU-Be; Thu, 28 Aug 2003 23:07:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sX5t-0005RR-0O for megaco@optimus.ietf.org; Thu, 28 Aug 2003 20:26: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 UAA03859 for ; Thu, 28 Aug 2003 20:26:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sX5q-0002NJ-00 for megaco@ietf.org; Thu, 28 Aug 2003 20:26:22 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19sX5p-0002Me-00 for megaco@ietf.org; Thu, 28 Aug 2003 20:26:21 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h7T0NDF19300; Fri, 29 Aug 2003 10:23:13 +1000 (EST) Received: from ericsson.com.au (146.11.245.139 [146.11.245.139]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYCQD40D; Fri, 29 Aug 2003 10:25:18 +1000 Message-ID: <3F4E9D16.7010807@ericsson.com.au> Date: Fri, 29 Aug 2003 10:23:50 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ar c'hasour" CC: megaco@ietf.org Subject: Re: [Megaco] 2 terminations on different MGs References: <20030828172340.26597.qmail@web80707.mail.yahoo.com> In-Reply-To: <20030828172340.26597.qmail@web80707.mail.yahoo.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 Hello, You would use a MOD command to place the peer users IP addr/port in the remote descriptor. Please look at the H.248.1 appendix for an example. Chirstian Ar c'hasour wrote: > Hello > > I would like to a question regarding to a cluster of > MGs. > > Suppose I have a MGC which has created 2 "isolated" > terminations for 2 users: > For user1, termination t1 is in context c1 on MG1 > (ip-adr1, port1) > For user2, termination t2 is in context c2 on MG2 > (ip-adr2, port2) > In a sense, user1 has established a "channel" towards > MG1, and user 2 has done the same towards MG2. > > Now if end-user 1 wants to speak with end-user2, I > would like the MGC to order to send data received on > t1 towards t2. > > To do it, the first idea would be to "move" the > termination t2 on mg1, but then it would also be > needed to inform user 2 that t2's ip address has > changed and I need to avoid this. > > Is there another way to do with MEGACO ? > > Greetings, > P. Kasour > > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.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 Aug 29 04:54:51 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 EAA29710 for ; Fri, 29 Aug 2003 04:54:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sdvU-0005fZ-B0 for megaco-archive@odin.ietf.org; Fri, 29 Aug 2003 03:44:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T7i88C021781 for megaco-archive@odin.ietf.org; Fri, 29 Aug 2003 03:44:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sdQc-0003g4-Am for megaco-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 03:12: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 DAA20207 for ; Fri, 29 Aug 2003 03:12:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sdQZ-0002uV-00 for megaco-web-archive@ietf.org; Fri, 29 Aug 2003 03:12:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sdQY-0002uS-00 for megaco-web-archive@ietf.org; Fri, 29 Aug 2003 03:12:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sbuZ-0003yD-2U; Fri, 29 Aug 2003 01:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sbY2-00039q-Q0 for megaco@optimus.ietf.org; Fri, 29 Aug 2003 01:11: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 BAA27428 for ; Fri, 29 Aug 2003 01:11:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sbXz-0000Ez-00 for megaco@ietf.org; Fri, 29 Aug 2003 01:11:43 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19sbXy-0000Et-00 for megaco@ietf.org; Fri, 29 Aug 2003 01:11:42 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7T5BU31019499; Fri, 29 Aug 2003 07:11:30 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id Q9L3VYN3; Fri, 29 Aug 2003 07:11:29 +0200 Received: from lmf.ericsson.se (vir.lmf.ericsson.se [131.160.61.15]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h7T5BfSZ015401; Fri, 29 Aug 2003 08:11:41 +0300 (EET DST) Message-ID: <3F4EE084.8050209@lmf.ericsson.se> Date: Fri, 29 Aug 2003 08:11:32 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Henrik Taubert Organization: Oy L M Ericsson Ab User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en, sv, fi MIME-Version: 1.0 To: narasingarao srinath CC: megaco@ietf.org Subject: Re: [Megaco] abbreviation of Megaco Packages References: <20030828194348.31487.qmail@web20610.mail.yahoo.com> In-Reply-To: <20030828194348.31487.qmail@web20610.mail.yahoo.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 narasingarao srinath wrote: > Hi, > Where can i find the abbreviation for all the megaco packages. > Is there any document where all the packages are listed. > Please suggest. > > regards, > srinath. > Hi, at least at iana.org there is a list of all packages, with references to their specifications. The direct link is: http://www.iana.org/assignments/megaco-h248 regards, Henrik Taubert _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Aug 29 05:51:13 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 FAA05072 for ; Fri, 29 Aug 2003 05:51:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19seA5-0006vG-Mm for megaco-archive@odin.ietf.org; Fri, 29 Aug 2003 03:59:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T7xD6l026609 for megaco-archive@odin.ietf.org; Fri, 29 Aug 2003 03:59:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19scq8-0001V1-DK for megaco-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 02:34: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 CAA17184 for ; Fri, 29 Aug 2003 02:34:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19scq4-0002F2-00 for megaco-web-archive@ietf.org; Fri, 29 Aug 2003 02:34:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19scq3-0002Ez-00 for megaco-web-archive@ietf.org; Fri, 29 Aug 2003 02:34:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sb2L-0001j7-Dc; Fri, 29 Aug 2003 00: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 19sX4A-0005KB-ID for megaco@optimus.ietf.org; Thu, 28 Aug 2003 20: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 UAA03731 for ; Thu, 28 Aug 2003 20:24:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sX48-0002L5-00 for megaco@ietf.org; Thu, 28 Aug 2003 20:24:36 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 19sX47-0002KE-00 for megaco@ietf.org; Thu, 28 Aug 2003 20:24:35 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h7T0LQF19128; Fri, 29 Aug 2003 10:21:26 +1000 (EST) Received: from ericsson.com.au (146.11.245.139 [146.11.245.139]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYCQD48V; Fri, 29 Aug 2003 10:23:31 +1000 Message-ID: <3F4E9CAB.7020901@ericsson.com.au> Date: Fri, 29 Aug 2003 10:22:03 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: narasingarao srinath CC: megaco@ietf.org Subject: Re: [Megaco] abbreviation of Megaco Packages References: <20030828194348.31487.qmail@web20610.mail.yahoo.com> In-Reply-To: <20030828194348.31487.qmail@web20610.mail.yahoo.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 http://www.iana.org/assignments/megaco-h248 or the packages supplement: http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-H.Sup2 Christian narasingarao srinath wrote: > Hi, > Where can i find the abbreviation for all the megaco packages. > Is there any document where all the packages are listed. > Please suggest. > > regards, > srinath. > > ------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! SiteBuilder > - Free, > easy-to-use web site design software _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Aug 29 05:58:14 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 FAA06028 for ; Fri, 29 Aug 2003 05:58:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19se65-0006aO-8e; Fri, 29 Aug 2003 03:55:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19scO4-0006CU-3U for megaco@optimus.ietf.org; Fri, 29 Aug 2003 02:05: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 CAA07429 for ; Fri, 29 Aug 2003 02:05:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19scO0-0001TK-00 for megaco@ietf.org; Fri, 29 Aug 2003 02:05:28 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19scNz-0001TH-00 for megaco@ietf.org; Fri, 29 Aug 2003 02:05:27 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7T65Q31026218; Fri, 29 Aug 2003 08:05:27 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 29 Aug 2003 08:06:29 +0200 Message-ID: From: "Christer Holmberg (KI/LMF)" To: "'Gunter Weiss'" , "'megaco@ietf.org'" Subject: RE: [Megaco] Question concerning Dynamic Payload Type negotiation /configuration Date: Fri, 29 Aug 2003 08:05:06 +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, Comments inline ([CHH]) >I have some basic questions on Dynamic PT negotiation within >H.248/SDP: >-------------------------------------------------------------- >--------- > How is it considered in a H.248 controlled network to negotiate > the Dynamic Payload type (used for DTMF relay a'la RFC2833) > between the two ends (Media Gateways) via the MGC. > In detail I'm interested to know, how will the first ADD request > from the MGC to the originating Gateway look like? > 1.1 > Will the MGC already send a dynamic payload in the session > description > of the first Add request from MGC towards the Gateway? > e.g.: > MGC >> MG: > m=audio $ RTP/AVP 8 96 > a=rtpmap:96 telephone-event/8000 > > MG >> MGC: > m=audio 10036 RTP/AVP 8 96 > a=rtpmap:96 telephone-event/8000 [CHH] This looks correct. > 1.1.1: What will be if the Gateway has another default PT for > let's say DTMF relay? Can it responsen than in the following way: > > MG >> MGC: > m=audio 10036 RTP/AVP 8 97 > a=rtpmap:97 telephone-event/8000 > > Or is it considered that the GW can always adapt the PT?? [CHH] That is an interesting question. It IS allowed, to my understanding, to use different PT in each media direction, for the same codec, but I am not sure H.248 allows you to override defined values. Also, I can't remember that the H.248 spec it would be forbidden to use the "$" wildcard for the payload type. But, in that case you would have to insert "$" in both the m= line and the rtpmap attribute. m=audio $ RTP/AVP 8 $ a=rtpmap: $ telephone-event/8000 ...but I am not sure that would work. Assume you have multiple rtpmap attributes, together with some fmtp attributes. How would the MG be able to map a specific fmtp attribute with a specific rtpmap attribute, since both only have "$" defined as payload type. And, no matter if it's allowed or not, I think that having a "default" payload type value, as you define it, is maybe not a very good idea... > 1.2 If the MGC will send already two PTs in the m line , > will there be the ReserveValue set to true or is in this > case the ReserveValue not considered at all as the Dynamic PT is > a further specification, what the resource should be able > to handle? > > MGC >> MG: > > MEGACO/1.0 [123.123.123.4]:55555 > Transaction = 11 { > Context = $ { > Add = DS0/1/1 > Add = $ { > Media { > LocalControl{ > Mode = ReceiveOnly, > ReserveValue = true}; > Local{ > v=0 > c=IN IP4 $ > m=audio $ RTP/AVP 8 96 > a=rtpmap:96 telephone-event/8000 > } > }}}} [CHH] I am not sure what you mean. I don't think ReserveValue has anything to do with the fact is a payload type is dynamic or static. > 1.3 Or is it not sent in the request from the MGC, but sent in the > response from the MG to the MGC? > e.g. > MGC >> MG: > m=audio $ RTP/AVP 8 > > MG >> MGC: > m=audio 10036 RTP/AVP 8 96 > a=rtpmap:96 telephone-event/8000 [CHH] This is wrong. > or another possible way to report the capabilities: > e.g.: > MGC >> MG: > m=audio $ RTP/AVP 8 > > MG >> MGC: > m=audio 3456 RTP/AVP 8 > a=sqn: 0 > a=cdsc: 1 audio RTP/AVP 8 96 > a=cpar: a=rtpmap:96 telephone-event/8000 [CHH] I'm lost... :) Regards, Christer Holmberg Ericsson Finland > > > If there are already scenarios on this topic please point me to it! > > Thanks in advance, > Gunter! > > -- > Gunter Weiss, VS/NGE, VND > +--------V--------+ Competance Area Leader - Gateway Protocols > | A L C A T E L | callto: +49-711-821-41613 faxto : .-40247 > +-----------------+ mailto:G.Weiss@alcatel.de > > _______________________________________________ > 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 Aug 29 09:05:59 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 JAA20623 for ; Fri, 29 Aug 2003 09:05:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19shcf-0002RS-KE for megaco-archive@odin.ietf.org; Fri, 29 Aug 2003 07:40:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TBevl1009376 for megaco-archive@odin.ietf.org; Fri, 29 Aug 2003 07:40:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sg0v-0005KW-8I for megaco-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 05:57: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 FAA06004 for ; Fri, 29 Aug 2003 05:57:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sg0r-0006zB-00 for megaco-web-archive@ietf.org; Fri, 29 Aug 2003 05:57:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sg0q-0006z8-00 for megaco-web-archive@ietf.org; Fri, 29 Aug 2003 05:57:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19se65-0006aO-8e; Fri, 29 Aug 2003 03:55:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19scO4-0006CU-3U for megaco@optimus.ietf.org; Fri, 29 Aug 2003 02:05: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 CAA07429 for ; Fri, 29 Aug 2003 02:05:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19scO0-0001TK-00 for megaco@ietf.org; Fri, 29 Aug 2003 02:05:28 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19scNz-0001TH-00 for megaco@ietf.org; Fri, 29 Aug 2003 02:05:27 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7T65Q31026218; Fri, 29 Aug 2003 08:05:27 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 29 Aug 2003 08:06:29 +0200 Message-ID: From: "Christer Holmberg (KI/LMF)" To: "'Gunter Weiss'" , "'megaco@ietf.org'" Subject: RE: [Megaco] Question concerning Dynamic Payload Type negotiation /configuration Date: Fri, 29 Aug 2003 08:05:06 +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, Comments inline ([CHH]) >I have some basic questions on Dynamic PT negotiation within >H.248/SDP: >-------------------------------------------------------------- >--------- > How is it considered in a H.248 controlled network to negotiate > the Dynamic Payload type (used for DTMF relay a'la RFC2833) > between the two ends (Media Gateways) via the MGC. > In detail I'm interested to know, how will the first ADD request > from the MGC to the originating Gateway look like? > 1.1 > Will the MGC already send a dynamic payload in the session > description > of the first Add request from MGC towards the Gateway? > e.g.: > MGC >> MG: > m=audio $ RTP/AVP 8 96 > a=rtpmap:96 telephone-event/8000 > > MG >> MGC: > m=audio 10036 RTP/AVP 8 96 > a=rtpmap:96 telephone-event/8000 [CHH] This looks correct. > 1.1.1: What will be if the Gateway has another default PT for > let's say DTMF relay? Can it responsen than in the following way: > > MG >> MGC: > m=audio 10036 RTP/AVP 8 97 > a=rtpmap:97 telephone-event/8000 > > Or is it considered that the GW can always adapt the PT?? [CHH] That is an interesting question. It IS allowed, to my understanding, to use different PT in each media direction, for the same codec, but I am not sure H.248 allows you to override defined values. Also, I can't remember that the H.248 spec it would be forbidden to use the "$" wildcard for the payload type. But, in that case you would have to insert "$" in both the m= line and the rtpmap attribute. m=audio $ RTP/AVP 8 $ a=rtpmap: $ telephone-event/8000 ...but I am not sure that would work. Assume you have multiple rtpmap attributes, together with some fmtp attributes. How would the MG be able to map a specific fmtp attribute with a specific rtpmap attribute, since both only have "$" defined as payload type. And, no matter if it's allowed or not, I think that having a "default" payload type value, as you define it, is maybe not a very good idea... > 1.2 If the MGC will send already two PTs in the m line , > will there be the ReserveValue set to true or is in this > case the ReserveValue not considered at all as the Dynamic PT is > a further specification, what the resource should be able > to handle? > > MGC >> MG: > > MEGACO/1.0 [123.123.123.4]:55555 > Transaction = 11 { > Context = $ { > Add = DS0/1/1 > Add = $ { > Media { > LocalControl{ > Mode = ReceiveOnly, > ReserveValue = true}; > Local{ > v=0 > c=IN IP4 $ > m=audio $ RTP/AVP 8 96 > a=rtpmap:96 telephone-event/8000 > } > }}}} [CHH] I am not sure what you mean. I don't think ReserveValue has anything to do with the fact is a payload type is dynamic or static. > 1.3 Or is it not sent in the request from the MGC, but sent in the > response from the MG to the MGC? > e.g. > MGC >> MG: > m=audio $ RTP/AVP 8 > > MG >> MGC: > m=audio 10036 RTP/AVP 8 96 > a=rtpmap:96 telephone-event/8000 [CHH] This is wrong. > or another possible way to report the capabilities: > e.g.: > MGC >> MG: > m=audio $ RTP/AVP 8 > > MG >> MGC: > m=audio 3456 RTP/AVP 8 > a=sqn: 0 > a=cdsc: 1 audio RTP/AVP 8 96 > a=cpar: a=rtpmap:96 telephone-event/8000 [CHH] I'm lost... :) Regards, Christer Holmberg Ericsson Finland > > > If there are already scenarios on this topic please point me to it! > > Thanks in advance, > Gunter! > > -- > Gunter Weiss, VS/NGE, VND > +--------V--------+ Competance Area Leader - Gateway Protocols > | A L C A T E L | callto: +49-711-821-41613 faxto : .-40247 > +-----------------+ mailto:G.Weiss@alcatel.de > > _______________________________________________ > 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 Sat Aug 30 00:58:03 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 AAA09321 for ; Sat, 30 Aug 2003 00:58:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sv8E-0008LU-2y; Fri, 29 Aug 2003 22:06:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sqHQ-0003kz-9h for megaco@optimus.ietf.org; Fri, 29 Aug 2003 16:55:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04281 for ; Fri, 29 Aug 2003 16:55:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sqHO-0006zx-00 for megaco@ietf.org; Fri, 29 Aug 2003 16:55:34 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.71] helo=mailrelay1.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 19sqHN-0006yw-00 for megaco@ietf.org; Fri, 29 Aug 2003 16:55:33 -0400 Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id WAA24263; Fri, 29 Aug 2003 22:54:53 +0200 (MET DST) Received: from slssiw ([149.204.245.113] helo=slsdtk.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 19sqGl-0006fn-00; Fri, 29 Aug 2003 22:54:55 +0200 Received: from slsufnt ([149.204.245.33] helo=alcatel.de) by slsdtk.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 19sqGl-0000K7-00; Fri, 29 Aug 2003 22:54:55 +0200 Message-ID: <3F4FBF59.8B49C44F@alcatel.de> Date: Fri, 29 Aug 2003 23:02:17 +0200 From: Gunter Weiss Organization: Alcatel SEL AG X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh-CN,zh MIME-Version: 1.0 To: "Christer Holmberg (KI/LMF)" CC: "'megaco@ietf.org'" Subject: Re: [Megaco] Question concerning Dynamic Payload Type negotiation/configuration References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes 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 Christer, thanks for your reply. I know it could be confusing but in general it is also confusing. The best at all would be to have an agreed Payload Type for DTMF relay a'la RFC 2833 with hin the range of 97 to 128. Then there are still numbers reserved for dynamic PT's. DTMF relay especially in domains with compressed codecs is a typical feature to be provided. Well that's my personal feeling! But now to your answers/questions/comments - see inline [GW]: "Christer Holmberg (KI/LMF)" wrote: > > Hi, > > Comments inline ([CHH]) > > >I have some basic questions on Dynamic PT negotiation within > >H.248/SDP: > >-------------------------------------------------------------- > >--------- > > How is it considered in a H.248 controlled network to negotiate > > the Dynamic Payload type (used for DTMF relay a'la RFC2833) > > between the two ends (Media Gateways) via the MGC. > > In detail I'm interested to know, how will the first ADD request > > from the MGC to the originating Gateway look like? > > 1.1 > > Will the MGC already send a dynamic payload in the session > > description > > of the first Add request from MGC towards the Gateway? > > e.g.: > > MGC >> MG: > > m=audio $ RTP/AVP 8 96 > > a=rtpmap:96 telephone-event/8000 > > > > MG >> MGC: > > m=audio 10036 RTP/AVP 8 96 > > a=rtpmap:96 telephone-event/8000 > > [CHH] This looks correct. > > > 1.1.1: What will be if the Gateway has another default PT for > > let's say DTMF relay? Can it responsen than in the following way: > > > > MG >> MGC: > > m=audio 10036 RTP/AVP 8 97 > > a=rtpmap:97 telephone-event/8000 > > > > Or is it considered that the GW can always adapt the PT?? > > [CHH] That is an interesting question. It IS allowed, to my understanding, to use different PT in each media direction, for > the same codec, but I am not sure H.248 allows you to override defined values. [GW] Are you sure on that? > Also, I can't remember that the H.248 spec it would be forbidden to use the "$" wildcard for the payload type. But, in that > case you would have to insert "$" in both the m= line and the rtpmap attribute. > > m=audio $ RTP/AVP 8 $ > a=rtpmap: $ telephone-event/8000 > > ...but I am not sure that would work. Assume you have multiple rtpmap attributes, together with some fmtp attributes. How > would the MG be able to map a specific fmtp attribute with a specific rtpmap attribute, since both only have "$" defined as > payload type. [GW] I'm not sure that SDP would allow such a choose parameter?? > > And, no matter if it's allowed or not, I think that having a "default" payload type value, as you define it, is maybe not a > very good idea... [GW] let me put it this way. Assuming a Gateway with a DSP. A DSP will have default value when you configure it although it can be overidden during a Call Setup phase! But let's assume the MG must always adapt to what the MGC is saying. I hope all the smart phones and SIP clients can adapt too! > > > 1.2 If the MGC will send already two PTs in the m line , > > will there be the ReserveValue set to true or is in this > > case the ReserveValue not considered at all as the Dynamic PT is > > a further specification, what the resource should be able > > to handle? > > > > MGC >> MG: > > > > MEGACO/1.0 [123.123.123.4]:55555 > > Transaction = 11 { > > Context = $ { > > Add = DS0/1/1 > > Add = $ { > > Media { > > LocalControl{ > > Mode = ReceiveOnly, > > ReserveValue = true}; > > Local{ > > v=0 > > c=IN IP4 $ > > m=audio $ RTP/AVP 8 96 > > a=rtpmap:96 telephone-event/8000 > > } > > }}}} > > [CHH] I am not sure what you mean. I don't think ReserveValue has anything to do with the fact is a payload type is dynamic or > static. [GW] I meant that normally if a MG replies not with only one media format (PT) there must be a the ReserveValue set to true otherwise it would only return the select/ configured one. Or am I wrong?? The reason for considering this was, that in my oppinion the Dynamic PT is a more specific description, what the resource reserved/allocated for the request of the MGC is able to handle too. I'm also not convinced to consider ReserveValue when talking about DTMF relay , but I wanted to know the generall opinion from the megaco community! > > > 1.3 Or is it not sent in the request from the MGC, but sent in the > > response from the MG to the MGC? > > e.g. > > MGC >> MG: > > m=audio $ RTP/AVP 8 > > > > MG >> MGC: > > m=audio 10036 RTP/AVP 8 96 > > a=rtpmap:96 telephone-event/8000 > > [CHH] This is wrong. [GW] When you say it's wrong then you just assume that the MGC will always trigger a negotiation? This brings me to another point : If the MGC will not send anything about DTMF relay (telephony events) to an MG - do you think that the MG is allowed to relay or does it has to send such events then always inband?? > > > or another possible way to report the capabilities: > > e.g.: > > MGC >> MG: > > m=audio $ RTP/AVP 8 > > > > MG >> MGC: > > m=audio 3456 RTP/AVP 8 > > a=sqn: 0 > > a=cdsc: 1 audio RTP/AVP 8 96 > > a=cpar: a=rtpmap:96 telephone-event/8000 > > [CHH] I'm lost... :) [GW] This was analog RFC 3407 a possible way to tell the MGC that the MG can even more with the resource than what was just requested?? I'm not sure that this is a practicle way? > > Regards, > > Christer Holmberg > Ericsson Finland > Best Regards, Gunter > > > > > > If there are already scenarios on this topic please point me to it! > > > > Thanks in advance, > > Gunter! > > > > -- > > Gunter Weiss, VS/NGE, VND > > +--------V--------+ Competance Area Leader - Gateway Protocols > > | A L C A T E L | callto: +49-711-821-41613 faxto : .-40247 > > +-----------------+ mailto:G.Weiss@alcatel.de > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Sat Aug 30 04:54: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 EAA02328 for ; Sat, 30 Aug 2003 04:54:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t0ka-0001gq-Nw for megaco-archive@odin.ietf.org; Sat, 30 Aug 2003 04:06:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7U86NTZ006485 for megaco-archive@odin.ietf.org; Sat, 30 Aug 2003 04:06:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sxnz-0007q9-7L for megaco-web-archive@optimus.ietf.org; Sat, 30 Aug 2003 00:57: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 AAA09298 for ; Sat, 30 Aug 2003 00:57:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sxnv-0006zf-00 for megaco-web-archive@ietf.org; Sat, 30 Aug 2003 00:57:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sxnv-0006zb-00 for megaco-web-archive@ietf.org; Sat, 30 Aug 2003 00:57:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sv8E-0008LU-2y; Fri, 29 Aug 2003 22:06:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sqHQ-0003kz-9h for megaco@optimus.ietf.org; Fri, 29 Aug 2003 16:55:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04281 for ; Fri, 29 Aug 2003 16:55:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sqHO-0006zx-00 for megaco@ietf.org; Fri, 29 Aug 2003 16:55:34 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.71] helo=mailrelay1.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 19sqHN-0006yw-00 for megaco@ietf.org; Fri, 29 Aug 2003 16:55:33 -0400 Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id WAA24263; Fri, 29 Aug 2003 22:54:53 +0200 (MET DST) Received: from slssiw ([149.204.245.113] helo=slsdtk.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 19sqGl-0006fn-00; Fri, 29 Aug 2003 22:54:55 +0200 Received: from slsufnt ([149.204.245.33] helo=alcatel.de) by slsdtk.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 19sqGl-0000K7-00; Fri, 29 Aug 2003 22:54:55 +0200 Message-ID: <3F4FBF59.8B49C44F@alcatel.de> Date: Fri, 29 Aug 2003 23:02:17 +0200 From: Gunter Weiss Organization: Alcatel SEL AG X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh-CN,zh MIME-Version: 1.0 To: "Christer Holmberg (KI/LMF)" CC: "'megaco@ietf.org'" Subject: Re: [Megaco] Question concerning Dynamic Payload Type negotiation/configuration References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes 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 Christer, thanks for your reply. I know it could be confusing but in general it is also confusing. The best at all would be to have an agreed Payload Type for DTMF relay a'la RFC 2833 with hin the range of 97 to 128. Then there are still numbers reserved for dynamic PT's. DTMF relay especially in domains with compressed codecs is a typical feature to be provided. Well that's my personal feeling! But now to your answers/questions/comments - see inline [GW]: "Christer Holmberg (KI/LMF)" wrote: > > Hi, > > Comments inline ([CHH]) > > >I have some basic questions on Dynamic PT negotiation within > >H.248/SDP: > >-------------------------------------------------------------- > >--------- > > How is it considered in a H.248 controlled network to negotiate > > the Dynamic Payload type (used for DTMF relay a'la RFC2833) > > between the two ends (Media Gateways) via the MGC. > > In detail I'm interested to know, how will the first ADD request > > from the MGC to the originating Gateway look like? > > 1.1 > > Will the MGC already send a dynamic payload in the session > > description > > of the first Add request from MGC towards the Gateway? > > e.g.: > > MGC >> MG: > > m=audio $ RTP/AVP 8 96 > > a=rtpmap:96 telephone-event/8000 > > > > MG >> MGC: > > m=audio 10036 RTP/AVP 8 96 > > a=rtpmap:96 telephone-event/8000 > > [CHH] This looks correct. > > > 1.1.1: What will be if the Gateway has another default PT for > > let's say DTMF relay? Can it responsen than in the following way: > > > > MG >> MGC: > > m=audio 10036 RTP/AVP 8 97 > > a=rtpmap:97 telephone-event/8000 > > > > Or is it considered that the GW can always adapt the PT?? > > [CHH] That is an interesting question. It IS allowed, to my understanding, to use different PT in each media direction, for > the same codec, but I am not sure H.248 allows you to override defined values. [GW] Are you sure on that? > Also, I can't remember that the H.248 spec it would be forbidden to use the "$" wildcard for the payload type. But, in that > case you would have to insert "$" in both the m= line and the rtpmap attribute. > > m=audio $ RTP/AVP 8 $ > a=rtpmap: $ telephone-event/8000 > > ...but I am not sure that would work. Assume you have multiple rtpmap attributes, together with some fmtp attributes. How > would the MG be able to map a specific fmtp attribute with a specific rtpmap attribute, since both only have "$" defined as > payload type. [GW] I'm not sure that SDP would allow such a choose parameter?? > > And, no matter if it's allowed or not, I think that having a "default" payload type value, as you define it, is maybe not a > very good idea... [GW] let me put it this way. Assuming a Gateway with a DSP. A DSP will have default value when you configure it although it can be overidden during a Call Setup phase! But let's assume the MG must always adapt to what the MGC is saying. I hope all the smart phones and SIP clients can adapt too! > > > 1.2 If the MGC will send already two PTs in the m line , > > will there be the ReserveValue set to true or is in this > > case the ReserveValue not considered at all as the Dynamic PT is > > a further specification, what the resource should be able > > to handle? > > > > MGC >> MG: > > > > MEGACO/1.0 [123.123.123.4]:55555 > > Transaction = 11 { > > Context = $ { > > Add = DS0/1/1 > > Add = $ { > > Media { > > LocalControl{ > > Mode = ReceiveOnly, > > ReserveValue = true}; > > Local{ > > v=0 > > c=IN IP4 $ > > m=audio $ RTP/AVP 8 96 > > a=rtpmap:96 telephone-event/8000 > > } > > }}}} > > [CHH] I am not sure what you mean. I don't think ReserveValue has anything to do with the fact is a payload type is dynamic or > static. [GW] I meant that normally if a MG replies not with only one media format (PT) there must be a the ReserveValue set to true otherwise it would only return the select/ configured one. Or am I wrong?? The reason for considering this was, that in my oppinion the Dynamic PT is a more specific description, what the resource reserved/allocated for the request of the MGC is able to handle too. I'm also not convinced to consider ReserveValue when talking about DTMF relay , but I wanted to know the generall opinion from the megaco community! > > > 1.3 Or is it not sent in the request from the MGC, but sent in the > > response from the MG to the MGC? > > e.g. > > MGC >> MG: > > m=audio $ RTP/AVP 8 > > > > MG >> MGC: > > m=audio 10036 RTP/AVP 8 96 > > a=rtpmap:96 telephone-event/8000 > > [CHH] This is wrong. [GW] When you say it's wrong then you just assume that the MGC will always trigger a negotiation? This brings me to another point : If the MGC will not send anything about DTMF relay (telephony events) to an MG - do you think that the MG is allowed to relay or does it has to send such events then always inband?? > > > or another possible way to report the capabilities: > > e.g.: > > MGC >> MG: > > m=audio $ RTP/AVP 8 > > > > MG >> MGC: > > m=audio 3456 RTP/AVP 8 > > a=sqn: 0 > > a=cdsc: 1 audio RTP/AVP 8 96 > > a=cpar: a=rtpmap:96 telephone-event/8000 > > [CHH] I'm lost... :) [GW] This was analog RFC 3407 a possible way to tell the MGC that the MG can even more with the resource than what was just requested?? I'm not sure that this is a practicle way? > > Regards, > > Christer Holmberg > Ericsson Finland > Best Regards, Gunter > > > > > > If there are already scenarios on this topic please point me to it! > > > > Thanks in advance, > > Gunter! > > > > -- > > Gunter Weiss, VS/NGE, VND > > +--------V--------+ Competance Area Leader - Gateway Protocols > > | A L C A T E L | callto: +49-711-821-41613 faxto : .-40247 > > +-----------------+ mailto:G.Weiss@alcatel.de > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco